A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

O Paradigma de Orientação a Objetos no Processo de Desenvolvimento de Software Prof. Alcides Calsavara

Apresentações semelhantes


Apresentação em tema: "O Paradigma de Orientação a Objetos no Processo de Desenvolvimento de Software Prof. Alcides Calsavara"— Transcrição da apresentação:

1 O Paradigma de Orientação a Objetos no Processo de Desenvolvimento de Software Prof. Alcides Calsavara

2 Objetivos Apresentar um processo de desenvolvimento de software baseado em orientação a objetos Apresentar um processo de desenvolvimento de software baseado em orientação a objetos Facilitar a discussão sobre a adequação de um processo similar ao apresentado no contexto da empresa Facilitar a discussão sobre a adequação de um processo similar ao apresentado no contexto da empresa

3 Um breve histórico 1967: Simula 1967: Simula 1970 a 1980: Smalltalk 1970 a 1980: Smalltalk 1985 a 1986: C++, Objective-C, Eiffel, a 1986: C++, Objective-C, Eiffel, : Booch, OMT, : Booch, OMT, : CORBA 1992: CORBA 1994: UML 1994: UML 1995: Java (Web) 1995: Java (Web) 1998: UP 1998: UP

4 The Unified Software Development Process Colaboração com os mestrandos da PUCPR: Orlando Alcantara Soares Cláudia Barcaro

5 Conteúdo Descrever a arquitetura do Unified Process Descrever a arquitetura do Unified Process Em suas principais fases e métodos Em suas principais fases e métodos Apresentando os produtos gerados em cada fase Apresentando os produtos gerados em cada fase

6 Histórico do Unified Process O primeiro passo para o Unified Process foi o desenvolvimento da linguagem UML (Unified Modeling Language), primeiramente proposta por Grady Booch e Jim Rumbaugh como padrão de fato para modelagem de sistemas de software O primeiro passo para o Unified Process foi o desenvolvimento da linguagem UML (Unified Modeling Language), primeiramente proposta por Grady Booch e Jim Rumbaugh como padrão de fato para modelagem de sistemas de software

7 Histórico do Unified Process Grady Booch foi o autor do Booch Method, uma das primeiras metodologias a divulgar o paradigma da orientação a objetos em conjunto com práticas de programação Grady Booch foi o autor do Booch Method, uma das primeiras metodologias a divulgar o paradigma da orientação a objetos em conjunto com práticas de programação Jim Rumbaugh foi o principal desenvolvedor da OMT (Object Modeling Technique), no General Electric Research and Development Center Jim Rumbaugh foi o principal desenvolvedor da OMT (Object Modeling Technique), no General Electric Research and Development Center

8 Histórico do Unified Process Ivar Jacobson foi autor de Objectory tem sua origem em metodologia de desenvolvimento de sistemas ( ) desenvolvida pela Ericson sueca, segundo o conceito decomponent-based development, fortemente influenciada pelas técnicas de modularidade da área de telecomunicações Ivar Jacobson foi autor de Objectory tem sua origem em metodologia de desenvolvimento de sistemas ( ) desenvolvida pela Ericson sueca, segundo o conceito decomponent-based development, fortemente influenciada pelas técnicas de modularidade da área de telecomunicações

9 Histórico do Unified Process Na metodologia Objectory (Object Factory), Jacobson formalizou o conceito de use case, ( ) uma técnica para produzir especificações com base na visão do usuário final Na metodologia Objectory (Object Factory), Jacobson formalizou o conceito de use case, ( ) uma técnica para produzir especificações com base na visão do usuário final Em 1994, Rumbaugh aderiu à Rational, onde, juntamente com Booch, propôs a versão 0.8 do então denominado UM (Unified Method), publicado em 1995 Em 1994, Rumbaugh aderiu à Rational, onde, juntamente com Booch, propôs a versão 0.8 do então denominado UM (Unified Method), publicado em 1995

10 Histórico do Unified Process Com a adesão de Jacobson à Rational (1995), os três amigos propuseram a versão 0.9 da UML, como linguagem independente de metodologia Com a adesão de Jacobson à Rational (1995), os três amigos propuseram a versão 0.9 da UML, como linguagem independente de metodologia A UML 0.9 teve a adesão da IBM, HP e Microsoft A UML 0.9 teve a adesão da IBM, HP e Microsoft

11 Histórico do Unified Process Em novembro de 1997, a UML versão 1.1 foi aceita como padrão pelo OMG - Object Management Group, após um processo de análise de várias propostas (entre as quais OPEN) Em novembro de 1997, a UML versão 1.1 foi aceita como padrão pelo OMG - Object Management Group, após um processo de análise de várias propostas (entre as quais OPEN) Na Rational, Jacobson passou a coordenar o desenvolvimento do Rational Objectory Process como proposta de metodologia dos três amigos, em linguagem UML Na Rational, Jacobson passou a coordenar o desenvolvimento do Rational Objectory Process como proposta de metodologia dos três amigos, em linguagem UML

12 Histórico do Unified Process A partir de 1998, após numerosas complementações, o Objectory Process teve como sucessor o Rational Unified Process A partir de 1998, após numerosas complementações, o Objectory Process teve como sucessor o Rational Unified Process

13 Unified Process: O que é um processo ? Um processo de desenvolvimento de software é o conjunto de atividades necessárias para transformar requisitos de usuários em sistema de software. Um processo de desenvolvimento de software é o conjunto de atividades necessárias para transformar requisitos de usuários em sistema de software.

14 Unified Process: Pilares O Unified Process é um processo O Unified Process é um processo Dirigido por Use Case Dirigido por Use Case Centrado em Arquitetura Centrado em Arquitetura Iterativo e Incremental Iterativo e Incremental

15 Unified Process: Ambiente Tecnológico O Unified Process é um processo O Unified Process é um processo orientado a tecnologia de objetos orientado a tecnologia de objetos baseado em componentes baseado em componentes componentes de software interconectados por uma interface bem definida componentes de software interconectados por uma interface bem definida em linguagem UML em linguagem UML

