ES I Aula04

FCT-UNESP 16/05/2017
Engenharia de Software I
Bacharelado em
Rogério Eduardo Garcia Ciência da
Computação
16/05/2017
(rogerio@fct.unesp.br)
Aula 04
In a calm sea every man is a pilot.
Engenharia de Software I –
Aula 4 BCC
16/05/2017
 Revisão
 Introdução ao Método Larman
 Planejar e Elaborar
 Construir
 Analisar
 Revisão de conceitos de Orientação a Objetos
16/05/2017 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 2
Prof. Dr. Rogério E. Garcia 1

FCT-UNESP 16/05/2017
Padrão IEEE para o

Documento de Requisitos BCC
16/05/2017
 1 Introdução
 1.1 Propósito do documento de requisitos

 Motivações, público-alvo, ...
 1.2 Escopo do produto
 Explicitar o que o produto faz (e o que não faz).
 Descrever a aplicação.
 1.3 Definições, acrônimos e abreviações
 1.4 Referências
 Listar todos os documentos referenciados.
 Especificar a origem dos documentos.
 1.5 Visão geral do restante do documento
 Estrutura/organização.
Padrão IEEE para o

16/05/2017
 2 Descrição Geral
 2.1 Perspectiva do Produto

 Relacionamento: sistema, usuário, hardware, software,
comunicação.
 2.2 Funcionalidades do Produto
 2.3 Características do Usuário
 2.4 Restrições Gerais
 Limitações de hardware, considerações sobre segurança,
...
 2.5 Suposições e Dependências
 Máquina específica, sistema operacional, ...

FCT-UNESP 16/05/2017
Padrão IEEE para o

16/05/2017
 3 Requisitos Específicos
 Abrangem os requisitos funcionais, não funcionais e de interface.
 Os requisitos podem documentar interfaces externas, descrever

funcionalidade e desempenho do sistema, especificar requisitos
lógicos de banco de dados, restrições de projeto, propriedades
emergentes do sistema e características de qualidade.
 4 Apêndices
 5 Índice
Análise de Requisitos BCC

16/05/2017
Engenharia de
Como Proceder?
Sistemas de
Computador ANÁLISE DE
REQUISITOS
Projeto de
Software

FCT-UNESP 16/05/2017
Princípios da Análise BCC

16/05/2017
 O domínio de informação de um problema deve ser

representado e compreendido
 Modelos que descrevam a informação, função e
comportamento do sistema devem ser
desenvolvidos
 Os modelos devem ser divididos em partições, de
maneira que revele os detalhes em forma de
camadas, preferencialmente
 O processo de análise deve ter como foco a
informação essencial do (UdeI) – detalhes de
implementação ficam para a fase de Projeto
Princípios da Especificação BCC

16/05/2017
 Separar funcionalidade de implementação
 Uso de uma linguagem de especificação orientada

ao processo
 A especificação deve abranger o sistema do qual o

software é um componente
 A especificação deve abranger o sistema no qual o

software opera

FCT-UNESP 16/05/2017
Princípios da Especificação
(Cont.) BCC
16/05/2017
 Uma especificação deve ser um modelo cognitivo
 Uma especificação deve ser operacional
 Uma especificação deve ser tolerante com a não-

inteireza e ser expansível
 Uma especificação deve ser localizada e

fracamente acoplada
Formulação dos requisitos BCC

16/05/2017
Estabelecimento das Estudo de Modelagem

necessidades do sistema viabilidade do sistema
Definição
Relatório de Relatório de dos
necessidades viabilidade requisitos
Documento de Especif.
requisitos dos
requisitos
Especificação
Especific.
do projeto
do sistema

FCT-UNESP 16/05/2017
Para que tudo isso? BCC

16/05/2017
 Obter uma descrição dos requisitos
 Propor uma solução (“software”) que atenda

ao requisitos da melhor maneira possível
 Possibilidade de avaliar não apenas a

proposta, mas também as conseqüências de
decisões tomadas em tempo de projeto
Problema X Solução BCC

16/05/2017
Problema Solução
Abstrato
Concreto

FCT-UNESP 16/05/2017
Portanto... BCC
16/05/2017
 É preciso planejar considerando a maneira

com que um projeto será implementado...
Orientado a Objetos
Mundo x Paradigma OO BCC

16/05/2017
 Mundo Real é formado por objetos que se

interagem
 Representar esses objetos em um software é mais

natural e permanente do que representar a sua
funcionalidade (decomposição funcional), pois essa
é mutável
 A representação usando objetos facilita o

mapeamento do mundo real, ou seja, a criação de
um modelo que o represente

FCT-UNESP 16/05/2017
Problema... BCC
16/05/2017
Mundo Real Mundo Computacional
ESPAÇO DE ESPAÇO DE
PROBLEMAS SOLUÇÕES
Gap Semântico
Todo software representa um Modelo de um problema

do mundo real, no Espaço de Soluções
Gap Semântico BCC

16/05/2017
 Quanto menor o Gap (diferença entre espaços)

mais fácil será :
 o desenvolvimento da aplicação
 assegurar a compreensão, confiabilidade e manutenção
da aplicação
 Diminuir o Gap implica em tornar o mapeamento do

mundo real (modelo) mais próximo da realidade
 Sendo mais “natural”, o Paradigma de Orientação a

Objetos tem por objetivo diminuir o gap semântico

FCT-UNESP 16/05/2017
Criação de Modelos BCC

16/05/2017
Processo de Identificação de
Mapeamento
“coisas” do mundo real para
compor o modelo
ABSTRAÇÃO Modelo Conceitual

16/05/2017
Problema Solução
Abstrato
Concreto

FCT-UNESP 16/05/2017
BCC
16/05/2017
Método Larman: Visão Geral BCC

16/05/2017
A/POO
Padrões Notação UML
Tópicos e
Habilidades
Princípios e Engenharia de
Diretrizes Requisitos
Desenvolvimento
Iterativo

FCT-UNESP 16/05/2017
BCC
16/05/2017
UML BCC
16/05/2017
 História da UML
 início em 1994 – esforço conjunto de Booch e
Rumbaugh para combinar as notações
diagramáticas de seus métodos Booch e OMT
(Object Modeling Technique)
 a eles juntaram-se outros colaboradores
 adotada como padrão em 1997 pela OMG
 continua a ser refinada…
 versão 2.0 em andamento (???)

FCT-UNESP 16/05/2017
UML BCC
16/05/2017
 Segundo OMG: “A UML (Unified Modeling

Language - Linguagem de Modelagem Unificada) é
uma linguagem para especificar, visualizar, construir
e documentar os artefatos de sistemas de software,
bem como para modelar negócios e outros sistemas
que não sejam de software”
 Notação UML - principalmente diagramática, para

modelagem de sistemas usando conceitos
baseados na metáfora de “objetos”
UML BCC
16/05/2017
 A UML é a linguagem padrão para visualizar,

especificar, construir e documentar os
artefatos de um sistema intensamente
baseado em software
 Pode ser usada com todos os processos,

durante todo o ciclo de desenvolvimento, e
com diferentes tecnologias de
implementação;

FCT-UNESP 16/05/2017
Diagramas BCC
16/05/2017
 Use Case
 Diagramas de Estrutura Estática
 Diagrama de Objetos
 Diagramas de Classe
 Diagramas de Interação
 Diagrama de Seqüência
 Diagrama de Colaboração
 Statecharts
 Diagramas de Atividade
 Diagrama de Implementação
 Diagrama de Componentes
 Diagrama de Desdobramentos (Deployment)

16/05/2017
Problema Solução
Diagrama de Diagrama de
Classes Classes
Abstrato
Concreto

FCT-UNESP 16/05/2017

16/05/2017
 Processo Planejar e Elaborar

 Casos de Uso: Formatos, Tipos e Diagrama
 Modelo Conceitual: Conceitos e Associações
 Processo Construir (Fase Analisar)

 Modelo Conceitual: Agregações, Generalizações e
Tipos Associativos
 Diagramas de Seqüência
 Contratos de Operação

16/05/2017
 Auxiliar o desenvolvedor a:
 Aplicar princípios, diretrizes e padrões na
construção de software
 Seguir um conjunto de atividades comuns de

análise e projeto, a partir de um ciclo de
desenvolvimento iterativo
 Criar diagramas freqüentemente utilizados na

notação UML

FCT-UNESP 16/05/2017
Desenvolvimento Iterativo BCC

16/05/2017
 Um ciclo de vida iterativo (CVI) envolve a repetição

dos ciclos de planejamento, elaboração, construção
e instalação
 O sistema cresce pela adição de novas funções (e
refinamento das existentes) em cada ciclo iterativo
 Cada ciclo ataca um pequeno conjunto de requisitos
instalar planejar
construir elaborar
Método Larman BCC

16/05/2017
Planejar e
Construir Instalar
Elaborar
Ciclo de
Desenvolvimento 1
Ciclo de
Desenvolvimento 2
…
Refinar Sincronizar Analisar Projetar Construir Testar

Plano Artefatos

FCT-UNESP 16/05/2017
Método Larman BCC

16/05/2017
Planejar e
Construir Instalar
Elaborar
Ciclo de
Desenvolvimento 1
Ciclo de
Desenvolvimento 2
…

