UNIVERSIDADE TECNOLGICA FEDERAL DO PARAN

PR

ANLISE E PROJETO OO & UML 2.0

Cesar Augusto Tacla

Departamento Acadmico de Informtica h t t p : / / w w w . d ai nf . c ef et p r . br / ~ t ac l a

O uso e reproduo desta apostila requerem autorizao expressa do autor.

SUMRIO
I INTRODUO ...................................................................................... 5 1 MODELO ................................................................................................. 5 2 UML ...................................................................................................... 5
2.1 3.1 3.2 4.1 4.2 Breve histrico ...................................................................................... 5 Anlise e projeto estruturados.................................................................... 6 Anlise e projeto orientados a objetos .......................................................... 7 Objeto ................................................................................................ 7 Classe ................................................................................................. 7

3 ANLISE E PROJETO ORIENTADOS A OBJETOS .................................................. 6 4 OBJETO E CLASSE ..................................................................................... 7 5 EXERCCIOS ............................................................................................. 8

II

NOO GERAL DE ANLISE E PROJETO OO .................................................. 9 1 VISO GERAL ........................................................................................... 9 2 ANLISE DE REQUISITOS ............................................................................. 9
2.1 2.2 3.1 3.2 3.3 3.4 3.5 Papel dos Casos de Uso na Anlise de Requisitos..............................................10 Casos de Uso ........................................................................................10 Diagramas de Interao ...........................................................................11 Refinamento do Diagrama de Classes ...........................................................12 Definir o Comportamento das Classes ..........................................................12 Implantao ........................................................................................13 Componentes do Sistema .........................................................................14

3 ANLISE E PROJETO .................................................................................11

4 Modelagem Estrutural e Comportamental ......................................................14

III

MODELO DE CASOS DE USO .................................................................... 16 1 DEFINIO .............................................................................................16 2 ATORES.................................................................................................16 3 CASOS DE USO ........................................................................................17
3.1 3.2 Descrio............................................................................................17 Fluxo de Eventos ...................................................................................17 3.2.1 Fluxo Bsico ...............................................................................18 3.2.2 Subfluxo ...................................................................................19 3.2.3 Pontos de extenso ......................................................................19 3.2.4 Fluxo Alternativo .........................................................................20 3.2.5 Diagrama de atividade...................................................................21 3.2.6 Cenrios ...................................................................................21 3.2.7 Realizaes de Casos de Uso............................................................22 Associao ..........................................................................................23 Incluso..............................................................................................24 Extenso.............................................................................................25 Generalizao/Especializao ...................................................................26 Dicas .................................................................................................29 Passos................................................................................................30

4 RELAES..............................................................................................22
4.1 4.2 4.3 4.4 5.1 5.2

5 MODELAGEM...........................................................................................29 6 EXERCCIOS ............................................................................................31

IV

ANLISE DOS CASOS DE USO ................................................................... 33 1 ANLISE ................................................................................................33 2 PADRO MVC ..........................................................................................35

3 PADRO OBSERVADOR...............................................................................37 4 CLASSES DE ANLISE.................................................................................37

4.1 Notao UML para Classes ........................................................................37 4.1.1 Atributos...................................................................................37 4.1.2 Mtodos ....................................................................................38 4.1.3 Esteretipos ...............................................................................38 Linhas Mestras ......................................................................................40

4.2

5 EXEMPLO ...............................................................................................40 6 EXERCCIOS ............................................................................................42

ESTUDO DA INTERAO ENTRE OBJETOS ................................................... 43 1 DIAGRAMA DE SEQUNCIA ..........................................................................43

1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 Tipos de mensagem................................................................................44 Linha da Vida .......................................................................................45 Ativao .............................................................................................45 Alt ....................................................................................................45 Opt ...................................................................................................46 Loop..................................................................................................46 Ref ...................................................................................................47 Criar e destruir .....................................................................................48 Linhas Mestras ......................................................................................48

2 3 4 5

DIAGRAMA DE COMUNICAO......................................................................49 EXEMPLO ...............................................................................................50 PACOTES ...............................................................................................50 EXERCCIOS ............................................................................................51

VI

RELAES ENTRE CLASSES DE ANLISE...................................................... 53 1 ASSOCIAO...........................................................................................53

1.1 1.2 1.3 1.4 2.1 2.2 2.3 2.4 3.1 3.2 3.3 3.4 Associao reflexiva ...............................................................................55 Classes associativas................................................................................55 Relaes Ternrias.................................................................................56 Levantamento das associaes...................................................................57 Notao .............................................................................................58 Multiplicidade ......................................................................................58 Tipos de agregaes ...............................................................................59 Levantamento ......................................................................................60 Hierarquia de classes..............................................................................61 Levantamento de generalizaes................................................................62 Qualidade de uma classificao .................................................................62 Herana mltipla...................................................................................63

2 AGREGAO ...........................................................................................58

3 GENERALIZAO......................................................................................60

4 EXERCCIOS ............................................................................................63

VII PROJETO DE CASOS DE USO ................................................................... 65 1 PROJETO ...............................................................................................65 2 CLASSES DE PROJETO ...............................................................................65 3 ESTUDO DA INTERAO ENTRE OBJETOS .......................................................66
3.1 4.1 4.2 Realizao Converter Celsius-Fahrenheit desktop ............................................66 Dependncia ........................................................................................68 Implementao de associaes e agregaes ..................................................69

4 REFINAR O DIAGRAMA DE CLASSES ...............................................................68 5 SUBSISTEMAS ..........................................................................................74 6 COMPORTAMENTOS ASSOCIADOS PERSISTNCIA.............................................75 7 EXERCCIOS ............................................................................................75

VIII DIAGRAMA DE ESTADOS......................................................................... 79

1 ELEMENTOS BSICOS ................................................................................79

1.1 1.2 1.3 1.4 1.5 1.6 1.7 2.1 2.2 2.3 2.4 3.1 Notao bsica .....................................................................................79 Ao nos estados (entry e exit) ..................................................................80 Atividade nos estados (do) .......................................................................81 Auto-transio......................................................................................81 Transio interna ..................................................................................82 Ordem de execuo de aes e atividades.....................................................82 Condio de guarda................................................................................83 De chamada.........................................................................................83 De sinal ..............................................................................................84 Temporal ............................................................................................85 De mudana.........................................................................................85 Histrico.............................................................................................87

2 TIPOS DE EVENTOS...................................................................................83

3 ESTADO COMPOSTO..................................................................................86 4 EXERCCIOS ............................................................................................88

IX

DIAGRAMA DE ATIVIDADES ..................................................................... 92 1 ELEMENTOS BSICOS ................................................................................92 2 EXERCCIOS ............................................................................................93 DIAGRAMA DE COMPONENTES E IMPLANTAO ............................................ 94 1 DIAGRAMA DE COMPONENTES......................................................................94 2 DIAGRAMA DE IMPLANTAO ......................................................................95 REFERNCIAS BIBLIOGRFICAS ................................................................ 97

XI

INTRODUO

Neste captulo so apresentados os conceitos fundamentais do curso: modelo, UML, anlise e projeto orientado a objetos, objeto e classes de objetos.

1 MODELO
Antes de entrar nos detalhes de UML, preciso ater-se ao conceito de modelo. Um modelo uma simplificao da realidade que descreve um sistema de um ponto de vista particular. Por exemplo, um projeto arquitetnico feito segundo diversas perspectivas: do arquiteto, projeto arquitetnico em si, do engenheiro eletricista, projeto eltrico, do engenheiro civil, projeto hidrulico e estrutural. Construmos modelos de sistemas complexos para melhor compreend-los. Abstrair e refinar incrementalmente so palavras-chaves. Em certos momentos, o projetista deve focalizar na interao entre componentes do sistema sem se preocupar com seus detalhes internos de funcionamento, ento ele abstrai estes detalhes. Em outros momentos, preciso detalhar o comportamento dos componentes. Enfim projetar um sistema significa fazer modelos sob diferentes perspectivas e graus de abstrao, representando-os por meio de uma notao precisa, refinando-os sucessivamente at transform-los em algo prximo da implementao lembrando sempre de verificar se os requisitos so satisfeitos. A modelagem visual (com auxlio de diagramas) ajuda a manter a consistncia entre os artefatos (produtos) ligados ao desenvolvimento de um sistema: requisitos, projeto e implementao. Resumidamente, a modelagem visual pode melhorar a capacidade de uma equipe a gerenciar a complexidade de software.

2 UML
UML significa Unified Modeling Language ou Linguagem de Modelagem Unificada de projetos orientados a objetos. Como o prprio nome diz, UML uma linguagem e no um mtodo! A UML uma linguagem padro de notao de projetos. Por notao entende-se especificar, visualizar e documentar os elementos de um sistema OO. A UML importante, pois: serve como linguagem para expressar decises de projeto que no so bvias ou que no podem ser deduzidas do cdigo; prov uma semntica que permite capturar as decises estratgicas e tticas; prov uma forma concreta o suficiente para a compreenso das pessoas e para ser manipulada pelas mquinas. independente das linguagens de programao e dos mtodos de desenvolvimento.

2.1

Breve histrico

Nos anos 90, conhecida como a poca da guerra dos mtodos, vrios mtodos coexistiam com notaes muitas vezes conflitantes entre si. Dentre estes, os mais conhecidos eram: OMT (Object Modelling Technique) de Rumbaugh; Mtodo de Booch; OOSE (Object Oriented Software Engineering) de Jacobson;

Inicialmente, Rumbaugh (OMT) e Booch fundiram seus mtodos (e notaes) resultando no Mtodo Unificado em 1995 quando trabalhavam juntos na Rational Software (atualmente uma diviso da IBM). Jacobson juntou-se a eles mais tarde e seu mtodo OOSE foi incorporado nova metodologia (RUP). Salienta-se que alm do mtodo, eles unificaram a notao de projeto e a chamaram UML. Ento, UML representa a unificao das notaes de Booch, OMT e Jacobson. Tambm agrega as idias de inmeros autores, tais como Harel e seu diagramas de estados, Shlaer-Mellor e o ciclo de vida dos objetos. Em suma, UML uma tentativa de padronizar os artefatos de anlise e projeto: modelos semnticos, sintaxe de notao e diagramas. Na dcada de 90, surge uma organizao importante no mundo dos objetos a OMG (Object Management Group), uma entidade sem fins lucrativos onde participam empresas e acadmicos para definirem padres de tecnologias OO. Outubro de 1995: primeira verso rascunho, verso 0.8 draft. Julho de 1996: reviso devido ao ingresso de Jacobson, verso 0.9 draft. Parceiros UML (HP, IBM, Microsoft, Oracle e Rational Software) desenvolveram a verso 1.1 e a propuseram OMG A OMG aceita a proposta em novembro de 1997 e assume a responsabilidade de realizar manuteno reviso da UML Em maro de 2003, a OMG lanou a verso 1.5 Em outubro de 2004, a OMG lanou verso 2.0 adotada1

3 ANLISE E PROJETO ORIENTADOS A OBJETOS

H vrios mtodos de desenvolvimento de software. Na dcada de 80 houve preponderncia dos mtodos estruturados. Atualmente o paradigma OO mais forte e, por isso, importante diferenciar anlise e projeto estruturado e orientado a objetos.

3.1

Anlise e projeto estruturados

Vrios autores participam da corrente de anlise, projeto e programao estruturados: 1979 - Tom DeMarco: Anlise estruturada (DEMARCO, 1989) 1982 - Gane e Sarson: Anlise estruturada (GANE & SARSON, 1983) 1985 - Ward e Mellor: Anlise estruturada para sistemas tempo real (WARD & MELLOR, 1986) 1989 - Yourdon: Anlise estruturada moderna (YOURDON, 1990) Na anlise e projeto estruturados, o processo a ser informatizado visto como um conjunto de funes com dados de entrada, processamento e dados de sada, ou seja, a nfase esta em funes que agem sobre dados. Estas funes podem ser decompostas em subfunes (decomposio funcional). As principais caractersticas so: preocupao com a modularidade e coeso; desenvolvimento em diferentes nveis de abstrao (top-down). Os principais diagramas empregados nas diversas metodologias estruturadas so: dicionrios de dados, modelagem do fluxo de dados (DFD); modelos de dados: diagrama entidade e relacionamento (DER) e modelo entidade-relacionamento (MER).

http://www.omg.org/technology/documents/formal/uml.htm

3.2

Anlise e projeto orientados a objetos

Anlise, projeto e programao orientados a objetos: Coad e Yourdon(1979), Rumbaugh(1991), Grady Booch(1991), Jacobson(1992). Diferentemente da anlise e projeto estruturados, na orientao a objetos o processo a ser informatizado visto como um conjunto de objetos que interagem para realizar as funes. As vantagens do modelo OO so: maior grau de abstrao; maior encapsulamento; modelos apoiados em conceitos do mundo real; reutilizao (reusabilidade). Neste curso, no abordado o ciclo de vida de desenvolvimento de software que so inmeros: cascata, iterativo, incremental, gil, extremo e outros. No entanto, as fases clssicas do ciclo de vida so utilizadas (engenharia de requisitos, anlise, projeto, implementao, testes, manuteno e operao).

4 OBJETO E CLASSE
Apresenta-se uma breve reviso de objeto e classes de objeto assim como a notao UML de ambos.

4.1

Objeto

uma abstrao que representa uma entidade do mundo real pode ser algo concreto (computador, carro) ou abstrato (transao bancria, histrico, taxa de juros). Um objeto num sistema possui trs propriedades: estado, comportamento e identidade.

Estado: definido pelo conjunto de propriedades do objeto (os atributos) e de suas relaes com os outros objetos. algo que muda com o tempo, por exemplo, um objeto turma pode estar no estado aberto ou fechado. Inicia no estado aberto e fecha quando 10 alunos fazem inscrio. Comportamento: como um objeto responde s solicitaes dos outros e tudo mais o que um objeto capaz de fazer. implementado por um conjunto de operaes. Ex. objeto turma pode ter operaes acrescentar aluno ou suprimir aluno. Identidade: significa que cada objeto nico no sistema. Por exemplo, o objeto turma Tecno-OO manh diferente do objeto Tecno-OO tarde.

objeto : classe

Tecno-OO manh :Turma

Tecno-OO tarde : Turma

.
Figura 1. Notao de objeto em UML

4.2

Classe

Uma classe uma descrio de um conjunto de objetos com propriedades, comportamento, relacionamentos e semntica comuns. Uma classe pode ser vista como um esqueleto/modelo para criar objetos. Exemplo: classe turma

Atributos: sala, horrio Operaes: obter local, adicionar estudante, obter horrio

Dicas Classes devem encerrar uma s abstrao do mundo real. Por exemplo, uma classe estudante contendo tambm o histrico do estudante no uma boa soluo. Melhor dividi-la em duas classes: estudante e histrico. Utilizar substantivos para nomear as classes. Nas fases iniciais de desenvolvimento, pode-se suprimir os atributos e os mtodos deixando somente os compartimentos.

<<esteretipo>> Classe atributos mtodos

Figura 2. Notao UML para classe.

5 EXERCCIOS
1. Um usurio deseja uma calculadora que efetue as quatro operaes bsicas. As expresses

permitidas so binrias envolvendo apenas dois nmeros, por exemplo, 2 + 3.5 ou 3 * 3.2. Identifique os objetos, seus mtodos e atributos.
2. Seguindo a abordagem de orientao a objetos, identificar no enunciado abaixo os objetos e

usurios do sistema. Liste os nomes dos objetos, seus atributos e os usurios do sistema. Faa o mesmo para a anlise e projeto estruturados identificando as grandes funes e suas decomposies.
UMA LOCADORA de veculos necessita de um sistema para facilitar o atendimento a seus clientes. Os carros so classificados por tipo: popular, luxo e utilitrio. As informaes que interessam locadora sobre cada um dos veculos so: placa do carro, tipo e valor dirio do aluguel. Os funcionrios da locadora so responsveis pelo cadastro dos clientes e dos veculos. Eles tambm fazem as locaes e encerram as mesmas. H clientes especiais e comuns. Os especiais tm direito a uma taxa de desconto e um valor de quilometragem extra nas suas locaes. Um cliente identificado pelo nome, nmero do carto de crdito e data de expirao.

II

NOO GERAL DE ANLISE E PROJETO OO

O objetivo deste captulo apresentar de maneira geral o mtodo de anlise e projeto de sistemas orientados a objetos utilizado durante o curso. So descritas as fases principais do mtodo e os diagramas UML mais indicados para cada uma delas. Este mtodo uma simplificao do RUP (Rational Unified Process).

1 VISO GERAL
No curso, seguiremos o seguinte mtodo:
1. Anlise de requisitos: lista de requisitos funcionais e no-funcionais e diagrama de Casos de

Uso.
2. Levantamento das classes candidatas: montar o diagrama de classes com um levantamento

preliminar das classes, com atributos, mtodos e relaes (quando possvel).

3. Estudo da interao entre objetos: diagramas de interao 4. Refinamento do diagrama de classes 5. Definio do comportamento de classes com estado atravs de mquinas de estados e

diagrama de atividades
6. Modelo de implantao 7. Modelo de implementao 8. Codificao

Os passos de 3 a 5 se repetem at que se chegue prximo da implementao. Eventualmente preciso revisar os requisitos e verificar as implicaes das mudanas no projeto.

2 ANLISE DE REQUISITOS
Consiste em determinar os servios que o usurio espera do sistema e as condies (restries) sob as quais o sistema ser desenvolvido e operar. As necessidades do usurio podem ser muito variadas, o analista deve ser capaz de retirar os requisitos funcionais e no-funcionais destas necessidades: Funcionais: lista de servios que o sistema deve oferecer ao usurio.

No funcionais: propriedades e caractersticas desejadas do sistema relativas capacidade de armazenamento, tempo de resposta, configurao, uso (ex. uso intuitivo), confiabilidade, etc.
Requisitos no-funcionais

Produto Confiabilidade Portabilidade Usabilidade Eficincia

Organizacionais Entrega Implementao Padres

Externos Interoperabilidade ticos Legais Segurana Privacidade

Desempenho Espao