16 Unified Process: Idéias Fundamentais Dirigido por Use Case ( use case driven ) Dirigido por Use Case ( use case driven ) use case é o artefato (artifact) primário para estabelecer o comportamento desejado do sistema e para comunicação entre seus participantes use case é o artefato (artifact) primário para estabelecer o comportamento desejado do sistema e para comunicação entre seus participantes use cases levam as especificações que descrevem o sistema sob o ponto de vista do usuário, sem antecipar decisões de implementação use cases levam as especificações que descrevem o sistema sob o ponto de vista do usuário, sem antecipar decisões de implementação

17 Unified Process: Idéias Fundamentais Modelo de Use Cases Modelo de Use Cases

18 Unified Process: Idéias Fundamentais Use case textual: Retirada de Dinheiro Use case textual: Retirada de Dinheiro Pré-condição: cliente possui conta que funciona com ATM Pré-condição: cliente possui conta que funciona com ATM 1. O ator cliente seleciona retirar dinheiro e identifica-se para a interface do ATM, possivelmente utilizando um cartão magnético com um número e uma senha 1. O ator cliente seleciona retirar dinheiro e identifica-se para a interface do ATM, possivelmente utilizando um cartão magnético com um número e uma senha 2. A interface ATM solicita ao subsistema Transaction Management a retirada do dinheiro. O Transaction Management é responsável por executar a seqüência de retirada como uma transação atômica, assim, o dinheiro é tanto deduzido da conta quanto entregue ao cliente 2. A interface ATM solicita ao subsistema Transaction Management a retirada do dinheiro. O Transaction Management é responsável por executar a seqüência de retirada como uma transação atômica, assim, o dinheiro é tanto deduzido da conta quanto entregue ao cliente 3. O Transaction Management solicita ao Account Management a retirada do dinheiro. O Account Management determina se o dinheiro pode ser retirado e, caso possa, deduz a quantia da conta e retorna uma resposta que especifica ser possível efetuar a retirada 3. O Transaction Management solicita ao Account Management a retirada do dinheiro. O Account Management determina se o dinheiro pode ser retirado e, caso possa, deduz a quantia da conta e retorna uma resposta que especifica ser possível efetuar a retirada 4. O Transaction Management autoriza a interface ATM a entregar o dinheiro 4. O Transaction Management autoriza a interface ATM a entregar o dinheiro 5. A interface ATM entrega o dinheiro ao cliente 5. A interface ATM entrega o dinheiro ao cliente

19 Unified Process: Idéias Fundamentais Dirigido por use case ( use case driven ) Dirigido por use case ( use case driven ) use case é o input básico para análise, projeto (design), implementação e teste do sistema use case é o input básico para análise, projeto (design), implementação e teste do sistema o conjunto dos use cases constituem o modelo de use case (use case model), que descreve a funcionalidade completa do sistema o conjunto dos use cases constituem o modelo de use case (use case model), que descreve a funcionalidade completa do sistema com base no modelo de use case, os desenvolvedores criam uma série de modelos de projeto e implementação que realizam os use cases com base no modelo de use case, os desenvolvedores criam uma série de modelos de projeto e implementação que realizam os use cases

20 Unified Process: Idéias Fundamentais Centrado em arquitetura (architecture- centric) Centrado em arquitetura (architecture- centric) A arquitetura de um software descreve as diferentes visões do sistema em construção A arquitetura de um software descreve as diferentes visões do sistema em construção A arquitetura se desenvolve a partir das visões do usuário expressas em use cases A arquitetura se desenvolve a partir das visões do usuário expressas em use cases A arquitetura é também influenciada por fatores de implementação: arquitetura de computador, sistema operacional, dbms, protocolos de rede, linguagem de programação, ambiente de interface gráfica, bibliotecas de funções disponíveis, sistemas legados, necessidades de performance, portabilidade etc. A arquitetura é também influenciada por fatores de implementação: arquitetura de computador, sistema operacional, dbms, protocolos de rede, linguagem de programação, ambiente de interface gráfica, bibliotecas de funções disponíveis, sistemas legados, necessidades de performance, portabilidade etc.

21 Arquitetura: C amadas de Componentes Classes específicas de negócio Classes de Serviços Pacotes Genéricos Sistema Operacional

22 Use Case e Arquitetura Como use case e arquitetura se relacionam? Como use case e arquitetura se relacionam? Use case é a funcionalidade; Arquitetura é a forma de realização Use case é a funcionalidade; Arquitetura é a forma de realização Os use cases dirigem a seleção de arquitetura e a arquitetura influencia a seleção de use cases Os use cases dirigem a seleção de arquitetura e a arquitetura influencia a seleção de use cases Use cases e arquitetura não podem ser considerados isoladamente Use cases e arquitetura não podem ser considerados isoladamente Use cases e Arquitetura devem evoluir em paralelo. Use cases e Arquitetura devem evoluir em paralelo.

23 Use Case e Arquitetura Vários fatores influenciam a arquitetura, não apenas os use cases Vários fatores influenciam a arquitetura, não apenas os use cases

24 Use Case e Arquitetura Trabalho Inicial Trabalho Inicial Buscar uma compreensão dos use cases fundamentais do sistema (de 5 a 10% do total de use cases) Buscar uma compreensão dos use cases fundamentais do sistema (de 5 a 10% do total de use cases) Delinear a arquitetura que é independente de use cases (ex.: plataforma de software) Delinear a arquitetura que é independente de use cases (ex.: plataforma de software) À medida em que a especificações dos use cases amadurecem, descobrem-se mais informações a respeito da arquitetura, o que leva a maior conhecimento sobre os use cases À medida em que a especificações dos use cases amadurecem, descobrem-se mais informações a respeito da arquitetura, o que leva a maior conhecimento sobre os use cases O processo continua, até que a arquitetura se torne estável O processo continua, até que a arquitetura se torne estável