Plano Artefatos
Método Larman: Planejar e

Elaborar BCC
16/05/2017
Planejar e Elaborar Construir Implantar
1. Definir 2. Criar Relatório de

3. Definir Requisitos
Plano Inicial Investigação Preliminar
4. Registrar 5. Implementar 6. Definir Casos de Uso

d ordem variada
Termos no Glossário a Protótipo bd (Alto Nível e Essenciais)

b opcional
a ongoing
c adiável
7. Definir Modelo 8. Definir Arquitetura 9. Aperfeiçoar (Refinar)

Conceitual Inicial c Inicial do Sistema acd Plano

FCT-UNESP 16/05/2017
Método Larman BCC

16/05/2017
Engenharia de Requisitos


Termos no Glossário Protótipo (Alto Nível e Essenciais)

Conceitual Inicial Inicial do Sistema Plano
Entendimento dos Requisitos BCC

16/05/2017
 Objetivos:
 Criar os artefatos da fase de engenharia de
requisitos
 Documento de Especificação de Requisitos
 Identificar e categorizar as funções do sistema
 Identificar e categorizar os atributos do sistema
e relacioná-los com as funções
JÁ VISTO!!!

FCT-UNESP 16/05/2017
Funções do Sistema BCC

16/05/2017
 O QUE o sistema deve fazer?

 ex: autorizar pagamento por cartão de crédito
 funções do sistema devem ser identificadas e
listadas em agrupamentos lógicos
 Geralmente escritas da forma: “O sistema
deve fazer <X>”
 Cada função pode ser expressa em termos
de um ou mais requisitos que o sistema
deve atender
Tipos de Funções BCC

16/05/2017
 Evidente ou Visível (E): deve ser executada e o

usuário tem conhecimento de ela foi executada
 Oculta (O): deve ser executada, mas não é visível
para o usuário
 vale para muitos serviços técnicos de infra-estrutura, tais
como salvar a informação em um dispositivo permanente
de armazenamento
 são freqüentemente, e incorretamente, esquecidas durante
a fase de especificação de requisitos

FCT-UNESP 16/05/2017
Tipos de Funções BCC

16/05/2017
 Enfeite/Decoração/Luxo (D): opcional

 sua adição não afeta significativamente o custo
ou outras funções. ???
Estudo de caso - TPV BCC

16/05/2017
 Descrição Geral:
 O propósito deste projeto é criar um terminal de
ponto de vendas (TPV) para ser usado em lojas
de varejo
 Clientes
 ObjectStore, Inc., uma multinacional que
comercializa objetos

FCT-UNESP 16/05/2017
Estudo de caso - TPV BCC

16/05/2017
 Objetivos:
 O objetivo geral é aumentar a automatização
das compras (checkout) para permitir serviços e
processos comerciais mais rápidos, melhores e
mais baratos. Tipicamente, isso inclui:
 checkout (passagem pelo caixa) mais rápido para o
cliente
 análise rápida e precisa do crédito
 controle automático do estoque
TPV - Funções Básicas BCC

16/05/2017
 R1.1 – Registrar a venda em andamento (corrente),

isto é, os itens comprados (E)
 R1.2 – Calcular o total da venda corrente, incluindo

os cálculos de impostos e de cupons de desconto
(E)
 R1.3 – Capturar a informação de um item adquirido,

usando o código, obtido por um leitor de código de
barra, ou pela entrada manual do código do
produto, usando o código universal de produto
(CUP ou UPC) (E)

FCT-UNESP 16/05/2017
Funções Básicas - TPV BCC

16/05/2017
 R1.4 – Reduzir a quantidade em estoque

quando a venda for finalizada (O)
 R1.5 – Registrar as vendas completadas (O)
 R1.6 – O funcionário (Caixa) deve abrir o
caixa (log in) com um Identificador (ID) e uma
senha para poder usar o sistema (E)
 R1.7 – Fornecer um mecanismo de
armazenamento permanente (O)
Funções Básicas - TPV BCC

16/05/2017
 R1.8 – Fornecer mecanismos de

comunicação inter-processos e inter-
sistemas (O)
 R1.9 – Exibir a descrição e o preço do item
registrado (E)

FCT-UNESP 16/05/2017
Funções de Pagamento - TPV BCC

16/05/2017
 R2.1 – Tratar os pagamentos em dinheiro:

capturar a quantia recebida e informar o
troco (E)
 R2.2 – Tratar o pagamento com cartão de
crédito: captar a informação do cartão de
crédito por um leitor de cartões ou uma
entrada manual e autorizar o pagamento com
o serviço de autorização de crédito (externo)
da loja via conexão por modem (E)
Funções de Pagamento - TPV BCC

16/05/2017
 R2.3 – Registrar os pagamentos por crédito

no sistema de contas a receber da loja, uma
vez que o serviço de autorização de crédito
deve à loja a quantia oferecida como
pagamento (O)
 R2.4 – Tratar os pagamentos com cheque:
capturar o CPF por entrada manual e
autorizar o pagamento com o serviço de
autorização de crédito da loja (externo) via
conexão por modem (E)

FCT-UNESP 16/05/2017
Atributos do Sistema – TPV BCC

16/05/2017
 para R1.9 (Exibir a descrição e o preço do

item registrado (E))
 tempo de resposta: Max 5s  Obrigatório
 metáfora da interface:
 saída baseada em formulário  Obrigatório
 saída colorida  Desejável
Atributos do Sistema – TPV BCC

16/05/2017
 para R2.3 (Registrar os pagamentos por

crédito no sistema de contas a receber da
loja (O))
 tolerância a falhas: deve registrar no sistema de
contas a receber em 24h, mesmo em caso de
falhas elétrica ou de hardware  Obrigatório
 tempo de resposta: Max 10s  Obrigatório

FCT-UNESP 16/05/2017
Método Larman BCC

16/05/2017



Casos de Uso: descrevendo

processos BCC
16/05/2017
 Objetivos:
 Identificar e Escrever Casos de Uso
 Elaborar Diagramas de Casos de Uso
 Contrastar Casos de Uso de Alto Nível e
Expandidos
 Contrastar Casos de Uso Reais e Essenciais

FCT-UNESP 16/05/2017
Casso de Uso –
Documentação BCC
16/05/2017
 Um documento de fluxo de eventos é criado para

cada caso de uso
 Escrito do ponto de vista do ator
 Detalha o que o sistema deve fornecer quando o

caso de uso é executado
 Conteúdos típicos
 Como o caso de uso inicia e termina
 Fluxo normal de eventos
 Fluxos alternativos de eventos
 Fluxos excepcionais de eventos (respostas a erros)
Casos de Uso BCC

16/05/2017
 Um caso de uso é um padrão de

comportamento que o sistema exibe
 Cada caso de uso é uma seqüência de

transações relacionadas executadas por um ator
e o sistema em um diálogo

FCT-UNESP 16/05/2017
Casos de Uso BCC

16/05/2017
 Um caso de uso é um documento textual que

descreve a seqüência de eventos realizados por um
ator (um agente externo) para completar um
processo durante o uso do sistema
 Contam “histórias” de utilização do sistema
 Casos de uso não são especificação de requisitos,

mas ilustram e implicam requisitos
 dependem de que se tenha um entendimento ao menos
parcial dos requisitos do sistema
Atores BCC
16/05/2017
 Um ator é uma entidade externa ao sistema que

participa de um caso de uso de alguma forma.
 Atores interagem com o sistema, estimulando-o
com eventos de entrada ou de saída
 Representam o papel que desempenham no caso
de uso. Ex: Cliente, Caixa
 uma pessoa, por exemplo, pode assumir vários papéis
 várias pessoas podem ser instâncias de um ator

FCT-UNESP 16/05/2017
Atores BCC
16/05/2017
 Atores podem ser papéis desempenhados

por pessoas, sistemas de computadores,
dispositivos elétricos e mecânicos, …
 Para um caso de uso, geralmente existe um

ator iniciador e possivelmente vários outros
atores participantes
Método Larman:
Formatos dos Casos de Uso BCC
16/05/2017
 de alto nível
 descreve o processo sucintamente, em duas ou
três sentenças
 são vagos a respeito de decisões de projeto e
são úteis para a compreensão dos principais
processos globais
 expandidos
 mostram mais detalhes
 compreensão mais profunda dos processos e
requisitos

FCT-UNESP 16/05/2017
Caso de Uso de Alto Nível BCC

16/05/2017
Usar verbo para

nomear caso de
Caso de uso: Comprar Itens uso
Nome de atores
Atores: Cliente, Caixa com letra
maiúscula
Tipo: primário (a ser discutido adiante…)
Descrição: Um Cliente chega ao balcão de saída da

loja com itens que deseja comprar. O Caixa
registra os itens de compra e recebe o
pagamento. Quando termina, o Cliente sai
com os itens comprados.
Caso de Uso Expandido BCC

16/05/2017
Parte 1
Descrição similar ao
Caso de uso de Alto Nível
Parte 2
Descrição da sequência
típica de eventos
Parte 3
Descrição de sequências
Alternativas de eventos

FCT-UNESP 16/05/2017
Caso de Uso Expandido

(Parte 1 - Resumo) BCC
16/05/2017
(restrito a pagamento em dinheiro e sem tratar controle de estoque)

