UML_Apostila_V7 0_ANP

Prévia do material em texto

D
en
iz
e 
P
im
en
ta
1
Este material está registrado na Biblioteca Nacional.
Registro 397.004 - Livro 739 - Folha 164
Índice
1: Visão Geral
1.1 – Importância da Modelagem 10
1.2 – Introdução à UML 14
1.3 – Introdução ao RUP 21
Exercícios do Capítulo 1 50
2: Conceitos de Orientação a Objetos e Diagramas UML
2.1 – Conceitos de Orientação a Objetos 54
2.2 – Diagramas da UML 66
Exercícios do Capítulo 2 86
3: Diagrama de Casos de Uso
3.1 – Conceito 90
3.2 – Construção do Caso de Uso 117
Exercícios do Capítulo 3 – Parte 1 121
Exercícios do Capítulo 3 – Parte 2 129
4: Diagrama de Classe
4.1 – Diagrama de Classe 132
Exercícios do Capítulo 4 164
D
en
iz
e 
P
im
en
ta
2
5: Diagrama de Sequência
5.1 – Conceitos 168
5.2 – Componentes do Diagrama 172
Exercícios do Capítulo 5 186
6: Diagrama de Atividades e Diagrama de Estados
5.1 – Diagrama de Atividades 189
Exercícios do Capítulo 6 – Parte 1 207
5.2 – Diagrama de Estados 208
Exercícios do Capítulo 6 – Parte 2 227
6: Exercício Prático 231
D
en
iz
e 
P
im
en
ta
3
D
en
iz
e 
P
im
en
ta
4
D
en
iz
e 
P
im
en
ta
5
D
en
iz
e 
P
im
en
ta
6
D
en
iz
e 
P
im
en
ta
7
De uma forma geral iremos ver o que a UML pode oferecer, um histórico da criação da
linguagem até como ela se encontra atualmente.
D
en
iz
e 
P
im
en
ta
8
linguagem até como ela se encontra atualmente.
O entorno da linguagem também será visto, iremos falar de metodologias de
desenvolvimento de software (foco no RUP) e a importância da modelagem de sistemas,
qual o objetivo que nos leva a construir vários diagramas e suas intermináveis
manutenções.
O uso de ferramenta CASE, neste curso, é secundário, porque primeiramente
necessitamos aprender a escrever os diagramas.
Objetivos do Capítulo 1:
1. Importância da Modelagem
2. Introdução à UML
D
en
iz
e 
P
im
en
ta
9
2. Introdução à UML
3. Introdução ao RUP
Neste tópico veremos:
• O que é modelo
• Porque é feita a modelagem de sistemas
D
en
iz
e 
P
im
en
ta
10
• Porque é feita a modelagem de sistemas
O principal produto, de uma equipe de desenvolvimento, é um bom software capaz de satisfazer às
necessidades de seus usuários e respectivos negócios. Tudo mais é secundário (não significa que é
irrelevante).
D
en
iz
e 
P
im
en
ta
11
Para desenvolver software de qualidade duradoura é necessário criar uma arquitetura de fundação
sólida que aceite modificações futuras. Desta forma devemos pensar antes da construção do sistema,
este pensamento é evoluído com os diagramas em suas fases de análise (lógico) e projeto (design).
O que é um modelo ?
Um modelo é uma simplificação da realidade.
São esquemas gráficos que representam o sistema.
D
en
iz
e 
P
im
en
ta
12
São esquemas gráficos que representam o sistema.
Como fazer a modelagem ?
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.
Cada modelo poderá ser expresso em diferentes níveis de precisão.
Os melhores modelos estão relacionados à realidade.
Nenhum modelo único é suficiente. Deve-se usar um conjunto de modelos independentes.
Como na Arquitetura e na Engenharia são utilizadas plantas e esquemas que traduzem como as
coisas são construídas, as relações entre as partes e o todo, o funcionamento e suas disposições.
Não existe nenhuma planta que mostre todos os detalhes de uma construção, existe a planta
hidráulica, a elétrica, a planta baixa e até uma maquete, mas o entendimento do que é o
empreendimento só faz sentido se analisarmos todos esses ‘pontos de vista’.
Nós construímos modelos, dentre outros fatores, com o objetivo de dominar a complexidade de um
sistema, compreendendo melhor a sua estrutura e funcionamento. Os modelos auxiliam os gerentes
pois permite que seja feito o planejamento adequado de recursos e a gerência riscos. No processo de
desenvolvimento de sistemas também construímos modelos para documentar a estrutura e o
comportamento do sistema.
“Construímos modelos para entender e visualizar um sistema - dominar a sua complexidade”
Existem metodologias quer pregam o desenvolvimento rápido, como a metodologia XP, onde não há
modelagem no início para levantamento, são feitas reuniões diárias e há a participação efetiva do
conhecedor do negócio “dentro do desenvolvimento” para tirar dúvidas a qualquer momento, existem
pontos negativos e positivos.
D
en
iz
e 
P
im
en
ta
13
pontos negativos e positivos.
No início deste capítulo foram colocados alguns motivos para fazer a modelagem de sistemas antes
do início do desenvolvimento (codificação) do sistema.
O que é melhor? Quando utilizar uma forma e quando não é possível utilizar o desenvolvimento
rápido?
Neste tópico veremos:
• O que é a UML
D
en
iz
e 
P
im
en
ta
14
• O que é a UML
• Histórico de versões
No início da conceituação de orientação a objeto vários autores trabalhavam isoladamente
construindo diagramas e receitas para um bom desenvolvimento de software, este trabalho foi
motivado com o surgimento das primeiras linguagens orientadas a objetos, como o Smalltalk.
Linguagens Orientadas à Objetos surgiram na década de 70/80. Métodos surgidos: Booch, OOSE
D
en
iz
e 
P
im
en
ta
15
Linguagens Orientadas à Objetos surgiram na década de 70/80. Métodos surgidos: Booch, OOSE
(Object-Oriented Software Engineering) – Jacobson, e OMT (Object Modeling Technique) –
Rumbaugh, entre outros Fusion, Shlaer-Mellor e Coad-Yourdon. Rumbaugh se uniu à Booch em 1994
formando o Método Unificado, ainda em 95 Jacobson se integrou a equipe e incorporou o OOSE,
várias empresas como Digital, HP, IBM, Microsoft, Oracle, Rational, Unisys, entre outras,
contribuíram para a definição da UML 1.0. Em 97 a OMG (Object Management Group) definiu a UML
como uma linguagem de modelagem padrão.
Após um período de trabalho isolado os autores resolveram se unir e trabalhar em conjunto, o
resultado desta união foi a criação da Linguagem de Modelagem Unificada (UML) e do Processo
Unificado, posteriormente conhecido como RUP (Rational Unified Process). A UML (Unified Modeling
Language) é o sucessor de um conjunto de métodos de análise e projeto orientados a objeto
(OOA&D).
A UML é um modelo de linguagem, não um método. Um método pressupõe um modelo de linguagem
e um processo. O modelo de linguagem é a notação que o método usa para descrever o projeto. O
processo são os passos que devem ser seguidos para se construir o projeto.
O modelo de linguagem corresponde ao ponto principal da comunicação. Se uma pessoa quer
conversar sobre o projeto, como outra pessoa, é através do modelo de linguagem que elas se
entendem. Nessa hora, o processo não é utilizado.
A UML define uma notação e um meta-modelo. A notação são todos os elementos de representação
gráfica vistos no modelo (retângulo, setas, o texto, etc.), é a sintaxe do modelo de linguagem. Um
meta-modelo é um diagrama de classe que define de maneira mais rigorosa a notação.
A UML (Unified Modeling Language) é uma linguagem-padrão para a elaboração da estrutura de
projetos de software. Pode ser empregada para a visualização, especificação, construção e
documentação de artefatos que façam uso de sistemas complexos de software.
“UML é uma linguagem de modelagem, não uma metodologia.”
Na modelagem tradicional há a decomposição funcional, ou seja, o analista divide (decompõe) o
problema em funções e processos, resultando em uma decomposição hierárquica do problema.
D
en
iz
e 
P
im
en
ta
16
Com esta forma o código não é flexível, não se pode, com facilidade, incorporar mudanças futuras.
Um procedimento cirúrgico de uma clínica veterinária, provavelmente pensaríamos na identificação
do animal, diagnóstico, preparação do animal para cirurgia e procedimento cirúrgico. A modelagem
tradicional foca o processo.
O paradigma da orientação a objetos entende o mundo como objetos, o que eles são e o que podem
fazer. Os objetos irão interagir entre si e com os atores através de mensagens. No exemplo da clínica
veterináriateríamos os objetos:
Animal – com suas características relevantes para identificação e apoio à cirurgia, como:
nome, raça, peso, altura, cor, temperatura, etc. O animal pode ser cadastrado, ser medido,
ser pesado, ser consultado pelo nome.
Cirurgia – com a data de agendamento, descrição da necessidade (motivo), descrição da
conclusão, data de realização, qual animal participou, qual cirurgião responsável.
D
en
iz
e 
P
im
en
ta
17
A versão 2 da UML trouxe algumas modificações gráficas e inclusão de alguns diagramas.
O XMI (XML Metadata Interchange) entrou como padrão para as ferramentas CASE que trabalham
D
en
iz
e 
P
im
en
ta
18
O XMI (XML Metadata Interchange) entrou como padrão para as ferramentas CASE que trabalham
com a UML para que haja transferência de diagramas de uma ferramenta para outra sem perda de
informação.
Novos Diagramas:
Diagrama de Comunicação – Até a UML 1.5 era chamado de diagrama de colaboração. É usado
para mostrar a colaboração entre objetos, exibindo a troca de mensagens entre eles.
Diagrama de Estrutura de Compósito (Composite Structure) – mostra a cooperação entre
instâncias.
Diagrama de Resumo de Interação (Interaction Overview) – é uma variação do diagrama de
atividades. Os nós do diagrama são frames. Existem 2 tipos de frames: frame de interação
(diagramas de seqüência, comunicação, tempo, resumo de interação) e frame de ocorrência de
interação que indica uma atividade ou operação executada (atividade ou operação).
Diagrama de Tempo (Timing) – é usado para explorar o comportamento de um ou mais objetos
durante um período de tempo.
Como a UML nasceu de trabalhos isolados, podemos entender porque a constituição da Linguagem
teve diagramas isomorfos, ou seja, que tem a mesma forma, a mesma maneira de expressas um
mesmo assunto.
D
en
iz
e 
P
im
en
ta
19
A UML também não tem regras que ditam que todos os diagramas devem ser usados, ou quais usar.
Os autores entendem que depende do tipo de projeto, cada projeto tem uma característica e
carências diferentes. A idéia aqui é ser flexível suficiente para que em nenhum momento fique
faltando, ou fique descoberto um ponto do projeto. Por isso é interessante conhecer todos os
diagramas, para saber o que usar e como usar na hora que for necessário.
Os envolvidos com o projeto devem conhecer os diagramas da UML para saber o que
usar quando necessário.
D
en
iz
e 
P
im
en
ta
20
usar quando necessário.
Nunca são usados todos os diagramas em um mesmo projeto – existem diagramas que
falam a mesma coisa (diagramas de interação).
Neste tópico veremos:
• Modelos de Processo (Cascata, Espiral, Iterativo)
D
en
iz
e 
P
im
en
ta
21
• Modelos de Processo (Cascata, Espiral, Iterativo)
• Melhores Práticas da Engenharia de Software
• Introdução ao RUP (Fases e Disciplinas)
D
en
iz
e 
P
im
en
ta
22
Processo de Desenvolvimento de Sistemas
Um processo de software pode ser entendido como um conjunto estruturado de atividades exigidas
para desenvolver um sistema de software.
D
en
iz
e 
P
im
en
ta
“O processo é um conjunto de atividades e resultados associados que produzem um produto de
software". Sommerville
No processo de desenvolvimento podemos reconhecer diversas fases que devem ser cumpridas a
fim de que tenhamos o sistema funcionando à disposição do usuário. O processo de desenvolvimento
define a regra do jogo.
Em cada fase do projeto, precisamos executar diversas atividades, tais como:
• Reuniões com os usuários,
• Gerar documentações (requisitos, cronograma, documento de visão, diversos diagramas, etc),
• Fazer protótipos do sistema,
• Testar funcionalidades,
• Fazer instalações de computadores e sistemas operacionais, etc.
Essas atividades são agrupadas em fases, que dividem o processo de desenvolvimento de sistemas.
Cada processo define fases e atividades.
Todo esse esforço tem como alvo principal a construção de um sistema de qualidade que seja
duradouro, suportando modificações com um mínimo de retrabalho.
23
Processo em Cascata
D
en
iz
e 
P
im
en
ta
Processo em Cascata
Modelo idealizado por Royce em 1970, também conhecido como abordagem ‘top-
down’, tem como principal característica a sequência de atividades onde cada fase
transcorre completamente e seus produtos são vistos como entrada para uma nova
fase. Sofreu diversas ajustes e aprimoramentos sendo ainda muito utilizado nos dias
atuais.
As desvantagens deste modelo são :
•Dificuldade em acomodar mudanças;
•É mais apropriado quando os requisitos são bem compreendidos;
•Os projetos reais raramente se adaptam ao modelo linear e sequencial;
•É difícil capturar os requisitos de uma só vez;
•Cliente tem de pacientemente esperar o resultado final;
•Alto custo de correção das especificações quando encontrados nas fases de Teste e
Implantação.
24
Desenvolver Iterativamente – Minimiza riscos, acomoda melhor as mudanças, busca
de melhor qualidade, aprendizado e melhoria contínua, aumento da reutilização.
D
en
iz
e 
P
im
en
ta
de melhor qualidade, aprendizado e melhoria contínua, aumento da reutilização.
Gerenciar Requisitos – investigar, organizar e documentar os requisitos do sistema,
além de firmar e atualizar acordos entre o cliente e a equipe do projeto sobre os
requisitos variáveis do sistema. As chaves para o gerenciamento eficaz de requisitos
incluem manter uma sentença clara dos requisitos, junto com os atributos aplicáveis e a
rastreabilidade para outros requisitos e outros artefatos do projeto.
Usar Arquitetura de Componentes - tende a reduzir o tamanho efetivo e a
complexidade da solução e, portanto, são mais robustas e flexíveis.
Modelar Visualmente (UML) – ajuda a compreensão de sistemas complexos; explora e
compara alternativas de design a um baixo custo; forma uma base para implementação;
captura requisitos com precisão; e comunica decisões sem ambigüidade.
Verificar Constantemente a Qualidade – os artefatos devem ser avaliados à medida
que as atividades que os produzem são concluídas e na conclusão de cada iteração.
Gerenciar Mudanças – com vários desenvolvedores, organizados em diferentes
equipes, possivelmente em diferentes locais, trabalhando juntos em várias iterações,
releases, produtos e plataformas. Na ausência de controle disciplinado, o processo de
desenvolvimento rapidamente se transforma em caos.
25
O RUP implementa as melhores práticas, pois é iterativo, tem disciplinas de gerência
D
en
iz
e 
P
im
en
ta
O RUP implementa as melhores práticas, pois é iterativo, tem disciplinas de gerência
de requisitos, de mudanças e de qualidade, é centrado na arquitetura de
componentes, dirigido a casos de uso (indica o uso da UML) e desde cedo dá
condições de mensurar a qualidade através das várias iterações.
26
O RUP é um processo extenso e completo e é um framework porque pode ser
configurado para se adequar a todos os projetos, ou seja, podemos adaptar o processo à
D
en
iz
e 
P
im
en
ta
configurado para se adequar a todos os projetos, ou seja, podemos adaptar o processo à
necessidade e assim retirar atividades desnecessárias, quando preciso, moldando o
processo à realidade.
27
O desenvolvimento iterativo parte o sistema em pedaços e cada parte é submetida às
atividades até que se chaga a implantação e validação para então se juntar com outra
D
en
iz
e 
P
im
en
ta
atividades até que se chaga a implantação e validação para então se juntar com outra
parte do sistema e passar pelo ciclo novamente de forma incremental, até um certo ponto
teremos o produto inteiro.
28
D
en
iz
e 
P
im
en
ta
29
D
en
iz
e 
P
im
en
ta
30
Na maioria das iterações temos um ‘pedaço’ do sistema funcionando para validação com
o usuário, quando a entrega for externa, ou validação com a equipe na entrega interna.
D
en
iz
e 
P
im
en
ta
o usuário, quando a entrega for externa, ou validação com a equipe na entrega interna.
31
Esta figura representa duas dimensões:
D
en
iz
e 
P
im
en
ta
Esta figura representa duas dimensões:
•A horizontal que representa o aspecto dinâmicodo processo, como é ordenado e
expresso em termos de fases, ciclos e marcos de projeto - é o eixo do tempo.
•A segunda dimensão, vertical, são representadas as atividades, fluxos de trabalho,
artefatos e pessoas - é o eixo de conteúdo.
O final de cada iteração é marcado pela entrega de um artefato de software (uma
versão, um módulo, um conjunto de diagramas), esta entrega pode ser para validação
com o usuário (externa) ou para a equipe (interna).
Podemos observar que o compromisso de desenvolver um sistema, envolve diversas
atividades que são executadas continuamente durante todo o projeto.
No RUP as atividades têm uma alocação maior em função da fase em que se
encontra o projeto. As fases ajudam o gerente do projeto a fazer a apropriação de
profissionais e custos, resultando em uma maior eficiência.
Por exemplo, na fase de Iniciação (Inception) existe uma alocação maior de analistas
envolvidos nas atividades relacionadas à disciplina de requisitos e modelagem de
negocio, como por exemplo as atividades de “Encontrar Atores e Casos de Uso” e
“Desenvolver a Visão”. Todas as informações sobre papéis, atividades e artefatos
estão descritas no RUP.
32
D
en
iz
e 
P
im
en
ta
33
Este documento é feito para o planejamento do que será desenvolvido e atacado nas
iterações e fases do projeto.
D
en
iz
e 
P
im
en
ta
iterações e fases do projeto.
O exemplo mostra 9 casos de uso com 2 riscos diferentes que estão associados a 5
casos de uso.
Primeiramente todos os casos de uso são identificados na fase de Iniciação, onde foi
planejada somente uma iteração e somente a disciplina de Requisitos possui atividades.
Na fase de Elaboração está prevista duas iterações, onde serão desenvolvidos e
testados dois casos de uso com prioridade alta definido pela área de negócio e desta
forma mitigando os dois riscos nesta fase. Todos os outros casos de uso serão
detalhados e terão os artefatos de análise e design criados.
Na fase de Construção o foco maior é em implementação e teste, a disciplina de
requisitos é marcado pois pode haver necessidade de ajustes e/ou mudanças. Foram
planejadas duas iterações nesta fase.
Na fase de Transição será feita a implantação de todo o sistema para o ambiente de
produto e serão construídos todo material de suporte e ajuda ao usuário.
34
O foco é viabilizar a construção do projeto, estudo do projeto como um todo.
D
en
iz
e 
P
im
en
ta
O foco é viabilizar a construção do projeto, estudo do projeto como um todo.
Na fase de concepção é estabelecido o contexto de negócio para o sistema e
delimitado o escopo do projeto. Para tal, identificamos os atores que estarão
interagindo com o sistema, bem como os casos de uso associados às essas
interações.
O contexto de negócio inclui também um critério de sucesso, ponderado em função
de recursos e tempo. Essa ponderação nos dá o grau de “risco” que é possível
assumir.
Além disso, devemos nessa fase elaborar um estudo que tem como produto final um
cronograma básico de execução com as principais fases e datas de entrega.
Essa fase envolve a elaboração de uma proposta composto pelo escopo, principais
atores envolvidos, principais casos de uso e o uma estimativa de cronograma (com
os principais marcos do projeto).
35
O foco é minimizar os riscos, onde os elementos de risco a serem analisados, são os
D
en
iz
e 
P
im
en
ta
O foco é minimizar os riscos, onde os elementos de risco a serem analisados, são os
riscos de requisitos, tecnológicos (referentes a capacidade das ferramentas
disponíveis), de habilidades (dos integrantes do projeto) e políticos.
Envolve o registro das necessidades (domínio dos requisitos), o desenho da solução
(análise e design do sistema) e desenvolvimento e testes de ferramentas, hardware
específico e/ou tecnologia nova.
Consiste de uma análise mais refinada do sistema a ser construído, juntamente com
um plano detalhado de trabalho a ser feito. As metas da fase de elaboração são:
analisar o domínio do problema, estabelecer uma arquitetura funcional, desenvolver
um plano do projeto e minimizar elementos de riscos potenciais ao projeto.
Essa fase envolve a elaboração de um projeto completo, com o detalhamento de
interações e estrutura do sistema. Nessa fase também podemos construir um
protótipo que teste a arquitetura escolhida.
36
O foco é a codificação da solução encontrada anteriormente.
D
en
iz
e 
P
im
en
ta
O foco é a codificação da solução encontrada anteriormente.
Durante a fase de construção trabalhamos sobre o protótipo da fase anterior
adicionando novas funcionalidades e refinando as funcionalidades pré-existentes.
Chamamos essa abordagem de iterativa (por ciclos) e incremental (adicionando
valor).
O gerente do projeto define várias versões que devem ser liberadas a cada ciclo,
incluindo alterações, refinamentos e novas funcionalidades.
A cada ciclo é necessário rever os requisitos de cada parte da aplicação, pois essa é
a essência do desenvolvimento incremental.
37
Nessa fase o software pode ser instalado em ambiente de produção para que os
D
en
iz
e 
P
im
en
ta
Nessa fase o software pode ser instalado em ambiente de produção para que os
clientes possam trabalhar com ele. Como esta transição será feita ? Em paralelo com
o sistema atual ou simplesmente o substituído deixará de funcionar para início do
novo sistema ?
Assim que o programa entra em operação é previsto que alguns pequenos ajustes
sejam necessários para que a versão final esteja disponível.
Um marco dessa fase é a revisão da “versão beta” do produto para testes.
Se tiver programado é nesta fase que ocorre o treinamento e outro produto (ou
artefato) é o conjunto de manuais com instruções de uso do sistema.
Ao final dessa fase teremos o produto em sua versão final para uso irrestrito por todo
o público-alvo.
38
D
en
iz
e 
P
im
en
ta
39
D
en
iz
e 
P
im
en
ta
40
D
en
iz
e 
P
im
en
ta
41
D
en
iz
e 
P
im
en
ta
42
D
en
iz
e 
P
im
en
ta
43
D
en
iz
e 
P
im
en
ta
44
D
en
iz
e 
P
im
en
ta
45
D
en
iz
e 
P
im
en
ta
46
D
en
iz
e 
P
im
en
ta
47
D
en
iz
e 
P
im
en
ta
48
D
en
iz
e 
P
im
en
ta
49
Fase 1: ____________________
D
en
iz
e 
P
im
en
ta
50
Fase 1: ____________________
Fase 2: ____________________
Fase 3: ____________________
Fase 4: ____________________
Exercícios do Capítulo 1:
1) Marque todas as alternativas que corretamente complete a sentença: uma iteração típica
da fase de transição
a) produz material de suporte ao usuário final.
b) resulta em mudanças significativas da arquitetura.
c) possibilita auxiliar e ajudar os usuários.
d) requer suporte full-time do arquiteto de software.
e) resulta na criação do caso de desenvolvimento do projeto.
2) O Gerente de Projetos é responsável por quais artefatos?
a) Business Case.
b) Plano de Desenvolvimento de Sistemas.
c) Avaliação da Iteração.
d) Guias do Projeto.
3) Quais das seguintes frases são verdadeiras sobre a disciplina de Implementação?
a) Implementação é feita somente na fase de construção.
b) O arquiteto estrutura o modelo de implementação.
c) Revisões de código podem ser usadas no lugar do teste unitário.
d) Os componentes desenvolvidos são testados (teste unitário) pelos
desenvolvedores.
4) Quais dos seguintes artefatos pertencem à disciplina de ambiente?
a) Guia de Modelagem de Negócio.
D
en
iz
e 
P
im
en
ta
51
b) Guia de Design.
c) Plano do Projeto.
d) Caso de Desenvolvimento.
e) Caso de Uso.
5) [SERPRO-2001] A respeito da linguagem UML é correto afirmar que (marque somente
uma alternativa):
a) não se trata de uma linguagem de documentação.
b) é voltada para a representação conceitual e física de um sistema.
c) não abrange a documentação para a realização de testes.
d) não deve ser empregada para a documentação de artefatos que façam uso de
sistemas complexos de software.
e) é uma linguagem utilizada para a realização de testes de programas.
6) Marque todas as alternativas que corretamente complete a sentença: uma iteração típica
da fasede elaboração
a) envolve maior esforço de análise e design do que teste.
b) contribui significativamente para o Documento de Arquitetura.
c) gasta maior esforço na definição da Visão e do Business Case.
d) cria o produto em versão estável.
e) atualiza a lista de risco.
Foi visto neste capítulo:
D
en
iz
e 
P
im
en
ta
52
• Importância de fazer e criar modelos.
• Conceito básico da UML, que é uma linguagem, uma notação, não tem uma
regra para sua utilização, permitindo que o desenvolvedor/analista/gerente
use os diagramas como bem entender (seguindo sua notação).
• O RUP é uma proposta de metodologia de desenvolvimento de sistemas
que indica o uso a UML como notação. O RUP tem as regras, os passos a
serem executados para desenvolver software.
Objetivos do Capítulo 2:
• Aprender os conceitos da Orientação à Objetos
D
en
iz
e 
P
im
en
ta
53
• Aprender os conceitos da Orientação à Objetos
• Conhecer todos os diagramas da UML descobrindo os objetivos de cada um
Neste tópico veremos:
• O que é
D
en
iz
e 
P
im
en
ta
54
• O que é
• Paradigma
• Abstração
• Objeto
• Classe
• Herança
• Polimorfismo
• Mensagem
• Persistência
• Estereótipo
• Encapsulamento
Paradigma
“É uma forma de pensar e perceber o mundo real e determina o que escolhemos como significativo e
o que descartamos ao compreender ou descrever o que existe ou ocorre no mundo em torno de nós.
D
en
iz
e 
P
im
en
ta
55
A mudança de paradigma é uma oportunidade de encontrar novas interpretações para antigas
questões, bem como, para rever soluções tidas como definitivas.
Dizemos que a O.O. constitui um novo paradigma computacional pois representa uma mudança na
forma de pensar e conceber sistemas e programas de computador.
A estratégia de O.O. para modelagem de sistemas baseia-se na identificação dos objetos (que
desempenham ou sofrem ações no domínio do problema) e dos padrões de cooperação e interação
entre estes objetos.”
Abstração
Permite ignorar os aspectos de um assunto não relevante para o propósito. Diminui a complexidade.
D
en
iz
e 
P
im
en
ta
56
Objeto
É alguma coisa que pode ser identificada distintamente.
Qualquer coisa, real ou abstrata, à respeito da qual armazenamos dados e os métodos que os
manipulam. (Martin/Odell).
Uma entidade capaz de armazenar um estado (informação) e que oferece um número de operações
(comportamento) para ou consultar ou alterar o estado. (Jacobson). É algo que possui estado,
comportamento e identidade. (Booch).
Classe
• Pode ser vista como uma fábrica de objetos idênticos.
• Possui atributos e métodos.
D
en
iz
e 
P
im
en
ta
57
• Possui atributos e métodos.
• Uma descrição de um conjunto de objetos que compartilham os mesmos atributos, operações,
relacionamentos e semântica. (Rumbaugh)
• Um gabarito para diversos objetos que descreve como estes objetos são estruturados internamente
(Jacobson).
• Um conjunto de objetos que compartilham uma estrutura comum e um comportamento comum
(Booch)
Exemplo Classe x Objeto
Para criar efetivamente um objeto, nós devemos instanciá-lo, conforme o método construtor
aluno escrito em Java:
D
en
iz
e 
P
im
en
ta
58
class Aluno {
private String nome;
private int matric;
aluno(String s,int m) {
nome = s;
matric = m;
}
Aluno a1 = new Aluno(“João“,2202); }
Na última frase há a instância do objeto é quando o objeto é criado em memória e começa a existir
para o sistema.
A classe casa é como uma forma que irá criar objetos semelhantes. Observe que cada objeto tem
característica própria, a cor o número.
D
en
iz
e 
P
im
en
ta
59
Herança
Capacidade de um novo objeto tomar atributos, operações e relacionamentos de um objeto existente,
permitindo criar classes complexas sem repetir código.
D
en
iz
e 
P
im
en
ta
60
Representa generalização e especialização. Uma especialização pode incluir novos métodos,
atributos e relacionamentos.
Polimorfismo (“muitas formas”)
Permite que operações com o mesmo nome, mas com uma semântica de implementação diferente,
sejam ativadas por objetos de tipos diferentes.
D
en
iz
e 
P
im
en
ta
61
Ocorre quando uma mesma operação pode assumir vários comportamentos, como no exemplo a
operação calcula saldo de formas diferentes.
Sobrescrita (override)
O método da subclasse (classe filha) retorna um valor e o método da superclasse (classe pai) retorna
outro.
D
en
iz
e 
P
im
en
ta
62
No exemplo a superclasse contém um método para calcular o salário dos funcionários. A subclasse
herda este método, mas a subclasse pode decidir sobrescrever a implementação da superclasse
redefinindo a forma de calcular o salário dos empregados que trabalham em venda.
Sobrecarga (overload)
Cada método em uma classe é identificado pelo seu nome e sua lista de parâmetros. Podem existir
dois ou mais métodos com o mesmo nome, mas cada um com uma lista de parâmetros diferentes.
D
en
iz
e 
P
im
en
ta
63
Este conceito é chamado sobrecarga de método, esta facilidade permite que seja executada a
mesma ação com diferentes tipos de entradas. Conforme o método do exemplo apresentado abaixo,
utilizado para calcular o valor máximo entre dois números em diferentes combinações de entradas:
public static int maximo ( int x, int y ) {
// calcular o maximo usando dois numeros inteiros
}
public static double maximo ( double x, double y ) {
// calcular o maximo usando dois numeros decimais
}
Mensagem
A mensagem é troca de informações entre objetos. Para uma determinada função funcionar serão
chamados n métodos através dos objetos relacionados, essa comunicação entre objetos, que é a
chamada de operações é chamada de mensagem.
D
en
iz
e 
P
im
en
ta
64
chamada de operações é chamada de mensagem.
Persistência
O objeto pode sobreviver após a consecução do sistema, a existência do objeto pode persistir ao
tempo, isto significa que o objeto deve ser armazenado de alguma forma. Um objeto não persistente
é também chamado de transiente.
As classes de entidade serão persistidas, provavelmente se tornarão tabelas em um SGBD.
Estereótipo
É um mecanismo de extensão da semântica de meta-modelo. Podem ser criados pelo usuário. São
reconhecidos por ícones ou entre aspas (guillemets) « ». Como por exemplo a representação das
classes que serão persistidas das outras classes (transientes), definimos o estereótipo entity.
Existem estereótipos pré-definidos na UML, como por exemplo: «include».
Observação: para inserir aspas francesas (guillemets) use a combinação de teclas:
Alt + 0171 ‘«’ e Alt + ‘»’.
Encapsulamento
Encapsulamento é o processo de impedir que os atributos de uma classe sejam lidos ou modificados
por outras classes.
D
en
iz
e 
P
im
en
ta
65
Ele garante a inviolabilidade dos dados aumentando a robustez do sistema.
Os atributos (valores armazenados) de um objeto devem ser consultados ou modificados através dos
métodos da classe do objeto.
O uso de métodos como interface deve garantir o reaproveitamento e atualização do objeto.
Um objeto externo tem acesso aos métodos públicos e estes tem garantido o acesso a atributos
definidos na classe.
Existem também métodos privados, acessíveis somente por métodos do mesmo objeto. Vamos ver
visibilidade ao final do diagrama de classes.
Neste tópico veremos:
• Diagramas Estruturais x Comportamentais
D
en
iz
e 
P
im
en
ta
66
• Diagramas Estruturais x Comportamentais
• Diagramas:
• Caso de Uso
• Classe
• Sequência
• Comunicação
• Estado
• Atividade
• Componente
• Implantação
A UML na versão 2 inclui doze diagramas:
Classes – diagrama estrutural que mostra um conjunto de classes, interfaces, colaborações e seus
relacionamentos.
D
en
iz
e 
P
im
en
ta
67
relacionamentos.
Objetos – diagrama estrutural que mostra um conjunto de objetos e seus relacionamentos.
Casos de Uso – diagrama comportamental que mostra uma interação, dando ênfase à organização
estrutural de objetos que enviam e recebem mensagens.
Interação (Sequência e Comunicação) – descrevem o comportamento do sistema de acordo com o
tempo e a troca de mensagensentre os objetos. São levantadores de métodos.
Gráfico de Estados – diagrama comportamental que mostra uma máquina de estados, dando ênfase
ao comportamento ordenado por eventos de um objeto.
Atividades – diagrama comportamental que mostra uma máquina de estados, dando ênfase ao fluxo
de uma atividade para outra.
Diagrama de Estrutura de Compósito (Composite Structure) – mostra a colaboração dos objetos
em tempo de execução de uma funcionalidade.
Diagrama de Resumo de Interação (Interaction Overview) – é uma variação do diagrama de
atividades. Exibem dois tipos de nós (frames): frame de interações (mostra qualquer tipo de diagrama
de interação) e de ocorrência de interação (indica a chamada de uma atividade ou operação)
Diagrama de Tempo (Timing) – mostra o comportamento de um ou mais objetos em um período de
tempo.
Componentes – diagrama estrutural que mostra um conjunto de componentes e seus
relacionamentos.
Implantação – diagrama estrutural que mostra um conjunto de nós e seus relacionamentos.
Os diagramas estão divididos em dois grandes grupos:
Comportamentais - modelam aspectos dinâmicos do sistema, mostram, na maioria das vezes, como
D
en
iz
e 
P
im
en
ta
68
Comportamentais - modelam aspectos dinâmicos do sistema, mostram, na maioria das vezes, como
as entidades interagem para a execução de uma funcionalidade, são eles: de caso de uso,
seqüência, comunicação, de estado, de Tempo (Timming), de Resumo da Interação (Interaction
Overview), Estrutura de Compósito (Composite Structure) e de atividade.
Estruturais - modelam a estrutura do sistema, sua parte estática, mostram como as entidades são
compostas e seus relacionamentos, são eles: diagrama de classe, de objetos, de componente e de
implantação.
Sistema de Controle de Horas
D
en
iz
e 
P
im
en
ta
69
Sistema de Controle de Horas
O sitema funciona para que a empresa tenha controle sobre as horas trabalhadas dos
seus funcionários. A principal funcionalidade do sistema é o cadastro das horas
trabalhadas, onde todos os funcionários deverão informar quais foram as tarefas
desempenhadas, o projeto e o período gasto para execução da tarefa. Os gerentes
ou coordenadores deverão analisar as horas lançadas e aprovar ou reprovar as horas
cadastradas dos funcionários para os projetos de sua responsabilidade.
Deve haver flexibilidade para que a administração informe os novos projetos, cancele
os projetos que terminaram e execute a manutenção das tarefas.
A partir deste cenário serão apresentados os diagramas da UML.
Imagine a tela ou o conjunto de telas que fará parte de uma funcionalidade e imagine
D
en
iz
e 
P
im
en
ta
70
Imagine a tela ou o conjunto de telas que fará parte de uma funcionalidade e imagine
a interação do usuário com o sistema, qual a ação do usuário e como o sistema irá
reagir, quais os campos que terão lista de bancos, quais os campos que o usuário
deverá informar valores.
Devemos prever todas as reações do sistema – se o usuário digitar letra no lugar de
um número, como o sistema irá reagir ? Neste momento podemos prever inclusive
quais as mensagens de alerta/erro que retornarão ao usuário, afinal de contas o caso
de uso servirá de base para os testes.
Alguns casos de uso que podem ser aplicados ao sistema de controle de horas são
D
en
iz
e 
P
im
en
ta
71
Alguns casos de uso que podem ser aplicados ao sistema de controle de horas são
(este é um exemplo os casos de uso não estão levantados na totalidade do sistema):
O funcionário cadastra alocação: para o cadastramento da tarefa será necessária a
interação entre o funcionário e o sistema pois o funcionário deverá informar: a data da
atividade, o horário (hora início e fim) de sua realização, o sistema deverá exibir o
logon do funcionário e uma lista de atividades e projetos, o funcionário deverá
selecionar uma categoria e uma Ordem de Projeto e opcionalmente informar FSA/OS,
Sistema, Aplicação e Observação e então solicitar a confirmar a tarefa, o sistema
deverá gravar a tarefa e exibir a lista de tarefas.
O gerente avalia as horas lançadas: Visto que um gerente pode interagir com mais
de um projeto, ele deverá informar o projeto e o sistema irá listar todos os
funcionários que lançaram horas no projeto informado e que ainda estão aguardando
aprovação, o gerente seleciona o funcionário e seleciona todas as horas do
funcionário e então confirma a aprovação das suas horas – um tratamento de
exceção é a reprovação das horas indevidas, e deve ser previsto neste cenário.
O funcionário consulta mês: o funcionário seleciona navegação pelos meses e o
sistema deverá exibir suas tarefas cadastradas.
O exemplo acima mostra como pode ser feita uma descrição de um caso de uso, neste caso há
divisão entre Cursos Alternativos e Exceções. Nos Cursos Alternativos são descritos passos de uma
outra forma de encerrar o caso de uso corretamente, já as exceções indicam algum problema em
algum momento que poderá ocorrer.
D
en
iz
e 
P
im
en
ta
72
algum momento que poderá ocorrer.
O Caso de Uso também pode servir de base para fazer o Caso de Teste, pois terá todas as exceções
previstas.
O exemplo citado é a descrição de um caso de uso, deverá haver uma descrição para cada caso de
uso apresentado anteriormente.
Note que na descrição do caso de uso devemos especificar todos os cenários (fluxos alternativos e
de exceção), como também a identificação das regras de negócio e atributos que são as informações
trocadas entre o sistema e o ator.
D
en
iz
e 
P
im
en
ta
73
D
en
iz
e 
P
im
en
ta
74
No Diagrama de Classe os objetos envolvidos no sistema de controle de horas são agrupados
em classes. Uma classe é um conjunto de objetos.
Na classe de funcionários, os atributos incluem o logon, nome, unidade, filial e número
funcional. Esta classe também armazena a operação buscarLogon (dentre outras aqui ainda
não definidas).
Um Diagrama de Seqüência oferece uma visão detalhada de um caso de uso. Ele
D
en
iz
e 
P
im
en
ta
75
Um Diagrama de Seqüência oferece uma visão detalhada de um caso de uso. Ele
mostra uma interação organizada em forma de uma seqüência de passos entre os
objetos, dentro de um determinado período de tempo e contribui para que se entenda
a lógica dentro de cada caso de uso.
Os participantes são apresentados dentro do contexto das mensagens que transitam
entre eles.
As restrições de tempo podem ser representadas neste diagrama. A OCL (Object
D
en
iz
e 
P
im
en
ta
76
As restrições de tempo podem ser representadas neste diagrama. A OCL (Object
Constraint Language) é a linguagem que define as restrições, muito utilizada aqui
para determinar as restrições temporais do sistema.
Um Diagrama de Comunicação (antes chamado de Colaboração) é outro tipo de
D
en
iz
e 
P
im
en
ta
77
Um Diagrama de Comunicação (antes chamado de Colaboração) é outro tipo de
diagrama de interação. Assim como no Diagrama de Seqüência, o Diagrama de
Comunicação mostra como um grupo de objetos num caso de uso interage com os
demais. Cada mensagem é numerada para documentar a ordem na qual ela ocorre.
Os diagramas de comunicação e de seqüência são equivalentes a diferença é que o
diagrama de seqüência tem o tempo como participante fundamental.
O diagrama da figura é equivalente ao diagrama de seqüência anterior. Podemos
D
en
iz
e 
P
im
en
ta
78
O diagrama da figura é equivalente ao diagrama de seqüência anterior. Podemos
dizer que o diagrama de comunicação (antigo diagrama de colaboração) e o
diagrama de seqüência são isomórficos, ou seja, tem a mesma forma, podemos obter
a visão de um a partir do outro.
Enquanto o diagrama de seqüência tem uma visão temporal, o diagrama de
comunicação apresenta uma visão espacial dos objetos.
O estado de um objeto é definido pelos seus atributos em um determinado momento.
D
en
iz
e 
P
im
en
ta
79
O estado de um objeto é definido pelos seus atributos em um determinado momento.
Os objetos se movem através de diferentes estados, por serem influenciados por
estímulos externos. O Diagrama deEstado mapeia estes diferentes estados em que
os objetos podem se encontrar e quais os eventos que fazem com que os estados
dos objetos sejam alterados.
A classe alocação guarda as horas cadastradas pelos funcionários, essas horas
D
en
iz
e 
P
im
en
ta
80
A classe alocação guarda as horas cadastradas pelos funcionários, essas horas
devem ser validadas pelos seus respectivos coordenadores que utilizam a
funcionalidade ‘Aprovar Horas’ para aprovar ou reprovar as horas cadastradas em
seu projeto. A figura mostra as alterações de estado da classe alteração.
Diagrama de Atividade
D
en
iz
e 
P
im
en
ta
81
Diagrama de Atividade
Descreve a seqüência de atividades, com suporte para comportamento condicional e
paralelo, pode ser utilizado para modelagem de processo ou para descrever o passo
a passo de um caso de uso.
Componentes:
- Atividade (ou estado de atividade): é o estado de estar executando algo.
- Comportamento condicional:
•Decisão (branches) - uma transição de entrada única com várias saídas, na
execução só pode ter um fluxo de saída, ou seja as saídas são mutuamente
exclusivas.
•Intercalaçao (merges) - múltiplas transições de entrada convergindo para
uma de saída, marca o final de um comportamento condicional.
-Comportamento paralelo:
•Junção (joins) - converge duas ou mais transações em uma, mas esta só
ocorre se as iniciais tiverem sido terminadas.
•Separação (forks) - tem uma transição de entrada e várias transições, em
paralelo, de saída.
O Diagrama de Atividade é uma ferramenta útil para desenhar a solução de
implementação e pode estar baseada em um caso de uso ou pode definir um método
mais complexo.
A figura exibida mostra as atividades necessárias, do sistema, para a execução do
Cadastro de Alocação, exibindo todos os cenários do caso de uso (uso da decisão).
Observe que há atividades que podem ser executadas em paralelo (threading).
O diagrama de atividade é baseado em um caso de uso inteiro (todos os cenários) ou
em um processo.
Um Diagrama de Componentes exibe a hierarquia de dependência entre os
D
en
iz
e 
P
im
en
ta
82
Um Diagrama de Componentes exibe a hierarquia de dependência entre os
componentes do sistema.
Um componente é uma parte do sistema e pode ser entendido como uma tela, uma
biblioteca (dll), um arquivo de críticas (arquivos js), um executável, etc.
A figura mostra que o sistema tem várias camadas, as páginas ASP chamam
algumas regras, neste diagrama vemos qual a dependência entre elas. Lembre que
os componentes são bibliotecas, executáveis, telas, tabelas, uma parte qualquer do
sistema.
O Diagrama de Implantação mostra o layout físico da rede, onde cada nó representa
D
en
iz
e 
P
im
en
ta
83
O Diagrama de Implantação mostra o layout físico da rede, onde cada nó representa
uma máquina, podendo mostrar a configuração delas (hardware e software) e
também onde cada componente irá ser instalado.
O diagrama de implantação poderá ser usado para caracterizar o hardware e o software necessário a
ser instalado nos nós (máquinas ou periféricos). Inclusive a conexão entre os nós.
D
en
iz
e 
P
im
en
ta
84
O nó é um elemento físico que representa um recurso computacional com memória e/ou capacidade
de processamento, como máquinas, servidores, hubs, impressoras, etc.
D
en
iz
e 
P
im
en
ta
85
D
en
iz
e 
P
im
en
ta
86
Exercícios do Capítulo 2:
1) [BNDES-2007] O diagrama UML mais indicado para representar o passo a passo do
fluxo de eventos principal de um caso de uso de um software orientado a objetos é o
diagrama de:
a) casos de uso.
b) atividades.
c) eventos e transições.
d) classes.
e) componentes.
2) [CREA-PR – 2008] Os Diagramas Comportamentais da UML são utilizados para
visualizar, especificar, construir e documentar os aspectos dinâmicos de um sistema.
Eles podem representar como o sistema reage às ações do usuário e como os objetos
são criados e manipulados. Assinale a alternativa que apresenta apenas Diagramas
Comportamentais da UML.?
a) Diagrama de Classes, Diagrama de Pacotes e Diagrama de Componentes.
b) Diagrama de Casos de Uso, Diagrama de Classes, Diagrama de Colaboração
e Diagrama de Pacotes.
c) Diagrama de Classes, Diagrama de Colaboração, Diagrama de Atividades e
Diagrama de Interfaces.
d) Diagrama de Interação, Diagrama de Arquitetura e Diagrama de
Componentes.
e) Diagrama de Casos de Uso, Diagrama de Seqüência, Diagrama de Estados e
Diagrama de Atividades.
3) São diagramas da UML:
D
en
iz
e 
P
im
en
ta
87
a) Casos de Usos, Classes e Objetos.
b) Estado, Colaboração e Contexto.
c) Componentes, Seqüência e Entidade/Relacionamento.
d) Fluxo de Dados, Implantação e Casos de Usos.
4) Qual item abaixo melhor descreve um objeto?
a) Parte de um sistema de software que é inteiramente único.
b) Um conceito, abstração ou coisa em um domínio de aplicação.
c) Um programa que representa algo tangível no domínio do problema.
5) Qual item abaixo melhor descreve abstração?
a) Uma representação de algo tangível.
b) Uma representação que pode ser armazenada num sistema de software.
c) Uma representação que contém somente detalhes relevantes.
6) Qual item melhor descreve encapsulamento?
a) A implementação de um objeto pode somente ser mudado pelo programador
original.
b) Dados dentro de um objeto podem somente ser acessados passando uma
mensagem válida a uma de suas operações próprias.
c) Dados dentro de um objeto podem somente ser acessados passando uma
mensagem válida a sua classe.
D
en
iz
e 
P
im
en
ta
88
Objetivos do Capítulo 3:
1. Conceitos e Componentes do Diagrama de Casos de Uso
D
en
iz
e 
P
im
en
ta
89
1. Conceitos e Componentes do Diagrama de Casos de Uso
2. Construção do Diagrama de Casos de Uso
� Identificação de Casos de Uso
� Descrição dos Casos de Uso
� Desenho do Diagrama de Casos de Uso
Neste tópico veremos:
• Conceitos
D
en
iz
e 
P
im
en
ta
90
• Conceitos
• Modelo de Caso de Uso
• O que é Diagrama de Caso de Uso
• O que é Requisito de Sistema
• Modelagem de Negócio
• O que é cenário
• Ator
• Conceito
• Relacionamento
• Caso de Uso
• Conceito
• Relacionamentos
A documentação a ser entregue deve ser composta de: o Diagrama de Casos de Uso (desenho) e
para cada caso de uso do diagrama deverá ter um texto descrevendo sua interação.
D
en
iz
e 
P
im
en
ta
91
Diagrama de Caso de Uso :
Deve ser usado quando se deseja visualizar o comportamento do sistema, como se fosse o cardápio
apresentando tudo que o restaurante pode oferecer ao cliente.
D
en
iz
e 
P
im
en
ta
92
apresentando tudo que o restaurante pode oferecer ao cliente.
O Diagrama de Casos de Uso exibe todas as funcionalidades que o sistema têm, com isso ajuda a
definir o escopo do sistema.
Um caso de uso representa uma funcionalidade.
Caso de Uso é :
“ Um conjunto de seqüências de ações que um sistema desempenha para produzir um resultado
observável de valor a um ator específico. ”
Objetivo dos casos de uso:
Descrever os requisitos funcionais do sistema de maneira consensual entre usuários e
desenvolvedores de sistemas;
Fornecer uma descrição consistente e clara sobre as responsabilidades que devem ser cumpridas
pelo sistema, além de formar a base para a fase de desenho;
Oferecer as possíveis situações do mundo real para o teste do sistema.
Requisito é uma característica do sistema ou a descrição de algo que o sistema é capaz de realizar
para atingir seus objetivos.
O requisito pode ser de dois tipos:
D
en
iz
e 
P
im
en
ta
93
• funcional quando descreve uma interação entre o sistema e seu ambiente. Exemplo: Cadastro do
Cliente, Consulta à pedidos, etc; ou
• não funcional (também chamado de requisito de qualidade) quando descreve uma restrição do
sistema. Exemplo: amigável, tempo de resposta de 3 segundos, etc.
Os casos de uso somente espelham os requisitos funcionais, para definir os requisitos não funcionais
deve ser utilizado outro documento (Especificação Suplementar).
A modelagem de negócios ou comercial abrange um nível maior dentro da empresa
D
en
iz
e 
Pim
en
ta
94
A modelagem de negócios ou comercial abrange um nível maior dentro da empresa
do que a modelagem do sistema a ser desenvolvido. Ela é utilizada para mapear os
processos da empresa e mostrar como a mesma funciona.
Objetivos desse tipo de modelagem:
• Mostrar à empresa uma visão do que o mundo externo ganha ao se relacionar com
a empresa;
• Entender e documentar o que a empresa faz;
• Auxiliar no trabalho de reengenharia;
O caso de uso de negócios é um guideline, um roteiro utilizado para mapear um
processo, por exemplo precisamos definir para o restaurante como os garçons devem
preparar a mesa a regra de ordenação de talheres e copos ficarão descritos dentro do
caso de uso de negócio ‘Preparar a Mesa’.
Um ator de negócios interage com a empresa ou setor modelado, por exemplo o
fornecedor interage com a empresa, um outro exemplo é o Garçom com o Preparar a
Mesa e Servir o Pedido. Se for indicada a informatização para um melhor controle do
restaurante o Garçom não será necessariamente um ator do sistema.
Iterar - Tornar a dizer; repetir. A iteração é um ciclo. (Dic. Aurélio)
Interação - Ação recíproca de dois ou mais corpos, uns nos outros. 2. Fís. Ação mútua entre duas
partículas ou dois corpos. (Dic. Aurélio)
D
en
iz
e 
P
im
en
ta
95
A interação ou comunicação é o relacionamento entre o ator e o sistema. Pode existir relacionamento
entre casos de uso (extensão, inclusão e generalização).
A figura acima mostra os caminhos de um caso de uso, cada caminho é executado por um cenário.
Todos os fluxos deverão ser previstos na descrição do caso de uso. Um caso de uso tem ‘n’ cenários,
para cada cenário percorreremos um caminho (ou fluxo) do caso de uso.
Os atores (pessoas, outros sistemas, periféricos) interagem com o sistema através de uma fronteira.
No diagrama de caso de uso teremos todas as funcionalidades do sistema. Para cada funcionalidade
iremos descrever as interações entre o ator e as reações do sistema.
D
en
iz
e 
P
im
en
ta
96
O que constitui um bom ator ?
“Ator representa o sujeito que interage ou troca informação com o sistema. São externos ao sistema
descrito.”
D
en
iz
e 
P
im
en
ta
97
descrito.”
Atores não são parte do sistema, eles interagem com o sistema.
Fornecem dados e/ou recebem informação do sistema; Uma mesma pessoa pode assumir papéis
diferentes; Várias pessoas podem assumir o mesmo papel;
Identificando o ator:
O ator Cliente é o mesmo que ator Inadimplente ? – se o inadimplente usar o sistema de
forma diferente (somente poderá consultar novas formas de pagamento) eles são atores
diferentes.
Não devemos criar ator para cada ‘coadjuvante’, temos que identificar um grupo de
personagens que desempenham o mesmo papel, por exemplo: Gerente de Projeto e o
Coordenador da Equipe acessam as mesmas telas e desempenham o mesmo trabalho no
sistema, portanto pertencem ao mesmo grupo de personagens de Gerência.
O ator é aquele que utiliza o sistema para passar/receber informações. Pode ser outro sistema, um
hardware, um grupo de pessoas. Mas têm que necessariamente interagir com o sistema.
D
en
iz
e 
P
im
en
ta
98
Um equipamento ou outro sistema pode ser ator, desde que seja externo ao sistema e interaja com
ele.
Generalização/Especialização entre Atores
D
en
iz
e 
P
im
en
ta
99
Generalização/Especialização entre Atores
Os diagramas de casos de uso podem ser simplificados por meio da herança entre
atores. Neste caso, mostra-se um caso de uso comum aos atores específicos, que se
comunicam apenas com o ator genérico.
A figura mostra as especializações de “Gerente” para o ator mais genérico
“Funcionário”.
Esta figura informa que o Gerente é uma especialização de Funcionário e a parte
D
en
iz
e 
P
im
en
ta
100
Esta figura informa que o Gerente é uma especialização de Funcionário e a parte
mais especializada herda todas as atividades da classe mais genérica, ou seja, o
Gerente pode tanto Aprovar Horas quanto Cadastrar Ocupação e Consultar Mês, mas
Funcionário pode somente Cadastrar Ocupação e Consultar Mês.
A notação de generalização/especialização pode ser vista entre casos de uso e em
outros diagramas da UML.
Atenção na associação unidirecional entre o caso de uso ‘Aprovar Horas’ e o ator
SisRH, este exemplo indica que o ator somente receberá informações do sistema.
O Caso de Uso em si é uma seqüência de ações que um sistema desempenha para
D
en
iz
e 
P
im
en
ta
101
O Caso de Uso em si é uma seqüência de ações que um sistema desempenha para
produzir um resultado observável por um ator específico. Em outras palavras, um
caso de uso define uma funcionalidade do sistema com um conjunto de ações
tomadas pelo ator e a previsão da reação por parte do sistema.
O Caso de Uso é uma classe, não uma instância. A sua especificação descreve a
funcionalidade como um todo, incluindo erros, possíveis alternativas e exceções que
podem ocorrer durante sua execução. O nome do Caso de Uso deve ser uma frase
indicando a ação que realiza.
Cuidado para não identificar um caso de uso no lugar de um passo! Um caso de uso
tem um conjunto de passos e trata as exceções desses passos. Na descrição do
caso de uso é que teremos que pensar quais as ações que o caso de uso
desempenhará.
Alguns exemplos de casos de uso: Cadastrar Cliente, Registrar Venda, Fechar Caixa,
etc.
Um caso de uso, como dito anteriormente, representa uma funcionalidade do sistema:
D
en
iz
e 
P
im
en
ta
102
Um caso de uso, como dito anteriormente, representa uma funcionalidade do sistema:
tem início, uma entrada, uma solicitação, tem meio, um processamento, uma
gravação e tem um fim, uma confirmação, uma impressão, o resultado de uma
consulta na tela.
O caso de uso é desenhado como uma elipse e seu nome pode vir dentro do desenho
D
en
iz
e 
P
im
en
ta
103
O caso de uso é desenhado como uma elipse e seu nome pode vir dentro do desenho
ou abaixo da mesma.
Um caso de uso retrata uma funcionalidade e não uma atividade atômica, pois tem
início meio e fim. Um ator entra no sistema para cadastrar cliente e sai com o cliente
cadastrado.
Notações especiais são utilizadas para facilitar a descrição de funcionalidade mais
D
en
iz
e 
P
im
en
ta
104
Notações especiais são utilizadas para facilitar a descrição de funcionalidade mais
complexa. Entre estas notações, destacam-se os casos de usos secundários, que
simplificam o comportamento dos casos de uso primários através dos mecanismos de
extensão e inclusão.
Casos de uso primários são aqueles que são invocados por iniciativa direta de um
ator; casos de uso secundários são invocados em um passo de outro caso de uso. Os
termos “primário” e “secundário”, quando referentes a casos de uso, não fazem parte
da UML.
O caso de uso B estende o caso de uso A quando B representa uma situação
D
en
iz
e 
P
im
en
ta
105
O caso de uso B estende o caso de uso A quando B representa uma situação
opcional ou de exceção, que normalmente não ocorre durante a execução de A. Essa
notação pode ser usada para representar fluxos complexos opcionais ou anormais.
O caso de uso “estendido” é referenciado nas precondições do caso de uso
“extensor”. As precondições são a primeira parte dos fluxos dos casos de uso.
“Extensão - 1. Ato ou efeito de estender ou estender-se. 2. Qualidade de extenso. 3.
Fís. Propriedade que têm os corpos de ocupar certa porção do espaço. 4.
Desenvolvimento no espaço. 5. Vastidão. 6. Grandeza, força, intensidade. 7. Porção
de espaço. 8. Comprimento. 9. Superfície, área. 10. Ramal telefônico, com o mesmo
número do telefone principal, usado geralmente em residências ou escritórios.” (Dic.
Aurélio)
“Estender - v. 1. Tr. dir. e pron. Alargar(-se), alongar(-se), estirar(-se). 2. Tr. dir.
Desdobrar, desenrolar, desenvolver. 3. Tr. dir. Oferecer, apresentando: Estendeu a
mão ao visitante. 4. Tr. dir. Alastrar, espalhar. 5. Pron. Ocupar certa extensão. 6. Tr.
dir. Esticar. 7. Tr. dir. Tornar mais amplo. 8. Tr. dir. Fazer chegar; levar. 9. Tr. dir.
Expor ao ar, ao sol etc.” (Dic. Aurélio)
O desenhomostra a instância do caso de uso sendo executada e quando chega ao
D
en
iz
e 
P
im
en
ta
106
O desenho mostra a instância do caso de uso sendo executada e quando chega ao
ponto de extensão um outro caso de uso é chamado e executado para que então se
retorne à execução do caso de uso original (base).
O desenho informa que o cadastro do cliente pode ser chamado diretamente da
D
en
iz
e 
P
im
en
ta
107
O desenho informa que o cadastro do cliente pode ser chamado diretamente da
solicitação do serviço, mas esta é uma ação que pode ocorrer ou não.
Observe que o caso de uso que estende tem uma relação de dependência com o
caso de uso estendido (seta tracejada), ou seja, a o Cadastro do Cliente só pode ser
executada se Solicitar Serviço for executado antes.
Na figura percebemos que na funcionalidade Comandar Jantar podemos ter um
D
en
iz
e 
P
im
en
ta
108
Na figura percebemos que na funcionalidade Comandar Jantar podemos ter um
atalho para Comandar Bebida ou Comandar Sobremesa. Esta técnica é aplicada para
facilitar o uso do sistema. Atenção o uso dos casos de uso estendidos são
facultativos, ou seja, pode haver o pedido de jantar sem bebida e sem sobremesa.
O caso de uso A inclui o caso de uso B quando B representa uma atividade
D
en
iz
e 
P
im
en
ta
109
O caso de uso A inclui o caso de uso B quando B representa uma atividade
complexa, comum a vários casos de uso. Essa notação pode ser usada para
representar subfluxos complexos e comuns a vários casos de uso. O caso de uso
“incluído” é referenciado no fluxo do caso de uso “que inclui”.
O desenho mostra a instância de um caso de uso sendo executada e quando chega
D
en
iz
e 
P
im
en
ta
110
O desenho mostra a instância de um caso de uso sendo executada e quando chega
em um determinado ponto sempre deverá ser chamado um outro caso de uso (o
incluído), e este é executado para que então se retorne à execução do caso de uso
original (base).
Cadastrar Pagamento são passos comuns a Solicitar Serviço e Cadastrar Venda, por
D
en
iz
e 
P
im
en
ta
111
Cadastrar Pagamento são passos comuns a Solicitar Serviço e Cadastrar Venda, por
este motivo este conjunto de passos são isolados em outro caso de uso.
Observe também que o caso de uso que inclui tem uma relação de dependência com
o caso de uso incluído (seta tracejada). Ou seja, Solicitar Serviço e Cadastrar Venda
só podem ser executadas se Cadastrar Pagamento for executada.
Neste caso, a solução foi pensada de forma que, quando houver o Comando de
D
en
iz
e 
P
im
en
ta
112
Neste caso, a solução foi pensada de forma que, quando houver o Comando de
Jantar necessariamente haverá o Pagamento de Conta, da mesma forma quando
houver Comando de Almoço haverá Pagamento de Conta.
O importante é saber ler o que está desenhado, no exemplo o sistema somente será
acionado ao final do processo, quando haverá o registro do consumo (almoço ou
jantar) e logo em seguida o pagamento da conta.
D
en
iz
e 
P
im
en
ta
113
Na generalização de casos de uso o caso de uso pai define todos os passos comuns e os passos
específicos são executados pelo caso de uso filho.
D
en
iz
e 
P
im
en
ta
114
Receber pagamento em cheque, Receber pagamento em dinheiro e Receber pagamento em cartão
são especializações do caso de uso Receber Pagamento.
D
en
iz
e 
P
im
en
ta
115
Os UCs filhos herdam os atributos, operações e seqüências de comportamento do UC pai.
Os UCs filhos podem adicionar e redefinir o comportamento do UC pai, através da inserção de
seqüências adicionais de ações em pontos arbitrários da seqüência do UC pai.
Os UCs filhos podem substituir o UC pai em qualquer lugar que ele aparece.
Relacionamentos de inclusão e extensão do use case filho também modificam o use case do pai.
Normalmente a similaridade entre use cases é identificada após a descrição dos casos.
Outro exemplo: Tanto Checar password quanto Scan de retina servem para validar o usuário, e em
validar usuário tem um conjunto de passos comuns aos subtipos.
O exemplo mostra a descrição de casos de uso em generalização/especialização, a descrição da
esquerda é do UC pai e o da direita representa um dos UC filho.
D
en
iz
e 
P
im
en
ta
116
O passo 5 fica sem definição no ‘Caso de Uso Pai’ e em itálico pois representa na sintaxe da UML
alguma coisa abstrata.
Note que a solução poderia ser apresentada de outras formas, como por exemplo utilizando «inclui»
ou «estende», mas esta notação enfatiza o ‘relacionamento de família’, de similaridade das ações,
compartilhando a mesma estrutura, comportamento e intenção.
Neste tópico veremos:
• Construção do Caso de Uso
D
en
iz
e 
P
im
en
ta
117
• Construção do Caso de Uso
• Identificação de todos os casos de uso e atores
• Descrição de todos os casos de uso
• Desenho do Diagrama
A UML não dita regras para a construção do diagrama, ela apenas é uma notação. Os passos que se
seguem são uma sugestão para facilitar a construção do diagrama de casos de uso.
D
en
iz
e 
P
im
en
ta
118
Para facilitar a identificação construção do diagrama, dividimos a construção em três partes:
-A primeira é a identificação dos possíveis casos de uso – lembre-se que caso de uso é uma
funcionalidade do sistema e tem início, meio e fim.
D
en
iz
e 
P
im
en
ta
119
-A segunda tarefa é a descrição dos casos de uso, neste momento identificamos os verdadeiros
casos de uso do sistema, casos de uso com um, dois ou três passos podem sair do modelo e seus
passos podem ser identificados como sendo de outro caso de uso. Pode ser identificada também a
necessidade de criar um caso de uso novo quando identificado um conjunto de passos iguais em
mais de um caso de uso.
-A terceira parte é o desenho do diagrama, após a identificação e a descrição dos casos de uso o
desenho do diagrama fica fácil.
D
en
iz
e 
P
im
en
ta
120
Iremos trabalhar com o Sistema de Controle de Restaurante até o final do curso, após
D
en
iz
e 
P
im
en
ta
121
Iremos trabalhar com o Sistema de Controle de Restaurante até o final do curso, após
apresentar conceitos e os diagramas, faremos a aplicação prática com este exercício,
para isso é necessário que cada um monte seu próprio restaurante (pode ser em
grupo).
O primeiro exercício é tentar fazer uma lista dos casos de uso, identificando os
principais casos de uso e seus atores.
Lembre-se: o ator interage com o sistema.
A descrição de casos de uso é livre não tem regra alguns profissionais utilizam em forma de tabela
outros na forma de texto corrido, a UML não tem regra para isso.
D
en
iz
e 
P
im
en
ta
122
Fluxo (ou curso) típico, normal, ou principal – é o que ocorre se der tudo certo, imaginar o mundo
perfeito, sem erros.
Fluxos (ou cursos) alternativos e/ou exceções – é a descrição de uma alternativa de execução do
curso principal, pode ter uma forma correta alternativa ou os possíveis erros. Como o sistema deverá
reagir se determinada condição for falsa, este é o tipo de informação que deverá constar e estar
mapeada nas exceções.
Existem autores que dividem Cursos Alternativos e Exceções, a UML não obriga nenhum uso, o
Fluxo (ou curso) Alternativo ou Secundário representa uma outra forma de execução de um passo (ou
um conjunto de passos), como uma alternativa do curso principal, como por exemplo a venda à prazo
ou à vista, ambas as formas são possíveis e não indicam erro, são apenas alternativas diferentes de
registrar um pagamento.
Descrição do Caso de Uso
(2º. Passo)
Nome : Registrar contrato
Ator : Vendedor
Descrição : Este caso de uso é responsável pelo cadastramento de novos contratos no 
sistema (não há renovação do contrato).
Fluxo Normal – Incluir Contrato
1- O vendedor informa CNPJ do cliente;
2- O sistema recupera a razão social do cliente;
3- O sistema lista todos os tipos de equipamentos cadastrados;
4- O vendedor seleciona o tipo de equipamento desejado e informa dados dos 
equipamentos;
Para cada equipamento, deve-se selecionar um tipo de equipamento e 
informar seu número de série e data de fabricação.5- O vendedor informa dados básicos do contrato;
• data de início, 
• data de término e 
• quantidade de cotas de pagamento. 
6- O sistema registra o contrato; 
O sistema registra data de inicio e data de término (12 meses após a data 
de início), e gera um número sequencial único do contrato do cliente.
7- O sistema registra os equipamentos do contrato;
Cada equipamento registrado no contrato recebe um número de 
manutenção gerado pelo sistema.
8- O sistema registra as cotas de pagamento do contrato;
9- Fim do caso de uso.
D
en
iz
e 
P
im
en
ta
123
9- Fim do caso de uso.
Fluxos Alternativos
Cliente não localizado
No passo 2 do Fluxo Básico, caso o CNPJ informado não seja localizado:
1. O sistema exibe mensagem de cliente não localizado;
2. Retornar ao passo 1 do fluxo básico.
Data inválida
No passo 6 do Fluxo Básico, caso a data informada seja inválida:
1. O sistema emite mensagem informando que a data é inválida;
2. Retorna ao passo 5 do fluxo básico.
Dados obrigatórios não informados
No passo 6 do Fluxo Básico, caso a quantidade de cotas, data de início ou término não
forem informadas:
1. O sistema emite mensagem informando que o dado é obrigatório;
2. Retorna ao passo 5 do fluxo básico.
A pré-condição é opcional e descreve o estado que o sistema deve estar antes do
D
en
iz
e 
P
im
en
ta
124
A pré-condição é opcional e descreve o estado que o sistema deve estar antes do
início do caso de uso. Por exemplo: o arquivo de importação (a ser gerado por outro
sistema) deve estar gerado e disponível no caminho XYZ.
A pós-condição é opcional e descreve o estado que o sistema vai se encontrar ao
final da execução do caso de uso. Por exemplo: Ao final do caso de uso efetuar
compra o boleto deverá ser impresso.
D
en
iz
e 
P
im
en
ta
125
Depois da identificação e da descrição dos casos de uso o desenho do diagrama se torna simples,
pois os diagramas reais já estão definidos, as inclusões, extensões, generalizações e atores já foram
identificados.
D
en
iz
e 
P
im
en
ta
126
Devemos evitar passos e regras repetidas em ‘n’ casos de uso, para isso devemos procurar unificar e
separar as regras em um caso de uso a ser usado pelos outros.
Atores que têm a mesma interação com o sistema em um caso de uso devem ser generalizados (ver
generalização/especialização de atores).
D
en
iz
e 
P
im
en
ta
127
generalização/especialização de atores).
Dicas
•Procure sempre iniciar um caso de uso com uma ação do Ator;
•Um erro comum é achar que um caso de uso é uma atividade simples, um caso de uso é definido na
sua descrição – é um conjunto de passos;
D
en
iz
e 
P
im
en
ta
128
sua descrição – é um conjunto de passos;
•Evite palavras estrangeiras, lembre-se que o Diagrama de Caso de Uso serve para validação com o
usuário;
•Não desenhe associação entre atores, somente é permitida a generalização;
•Sempre que necessário use os pacotes para agrupar casos de uso;
•O Diagrama de Casos de Uso é uma excelente ferramenta para levantamento de requisitos, portanto
cuidado com o requisito falso arbitrário - funcionalidade que o sistema não precisa possuir para
atender ao seu propósito.
O nome do Caso de Uso deve ser uma frase indicando a ação que realiza.
Lembre-se que é com a prática que você irá aprender a fazer os diagramas.
D
en
iz
e 
P
im
en
ta
129
Lembre-se que é com a prática que você irá aprender a fazer os diagramas.
D
en
iz
e 
P
im
en
ta
130
Objetivos do Capítulo 4:
• Conhecer Componentes do Diagrama de Classes
D
en
iz
e 
P
im
en
ta
131
• Conhecer Componentes do Diagrama de Classes
• Construir um Diagrama de Classe
• Exercícios e Desafios
Neste tópico veremos:
• Conceitos
D
en
iz
e 
P
im
en
ta
132
• Conceitos
• Pacotes
• Associação
• Simples
• n-ária
• agregação
• composição
• generalização
• Classe Abstrata
• Classe Associativa
• Dependência
• Navegabilidade
• Papel
• Multiplicidade
• Visibilidade
• Geração de Código
D
en
iz
e 
P
im
en
ta
133
As classes podem ser exibidas com ou sem seus atributos e/ou métodos, o que é obrigatório é o
nome da classe.
D
en
iz
e 
P
im
en
ta
134
As classes de interface são exibidas como um pequeno círculo, estas especificam um conjunto de
operações ou serviços de uma classe ou componente. As interfaces ultrapassam as fronteiras lógica
e física. A mesma interface utilizada ou realizada por um componente será encontrada utilizada ou
realizada pelas classes que o componente implementa.
As classes exibidas no rodapé da página tem um estereótipo diferente e cada uma indica um tipo
diferente, a primeira é uma classe de controle, a segunda uma classe de fronteira e a terceira uma
classe de entidade.
Classe de Controle – são elementos que coordenam o comportamento do caso de uso, atuando
como uma interface entre fronteira e entidade.
Classe de Fronteira – modelam a interação entre o sistema e seu ambiente. Geralmente são
representadas por Interfaces Gráficas com o Usuário (GUI – Graphical User Interfaces), interfaces
com outros sistemas e interfaces com dispositivos.
Classe de Entidade – atuam de forma a armazenar e controlar informações no sistema.
D
en
iz
e 
P
im
en
ta
135
Os pacotes lógicos são agrupamentos de elementos de um modelo. No modelo de
D
en
iz
e 
P
im
en
ta
136
Os pacotes lógicos são agrupamentos de elementos de um modelo. No modelo de
análise, eles podem ser utilizados para formar grupos de classes com um tema
comum, pode ser útil para a divisão do trabalho na equipe de desenvolvimento.
Os pacotes da figura são usados para agrupar classes especializadas em relação a
esses aspectos.
Pacotes lógicos podem ter relações de dependência e pertinência entre si.
A associação binária é a mais comum nos diagramas de classe.
D
en
iz
e 
P
im
en
ta
137
Associação Simples - Unária ou Autorelacionamento
D
en
iz
e 
P
im
en
ta
138
Associação Simples - Unária ou Autorelacionamento
O exemplo acima indica que um Estado pode ter várias Cidades, a estrutura das duas
classes é idêntica, e uma outra forma mais simplista de desenhar seria em uma única
classe.
A associação n-ária representa o relacionamento com mais de duas classes. O
D
en
iz
e 
P
im
en
ta
139
A associação n-ária representa o relacionamento com mais de duas classes. O
exemplo acima está exibindo o relacionamento de avaliação de um funcionário em
um projeto, e esta avaliação é para um quesito. Então, por exemplo, o funcionário
João será avaliado em pontualidade no projeto A e terá uma nota de avaliação,
quando ele for trabalhar no Projeto B ele poderá ter outra nota de avaliação no
mesmo quesito. Os quesitos servem para pontuar os funcionários e são exemplo:
organização, limpeza, pontualidade, etc.
Neste exemplo a cauda a fuselagem e as asas do avião poderão ser utilizadas em outro avião. E se o
planador for excluído talvez as partes continuem existindo para um dia compor outro planador.
D
en
iz
e 
P
im
en
ta
140
As figuras mostram dois exemplos de agregação: um documento pode ter figuras e
D
en
iz
e 
P
im
en
ta
141
As figuras mostram dois exemplos de agregação: um documento pode ter figuras e
essas figuras podem ser utilizadas em outros documentos. Estes serão membros do
documento (todo-parte). Da mesma forma um projeto pode trabalhar com classes e
funcionários, que poderão ser utilizados por outro projeto, significa dizer que quando
chegar ao fim de um projeto, as classes e os funcionários poderão ser
reaproveitados.
A composição indica que a ‘parte’ não tem vida sem o ‘todo’. No exemplo o desenho do círculo será
composto de pontos e estes pontos somente poderão compor este círculo.
D
en
iz
e 
P
im
en
ta
142
D
en
iz
e 
P
im
en
ta
143
A composição impõe a cardinalidade de no mínimo 1. Os exemplos sugerem que as
D
en
iz
e 
P
im
en
ta
144
A composição impõe a cardinalidade de no mínimo 1. Os exemplos sugerem que as
páginas e a capa do livro compõem um livro e não podem compor outro objeto. Assim
como os quartos do hotel somente pertencerão a ele, não faz sentidoretirar o quarto
do cadastro e aproveitar para outro hotel (a parte não existe sem o todo).
D
en
iz
e 
P
im
en
ta
145
Generalização/Especialização
Relacionamento entre um elemento mais geral e um mais específico, também conhecido como
herança ou classificação. O elemento mais específico pode conter somente informação adicional
acerca do elemento mais geral.
D
en
iz
e 
P
im
en
ta
146
acerca do elemento mais geral.
Restrição
O uso das restrições é facultativo e serve para identificar o que está desenhado nas especializações
da super-classe. Pode ser que estejam todos os sub-tipos desenhados no diagrama, se fosse
colocado no exemplo acima poderíamos dizer que todas as contas são do tipo Fundo, Corrente ou
Poupança, neste caso a restrição seria ‘completo’. Caso tenha algum tipo de conta não mostrado no
desenho, como Conta Aplicação teríamos a restrição sendo ‘incompleto’.
Para as restrições de sobreposição temos que uma conta bancária pode se comportar como
poupança e como conta corrente, o dinheiro não fica parado nunca está no mínimo rendendo os juros
da poupança. Se o sistema não funcionar desta forma, ou seja, uma conta bancária é uma conta
poupança ou corrente ou fundo de ações temos a restrição de ‘disjunção’.
D
en
iz
e 
P
im
en
ta
147
Um exemplo raríssimo do uso de herança múltipla, o veículo anfíbio herda características (atributos e
métodos) tanto de ‘Terrestre’ quanto da classe ‘Marítimo’.
D
en
iz
e 
P
im
en
ta
148
Neste exemplo as restrições não estão definidas, o que dificulta um pouco o entendimento do
desenho.
Classe Abstrata
D
en
iz
e 
P
im
en
ta
149
Classe Abstrata
E uma classe que define o comportamento e atributos para subclasses. Não é
instanciada diretamente.
Uma classe abstrata pode conter operações abstratas. São operações cuja
implementação não é especificado na superclasse, somente sua assinatura.
As classes que herdarem essa operação deverão implementá-la, sendo a
implementação diferente para cada classe, ou mantê-la abstrata.
No desenho exibido nunca será instanciado um Veículo, ou será instanciado Carro ou
Barco.
D
en
iz
e 
P
im
en
ta
150
Os dados de emprego só existem se houver uma pessoa e uma empresa, se não
D
en
iz
e 
P
im
en
ta
151
Os dados de emprego só existem se houver uma pessoa e uma empresa, se não
houver associação entre esses elementos não existirá emprego.
A dependência entre as classes não indica inclusão dos atributos do relacionamento
D
en
iz
e 
P
im
en
ta
152
A dependência entre as classes não indica inclusão dos atributos do relacionamento
(não haverá chave estrangeira na geração do banco), essa associação indica
simplesmente que uma classe envia uma mensagem a outra. No exemplo acima o
objeto Pedido solicita uma informação do Produto, por exemplo seu preço. Nada
impede de haver associação entre as classes.
No exemplo acima uma operação de pedido faz referência à um objeto da classe Produto.
D
en
iz
e 
P
im
en
ta
153
Como no diagrama de classe não tem a representação de chave estrangeira, a navegabilidade indica
que a divulgação terá a chave estrangeira da entidade programa, pois todos os objetos de Divulgação
têm a responsabilidade de saber qual o Programa fazem referência.
D
en
iz
e 
P
im
en
ta
154
D
en
iz
e 
P
im
en
ta
155
A multiplicidade indica a quantidade de objetos da classe B pode estar associada a um
objeto da classe A em uma associação.
D
en
iz
e 
P
im
en
ta
156
objeto da classe A em uma associação.
No exemplo um cliente pode se relacionar com vários objetos da classe pedido, mas um
objeto da classe pedido só poderá estar associado a um objeto da classe cliente (no
mínimo um e no máximo um cliente).
Uma classe pode definir o tipo de acesso que seus membros (propriedades e métodos) permitirão às
demais partes do sistema.
D
en
iz
e 
P
im
en
ta
157
Em uma escala progressiva de “privacidade” dos membros, os tipos de acesso possíveis são público,
pacote, protegido e privado.
O padrão para criação de atributos é com visibilidade privada e os métodos como públicos, desta
forma utilizamos o conceito de encapsulamento (proteção dos dados pelos métodos da própria
classe).
A classe ‘Visibilidade’ exibida acima mostra o desenho da visibilidade na ferramenta CASE Rose.
Exemplo do diagrama de classes completo.
D
en
iz
e 
P
im
en
ta
158
O código acima foi gerado a partir do desenho da classe utilizando a ferramenta CASE JUDE
Community 1.4.3.
D
en
iz
e 
P
im
en
ta
159
O script gerado foi feito usando a ferramenta CASE Rational Rose 2003.
D
en
iz
e 
P
im
en
ta
160
Mais uma vez a UML não tem regra para a construção do diagrama, mas para facilitar sua construção
vamos seguir esses passos.
D
en
iz
e 
P
im
en
ta
161
1o. Passo: Identificar as Informações do Sistema (classes e atributos)
2o. Passo: Desenhar o diagrama
Agora o que foi identificado anteriormente entrará no desenho: como uma classe, ou atributo,
ou método, ou associação – ou não entra no modelo
3o. Passo: Relacionar todas as classes levantadas
Os objetos de uma determinada classe fazem referência a quais outros objetos?
4o. Passo: detalhar atributos e métodos – busque mais informações na documentação do sistema.
Atributos – Leia atentamente os casos de uso e identifique as necessidades de informação
5o. Passo: fazer batimento com as descrições dos casos de uso para verificar se há divergências.
Pode haver necessidade de criação de novos casos de uso.
Podem ser descobertas novas classes/atributos.
6o. Passo: identificar métodos.
Usar o diagrama de sequência para identificar os métodos das classes.
Dicas
• Faça o diagrama de classe pensando em conjuntos. Conjunto de clientes, serviços e o
relacionamento entre eles, aliás, o que é classe senão um conjunto de objetos?
D
en
iz
e 
P
im
en
ta
162
relacionamento entre eles, aliás, o que é classe senão um conjunto de objetos?
• O diagrama de classes pode ser feito com perspectivas diferentes.
• Cuidado com associações que tenham multiplicidades mínimas 1, em perspectiva de
implementação. Como no exemplo, o cliente tem no mínimo um serviço e o serviço tem no mínimo
um cliente associado.
D
en
iz
e 
P
im
en
ta
163
D
en
iz
e 
P
im
en
ta
164
Desafio
D
en
iz
e 
P
im
en
ta
165
Desafio
Precisamos modelar um esquema para registrar os gols do Campeonato Carioca de
forma que ao final do campeonato deve se informar qual o jogador que fez
mais/menos gols, qual a defesa mais vazada, o placar dos jogos e qual a colocação
dos times.
E para o Campeonato Brasileiro, como ficaria?
Lembre-se que o jogador pode mudar de time durante o campeonato.
( Este exercício é complementar, tente fazer e traga dúvidas )
D
en
iz
e 
P
im
en
ta
166
Objetivos do Capítulo 5:
•Visualizar a dinâmica do sistema através do Diagrama de Seqüência.
D
en
iz
e 
P
im
en
ta
167
•Visualizar a dinâmica do sistema através do Diagrama de Seqüência.
Neste tópico veremos:
• O que é Interação
D
en
iz
e 
P
im
en
ta
168
• O que é Interação
• O que é o Diagrama de Sequência
Interação é uma especificação comportamental que inclui uma seqüência de trocas de mensagem
entre um conjunto de objetos dentro de um contexto.
D
en
iz
e 
P
im
en
ta
169
Existem dois diagramas de Interação:
Diagrama de Seqüência – interação entre objetos ao longo do tempo, mostrando todos os objetos
que participam do contexto e a seqüência de mensagens trocadas.
Diagrama de Comunicação – representa a troca de mensagens entre um conjunto de objetos.
Os diagramas expressam informações similares, mas em formato diferente.
Um diagrama de seqüência dá ênfase à ordenação temporal das mensagens.
D
en
iz
e 
P
im
en
ta
170
Um diagrama de seqüência dá ênfase à ordenação temporal das mensagens.
É difícil representar lógicas de seleção e repetição sem prejudicar a legibilidade do
diagrama.
Os diagramas de interação são elaborados baseados na descrição de um fluxo (ou sub-fluxo) do caso
de uso juntamente com o diagrama de