25 Arquitetura: Fatores que influenciam Use cases Use cases Tipo de software a ser construído: sistema operacional, sistema de apoio a decisão etc. Tipo de software a ser construído: sistema operacional, sistema de apoio a decisão etc. Middleware: object broker, interfaces gráficas Middleware: object broker, interfaces gráficas Sistemas legados Sistemas legados Padrões e políticas: linguagem de definição de interfaces, padrões de telecomunicações Padrões e políticas: linguagem de definição de interfaces, padrões de telecomunicações Patterns utilizados Patterns utilizados Requisitos não funcionais: performance, tempo de recuperação Requisitos não funcionais: performance, tempo de recuperação Mecanismos genéricos: armazenamento em dbms Mecanismos genéricos: armazenamento em dbms Modo de distribuição: arquitetura cliente/servidor, internet Modo de distribuição: arquitetura cliente/servidor, internet

26 Unified Process: Idéias Fundamentais O que é uma Iteração O que é uma Iteração Uma iteração é um mini-projeto que resulta em um incremento do sistema Uma iteração é um mini-projeto que resulta em um incremento do sistema Uma iteração contém um grupo de use cases que ampliam a funcionalidade do produto até então desenvolvido Uma iteração contém um grupo de use cases que ampliam a funcionalidade do produto até então desenvolvido Como um mini-projeto, uma iteração passa pelas fases de análise, design, implementação e teste, podendo mesmo colocar os use cases (pertencentes à iteração) sob a forma de código executável Como um mini-projeto, uma iteração passa pelas fases de análise, design, implementação e teste, podendo mesmo colocar os use cases (pertencentes à iteração) sob a forma de código executável Uma iteração pode não acrescentar nova funcionalidade, mas adicionar detalhes a artefatos já existentes Uma iteração pode não acrescentar nova funcionalidade, mas adicionar detalhes a artefatos já existentes

27 Estrutura de uma Iteração Uma Iteração e seu Workflow Uma Iteração e seu Workflow

28 Concorrência de Iterações Iterações podem caminhar em paralelo Iterações podem caminhar em paralelo

29 Iteração, Use Case e Arquitetura O Processo é Iterativo e Incremental O Processo é Iterativo e Incremental Para cada iteração os desenvolvedores identificam os use cases relevantes, analisando-os segundo a arquitetura selecionada Para cada iteração os desenvolvedores identificam os use cases relevantes, analisando-os segundo a arquitetura selecionada O produto da iteração são componentes (modelos ou módulos executáveis) O produto da iteração são componentes (modelos ou módulos executáveis) Verifica-se então se os componentes satisfazem os use cases e a arquitetura Verifica-se então se os componentes satisfazem os use cases e a arquitetura Se a implementação atinge os objetivos (componentes satisfazem use cases e arquitetura), o desenvolvimento passa para a próxima iteração Se a implementação atinge os objetivos (componentes satisfazem use cases e arquitetura), o desenvolvimento passa para a próxima iteração Caso contrário, os desenvolvedores devem revisar as decisões anteriores e tentar uma nova abordagem Caso contrário, os desenvolvedores devem revisar as decisões anteriores e tentar uma nova abordagem

30 Benefícios do Processo Iterativo Redução de Riscos Redução de Riscos Caso necessário repetir a iteração, perde-se o esforço de um único incremento, não o de todo o projeto Caso necessário repetir a iteração, perde-se o esforço de um único incremento, não o de todo o projeto Reduzem-se os riscos de entrega de sistema fora do prazo; problemas são detectados em fase anterior à de testes globais Reduzem-se os riscos de entrega de sistema fora do prazo; problemas são detectados em fase anterior à de testes globais Iterações controladas reduzem o tempo global de desenvolvimento; os desenvolvedores trabalham mais eficientemente em objetivos menores Iterações controladas reduzem o tempo global de desenvolvimento; os desenvolvedores trabalham mais eficientemente em objetivos menores

31 Benefícios do Processo Iterativo Adequação a Requisitos Adequação a Requisitos Iterações controladas reconhecem uma realidade inevitável: Iterações controladas reconhecem uma realidade inevitável: necessidades e requisitos não podem ser adequadamente definidos por antecipação; necessidades e requisitos não podem ser adequadamente definidos por antecipação; mas devem ser refinados em iterações sucessivas mas devem ser refinados em iterações sucessivas Este modo de operar facilita a adaptação a alterações de requisitos Este modo de operar facilita a adaptação a alterações de requisitos

32 Unified Process: O Sistema Os Ciclos Os Ciclos O Unified Process é composto de uma série de ciclos O Unified Process é composto de uma série de ciclos Cada ciclo conclui com a entrega de um produto Cada ciclo conclui com a entrega de um produto Cada ciclo constitui-se de quatro fases: incepção, elaboração, construção e transição Cada ciclo constitui-se de quatro fases: incepção, elaboração, construção e transição cada fase se subdivide em iterações cada fase se subdivide em iterações

33 Ciclos de um Sistema A vida de um sistema consiste de ciclos A vida de um sistema consiste de ciclos

34 Estrutura do Ciclo Um ciclo com suas fases e iterações Um ciclo com suas fases e iterações

35 Unified Process: Fases de um Ciclo Incepção Incepção Cada iteração nesta fase focaliza a compreensão do problema e da tecnologia Cada iteração nesta fase focaliza a compreensão do problema e da tecnologia Essencialmente a fase corresponde às seguintes questões: Essencialmente a fase corresponde às seguintes questões: O que o sistema fará para cada um de seus usuários: modelo simplificado dos principais use cases O que o sistema fará para cada um de seus usuários: modelo simplificado dos principais use cases Como deve ser uma arquitetura para o sistema Como deve ser uma arquitetura para o sistema Qual é o plano e quanto custará para desenvolver o produto?: estimativa de custos Qual é o plano e quanto custará para desenvolver o produto?: estimativa de custos Cada iteração está voltada para a produção de use cases de negócio e da arquitetura preliminar Cada iteração está voltada para a produção de use cases de negócio e da arquitetura preliminar

