Uml

UNIP Universidade Paulista
Cincia da Computao e Sistemas de Informao

Linguagem de Modelagem Unificada (UML)
1. Introduo
Sob o ponto de vista de quem desenvolve software, seu principal papel deve ser a
construo de um produto de software capaz de satisfazer s necessidades de seus
usurios e respectivos negcios, a partir de uma verificao detalhada dos problemas
que devem ser resolvidos, aliada aos desejos do usurio sobre a questo. Nem sempre
todas as solicitaes oriundas do contexto para informatizao parecero lgicas sob a
tica de um tcnico, mas sero motivadas por questes polticas no cerne de uma cultura
empresarial. Considerar todos os requisitos para desenvolvimento de um software deve
ser o principal objetivo para um desenvolvedor e modelar um sistema uma atividade
de primeira grandeza, sem a qual, o objetivo principal no ser devidamente alcanado.
1.1 Modelagem Visual
Para conseguir desenvolver um software capaz de satisfazer s necessidades de seus
usurios, com qualidade duradoura, por intermdio de uma arquitetura slida que aceite
modificaes, de forma rpida, eficiente, com o mnimo de desperdcio e retrabalho,
necessrio o emprego de modelagem. Modelagem uma parte central de todas as
atividades que levam implantao de um bom software. Construir o modelo de um
sistema no uma atividade simples ou fcil, so vrias abordagens a serem
consideradas: a organizao da empresa, os processos existentes ou requeridos, as
informaes existentes (ou requeridas) e os recursos envolvidos.
Pode-se fazer uma representao dos recursos organizacionais dispondo-os em
hierarquia, conforme a figura a seguir, de maneira que o primeiro nvel hierrquico
poderia ser visualizado em um organograma que define responsabilidades a serem
exercidas por pessoas. As pessoas no desempenho de algum papel dentro da
organizao so, em geral, as responsveis pela execuo de processos. Assim, do ponto
de vista da confrontao ou cruzamento entre um organograma e uma modelagem
funcional da organizao, encontra-se um forte impacto de natureza poltica, que
promove, segundo sua convenincia, vrias modificaes na conduo dos processos
existentes, muitas vezes sem uma preocupao com os aspectos tcnicos envolvidos, o
que torna a modelagem de processos uma tarefa difcil.
No possvel desenvolver uma modelagem de processos sem interferncia de pessoas
e da cultura estabelecida em uma organizao; portanto, quem modela deve desenvolver
habilidades que sobrepujam s tcnicas.
Organizao
da Empresa
Recursos
existentes
na empresa
envolvidos
nos
processos
que geram
informao
Processos
existentes ou
requeridos
Informaes
existentes ou
que se espera
que os
processos
gerem
Figura: Vrios aspectos a serem considerados em uma modelagem
Prof. Marcelo Nogueira

Modelos so construdos para que o sistema que ser desenvolvido seja melhor
compreendido. Com a modelagem, pode-se alcanar quatro objetivos:
Os modelos ajudam a visualizar o sistema como ele ou como desejamos que seja.
Os modelos permitem especificara estrutura ou o comportamento de um sistema.
Os modelos proporcionam um guia para a construo do sistema.
Os modelos documentam as decises tomadas
Existem limites para a capacidade humana de compreender complexidades, mais
especificamente, reter todos os detalhes que envolvem uma realidade complexa, os
relacionamentos existem, as possveis situaes que possam ocorrer dependendo da
combinao de cada aspecto envolvido. Com a ajuda da modelagem, delimitamos o
problema que estamos estudando, restringindo nosso foco a um nico aspecto por vez.
Quanto mais complexo for o sistema, maior ser a probabilidade de ocorrncia de erros
ou de construo de itens errados, caso no haja nenhuma modelagem, alm disso,
pode-se esquecer de detalhes que surpreendentemente iro comprometer o produto
quando estiver sendo utilizado.
Os diferentes aspectos do sistema que est sendo modelado so chamados de vises.
Um sistema que se planeja construir poder vir a ter um nmero ilimitado de vises;
quanto maior a complexidade do sistema maior tende a ser a quantidade de vises que
se avaliar, cada uma mostrar aspectos particulares do sistema propiciando ngulos e
nveis de abstrao diferentes; desse modo, um molde completo do sistema poder ser
construdo. As vises tambm podem servir de ligao entre a linguagem de modelagem
e o mtodo/processo de desenvolvimento escolhido. Qualquer sistema deve ser
considerado a partir de trs macros aspectos bsicos:
Funcionais (sua estrutura esttica e suas interaes dinmicas).
No Funcionais (requisitos de tempo, confiabilidade, desenvolvimento etc.).
Organizacionais (organizao do trabalho, mapeamento dos mdulos de cdigo,
distribuio fsica do hardware etc.).
De acordo com o mtodo de desenvolvimento a ser utilizado, cada viso descrita por
um ou mais conjuntos de diagramas que contemplam os elementos daquela poro da
realidade. Todos os sistemas bem desenvolvidos, que se mostram como recursos teis a
seus usurios, apresentam uma tendncia natural para se transformarem em algo mais
complexo ao longo do tempo, dados que os requisitos so mutveis no tempo; assim, o
panorama que originou o software em algum momento, vai se transformando de
maneira que, se o software no sofrer adequaes para atender aos novos requisitos,
acaba se tornando obsoleto. Portanto, ainda que considere no ser necessrio fazer
modelagem hoje, medida que o sistema construdo evoluir, tornando-se algo mais
complexo, voc certamente se arrepender dessa deciso.
1.2 SNTESE HISTRICA DA UML
A linguagem de modelagem unificada (UML) no um mtodo de desenvolvimento de
sistemas, uma linguagem grfica que poder ser aplicada para descrever e documentar
um projeto de software. Ela simplifica o complexo processo de anlise, projeto e
construo de software criando vises do sistema que est sendo construdo.
Um mtodo pressupe um modelo de linguagem para as especificaes tcnicas e um
processo. O modelo de linguagem a notao que o mtodo usa para descrever o

