Analise e Projeto Orientado a Objetos – APS II

1. Analise e Projeto Orientado a Objetos – APS II Prof. Isledna

2. Objetivos • Apresentar um método para análise e projeto de sistemas orientado a objetos, baseado na abordagem do Processo Unificado (PU).

3. O que vamos fazer ? • Usaremos a linguagem UML (Unified Modeling Language) para criar modelos (de análise e de projeto) • Um modelo é uma representação abstrata dos aspectos essenciais de um sistema • O que é "essencial" depende do momento da modelagem • A UML usa uma representação principalmente gráfica para representar os modelos • UML é muito popular hoje em dia para modelar sistemas

4. O que vamos fazer ? • Usaremos Design Patterns (padrões de projeto) para mostrar soluções abstratas para problemas que surgem frequentemente durante o projeto de sistemas OO • Os patterns tratarão principalmente de: • Como atribuir responsabilidades a objetos (uma das atividades mais difícil no desenvolvimento de sistemas OO) • Como separar o que muda do que é constante numa determinada situação, com o objetivo de ganhar flexibilidade • Para evitar "o efeito gelatina"

5. O que vamos fazer ? • Explicaremos e seguiremos um processo de desenvolvimento que mostra claramente quais são as etapas a seguir para produzir software de qualidade • Veremos também quais artefatos devem ser produzidos na várias fases e etapas do processo

6. O que é Análise e Projeto ? • Diferenças entre análise e projeto: tem mais do que uma definição empregada • Primeira alternativa: • A análise modela o problema e consiste das atividades necessárias para entender o domínio do problema (o que deve ser feito). É uma atividade de investigação. • O projeto modela a solução e consiste das atividades de criação (como pode ser feito)

8. O que é Análise e Projeto ? • Segunda alternativa: • A análise consiste de todas as atividades feitas com ou para o conhecimento do cliente. A informação produzida é aquela que o cliente deve discutir e aprovar • O projeto inclui as atividades que resultam em informação que interessa apenas ao programador • Com essa definição, a análise invade um pouco o "lado da solução", pois o cliente deve discutir alguns tipos de interações que ocorrerão na interface do usuário, etc.

10. O que é Análise e Projeto ? • Nesta disciplina, adotaremos a segunda alternativa • associar as palavras "análise" e "projeto" aos artefatos (deliverables) entregues nos final de cada fase • Um modelo de análise deve ser aprovado pelo cliente e pode incluir alguma (pequena) discussão da solução, principalmente no que diz respeito à interface com usuário, etc.

11. Outros pontos a serem abordados: • As fases de requisitos • Implementação e • Testes

13. O que é Análise e Projeto Orientados a Objeto ? • A perspectiva empregada é de objetos (coisas, conceitos ou entidades) • Durante a Análise OO, a ênfase está em achar e descrever objetos (ou conceitos) no domínio do problema • Por exemplo, num sistema de informação para uma biblioteca, alguns dos conceitos são Livro, Biblioteca, Usuário. • Tais objetos podem ter atributos e responsabilidades

14. Durante o projeto orientado a objeto, a ênfase está em achar objetos lógicos de software que poderão ser eventualmente implementados usando uma linguagem de programação OO • Tais objetos pode ter atributos e métodos • Durante a construção (programação OO), os objetos do projeto são implementados e testados

16. APOO versus AP Estruturada • Com ambas as técnicas, usa-se decomposição • A decomposição é por função ou processo

18. Introdução a Análise e projeto • Motivação • Sociedade dependente de sistemas • Anos atrás: bancos, empresas de grande porte • Hoje: celulares, aplicações distribuídas, Internet • Pressão sobre desenvolvedores: rapidez, confiabilidade, preço, etc.

19. Cenário atual do desenvolvimento • Dificuldade de entendimento dos requisitos • Dificuldade de manutenção • Proliferação de tecnologias • Baixa qualidade

20. Melhores soluções existentes • Utilizar modelos mais baratos para visualizar soluções • Utilizar soluções que já foram utilizadas com sucesso • Melhorar a comunicação na equipe • Orientação a objetos • Representa o mundo real em termos de objetos

21. Processo de Desenvolvimento • Uma linguagem de modelagem não é suficiente • Precisamos também de um processo de desenvolvimento • O que é um processo de desenvolvimento? • Define quem faz o que, quando e como, para atingir um certo alvo

22. Exemplos • Modelo em Cascata • Modelo de Prototipagem • Modelo Evolucionário • Desenvolvimento Baseado em Componentes • Modelo de Métodos formais • Programação Extrema • Processo Unificado

23. Processo unificado (PU) • Linguagem de modelagem + processo de desenvolvimento = método (ou metodologia) de desenvolvimento • Linguagem de Modelagem = UML

