Análise e Projeto Orientado a Objetos

Transcrição

1 Análise e Projeto Orientado a Objetos

2 Contextualizando Por que Análise e Projeto? Análise versus Projeto Análise e Projeto OO Processo de Desenvolvimento de Software Alguns Processos de Desenvolvimento

3 Um pouco de engenharia de software...: Softwares estão presentes em todas as áreas e a socidade é cada vez mais dependente deles. Em bancos, empresas de telecom, pesquisas médicas, produções cinematográficas, exploração espacial, etc. Analistas e desenvolvedores sofrem pressão por preço, prazo, qualidade, complexidade... Mais de 30% dos projetos são cancelados (alguns já nascem fadados ao fracasso projetos marcha da morte ); Custos superam até 3 vezes o que foi orçado; Cronogramas executados ultrapassam facilmente 100% em relação ao planejado ou linha de base.

4 Para pensar nos riscos...: Software Construção de casa Você deixaria um pedreiro construir uma casa, sem planta? Em que tipo de casa isso seria aceitável? Software Instalação elétrica Você levaria a um eletricista do meio de rua, um transformador, sem o desenho do circuito? Em que tipo de transformador isso seria aceitável? Software, simplesmente Você deixaria o primo do vizinho do seu tio implementar um software, só com uma conversa? Em que tipo de software isso seria aceitável?

5 Um carro!

6 Um avião!

7 Uma casa!

8

9 Construir um software sem realizar análise e projeto, é como construir uma casa sem ter plantas estruturais, hidráulicas, elétricas, arquitetônicas... Pode ser aceitável para certos tipos de software de complexidade e risco baixos; Nos demais casos, análise e projeto são a base para a construção de um software, trazendo a segurança do que exatamente está especificado e o que será implementado; Análise e projeto oferecem recursos para garantir que melhoramentos na descrição de um sistema preservam o comportamento e funcionalidade do mesmo.

10

11

12 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 investigativa e de levantamento; O projeto/design enfatiza a proposta de uma solução que atenda ao identificado na análise (como pode ser feito); É uma atividade de criação.

13 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 ao programador; Em alguns casos (fortemente em MDD) o cliente estará interessado em artefatos de projeto.

14 Pode-se dizer que o resultado da análise é o enunciado do problema, e que o projeto será a sua resolução; Problemas mal enunciados podem até ser resolvidos, mas a solução não corresponderá às expectativas; Análise e projeto bem-feitos são importantes! Um erro verificado na fase de análise tem um custo; na fase de projeto tem um custo maior; na fase de implementação maior ainda, e na fase de implantação do sistema tem um custo incalculável.

15 Custos de correção de software, de acordo com as fases do projeto em que são descobertos:

16 Um novo paradigma de análise e projeto; A perspectiva empregada é da abstração de objetos (coisas, conceitos ou entidades), tanto na análise quanto no projeto; A ênfase está em achar e descrever objetos (ou conceitos) no domínio do problema e entender suas relações; Por exemplo, num sistema de informação para uma locadora de DVDs, alguns dos conceitos são: Locadora, Funcionário, Cliente, Locação, DVD; Tais objetos podem ter atributos (características) e responsabilidades.

17 Testando outros cenários... Farmácia Biblioteca Controle de Estacionamento Nestes 3 casos acima, o domínio do problema parece ser amplamente conhecido. E nos cenários abaixo: Financiamentos Bancários Processos Judiciais Meteorologia Fiscalização Fazendária Emissão de Passaportes

18 Exemplo da Biblioteca e seus objetos, com a visáo detalhada do objeto Livro (atributos e operações).

19 As abstrações do mundo real são objetos que correspondem às coisas do domínio do problema: Pensar em objetos é mais natural do que pensar apenas em funções; Os objetos servem de instrumentos para comunicação e entendimento do software que será desenvolvido; Promovem decomposição do problema, flexibilidade e reutilização; As abstrações e suas decomposições podem ser representadas por uma linguagem visual chamada UML (a ser vista a diante).

20 DISCIPLINA! Define atividades, papéis, artefatos e um fluxo que tem como objetivo padronizar o ciclo de vida de um projeto de desenvolvimento de software. Quem, O que, Quando e Como Objetivo. Normalmente o objetivo é: Evoluir um software existente; Implementar um novo software; Com qualidade! Atividades de análise e projeto estão no contexto dos processos de desenvolvimento de software.

21 Metodologias Processos Modelagem Metodologias de desenvolvimento: Estruturada, Orientada a Objetos e Ágil Processos de desenvolvimento:/ Frameworks RAD, UP, RUP, Scrum, XP, MDD, Crystal, Lean Modelagem de software Análise essencial, Análise estruturada, UML Mas, podemos dizer que: Metodologias = Processos + Modelagem

22 Algumas consultorias, vendedores de ferramentas ou marqueteiros vendem qualquer processo, para qualquer empresa, como a SOLUÇÃO DE TODOS OS PROBLEMAS de (falta de) qualidade dos softwares ou projetos fracassados.

23 Ao contrário do que dizem os torcedores (que são diferentes dos marqueteiros...): Não existe A MELHOR metodologia ou processo; Existe a escolha certa para o cenário certo, e para a realidade da empresa, das equipes e seus projeto; Optar por uma metodologia e processo no ciclo de vida de um projeto de software, não é garantia de sucesso e objetivos atingidos; Ferramentas de apoio ao processo não necessariamente direcionam um projeto ao seus objetivos.

24 O importante não é escolher um processo porquê este está na moda ou lhe garante um certificado. Identificar objetivos para aderência a um processo; Relacionar boas práticas e a melhor forma de trabalho; Relacionar ferramentas de apoio; Envolver as pessoas.

25 RUP Rational Unified Process O RUP é um processo de desenvolvimento que descreve: O que deve ser executado (atividades e disciplinas); Quem deve executar (papéis); Qual resultado deve ser gerado (artefatos). O RUP prevê o desenvolvimento de sistemas de modo iterativo-incremental; Requisitos funcionais são tratados como casos de uso.

26

27 XP Extreme Programming O XP (Extreme Programming) busca menos burocracia, mais produtividade e redução de custos; Quatro elementos principais: Comunicação; Simplicidade; Feedback; Coragem. XP também prevê o desenvolvimento iterativoincremental; Requisitos extraídos de user stories.

28

29 Scrum Iterativo-incremental e empírico; Processo ágil e simples (poucas regras ), que pode vem sendo aplicado na execução de qualquer projeto, inclusive de natureza complexa e incerta; Entregas rápidas (em sprints de duas a quatro semanas) e contínuas, com valor agregado de negócio e novas ou melhoradas funcionalidades; Times de desenvolvimento pequenos e autogerenciáveis; Requisitos compõem um backlog do produto.

30

31

32 Outros... Cleanroom - Processo estruturado pesado RAD Processo baseado em prototipagem leve Kanban Processo mais-ágil Lembrando: não há processo ideal, há o melhor processo para uma realidade de projeto de software. Não existem balas-de-prata no desenvolvimento de software (termo de Fred Brooks em seu clássico The Mythical Man-Month).

33 Frederick Brooks Robert Glass Ed Yourdon - Death March RUP XP Scrum das Trincheiras

34 Atribuição-Uso Não-Comercial 2.5 Brasil