Figura 3: Taxonomia de requisitos no-funcionais (extrada de

http://www.csc.liv.ac.uk/~igor/COMP201/files/SE_L4.ppt#289,15,Non-functional requirement types)

2.1

Papel dos Casos de Uso na Anlise de Requisitos

Casos de uso representam funcionalidades completas para o usurio e no, funcionalidades internas do sistema. Outro ponto importante que o diagrama de casos de uso um artefato de comunicao entre cliente, usurios e desenvolvedores. Por ser extremamente simples e, consequentemente, de fcil compreenso, incentiva a participao do cliente e usurios no processo de desenvolvimento. Tambm serve como um contrato entre a equipe/empresa desenvolvedora e o cliente.

2.2

Casos de Uso

A coleo de casos de uso representa todos os modos pelos quais o sistema pode ser utilizado pelos atores envolvidos. Um caso de uso uma seqncia de aes realizadas colaborativamente pelos atores envolvidos e pelo sistema que produz um resultado significativo (com valor) para os atores. Um ator pode ser um usurio ou outro sistema. Para uma calculadora de linha de comando cujo objetivo executar expresses aritmticas (ex. -2 + 3*5), o diagrama de casos da figura 4 pode ser considerado adequado.

Figura 4. Diagrama de casos de uso para a calculadora.

O diagrama de casos de uso apenas um panorama visual das funcionalidades do sistema, necessria uma descrio textual para detalhar os casos de uso. A tabela 1 ilustra esta documentao para o caso de uso resolver expresses aritmticas.
TABELA 1: DOCUMENTAO PARA O CASO DE USO RESOLVER EXPRESSES ARITMTICAS BSICAS.

Nome do caso de uso

Efetuar expresses aritmticas bsicas

10

Descrio Ator Envolvido Pr-condies Ps-condies Fluxo bsico Usurio

Permite resolver expresses envolvendo nmeros inteiros e reais e as operaes bsicas de soma, subtrao, multiplicao e diviso sem parnteses. Usurio Sistema deve estar em execuo aguardando por uma expresso Expresso aritmtica resolvida ou abandono da expresso pelo usurio. Sistema {Solicita expresso} Solicita a expresso. (A2) {Valida expresso} Avalia se a expresso sintaticamente correta (A1) {Calcula valor} Calcula o valor da expresso. {Mostra o resultado} Informa o resultado da expresso. {Fim} Fim do caso de uso.

Fornece a expresso

Fluxos alternativos A1: em {Valida expresso} Se o usurio fornecer uma expresso sintaticamente incorreta, inform-lo sobre o erro e retomar o fluxo bsico em {Solicita expresso} O usurio pode decidir encerrar o caso de uso sem fornecer uma expresso. Nesse caso retomar o fluxo bsico em {Fim}

A2: em {Solicita expresso}

Portanto, a sada da fase de anlise de requisitos composta por: lista de requisitos funcionais e no-funcionais; diagrama de casos de uso e definies textuais dos casos.

3 ANLISE E PROJETO
Anlise a soluo conceitual dada ao problema. Marca o incio da definio informtica, mas sem levar em conta detalhes da implementao tais como a linguagem a ser utilizada e o sistema gerenciador de banco de dados. Preocupa-se principalmente com as classes do domnio do problema e suas relaes e tambm com os casos de uso. Projeto a soluo informtica dada ao problema. A separao entre anlise e projeto tnue, pois o projeto acaba sendo o resultado de sucessivos refinamentos do modelo conceitual de anlise.

3.1

Diagramas de Interao

H vrios tipos de diagramas de interao na UML. Exemplifica-se o uso do diagrama de seqncia cuja utilidade estudar as interaes entre os objetos com o objetivo de refinar o diagrama de classes, identificando relaes entre classes, seus mtodos e atributos. A figura 5 mostra um cenrio onde o usurio fornece uma expresso aritmtica sintaticamente correta.

11

Figura 5. Diagrama de seqncia para a calculadora.

3.2

Refinamento do Diagrama de Classes

A partir das informaes do diagrama de seqncia, possvel: identificar mtodos associados s classes. Por exemplo, a classe IUCalculadora deve ter um mtodo mostrarResultado(<resultado>). identificar as relaes entre classes. Pelo diagrama de seqncia, fica clara a existncia de uma relao de dependncia entre a classe de controle e as duas outras como ilustra a figura 6.

Figura 6. Diagrama de classes.

3.3

Definir o Comportamento das Classes

Nem todas as classes de um sistema possuem mais de um estado. Para as classes mais complexas, podemos especificar seus comportamentos utilizando mquinas de estado. A figura 7 mostra uma possvel mquina de estados para a calculadora.

12

Figura 7. Mquina de estados para calculadora.

Os mtodos de uma classe podem ainda ser detalhados por meio de um diagrama de atividades como ilustra figura 8.

Figura 8: diagrama de atividades - detalhe de um mtodo para verificar a sintaxe de expresso aritmtica.

3.4

Implantao

O diagrama de implantao representa as necessidades de hardware e sofware bsico (ex. servidores). Para tornar o diagrama mais realista, a figura 9 supe que a calculadora um servio ofertado por um servidor de aplicaes Web.

13

Figura 9: diagrama de implantao (deployement).

3.5

Componentes do Sistema

O objetivo documentar os componentes do sistema (fontes, bibliotecas) e suas relaes. A figura 10 ilustra o diagrama de componentes para a calculadora e mostra a dependncia entre seus componentes.

Figura 10: diagrama de componentes para a calculadora.

4 MODELAGEM ESTRUTURAL E COMPORTAMENTAL

Com esta rpida introduo UML, possvel observar que alguns diagramas so mais indicados para modelar a estrutura do sistema e outros, o comportamento. A figura 11 mostra esta diviso.

14

Diagramas UML

Estrutural Classes Pacotes Objetos Componentes Implantao Estrutura Composta

Comportamental Casos de Uso Atividades Mquina de Estados Interao Seqncia Comunicao Tempo Geral de Interao

Figura 11. Diagramas estruturais e comportamentais da UML. Segue uma breve descrio dos diagramas UML ainda no descritos neste documento: Pacotes: representa uma coleo de classes que juntas formam uma unidade. Tambm pode servir para agrupar um conjunto de casos de uso com similaridades funcionais. Os pacotes podem apresentar relaes, por exemplo, um pacote de classes pode depender de outro para executar suas funes. Objetos: um instantneo da execuo do sistema, retrata os objetos instanciados e suas relaes em um dado momento. Componentes: segundo a definio de (OMG, 2007, pg. 146), um componente um mdulo ou parte de um sistema que encapsula seu contedo (comportamento e dados). Um componente exibe seu comportamento atravs de interfaces bem definidas e pode depender de outros componentes. Deployement (Implantao ou Distribuio): para representar a arquitetura fsica do sistema, ou seja, para representar as relaes entre os componentes (artefatos) e os locais de execuo (nodos: mquinas ou sistemas servidores). Estrutura Composta: descreve a estrutura interna de uma classe ou componente, detalhando as partes internas que o compe como estas se comunicam e colaboram entre si (Guedes, 2004). Atividades: pode ser utilizado para diversos fins, um deles a especificao mais detalhada de mtodos complexos ou do encadeamento dos casos de uso. Interao.Comunicao: mostra as interaes entre uma coleo de objetos sem a linha do tempo (pode ser obtido do diagrama de seqncia e vice-versa). Interao.Tempo: mostra o estado de um objeto ao longo do tempo. Interao.Geral: a fuso do diagrama de atividades com o de seqncia. Permite fazer referncia a diagramas de seqncia e combin-los com controle de fluxo (ex. pontos de deciso, forks e joins).

15

III MODELO DE CASOS DE USO

O modelo de casos de uso (que mais do que o diagrama) o principal resultado da fase de anlise de requisitos. Diagramas de casos de uso so utilizados para representar de forma panormica os requisitos funcionais de um sistema do ponto de vista do usurio. Cabe salientar que h outras utilizaes possveis para o diagrama de casos de uso, tal como modelagem do negcio, porm, o foco nesta seo est na representao de requisitos funcionais do usurio.

1 DEFINIO
um diagrama utilizado na anlise de requisitos com objetivos claros:
1. Compreender o problema. 2. Delimitar o sistema (quem est no entorno). 3. Definir as funcionalidades oferecidas ao usurio (no h preocupao com a

implementao). Diagrama de casos de uso uma ferramenta de comunicao entre clientes, usurios e desenvolvedores para discutirem e definirem as funcionalidades que devem ser realizadas pelo sistema. Os elementos bsicos de um diagrama de casos de uso so: atores, casos de uso e relaes entre os mesmos.

2 ATORES
Representam papis desempenhados por usurios ou qualquer outra entidade externa ao sistema (ex. hardware, outros sistemas) Podem iniciar casos de uso Podem prover e/ou receber informaes dos casos de uso

Figura 12: Notao UML para ator.

Como encontrar atores de um sistema

Examinar o problema procurando por pessoas ou sistemas do entorno. Quais as pessoas ou departamentos interessados num determinado requisito funcional? Quem ir suprir o sistema com informaes e quem ir receber informaes do sistema? Quais os recursos externos utilizados pelo sistema? Uma pessoa desempenha diferentes papis? O sistema interage com outros sistemas j existentes?

16

Como saber se um ator foi bem escolhido?

um processo iterativo, a primeira tentativa dificilmente ser a definitiva. Por exemplo, um aluno calouro diferente de um veterano so atores diferentes? SIM, se eles utilizam o sistema de maneiras diferentes e NO, caso contrrio.

3 CASOS DE USO
A coleo de casos de uso representa todos os modos de execuo do sistema do ponto de vista do usurio. Um caso de uso uma seqncia de aes que produz um resultado significativo (com valor) para um ator. Quais so as tarefas de cada ator? Que informaes o ator obtm do sistema? Quem as fornece? Quem as captura? Algum ator precisa ser informado sobre eventos produzidos pelo sistema? Sim => casos de uso de registro e notificao H eventos externos que devem ser notificados ao sistema? Sim => devem haver casos para que os atores possam notificar o sistema

3.1

Descrio

No h descrio padro definida pela UML. Em geral o diagrama bastante informal e sua estruturao (relao entre casos) no deve ser levada ao extremo. importante ressaltar que o diagrama de casos de uso uma forma de visualizar os casos e no de descrev-los detalhadamente. Portanto, o diagrama por si s no suficiente. Os casos de uso so descritos normalmente pelos seguintes elementos:

nome descrio requisitos (requirements): so os requisitos funcionais providos pelo caso de uso restries (constraints), tais como pr e ps-condies e condies invariantes: Pr-condies: define o que deve ser verdadeiro para que o caso de uso seja iniciado. Por exemplo, num sistema bancrio, para o caso de uso Abrir conta-corrente, uma pr-condio apresentar CPF sem restries (aprovao do pedido) Ps-condies: o que se torna verdadeiro pela execuo do caso de uso. No mesmo caso de uso acima, o sistema pode se encontrar em um dos seguintes estados: conta aberta e com um depsito inicial ou conta no-aberta por reprovao do CPF. Invariantes: condies que so verdadeiras durante a execuo do caso de uso.

fluxos de eventos: descrio de interaes entre atores e sistema que ocorrem durante a execuo do caso de uso. outras informaes: data, autor, etc.

3.2

Fluxo de Eventos

Um fluxo de evento descreve i) como o sistema e os atores colaboram para produzir algo de valor aos atores e ii) o que pode impedir sua obteno. Um fluxo descreve um caminho entre muitos possveis visto que um caso de uso pode ser executado de vrios modos.

17

H fluxos primrios ou bsicos (fluxo normal de eventos) e alternativos (o que fazer se). Para descrev-los, possvel se inspirar na situao em que uma pessoa explica um caminho outra. Primeiro, o fluxo bsico explicado, depois, as alternativas.
Para ir ao churrasco, pegue a BR116 na direo So Paulo. Logo aps o clube Santa Mnica, tem um retorno por baixo da pista. Faa o retorno e continue reto (no retorne BR). Continue nesta estradinha asfaltada por 1 km, no entroncamento pegue a estrada de terra direita, ande cerca de 500m, voc ver um grande eucalipto e uma araucria. A entrada da chcara entre os dois. No se esquea de trazer o pinho. // primrio Se estiver chovendo muito, os 500m na terra podem ser bem difceis porque o barro mole. Neste caso, siga reto no entroncamento (ao invs de virar direita) e na prxima a direita pegue a rua de paraleleppedos. Ande cerca de 1 km e depois vire na segunda a direita que vai desembocar na frente da chcara. // alternativo 1

Se voc for comprar o pinho no caminho, logo depois de fazer o retorno da BR tem uma venda. Se estiver fechada, um pouco mais a frente, tem um senhor da chcara Pinhais que tambm vende. Se no encontrar pinho, no tem problema. // alternativo 2 Fluxos documentam as responsabilidades, ou seja, como as responsabilidades especificadas nos casos de uso so divididas entre sistema e atores. No desenrolar do projeto, as responsabilidades atribudas ao sistema devem ser distribudas entre os objetos que compem o sistema. Nas fases iniciais de anlise bom concentrar-se nos fluxos bsicos (cerca de 80% do tempo de execuo de um sistema ocupado pelos casos primrios) e somente identificar os casos secundrios.

3.2.1 Fluxo Bsico

Um fluxo bsico representa o que ocorre normalmente quando o caso de uso executado. A descrio do fluxo bsico deve conter (Bittner e Spencer, 2003):

ator e o evento que o mesmo dispara para iniciar o caso; a interao normal (sem tratamento de excees) entre ator e sistema; descrio de como o caso termina.

Exemplo: considere um sistema onde o cliente realiza compras on-line num site utilizando um carrinho de compras virtual. O projetista do sistema previu um caso chamado buscar produtos e fazer pedido especificado pelo fluxo bsico seguinte - extrado de (Bittner e Spencer, 2003): NOME: Buscar produtos e fazer pedido DESCRIO: Este caso descreve como um cliente usa o sistema para visualizar e comprar produtos disponveis. Para encontrar um produto, o cliente pode pesquisar o catlogo por tipo de produto, fabricante ou por palavras-chaves. PR-CONDIES: o cliente est logado no sistema. PS-CONDIES: o cliente realiza uma compra ou no. FLUXO BSICO DE EVENTOS
1. O caso de uso inicia quando o ator cliente escolhe a opo de consultar o catlogo de

produtos.
2. {Mostrar catlogo de produtos} 3. O sistema mostra os produtos oferecidos, ressaltando os produtos cujas categorias constam

no perfil do cliente.
4. {Escolher produto}

18

5. O cliente escolhe um produto a ser comprado e define a quantidade desejada. 6. Para cada produto selecionado disponvel em estoque, o sistema registra o cdigo do

produto e a quantidade solicitada reservando-a no estoque e adiciona-o ao carrinho de compras.

7. {Produto esgotado} 8. Os passos 3 e 4 se repetem at que o cliente decida efetuar a compra dos produtos. 9. {Processar pedido} 10. O sistema pergunta ao cliente se deseja fornecer informaes sobre o pagamento. 11. O sistema utiliza um protocolo seguro para obter as informaes de pagamento do cliente. 12. Executar subfluxo validar informaes de pagamento 13. {Informaes de pagamento no vlidas} 14. O sistema pergunta ao cliente se deseja fornecer informaes sobre o envio das mercadorias. 15. O sistema utiliza um protocolo seguro para obter as informaes de envio. 16. Executar subfluxo validar informaes de envio. 17. {Informaes de envio no vlidas} 18. Executar subfluxo efetuar transao financeira. 19. O sistema pergunta ao cliente se deseja comprar mais produtos. 20. Se o cliente desejar comprar mais produtos, retomar o caso no ponto {Mostrar catlogo de

produtos}, se no o caso termina. No fluxo bsico acima, pode-se notar a existncia de vrios elementos que sero descritos a seguir: subfluxo, pontos de extenso e fluxos alternativos.

3.2.2 Subfluxo
Um fluxo de eventos pode ser decomposto em subfluxos para melhorar a legibilidade. No entanto, interessante evitar muitas decomposies, pois o fluxo ficar muito fragmentado e seu entendimento dificultado. Um subfluxo deve ser atmico, isto , ou executado na sua totalidade ou no executado. Para referenciar um subfluxo a partir de outro fluxo usar a notao: executar <nome subfluxo>. No exemplo Buscar produtos e fazer pedido, os subfluxos seguintes so encontrados:

S1 Validar informaes de pagamento; S2 Validar informaes de envio; S3 Efetuar transao financeira.

Estes subfluxos podem ser detalhados da mesma maneira que um fluxo bsico, porm deve-se evitar muitas decomposies sob o risco de perder a viso geral do caso de uso.

3.2.3 Pontos de extenso

So pontos precisos num fluxo de eventos que servem para inserir comportamentos adicionais. Pontos de extenso podem ser privados ou pblicos. So privados se visveis somente dentro do caso onde foram definidos ou pblicos se visveis nos casos que estendem o caso onde foram definidos. No exemplo Buscar produtos e fazer pedido, os pontos de extenso seguintes so encontrados:

{Mostrar catlogo de produtos} {Escolher produto}

19

{Produto esgotado} {Processar pedido} {Informaes de pagamento no vlidas} {Informaes de envio no vlidas}

Um ponto de extenso pode definir

uma localizao nico dentro do fluxo, por exemplo, {Mostrar catlogo de produtos}, {Escolher produtos} e {Processar pedido}; um conjunto de localizaes que representam um certo estado do caso de uso, por exemplo, {Produto esgotado} que poderia aparecer em vrios pontos do fluxo de eventos; uma regio entre dois pontos de extenso, por exemplo, {Escolher produtos} e {Processar pedido}.

3.2.4 Fluxo Alternativo

Um fluxo alternativo apresenta um comportamento opcional, de outra forma, que no parte do comportamento normal de um caso de uso. Fluxos alternativos so utilizados para representar tratamento de excees ou um comportamento alternativo complexo que tornaria o fluxo bsico muito longo ou de difcil compreenso. Fluxos alternativos sempre so dependentes da existncia de uma condio que ocorre em um ponto de extenso de outro fluxo de eventos. H trs tipos de fluxos alternativos:
1. Especfico: iniciam num ponto de extenso. 2. Regional: podem ocorrer entre dois pontos de extenso. 3. Geral: podem ocorrer em qualquer ponto do caso de uso.

No exemplo Buscar produtos e fazer pedido, os fluxos alternativos seguintes so encontrados: Tratar produto esgotado (especfico) e pesquisar por palavras-chaves (regional). A2 Tratar produto esgotado Em {Produto esgotado} quando no h a quantidade requisitada do produto em estoque.
1. O sistema informa que o pedido no pode ser completamente satisfeito. 2. // a descrio deste fluxo continua com oferta de quantidades e produtos alternativos ao cliente 3. O fluxo de eventos bsico retomado no ponto onde foi interrompido.

A1 Pesquisar por palavras-chaves Entre {Mostrar catlogo de produtos} e {Escolher produto} quando o cliente escolhe realizar uma pesquisa por palavras-chaves.
1. O sistema pergunta ao cliente pelos critrios de busca do produto. 2. O cliente fornece os critrios de busca de produto. 3. // a descrio deste fluxo continua 4. O fluxo de eventos bsico retomado em {Escolher produto}.

No h fluxo geral para o exemplo, mas poderia ser definido da seguinte maneira: em qualquer ponto do caso de uso Buscar produtos e fazer pedido...

20

Por que representar um fluxo alternativo separadamente do fluxo bsico se possvel represent-lo com um se (if) no fluxo bsico?

Fluxos alternativos so opcionais e descrevem comportamentos que esto fora do comportamento normal esperado. Nem todos os fluxos alternativos representam funcionalidades essenciais, muitos deles podem no ser necessrios, podem ser muito caros ou no prover funcionalidades importantes o suficiente para dispndio de esforos de desenvolvimento. Fluxos alternativos permitem adicionar funcionalidade ao fluxo bsico de maneira incremental ou remover funcionalidade medida que tempo e dinheiro se esgotam.

