IF 718Análise e Projeto de Sistemas

Augusto SampaioVitor Braga (Estágio

docência) Camila Sá (Monitora)

2010.2

• Parte do material cedido pela Qualiti Software Processes

Copy

right

© 2

008

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

Análise e Projeto de Sistemas

Objetivos: Processo de Análise e Projeto no RUP Processo baseado em paradigmas recentes:

• SOA (Software-Oriented Architecture)• MDA (Model-Driven Architecture)

Análise comparativa contínua entre os processos Técnicas de modelagem OO em UML Ênfase em Padrões de Projeto e Arquiteturais Consolidação dos conceitos em um exemplo

construído incrementalmente Uso de uma ferramenta de modelagem

Análise e Projeto OO com UML e Padrões| 2

Copy

right

© 2

008

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

ConteúdoA&P no RUP Disciplina de A&P Análise de caso de

uso Projetar

arquitetura Projetar casos de

uso

A&P com SOA e MDA Introdução ao

processo Especificação do

modelo de negócios Analisar serviços Projetar serviços

Análise e Projeto OO com UML e Padrões| 3

• Projetar subsistemas (componentes)• Projetar classes

• Projetar concorrrência e distribuição• Projetar base de dados

Copy

right

© 2

008

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

Para ser uma atividade sistematizada, Análise e Projeto deve ser parte de um processoProcesso: O que é? Representação? Ciclo de vida? Execução? Modelos de processo

Análise e Projeto OO com UML e Padrões| 4

Processo de software

Copy

right

© 2

008

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

CIn-UFPE5/45

A&P no modelo Cascata

Análise e Projeto

Copy

right

© 2

008

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

CIn-UFPE6/45

A&P no modelo Espiral

Copy

right

© 2

008

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

CIn-UFPE7/45

A&P no modelo iterativo do RUP

Planejamento e Gerenciamento.....

Fluxos de Suporte

Gerência de Configuração............

Requisitos...............................Análise e Projeto......................Implementação........................Testes...................................Implantação............................

Fluxos de Processo

Iterações

FasesConcepção Elaboração Construção Transição

Inicial

Copy

right

© 2

008

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

Análise e Projeto OO com UML e Padrões| 8

Relacionamento com outras disciplinas do processo de

softwarePlanejamento e Gerenciamento – planeja e acompanha todo o desenvolvimento Requisitos – entrada para a análise e projeto do sistemaImplementação – o modelo de análise e projeto é entrada a implementaçãoGerência de Configuração e Ambiente – oferece suporte aos artefatos gerados (incluindo modelos)

Copy

right

© 2

008

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

CIn-UFPE9/45

Análise versus Projeto

Na Análise, investigamos o problema e descobrimos o QUE precisa estar no sistemaDurante o Projeto: detalhamos a Análise de modo a encontrar uma solução

computacional que satisfaça os requisitos (não funcionais) do software

estruturamos COMO o sistema será implementado

O projeto oferece uma ponte entre a Análise e a Implementação

Copy

right

© 2

008

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

CIn-UFPE10/45

Análise versus Projeto

No conceito de MDE (Model Driven Engineering) da OMG (Object Management Group) ... Análise corresponde aos modelos

independentes de plataforma (PIM – Platform Independent Model)

No projeto, os modelos podem estar vinculados a uma tecnologia particular (PSM – Platform Specific Model)

Copy

right

© 2

008

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

CIn-UFPE11/45

Análise versus Projeto

Análise Foco no problema Comportamento (caixa

preta, sem detalhes de implementação)

Estrutura geral da arquitetura do sistema

Requisitos funcionais Modelo simples

Projeto Foco em uma solução Operações e atributos Representação próxima

do código Requisitos não-funcionais

(exemplo: desempenho), além dos funcionais

Modelo complexo

Fonte: Rational

Copy

right

© 2

008

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

CIn-UFPE12/45

Modelo de Análise e Projeto

Pode ser um só artefato evoluindo de uma visão abstrata (nas

atividades de análise), para uma visão detalhada (nas atividades de projeto)

Podem ser feitos dois artefatos um modelo de análise um modelo de projeto (inicia igual à última

versão do modelo de análise e evolui independentemente)

Documentação x esforço e disciplina de manutenção

Copy

right

© 2

008

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

CIn-UFPE13/45

