Professor Mário Dantas

1. Análise Orientada a Objetos Ago/2010 Professor MárioDantas

2. Ementa da Disciplina • A UML - Linguagem de Modelagem Unificada • História • Métodos que originaram a UML • Elementos • Aplicação • Processos • Ferramentas de Apoio • Engenharia de Requisitos • Definição e Etapas

3. Ementa da Disciplina • Diagramas: • Caso de Uso: Aplicação e Notação • Atividade: Aplicação e Notação • Classes: Aplicação e Notação • Objeto: Uso, Notação • Interação - Seqüência: Aplicação e Notação • Interação – Interação Geral • Estrutura Composta: Uso, Notação e Aplicação • Estados: Uso, Notação e Aplicação • Demais Diagramas da UML 2.0 e extensões: Uso, Notação

4. Bibliografia Básica • WAZLAWICK, Raul Sidnei. Análise e Projeto de Sistemas de Informação Orientados a Objetos, Campus, 2004. • RUMBAUGH, James e BLAHA, Michael. Modelagem e projetos baseados em objetos com UML 2. Campus, 2006. • MEDEIROS, Ernani. Desenvolvendo Software com UML 2.0 Definitivo. Makron Books, 2004.

5. Bibliografia Complementar • TAFNER, Malcon A. & Carlos Henrique Correia. Análise Orientada a Objetos. 2 Ed., Visual Books, 2006. • MELO, Ana Cristina. Exercitando Modelagem em UML. Brasport, 2006. • BEZERRA, Eduardo. Princípio de Análise e Projetos de Sistemas com UML. Elsevier - Campus, 2006. • PENDER, Tom. UML: a Bíblia. 1 ed., Campus, 2004.

6. Aula 01 - Agenda • Grandes Verdades Sobre Software • Conceitos Fundamentais • A UML - Linguagem de Modelagem Unificada • História • Métodos que originaram a UML • Elementos

7. Histórico • Anos 60 – 70 • COBOL, FORTRAN E C • Métodos de Análise e Projeto Estruturado • Final dos anos 60 • Simula (primeira linguagem a incorporar elementos de OO) • Anos 80 e início dos anos 90 • ADA, Smalltalk e C++ • Primeiros métodos de OO

8. Histórico • Restante dos anos 90: início da atração por OO • Java, UML e Unified Process • Proliferação de métodos OO • Método: notação + atividades

9. Métodos OO Precursores • 1989 – Wirfs-Brock • Cartões CRC ( Classe – Responsabilidade – Colaborador) • 1991 – Coad / Yourdon • OOA e OOD • 1991 – GradyBooch • Método BOOCH • 1991 – James Rumbaugh • Método OMT (ObjectModelingTechnique)

10. Métodos OO Precursores • 1992 – Ivar Jacobson • OBJECTORY OOSE • 1994 – Coleman • Método Fusion (Mistura de conceitos presentes nos métodos Booch, OMT, CRC e Métodos Formais).

11. Antes da UML • Vários métodos surgem entre 89 e 94 (“Guerra dos métodos”) • Novas versões dos métodos, incorporando técnicas uns dos outros (OOSE, OMT-2, Booch’93) • Reconhecia-se que havia pontos mais fortes em cada um dos métodos • Parceria entre Booch e Rumbaugh (Rational) –1994 • Unified Method (UM)

12. Antes da UML • Rational a incorpora a Objective Systems (Objectory) de Jacobson – 1995 • Parceria Booch/Rumbaugh estendida com Jacobson • UnifiedModelingLanguage (UML)

13. Surgimento da UML UML BOOCH OMT • Diagrama de Estados • Diagrama de Objetos • (Colaboração) • Diagrama de Processo • (Desenvolvimento) • Diagrama de Módulos • (Componentes) • Diagrama de Estados • Diagrama de Classes • Use Case • Subsistemas (Package) • Diagrama de Interações • MiniEspecificação OOSE

14. Surgimento da UML

15. Mais Contribuições

16. UML • A UML - UnifiedModelingLanguageé uma linguagem para especificação, documentação, visualização e desenvolvimento de sistemas orientados a objetos. Por meio de seus diagramas é possível representar sistemas de softwares sob diversas perspectivas de visualização.