projeto. O processo constitudo de passos que devem ser seguidos na construo de
um projeto. O modelo de linguagem uma parte muito importante do mtodo.
Corresponde ao ponto principal da comunicao. Se uma pessoa que conversar com
outra sobre o projeto, por meio do modelo de linguagem que elas se entendem, na
medida em que um projeto avana, por meio do modelo de linguagem documenta-se
tudo o que foi definido nas fases. Se em algum momento deseja-se recuperar detalhes
sobre um aspecto que foi analisado anteriormente, essa atividade facilitada com o
modelo de uma linguagem, ainda que a atividade seja desenvolvida por uma pessoa
diferente daquela que fez a referida especificao.
A UML uma linguagem padro para visualizar, especificar, construir e documentar
artefatos de um sistema baseado em software. Os autores da UML preocupam-se em
incorporar recursos que permitissem a abordagem de diversos tipos de sistemas, dos
mais simples at os sistemas concorrentes e distribudos. Os esforos so concentrados
em um metamodelo comum, que unifica as semnticas, e em uma notao comum que
fornece uma interpretao humana dessas semnticas. A UML reuniu vrios recursos
existentes em diversos mtodos orientados a objetos.
So vrias as menes acerca da grande quantidade de mtodos orientados a objetos que
foram originados no incio dos anos 90. A novidade de aplicar-se o modelo orientado
a objetos no processo de desenvolvimento do software, bem como algumas
caractersticas que demonstravam ser um meio eficaz para a produo do software,
levaram a um grande entusiasmo quanto aplicao do recurso, muito embora tenha se
estabelecido o inconveniente de que, dado ao grande numero de metodologias
existentes, no se tinha a noo de qual deles seria o ideal. A indstria no tinha como
lanar produtos que dessem resguardo a este ou aquele mtodo, pois no tinha a
perspectiva sobre qual deles haveria uma convergncia de mercado.
Em 1997, por iniciativa da OMG (Object Management Group), foi aberta a proposta
para apresentao de trabalhos de padronizao de um modelo para desenvolvimento de
sistemas que atendesse ao modelo orientado a objetos. A UML foi a proposta
vencedora, apresentada pela empresa Rational Software Corporation e se tornou um
padro a ser seguido pelo mercado, com relao s especificaes orientadas a objetos.
A OMG uma organizao sem fins lucrativos que cuida das padronizaes vinculadas
ao modelo orientado a objetos, possui mais de 800 filiados, incluindo empresas de
renome no mercado internacional, implicando, portanto, que o mercado como um todo
utilizar softwares que iro considerar a UML como referncia.
Essa proposta de padronizao foi um esforo liderado por Grady Booch, James
Rumbaugh e Ivar Jacobson que resultou na verso 1.0 da UML publicada em 13 de
janeiro de 1997 e adotada como padro pela OMG no mesmo ano. Aglutinou o que
havia de melhor em vrios mtodos existentes, tendo recebido a colaborao de vrios
metodologistas.
1.3 CONCEITOS DA UML
A UML tem como objetivo prover as necessidades de desenvolvedores de software com
uma linguagem de modelagem visual completa, buscando atingir os seguintes aspectos:
Disponibilizao de mecanismos de especificaes que possam expressar os nveis
conceituais.

Independncia de processos de desenvolvimento e linguagens de programao.

Incentivo do crescimento das aplicaes desenvolvidas no conceito da orientao a
objetos.
Permisso de suporte a conceitos de desenvolvimento de alto nvel, tais como
frameworks, padro e componentes.
O processo de desenvolvimento do software no est previsto na UML, o que a torna,

portanto, uma linguagem de modelagem e no um mtodo; no entanto, pode-se eleger
em termos genricos cinco etapas para o desenvolvimento de software em que a UML
pode ser aplicada: anlise de requisitos, anlise sistmica, projeto, implementao e
testes/implantao.
1.3.1
ANLISE DE REQUISITOS
O levantamento de requisitos deve ser a primeira etapa a ser desenvolvida, uma vez que
reunir os subsdios necessrios para as etapas seguintes. Na anlise de requisitos se
verificam quais so os problemas e desejos do usurio com relao ao software que ser
desenvolvido. medida que o levantamento de requisitos realizado, pode-se fazer
uma modelagem das atividades encontradas, empregando-se para isso o diagrama usecase. Esse diagrama permite a representao da relao do software com o ambiente
externo a ele, demonstrando tudo aquilo que ter alguma responsabilidade frente ao
software (pessoas, departamento e outros sistemas). As pessoas, departamentos e outros
sistemas so considerados entidades externas diante do software que ser desenvolvido
e, em geral, tm alguma relao com ele. A UML, a ttulo de generalizao de conjunto
de coisas, utiliza um esteretipo chamado ator (actor). Dessa maneira, as pessoas, os
departamentos e outros sistemas so denotados como atores externos. Os atores
externos tm alguma relao com o sistema. Essa relao sempre denota uma
responsabilidade que pode ser modelada no diagrama use-case. A relao entre atores
e o sistema tem vnculo a uma funcionalidade do software que ser desenvolvido, de
maneira que se pode antecipadamente conhecer o que dever existir no software, sem a
preocupao de como isso ser implementado.
1.3.2
ANLISE SISTMICA
Durante a anlise sistmica ser feito um estudo de todos os dados e processos

verificados na fase anterior (levantamento de requisitos), de maneira que se faam
abstraes para identificao de classes, seus atributos e mtodos. As classes devero
ser apresentadas em um modelo de maneira que se visualize a estrutura e a forma em
que elas devero interoperar, para tanto, poder ser empregado o diagrama de classes.
Na anlise sistmica s sero modeladas classes que pertenam ao domnio principal do
problema, ou seja, classes tcnicas que gerenciem banco de dados, interface,
comunicao, concorrncia e outros que no estaro presentes nesse diagrama.
1.3.3
PROJETO
Nesta etapa extrapola-se o domnio principal do problema do software. Outras classes

podem ser adicionadas ao modelo existente para propiciar uma infra-estrutura
tecnolgica, como a interface do usurio e dos perifricos, o gerenciamento de banco de
dados, a comunicao com outros sistemas etc. Trata-se de um aprimoramento da etapa

anterior, cujo resultado ser um detalhamento das especificaes para que seja possvel
a programao do software.
1.3.4
IMPLEMENTAO
Nesta fase ocorre a codificao dos programas de computador, naturalmente

empregando uma linguagem orientada a objetos. Essa codificao deve inicialmente
estar ocorrendo automaticamente, convertendo-se o modelo de classe para o cdigo da
linguagem escolhida. Essa converso automtica ser possvel dependendo do software
CASE que esteja sendo utilizado. No momento, a converso realizada pelos softwares
CASE, do modelo de classes para uma linguagem, gera apenas a espinha dorsal do
cdigo. Ainda h a necessidade de interveno manual para a criao do software. O
que se realiza nas etapas anteriores a esta apenas a criao de modelos que traduzem
tecnicamente o significado do entendimento e da estrutura do sistema. A programao
o desfecho onde os modelos criados ganham vida.
1.3.5
TESTES E IMPLANTAO
Todo software codificado deve sofrer rigoroso e exaustivos testes na busca de erros e
conseqente eliminao dos mesmos. So quatro aspectos que devem ser abordados
nesta etapa. O primeiro aspecto so os testes de unidade, onde cada programa,
individualmente, testado. Posteriormente, quando todos os programas tiverem sido
testados, faz-se um teste de conjunto. Nada garante que, apesar de terem funcionado
individualmente, iro se comportar bem quando executados em conjunto (pois nessa
situao outros fatores esto relacionados, performance, compartilhamento etc). Se tudo
estiver certo, deve-se partir para testes de integrao, quando o software criado estiver
algum mecanismo de interface com outros sistemas. Por ltimo ser o teste de
adequao aos requisitos, com o envolvimento direto do usurio, o qual dar a
aprovao final, quando ento o software poder ser implantado.