Por exemplo, qual a importncia de realizar pesquisas por palavras-chaves no exemplo em uso? Se for apenas uma das alternativas de busca no inviabiliza a funcionalidade do fluxo bsico como um todo. Agora se algum perguntar qual a importncia do fluxo bsico buscar produtos e realizar pedido, fcil ver que no pode ser deixado de fora.

3.2.5 Diagrama de atividade

Um diagrama de atividade pode ser empregado para representar os fluxos de eventos de um caso de uso. Sua utilizao no suprime a descrio textual, pelo contrrio, ele deve ser visto como uma ilustrao simplificada da descrio textual. Se todos os detalhes da descrio textual forem colocados no diagrama, este ficar extremamente poludo e perder sua utilidade: tornar o caso de uso mais compreensvel aos leitores.

Figura 13: Exemplo de diagrama de atividades.

3.2.6 Cenrios
Cenrios so instncias de execuo dos casos de uso. Os fluxos alternativos representam as possibilidades de execuo de um caso de uso. No exemplo buscar produtos e realizar pedido, o fluxo alternativo pesquisar produtos por palavras-chaves uma alternativa simples visualizao do catlogo

21

de produtos, logo h pelo menos dois caminhos possveis de execuo. Um cenrio representa um desses caminhos (figura 14).
cenrio Fluxo alternativo

Fluxo bsico

Figura 14: Representao esquemtica de um cenrio.

Cenrios so importantes para definir casos de teste e para desenvolvedores pensarem sobre como o sistema ser utilizado. Podem ser documentada adicionando-se informao s descries dos casos de uso ou como parte da descrio dos testes. No h necessidade de descrev-los detalhadamente, basta nome-los e descrever o caminho a ser percorrido (por exemplo, fluxo bsico, fluxo alternativo a1, fluxo bsico).

3.2.7 Realizaes de Casos de Uso

Um caso de uso pode ser realizado (projetado e implementado) de diferentes modos. Em UML h uma representao para realizao de caso de uso como ilustra a figura 15. O intuito dessa representao fazer uma ponte entre as descries do sistema utilizadas pelas pessoas envolvidas na sua construo, mas que no participam do desenvolvimento em si, e as descries do sistema utilizadas pela equipe de desenvolvimento.

Modelo de casos de uso

Modelo de anlise e projeto

Figura 15: Realizao de um caso de uso.

Diagramas de interao podem ser associados s realizaes de casos de uso para especificar o fluxo de informaes entre objetos que concretizam o caso. Porm, a representao de realizao de caso no muito utilizada.

4 RELAES
H vrios tipos de relaes possveis num diagrama de casos de uso, porm importante salientar que as relaes:
1. no representam a ordem de execuo dos casos; 2. devem melhorar a compreenso do que o sistema deve fazer (e no como projet-lo).

Em seguida, apresentam-se as relaes mais comuns.

22

4.1

Associao

Associao o tipo mais comum de relao. Pode ser utilizada entre dois atores ou entre um ator e um caso de uso. So representadas por uma linha cheia, com ou sem direo.

Ator x Ator
Relaes associativas podem conectar atores para representar comunicao entre atores. A relao pode receber um nome que identifica o contedo da mensagem, documento ou objeto que trafega entre os atores. A figura 16 mostra uma associao entre o ator usurio de biblioteca que passa o livro ao atendente que realiza o emprstimo ou a devoluo. Como no h flechas, assume-se que o atendente devolve algo ao usurio da biblioteca, provavelmente um comprovante no representado no diagrama. No recomendvel colocar este tipo de relao no diagrama de casos de uso.

Figura 16: Exemplo de associao entre atores.

Ator x Caso
H vrios usos para associaes entre atores e casos de uso: 1. indica quem inicia a comunicao, o ator ou o caso de uso (sistema); 2. indica o fluxo de informaes, ou seja, quem fornece informaes a quem. Para documentar a escolha, pode-se atribuir um nome associao. Na figura 16, h uma associao entre o atendente e o caso de uso realizar emprstimo. Observar que bidirecional, portanto o atendente inicia a execuo do caso, fornece e recebe informaes do mesmo. Associaes unidirecionais deixam os diagramas mais claros, embora no sejam obrigatrias. Por exemplo, a figura 17 ilustra um mesmo diagrama que representa os requisitos de um sistema de telefonia com relaes bidirecionais e unidirecionais. No diagrama superior, pode-se deduzir que o emissor inicia a chamada telefnica e, no inferior, esta informao est explcita.

23

Figura 17: Associaes bidirecionais e unidirecionais.

4.2

Incluso

A relao de incluso utilizada entre dois casos, quando um deles inclui o outro na sua execuo (subcaso). Um subcaso representa parte de um fluxo de eventos bsico, isto , um subfluxo que foi separado e representa um conjunto de aes atmico. Ressalta-se que a existncia de um subfluxo na descrio textual de um caso no implica sua representao no diagrama de casos de uso. A relao de incluso (<<include>>) deve ser utilizada somente quando dois ou mais casos de uso apresentam partes idnticas nos seus fluxos de evento, caso contrrio (se somente um caso de uso utilizar o subfluxo) no deve ser representado. Isto requer que os fluxos de evento sejam escritos antes de se colocar relaes de incluso no diagrama. A figura 18 mostra um caso efetuar matrcula que possui subfluxos escolher disciplinas, alocar alunos s turmas e emitir boleto. Este ltimo compartilhado com o caso Efetuar inscrio curso opcional e, portanto, deve ser representado no diagrama. Um erro comum que adiciona complexidade ao diagrama incluir os subfluxos escolher disciplinas e alocar alunos s turmas no diagrama.

Figura 18: exemplo de incluso de casos.

24

 importante ressaltar que:

um caso de uso nunca deve ser includo apenas por um caso, ou seja, no utilizar <<include>> para decompor o diagrama em partes; um caso de uso que includo por vrios outros no tem conhecimento sobre quem o inclui, portanto, podem ser includos por qualquer caso sem sofrer modificaes; no utilizar a relao de incluso para representar opes de menu, pois o caso que faz a incluso seria um simples despachante, todo o comportamento estaria fragmentado nos casos includos.

Enfim, incluso deve ser utilizada para administrar comportamentos comuns e no para estruturar funcionalmente o diagrama.

4.3

Extenso

Um caso pode estender outro quando se deseja inserir um comportamento opcional ou excepcional disparado por alguma condio (ex. um alarme ou condio especial de algum objeto). Situaes que podem levar ao uso da relao de extenso (Bittner e Spencer, 2003):

Descries opcionais ao comportamento normal do sistema: por exemplo, mdulos que podem ser comprados do desenvolvedor ou de terceiros. Descries de tratamento de erros e excees complexos: estes tratamentos podem ser extremamente longos e ofuscar o fluxo bsico. Customizao: fluxos alternativos que especificam como diferentes clientes tratam certas situaes no dentro do mesmo caso de uso base. Administrao de escopo e de release: comportamentos que sero includos futuramente.

importante ressaltar que:

Um caso de uso de extenso no requer modificaes no caso base (aquele que estendido). O comportamento bsico do caso base permanece intacto. Um caso de uso que estende um caso base conhece este ltimo (no muito comum um caso de uso estender mais de um caso base). Uma extenso nasce como um fluxo alternativo, mas nem todo fluxo alternativo vira uma extenso. Casos de uso que estendem assumem o controle no ponto de extenso e quando terminam devolvem o controle no mesmo ponto.

Aqui cabe uma distino entre fluxos alternativos e casos de uso que estendem outros. Fluxos alternativos so parte do caso de uso base e tm acesso ao seu estado, pr-condies, outros fluxos existentes e pontos de extenso alm daquele onde se inserem. Casos de uso que estendem conhecem apenas o ponto de extenso onde se inserem no caso estendido. Para saber se um fluxo alternativo candidato a ser uma extenso, deve responder positivamente questo: o sistema pode ser entregue sem a extenso? Na figura 19, a emisso de histrico escolar estendida pelo caso imprimir comprovante de trmino quando o aluno solicitante for formado. Observa-se que um comportamento opcional que pode no ser oferecido sem prejuzo ao comportamento bsico emitir histrico escolar.

25

Figura 19: exemplo de relao de extenso entre casos de uso.

Nota-se na o ponto de extenso pblico denominado {aluno formado} onde o comportamento opcional imprimir comprovante trmino inserido. provvel que existam outros pontos de extenso privados definidos nos fluxos de emitir histrico escolar, porm, no diagrama s os usados pelas extenses so listados. A figura 20 ilustra o diagrama de casos de uso para o exemplo buscar produto e fazer pedido.

Figura 20: pontos de extenso para o caso buscar produtos e fazer pedido.

4.4

Generalizao/Especializao

A relao de generalizao/especializao pode ocorrer entre casos de uso ou entre atores.

Caso x Caso
Generalizao permite especificar comportamentos genricos que podem ser especializados para atenderem necessidades especficas. Normalmente utilizado quando se quer descrever famlias de sistemas. Por exemplo, uma empresa que desenvolve software pare terminais bancrios de auto-atendimento quer expandir seus negcios para outras reas, tais como pagamento direto em bombas de gasolina. NOME: Realizar transao (caso abstrato) DESCRIO: Permite ao usurio comprar mercadorias de um terminal automtico sendo que o valor das mercadorias descontado de uma conta bancria.

26

PR-CONDIES: (e) o cliente possui um carto bancrio; a conexo com o banco est ativa; o terminal deve ter mercadoria. PS-CONDIES: (ou) O terminal retornou o carto bancrio ao cliente, entregou a mercadoria ao cliente e debitou o valor de sua conta. O terminal retornou o carto bancrio ao cliente, no entregou nenhuma mercadoria e nenhum valor foi debitado da sua conta. FLUXO BSICO DE EVENTOS
1. O ator cliente insere o carto bancrio no terminal. 2. O sistema l as informaes da conta do cliente no carto bancrio 3. O sistema solicita ao cliente a senha 4. O cliente fornece a senha 5. O sistema verifica se a senha fornecida pelo cliente idntica lida do carto

bancrio
6. O sistema contata com o Sistema Bancrio para verificar se as informaes da

conta do cliente so vlidas

7. O sistema solicita o valor da transao 8. O sistema contata o Sistema Bancrio para verificar se o cliente tem saldo para

cobrir a solicitao. {Cliente realiza a transao}

9. O sistema registra o valor da transao. 10. O sistema comunica ao Sistema Bancrio que a transao foi efetuada. 11. O sistema grava no log os dados da transao: data, hora, valor e conta. 12. Trmino do caso de uso.

NOME: Sacar (caso concreto) DESCRIO: Especializa o caso de uso realizar transao para permitir ao cliente retirar dinheiro de um terminal de auto-atendimento bancrio. PR-CONDIES: (e) o cliente possui um carto bancrio; a conexo com o banco est ativa; o terminal deve ter dinheiro. PS-CONDIES: (ou) O terminal retornou o carto bancrio ao cliente, entregou o dinheiro ao cliente e debitou o valor de sua conta. O terminal retornou o carto bancrio ao cliente, no entregou dinheiro e nenhum valor foi debitado da sua conta. FLUXO BSICO DE EVENTOS Em {Cliente realiza transao}
1. O sistema verifica se tem dinheiro suficiente em relao ao montante solicitado

pelo cliente.
2. O sistema entrega o montante solicitado. 3. O sistema solicita que retire o dinheiro do terminal. 4. O cliente pega o dinheiro.

27

5. Retoma-se o caso de uso abstrato em {Cliente realiza transao}

NOME: Abastecer veculo (caso concreto) DESCRIO: Especializa o caso de uso realizar transao para permitir ao cliente obter combustvel de uma bomba debitando o valor de sua conta. PR-CONDIES: (e) o cliente possui um carto bancrio; a conexo com o banco est ativa; a bomba tem combustvel. PS-CONDIES: (ou) O terminal retornou o carto bancrio ao cliente, liberou o combustvel ao cliente e debitou o valor de sua conta. O terminal retornou o carto bancrio ao cliente, no liberou combustvel e nenhum valor foi debitado da sua conta. FLUXO BSICO DE EVENTOS Em {Cliente realiza transao}
1. O sistema solicita ao cliente para tirar o bico de abastecimento e libera o fornecimento

de combustvel.
2. O cliente enche o tanque at atingir o valor informado ou at que o tanque esteja cheio. 3. O cliente recoloca o bico na bomba. 4. Retoma-se o caso de uso abstrato em {Cliente realiza transao}

O diagrama de casos de uso correspondente aos casos acima ilustrado na figura 21.

Figura 21: generalizao/especializao de casos de uso.

Ressalta-se que nesta situao, so executados os casos de usos especializados. Eles apenas reusam partes do caso geral. A tabela 3 mostra as diferenas entre especializao e extenso de casos de uso.
TABELA 3: COMPARATIVO ENTRE ESPECIALIZAO E EXTENSO DE CASOS DE USO.

Especializao O caso de uso especializado executado O caso de uso base no precisa ser completo e com sentido. H vrias lacunas preenchidas somente nas especializaes. O comportamento de uma execuo depende unicamente do caso especfico.

Extenso O caso de uso base executado O caso de uso base deve ser completo e com sentido.

O comportamento de uma execuo depende do caso de uso base e de todas as

28

extenses que so executadas.

Ator x Ator
Especializao de atores representa que um conjunto deles possui responsabilidades ou caractersticas em comum. Algumas dicas para evitar modelagens desnecessrias:

No utilizar atores para representar permisses de acesso. No utilizar atores para representar organogramas (hierarquias) de cargos de uma empresa. Utilizar atores somente para definir papis em relao ao sistema.

Por exemplo, se num sistema de matrculas de uma universidade h casos de uso especiais para alunos de cincias exatas e para alunos de humanas, ento sinal que estes alunos so especializaes de um ator genrico aluno. A figura 22 ilustra a notao UML para este caso. Observar que alunos de cincias exatas e de humanas herdam todas as associaes do ator aluno.

Figura 22: Especializao de atores.

5 MODELAGEM
5.1 Dicas

Casos de uso auxiliares

Casos de uso auxiliares so frequentemente esquecidos, pois no so essenciais funcionalidade do sistema. Porm, esquec-los completamente pode conduzir a um sistema difcil de ser utilizado. Lembrar de colocar casos de uso para executar, manter e configurar o sistema, tais como: lanar e parar o sistema, incluir novos usurios, fazer backup das informaes, incluir novos relatrios e realizar configuraes.

Decomposio funcional

No necessrio detalhar em excesso os casos de uso. Muitos detalhes levam a decomposio dos casos em funes. O objetivo compreender o sistema atravs de cenrios de utilizao. Casos de uso no so feitos para analisar (no sentido de decompor) os requisitos em requisitos menores. um processo de sntese ou elaborao (e no de anlise) no qual o problema no

29

totalmente conhecido. Quebr-lo em partes menores (anlise) dificulta a obteno de uma viso geral.

Em equipes com forte competncia em anlise estruturada, h tendncia em encontrar funes ao invs de casos de uso. Por exemplo, fazer pedido, revisar pedido, cancelar pedido e atender pedido podem parecer bons casos de uso. No fundo, todas estas funes esto relacionadas ao caso de uso realizar pedido. Decomposio funcional pode levar a um nmero intratvel de casos, mesmo para pequenos sistemas, e perda de foco no que realmente importante no sistema (o que traz valor aos atores). Casos de uso no chamam outros casos de uso ou se comunicam com outros casos.

Estrutura e detalhamento

No estruturar demais o diagrama de casos de uso, isto , no inclua relaes entre casos de uso a no ser que sejam extremamente necessrias. O uso em excesso destas relaes podem fragmentar o diagrama, diminuindo a compreenso global. O modelo deve ser o mais simples e direto possvel. No descrever o que ocorre fora do sistema. Por exemplo, interao entre atores pode ser importante para o negcio, mas se o sistema no facilita esta interao, deixe-a fora. Se for necessrio esclarecer estes pontos faa um modelo do negcio e no um modelo de casos de uso. No fazer casos tais como incluir, consultar, alterar e excluir (ICAE). Casos de uso que descreve comportamentos ICAE no adicionam muito valor descrio da funcionalidade do sistema. Para estes tipos de comportamentos, os requisitos so bastante claros e no se deve perder tempo especificando-os. A maior parte destes comportamentos tem um padro mostrar campos, usurio entra com os dados, sistema valida, usurio corrige erros,... A validao, a parte mais importante dos comportamentos ICAE, pode ser capturada no domnio do modelo (por meio de relaes, cardinalidade e restries) ou textualmente no glossrio de dados.

Modelo de casos de uso mais que um diagrama

O diagrama de casos de uso uma viso panormica dos casos de uso e, portanto, apenas um dos componentes do modelo de casos de uso. A descrio textual dos mesmos a parte mais importante do modelo. So elementos do modelo de casos de uso: glossrio, modelo do domnio e diagramas de atividades. Um glossrio e um modelo do domnio podem evitar o excesso de detalhes nas descries dos casos de uso. Por exemplo, ao invs de descrever a validao da entrada de dados, os campos podem ser definidos no glossrio com os respectivos valores possveis. Um modelo do domnio ajuda a entender as relaes existentes entre as entidades do domnio e as restries sobre as relaes.

5.2

Passos

Para elaborar um modelo de casos de uso, os seguintes passos podem ser seguidos:

Recapitular a viso do sistema (estudo de viabilidade) aos envolvidos. Elaborar se necessrio um diagrama de contexto para definir os limites do sistema (o que est dentro e o que est fora). Identificar os atores do sistema. Identificar os casos de uso: descrev-los e rascunhar o fluxo de eventos. No se preocupe com fluxos alternativos. No gaste mais do que 10 minutos para descrever cada caso de uso. Esboar o diagrama de casos de uso mostrando associaes entre atores e casos de uso.

30

Verificar os casos de uso: H casos de uso sem conexo com requisitos funcionais? Caso haja, pode haver casos em excesso ou requisitos que no foram identificados! H requisitos funcionais sem casos? Alguns casos podem ter sido esquecidos. Todos os requisitos no-funcionais foram tratados (associados aos casos de uso quando so especficos)? Todos os tipos de usurios foram mapeados para um ator ao menos? Descrever os casos detalhadamente Representar os subfluxos (<<include>>) e fluxos alternativos (<<extend>>) considerados importantes no diagrama Verific-los: possvel eliminar os casos includos ou as extenses e ainda ser capaz de entender o que o sistema faz para as partes interessadas?

6 EXERCCIOS
1. Um aluno de uma universidade particular deve escolher disciplinas do semestre. Em seguida

ele alocado s turmas para ento receber uma fatura emitida pelo sistema de faturamento com o valor a ser pago em funo do nmero de turmas em que conseguiu vaga. Quais so os atores e casos de uso?
2. A secretaria de uma universidade deve cadastrar turmas, apag-las e modific-las e envi-las

aos departamentos acadmicos? Quais so os atores e casos de uso?

3. Construir o diagrama de casos de uso e especificar os fluxos de eventos bsico.

