Prof. Msc. Emerson Silas Dória1 Análise e Projeto Orientados a Objeto com UML e Padrões Parte III...

Prof. Msc. Emerson Silas Dória 1

Análise e Projeto Orientados a Objetocom UML e Padrões

Parte III Análise (1)


Construindo um Modelo Conceitual

Ciclo deDesenv. 1

Sinc.Artefatos

Análise Projeto TesteRefin.Plano

Impl.

Ciclo deDesenv. 2 ...

ConstruçãoPlan. &Elaboração

Implantação


Construindo um Modelo Conceitual

Sinc.Artefatos


Impl.

2. Refinar Diag. Casos de Uso

3. Refinar ModeloConceitual

4. Refinar Glossário b

6. Definir Contrat.de Operação

1. Definir Casos de Uso Essenciais a

5. Definir Diag.Seq.

7. Definir Diag.Estado c

a. se ainda não feitob. contínuoc. opcional

Notas


Modelo Conceitual Artefato mais importante da AOO

Representa conceitos relevantes (do ponto de vista do projetista) do domínio do problema

Na UML, ilustrado com diagramas de estruturas estáticas contendo: Conceitos Associações entre conceitos Atributos de conceitos


Modelo Conceitual Parcial para o Sistema POST

POST

Item

Depósito

endereçonome

Venda

datahora

Pagamento

quantia

Item de Venda

quantidade

Armazenado-em

Aloja

Contido-em

1..*

Registra-venda-de

0..1

Pago-por

1

1

1

1

1

1

1

1

Capturado-no

Conceito

Associação

Atributos

*

1..*


Conceitos

BancodeDados Artefato de software;não faz parte do modeloevita

r

Classe de software ; não faz parte do modelo conceitual

Sale

datahora

imprime()

evitar

Idéias, coisas, ou objetos do mundo real

Não representam componentes de software!


Identificando Conceitos Regras úteis:

É melhor especificar demais do que especificar de menos

Não exclua conceitos simplesmente porque os requisitos não indicam a necessidade de guardar informações sobre eles (comum em projeto de BD)

Comece fazendo uma lista de conceitos candidatos a partir de uma lista de conceitos comuns

Considere os substantivos e frases nominais nas descrições textuais do domínio do problema como possíveis candidatos a conceitos ou atributos


Conceitos TípicosCategoria Exemplos

Objetos físicos ou tangíveis POSTAvião

Especificação de projetos ou descrição de coisas

Especificação de produtoDescrição de vôo

Lugares LojaAeroporto

Transações Venda, PagamentoReserva

Itens de transação Itens de venda

Papéis de pessoas OperadorPiloto

Contêiner de outras coisas Depósito, Armário, Aeronave


Conceitos TípicosCategoria Exemplos

Coisas em um container ItemPassageiro

Sistemas externos Sistema de Autorização de Crédito

Conceitos e substantivos abstratos

FomeAerofobia

Organizações Departamento de vendasCompanhia aérea

Eventos Venda, Roubo, ReuniãoVôo, Decolagem

Regras e políticas Política de reembolsoPolítica de cancelamento


Identificando Conceitos e Atributos em Descrições TextuaisSeqüência Típica de Eventos

Ação do Ator Resposta do Sistema

2. O Operador registra o identificador de cada item.Se houver mais de um exemplar do mesmo item, o Operador também pode informar a quantidade.

3. Determina o preço do item e adiciona informação sobre o item à transação de venda corrente.Mostra a descrição e o preço do item corrente.

1. Este caso de uso começa quando um Cliente chega no caixa (equipado com um POST) com itens que deseja comprar.

Usar com cuidado! Linguagens naturais: imprecisão e ambigüidade


Conceitos Candidatos para o Sistema POST

Conceitos restritos ao caso de uso Comprar Itens - Versão expandida

LojaPost VendaItem

Pagamento

Item de Venda

