o paradigma de orientação a objetos no processo de desenvolvimento de software prof. alcides...

O Paradigma de Orientação a O Paradigma de Orientação a Objetos no Processo de Objetos no Processo de Desenvolvimento de SoftwareDesenvolvimento de Software

Prof. Alcides CalsavaraProf. Alcides Calsavara

PUCPRPUCPR

[email protected]@ppgia.pucpr.br

ObjetivosObjetivos

Apresentar um processo de Apresentar um processo de desenvolvimento de software baseado desenvolvimento de software baseado em orientação a objetosem orientação a objetos

Facilitar a discussão sobre a Facilitar a discussão sobre a adequação de um processo similar ao adequação de um processo similar ao apresentado no contexto da empresaapresentado no contexto da empresa

Um breve históricoUm breve histórico

1967: Simula1967: Simula 1970 a 1980: Smalltalk1970 a 1980: Smalltalk 1985 a 1986: C++, Objective-C, Eiffel, ...1985 a 1986: C++, Objective-C, Eiffel, ... 1980-1990: Booch, OMT, ...1980-1990: Booch, OMT, ... 1992: CORBA1992: CORBA 1994: UML1994: UML 1995: Java (Web)1995: Java (Web) 1998: UP1998: UP

The Unified Software The Unified Software Development ProcessDevelopment Process

Colaboração com os mestrandos da Colaboração com os mestrandos da PUCPR:PUCPR:

Orlando Alcantara SoaresOrlando Alcantara Soares

Cláudia BarcaroCláudia Barcaro

ConteúdoConteúdo

Descrever a arquitetura do Unified Descrever a arquitetura do Unified ProcessProcess

Em suas principais fases e métodosEm suas principais fases e métodos Apresentando os produtos gerados Apresentando os produtos gerados

em cada faseem cada fase

Histórico do Unified ProcessHistórico do Unified Process

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


Grady Booch foi o autor do “Booch Grady Booch foi o autor do “Booch Method”, uma das primeiras Method”, uma das primeiras metodologias a divulgar o paradigma metodologias a divulgar o paradigma da orientação a objetos em conjunto da orientação a objetos em conjunto com práticas de programaçãocom práticas de programação

Jim Rumbaugh foi o principal Jim Rumbaugh foi o principal desenvolvedor da OMT (Object desenvolvedor da OMT (Object Modeling Technique), no General Modeling Technique), no General Electric Research and Development Electric Research and Development CenterCenter


Ivar JacobsonIvar Jacobson foi autorfoi autor de Objectory de Objectory tem sua origem em metodologia de tem sua origem em metodologia de desenvolvimento de sistemas (1967-desenvolvimento de sistemas (1967-1987) desenvolvida pela Ericson 1987) desenvolvida pela Ericson sueca, segundo o conceito de sueca, segundo o conceito de ““componentcomponent--basedbased developmentdevelopment”, ”, fortemente influenciada pelas técnicas fortemente influenciada pelas técnicas de modularidade da área de de modularidade da área de telecomunicaçõestelecomunicações


Na metodologia Na metodologia ObjectoryObjectory (“ (“ObjectObject FactoryFactory”), Jacobson formalizou o ”), Jacobson formalizou o conceito de “conceito de “use caseuse case” , (1985-1987) ” , (1985-1987) uma técnica para produzir uma técnica para produzir especificações com base na visão do especificações com base na visão do usuário final usuário final

Em 1994, Rumbaugh aderiu à Em 1994, Rumbaugh aderiu à Rational, onde, juntamente com Rational, onde, juntamente com Booch, propôs a versão 0.8 do então Booch, propôs a versão 0.8 do então denominado UM (Unified Method), denominado UM (Unified Method), publicado em 1995publicado em 1995


Com a adesão de Jacobson à Rational Com a adesão de Jacobson à Rational (1995), “os três amigos” propuseram (1995), “os três amigos” propuseram a versão 0.9 da UML, como linguagem a versão 0.9 da UML, como linguagem independente de metodologiaindependente de metodologia

A UML 0.9 teve a adesão da IBM, HP e A UML 0.9 teve a adesão da IBM, HP e MicrosoftMicrosoft


Em novembro de 1997, a UML versão Em novembro de 1997, a UML versão 1.1 foi aceita como padrão pelo OMG - 1.1 foi aceita como padrão pelo OMG - Object Management Group, após um Object Management Group, após um processo de análise de várias processo de análise de várias propostas (entre as quais OPEN)propostas (entre as quais OPEN)

Na Rational, Jacobson passou a Na Rational, Jacobson passou a coordenar o desenvolvimento do coordenar o desenvolvimento do Rational Objectory ProcessRational Objectory Process como como proposta de metodologia dos “três proposta de metodologia dos “três amigos”, em linguagem amigos”, em linguagem UMLUML


A partir de 1998, após numerosas A partir de 1998, após numerosas complementações, o complementações, o ObjectoryObjectory ProcessProcess teve como sucessor o teve como sucessor o RationalRational UnifiedUnified ProcessProcess

Unified Process: O que é um Unified Process: O que é um processo ?processo ? Um Um processoprocesso de desenvolvimento de de desenvolvimento de

software é o conjunto de software é o conjunto de atividadesatividades necessárias para transformar necessárias para transformar requisitos de usuários em sistema de requisitos de usuários em sistema de software.software.

Unified Process: PilaresUnified Process: Pilares

O Unified Process é um processoO Unified Process é um processo Dirigido por Use CaseDirigido por Use Case Centrado em ArquiteturaCentrado em Arquitetura Iterativo e IncrementalIterativo e Incremental

Unified Process:Unified Process: Ambiente TecnológicoAmbiente Tecnológico

O Unified Process é um processoO Unified Process é um processo orientado a tecnologia de objetosorientado a tecnologia de objetos baseado em componentesbaseado em componentes

componentes de software componentes de software interconectados por uma interface interconectados por uma interface bem definidabem definida

em linguagem UMLem linguagem UML

