Engenharia de Software Aula 02

Engenharia de Software
Aula 02
Prof. César França
PARFOR / UFRPE

PARFOR / UFRPE
Terreno
Localização
Fluxo de
Pessoas
Tipo de
Pessoas
Tempo de
Construção
Clima
Quantidade de
Recursos
Qualidade do
Material
Arquitetura
Planta-baixa
Tendência de
Mercado

Desenvolvimento Tradicional
(Clássico / Cascata / Waterfall)
PARFOR / UFRPE

Linha de Produção
Pipeline
FAFICA - Faculdade de Filosofia, Ciências e Letras de Caruaru 5
Analista Projetista Programador Testador
Gerente

A Equação da Engenharia
Potencial Produtivo = Qualidade x Escopo
Custo x Tempo
PARFOR / UFRPE

Modelo Espiral
ProjetoPlanejamento
Implementação
Implantação
PARFOR / UFRPE

Métodos Ágeis
Tradicional Ágil
Escopo Prazo
Custo
Qualidade
Qualidade Prazo
Custo
Escopo
PARFOR / UFRPE

Modelagem Orientada a Objetos
Prof. César França

Representação de Objetos
Telefone Tecla
Número Letra
Câmera Lente
1
1
1 *
1
*
1
1
1

Análise x Projeto
Análise  Investigação Projeto  Solução

Representações
Requisitos
Estrutura
Estática
Estrutura
Dinâmica

Ferramentas UML
Funcionalidades Comuns
• Diagramação
• Engenharia Reversa
• Geração de Código
• Intercâmbio de Diagramas
• Transformação de Modelos
Existem mais de 100 no mercado!
“Embora a UML defina uma
linguagem precisa, ela não é uma
barreira para futuros
aperfeiçoamentos nos conceitos
de modelagem”

Modelagem de Negócios
PARFOR / UFRPE

http://www.wthreex.com/rup/

Finalidades:
• Entender a estrutura e a dinâmica da organização na qual um software deve
ser implantado.
• Entender os problemas atuais da organização-alvo e identificar as
possibilidades de melhoria.
• Assegurar que os clientes, usuários e desenvolvedores tenham um
entendimento comum da organização-alvo.

(Artefatos)

Modelagem de
Negócios
Ciclo Opcional

Exemplo prático
Atendimento Bancário
Um cliente deseja fazer um depósito
no banco. Ao chegar no banco,
depara-se com uma fila e aguarda
até chegar a sua vez. Quando o
atendente o chama, ele fala que quer
fazer o depósito, entrega o cheque e
diz qual é a conta para depósito. O
atendente confere o cheque e
despacha para compensação. O setor
de compensação do banco verifica o
saldo da conta do emissor do cheque
e, caso tenha saldo, efetua a
transferência e arquiva o cheque.
Dois dias úteis depois, a quantia está
disponível na conta depositada.

Exemplo prático
Entendendo o Problema:

RUP
Objetivo:
Desenvolver uma visão da nova organização-alvo e, com base nesta visão, definir os processos, os papéis e as
responsabilidades dessa organização em um modelo de casos de uso de negócios.
Banco
Setor de
Atendimento ao
Cliente
Setor de
Pagamentos
Setor de
Investimentos
Setor de
Conferência dos
Cheques
Setor de
Cobranças
Setor de Crédito

Escopo da Modelagem de Negócios
• Um Novo Negócio
• Um Negócio Existente
• Um Negócio, Muitos Sistemas
• Um Sistema, Muitos Negócios
• Re-engenharia de Negócios

Descrição da Organização
O que é?
O que faz?
Onde atua?
Qual o tamanho?
Quantos anos no mercado?
Quanto clientes?
Perfil dos clientes?
FAFICA - Faculdade de Filosofia, Ciências e Letras de Caruaru
28

Organograma
Quantos funcionários?
O que eles fazem?
Quem são?
Quais são as características
destes funcionários?
29

Estrutura do Documento de Visão
1. Introdução
2. Posicionamento
• Oportunidade de negócios
• Detalhes sobre o problema
• Posicionamento do produto
3. Descrição da Parte Interessada
• Histórico, Descrição, etc.
• Perfis de Usuários
• Necessidades de cada parte/perfil
• Alternativas e concorrência
4. Visão Geral do Produto
• Funções e Benefícios
• Custo e precificação
• Licenciamento
5. Recursos do Produto
• Recursos/funcionalidades
• Restrições de uso
• Faixas de qualidade
• Padões aplicáveis
• Documentação
PARFOR / UFRPE
https://www.ibm.com/support/knowledgecenter/pt-
br/SSWMEQ_4.0.6/com.ibm.rational.rrm.help.doc/to
pics/r_vision_doc.html

UML: Diagrama de Atividades
PARFOR / UFRPE