Operador Cliente Gerente

Catálogo Produtos

Especificação de

Produtos


Criando um Modelo Conceitual Passos sugeridos:

Liste os conceitos candidatos, usando a Lista de Categorias de Conceitos e a identificação de substantivos relacionados com os requisitos que estão sendo considerados;

Desenhe-os em um modelo conceitual; Acrescente as associações necessárias para

registrar os relacionamentos para os quais existe a necessidade de preservar alguma memorização *

Acrescente os atributos necessários para completar os requisitos de informação *

* serão apresentados posteriormente


Estratégia do “fazedor de mapas”: Usar nomes existentes no vocabulário do

domínio Incluir apenas conceitos pertinentes para os

requisitos (casos de uso) em questão Excluir tudo que não há no domínio do problema

Erro comum: atributo em vez de conceito Atributos normalmente correspondem a um

texto ou número no mundo real

Criando um Modelo Conceitual


A especificação ou descrição de um objeto deve ser representada como um conceito em separado evita perda de informação quando o objeto

é excluído reduz informações redundantes ou

duplicadas Muito comum no domínio de produtos e

vendas

Conceitos de Especificação ou de Descrição

Item

descriçãopreçonúmero serialUPC

EspecificaçãoProdutoItem

Número serial

Descreve1 *

descriçãopreçoUPC

pior melhor


outro exemplo:

Conceitos de Especificação ou de Descrição

pior

melhor

Vôo

DataNúmerohora

Aeroporto

nome

Voa-para

1*

Vôo

datahora

Descrição-Vôo

número

Aeroporto

nome

Descreve-vôo-para

Descrito-por

1*

1

*


Terminologia da UML UML usa o termo genérico “classe”

para denotar tanto entidades do domínio da aplicação quanto classes na POO Uma classe na POO é chamada mais

especificamente de “classe de implementação”


Associações Uma associação é um relacionamento

entre conceitos que indica uma conexão com significado e interesse

Descritos na UML como “relacionamentos estruturais entre objetos de tipos diferentes”

Indicam conhecimento de um relacionamento que precisa ser preservado durante algum tempo Duração de milisegundos ou anos, dependendo

do contexto Entre quais objetos necessitamos ter

alguma memória de um relacionamento?


Associações Notação na UML

Uma linha entre dois conceitos mais um nome

Inerentemente bidirecional Pode conter um seta de direção de

leitura Pontas podem conter expressões de

cardinalidadeEspecificaçãoProduto

Item

Númeroserial

descreve

1 *DescriçãoPreçoUPC


Associações Típicas(*) alta prioridadeCategoria Exemplos

A é uma parte física de B (*) Gaveta - POSTAsa – Avião

A é uma parte lógica de B (*) Item de Venda - VendaEscala – Vôo

A está fisicamente contido em/sobre B (*)

POST - LojaPassageiro – Avião

A está logicamente contido em B (*)

Descrição-Item - CatálogoVôo - Roteiro de Viagem

A é uma descrição de B Descrição-Item - ItemDescrição-Vôo – Vôo

A é um item de uma transação ou relatório B

Item de Venda - VendaOpção de Reserva – Reserva

A é conhecido/registrado/repor-tado/capturado em B (*)

Venda - POSTReserva - Terminal de Reserva


Associações TípicasCategoria Exemplos

A é um membro de B Operador - LojaPiloto - Companhia Aérea

A é uma sub-unidade organizacional de B

Departamento - LojaManutenção - Companhia Aérea

A usa ou gerencia B Operador - POSTPiloto – Avião

A se comunica com BCliente - OperadorAgente de Reserva – Passageiro

A está relacionado com uma transação B

Cliente - PagamentoPassageiro – Bilhete

A é uma transação relacionada com outra transação B

Pagamento - VendaReserva – Cancelamento

A é possuído por B POST - LojaAvião - Companhia Aérea