2. NOTAO DA UML
Como impossvel representar um sistema na sua completude por meio de um nico
diagrama, necessrio um conjunto de recursos que expresse os diversos aspectos que
compem o sistema. Pensando neste contexto, a UML possibilita empregar vrias
notaes grficas que buscam caracterizar o sistema na sua totalidade. O sistema
descrito em facetas (vises), em cada qual observa-se um aspecto particular do sistema,
a juno dessas vises mostram o sistema na sua totalidade. Cada viso est composta
por um conjunto de diagramas que retratam a particularidade enfatizada pela viso.
2.1 DIAGRAMA DE CASOS DE USO (USE CASES)
O diagrama usado para descrever o que um novo sistema dever fazer ou para
descrio de um sistema j existente, podendo mostrar como o sistema se comporta em
vrias situaes que podem ocorrer durante sua operao. Deve prever todas as
operaes que vier a disponibilizar. Naturalmente, por operao, subentende-se macro
como procedimentos tm um objetivo completo dentro do contexto geral, por exemplo,
em sistema de vendas, cadastrar pedidos seria uma operao, cadastrar cliente outra.
Originalmente o diagrama foi criado por Ivar Jacobson, baseado em suas experincias
no desenvolvimento de um sistema para a Ericsson com a utilizao dos mtodos OOSE
e Objectory. Considerando as cinco fases de desenvolvimento de sistemas mencionadas
(anlise de requisitos, anlise sistmica, projeto, implementao e implantao), o
diagrama Use Case est relacionado com a primeira delas, pois os casos de usos so
aplicados para capturar os requisitos solicitados pelo cliente. Por meio dessa
modelagem pode-se ter um contexto de como ser o funcionamento do sistema, sem se
preocupar com a implementao do mesmo. Trata-se de um primeiro nvel de abstrao
acerca do sistema.
Um diagrama um diagrama de caso de uso representa uma coleo de use e ator,
permite a representao da relao existente entre eles e, com isso, especifica ou
caracteriza a funcionalidade e o comportamento de um sistema. A construo de
modelos de casos de uso feita a partir de vrias discusses entre as pessoas envolvidas
com o sistema a ser modelado: desenvolvedores, clientes e usurios finais. necessrio
um esforo muito grande do analista de sistemas no sentido de reunir todas as
informaes necessrias sobre cada aspecto que est sendo entendido e avaliado do
sistema.
Os clientes e os usurios finais tm interesse nesse tipo de modelagem, pois ela
representa toda a funcionalidade do sistema e descreve como ele ser usado; sua
participao durante a modelagem fundamental, uma vez que um analista de sistema
ser um agente que transcrever aquilo que entender sobre a realidade exposta pelos
clientes/usurios e suas necessidades, em especificaes tcnicas que devem retratar tal
realidade. Naturalmente, na medida em que a modelagem vai sendo construda, ser
constantemente adaptada de forma a refletir em detalhes as necessidades de
clientes/usurio. Mais uma vez, embora enfadonha ressaltar, o processo de feedback
imprescindvel. O analista de sistemas deve sempre repassar o que entendeu com os
usurios envolvidos no problema.

importante que na modelagem a ser construda seja especificado os limites do
sistema, definidos pela funcionalidade que exigida do software. A funcionalidade de
todo o sistema representada por um conjunto de casos de uso que retratam a
funcionalidade completa esperada para o sistema. Cada caso de uso por sua vez deve ser
extensivamente avaliado, para encontrar todas as possveis situaes de uso daquela
funcionalidade que est sendo modelada.
Pode-se dizer que, no diagrama de caso de uso, o sistema se parece com uma caixa
preta que oferece funcionalidades. No momento da construo do diagrama, no se
deve ter a preocupao quanto aos aspectos de implementao, visto que os principais
objetivos da representao so:
Captar (entender) a funcionalidade necessria para resoluo dos problemas
existentes, sob a tica do cliente ou usurios.
Mostrar uma viso funcional coesa sobre tudo o que o software dever fazer, pois
esse diagrama ser a base para todo o processo de desenvolvimento.
Dever ser aplicado para testes de validao ( O software quando pronto realmente
possui a funcionalidade inicialmente planejada).
Propiciar facilidades para a transformao dos requisitos funcionais em classes e
operaes reais do software.
Para a criao do diagrama de use case, pode-se utilizar um caminho constitudo das
seguintes etapas:
Definio do sistema e entendimento macro de seus objetivos.
Identificar os possveis atores (quem exerce alguma atividade pertinente ao sistema)
e os casos de uso existentes (atividades que envolvem os atores identificados).
Detalhar vrias situaes de funcionalidade para os casos de uso.
Estabelecer os relacionamentos entre os elementos.
Checar o modelo com usurios e clientes.
O diagrama de casos de uso deve descrever o sistema, seu ambiente e a relao entre os
dois. Os componentes desse diagrama so os atores e os casos de uso propriamente
dito, conforme mostra a Figura abaixo.
Ator
Use Case
Figura 1. Ator e caso de uso

Pessoas, departamentos e mesmo equipamentos, que possam de alguma forma interagir
com o sistema que est sendo modelado, so considerados uma entidade externa ao
sistema, constituindo-se o que chamado de ator (actor). Visto que os atores
representam as entidades externas do sistema, eles ajudam a delimit-lo e fornecem uma
viso clara do que ser realizado. Os use case so desenvolvidos de acordo com os
eventos que ocorrem entre as entidades externas e o sistema.

Um ator representa um tipo de objeto (pessoas, departamentos, mquinas) que interage
diretamente com o sistema. Cada ator deve ter um nome, como, por exemplo
AtorCliente, mostrado na Figura abaixo.
AtorCliente
Figura 2. Esteretipo de ator
Actor na UML a representao de um esteritipo (stereotype). Um stereotype tem a
capacidade de criar um tipo de elemento de modelagem. Um stereotype representa a
metaclassificao de um elemento, ou seja, mostra uma classe dentro do metamodelo da
UML (isto , um tipo de elemento de modelagem). Embora existam stereotypes j
definidos, novos tipos podem ser adicionados.
Qualquer entidade externa ao sistema representado pelo esteritipo ator, de maneira
que apresenta as seguintes caractersticas:
Ator externo ao sistema, pode oper-lo; porm, no parte dele. Representa os
papis que algum pode desempenhar interagindo com o sistema.
Ator pode interagir ativamente com o sistema ou com outros atores.
Ator pode receber informaes do sistema.
Ator pode representar departamento, uma empresa, um ser humano, uma mquina
ou outro sistema.
Um ator tipo de objeto (uma possvel classe) e no uma instncia. O ator retrata um
papel e no um usurio em particular que tenha alguma relao com o sistema. Em uma
biblioteca universitria, caso Joaquim queira emprestar um livro, estamos diante de uma
atividade desenvolvida pelo papel de usurio da biblioteca. sobre o papel de usurio
que se est interessado conhecer quando modela-se um ator. Modela-se o
comportamento diante do sistema, e no a pessoa propriamente dita, como no caso
Joaquim, pois, assim como ele, tambm a Maria no papel de usuria pode fazer a
mesma coisa. Dependendo do seu papel em um sistema, uma pessoa pode ser vrios
atores. Os papis que algum pode ter no sistema tambm podem ser restringidos. Por
exemplo, na mesma biblioteca mencionada, uma mesma pessoa pode ser proibida de ter
um livro emprestado se ao mesmo tempo ela tambm exercer o papel (for o ator)
atendente do balco.
Os nomes atribudos aos atores devem refletir a generalidade dos papis que
desempenham e no uma instncia especfica.
Os atores devem ser investigados em todos os seus atributos que, de alguma maneira, se
exige que o sistema venha a conhecer. No caso de um usurio de uma biblioteca, pode
ser necessrio que se conhea sobre o ator usurio atributos como: RG, nome, endereo,

