Carregar apresentação
A apresentação está carregando. Por favor, espere
PublicouJuliana Fraga Bardini Alterado mais de 8 anos atrás
1
©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE1/45 Análise e Projeto de Sistemas www.cin.ufpe.br/~if718 Augusto Sampaio 2008.2 Em co-autoria com Alexandre Vasconcelos Parte do material cedido pela Qualiti Software Processes
2
©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 2/45 Objetivos do Curso n Visão geral de Análise e Projeto de Software (Orientado a Objetos) n Construção sistematizada de modelos de análise a partir de requisitos n Evolução dos modelos de análise em modelos de projeto (concorrentes e distribuídos) n Estudo detalhado da Disciplina de Análise e Projeto do RUP e modelagem com o ROSE-RT n Exemplo (projeto) único ilustrando todo o processo
3
©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 3/45 Planejamento do Curso n Programa, cronograma, transparências, referências, avaliação, projetos e ferramentas: http://www.cin.ufpe.br/~if718 http://www.cin.ufpe.br/~if718
4
©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE4/45 Análise e Projeto de Sistemas Introdução à Análise e ao Projeto de Software
5
©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 5/45 Agenda da Aula n Análise e projeto no ciclo de vida de software n Análise versus Projeto n Exemplo de processo de análise e projeto de software n Estratégias top-down e bottom-up n Decomposição funcional e baseada em dados n Atributos de qualidade de projeto de software
6
©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 6/45 A&P no modelo Cascata Análise e Projeto
7
©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 7/45 A&P no modelo Espiral
8
©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 8/45 A&P 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 Fases Concepção ElaboraçãoConstrução Transição Inicial
9
©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 9/45 Análise versus Projeto n Na Análise, investigamos o problema e descobrimos o QUE precisa estar no sistema n 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 n O projeto oferece uma ponte entre a Análise e a Implementação
10
©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 10/45 Análise versus Projeto n 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)
11
©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 11/45 Análise versus Projeto n Análise Foco no problema Comportamento (caixa preta, sem detalhes de implementação) Estrutura geral da arquitetura do sistema Requisitos funcionais Modelo simples n 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
12
©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 12/45 Modelo de Análise e Projeto n 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) n 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) n Documentação x esforço e disciplina de manutenção
13
©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 13/45 Características da Análise/Projeto de Software n Processo criativo, porém deve ser sistematizado n Baseado no aprendizado Prática Experiência, exemplos Padrões n Deriva uma solução que satisfaz os requisitos de software n Influenciado pela implementação computacional (projeto)
14
©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 14/45 Principais Fases do Processo n Analisar o problema Analisar o problema sob diferentes ângulos Analisar/identificar abstrações (tipicamente de componentes) a partir dos requisitos de projeto n Identificar uma ou mais soluções (arquiteturais) Avaliar possíveis soluções Escolher a mais apropriada n 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
15
©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 15/45 Refinamento da Análise/Projeto O sistema é projetado iterativamente em diferentes níveis de abstração Informal Informal design More formal design Finished outline Nível crescente de estruturação Nível decrescente de abstração
16
©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 16/45 Atividades típicas de análise e projeto
17
©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 17/45 Detalhamento das atividades n Projeto de arquitetura: Identifica subsistemas e outros elementos de projeto n 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. n Projeto de interface: Especifica as interfaces entre subsistemas
18
©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 18/45 Detalhamento das atividades n Projeto de componentes: Transforma (possivelmente decompondo) subsistemas em componentes individuais para se ajustar à arquitetura n Projeto de estrutura de dados: Projeta estrutura de dados para armazenar os dados do sistema n Projeto de algoritmos: Descreve os algoritmos a serem usados na solução do problema
19
©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 19/45 Notações para Modelagem n Notações gráficas: Usadas para descrever os elementos de projeto e relacionamentos n Linguagens de descrição de programa: Baseadas em linguagens de programação, porém com mais flexibilidade para representar conceitos abstratos n Notações formais: baseadas em linguagens de especificação formal n Texto informal: Descrição em linguagem natural.
20
©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 20/45 Notações Gráficas para Modelagem n Qualquer projeto pode ser modelado como um grafo direcionado Nós: entidades (elementos de projeto) èClasses, Tipos, processos, subsistemas, funções,... Arestas: relacionamentos
21
©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 21/45 Métodos Estruturados n Características Notações para expressar o projeto Diretrizes para criar e avaliar um projeto n Exemplos Projeto Estruturado (Yourdon) JSD (Jackson Method) Booch, OMT, UML + RUP n Suporte de Ferramentas CASE Documentação padronizada Redução de custo (treinamento, manutenção) Produtividade n Mas padronização é fundamental...
22
©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 22/45 Estratégias de decomposição Projeto Top-down x Bottom-up
23
©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 23/45 Projeto Top-down x Bottom-up n 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
24
©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 24/45 Estratégias de Decomposição Funcional x Dados n 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
25
©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 25/45 Estratégias de Decomposição Funcional x Dados n 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
26
©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 26/45 Visão Funcional de um Compilador
27
©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 27/45 Visão Orientada a Objetos de um Compilador
28
©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 28/45 Top-down x Bottom-up e Funcional X Dados n 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
29
©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 29/45 Atributos de Qualidade de Projeto n A qualidade é uma propriedade relativa a prioridades específicas da organização n Características de qualidade são igualmente aplicáveis a projetos orientados a objeto ou a função n Os atributos discutidos aqui estão relacionados principalmente a facilidades de evolução e manutenção de um projeto
30
©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 30/45 O Atributo Coesão n Medida da proximidade das partes (elementos) de um sub-componente n Um componente deve implementar uma única entidade lógica ou função (abstração) n Importância Quando uma mudança tiver que ser feita, ela será facilmente localizada Reuso...
31
©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 31/45 Coesão em Orientação a Objetos n Classes que modelam mais de uma entidade são fracamente coesas n 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
32
©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 32/45 n Medida da intensidade das interconexões entre componentes do sistema n Importância Baixo acoplamento implica que mudanças em um componente tendem a não afetar outros componentes Reuso... O Atributo Acoplamento
33
©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 33/45 Acoplamento Forte
34
©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 34/45 Acoplamento Fraco
35
©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 35/45 n Sistemas orientados a objeto são, potencialmente, fracamente acoplados Geralmente não compartilham estado A comunicação é feita através de passagem de mensagens n 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
36
©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 36/45 n 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 Entendimento
37
©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 37/45 n Medida da facilidade de mudança nos componentes n Alguns fatores relevantes Componentes fracamente acoplados Componentes fortemente coesos Boa documentação O Atributo Adaptabilidade
38
©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 38/45 n Herança aumenta a adaptabilidade Componentes podem ser adaptados sem mudanças através da definição de uma subclasse que é efetivamente modificada n Por outro lado... O aumento da profundidade da hierarquia a torna mais complexa Adaptabilidade em Orientação a Objetos
39
©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 39/45 Fatores que Influenciam o Projeto n Funcionalidade n Performance - tempo de resposta, tempo total de execução n Eficiência - uso eficiente do dispositivo de armazenamento e do hardware n Portabilidade - funcionar em novas plataformas n Segurança n Disponibilidade - disponível quando requerido n Robustez n Generalidade n Usabilidade n Reusabilidade
40
©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 40/45 Compromissos de Projeto n É impossível alcançar todos os objetivos Performance X Portabilidade Performance X Generalidade
41
©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 41/45 Compromissos de Projeto n Projeto acontece no contexto do mundo real n 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
42
©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 42/45 Medindo a Eficiência do Projeto n Sucesso deve ser mostrado em termos de objetivos mensuráveis Funcionalidade - presente ou ausente Eficiência ètempo de resposta Portabilidade èplataformas
43
©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 43/45 n Disponibilidade ex. Sistema funcionando 98% do tempo. n Robustez ex. 90% das falhas são recuperadas em uma hora n 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 Projeto
44
©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 44/45 n Projeto é um processo de engenharia (modelagem), mas exige criatividade n 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 Principais
45
©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 45/45 Pontos Principais n Decomposição funcional considera o sistema como um conjunto de unidades funcionais (estado centralizado) Importante para definir escopo, planejar, gerenciar e testar n Orientação a objetos considera o sistema como uma coleção de objetos (estado descentralizado) Importante na modelagem estrutural e de dados n Projetistas devem procurar produzir sistemas Fortemente coesos Fracamente acoplados
Apresentações semelhantes
© 2024 SlidePlayer.com.br Inc.
All rights reserved.