Buscar

Processo Unificado (1)

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

*
*
*
*
Desenvolver um sistema de controle de vendedores ambulantes de um empresa. A empresa dividiu cada cidade em que atua em regiões. Cada região é controlada por um supervisor ao qual está subordinado um certo número de vendedores. 
A empresa possui diversos pontos distribuídos na cidade. Todo dia os vendedores passam pela empresa, de manhã, e registram, em um boletim de controle, a hora da partida, o roteiro de visitas planejado e o número de contratos de vendas que levaram. Ao final da tarde, cada vendedor passa por um pontos, e registra o resultado das atividades do dia, ou seja, os contratos de venda fechados.
Até as 20 horas, todos vendedores devem ter registrados suas produções do dia. Cada ponto da empresa, processa a esta hora, um resumo das atividades registradas e o remete para a central da empresa. 
No outro dia o supervisor analisa os boletins recebidos e passa-os, com alguns comentários, ao controle geral de vendas da empresa.
O supervisor, além de controlar a produção dos vendedores, registra o recebimento de novos vendedores e a liberação deles para o departamento pessoal que, por sua vez, controla a contratação, alocação, relocação e demissão de vendedores e supervisores.
*
*
ARTEFATOS
 Modelo Use-Case 
 ator 
 Use-Case 
 descrição da arquitetura 
*
*
Profissionais 
 Analista de sistemas
 arquiteto 
 Especificador de Use-Case 
 projetista de interfaces 
*
*
PASSOS
 listar requisitos 
 entender o contexto do sistema 
 capturar requisitos funcionais 
 capturar requisitos não-funcionais 
*
*
 listar requisitos 
Resultado:Lista de características obtidas de clientes,
	usuários, analistas e desenvolvedores
PARA CADA REQUISITO:
 nome
 breve descrição ou definição
 conjunto de valores
 Estado (proposto, aprovado, incorporado, validado)
estimativa de custos
prioridade (crítica, importante ou secundária)
 riscos (crítico, significante, ordinário)
*
*
 entender o contexto do sistema 
 criar um modelo do domínio 
 objetos de negócio (pedidos, contas, contratos,..)
 objetos do mundo real (veículos, máquinas, trajetos,..)
 eventos básicos (chegada de um pedido, partida de um transporte, ..)
 
 usar diagramas UML, em particular diagramas de classe
*
*
 capturar requisitos funcionais 
ARTÍFICE
ARTEFATO
Analista de Sistemas
Especificador de Use-Cases
Projetista de Interfaces
Arquiteto
Modelo use-case
atores
glossários
Protótipos de interfaces
Use-cases
Arquitetura
responsável
*
*
 capturar requisitos funcionais 
ATIVIDADES E SUBPASSOS
 A1) encontrar os atores e use-cases
 encontrar os atores
 encontrar e descrever cada use-case
 descrever o Modelo Use-Case como um todo
 A2) Priorizar Use-Cases (visão arquitetural)
*
*
 capturar requisitos funcionais 
ATIVIDADES E SUBPASSOS
 A3) Detalhar cada Use-Case
 estruturar a descrição do use-case (construir um diagrama de estados e analisar cada caminho) 
 formalizar a descrição do use-case (usar diagramas de estado, diagramas de atividade ou diagramas de interação) 
 descrever o Modelo Use-Case como um todo
*
*
 capturar requisitos funcionais 
ATIVIDADES E SUBPASSOS
 A4) Prototipar as interfaces com o usuário
 projeto lógico da interface do usuário
 projeto físico da interface do usuário e protótipo
*
*
PROJETO LÓGICO: para cada ator, ver todos use-cases nos 
 quais está envolvido e especificar os elementos de interação 
 (ícones, listas, campos, figuras, etc.)
N.B. a mesma interface (formulário) pode aparecer em diversos
 use-cases para diversos atores!
QUESTÕES para determinar os elementos de interação:
 quais informações o ator fornece ao sistema?
 quais informações o ator necessita do sistema?
 com quais elementos de interação o ator trabalha?
 quais ações o ator pode acionar e quais decisões tomar?