Unified Process:Unified Process: Idéias Fundamentais Idéias Fundamentais

Dirigido por Use Case (Dirigido por Use Case (use case drivenuse case driven)) use case é o artefato (artifact) primário use case é o artefato (artifact) primário

para estabelecer o comportamento para estabelecer o comportamento desejado do sistema e para comunicação desejado do sistema e para comunicação entre seus participantesentre seus participantes

use cases levam as especificações que use cases levam as especificações que descrevem o sistema sob o ponto de descrevem o sistema sob o ponto de vista do usuário, sem antecipar decisões vista do usuário, sem antecipar decisões de implementaçãode implementação


Modelo de Use CasesModelo de Use Cases

Unified Process:Unified Process: Idéias Fundamentais Idéias Fundamentais Use case textual: Retirada de DinheiroUse case textual: Retirada de Dinheiro

Pré-condição: cliente possui conta que funciona com Pré-condição: cliente possui conta que funciona com ATMATM

1. O ator cliente seleciona retirar dinheiro e identifica-se 1. O ator cliente seleciona retirar dinheiro e identifica-se para a interface do ATM, possivelmente utilizando um para a interface do ATM, possivelmente utilizando um cartão magnético com um número e uma senhacartão magnético com um número e uma senha

2. A interface ATM solicita ao subsistema Transaction 2. A interface ATM solicita ao subsistema Transaction Management a retirada do dinheiro. O Transaction Management a retirada do dinheiro. O Transaction Management é responsável por executar a seqüência de Management é responsável por executar a seqüência de retirada como uma transação atômica, assim, o dinheiro retirada como uma transação atômica, assim, o dinheiro é tanto deduzido da conta quanto entregue ao clienteé tanto deduzido da conta quanto entregue ao cliente

3. O Transaction Management solicita ao Account 3. O Transaction Management solicita ao Account Management a retirada do dinheiro. O Account Management a retirada do dinheiro. O Account Management determina se o dinheiro pode ser retirado e, Management determina se o dinheiro pode ser retirado e, caso possa, deduz a quantia da conta e retorna uma caso possa, deduz a quantia da conta e retorna uma resposta que especifica ser possível efetuar a retiradaresposta que especifica ser possível efetuar a retirada

4. O Transaction Management autoriza a interface ATM a 4. O Transaction Management autoriza a interface ATM a entregar o dinheiroentregar o dinheiro

5. A interface ATM entrega o dinheiro ao cliente5. A interface ATM entrega o dinheiro ao cliente


Dirigido por use case (Dirigido por use case (use case drivenuse case driven)) use case é o input básico para análise, use case é o input básico para análise,

projeto (design), implementação e teste projeto (design), implementação e teste do sistemado sistema

o conjunto dos use cases constituem o o conjunto dos use cases constituem o modelo de use case (modelo de use case (useuse casecase model)model), , que descreve a funcionalidade completa que descreve a funcionalidade completa do sistemado sistema

com base no modelo de use case, os com base no modelo de use case, os desenvolvedores criam uma série de desenvolvedores criam uma série de modelos de projeto e implementação que modelos de projeto e implementação que realizam os use casesrealizam os use cases


Centrado em arquitetura (architecture-Centrado em arquitetura (architecture-centric)centric) A arquitetura de um software descreve as A arquitetura de um software descreve as

diferentes visões do sistema em construçãodiferentes visões do sistema em construção A arquitetura se desenvolve a partir das visões A arquitetura se desenvolve a partir das visões

do usuário expressas em use casesdo usuário expressas em use cases A arquitetura é também influenciada por fatores A arquitetura é também influenciada por fatores

de implementação: arquitetura de computador, de implementação: arquitetura de computador, sistema operacional, dbms, protocolos de rede, sistema operacional, dbms, protocolos de rede, linguagem de programação, ambiente de linguagem de programação, ambiente de interface gráfica, bibliotecas de funções interface gráfica, bibliotecas de funções disponíveis, sistemas legados, necessidades de disponíveis, sistemas legados, necessidades de performance, portabilidade etc.performance, portabilidade etc.

Arquitetura: CArquitetura: Camadas de Componentesamadas de Componentes

Classes específicas de negócio

Classes de Serviços

Pacotes Genéricos

Sistema Operacional

Use Case e ArquiteturaUse Case e Arquitetura

Como use case e arquitetura se Como use case e arquitetura se relacionam?relacionam? Use case é a funcionalidade; Arquitetura é a Use case é a funcionalidade; Arquitetura é a

forma de realizaçãoforma de realização Os use cases dirigem a seleção de arquitetura e Os use cases dirigem a seleção de arquitetura e

a arquitetura influencia a seleção de use casesa arquitetura influencia a seleção de use cases Use cases e arquitetura não podem ser Use cases e arquitetura não podem ser

considerados isoladamenteconsiderados isoladamente Use cases e Arquitetura devem evoluir em Use cases e Arquitetura devem evoluir em

paralelo.paralelo.


Vários fatores influenciam a arquitetura, não Vários fatores influenciam a arquitetura, não apenas os use casesapenas os use cases


Trabalho InicialTrabalho Inicial Buscar uma compreensão dos use cases Buscar uma compreensão dos use cases

fundamentais do sistema (de 5 a 10% do total fundamentais do sistema (de 5 a 10% do total de use cases)de use cases)

Delinear a arquitetura que é independente de Delinear a arquitetura que é independente de use cases (ex.: plataforma de software)use cases (ex.: plataforma de software)

À medida em que a especificações dos use À medida em que a especificações dos use cases amadurecem, descobrem-se mais cases amadurecem, descobrem-se mais informações a respeito da arquitetura, o que informações a respeito da arquitetura, o que leva a maior conhecimento sobre os use casesleva a maior conhecimento sobre os use cases

O processo continua, até que a arquitetura se O processo continua, até que a arquitetura se torne estáveltorne estável

Arquitetura: Fatores que influenciamArquitetura: Fatores que influenciam

Use casesUse cases Tipo de software a ser construído: sistema Tipo de software a ser construído: sistema

