Análise e Projeto Orientados a Objeto com UML e Padrões

1. Análise e Projeto Orientados a Objetocom UML e Padrões Parte I Introdução Prof. Msc. Emerson Silas Dória

2. Aplicando UML, Padrões e APOO • Objetivo • Desenvolver habilidades práticas em APOO para a criação de sistemas de software bem projetados, robustos e modificáveis. • LPOO são um primeiro passo necessário, mas insuficiente • Outros recursos importantes • processo de desenvolvimento • padrões • UML • Práticas através de estudo de caso detalhado Prof. Msc. Emerson Silas Dória

3. Atribuindo Responsabilidades • Saber a maneira adequada de atribuir responsabilidades a componentes de software é a habilidade mais importante na APOO • Mais difícil de dominar • Afeta com mais profundidade a robustez, modificabilidade e reusabilidade do sistema Prof. Msc. Emerson Silas Dória

4. Atribuindo Responsabilidades • Padrões descrevem princípios fundamentais para auxiliar na atribuição de responsabilidades, ex: GRASP • Saber identificar objetos ou abstrações adequados é a segunda habilidade mais importante Prof. Msc. Emerson Silas Dória

5. O que são Análise e Projeto? Análise — “o quê” investigação do problema e dos requisitos Projeto — “como” descrição de uma solução lógica Quais os processos de negócio relacionados com o seu uso? Como exatamente o software irá capturar e registrar informações? Prof. Msc. Emerson Silas Dória

6. Conflito de Terminologias • Termos “Análise” e “Projeto” não são fixos, mas usados ao longo de um contínuo • Significados variam de metodologia para metodologia • Distinção é útil na prática, mas debater definições rígidas não é construtivo Mais orientado a projeto Mais orientado a análise Prof. Msc. Emerson Silas Dória

7. O que é APOO? • A essência da APOO é enfatizar a consideração de um domínio de problema e uma solução lógica, segundo a perspectiva de objetos (coisas, conceitos e entidades) • O que é Análise OO? • Ênfase na descoberta e na descrição dos objetos. • O que é Projeto OO? • Ênfase na definição de elementos lógicos de software. Prof. Msc. Emerson Silas Dória

8. Conceito de domínio Representação na análise Representação no projeto Livro Livro título título imprimir() public class Livro { public void imprimir(); private String titulo; } Representação no código Representação de um conceito na APOO • Exemplo: O conceito “Livro” em um sistema de biblioteca. Prof. Msc. Emerson Silas Dória

9. Quem é responsável por o quê? Como eles interagem? Atribuição de responsabilidades, projeto das interações Diagramas de classes de projeto, diagramas de colaboração Uma analogia — Organizando os negócios de uma empresa Analogia de Negócio APOO Documentos Associados Quais são os processos de negócio? Análise de requisitos Casos de uso Quais são os papeis dos empregados? Análise do domínio Modelo conceitual Prof. Msc. Emerson Silas Dória

10. Jogo de DadosExemplo • Objetivo: ganha o jogo o jogador que rolar dois dados e tirar sete Processo de Software OO Definir Modelo Conceitual Definir Diagramas de Interação Definir Casos de Uso Definir Diagramas Classes de Projeto Prof. Msc. Emerson Silas Dória

11. Jogo de DadosExemplo continuação... • Casos de Uso • Descrições narrativas de processos do domínio no formato de prosa estruturada Jogar Jogador Este caso de uso começa quando o jogador rola os dados. Se o total dos dados for sete, o jogador ganha; do contrário, ele perde. Caso de uso: Atores: Descrição: Prof. Msc. Emerson Silas Dória

12. Jogo de DadosExemplo continuação... • Modelo Conceitual • Conceitos, atributos, e associações que são considerados importantes no domínio do problema Jogador Dado 1 2 lança ValorDaFace Nome 1 2 joga 1 JogoDeDados 1 inclui Prof. Emerson Silas Dória - FIPP

