análise e projeto no rupbacala/mds2011/mds6.pdf · 2011. 5. 3. · 2009 mds - bacalá 12 fluxo de...

Análise e Projeto no RUP

2009 MDS - Bacalá 2

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á 3 3

Contexto

Requisitos Análise Projeto


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?


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


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

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


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


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


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


Fluxo de Análise e Projeto

Diagrama de Atividades


Realizar síntese da arquitetura


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


Definir a arquitetura candidata


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


Analisar comportamento


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


Projetar componentes


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


Projetar Banco de Dados


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


Refinar Arquitetura


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 RUP para um contexto

específico


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 Arquitetura

2. Analisar Caso de Uso

3. Projetar Classes

4. Projetar Banco de Dados

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


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


Exemplo de arquitetura inicial

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


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


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


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


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


Passo 1: Encontrar classes de análise

O comportamento do caso de uso é distribuído em classes de análise


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á 40 40/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>>


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


O Papel de uma Classe de Fronteira

<<boundary>>

<<entity>>

<<control>>

<<boundary>>

<<boundary>>

<<entity>>

Usuário

Modela interação entre o sistema e seu ambiente


Exemplo de classes de fronteira

Matricular-se Em disciplina Estudante Sistema

Academico

<<boundary>> FormRegistroCursos

<<boundary>> SistemaAcademico


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

<<entity>>

Glossário

Descrição do

Caso de uso

<<entity>>

<<entity>>


O Papel de uma Classe de Entidade

<<boundary>>

<<entity>>

<<control>>

<<boundary>>

<<boundary>>

<<entity>>

Usuário

Armazenam e gerenciam informação no sistema


Exemplo de classes de entidade

<<entity>> Estudante

<<entity>> Curso

<<entity>> Horario


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

<<control>>


O Papel de uma Classe de Controle

<<boundary>>

<<entity>>

<<control>>

<<boundary>>

<<boundary>>

<<entity>>

Usuário

Coordenam o comportamento do caso de uso


Exemplo de Classe de Controle

Matricular-se Em disciplina Estudante Sistema

Academico

<<control>> ControladorMatricula

matricurlarAluno()


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


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


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


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>>).


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>>


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


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


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


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


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


Vários diagramas podem ser necessários


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


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


Diagrama de Colaboração


Objetos

Mensagem

1: Solicita serviço

Ligação


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


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


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


Como fazer?


// Executar responsabilidade

Fornecedor

// Executar responsabilidade

diagrama de

classe

diagrama de

interação


Classes com métodos


Passo 4: Descrever atributos e associações

Definir atributos

Estabelecer agregações e associações


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


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


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


Encontrando Relacionamentos

:Client :Supplier

Link

Supplier

PerformResponsibility()

Diagrama

de classe

Diagrama de

Colaboração

Association

Client Supplier

Client

1: PerformResponsibility

Prime suppliers

0..* 0..*


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


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


Passo 6: Unificar classes de análise


de Uso

Diagramas de Classe Diagramas de Classe

…


de Uso


…


de Uso


…


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


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:


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


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…


Projetando classes de entidade

Classes de Entidade são

Transitórias

Persistentes

São detalhadas no passo “Identificar classes persistentes”


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


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


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


:Fornecedor

Mapeando operações

: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


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


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


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


Passo 6: Definir Relacionamentos

Dependências

Associações

Simples

Agregação

Composição

Generalização


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, …)


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

análise e projeto no rupbacala/mds2011/mds6.pdf · 2011. 5. 3. · 2009 mds - bacalá 12 fluxo de...

Documents