A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Análise e Projetos de Sistemas Orientados a Objetos

Apresentações semelhantes


Apresentação em tema: "Análise e Projetos de Sistemas Orientados a Objetos"— Transcrição da apresentação:

1 Análise e Projetos de Sistemas Orientados a Objetos
Prof. André Argeri Ribeirão Preto, Fevereiro 2010

2 Apresentação da Disciplina
Conteúdo Programático: O que é a UML? Histórico UML Princípios da modelagem Orientação a Objetos Ferramentas CASE baseadas na linguagem UML Diagramas

3 Apresentação da Disciplina
Objetivo Geral Conhecer e desenvolver todos diagramas da UML.

4 Apresentação da Disciplina
Bibliografia: BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML Guia do Usuário (2ª Edição). Rio de Janeiro: Elsevier, 2005. Guedes, G.T.A. UML 2 Guia de Consulta Rápida (2ª Edição). São Paulo: Notatec, 2005. Pilone, D.; Pitman, N. UML 2 Rápido e Prático. Alta Books, 2006.

5 O que é a UML? UML – Unified Modeling Language ou Linguagem de Modelagem Unificada. Linguagem altamente adotada mundialmente pela indústria de Engenharia de Software. Não é linguagem de programação. O objetivo dela é auxiliar todas as pessoas que estão envolvidas no projeto.

6 Características da UML
Requisitos. Comportamento. Estrutura lógica. Dinâmica de seus processos. Até necessidades físicas em relação ao equipamento sobre o qual o sistema deverá ser implantado. Importante: Todas essas características são definidas por meio da UML antes do software começar a ser realmente desenvolvido.

7 Histórico da UML União de três metodologias: Método Booch.
Método OMT (Object Modeling Techinique) – Jacobson. Método OOSE (Object Oriented Software Engineering) – Rumbaugh. Estas eram as metodologias usadas até meados da década de 90.

8 Histórico da UML O esforço inicial do projeto iniciou com a União do método de Booch com o método OMT de Jacobson, o que resultou no lançamento do método Unificado no final de 95. Logo em seguida, juntou-se Rumbaugh com o método OOSE que começou a ser incorporado à nova tecnologia. Em 96 foi lançada a primeira versão da UML.

9 Histórico da UML Tão logo a primeira versão foi lançada, diversas grandes empresas atuantes na área de engenharia e desenvolvimento de software passaram a contribuir com o projeto, fornecendo sugestões para melhorar e ampliar a linguagem.

10 Princípios da modelagem
1º - A escolha dos modelos a serem criados tem profunda influência sobre a maneira como um determinado problema é atacado e como uma solução é definida; 2º - Cada modelo poderá ser expresso em diferentes níveis de precisão;

11 Princípios da modelagem
3º - Os melhores modelos estão relacionados à realidade; 4º - Nenhum modelo único é suficiente. Qualquer sistema não-trivial será melhor investigado por meio de um pequeno conjunto de modelos quase independentes com vários pontos de vista.

12 Orientação a Objetos O método orientado a objetos para o desenvolvimento do software é, com certeza, uma parte do fluxo principal, simplesmente porque tem sido provado seu valor para a construção de sistemas em todos os tipos de domínios de problemas, abrangendo todos os graus de tamanho e de complexidade. Alem disso, muitas linguagens, sistemas operacionais e ferramentas contemporâneos são, de alguma forma, orientados a objetos, fortalecendo a visão de mundo em termos de objetos.

13 UML é uma Linguagem para documentação
Requisitos Arquitetura Projeto Código fonte Planos de projetos Testes Prototipos

