Curso CompletoOs livros desta coleco e das linguagens de programao abordam, de uma maneira simples e objectiva, praticamentfltodas as capacidades dos programas tratados. As inmeras ilustraes e exemplos com instrues, passo a passo, levam!no a dominar com rapidez as matrias apresentadas. AUTOCAD 2002 (Jos Garcia) CRYSTAL REPORTS (Srgio Vasconcelos Oliveira)

HARDWARE - Montagem, Actualizada, Deteco e Reparao de Avarias em PC'S e Perifricos - 3a Edio Actualizada (Jos Gouveia/Alberto MagalhesJ HTML 4 & XHTML (Pedro Coelho) PHOTOSHOP 7 (Fernando Tavares Ferreira) PROGRAMAO EM JAVA 2 (Pedro Coelho) UTILIZAO DO LOTUS NOTES t (Jorge Neves) WINDOWS SERVER 2003 (Samuel Santos/Antnio Rosa)

Uma coleco especialmente dirigida aos estudantes de Engenharia Informtica e Informtica de Gesto, assim comoaos profissionais destas reas que pretendam actualizar os seus conhecimentos. Inclui obras que apresentam, de umaforma clara e pragmtica, os conceitos fundamentais e o estado da arte PROGRAMAO COM CLASSES EM C++ - 2' Edio Actualizada (Pedro Guerreiro)

Uma coleco dedicada aos profissionais de Sistemas de Informao, assim como a outros profissionais de informticaque pretendem desenvolver os seus conhecimentos, e aos estudantes das licenciaturas e mestrados. GESTO DO CONHECIMENTO - O NOVO PARADIGMA DAS ORGANIZAES (Cndido Fialho/Antnio Serrano)

A nova cojeco da FCA dedicada aos profissionais de projecto e desenvolvimento de software, e aos estudantesdas licenciaturas e mestrados. j GESTO DE PROJECTOS DE SOFTWARE (Antnio Miguel) I

Uma coleco que trata o impacto das tecnologias de informao na sociedade e suas influncias a nvel das pessoas,das empresas e das instituies. INFORMATIZAO DO PODER LOCAL (Francisco Melo Pereira)

Para Profissionais jUma coleco dedicada aos profissionais da Informtica, abordando matrias de uma forma acessvel, mas profunda. Stambm teis para os que querem tirar uma certificao. HARDWARE PARA PROFISSIONAIS - 2' Edio Actualizada e Aumentada (Antnio Sampaio) TCP/IP EM REDES MICROSOFT - 5' Edio Actualizada (Paulo Loureiro)

OUTRAS PUBLICAES DICIONRIO DE INFORMTICA E NOVAS TECNOLOGIAS (Jos A. de Matos) EXERCCIOS RESOLVIDOS COM O EXCEL XP E 2000 (Adelaide Carvalho) PALMTOPS (Oscar Martins/Fernando Franco) SOLUES INFORMTICAS NA GESTO DE RECURSOS HUMANOS - 2' Edio Actualizada (Srgio Sousa/Maria Jos Sousa) VISUAL BASIC.NET - PROGRAMAO PRTICA (Nuno Nina)

1- edio actualizada e aumentada

Mauro Nunes / Henrique O'Neill

FCA-EDITORA DE INFORMTICARUA D. ESTEFNIA, 183-1. ESQ. 1000-154 LISBOA

TEL. 21 353 27 35 (S. Editorial) FAX 21 352 26 84TEL 21 351 1448 (Servio Clientes)

E-mail: fca@fca.ptVisite a nossa pgina em http://www.fca.pt

s/te seguro (certificado pela Thawte)

Nesta coleco, pretendemos oferecer uma panormica sobre vrios produtos de Software, pertencendo a maioriacategoria de "software li\re", em ingls "open source", e alguns de "software grtis". COMO INSTALAR UM SERVIDOR COMPLETO DE E-MAIL (Mrio Gamito/Ricardo Oliveira) PYTHON (Pedro Morais/Jos Nuno Pires l PROGRAMAO EM PERL (Leii Luo/Vasco Amaral) PROGRAMAO COM PHP 4 tCdilos Serro/Joaquim Marques)

Prefcio

E AUDINCIAO objectivo do Fundamental de UML efectuar uma abordagemsimples e prtica linguagem de modelao visual UML.

Este livro direccionado a todos os que procuram um manualprtico e simples sobre as principais tcnicas de modelao naUML. Ajuda a compreender e a construir os diagramas maisimportantes na especificao e anlise de Sistemas de Informao.

Nesta 2a edio melhora-se a componente didctica do livro,apresentando em cada captulo um conjunto de perguntas dereviso e de exerccios resolvidos. O captulo 10 foi aumentadoatravs da apresentao de um novo caso de estudo, onde se propea especificao e desenvolvimento de um sistema de informaopara uma Universidade. O livro foi igualmente objecto de umareviso, tendo sido a notao grfica presente nos diagramascompatibilizada com a verso 1.5 da UML, de Maro de 2003.Com esta nova edio, pretendem os autores reforar a capacidadedo Fundamental de UML como um elemento de formao nodomnio da modelao visual de sistemas de informao.

KSTRUTURA DA OBRA

O Captulo l fornece uma introduo necessidade de efectuar odesenvolvimento de Sistemas de Informao. A actividade delevantamento de requisitos abordada no Captulo 2-Diagrama deuse cases. A estrutura de informao em termos de objectos,classes e suas relaes introduzida no Captulo 3-Diagrama deClasses.

O Captulo 4-Diagrama de Actividades explica os principaisconceitos necessrios para a modelao de actividades. Emseguida, no Captulo 5-Diagramas de Interaco fornecida umaviso sobre a modelao das interaces entre objectos. O Captulo6-Diagrama de Estados completa os aspectos dinmicos demodelao do sistema, abordando a representao dos diversosestados dos objectos.No Captulo 7-Desenho do Sistema so apresentados algunsprincpios gerais para a definio da arquitectura da aplicao. Osdiagramas de componentes e de instalao so apresentados noCaptulo 8-Diagramas Fsicos. No Captulo 9-Processo deModelao abordado o mtodo de desenvolvimento eapresentadas ferramentas informticas de apoio modelao.

Por fim, no Captulo 10-Casos de Estudo so apresentados modelosde Sistemas de Informao, que demonstram de forma integrada asdiversas tcnicas disponibilizadas pela UML.

Ao longo dos diversos captulos so apresentadas sugesteprticas para facilitar a utilizao da linguagem UML. As sugesteso realadas dentro da seguinte moldura:

Quando definido um conceito, este realado a negrito parafacilitar a sua identificao.

Mauro Nunes (mauro.nunes@iscte pt)Henrique O'Neill (henrique.oneill@iscte.pt)

ndice1. Introduo \

1.1 Introduo i1.2 Modelao Visual 21.3 Definio da Unified Modelling Language (UML) 31.4 Histria 4

1.4.1 A evoluo das tcnicas e metodologias de modelao 41.5 Notao 5

1.5.1 Diagramas 51.5.2 Abstraces de modelao 7

1.6 Desenvolvimento de Sistemas de Informao 91.6.1 Mtodo iterativo e incremental 91.6.2 Arquitectura \\

1.7 Descrio do exemplo 122. Diagrama de Use Cases 13

2.1 Conceito e Aplicao 132.1.1 mbito ig2.1.2 Actores ig2.1.3 Use cases de Negcio e de Sistema 172.1.4 Comunicao entre actores e use cases 182.1.5 Tempo 192.1.6 Cenrio principal e Cenrios Secundrios 202.1.7 Relaes de include, extend e generalizao 24

2.2 Exerccios 293. Diagrama de Classes 35

3.1 Conceito e Aplicao 353.1.1 O que um Objecto 383.1.2 O que uma Classe 393.1.3 Tipos de dados bsicos 423.1.4 Associaes 433.1.5 Multiplicidade 443.1.6 Identificao de classes 453.1.7 Identificao de atributos 473.1.8 Identificao de associaes e operaes 473.1.9 Restries 48

3.2 Tpicos Avanados 493.2.1 Classes Associativas 493.2.2 Generalizao e Herana 50

Fundamentai deJJMJL ndice

3.2.3 Agregao e Composio 513.2.4 Diagrama de classes PhonePizza revisto 52

3.3 Exerccios 534. Diagrama de Actividades 57

4.1 Conceito e Aplicao 57i 4.1.1 Linhas verticais de responsabilizao 61

4.1.2 Actividades 614.1.3 Transio entre actividades 624.1.4 Comportamento condicional 63

4.2 Tpicos avanados 644.2.1 Agrupamento e decomposio de actividades 65 i4.2.2 Processamento paralelo 66 j4.2.3 Fluxo de objectos 674.2.4 Diagrama de actividades revisto 68l

4.3 Exerccios 69l5. Diagramas de Interaco 75l

5.1 Conceito e Aplicao 75|5.2 Diagrama de Sequncia 7

5.2.1 Mensagens Ti5.2.2 Linha temporal e controlo5.2.3 Processamento em paralelo5.2.4 Interface com o utilizador

5.3 Diagrama de Colaborao5.3.1 Ordenao numrica5.3.2 Repeties5.3.3 Esteretipos ,5.3.4 Mensagens condicionais 865.3.5 Sincronizao 865.3.6 Objectos e ligaes 87

5.4 Construo de diagramas de interaco 885.5 Exerccios 89

6. Diagrama de Estados 956.1. Conceito e Aplicao 95

1.1.l Estado 976.1.2 Transio entre estados 98

6.2. Tpicos avanados 996.2.1 Agrupamento de Estados 99|6.2.2 Concorrncia entre subestados 1

6.3 Exerccios 101

7. Desenho do Sistema 1057.1. Conceito e Aplicao 1057.2 Diagrama de classes - perspectiva de Desenho 106

7.2.1 Esteretipos 1067.2.2 Relao de Dependncia 1077.2.3 Relao de Realizao 1087.2.4 Interfaces 1087.2.5 Diagrama de Classes com nveis 110

7.3 Pacotes 1137.3.1 Relaes entre pacotes 1147.3.2 Representao do sistema em 3 nveis 116

7.4 Exerccios 1168. Diagramas Fsicos 119

8.1. Conceito e Aplicao 1198.2. Diagrama de Componentes 121

8.2.1. Componentes 1238.2.2. Interfaces 125

8.3. Diagrama de Instalao 1268.3.1. Ns 1278.3.2. Comunicao 1298.3.3 Ns e componentes 129

8.4 Exerccios 1319. Processo de Modelao 135

9.1 Conceito e Aplicao 1359.1.1 Orientaes para o desenvolvimento 136

9.2 Processo de Modelao Unificado 1379.2.1 Actividades 1379.2.2 Fases 1389.2.3 Arquitectura de modelao 1409.2.4 Resultado da Modelao 142

9.3 Aproximao prtica ao desenvolvimento 1439.4 Ferramentas de modelao com UML 145

9.4.1 Rose 2000 1489.4.2 Visio 2000 150

9.4 MDA - Model Driven Architecture 15110- Casos de Estudos 155

10.1 PhonePizza 15510.1.1 Modelo Negcio 15610.1.2 Modelo de Domnio 15910.1.3 Modelo de Use Cases 162

XII xni

FundamentaLdeJIML.

> 10.1.4 Modelo de Desenho 17310.1.5 Modelo de Implementao 17510.1.6 Modelo de Instalao 176

