Linguagem de Modelagem Unificada
• A UML é uma linguagem para– visualização– especificação– construção– documentação
• de artefatos de um sistema com uma componenteintensiva 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 DrivenDevelopment), etc.
• UML não é uma linguagem de programaçãoEstes slides estão baseados em material disponível na internet pela Rational Software.Foi utilizada tradução de João Pascoal Faria, Univ. do Porto
Histórico UML
Booch method OMT
Unified Method 0.8OOPSLA ´95
OOSEOther methods
UML 0.9Web - June ´96
publicfeedback
Final submission to OMG, Sep ‘97
First submission to OMG, Jan ´97
UML 1.1OMG Acceptance, Nov 1997
UML 1.3, 1.4, 1.5
UML 1.0UML partners
UML 2.0, 2.1
Minor revisions – 1.3, 1.4, 1.5
Major revision – UML 2.0, 2003
Minor revisions – UML 2.1, 2007
Meyer
Before and after conditions
Harel
StatechartsGamma, et al
Frameworks and patterns,
HP Fusion
Operation descriptions and message numbering
Embley
Singleton classes andhigh-level view
Wirfs-Brock
Responsibilities
Odell
Classification
Shlaer - Mellor
Object lifecycles
Rumbaugh
OMT
Booch
Booch method
Jacobson
OOSE
Unificação de métodos e formalismos
Vantagens da UML
• É um padrão aberto– versão 1.1 aprovada pelo OMG (Object Management Group)
em Novembro de 1997
• Suporta todo o ciclo de vida do software– modelagem do negócio (processos e objetos do negócio)– modelagem de requisitos alocados ao software– modelagem da solução de software
• Suporta diversas áreas de aplicação• É baseada na experiência e necessidades da
comunidade de usuários• É suportada por muitas ferramentas
Parceiros UML
• Rational Software Corporation• Hewlett-Packard• I-Logix• IBM• ICON Computing• Intellicorp• MCI Systemhouse• Microsoft• ObjecTime• Oracle• Platinum Technology• Taskon• Texas Instruments/Sterling Software• Unisys
Modelos, Diagramas e Visões (1.x)
Use CaseDiagramsUse Case
DiagramsDiagramas de Casos de Uso
ScenarioDiagramsScenario
DiagramsDiagramas deColaboração
StateDiagramsState
DiagramsDiagramas de Componentes
ComponentDiagramsComponent
DiagramsDiagramas de Implantação
StateDiagramsState
DiagramsDiagramasde Objetos
ScenarioDiagramsScenario
DiagramsDiagramas deEstados
Use CaseDiagramsUse Case
DiagramsDiagramas deSequência
StateDiagramsState
DiagramsDiagramas deClasses
Diagramas deAtividades
Modelos
Um modelo éuma descriçãocompleta de umsistema a partirde umaperspectivaparticular.
Exemplo básico – Hello World!
import java.awt.Graphics;class HelloWorld extends java.applet.Applet{ public void paint (Graphics g) { g.drawString("Hello, World!", 10, 10); }}
Modelos, Diagramas, Visões eElementos (1)• Um modelo é uma representação em pequenaescala, numa perspectiva particular, de umsistema existente ou a criar
• Ao longo do ciclo de vida de um sistema sãoconstruídos vários modelos, sucessivamenterefinados e enriquecidos
• Um modelo é constituído por um conjunto dediagramas (desenhos) consistentes entre si,acompanhados de descrições textuais doselementos que aparecem nos vários diagramas
Modelos, Diagramas, Visões eElementos (2)• Um diagrama é uma visão sobre um modelo
– De acordo com o interesse de uma das partes envolvidas(stakeholder)
– Proporciona uma representação parcial do sistema– Deve ser semanticamente consistente com outras visões
• Na UML 1.5, há 9 diagramas padrões e 3 deorganização– Diagramas de visão estática: casos de uso (use case),
classes, objetos, componentes, implantação (deployment)– Diagramas de visão dinâmica: sequência, colaboração,
estados (statechart), actividades– Diagramas de organização: pacotes, subsistemas e
modelos• O mesmo elemento (exemplo: classe) pode aparecer
em vários diagramas de um modelo
Diferentes Visões
Organização Comportamento
Visão deDesign
Visão de implementação
Visão deProcesso
Components Classes, interfaces,collaborations
Active classes
Visão de implantação
Nodes
Use Case View
Use cases
Diagramas na UML 2.x
DiagramaUML
DiagramaEstrutural
DiagramaComportamental
Diagrama de Classe
Diagrama de Componentes
Diagrama de Objetos
Diagrama de Estruturas
Compostas
Diagrama de Implantação
Diagrama de Pacotes
Diagrama de Atividades
Diagrama de Casos de Uso
Diagrama de Máquinasde Estados
Diagrama de Interação
Diagrama de Seqüência Diagrama de
Visão Geral de InteraçãoDiagrama de
ComunicaçãoDiagrama de Temporização
Elementos de Modelagem (1)
• Elementosestruturais– classe, interface,
colaboração, casode uso, classeativa, componente,nó
• Elementos decomportamento– interação, máquina
de estados• Elementos de
agrupamento– pacote (package),
subsistema• Outros elementos
– nota
Fonte: Grady Booch
Elementos de Modelagem (2)
• Relações– Dependência– Associação– Generalização– Realização (realization)
• Mecanismos de extensibilidade– Estereótipos– Propriedades (tagged values)– Restrições (constraints)
Fonte: Grady Booch
Fonte: Grady Booch
Diagrama de Casos de Uso (Use CaseDiagram)• Captura a funcionalidade do sistema tal como
é visto pelos utilizadores• Construído nos primeiros estágios do
desenvolvimento• Objetivo
– Especificar o contexto de um sistema– Capturar os requisitos funcionais de um sistema– Validar a arquitetura de um sistema– Dirigir a implementação e gerar casos de teste
• Desenvolvido por analistas e especialistas dedomínio
Diagrama de Casos de Uso(Use Case Diagram)
Fonte: Grady Booch
Diagrama de Classes
• Captura o vocabulário de umsistema
• Construído e refinado aolongo do desenvolvimento
• Objetivo– Nomear e modelar
conceitos do domínio– Especificar esquemas
lógicos de bases de dados– Especificar programas OO
• Desenvolvido por analistas,designers eimplementadores
Diagrama de Objetos
• Mostra objetos(instâncias de classes)e ligações (instânciasde associações)
• Construído durante aanálise e design
• Objetivo– Ilustrar estruturas de
dados/objetos– Especificar
instantâneos(snapshots)
• Desenvolvido poranalistas, designers eimplementadores
Diagrama de Componentes
• Captura a estrutura físicada implementação(tipicamente arquivos)
• Construído como parte daespecificação daarquitetura
• Objetivo– Organizar o código fonte– Construir uma release
executável– Especificar uma base de
dados física• Desenvolvido por
arquitetos eprogramadores
Diagrama de Implantação(Deployment Diagram)• Captura a topologia do
hardware de um sistema• Construído como parte da
especificação da arquitetura• Objetivo
– Especificar a distribuição decomponentes
– Identificar estrangulamentosde desempenho
• Desenvolvido por arquitetos,engenheiros de redes, eengenheiros de sistemas
Diagrama de Sequência
• Capturacomportamentodinâmico (orientadoao tempo)
• Objetivo– Modelar fluxos de
controle– Ilustrar cenários
típicos
Diagrama de Colaboração
• Captura comportamento dinâmico (orientado amensagens)
• Objetivo– Modelar fluxo de controle– Ilustrar a coordenação entre estrutura de objetos e controle
Diagrama de Estados(Statechart Diagram)• Captura comportamento dinâmico (orientado a
eventos)• Objetivo
– Modelar ciclo de vida de objetos– Modelar objetos reativos (interfaces com o utilizador,
dispositivos, etc.)
Diagrama de Actividades
• Capturacomportamentodinâmico (orientadoa atividades)
• Objetivo– Modelar processos
de negócio eworkflows
– Modelar operações(algoritmos)
Top Related