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

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

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

Apresentações semelhantes


Apresentação em tema: "1 Análise e Projetos de Sistemas Orientados a Objetos Prof. André Argeri Ribeirão Preto, Fevereiro 2010."— Transcrição da apresentação:

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

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

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

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

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

6 6 Características da UML Requisitos. Requisitos. Comportamento. Comportamento. Estrutura lógica. Estrutura lógica. Dinâmica de seus processos. Dinâmica de seus processos. Até necessidades físicas em relação ao equipamento sobre o qual o sistema deverá ser implantado. 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 7 Histórico da UML União de três metodologias: 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 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. 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. Em 96 foi lançada a primeira versão da UML.

9 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. 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 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; 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; 2º - Cada modelo poderá ser expresso em diferentes níveis de precisão;

11 11 Princípios da modelagem 3º - Os melhores modelos estão relacionados à realidade; 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. 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 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. 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 13 UML é uma Linguagem para documentação RequisitosArquiteturaProjeto Código fonte Planos de projetos TestesPrototipos

14 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. 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 15 Exemplos de Ferramentas Rational Rose Rational Rose Enterprise Architect Enterprise Architect Visual Paradigm for UML ou VP-UML Visual Paradigm for UML ou VP-UML Poseidon for UML Poseidon for UML ArgoUML ArgoUML Jude Jude Entre outros. Entre outros.

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

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

18 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. 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 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. 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 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 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 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. 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 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. 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 23 Diagrama de caso de uso Casos de Uso. Nome do caso de uso Nome do caso de uso Objetivo Objetivo Atores Atores Passos Passos

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

25 25 Diagrama de caso de uso Casos de Uso. Restrições 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.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. 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. 3.1 – O ator não seleciona o período, o sistema solicita o preenchimento do mesmo.

26 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. 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 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). 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 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. 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 29 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. 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. Diagrama de caso de uso Especialização / Generalização

30 30 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. 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. Diagrama de caso de uso Inclusão (include)

31 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. 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 32 Diagrama de caso de uso Inclusão (include) Exemplo Exemplo

33 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. 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 34 Diagrama de caso de uso Extensão (extend) Exemplo Exemplo

35 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. 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 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á. 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 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 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 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. 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. 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 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: 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 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 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. O mecânico vai imprimir os problemas que o cliente reclamou e começa a verificar o veículo. 38

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. 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 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 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. 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. Ao chegar a oficina o cliente vai efetuar o pagamento no caixa, para liberar seu veículo. 39

40 Diagrama de caso de uso Exercício 40

41 Diagrama de caso de uso Exercício 41

42 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. 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 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. 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 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. 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 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. 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 46 Diagrama de Classe Exemplo Nome da classe Atributos Métodos

47 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. 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 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. Este tipo de associação ocorre quando existe um relacionamento de um objeto de uma classe com objetos da mesma classe.

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

50 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. 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 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. 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 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. 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 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. 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 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. 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 55 Diagrama de Classe Dependência Exemplo

56 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. 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 57 Diagrama de Classe Classe associativa Exemplo

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

59 59 Diagrama de caso de uso e de Classe Exercícios Monte os diagramas para um sistema de e- commerce Monte os diagramas para um sistema de e- commerce Montar todos os casos de uso e o diagrama de classe. 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. 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. 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 sistema terá de retirar os produtos do estoque. O cliente escolhe a forma de pagamento. O cliente escolhe a forma de pagamento. O cliente pode consultar o pedido posteriormente. O cliente pode consultar o pedido posteriormente.

60 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. 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. Não possui esse diagrama no astah.

61 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. 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 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 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. 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 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. 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 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. 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 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. 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 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. É 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 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. 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 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. 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 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. É 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 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. 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 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. 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 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. Este diagrama é uma variação do diagrama de atividade. Seu objetivo é fornecer uma visão geral do controle do fluxo.

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

75 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. 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 "1 Análise e Projetos de Sistemas Orientados a Objetos Prof. André Argeri Ribeirão Preto, Fevereiro 2010."

Apresentações semelhantes


Anúncios Google