10.2 SlUniversitas 17710.2. l Modelo de Use Cases 181

' 10.2.2 Modelo de Desenho 190'

Fundamentai de UML Jntrodug

satisfazem essas necessidades e informticos que desenvolvam asfuncionalidades pretendidas.

A utilizao da UML - Unified Modelling Language abre!perspectivas para responder ao desafio de desenvolvimento dejnovos sistemas de informao, cada vez mais complexos, robustos,fiveis e ajustados s necessidades dos utilizadores.

1,2 MODELAO VISUALQuando se pensa em projectar algo de novo, torna-se conveniente]recorrer a modelos que representem aquilo que ir seidesenvolvido. Esses modelos constituem assim uma representaoabstracta de uma realidade projectada para o futuro. Tomemos poiexemplo a construo de um novo edifcio ou de uma novamquina. Para tal, os arquitectos e engenheiros criamrepresentaes das suas ideias atravs de desenhos tcnicos ou demaquetas, para serem compreendidas e validadas. Estes modelo^possuem uma forte componente grfica e utilizam um conjuntolimitado de smbolos com um significado especfico. Estaaproximao procura eliminar a ambiguidade e redundnciageralmente associada a uma descrio escrita, tirando partido daimagem como elemento de comunicao.

Estes modelos tendem a ser to mais elaborados quanto maiscomplexo for aquilo que se pretende desenvolver: um simplesesboo ser suficiente para orientar a construo de um pequenoanexo para arrumao de material de jardinagem; o projecto de umgrande edifcio exigir um conjunto complexo de diagramas quepermitam coordenar o trabalho de todos aqueles envolvidos na suaconstruo. Independentemente da complexidade do problema, alinguagem utilizada nestes diagramas dever ser isenta deambiguidade, permitir descrever as partes essenciais do problema amodelar e ser simples para ser entendida por todos.

O desenvolvimento de sistemas informticos depara com desafiossemelhantes aos que se encontram noutras reas de criao tcnica,C0mo a arquitectura ou a engenharia. Estes desafios talvez sejammaiores, j que os sistemas informticos se vo tornando maiscomplexos e permanecem mais tempo entre ns, exigindo umapermanente actualizao de forma a responder s contnuassolicitaes de melhoria colocadas pelos seus utilizadores e a tirarpartido de novos desenvolvimentos tecnolgicos.

UML a sigla de Unified Modelling Language, que pode sertraduzido por Linguagem de Modelao Unificada.

A UML uma linguagem que utiliza uma notao padro paraespecificar, construir, visualizar e documentar sistemas deinformao orientados por objectos.Pela abrangncia e simplicidade dos conceitos utilizados, a UMLfacilita o desenvolvimento de um sistema de informao. Permiteintegrar os aspectos de natureza organizacional que constituem onegcio e os elementos de natureza tecnolgica, que iro constituiro sistema informtico, ajudando a dominar a complexidade dasregras de negcio e definir os processos e fluxos informativos.

Pelo facto de utilizar um conjunto de smbolos padro, a UMLfunciona como um meio de comunicao entre os diversoselementos envolvidos no processo, utilizadores, gestores e equipade desenvolvimento. A linguagem pode ser utilizada paradocumentar o sistema ao longo de todo o ciclo de desenvolvimento,comeando com a tarefa inicial de anlise dos processos de negcioda organizao e prolongando-se at tarefa de manutenoevolutiva do sistema informtico.

A UML permite ainda responder a requisitos tcnicos relevantespara uma evoluo dos sistemas informticos, como a arquitectura

Fundamentai de UML

da aplicao informtica (software), a capacidade de reutilizaodos componentes desenvolvidos e a independncia em relao aoequipamento.

A abrangncia da UML justifica assim a utilizao do termounificada.

1.4

1.4.1 A evoluo das tcnicas e metodologias de modelao

Na curta histria do desenvolvimento de sistemas de informao, edo software em geral, poderemos identificar duas grandes fases:uma fase inicial em que se adoptou uma aproximao estruturadaou funcional e uma outra fase, mais recente, em que a aproximaose baseia no paradigma dos objectos (Rumbaugh et ai, 1991). AlUML o resultado de um longo processo de maturao no domnida modelao de sistemas de informao segundo o paradigma doobjectos.So muitos os autores que contriburam para o conhecimento queexiste actualmente sobre o modo como os sistemas de informaodevem ser modelados e construdos (fig. 1.1). Todos estes trabalhostm muito em comum, mas cada um deles prope nomenclaturas eabordagens especficas para a modelao de sistemas deinformao.

A diversidade de propostas tornava difcil a comunicao e reduziaa utilidade prtica desta rea de conhecimento, em grande partedevido diferena de nomenclaturas utilizadas nos modelossemnticos, notao sintctica e diagramas. Atentos a esteproblema, trs dos mais relevantes autores neste domnio - Booch,Jacobson e Rumbaugh - comearam a trabalhar em conjunto paraapresentar uma proposta unificadora dos seus trabalhos individuais.

FIGURA 1.1 - CONTRIBUIES PARA UMLEste trabalho veio a dar origem UML (Linguagem de ModelaoUnificada), apresentada publicamente pela primeira vez emOutubro de 1995. Em Novembro de 1997, a UML foi adoptadapelo OMG (Object Management Group) como uma linguagem demodelao padronizada e de livre utilizao. Actualmente a UMLest na verso 1.5 (OMG, 2003).

A UML recorre a uma notao padronizada, constituda por umconjunto limitado de elementos de modelao, que podem sertipificados em diagramas, abstraces e relacionamentos.

Um modelo em UML constitudo por um conjunto de diagramasque representam aspectos complementares de um sistema deinformao. Em cada um destes diagramas so utilizados smbolosque representam os elementos que esto a ser modelados(abstraces) e linhas que relacionam esses elementos. Os smbolose as linhas tm significado especfico e possuem formas distintas,

constituindo uma forma de notao.

1.5 NOTAO . , *,.,..., ,.,'W - ; , , ,

1.5.1 Diagramasf-

A UML disponibiliza o seguinte conjunto de diagramas:Diagrama de Use Case - serve para identificar as fronteiras do

sistema e descrever os servios (use cases) que devem serdisponibilizados a cada um dos diversos utilizadores (actores).Captulo 2.

l

Diagrama de Classes - atravs do qual descrevemos a estrutura de]informao (classes e suas relaes) que utilizada no sistemajCaptulo 3.

Diagrama de Objectos - que pode ser utilizado para ilustrar umdiagrama de classes com um exemplo concreto.

Diagrama de Sequncia e Diagrama de Colaborao - servempara ilustrar como os objectos do sistema interagem parafornecer a funcionalidade do use case. Estes diagramasdesignam-se genericamente por Diagramas de Interaco.Captulo 5.

Diagrama de Actividade - pode ser utilizado para descrever cadaum dos use cases, realando o encadeamento de actividadesrealizadas por cada um dos objectos do sistema, numa ptica defluxo de trabalho (work-flow). Captulo 4.

Introduo

Diagrama de Estados - que utilizado para modelarcomportamento dos objectos isto , descrever alteraes nosvalores de atributos dos objectos em resultado da ocorrncia decertos eventos. Captulo 6.

Diagrama de Componentes - utilizado para descrever aarquitectura da aplicao informtica em termos decomponentes de software. Captulo 8.

Diagrama de Instalao (deployment) - permite descrever aarquitectura de equipamento informtico utilizado e distribuiodos componentes da aplicao pelos elementos da arquitectura.

1.5.2 Abstraces de modelao

As Abstraces podem ser tipificadas como estruturais,comportamentais, de agrupamento ou anotacionais. A figura 1.2ilustra algumas destas abstraces.

Fu ndamental. de UML .Introduo

Abstraces estruturais e comportamentais reflectem a orientao jpor objectos da UML, permitindo descrever a estrutura e o;comportamento dos diversos elementos que constituem o sistema de informao. Abstraces de agrupamento so meramente;conceptuais, podendo ser utilizadas para agrupar outros elementos!estruturais, comportamentais ou mesmo de agrupamento. As notasso utilizadas para colocar comentrios nos diagramas.

Os Relacionamentos so utilizados para realar relaes existentesentre os elementos abstractos de modelao (Fig. 1.3):

Esteretipos, etiquetas e restries so mecanismos comuns aJUML que podem ser utilizados para reforar a capacidade dlexpresso da linguagem (Fig. 1.4): '

FIGURA 1.4 - MECANISMOS COMUNS DE MODELAOO conceito de esteretipo permite estender a capacidadeexpressiva da linguagem, i.e., atribuir novos significados aossmbolos que so utilizados para a modelao de um determinadotipo de problema. As etiquetas servem para caracterizar elementosde modelao especficos. As restries nos diferentes elementospodem ser tambm evidenciadas atravs de notas.

1.6 DESENVOLVIMENTO DE SISTEMWS DE

O desenvolvimento de sistemas de informao segue um mtodoque enquadra um conjunto de regras, etapas e actividades quedevem ser satisfeitas.

A UML pode ser utilizada em diversas aproximaes dedesenvolvimento, desde o tradicional ciclo de vida sequencial emcascata, at s abordagens mais recentes utilizando prottipos.Todavia, as caractersticas da UML tornam-na particularmenteadequada para um desenvolvimento iterativo e incremental.

Outro aspecto relevante no processo de desenvolvimento autilizao de uma arquitectura de referncia que permita enquadrare potenciar as vantagens da linguagem UML.

1.6.1 Mtodo iterativo e incremental

O desenvolvimento de sistemas de informao inclui a realizaode tarefas de anlise da organizao, levantamento de requisitos deutilizao, anlise do sistema de informao, desenho, codificao,teste, instalao e manuteno. A nossa experincia indica-nos quepara sistemas de informao complexos no possvel isolar econcluir completamente cada uma destas tarefas.

O desenvolvimento de um sistema de informao segundo umaabordagem iterativa e incremental pressupe a existncia desucessivas iteraes de refinamento, que se repetem ao longo dotempo, at se obter uma soluo final. Os riscos tcnicos soidentificados e prioritizados inicialmente, sendo revistos em cadaiterao.

O Unified Modelling Process (UMP) uma abordagem iterativa emcremental que sugere uma utilizao efectiva da UML (Jacobsonet ai, 1999). Este processo prope que um projecto seja estruturadonuma dimenso temporal e numa dimenso processual.

l

Introdurn

Na dimenso temporal so identificadas 4 fases: Incio (Inception)na qual se especifica a viso do projecto; Elaborao associada aoplaneamento das actividades e recursos, bem como scaractersticas gerais da arquitectura; Construo durante a qual osistema construdo de forma iterativa; Transio, na qual disponibilizado o sistema aos utilizadores.

Na dimenso de processo so contempladas diversas actividadestcnicas: anlise e modelao do negcio, levantamento derequisitos, anlise, desenho, programao, teste e instalao.Complementarmente devem ser asseguradas actividades de gestode projecto e de preparao da instalao. Em cada uma destasactividades podem ser utilizados instrumentos especficos,designadamente os diagramas UML ou tcnicas de gesto deprojecto.A figura l .5 mostra corno as fases e os componentes do processo searticulam.

FasesActividades

Componentes de ProcessoModelao do Negcio

Requisitos

Anlise e Desenho

Implementao

Teste

Instalao

Actividades de SuporteConfigurao eGesto da MudanaGesto de Projecto

Ambiente