(*) alta prioridade


Identificando Associações Regras úteis:

Focaliza-se naquelas associações para as quais o conhecimento do relacionamento necessita ser preservado por algum tempo;

É mais importante identificar conceitos do que identificar associações;

O excesso de associações tende a tornar um modelo conceitual confuso, em vez de esclarecê-lo.


Cada ponta de um associação é chamada de um “papel”

Um papel pode ter: Nome Expressão de multiplicidade Navegabilidade

Papéis de uma Associação

ItemLoja Estoca

*1


Adicionando Associações ao Modelo Conceitual do POST Relacionamentos fundamentais

Venda Capturada-em POST Para conhecer a venda corrente, calcular total e

imprimir recibo Venda Paga-por Cliente

Para saber se a venda foi paga, calcular troco, e imprimir recibo

Catálogo-Produto Contém Especificação-Item

Para obter a especificação de um item, dado um UPC


Aplicando a lista de Associações Típicas

Categoria Sistema POST

A é uma parte física de B (*) Não aplicável

A é uma parte lógica de B (*) Item de Venda – Venda

A está fisicamente contido em/sobre B (*)

POST – LojaItem – Loja

A está logicamente contido em B (*)EspecificaçãoProduto – CatálogoProdutos CatálogoProdutos – Loja

A é uma descrição de B EspecificaçãoProduto – Item

A é um item de uma transação ou relatório B ItemVenda – Venda

A é conhecido/registrado/repor-tado/capturado em B (*)

Venda (corrente) – POSTVendas (completada) – Loja


Aplicando a lista de Associações Típicas

Categoria Sistema POST

A é um membro de B Operador - Loja

A é uma sub-unidade organizacional de B Não aplicável

A usa ou gerencia B Operador – POSTGerente – POST

A se comunica com B Cliente – Operador

A está relacionado com uma transação B

Cliente – PagamentoOperador – Pagamento

A é uma transação relacionada com outra transação B Pagamento – Venda

A é possuído por B POST – Loja


Conceitos e Associações candidatos para o POST

POST

ItemLoja

Venda

Pagamento

Item Venda

OperadorCliente

Gerente

Catálogode Produtos

Especificaçãode Produto

estoca

*

possui

1..*

usado-por

*

contém1..*

descreve

*

capturada-por

contido-em

1..*

descrito-por

*

registra-venda-de

0..1

iniciado-por

paga-por iniciada-por

log-vendas realizadas

*

registra-venda-no

1

1

1

1

1

1

11

1

1

1

1

1

1

1

1 1

1

iniciada-por

1

1


Eliminando associações redundantes ou desnecessárias Associações cujo conhecimento não precisa

ser preservado podem ser removidas do modelo:Associação Consideração

Venda iniciada-por OperadorConhecimento não exigido nos requisitos; derivável da associação Operador registra-vendas-em POST.

Operador registra-vendas-em POST Conhecimento não exigido nos requisitos.

POST inicializado-por Gerente Conhecimento não exigido nos requisitos.

Venda iniciada-por Cliente Conhecimento não exigido nos requisitos.

Loja armazena Item Conhecimento não exigido nos requisitos.

ItemVenda registra-venda-de Item Conhecimento não exigido nos requisitos.


Preservando Associações de Compreensão Preservar apenas associações de

conhecimento pode resultar num modelo que não transmite um completo entendimento do domínio: Exemplo: venda iniciada-por cliente

Remoção deixa de fora um aspecto importante do domínio - o fato de que um cliente gera uma venda

Modelo conceitual é um artefato de comunicação ou informação;

Regra geral é enfatizar associações de conhecimento, mas preservar associações que enriquecem o entendimento do domínio


Atributos Um atributo é um dado lógico de um objeto

do domínio Definidos para conceitos cujos requisitos

(casos de uso) sugerem a necessidade de preservar algum tipo de informação Ex.: atributos data e hora para o conceito

