Análise e Projeto no RUP

2012

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

2012

3

Contexto

3/28

Requisitos Análise Projeto

Arquitetura

2012

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

2012

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

2012

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

2012

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

2012

8

Visão geral dos artefatos

2012

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

2012

10

Realização de Caso de Uso

2012

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

2012

12

Diagrama de Atividades

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

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

2012

26

2012

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

2012

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

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

2012

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

2012

35

<<boundary>>

Notação em UML

O Papel de uma Classe de Fronteira

2012

36

<<boundary>>

<<entity>>

<<control>>

<<boundary>>

<<boundary>>

<<entity>>

Usuário

Modela interação entre o sistema e seu ambiente

Exemplo de classes de fronteira

2012

37

Matricular-se Em disciplina Estudante Sistema

Academico

<<boundary>> FormRegistroCursos

<<boundary>> SistemaAcademico

2012

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

2012

39

<<entity>>

Glossário

Descrição do

Caso de uso

<<entity>>

<<entity>>

O Papel de uma Classe de Entidade

2012

40

<<boundary>>

<<entity>>

<<control>>

<<boundary>>

<<boundary>>

<<entity>>

Usuário

Armazenam e gerenciam informação no sistema

Exemplo de classes de entidade

2012

41

<<entity>> Estudante

<<entity>> Curso

<<entity>> Horario

2012

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

2012

43

<<control>>

O Papel de uma Classe de Controle

2012

44

<<boundary>>

<<entity>>

<<control>>

<<boundary>>

<<boundary>>

<<entity>>

Usuário

Coordenam o comportamento do caso de uso

Exemplo de Classe de Controle

2012

45

Matricular-se Em disciplina Estudante Sistema

Academico

<<control>> ControladorMatricula

matricurlarAluno()

2012

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

2012

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

2012

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

2012

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

2012

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

2012

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

2012

52

Distribuindo comportamento entre as classes

2012

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

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 2

012

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

2012

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

2012

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

2012

60

:Cliente :Fornecedor

Objetos

Mensagem

1: Solicita serviço

Ligação

Exemplo de diagrama de colaboração

2012

61

: Secretaria

janela de curso :

JanelaCurso

gerenciador :

GerenciadorCurriculo

curso :

Curso

1: informação do curso

2: processa

3: adiciona curso

4: novo curso

2012

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

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?

2012 65

:Cliente :Fornecedor

// Executar responsabilidade

Fornecedor

// Executar responsabilidade

diagrama de

classe

diagrama de

interação

2012

66

Classes com métodos

Passo 4: Descrever atributos e associações

• Definir atributos

• Estabelecer agregações e associações

2012

67

2012

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

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

2012

72

:Client :Supplier

Link

Supplier

PerformResponsibility()

Diagrama

de classe

Diagrama de

Colaboração

Association

Client Supplier

Client

1: PerformResponsibility

Prime suppliers

0..* 0..*

2012

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

2012

74

Passo 5: Qualificar mecanismos de análise

• Mapear classes de análise em mecanismos de análise

2012

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

2012

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

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

2012

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

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

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

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

2012

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

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

2012

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

2012

92

Mapeando operações

2012

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

2012

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

2012

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

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

Projetar Banco de Dados

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