operacional, sistema de apoio a decisão etc.operacional, sistema de apoio a decisão etc. Middleware: object broker, interfaces gráficasMiddleware: object broker, interfaces gráficas Sistemas legadosSistemas legados Padrões e políticas: linguagem de definição de Padrões e políticas: linguagem de definição de

interfaces, padrões de telecomunicaçõesinterfaces, padrões de telecomunicações Patterns utilizadosPatterns utilizados Requisitos não funcionais: performance, tempo de Requisitos não funcionais: performance, tempo de

recuperaçãorecuperação Mecanismos genéricos: armazenamento em dbmsMecanismos genéricos: armazenamento em dbms Modo de distribuição: arquitetura cliente/servidor, Modo de distribuição: arquitetura cliente/servidor,

internetinternet


O que é uma IteraçãoO que é uma Iteração Uma iteração é um mini-projeto que resulta em um Uma iteração é um mini-projeto que resulta em um

incremento do sistemaincremento do sistema Uma iteração contém um grupo de use cases que Uma iteração contém um grupo de use cases que

ampliam a funcionalidade do produto até então ampliam a funcionalidade do produto até então desenvolvidodesenvolvido

Como um mini-projeto, uma iteração passa pelas Como um mini-projeto, uma iteração passa pelas fases de análise, design, implementação e teste, fases de análise, design, implementação e teste, podendo mesmo colocar os use cases podendo mesmo colocar os use cases (pertencentes à iteração) sob a forma de código (pertencentes à iteração) sob a forma de código executávelexecutável

Uma iteração pode não acrescentar nova Uma iteração pode não acrescentar nova funcionalidade, mas adicionar detalhes a artefatos já funcionalidade, mas adicionar detalhes a artefatos já existentesexistentes

Estrutura de uma IteraçãoEstrutura de uma Iteração

Uma Iteração e seu WorkflowUma Iteração e seu Workflow

Concorrência de IteraçõesConcorrência de Iterações

Iterações podem caminhar em Iterações podem caminhar em paraleloparalelo

Iteração, Use Case e ArquiteturaIteração, Use Case e Arquitetura

O Processo é Iterativo e IncrementalO Processo é Iterativo e Incremental Para cada iteração os desenvolvedores identificam Para cada iteração os desenvolvedores identificam

os use cases relevantes, analisando-os segundo a os use cases relevantes, analisando-os segundo a arquitetura selecionadaarquitetura selecionada

O produto da iteração são componentes (modelos O produto da iteração são componentes (modelos ou módulos executáveis)ou módulos executáveis)

Verifica-se então se os componentes satisfazem os Verifica-se então se os componentes satisfazem os use cases e a arquiteturause cases e a arquitetura

Se a implementação atinge os objetivos Se a implementação atinge os objetivos (componentes satisfazem use cases e arquitetura), o (componentes satisfazem use cases e arquitetura), o desenvolvimento passa para a próxima iteraçãodesenvolvimento passa para a próxima iteração

Caso contrário, os desenvolvedores devem revisar Caso contrário, os desenvolvedores devem revisar as decisões anteriores e tentar uma nova as decisões anteriores e tentar uma nova abordagemabordagem

Benefícios do Processo IterativoBenefícios do Processo Iterativo

Redução de RiscosRedução de Riscos Caso necessário repetir a iteração, perde-se o Caso necessário repetir a iteração, perde-se o

esforço de um único incremento, não o de todo esforço de um único incremento, não o de todo o projetoo projeto

Reduzem-se os riscos de entrega de sistema Reduzem-se os riscos de entrega de sistema fora do prazo; problemas são detectados em fora do prazo; problemas são detectados em fase anterior à de testes globaisfase anterior à de testes globais

Iterações controladas reduzem o tempo global Iterações controladas reduzem o tempo global de desenvolvimento; os desenvolvedores de desenvolvimento; os desenvolvedores trabalham mais eficientemente em objetivos trabalham mais eficientemente em objetivos menoresmenores

Benefícios do Processo IterativoBenefícios do Processo Iterativo

Adequação a RequisitosAdequação a Requisitos Iterações controladas reconhecem uma Iterações controladas reconhecem uma

realidade inevitável:realidade inevitável: necessidades e requisitos não podem ser necessidades e requisitos não podem ser

adequadamente definidos por antecipação;adequadamente definidos por antecipação; mas devem ser refinados em iterações mas devem ser refinados em iterações

sucessivassucessivas Este modo de operar facilita a adaptação a Este modo de operar facilita a adaptação a

alterações de requisitosalterações de requisitos

Unified Process: O SistemaUnified Process: O Sistema

Os CiclosOs Ciclos

O Unified Process é composto de uma série de O Unified Process é composto de uma série de ciclosciclos

Cada Cada ciclociclo conclui com a entrega de um conclui com a entrega de um produtoproduto

Cada Cada ciclociclo constitui-se de quatro constitui-se de quatro fasesfases: : incepçãoincepção, , elaboraçãoelaboração, , construçãoconstrução e e transiçãotransição

cada cada fasefase se subdivide em se subdivide em iteraçõesiterações

Ciclos de um SistemaCiclos de um Sistema

A vida de um sistema consiste de A vida de um sistema consiste de ciclosciclos

Estrutura do CicloEstrutura do Ciclo

Um ciclo com suas fases e iteraçõesUm ciclo com suas fases e iterações

Unified Process:Unified Process: Fases de um Ciclo Fases de um Ciclo

IncepçãoIncepção Cada iteração nesta fase focaliza a compreensão do Cada iteração nesta fase focaliza a compreensão do

problema e da tecnologiaproblema e da tecnologia Essencialmente a fase corresponde às seguintes Essencialmente a fase corresponde às seguintes

questões:questões: O que o sistema fará para cada um de seus usuários: O que o sistema fará para cada um de seus usuários:

