Modelando Sistemas em UML - Casos de Uso

Neste artigo vou falar um pouco sobre modelagem de sistemas usando UML focando exclusivamente os diagramas de casos de uso . A primeira coisa que devemos ter em mente que os princpios aqui discutidos no se referem a uma linguagem especfica ; estamos focando claro a anlise orientada a objetos onde conceitos como encapsulamento de atributos e mtodos , alta coeso e baixo acoplamento , herana e polimorfismo devem esta bem assimilados. Vamos usar a UML que um modelo de linguagem que define uma notao que so todos os elementos de representao grfica vistos no modelo. Estamos pois na fase de anlise e no estamos preocupados com software nem hardware.

Caso de Uso - definies

Segundo Ivan Jacobson , podemos dizer que um caso de uso um "documento narrativo que descreve a sequncia de eventos de um ator que usa um sistema para completar um processo". Um caso de uso uma tcnica de modelagem usada para descrever o que um novo sistema deve fazer . Ele construdo atravs de um processo interativo no qual as discusses entre o cliente e os desenvolvedores do sistema conduzem a uma especificao do sistema da qual todos esto de acordo. Um caso de uso descreve as operaes que o sistema deve cumprir para cada usurio. Ele vai ajudar a formalizar as funes que o sistema precisa fazer. Um caso de uso se apresenta como uma lista completa das interaes entre um usurio e o sistema para cumprir uma tarefa. Lista completa significa que o caso de uso descreve as interaes desde o incio da tarefa, at o fim. Casos de uso tm que ser compreensveis por usurios por que s eles sabem o que o sistema precisa fazer. Os casos de uso permitem verificar se o desenvolvedor e o usurio concordam sobre o que o sistema deve fazer. Isso um problema importante no desenvolvimento de software. No mesmo tempo, casos de uso podem servir de "contratos'' entre os usurios e a equipe de desenvolvimento. Os casos de usam tem por objetivo : Decidir e descrever os requisitos funcionais do sistema. Fornecer uma descrio clara e consistente do que o sistema deve fazer. Permitir descobrir os requisitos funcionais das classes e operaes do sistema. (Casos de uso NO so requisitos)

Podemos dizer que os componentes de um modelo de casos de uso so :

Ator - um papel que tipicamente estimula/solicita aes/eventos do sistema e recebe reaes. Cada ator pode participar de vrios casos de uso Casos de uso - documento narrativo que descreve a seqncia de eventos feitos por um ator no uso do sistema. Sistema - O sistema a ser modelado

Na UML o modelo de casos de uso consiste de diagramas de casos de uso que mostram os atores , os casos de uso e seus relacionamentos. Os elementos grficos que representam atores, casos de uso e sistema so mostrados abaixo: O nome de um caso de uso pode ser qualquer sentencia, mas a UML recomenda usar uma frase ativa curta (verbo + substantivo), por exemplo: "comprar itens'', "efetuar venda", ... Os elementos principais do diagrama so uma elipse para representar um caso de uso e um pequeno boneco para representar um ator

Nota: Abaixo temos uma estrutura de especificao que voc pode usar para casos de uso. No existe um padro.
Nome do caso de uso Descrio do caso de uso (um pargrafo). Atores Lista dos nomes dos atores com descrio curta. Prioridade Seja este caso de uso muito importante no projeto ou acessrio? Pre-Condies Lista de condies que tm que ser verificadas antes que o caso de uso comea. Fluxo de eventos Fluxo principal 1. Primeiro passo no caso de uso. 2. Segundo passo no caso de uso. 3. ... Fluxos alternativos Descrever os fluxos alternativos. Ps-Condies Lista de condies que tm que ser verificadas depois do fim do caso de uso. Pontos de extenso Lista dos pontos de extenso no caso de uso. Casos de uso includos Lista dos nomes dos casos de usos includos.

Nos primeiros contatos com os modelos de casos de uso surgem com frequncia trs perguntas para as quais no existe uma resposta absoluta , so elas :: 1 - Como identificar atores ?

Para identificar os atores que vo participar do modelo devemos fazer as seguintes perguntas : Quem Quem Quem Quem usa o sistema ? inicia o sistema ? fornece os dados ? usa as informaes ?

2- Como descrever atores ? Geralmente descreve atores usando : Nome do caso de uso tipo de uso (frequente, ocasional , etc...) descrio de seu papel no sistema