Um cliente deseja um sistema que permite jogar jogo da velha e forca. O sistema destinado a um usurio e deve armazenar as estatsticas de uma sesso (do lanamento ao trmino do sistema). Em uma sesso o usurio pode jogar diversas vezes cada um dos jogos. Ao trmino de cada jogo, atualizam-se as estatsticas da sesso: nmero de vezes que jogou velha, nmero de vitrias absoluto e percentual e o mesmo para forca. O usurio deseja que o painel de estatsticas esteja sempre visvel.
4. Qual a diferena entre as relaes de incluso e extenso entre casos de uso? 5. Como voc modelaria a situao abaixo utilizando casos de usos? Faa a descrio completa

para um dos casos incluindo descrio, pr-condies, ps-condies, fluxo de eventos bsico e alternativos e o diagrama de casos. A atividade da biblioteca centra-se principalmente no emprstimo de publicaes pelos alunos. O emprstimo registrado pelos funcionrios da biblioteca que tambm consultam diariamente os emprstimos cujos prazos foram ultrapassados. Os alunos necessitam pesquisar os livros existentes na biblioteca. Caso um livro esteja emprestado mostrado a data esperada de entrega.
6. Construir o diagrama de casos de uso:

Um cliente (pessoa fsica ou jurdica que paga o advogado pra defend-la ou para processar outra pessoa) procura o advogado. Se o cliente ainda no estiver cadastrado, o advogado dever registrar seus dados pessoais. Em seguida, o cliente deve fornecer informaes a respeito do processo que deseja que o advogado mova contra algum ou que o defenda de outra pessoa. Obviamente o processo precisa ser registrado e receber diversas adies enquanto estiver em andamento. O cliente

31

deve fornecer tambm informaes sobre a parte contrria (pessoa fsica ou jurdica que est processando ou sendo processada pelo cliente), que dever ser registrada, caso ainda no esteja. Observe que uma mesma pessoa fsica ou jurdica pode ser tanto um cliente como uma parte contrria em processos diferentes obviamente. Um processo deve tramitar em um determinado tribunal e em uma determinada vara, no entanto um tribunal pode julgar muitos processos e uma vara pode possuir diversos processos tramitando nela. Um tribunal pode possuir diversas varas, porm um processo julgado por um tribunal s pode tramitar em varas pertencentes ao mesmo. O advogado pode achar necessrio emitir relatrios de todos os processos em andamento em um tribunal e tramitando em uma vara. Cada processo possui no mnimo uma audincia, cada audincia relativa a um determinado processo deve conter sua data e a recomendao do tribunal. Para fins de histrico do processo, cada audincia deve ser registrada. Um processo pode gerar custas (cpias, viagens, etc.). Cada custa deve ser armazenada de forma a ser cobrada da forma contrria caso o processo seja ganho. Este sistema deve estar integrado a um sistema de contas a pagar receber, cada custa gera uma conta a pagar. Caso o processo seja ganho, ele gerar uma ou mais contas a receber, dependendo da negociao com a parte contrria.

32

IV ANLISE DOS CASOS DE USO

Este captulo inicia com uma breve apresentao do padro de projeto MVC e do padro observador que servem de ponto de partida na escolha das classes que fazem parte de um sistema (classes de anlise). Em seguida, apresenta-se o levantamento das classes de anlise a partir dos casos de uso.

1 ANLISE
O levantamento das classes de anlise marca o incio da construo do modelo da anlise (RUP). Ocorre uma mudana na linguagem, enquanto no modelo de casos de uso a descrio do sistema era feita na linguagem do cliente/usurio, na anlise emprega-se a linguagem dos desenvolvedores. A tabela 4 ilustra as diferenas entre o modelo de casos de uso e o modelo de anlise segundo (Jacobson e co-autores, 1999).
TABELA 4: COMPARAO ENTRE MODELO DE CASOS DE USO E DE ANLISE (JACOBSON E CO-AUTORES, 1999).

Modelo de casos de uso Linguagem do cliente/usurio Viso externa do sistema Estruturado pelos casos de uso Contrato entre cliente e desenvolvedores sobre o que o sistema deve e no deve fazer Pode haver redundncias e inconsistncias nos requisitos Captura a funcionalidade do sistema Define casos de uso que so analisados no modelo de anlise

Modelo de anlise Linguagem dos desenvolvedores Viso interna do sistema Estruturado por classes estereotipadas e pacotes Utilizado pelos desenvolvedores para entender qual a forma do sistema, i.e., como deve ser projetado e implementado No deve haver redundncias e inconsistncias nos requisitos Rascunha como realizar a funcionalidade Define realizaes de casos de uso, cada uma representando a anlise de um caso de uso

Por que fazer anlise?

Uma pergunta recorrente por que fazer anlise ao invs de partir diretamente ao projeto e implementao? H vrias respostas que se complementam:

Antes de projetar e implementar preciso especificar os casos de uso num grau de detalhamento e de formalismo que no interessa aos usurios, s aos desenvolvedores. Anlise permite obter uma viso geral do sistema de difcil obteno se todos os detalhes de projeto e implementao fossem nela inseridos. Anlise pode envolver grandes pores do sistema sem muitos custos se comparado ao projeto e implementao. Resultados da anlise permitem planejar melhor o projeto/implementao dividindo-se o sistema em partes menores que podem ser desenvolvidos incrementalmente de maneira seqencial ou concorrente (projetado e implementado por equipes diferentes). Se o sistema em desenvolvimento utiliza um sistema legado este ltimo pode sofrer reengenharia para se obter o modelo de anlise para que os desenvolvedores o entendam sem entrar nos detalhes tecnolgicos. A reengenharia completa um processo caro, custoso e demorado que pode no ser necessrio se o sistema legado no necessita ser modificado e utiliza tecnologias obsoletas. Um modelo de anlise pode fornecer uma viso conceitual do sistema independente das tecnologias empregadas. Por exemplo, um cliente pode querer que duas fornecedoras de software faam uma proposta baseando-se em uma especificao. Outro caso seria a necessidade de implementar parte de um sistema em plataformas ou linguagens diferentes devido infraestrutura existente em filiais distintas (por exemplo, plataformas diferentes). Ainda, sistemas

33

crticos (controle de aeronaves, linhas de trem) podem necessitar de programas que realizam clculos empregando diferentes mtodos para que decises crticas s sejam tomadas quando os dois mtodos produzem resultados equivalentes.

Anlise ou no
Em relao aos modelos de anlise, pode-se dizer que h trs abordagens possveis:

Mant-lo atualizado durante todo o ciclo de vida do sistema. Consider-lo como um resultado intermedirio e, uma vez que o projeto esteja feito, atualizar o modelo de projeto. Fazer anlise e projeto integrados (recomendvel apenas para sistemas extremamente simples), h duas possibilidades: requisitos so analisados durante o levantamento ou captura: exige mais formalismo no modelo de casos de uso; requisitos so analisados durante o projeto: se os requisitos forem simples e/ou bem conhecidos.

Realizao dos casos de uso

Segundo (Jacobson e co-autores, 1999, pg. 221), se o modelo de anlise no atualizado durante o ciclo de vida do software, ou seja, foi criado apenas para possibilitar a elaborao de um bom projeto, no h realizao de casos de uso na anlise. Neste caso, a realizao do caso de uso ocorrer somente no projeto. As realizaes de casos de uso de projeto podem ser diretamente conectadas ao modelo de caso de uso por uma relao de dependncia <<trace>> (ao invs de estarem ligadas realizao do caso de uso de anlise), conforme ilustra a Figura 24.

<<trace>> Modelo de casos de uso Realizao do caso de uso (anlise)

<<trace>> Realizao do caso de uso (projeto)

<<trace>> Modelo de casos de uso

<<trace>> Realizao do caso de uso (projeto)

Figura 24: realizao dos casos de uso - anlise e projeto ou somente no projeto.

Mtodo de Anlise
De acordo com o RUP, a anlise de casos de uso composta por:

Para cada caso de uso considerado em uma iterao Criar uma realizao de caso de uso Complementar a descrio do caso de uso Levantar as classes de anlise examinando o comportamento do caso de uso Distribuir o comportamento do caso de uso entre as classes de anlise Para cada classe de anlise Descrever as responsabilidades da classe

34

Definir atributos Definir relaes entre classes

2 PADRO MVC
MVC (Model, View, and Controller) um padro de arquitetura de software. No contexto da engenharia de software, um padro uma soluo comprovada a um problema recorrente. Segundo (Gamma e co-autores, 1995), padres especificam abstraes que esto acima do nvel de classes, objetos isolados ou de componentes. As vantagens ao se utilizar padres de projeto so: ter um vocabulrio comum para a discusso de problemas e solues de projeto (Gamma et al. 1995); facilitar documentao e manuteno da arquitetura do software (Buschmann et al., 1996); auxiliar o projeto de uma arquitetura com determinadas propriedades (Buschmann et al., 1996). A idia do padro MVC desacoplar ao mximo a apresentao da aplicao (view) da lgica do negcio (business model). Muitos sistemas tornam-se complexos, pois misturam cdigo da apresentao com o cdigo da lgica do negcio. Qualquer mudana requerida pelo usurio na forma de apresentao das informaes exige tambm mudana na lgica do negcio. A camada de apresentao envolve interfaces e tambm relatrios. Atualmente, freqente a utilizao de diversas interfaces para um mesmo negcio em funo do tipo de usurio ou do tipo de dispositivo de sada. Se para cada tipo de usurio/tipo de dispositivo de sada fizermos uma lgica de negcio diferente, estaremos replicando cdigo desnecessariamente. Por exemplo, uma aplicao que mostra o extrato bancrio de uma conta corrente em diversos tipos de dispositivo tais como PC, caixa automtico, Palm e celular. A lgica do negcio sempre a mesma, juntar as transaes executadas em uma conta em um perodo, mudando apenas a forma de mostrar os dados. O padro MVC prope a diviso da aplicao em trs partes (ou camadas):

Modelo do negcio (model): contm os dados do negcio e as regras do negcio que ditam o acesso e a modificao dos dados. De forma mais prtica, encapsula os dados e os comportamentos do negcio e salva os mesmos sem se preocupar em como sero mostrados.

Viso (view): responsvel pela interao com o usurio e por apresentar as diversas vises que dos dados do negcio. No se preocupa em como os dados foram obtidos, apenas em apresentlos. Controle (controller): comanda o fluxo de obteno, encaminhamento e apresentao das informaes fazendo a intermediao entre as camadas de viso e de modelo.

A Figura 25 ilustra o modelo MVC. H duas formas bsicas, na primeira (a) os eventos/respostas da interface so tratados diretamente pela camada de viso e na segunda, pelo controle que ento seleciona a viso apropriada. O controle interpreta os eventos e informaes fornecidas pelo usurio e chama as aes que podero mudar o estado do modelo do negcio. Em seguida, as alteraes do modelo so retratadas pela camada da viso podendo ter o controle como intermedirio ou no. Normalmente, h um controlador para cada caso de uso do modelo do negcio.

35

(a)

Eventos de interface, entrada de informaes

aes Estado modelo

Viso

Controle

Modelo do negcio

Eventos e respostas gerados pelo modelo

(b)
Eventos de interface, entrada de informaes aes Estado modelo

Viso

Controle

Modelo do negcio

Viso selecionada

Eventos e respostas gerados pelo modelo

Figura 25. Modelo MVC nas duas formas possveis.

O modelo MVC bastante utilizado em aplicaes WEB. Um servio pode ser chamado a partir de diferentes clientes tais como celulares, PCs e Palms. A lgica do negcio, no entanto, permanece a mesma independente do cliente. Normalmente, nas aplicaes WEB o servidor escolhe a viso mais apropriada como mostra a Figura 26. Observar que os servidores no so necessariamente mquinas distintas. Existe um framework chamado Struts que diminui o esforo de desenvolver uma aplicao Web segundo o padro MVC. Framework uma coleo de interfaces e classes para auxiliar o desenvolvimento e manuteno de aplicaes.
Servidor web Cliente HTML Cliente Celular Servidor de aplicao

Controlador

Modelo do negcio

Cliente Palm

Figura 26. Padro MVC numa aplicao WEB.

36

3 PADRO OBSERVADOR
O objetivo do padro observador (Gamma e co-autores, 1995, pg. 294) reduzir o acoplamento entre classes. Podemos utilizar este padro em conjunto com o MVC para desacoplar as classes da camada de viso das do modelo. Este o desacoplamento mais importante, pois separar as classes de controle das de viso nem sempre uma tarefa evidente. Suponha que os dados do modelo devem ser vistos de vrias maneiras (por meio de diferentes interfaces), mas de maneira sincronizada, ou seja, cada mudana nos dados do modelo deve ser refletida igualmente em todas as interfaces. Neste caso o padro observador til, pois as classes do modelo no necessitam saber quantas e quais classes da camada de viso dependem delas. Segundo (Gamma et al., 1995), o padro observador til nas situaes seguintes:

Quando uma modificao em um objeto implica modificaes em outros e no se sabe quantos objetos precisam ser modificados. Quando um objeto deve ser capaz de notificar outros objetos, mas sem pressupostos sobre os objetos a serem notificados.

4 CLASSES DE ANLISE
Em um diagrama de classes so definidas as classes de objetos, suas operaes e atributos e as relaes entre classes. A dificuldade que no h mtodo ou receita para escolher as classes de um sistema. uma tarefa que depende em grande parte da experincia do desenvolvedor. Nas fases iniciais do projeto, as classes so chamadas de classes candidatas ou de anlise, pois h grande probabilidade que mudem ao longo do projeto. Com base no padro de projeto MVC, uma primeira aproximao das classes necessrias ao sistema pode ser feita. Antes de explicar como fazla, apresenta-se a notao de classes e alguns esteretipos de classes.

4.1

Notao UML para Classes

Uma classe representada por um retngulo dividido em trs compartimentos como ilustra a figura 27. Os compartimentos de atributos e mtodos so opcionais (figura 28). Um esteretipo define um tipo para a classe.

<<esteretipo>> NomeClasse atributos mtodos

Figura 27: notao para classe.

Figura 28: notao de classe sem atributos e mtodos.

4.1.1 Atributos
A sintaxe para declarao de um atributo em UML segue o formato:

37

[<visibilidade>]<nome>[<multiplicidade>]:[<tipo>][=<valor inicial>] <visibilidade>: + pblico, todas as classes tm acesso; - privada, somente mtodos definidos na classe podem v-lo; # protegido, mtodos definidos na classe e nas classes derivadas podem v-lo; ~ pacote, visvel dentro das classes de um pacote. <nome>: nome do atributo <multiplicidade>: por exemplo, valores[5] ou matriz[4, 6] <tipo>: pode-se utilizar os tipos da linguagem de implementao. Por exemplo, char, float ou int. <valor inicial>: valor inicial para o atributo que respeite o tipo de dado.

Exemplos - nome: String - sexo: char=f + cdigo: int=20

4.1.2 Mtodos
Sintaxe para declarao de um mtodo em UML: [<visibilidade>]<nome>(<lista argumentos>):[<retorno>] <visibilidade>: + pblico, todas as classes tm acesso; - privada, somente mtodos definidos na classe podem v-lo; # protegido, mtodos definidos na classe e nas classes derivadas podem v-lo; ~ pacote, visvel dentro das classes de um pacote. <nome>: nome do mtodo <lista de argumentos>: (<nome_argumento>:<tipo>, ..., <nome_argumento>:<tipo>). Por exemplo, (nome:String, idade: int) <retorno>: tipo do dado retornado. Pode-se utilizar os tipos da linguagem de implementao. Por exemplo, char, float ou int.

Exemplos - calcularIdadeEmMeses(Data dataNasc): int +moverPara(x:int, y:int):void

4.1.3 Categorias de responsabilidades: esteretipos

De maneira geral, um esteretipo deixa clara a funo de um componente em um diagrama. possvel definir seus prprios esteretipos o que permite estender a UML. No diagrama de classes h trs esteretipos bastante utilizados que designam a responsabilidade das classes: <<entidade>> ou <<entity>> <<controle>> ou <<control>> <<fronteira>> ou <<boundary>> Estes esteretipos so oriundo do trabalho de Ivar Jacobson (1992) sobre Anlise de Robustez. Basicamente, a anlise de robustez permite determinar preliminarmente as classes de anlise baseando-se nas descries dos casos de uso.

38

Classes entidade
utilizado em classes que armazenam informaes do domnio a longo-prazo. Objetos destas classes so normalmente persistentes, mas no uma regra geral. Frequentemente estas classes se encontram na camada do modelo, por isso no dependem (ou ao menos no deveriam depender) do contexto onde o sistema est inserido. Pode tanto refletir uma entidade do mundo real ou uma entidade necessria ao funcionamento interno do sistema. Classes com este esteretipo podem ser representadas pelo cone alternativo2 da figura 29.

Figura 29: cone alternativo para classes <<entidade>>.

Classes de fronteira
utilizado em classes que realizam a interao entre sistema e ator (humano ou no). So classes que dependem do contexto onde o sistema est inserido, dado que o contexto dado justamente pelas interaes com o mundo externo. Classes de fronteira representam, por exemplo, protocolos de interao com outros sistemas, interfaces com usurios, interao entre sistema e dispositivos. Classes com este esteretipo podem ser representadas pelo cone da figura 30. Segundo (Jacobson e co-autores, 2002), se uma classe <<fronteira>> j foi designada para um ator humano, o desenvolvedor deve tentar reutiliz-la para minimizar o nmero de janelas que o ator utiliza.

Figura 30: cone alternativo para classes <<fronteira>>.

Esteretipo de controle
utilizado em classes que encapsulam o controle/lgica de um caso de uso, ou seja, aquelas que comandam a execuo de um caso de uso fazendo a ligao das classes de fronteira com as de entidade. Normalmente so dependentes da aplicao. Classes com este esteretipo podem ser representadas pelo cone da figura 31. Em alguns casos, a lgica do caso de uso pode ser muito complexa e exigir mais de uma classe de controle. Em outros, a lgica comanda pelo ator e neste caso, a classe de controle e de fronteira podem ser unificadas como fronteira.

Figura 31: cone alternativo para classes <<controle>>.

Robustness Analysis Icon

39

4.2

Linhas Mestras

Para identificar as classes candidatas seguindo o padro de projeto MVC, executar os passos seguintes: Definir uma classe de fronteira para cada par ator-caso de uso Definir uma classe de controle para cada caso de uso Definir classes de entidade: procurar substantivos nos casos de uso e pontos onde h um conjunto de dados que possuem unidade (objeto).

Estas linhas so extremamente gerais e, portanto, sujeitas a adaptaes em funo do problema em mos. Por exemplo, se a fronteira com um ator for extremamente simples pode-se conjugar controle e fronteira. Se o controle para todos os casos de uso for extremamente simples, pode-se coloc-los numa s classe de controle.

5 EXEMPLO
O levantamento de classes de anlise mostrado por meio de um exemplo didtico cujo enunciado o seguinte:
Um meteorologista necessita de um programa simples que faa converses de temperaturas em graus Celsius para Fahrenheit. Ele deseja armazenar as 10 ltimas converses realizadas, denominadas no seu todo histrico, e visualiz-las constantemente numa janela independente daquela destinada a fazer a converso. Se por acaso o usurio fechar a janela do histrico, ele deve ter algum modo de reabri-la. Uma converso formada pela data, hora, valor em Celsius e em Fahrenheit.

