Análise e Projeto Orientados a Objeto

Transcrição

1 Análise e Projeto Orientados a Objeto com UML e Padrões Parte I Análise, Projeto, e Processo Baseado em Craig Larman 1

2 Aplicando UML, Padrões e APOO Objetivo Desenvolver habilidades práticas na utilização da TO para a criação de sistemas de software bem projetados, robustos, e modificáveis Linguagens OO são um primeiro passo necessário mas insuficiente Outros recursos importantes processo de desenvolvimento padrões UML Ilustrados na prática através de um estudo de caso detalhado 2

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 é Padrões GRASP descrevem princípios fundamentais para auxiliar na atribuição de responsabilidades Saber identificar objetos ou abstrações adequados é a segunda habilidade mais importante 3

4 O que é 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 Requisitos Casos de uso Restrições Vocabulário Objetos Arquitetura Instalação & Operação Interface do usuário 4

5 Conflito de Terminologias Termos Análise e Projeto não são fixos, mas usados ao longo de um contínuo Mais orientado a análise Mais orientado a projeto Significados variam de metodologia para metodologia Distinção é útil na prática, mas debater definições rígidas não é construtivo 5

6 O que é APOO? Na essência, considerar um problema e uma solução dentro da perspectiva de objetos, coisas ou conceitos O que é AOO? Investigação dos objetos de domínio e seus relacionamentos Descritos no Modelo de Objetos de Domínio O que é POO? Elaboração de uma solução lógica em termos de componentes de software e suas colaborações e responsabilidades Descritos em Diagramas de Classes e Diagramas de Interação 6

7 Representação de um Conceito na APOO Ex.: O conceito Livro em um sistema de biblioteca Conceito de domínio Representação na análise Representação no projeto título Livro título Livro imprimir() Representação no código public class Livro { public void imprimir(); private String titulo; } 7

8 Uma Analogia Organizando os Negócios de uma Empresa Analogia Quais são os processos de negócio? APOO Análise de requisitos Documentos Associados Casos de uso Quais são os papeis dos empregados? Análise do domínio Modelo conceitual 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 8

9 Um Exemplo Jogo de Dados Objetivo: ganha o jogo o jogador que rolar dois dados e tirar sete Modelagem na APOO Casos de uso Descrições narrativas de processos do domínio no formato de prosa estruturada Ex.: Caso de uso: Atores: Descrição: 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. 9

10 Um Exemplo Jogo de Dados Modelagem na APOO (cont.) Modelo conceitual Conceitos, atributos, e associações que são considerados importantes no domínio da aplicação Ex.: Jogador 1 Rola 2 Dado nome valor 1 Joga 1 2 JogoDeDados 1 Inclui Um modelo conceitual descreve conceitos do mundo real, não componentes de software! 10

11 Um Exemplo Jogo de Dados Modelagem na APOO (cont.) Diagramas de colaboração Alocação de responsabilidades para objetos ilustrando como eles interagem via mensagens Mostram o fluxo de mensagens entre instâncias e a invocação de métodos Ex.: joga() :Jogador 1: r1 := rola() d1 : Dado 2: r2 := rola() d2 : Dado 11

12 Um Exemplo Jogo de Dados Modelagem na APOO (cont.) Diagramas de classes de projeto Como os objetos (de software) se conectam? Quais são os métodos de uma classe? Ex.: Jogador Dado Rola nome valor 1 2 joga() rola() 1 2 Joga 1 JogoDeDados inicializa() 1 Inclui 12

13 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 Decomposição por objetos ou conceitos A&P Estruturados Decomposição por funções ou processos Catálogo Bibliotecário Sistema Livro Biblioteca Registra Empréstimos Adiciona Recursos Reporta Multas 13

14 A Linguagem de Modelagem Unificada UML 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 14