3- Como Identificar casos de uso ? Os casos de uso so interaes entre os atores e o sistema . Temos ento aes do ator e aes do sistema. Sendo que os atores sempre iniciam a ao. Vamos dar um exemplo prtico para que tudo fique mais claro. Vamos supor , por questo de simplicidade , que temos que modelar usando casos de uso a compra de item em um a loja com um terminal de ponto de venda. Quais so os atores ? Quem usa o sistema o cliente e ele usa um terminal de caixa . Como podemos identificar o caso de uso ? Podemos chamar este caso de uso de : Comprar Item (verto+substantivo) Agora vamos a um descrio textual do caso de uso Comprar Item onde atual os atores cliente e caixa. (Aqui estou adotando uma estrutura de especificao bem simplificada por questes didticas) Caso de uso - Comprar Item Atores - Cliente , Caixa Descrio - Este caso de uso comea quando um cliente chega ao terminal com itens que deseja comprar. O caixa registra os itens , recebe o pagamento e emite uma nota fiscal. O Cliente recebe os itens comprados. Na UML temos o diagrama de caso de uso que pode ser representado para o caso acima da seguinte forma:

Algumas consideraes : - Nomeie um caso de uso comeando com um verbo , para enfatizar que ele um processo. Ex: Cadastrar Cliente , Comprar Item , etc. - Para identificar claramente um ator iniciador e um evento , comece a descrio da sequncia de um caso de uso usando o seguinte esquema: - Este caso de uso comea quando o <Ator> <Evento que inicia o caso de uso> Ex: Este caso de uso comea quando um cliente chega com vrios itens para comprar Vamos a um outro exemplo: Suponha que voc tenha um almoxarifado de peas onde clientes faam pedido e onde um operador receba tarefas do sistema para buscar peas para os pedidos dos clientes e distribuir peas do setor de compras para o almoxarifado. (O exemplo bem simples para facilitar o entendimento do conceito) Como poderamos identificar os atores e os casos de uso para este exemplo? Vamos identificar os atores . Eles so : Cliente , Operador , Sistema e Setor de Compras. Certo ? No errado !!! No exemplo acima Sistema no pode ser um ator pois ele no se ajusta ao conceito dado a um ator : Um agente externo ao sistema. Lembre-se que um ator um papel que interage com o sistema mas no faz parte do sistema, ento no lugar de Sistema poderamos sugerir um administrador ou gerente. Ento os atores seriam : Cliente , Operador , Administrador e Compras. (Podem existir sub-sistemas que interagem com o sistema , neste caso eles seriam considerados atores.) E os casos de usos , quais seriam ? solicita peas (ator Cliente) entrega peas (ator Compras) buscar pedidos (ator operador) distribuir pedidos (ator operador) cadastrar Tarefas (administrador)

Certo ? Errado !!! No caso do ator operador ele no atua sobre o sistema nos casos de uso buscar pedidos e distribuir pedidos , ele atua sobre o sistema realizando Tarefa. Ento o correto seria. solicita peas (ator Cliente) entrega peas (ator Compras) realiza Tarefa (ator operador) cadastrar Tarefas (administrador)

Usando a representao UML para os diagramas de casos de uso teramos :

Este seria o caso de uso preliminar(simplificado) pois no temos muito detalhamento nesta etapa do modelo. A prxima etapa seria realizar um refinamento do modelo a fim de obter o relacionamento entre os casos de uso atravs da generalizao , incluso ou extenso. A partir do diagrama de casos de uso preliminar muitas vezes temos que definir casos de usos adicionais separadamente pois as operaes se encontram duplicadas em outros casos de uso ou so complexas e longas e a separao nos ajuda a compreend-las. Os relacionamentos possveis so : 1- Incluso : Se um caso de uso inicia ou inclui o comportamento de outro , dizemos que ele usa o outro. Ex: No caso de uso Comprar Item se o pagamento for feito com dinheiro podemos ter a incluso PagarComDinheiro

O relacionamento de incluso em UML ilustrado com uma linha de generalizao com o rtulo <<include>>. Ento para o exemplo do cliente com o use case Solicitar Pedidos de peas teramos:

As propriedades bsicas da incluso so : realizar um decomposio funcional reduzir a complexidade de um caso de uso O caso de uso bsico no pode executar sem a incluso. Comportamento comum

2- Extenso - Define pontos de extenso que adicionam comportamento a um caso de uso base descrevendo uma variao do comportamento normal. O caso de uso base pode ser executado mesmo sem a extenso. Ex: O caso de uso Comprar Produto pode apresentar a extenso Compra por um Cliente Regular. Abaixo temos o diagrama UML