A partir do enunciado, elaborou-se o diagrama de casos de uso da figura 53. Notar que no preocupao com a ordem de execuo dos casos de uso e com o fluxo de dados (o fato de consultar histrico utilizar os mesmos dados manipulados por atualizar histrico).

Figura 32: Diagrama de casos de uso para conversor de graus Celsius para Fahrenheit. TABELA 5: DESCRIO DO CASO DE USO CONVERTER.

Nome do caso de uso Descrio Ator Envolvido Pr-condies Ps-condies Fluxo Bsico Ator Solicitar converso de uma temperatura em graus Celsius

Converter Celsius Fahrenheit Permite ao meteorologista realizar vrias converses de Celsius para Fahrenheit e as armazena em um histrico. Meteorologista Sesso iniciada Converso realizada Sistema

{Obter valor}

40

Solicita o valor a ser convertido Fornece valor a ser convertido Obtm o valor {Validade valor entrada} Realizar a converso Executar subfluxo Atualizar Histrico Mostrar temperatura em Fahrenheit Se o usurio deseja continuar, voltar ao ponto {Obter valor}; se no, o caso de uso termina. Fluxos alternativos e subfluxos A1: em {Validade valor entrada} S1: Atualizar Histrico Se temperatura no for numrica voltar ao ponto {Obter valor} Armazena uma converso de Celsius para Fahrenheit incluindo o valor em Celsius, o equivalente em Fahrenheit, data e hora da converso.

TABELA 6: DESCRIO DO CASO DE USO CONSULTAR HISTRICO

Nome do caso de uso Descrio Ator Envolvido Pr-condies Ps-condies Fluxo bsico Ator Solicitar visualizao

Consultar Histrico Permite ao usurio visualizar as dez ltimas converses realizadas. Meteorologista Sesso iniciada Histrico mostrado ao meteorologista. Sistema {nenhuma converso realizada} Sistema busca as ltimas dez converses realizadas ou as existentes Mostra o histrico de converso {fim} O caso de uso termina.

Fluxos alternativos A1: em {nenhuma converso realizada} Se no houver converses no histrico mostrar mensagem nenhuma converso realizada at o momento e ir para o ponto {fim}

Aps a elaborao do diagrama de casos de uso, fez-se uma primeira tentativa de identificar classes de anlise seguindo as linhas mestras. Na figura 33, as linhas mestras foram seguidas risca.

41

class Classes de anlise (lev antamento)

IUConversao

CtrlConversao

Historico

IUHistorico

CtrlHistorico

ConversaoCF

Figura 33: Levantamento das classes de anlise.

6 EXERCCIOS
1. Considere um caso de uso chamado efetuar operaes aritmticas para uma calculadora. Analise as responsabilidades e o comportamento de uma classe de controle para este caso de uso frente a duas implementaes para a classe <<entidade>> calculadora cujo comportamento descrito abaixo: a. capaz de efetuar operaes binrias, por exemplo, somar(2, 3), subtrair (5, 4), etc. b. capaz de avaliar sintaticamente e executar expresses aritmticas, por exemplo, 2 + 3/5. Qual o auxlio trazido pelo padro observador ao modelo MVC? Fazer o levantamento das classes candidatas para os exerccios do captulo anterior (pg. 31): a. Biblioteca b. Jogo da forca e da velha c. Escritrio de advocacia

2. 3.

42

ESTUDO DA INTERAO ENTRE OBJETOS

O projeto de um sistema pode ser visto como sucessivos refinamentos de diviso de responsabilidades. Nos casos de uso, so identificadas as funcionalidades do sistema separando-as do que externo ao mesmo. Em seguida, so levantadas as classes de anlise, o que representa uma primeira tentativa de identificar quem dentro do sistema far o qu para que os casos de uso se concretizem. Os diagramas de interao constituem um passo importante nesta diviso, pois detalham como os objetos das classes de anlise e, por consequncia, quais operaes cada um deve realizar. Se um caso de uso possui vrios fluxos, pode ser til criar um diagrama de interao para cada cenrio. Os diagramas de interao mais utilizados so o de sequncia e o de comunicao (ex-colaborao). Diagramas de interao so usados tanto na anlise quanto no projeto. Na anlise as comunicaes entre objetos so mais abstratas, no importando muito os argumentos e valores retornados. No projeto, o detalhamento maior

1 DIAGRAMA DE SEQUNCIA
Relembra-se que cada caso de uso representa uma funcionalidade do sistema vista da perspectiva de um ator. Um caso de uso pode apresentar diversas possibilidades de execuo visto que h fluxos primrios (fluxo normal de eventos) e alternativos (o que fazer se). Estes fluxos so documentados textualmente ou na forma de uma tabela ator x sistema. Cenrios so utilizados para identificar como uma sociedade de objetos interage para realizar um caso de uso. Cenrios documentam as responsabilidades, ou seja, como as responsabilidades especificadas nos casos de uso so divididas entre os objetos do sistema. Portanto, um cenrio uma instncia de um caso de uso: um caminho entre os muitos possveis. Cenrios podem ser representados por diagramas de seqncia e pelos diagramas de colaborao. Um diagrama de seqncia representa os atores e objetos envolvidos num cenrio e a seqncia de troca de mensagens ao longo do tempo para realizar o cenrio. Um diagrama de seqncia permite identificar os mtodos e atributos de cada classe assim como as responsabilidades de cada classe na realizao de um caso de uso. Os elementos bsicos de um diagrama se seqncia so Atores Objetos Linha do tempo (uma para cada objeto e ator) Comunicao entre ator e objeto ou entre objetos Interpretao das mensagens: por exemplo, evento do sistema operacional ou de uma interface, envio de mensagem ou chamada de mtodo

43

sd Interao

objeto
:A usurio :B

sncrona

ativao

resposta assncrona

Linha da vida

Figura 34: exemplo de diagrama de seqncia.

1.1

Tipos de mensagem

H vrios tipos de mensagem que podem ser utilizados num diagrama se seqncia, sendo os mais comuns os seguintes (figura 34):

Simples: quando o tipo de mensagem irrelevante ou ainda no foi definido. Sncrona: quando enviada, o emissor fica bloqueado aguardando a resposta. Assncrona: o emissor no bloqueia at que o receptor enviar resposta para continuar seu processamento. Retorno ou resposta: resposta mensagem sncrona; pode ser omitida

Uma mensagem definida sintaticamente por: expresso-seqncia recorrncia: v := mensagem Expresso-seqncia: um nmero seqencial de envio das mensagens. Por exemplo, 1: msg1 2: msg2 representando que a mensagem msg1 precede a msg2. Pode-se utilizar nveis: 1.1: msg1 1.2: msg2 representando que msg1 e msg2 foram enviadas aps recebimento de uma mensagem 1. Para representar mensagens concorrentes, pode-se utilizar letras: 1.1a: msg1 1.1b: msg2 significando que msg1 e msg2 so enviadas concorrentemente. Recorrncia: indica um envio condicional ou uma repetio. Zero ou mais mensagens so enviadas dependendo da condio envolvida. As opes so: *[clusula-iterao] ou [guarda] No h sintaxe rgida definida pela UML, a clusula de interao e a condio de guarda podem ser especificadas em pseudocdigo ou na linguagem alvo. Exemplos:

44

[x > y] msg: mensagem msg enviada somente se x > y *[i:=1..10] msg: mensagem msg enviada 10 vezes. *[x > 0] msg: enquanto x for maior que zero enviar mensagem msg. Receber valor de retorno: possvel receber um valor de retorno e atribu-lo a uma varivel. x:=obter()

1.2

Linha da Vida

So linhas verticais que representam o tempo de vida de um objeto. Um X na linha denota o fim da existncia do objeto. Objetos no topo do diagrama so considerados criados desde o incio.

1.3

Ativao

Uma ativao (um retngulo sobre a linha da vida) representa o perodo durante o qual um objeto est em execuo diretamente ou indiretamente. Direta, se estiver executando um mtodo ou indireta, se chamou um mtodo e est bloqueado aguardando o retorno. A ativao mostra a durao das operaes nos objetos e o fluxo de controle entre o objeto invocador e o invocado.

1.4

Alt

Equivale ao if-else.
sd Interao :A usurio x alt v erifica x [x>0] msg1 :B

[x<=0] msg2

Figura 35: exemplo de alt no diagrama de seqncia. O mesmo comportamento pode ser representado atravs de uma condio de guarda in-line como ilustra a figura 36.

45

sd Interao :A usurio x [x>0]: msg1 [x<=0]: msg2 :B

Figura 36: exemplo de condio de guarda no diagrama de seqncia.

1.5

Opt

Opcional: equivale ao if (sem else).

sd Opt :A usurio :B

x opt testa x [x > 0]

msg1 msg2

msg3

Figura 37: exemplo de opt.

1.6

Loop

Permite representar laos.

sd Loop :A usurio x loop notificaes [x >= 0] :B

msg1 msg2

Figura 38: exemplo de loop em diagrama de seqncia.

46

Repeties tambm podem ser representados inline. Na Figura 39 est representado que a mensagem msg1 enviada vrias vezes (*) enquanto x for maior ou igual a zero. Ao fazer a chamada msg1, o objeto da classe A recebe como resposta um inteiro e o armazena na varivel x.

sd Loop in-line :A usurio x [x>=0]: * x= msg1 :int :B

Figura 39: exemplo de loop inline.

A sintaxe especificada no UML Superstructure (7/2/2005) para loop definida como: loop[( <minint> [, <maxint> ] )] <minint> ::= natural no negativo <maxint> ::= natural no-negativo maior ou igual <minint> | * significa infinito. Se somente <minint> for definido, significa que <minint> = <maxint> = <inteiro>. Se somente loop for definido, ento representa um lao com limite superior infinito e limite inferior igual a zero. Exemplo: loop[(0, 10)] define um lao com 11 repeties

1.7

Ref

Permite fazer referncias a outros diagramas. Observar no diagrama referenciado que o resultado retornado foi representado como um objeto. Para fazer referncia ao diagrama em questo, basta colocar um fragmento ref inline. O fragmento ref substitudo por uma rplica do diagrama referenciado onde os argumentos substituem os parmetros.

Figura 40: exemplo de referncia a outro diagrama (ver figura 41)

47

sd Verificar x(int x):Resultado :A :B Resultado

alt trata x [x < 0] [x > 0]

msg1 setTo(NEGATIVO) msg2 setTo(POSITIVO)

[x = 0]

msg3 setTo(ZERO)

Figura 41: exemplo de diagrama referenciado.

1.8

Criar e destruir

possvel mostrar a criao e a destruio de objetos num diagrama de seqncia. Objetos que so criados e destrudos so chamados de transientes.

Figura 42: exemplo de objeto transiente (CartItem).

1.9

Linhas Mestras

Um diagrama de seqncia deve ter certa distncia do cdigo fonte, no preciso representar todos os detalhes do cenrio. Algumas dicas: mant-lo simples; condies de guarda: se forem poucas devem ser colocadas em um s diagrama, caso contrrio fazer um novo diagrama s para mostr-las; os diagramas podem ser ligados entre si (ref).
Em algumas ferramentas possvel gerar automaticamente a primeira verso do diagrama de seqncia. Por exemplo, no Rational Rose, se o fluxo de evento foi definido, basta clicar com o boto da direita em cima do caso de uso e escolher generate sequence diagram.

48

2 DIAGRAMA DE COMUNICAO
Diagrama de comunicao (antes da verso 2.0 era chamado colaborao) outra forma de representar um cenrio: contm as mesmas informaes que o diagrama de seqncia, mas no considera a dimenso temporal. Alguns autores recomendam utiliz-lo para analisar a colaborao das classes de realizao de um caso de uso (Jacobson e co-autores, 1999), pois facilita a identificao das classes que colaboram de forma mais prxima e, por conseqncia, a identificao de pacotes de anlise.
Visual Paradigm: Para gerar automaticamente este diagrama a partir do de seqncia clicar com o boto da direita no pano de fundo do diagrama de seqncia e escolher to collaboration diagram.

No diagrama de comunicao, a ordem de envio das mensagens dada por nmeros seqenciais ( possvel utiliz-los no diagrama de seqncia tambm). A figura 43 mostra um exemplo de diagrama de colaborao. Observar a restrio {transient} junto ao objeto Transaction indicando que ele criado e destrudo na interao.

Figura 43: diagrama de comunicao.

A figura 44 mostra o diagrama de seqncia equivalente ao de comunicao da figura 43.

Figura 44: diagrama de seqncia equivalente.

49

3 EXEMPLO
Retoma-se o exemplo do conversor de graus Celsius para Fahrenheit. O cenrio fluxo bsico + subfluxo atualizar histrico mostrado na figura 45. Observar que o diagrama bastante informal, sem preocupao com argumentos de mtodos, criao e destruio de objetos, armazenamento em banco de dados ou sistema de arquivos e se h lugar ou no no histrico para guardar uma nova converso.
sd anlise casos de uso

:meteorologista :IUConv ersao :CtrlConv ersao :Historico :Conv ersaoCF

solicitar valor Celsius valor Celsius? c c converter valor c guardar conversao

mostrar valor convertido valor Fahrenheit

valor Fahrenheit

Figura 45: diagrama de seqncia para o caso realizar converso C > F.

4 PACOTES
A estrutura de uma aplicao dada pelas classes e suas relaes. Classes podem ser agrupadas em pacotes de anlise para facilitar o manuseio do modelo de anlise (lidar com partes menores) ou medida que o modelo de anlise aumenta e precisa ser decomposto. Alm de identificar os pacotes de anlise, preciso definir os servios que cada um deles fornece.

50

5 EXERCCIOS
1. No diagrama de seqncia abaixo qual a ordem das mensagens enviadas (m1 e m2):
sd Exerccio :A :B :C

3.1 *[i:=1..2] m() 3.1.1 *[i:=1..3] m2( )

2. 3. 4. 5.

Desenhe o diagrama de comunicao equivalente ao diagrama de seqncia anterior. Faa um diagrama de seqncia para representar um cliente que efetua uma retirada R$50,00 em um caixa automtico. A retirada deve ser debitada da conta corrente do cliente. Complete o exerccio anterior para permitir saques somente quando h saldo na conta corrente e se o valor do saque for inferior a R$1.000,00. Um casal tem trs filhos. Cada filho tem seu quarto. Para facilitar as tarefas matinais, o casal dispe de um relgio no quarto capaz de enviar sinais de rdio aos relgios dos filhos, mas no de receber. Ao anoitecer, o casal seta no relgio deles o horrio para despertar, idntico para todos os filhos. Ao amanhecer, na hora marcada, o relgio do casal envia o sinal de despertar para cada um dos relgios dos filhos. Desenhe o diagrama de seqncia. Suponha o caso de uso apresentado em seguida resultante da fase de anlise de requisitos. Na fase de anlise (realizao dos casos de uso) sua descrio pode ser detalhada sem se preocupar profundamente com a implementao. Descreva a realizao do mesmo fazendo os itens abaixo: a. Detalhe a descrio do caso de uso considerando que ele ser voltado a funcionar na web. Os clientes devem ter meios de realizar reservas on-line: i) Podem escolher a categoria de veculo ao invs de visualizar todos (passo 5).

6.

ii) Podem participar de um programa de fidelidade e, neste caso, informaes de cadastro (ou perfil) so utilizadas para pr-popular os formulrios. iii) Ao confirmar a reserva, o sistema deve mostrar os dados da mesma. iv) Se o usurio informou um endereo de e-mail vlido, o sistema envia-lhe a confirmao por email. b. c. Identifique as classes de anlise candidatas. Filtre as classes de anlise reduzindo (possivelmente) o nmero de classes candidatas

d. Identifique e descreva as responsabilidades de cada classe e possveis relacionamentos entre elas e. f. Estude a interao entre os objetos das classes Identifique possveis atributos para as classes

51

Sistema para locao de carros on-line (web) NOME: Reservar veculo DESCRIO: Este caso descreve como um cliente usa o sistema para reservar um veculo. PR-CONDIES: o cliente est conectado ao sistema. PS-CONDIES: o cliente realiza uma reserva ou no. REQUISITOS NO-FUNCIONAIS: servio acessvel pela WEB. FLUXO BSICO DE EVENTOS
1. O caso de uso inicia quando o ator cliente escolhe a opo de reservar veculo. 2. O sistema solicita ao usurio os locais, datas e horrios de retirada e de devoluo do

veculo.
3. O cliente informa os locais, datas e horrios de retirada e de devoluo do veculo. 4. O sistema pergunta ao usurio qual o tipo de veculo desejado. 5. O sistema apresenta todas as opes de tipos de veculo disponveis no local de retirada para

a data e horrios escolhidos.

6. O cliente escolhe um veculo para locar. 7. O sistema solicita informaes de identificao ao cliente (nome completo, telefone, e-mail,

bandeira do carto de crdito, data de expirao, etc.).

8. O cliente fornece as informaes de identificao solicitadas. 9. O sistema apresenta informaes sobre seguros e protees e pergunta ao cliente para aceitar

ou rejeitar cada oferta.

10. O cliente informa suas escolhas. 11. O sistema solicita confirmao da reserva. 12. O cliente aceita a reserva.

52

VI RELAES ENTRE CLASSES DE ANLISE

O diagrama de classes um dos principais diagramas da UML, representa a estrutura do sistema (elementos que foram selecionados para fazer parte do sistema). A partir dele, por exemplo, o esqueleto do cdigo fonte pode ser gerado automaticamente. Neste captulo so apresentadas as relaes mais usuais para a fase de anlise. Posteriormente, apresentam-se relaes mais prximas da implementao e, portanto, mais adequadas fase de projeto. O comportamento requerido do sistema alcanado pela colaborao entre objetos. O diagrama de classes fornece uma representao esttica da colaborao por meio de relacionamentos. Os relacionamentos so utilizados no diagrama de classes que refinado incrementalmente (modelo do domnio, anlise e, posteriormente, no projeto). So apresentadas as seguintes relaes:

associao (mais comum), agregao (um tipo de associao), generalizao/especializao

1 ASSOCIAO
uma relao entre duas classes significando que os objetos destas classes possuem uma ligao. Por exemplo, a figura 46 representa um professor leciona uma disciplina.
Professor Disciplina

leciona

Figura 46: Exemplo de associao. possvel designar que uma quantidade objetos de uma classe se relacionam com uma quantidade de objetos de outra classe por meio da notao de multiplicidade (tabela 7). As multiplicidades so colocadas nos extremos das linhas que representam as relaes.
TABELA 7:
MULTIPLICIDADE DE RELAES

Repr 1 0.. * * 1.. * 0..1 5..8 4..7,9

Significado Exatamente uma Zero ou mais Zero ou mais Uma ou mais Zero ou uma Intervalo especfico (5, 6, 7, or 8) Combinao (4, 5, 6, 7, or 9)

Por exemplo, a figura 53 interpretada como um professor leciona uma ou mais disciplinas, sendo ilimitado o nmero mximo de disciplinas. Observar que no lado do Professor a multiplicidade igual a 1, ento a participao de objetos Professor no relacionamento leciona obrigatria, ou seja, um professor s pode existir se estiver associado a uma disciplina.

53

Professor

leciona

