1 / 65

Princ pios da Orienta o a Objetos Linguagem de Modelagem Unificada U M L

U M L. A Unified Modeling Language (UML) ? uma linguagem de modelagem n?o propriet?ria de terceira gera??o. A UML n?o ? uma metodologia de desenvolvimento, n?o mostrando como projetar seu sistema, e sim auxiliando a visualiza??o de seu desenho e a comunica??o entre objetos.? uma nota??o independen

todd
Download Presentation

Princ pios da Orienta o a Objetos Linguagem de Modelagem Unificada U M L

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


    1. Princípios da Orientação a Objetos Linguagem de Modelagem Unificada U M L

    2. U M L A Unified Modeling Language (UML) é uma linguagem de modelagem não proprietária de terceira geração. A UML não é uma metodologia de desenvolvimento, não mostrando como projetar seu sistema, e sim auxiliando a visualização de seu desenho e a comunicação entre objetos. É uma notação independente de processos, embora o RUP (Rational Unified Process) tenha sido especificamente desenvolvido utilizando a UML.

    3. Histórico Os esforços para a criação da UML tiveram início em outubro de 1994, quando Rumbaugh se juntou a Booch na Rational. Com o objetivo de unificar os métodos Booch e OMT, decorrido um ano de trabalho, foi lançado, em outubro de 1995, o esboço da versão 0.8 do Unified Process - Processo Unificado (como era conhecido). Nesta mesma época, Jacobson se associou à Rational e o escopo do projeto da UML foi expandido para incorporar o método OOSE. Nasceu então, em junho de 1996, a versão 0.9 da UML.

    4. Evolução da UML

    5. Visões Arquiteturais

    8. Modelagem Estática ou Estrutural Diagramas estáticos ou estruturais definem estaticamente a arquitetura de um modelo. São usados para modelar classes, objetos, relações e componentes físicos que compõem um modelo. Além disso, também são usados modelar os relacionamentos e as dependências entre elementos.

    9. Diagrama de pacotes O Diagrama de pacotes ou diagrama de módulos descreve os pacotes ou pedaços do sistema divididos em agrupamentos lógicos, mostrando as interações entre eles em alto nível (já que pacotes podem depender de outros pacotes). Esse diagrama é muito utilizado para ilustrar a arquitetura de um sistema mostrando o agrupamento de suas classes.

    11. Diagrama de classes Define os elementos básicos de um modelo, ou seja, os tipos, as classes e os relacionamentos usados para construir um modelo completo. Em programação, um diagrama de classes é uma representação da estrutura e relações das classes que servem de modelo para objetos. É uma modelagem muito útil para o sistema, definindo todas as classes que o sistema necessita possuir e é a base para a construção dos diagramas de comunicação, seqüência e estados.

    12. Diagrama de objetos É uma variação do diagrama de classes e utiliza quase a mesma notação, com duas exceções: os objetos são escritos com seus nomes sublinhados e todas as instâncias num relacionamento são mostradas. A diferença é que o diagrama de objetos apresenta os atributos com valores e mostra os objetos que foram instanciados das classes. É como se fosse o perfil do sistema em um certo momento de sua execução. Os diagramas de objetos não são tão importantes como os diagramas de classes, mas eles são muito úteis para exemplificar diagramas complexos de classes ajudando muito em sua compreensão. Também são usados como parte dos diagramas de colaboração, onde a colaboração dinâmica entre os objetos do sistema é mostrada.

    14. Diagrama de estrutura composta Definido a partir da UML 2.0 e do RUP. Destina-se à descrição dos relacionamentos entre os elementos, ou seja, a colaboração interna de classes, interfaces ou componentes para especificar uma funcionalidade. Fornece meios de definir a estrutura de um elemento e de focalizá-la no detalhe, na construção e em relacionamentos internos, mostrando a estrutura interna (incluindo partes e conectores) de um classificador estruturado ou colaboração.

    16. Diagrama de componentes Ilustra como as classes deverão se encontrar, organizadas através da noção de componentes de trabalho, ou seja, apresenta as dependências ente componentes de software, incluindo implementação de classes, arquivos de código fonte, arquivo de código binário, arquivos executáveis, scripts. Utilizado para: * Modelar os componentes do código-fonte, do código executável do software; * Destacar a função de cada módulo para facilitar a sua reutilização; * Auxiliar no processo de engenharia reversa, por meio da organização dos módulos do sistema e seus relacionamentos. Componente: Peça física distribuível e substituível de código que contém elementos que apresentam um conjunto de interfaces requeridas e fornecidas.

    18. Diagrama de componentes – exemplo uml 2.0

    19. Diagrama de instalação ou execução Mostra a configuração dos elementos de processamento em tempo de execução, além dos componentes, processos e objetos do sistema neles existentes, sendo usado para modelar a arquitetura de um sistema de informação da perspectiva dos seus componentes físicos/hardware (computadores, adaptadores de rede, impressoras, routers etc), explicitando as suas dependências de comunicação, assim como, que componentes são instaladas em cada nó computacional, ilustrando a configuração dos elementos de processamento e dos componentes de software, processos e objetos neles suportados. Modela também sistemas cliente-servidor e sistemas distribuídos.

    21. Modelagem dinâmica (de comportamento) Os diagramas dinâmicos ou de comportamento apresentam as variedades da interação e do estado instantâneo dentro de um modelo enquanto é “executado”.

    22. Diagrama de casos de uso Descreve a funcionalidade proposta para o novo sistema, sendo usado para modelar interações do usuário/sistema. Define o comportamento, as exigências e o resultado esperado de uma funcionalidade. Segundo Ivar Jacobson, idealizador do modelo, pode-se dizer que um Caso de Uso é um "documento narrativo que descreve a seqüência de eventos de um ator que usa um sistema para completar um processo". Um Caso de Uso pode "usar" outra funcionalidade de Caso de Uso ou "estender" outro Caso de Uso com seu próprio comportamento.

    24. Diagrama de máquina de estados Em engenharia de software e eletrônica digital, um diagrama de transição de estados é uma representação do estado ou situação em que um objeto pode se encontrar no decorrer da execução de processos de um sistema. Com isso, o objeto pode passar de um estado A (estado inicial) para um estado B (estado final) através de uma transição. Representa as ações ocorridas em reposta ao recebimento de um evento, onde cada ponto de parada representa um estado da aplicação.

    26. Diagrama de atividades É uma variação do diagrama de máquina de estados que representa a execução das ações e as transições que são acionadas pela conclusão de outras ações ou atividades, ou seja, um gráfico de fluxo, mostrando o fluxo de controle de uma atividade para outra. Comumente, isso envolve a modelagem das etapas seqüenciais em um processo computacional. Os diagramas de atividade não são importantes somente para a modelagem de aspectos dinâmicos de um sistema ou um fluxograma, mas também para a construção de sistemas executáveis por meio de engenharia de produção reversa.

    28. Diagrama de colaboração ou comunicação Mostra, de maneira semelhante ao diagrama de seqüência, a colaboração dinâmica entre os objetos, ou seja, exibe uma interação, consistindo de um conjunto de objetos e seus relacionamentos, incluindo as mensagens que podem ser trocadas entre eles. Se a ênfase do diagrama for o decorrer do tempo, o ideal é o diagrama de seqüência, mas se a ênfase for o contexto do sistema, a prioridade será o diagrama de colaboração que dá ênfase à ordenação estrutural em que as mensagens são trocadas entre os objetos de um sistema.

    30. Diagrama de seqüência de mensagens Representa a seqüência de processos (mais especificamente de mensagens passadas entre objetos) num programa de computador. É usado para representar o comportamento das operações, métodos (procedimentos ou funções) entre classes de um cenário. Ele registra o comportamento de um único caso de uso (interações entre objetos de um cenário, realizadas através de operações ou métodos (procedimentos ou funções)). Exibe os objetos e as mensagens passadas entre esses objetos no caso de uso, descrevendo a maneira como os grupos de objetos colaboram em algum comportamento ao longo do tempo. O diagrama de seqüência dá ênfase à ordenação temporal em que as mensagens são trocadas entre os objetos de um sistema. Entende-se por mensagens os serviços solicitados de um objeto a outro, e as respostas desenvolvidas para as solicitações.

    32. Diagrama de tempo ou temporal O Diagrama de tempo (Timing Diagram), incluído a partir da UML 2.0, apresenta o comportamento dos objetos e sua interação em uma escala de tempo, focalizando as condições que mudam no decorrer desse período. Modo alternativo de mostrar um diagrama de seqüência, ou melhor, a fusão dos diagramas de seqüência e de estado, apresentando o estado dos objetos em relação ao tempo e as mensagens que modificam esse estado, usando para isso métrica de tempo na linha de vida. Pode ser útil em aplicações de tempo real.

    33. Diagrama de tempo (exemplo)

    34. Diagrama de interatividade Diagramas de interatividade são variações de "Diagrama de atividades", ou melhor, a fusão do diagrama de atividades e seqüência. Ele permite que fragmentos das interações sejam facilmente combinados aos pontos e fluxos de decisão. Nele, seqüências formam um fluxo de atividades, mostrando como elas trabalham em uma seqüência de eventos.

    35. Diagrama de visão geral de interação Uma variação do diagrama de atividade que incorpora fragmentos de diagrama de seqüencia junto com construções de fluxo de controle.

    36. Comparação entre os diagramas da 1ª e 2ª versões

More Related