Apostila Uml

Andrey Ricardo Pimentel
Projeto de Software Usando a UML

Apostila para Curso de Projeto de
Sistemas Orientado a Objetos
Usando a UML.
Setembro de 2015
Sumrio
AULA 1 PROCESSO DE SOFTWARE..........................................................................................5
1.1. Apresentao........................................................................................................................5
1.2. Introduo............................................................................................................................5
1.3. UML.....................................................................................................................................5
1.4. Crise do software.................................................................................................................6
1.5. Processo e Notao..............................................................................................................6
1.6. O poder da tecnologia de Objetos........................................................................................6
1.7. Anlise e projeto...................................................................................................................7
1.8. Desenvolvimento Iterativo e Incremental............................................................................7
1.9. Processo Unificado..............................................................................................................7
1.10. Atividade............................................................................................................................9
AULA 2 LEVANTAMENTO DE REQUISITOS..........................................................................10
2.1. Apresentao......................................................................................................................10
2.2. Levantamento de Requisitos..............................................................................................10
2.3. Atividade............................................................................................................................11
AULA 3 CASOS DE USO............................................................................................................13
3.1. Apresentao......................................................................................................................13
3.2. Comportamento do Sistema...............................................................................................13
3.3. Atores.................................................................................................................................13
3.4. Casos de Uso......................................................................................................................14
3.5. DIAGRAMAS DE CASO DE USO..................................................................................15
3.6. Atividade............................................................................................................................16
AULA 4 ESPECIFICAO DE CASOS DE USO......................................................................17
4.1. Apresentao......................................................................................................................17
4.2. A Especificao de um caso de Uso...................................................................................17
4.3. Atividade............................................................................................................................18
AULA 5 RELACIONAMENTOS ENTRE CASOS DE USO......................................................19
5.1. Apresentao......................................................................................................................19
5.2. Relacionamentos entre casos de uso..................................................................................19
5.3. Relacionamento <<include>>............................................................................................19
5.4. Relacionamento <<extend>>.............................................................................................19
5.5. Generalizaes...................................................................................................................20
5.6. Atividade............................................................................................................................21
AULA 6 IDENTIFICAO DE CLASSES USANDO O MVC..................................................22
6.1. Apresentao......................................................................................................................22
6.2. Descobrindo Classes..........................................................................................................22
6.3. Classes Entidade................................................................................................................22
6.4. Classes Limite....................................................................................................................22
6.5. Classes Controle.................................................................................................................23
6.6. Objetos e Classes no problema do Sistema de Matrcula (MATRI)..................................23
6.7. Atividade............................................................................................................................24
AULA 7 IDENTIFICAO DAS RESPONSABILIDADES DAS CLASSES ..........................25
7.1. Apresentao......................................................................................................................25
7.2. Cartes CRC......................................................................................................................25
7.3. Atividade............................................................................................................................26
AULA 8 IDENTIFICAO DE ATRIBUTOS E OPERAES DE UMA CLASSE................27
8.1. Apresentao......................................................................................................................27
3
8.2. O que uma operao?......................................................................................................27
8.3. O que um Atributo?.........................................................................................................29
8.4. Encapsulamento.................................................................................................................29
8.5. Atividade............................................................................................................................31
AULA 9 ASSOCIAES ENTRE CLASSES.............................................................................32
9.1. Apresentao......................................................................................................................32
9.2. Associaes........................................................................................................................32
9.3. Multiplicidade para Associaes........................................................................................33
9.4. Atividade............................................................................................................................34
AULA 10 AGREGAES E ASSOCIAES............................................................................36
10.1. Apresentao....................................................................................................................36
10.2. Agregao.........................................................................................................................36
10.3. Associaes Reflexivas....................................................................................................37
10.4. Classes de Ligao...........................................................................................................38
10.5. Encontrando Associaes e Agregaes..........................................................................39
10.6. Atividade..........................................................................................................................39
AULA 11 HERANA...................................................................................................................40
11.1. Apresentao....................................................................................................................40
11.2. Generalizao...................................................................................................................40
11.3. Herana Mltipla..............................................................................................................42
11.4. Atividade..........................................................................................................................43
AULA 12 INTERFACES E PACOTES.........................................................................................44
12.1. Apresentao....................................................................................................................44
12.2. Interfaces..........................................................................................................................44
12.3. Pacotes.............................................................................................................................45
12.4. Atividade..........................................................................................................................47
AULA 13 MODELO DE CLASSES, IMPLEMENTAO E MODELO RELACIONAL.........48
13.1. Apresentao....................................................................................................................48
13.2. Mapeando diagramas de Classe para cdigo em java......................................................48
13.3. Mapeando Classes para Modelo RElacional....................................................................50
13.4. Atividade..........................................................................................................................52
AULA 14 DIAGRAMAS DE INTERAO................................................................................53
14.1. Apresentao....................................................................................................................53
14.2. Diagramas de interao....................................................................................................53
14.3. Atividade..........................................................................................................................55
AULA 15 DIAGRAMAS DE SEQNCIA................................................................................56
15.1. Apresentao....................................................................................................................56
15.2. DESENVOLVIMENTO...................................................................................................56
15.3. Atividade..........................................................................................................................58
AULA 16 DIAGRAMAS DE ESTADOS.....................................................................................59
16.1. Apresentao....................................................................................................................59
16.2. Diagramas de Estados:.....................................................................................................59
16.3. Atividade..........................................................................................................................61
AULA 17 DIAGRAMAS DE COMPONENTES E DE IMPLANTAO..................................62
17.1. Apresentao....................................................................................................................62
17.2. Diagramas de Componentes.............................................................................................62
17.3. Diagramas de Implantao...............................................................................................63
17.4. Atividade..........................................................................................................................64
17.5. BIBLIOGRAFIA BSICA..............................................................................................64
AULA 1 PROCESSO DE SOFTWARE

1.1. APRESENTAO
Nesta aula sero apresentados e discutidos os conceitos de processo de desenvolvimento de
software, processo e notao, crise de software, anlise e projeto, desenvolvimento iterativo e
incremental e do Processo Unificado.
1.2. INTRODUO
O desenvolvimento orientado a objetos comeou em 1967 com a linguagem Simula-67 e desde
ento surgiram linguagens orientadas a objetos como Smalltalk e C++ entre outras. Nos anos
80 comearam a surgir metodologias de desenvolvimento orientadas a objetos para tirar
vantagens deste paradigma. Entre 1989 e 1994 surgiram quase 50 mtodos de
desenvolvimento orientados a objetos, fenmeno que foi chamado a guerra dos mtodos.
Entre as mais importantes estavam: o mtodo de G. Booch, a Object Modeling Technique
(OMT) de J. Rumbaugh, o mtodo de Shlaer e Mellor e o mtodo Objectory de I. Jacobson. I.
Jacobson introduziu a modelagem de casos de uso em 1987 e criou o primeiro processo de
desenvolvimento de software que utiliza casos de uso, chamado Objectory.
Cada mtodo possua uma notao prpria, o que gerou uma infinidade de tipos de diagramas
e notaes. Isto causava problemas de comunicao, treinamento de pessoal e portabilidade.
Um esforo de unificao comeou em 1994 quando J. Rumbaugh e, logo aps, I. Jacobson,
juntaram-se a G. Booch, na empresa Rational Software Corporation. O primeiro grande
resultado desse esforo foi a criao da Unified Modeling Language (UML), apresentada, na
sua verso 1.0, em 1997.
1.3. UML
A UML uma linguagem criada para visualizar, especificar, construir e documentar os artefatos
de um sistema de software. A UML adotada, desde 1997, como padro internacional pelo
OMG (Object Management Group). A UML prov um conjunto de diagramas e seus
componentes, todos com notao e comportamento (semntica) bem definidos. A UML
descreve 13 diagramas que so apresentados na figura abaixo.
1.4. CRISE DO SOFTWARE

No comeo os sistemas computacionais, tinham um custo de hardware muitas vezes maior que
o custo do software. O software tinha um carter "descartvel". Com a diminuio dos custos
do hardware e o aumento da complexidade do software, o custo do software comeou a ser
notado. Com isso o software deixou de ser descartvel. Aumentaram as preocupaes com
manuteno e evoluo dos softwares das empresas. Qualidade de software passou a ser
fundamental. Fazer software deixou de ser arte para ser engenharia. Surgiram processos de
desenvolvimento
1.5. PROCESSO E NOTAO

Processo de desenvolvimento de software pode ser definido como uma seqncia de etapas
para a construo do software. Por exemplo: Especificao de requisitos, anlise, projeto,
implementao, testes e implantao. Cada etapa tem objetivos bem definidos e gera um
conjunto de artefatos. Artefatos so os produtos gerados em cada etapa. Por exemplo: uma
etapa de anlise pode gerar os diagramas de caso de uso. Milestones so pontos do processo
onde os artefatos da etapa devem ser sincronizados e validados. Por exemplo: o diagrama de
classe deve ser sincronizado com o diagrama de seqncia. Notao a linguagem, grfica ou
textual, usada na elaborao dos artefatos. UML uma linguagem de modelagem.
1.6. O PODER DA TECNOLOGIA DE OBJETOS

Amento da Coeso entre os mdulo e diminuio do Acoplamento
Aumento da reutilizao de cdigo
Facilita a criao de bibliotecas de classe da empresa
Reduo do tempo de desenvolvimento dos projetos
6
Reduo do nmero de linhas de cdigo dos projetos
1.7. ANLISE E PROJETO

Anlise a descrio do problema a ser implementado Na anlise voc descreve os objetos e
classes que existem no problema, suas relaes e como eles se comportam durante os
eventos que existem no problema a ser implementado.
Projeto a descrio da soluo adotada na implementao. No projeto voc descreve como
os objetos que voc descreveu na anlise vo se comportar na soluo que voc criou.
Tambm so criados novos objetos, relaes e comportamentos para facilitar e melhorar o
sistema que vai ser construdo. No projeto, tambm descrita a arquitetura do sistema, sua
base da dados, entre outros. O limite entre anlise e projeto no muito bem definido.
1.8. DESENVOLVIMENTO ITERATIVO E INCREMENTAL

O desenvolvimento de sistemas seguindo o Processo Unificado :
Iterativo e incremental
Guiado por casos de uso (use cases)
Baseado na arquitetura do sistema
1.9. PROCESSO UNIFICADO

Outro grande resultado deste esforo de unificao de metodologias foi a criao, pela
Rational, de um processo de desenvolvimento que usa a UML em seus modelos, chamado
Processo Unificado. O Processo Unificado evoluiu do processo Rational Objectory, sendo
inicialmente chamado de Rational Unified Process (RUP). O Processo Unificado, apesar de no
ser um padro, amplamente adotado, sendo considerado como um modelo de processo de
desenvolvimento de software orientado a objetos.
O ciclo de vida de um sistema consiste de quatro fases, divididas em iteraes:
Concepo (define o escopo do projeto)

Elaborao (define os requisitos e a arquitetura)
Construo (desenvolve o sistema)
Transio (implanta o sistema)
Cada fase dividida em iteraes e cada iterao

planejada
realiza uma seqncia de atividades (de elicitao de requisitos, anlise e
projeto, implementao, etc.) distintas
geralmente resulta em uma verso executvel do sistema
avaliada segundo critrios de sucesso previamente definidos
O Processo Unificado guiado por casos de uso

