Apostila para Curso de UML

UML: Unified Modeling Language
Sumrio
1. Introduo....................................................................................1 Objetivos............................................................................................................................................2 Conectando os estudos.......................................................................................................................3 Desenvolvimento de software orientado a objetos...........................................................................5 UML A unificao dos mtodos e criao de um novo padro.....................................................6 Uso da UML......................................................................................................................................8 Fases do Desenvolvimento de um Sistema.....................................................................................10 Anlise de Requisitos......................................................................................................................11 Anlise.............................................................................................................................................12 Design (Projeto)...............................................................................................................................13 Programao....................................................................................................................................14 Testes...............................................................................................................................................15 Exerccios.........................................................................................................................................16 2. Diagrama de Use Case...................................................................1 Objetivos............................................................................................................................................2 Definio de Use Case.......................................................................................................................3 O Levantamento de Requisitos..........................................................................................................4 O Use Case.........................................................................................................................................6 ...................................................................................................................................................8 Atores.................................................................................................................................................9 Relacionamentos entre casos de uso e atores..................................................................................14 Associao.......................................................................................................................................15 Generalizao...................................................................................................................................16 Extenso (extends)...........................................................................................................................18 Incluso (Include)............................................................................................................................20 Modelando requisitos com casos de uso.........................................................................................22 Casos de uso e pacotes.....................................................................................................................24 Quando Utilizar Casos de Uso........................................................................................................26 Exemplos de descrio textual........................................................................................................27 Exerccios.........................................................................................................................................29 3. Diagrama de Atividades.................................................................1 Objetivos............................................................................................................................................2 Definio do diagrama.......................................................................................................................3 Elementos do diagrama.....................................................................................................................4 Atividade............................................................................................................................................5 Incio do diagrama ............................................................................................................................6 Fim do diagrama................................................................................................................................7 Transies..........................................................................................................................................8 Desvios...............................................................................................................................................9 Separao e Unio...........................................................................................................................12 Estado de subatividade....................................................................................................................15 Concorrncia Dinmica...................................................................................................................16 Raias (Swimlanes)...........................................................................................................................17 Quando Utilizar Diagramas de Atividades.....................................................................................18 Exerccios.........................................................................................................................................20
II
4. Diagrama de Classes......................................................................1 Objetivos............................................................................................................................................2 Introduo..........................................................................................................................................3 Perspectivas...............................................................................................................................6 Criando Diagramas de Classe............................................................................................................8 Compartimento do Nome da Classe................................................................................................11 Atributos..........................................................................................................................................12 Operaes.........................................................................................................................................16 Relacionamentos..............................................................................................................................19 Associao.......................................................................................................................................20 Nome da associao ........................................................................................................................21 Multiplicidade .................................................................................................................................22 Papel (role).......................................................................................................................................23 Navegabilidade ...............................................................................................................................24 Uma seta pode ser colocada na extremidade de uma associao indicando que a navegao determinada na direo para onde partiu a seta. As setas podem ser omitidas, colocadas em apenas uma das extremidades ou em ambas. A navegabilidade quando omitida indica que a mesma desconhecida ou bidirecional.........................................................................24 Herana/Generalizao....................................................................................................................25 Dependncia.....................................................................................................................................29 Agregao........................................................................................................................................31 Composio.....................................................................................................................................33 Pacotes.............................................................................................................................................35 Colaboraes....................................................................................................................................38 Quando Utilizar Diagramas de Pacotes e Colaboraes.................................................................39 Multiplicidade..................................................................................................................................40 Escopo..............................................................................................................................................42 Classes de Associao.....................................................................................................................44 Associao Xor (ou exclusiva)........................................................................................................46 Esteretipo.......................................................................................................................................47 Notas........................................................................................................................................47 Interfaces e Classes Abstratas.........................................................................................................49 Objetos de Referncia e Objetos de Valor......................................................................................52 Objetos de referncia ......................................................................................................................53 Objeto de Valor................................................................................................................................54 Colees para Pontas de Associaes de Valores Mltiplos..........................................................55 Frozen..............................................................................................................................................56 Visibilidade......................................................................................................................................57 Quando Utilizar Diagramas de Classes...........................................................................................60 Exerccios.........................................................................................................................................61 5. Diagrama de Estados.....................................................................1 Objetivos............................................................................................................................................2 O que um Diagrama de Estados?....................................................................................................3 Estado.................................................................................................................................................4 Estado Inicial e Estado Final.............................................................................................................7 Transies..........................................................................................................................................8 Estado composto..............................................................................................................................11 Quando Utilizar Diagramas de Estados..........................................................................................12 Exerccios.........................................................................................................................................13
III
6. Diagrama de Objetos.....................................................................1 Objetivos............................................................................................................................................2 O que um diagrama de objetos?.....................................................................................................3 Criando diagramas de objetos...........................................................................................................4 ...................................................................................................................................................7 Quando utilizar diagrama de objetos?...............................................................................................9 Exerccios.........................................................................................................................................10 7. Diagrama de Interao...................................................................1 Objetivos............................................................................................................................................2 O que um diagrama de Interao?..................................................................................................3 Diagrama de seqncias....................................................................................................................5 Diagrama de colaborao................................................................................................................11 Modelando diagramas de seqncias..............................................................................................14 Quando Utilizar Diagramas de Interao........................................................................................17 Exerccios.........................................................................................................................................18 8. Diagramas Fsicos..........................................................................1 Objetivos............................................................................................................................................2 O que so diagramas fsicos?............................................................................................................3 Diagrama de Componentes................................................................................................................4 Componente.......................................................................................................................................5 Diagrama de Implantao..................................................................................................................6 N.......................................................................................................................................................7 Combinando Componentes com Diagramas de Utilizao..............................................................8 Quando Utilizar Diagramas Fsicos................................................................................................10 Exerccios.........................................................................................................................................11 9. Apndice 1: Extensibilidade da UML................................................1 Mecanismos de extensibilidade da UML..........................................................................................2 Esteretipos........................................................................................................................................3 Restries...........................................................................................................................................7 Glossrio............................................................................................................................................8 10. Apendice 2: Diagramas UML dos exerciccios.................................1
IV
1. Introduo
Introduo
Objetivos
Conhecer a UML Conhecer os principais mtodos que originaram a UML Descrever onde pode ser utilizada a UML Conhecer as fases de um processo de construo de software
Introduo
Conectando os estudos
No curso anterior estudamos os conceitos de orientao a objetos e vimos como a tecnologia de objetos est organizada. Estudamos vrios conceitos importantes dentre eles o conceito de classe, objeto, herana, polimorfismo e alguns relacionamentos entre as classes. Foi dado nfase no estudo da orientao a objetos e deixado para este curso que voc est iniciando o estudo de como podemos modelar um sistema utilizando uma linguagem de modelagem de sistemas voltada para a tecnologia de objetos. No iremos utilizar diagramas de fluxo de dados (DFDs) para fazer a modelagem de sistemas orientados a objetos, a pesar de algumas pessoas tentarem utilizar, uma vez que para a tecnologia de objetos existe outra tcnica especfica. O grande problema do desenvolvimento de novos sistemas utilizando a orientao a objetos nas fases de anlise de requisitos, anlise de sistemas e design que no existe uma notao padronizada e realmente eficaz que abranja qualquer tipo de aplicao que se deseje. Cada simbologia existente possui seus prprios conceitos, grficos e terminologias, resultando numa grande confuso, especialmente para aqueles que querem utilizar a orientao a objetos no s sabendo para que lado aponta a seta de um relacionamento, mas sabendo criar modelos de qualidade para ajud-los a construir e manter sistemas cada vez mais eficazes. Quando a "Unified Modeling Language" (UML) foi lanada, muitos desenvolvedores da rea da orientao a objetos ficaram entusiasmados j que essa padronizao proposta pela UML era o tipo de fora que eles sempre esperaram. A UML muito mais que a padronizao de uma notao. tambm o desenvolvimento de novos conceitos no normalmente usados. Por isso e muitas outras razes, o bom entendimento da UML no apenas aprender a simbologia e o seu significado, mas tambm significa aprender a modelar orientado a objetos no estado da arte. UML foi desenvolvida por Grady Booch, James Rumbaugh e Ivar Jacobson que so conhecidos como "os trs amigos". Eles possuem um extenso conhecimento na rea de modelagem orientado a objetos j que as trs mais conceituadas metodologias de modelagem orientada a objetos foram eles que desenvolveram e a UML a juno do que havia de melhor nestas trs metodologias adicionado novos conceitos e vises da linguagem. Veremos caractersticas de cada uma destas metodologias no desenvolver deste curso. Veremos neste curso como a UML aborda o carter esttico e dinmico do sistema a ser analisado levando em considerao, j no perodo de modelagem, todas as futuras caractersticas do sistema em relao a utilizao de "packages" prprios da linguagem a ser utilizada, utilizao do banco de dados
Introduo
bem como as diversas especificaes do sistema a ser desenvolvido de acordo com as mtricas finais do sistema. No intuito deste curso definir e explicar os significados de classes, objetos, relacionamentos, mensagens e outras entidades comuns da orientao a objetos, e sim apresentarmos como essas entidades so criadas, simbolizadas, organizadas e como sero utilizadas dentro de um desenvolvimento utilizando a UML. Os conceitos como j comentado foram tratados no curso de Orientao a Objetos o qual recomendamos que seja feito antes deste.
Introduo
Desenvolvimento de software orientado a objetos
Os conceitos da orientao a objetos tm sido discutidos h muito tempo, desde o lanamento da primeira linguagem orientada a objetos, a SIMULA. Vrios "papas" da engenharia de software mundial como Peter Coad, Edward Yourdon e Roger Pressman abordaram extensamente a anlise orientada a objetos como realmente um grande avano no desenvolvimento de sistemas. Mas mesmo assim, eles citam que no existe (ou que no existia no momento de suas publicaes) uma linguagem que possibilitasse o desenvolvimento de qualquer software utilizando a anlise orientada a objetos.
Os conceitos que Coad, Yourdon, Pressman e tantos outros abordaram, discutiram e definiram em suas publicaes foram que:
A orientao a objetos uma tecnologia para a produo de modelos que especifiquem o domnio do problema de um sistema. Quando construdos corretamente, sistemas orientados a objetos so flexveis a mudanas, possuem estruturas bem conhecidas e provm a oportunidade de criar e implementar componentes totalmente reutilizveis. Modelos orientados a objetos so implementados convenientemente utilizando uma linguagem de programao orientada a objetos. A engenharia de software orientada a objetos muito mais que utilizar mecanismos de sua linguagem de programao, saber utilizar da melhor forma possvel todas as tcnicas da modelagem orientada a objetos. A orientao a objetos no s teoria, mas uma tecnologia de eficincia e qualidade comprovada e usada em inmeros projetos para construo de diferentes tipos de sistemas.
A orientao a objetos requer um mtodo que integre o processo de desenvolvimento e a linguagem de modelagem com a construo de tcnicas e ferramentas adequadas.
Introduo
UML A unificao dos mtodos e criao de um novo padro
A UML uma tentativa de padronizar a modelagem orientada a objetos de uma forma que qualquer sistema, seja qual for o tipo, possa ser modelado corretamente, com consistncia, fcil de se comunicar com outras aplicaes, simples de ser atualizado e compreensvel. Existem vrias metodologias de modelagem orientada a objetos que at o surgimento da UML causavam uma guerra entre a comunidade de desenvolvedores orientado a objetos. A UML acabou com esta guerra trazendo as melhores idias de cada uma destas metodologias, e mostrando como deveria ser a migrao de cada uma para a UML. Falaremos sobre algumas das principais metodologias que se tornaram populares nos anos 90:
Booch O mtodo de Grady Booch para desenvolvimento orientado a objetos est disponvel em muitas verses. Booch definiu a noo de que um sistema analisado a partir de um nmero de vises, onde cada viso descrita por um nmero de modelos e diagramas. O Mtodo de Booch trazia uma simbologia complexa de ser desenhada a mo, continha tambm o processo pelo qual sistemas so analisados por macro e micro vises. OMT Tcnica de Modelagem de Objetos (Object Modelling Technique) um mtodo desenvolvido pela GE (General Electric) onde James Rumbaugh trabalhava. O mtodo especialmente voltado para o teste dos modelos, baseado nas especificaes da anlise de requisitos do sistema. O modelo total do sistema baseado no mtodo OMT composto pela juno dos modelos de objetos, funcional e use-cases. OOSE/Objectory Os mtodos OOSE e o Objectory foram desenvolvidos baseados no mesmo ponto de vista formado por Ivar Jacobson. O mtodo OOSE a viso de Jacobson de um mtodo orientado a objetos, j o Objectory usado para a construo de sistemas to diversos quanto eles forem. Ambos os mtodos so baseados na utilizao de use-cases, que definem os requisitos iniciais do sistema, vistos por um ator externo. O mtodo Objectory tambm foi adaptado para a engenharia de negcios, onde usado para modelar e melhorar os processos envolvidos no funcionamento de empresas.
Cada um destes mtodos possui sua prpria notao (seus prprios smbolos para representar modelos orientados a objetos), processos (que
Introduo
atividades so desenvolvidas em diferentes partes do desenvolvimento), e ferramentas (as ferramentas CASE que suportam cada uma destas notaes e processos). Diante desta diversidade de conceitos, "os trs amigos", Grady Booch, James Rumbaugh e Ivar Jacobson decidiram criar uma Linguagem de Modelagem Unificada. Eles disponibilizaram inmeras verses preliminares da UML para a comunidade de desenvolvedores e a resposta incrementou muitas novas idias que melhoraram ainda mais a linguagem. Os objetivos da UML so:

A modelagem de sistemas (no apenas de software) usando os conceitos da orientao a objetos Estabelecer uma unio fazendo com que mtodos conceituais sejam tambm executveis Criar uma linguagem de modelagem usvel tanto pelo homem quanto pela mquina
A UML est destinada a ser dominante, a linguagem de modelagem comum a ser usada nas indstrias. Ela est totalmente baseada em conceitos e padres extensivamente testados provenientes das metodologias existentes anteriormente, e tambm muito bem documentada com toda a especificao da semntica da linguagem representada em meta-modelos. Atualmente as empresas de desenvolvimento de software utilizam muito esta linguagem, podemos afirmar tranqilamente que esta a linguagem de modelagem de dados e processos mais utilizada por empresas que trabalham com linguagens orientadas a objeto.
Introduo
Uso da UML
A UML usada no desenvolvimento dos mais diversos tipos de sistemas. Ela abrange sempre qualquer caracterstica de um sistema em um de seus diagramas e tambm aplicada em diferentes fases do desenvolvimento de um sistema, desde a especificao da anlise de requisitos at a finalizao com a fase de testes. O objetivo da UML descrever qualquer tipo de sistema, em termos de diagramas orientado a objetos. Naturalmente, o uso mais comum para criar modelos de sistemas de software, mas a UML tambm usada para representar sistemas mecnicos sem nenhum software. Aqui esto alguns tipos diferentes de sistemas com suas caractersticas mais comuns:
Sistemas de Informao: Armazenar, pesquisar, editar e mostrar informaes para os usurios. Manter grandes quantidades de dados com relacionamentos complexos, que so guardados em bancos de dados relacionais ou orientados a objetos. Sistemas Tcnicos: Manter e controlar equipamentos tcnicos como de telecomunicaes, equipamentos militares ou processos industriais. Eles devem possuir interfaces especiais do equipamento e menos programao de software de que os sistemas de informao. Sistemas Tcnicos so geralmente sistemas real-time. Sistemas Real-Time Integrados: Executados em simples peas de hardware integrado a telefones celulares, carros, alarmes etc. Estes sistemas implementam programao de baixo nvel e requerem suporte real-time. Sistemas Distribudos: Distribudos em mquinas onde os dados so transferidos facilmente de uma mquina para outra. Eles requerem mecanismos de comunicao sincronizados para garantir a integridade dos dados e geralmente so construdos em mecanismos de objetos como CORBA, COM/DCOM ou Java Beans/RMI. Sistemas de Software: Definem uma infra-estrutura tcnica que outros softwares utilizam. Sistemas Operacionais, bancos de dados, e aes de usurios que executam aes de baixo nvel no hardware, ao mesmo tempo que disponibilizam interfaces genricas de uso de outros softwares. Sistemas de Negcios: descreve os objetivos, especificaes (pessoas, computadores etc.), as regras (leis, estratgias de negcios etc.), e o atual trabalho desempenhado nos processos do negcio.
Introduo
importante perceber que a maioria dos sistemas no possuem apenas uma destas caractersticas acima relacionadas, mas vrias delas ao mesmo tempo. Sistemas de informaes de hoje, por exemplo, podem ter tanto caractersticas distribudas como real-time. E a UML suporta modelagens de todos estes tipos de sistemas.
Introduo
Fases do Desenvolvimento de um Sistema

