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?
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?
Um modelo é uma visão parcial
(representação) da realidade
- 4-
Realidade
Representa
Modelos
(visões parciais)
Sistema respiratório
Esqueleto
Outros modelos:
• Muscular,
• Nervoso,
• Circulatório,
• Digestivo,
• etc.
Multiplas visões:
controle da complexidade
Plumber's
view
Architect's
view
Landlord's
view
Renter's
view
Mason's
view
Interior
Designer's
view
Carpenter's
view
System
Electrician's
view
repOf
Tax
Collector's
view
Model
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 RUP
Aspectos 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 Arquiteturais
Consolidação dos conceitos em um exemplo
construído incrementalmente
Uso de ferramentas de modelagem
Geração de esqueleto de código
Conteúdo do curso
Aná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ório
Exemplo único para ilustrar conceitos
Processos de software
Processo de software
Para ser uma atividade sistematizada,
Análise e Projeto deve ser parte de um
processo
Processo:
- O que é?
- Representação?
- Ciclo de vida?
- Execução?
- Modelos de processo
Análise e Projeto
no modelo Cascata
Análise e Projeto
no modelo Espiral
Análise e Projeto
no modelo iterativo do RUP
Fluxos de Processo
Fases
Concepção
Elaboração
Construção
Requisitos...............................
Análise e Projeto......................
Implementação........................
Testes...................................
Implantação............................
Fluxos de Suporte
Gerência de Configuração............
Planejamento e Gerenciamento.....
Inicial
Iterações
Transição
Análise e Projeto em SOA
(Service Oriented Architecture)
Requisitos
Especificação do
modelo de negócios
Modelagem do
Negócio
Analisar serviços
Planejamento
Projetar Serviços
Planejamento
Inicial
Implementação
Avaliação
Teste
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-system
level
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ção
Características de qualidade são igualmente
aplicáveis a projetos orientados a objeto ou
à função
Dois 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
O Atributo Acoplamento
Medida da intensidade das interconexões entre
componentes do sistema
Importância
- Baixo acoplamento implica que mudanças em um
-
componente tendem a não afetar outros
componentes
Reuso ...
Acoplamento Forte
Module A
Module C
Module B
Module D
Shared data
area
Acoplamento Fraco
Module A
A’s data
Module B
B’s data
Module D
D’s data
Module C
C’s data
Acoplamento em Orientação
a Objetos
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
Padrões, anti-padrões e
frameworks
Padrões de Projeto e Arquiteturais
Projetistas experientes (re)utilizam soluções
bem sucedidas no passado
Padrõ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ção
Especializaçã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 sistema
Implementação – o modelo de análise e
projeto é entrada a implementação
Gerê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