Processo unificado e notação uml

822 visualizações

Publicada em

Processo unificado e notação uml

Publicada em: Educação
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
822
No SlideShare
0
A partir de incorporações
0
Número de incorporações
11
Ações
Compartilhamentos
0
Downloads
14
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Processo unificado e notação uml

  1. 1. Processo Unificado e Notação UML Professor Wagner Gadêa Lorenz wagnerglorenz@gmail.com Disciplina: Engenharia de Software II Curso de Sistemas de Informação Cachoeira do Sul, 04 de Março de 2015.
  2. 2. Processo Unificado Rational Um dos mais conhecidos processos tradicionais é o Processo Unificado da IBM/Rational; O Processo Unificado é baseado em componentes, e utiliza a Linguagem de Modelagem Unificada (UML); O Processo Unificado integra ciclos, fases, disciplinas, suavização de riscos, controle de qualidade, gerenciamento de projetos e controle de configuração; Engenharia de Software II 2
  3. 3. Solução • Uso das Melhores Práticas de Desenvolvimento: práticas usadas com sucesso pela indústria de software; • São elas: • Desenvolvimento iterativo; • Gerência de requisitos; • Uso de arquitetura baseada em componentes; • Modelagem visual; • Verificação contínua da qualidade de software ; • Gerência de mudança. Engenharia de Software II 3
  4. 4. Prática 1: Desenvolvimento Iterativo Engenharia de Software II 4 Cada iteração resulta e m u m r e l e a s e executável
  5. 5. Análise de Riscos Engenharia de Software II 5
  6. 6. Prática 2: Gerência de Requisitos • Tenha certeza que você está • Resolvendo o problema certo • Construindo o sistema certo • Por usar uma abordagem sistemática para: • elicitar • organizar • documentar • gerenciar • As mudanças dos requisitos de um software. Engenharia de Software II 6
  7. 7. Prática 3: Uso de Arquitetura baseada em Componentes • Base para reuso • Reuso de Componentes • Reuso de Arquitetura Engenharia de Software II 7 System- software Middleware Business- specific Application- specific Arquitetura baseada em componentes com camadas
  8. 8. Prática 4: Modelagem Visual usando a UML 8 Engenharia de Software II
  9. 9. Prática 5: Verificação Contínua da Qualidade 9 Engenharia de Software II
  10. 10. Dimensões de Teste de Qualidade Confiabilidade ⬥Testar se a aplicação se comporta consistentemente e previsivelmente. Performance ⬥Testar resposta online com sobrecarga Funcionalidade ⬥Testar cada cenário de caso de uso para verificar que se comporta corretamente Usabilidade ⬥Testar a aplicação da perspectiva do usuário final Suportabilidade ⬥Testar a habilidade de manter e suportar a aplicação sob uso em ambiente de produção 10 Engenharia de Software II
  11. 11. Testes em cada Iteração 11 Engenharia de Software II
  12. 12. Prática 6: Gerenciar Mudanças ❖ O que você quer controlar? ❖ workspaces seguros para cada desenvolvedor ❖ Gerenciamento de build/integração automatizados ❖ Desenvolvimento paralelo Engenharia de Software II 12
  13. 13. Alcançando as melhores práticas por meio de um processo ❖ Abordagem iterativa; ❖ Guia para atividades e artefatos; ❖ Processo focado na arquitetura; ❖ Casos de uso dirigem o projeto e a implementação; ❖ Modelos simplificados do sistemas; Engenharia de Software II 13
  14. 14. Organização do RUP conteúdo Disciplinas agrupam atividades relacionadas A iteração percorre todas as disciplinas. tempo Engenharia de Software II
  15. 15. Organização do RUP por tempo ❖ Rational Unified Process é organizado em 4 fases: ❖ Concepção: define o escopo do software ❖ Elaboração: planeja o projeto, especifica features, define e valida a arquitetura ❖ Construção: constrói o produto ❖ Transição: implantação do software Engenharia de Software II 15
  16. 16. Número de Iterações ❖ Rule of thumb: Use 6 ± 3 iterações Phase Low Medium High Inception 0 1 1 Elaboration 1 2 3 Construction 1 2 3 Transition 1 1 2 Total 3 6 9 Engenharia de Software II 16
  17. 17. Disciplinas Cada disciplina no RUP contém um fluxo de trabalho (workflow). Um workflow é um fluxo de a t i v i d a d e s d e a l t o - n í v e l ( W o r k f l o w D e t a i l s ) q u e produzem um resultado de valor observável •Workflow Details Engenharia de Software II 17
  18. 18. Workflows Details Exemplo: Disciplina Requisitos Exemplo diagrama Workflow Detail: Analyze the Problem Workflows details mostram trabalhadores, atividades que estes executam, artefatos de entrada e artefatos de saída. Engenharia de Software II18
  19. 19. Disciplinas ❖ No Processo Unificado Rational existem nove disciplinas, que são divididas em seis disciplinas de processo e três de suporte: ❖ As disciplinas de processo são: ❖ Modelagem de Negócio; ❖ Requisitos; ❖ Análise e Projeto (desenho); ❖ Implementação; ❖ Teste; ❖ Implantação. ❖ As disciplinas de suporte são: ❖ Gerenciamento de Configuração e Alteração; ❖ Gerenciamento de Projetos ❖ Ambiente. Engenharia de Software II 19
  20. 20. Conceitos Básicos do RUP Engenharia de Software II 20
  21. 21. Trabalhador (Worker) ❖ O trabalhador define o comportamento e as responsabilidades de um indivíduo, ou um conjunto de indivíduos trabalhando em uma equipe, dentro do contexto de uma organização de software; ❖ O trabalhador representa um cargo executado por indivíduos em um projeto e define como eles devem realizar o trabalho [RAT 99][RAT 2001]; ❖ Exemplos: Analistas de Sistemas, gerentes de projeto, arquitetos de software, testadores, entre outros. Engenharia de Software II 21
  22. 22. Atividade (Activity) ❖ Uma atividade é uma unidade de trabalho que um indivíduo que representa um trabalhador é encarregado de executá-la; ❖ Uma atividade tem uma finalidade clara, usualmente expressa em termos de criação ou atualização de algum artefato, como um modelo, uma classe, um plano [RAT 99][RAT 2001]. Engenharia de Software II 22
  23. 23. Artefatos (Artifacts) ❖ Atividades têm artefatos como entrada e saída; ❖ Um artefato é um produto de trabalho do processo, trabalhadores usam artefatos para executar suas atividades, e produzem artefatos durante a execução de suas atividades; ❖ Artefatos são de responsabilidade de um único trabalhador, em um processo, cada porção de informação é de responsabilidade de uma pessoa específica Engenharia de Software II 23
  24. 24. Artefatos (Artifacts) Iteration Plan Developer Test Storyboar d Project Measurements Business Use Case Model Iteration Assessment Analysis Model Architectura l Proof-of- Concept Use Case Model Test Environment Configuration User- Interface Prototype Engenharia de Software II 24
  25. 25. Trabalhador , Atividade e Artefato Engenharia de Software II 25
  26. 26. Referências Bibliográficas ❖ [JAC 98] JACOBSON, Ivar; BOOCH, Grady; RUMBAUGH, James. The Unified Software Development Process. [S.l.]: Addison Wesley, 1998. ❖ [KRU 2000] KRUCHTEN, Philippe. The Rational Unified Process: An Introduction. Massachusetts: Addison Wesley, 2000. ❖ [RAT 2001] RATIONAL SOFTWARE CORPORATION. Rational Unified Process, Version 2001.03.00. Cupertino, 2001. ❖ [SCO 2004] SCOTT, Kendall. O Processo Unificado (RUP) Explicado – UML. Bookman, 2004. ❖ Material da Profa. Lisandra Manzoni Fontoura, disciplina de Engenharia de Software. Engenharia de Software II 26
  27. 27. UML ❖ A UML - Unified Modeling Language ou Linguagem de Modelagem Unificada, é uma linguagem visual utilizada para modelar softwares baseados no paradigma de orientação de objetos. ❖ Essa linguagem tornou-se, nos últimos anos, a linguagem-padrão de modelagem adotada internacionalmente pela indústria de engenharia de software. Engenharia de Software II 27
  28. 28. UML ❖ Deve ficar bem claro, que a UML não é uma linguagem de programação, e sim uma linguagem de modelagem, uma notação, cujo objetivo é auxiliar os engenheiros de software a definirem as características do software, tais como seus requisitos, seu comportamento, seus estrutura lógica, a dinâmica de seus processos e até mesmo suas necessidades físicas em relação ao equipamento sobre o qual o sistema deverá ser implantado. ❖ Tais características podem ser definidas por meio da UML antes do software começar a ser realmente desenvolvido. Engenharia de Software II 28
  29. 29. UML ❖ Além disso, cumpre destacar que a UML não é um processo de desenvolvimento de software e tampouco está ligada a um de forma exclusiva, sendo totalmente independente, podendo ser utilizada por muitos processos de desenvolvimento diferentes ou mesmo da forma que o engenheiro considerar mais adequada. Engenharia de Software II 29
  30. 30. Breve Histórico da UML ❖ A UML surgiu da união de três métodos de modelagem: ❖ O método de Booch, o método OMT (Object Modeling Technique), de Jacobson; e ❖ O método OOSE (Object-Oriented Software Engineering) de Rumbaugh. ❖ Estes eram até meados da década de 1990, os métodos de modelagem orientada a objetos mais populares entre os profissionais da área de desenvolvimento de software. Engenharia de Software II 30
  31. 31. Breve Histórico da UML ❖ A união desses métodos contou com o amplo apoio da Rational Software, que a incentivou e financiou. ❖ O esforço inicial do projeto começou com a união do método de Booch ao OMT de Jacobson, o que resultou no lançamento do Método Unificado, no final de 1995. ❖ Logo em seguida, Rumbaugh juntou-se a Booch e Jacobson na Rational Software, e seu método OOSE começou também a ser incorporado à nova metodologia. Engenharia de Software II 31
  32. 32. Breve Histórico da UML ❖ O trabalho de Booch, Jacobson e Rumbaugh, conhecidos popularmente como “Os Três Amigos”, resultou no lançamento, em 1996, da primeira versão da UML propriamente dita. ❖ Em 1997, a UML foi adotada pela OMG (Object Management Group ou Grupo de Gerenciamento de Objetos), como uma linguagem-padrão de modelagem. ❖ A versão 2.0 da linguagem foi oficialmente lançada em julho de 2005. ❖ http://www.omg.org/ Engenharia de Software II 32
  33. 33. Rápido Resumo dos Diagramas da UML ❖ Será descrito brevemente cada um dos diagramas oferecidos pela UML, destacando suas principais características. Engenharia de Software II 33
  34. 34. Diagrama de Caso de Uso ❖ O Diagrama de Caso de Uso é o diagrama mais geral e informal da UML, utilizado normalmente nas fases de levantamento e análise de requisitos do sistema, embora venha a ser consultado durante todo o processo de modelagem e possa servir de base para outros diagramas. Engenharia de Software II 34
  35. 35. Diagrama de Caso de Uso ❖ Apresenta uma linguagem simples e de fácil compreensão para que os usuários possam ter uma ideia geral de como o sistema irá se comportar. ❖ Procura identificar os atores (usuários, outros sistemas ou até mesmo algum hardware especial) que utilizarão de alguma forma o software, bem como os serviços, ou seja, as funcionalidades que o sistema disponibilizará aos atores, conhecidas nesse diagrama como casos de uso. Engenharia de Software II 35
  36. 36. Diagrama de Caso de Uso ❖ Apresenta uma linguagem simples e de fácil compreensão para que os usuários possam ter uma ideia geral de como o sistema irá se comportar. ❖ Procura identificar os atores (usuários, outros sistemas ou até mesmo algum hardware especial) que utilizarão de alguma forma o software, bem como os serviços, ou seja, as funcionalidades que o sistema disponibilizará aos atores, conhecidas nesse diagrama como casos de uso. Engenharia de Software II 36
  37. 37. Diagrama de Caso de Uso Engenharia de Software II 37
  38. 38. Diagrama de Classes ❖ O Diagrama de Classes é provavelmente o mais utilizado e é um dos mais importantes da UML. ❖ Serve como apoio para a maioria dos demais diagramas. ❖ Como o próprio nome diz, define a estrutura das classes utilizadas pelo sistema, determinando os atributos e métodos que cada classe tem, além de estabelecer como as classes se relacionam e trocam informações entre si. Engenharia de Software II 38
  39. 39. Diagrama de Classes Engenharia de Software II 39
  40. 40. Diagrama de Classes Engenharia de Software II 40
  41. 41. Diagrama de Classes Engenharia de Software II 41
  42. 42. Diagrama de Objetos* ❖ O Diagrama de Objetos está amplamente associado ao diagrama de Classes. ❖ Na verdade, o diagrama de objetos é praticamente um complemento do diagrama de classes e bastante dependente deste. ❖ O diagrama fornece uma visão dos valores armazenados pelos objetos de um diagrama de classes em um determinado momento de execução de um processo de software. Engenharia de Software II 42
  43. 43. Diagrama de Objetos Engenharia de Software II 43
  44. 44. Diagrama de Objetos Engenharia de Software II 44
  45. 45. Diagrama de Pacotes* ❖ O Diagrama de Pacotes é um diagrama estrutural que tem por objetivo representar os subsistemas ou submódulos englobados por um sistema de forma a determinar as partes que o compõem. ❖ Pode ser utilizado de maneira independente ou associado com outros diagramas. ❖ Este diagrama pode ser utilizado também para auxiliar a demonstrar a arquitetura de uma linguagem, como ocorre com a própria UML ou ainda para definir as camada de um software ou de um processo de desenvolvimento. Engenharia de Software II 45
  46. 46. Diagrama de Pacotes Engenharia de Software II 46
  47. 47. Diagrama de Sequência ❖ O Diagrama de Sequência é um diagrama comportamental que preocupa-se com a ordem temporal em que as mensagens são trocadas entre os objetos envolvidos em um determinado processo. ❖ Em geral, baseia-se em um caso de uso definido pelo diagrama de mesmo nome e apoia-se no diagrama de classes para determinar os objetos das classes envolvidas em um processo. ❖ Um diagrama de sequência costuma identificar o evento gerado do processo modelado, bem como o ator responsável por esse evento, e determina como o processos deve se desenrolar e ser concluído por meio da chama de métodos disparados por mensagens enviadas entre os objetos. Engenharia de Software II 47
  48. 48. Diagrama de Sequência Engenharia de Software II 48
  49. 49. Diagrama de Sequência Engenharia de Software II 49
  50. 50. Diagrama de Comunicação ❖ O Diagrama de Comunicação era conhecido como de Diagrama de Colaboração até a versão 1.5 da UML, tendo o seu nome modificado para diagrama de comunicação a partir da versão 2.0. ❖ Está amplamente associado ao diagrama de sequência: na verdade, um complementa o outro. ❖ As informações mostradas no diagrama de comunicação com frequência são praticamente as mesmas apresentadas no de sequência, porém com um enfoque distinto, visto que esse diagrama não se preocupa com a temporalidade do processo, concentrando-se em como os elementos do diagrama estão vinculados e quais mensagens trocam entre si durante o processo. Engenharia de Software II 50
  51. 51. Diagrama de Comunicação Engenharia de Software II 51
  52. 52. Diagrama de Comunicação Engenharia de Software II 52
  53. 53. Diagrama de Máquina de Estados ❖ O Diagrama de Máquina de Estados demonstra o comportamento de um elemento por meio de um conjunto finito de transições de estado, ou seja, uma máquina de estados. ❖ Além de poder ser utilizado para expressar o comportamento de uma parte do sistema, quando é chamado de máquina de estado comportamental, também pode ser usado para expressar o protocolo de uso de parte de um sistema, quando identifica uma máquina de estados de protocolo. ❖ Como o diagrama de sequência, o de máquina de estados pode basear-se em um caso de uso, mas também pode ser utilizado para acompanhar os estados de outros elementos, como, por exemplo, uma instância de uma classe. Engenharia de Software II 53
  54. 54. Diagrama de Máquina de Estados Engenharia de Software II 54
  55. 55. Diagrama de Máquina de Estados Engenharia de Software II 55
  56. 56. Diagrama de Atividade ❖ O Diagrama de Atividade era considerado um caso especial do antigo diagrama de gráfico de estados, hoje conhecido como diagrama de máquina de estados, conforme descrito anteriormente. ❖ A partir da UML 2.0, foi considerado independente do diagrama de máquina de estados. ❖ O diagrama de atividade preocupa-se em descrever os passos a serem percorridos para a conclusão de uma atividade específica, podendo esta ser representada por um método com certo grau de complexidade ou mesmo por um processo completo. ❖ O diagrama de atividade concentra-se na representação do fluxo de controle de uma atividade. Engenharia de Software II 56
  57. 57. Diagrama de Atividade Engenharia de Software II 57
  58. 58. Diagrama de Atividade Engenharia de Software II 58
  59. 59. Diagrama de Atividade Engenharia de Software II 59
  60. 60. Diagrama de Visão Geral de Interação ❖ O Diagrama de Visão Geral de Interação é uma variação do diagrama de atividade que fornece uma visão geral dentro de um sistema ou processo de negócio. ❖ Esse diagrama passou a existir apenas a partir da UML 2. Engenharia de Software II 60
  61. 61. Diagrama de Visão Geral de Interação Engenharia de Software II 61
  62. 62. Diagrama de Componentes ❖ O Diagrama de Componentes está amplamente associado à linguagem de programação que será utilizada para desenvolver o sistema modelado. ❖ Esse diagrama representa os componentes do sistema quando o mesmo for ser implementado em termos de módulos de código-fonte, bibliotecas, formulários, arquivos de ajuda, módulos executáveis etc. e determina como tais componentes estarão estruturados e irão interagir para que o sistema funcione de maneira adequada. Engenharia de Software II 62
  63. 63. Diagrama de Componentes Engenharia de Software II 63
  64. 64. Diagrama de Componentes Engenharia de Software II 64
  65. 65. Diagrama de Implantação ❖ O Diagrama de Implantação determina as necessidades de hardware do sistema, as características físicas como servidores, estações, topologias e protocolos de comunicação, ou seja, todo o aparato físico sobre o qual o sistema deverá ser executado. Engenharia de Software II 65
  66. 66. Diagrama de Implantação Engenharia de Software II 66
  67. 67. Diagrama de Implantação Engenharia de Software II 67
  68. 68. Síntese Geral dos Diagramas ❖ Os diagramas da UML dividem-se em diagramas estruturais e diagramas comportamentais, sendo que os últimos contêm ainda uma subdivisão representada pelos diagramas de interação. Engenharia de Software II 68
  69. 69. Síntese Geral dos Diagramas Engenharia de Software II 69
  70. 70. Próxima Aula • Ferramentas CASE Orientadas a Objetos; e • Orientação a Objetos Engenharia de Software II 70
  71. 71. Dúvidas • Conteúdo • Moodle • (http://wagnerglorenz.com.br/moodle/) • Dúvidas • wagnerglorenz@gmail.com Engenharia de Software II 71
  72. 72. Referências Bibliográficas • GUEDES, Gilleanes T. A.. UML: uma abordagem prática. São Paulo: Novatec, 2004. Engenharia de Software II 72

×