Carregar apresentação
A apresentação está carregando. Por favor, espere
PublicouIvan Bergler Vieira Alterado mais de 8 anos atrás
1
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE1/38 Análise e Projeto de Sistemas Introdução à Análise e ao Projeto de Software
2
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 2/38 Objetivos da Aula n Discutir as diferenças entre Análise e Projeto n Introduzir o processo de projeto de software n Descrever os diferentes estágios deste processo n Discutir as estratégias de projeto de software funcional e orientada a objeto n Discutir alguns atributos de qualidade de projeto de software
3
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 3/38 Análise x 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
4
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 4/38 Análise x 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)
5
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 5/38 Características do Projeto de Software n Processo criativo 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 n Deve incluir detalhes (baixo nível) que foram ignorados no modelo de análise
6
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 6/38 Definição de Projeto de Software “Após a análise do problema, você deve decidir a abordagem do projeto. O projeto do sistema é uma estratégia de alto nível para resolução de problemas e construções de soluções. O projeto do sistema inclui decisões sobre a organização do sistema em termos de subsistemas, a evolução de subsistemas para componentes de software e hardware, bem como as principais decisões conceituais e políticas.” [Rumbaugh]
7
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 7/38 Principais Fases do Processo de Projeto n Analisar o problema Olhar para o problema de diferentes ângulos Descobrir os requisitos de projeto n Identificar uma ou mais soluções Avaliar possíveis soluções Escolher a mais apropriada n Descrever as abstrações da solução Usar notações gráficas ou descritivas para especificar os componentes do projeto Repetir este processo para cada abstração identificada até o projeto estar expresso em termos primitivos
8
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 8/38 Refinamento de Projeto O sistema é projetado iterativamente em diferentes níveis de abstração Informal Informal design More formal design Finished outline
9
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 9/38 Fases do Processo de Projeto
10
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 10/38 Fases do Processo de Projeto 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
11
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 11/38 Fases do Processo de Projeto 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
12
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 12/38 Notações para Descrição de Projeto n Notações gráficas: Usadas para descrever os elementos de projeto e os relacionamentos entre estes. n Linguagens de descrição de programa: Baseadas em linguagens de programação, porém com mais flexibilidade para representar conceitos abstratos. n Texto informal: Descrição em linguagem natural.
13
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 13/38 Notações Gráficas para Modelagem de Projeto n Qualquer projeto pode ser modelado como um grafo direcionado Nós: entidades (elementos de projeto) èClasses, Tipos, processos, subsistemas, funções,... Arestas: relacionamentos
14
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 14/38 Métodos Estruturados de Projeto 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...
15
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 15/38 Tipos de Modelos nos Métodos Estruturados n Modelo de fluxo de dados: transformação de dados n Modelo estrutural: elementos do sistema e suas interações Modelo entidade-relacionamento: estrutura lógica dos dados Modelo de herança e composição de objetos, se o método for orientado a objetos n Modelos complementares: diagrama de estados, dicionário de dados
16
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 16/38 Deficiências dos Métodos Estruturados n Existem diretrizes e não métodos no sentido matemático. Projetistas diferentes criam projetos bastante diferentes n Não oferecem mecanismos de garantia de consistência entre os diversos modelos gerados n Uma alternativa é complementar estes métodos com uma notação mais precisa para descrever comportamento Exemplo: UML + OCL
17
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 17/38 Estratégias de decomposição Projeto Top-down x Bottom-up
18
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 18/38 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
19
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 19/38 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
20
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 20/38 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
21
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 21/38 Visão Funcional de um Compilador
22
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 22/38 Visão Orientada a Objetos de um Compilador
23
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 23/38 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
24
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 24/38 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
25
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 25/38 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 n Importância Quando uma mudança tiver que ser feita, ela será facilmente localizada
26
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 26/38 Coesão em Orientação a Objetos 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
27
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 27/38 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 O Atributo Acoplamento
28
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 28/38 Acoplamento Forte
29
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 29/38 Acoplamento Fraco
30
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 30/38 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
31
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 31/38 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
32
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 32/38 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
33
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 33/38 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
34
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 34/38 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
35
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 35/38 Compromissos de Projeto n É impossível alcançar todos os objetivos Performance X Portabilidade Performance X Generalidade
36
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 36/38 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
37
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 37/38 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
38
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 38/38 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
39
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 39/38 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
40
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 40/38 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.