Os pontos de extenso so indicados na linha entre os casos de uso do sistema. 3- Generalizao - Indica um caso de base que possui diferentes especializaes e inclui comportamento ou sobrescreve o caso de uso base. O caso de uso Pagar fatura apresenta as generalizaes : Pagamento com carto e Pagamento com Cheque , conforme o diagrama Abaixo:

Alm disto temos tambm os relacionamentos entre atores onde um ator especializado pode acessar os casos de uso de um Ator base. Abaixo temos um exemplo onde o Ator gerente acessa os casos de uso do ator funcionrio

Espero que esta pequena introduo aos casos de uso amplie o seu horizonte para a modelagem UML. Creio que uma das melhores ferramentas para modelagem o Rational Rose, mas o preo bem salgado. Como opo voc pode usar uma das seguintes ferramentas : Poseidon - existe um verso opensource (Community version) Pacestar UML - Uma verso shareware de uma ferramenta mais simples. Rational Rose - Cpia demo do (Rational Rose Limited Edition).(Tem 10 MB)

Aguarde mais artigos onde irei falar sobre modelo conceitual , diagramas de seqncia , diagramas de estado , e muito mais... At breve... referncias: - OMG (Object Modeling Glossary).

- Rational - Larman, Craig , "Utilizando UML e Padres - Uma introduo analise e ao projeto orientados a objetos" , BooKman, 2000

UML - Conceitos Bsicos II

Este artigo , recebido como colaborao , visa complementar os conceitos desta importante linguagem para modelagem - UML. Para saber mais sobre o assunto leia tambm:

UML - Modelando sistemas - Casos de Uso UML - Unified Modeling Language e Visual Modeler. VB.NET - Revisitando conceitos OOP VB .NET - Conceitos OOP. VB .NET - Primeiros passos - Conceitos - VI. VB .NET - Finalmente uma linguagem orientada a objetos. OOP noes para iniciantes O que significa "orientao a objetos" ? Conceitos sobre Projetos - Decomposio de software.

Para efetuar a modelagem UML podemos usar uma das seguintes ferramentas:

Poseidon - existe um verso opensource (Community version) Pacestar UML - Uma verso shareware de uma ferramenta mais simples. Rational Rose - Cpia demo do (Rational Rose Limited Edition).(Tem 10 MB) Dia - http://www.lysator.liu.se/~alla/dia/ ArgoUML - http://www.argoUML.tigris.org

Agora ao artigo:

Histrico da UML
Os estudos sobre a tecnologia de objetos iniciaram-se na dcada de 1980 com nfase nas linguagens de programao. No final da mesma dcada comearam a surgir os mtodos de anlise e projeto. Os principais mtodos foram de:

SHLAER & MELLOR (1989 e 1991); COAD & YOURDON (1991);

COAD & NICOLA (1993); COAD et al. (1995); WIRFS-BROCK et al. (1990); BOOCH (1994 e 1995); RUMBAUGH et al. (1991 e 1996); MARTIN & ODELL (1994 e 1995); JACOBSON (1994 e 1995).

Todos os mtodos eram muito similares, apesar da existncia de diferentes notaes para representar o mesmo conceito, o que na verdade, causava muita confuso entre os tcnicos e competio entre os metodologistas, o que provocou a "guerra dos mtodos". Em 1994 James Rumbaugh e Grady Booch iniciaram o trabalho de unificao dos mtodos Booch e OMT. Em 1995 no OOPSLA , Booch e Rumbaught apresentaram a documentao da verso 0.8 do mtodo unificado e anunciaram a integrao de Ivar Jacobson na equipe, formando assim o que eles denominaram de "Three amigos". Durante 1996 eles trabalharam no mtodo que passou a chamar de Unified Modeling Language (UML) e a Object Management Group (OMG) iniciou um esforo para padronizao na rea de mtodos. Os esforos de Rumbaugh, Booch e Jacobson resultaram as verses 0.9 e 0.91 da UML em junho e outubro de 1996 respectivamente. A UML a sucessora da linguagem de modelagem encontrada nos mtodos Booch, OOSE/Jacobson, OMT e outros como Modelos de Entidades e Relacionamentos. Cada um desses mtodos era reconhecido mediante alguma forte caracterstica. O OOSE orientado a use case e prov um excelente recurso para a anlise de requisitos. A OMT foi expressiva para anlise e sistemas centrados a dados. Durante 1996 a Rational Software Corporation contou com a participao de outras Instituies parceiras como: Hewlett-Packard, IBM, Microsoft, Oracle, Unisys, Platinum Technology, etc. Essa colaborao contribuiu para a produo da verso 1.0, uma verso bem definida, expressiva, poderosa e aplicvel, a qual foi submetida a OMG para adoo.

