4 Anlise Orientada a Objetos

Prof. Leandro Buss Becker Email: lbecker@das.ufsc.br

Processo de Desenvolvimento Orientado a Objetos

Requisitos Anlise Projeto
Levantamento de Requisitos Modelo de Casos de Uso

Implementao Testes

Copyright Leandro Becker

Copyright Leandro Becker

Tpicos da Apresentao

Introduo Anlise OO

Introduo Anlise OO Identificao de classes Cartes CRC Detalhamento dos Casos de Uso

O objetivo da fase de anlise modelar o problema a ser solucionado Em suma, serve para:
Refinar e estruturar os requisitos Alcanar um melhor entendimento dos requisitos Criar uma descrio fcil de ser mantida

Copyright Leandro Becker

Copyright Leandro Becker

Introduo Anlise OO

Mapeamento Semntico
"Tanto mais um domnio de aplicao apresente relaes com componentes do mundo real, mais fcil e natural tornatorna-se a modelagem deste domnio com o uso de tcnicas de orientao a objetos"

Esta etapa serve para identificar pendncias no levantamento de requisitos

Pode ser falho visto que no so usados mtodos formais

Gera uma nova estrutura (classes e pacotes), que ortogonal aos Casos de Uso

Copyright Leandro Becker

Copyright Leandro Becker

Diferenas entre Anlise e Especificao de Requisitos

1. 2. 3.

Anlise do Sistema

4. 5. 6.

Descrito com a linguagem do cliente Viso externa do sistema Usado como contrato entre cliente e desenvolv sobre o que fazer Pode conter redundnc., redundnc., inconsist., inconsist., entre reqs. reqs. Captura as funcionalidades do sistema Define CdU que sero detalhados na anlise

1. 2. 3.

4. 5.

6.

Descrito com a ling. do desenvolvedor Viso interna do sistema Estruturado por classes e pacotes; pacotes; viso interna estruturada No pode conter redund e inconsistncias Sugere como realizar as funcionalidades; funcionalidades; esboo do projeto Define realizaes de CdU
Copyright Leandro Becker

Gera um modelo conceitual de objetos Refina requisitos e permite pensar na estrutura interna do sistema

Foca na mantenabilidade do sistema, sistema, i.e. facilidades de mudana nos requisitos e tambm no reuso

Aumenta expressividade e formalismo Serve de entrada para o projeto e implementao

Copyright Leandro Becker

Anlise vs. Projeto

Elementos da Anlise

Projeto tem escopo muito maior que a anlise (5:1), pois trata da implementao do sistema como um todo

Segundo a viso do RUP, o processo de anlise gera os seguintes elementos: elementos:

Classes do Modelo de Anlise Realizao dos Casos de Uso Anlise Pacotes de Anlise

D vida aos requisitos requisitos

Propsito da anlise
Especificar requisitos com mais preciso Usar linguagem do projetista (mais formal) Estrutura os requisitos para permitir futuras modific. modific. Esboo do modelo de projeto

Copyright Leandro Becker

Copyright Leandro Becker

Classes no Modelo de Anlise

Tipos de Classes da Anlise

Objetiva se concentrar nos requisitos funcionais Seu comportamento definido atravs de responsabilidades num nvel mais alto, menos formal Contm atributos, atributos, embora estes tambm se encontrem num nvel mais alto de detalhamento Contm relacionamentos, relacionamentos, que so mais conceituais do que fisicos fisicos propriamente
Copyright Leandro Becker

Boundary classes

Prov interface entre ator e sistema Representa os elementos persistentes Contm a lgica de controle (coordenao, coordenao, seqenciamento, seqenciamento, transaes, transaes, controle de outros objs) objs) em Casos de Uso especficos
Copyright Leandro Becker

Entity classes

Control classes

Identificao das Classes

1. 2.

Identificao das Classes (cont.)

Sugestes: No criar classes muito genricas ou muito especficas Nomes de classes:

Procurar por substantivos na especificao funcional Procurar por outras categorias:

Elementos do domnio do problema Agentes (terminados em or ) or) Eventos e transaes Usurios e papis Interfaces do sistema e dispositivos Classes funcionais

Substantivos no singular: Mensagem, Aluno, Produto Algumas vezes associados a um adjetivo ou particpio: AlunoEspecial, BufferDeEntrada, IconeAnimado. Evite a palavra objeto: MailBoxObject Evite nomes genricos: Agente, Tarefa, Item. Evite nomes que so verbos: Imprimir, Calcular.

Copyright Leandro Becker