17. UML • A UML é uma linguagem de modelagem não proprietária de terceira geração. A UML não é uma metodologia de desenvolvimento, o que significa que ela não diz para você o que fazer primeiro e em seguida ou como projetar seu sistema, mas ela lhe auxilia a visualizar seu desenho e a comunicação entre objetos.

18. A modelagem visual com UML • Permite a compreensão de detalhes de sistemas complexos; • Melhora a comunicação entre a equipe de projeto; • Fornece base não ambígua para a implementação; • Permite a formulação de alternativas de solução e sua comparação a baixo custo; • Captura os requisitos de modo preciso.

19. A Estrutura de Conceitos do UML “Elementos” Relações (relacionam “elementos”) Diagramas (agrupam “elementos”)

20. A EC do UML: Elementos • Elementos de Estrutura • Elementos de Comportamento • Elementos de Agrupamento • Elementos de Anotação

21. A EC do UML: Elementos Elementos de Estrutura

22. A EC do UML: Elementos

23. A EC do UML: Relações Tipos de Relações

24. Visão Funcional Diagrama de casos de utilização Diagrama de atividade Visão Dinâmica Diagrama de máquina de estados (state machine diagram) Diagrama de interação Diagrama de sequência Diagrama de comunicação Diagrama de visão geral da interação (interaction overview diagram) Diagrama temporal (timing diagram) Visão Estática ou Estrutural Diagrama de pacotes Diagrama de classes Diagrama de objetos Diagrama de estrutura composta (composite structure diagram) Diagrama de componentes Diagrama de instalação A EC do UML: Diagramas

25. A EC do UML: Exemplos Diagrama de Casos de Utilização: representa a visão do sistema na perspectiva dos seus utilizadores (e.g., UAnónimo no contexto do WebGTTI)

26. A EC do UML: Exemplos Diagrama de Classes: especifica a estrutura estática de um sistema segundo a abordagem baseada em objectos(e.g., classes do WebGTTI)

27. A EC do UML: Exemplos Diagrama de Sequências: especifica a dinâmica ou o comportamento de um sistema (e.g., registo de membro no WebGTTI)

28. A EC do UML: Exemplos Exemplo de um Diagrama de Atividades (processo de negócio “Fazer Proposta”)

29. A EC do UML: Exemplos Diagrama de Distribuição (e.g., arquitectura hardware de um sistemadistribuído)

30. A EC do UML: Exemplos Diagrama de (Transição de) Estados (e.g., daclasse “Termo” do WebGTTI)

31. Aplicação • A UML é uma linguagem para: • Visualização • Especificação • Construção • Documentação • A UML fornece um método padrão para descrever um sistema tendo em conta aspectos conceituais e/ou concretos.

32. Visualização • Modelos explícitos facilitam a comunicação • Algumas estruturas transcendem o que pode ser representado por uma linguagem de programação • Cada símbolo tem uma semântica bem definida.

33. Especificação • A notação UML permite a especificação das decisões importantes em nível de análise, projeto, implementação e implantação

34. Construção • Forward engineering • Geração de código com base no modelo • Background engineering • Geração do modelo com base no código • Round-Trip engineering • Ciclo iterativo de desenvolvimento com geração de código a parir de um modelo e atualização do modelo com base no código.

35. Documentação • A notação UML permite a criação de documentação do artefatos existentes no sistema: • Conceitos do problema • Cenários de instalação • É possível acrescentar links para documentação externa: • Documentos de requisitos, planos de testes, ...

36. Razões para modelar • Comunicar a estrutura e o comportamento desejado (desejável) para o sistema • Visualizar e controlar a arquitetura do sistema • Compreender o sistema e expor oportunidade de simplificação e reutilização • ...

37. Triângulo para o sucesso • Este conceito pertence a Terry Quatrani, autora do livro: Modelagem Visual com Rational Rose 2000 e UML.

38. Triângulo para o sucesso • Segundo Terry, para um projeto bem sucedido é necessário conhecer bem três coisas: Notação, Processo e Ferramenta. • Você pode saber uma notação, mas se não souber usar (Processar), terá falha; • Você pode ter um ótimo processo, mas se não souber comunicar (Notação), terá falha • Se não souber documentar seu trabalho (Ferramenta), terá falha.

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

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

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

42. Processo em cascata

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

44. 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. • Interativo e incremental.

45. Fases do Processo Unificado

46. Workflows do PU

47. Processo Unificado

48. 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”.

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

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