Quais classes de domínio ou entidades de negócio estão envolvidos com elementos de interação?
*
*
PROJETO FÍSICO:
 combinar elementos de interação para formar interfaces que atendam a atores
 
 determinar elementos adicionais (folders, janelas, controles, etc.)
 desenvolver um protótipo para cada interface
*
*
 capturar requisitos funcionais 
ATIVIDADES E SUBPASSOS
 A5) Estruturar o modelo Use-Case
 identificar funcionalidades comuns (generalizações, <<estende>>)
 identificar funcionalidades adicionais ou opcionais
 identificar outros relacionamentos entre use-cases (<<inclui>>, inverso de <<estende>>)
*
*
 capturar requisitos não-funcionais 
ATIVIDADES
 usabilidade
requisitos de interfaces metáfora, frequência de uso, ..
 documentação
 confiabilidade
 tolerância a falhas. 
*
*
 capturar requisitos não-funcionais 
ATIVIDADES
 performance
 tempos de resposta
 volumes de transações
 requisitos físicos
 equipamentos, material, espaços, configurações de rede,
 software
*
*
*
*
Os requisitos externos são transformados em um modelo interno
 preciso e completo para desenvolver o projeto do sistema
*
*
2. CLASSE DE ANÁLISE
Classe de
fronteira
Classe de
controle
Classe de
entidades
EXEMPLO
Interface de
registro
processar
resumo do dia
Boletim de
controle
1. MODELO DA
 ANÁLISE
*
*
3. REALIZAÇÃO DE UM USE-CASE
 Diagramas de classe
Diagramas de colaboração
Resultado
do dia
Processar
resumo
boletim 
de controle
VENDEDOR
partida
Resumo do dia
SUPERVISOR
mostra
resumos
1.registra partida
3. registra retorno
2. abre boletim
3. completa boletim
5. dados boletim
6. Registra resumo
8. analisa resumo
9. comentários
7. mostra resumo
10. resumo
comentado
RELOGIO
4. 8 horas
*
*
3. REALIZAÇÃO DE UM USE-CASE (cont.)
 requisitos especiais
 fluxo de eventos
Descrição textual de requisitos não-funcionais
Descrição textual do diagrama de colaboração
4. PACOTES DE ANÁLISE
PACOTE DE SERVIÇOS
Devem ter coesão e fraco acoplamento
Candidatos a subsistemas do projeto
é um conjunto de ações coerentes, indivisíveis para uso
em vários use-cases
5. DESCRIÇÃO DA ARQUITETURA
*
*
 arquiteto 
 Especificador de Use-Case 
 Especificador de componentes 
ARTÍFICES
 responsável pela integridade global do modelo de análise (corretude, consistência e legibilidade), tanto pela sua funcionalidade quanto pela arquitetura
 responsável que a realização de um use-case corresponde a sua especificação
 responsável pelas classe de análise e pelos pacotes
*
*
PASSOS
 Análise arquitetural 
 Análise de cada Use-Case 
 Análise de cada classe 
 Análise de cada pacote 
*
*
 Análise arquitetural 
Análise 
arquitetural
MODELO
USE-CASE
REQUISITOS 
ADICIONAIS
MODELO
DO DOMÍNIO
DESCRIÇÃO
ARQUITETURA
(mod. Requisitos)
ARQUITETO
DESCRIÇÃO
ARQUITETURA
(mod. Análise)
CLASSE 
DE ANÁLISE
(esboço)
PACOTE
ANÁLISE
(esboço)
*
*
 Análise arquitetural 
ATIVIDADES E SUBPASSOS
 A1) Identificar pacotes de análise 
 Encontrar pacotes coesos e fracamente acoplados
 Identificar funcionalidades comuns entre pacotes (pacotes genéricos)
 Identificar pacotes de serviço (serviços opcionais, classes relacionadas funcionalmente)
 Dependências entre pacotes 
*
*
 Análise arquitetural (cont.) 