1..*

Disciplina

Figura 47: Exemplo de multiplicidade em associao.

Navegabilidade
As associaes podem opcionalmente direcionadas. No exemplo abaixo, a partir de um professor pode-se chegar a uma disciplina, mas o caminho inverso no possvel o que indicado pelo X sobre a associao.
Professor leciona Disciplina

Figura 48: associao unidirecional. Para representar uma associao bidirecional, navegvel nos dois sentidos, utiliza-se uma flecha bidirecional. Para facilitar a leitura, pode-se indicar a direo da mesma (tringulo ao lado do nome da associao).
Professor leciona Disciplina

Figura 49: associao bidirecional. Se no h definio sobre a navegabilidade pode-se deix-la no-especificada. Neste caso, no se deve utilizar flechas. Por exemplo, a figura 50 representa uma associao 1:1 de navegabilidade noespecificada.
Professor leciona Disciplina

Figura 50: associao no-especificada.

Papis
Podemos associar papis s associaes para clarificar as responsabilidades dos objetos participantes. A figura 51 ilustra uma associao entre Empresa e pessoa. Para evitar um nome ambguo de associao pela utilizao de papis. Por exemplo, o nome trabalha pode ser interpretado como: pessoa trabalha para Empresa empresa trabalha (presta um servio) para Pessoa; O nome emprega pode ser interpretado como: empresa emprega Pessoa; pessoa emprega (contrata) Empresa Assim, para representar os dois primeiros itens pode-se utilizar papis, a Empresa desempenha o papel de empregador de Pessoa e Pessoa, empregado.

54

Empresa

Trabalha ou emprega ?

Pessoa

Empresa

empregador

empregado

Pessoa

Figura 51: Papis nas relaes.

1.1

Associao reflexiva

Os objetos de uma classe podem se relacionar com objetos da mesma classe. Por exemplo, uma relao do tipo pai-filho ou chefe-empregado cada objeto desempenha um papel diferente. Neste tipo de associao freqente a utilizao de papis ao invs de nome de associao para evitar ambigidades na leitura. Na associao reflexiva da classe Pessoa (figura 52), a interpretao a seguinte: uma pessoa tem zero ou um pai e uma pessoa pode ser pai de vrios filhos. A multiplicidade zero no papel filho permite que mulheres e homens sem filhos no participem desta associao. A multiplicidade zero no papel pai pode parecer estranha, pois todo filho tem um pai, porm, se colocarmos 1 na multiplicidade, todos os pais do mundo teriam que ser representados no sistema.

Pessoa

filho 0..*

Empregado

subordinado 0..*

pai

0..1

gerente

Figura 52: Exemplos de associaes reflexivas. Na associao reflexiva da classe Empregado (figura 52), a interpretao a seguinte: um empregado que desempenha o papel de gerente tem zero ou mais subordinados. Pode parecer estranho um gerente sem subordinados, mas se colocssemos 1 ao invs de zero na multiplicidade no lado do papel subordinado, todo empregado teria que ter ao menos um subordinado. Portanto, este zero significa que empregados que no desempenham o papel de gerente no precisam estar associados a subordinados. No sentido contrrio, todo empregado est associado a exatamente um gerente. Neste caso, define-se que um gerente subordinado a ele mesmo no nvel mais alto da hierarquia, por isso podemos deixar multiplicidade igual a 1 no lado gerente.

1.2

Classes associativas

Quando uma relao associativa possui atributos prprios pode-se criar uma classe associativa. Estas classes so teis quando queremos armazenar o histrico de uma associao (relacionamentos que ocorrem e interessam serem salvos). No exemplo abaixo (figura 53) quando existir uma associao entre uma instncia de aluno e uma de turma haver tambm uma instncia de inscrio para armazenar o resultado escolar.

55

Figura 53: Exemplo de classe associativa.

Algumas caractersticas das classes associativas: Classes associativas so comuns em relaes de multiplicidade *:*, embora no seja uma regra definitiva. A linha que representa a associao no nomeada, o nome da classe associativa deve ser suficiente para identificar a relao. Classes associativas podem estar relacionadas a outras classes.

1.3

Relaes Ternrias

possvel representar em UML relaes entre objetos de trs ou mais classes. No exemplo abaixo, est representado o fato de um professor lecionar numa sala para vrios alunos (o professor sempre utiliza a mesma sala).

Figura 54: exemplo de relao ternria. Podemos ter classes associativas tambm nas associaes mltiplas. No exemplo abaixo, o jogador participa de vrios times ao longo de uma temporada, para cada participao num time armazena-se os dados de gols marcados, gols levados, vitrias e derrotas do time.

56

Figura 55: exemplo de relao ternria com classe associativa.

1.4

Levantamento das associaes

Normalmente as associaes vem as regras do negcio, dos requisitos funcionais e dos diagramas de interao. Por exemplo, em uma universidade prtica comum que cada professor tenha entre zero e quatro turmas. Em uma biblioteca, alunos no podem emprestar mais de quatro livros ao mesmo tempo.
Aluno 0..1 Empresta 0..4 Livro

Figura 56: associao capturada a partir de uma regra do negcio. Ao observar o diagrama de seqncia da converso de graus Celsius para Fahrenheit (figura 45, pg. 50), possvel identificar as seguintes classes esto de alguma forma associadas:

IUConverso e CtrlConverso CtrlConverso e ConversoCF ConversoCF e Histrico

O diagrama de classes de anlise pode ser enriquecido com estas relaes e com outras provenientes do diagrama de seqncia do caso de uso Visualizar histrico produzindo o diagrama de classes de anlise da figura 57. Observar que as associaes que envolvem classes de controle e de fronteira no so nomeados, pois apresentam uma mesma semntica: comunicao.

57

class Classes de anlise (associaes)

1 IUConversao

1 ConversaoCF pertence 0..10 1

CtrlConversao

1 :IUHistorico

1 CtrlHistorico

1 Historico

Figura 57: classes de anlise do conversor Celsius-Fahrenheit com associaes.

2 AGREGAO
um caso especial de associao utilizada para representar relacionamentos de pertinncia (parte de). Permite representar o fato que um objeto ou mais objetos de uma classe fazem parte de um objeto de outra classe. Um exemplo tpico uma janela de interface com o usurio composta por diversos botes, campos texto, scrolls bars, etc. A agregao representa uma ligao entre o objeto o todo (a janela) e as partes (Boto, ComboBox, ScrollBar). Um comportamento que se aplica ao todo se propaga as partes, por exemplo, ao movimentar a janela, todos seus elementos de deslocam tambm.
class Classe

Janela

1 1 3 Boto 1 ComboBox

1 0..1 ScrollBar

Figura 58: exemplo de agregao.

2.1

Notao

Podem-se incluir nomes, papis, multiplicidades e navegabilidades, enfim aceita todos os adornos de uma relao de associao.

2.2

Multiplicidade

Frequentemente ser 1 do lado da classe todo visto que um objeto normalmente parte de um s objeto. Porm, h diversas excees como o exemplo da figura 59. Nela representa-se que um time composto por vrios jogadores (inclusive por nenhum) e que um jogador pode participar de vrios

58

times. Observar tambm a representao da navegabilidade: do todo possvel alcanar todas as partes e de cada uma das partes possvel alcanar o todo.
class Classe

Time * *

Jogador

Figura 59: Exemplo de agregao com multiplicidade.

2.3

Tipos de agregaes

Nos exemplos anteriores, foram utilizados dois tipos de agregaes, de composio e de associao, representadas respectivamente por losangos preenchidos e vazios.

Composio (composite aggregation)

uma agregao de fato, o todo composto pelas partes. Existe uma relao forte entre o todo e as partes, pois quando o todo destrudo as partes tambm o sero, ou seja, a eliminao do todo se propaga para as partes. De outra forma, o todo e as partes tm tempos de vida semelhantes.

Associao
uma forma mais branda de agregao, embora exista uma relao de composio os todos os comportamentos so propagados para as partes. Por exemplo, uma equipe de futebol composta por vrios jogadores pode deixar de existir, mas os jogadores continuam. A figura 60 mostra um exemplo similar, onde uma turma composta por alunos (de 0 a 45). A turma pode ser destruda sem afetar a existncia dos objetos alunos dentro do sistema.

Figura 60: Exemplo de agregao por associao. No exemplo da figura 61, se destruirmos o cinema a bilheteria ser destruda. A coleo de filmes no ter o mesmo fim.

Figura 61: Exemplo de agregaes por composio e por associao.

59

2.4

Levantamento

A identificao de agregaes pode ser feita a partir de: decomposio: quando uma classe torna-se muita complexa ou extensa podemos dividi-la em vrias classes que comunicam entre si. O risco perder a viso do todo.

composio: identifica-se um conjunto de objetos que reunidos formam um objeto maior. Por exemplo, barra de rolagem, menu e text area compem uma janela. partes comuns: se duas ou mais classes apresentam um conjunto de atributos semelhantes podemos agrup-los num objeto desde que tenham uma identidade.

Figura 62: Exemplo de agregao a partir de partes comuns.

No exemplo do conversor Celsius-Fahrenheit, a associao entre a classe ConversoCF e Histrico pode ser substituda por uma agregao por composio. Se o objeto histrico destrudo todas as converses tambm o sero.
class Classes de anlise (associaes)

1 IUConversao

1 ConversaoCF 0..10

CtrlConversao

1 :IUHistorico

1 CtrlHistorico

1 Historico

Figura 63: substituio da associao entre ConversoCF e Histrico por uma agregao.

3 GENERALIZAO
A relao de especializao utilizada quando um conjunto de classes compartilha comportamentos e atributos, pode-se ento generaliz-las agrupando seus comportamentos e atributos comuns.

60

A relao de generalizao recebe muitos nomes, tais como herana e especializao. A leitura pode ser feita, partindo-se da classe base em direo a derivada, como um tipo de, uma ou um. Na figura 64, aluno (classe derivada) um tipo de pessoa (classe base).

Figura 64: exemplo de relao de generalizao/especializao.

A implementao da relao de generalizao ocorre pelo mecanismo de herana. Por herana, a classe derivada incorpora os mtodos e atributos da classe base. A classe derivada pode incluir novos mtodos e atributos e redefinir os mtodos herdados (polimorfismo de reescrita). Em UML quando repetimos a assinatura de uma operao numa classe derivada significa que temos uma nova implementao. No exemplo da Figura 65 o clculo do IPVA na classe derivada leva em conta a quantidade de cavalos do carro.

Figura 65: Relao de generalizao/especializao com reescrita de mtodo.

3.1

Hierarquia de classes

Nas classes base colocamos os atributos e operaes que so comuns a todas as classes derivadas, evita-se redundncia e facilita-se reutilizao. A figura 66 ilustra uma situao onde atributos e operaes comuns s classes Aluno e Professor foram colocados na classe base Pessoa, desta forma no preciso redeclar-las em cada uma das especializaes.

61

Figura 66: Exemplo de hierarquia de classes.

3.2

Levantamento de generalizaes

Basicamente, h duas maneiras de se identificar generalizaes: Identificao de partes comuns: a partir de classes especficas tenta-se estabelecer classes genricas. Sntese de classes base: pode-se iniciar a concepo a partir de classes abstratas tentando especializ-las.

3.3

Qualidade de uma classificao

Uma boa classificao estvel e extensvel. Estvel: os critrios de classificao no mudam ao longo do tempo. Extensvel: fcil de incluir novas classes derivadas na hierarquia. No classificar os objetos em funo de critrios que caracterizam seus estados ou critrios muito vagos como ilustra a figura 67. Ao tentar estender a hierarquia desta figura com uma janela do tipo Dialog, torna-se evidente que o critrio de classificao no foi bem escolhido.

Figura 67: exemplo de taxonomia em funo de estados.

62

Dica
Uma boa relao de herana deve respeitar o princpio da substituio: qualquer instncia da classe base pode ser substituda por uma instncia de uma classe derivada sem alterar a semntica de um programa escrito para (em funo da) a classe base.

3.4

Herana mltipla

Uma classe derivada de mais de uma classe base. Ocorre perda conceitua,l pois uma classe base no representa um caso geral completo da classe derivada, ela representa uma parte do conceito representado na classe derivada. No exemplo abaixo, Cautomovel no uma generalizao completa de Ccarro pois no leva em conta aspectos do carro ligados ao patrimnio.

Figura 68: Exemplo de herana mltipla (extrada da apostila do Paulo)

4 EXERCCIOS
1. Em relao aos relacionamentos abaixo responda: a. Qual a representao mais correta a primeira ou a segunda relao? Por qu? b. O que preciso mudar na segunda relao para representar que uma casa possui diversos proprietrios ao longo do tempo?
class Casa

Casa 0..*

propriedade 1

Pessoa

Casa

+propriedade 1..*

+proprietrio 0..*

Pessoa

63

2.

Qual a diferena de interpretao entre as duas representaes? Qual seria mais indicada para um tribunal regional eleitoral?

class eleies eleitor 0..* Pessoa vota > vota > eleitor 0..* Pessoa

candidatoPresidente 0..1

candidatoPresidente 0..1

3. 4.

Represente um e-mail na forma de um diagrama de classes. Identifique os componentes (destinatrio, assunto, etc.) e suas relaes (fazer o diagrama no editor). Qual a diferena de interpretao entre os relacionamentos livro-sobrecapa e livro-pginas?

5.

Todo aluno matriculado em trabalho de diplomao ser orientado por um professor. Alguns professores orientam vrios alunos e outros, nenhum. Qual dos diagramas melhor representa esta relao?

6. 7.

Construa uma hierarquia de classes para os seguintes tipos de obra: romance, livro de fico, livro de auto-ajuda, gibi, rock, MPB, filme fico e comdia. Um cliente pode fazer diversos contratos de locao de carros numa locadora de veculos. A locadora aluga caminhes, carros de passeio categoria A, B e C e motos. Os contratos diferem em valor e imposto segundo o tipo de veculo locado. Construa um diagrama de classes para representar as classes e seus relacionamentos. Retoma as classes de anlise e o diagrama de seqncia do exerccio 6 (pg. 51) e defina as relaes entre as classes de anlise (arquivo disponvel na pgina do curso verso Enterprise Architect).

8.

64

VII PROJETO DE CASOS DE USO

De forma geral, a atividade de projeto de casos de uso a transformao das classes de anlise em uma ou mais classes de projeto. A representao das classes na atividade de projeto muito mais prxima da implementao, ou seja, leva em conta as tecnologias que so utilizadas na implementao do sistema.

1 PROJETO
Resultados
Os resultados da atividade de projeto de casos de uso so:

Classes de projeto Operaes e atributos de cada classe Diagramas de interao para mostrar como as classes de projeto colaboram para realizar os processos do negcio capturados nos casos de uso. Arquitetura de software (SAD Software Architecture Document) Interfaces com subsistemas especficos ou software de terceiros Subsistemas

Mtodo

Criar realizaes de casos de uso: na anlise, as realizaes contm classes de anlise e objetos que aparecem em diagramas de classes e de interao. No projeto, so utilizados praticamente os mesmos diagramas, a diferena que as informaes so mais prximas da implementao. Descrever interaes entre objetos e refinar diagrama de classes Simplificar diagramas de seqncia utilizando subsistemas (opcional) Descrever comportamentos associados persistncia

2 CLASSES DE PROJETO
Na atividade de anlise, ao construir os diagramas de interao (seqncia e comunicao), considerou-se que os objetos estavam disponveis e persistidos, no havia preocupao com a criao e destruio dos mesmos e nem em acess-los e associ-los a outros objetos. Na atividade de projeto, estas questes devem ser levadas em conta. Alm disso, classes de anlise podem ser transformadas em vrias classes de projeto, reduzidas a um mtodo de uma classe de projeto, suprimidas, etc.

Classes de Anlise x Projeto

Qual a diferena entre uma classe de anlise e uma de projeto?

Uma classe de projeto especificada na linguagem de programao alvo (tipos de dados, operaes, atributos so definidos utilizando-se a sintaxe da linguagem de programao). As visibilidades dos atributos e operaes de uma classe de projeto so especificadas na maior parte das vezes.

65

As relaes entre classes num diagrama de classes de projeto influenciam diretamente na implementao destas classes. Por exemplo, associaes e agregaes so mapeadas para atributos das classes para que os objetos envolvidos possam se referenciar. Operaes das classes de projeto so traduzidas de forma direta em cdigo.

3 ESTUDO DA INTERAO ENTRE OBJETOS

Esta seo exemplifica o estudo da interao entre objetos para realizar o caso de uso converso de Celsius para Fahrenheit em uma aplicao desktop com interface textual. O intuito mostrar como refinar um diagrama de classes a partir do detalhamento do diagrama de seqncia.

3.1

Realizao Converter Celsius-Fahrenheit desktop

O diagrama de seqncia representa o cenrio onde o meteorologista realiza vrias converses de Celsius para Fahrenheit que so guardadas numa coleo denominada histrico. Ao decidir encerrar a sesso, o histrico persistido em disco por meio de um objeto serializvel.

66

 sd conv erter c-f

:meteorologista :CtrlConv ersao

:IUConv ersao :Historico loop [!FIM] solicitarCelsius() :float Celsius?

c c ConversaoCF(c) conv :Conv ersaoCF adicionar(this) mostrar(conv.getFahr()) conv.Fahr

salvar() writeObject

Figura 69: Diagrama de seqncia (converter Celsius-Fahrenheit textual).

Das colaboraes expressas na Figura 69, pode-se derivar o seguinte diagrama de classes de projeto.

67

class classes conv erter boundary IUConv ersao ~ ~ mostrar(float) : void solicitarCelsius() : float

control CtrlConv ersao

1 instantiate 1

interface Serializable

1 instantiate instantiate 1 entity Conv ersaoCF + celsius: float Horario: Date getFahr() : float + 1 entity Historico adicionar(ConversaoCF) : void writeObject() : void

0..10 {ordered}

Figura 70: Diagrama de classes de projeto (converter Celsius-Fahrenheit textual).

Observar que as associaes entre CtrlConversao e as demais classes foram transformadas em dependncias. Deixou-se claro que Histrico implementa (realiza) uma classe de interface serializvel. Histrico uma coleo ordenada de objetos ConversaoCF. Os atributos e operaes tambm possuem tipos de dados compatveis com Java (a suposta linguagem de implementao) e visibilidades. importante notar que as mensagens que chegam num objeto so transformadas em operaes (ex. solicitarCelsius() transformada numa operao em IUConversao). Neste exemplo didtico, as classes de anlise no sofreram grandes modificaes. Tambm no houve necessidade de dividir o sistema em subsistemas ou pacotes.

4 REFINAR O DIAGRAMA DE CLASSES

A partir dos diagramas de seqncia de projeto, detalham-se as relaes do diagrama de classes. Alguns refinamentos no diagrama de classes podem ser feitos em funo da implementao desejada.

4.1

Dependncia

Uma relao de dependncia indica que uma classe depende do auxlio de outra classe para implementar seus comportamentos. um relacionamento utilizado prioritariamente na fase de projeto. Dadas duas classes A e B, as dependncias possveis entre elas podem ser assim resumidas:

