Análise Orientada a Objetos com UML

19,676 views
19,350 views

Published on

Apresentação sobre conceitos básicos de Análise Orientada a Objetos com UML

Published in: Education

Análise Orientada a Objetos com UML

  1. 1. Análise Orientada a Objetos<br />Prof. Eliseu Castelo Branco Jr.,PMP,MSc.<br />ecastelob@gmail.com<br />
  2. 2. Conceitos de Orientação a Objetos<br />Visão Geral da UML<br />Diagrama de Caso de Uso<br />Diagrama de Classes<br />Diagrama de Objetos<br />Diagramas de Interação<br />Diagrama de Estado<br />Diagrama de Atividades<br />Diagramas de Implementação<br />Ementa da Disciplina<br />
  3. 3. Cronograma de Aulas<br />
  4. 4. Provas sobre conteúdo teórico da disciplina (Av1, Av2, Av3)<br />Trabalhos de pesquisa publicados na Internet<br />Documentos de Análise e Projeto de software entregues<br />Exercícios realizados em sala de aula<br />OBS: mínimo de 75% de presença em sala de aula necessário para aprovação na disciplina.<br />Avaliações<br />
  5. 5. Sistemas de software são complexos.<br />O uso de modelos auxilia na compreensão de conceitos complexos.<br />Introdução<br />
  6. 6. O desenvolvimento de um sistema envolve grande quantidade de atividades e pessoas<br />Erros são inevitáveis e se identificados nos modelos sua correção é mais fácil e barata.<br />Introdução<br />
  7. 7. O uso de modelos reduz o custo do desenvolvimento de sistemas.<br />O modelo permite prever o comportamento do sistema no futuro.<br />Introdução<br />
  8. 8. A modelagem de sistemas de software consiste na utilização de notações gráficas e textuais com o objetivo de construir modelos que representam as partes essenciais de um sistema, considerando-se diversas perspectivas diferentes e complementares.<br />O que é modelagem de software?<br />
  9. 9. “Paradigma é a forma de abordar um problema”<br />Princípios:<br />Qualquer coisa é um objeto<br />Objetos realizam tarefas através da requisição de serviços a outros objetos<br />Cada objeto pertence a uma classe<br />A classe é um repositório para comportamento associado ao objeto<br />Classes são organizadas em hierarquias<br />Paradigma da Orientação a Objetos<br />
  10. 10. O paradigma da orientação a objetos visualiza um sistema de software como uma coleção de agentes interconectados chamados OBJETOS. Cada objeto realiza tarefas específicas. É através da interação entre objetos que uma tarefa computacional é realizada.<br />Paradigma da Orientação a Objetos<br />
  11. 11. Tipos de Sistemas<br />
  12. 12. O Sistema contem subsistemas<br />
  13. 13.
  14. 14.
  15. 15.
  16. 16.
  17. 17.
  18. 18.
  19. 19.
  20. 20.
  21. 21.
  22. 22.
  23. 23.
  24. 24.
  25. 25.
  26. 26.
  27. 27.
  28. 28. Subsistemas de um Sistema de Informação<br />
  29. 29. Módulos do Sistema (subsistemas)<br />
  30. 30. Classe Movimentação Financeira<br />Classe Bancos<br />Classe Rendas Diversas <br />Classe Contas a Pagar<br />Classe Receitas Diversas<br />Subsistema Contas a Pagar<br />
  31. 31. Classe Banco<br />Atributos<br />Métodos<br />
  32. 32. O que é Análise e Projeto?<br />Análise — “o quê”<br />Investigação do problema e dos requisitos<br />Projeto — “como”<br />Descrição de uma solução lógica<br />Requisitos<br />Casos de uso<br />Restrições<br />Vocabulário<br />Objetos<br />Arquitetura<br />Instalação & Operação<br />Interface do usuário<br />
  33. 33. Conceito<br />de domínio<br /> Representação<br />na análise<br /> Representação<br />no projeto<br />Livro<br />Livro<br />título<br />título<br />imprimir()<br />public class Livro<br />{<br />public void imprimir();<br />private String titulo;<br />}<br />Representação<br />no código<br />Representação de um Conceito na APOO<br />Ex.: O conceito “Livro” em um sistema de biblioteca<br />
  34. 34. Diagramas de classes de projeto, diagramas de colaboração<br />Atribuição de responsabilidades, projeto das interações<br />Quem é responsável por o quê? Como eles interagem?<br />Uma Analogia — Organizando os Negócios de uma Empresa <br />Documentos<br />Associados<br />APOO<br />Analogia<br />Casos de uso<br />Análise de requisitos<br />Quais são os processos de negócio?<br />Modelo conceitual<br />Análise do domínio<br />Quais são os papeis dos empregados?<br />
  35. 35. Um Exemplo — Jogo de Dados<br />Objetivo: ganha o jogo o jogador que rolar dois dados e tirar sete<br />Modelagem na APOO<br />Casos de uso<br />Descrições narrativas de processos do domínio no formato de prosa estruturada<br />Ex.: <br />Caso de uso:<br />Atores:<br />Descrição:<br />Jogar<br />Jogador<br />Este caso de uso começa quando<br />o jogador rola os dados. Se o total<br />dos dados for sete, o jogador ganha;<br />do contrário, ele perde.<br />
  36. 36. Um Exemplo — Jogo de Dados<br />Modelagem na APOO (cont.)<br />Modelo conceitual<br />Conceitos, atributos, e associações que são considerados importantes no domínio da aplicação<br />Ex.:<br />Um modelo conceitual descreve conceitos do mundo real, não componentes de software!<br />Jogador<br />Dado<br />2<br />1<br />Rola<br />nome<br />valor<br />2<br />1<br />Joga<br />1<br />JogoDeDados<br />1<br />Inclui<br />
  37. 37. Um Exemplo — Jogo de Dados<br />Modelagem na APOO (cont.) <br />Diagramas de colaboração<br />Alocação de responsabilidades para objetos ilustrando como eles interagem via mensagens<br />Mostram o fluxo de mensagens entre instâncias e a invocação de métodos<br />Ex.:<br />joga()<br />1: r1 := rola()<br />:Jogador<br />d1 : Dado<br />2: r2 := rola()<br />d2 : Dado<br />
  38. 38. Um Exemplo — Jogo de Dados<br />Modelagem na APOO (cont.) <br />Diagramas de classes de projeto<br />Como os objetos (de software) se conectam? <br />Quais são os métodos de uma classe?<br />Ex.:<br />Jogador<br />Dado<br />Rola<br />valor<br />nome<br />2<br />1<br />rola()<br />joga()<br />1<br />2<br />Joga<br />1<br />JogoDeDados<br />Inclui<br />1<br />inicializa()<br />
  39. 39. APOO X APE<br />Metodologias mais antigas, como Análise e Projeto Estruturados, baseiam-se em outras dimensões de decomposição<br />Sistema de<br />Biblioteca<br />Decomposição por objetos ou conceitos<br />Decomposição por funções ou processos<br />A&P Orientados a Objeto<br />A&P Estruturados<br />Sistema<br />Catálogo<br />Bibliotecário<br />Registra<br />Empréstimos<br />Livro<br />Adiciona<br />Recursos<br />Reporta<br />Multas<br />Biblioteca<br />
  40. 40. A Linguagem de Modelagem Unificada — UML<br />A UML é a linguagem padrão de diagramação para visualizar os resultados da análise e projeto<br />A notação (a própria UML) é relativamente trivial<br />Muito mais importante: habilidade para modelar com objetos<br />Só aprender a notação UML não ajuda<br />A UML não é<br />um processo ou metodologia<br />APOO<br />regras de projeto <br />
  41. 41. Origem e Evolução da UML<br />UML 1.1<br />Industrialização<br />(Set’97)<br />UML 1.0<br />Padronização<br />(Jan’97)<br />Parceiros<br />da UML<br />UML 0.9 & 0.91<br />Unificação II<br />(Out’96)<br />Unified Method 0.8<br />Unificação I<br />(Out’95)<br />Booch’93<br />OMT-2<br />Outros <br />métodos<br />OOSE<br />Booch’91<br />OMT-1<br />Fragmentação<br />
  42. 42.
  43. 43. Processo de Desenvolvimento<br />Organização das atividades relacionadas à produção e manutenção de sistemas de software<br />Útil, mas um fator de segunda ordem<br />O principal: equipe qualificada<br />Boa equipe + bom processo = menor risco<br />O processo racional unificado (RUP), baseado no modelo iterativo, é o processo padrão na indústria<br />
  44. 44. Sol, Mar e UML<br />
  45. 45. Visões da UML<br />
  46. 46. Uma série de pesquisas (www.embeddded-forecast.com) tem mostrado que muitos projetos de software embarcados são entregues com atraso ou cancelados. <br />Em média, observou-se que mais de 50% dos projetos têm seus cronogramas atrasados em pelo menos quatro meses e cerca de 11% são cancelados.<br />
  47. 47. O custo dos atrasos pode ser significativo. Por exemplo, no setor de aviônicos o custo dos atrasos é estimado de 50.000 a 300.000 dólares por mês.<br />Outro problema apontado é o nível de conformidade do produto final com as especificações. <br />Identificou-se que pelo menos 30% dos projetos não alcançavam 50% das especificações propostas de performance ou funcionalidade. <br />
  48. 48. À medida que os sistemas embarcados aumentam em complexidade, esta situação tende a piorar. <br />A pesquisa mostrou também que adoção de UML (UnifiedModelingLanguage) ainda não é uma prática comum.<br />
  49. 49. Ações (*) : unidade básica de especificação de comportamento. Ações estão contidas em atividades<br />Artefatos (*) : Pedaço físico da informação usado ou produzido durante o desenvolvimento do sistema<br />Atividades<br />Casos de Uso<br />Classes<br />Classes ativas<br />Colaboração<br />Componente<br />Estado<br />Interação<br />Interface<br />Elementos básicos do modelo UML<br />
  50. 50. No<br />Nota<br />Pacote<br />Partes (*)<br />Portas (*)<br />Estereótipos (*)<br />Valores de etiqueta (*)<br />Restrições (*)<br />Elementos básicos do modelo UML<br />

×