Análise e Projeto no RUPbacala/AS2/03-AnáliseProjetoOO.pdf• O RUP é um Framework • Genérico...
101
Análise e Projeto no RUP
Transcript of Análise e Projeto no RUPbacala/AS2/03-AnáliseProjetoOO.pdf• O RUP é um Framework • Genérico...
Análise e Projeto no RUP
2017
2
Contexto • Após a 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 (requisitos funcionais).
• Este modelo é chamado de modelo de análise.
• Analisando os requisitos não funcionais, é feita escolha da Arquitetura a ser usada;
• Definida a arquitetura, geramos um modelo de projeto a ser implementado.
2/28
2017
3
Contexto
3/28
Requisitos Análise Projeto
Arquitetura
2017
4
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?
4/28
2017
5
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
2017
6
Casos de Uso X Análise
casos de uso análise
Descritos na linguagemdo cliente
Descrito na linguagemdos desenvolvedores
Visão externa dosistema
Visão interna do sistema
Captura as
funcionalidades dosistema
Mostra, de modo
abstrato, como afuncionalidade pode serrealizada
Estruturado por casosde uso
Estruturado por classese pacotes
Análise & Projeto
2017
7
Os objetivos do fluxo:
Transformar os requisitos em um projeto do
sistema do que o sistema será
Derivar uma arquitetura robusta do sistema
Adaptar o projeto
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
2017
8
Visão geral dos artefatos
2017
9
Análise e
projeto
Modelo de análise e projeto
Documento da arquitetura
Modelo de caso de uso
Modelo de dados
Documento requisitos
Glossário
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
2017
10
Realização de Caso de Uso
2017
11
Realização de Caso
de Uso
Caso de Uso
Diagramas de Classe Diagramas de Classe
Descreve como o caso de uso é realizado, associando o caso de uso com classes e outros elementos de projeto
Requisitos Analise e projeto
Fluxo de Análise e Projeto
2017
12
Diagrama de Atividades
Realizar síntese da arquitetura
2017
13
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
2017
14
Definir a arquitetura candidata
2017
15
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
2017
16
Analisar comportamento
2017
17
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
2017
18
Projetar componentes
2017
19
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
2017
20
Projetar Banco de Dados
2017
21
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
2017
22
Refinar Arquitetura
2017
23
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
2017
24
Fluxo de Análise e Projeto Simplificado
Simplificando/Instanciando o processo para um contexto específico
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
2017
26
2017
27
Passos da Atividade de Análise
• Identificar as classes
• Identificar persistência
• Identificar responsabilidades das classes
• Identificar relacionamentos
• Identificar atributos
Fluxo de atividades simplificado
1. Analisar Caso de Uso
2. Analisar Arquitetura
3. Projetar Classes
4. Projetar Banco de Dados
2017
28
Analisar Caso de Uso
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
2017
30
Passos para Analisar Caso de Uso
• Para cada caso de uso:
1. Encontrar classes de análise
2. Distribuir comportamento entre as classes
• Para cada classe:
3. Descrever responsabilidades
4. Descrever atributos e associações
5. Qualificar mecanismos de análise
2017
31
Passo 1: Encontrar classes de análise • O comportamento do caso de uso é distribuído em classes de
análise
2017
32
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>>)
2017
33
2017
34
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>>
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
2017
35
<<boundary>>
Notação em UML
O Papel de uma Classe de Fronteira
2017
36
<<boundary>>
<<entity>>
<<control>>
<<boundary>>
<<boundary>>
<<entity>>
Usuário
Modela interação entre o sistema e seu ambiente
Exemplo de classes de fronteira
2017
37
Matricular-se Em disciplina Estudante Sistema
Academico
<<boundary>> FormRegistroCursos
<<boundary>> SistemaAcademico
2017
38
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>>
Classes de Entidade
• Abstrações chave dos casos de uso
2017
39
<<entity>>
Glossário
Descrição do
Caso de uso
<<entity>>
<<entity>>
O Papel de uma Classe de Entidade
2017
40
<<boundary>>
<<entity>>
<<control>>
<<boundary>>
<<boundary>>
<<entity>>
Usuário
Armazenam e gerenciam informação no sistema
Exemplo de classes de entidade
2017
41
<<entity>> Estudante
<<entity>> Curso
<<entity>> Horario
2017
42
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>>
Classes de Controle
• Coordenam o comportamento (lógica de controle) do caso de uso
• Interface entre fronteira e entidade
2017
43
<<control>>
O Papel de uma Classe de Controle
2017
44
<<boundary>>
<<entity>>
<<control>>
<<boundary>>
<<boundary>>
<<entity>>
Usuário
Coordenam o comportamento do caso de uso
Exemplo de Classe de Controle
2017
45
Matricular-se Em disciplina Estudante Sistema
Academico
<<control>> ControladorMatricula
matricurlarAluno()
2017
46
registrar faltas
registrar súmulas
das 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
2017
47
Exemplo
• Efetuar Login
• Fluxo de eventos:
1. Usuário informa login e senha
2. Sistema checa se o login e senha conferem
3. Sistema registra a sessão do aluno e a tela principal do sistema é exibida
2017
48
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
2017
49
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>>).
2017
50
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>>
2017
51
Exemplo
TelaLogin
<<boundary>>
CadastroUsuarios
<<entity collection>>
ControladorLogin
<<control>>
Usuario
<<entity>>
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
2017
52
Distribuindo comportamento entre as classes
2017
53
Caso de uso
Diagrama de seqüência Diagrama de colaboração
Classes de análise
Classes de análise com
responsabilidades
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
2017
54
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 2
017
55
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
2017
56
Vários diagramas podem ser necessários
2017
57
Anatomia de um Diagrama de Seqüência
2017
58
:Cliente :Fornecedor
Objetos
Linha da vida
1: Solicita serviço
1.1: Solicita outro serviço
Mensagem reflexiva
Foco do controle Numeração
hierárquica
Mensagem
Exemplo de diagrama de Seqüência
2017
59
: Aluno janela de
matrícula controle de
matrícula
mat 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
Diagrama de Colaboração
2017
60
:Cliente :Fornecedor
Objetos
Mensagem
1: Solicita serviço
Ligação
Exemplo de diagrama de colaboração
2017
61
: Secretaria
janela de curso :
JanelaCurso
gerenciador :
GerenciadorCurriculo curso :
Curso
1: informação do curso
2: processa
3: adiciona curso
4: novo curso
2017
62
Exemplo
: usuário : TelaLogin : ControladorLogin : CadastroAlunos
efetuarLogin(login, senha)
efetuarLogin(login, senha)
checar(login, senha)
registrarSessao()
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
2017
63
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
2017
64
Como fazer?
2017 65
:Cliente :Fornecedor
// Executar responsabilidade
Fornecedor
// Executar responsabilidade
diagrama de
classe
diagrama de
interação
2017
66
Classes com métodos
Passo 4: Descrever atributos e associações
• Definir atributos
• Estabelecer agregações e associações
2017
67
2017
68
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
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
2017
69
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
2017
70
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
2017
71
Encontrando Relacionamentos
2017
72
:Client :Supplier
Link
Supplier
PerformResponsibility()
Diagrama
de classe
Diagrama de
Colaboração
Association
Client Supplier
Client
1: PerformResponsibility
Prime suppliers
0..* 0..*
2017
73
Diagrama final
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
2017
74
Passo 5: Qualificar mecanismos de análise
• Mapear classes de análise em mecanismos de análise
2017
75
Classes de análise Mecanismos de análise
Estudante Persistente
ControladorMatricula Distribuição, Segurança
Curso Persistente, Interface Legado
Passo 6: Unificar classes de análise
2017
76
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
Analisar Arquitetura
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
2017
78
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
2017
79
Exemplo de arquitetura inicial
2017
80
Interface Gráfica
Negócio
Dados
Módulo de Vendas
Módulo de Estoque
Socket
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
2017
81
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
2017
82
Identificar Abstrações-chave
• Definir classes de análise preliminares
• Conhecimento do domínio
• Requisitos
• Outros artefatos (Glossário e modelo de negócio)
2017
83
Projetar classes
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
2017
85
Passos do projeto de classes
1. Criar classes de projeto
2. Identificar classes persistentes
3. Definir métodos
4. Definir atributos
5. Definir estados
6. Definir relacionamentos
7. Contemplar os requisitos não-funcionais
2017
86
Para cada classe:
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
2017
87
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…
2017
88
Projetando classes de entidade
• Classes de Entidade são
• Transitórias
• Persistentes
• São detalhadas no passo “Identificar classes persistentes” 2017
89
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
2017
90
Passo 2: Identificando classes persistentes • Instancias da classe precisam preservar o seu estado
• Estratégia de persistencia é definida para cada classe persistente
2017
91
Curso BD Relacional
Candidato Arquivo
JDBC
Serialização
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
2017
92
Mapeando operações
2017
93
:Fornecedor :Cliente
// Realizar alguma operação
:Fornecedor :Cliente
fazerAlgo()
Projeto
Análise
+ concreto
- concreto
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 2017
94
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
2017
95
Diagrama de Estados
• Um diagrama de estados mostra o ciclo de vida de um objeto
2017
96
Nome do estado
Variavel: Tipo = valor
Ação de entrada Ação de saída
Atividade
Evento(args)
[condição]
/ Operacao(args)
^obj.enviarMensagem(args) Estado
Ações
Atividades Transição
Exemplo de diagrama de estado
2017
97
Inicializado Aberto
Fechado
Cancelado
do: Incializa Curso
do: Finaliza curso
do: Notifica Alunos
Adiciona Aluno / contador = 0
Adiciona Aluno[ contador < 10 ]
[ contador = 10 ]
Cancela
Cancela
Cancela
Passo 6: Definir Relacionamentos
• Dependências
• Associações
• Simples
• Agregação
• Composição
• Generalização
2017
98
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, …)
2017
99
Projetar Banco de Dados
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
2017
101
