©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE1/45 Análise e Projeto de Sistemas Augusto Sampaio Em co-autoria com Alexandre Vasconcelos Parte do material cedido pela Qualiti Software Processes

©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

©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 3/45 Planejamento do Curso n Programa, cronograma, transparências, referências, avaliação, projetos e ferramentas: 

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

©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

©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 6/45 A&P no modelo Cascata Análise e Projeto

©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 7/45 A&P no modelo Espiral

©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

©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

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

©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

©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

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

©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

©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

©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 16/45 Atividades típicas de análise e projeto

©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

©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

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

©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

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

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

©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

©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

©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

©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 26/45 Visão Funcional de um Compilador

©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 27/45 Visão Orientada a Objetos de um Compilador

©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

©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

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

©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

©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

©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 33/45 Acoplamento Forte

©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE 34/45 Acoplamento Fraco

©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

©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

©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

©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

©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

©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

©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

©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

©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

©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

©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