Revisão Aula Conceitos Gerais (28 03)

Prévia do material em texto

Análise de sistemas orientado a objetos
Revisão
Conceitos básicos da orientação a objetos
2
Objetivos:
� Entender o significado de objetos e classes;
� Definir abstração
� Definir atributos e operações
� Conhecer mecanismos de herança e polimorfismo
� Exemplificar encapsulamento
Introdução
3
Antes de começarmos a desenvolver orientado a objetos, é preciso,
começar a pensar orientado a objetos
Mas o que é um objeto?
4
Portanto, objetos são coisas do mundo real, como pessoas, animais etc,
que descobrimos estudando suas características (atributos), como altura,
tamanho, cor e seu comportamento (ações), como falar, dormir, andar.
Além de objetos animados, essa observação inclui também objetos
inanimados, como por exemplo: uma bola de futebol, que possui
atributos, como diâmetro, cor, peso e ações como rolar, encher chutar etc.
O que é abstração?
5
Suponha um conjunto formado pelos seguintes objetos: calculadora,
caminhão, impressora, pessoas. Se por exemplo, o propósito fosse
desenvolver um sistema de transporte, os demais objetos estariam
descartados.
Classes
6
Uma Classe é a definição dos atributos e funções de um tipo de objetos;
ela descreve um conjunto de objetos individuais em qualquer contexto.
Ela é obtida pela classificação de objetos com a mesma estrutura de
dados e o mesmo comportamento.
Nome da classe
Atributos da classe
Funções da classe
Atributos
7
Os atributos, são recursos de uma classe ou qualquer outro elemento que
represente propriedades ou elementos de dados. Em algumas
linguagens, os atributos são denominados variável de instancia de
classe ou membro de dado.
Eles possuem algumas características importantes, como visibilidade
(escopo), nome, tipo de dado e valor inicial.
A visibilidade de um atributo pode ser:
Operações
8
Os objetos interagem e comunicam-se por meio de mensagens, que
identificam os métodos a serem executados, no objeto receptor.
Para invocar um método de um objeto, enviar-se uma mensagem para
ele especificando o nome do objeto, o método a ser executado e a lista
de argumentos requeridos. Após a execução, o objeto pode ou não
retornar um valor como resposta a mensagem recebida.
Herança
9
Juntamente com o Polimorfismo, a Herança é uma das características
mais poderosas e importantes da Orientação a objetos, em razão do fato
de esta permitir o reaproveitamento de atributos e de métodos,
otimizando o tempo de desenvolvimento, além de permitir a diminuição
de linhas de código, bem como facilitar futuras manutenções.
O conceito de herança trabalha com os conceitos de superclasses e
subclasses. Uma superclasse é uma classe que possui classes derivadas
dela, chamadas subclasses. As subclasses, ao serem derivadas de uma
superclasse, herdam seus atributos e métodos.
10
Polimorfismo
11
Polimorfismo: é o principio pelo qual classes derivadas de uma mesma
superclasse, podem invocar operações que tem a mesma assinatura,
mas comportamentos diferentes em cada subclasse, produzindo
diferentes resultados, dependendo de como cada objeto implementa a
operação.
Em outra palavras, é a capacidade de objetos diferentes possuírem
operações com o mesmo nome e a mesma lista de argumentos, mas que
executam tarefas diferentes
Encapsulamento
12
Os atributos estão encapsulamento, isto é, envolvidos por código de
forma que só é visível na operação em que foi criado. Isso também vale
para as operações, quando algumas delas são visíveis apenas pelo
próprio objeto.
Análise e Projeto Orientados a Objeto
com UML e Padrões
Parte I 
Análise, Projeto, e Processo
13
O que é Análise e Projeto?
Análise — “o quê”
Investigação do problema e 
dos requisitos
Requisitos
Casos de uso
Restrições
Vocabulário
Projeto — “como”
Descrição de uma solução lógica
Objetos
Arquitetura
Instalação & Operação
Interface do usuário
Fonte:
Livro - Utilizando Uml e Padroes Por Craig Larman
O que é APOO?
Na essência, considerar um problema e uma
solução dentro da perspectiva de objetos,
coisas ou conceitos.
O que é AOO?
» Investigação dos objetos de domínio e seus 
relacionamentos
� Descritos no Modelo de Objetos de Domínio
O que é POO?
» Elaboração de uma solução lógica em termos de 
componentes de software e suas colaborações e 
responsabilidades
� Descritos em Diagramas de Classes e Diagramas de 
Interação
Representação de um Conceito na APOO
Ex.: O conceito “Livro” em um sistema de biblioteca
Conceito
de domínio
public class Livro
{
public void imprimir();
private String titulo;
}
Representação
no código
Livro
título
Representação
na análise
Livro
título
Representação
no projeto
imprimir()
Fases
Planejamento e Elaboração
» Concepção inicial, investigação de alternativas, 
definição de requisitos, etc.
Construção
» Construção do sistema através de múltiplos ciclos de 
análise, projeto, implementação e teste
Implantação
» Instalação e operação do sistema
Fase de Planejamento e 
Elaboração
2. Criar Rel. Prel.
de Investigação 3. Definir Requisitos
9. Refinar Plano7. Definir Mod.Conc. Inicial c
4. Reg. Termos
no Glossário a
6. Definir Casos 
de Uso
1. Definir Plano
Inicial
5. Implementar
Protótipo b, d
a. contínua
b. opcional
c. adiável
d. ordem variada
8. Definir Arquit.
Inicial a, c, d
Notas
ConstruçãoPlan. &Elaboração Implantação
Fase de Planejamento e Elaboração
Atividades:
1. Definir plano inicial
� Prazos, recursos, orçamento
2. Criar relatório preliminar de investigação
� Motivação, alternativas, necessidades de negócio
3. Definir requisitos
� Especificação declarativa dos requisitos
4. Registrar termos no glossário
� Dicionário de termos, regras, restrições
5. Implementar protótipo
� Protótipo do sistema para ajudar na definição dos requisitos
Fase de Planejamento e Elaboração
Atividades:
6. Definir casos de uso
� Descrição em prosa estruturada dos processos de negócio
7. Definir modelo conceitual inicial
� Objetos de domínio e seus relacionamentos
8. Definir arquitetura inicial
� Principais subsistemas e suas dependências
9. Refinar plano
Fase de Construção
Ciclo de
Desenv. 1
Sinc.
Artefatos Análise Projeto Teste
Refin.
Plano Impl.
Ciclo de
Desenv. 2 ...
ConstruçãoPlan. &Elaboração Implantação
Fase de Construção
Repetição de ciclos de desenvolvimento
» Construção progressiva do sistema até atingir uma 
versão que satisfaça corretamente os requisitos
Atividades típicas de cada ciclo:
1. Refinar plano
2. Sincronizar artefatos
3. Análise
4. Projeto
5. Implementação
6. Teste
Ciclos de Desenvolvimento
Cada ciclo implementa um conjunto reduzido de 
requisitos, adicionando novas funções ao 
sistema 
» Crescimento incremental, através de expansões e 
refinamentos sucessivos
Ciclos com tempo fixo de duas a oito semanas
Vantagens:
» Evita complexidade excessiva
» Antecipa feedback dos usuários
Ciclos de Desenvolvimento e 
Casos de Uso
Um ciclo deve atacar um ou mais casos de uso, ou 
versões simplificadas de casos de uso
Casos de uso mais relevantes devem ser atacados nos 
primeiros ciclos
» Prioridade para serviços com grande influência na arquitetura do 
sistema ou de alto risco 
Ciclo de 
Desenv. 1
Caso de uso A
Versão
Simplificada
Ciclo de 
Desenv. 2
Caso de uso A
Versão
Completa
Ciclo de 
Desenv. 3
Caso de
uso B
Caso de 
uso C
Fonte:
Livro - UML 2 Guia Pratico Gilleanes T. A. Guedes
Análise
a. se ainda não feito
b. contínuo
c. opcional
2. Refinar Diag. 
Casos de Uso
3. Refinar Modelo
Conceitual
4. Refinar 
Glossário b
6. Definir Contrat.
de Operação
1. DefinirCasos de
Uso Essenciais a
5. Definir Diag.
Seq.
7. Definir Diag.
Estado c
Notas
...
Ciclo de
Desenv. 1
Sinc.
Artefatos Análise Projeto Teste
Refin.
Plano Impl.
Ciclo de
Desenv. 2
Análise
Subatividades:
1. Definir casos de uso essenciais
2. Refinar diagramas de casos de uso
3. Refinar modelo conceitual
4. Refinar glossário
5. Definir diagramas de seqüência do sistema
6. Definir contratos de operação
7. Definir diagramas de estado
Projeto
2. Definir Rel. & IU
4. Definir Diag.
Interação
5. Definir Diag.
Classes a
6. Definir Esquema
do BD
1. Definir Casos de
Uso Reais
3. Refinar
Arquitetura b
Notas
a. em paralelo com
diag. interação
b. ordem variada
...
Ciclo de
Desenv. 1
Sinc.
Artefatos Análise Projeto Teste
Refin.
Plano Impl.
Ciclo de
Desenv. 2
Projeto
Subatividades:
1. Definir casos de uso reais
2. Definir relatórios e interfaces com o usuário
3. Refinar arquitetura do sistema
4. Definir diagramas de interação
5. Definir diagramas de classes de projeto
6. Definir esquema do banco de dados
Ênfase do Estudo de Caso: Camada de Lógica da 
Aplicação
Apresentação
Lógica da Aplicação
Armazenamento
SGBD
Object Store
Enter Item End Sale
UPC
Make Payment
Total
Quantity
Tendered Balance
Venda Pagamento
BD Segurança
Foco principal
Foco secundário
-objetos de domínio
-objetos de serviço
Foco menor
Estratégia do Curso
Aprendizagem e desenvolvimento iterativos
APOO aplicada ao sistema POST em dois ciclos de 
desenvolvimento:
» Ciclo 1 Funcionalidades básicas
� Introdução das habilidades de análise e projeto pertinentes para o 
primeiro ciclo
» Ciclo 2 Funcionalidades expandidas
� Introdução de habilidades adicionais de análise e projeto
Definição de Requisitos
2. Criar Rel. Prel.
de Investigação 3. Definir Requisitos
9. Refinar Plano7. Definir Mod.Conc. Inicial c
4. Reg. Termos
no Glossário a
6. Definir Casos 
de Uso
1. Definir Plano
Inicial
5. Implementar
Protótipo b, d
a. contínua
b. opcional
c. adiável
d. ordem variada
8. Definir Arquit.
Inicial a, c, d
Notas
ConstruçãoPlan. &Elaboração Implantação
Definição de Requisitos
Requisitos mal-entendidos ou incorretamente
especificados representam um grande risco
para o desenvolvimento de software.
Especificações bem-feitas requerem uma gama
de habilidades e técnicas, cujo estudo
detalhado está fora do escopo do curso.
Foco: introdução à especificação de requisitos,
usando o sistema POST como exemplo.
O que são Requisitos?
Descrições das necessidades ou desejos para um 
produto.
Usados para identificar e documentar o que é 
realmente necessário, de uma forma que fique 
claro para clientes e desenvolvedores.
Desafio:
» Evitar ambiguidades
» Identificar riscos 
» Coletar e “digerir” dados de fontes variadas de 
informação (documentos, entrevistas, reuniões, etc.)
Descrição de Requisitos
Alguns artefatos básicos:
» Visão geral
� Sumário descrevendo o propósito geral do projeto
» Clientes
� Quem encomendou ou está pagando pelo sistema
» Objetivos 
� Objetivos a serem alcançados com o sistema
» Funções
� O que o sistema deve fazer
» Atributos
� Aspectos não funcionais relevantes
Funções
Devem ser documentadas e listadas em grupos logicamente 
coesos
Categorias de funcões
» Evidente
� Deve ser executada, e o usuário deve estar ciente da execução (ex.: Registrar venda, 
Processar pagamento)
» Escondida
� Deve ser executada, mas de modo transparente para o usuário (ex.: Guardar 
informações no BD)
» Opcional
� Função não afeta os custos ou as outras funções do sistema de maneira significativa
Atributos
Características ou qualidades não funcionais do sistema
» Ex.: facilidade de uso, tolerância a falhas, tempo de resposta,
metáfora de interface, etc.
Podem estar relacionados com todas as funções, ou ser
específicos para uma função ou um grupo de funções
particular.
Podem ter detalhes (possíveis valores simbólicos para o
atributo) e restrições de contorno (intervalos obrigatórios
para os valores do atributo) .
Artefatos de Requisitos para o Sistema POST
Visão geral
� O propósito deste projeto é criar um sistema para um terminal de ponto de 
venda a ser usado em lojas de varejo.
Clientes
� ObjectStore, Inc., uma cadeia de lojas de venda de componentes de 
software reutilizáveis.
Objetivos
� Redução do tempo de espera dos clientes nos caixas.
� Análise rápida e acurada das vendas.
� Controle automático de estoque.
Artefatos de Requisitos para o Sistema POST
Funções básicas
R1.1 Registrar a venda corrente (itens de compra). evidente
R1.2 Calcular total da venda corrente, incluindo imposto 
e descontos.
evidente
R1.3 Capturar informação do código de barras dos 
itens de compra (UPC), via uma leitora de código 
de barras ou digitação manual.
evidente
R1.4 Reduzir quantidades do estoque quando a venda 
for confirmada.
escondida
R1.5 Registrar venda no log de vendas completadas. escondida
R1.6 Operador do caixa deve digitar um ID e senha 
para usar o sistema.
evidente
R1.7 Oferecer um mecanismo de armazenamento 
persistente.
escondida
Ref # Função Categoria
Artefatos de Requisitos para o Sistema POST
Atributos
tempo de resposta (restrição de contorno) Durante o registro de um item 
de compra, a descrição e o preço do produto 
aparecerão em até 5 segundos. 
Atributo Detalhes e Restrições de Contorno
metáfora de interface (detalhe) Janelas e caixas de diálogo baseadas na 
metáfora de formulários. 
(detalhe) Maximizar facilidade de navegação via 
teclado ao invés de via mouse. 
tolerância a falha (restrição de contorno) Deve registrar pagamentos 
com cartão de crédito autorizados junto ao sistema 
de contas a receber dentro de 24 horas, mesmo se 
houver falha de energia ou nos equipamentos. 
plataformas de S.O. (detalhe) Microsoft Windows 7/8
Casos de Uso
Descrições narrativas de processos do domínio da 
aplicação.
Documentam a sequência de eventos de um ator 
(um agente externo) usando o sistema para 
completar, do início ao fim, um determinado 
processo
Representação em UML: Comprar Items
Casos de Uso
Exemplo de um caso de uso de alto-nível:
A UML não especifica um formato rígido para os 
cabeçalhos e a estrutura de um caso de uso 
» Podem ser alterados de acordo com as 
necessidades de documentação 
Caso de uso:
Atores:
Tipo:
Descrição:
Comprar Itens (Buy Items)
Cliente (Customer), Operador (Cashier )
primário
Um Cliente chega no caixa com itens para comprar. O Operador registra
os itens e coleta o pagamento. Ao final, o Cliente sai com os itens.
Casos de Uso
Exemplo de um caso de uso expandido:
I. Caso de uso:
II. Atores:
III. Propósito:
IV. Descrição:
I. Comprar Itens com Dinheiro (Buy Items with Cash)
II. Cliente (Iniciador), Operador
III. Capturar uma venda e seu pagamento em dinheiro.
IV. Um Cliente chega no caixa com itens para comprar. O Operador
registra os itens e coleta um pagamento com dinheiro. Ao final, o
Cliente sai com os itens.
Tipo:
Referencia: primário e essencial 
Funções: R1.1, R1.2, R1.3, R1.7, R1.9, R2.1
Típica Sequência de Eventos
Ação do Ator
Resposta do Sistema
1. Este caso de uso começa quando um
Cliente chega no caixa com itens para
comprar.
Casos de Uso
Exemplo de um caso de uso expandido (cont.):
Típica Sequência de Eventos
Ação do Ator Resposta do Sistema
2. O Operador registra o
identificador de cada item.
Se há mais de um 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 em
andamento.
Mostra a descrição e o preçodo
item corrente.
4. Após processar o último item, o
Operador indica ao POST que a
entrada de itens terminou.
5. Calcula e mostra o valor total
da venda.
6. O Operador informa o total ao
Cliente.
.
Casos de Uso
Exemplo de um caso de uso expandido (cont.):
Típica Sequência de Eventos
Ação do Ator Resposta do Sistema
7. O Cliente entrega um pagamento em
dinheiro, possivelmente maior do que o
valor total.
8. O Operador registra o valor recebido em
dinheiro.
9. Mostra o troco devido.
Emite um recibo.
12. O Cliente sai com os itens comprados.
.
10. O Operador deposita o dinheiro e retira
o troco devido.
O Operador entrega o troco e o recibo ao
Cliente.
11. Registra a venda no log de
vendas completadas.
Atores
Entidades externas ao sistema que de algum 
modo participam da estória do caso de uso
» Estimulam o sistema com eventos de entrada, ou 
recebem alguma coisa dele
» Designados pelo papel que exercem no caso de uso
� Ex.: Cliente, Operador, etc.
Representação em UML:
Cliente
Atores e Casos de Uso
Um caso de uso possui um ator iniciador, que gera 
o estímulo inicial, e possivelmente vários atores 
participantes.
» O ator iniciador deve ser indicado explicitamente na 
descrição do caso de uso
Algumas categorias típicas de atores incluem:
» papeis exercidos por pessoas
» sistemas de computação
» dispositivos elétricos e mecânicos
Identificando Casos de Uso
Normalmente não são eventos ou passos individuais, 
mas um processo completo. 
» Erro mais comum!
Método baseado em atores
1. Identificar os atores relacionados com o sistema ou 
organização;
2. Para cada ator, identificar os processo que eles iniciam ou 
participam;
Identificando Casos de Uso
Método baseado em eventos
1. Identificar os eventos externos aos quais o sistema 
deve responder
2. Relacionar os eventos a atores e casos de uso
Exemplos do sistema POST
» Operador: Login, Retirar Dinheiro
» Cliente: Comprar Itens, Devolver Itens
» Digitar Senha?
» Imprimir Recibo?
Casos de Uso e Funções
Todas as funções do sistema identificadas na 
especificação dos requisitos devem ser alocadas a 
casos de usos.
» Alocação documentada através da seção Referencia;
Idealmente, funções e casos de uso devem ser 
rastejáveis até a implementação e teste do sistema .
Casos de Uso e o Limite do Sistema
Identificar os atores e casos de uso de um 
sistema requer a definição de seu limite de 
atuação 
Alguns limites típicos incluem:
» o software/hardware de um dispositivo ou sistema de 
computação
» um departamento de uma organização
» uma organização inteira 
Limites diferentes podem resultar em diferentes 
conjuntos de atores e casos de uso
Tipos de Caso de Uso
Primário
Representam os processos principais ou mais comuns 
(ex.: Comprar Itens)
Secundário
Representam processos menos importantes ou mais 
raros (ex.: Cadastrar Operadores)
Opcional
Representam processos que podem ser ignorados ou 
incluídos em futuras versões do sistema (ex.: Solicitar 
Estoque para um Novo Produto).
Casos de Uso no Processo de Desenvolvimento
Passos da fase de Planejamento e Elaboração
1. Após as funções do sistema terem sido descritas, defina o limite de 
atuação do sistema e identifique atores e casos de uso.
2. Escreva todos os casos de uso no formato alto-nível, categorizando-os 
como primário, secundário ou opcional.
3. Desenhe um diagrama de caso de uso.
4. Relacione casos de uso e ilustre seus relacionamentos no diagrama de 
caso de uso. 
5. Escreva os casos de uso mais importantes ou críticos no formato 
expandido essencial. 
6. Se estritamente necessário, escreva alguns casos de uso no formato 
real.
7. Ordene os casos de uso por prioridade de desenvolvimento.
Casos de Uso no Processo de Desenvolvimento
Passos da fase de Construção
1. Análise—Escreva casos de uso expandidos essenciais para 
aqueles sendo atacados no ciclo de desenvolvimento corrente, 
se ainda não feito.
2. Projeto—Escreva casos de uso reais para aqueles sendo 
atacados no ciclo de desenvolvimento corrente, se ainda não 
feito.
Passos do Processo para o Sistema POST
Desenhar diagrama de caso de uso
Caixa
POST
Compra Items
Cliente
Log In
Reembolso items 
comprados
Gerente
System
Administrator
Start Up
Manage Users
etc.
Priorizando Casos de Uso
Atacar primeiro aqueles com maior influência na 
estrutura básica do sistema.
Características que podem aumentar a prioridade 
de um caso de uso:
» Impacto significativo no projeto da arquitetura 
» Funções complexas, arriscadas, ou de tempo crítico
» Envolve novas pesquisas ou tecnologia emergente
» Representa processos primários de negócio
» Contribui diretamente para aumentar lucros ou 
diminuir custos 
Priorizando Casos de Uso
Ordenação baseada em classificação simples 
de prioridades (ex.: alta-média-baixa)
Priorizando os casos de uso do sistema POST
Caso de Uso
Média Manter Usuários
Log In
Devolver Itens
Alta Comprar Itens
Baixa Retirar Dinheiro
Inicializar
Encerrar
Prioridade Justificativa
Afeta sub-domínio de segurança
Afeta sub-domínio de segurança
Afeta contabilidade
Processo primário de negócio
Mínimo efeito na arquitetura
Depende de outros casos de uso
Mínimo efeito na arquitetura
Modelo Conceitual
Artefato mais importante da AOO
Representa conceitos relevantes (do ponto de 
vista do modelador) 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 para o Sistema POST
Diagrama parcial
POST
Item
Loja
endereço
nome
Venda
date
hora
Pagamento
Valor total
Vendas
Itens linha
quantidade
Abastecido em
*
Casas
1..*
Contido em
1..*
Registros de vendas
0..1
pagar
1
1
1
1
1
1
1
1
Enviado para 4
Conceitos
Associação
Atributos
Associações
Uma associação é um relacionamento entre 
conceitos que indica uma conexão significativa 
e interessante
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
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 cardinalidade
VendaPOST Registros-correntes 4 11
association name multiplicity
-“seta de direção leitura"
-Muitas vezes excluidos
Ele não tem qualquer relação, com exceção para
indicar a direção da leitura da etiqueta associada
Cada ponta de uma associação é chamada de um 
“papel”
Um papel pode ter:
» Nome
» Expressão de multiplicidade 
» Navegabilidade
Papeis de Uma Associação
ItemLoja Estoque
*
Multiplicidade de papeis
1
O valor da multiplicidade depende do contexto
» Ex.: Pessoa Trabalha-para Empresa
Expressões de Multiplicidade 
zero ou mais;
“muitos"
Um ou mais
Um para 40
Exatamente cinco
T
T
T
T
*
1..*
1..40
5
T3, 5, 8 Exatamente três,Cinco ou oito
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
data
Hora inicio : hora
atributos
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”)
Caixa
name
atualPOST
Caixa
name
POST
numero
Uses
ruim
bom
Não é um simples atributo...
1 1
Registrando Termos no Glossário
Um glossário ou dicionário de modelo é um documento que 
define os termos (ou vocabulário) do domínio
» Similar a um dicionário de dados usado na modelagem de BD
Fundamental para garantir uma comunicação consistente e 
um entendimento compartilhado entre usuários e 
desenvolvedores
Também pode ser usado para registrar restrições de 
domínio e regras de negócio (não explorado no curso) 
Glossário Parcial para o Sistema POST
Categoria
atributo Uma descrição sucinta de um item de 
venda.
caso de uso Descrição do processo de um cliente 
comprando itens numa loja.
tipo Um item à venda numa loja.
tipo Um pagamento em dinheiro.
Comentário
atributo O preço de um item de venda. 
Termo
Especificação-Produto.descrição 
:Texto
Comprar Itens
Item
Pagamento
Especificação-Produto.preço 
:Quantidade 
atributo A quantidade de um tipo particular de 
item comprado.
tipo Uma transação de venda.
tipo Um item particular comprado como 
parte de uma venda.
Item de Venda.quantidade :Inteiro
Venda
Item de Venda
a. se ainda não feito
b. contínuo
c. opcional
2. Refinar Diag. 
Casos de Uso
3. Refinar Modelo
Conceitual
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
Notas
Sinc.
Artefatos Análise Projeto Teste
Refin.
Plano Impl.
Um Ciclo de Desenvolvimento