Professor Mário Dantas

1. Análise Orientada a Objetos Fev/2011 Professor MárioDantas

2. Aula 02 - Agenda • Paradigmas de Programação • Processo de Desenvolvimento de Software • Ferramentas de Apoio

3. Software Deselegante • O software deselegante é aquele software feito sem uma estrutura clara. • O software deselegante é aquele do qual não se consegue reusar partes e que não se consegue entender como funciona sem uma boa carga de documentação (e muitas vezes nem assim). • É aquele no qual uma pequena modificação em uma de suas características pode causar um não funcionamento generalizado.

4. Software Elegante • O software elegante é o software cuja estrutura é intrinsecamente mais fácil de compreender, é auto documentado e pode ser compreendido em nível macro ou em detalhes. • Ele é mais fácil de modificar: quando alguma de suas características é mudada, ele continua funcionando. • Soluções para prover elegância -> Padrões de Projeto – lições aprendidas ao longo dos anos em diferentes projetos.

5. Orientação a Objetos • Orientação a objetos (OO) é uma abordagem de programação que procura explorar nosso lado intuitivo. Os objetos da computação são análogos aos objetos existentes no mundo real. • No enfoque de OO, os átomos do processo de computação são os objetos que trocam mensagens entre si. • Essas mensagens resultam na ativação de métodos, os quais realizam as ações necessárias.

6. Orientação a Objetos • Os objetos que compartilham uma mesma interface, ou seja, respondem as mesmas mensagens, são agrupados em classes. • Objeto é algo dinâmico: é criado por alguém, tem uma vida, morre ou é morto por alguém. Assim durante a execução do sistema, os objetos podem: • Ser construídos • Executar ações • Ser destruídos • Tornar-se inacessíveis

7. Problemas do paradigma procedural • Consideremos o clássico problema da validação de um CPF. • Normalmente, temos um formulário, no qual recebemos essa informação, e depois temos que enviar esses caracteres para uma função que irá validá-lo, como no pseudo-código abaixo: cpf = formulario->campo_cpf valida(cpf)

8. Problemas do paradigma procedural • Alguém te obriga a sempre validar esse CPF? • Você pode, inúmeras vezes, esquecer de chamar esse validador. • Mais: considere que você tem 50 formulários e precise validar em todos eles o CPF. • Se sua equipe tem 3 programadores trabalhando nesses formulários, quem fica responsável por essa validação? • Todos!

9. Problemas do paradigma procedural • A situação pode piorar: na entrada de um novo desenvolvedor. • É nesse momento que nascem aqueles guias de programação - às vezes, é um documento enorme. • Em outras palavras, todo desenvolvedor precisa ficar sabendo de uma quantidade enorme de informações, resultando um entrave muito grande!

10. Problemas do paradigma procedural • Outra situação é quando nos encontramos na necessidade de ler o código que foi escrito por outro desenvolvedor e descobrir como ele funciona internamente. • Um sistema bem encapsulado não deveria gerar essa necessidade. Em um sistema grande, simplesmente não temos tempo de ler todo o código existente.

11. Problemas do paradigma procedural • Considerando que você não erre nesse ponto e que sua equipe tenha uma comunicação muito boa, ainda temos outro problema: • imagine que, agora, em todo formulário, você também quer que a idade do cliente seja validada - o cliente precisa ter mais de 18 anos. • Vamos ter de colocar um if... mas onde? Espalhado por todo seu código... Mesmo que se crie outra função para validar, precisaremos incluir isso nos nossos 50 formulários já existentes. • Qual é a chance de esquecermos em um deles? • É muito grande.

12. Problemas do paradigma procedural • Melhor ainda seria se conseguíssemos mudar essa validação e os outros programadores nem precisassem ficar sabendo disso. • Eles criariam formulários e um único programador seria responsável pela validação: os outros nem sabem da existência desse trecho de código. Impossível? • Não, o paradigma da orientação a objetos facilita tudo isso.

13. Problemas do paradigma procedural • O problema do paradigma procedural é que não existe uma forma simples de criar conexão forte entre dados e funcionalidades. • No paradigma orientado a objetos é muito fácil ter essa conexão através dos recursos da própria linguagem.

14. Vantagens de OO • Abstração de dados: os detalhes referentes às representações das classes serão visíveis apenas a seus atributos; • Compatibilidade: as heurísticas para a construção das classes e suas interfaces levam a componentes de software que são fáceis de combinar; • Diminuiçãoda complexidade: as classes delimitam-se em unidades naturais para a alocação de tarefas de desenvolvimento de software.

15. Vantagens de OO • Reutilização: o encapsulamento dos métodos e representação dos dados para a construção de classes facilitam o desenvolvimento de software reutilizável, auxiliando na produtividade de sistemas; • Extensibilidade: facilidade de estender o software devido a duas razões: • Herança: novas classes são construídas a partir das que já existem; • As classes formam um estrutura fracamente acoplada, o que facilita alterações; • Manutenibilidade: a modularização natural em classes facilita a realização de alterações no software.

