revisao uml
TRANSCRIPT
Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior
UML (Unified Modelling Language)
Referências: Booch, G. et al. The Unified Modeling Language User Guide Medeiros, E. Desenvolvendo Software com UML 2.0: Definitivo, Makron Books, 2006.
Sommerville, I. Engenharia de Software, 8ª edição, 2007.
Introdução � É uma linguagem para especificação,
construção, visualização e documentação de artefatos de um sistema de software
� É mantida pelo Object Management Group (OMG), com contribuições e direitos de autoria das seguintes empresas: Hewlett-Packard, IBM, ICON Computing, i-Logix, IntelliCorp, Electronic Data Services, Microsoft, ObjecTime, Oracle, Platinum,Ptech, Rational, Reich, Softeam, Sterling, Taskon A/S e Unisys.
2
Introdução
UML BOOCH OMT
OOSE
q Diagrama de Estados q Diagrama de Objetos (Colaboração) q Diagrama de Processo (Desenvolvimento) q Diagrama de Módulos (Componentes)
q Use Case q Subsistemas (Package) q Diagrama de Interações q MiniEspecificação
q Diagrama de Estados q Diagrama de Classes
3
A UML não é
� um processo � uma metodologia � Análise e Projeto OO � regras de projeto � Linguagem de Programação
4
Razões para Modelar � Comunicar a estrutura e o comportamento
desejado de um sistema. � Visualizar e controlar a arquitetura de um
sistema. � Para melhorar o nosso entendimento de um
sistema e, assim, expor oportunidades para melhorias e reutilização.
� Para administrar os riscos � A UML permite modelar:
� Elementos; � Relacionamentos; � Mecanismos de extensibilidade; � Diagramas
5
Diagrama § Os diagramas UML são abordados como
Estáticos e Dinâmicos.
Estes diagramas também Podem ser classificados como: Comportamentais Estruturais
6
Diagrama de Casos de Uso
Caso de Uso � Seqüência de ações, executada pelo
sistema, que gera um resultado � De valor observável � E para ator particular
� É uma seqüência completa de cenários de interação mostrando como eventos externos iniciais são respondidos no caso de uso.
Função
8
Cenário � Um cenário é uma narrativa de uma parte do
comportamento global do sistema e uma coleção completa de cenários é usada para especificar completamente um sistema
� Um caso de uso está para um cenário assim como uma classe está para um objeto. Ou seja, um caso de uso representa uma declaração de um aspecto de comportamento que é caracterizado por um lote de cenários concretos
9
Ator � Um ator é uma entidade externa ao
sistema que de alguma forma participa de um caso de uso, isto é, interage com o sistema
� Um ator estimula o sistema com eventos externos e tipicamente recebe algo do sistema.
� Um ator pode ser um ser humano, máquinas, dispositivos, ou outros sistemas. Atores típicos incluem, por exemplo, clientes, usuários, gerentes, computadores e impressoras.
Emissor/Receptor
10
Casos de Uso e Ator
Função Emissor
Função Receptor
Ator
Par
ticul
ar
Resu
ltado
de
Valo
r O
bser
váve
l
11
Diagrama Casos de Uso – Introdução
12
Casos de Uso e Ator
Função
Emissor
Passo 1 Passo 2 … Passo N
Descrição
13
Casos de Uso e Ator - Exemplo
Consultar saldo
Cliente
Transferir dinheiro
Sacar dinheiro
Valor de resultado
observável
Nome = Verbo + Substantivo (indicação de
ação)
14
Fluxo de Eventos � Parte mais importante de um caso de uso � Define a seqüência de ações entre o ator e o
sistema � É uma sequência de comandos declarativos
que descreve as etapas de execução de um Caso de Uso
� Contém informações relativas: � Às condições de início e término do caso de uso � Quais os atores interessados no sistema � Como o caso de uso interage com esses atores
15
Documentação de Caso de Uso
16
Nome do Caso de Uso Abertura de Conta
Tipo Primário, Expandido, Essencial
Atores Cliente
Resumo Este caso de uso descreve as etapas percorridas por um cliente para abrir uma conta corrente
Pré-Condições O pedido de abertura de conta corrente precisa ser aprovado
Pós-Condições É necessário realizar um depósito inicial
Fluxo Principal
Ações do Ator Ações do Sistema
1. Solicitar Abertura de Conta
2. Consultar cliente por seu CPF
3. ....
Fluxo Alternativo
Requisitos Especiais
Relacionamentos no Diagrama de Casos de Uso
� Relacionamento entre atores � Relacionamento entre atores e casos de uso
� Relacionamento entre casos de uso
17
Inclusão � Significa um caso de uso inclui (precisa de,
é composto de) outro. � Representado como uma dependência (seta
tracejada) que aponta para o caso de uso incluído
� “Se o caso de uso incluído muda, o caso de uso base precisa ser revisto”
� A dependência possui o estereótipo <<include >>
18
Inclusão � Como exemplo, tanto “Sacar dinheiro” quanto
“Consultar saldo” necessitam da senha � Cria-se novo caso de uso “Autenticar usuário” e incluí-
lo � Mas atenção
� Não se deve criar casos de uso MÍNIMOS � Deve haver ganho no reuso
Caso de uso incluído
Sacar dinheiro
Consultar saldo
Autenticar usuário << include >> << include >>
Caso de uso base 19
Extensão � Significa que o caso de uso base incorpora
implicitamente o comportamento de outro caso de uso
� Apenas em circunstâncias específicas, o caso de uso estendido tem seu comportamento incorporado pelo caso de uso base: pontos de extensão
� Utilizado para modelar o comportamento excepcional do sistema (exceções)
20
Extensão
Efetuar troca Devolver Produto
<< extend >> (opção de troca)
Relacionamento de Extensão Ponto de Extensão
Caso de uso base Caso de uso estendido
21
Generalização/Especialização � Similar à generalização entre classes � Caso de uso pode especializar outro
� Adição/refinamento do fluxo de eventos original
� Um caso de uso filho pode ser utilizado no lugar do seu pai
� Também pode ser utilizado entre atores � Representado por uma seta contínua que
aponta do filho para o pai � Especialização permite modelar
comportamento de estruturas de aplicação em comum 22
Generalização/Especialização
Efetuar Pagamento Efetuar Pagamento com Cartão de Crédito
Δ
Cliente Cliente comercial
Δ
Caso de uso base Caso de uso derivado
23
Diagrama de Atividades
Definições � Capturam ações e seus resultados, focando o
trabalho executado na implementação de uma operação (método), e suas atividades numa instância de um objeto.
� Trata-se de uma variação do diagrama de estado com um propósito um pouco diferente do diagrama de estado: � Capturar ações (trabalho e atividades que serão
executados) e seus resultados em termos das mudanças de estados dos objetos.
25
Definições � Forma alternativa de se mostrar interações
� expressar como as ações são executadas � o que elas fazem (mudanças dos estados dos objetos) � quando elas são executadas (seqüência das ações) � onde elas acontecem (raias de natação).
� Consistem em estados de ação, contendo a especificação de uma atividade a ser desempenhada por uma operação do sistema.
� Decisões e condições, como: execução paralela, também podem ser mostradas na diagrama de atividade.
� O diagrama também pode conter especificações de mensagens enviadas e recebidas como partes de ações executadas.
26
Notação � Estado de Ação: usado quando o
usuário faz alguma coisa ou existe a resposta do sistema, pode ser usado este símbolo.
� Passagens entre atividades: (fluxo ou gatilho) Podem ser acrescentados efeitos e resultados.
� Decisão: Diversas saídas para o símbolo de decisão
27
Notação
� Fork: Significa que uma atividade chegou neste ponto e foi subdividida em mais de uma atividade.
� Join: Significa que uma atividade chegou num mesmo ponto e criou-se uma nova atividade.
� Entrada/Saída: Pode haver diversos pontos de saída para um processo.
28
Notação � Merge: Fluxos convergentes para um
único ponto e existe apenas um saída, o que é diferente do join, onde vários fluxos chegam concorrentemente.
� Condição: pode ser representada escrevendo um texto entre colchetes e em itálico. Esse texto está sob a forma de um fluxo, necessariamente.
� Raias de Natação. Reproduz as raias de uma piscina. Indica a passagem do fluxo de atividade de um ator para outro. Pode ser vertical ou horizontal.
29
Estado Composto
30
Comportamento Condicional
31
Comportamento Paralelo
32
Decomposição � Uma atividades pode ser dividida em subatividades:
33
Concorrência Dinâmica � Informa a ocorrência de um laço onde um
mesmo Estado de Ação pode se repetir várias vezes
� Indicado por um *
34
Sinais
35
Raias � Permite que se documente o que acontece e
quem faz acontecer. � Permite que, em modelagem de domínio, o
diagrama de atividade represente pessoas ou departamentos responsáveis por cada atividade.
� Para usar raias, você deve organizar seus diagramas de atividades em zonas verticais separadas por linhas. Cada zona representa as responsabilidades de uma classe específica ou um depto específico.
36
Raias
37
Diagrama de Classes
Introdução
� Uma classe é a descrição de um tipo de objeto.
� Todos os objetos são instâncias de classes, onde a classe descreve as propriedades e comportamentos daquele objeto.
� Identificar as classes de um sistema pode ser complicado, e deve ser feito por especialistas no domínio do problema a que o software modelado se baseia.
39
Introdução
� Um diagrama de classes denota a estrutura estática de um sistema e as classes representam coisas que são manipuladas por esse sistema.
� O diagrama de classes é considerado estático já que a estrutura descrita é sempre válida durante o ciclo de vida do sistema.
� A notação utilizada para representar o diagrama de classes em UML é fortemente baseada na notação de Diagramas Entidade-Relacionamento [CHE90] e no Modelo de Objetos de OMT [RUM94].
40
Propósito do Diagrama de Classes � Fazer modelagem do vocabulário do sistema
� Indica quais abstrações fazem parte do sistema e quais estão fora do limite do mesmo
� Fazer a modelagem e colaboração simples � Mostra como as classes trabalham em conjunto permitindo a
compreensão de uma semântica maior do que se estas mesmas classes fossem analisadas individualmente.
� Fazer a modelagem do esquema lógico de um banco de dados � Descreve, de forma orientada a objetos, o esquema lógico de
um banco de dados que fisicamente pode ser orientado a objetos, relacional ou híbrido.
41
Um exemplo
42
SalesLineItem quantity : Integer
subtotal()
ProductCatalog
specification()
ProductSpecification description : Text price : Quantity upc : UPC
Store address : Address
name : Text addSale()
Payment amount : Quantity
Contains 1.. *
Contains 1.. *
POST
endSale() enterItem() makePayment()
Sale date : Date
isComplete : Boolean time : Time becomeComplete()
makeLineItem() makePayment()
total()
Captures
Houses
Uses
Looks-in
Paid-by
Describes
1 1
1
1 1
1
1 1
1
1
1
1
1
*
Logs-completed 4 *
1
Perspectivas de um Diagrama de Classes � Conceitual: forma abstrata de se observar
classes e objetos e independente da linguagem de programação (Modelo Conceitual)
� De Implementação: pensa-se em detalhes de implementação para definir as classes e objetos.
43
Identificação de Classes com Estereótipos
Estereótipo é um classificador. Tipos: • Entidade: representam conceitos do mundo real
e armazenam dados que os identificam • Controle: controlam a execução de processos e
o fluxo de execução de todo ou de parte de casos de uso e comandam outras classes
• Fronteira: realizam o interfaceamento com entidades externas (atores), contém o protocolo de comunicação com impressora, monitor, teclado, disco, porta serial, modem, etc.
44
Exemplo de Uma Classe
Aluno
<<entidade>> Aluno DePacoteCadastro
nome:TipoNome RA: TipoCódigo -nome[30]:char
+RA: int {valorconstante}
calculaMédia():TipoNota +calculaMédia():Double
Visão Conceitual Visão de Implementação
45
Exemplos no Sistema Posto Comercial
<<identidade>>
Intens <<controle>> <<fronteira>>
ControleComprarItens InterfaceCliente
46
Relacionamentos
� Os relacionamentos ligam as classes/objetos entre si criando relações lógicas entre estas entidades.
� Os relacionamentos podem ser dos seguintes tipos: � Associação � Generalização � Dependência e Refinamentos
47
Associação
� Uma associação representa que duas classes possuem uma ligação (link) entre elas, significando, por exemplo, que elas “conhecem uma a outra”, “estão conectadas com”, “para cada X existe um Y” e assim por diante.
� Podem ser: � Normal, Recursiva, Qualificada, Exclusiva,
Ordenada, Classe, Ternária e Agregação.
48
Associações Normal– Cardinalidade (Multiplicidade) � Especifica o número de objetos de cada
classe envolvidos com a associação � A leitura da cardinalidade é diferente para
os diferentes sentidos da associação
Caixa Venda
registra
0..* 1
49
Associação de Classe - Exemplo � A associação da classe Fila com a associação das
classes Cliente e Processo pode ser estendida com operações de adicionar processos na fila, para ler e remover da fila e de ler o seu tamanho.
� Se operações ou atributos são adicionados a associação, ela deve ser mostrada como uma classe.
50
Associação de Agregação � A agregação é um caso particular da associação. � A agregação indica que uma das classes do
relacionamento é uma parte, ou está contida em outra classe.
� As palavras chaves usadas para identificar uma agregação são: “consiste em”, “contém”, “é parte de”.
� Existem tipos especiais de agregação que são as agregações: compartilhadas e as compostas.
51
Agregação de Composição � É uma agregação onde uma classe que está contida
na outra "vive" e constitui a outra. Se o objeto da classe que contém for destruído, as classes da agregação de composição serão destruídas juntamente já que as mesmas fazem parte da outra.
52
Generalização Normal � Na generalização normal a classe mais
específica, chamada de subclasse, herda tudo da classe mais geral, chamada de superclasse. Os atributos, operações e todas as associações são herdados.
� Uma classe pode ser tanto uma subclasse quanto uma superclasse, se ela estiver numa hierarquia de classes que é um gráfico onde as classes estão ligadas através de generalizações.
53
Generalização Normal - Exemplo � A generalização normal é representada por uma linha
entre as duas classes que fazem o relacionamento, sendo que se coloca uma seta no lado da linha onde se encontra a superclasse indicando a generalização.
54
Dependência e Refinamento � Uma relação de dependência é simbolizada por uma
linha tracejada com uma seta no final de um dos lados do relacionamento. E sobre essa linha o tipo de dependência que existe entre as duas classes.
� As classes “Amigas” provenientes do C++ são um exemplo de um relacionamento de dependência.
55
Organização de Classes em Pacotes Lógicos
Vendas Compras Adminis- tração
56
Diagrama de Objetos
Definições � A notação UML de um objeto é semelhante à de
uma classe: � São mostrados os valores dos atributos � Os métodos não são incluídos � Além do nome da classe, podemos dar um nome ao
objeto.
58
Definições � Exemplo
59
Diagramas de Interação Sequência
Interação � Diagrama de Interação: modelam os aspectos
dinâmicos do sistema � Contém:
� Objetos � Vínculos � Mensagens
� Tipicamente, um diagrama de interação captura comportamento em um caso de uso
� Descrevem como grupos de objetos colaboram num contexto de um cenário
� Existem 2 tipos de diagramas de interação: � Diagrama de Seqüência � Diagrama de Comunicação
61
Interação � Cenários:
� Instância de um caso de uso, descrevendo como este funciona
� É um caminho através do fluxo de eventos de um caso de uso
� Fluxo de eventos: documentado via texto � Cenário : documentado via diagramas de interação � Documenta como as responsabilidades são divididas
entre classes e objetos
62
Diagrama de Interação � Interação em caso de uso
� Inclui uma seqüência de trocas de mensagens entre um conjunto de objetos para realização de um caso de uso
� As mensagens podem incluir sinais e chamadas implícitas
� Em modelagem comportamental é comum descrever vários cenários para cada caso de uso
� Para especificar uma interação é necessário definir um contexto de caso de uso e estabelecer os objetos que interagem e seus relacionamentos
63
Diagrama de Interaçãos
� Interação em caso de uso
64
Diagrama de Interação � Diagrama de Seqüência
� Mostra a interação entre objetos tendo em vista a seqüência das mensagens no tempo
� Mostra no cenário: � Objetos e classes envolvidos
� A seqüência de mensagens trocadas pelos objetos � Elementos:
� Linha da vida, ativação, auto chamada, condição , retorno, iteração
65
Diagrama de Sequência � Notação:
66
Mensagens � Representam a execução de uma operação de uma
classe ou a ocorrência de um evento em uma máquina de estados, e são ordenadas no tempo (de cima para baixo);
67
Sintaxe para Mensagens � Mensagem
� rótulos: predecessor cond-guarda exp-sequencia valor retorno:= nome-da-mensagem lista-de-argumento � expressão de seqüência - 1.1.2: , 1.2.3: , 3.1a: , 3.1b: � predecessor - 1.1, 1.2 / 1.3 : continue ( ) � condições de guarda - [cláusula-de-condição]
� 3.1 [x < 0] : abc ( ) � 3.2 [x >= 0] : def ( )
� iterações - * [cláusula-de-interação] � 1.1 * [n := 1..10]: execute ( )
� valor de retorno := nome-da-msg lista-arg � 1.4.5: x := calcular (n)
� EX: 2 * [n : = 1 .. 8] : Acumulado := calcularNext (n)
68
Sintaxe para Mensagens
:Posto :Venda
1: *[(x<10)] t:=total():Integer
69
Mensagem Reflexiva ou Autodelegação
70
Criação e Destruição de Objetos
71
Diagrama de Sequência- Exemplo
72
Diagrama de Comunicação
n Relacionamento com outros Diagrama n Uma colaboração não precisa,
necessariamente, ser representada em um diagrama de comunicação. Você pode fazer isso num diagrama de classe.
n As classes colaboram enviando mensagem umas para as outras. Na verdade, são objetos, instanciados na memória, que enviam mensagem uns para os outros.
n Se a ênfase do diagrama for o decorrer do tempo: n diagrama de seqüência
n Se a ênfase for o contexto do sistema (classes): n diagrama de colaboração (comunicação).
73
Diagrama de Comunicação
n Modela objetos e ligações de uma interação: n Apresenta somente os objetos e ligações
significativas para a interação; n As mensagens são numeradas
sequencialmente; n Mostra implementação de operações,
descrevendo parâmetros e variáveis locais usadas.
74
Composição � É formado por: � Objetos (retângulos) � Interações entre objetos (linhas
ligando objetos) � Mensagens (texto e setas)
75
Diagrama de Comunicação � Em um diagrama de comunicação o tempo não é mais representado por linhas verticais, mas sim através de uma numeração, que pode ser de duas formas: � simples (1,2,3,...) � composta (1.1, 1.2, 1.2.1, ...)
76
Diagrama de Comunicação � Um vínculo é uma associação que identifica uma ligação entre dois ob j e t o s envo l v i do s em um processo. É caracterizado pelo envio ou recebimento de uma mensagem, ou ambos.
77
Diagrama de Comunicação
78
79
Diagrama de Comunicação
80
Diagrama de Estados
Definições � Trata-se de um complemento para a descrição
das classes, documentando os estados possíveis que objetos de uma certa classe podem assumir, além de mostrar ainda os eventos do sistema que geram tais mudanças.
� Os diagramas de estado não são escritos para todas as classes de um sistema, mas apenas para aquelas que possuem um número definido de estados conhecidos e onde o comportamento das classes é afetado e modificado pelos diferentes estados.
82
Visualização
� Eles mostram os estados que um objeto pode possuir e como os eventos (mensagens recebidas, timer, erros, e condições sendo satisfeitas) afetam estes estados ao passar do tempo.
� Todos os objetos possuem um estado que significa o resultado de atividades executadas pelo objeto, e é normalmente determinada pelos valores de seus atributos e ligações com outros objetos.
83
Quando usar
� Se o relacionamento de classes não está claro o suficiente em função do estado dos objetos, isso será uma pista de que deve usar este diagrama. Essa percepção é pessoal
� Diagrama de Estados enfatizam os estados dos objetos e as transições entre estes estados enquanto o Diagrama de Atividades enfatiza o fluxo de controle de uma atividade para outra.
84
Evento � Um objeto muda de estado quando acontece
algo, o fato de acontecer alguma coisa com o objeto é chamado de evento.
� Os objetos de uma classe habitualmente possuem um ciclo de vida: são gerados, assumem posições durante a sua vida, dão origem a outros objetos em classes relacionadas e deixam de existir no momento de sua destruição.
85
Transições � Uma transição representa um evento que
causa a mudança de estado de um objeto. � Evento de Ativação
86
Evento de Transição � A transição de estados é criada a partir de
um evento � Este pode ou não conter uma descrição � Pode conter uma ordem para realizar uma
tarefa � Pode também conter condições de guarda
87
Estados de Início/Fim
88
Ações Internas � Entry: ações realizadas no momento em
que o objeto assume o estado em questão � Exit: ações realizadas antes do objeto
mudar de estado � Do: atividades executadas enquanto o
objeto se encontra em determinado estado
89
Escolha � Um losango simples é um estado de escolha. Ao se
chegar a um estado de escolha, o software deve tomar um decisão e ir para qualquer estado possível, dos que saem do estado de escolha.
90
Escolha � Um losango simples é um estado de escolha. Ao se
chegar a um estado de escolha, o software deve tomar um decisão e ir para qualquer estado possível, dos que saem do estado de escolha.
91
Barra de Sincronização
92
Estado de História
93
Exemplo – Objeto Venda
94
Diagramas de Componentes e Implantação
Definição conjunta � Diagrama de Componentes: mostra vários
componentes em um sistema e suas dependências
� Diagrama de Implantação (Utilização): mostras as relações físicas entre componentes de software e hardware no sistema implementado
� Podem ser criados separadamente ou combinados (quais os componentes funcionam em que nós)
96
Diagrama de Componentes � Apresenta uma visão estática de como o
sistema está implementado e quais os seus módulos de software: componentes
� Muito associado a linguagem de programação
� Procurar associar módulos, bibliotecas, formulários, arquivos, tabelas ...
97
� Componente:. O componente pode ser uma página HTML, um arquivo txt, dll, jar e etc.
� Um componente expõe suas interfaces (métodos públicos) para o mundo externo. Para representar isso é possível utilizar a notação de uma interface e estereotipá-la como um componente.
� É possível representar as interface públicas de um componente.
� Um componente normalmente é descrito por um <<estereótipo>>
Notação <<componente>>
PedirMaterial
PedirMaterial
PedirMaterial
98
Dependências � Um componente pode utilizar serviços ou
depender de alguma outra forma de outros componentes do sistema
99
Dependências � Classes manipuladas por um componente
100
Interface
101
� A forma de representar uma interface esperada
� Interfaces esperadas se encontrando com interfaces fornecidas
Notação
ControlarEstoque
PedirMaterial
ControlarEstoque
ReceberPedidos
102
Interface
103
<<interfaces fornecidas>> ReceberPedidos <<interfaces requeridas>> ControlarEstoque <<realiza>> Professor Pedido Funcionario <<artefato>> ControlePedido.JAR
PedirMaterial
Interface
104
Exemplo
105
Diagrama de Implantação
� O diagrama de implantação representa como é realizada a distribuição do sistema através de nós de hardware, componentes e dependências de software e as suas devidas relações de comunicação.
� Um diagrama de implantação modela o inter-relacionamento entre recursos de infra-estrutura, de rede ou artefatos de sistemas. Normalmente representamos servidores neste diagrama. Estes recursos são chamados de nodes ou nós.
106
Diagrama de Implantação
� Cada nó é um máquina física que encerra um ou vários componentes. Outros dispositivos podem ser representados com o estereótipo de <<dispositivos>> ou <<device>>
107
Associações � Os nós podem possuir ligações entre si de
forma que possam se comunicar e trocar informãções
108
Nós com Componentes � Comum identificar os componentes que são
executados por um nó
109
Exemplo
110