©2008, alexandre vasconcelos & augusto sampaio cin-ufpe1/45 análise e projeto de sistemas...
Post on 07-Apr-2016
225 Views
Preview:
TRANSCRIPT
CIn-UFPECIn-UFPE 11/45/45©2008, Alexandre Vasconcelos & Augusto Sampaio©2008, Alexandre Vasconcelos & Augusto Sampaio
Análise e Projeto de SistemasAnálise e Projeto de Sistemas
www.cin.ufpe.br/~if718www.cin.ufpe.br/~if718
Augusto SampaioAugusto Sampaio2008.22008.2
• Em co-autoria com Alexandre Vasconcelos• Parte do material cedido pela Qualiti Software Processes
CIn-UFPECIn-UFPE 22/45/45©2008, Alexandre Vasconcelos & Augusto Sampaio©2008, Alexandre Vasconcelos & Augusto Sampaio
Objetivos do CursoObjetivos do Curso
Visão geral de Análise e Projeto de Software (Orientado a Objetos)
Construção sistematizada de modelos de análise a partir de requisitos
Evolução dos modelos de análise em modelos de projeto (concorrentes e distribuídos)
Estudo detalhado da Disciplina de Análise e Projeto do RUP e modelagem com o ROSE-RT
Exemplo (projeto) único ilustrando todo o processo
CIn-UFPECIn-UFPE 33/45/45©2008, Alexandre Vasconcelos & Augusto Sampaio©2008, Alexandre Vasconcelos & Augusto Sampaio
Planejamento do CursoPlanejamento do Curso
Programa, cronograma, transparências, referências, avaliação, projetos e ferramentas:http://www.cin.ufpe.br/~if718
CIn-UFPECIn-UFPE 44/45/45©2008, Alexandre Vasconcelos & Augusto Sampaio©2008, Alexandre Vasconcelos & Augusto Sampaio
Análise e Projeto de SistemasAnálise e Projeto de Sistemas
Introdução à Análise e ao Projeto de Introdução à Análise e ao Projeto de SoftwareSoftware
CIn-UFPECIn-UFPE 55/45/45©2008, Alexandre Vasconcelos & Augusto Sampaio©2008, Alexandre Vasconcelos & Augusto Sampaio
Agenda da AulaAgenda da Aula
Análise e projeto no ciclo de vida de software
Análise versus Projeto
Exemplo de processo de análise e projeto de software
Estratégias top-down e bottom-up
Decomposição funcional e baseada em dados
Atributos de qualidade de projeto de software
CIn-UFPECIn-UFPE 66/45/45©2008, Alexandre Vasconcelos & Augusto Sampaio©2008, Alexandre Vasconcelos & Augusto Sampaio
A&P no modelo Cascata A&P no modelo Cascata
Análise e Projeto
CIn-UFPECIn-UFPE 77/45/45©2008, Alexandre Vasconcelos & Augusto Sampaio©2008, Alexandre Vasconcelos & Augusto Sampaio
A&P no modelo Espiral A&P no modelo Espiral
CIn-UFPECIn-UFPE 88/45/45©2008, Alexandre Vasconcelos & Augusto Sampaio©2008, Alexandre Vasconcelos & Augusto Sampaio
A&P no modelo iterativo do RUPA&P no modelo iterativo do RUP
Planejamento e Gerenciamento.....
Fluxos de SuporteGerê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
CIn-UFPECIn-UFPE 99/45/45©2008, Alexandre Vasconcelos & Augusto Sampaio©2008, Alexandre Vasconcelos & Augusto Sampaio
Análise versus ProjetoAnálise versus Projeto
Na Análise, investigamos o problema e descobrimos o QUE precisa estar no sistema
Durante o Projeto: detalhamos a Análise de modo a encontrar uma solução
computacional que satisfaça os requisitos do software estruturamos COMO o sistema será implementado
O projeto oferece uma ponte entre a Análise e a Implementação
CIn-UFPECIn-UFPE 1010/45/45©2008, Alexandre Vasconcelos & Augusto Sampaio©2008, Alexandre Vasconcelos & Augusto Sampaio
Análise versus ProjetoAnálise versus Projeto
No conceito de MDA (Model Driven Architecture) 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)
CIn-UFPECIn-UFPE 1111/45/45©2008, Alexandre Vasconcelos & Augusto Sampaio©2008, Alexandre Vasconcelos & Augusto Sampaio
Análise versus ProjetoAná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
CIn-UFPECIn-UFPE 1212/45/45©2008, Alexandre Vasconcelos & Augusto Sampaio©2008, Alexandre Vasconcelos & Augusto Sampaio
Modelo de Análise e ProjetoModelo 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
CIn-UFPECIn-UFPE 1313/45/45©2008, Alexandre Vasconcelos & Augusto Sampaio©2008, Alexandre Vasconcelos & Augusto Sampaio
Características da Análise/Projeto de SoftwareCaracterísticas da Análise/Projeto de Software
Processo criativo, porém deve ser sistematizado Baseado no aprendizado
Prática
Experiência, exemplos
Padrões
Deriva uma solução que satisfaz os requisitos de software
Influenciado pela implementação computacional (projeto)
CIn-UFPECIn-UFPE 1414/45/45©2008, Alexandre Vasconcelos & Augusto Sampaio©2008, Alexandre Vasconcelos & Augusto Sampaio
Principais Fases do ProcessoPrincipais Fases do Processo
Analisar o problema Analisar o problema sob diferentes ângulos Analisar/identificar abstrações (tipicamente de componentes)
a partir dos requisitos de projeto Identificar uma ou mais soluções (arquiteturais)
Avaliar possíveis soluções Escolher a mais apropriada
Detalhar as abstrações da solução Usar notações gráficas ou descritivas para especificar os
componentes do projeto Repetir este processo para cada nova abstração identificada
até o projeto estar expresso em termos primitivos
CIn-UFPECIn-UFPE 1515/45/45©2008, Alexandre Vasconcelos & Augusto Sampaio©2008, Alexandre Vasconcelos & Augusto Sampaio
Refinamento da Análise/ProjetoRefinamento da Análise/Projeto
O sistema é projetado iterativamente emdiferentes níveis de abstração
Informal Informaldesign
Moreformaldesign
Finisheddesign
designoutline
Nível crescente de estruturação
Nível decrescente de abstração
CIn-UFPECIn-UFPE 1616/45/45©2008, Alexandre Vasconcelos & Augusto Sampaio©2008, Alexandre Vasconcelos & Augusto Sampaio
Atividades típicas de análise e projetoAtividades típicas de análise e projeto
Architecturaldesign
Abstractspecificatio
n
Interfacedesign
Componentdesign
Datastructuredesign
Algorithmdesign
Systemarchitecture
Softwarespecification
Interfacespecification
Componentspecification
Datastructure
specification
Algorithmspecification
Requirementsspecification
Design activities
Design products
CIn-UFPECIn-UFPE 1717/45/45©2008, Alexandre Vasconcelos & Augusto Sampaio©2008, Alexandre Vasconcelos & Augusto Sampaio
Detalhamento das atividadesDetalhamento das atividades
Projeto de arquitetura: Identifica subsistemas e outros elementos de projeto
Especificação abstrata: Para cada subsistema (e outros elementos de projeto) é produzida uma especificação abstrata de suas funções e das restrições dentro das quais deve operar.
Projeto de interface: Especifica as interfaces entre subsistemas
CIn-UFPECIn-UFPE 1818/45/45©2008, Alexandre Vasconcelos & Augusto Sampaio©2008, Alexandre Vasconcelos & Augusto Sampaio
Detalhamento das atividadesDetalhamento das atividades
Projeto de componentes: Transforma (possivelmente decompondo) subsistemas em componentes individuais para se ajustar à arquitetura
Projeto de estrutura de dados: Projeta estrutura de dados para armazenar os dados do sistema
Projeto de algoritmos: Descreve os algoritmos a serem usados na solução do problema
CIn-UFPECIn-UFPE 1919/45/45©2008, Alexandre Vasconcelos & Augusto Sampaio©2008, Alexandre Vasconcelos & Augusto Sampaio
Notações para ModelagemNotações para Modelagem
Notações gráficas: Usadas para descrever os elementos de projeto e relacionamentos
Linguagens de descrição de programa: Baseadas em linguagens de programação, porém com mais flexibilidade para representar conceitos abstratos
Notações formais: baseadas em linguagens de especificação formal
Texto informal: Descrição em linguagem natural.
CIn-UFPECIn-UFPE 2020/45/45©2008, Alexandre Vasconcelos & Augusto Sampaio©2008, Alexandre Vasconcelos & Augusto Sampaio
Notações Gráficas Notações Gráficas para Modelagem para Modelagem
Qualquer projeto pode ser modelado como um grafo
direcionado
Nós: entidades (elementos de projeto)
Classes, Tipos, processos, subsistemas,
funções, ...
Arestas: relacionamentos
CIn-UFPECIn-UFPE 2121/45/45©2008, Alexandre Vasconcelos & Augusto Sampaio©2008, Alexandre Vasconcelos & Augusto Sampaio
Métodos Estruturados Métodos Estruturados
Características Notações para expressar o projeto Diretrizes para criar e avaliar um projeto
Exemplos Projeto Estruturado (Yourdon) JSD (Jackson Method) Booch, OMT, UML + RUP
Suporte de Ferramentas CASE Documentação padronizada Redução de custo (treinamento, manutenção) Produtividade
Mas padronização é fundamental ...
CIn-UFPECIn-UFPE 2222/45/45©2008, Alexandre Vasconcelos & Augusto Sampaio©2008, Alexandre Vasconcelos & Augusto Sampaio
Estratégias de decomposiçãoEstratégias de decomposiçãoProjeto Top-down x Bottom-upProjeto Top-down x Bottom-up
System level
Sub-systemlevel
CIn-UFPECIn-UFPE 2323/45/45©2008, Alexandre Vasconcelos & Augusto Sampaio©2008, Alexandre Vasconcelos & Augusto Sampaio
Projeto Top-down x Bottom-upProjeto 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
CIn-UFPECIn-UFPE 2424/45/45©2008, Alexandre Vasconcelos & Augusto Sampaio©2008, Alexandre Vasconcelos & Augusto Sampaio
Estratégias de DecomposiçãoEstratégias de DecomposiçãoFuncional x DadosFuncional x Dados
Decomposiçã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
CIn-UFPECIn-UFPE 2525/45/45©2008, Alexandre Vasconcelos & Augusto Sampaio©2008, Alexandre Vasconcelos & Augusto Sampaio
Estratégias de DecomposiçãoEstratégias de DecomposiçãoFuncional x DadosFuncional 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 e projeto
CIn-UFPECIn-UFPE 2626/45/45©2008, Alexandre Vasconcelos & Augusto Sampaio©2008, Alexandre Vasconcelos & Augusto Sampaio
Visão Funcional de um CompiladorVisão Funcional de um Compilador
AnalyseBuild
symboltable
Scansource
Generatecode
Symboltable
Outputerrors
Sourceprogram
Tokens Tokens Syntaxtree
Objectcode
ErrorindicatorSymbols Symbols
Errormessages
CIn-UFPECIn-UFPE 2727/45/45©2008, Alexandre Vasconcelos & Augusto Sampaio©2008, Alexandre Vasconcelos & Augusto Sampaio
Visão Orientada a Objetos de um CompiladorVisão Orientada a Objetos de um Compilador
Sourceprogram
Tokenstream
Symboltable
Syntaxtree
Grammar Errormessages
Abstractcode
Objectcode
Scan Add
Check Get
Build Print
Generate
Generate
CIn-UFPECIn-UFPE 2828/45/45©2008, Alexandre Vasconcelos & Augusto Sampaio©2008, Alexandre Vasconcelos & Augusto Sampaio
Top-down x Bottom-up e Top-down x Bottom-up e Funcional X DadosFuncional X Dados
Estratégias ortogonais (independentes) Por exemplo, uma estratégia Top-Down baseada
em dados decompõe classes usando o mecanismo de herança
Uma estratégia Bottom-Up baseada em dados usaria generalização
Uma estratégia Top-Down funcional inicia com a visão funcional do sistema e decompõe em subunidades
Uma estratégia Bottom-Up funcional reutilizaria bibliotecas de funções no projeto de funções mais complexas
CIn-UFPECIn-UFPE 2929/45/45©2008, Alexandre Vasconcelos & Augusto Sampaio©2008, Alexandre Vasconcelos & Augusto Sampaio
Atributos de Qualidade de ProjetoAtributos de Qualidade de Projeto
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 a função
Os atributos discutidos aqui estão relacionados principalmente a facilidades de evolução e manutenção de um projeto
CIn-UFPECIn-UFPE 3030/45/45©2008, Alexandre Vasconcelos & Augusto Sampaio©2008, Alexandre Vasconcelos & Augusto Sampaio
O Atributo Coesão O Atributo Coesão
Medida da proximidade das partes (elementos) de um sub-componente
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 ...
CIn-UFPECIn-UFPE 3131/45/45©2008, Alexandre Vasconcelos & Augusto Sampaio©2008, Alexandre Vasconcelos & Augusto Sampaio
Coesão em Orientação a ObjetosCoesão em Orientação a Objetos
Classes que modelam mais de uma entidade são fracamente coesas
Herança de atributos de uma superclasse enfraquece a coesão Para entender a estrutura de uma classe, a superclasse e a
própria classe precisam ser examinadas
CIn-UFPECIn-UFPE 3232/45/45©2008, Alexandre Vasconcelos & Augusto Sampaio©2008, Alexandre Vasconcelos & Augusto Sampaio
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 ...
O Atributo AcoplamentoO Atributo Acoplamento
CIn-UFPECIn-UFPE 3333/45/45©2008, Alexandre Vasconcelos & Augusto Sampaio©2008, Alexandre Vasconcelos & Augusto Sampaio
Acoplamento ForteAcoplamento Forte
Module A Module B
Module C Module D
Shared dataarea
CIn-UFPECIn-UFPE 3434/45/45©2008, Alexandre Vasconcelos & Augusto Sampaio©2008, Alexandre Vasconcelos & Augusto Sampaio
Acoplamento FracoAcoplamento Fraco
Module A
A’s data
Module B
B’s data
Module D
D’s data
Module C
C’s data
CIn-UFPECIn-UFPE 3535/45/45©2008, Alexandre Vasconcelos & Augusto Sampaio©2008, Alexandre Vasconcelos & Augusto Sampaio
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 ObjetosAcoplamento em Orientação a Objetos
CIn-UFPECIn-UFPE 3636/45/45©2008, Alexandre Vasconcelos & Augusto Sampaio©2008, Alexandre Vasconcelos & Augusto Sampaio
Relacionado a várias características do componente Acoplamento e Coesão. Cada componente modela
(completamente) uma única abstração?
Nomes. São usados nomes sugestivos?
Documentação. O projeto está bem documentado?
Complexidade. Algoritmos complexos são utilizados?
Padrões. Soluções conhecidas são utilizadas?
O Atributo EntendimentoO Atributo Entendimento
CIn-UFPECIn-UFPE 3737/45/45©2008, Alexandre Vasconcelos & Augusto Sampaio©2008, Alexandre Vasconcelos & Augusto Sampaio
Medida da facilidade de mudança nos componentes Alguns fatores relevantes
Componentes fracamente acoplados Componentes fortemente coesos Boa documentação
O Atributo AdaptabilidadeO Atributo Adaptabilidade
CIn-UFPECIn-UFPE 3838/45/45©2008, Alexandre Vasconcelos & Augusto Sampaio©2008, Alexandre Vasconcelos & Augusto Sampaio
Herança aumenta a adaptabilidade Componentes podem ser adaptados sem mudanças através da
definição de uma subclasse que é efetivamente modificada
Por outro lado ... O aumento da profundidade da hierarquia a torna mais complexa
Adaptabilidade em Orientação a ObjetosAdaptabilidade em Orientação a Objetos
CIn-UFPECIn-UFPE 3939/45/45©2008, Alexandre Vasconcelos & Augusto Sampaio©2008, Alexandre Vasconcelos & Augusto Sampaio
Fatores que Influenciam o ProjetoFatores que Influenciam o Projeto
Funcionalidade Performance - tempo de resposta, tempo total de execução Eficiência - uso eficiente do dispositivo de armazenamento
e do hardware Portabilidade - funcionar em novas plataformas Segurança Disponibilidade - disponível quando requerido Robustez Generalidade Usabilidade Reusabilidade
CIn-UFPECIn-UFPE 4040/45/45©2008, Alexandre Vasconcelos & Augusto Sampaio©2008, Alexandre Vasconcelos & Augusto Sampaio
Compromissos de ProjetoCompromissos de Projeto
É impossível alcançar todos os objetivos Performance X Portabilidade Performance X Generalidade
CIn-UFPECIn-UFPE 4141/45/45©2008, Alexandre Vasconcelos & Augusto Sampaio©2008, Alexandre Vasconcelos & Augusto Sampaio
Compromissos de ProjetoCompromissos de Projeto
Projeto acontece no contexto do mundo real Portanto, deve levar em consideração:
Investimento custos de projeto e execução
Prazos bom projeto leva mais tempo Os resultados obtidos a partir do sistema implementado
devem acontecer na data apropriada Integração com outros sistemas Habilidades
da equipe de projeto e usuários Padrões
internos e externos
CIn-UFPECIn-UFPE 4242/45/45©2008, Alexandre Vasconcelos & Augusto Sampaio©2008, Alexandre Vasconcelos & Augusto Sampaio
Medindo a Eficiência do ProjetoMedindo a Eficiência do Projeto
Sucesso deve ser mostrado em termos de objetivos mensuráveis Funcionalidade - presente ou ausente Eficiência
tempo de resposta Portabilidade
plataformas
CIn-UFPECIn-UFPE 4343/45/45©2008, Alexandre Vasconcelos & Augusto Sampaio©2008, Alexandre Vasconcelos & Augusto Sampaio
Disponibilidade ex. Sistema funcionando 98% do tempo.
Robustez ex. 90% das falhas são recuperadas em uma hora
Usabilidade tempo para aprender a usar o sistema freqüência de erros tempo para recuperar de erros específicos tempo para re-aprender o sistema depois de um período sem
usá-lo atitude e satisfação do usuário (questionário)
Medindo a Eficiência do ProjetoMedindo a Eficiência do Projeto
CIn-UFPECIn-UFPE 4444/45/45©2008, Alexandre Vasconcelos & Augusto Sampaio©2008, Alexandre Vasconcelos & Augusto Sampaio
Projeto é um processo de engenharia (modelagem), mas exige criatividade
Atividades de projeto incluem Projeto de arquitetura Especificação de sistema Projeto de interface Projeto de componentes Projeto de estrutura de dados Projeto de algoritmos
Pontos PrincipaisPontos Principais
CIn-UFPECIn-UFPE 4545/45/45©2008, Alexandre Vasconcelos & Augusto Sampaio©2008, Alexandre Vasconcelos & Augusto Sampaio
Pontos PrincipaisPontos Principais
Decomposição funcional considera o sistema como um conjunto de unidades funcionais (estado centralizado) Importante para definir escopo, planejar, gerenciar e testar
Orientação a objetos considera o sistema como uma coleção de objetos (estado descentralizado) Importante na modelagem estrutural e de dados
Projetistas devem procurar produzir sistemas Fortemente coesos Fracamente acoplados
top related