modelo simplificado dos principais use casesmodelo simplificado dos principais use cases Como deve ser uma arquitetura para o sistemaComo deve ser uma arquitetura para o sistema Qual é o plano e quanto custará para desenvolver o Qual é o plano e quanto custará para desenvolver o

produto?: estimativa de custosproduto?: estimativa de custos Cada iteração está voltada para a produção de use cases Cada iteração está voltada para a produção de use cases

de negócio e da arquitetura preliminarde negócio e da arquitetura preliminar


ElaboraçãoElaboração Nesta fase, as iterações estão voltadas para a produção Nesta fase, as iterações estão voltadas para a produção

da arquitetura básica da arquitetura básica Vários dos use cases são especificados com detalhes; a Vários dos use cases são especificados com detalhes; a

arquitetura do sistema é projetadaarquitetura do sistema é projetada A arquitetura é expressa em visões dos modelos do A arquitetura é expressa em visões dos modelos do

sistema:sistema: modelo de use casesmodelo de use cases modelo de análisemodelo de análise modelo de projetomodelo de projeto modelo de implementaçãomodelo de implementação modelo de distribuição (deployment)modelo de distribuição (deployment)

O resultado da fase é o conjunto dos modelos acrescidos O resultado da fase é o conjunto dos modelos acrescidos de elementos de implementaçãode elementos de implementação


ConstruçãoConstrução Nesta fase, as iterações estão voltadas para a produção Nesta fase, as iterações estão voltadas para a produção

de módulos executáveis, culminando com o de módulos executáveis, culminando com o desenvolvimento de um produto pronto para entrega à desenvolvimento de um produto pronto para entrega à comunidade de usuárioscomunidade de usuários

Durante esta fase o produto é construídoDurante esta fase o produto é construído O sistema torna-se um produto pronto para ser posto à O sistema torna-se um produto pronto para ser posto à

disposição da comunidade de usuáriosdisposição da comunidade de usuários A arquitetura é estável, ainda que possa ser aperfeiçoadaA arquitetura é estável, ainda que possa ser aperfeiçoada Ao final da fase, o sistema conterá todos os use cases Ao final da fase, o sistema conterá todos os use cases

que gerência e usuários concordaram em desenvolver que gerência e usuários concordaram em desenvolver para esta versão do produtopara esta versão do produto

Erros poderão ser encontrados e serão corrigidosErros poderão ser encontrados e serão corrigidos


TransiçãoTransição Compreende o período em que o produto passa para Compreende o período em que o produto passa para

beta-teste; a primeira versão é entregue aos usuáriosbeta-teste; a primeira versão é entregue aos usuários A fase envolve atividades de treinamento de usuários, A fase envolve atividades de treinamento de usuários,

assistência de uso do produto e correção de defeitos assistência de uso do produto e correção de defeitos encontrados após a entregaencontrados após a entrega

Um pequeno número de usuários experientes utiliza o Um pequeno número de usuários experientes utiliza o produto e reporta os erros e inadequações encontradasproduto e reporta os erros e inadequações encontradas

Os desenvolvedores corrigem os erros e e incorporam Os desenvolvedores corrigem os erros e e incorporam melhorasmelhoras

Visão Global das FasesVisão Global das Fases

O ProcessoO Processo

Pontos de Revisão (Milestones)Pontos de Revisão (Milestones)

Cada fase da Metodologia conclui com um Ponto Cada fase da Metodologia conclui com um Ponto de Revisãode Revisão Incepção: objetivos de negócioIncepção: objetivos de negócio Elaboração: arquiteturaElaboração: arquitetura Construção: capacidade operacionalConstrução: capacidade operacional Transição: entrega do produtoTransição: entrega do produto

Dentro de cada fase podem ser definidos Pontos Dentro de cada fase podem ser definidos Pontos de Revisão de menor amplitude (por ex., a cada de Revisão de menor amplitude (por ex., a cada iteração)iteração)

Pontos de Revisão (Milestones)Pontos de Revisão (Milestones)

Unified Process:Unified Process: Produtos Produtos

Modelos do Unified ProcessModelos do Unified Process

Modelos por FasesModelos por Fases

Workflow do Unified ProcessWorkflow do Unified Process

Fase de RequisitosFase de Requisitos

Modelo de Use CaseModelo de Use Case O Modelo de use case representa os Requisitos O Modelo de use case representa os Requisitos

FuncionaisFuncionais Um use case especifica uma seqüência de Um use case especifica uma seqüência de

ações, incluindo variantes, que o sistema ações, incluindo variantes, que o sistema realiza e que resulta em um resultado realiza e que resulta em um resultado observável produzido por um determinado atorobservável produzido por um determinado ator

Devem ser considerados em conjunto os use Devem ser considerados em conjunto os use cases pertencentes a uma iteraçãocases pertencentes a uma iteração

Fase de RequisitosFase de Requisitos

Modelo de Use Case: ExemploModelo de Use Case: Exemplo

Fase de AnáliseFase de Análise

Modelo de AnáliseModelo de Análise

O Modelo de Use Cases é a entrada para o Modelo de O Modelo de Use Cases é a entrada para o Modelo de AnáliseAnálise

O Modelo de Análise é uma especificação detalhada dos O Modelo de Análise é uma especificação detalhada dos requisitos e é uma primeira aproximação do Modelo de requisitos e é uma primeira aproximação do Modelo de ProjetoProjeto

O MA é usado pelos desenvolvedores para uma O MA é usado pelos desenvolvedores para uma compreensão mais precisa dos use cases, definindo-os compreensão mais precisa dos use cases, definindo-os como uma colaboração entre tipos conceituais de como uma colaboração entre tipos conceituais de objetos (sem detalhes de implementação)objetos (sem detalhes de implementação)

Cada elemento conceitual do Modelo de Análise Cada elemento conceitual do Modelo de Análise reaparecerá no correspondente Modelo de Projetoreaparecerá no correspondente Modelo de Projeto


Modelo de AnáliseModelo de Análise Modelo de Análise a partir de Modelo de Modelo de Análise a partir de Modelo de

Use CaseUse Case