15 Origem e Evolução da UML Parceiros da UML UML 1.1 UML 1.0 UML 0.9 & 0.91 Unified Method 0.8 Industrialização (Set 97) Padronização (Jan 97) Unificação II (Out 96) Unificação I (Out 95) Booch 93 OMT-2 Outros métodos Booch 91 OMT-1 OOSE Fragmentação 15

16 16

17 Introdução à UML UML (Unified Modelling Language) É uma linguagem para especificação, construção, visualização e documentação de sistemas. É uma evolução das linguagens para especificação de conceitos de Booch, OMT e OOSE e também de outros métodos de especificação de requisitos orientados a objetos ou não. 17

18 Histórico da UML Início em Outubro de 1994: Booch e Jim Rumbaugh começaram um esforço para unificar o método de Booch e OMT Object Modeling Technique). Uma primeira versão chamada Unified Method, foi divulgada em outubro de Jacobson juntou-se a grupo, agregando o método OOSE (Object- Oriented Software Engineering). 18

19 Histórico da UML O esforço dos três resultou na liberação da UML versão 0.9 e 0.91 em junho e outubro de Em janeiro de 1997, foi liberada a versão 1.0 da UML. Adotada como padrão segundo a OMG (Object Management Group, ) em Novembro de 1997 UML 2.0 em

20 Introdução: UML 20

21 Ferramentas de Apoio Diversas empresas lançaram ferramentas para auxiliar a modelagem e projeto de sistemas utilizando UML, gerar código a partir da modelagem e projetos e realizar engenharia reversa, ou seja, obter o modelo em UML a partir do código. 21

22 Ferramentas de Apoio Exemplos: A família Rational Rose Interprise (da Rational Software Corporation que gera código em Smaltalk, PowerBuilder, C++, J++ e VB. ArgoUML- free tml (lista de ferramentas que envolvem a UML) MVCase: Desenvolvida por pesquisadores da UFSCAR. Disponível em 22

23 Diagramas da UML Diagramas de Casos de Uso Diagramas de classe Diagramas de Comportamento Diagrama de Estado Diagrama de Atividade Diagrama de Seqüência Diagrama de Colaboração Diagramas de Implementação Diagrama de Componente Diagrama de Implantação 23

24 Elementos Genéricos: Notas e Restrições Nota é um comentário inserido no diagrama: Restrições (constraint): é uma relação semântica entre elementos do modelo. Especifica condições ou proposições que devem ser mantidas verdadeiras. Uma restrição é mostrada como uma cadeia entre chaves {}. 24

25 Elementos Genéricos: Pacotes Pacotes agrupam elementos de modelagem. Pacotes podem conter classes, relacionamentos, classes abstratas, Packages, tipos, etc... 25

26 Elementos Genéricos: Estereótipos (stereotypes) Mecanismo de extensão introduzido pela UML, que permite estender o meta-modelo para suprir necessidades que não encontram-se entre os metaelementos disponíveis (desde que a definição semântica da própria linguagem não seja ferida). Deve ser baseado em certas classes existentes no metamodelo e deve estender estas classes apenas em certas formas pré-definidas, porém esses limites não são claramente especificados. 26

27 Elementos Genéricos: Estereótipos (stereotypes) Um estereótipo pode ser aplicado a classes, relacionamentos de dependência, atributos, operações, etc., por ex: <<abstract>>, <<metaclass>> 27

28 Material sobre UML (Rational) (Object Management Group) Page-Jones, M.; Fundamentos do desenho orientado a objeto com UML, Makron Books, Furlan, J.D.; Modelafem de Objetos Através da UML, Makron Bools, Rumbaugh, J., Jacobson, I., Booch, G; The Unified Modeling Language Reference Manual, Addison- Wesley, c1999. Conallen,J.; Building Web Applications with UML, Addison- Wesley, Fowler, M, Scott, K.; UML Essencial, Bookman,

29 Processo de Desenvolvimento Organização das atividades relacionas à produção e manutenção de sistemas de software Útil, mas um fator de segunda ordem O principal: equipe qualificada Boa equipe + bom processo = menor risco O processo racional unificado (RUP), baseado no modelo iterativo, é o processo padrão na indústria 29

30 O Processo Unificado 30

31 Objetivo Seguir um processo de desenvolvimento simples, da engenharia de requisitos à implementação 31

32 Modelos de Processo de Software Desenvolver software é geralmente uma tarefa complexa e sujeita a erros. Sucesso ou fracasso dependem de inúmeros fatores que ocorrem durante todo o processo. Necessidade de estabelecer processos sistemáticos para desenvolvimento -> modelos de processo de software 32

33 Exemplos de Modelos de Processo de Software Modelo em Cascata Modelo de Prototipagem Modelo Evolucionário Desenvolvimento Baseado em Componentes Modelo de Métodos formais Programação Extrema Processo Unificado 33

34 UML e Processo de Software A UML não define um processo padrão. A habilidade de saber como criar um bom projeto é mais importante do que seguir um método ou processo oficial. 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. 34

35 Princípios Básicos do PU Desenvolvimento iterativo Baseado em casos de uso Centrado na arquitetura 35

36 Desenvolvimento Interativo O desenvolvimento de um software é dividido em vários ciclos de iteração, cada qual produzindo um sistema testeaado, 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. 36

37 Desenvolvimento Iterativo 37

38 Desenvolvimento Interativo 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. 38

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

40 Baseado em 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). 40