13. Jogo de DadosExemplo continuação... • Modelo Conceitual • Um modelo conceitual descreve conceitos do mundo real, não componentes de software! Prof. Msc. Emerson Silas Dória

14. Jogar( ) 1: r1 := Lançar( ) :Jogador d1 : Dado 2: r2 := Lançar( ) d2 : Dado Jogo de DadosExemplo continuação... • Diagramas de Interação Diagrama de Colaboração • Alocação de responsabilidades para objetos e ilustração de como eles interagem via mensagens • Mostram o fluxo de mensagens entre instâncias e a invocação de métodos Prof. Msc. Emerson Silas Dória

15. Jogo de DadosExemplo continuação... • Diagramas de Interação Diagrama de Seqüência :JogoDeDados d1:Dado d2:Dado Jogar() Lançar( ) vf1:=ObterValorDaFace( ) Lançar( ) vf2:=ObterValorDaFace( ) Prof. Msc. Emerson Silas Dória

16. Jogador JogoDeDados Nome Jogar( ) Inicializar( ) Dado Valordaface:int Lançar( ) Jogo de DadosExemplo continuação... • Diagramas de Classes de Projeto • Como os objetos (de software) se conectam? • Quais são os métodos de uma classe? Versão 1 1 2 2 1 Prof. Msc. Emerson Silas Dória

17. JogoDeDados d1,d2:Dado Jogar( ) Dado Valordaface:int Lançar( ) ObterValorDaFace():int Jogo de DadosExemplo continuação... • Diagramas de Classes de Projeto • Como os objetos (de software) se conectam? • Quais são os métodos de uma classe? Versão 2 1 2 Prof. Msc. Emerson Silas Dória

18. APOO X APE • Metodologias mais antigas, como Análise e Projeto Estruturados, baseiam-se em outras dimensões de decomposição Sistema de Biblioteca A&P Orientados a Objeto A&P Estruturados decomposição por objetos ou conceitos decomposição por funções ou processos Sistema Catálogo Bibliotecário Registra Empréstimos Livro Adiciona Recursos Reporta Multas Biblioteca Prof. Msc. Emerson Silas Dória

19. A Linguagem de Modelagem Unificada • A UML é a linguagem padrão de diagramação para visualizar os resultados da análise e projeto • A notação (a própria UML) é relativamente trivial • Muito mais importante: habilidade para modelar com objetos • Só aprender a notação UML não ajuda • A UML não é • um processo ou metodologia • APOO • regras de projeto Prof. Msc. Emerson Silas Dória

20. UML 1.1 Industrialização (Set’97) UML 1.0 Padronização (Jan’97) Parceiros da UML UML 0.9 & 0.91 Unificação II (Out’96) Unified Method 0.8 Unificação I (Out’95) Booch’93 OMT-2 Outros métodos OOSE Booch’91 OMT-1 Fragmentação Origem e Evolução da UML Prof. Msc. Emerson Silas Dória

21. Processo de Desenvolvimento • Um processo de desenvolvimento de software é um método para organizar as atividades relacionadas à criação, entrega e manutenção de sistemas de software. • A habilidade de saber como criar um bom projeto é mais importante do que seguir um método ou processo oficial. Prof. Msc. Emerson Silas Dória

22. Processo de Desenvolvimento • Essa habilidade é adquirida dominando-se um conjunto de princípios e heurísticas para identificar e abstrair um conjunto relevante de objetos e atribuir responsabilidade a eles. • Em essência, a descrição de um processo inclui atividades que vão da análise dos requisitos até a instalação. • O material apresentado (e a disciplina) não vão tratar de atividades tais como: concepção, planejamento, gerenciamento, documentação e teste. Prof. Msc. Emerson Silas Dória

23. Processo de Desenvolvimento • UML padroniza artefatos e notação, mas não define um processo-padrão, razões: • Aumentar a probabilidade de aceitação ampla de uma notação de modelagem padronizada; • Variação significativa naquilo que constitui um processo apropriado; Prof. Msc. Emerson Silas Dória

