©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE1/38 Análise e Projeto de Sistemas Introdução à Análise e ao Projeto de Software

©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

©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

©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)

©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

©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]

©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

©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

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 9/38 Fases do Processo de Projeto

©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

©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

©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.

©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

©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...

©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

©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

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 17/38 Estratégias de decomposição Projeto Top-down x Bottom-up

©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

©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

©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

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 21/38 Visão Funcional de um Compilador

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 22/38 Visão Orientada a Objetos de um Compilador

©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

©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

©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

©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

©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

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 28/38 Acoplamento Forte

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 29/38 Acoplamento Fraco

©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

©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

©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

©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

©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

©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

©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

©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

©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

©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

©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