Atualmente existem muitos processos para desenvolvimento de software criados por empresas e pesquisadores. Ns iremos aqui mostrar algumas fazes do desenvolvimento de software, para isto dividimos o ciclo de desenvolvimento em cinco fases: anlise de requisitos, anlise, design (projeto), programao e testes. Estas cinco fases no devem ser executadas na ordem descrita acima, mas concomitantemente de forma que problemas detectados numa certa fase modifiquem e melhorem as fases desenvolvidas anteriormente de forma que o resultado global gere um produto de alta qualidade e desempenho. A seguir falaremos sobre cada fase do desenvolvimento de um sistema em UML.
Introduo
Anlise de Requisitos
Esta fase captura as intenes e necessidades dos usurios do sistema a ser desenvolvido atravs do uso de funes chamadas "use-cases". Atravs do desenvolvimento de "use-case", as entidades externas ao sistema (em UML chamados de "atores externos") que interagem e possuem interesse no sistema so modelados entre as funes que eles requerem, funes estas chamadas de "use-cases". Os atores externos e os "use-cases" so modelados com relacionamentos que possuem comunicao associativa entre eles ou so desmembrados em hierarquia. Cada "use-case" modelado descrito atravs de um texto, e este especifica os requerimentos do ator externo que utilizar este "use-case". O diagrama de "use-cases" mostrar o que os atores externos, ou seja, os usurios do futuro sistema devero esperar do aplicativo, conhecendo toda sua funcionalidade sem importar como esta ser implementada. A anlise de requisitos tambm pode ser desenvolvida baseada em processos de negcios, e no apenas para sistemas de software.
Introduo
Anlise
A fase de anlise est preocupada com as primeiras abstraes (classes e objetos) e mecanismos que estaro presentes no domnio do problema. As classes so modeladas e ligadas atravs de relacionamentos com outras classes, e so descritas no Diagrama de Classe. As colaboraes entre classes tambm so mostradas neste diagrama para desenvolver os "use-cases" modelados anteriormente, estas colaboraes so criadas atravs de modelos dinmicos em UML. Na anlise, s sero modeladas classes que pertenam ao domnio principal do problema do software, ou seja, classes tcnicas que gerenciem banco de dados, interface, comunicao, concorrncia e outros no estaro presentes neste diagrama.
Introduo
Design (Projeto)
Na fase de design, o resultado da anlise expandido em solues tcnicas. Novas classes sero adicionadas para prover uma infra-estrutura tcnica: a interface do usurio e de perifricos, gerenciamento de banco de dados, comunicao com outros sistemas, dentre outros. As classes do domnio do problema modeladas na fase de anlise so mescladas nessa nova infraestrutura tcnica tornando possvel alterar tanto o domnio do problema quanto a infra-estrutura. O design resulta no detalhamento das especificaes para a fase de programao do sistema.
Introduo
Programao
Na fase de programao, as classes provenientes do design so convertidas para o cdigo da linguagem orientada a objetos escolhida (a utilizao de linguagens procedurais extremamente no recomendada). Dependendo da capacidade da linguagem usada, essa converso pode ser uma tarefa fcil ou muito complicada. No momento da criao de modelos de anlise e design em UML, melhor evitar traduzi-los mentalmente em cdigo. Nas fases anteriores, os modelos criados so o significado do entendimento e da estrutura do sistema, ento, no momento da gerao do cdigo onde o analista conclua antecipadamente sobre modificaes em seu contedo, seus modelos no estaro mais demonstrando o real perfil do sistema. A programao uma fase separada e distinta onde os modelos criados so convertidos em cdigo.
Introduo
Testes
Um sistema normalmente rodado em testes de unidade, integrao, e aceitao. Os testes de unidade so para classes individuais ou grupos de classes e so geralmente testados pelo programador. Os testes de integrao so aplicados j usando as classes e componentes integrados para se confirmar se as classes esto cooperando uma com as outras como especificado nos modelos. Os testes de aceitao observam o sistema como uma "caixa preta" e verificam se o sistema est funcionando como o especificado nos primeiros diagramas de "use-cases". O sistema ser testado pelo usurio final o qual verificar se os resultados mostrados esto realmente de acordo com as necessidades levantadas durante a fase de requisitos.
Introduo
Exerccios
1. Cite e descreva, brevemente, os principais mtodos que deram origem a UML bem como os seus autores. 2. Que tipos de sistemas podem fazer uso da UML? 3. Quais so as fases do desenvolvimento de software? Quais so as principais atividades de cada uma destas fases?
Introduo
Espao para anotaes
2. Diagrama de Use Case
Diagrama de Use Case
Objetivos
Entender o diagrama de use case Conhecer os elementos que fazem parte deste diagrama Aprender a modelar um diagrama de use case para um sistema
Conhecer os tipos de relacionamentos possveis entre os elementos do use case Saber quando e como utilizar use case
Definio de Use Case
Neste captulo iremos estudar um dos diagramas centrais da UML, o diagrama de Use Case (Casos de Uso). Este um diagrama fundamental para a modelagem de sistemas orientados a objeto quando utilizamos UML. A maior dificuldade em modelarmos um sistema no est nos diagramas que temos que desenhar, no cdigo que devemos criar ou nas bases de dados que devemos projetar. Na realidade est nos requisitos que devemos gerenciar. Os requisitos que um sistema possui muitas vezes so complexos, no estou falando aqui de requisitos simples, como o usurio pedir "Faa um programa que permita a leitura de uma seqncia de nmeros e informe a mdia e o desvio padro desse conjunto". Temos na verdade que lidar com dezenas de pginas de "desejos do usurio". Sim, o usurio deseja que o sistema realize determinadas tarefas, deseja que o sistema realize seus sonhos e muitas vezes deseja que ele faa milagres. A espectativa dos usurios quanto aos sistemas sempre muito grande, eles imaginam que o mesmo possa realizar todas as coisas que eles precisam e que ir resolver todos os seus problemas. Acham no sistema a soluo para os seus problemas. Sabemos que isto no verdade e que algumas tarefas no podemos modelar e passar par dentro do software. Pois com essa expectativa humana que temos que lidar. Temos que entender o que o usurio quer, e muito mais importante, demonstrar que realmente entendemos seus desejos. A grande pedra do desenvolvimento de sistemas comea exatamente neste ponto. Como era difcil validar com o usurio o que havia sido levantado! Como era difcil transportar para modelos e cdigos aquelas dezenas de linhas em linguagem natural! Precisamos documentar todos os desejos dos usurios para depois podermos tentar realizlos. A Lngua Portuguesa, assim como outras, ambgua, por natureza. Portanto, necessitamos de um padro que permita o uso de linguagem natural, mas em um formato que reduza as ambiguidades. Alm disso, que permita com facilidade converter essa estrutura para os diagramas e implementaes do sistema. Para isto ento temos os diagramas de Caso de Uso na UML.
O Levantamento de Requisitos
A UML e a modelagem de casos de usos no interfere nas tcnicas usadas pelos desenvolvedores para o levantamento de requisitos. Pelo contrrio, o caso de uso torna-se o "brao direito" do desenvolvedor, auxiliando-o a validar os requisitos extrados junto ao usurio. O levantamento de requisitos de um sistema no uma tarefa fcil, mas tambm no impossvel. O problema reside no fato de que estamos lidando com um ser humano que expressa suas idias, geralmente fora de ordem e sem muita explicao. difcil encontrarmos o usurio que nos fornea a receita de bolo pronta para desenvolver seu sistema. Normalmente ele tem muitos problemas, muitas idias de como solucion-los e uma idia bem distorcida do que um sistema de computao pode fazer por ele. E a partir da nossa tarefa bem simples: pegar todo esse emaranhado e transformar primeiramente numa documentao inteligvel para ambas as partes e depois no sistema dos sonhos dele! Claro que estou brincando, no to simples assim todo este processo e muitas vezes ns passamos por inmeras discues onde precisamos mostrar que algumas coisas que o usurio est querendo fazer de uma determinada forma no ser possvel e que para poder atingir o mesmo objetivo devemos seguir outro caminho. Sabemos que os problemas existem, mas com as tcnicas, ferramentas e paradigma adequados, tudo pode correr tranqilamente. Temos que ter em mente que o usurio no o nosso inimigo, pelo contrrio, se conseguirmos estabelecer com ele uma comunicao sem rudos, certamente a validao ocorrer sem problemas e o nosso software conseguir ento satisfazer os desejos do usurio. Durante este processo de levantamento de requisitos atravs de conversas com os usurios preciso mostrar para o usurio que devemos formar um time para alcanarmos o mesmo objetivo. importante que durante este processo haja muita troca de informaes entre os usurios e analistas. Esta troca de informaes que ir garantir o sucesso desta etapa de levantamento de requisitos. Vamos pensar: se o usurio despeja sobre ns analistas uma centena de conceitos e procedimentos a respeito da sua rea de negcios e apenas "engolimos" esses conceitos sem analis-los, o que ocorrer? Provavelmente estaremos implementando a nossa impresso sobre o assunto e no a realidade do problema. Toda informao, por mais singela, deve ser analisada quanto a sua inconsistncia e/ou ambiguidade. Para que voc entenda o que quero transmitir, vamos fazer um teste.
Suponhamos o seguinte dialogo entre usurio e analista: Desenvolvedor: O quo o senhor espera desse sistema? Usuario: Eu tenho uma loja de peas. Gostaria que o meu PV fosse interligado com meu estoque e eu pudesse a qualquer momento alterar valores dos FP's. Posso oferecer descontos a alguns tipos de clientes, mas preciso autorizar essa operao. No fim do ms quero um relatrio dos produtos que mais venderam. Preciso tambm saber a estatstica de vendas por forma de pagamento. De tempos em tempos deve aparecer na tela do sistema uma promoo relmpago que de um brinde ao cliente. Preciso que o sistema controle os pedidos tambm. O que voc identificaria de ambguo ou no compreensvel nessa descrio do usurio? Vrias coisas, no?! Pois bem, cabe ao analista buscar o esclarecimento desses itens. Podemos ento comear perguntando a esse usurio:
O que 6 PV e FP? Que tipos de clientes podem receber descontos? Como seria feita esta autorizao de desconto e por quem? Que quantidade de produtos deve aparecer no relatrio dos que mais venderam? A estatstica leva em conta que perodo (semanal, quinzenal, mensal, etc)? Quanto tempo significa "de tempos em tempos"? Quais pedidos precisam ser controlados: os dos clientes ou os feitos aos fornecedores?
Provavelmente, as respostas a essas perguntas levaro a novas dvidas, que precisaro ser esclarecidas. Percebemos, ento, que uma postura correta dos participantes associada a boas tcnicas de levantamento de requisitos (por exemplo: entrevistas e brainstorming (Consiste em uma ou vrias reunies nas quais os participantes sugerem idias, sem que as mesmas sejam criticadas. Numa segunda fase, as idias passam por uma reviso e organizao). Todavia, precisamos expressar esses requisitos de uma forma que no seja para o desenvolvedor um texto extenso e pouco estruturado e para o usurio no sejam seqncias de comandos sem o menor sentido. agora que a modelagem de casos de uso nos ajuda, unindo usurios e desenvolvedores.
O Use Case
Um caso de uso (Use Case) descreve uma seqncia de aes que representam um cenrio principal (perfeito) e cenrios alternativos, com o objetivo de demonstrar o comportamento de um sistema (ou parte dele), atravs de interaes com atores. Vamos esmiuar essa definio para conseguir entende-la. Uma vez que o desenvolvedor levante os requisitos com o usurio, h a necessidade de document-los, no s para entendimento e validao de ambas as partes, como para servir de base no ambgua para toda a equipe de desenvolvimento. A documentao dos requisitos evita que informaes importantes se percam, sendo descobertas apenas ao apresentar o produto final ao usurio. Em desenvolvimento de sistemas no funciona amarrar uma fitinha no dedo, para no esquecer de um requisito importante! Utilizando a modelagem de casos de uso, o primeiro passo do desenvolvedor separar as funcionalidades do sistema. Destas funcionalidades, devemos agrupar um conjunto de aes que tenham um objetivo bem definido. Suponhamos, num sistema de vendas de uma loja de roupa, que sejam tarefas distintas e bem definidas: consultar informaes sobre um produto, efetuar reserva, emitir comprovante de reserva, efetuar venda, emitir nota fiscal, realizar fechamento dirio do caixa, etc. Cada uma destas tarefas possui um conjunto de aes que precisam ser executadas para que o objetivo da tarefa seja alcanado. No caso de efetuar venda, preciso informar a identificao da vendedora, a identificao do produto, quantidade vendida, etc. Ao pensarmos nessas aes realizadas numa rotina sem problemas, estamos lidando com um cenrio perfeito, que ser o nosso cenrio principal. O cenrio principal descreve uma seqncia de aes que sero executadas considerando que nada de errado ocorrer durante a execuo da seqncia. Vejamos no exemplo abaixo o trecho do caso de uso "Emitir Saldo em um terminal de caixa eletrnico":
Cenrio Principal
1. 2. 3. 4. 5. 6. O sistema realiza a leitura do carto magntico do correntista; O sistema solicita a digitao da senha. O correntista digita a senha; O sistema valida a senha; O correntista seleciona a opo de saldo; O sistema questiona o tipo de saldo: conta corrente, poupana e aplicaes; O sistema processa e mostra o saldo solicitado pelo cliente.
No exemplo acima, temos um cenrio perfeito, no qual nada ocorre de errado. Todavia, o mundo no perfeito, muito menos as transaes de um sistema. Ento, como podemos representar as excees? Podemos represet-las com os cenrios alternativos. Por exemplo: considerando o cenrio principal da emisso de saldo em um Caixa Eletrnico, poderiamos modelar os cenrios alternativos descritos abaixo. Alternativa: Problemas na leitura do carto magntico 1) Se o sistema no conseguir ler os dados do carto magntico, tentar nova leitura por, no mximo, mais duas vezes. Caso persista o problema, encerrar o caso de uso (ao dizermos que haver o encerramento do caso de uso. Estamos afirmando que a rotina no pode prosseguir pelo motivo relatado. Logicamente que numa implementao, o fluxo retornar ao seu incio (nesse caso, a leitura de um prximo carto magntico). Alternativa: Senha Invlida 3) Se a senha digitada pelo correntista no for igual a senha cadastrada no sistema, informar ao mesmo e solicitar nova digitao. Esse processo pode ser repetido por no mximo trs tentativas (incluindo a primeira). Aps a terceira tentativa, a conta do usurio dever ser bloqueada e o caso de uso encerrado. Include Bloquear Conta (o include corresponde a um dos tipos de relacionamentos entre os diagramas de caso de uso e ser explocado mais adiante nesta apostila). Alternativa: Conta Inexistente 6) Se o correntista no possuir o tipo de conta selecionada, informar ao mesmo e encerrar o caso de uso.
Nos exemplos acima as alternativas so apresentadas como subitens do cenrio principal (tens 1, 3 e 6). Esse procedimento facilita a associao da alternativa com o fluxo principal. O caso de uso deve descrever uma rotina bem definida do sistema e deve ser totalmente compreensvel tanto para a equipe de desenvolvimento quanto para os clientes que detm o conhecimento do domnio do sistema. O caso de uso, por expressar os requisitos do sistema - nada mais do que a essncia deste -, utilizado durante todo o processo de desenvolvimento. Os requisitos alm de serem a base para a criao dos modelos de anlise, projeto e implementao, tambm so usados como base para a criao de testes do sistema. Podemos dizer que o modelo de casos de uso ser central para todas as demais etapas do desenvolvimento do sistema. Este diagrama ser sempre
utilizado na construo dos demais, sendo muito importante estar bem definido expressando os desejos do cliente. J entendemos porque o caso de uso uma seqncia de aes, o que um cenrio principal e o que um cenrio alternativo. Esta faltando apenas saber o que so interaes com atores. Ao modelarmos um sistema, necessitamos saber at que ponto devemos nos preocupar. Estes pontos-limites so a fronteira do sistema (system boundary). Por exemplo: um sistema de controle de vendas emitir em algum momento o faturamento semanal ou mensal de cada vendedor para o Departamento Pessoal. Todavia, no responsabilidade do sistema o que o Departamento Pessoal far com essa informao. Os sistemas recebem e enviam informaes para o mundo externo atravs de suas fronteiras, tambm conhecidas como interface do sistema. Logicamente que essas informaes no podem cair num "buraco negro", na sada, nem surgem por mgica, na entrada. Algum ou algo deve ser responsvel por enviar e/ou receber informaes do sistema.
Vejamos a representao grfica do caso de uso:
Um caso de uso representado por uma elipse contendo o seu nome. O nome do caso de uso tambm pode ser colocado abaixo da elipse, que pode conter ou no compartimentos referentes a pontos de extenso (estes sero apresentados mais tarde no curso).
Figura 2-1: Representao bsica de um use case
Atores
Na modelagem de casos de uso, esse papel externo exercido por um ator (actor). Na realidade, esse ator, que pode ser tanto uma pessoa, como um grupo ou ainda um sistema, representa um conjunto de papis. Um caso de uso pode se relacionar com mais de um ator. Um ator representa um conjunto de papis exercido por um usurio do sistema ao interagir com um determinado caso de uso. Um ator , portanto, um papel que um usurio desempenha em relao ao sistema. Quando voc lidar com atores, importante pensar nos papeis em vez de pensar nas pessoas ou em cargos. Os atores desempenham os casos de uso. Um nico ator pode desempenhar muitos casos de uso; um caso de uso pode ter reciprocamente vrios atores desempenhando-o. Na prtica, considero que os atores so mais teis quando se est propondo os casos de uso. Em face de um grande sistema, freqntemente pode ser difcil propor uma lista de casos de uso. Nestas situaes, mais fcil chegar primeiro a lista de atores, e, ento, tentar estabelecer os casos de uso para cada ator. Os atores no precisam ser humanos, embora sejam representados como bonecos humanos nos diagramas de caso de uso. Um ator tambm pode ser um sistema externo que necessita de alguma informao do sistema atual. Existem diversas variaes no que as pessoas mostram como atores. Algumas pessoas mostram cada sistema externo ou agente humano no diagrama de caso de uso; outras preferem mostrar o ativador do caso de uso. Prefiro expor o agente que obtm valor do caso de uso, o qual algumas pessoas chamam de ator bsico. Entretanto, no levo isso muito longe. Contento-me em ver o sistema de contabilidade obtendo valor, sem tentar identificar o agente humano que obtm o valor do sistema de contabilidade - isso transmitiria modelagem ao prprio sistema de contabilidade. Dito isto, voc deve sempre contrapor casos de uso com atores do sistema, descubra quais so os objetivos reais do usurio e considere maneiras alternativas para atingir estes objetivos.
Vejamos a representao grfica de um ator:
O cone esteretipo padro para um ator a figura de um "stick man", contendo seu nome abaixo da figura. Outra representao consiste num retngulo de classe, com o esteretipo << actor >>. E, ainda, permitido ao desenvolvedor utilizar outros cones que identifiquem mais precisamente o tipo de ator.
Figura 2-2: Representao de atores
Quando estou trabalhando com atores e casos de uso, no me preocupo muito sobre qual a associao exata entre eles. Na maioria das vezes, estou realmente interessado nos casos de uso; os agentes so simplesmente um meio de chegar l. A medida que tenho todos os casos de uso, no me preocupo com os detalhes dos agentes. Existem algumas situaes nas quais vale a pena descobrir os agentes mais tarde.
O sistema pode precisar configurao para vrios tipos de usurios. Neste caso, cada tipo de usurio um ator e os casos de uso lhe mostram o que cada ator precisa fazer. Identificar quem deseja casos de uso pode ajud-lo a negociar prioridades entre vrios atores.
Alguns casos de uso no tm ligaes claras com atores especficos. Considere uma empresa de servio pblico. Evidentemente, um dos seus casos de uso Enviar Contas. Entretanto, no fcil identificar um ator associado. Nenhum papel de usurio em especial necessita uma conta. A conta enviada para o cliente, mas ele no se importaria se isso no acontecesse. O melhor palpite para ator aqui o Departamento de Cobrana, no sentido que este obtm valor deste caso de uso. Mas o Departamento de Cobranca, no est, geralmente, envolvido neste caso de uso.
Esteja ciente de que alguns casos de uso no aparecem como resultado do processo de consider-los para cada ator. Se isso acontecer, no se preocupe muito. O importante compreender casos de uso e os objetivos dos usurios que eles atingem. Uma boa fonte para identificar os casos de uso so os eventos externos. Considere todos os eventos do mundo externo para os quais voc quer reagir. Um dado evento pode causar uma reao no sistema que no envolve usurios, ou pode causar principalmente reao dos usurios. A identificao dos acontecimentos para os quais o sistema necessita reagir vai lhe ajudar a identificar os casos de uso. Como exemplo vamos considerar a representao da figura abaixo. Num determinado sistema acadmico, a rotina de atualizar a freqncia dos alunos pode ser executada por quem? Pelos funcionrios da Secretaria, pelo prprio Professor ou pelo Sistema de Avaliao on-line. Esses papis so representados por Atores. Essa comunicao sistema-ator (e vice-versa) consiste da interao entre sistema e atores.
Figura 2-3: Atores interagindo com o caso de uso
responsabilidade do caso de uso demonstrar com quais atores o sistema interage. Essa identificao na fase de anlise fornece ao projetista, no futuro, base para a criao dos perfis de acesso ao sistema.
O caso de uso especifica como alcanar a realizao de um procedimento sem relacionar detalhes de implementao. Portanto, mostramos o que executar sem definir a forma como feito. Veja os exemplos. Considere o seguinte trecho de caso de uso: "... O cliente seleciona na lista o produto desejado..." Essa pequena descrio nos diz que existe uma lista contendo os produtos disponveis para esta operao. Todavia, a descrio no diz se essa lista ser representada por um grid, uma listbox, uma combobox ou algum outro tipo de componentes. No represente nas alternativas validaes que por default j so feitas em qualquer sistema. Por exemplo: num campo data qualquer, checar se a entrada do usurio uma data vlida no calendrio (por exemplo: 14/01/2004). Entretanto, deve-se expressar validaes que se refiram as regras de negcio. Por exemplo: o campo data de resciso de contrato deve estar dentro do ms corrente. Esta uma regra de negcio que deve aparecer no caso de uso. Exemplo de um caso de uso com cenrios principais e alternativos. Caso de Uso: Reserva em um Restaurante
Ator: Atendimento ao cliente Cenrio Principal
1. O cliente informa ao atendente a data da reserva, que repassada ao sistema; 2. O sistema mostra o mapa do salo do restaurante, indicando as mesas j reservadas e as que esto livres. O sistema calcula e exibe o nmero de reservas ainda disponveis. 3. Um ou vrios lugares disponveis (so) escolhido(s) para reserva. 4. O sistema solicita o CPF do cliente, para identificao do mesmo no sistema. O sistema pesquisa o cliente e mostra nome e telefones de contato, para confirmao. 5. Aps confirmao, a reserva efetuada em nome do cliente.
Cenrios Alternativos
Alternativa: Data no disponfvel para reserva 1) O sistema verifica se para a data informada possvel efetuar reservas. Caso negativo, uma nova data deve ser solicitada.
Alternativa: Reservas esgotadas 1) O sistema verifica se para o dia informado, as reservas esto esgotadas. O sistema deve possibilitar que seja informada nova data ou que se encerre a solicitao de reserva. Alternativa: Cliente no cadastrado 4) Se o cliente no for cadastrado: Extend Cadastrar Cliente de Reserva (Extend um tipo de relacionamento que explicarei mais adiante). No existe um padro da UML que determine uma forma nica de se escrever casos de uso. As aes podem ser descritas em pargrafos ou atravs de enumeraes, identificadas (por letras ou nmeros) ou no. Outra forma criar um texto com sees de pr e ps-condies. possvel, ainda, escrever o caso de uso como um pseudocdigo. O importante que cada caso de uso deve relacionar o suficiente para seu entendimento e que seja compreensvel para todos os envolvidos no processo de desenvolvimento.
Relacionamentos entre casos de uso e atores
Os casos de uso representam conjuntos bem definidos de funcionalidades do sistema, que no podem trabalhar sozinhas no contexto do sistema. Portanto, esses casos de uso precisam se relacionar com outros casos de uso e com atores que enviaro e recebero mensagens destes.
Relacionamentos entre extenso e incluso.
casos
de
uso:
generalizao/herana,
Relacionamentos entre atores: generalizao/herana Relacionamentos entre atores e casos de uso: associao
Associao
Representa a interao do ator com o caso de uso, ou seja, a comunicao entre atores e casos de uso, por meio do envio e recebimento de mensagens. As associaes entre casos de uso so sempre binrias, ou seja, envolvem apenas dois elementos. Representam o nico relacionamento possvel entre atores e casos de uso. Por exemplo: O ator Correntista envia e recebe mensagens do Caso de Uso Calcular Emprstimo Pessoal, por um relacionamento de associao.
Figura 2-4: Relacionamento de associao entre atores e use case
A representao grfica de uma associao corresponde a uma linha slida, ligando o caso de uso ao ator e vice-versa.
Generalizao
Ocorre entre casos de uso ou entre atores. considerado quando temos dois elementos semelhantes, mas com um deles realizando algo a mais. Costuma ser comparado ao relacionamento de extenso, com uma variao do comportamento normal sendo descrita sem muito rigor. Segue o mesmo conceito da orientao a objetos. Podemos dizer tambm que este relacionamento conhecido como herana. Vejamos a representao deste relacionamento:
Um relacionamento de generalizao representado graficamente pela seta de generalizao, que corresponde a uma linha slida com uma nica seta fechada, mas no preenchida em uma das pontas. A seta parte do caso de uso mais especfico em direo ao mais genrico.
Por exemplo: num caso de uso no qual C2 herda de C1, significa dizer que temos C1como um caso de uso mais genrico e C2 mais especfico.
Figura 2-5: Generalizao entre casos de uso
Por exemplo: podemos criar um ator generico Aluno e especializ-lo nos atores Aluno Matriculado e Aluno Ouvinte.
Figura 2-6: Gerneralizao entre atores
Extenso (extends)
Um relacionamento de extenso entre casos de uso indica que um deles ter seu procedimento acrescido, em um ponto de extenso, de outro caso de uso, identificado como base. Os pontos de extenso so rtulos que aparecem nos cenrios do caso de uso base. permitido colocar diversos pontos de extenso num mesmo caso de uso, inclusive repetir um mesmo ponto de extenso. No corpo do caso de uso representamos a extenso com o termo Extend seguido do ponto de extenso.
Figura 2-7: Relacionamento de extenso (extend)
Por exemplo: Cenrio Principal ... 5. Escolher forma de pagamento. 6. Se cliente VIP, calcular desconto especial. Extend (desconto ClienteVip). ... Voc deve estar se perguntando: Como e quando usar um relacionamento de extenso? Um caso de uso de extenso muito utilizado para: expressar rotinas de exceo ou para expressar o desmembramento de um caso de uso (quando um cenrio alternativo possui um fluxo grande ou que merea uma ateno especial); separar um comportamento obrigatrio de outro opcional; separar um trecho do caso de uso que ser executado apenas em determinadas condies; separar trechos que dependam da interao com um determinado ator. Por exemplo: no cadastro de uma venda, a rotina de desconto s pode ser
executada pelo gerente. Essa rotina pode ser transferida para um caso de uso de extenso. Vejamos a representao grfica:
Um relacionamento de extenso representado graficamente por uma seta tracejada com a ponta aberta, que parte do caso de uso estendido e contm o esteretipo <<extend>>. Junto deste texto possvel colocar rtulos correspondentes aos pontos de extenso.
Figura 2-8: Relacionaemnto de extenso e incluso (visto abaixo)
Incluso (Include)
Indica que um deles ter seu procedimento copiado num local especificado no outro caso de uso, identificado como base. Voc deve estar se perguntando: Quando uso um relacionamento de incluso? Quando existem cenrios cujas aes servem a mais de um caso de uso. Por exemplo: validar matrcula til para casos de uso como renovar matrcula de aluno, emitir histrico escolar, lanar notas de provas, entre outros. Textualmente, um relacionamento de incluso, dentro da descrio de um caso de uso base, representado com o termo Include seguido de seu nome.
Por exemplo: Cenrio Principal 1. O aluno digita sua matrcula. O sistema verifica se a matrcula vlida e ativa. Include (Validar Matrcula). (...) Mais do que evitar a cpia de trechos idnticos, ganhamos tempo de modelagem e tambm de implementao ao trabalhar com casos de uso de incluso. Perceba ainda que teremos um ganho significativo quando depois formos fazer a manuteno do sistema. Veja a representao grfica deste tipo de relacionamento:
Um relacionamento de incluso representado graficamente por uma seta tracejada com a ponta aberta (este o smbolo da dependncia tambm), que parte do caso de uso base e contm o esteretipo <<include>>.
Figura 2-9: Relacionamento de incluso
Abaixo voc tem outro exemplo de um relacionamento de incluso, onde um instrutor pode atualizar material didtico porm esta atividade ir incluir outra onde dever ser definido e registrado uma data para entrega deste material.
Figura 2-10: Relacionamento de incluso entre use cases
Modelando requisitos com casos de uso

No existe uma ordem prdefinida que determine quais diagramas devem ser modelados primeiramente. A ordem determinada pela preferncia do desenvolvedor e/ou processo que esteja sendo usado. Sabemos que a UML independente de processo. Desta forma, o objetivo deste curso no apresentar um processo formal para trabalhar com a UML. Entretanto, presencio a ansiedade vivida por quem inicia a aprendizagem da UML em conhecer a "ordem dos fatos". Assim, procurarei, em tpicos como este, orientar sobre um determinado caminho dos muitos que vocs podem escolher. Pelo menos um pontape inicial! Alguns desenvolvedores iniciam a modelagem do sistema pela criao das classes, outros pelos casos de uso. Se este for o caso, importante tomar cuidado com os nomes e os verbos utilizados, pois estes transformar-se-o em objetos, atributos e mtodos. Outros desenvolvedores comeam desenvolvendo o diagrama de casos de uso para fazer o levantamento dos requisitos do sistema, depois ustilizam alguns diagramas de atividades para expressar atividades que j existem e que devero ser consideradas quando for elaborado o sistema e somente depois deste diagrama partem para a definio das classes atravs do diagrama de classes. Aconselho seguir sempre esta ltima abordagem pois melhor levantarmos todos os requisitos do sistema e document-los assim como descobrir e tambm documentar as principais atividades do sistema antes de comenar a modelar as classes. O modelo de classes est bem focado na estrutura interna do software a ser desenvolvido e quando estamos levantando requisitos bem como as atividades no estamos ainda preocupados com isto. Neste curso iremos adotar esta abordagem. Todos os casos de uso possuem nomes que os identificam e diferenciam dos demais. Segundo a UML corresponde a uma seqncia de caracteres (letras, nmeros e a maioria dos sinais de pontuao), exceto os dois-pontos, que so usados no nome do caminho (com o nome de seu pacote). Normalmente so breves expresses representando a essncia do que voc est modelando. Pode-se iniciar a modelagem a partir da descoberta de uma lista de casos de uso ou uma lista de atores. Certo que a partir de um deles possvel chegar ao outro. Veja por exemplo: Dado um caso de uso descobrimos seus atores a partir de vrios questionamentos. Um deles seria: "Quais atores so responsveis por esse caso de uso?" Dado um ator, descobrimos casos questionamentos. Alguns deles seriam: de uso a partir de vrios "Quais casos de uso so
responsabilidades desse ator?" "Os atores precisam interagir com quais casos de uso?" Antes de identificar o ator importante identificar seus papis. Uma vez identificados os casos de uso, devemos nos concentrar em descrever os cenrios principais. A partir dos cenrios principais, identificamos e descrevemos os cenrios alternativos. comum durante a descrio percebermos a necessidade de cenrios comuns a outros casos de uso. Estamos comecando a descobrir os casos de incluso. Da mesma forma, casos de uso muito extensos, seja quanto ao cenrio principal ou quanto aos cenrios alternativos, devem ser divididos em casos de extenso. Os casos de uso possuem um enfoque conceitual dentro da modelagem em UML. A implementao de um caso de uso ocorre atravs dos diagramas de interao (estes sero estudados mais adiante no curso)
Casos de uso e pacotes