Como se pode verificar pela figura, em cada uma das fases existeuma actividade que predominante, mas no exclusiva. Porexemplo, ser possvel fazer levantamento de requisitos edesenvolver um pequeno prottipo demonstrador na fase de Incio.Todas as tarefas podem ser realizadas em cada fase de formaiterativa e incremental.

Esta aproximao tem claras vantagens, melhorando o detalhe e ombito de especificao. O facto de antecipadamente se limitar onmero de iteraes permite convergir para uma soluo final deuma forma controlada, minimizando o risco de dilatar o prazo deconcluso do projecto.1.6.2 Arquitectura

Uma arquitectura de referncia constitui um elemento fundamentalpara a concepo, construo, evoluo e gesto de um sistema deinformao.

10

A figura 1.6 sugere uma arquitectura adaptada s caractersticas daUML, segundo a qual um sistema de informao deve serdesenvolvido segundo 4 vises, cada uma das quais aprofundaaspectos complementares do sistema, e que so centradas numaquinta, que permite validar e ilustrar as anteriores. A viso central constituda por cenrios que ilustram os requisitos mais importantesdo sistema e que so descritos sob a forma de use cases. Asrestantes quatro vises so igualmente descritas atravs dosdiagramas da UML. A arquitectura de modelao abordada commais detalhe no Captulo 9.

1.7 DO

Ao longo deste livro ser utilizado um caso de estudo para facilitara descrio da linguagem e exemplificar a sua utilizao.

Este caso de estudo baseia-se no desenvolvimento de um sistemade informao para gerir uma empresa que possui uma redeintegrada de lojas de produo e distribuio de refeies rpidas.O sistema de informao ir apoiar os servios de atendimento,acompanhamento de clientes e encomendas. O sistema deinformao permite que as encomendas possam ser recebidas portelefone, pela Internet ou nas lojas.A PhonePizza constitui um exemplo bastante rico que permitedescrever em profundidade as especificidades da linguagem.Simultaneamente, permite criar um modelo que pode ser facilmenteadaptado a muitas organizaes que pretendam desenvolverestratgias de negcio baseadas em prticas de comrcioelectrnico.

Diagrama de Use Cases 22,1 CONCEITO E APLICAO '.Os use cases, ou traduzindo letra "casos de utilizao",constituem a tcnica em UML para representar o levantamento derequisitos de um sistema. Desde sempre que o correctolevantamento de requisitos no desenvolvimento de sistemas deinformao tenta garantir que o sistema ser til para o utilizadorfinal, estando de acordo com as suas necessidades.

O requisito num sistema uma funcionalidade ou caractersticaconsiderada relevante na ptica do utilizador. Normalmente,representa o comportamento esperado do sistema, que na prticaconsiste num servio que deve ser disponibilizado a um utilizador(Booch, Rumbaugh e Jacobson, 1999).

Bennet, McRobb e Farmer (1999) identificam trs categorias derequisitos:

Requisitos funcionais - descrevem o que um sistema faz ou esperado que faa. Estes so os requisitos que inicialmentesero levantados, abrangendo a descrio de processamentos aefectuar pelo sistema, entradas (inputs) e sadas (putputs) deinformao em papel ou no ecr que derivam da interaco compessoas e outros sistemas.Requisitos no funcionais - relacionados com ascaractersticas qualitativas do sistema, descrevendo a qualidadecom que o sistema dever fornecer os requisitos funcionais.Abrange medidas de desempenho como, por exemplo, temposde resposta, volume de dados ou consideraes de segurana.

FundamentaieteOML, Diagrama de Use Case*

* Requisitos de facilidade de utilizao (usability) - garantemque existir uma boa ligao entre o sistema desenvolvido,utilizadores do sistema e tambm as tarefas que desempenhamapoiados pelo sistema.

l

Existem vrias tcnicas que podem ser utilizadas para efectuar o \levantamento de requisitos. Estas tcnicas abrangem a realizao |de reunies participativas (workshops), entrevistas, questionrios,!observao directa, estudo e amostra de documentos e relatrios.Para efectuar um correcto levantamento, frequentemente osanalistas combinam diversas destas tcnicas.

Os diagramas de use cases so utilizados para a apresentao derequisitos e para assegurar que tanto o utilizador final como operito numa determinada rea ou o especialista informtico,possuem um entendimento comum dos requisitos. O seu objectivo mostrar o que um sistema deve efectuar e no como o vai fazer.

Estes diagramas utilizam as seguintes abstraces de modelao:

* Actores* Use cases Relaes (Include, Extend e Generalizao)

O seguinte texto descreve um conjunto de requisitos para um novosistema, que poderia ser obtido, por exemplo, em resultado de umajentrevista:

"Pretende-se desenvolver um sistema de informao degesto para um grupo de pizzarias PhonePizza, que permitaaos clientes efectuar encomendas na loja e atravs daInternet. Na loja, o cliente dirige-se ao empregado de balcoque introduzir no sistema a encomenda pretendida.

Caso a encomenda seja efectuada atravs da Internet, ocliente ter que se identificar, atravs do seu nome de

M

utilizador e palavra-chave (controlo de acesso). O clientepode ento registar os artigos que pretende encomendar, V;podendo usufruir de um desconto no item, caso este esteja em &>promoo. O sistema deve ainda permitir que o Gestor daPizzaria efectue as reservas de mesa, verificando se este tem ;autorizao para o efectuar."

O resultado do levantamento de requisitos encontra-se representadopelo seguinte diagrama de use cases.

J

Este diagrama o resultado de um processo de construo. Esteprocesso, bem como os principais conceitos, so explicados emseguida.

2.1.1 mbitoPara assegurar a compreenso do projecto a desenvolver por todasas partes envolvidas, necessrio definir partida o seu mbito eobjectivo(s). Esta definio deve ser curta e concisa, evitandodetalhes sobre os requisitos do sistema. Normalmente, noultrapassa um pargrafo para sistemas pequenos ou algumaspginas para sistemas de maior dimenso. Para o exemploapresentado inicialmente, teremos a seguinte descrio do seumbito.

mbito do sistema"Pretende-se desenvolver um sistema de informao degesto para um grupo de pizzarias PhonePizza, que permitaaos clientes efectuar encomendas na loja e atravs daInternet"

2.1.2 Actores

A primeira tarefa a desenvolver para construir um diagrama de usecases a identificao dos actores do sistema. Um actor representauma entidade externa que interage com o sistema.

Recorrendo ao nosso exemplo, so identificados os seguintesactores:

Os actores Cliente e Gestor Pizzaria so as pessoas queiro interagir com o sistema. Apesar da representao humanizada,os actores podem no ser s pessoas, mas tambm outros sistemasfsicos ou lgicos como, por exemplo, um mdulo deContabilidade.

Em geral, um actor pode invocar vrios use cases e um use casepode ser invocado por vrios actores. Por exemplo, um actorFuncionrio pode tambm ser um actor Chefe de Loja.

Os actores devem ser caracterizados atravs de uma pequenadescrio, de forma a assegurar uma correcta compreenso dosignificado do actor por todos os elementos da equipa envolvida naanlise. Para os actores identificados anteriormente, teremos aseguinte descrio:

Descrio dos actores

Cliente - Uma pessoa que encomenda produtos da PhonePizzapela Internet e nas pizzarias.Empregado de Balco - Empregado que recebe asencomendas ao balco da pizzaria.Gestor Pizzaria - Empregado que est encarregue de efectuaras reservas de mesa numa pizzaria.

2.1.3 Use cases de Negcio e de Sistema

Os use cases podem ser definidos numa perspectiva de Negcio oude Sistema. Na primeira perspectiva, procura-se identificar a formacomo se responde a um cliente ou evento em termos de processo denegcio. Na perspectiva do Sistema, procura-se caracterizar asfuncionalidades que a aplicao a desenvolver (software) devedisponibilizar ao utilizador.

A principal razo para esta distino (por vezes, pouco ntida emcontextos altamente informatizados, como o caso PhonePizza que

nos serve de exemplo) prende-se com o facto de nem todos os usecases (processos) de negcio virem a ser suportados pelo sistemainformtico. Para alm disso, devemos ter presente, que umasimplificao no processo de negcio poder ser uma soluo maiscorrecta (eficiente e eficaz) do que o desenvolvimento de umaaplicao informtica com uma funcionalidade complexa.

Aps a identificao dos actores, deve-se identificar para cada actoros use cases em que este interage com o sistema. No nossoexemplo, estes so identificados na tabela seguinte:

ACTORCliente

Empregado Balco

Gestor Pizzaria

USE CASES

Efectuar Encomenda Internet Controlo de Acesso

* Efectuar Encomenda' Controlo de Acesso

Reservar MesaControlo de Acesso

TABELA 2,1 - IDENTIFICAO DE USE CASES POR ACTOR

2.1.4 Comunicao entre actores e use cases

A comunicao entre um actor e os use cases pode ser representadauma simples linha recta ou uma seta cujas pontas indicam adireco da comunicao.

* Linha recta simples - Os actores podem estar colocados emqualquer ponto do diagrama, com o pressuposto que existiralguma comunicao de emisso ou recepo.

* Seta unidireccional - A seta indica o sentido preferencial dacomunicao. Normalmente, neste caso habitual a colocao

dos actores emissores esquerda da fronteira do sistema, e dosactores receptores direita.

normal utilizarmos tanto a primeira como a segunda alternativa.Neste livro os exemplos mais simples utilizaro a linha rectasimples, enquanto que os exemplos um pouco mais complexosutilizaro a seta unidireccional. A fig. 2.3 ilustra estas duasalternativas.

FIGURA 2,3 - REPRESENTAO DE COMUNICAO

2.1.5 Tempo

Na identificao dos use cases parte-se do princpio que todos sooriginados pelos actores. Contudo, em alguns sistemas existem usecases que so despoletados, automaticamente, de acordo com umprocesso temporal cclico, onde num determinado intervalo detempo o use case executado.

Por exemplo, no caso em estudo poderia existir a necessidade deefectuar um cpia peridica dos dados das encomendas ou o enviomensal das promoes aos clientes registados. A fig. 2.4 mostra arepresentao destes use cases, repare na seta unidireccional:

19

2.1.6 Cenrio principal e Cenrios Secundrios

Cada um dos use cases identificados deve ser detalhado ou descritoem termos de cenrios de utilizao. Estes cenrios so os possveiscaminhos seguidos dentro do use case, de forma a fornecer ao actoruma resposta (Shneider e Winters, 1999).

Esta descrio pode assumir a forma de texto livre ou estruturadosegundo um conjunto de passos numerados, ficando esta deciso aocritrio do analista. Complementarmente, a UML disponibiliza umconjunto de tcnicas, designadas por diagramas de interaco, quepermitem descrever de forma grfica os diversos cenrios (estetema abordado no Captulo 5).

Por exemplo, o detalhe do use case "Efectuar Encomenda Internet"seria:

Texto Livre

"Efectuar Encomenda Internet:O cliente, aps ter validado o seu acesso, selecciona a opoEncomendar, sendo mostrado em simultneo com a suaencomenda o catlogo de produtos. Para adicionar um

produto, tem apenas que introduzir o cdigo do mesmo, paraque, automaticamente, o seu nome, descrio e preo sejamvisualizados no respectivo item da encomenda. Ao mesmotempo, calculado o valor total da encomenda.

Atravs da opo Confirmar, o cliente confirma a suaencomenda e passa para a funo de pagamento, onde aps aintroduo e confirmao dos dados do carto de crdito atribudo um nmero de identificao encomenda, queposteriormente ser entregue na morada do cliente."