Em setembro de 1997 liberaram a verso 1. 1 da UML e em dezembro a mesma foi aprovada como padro pela OMG. Com a unificao dos mtodos a UML alcanou dois objetivos:

Acabou com as diferenas existentes entre os mtodos anteriores; Unificaram as perspectivas entre os diferentes tipos de sistemas, fases de desenvolvimento e conceitos internos.

Mtodo
A UML no um mtodo uma linguagem de modelagem designada para especificar, visualizar, construir e documentar um sistema. A linguagem de modelagem a notao que o mtodo utiliza para expressar projetos enquanto que o processo indica quais passos seguir para desenvolver um projeto. A especificao da UML consiste de duas partes:

Semntica - especifica a sintaxe abstrata e a semntica dos conceitos de modelagem esttica e dinmica de objetos; Notao especifica a notao grfica para a representao visual da semntica.

A UML suporta o desenvolvimento iterativo e incremental. Desenvolvimento iterativo e incremental o processo de desenvolvimento de sistemas em pequenos passos. Uma iterao um lao de desenvolvimento que resulta na liberao de um subconjunto de produtos que evolui at o produto final percorrendo as seguintes atividades:

Anlise de requisitos Anlise Projeto Implementao Teste

O detalhamento de cada etapa destas atividades define o mtodo de desenvolvimento de sistemas.

Anlise de requisitos
Esta etapa se caracteriza pela definio do comportamento do sistema, ou seja, como o sistema age ou reage, descrevendo o

relacionamento entre o ambiente e o sistema. Deve ser uma definio de necessidades do usurio e no uma proposta de soluo. O usurio deve indicar os requisitos prioritrios para o sistema. O grupo de anlise deve identificar as necessidades do usurio. Decises do projeto impostas no so caractersticas essenciais do domnio do problema. A anlise de requisitos compe-se dos seguintes diagramas:

Diagrama de caso de uso; Diagrama de seqncia; Diagrama de colaborao;

Para realizar a anlise de requisitos, primeiramente deve-se:

Identificar objetivo e caractersticas do sistema; Identificar os requisitos essenciais; Descrever as necessidades do usurio; Elaborar diagrama de caso de uso; Elaborar diagrama de seqncia; Elaborar diagrama de colaborao

Conceitos
UML uma linguagem visual para especificao (modelagem) de sistemas orientados a objeto. A UML privilegia a descrio de um sistema seguindo trs perspectivas: 1. Os diagramas de classes - (Dados estruturais); 2. Os diagramas de casos de uso (Operaes funcionais); 3. Os diagramas de seqncia, atividades e transio de Estados (Eventos temporais). Os casos de uso de um projeto de software so descritos na linguagem UML atravs de Diagramas de Casos de Uso (Use Case). Diagrama de "Use Case": um diagrama usado para se identificar como o sistema se comporta em vrias situaes que podem ocorrer durante sua operao. Descrevem o sistema, seu ambiente e a relao entre os dois. Os componentes deste diagrama so os atores, os "Use Case" e os relacionamentos. Casos de uso e Relacionamentos. Ainda pode-se usar as primitivas Pacotes e Notas. Ator: Representa qualquer entidade que interage com o sistema durante sua execuo essa interao se d atravs de comunicaes

(troca de mensagens). Um ator pode ser uma pessoa (usurio, secretaria, aluno...), um dispositivo (impressora, mquina...), hardware (placa de modem, scaner...), softwares (sistema de bd, aplicativos...), etc. Algumas de suas caractersticas so descritas abaixo:

Ator no parte do sistema. Representa os papis que o usurio do sistema pode desempenhar. Ator pode interagir ativamente com o sistema. Ator pode ser um receptor passivo de informao. Ator pode representar um ser humano, uma mquina ou outro sistema.

Representao:

OBS: Atores representam, na verdade, papeis desempenhados por pessoas, dispositivos ou outros quando interagem com o sistema. Um ator cujo identificador seja ALUNO no representa um aluno, mais sim um aluno qualquer, uma pessoa que esteja interagindo com o sistema na qualidade de aluno. Use Case: Como foi exemplificado acima, uma seqncia de aes que o sistema executa e produz um resultado de valor para o ator. Modela o dialogo entre os atores e o sistema; um fluxo de eventos completos. Algumas de suas caractersticas so descritas abaixo:

