análise e projeto no rup. 2009mds - bacalá215/03/20052/28 contexto após a etapa de análise de...
TRANSCRIPT
Análise e Projeto no RUP
2009 MDS - Bacalá 215/03/2005 2/28
Contexto
Após a etapa de análise de requisitos, temos documentos de requisitos e os casos de uso em mãos.
Queremos agora gerar um primeiro modelo do sistema a partir dos casos de uso.
Este modelo é chamado de modelo de análise.
2009 MDS - Bacalá 315/03/2005 3/28
Contexto
Requisitos Análise Projeto
2009 MDS - Bacalá 415/03/2005 4/28
Atividade de Análise
Vai proporcionar um método que permita que criemos um modelo de classes do sistema a partir dos casos de uso
Trará a resposta para a pergunta: Quais classes preciso para implementar
estes casos de uso?
2009 MDS - Bacalá 515/03/2005 5/28
Análise & RUP
A maneira como vamos realizar a etapa de análise se baseia no processo do RUP (Rational Unified Process)
A análise será orientada a casos de uso, ou seja, os casos de uso servirão de guia para a etapa de análise
2009 MDS - Bacalá 615/03/2005 6/28
Casos de Uso X Análise
casos de uso análiseDescritos na linguagemdo cliente
Descrito na linguagemdos desenvolvedores
Visão externa dosistema
Visão interna do sistema
Captura asfuncionalidades dosistema
Mostra, de modoabstrato, como afuncionalidade pode serrealizada
Estruturado por casosde uso
Estruturado por classese pacotes
2009 MDS - Bacalá 7
Análise & Projeto
Os objetivos do fluxo:
Transformar os requisitos em um projeto do
sistema do que o sistema seráDerivar uma arquitetura robusta do sistemaAdaptar o projeto
2009 MDS - Bacalá 8
Análise versus Projeto
Foco no entendimento do problema
Projeto idealizado Comportamento Estrutura do sistema Requisitos funcionais Modelos simples
Foco no entendimento da solução
Operações e atributos Performance Pensamento no código Ciclo de vida de
objetos Requisitos não-
funcionais Modelo complexo
2009 MDS - Bacalá 9
Visão geral dos artefatos
Análise eprojeto
Modelo de análise e projeto
Documento daarquitetura
Modelo de caso de uso
Modelo de dados
Documento requisitos
Glossário
2009 MDS - Bacalá 10
Modelo de Analise e Projeto A construção do modelo de análise e
projeto é o principal objetivo desta disciplina
O modelo de análise e projeto contém as realizações de casos de uso
Pode ser particionado em dois modelos Modelo de Analise Modelo de Projeto
2009 MDS - Bacalá 11
Realização de Caso de Uso
Realização de Caso de Uso
Caso de Uso
Diagramas de ColaboraçãoDiagramas de ColaboraçãoDiagramas de Classe Diagramas de Classe
Diagramas de SequênciaDiagramas de Sequência
Descreve como o caso de uso é realizado, associando o caso de uso com classes e outros elementos de projeto
Requisitos Analise e projeto
2009 MDS - Bacalá 12
Fluxo de Análise e Projeto
Diagrama de Atividades
2009 MDS - Bacalá 13
Realizar síntese da arquitetura
2009 MDS - Bacalá 14
Objetivo
Construir e avaliar uma prova de conceito arquitetural Mostrar que existe uma solução possível
de satisfazer os requisitos do sistema relevantes à arquitetura
2009 MDS - Bacalá 15
Definir a arquitetura candidata
2009 MDS - Bacalá 16
Objetivo
Criar o esqueleto inicial da arquitetura do sistema
Identificar classes de análise dos casos de uso arquiteturalmente relevantes
Atualizar a realização de caso de uso com as interações entre classes de análise
2009 MDS - Bacalá 17
Analisar comportamento
2009 MDS - Bacalá 18
Objetivo
Transformar as descrições sobre o comportamento providas pelos caso de uso em um conjunto de elementos nos quais o modelo de projeto vai se basear
2009 MDS - Bacalá 19
Projetar componentes
2009 MDS - Bacalá 20
Objetivo
Refinar as definições dos elementos acrescentado detalhes sobre como estes elementos implementam o comportamento requerido
Refinar e atualizar as realizações de casos de uso com os novos elementos identificados
2009 MDS - Bacalá 21
Projetar Banco de Dados
2009 MDS - Bacalá 22
Objetivo
Identificar classes persistentes no modelo de projeto
Projetar as estruturas de banco de dados (Modelo de dados)
Definir mecanismos e estratégias para armazenar e recuperar dados
2009 MDS - Bacalá 23
Refinar Arquitetura
2009 MDS - Bacalá 24
Objetivo
Permitir uma transição entre os elementos e mecanismos de análise para os de projeto
Manter a consistência e integração da arquitetura
Descrever a arquitetura de execução e produção da aplicação
Fluxo de Análise e Projeto Simplificado
Simplificando/Instanciando o processo para um contexto
específico
2009 MDS - Bacalá 26
Motivação O RUP é um Framework
Genérico e complexo demais, pois visa atender todos os tipos de projetos de desenvolvimento de software
Toda disciplina do RUP deve ser analisada e customizada de acordo com as necessidades específicas do projeto antes de sua implantação
2009 MDS - Bacalá 2715/03/2005 27/28
Passos da Atividade de Análise
Identificar as classes Identificar persistência
Identificar responsabilidades das classes
Identificar relacionamentos Identificar atributos
2009 MDS - Bacalá 28
Fluxo de atividades simplificado
1. Analisar Arquitetura
2. Analisar Caso de Uso
3. Projetar Classes
4. Projetar Banco de Dados
Analisar Arquitetura
2009 MDS - Bacalá 30
Analisar Arquitetura
Esforço inicial em definir as partes do sistema e seus relacionamentos (Arquitetura Inicial)
Definir as convenções de modelagem
Identificar os mecanismos de análise
Identificação das abstrações-chave
2009 MDS - Bacalá 31
Arquitetura Inicial
Quais as principais partes do sistema? Como elas interagem entre si? Que padrões arquiteturais utilizar (no
todo ou internamente nas partes) ? MVC Baseado em camadas Canais e filtros Centrado em repositório
2009 MDS - Bacalá 32
Exemplo de arquitetura inicial
Interface Gráfica
Negócio
Dados
Módulo de Vendas
Módulo de Estoque
Socket
2009 MDS - Bacalá 33
Convenções de modelagem O que são?
Que diagramas e elementos de modelagem utilizar Definir as regras para utilização desses
componentes Convenções de nome
Exemplos Casos de uso devem ser nomeados como ações
(Cadastrar usuário) Cada realização de caso de uso deve conter:
Um diagrama de classes No mínimo um diagrama de seqüência
representando o fluxo principal de ações
2009 MDS - Bacalá 34
Mecanismos de análise O que são?
Focam nos requisitos não-funcionais do sistema Decisão estratégica sobre padrões, politicas e
práticas a serem utilizadas no projeto
Exemplos Persistência Comunicação Gerenciamento de transações Segurança
2009 MDS - Bacalá 35
Identificar Abstrações-chave
Definir classes de análise preliminares Conhecimento do domínio Requisitos Outros artefatos (Glossário e modelo de
negócio)
Analisar Caso de Uso
2009 MDS - Bacalá 37
Objetivos
Identificar as classes que executam o fluxo de eventos do caso de uso
Distribuir o comportamento do caso de uso nestas classes
Identificar atributos, responsabilidades e associações das classes
2009 MDS - Bacalá 38
Passos para Analisar Caso de Uso
Para cada caso de uso:1. Encontrar classes de análise2. Distribuir comportamento entre as
classes
Para cada classe:3. Descrever responsabilidades4. Descrever atributos e associações5. Qualificar mecanismos de análise
2009 MDS - Bacalá 39
Passo 1: Encontrar classes de análise
O comportamento do caso de uso é distribuído em classes de análise
2009 MDS - Bacalá 40
O que são classes de análise? Representam o conceito mais abstrato dos elementos
do sistema Primeiro passo concreto até chegar em um sistema
executável
Categorização temporária São convertidas para classes de projeto Servem para diminuir o gap entre os requisitos e
projeto
Podem ser dos seguintes tipos Fronteira (<<boundary>>) Controle (<<control>>) Entidade (<<entity>>)
2009 MDS - Bacalá 4115/03/2005 41/28
Classes de Fronteira
Utilizada para modelar a interação entre um ator e o sistema
Para cada interação entre um ator e caso de uso, é criada uma classe de fronteira
Possuem o estereótipo <<boundary>>
2009 MDS - Bacalá 42
Classes de Fronteira
Itermediam a interface para qualquer coisa externa ao sistema
Exemplos de classes fronteira GUI Interface com outros sistemas Interface com dispositivos
Uma classe de Fronteira por interação ator X caso de uso
<<boundary>>
Notação em UML
2009 MDS - Bacalá 43
O Papel de uma Classe de Fronteira
<<boundary>>
<<entity>>
<<control>>
<<boundary>>
<<boundary>>
<<entity>>
Usuário
Modela interação entre o sistema e seu ambiente
2009 MDS - Bacalá 44
Exemplo de classes de fronteira
Matricular-seEm disciplinaEstudante Sistema
Academico
<<boundary>>FormRegistroCursos
<<boundary>>SistemaAcademico
2009 MDS - Bacalá 4515/03/2005 45/28
Classes de Entidade
Utilizadas para modelar a informação manipulada pelo sistema
Podem ser persistentes ou não Conceito análogo às entidades dos
diagramas ER São identificadas a partir do fluxo de
eventos do caso de uso Possuem o estereótipo <<entity>>
2009 MDS - Bacalá 46
Classes de Entidade
Abstrações chave dos casos de uso
<<entity>>
Glossário
Descrição doCaso de uso
<<entity>>
<<entity>>
2009 MDS - Bacalá 47
O Papel de uma Classe de Entidade
<<boundary>>
<<entity>>
<<control>>
<<boundary>>
<<boundary>>
<<entity>>
Usuário
Armazenam e gerenciam informação no sistema
2009 MDS - Bacalá 48
Exemplo de classes de entidade
<<entity>>Estudante
<<entity>>Curso
<<entity>>Horario
2009 MDS - Bacalá 4915/03/2005 49/28
Classes de Controle
Classes responsáveis por controlar o fluxo de execução do caso de uso
Normalmente é criada uma classe de controle para cada caso de uso
Possuem o estereótipo <<control>>
2009 MDS - Bacalá 50
Classes de Controle
Coordenam o comportamento (lógica de controle) do caso de uso
Interface entre fronteira e entidade
<<control>>
2009 MDS - Bacalá 51
O Papel de uma Classe de Controle
<<boundary>>
<<entity>>
<<control>>
<<boundary>>
<<boundary>>
<<entity>>
Usuário
Coordenam o comportamento do caso de uso
2009 MDS - Bacalá 52
Exemplo de Classe de Controle
Matricular-seEm disciplinaEstudante Sistema
Academico
<<control>>ControladorMatricula
matricurlarAluno()
2009 MDS - Bacalá 5315/03/2005 53/28
registrar faltas
registrar súmulasdas aulas
Professor
consultar freqüência
Aluno
editar alunos remover alunos
adicionar turma
remover turma
editar turma
Servidor de e-mailadicionar alunos
Secretária
Usuarioefetuar login
Exemplo
2009 MDS - Bacalá 5415/03/2005 54/28
Exemplo
Efetuar Login Fluxo de eventos:1. Usuário informa login e senha2. Sistema checa se o login e senha
conferem3. Sistema registra a sessão do aluno e
a tela principal do sistema é exibida
2009 MDS - Bacalá 5515/03/2005 55/28
Exemplo
Que classes preciso criar? uma classe de fronteira para lidar com a
interação dos atores com o sistema uma classe de entidade para representar
as informações relevantes do aluno uma classe de controle para gerenciar o
fluxo de execução do caso de uso
2009 MDS - Bacalá 5615/03/2005 56/28
Exemplo
ControladorLogin UsuarioTelaLogin
ControladorLogin<<control>>
Usuario<<entity>>
TelaLogin<<boundary>>
Há diferentes opções de visualização dos estereótipos. A opção padrão é mostrada acima - os estereótipos são visualizados através da mudança dos ícones das classes. Há também a opção de se visualizar os estereótipos do modo convencional (<<estereótipo>>).
2009 MDS - Bacalá 5715/03/2005 57/28
Persistência
Mas caso alguma classe de entidade precise ser persistente?
Que classe será responsável por realizar as tarefas de persistência?
Para cada classe de entidade que precise ser persistente, é criada uma nova classe com o estereótipo <<entity collection>>
2009 MDS - Bacalá 5815/03/2005 58/28
Exemplo
TelaLogin<<boundary>>
CadastroUsuarios<<entity collection>>
ControladorLogin<<control>>
Usuario<<entity>>
2009 MDS - Bacalá 59
Passo 2: Distribuir comportamento
Para cada fluxo de eventos Identificar classes de análise
participantes Alocar responsabilidades do caso de uso
às classes de análise Modelar interações entre as classes
através dos diagramas de interação
2009 MDS - Bacalá 60
Distribuindo comportamento entre as classes
Caso de uso
Diagrama de seqüência Diagrama de colaboração
Classes de análise
Classes de análise com responsabilidades
2009 MDS - Bacalá 61
Alocando responsabilidades Use estereótipos de análise como guia
Classes de fronteira Comportamento que envolve comunicação com
um ator Classes de entidade
Comportamento que envolve informação encapsulada na abstração
Classes de controle Comportamento específico ao (lógica de
controle do) caso de uso
2009 MDS - Bacalá 62
Guia: Alocando responsabilidades
Quem tem a informação necessária para realizar a responsabilidade isso pode envolver apenas uma classe,
mas pode ser preciso criar novas classes ou relacionamentos entre classes
2009 MDS - Bacalá 63
Modelando interações Diagramas de interação (colaboração e
seqüência) modelam interações do sistema com seus atores
A interação é iniciada por um ator e envolve instâncias (objetos) das classes
Diagramas de interação capturam a semântica do fluxo de eventos do caso de uso Auxiliam a identificar classes, responsabilidades
e relacionamentos Mecanismo de validação da arquitetura
2009 MDS - Bacalá 64
Vários diagramas podem ser necessários
2009 MDS - Bacalá 65
Anatomia de um Diagrama de Seqüência
:Cliente :Fornecedor
Objetos
Linha da vida 1: Solicita serviço
1.1: Solicita outro serviço
Mensagemreflexiva
Foco docontrole Numeração
hierárquica
Mensagem
66MDS - Bacalá2009
Exemplo de diagrama de Seqüência
: Alunojanela de
matrículacontrole de
matrículamat 101
1: preenche info
2: submete
3: ad curso(Jose, mat 101)
4: ad(Jose)
5: curso aberto?
6: ad(Jose)
mat 101 section 1
2009 MDS - Bacalá 67
Diagrama de Colaboração
:Cliente :Fornecedor
Objetos
Mensagem
1: Solicita serviço
Ligação
68MDS - Bacalá2009
Exemplo de diagrama de colaboração
: Secretaria
janela de curso :
JanelaCurso
gerenciador :
GerenciadorCurriculo
curso :
Curso
1: informação do curso
2: processa
3: adiciona curso
4: novo curso
2009 MDS - Bacalá 6915/03/2005 69/28
Exemplo
: usuário : TelaLogin : ControladorLogin : CadastroAlunos
efetuarLogin(login, senha)
efetuarLogin(login, senha)
checar(login, senha)
registrarSessao()
2009 MDS - Bacalá 70
Colaboração X Sequência Colaboração
Mostra os relacionamentos, além das interações
Melhor para visualizar a colaboração
Melhor de ser usado em reuniões
Sequência Mostra a sequência
explicíta de mensagens
Melhor para visualizar o fluxo
Melhor para cenários complexos
2009 MDS - Bacalá 71
Passo 3: Descrever Responsabilidades
Atualizar os diagramas de classes com as responsabilidades identificadas no de iteração
Mensagens nestes diagramas resultam em responsabilidades nas classes receptoras
2009 MDS - Bacalá 72
Como fazer?
:Cliente :Fornecedor
// Executar responsabilidade
Fornecedor
// Executar responsabilidade
diagrama de classe
diagrama de interação
2009 MDS - Bacalá 7315/03/2005 73/28
Classes com métodos
TelaLogin
efetuarLogin(login, senha)
<<boundary>>
CadastroUsuarios
checar(login, senha)
<<entity collection>>
ControladorLogin
efetuarLogin(login, senha)registrarSessao()
<<control>>
Usuario<<entity>>
2009 MDS - Bacalá 74
Passo 4: Descrever atributos e associações
Definir atributos
Estabelecer agregações e associações
2009 MDS - Bacalá 7515/03/2005 75/28
Identificando Atributos Também é necessário identificar
quais os atributos das classes Um bom conhecimento do domínio do
problema é bastante importante para esta tarefa, principalmente na identificação de atributos das classes de entidade
Nesta etapa ainda não precisamos indicar quais os tipos dos atributos
2009 MDS - Bacalá 76
Encontrando Atributos Possíveis fontes: conhecimento do negócio,
requisitos, glossário, modelo do negócio, etc.
São propriedades/características das classes identificadas informação de propriedade exclusiva do objeto informação que pode ser lida ou escrita por
operações, mas sem outro comportamento a não ser fornecer um valor
Se a informação tem comportamento complexo ou é compartilhada, deve gerar uma classe
2009 MDS - Bacalá 7715/03/2005 77/28
Identificando relacionamentos As classes identificadas não
funcionam isoladamente, elas se relacionam com as demais classes
Os diagramas de interação são muito úteis nesta tarefa
Para cada ligação presente nos diagramas de interação, é necessário um relacionamento no diagrama de classes
2009 MDS - Bacalá 78
Encontrando Relacionamentos
Interações entre objetos nos diagrama de interação pode indicar a necessidade de definir um relacionamento entre as classes
Adicionar os elementos de um relacionamento Tipo e nome Navegabilidade Multiplicidade Papéis
2009 MDS - Bacalá 79
Encontrando Relacionamentos
:Client :Supplier
Link
Supplier
PerformResponsibility()
Diagramade classe
Diagrama deColaboração
Association
Client Supplier
Client
1: PerformResponsibility
Prime suppliers
0..* 0..*
2009 MDS - Bacalá 8015/03/2005 80/28
Diagrama final
Usuario
loginsenha
<<entity>>
TelaLogin
efetuarLogin(login, senha)
<<boundary>>ControladorLogin
efetuarLogin(login, senha)registrarSessao()
<<control>>
1*
CadastroUsuarios
checar(login, senha)
<<entity collection>> 1
1
* 1
1
1
2009 MDS - Bacalá 81
Gerenciando a consistência Classes com responsabilidades similares
são candidatas a serem combinadas
Uma classe com responsabilidades disjuntas é candidata a ser dividida
Classes sem (ou com apenas uma responsabilidade) e classes que interagem com muitas classes são candidatas a serem reexaminadas
2009 MDS - Bacalá 82
Passo 5: Qualificar mecanismos de análise
Mapear classes de análise em mecanismos de análise
Classes de análise Mecanismos de análise
Estudante Persistente
ControladorMatricula Distribuição, Segurança
Curso Persistente, Interface Legado
2009 MDS - Bacalá 83
Passo 6: Unificar classes de análise
Realização de Caso de Uso
Diagramas de Classe Diagramas de Classe
…
Realização de Caso de Uso
Diagramas de Classe Diagramas de Classe
…
Realização de Caso de Uso
Diagramas de Classe Diagramas de Classe
…
Diagramas de Classe Diagramas de Classe
Projetar classes
2009 MDS - Bacalá 85
Objetivo Detalhar as partes do sistema Concretização dos conceitos definidos
até o momento Detalhes de implementação e ambiente
de produção Produtos utilizados Linguagem de programação Distribuição Performance Restrições físicas
2009 MDS - Bacalá 86
Passos do projeto de classes
1. Criar classes de projeto2. Identificar classes persistentes3. Definir métodos4. Definir atributos5. Definir estados6. Definir relacionamentos7. Contemplar os requisitos não-funcionais
Para cada classe:
2009 MDS - Bacalá 87
Passo 1: Criar classes de projeto Converter classes de análise
(Fronteira, Controle e Entidade) em classes de projeto
Padrões de projeto podem ser incorporados
As classes são refinadas para incorporar os mecanismos arquiteturais
2009 MDS - Bacalá 88
Projetando classes de fronteira GUI (Graphical User Interface)
Que ferramenta de desenvolvimento de interface gráfica será utilizada?
Quant pode ser criada pela ferramenta? Que padrões serão utilizados?
Sistemas Externos Que tecnologias/mecanismos de integração? Que padrões? Projetar como um subsistema…
2009 MDS - Bacalá 89
Projetando classes de entidade
Classes de Entidade são Transitórias Persistentes
São detalhadas no passo “Identificar classes persistentes”
2009 MDS - Bacalá 90
Projetando classes de controle
Decisões que deve ser tomadas: Elas são realmente necessárias? Elas podem/devem ser agrupadas?
Como decidir? Complexidade Operações relacionadas Probabilidade de mudar Performance e distribuição
2009 MDS - Bacalá 91
Passo 2: Identificando classes persistentes Instancias da classe precisam preservar o
seu estado Estratégia de persistencia é definida para
cada classe persistente
Curso BD Relacional
Candidato Arquivo
JDBC
Serialização
2009 MDS - Bacalá 92
Passo 3: Definir Métodos
Tem como propósito mapear responsabilidades identificada na análise para métodos na classe
Deve-se considerar Nome, assinatura e visibilidade dos
métodos
2009 MDS - Bacalá 93
:Fornecedor
Mapeando operações
:Cliente
// Realizar alguma operação
:Fornecedor:Cliente
fazerAlgo()
Projeto
Análise
+ concreto
- concreto
2009 MDS - Bacalá 94
Passo 4: Definir Atributos
Tem como propósito formalizar a definição dos atributos
Deve-se considerar Persistência Visibidade, nome, tipo e valor inicial
2009 MDS - Bacalá 95
Passo 5: Definir estado
Tem como objetivo definir como o objeto se comporta
Relevante apenas para objetos com ciclo de vida complexo
Pode ser especificado em UML Diagrama de estados Diagrama de atividades
2009 MDS - Bacalá 96
Diagrama de Estados
Um diagrama de estados mostra o ciclo de vida de um objeto
Nome do estado
Variavel: Tipo = valor
Ação de entradaAção de saídaAtividade
Evento(args)[condição]/ Operacao(args)^obj.enviarMensagem(args)Estado
Ações
Atividades Transição
2009 MDS - Bacalá 97
Exemplo de diagrama de estado
InicializadoAberto
Fechado
Cancelado
do: Incializa Curso
do: Finaliza curso
do: Notifica Alunos
Adiciona Aluno /contador = 0
Adiciona Aluno[ contador < 10 ]
[ contador = 10 ]
Cancela
Cancela
Cancela
2009 MDS - Bacalá 98
Passo 6: Definir Relacionamentos
Dependências Associações
Simples Agregação Composição
Generalização
2009 MDS - Bacalá 99
Passo 7: Contemplar os requisitos não-funcionais Concretização dos mecanismos de análise
Incorporar responsabilidades em algumas classes Criar novas classes
Exemplos: Segurança Como armazenar as senhas? Que
algoritmo usar para criptografar uma mensagem? Distribuição Que tecnologia utilizar? Qual o
impacto da tecnologia nos objetos já definidos? Tratamento de logs Que tipo de operações
deve ter log (Acesso a dados, execução de negócio, …)
2009 MDS - Bacalá 100
Projetar Banco de Dados
Mapear as classes persistentes em conceitos do Banco de Dados
Definir os tipos de dados mais adequados para o BD
Normalizar se necessário