IF718Análise e Projeto de Sistemas

Augusto Sampaio - acasPedro Antonino – prga2 (Estágio

docência)

2013.2

• Parte do material cedido pela Qualiti Software Processes

Motivação

O que é um modelo?Por que construir modelos?Quantos modelos construir para: capturar os elementos do problema

Representar diferentes níveis de abstração

Em Engenharia de Software O que é Desenvolvimento Baseado em

Modelos?

Essência de Análise e Projeto: construção de

modelos

- 4 -

Sistema respiratório

Outros modelos:•Muscular,•Nervoso,•Circulatório,•Digestivo,•etc.

Esqueleto

RealidadeModelos (visões parciais)

Representa

Um modelo é uma visão parcial (representação) da

realidade

Multiplas visões: controle da complexidade

Carpenter'sview

Mason'sview

Plumber'sview

Architect'sview

Landlord'sview

Renter'sview

InteriorDesigner'sview

TaxCollector'sview

Electrician'sview

ModelrepOfSystem

Desenvolvimento baseado em modelos

A principal motivação é aumentar a produtividade: Independência de tecnologia

Reutilização

Automação

Aumentar o nível de abstração Foco no modelo, não no código

“O modelo é o código ...”

Processos são essenciais para sistematizar o desenvolvimento

O grande desafio ...

Vídeo: Modeling Through the Ages

Objetivos do curso

Processo de Análise e Projeto no RUPAspectos de modelagem de paradigmas recentes:

SOA (Software-Oriented Architecture)

MDD (Model-Driven Development)

Técnicas de modelagem OO em UMLÊnfase em Padrões de Projeto e ArquiteturaisConsolidação dos conceitos em um exemplo construído incrementalmenteUso de ferramentas de modelagemGeração de esqueleto de código

Conteúdo do cursoAnálise/projeto no RUP Disciplina de A&P

Análise de caso de uso

Projetar arquitetura

Projetar casos de uso

Considerando SOA e MDD Modelo de negócio

Analisar serviços

Projetar serviços

• Padrões de projeto e arquiteturais • Projetar subsistemas (componentes)

• Projetar classes• Projetar concorrrência e distribuição

• Projetar base de dados

Aulas conceituais e prática em laboratórioExemplo único para ilustrar conceitos

Processos de software

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

Processo de software

Análise e Projeto no modelo Cascata

Análise e Projeto no modelo Espiral

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

Análise e Projeto em SOA(Service Oriented Architecture)

Especificação do modelo de negócios

Analisar serviços

Implementação

TesteAvaliação

PlanejamentoInicial

Planejamento

Modelagem do Negócio

Requisitos

Projetar Serviços

Análise versus Projeto

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

Análise versus Projeto

Em MDD (Model Driven Development) 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)

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

Estratégias de decomposição

Estratégias de Decomposição

Funcional x Dados

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

funcionais (exemplo: casos de uso)

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

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

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

Estratégias de decomposição

Projeto Top-down x Bottom-up

System level

Sub-systemlevel

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

Atributos de qualidade de modelos de análise e

projeto

Atributos de Qualidade

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

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

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

Acoplamento Forte

Module A Module B

Module C Module D

Shared dataarea

Acoplamento Fraco

Module A

A’s data

Module B

B’s data

Module D

D’s data

Module C

C’s data

Sistemas orientados a objeto são, potencialmente, fracamente acoplados

Geralmente não compartilham estado

A comunicação é feita através de passagem de mensagens

Entretanto...

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

Padrões, anti-padrões e frameworks

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

Exemplo: Padrão Fachada

Fachada

Anti-Padrões

São uma maneira de documentar soluções recorrentes que não tiveram sucesso

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

Frameworks

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

Herança

Relacionamento com outras disciplinas do processo de

software

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

Planejamento do Curso

Programa, cronograma, transparências, referências, avaliação, projetos e ferramentas:

http://www.cin.ufpe.br/~if718

MAS SÓ DEPOIS DA QUINTA-FEIRA