24. Processo Iterativo Simplificado • Planejar e Elaborar: planejamento, definição de requisitos, protótipo, etc; • Construir: a construção do sistema; • Instalar: a colocação em uso do sistema; instalar planejar elaborar construir Prof. Msc. Emerson Silas Dória

25. Desenvolvimento Iterativo • Um ciclo de vida iterativo envolve a repetição de vários ciclos de planejamento, elaboração, construção e instalação. • O sistema cresce pela adição de novas funções (e refinamento das existentes) em cada ciclo iterativo. • Cada ciclo ataca um pequeno conjunto de requisitos. Prof. Msc. Emerson Silas Dória

26. Sinc. Artefatos Análise Projeto Desenvolvimento Iterativo Plan. & Elaboração Construção Implantação Ciclo de Desenv. 1 Ciclo de Desenv. 2 ... Refin. Plano Impl. Teste Prof. Msc. Emerson Silas Dória

27. Casos de Uso e CVIs • Um caso de uso é uma descrição textual (narrativa) de um processo do domínio. Exemplo: “Emprestar um livro da biblioteca” • Os ciclos de desenvolvimento iterativos são organizados com base nos requisitos de um conjunto de casos de uso. • Os casos de uso devem ser classificados e os mais importantes devem ser atacados nos CVIs iniciais, bem como requisitos não funcionais. Prof. Msc. Emerson Silas Dória

28. ... CVIs baseados em Casos de Uso Ciclo de Desenvolvi-mento 1 Ciclo de Desenvolvi-mento 2 Ciclo de Desenvolvi-mento 3 Caso de uso A Versão Completa --- --- Caso de uso A Versão Simplificada --- --- Caso de uso B Caso de uso C Prof. Msc. Emerson Silas Dória

29. Planejar e Elaborar a:permanente b:opcional c: pode atrasar d: qq ordem • Definir plano inicial • Criar Relatório de Investigação Preliminar • Definir Requisitos • Registrar termos no glossário (a) • Implementar protótipo (b,d) • Definir casos de uso(alto nível e essenciais) • Definir modelo conceitual inicial • Definir a arquitetura inicial do sistema(a,c,d) • Refinar o plano Prof. Msc. Emerson Silas Dória

30. Análise • Definir os casos de uso essenciais (se ainda não foi feito) • Refinar os diagramas de casos de uso • Refinar o modelo conceitual • Refinar o glossário (permanente) • Refinar os Diagramas de Seqüência do Sistema • Definir os contratos de operação • Definir os diagramas de estado (opcional) Prof. Msc. Emerson Silas Dória

31. Projeto • Definir casos de uso reais • Definir Relatórios, Interface e Storyboards • Refinar a arquitetura do sistema (qq ordem) • Definir diagramas de interação • Definir diagramas de classe do projeto (em paralelo com diagramas de interação) • Definir esquema da base de dados Prof. Msc. Emerson Silas Dória

32. Casos de Uso e CVIs • Na fase de planejamento e elaboração, criar todos os casos de uso de alto nível, mas refinar apenas os mais críticos e importantes, deixando os demais para outros CVIs. Prof. Msc. Emerson Silas Dória

33. Definição de Modelos e Artefatos • O mundo real é complexo e cheio de detalhes, por isso ele deve ser decomposto em partes, chamadas de modelos, que descrevem e abstraem aspectos essenciais dos sistemas. • Modelos são compostos de outros modelos, que são chamados de artefatos - diagramas e documentos – e são visualizados em visões. • Os modelos podem enfatizar aspectos dinâmicos e estáticos do sistema. Prof. Msc. Emerson Silas Dória

34. Definição de Modelos e Artefatos • Modelo de Análise: modelos relacionados a uma investigação do domínio e do espaço do problema, mas não à solução. • Modelo de Projeto: modelos relacionados à solução lógica. Prof. Msc. Emerson Silas Dória