Venda Notação na UML

Venda

Atributos datahora:data


Identificando Atributos Atributos devem preferencialmente

representar tipos primitivos de dados ou de valores simples

Ex.: Data, Número, Texto, Hora, Endereço, etc. Atributos não devem ser usados para:

Representar um conceito complexo Relacionar conceitos (atributo “chave-estrangeira”)Operador

nomePOSTcorrente

pior

Operador

nome

POST

número

usamelhor

1 1


Podem ser representados diretamente no modelo conceitual

Um atributo deve ser de tipo não-primitivo quando: É composto de seções separadas

Ex.: endereço, data Precisa ser analisado ou validado

Ex.: CPF, número de matrícula Possui outros atributos

Ex.: Um preço promocional com prazo de validade É uma quantidade com uma unidade

Ex.: valores monetários, medidas

Atributos Não-Primitivos

Especificação de Produto

upc : UPC

Loja

endereço:Endereço


Adicionando Atributos aos Conceitos Candidatos do Sistema POST

Conceito Atributos e justificativa

Pagamentoquantia - Para determinar se pagamento é suficiente e calcular troco.

EspecificaçãoProduto

descrição - Para mostrar na tela e imprimir no recibo.UCP - Para localizar especificação do item.preço - Para calcular o total da venda.

Venda data, hora - Para imprimir no recibo e registrar no log de vendas.

ItemVendaquantidade - Para registrar a quantidade digitada quando há mais de um do mesmo item.

Loja nome, endereço - Para imprimir no recibo.


Atributo Derivado Um atributo derivado é um atributo cujo

valor pode ser deduzido a partir de outras informações Ex.: quantidade em Item Venda - pode ser

deduzido a partir da multiplicidade da associação entre Item Venda e Item

Na UML, indicado com o símbolo “/”


Modelo Conceitual Inicial do POST

POST

ItemStore

addressname

Sale

date

time

Payment

amount

SalesLineItem

/quantity

CashierCustomer

Manager

ProductCatalog

ProductSpecification

descriptionpriceUPC

Stocks

*

Houses

1..*

Used-by

*

Contains

1..*

Describes

*

Captured-on

Contained-in

1..*

Described-by

*

Records-sale-of

0..1

Started-by

Paid-by Initiated-by

Logs-completed

*

Records-sales-on

1

1

1

1

1

1..*

11

1

1

1

1

1

1

1

1 1

1

Um item da venda pode estar associado a vários

itens, portanto, quantidade pode ser

obtida através da multiplicidade do relacionamento

ItemVenda e Item


Definindo Diagramas de Seqüência (Comportamento do Sistema)

Sinc.Artefatos


Impl.









Notas


Comportamento do Sistema Um diagrama de seqüência do sistema é uma

figura que mostra, para o particular cenário de uso, os eventos que os atores externos geram, sua ordem e os eventos entre sistemas;

Todos os sistemas são tratados com uma caixa-preta; a ênfase do diagrama está nos eventos que atravessam a fronteira do sistema entre atores e outros sistemas;

Um diagrama de seqüência do sistema deve ser feito para a seqüência típica de eventos do caso de uso.


Diagrama de Seqüência do Sistema (Comportamento do Sistema)

EntrarItem(UPC,quantidade)

:SistemaOperador

TerminarVenda()

Repetir até nãoter mais itens

RegistrarPagamento(quantia)Texto que esclarece o controle, a lógica, a iteração, etc.Pode se obtido do caso de uso.

AtorComprar Itens – versão 1

O sistema como umacaixa-preta

Evento de sistema dispara uma operação de sistema.


Eventos e Operações Um evento de sistema é um evento

externo de entrada gerado por um ator para um sistema Inicia uma operação de resposta do sistema

Uma operação de sistema é uma operação executada em resposta a um evento de sistema

O nome do evento e da operação são idênticos; evento é o estimulo nomeado, e a operação é a resposta