A2) Identificar classes de entidades óbvias Obtidas a partir das classe do domínio
A3) Identificar requisitos especiais comuns
 Persistência
 Distribuição e concorrência
aspectos de segurança
 tolerância a falhas
 gerência de transações
*
*
 Análise de cada Use-Case 
 encontrar as classe de análise para realizar o use-case
 distribuir o comportamento do use-case entre as classes
 identificar requisitos especiais
Análise de um 
Use-Case
MODELO
USE-CASE
REQUISITOS 
ADICIONAIS
MODELO
DO DOMÍNIO
DESCRIÇÃO
ARQUITETURA
(mod Análise)
ESPECIFICADOR
DE USE-CASES
CLASSE 
DE ANÁLISE
(esboço)
REALIZAÇÃO
DE UM USE-CASE
(diagramas de classes
e de colaboração)
*
*
 Análise de cada Use-Case 
 A1) Identificar classes de análise 
 encontrar classes de entidades para armazenar as informações do use-case
 para cada ator humano, determinar uma classe de fronteira central (representa a janela principal)
 determinar as classe de fronteira que interagem com as classes de entidade
 determinar, pelo menos, uma classe
de controle que coordena o use-case
CONSTRUIR UM DIAGRAMA DE CLASSES
*
*
 Análise de cada Use-Case (cont.) 
 A2) Descrever interações entre objetos
 construir um diagrama de colaboração
 toda classe de análise deve participar de algum diagrama de colaboração
 dar maior ênfase às conexões e condições do que à sequência
 às conexões de mensagens podem corresponder associações do diagrama de objetos ou não
 considerar as relações entre use-cases no diagrama
 A3) Determinar requisitos especiais
*
*
Resultado
do dia
Processar
resumo
boletim 
de controle
VENDEDOR
partida
Resumo do dia
mostra
resumos
1.registra partida
3. registra retorno
2. abre boletim
4. completa boletim
6. dados boletim
7. Registra resumo
9. analisa resumo
10. comentários
8. mostra resumo
11. resumo
comentado
5. 8 horas
RELÓGIO
SUPERVISOR
 Análise de cada Use-Case (cont.) 
*
*
 Análise de cada classe 
 identificar as responsabilidades de cada classe, baseado em sua função na realização de use-cases
 definir os atributos e relacionamentos
 capturar requisitos especiais para cada classe
Análise 
de uma classe
REALIZAÇÃO
DE UM USE-CASE
(diagramas de classes
e de colaboração)
ESPECIFICADOR
DE COMPONENTES
CLASSE 
DE ANÁLISE
(completa)
CLASSE 
DE ANÁLISE
(esboço)
*
*
 Análise de cada classe 
 A3) Identificar associações e agregações
 A2) Definir os atributos
 tipos de atributos são conceituais
 classes com muitos atributos podem ser divididas
 atributos de classes de fronteira são campos em interfaces
classes de controle geralmente não tem atributos
 A1) Identificar responsabilidades 
 Determinar os papéis de cada classe nos diferentes use-cases
 A4) Identificar generalizações
 A5) Determinar requisitos especiais
*
*
 Análise de cada pacote 
 Rever as dependências entre pacotes de acordo com associações estáticas ou dinâmicas entre as classes, criadas nos passos anteriores
 Garantir que cada pacote preenche sua função
 Rever as questões de acoplamento fraco e coesão
*
*
 adquirir uma compreensão de aspectos de requisitos não funcionais e restrições sobre linguagens de programação, sistemas operacionais, SGBDs, aspectos de distribuição, etc. .
 Criar informações suficientes para a implementação, descre- vendo subsistemas, interfaces e classes. 
 Estar apto a dividir a tarefa de implementação em equipes 
 Determinar mais cedo as interfaces entre os subsistemas 
 Criar um modelo que possibilite uma implementação que preencha as estruturas definidas sem altera-las 
