Aula 6_Análise e Projeto_Parte1

Análise de Sistemas
Análise e Projeto
Prof. Jeime Nunes
Email: [email protected]
Site: [email protected]
29/06/2017
Fluxo de análise e projeto

O objetivo aqui é traduzir os requisitos em
uma especificação de como implementá-los;

A UML será utilizada para essa especificação;

É preciso transformar os requisitos em um
projeto do sistema;

Será desenvolvida uma arquitetura para o
sistema;
29/06/2017
Fluxo de análise e projeto
29/06/2017
Fluxo de análise e projeto
29/06/2017
Fluxo de análise e projeto

Realizar caso de uso

Conjunto de elementos
que descreve como o caso
de uso será realizado;
29/06/2017
Fluxo de análise e projeto

Vamos usar o exemplo do sistema bancário
Desbloquear Talões
de Cheque
Efetuar Login
Solicitar Talões de Cheque
Alterar Senha
Consultar Cheques
Consultar Saldo
ClienteAtor
Realizar DOC
Realizar Transferência
Operadora do DOC
Consultar Extrato
Efetuar Pagamento do
Qualiti Card
Consultar Cotações de Ações
Comprar Ações
Vender Ações
Operadora Cartão de
Crédito
29/06/2017
Consultar Qualiti Card
Operadora Mercado de
Ações
Realizar caso de uso

Para cada caso de uso:

Encontrar as classes de análise;
Ainda bastante abstratas;
 Futuramente podem ser divididas ou mesmo
transformadas em subsistemas;



Para cada classe descrever responsabilidades,
atributos e relacionamentos;
As classes de análise podem ser de três tipos:

29/06/2017
Fronteira, entidade e controle;
Realizar caso de uso

Classes de Fronteira (boundary classes)





Fazem a fronteira do sistema com qualquer
interface externa;
Isolam o núcleo do sistema do mundo exterior;
Evitam que mudanças no mundo exterior afetem
outras classes do sistema;
Identificadas com o estereótipo <<boundary>>;
Notação UML:
ou
29/06/2017
Realizar caso de uso

Descobrindo Classes de Fronteira

Regra geral é uma classe para cada par ator/caso
de uso;
29/06/2017
Realizar caso de uso

Classes de entidade (entity)



Representam os conceitos principais do sistema, as
fontes de informações que o sistema manipula;
Principal função é armazenar e gerenciar
informação;
Notação UML:
ou
29/06/2017
Realizar caso de uso

Descobrindo classes de entidade


Observe o glossário e o fluxo de eventos do
caso de uso;
Identifique substantivos no fluxo de eventos;



Os substantivos são candidatos naturais a classes de
entidade;
Remova substantivos redundantes e vagos;
Remova atributos e operações (serão usados
mais tarde);
29/06/2017
Realizar caso de uso

Efetuar pagamento do QualitiCard
Fluxo de evento principal
1. O cliente informa os dados necessários para efetuar o pagamento do
cartão:
- O código de barras da fatura que deseja efetuar o pagamento;
- O valor que deseja pagar.
2. O sistema recupera a conta bancária do cliente logado;
3. O sistema verifica se o saldo da conta do cliente é suficiente para
realizar o pagamento;
4. O sistema debita da conta do cliente;
5. O sistema envia o pagamento à operadora de cartão de crédito;
6. O sistema registra a transação de pagamento e emite um comprovante
da mesma para o usuário. A transação registrada contém os dados da
29/06/2017
conta do cliente, o código de barras da fatura, data, hora e valor do
pagamento;
Realizar caso de uso

Efetuar pagamento do QualitiCard
29/06/2017
Realizar caso de uso

Classes de controle


Coordenam o comportamento (lógica de
controle) do caso de uso;
Interface entre fronteira e entidade;



Deixam as classes de fronteira mais reusáveis, pois
ficam isoladas do comportamento específico do
sistema;
Identificadas com o estereótipo <<control>>;
Notação UML:
ou
29/06/2017
Realizar caso de uso

Classes de controle

Usualmente, um classe de controle por caso de
uso;


29/06/2017
Casos de uso com fluxos simples podem ser realizados
sem classes de controle;
Casos de uso com fluxos mais complexos podem
precisar de mais de uma classe de controle;
Realizar caso de uso