telefone. Esses atributos devero compor parte do encapsulamento de uma classe
(conforme ser cisto adiante).
Usurio
- RG
- Nome
- Endereo
- Telefone
+ Cadastrar()
+ Consultar()
+ ListarFicha()
Usurio
Figura 3. Classe derivada de um ator

Como os atores podem dar origem a classes, eles podem ter os mesmos relacionamentos
existentes entre as classes (conforme ser visto adiante no diagrama de classes). Nos
diagramas de casos de uso, apenas os relacionamentos de generalizao so usados para
descrever um comportamento comum entre um nmero de atores.
Usurio
Alunos
Professores
Outros (Externos
a Universidade)
Figura 4. Notao de herana entre atores

De acordo com a definio dada pela UML, um caso de uso um conjunto de
seqncias de aes que um sistema desempenha para produzir um resultado observvel
de valor a um ator especfico. Portanto, um caso de uso representa uma funcionalidade
completa na percepo de um ator. Emprestar um livro, por exemplo, trata-se de uma
funcionalidade do sistema de biblioteca, sob a tica do ator usurio.
Um caso de uso uma atividade ou procedimento composto por uma seqncia de
aes que o sistema executa, revela um padro de comportamento, acionado em geral

por um ator e produz um resultado que contribui para os objetivos do sistema. Algumas
caractersticas de casos de uso so descritas a seguir:
Um caso de uso modela a interao entre os atores e o sistema, ou mesmo entre
casos de uso.
Um caso de uso ativado por um ator ou por um outro caso de uso para acionar uma
certa funo do sistema, como por exemplo cadastrar fornecedor.
Um caso de uso um fluxo de eventos completo e consistente (conjunto de
operaes que se completam, atingindo um objeto).
Todos os casos de uso juntos representam todas as situaes possveis de utilizao
do sistema e mostram toda a funcionalidade existente disponvel no sistema.
Aps a definio dos atores (ainda que nem todos tenham sido descobertos a priori), os
casos de uso podem ser identificados seguindo-se um roteiro que compreende as
seguintes questes:
O software precisar ter quais funes para satisfazer as necessidades de um ator? O
que o ator precisa fazer?
Um ator precisar ter acesso ou informar dados do software? O ator precisa ser
notificado sobre os eventos no sistema ou o ator que precisa notificar o sistema
sobre algo?
possvel simplificar ou melhorar o trabalho do ator mediante a incluso de novas
funes ao sistema, principalmente funes no automatizadas?
As questes acima pressupem como ponto de partida a existncia dos atores j
identificados. Deve-se acrescer as seguintes questes para completude da viso de casos
de uso, o que pode levar identificao de atores ainda no identificados:
De que entrada ou sada o sistema precisa? De onde elas vm e para onde vo?
Quais so os principais problemas com a implementao j existente do sistema?
Um use case visualmente mostrado como uma elipse com um nome, que poder ser
colocado acima, dentro ou abaixo do smbolo, como por exemplo, CadstrarCliente,
mostrado na Figura abaixo.
CadastrarCliente
CadastrarCliente
CadastrarCliente
Figura 5. Exemplos de use case
Para que um diagrama de caso de uso seja rigorosamente avaliado, emprega-se o
conceito de cenrio. Um caso de uso deve ser avaliado sob a tica de vrios cenrios, o
que permitir avaliar sua completude da funcionalidade. Deve-se criar tanto cenrios
quantos forem necessrios. Os cenrios so situaes de uso informal para validao do
sistema com relao ao caso de uso em particular.
A criao de cenrios decorrente da atividade de anlise e especificao dos
requisitos, os quais agora so modelados. Antes de descrever os cenrios, o analista
deve ter entrevistado o cliente e os usurios, bem como feito as observaes in loco

necessrias, de maneira que se tenha certeza quanto ao entendimento daquela situao
em particular, a qual ir retratar. As entrevistas feitas propiciaram aos usurios falarem
sobre suas tarefas e os problemas associados a cada uma delas. A observao direta in
loco realizada deve ter permitido que o analista tenha entendido a situao de uso como
ela realmente vem ocorrendo na prtica.
Os procedimentos do usurio (usurio versus atividades) pode ser melhor entendida
quando o analista procura descrever situaes do processo de trabalho, que consistem de
uma coleo de narrativas de situaes no domnio que favorecem o levantamento de
informaes, a identificao de problemas e a antecipao de solues. As atividades
realizadas pelas pessoas o foco dos cenrios a serem criados, uma vez que tal
procedimento possibilita uma perspectiva ampla quanto a visualizao dos problemas
atuais no domnio descrito.
A criao dos cenrios, alm do entendimento do domnio do problema, se presta a
estimular novos questionamentos, possibilitando que se encontre alternativas para o
desenvolvimento do software, o que implica que os cenrios, via de regra, no precisam
apresentar uma viso absolutamente precisa sobre a realidade. Novas caractersticas que
estejam sendo planejadas aos procedimentos existentes podem ser vislumbradas na
explorao dos cenrios. Como fica determinada a situao se for acrescido
determinado procedimento? Como fica a situao se o procedimento atual for realizado
de tal forma? Quais as conseqncias se for extinto determinado procedimento, ou se
pular-se determinada etapa, ou ainda forem incorporadas novas funcionalidades?
Aps a elaborao dos possveis cenrios, os quais certamente possuem certo grau de
impreciso, o analista deve reunir-se com os usurios envolvidos e validar sua
modelagem discutindo cada cenrio desenhado (para cada cenrio um diagrama de caso
de uso). Os diagramas podem ser afixados em quadros, na parede ou projetados por
recursos de datashow onde os participantes possam analis-los e fazer comentrios,
possivelmente redesenhando possveis trechos na medida em que o debate de idias se
realiza, modificando-se os cenrios existentes. Somente depois dessa discusso que
realmente o analista ter uma definio quanto aos possveis cenrios de uso de uma
determinada atividade no sistema, e s ento conseguir construir definitivamente os
diagramas de casos de uso para tais abordagens. Contudo, no se deve esquecer que o
cenrio obtido ir mudar com o tempo, pois os requisitos que deram origem a ele,
mudam; o que se espera que o software possa ir evoluindo (sem muitos traumas)
acompanhando os novos requisitos que viro a existir.
Necessariamente, no obrigatrio que o analista construa logo de incio todos os
diagramas de caso de uso para cada situao constatada, ou diante das sugestes de
funcionalidades ainda inexistentes, mas que devero estar disponveis no software a ser
construdo. Pode-se em um primeiro momento constuir cenrios empregando-se
narrativas textuais ou por meio de storyboards, muito embora, aparentemente, desenhar
os casos de uso menos dispendioso. As narrativas textuais podem ser descritas
livremente, identificando os agentes e as aes que eles participam, o problema neste
caso tentar evitar possveis ambigidades, uma vez que o texto livre.
O storyboarding um roteiro (textual), podendo-se fazer acompanhar de um quadro
ilustrativo da cena. Emprega-se na estruturao de propagandas de televiso e mesmo
no cinema. uma forma muito natural de lidar com a descrio de cenrio, porque

