IF718 Análise e Projeto de Sistemas Augusto Sampaio - acas Vitor Braga - vtb (Estágio docência)...
-
Upload
andre-aveiro-estrela -
Category
Documents
-
view
214 -
download
0
Transcript of IF718 Análise e Projeto de Sistemas Augusto Sampaio - acas Vitor Braga - vtb (Estágio docência)...
IF718Análise e Projeto de Sistemas
Augusto Sampaio - acasVitor Braga - vtb (Estágio
docência) Diogo Peixoto - dcp (Monitor)
2011.2
• Parte do material cedido pela Qualiti Software Processes
Motivação
Análise,e Projeto OO com UML para Sistemas RT| 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.
Essência de Análise e Projeto: construção de
modelosO 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?
Análise,e Projeto OO com UML para Sistemas RT| 3
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.
- 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
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.
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
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.
Desenvolvimento baseado em modelos
A principal motivação é aumentar a produtividade: Reutilização Independência de tecnologia Automação
Aumentar o nível de abstração Foco no modelo, não no código
“The model is the code”Processos são essenciais para sistematizar o desenvolvimento
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.
O grande desafio ...
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.
Vídeo: Modeling Through the Ages
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.
Objetivos do cursoProcesso 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 modelagem
Análise e Projeto OO com UML e Padrões| 9
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údo do cursoA&P 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
Análise e Projeto OO com UML e Padrões| 10
• 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
Análise,e Projeto OO com UML para Sistemas RT| 11
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| 12
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-UFPE13/45
Análise e Projeto 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-UFPE14/45
Análise e Projeto 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-UFPE15/45
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
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 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,e Projeto OO com UML para Sistemas RT| 17
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
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-UFPE19/45
Análise versus Projeto
No conceito de 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)
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
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-UFPE21/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
Estratégias de decomposição
Análise,e Projeto OO com UML para Sistemas RT| 22
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-UFPE23/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-UFPE24/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-UFPE25/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-UFPE26/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
Atributos de qualidade de modelos de análise e
projeto
Análise,e Projeto OO com UML para Sistemas RT| 27
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-UFPE28/45
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
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-UFPE29/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-UFPE30/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-UFPE31/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-UFPE32/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-UFPE33/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
Padrões, anti-padrões e frameworks
Análise,e Projeto OO com UML para Sistemas RT| 34
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.
35
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
36
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.
37
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.
38
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.
Análise e Projeto OO com UML e Padrões| 39
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-UFPE40/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 quinta-feira ...