Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
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
2012 2
Contexto
3/28
Requisitos Análise Projeto
2012 3
Arquitetura
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
2012 4
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
2012 5
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
2012 6
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 sistema
Adaptar o projeto
2012 7
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
2012 8
Visão geral dos artefatos
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
2012 9
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
2012 10
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
2012 11
Fluxo de Análise e Projeto
Diagrama de Atividades
2012 12
Realizar síntese da arquitetura
2012 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
2012 14
Definir a arquitetura candidata
2012 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
2012 16
Analisar comportamento
2012 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
2012 18
Projetar componentes
2012 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
2012 20
Projetar Banco de Dados
2012 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
2012 22
Refinar Arquitetura
2012 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
2012 24
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
2012 26
Passos da Atividade de Análise Identificar as classes
Identificar persistência
Identificar responsabilidades das classes
Identificar relacionamentos
Identificar atributos
2012 27
Fluxo de atividades simplificado
1. Analisar Caso de Uso
2. Analisar Arquitetura
3. Projetar Classes
4. Projetar Banco de Dados
2012 28
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
2012 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
2012 31
Passo 1: Encontrar classes de análise O comportamento do caso de uso é distribuído em
classes de análise
2012 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>>)
2012 33
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>>
2012 34
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
2012 35
O Papel de uma Classe de Fronteira
<<boundary>>
<<entity>>
<<control>>
<<boundary>>
<<boundary>>
<<entity>>
Usuário
Modela interação entre o sistema e seu ambiente
2012 36
Exemplo de classes de fronteira
Matricular-se Em disciplina Estudante Sistema
Academico
<<boundary>> FormRegistroCursos
<<boundary>> SistemaAcademico
2012 37
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>>
2012 38
Classes de Entidade Abstrações chave dos casos de uso
<<entity>>
Glossário
Descrição do
Caso de uso
<<entity>>
<<entity>>
2012 39
O Papel de uma Classe de Entidade <<boundary>>
<<entity>>
<<control>>
<<boundary>>
<<boundary>>
<<entity>>
Usuário
Armazenam e gerenciam informação no sistema
2012 40
Exemplo de classes de entidade
<<entity>> Estudante
<<entity>> Curso
<<entity>> Horario
2012 41
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>>
2012 42
Classes de Controle Coordenam o comportamento (lógica de controle) do
caso de uso
Interface entre fronteira e entidade
<<control>>
2012 43
O Papel de uma Classe de Controle
<<boundary>>
<<entity>>
<<control>>
<<boundary>>
<<boundary>>
<<entity>>
Usuário
Coordenam o comportamento do caso de uso
2012 44
Exemplo de Classe de Controle
Matricular-se Em disciplina Estudante Sistema
Academico
<<control>> ControladorMatricula
matricurlarAluno()
2012 45
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
2012 46
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
2012 47
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
2012 48
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>>).
2012 49
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>>
2012 50
Exemplo
TelaLogin
<<boundary>>
CadastroUsuarios
<<entity collection>>
ControladorLogin
<<control>>
Usuario
<<entity>>
2012 51
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
2012 52
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
2012 53
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
2012 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
2012 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
2012 56
Vários diagramas podem ser necessários
2012 57
Anatomia de um Diagrama de Seqüência
: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
2012 58
Exemplo de diagrama de Seqüência
: 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
2012 59
Diagrama de Colaboração
:Cliente :Fornecedor
Objetos
Mensagem
1: Solicita serviço
Ligação
2012 60
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
2012 61
Exemplo
: usuário : TelaLogin : ControladorLogin : CadastroAlunos
efetuarLogin(login, senha)
efetuarLogin(login, senha)
checar(login, senha)
registrarSessao()
2012 62
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
2012 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
2012 64
Como fazer?
:Cliente :Fornecedor
// Executar responsabilidade
Fornecedor
// Executar responsabilidade
diagrama de
classe
diagrama de
interação
2012 65
Classes com métodos
66 2012
Passo 4: Descrever atributos e associações
Definir atributos
Estabelecer agregações e associações
2012 67
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
2012 68
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
2012 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
2012 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
2012 71
Encontrando Relacionamentos
:Client :Supplier
Link
Supplier
PerformResponsibility()
Diagrama
de classe
Diagrama de
Colaboração
Association
Client Supplier
Client
1: PerformResponsibility
Prime suppliers
0..* 0..*
2012 72
Diagrama final
2012 73
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
2012 74
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
2012 75
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
2012 76
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
2012 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
2012 79
Exemplo de arquitetura inicial
Interface Gráfica
Negócio
Dados
Módulo de Vendas
Módulo de Estoque
Socket
2012 80
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
2012 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
2012 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)
2012 83
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
2012 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
Para cada classe:
2012 86
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
2012 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…
2012 88
Projetando classes de entidade Classes de Entidade são
Transitórias
Persistentes
São detalhadas no passo “Identificar classes persistentes”
2012 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
2012 90
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
2012 91
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
2012 92
Mapeando operações
:Fornecedor :Cliente
// Realizar alguma operação
:Fornecedor :Cliente
fazerAlgo()
Projeto
Análise
+ concreto
- concreto
2012 93
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
2012 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
2012 95
Diagrama de Estados Um diagrama de estados mostra o ciclo de vida de um
objeto
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
2012 96
Exemplo de diagrama de estado
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
2012 97
Passo 6: Definir Relacionamentos
Dependências
Associações
Simples
Agregação
Composição
Generalização
2012 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, …)
2012 99
2012 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
2012 101