UNIVERSIDADE TECNOLGICA FEDERAL DO PARAN

PR

ANLISE E PROJETO OO & UML 2.0

Cesar Augusto TaclaDepartamento 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.

SUMRIOI INTRODUO ...................................................................................... 5 1 MODELO ................................................................................................. 5 2 UML ...................................................................................................... 52.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 ............................................................................. 92.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 ........................................................................................173.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..............................................................................................224.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

2

3 PADRO OBSERVADOR...............................................................................37 4 CLASSES DE ANLISE.................................................................................374.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

V

ESTUDO DA INTERAO ENTRE OBJETOS ................................................... 43 1 DIAGRAMA DE SEQUNCIA ..........................................................................431.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...........................................................................................531.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 .......................................................663.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

3

1 ELEMENTOS BSICOS ................................................................................791.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

X

XI

4

I

INTRODUO

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

1 MODELOAntes 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 UMLUML 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;

5

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

1

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

6

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 CLASSEApresenta-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

7

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.

Classe atributos mtodosFigura 2. Notao UML para classe.

5 EXERCCIOS1. 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.

8

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 GERALNo 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 atividades6. 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 REQUISITOSConsiste 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.

9

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 dehttp://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 PROJETOAnlise 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(). 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 COMPORTAMENTALCom 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 USOO 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 ATORESRepresentam 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 sistemaExaminar 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 USOA 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 BsicoUm 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 EVENTOS1. 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 SubfluxoUm 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 . 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 extensoSo 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 AlternativoUm 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 atividadeUm 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 CenriosCenrios 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 UsoUm 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 RELAESH 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 AtorRelaes 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 CasoH 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 () 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 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 CasoGeneralizao 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 EVENTOS1. 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

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

conta do cliente so vlidas7. 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 AtorEspecializao 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 MODELAGEM5.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 () e fluxos alternativos () 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 EXERCCIOS1. 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 USOEste 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 ANLISEO 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 noEm 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 usoSegundo (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 (ao invs de estarem ligadas realizao do caso de uso de anlise), conforme ilustra a Figura 24.

Modelo de casos de uso Realizao do caso de uso (anlise)

Realizao do caso de uso (projeto)

Modelo de casos de uso

Realizao do caso de uso (projeto)

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

Mtodo de AnliseDe 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 MVCMVC (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 OBSERVADORO 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 ANLISEEm 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.

NomeClasse atributos mtodosFigura 27: notao para classe.

Figura 28: notao de classe sem atributos e mtodos.

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

37

[][]:[][=] : + 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 do atributo : por exemplo, valores[5] ou matriz[4, 6] : pode-se utilizar os tipos da linguagem de implementao. Por exemplo, char, float ou int. : valor inicial para o atributo que respeite o tipo de dado.

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

4.1.2 MtodosSintaxe para declarao de um mtodo em UML: []():[] : + 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 do mtodo : (:, ..., :). Por exemplo, (nome:String, idade: int) : 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: esteretiposDe 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: ou ou ou 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 .

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

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 .

2

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 EXEMPLOO 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 EXERCCIOS1. 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 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

V

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 SEQUNCIARelembra-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 recebimen