Um "Use Case" modela o dilogo entre atores e o sistema. Um "Use Case" iniciado por um ator para invocar uma certa funcionalidade do sistema. Um "Use Case" fluxo de eventos completo e consistente. O conjunto de todos os "Use Case" representa todas as situaes possveis de utilizao do sistema.

Relacionamento: Os relacionamentos ligam as classes/objetos entre si criando relaes lgicas entre estas entidades. Os relacionamentos podem ser dos seguintes tipos:

Associao: uma conexo entre classes, e tambm significa que uma conexo entre objetos daquelas classes. Em UML, uma associao definida com um relacionamento que descreve uma srie de ligaes, onde a ligao definida como a semntica entre as duplas de objetos ligados. Generalizao: um relacionamento de um elemento mais geral e outro mais especfico. O elemento mais especfico pode conter apenas informaes adicionais. Uma instncia (um objeto uma instncia de uma classe) do elemento mais especfico pode ser usada onde o elemento mais geral seja permitido.

Os relacionamentos em um diagrama de casos de uso podem envolver dois atores e dois casos de uso ou um ator e um caso de uso e assim sucessivamente. O relacionamento representado atravs de uma seta : Exemplo: Diagrama de "Use Cases" para um sistema automatizado de Matrcula num Curso

Tipo de Relacionamento - Associaes Uma associao representa que duas classes possuem uma ligao (link) entre elas, significando, por exemplo, que elas "conhecem uma a outra", "esto conectadas com", "para cada X existe um Y" e assim por diante. Classes e associaes so muito poderosas quando modeladas em sistemas complexos Associaes Normais

O tipo mais comum de associao apenas uma conexo entre classes. representada por uma linha slida entre duas classes. A associao possui um nome (junto linha que representa a associao), normalmente um verbo, mas substantivos tambm so permitidos. Pode-se tambm colocar uma seta no final da associao indicando que esta s pode ser usada para o lado onde a seta aponta. Mas associaes tambm podem possuir dois nomes, significando um nome para cada sentido da associao. Para expressar a multiplicidade entre os relacionamentos, um intervalo indica quantos objetos esto relacionados no link. O intervalo pode ser de zero para um (0..1), zero para vrios (0..* ou apenas *), um para vrios (1..*), dois (2), cinco para 11 (5..11) e assim por diante. tambm possvel expressar uma srie de nmeros como (1, 4, 6..12). Se no for descrita nenhuma multiplicidade, ento considerado o padro de um para um (1..1 ou apenas 1).

Duas classes se relacionando por associao normal No exemplo acima vemos um relacionamento entre as classes Cliente e Conta Corrente que se relacionam por associao. Associao Recursiva possvel conectar uma classe a ela mesma atravs de uma associao e que ainda representa semanticamente a conexo entre dois objetos, mas os objetos conectados so da mesma classe. Uma associao deste tipo chamada de associao recursiva.

Exemplo de uma associao recursiva Associao Ternria

Mais de duas classes podem ser associadas entre si, a associao ternria associa trs classes. Ela mostrada como uma grade losango (diamante) e ainda suporta uma associao de classe ligada a ela, traaria-se, ento, uma linha tracejada a partir do losango para a classe onde seria feita a associao ternria.

Exemplo de uma associao ternria No exemplo acima a associao ternria especifica que um cliente poder possuir 1 ou mais contratos e cada contrato ser composto de 1 ou vrias regras contratuais. Agregao A agregao um caso particular da associao. A agregao indica que uma das classes do relacionamento uma parte, ou est contida em outra classe. As palavras chaves usadas para identificar uma agregao so: "consiste em", "contm", " parte de".

uma forma especializada de associao na qual um todo relacionado com suas partes. Tambm conhecida como relao de contedo. representada como uma linha de associao com um diamante junto Classe agregadora. A multiplicidade representada da mesma maneira que nas associaes.

Tipo de Relacionamento - Generalizaes A generalizao um relacionamento entre um elemento geral e um outro mais especfico. O elemento mais especfico possui todas as caractersticas do elemento geral e contm ainda mais particularidades. Um objeto mais especfico pode ser usado como uma instncia do elemento mais geral. A generalizao, tambm

chamada de herana, permite a criao de elementos especializados em outros. Existem alguns tipos de generalizaes que variam em sua utilizao a partir da situao. So elas: generalizao normal e restrita. As generalizaes restritas se dividem em generalizao de sobreposio, disjuntiva, completa e incompleta. Generalizao Normal Na generalizao normal a classe mais especfica, chamada de subclasse, herda tudo da classe mais geral, chamada de superclasse. Os atributos, operaes e todas as associaes so herdados.