Na UML...
Diagramas de Atividade capturam ações e seus resultados. São utilizados –
num primeiro momento – para representar a forma como os processos do
negócio ocorrem.
Uma atividade representa um processo do negócio.
Ex.
Um cliente deseja fazer um depósito no banco. Ao chegar no banco, depara-se com
uma fila e aguarda até chegar a sua vez. Quando o atendente o chama, ele fala que
quer fazer o depósito, entrega o cheque e diz qual é a conta para depósito. O
atendente confere o cheque e despacha para compensação. O setor de compensação
do banco verifica o saldo da conta do emissor do cheque e, caso tenha saldo, efetua a

Ação
Uma ação representa um passo relevante de uma
atividade.

Transição
Encadeamento de passos do processo.
Obs1.
Ao terminar uma ação, o fluxo
imediatamente passa para a próxima!
Obs2.
Cada ação só pode ter um único ponto
de chegada e um único ponto de saída!
Obs3.
Ações DEVEM ser nomeadas com
VERBOS NO INFINITIVO

Início/Fim
Toda atividade deve ser marcada com seu pontos
iniciais e finais.

Decisão e Condições
Representa os pontos de decisão em uma atividade.
A decisão corresponde ao “SE” lógico.

Convergência
Quando uma ação pode ser disparada após mais de
um evento.
Corresponde ao “OU” lógico.

BPM (Business Process Management)
PARFOR / UFRPE

BPM (Business Process Modeling)
PARFOR / UFRPE

BPMN (Business Process Modeling Notation)
PARFOR / UFRPE

Requisitos
Não foi isso que
eu pedi!
(~10%)
Isso não era pra
ser assim!
(~10%)
Está faltando
aquela outra
função!
(~15%)
Pfleeger

O que são?
• Descrições de serviços
oferecidos pelo sistema, bem
como suas restrições
operacionais
• Necessidades do cliente
• O que o usuário quer
• O que o usuário precisa
• Comportamento desejado do
sistema
Sommerville
Pressman
Pfleeger

Pra que servem?
Requisitos do usuário
• Será que o que eu pedi, foi
feito?
Requisitos do sistema
• Como isso deve ser feito?
Analista de Requisitos
Sommerville

Engenharia de Requisitos
“é o processo de descobrir, analisar, documentar e verificar os
requisitos do usuário e do sistema”
Sommerville

Etapas da
Elicitação
Análise e
Especificação
Validação
Pressman
Levantamento de
requisitos
Determinação do
escopo
Documentação
Detalhamento
Verificação
O que o cliente
quer?
O que o cliente
precisa?
Como vamos
implementar isso?
Nós fizemos tudo
o que o cliente
pediu?
Cadê?

Elicitação de Requisitos
Elicitação
Análise e
Especificação
Validação
Pressman

Elicitação de Requisitos
Stakeholders
• Clientes
• Usuários
• Clientes dos clientes
• Governo
• Etc...
Resolução de Conflitos
Sommerville Pressman

Tipos de Requisitos
Funcionais
• Funcionalidades
• Funções
• Features
• Casos de Uso
Não-Funcionais
• Segurança
• Desempenho
• Usabilidade
• Confiabilidade
• Hardware e Software
• Normas e Padrões

Especificação de Requisitos
Elicitação
Análise e
Especificação
Validação
Pressman

Elicitação de requisitos
• Ex. Cadastro de clientes
Especificação de requisitos
• Deve conter: nome, telefone, etc
• O cadastro de clientes só pode ser modificado pelo chefe
• Pintar o nome de vermelho, se o cliente for devedor
• ...
Sommerville

Características de Requisitos
Requisitos devem ser:
• Detalhados
• Padronizados
• Consistentes
• Verificáveis
• Rastreáveis
• Aprovados pelo cliente
Requisitos NÃO devem ser:
• Ambíguos
• Confusos
• Agrupados
• Omitir informações

Técnicas
Casos de Uso
• Método estruturado
• Informações detalhadas
• Pré-condição, fluxos, pós-
condições
User Stories
• Método ágil
• Textual e objetivo
Pressman Beck

Exemplo de Caso de Uso

Exemplo de User Story
O gerente de TI cadastra novos
usuários. Pra isso ele precisa estar
logado, e entrar com o nome e
setor, e clica em "confirmar".
Cadastro de Usuários
Beck

• Modelo de Casos de Uso

• Protótipos de Telas

Validação de Requisitos
Elicitação
Análise e
Especificação
Validação
Pressman

Gerenciamento de Requisitos
Elicitação
Análise e
Especificação
Validação

Variáveis de Gerenciamento
Importância Complexidade
(Dificuldade)
Volatilidade

Matriz de Rastreabilidade
• Manter o controle sobre
a mudança
• Rastrear os impactos da
mudança

Elicitação
Análise e
Especificação
Validação

RUP
http://www.wthreex.com/rup/