Caso de Uso: Comprar Itens com Dinheiro
Informar ator que
Atores: Cliente (iniciador), Caixa inicia o processo
Finalidade: Capturar a venda e seu pagamento em dinheiro

Visão geral: Um Cliente chega ao balcão de saída da loja com itens que
deseja comprar. O Caixa registra os itens de compra e
recebe o pagamento. Quando termina, o Cliente sai com os
itens comprados.
Tipo: primário e essencial (a ser discutido adiante…)
Referências Requisitos: R1.1, R1.2, R1.3, R1.7, R1.9, R2.1

Cruzadas:

16/05/2017
 Rastreabilidade
 A cláusula de referência cruzada permite conferir
se todos os requisitos foram atendidos por casos
de uso.
 Ao final, todos os casos de uso devem poder ser

rastreados para a implementação e o teste.

FCT-UNESP 16/05/2017
Lembrando... BCC
16/05/2017
 R1.1 – Registrar a venda em andamento … (E)

 R1.2 – Calcular o total da venda corrente … (E)
 R1.3 – Capturar a informação de um item adquirido,
usando o código… (E)
 R1.7 – Fornecer um mecanismo de armazenamento
permanente (O)
 R1.9 – Exibir a descrição e o preço do item
registrado (E)
 R2.1 – Tratar os pagamentos em dinheiro… (E)

Parte 2 - Seqüência típica de eventos BCC
16/05/2017
Ação do ator Resposta do Sistema
1. Este caso de uso começa quando o Cliente
chega ao TPV com itens para comprar
2. O Caixa registra o identificador de cada 3. Determina o preço do item e adiciona

item informação sobre o item à transação de venda
corrente
Se há mais de um do mesmo item, o caixa A descrição e o preço do item são

também entra a quantidade apresentados
4. Quando termina a entrada dos itens, o 5. Calcula e apresenta o total da venda
Caixa indica ao TPV que as entradas estão
completas
6. O Caixa informa o total ao cliente
7. O Cliente entrega o pagamento em dinheiro

– o “pagamento em dinheiro” – possivelmente
maior que o total da venda

FCT-UNESP 16/05/2017

Parte 2 - Seqüência típica de eventos-Cont. BCC
16/05/2017

8. O Caixa registra a quantidade de dinheiro 9. Exibe o valor do troco a ser devolvido ao
recebida cliente
10. O Caixa deposita o dinheiro recebido e 11. Registra a venda completada (logs)
retira o troco devido
O Caixa entrega ao cliente o troco e o recibo

impresso
12. O Cliente sai com os itens comprados

(Parte 3 – Seqüências Alternativas) BCC
16/05/2017
 Descreve alternativas importantes ou

exceções que podem ocorrer numa
seqüência típica
 se forem muito complexas podem se transformar
num caso de uso
 Seqüências alternativas:
 Linha 2: Identificador de item inválido digitado.
Indicar o erro.
 Linha 7: O Cliente não tem dinheiro suficiente.
Cancelar a transação de venda

FCT-UNESP 16/05/2017
Tipos de Casos de Uso (I) BCC

16/05/2017
 Primários : principais processos comuns

Ex: Comprar Itens
 Secundários: processos menos importantes ou

raros
Ex: Requisição de estoque de produto novo
 Opcionais: processos que podem não ser incluídos

na solução
Tipos de Casos de Uso (II) BCC

16/05/2017
 Essencial: caso de uso expandido expresso numa

forma ideal, que é relativamente livre de detalhes
tecnológicos e de implementação
 decisões de projeto são postergadas
 Real: descreve o processo em termos de seu

projeto atual (real)
 considera tecnologia, entrada e saída, interface,…
 definido na fase de projeto

FCT-UNESP 16/05/2017
Tipos de Casos de Uso (II) BCC

16/05/2017
 Casos de uso de alto nível são essenciais por

natureza, devido à sua forma resumida e alto nível
de abstração
 O intervalo entre essencial e real deve ser visto

como um contínuo em que o caso de uso pode se
situar em qualquer ponto
Requisitos/Análise Projeto
Essencial, Real,
muito muito
16/05/2017
abstratoCiência da Computação - Engenharia de Software I - Rogério Eduardo Garcia
concreto 72
Caso de Uso Comprar Itens:

Essencial BCC
16/05/2017

1. Este caso de uso começa quando o
Cliente chega ao TPV com itens para
comprar
2. O Caixa registra o identificador de 3. Determina o preço do item e adiciona
cada item informação sobre o item à transação de
venda corrente
Se há mais de um do mesmo item, o A descrição e o preço do item são
caixa também entra a quantidade apresentados
4. … ….

FCT-UNESP 16/05/2017
Caso de Uso Comprar Itens:

Real BCC
16/05/2017
Ação do Ator Resposta do Sistema

1. Este caso de uso começa quando o
Cliente chega ao TPV com itens para
comprar
2. Para cada item o Caixa digita o código 3. Mostra o preço do item e adiciona a
universal do produto no campo de informação do item à transação de venda
entrada UPC da janela. Ele então corrente. A descrição e o preço são
pressiona o botão “Entrar Item” com o mostrados na caixa de texto 2 da Janela1.
mouse ou pressiona <Enter>
…. ...
Importante BCC
16/05/2017
 Em geral, os casos de uso reais não devem

ser produzidos na fase de engenharia de
requisitos (comprometimento prematuro com
uma decisão de projeto e complexidade
desnecessária)

FCT-UNESP 16/05/2017
Resumo BCC
16/05/2017
Alto nível
Formato do caso de uso
Expandido
Primário
Tipo do caso de uso (I)
Secundário
Opcional
Tipo do caso de uso (II) Essencial

Real
Diagrama de Casos de Uso:

UML Diagram BCC
16/05/2017
 Objetivo
 Mostrar como o sistema a ser desenvolvido irá
interagir com o ambiente, delimitando o sistema e
definindo a funcionalidade
 Importantes na organização e modelagem do

comportamento do sistema

FCT-UNESP 16/05/2017
Diagrama de Casos de Uso BCC

16/05/2017
 Um diagrama de caso de uso mostra o

relacionamento entre os atores e os casos de uso
dentro de um sistema.
 Um caso de uso representa uma funcionalidade do
sistema.
 Representado por uma elipse contendo o nome do caso de
uso.
 Um ator é um agente externo (um usuário ou um outro
sistema) que interage com o sistema.
 Pode ser representado como um retângulo de classe com o
estereótipo "ator” ou pela figura de um homem estilizado.

Notação BCC
16/05/2017
Comprar Itens
ícone para caso de uso

Caixa
ícone para ator

FCT-UNESP 16/05/2017

16/05/2017
TPV
Comprar
Itens
Abrir
Caixa (Log in) Cliente
Reembolsar
Itens

16/05/2017
TPV
Comprar
Itens
Abrir
Caixa (Log in) Cliente
Reembolsar
Itens

FCT-UNESP 16/05/2017

Notação BCC
16/05/2017
 Relacionamentos entre casos de uso e atores:

 communicates: relacionamento entre atores e casos de
uso.
 extends: um relacionamento extends de um caso de uso

A para um caso de uso B indica que uma instância de B
pode incluir o comportamento especificado por A.
 include: um relacionamento include de um caso de uso A

para um caso de uso B indica que uma instância
de B inclui o comportamento especificado por A.

Notação BCC
16/05/2017
Relacionamento <<include>> Relacionamento <<extends>>
Cliente RealizarPedido Cliente RealizarPedido

<<extends>>
<<include>>
ValidarCliente CadastrarCliente

FCT-UNESP 16/05/2017

Exemplo BCC
16/05/2017
Sistema de Biblioteca
Leitor Adicionar título
Reservar
Cancelar << extends >>

reserva
Remover
/atualizar
<<extends>> título << extends >>
Bibliotecário Manter
Emprestar
Adicionar item << extends >> Bibliotecário
<< extends >>

Devolver
Adicionar leitor
Identificação de casos de uso BCC

16/05/2017
 Dois métodos: baseado nos atores ou

baseado nos eventos do sistema
 Baseado em atores
 Identificar os atores relacionados a um sistema
ou organização
 Para cada ator, identificar os processos que eles
iniciam ou dos quais eles participam
 Exemplos:
 Caixa - Iniciar uso, Registrar retirada de dinheiro
 Cliente – Comprar itens, Reembolsar itens

FCT-UNESP 16/05/2017
Identificação de casos de uso BCC

16/05/2017
 Baseado em eventos
 Identificar os eventos externos aos quais um
sistema deve responder
 Relacionar os eventos a atores e a casos de uso
 Exemplos:
 Itens vendidos (ator=cliente, caso de uso=comprar
item)
 Dinheiro retirado (ator=caixa, caso de uso=registrar
retirada de dinheiro)
Importante BCC
16/05/2017
 um caso de uso não representa um passo individual ou uma

operação ou transação de entrada. por exemplo: “imprimir o
recibo” não é um caso de uso no sistema de TPV
 um caso de uso é normalmente a descrição de um processo

relativamente grande, com início e fim próprios, que
normalmente incluem várias transações ou operações de
entrada e saída. Ex:
 retirar dinheiro de um caixa automático
 matricular-se em uma disciplina
 verificar ortográfica em um editor de texto
 …