Exemplo de uma generalizao normal Uma classe pode ser tanto uma subclasse quanto uma superclasse, se ela estiver numa hierarquia de classes que um grfico onde as classes esto ligadas atravs de generalizaes. A generalizao normal representada por uma linha entre as duas classes que fazem o relacionamento, sendo que se coloca uma seta no lado da linha onde se encontra a superclasse indicando a generalizao. Generalizao Restrita Uma restrio aplicada a uma generalizao especifica informaes mais precisas sobre como a generalizao deve ser usada e estendida no futuro. As restries a seguir definem as generalizaes restritas com mais de uma subclasse: Generalizaes de Sobreposio e Disjuntiva: Generalizao de sobreposio significa que quando subclasses herdam de uma superclasse por sobreposio, novas subclasses destas podem herdar de mais de uma subclasse. A generalizao disjuntiva exatamente o contrrio da sobreposio e a generalizao utilizada como padro

Exemplo de uma generalizao de sobreposio

Generalizaes Completa e Incompleta: Uma restrio simbolizando que uma generalizao completa significa que todas as subclasses j foram especificadas, e no existe mais possibilidade de outra generalizao a partir daquele ponto. A generalizao incompleta exatamente o contrrio da completa e assumida como padro da linguagem.

Diagrama de Seqncia Em um sistema computacional orientado a objeto os servios (casos de uso) so fornecidos atravs da colaborao de grupos. Os objetos interagem atravs de comunicaes de forma que juntos, cada um com suas responsabilidades, realizem os casos de uso. O Diagrama de seqncia uma ferramenta importante no projeto de sistemas orientados a objetos. Embora a elaborao dos diagramas possa consumir um tempo considervel para sistemas maiores ou mais complexos, eles oferecem a seguir as bases para a definio de uma boa parte do projeto como: os relacionamentos necessrios entre as

classes, mtodos e atributos das classes e comportamento dinmico dos objetos. Um diagrama de seqncia um diagrama de objetos, ou seja, ele contm como primitiva principal um conjunto de objetos de diferentes classes. O objetivo dos diagramas de seqncia descrever as comunicaes necessrias entre objetos para a realizao dos processos em um sistema computacional. Os diagramas de seqncia tm este nome porque descrevem ao longo de uma linha de tempo a seqncia de comunicaes entre objetos. Como podem existir muitos processos em um sistema computacional, sugere-se proceder construo dos diagramas de seqncia por caso de uso. Assim, tomar-se-ia separadamente cada caso de uso para a construo de seus diagramas de seqncia. De uma forma geral, para cada caso de uso constri-se um diagrama de seqncia principal descrevendo as seqncias normais de comunicao entre objetos e diagramas complementares descrevendo seqncias alternativas e tratamento de situaes de erro. Utiliza-se tambm o termo cenrio associado com os diagramas de seqncia. Um cenrio uma forma de ocorrncia de um caso de uso. Como o processo de um caso de uso pode ser realizado de diferentes formas, para descrever a realizao de um caso de uso pode ser necessrio estudar vrios cenrios. Cada cenrio pode ser descrito por um diagrama de seqncia. No exemplo do caso de uso Cadastrar Aluno do sistema de controle acadmico, podem-se considerar os cenrios de incluso, alterao e excluso de aluno. Notao UML para Diagramas de Seqncia A notao UML para descrio de diagramas de seqncia envolve a indicao do conjunto de objetos envolvidos em um cenrio e a especificao das mensagens trocadas entre estes objetos ao longo de uma linha de tempo. Os objetos so colocados em linha na parte superior do diagrama. Linhas verticais tracejadas so traadas da base dos objetos at a parte inferior do diagrama representando a linha de tempo. O ponto superior destas linhas indica um instante inicial e, medida que se avana para baixo evolui-se o tempo. Retngulos colocados sobre as linhas de tempo dos objetos indicam os perodos de ativao do objeto. Durante um perodo de ativao, o objeto respectivo esta em execuo realizando algum processamento. Nos perodos em que o objeto no esta ativo, ele esta alocada (ele existe), mas no esta executando nenhuma instruo. A figura abaixo ilustra a estrutura bsica de um diagrama

de seqncia para o cenrio Incluso de Aluno do caso de uso Cadastrar Aluno.

