Análise e Projeto Orientados a Objeto

(1)

1

Análise e Projeto

Orientados a Objeto

com UML e Padrões

Parte I

Análise, Projeto, e

Processo

(2)

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

(3)

3

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

(4)

O que é Análise e Projeto?

Análise — “o quê”

Investigação do problema e dos requisitos

Requisitos

Casos de uso

Restrições

Projeto — “como”

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

Objetos

Arquitetura

(5)

5

■

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 orientado

(6)

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

(7)

7

Representação de um Conceito na APOO

Conceito de domínio

public class Livro {

public void imprimir();

private String titulo; }

Representação no código

■

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

Livro título Representação na análise Livro título Representação no projeto imprimir()

(8)

Uma Analogia — Organizando os Negócios de

uma Empresa

Documentos Associados APOO Analogia Casos de uso Análise de requisitos

Quais são os processos de negócio?

Modelo conceitual Análise do domínio

Quais são os papeis dos empregados? Diagramas de classes de projeto, diagramas Atribuição de responsabilidades, Quem é responsável

(9)

9

■

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:

Jogar Jogador

Este caso de uso começa quando o jogador rola os dados. Se o total dos dados for sete, o jogador ganha; do contrário, ele perde.

(10)

■

Modelagem na APOO (cont.)

–

Modelo conceitual

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

Ex.:

Um Exemplo — Jogo de Dados

Jogador nome JogoDeDados Dado valor Rola Joga Inclui 2 2 1 1 1 1

(11)

11

Um Exemplo — Jogo de Dados

■

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

(12)

■

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 2 2 Jogador nome joga() Dado valor rola() 1 1

(13)

13

APOO X APE

Sistema de Biblioteca

Sistema A&P Orientados a Objeto

Decomposição por objetos ou conceitos

A&P Estruturados

Decomposição por funções ou processos

Registra

Empréstimos RecursosAdiciona 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

(14)

■

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

A Linguagem de Modelagem Unificada —

UML

(15)

15

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 Parceiros da UML Padronização (Jan’97) UML 1.1 Industrialização (Set’97)

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

(16)

(17)

17

Introdução à UML

■

UML (Unified Modelling Language)

■

É uma linguagem para especificação,

construção, visualização e documentação de

sistemas.

■

É uma evolução das linguagens para

especificação de conceitos de Booch, OMT e

OOSE e também de outros métodos de

especificação de requisitos orientados a

objetos ou não.

(18)

Histórico da UML

■

Início em Outubro de 1994:

Booch

e

Jim

Rumbaugh

começaram um esforço para

unificar o método de Booch

Booch

e OMT

OMT

Object

Modeling Technique).

■

Uma primeira versão chamada Unified

Method, foi divulgada em outubro de 1995.

■

Jacobson

juntou-se a grupo, agregando o

método OOSE

OOSE