Modelo de AnáliseModelo de Análise

O Modelo de Análise utiliza Diagrama de Colaboração O Modelo de Análise utiliza Diagrama de Colaboração para descrever a realização de um use casepara descrever a realização de um use case

O use case é descrito em termos de interação entre O use case é descrito em termos de interação entre objetos e atoresobjetos e atores

O diagrama de colaboração pode ser complementado O diagrama de colaboração pode ser complementado com texto, texto estruturado ou pseudocódigocom texto, texto estruturado ou pseudocódigo

O Modelo de Análise auxilia na descoberta dos tipos O Modelo de Análise auxilia na descoberta dos tipos conceituais de objetos participantes do sistema e no conceituais de objetos participantes do sistema e no modo como os objetos realizam atividades modo como os objetos realizam atividades (funcionalidade dos objetos)(funcionalidade dos objetos)


Use Case: Modelo de ColaboraçãoUse Case: Modelo de Colaboração


Modelo de Análise e definição de Modelo de Análise e definição de ClasseClasse As responsabilidades de uma classe são uma As responsabilidades de uma classe são uma

compilação dos papéis representados pela compilação dos papéis representados pela classe em todas as realizações de use cases classe em todas as realizações de use cases (diagramas de colaboração)(diagramas de colaboração)

Caso uma classe seja alterada, o desenvolvedor Caso uma classe seja alterada, o desenvolvedor precisa verificar se ela continua realizando seu precisa verificar se ela continua realizando seu papel em cada realização de use casepapel em cada realização de use case

Fase de ProjetoFase de Projeto

Modelo de ProjetoModelo de Projeto

O Modelo de Projeto é uma descrição da implementação O Modelo de Projeto é uma descrição da implementação do sistema, a partir do Modelo de Análisedo sistema, a partir do Modelo de Análise

O Modelo de Projeto precisa adequar-se ao ambiente de O Modelo de Projeto precisa adequar-se ao ambiente de implementação (tecnologia de distribuição de objetos, implementação (tecnologia de distribuição de objetos, ambiente gráfico, dbms, reuso de sistemas legados, ambiente gráfico, dbms, reuso de sistemas legados, bibliotecas de patterns etc.)bibliotecas de patterns etc.)

Existe um mapeamento direto entre os subsistemas do Existe um mapeamento direto entre os subsistemas do Modelo de Projeto e os componentes do Modelo de Modelo de Projeto e os componentes do Modelo de ImplementaçãoImplementação

Subsistemas são grupamentos de classes e outros Subsistemas são grupamentos de classes e outros subsistemassubsistemas

Fase de ProjetoFase de Projeto


O Modelo de Projeto define tipos de objetos, O Modelo de Projeto define tipos de objetos, associações e colaborações entre os tiposassociações e colaborações entre os tipos

Basicamente são as mesmas definições do Basicamente são as mesmas definições do Modelo de Análise. Entretanto, as definições do Modelo de Análise. Entretanto, as definições do Modelo de Análise são “conceituais”, enquanto Modelo de Análise são “conceituais”, enquanto que as definições do Modelo de Projeto são que as definições do Modelo de Projeto são voltadas para o ambiente operacionalvoltadas para o ambiente operacional

Ou seja: O Modelo de Projeto é “mais físico” e o Ou seja: O Modelo de Projeto é “mais físico” e o Modelo de Análise é “mais conceitual”Modelo de Análise é “mais conceitual”


Levantamento de ClassesLevantamento de Classes


Diagrama de ClassesDiagrama de Classes


Diagrama de ClassesDiagrama de Classes O diagrama anterior exibe um “diagrama de O diagrama anterior exibe um “diagrama de

classes”, não um diagrama de colaboraçãoclasses”, não um diagrama de colaboração O diagrama de classes introduz classes O diagrama de classes introduz classes

pertencentes ao ambiente de implementação, o pertencentes ao ambiente de implementação, o que leva ao detalhamento do modelo conceitualque leva ao detalhamento do modelo conceitual

É necessário detalhar a interação entre os É necessário detalhar a interação entre os objetos pertencentes às classes de projeto - objetos pertencentes às classes de projeto - isto é feito por meio de um “diagrama de isto é feito por meio de um “diagrama de seqüência”seqüência”


Diagrama de ClasseDiagrama de Classe


Diagrama de SeqüênciaDiagrama de Seqüência O diagrama de seqüência mostra como o foco O diagrama de seqüência mostra como o foco

passa de objeto para objeto e mensagens são passa de objeto para objeto e mensagens são trocadas, durante a execução de um use casetrocadas, durante a execução de um use case

Os desenvolvedores podem usar textos e Os desenvolvedores podem usar textos e pseudocódigo para complementar os pseudocódigo para complementar os diagramas de seqüência, para explicar detalhes diagramas de seqüência, para explicar detalhes de interação entre os objetosde interação entre os objetos


Diagrama de SeqüênciaDiagrama de Seqüência


Diagrama de EstadosDiagrama de Estados Alguns objetos de projeto são controlados por Alguns objetos de projeto são controlados por

estadosestados O estado de seus atributos e operações O estado de seus atributos e operações

determina o modo como o objeto reage a determina o modo como o objeto reage a mensagens enviadas por outros objetosmensagens enviadas por outros objetos

As transições de estados são representadas As transições de estados são representadas por Diagramas de Estados, um importante por Diagramas de Estados, um importante elemento a ser utilizado durante a fase de elemento a ser utilizado durante a fase de implementação da classe correspondente ao implementação da classe correspondente ao objeto analisadoobjeto analisado


Exemplo de Diagrama de EstadosExemplo de Diagrama de Estados


SubsistemasSubsistemas O Modelo de Projeto pode conter uma O Modelo de Projeto pode conter uma

quantidade excessivamente grande de classes quantidade excessivamente grande de classes (centenas ou milhares)(centenas ou milhares)

É necessário um meio para grupar as classes É necessário um meio para grupar as classes que participam de determinados use cases, o que participam de determinados use cases, o que é feito por meio de subsistemasque é feito por meio de subsistemas