Os casos de uso no servem apenas para definir os requisitos do sistema
Vrias atividades do Processo Unificado so guiadas pelos casos de uso:
planejamento das iteraes
criao e validao do modelo de projeto
planejamento da integrao do sistema
definio dos casos de teste
O Processo Unificado baseado na arquitetura do sistema
Arquitetura a viso geral do sistema em termos dos seus subsistemas e como estes se
relacionam
A arquitetura prototipada e definida logo nas primeiras iteraes
O desenvolvimento consiste em complementar a arquitetura
A arquitetura serve para definir a organizao da equipe de desenvolvimento e identificar
oportunidades de reuso
Fluxos de atividades
Atividades
passos
entradas e sadas
guias (de ferramentas ou no), templates
Responsveis (papel e perfil, no pessoa)
Artefatos
1.10. ATIVIDADE
1)
2)
3)
4)
5)
6)
Qual a diferena entre processo e notao?

Qual a diferena entre anlise e projeto de sistemas de software?
Cite algumas caractersticas da orientao a objetos.
Quais so as caractersticas do processo unificado?
Quais so e o que feito em cada uma das fases do processo unificado?
O que arquitetura do sistema?
AULA 2 LEVANTAMENTO DE REQUISITOS

2.1. APRESENTAO
Nesta aula sero apresentados e discutidos os conceitos de concepo e
especificao de um projeto de um sistema de software.
2.2. LEVANTAMENTO DE REQUISITOS

A atividade de levantamento de requisitos corresponde etapa de compreenso do problema.
O levantamento de requisitos fornece o mecanismo adequado para entender o que o cliente
deseja, analisando suas necessidade, e determinando se elas so possveis.
Dificuldades no levantamento de requisitos:
Problemas de escopo: o limite do sistema mal definido ou o cliente especifica detalhes

tcnicos que atrapalham a especificao.
Problemas de entendimento: Os clientes ou usurios no esto certos do que

necessrio para o sistema, no tm conhecimento sobre o domnio do problema, no
tm conhecimento sobre as limitaes tcnicas ou omitem detalhes tcnicos.
Problemas de volatilidade: Os requisitos mudam ao longo do tempo.
Durante o levantamento de requisitos a equipe tenta entender o domnio que deve ser
automatizado pelo sistema de software. O levantamento de requisitos um estudo exploratrio
das necessidades dos clientes, usurios e stakeholders (pessoas que so afetadas pelo
sistema).
O produto do levantamento de requisitos o documento de requisitos. Neste documento, os
requisitos so categorizados em: requisitos funcionais, requisitos no funcionais e requisitos
normativos.
Os requisitos funcionais representam as necessidades que o sistema deve prover. Por
exemplo:
O sistema deve permitir que o professor lance as notas de um aluno,
O sistema deve permitir que o cliente se cadastre para receber emails,
O sistema deve permitir que o gerente de vendas visualize o relatrio de vendas por
regio.
Os requisitos no funcionais representam caractersticas de qualidade que o sistema deve ter e

que no esto relacionadas com suas funcionalidades. Alguns tipos de requisitos funcionais
so:
Confiabilidade: tempo mdio entre falhas, recuperao de falhas ou nmero de erros
10
por milhares de linhas de cdigo.
Desempenho: tempo de resposta esperado para cada funcionalidade do sistema.
Portabilidade: restries sobre as plataformas de hardware ou software nas quais o

sistema ser implementado e o grau de portabilidade para outras plataformas.
Segurana: limitaes sobre segurana do sistema em relao a acessos no

autorizados.
Usabilidade: requisitos sobre facilidade de uso, idiomas, acessibilidades especiais,

necessidade ou no de treinamento.
Os requisitos normativos representam restries impostas sobre o desenvolvimento do sistema

como: adequaes a custos, prazos, plataforma, aspectos legais, alm de regras de negcio e
polticas de funcionamento.
O documento de requisitos serve como um termo de acordo entre o cliente e a equipe de
desenvolvedores. Ele servir de base para as atividades de desenvolvimento e para validaes
posteriores. O documento de requisitos estabelece o escopo do sistema, ou seja, o que faz
parte do sistema e o que no faz parte do sistema.
2.3. ATIVIDADE
1)Faa uma especificao de requisitos para o sistema descrito abaixo:
Sistema de Matrcula em cursos de Universidade
O processo de designao de professores para cursos e a matrcula de estudantes
uma experincia frustrante e que consome muito tempo.
Depois que os professores da Universidade decidem em quais cursos eles vo lecionar
no semestre, a Secretaria alimenta essa informao no sistema em computador. Um
relatrio batch impresso para os professores indicando em quais cursos eles
lecionaro. Um catlogo de cursos impresso e distribudo para os estudantes.
Atualmente, os alunos preenchem formulrios de matrcula que indicam suas escolhas de
cursos e retornam os formulrios para a Secretaria. A carga tpica de um estudante de
quatro cursos. Os funcionrios da Secretaria alimentam os dados dos formulrios dos
estudantes no sistema de computador no mainframe. Uma vez que o currculo para o
semestre foi alimentado no sistema, um job batch executado durante a noite para
inscrever os estudantes nos cursos. Na maioria das vezes os estudantes obtm sua
primeira escolha; entretanto, naqueles casos em que h um conflito, a Secretaria
conversa com cada estudante para obter escolhas adicionais. Quando todos os
estudantes tiverem sido inscritos com sucesso nos cursos, um relatrio dos currculos
dos estudantes encaminhado para eles para verificao. A maioria dos registros dos
estudantes so processados durante uma semana, mas alguns casos excepcionais
demoram at duas semanas para serem solucionados. Quando o perodo inicial de
matrcula concludo, os professores recebem uma lista de estudantes para cada curso
que devem lecionar.
O novo sistema vai permitir, no incio de cada semestre, que os estudantes possam
solicitar um catlogo de cursos contendo uma lista dos cursos oferecidos no semestre.
Informaes sobre cada curso, tais como professor, departamento e pr-requisitos
estaro includas para ajudar os estudantes a tomarem suas decises.
O novo sistema vai permitir aos estudantes selecionarem quatro dos cursos oferecidos
para o semestre. Alm disso, cada estudante indicar duas escolhas alternativas para
caso um curso oferecido seja cancelado ou no tenha vagas suficientes. Nenhum curso
poder ter mais de dez ou menos do que trs alunos. Um curso com menos de trs
alunos ser cancelado. Uma vez concludo o processo de matrcula de um estudante, o
11
sistema de matrcula envia informao para o sistema de faturamento de forma que o
aluno possa receber as faturas para o semestre.
Professores devem poder acessar o sistema online para indicar quais cursos eles
lecionaro e para ver que estudantes se inscreveram em suas ofertas de curso. Para
cada semestre, h um perodo de tempo no qual os estudantes podem mudar sua grade
horria. Os estudantes devem poder acessar o sistema durante este perodo para
adicionar ou retirar cursos.
12
AULA 3 CASOS DE USO

3.1. APRESENTAO
Nesta aula sero discutidos de comportamento do sistema, como definir casos de uso e
atores e como utilizar o diagrama de casos de uso para mostrar os atores, os casos de uso
e suas interaes.
3.2. COMPORTAMENTO DO SISTEMA

O comportamento do sistema em desenvolvimento, que o que funcionalmente deve ser
fornecido pelo sistema, documentado em um Modelo de Caso de Uso que ilustra as funes
pretendidas do sistema (casos de uso), suas vizinhanas (atores) e relacionamentos entre os
casos de uso e atores (diagramas de casos de uso). O papel mais importante de um modelo de
caso de uso o de comunicao. Ele prov um veculo usado pelo cliente ou usurios finais e
os desenvolvedores, para discutir a funcionalidade e o comportamento do sistema.
O modelo de caso de uso iniciado na Fase de Concepo com a identificao dos atores e
casos de uso principais do sistema. O modelo ento amadurecido na Fase de Elaborao informao mais detalhada adicionada aos casos de uso identificados, e casos de uso
adicionais so introduzidos medida que forem necessrios.
3.3. ATORES
Atores no so parte do sistema - eles representam algo ou algum que deve interagir com o
sistema. Um ator pode:
Somente fornecer informaes para o sistema
Somente receber informaes do sistema
Fornecer e receber informaes para e do sistema
Tipicamente, estes atores so encontrados na definio do problema e em conversas com

clientes e especialistas no domnio do problema. As seguintes perguntas podem ser usadas
para auxiliar na identificao dos atores de um sistema:
Quem est interessado numa certa necessidade?
Onde na organizao o sistema usado?
Quem se beneficiar do uso do sistema?
Quem suprir o sistema com esta informao, usar esta informao e remover esta
informao?
Quem dar o suporte e manter o sistema?
O sistema usa um recurso externo?
Uma pessoa desempenha diferentes papis?
Vrias pessoas desempenham o mesmo papel?
O sistema interage com um sistema legado?
Na UML, um ator representado como um homem palito, como mostrado na figura abaixo.
13
Notao UML para um Ator

O que constitui um bom ator?
Devemos tomar cuidado quando identificamos um ator para o sistema. Esta identificao feita
de uma maneira iterativa - a primeira lista de atores para um sistema raramente constitui a lista
final. Por exemplo: um novo estudante um ator diferente de um estudante que est
retornando? Suponha que voc inicialmente responda afirmativamente a esta questo. O
prximo passo identificar como o ator interage com o sistema. Se o novo estudante usa o
sistema de forma diferente de um estudante que retorna, eles so atores diferentes. Se eles
usam o sistema da mesma forma, eles so o mesmo ator.
Atores no Sistema de Matrcula - MATRI
Respondendo s perguntas anteriores, identificaremos diversos atores. Um deles
Professor.
Documentao de Atores
Uma breve descrio para cada ator deveria ser adicionada ao modelo. A descrio
deveria identificar o papel que o ator desempenha na interao com o sistema. Exemplo:
Professor - uma pessoa que certificada para lecionar na universidade
3.4. CASOS DE USO

Casos de Uso modelam um dilogo entre um ator e o sistema. Eles representam a
funcionalidade fornecida pelo sistema; isto , que capacidades sero providas para o ator pelo
sistema. A coleo de casos de uso para um sistema constitui todos os caminhos definidos nos
quais o sistema pode ser usado. A definio formal para um caso de uso :
Um caso de uso uma seqncia de transaes executadas por um sistema, que produz
um resultado mensurvel de valores para um ator em particular.
As seguintes perguntas devem ser usadas para auxiliar na identificao dos casos de
uso para um sistema:
Quais so as tarefas de cada ator?

Algum ator criar, armazenar, mudar, remover ou ler informao do sistema?
Que casos de uso criaro, armazenaro, mudaro, removero ou lero esta informao?
Algum ator precisar informar o sistema a respeito de mudanas externas repentinas?
Algum ator necessita ser informado a respeito de certas ocorrncias no sistema?
Que casos de uso suportaro ou mantero o sistema?
Todas as necessidades funcionais podem ser executadas pelos dos casos de uso?
Na UML, um caso de uso representado como uma figura oval, como mostrado na figura
abaixo.
Notao para caso de uso
14
O que Constitui um Bom Caso de Uso?
Ao longo dos anos tem havido muita discusso sobre o que um bom caso de uso. Um
problema freqentemente encontrado o nvel de detalhe dos casos de uso. Isto , quo
grande (ou quo pequeno) ele deveria ser? No h uma resposta certa. Uma boa regra
aplicvel :
Um caso de uso tipicamente representa uma pea maior de funcionalidade que est
completa do incio ao fim. Um caso de uso deve fornecer algo de valor para um ator.
Outro problema como empacotar funcionalidade que diferente mas que
aparentemente deveria permanecer junta. Por exemplo, a Secretaria deve incluir cursos,
eliminar cursos e modificar cursos. Trs casos de uso ou um nico? Aqui novamente, deveria
ser feito um caso de uso - a manuteno de currculo, j que a funcionalidade iniciada pelo
mesmo ator (a Secretaria) e trata com as mesmas entidades no sistema (o currculo).
3.5. DIAGRAMAS DE CASO DE USO