Varivel local: Classe A utiliza em alguma operao uma varivel de tipo B Parmetro de operao: Classe A utiliza como parmetro de alguma operao cujo tipo B. Instanciao: a Classe A instancia um objeto de B.

Para representar os tipos de dependncia ilustrados, esteretipos podem ser utilizados (figura 71).

68

class Dependncia

ClasseA + operacao(ClasseC) : void local

ClasseB

parameter instantiate

ClasseC

ClasseD

Figura 71: Alguns tipos de dependncia.

4.2

Implementao de associaes e agregaes

No h diferena entre a implementao de uma associao e uma agregao. Portanto, o texto que segue serve indistintamente para os dois tipos de relaes. Tambm no h diferenas significativas entre uma agregao por associao e uma agregao por composio. Nesta ltima, a lgica da classe todo deve garantir que os comportamentos se propagam em direo s partes sempre que necessrio. Em uma composio, uma parte exclusiva do todo e, portanto, no deve participar de outras agregaes.

Multiplicidade 1:1 e variaes

Associaes unidirecionais de multiplicidade 1:1 so de simples implementao: basta colocar um atributo na classe origem da relao. Se a relao for bidirecional, coloca-se um atributo em cada uma das classes que participam da associao.
class Classe

ClasseA 1 1

ClasseB

Figura 72: Implementao de uma associao unidirecional de multiplicidade 1:1