OBJETIVOS
*
*
MODELO DE ANÁLISE
MODELO DE PROJETO
conceitual
físico
Genérico (c.r. projeto)
específico
3 tipos de classes
Depende da implementação
Menos formal
Mais formal
Mais rápido (1/5 do projeto
Mais demorado (5 x análise)
Poucos níveis
Muitos níveis
Menos dinamica
Mais dinâmica, foco na sequencia
Não se mantém no ciclo
Se manté em todo ciclo
*
*
1. MODELO DE PROJETO
É uma hierarquia de subsistemas contendo 
classe de projeto, projetos de use-cases e interfaces
2. CLASSE DE PROJETO
 na linguagem de programação da implementação
 visibilidade dos atributos (ex. publico, protegido, privado)
 generalizações  herança; 
 associações e agregações  atributos
 métodos em pseudo-código
*
*
3. REALIZAÇÃO DO USE-CASE
 Diagrama de classes 
 Diagrama de interações (diagramas de sequência) 
 Fluxo de eventos (textual) 
 Requisitos de implementação
*
*
7. MODELO DE DISTRIBUIÇÃO (Diagrama de nós e conexões)
5. INTERFACE (separa funcionalidade de implementação)
6. ARQUITETURA (VISÃO DO PROJETO) (1. Subsistemas, interfaces e dependências 2. Classes chave, classes ativas 3. Realização de use-cases centrais ao sistema
4. SUBSISTEMA DE PROJETO (pacotes de análise, componentes, produtos de software, sistemas existentes) - SUBSISTEMAS DE SERVIÇO
8. ARQUITETURA (VISÃO DO MODELO DE DISTRIBUIÇÃO)
*
*
 Arquiteto 
 Especificador de use-cases 
 Especificador de componentes 
MODELO DO PROJETO
ARQUITETURA
MODELO DE DISTRIBUIÇÃO
REALIZAÇÃO DE USE CASE
CLASSE DE PROJETO
SUBSISTEMA
INTERFACE
*
*
Projeto de
um use-case
Projeto de 
uma classe
Projeto de
um subsistema
Projeto da
arquitetura
ARQUITETO
ESPECIFICADOR
DE COMPONENTES
ESPECIFICADOR
DE USE-CASES
*
*
 Projeto da arquitetura
 A1) Identificar nós e configurações de rede 
 determinar os nós envolvidos e suas características 
 determinar os tipos de conexões entre os nós 
 verificar necessidades de processamentos redundantes, backups, etc.
*
*
 Projeto da arquitetura (cont.)
 A2) Identificar subsistemas e suas interfaces
 subsistemas da aplicação
 identificar middleware (SO, SGBD, software de comunicação, pacotes GUI, distribuição, etc.)
 definir dependências entre os subsistemas
 identificar as interfaces entre os subsistemas
Pacote (análise)
Subsistema novo
Software existente
Não serve como subsistema
É integrado com sistemas existentes
*
*
 Projeto da arquitetura (cont.)
 A3) Identificar classes de projeto significativas 
 a partir das classes de análise 
 classes ativas (requisitos de concorrência, performance, inicialização, distribuição, prevenção de deadlocks) 
 A4) outros requisitos de projeto (persistência, transparência de distribuição, segurança, recuperação de erros, gerência de transações) 
*
*
 Projeto de um use-case
 A1) Identificar classes de projeto participantes 
 estudar as classes de análise
 identificar classes que realizam os requisitos especiais da análise
 definir as classes de projeto e passar para o projetista de componentes
OBJETIVO:
 identificar classes de projeto
 distribuir o comportamento entre os objetos
 definir requisitos das operações
 requisitos de implementação do use-case
*
*
 Projeto de um use-case (cont.)
 A2) Descrever a interação entre objetos 
 o use-case é acionado por uma mensagem de um ator a um objeto
 traçar um ou vários diagramas de sequência
 utilize nomes e textos (fluxo de eventos) para descrever as sequências
 considere as associações entre use-cases no diagrama de sequência