FCT-UNESP 16/05/2017
Escopo do Sistema BCC

16/05/2017
 O sistema pode ser limitado por:

 Hardware ou software
 Departamentos de uma organização
 Toda a organização
 O limite é sempre delimitado arbitrariamente pelo

analista e o cliente, mas geralmente leva em conta
critérios tais como: política organizacional, limites de
menor comunicação entre os subsistemas,
oportunidade e tamanho do sistema
Exemplo BCC
16/05/2017
TPV
Comprar
Ex: considerar toda a loja como sendo
Itens
o sistema. O caixa está dentro do
Abrir
Cliente
sistema e é um de seus recursos.
Caixa (Log in)
Reembolsar
Itens
LOJA
Comprar
Itens
Limite do
sistema Cliente
Reembolsar
Itens

FCT-UNESP 16/05/2017
Decisão e Desvio BCC

16/05/2017
 Pontos de decisão e desvio podem ocorrer em um caso de

uso
 Ex: no caso de uso Comprar Itens, o cliente pode pagar em
dinheiro, cartão de crédito ou cheque
 Dividir o caso de uso em seções
 Para cada caso de uso:
 Parte 1 – Resumo
 Seção Principal
 parte 2 – seqüência típica de eventos
 parte 3 – seqüências alternativas
 Seção Pagamento com dinheiro
 parte 2 – seqüência típica de eventos
 parte 3 – seqüências alternativas
 Seção Pagamento com cartão de crédito
 …
Caso de Uso Comprar Itens

Seção Principal
BCC
Seqüência típica de eventos 16/05/2017
1. Este caso de uso começa quando o Cliente chega
ao TPV com itens para comprar
2. O Caixa registra o identificador de cada item … 3. Determina o preço do item…
4. Quando termina a entrada dos itens… 5. Calcula…

7. O Cliente escolhe o tipo de pagamento:
i. Se for pagamento em dinheiro, ver seção
Pagamento em Dinheiro
ii. Se for pagamento com cartão de crédito ver
seção Pagamento por Cartão de Crédito
iii. Se for pagamento por cheque, ver seção
Pagamento em Cheque
8. Registra a venda completada

9. O Caixa entrega o recibo para o Cliente
10. O Cliente sai da loja com os itens…

FCT-UNESP 16/05/2017
Caso de Uso Comprar Itens

Seção Pagamento com Dinheiro
BCC
Seqüência típica de eventos 16/05/2017

1. O Cliente entrega o pagamento em
dinheiro, possivelmente maior que o total
da venda
2. O Caixa registra a quantidade de 3. Exibe o valor do troco a ser devolvido
dinheiro recebida ao cliente
4. O Caixa deposita o dinheiro recebido e
retira o troco devido
O Caixa entrega o troco ao Cliente
Seqüência alternativa:
• Linha 4: Dinheiro insuficiente na gaveta para pagar o troco. Solicita
dinheiro ao supervisor
Planejar e Elaborar:
Passos do Processo BCC
16/05/2017
1. Listar todas as funções (requisitos), definir os limites do sistema e

identificar atores e casos de uso.
2. Escrever todos os casos de uso no formato de alto nível, classificando-
os como principais, secundários e opcionais.
3. Desenhar o diagrama de casos de uso.
4. Escrever o formato expandido dos casos de uso mais importantes,

mais complexos ou mais arriscados. Os demais poderão ser
expandidos quando forem tratados em fases posteriores do processo
de desenvolvimento.
5. Idealmente, postergar os casos de uso reais até a fase de projeto.

Exceções podem ocorrer se:
a) descrições concretas auxiliam grandemente a compreensão, ou
b) os clientes demandam que o processo seja especificado dessa
forma.

FCT-UNESP 16/05/2017
Exemplo – Sistema TPV BCC

16/05/2017
(Passo 1. Identificar atores, casos de uso e limites do sistema.)
Os limites do sistema serão definidos como o sistema de hardware e

software.
Atores e casos de uso:
Caixa: Abrir (Log In), Retirar dinheiro da caixa, Fechar

Cliente: Comprar Itens, Reembolsar Itens
Gerente: Iniciar e Encerrar (o sistema)
Administrador do Sistema: Adicionar novo usuário

16/05/2017
(Passo 2. Escrever casos de uso no formato de alto nível.)
Caso de uso: Comprar Itens

Atores: Cliente (iniciador), Caixa
Tipo: primário
Descrição: Um cliente chega ao balcão de saída da loja com
itens para comprar. O caixa registra os itens de
compra e recebe o pagamento. Quando termina,
o cliente sai com os itens comprados.

FCT-UNESP 16/05/2017

16/05/2017
(Passo 2. Escrever casos de uso no formato de alto nível.)
Caso de uso: Iniciar

Atores: Gerente
Tipo: primário
Descrição: Um Gerente liga o sistema TPV de modo a
prepará-lo para o uso pelos Caixas. O Gerente
confere que as datas e hora estão corretas, após
o que o sistema está pronto para uso dos Caixas.
Exemplo:
Sistema TPV TPV
BCC
16/05/2017
Comprar
(Passo 3. Desenhar um Itens
diagrama de casos
de uso.) Abrir
Caixa Cliente
Reembolsar
Itens
Adicionar
novos
usuários
Administrador Gerente
Do Sistema Iniciar
etc.

FCT-UNESP 16/05/2017
Exemplo – Sistema TPV

(Passo 4. Escrever casos de uso essenciais expandidos.)
BCC
16/05/2017
Caso de Uso: Comprar Itens

’
Propósito: Captura a venda e seu pagamento em dinheiro

Visão geral: Um cliente chega a um ponto de pagamento, com vários itens que
deseja comprar. O caixa registra os itens de compra e recebe o
pagamento, o qual pode necessitar autorização. No final, o cliente
sai com os itens comprados.
Tipo: primário e essencial
Referências
Cruzadas: Funções: R1.1, R1.2, R1.3, R1.7, R1.9, R2.1, R2.2, R2.3, R2.4
Casos de Uso: o caixa deve ter completado o caso de uso Abrir

BCC
16/05/2017
Seção : Principal
Seqüência Típica de Eventos
Ação do ator Resposta do sistema
1. Este caso de uso começa quando um Cli-
ente chega a um ponto de pagamento equi-
pado com um TPV, com vários itens que
deseja comprar.
2. O Caixa registra cada item. 3. Determina o preço do item e

acrescenta informação sobre o
Se houver mais de um exemplar do item, o item à transação de vendas em andamento
Caixa também pode entrar a quantidade. A descrição e o preço do item corrente são
apresentados
4. No término da entrada de itens, o Caixa 5. Calcula e apresenta o total

indica para o TPV que a entrada de itens da venda.
está completa.
6. O Caixa informa ao Cliente o total.

FCT-UNESP 16/05/2017

BCC
16/05/2017
(continuação…)
7. O Cliente escolhe o tipo de pagamento:

a. Se pagamento em dinheiro, ver seção
Pagar com Dinheiro.
b. Se pagamento com cartão, ver seção
Pagar com Cartão de Crédito.
c. Se pagamento com cheque, ver seção
Pagar com Cheque.
8. Registra a venda completada.
9. Atualiza os níveis de estoque.
10. Gera um recibo.
11. O Caixa dá o recibo ao Cliente.
12. O Cliente sai com os itens comprados.
Seqüências alternativas
Linha 2: Entrada de Identificador de item inválido. Indicas erro.

Linha 7: Cliente não pode pagar. Cancelar a transação de venda.

BCC
16/05/2017
Seção: Pagar com Dinheiro
1. O Cliente dá um pagamento em dinheiro.
O valor fornecido é possivelmente maior que o
total da venda.
2. O Caixa registra a quantia fornecida 3. Apresenta o troco devido ao
Cliente
4. O Caixa deposita o dinheiro recebido e retira
o troco devido.
O Caixa dá o troco ao Cliente
Seqüências Alternativas
Linha 1: O Cliente não tem dinheiro suficiente. Pode cancelar a venda ou iniciar outro método de
pagamento
Linha 4: A gaveta de dinheiro não contém o suficiente para pagar o troco. O Caixa solicita mais dinheiro
ao supervisor ou pede ao Cliente uma quantia de dinheiro diferente ou a opção por
um outro método de pagamento

FCT-UNESP 16/05/2017

BCC
16/05/2017
Seção: Pagar com Cartão de Crédito
1. O Cliente comunica suas 2. Gera uma solicitação de pagamento com
informações de Crédito para o cartão de crédito e a envia a um Serviço
pagamento com cartão de crédito de Autorização de Crédito (SAC) externo
3. O SAC autoriza o pagamento 4. Recebe uma resposta de aprovação
de crédito do SAC.
5. Lança o pagamento com cartão de crédito
e a informação da resposta de aprovação no
sistema de Contas a Receber (C/R). (O SAC
deve dinheiro à Loja, logo C/R deve fazer o
acompanhamento)
6. Exibe a mensagem de autorização bem
sucedida
Linha 3: Solicitação de crédito negada pelo SAC. Sugerir um método de pagamento diferente

BCC
16/05/2017
Seção: Pagar com Cheque