36 Unified Process: Fases de um Ciclo Elaboração Elaboração Nesta fase, as iterações estão voltadas para a produção da arquitetura básica Nesta fase, as iterações estão voltadas para a produção da arquitetura básica Vários dos use cases são especificados com detalhes; a arquitetura do sistema é projetada Vários dos use cases são especificados com detalhes; a arquitetura do sistema é projetada A arquitetura é expressa em visões dos modelos do sistema: A arquitetura é expressa em visões dos modelos do sistema: modelo de use cases modelo de use cases modelo de análise modelo de análise modelo de projeto modelo de projeto modelo de implementação modelo de implementação modelo de distribuição (deployment) modelo de distribuição (deployment) O resultado da fase é o conjunto dos modelos acrescidos de elementos de implementação O resultado da fase é o conjunto dos modelos acrescidos de elementos de implementação

37 Unified Process: Fases de um Ciclo Construção Construção Nesta fase, as iterações estão voltadas para a produção de módulos executáveis, culminando com o desenvolvimento de um produto pronto para entrega à comunidade de usuários Nesta fase, as iterações estão voltadas para a produção de módulos executáveis, culminando com o desenvolvimento de um produto pronto para entrega à comunidade de usuários Durante esta fase o produto é construído Durante esta fase o produto é construído O sistema torna-se um produto pronto para ser posto à disposição da comunidade de usuários O sistema torna-se um produto pronto para ser posto à disposição da comunidade de usuários A arquitetura é estável, ainda que possa ser aperfeiçoada A arquitetura é estável, ainda que possa ser aperfeiçoada Ao final da fase, o sistema conterá todos os use cases que gerência e usuários concordaram em desenvolver para esta versão do produto Ao final da fase, o sistema conterá todos os use cases que gerência e usuários concordaram em desenvolver para esta versão do produto Erros poderão ser encontrados e serão corrigidos Erros poderão ser encontrados e serão corrigidos

38 Unified Process: Fases de um Ciclo Transição Transição Compreende o período em que o produto passa para beta-teste; a primeira versão é entregue aos usuários Compreende o período em que o produto passa para beta-teste; a primeira versão é entregue aos usuários A fase envolve atividades de treinamento de usuários, assistência de uso do produto e correção de defeitos encontrados após a entrega A fase envolve atividades de treinamento de usuários, assistência de uso do produto e correção de defeitos encontrados após a entrega Um pequeno número de usuários experientes utiliza o produto e reporta os erros e inadequações encontradas Um pequeno número de usuários experientes utiliza o produto e reporta os erros e inadequações encontradas Os desenvolvedores corrigem os erros e e incorporam melhoras Os desenvolvedores corrigem os erros e e incorporam melhoras

39 Visão Global das Fases O Processo O Processo

40 Pontos de Revisão (Milestones) Cada fase da Metodologia conclui com um Ponto de Revisão Cada fase da Metodologia conclui com um Ponto de Revisão Incepção: objetivos de negócio Incepção: objetivos de negócio Elaboração: arquitetura Elaboração: arquitetura Construção: capacidade operacional Construção: capacidade operacional Transição: entrega do produto Transição: entrega do produto Dentro de cada fase podem ser definidos Pontos de Revisão de menor amplitude (por ex., a cada iteração) Dentro de cada fase podem ser definidos Pontos de Revisão de menor amplitude (por ex., a cada iteração)

41 Pontos de Revisão (Milestones)

42 Unified Process: Produtos Modelos do Unified Process Modelos do Unified Process

43 Modelos por Fases Workflow do Unified Process Workflow do Unified Process

44 Fase de Requisitos Modelo de Use Case Modelo de Use Case O Modelo de use case representa os Requisitos Funcionais O Modelo de use case representa os Requisitos Funcionais Um use case especifica uma seqüência de ações, incluindo variantes, que o sistema realiza e que resulta em um resultado observável produzido por um determinado ator Um use case especifica uma seqüência de ações, incluindo variantes, que o sistema realiza e que resulta em um resultado observável produzido por um determinado ator Devem ser considerados em conjunto os use cases pertencentes a uma iteração Devem ser considerados em conjunto os use cases pertencentes a uma iteração

45 Fase de Requisitos Modelo de Use Case: Exemplo Modelo de Use Case: Exemplo

46 Fase de Análise Modelo de Análise Modelo de Análise O Modelo de Use Cases é a entrada para o Modelo de Análise O Modelo de Use Cases é a entrada para o Modelo de Análise O Modelo de Análise é uma especificação detalhada dos requisitos e é uma primeira aproximação do Modelo de Projeto O Modelo de Análise é uma especificação detalhada dos requisitos e é uma primeira aproximação do Modelo de Projeto O MA é usado pelos desenvolvedores para uma compreensão mais precisa dos use cases, definindo-os como uma colaboração entre tipos conceituais de objetos (sem detalhes de implementação) O MA é usado pelos desenvolvedores para uma compreensão mais precisa dos use cases, definindo-os como uma colaboração entre tipos conceituais de objetos (sem detalhes de implementação) Cada elemento conceitual do Modelo de Análise reaparecerá no correspondente Modelo de Projeto Cada elemento conceitual do Modelo de Análise reaparecerá no correspondente Modelo de Projeto

47 Fase de Análise Modelo de Análise Modelo de Análise Modelo de Análise a partir de Modelo de Use Case Modelo de Análise a partir de Modelo de Use Case

48 Fase de Análise Modelo de Análise Modelo de Análise O Modelo de Análise utiliza Diagrama de Colaboração para descrever a realização de um use case O Modelo de Análise utiliza Diagrama de Colaboração para descrever a realização de um use case O use case é descrito em termos de interação entre objetos e atores O use case é descrito em termos de interação entre objetos e atores O diagrama de colaboração pode ser complementado com texto, texto estruturado ou pseudocódigo O diagrama de colaboração pode ser complementado com texto, texto estruturado ou pseudocódigo O Modelo de Análise auxilia na descoberta dos tipos conceituais de objetos participantes do sistema e no modo como os objetos realizam atividades (funcionalidade dos objetos) O Modelo de Análise auxilia na descoberta dos tipos conceituais de objetos participantes do sistema e no modo como os objetos realizam atividades (funcionalidade dos objetos)

