Upload
kamin
View
43
Download
3
Embed Size (px)
DESCRIPTION
IF718 Análise e Projeto de Sistemas. Augusto Sampaio - acas Pedro Antonino – prga2 (Estágio docência) 2013.2. Parte do material cedido pela Qualiti Software Processes. Motivação. Essência de Análise e Projeto: construção de modelos. O que é um modelo? Por que construir modelos? - PowerPoint PPT Presentation
Citation preview
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