Copyright Leandro Becker

Identificao das Responsabilidades

1. 2.

Identificao dos Atributos

1. 2.

Procurar por verbos na especificao funcional Cada responsabilidade deve pertencer a uma classe somente Interessante se efetuado por um grupo ao invs de uma nica pessoa As responsabilidades de uma classe devem pertencer a um mesmo nvel de abstrao

3. 4.

5. 6.

O nome do atributo deve ser um substantivo No devem ser restritos a determinados ambientes de implementao Procurar reusar atributos definidos previamente Um mesmo atributo no pode ser compartilhado entre mais de um objeto Atributos devem ser simples Muitos atributos so classes (de entidade)

Copyright Leandro Becker

Copyright Leandro Becker

Relacionamentos entre classes

Relacionamento de Dependncia

Relacionamentos mais comuns:

Dependncia (usa) Agregao (possui) Herana ()

Uma classe depende de outra classe se ela manipular objetos da ltima Relacionamento oposto (no(no-depende) tambm facilita a identificao da existncia ou no de dependncia

Copyright Leandro Becker

Copyright Leandro Becker

Relacionamento de Agregao

Relacionamento de Herana

Tipo especial de dependncia Usado quando uma classe contm outra

Usado quando uma classe um caso especial de outra A classe que herda incorpora os dados e o comportamento da classe base

Copyright Leandro Becker

Copyright Leandro Becker

Cartes CRC (ClassClass-ResponsibilityResponsibility-collaborator)

Cartes CRC

Tcnica de projeto que auxilia na descoberta de classes, responsabilidades e relacionamentos Consiste num ndice que descreve uma nica classe, suas responsabilidades e tambm seus colaboradores (classes dependentes)

So um processo interativo AconselhaAconselha-se pelo menos dois papeis

Um propem as classes Advogado do diabo: testa contra os casos de uso

So uma boa ferramenta de projeto no so uma ferramenta de documentao Para documentao: UML

Copyright Leandro Becker

Copyright Leandro Becker

Cartes CRC

Exemplo de Carto CRC

Usuario Gerenciar senha Gerenciar saudao Gerenciar transaes ContaCorrente

Responsabilidades: Responsabilidades:
Devem estar em alto nvel No correspondem a mtodos No mximo duas a trs por carto

Colaboradores: Colaboradores:
No precisam se localizar ao lado da responsabilidade correspondente Devem ser listados na medida da necessidade

Copyright Leandro Becker Copyright Leandro Becker

Dicas

Realizao dos Casos de Uso

Caso uma classe contenha muitas responsabilidades, considere dividdivid-la: la:

As classes devem ser coesas

Evite adicionar responsabilidades desnecessrias Classe sem responsabilidades intil

Descreve como um caso de uso especfico concebido e implementado em termos das classes de anlise e seus objetos Geralmente contm um diagrama de colaborao

Copyright Leandro Becker

Copyright Leandro Becker

Elementos dos Casos de Uso

ContraContra-Exemplo
1a. Joys tickInterface::run() 1.1a. Joys tickInterface::readInputData() 1.2a. Joys tickInterface::inputDataToMovem entAxis () 1.3a. Joys tickInterface::verifyMovem ent() 1.4a. Joys tickInterface::calculates Angle() 1.5a. Joys tickInterface::calculates Speed()

Diagrama de classes da anlise Diagrama de interaes (geralmente diagrama de colaborao) colaborao) Descrio textual do fluxo de eventos
: Joys tick

: Joys tickDriver 1b Movem entDr iver::run( ) 1.1b Moveme ntDriver::c alculates Axis( ) 1.2b. Movem entDriver::writeAxis ()

1.6a . Movem entContr oller ::notify( )

1.7a. Movem entDriver::notify() : Movemen tControll er : Movem entDriver

Copyright Leandro Becker

Copyright Leandro Becker

Unified Modelling Language (UML)

Unified Modelling Language (UML)

OMT (Rumbaugh)
1996

UML surgiu como notao padro para modelagem de sistemas OO

UML 1.4
Mar. 1999

No faz referncia as etapas de desenvolvimento do projeto

Booch

Booch, Jacobson e Rumbaugh definiram o chamado Unified Development Process (UDP), a fim de descrever as etapas de desenvolvimento (posteriormente derivou no RUP - Rational Unified Process)
Copyright Leandro Becker

UML 0.9

UML 1.1
Nov. 1997

OOSE (Jacobson) Catalysis ROOM etc.

Copyright Leandro Becker