24. Princípios Básicos do PU • Desenvolvimento iterativo • Baseado em casos de uso • Centrado na arquitetura

25. Desenvolvimento Iterativo • O desenvolvimento de um software é dividido em vários ciclos de iteração, cada qual produzindo um sistema testado, integrado e executável. • Em cada ciclo ocorrem as atividades de análise de requisitos, projeto, implementação e teste, bem como a integração dos artefatos produzidos com os artefatos já existentes.

26. Desenvolvimento Iterativo • Planejar quantos ciclos de desenvolvimento serão necessários para alcançar os objetivos do sistema. • As partes mais importantes devem ser priorizadas e alocadas nos primeiros ciclos. • A primeira iteração estabelece os principais riscos e o escopo inicial do projeto, de acordo com a funcionalidade principal do sistema. • Partes mais complexas do sistema devem ser atacadas já no primeiro ciclo, pois são elas que apresentam maior risco de inviabilizar o projeto.

27. Desenvolvimento Iterativo • O tamanho de cada ciclo pode variar de uma empresa para outra e conforme o tamanho do sistema. • Por exemplo, uma empresa pode desejar ciclos de 4 semanas, outra pode preferir 3 meses. • Produtos entregues em um ciclo podem ser colocados imediatamente em operação, mas podem vir a ser substituídos por outros produtos mais complexos em ciclos posteriores.

28. Baseado em Casos de Uso • Um caso de uso é uma seqüência de ações, executadas por um ou mais atores e pelo próprio sistema, que produz um ou mais resultados de valor para um ou mais atores. • O PU é dirigido por casos de uso, pois utiliza-os para dirigir todo o trabalho de desenvolvimento, desde a captação inicial e negociação dos requisitos até a aceitação do código (testes).

29. Baseado em Casos de Uso • Os casos de uso são centrais ao PU e a outros métodos iterativos, pois: • Os requisitos funcionais são registrados preferencialmente por meio deles • Eles ajudam a planejar as iterações • Eles podem conduzir o projeto • O teste é baseado neles.

30. Centrado na Arquitetura • Arquitetura é a organização fundamental do sistema como um todo. Inclui elementos estáticos, dinâmicos, o modo como trabalham juntos e o estilo arquitetônico total que guia a organização do sistema. • •A arquitetura também se refere a questões como desempenho, escalabilidade, reuso e restrições econômicas e tecnológicas.

31. Centrado na Arquitetura • No PU, a arquitetura do sistema em construção é o alicerce fundamental sobre o qual ele se erguerá • •Deve ser uma das preocupações da equipe de projeto. • •A arquitetura, juntamente com os casos de uso, deve orientar a exploração de todos os aspectos do sistema

32. Centrado na arquitetura • A arquitetura é importante porque: • –Ajuda a entender a visão global • –Ajuda a organizar o esforço de desenvolvimento • –Facilita as possibilidades de reuso • –Facilita a evolução do sistema • –Guia a seleção e exploração dos casos de uso.

33. Processo de Desenvolvimento • As grandes fases de qualquer processo de desenvolvimento • Concepção • Visão e viabilidade do sistema • Elaboração • Arquitetura e requisitos definidos • Implementação dos requisitos mais complicados

34. As grandes fases de qualquer processo de desenvolvimento (cont.) • Construção • Versão beta do software • Transição • Implantação do sistema no ambiente de produção

35. Fase de Concepção • Estabelece-se as viabilidade de implantação do sistema • Definição do escopo do sistema. • Estimativas de custos e cronograma • Identificação dos potenciais riscos que devem ser gerenciados ao longo do projeto • Esboço da arquitetura do sistema, que servirá como alicerce para a sua construção.

36. Fase de Elaboração • Visão refinada do sistema: • com a definição dos requisitos funcionais; • detalhamento da arquitetura criada na fase anterior; • gerenciamento contínuo dos riscos envolvidos.

37. Fase de Construção • O sistema é efetivamente desenvolvido e, em geral, tem condições de ser operado, mesmo que em ambiente de teste, pelos clientes. • É nesta fase que o desenvolvimento iterativo e incremental é realizado

38. Fase de transição • O sistema é entregue ao cliente para uso em produção. • Testes são realizados e um ou mais incrementos do sistema são implantados. • Defeitos são corrigidos, se necessário.

39. Resumo • Um processo de desenvolvimento deve ser: • Iterativo (ter várias iterações no tempo) • Incremental (gerar novas versões incrementadas a cada release) • Motivos: • Sempre tem algo para entregar para o cliente apressado (a última iteração) • Os requisitos mudam com tempo e um processo iterativo mantém freqüentes contatos com o cliente o que ajuda a manter os requisitos sincronizados • Altamente motivador para a equipe de desenvolvimento (e o cliente) ver o software funcionando cedo