(Object- Oriented Software

(19)

19

Histórico da UML

■ O esforço dos três resultou na liberação da UML

versão 0.9 e 0.91 em junho e outubro de 1996.

■ Em janeiro de 1997, foi liberada a versão 1.0 da UML. ■ Adotada como padrão segundo a OMG (Object

Management Group, http://www.omg.org ) em Novembro de 1997

(20)

(21)

21

Ferramentas de Apoio

■

Diversas empresas lançaram ferramentas

para auxiliar a modelagem e projeto de

sistemas utilizando UML, gerar código a

partir da modelagem e projetos e realizar

engenharia reversa, ou seja, obter o modelo

em UML a partir do código.

(22)

Ferramentas de Apoio

■ Exemplos:

– A família Rational Rose Interprise (da Rational Software

Corporation www.rational.com) que gera código em Smaltalk, PowerBuilder, C++, J++ e VB.

– _{ArgoUML- free}_{http://argouml.tigris.org/}

www.objectsbydesign.com/tools/umltoolsbyCompany.h tml

(lista de ferramentas que envolvem a UML)

– MVCase: Desenvolvida por pesquisadores da UFSCAR.

(23)

23

Diagramas da UML

■ Diagramas de Casos de Uso ■ Diagramas de classe ■ Diagramas de Comportamento – Diagrama de Estado – _{Diagrama de Atividade} – Diagrama de Seqüência – _{Diagrama de Colaboração} ■ Diagramas de Implementação – _{Diagrama de Componente} – Diagrama de Implantação

(24)

Elementos Genéricos: Notas e

Restrições

■

Nota é um comentário inserido no diagrama:

• Restrições (constraint): é uma relação

semântica entre elementos do modelo.

Especifica condições ou proposições

que devem ser mantidas verdadeiras.

(25)

25

Elementos Genéricos: Pacotes

■ Pacotes agrupam elementos de modelagem.

■ Pacotes podem conter classes, relacionamentos,

(26)

Elementos Genéricos: Estereótipos

(stereotypes)

■ Mecanismo de extensão introduzido pela UML, que

permite estender o meta-modelo para suprir

necessidades que não encontram-se entre os

meta-elementos disponíveis (desde que a definição semântica da própria linguagem não seja ferida).

■ Deve ser baseado em certas classes existentes no

meta-modelo e deve estender estas classes apenas em certas formas pré-definidas, porém esses limites não são

(27)

27

Elementos Genéricos: Estereótipos

(stereotypes)

■ Um estereótipo pode ser aplicado a classes,

relacionamentos de dependência, atributos, operações, etc., por ex: <<abstract>>, <<metaclass>>

(28)

Material sobre UML

■ http://www.rational.com (Rational)

■ http://www.omg.org (Object Management Group)

■ Page-Jones, M.; Fundamentos do desenho orientado a objeto com

UML, Makron Books, 2001.

■ Furlan, J.D.; Modelafem de Objetos Através da UML, Makron

Bools, 1998.

■ Rumbaugh, J., Jacobson, I., Booch, G; The Unified Modeling

Language Reference Manual, Addison- Wesley, c1999.

■ Conallen,J.; Building Web Applications with UML,

Addison-Wesley, 19999.

(29)

29

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

(30)

(31)

31

Objetivo

■

Seguir um processo de desenvolvimento simples,

(32)

Modelos de Processo de Software

■ Desenvolver software é geralmente uma tarefa complexa e

sujeita a erros.

■ Sucesso ou fracasso dependem de inúmeros fatores que

ocorrem durante todo o processo.

■ Necessidade de estabelecer processos sistemáticos para

(33)

33

Exemplos de Modelos de Processo de

Software

■ Modelo em Cascata

■ Modelo de Prototipagem ■ Modelo Evolucionário

■ Desenvolvimento Baseado em Componentes

■ Modelo de Métodos formais ■ Programação Extrema

(34)

UML e Processo de Software

■ A UML não define um processo padrão.

■ A habilidade de saber como criar um bom projeto é mais

importante do que seguir um método ou processo oficial.

■ Essa habilidade é adquirida dominando-se um conjunto de

princípios e heurísticas para identificar e abstrair um

conjunto relevante de objetos e atribuir responsabilidade a eles.

(35)

35

Princípios Básicos do PU

■

Desenvolvimento iterativo

■

Baseado em casos de uso

■

Centrado na arquitetura

(36)

Desenvolvimento Interativo

■

O desenvolvimento de um software é dividido em

O desenvolvimento de um software

vários ciclos de iteração, cada qual produzindo um

sistema testeaado, integrado e executável.

■

Em

cada ciclo ocorrem as atividades de

cada ciclo

análise de

requisitos

requisitos,

projeto,

projeto

implementação e

implementação

teste, bem

teste

como a integração dos artefatos produzidos com

os artefatos já existentes.

(37)

37

(38)

Desenvolvimento Interativo

■ Planejar quantos ciclos de desenvolvimento serão

necessários para alcançar os objetivos do sistema.

■ As partes mais importantes devem ser priorizadas e

alocadas nos primeiros ciclos.

– _{A primeira iteração estabelece os principais riscos e o escopo}

inicial do projeto, de acordo com a funcionalidade principal do sistema.

– Partes mais complexas do sistema devem ser atacadas já no

primeiro ciclo, pois são elas que apresentam maior risco de inviabilizar o projeto.

(39)

39

Desenvolvimento Interativo

■ O tamanho de cada ciclo pode variar de uma empresa para

outra e conforme o tamanho do sistema.

– _{Por exemplo, uma empresa pode desejar ciclos de 4 semanas,}

outra pode preferir 3 meses.

■ Produtos entregues em um ciclo podem ser colocados

imediatamente em operação, mas podem vir a ser

substituídos por outros produtos mais complexos em ciclos posteriores.

(40)

Baseado em Casos de Uso

■ Um caso de uso é uma seqüência de ações, executadas por

um ou mais atores e pelo próprio sistema, que produz um ou mais resultados de valor para um ou mais atores.

■ O PU é dirigido por casos de uso, pois utiliza-os para dirigir

todo o trabalho de desenvolvimento, desde a captação inicial e negociação dos requisitos até a aceitação do código (testes).

(41)

41

Baseado em Casos de Uso

■

Os casos de uso são centrais ao PU e a outros

métodos iterativos, pois:

–

Os requisitos funcionais são registrados

preferencialmente por meio deles

–

Eles ajudam a planejar as iterações

–

Eles podem conduzir o projeto

(42)

Centrado na arquitetura

■ Arquitetura é a organização fundamental do sistema como

um todo. Inclui elementos estáticos, dinâmicos, o modo como trabalham juntos e o estilo arquitetônico total que guia a organização do sistema.

■ A arquitetura também se refere a questões como

desempenho, escalabilidade, reuso e restrições econômicas e tecnológicas.

(43)

43

Centrado na arquitetura

■ No PU, a arquitetura do sistema em construção é o alicerce

fundamental sobre o qual ele se erguerá

■ Deve ser uma das preocupações da equipe de projeto. ■ A arquitetura, juntamente com os casos de uso, deve

(44)

Centrado na arquitetura

■ A arquitetura é importante porque:

– _{Ajuda a entender a visão global}

– _{Ajuda a organizar o esforço de desenvolvimento} – Facilita as possibilidades de reuso

– Facilita a evolução do sistema

(45)

45

As Fases do PU

■ Cada um dos ciclos de desenvolvimento do PU é dividido

em quatro fases

– Concepção

– Elaboração – _Construção – _Transição

(46)

(47)

47

Fases do PU: Concepção

■ Estabelece-se as viabilidade de implantação do sistema ■ Definição do escopo do sistema.

■ Estimativas de custos e cronograma

■ Identificação dos potenciais riscos que devem ser

gerenciados ao longo do projeto

■ Esboço da arquitetura do sistema, que servirá como alicerce

(48)

Fases do PU: Elaboração

■ Visão refinada do sistema, com a definição dos requisitos

funcionais, detalhamento da arquitetura criada na fase anterior e gerenciamento contínuo dos riscos envolvidos.

■ Estimativas realistas feitas nesta fase permitem um plano

(49)

49

Fases do PU: Construção

■ O sistema é efetivamente desenvolvido e, em geral, tem

condições de ser operado, mesmo que em ambiente de teste, pelos clientes.

■ É nesta fase que o desenvolvimento iterativo e incremental

(50)

Fases do PU: Transição

■ O sistema é entregue ao cliente para uso em produção.

■ Testes são realizados e um ou mais incrementos do sistema

são implantados.

(51)

51

As disciplinas do PU

■ Avaliando-se as fases do PU, pode-se ter a impressão de

que cada ciclo de iteração comporta-se como o modelo em cascata.

■ Mas isso não é verdade: paralelamente às fases do PU,

atividades de trabalho, denominadas disciplinas do PU, são realizadas a qualquer momento durante o ciclo de desenvolvimento.

■ As disciplinas entrecortam todas as fases do PU,

podendo ter maior ênfase durante certas fases e menor ênfase em outras, mas podendo ocorrer em qualquer uma delas.

(52)

(53)

53

Os Artefatos do PU

■ Cada uma das disciplinas do PU pode gerar um ou mais

artefatos

artefatos, que devem ser controlados e administrados corretamente durante o desenvolvimento do sistema.

■ Artefatos são quaisquer dos documentos produzidos

durante o desenvolvimento, tais como modelos,

diagramas, documentos de especificação de requisitos, código fonte ou executável, planos de teste, etc.

■ Muitos dos artefatos são opcionais, produzidos de

(54)

(55)

55

(56)

Definição de Modelos e Artefatos

■ O mundo real é complexo e cheio de detalhes, por isso ele

deve ser decomposto em partes, chamadas de modelos, que descrevem e abstraem aspectos essenciais dos sistemas.

■ Modelos são compostos de outros modelos, que são

chamados de artefatos - diagramas e documentos – e são visualizados em visões.

■ Os modelos podem enfatizar aspectos dinâmicos e estáticos

(57)

57

O Modelo do Sistema

■

Modelo de Análise: modelos relacionados a uma

Modelo de Análise

investigação do domínio e do espaço do problema,

mas não à solução.

■

Modelo de Projeto: modelos relacionados à

Modelo de Projeto

(58)

Relacionamento entre os artefatos da fase planejar e

elaborar

Relatório de Investigação Preliminar Protótipos Orçamento, Cronograma Especificação de Requisitos Casos de Uso

a. Todos os de alto nível b. Alguns essenciais

expandidos

Diagramas de Casos de Uso

Esboço do modelo Conceitual

Depende de

(59)

59

■

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ção Plan. &

(60)

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

(61)

61

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

(62)

Fase de Planejamento e Elaboração

2. Criar Rel. Prel.

de Investigação 3. Definir Requisitos

4. Reg. Termos no Glossário _a 6. Definir Casos de Uso 1. Definir Plano Inicial 5. Implementar Protótipo b, d _Notas Construção Plan. & Elaboração Implantação

(63)

63

Fase de Planejamento e Elaboração

■

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

(64)

Fase de Planejamento e Elaboração

■

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

(65)

65

Fase de Construção

Ciclo de Desenv. 1

Sinc.

Artefatos Análise Projeto Teste Refin. Plano Impl. Ciclo de Desenv. 2 ... Construção Plan. & Elaboração Implantação

(66)

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

(67)

67

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

(68)

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

(69)

69

Análise

a. se ainda não feito b. contínuo

c. opcional

2. Refinar Diag.

Casos de Uso 3. Refinar ModeloConceitual Glossário 4. Refinar _b

6. Definir Contrat. de Operação 1. Definir Casos de

Uso Essenciais_a

5. Definir Diag.

Seq. 7. Definir Diag.Estado _c

Notas ...

Sinc.

Artefatos Análise Projeto Teste Refin.

Plano Impl.

(70)

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

(71)

71

Projeto

2. Definir Rel. & IU

4. Definir Diag.

Interação 5. Definir Diag.Classes _a 6. Definir Esquemado BD 1. Definir Casos de

Uso Reais Arquitetura3. Refinar _b

Notas a. em paralelo com diag. interação b. ordem variada ... Ciclo de Desenv. 1 Sinc.