1. O Cliente preenche um cheque

e se identifica.
2. O Caixa registra a informação de 3. Gera uma solicitação de pagamento

identificação e solicita autorização com cheque e a envia a um Serviço de
para pagamento com cheque Autorização de Cheques externo
4. O Serviço de autorização de 5. Recebe uma resposta de aprovação

Cheques autoriza o pagamento do Serviço de Autorização de Cheques.
6. Indica autorização bem-sucedida.
Linha 4: Solicitação de cheque negada pelo Serviço de Autorização de Cheques. Sugerir um método de pagamento diferente

FCT-UNESP 16/05/2017
Planejar e Elaborar: Artefatos BCC

16/05/2017
Especificação de
Relatório de Requisitos
Investigação
Preliminar
Casos de Uso
a. Todos os de alto nível
b. Alguns essenciais
expandidos
Protótipos
Diagramas de Casos de Uso
Orçamento,
Cronograma Esboço do modelo conceitual
Glossário
Depende de
Método Larman BCC

16/05/2017




FCT-UNESP 16/05/2017
Método Larman BCC

16/05/2017



Modelos Conceituais BCC

16/05/2017
 Modelo Conceitual é uma representação dos

conceitos, ou objetos, do mundo real pertencentes a
um domínio de interesse
 É exibido por um conjunto de diagramas de
estrutura estática, no qual não se definem
operações
 Pode ser tratado como um “dicionário visual” das
abstrações significativas do domínio
 ajuda a compreender vocabulário e informação do domínio
 Pode mostrar: conceitos, associações entre
conceitos e atributos de conceitos

FCT-UNESP 16/05/2017
Modelagem Conceitual BCC

16/05/2017
 Realiza-se a análise do domínio da aplicação

e a modelagem das entidades e fenômenos
desse domínio considerados importantes,
independentemente da implementação.
 A tarefa de modelagem conceitual envolve
dois mecanismos:
 Abstração e
 Representação.
Modelagem Conceitual BCC

16/05/2017
Expressão segundo
Operação mental as convenções:
para observar um notação gráfica,
domínio e capturar linguagem de
sua estrutura programação, etc.
ABSTRAÇÃO REPRESENTAÇÃO
Entidade Entidade
Observada Representada
Avião

FCT-UNESP 16/05/2017
Classificação/Instanciação BCC
16/05/2017
Estudante
CATEGORIA
INSTANCIAÇÃO
de
Graduação
CLASSIFICAÇÃO
INDIVÍDUO Maria
(Objeto) José
Modelo Conceitual: Conceito BCC

16/05/2017
 Informal: idéia, “coisa”, ou objeto do mundo real no domínio

de interesse.
 Algo digno de nota, de ser documentado, de importância para o
domínio.
 Formal: Um conceito pode ser considerado em termos de

seu:
 Símbolo: palavra ou imagem representando um conceito.
 Ex.: Venda
 Intenção: a definição de um conceito.
 Ex.: Uma venda representa uma transação de compra e possui
data e hora.
 Extensão: o conjunto de exemplos (instâncias) ao qual o
conceito se aplica.
 Ex.: Venda1, Venda2, Venda3 …

FCT-UNESP 16/05/2017
Modelo Conceitual: Conceito BCC

16/05/2017
 Símbolo
 Ex.: Aeronave
 Intenção
 Ex.: (o conceito) Aeronave representa uma aeronave, ou
seja, um meio de transporte aéreo que possui categoria,
dimensões, número de lugares, …
 Extensão
 Ex.: AirBus PT999, Boing747 PX111, …
Conceitos no Sistema TPV BCC

16/05/2017
TPV Venda Loja
 Como identificar conceitos em um sistema ?

FCT-UNESP 16/05/2017
Estratégias para
Identificar Conceitos BCC
16/05/2017
 É melhor especificar em excesso um modelo conceitual com

muitos conceitos do que subespecificá-lo.
 Menos conceitos não implicam em um modelo melhor.
 Não exclua um conceito só porque sua necessidade não está
óbvia nos requisitos.
 Não exclua um conceito só porque não tem atributos – ele pode
possuir um papel de comportamento e não de informação.
 Usar uma Lista de Categorias de Conceitos.

 Identificar Substantivos.
Conceito - Definição BCC

16/05/2017
 Informal: idéia, “coisa”, ou objeto do mundo real no domínio

de interesse
 algo digno de nota, de ser documentado, de importância para o
domínio
 Formal - Um conceito pode ser considerado em termos de
seu:
 Símbolo: palavra ou imagem representando um conceito. Ex:
Venda
 Intenção: a definição de um conceito. Ex: Uma venda
representa uma transação de compra e possui data e hora
 Extensão: o conjunto de exemplos (instâncias) ao qual o
conceito se aplica: Ex: Venda1, Venda2, Venda3 …

FCT-UNESP 16/05/2017
Exemplo BCC
16/05/2017
 Símbolo - Ex: Aeronave

 Intenção - Ex: (o conceito) Aeronave representa uma
aeronave, ou seja, um meio de transporte aéreo que possui
categoria, dimensões, número de lugares, …
 Extensão - Ex: AirBus PT999, Boing747 PX111,…
Conceitos no Sistema TPV BCC

16/05/2017
TPV Venda Loja
 Como identificar conceitos em um sistema ?

FCT-UNESP 16/05/2017
Exemplos de Categorias de
Conceitos BCC
16/05/2017
 Objetos físicos ou tangíveis: TPV, Carro, Aeronave

 Especificações ou Descrições de “Coisas”:
EspecificaçãoProduto, ListaVerificação
 Lugares: Loja, Aeroporto
 Transações: Venda, Pagamento, Reserva
 Regras e Políticas: PolíticaReembolso
 Itens de linha de transação: ItemLinhaVendas
Exemplos de Categorias de
Conceitos (cont.) BCC
16/05/2017
 Papéis desempenhados por pessoas: Caixa

 Contêineres: Depósito, Armário, Aeronave
 Coisas em um contêiner: Item, Passageiro
 Catálogos: CatálogoProdutos, CatálogoPeças
 Organizações: DepartamentoVendas
 Sistema externo: SistmAutorizaçãoCartCrédito
 …

FCT-UNESP 16/05/2017
Identificação de Substantivos -
BCC
caso de uso Comprar Itens 16/05/2017
1. Este caso de uso começa quando um Cliente chega a um

ponto de pagamento equipado com um TPV com vários
itens que deseja comprar.
2. O caixa registra o código universal do produto (UPC) de
cada item.
Se houver mais de um exemplar do item o caixa
também pode entrar a quantidade.
3. Determina o preço do item e acrescenta informação sobre o
item à transação de vendas em andamento.
A descrição e o preço do item corrente são apresentados
Identificação de Substantivos BCC

16/05/2017
Lembre-se:
1. Nem todos os substantivos são conceitos – linguagem
natural pode ser ambígua
Ex: substantivos diferentes podem representar o mesmo conceito –
(Consumidor e Cliente)
2. Alguns dos substantivos são candidatos a conceitos e
outros são candidatos a atributos

FCT-UNESP 16/05/2017
Conceitos candidatos
BCC
Domínio TPV – caso de uso Comprar Itens 16/05/2017
 Ideal: Combinar as estratégias para identificar

uma lista de candidatos a conceito
• TPV • EspecificaçãoProduto
• Item • ItemLinhaVenda
• Loja
• Venda • Caixa
• CatálogoProdutos • Cliente
• Pagamento
• Gerente
Incluir no modelo objetos do

tipo relatório? BCC
16/05/2017
 Um recibo é um relatório (uma saída do sistema) de uma

venda
 a informação contida num recibo é derivada de outras fontes, e
portanto essa informação é duplicada
  razão para excluí-lo
 Um recibo desempenha um papel importante em termos das
regras do negócio
 confere ao portador o direito de retornar o item comprado 
razão para incluí-lo
 Então… o Recibo deve ser incluído somente na fase onde o
retorno de itens for tratado – considerando o ciclo de
desenvolvimento iterativo

FCT-UNESP 16/05/2017
O Conceito de Especificação
(ou de Descrição) BCC
16/05/2017
 O que aconteceria se todas as TVs de 19” (Item)

fossem vendidas ?
 Como fazer para saber o preço desse item de
venda ?
Item EspecificaçãoProduto Item

descrição ou 1 * número série
descrição
preço Descreve
preço
número série ?????
CUP
CUP
MELHOR
Quando utilizar conceitos de

especificações BCC
16/05/2017
 Quando houver necessidade da existência de uma

descrição de um item ou serviço, independente da
existência de uma instância do item ou serviço
 se a exclusão de instâncias do item/serviço resultar em
perda de informação que deveria ser mantida
 Quando reduzir informação redundante ou
duplicada

FCT-UNESP 16/05/2017
Dicas... BCC
16/05/2017
 Objetos podem ser:

 Entidades Externas que produzem ou consomem informações
(outros sistemas, pessoas)
 Coisas que fazem parte do domínio (relatórios, displays, cartas)
 Eventos que ocorrem no contexto do sistema (transferência de
propriedade)
 Papéis desempenhados por pessoas (gerente, engenheiro,
vendedor)
 Unidades organizacionais (grupo, equipe)
 Lugares que estabelecem o contexto do problema (piso de
fábrica, área de descarga)
Dicas... BCC
16/05/2017
 Isolar nomes (e locuções nominais), verbos (e locuções

verbais)
 Os nomes e os verbos que são sinônimos ou que não tem