Distribuir comportamento entre as classes



Alocar responsabilidades às classes;
Modelar interações entre classes através dos
diagramas de interação:
Usaremos os diagramas de sequência e
colaboração;
29/06/2017
UML: Diagrama de Sequência
15/06/2012
Diagrama de Sequência

Diagrama que representa a sequência de
eventos do sistema;


Identificando os métodos que são disparados
entre os atores e os objetos envolvidos;
É baseado na descrição dos casos de uso
do sistema;

O texto dos casos de uso são fontes de
informações para identificar as operações e
consultas do sistema;
15/06/2012
Diagrama de Sequência
15/06/2012
Elementos do Diagrama de Sequência
Atores: são instâncias dos atores
declarados no diagrama de casos
de uso;
 Objetos: são objetos que participam de
uma iteração durante um determinado
tempo;


Se você já iniciou o diagrama de classes,
os objetos serão instâncias das classes
existentes no sistema;
15/06/2012
Elementos do Diagrama de Sequência

Linha de vida: representa o tempo
em que um objeto existe durante
um processo;


Interrompida com um “X” quando o
objeto é destruído;
Foco de controle ou Ativação: indica
os períodos que um objeto está
participando ativamente do
processo;
15/06/2012
Elementos do Diagrama de Sequência

Mensagens ou estímulos

Utilizadas para demonstrar a ocorrência de
eventos;


Normalmente forçam a chamada de um método em
algum dos objetos;
Podem ser disparadas entre: ator para ator,
ator para objeto; objeto para objeto e objeto
para ator;
15/06/2012
Elementos do Diagrama de Sequência

Mensagens de retorno


É a resposta a uma mensagem para o objeto
que a chamou;
São representadas por uma seta tracejada
apontando para o objeto ou ator que recebe o
resultado do método chamado;
15/06/2012
Elementos do Diagrama de Sequência

Auto-chamadas

São mensagens que partem da linha de vida
de um objeto e atingem a linha de vida do
próprio objeto;
15/06/2012
Elementos do Diagrama de Sequência

Fragmentos de Interação



É uma parte de uma interação, porém é
considerado como uma interação
independente;
Representado por um retângulo que envolve a
interação, com uma aba no canto superior
contendo um operador que indica o tipo de
diagrama de interação ele se refere;
Ex:

15/06/2012
sd Confirmar pedido
Nome da interação
Operador sd (diagrama de sequência
Elementos do Diagrama de Sequência

Fragmentos de Interação
15/06/2012
Os fragmentos são úteis para poder referencia-los
por meio do operador Ref (Referred – referido). Ou
seja, o fragmento faz referência a outro diagrama.
Elementos do Diagrama de Sequência

Ocorrência de Interação
Operador
15/06/2012
As referencias em um fragmento de interação são
chamadas de Ocorrências de Interação. Permite a
criação de diagramas complexos que fazem
referências a outros diagramas.
Elementos do Diagrama de Sequência

Fragmentos combinados e operadores
UML

Utilizados para uma modelagem semiindependente de parte do diagrama em que se
deve focar algum problema;

Representado por um retângulo que determina
a área de abrangência do fragmento;

15/06/2012
No canto superior esquerdo do retângulo contém
uma subdivisão com um operador de interação que
define o tipo de fragmento que está sendo modelado;
Elementos do Diagrama de Sequência
Fragmentos
combinados e
operadores UML

15/06/2012
Elementos do Diagrama de Sequência

Outros Operadores UML

Opt (Opção): determina que o fragmento
combinado pode ou não ser executado;
15/06/2012
Elementos do Diagrama de Sequência

Outros Operadores UML

Loop (Laço): determina que o fragmento
representa um laço que poderá ser repetido
diversas vezes;
15/06/2012
Elementos do Diagrama de Sequência

Outros Operadores UML





Par (paralelo): representa uma execução
paralela de dois ou mais comportamentos;
Break(Quebra): indica uma quebra na
execução normal do processo;
CriticalRegion (Região Critica): identifica uma
operação que não pode ser interrompida por
outro processo até ser totalmente concluída;
Ignore(Ignorar): indica que as mensagens
contidas no fragmento devem ser ignoradas;
Vejam outras no livro;
15/06/2012
29/06/2017