49 Fase de Análise Use Case: Modelo de Colaboração Use Case: Modelo de Colaboração

50 Fase de Análise Modelo de Análise e definição de Classe Modelo de Análise e definição de Classe As responsabilidades de uma classe são uma compilação dos papéis representados pela classe em todas as realizações de use cases (diagramas de colaboração) As responsabilidades de uma classe são uma compilação dos papéis representados pela classe em todas as realizações de use cases (diagramas de colaboração) Caso uma classe seja alterada, o desenvolvedor precisa verificar se ela continua realizando seu papel em cada realização de use case Caso uma classe seja alterada, o desenvolvedor precisa verificar se ela continua realizando seu papel em cada realização de use case

51 Fase de Projeto Modelo de Projeto Modelo de Projeto O Modelo de Projeto é uma descrição da implementação do sistema, a partir do Modelo de Análise O Modelo de Projeto é uma descrição da implementação do sistema, a partir do Modelo de Análise O Modelo de Projeto precisa adequar-se ao ambiente de implementação (tecnologia de distribuição de objetos, ambiente gráfico, dbms, reuso de sistemas legados, bibliotecas de patterns etc.) O Modelo de Projeto precisa adequar-se ao ambiente de implementação (tecnologia de distribuição de objetos, ambiente gráfico, dbms, reuso de sistemas legados, bibliotecas de patterns etc.) Existe um mapeamento direto entre os subsistemas do Modelo de Projeto e os componentes do Modelo de Implementação Existe um mapeamento direto entre os subsistemas do Modelo de Projeto e os componentes do Modelo de Implementação Subsistemas são grupamentos de classes e outros subsistemas Subsistemas são grupamentos de classes e outros subsistemas

52 Fase de Projeto Modelo de Projeto Modelo de Projeto O Modelo de Projeto define tipos de objetos, associações e colaborações entre os tipos O Modelo de Projeto define tipos de objetos, associações e colaborações entre os tipos Basicamente são as mesmas definições do Modelo de Análise. Entretanto, as definições do Modelo de Análise são conceituais, enquanto que as definições do Modelo de Projeto são voltadas para o ambiente operacional Basicamente são as mesmas definições do Modelo de Análise. Entretanto, as definições do Modelo de Análise são conceituais, enquanto que as definições do Modelo de Projeto são voltadas para o ambiente operacional Ou seja: O Modelo de Projeto é mais físico e o Modelo de Análise é mais conceitual Ou seja: O Modelo de Projeto é mais físico e o Modelo de Análise é mais conceitual

53 Modelo de Projeto Levantamento de Classes Levantamento de Classes

54 Modelo de Projeto Diagrama de Classes Diagrama de Classes

55 Modelo de Projeto Diagrama de Classes Diagrama de Classes O diagrama anterior exibe um diagrama de classes, não um diagrama de colaboração O diagrama anterior exibe um diagrama de classes, não um diagrama de colaboração O diagrama de classes introduz classes pertencentes ao ambiente de implementação, o que leva ao detalhamento do modelo conceitual O diagrama de classes introduz classes pertencentes ao ambiente de implementação, o que leva ao detalhamento do modelo conceitual É necessário detalhar a interação entre os objetos pertencentes às classes de projeto - isto é feito por meio de um diagrama de seqüência É necessário detalhar a interação entre os objetos pertencentes às classes de projeto - isto é feito por meio de um diagrama de seqüência

56 Modelo de Projeto Diagrama de Classe Diagrama de Classe

57 Modelo de Projeto Diagrama de Seqüência Diagrama de Seqüência O diagrama de seqüência mostra como o foco passa de objeto para objeto e mensagens são trocadas, durante a execução de um use case O diagrama de seqüência mostra como o foco passa de objeto para objeto e mensagens são trocadas, durante a execução de um use case Os desenvolvedores podem usar textos e pseudocódigo para complementar os diagramas de seqüência, para explicar detalhes de interação entre os objetos Os desenvolvedores podem usar textos e pseudocódigo para complementar os diagramas de seqüência, para explicar detalhes de interação entre os objetos

58 Modelo de Projeto Diagrama de Seqüência Diagrama de Seqüência

59 Modelo de Projeto Diagrama de Estados Diagrama de Estados Alguns objetos de projeto são controlados por estados Alguns objetos de projeto são controlados por estados O estado de seus atributos e operações determina o modo como o objeto reage a mensagens enviadas por outros objetos O estado de seus atributos e operações determina o modo como o objeto reage a mensagens enviadas por outros objetos As transições de estados são representadas por Diagramas de Estados, um importante elemento a ser utilizado durante a fase de implementação da classe correspondente ao objeto analisado As transições de estados são representadas por Diagramas de Estados, um importante elemento a ser utilizado durante a fase de implementação da classe correspondente ao objeto analisado

60 Modelo de Projeto Exemplo de Diagrama de Estados Exemplo de Diagrama de Estados

61 Modelo de Projeto Subsistemas Subsistemas O Modelo de Projeto pode conter uma quantidade excessivamente grande de classes (centenas ou milhares) O Modelo de Projeto pode conter uma quantidade excessivamente grande de classes (centenas ou milhares) É necessário um meio para grupar as classes que participam de determinados use cases, o que é feito por meio de subsistemas É necessário um meio para grupar as classes que participam de determinados use cases, o que é feito por meio de subsistemas Um subsistema é um grupamento de classes (e outros subsistemas) que possuem alguma afinidade semântica Um subsistema é um grupamento de classes (e outros subsistemas) que possuem alguma afinidade semântica A comunicação entre subsistemas e feita por meio de interfaces (oferecidos por classes dos subsistemas) A comunicação entre subsistemas e feita por meio de interfaces (oferecidos por classes dos subsistemas)

62 Modelo de Projeto Subsistemas Subsistemas

