IF 718 Análise e Projeto de Sistemas Augusto Sampaio Vitor Braga (Estágio docência) Camila Sá (Monitora) Parte do material cedido pela Qualiti Software Processes

Copyright © 2008 Qualiti. Todos os direitos reservados. Copyright © 2006 Qualiti. Todos os direitos reservados. Análise e Projeto de Sistemas Objetivos: ­ Processo de Análise e Projeto no RUP ­ Processo baseado em paradigmas recentes: SOA (Software-Oriented Architecture) MDA (Model-Driven Architecture) ­ Análise comparativa contínua entre os processos ­ Técnicas de modelagem OO em UML ­ Ênfase em Padrões de Projeto e Arquiteturais ­ Consolidação dos conceitos em um exemplo construído incrementalmente ­ Uso de uma ferramenta de modelagem Análise e Projeto OO com UML e Padrões| 2

Copyright © 2008 Qualiti. Todos os direitos reservados. Copyright © 2006 Qualiti. Todos os direitos reservados. Conteúdo A&P no RUP ­ Disciplina de A&P ­ Análise de caso de uso ­ Projetar arquitetura ­ Projetar casos de uso A&P com SOA e MDA ­ Introdução ao processo ­ Especificação do modelo de negócios ­ Analisar serviços ­ Projetar serviços Análise e Projeto OO com UML e Padrões| 3 Projetar subsistemas (componentes) Projetar classes Projetar concorrrência e distribuição Projetar base de dados

Copyright © 2008 Qualiti. Todos os direitos reservados. Copyright © 2006 Qualiti. Todos os direitos reservados. Para ser uma atividade sistematizada, Análise e Projeto deve ser parte de um processo Processo: ­ O que é? ­ Representação? ­ Ciclo de vida? ­ Execução? ­ Modelos de processo Análise e Projeto OO com UML e Padrões| 4 Processo de software

Copyright © 2008 Qualiti. Todos os direitos reservados. Copyright © 2006 Qualiti. Todos os direitos reservados. CIn-UFPE 5/45 A&P no modelo Cascata Análise e Projeto

Copyright © 2008 Qualiti. Todos os direitos reservados. Copyright © 2006 Qualiti. Todos os direitos reservados. CIn-UFPE 6/45 A&P no modelo Espiral

Copyright © 2008 Qualiti. Todos os direitos reservados. Copyright © 2006 Qualiti. Todos os direitos reservados. CIn-UFPE 7/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

Copyright © 2008 Qualiti. Todos os direitos reservados. Copyright © 2006 Qualiti. Todos os direitos reservados. Análise e Projeto OO com UML e Padrões| 8 Relacionamento com outras disciplinas do processo de software Planejamento e Gerenciamento – planeja e acompanha todo o desenvolvimento Requisitos – entrada para a análise e projeto do sistema Implementação – o modelo de análise e projeto é entrada a implementação Gerência de Configuração e Ambiente – oferece suporte aos artefatos gerados (incluindo modelos)

Copyright © 2008 Qualiti. Todos os direitos reservados. Copyright © 2006 Qualiti. Todos os direitos reservados. CIn-UFPE 9/45 Aná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 (não funcionais) do software ­ estruturamos COMO o sistema será implementado O projeto oferece uma ponte entre a Análise e a Implementação

Copyright © 2008 Qualiti. Todos os direitos reservados. Copyright © 2006 Qualiti. Todos os direitos reservados. CIn-UFPE 10/45 Análise versus Projeto No conceito de MDE (Model Driven Engineering) 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)

Copyright © 2008 Qualiti. Todos os direitos reservados. Copyright © 2006 Qualiti. Todos os direitos reservados. CIn-UFPE 11/45 Aná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

Copyright © 2008 Qualiti. Todos os direitos reservados. Copyright © 2006 Qualiti. Todos os direitos reservados. CIn-UFPE 12/45 Modelo 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

Copyright © 2008 Qualiti. Todos os direitos reservados. Copyright © 2006 Qualiti. Todos os direitos reservados. CIn-UFPE 13/45 Estratégias de Decomposição Funcional 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

Copyright © 2008 Qualiti. Todos os direitos reservados. Copyright © 2006 Qualiti. Todos os direitos reservados. CIn-UFPE 14/45 Estratégias de Decomposição Funcional 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, projeto e implementação

Copyright © 2008 Qualiti. Todos os direitos reservados. Copyright © 2006 Qualiti. Todos os direitos reservados. CIn-UFPE 15/45 Estratégias de decomposição Projeto Top-down x Bottom-up

Copyright © 2008 Qualiti. Todos os direitos reservados. Copyright © 2006 Qualiti. Todos os direitos reservados. CIn-UFPE 16/45 Projeto 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

Copyright © 2008 Qualiti. Todos os direitos reservados. Copyright © 2006 Qualiti. Todos os direitos reservados. CIn-UFPE 17/45 Atributos de Qualidade de um modelo de Análise ou 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 à função Dois atributos importantes são coesão e acoplamento

Copyright © 2008 Qualiti. Todos os direitos reservados. Copyright © 2006 Qualiti. Todos os direitos reservados. CIn-UFPE 18/45 O Atributo Coesão Medida da proximidade das partes (elementos) de um componente do sistema 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... Em Orientação a objetos, cada classe deve modelar uma única entidade

Copyright © 2008 Qualiti. Todos os direitos reservados. Copyright © 2006 Qualiti. Todos os direitos reservados. CIn-UFPE 19/45 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 Acoplamento

Copyright © 2008 Qualiti. Todos os direitos reservados. Copyright © 2006 Qualiti. Todos os direitos reservados. CIn-UFPE 20/45 Acoplamento Forte

Copyright © 2008 Qualiti. Todos os direitos reservados. Copyright © 2006 Qualiti. Todos os direitos reservados. CIn-UFPE 21/45 Acoplamento Fraco

Copyright © 2008 Qualiti. Todos os direitos reservados. Copyright © 2006 Qualiti. Todos os direitos reservados. CIn-UFPE 22/45 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 Objetos

Copyright © 2008 Qualiti. Todos os direitos reservados. Copyright © 2006 Qualiti. Todos os direitos reservados. 23 Padrões de Projeto e Arquiteturais Projetistas experientes (re)utilizam soluções bem sucedidas no passado Padrões sistematizam soluções, incluindo Nome Problema Solução Conseqüência Exemplo,... Durante as duas última décadas, surgiu uma “comunidade” voltada a padrões

Copyright © 2008 Qualiti. Todos os direitos reservados. Copyright © 2006 Qualiti. Todos os direitos reservados. Exemplo: Padrão Fachada 24 Fachada

Copyright © 2008 Qualiti. Todos os direitos reservados. Copyright © 2006 Qualiti. Todos os direitos reservados. 25 Anti-Padrões São uma maneira de documentar soluções recorrentes que não tiveram sucesso Podem também incluir soluções re-trabalhadas que sejam efetivas

Copyright © 2008 Qualiti. Todos os direitos reservados. Copyright © 2006 Qualiti. Todos os direitos reservados. 26 Frameworks Usualmente baseado em padrões, mas já voltados para uma linguagem de programação Especialização/instanciação ­ Hot spots ­ Herança

Copyright © 2008 Qualiti. Todos os direitos reservados. Copyright © 2006 Qualiti. Todos os direitos reservados. CIn-UFPE 27/45 Planejamento do Curso Programa, cronograma, transparências, referências, avaliação, projetos e ferramentas: ­ ­ Mas só a partir de terça-feira...