41 Baseado em 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. 41

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

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

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

45 As Fases do PU Cada um dos ciclos de desenvolvimento do PU é dividido em quatro fases Concepção Elaboração Construção Transição 45

46 As Fases do PU 46

47 Fases do PU: Concepção Estabelece-se as 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. 47

48 Fases do PU: Elaboração Visão refinada do sistema, com a definição dos requisitos funcionais, detalhamento da arquitetura criada na fase anterior e gerenciamento contínuo dos riscos envolvidos. Estimativas realistas feitas nesta fase permitem um plano para orientar a construção do sistema. 48

49 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. É nesta fase que o desenvolvimento iterativo e incremental é realizado. 49

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

51 As disciplinas 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, atividades de trabalho, denominadas disciplinas do PU, são realizadas a qualquer momento durante o ciclo de desenvolvimento. As disciplinas 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. 51

52 As disciplinas do PU 52

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

54 Os Artefatos do PU 54

55 Definição de Modelos e Artefatos 55

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

57 O Modelo do Sistema 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 Modelo de Projeto: modelos relacionados à solução lógica. 57

58 Relacionamento entre os artefatos da fase planejar e elaborar Especificação de Requisitos Relatório de Investigação Preliminar Protótipos Casos de Uso a. Todos os de alto nível b. Alguns essenciais expandidos Diagramas de Casos de Uso Depende de Orçamento, Cronograma Esboço do modelo Conceitual Glossário 58

59 Um Processo Iterativo Simplificado Simplificação do processo iterativo unificado Plan. & Elaboração Construção Implantação Fácil extensão e customização Não inclui atividades importantes como Verificação & validação Divisão do trabalho Gerência de projeto Documentação 59

60 Fases Planejamento e Elaboração Concepção inicial, investigação de alternativas, definição de requisitos, etc. Construção Construção do sistema através de múltiplos ciclos de análise, projeto, implementação e teste Implantação Instalação e operação do sistema 60

61 Modelos e Artefatos Um modelo descreve e abstrai aspectos essenciais de um sistema Modelo estático (estrutura) Modelo dinâmico (comportamento) Modelos são compostos por artefatos diagramas e documentos que descrevem os elementos do modelo Na APOO, a UML é usada para descrever e visualizar os modelos e artefatos produzidos em cada fase do processo de desenvolvimento 61