Um diagrama de caso de uso uma viso grfica de alguns ou todos os atores, casos de usos
e seus relacionamentos identificados para um sistema. Cada sistema normalmente tem um
Diagrama de Caso de Uso principal, o qual uma representao da fronteira do sistema
(atores) e a maior funcionalidade fornecida pelo sistema (casos de uso). Outros diagramas de
casos de uso podem ser criados quando necessrio. Alguns exemplos so:
um diagrama que mostre todos os casos de uso para um ator selecionado;

um diagrama mostrando todos os casos de uso a serem implementados em uma iterao;
um diagrama mostrando um caso de uso e todos os seus relacionamentos com outros
casos de uso e atores.
Exemplo de diagrama de casos de uso

Casos de Uso no Sistema Matrcula - MATRI
As seguintes necessidades devem ser tratadas pelo sistema:
O ator estudante precisa usar o sistema para registrar-se em cursos
Depois que o processo de seleo estiver completo, o sistema de Faturamento deve ser
suprido com informaes de fatura
O ator Professor precisa usar o sistema para selecionar os cursos para lecionar por um
semestre e deve estar habilitado a receber uma lista de cursos do sistema
A Secretaria responsvel pela gerao do catlogo de curso para um semestre e, pela
15
manuteno de todas as informaes a respeito do currculo, dos estudantes e dos
professores.
Baseado nestas necessidades, diversos casos de usos podem ser identificados, como o
"Matricula em um curso".
3.6. ATIVIDADE
Baseando-se na descrio dos sistema de matrculas (MATRI), descrito acima, desenvolva as
seguintes atividades:
1)Encontre os casos de uso, os atores, e os relacionamentos entre os casos de uso e
atores (coloque tudo no diagrama de casos de uso)
2)Faa uma breve descrio para os atores e os casos de uso que forem identificados
(mximo 2 frases)
16
AULA 4 ESPECIFICAO DE CASOS DE USO

4.1. APRESENTAO
Nesta aula ser apresenta e discutida a especificao dos caso de uso
4.2. A ESPECIFICAO DE UM CASO DE USO

Cada caso de uso tambm documentado com uma Especificao de Caso de Uso. Uma
Especificao dos casos de uso um documento que tem por objeto descrever o
comportamento do casos de uso. Este comportamento descrito basicamente atravs do fluxo
principal de eventos.
O fluxo de eventos para um caso de uso uma descrio dos eventos necessrios para atingir
o comportamento esperado do caso de uso. O fluxo de eventos escrito em termos do que o
sistema deveria fazer, no como o sistema o faz. Isto , escrito na linguagem do domnio, no
em termos de implementao. Especificao de Caso de Uso deveria incluir:
Quando e como o caso de uso inicia e termina

Que interao o caso de uso tem com os atores
Que dados so necessrios para o caso de uso
A seqncia normal de eventos para o caso de uso
A Especificao de Caso de Uso criada tipicamente na Fase de Elaborao numa maneira

iterativa. Inicialmente, somente uma breve descrio dos passos necessrios para executar o
fluxo normal do caso de uso (isto , que funcionalidade fornecida pelo caso de uso) escrita.
medida que a anlise progride, os passos so preenchidos a fim de se adicionar mais
detalhes. Finalmente, os fluxos de exceo so adicionados ao caso de uso.
Cada projeto deveria usar um template padro para a criao da documentao do fluxo de
eventos. til o seguinte template:
1Nome do Caso de Uso
2Breve descrio
3Fluxo de eventos
3.1Fluxo bsico
3.1.1< Primeiro evento do fluxo bsico>
3.1.2< Primeiro evento do fluxo bsico>
3.2Fluxos alternativos
3.2.1< Primeiro fluxo alternativo>
3.2.2< Outro fluxo alternativo>
4Requisitos Especiais
4.1< primeiro requisito especial >
5Pr-condies
5.1< pr-condio um >
6Ps-condies
6.1< ps-condio um >
7Pontos de Extenso
Uma amostra do documento de Fluxo de Eventos para o Caso de Uso Selecionar Cursos para
17
Lecionar mostrada a seguir:
Especificao do Caso de Uso Cadastrar Usurio
1 Nome do Caso de Uso
Cadastrar Usurio
2 Breve descrio
Cadastra um usurio no sistema, com todos os dados, inclusive uma fotografia.
3 Fluxo de eventos
3.1Fluxo bsico
3.1.1 O caso de uso comea quando o ator seleciona a opo cadastrar
usurio. O sistema mostra a tela de cadastro de usurio com os seguintes
campos em branco: nome, "endereo", RG, CPF, telefone, email.
3.1.2 O ator preenche os campos e seleciona a opo cadastrar. O sistema
mostra uma tela para fazer o upload da fotografia.
3.1.3 O ator indica o nome e o caminho do arquivo com a sua fotografia e
seleciona importar. O sistema mostra uma tela com todos os dados e a
fotografia do cliente.
3.1.4 O ator seleciona a opo cadastrar e o sistema cadastra o novo
usurio, mostra uma mensagem de sucesso na operao e mostra a tela
inicial do sistema.
3.2 Fluxos alternativos
3.2.1< Primeiro fluxo alternativo>
Caso o ator no tenha preenchido um dos campos dos dados do usurio, o
sistema avisa o erro e retorna para a tela de cadastro dos dados do usurio com
os dados j preenchidos.
3.2.2< segundo fluxo alternativo>
Caso o usurio no importe um arquivo com a foto, o sistema mostra a tela de
confirmao sem a fotografia e uma mensagem de aviso.
3.2.3< Terceiro fluxo alternativo>
Caso o ator tenha cadastrado um usurio com o mesmo CPF, o sistema avisa o
erro e retorna para a tela de cadastro dos dados do usurio com os dados j
preenchidos.
4 Requisitos Especiais
No se aplica
5 Pr-condies
< pr-condio um >
O ator deve estar logado no sistema. Nenhum outro usurio com o mesmo CPF
dever ter sido cadastrado.
6 Ps-condies
< ps-condio um >
Um usurio novo cadastrado.
7 Pontos de Extenso
No se aplica.
4.3. ATIVIDADE
1)Baseando-se na descrio dos sistema de matrculas (MATRI), descrito nas unidades
anteriores, selecione 3 dos casos de uso identificados e faa a especificao de casos de uso
para cada um deles
18
AULA 5 RELACIONAMENTOS ENTRE CASOS

DE USO
5.1. APRESENTAO
Nesta aula ser apresentado e discutido como utilizar o diagrama de casos de uso
para mostrar os atores, os casos de uso e suas interaes.
5.2. RELACIONAMENTOS ENTRE CASOS DE USO

Um relacionamento de associao pode existir entre um ator e um caso de uso. Esse tipo de
associao normalmente chamado como uma Associao de Comunicao, desde que ela
represente uma comunicao entre um ator e um caso de uso. Uma associao
representada como uma linha que liga os elementos a serem relacionados. A navegao em
somente uma direo pode ser representada pela adio de uma seta que indica a direo na
linha da associao. No pode existir no modelo um caso de uso iniciado por dois atores.
Existem somente 3 tipos de relacionamentos entre os casos de uso: <<include>>, <<extend>>
e a generalizao.
5.3. RELACIONAMENTO <<INCLUDE>>

Muitos casos de uso podem compartilhar pedaos de pequenas funcionalidades. Esta
funcionalidade colocada em separado em outro caso de uso ao invs de ser documentada
em cada caso de uso que precisa dela. Relacionamentos de <<include>> so criados entre um
novo caso de uso e qualquer outro caso de uso que utilize esta funcionalidade. Por exemplo,
os casos de uso remover cliente e alterar cliente precisam pesquisar o cliente a ser removido
ou alterado. Essa funcionalidade pode ser colocada em um caso de uso chamado de
pesquisar cliente, o qual ento includo por outros casos de uso quando necessrio.
Figura relacionamento <<include>>
5.4. RELACIONAMENTO <<EXTEND>>

Um relacionamento de "extend" usado para mostrar: comportamento opcional,
comportamento que somente executado sobre determinadas condies, como o disparo de
19
um alarme, muitos diferentes caminhos que podem ser executados de acordo com uma
seleo feita por um ator. Por exemplo, um caso de uso que monitora o fluxo de pacotes em
uma esteira de transporte pode acionar um caso de uso de Disparo de Alarme se os pacotes
empilharem. At este momento, nenhum <<extend>> foi identificado para o Sistema de
Matrcula (MATRI).
Figura relacionamento <<extend>>

Um relacionamento extend de um caso de uso A para um caso de uso B indica que o caso de
uso B pode ser aumentado (de acordo com condies especificadas na extenso) por um
comportamanto especificado pelo caso de uso A. O comportamento inserido no local definido
pelo ponto de extenso em B o qual referenciado pelo relacionamento extend. No caso de
uso A, o comportamento a ser inserido deve ser marcado com um rtulo.
5.5. GENERALIZAES
Uma generalizao entre um caso de uso C e um caso de uso D indica que C uma
especializao de D. Este relacionamento representado por uma seta de generalizao
partindo de D para C.
Pode ser representado, tambm, um tipo de relacionamento entre atores. Este relacionamento
o de generalizao. Uma generalizao de um ator A para um ator B indica que A pode se
comunicar com os mesmos casos de uso que B.
Siga a seguinte regra:
Utilize <<extend>> quando estiver descrevendo uma variao do comportamento normal de

um caso de uso;
Utilize <<include>> para permitir a reutilizao de um determinado comportamento de um
caso de uso por outros casos de uso.
20
5.6. ATIVIDADE
Baseando-se na descrio dos sistema de matrculas (MATRI), descrito na unidade anterior,
desenvolva as seguintes atividades:
1)Encontre os casos de uso, os atores, e os relacionamentos entre os casos de uso e
atores (coloque tudo no diagrama de casos de uso)
21
AULA 6 IDENTIFICAO DE CLASSES

USANDO O MVC
6.1. APRESENTAO
Nesta aula ser visto como identificar Classes de um sistema usando o Padro Modelo-VisoControlador.
6.2. DESCOBRINDO CLASSES

No existe um livro de receitas que ensine como descobrir classes. O RUP (Rational Unified
Process) sugere que as classes sejam descobertas no desenvolvimento do sistema,
procurando as classes de limite, controle e entidade. Estes trs esteretipos ajustam-se, ponto
de vista model-view-controler e permitem ao analista particionar o sistema separando a viso
do domnio do controle necessrio pelo sistema.
Tendo como base, que a anlise e o projeto do processo so interativos, a lista de classes ir
mudar ao longo do tempo. O conjunto inicial de classes provavelmente no ser o conjunto de
classes que sero efetivamente implementadas. Para ns, o termo candidato para uma classe
freqentemente usado para descrever o primeiro conjunto de classes descobertas para o
sistema.
6.3. CLASSES ENTIDADE