*
*
 Projeto de um use-case (cont.)
 A3) Identificar subsistemas e interfaces 
 identificar os subsistemas obtidos a partir de pacotes deste use-case
 verifique se há classes de projeto especiais e seus subsistemas
 A4) Descrever a interação entre subsistemas 
 a partir dos caminhos no diagrama se sequência determinar a interação
 determinar qual interfaces é utilizada por qual mensagem 
*
*
 Projeto de uma classe
 A1) Definir uma classe de projeto 
 a partir de classes de fronteira : depende da linguagem
 classes de entidades persistentes podem produzir tabelas relacionais 
 classes de controle podem gerar várias classes de projeto (distribuição) ou serem encapsuladas em classes de entidades
ASPECTOS:
 atributos
 operações e sua realização
 relacionamentos
 estados
 dependências
 interfaces
 requisitos de implementação
*
*
 Projeto de uma classe (cont.)
 A2) Definir operações
 realizar as responsabilidades da classe
 requisitos especiais (e.g. acesso ao banco de dados)
 atender às necessidades das interfaces da classe
 A3) Definir atributos
 considerar os atributos da análise
 os tipos dos atributos são determinados pela linguagem de programação
 valores de atributos usados por vários objetos devem ser transformados em objetos
*
*
 Projeto de uma classe (cont.)
 A4) Identificar associações e agregações
 dependendo da linguagem, transformá-los em relacionamentos
 tentar transformar cardinalidades, papéis, etc. em atributos ou em novas classes para realizar a associação
 analise a navegabilidade pelas associações
 A5) Identificar generalizações
 A6) Descrever métodos
 realização de operações por pseudo-código, diagramas de atividades, linguagem natural,..
 A7) Descrever estados
 diagrama de estados
*
*
 Projeto de um subsistema
 A1) Rever as dependências entre subsistemas
 
 A2) Rever as interfaces
 
 A3) Rever o conteúdo
*
*
1. MODELO DA IMPLEMENTAÇÃO
2. COMPONENTE
3. SUBSISTEMA
DE IMPLEMENTAÇÃO
4. INTERFACE
5. ARQUITETURA (visão da implementação)
6. PLANO DE INTEGRAÇÃO
*
*
1. MODELO DA IMPLEMENTAÇÃO
É uma hierarquia de subsistemas de implementação
 contendo componentes e interfaces
2. COMPONENTE
 <<executable>> (programa executável)
 <<file>> (arquivo contendo código fonte ou dados)
 <<library>> (biblioteca estática ou dinâmica) 
 <<table>> (tabela do banco de dados)
 <<document>> (um documento)
É UM PACOTE CONTENDO ELEMENTOS DO PROJETO
Estereótipos:
*
*
2. COMPONENTE - exemplos
<<executable>>
ProcessaBoletim.java
<<table>>
Resumo
BOLETIM
__________
__________
RESUMO
__________
__________
<<table>>
Contrato
realiza
realiza
gera
gera
*
*
3. SUBSISTEMAS DE IMPLEMENTAÇÃO
 um package em Java
um project em Visual Basic
um diretório de C++
CORRESPONDÊNCIA 1-1 COM SUBSISTEMAS DE PROJETO
4. INTERFACES
Implementam as interfaces do projeto
*
*
5. ARQUITETURA (visão da implementação)
6. PLANO DE INTEGRAÇÃO
Decomposição em subsistemas, compostos de interfaces e componentes 
Componentes chave
 Primeira versão executável
 testes localizados de integração para facilitar a detecção de erros
 versão final
*
*
 Arquiteto 
 Integrador do sistema 
 Engenheiro de componentes 
MODELO DA IMPLEMENTAÇÃO
DESCRIÇÃO DA ARQUITETURA
MODELO DE DISTRIBUIÇÃO
PLANO DE INTEGRAÇÃO
COMPONENTE
SUBSISTEMA DE 
IMPLEMENTAÇÃO
INTERFACE
*
*
*
*
PASSOS
 Implementação arquitetural 
 Integrar sistemas 
 Implementar subsistema 
 Testar componentes 
 Implementar uma classe 