62 Fase de Planejamento e Elaboração Plan. & Elaboração Construção Implantação 1. Definir Plano Inicial 2. Criar Rel. Prel. de Investigação 3. Definir Requisitos 4. Reg. Termos 5. Implementar 6. Definir Casos no Glossário Protótipo de Uso a b, d Notas 7. Definir Mod. Conc. Inicial c 8. Definir Arquit. Inicial a, c, d 9. Refinar Plano a. contínua b. opcional c. adiável d. ordem variada 62

63 Fase de Planejamento e Elaboração Atividades: 1. Definir plano inicial Prazos, recursos, orçamento 2. Criar relatório preliminar de investigação Motivação, alternativas, necessidades de negócio 3. Definir requisitos Especificação declarativa dos requisitos 4. Registrar termos no glossário Dicionário de termos, regras, restrições 5. Implementar protótipo Protótipo do sistema para ajudar na definição dos requisitos 63

64 Fase de Planejamento e Elaboração Atividades: 6. Definir casos de uso Descrição em prosa estruturada dos processos de negócio 7. Definir modelo conceitual inicial Objetos de domínio e seus relacionamentos 8. Definir arquitetura inicial Principais subsistemas e suas dependências 9. Refinar plano Atividades não lineares Ex.: 7, 4, 6 em paralelo 64

65 Fase de Construção Plan. & Elaboração Construção Implantação Ciclo de Desenv. 1 Ciclo de Desenv Refin. Plano Sinc. Artefatos Análise Projeto Impl. Teste 65

66 Fase de Construção Repetição de ciclos de desenvolvimento Construção progressiva do sistema até atingir uma versão que satisfaça corretamente os requisitos Atividades típicas de cada ciclo: 1. Refinar plano 2. Sincronizar artefatos 3. Análise 4. Projeto 5. Implementação 6. Teste 66

67 Ciclos de Desenvolvimento Cada ciclo implementa um conjunto reduzido de requisitos, adicionando novas funções ao sistema Crescimento incremental, através de expansões e refinamentos sucessivos Ciclos com tempo fixo de duas a oito semanas Vantagens: Evita complexidade excessiva Antecipa feedback dos usuários 67

68 Ciclos de Desenvolvimento e Casos de Uso Um ciclo deve atacar um ou mais casos de uso, ou versões simplificadas de casos de uso Casos de uso mais relevantes devem ser atacados nos primeiros ciclos Prioridade para serviços com grande influência na arquitetura do sistema ou de alto risco Ciclo de Desenv. 1 Ciclo de Desenv. 2 Ciclo de Desenv. 3 Caso de uso A Versão Simplificada Caso de uso A Versão Completa Caso de uso B Caso de uso C 68

69 Análise Notas Ciclo de Desenv. 1 Ciclo de Desenv a. se ainda não feito b. contínuo c. opcional Refin. Plano Sinc. Artefatos Análise Projeto Impl. Teste 1. Definir Casos de Uso Essenciais a 2. Refinar Diag. Casos de Uso 3. Refinar Modelo Conceitual 4. Refinar Glossário b 5. Definir Diag. Seq. 6. Definir Contrat. de Operação 7. Definir Diag. Estado c 69

70 Análise Subatividades: 1. Definir casos de uso essenciais 2. Refinar diagramas de casos de uso 3. Refinar modelo conceitual 4. Refinar glossário 5. Definir diagramas de seqüência do sistema 6. Definir contratos de operação 7. Definir diagramas de estado 70

71 Projeto Ciclo de Desenv. 1 Ciclo de Desenv Notas a. em paralelo com diag. interação b. ordem variada Refin. Plano Sinc. Artefatos Análise Projeto Impl. Teste 1. Definir Casos de Uso Reais 2. Definir Rel. & IU 3. Refinar Arquitetura b 4. Definir Diag. Interação 5. Definir Diag. Classes a 6. Definir Esquema do BD 71

72 Projeto Subatividades: 1. Definir casos de uso reais 2. Definir relatórios e interfaces com o usuário 3. Refinar arquitetura do sistema 4. Definir diagramas de interação 5. Definir diagramas de classes de projeto 6. Definir esquema do banco de dados 72