apresenta uma cena que foca uma situao, na qual so descritas as aes que os atores
desempenham. A ttulo de exemplo, segue uma forma de representao textual para
descrever cenrio e na seqncia a representao dos mesmos cenrios com aplicao
do diagrama de caso de uso.
Cena 1
Agentes Envolvidos
Usurio
Atendente
Usurio
Atendente
Usurio
Atendente
Bibliotecria
Usurio
Cena 2
Agentes Envolvidos
Usurio
Atendente
Usurio
Atendente
Usurio solicita um livro com um certo contedo

Usurio, Atendente e Bibliotecria
Usurio entra na biblioteca e dirige-se ao balco onde est a
atendente:
Eu gostaria de emprestar um livro sobre modelagem orientada
a objetos.
Algum ttulo especfico?
No, mas gostaria que abordasse o padro estabelecido pela
OMG.
Voc se recorda do nome desse padro?
No, esqueci.
A atendente pergunta bibliotecria:
Voc sabe o nome do padro que a PMG estabeleceu para a
modelagem orientada a objetos?
Hummm. Me lembro que uma sigla curta. Acho que comea
com U. UXL, no, no...UML acho que isso...
isso mesmo.
Em seguida, a atendente faz a consulta por palavra-chave e
descobre todos os livros disponveis que tm UML como
contedo. O cliente escolhe um e o leva emprestado.
Usurio procura livros sobre anlise e projeto de sistemas,
conhecendo alguns autores
Usurio, Atendente e Bibliotecria
Usurio entra na biblioteca e dirige-se ao balco onde est a
atendente:
Eu gostaria de emprestar livros sobre anlise e projeto de
sistemas.
Algum especfico? Algum autor?
Bem, pode ser do Chris Gane, Yourdon ou Coad.
Atendente procura para ver disponibilidades:
Temos esses aqui.
A atendente mostra quatro ttulos disponveis. O usurio
escolhe dois. A atendente encaminha o usurio bibliotecria
para os procedimentos de retirada dos livros. Depois de
preencher a ficha do usurio, registrando a retirada, a
bibliotecria passa os livros para o usurio.
Esses mesmos cenrios podem ser representados empregando-se o diagrama de casos de

uso. Deve-se escolher uma outra forma, desde que estejamos falando de um momento
inicial da anlise, antes da validao da modelagem, pelos envolvidos no cenrio. Aps

a validao, necessariamente deve ter-se o diagrama de casos de uso que representa o
processo.
CENRIO 1
Assunto desejado
Atendente
Usurio
Pede ajuda
Consulta livro por

palavras-chave
Bibliotecria
O usurio conhece o conteudo

que deseja, porem no sabe
dizer o titulo ou autor do livro.
A atendente tenta obter alguma

pista quanto a possveis termos
que sirvam para palavras-chave
de consulta
Figura 6. Primeiro cenrio
CENRIO 2
Ttulo genrico e autores
Mostra ttulos disponveis
Informa o que vai levar
Atendente
Usurio
Entrega livros
Passa os livros
Bibliotecria
O usurio sabe o titulo

genrico do livro e
aponta alguns autores.
A bibliotecria registra
a retirada dos livros
escolhidos e os passa
ao usurio..
Figura 7. Segundo cenrio
Consulta livro por

palavra-chave
A atendente mostra ao
usurio livros disponveis. Ao
receber um ok do usurio,
separa os livros desejados.

Aps os cenrios estarem desenvolvidos, o analista deve trabalhar em conjunto com os
usurios para avali-los e refin-los, pois tanto a forma descritiva textual quanto o
diagrama de casos de uso so amigveis. O analista pode explicar os cenrios aos
usurios para checar se a modelagem realmente retrata o que ocorre na realidade, ou se
retrata a nova funcionalidade ainda existente.
Quando se chegar a um modelo que os usurios tenham aprovado, deve-se desenhar um
diagrama de caso de uso que integre os cenrios; assim, considerando-se como exemplo
o caso de uso emprstimo do acervo se conseguiria a representao de um modelo
onde estaria previsto todas as possibilidades em termos de formas de emprstimo.
O resultado da modelagem por meio de cenrios uma base para a compreenso de
quem so os agentes (atores) envolvidos e quais as atividades que devem ser previstas
quanto a um aspecto particular do software que ser desenvolvido. Um software o
resultado da unio de vrios casos de usos, e cada um deles possui diversos cenrios a
serem investigados.
Nos exemplos de casos de uso apresentados, que representam cenrios de uma situao
de emprstimo de livros, verifica-se a existncia de relacionamento entre casos de uso e
atores. Esse relacionamento chamado de associao, que representado por uma
conexo semntica entre o caso de uso e o ator. As associaes so unidirecionais. O
nome da associao usado para identificar o propsito do relacionamento.
A Figura a seguir apresenta um diagrama de caso de uso com relacionamento de
associao: o ator Usurio relaciona-se por intermdio da associao Ttulo, Autor ou
Editora, com o use case Consultar Obras. O use case Consultar Obras relaciona-se com
o ator Usurio por meio da associao Obras Existentes.
Obras existentes
Titulo, autor ou editora

Usurio
Consultar obras
Dados da obra
Cadastrar obras
Bibliotecria
Dados locao
Locar obra
Figura 8. Exemplo relacionamento de associao

Casos de uso podem compartilhar aes executadas por outros casos de uso. Essa
situao expressa um relacionamento chamado de generalizao. A generalizao em
casos de uso empregada para descrever o comportamento comum entre dois ou mais
use cases; portanto, um dos mecanismos utilizados para identificar comportamentos
reutilizveis.
A Figura apresenta um diagrama de use case com relacionamento de generalizao: o
ator aluno conecta-se atravs do relacionamento de associao dados consulta, como o
use case Consulta Notas. O use case Consultar Notas conecta-se com o use case
Identificar Aluno, por meio do relacionamento de generalizao, o qual faz a
identificao do aluno. O caso de uso Consultar Notas relaciona-se com o aluno por
intermdio da associao notas.
Identificao do aluno
Aluno
Dados consulta
<<uses>>
Notas
Consultar notas
Figura 9. Exemplo de um relacionamento de generalizao