63 C amadas de subsistemas A arquitetura toma forma principalmente durante a fase de elaboração do sistema A arquitetura toma forma principalmente durante a fase de elaboração do sistema A arquitetura de um sistema é especificada por meio de sucessivas iterações, cada iteração acrescentando detalhes à iteração anterior A arquitetura de um sistema é especificada por meio de sucessivas iterações, cada iteração acrescentando detalhes à iteração anterior Cada iteração segue o padrão requisitos, análise, projeto, implementação, teste Cada iteração segue o padrão requisitos, análise, projeto, implementação, teste Cada iteração (de definição de arquitetura) focaliza os use cases arquitetonicamente relevantes e os elementos mencionados na transparência anterior Cada iteração (de definição de arquitetura) focaliza os use cases arquitetonicamente relevantes e os elementos mencionados na transparência anterior Ao final da fase de elaboração, obtem-se a architecture baseline, que é a coleção de modelos acrescida das especificações de arquitetura Ao final da fase de elaboração, obtem-se a architecture baseline, que é a coleção de modelos acrescida das especificações de arquitetura

64 C amadas de Subsistemas: Exemplo

65 C amadas de subsistemas: Layer Pattern A figura exibe o pattern de definição em camadas (Layer Pattern) A figura exibe o pattern de definição em camadas (Layer Pattern) Os componentes pertencentes a determinada camada apenas podem referenciar componentes pertencentes a uma camada inferior Os componentes pertencentes a determinada camada apenas podem referenciar componentes pertencentes a uma camada inferior O pattern simplifica e organiza a compreensão e a organização de sistemas complexos O pattern simplifica e organiza a compreensão e a organização de sistemas complexos O pattern reduz a dependência entre módulos, uma vez que camadas mais baixas desconhecem detalhes de interface com camadas situadas acima O pattern reduz a dependência entre módulos, uma vez que camadas mais baixas desconhecem detalhes de interface com camadas situadas acima Também facilita-se a identificação dos módulos a serem reutilizados, e dos módulos a serem adquiridos ou desenvolvidos Também facilita-se a identificação dos módulos a serem reutilizados, e dos módulos a serem adquiridos ou desenvolvidos

66 C amadas de subsistemas: Arquitetura Um sistema desenvolvido segundo a arquitetura do layer pattern situa os subsistemas aplicativos na camada do topo Um sistema desenvolvido segundo a arquitetura do layer pattern situa os subsistemas aplicativos na camada do topo Patterns de projeto, frameworks e bibliotecas de classes situam-se em camadas inferiores Patterns de projeto, frameworks e bibliotecas de classes situam-se em camadas inferiores Quanto mais abaixo localiza-se a camada, maior é a reutilização de módulos Quanto mais abaixo localiza-se a camada, maior é a reutilização de módulos A arquitetura das duas camadas inferiores pode ser estabelecida sem se levar em consideração os detalhes dos use cases, uma vez que essas camadas independem das especificações de negócios A arquitetura das duas camadas inferiores pode ser estabelecida sem se levar em consideração os detalhes dos use cases, uma vez que essas camadas independem das especificações de negócios

67 Subsistemas e suas Interfaces Estrutura estática da visão arquitetônica do modelo de projeto: diagrama de classes que exibe subsistemas e suas interfaces Estrutura estática da visão arquitetônica do modelo de projeto: diagrama de classes que exibe subsistemas e suas interfaces

68 Modelo de Projeto Subsistemas Subsistemas Cada subsistema é representado por um package da UML Cada subsistema é representado por um package da UML Vantagem em se utilizar interfaces entre subsistemas: o subsistema ATM Interface pode eventualmente ser substituído por outro de diferente implementação, sem que a alteração modifique a funcionalidade oferecida a Transaction Management Vantagem em se utilizar interfaces entre subsistemas: o subsistema ATM Interface pode eventualmente ser substituído por outro de diferente implementação, sem que a alteração modifique a funcionalidade oferecida a Transaction Management

69 Modelo de Projeto Subsistemas e Use Cases Subsistemas e Use Cases Modelo de colaboração de um use case: interação entre subsistemas e atores Modelo de colaboração de um use case: interação entre subsistemas e atores

70 Modelo de Distribuição (Deployment) O Modelo de Distribuição define a arquitetura física do sistema em termos de processadores (nodes) que se conectam O Modelo de Distribuição define a arquitetura física do sistema em termos de processadores (nodes) que se conectam Esses processadores são unidades de hardware em que os componentes de software podem ser executados Esses processadores são unidades de hardware em que os componentes de software podem ser executados Freqüentemente, a arquitetura física do sistema é conhecida antes mesmo do início de desenvolvimento do sistema Freqüentemente, a arquitetura física do sistema é conhecida antes mesmo do início de desenvolvimento do sistema Os processadores e suas conexões podem ser modelados no Modelo de Distribuição já durante o levantamento de requisitos Os processadores e suas conexões podem ser modelados no Modelo de Distribuição já durante o levantamento de requisitos

71 Diagrama de Distribuição O Modelo de Distribuição é representado em Diagramas de Distribuição (Deployment) O Modelo de Distribuição é representado em Diagramas de Distribuição (Deployment)

72 Modelo de Distribuição e Subsistemas

73 Modelo de Distribuição: Visão Aquitetônica Uma vez definidos os processadores, pode-se indicar a distribuição de funcionalidade por eles Uma vez definidos os processadores, pode-se indicar a distribuição de funcionalidade por eles O diagrama a seguir exibe a distribuição das classes ativas segundo o modo como elas são alocadas aos processadores O diagrama a seguir exibe a distribuição das classes ativas segundo o modo como elas são alocadas aos processadores

74 Fase de Implementação Modelo de Implementação: componentes que implementam classes Modelo de Implementação: componentes que implementam classes Um Modelo de Implementação contém todas as informações necessárias à produção de um sistema executável: componentes executáveis, componentes de bancos de dados etc. Um Modelo de Implementação contém todas as informações necessárias à produção de um sistema executável: componentes executáveis, componentes de bancos de dados etc. Um componente é uma parte física e substituível de um sistema; um componente provê um conjunto de interfaces Um componente é uma parte física e substituível de um sistema; um componente provê um conjunto de interfaces O Modelo de Implementação é constituído de elementos de software, os quais incluem todos os módulos executáveis (como ActiveX e JavaBeans) O Modelo de Implementação é constituído de elementos de software, os quais incluem todos os módulos executáveis (como ActiveX e JavaBeans)