16. Vantagens de OO • Maior dedicação à fase de análise, preocupando-se com a essência do sistema; • Mesma notação é utilizada desde a fase de análise até a implementação. Frente a essas vantagens, a abordagem OO tem se mostrado “popular” e eficaz.

17. Classes

18. Classes e Objetos

19. Processo de Desenvolvimento Ago/2010

20. Processo de Desenvolvimento • O que é um processo de desenvolvimento? • É a definição de quem faz o que, quando e como, para atingir um certo alvo. • UML é uma linguagem de modelagem, não é uma metodologia. Não se consegue fazer uma boa modelagem sem conhecer processos. • Linguagem de modelagem + processo de desenvolvimento = método (ou metodologia) de desenvolvimento.

21. Processo de Desenvolvimento • As grandes fases de qualquer processo de desenvolvimento são: • Planejamento e elaboração • Planejamento, definição de requisitos, construção de protótipos (opcional) • Construção do sistema (inclui codificação e testes) • Implantação (colocar em produção, treinar usuários, ...)

22. Processo de Desenvolvimento • UML não depende de processo. Você deve escolher o que for adequado ao seu projeto. • Existem diversos modelos, e esse modelos são influenciados por alguns fatores como: • Tipo de software que será desenvolvido (real-time, sistema de informação, etc.) • Escala (Um desenvolvedor, equipe pequena, etc.)

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

24. Processo em cascata

25. Processo Unificado • O processo unificado (PU) de desenvolvimento de software é o conjunto de atividades necessárias para transformar requisitos do usuário em um sistema de software. • É fundamental na visão de que o avanço de um projeto deve estar baseado na construção de artefatos de software, e não apenas em documentação.

26. Processo Unificado • A motivação para o uso da abordagem de CraigLarmanao Processo Unificado deve-se ao fato de que este é um processo bastante conciso e eficiente para análise e projeto de sistemas orientado a objetos • Neste método, cada artefato (documento ou diagrama) tem uma razão muito clara para existir e as conexões entre os diferentes artefatos são muito precisas.

27. Processo Unificado • Principais Características: • Dirigido por casos de uso. • Descrições de casos de uso e seus diagramas embasam a construção do software. • Centrado na arquitetura. • O documento visão, diagrama de componentes e implantação, diagrama de interação e diagrama de classes (modelo de dados) fornecem a perspectivas da arquitetura do software. • Iterativo e incremental.

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

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

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

36. Trabalhadores • Trabalhadores: Um trabalhador é alguém que desempenha um papel e é responsável pela realização de atividades para produzir ou modificar um artefato. • Exemplos: analista de sistemas, programador, testador, etc.

37. Atividades • Atividades: tarefa que um trabalhador executa a fim de produzir ou modificar um artefato.

38. Processos do PU • Descreve as seqüências das atividades que produzem algum resultado significativo e mostra as interações entre os participantes • São realizadas a qualquer momento durante o ciclo de desenvolvimento (Fases do PU) • Ex.: • Requisitos, Análise, Projeto, Implementação e Teste

39. Processos do PU • Conjunto de atividades (e artefatos relacionados): • Modelagem de Negócio • Requisitos • Projeto • Implementação • Teste • Implantação • Gestão de Configuração e Mudanças • Gerenciamento de projeto • Ambiente

40. Fases do Processo Unificado • Cada um dos ciclos de desenvolvimento do PU é dividido em quatro fases: • Concepção; • Elaboração; • Construção; • Transição.

41. Fases do PU: Concepção • Estabelece-se a 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.

42. Fases do PU: Elaboração • Visão refinada do sistema: • definição dos requisitos funcionais; • detalhamento da arquitetura criada na fase anterior; • gerenciamento contínuo dos riscos envolvidos. • Estimativas realistas feitas nesta fase permitem um plano para orientar a construção do sistema.

43. Fases do PU: Construção • O sistema é efetivamente desenvolvido e, em geral, tem condições de ser operado, mesmo que em ambiente de teste, pelos clientes.

44. Fases do PU: 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.

45. Fases do Processo Unificado

46. Processos do PU • Avaliando-se as fases do PU, pode-se ter a impressão de que cada ciclo de iteração comporta-se como o modelo em cascata. • Mas isso não é verdade: paralelamente às fases do PU, as atividades de trabalho, denominados Processos do PU, são realizadas a qualquer momento durante o ciclo de desenvolvimento. • Processos do PU entrecortam todas as fases do PU, podendo ter maior ênfase durante certas fases e menor ênfase em outras, mas podendo ocorrer em qualquer uma delas.

47. Processos do PU

48. Processo Unificado

49. Os Artefatos do PU • Cada uma das disciplinas do PU pode gerar um ou mais artefatos, que devem ser controlados e administrados corretamente durante o desenvolvimento do sistema. • Artefatos são quaisquer dos documentos produzidos durante o desenvolvimento, tais como modelos, diagramas, documentos de especificação de requisitos, código fonte ou executável, planos de teste, etc. • Muitos dos artefatos são opcionais, produzidos de acordo com as necessidades específicas de cada projeto.

50. Os Artefatos do PU P = produzir R = revisar