O cdigo abaixo ilustra uma implementao possvel para a associao da figura 72.
1 2 3 4 5 class ClasseA { Private ClasseB objB = new ClasseB(); // pode ser instanciado em outro local // outros atributos // mtodos }

O cdigo abaixo ilustra uma implementao para uma associao bidirecional de multiplicidade 1:1.
1 2 3 4 5 6 7 8 9 class ClasseA { Private ClasseB objB = new ClasseB(); // pode ser instanciado em outro local // outros atributos // mtodos } class ClasseB { Private Classe objA = new ClasseA(); // pode ser instanciado em outro local // outros atributos // mtodos

69

10

Multiplicidade 1:* e variaes

Quando a multiplicidade mxima menor que infinito (e no muito grande) pode-se alocar espao na instanciao do objeto do lado 1 e povoar o vetor neste instante ou posteriormente.
class Professor

Professor leciona 0..1 0..5

Disciplina

Figura 73: associao de multiplicidade 0..1:0..5

Por exemplo, para a associao representada na figura 73 as seguintes implementaes so possveis.

1 2 3 4 5 6 7 class Professor { private Disciplina[] disciplinas = new Disciplina[5]; // aloca espao para 5 objs public void adicionarDisciplinas(Disciplina[] disc){ // inicializar vetor disciplinas com parmetro disc } }

1 2 3 4 5 6 7 8 9 10

class Professor { private Disciplina[] disciplinas = { // instancia os objetos disciplina new Disciplina(), new Disciplina(), new Disciplina(), new Disciplina(), New Disciplina(), }; }

Quando multiplicidade mxima for igual a * (figura 74) recomenda-se utilizar uma coleo parametrizada como ilustra o cdigo seguinte.
class classes

Professor 1 *

Disciplina

Figura 74: associao de multiplicidade 1:*

1 2 3 4 5 6 7 class Professor { private Vector<Disciplina> disciplinas = new Vector<Disciplina>(4, 2); public void adicionarDisciplinas(Disciplina[] disc){ disciplinas.add(disc[0]); ... } }

Dica Enterprise Architect: para gerar cdigo nesta situao, em tools>options>Java>[Collection classes], definir Vector como default collection class. Nas propriedades da associao, no lado target (*), colocar Member Type = Vector<Disciplina>.

70

Multiplicidade *:*
A implementao de associaes com multiplicidade *:* envolve a utilizao de colees. Para o exemplo da figura 75, utilizou-se a coleo Vector. Em seguida, mostra-se o cdigo Java correspondente.
class muitos para muitos

Proj eto

+emprega 0..*

+participa 0..*

Pessoa

Figura 75: Associao muitos para muitos.

1 2 3 4 5 1 2 3 4 public class Projeto { public Vector<Pessoa> participa; ... } public class Pessoa { public Vector<Projeto> emprega; ... }

Associaes reflexivas
O mapeamento para Java de uma associao reflexiva no difere dos mapeamentos entre duas classes distintas.
class associao reflexiv a

+temPrerequisito 0..* Professor 1 * Disciplina

+preRequisito 0..*

Figura 76: Associao reflexiva muito para muitos.

A implementao da classe Disciplina ilustrada no cdigo seguinte:

1 2 3 4 5 6 7 public class Disciplina { public Vector<Disciplina> temPrerequisito; public Vector<Disciplina> preRequisito; ... }

Classes associativas
Classes associativas podem ser transformadas em classes comuns e, a partir da, as associaes caem nos casos anteriores. Por exemplo, a figura 77 ilustra um caso onde um projeto pode ter vrias pessoas e uma pessoa pode participar de vrios projetos. Cada participao possui uma carga horria, data de entrada no projeto e de sada.

71

class classe associativ a

Proj eto

Pessoa +emprega 0..* +participa 0..*

Participacao cargaHoraria: int dataEntrada: Date dataSaida: Date

Figura 77: Classe associativa.

O diagrama anterior poderia ser representado da seguinte forma

class classe associativ a (proj )

Proj eto possui 1 0..* -

Participacao cargaHoraria: int dataEntrada: Date 0..* dataSaida: Date

participa 1

Pessoa

Figura 78: Classe associativa transformada em classe normal.

A implementao correspondente ao diagrama da figura 78 ficaria:

1 2 3 4 1 2 3 4 1 2 3 4 5 6 7 8 public class Projeto { public Vector<Participacao> ... } public class Pessoa { public Vector<Participacao> ... } m_Participacao;

m_Participacao;

public class Participacao { private int cargaHoraria; private Date dataEntrada; private Date dataSaida; public Projeto projeto; // se relao for bidirecional Public Pessoa pessoa; // se relao for bidirecional ... }

Agregao por composio

uma agregao de fato, a criao/alocao de um objeto feita dentro de outro. Existe uma relao forte, pois quando todo destrudo as partes tambm o sero, ou seja, a eliminao do todo se propaga para as partes. O todo e as partes agregado tm tempos de vida semelhantes.

72

class agregao por composio

HistoricoPagsWeb 1 0..* -

URLVisitada URL: String

Figura 79: Agregao por composio.

A seguir duas implementaes possveis para a composio da figura 79. Um histrico uma agregao de URLS visitadas, portanto, uma vez que o histrico destrudo as instncias de URLs visitadas tambm o sero. Em Java no h necessidade de destruir os objetos devido ao Garbage Collection. Todos os objetos criados so eliminados da memria quando no so mais referenciados por nenhuma varivel, portanto na implementao da agregao por composio no precisamos nos preocupar com a igualdade dos tempos de vida do todo e das partes.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 class URLVisitada { private String url; URLVisitada (String url) { this.url = url; } } class Historico { // cria trs objetos da classe URLVisitada private URLVisitada[] historico = { // poderia ser com alguma coleo new URLVisitada("http://www.uol.com.br"), new URLVisitada("http://www.terra.com.br"), new URLVisitada("http://www.lemonde.fr"), }; }

possvel implementar uma agregao com classes aninhadas, como ilustra o cdigo abaixo.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 class Historico { // como private, a URLVisitada s pode ser instanciada dentro do escopo do todo private class URLVisitada { private String url; URLVisitada (String umaURL) { url = umaURL; } ... } private Vector<URLVisitada> historico = new Vector<URLVisitada>(4, 2); ... }

Agregao por associao

A implementao idntica a da associao.

Realizao
uma relao que indica que uma classe realiza ou segue o contrato definido por uma classe de interface (no sentido Java). No diagrama de classes do conversor de Celsius-Fahrenheit, a classe Histrico realiza a interface Serializable (implements).

73

interface Serializable

instantiate

1 entity Historico + adicionar(ConversaoCF) : void writeObject() : void

Figura 80: Relao de realizao.

A implementao em Java de uma realizao mostrada em seguida.

1 2 3 1 2 3 public interface Serializable { ... } public class Histrico implements Serializable { ... }

5 SUBSISTEMAS
Aps estudar em detalhes a interao entre objetos e refinar o diagrama de classes, possvel identificar subsistemas. Uma forma de identificar subsistemas observar comportamentos repetidos nos diagramas de seqncia. Subsistemas podem conter outros elementos de modelagem (ex. classes, pacotes) e apresentam comportamento definido pelas interfaces que realiza. Em UML, subsistemas so representados como pacotes, porm com um esteretipo <<subsistema>>. Considere o exemplo onde durante a anlise foi identificada uma classe de anlise <<fronteira>> com um sistema de faturamento. No projeto, esta classe se mostrou muito complexa e foi transformada num subsistema onde vrias classes colaboram para realizar as responsabilidades previstas.

74

class subsistema interface Faturamento + emitirFatura(Pessoa, float) : void

cone para esteretipo <<Subsistema>>

Faturamento

Class3 Class4

Figura 81: Exemplo de subsistema.

6 COMPORTAMENTOS ASSOCIADOS PERSISTNCIA

No interessante que objetos da camada de modelo conheam detalhes do banco de dados (ex. conexo, tabelas, formato de registros). O problema que qualquer mudana no esquema do banco de dados se reflete nos objetos do modelo. Para desacoplar os objetos da camada do modelo do banco de dados possvel utilizar padres, tais como factory, que cria objetos do modelo j preenchidos com informaes do banco de dados e da, um intermedirio que faz a ligao entre o(s) objeto(s) do modelo e o banco de dados. Pode haver aumento da complexidade se o acesso ao banco de dados for simples. Por outro lado diminui-se a dependncia do modelo em relao ao banco de dados. Dao pode ser feito num nvel de granularidade maior, por exemplo, para manipular um conjunto de registros (viso) ou uma tabela.

7 EXERCCIOS
1. Supor que no projeto do conversor de graus Celsius para Fahrenheit, a persistncia do Histrico agora somente pelo tempo de uma sesso Web. A partir destas decises de projeto, uma nova realizao de projeto do caso de uso Converter Celsius-Fahrenheit deve ser realizada. Supor o cenrio onde o cliente faz o primeiro acesso ao sistema, logo uma sesso deve ser criada para armazenar as converses realizadas daquele momento em diante. O diagrama de seqncia parcial mostrado em seguida. Complete o diagrama de seqncia e refine o diagrama de classes.

75

sd proj eto casos de uso (w eb) jsp page :IUConversao :meteorologista pg. converso celsius POST celsius ConversaoCF(celsius) :Conv ersaoCF servlet :CtrlConversao

2.

Para o sistema de locao de veculos, caso de uso Reservar Veculo, supor que na fase de projeto o arquiteto de software decidiu por uma arquitetura Web como mostra o diagrama de implantao. Alm disso, o arquiteto de software optou por utilizar o conhecimento da equipe desenvolvedora em Java, Java ServerPages, servlets e Java Script.
deployment proj eto casos de uso

Serv idor WEB

http http http

http

Nav egador N

Nav egador 1

Nav egador 2

Nav egador N-1

Com estas decises, o diagrama de seqncia reservar veculo foi parcialmente refinado, ou seja, somente a parte de seleo de veculo por parte do cliente em um cenrio onde tudo funciona como mostra a figura seguinte. No est includo o tratamento do perfil do cliente.

76

sd Reserv ar Veculo (prj ) jsp page :IUReserva :Cliente pg. de reserva vec, IDFilial e datas POST veic, IDFilial e datas :Filial jsp page :MostraInventario servlet :CtrlReserva :DataAccess

popular(IDFilial) buscarFilial(IDFilial) preencher(regDB)

validar(datas) verifica se a filial estar aberta nos dias e horrios solicitados

ok entity :Inventario popular(IDFilial, datas, catVeic) buscarVeiculos(this) entity :Veiculo

preencher(regDB) adicionar(veiculo)

armazena coleo veics. na sesso

forward pg. inventario

mostrar inventrio mostra todos vecs. disponveis

A partir do diagrama de seqncia, refinou-se o diagrama de classes. A figura seguinte mostra apenas as modificaes em relao ao diagrama de classes de anlise. Note que operaes foram adicionadas e outras classes dependentes da arquitetura escolhida, tais como as pginas JSP.

77

class Classes proj eto (delta 1) DataAccess + + buscarFilial(int) : regDB buscarVeiculos(Inventario) : regDB entity Inv entario servlet CtrlReserv a instantiate + + 1 1 1 adicionar(Vei culo) : void popular(int, Date[2], int) : void

jsp page IUReserv a

jsp page MostraInv entario

instantiate + + + + + +

entity Filial endereco estadoFederecao IDFilial popular(int) : void preencher(regDB) : void validar(Date[2]) : boolean

* entity Veiculo + + + + acessorio categoriaVeic estado preencher(regDB) : void

Pede-se: Faa o diagrama de seqncia que mostre a efetivao da reserva por parte do usurio Faa as mudanas necessrias no diagrama de classes. (arquivo disponvel na pgina do curso formato Enterprise Architect)

78

VIII DIAGRAMA DE ESTADOS

1 ELEMENTOS BSICOS
Casos de uso e cenrios (diagramas de interao seqncia e comunicao) so utilizados para descrever o comportamento do sistema. Frequentemente necessrio descrever o comportamento interno de uma classe de objetos. No necessrio fazer diagramas de estado para todas as classes do sistema, somente para as mais complexas onde o comportamento dos objetos modificado pelos diferentes estados. Um diagrama de estados mostra os eventos que causam as transies de estados e as aes/atividades tomadas em conseqncia da transio. Condies de guarda podem ser associadas aos eventos, neste caso, a ocorrncia do evento no garante a ocorrncia da transio, preciso que a condio de guarda seja satisfeita para que ela ocorra.

Estado a situao na qual se encontra o objeto. Ao longo da sua vida, um objeto criado no estado inicial, passa por estados intermedirios e morre no estado final. Estados recebem nomes no particpio ou gerndio. Por exemplo, um objeto pode estar emprestado ou disponvel. Evento (trigger event): algo que ocorre de forma instantnea no tempo e pode ocasionar uma transio de estado em um objeto. Ao: uma ao algo executado de forma imediata e atmica, ou seja, o tempo de execuo muito pequeno e a ao no pode ser interrompida. Est frequentemente associada a uma transio embora possa aparecer dentro de um estado relacionada s palavras-chave entry e exit ou a transies internas a um estado. Atividade: similar a uma ao, porm pode ser interrompida. associada a um estado por meio da palavra-chave do. Condio de guarda: expresso lgica que deve ser verdadeira na ocorrncia do evento para que a transio ocorra.

1.1

Notao bsica

Diagrama de estados um grafo dirigido onde os nodos so os estados e os arcos, transies entre estados como ilustra a figura seguinte.

stm Abstrato

Transio externa
Estado transio estado inicial evento [guarda] /ao Final Estado 2

Figura 82: elementos bsicos de um diagrama de estados. A Figura 83 mostra o comportamento de uma janela que inicia no tamanho original e pode ser minimizada, podendo trocar de estados vrias vezes, at ser fechada.

79

class Estaes do ano JanelaOriginal boto fechar pressionado /destruir Final boto min. pressionado /minimizar boto rest. pressionado /restaurar

Initial

JanelaMinimizada

Figura 83: Diagrama de estados para uma janela (original, minimizada)

1.2

Ao nos estados (entry e exit)

Aes podem ser representadas nos eventos ou nos estados. Normalmente, a representao nos estados permite simplificar o diagrama. Observar na figura 84 que toda vez que o Livro passa ao estado Disponvel a ao de NotificarInteressados executada. Ao invs de repetir a ao em cada transio, pode-se coloc-la no interior do estado associada palavra-chave entry (figura 85). Cada vez que o estado Disponvel alcanado, executa-se a ao NotificarInteressados.
stm Liv ro aes nas transies comprado /NotificarInteressados Initial Emprestado devolvido /NotificarInteressados reparado /NotificarInteressados Colocado em reparo

Disponv el

Em reparo

Emprestado

retirado do acervo

Final

Figura 84. Aes nas transies que levam ao estado Disponvel.

80

stm Liv ro aes no estado Disponv el comprado + Initial emprestado devolvido entry / NotificarInteressados colocado em reparo reparado Em reparo

Emprestado

retirado do acervo

Final

Figura 85. Ao no estado Disponvel.

De forma similar, pode-se utilizar a declarao exit <ao> nos estados para representar que a <ao> ser executada toda vez que se deixar o estado.

1.3

Atividade nos estados (do)

Uma atividade pode ser interrompida ou terminar por si s. Um atividade est sempre associada a um estado por meio da palavra-chave do (faa). Por exemplo, na a atividade beep(tempo) ser executada toda vez que a impressora estiver sem papel. Esta atividade pode ser interropida a qualquer momento pela ocorrncia do evento impresso cancelada ou papel colocado.
stm Ativ idade no estado Impressora ociosa impresso cancelada fim impresso impresso iniciada Initial impresso cancelada papel colocado Imprimindo

Sem papel + do / beep(tempo) falta de papel

Figura 86. Atividade na transio Sem Papel.

1.4

Auto-transio

possvel que um evento provoque a transio de um estado para ele mesmo. Neste caso, todas as aes associadas ao estado por meio das palavras-chaves entry e exit e as aes associadas palavrachave do sero executadas. Na figura 87, toda vez que uma letra for teclada, dispara-se a transio do estado Contado letras para ele mesmo o que provoca a execuo da ao num++. Notar que possvel definir atributos das classes nos estados onde so manipulados (num: int).

81

stm Conta letras letra teclada

Contando letras /num:=-1 Initial + num: int entry / num++ enter Final

Figura 87: Auto-transio em mquina de estado.

1.5

Transio interna

possvel representar a ocorrncia de um evento que no provoca uma mudana de estado, somente a execuo de uma ao. Estes eventos so chamados de eventos internos e so representados no interior dos estados. A resposta a um evento interno difere daquela da auto-transio, pois no se deixa o estado para reentrar em seguida. Portanto, as aes associadas s palavras-chaves entry e, exit no so executadas e a atividade porventura em execuo no interrompida. No exemplo seguinda (Figura 88), h uma transio interna disparada pela tecla F1. Neste caso, a ao mostrar help ser executada, porm a ao num++ no ser executada.
stm Conta letras letra teclada

Contando letras /num:=-1 Initial + + num: int F1 / mostrar help entry / num++ enter Final

Figura 88: Exemplo de transio interna.

1.6

Ordem de execuo de aes e atividades

A ordem de execuo das aes e atividades a seguinte, supondo-se que a mquina j se encontra num estado A e passa ao estado B pela ocorrncia de um evento AB:
1. se existe uma atividade em execuo em A, ela interrompida; 2. executa-se a ao exit do estado A; 3. executa-se a ao associada ao evento AB; 4. executa-se a ao entry do estado B; 5. executa-se a atividade do em B, se existir.

No exemplo da figura 89, supe-se a seguinte seqncia de eventos: incio, ev AB, ev interno, ev B e ev FIM. Para esta seqncia, as aes so executadas na seguinte ordem: incio - A0 A1, A2, A3 ev AB AB, A5, A6 ev interno - A7 (sem matar A6) ev B (interrompe A6) A8, A4, A5, A6 ev FIM A8, A9.

82

stm Ordem exec Estado A /A0 Initial + + + entry / A1 do / A2 exit / A3 ev AB /AB

Estado B + + + + entry / A5 do / A6 ev interno / A7 exit / A8 ev FIM /A9 Final

ev B /A4

Figura 89: Ordem de execuo das aes e atividades.

1.7

Condio de guarda

Condio de guarda uma expresso lgica que deve ser satisfeita na ocorrncia de um evento para que a transio correspondente ocorra. Por exemplo, na Figura 90, quando ocorrer o evento userInput h trs opes mutuamente exclusivas dadas pelas condies de guarda: 1. opo = OK: a auto-transio sem ao associada ser executada;
2. opo = NOK: a auto-transio com a ao mostrarMsg ser executada; 3. opo = fim: o objeto ser destrudo.

Figura 90: Condio de guarda.

A condio de guarda importante para evitar conflitos entre transies. Se pela ocorrncia de um evento, mais de uma transio pode ser disparada, ento a mquina de estados no determinstica.

2 TIPOS DE EVENTOS
2.1
De chamada

um evento sncrono, tipicamente uma chamada de mtodo. Pode-se chamar um mtodo da prpria classe ou de outra classe. Por exemplo, a partir do diagrama de seqncia (figura 69, pg. 67) da realizao do caso de uso Converter Celsius-Fahreneheit pode-se identificar que a classe CtrlConverso possui um estado inicial (onde instancia a interface e histrico) e passa automaticamente ao estado Aguarda entrada onde executa a ao associada entry. Esta ao produz um evento de chamada na classe IUConversao que faz com que a mquina correspondente passe do estado Aguarda cmdo controle

83

para Aguarda entrada do usurio. Observar que do ponto de vista do CtrlConversao solicitarCelsius uma ao e de IUConversao, um evento de chamada. Embora no esteja representado (e no preciso representar todos os detalhes) fica subentendido que quando o usurio fornece um valor de entrada ao objeto da classe IUConversao, gera-se o evento valor fornecido no CtrlConversao (equivale resposta ao evento de chamada solicitarCelsius).
stm CtrlConv ersao ME /instancia Historico e IUConversao + Inicial v:=valor fornecido

Aguarda entrada entry / ^IUConversao.solicitarCelsius

[falso] /ConversaoCF(v), ^IUConversao.mostrar(f)

fim

stm IUConv ersao ME mostrar(f) /mostrar(f)

[verdadeiro] /writeObject()

Final

Aguarda cmdo controle Initial solicitarCelsius

destroy final valor fornecido [numrico ou "fim"]

Aguarda entrada usurio

valor fornecido [~fim & ~numrico]

Figura 91: diagrama de estados para a classe CtrlConversao e IUConversao.

Quando um objeto envia um evento de chamada a outro objeto ele passa o controle da execuo ao receptor. Uma vez que o objeto receptor processa o evento, disparando uma transio (se houver), o controle retorna ao invocador. Porm, contrariamente a chamada de um mtodo, uma mquina de estados que recebe um evento de chamada pode continuar sua execuo em paralelo (aps retorno do controle) com o objeto invocador.

2.2

De sinal

So eventos assncronos que, portanto, no bloqueiam o emissor, tal como um sinal enviado pela rede de comunicao de um processo a outro ou vindo da prpria interface do usurio. Para ilustrar este tipo de sinal, considerar um servidor de pginas WEB. O funcionamento tpico o seguinte: o servidor aguarda mensagens que podem chegar a qualquer momento. Quando chega uma mensagem, o servidor a trata e envia uma resposta de forma assncrona (sem se preocupar se a mensagem chegou ou no).

84

2.3

Temporal

Tipicamente so utilizados eventos nomeados por After(30seg) ou when(data= 1/ 2/2004) para indicar, respectivamente, um intervalo de tempo relativo ou um momento preciso no tempo. Por exemplo, um semforo passa pelos estados vermelho, verde e amarelo, sendo 45s no vermelho, 45s no verde e 5s no amarelo.

Figura 92: Exemplo de evento temporal em mquina de estados.

2.4

De mudana

uma condio avaliada continuamente disparando um evento toda vez que se torna verdadeira. representada frequentemente por meio do evento When. Difere de uma condio de guarda que avaliada somente uma vez quando o evento ao qual est associada ocorre. A figura 93 ilustra a diferena entre um evento de mudana e uma condio de guarda: Parte superior da figura: encher o tanque e parar quando volume = 25 litros Parte inferior da figura: uma vez o tanque cheio, se o volume for maior ou igual a 25 ganha ducha, caso contrrio, no ganha.

Figura 93: diferena entre condio de guarda e evento de mudana.

85

Exerccio. Refaa o exemplo do semforo para acomodar a seguinte situao: da meia-noite s 5h00 o sinal fica no estado alerta (piscando amarelo).

3 ESTADO COMPOSTO
Um estado composto pode ser decomposto em um conjunto de regies, cada uma delas com vrios subestados. H diversas razes e, por conseqncia, formas ligeiramente diferentes de se representar estados compostos.

Para representar decomposio de um estado, pode-se fazer um estado composto com uma nica regio com subestados diretos onde somente um deles est ativo por vez. Para representar concorrncia entre estados, isto , o fato de dois estados estarem ativos ao mesmo tempo, preciso representar dividir o estado composto em duas ou mais regies cada qual ter um estado ativo. Para representar uma submquina, ou seja, um estado que referencia outra mquina de estados que conceitualmente substitui o estado em questo.

Para exemplificar a situao, imaginar um aparelho de fax capaz de enviar e transmitir simultaneamente. A representao, idntica utilizada no caso de multithreading, ilustrada na figura 94. O estado composto Processando dividido em duas regies concorrentes, a superior, responsvel pela recepo de fax, e a inferior, pelo envio. Em um dado momento, o aparelho de fax pode estar com os subestados transmitindo e recebendo ativos.

86

Figura 94: Estado composto Processando com duas regies concorrentes.

Na figura 94, possvel observar um pequeno smbolo na parte inferior do subestado Recebendo que indica ser um estado composto. Sua decomposio est detalhada na figura 95.

Figura 95: Detalhamento do estado Recebendo.

3.1

Histrico

O pseudo-estado histrico denotado por H utilizado para memorizar o ltimo estado ativo quando se deixou um estado composto. A flecha do H aponta para o estado default, ou seja, o subestado que ativado na primeira vez em que o estado composto alcanado. Por exemplo, a Figura 96 mostra um lava-car que inicia no estado composto, subestado lavagem. Caso ocorra o evento parada de urgncia durante o estado enxaguar, retorna-se ao estado enxaguar aps a ocorrncia do evento retomada graas ao smbolo histrico.

87

Figura 96: Memorizao do ltimo estado visitado (histrico).

4 EXERCCIOS
1. 2. Fazer um diagrama de estados para as estaes do ano. Fazer o diagrama de estados no editor UML e codificar a classe em JAVA. Anlise o cdigo abaixo (CD Player) e construa a mquina de estados equivalente ao comportamento apresentado. Utilize condies de guarda e aes nas transies.

1 import java.io.*; 2 class CDPlayer { 3 static private int estado=0; 4 5 // AES 6 static private void desligar() { 7 System.out.println("*cortar fonte de energia*"); 8 } 9 static private void ligar() { 10 System.out.println("*alimentao acionada*"); 11 } 12 static private void pararCDabrirCompartimento() { 13 pararCD(); 14 abrirCompartimento(); 15 } 16 static private void fecharCompartimentoTocarCD() { 17 fecharCompartimento(); 18 tocarCD(); 19 } 20 static private void fecharCompartimento() { 21 System.out.println("*acionar motor fechamento*"); 22 } 23 static private void abrirCompartimento() { 24 System.out.println("*acionar motor abertura*"); 25 } 26 static private void tocarCD() { 27 System.out.println("*acionar leitor otico e giro CD*"); 28 } 29 static private void pararCD() { 30 System.out.println("*parar leitor otico e giro CD*"); 31 } 32 33 34 static private void mudarEstado(String evento) { 35 switch(estado) {

88

36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112

case 0: // estado desligado if (evento.compareToIgnoreCase("l")==0) { estado=1; ligar(); System.out.println("[CD LIGADO]"); } break; case 1: // estado ligado if (evento.compareToIgnoreCase("l")==0) { estado=0; desligar(); System.out.println("[CD DESLIGADO]"); } else if (evento.compareToIgnoreCase("p")==0) { estado=2; tocarCD(); System.out.println("[TOCANDO]"); } else if (evento.compareToIgnoreCase("o")==0) { estado=3; abrirCompartimento(); System.out.println("[ABERTO]"); } break; case 2: // tocando if (evento.compareToIgnoreCase("l")==0) { estado=0; pararCD(); desligar(); System.out.println("[CD DESLIGADO]"); } else if (evento.compareToIgnoreCase("o")==0) { estado=3; pararCDabrirCompartimento(); System.out.println("[ABERTO]"); } if (evento.compareToIgnoreCase("s")==0) { estado=1; pararCD(); System.out.println("[CD LIGADO]"); } break; case 3: // aberto if (evento.compareToIgnoreCase("l")==0) { estado=0; fecharCompartimento(); System.out.println("[CD DESLIGADO]"); } else if (evento.compareToIgnoreCase("p")==0) { estado=2; fecharCompartimentoTocarCD(); System.out.println("[TOCANDO]"); } else if (evento.compareToIgnoreCase("c")==0) { estado=1; fecharCompartimento(); System.out.println("[LIGADO]"); } break; } } static public void main(String args[]) { BufferedReader rdr = new BufferedReader(new InputStreamReader(System.in)); String evento=""; System.out.println("[CD DESLIGADO]"); do { System.out.println("(L)iga/desliga (P)lay (S)top (O)pen (C)lose (F)im"); try {

89

113 114 115 116 117 118 119 120 }

evento = rdr.readLine(); mudarEstado(evento); } catch (IOException e) { System.out.println("!!! Erro leitura !!!"); } } while (evento.compareToIgnoreCase("f")!=0); }

3. 4.

Refazer o exerccio acima mostrando como colocar aes nos estados (entry e exit). Refazer o diagrama de estados abaixo utilizando um estado composto.

Inserir carto /Ler carto Cancelar/ ejetar carto

Validao do carto

Ociosa
Fazer manut. Fim manut.

Cancelar/ ejetar carto

Seleo operao

Manuteno

Cancelar/ ejetar carto Cancelar/ ejetar carto Fim impresso/ ejetar carto

Processamento

Impresso

5.

Faa um diagrama de estados para uma classe que implemente um jogo de xadrez. Voc pode usar, por exemplo, os eventos seguintes: branca move, preta move, branca desiste, preta desiste, xeque mate. Represente nos estados o jogador da vez (brancas ou pretas). Faa o diagrama de estados para um despertador. O despertador pode estar em um dos estados seguintes: desarmado, esperando e despertando. O despertador inicia no estado desarmado. Para passar ao estado esperando, ele deve ser armado para disparar num determinado horrio. No estado despertando ele soa por 30 segundos. Se o usurio deslig-lo ele volta ao estado desarmado. Caso o usurio no desligue, o despertador volta a soar em 2 minutos at 3 vezes. Se ao cabo destas 3 vezes o usurio no desligou-o ento o despertador volta ao estado desarmado. Desenhe o diagrama de estados correspondente ao algoritmo do fatorial de n:

6.

7.

0! = 1 1! = 1 n! se n > 1 = n*(n-1)!
8. Represente em 3 diagramas de estado, uma televiso que pode estar ligada ou desligada, um DVD player, que tambm pode estar ligado ou desligado e um controle remoto que tem dois modos de funcionamento ora liga/desliga a televiso e ora liga/desliga o DVD player. Os botes dos trs aparelhos so do tipo liga/desliga (o mesmo boto realiza as duas funes). Suponha um editor de textos capaz de manipular trs tipos diferentes de objetos: textos, imagens e desenhos. Este programa manipula somente um tipo de objeto por vez de acordo com a seleo corrente do usurio. Quando o usurio seleciona um texto, o editor mostra um menu pop-up com as opes de edio textuais, o mesmo ocorre quando da seleo de uma imagem ou de um

9.

90

desenho. Faa o diagrama de estados representado este comportamento e o pseudocdigo que implementa o diagrama de estados

91

IX DIAGRAMA DE ATIVIDADES
O diagrama de atividades utilizado para representar a dinmica do negcio, dos casos de uso ou para detalhar uma operao de uma classe. Em relao aos casos de uso, pode tanto representar o fluxo bsico como um cenrio particular de execuo. importante ressaltar que diagramas de atividade no devem tomar o lugar dos diagramas de estado nem dos diagramas de interao, pois ele no detalha como os objetos se comportam nem como interagem. Normalmente utilizado na fase de inicializao para descrever os fluxos dos casos de uso, amadurecendo na fase de elaborao. Posteriormente pode ser utilizado para representar o fluxograma para uma operao.

1 ELEMENTOS BSICOS

Ao: realizada de forma instantnea. Atividade: demora certo tempo para ser realizada. Transio: Deciso Paralelismo ou bifurcao (fork) Sincronizao ou unio (join) Raias

Figura 97: Elementos bsicos do diagrama de atividades.

A figura 98, ilustra um caso de uso de oferta de disciplinas em uma universidade. Professores escolhem as disciplinas e horrios (que formam as turmas), os alunos recebem uma notificao e tambm uma cpia do catlogo impressa. As seguintes atividades esto representadas:

Criar turmas (entrar com as informaes das turmas para o semestre) Escolher turmas (professor escolhe turmas) Associar professor s turmas Criar catlogo de disciplinas (na verdade das turmas)

As transies entre as atividades representam o fluxo de controle do caso de uso. H atividades seqenciais, pontos de deciso, barras de paralelismo e de sincronizao, raias que identificam os responsveis pelas atividades e atividades inicial e final.

92

Incio de paralelismo

Barra de sincronizao

Figura 98: Exemplo de diagrama de atividades.

2 EXERCCIOS
Representar por meio de um diagrama de atividades a regra de negcio de um sistema de controle de notas escolares que determina se um aluno foi aprovado ou reprovado em funo de:

O aluno de v ter freqncia igual ou maior a 75%, caso contrrio estar reprovado por faltas. Em relao mdia das notas parciais n1 e n2: se superior ou igual a 7,0, aprovado por mdia se superior ou igual 5, 0 e inferior a 7,0, em final se inferior a 5,0, reprovado por nota. Se aluno em final, realiza uma terceira prova: Se mdia + final / 2 for maior ou igual a 5,0, aprovado, caso contrrio reprovado por nota.

93

DIAGRAMA DE COMPONENTES E IMPLANTAO 1 DIAGRAMA DE COMPONENTES

Quando um classificador (classe, pacote, subsistema, componente) realiza uma interface, significa que ele implementa uma ou mais operaes especificadas pela mesma. Uma interface define, portanto, uma coleo de servios que devem ser implementados em algum ponto do sistema. Um componente uma parte fsica do sistema, como um arquivo executvel, que realiza uma interface e , portanto, substituvel por outro componente que realize a mesma interface. A figura 99 ilustra um componente.java que realiza a interface ImageObserver e um outro, image.java, que depende da interface (e no da implementao da mesma).

Figura 99: Exemplo de componentes e de suas relaes3. A UML define trs tipos de componentes (Bezerra, 2004):

De execuo: existem em tempo de execuo, por exemplo, processos, threads, etc. De instalao: por exemplo, arquivos executveis, controles Active-X, DLLs, etc. De trabalho: so aqueles a partir dos quais os componentes de instalao so criados, tais como documentos, fontes, bibliotecas estticas, etc.

H vrios esteretipos para componentes:

Executvel Biblioteca: bibliotecas de classes ou funes; Tabela: repositrio de dados; Documento: arquivos texto (help), manual do usurio; Arquivo: cdigo fonte ou outro arquivo qualquer.

Extrado de http://paginas.fe.up.pt/~jpf/teach/POO/componentes.pdf

94

2 DIAGRAMA DE IMPLANTAO
O diagrama de implantao (deployement) representa a arquitetura fsica do sistema e, opcionalmente, os componentes que existem em tempo de execuo. Os elementos bsicos so:

Ns: representa um recurso computacional (processadores, dispositivos, sensores, roteadores); Conexes: ligam os ns, normalmente so meios fsicos de comunicao (fibra tica, cabo coaxial) ou protocolos de comunicao (TCP/IP, HTTP, UDP).

A figura 100 mostra um exemplo de diagrama de implantao.

deployment Proj eto

execution environ... cliente: Nav egador HTTP

execution environ... App Serv er ODBC

execution environ... BD Coorp.

LAN device Impressora

Figura 100: Exemplo de diagrama de implantao.

O diagrama de implantao pode ser associado ao de componentes para representar a distribuio dos componentes. Pode ser importante para analisar o sistema quanto distribuio de carga de trabalho. O diagrama de componentes da figura 101 pode ser associado ao diagrama de implantao da figura 100 resultando naquele ilustrado pela figura 101.
cmp Proj eto

IAlunos

executable Alunos

BD

executable SGBD

executable Lanamento de Notas IProf

executable Professores Persistncia iPersist executable Turmas

ITurmas

Figura 101 Exemplo de diagrama de componentes.

95

deployment Proj eto

execution environm... cliente: Nav egador

execution environment App Serv er

execution environment BD Coorp.

executable :Lanamento de Notas

HTTP

executable :Alunos ODBC

executable :SGBD

LAN device Impressora

executable :Professores

:Persistncia

executable :Turmas

Figura 102 Exemplo de diagrama de componentes.

96

XI REFERNCIAS BIBLIOGRFICAS
BOOCH G; RUMBAUGH J; JACOBSON I. UML: guia do usurio. Rio de Janeiro: Campus, c2000. 472p. ISBN 85-352-0562-4 BEZERRA E. Princpios de Anlise e Projeto de Sistemas com UML, Rio de Janeiro, Elsevier, 2002, 286p, ISBN 85-352-1032-6. FOWLER M; SCOTT K. UML essencial: um breve guia para a linguagem-padro de modelagem de objetos. 2.ed. Porto Alegre: Bookman, 2000 169 p. ISBN 8573077298 FOWLER M. Padres de Arquitetura de Aplicaes Corporativas, Bookman (ed.), 494p. GUEDES G. T. A.; UML Uma Abordagem Prtica, Inovatec, 319p., 2004. OMG, Unified Modeling Language 2.1.1, 732p., Fevereiro/2007. Disponvel em http://www.omg.org/cgi-bin/apps/doc?formal/07-02-05.pdf, acesso em 16/04/2007. PRESSMAN R. S. Engenharia de software. So Paulo: Makron, 1995. 1056 p. ISBN 85-346-0237-9 RUMBAUGH J., JACOBSON I., BOOCH G. The Unified Modeling Language Reference Manual, 2ed., Pearson Education, 2005, ISBN 0-321-24562-8. QUATRANI T. Visual Modelling with Rational Rose 2000, Addison-Wesley, 2a edio, 1999, 288p.

97