Uma classe entidade modela informao e comportamento associado que geralmente tem uma
vida longa. Este tipo de classe pode refletir uma entidade do mundo real, ou ela pode ser
necessria para executar uma tarefa interna do sistema. Elas so tipicamente independentes
do meio em que esto; isso , elas no preciso saber como as classes que esto no limite se
comunicam com o sistema. Muitas vezes, elas so aplicaes independentes, isso significa que
muitas delas podero ser utilizadas por mais de uma sistema.
O primeiro passo examinar as responsabilidades documentadas no fluxo de eventos para o
caso de uso identificado (i.e., o que o sistema deve fazer). Classes entidade so normalmente
utilizadas pelo sistema para definir alguma responsabilidade. Os nomes e as frases usadas
para descrever a responsabilidade podem ser um bom ponto de partida. A lista inicial de nomes
deve ser filtrada, pois ela pode conter nomes que esto fora do domnio do problema, nomes
que so somente expresso de linguagem, nomes que so redundantes, e nomes que so
descries da estrutura da classe.
Classes entidade so normalmente encontradas na Fase de Elaborao. Elas so
freqentemente chamadas de classes de domnio, desde que elas usualmente tratam com
abstraes de entidades do mundo real.
6.4. CLASSES LIMITE

Classes Limite cuidam da comunicao entre meio com o qual o sistema interage e o sistema
propriamente dito. Elas fornecem a interface para um usurio ou para um outro sistema (i.e., a
interface para um ator). Elas constituem a parte do sistema que dependem do meio em que
elas esto. Classes limite so utilizadas para modelar as interfaces do sistema.
Cada par ator/cenrio examinado para descobrir as classes limite. As classes limites
escolhidas na Fase de Elaborao do desenvolvimento so tipicamente de alto nvel. Por
22
exemplo, voc pode modelar uma janela mas no modela cada caixa de dilogo e botes.
Neste ponto, voc est documentando os requerimentos da interface com o usurio, no
implementando a interface.
Os requerimentos das interfaces com o usurio tendem a ser muito vagos - os termos
amigveis e flexveis so muito utilizados. Mas amigvel, tem significados diferentes para
pessoas diferentes. Neste caso as tcnicas de prototipagem podem ser muito teis. O cliente
pode dar uma olhada e sentir o sistema e realmente entender o que o termo amigvel significa.
O "o que" ento compreendido assim como a estrutura e o comportamento da Classe Limite.
Durante o projeto, essas classes so refinadas para levar em considerao os mecanismos da
interface escolhida.
Classes Limite so tambm adicionadas para facilitar a comunicao com outros sistemas.
Durante o projeto, estas classes so refinadas para levar em considerao o protocolo de
comunicao escolhido.
6.5. CLASSES CONTROLE

Classes Controle modelam uma seqncia de comportamento especfico a um ou mais casos
de uso. Classes Controle coordenam os eventos necessrios para a realizao do
comportamento especificado em um caso de uso. Voc pode pensar que uma Classe Controle
como "rodando" ou "executando" o caso de uso - ela representa a dinmica do caso de uso.
Estas classes normalmente so classes dependentes da aplicao.
Logo nos primeiros estgios da fase de Elaborao, uma Classe Controle adicionada para
cada par Ator/Caso de Uso. A Classe Controle responsvel pelo fluxo de eventos do caso de
uso.
O uso de Classes Controle muito subjetivo. Muitos autores sentem que o uso de Classes
Controle resultam no comportamento sendo separado dos dados. Isso pode acontecer se a
Classe Controle no foi escolhida prudentemente. Se uma Classe Controle est fazendo mais
do estabelecer uma seqncia, ento ela est fazendo coisas demais. Por exemplo, no sistema
de matrculas, um estudante seleciona um curso ofertado, se o curso ofertado est disponvel,
o estudante matriculado nele. Quem sabe como matricular um estudante - a Classe Controle
ou a OfertaCurso? A resposta correta , OfertaCurso. A Classe Controle sabe quando o
estudante deveria ser matriculado, o curso ofertado sabe como matricular o estudante. Uma
pssima Classe Controle no saberia s quando matricular o estudante mas como matricular o
estudante.
A adio de uma Classe Controle para cada par Ator/Caso de Uso somente um comeo enquanto a anlise e o projeto continuam, as Classes Controle podem ser eliminadas,
explodidas ou combinadas.
6.6. OBJETOS E CLASSES NO PROBLEMA DO SISTEMA DE

MATRCULA (MATRI)
Vamos dar uma olhada no cenrio Adicionando uma Oferta de Curso para Lecionar, o qual
um dos subfluxos do caso de uso Selecionar Cursos para Ministrar (ver apostila anterior, sobre
Comportamento do Sistema). A principal definio especificada neste cenrio a habilidade do
professor selecionar um curso ofertado para lecionar em um dado semestre.
Embora ns estejamos olhando este processo passo a passo, muitos desses passos podem
ocorrer ao mesmo tempo no mundo real.
Identificando Classes Limite
23
Este caso de uso interage somente com o ator Professor. A ao especificada neste cenrio
somente uma das definidas no caso de uso (o caso de uso tambm afirma que o Professor
pode modificar, excluir, rever e imprimir a seleo). Isto significa que alguma coisa no sistema
deve prover ao Professor a capacidade de selecionar a sua opo. Uma classe contm todas
as opes disponveis ao Professor como est registrado no caso de uso, para satisfazer a
especificao feita. Esta classe chamada OpesCursoProfessor. Adicionalmente podemos
identificar uma classe que faa a adio de um novo Curso Ofertado para o Professor. Esta
classe chamada AdicionaOfertaCurso.
Identificando Classes Entidade
Este cenrio est relacionado com Cursos, com as Ofertas de Curso e com o Relacionamento
do Curso com o Professor. Ns podemos identificar trs classes entidade: Curso, OfertaCurso
e InformaoProfessor.
Identificando Classes de Controle
Iremos adicionar uma classe de controle para manusear o fluxo de eventos para o caso de uso.
Esta classe chamada ControleCursoProfessor. As classes identificadas foram adicionadas ao
modelo.
6.7. ATIVIDADE
Baseando-se no modelo de Caso de Uso abaixo, tente levantar as classes para o sistema de
Matrcula (MATRI).
24
AULA 7 IDENTIFICAO DAS

RESPONSABILIDADES DAS CLASSES
7.1. APRESENTAO
Nesta aula ser visto como identificar as classes de um sistema usando os cartes CRC
7.2. CARTES CRC

Uma forma para modelar um problema em classes e objetos a forma proposta no artigo "A
Laboratory For Teaching Object-Oriented Thinking", por ser simples e fcil de ser aplicada. So
os Cartes Classe-Responsabilidade-Colaboradores (CRC). Os cartes CRC foram usados por
algumas metodologias de desenvolvimento como a apresentada por Wirfs-Brock, Wilkerson e
Wiener no livro "Designing Object-Oriented Software".
baseada nos trs atributos principais de um objeto na fase de projeto: nome da classe, suas
responsabilidades e seus colaboradores.
O nome da classe deve descrever o objeto no contexto geral do ambiente. Deve-se
tomar um certo cuidado e gastar um pouco de tempo para escolher o conjunto certo de
palavras para descrever o objeto.
As responsabilidades devem identificar os problemas a serem resolvidos e no as
solues. Identificando-se os problemas fica fcil escolher entre as solues possveis.
Novamente deve-se tomar cuidado com o conjunto de palavras usadas. As frases
devem ser curtas e concisas.
Os colaboradores de um objeto so os objetos para os quais este ir enviar mensagens
a fim de satisfazer as suas responsabilidades.
Para facilitar a modelagem, Cunningham inventou os cartes Classe-ResponsabilidadesColaboradores (CRC). Esses cartes servem, tambm, como meio de documentao do
projeto. Os cartes CRC so pedaos de papel grosso medindo 10x15cm e contm o nome da
classe, as responsabilidades e os colaboradores, como na figura.
25
A disposio espacial dos cartes importante. Quando duas classes so mtuas
colaboradoras, seus cartes devem ser colocados levemente sobrepostos. Quando uma classe
colaboradora de outras classes (a classe usada pelas outras), seu carto deve ficar abaixo
dos cartes das outras classes. Se h uma relao de herana, dever haver uma
sobreposio quase completa dos cartes. A disposio dos cartes importante, pois em
projetos ainda incompletos possvel notar a localizao de uma classe antes da mesma ter
sido projetada.
Para achar as classes, sua responsabilidades e seus colaboradores deve-se seguir as
seguintes etapas:
1. Definio das classes e das estruturas de dados de cada classe;
2. Definio das responsabilidades de cada classe;
3. Definio dos colaboradores de cada classe;
O que so classes e como defini-las
Num problema a ser resolvido, as diversas classes podem ser identificadas como as entidades
que existem no problema, por exemplo, aluno, turma, professor, etc... So classes, tambm, as
estruturas de dados utilizadas para resolver o problema, bem como os dispositivos(fsicos e
virtuais) a serem acessados. Por exemplo: interface, arquivo, controlador de tempo, etc...
O que so responsabilidades e como defini-las
As responsabilidades so definidas como sendo os problemas que as classes devem resolver.
So, a grosso modo, as funes das classes. Por exemplo: colocar um registro no arquivo, dar
presena ao aluno, cobrar mensalidade, etc... As responsabilidades so os problemas a serem
resolvidos. A maneira de resolve-los vo ser os mtodos das classes(implementao).
O que so colaboradores e como defini-los
Os colaboradores so as classes que ajudam uma classe a resolver as suas
responsabilidades. So as classes que vo prestar servios classe. A classe que est sendo
analisada solicita servios a outras classes e estas, por sua vez, prestam estes servios,
ajudando a resolver os problemas.
7.3. ATIVIDADE
1. modelar o problema de controle de uma pizzaria de entrega em domiclio. O cliente
pede uma ou mais pizzas, refrigerantes ou cervejas. O atendente anota o pedido no
sistema. Cada pizza pode ser (mdia, grande ou enorme). Cada pizza pode ter no
mximo 3 sabores. O atendente anota os dados do cilente e a forma de pagamento
(inclusive o troco necessrio). O atendente anota o cdigo do entregador e o tempo de
entrega. O gerente cadastra os sabores de pizzas existentes, os dados dos
entregadores e visualizaos relatrios de vendas(por sabor, regio) e tempo de entrega.
26
AULA 8 IDENTIFICAO DE ATRIBUTOS E

OPERAES DE UMA CLASSE
8.1. APRESENTAO
Nesta aula ser visto como identificar os atributos e as operaes das classes do sistema
8.2. ORIENTAO A OBJETOS (OO)

uma forma de entender e representar sistemas complexos como estruturas hierrquicas de
objetos correlatos.
Objeto
Um objeto uma construo de software que encapsula estado e comportamento,

atravs de propriedades (atributos) e operaes (mtodos);
Estado de um objeto: composto por suas propriedade e seus respectivos valores;
Comportamento: a maneira como o objeto reage quando o seu estado alterado ou

quando uma mensagem recebida.
CLASSES
Conjunto de objetos similares.
Estrutura de dados similares (propriedades);
27
Comportamento similar (operaes)
Um objeto uma instncia de uma classe;
Objetos de uma mesma classe diferenciam-se pelos valores de suas propriedades e de

seus identificadores nicos.
Troca de Mensagens
Mecanismo atravs do qual os objetos se comunicam, invocando as operaes

desejadas;
Um objeto (Emissor) envia uma mensagem a outro (Receptor) que executar uma
tarefa;
Operaes (mtodos) so invocados atravs de mensagens.
Encapsulamento
No mostre as cartas de seu baralho
Objetivo: Ocultar do mundo externo ao objeto, os detalhes de implementao e

