Uml

UNIP Universidade Paulista Cincia da Computao e Sistemas de Informao

Prof. Marcelo Nogueira

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.

Figura: Vrios aspectos a serem considerados em uma modelagem

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



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 use-case. 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.

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.

Ator Use Case



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.

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,

AtorCliente



telefone. Esses atributos devero compor parte do encapsulamento de uma classe (conforme ser cisto adiante).

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.

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

Usurio - RG - Nome - Endereo - Telefone + Cadastrar() + Consultar() + ListarFicha() Usurio

Usurio

Alunos Professores Outros (Externos a Universidade)



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.

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

CadastrarCliente

CadastrarCliente

CadastrarCliente



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 Usurio solicita um livro com um certo contedo Agentes Envolvidos Usurio, Atendente e Bibliotecria Usurio entra na biblioteca e dirige-se ao balco onde est a

atendente: Usurio Eu gostaria de emprestar um livro sobre modelagem orientada

a objetos. Atendente Algum ttulo especfico? Usurio No, mas gostaria que abordasse o padro estabelecido pela

OMG. Atendente Voc se recorda do nome desse padro? Usurio No, esqueci. A atendente pergunta bibliotecria: Atendente Voc sabe o nome do padro que a PMG estabeleceu para a

modelagem orientada a objetos? Bibliotecria Hummm. Me lembro que uma sigla curta. Acho que comea

com U. UXL, no, no...UML acho que isso... Usurio 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.

Cena 2 Usurio procura livros sobre anlise e projeto de sistemas, conhecendo alguns autores

Agentes Envolvidos Usurio, Atendente e Bibliotecria Usurio entra na biblioteca e dirige-se ao balco onde est a

atendente: Usurio Eu gostaria de emprestar livros sobre anlise e projeto de

sistemas. Atendente Algum especfico? Algum autor? Usurio Bem, pode ser do Chris Gane, Yourdon ou Coad. Atendente procura para ver disponibilidades: Atendente 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.

Figura 6. Primeiro cenrio

Figura 7. Segundo cenrio

CENRIO 2

Usurio

Consulta livro por palavra-chave

Atendente

Bibliotecria

Ttulo genrico e autores

Passa os livros

O usurio sabe o titulo genrico do livro e aponta alguns autores.

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

Mostra ttulos disponveis Informa o que vai levar

Entrega livros

A bibliotecria registra a retirada dos livros escolhidos e os passa ao usurio..

CENRIO 1

Usurio

Consulta livro por palavras-chave

Atendente

Bibliotecria

Assunto desejado

Pede ajuda

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



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.

Figura 8. Exemplo relacionamento de associao

Usurio Consultar obras

Bibliotecria

Titulo, autor ou editora

Cadastrar obras

Locar obra

Dados locao

Dados da obra

Obras existentes



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.

Figura 9. Exemplo de um relacionamento de generalizao

O relacionamento de generalizao da Figura est empregando o esteritipo >. 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 . Ele empregado para expressar comportamento opcional por um use case. Por exemplo, a Figura mostra uma generalizao do use case Consultar Notas para o use case Atualizar dados cadastrais aluno. A generalizacao indica que o use case Consultar Notaspoder ou no utilizar o use case Atualizar dados cadastrais aluno.

Aluno

Identificao do aluno

Notas Consultar notas

Dados consulta



Figura 10. Exemplo de generalizao

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 :

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

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

Projeto

NomeClasse

Aluno

Identificao do aluno

Dados consulta

Notas Consultar notas

Atualizar dados cadastrais aluno



empregar-se o smbolo de classe, a UML prev uma sintaxe de desenho e escrita dos elementos que a constituem, conforme a Figura abaixo.

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.

PESSOA - CodPessoa : Int + Nome : String + Sexo : Char = M # DataNasc : Date + Cadastrar(Dados: String): Boolean + Consultar(CodPessoa: Int): String - Eliminar(CodPessoa: Int): Boolean



{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.



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.

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, l-

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

pessoa

cliente

contrato de aluguel

itens do contrato

modelo veculo

veculo alugado

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) { //inserir codigo do metodo aqui } }



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.



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.

Generalizao

Especializao

SuperClasse

SubClasse

Pessoa

+ Cadastrar( ) + Consultar( ) + Atualizar( )

- CodigoIdentificacao - Nome - Telefone - Endereco

Cliente

+ AvaliarCredito( )

- EndCobranca - Credito

Fornecedor

+ SaldoPagar( )



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.

Figura 16. Exemplo de associao binria

Aluno

Matricula

0..* 1 Faz

Disciplina

Alunos

ListaDePresenca

presente(alu:Alunos, disc:Disciplina) ausente(alu:Alunos, disc:Disciplina)

Data Horario TotalAlunosPresentes



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).

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.

Figura 18. Exemplo de agregao

Pedido

ItensPedido

1..* 1 Contm

Curso

Disciplinas

Salas

Projetos Pr-requisitos Funcionrios

Avaliao

Associao Ternria

Funcionrio

Gerncia

Associao Unria

*

1



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 qualquer inteiro maior ou igual a 1.

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.

Figura 19. Exemplo da classe Interface

Notao Significado 0..1 Zero ou uma instncia 1 Somente uma instncia 0..* Zero ou mais instncias * Default, numero mnimo e mximo de instncia so ilimitados 1..* Uma ou mais instncias ..* Numero exato ou mais instncias

public interface ContratoModelo { public void emitirTexto(String txt); }

public class ContratoVenda implements Contrato Modelo { public void emitirTexto(String txt) { //inserir codigo do metodo aqui } }

ContratoModelo

emitirTexto(txt: String)

ContratoVenda

emitirTexto(txt: String)



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).



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.

Imprimir(arquivo) [se livre] imprimir (arquivo)

guardar (arquivo)

Computador Servidor de impresso Fila de

impresso Impressora



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.

Figura 22. Exemplo de estado inicial

Computador

Servidor de impresso

Impressora

Fila

3 impresso ok

5 arquivo aguardando impresso

1 - imprimir (arquivo)

2 imprimir, se impressora livre

4 aguardar, se impressora ocupada

Primeiro estado real



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.

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.

Figura 24. Exemplo de transio de estados

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

matriculado

cursando disciplina

aprovado reprovado

Concluso curso Desistncia

matricular matricular

reprovar (qtd faltas,media)

aprovar (qtd faltas,media)

matriculado

cursando disciplina

aprovado reprovado

Documents

Uml