nenhuma relação com o processo de modelagem são
omitidos
 Os nomes são classes ou atributos (itens de dados)
 Os verbos são operações (métodos) - relacionamento entre
classes

FCT-UNESP 16/05/2017
Exemplo para TPV BCC

16/05/2017
 Parte do Modelo Conceitual do TPV

 indica que os conceitos Venda e Pagamento são
significativos para o domínio
 indica que Venda e Pagamento estão relacionados de uma
forma digna de nota
Venda Pagamento
1 1
data
hora
Pago-por quantia
Modelo Conceitual BCC

16/05/2017
 Modelo Conceitual NÃO mostra artefatos de

software
NÃO!!!
 objetos ou classes de software
 métodos ou responsabilidades BDdeVendas
 janelas
 bases de dados
Venda
data
hora
imprimir ()

FCT-UNESP 16/05/2017
Cardinalidade ou
Multiplicidade BCC
16/05/2017
 Cardinalidade define quantos objetos participam da

relação
 É o número de instâncias de objetos da classe que

participam da relação
 Para cada associação e agregação, são definidas duas

multiplicidades: uma para cada participante do
relacionamento.
Multiplicidade: Exemplo BCC

16/05/2017
• A multiplicidade * C zero ou mais - muitos (as)

define quantas
instâncias de um
1..*
conceito A podem C um ou mais
ser associadas a
cada instância do
conceito B 1..40 C um a quarenta
5 exatamente cinco
C
3,5,8 exatamente três, cinco ou

C oito

FCT-UNESP 16/05/2017
Navegação BCC
16/05/2017
 Embora associações e agregações sejam bi-

direcionais por default, por ser desejável restringir a
navegação em uma direção
 Para isso, uma ponta (flecha) é adicionada à linha,

indicando a direção da navegação
Exemplo do Sistema TPV BCC

16/05/2017
associação
1 1 Venda
TPV
Captura
nome da associação direção de leitura

(default: opcional)
OBS: o símbolo SOMENTE indica direção de

leitura – não tem significado no modelo

FCT-UNESP 16/05/2017
Exemplo BCC
16/05/2017
associação
multiplicidade
1 1 Venda
TPV
Captura
nome da associação direção de leitura

(default: opcional)
1 Estoca *
Loja Item
Associação - definição BCC

16/05/2017
 Associação é um relacionamento entre

conceitos
 indica uma conexão com significado e interesse
 Em UML são descritas como

“relacionamentos semânticos entre objetos
diferentes”

FCT-UNESP 16/05/2017
Critérios para incluir

associações BCC
16/05/2017
 Quando o conhecimento associado necessita ser preservado por

algum tempo
 “necessário-ser-conhecida” – requisitos indicam essa necessidade
 Ex: associação entre Venda e Pagamento
 Evite associações cuja necessidade não é sugerida nos requisitos
 Ex: associação entre Venda e Gerente
 É mais importante identificar conceitos do que associações
 Excesso de associações pode tornar o modelo conceitual confuso
 Evite mostrar associações redundantes ou deriváveis
Associações Comuns BCC

16/05/2017
 A é uma parte física de B

 Gaveta – TPV
 Asa - Aeronave
 A é uma parte lógica de B
 ItemLinhaVenda – Venda
 PernaVôo (Flight Leg) - RotaVôo
 A está fisicamente contida em/sobre B
 Item – Prateleira
 Passageiro - Aeronave
 A está logicamente contida em B
 DescriçãoItem - Catálogo
 Vôo – ProgramaçãoVôo
 A é registrada em B
 Venda - TPV
 Reserva - ManifestoVôo

FCT-UNESP 16/05/2017
Associações Comuns BCC

16/05/2017
 A é uma descrição para B

 DescriçãoItem – Item
 DescriçãoVôo – Vôo
 A é um item de linha de uma transação ou relatório B
 ItemLinhaVenda – Venda
 ServiçoManutenção - LogManutenção
 A é uma transação relacionada a outra transação B
 Pagamento – Venda
 Reserva – Cancelamento
 …
Associações com Papéis BCC

16/05/2017
 Cada extremo de uma associação é chamado de

papel.
 Os papéis podem ter, opcionalmente, as seguintes

propriedades:
 Nome
 Expressão de multiplicidade
 Navegabilidade

FCT-UNESP 16/05/2017
Associações com Papéis BCC

16/05/2017
 Nomes de papéis são necessários,

principalmente, para associação entre dois
objetos de mesma classe.
1 1 .. * Empregado subordinado
Companhia
0 .. *
Associações Múltiplas
entre Conceitos BCC
16/05/2017
Destino
* Voa-para 1
Vôo Voa-de
Aeroporto
* 1
Origem

FCT-UNESP 16/05/2017
Associações e Implementação BCC

16/05/2017
 Uma associação indica um relacionamento significativo apenas

sob a perspectiva conceitual.
 Uma associação não implica em um fluxo de dados ou conexão
entre objetos em uma solução de software.
 Algumas associações do modelo conceitual podem não ser

necessárias na implementação.
 Durante a implementação podem ser descobertas associações

entre objetos de software que foram esquecidas durante a
modelagem conceitual.
Exemplo BCC
16/05/2017
Companhia
Aérea OBS: considere vôos não
1 simultâneos na alocação de
pessoas e aeronaves. Essa
alocação seria feita, por
Emprega exemplo, o planejamento de
vôos do dia/semana/mês…
1..*
Designada-para Designada-para
Pessoa Vôo Aeronave
1 * 1
*
1 *
Supervisiona

FCT-UNESP 16/05/2017
Exemplo Registra-venda-de
BCC
16/05/2017
Descritos-por
1..1
Catálogo de Produtos Contém
0..1 * Especificação de Produto
1..1 1..*
ItemLinhaVenda 1..1
1..1
Usado-por
1..* Descreve
*
1..1 *
Contido-em Loja Estoca
Item
1..1 Registra-dados-da * 1..1
v 1..1
* 1..1
Venda Possui
1..1
1..*
1..1 capturada-em Iniciado por Gerente
1..1
1..1 TPV 0..* 1..1
1..1
Paga-por
1..1 < Registra-Vendas-do
Iniciada-por
1..1
Iniciada-por
1..1 1..1 Caixa
1..1
Pagamento Cliente
Modelo Conceitual BCC

16/05/2017




FCT-UNESP 16/05/2017

16/05/2017
Planejar e
Construir Instalar
elaborar
Ciclo de
Desenvolvimento 1
Ciclo de
Desenvolvimento 2
…

Plano Artefatos
Método Larman BCC

16/05/2017
Refinar Sincronizar
Analisar Projetar Construir Testar
Plano artefatos
1. Definir Casos 2. Refinar Diagramas 3. Refinar o Modelo

de Uso Essenciais de Casos de Uso Conceitual
5. Definir Diagramas de
4. Refinar Glossário
Seqüência do Sistema
6. Definir Contratos 7. Definir Diagramas

de Operação de Estado

FCT-UNESP 16/05/2017
Modelo Conceitual: Atributo BCC

16/05/2017
 Um atributo é um valor de dados lógico de um objeto.

Descreve uma característica do objeto.
 Inclua no modelo conceitual apenas os atributos para os

quais os requisitos sugerem ou implicam uma necessidade
de memorizar a informação.
 Ex: preço de item, valor da compra, …
 Preferivelmente, no modelo conceitual, os tipos de atributos

devem ser simples, como:
 tipos de dados primitivos - booleano, inteiro, real, cadeia de
caracteres,...
 data, hora, cor, endereço, geometria, número de telefone, CEP,
…
Modelo Conceitual: Atributo BCC

16/05/2017
 Os atributos são descritos na segunda seção

da caixa de conceito.
 O tipo do atributo é opcional.

Venda Pessoa
data: Data nome: String

hora: Hora idade: Inteiro

FCT-UNESP 16/05/2017
Exemplo BCC
16/05/2017
Registra-venda-de
Descritos-por
1..1
CatálogoProdutos
Contém EspecificaçãoProduto
0..1 * descrição
1..1 1..* preço
ItemLinhaVenda
1..1 UPC
quantidade Usado-por
1..1
1..* * Descreve
Loja *
Contido-em 1..1 endereço Estoca
Item
1..1 nome
Registra-Dados-da 1..1 * 1..*
Venda 1..1
*
data Possui
hora
1..1
Capturada-em 1..*
1..1 1..1 Iniciado por
Paga-por TPV Gerente
Iniciada-por 1..1 1..* 1..1
1..1 1..1 1..1
Pagamento Cliente Caixa
Registra-Vendas-do
quantia
1..1
Generalização BCC
16/05/2017
 No sistema TPV – caso de uso ComprarItens :
 Os conceitos de PagamentoComDinheiro,
PagamentoComCartãoCrédito e PagamentoComCheque
são muitos semelhantes.
 Podem ser organizados em uma hierarquia de tipos (ou

conceitos).
 Hierarquia “generalização/especialização”.

