An

1
Análise e Projeto no RUP
2
Tópicos abordado

• Visão geral do RUP
• Introdução à disciplina de Análise Projeto
• Atividades
• Papéis
• Artefatos

3
Análise Projeto
4
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

5
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

6
Visão geral dos artefatos
Modelo de análise e projeto
Modelo de caso de uso
Documento da arquitetura
Modelo de dados
Documento requisitos
Glossário
7
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

8
Realização de Caso de Uso

• Descreve como o caso de uso é realizado,
  associando o caso de uso com classes e outros
  elementos de projeto

? Analise e projeto ?
? Requisitos ?
9
Fluxo de Análise e Projeto
Diagrama de Atividades
10
Realizar síntese da arquitetura
11
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

12
Definir a arquitetura candidata
13
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

14
Analisar comportamento
15
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

16
Projetar componentes
17
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

18
Projetar Banco de Dados
19
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

20
Refinar Arquitetura
21
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

22
Fluxo de Análise e Projeto Light

• Simplificando/Instanciando o processo para um
  contexto específico

23
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

24
Fluxo de atividades simplificado

1. Analisar Arquitetura
2. Analisar Caso de Uso
3. Projetar Classes
4. Projetar Banco de Dados

25
Analisar Arquitetura
26
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

27
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

28
Exemplo de arquitetura inicial
Módulo de Vendas
Módulo de Estoque
Interface Gráfica
Negócio
Socket
Dados
29
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

30
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

31
Identificar Abstrações-chave

• Definir classes de análise preliminares
• Conhecimento do domínio
• Requisitos
• Outros artefatos (Glossário e modelo de negócio)

32
Exercício
33
Analisar Caso de Uso
34
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

35
Passos para Analisar Caso de Uso

• Para cada caso de uso
• Encontrar classes de análise
• Distribuir comportamento entre as classes
• Para cada classe
• Descrever responsabilidades
• Descrever atributos e associações
• Qualificar mecanismos de análise

36
Passo 1 Encontrar classes de análise

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

37
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 (ltltboundarygtgt)
• Controle (ltltcontrolgtgt)
• Entidade (ltltentitygtgt)

38
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

Notação em UML
39
O Papel de uma Classe de Fronteira
Usuário
Modela interação entre o sistema e seu ambiente
40
Exemplo de classes de fronteira
41
Classes de Entidade

• Abstrações chave dos casos de uso

42
O Papel de uma Classe de Entidade
Usuário
Armazenam e gerenciam informação no sistema
43
Exemplo de classes de entidade
44
Classes de Controle

• Coordenam o comportamento (lógica de controle) do
  caso de uso
• Interface entre fronteira e entidade

ltltcontrolgtgt
45
O Papel de uma Classe de Controle
Coordenam o comportamento do caso de uso
46
Exemplo de Classe de Controle
matricurlarAluno()
47
Exercício
48
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

49
Distribuindo comportamento entre as classes
Classes de análise
Diagrama de seqüência
Diagrama de colaboração
Classes de análise com responsabilidades
Caso de uso
50
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

51
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

52
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

53
Vários diagramas podem ser necessários
54
Anatomia de um Diagrama de Seqüência
Objetos
Fornecedor
Cliente
Mensagem reflexiva
? Linha da vida ?
1 Solicita serviço
1.1 Solicita outro serviço
Mensagem
Foco do controle
Numeração hierárquica
55
Exemplo de diagrama de Seqüência
56
Diagrama de Colaboração
Objetos
Cliente
Fornecedor
1 Solicita serviço
Mensagem
Ligação
57
Exemplo de diagrama de colaboração
58
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

59
Exercício
60
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

61
Como fazer?
Fornecedor
Cliente
diagrama de interação
// Executar responsabilidade
Fornecedor
diagrama de classe
// Executar responsabilidade
62
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

63
Passo 4 Descrever atributos e associações

• Definir atributos
• Estabelecer agregações e associações

64
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

65
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

66
Encontrando Relacionamentos
1 PerformResponsibility
Diagrama de Colaboração
Client
Supplier
Link
Client
Supplier
Client
Supplier
0..
0..
Diagrama de classe
Prime suppliers
PerformResponsibility()
Association
67
Exercício
68
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
69
Passo 6 Unificar classes de análise



70
Projetar classes
71
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

72
Passos do projeto de classes
Para cada classe

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

73
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

74
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

75
Projetando classes de entidade

• Classes de Entidade são
• Transitórias
• Persistentes
• São detalhadas no passo Identificar classes
  persistentes

76
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

77
Passo 2 Identificando classes persistentes

• Instancias da classe precisam preservar o seu
  estado
• Estratégia de persistencia é definida para cada
  classe persistente

JDBC
Curso
BD Relacional
Serialização
Candidato
Arquivo
78
Exercício
79
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

80
Mapeando operações
- concreto
Fornecedor
Cliente
// Realizar alguma operação
Análise
Projeto
Fornecedor
Cliente
fazerAlgo()
concreto
81
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

82
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

83
Diagrama de Estados

• Um diagrama de estados mostra o ciclo de vida de
  um objeto

Evento(args) condição / Operacao(args) obj.envi
arMensagem(args)
Nome do estado
Variavel Tipo valor
Estado
Ação de entrada
Ações
Ação de saída
Atividade
Atividades
Transição
84
Exemplo de diagrama de estado
85
Exercício
86
Passo 6 Definir Relacionamentos

• Dependências
• Associações
• Simples
• Agregação
• Composição
• Generalização

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

88
Exercício
89
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
• Será visto com mais detalhes em outra disciplina

90
FIM!!!