1 / 31

Metodos de Especificação de Software 2ª Parte (UML)

Metodos de Especificação de Software 2ª Parte (UML). Patrícia Macedo Joaquim Filipe João Ascenso Engenharia de Software 2005/2006 EST, Setúbal. Indice Geral. 1ª Parte Especificação de Software DFD’s Maquinas de estados Petri Nets 2ª Parte UML 3ª Parte Exemplos. Introdução

remy
Download Presentation

Metodos de Especificação de Software 2ª Parte (UML)

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. Metodos de Especificação de Software2ª Parte (UML) Patrícia Macedo Joaquim Filipe João Ascenso Engenharia de Software 2005/2006 EST, Setúbal

  2. Indice Geral 1ª Parte • Especificação de Software • DFD’s • Maquinas de estados • Petri Nets 2ª Parte • UML 3ª Parte • Exemplos Engenharia de Software

  3. Introdução O que é a UML? Valor da UML Origens da UML Parceiros da UML Modelos e diagramas Elementos de modelação Diagramas Diagrama de casos de utilização Diagrama de classes Diagrama de objectos Diagrama de componentes Diagrama de distribuição Diagrama de sequência Diagrama de colaboração Diagrama de estados Diagrama de actividades Índice Engenharia de Software

  4. O que é a UML? • UML = Unified Modeling Language • UML é uma linguagem (notação com semântica associada) para • visualizar • especificar • construir • documentar os artefactos de um sistema com uma componente intensiva de software (software intensive system) • UML não é uma metodologia • não diz quem deve fazer o quê, quando e como • UML pode ser usado segundo diferentes metodologias, tais como RUP (Rational Unified Process), FDD (Feature Driven Development), etc. • UML não é uma linguagem de programação Engenharia de Software

  5. Valor da UML • É um standard aberto • versão 1.1 aprovada pelo OMG (Object Management Group) em Novembro de 1997 • versão 1.3 aprovada em Junho de 1999 • Suporta todo o ciclo de vida do software • modelação do negócio (processos e objectos do negócio) • modelação de requisitos alocados ao software • modelação da solução de software • Suporta diversas áreas de aplicação • É baseado na experiência e necessidades da comunidade de utilizadores • É suportado por muitas ferramentas Engenharia de Software

  6. HP Fusion Meyer Booch Operation descriptions and message numbering Before and after conditions Booch method Rumbaugh Embley Harel OMT Singleton classes and high-level view Statecharts Gamma, et al Wirfs-Brock Frameworks and patterns, Responsibilities Odell Shlaer - Mellor Jacobson Classification Object lifecycles OOSE Origens da UML Engenharia de Software

  7. Rational Software Corporation Hewlett-Packard I-Logix IBM ICON Computing Intellicorp MCI Systemhouse Microsoft ObjecTime Oracle Platinum Technology Taskon Texas Instruments/Sterling Software Unisys Parceiros da UML Engenharia de Software

  8. Modelos • Um modelo é uma representação em pequena escala, numa perspectiva particular, de um sistema existente ou a criar • Atitude de abstracção (omissão de detalhes) fundamental na construção de um modelo • Modelos são a linguagem por excelência do projectista (designer) • Modelos são veículos para comunicação com vários interessados (stakeholders) • Modelos permitem raciocinar acerca do sistema real, sem o chegar a construir • Ao longo do ciclo de vida de um sistema são construídos vários modelos, sucessivamente refinados e enriquecidos Engenharia de Software

  9. Diagramas • Um modelo é constituído por um conjunto de diagramas (desenhos) consistentes entre si, acompanhados de descrições textuais dos elementos que aparecem nos vários diagramas • Um diagrama é uma vista sobre um modelo • O mesmo elemento (exemplo: classe) pode aparecer em vários diagramas de um modelo • No UML, há nove diagramas standard • Diagramas de visão estática: casos de utilização (use case), classes, objectos, componentes, distribuição (deployment) • Diagramas de visão dinâmica: sequência, colaboração, estados (statechart), actividades Engenharia de Software

  10. State Diagrams State Diagrams State Diagrams State Diagrams State Diagrams State Diagrams Diagramas de Objectos Diagramas de Classes Diagramas de Componentes Component Diagrams Component Diagrams Diagramas de Distribuição Use Case Diagrams Use Case Diagrams Scenario Diagrams Scenario Diagrams Use Case Diagrams Use Case Diagrams Scenario Diagrams Scenario Diagrams Diagramas de Casos de Utilização Diagramas de Sequência Diagramas de Estados Diagramas de Colaboração Modelos e Diagramas Modelos Diagramas de Actividades Engenharia de Software

  11. Elementos de Modelação (1) • Elementos estruturais • classe, interface, colaboração, caso de utilização, classe activa, componente, nó Fonte: Grady Booch • Elementos de comportamento • interacção, máquina de estados • Elementos de agrupamento • pacote (package), subsistema • Outros elementos • nota Engenharia de Software

  12. Elementos de Modelação (2) • Relações • Dependência • Associação • Generalização • Concretização (realization) • Mecanismos de extensibilidade • Estereótipos • Propriedades (tagged values) • Restrições (constraints) Fonte: Grady Booch Fonte: Grady Booch Engenharia de Software

  13. Diagrama de Casos de Utilização (Use Case Diagram) • Captura a funcionalidade do sistema tal como é visto pelos utilizadores • Construído nos primeiros estágios do desenvolvimento • Objectivo • Especificar o contexto de um sistema • Capturar os requisitos funcionais de um sistema • Validar a arquitectura de um sistema • Dirigir a implementação e gerar casos de teste • Desenvolvido por analistas e especialistas de domínio Engenharia de Software

  14. Diagrama de Casos de Utilização(Use Case Diagram) Fonte: Grady Booch Engenharia de Software

  15. Diagrama de Classes • Captura o vocabulário de um sistema • Construído e refinado ao longo do desenvolvimento • Objectivo • Nomear e modelar conceitos no sistema • Especificar colaborações • Especificar esquemas lógicos de bases de dados • Desenvolvido por analistas, designers e implementadores Engenharia de Software

  16. Diagrama de Classes composition Fonte: Grady Booch Engenharia de Software

  17. Diagrama de Objectos • Mostra objectos (instâncias de classes) e ligações (instâncias de associações) • Construído durante a análise e design • Objectivo • Ilustrar estruturas de dados/objectos • Especificar instantâneos (snapshots) • Desenvolvido por analistas, designers e implementadores Engenharia de Software

  18. Diagrama de Objectos Fonte: Grady Booch Engenharia de Software

  19. Diagrama de Componentes • Captura a estrutura física da implementação (tipicamente ficheiros) • Construído como parte da especificação da arquitectura • Objectivo • Organizar o código fonte • Construir uma release executável • Especificar uma base de dados física • Desenvolvido por arquitectos e programadores Engenharia de Software

  20. Diagrama de Componentes Fonte: Grady Booch Engenharia de Software

  21. Diagrama de Distribuição (Deployment Diagram) • Captura a topologia do hardware de um sistema • Construído como parte da especificação da arquitectura • Objectivo • Especificar a distribuição de componentes • Identificar estrangulamentos de desempenho • Desenvolvido por arquitectos, engenheiros de redes, e engenheiros de sistemas Engenharia de Software

  22. Diagrama de Distribuição (Deployment Diagram) Fonte: Grady Booch Engenharia de Software

  23. Diagrama de Sequência • Captura comportamento dinâmico (orientado ao tempo) • Objectivo • Modelar fluxos de controlo • Ilustrar cenários típicos Engenharia de Software

  24. Diagrama de Sequência Fonte: Grady Booch Engenharia de Software

  25. Diagrama de Colaboração • Captura comportamento dinâmico (orientado a mensagens) • Objectivo • Modelar fluxo de controlo • Ilustrar a coordenação entre estrutura de objectos e controlo Engenharia de Software

  26. Diagrama de Colaboração Fonte: Grady Booch Engenharia de Software

  27. Diagrama de Estados (Statechart Diagram) • Captura comportamento dinâmico (orientado a eventos) • Objectivo • Modelar ciclo de vida de objectos • Modelar objectos reactivos (interfaces com o utilizador, dispositivos, etc.) Engenharia de Software

  28. Diagrama de Estados (Statechart Diagram) Fonte: Grady Booch Engenharia de Software

  29. Diagrama de Actividades • Captura comportamento dinâmico (orientado a actividades) • Objectivo • Modelar processos de negócio e workflows • Modelar operações (algoritmos) Engenharia de Software

  30. Diagrama de Actividades Fonte: Grady Booch Engenharia de Software

  31. Referências • Ferramentas de modelação visual • Rational Rose (www.rational.com) • Together (www.togethersoft.com) – disponível nos computadores da FEUP • Platinum Paradigm Plus (www.platinum.com) • Microsoft Visio – disponível no DEEC ao abrigo de protocolo com Microsoft • Livros • The Unified Modeling Language User Guide, Grady Booch et al, Addison-Wesley, October, 1998 • UML, Metodologias e Ferramentas CASE, Alberto SIlva e Carlos Videira, Centro Atlântico, 2001 • Especificações • www.omg.org Engenharia de Software

More Related