Descrio Estruturada

Pr-condioDescrio

Ps-Condio

O cliente um utilizador vlido no sistema.1. O use case comea quando o cliente

selecciona a opo de Encomendar.2. Em simultneo com a sua encomenda

mostrado o catlogo de produtos.3. O cliente adiciona produtos encomenda

atravs da introduo do cdigo do produto.4. Automaticamente, o sistema mostra o

nome, descrio e preo do produto.5. De cada vez que adicionado um produto,

o valor total da encomenda calculado.6. O cliente confirma a sua encomenda atravs

da opo Confirmar.7. O sistema pede ento os detalhes do carto

de crdito.8. O sistema confirma os dados do pagamento

e atribui um nmero de identificao encomenda.

A encomenda ser entregue na morada docliente.

Efectuar Encomenda Internet (Cenrio Principal)

Na nossa experincia, a descrio estruturada tem provadoser bastante eficaz.

No exemplo anterior, foram introduzidos os conceitos depr-condio e ps-condio que indicam, respectivamente, oestado inicial e final do sistema aquando da realizao do use case.

A pr-condio indica o que deve existir inicialmente para que ocenrio descrito seja seguido com sucesso. No caso daps-condio demonstrado o que ir acontecer depois do cenrioser concludo.

Na descrio do use case pressupe-se que esto reunidas todas ascondies que garantem que tudo corre bem, sendo um cenrioonde no surgem problemas, denominado como o cenrioprincipal. Contudo, pode existir a necessidade de descreversituaes (caminhos) alternativas, ou seja, cenrios secundrios,especialmente quando se pensa no que poder correr mal nocenrio. Por exemplo, no caso anterior, o cliente poderia terintroduzido um cdigo de produto errado ou no ter um carto deicrdito vlido.

Assim, ficaramos com a seguinte descrio:

Efectuar Encomenda Internet (Cenrios Secundrios)Pr-condioDescrio

O1.

2.

3.

4.

cliente um utilizador vlido no sistema.O use case comea quando o clienteselecciona a opo de Encomendar.Em simultneo com a sua encomenda mostrado o catlogo de produtos.O cliente adiciona produtos encomendaatravs da introduo do cdigo do produto.a) Se um cdigo invlido o sistema avisao cliente com uma mensagem.Automaticamente o sistema mostra o nome,descrio e preo do produto.

1

.&

CaminhosAlternativos

Ps-Condio

5.

6.

7.

8.

De cada vez que adicionado um produto ovalor total da encomenda calculado.O cliente confirma a sua encomenda atravsda opo Confirmar.O sistema pede ento os detalhes do cartode crdito.O sistema confirma os dados do pagamentoe atribui um nmero de identificao encomenda,a) Se o carto for invlido, o sistema avisao cliente atravs de uma mensagem,voltando em seguida para o passo 7.

A qualquer momento, antes de efectuar opagamento, o cliente pode cancelar a suaencomenda, pressionando no boto Cancelar.A encomenda ser entregue na morada docliente.

As alternativas podem ser introduzidas directamente no texto dadescrio ou quando mais complexas, na linha de CaminhosAlternativos.

A representao grfica do cenrio principal e dos cenriossecundrios pode ser efectuada em conjunto quando a suacomplexidade reduzida.

Ao serem definidos os actores e use cases, tambm definida afronteira do sistema, que separa os requisitos que esto fora oudentro do sistema a desenvolver. Contudo, por vezes, difcildistinguir claramente onde enquadrar determinados requisitos,ficando esta deciso ao critrio do analista que deve procurar aresposta, analisando cuidadosamente a pertinncia de cadarequisito.

ital de UML

Nem todos os requisitos possuem a mesma importncia para osistema. Sendo assim, necessrio efectuar uma triagem dosmesmos, atravs de uma classificao por ordem de importncia. frequente a utilizao da seguinte escala:

Obrigatrio - O requisito ser includo de certeza.* Desejvel - No garantida a sua incluso, depende de outros

factores como custos, risco ou recursos.* Adiado - Ser includo numa segunda verso do sistema.

Diagrama de Use Cases

A descrio de um use case deve incluir todos os detalhesencontrados na anlise (actores, dados, processo) de formaa aumentar a informao disponvel.

2.1.7 Relaes de include, extend e generalizao

Os use cases podem estar relacionados entre si. As relaes nwfrequentes so include, extend e generalizao,relao include significa que um determinado use case utiliaou inclui a funcionalidade disponibilizada num outro use case. '

No nosso exemplo foram utilizadas as seguintes relaes:

Efectuar EncomendaInternet

Desconto p.5

'extend< ( Desconto Internet ]

include\

FIGURA 2.5 - EXEMPLO DE RELAES

Neste diagrama utiliza-se a relao include para demonstrarque a funcionalidade "Controlo Acesso" utilizada quandounia encomenda efectuada atravs da Internet. Esta relaotambm til quando existem use cases repetidos, pois evita a suaduplicao no diagrama.

Alguns autores utilizam a relao uses em vez deinclude.

Na descrio do use case "Efectuar EncomendaInternet" foi referido um pressuposto na pr-condio que ocliente era um utilizador vlido do sistema, ou seja, j tinhapassado pelo controlo de acesso. Caso no existisse estepressuposto, a relao include tambm teria que ser includana descrio, como mostrado em seguida:

Descrio Estruturada (Include)

Efectuar Encomenda Internet (Cenrio Principal)Pr-condioDescrio 1.

2.

3.

4.

Include: Controlo de Acesso.O use case comea quando o clienteselecciona a opo de Encomendar.Em simultneo com a sua encomenda mostrado o catlogo de produtos.

A relao extend ocorre quando existe um comportamentoopcional que deve ser includo num use case. Este comportamento definido num segundo use case e invocado pelo use case base,atravs de um mecanismo de pontos de extenso.

O mecanismo de pontos de extenso permite definir no use casebase onde o comportamento ser incorporado, sem alterar a suadescrio. Tambm garante que o seu comportamento no seja

24 25

alterado caso o "Desconto Internet" deixe de existir. A sua jdescrio efectuada da seguinte forma:

Descrio Estruturada (extend)Efectuar Encomenda Internet (Cenrio Principal)Pr-condioDescrio 4. ...

5. Para cada produto escolhido, o sistemaverifica o seu preo, que adicionado aocusto total da encomenda.

6. Se o produto est em promoo,existindo assim um desconto:

a. Extend: Calcular Desconto.Em simultneo com a sua encomenda 7.

8.mostrado o catlogo de produtos.

Na descrio do use case "Efectuar Encomenda]Internet" definido um ponto de extenso "Desconto p. 6'que indica onde, ser utilizado o comportamento do use case"Desconto Internet", neste caso no passo 6 (p. 6). Destaforma, o cliente ao adicionar um novo produto sua encomendaobter um desconto caso o produto esteja em promoo.A descrio do use case de extenso "Desconto Internet" ia seguinte:

Desconto Internet (Extenso)Pr-condioDescrio

O produto est em promoo na Internet.1. O sistema retorna a valor do desconto.2. Mostra o desconto na encomenda.3. Calcula o desconto subtraindo ao preo do

produto.

A relao de generalizao utilizada quando existe um use caseque um caso particular de um outro use case. Por exemplo, na fig.2.5 o comportamento do use case "Efectuar Encomendainternet" semelhante ao use case "EfectuarEncomenda", existindo apenas pequenas variaes especficas domeio onde efectuada a encomenda.

A generalizao usufrui das mesmas propriedades que uma relaopai/filho, onde o use case "filho" herda ou substitui por completo ocomportamento do use case "pai". Por exemplo, imaginemos que ouse case "Controlo de Acesso" pode ser realizado de 2formas diferentes, conforme efectuado atravs da Internet ou naloja. Para representar estes requisitos, poderamos utilizar aseguinte generalizao (fig. 2.6):

FIGURA 2,6 - EXEMPLO DE GENERALIZAOEsta relao tambm pode ser utilizada entre actores, como demonstrado pela fig. 2.7.

FIGURA 2.7 - EXEMPLO DE GENERALIZAO ENTRE ACTORES

27

No exemplo da figura anterior estabelecida uma relao degeneralizao entre o actor Funcionrio (caso geral) e o actorEmpregado de Balco (caso especfico). Esta relao evita aduplicao de ligaes quando ambos os actores partilham algunsuse cases.

A fig. 2.8 ilustra a situao em que todos os funcionrios tm queregistar a hora de entrada/sada e apenas o empregado de balcopode registar encomendas.

Segundo Fowler (2000), as seguintes regras podem ser aplicadaspara decidir sobre que relaes utilizar: jl Utilizar include quando o mesmo use case pode ser

utilizado em duas ou mais situaes.* Utilizar a generalizao quando se descreve a variao dos

comportamento normal, pretendendo apenas efectuar umadescrio casual.

* Utilizar extend quando se descreve a variao docomportamento normal, mas de uma forma mais controlada,atravs de pontos de extenso no use case base.

Tendo definido os requisitos do sistema, possvel descrever osobjectos que compem o sistema e as suas relaes, constituindoum resultado da anlise dos requisitos. Esta descrio efectuadaatravs de um diagrama de classes, tema abordado no captuloseguinte.

2,2 EXERCCIOS2.2.1 Perguntas de Reviso

1: O que significa um use casei2: Qual a notao para um use casei3: O que significa um actor?4: Qual a notao para um actor?5: Para que servem os diagramas de use casei6: Defina o conceito de requisito?7: Que tipos de requisitos existem?8: Que tipo de associao possvel entre um actor e um use casei9: Que tipos de relao podem ser efectuadas entre use casesl10: Qual a diferena entre a relao de include e

extend?H: Que notao utilizada para a relao de generalizao?12: O que significa um ponto de extenso?

Diagrama de

2.2.2 Problemas Resolvidos

Efectue o levantamento de requisitos e desenhe o respectivodiagrama de use cases.

Primeiro identifique os actores, em seguida, identifique osrespectivos use cases e, por fim, desenhe o diagrama.

Biblioteca

Da entrevista com o responsvel da biblioteca de uma universidaderesultou a seguinte descrio para um novo sistema informtico:

"Um das actividades principais da biblioteca efectuar oemprstimo de publicaes aos alunos da universidade. Oemprstimo registado pelos funcionrios da biblioteca, quetambm consultam diariamente os emprstimos cujos prazos foram iultrapassados. Todo este processo efectuado manualmente, sendomuito ineficiente. Espera-se que o novo sistema resolva estasituao.Os alunos necessitam de pesquisar os livros existentes nabiblioteca. Caso um livro esteja requisitado, mostrada a dataesperada de entrega."

Parque de Estacionamento

Considere os seguintes requisitos de um sistema informtico para agesto de um parque de estacionamento.a) O controlo efectuado com base na matrcula do veculo.b) Na entrada do parque existir um funcionrio que introduz asmatrculas no sistema, ficando de imediato registado a data e horade incio do estacionamento. O sistema tem que verificar se amatrcula existe.c) Se a matrcula no for reconhecida pelo sistema, ento ofuncionrio registar um novo veculo no sistema.

30

d) Na sada, um funcionrio introduz novamente a matrcula, sendoque o sistema calcula o custo do estacionamento.e) O Gestor do Parque precisa de consultar diariamente umalistagem dos estacionamentos. Em algumas situaes, o gestorpoder desempenhar as funes de atendimento, no entanto, apenaso gestor poder obter as listagens.