O relacionamento de generalizao da Figura est empregando o esteritipo << uses>>.
Esse esteritipo no relacionamento de generalizao indica que ser obrigatrio que o
caso de uso consultar notas acione o comportamento expresso pelo caso de uso
identificao do aluno. Outro esteritipo possvel de ser empregado em
relacionamentos de generalizao nos casos de uso o <<extends>>. Ele empregado
para expressar comportamento opcional por um use case. Por exemplo, a Figura
mostra uma generalizao <<extends>> do use case Consultar Notas para o use case
Atualizar dados cadastrais aluno. A generalizacao <<extends>> indica que o use case
Consultar Notaspoder ou no utilizar o use case Atualizar dados cadastrais aluno.

Identificao do aluno
Aluno
Dados consulta
<<uses>>
Notas
Consultar notas
<<extends>>
Atualizar dados cadastrais aluno
Figura 10. Exemplo de generalizao <<extends>>

Diagrama use case pode ser empregado para:
Capturar os requisitos do sistema e compreender o que o sistema faz.
Fase
Analise
Especificar o comportamento do sistema que ser implementado e/ou Projeto

especificar as semnticas do mecanismo do use case.
Tabela 1. Uso do diagrama use case
2.2 DIAGRAMA DE CLASSES
O diagrama de classes expressa a estrutura esttica de um sistema, pois aquilo que
descrito sempre vlido em qualquer ponto no ciclo de vida do sistema. No diagrama
de classes tambm mostrada a possibilidade de interaes entre classes, pois no se
constituem elementos isolados e com absoluta autonomia; na verdade, muitas tarefas
somente so possveis de serem realizadas pela colaborao existente entre as classes. A
notao padro usada pela UML para representar uma Classe de Objetos :
NomeClasse
<atributos>
<mtodos>
A classe de objeto representada por um retngulo, subdividido em trs reas. A
primeira contm o nome da classe, a segunda contm seus atributos e a terceira contm
seus mtodos (funes/procedimentos). Uma classe representa um conjunto de objetos
que tenham a mesma estrutura e comportamento. uma abstrao de objetos do mundo
real. Os objetos so instncias da classe. As classes so utilizadas para classificar os
objetos identificados no mundo real; sendo assim, elas devem ser retiradas do domnio
do problema e serem nomeadas pelo que elas representam no sistema. Essa atividade
deve ser feita por algum com muito conhecimento do domnio do problema. Ao

