Prof. Alcides Calsavara PUCPR

Apresentação em tema: "Prof. Alcides Calsavara PUCPR"— Transcrição da apresentação:

1 Prof. Alcides Calsavara PUCPR alcides@ppgia.pucpr.br
O Paradigma de Orientação a Objetos no Processo de Desenvolvimento de Software Prof. Alcides Calsavara PUCPR

2 Objetivos 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

3 Um breve histórico 1967: Simula 1970 a 1980: Smalltalk
1985 a 1986: C++, Objective-C, Eiffel, ... : Booch, OMT, ... 1992: CORBA 1994: UML 1995: Java (Web) 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
Em suas principais fases e métodos 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

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 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 de “component-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 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 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) 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

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.

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

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

16 Unified Process: Idéias Fundamentais
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 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

18 Unified Process: Idéias Fundamentais
Use case textual: Retirada de Dinheiro 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 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 4. O Transaction Management autoriza a interface ATM a entregar o dinheiro 5. A interface ATM entrega o dinheiro ao cliente

19 Unified Process: Idéias Fundamentais
Dirigido por use case (use case driven) 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 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) 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 é 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: Camadas 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?
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 Use cases e arquitetura não podem ser considerados isoladamente 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

24 Use Case e Arquitetura Trabalho Inicial
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) À 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

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

26 Unified Process: Idéias Fundamentais
O que é uma Iteração 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 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

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

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

29 Iteração, Use Case e Arquitetura
O Processo é Iterativo e Incremental 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) 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 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 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 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 Iterações controladas reconhecem uma realidade inevitável: necessidades e requisitos não podem ser adequadamente definidos por antecipação; mas devem ser refinados em iterações sucessivas Este modo de operar facilita a adaptação a alterações de requisitos

32 Unified Process: O Sistema
Os Ciclos O Unified Process é composto de uma série de ciclos 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 fase se subdivide em iterações

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

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

35 Unified Process: Fases de um Ciclo
Incepção Cada iteração nesta fase focaliza a compreensão do problema e da tecnologia 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 Como deve ser uma arquitetura para o sistema 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

36 Unified Process: Fases de um Ciclo
Elaboração 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 A arquitetura é expressa em visões dos modelos do sistema: modelo de use cases modelo de análise modelo de projeto modelo de implementação modelo de distribuição (deployment) O resultado da fase é o conjunto dos modelos acrescidos de elementos de implementação

37 Unified Process: Fases de um Ciclo
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 Durante esta fase o produto é construído 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 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

38 Unified Process: Fases de um Ciclo
Transição 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 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

39 Visão Global das Fases O Processo

40 Pontos de Revisão (Milestones)
Cada fase da Metodologia conclui com um Ponto de Revisão Incepção: objetivos de negócio Elaboração: arquitetura Construção: capacidade operacional 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)

41 Pontos de Revisão (Milestones)

42 Unified Process: Produtos
Modelos do Unified Process

43 Modelos por Fases Workflow do Unified Process

44 Fase de Requisitos Modelo de Use Case
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 Devem ser considerados em conjunto os use cases pertencentes a uma iteração

45 Fase de Requisitos Modelo de Use Case: Exemplo

46 Fase de Análise 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 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

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

48 Fase 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 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 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

50 Fase de Análise 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) 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
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.) 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

52 Fase de Projeto Modelo de Projeto
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 Ou seja: O Modelo de Projeto é “mais físico” e o Modelo de Análise é “mais conceitual”

53 Modelo de Projeto Levantamento de Classes

54 Modelo de Projeto Diagrama de Classes

55 Modelo de Projeto Diagrama de Classes
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 É 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

57 Modelo de Projeto 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 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

59 Modelo de Projeto Diagrama de 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 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

61 Modelo de Projeto Subsistemas
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 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)

62 Modelo de Projeto Subsistemas

63 Camadas de subsistemas
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 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 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 Camadas de Subsistemas: Exemplo

65 Camadas de subsistemas: 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 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 Também facilita-se a identificação dos módulos a serem reutilizados, e dos módulos a serem adquiridos ou desenvolvidos

66 Camadas de subsistemas: Arquitetura
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 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

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

68 Modelo de Projeto Subsistemas
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

69 Modelo de Projeto Subsistemas e Use Cases
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 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 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)

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

76 Fase de Implementação Componentes no Modelo de Implementação
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 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
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 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

78 Fase de Teste Exemplo de Test Case

79 Fase de Teste Test Case: descrição textual Input:
A conta possui saldo de $350 O cliente identifica-se corretamente O cliente solicita a retirada de $200 da conta Há dinheiro suficiente no ATM (ao menos $200) Resultado O saldo da conta decresce para $150 O cliente recebe $200 da ATM Condições 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 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: Você planeja um pouco Você especifica, projeta e implementa 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 [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 [4] Kruchten, Philippe. A Rational Development Process [5] Rational, [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 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

84 Processo centrado em Arquitetura: Modularidade
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 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

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

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

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

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