IF718 Análise e Projeto de Sistemas

1. IF718Análise e Projeto de Sistemas Augusto Sampaio - acas Pedro Antonino – prga2 (Estágio docência) 2013.2 • Parte do material cedido pela Qualiti Software Processes

2. Motivação

3. Essência de Análise e Projeto: construção de modelos • O que é um modelo? • Por que construir modelos? • Quantos modelos construir para: • capturar os elementos do problema • Representar diferentes níveis de abstração • Em Engenharia de Software • O que é Desenvolvimento Baseado em Modelos?

4. Um modelo é uma visão parcial (representação) da realidade Modelos (visões parciais) Representa Realidade Sistema respiratório • Outros modelos: • Muscular, • Nervoso, • Circulatório, • Digestivo, • etc. Esqueleto

5. Multiplas visões: controle da complexidade System Model repOf Plumber's view Architect's view Landlord's view Renter's view Mason's view Interior Designer's view Carpenter's view Tax Collector's view Electrician's view

6. Desenvolvimento baseado em modelos • A principal motivação é aumentar a produtividade: • Independência de tecnologia • Reutilização • Automação • Aumentar o nível de abstração • Foco no modelo, não no código • “O modelo é o código ...” • Processos são essenciais para sistematizar o desenvolvimento

7. O grande desafio ...

8. Vídeo: Modeling Through the Ages

9. Objetivos do curso • Processo de Análise e Projeto no RUP • Aspectos de modelagem de paradigmasrecentes: • SOA (Software-Oriented Architecture) • MDD (Model-Driven Development) • 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 ferramentas de modelagem • Geração de esqueleto de código

10. Conteúdo do curso • Análise/projeto no RUP • Disciplina de A&P • Análise de caso de uso • Projetararquitetura • Projetarcasos de uso • Considerando SOA e MDD • Modelo de negócio • Analisar serviços • Projetar serviços • Padrões de projeto e arquiteturais • Projetar subsistemas (componentes) • Projetar classes • Projetar concorrrência e distribuição • Projetar base de dados Aulas conceituais e prática em laboratório Exemplo único para ilustrar conceitos

11. Processos de software

12. Processo de software • 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

13. Análise e Projeto no modelo Cascata

14. Análise e Projeto no modelo Espiral

15. Análise e Projeto no modelo iterativo do RUP Fases Fluxos de Processo Transição Concepção Elaboração Construção Requisitos............................... Análise e Projeto...................... Implementação........................ Testes................................... Implantação............................ Fluxos de Suporte Gerência de Configuração............ Planejamento e Gerenciamento..... Inicial Iterações

16. Análise e Projeto em SOA(Service Oriented Architecture) Requisitos Especificação do modelo de negócios Modelagem do Negócio Analisar serviços Planejamento Projetar Serviços Planejamento Inicial Implementação Avaliação Teste

17. Análise versus Projeto

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

19. Análise versus Projeto • Em MDD (Model Driven Development) 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)

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

21. Estratégias de decomposição

22. Estratégias de DecomposiçãoFuncional x Dados • Decomposição Funcional • Decomposição do sistema em componentes funcionais (exemplo: casos de uso) • 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

23. Estratégias de DecomposiçãoFuncional 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 • 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

24. Estratégias de decomposiçãoProjeto Top-down x Bottom-up

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

26. Atributos de qualidade de modelos de análise e projeto

27. Atributos de Qualidade • 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

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

29. O Atributo Acoplamento • 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 ...

30. Acoplamento Forte

31. Acoplamento Fraco

32. Acoplamento em Orientação a Objetos • 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

33. Padrões, anti-padrões e frameworks

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

35. Exemplo: Padrão Fachada Fachada

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

37. Frameworks • Usualmente baseado em padrões, mas já voltados para uma linguagem de programação • Especialização/instanciação • Hot spots • Herança

38. 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)

39. Planejamento do Curso • Programa, cronograma, transparências, referências, avaliação, projetos e ferramentas: • http://www.cin.ufpe.br/~if718 • MAS SÓ DEPOIS DA QUINTA-FEIRA