Em sistemas de media/alta complexidade comum termos dezenas de casos de uso. Nesse caso, a representao de todos eles em um nico diagrama uma tarefa impossvel. A fim de minimizar a visualizao e, principalmente, organizar esses casos de uso considerando uma mesma abordagem conceitual, podemos trabalhar com pacotes. Um pacote corresponde a um agrupamento de qualquer elemento de modelo, como casos de uso, classes, estados, outros pacotes, etc. Graficamente, o pacote representado como um grande retngulo com um pequeno retngulo como uma aba posicionada no topo do seu lado esquerdo - algo como o cone que representa uma pasta. O nome do pacote deve ser exibido na aba caso seu contedo seja mostrado. Caso contrrio, o nome do pacote deve vir no seu interior.
Figura 2-11: Representao de pacote exibindo os casos de uso
Quando desejamos fazer referenda a um elemento que pertena a algum pacote, devemos usar a nomenclatura <nome do pacote> seguido de :: e <nome do elemento>.
pacote:: elemento
Por exemplo: Controle Acadmico:: Cadastrar Aluno Os elementos de um pacote devem ter nomes distintos dentro do mesmo pacote. Todavia, possvel termos elementos com o mesmo nome desde que residentes em pacotes diferentes.
Figura 2-12: Representao de um pacote sem os casos de uso
Quando Utilizar Casos de Uso
Muitas vezes nos perguntamos quando usar isto tudo, inicialmente pode parecer um pouco burocrtivo e no necessrio este processo todo, mas veremos ao passar do tempo que ele fundamental para uma boa anlise. No consigo imaginar, no momento, uma situao na qual no utilizaria casos de uso. Eles so uma ferramenta essencial na captura de requisitos e no planejamento e controle de um projeto iterativo. A captura de casos de uso uma das tarefas bsicas na fase de elaborao. A maioria dos seus casos de uso ser gerada durante est fase do projeto, mas voc descobrir mais a medida que avana. Fique alerta a eles o tempo todo. Cada caso de uso um requisito em potencial, e at que voc tenha capturado um requisito, voc no pode planejar como lidar com ele. Algumas pessoas, primeiro, listam e discutem os casos de uso, ento fazem um pouco de modelagem. Tambm descobri que, fazendo modelagem conceitual com os usurios, ajuda a revelar casos de uso. Portanto, tendemos a fazer casos de uso e modelagem conceitual ao mesmo tempo. E importante lembrar que casos de uso representam uma viso externa do sistema. Como tal, no espere nenhuma correlao entre eles e classes dentro do sistema. Quantos casos de uso voc deve ter? No existe uma resposta exata para isto. Depende do tamanho do sistema e tambm depender da equipe e tipo de sistema que est sendo feito. Lembre-se que voc ter vrios cenrios e que em cada cenrio podem existir vrios casos de uso e um caso de uso pode ter casos alternativos. Com isto voc j viu que o nmero de casos de uso ser medido pelo seu bom senso de modelagem e que voc dever fazer quantos achar necessrio para levantar todos os requisitos. No tem um nmero e nem uma frmula para calcular isto.
Exemplos de descrio textual