Soluo Biblioteca

1 - Identificao dos actores

No texto da entrevista existem dois actores que interagem/utilizamo sistema:Funcionrio - Pessoa responsvel por registar o emprstimo e geriros emprstimos em atraso.Aluno - Necessita de pesquisar os livros existentes.

2 - Identificao dos use cases por actor

ACTOR USE CASESFuncionrio Registar Emprstimo

Consultar Emprstimos AtrasadosAluno Pesquisar Livros

3 - Desenhar o diagrama de use cases

Consultar EmprstimosAtrasados

Aluno31

ital de UML Diagrama de Use Cases

Soluo Alternativa " " fn"n'f.i-':-^u-i r uj ^-aa^fU.- - - i---". : : ; , ; > er r . i i i . ' . - . '

A primeira soluo no tem em considerao relaes entre os usecases e tambm no demonstra que na pesquisa tem que sermostrada a data de entrega quando um livro est emprestado.Sendo assim, o diagrama seguinte inclui este use case.

Consultar EmprstimosAtrasados

Funcionrio

Aluno

Possvel descrio simplificada para o use case "PesquisarLivro" (repare no extend):1. O aluno introduz a sua expresso de pesquisa.2. O sistema procura em cada livro a expresso.3. Caso o livro possua a expresso de pesquisa, a sua referncia acrescentada lista de livros a devolver.4. Caso um livro esteja emprestado, acrescenta a data de entrega.

a. Extend: Retorna data entrega.5. A lista de referncias devolvida ao utilizador.

Soluo Parque de Estacionamento

Identificao dos actores e use cases

ACTOR USE CASESFuncionrio Registar Entrada (se matrcula

reconhecida, criar novo veculo)Registar Sada

Gestor do Parque Listagem dos Estacionamentos

Diagrama de use cases

no

O

FuncionrioA

Gestor do Parque

S.I. Parque Estacionamento

Listagem dosVEstacionamentosy

32

Fundamentai de UML r Diagrama de Use CasesSoluo Alternativa ' ;

A primeira soluo no tem em considerao relaes entre os usecases e tambm no demonstra que na pesquisa tem que sermostrada a data de entrega quando um livro est emprestado.Sendo assim, o diagrama seguinte inclui este use case.

Consultar EmprstimosAtrasados

Funcionrio

Aluno

Possvel descrio simplificada para o use case "Pesquisa:Livro" (repare no extend):1. O aluno introduz a sua expresso de pesquisa.2. O sistema procura em cada livro a expresso.3. Caso o livro possua a expresso de pesquisa, a sua refernciaacrescentada lista de livros a devolver.4. Caso um livro esteja emprestado, acrescenta a data de entrega.

a. Extend: Retorna data entrega.5. A lista de referncias devolvida ao utilizador.

Soluo Parque de Estacionamento

Identificao dos actores e use cases

ACTORFuncionrio

Gestor do Parque

USE CASESRegistar Entrada (se matrculareconhecida, criar novo veculo)Registar SadaListagem dos Estacionamentos

no

Diagrama de use cases

S.l. Parque Estacionamento

Registar Entrada

Registar Sada ) f Cria Novo Vecu|o

Listagem dosEstacionamentos

FuncionrioA

Gestor do Parque

32 33

Diagrama de Classes 33,1 E

A UML adoptou tambm o diagrama de classes, uma das tcnicasmais utilizadas no desenvolvimento orientado por objectos. Estediagrama uma descrio formal da estrutura de objectos numsistema. Para cada objecto descreve a sua identidade, os seusrelacionamentos com os outros objectos, os seus atributos e as suasoperaes.

A criao de um modelo de classes resulta de um processo deabstraco atravs do qual se identificam os objectos (entidades econceitos) relevantes no contexto que se pretende modelar e seprocuram descrever caractersticas comuns em termos depropriedades (atributos) e de comportamento (operaes). A essadescrio genrica designa-se por classe. Assim, as classesdescrevem objectos com atributos e operaes comuns, e servemdois propsitos: permitem compreender o mundo real naquilo que relevante para o sistema de informao que se pretendedesenvolver e fornecem uma base prtica para a implementao emcomputador (Rumbaugh et ai, 1991).

Os diagramas de classes descrevem o modelo geral de informaode um sistema. Os diagramas de objectos podem ser utilizadoscomo exemplo para ajudar a compreender um diagrama de classescomplexo.

Um diagrama de classes composto pelos seguintes elementosabstractos de modelao:

35

Fundamental de UML

Classes de objectos Relaes de Associao Multiplicidade

'alizao

A perspectiva esttica fornecida pelo diagrama de classes temcomo objectivo suportar os requisitos funcionais do sistema, queforam levantados previamente (tema abordado no Captulo 2).Assim, o diagrama de classes um resultado da anlise derequisitos, fornecendo um modelo que mais tarde ser utilizado nafase de desenho para a definio dos componentes da aplicao.

Tipicamente, o diagrama de classes utilizado no seguinteconjunto interdependente de formas (Booch et ai., 1999):

1. Modelar o vocabulrio de um sistema: Envolve o decidir sobre que abstraces estruturais (aspectos mais

importantes) fazem parte do sistema em estudo e quaisesto fora das suas fronteiras.

2. Modelar colaboraes simples: Visualizar o sistemacomo um todo constitudo por classes e suas relaesque, atravs do seu trabalho em conjunto, fornecem umcomportamento cooperativo.

3. Modelar o esquema lgico de uma base de dados(BD): Desenhar a estrutura de dados para uma BDrelacional ou orientada por objectos, de forma a guardara informao do sistema.

Neste captulo os diagramas so elaborados na perspectiva demodelar as classes do sistema e as suas relaes. Aproveitando oexemplo apresentado no Captulo 2, poderamos acrescentar aseguinte descrio:

"Um cliente pode efectuar muitas encomendas, contendocada encomenda diversos itens, numerados sequencialmente,que se referem a um determinado produto e respectivaquantidade encomendada. Os produtos vendidos pela

Diagrama de Passes

PhonePizza abrangem pizzas com diversos tamanhos(Pequena, Mdia e Grande), bebidas e saladas. O preo podevariar conforme o tamanho do produto bem como com aspromoes existentes que tm uma data de incio e de fim."

A fig. 3.1 apresenta um possvel diagrama de classes simplificadopara o problema.

KRestries:Preo.tipoPreco={Normal, Promoo}Preo.tamanho={nico,Pequeno, Mdio, Grande}

"Jl . FIGURA 3,1- EXEMPLO DIAGRAMA DE CLASSES

Existem pormenores como os diversos tipos de produto ^associaes que s so demonstrados nos tpicos avanados dodiagrama de classes. Os principais conceitos so explicados "mseguida.

em

Fundamental de UML

3.1.1 O que um ObjectoUm objecto uma entidade ou conceito existente no contexto demodelao (mundo real). Que relevante incorporar no modelo deinformao. caracterizado por um conjunto de Propriedades, umComportamento e Identidade. As Propriedades so ascaractersticas que definem o objecto, transpostas para um conjuntode atributos, cujos valores estabelecem o Estado do objecto. OComportamento definido como as operaes que o objecto podeefectuar. A Identidade permite identificar um objecto emparticular como nico num conjunto de objectos semelhantes. Porexemplo, podemos ter os seguintes objectos:

Carro C

FIGURA 3,2 - EXEMPLO DE OBJECTOS CARROO carro A diferente do carro B e C, contudo todos eles possuemum conjunto de atributos (Numero de Srie, Cor, Datade Fabrico, etc.) que os definem (Estado) e realizam operaescomo de "Iniciar Marcha" ou "Acelerar"(Comportamento). E, para alm de algumas semelhanas, possuemuma identidade prpria que os torna nicos.

A mesma caracterizao pode ser aplicada para os clientes de umaloja, por exemplo:

Cliente X Cliente Y Cliente Z

38FIGURA 3,3 - EXEMPLO DE OBJECTOS CLIENTE

Os diversos objectos cliente tambm partilham as mesmaspropriedades como o Nome, Morada, Data de Nascimento, NmeroBilhete de Identidade, Sexo, etc. O mesmo para o comportamento,pois todos tm que se registar como clientes ("registar") oupodem actualizar os seus dados pessoais ("alterarDados").

3.1.2 O que uma Classe

Representa uma abstraco sobre um conjunto de objectos quepartilham a mesma estrutura e comportamento. Na prtica, umobjecto um caso particular de uma classe, tambm referido comouma instncia da classe.

No exemplo anterior poderamos resumir os diferentes objectosnum conjunto de propriedades e operaes comuns (fig. 3.4):

Cliente X : Clientebi = 1242454nome = Joomorada = Rua XdtNasc = 03/08/74

Cliente Y : Clientebi = 1233424nome = Mariamorada = Rua YdtNasc = 05/06/78

Cliente Z : Clientebi = 11234454nome = Marcomorada = Rua XdtNasc = 26/09/80

FIGURA 3,4 - RESUMO DE PROPRIEDADES E COMPORTAMENTO

Sendo descritos na seguinte classe Cliente:

Nome da Classe

Atributos

Operaes

FIGURA 3.5 - CLASSE CLIENTE

39

Fundamentai de U_Mj-_ Diagrama de Classes

As instncias da classe (objectos) podem ser representadasseguinte forma: K

Contm o nome do objecto e daclasse separados por":" e sublinhado

"b.O nome dos atributos evalor so mostrados.

FIGURA 3.6 - INSTNCIA DE UMA CLASSE (OBJECTO)Um atributo uma caracterstica que os objectos possuem e que representada por um valor de dados. Por exemplo, o atributo Corpoder ser igual a "Vermelho" ou "Azul". Os nomes dos atributosso nicos numa classe, no podendo existir na mesma classe doisatributos com o mesmo nome. Em classes diferentes podem existiratributos com nomes iguais.

Os objectos apenas comunicam entre si por mensagens, que naprtica resulta na invocao de operaes. Este conceito explorado em detalhe no Captulo 5. As operaes so arepresentao lgica do comportamento de um objecto, consistindoem aces efectuadas por ou sobre um objecto. Em alternativa,tambm se pode definir operaes como servios disponibilizadospor um objecto. Estes servios sero invocados por outros objectoscomo parte integrante de uma colaborao (a modelao dacolaborao abordada no Captulo 5).

Na classe Cliente pode-se definir a operaocalcularldade ( ) . A UML utiliza parntesis para simbolizar aexistncia ou no de parmetros. Para a operao anterior poderia'ser necessrio fornecer a data actual, o que implicaria definir aoperao como calcularldade (dtActual). Uma operaotambm pode possuir um valor de retorno, que no exemplo anteriorcorresponderia no retorno da idade do cliente. O nome, osparmetros e valor de retorno da operao constituem a supublicaes?

J.A.: Para os livros temos que registar o seu nmero deidentificao internacional, ISBN, e para as revistas registamos asua periodicidade."

parque de Estacionamento

Considere a seguinte informao adicional descrio apresentadano exerccio 2.2.2. Esta informao um resumo das entrevistasconduzidas na empresa concessionria do parque deestacionamento.- Em cada veculo apenas interessa guardar no sistema a respectivamatrcula.- Um veculo pode efectuar vrios estacionamentos no mesmo dia.- Os veculos podem ser automveis ou motorizadas.- De incio existe uma tarifa base que aplicada a todos osveculos. Contudo, para veculos com um elevado nmero deestacionamentos, possvel criar tarifas especficas. Cada tarifapossui um custo por hora.- O estacionamento possui um nmero de lugares limitado. Oslugares so caracterizados por um nmero, piso e um estado. Esteestado s pode assumir os valores de Livre ou Ocupado.

