Análise e Projeto no RUP. 2009MDS - Bacalá215/03/20052/28 Contexto Após a etapa de análise de requisitos, temos documentos de requisitos e os casos

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


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 eprojeto

Modelo de análise e projeto

Documento daarquitetura

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


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

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


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álise2. Distribuir comportamento entre as

classes

Para cada classe:3. Descrever responsabilidades4. Descrever atributos e associações5. 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á 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>>


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


Classes de Entidade

Abstrações chave dos casos de uso

<<entity>>

Glossário

Descrição doCaso 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

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


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


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

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


Diagrama de Colaboração


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)


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

2009 MDS - Bacalá 7315/03/2005 73/28

Classes com métodos

TelaLogin


<<boundary>>

CadastroUsuarios


<<entity collection>>

ControladorLogin

efetuarLogin(login, senha)registrarSessao()

<<control>>

Usuario<<entity>>


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


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


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

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


<<boundary>>ControladorLogin

efetuarLogin(login, senha)registrarSessao()

<<control>>

1*

CadastroUsuarios


<<entity collection>> 1

1

* 1

1

1


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


Diagramas de Classe Diagramas de Classe

…



…



…


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 projeto2. Identificar classes persistentes3. Definir métodos4. Definir atributos5. Definir estados6. Definir relacionamentos7. 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 entradaAção de saídaAtividade

Evento(args)[condição]/ Operacao(args)^obj.enviarMensagem(args)Estado

Ações

Atividades Transição


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


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

Documents

Análise e Projeto no RUP. 2009MDS - Bacalá215/03/20052/28 Contexto Após a etapa de análise de requisitos, temos documentos de requisitos e os casos