Um subsistema é um grupamento de classes (e Um subsistema é um grupamento de classes (e outros subsistemas) que possuem alguma outros subsistemas) que possuem alguma afinidade semânticaafinidade semântica

A comunicação entre subsistemas e feita por A comunicação entre subsistemas e feita por meio de interfaces (oferecidos por classes dos meio de interfaces (oferecidos por classes dos subsistemas)subsistemas)


SubsistemasSubsistemas

CCamadas de subsistemasamadas de subsistemas

A arquitetura toma forma principalmente durante a A arquitetura toma forma principalmente durante a fase de elaboraçãofase de elaboração do sistema do sistema

A arquitetura de um sistema é especificada por A arquitetura de um sistema é especificada por meio de sucessivas iterações, cada iteração meio de sucessivas iterações, cada iteração acrescentando detalhes à iteração anterioracrescentando detalhes à iteração anterior

Cada iteração segue o padrão requisitos, análise, Cada iteração segue o padrão requisitos, análise, projeto, implementação, testeprojeto, implementação, teste

Cada iteração (de definição de arquitetura) focaliza Cada iteração (de definição de arquitetura) focaliza os use cases arquitetonicamente relevantes e os os use cases arquitetonicamente relevantes e os elementos mencionados na transparência anteriorelementos mencionados na transparência anterior

Ao final da fase de elaboração, obtem-se a Ao final da fase de elaboração, obtem-se a “architecture baseline”, que é a coleção de “architecture baseline”, que é a coleção de modelos acrescida das especificações de modelos acrescida das especificações de arquiteturaarquitetura

CCamadas de Subsistemas: Exemploamadas de Subsistemas: Exemplo

CCamadas de subsistemas: Layer Patternamadas de subsistemas: Layer Pattern

A figura exibe o pattern de definição em camadas A figura exibe o pattern de definição em camadas (Layer Pattern)(Layer Pattern)

Os componentes pertencentes a determinada Os componentes pertencentes a determinada camada apenas podem referenciar componentes camada apenas podem referenciar componentes pertencentes a uma camada inferiorpertencentes a uma camada inferior

O pattern simplifica e organiza a compreensão e a O pattern simplifica e organiza a compreensão e a organização de sistemas complexosorganização de sistemas complexos

O pattern reduz a dependência entre módulos, uma O pattern reduz a dependência entre módulos, uma vez que camadas mais baixas desconhecem vez que camadas mais baixas desconhecem detalhes de interface com camadas situadas acimadetalhes de interface com camadas situadas acima

Também facilita-se a identificação dos módulos a Também facilita-se a identificação dos módulos a serem reutilizados, e dos módulos a serem serem reutilizados, e dos módulos a serem adquiridos ou desenvolvidosadquiridos ou desenvolvidos

CCamadas de subsistemas: Arquiteturaamadas de subsistemas: Arquitetura

Um sistema desenvolvido segundo a arquitetura Um sistema desenvolvido segundo a arquitetura do “layer pattern” situa os subsistemas aplicativos do “layer pattern” situa os subsistemas aplicativos na camada do topona camada do topo

Patterns de projeto, frameworks e bibliotecas de Patterns de projeto, frameworks e bibliotecas de classes situam-se em camadas inferioresclasses situam-se em camadas inferiores

Quanto mais abaixo localiza-se a camada, maior é Quanto mais abaixo localiza-se a camada, maior é a reutilização de módulosa reutilização de módulos

A arquitetura das duas camadas inferiores pode A arquitetura das duas camadas inferiores pode ser estabelecida sem se levar em consideração os ser estabelecida sem se levar em consideração os detalhes dos use cases, uma vez que essas detalhes dos use cases, uma vez que essas camadas independem das especificações de camadas independem das especificações de negóciosnegócios

Subsistemas e suas InterfacesSubsistemas e suas Interfaces

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


SubsistemasSubsistemas Cada subsistema é representado por um Cada subsistema é representado por um

“package” da UML“package” da UML Vantagem em se utilizar interfaces entre Vantagem em se utilizar interfaces entre

subsistemas: o subsistema ATM Interface pode subsistemas: o subsistema ATM Interface pode eventualmente ser substituído por outro de eventualmente ser substituído por outro de diferente implementação, sem que a alteração diferente implementação, sem que a alteração modifique a funcionalidade oferecida a modifique a funcionalidade oferecida a Transaction ManagementTransaction Management


Subsistemas e Use CasesSubsistemas e Use Cases

Modelo de colaboração de um use case: interação entre Modelo de colaboração de um use case: interação entre subsistemas e atoressubsistemas e atores

Modelo de Distribuição (Deployment)Modelo de Distribuição (Deployment)

O Modelo de Distribuição define a arquitetura física O Modelo de Distribuição define a arquitetura física do sistema em termos de processadores (nodes) do sistema em termos de processadores (nodes) que se conectamque se conectam

Esses processadores são unidades de hardware Esses processadores são unidades de hardware em que os componentes de software podem ser em que os componentes de software podem ser executadosexecutados

Freqüentemente, a arquitetura física do sistema é Freqüentemente, a arquitetura física do sistema é conhecida antes mesmo do início de conhecida antes mesmo do início de desenvolvimento do sistemadesenvolvimento do sistema

Os processadores e suas conexões podem ser Os processadores e suas conexões podem ser modelados no Modelo de Distribuição já durante o modelados no Modelo de Distribuição já durante o levantamento de requisitoslevantamento de requisitos

Diagrama de DistribuiçãoDiagrama de Distribuição

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

Modelo de Distribuição e SubsistemasModelo de Distribuição e Subsistemas

Modelo de Distribuição: Visão AquitetônicaModelo de Distribuição: Visão Aquitetônica

Uma vez definidos os processadores, pode-se Uma vez definidos os processadores, pode-se indicar a distribuição de funcionalidade por elesindicar a distribuição de funcionalidade por eles