Soluo Biblioteca

1 - Identificao dos objectosOs seguintes objectos so identificados:

PublicaoLivroRevistaAutorrea da publicaoFicha de Emprstimo

2 - Identificao das classesPublicaoLivro

54

Fundamental de UFiL

Revista

Fundamental de UML Diagrama de Actividades

programa. Face aos fluxogramas tradicionais, o diagramaactividades apresenta a vantagem de permitir descrever com rigcfluxos de processamento de actividades em paralelo, bem comoatribuir a uma classe responsabilidade pela execuo de uractividade.

Cada um dos diagramas propostos pela UML permite modelaraspecto especfico do sistema e deve ser utilizado em complement|com os outros diagramas. Esta nota serve para realar utilizacpor vezes indevidas do diagrama de actividade.

Assim, um diagrama de actividades no deve ser utilizado pdemonstrar colaborao entre objectos. Neste caso um diagramasequncia ou de colaborao mais apropriado. Um diagramaactividades tambm no deve ser utilizado para descrevercomportamento de um objecto ao longo do tempo, o que deve sefeito atravs de um diagrama de estado.

Estas utilizaes indevidas so por vezes frequentes naqueles que*possuem grande experincia em anlise estruturada e que utilizam!o diagrama de actividades para modelar decomposio funcionalJsem o enquadrarem nos princpios da modelao orientada por|objectos.A utilizao dos diagramas de actividades no contexto do lparadigma dos objectos requer uma certa disciplina. Um dosprincpios fundamentais dos objectos a integrao de atributos ecomportamento. A utilizao correcta de um diagrama dejactividades exige que se identifique qual o objecto responsvel pelarealizao de cada uma das actividades. Tal pode ser possvel]identificando junto de cada uma das actividades qual o objecto]responsvel. Uma forma alternativa de identificao deiresponsabilidade a utilizao de linhas verticais ("swimlanes"}\que enquadram as actividades que ficam associadas a cada objecto.

Considerando o exemplo da PhonePizza que temos vindo a utilizarpensemos no use case "Processar Encomenda na Pizzaria":

"O cliente dirige-se ao balco e pede ao funcionrio umconjunto de produtos que pretende. O funcionrio vaitomando nota do pedido, verificando se o produto est nalista de produtos comercializados e se existe em stock. Nocaso do produto no existir, informa o cliente. Se fordetectada uma rotura de stock, enviada uma mensagem aoGestor de Loja para encomendar o produto em falta e ofuncionrio sugere um produto alternativo. Se o produtosolicitado no pertencer lista dos que so vendidos napizzaria, o funcionrio sugere igualmente um produtoalternativo.

Aps o cliente ter concludo a sua encomenda, determinadoo valor da encomenda e solicitado o pagamento. Se opagamento for vlido, a encomenda entregue ao cliente.Caso contrrio, a encomenda cancelada."

O diagrama de actividades que se apresenta na figura 4.1 descreveeste use case. Neste diagrama so utilizados os seguintes elementosde modelao:

Linhas verticais de responsabilidadeActividades de Incio e de Fim

- Actividade intermdia* Transio de actividade e smbolos de comportamento

condicional

Cada um destes elementos explicado detalhadamente nos pontosseguintes.

Fundamental de UML

Gestor de Loja

Inicia Encomenda j