Papéis
68
Analista de
Requisitos
Identificar
Requisitos
Listagem dos
Requisitos
Gerenciamento
de Requisitos
Especificador
de Requisitos
Detalhar
Requisitos
Especificação de
Casos de Uso
Gerenciamento de
Casos de Uso
Especificador
de Requisitos
Revisar
Requisitos

RUP
Exemplo de Negócio (Atendimento Bancário):

RUP
Exemplo de Negócio (Atendimento Bancário):
SUBSTANTIVOS:
• ATORES
• SETORES
• ENTIDADES
• ...

RUP

RUP
Atividades:
Fazer depósito.
Aguardar.
Ser Atendido.
Conferir Cheque.
Despachar Cheque.
Conferir Saldo da Conta.
Efetuar Transferência.
VERBOS

RUP
Casos de Uso do Negócio
Objetivo:
Desenvolver uma visão da nova organização-alvo e, com base nesta visão, definir os processos, os papéis e as
responsabilidades dessa organização em um modelo de casos de uso de negócios.
Um ator de negócio representa um
papel desempenhado em
relação ao negócio por
alguém ou algo no
ambiente do negócio.
Um caso de uso de negócios é
uma seqüência de ações
realizadas em um negócio
que produz um resultado
de valor observável
para um ator individual do negócio.

RUP
Requisitos
Objetivo:
Descrever integralmente o sistema - o que o sistema fará - em um trabalho em que todos os envolvidos, incluindo
clientes e usuários potenciais, são vistos como fontes de informações.
Casos de Uso do Sistema
e Atores do Sistema.
76

RUP
Requisitos
Lista de Requisitos
(Caixa de auto-atendimento)
R01: Identificar cliente
R02: Verificar saldo
R03: Realizar Saque
R04: Realizar Pagamento
R05: Realizar Transferência
...
77

RUP
Tipos de Requisitos
Funcionais
Correspondem as funcionalidades do sistema
Ex.
R01: Identificar cliente
R02: Verificar saldo
R03: Realizar Saque
...
Não Funcionais
Correspondem à exigências do
cliente/negócio
Ex.
R04: Disponibilidade
R05: Eficiência
R06: Facilidade de uso
...
78

UML: Diagrama de Casos de Uso
PARFOR / UFRPE

Caso de Uso
Diagramas de Casos de Uso descrevem os requisitos funcionais de um
sistema, através das interações entre o sistema (software) e todos os
outros atores do ambiente.
Responder a Pergunta: “Pra que serve esse sistema?”

Atores
Atores são representações de
entidades externas mas que
interagem com o sistema
durante sua execução.
Ex.
Pessoas (Cliente, Garçom, etc.)
Dispositivos (impressoras, etc.)
Hardware
Software (API’s)
Notação UML:

Relacionamentos entre Atores
Comunicação
Representa a comunicação
direta entre os atores do
negócio.
Os atores são entidades externas, e os
relacionamentos entre eles serão relações
externas ao sistema também.
Notação UML:

Relacionamentos entre Atores
Generalização
Funciona semelhante à
Herança, em OO.
Representa que um
determinado ator herda as
características de outro, além
de apresentar outras
características próprias.
Os atores são entidades externas, e os
relacionamentos entre eles serão relações externas
ao sistema também.
Notação UML:

Caso de Uso
Casos de uso representa os
serviços a serem oferecidos
pelo sistema. Não deve-se
confundir o conceito de “caso
de uso” com “módulo”, pois
caso de uso representa
funcionalidades atômicas (que
não podem ser divididas).
CUIDADO!!! Ao contrair o termo “Caso de Uso”. Utilize siglas
como UC (Use Case) ou CDU.
Notação UML:

Relacionamentos
Os casos de uso
representam interações
do sistema, portanto
devem estar relacionados
a um ou mais atores.
Notação UML:

Indica que um caso de uso
depende de outro.
Relacionamentos entre Casos de Uso
Dependência
Notação UML:

É uma relação onde um
caso de uso insere no seu
interior um outro caso de
uso (sub-caso de uso).
Inclusão
Notação UML:

É um relacionamento
entre dois casos de uso
através da qual um caso
de uso maior é estendido
por um caso de uso
menor.
Extensão
Notação UML:

Observações
Organização:
Cuidado ao apagar e recriar atores, para não
duplicá-los pelo projeto!
É possível criar vários diagramas, e pastas
para organizar o seu projeto! Faça bom uso
destas estruturas.

Observações
RAIA (diagrama de atividades) = ATOR (diagrama de casos de uso)?
Nem sempre!!!
Observe se os atores realmente fazem sentido para o software.
Discussão:
No caso do restaurante, o ator “Garçom” seria realmente necessário?

Engenharia de Software Aula 02

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Engenharia de Software Aula 02

Semelhante a Engenharia de Software Aula 02 (20)

Último

Último (6)

Engenharia de Software Aula 02