restringir o acesso aos propriedades e mtodos.
Vantagens:
Segurana no acesso ao objeto;
Melhor consistncia no estado interno, pois evita alteraes incorretas de

valores das propriedades.
28
8.3. O QUE UMA OPERAO?
Uma classe incorpora um conjunto de responsabilidades que definem o

comportamento dos objetos na classe
As responsabilidades de uma classe so executadas por suas operaes
No necessariamente um mapeamento um-para-um
Responsabilidade da classe Produto -- fornecer preo
Operaes para esta responsabilidade
Buscar informao de um banco de dados
Calcular o preo
Uma operao um servio que pode ser requisitado por um objeto para obter
um dado comportamento
Operaes Dependem do Domnio
Liste todas as operaes relevantes ao domnio do problema

As operaes de uma classe Pessoa sero diferentes dependendo de 'quem
est perguntando'
Perspectiva do Bancrio
Perspectiva do Mdico
receber emprstimo
anexar conta
receber linhaDeCrdito
examinar
tomarRemdio
irParaHospital
receberConta
Nomeando Operaes
As operaes devem ser nomeadas para indicar seus resultados, no os passos

por trs da operao. Exemplos:
calcularSaldo()
Nome pobre
Indica que o saldo deve ser calculado - isto uma deciso de
implementao/otimizao
obterSaldo()
Bem nomeado
Indica apenas o resultado
Nomeando Operaes
As operaes devem ser nomeadas do ponto de vista do fornecedor e no do
cliente
Em um posto de gasolina, a gasolina vem da bomba
Uma operao para que a bomba tenha esta responsabilidade -- como
29
deveria ser chamada?
Bons nomes -- distribuir(), darGasolina()
Nome ruim -- receberGasolina()
A bomba d a gasolina -- ela no recebe a gasolina
O que uma Operao Primitiva?
Uma operao primitiva uma operao que pode ser implementada apenas
usando o que intrnseco, interno a classe
Todas as operaes de uma classe so tipicamente primitivas
Exemplos:
Adicione um item a um conjunto -- operao primitiva
Adicione quatro itens a um conjunto -- no primitiva
Pode ser implementada com mltiplas chamadas a operao adicione um item a um conjunto
Assinatura da Operao
A assinatura da operao consiste de :
Lista de argumentos opcional
Classe de retorno
Durante a anlise NO OBRIGATRIO preencher a assinatura de operaes
Esta informao pode ser adiada para fase de projeto
Mostrando Operaes
Operaes so mostradas no terceiro compartimento da classe
Descobrindo Operaes nos Diagramas de Interao

As mensagens mostradas nos diagramas de seqncia e/ou colaborao so
usualmente operaes da classe receptora
As mensagens so traduzidas em operaes e adicionadas ao diagrama de classes
GerenteDe
Matricula
um curso
GerenteDe
Matricula
get prerequisito
getPrerequisito():ListaDeCurso
8.4. O QUE UM ATRIBUTO?
um curso
Um atributo uma caracterstica de uma classe
30
Atributos no tem comportamento -- eles no so objetos

Nomes de atributos so substantivos simples ou frases substantivas
Os nomes devem ser nicos dentro da classe
Cada atributo deve ter uma definio clara e concisa
Bons atributos para a classe Estudante:
Nome -- primeiro e ltimo nome
CampoEstudo -- principal campo de estudo
Atributos ruins -- cursosSelecionados
Isto um relacionamento e no um atributo
Mostrando Atributos
Atributos so mostrados no segundo compartimento da classe
Como Descobrir Atributos?

Muitos atributos so descobertos no texto da descrio do fluxo de eventos para
os casos de uso
Procure substantivos que no foram considerados bons candidatos para
classes
Outros so descobertos quando a definio da classe criada
Experincia no domnio tambm pode prover bons atributos
Exibindo Atributos e Operaes
Atributos e/ou operaes podem ser mostrados dentro de uma classe

Diagramas de classes adicionais podem ser criados para exibir atributos e
operaes
Os relacionamentos no costumam ser exibidos nestes diagramas de
classes
8.5. ENCAPSULAMENTO
Uma maneira de visualizar uma classe a que consiste de duas partes: a

interface e a implementao
A interface pode ser vista e usada por outros objetos (clientes)
A implementao escondida dos clientes
Esconder os detalhes da implementao de um objeto chamado
encapsulamento ou "information hiding"
Encapsulamento oferece dois tipos de proteo. Protege:
O estado interno de um objeto de ser corrompido por seus clientes
O cdigo cliente de mudanas na implementao dos objetos
Exemplo: Encapsulamento
31
Valores de atributos podem ser alterados
apenas pelas operaes providas pelo
objeto
mudeNomeProprietrio
depsito
nmeroConta
nomeBanco
nomeProprietrio
saldo
saque
getSaldo
So criadas operaes para mostrar os

valores de atributos requisitados por
clientes
O estado do objeto no pode ser modificado
diretamente por clientes
geraTransao
Benefcios do Encapsulamento
O cdigo cliente pode usar a interface para uma operao
O cdigo cliente no pode tirar vantagem da implementao de uma operao
A implementao pode mudar, por exemplo, para:
Corrigir um erro (bug)
Aumentar performance
Refletir uma mudana no plano de ao
O cdigo cliente no ser afetado pelas mudanas na implementao, assim

reduzindo o "efeito ondulao" (ripple effect) no qual uma correo em uma
operao fora correes correspondentes numa operao cliente, o qual por
sua vez, causa mudanas em um cliente do cliente...
A manuteno mais fcil e menos custosa
32
8.6. ATIVIDADE
1) modelar o problema de controle de uma pizzaria de entrega em domiclio. O cliente pede

uma ou mais pizzas. O atendente anota o pedido no sistema. Cada pizza pode ser (mdia,
grande ou enorme). Cada pizza tem apenas 1 (um sabor). O atendente anota os dados do
cilente e o pedido. A tela acima a usada para anotar o pedido.
33
AULA 9 ASSOCIAES ENTRE CLASSES

9.1. APRESENTAO
Nesta aula iremos abordar e exercitar o que so associaes entre classes e como us-las.
Iremos abordar aspectos como: associaes, nomes, papeis, multiplicidade, qualificadores,
navegabilidade e associaes reflexivas.
9.2. ASSOCIAES
A Necessidade de Relacionamentos
Todos os sistemas abrangem muitas classes e objetos
Objetos atuam no comportamento de um sistema colaborando entre eles
A Colaborao realizada atravs de relacionamentos
Ocorrem dois tipos importantes de relacionamentos durante a anlise
Associao e
Generalizao
Associaes
Uma associao uma conexo semntica bi-direcional entre classes
Isto implica na existncia de uma ligao (link) entre os objetos das classes associadas
Associaes so representadas no diagrama de classes por uma linha ligando as classes
associadas. Em um link os dados podem fluir em ambas as direes
Navegao
Uma associao um relacionamento bi-direcional
Dada uma instncia de GerentelDeMatrcula h um objeto Curso associado
Dada uma instncia de Curso h um objeto OficialDeMatrcula associado
Dando Nomes s Associaes

Para tornar seu significado mais claro, uma associao pode receber um nome
O nome representado como uma etiqueta (label) colocada ao longo da linha de associao,
no meio da linha, entre os cones das classes
Um nome de associao geralmente um verbo ou uma frase verbal
34
Definindo Papis
Um papel denota o propsito ou capacidade em que uma classe se associa com outra
Nomes de papis so tipicamente substantivos ou frases substantivas
Um nome de papel colocado ao longo da linha de associao, prximo da classe
referenciada
Um ou ambos os lados da associao podem ter nomes de papis
Associaes Mltiplas
Pode existir mais de uma associao entre duas classes
Se houver mais de uma associao entre duas classes, elas DEVEM ser nomeadas
Associaes mltiplas devem ser questionadas
9.3. MULTIPLICIDADE PARA ASSOCIAES

Multiplicidade o nmero de instncias de uma classe relacionada a UMA instncia da outra
classe
Para cada associao, devem ser tomadas duas decises de multiplicidade : uma para cada
lado da associao
Por exemplo, na conexo entre Pessoa, atuando no papel de professor, e Curso
Para cada instncia de Pessoa, muitos (i.e., zero ou mais) Cursos podem ser
ministrados
Para cada instncia de Curso, exatamente uma Pessoa o professor
35
Muitos
Exatamente Um
Zero or mais
Um ou Mais
Zero or um
Intervalo Especfico
*
1
0..*
1..*
0..1
2..4
Indicadores de Multiplicidade
Cada lado de uma associao contem um indicador de multiplicidade
Indica o nmero de objetos que participam no relacionamento
Exemplo: Multiplicidade
Decises de Multiplicidade expem muitas suposies, antes ocultas, sobre o problema sendo
modelado
Um professor pode estar indisponvel?
Um curso pode ter dois professores?
Qualificadores
Um qualificador um atributo de uma classe que pode ser usado para reduzir a multiplicidade
da associao
Departamento
Professor
EmpregadoID
1
Restries
Uma restrio expressa alguma condio que deve ser preservada

Uma restrio mostrada entre chaves.
9.4. ATIVIDADE
1. Faa um Diagrama de Classes do subsistema de Operao de Trem, sem utilizar herana e
considerando o seguinte:
Um trem pode ser de carga, passageiros ou ambos e pode ser movido por um ou mais
vages com fora motriz.
Um vago com fora motriz possui um determinado tipo de motor, com potncia
especfica.
O trem de passageiros pode possuir vrias portas por vago, que devem abrir e fechar
automaticamente, ao chegar na estao e antes de partir, respectivamente.
A capacidade de passageiros de um trem deve estar registrada em quantidade, e a
capacidade de cada vago de carga em metros cbicos.
36
Cada trem possui uma rota que deve ser seguida durante a viagem.
A data de incio de trabalho de cada vago deve ser registrada.
A velocidade do trem deve ser controlada automaticamente. Ao arrancar ele dever
estar ganhando velocidade, e ao logo da viagem dever manter outra velocidade e
estando a uma determinada distncia da estao dever reduzir a velocidade para
parar.
Os segmentos de trilho iniciam e terminam em um determinado quilmetro.
A localizao do trem numa ferrovia deve ser possvel.
37
AULA 10 AGREGAES E ASSOCIAES

10.1. APRESENTAO
Nesta aula iremos abordar e exercitar o que so agregaes entre classes e como us-las.
Iremos abordar aspectos como: agregaes, composies, associaes reflexivas, classes de
ligao e as diferenas entre associaes e agregaes.
10.2. AGREGAO
Agregao uma forma especializada de associao na qual o todo est relacionado a sua(s)
parte(s). Agregao conhecida como parte-de ou relacionamento de contedo. Uma
agregao representada como uma associao com um losango perto da classe que denota
a agregao (todo). A multiplicidade representada da mesma maneira que nas outras
associaes
<<limite>>
FormularioDeMatrcula
<<limite>>
FormularioDeHorrio
1
Testes de Agregao
A frase parte de usada para descrever o relacionamento?
Uma Porta parte de um Carro
Algumas operaes no todo so automaticamente aplicadas nas partes?
Mova o Carro, Mova a Porta
Alguns valores de atributos so propagados do todo para algumas ou todas as suas
partes?
O Carro azul, a Porta azul
H uma assimetria intrnseca no relacionamento onde uma classe subordinada a
outra?
Uma Porta parte de um Carro, um Carro NO parte de uma Porta
Tipos de Agregao
Existem dois tipos de agregao:
Agregao propriamente dita, ou tambm chamada agregao por referncia
Conhecida como relacionamento tem-um(a)
Envolve partes componentes que existem independentemente de seus
agregados
Exemplo: A rea X da empresa tem os empregados A, B e C
Area
Empregado
1
0..*
Visualizando o conceito de agregao, o agregado contm uma referncia aos seus