* Processa Item [ Para cada Item l / Pede o nome do produtoDeciso

(Divergncia)

Sugere reaprovisionamentc[Rotura de Stock Produto no includo na lista l \. [ Produto disponvel l

i Produto na EncomendaSugere Produto AlternativoReaprovisiona Produto

Prepara Encomenda

Apura valor da |Encomenda l

[ Recusado ]Recebe Pagamento ) ^f Cancela Encomenda

[ Stock atribudo a todos os itense pagamento efectuado ]

[ Expedio de Encomenda

FIGURA 4,1 - EXEMPLO DIAGRAMA DE ACTIVIDADES

_Djaflrama_cfe.Actjyjdades

4.1.1 Linhas verticais de responsabilizao

Atravs da utilizao das linhas verticais de responsabilidade, possvel descrever quais so os objectos responsveis por cada umadas actividades. No diagrama da fig. 4.1 podemos identificar que oGestor de Loja responsvel pelo reaprovisionamento e oFuncionrio pelas restantes actividades representadas nodiagrama.

4.1.2 Actividades

Num diagrama de actividades necessrio identificar a actividadeinicial. Esta actividade pode ser puramente virtual, definida paraidentificar o incio do diagrama, ou corresponder a uma actividadeoperacional do sistema. Uma actividade inicial descrita por umcrculo preenchido a negro.

Uma actividade operacional descrita graficamente por umrectngulo de lados arredondados com um identificador. Umaactividade permite descrever um conjunto de aces, que sorealizadas quando a actividade se inicia, durante o seu decursonormal, e quando termina. Numa actividade podemos aindadescrever a ocorrncia de eventos excepcionais.

Atendeentry/ Cumprimenta clientedo/ Informa sobre a promoo da semanaexit/ Pergunta o que desejaon Pedido do Gestor da Loja( Mensagem )

[ No existirem clientes em fila de espera ]/ Executa tarefa/

FIGURA 4,2 - ACTIVIDADE

Fundamental de UML

Na figura 4.2 identificam-se as aces que so realizadas naactividade Atende Cliente, atravs da utilizao dosdescritores "entry/", "do/" e "exit/". Neste caso,

0funcionrio comea por saudar o cliente, em seguidainforma-o sobre a promoo da semana e, por fim, pergunta-lhe oque deseja.

No decurso de uma actividade pode ser realizada uma aco emresposta a um evento exterior. Por exemplo, o Gestor daPi z z ar i a pode transmitir uma mensagem ao Funcionriopara realizar uma determinada tarefa, desde que no existamclientes em fila de espera. Esse evento encontra-se descrito nafigura associado ao descritor "on event /":

on Pedido do Gestor da Loja(Mensagem)[No existem clientesem fila de espera]/Executa tarefa

Para identificar uma actividade terminal de um fluxo de trabalhoutiliza-se um crculo a preto, limitado com uma circunferncia.Num diagrama de actividades s existe uma actividade inicial, maspode existir mais do que uma actividade terminal.

4.1.3 Transio entre actividades

Uma transio permite descrever a sequncia pela qual asactividades se realizam (fig. 4.3):

IniciaEncomenda

'Processa item[ Para cadaV

item ] / Pede nome produto

FIGURA 4,3 - TRANSIO62

A transio entre actividades representada por uma seta. Natransio podem ainda ser listados os eventos, aces e condies,com a seguinte sintaxe:

Evento (argumentos) [condio] / Aco Aalvo.algumEvento (args)

A transio Processa Item repete-se para cada um dosprodutos que o cliente pretende adquirir. Esta funcionalidadedesigna-se por concorrncia dinmica e permite representar asiteraes atravs do smbolo * , que aparece junto do identificadorda transio, sem ter de construir um ciclo.

4.1.4 Comportamento condicional

Num fluxo de actividades podem existir caminhos alternativos.Para representar o fluxo de controlo num diagrama de actividadesutilizam-se "guardas" e diamantes de deciso.

Guardas so expresses booleanas limitadas por parntesis rectos[ ] , que tm de ser verificadas para se realizar a transio para umanova actividade.

Nos diagramas de actividade podem igualmente ser utilizadossmbolos, em forma de diamante, para representar caminhosalternativos baseados numa expresso booleana (condio). Osdiamantes de deciso, que so semanticamente equivalentes amltiplas transies com guarda, devem ser utilizados paraaumentar a legibilidade do diagrama. Estes smbolos podem serutilizados para descrever uma divergncia (branch) ou umaconvergncia (merg) no fluxo de controlo.

Um diamante de deciso que representa uma divergncia no fluxode controlo, possui uma transio de entrada e duas ou maistransies de sada. Um diamante que representa uma convergnciapossui uma ou vrias transies de entrada e uma transio desada. Os diamantes de deciso devem ser utilizados de forma

63

Fundamenta!_de_yML_

equilibrada. Se for utilizado um smbolo para representar um pontode divergncia, dever existir um outro smbolo para representar aconvergncia no fluxo de controlo das actividades.

No diagrama da figura 4.4 utilizam-se guardas e smbolos dedeciso para controlar quais as actividades que devem ocorrer, face existncia ou indisponibilidade do produto para satisfazer aencomenda.

Inicia Encomenda

* Processa Item [ Para cad^ Item ] / Pede o nome do produto

Sugere reaprovisionamento[Rotura de Stock

FIGURA 4,4 - DECISO E GUARDA

4,2 TPICOS AVANADOSNo mbito dos diagramas de actividades poderemos identificalguns aspectos que constituem tpicos avanados, designa-damente:

Agrupamento e decomposio de actividadesProcessamento paraleloFluxo de objectos no diagrama de actividades

4.2.1 Agrupamento e decomposio de actividades

^ UML permite que um conjunto de subactividades possam seragrupadas numa superactividade ou que uma actividade possa serdecomposta num conjunto de subactividades.

1 Processa Item

k Inicio

Sugere reaprovisior/amento[ Roturade stok ] "

' Reaprovisiona^produto

/ -,'t produto noinclufdo na lista] x^E Produto disponvel ]

Sugere produto ^alternativo J

Inclui produto \x na encomenda/

i\Fim

; FIGURA 4.5 - ACTIVIDADES AGRUPADAS

A figura 4.5 apresenta um exemplo em que se optou por agrupar asactividades Sugere Produto Alternativo e IncluiProduto na Encomenda numa actividade designada porProcessa Item. Nesta situao podemos representar nodiagrama geral as subactividades includas na superactividadeProcessa Item, ou criar um diagrama especfico para

|| representar o detalhe da actividade Proces s I tem.lS O identificador da actividade Processa Item vem antecedidoQ de um * pelo facto de se repetir para cada um dos itens da

l Q encomenda. No diagrama que representa as subactividades,optamos por representar explicitamente uma actividade inicial euma actividade final, permitindo, deste modo, que a actividade

64 65

Fundamental de UML

Processadiagramas.

Item possa ser utilizada autonomamente noutros

4.2.2 Processamento paralelo , -. \ : ,1 ' . - ( . . i j.,,;. ' ,1 j

Um aspecto relevante na capacidade de modelao dos diagramasde actividade a possibilidade de representar fluxos de actividadesque se desenvolvem em paralelo. Esta possibilidade particularmente til na descrio de processos organizacionais,porque ajuda a identificar oportunidades para aumentar a eficinciado processo, atravs da realizao de actividades em paralelo.

ProcessaItem

/ PreparaV Encomenda

Apura valor da iencomenda

[ Stock atribudo a todos os itens epagamento autorizado ]

Expedio de \Encomenda J

FIGURA 4,6 - PROCESSAMENTO PARALELO DE

Para descrever processamento paralelo so utilizadas barrashorizontais. Estas podem assumir dois papis: marcar um ponto dedivergncia (fork), a partir do qual duas ou mais tarefas se podem

Diagrama de Actividades

iniciar em paralelo, ou permitir sincronizar (joir) tarefas que tmde estar concludas para que se inicie uma nova tarefa (ponto deconvergncia) . Num diagrama de actividades uma barra dedivergncia deve ser compensada com uma barra de convergncia.

Na figura 4.6 representa-se o facto de se poder efectuar apreparao da encomenda em paralelo com o apuramento do valore a concretizao do pagamento.

Conceptualmente, esta representao descreve o facto de oconjunto de actividades pertencentes a cada um dos braos do fluxopoderem ser executadas em simultneo, ou sequencialmente, aindaque no exista uma ordem estabelecida. Assim, poder-se- proceder preparao da encomenda e, posteriormente, ao apuramento dovalor e pagamento ou vice-versa.

4.2.3 Fluxo de objectos

A interveno de objectos para a realizao das actividades podeser representada colocando estes objectos nos diagramas e ligando--os actividade atravs do smbolo de dependncia. Na figura 4.7exemplifica-se esta situao tomando como referncia a actividadePrepara Encomenda que necessita do objecto e:Encomenda.

u1-1 'FIGURA 4.7 - FLUXO DE OBJECTOS NO FLUXO DE CONTROLO

66 67

4.2.4 Diagrama de actividades revisto

Em seguida, apresentada, na figura 4.8, uma actualizao dodiagrama de actividades para o use case "Processar Encomenda naPizzaria", utilizando os conceitos mais avanados.

Stock atribudo a todos os itense pagamento efectuado ]

FIGURA 4,8 - EXEMPLO DIAGRAMA ACTIVIDADES AVANADOA principal diferena entre este diagrama e o diagrama apresentadoinicialmente (fig. 4.1) est no agrupamento de actividades naactividade Processa Item, utilizao do processamento

paralelo e introduo do objecto e: Encomenda na actividadeprepara Encomenda.

Deve-se sempre comear com um diagrama de actividadessimples para ter uma ideia geral do processo.Eventualmente, processos mais complexos podem serrepartidos por vrios diagramas.

4.3

4.3.1 Perguntas de Reviso

Qual a finalidade de um diagrama de actividades?Identifique duas caractersticas distintivas dos diagramas deactividades como instrumentos de modelao.

Quais os elementos de modelao que so utilizados numdiagrama de actividades?

Como se descreve num diagrama de actividades o princpio daresponsabilidade de um objecto pela realizao das operaes?

: Qual a notao utilizada para caracterizar uma actividadeinicial?

: Caracterize os diversos elementos que so utilizados paradescrever uma actividade operacional.

Quantas actividades iniciais e terminais poderemos colocar numdiagrama?

Que elementos podem ser listados numa transio entreactividades?

8 6

utilizados numcomportamento

9: Que elementos de modelao podem serdiagrama de actividade para descrevercondicional?

10: possvel efectuar o agrupamento e a decomposio deactividades? Exemplifique de que forma o faria?

11: Que elementos so utilizados para modelar a execuo deactividades em paralelo?

12: Como se representa a interveno de objectos para a realizaodas actividades?

4.3.2 Problemas Resolvidos iDesenhe os respectivos diagramas de actividades de acordo com asdescries seguintes.

Biblioteca

Considere os seguintes requisitos para o processo dedisponibilizao de obras que foram definidos pelo responsvel dabiblioteca.

Os leitores, professores ou alunos, interessados na consulta de umaobra no disponvel na Biblioteca podem apresentar uma sugestode aquisio ao responsvel.Regularmente as listas com as publicaes sugeridas so enviadaspara os fornecedores com um pedido de proposta de fornecimento,que deve incluir prazo de entrega e preo.As propostas dos fornecedores so analisadas e, em funo dospreos e do oramento disponvel, sero seleccionadas as obras aadquirir. A biblioteca estabeleceu critrios que do prioridade aquisio de obras formativas, que faam parte da bibliografia dasdisciplinas do sistema de ensino. Aps ter sido definida a lista deobras a adquirir, so enviadas notas de encomenda para osfornecedores seleccionados. As obras entregues pelos fornecedores

M

so verificadas no momento da recepo, sendo confrontadas asguias de remessa com as notas de encomenda, de modo a assegurara consistncia com a encomenda efectuada.Aps a catalogao e registo de cada obra no sistema deinformao de gesto da biblioteca, enviada uma notificao aosleitores que propuseram a sua aquisio. As novas obras socolocadas num expositor especial de divulgao, durante umperodo de 2 semanas, antes de serem arrumadas na respectivaprateleira. A partir desse momento a obra fica disponvel para seremprestada.

Parque de Estacionamento

Uma anlise do controlo de entrada de viaturas no parque sugeriualgumas melhorias que poderiam ser introduzidas, no sentido detornar o processo mais eficiente.

Um objectivo simplificar a tarefa do funcionrio que tem aresponsabilidade de registar a matrcula dos veculos. A adopo deuma tecnologia de reconhecimento de imagens permite que seja osistema de informao a visualizar, reconhecer e registar amatrcula de fornia automtica. Assim, o processo passa a incluir asseguintes actividades:

O sistema de informao detecta a presena do veculo junto cancela de entrada. Se existir lugar vago no parque, identifica amatrcula do veculo, regista a entrada e emite o bilhete. Quando ocondutor retira o bilhete, o sistema de informao abre a cancela equando detecta a passagem do veculo, incrementa o contador delotao e fecha a cancela.

Fundamental de UML

Soluo Biblioteca

Leitor

Sugere Aquisio

f Recebe Notificao j

Bibliotecrio

Solicita Proposta

\/

Analisa Propostas

\/Estabelece Lista de Aquisies

v Envia Nota de Encomenda

v Recepciona Encomenda

-l Envia Notificao

Livreiro

Elabora Oramento

Satisfaz Encomenda

Diagrama de Actividades

Soluo Parque de Estacionamento

72 73

Diagramas de Interaco

5,1 E APLICAOModelar a dinmica de um sistema fundamental para dominar asua complexidade e compreender as suas particularidades. Osdiagramas de interaco so utilizados na UML para modelar osaspectos dinmicos do sistema em termos dos objectos e suasinteraces, tendo como base as mensagens trocadas entre objectos.Booch et ai (1999) definem uma interaco como umcomportamento que consiste na troca de um conjunto demensagens entre objectos, dentro de um contexto, para atingir umobjectivo.

Os diagramas de interaco permitem definir e clarificar acolaborao entre as classes do sistema. Normalmente, soutilizados para ilustrar o comportamento do sistema num cenrio deconcretizao de um use case.

frequente utilizar diagramas de interaco em conjunto com adescrio textual dos use cases, pois facilitam a sua compreensoao fornecer uma representao grfica das interaces entre osobjectos.

Diagrama de interaco uma designao genrica que na UML seH aplica a diagrama de sequncia ou diagrama de colaborao. Umi diagrama de sequncia apresenta as interaces entre objectos a

Partir do encadeamento temporal das mensagens. Um diagrama decolaborao descreve as mesmas interaces mas centradas nosbjectos intervenientes. Estes diagramas podem ser desenhados

L com vrios nveis de detalhe e ao longo das diversas etapas doProcesso de desenvolvimento do sistema.

75

Fundamentai de UML

Um diagrama de interaco composto pelos seguintes elementojabstractos de modelao: "**" . . - . . , , , .

Objectos* Ligaes (links)* Mensagens

Por exemplo, vejamos o seguinte descrio para oPhonePizza:

"Para que o cibernauta possa efectuar encomendas atravs daInternet este ter que efectuar um pr-registo onde indicar oseu nome, morada, nmero de telefone, username epassword. O pr-registo ser confirmado atravs de umcdigo de acesso que ser enviado por correio electrnico. Ocdigo ser utilizado uma nica vez pelo cliente para activaros servios de encomenda pela Internet."

Esta descrio caracteriza o use case "Pr-registo peleInternet". Um cenrio de registo tpico ser utilizado paraapresentar os diagramas de interaco.

Cada um dos diagramas explicado detalhadamente em seguida.

5,2 DE

Na figura 5.1 apresentado o diagrama de sequncia para o usecase "Pr-registo pela Internet".

O diagrama de sequncia um diagrama de interaco que realaa ordem cronolgica das mensagens entre objectos.

OObjectos

Cibernauta A: Ecr Pr-Registo Cliente A Cliente

CD

ao

geraCodigoAcessoQ

FIGURA 5,1 - DIAGRAMA DE SEQUNCIA: PR-REGISTO

5.2.1 Mensagens

As mensagens trocadas entre objectos representam a invocao deum servio (operao) disponibilizado por um objecto, com oobjectivo de despoletar uma aco ou actividade. Uma definiomais formal descreve uma mensagem como a especificao dacomunicao entre objectos.

^ O tipo de mensagens pode ser sncrono, assncrono, simples ou del retorno. Uma mensagem sncrona significa que o objecto emissors fica suspenso espera de uma resposta, retomando posteriormente| o controlo. Utiliza-se esta mensagem quando o objecto emissor| necessita de dados provenientes do objecto receptor, para continuar^ o seu processamento.

76 77

Fundamental de UML

Por outro lado, uma mensagem assncrona permite opera?emissora prosseguir o seu processamento. Este tipo de mensagens particularmente til para ilustrar sistemas com processosconcorrentes, como o caso do exemplo apresentado na fig. 5.4.

A mensagem simples utiliza-se quando ainda no est definido otipo da mensagem ou este tipo no relevante.

Por fim, a mensagem de retorno utilizada para ilustrar o retornoda mensagem enviada que poder ser um valor ou um sinal. Paramensagens simples ou sncronas est implcita a existncia de umretorno, sendo a sua representao opcional. No entanto, paramensagens assncronas deve-se representar a mensagem de retorno.

A figura 5.2 ilustra a notao grfica para os diferentes tipos demensagens.

SimplesRetorno

SncronaAssncrona

Diagramas de Interaco

FIGURA 5,2 - TIPOS DE MENSAGENS

As mensagens podem despoletar vrios tipos de aco no objectoreceptor. A UML define os seguintes tipos de aco para asmensagens:

Call - Invoca uma operao de um objecto. Este tipo5!mensagem pode ser enviada ao prprio objecto.

Return - Retorna um valor para o objecto emissor paramensagens sncronas ou um sinal para mensagens assncronas.

* Send - Envia um sinal a um objecto. Create - Cria um objecto. Destroy - Destri um objecto;O tipo de aco mais frequente o Call, utilizado em mensagenssncronas. O tipo Send utilizado em mensagens assncronas-

Apenas os tipos Create e Destroy so explicitamente ilustrados nasmensagens, todas as outras esto implcitas ao tipo de mensagem.

5.2.2 Linha temporal e controlo

Isfo diagrama de sequncia existe uma linha temporal queacompanha o ciclo de vida dos objectos, onde tambm pode serrepresentado o intervalo de tempo. Neste intervalo, o objecto tem ocontrolo para processamento e envio de mensagens. A figura 5.3reala estes conceitos ilustrando um excerto do exemploapresentado inicialmente na figura 5.1.

Cliente A Cliente

geraCodigoAcesso()

g ; FIGURA 5.3 - LINHA TEMPORAL E CONTROLOl Sempre que um objecto envia uma mensagem, tem que possuir os controlo. Este poder estar sempre presente ou existir apenas5 quando ocorre algum processamento no objecto. possvel impor| urna restrio temporal entre o envio de uma mensagem e aj respectiva resposta. Neste caso, no pode ultrapassar os 3*

segundos.

78

Fundamental de UML

No caso da fig. 5.3, o objecto de interface Ecr Pr-Registdienvia uma mensagem para o objecto Cliente, para que um novocliente seja criado. O objecto Cliente, por sua vez, envia umamensagem a si prprio para que seja gerado um cdigo de acesso(repare na linha dupla de controlo). Findo este processamento, enviado para o objecto de interface uma mensagem de retorno.Na figura 5.4, o diagrama de sequncia utilizado para ilustrar ocenrio em que um cliente cria uma encomenda, adiciona itens econfirma a encomenda. Neste caso, um objecto Cliente cria umanova encomenda, usando a mensagem com o esteretipocreate.

O processo de adicionar produtos encomenda repetido para cadaproduto a adicionar, por isso utilizado um asterisco (*) comosmbolo de iterao. Este processo requer o envio de umamensagem adicionaProduto ( ) ao objecto Encomenda, quepor sua vez ir adicionar o produto encomenda aps a consulta dorespectivo preo atravs da mensagem devolvePreo ( ) .

Por fim, o cliente confirma a encomenda enviando a mensagemconfirmaEncomenda() ao objecto Encomenda. Estamensagem apenas ser enviada se o nmero de itens/produtosadicionados encomenda for superior a zero.

Por vezes, necessrio introduzir uma condio no diagrama. Paratal, especifica-se a condio entre parntesis rectos perto da linhade controlo como, por exemplo, na figura 5.4 utilizada a condio[nmero i tens>0], que significa que uma encomenda ser

registada apenas se contiver pelo menos um item/produto. Deforma a demonstrar que um conjunto de mensagens so enviadas deacordo com uma condio, pode-se utilizar uma separao na linhade controlo. A figura 5.5 ilustra esta alternativa.

No se deve representar muitas condies no diagrama desequncia, pois corre-se o risco de o complicar.

o

o

: Cliente

Iterao:para cada produto

a adicioanar

create

,*: adicionaProdutoO

confirmaEncomendaQ

devolvePreo()

calculaTotal()

[nmero itens>0]

FIGURA 5,4 - DIAGRAMA DE SEQUNCIA: EFECTUAR ENCOMENDA

\ [condio]mensagem1()

mensagem2()

mensagemSO

Separao da linha de contnde acordo com uma condio.

FIGURA 5.5 - SEPARAO DA LINHA DE CONTROLO80 81

Fundamental de UML

5.2.3 Processamento em paralelo

A utilizao de mensagens assncronas permite efectuar diagramasde sequncia onde so enviadas mensagens para objectos distintosque estaro a correr em paralelo.

Por exemplo, no diagrama de sequncia para o controlo de acessos(figura 5.6), o objecto Controlo Acesso, ao receber umamensagem verif icaAcesso ( ) , cria dois outros objectos queiro correr em paralelo para verificar as permisses do utilizadornos objectos e operaes do sistema. A mensagem que pede averificao (verifica ( ) ) assncrona, sendo assim a operaoemissora pode continuar o seu processamento.

Diagramas de Interaco

82FIGURA 5,6 - DIAGRAMA DE SEQUNCIA: CONTROLO DE ACESSC

\ medida que cada verificao de permisses vai terminando enviado um sinal ao objecto Controlo Acesso, que regista aseu resultado individual e remove o respectivo objecto depermisses, sendo representado por um sinal de destruio (X),cuja representao opcional (um objecto pode autodestruir-se).Quando o ltimo objecto de permisses termina, o resultado globalda verificao de acesso retornado.

5.2.4 Interface com o utilizador

Nem todos os exemplos de diagramas de sequncia que foramapresentados possuem um objecto de interface que faa deintermedirio entre o utilizador e o sistema. De facto a suarepresentao opcional, mas ao seguir um cenrio de um use caseest implcita a existncia de uma interface. Estes objectos deinterface de utilizador tambm devem ser identificados,especificados e representados. Contudo, numa actividade de anliseapenas devemos estar preocupados em identificar a natureza dainterface, em particular como que um actor acede funcionalidade e que informao necessita. A especificaodetalhada da interface com o utilizador efectuada, posteriormente,numa actividade tipicamente de desenho. O Captulo 7 aborda estetema.

53 DE COLABORAONa figura 5.7 apresentado o diagrama de colaborao quedescreve o cenrio de realizao do use case introduzido no inciodo captulo. O diagrama de colaborao reala a organizao

j= estrutural dos objectos que enviam e recebem mensagens. Possui| uma equivalncia semntica com o diagrama de sequncia, nojjj entanto representa a informao de uma forma diferente. Enquantog que o diagrama de sequncia est rigidamente ligado varivell tempo, o diagrama de colaborao apenas demonstra a interacoj ntre os objectos.

83

Fundar

L\Objecto

1 : setDadosO

Pr-Reaisto Internet : Ecr Pr-Registo

Cibernauta A

Sequncia

KLigao

Mensagem

l l l

Fundamental de UML

A figura 5.8 mostra o diagrama de colaborao para o use c"Efectuar Encomenda" referido anteriormente. Na prtexiste uma equivalncia directa com o diagrama de sequn(figura 5.4).

5.3.4 Mensagens condicionais

Estas mensagens s so enviadas quando uma determinadacondio validada. Esta condio ilustrada entre parntesisrectos [ ]. Por exemplo, na figura 5.8 a mensagem 3:conf irmaEncomenda ( ) s ser enviada se a condio[nmeroltens>0] for vlida.

5.3.5 Sincronizao

Para sincronizar processos concorrentes utiliza-se um prefixo (/)de sincronizao que estabelece as mensagens que devem serconcludas antes do envio da uma mensagem. Este mecanismo demonstrado na figura 5.9.

Diagramas de Interaco

Sincronizao 1.2/1.5: registaQ-~1.4/1.6:regista()-

: PermissesOperaco^

/%*f&vz : PermissesObiecto

vfeste diagrama de colaborao a mensagem 1.5: registaOs enviada quando a i . 2 : ve r i f i ca ( ) terminar.

5.3.6 Objectos e ligaes O diagrama de colaborao tambm representa explicitamente aligao entre os objectos que deriva das associaes no diagramade classes.

No diagrama de classes as associaes representam a relao entreas diversas classes. Quando se concretizam as classes em objectos,a associao passa a ser representada por uma ligao querepresenta uma instncia da associao.

Quando existe uma ligao entre dois objectos estes podem trocarmensagens entre si. A figura 5.10 exemplifica esta equivalncia:

Classes eAssociao

Encomenda Refere

1

Produto

+devolvePreo()

Objectos eLigao

FIGURA 5.10 - TRANSIO PARA OBJECTOS E LIGAES

FIGURA 5.9 - DIAGRAMA DE COLABORAO: CONTROLO DE ACESSOS86 87

FundamentaLdeJJML

Nesta figura efectuada a transposio do diagrama de classes numcenrio de colaborao entre objectos, onde um objecto da classeEncomenda envia uma mensagem a um objecto da classeProduto.

5,4 CONSTRUO DE DIAGRAMAS DE INTERACOO cenrio principal de um use case um bom ponto de partida paraa construo de um diagrama de interaco. Deve-se estabelecer osobjectos que participam com os seus servios para alcanar afuncionalidade desejada no cenrio.Deve-se tambm tentar manter consistente a responsabilidadeindividual de cada objecto, aceitando apenas mensagens (fornecerservios) que estejam directamente relacionadas com o seu mbito.

Recomenda-se a utilizao de uma ferramenta CASE que faa umaintegrao automtica dos diagramas, permitindo associar umamensagem para um objecto a uma operao que este possui, oucriar uma nova. Caso seja criada uma nova operao, esta automaticamente reflectida na respectiva classe do objecto e, emconsequncia, na sua representao no diagrama de classes. Estemecanismo garante que existe consistncia entre os diversosmodelos.

Diagramas de Interacd^

5,5

5.5.1 Perguntas de Reviso

1: Explique o conceito de interaco?2: Quais so os elementos que compem um diagrama de

interaco?

3: Qual a funo principal de um diagrama de sequncia?4: Explique o conceito de mensagem?5: Que tipos de mensagem podem ser representados num diagrama

de sequncia?6: Explique o conceito de linha temporal e controlo?7: Qual a principal diferena entre um diagrama de colaborao e

um diagrama de sequncia?8: Em que consiste uma ligao num diagrama de colaborao?9: Como indicada a repetio num diagrama de interaco?10: Como ilustrada a criao de um objecto num diagrama de

sequncia?

11: Como ilustrada a destruio de um objecto num diagrama desequncia?

12: Como representada uma mensagem condicional?

88

Fundamentai de UML

5.5.2 Problemas Resolvidos \

Elabore o diagrama de sequncia para os seguintes problemas.

Dtaq r mas de Interaco

Primeiro identifique os objectos e as suas interaces.

Biblioteca

Considere a seguinte descrio para o cenrio principal do use caie"Registar Emprstimo".

Registar Emprstimo (Cenrio Principal)Pr-condioDescrio

CaminhosAlternativosPs-Condio

9. O use case comea quando o funcionrioselecciona a opo de Registar Emprstimo.

10. De acordo com a ficha de emprstimo,previamente preenchida pelo aluno, ofuncionrio comea por introduzir onmero do aluno.

11. Selecciona a opo Criar NovoEmprstimo. O sistema s permite criarnovos emprstimos se o aluno no excedeuo limite de 3 emprstimos.

12. O funcionrio introduz a cota da publicaoque ser emprestada.

13. O emprstimo formalizado e gravado nabase de dados atravs da opo Confirma.

O sistema volta para o ecr de registo deemprstimos. .

parque de Estacionamento

Considere a seguinte descrio para o cenrio principal do use case"Registar Entrada".

"Registar Entrada (Cenrio Principal)"pr^cndioDescrio

CaminhosAlternativosPs-Condio

1. O use case comea quando o funcionriointroduz uma matrcula no seu terminal.

2. Caso a matrcula no seja reconhecida, serefectuado o registo do novo veculo,a. Extends: Cria Novo Veculo

3. O funcionrio confirma o estacionamentopressionando a tecla Enter. O sistemaregista a data e a hora do incio doestacionamento.

Soluo Biblioteca

1 Identificao dos objectos

''RegistarDa descrio do cenrio principal do use caseEmprstimo" surgem os seguintes objectos:Funcionrio - Actor responsvel por despoletar o use case. A suarepresentao opcional.Ecr Registo Emprstimo - Representa a interface com o actor,onde este pode registar emprstimos de publicaes. Arepresentao deste objecto permite identificar as classesresponsveis pela interaco com os utilizadores.Emprstimo - Representa o emprstimo efectuado.

90 Si

Fundamentai de UML

Base de Dados - Representa a base de dados onde ser gravado oemprstimo.

2 Desenho do Diagrama de Sequncia

: f :.Funcionrio

Soluo Parque de Estacionamento

1 Identificao dos objectosDa descrio do cenrio principal do use case "RegistarEntrada" surgem os seguintes objectos:Funcionrio - Actor responsvel por despoletar o use case. A suarepresentao opcional.

Diagramas de Interaco

gera Estacionamento - Representa a interface com o actor, ondeeste pode registar estacionamentos. Emprstimo - Representa oemprstimo efectuado.Estacionamento - Representa um estacionamento que serregistado.Veculo - Representa um novo veculo que ser adicionado aosistema, caso este seja desconhecido.Neste problema optou-se por n