Outra primitiva importante dos diagramas de seqncia a troca de mensagem. Esta primitiva utilizada para indicar os momentos de interao ou comunicao entre os objetos. Utiliza-se como notao para trocas de mensagens segmentos de retas direcionadas da linha de tempo de um objeto origem para a linha de tempo de um objeto destino. Uma seta colocada na extremidade do objeto destino. As linhas representando troca de mensagens so desenhadas na horizontal, pois se presume que a troca de uma mensagem consome um tempo desprezvel. O objeto destino de uma mensagem deve receber a mensagem e processa-la. Desta forma, no recebimento de uma mensagem o objeto destino ativado para tratamento da mensagem. A figura abaixo ilustra a troca de mensagens entre objetos e entre atores e objetos.

As mensagens trocadas entre um objeto ou entre um objeto e um ator podem ter trs significados: Chamada de Funo ou Procedimento Uma das interaes mais freqentes entre objetos a chamada de funo. Uma chamada de funo significa que um objeto esta solicitando a execuo de uma funo (um mtodo) de um outro objeto. Este conceito segue estritamente o processo de chamada de funo ou de procedimento utilizado nas linguagens de programao. Obviamente, para que um objeto possa chamar um mtodo de outro objeto necessrio que o mtodo seja declarado como publico na classe respectiva. Como ser visto a seguir, a sintaxe, no caso de mensagens que representem chamadas de funo, semelhante quela das linguagens de programao. Envio de Mensagem Objetos tambm podem comunicar-se com outros objetos atravs do envio explcito de uma mensagem. O envio de uma mensagem, ao contrario da chamada de funo, no uma interao direta entre dois objetos. Na verdade, quando um objeto envia uma mensagem a outro objeto, a mensagem roteada ou encaminhada por algum mecanismo de entrega de mensagens. Normalmente, este servio prestado pelo sistema operacional atravs de mecanismos como Message Queries (filas de mensagens) ou servios de notificao. Ocorrncia de Evento Existem tambm outras formas de interao entre objetos atravs de eventos. Esta tambm a forma padro de interao entre objetos e atores. Basicamente, um evento algum acontecimento externo ao software, mas que a ele notificado, pois lhe diz respeito. A notificao, ou seja, a indicao de que um determinado evento ocorreu , na maioria dos casos, feita pelo sistema operacional. Eventos podem tambm ser gerados pelo software para o sistema operacional. Exemplos so as sadas para dispositivos (monitor, porta serial, disco) feitos atravs de servios do sistema operacional. Alguns exemplos de eventos so:
Evento Origem Destino

Clique do mouse

mouse

Algum objeto

Movimentao do mouse

mouse

Algum objeto

Dados no buffer do teclado

teclado

Algum objeto

Dados no buffer da serial

porta serial

Algum objeto

Projeo de dados no monitor. Bip do alto-falante.

Algum objeto Algum objeto

monitor alto-falante

Colocao de dados no buffer da serial

Algum objeto

Porta serial

Interrupo

Dispositivo de hardware

Algum objeto

Eventos do sistema operacional (timer)

Sistema operacional

Algum objeto

Tipos de Mensagens Nos exemplos das figuras utilizou-se como notao grfica para as trocas de mensagens segmentos de reta com uma seta aberta em uma das extremidades. Esta a notao genrica para mensagens que pode ser utilizada nas primeiras verses dos diagramas de seqncia. Em diagramas mais detalhados, entretanto, ser utilizada outra notao deforma a indicar tambm o tipo das mensagens. Existem dois tipos de mensagens chamadas mensagens sncronas e assncronas. Mensagens Sncronas Mensagens sncronas so mensagens que implicam um sincronismo rgido entre os estados do objeto que envia a mensagem e os do objeto de destino da mensagem. Um sincronismo entre objetos pode ser entendido, de uma forma geral, como uma dependncia na