Eventos e Operações


:SistemaOperador

Comprar Itens – versão 1

evento de sistema “EntrarItem”ele dispara uma operação de sistema, da mesma maneira, chamada “EntrarItem”


O conjunto necessário de operações de sistema é determinado através da identificação dos eventos de sistema Exemplos de operações para o sistema

POST: EntrarItem(UPC, quantidade) TerminarVenda() RegistrarPagamento(quantia)

Na UML, representado como operações de um tipo denominado Sistema

Representando Operações

Sistema

EntrarItem(UPC, quantidade)

TerminarVenda()

RegistrarPagamento(quantia)



Regras úteis1. Desenhar uma linha vertical representando o

sistema como uma caixa-preta.2. Identificar os atores que operam diretamente

com o sistema. Desenhar uma linha vertical representando cada um desses atores.

3. A partir da descrição das seqüências típicas de eventos dos casos de uso, identificar e ilustrar os eventos de sistema que cada ator gera.

4. Opcionalmente, incluir o texto do caso de uso à esquerda do diagrama.




:SistemaOperador

TerminarVenda()


Comprar Itens – versão 1

2. O Operador registra o identificador de cada item.Se houver mais de um exemplar do mesmo item, o Operador também pode informar a quantidade.

4. Após processar o último item, o Operador indica ao POST que a entrada de itens terminou.

6. O Operador informa o total ao Cliente.

1. Este caso de uso começa quando um Cliente chega no caixa (equipado com um POST) com itens que deseja comprar.

Identifique os eventos do sistemaque cada ator gera.

Registre as operações de sistema requeridas.


Nomeando Eventos e Operações Regras úteis:

Começar com um verbo Enfatizar “intenção” em vez do meio físico

de entrada ou componente gráfico da interface com o usuário

Ex.: TerminarVenda em vez de PressionarTeclaEnter

Expressar intenção no nível mais alto de abstração

Ex.: RegistrarPagamento em vez de EntrarQuantia


Definindo Contratos de Operação

Sinc.Artefatos


Impl.









Notas


Contratos Um contrato é um documento que

descreve o que uma operação se compromete a atingir: Estilo declarativo Pré e pós-condições de mudanças de

estado Para métodos, classes, ou operações

gerais de sistema


Contratos Exemplo para operação EntrarItem

Contrato: EntrarItem (UCP:número, quantidade:inteiro)

Responsabilidade: Registra venda de um item e o adiciona à venda corrente. Mostra descrição e preço do item

Tipo: Sistema

Referência Cruzada: Funções: R1.1, R1.3, R1.9Caso de Uso: Comprar Itens

Notas: Usar acesso rápido ao BD

Exceções: Se UPC inválido, indicar erro

Saída:

Pré-condições: UPC é conhecido do sistema


Contratos Exemplo para operação EntrarItem

Pós-condições: Se for uma nova venda, uma Venda foi criada (criação de instância); Se for uma nova venda, a nova Venda foi associada ao POST (formada uma associação); Um ItemVenda foi criado (criação de instância); O ItemVenda foi associado à Venda (formada uma associação); ItemVenda.quantidade recebeu o valor de quantidade (modificação de atributo); O ItemVenda foi associado a uma EspecificaçãoDeProduto, baseada numa correspondência com o UPCs (formada uma associação).


Seções de um Contrato

Contrato: Nome e parâmetros da operação

Responsabilidade: Descrição informal das responsabilidades da operação

Tipo: Nome do tipo (conceito, classe, interface)

Referência Cruzada: Número de referência de funções, casos de uso, etc.

Notas: Notas de projeto, algoritmos, etc.

Exceções: Casos excepcionais

Saída: Saídas não-IU, tais como mensagens ou registros enviados para fora do sistema

Pré-condições: Hipóteses e assertivas sobre o estado do sistema antes da execução da operação