14 Ferramentas CASE baseadas na linguagem UML
Ferramentas CASE (computer aided software engineering ou engenharia de software auxiliada por computador, são softwares que de alguma maneira colaboram para a execução de uma ou mais atividades realizadas durante o processo de engenharia de software.

15 Exemplos de Ferramentas
Rational Rose Enterprise Architect Visual Paradigm for UML ou VP-UML Poseidon for UML ArgoUML Jude Entre outros.

16 Diagramas Diagrama de Classes Diagrama de Objetos
Diagrama de componentes Diagrama de estruturas compostas Diagrama de caso de uso Diagrama de seqüências Diagrama de comunicações

17 Diagramas Diagrama de gráficos de estados Diagrama de atividades
Diagrama de implantação Diagrama de pacote Diagrama de temporização Diagrama de visão geral de interação No total são 13 diagramas.

18 Diagrama de caso de uso Este diagrama procura, por meio de uma linguagem simples, demonstrar o comportamento externo do sistema, procurando apresentar o sistema através de uma perspectiva do usuário, demonstrando as funções e serviços oferecidos e quais usuários poderão utilizar cada serviço.

19 Diagrama de caso de uso Este diagrama é, dentre todos os diagramas da UML, o mais abstrato, flexível e informal, sendo utilizado principalmente no inicio da modelagem do sistema, embora venha a ser consultado e possivelmente modificado durante todo o processo de engenharia e sirva de base para a modelagem de outros programas.

20 Diagrama de caso de uso Atores (Bonecos Magros)
Os atores representam os papéis desempenhados pelos diversos usuários que poderão utilizar ou interagir com os serviços e funções do sistema. Eventualmente um ator pode representar algum hardware especial ou mesmo um outro software que interaja com o sistema. Ele possuem uma breve descrição logo abaixo do seu símbolo que identifica o papel que o autor assume dentro do diagrama

21 Diagrama de caso de uso Casos de Uso
Os casos de uso referem-se aos serviços, tarefas ou funções oferecidas pelo sistema, como emitir um relatório ou cadastrar a venda de algum produto. São utilizados para expressar e documentar os comportamentos pretendidos para as funções do sistema.

22 Diagrama de caso de uso Casos de Uso
Os casos de uso costumam ser documentados , demonstrando qual o comportamento pretendido para o caso de uso em questão e quais funções ele executará quando for solicitado.

23 Diagrama de caso de uso Casos de Uso.
Nome do caso de uso Objetivo Atores Passos

24 Diagrama de caso de uso Casos de Uso.
Exemplo da descrição do caso de uso: Nome: Visualizar Notas e faltas. Objetivo: Listar para o aluno as suas respectivas informações. Ator: Aluno. Passos 1 – O ator entra com o seu numero de matricula e senha. 2 – O sistema Lista os períodos. 3 – O ator seleciona o período desejado 4 – O sistema lista as informações para o ator.

25 Diagrama de caso de uso Casos de Uso.
Restrições 1.1 – O sistema verifica se o nome o número de matricula está correto, caso negativo, o sistema bloqueia a entrada no sistema e exibe mensagem. 1.2 – O sistema verifica se a senha condiz com o número de matricula, caso negativo, o sistema bloqueia a entrada do sistema e exibe mensagem. 3.1 – O ator não seleciona o período, o sistema solicita o preenchimento do mesmo.

26 Diagrama de caso de uso Associações.
As associações representam os relacionamentos entre os atores que interagem com o sistema, entre os atores e os casos de uso. Relacionamentos entre os casos de uso recebem nomes especiais, como inclusão, extensão e generalização.

27 Diagrama de caso de uso Associações.
Uma associação entre um ator e um caso de uso demonstra que o ator utiliza-se, de alguma maneira, da função representada pelo caso de uso. A associação entre um ator e um caso de uso é representado por uma reta ligando o ator com o caso de uso, podendo ocorrer que as extremidades da reta contenham setas, indicando a navegabilidade da associação, ou seja, se as informações são fornecidas pelo autor ao caso de uso, se não transmitidas do caso de uso para o autor ou ambos (neste ultimo caso a reta não possui setas).

28 Diagrama de caso de uso Especialização / Generalização
Este relacionamento é uma forma de associações entre casos de uso na qual existem dois ou mais casos de uso com características semelhantes, apresentando pequenas diferenças entre si.

29 Diagrama de caso de uso Especialização / Generalização
Quando tal situação ocorre, costuma-se definir um caso de uso geral, que descreve as características compartilhadas por todos os casos de uso em questão, e então relacioná-lo com estes, cuja documentação conterá somente as características específicas de cada um. Assim não é necessário colocar a mesma documentação para todos os casos de uso envolvidos, porque toda a estrutura de um caso de uso generalizado é herdada pelos casos de uso especializados, incluindo quaisquer possíveis associações.

30 Diagrama de caso de uso Inclusão (include)
Esta associação é utilizada quando existe um situação ou rotina comum a mais de uma caso de uso. Quando ocorre, a documentação dessa rotina é colocada em caso de uso específico para que outros caso de uso utilizem-se desse serviço, evitando-se descrever uma mesma seqüência de passos em vários casos de uso.

31 Diagrama de caso de uso Inclusão (include)
Os relacionamentos de inclusão indicam uma obrigatoriedade, ou seja, quando um determinado caso de uso possui um relacionamento de inclusão com outro, a execução do primeiro obriga também a execução do segundo. Um relacionamento de inclusão pode ser comparado à chamada de uma sub-rotina.

32 Diagrama de caso de uso Inclusão (include)
Exemplo

33 Diagrama de caso de uso Extensão (extend)
Esta associação é utilizada para descrever cenários opcionais de um caso de uso, que somente ocorrerão se uma determinada condição for satisfeita. As associações de extensão possuem uma representação muito semelhante às associações de inclusão, sendo também representados por uma linha tracejada.

34 Diagrama de caso de uso Extensão (extend)
Exemplo

35 Diagrama de caso de uso Multiplicidade
A multiplicidade em uma associação entre um ator e um caso de uso basicamente especifica o número de vezes que um ator pode utilizar um determinado caso de uso.

36 Diagrama de caso de uso Fronteira do Sistema
Um fronteira do sistema identifica um classificador que contém um conjunto de casos de uso. Uma fronteira de sistema permite identificar um sub-sistema ou mesmo um sistema completo, além de destacar o que está contido no sistema e o que não está.

37 Diagrama de caso de uso Exercício
Fazer o diagrama de caso de uso referente ao atendimento do paciente: O atendimento começa quando o paciente chega e avisa o atendente de sua chegada. O atendente por sua vez entra no sistema e marca que o paciente já está pronto para a consulta. O medico faz a consulta e pode pedir exames e receitar medicamentos, após a consulta o paciente pode solicitar o retorno. Ao finalizar o atendimento o médico seleciona o próximo paciente da lista dos presentes. Descrever o caso de uso para a Consulta do paciente

38 Diagrama de caso de uso Exercício
Monte um caso de uso para uma oficina mecânica, segue os dados: O cliente, conta todos os problemas pertinentes com o veículo. O atendente adiciona cada item que o cliente está solicitando para fazer a Ordem de Serviço. O mecânico vai imprimir os problemas que o cliente reclamou e começa a verificar o veículo.

39 Diagrama de caso de uso Exercício (Cont)
Após as constatações efetuadas o mecânico entra com as informações sobre o serviço a ser executado. O atendente verifica quais orçamentos podem ser passados para o cliente. O cliente pode solicitar que nada seja feito ou efetuar o concerto total ou parcial . O atendente passa um prazo para o cliente buscar seu veículo. Ao chegar a oficina o cliente vai efetuar o pagamento no caixa, para liberar seu veículo.

40 Diagrama de caso de uso Exercício

41 Diagrama de caso de uso Exercício

42 Diagrama de Classe O diagrama de classe é o diagrama mais utilizado na UML. Se objetivo é permitir a visualização das classes utilizadas pelo sistema e como estas se relacionam. Esse diagrama apresenta uma visão estática de como suas classes estão organizadas, preocupando-se em definir sua estrutura lógica.

43 Diagrama de Classe Um diagrama de classe pode ser utilizado para modelar o modelo lógico de um banco de dados, quando se assemelha aos antigos Modelos- Entidade-Relacionamento. Na verdade o diagrama de classe foi propositalmente projetado para ser uma evolução do MER.

44 Diagrama de Classe No entanto deve ficar bem claro que o diagrama de classe não é utilizado unicamente para a modelagem de modelos lógicos e banco de dados e mais importante, que uma classe não corresponde a uma tabela.

45 Diagrama de Classe Relacionamentos ou Associações
As classes costumam possuir relacionamentos entre si, chamados associações que as permitem compartilhar informações e colaborarem para a execução dos processos executados pelo sistema. Uma associação descreve um vínculo que ocorre normalmente entre os objetos de uma ou mais classes.

46 Diagrama de Classe Exemplo
Nome da classe Atributos Métodos

47 Diagrama de Classe Relacionamentos ou Associações
As associações são representadas por retas ligando as classes envolvidas, podendo também possuir setas em suas extremidades para indicar a navegabilidade da associação, o que representa o sentido em que as informações são transmitidas entre os objetos das classes envolvidas.

48 Diagrama de Classe Associação Unária
Este tipo de associação ocorre quando existe um relacionamento de um objeto de uma classe com objetos da mesma classe.

49 Diagrama de Classe Associação Binária
Associações binárias ocorrem quando são identificados relacionamentos entre objetos de duas classes.

50 Diagrama de Classe Associação Ternária ou N-ária
Associações ternárias ou N-árias são associações que conectam objetos de mais de duas classes. São representadas por um losângulo para onde convergem todas as ligações da associação.

51 Diagrama de Classe Agregação
Agregação é um tipo especial de associação onde tenta-se demonstrar que as informações de um objeto precisam ser complementadas pelas informações contidas em um ou mais objetos de outra classe.

52 Diagrama de Classe Composição
Essa associação é uma variação da agregação, onde é apresentado um vínculo mais forte entre os objetos-todo e os objetos-parte, procurando demonstrar que os objetos-parte tem de estar associados a um único objeto-todo.

53 Diagrama de Classe Especialização / Generalização
Esta associação identifica classes-mãe, chamadas gerais e classes-filhas, chamadas especializadas, demonstrando a ocorrência de herança e possivelmente de métodos polimórficos nas classes especializadas.

54 Diagrama de Classe Dependência
Este relacionamento, como o próprio nome diz identifica um certo grau de dependência de uma classe em relação à outra. O relacionamento de dependência é representado por uma reta tracejada entre duas classes contendo uma seta apontando a classe da qual a classe posicionada na outra extremidade do relacionamento dependente.

55 Diagrama de Classe Dependência Exemplo

56 Diagrama de Classe Classe associativa
Classes associativas são produzidas quando ocorrem associações que possuem multiplicidade de muitos para muitos. As classes associativas são necessárias nesses casos porque não existe um repositório que possa armazenar as informações produzidas pelas associações já que todos os objetos envolvidos apresentam multiplicidade muitos e isto obriga que seu atributo-chave seja transmitido aos outros objetos e como todos possuem a mesma multiplicidade, nenhum deles pode receber os atributos dos outros, assim é preciso criar uma classe associativa para armazenar os atributos transmitidos pela associação, o que não impede que a classe associativa possua atributos próprios.

57 Diagrama de Classe Classe associativa Exemplo

58 Diagrama de Classe Exercícios
Continue o diagrama de caso de uso feito anteriormente.

59 Diagrama de caso de uso e de Classe Exercícios
Monte os diagramas para um sistema de e-commerce Montar todos os casos de uso e o diagrama de classe. O cliente vai escolher os produtos que deseja comprar, e vai listando no carrinho de compra. Após efetuar a compra o cliente pode tanto efetuar seu cadastro ou utilizar o cadastramento feito em alguma compra anterior. O sistema terá de retirar os produtos do estoque. O cliente escolhe a forma de pagamento. O cliente pode consultar o pedido posteriormente.

60 Diagrama de Objetos O diagrama de objetos tem como objetivo fornecer uma “visão” dos valores armazenados pelos objetos das classes definidas no diagrama de classes em um determinado processo do sistema. Assim, embora o diagrama de classes seja estático, pode-se criar diagrama de objetos, onde as possíveis situações pelas quais os objetos das classes passarão possam ser simuladas. Não possui esse diagrama no astah.

61 Diagrama de Componentes
Como seu próprio nome diz, identifica os componentes que fazem parte de um sistema, um subsistema ou mesmo os componentes ou classes internas de um componente individual. Um componente pode representar tanto um componente lógico (um componente de negócio ou de processo) ou um componente físico, como arquivos contendo código fonte, arquivos de ajuda, bibliotecas, etc.

62 Diagrama de estruturas compostas
Ele é utilizado para modelar colaborações. Uma colaboração descreve uma visão de um conjunto de entidades cooperativas interpretadas por instâncias que cooperam entre si para executar uma função específica. Ele tenta expressar arquiteturas de tempo de execução, padrões de uso e os relacionamentos dos elementos participantes, o que nem sempre pode ser representado por diagramas estáticos (diagrama de classe).

63 Diagrama de seqüências
Este diagrama procura determinar a seqüência de eventos que ocorrem em um determinado processo, identificando quais métodos devem ser disparados entre os atores e objetos envolvidos e em ordem. O diagrama de seqüência baseia-se no diagrama de caso de uso, havendo normalmente um diagrama de seqüência para cada caso de uso, uma vez que um caso de uso, em geral refere-se a um processo disparado por um ator. Assim um diagrama de seqüência também permite documentar um caso de uso.

64 Diagrama de seqüências
O diagrama de seqüência depende também do diagrama de classes, já que as classes dos objetos declarados no diagrama estão descritas nele, bem como os métodos disparados entre os objetos. No entanto, o diagrama de seqüência é uma excelente forma de validar o diagrama de classes, pois ao modelá-lo muitas vezes percebem-se falhas e a necessidade de declarar novos métodos que não haviam sido imaginados antes.

65 Diagrama de comunicações
Ele está amplamente associado ao diagrama de seqüência, na verdade um complementa o outro. As informações mostradas no diagrama de comunicação são, com freqüência, praticamente as mesmas apresentadas no diagrama de seqüência, porém com enfoque diferente, visto que este diagrama não se preocupa com a temporidade do processo, concentrando-se em como os objetos estão vinculados e quais mensagens trocam entre si durante o processo.

66 Diagrama de gráficos de estados
Este diagrama demonstra o comportamento de um elemento através de um conjunto de transições de estado. O elemento modelado muitas vezes é uma instância de uma classe, no entanto, pode-se usar este diagrama para modelar o comportamento de um caso de uso ou mesmo o comportamento de um sistema completo, neste caso estaremos considerando o caso de uso ou o sistema como objetos.

67 Diagrama de atividades
É o diagrama com maior ênfase ao nível de algoritmo da UML e provavelmente um dos mais detalhistas. Este diagrama apresenta muitas semelhanças com os antigos fluxogramas utilizados para desenvolver a lógica de programação e determinar o fluxo de controle de um algoritmo, sendo inclusive comum encontrar-se diagramas de atividade utilizando uma linguagem de programação real.

68 Diagrama de atividades
Este diagrama é utilizado, como o próprio nome diz, para modelar atividades, que podem ser um método ou um algoritmo, ou mesmo um processo completo. Atividades podem descrever computação procedural, neste contexto elas são os métodos correspondentes às operações sobre classes. Uma atividade é composta por um conjunto de ações, ou seja, os passos necessários para que uma atividade seja concluída.

69 Diagrama de atividades
Uma atividade sempre conterá ações, no entanto, não necessariamente estas estarão representadas dentro da atividade, como quando for necessário fazer referência a uma atividade já modelada ou para poupar espaço no diagrama. Além disso, o diagrama de atividades pode ser usado para representar dois tipos de fluxo: de controle e de objetos.

70 Diagrama de implantação
É o diagrama com a visão mais física da UML. Este diagrama enfoca a questão da organização da arquitetura física sobre a qual o software irá ser implantado e executado em termos de hardware, ou seja, as máquinas (computadores pessoais, servidores, etc) que suportarão o sistema, além de definir como estas máquinas estarão conectadas e através de quais protocolos se comunicarão e transmitirão informações.

71 Diagrama de pacote O diagrama de pacotes tem por objetivo representar os subsistemas ou sub-módulos englobados por um sistema de forma a determinar as partes que o compõem. Demonstra como os elementos estão organizados nos pacotes e as dependências que existem entre os elementos e os próprios pacotes. Pode ser utilizado de maneira independente ou associado com outros diagramas. Este diagrama pode ser utilizado também para auxiliar a demonstrar a arquitetura de uma linguagem, como ocorre com a própria UML.

72 Diagrama de temporização
Este diagrama apresenta algumas semelhanças com o diagrama de gráficos e estado, no entanto, ele enfoca as mudanças de estado de um objeto ao longo do tempo. Este diagrama terá pouca utilidade para modelar aplicações comerciais, contudo poderá ser utilizado na modelagem de sistemas em tempo real ou sistemas que utilizem recursos de multimídia, onde o tempo em que um objeto executa algo é muitas vezes importante.

73 Diagrama de visão geral de interação
Este diagrama é uma variação do diagrama de atividade. Seu objetivo é fornecer uma visão geral do controle do fluxo.

74 Conhecendo os diagramas
Vamos conhecer o diagrama de caso de uso, abra o jude.

75 Exercícios Faça um diagrama de caso de uso com todo o processo de movimentação do cartão de crédito. Desde a aprovação até o uso.


Carregar ppt "Análise e Projetos de Sistemas Orientados a Objetos"

Apresentações semelhantes


Anúncios Google