*
*
Integrar
sistemas
Implementar
uma classe
Implementar
um subsistema
Implementação
arquitetural
ARQUITETO
ENGENHEIRO DE 
COMPONENTES
INTEGRADOR 
DE SISTEMAS
Teste de
unidade
*
*
 Implementação arquitetural 
 identificar componentes significativos
 Integrar sistemas 
 determinar sequência de construção
 integrar construções (compilar e linkar novos componentes)
*
*
 Implementar subsistema
 garantir conteúdo do subsistema
 Implementar uma classe 
 implementar métodos
 determinar operações/métodos auxiliares
*
*
Teste
OBJETIVOS
 Planejar os testes em cada iteração, tanto os 	 testes de integração quanto os testes de sistema
 preparar casos de teste, criar procedimentos de teste e 	procedimentos executáveis
 Realizar os testes e analisar os resultados
*
*
Teste - artefatos
1. MODELO DE TESTE
 Planejar os testes em cada iteração, tanto os 	os testes de integração quanto os testes de sistema
 preparar casos de teste, criar procedimentos de teste e 	procedimentos executáveis
 Realizar os testes e analisar os resultados
2. CASO DE TESTE
*
*
Fases X Etapas 
Fases
Concepção
Elaboração
Construção
Transição
Requisitos
Análise
Projeto
Implementação
Testes
Iter.
#1
Iter.
#2
_
_
_
_
_
Iter.
#n-1
Iter.
#n
*
*
As quatro Fases
 Fase de Concepção
 estabelece o business case (prioridade de negócio)
 Delimitar o escopo do sistema
 Determinar arquitetura candidata (elementos novos, arriscados)
 Identificar riscos críticos
 Identificar potenciais usuários ou clientes do sistema
Passos
*
*
As quatro Fases
 Fase de Elaboração
 determina uma arquitetura estável
 Determinar linha base da arquitetura cobrindo funcionalidades 	significantes
 Identificar riscos críticos que podem derrubar planos, orçamentos, 	e prazos
 Determinar níveis de qualidade (confiabilidade, tempos de resposta)
 Definir use-cases que cobrem ca. de 80% da funcionalidade do 	sistema
 Determinar limites de pessoal, custos, prazos.
Passos
*
*
As quatro Fases
 Fase de Construção
 determina capacidades operacionais iniciais
 Estender o modelo de use-cases para toda a aplicação
 Finalizar a análise, projeto, implementação e testes
 Checar integridade da arquitetura (com possíveis alterações)
 Monitorar ricos críticos
Passos
*
*
As quatro Fases
 Fase de transição
 transforma versão beta em um sistema operacional
 Preparar atividades de transição
 Avisar clientes sobre mudanças no ambiente (hardware, software, 	distribuição, ..)
 Preparar documentação final
 Carregar o novo sistema
 Corrigir possíveis defeitos detectados no beta-teste
Passos
*
*
Iterativo e incremental
 Uma ITERAÇÃO genérica é composta pelas 5 etapas: Requisitos, Análise, Projeto, Implementação e Testes
Após cada iteração ou cada fase:
 planejar a próxima iteração à luz da experiência anterior
 modificar o processo, adaptar ferramentas, treinamento, etc.
*
*
Iterativo e incremental
requisitos
análise
projeto
Implement.
testes
planejamento
consolidação
ITERAÇÃO
*
*
Iterativo e incremental
Planejando as
ITERAÇÕES
Planejando as FASES
 tempos por fase
 milestones
 iterações por fase
 plano do projeto
 cronograma
 conteúdo: - quais use-cases serão realizados - iterações anteriores e posteriores
*
*
Riscos
Possíveis riscos:
Gerenciar uma
lista de riscos:
 descrição
 prioridade (crítico, signifcante, rotineiro)
 impacto
 responsabilidades
 contingência (o que fazer?)
 relacionados a um produto
 não conseguir a arquitetura
 não realizar os requisitos
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*

Teste o Premium para desbloquear

Aproveite todos os benefícios por 3 dias sem pagar! 😉
Já tem cadastro?

Outros materiais