evoluo de estado de um objeto sobre o estado de um segundo objeto. De uma forma mais direta, pode-se dizer que uma mensagem sncrona implica que o objeto que enviou a mensagem aguarde a concluso do processamento da mensagem (entendida como um sinal de sincronismo) feito pelo objeto destino, para ento prosseguir seu fluxo de execuo. O exemplo mais comum de mensagem sncrona a chamada de funo. Em uma chamada de funo o objeto que faz a chamada empilhado e fica neste estado at a concluso do processamento da funo chamada. Trata-se, portanto, de um sincronismo rgido entre o objeto chamador e o objeto chamado. Alguns sistemas operacionais oferecem tambm mecanismos de troca de mensagens sncronas de forma que o objeto que envia a mensagem fique em estado de espera at a concluso do tratamento da mensagem. A notao UML para uma mensagem sncrona a de um segmento de reta com uma seta cheia em uma das extremidades Mensagens Assncronas Mensagens assncronas so mensagens enviadas de um objeto a outro sem que haja uma dependncia de estado entre os dois objetos. O objeto de origem envia a mensagem e prossegue seu processamento independentemente do tratamento da mensagem feita no objeto destino. Os mecanismos de envio de mensagens suportados pelos sistemas operacionais so o exemplo mais comum deste tipo de mensagem. Alm disso, de uma forma geral, todas as comunicaes entre atores e objetos representam trocas de mensagem assncronas. Considere, por exemplo, uma operao para apresentao de uma mensagem no monitor. Um objeto executa uma instruo print (ou print ou write) e o sistema despacha a mensagem para o ator (o monitor). O objeto prossegue seu processamento independentemente do desfecho na operao. Observe que os softwares no bloqueiam quando o monitor no apresenta alguma informao. A notao UML para uma mensagem assncrona a de um segmento de reta com uma meia seta em uma das extremidades. Autodelegao Um objeto pode enviar mensagens para outros objetos e pode tambm enviar mensagens para ele prprio. Uma mensagem enviada de um objeto para ele prprio chama-se uma Autodelegao. Mensagens de Autodelegao podem ser sncronas ou assncronas. O caso mais comum de mensagens assncronas o envio de uma mensagem de um objeto para ele mesmo atravs de mecanismos de

envio de mensagens do sistema operacional. O caso mais comum de mensagens de Autodelegao sncronas a chamada de funo de um objeto pelo prprio objeto.

Diagrama de Colaborao Mostra a interao organizada ao lado de cada classe de objetos e a ligao entre elas. Como o diagrama de seqncia, o diagrama de colaborao mostra as mensagens trocadas por um conjunto de objetos durante um cenrio. uma representao grfica alternativa para mostrar um cenrio. Descrevem grupos de objetos que colaboram atravs de comunicao. Um diagrama de colaborao contm:

Objetos, que so representados por retngulos. Ligaes entre objetos, representadas por uma linha conectando os objetos. Mensagens trocadas entre objetos em uma seqncia ordenada Fluxo de dados entre objetos, se houver.

Atravs do diagrama de colaborao mais fcil visualizar as mensagens trocadas entre os objetos, subsidiando assim a elaborao do diagrama de classes de objetos. Os objetos e as mensagens so as mesmas do diagrama de seqncia. Utilizando o diagrama de colaborao possvel identificar se existe algum objeto que no troca mensagens com outro. Caso isto acontea deve-se analisar o modelo de origem e verificar se este objeto mesmo necessrio. Os diagramas de seqncia e de colaborao sero mais utilizados no desenvolvimento do projeto quando so projetadas as implementaes dos relacionamentos.

O objetivo do diagrama de colaborao agrupar as mensagens entre pares de objetos de forma a fazer-se um levantamento das necessidades de comunicao. Diagrama de Estado O comportamento de uma classe de objetos representado atravs de um diagrama de transio de estado, que descreve o ciclo de vida de uma dada classe, os eventos que causam a transio de estado para o outro e as aes resultantes da mudana de estado. O estado de um objeto uma das possveis condies na qual o objeto pode existir. O estado compreende todas as propriedades do objeto associadas aos valores correntes de cada uma dessas propriedades. Segundo a UML a especificao da dinmica do sistema deve ser feita atravs de diagramas de estados. Constri-se um diagrama de estado descrevendo o comportamento de cada classe e eventuais diagramas comportamentais para descrever a dinmica de todo o sistema ou de certos mdulos.

Diagrama de estado uma descrio global do comportamento dos objetos desta classe em todo o sistema; Diagrama de estado; a especificao da dinmica do sistema deve ser feita atravs de diagramas de classe; Descreve-se o conjunto de estados de um objeto e tambm o conjunto de transaes de estados existentes.

A UML utiliza como notao para diagramas de estados a notao proposta por Harel. Nesta notao, um diagrama de estados e um grafo dirigido cujos nodos representam estados e cujos arcos representam transies entre estados. Estados so representados graficamente por elipses ou retngulos com bordas arredondadas e transies so representadas por segmento de retas dirigidas. Referncias:

UML - Apresentando os principais diagramas da linguagem UML - Modelando sistemas - Casos de Uso UML - Conceitos Bsicos UML - Unified Modeling Language e Visual Modeler.