© nabor c. mendonça 2001 1 análise e projeto orientados a objeto com uml e padrões parte i...

© Nabor C. Mendonça 2001 1

Análise e Projeto Orientados a Objetocom UML e Padrões

Parte I

Análise, Projeto, e Processo


Aplicando UML, Padrões e APOO

Objetivo – Desenvolver habilidades práticas na utilização da

TO para a criação de sistemas de software bem projetados, robustos, e modificáveis

Linguagens OO são um primeiro passo necessário mas insuficiente

Outros recursos importantes – processo de desenvolvimento– padrões– UML

Ilustrados na prática através de um estudo de caso detalhado


Atribuindo Responsabilidades

Saber a maneira adequada de atribuir responsabilidades a componentes de software é a habilidade mais importante na APOO– Mais difícil de dominar

– Afeta com mais profundidade a robustez, modificabilidade e reusabilidade do sistema

Padrões GRASP descrevem princípios fundamentais para auxiliar na atribuição de responsabilidades

Saber identificar objetos ou abstrações adequados é a segunda habilidade mais importante


O que é Análise e Projeto?

Análise — “o quê”

Investigação do problema e dos requisitos

Requisitos

Casos de uso

Restrições

Vocabulário

Projeto — “como”

Descrição de uma solução lógica

Objetos

Arquitetura

Instalação & Operação

Interface do usuário


Termos “Análise” e “Projeto” não são fixos, mas usados ao longo de um contínuo

Significados variam de metodologia para metodologia

Distinção é útil na prática, mas debater definições rígidas não é construtivo

Conflito de Terminologias

Mais orientadoa análise

Mais orientado a projeto


O que é APOO?

Na essência, considerar um problema e uma solução dentro da perspectiva de objetos, coisas ou conceitos

O que é AOO?– Investigação dos objetos de domínio e seus

relacionamentos

Descritos no Modelo de Objetos de Domínio

O que é POO?– Elaboração de uma solução lógica em termos de

componentes de software e suas colaborações e responsabilidades

Descritos em Diagramas de Classes e Diagramas de Interação


Representação de um Conceito na APOO

Conceitode domínio

public class Livro{public void imprimir();

private String titulo;}

Representaçãono código

Ex.: O conceito “Livro” em um sistema de biblioteca

Livro

título

Representaçãona análise

Livro

título

Representaçãono projeto

imprimir()


Uma Analogia — Organizando os Negócios de uma Empresa

DocumentosAssociados

APOOAnalogia

Casos de usoAnálise de requisitosQuais são os processos de negócio?

Modelo conceitualAnálise do domínioQuais são os papeis dos empregados?

Diagramas de classes de projeto, diagramas de colaboração

Atribuição de responsabilidades, projeto das interações

Quem é responsável por o quê? Como eles interagem?


Objetivo: ganha o jogo o jogador que rolar dois dados e tirar sete

Modelagem na APOO– Casos de uso

Descrições narrativas de processos do domínio no formato de prosa estruturada

Ex.:

Um Exemplo — Jogo de Dados

Caso de uso:Atores:Descrição:

JogarJogadorEste caso de uso começa quandoo jogador rola os dados. Se o totaldos dados for sete, o jogador ganha;do contrário, ele perde.


Modelagem na APOO (cont.)– Modelo conceitual

Conceitos, atributos, e associações que são considerados importantes no domínio da aplicação

Ex.:

– Um modelo conceitual descreve conceitos do mundo real, não componentes de software!


Jogador

nome

JogoDeDados

Dado

valor

Rola

Joga

Inclui

2

2

1

1

1

1



Modelagem na APOO (cont.) – Diagramas de colaboração

Alocação de responsabilidades para objetos ilustrando como eles interagem via mensagens

Mostram o fluxo de mensagens entre instâncias e a invocação de métodos

Ex.:

:Jogador d1 : Dado

d2 : Dado

joga() 1: r1 := rola()

2: r2 := rola()


Modelagem na APOO (cont.) – Diagramas de classes de projeto

Como os objetos (de software) se conectam?

Quais são os métodos de uma classe?

Ex.:

Rola

Joga

Inclui

2

2

Jogador

nome

joga()

Dado

valor

rola()

JogoDeDados

inicializa()

1

1

1

1



APOO X APE

Sistema deBiblioteca

Sistema

A&P Orientados a ObjetoDecomposição por objetos ou conceitos

A&P EstruturadosDecomposição por funções ou processos

RegistraEmpréstimos

AdicionaRecursos

ReportaMultas

Catálogo

Livro

Bibliotecário

Biblioteca

Metodologias mais antigas, como Análise e Projeto Estruturados, baseiam-se em outras dimensões de decomposição


A UML é a linguagem padrão de diagramação para visualizar os resultados da análise e projeto

A notação (a própria UML) é relativamente trivial Muito mais importante: habilidade para modelar

com objetos– Só aprender a notação UML não ajuda

A UML não é– um processo ou metodologia

– APOO

– regras de projeto

A Linguagem de Modelagem Unificada — UML


Origem e Evolução da UML

Unified Method 0.8 Unificação I(Out’95)

Booch’93 OMT-2

Outros métodos Booch’91 OMT-1 OOSE Fragmentação

UML 1.0

Parceirosda UML

Padronização(Jan’97)

UML 1.1 Industrialização(Set’97)

UML 0.9 & 0.91 Unificação II(Out’96)


