Projeto de Software Usando a UML

Andrey Ricardo Pimentel
Projeto de Software Usando a UML

Apostila para Curso de Projeto de
Sistemas Orientado a Objetos
Usando a UML.
julho de 2007
2
Sumrio
AULA 1 PROCESSO DE SOFTWARE..........................................................................................5
1.1. Apresentao........................................................................................................................5
1.2. Introduo............................................................................................................................5
1.. U!L.....................................................................................................................................5
1.". Cr#se do so$t%are.................................................................................................................&
1.5. Pro'esso e (otao..............................................................................................................&
1.&. O poder da te'no)o*#a de O+,etos........................................................................................&
1.-. An.)#se e pro,eto...................................................................................................................-
1./. Desen0o)0#1ento Iterat#0o e In're1enta)............................................................................-
1.2. Pro'esso Un#$#'ado..............................................................................................................-
1.13. At#0#dade............................................................................................................................2
AULA 2 LE4A(TA!E(TO DE RE5UISITOS..........................................................................13
2.1. Apresentao......................................................................................................................13
2.2. Le0anta1ento de Re6u#s#tos..............................................................................................13
2.. At#0#dade............................................................................................................................11
AULA CASOS DE USO............................................................................................................1
.1. Apresentao......................................................................................................................1
.2. Co1porta1ento do S#ste1a...............................................................................................1
.. Atores.................................................................................................................................1
.". Casos de Uso......................................................................................................................1"
.5. DIA7RA!AS DE CASO DE USO..................................................................................15
.&. At#0#dade............................................................................................................................1&
AULA " ESPECIFICA89O DE CASOS DE USO......................................................................1-
".1. Apresentao......................................................................................................................1-
".2. A Espe'#$#'ao de u1 'aso de Uso...................................................................................1-
".. At#0#dade............................................................................................................................1/
AULA 5 RELACIO(A!E(TOS E(TRE CASOS DE USO......................................................12
5.1. Apresentao......................................................................................................................12
5.2. Re)a'#ona1entos entre 'asos de uso..................................................................................12
5.. Re)a'#ona1ento ::#n')ude;;............................................................................................12
5.". Re)a'#ona1ento ::e<tend;;.............................................................................................12
5.5. 7enera)#=a>es...................................................................................................................23
5.&. At#0#dade............................................................................................................................21
AULA & IDE(TIFICA89O DE CLASSES USA(DO O !4C..................................................22
&.1. Apresentao......................................................................................................................22
&.2. Des'o+r#ndo C)asses..........................................................................................................22
&.. C)asses Ent#dade................................................................................................................22
&.". C)asses L#1#te....................................................................................................................22
&.5. C)asses Contro)e.................................................................................................................2
&.&. O+,etos e C)asses no pro+)e1a do S#ste1a de !atr?'u)a @!ATRIA..................................2
&.-. At#0#dade............................................................................................................................2"
AULA - IDE(TIFICA89O DAS RESPO(SABILIDADES DAS CLASSES ..........................25
-.1. Apresentao......................................................................................................................25
-.2. Cart>es CRC......................................................................................................................25
-.. At#0#dade............................................................................................................................2&
AULA / IDE(TIFICA89O DE ATRIBUTOS E OPERA8CES DE U!A CLASSE................2-
/.1. Apresentao......................................................................................................................2-
/.2. O 6ue D u1a operaoE......................................................................................................2-
/.. O 6ue D u1 Atr#+utoE.........................................................................................................22
/.". En'apsu)a1ento.................................................................................................................22
/.5. At#0#dade............................................................................................................................1
AULA 2 ASSOCIA8CES E(TRE CLASSES.............................................................................2
2.1. Apresentao......................................................................................................................2
2.2. Asso'#a>es........................................................................................................................2
2.. !u)t#p)#'#dade para Asso'#a>es........................................................................................
2.". At#0#dade............................................................................................................................"
AULA 13 A7RE7A8CES E ASSOCIA8CES............................................................................&
13.1. Apresentao....................................................................................................................&
13.2. A*re*ao.........................................................................................................................&
13.. Asso'#a>es Re$)e<#0as....................................................................................................-
13.". C)asses de L#*ao.........................................................................................................../
13.5. En'ontrando Asso'#a>es e A*re*a>es..........................................................................2
13.&. At#0#dade..........................................................................................................................2
AULA 11 FERA(8A..................................................................................................................."3
11.1. Apresentao...................................................................................................................."3
11.2. 7enera)#=ao..................................................................................................................."3
11.. Ferana !G)t#p)a.............................................................................................................."2
11.". At#0#dade.........................................................................................................................."
AULA 12 I(TERFACES E PACOTES.........................................................................................""
12.1. Apresentao....................................................................................................................""
12.2. Inter$a'es..........................................................................................................................""
12.. Pa'otes............................................................................................................................."5
12.". At#0#dade.........................................................................................................................."-
AULA 1 !ODELO DE CLASSESH I!PLE!E(TA89O E !ODELO RELACIO(AL........."/
1.1. Apresentao...................................................................................................................."/
1.2. !apeando d#a*ra1as de C)asse para 'Id#*o e1 ,a0a......................................................"/
1.. !apeando C)asses para !ode)o RE)a'#ona)....................................................................53
1.". At#0#dade..........................................................................................................................52
AULA 1" DIA7RA!AS DE I(TERA89O................................................................................5
1".1. Apresentao....................................................................................................................5
1".2. D#a*ra1as de #nterao....................................................................................................5
1".. At#0#dade..........................................................................................................................55
AULA 15 DIA7RA!AS DE SE5JK(CIA................................................................................5&
15.1. Apresentao....................................................................................................................5&
15.2. DESE(4OL4I!E(TO...................................................................................................5&
15.. At#0#dade..........................................................................................................................5/
AULA 1& DIA7RA!AS DE ESTADOS.....................................................................................52
1&.1. Apresentao....................................................................................................................52
1&.2. D#a*ra1as de EstadosL.....................................................................................................52
1&.. At#0#dade..........................................................................................................................&1
AULA 1- DIA7RA!AS DE CO!PO(E(TES E DE I!PLA(TA89O..................................&2
1-.1. Apresentao....................................................................................................................&2
1-.2. D#a*ra1as de Co1ponentes.............................................................................................&2
1-.. D#a*ra1as de I1p)antao...............................................................................................&
1-.". At#0#dade..........................................................................................................................&"
"
1-.5. BIBLIO7RAFIA BMSICA..............................................................................................&"
5
AULA 1 PR!"SS #" S$%&AR"
1'1' APR"S"(%A)*
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' +(%R#U)*
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 . Jacobson. .
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. sto causava problemas de comunicao, treinamento de pessoal e portabilidade.
Um esforo de unificao comeou em 1994 quando J. Rumbaugh e, logo aps, . 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',' 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'-' !R+S" # S$%&AR"
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'.' PR!"SS " (%A)*
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'/' P#"R #A %"!(L0+A #" 12"%S
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
-
Reduo do nmero de linhas de cdigo dos projetos
1'7' A(3L+S" " PR2"%
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'4' #"S"(5L5+M"(% +%"RA%+5 " +(!R"M"(%AL
O desenvolvimento de sistemas seguindo o Processo Unificado :
terativo e incremental
Guiado por casos de uso (use cases)
Baseado na arquitetura do sistema
1'6' PR!"SS U(+$+!A#
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
2
1'10' A%+5+#A#"
1) Qual a diferena entre processo e notao?
2) Qual a diferena entre anlise e projeto de sistemas de software?
3) Cite algumas caractersticas da orientao a objetos.
4) Quais so as caractersticas do processo unificado?
5) Quais so e o que feito em cada uma das fases do processo unificado?
6) O que arquitetura do sistema?
13
AULA 2 L"5A(%AM"(% #" R"7U+S+%S
2'1' APR"S"(%A)*
Nesta aula sero apresentados e discutidos os conceitos de concepo e
especificao de um projeto de um sistema de software.
2'2' L"5A(%AM"(% #" R"7U+S+%S
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 staeholders (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:
11
Confiabilidade: tempo mdio entre falhas, recuperao de falhas ou nmero de erros
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',' A%+5+#A#"
1)Faa uma especificao de requisitos para o sistema descrito abaixo:
Sistema de Matr8cula em cursos de Uni9ersidade
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.
nformaes 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
12
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
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.
1
AULA , !ASS #" US
,'1' APR"S"(%A)*
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.
,'2' !MPR%AM"(% # S+S%"MA
O comportamento do sistema em desenvolvimento, que o que funcionalmente deve ser
fornecido pelo sistema, documentado em um Modelo de !aso 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 $ase de !once:;<o 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.
,',' A%R"S
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?
1"
Na UML= um ator representado como um homem palito, como mostrado na figura abaixo.
Notao UML para um Ator
>ue constitui um ?om 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 Matr8cula A MA%R+
Respondendo s perguntas anteriores, identificaremos diversos atores. Um deles
Professor.
#ocumenta;<o 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
,'-' !ASS #" US
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.
15
Notao para caso de uso
>ue !onstitui um 1om !aso 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. sto , 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).
,'.' #+A0RAMAS #" !AS #" US
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
!asos de Uso no Sistema Matr8cula A MA%R+
As seguintes necessidades devem ser tratadas pelo sistema:
O ator estudante precisa usar o sistema para registrar-se em cursos
1&
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
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".
,'/' A%+5+#A#"
Baseando-se na descrio dos sistema de matrculas (MATR), 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)
1-
AULA - "SP"!+$+!A)* #" !ASS #" US
-'1' APR"S"(%A)*
Nesta aula ser apresenta e discutida a especificao dos caso de uso
-'2' A "SP"!+$+!A)* #" UM !AS #" US
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. sto , 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. nicialmente, 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
1/
Uma amostra do documento de Fluxo de Eventos para o Caso de Uso Selecionar Cursos para
Lecionar mostrada a seguir:
"s:ecifica;<o do !aso de Uso !adastrar Usurio
1 (ome do !aso de Uso
Cadastrar Usurio
2 1re9e descri;<o
Cadastra um usurio no sistema, com todos os dados, inclusive uma fotografia.
, $luBo de e9entos
,'1$luBo ?sico
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.
,'2 $luBos alternati9os
,'2'1C Primeiro fluBo alternati9oD
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.
,'2'2C seEundo fluBo alternati9oD
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.
,'2',C %erceiro fluBo alternati9oD
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.
- Re>uisitos "s:eciais
No se aplica
. PrFAcondi;Ges
< pr-condio um >
O ator deve estar logado no sistema. Nenhum outro usurio com o mesmo CPF
dever ter sido cadastrado.
/ PHsAcondi;Ges
< ps-condio um >
Um usurio novo cadastrado.
7 Pontos de "Btens<o
No se aplica.
-',' A%+5+#A#"
1)Baseando-se na descrio dos sistema de matrculas (MATR), descrito nas unidades
anteriores, selecione 3 dos casos de uso identificados e faa a especificao de casos de uso
para cada um deles
12
AULA . R"LA!+(AM"(%S "(%R" !ASS
#" US
.'1' APR"S"(%A)*
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.
.'2' R"LA!+(AM"(%S "(%R" !ASS #" US
Um relacionamento de associao pode existir entre um ator e um caso de uso. Esse tipo de
associao normalmente chamado como uma "ssocia#$o de Comunica#$o, 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.
.',' R"LA!+(AM"(% CC+(!LU#"DD
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>>
.'-' R"LA!+(AM"(% CC"I%"(#DD
Um relacionamento de "extend" usado para mostrar: comportamento opcional,
comportamento que somente executado sobre determinadas condies, como o disparo de
23
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 (MATR).
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.
.'.' 0"("RAL+JA)K"S
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.
21
.'/' A%+5+#A#"
Baseando-se na descrio dos sistema de matrculas (MATR), 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)
22
AULA / +#"(%+$+!A)* #" !LASS"S
USA(# M5!
/'1' APR"S"(%A)*
Nesta aula ser visto como identificar Classes de um sistema usando o Padro Modelo-Viso-
Controlador.
/'2' #"S!1R+(# !LASS"S
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%&iew%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.
/',' !LASS"S "(%+#A#"
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.
/'-' !LASS"S L+M+%"
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.
2
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
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.
/'.' !LASS"S !(%RL"
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. sso 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.
/'/' 12"%S " !LASS"S ( PR1L"MA # S+S%"MA #"
MA%RL!ULA MMA%R+N
Vamos dar uma olhada no cenrio "dicionando 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.
2"
+dentificando !lasses Limite
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). sto 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 Op#'esCurso(rofessor. Adicionalmente podemos
identificar uma classe que faa a adio de um novo Curso Ofertado para o Professor. Esta
classe chamada "dicionaOfertaCurso.
+dentificando !lasses "ntidade
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 )nforma#$o(rofessor.
+dentificando !lasses de !ontrole
remos adicionar uma classe de controle para manusear o fluxo de eventos para o caso de uso.
Esta classe chamada ControleCurso(rofessor. As classes identificadas foram adicionadas ao
modelo.
/'7' A%+5+#A#"
Baseando-se no modelo de Caso de Uso abaixo, tente levantar as classes para o sistema de
Matrcula (MATR).
25
AULA 7 +#"(%+$+!A)* #AS
R"SP(SA1+L+#A#"S #AS !LASS"S
7'1' APR"S"(%A)*
Nesta aula ser visto como identificar as classes de um sistema usando os cartes CRC
7'2' !AR%K"S !R!
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. dentificando-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-Responsabilidades-
Colaboradores (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.
2&
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;
>ue s<o classes e como definiAlas
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...
>ue s<o res:onsa?ilidades e como definiAlas
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).
>ue s<o cola?oradores e como definiAlos
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',' A%+5+#A#"
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.
2-
AULA 4 +#"(%+$+!A)* #" A%R+1U%S "
P"RA)K"S #" UMA !LASS"
4'1' APR"S"(%A)*
Nesta aula ser visto como identificar os atributos e as operaes das classes do sistema
4'2' 7U" O UMA P"RA)*@
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
:era;Ges #e:endem do #om8nio
Liste todas as operaes relevantes ao domnio do problema
As operaes de uma classe Pessoa sero diferentes dependendo de 'quem
est perguntando'
(omeando :era;Ges
As operaes devem ser nomeadas para indicar seus resultados, no os passos
por trs da operao. Exemplos:
calcularSaldo()
Nome pobre
ndica que o saldo deve ser calculado - isto uma deciso de
implementao/otimizao
obterSaldo()
Bem nomeado
ndica apenas o resultado
(omeando :era;Ges
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
Perspectiva do Bancrio
receber emprstimo
anexar conta
receber linhaDeCrdito
Perspectiva do Mdico
examinar
tomarRemdio
irParaHospital
receberConta
2/
Uma operao para que a bomba tenha esta responsabilidade -- como
deveria ser chamada?
Bons nomes -- distribuir(), darGasolina()
Nome ruim -- receberGasolina()
A bomba d a gasolina -- ela no recebe a gasolina
>ue F uma :era;<o Primiti9a@
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 :era;<o
A assinatura da operao consiste de :
Lista de argumentos opcional
Classe de retorno
Durante a anlise NO OBRGATRO preencher a assinatura de operaes
Esta informao pode ser adiada para fase de projeto
Mostrando :era;Ges
Operaes so mostradas no terceiro compartimento da classe
#esco?rindo :era;Ges nos #iaEramas de +ntera;<o
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
get prerequisito
um curso
GerenteDe
Matricula
getPrerequisito():ListaDeCurso
um curso
22
4',' 7U" O UM A%R+1U%@
Um atributo uma caracterstica de uma classe
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
sto um relacionamento e no um atributo
Mostrando Atri?utos
Atributos so mostrados no segundo compartimento da classe
!omo #esco?rir Atri?utos@
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
"Bi?indo Atri?utos e :era;Ges
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
4'-' "(!APSULAM"(%
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:
3
O estado interno de um objeto de ser corrompido por seus clientes
O cdigo cliente de mudanas na implementao dos objetos
"Bem:loP "nca:sulamento
1enef8cios do "nca:sulamento
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
nmeroConta
nomeBanco
nomeProprietrio
saldo
saque
depsito
geraTransao
getSaldo
mudeNomeProprietrio
Valores de atributos podem ser alterados
apenas pelas operaes providas pelo
objeto
So criadas operaes para mostrar os
valores de atributos requisitados por
clientes
O estado do objeto no pode ser modificado
diretamente por clientes
1
4'.' A%+5+#A#"
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.
2
AULA 6 ASS!+A)K"S "(%R" !LASS"S
6'1' APR"S"(%A)*
Nesta aula iremos abordar e exercitar o que so associaes entre classes e como us-las.
remos abordar aspectos como: associaes, nomes, papeis, multiplicidade, qualificadores,
navegabilidade e associaes reflexivas.
6'2' ASS!+A)K"S
A (ecessidade 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
Associa;Ges
Uma associao uma conexo semntica bi-direcional entre classes
sto 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
(a9eEa;<o
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
#ando (omes Qs Associa;Ges
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
#efinindo Pa:Fis
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
Associa;Ges MRlti:las
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
6',' MUL%+PL+!+#A#" PARA ASS!+A)K"S
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
"
+ndicadores de Multi:licidade
Cada lado de uma associao contem um indicador de multiplicidade
ndica o nmero de objetos que participam no relacionamento
"Bem:loP Multi:licidade
Decises de Multiplicidade expem muitas suposies, antes ocultas, sobre o problema sendo
modelado
Um professor pode estar indisponvel?
Um curso pode ter dois professores?
7ualificadores
Um qualificador um atributo de uma classe que pode ser usado para reduzir a multiplicidade
da associao
Restri;Ges
Uma restrio expressa alguma condio que deve ser preservada
Uma restrio mostrada entre chaves.
6'-' A%+5+#A#"
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
Exatamente Um
Zero or mais
Um ou Mais
Zero or um
ntervalo Especfico
1
0..*
1..*
0..1
2..4
Muitos
*
Departamento Professor
EmpregadoD
1
5
capacidade de cada vago de carga em metros cbicos.
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.
&
AULA 10 A0R"0A)K"S " ASS!+A)K"S
10'1' APR"S"(%A)*
Nesta aula iremos abordar e exercitar o que so agregaes entre classes e como us-las.
remos abordar aspectos como: agregaes, composies, associaes reflexivas, classes de
ligao e as diferenas entre associaes e agregaes.
10'2' A0R"0A)*
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
%estes de AEreEa;<o
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
%i:os de AEreEa;<o
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
Visualizando o conceito de agregao, o agregado contm uma referncia aos seus
FormularioDeHorrio
<<limite>>
1
FormularioDeMatrcula
<<limite>>
1
Area
Empregado
0..* 1
-
componentes
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
Visualizando o conceito de composio, o composto contm os seus componentes
Associa;<o ou AEreEa;<o @
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',' ASS!+A)K"S R"$L"I+5AS
Em uma associao reflexiva, objetos de uma mesma classe so relacionados
ndica que mltiplos objetos da mesma classe colaboram juntos de algum modo
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
sto indica um relacionamento recursivo
Automovel Porta
2..5 1
Curso
Pr-requisito
0..*
0..*
ParteDeProduto
0..*
/
Um objeto ParteDeProduto "composto de zero ou mais objetos ParteDeProduto
10'-' !LASS"S #" L+0A)*
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?
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
#esenhando !lasses de LiEa;<o
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
!lasses de LiEa;<o e Multi:licidade
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
Estudante
0..*
3-10
Curso
Estudante
1..*
3-10
Curso
Boletim
2
10'.' "(!(%RA(# ASS!+A)K"S " A0R"0A)K"S
Associa;<o ou AEreEa;<o @
FormularioDeMatrcula e FormularioDeHorario so estreitamente ligados
-- uma FormularioDeHorario "parte daFormularioDeMatricula
10'/' A%+5+#A#"
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 acetil-
saliclico) foi fabricado, em que lote(s) e com que nmero de permisso.
Estudante
1
3-10
Curso
nota
Estudante
1
3-10
Curso
nota
$ormulario#eSorario e
0erente#eMatr8cula
s<o inde:endentes
FormularioDeMatrcula
<<limite>>
1
FormularioDeHorario
<<limite>>
1
GerenteDeMatrcula
1
1
"3
AULA 11 S"RA()A
11'1' APR"S"(%A)*
Nesta aula iremos abordar e exercitar o que so generalizaes entre classes e como us-las.
remos abordar aspectos como: generalizao, hierarquia, notao, subclasse, superclasse,
especializao, e herana mltipla.
11'2' 0"("RAL+JA)*
0eneraliTa;<o 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 heran;a sim:les, a subclasse herda de apenas uma superclasse
Com heran;a mRlti:la, a subclasse herda de mais de uma superclasse
Generalizao um relacionamento " um" ou "tipo de"
#esenhando uma Sierar>uia de Seran;a
!onsidera;Ges so?re EeneraliTa;<o
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
>ue F Serdado@
Uma subclasse herda de seus pais:
Atributos
Operaes
Relacionamentos
Uma subclasse pode:
ncluir atributos, operaes e relacionamentos adicionais
Superclasse
Subclasse
Relacionamento de 0eneraliTa;<o
nfoEstudante
nfoRegistroUsurio
"1
Redefinir as operaes herdadas (use com cautela!)
Serdando Atri?utos
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
Serdando :era;Ges
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
Serdando 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
0eneraliTa;<o de !lasses
Generalizao proporciona a capacidade de criar superclasses que reunem estrutura
e/ou comportamento comum a vrias subclasses
Procedimento de generalizao
dentificar 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
"Bem:lo de 0eneraliTa;<o
Caminho
tonelagem
VeculoTerrestre
peso
nmeroLicena
Carro
Um caminh<o tem trUs atri?utosP
:eso
nRmeroLicen;a
tonelaEem
"2
"s:ecialiTa;<o de !lasses
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
Sierar>uias de Seran;a
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
ncorporar classes de implementao
ncorporar bibliotecas de classes disponveis
11',' S"RA()A MVL%+PLA
!onceitos de Seran;a MRlti:la
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
Poupana
Bens
mveis ContaBancria
ContaCorrente Aes
Seguro
Bnus
Avio Helicptero Lobo Cavalo
CoisaQueVoa Animal
Pssaro
herana
mltipla
"
Cada ambiente/linguagem de programao escolhe maneiras de resolver estas dificuldades
"ncontrando EeneraliTa;<o
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
0eneraliTa;<o 9ersus AEreEa;<o
Generalizao e agregao so geralmente confundidas
Generalizao representa um relacionamento "-um" ou "tipo-de"
Agregao representa um relacionamento "tem-um"
11'-' A%+5+#A#"
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.
0eneraliTa;<o AEreEa;<o
Palavra chave WF umX
Relaciona objetos da
mesma superclasse
Representado por uma seta
Palavra chave Wtem umX
Relaciona objetos de classes diferentes
Representado por um losango
""
AULA 12 +(%"R$A!"S " PA!%"S
12'1' APR"S"(%A)*
Nesta aula iremos abordar e exercitar o que so ntefaces e pacotes.
12'2' +(%"R$A!"S
Uma nterface 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
framewors 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.
(ota;<oP
RelacionamentosP
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.
"5
12',' PA!%"S
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.
!riando PacYaEes
O prximo passo agrupar as classes em packages. Neste ponto, ns temos identificadas seis
classes: Curso, OfertaCurso, )nforma#$o(rofessor, Op#'esCurso(rofessor,
"dicionaOfertaCurso e ControleCurso(rofessor. 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: )nterfaces,
Ser&icoUni&ersidade e )nformacao(essoa. 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.
"&
O diagrama de classe principal (Main) para o package Ser&icoUni&ersidade 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
"-
12'-' A%+5+#A#"
Construa um Diagrama de Classes inicial para controlar emprstimos e reservas de
deve ser avisado.
nterfaces
Controle
Artefatos
Universitrios
"/
AULA 1, M#"L #" !LASS"S=
+MPL"M"(%A)* " M#"L R"LA!+(AL
1,'1' APR"S"(%A)*
Nesta aula iremos abordar e exercitar que o modelo de classes tem com a codificao em java
e com o modelo relacional.
1,'2' MAP"A(# #+A0RAMAS #" !LASS" PARA !Z#+0
"M 2A5A
mplementar 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.
mplementando classes simples:
Este o cdigo em java para a classe descrita pelo diagrama acima.
class Produto {
private String nome;
private String descricao;
protected double preco;
public void setNome(String umNome) {}
public String getNome() {return null;}
static public Vector getAll() {return null;}
}
+m:lementando associa;GesP
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:
"2
public class ItemdePedido
{
private int quantidade;
private EspecificacaoProduto produto;
}
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:
public class ItemDePedido
{
private int quantidade;
private int codProduto;
}
No caso de muitos para muitos:
Existe a necessidade da criao de uma classe para a associao:
public class Matricula
{
private Aluno aluno;
private Turma turma;
}
AEreEa;GesP
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;
public class Pedido
{
private Date data;
private String codPedido;
private boolean completo;
53
private Vector todosItens;
}
1,',' MAP"A(# !LASS"S PARA M#"L R"LA!+(AL
Associa;<o 1P(
Define-se uma tabela por classe acrescentando-se os atributos identificadores de cada classe
respectiva tabela. A figura abaixo ilustra a situao tratada:
Associa;<o MP(
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 um para muitos
Associao muitos para muitos
Seran;a
dentificam-se quatro formas para o mapeamento das heranas. So elas:
51
Uma ta?ela :or classe Uma Rnica ta?ela
Uso de ta?elas a:enas :ara classes
es:ec8ficas
Mista
52
1,'-' A%+5+#A#"
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.
5
AULA 1- #+A0RAMAS #" +(%"RA)*
1-'1' APR"S"(%A)*
Nesta aula vamos apresentar os diagramas de seqncia e comunicao
1-'2' #+A0RAMAS #" +(%"RA)*
Os diagramas de nterao, compostos por: Diagramas de Seqncia e Diagramas de
Comunicao.
#+A0RAMA #" S"7[\(!+AP
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.
PASSSP
1. dentifique os "principais objetivos do seu sistema".
2. Descreva o cenrio.
3. dentifique os objeto origem e o objeto destino.
4. Construa o Diagrama.
Exemplo de um diagrama seqncia na UML:
sd eBem:lo01
Usuario
P+ntUsuario P!trl!ad!liente P!liente
Cliente:= mostraTelaCadCliente()
formulrio cliente
dados Cliente
setNome(nome)
setCNPJ(cnpj)
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.
5"
retorno de mensagem;
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)
sd eBem:lo0-
P!lasseA P!lasse1 P!lasse!
alt
[numero <= 3]
[numero >3]
numero:= verificaNome(nome)
[numero = 0]: codigoNulo:= geracodigoNulo()
setNome(nome)
codigo:= calculaCodigo(nome)
nome:= getNome()
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)
sd eBem:lo0.
P!onta P!trlPedido
PPedido
P%icYet1#
loo:
[proximo item]
alt
[disponvel]
[no disponvel]
recuperar status de cliente existente
criar ( )
reservar(contagem,date)
adicionar(assentos)
rejeitar()
debitar(custo)
Alguns aspectos dependentes da linguagem para expressar a mensagem, podem ser
55
omitidos na fase de anlise.
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.
#+A0RAMA #" !MU(+!A)*:
- 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.
1-',' A%+5+#A#"
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.
5&
AULA 1. #+A0RAMAS #" S"7[\(!+A
1.'1' APR"S"(%A)*
Construindo e implementando diagramas de sequncia em java com jsp e servlet de controle
1.'2' #"S"(5L5+M"(%
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>>
ntAdministrador
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:
:Administrador :SGBD
limite
P+ntAdministrador
controle
P!trl!adastrarProduto
entidade
PProduto
limite
PRe:ositorio
Agora vamos colocar as mensagens relativas ao primeiro evento do fluxo bsico:
5-
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.
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;
limite
P+ntAdministrador
controle
entidade
PProduto
limite
PRe:ositorio
opcao:= mostraMenu()
menu
cadastrar produto
produto:= telaCadastroProduto()
tela cadastro produto
dados do produto
setDados(valor,codigo,descricao,nome)
confirmacao:= pedeConfirmacao(produto)
dadosProduto:= getDados()
dados do produto
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.
limite
P+ntAdministrador
controle
entidade
PProduto
limite
PRe:ositorio
menu
cadastrar produto
5/
limite
P+ntAdministrador
controle
entidade
PProduto
limite
PRe:ositorio
alt
[gravou]
menu
cadastrar produto
dados do produto
setDados(valor,codigo,descricao,nome)
confirmacao:= pedeConfirmacao(produto)
dados do produto
confirmacao
gravou:= gravaProduto(produto)
insere dados
mostraMensagem(mensagemSucesso)
Produto gravado
1.',' A%+5+#A#"
1. Construa o digrama de seqncia, e implemente o caso de uso "alterar Produto para o
mesmo sistema.
52
AULA 1/ #+A0RAMAS #" "S%A#S
1/'1' APR"S"(%A)*
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.
1/'2' #+A0RAMAS #" "S%A#SP
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:
"stadosP
Condio ou situao na vida do objeto
Notao:
Um Estado pode ter:
aes de entrada/saida
transies internas
subestados
%ransi;Ges
Representam a mudana de um estado para outro
As transies podem ter:
Estado Origem
&3
Estado Destino
Evento
Condies de proteo
Aes
"Bem:loP
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.
Su?estadosP
&1
1/',' A%+5+#A#"
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.
&2
AULA 17 #+A0RAMAS #" !MP("(%"S "
#" +MPLA(%A)*
17'1' APR"S"(%A)*
Diagramas de componentes e de mplantao
17'2' #+A0RAMAS #" !MP("(%"S
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.
&
17',' #+A0RAMAS #" +MPLA(%A)*
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:
&"
Exemplo:
17'-' A%+5+#A#"
Faa um diagrama de implantao para o problema do sistema de Matrculas
&5
1+1L+0RA$+A 13S+!A
BECK, K; CUNNNGHAM, W.. A laboratory for teaching Object-Oriented thinking! "nais do
)nternational Conference on Object%Oriented (rogramming* Systems* Languages and
"pplications OO(LS"+,. New Orleans, EUA: 1989.
BEZZERRA, E.. (rinc-pios de an.lise e projeto de sistemas com UML. Rio de Janeiro,
Brasil: Campus, 2002.
BOOCH, G.; RUMBAUGH, J.; JACOBSON, .. The Unified Modeling Language user guide.
2a. ed.Westford, Massachusets, EUA: Addison-Wesley, 2005.
JACOBSON, .; BOOCH, G.; RUMBAUGH, J.. The Unified Software /e&elopment (rocess.
Reading, Massachusetts, EUA: Addison-Wesley, 1999.
LARMAN, C.. "pplying UML and (atterns0 "n )ntroduction to Object%Oriented "nalysis and
/esign and )terati&e /e&elopment. 3a. ed. New Jersey, EUA: Addison-Wesley Professional,
2004.
OMG. Unified Modeling Language % Superstructure specification 1ers$o 2!3. OBJECT
MANAGEMENT GROUP: Nedham, Massachusets, EUA, 2005
PRESSMAN, R. S.. Software 4ngineering0 a practitioner5s approach. 6a. ed .New York,
EUA: McGraw-Hill, 2005.
RUMBAUGH, J.; JACOBSON, .; BOOCH, G.. The unified modeling language reference
manual. 2a. ed. Reading, Massachusetts, EUA: Addison-Wesley, 2004.

Projeto de Software Usando a UML

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Projeto de Software Usando a UML

Uploaded by

Copyright:

Available Formats

Andrey Ricardo Pimentel

Projeto de Software Usando a UML

You might also like