75 Fase de Implementação Componentes no Modelo de Implementação Componentes no Modelo de Implementação

76 Fase de Implementação Componentes no Modelo de Implementação Componentes no Modelo de Implementação A figura anterior exibe componentes que implementam classes pertencentes ao modelo de projeto A figura anterior exibe componentes que implementam classes pertencentes ao modelo de projeto O componente de arquivo dispenser.c contém o código fonte e implementa três classes; este componente é compilado e ligado, juntamente com client.c, dentro do componente client.exe, o qual é executável O componente de arquivo dispenser.c contém o código fonte e implementa três classes; este componente é compilado e ligado, juntamente com client.c, dentro do componente client.exe, o qual é executável Se os componentes são implementados por meio de uma linguagem orientada a objetos, a implementação das classes é direta: cada classe do projeto corresponde a uma classe da implementação; cada componente de arquivo pode implementar várias dessas classes Se os componentes são implementados por meio de uma linguagem orientada a objetos, a implementação das classes é direta: cada classe do projeto corresponde a uma classe da implementação; cada componente de arquivo pode implementar várias dessas classes

77 Fase de Teste Teste dos Use Cases Teste dos Use Cases Durante a fase de teste, é verificado se o sistema implementa corretamente as especificações Durante a fase de teste, é verificado se o sistema implementa corretamente as especificações É desenvolvido um Modelo de Teste, que consiste de test cases e test procedures É desenvolvido um Modelo de Teste, que consiste de test cases e test procedures Um test case é um conjunto de entradas (input) de teste, condições de execução e resultados esperados, desenvolvidos para um objetivo particular, como verificar um determinado caminho em um use case Um test case é um conjunto de entradas (input) de teste, condições de execução e resultados esperados, desenvolvidos para um objetivo particular, como verificar um determinado caminho em um use case Uma test procedure é uma especificação de como executar o setup, a execução e a avaliação de resultados de um determinado test case Uma test procedure é uma especificação de como executar o setup, a execução e a avaliação de resultados de um determinado test case

78 Fase de Teste Exemplo de Test Case Exemplo de Test Case

79 Fase de Teste Test Case: descrição textual Test Case: descrição textual Input: Input: A conta possui saldo de $350 A conta possui saldo de $350 O cliente identifica-se corretamente O cliente identifica-se corretamente O cliente solicita a retirada de $200 da conta O cliente solicita a retirada de $200 da conta Há dinheiro suficiente no ATM (ao menos $200) Há dinheiro suficiente no ATM (ao menos $200) Resultado Resultado O saldo da conta decresce para $150 O saldo da conta decresce para $150 O cliente recebe $200 da ATM O cliente recebe $200 da ATM Condições Condições Nenhuma outra instância de use case está autorizada a acessar a conta durante o test case Nenhuma outra instância de use case está autorizada a acessar a conta durante o test case

80 Fundamentos da Metodologia revisitados Dirigido por Use Case (Use Case Driven): cada cada produto, em cada fase, tem sua origem em algum use case; ou seja, refere-se a algo que o usuário realmente necessita Dirigido por Use Case (Use Case Driven): cada cada produto, em cada fase, tem sua origem em algum use case; ou seja, refere-se a algo que o usuário realmente necessita Centrado em Arquitetura (Architecture Centric): o desenvolvimento é focado no pattern arquitetônico que guiará a construção do sistema desde sua fase inicial Centrado em Arquitetura (Architecture Centric): o desenvolvimento é focado no pattern arquitetônico que guiará a construção do sistema desde sua fase inicial Iterativo e Incremental: o software é desenvolvido em pequenos passos gerenciáveis; se você está satisfeito com um passo, você ajusta seu foco para o próximo passo: Iterativo e Incremental: o software é desenvolvido em pequenos passos gerenciáveis; se você está satisfeito com um passo, você ajusta seu foco para o próximo passo: Você planeja um pouco Você planeja um pouco Você especifica, projeta e implementa um pouco Você especifica, projeta e implementa um pouco Você integra, testa e executa cada iteração um pouco Você integra, testa e executa cada iteração um pouco

81 Referências [1] Jacobson, Ivar; Booch, Grady; Rumbaugh, James. The Unified Software Development Process. Addison-Wesley, 1999 [1] Jacobson, Ivar; Booch, Grady; Rumbaugh, James. The Unified Software Development Process. Addison-Wesley, 1999 [2] Rational Software Corporation. Unified Modeling Language - Notation Guide version 1.0. Rational Software Corporation, 1997 [2] Rational Software Corporation. Unified Modeling Language - Notation Guide version 1.0. Rational Software Corporation, 1997 [3] IBM, Rational Software, Unisys et al. Software Process Engineering Mamagement - The Unified Process Model (UPM). OMG doc. Number ad/ , May, 2000 [3] IBM, Rational Software, Unisys et al. Software Process Engineering Mamagement - The Unified Process Model (UPM). OMG doc. Number ad/ , May, 2000 [4] Kruchten, Philippe. A Rational Development Process [4] Kruchten, Philippe. A Rational Development Process [5] Rational, [5] Rational, [6] Rumbaugh, James; Jacobson, Ivar; Booch, Grady. The Unified Modeling Language Reference Manual. Addison- Wesley, 1998 [6] Rumbaugh, James; Jacobson, Ivar; Booch, Grady. The Unified Modeling Language Reference Manual. Addison- Wesley, 1998

82 Anexos