Processo de Desenvolvimento

Organização das atividades relacionas à produção e manutenção de sistemas de software

Útil, mas um fator de segunda ordem– O principal: equipe qualificada

Boa equipe + bom processo = menor risco

O processo racional unificado (RUP), baseado no modelo iterativo, é o processo padrão na indústria


Simplificação do processo iterativo unificado

Fácil extensão e customização

Não inclui atividades importantes como – Verificação & validação

– Divisão do trabalho

– Gerência de projeto

– Documentação

Um Processo Iterativo Simplificado

ConstruçãoPlan. &Elaboração Implantação


Fases

Planejamento e Elaboração– Concepção inicial, investigação de alternativas,

definição de requisitos, etc.

Construção– Construção do sistema através de múltiplos ciclos

de análise, projeto, implementação e teste

Implantação– Instalação e operação do sistema


Modelos e Artefatos

Um modelo descreve e abstrai aspectos essenciais de um sistema– Modelo estático (estrutura)

– Modelo dinâmico (comportamento)

Modelos são compostos por artefatos — diagramas e documentos que descrevem os elementos do modelo

Na APOO, a UML é usada para descrever e visualizar os modelos e artefatos produzidos em cada fase do processo de desenvolvimento


Fase de Planejamento e Elaboração

2. Criar Rel. Prel. de Investigação

3. Definir Requisitos

9. Refinar Plano7. Definir Mod. Conc. Inicial c

4. Reg. Termos no Glossário a

6. Definir Casos de Uso

1. Definir PlanoInicial

5. ImplementarProtótipo

b, d

a. contínuab. opcionalc. adiáveld. ordem variada

8. Definir Arquit.Inicial a, c, d

Notas




Atividades:

1. Definir plano inicial

Prazos, recursos, orçamento

2. Criar relatório preliminar de investigação

Motivação, alternativas, necessidades de negócio

3. Definir requisitos

Especificação declarativa dos requisitos

4. Registrar termos no glossário

Dicionário de termos, regras, restrições

5. Implementar protótipo

Protótipo do sistema para ajudar na definição dos requisitos



Atividades:

6. Definir casos de uso

Descrição em prosa estruturada dos processos de negócio

7. Definir modelo conceitual inicial

Objetos de domínio e seus relacionamentos

8. Definir arquitetura inicial

Principais subsistemas e suas dependências

9. Refinar plano

Atividades não lineares – Ex.: 7, 4, 6 em paralelo


Fase de Construção

Ciclo deDesenv. 1

Sinc.Artefatos Análise Projeto Teste

Refin.Plano Impl.

Ciclo deDesenv. 2

...



Fase de Construção

Repetição de ciclos de desenvolvimento– Construção progressiva do sistema até atingir uma

versão que satisfaça corretamente os requisitos

Atividades típicas de cada ciclo:

1. Refinar plano

2. Sincronizar artefatos

3. Análise

4. Projeto

5. Implementação

6. Teste


Ciclos de Desenvolvimento

Cada ciclo implementa um conjunto reduzido de requisitos, adicionando novas funções ao sistema – Crescimento incremental, através de expansões e

refinamentos sucessivos

Ciclos com tempo fixo de duas a oito semanas

Vantagens:– Evita complexidade excessiva

– Antecipa feedback dos usuários


Ciclos de Desenvolvimento e Casos de Uso

Um ciclo deve atacar um ou mais casos de uso, ou versões simplificadas de casos de uso

Casos de uso mais relevantes devem ser atacados nos primeiros ciclos– Prioridade para serviços com grande influência na

arquitetura do sistema ou de alto risco

Ciclo de Desenv. 1

Caso de uso AVersãoSimplificada

Ciclo de Desenv. 2

Caso de uso AVersãoCompleta

Ciclo de Desenv. 3

Caso de uso B

Caso de uso C


Análise

a. se ainda não feitob. contínuoc. opcional

2. Refinar Diag. Casos de Uso

3. Refinar ModeloConceitual

4. Refinar Glossário b

6. Definir Contrat.de Operação

1. Definir Casos de Uso Essenciais a

5. Definir Diag.Seq.

7. Definir Diag.Estado c

Notas

...Ciclo deDesenv. 1

Sinc.Artefatos Análise Projeto TesteRefin.

Plano Impl.

Ciclo deDesenv. 2


Análise

Subatividades:

1. Definir casos de uso essenciais

2. Refinar diagramas de casos de uso

3. Refinar modelo conceitual

4. Refinar glossário

5. Definir diagramas de seqüência do sistema

6. Definir contratos de operação

7. Definir diagramas de estado


Projeto

2. Definir Rel. & IU

4. Definir Diag.Interação

5. Definir Diag.Classes a

6. Definir Esquemado BD

1. Definir Casos deUso Reais

3. Refinar Arquitetura b

Notas

a. em paralelo com diag. interaçãob. ordem variada

...Ciclo deDesenv. 1

Sinc.Artefatos Análise Projeto TesteRefin.

Plano Impl.

Ciclo deDesenv. 2


Projeto

Subatividades:

1. Definir casos de uso reais

2. Definir relatórios e interfaces com o usuário

3. Refinar arquitetura do sistema

4. Definir diagramas de interação

5. Definir diagramas de classes de projeto

6. Definir esquema do banco de dados

© nabor c. mendonça 2001 1 análise e projeto orientados a objeto com uml e padrões parte i...

Documents