componentes
38
Composio, ou tambm chamada agregao por valor

Conhecida como relacionamento contm um(a)
Especifica que as partes componentes s tem um dono
Especifica que o composto possui suas partes componentes
Especifica que as partes componentes existem, ou vivem e morrem com seu
composto proprietrio
Exemplo: Um automvel possui de 2 a 5 portas
Automovel
Porta
1
2..5
Visualizando o conceito de composio, o composto contm os seus componentes
Associao ou Agregao ?
Se dois objetos so estreitamente ligados por um relacionamento parte-todo
O relacionamento uma agregao
Se dois objetos so usualmente considerados independentes, mesmo que eles estejam
freqentemente ligados
O relacionamento uma associao
10.3. ASSOCIAES REFLEXIVAS
Em uma associao reflexiva, objetos de uma mesma classe so relacionados

Indica que mltiplos objetos da mesma classe colaboram juntos de algum modo
Curso
0..*
Pr-requisito
0..*
Um curso pode ter muitos pr-requisitos

Um curso pode ser um pr-requisito para muitos outros cursos
Agregados tambm podem ser reflexivos

Problema clssico de lista de materiais
Isto indica um relacionamento recursivo
ParteDeProduto
0..*
Um objeto ParteDeProduto composto de zero ou mais objetos ParteDeProduto
39
10.4. CLASSES DE LIGAO

Ns desejamos rastrear todas as notas que um estudante teve em todos os cursos que fez
O relacionamento entre Estudante e Curso um relacionamento muitos-para-muitos
Onde colocamos o atributo nota?
Estudante
0..*
Curso
3-10
O atributo nota no pode ser colocado em Curso porque h (potencialmente) muitas ligaes
para muitos objetos Estudante
O atributo nota no pode ser colocado na classe Estudante porque h (potencialmente) muitas
ligaes para muitos objetos Curso
Portanto, o atributo realmente pertence a uma ligao particular Estudante-Curso
Uma classe de ligao usada para conter a informao da ligao
Desenhando Classes de Ligao
Crie uma classe de ligao usando um cone de classe
Conecte a classe na linha da associao usando uma linha tracejada
A classe de ligao pode incluir propriedades mltiplas da associao
Apenas uma classe de ligao permitida por associao
Estudante
1..*
Curso
3-10
Boletim
Classes de Ligao e Multiplicidade

Classes de Ligao so freqentemente usadas em associaes muitos-para-muitos
Se a multiplicidade em um os lados de uma associao para-um
O atributo pode ser colocado dentro da classe no lado muitos do relacionamento
OU
Uma classe de ligao ainda pode ser usada
40
Estudante
nota
Curso
3-10
Estudante
Curso
3-10
nota
10.5. ENCONTRANDO ASSOCIAES E AGREGAES

Associao ou Agregao ?
FormularioDeMatrcula e FormularioDeHorario so estreitamente ligados
-- uma FormularioDeHorario parte daFormularioDeMatricula
<<limite>>
<<limite>>
FormularioDeMatrcula
FormularioDeHorario
1
FormularioDeHorario e
GerenteDeMatrcula
so independentes
1
1
1
GerenteDeMatrcula
10.6. ATIVIDADE
Faa um Diagrama de Classes para um problema com as seguintes caractersticas:
Existem medicamentos aprovados para uso clnico, pelo rgo governamental

apropriado.
Esses medicamentos so fabricados por firmas capacitadas para tanto, que atribuem
aos medicamentos um nome de medicamento do fabricante, alm do nome genrico
que os mesmos j possuem.
Nem todos os medicamentos podem ser fabricados por todas as empresas.
A data em que uma empresa foi outorgada para fabricar um medicamento indica o incio
da permisso para fabricao.
Cada fabricante pode produzir muitos lotes do medicamento, que tem data de
fabricao e validade.
O modelo deve estar apto a responder por quem um medicamento (ex.: cido acetilsaliclico) foi fabricado, em que lote(s) e com que nmero de permisso.
41
AULA 11 HERANA
11.1. APRESENTAO
Nesta aula iremos abordar e exercitar o que so generalizaes entre classes e como us-las.
Iremos abordar aspectos como: generalizao, hierarquia, notao, subclasse, superclasse,
especializao, e herana mltipla.
11.2. GENERALIZAO
Generalizao define um relacionamento entre classes onde uma classe compartilha a
estrutura e/ou comportamento de uma ou mais classes
Generalizao define uma hierarquia de abstraes na qual uma subclasse herda de
uma ou mais superclasses
Com herana simples, a subclasse herda de apenas uma superclasse
Com herana mltipla, a subclasse herda de mais de uma superclasse
Generalizao um relacionamento " um" ou "tipo de"
Desenhando uma Hierarquia de Herana

InfoRegistroUsurio
Superclasse
Relacionamento de Generalizao
InfoEstudante
Subclasse
Consideraes sobre generalizao

Como um relacionamento de generalizao no se refere a objetos individuais
O relacionamento no nomeado
Multiplicidade no tem sentido
Teoricamente, no h limite no nmero de nveis em uma hierarquia
Na prtica, os nveis precisam ser bem limitados
Hierarquias tpicas em C++ tem 3 a 5 nveis
Hierarquias em Smalltalk podem ser um pouco maiores
O que Herdado?
Uma subclasse herda de seus pais:
Atributos
Operaes
Relacionamentos
Uma subclasse pode:
Incluir atributos, operaes e relacionamentos adicionais
Redefinir as operaes herdadas (use com cautela!)
42
Herdando Atributos
Atributos so definidos no nvel mais alto da hierarquia de herana na qual eles so
aplicveis
Subclasses de uma classe herdam todos os atributos
Cada subclasse pode adicionar novos atributos
VeculoTerrestre
peso
nmeroLicena
Carro
Um caminho tem trs atributos:

peso
nmeroLicena
tonelagem
Caminho
tonelagem
Herdando Operaes
Operaes so definidas no nvel mais alto da hierarquia de herana na qual elas so
aplicveis
Subclasses de uma classe herdam todas as operaes
Cada subclasse pode aumentar ou redefinir operaes herdadas
Herdando Relacionamentos
Relacionamentos tambm so herdados e devem ser definidos no nvel mais alto da
hierarquia de herana na qual eles so aplicveis
Subclasses de uma classe herdam todos os relacionamentos
Cada subclasse pode tambm possuir relacionamentos adicionais
Generalizao de Classes
Generalizao proporciona a capacidade de criar superclasses que reunem estrutura
e/ou comportamento comum a vrias subclasses
Procedimento de generalizao
Identificar similaridades de estrutura/comportamento entre vrias classes
Criar uma superclasse para reunir a estrutura/comportamento comum
As classes originais passam a ser subclasses da nova superclasse
Superclasses so mais abstratas que suas subclasses
Exemplo de Generalizao
43
Bens
ContaBancria
Poupana
ContaCorrente
Seguro
Imveis
Aes
Bnus
Especializao de Classes
A especializao proporciona a capacidade de criar subclasses que representam
refinamentos nos quais a estrutura e/ou comportamento da superclasse so
adicionados ou modificados
Procedimento de Especializao
Notar que algumas instncias apresentam estrutura ou comportamento especializado
Criar subclasses para agrupar instncias de acordo com sua especializao
Subclasses so menos abstratas que suas superclasses
Hierarquias de Herana
Tanto generalizao quanto especializao so usadas no desenvolvimento de uma
hierarquia de herana
Durante a anlise, so estabelecidas hierarquias de herana entre abstraes chaves
(i.e., classes) se necessrio
Durante o projeto, as hierarquias de herana so refinadas para:
Aumentar reutilizao
Incorporar classes de implementao
Incorporar bibliotecas de classes disponveis
11.3. HERANA MLTIPLA

CoisaQueVoa
Animal
herana
mltipla
Avio
Helicptero
Pssaro
Lobo
Cavalo
Conceitos de Herana Mltipla
Conceitualmente necessrio para modelar o mundo real de forma precisa

Na prtica, isto pode gerar dificuldades na implementao
Nem todas as linguagens de programao orientadas a objetos suportam herana
mltipla diretamente
44
Cada ambiente/linguagem de programao escolhe maneiras de resolver estas dificuldades
Encontrando generalizao
importante avaliar todas as classes para encontrar possveis generalizaes
Procure por comportamento comum (operaes) e estado comum (atributos) nas
classes
Tcnica de adio
Adicione novas operaes/atributos na(s) subclasse(s)
Tcnica de modificao
Redefina operaes
Deve ser feito com cuidado para no alterar a semntica
Generalizao versus Agregao
Generalizao e agregao so geralmente confundidas
Generalizao representa um relacionamento "-um" ou "tipo-de"
Agregao representa um relacionamento "tem-um"
Generalizao
Palavra chave um
Relaciona objetos da
mesma superclasse
Representado por uma seta
Agregao
Palavra chave tem um
Relaciona objetos de classes diferentes
Representado por um losango
11.4. ATIVIDADE
Construa um Diagrama de Classes inicial para controlar emprstimos e reservas de
publicaes em uma biblioteca, considerando o seguinte:
A biblioteca pertence a uma empresa e somente os funcionrios da empresa esto

aptos a reservar ou emprestar publicaes.
A biblioteca tem acesso aos dados cadastrais dos funcionrios.
Uma publicao pode ser um livro, uma revista, um jornal, etc. A biblioteca pode possuir
vrios exemplares de uma mesma publicao.
Qualquer tipo de publicao pode ser emprestada ou reservada.
No h nmero limite de reservas por publicao.
Quando uma publicao for devolvida e para ela existirem reservas, o primeiro da fila
deve ser avisado.
A reserva expira um dia aps o aviso da disponibilidade da publicao ao interessado.
Caso o mesmo no venha a emprestar a publicao, ela ser considerada disponvel e
o prximo da fila deve ser avisado.
Uma reserva pode ser excluda a pedido do usurio.
Emprstimos de publicaes no devolvidas 2 dias aps o prazo sero consideradas
irregulares e um funcionrio da biblioteca deve resgatar o livro.
45
AULA 12 INTERFACES E PACOTES