Estratégias de Decomposição

Funcional x DadosDecomposição Funcional Decomposição do sistema em componentes

funcionais O estado do sistema é centralizado e

compartilhado entre as funções Experiência mostrou inadequação para

estruturação de modelos de análise e projeto (as regras de negócio mudam constantemente)

Entretanto, útil para estruturar requisitos, planejar e gerenciar projetos, e realizar testes

Copy

right

© 2

008

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

CIn-UFPE14/45

Estratégias de Decomposição

Funcional x Dados Decomposição Baseada em Dados O sistema é visto como uma coleção de

entidades que interagem (ou objetos, no paradigma OO)

O estado do sistema é descentralizado Pode existir uma considerável sobreposição

entre os modelos de análise e de projeto • Na prática muitas porções do modelo de

análise podem ser reusadas no projeto Mostrou-se adequada como mecanismo de

estruturação (estabilidade de dados com relação a funções) de modelos de análise, projeto e implementação

Copy

right

© 2

008

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

CIn-UFPE15/45

Estratégias de decomposição

Projeto Top-down x Bottom-up

System level

Sub-systemlevel

Copy

right

© 2

008

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

CIn-UFPE16/45

Projeto Top-down x Bottom-up

Na prática, o projeto de grandes sistemas nunca é inteiramente top-down

Os projetistas reutilizam experiência (e componentes)

No processo, ocorre brainstorm nos dois sentidos

Copy

right

© 2

008

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

CIn-UFPE17/45

Atributos de Qualidade de um modelo de Análise ou

Projeto

A qualidade é uma propriedade relativa a prioridades específicas da organizaçãoCaracterísticas de qualidade são igualmente aplicáveis a projetos orientados a objeto ou à funçãoDois atributos importantes são coesão e acoplamento

Copy

right

© 2

008

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

CIn-UFPE18/45

O Atributo Coesão Medida da proximidade das partes (elementos) de um componente do sistema Um componente deve implementar uma única entidade lógica ou função (abstração)Importância Quando uma mudança tiver que ser feita, ela

será facilmente localizada Reuso ...

Em Orientação a objetos, cada classe deve modelar uma única entidade

Copy

right

© 2

008

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

CIn-UFPE19/45

Medida da intensidade das interconexões entre componentes do sistemaImportância Baixo acoplamento implica que mudanças em

um componente tendem a não afetar outros componentes

Reuso ...

O Atributo Acoplamento

Copy

right

© 2

008

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

CIn-UFPE20/45

Acoplamento Forte

Module A Module B

Module C Module D

Shared dataarea

Copy

right

© 2

008

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

CIn-UFPE21/45

Acoplamento Fraco

Module A

A’s data

Module B

B’s data

Module D

D’s data

Module C

C’s data

Copy

right

© 2

008

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

CIn-UFPE22/45

Sistemas orientados a objeto são, potencialmente, fracamente acoplados Geralmente não compartilham estado A comunicação é feita através de passagem de

mensagensEntretanto... uma classe está acoplada a sua superclasse

(mudanças nos atributos ou operações se propagam a todas as subclasses)

Relacionamentos cíclicos (em particular, bidirecionais) também geram forte acoplamento

Acoplamento em Orientação a Objetos

Copy

right

© 2

008

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

23

Padrões de Projeto e Arquiteturais

Projetistas experientes (re)utilizam soluções bem sucedidas no passadoPadrões sistematizam soluções, incluindo

• Nome• Problema• Solução• Conseqüência• Exemplo, ...

Durante as duas última décadas, surgiu uma “comunidade” voltada a padrões

Copy

right

© 2

008

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

Exemplo: Padrão Fachada

24

Fachada

Copy

right

© 2

008

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

25

Anti-PadrõesSão uma maneira de documentar soluções recorrentes que não tiveram sucesso

• Podem também incluir soluções re-trabalhadas que sejam efetivas

Copy

right

© 2

008

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

26

FrameworksUsualmente baseado em padrões, mas já voltados para uma linguagem de programaçãoEspecialização/instanciação Hot spots Herança

Copy

right

© 2

008

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

CIn-UFPE27/45

Planejamento do Curso

Programa, cronograma, transparências, referências, avaliação, projetos e ferramentas: http://www.cin.ufpe.br/~if718

Mas só a partir de terça-feira ...