empregar-se o smbolo de classe, a UML prev uma sintaxe de desenho e escrita dos
elementos que a constituem, conforme a Figura abaixo.
PESSOA
- CodPessoa : Int
+ Nome : String
+ Sexo : Char = M
# DataNasc : Date
+ Cadastrar(Dados: String): Boolean
+ Consultar(CodPessoa: Int): String
- Eliminar(CodPessoa: Int): Boolean
Figura 11. Exemplo de uma classe
Ao escrever o nome de um atributo ou de um mtodo, a UML sugere uma sintaxe a ser
seguida.
Com relao aos atributos a proposta geral :
Visibilidade NomeAtributo: TipoDoAtributo = ValorDefault {propriedade}
Visibilidade
Trata-se de uma marcao que pode ser realizada pelos smbolos ( +, #, - ), ou ainda
pela aplicao de cones. O elemento visual a ser empregado deve indicar uma das
possibilidades abaixo:
( + ) Visibilidade pblica acessvel por todas as classes (trata-se do valor
default).
( # ) Visibilidade protegida pode ser visto pela classe e pelo pacote no qual a
classe definida.
( - ) Visibilidade privada somente acessvel pela prpria classe.
NomeAtributo
Seqncia de caracteres que devem formar um nome auto-explicativo criado pelo
analista que denota o contedo que se pretende armazenar. Tipicamente inicia-se
com uma letra.
TipoDoAtributo
Expressa o tipo de contedo que se pretende armazenar para o atributo. Como est
intimamente ligado linguagem de programao, a UML deixa definida a sintaxe
para esse elemento.
ValorDefault
Refere-se ao contedo inicial do atributo, de acordo com o seu tipo.

{propriedade}
Trata-se de um elemento opcional, que complementa informaes a respeito do
atributo, acomodando uma descrio sobre o atributo, representando claramente seu
propsito e domnio de valores.
Com relao aos mtodos, a sintaxe geral sugerida :
Visibilidade
Equivalente mesma representao utilizada para os atributos.
NomeDoMtodo
Palavra criada pelo analista que representa a operao que ser processada. Pode ser
formada pela concatenao de duas ou mais palavras: obterSaldo,
consultarDepositoBancrio, atualizarDados etc.
Parmetro
Tara-se de uma lista de valores devidamente separados por vrgula, pois, para cada
um, o mtodo tem uma necessidade claramente definida.
TipoDeRetorno
Equivalente definio existente para os atributos.
{propriedade}
Equivalente definio existente para os atributos.
Com base nos elementos padronizados para descrio visual de uma classe, um software
CASE poder ser capaz de entender a especificao visual e gerar um correspondente
trecho em cdigo-fonte, de acordo com uma linguagem de programao previamente
escolhida, conforme exemplo na Figura abaixo.

FUNCIONARIO
- codigo : Int
- nome : String
- telefone : String
- ativo : boolean
cadastrar(dados: String)
consultar(codigo: Int): String
public class Funcionario

{
private int codigo;
private String nome;
private String telefone;
private Boolean ativo;
public void cadastrar(String dados)
{
//inserir codigo do metodo aqui
}
public string consultar(ind codigo)
{
}
}
Figura 12. Transformao automtica de classe em cdigo-fonte (no caso, JAVA)

2.2.1 RELAES ENTRE CLASSES
As classes podem apresentar quatro tipos de relaes: herana, dependncia,
associao e agregao.
pessoa
cliente
modelo veculo
contrato de aluguel
veculo alugado
itens do contrato
Figura 13. Exemplo com relacionamento de associao e herana

Por herana, como relacionamento entre classes, subentende-se que a subclasse
compartilha toda a estrutura e o comportamento da superclasse (classe me ou
metaclasse). Na figura 13, o cliente herda a estrutura e o comportamento da pessoa, lProf. Marcelo Nogueira

se cliente -uma pessoa. A notao de herana uma forma de representar
hierarquias entre classes, mostrando uma estrutura do mais geral ( generalizao) para
algo mais especfico (especializao).
Na Figura 13, a classe Veculo alugado depende da existncia do modelo veculo.
Essa notao indica que, se houver uma mudana em algum objeto da classe
independente (modelo de veculo, no exemplo), pode afetar outro objeto da classe
dependente (Veculo alugado).
A classe contrato de aluguel um agregado de itens do contrato. A Figura 13
tambm mostra uma relao de associao entre contrato de aluguel e cliente, bem
como entre contrato de aluguel e veculo alugado. Todos esses tipos de relaes so
explicados em maiores detalhes a seguir.
Relacionamento de herana
O relacionamento de herana induz a dois conceitos bsicos, conforme mostra a Figura

14. Nas laterais da figura esto dispostos graficamente os conceitos inerentes ao
relacionamento entre as classes pessoa, cliente e fornecedor. Pessoa uma
generalizao de cliente e fornecedor, ou seja, tanto cliente quanto fornecedor possui
atributos e mtodos comuns. Cliente ou Fornecedor um tipo de pessoa (sua
especializao). A classe raiz (genrica) chamada de classe me, superclasse ou
metaclasse. A classe que herda as caractersticas da classe me chamada de subclasse
ou classe filha.

Generalizao
Pessoa
SuperClasse
CodigoIdentificacao
Nome
Telefone
Endereco
+ Cadastrar( )
+ Consultar( )
+ Atualizar( )
Especializao
SubClasse
Cliente
- EndCobranca
- Credito
Fornecedor
+ SaldoPagar( )
+ AvaliarCredito( )
Figura 14. Exemplo de relacionamento de herana entre classes

(generalizao/especializao)
Relacionamento de dependncia
Um relacionamento de dependncia entre duas classes mostra que uma instncia de uma
classe depende da instncia de outra classe, normalmente chamada cliente/servidora
respectivamente. Por exemplo, a Figura 13 mostra que a classe Veculo Alugado
depende da classe Modelo Veculo para existir; denota-se no caso especfico que um
veculo para ser alugado s existir se houver um modelo daquele veculo previamente
existente. Um outro exemplo de dependncia representado por uma lista de presena
em aulas, conforme a Figura 15.

Disciplina
Alunos
ListaDePresenca
Data
Horario
TotalAlunosPresentes
presente(alu:Alunos, disc:Disciplina)
ausente(alu:Alunos, disc:Disciplina)
Figura 15. Exemplo de dependncia
Uma instncia da classe ListaDePresena (Figura 15) depende de Alunos e Disciplinas,
pois seu mtodo presente utilizar a informao de aluno e de disciplina, cujo objetivo
marcar como presente um aluno em uma determinada disciplina, em uma data e horrio;
caso exista uma marcao indevida, o mtodo ausente ser acionado para corrigir a
situao.
Relacionamento de associao
Um relacionamento de associao representa uma conexo semntica entre duas classes

e o relacionamento mais utilizado. bidirecional e representado por uma linha
ligando as classes. Na Figura 13 tem-se o relacionamento de associao entre o
contrato de aluguel e a classe cliente, alm de contrato de aluguel com a classe
veiculo alugado.
O relacionamento de associao representa uma dependncia estrutural entre objetos;
em geral, provenientes de classes diferentes, pode possuir um nome que deve estar
prximo a linha que representa a associao. Uma associao pode apresentar o
conceito de multiplicidade (conforme a Tabela 2) e navegabilidade conforme o exemplo
da Figura 16.
Aluno
0..*
Matricula
Faz
Figura 16. Exemplo de associao binria

A associao com navegabilidade (ponta de seta) indica que, ao estabelecer uma
associao, a mesma s pode ocorrer na direo indicada pela ponta de seta. No
exemplo da Figura 16, tem-se uma associao binria, mas ainda possvel encontrar-se
outros tipos de associao: unria e ternria (Figura 17).
Projetos
Gerncia
Pr-requisitos
Funcionrios
Funcionrio
Avaliao
Associao Unria
Associao Ternria
Figura 17. Associao unria e ternria

A associao unria tambm conhecida como associao recursiva, pelo fato de ser
um relacionamento entre objetos da mesma classe. As associaes no esto limitadas
ao conjunto de trs classes participantes (ternria), como o exemplo da Figura 17 pode
induzir. Pode-se representar associaes n-ria, embora isso no seja comum.
Relacionamento de agregao
Um relacionamento de agregao uma forma especial de associao, que usada para

mostrar que um tipo de objeto composto de outro objeto. Um relacionamento de
agregao tambm chamado de todo-parte. Conforme mostra a Figura 18, Pedido
um agregado de itens do Pedido. O relacionamento de agregao possui duas formas
de representao, com significados diferentes. A agregao por valor (losango cheio)
indica que o tempo de vida das partes so dependentes do tempo de vida do todo. Um
item de pedido existe quando existe o pedido, e vice-versa. Na agregao por
referncia (losango sem preenchimento0, o tempo de vida das partes no so
mutuamente dependentes do tempo de vida do todo.
Pedido
1..*
ItensPedido
Contm
Disciplinas
Curso
Salas
Figura 18. Exemplo de agregao

2.2.2 MULTIPLICIDADE
Nos relacionamentos de associao e de agregao, pode-se acrescentar a multiplicidade
(similar cardinalidade na modelagem estruturada), que especifica o nmero de
instancias de uma classe em relao a outra em um relacionamento, por meio do nmero
mnimo e mximo. A tabela 2 resume as possveis variaes da multiplicidade, onde
<literal> qualquer inteiro maior ou igual a 1.
Notao
0..1
Significado
Zero ou uma instncia
Somente uma instncia
0..*
Zero ou mais instncias
Default, numero mnimo e mximo de instncia so ilimitados
1..*
Uma ou mais instncias
<literal>..*
Numero exato ou mais instncias

Tabela 2. Notaes da multiplicidade
2.2.3 INTERFACE
H um tipo de classe a qual no pode ser instanciada, ou seja, no se conseguir gerar
objetos diretamente dela, o que a torna uma classe virtual, servindo apenas para
especificar as operaes externamente visveis para uma classe. Uma interface descreve
os padres legais de interao entre dois objetos. A interface funciona como uma classe
modelo, que outras classes podero fazer uso, implementando as funcionalidades
descritas.
<interface>
ContratoModelo
emitirTexto(txt: String)
<<implementa>>
ContratoVenda
emitirTexto(txt: String)
public interface ContratoModelo

{
public void emitirTexto(String txt);
}
public class ContratoVenda implements
Contrato Modelo
{
public void emitirTexto(String txt)
{
}
}
Figura 19. Exemplo da classe Interface

2.3 DIAGRAMA DE INTERAO
Todos os aspectos vistos at este momento foram derivados de dois diagramas bsicos:
diagramas de casos de uso e diagrama de classes. Pode-se dizer que tais diagramas
representam a parte esttica de um sistema e, portanto, no esto qualificados para
representar temporais ou de colaborao que possam existir entre os objetos das classes.
O diagrama de interao na verdade no existe; um termo genrico aplicado juno
de dois outros diagramas: seqncia e colaborao. O diagrama de interao visa
construir a modelagem comportamental ou dinmica do sistema. Isso possvel atravs
dos diagramas de seqncia e colaborao que juntos conseguem demonstrar o
comportamento dos objetos, considerando-se a seqncia da troca de mensagens
existentes entre eles, para que se cumpra um determinado papel ou se atenda a
determinado contexto. Ao trocar mensagens para atingir determinado objetivo, se
estabelece um contexto de colaborao entre os objetos.
Os diagramas de seqncia e colaborao favorecem a identificao de
responsabilidades que as classes podero ter, uma vez que as mensagens trocadas pelos
objetos correspondem a mtodos que devem estar previstos nas respectivas classes.
Para avaliar uma interao, necessrio eleger um caso de uso. Com foco em um caso
de uso especfico, se busca identificar quais objetos participam da interao. Na medida
em que se vai identificando os objetos envolvidos, percebe-se a forma como eles esto
relacionados, o que vem facilitar o entendimento de como deve-se estabelecer
associaes entre classes no diagrama de classes, bem como quais mtodos devam
existir para determinadas classes.
Diagrama de seqncia
No diagrama de seqncia mostra-se a interao entre objetos com a preocupao de

documentar os mtodos (funes/procedimentos) executados ao longo do tempo,
conforme mostra a Figura 20.
Diagramas de seqncia documentam interao organizada em uma seqncia de tempo
entre os objetos participantes de uma operao e as trocas de mensagens entre eles. Um
diagrama de seqncia possui duas dimenses: vertical, que representa o tempo; e
horizontal, que representa o tempo; e horizontal, que representa diferentes objetos (se
for necessrio, as dimenses podem ser invertidas).

Computador
Servidor de
impresso
Imprimir(arquivo)
Fila de
impresso
Impressora
[se livre] imprimir (arquivo)
guardar (arquivo)
Figura 20. Exemplo de generalizao diagrama de seqncia
Diagrama de colaborao
um modo alternativo para representar a troca de mensagens entre um conjunto de

objetos, mostra a interao organizada em torno dos objetos e suas ligaes uns com os
outros, sem a preocupao de expressar a vida til das mensagens no tempo. O
diagrama de colaborao no mostra a dimenso do tempo, por isso as seqncias de
mensagens e linhas concorrentes devem ser determinadas usando a seqncia de
nmeros.

Computador
1 - imprimir (arquivo)
Servidor de impresso
3 impresso ok
2 imprimir, se impressora livre
Impressora
4 aguardar, se impressora ocupada
5 arquivo aguardando impresso
Fila
Figura 21 Exemplo de diagrama de colaborao

2.4 DIAGRAMA DE ESTADO
Normalmente, um sistema aberto reage a estmulos provenientes de fora dele ou ainda
estmulos temporais por ele mesmo desencadeado. Essa reao pode originar respostas
externas ao sistema. Essa dinmica existente nos sistemas fruto da colaborao entre
objetos, os quais estaro em determinado estado em um certo momento no tempo.
O Diagrama de Estados usado para mostrar os possveis estados dos objetos de uma
classe. A mudana de um estado para outro chamado de transio de estados. Os
eventos do diagrama de estados causam uma transio de um estado para outro e as
aes resultam na mudana de estado. Cada diagrama de transio de estados est
associado a uma classe ou a um diagrama de transio de estados de um nvel mais alto.
O incio de um diagrama de estados indicado pelo chamado estado inicial, cuja
representao grfica um circulo preenchido. Na verdade, ele no expressa um estado
especifico do objeto da classe, indica apenas o inicio do diagrama. Na seqncia, se
conecta o primeiro estado real com uma transio, rotulada ou no. Em cada diagrama
de estado h somente um estado inicial. A notao grfica de um estado inicial
mostrada no Figura 22.
Primeiro estado real
Figura 22. Exemplo de estado inicial

Um estado demonstra uma situao no tempo de algum aspecto do sistema sobre o qual
existe interesse de controle. Durante a vida de um objeto, pode vir a existir controle
sobre vrias situaes, cada qual podendo assumir diversos estados possveis no tempo.
Um objeto permanece em um estado por um tempo finito. A notao grfica e um
exemplo de estado so mostrados na Figura 23.
matriculado
cursando disciplina
aprovado
reprovado
Figura 23. Representao de um estado do objeto

O estado final representa a termino do ciclo previsto de controle para mudanas de
estados de um dos aspectos do sistema. Na figura 24 verifica-se a representao grfica
do estado final, mediantes dois crculos, sendo o interno totalmente preenchido.
A mudana de um estado para outro chamado de transio de estados. Trata-se de um
relacionamento entre dois estados. Para o objeto passar de um estado para outro,
necessrio dois mecanismos: condio e ao. A condio, se existir, dever ser
satisfeita para que a ao seja executada. Essa ao responsvel pela transio dos
estados.
matriculado
cursando disciplina
matricular
aprovado
aprovar
(qtd faltas,media)
matricular
reprovar
(qtd faltas,media)
Concluso curso
reprovado
Desistncia
Figura 24. Exemplo de transio de estados

TONSIG, Srgio Luiz, Engenharia de Software, Ed. Futura, 2003, So Paulo.

Uml

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Uml

Hochgeladen von

Copyright:

Verfügbare Formate

UNIP Universidade Paulista

Cincia da Computao e Sistemas de Informao

Figura: Vrios aspectos a serem considerados em uma modelagem

Prof. Marcelo Nogueira

UNIP Universidade Paulista

UNIP Universidade Paulista

Prof. Marcelo Nogueira

UNIP Universidade Paulista

Independncia de processos de desenvolvimento e linguagens de programao.

O processo de desenvolvimento do software no est previsto na UML, o que a torna,

Durante a anlise sistmica ser feito um estudo de todos os dados e processos

Nesta etapa extrapola-se o domnio principal do problema do software. Outras classes

Prof. Marcelo Nogueira

UNIP Universidade Paulista

Nesta fase ocorre a codificao dos programas de computador, naturalmente

Prof. Marcelo Nogueira

UNIP Universidade Paulista

Prof. Marcelo Nogueira

UNIP Universidade Paulista

Figura 1. Ator e caso de uso

Prof. Marcelo Nogueira

UNIP Universidade Paulista

Prof. Marcelo Nogueira

UNIP Universidade Paulista

Figura 3. Classe derivada de um ator

Figura 4. Notao de herana entre atores

Prof. Marcelo Nogueira

UNIP Universidade Paulista

UNIP Universidade Paulista

Prof. Marcelo Nogueira

UNIP Universidade Paulista

Usurio solicita um livro com um certo contedo

Esses mesmos cenrios podem ser representados empregando-se o diagrama de casos de

Prof. Marcelo Nogueira

UNIP Universidade Paulista

Consulta livro por

O usurio conhece o conteudo

A atendente tenta obter alguma

Figura 6. Primeiro cenrio

O usurio sabe o titulo

Figura 7. Segundo cenrio

Prof. Marcelo Nogueira

Consulta livro por

UNIP Universidade Paulista

Titulo, autor ou editora

Figura 8. Exemplo relacionamento de associao

Prof. Marcelo Nogueira

UNIP Universidade Paulista

Figura 9. Exemplo de um relacionamento de generalizao

Prof. Marcelo Nogueira

UNIP Universidade Paulista

Figura 10. Exemplo de generalizao <<extends>>

Especificar o comportamento do sistema que ser implementado e/ou Projeto

Prof. Marcelo Nogueira

UNIP Universidade Paulista

UNIP Universidade Paulista

Com relao aos mtodos, a sintaxe geral sugerida :

Prof. Marcelo Nogueira

UNIP Universidade Paulista

public class Funcionario

Figura 12. Transformao automtica de classe em cdigo-fonte (no caso, JAVA)

Figura 13. Exemplo com relacionamento de associao e herana

UNIP Universidade Paulista

O relacionamento de herana induz a dois conceitos bsicos, conforme mostra a Figura