FCT-UNESP 16/05/2017
Generalização BCC
16/05/2017
 Identifica o que há em comum entre conceitos.
 Permite:
 Construir classificações taxonômicas – hierarquias de tipos.
 Compreender os conceitos em termos mais gerais e abstratos, ou mais
refinados.
 Conduz a uma notação mais econômica

 Evita repetição de informação.
 Na implementação, pode ser feita com classes e herança.
Generalização: Notação UML BCC

16/05/2017
supertipo –
conceito geral
ConceitoA ConceitoA
ConceitoA1 ConceitoA2 ConceitoA3 ConceitoA1 ConceitoA2 ConceitoA3
subtipo -
conceito especializado

FCT-UNESP 16/05/2017
Generalização e Tipo BCC

16/05/2017
 A definição de um supertipo é mais geral e mais abrangente que a

definição de um subtipo.
 Pagamento: uma transação de transferência de dinheiro (não
necessariamente em espécie) de um comprador para um vendedor.
 PagamentoComCartãoCrédito: transferência de dinheiro, via uma
instituição de crédito, que necessita ser autorizada.
 Propriedade pertinência ao conjunto: todos os membros de um subtipo
são membros do supertipo.
 ex: PagamentosComCartãoCrédito estão dentro do conjunto
Pagamento.
Generalização/Especialização BCC
16/05/2017
Regra É-Um
Todos os membros de um conjunto
subtipo devem ser membros de seu
conjunto supertipo.
O Subtipo é um Supertipo.

FCT-UNESP 16/05/2017
Exemplo BCC
16/05/2017
Pagamento supertipo –
conceito geral
PagamentoComDinheiro PagamentoCheque
PagamentoComCartãoCrédito
subtipo -
conceito especializado
Pagamento
Pagamento Com Pagamento Com Pagamento Com

Dinheiro Cheque Cartão Crédito
Generalização/Especialização BCC
16/05/2017
Regra dos 100%

100% da definição do supertipo dever ser aplicada ao subtipo.
O subtipo deve estar em conformidade com 100% dos seguintes elementos
do supertipo:
• Atributos
• Associação
Pagamento
Pago-a Venda
valor: Quantia
PagamentoComDinheiro PagamentoComCartãoCrédito PagamentoComCheque

FCT-UNESP 16/05/2017
Quando definir um subtipo ? BCC

16/05/2017
 Criar subtipos significa particionar um tipo.

 Dividir um tipo em subtipos disjuntos.
 Quando mostrar a partição de um tipo?
 Depende da relevância da partição para o domínio do problema.
 Ex: No sistema TPV seria útil definir a seguinte hierarquia??
Cliente
ClienteFeminino ClienteMasculino
Dicas de quando particionar... BCC

16/05/2017
1. Um subtipo tem atributos adicionais de interesse.

2. O subtipo tem associações adicionais de interesse.
3. O conceito do subtipo é tratado, operado ou manipulado de
maneira diferente que o supertipo ou outros subtipos,
segundo formas que são de interesse considerar.
4. O conceito do subtipo representa uma coisa ou ser animado
que se comporta de maneira diferente do supertipo ou de
outros subtipos, segundo formas que são de interesse
considerar.

FCT-UNESP 16/05/2017
Exemplo BCC
16/05/2017
Pessoa Departamento
atributos em Está-vinculada-a
nome nome
comum CPF * 1
Estudante Docente
nro. UNESP titulação
* 1..2
subtipos com Cursa Ministra

atributos e
associações
adicionais, e * Disciplina
comportament código 0..3
o e distintos

16/05/2017
Pagamento
1 Venda
valor : Quantia Pago-a 1
PagamentoComDinheiro PagamentoComCartãoCrédito PagamentoComCheque
* 1
Identifica_crédito_com Pago_com
1 1
CartãodeCrédito Cheque

FCT-UNESP 16/05/2017
O que fazer??? BCC

16/05/2017
 Se uma pessoa pode ter mais de um emprego em empresas

diferentes, onde colocar a informação de salário????
Empresa Pessoa
* emprega * nome
nome
 Uma opção:
Empresa Pessoa
* emprega * nome
nome
* *
paga Salário * recebe
*
valor
Um opção MELHOR:
Tipos Associativos BCC
16/05/2017
Empresa Pessoa
* emprega * nome
nome
Emprego
TIPO
salário: Quantia ASSOCIATIVO
 Classe associativa: seus atributos estão relacionados a uma

associação e não a um dos conceitos envolvidos na associação.
 Seu tempo de vida depende do tempo de vida da associação.


FCT-UNESP 16/05/2017
Tipos Associativos BCC

16/05/2017
 Indícios da existência de tipos associativos:
 Um atributo está relacionado a uma associação.
 As instâncias do tipo associativo têm tempo de vida

dependente do tempo de vida da associação.
 Existe uma associação muitos-para-muitos entre dois

conceitos, bem como informações relacionadas à
associação propriamente dita.
Agregação BCC
16/05/2017
 É um tipo de associação usado para modelar relacionamentos

todo-parte entre coisas.
 O todo é geralmente chamado composto, as partes podem ser
chamadas componentes.
 Notação em UML: losango vazio ou preenchido.
Mão Dedo
1 0..5
COMPOSTO
COMPONENT
E

FCT-UNESP 16/05/2017
Agregação Composta BCC

(Losango Preenchido) 16/05/2017
 Agregação composta ou composição significa que:

 A multiplicidade na extremidade do composto pode ser no
máximo 1.
 Uma instância do componente pode ser parte de apenas
uma instância do composto (simultaneamente).
 Existe uma dependência de existência entre o

componente e o composto.
 A existência de uma instância do composto implica na

existência de instâncias dos componentes.
 A destruição de uma instância do composto implica na

destruição das instâncias dos componentes agregados.
Exemplos BCC
16/05/2017
 Um dedo só pode fazer parte de uma mão.
Mão 1 0..5 Dedo
 Um item de linha de venda só pode fazer parte de uma venda.
Venda 1 1..* ItemLinhaVenda
 Uma especificação de produto só pode ser parte de um catálogo.
1 1..* EspecificaçãoProduto
CatálogoProduto

FCT-UNESP 16/05/2017
Agregação Compartilhada BCC

(Losango Vazio) 16/05/2017
 Agregação compartilhada significa que:

 A multiplicidade na extremidade do composto pode ser
maior que 1.
 Uma instância do componente pode estar
simultaneamente em muitas instâncias do composto.
 Esse tipo de agregação é raro em agregados

físicos, mas aparece em conceitos não-físicos.
 Exemplo:
Software
Classe
OO * *
Modelo Conceitual:
Diretrizes para Construção BCC
16/05/2017
 Liste os conceitos candidatos relacionados aos requisitos

considerados.
 Use a Lista de Categorias de Conceitos e a Identificação de
Substantivos.
 Desenhe os conceitos em um modelo conceitual.
 Registre as associações entre conceitos.
 Acrescente os atributos necessários para completar os

requisitos.
 Identifique possíveis agregações, generalizações e tipos
associativos.

FCT-UNESP 16/05/2017
Método Larman BCC

16/05/2017
Refinar Sincronizar
Plano artefatos


Método Larman BCC

16/05/2017
Refinar Sincronizar
Plano artefatos



FCT-UNESP 16/05/2017
Diagramas de Seqüência
do Sistema (DSS) BCC
16/05/2017
 Para dar prosseguimento à fase de análise, é

desejável ter uma noção mais concreta do
comportamento esperado do sistema diante dos
eventos que fazem parte de cada caso de uso
 Idéia: investigar e definir o comportamento do sistema

como uma “caixa preta”.
 O comportamento é dependente dos casos de uso.

 Interação de atores com o sistema gera eventos que
solicitam operações em resposta.
16/05/2017
 Os diagramas de seqüência do sistema são

utilizados para especificar parte de seu
comportamento.
 Mostram um cenário global do funcionamento do

sistema, dividindo o caso de uso em partes bem
definidas, denominadas operações, que são
executadas em resposta aos eventos.

FCT-UNESP 16/05/2017
16/05/2017
 Um DSS ilustra os eventos de entrada e saída do sistema.

Para uma seqüência específica de eventos (cenário) de um
caso de uso, o DSS mostra:
 Os atores que interagem com o sistema.
 O sistema, como uma “caixa-preta”.
 Eventos do sistema gerados pelos atores.
 Eventos entre sistemas.
 A ordem dos eventos.
 Deve ser feito para uma seqüência típica do caso de uso.
 Possivelmente outros DSS podem ser criados para as
seqüências alternativas mais interessantes.
Eventos e Operações do
Sistema BCC
16/05/2017
 Um evento de sistema é um evento externo de entrada para o

sistema, gerado por um ator.
 Eventos de sistema podem incluir parâmetros.
 Cada evento inicia uma operação de resposta do sistema.

 Uma operação de sistema é uma operação executada em
resposta a um evento de sistema.
 Um mesmo nome é atribuído a um evento e à operação

correspondente (assim como mensagens e métodos).
 Eventos e operações também podem ser de saída.

FCT-UNESP 16/05/2017
Relembrando...
BCC
Caso de Uso Expandido: Comprar Itens 16/05/2017
(restrito a pagamento em dinheiro e sem tratar controle de estoque)