12.1. APRESENTAO
Nesta aula iremos abordar e exercitar o que so Intefaces e pacotes.
12.2. INTERFACES
Uma Interface uma coleo de operaes utilizadas para especificar um servio de uma
classe ou componente.
As interfaces so empregadas para visualizar, especificar, construir e documentar a coeso
interna do sistema.
Escolhendo as interfaces corretas, voc pode selecionar componentes padro, bibliotecas e
frameworks para a implementao destas interfaces, sem precisar constru-las. medida que
descobrir implementaes melhores, voc pode substituir as antigas sem perturbar seus
usurios
Declarando a interface, voc pode estabelecer o comportamento desejado de uma abstrao
independente de qualquer implementao desta interface.
Notao:
Relacionamentos:
A relao entre Alvo e Observador uma relao de dependncia, enquanto que a relao
entre Observador e Rastreador uma relao de realizao. Uma relao de realizao indica
que a classe Rastreador implementa a interface Observador.
46
12.3. PACOTES
Se um sistema contm somente poucas classes, voc pode gerenci-las facilmente. Mas, a
maioria dos sistemas so compostos por muitas classes, neste caso ento necessrio um
mecanismo para agrupa-las, para obter uma melhor facilidade de uso, manuteno e
reutilizao. Neste caso onde o conceito de packages til. Um package na viso lgica de
um modelo uma coleo de packages e/ou classes relacionados. Agrupando classes em
packages, ns podemos ter uma viso de mais alto nvel do modelo (i.e., os packages), ou
podemos nos aprofundar no modelo, dando uma olhada no que est contido no package.
Cada package contm uma interface que implementada por um conjunto de classes pblicas
- aquelas classes com as quais os outros packages falam. O resto das classes em um package
so classes de implementao - classes, que no se comunicam com as classes de outros
packages.
Se um sistema complexo, packages podem ser criados logo no incio da Fase de Elaborao
para facilitar a comunicao. Para sistemas simples, as classes descobertas na anlise podem
ser agrupadas em um package - o prprio sistema. No decorrer do processo de anlise e
projeto, o conceito de package ser utilizado para agrupar as classes que so necessrias para
realizar as decises arquiteturais tomadas para o sistema.
Na UML, packages so representados como pastas.
Criando Packages
O prximo passo agrupar as classes em packages. Neste ponto, ns temos identificadas seis
classes: Curso, OfertaCurso, InformaoProfessor, OpesCursoProfessor,
AdicionaOfertaCurso e ControleCursoProfessor. Elas caem em trs grupos lgicos - coisas
nicas para a universidade, coisas que contm informaes sobre pessoas e coisas que so
parte das interfaces com os atores. Ns podemos identificar os packages: Interfaces,
ServicoUniversidade e InformacaoPessoa. As classes so realocadas para os packages
identificados. Os packages com suas classes so mostrados abaixo.
O principal diagrama de classes na viso lgica do modelo normalmente uma figura dos
packages do sistema. Cada package tambm tem o seu prprio diagrama principal, o qual
normalmente mostra as classes pblicas do package. Outros diagramas podem ser criados de
acordo com a necessidade. Alguns dos usos tpicos de outros diagramas so:
Viso de todas as classes de implementao do package;
Viso da estrutura e comportamento de uma ou mais classes;
Viso da hierarquia de herana.
Um exemplo do diagrama de classe principal do sistema de matrcula mostrado na figura
abaixo.
47
O diagrama de classe principal (Main) para o package ServicoUniversidade mostrado na

figura. Note que a classe OfertaCurso no est no diagrama. Esta uma classe de
implementao e foi decidido no mostr-la no diagrama principal do package.
Quando mais packages e classes so adicionados ao modelo, diagramas adicionais podem ser
criados quando necessrios.
Um package na viso lgica do modelo uma coleo packages e/ou classes relacionadas.
Agrupando classes em packages, ns podemos olhar ao mais alto nvel de viso do modelo
(i.e., os packages), ou ns podemos ir fundo no modelo olhando o que est contido dentro dos
packages.
Relacionamentos entre Pacotes
Pacotes so relacionados entre si usando um relacionamento de dependncia
Se uma classe em um pacote conversa com uma classe em outro pacote ento um
relacionamento de dependncia adicionado ao nvel de pacote
Diagramas de Cenrio e diagramas de classe so avaliados para determinar relacionamentos
entre pacotes
48
Interfaces
Controle
Artefatos
Universitrios
12.4. ATIVIDADE
Construa um Diagrama de Classes inicial para controlar emprstimos e reservas de

deve ser avisado.
49
AULA 13 MODELO DE CLASSES,

IMPLEMENTAO E MODELO RELACIONAL
13.1. APRESENTAO
Nesta aula iremos abordar e exercitar que o modelo de classes tem com a codificao em java
e com o modelo relacional.
13.2. MAPEANDO DIAGRAMAS DE CLASSE PARA CDIGO

EM JAVA
Implementar um sistema baseado em um modelo, depende primeiro do paradigma
usado na construo do modelo e no paradigma da linguagem escolhida para o
desenvolvimento. possvel construir um sistema a partir de um modelo orientado a objetos
usando uma linguagem estruturada e vice-versa. Mas, para isso teremos que fazer diversas
adaptaes.
No nosso caso iremos apresentar a implementao usando a linguagem Java.
Implementando classes simples:
Este o cdigo em java para a classe descrita pelo diagrama acima.

classProduto{
privateStringnome;
privateStringdescricao;
protecteddoublepreco;
publicvoidsetNome(StringumNome){}
publicStringgetNome(){returnnull;}
staticpublicVectorgetAll(){returnnull;}
}
Implementando associaes:
Para implementar uma associao precisamos colocar um atributo de referncia. Em qual
classe ser colocado este atributo, depende da multiplicidade da associao. Estes atributos
ou classes que so criados para este fim no devem ser colocados no diagrama de classes.
No caso 1 para muitos podemos colocar todo o objeto com multiplicidade 1 como atributo do
objeto com multiplicidade muitos:
50
publicclassItemdePedido
{
privateintquantidade;
privateEspecificacaoProdutoproduto;
}
ou, se o objeto tiver um cdigo gerado automaticamente na base de dados, apenas o cdigo do
objeto com multiplicidade 1 como atributo do objeto com multiplicidade muitos:
publicclassItemDePedido
{
privateintquantidade;
privateintcodProduto;
}
No caso de muitos para muitos:
Existe a necessidade da criao de uma classe para a associao:

publicclassMatricula
{
privateAlunoaluno;
privateTurmaturma;
}
Agregaes:
Uma agregao pode ser implementada usando um objeto para colees do Java como
java.util.Vector. Este objeto colocado como atributo da classe que agrega e contm objetos
da classe agregada;
publicclassPedido
{
privateDatedata;
privateStringcodPedido;
privatebooleancompleto;
51
privateVectortodosItens;
}
13.3. MAPEANDO CLASSES PARA MODELO RELACIONAL

Associao 1:N
Define-se uma tabela por classe acrescentando-se os atributos identificadores de cada classe
respectiva tabela. A figura abaixo ilustra a situao tratada:
Associao M:N
Define-se uma tabela por classe acrescentando-se os atributos identificadores de cada classe
respectiva tabela. Neste caso, necessria a criao de uma tabela auxiliar para indicar as
associaes entre os objetos. A figura abaixo ilustra a situao tratada:
Associao muitos para muitos
Associao um para muitos

Herana
Identificam-se quatro formas para o mapeamento das heranas. So elas:
52
Uma tabela por classe
Uma nica tabela
Uso de tabelas apenas para classes

especficas
Mista
53
13.4. ATIVIDADE
1) Construa um Diagrama de Classes inicial para controlar emprstimos e reservas de

deve ser avisado.
2) Crie o cdigo Java para trs das classes identificadas acima, que possuas relacionamento.
3) Crie o script SQL de criao dessas 3 classes.
54
AULA 14 DIAGRAMAS DE INTERAO

14.1. APRESENTAO
Nesta aula vamos apresentar os diagramas de seqncia e comunicao
14.2. DIAGRAMAS DE INTERAO

Os diagramas de Interao, compostos por: Diagramas de Seqncia e Diagramas de
Comunicao.
DIAGRAMA DE SEQNCIA:
O prximo passo identificar os objetos envolvidos nele, formando assim diagramas de

seqncia.
Mostra como os objetos se interagem atravs do tempo em um determinado cenrio.
As linhas verticais so objetos e no classes.
Podem existir eventos simultneos.
Podem existir eventos reflexivos.
PASSOS:
1.
2.
3.
4.
Identifique os "principais objetivos do seu sistema".

Descreva o cenrio.
Identifique os objeto origem e o objeto destino.
Construa o Diagrama.
Exemplo de um diagrama seqncia na UML:

s d e x e m p lo 0 1
:I n t U s u a r i o
:C t r lC a d C lie n t e
:C lie n t e
U s u a r io
C lie n t e : = m o s t r a T e la C a d C lie n t e ( )
f o r m u l r io c lie n t e
d a d o s C lie n t e
s e tN o m e ( n o m e )
s e tC N P J ( c n p j)
Os diagramas de seqncia podem representar vrios aspectos da interao entre 2 objetos:

a) Dois tipos de mensagens:
mensagens sncronas (esperam um retorno):
chamadas de mtodo;
chamadas de criao de objetos;
chamadas de destruio de objetos.
retorno de mensagem;
55
mensagens assncronas (no esperam um retorno)
b)Comandos de deciso (if, if else):
podem ser representados na mensagem ou atravs de um fragmento combinado (UML
2.0)
:C la s s e A
:C la s s e B
:C la s s e C
n u m e r o : = v e r if ic a N o m e ( n o m e )
[ n u m e r o = 0 ] : c o d ig o N u lo : = g e r a c o d ig o N u lo ( )
a lt
[n u m e ro < = 3 ]
s e tN o m e (n o m e )
c o d ig o : = c a lc u la C o d ig o ( n o m e )
n o m e := g e tN o m e ( )
[n u m e ro > 3 ]
c) Repeties (loops):
representados direto na mensagem ou atravs de fragmentos combinados (UML 2.0)
d) Chamadas a outros diagramas de seqncia (UML 2.0)
:C t r lP e d id o
c r ia r ( )
:T ic k e t B D
:C o n t a
:P e d i d o
r e c u p e r a r s t a t u s d e c lie n t e e x is t e n t e
lo o p
[ p r o x im o it e m ]
re s e rv a r(c o n ta g e m ,d a te )
a lt
[ d is p o n v e l]
[ n o d is p o n v e l]
a d ic io n a r ( a s s e n t o s )
r e je it a r ( )
d e b it a r ( c u s t o )
Alguns aspectos dependentes da linguagem para expressar a mensagem, podem ser

omitidos na fase de anlise.
56
e)Podemos especificar objetos que so criados em tempo de execuo do sistema.
f) Podemos tambm expressar mensagens reflexivas.
g) Tambm podemos expressar noo de tempo de transmisso de mensagem.
DIAGRAMA DE COMUNICAO:
- Vieram a substituir os diagramas de colaborao na UML 2.0
- Mesmo comportamento do diagrama de rastreamento de eventos, porm com uma outra
viso.
- Algumas ferramentas CASE fazem a transformao automtica.
- a mesma coisa "escrita" de outra forma.
14.3. ATIVIDADE
construa o diagrama de seqncia para os seguintes enunciados:
2.2. Fluxo de Eventos
2.2.1. Fluxo bsico
1. O caso de uso comea quando o funcionrio seleciona a opo manter dados do ponto. O
sistema mostra uma lista com os ltimos registro de ponto e as opes "alterar " e "inserir".
2. Se o funcionrio seleciona a opo "incluir", o sub-fluxo incluir ponto executado; Se o
funcionrio seleciona a opo "alterar", o sub-fluxo alterar ponto executado;
2.2.2. Subfluxo inserir ponto
1. O sistema mostra uma tela com os campos do ponto, que so: "hora de incio", "hora de
trmino", "data", "nmero do projeto".
2. O funcionrio preenche os campos. O sistema mostra os dados preenchidos e pede
confirmao
3. O funcionrio confirma a incluso. O sistema mostra uma mensagem de sucesso.
2.2.3. Subfluxo alterar ponto
1. O sistema mostra uma lista com os ltimos registro de ponto.
2. O funcionrio seleciona o ponto a ser alterado. O sistema mostra uma tela com os dados do
ponto, que so: "hora de incio", "hora de trmino", "data", "nmero do projeto".
3. O funcionrio altera os dados necessrios. O sistema mostra os dados alterados e pede
confirmao
4. O funcionrio confirma a alterao. O sistema mostra uma mensagem de sucesso.
57
AULA 15 DIAGRAMAS DE SEQNCIA