O diagrama a seguir exibe a distribuição das O diagrama a seguir exibe a distribuição das classes ativas segundo o modo como elas são classes ativas segundo o modo como elas são alocadas aos processadoresalocadas aos processadores

Fase de ImplementaçãoFase de Implementação

Modelo de Implementação: Modelo de Implementação: componentes que implementam componentes que implementam classesclasses Um Modelo de Implementação contém todas as Um Modelo de Implementação contém todas as

informações necessárias à produção de um sistema informações necessárias à produção de um sistema executável: componentes executáveis, componentes de executável: componentes executáveis, componentes de bancos de dados etc.bancos de dados etc.

Um componente é uma parte física e substituível de um Um componente é uma parte física e substituível de um sistema; um componente provê um conjunto de sistema; um componente provê um conjunto de interfacesinterfaces

O Modelo de Implementação é constituído de elementos O Modelo de Implementação é constituído de elementos de software, os quais incluem todos os módulos de software, os quais incluem todos os módulos executáveis (como ActiveX e JavaBeans)executáveis (como ActiveX e JavaBeans)


Componentes no Modelo de Componentes no Modelo de ImplementaçãoImplementação


Componentes no Modelo de Componentes no Modelo de ImplementaçãoImplementação A figura anterior exibe componentes que implementam A figura anterior exibe componentes que implementam

classes pertencentes ao modelo de projetoclasses pertencentes ao modelo de projeto O componente de arquivo O componente de arquivo dispenser.cdispenser.c contém o código contém o código

fonte e implementa três classes; este componente é fonte e implementa três classes; este componente é compilado e ligado, juntamente com compilado e ligado, juntamente com client.cclient.c, dentro do , dentro do componente componente client.execlient.exe, o qual é executável, o qual é executável

Se os componentes são implementados por meio de uma Se os componentes são implementados por meio de uma linguagem orientada a objetos, a implementação das linguagem orientada a objetos, a implementação das classes é direta: cada classe do projeto corresponde a classes é direta: cada classe do projeto corresponde a uma classe da implementação; cada componente de uma classe da implementação; cada componente de arquivo pode implementar várias dessas classesarquivo pode implementar várias dessas classes

Fase de TesteFase de Teste

Teste dos Use CasesTeste dos Use Cases Durante a fase de teste, é verificado se o sistema Durante a fase de teste, é verificado se o sistema

implementa corretamente as especificaçõesimplementa corretamente as especificações É desenvolvido um Modelo de Teste, que consiste de É desenvolvido um Modelo de Teste, que consiste de test test

casescases e e test procedurestest procedures Um Um test casetest case é um conjunto de entradas (input) de teste, é um conjunto de entradas (input) de teste,

condições de execução e resultados esperados, condições de execução e resultados esperados, desenvolvidos para um objetivo particular, como verificar desenvolvidos para um objetivo particular, como verificar um determinado caminho em um use caseum determinado caminho em um use case

Uma Uma test proceduretest procedure é uma especificação de como é uma especificação de como executar o setup, a execução e a avaliação de resultados executar o setup, a execução e a avaliação de resultados de um determinado de um determinado test casetest case


Exemplo de Test CaseExemplo de Test Case


Test Case: descrição textualTest Case: descrição textual Input:Input:

A conta 12-121-1211 possui saldo de $350A conta 12-121-1211 possui saldo de $350 O cliente identifica-se corretamenteO cliente identifica-se corretamente O cliente solicita a retirada de $200 da conta 12-121-O cliente solicita a retirada de $200 da conta 12-121-

12111211 Há dinheiro suficiente no ATM (ao menos $200)Há dinheiro suficiente no ATM (ao menos $200)

ResultadoResultado O saldo da conta 12-121-1211 decresce para $150O saldo da conta 12-121-1211 decresce para $150 O cliente recebe $200 da ATMO cliente recebe $200 da ATM

CondiçõesCondições Nenhuma outra instância de use case está autorizada Nenhuma outra instância de use case está autorizada

a acessar a conta 12-121-1211 durante o test casea acessar a conta 12-121-1211 durante o test case

Fundamentos da Metodologia revisitadosFundamentos da Metodologia revisitados

Dirigido por Use Case (Use Case Driven): cada Dirigido por Use Case (Use Case Driven): cada cada produto, em cada fase, tem sua origem em cada produto, em cada fase, tem sua origem em algum use case; ou seja, refere-se a algo que o algum use case; ou seja, refere-se a algo que o usuário realmente necessitausuário realmente necessita

Centrado em Arquitetura (Architecture Centric): o Centrado em Arquitetura (Architecture Centric): o desenvolvimento é focado no pattern arquitetônico desenvolvimento é focado no pattern arquitetônico que guiará a construção do sistema desde sua fase que guiará a construção do sistema desde sua fase inicialinicial

Iterativo e Incremental: o software é desenvolvido Iterativo e Incremental: o software é desenvolvido em pequenos passos gerenciáveis; se você está em pequenos passos gerenciáveis; se você está satisfeito com um passo, você ajusta seu foco para satisfeito com um passo, você ajusta seu foco para o próximo passo:o próximo passo: Você planeja um poucoVocê planeja um pouco Você especifica, projeta e implementa um poucoVocê especifica, projeta e implementa um pouco Você integra, testa e executa cada iteração um poucoVocê integra, testa e executa cada iteração um pouco

ReferênciasReferências

[1] Jacobson, Ivar; Booch, Grady; Rumbaugh, James. The [1] Jacobson, Ivar; Booch, Grady; Rumbaugh, James. The Unified Software Development Process. Addison-Wesley, Unified Software Development Process. Addison-Wesley, 19991999

[2] Rational Software Corporation. Unified Modeling [2] Rational Software Corporation. Unified Modeling Language - Notation Guide version 1.0. Rational Software Language - Notation Guide version 1.0. Rational Software Corporation, 1997Corporation, 1997