83 Processo centrado em Arquitetura: Refinamentos Sucessivos No contexto do ciclo de vida de um software, centrado em arquitetura significa que a seleção dos elementos estruturais (expressa nos modelos do sistema) e suas interfaces são elementos importantes para conceituação, construção, administração e evolução do sistema que está em desenvolvimento No contexto do ciclo de vida de um software, centrado em arquitetura significa que a seleção dos elementos estruturais (expressa nos modelos do sistema) e suas interfaces são elementos importantes para conceituação, construção, administração e evolução do sistema que está em desenvolvimento Os modelos do sistema passam por refinamentos sucessivos para incorporar elementos de implementação, percorrendo o caminho do mais conceitual para o mais concreto. Os modelos do sistema passam por refinamentos sucessivos para incorporar elementos de implementação, percorrendo o caminho do mais conceitual para o mais concreto. A incorporação sucessiva dos elementos de estrutura (detalhes de implementação) leva a uma reavaliação dos use cases A incorporação sucessiva dos elementos de estrutura (detalhes de implementação) leva a uma reavaliação dos use cases

84 Processo centrado em Arquitetura: Modularidade A boa arquitetura é aquela que divide o sistema em subsistemas (idealmente) autônomos A boa arquitetura é aquela que divide o sistema em subsistemas (idealmente) autônomos Cada subsistema oferece serviços a outros subsistemas por meio de uma (ou mais) interface bem definida Cada subsistema oferece serviços a outros subsistemas por meio de uma (ou mais) interface bem definida Deste modo reduzindo os problemas de comunicação entre módulos Deste modo reduzindo os problemas de comunicação entre módulos E tornando cada módulo independente da implementação de módulos pertencentes a outros subsistemas E tornando cada módulo independente da implementação de módulos pertencentes a outros subsistemas

85 Processo centrado em Arquitetura: Modularidade Interfaces estáveis permitem que o software situado em cada lado da interface possa evoluir independentemente, desde que preserve a interface Interfaces estáveis permitem que o software situado em cada lado da interface possa evoluir independentemente, desde que preserve a interface A modularidade de sistemas (subsistemas interligados por interfaces) facilita a escolha da arquitetura mais adequada para cada subsistema e viabiliza a utilização de bibliotecas de patterns A modularidade de sistemas (subsistemas interligados por interfaces) facilita a escolha da arquitetura mais adequada para cada subsistema e viabiliza a utilização de bibliotecas de patterns A modularização centrada em interfaces bem definidas é o mecanismo que viabiliza o reaproveitamento de soluções A modularização centrada em interfaces bem definidas é o mecanismo que viabiliza o reaproveitamento de soluções

86 Princípios que regem a arquitetura no Processo Unificado Modularidade Funcional: as Classes são grupadas em blocos funcionais (ou subsistemas), que os usuários possam tratar como opcionais; cada subsistema possui uma forte coesão interna; alterações no sistema devem ficar restritas a determinados subsistemas, sem alterar o sistema como um todo Modularidade Funcional: as Classes são grupadas em blocos funcionais (ou subsistemas), que os usuários possam tratar como opcionais; cada subsistema possui uma forte coesão interna; alterações no sistema devem ficar restritas a determinados subsistemas, sem alterar o sistema como um todo Separação Interface/Subsistema: o projeto das interfaces deve ser separado do projeto dos subsistemas; o objetivo é conseguir projetos plugáveis, em que diferentes subsistemas possam oferecer as mesmas interfaces; subsistemas possam ser substituídos ou alterados sem que haja qualquer alteração em seus clientes Separação Interface/Subsistema: o projeto das interfaces deve ser separado do projeto dos subsistemas; o objetivo é conseguir projetos plugáveis, em que diferentes subsistemas possam oferecer as mesmas interfaces; subsistemas possam ser substituídos ou alterados sem que haja qualquer alteração em seus clientes

87 Princípios que regem a arquitetura no Processo Unificado Mapeamento Subsistema/Componente: cada subsistema (projeto) é mapeado a um ou mais componentes (implementação); cada componente é executado em apenas uma estação de processamento (node); caso o subsistema seja executado em diferentes processadores (ex.: cliente e servidor), cada componente envolvido deve ser instanciado isoladamente (duplicado) em cada processador; este princípio facilita a distribuição e a alteração de software em diferentes instalações Mapeamento Subsistema/Componente: cada subsistema (projeto) é mapeado a um ou mais componentes (implementação); cada componente é executado em apenas uma estação de processamento (node); caso o subsistema seja executado em diferentes processadores (ex.: cliente e servidor), cada componente envolvido deve ser instanciado isoladamente (duplicado) em cada processador; este princípio facilita a distribuição e a alteração de software em diferentes instalações

88 Princípios que regem a arquitetura no Processo Unificado Isolamento de subsistemas: a troca de mensagens é o único meio de comunicação entre subsistemas; como as trocas de mensagens são assíncronas (inexistência de sincronização entre uma mensagem e sua resposta), os subsistemas possibilitam não apenas encapsulamento, mas também distribuição Isolamento de subsistemas: a troca de mensagens é o único meio de comunicação entre subsistemas; como as trocas de mensagens são assíncronas (inexistência de sincronização entre uma mensagem e sua resposta), os subsistemas possibilitam não apenas encapsulamento, mas também distribuição

89 Modelo de Implementação: Visão Aquitetônica O Modelo de Implementação é um mapeamento direto a partir dos Modelos de Projeto e de Distribuição O Modelo de Implementação é um mapeamento direto a partir dos Modelos de Projeto e de Distribuição Cada subsistema de projeto usualmente resulta em um componente para cada processador em que o subsistema precisa ser instalado Cada subsistema de projeto usualmente resulta em um componente para cada processador em que o subsistema precisa ser instalado Algumas vezes, porém, o mesmo componente é instalado e executado em diferentes processadores Algumas vezes, porém, o mesmo componente é instalado e executado em diferentes processadores Algumas linguagens provêm construções para a definição de packages de componentes (como JavaBeans) Algumas linguagens provêm construções para a definição de packages de componentes (como JavaBeans) As Classes também podem ser organizadas em arquivos de código que contêm os componentes As Classes também podem ser organizadas em arquivos de código que contêm os componentes


Carregar ppt "O Paradigma de Orientação a Objetos no Processo de Desenvolvimento de Software Prof. Alcides Calsavara"

Apresentações semelhantes


Anúncios Google