Abaixo voc tem dois exemplos de descrio textual para use-cases.
Use Case: Criar repositrio para material Atores: - Gerente Cenrio principal de Sucesso ( Perfeito ): 1 - Gerente fornece usurio e senha para login 2 - Sistema valida usurio e senha 3 - Sistema redireciona Gerente para sua pgina home 4 - Gerente seleciona no menu a opo para criar repositrio 5 - Sistema redireciona o Gerente para uma tela de criao do repositrio 6 - Gerente seleciona em uma lista o curso para o qual quer criar repositrio 7 - Gerente seleciona em uma lista de instrutores habilitados o responsvel pelo material 8 - Gerente informa data prevista de entrega para o material 9 - Gerente confirma a criao do repositrio 10 - Sistema valida os dados da interface fornecidos pelo Gerente 11 - Sistema envia email para o Instrutor comunicando que o repositrio foi criado Cenrios alternativos ( Excees ): 2a: Sistema no consegue validar usurio e senha: 1 - Sistema avisa o Gerente atravs de uma mensagem na tela e solicita novamente o login e senha para novamente validar. Validar no mximo 3 vezes o usurio e senha. Se no for possvel validar ento bloquear a conta deste usurio. 10a: Erro ao validar dados da tela, falta preencher campos ou as informaes esto em formato incorreto. 1 - Sistema sinaliza o campo com problema e solicita correo.
Use Case: Entrega do material didtico Atores: - Instrutor Cenrio principal de Sucesso ( Perfeito ): 1 - Instrutor acessa o sistema com seu usurio e senha 2 - Sistema valida o usurio do Instrutor e redireciona para uma pgina home 3 - Instrutor seleciona o link para envio do material didtico no men do sistema 4 - Instrutor fornece os arquivos que fazem parte do material didtico em um formulrio para seleo de arquivos 5 - Sistema recebe os arquivos e os salva no repositrio do banco de dados 6 - Sistema confirma para o Instrutor de que o envio foi feito com sucesso 7 - Sistema envia uma confirmao por email para o Instrutor informando da entrega 8 - Sistema envia um aviso por email para o Gerente de que o material foi entregue Cenrios alternativos ( Excees ): 2a: Sistema no consegue validar usurio e senha: 1 - Sistema avisa o Instrutor atravs de uma mensagem na tela e solicita novamente o login e senha para novamente validar. Validar no mximo 3 vezes o usurio e senha. Se no for possvel validar ento bloquear a conta deste usurio. 4a: Sistema detecta a falta de um tem do material didatico. 1 - Sistema avisa qual tem (apostila, slides, setup, instrues) falta e solicita ao Instrutor para fornecer este item. Se no houver este tem o Instrutor deve sinalizar selecionando uma opo
Exerccios
1 Brevemente descreba quais so os objetivos bem como em qual momento devemos utilizar o diagrama de use case. 2 O texto abaixo um descritivo para um sistema de controle de material didtico em uma empresa de treinamento. Voc deve ler o texto e montar um diagrama de use case que represente as funcionalidades bem como os papis/atores que podem executar cada uma delas. No se preocupe ainda com classes, estas sero levantadas e modeladas mais adiante. Dica: No se detenha inicialmente nos tipos de relacionamentos entre os elementos, concentre-se nos use cases e no ator que pode executa-los, deixe para no final uma segunda passade de olhos para identificar possveis relacionamentos.
Descrio do sistema: Objetivo: Desenvolver um sistema para controle de material didtico dos cursos realizados em uma empresa de treinamento. Perfis de usurios: Gerente de Treinamento, Instrutores, Responsvel pelo Suporte ao Treinamento. Telas do sistema: 1) 2) 3) 4) 5) 6) Criao do repositrio para o material didtico; Instrutor fornece a data prevista para entrega do material didtico; Instrutor entrega material didtico via o sistema; Instrutor solicita alterao do material didtico; Manuteno do repositrio: alterao do responsvel pelo mesmo; Bloquear acesso de um usurio ao sistema. Assistente Administrativo e
Descrio da necessidade: Fazem uso deste sistema instrutor, assistente administrativo, responsvel pelo suporte ao treinamento e o gerente de treinamento da empresa. Os grupos de usurios devem acessar o mesmo a fim de alimentar e buscar informaes sobre o material didtico dos treinamentos. O gerente de treinamento deve
acessar o sistema (com usurio e senha) a fim de criar um repositrio para o material didtico de um determinado curso, o qual dever ser fornecido por um instrutor. Todo curso da empresa ter um material didtico e um instrutor responsvel por ele. O material didtico composto por: arquivo texto compactado da apostila, arquivo compactado com os slides do curso, arquivo compactado com uma documentao relatando o tipo de equipamentos necessrios para realizar o curso, softwares necessrios bem como o procedimento de instalao dos mesmos nos respectivos equipamentos, arquivo compactado com o setup do curso (arquivos, scripts, imagens e informaes de como deve ser instalado este setup em cada estao de trabalho dos alunos). A criao de um repositrio para o material didtico de um curso ser feita pelo gerente de forma que o instrutor possa acessar o sistema e enviar os arquivos que compe este material didtico. Existe uma checagem automtica do sistema no momento que o instrutor est enviando os dados do material didtico para que o mesmo fornea ao menos o arquivo da apostila, os slides do curso e o documento de configurao do ambiente contendo os equipamentos e procedimentos necessrios para instalao dos softwares. Caso o instrutor no fornea estes trs arquivos mencionados acima, ser avisado pelo sistema na hora do envio e o procedimento ser cancelado. Aqueles itens que no fizerem parte do material didtico de um curso devem ser marcados na hora de submeter o material pelo instrutor como no existente para aquele curso. O instrutor ao acessar o sistema visualizar uma lista de cursos dos quais ele o responsvel pelo material didtico, bem como um indicativo de quais itens deste material didtico j foram entregues e quais ainda faltam. Uma vez submetido, caso seja necessrio atualizar ou alterar algum dos itens do material, o instrutor dever solicitar ao gerente que libere o acesso para alterao do mesmo, uma vez que logo aps os arquivos serem enviados o material didtico ser bloqueado para alterao e isto ser possvel somente atravs da liberao do gerente. Quando for feita esta solicitao para alterao do material didtico, o instrutor dever fornecer uma nova data prevista de entrega do mesmo, bem como dever ser informado o motivo da alterao. O motivo ser julgado pelo gerente que ir decidir se libera ou no o acesso ao material. Isto feito por questo de segurana e tambm para controle de verses de apostilas a fim de evitar que pequenas alteraes gerem uma nova verso sem necessidade. Todo o material que for entregue provocar um arquivamento a ttulo de histrico da verso anterior do mesmo, bem como ir disparar um aviso ao assistente administrativo de que o material deve ser substitudo na grfica para impresso. Neste mdulo de interao com o usurio o sistema tambm deve permitir que o instrutor possa sugerir nomes de cursos a serem montados sendo que estes sero recebidos e avaliados pelo gerente de treinamento. No momento de criao do repositrio para o material didtico dever ser definida uma data prevista para entrega do material. Uma vez fornecida a data o instrutor no mais poder alter-la. O sistema dever possuir um mecanismo de alertas para que o instrutor seja lembrado com 15 e 5 dias de antecedncia da entrega do material didtico do curso. Sempre no momento de criao de um repositrio para material didtico de um curso, o instrutor deve ser alertado pelo sistema de que o mesmo foi criado. O gerente de treinamentos dever acessar o sistema e ter a sua disposio as seguintes funes: criar repositrio para o material didtico de um determinado curso, adicionar instrutor, assistente administrativo e responsvel
pelo suporte ao sistema, liberar acesso ao material didtico para um determinado instrutor, definir o modelo de material didtico para os cursos, transferir a propriedade de um material didtico de curso de um instrutor para o outro, verificar materiais didticos de cursos que foram entregues pelos instrutores, emitir relatrios diversos (listados mais abaixo) e bloquear acesso de um instrutor ao sistema. Funes disponveis para o gerente do sistema: Criar repositrio para setup: cada curso possui um material didtico e o sistema dever permitir ao gerente criar o repositrio para o mesmo, remover ou trocar a propriedade deste material didtico. O material didtico composto por uma srie de elementos citados anteriormente e que devem ser fornecidos pelo instrutor quando o mesmo acessar o sistema para enviar o material. Manter instrutores, assistente administrativo e responsvel pelo suporte aos laboratrios no sistema: dever ser possvel criar, deletar e alterar contas destes perfis. Os usurios podem querer atualizar o seu endereo de e-mail ou telefone. Enviar modelo de material didtico para o instrutor: o sistema dever ser capaz de permitir com que o gerente possa liberar o material didtico de modelo do curso para o instrutor fazer o download do mesmo. Definir o modelo de material didtico para os cursos: o gerente pode adicionar ao sistema um modelo de material didtico para os cursos da empresa. Verificar materiais didticos entregues: ao acessar o sistema o gerente ir visualizar os ltimos materiais didticos de cursos que foram submetidos pelos instrutores os quais necessitam ser revisados para uma possvel aprovao. Logo aps a ao do gerente o sistema deve mandar um e-mail para o instrutor informando se o mesmo foi ou no aprovado. Caso no tenha sido aprovado consta no e-mail o motivo da rejeio. Emitir relatrios: o gerente pode emitir os seguintes relatrios: 1. listagem de cursos com o material didtico aprovado; 2. listagem de cursos com o material didtico no aprovado e que estejam sendo aguardados; 3. listagem de instrutores com os seus respectivos cursos; 4. listagem dos ltimos materiais didticos alterados em lista cronolgica inversa. Bloquear acesso de um usurio: poder ser bloqueado o acesso de um usurio (instrutor, assistente administrativo ou responsvel pelo suporte ao treinamento) ao sistema, a fim de garantir segurana do mesmo. Isto deve acontecer mais freqentemente para instrutores pois estes tem mais rotatividade.
No momento de cadastro de um instrutor devem ser fornecido os seguintes dados do mesmo: nome completo, telefones de contato, e-mail, rea de atuao. Os mesmos dados devem ser fornecidos quando for cadastrado os demais perfis do sistema.
Espao para anotaes
3. Diagrama de Atividades
Diagrama de Atividades
Objetivos
Compreender o diagrama de atividades Conhecer os elementos que fazem parte deste diagrama Aprender como desenvolver um diagrama de atividades Saber quando utilizar o diagrama de atividades
Definio do diagrama
Conforme escrevi no captulo anterior, acredito que este diagrama pode ser utilizado logo depois de fazermos uso do diagrama de casos de uso. Nem sempre voc far um diagrama de atividades, isto ir depender da anlise que voc est fazendo, se voc de fato julgar necessrio representar alguma atividade que esteja envolvida no sistema e que ir lhe ajudar a entender e documentar alguma parte importante, este diagrama ser til. Diagramas de atividades so uma das partes mais inesperadas de UML. Ao contrrio da maioria das outras tcnicas da UML, diagramas de atividades no tm origens claras nos trabalhos anteriores dos trs amigos. Ao contrrio, o diagrama de atividades combina idias de vrias tcnicas: os diagramas de eventos de Jim Odell, tcnicas de modelagem de estado SDL, modelagem de workflow e redes de Petri. Estes diagramas so particularmente teis em conexo com workflow e na descrio de comportamento que tem muito processamento em paralelo. Um diagrama de atividades um caso especial do diagrama de estados no qual todos (ou pelo menos a maioria) os estados so aes ou subatividades e no qual todas (ou pelo menos a maioria) as transies so disparadas pela concluso de aes ou subatividaes nos estados de origem. Este diagrama tem por propsito focalizar um fluxo de atividades que ocorrem internamente em um processamento, dentro de um perodo de tempo.
Elementos do diagrama
Neste item iremos estudar os elementos que compe o diagrama de atividades para depois construir um diagrama. Os elementos so simples e fceis de representar. Voc perceber que muitos deles so parecidos com aqueles que voc estava acostumado a utilizar nos fluxogramas.
Atividade
Na figura abaixo se pode ver o smbolo de uma atividade, este smbolo o estado de atividade, ou simplesmente atividade. Uma atividade um estado de estar fazendo algo: tanto um processo de mundo real, tal como datilografar uma carta, ou a execuo de uma rotina de software, tal como um mtodo em uma classe.
Figura 3-1: Representao da atividade
O diagrama de atividades descreve a seqncia de atividades, com suporte para comportamento condicional e paralelo. Um diagrama de atividades uma variante de um diagrama de estados no qual a maioria, se no todos, dos estados estado de atividade. Portanto, muito da terminologia segue a mesma terminologia de diagrama de estados.
Incio do diagrama
O incio do diagrama de atividades marcado com um sinal de um crculo preenchido. Este smbolo o mesmo para o diagrama de estados. Veja abaixo o smbolo grfico:
Figura 3-2: Representao grfica do incio do diagrama de atividades
Fim do diagrama
Assim como para indicar o incio do diagrama de atividades h um smbolo para indicar o fim deste diagrama e este smbolo utilizado tanto para o diagrama de atividades como para o diagrama de estados. A representao um cculo preenchido com um circulo contornando o mesmo. Veja abaixo o smbolo grfico:
Figura 3-3: Representao grfica do fim do diagrama de atividades
Transies
Para ligar as atividades e indicar a seqncia utilizamos flexas que representam as transies entre as atividades bem como a transio entre o incio e a primeira atividade, bem como das atividades para o fim do diagrama. Veja abaixo a representao grfica juntamente com outros itens do diagrama.
Figura 3-4: Representao grfica das transies no diagrama de atividades
Desvios
Comportamento condicional delineado por desvios (branches) e intercalaes (merges). Um desvio (branch) uma transio de entrada nica e vrias transies de sada guardadas. Somente uma transio de sada pode ser tomada, de modo que os guardas devem ser mutuamente exclusivos. A utilizao de [else] como um guarda indica que a transio "else" dever ser usada se todos os outros guardas do desvio forem falsos. Veja na figura abaixo a representao grfica de um desvio (branch):
Figura 3-5: Representao grfica de um desvio (branch)
Uma intercalao (merge) tem mltiplas transies de entrada e uma nica sada. Um merge marca o final de um comportamento condicional iniciado por um branch. Veja abaixo a representao grfica:
Figura 3-6: Representao grfica de uma intercalao (merge)
Voc no precisa mostrar explicitamente o losango para desvios e intercalaes. Um estado de atividade, como qualquer estado, pode ter mltiplas transies de sada guardadas e mltiplas transies de entrada. Use o losango se voc quiser deixar claros os desvios e as intercalates em um diagrama. Abaixo temos outro exemplo de um diagrama de atividades completo para representar a atividade de entrega de um material didtico.
Figura 3-7: Diagrama de atividades para entrega de um material didtico
Separao e Unio
Comportamento paralelo indicado por separao (Forks) e unies (Joins). Iremos agora ver este tipo de elemento pertencente ao diagrama de atividades. Uma separao (Fork) tem uma transio de entrada e vrias transies de sada. Quando uma transio de entrada acionada (triggered), todas as transies de sada so executadas em paralelo. Veja o diagrama abaixo:
Figura 3-8: Representao de Fork e Join
O diagrama mostra que as atividades de Carregar texto e Exibindo texto podem ocorrer em paralelo. Essencialmente, isso significa que a seqncia entre elas irrelevante. Essas atividades tambm podem ser executadas intercaladamente. Por exemplo, uma parte do texto carregada e ento exibida, depois carrega-se outra parte do texto a a exibe. Tambm estas atividades podem acontecer em paralelo, de forma que as duas sero executadas exatamente ao mesmo tempo, mas sabemos que para este exemplo
dado acima isto no possvel. No podemos carregar e ao mesmo tempo exibir as informaes. O diagrama de atividades permite que voc escolha a ordem em que faz as coisas. Em outras palavras, ele simplesmente determina as regras essenciais de seqncia que voc deve seguir. Esta a diferena-chave entre um diagrama de atividades e um fluxograma: os fluxogramas so normalmente limitados a processos sequenciais, enquanto que os diagramas de atividades podem lidar com processos paralelos. Isso importante para modelagem de negcios. Os negcios tem, frequentemente, processos no necessariamente seqenciais. Uma tcnica como esta que encoraja comportamento paralelo valiosa nestas situaes porque ela encoraja as pessoas a se afastarem de seqencias desnecessarias nos seus comportamentos e a identificar oportunidades para fazer coisas em paralelo. Isso pode melhorar a eficincia e o retorno de processos de negcio. Os diagramas de atividades tambm so teis para programas concorrentes, uma vez que voc pode projetar graficamente quais caminhos (threads) voc tem e quando eles precisam ser sincronizados. Quando voc tem comportamento paralelo, precisa sincronizar. No podemos liberar a edio do arquivo at que ele seja completamente carregado. Mostramos isso com a unio (join) antes da atividade Liberar edio do arquivo. Com a unio (join), a transio seguinte efetuada somente quando todos os estados nas transies de entrada tenham completado suas atividades. Separao e unio devem se completar. No caso mais simples, isso significa que toda vez que voc tiver uma separao, deve ter uma unio que una os threads iniciadas por aquelas separaes. (Esta regra vem do fato de que um diagrama de atividades , atualmente, uma forma de diagrama de estados). Entretanto, existem vrias extenes para esta regra.
Um thread que sai de uma separao pode abrir-se em uma nova separao, com os novos threads juntando-se antes de alcanar a unio da primeira separao. Se um thread saindo de uma separao vai direto para outra separao, voc pode remover a segunda separao e somente ter os threads da segunda separao saindo da primeira separao. De modo semelhante, se uma unio vai direto para uma outra unio, voc pode eliminar a primeira unio e ter as threads indo direto para a segunda. Isso uma forma de simplificar o diagrama; ela tem o mesmo significado semntico como se as separaes e unies extras estivessem l.
Existe uma exceo para a regra de que todos os estados de entrada em uma unio devem ter terminado suas atividades, antes que a unio possa ser
efetuada. Voc pode acrescentar uma condio para um thread saindo de uma separao. O resultado um thread condicional. Durante a execuo, se a condio de um thread condicional for falsa, este thread e considerado completado no que diz respeito a unio. Veja na figura abaixo um exemplo:
Figura 3-9: Representao de uma thread que pode no ser realizada
Estado de subatividade
Um estado de subatividade indica que quando este iniciado, o grfico de atividade aninhado a ele executado como um grfico de atividade independente. O estado de subatividade no finalizado at que o estado final do grfico aninhado seja alcanado, ou quando eventos disparadores ocorrem em transies vindas de fora do estado de subatividade. Visto que estados em grficos de atividade no tem normalmente eventos disparadores, estados de subatividade so normalmente finalizados quando seus grficos aninhados so terminados. Um grfico de atividade simples pode ser invocado por muitos estados de subatividades. Um estado de subatividade mostrado graficamente da mesmo forma que um estado de ao, adicionando apenas um cone no canto direito inferior representado um diagrama de atividades aninhado. O nome da subatividade colocado dentro da figura. A subatividade no necessita ser nica dentro do diagrama.
Figura 3-10: Representao de um estado de subatividade
Concorrncia Dinmica
Concorrncia dinmica permite que voc mostre interaes sem que tenha que construir um ciclo (loop). Na figura abaixo, a atividade gravar arquivo executada uma vez para cada arquivo recebido. O marcador de multiplicidade (*) indica que a atividade executada muitas vezes. A transio para Bloquear material didtico executado somente quando todos os arquivos tiverem sido gravados.
Figura 3-11: Representao de uma atividade concorrente
Raias (Swimlanes)
Os diagramas de atividades dizem o que acontece, mas no dizem quem faz o que. Em programao, isso significa que o diagrama no representa qual classe responsavel para cada atividade. Em modelagem de domno, isso significa que o diagrama no representa que pessoas ou departamentos so responsveis por cada atividade. Uma soluo, aqui, rotular cada atividade com a classe ou pessoa responsvel. Isso funciona, mas no oferece a mesma clareza que os diagramas de interao (estudaremos mais tarde) para mostrar a comunicao entre objetos. Raias so uma soluo para isso. Para usar raias, voc deve organizar seus diagramas de atividades em zonas verticais separadas por linhas. Cada zona representa as responsabilidades de uma classe especifica ou, um departamento especfico. As raias so teis porque elas combinam a descrio de lgica do diagrama de atividades com a descrio de responsabilidade do diagrama de interao. Entretanto, elas podem ser difceis de serem projetadas em um diagrama complexo. Veja abaixo a representao das rais.
Figura 3-12: Diagrama de atividade com raias
Quando Utilizar Diagramas de Atividades
Como a maioria das tcnicas de modelagem comportamental, os diagramas de atividades tem qualidades e fraquezas definidas, por isso a melhor maneira de us-los em combinao com outras tcnicas. A maior qualidade dos diagramas de atividades est no fato de que eles suportam e encorajam comportamento paralelo. Isso os torna uma grande ferramenta para modelagem de workflow, e, em princpio, para programao concorrente. A maior desvantagem destes diagramas que eles no deixam muito claras as ligaes entre aes e objetos. Voc pode definir uma ligao para um objeto rotulando uma atividade com um nome de objeto ou usando raias que dividem um diagrama de atividades em base em responsabilidades, mas isso no tem a clareza simples de diagramas de interao (estudaremos estes diagramas mais adiante no curso). Por esta razo, algumas pessoas sentem que diagramas de atividades no so orientados a objetos e, portanto, so maus. A tcnica pode ser muito til nas seguintes situaes:
Analisando um caso de uso. Neste estgio, no estou interessado em alocar aes aos objetos; eu preciso simplesmente compreender que aes precisam acontecer e quais so as dependncias comportamentais. Compreendendo o workflow. Mesmo antes de iniciar os casos de uso, acredito que os diagramas de atividades so muito teis para compreenso de um processo de negcio. Posso, facilmente, projetar estes diagramas junto com especialistas do negcio para compreender como o negcio funciona e como ele pode mudar. Descrevendo um algoritmo seqencial complicado. Neste caso, um diagrama de atividades no nada mais do que um flowchart em notao UML. Os prs e contras comuns de flowcharts se aplicam aqui. Lidando com aplicaes de processamento paralelo. Este tipo de diagrama, como j foi mostrado pode ser utilizado para demonstrar atividades que devem ou podem acontecer em paralelo.
No use diagramas de atividades nas seguintes situaes:
Tentando ver como os objetos colaboram. Um diagrama de interao mais simples e lhe d uma viso mais clara das colaboraes. Tentando ver como um objeto se comporta durante o sen ciclo de vida. Use um diagrama de estados para isso (Estudaremos mais adiante no curso).
Exerccios
Utilizando a ferramenta para modelagem de diagramas UML faa: 1 Para o diagrama de atividades da figura 18 monte um diagrama de atividades com raias destacando assim quais so os papeis que executam determinada atividade 2 Construa um diagrama de atividades para descrever o processo de solicitao de autorizao para uma reviso no material didtico.
Espao para anotaes
4. Diagrama de Classes
Diagrama de Classes
Objetivos
Conhecer os elementos que fazem parte deste diagrama Estudar os tipos de associaes que fazem parte deste diagrama Saber utilizar o escopo e visibilidade para os atributos e operaes Aprender quando se deve utilizar este diagrama Modelar um diagrama de classes
Diagrama de Classes
Introduo
Depois de termos estudado dois diagramas pertencentes UML e que podem nos auxiliar no levantamento de requisitos bem como na descrio das principais atividades envolvidas no processo do software, vamos agora estudar o diagrama de classes. Este um diagrama muito importante para a modelagem oriendada a objetos utilizando UML. Posso dizer que obrigatria a sua modelagem em funo do mesmo demostrar os componentes que fazem parte do software destacando as suas operaes e atributos. A tcnica de diagrama de classes tornou-se realmente central nas metodologias orientadas a objetos. Praticamente, cada metodologia incluiu algumas variaes nesta tcnica. O diagrama de classes no somente amplamente usado, mas tambm o receptculo para o maior escopo de conceitos de modelagem. Embora os elementos bsicos sejam necessrios para todos, os conceitos avanados so utilizados com menos freqncia. Um diagrama de classes descreve os tipos de objetos no sistema e os vrios tipos de relacionamento esttico que existem entre eles. H dois tipos principais de relacionamento esttico:
associaes (por exemplo, um cliente pode alugar vrios vdeos) subtipos (uma enfermeira um tipo de pessoa)
Diagramas de classes tambm mostram atributos e operaes de uma classe e as restries maneira com que os objetos so conectados. Veja abaixo um exemplo de diagrama de classes que iremos estudar detalhadamente neste curso.
Diagrama de Classes
Diagrama de Classes
Figura 4-1: Representao tpica de um diagrama de classes
Diagrama de Classes
Perspectivas
Antes de comear a descrever diagrama de classes, temos que mencionar uma sutileza importante no modo com que as pessoas os utilizam. Esta sutileza no comumente documentada, mas tem um impacto na maneira que voc deve interpretar um diagrama, pois se refere muito ao que voc est descrevendo com o modelo. Existem trs perspectivas que voc pode usar quando projetar diagramas de classes ou, de fato, qualquer modelo, mas esta classificao mais perceptvel em conexo com diagramas de classes.
Conceitual: Se tomar a perspectiva conceitual, voc projeta um diagrama que representa os conceitos no domnio que est sendo estudado. Estes conceitos sero naturalmente relacionados s classes que vo execut-los, mas freqentemente no existe um mapeamento direto. Na verdade, um modelo conceitual deve ser projetado com pouca ou nenhuma preocupao com o software que poder implement-lo, portanto ele pode ser considerado independente de linguagem. Especificao: Agora estamos examinando o software, mas estamos analisando as suas interfaces, no a sua implementao. O desenvolvimento orientado a objeto pe muita nfase na diferena entre interface e implementao, mas isto freqentemente negligenciado na prtica porque a noo de classe em uma linguagem OO combina interface com implementao. uma pena, porque a chave para uma programao OO eficaz programar para uma interface de classe em vez de faz-lo para sua implementao. Voc ouve com freqncia a palavra "tipo" para falar sobre uma interface de uma classe; um tipo pode ter muitas classes que o implementam e uma classe pode implementar muitos tipos. Implementao: Nesta viso, realmente, temos classes e estamos pondo a implementao s claras. Esta , provavelmente, a perspectiva usada com mais freqncia, mas, de vrias formas, a perspectiva de especificao freqentemente a melhor para ser usada.
A compreenso das diversas perspectivas crucial tanto para desenhar como para ler diagramas de classes. Infelizmente, as linhas entre as perspectivas no so rgidas, e a maioria dos modeladores no se preocupa em ter suas perspectivas classificadas quando eles esto modelando. Embora acredite que isso freqentemente no afeta muito a perspectiva conceitual e a
Diagrama de Classes
perspectiva de especificao, muito importante separar a perspectiva de especificao e a perspectiva de implementao. A perspectiva no parte da UML formal, mas considerada extremamente valiosa na modelagem e na reviso de modelos. UML pode ser usada com todas as trs perspectivas. Ligando classes com um esteretipo (Iremos estudar mais adiante), voc pode dar uma indicao da perspectiva. Voc marca classes como <<classe de implementao>> para mostrar a perspectiva de implementao, e com <<tipo>> para as perspectivas de especificao e conceitual.
Diagrama de Classes
Criando Diagramas de Classe
O diagrama de classes a estrela principal de um sistema orientado a objetos. Nesse diagrama possvel modelar detalhes das classes e seus relacionamentos. Tambm so visveis outros elementos como interfaces e pacotes. Diagramas de classes podem ser organizados dentro de pacotes, assim como um pacote (iremos estudar pacotes mais tarde) pode ser representado por um ou mais diagramas de classes. As classes so declaradas no diagrama de classes mas so usadas em muitos outros diagramas. Uma classe representada como um retngulo subdividido em trs compartimentos, separados por linhas horizontais que nessa ordem armazenam:
o nome da classe e outras propriedades gerais da mesma, incluindo esteretipos; lista de atributos; Lista de operaes.
Essa diviso corresponde notao bsica dos diagramas de classes. Entretanto, compartimentos adicionais (no definidos pela UML) podem ser includos e usados como extenses das ferramentas de modelagem, com o intuito de exibir outras informaes do modelo, como por exemplo: regras de negcio, responsabilidades, excees, etc. A maior parte desses compartimentos exibem apenas uma lista de strings, entretanto so possveis outros formatos definidos pelas ferramentas.
Figura 4-2: Representao de classe
Diagrama de Classes
As normas de estilo da UML determinam que:
o nome da classe seja centralizado e negritado para todas as linguagens que distinguem entre caracteres minsculos e maisculos, escrever as iniciais dos nomes das classes em maisculas, inclusive as primeiras letras de nomes compostos Exemplo: AlunoUniversitario, PessoaFisica, Funcionrio, Gerente, Carro,
Curso, Instrutor
os atributos e operaes devem ser escritos com formatao normal e alinhados esquerda os nomes de atributos e operaes devem iniciar com letra minscula, entretanto as iniciais das palavras compostas seguintes devem iniciar com letra maiscula Exemplo: reajustarSalario, matricular, dataNascimento
Como extenso de ferramentas, o negrito pode ser usado para marcar listas especiais de elementos. As normas de estilo da UML so importantes para a padronizao da notao da linguagem. Entretanto, s vezes, comum compatibilizarmos as normas de estilo da UML com as normas da linguagem com a qual estamos trabalhando. A linguagem java, por exemplo, segue o padro de nomes de classes e atributos especificado na UML. Os nomes de mtodos so somente modificados de forma a termos a palavra get e set na frente de alguns deles. Isto dependente da linguagem de programao e por isto no ser estudado neste curso. Se necessrio, compartimentos podem ser nomeados, cujos nomes devem ser representados com uma fonte diferente, centralizados no topo do compartimento.
Figura 4-3: Classe com seus compartimentos nomeados
Diagrama de Classes
A UML permite que em algumas visualizaes os detalhes sejam omitidos, isto , possvel mostrar: apenas o nome da classe ou o nome da classe e seus atributos ou o nome da classe e suas operaes
O nome da classe obrigatrio no podemos representar uma classe sem nome, mas perceba que podemos representar sem atributos e operaes. A grande maioria dos processos de modelagem recomendar que, no primeiro diagrama de classes desenhado, no faamos o registro de todos os detalhes das classes. Na realidade, a identificao das classes e seu detalhamento ocorre gradativamente. No processo de desenvolvimento, deve-se levar em conta que a verso do diagrama usada na fase de projeto estar mais completa.
Diagrama de Classes
Compartimento do Nome da Classe
O compartimento de nome mostra o nome da classe e outras propriedades divididas em trs sees, contendo as informaes conforme descritas a seguir:
Esteretipos podem ser escritos em estilo normal dentro de guillemets (<< >>) acima do nome da classe, e/ou um cone esteretipo pode ser colocando no canto superior direito do compartimento. Exemplo: <<type>>; O nome da classe aparece em seguida, centralizado e em negrito (nica informao obrigatria); Uma lista de strings indicando propriedades como atributos a nvel de classe e valores de etiqueta so mostrados abaixo do nome da classe, entre chaves. Exemplo: { verso = 1.2 }
Figura 4-4: Classe com informaes no compartimento de nome
Diagrama de Classes
Atributos
Ao definirmos atributos no informamos apenas seu nome ou tipo de dados. Podemos determinar, tambm, seu valor inicial, visibilidade e outras caractersticas. A nica informao obrigatria o prprio nome do atributo, mas conforme a modelagem refinada, outras caractersticas do atributo tornam-se importantes para o projeto. A sintaxe default para a definio de atributos :
visibilidade nome: tipo [ multiplicidade ordering] = valor-inicial {stringpropriedade}
A visibilidade pode ser representada pelas palavras-chaves public, protected, private ou package (ou por seus cones +, #, -, ~). Por exemplo:
private senha: String + tamanho: int
O tipo do atributo pode corresponder ao nome de uma classe ou ser um tipo dependente da linguagem de programao a ser adotada (String acima uma classe pois est com a primeira letra maiscula, j int um tipo pertencente a linguagem java). Na maior parte das vezes os atributos correspondero a tipos bsicos (int, float, boolean). Mas, tambm podemos associar tipos definidos pela linguagem de implementao, como por exemplo Date, Vector, String em Java. Outra forma de definir o tipo de um atributo associ-lo a tipos nobsicos, como uma classe. Por exemplo: um livro pertence a uma editora. Este relacionamento pode aparecer de duas formas: a primeira consiste numa associao entre as classes Livro e Editora; a segunda seria colocar um atributo editora do tipo classe Editora, na classe Livro. Esta ltima forma permite um mapeamento direto para as bases de dados, ou seja, mais usada na fase de projeto. Por exemplo:
editora: Editora
Diagrama de Classes
A multiplicidade pode ser omitida se corresponder a exatamente 1 (1..1). Em outros casos pode ser representada dentro de colchetes. Por exemplo:
telefones: String [0..5] filhos: Filhos [0..*]
O primeiro exemplo nos diz que uma determinada classe no tem valor para o atributo telefone ou tem at cinco valores. No segundo exemplo, temos que uma determinada classe tem de um a trs filhos. A propriedade ordering relevante se o limite superior da multiplicidade for superior a 1. Nesse caso, o atributo pode assumir os valores: unordered (valor tambm assumido quando a propriedade est ausente) ou ordered, respectivamente significando que no possuem ou que possuem ordenao. Por exemplo: vamos supor uma classe CorredorFormula1 que possua um atributo campeonatos que contenha a lista de temporadas (anos) nos quais ele foi campeo da Frmula1. Esse atributo poderia ser modelado da seguinte forma:
campeonatos: integer [0..* ordering]
que indicaria que um piloto pode nunca ter sido campeo ou j ter sido campeo de vrios (*) campeonatos, sendo que essa lista de anos deve aparecer ordenada cronologicamente. O valor-inicial determina o valor inicial do atributo no momento em que o objeto instanciado. Por exemplo:
salario: float = 1350.40 nota1: float = 0
A string-propriedade indica valores de propriedades que se aplicam ao atributo, como:

changeable: o valor do atributo pode ser modificado, sem restries. Corresponde ao default, se nenhuma propriedade for informada. addOnly: no caso de multiplicidades superiores a 1, indica que podem ser includas novas instncias, porm estas no podem ser alteradas ou excludas. frozen: aps o instanciamento do objeto, o valor do atributo no poder ser modificado.
Diagrama de Classes
Por exemplo:
identificacaoCliente: int {frozen } feriasGozadas: String [0..*] {addOnly}
No ltimo caso, o atributo feriasGozadas armazena a lista de perodos de frias j gozadas pelo funcionrio. Mas uma vez cadastrada essa informao, no deve ser possvel alter-la. O escopo (visto anteriormente) default corresponde a um atributo de instncia. Para representar um atributo de classe deve-se sublinhar o nome e o tipo do atributo. Por exemplo:
Figura 4-5: Classe com um atributo de classe
Temos, ainda, a representao de atributo derivado. Um atributo derivado aquele cujo valor computado a partir de outro(s) atributo(s). Por ser um valor sempre gerado no teria necessidade de aparecer em forma de atributo. Todavia sua exibio no diagrama feita com o intuito de melhorar o entendimento do modelo ou por propsitos de projeto. Indica-se graficamente que um atributo derivado inserindo-se uma barra (/) frente do nome do atributo. Veja por exemplo: a classe BoletimEscolar possui, entre outros, os atributos: nota1 e nota2. Sabemos que a mdia calculada pela diviso por dois do resultado da soma das notas 1 e 2. Ento, para obter a mdia, basta que tenhamos as notas 1 e 2. Todavia, deixar essa informao implcita pode levar a falhas no entendimento do modelo. Assim, modela-se o atributo mdia, mas determinando que sua atualizao feita por uma operao de clculo e no por uma atribuio, como ocorre com os outros atributos. Veja o exemplo na figura abaixo:
Diagrama de Classes
Figura 4-6: Classe com atributo derivado
Podemos especificar a forma de clculo de um atributo derivado, fazendo uso de uma nota ligada ao nome do atributo. Veja o exemplo abaixo:
Figura 4-7: Descrio para atributo derivado
Diagrama de Classes
Operaes
Da mesma forma que ocorre com os atributos, a modelagem das operaes no se limita a seu nome e parmetros. A nica informao obrigatria o prprio nome da operao, mas conforme a modelagem refinada, outras caractersticas da operao tornam-se importantes para o projeto. A sintaxe default para a definio de operaes :
visibilidade nome (lista-de-parmetros): tipo-de-retorno {string-propriedade}
A visibilidade pode ser representada pelas palavras-chaves public, protected private ou package (ou por seus cones +, #, -, ~). Por exemplo:
private obterSenha: String + modificarTamanho (t: int)
A lista-de-parmetros corresponde a uma lista de parmetros separada por vrgula, no qual cada parmetro deve obedecer a seguinte sintaxe: escopo-parmetro nome: tipo = valor-default O escopo-parmetro pode assumir os valores:

in: o parmetro apenas de entrada, no aceitando modificao. out: parmetro apenas de sada, no aceitando leitura. inout: parmetro de entrada e sada. Aceita leitura e modificao (default no caso do escopo ser omitido).
O tipo do parmetro tambm dependente da linguagem de programao. No caso da linguagem Java todo os parmetros que forem do tipo primitivo (exemplo: int, float, boolean, etc.) tero escopo in e todos aqueles que forem do tipo composto (exemplo: String, Date, Vector, etc.) sero do tipo inout. No h, no java, mapeamento para o escopo out. O valor-default indica um valor que ser considerado, caso nenhum valor seja passado para o parmetro. Por exemplo:
calcularMedia(tipo: TipoMedia = Aritmtica)
Diagrama de Classes
O tipo-de-retorno da operao dependente da linguagem de programao a ser adotada. Se nenhum retorno for especificado, estamos declarando uma operao que no possui retorno (estes conceitos so anlogos a funes e procedimentos). Existem linguagens com o Java que mesmo quando uma operao no possui retorno nos precisamos indicar o retorno como sendo void. O escopo default corresponde a uma operao de instncia. Para representar uma operao de classe deve-se sublinhar o nome e o tipo de retomo da operao. Por exemplo, a operao emitirListaFrequencia() possui escopo de classe:
Figura 4-8: Operaes com escopo de classe
A string-propriedade indica valores de propriedades que se aplicam operao. As semnticas de concorrncia (usadas em processos e threads) de uma operao so especificadas por uma propriedade no formato: {concorrncia = nome} O nome da concorrncia pode assumir os seguintes valores: sequential, guarded, concurrent. Vejamos, ento, as propriedades usadas:
query: indica que a execuo da operao no modifica o estado do objeto. Por exemplo: ao chamarmos a operao emitirListaFrequencia(), no realizamos qualquer alterao nos dados armazenados. Isto j no ocorre com a operao reajustarMensalidade que poderamos ter na classe. sequential: a chamada para um objeto precisa ocorrer imediatamente, de forma completa e perfeita. Se ocorrerem chamadas simultneas, a semntica e integridade do sistema no podem ser garantidas. guarded: mltiplas chamadas de threads concorrentes podem ocorrer simultaneamente para um objeto, mas somente permitida a uma delas iniciar. As outras so bloqueadas at que a execuo da primeira operao esteja completa. Essa responsabilidade pertence ao projetista do sistema, que deve assegurar que deadlocks no ocorram devido a blocos simultneos.
Diagrama de Classes
concurrent: mltiplas chamadas de threads concorrentes podem ocorrer simultaneamente para um objeto. Todas precisam ser executadas concorrentemente, mantendo correta sua semntica.
Existe uma diferena entre operao e mtodo que necessita ser relembrada. Uma operao corresponde definio conceitual do servio de uma classe, enquanto que o mtodo corresponde implementao da operao. Por default, uma operao considerada como no-abstrata, o que significa que obrigatoriamente deve ter um mtodo que a implemente. Para indicar que a classe no implementa a operao, esta deve ser marcada como {abstract} (iremos estudar mais adiante as classes abstratas) ou a assinatura da operao ser escrita em itlico. O corpo de um mtodo pode ser mostrado no diagrama de classes por meio de uma nota ligada operao. Especificaes formais, expressas em qualquer linguagem, devem ser colocadas entre chaves. Desta forma na nota iremos colocar o cdigo entre chaves. Perceba que este tipo de situao no comum, e na maioria dos diagramas voc no ir encontrar isto. Outro conceito importante quanto assinatura da operao, que composta do nome da operao, seus parmetros e o tipo de retorno (se existir). Quando no temos o interesse de demonstrar todas as operaes iremos colocar no final da regio das operaes na representao da classe trs pontinhos, mostrando que h mais operaes porm estas no esto sendo mostradas.
Diagrama de Classes
Relacionamentos
As classes dentro do contexto da modelagem de um sistema, na sua maioria, no trabalham sozinhas. Pelo contrrio, elas colaboram umas com as outras por meio de relacionamentos. No diagrama de classes temos os relacionamentos de associao, generalizao e dependncia. Como variao do relacionamento de associao, ainda possvel modelar relacionamentos de agregao e composio.
Diagrama de Classes
Associao
A associao um relacionamento que conecta duas (associao binria) ou mais classes (associao ternria ou de ordem-n), demonstrando a colaborao entre as instncias de classe. A associao binria conecta exatamente duas classes, sendo possvel a associao de uma classe com ela prpria. Por exemplo: uma empresa possui diversos funcionrios. Essa uma associao entre as classes Empresa e Funcionrio. De outra forma, um funcionrio tem um chefe que tambm um funcionrio, portanto temos uma associao da classe Funcionrio com ela prpria. Veja a figura abaixo:
Figura 4-9: Associao entre classes
A associao binaria representada grafcamente por uma linha slida que liga uma classe a outra ou uma classe a ela prpria. Em UML, a associao pode ser de trs tipos diferentes: associao simples; agregao por composio; agregao compartilhada. Visto que a construo de agregao pode ter diferentes significados dependendo da rea de aplicao, a UML fornece um significado mais preciso para duas dessas construes (associao e agregao por composio) e deixa a agregao compartilhada mais livremente definida no meio das outras. Mais adiante veremos os conceitos de agregao e composio. Uma associao pode conter adornos que melhoram, em alguns casos, a compreenso do modelo. Adornos so um tipo de esteritipos (Veja sobre os tipos de adorno no apndice). Todos esses adornos so opcionais e s devem ser usados quando sua funo for plenamente atendida, para no poluir visualmente o diagrama de classes. Eles devem ajudar a modelagem, no complic-la!
Diagrama de Classes
Nome da associao
mostrado prximo linha do relacionamento, todavia no se deve coloc-lo prximo s extremidades, pois estas posies pertencem aos nomes de papis. O nome da associao pode ser acompanhado de um pequeno tringulo preenchido indicando a direo na qual o nome deve ser lido. No exemplo abaixo o tringulo expressa a leitura da associao como "aluno cursa curso".
.
Figura 4-10: Associao com nome
Para associaes binrias, na sua maioria, no preciso nomear as associaes, pois elas j so auto-explicativas. O nome de associao mais usado quando possa haver dvidas sobre o tipo de associao ou nas associaes que envolvem uma nica classe. J nas associaes n-rias seu uso mais freqente. Veja na figura abaixo que usamos o nome pr-requisito para esclarecer o relacionamento: "Um curso pr-requisito de outro curso".
Figura4-11: Nome para associao
Diagrama de Classes
Multiplicidade
Colocada nas extremidades do caminho da associao, identifica o nmero de instncias de uma classe que pode se relacionar com outra. A mulplicidade especificada em uma extremidade determina que essa a quantidade de instncias da classe oposta que se relacionar na associao. Apesar de ser opcional, s deve ser omitida nas primeiras vises do diagrama. Uma vez que a modelagem avance, determinadas informaes so relevantes para o projeto. Uma delas a multiplicidade. Por exemplo: Vamos considerar um curso que possa ter no mximo 10 alunos. Para representar este relacionamento iremos colocar as seguintes multiplicidades na associao:
Figura 4-12: Multiplicidade na associao
Se fossemos ler o relacionamento acima diramos que um aluno pode estar matriculado em pelo menos um curso ou mais, no havendo limite de cursos. E ainda podemos dizer que um curso contm no mximo 10 alunos. Se a multiplicidade da associao for superior a um, ento os elementos relacionados podem ser ordenados ou no. Se no incluirmos nenhum adorno na associao, estaremos determinando que os elementos no so ordenados. Para determinar a ordenao deve-se incluir a string {ordered}. Essa declarao no especifica como a ordenao realizada ou mantida. Essa uma responsabilidade das operaes que agem sobre as instncias, demonstra somente que ordenado os objetos dentro da coleo que ir conter os mesmos. Geralmente essa especificao feita no projeto.
Diagrama de Classes
Papel (role)
Colocada nas extremidades do caminho da associao, indica o papel representado pela classe na associao (veja figura abaixo). Esse nome colocado na extremidade do caminho da associao, prximo classe a que se refere. De uma forma geral, o nome da classe j identifica o papel dela na associao, como por exemplo: Curso e Aluno. Todavia, quando temos classes que podem exercer vrios papis, a transparncia diminui. Assim, o nome do papel passa a ser importante.
Figura 4-13: Papel execido pela classe no relacionamento
Diagrama de Classes
Navegabilidade
Uma seta pode ser colocada na extremidade de uma associao indicando que a navegao determinada na direo para onde partiu a seta. As setas podem ser omitidas, colocadas em apenas uma das extremidades ou em ambas. A navegabilidade quando omitida indica que a mesma desconhecida ou bidirecional. Se temos a classe Aluno e Curso sem navegabilidade, podemos dizer que a partir de aluno podemos saber o curso dele, e por outro lado, a partir de um determinado curso podemos saber quais so os alunos matriculados. Se indicssemos uma navegabilidade direcionada ao aluno, estaramos dizendo que a partir de um aluno no deve ser implementada uma forma de saber seu curso. Claro que essa no uma situao perfeita, pois claro que precisamos saber o curso de um aluno. A "via de mo dupla" mais comum na grande maioria dos relacionamentos de associao. Veja a figura abaixo uma situao onde o curso sabe quais so os alunos que tem nele mas os alunos no sabem a quais cursos eles pertencem.
Figura4-14: Associao com navegabilidade
Sabemos que um aluno precisa saber em quais cursos ele est matriculado, ento no iremos em uamsituao real modelar com navegabilidade somente de Curso para Aluno, mas sim com navegabilidade para os dois lados. Quando a navegabilidade for para os dois lados, no precisamos colocar flexas nas extremidades da associao.
Diagrama de Classes
Herana/Generalizao
Vamos recordar dos conceitos de orientao a objetos que voc aprendeu no curso anterior: a generalizao entre classes envolve elementos mais genricos e outros mais especficos. O relacionamento de generalizao entre classes mostrado graficamente como uma seta fechada e vazada, com seu corpo slido, que parte da classe especfica em direo classe mais genrica. Veja abaixo a representao:
Figura 4-15: Primeira forma de relacionamento de Herana/Generalizao entre as classes
Diagrama de Classes
Outra forma de representar a Herana/Gerneralizao mostrada abaixo:
Figura 4-16: Segunda forma de relacionamento de Herana/Generalizao entre as classes
Restries predefinidas podem ser usadas para indicar restries semnticas entre as classes filhas. Essas restries so colocadas entre chaves, separadas por vrgula e posicionadas prximas seta do relacionamento. Uma forma alternativa consiste em colocar uma linha tracejada atravessando as linhas de relacionamento as quais se referem restrio. A restrio, ento, colocada prxima linha tracejada. Duas restries predefinidas para generalizao so:
Completo (complete) - todas as subclasses de uma superclasse j foram especificadas (dentro do contexto do sistema), mesmo que algumas tenham sido omitidas no diagrama. No permitida nenhuma especializao adicional. Por exemplo: Superclasse: Subclasses: Pessoa Fsica e Jurdica
No caso da superclasse Pessoa, todas as subclasses j foram definidas e se outras subclasses fossem possveis, no seriam permitidas suas incluses. Superclasse: Subclasses: Funcionrio Vendedor / Auxiliar Administrativo / Gerente
No foco do sistema, estes so os nicos funcionrios existentes na empresa.
Diagrama de Classes
Figura 4-17: Representao de uma associao completo
Incompleto (incomplete) - determina que nem todas as subclasses possveis foram especificadas no modelo, mas que essas incluses ainda so permitidas. Por exemplo:
Modelando os animais de um zoolgico. Mamfero e Ave no so os nicos animais, mas no momento a modelagem se restringiu a eles. Superclasse: Subclasses: Animal Mamfero / Ave
Supondo o contexto de um sistema acadmico, percebemos que outras subclasses da Classe Pessoa podem surgir no futuro, como: Funcionrio Administrativo, Monitor, etc. Superclasse: Subclasses: Pessoa Aluno e Professor
Diagrama de Classes
Figura 4-18: Incompleto
Para representar o polimorfismo, reescrevemos a operao na subclasse, ou seja, estamos redefinindo a operao. No exemplo da figura abaixo demonstramos o relacionamento entre as classes Funcionrio, Professor e Vendedor. A classe Funcionrio possui a operao calcularSalario() que realiza seu clculo a partir de um salrio base. No caso de Professor, a operao tambm existe, porm com um mtodo (implementao) diferente - o clculo feito sobre hora-aula. O mesmo ocorre com o vendedor que possui um salrio base mais uma comisso sobre as vendas. Desta forma, redefinimos as operaes, permitindo que os mtodos sejam implementados de maneiras diferentes.
Figura 4-19: Polimorfismo redefinindo uma operao
Diagrama de Classes
Dependncia
O relacionamento de dependncia entre duas classes indica que uma mudana na interface de uma delas pode causar mudanas na outra. Existem vrios fatores que levam dependncia entre classes. Vejamos alguns deles:
troca de mensagens entre classes (uma classe chama operaes de outra)
Por exemplo: a classe ProdutoDB uma classe que possui as operaes para manuteno de produtos em uma tabela de produtos no banco de dados. Ela necessita da classe Conexao para para fazer este acesso ao banco de forma que a mesma ir chamar os mtodos de abrir conexo, inserir, alterar, etc. que esto escritos em Conexao. Mudanas na interface dessa classe pode afetar a classe ProdutoDB. Assim, dizemos que a classe ProdutoDB dependente da classe Conexao.
Figura 4-20: Relacionamento de dependncia
uma classe tem como atributo outra classe
Por exemplo: uma classe Imvel possui o atributo Proprietrio que uma instncia da classe Proprietrio. Na assinatura de uma operao, uma classe aparece como parmetro.
Por exemplo: Na classe Gndola de um supermercado, vamos supor a existncia da operao ReporProduto (produto_reposicao: Produto). Essa operao recebe por parmetro uma instncia da classe Produto. No representamos sempre todas as dependncias, pois essas caractersticas citadas anteriormente j expressam o relacionamento. Representamos o relacionamento de dependncia apenas em casos que a mesma implcita.
Diagrama de Classes
Diagrama de Classes
Agregao
A agregao corresponde a um caso particular da associao (apenas associaes binrias), utilizada para expressar um relacionamento "todo-parte". A agregao representa uma propriedade fraca, pois uma classe "parte" pode estar contida em outras agregaes. Vamos primeiro discutir a agregao: quando definimos um relacionamento de associao, estabelecemos uma ligao entre as classes, mantendo a independncia de vida das mesmas. No contexto de um Sistema Acadmico, ao acabar com uma associao entre as classes Curso e Professor, as classes envolvidas continuam a ter vida prpria, com pleno significado. Eu pergunto "o que um curso dentro de um Sistema Acadmico?" ou pergunto "O que um professor dentro de um Sistema Acadmico?". As respostas provavelmente sero objetivas e explicativas. Mais do que isso, curso pode ser definido sem depender da existncia do professor e da mesma forma professor pode ser conceituado sem depender da existncia do curso. Agora, vamos pensar em uma pgina da Web. Uma pgina composta (ou no) de imagens. Uma imagem tambm parte de um diretrio do Site. E se eu perguntasse "O que uma imagem dentro de um Site?". Voc poderia comear respondendo " uma figura que ilustra uma pgina" ou " uma figura que serve de link em uma pgina", etc. Veja que a figura tem um significado que para ser completo est dependente de outro elemento. como um verbo transitivo direto ou indireto. Se eu digo "voc acorda", estou me referindo a um verbo intransitivo (que no pede complemento). Quem acorda, acorda e ponto final. J se digo: "eu chamo", fica faltando alguma coisa. Quem chama, chama algum. Paralelamente, uma imagem uma imagem de algum (ou algo). A pgina Web representa o todo enquanto que a imagem representa a parte. Portanto, nesse caso, podemos modelar o relacionamento entre Pgina Web e Imagem como uma agregao. Lembrem-se sempre de que o contexto interfere diretamente no tipo de relacionamento. Uma imagem no far sempre parte de uma agregao depende do contexto no qual ela est envolvida. A representao grfica da agregao consiste em se colocar um diamante aberto junto classe agregadora.
Diagrama de Classes
Figura 4-21: Relacionamento de agregao
O relacionamento de agregao mostra que um objeto pode estar sendo referenciado por dois ou mais outros objetos. Na figura acima imagine que um objeto da classe PaginaWeb morra (no seja mais utilizado e pode ser coletado da memria pelos gerenciadores de memria das linguagens), desta forma o objeto imagem deve continuar l e no ser removido junto com a PaginaWeb.
Diagrama de Classes
Composio
A composio (ou agregao por composio) uma variao mais poderosa da agregao. Passamos a interpretar o relacionamento como um objeto composto de partes. A diferena consiste no fato de que a classe parte pertence s e somente s classe todo, em um determinado momento, no podendo fazer parte de outro relacionamento de composio. A classe composta responsvel pela criao e destruio de suas partes. Entende-se, assim, que uma vez que a classe composta deixe de existir, todas as suas partes morrem juntas. Observe que justamento o contrrio do relacionamenro de agregao mostrado acima onde as partes continuam a existir. Ao definirmos uma classe como parte de uma composio, indicamos que no relacionamento essa classe perdeu sua identidade, pois parte incorporada da outra classe. Seguindo o exemplo do relacionamento de agregao, vamos pensar em um frame que representa uma tela de uma aplicao. Imagine que dentro desta tela temos um boto de pesquisar, perceba que este boto s estar dentro desta janela no ir estar presente em outras janelas (pelo menos o mesmo boto). Quando a janela for fechada (morrer) o boto ser tambm morto, ou seja ir junto com a janela por fazer parte da estrutura da mesma. Temos, portanto, uma agregao mais forte: uma composio. Graficamente, representada por um diamante preenchido junto classe composta.
Figura 4-22: Relacionamento de composio
Diagrama de Classes
Pacotes de classes e colaboraes no sistema
Uma das questes mais antigas nas metodologias de software : como voc quebra um sistema grande em sistemas pequenos? Fazemos esta pergunta porque medida que os sistemas crescem, se torna difcil compreend-los, bem como as mudanas que neles fazemos. Mtodos estruturados usam decomposio funcional, no qual todo o sistema foi mapeado como uma funo e quebrado em sub-subfunes, que foram posteriormente quebradas em sub-subfunes e assim por diante. As funes eram como os casos de uso em um sistema orientado a objeto no qual as funes representavam algo que o sistema fazia como um todo. Aquela era uma poca em que o processo e os dados eram separados. Ento, alm da decomposio funcional, havia tambm a estrutura de dados. Isso assumiria um segundo plano, embora algumas tcnicas de Engenharia de Informao agrupassem registros de dados em reas de interesse e produzissem matrizes para mostrar como as funes e os registros de dados interagiam. E deste ponto de vista que vemos a maior mudana que a orientao a objetos tem trazido. A separao entre processo e dados j era, a decomposio funcional j era, mas a velha questo ainda continua. Uma idia agrupar as classes em unidades de nvel mais alto. Esta idia, aplicada de forma bastante livre, aparece em muitas metodologias orientadas a objetos. Em UML, este mecanismo de agrupamento chamado pacote (package).
Diagrama de Classes
Pacotes
A idia de um pacote pode ser aplicada a qualquer elemento do modelo, no somente a classes. Sem alguma heurstica para agrupar as classes, o agrupamento se torna arbitrrio. A dependncia a heurstica que considero mais til e mais enfatizada em UML. Usamos o termo diagrama de pacotes para um diagrama que mostra pacotes de classes e as dependncias entre eles. De modo restrito, um diagrama de pacotes simplesmente um diagrama de classes que mostra apenas pacotes e dependncias. Utilizamos muito estes diagramas, por isso chamamos de diagramas de pacotes, mas voc deve lembrar que este um termo no oficia, no um nome oficial de diagramas da UML . Existe dependncia entre dois elementos se mudanas na definio de um elemento possam causar mudanas ao outro. Nas classes, as dependncias existem por vrias razes: uma classe manda uma mensagem para outra; uma classe tem outra como parte de seus dados; uma classe menciona uma outra como um parmetro para uma operao. Se uma classe muda a sua interface, qualquer mensagem que ela mande pode no ser mais vlida. De forma ideal, apenas mudanas na interface de uma classe devem afetar qualquer outra. A arte de projetar em grande escala envolve minimizao de dependncias; desta forma, os efeitos da mudana so reduzidos, e o sistema requer menos esforo para mudar. UML tem muitas variedades de dependncia, cada uma com esteretipos e semntica particulares. mais fcil comear com a dependncia noestereotipada e usar as dependncias mais particulares somente se necessrio.
Diagrama de Classes
Na figura abaixo voc pode ver alguns pacotes e suas dependncias.
Figura 4-23: Diagrama de pacotes
H dependncia entre dois pacotes se houver qualquer dependncia entre quaisquer duas classes nos pacotes. Por exemplo, veja que o pacote Gerenciador de Conexes com Banco de Dados um pacote muito utilizado pelos demais, todos ous outrs pacotes dependem dele. Desta forma uma alterao em classes deste pacote deve ser feito com muito cuidado pois pode projudicar as classes nos demais pacotes. possvel tambm representar um relacionamento de generalizao/herana entre os pacotes. Este tipo de relacionamento
Diagrama de Classes
normalmente utilizado quando temos um conjunto de classes em um pacote que so abstratas e devem ser utilizadas para que possamos criar outras classes a fim de as mesmas executarem algo. Imagine o exemplo dado anteriormente onde tnhamos um pacote com classes para conectar com o banco de dados, todas as classes que estavam naque pacote eram abrastratas e ns precisamos espcializar as mesmas e criar classes para fazer aquilo que ns de fato queremos fazer: conectar com oracle, postgreSQl, etc. Veja abaixo ento como ficaria esta representao:
Figura 4-24: Diagrama de pacotes com generalizao
Diagrama de Classes
Colaboraes
Alm de conter classes, um pacote pode conter colaboraes. Uma colaborao um nome dado interao entre duas ou mais classes. Tipicamente, isso uma interao, como descrito no diagrama de interao (este diagrama ser vistomais adiante no curso). Vejamos uma pequena colaborao abaixo:
Figura 4-25: Colaborao entre classe para agendar um curso
Esta colaborao pode mostrar a implementao de uma operao ou a realizao de um caso de uso. Voc pode modelar a colaborao antes de decidir que operao a chama. Uma colaborao pode ser descrita com mais de um diagrama de interao, com cada um mostrando um caminho diferente. Voc tambm pode mostrar um diagrama de classes para mostrar as classes que participam na colaborao conforme a figura acima.
Diagrama de Classes
Quando Utilizar Diagramas de Pacotes e Colaboraes

Os pacotes so ferramentas vitais para projetos grandes. Utilize pacotes sempre que um diagrama de classes que compreenda todo o sistema no for mais legvel numa nica folha de papel tamanho A4. Os pacotes so particularmente teis para testes. Embora normalmente se escreve alguns testes em um fundamento de classe-por-classe, prefira fazer teste de unidade em um fundamento de pacote-por-pacote. Cada pacote deve ter uma ou mais classes de teste que testem o comportamento do pacote. Considere colaboraes teis sempre que voc quer se referir a uma interao particular ou mostrar uma pequena parte do diagrama de classes focando um objetivo final para uma relao entre classes.
Diagrama de Classes
Multiplicidade
Indica uma faixa de cardinalidade permitida a um elemento, isto , a quantidade de instncias possveis em um relacionamento. Por exemplo: Numa classe Pessoa com o atributo cnjuge podemos afirmar (na nossa atual legislao) que sua multiplicidade de no mnimo zero e no mximo um cnjuge (levando em conta o cnjuge atual). Considerando uma classe Curso que se relacione com uma classe Aluno, podemos afirmar que para cada instncia de Curso h um relacionamento com no mnimo zero e no mximo vrios alunos; e para cada instncia de Aluno h um relacionamento com no mnimo zero (a-luno est com a matrcula trancada) e no mximo vrios cursos.
A multiplicidade consiste num subconjunto de um conjunto infinito de nmeros inteiros no-negativos. A especificao da multiplicidade mostrada como uma string compreendida numa seqncia de intervalos inteiros separados por vrgula, no qual um intervalo representa uma faixa de inteiros no formato: limite-inferior.. limite-superior Se a multiplicidade contiver um asterisco (*), significa que temos uma faixa infinita de nmeros inteiros no-negativos. equivalente a 0..* (zero ou mais). As multiplicidades mais comuns so: 0..1 (valor opcional) 1 ou 1..1 (exatamente um) * ou 0..* (qualquer valor inteiro no-negativo) 1..* (qualquer valor inteiro positivo)
Exemplos de multiplicidades: "1", "*", "0..1", "1..*", "1..5", "3, 5..7, 10..12" Algumas normas de estilo devem ser usadas para multiplicidade, como: os intervalos devem ser mostrados em ordem crescente. Exemplo: Adequado: 2..5, 8, 10..15 Inadequado: 10..15, 2..5, 8
Diagrama de Classes
dois intervalos contguos devem ser combinados num intervalo simples. Exemplo: Adequado: 3..8 Inadequado: 3..5, 6..8
Figura4-26: Multiplicidade entre classes
Diagrama de Classes
Escopo
Vamos supor o objeto Funcionrio com o atributo salrio. Agora vejamos a seguinte situao: na empresa fictcia XYZ Ltda, instanciamos dois objetos a partir de uma classe Funcionrio identificando-os como objetoP e objetoA, os quais representaro os funcionrios Pedro e Augusto, respectivamente. Pedro recebe R$ 500,00 de salrio enquanto que Augusto recebe R$ 2000,00. Se quisermos saber os salrios desses funcionrios, podemos nos referenciar da seguinte forma: objetoP.salario e objetoA.salario Veja que dependemos da individualidade do objeto para obtermos os salrios corretos. Estamos diante do conceito de escopo de instncia, que tambm pode ocorrer com as operaes. Vamos levar em conta a operao gerarContraCheque. O resultado dessa operao ser diferente para as seguintes chamadas: objetoP. gerarContraCheque() e objetoA.gerarContraCheque() A diferena ser dada em funo dos objetos terem salrios diferentes, um possui R$ 500,00 e o outro R$ 2000,00. O contra-cheque gerado na primeira chamada apresentar os dados funcionais do funcionrio Pedro, incluindo a demonstrao de seus proventos e descontos. J na segunda chamada, o contra-cheque apresentar os dados funcionais e demonstrao de proventos e descontos do funcionrio Augusto. Isso significa que, ao definirmos o escopo de um atributo ou operao como sendo de instncia, estamos dizendo que eles esto ligados identidade do objeto, ou seja, pertencero ao objeto. Agora vamos pensar numa outra situao: vamos supor que os funcionrios dessa empresa no possam ganhar menos que um determinado piso salarial, independente de seu cargo. Nesse caso, eu pergunto: piso salarial um atributo que modifica seu valor se o funcionrio for o Pedro, Augusto ou qualquer outro da empresa? No. Isso significa dizer que esse atributo no est ligado identidade do objeto e sim coleo (conjunto) de funcionrios da empresa. Est ligado classe Funcionrio. Dessa forma, supondo que a classe Funcionario seja identificada como Funcionario, a referncia a esse atributo seria feita da seguinte forma: Funcionario.pisoSalarial
Diagrama de Classes
Obteramos o mesmo resultado, acessando objetoP.pisoSalarial ou objetoA.pisoSalarial. A diferena que no primeiro caso, no preciso instanciar um objeto. Imaginem criar um objeto s para saber o valor de um atributo pblico! O mesmo ocorreria com uma operao chamada emitirFolhaPagamento. O resultado dessa operao a folha de pagamento mensal contendo todos os funcionrios. Desta forma no importa cham-la a partir de um nico funcionrio, pois seu processamento ser sempre sobre o conjunto de funcionrios, independente de quem ou quantos sejam. Funcionario.emitirFolhaPagamento() Estes dois ltimos casos ilustram o conceito de escopo de classe. Assim comum dizermos que estamos definindo um atributo de classe ou uma operao de classe. A UML determina que o escopo de classe seja representado sublinhandose o elemento. Voc pode encontrar representaes diferentes em algumas ferramentas, como por exemplo colocar frente do elemento, um sinal de dlar ($) - notao usada em verses mais antigas.
Figura 4-27: Operaes com escopo de classe
Diagrama de Classes
Classes de Associao
Classes de associao permitem que voc acrescente atributos, operaes e outras caractersticas s associaes, como mostrado na figura abaixo.
Figura 4-28: Representao de uma classe de associao
Voc pode ver pelo diagrama que uma Pessoa pode trabalhar para uma nica Companhia. Suponhamos que necessitamos manter informao sobre o perodo de tempo que cada funcionrio trabalha para cada Companhia. Podemos fazer isso adicionando o atributo dataInicio associao. Poderamos acrescentar este atributo classe Pessoa. Mas realmente um fato sobre a relao da Pessoa com a companhia, que mudar caso a pessoa mude de empregador. A figura abaixo mostra uma outra maneira para representar esta informao: faa de Emprego uma classe plena (observe como as multiplicidades foram movidas correspondentemente). Neste caso, cada uma das classes na associao original tem uma ponta de associao de valor nico em relao classe Emprego. A ponta "Empregador" agora derivada, embora eu no tenha que mostr-lo.
Diagrama de Classes
Figura 4-29: Representao de uma classe de associao com emprego sendo classe plena
No diagrama acima podemos ver que uma pessoa pode trabalhar em uma ou nenhuma empresa, sendo que esta empresa possui vrias pessoas trabalhando nela. A ponta empregador mostra que na pessoa teremos um atributo empregador quando houver uma associao de pessoa tambm com Empredo. Pereba que a empresa esta ligada a um emprego e este emprego (que nico) pode ser exercido por uma pessoa, que por sua vez pode tambm no estar liagada a emprego nenhum sendo que no estar ento ligada tambm a empresa.
Diagrama de Classes
Associao Xor (ou exclusiva)
Uma restrio Xor (ou exclusiva) indica que, dentre as vrias associaes envolvidas nessa restrio, somente uma delas pode ocorrer por vez. Por exemplo: suponha a classe Contrato que se relacione com a Classe Contratante. Podemos ter um contratante do tipo Pessoa Fsica, assim como um contratante do tipo Pessoa Jurdica, gerando duas associaes: Classe Contrato com a classe Pessoa Fsica Classe Contrato com a classe Pessoa Jurdica
Entretanto, no podemos permitir que ambas as associaes ocorram ao mesmo tempo. No seria possvel num mesmo contrato termos um contratante que fosse ao mesmo tempo Pessoas Fsica e Jurdica. Representamos graficamente esta restrio por meio de uma linha tracejada ligando as associaes envolvidas. Essa linha identificada com a string {xor}. Veja a figura abaixo que ilustra esta associao:
Figura 4-30: Representao de {xor}
Diagrama de Classes
Esteretipo
Um esteretipo um mecanismo de extensibilidade da UML que representa uma subclasse de um elemento j existente com o mesmo formato porm com objetivos diferentes e bem definidos. Geralmente, quando necessitamos distinguir um uso especfico para um elemento, utilizamos esteretipos. O esteretipo possui a mesma representao grfica do elemento, sendo colocado seu nome entre guillemets (<<>>) acima ou em frente do nome do elemento que est sendo descrito pelo esteretipo. Se mltiplos esteretipos so definidos para o mesmo elemento de modelo, ento, eles so colocados verticalmente um abaixo do outro. Por exemplo: <<utility>> Um outro exemplo disso a interface. A interface de UML uma classe que tem somente operaes pblicas sem mtodos nem atributos. Isso corresponde a interfaces em Java, COM e CORBA. Uma vez que este um tipo especial de classe, ele definido como um esteretipo de classe. Utilizamos tambm esteretipos para classes abstratas. Veja abaixo as figuras:
Figura 4-31: Utilizao de esteretipos em classes
Notas
um smbolo grfico contendo informao textual. utilizado para especificar vrios tipos de informaes sobre os modelos, como: restries, comentrios, corpos de mtodos e valores de etiquetas. Veja abaixo a presentao de uma nota:
Diagrama de Classes
Figura 4-32: Representao de uma nota
As notas so os elementos mais utilizados para melhorar e enriquecer os seus diagramas com informaes. Elas podem ser utilizadas em qualquer diagrama e iro nos ajudar a explicar partes dos diagramas que os elementos do mesmo utilizados pela UML no conseguem deixar claro.
Diagrama de Classes
Interfaces e Classes Abstratas
Uma das grandes qualidades do desenvolvimento orientado a objetos que voc pode variar as interfaces de classes, independentemente da implantao. Muito da fora do desenvolvimento orientado a objetos vem desta propriedade. Entretanto, poucas pessoas fazem bom uso disso. As linguagens de programao usam uma construo nica, a classe, que contm tanto a interface quanto a implementao. Quando voc faz subclassificao, voc herda as duas. Raramente, faz-se uso de interface como uma construo separada, o que uma pena. Uma interface pura, como em Java, uma classe sem implementao e, portanto, tem declaraes de operaes mas no corpos de mtodos e no tem campos. As interfaces so, freqentemente, declaradas atravs de classes abstratas. Tais classes podem oferecer alguma implementao, mas, com freqncia, elas so usadas basicamente para declarar uma interface. O ponto que a subclassificao - ou outro mecanismo- prover a implementao, mas os clientes nunca vero a implementao, somente a interface. O editor de texto representado na figura abaixo um exemplo tpico disso. Para permitir que o editor seja independente da plataforma, definimos uma classe Janela abstrata independente de plataforma. Esta classe no tem corpos de mtodos; ela apenas define uma interface para utilizao pelo editor de texto. Subclasses especficas de plataforma podem ser usadas conforme o desejado.
Diagrama de Classes
Figura 4-33: Representao de uma classe abstrata
Se voc tem uma classe ou um mtodo abstrato, a conveno de UML de colocar em itlico o nome do item abstrato. Voc tambm pode usar a restrio {abstract}. Uso {abstract} em quadros brancos porque no posso escrever um texto em itlico. Os editores permitem usar itlico, mas acredito que o uso do esteretipo deixa mais claro. Classes abstratas podem possuir operaes com implementao, a pesar de se diferenciarem por terem operaes sem implementao. Muitas vezes consideramos a classe abstrata como uma classe inacabada e que que no pode ser acabada porque a implementao do que falta dependente de algum, como por exemplo na figura acima, dependente de uma plataforma. Normalmente as classes abstratas representam estruturas das quais no iremos criar objetos mas sim serviro de moldes para a padronizao de outras classes, as classes filhas. Uma interface muito parecida com uma classe abstrata, porm ela se difere por ser uma estrutura voltada para a representao de comportamentos, onde os comportamentos sero as operaes. Uma interface no possui operaes com implementao, elas tem somente a assinatura das mesmas declaradas. A interface ser implementada por classes e a relao entre elas ser conhecida como realizao. Veja abaixo a representao de uma interface com algumas operaes:
Diagrama de Classes
Figura 4-34: Representao de uma interface
Abaixo temos uma JanelaWindows que est implementando o comportamento de uma interface WindowListener. Este interface define todos os comportamentos que uma janela pode ter. Se a JanelaWindows implementar estes comportamentos ento ser obrigado termos na mesma todas as operaes descritas na interface. A classe que implementar esta interface poder tratar aes que acontecem em uma janela, ou seja os comportamentos da interface WindowListener.
Figura 4-35: Relacionamento de realizao entre uma classe e uma interface
Diagrama de Classes
Objetos de Referncia e Objetos de Valor
Uma das coisas comuns dita sobre objetos que eles tm identidade. Isso verdade, mas no to simples assim. Na prtica, voc percebe que a identidade importante para objetos de referncia, mas no to importante para objetos de valor.
Diagrama de Classes
Objetos de referncia
So coisas como Clientes, geralmente as classes das linguagens. Aqui, a identidade muito importante, porque voc geralmente quer que somente um objeto de software designe um cliente no mundo real. Um objeto que faz referncia a um objeto-Cliente far isso atravs de uma referncia ou ponteiro; todos os objetos que se referem a este Cliente vo se referir ao mesmo objeto de software. Desta forma, modificaes em um Cliente ficam disponveis para todos os usurios do Cliente. Se voc tem duas referncias para um Cliente e quer ver se so as mesmas, voc, normalmente, compara suas identidades. Cpias podem ser proibidas; se so permitidas, elas tendem a ser feitas raramente, talvez para propsitos de arquivamento ou para replicao na rede. Se cpias forem feitas, voc necessita decidir como sincronizar as atualizaes do objeto.
Diagrama de Classes
Objeto de Valor
So coisas como datas, ou tipos primitivos das linguagens. Voc tem, geralmente, mltiplos objetos de valor representando o mesmo objeto do mundo real. Por exemplo, normal ter centenas de objetos que designam 29Jul-2004. Estas so todas cpias intercambiveis. Novas datas so freqentemente criadas e destrudas. Se voc tem duas datas e quer ver se elas so a mesma, voc no examina as suas identidades, mas sim os valores que elas armazenam. Isso significa, geralmente, que voc tem que escrever um operador de teste de igualdade, que para datas far testes no ano, ms e dia (ou qualquer outra forma de representao interna). Normalmente, cada objeto que faz referncia a 29-Jul-2004 tem o seu prprio objeto data dedicado a isso, mas voc tambm pode compartilhar datas. Objetos de valor devem ser imutveis (congelados; veja "Frozen" mais adiante). Em outras palavras, voc no deve ser capaz de pegar um objeto data de 29-Jul-2004 e mud-lo para ser 31-Jul-2004. Em vez disso, voc deve criar um novo objeto 31-Jul-2004 e lig-lo ao primeiro objeto. A razo que se a data fosse compartilhada, voc atualizaria a data de outro objeto de um modo imprevisvel. Antigamente, a diferena entre objetos de referncia e objetos de valor era mais clara. Objetos de valor eram os valores bsicos (built-in) de um sistema de tipos. Agora, voc pode estender o sistema de tipos com suas prprias classes, por isso esta questo requer mais reflexo. Em UML, atributos so geralmente usados para objetos de valor e associaes so usadas para objetos de referncia. Voc tambm pode usar composio para objetos de valor. A distino entre objetos de valor e de referncia seja til para modelos conceituais. Isso pode causar confuso com multiplicidades. Se representar uma ligao para um objeto de valor com uma associao, normalmente marcamos a multiplicidade da ponta do usurio de um dado valor como "*", a no ser que exista uma regra de unicidade, tal como um nmero de seqncia.
Diagrama de Classes
Colees para Pontas de Associaes de Valores Mltiplos

Uma ponta de valor mltiplo uma cujo limite superior de multiplicidade maior que 1 (por exemplo, "*"). Uma conveno usual que pontas de valores mltiplos sejam consideradas como conjuntos. No h ordem para os objetos-alvo, e nenhum objeto aparece no conjunto mais de uma vez. Entretanto, voc pode mudar estas suposies anexando uma restrio. A restrio {ordered} implica que h uma seqncia de ordem para os objetos-alvo - isto , objetos-alvo formam uma lista. Eles podem aparecer somente uma vez na lista. Uso a restrio {bag} para indicar que objetos-alvo podem aparecer mais de uma vez, mas sem ordem. Tambm a restrio {hierarchy} para indicar que eles formam uma hierarquia.
Diagrama de Classes
Frozen
Frozen (Congelado) uma restrio que UML define como aplicvel a um atributo ou a uma ponta de associao, mas considero-o til tambm para classes. Em uma ponta de associao ou atributo, Frozen indica que o valor daquela ponta de associao ou atributo no pode mudar durante o tempo de vida do objeto-fonte. O valor deve ser estabelecido na criao do objeto e no pode mudar jamais. O valor inicial pode ser nulo. Certamente, se isso verdade quando o objeto for construdo, isso ser verdade durante toda a vida do objeto. Isso indica que existe um argumento para este valor em um construtor e no existe operao que atualize este valor. Quando aplicado a uma classe, congelado indica que todas as pontas de associao e todos os atributos associados com aquela classe so congelados. Congelado no o mesmo que Read-Only (somente-de-leitura). Read-Only indica que um valor no pode ser mudado diretamente, mas pode mudar devido a uma mudana em algum outro valor. Por exemplo, se uma pessoa tem uma data de nascimento e uma idade, a idade pode ser somente-de-leitura, mas no pode ser congelada. Frozen quando colocado na assinatura de uma classe indica que esta classe no pode ter filhos, ou seja no poder ser classe pai em uma relao de generalizao/herana. J quando colocamos frozen em uma assinatura de uma operao estamos dizendo que esta operao no poder ser sobreescrita, ou seja ela no poder ser redefinida na classe filha da classe que a contm.
Diagrama de Classes
Visibilidade
A visibilidade um daqueles assuntos que simples em princpio, mas tem complexas sutilezas. A idia bsica que qualquer classe tem elementos pblicos e elementos particulares. Os elementos pblicos podem ser usados por qualquer outra classe; os elementos particulares podem ser usados somente pela classe proprietria. Entretanto, cada linguagem tem suas prprias regras. Embora muitas linguagens usem termos como public ("pblico"), private ("particular") e protected ("protegido"), eles tm significados diferentes em linguagens diferentes. Estas diferenas so pequenas, mas causam confuso, principalmente para alguns de ns que utilizamos mais de uma linguagem. UML tenta abordar o tema sem entrar em terrvel confuso. Essencialmente, dentro de UML, voc pode rotular qualquer atributo ou operao com um indicador de visibilidade. Voc pode usar qualquer marcador que quiser, e seu significado dependente da linguagem. Entretanto, UML fornece quatro (bastante difceis de lembrar) abreviaes para visibilidade; + (pblico), - (privado), # (protegido) e ~ (pacote) Para compreender realmente algumas diferenas comuns que existem entre modelos, voc necessita compreender os enfoques que linguagens diferentes usam em relao visibilidade. Com C++, que a base para o usopadro de UML, temos os trs primeiros mostrados abaixo, porm a maioria das linguagens possui o pacote tambm.

PUBLIC visvel em qualquer lugar no programa e pode ser acessado por qualquer objeto no sistema. PRIVADO pode ser usado somente pela classe que o define. PROTEGIDO pode ser usado somente por (a) uma classe que o define ou (b) uma subclasse daquela classe. PACOTE pode ser utilizado pela classe que o define e por outras classes que estivrem no mesmo pacote.
Considere uma classe Cliente que tem uma subclasse Cliente PessoaFsica. Considere tambm o objeto Martin, que uma instncia de Cliente Pessoa-Fsica. Martin pode usar qualquer membro pblico de qualquer objeto no sistema. Martin tambm pode usar qualquer membro particular da classe Cliente Pessoa-Fsica. Martin no pode usar membros particulares definidos dentro de Clientes; pode, entretanto, usar membros protegidos de Cliente e membros protegidos de Cliente Pessoa-Fsica. Agora, examinemos Smalltalk. Dentro desta linguagem, todas as variveis de instncia so particulares, e todas as operaes so pblicas. Entretanto, particular no significa a mesma coisa em Smalltalk que em C++. Em um
Diagrama de Classes
sistema Smalltalk, Martin pode acessar qualquer varivel de instncia dentro do seu prprio objeto se aquela varivel de instncia estiver definida dentro de Cliente ou Cliente Pessoa-Fsica. Ento, de certa forma, particular em Smalltalk semelhante a protegido em C++. Ah, mas isso seria simples demais... Vamos voltar para C++. Digamos que eu tenha uma outra instncia de Cliente Pessoa-Fsica chamada Kendall. Kendall pode acessar qualquer membro de Martin que tenha sido definido como parte cia classe Cliente Pessoa-Fsica, seja pblico, particular ou protegido. Kendall tambm pode acessar qualquer membro pblico ou protegido de Martin que tenha sido definido em Cliente. Entretanto, em Smalltalk, Kendall no pode acessar as variveis de instncia particulares de Martin - somente as operaes pblicas de Martin. Em C++, voc pode acessar membros de outros objetos de sua prpria classe da mesma forma que acessa os seus prprios membros. Em Smalltalk, no faz diferena se um outro objeto da mesma classe ou no; voc pode somente acessar as partes pblicas de um outro objeto. Java semelhante a C++; ela oferece acesso livre a membros de outros objetos de uma mesma classe. Ela tambm acrescenta um novo nvel de visibilidade, chamado pacote. Um membro com visibilidade de package (pacote) pode ser acessado somente por instncias de outras classes dentro do mesmo pacote. Permanecendo em nosso tema, para garantir que as coisas no so to simples, Java redefine levemente visibilidade protegida. Em Java, um membro protegido pode ser acessado por subclasses, mas tambm por qualquer outra classe do mesmo pacote da classe proprietria. Isso significa que, em Java, protegido mais pblico que pacote. Java tambm permite que classes sejam marcadas: como pblicas ou de pacote. Os membros pblicos de uma classe pblica podem ser usados por qualquer classe que importa o pacote em que a classe pertence. Uma classe de pacote pode ser usada somente por outras classes do mesmo pacote. C++ acrescenta um penduricalho adicional. Um mtodo ou classe de C++ pode se tornar um amigo ("friend") de uma classe. Um amigo tem acesso completo a todos os membros de uma classe - portanto, a frase (de mau-gosto) "em C++, amigos tocam as partes particulares dos outros". Quando voc estiver usando visibilidade, use as regras da linguagem qual est trabalhando. Quando voc est examinando um modelo UML qualquer outra origem, seja cuidadoso com o significado dos marcadores visibilidade, e esteja ciente de como estes significados podem mudar linguagem para linguagem. na de de de
As visibilidades geralmente mudam quando voc comea a trabalhar com cdigo. Ento, no fique amarrado a elas no incio do projeto. Veja abaixo uma classe com a visibilidade para seus atributos:
Diagrama de Classes
Figura4-36: Representao da visibilidade para atributos de uma classe
Na Orientao a Objetos lembre-se que o recomendado ter os atributos de uma classe sempre privados, desta forma teramos sempre o sinal de - na frente de cada um doa atributos.
Diagrama de Classes
Quando Utilizar Diagramas de Classes
Diagramas de classes so a base de quase todas as metodologias OO, portanto voc ir utiliz-los o tempo todo. Este captulo cobre os conceitos bsicos; neste captulo do curso discutimos muitos conceitos avanados. O problema com diagramas de classes que eles so muito ricos e podem ser complexos de se usar. Voc tem aqui algumas dicas.
No tente utilizar todas as notaes que voc dispe. Comece com os recursos mais simples: classes, associaes, atributos, generalizao e restries. Introduza outras notaes mais avanadas vistas neste captulo somente se necessitar. Ajuste a perspectiva na qual voc est desenhando os modelos para o estgio do projeto.
1- Se voc estiver fazendo anlise, desenhe modelos conceituais. 2- Quando voc estiver trabalhando com software, concentre-se nos modelos de especificao. 3- Desenhe modelos de implementao somente quando voc estiver ilustrando uma particular tcnica de implementao. No desenhe modelos para tudo; em vez disso, concentre-se nas reas principais. melhor ter poucos diagramas que voc usa e mantm atualizados do que ter muitos modelos esquecidos e obsoletos.
O maior perigo com diagrama de classes que voc pode ficar detido em detalhes de implementao muito facilmente. Para combater isso, concentre-se nas perspectivas conceituais e de especificao.
Diagrama de Classes
Exerccios
Utilizando a ferramenta de modelagem de diagramas UML faa: 1 Para o texto descritivo do sistema apresentado no exerccio do captulo 1 (captulo sobre use cases) elabore um diagrama de classes que possa representar as classes envolvidas no sistema mostrando as suas assiciaes. Tente utilizar ao mximo a notao para representao dos elementos do diagrama de classes estudada no captulo. 2 Reflita e discuta com o instrutor e colegas quais so os benefcios da construo de um diagrama de classes para a modelagem de sistemas orientados a objeto.
Diagrama de Classes
Espao para anotaes
5. Diagrama de Estados
Diagrama de Estados
Objetivos
Aprender o que e como pode ser utilizado diagramas de estados Conhecer os elementos que fazem parte deste tipo de diagrama Saber quando devemos utilizar diagramas de classes
Diagrama de Estados
O que um Diagrama de Estados?
O diagrama de grfico de estados descreve o comportamento de objetos como reao a eventos discretos (como por exemplo sinais e invocao de operaes), por meio de seqncias de estados e aes que ocorrem durante a sua vida. Um diagrama de grfico de estados tem por objetivo mostrar uma mquina de estado. Uma mquina de estado consiste num comportamento que especifica a seqncia de estados que um objeto atravessa durante sua vida, em resposta a eventos, junto com suas responsabilidades e aes.
Diagrama de Estados
Estado
Um estado uma condio ou situao existente na vida de um objeto durante a qual o estado satisfaz alguma condio, executa alguma atividade ou espera por algum evento. Um estado representado graficamente como um retngulo com cantos arredondados. O nome do estado colocado no centro do mesmo, caso ele no esteja subdividido em compartimentos. Veja na figura abaixo a representao de um estado:
Figura 5-1: Representao de estados
Um estado pode ser opcionalmente subdividido em compartimentos separados cada qual por uma linha horizontal. So eles:
Compartimento de nome: armazena o nome do estado, como uma string. possvel desenharmos estados sem nomes. Estes so estados annimos, distintos em si. Compartimento de transies internas: este compartimento armazena uma lista de aes ou atividades internas que so executadas enquanto o objeto se apresenta no estado em foco.
Essas transies internas so representadas por expresses que identificam as circunstncias sobre as quais a ao associada ser invocada. A ao associada ao tipo de transio externa pode fazer uso de quaisquer atributos e links, que esto no escopo do objeto proprietrio. Uma transio interna no modifica o estado do objeto. Por exemplo: quando um objeto OperacaoBancaria entra no estado de "Liberando dinheiro de saque", ele pode chamar uma ao que bloqueie na conta do correntista o valor designado para saque. Na sada desse estado, ele pode chamar a ao de debitar o valor da conta. Durante o estado, estar sendo executada a operao de contagemCedulas().
Diagrama de Estados
Existem algumas palavras reservadas que representam as transies internas. Veja quais so e seus significados:

entry: identifica uma ao que executada na entrada do estado. exit: identifica uma ao que executada na sada do estado. do: identifica uma atividade em andamento, ou seja, que executada continuamente durante o tempo em que o objeto permanece nesse estado. include: usado para identificar a invocao de uma submquina, cujo nome est ligado expresso.
As expresses citadas identificam, cada qual, o evento que dispara a expresso correspondente associada. O formato geral para qualquer item da lista :
nome-do-evento (lista de parmetros separada por vrgula ) [ condio-de-guarda ] / expressoao
Cada nome de evento pode aparecer mais de uma vez por estado se as condies de guarda forem diferentes. Os parmetros do evento e as condies de guarda so opcionais.
Figura 5-2: Compartimento de transies internas
Vou utilizar em seguida um exemplo do nosso mundo real para que vocs possam abstrair mais facilmente o conceito de estados. Vamos pensar na vida de uma pessoa do nascimento at a terceira idade. Veja, de forma sucinta, como seria parte do nosso diagrama de estados. Para assumirmos o primeiro estado de nossa existncia, precisamos do evento nascer. J nascemos como beb e a primeira ao que temos reconhecer nossa me, pelo toque, voz e/ou cheiro. Durante esse perodo inicial, o beb, alm de dormir e mamar, tambm desenvolve suas habilidades principalmente motoras: aprende a sentar, engatinhar, falar e andar. S que ao final dessa fase, quando ele j tem uma personalidade bem formada, j
Diagrama de Estados
podemos considerar nosso beb como uma pequenina criana. Nesse perodo no "estado de criana", recebemos muitos estmulos e executamos muitas aes. Mas pelo foco que quero dar nesse primeiro exemplo, coloquei como atividade principal: brincar. At que chega a dita puberdade, que transforma nossas crianas em adolescentes. Na sada do estado de criana, algumas atitudes so tomadas: se criana do sexo feminino, abandonar as bonecas; se do sexo masculino, abandonar os carrinhos (ou as bolinhas de gude). J ao entrar na fase de adolescncia, a primeira ao de nossa "pscriana" estabelecer seu territrio: o quarto deles, as coisas deles, os direitos deles, etc. No estado de adolescente h vrias coisas que podem ser feitas, mas decidi colocar a operao namorar. Em determinado momento da vida (que no sei precisar qual e no sei se algum consegue determinar), o adolescente passa para o estado adulto. Ou, ento, por uma precipitao da sua ao principal (namorar), casa-se sem se tornar adulto.
Figura 5-3: Exemplo de um diagrama de estados descrevendo nossa evoluo
Durante sua permanncia no estado adulto, essa pessoa exerce a ao Trabalhar . Finalizarei o exemplo com uma separao do estado Adulto (como solteiro) para um estado de Casado.
Diagrama de Estados
Estado Inicial e Estado Final
Um estado inicial um tipo de estado que indica o local de incio na mquina de estados ou em um subestado. representado graficamente como um crculo preenchido.
Figura 5-4: Exemplo de estado inicial
Um estado final um tipo de estado que indica que a mquina de estados ou um estado composto concluiu sua execuo. representado graficamente como ura crculo envolvendo um pequeno crculo preenchido.
Figura 5-5: Exemplo de estado final
Diagrama de Estados
Transies
Uma transio um relacionamento entre dois estados indicando que houve uma mudana de estado e determinadas aes sero executadas, quando um evento especfico ocorrer, garantindo que condies foram satisfeitas. A transio disparada quando ocorre a mudana de estado.
representada graficamente como uma linha slida na qual o estado de partida identificado como estado de origem e o estado-alvo o estado de destino. A linha da transio finaliza com uma seta. Pode ser identificada por uma string que possui o seguinte formato: assinatura-do-evento [ condio-de-guarda ] / expresso-ao A assinatura-do-evento descreve um evento com seus argumentos, no seguinte formato: nome-do-evento (lista de parmetros separada por vrgula ) Exemplo: ChecarEstoque(produto)
Figura 5-6 Diagrama de estados para uma fila de impresso
A condio de guarda uma expresso booleana que determina, quando verdadeira, o incio da transio. Pode ser escrita com parmetros do evento disparador ou ainda atributos e links do objeto proprietrio da mquina de estados. S avaliada depois que o evento de ativao ocorre. possvel termos vrias transies a partir do mesmo estado de origem, identificadas com o mesmo evento, diferenciando apenas na sua condio de guarda. Exemplo: [estoqueAtual <= estoqueMinimo] A expresso-ao somente executada no incio da transio, se esta ocorrer. Pode ser escrita com operaes, atributos e links do objeto proprietrio
Diagrama de Estados
da mquina de estados, parmetros do evento disparador ou qualquer outro elemento visvel no mesmo escopo. Exemplo: DataPagamento:= DataPagamento + 3 Veja por exemplo a figura abaixo. O objeto est no estado Aguardando Nota, at que o evento Nota lanada ocorra. Nesse momento, temos duas possibilidades para o mesmo evento. A primeira representada na transio para o estado Atualizando Mdia, que s ser iniciada se a sua condio de guarda for satisfeita, ou seja, que nota >= 0. Outra possibilidade ocorre na transio para o estado Habilitando Segunda Chamada, que s ter incio se a condio de guarda nota = "FT" for verdadeira, ou seja, se no tiver havido nota pois o aluno faltou.
Figura 5-7: Diagrama de Estados com condio nas transies
Um evento a especificao de um tipo de ocorrncia observvel. Para propsitos prticos em diagramas de estado, ele uma ocorrncia que pode disparar uma transio de estado. Eventos podem ser processados um de cada vez. Se um evento no disparar uma transio, esta descartada. Eventos podem ser de vrios tipos (no necessariamente mutuamente exclusivos):
Quando uma condio (descrita por uma expresso booleana) tem seu valor modificado de falso para verdadeiro; Quando h recepo de um sinal explcito de um objeto para outro; Quando h recepo da chamada de uma operao implementada como uma transio por um objeto; Quando a passagem de um perodo de tempo especfico depois da ocorrncia de outro evento representa um evento de tempo. Pode ser representado pela palavra chave after seguida pela expresso a ser avaliada (ex: after 10 minutos). Outra palavra-chave que pode ser usada when (ex: when (dataAdmissao >= 01/01/1987)).
Diagrama de Estados
Figura 5-8: Diagrama para fila de impresso com eventos internos
Diagrama de Estados
Estado composto
Um estado composto um estado que possui uma decomposio grfica em dois ou mais subestados concorrentes (sobrepostos) ou sequenciais (disjuntos).Cada regio de um estado pode possuir estados inicial e final. Uma transio para um estado composto representa uma transio para o estado inicial do referido estado composto. Uma transio para um estado final representa a concluso da atividade na regio do estado composto. Vamos supor um sistema de avaliao no qual o aluno responda as questes de sua prova on-line. Vamos pensar para esse sistema em um objeto Prova (veja figura abaixo). Durante a vida deste objeto, no momento que o aluno responde s questes, o objeto estar passando do estado Aguardando Escolha de Questo para Aguardando Resposta de Questo e assim por diante. Todavia, em paralelo com essas respostas, temos o estado Checando Trmino da Prova, que ocorre quando o tempo decorrido de prova se iguala ao valor do atributo tempoProva. Neste caso, estamos diante de subestados concorrentes, nos quais os estados ocorrem simultaneamente.
Figura 5-9: Diagrama de Estados concorrentes
Diagrama de Estados
Quando Utilizar Diagramas de Estados
Diagramas de estados so bons para descrever o comportamento de um objeto, atravs de vrios casos de uso. Esses diagramas no so muito bons para descrever um comportamento que envolve vrios objetos em colaborao. Para tal, til combinar diagramas de estados com outras tcnicas. Por exemplo, diagramas de interao (vistos mais adiante neste curso) so bons para descrever o comportamento de vrios objetos em um nico caso de uso, e diagramas de atividades (visto anteriormente) so bons para mostrar a seqncia geral de aes para vrios objetos e casos de uso. Nem todo mundo considera que os diagramas de estados sejam naturais. Fique atento ao modo que as pessoas trabalham com eles. Pode ser que sua equipe no considere diagramas de estados teis para seu tipo de trabalho. Isso no um grande problema; como sempre, voc deve lembrar de usar uma combinao das tcnicas que funcionam para voc. Se voc utilizar diagramas de estados, no tente projet-los para cada classe no sistema. Embora este mtodo seja frequentemente usado por perfeccionistas de muita formalidade, ele quase sempre um desperdcio de trabalho. Use diagramas de estados somente para aquelas classes que exibem comportamento interessante, para as quais a construo do diagrama de estados ajude a compreender o que est acontecendo. Muitas pessoas acreditam que Interface de Usurios e objetos de controle tm o tipo de comportamento que til descrever com diagramas de estados.
Diagrama de Estados
Exerccios
1 Em quais situaes voc julga importante a criao de diagramas de estados? 2 Utilize a ferramenta de modelagem UML para criar um ou mais diagramas de Estados para as classes que voc julgar que necessitam no seu diagrama de classes. Concentre-se nos esdados das classes e deixe para pensar depois as operaes (entry/do/exit).
Diagrama de Estados
Espao para anotaes
6. Diagrama de Objetos
Diagrama de Objetos
Objetivos
Conhecer o diagrama de objetos Reconhecer os elementos do diagrama de objetos Montar um diagrama de objetos Saber quando utilizar este tipo de diagrama
Diagrama de Objetos
O que um diagrama de objetos?
Este diagrama poderia tranquilamente ser abordado como um item do captulo de diagrama de classes, j que representa a instncia desse diagrama num determinado ponto do tempo. Por suas caractersticas, ele merece um pouco mais de ateno. Se pensarmos naqueles sistemas cujos requisitos so fonte de dvidas, certamente voc achar que esse diagrama lhe fornece muito mais produtividade do que aparenta. Para instncias de uma classe Aluno, talvez esse diagrama seja desnecessrio, mas ser que teramos o mesmo pensamento no caso de classes envolvendo um ambiente industrial? Vejamos agora este diagrama em detalhes, o mesmo um diagrama simples e no frequentemente utilizado.
Diagrama de Objetos
Criando diagramas de objetos
Um diagrama de objetos consiste numa instncia do diagrama de classes, no qual para cada classe ternos um objeto (sua instncia) em um determinado ponto do tempo. Voc deve estar perguntando: e para que isso me serviria? Primeiramente, muitas vezes estamos naqueles dias em que a criatividade custa para vir ou simplesmente o relacionamento entre classes no est claro suficiente para que possamos realizar a modelagem do diagrama. Uma vez que criamos um diagrama de objetos, passamos a trabalhar com dados reais, que numa viso direta lhe dizem muito mais do que a simples estrutura de uma classe. Essa viso no s esclarece o relacionamento entre as classes, como pode levar ao esclarecimento de dvidas de domnio. Os diagramas de objetos so muito teis para facilitar a modelagem de estruturas complexas de dados. O diagrama de objetos pode tambm auxiliar o desenvolvedor no momento de identificar problemas na execuo de uma aplicao. Durante o debugging, pode-se parar a execuo e paralelamente mapear, num diagrama de objetos, os objetos que esto sendo manipulados, expandindo seus relacionamentos e alguns objetos vizinhos. Se levarmos em conta todos os objetos e relacionamentos possveis dentro de um diagrama, teremos milhares de objetos. Logicamente impossvel exibirmos tudo. Desta forma, deve-se mostrar no diagrama de objetos somente um conjunto de objetos que tenham relevncia dentro da modelagem. Esse conjunto procura se basear em colaboraes. A partir de um determinado objeto, percorrem-se os relacionamentos existentes, congelando-se um determinado estado do objeto. Fowler, no seu livro UML Distilled - A BriefGuide to the Standard Object, afirma que podemos considerar um diagrama de objetos como um diagrama de colaborao (visto anteriormente) sem mensagens, uma vez que estamos representando os objetos ligados uns aos outros para realizar determinada tarefa. As ferramentas no necessitam possuir uma implementao separada para diagramas de objetos. possvel apenas adotar um diagrama de classes que mostre objetos no lugar das classes. Para chamar a ateno para caractersticas importantes, pode-se trabalhar com anotaes e cores diferenciadas no diagrama. A representao grfica de um objeto similar de uma classe. Consiste num retngulo com dois compartimentos. O primeiro mostra o nome do objeto e o segundo mostra os atributos, um em cada linha, com seus valores. Veja a figura abaixo:
Diagrama de Objetos
Figura 6-1: Representao de um objeto
O nome do objeto deve ser sublinhado, na seguinte notao: nome do objeto: nome da classe Por exemplo: uml: Curso possvel ainda omitir o nome do objeto (preservando os dois pontos), representando um objeto annimo ou omitir o nome da classe (juntamente com os dois pontos). Em qualquer um desses casos, mantm-se o sublinhado. mais comum representarmos somente o tipo do objeto no se preocupando com o nome do mesmo. Veja a figura abaixo:
Figura 6-2: Representaes possveis para um objeto
Quanto aos atributos, estes so exibidos na notao:

nome do atributo: tipo = valor
O tipo, se for citado, deve ser o mesmo definido na classe. Desta forma, ele pode ser omitido sem prejuzo da compreenso do diagrama.
Diagrama de Objetos Figura 6-3: Representaes de um objeto com atributos e valores
Atributos cujos valores no sejam relevantes para a modelagem podem ser omitidos. possvel tambm representar atributos cujos valores mudam durante um processamento. Nesse caso, representa-se essa mudana por meio de uma lista de valores. O relacionamento entre os objetos feito atravs de links. Um link a instncia de uma associao. Um nome de papel pode ser mostrado ao final de cada link. Da mesma ferma, um nome de associao pode ser mostrado prximo linha. Multiplicidades no podem ser mostradas para links, pois estes j so instncias de associaes. Os adornos de associao como agregao, composio e navegao, assim como qualifcadores, podem ser mostrados na terminao dos links. Os diagramas de objetos podem tambm conter: notas, restries e pacotes. Vamos considerar o diagrama de classes da figura abaixo. A partir deste diagrama vamos montar um diagrama de objetos, mostrando mais explicitamente as multiplicidades que podem ser representadas por objetos.
Diagrama de Objetos
Figura 6-4: Diagrama de classes base para o diagrama de objetos
Abaixo podemos ver um diagrama de objetos para este diagrama de classes. Note que o diagrama de objetos mostra claramente a multiplicidade que pode acontecer entre um Instrutor e MaterialDidatico, bem como a possibilidade de haver mais de uma verso para o material didtico que mostrado na associao entre Curso e MaterialDidatico. Note ainda que cada associao entre o MaterialDidatico e o Arquivo resultou na criao de um objeto ligado a MaterialDidatico.
Diagrama de Objetos
Figura 6-5: Diagrama de objetos para o diagrama de classes
Diagrama de Objetos
Quando utilizar diagrama de objetos?
Como j falamos na parte introdutria deste captulo, o diagrama de objetos ser utilizado nas seguintes situaes: 1 Durante o debugging, pode-se parar a execuo e paralelamente mapear, num diagrama de objetos, os objetos que esto sendo manipulados, expandindo seus relacionamentos e alguns objetos vizinhos 2 Mostrar as multiplicidades do diagrama de classes de forma mais clara ligando os objetos 3 Muitas vezes estamos naqueles dias em que a criatividade custa para vir ou simplesmente o relacionamento entre classes no est claro suficiente para que possamos realizar a modelagem do diagrama. Um diagrama de objetos ir nos ajudar nestes relacionamentos 4 Montar uma diagrama de objetos com valores e enviar para o programador fazer testes no sistema com objetos com aqueles dados
Diagrama de Objetos
Exerccios
1 Qual a finalidade dos diagramas de objetos? 2 Para o diagrama de classes que voc construiu nos exerccios do captulo de classes faa agora um diagrama de objeto para algumas regies que voc julgar importantes do mesmo.
Diagrama de Objetos
Espao para anotaes
7. Diagrama de Interao
Diagrama de Interao
Objetivos
Conhecer o diagrama de interao Reconhecer os elementos do diagrama de interao Estudar diagramas de colaborao Estudar diagramas de seqncia Saber quando utilizar estes diagramas
Diagrama de Interao
O que um diagrama de Interao?
Antes de iniciarmos o estudo sobre os diagramas de interao, seria importante definirmos o que uma interao. Mais do que isso, acho pertinente esclarecermos quaisquer dvidas sobre interao e iterao. Definio, segundo o Dicionrio Aurlio: interao. [De inter- + no.] S. f. L Ao que se exerce mutuamente entre duas ou mais coisas, ou duas ou mais pessoas; ao recproca: "Nesse fenmeno de interao de linguagem popular e linguagem potica o fato que nos parece mais curioso o do aproveitamento, no curso da vida de cada um, .... de expresses usadas por poetas" (Valdemar Cavalcanti, Jornal Literrio, p. 199); " evidente que a obra de arte resulta da interao de fatores subjetivos e objetivos, veiculados atravs do meio social. " (Euralo Canabrava, Esttica da Crtica, p. 29) iterao. [Do lat. iteratione.] S. f. L Ato de iterar; repetio. 2. lg. Inform. Processo de resoluo (de uma equao, de um problema) mediante uma seqncia finita de operaes em que o objeto de cada uma o resultado da que a precede. Isto posto, interao corresponde a um conjunto de mensagens trocadas entre objetos, com o objetivo de alcanar um determinado propsito, respeitando-se o contexto do sistema. J iterao corresponde, em uma abordagem mais complexa, s fases que se repetem, nas quais a entrada de uma fase corresponde sada da sua antecessora. Em uma abordagem mais simples, corresponde a um processo de repetio. Um diagrama de interao mostra as interaes por meio de uma viso dinmica do sistema. Pode representar um sistema, subsistema, operao, classe ou cenrio de um caso de uso, sendo essa ltima representao a mais frequente. Um diagrama de interao formado, basicamente, por objetos, relacionamentos e mensagens. Os diagramas de interao se apresentam de duas formas:
diagramas de seqncias diagramas de colaborao
Esses diagramas possuem cada qual alguns aspectos que os diferenciam. O diagrama de seqncias enfatiza a seqncia de mensagens dentro de uma linha de tempo, enquanto que o de colaborao enfatiza o relacionamento estrutural entre os objetos, sem se preocupar com o tempo determinado para cada interao.
Diagrama de Interao
Traando um paralelo: suponha que no Restaurante A sei que o garom leva dez minutos at trazer meu pedido e levo vinte minutos comendo. Espero mais cinco minutos pela conta e outros cinco minutos pelo troco. Devo lembrar que a conta s trazida depois que termino minha refeio. Quando vou ao Restaurante B, no preciso me preocupar com o tempo. Assim, no olho toda a hora para o relgio. Sei que fao um pedido ao garom, ele atende meu pedido, recebo a conta, pago, pego o troco e vou embora. S no d para afirmar se a conta chega antes de terminar a minha refeio ou no. Assim, o Restaurante A seria similar ao diagrama de seqncias, no qual as mensagens so trocadas entre os objetos (nesse caso: cliente e garom), com demonstrao do tempo de processamento (no necessariamente com valor definido (10 minutos). O Restaurante B seria similar ao Diagrama de Colaborao, no qual as mensagens so passadas de um objeto a outro sem indicar o tempo de processamento de cada uma. interessante ressaltar que esses diagramas apresentam formas diferentes de modelar os mesmos elementos. como se ordenssemos uma mesma lista de duas maneiras distintas. Apesar da viso ser diferente, estamos lidando com os mesmos dados.
Diagrama de Interao
Diagrama de seqncias
Para melhor ilustrar a interao de um Diagrama de Seqncias, vamos imaginar um processo X qualquer de uma empresa, na qual trabalham os funcionrios Antnio, Joo e Carlos. Num dado instante, o Gerente da empresa solicita ao Antnio que prepare um relatrio de comisses para um determinado ms. Entretanto, para que o Antnio consiga preparar esse relatrio, ele precisa do total de cada vendedor, obtido no ms em foco, e essa informao quem tem o Joo. Ento, Antnio passa um e-mail para o Joo pedindo essa informao. Joo quando recebe essa mensagem (eletrnica) inicia os procedimentos necessrios para relacionar as vendas de cada vendedor. Todavia, ele s possui em mos a matrcula de cada vendedor e seu total vendido. Mas ele pode conseguir o nome de cada vendedor com o Carlos. Assim, Joo passa um e-mail para o Carlos, enviando no corpo da mensagem a lista de matrculas que ele possui, solicitando que seu colega diga a quem pertence. Carlos, ao receber a mensagem, procura em suas fichas os nomes dos vendedores. De posse desses nomes, ele responde ao e-mail de Joo, acrescentando os nomes dos vendedores. Joo, ao receber a resposta de Carlos, responde a mensagem original de Antnio, acrescentando no corpo da mensagem a lista de vendedores (com matrcula e nome) acompanhada dos totais de vendas de cada um. Antnio, feliz da vida pois a equipe bem entrosada, abre a mensagem de resposta, pega as informaes recebidas e coloca em seu relatrio. Nada como uma empresa que funciona! Guardadas as devidas propores, se trocarmos os funcionrios Antnio, Joo e Carlos pelas responsabilidades que eles possuem, temos a encenao da troca de mensagens entre objetos em um diagrama de seqncias. Antnio um captador e transmissor de informaes; ser nossa tela de Relatrio. Joo responsvel por controlar as vendas do ms; ser nosso objeto Vendas. Carlos responsvel por controlar o cadastro dos vendedores; ser nosso objeto vendedor. A representao grfica de um diagrama de seqncias baseada em duas dimenses. A primeira dimenso vertical e representa as mensagens trocadas no decorrer de um tempo de vida (eixo Y). A segunda dimenso horizontal e representa os objetos participantes das interaes (eixo X). As mensagens correspondem a chamadas de servios dos objetos, ou seja, a chamadas de suas operaes. Assim, estabelecemos uma interao que corresponde representao de um elemento do modelo (por exemplo: Diagrama de Seqncias para o caso de uso Cadastro de Funcionrio) e para tal relacionamos os objetos envolvidos e
Diagrama de Interao
desenhamos cada chamada de operao como o disparo de uma mensagem, partindo do objeto chamador para o objeto executor da operao.
Figura 6-6: Exemplo simplificado de troca de mensagens
A representao dos objetos em um diagrama de seqncias feita com um retngulo alinhado no topo do diagrama, partindo dele uma linha vertical tracejada denominada linha de vida, que desenhada at o fim do diagrama. A linha de vida representar a vida deste objeto dentro de um determinado perodo de tempo.
Diagrama de Interao Figura 6-7: Diagrama de seqncia para clculo de preo do produto
Um objeto, que j existe quando a transao do diagrama tem incio, mostrado alinhado ao topo do diagrama, de forma a ficar acima da primeira seta de mensagem. Por outro lado, um objeto que continuar a existir, mesmo aps a finalizao da transao do diagrama, tem sua linha de vida estendida para alm da ltima seta de mensagem. A criao ou destruio de um objeto dentro do perodo de tempo total representado pelo diagrama so mostradas desenhando-se o incio ou fim da linha de vida do objeto no ponto determinado pela criao ou destruio. No caso da criao, a seta que representa essa mensagem desenhada de forma a apontar sua cabea para o smbolo do objeto. No caso da destruio, a seta que carrega essa mensagem direcionada a um grande "X" colocado no fim da linha de vida. As mensagens de criao e destruio podem ser estereotipadas com <<create>> e <<destroy>>, respectivamente. Abaixo voc tem um exemplo de um diagrama de seqncia para mostrar de forma simplificada o agendamento de um curso. Observe as criaes de objetos, bem como as chamadas e retornos de mtodos. Note que as expresses entre [ ..] representam condies que sero explicadas mais adiante.
Figura 6-8: Diagrama de seqncia com mensagens de retorno
Diagrama de Interao
Figura 6-9: Diagrama de Seqncia com a criao e retorno dos objetos
Diagrama de Interao
As mensagens so enviadas de um objeto a outro, por meio de setas que partem de uma linha de vida para outra. Essas setas so identificadas com o nome da operao que est sendo chamada. As mensagens podem carregar a solicitao de um processamento, a comunicao de um evento ou outras informaes relevantes para o cumprimento de responsabilidades. A seqncia de mensagens pode ser numerada, mas seu uso desnecessrio nesse tipo de diagrama. Na figura acima voc pode ver as mensagens numeradas sendo que os nmeros ajudam no entendimento da ordem das mensagens. Ao alcanar o outro lado, a seta d incio ativao, que corresponde ao perodo de tempo durante o qual um determinado procedimento de um objeto est sendo executado. Essa ativao mostrada graficamente como um retngulo fino e comprido, que tem sua parte superior alinhada ao final da seta ativadora e se estende at o fim do processamento, que pode ter uma representao extra com uma mensagem de retorno. A mensagem de retorno no obrigatria. Os retornos so dados por uma linha pontilhada com uma sea na ponte partindo do receptor da mensagem para quem a chamou. A seta de mensagem, alm do nome da operao, tambm pode conter uma condio e/ou uma expresso de iterao (seqncia repetida de mensagens). Textos de identificao como restries de tempo, descries de aes durante uma ativao, entre outros, tambm podem ser mostrados na margem esquerda do diagrama ou perto dos elementos que eles identificam. Condies so colocadas dentro de colchetes e determinam que a mensagem s ser disparada se a condio for verdadeira. Por exemplo:
[instrutorOk] agendarCurso()
A iterao representa o envio da mesma mensagem diversas vezes para o mesmo objeto, sendo comum no tratamento de colees de objetos. Vamos supor que tenho que chamar a operao calculaMedia() dos alunos da turma. Marcando a iterao para a mensagem calculaMedia(), indicamos que ela deve ser chamada vrias vezes. A representao da iterao feita dentro de colchetes, incluindo antes do colchete inicial o smbolo (*) A notao de condio e iterao a mesma para o diagrama de iterao. O texto dentro dos colchetes indica a condio que determinar quantas vezes a mensagem ser passada. Por exemplo:
*[para cada aluno da turma] calcularMedia() *[para cada instrutor] instrutorOk := disponivel(data)
No caso de chamada recursiva (um objeto passa mensagem para si prprio), o segundo smbolo de ativao desenhado levemente direita do
Diagrama de Interao
primeiro, dando a impresso de que esto empilhados. Essa chamada recursiva denominada auto-chamada. Num fluxo de controle procedural, a mensagem de retorno pode ser omitida, pois fica implcito que, ao final da ativao, o retomo ocorrer, ou seja, assume-se que toda mensagem de chamada faz par com uma mensagem de retorno. Para fluxos de controle no-procedurais (como mensagens de processamento paralelo), mensagens de retorno devem ser mostradas explicitamente. Na arrumao dos objetos, deve-se colocar como o primeiro objeto exatamente aquele que d incio interao. No diagrama de seqncias tambm representamos uma ramificao para condies ou concorrncias, que mostrada por mltiplas setas partindo de um ponto simples, sendo cada ramo identificado por uma condio. Dependendo de como as condies so mutuamente exclusivas, essa construo pode representar condicionalidade ou concorrncia. Veja a figura abaixo:
Figura 6-10: Exemplo de ramificao de mensagens
Diagrama de Interao
Diagrama de colaborao
Os objetos so distribudos no diagrama de do diagrama de seqncias, obedecendo colaborao entre objetos representada acompanhada de uma numerao sequencial e condies e iteraes.
colaborao na ordem similar seqncia de mensagens. A por uma ligao simples de outras informaes como
Em virtude da forma como um diagrama de colaborao apresentado, identificamos a seqncia temporal das mensagens por meio de seqncias numricas. A autochamada do diagrama de seqncias identificado como autodelegao no diagrama de colaborao e representado como um arco ligado ao objeto. Na figura abaixo, a primeira mensagem a chamada do mtodo obterGrade() para o objeto cursoX. O cdigo deste mtodo para ser concludo necessita de informaes das disciplinas do referido curso e das turmas ativas. Ento, para cada disciplina chamado o mtodo obterInfDisciplina() do objeto disc1. O objeto disc1, por sua vez, necessita de informaes dos prrequisitos das disciplinas. Ento, passa uma mensagem para si mesmo, chamando o mtodo obterPreRequisito(). O objeto cursoX, depois que recebe a resposta de sua mensagem n 2, chama o mtodo obterTurmasAtivas() que pertence ao objeto turma 1. Repare que uma grande diferena entre o Diagrama de Colaborao e o de Seqncias exatamente o que ocorre com o objeto cursoX. No fica explcito no diagrama as mensagens de retorno e o momento em que isso ocorre.
Figura 6-11: Diagrama de colaborao
Diagrama de Interao
Figura 6-12: Diagrama de colaboraco para o diagrama de classes
Figura 6-13: Diagrama de colaboraco com mensagens sequenciais
Diagrama de Interao
Figura 6-14: Diagrama de colaboraco com mensagens sequenciais aninhadas
Diagrama de Interao
Modelando diagramas de seqncias
O Diagrama de Seqncias totalmente adequado para a identificao de operaes de classes. Normalmente, durante o desenho dos diagramas, vamos percebendo as mensagens necessrias, e se elas no existirem como operaes de classe, podero ser includas neste momento. O diagrama pode ser desenhado de forma gradativa, no qual a cada mensagem surgida, verifica-se a existncia de um objeto instanciado ou no, procedendo sua criao, se necessrio. Condies so recursos interessantes no diagrama de seqncias, mas seu uso para separar cenrios totalmente distintos pode dificultar a compreenso do diagrama. O uso mais frequente para o diagrama de seqncias o de representar cenrios de um caso de uso. Vamos considerar o diagrama de classes da figura abaixo:
Figura 6-15 - Diagrama de Classes para exemplificao do Diagrama de Seqncias
Esse diagrama de classes refere-se a um Controle das vendas efetuadas por um conjunto de vendedores de uma loja de R$ 1,99. Nesse caso, no controlamos os produtos vendidos. Para tanto, vamos pensar no Caso de Uso Registrar vendas.
Diagrama de Interao
Registrar vendas Objetivo: permite cadastrar as vendas efetuadas plos vendedores Ator: Assistente de gerncia Cenrio Principal 1. O sistema prepara uma lista dos vendedores cadastrados na loja. 2. O usurio informa o nmero da venda. 3. O usurio informa, ainda: 3.1. a data da venda; 3.2. o valor da venda; 4. O usurio seleciona o vendedor que efetuou a venda, a partir da lista j montada pelo sistema. 5. O sistema efetua a gravao da venda. Cenrio Alternativo Venda j cadastrada 2a. Se o nmero da venda j estiver cadastrado, informar ao usurio, mostrar as informaes da venda na tela e entrar em modo de alterao dos dados. A partir desses elementos, montamos o diagrama de seqncia com os objetos envolvidos no caso de uso mais o ator. Analisando o caso de uso percebemos a presena da Classe Venda com seus atributos e da Classe Vendedor, pois ningum melhor do que ela para nos dizer quem so os vendedores ativos. Vejamos a figura abaixo que apresenta o diagrama de seqncias que representa este caso de uso. Comeamos o diagrama de seqncias com o ator Assistente de Gerncia. Em seguida poderamos colocar a instncia da classe principal (Venda) ou fazer uso de uma instncia de tela. Como o usurio, ao usar a classe, o faz via uma tela. Desta forma, desenhamos os objetos que representam instncias da tela de cadastramento, da classe venda e da classe vendedor.
Diagrama de Interao
Figura 6-16: Exemplo de um diagrama de seqncias a partir de uma descrio de caso de uso
Conforme dito no caso de uso, a primeira ao do sistema, obter uma lista de vendedores ativos. Assim, a instncia de tela passa uma mensagem para o objeto da classe Vendedor, solicitando esta lista de vendedores. Depois de receber a resposta, o controle passa para o ator, que informa: o nmero da venda. O sistema, antes de permitir que o ator prossiga seu cadastro, verifica se a venda j foi cadastrada anteriormente, por meio do envio de uma mensagem de busca classe Venda. Sendo positivo, o sistema mostrar os dados na tela, mas essa operao no precisa ser representada no diagrama de seqncias, j que foi devidamente detalhada no caso de uso. O ator informa a data e o valor. Em seguida, seleciona na lista montada o vendedor que efetuou a venda. Nada mais tendo para informar, cabe ao sistema (Logicamente que o sistema aguarda a confirmao do usurio para efetuar a gravao. Mas essa mensagem no precisa ser mostrada) efetuar a gravao da mesma, passando uma mensagem para a classe Venda.
Diagrama de Interao
Quando Utilizar Diagramas de Interao
Voc deve utilizar diagramas de interao quando quiser observar o comportamento de vrios objetos dentro de um nico caso de uso. Esses diagramas de interao so bons para mostrar as colaboraes entre objetos; eles no so to bons para uma definio precisa de comportamento. Se voc quer observar o comportamento de um simples objeto atravs de muitos casos de uso, use um diagrama de estados. Se voc quer observar o comportamento atravs de muitos casos de uso ou de muitas trilhas de execuo (threads), considere um diagrama de atividades.
Diagrama de Interao
Exerccios
1 Quais as principais diferenas entre diagrama de seqncia e diagrama de colaborao? 2 Construa um diagrama de seqncia para representar o processo de entrega de um material didtico 3 Para o diagrama de seqncia da figura 69 faa um diagrama de colaborao
Diagrama de Interao
Espao para anotaes
Diagrama de Interao
8. Diagramas Fsicos
Diagramas Fsicos
Objetivos
Conhecer os diagramas fsicos de componentes e implantao Reconhecer os elementos destes diagramas Saber quando utilizar estes diagramas
Diagramas Fsicos
O que so diagramas fsicos?
Diagramas de Fsicos mostram aspectos de implementao fsica, incluindo a estrutura de componentes e a estrutura do sistema em tempo de execuo (run-time) Eles so expressos de duas formas: Diagrama de Componentes Diagrama de Implantao
O Diagrama de Componentes mostra a estrutura de componentes, incluindo os classificadores que eles especificam e os artefatos que eles implementam. O Diagrama de Implantao mostra a estrutura de ns nos quais os componentes so implantados. Esses diagramas tambm podem ser aplicados na modelagem de negcios, no qual os componentes representam artefatos e procedimentos de negcios e os ns de implantao representam a organizao de unidades e recursos (humanos e outros) do negcio. Vamos ver agora com mais detalhes estes diagramas, comearemos pelo diagrama de componentes.
Diagramas Fsicos
Diagrama de Componentes
Um diagrama de componentes mostra as dependncias entre componentes de software, incluindo os classificadores que eles especificam (isto , classes de implementao) e os artefatos que eles implementam (isto , arquivos de cdigos-fonte, arquivos de cdigo binrio, arquivos executveis, scripts). Um diagrama de componentes representa o tipo e no a instncia. Para mostrar instncias de componentes, utilize um diagrama de implantao. Um diagrama de componentes um grfico de componentes conectados por relacionamentos de dependncia. Componentes podem ser conectados a outros componentes por compartimentos fsicos representando relacionamentos de composio. Classificadores que especificam componentes podem ser conectados a eles por compartimentos fsicos ou por um relacionamento estereotipado <<reside>>. Outros-sim, artefatos que especificam componentes podem ser conectados a eles por compartimentos fsicos ou por um relacionamento estereotipado <<implement>>. Um diagrama contendo tipos de componente pode ser usado para mostrar dependncias estticas, como as dependncias de compilao entre programas, que so mostradas como setas tracejadas (de dependncia) de um componente cliente para um componente fornecedor que depende dele de alguma maneira. Embora um componente no tenha suas prprias propriedades (isto , atributos, operaes), ele age como um container para outros classificadores que so definidos com propriedades. Componentes, tipicamente, expem um conjunto de interfaces que representam os servios providos plos elementos que neles residem. O diagrama pode mostrar essas interfaces e a chamada de dependncias entre componentes, usando setas tracejadas dos componentes para as interfaces em outros componentes.
Diagramas Fsicos
Componente
Um componente representa um mdulo fsico, implementvel e substituvel, que corresponde parte de um sistema. Um componente encapsula a implementao e exibe um conjunto de interfaces. Um componente corresponde s interfaces que ele expe, interfaces essas que representam servios providos plos elementos que residem no componente. Um componente pode ser implementado por um ou mais artefatos, tais como: arquivos binrios, arquivos executveis ou arquivos de script. So tipos de componentes: os necessrios para a execuo de um sistema (.exe, .dll, etc), arquivos de cdigo fonte, arquivos de dados, tabelas, etc. mostrado graficamente como um retngulo grande contendo dois pequenos retngulos sobrepostos, partindo de seu interior para o lado de fora do retngulo principal.
Figura 8-1 Representao grfica de um componente
Diagramas Fsicos
Diagrama de Implantao
Diagramas de implantao mostram a configurao de elementos de processamento em tempo de execuo e os componentes de software, processos e objetos que so executados sobre eles. Instncias de componentes de software representam manifestaes em tempo de execuo de unidades de cdigo de software. Para modelagem de negcios, os elementos de processamento em tempo de execuo incluem trabalhadores e unidades organizacionais, e os componentes de software incluem procedimentos e documentos usados plos trabalhadores e unidades organizacionais. Um diagrama de implantao um grfico de ns conectados por associaes de comunicao. Os ns podem conter instncias de componentes. Isto indica que o componente executado dentro do n. Componentes podem conter instncias de classificadores, que indicam que a instncia reside no componente. Componentes so conectados a outros componentes por setas tracejadas de dependncia (possivelmente por meio de interfaces). Isto indica que um componente usa os servios de outros componentes. Um esteretipo pode ser usado para indicar uma dependncia precisa, se necessrio.
Diagramas Fsicos
N
Um n um objeto fsico que representa um recurso de processamento, frequentemente possuindo capacidade de processamento. Os ns incluem dispositivos de computao mas tambm recursos humanos ou recursos de processamento mecnico. Os ns podem ser representados como tipos e como instncias. Um n mostrado graficamente como uma figura que parece uma viso tridimensional de um cubo. Um n possui um tipo-n. Uma instncia de n tem um nome e um nome de tipo. O n pode ter um nome sublinhado, mostrado dentro ou abaixo dele. O nome do n tem a sintaxe:
Nome : tipo-do-n
As normas de apresentao do n com seu tipo so similares apresentao de objetos. Setas tracejadas com a palavra-chave <<deploy>> mostram a capacidade de um tipo-n suportar um tipo-componente. Alternativamente, isto pode ser mostrado por smbolos de componentes aninhados dentro de smbolos de n. Instncias de componentes e objetos podem estar contidos dentro de smbolos de instncias de ns. Isto indica que os itens residem nas instncias dos ns. Ns podem ser conectados por associaes para outros ns, por meio de um caminho de comunicao. A associao pode ter um esteretipo para indicar a natureza do caminho de comunicao (por exemplo: o tipo de canal ou rede). Veja abaixo a representao grfica:
Figura 8-2: Rerpesentao grfica de um N
Diagramas Fsicos
Combinando Componentes com Diagramas de Utilizao
Embora possa projetar em separado o diagrama de utilizao e o diagrama de componentes, voc tambm pode colocar o diagrama de componentes no diagrama de utilizao, como na figura abaixo. Voc pode fazer isso para mostrar quais componentes funcionam em que ns.
Figura 8-3: Componentes e ns juntos em um diagrama fsico
Diagramas Fsicos
As pessoas, projetam, frequentemente, estes tipos de diagramas com smbolos que se parecem com os vrios elementos. Por exemplo, elas usam cones especiais para servidores, PC e bancos de dados. Isso vlido em UML: voc pode tratar cada cone como um esteretipo de um elemento de diagrama apropriado. Geralmente, tais cones facilitam a compreenso do diagrama, embora eles se tornem confusos se voc mostrar ns e componentes juntos. A arquitetura mostrada acima de uma aplicao que estar armazenada em um J2EE Server central o qual ser acessado via web pelos seus usurios. Nele ter uma pgina HTML com o link para rodar a aplicao. O usurio dever pela primeira vez acessar esta pgina e clicar no link para que a aplicao seja baixada e instalada automaticamente pelo Java Web Start na mquina. Durante a instalao o Java Web Start ir perguntar se o usurio deseja criar um atalho no desktop do seu micro para futuramente rodar a aplicao. Desta forma as prximas execues do software podem ser feitas clicando no cone localizado no desktop, da mesma forma como as demais aplicaes so executadas. Aps ter sido baixado e instalado o programa passar a estar acessvel para o usurio localmente na mquina. No mais o usurio precisar esperar o download da aplicao para poder utiliz-la. O programa ser armazenado localmente em uma espcie de cache do Java Web Start fazendo com que nas prximas execues ele j esteja disponvel e no precise ser baixado novamente. Caso seja atualizado algum mdulo do sistema esta atualizao dever ser colocada no servidor J2EE central, onde antes de cada execuo, se houver rede, o Java Web Start ir procurar por atualizaes do software a fim de manter sempre o mesmo atualizado para o cliente. Caso haja alguma atualizao esta ser feita de forma transparente para o usurio. Problema: Demanda mquinas mais robustas no lado do cliente; Requer a instalao do JRE no cliente. Benefcios: Pode funcionar mesmo que no haja rede; Emisso de relatrios mais fcil.
Diagramas Fsicos
Quando Utilizar Diagramas Fsicos
A maioria das pessoas projeta este tipo de informao informalmente, mas as pessoas esto gradualmente formalizando os diagramas para se adaptarem a UML. Projeta-se estes diagramas sempre que preciso mostrar informao fsica que diferente da informao lgica associada.
Diagramas Fsicos
Exerccios
1 Qual a finalidade do diagrama de componentes e do diagrama de implantao? 2 Para o sistema acima monte um diagrama de componentes em conjunto com um diagrama de implantao consideranco que o sistema dever ser em n-camadas. Para isto escolha uma tecnologia que voc gostaria de implantar o mesmo e coloque os componentes de software necessrios para rodar o mesmo.
Diagramas Fsicos
Espao para anotaes
9. Apndice 1: Extensibilidade da UML
Apndice: Extensibilidade da UML
Mecanismos de extensibilidade da UML

A UML uma linguagem-padro para a modelagem de sistemas orientados a objetos. Apesar de sua padronizao predefinida, a UML oferece notaes de extenso que permitem a ampliao de como podemos expressar nossos modelos. Basicamente, podemos encontrar duas formas de extenso da UML:

Esteretipos Restries
Esteretipos
Os esteretipos so utilizados para a classificao de novos elementos na UML. O esteretipo utilizado para a criao de classificaes de elementos que no foram definidos como padro, e deve ser utilizado para o tratamento de problemas especficos de modelagem. Os esteretipos so formados por palavras entre ngulos duplos <<esteretipo>>". Segue uma lista de esteretipos predefinidos, que foram extrados a partir do uso comum destes. Essa lista segue a seguinte classificao: Esteretipos Esteretipos Esteretipos Esteretipos Esteretipos Esteretipos Esteretipos para relacionamentos de dependncias. para classes. para eventos e mensagens. para componentes. para relacionamentos de generalizao. para restries. para comentrios.
Esteretipos
para
relacionamentos
de dependncias
<<access>> Especifica que o contedo pblico do pacote de destino est acessvel ao espao do nome do pacote de origem. <<bind>> Especifica que a origem instncia o template de destino, utilizando os parmetros reais dados. <<call>> Especifica que a operao de origem invoca a operao de destino. <<derived>> Especifica que o elemento-origem derivado do elemento-destino. Isso significa que o elemento-origem no uma instncia do elemento-destino, mas uma instncia de um outro elemento que um subtipo ou uma subclasse do elemento-destino. <<extend>> Especifica que um caso de uso tem um comportamento estendido a partir de um caso de uso-base. <<friend>> Especifica que o elemento-origem tem visibilidade especial no elemento destino.
<<import>> Especifica que o contedo pblico do pacote-destino pode ser recebido e acessado por um pacote-origem. <<include>> Especifica que comportamentos comuns a mais de um caso de uso devem ser captura em outro caso de uso que ser utilizado plos casos de uso que lhe deram origem. <<instanceof>> Especifica que o objeto de origem uma instncia do classificador de destino. <<instantiate>> Especifica que as operaes na classe de origem criam instncias da classe de destino. <<refine>> Especifica que a origem um grau mais alto de abstrao que o destino. <<send>> Especifica que a operao de origem envia o evento destino. <<trace>> Especifica que o destino um antecessor histrico da origem.
Esteretipos para classes

<<actor>> Especifica um elemento que interage externamente com o sistema. <<exception>> Especifica um evento que pode ser ativado ou capturado por uma operao de classe. <<implementationClass>> Especifica a implementao de uma classe em uma linguagem de programao. <<interface>> Coleo de operaes que pode ser utilizado para definir os servios que uma classe pode oferecer a outras. <<powertype>> Especifica um classificador cujas instncias de suas classes esto envolvidas em um relacionamento de generalizao. <<process>> Especifica um classificador cujas instncias representam um fluxo pesado.
<<signal>> Especifica um estmulo assncrono comunicado entre instncias. <<stereotype>> Especifica que o classificador um esteretipo que pode ser aplicado a outros elementos. <<thread>> Especifica um classificador cujas instncias representam um fluxo leve. <<type>> Especifica uma classe abstraia que utilizada somente para determinar a estrutura e o comportamento de um conjunto de objetos. <<utility>> Especifica classes cujos atributos e operaes so todos escopo de classes.
Esteretipos para eventos e mensagens

<<becomes>> Especifica que o objeto-destino o mesmo objeto que o de origem, mas em um ponto adiante no tempo e com possveis valores, estados ou papis diferentes. <<copy>> Especifica que o objeto de destino uma cpia exata do objeto-origem, mas independente. <<create>> Especifica que o objeto-destino criado pelo evento ou pela mensagem enviada pelo objeto-origem. <<destroy>> Especifica que o objeto-destino destrudo pelo evento ou pela mensagem enviada pelo objeto-origem.
Esteretipos para componentes

<<table>> Especifica um componente que representa uma tabela de banco de dados no sistema. <<documents>> Especifica um componente que representa um documento do sistema.
<<executable>> Especifica um componente que representa um componente que poder ser executado no sistema. <<file>> Especifica um componente que representa cdigos-fonte ou dados. <<library>> Especifica um componente que representa uma biblioteca de objetos.
Esteretipos
para
relacionamentos
de generalizao
<<implementation>> Especifica que o filho herda a implementao do pai, mas no a torna pblica, nem oferece suporte para suas interfaces, violando dessa forma a caracterstica de permitir substituies.
Esteretipos para restries

<<invariant>> Especifica uma restrio que sempre precisa ser mantida para o elemento que est associado. <<precondition>> Especifica uma condio que deve ser verdadeira antes da invocao de uma operao. <<poscondition>> Especifica uma condio que deve ser verdadeira aps o trmino da execuo de uma operao.
Esteretipos para comentrios

<<requirement>> Especifica uma caracterstica ou comportamento desejado para um sistema. <<responsability>> Responsabilidade ou obrigaes que um elemento encarregado de cumprir.
Restries
As restries ampliam o vocabulrio dos elementos na UML, permitindo modificar ou acrescentar novas regras aos elementos do modelo. Por exemplo, por uma questo de regra de negcio, todos os clientes do tipo pessoa fsica devem ter obrigatoriamente o salrio informado. Podemos expressar essa restrio como no exemplo a seguir. As regras devem ser expressa entre chaves {}. { PessoaFisica.salrio > O } Exemplo de uma restrio simples Alguns padres para restrio A UML tambm define como padro algumas restries. Aqui segue uma lista com esses padres com o elemento a qual se aplica. Restries para generalizao {complete} Especifica que todos os subtipos de um supertipo j foram especificados, no permitindo filhos adicionais. {incomplete} Especifica que nem todos os subtipos de um supertipo foram totalmente especificados, permitindo filhos adicionais. {overllaping} Especifica que subtipos de um supertipo podem ter mais de um filho como tipo. Restries para instncias {destroyed} Especifica que a instncia deve ser destruda antes da concluso da interao da qual ela faz parte. {new} Especifica que a instncia deve ser criada durante a execuo da interao da qual ela faz parte. {transient} Especifica que a instncia deve ser criada durante a execuo da interao da qual ela faz parte, mas destruda antes da concluso da execuo.
Glossrio
abstrao Caracterstica essencial de uma entidade que a diferencia de todos os outros tipos. agregao Tipo de associao na qual um todo relacionado com suas partes (relacionamento todo/parte). agregada Classe que representa o "todo" no relacionamento de agregao. arquitetura Arquitetura de sistemas um conjunto de decises sobre artefatos e elementos que formaram o sistema. A arquitetura deve abranger como ser construdo o sistema, seus elementos estruturais e comportamentais, suas colaboraes, etc. artefato Conjunto de informaes utilizado ou desenvolvimento de sistemas de software. realizado por um processo de
assinatura Nome, parmetros e valores de retomo de uma operao. associao Associao descr v relacionamentos entre objetos. Cada associao tem duas pontas, onde em cada ponta est ligado um objeto. atividade Estado de execuo de alguma coisa. Pode ser, por exemplo, a execuo de um mtodo em uma classe, uma rotina de trabalho, etc. ator Papel desempenhado por qualquer usurio de um caso de uso, ou seja, o ator quem solicita os servios disponveis em casos de uso. atributo Atributo uma propriedade de classe. Representa as caractersticas prprias de uma abstrao. autochamada Mensagem que um objeto envia para si mesmo. caracterstica comportamental Caracterstica dinmica de um elemento, como uma operao ou um mtodo. caracterstica estrutural
Caracterstica estrutural (esttica) de um elemento. cardinalidade Nmero de elementos existentes em um conjunto. caso de uso Documento que descreve os cenrios pretendidos para um sistema, com o objetivo de atender as necessidades do usurio. classe Abstrao de um conjunto de objetos que compartilham os mesmos atributos, operaes e relacionamentos. colaborao Nome dado interao entre duas ou mais classes, com o objetivo de fornecer algum comportamento cooperativo. componente Parte fsica de um sistema, que representa elementos lgicos para a realizao de uma ou mais interfaces. comportamento Resultados produzidos por eventos e mtodos. composio Forma de agregao, em que o objeto-parte pode pertencer somente ao objetotodo. Alm disso, geralmente o objeto-todo vive e morre com suas partes, isto , acontece uma remoo em cascata container Objeto que existe para conter outros objetos e que proporciona operaes para acessar ou interagir com seu contedo. delegao Habilidade de um objeto enviar uma mensagem a um outro objeto como resposta a uma mensagem recebida. dependncia Relacionamento entre dois itens, em que a alterao do item independente pode alterar a semntica do item dependente. destinatrio Objeto que manipula a instncia de uma mensagem passada pelo objeto emissor. diagrama Representao grfica de um conjunto de elementos do sistema, que permite a visualizao do sistema sob diferentes perspectivas. diagrama de atividades
Representa um fluxo de controle de atividades, que ocorrem no processo de um sistema, oferecendo suporte para comportamentos condicionais e paralelos diagrama de casos de uso Representa um conjunto de cenrios identificados, que seja til aos usurios de um sistema. diagrama de classes Representa o modelo da estrutura de um sistema orientado a objetos, demonstrando as classes, os tipos e os relacionamentos. diagrama de colaborao Um dos diagramas de interao que d nfase organizao estrutural dos objetos que colaboram entre si. diagrama de componentes Representa os componentes que faro parte dos sistemas em construo, demonstrando as dependncias entre esses componentes. diagrama de grficos de estados Representa os estados possveis de um objeto em particular. So demonstrados os estados de um objeto, eventos, transies e atividades. diagrama de implantao Representa a configurao e a arquitetura de um sistema a que estaro ligados seus respectivos componentes, podendo ser representada tambm a arquitetura fsica de hardwares, processadores, etc. diagrama de objetos Representa a modelagem de instncias das classes de um sistema em determinado ponto e momento de execuo. diagrama de seqncia Um dos diagramas de interao que d nfase ordenao sequencial em que os comportamentos acontecem. encapsulamento Mecanismo usado para ocultar os dados, a estrutura interna e os detalhes de implementao de um objeto. Toda a interao com um conjunto de objetos feita de uma interface pblica constituda de operaes. estado Situao vivida por um objeto, pela qual esse objeto deve responder algo aos eventos gerados. esteretipo Extenso do vocabulrio da UML que permite a criao de novos tipos de blocos de construo, para atender necessidades especficas de um modelo. estmulo Evento gerado no sistema que necessita de resultados.
evento Ocorrncia de um estmulo gerado para o objeto, capaz de fazer a mudana de seu estado atual. exportar Tornar visvel um elemento fora do espao do nome que o contm. expresso Seqncia de caracteres que tem como resultado um valor. expresso booleana Tem como resultado um valor booleano. filha Subclasse. foco de controle Indicador do perodo de durao pelo qual os objetos esto cooperando para realizar um comportamento. generalizao a capacidade de se criar superclasses que encapsulam a estrutura e o comportamento comum a vrias subclasses. herana Mecanismo pelo qual elementos mais especficos incorporam a estrutura e o comportamento de elementos mais gerais. herana mltipla Uma variao da generalizao, em que uma subclasse pode herdar a estrutura e o comportamento de mais de uma superclasse. hierarquia de classes Representa descries das relaes de herana entre classes. implementao Realizao concreta do contrato declarado por uma interface ou a definio de como algo construdo ou computado. incompleto Modelagem de um elemento em que faltam certas partes. instncia Manisfestao concreta de alguma abstrao, uma entidade qual um conjunto de operaes pode ser aplicado e que tem um estado para armazenar o efeito das operaes. integridade Relacionamento consistente e apropriado entre dois ou mais elementos.
interao Conjunto de objetos que interagem por meio da troca de mensagens, para a realizao de um comportamento. linha de vida do objeto Representa a existncia de um objeto em uma interao. me Superclasse. mquina de estados Seqncia de estados pela qual um objeto passa durante seu tempo de vida. mecanismos de extensabilidade Um dos mecanismos que permite a extenso da UML de maneira organizada. mensagem Meio de comunicao entre objetos que contm informaes espera de atividades que acontecero. mtodo Implementao de uma operao para uma classe. modelo Simplificao da realidade, criado com a finalidade de proporcionar uma melhor compreenso do sistema que ser gerado. multiplicidade Indicao de quantos objetos podem participar de um dado relacionamento. n Elemento fsico existente em tempo de execuo que representa um recurso computacional. nota Representa comentrios, observaes e esclarecimentos que se podem utilizar para qualquer elemento da UML. objeto Sinnimo de instncia de classe, sendo uma manifestao concreta de uma abstrao com uma identidade que encapsula estados e comportamentos. objeto persistente Objeto que sobrevive aps o trmino de execuo de um processo ou um thread. objeto transiente Objeto que sobrevive somente at o trmino de execuo de um processo ou um thread. operao Procedimento de chamada em um objeto.
operao polimrfica Uma mesma operao que implementada de maneira diferente por dois ou mais tipos. orientado a casos de uso Processo pelo qual os casos de uso so utilizados como artefatos primrios para o estabelecimento do comportamento desejado do sistema, para verificar e validar a arquitetura de um sistema. pacotes Organizam os modelos criados na UML. pai Superclasse. papel Comportamento de uma entidade que participa de determinado contexto no sistema. parmetro Especificao de uma varivel que pode ser alterada, passada ou retornada. polimorfismo Conceito segundo o qual dois ou mais tipos de objetos podem responder mesma mensagem de maneiras diferentes, usando operaes polimrficas. ps-condio Algo que necessita ser verdadeiro aps a chamada de uma operao. pr-condio Algo que necessita ser verdadeiro antes da chamada de uma operao. privado Mecanismo de escopo usado para restringir o acesso a atributos e operaes de uma classe, de maneira que outros objetos no possa utiliz-los. produto Artefatos de desenvolvimento, como cdigos, modelos, documentao gerada, etc. propriedade Caracterstica de um elemento da UML. pblico Mecanismo de escopo usado para tornar atributos e operaes de classes acessveis a outros objetos. raia de natao
Organiza as atividades representadas em diagramas de atividades. Essa organizao consiste em criar grupos que so responsveis pelas atividades ocorridas. realizao Relacionamento entre itens, no qual um item implementa comportamentos especificados por outros. receptor Objeto ao qual enviada uma mensagem. refinamento Relacionamento que representa a especificao especificado em determinado nvel de detalhe. relacionamentos Conexo semntica entre elementos. responsabilidade Contrato ou obrigao em um tipo ou de uma classe. restrio Extenso da semntica de um elemento da UML, permitindo criar ou modificar regras j existentes. solicitao Especificao de um estmulo enviado a um objeto. subclasse Elemento que recebe por herana a estrutura e os comportamentos de uma superclasse. superclasse Elemento que contm a estrutura e o comportamento generalizado de outras classes (as subclasses). thread Fluxo leve de controle que pode ser executado concorrentemente com outros threads no mesmo processo. tipo Esteretipo de uma classe, utilizado para especificar um domnio de objetos, com as operaes que podem ser aplicadas aos objetos. transio Relacionamento entre dois estados, em que o objeto no seu estado atual deve realizar atividades para passar para um outro estado, desde que as atividades tenham sido cumpridas. completa de algo j
UML (Unified Modeling Language) Linguagem de modelagem unificada para visualizao, especificao, construo e documentao de artefatos de sistemas de software. valor atribudo Extenso das propriedades de um elemento da UML, que permite a criao de novas informaes na especificao desse elemento. verso Um conjunto de artefatos de software, relativamente completos e consistentes que sero entregues. viso Projeo em um modelo, vista a partir de determinada perspectiva ou ponto de vista, que omite as entidades que no so relevantes para essa viso. viso dinmica Aspectos de um sistemaque do nfase a comportamentos. viso esttica Aspectos de um sistema que do nfase estrutura. visibilidade Especificao de como uma caracterstica ou um comportamento especificado para uma classe podem ser vistos por outros objetos de classe.
10.
Apendice 2: Diagramas UML dos exerciccios

Apostila para Curso de UML

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Apostila para Curso de UML

Încărcat de

Drepturi de autor:

Formate disponibile

UML: Unified Modeling Language

UML: Unified Modeling Language

Desenvolvimento de software orientado a objetos

UML A unificao dos mtodos e criao de um novo padro

Fases do Desenvolvimento de um Sistema

Espao para anotaes

UML: Unified Modeling Language

2. Diagrama de Use Case

Diagrama de Use Case

Diagrama de Use Case

Definio de Use Case

Diagrama de Use Case

Diagrama de Use Case

Diagrama de Use Case

Diagrama de Use Case

Diagrama de Use Case

Figura 2-1: Representao bsica de um use case

Diagrama de Use Case

Diagrama de Use Case

Figura 2-2: Representao de atores

Diagrama de Use Case

Figura 2-3: Atores interagindo com o caso de uso

Diagrama de Use Case

Ator: Atendimento ao cliente Cenrio Principal

Diagrama de Use Case

Diagrama de Use Case

Relacionamentos entre casos de uso e atores

Relacionamentos entre extenso e incluso.

Diagrama de Use Case

Figura 2-4: Relacionamento de associao entre atores e use case

Diagrama de Use Case

Figura 2-5: Generalizao entre casos de uso

Diagrama de Use Case

Figura 2-6: Gerneralizao entre atores

Diagrama de Use Case

Figura 2-7: Relacionamento de extenso (extend)

Diagrama de Use Case

Figura 2-8: Relacionaemnto de extenso e incluso (visto abaixo)

Diagrama de Use Case

Diagrama de Use Case

Figura 2-9: Relacionamento de incluso

Figura 2-10: Relacionamento de incluso entre use cases

Diagrama de Use Case

Modelando requisitos com casos de uso

Diagrama de Use Case

Diagrama de Use Case

Casos de uso e pacotes

Figura 2-11: Representao de pacote exibindo os casos de uso

Diagrama de Use Case

Figura 2-12: Representao de um pacote sem os casos de uso

Diagrama de Use Case

Quando Utilizar Casos de Uso

Diagrama de Use Case

Exemplos de descrio textual

Diagrama de Use Case

Diagrama de Use Case

Diagrama de Use Case

Diagrama de Use Case

Diagrama de Use Case

Diagrama de Use Case

Espao para anotaes

UML: Unified Modeling Language