Como Fazer um Contrato Regras úteis:

1. Identificar operações de sistema a partir dos diagramas de seqüência do sistema;

2. Para cada operação construa um contrato;3. Começar escrevendo a seção Responsabilidades,

descrevendo informalmente o propósito da operação;

4. Completar a seção Pós-condições, descrevendo de forma declarativa as mudanças de estado que ocorrem aos objetos do modelo conceitual;

5. Para descrever as Pós-condições considere as seguintes categorias:

Criação e remoção de instâncias Modificação de atributos Associações formadas e desfeitas (erro mais comum!)


Contratos e Outros Artefatos

Caso de Uso:Comprar Itens

Sequência Tipica de Eventos

1. Este caso de uso começa...

Operação: EntrarItemPós-Condições:1. Se tSe for uma nova venda, uma Venda foi criada (criação de instância);Sistema

EntrarItem(UPC, quantidade)

TerminarVenda()



:SistemaOperador

TerminarVenda()


Caso de Uso DSS Operações do Sistema Contratos

Operação: TerminarVendaPós-Condições:1. Venda.Completada recebe o valor...


Pós-condições Pós-condições devem ser expressas no

passado, enfatizando mudanças de estado já ocorridas

Analogia: Palco e Cortina Imagine os objetos do sistema no palco de um

teatro Antes da operação, fotografe o palco Feche a cortina e execute a operação Abra a cortina e fotografe o palco novamente Compare as duas fotos, e então expresse como

pós-condições as mudanças no estado do palco


Contratos para o POST Operação TerminarVendaContrato: TerminarVenda()

Responsabilidade: Registrar que é o fim da entrada de itens de venda e exibir o total da venda

Tipo: Sistema

Referência Cruzada: Funções: R1.2Caso de Uso: Comprar Itens

Notas:

Exceções: Se uma venda não está em andamento, indicar o erro

Saída:

Pré-condições: UPC é conhecido do sistema


Contratos para o POST Operação TerminarVendaPós-condições: Venda.Completada recebe o valor true (modificação

de atributos).


Contratos para o POST Operação RegistrarPagamento:Contrato: RegistrarPagamento(quantia:numero)Responsabilidade: Registrar o pagamento, calcular o troco e imprimir

recibo.Tipo: SistemaReferência Cruzada: Funções: R2.1

Caso de Uso: Comprar ItensNotas:

Exceções: Se a venda não está completa, indicar um erroSe a quantia for menor que o total da venda, indicar um erro

Saída:

Pré-condições:


Contratos para o POST Operação RegistrarPagamento:Pós-condições: Um Pagamento foi criado (criação de instância);

Pagamento.quantiaFornecida recebeu o valor da quantia (modificação de atributos); O Pagamento foi associado à Venda (relacionamento foi formado); A Venda foi associada à Loja, para acrescentá-la ao histórico de vendas completadas (relacionamento foi formado).


Contratos para o POST Operação InicializarContrato: Inicializar()

Responsabilidade: Inicializar o sistema

Tipo: Sistema... ...

Pós-condições: Uma Loja, CatálogodeProdutos, EspecificaçõesDeProdutos foram criadas (criação de instâncias); CatálogodeProdutos foi associado a EspecificaçõesDeProdutos (associação formada); Loja foi associada a CatálogodeProdutos (associação formada);


Contratos para o POST Operação Inicializar

Pós-condições: Loja foi associada POST (associação formada); POST associado a CatálogodeProdutos (associação formada).


Diagrama da UML Consulte na página

www2.unoeste.br/~emerson documentos específicos com os detalhes sintáticos da UML.

Prof. Msc. Emerson Silas Dória1 Análise e Projeto Orientados a Objeto com UML e Padrões Parte III...

Documents

Transcript of Prof. Msc. Emerson Silas Dória1 Análise e Projeto Orientados a Objeto com UML e Padrões Parte III...