Professor Mário Dantas

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

2. Aula 03 - Agenda • Processo de Desenvolvimento de Software • Ferramentas de Apoio

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

4. 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, ...)

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

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

7. Processo em cascata

8. Processo Unificado • Causas dos fracassos da maioria dos projetos: • Gerenciamento informal dos requisitos; • Não entendimento das necessidades dos usuários; • Incapacidade de lidar com as mudanças de requisitos; • Complexidade crescente e excessiva; • Qualidade ruim; • Testes insuficiente.

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

10. Processo Unificado • A motivação para o uso do 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.

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

12. Processo Unificado • Outras características: • Gerenciamento de requisitos; • Arquitetura baseada em componentes; • Organização da especificação em “modelos”; • Verificação constante da qualidade; • Controle de mudança; • Organiza o sistema com estrutura estática e dinâmica.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

30. Fases do Processo Unificado

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

32. Processos do PU

33. Processo Unificado

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

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

36. Ferramentas de Apoio Ago/2010

37. Ferramentas • O que são Ferramentas CASE? • A sigla CASE significa “Computer-Aided Software Engineering”. • Traduzindo para um bom português: “Engenharia de Software Auxiliada por Computador”.

38. Ferramentas • As ferramentas se dividem em três categorias. São elas: • LowerCASE- ferramentas de codificação (front-end); • UpperCASE- ferramentas de análise, projeto e implementação; • IntegratedCASE- união de Upper e Lower CASE.

39. Ferramentas • Como escolher a ferramenta? • O primeiro passo é saber qual será o uso da ferramenta na sua empresa. Isto é, ferramenta para codificação ou ferramenta para análise. • Outro fator importante é que a ferramenta deve ser aderente ao conceitos de trabalho na sua empresa.Como estes conceitos e técnicas evoluem no tempo.

40. Ferramentas • Questões importantes para escolha da ferramenta: • O time de desenvolvimento está preparado tecnicamente para trabalhar com ferramentas case? • Preciso capacitar os recursos humanos de minha empresa? • A metodologia de desenvolvimento em minha empresa está “amadurecida”?

41. Ferramentas • Na prática, as ferramentas existentes no mercado possuem as características das quais destacam-se os seguintes pontos: • Desenvolvidas sobre uma arquitetura inteligente (customizável); • Possuem "facilitadores" para auxiliar nas tarefas repetitivas; • Verificação da consistência através de regras específicas; • Geração de relatórios para acompanhamento do trabalho; • Interfaces com outros aplicativos de desenvolvimento.

42. Ferramentas “Uma ferramenta CASE não é a solução para todos os problemas da organização. A organização deve ter certeza de estar pronta para a nova ferramenta. Desta forma uma ferramenta só deveria ser selecionada após a definição do processo de desenvolvimento, dos métodos e de ter sido utilizada num projeto piloto.” (Reid).

43. Ferramentas • Comerciais e “FreeEditions” • MagicDraw ($ 1,599,00) • Together Architect  ( $ 11.500,00) • Poseidon ($ 875,00 ) • Enterprise Architect ($ 2.500,00) • Rose Technical Developer ($6,880.00) • Jude/Astah ($280,00 1usuário/1ano) • Omondo Eclipse UML ($ 84,900.00 / 20 usuários) • Visual Paradigm ($ 699) Fonte: http://www.objectsbydesign.com/tools/umltools_byPrice.html

44. Ferramentas • Livres (BSD e GPL) • Umbrello • ArgoUML • Dia • BOUML • Fajuba • StarUML

45. Dia é um programa baseado em gtk+ para criação do diagrama, liberado sob a licença GPL. • É parte do projeto Gnome. • Atualmente tem objetos especiais de lógica, entidade e relacionamento, diagramas UML, fluxogramas, diagramas da rede, e circuitos simples entre outros.

46. ArgoUML • ArgoUML é uma ferramenta CASE baseada na notação UML (UnifiedModelingLanguage). • Foi desenvolvido pela comunidade de desenvolvedores de código livre Tigris vinculada a Universidade da California, Berkeley. • Sua interface é bem completa o que a torna um pouco complexa de manipular.

47. Umbrello e um Software de Modelagem UML, que e integrado ao projeto KDE. • Este Software é utilizado para modelar o próprio projeto do KDE por a grande de seus desenvolvedores que utilizam UML.

48. JUDE é uma ferramenta profissional de modelagem para sistemas a qual suporta UML, diagrama entidade relacionamento, Flowchart, CRUD, Mini Mapas e Diagrama de Fluxo de Dados. • Permite também a conversão entre modelos UML, ER Diagramas, Flowcharts, fluxo de dados e mini mapas. • O nome do programa é um acrônimo de Java andUML DevelopersEnvironment (Ambiente para Desenvolvedores UML e Java).