Principais Diagramas UML

Detalhamento dos Casos de Uso

Use Cases Diagrama de Colaborao Diagrama de Seqncia Diagrama de Classes Outros diagramas: diagramas:

Refinar em subsub-funcionalidades (novos use cases) sempre que possvel Cada caso de uso deve representar um cenrio de execuo do sistema
Conjunto de objetos interagindo para produzir uma determinada funcionalidade Diagramas de Interao

Statecharts Diagramas de Atividades Diagramas Deployment

Copyright Leandro Becker

Copyright Leandro Becker

Exemplo Refinamento
Agenda tarefas Acom panhaAlvo
(from Prel im inarSuperi or) (from Preli m i narSuperior)

Exemplo Refinamento

Controla bateria
(f ro m Pr el im i narSupe ri or )

Encoder <<include>> Supervis iona m ovim ento Joys tick

(from Actors)

Detec ta col is ao da c adeira

(from Preli m inarSuperior)

Us uario ( from Ac tor s) Move cadeira

(from Preli m inarSuperior)

(f rom Ac to rs)

<<include>> Move cadeira

Freedom Movem entActuator

Verifica param etros vitais do cadeirante
(from P rel imi narSuperi or)

Movim enta autom aticam ente

(f rom Pr el im i nar Sup eri or)

(f rom Actors)

ControleNavegacao (from Actors )

Atua s ob re o m ovim ento

Tes ta cadeira
(from Prel im inarSuperi or)

Supervis iona cadeira

(f ro m Prel im i nar Supe ri or )

Copyright Leandro Becker

Copyright Leandro Becker

Diagramas de Interao

Exemplo de Diagrama de Colaborao

1a. Joys tickInterface::run() 1.1a. Joys tickInterface::readInputData() 1.2a. Joys tickInterface::inputDataToMovem entAxis () 1.3a. Joys tickInterface::verifyMovem ent() 1.4a. Joys tickInterface::calculates Angle() 1.5a. Joys tickInterface::calculates Speed()

Representam uma instncia de um use case So descritos por: por:

Diagrama de colaborao: colaborao: ressalta a associao entre os objetos e as mensagens trocadas Diagrama de seqncia: descreve a seqncia de mensagens trocadas entre os objetos ao longo do tempo
: Joys tick

: Joys tickDriver 1b Movem entDr iver::run( ) 1.1b Moveme ntDriver::c alculates Axis( ) 1.2b. Movem entDriver::writeAxis ()

1.6a . Movem entContr oller ::notify( )

1.7a. Movem entDriver::notify() : Movemen tControll er : Movem entDriver

Copyright Leandro Becker

Copyright Leandro Becker

Exemplo de Diagrama de Seqncia

<<active>> : Joy stickDriv er : MovementController <<active>> : MovementDriver

Diagrama de Classes

readInputData( ) inpuntDataToMovementAxis( ) verify Mov ement( ) calculatesAngle( ) calculatesSpeed( ) notify() return notify(Integer, Integer) return calculatesAxis(Integer, Intege

Contm os elementos do domnio do problema Representa o modelo esttico e seus relacionamentos

writesAxis(Integer, Integer)

Copyright Leandro Becker

Copyright Leandro Becker

Exemplo Diagrama de Classes

::BaseDados comunica 1 ::Persistente void inserir (in String nome, in int numero, in float saldo) void buscar (in int numeroConta) void delete (in int numeroConta) 1 1 1 1 ::BaseDadosLocal void instance () 1 PackageContas PackageView ::ContaCorrente String nomeCliente int numero float saldo void modificarSaldo () void validaSaldo () void consisteDados () ::JanelaBasica 1 leitura 1 void create () void delete () ::Factory 1 void instance (in int numeroConta) void delete (in int numeroConta) void update ()

Relacionamentos entre classes

Relacionamentos mais comuns:

Dependncia (usa) Agregao (possui) Herana ()

::Comunicacao void instance () void montaPacote () void processaPacote () 1 1 1 ::BaseDadosRemota void enviaPacote ()

::JanelaMovimento void void void void lerNumeroConta () atualizar () lerValor () lerDados ()

::JanelaCadastro void leDados ()

::ContaEspecial int limite

::Poupanca Data dataAniversario float saldoMinimo float taxa

Copyright Leandro Becker

Copyright Leandro Becker

Bibliografia

Booch, Jacobson and Rumbaugh, The unified software development process. Boston: Addison-Wesley, c1999. 463p. ISBN 020157 (Cap 8)

Copyright Leandro Becker