15.1. APRESENTAO
Construindo e implementando diagramas de sequncia em java com jsp e servlet de controle
15.2. DESENVOLVIMENTO
Dicas para a identificao de classes que participam do caso de uso:
Para cada ator que participa do caso de uso, identifique pelo menos uma classe <<limite>>;
Para cada caso de uso identifique uma classes <<controle>>;
Para cada grupo de informaes manipulado no caso de uso, identifique uma classe <<entidade>>.
Para o caso de uso cadastrar produto identificamos as seguintes classes:

<<limite>>
IntAdministrador
Repositorio
<<controle>>
CtlrCadastrarProduto
<<entidade>>
Produto
Agora vamos desenhar o diagrama com base nos eventos.

2.2. Fluxo de Eventos
2.2.1. Fluxo bsico
1. O caso de uso comea quando o administrador seleciona a opo cadastrar produto. O sistema
mostra um formulrio com os campos para os dados do produto.
2. O Administrador preenche os dados do produto e seleciona a opo gravar produto. O sistema mostra
uma tela com os dados preenchidos do produto e pede confirmao;
3. O Administrador seleciona confirmar. O sistema grava as informaes do produto na base e mostra

uma tela confirmando o sucesso da operao.
Primeiro vamos colocar as instncias (objetos) das classes identificadas acima no diagrama:
: A d m in is t r a d o r
lim it e
:I n t A d m in i s t r a d o r
c o n t r o le
:C t r l C a d a s t r a r P r o d u t o
e n t id a d e
:P r o d u t o
lim it e
:R e p o s it o r io
Agora vamos colocar as mensagens relativas ao primeiro evento do fluxo bsico:
:S G B D
58
1. O caso de uso comea quando o administrador seleciona a opo cadastrar produto. O sistema
mostra um formulrio com os campos para os dados do produto.
lim it e
:In t A d m in is t r a d o r
c o n t r o le
:C t r lC a d a s t r a r P r o d u t o
e n t id a d e
:P r o d u t o
lim it e
:S G B D
o p c a o := m o s tra M e n u ()
m enu
c a d a s tra r p ro d u to
p r o d u to := te la C a d a s tr o P r o d u to ( )
t e la c a d a s t r o p r o d u t o
Agora vamos colocar as mensagens relativas ao segundo evento do fluxo bsico:
2. O Administrador preenche os dados do produto e seleciona a opo gravar produto. O sistema mostra
uma tela com os dados preenchidos do produto e pede confirmao;
lim it e
:I n t A d m in i s t r a d o r
c o n t r o le
:C t r l C a d a s t r a r P r o d u t o
e n t id a d e
:P r o d u t o
lim it e
:S G B D
o p c a o := m o s tra M e n u ( )
m enu
p r o d u t o : = t e la C a d a s t r o P r o d u t o ( )
d a d o s d o p ro d u to
s e t D a d o s ( v a lo r , c o d ig o , d e s c r ic a o , n o m e )
c o n f ir m a c a o : = p e d e C o n f ir m a c a o ( p r o d u t o )
d a d o s d o p r o d u to
d a d o s P ro d u to := g e tD a d o s ()
Agora vamos colocar as mensagens relativas ao segundo evento do fluxo bsico:

3. O Administrador seleciona confirmar. O sistema grava as informaes do produto na base e mostra
uma tela confirmando o sucesso da operao.
59
lim it e
:In t A d m in is t r a d o r
c o n t r o le
:C t r lC a d a s t r a r P r o d u t o
e n t id a d e
:P r o d u t o
lim it e
:S G B D
o p c a o := m o s tra M e n u ()
m enu
p r o d u t o : = t e la C a d a s t r o P r o d u t o ( )
s e t D a d o s ( v a lo r , c o d ig o , d e s c r ic a o , n o m e )
c o n f ir m a c a o : = p e d e C o n f ir m a c a o ( p r o d u t o )
c o n f ir m a c a o
g ra v o u := g ra v a P ro d u to (p ro d u to )
a lt
[g ra v o u ]
m o s tra M e n s a g e m (m e n s a g e m S u c e s s o )
in s e r e d a d o s
P ro d u to g r a v a d o
15.3. ATIVIDADE
1. Construa o digrama de seqncia, e implemente o caso de uso alterar Produto para o
mesmo sistema.
60
AULA 16 DIAGRAMAS DE ESTADOS

16.1. APRESENTAO
Vimos e estudamos os diagramas de casos de uso, diagramas de classes e diagramas de
interao. Em continuao vamos apresentar, a partir desta aula, os diagramas de estados.
16.2. DIAGRAMAS DE ESTADOS:

So diagramas que representam os estados que um objeto pode assumir e as mudanas de
um estado para outro. So compostos basicamente por: Estados e Transies:
Estados:
Condio ou situao na vida do objeto
Notao:
Um Estado pode ter:

aes de entrada/saida
transies internas
subestados
Transies
Representam a mudana de um estado para outro
As transies podem ter:

Estado Origem
Estado Destino
61
Evento
Condies de proteo
Aes
Exemplo:
Um diagrama que representa os estados de um pedido em uma empresa que fabrica itens sob
medida. O pedido aberto. Uma vez efetuada a venda, o pedido passa a para a produo.
Terminada a produo, o pedido passa para a entrega e, uma vez entregue ele concludo. O
pedido s pode ser cancelado enquanto est aberto ou em produo.
Subestados:
62
16.3. ATIVIDADE
1) Fazer um diagrama de estados para representar os diferentes estados de um funcionrio em
uma empresa.
2) Fazer um diagrama de estado para representar os diferentes estados de uma fita de vdeo
em uma vdeo-locadora.
63
AULA 17 DIAGRAMAS DE COMPONENTES E

DE IMPLANTAO
17.1. APRESENTAO
Diagramas de componentes e de Implantao
17.2. DIAGRAMAS DE COMPONENTES

Mostram as dependncias entre os componentes do sistema.
Componentes: "Arquivos" que o sistema necessita para funcionar.
Notao:
As dependencias entre os arquivos so representadas como no exemplo:
Os componentes podem ser arquivos de propriedades, arquivos fonte, arquivos html, jsp e at
mesmo bibliotecas que precisam ser instaladas.
64
17.3. DIAGRAMAS DE IMPLANTAO

So diagramas que representam a arquitetura de hardware e software do sistema
Ns: representam as mquinas e o software que roda em cada uma
Notao:
Ligaes: representam as conexes fsicas entre as mquinas:
65
Exemplo:
17.4. ATIVIDADE
Faa um diagrama de implantao para o problema do sistema de Matrculas
66
BIBLIOGRAFIA BSICA
BECK, K; CUNNINGHAM, W.. A laboratory for teaching Object-Oriented thinking. Anais do
International Conference on Object-Oriented Programming, Systems, Languages and
Applications OOPLSA89. New Orleans, EUA: 1989.
BEZZERRA, E.. Princpios de anlise e projeto de sistemas com UML. Rio de Janeiro,
Brasil: Campus, 2002.
BOOCH, G.; RUMBAUGH, J.; JACOBSON, I.. The Unified Modeling Language user guide.
2a. ed.Westford, Massachusets, EUA: Addison-Wesley, 2005.
JACOBSON, I.; BOOCH, G.; RUMBAUGH, J.. The Unified Software Development Process.
Reading, Massachusetts, EUA: Addison-Wesley, 1999.
LARMAN, C.. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and
Design and Iterative Development. 3a. ed. New Jersey, EUA: Addison-Wesley Professional,
2004.
OMG. Unified Modeling Language - Superstructure specification Verso 2.0. OBJECT
MANAGEMENT GROUP: Nedham, Massachusets, EUA, 2005
PRESSMAN, R. S.. Software Engineering: a practitioner's approach. 6a. ed .New York,
EUA: McGraw-Hill, 2005.
RUMBAUGH, J.; JACOBSON, I.; BOOCH, G.. The unified modeling language reference
manual. 2a. ed. Reading, Massachusetts, EUA: Addison-Wesley, 2004.

Apostila Uml

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Apostila Uml

Enviado por

Direitos autorais:

Formatos disponíveis

Andrey Ricardo Pimentel

Projeto de Software Usando a UML

AULA 1 PROCESSO DE SOFTWARE

1.4. CRISE DO SOFTWARE

1.5. PROCESSO E NOTAO

1.6. O PODER DA TECNOLOGIA DE OBJETOS

1.7. ANLISE E PROJETO

1.8. DESENVOLVIMENTO ITERATIVO E INCREMENTAL

1.9. PROCESSO UNIFICADO

Concepo (define o escopo do projeto)

Transio (implanta o sistema)

Cada fase dividida em iteraes e cada iterao

O Processo Unificado guiado por casos de uso

Qual a diferena entre processo e notao?

AULA 2 LEVANTAMENTO DE REQUISITOS

2.2. LEVANTAMENTO DE REQUISITOS

Problemas de escopo: o limite do sistema mal definido ou o cliente especifica detalhes

Problemas de entendimento: Os clientes ou usurios no esto certos do que

Problemas de volatilidade: Os requisitos mudam ao longo do tempo.

O sistema deve permitir que o professor lance as notas de um aluno,

O sistema deve permitir que o cliente se cadastre para receber emails,

Os requisitos no funcionais representam caractersticas de qualidade que o sistema deve ter e

Confiabilidade: tempo mdio entre falhas, recuperao de falhas ou nmero de erros

Desempenho: tempo de resposta esperado para cada funcionalidade do sistema.

Portabilidade: restries sobre as plataformas de hardware ou software nas quais o

Segurana: limitaes sobre segurana do sistema em relao a acessos no

Usabilidade: requisitos sobre facilidade de uso, idiomas, acessibilidades especiais,

Os requisitos normativos representam restries impostas sobre o desenvolvimento do sistema

AULA 3 CASOS DE USO

3.2. COMPORTAMENTO DO SISTEMA

Somente fornecer informaes para o sistema

Somente receber informaes do sistema

Fornecer e receber informaes para e do sistema

Tipicamente, estes atores so encontrados na definio do problema e em conversas com

Quem est interessado numa certa necessidade?

Onde na organizao o sistema usado?

Quem se beneficiar do uso do sistema?

Quem dar o suporte e manter o sistema?

O sistema usa um recurso externo?

Uma pessoa desempenha diferentes papis?

Vrias pessoas desempenham o mesmo papel?

O sistema interage com um sistema legado?

Notao UML para um Ator

3.4. CASOS DE USO

Quais so as tarefas de cada ator?

Notao para caso de uso

3.5. DIAGRAMAS DE CASO DE USO

um diagrama que mostre todos os casos de uso para um ator selecionado;

Exemplo de diagrama de casos de uso

AULA 4 ESPECIFICAO DE CASOS DE USO

4.2. A ESPECIFICAO DE UM CASO DE USO

Quando e como o caso de uso inicia e termina

A Especificao de Caso de Uso criada tipicamente na Fase de Elaborao numa maneira

AULA 5 RELACIONAMENTOS ENTRE CASOS

5.2. RELACIONAMENTOS ENTRE CASOS DE USO

5.3. RELACIONAMENTO <<INCLUDE>>

Figura relacionamento <<include>>

5.4. RELACIONAMENTO <<EXTEND>>

Figura relacionamento <<extend>>

Siga a seguinte regra:

Utilize <<extend>> quando estiver descrevendo uma variao do comportamento normal de

AULA 6 IDENTIFICAO DE CLASSES

6.2. DESCOBRINDO CLASSES