Caso de Uso: Comprar Itens com Dinheiro
Finalidade: Capturar a venda e seu pagamento em dinheiro
Visão geral: Um Cliente chega ao balcão de saída da loja com itens que deseja comprar. O
Caixa registra os itens de compra e recebe o pagamento. Quando termina, o
Cliente sai com os itens comprados.
Tipo: primário e essencial (a ser discutido adiante…)
Referências Requisitos: R1.1, R1.2, R1.3, R1.7, R1.9, R2.1

Cruzadas:

16/05/2017
1. Este caso de uso começa quando o Cliente

chega ao TPV com itens para comprar
2. O Caixa registra o identificador de cada 3. Determina o preço do item e adiciona
item informação sobre o item à transação de venda
corrente
Se há mais de um do mesmo item, o caixa A descrição e o preço do item são

também entra a quantidade apresentados
4. Quando termina a entrada dos itens, o 5. Calcula e apresenta o total da venda
Caixa indica ao TPV que as entradas estão
completas
7. O Cliente entrega o pagamento em dinheiro

– o “pagamento em dinheiro” – possivelmente
maior que o total daCiência
16/05/2017 venda da Computação - Engenharia de Software I - Rogério Eduardo Garcia 180

FCT-UNESP 16/05/2017

16/05/2017

8. O Caixa registra a quantidade de 9. Exibe o valor do troco a ser devolvido
dinheiro recebida ao cliente
10. O Caixa deposita o dinheiro recebido 11. Registra a venda completada (logs)
e retira o troco devido
O Caixa entrega ao cliente o troco e o

recibo impresso
12. O Cliente sai com os itens comprados
Que ator(es) realmente interage(m) com o sistema??


BCC
DSS para o Caso de Uso Comprar Itens 16/05/2017
Ator
Comprar Itens :Sistema
Operação
:Caixa Linha do
iniciarNovaVenda( ) tempo
“:” indica
instância
entrarItem(CUP, quantidade)
descrição item, total
*[mais itens]
“*[..]” indica iteração e terminarVenda()

a caixa refere-se à
iteração
fazerPagamento(quantia) Repetição
de uma
troco, recibo operação

FCT-UNESP 16/05/2017

DSS para o Caso de Uso Comprar Itens BCC
16/05/2017
Comprar Itens :Sistema

:Caixa
iniciarNovaVenda( ) Valores de retorno associados
ao evento anterior
entrarItem(CUP, quantidade)
Evento de
entrada: ator
dispara uma descrição item, total
operação do
sistema *[mais itens]
terminarVenda()
Evento com parâmetro –
representa o evento de entrada
fazerPagamento(quantia) de dados de pagamento por
Evento de saída: algum mecanismo
resposta do sistema
à uma operação troco, recibo
Operações do Sistema BCC

16/05/2017
 O conjunto de eventos do sistema define um

conjunto de operações do sistema.
 entrarItem(CUP, quantidade)
 Retorna descrição do item e total da compra.
 terminarVenda()
 Sem retorno.
 fazerPagamento(quantia)
 Retorna o troco e o recibo da compra.

FCT-UNESP 16/05/2017
Como dar nome aos eventos

do sistema??? BCC
16/05/2017
 Devem capturar a intenção do evento.

 Não devem ser nomeados em termos dos meios físicos da
entrada de dados ou dos elementos da interface.
 Começar o nome com um verbo no infinitivo.
 Exemplo:
 “entrarItem” (intenção do evento) é melhor que
“escanearItem” (revela intenções de projeto – uso de
scaner laser).
Método Larman BCC

16/05/2017
Refinar Sincronizar
Plano artefatos



FCT-UNESP 16/05/2017
Método Larman BCC

16/05/2017
Refinar Sincronizar
Plano artefatos


Contratos de Operação BCC

16/05/2017
 É importante que as tarefas atribuídas às operações sejam

bem documentadas, para evitar redundâncias e
inconsistências.
 Um contrato especifica o comportamento esperado para cada

operação correspondente a um evento do sistema.
 Linguagem precisa, analítica e rigorosa.
 Deve-se fazer um contrato para cada operação relevante.

FCT-UNESP 16/05/2017

16/05/2017
 Características típicas de um contrato:

 Nome da operação.
 Parâmetros de entrada.
 Referências cruzadas.
 Casos de uso nos quais a operação pode ocorrer.
 Pré-condições.
 Pós-condições.

16/05/2017
 Pré-Condições
 Representam o estado do sistema antes da
invocação da operação.
 Não serão verificadas pela operação.

 Assume-se que elas são verdadeiras ao invocar a
operação.

FCT-UNESP 16/05/2017

16/05/2017
 Pós-Condições
 Representam o estado do sistema após a invocação da

operação, mostrando o que mudou como conseqüência da
sua execução.
 Para cada operação, analisar os conceitos identificados no

Modelo Conceitual e definir, para cada possível objeto do
sistema, o que muda quando a operação é invocada.
 Observar o DSS para ter uma melhor idéia do contexto em

que a operação está inserida e o contexto resultante.

16/05/2017
 entrarItem
 Qual a responsabilidade desta operação?
 Em quais casos de uso ela aparece?
 O que ela considera como verdadeiro para ser

executada?
 O que muda no Modelo Conceitual após sua

invocação?

FCT-UNESP 16/05/2017

16/05/2017
 Operação: entrarItem(CUP, quantidade)

 Referências Cruzadas: Casos de uso: ProcessarVenda
 Pré-Condições: Existe uma venda em andamento.
 Pós-Condições:
 Foi criada uma instância liv de LinhaDeItemDeVenda (criação de uma
instância)
 Liv foi associada com a Venda corrente (associação formada)
 liv.quantidade tornou-se quantidade (modificação de atributo).
 liv foi associada com uma EspecificaçãoDeProduto, com base na
correspondência de um itemID (associação formada).
Método Larman BCC

16/05/2017
Refinar Sincronizar
Plano artefatos



FCT-UNESP 16/05/2017
Conclusão da Fase de Análise BCC

16/05/2017
 A fase de análise enfatiza uma compreensão dos

requisitos do sistema.
 “Fazer a Coisa Certa” – compreender objetivos, conceitos
e características do domínio do problema.
 Artefatos estudados...
Artefato da Análise Questões Respondidas
Casos de Uso Quais são os processos do domínio?
Modelo Conceitual Quais são os conceitos (objetos)?
Diagramas de Seqüência do Sistema Quais são os eventos e operações?
Contratos de Operação Qual é o comportamento da operação?


16/05/2017
Planejar e
Construir Instalar
elaborar
Ciclo de
Desenvolvimento 1
Ciclo de
Desenvolvimento 2
…

Plano Artefatos
Próximo passo...

ES I Aula04

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

ES I Aula04

Enviado por

Direitos autorais:

Formatos disponíveis

FCT-UNESP 16/05/2017

 Revisão de conceitos de Orientação a Objetos

16/05/2017 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 2

Prof. Dr. Rogério E. Garcia 1

Padrão IEEE para o

 1.1 Propósito do documento de requisitos

16/05/2017 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 6

Padrão IEEE para o

 2.1 Perspectiva do Produto

16/05/2017 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 7

Prof. Dr. Rogério E. Garcia 2

Padrão IEEE para o

 Abrangem os requisitos funcionais, não funcionais e de interface.

 Os requisitos podem documentar interfaces externas, descrever

16/05/2017 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 8

Análise de Requisitos BCC

16/05/2017 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 9

Prof. Dr. Rogério E. Garcia 3

Princípios da Análise BCC

 O domínio de informação de um problema deve ser

16/05/2017 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 10

Princípios da Especificação BCC

 Separar funcionalidade de implementação

 Uso de uma linguagem de especificação orientada

 A especificação deve abranger o sistema do qual o

 A especificação deve abranger o sistema no qual o

16/05/2017 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 11

Prof. Dr. Rogério E. Garcia 4

 Uma especificação deve ser um modelo cognitivo

 Uma especificação deve ser operacional

 Uma especificação deve ser tolerante com a não-

 Uma especificação deve ser localizada e

16/05/2017 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 12

Formulação dos requisitos BCC

Estabelecimento das Estudo de Modelagem

Prof. Dr. Rogério E. Garcia 5

Para que tudo isso? BCC

 Obter uma descrição dos requisitos

 Propor uma solução (“software”) que atenda

 Possibilidade de avaliar não apenas a

16/05/2017 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 14

Problema X Solução BCC

16/05/2017 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 15

Prof. Dr. Rogério E. Garcia 6

 É preciso planejar considerando a maneira

16/05/2017 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 16

Mundo x Paradigma OO BCC

 Mundo Real é formado por objetos que se

 Representar esses objetos em um software é mais

 A representação usando objetos facilita o

Prof. Dr. Rogério E. Garcia 7

Mundo Real Mundo Computacional

Todo software representa um Modelo de um problema

Gap Semântico BCC

 Quanto menor o Gap (diferença entre espaços)

 Diminuir o Gap implica em tornar o mapeamento do

 Sendo mais “natural”, o Paradigma de Orientação a

Prof. Dr. Rogério E. Garcia 8

Criação de Modelos BCC

ABSTRAÇÃO Modelo Conceitual

16/05/2017 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 22

Problema X Solução BCC