[3] IBM, Rational Software, Unisys et al. Software Process [3] IBM, Rational Software, Unisys et al. Software Process Engineering Mamagement - The Unified Process Model Engineering Mamagement - The Unified Process Model (UPM). OMG doc. Number ad/2000-05-05, May, 2000(UPM). OMG doc. Number ad/2000-05-05, May, 2000

[4] Kruchten, Philippe. A Rational Development Process. [4] Kruchten, Philippe. A Rational Development Process. http://rational.com, 2000http://rational.com, 2000

[5] Rational, http://www.rational.com[5] Rational, http://www.rational.com [6] Rumbaugh, James; Jacobson, Ivar; Booch, Grady. The [6] Rumbaugh, James; Jacobson, Ivar; Booch, Grady. The

Unified Modeling Language Reference Manual. Addison-Unified Modeling Language Reference Manual. Addison-Wesley, 1998Wesley, 1998

AnexosAnexos

Processo centrado em Arquitetura: Processo centrado em Arquitetura: Refinamentos SucessivosRefinamentos Sucessivos

No contexto do ciclo de vida de um software, No contexto do ciclo de vida de um software, centrado em arquiteturacentrado em arquitetura significa que a seleção significa que a seleção dos elementos estruturais (expressa nos modelos dos elementos estruturais (expressa nos modelos do sistema) e suas interfaces são elementos do sistema) e suas interfaces são elementos importantes para conceituação, construção, importantes para conceituação, construção, administração e evolução do sistema que está em administração e evolução do sistema que está em desenvolvimentodesenvolvimento

Os modelos do sistema passam por Os modelos do sistema passam por refinamentos refinamentos sucessivossucessivos para incorporar elementos de para incorporar elementos de implementação, percorrendo o caminho do implementação, percorrendo o caminho do mais mais conceitualconceitual para o para o mais concretomais concreto..

A incorporação sucessiva dos elementos de A incorporação sucessiva dos elementos de estrutura (detalhes de implementação) leva a uma estrutura (detalhes de implementação) leva a uma reavaliação dos use casesreavaliação dos use cases

Processo centrado em Arquitetura: Processo centrado em Arquitetura: ModularidadeModularidade

A boa arquitetura é aquela que divide o sistema em A boa arquitetura é aquela que divide o sistema em subsistemas (idealmente) autônomossubsistemas (idealmente) autônomos

Cada subsistema oferece serviços a outros Cada subsistema oferece serviços a outros subsistemas por meio de uma (ou mais) interface subsistemas por meio de uma (ou mais) interface bem definida bem definida

Deste modo reduzindo os problemas de Deste modo reduzindo os problemas de comunicação entre móduloscomunicação entre módulos

E tornando cada módulo independente da E tornando cada módulo independente da implementação de módulos pertencentes a outros implementação de módulos pertencentes a outros subsistemassubsistemas

Processo centrado em Arquitetura: Processo centrado em Arquitetura: ModularidadeModularidade

Interfaces estáveis permitem que o software Interfaces estáveis permitem que o software situado em cada lado da interface possa evoluir situado em cada lado da interface possa evoluir independentemente, desde que preserve a independentemente, desde que preserve a interfaceinterface

A modularidade de sistemas (subsistemas A modularidade de sistemas (subsistemas interligados por interfaces) facilita a escolha da interligados por interfaces) facilita a escolha da arquitetura mais adequada para cada subsistema e arquitetura mais adequada para cada subsistema e viabiliza a utilização de bibliotecas de viabiliza a utilização de bibliotecas de patternspatterns

A modularização centrada em interfaces bem A modularização centrada em interfaces bem definidas é o mecanismo que viabiliza o definidas é o mecanismo que viabiliza o reaproveitamento de soluçõesreaproveitamento de soluções

Princípios que regem a arquitetura no Princípios que regem a arquitetura no Processo UnificadoProcesso Unificado

Modularidade FuncionalModularidade Funcional: as Classes são grupadas : as Classes são grupadas em blocos funcionais (ou subsistemas), que os em blocos funcionais (ou subsistemas), que os usuários possam tratar como opcionais; cada usuários possam tratar como opcionais; cada subsistema possui uma forte coesão interna; subsistema possui uma forte coesão interna; alterações no sistema devem ficar restritas a alterações no sistema devem ficar restritas a determinados subsistemas, sem alterar o sistema determinados subsistemas, sem alterar o sistema como um todocomo um todo

Separação Interface/SubsistemaSeparação Interface/Subsistema: o projeto das : o projeto das interfaces deve ser separado do projeto dos interfaces deve ser separado do projeto dos subsistemas; o objetivo é conseguir projetos subsistemas; o objetivo é conseguir projetos “plugáveis”, em que diferentes subsistemas “plugáveis”, em que diferentes subsistemas possam oferecer as mesmas interfaces; possam oferecer as mesmas interfaces; subsistemas possam ser substituídos ou alterados subsistemas possam ser substituídos ou alterados sem que haja qualquer alteração em seus clientessem que haja qualquer alteração em seus clientes


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


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

Modelo de Implementação: Visão AquitetônicaModelo de Implementação: Visão Aquitetônica

O Modelo de Implementação é um mapeamento O Modelo de Implementação é um mapeamento direto a partir dos Modelos de Projeto e de direto a partir dos Modelos de Projeto e de DistribuiçãoDistribuição

Cada subsistema de projeto usualmente resulta em Cada subsistema de projeto usualmente resulta em um componente para cada processador em que o um componente para cada processador em que o subsistema precisa ser instaladosubsistema precisa ser instalado

Algumas vezes, porém, o mesmo componente é Algumas vezes, porém, o mesmo componente é instalado e executado em diferentes instalado e executado em diferentes processadoresprocessadores

Algumas linguagens provêm construções para a Algumas linguagens provêm construções para a definição de packages de componentes (como definição de packages de componentes (como JavaBeans)JavaBeans)

As Classes também podem ser organizadas em As Classes também podem ser organizadas em arquivos de código que contêm os componentesarquivos de código que contêm os componentes

o paradigma de orientação a objetos no processo de desenvolvimento de software prof. alcides...

Documents