CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS THIAGO SANTOS MEZACASA

RESENHA
Capitulo 11 - Projeto de Arquitetura

Londrina 2012

THIAGO SANTOS MEZACASA

RESENHA
Capitulo 11 - Projeto de Arquitetura

Trabalho de Resenha apresentado à Universidade Norte do Paraná - UNOPAR, como requisito parcial para a obtenção de média bimestral na disciplina de Engenharia de Software. Orientador: Prof. Luis Claudio Perini

Londrina 2012

SUMÁRIO .

O processo inicial de projeto consiste em identificar esses subsistemas e estabelecer um framework para o controle e a comunicação. Existem três vantagens em projetar. • Segurança: deve ser projetada de modo que as operações relacionadas à segurança estejam todas localizadas em um único subsistema ou em um pequeno numero de subsistemas. Sugerem que a arquitetura possa servir como um plano de projeto para negociar requisitos de sistemas e como um meio de estruturação de discussões com os clientes. desenvolvedores e gerentes. O processo envolve o estabelecimento de um framework básico que identifica os principais componentes de um sistema e as comunicações entre eles. como tão pouca a comunicação quanto possível entre eles. . • Reuso em larga escala: é uma descrição compacta e administrável de como um sistema está organizado e de como os componentes operam entre si. • Desempenho: deve ser projetada para localizar operações criticas dentro de alguns subsistemas.São sistemas grandes e decompostos em subsistemas que fornecem algum conjunto de serviços relacionados. O estilo e a estrutura específicos de uma aplicação podem. A arquitetura de sistema afeta o desempenho. facilidade de distribuição e de manutenção de um sistema. • Análise de sistema: A arquitetura do sistema é clara em um estágio inicial de desenvolvimento do sistema requer alguma análise como as decisões de projeto. portanto depender dos requisitos não funcionais do sistema. • Comunicação com stakeholders: É a arquitetura apresentada em alto nível do sistema e pode ser usada para enfocar a discussão entre diferentes stakeholders. • Proteção: estrutura em camada para a arquitetura e deve ser usada com os itens mais críticos protegidos por camadas mais internas e com um alto nível de validação de proteção aplicado a essas camadas. O estágio de projeto de arquitetura força os projetistas de software considerar principais aspectos do projeto logo no início.

1 DECISÕES DE PROJETO DE ARQUITETURA É o processo criativo em que se tenta estabelecer uma organização de sistema que satisfaça os requisitos do sistema. cada um dos quais podendo ser um sistema substancial e independente. apenas para sistemas muito pequenos. a origem e a experiência do arquiteto do sistema e os requisitos específicos do sistema. Durante o . os requisitos de sistemas são um fator principal onde se tenta criar um projeto em que haja uma correspondência estrita entre os requisitos e os subsistemas. deve ser projetada para incluir componentes redundantes possíveis de substituir e atualizar componentes sem parar • Facilidade de manutenção: deve ser projetada usando componentes de baixa granularidade e autocontidos que possam ser prontamente mudados. Um projeto de subsistema é uma decomposição abstrata de um sistema em componentes de alta granularidade. A decomposição de arquitetura é necessária estruturar e organizar a especificação. O problema da decisão de como decompor um sistema em subsistema não é fácil.• Disponibilidade: o sistema. Uma especificação de sistema não deve incluir quaisquer informações do projeto. Há uma sobreposição significativa entre os processos de engenharia de requisitos e projeto de arquitetura. Diagramas de bloco são usados para descrever projetos de subsistemas em que cada caixa no diagrama representa um subsistema. Pode-se pensar no processo de projeto de arquitetura sob uma perspectiva de decisão ao invés de uma perspectiva de atividade. mas não é usado na prática. Os diagramas de blocos apresentam um desenho de alto nível da estrutura o sistema para que pessoas de áreas diferentes envolvidas no processo de desenvolvimento do sistema possam compreender prontamente. As atividades diferem radicalmente dependendo do tipo de sistema que será desenvolvido. se os requisitos mudam provavelmente essa mudança será localizada e não distribuída entre os vários subsistemas. 11.

há somente um processador. Portanto. Um estilo de arquitetura é um padrão de organização de sistema como uma organização cliente – servidor ou uma arquitetura em camadas. frequentemente sistemas de um mesmo domínio de aplicação tem arquiteturas similares que refletem os conceitos fundamentais de domínio. é preciso projetar uma arquitetura distribuída para o sistema. A arquitetura de um sistema de software de sistema é distribuída e pode ser baseada em um modelo ou estilo de arquitetura especifica. podem ser bastante genéricas como a arquitetura de sistemas de gerenciamento de informações. os arquitetos de sistema precisam tomar uma série de decisões que afetam profundamente o sistema e o seu processo de desenvolvimento. ou muito mais especificas. Diferentes partes do sistema podem ser projetadas usando estilos diferentes de arquitetura. . atualmente sistema distribuídos em que o software e distribuído por meio de computadores diferentes. Em sistema embutidos e sistemas projetados para computadores pessoais. Alguns casos a arquitetura pode ser composta criada pela combinação de estilos de arquitetura diferentes. Respondendo a algumas questões fundamentais como: • Existe uma arquitetura genérica de aplicação que possa funcionar como um modelo para o sistema que esta sendo projetado.processo. é preciso decidir o seu sistema e as classes mais amplas de aplicação tem em comum e decidir quanto conhecimento dessas arquitetura de aplicação pode reusar. • Como o sistema está distribuído ao longo de vários processadores? • Qual ou quais estilos de arquitetura são apropriados para o sistema? • Qual será a abordagem fundamental usada para estruturar o sistema? • Como as unidades estruturais de um sistema serão decompostas em módulos? • Qual estratégia será usada para controlar a operação das unidades no sistema? • Como o projeto de arquitetura será avaliado? • Como a arquitetura do sistema deve ser documentada? Embora cada sistema de software seja único. Ao projetar uma arquitetura de sistema. sistemas muito grandes são.

• Modelos de relacionamento: Que mostram os relacionamentos. O processo de projeto de arquitetura é um documento. . • Um modelo dinâmico de processo: Que mostra como o sistema esta organizado em processos em tempo de execução. mas as ADLs podem ser compreendidas somente por especialistas em linguagens e são inacessíveis para especialistas em domínios e aplicações. entre os subsistemas.É preciso escolher a estrutura mais apropriada como a estrutura cliente – servidor ou em camadas que permita atender aos requisitos sistema. Os elementos básicos são componentes e conectores e incluem regras e guias para arquiteturas bem formadas. • Um modelo de interface: Que define os serviços oferecidos por cada subsistema por meio de suas interfaces publicas. A avaliação do projeto de arquitetura é difícil. Os modelos de arquitetura podem ser desenvolvidos podem incluir: • Um modelo estático de estrutura: Que mostra os subsistemas ou componentes desenvolvidos como unidades separadas. pois o verdadeiro teste de uma arquitetura recai sobre quem bem ela atende os requisitos funcionais e não funcionais depois de implantadas. Alguns pesquisadores propuseram o uso de ADL – Linguagem de descrição de arquiteturas para descrever arquiteturas de sistemas. a abordagem adotada e como cada subsistema está estruturada em módulos. tal com fluxo de dados. É preciso tomar decisão sobre a estratégia de decomposição de subsistemas em componentes ou módulos. Modelos informais e notações como a UML permanecerão como as notações mais comumente usadas para descrição de arquiteturas. • Um modelo de distribuição: que mostra como os subsistemas podem ser distribuídos pelos computadores. ele pode incluir varias representações gráficas do sistema junto com um texto descritivo associado. No processo de modelagem de controle. Deve ser descrito como o sistema está estruturado em subsistemas. deve tomar decisões como a execução de subsistemas é controlada.

A maioria dos sistemas que usam grande quantidade de dados é organizada em um banco de dados ou repositório compartilhado. Serão apresentados três estilos organizacionais que são utilizados. A organização do sistema pode refletir-se diretamente na estrutura do subsistema.1 O modelo repositório Os subsistemas constituem um sistema que devem trocar informações de modo que possam trabalhar juntos eficientemente. • Cada subsistema mantém seu próprio banco de dados. O sistema baseado em um banco de dados compartilhado é algumas vezes denominado modelo repositório. Os dados são trocados com outros subsistemas por meio da passagem de mensagem entre eles.2 ORGANIZAÇÕES DE SISTEMA Reflete a estratégia básica usada para estruturá-lo. É preciso tomar decisão sobre modelo geral organizacional de um sistema com antecedência no processo de projeto de arquitetura. É frequente que o modelo de subsistema inclua mais detalhes que o modelo de organização e nem sempre há um mapeamento simples dos sistemas para a estrutura organizacional. 11. Portanto é adequado para aplicações em que os dados são gerados por um subsistema e usado por outro. sistemas CAD e os conjuntos de ferramentas CASE. • Todos os dados compartilhados são mantidos em um banco de dados podendo ser acessado por um subsistema. .2. Existem duas maneiras pelas quais isso pode ser feito. Segue as vantagens e Desvantagens de um repositório compartilhado: • É a maneira eficiente de compartilhar grandes quantidades de dados. Nesse tipo de sistema incluem sistemas de comando e controle de informações gerenciais.11. Não há necessidade de transmitir dados explicitamente de um subsistema para outro.

• Os subsistemas devem estar de acordo com o modelo de dados de repositório. proteção. • • Subsistemas diferentes podem ter requisitos diferentes para políticas de proteção. Atividades como back-ups. • Pode ser difícil distribuir o repositório por uma série de máquinas. Novas ferramentas podem ser integradas diretamente considerando que sejam compatíveis com o modelo de dados estabelecido.2 O modelo cliente – servidor É um modelo em que o sistema é organizado como um conjunto de serviços servidores e clientes associados que acessam e usam os serviços. Foi feito uma abordagem alternativa para sistemas de IA que usam o modelo blackboard. pode haver problemas com redundância e inconsistência de dados. embora seja possível distribuir um repositório centralizado. Principais componentes são: • Um conjunto de servidores que oferecem serviços para outros subsistemas. Elas são de responsabilidade do gerenciador de repositório. É um compromisso entre as necessidades especificas de cada ferramenta. Modelo de compartilhamento é visível pro meio do esquema de repositório. . 11. controle de acesso e recuperação de erros são centralizadas.2. A evolução pode ser difícil quando um grande volume de informação é gerado de acordo com o modelo de dados estabelecidos. que dispara os subsistemas quando um determinado dado torna-se disponível. é mais adequado quando a forma dos dados do repositório é bem menos estruturada. • • • Os subsistemas que produzem dados não precisam sabem como esses dados são usados por outros subsistemas. recuperação e back-ups. O repositório é passivo e o controle é de responsabilidade dos subsistemas que o usam. Como exemplo tem os servidores de impressora.

e um sistema e-commerce que apoia a venda de filmes e videoclipes. Cada camada pode ser imaginada como uma máquina abstrata cuja linguagem de máquina é definida pelos serviços fornecidos pela camada. No entanto servidores não precisam saber identidades dos clientes ou quantos clientes existem. cada uma das quais fornecendo um conjunto de serviços. Normalmente são subsistemas independentes. Os clientes acessam os serviços fornecidos pelo servidor meio de chamadas remotas de procedimento usando um protocolo request – reply como protocolo HTTP usando na web. organiza um sistema em camadas. • Um conjunto de cliente que solicita os serviços oferecidos pelos servidores. Um exemplo de modelo de camada é o modelo de referência OSI de protocolos de rede. O programa cliente é simplesmente uma interface com o usuário.3 O modelo em camadas Denominado modelo de máquina abstrata.servidores de arquivos e servidores de compiladores. podem ser executados em uma única maquina. clientes e servidores. • Uma rede que permite aos clientes acessarem esses serviços. 11. O catalogo deve ser capaz de lidar com várias consultas e fornecer links para sistema web de informações com dados do filmo e videoclipe.2. Os clientes precisam saber os nomes dos servidores disponíveis e os serviços que eles fornecem. construída com o uso de um navegador web para esses serviços. Não é estritamente necessário quando ambos. Mudança em clientes e servidores pode ser existente podem ser necessárias para obter os plenos benefícios da integração de um novo servidor. A vantagem mais importante de um modelo cliente – servidor é que ele é uma arquitetura distribuída. O Sistema de gerenciamento de configuração gerencia versões .

11.3 ESTILOS DE DECOMPOSIÇÃO MODULAR É uma tomada de decisão sobre a abordagem a ser usada na decomposição de subsistemas em módulos. Camadas mais internas podem fornecer recursos básicos como gerenciamento de arquivos. À medida que uma camada é desenvolvida alguns serviços fornecidos por essa camada podem ser disponibilizados para os usuários. A desvantagem da abordagem em camadas é que a estruturação de sistemas maneira pode ser difícil. É usado para um sistema de gerenciamento de objetos que armazena informações e serviços de gerenciamento para itens ou objetos de configuração. Os módulos são compostos em série de outros componentes mais simples do sistema. O desempenho pode ser um problema devido aos vários níveis de interpretação de comandos algumas vezes exigidos. como gerenciamento de transações. necessários em todos os níveis. uma camada poderá ser substituída por outra equivalente. São decompostos em módulos e definem interfaces que são usadas para comunicação. Podemos pensar nos subsistemas e módulos da seguinte maneira: • Um subsistema é um sistema em si cuja operação não depende de serviços fornecidos por outros subsistemas. e controle de acesso. Desde que sua interface permaneça inalterada. Existem duas estratégias principais que pode usar para . O gerenciamento de banco de dados usa recursos básicos do sistema operacional e repositório de arquivos em sua implantação. A abordagem em camada apoia o desenvolvimento incremental de sistemas.de objetos e fornece recursos gerais de gerenciamento de configuração. Esse sistema é construído sobre um sistema de banco de dados para fornecer armazenamento e serviços básicos de dados. rollback e recuperação. • Um módulo é normalmente um componente de um sistema que Fornece um ou mais serviços para outros módulos. Os componentes em módulo são geralmente menores do que os subsistemas que permitem a utilização de estilos alternativos de decomposição.

os objetos podem ser reusados.3. Os objetos são representações de entidades do mundo real e. • Decomposição orientada a objeto: onde compõe um sistema em um conjunto de objetos que se comunicam. Essas entidades são usadas em sistemas diferentes. Quando implementados os objetos são criados a partir dessas classes e algum modelo de controle é usado para coordenar as operações de objetos. No modelo pipelining. seus atributos e suas operações. Em orientado a objetos.1 Decomposição orientada a objetos É um sistema em um conjunto de objetos não firmemente acoplados com interfaces bem definidas. os módulos são transformações funcionais. Linguagem de programação orientada a objetos foram desenvolvidas de modo a permitirem implementação direta de componentes de arquitetura. 11. Uma decomposição orientada a objetos está relacionada a classes de objetos. A abordagem orientada a objetos tem desvantagens. A vantagem de evitar um projeto de sistema concorrente é que programas sequencias são mais fáceis de projetar. os módulos são objetos com estado privado e operações definidas sobre esse estado. Deve evitar decisões prematuras sobre a simultaneidade de um sistema. • Pipelining: Orientado a função na qual decompões um sistema em modulo funcionais que aceitam dados de entrada e transforma – os em dados de saída.decompor um subsistema em módulo. . a estrutura do sistema é rapidamente entendida. assim. implementar e testar do que sistemas paralelos. Os objetos devem fazer referências ao nome e a interface de outros objetos.

O principal problema desse estilo é que ele necessita ser um formato comum para transferência de dados que possa ser reconhecido por todas as transformações. no sentido de que muitas pessoas pensam em seu trabalho em termos de processamento de entrada e saída. As transformações são representadas como processos separados esse modelo é algumas vezes chamado estilo duto (PIPE) e filtro. As vantagens dessa arquitetura são: • Ela apoia o reuso de transformações. O sistema Unix fornece dutos que agem como condutores de dados e um conjunto de comandos que são transformações funcionais. As transformações devem analisar sua entrada e ajustar sua saída de acordo com a forma estabelecida. As transformações devem estar de acordo com suas transformações de comunicação sobre o formato de dados que serão processados ou. as transformações funcionais processam suas camadas e produzem saídas. então deve ser imposto um formato padrão para todos os dados comunicados. Com isso aumenta o overhead dos sistemas e pode significar a impossibilidade de integrar transformações que usam formatos de dados incompatíveis. • A evolução do sistema pela adição de novas transformações e geralmente direta. • Ela é simples de ser implementada tanto quanto um sistema concorrente ou sequencial. segundo a terminologia usada no sistema Unix.3.2 PIPELINING ORIENTADO A FUNÇÕES As funções ou modelo de fluxo de dados. • Ela é intuitiva. Os dados podem ser processados por cada transformação item por item ou em um único lote. Sistemas interativos são difíceis de escrever usando o modelo de pipelining por causa da necessidade de uma sequencia de dados ser .11. O termo filtro é usado porque uma transformação ‘filtra’ os dados que pode processar a partir do caminho de dados de entrada. Os dados fluem de uma para outra função e são transformados ao moverem-se sequencialmente.

O arquiteto deve organizar os subsistemas de acordo com algum modelo de controle que suplementa o modelo de estrutura usado. Os modelos de controle centralizado dividemse em duas classes dependendo de se os subsistemas controlados forem . Para funcionar como um sistema. mas esperará que essa responsabilidade de controle seja devolvida a ele. 11.1 Controle centralizado No modelo centralizado um subsistema é designado como controlador de sistema e tem a responsabilidade pelo gerenciamento da execução de outros subsistemas. Modelos de controles no nível de arquitetura lidam com o fluxo de controle entre subsistemas. interface gráficas com o usuário tem formatos e controlo de entradas/saídas mais complexos. os subsistemas devem ser controlados de maneira que seus serviços sejam entregues no lugar certo e no tempo certo. Os estilos de estrutura podem ser implementados por meio de controle centralizado ou baseado em eventos. Pode também passar o controle a outro subsistema. Modelos de controle são usados em conjunto com estilo de estrutura. baseando em eventos como cliques com o mouse ou seleções de menus. Existem dois estilos genéricos de controle usados pelo sistema de software: • Controle centralizado: É um subsistema que tem responsabilidade geral pelo controle e inicia e para outros sistemas. cada subsistema podem responder a eventos gerados externamente. A entrada e a saída de textos simples podem ser modeladas dessa maneira.4 MODELOS DE CONTROLE Os modelos de estruturação estão relacionados como um sistema é decomposto em subsistemas.4. Modelos estruturais não incluem (nem devem incluir) informações de controle. • Controle baseado a eventos: As informações de controle em vez de ser incorporado em um subsistema.processada. 11.

Em muitos sistemas orientados objetos. varrendo os sensores e outros processos em busca de eventos ou mudanças de estado. passa para os níveis mais baixos na árvore. Ele verifica se outros processos produziram informações a serem processadas ou passadas a eles para processamento. Quando um objeto Java requisita um serviço para outro objeto. • O modelo gerenciador: este modelo é aplicável a sistemas concorrentes. usado em sistemas de tempo real simples sem muitas restrições rígidas de tempo. Um processo é um subsistema ou um modulo que pode ser executado paralelamente com outros processos. Ponto forte porque é relativamente simples analisar fluxos de controle e testar como o sistema responderá a entradas específicas. ele o faz chamando um método associado. • O modelo chamada–retorno: é conhecido modelo top-down de sub-rotina em que o controle começa no topo da hierarquia de sub-rotina e através de chamadas de sub-rotinas. Aplicável somente em sistemas sequenciais.executados sequencial ou paralelamente. a parada e a coordenação de outros processos de sistemas. As sub-rotinas em uma linguagem de programação chamada por outras sub.rotinas são naturalmente funcionais. O modelo chamada-retorno pode ser usado no nível de módulo para controlar funções e objetos. O controlador geralmente esta em loop contínuo. É projetado como um gerenciador de sistemas e controla o início. O modelo controle centralizado de gerenciamento muitas vezes. Um ponto fraco porque. A natureza rígida e restritiva desse modelo é ao mesmo tempo um ponto forte e fraco. O controlador central gerencia a execução de um conjunto de processos associados a sensores e atuadores. em operação normal. é difícil lidar com as exceções. O processo controlador do sistema decide quando os processos devem ser iniciados ou interrompidos dependendo das variáveis de estado do sistema. . as operações que envolvem objetos (métodos) são implementadas como procedimentos ou funções.

nos quais uma condição ai tornar-se verdadeira causa uma ação a ser disparada. Modelos de broadcast são eficazes na integração de sistemas distribuídos em diferentes computadores de rede. Qualquer subsistema programado para manipular esse evento pode responder a ele. Incluem editores em que os eventos de interface com o usuário significam comandos de edição. Estas são passadas para algum outro componente para processamento. O tratador de evento detecta os eventos. Em broadcast os sistemas registram um interesse em eventos específicos. consulta o registrador de eventos e passa o evento aos subsistemas que . mas isso impõe um grande overhead de processamento. o controle é transferido para o subsistema que pode tratar o evento. Nesta seção abordo dois modelos de controle orientados a eventos: • Modelos de broadcast: neste modelo. Existem muitos tipos sistemas orientados a eventos.4.11.2 Sistemas orientados a eventos Neste contexto o termo evento não significa somente um sinal binário. Pode ser um sinal que pode assumir uma gama de valores ou uma entrada de comando baseado em um menu. um evento é transmitido a todos os subsistemas. • Modelos orientados a interrupções: são usados exclusivamente em sistema de tempo real nos quais interrupções externas são detectadas por um tratador de interrupções. e objetos ativos nos quais a mudança de um valor de um atributo de objetos dispara algumas ações. Os subsistemas geram eventos que indicam que algum dado está disponível para processamento. A distinção entre um evento e uma entrada simples é que a ocorrência do evento esta fora do controle do processo que manipula esse evento. Quando esses eventos ocorrem. Modelos orientados a interrupções são usados em sistemas de tempo real com requisitos rigorosos de tempo. sistema de produção baseados em regras como os usados em IA (inteligência Artificial). Todos os eventos podem ser transmitidos a todos os subsistemas.

A vantagem dessa abordagem de broadcast é que a evolução é que e relativamente simples. Podem obter melhores resultados com essa limitação pelo mapeamento dos vários tipos de eventos em uma única interrupção. Cada tipo de interrupção de determinado tipo é recebida. Esse modelo é usado em sistemas de tempo real em que uma resposta imediata a algum evento é necessário. Qualquer subsistema pode ativar qualquer outro subsistema sem saber seu nome ou sua localização. 11. existem subsistemas explícitos do tipo evento – ouvinte que escutam os eventos do mouse. Esses modelos de arquitetura são . A desvantagem é a complexidade da programação e a dificuldade de validação. A vantagem da abordagem é que ela permite resposta muito rápidas aos eventos por serem implementados. A desvantagem desse modelo é que os subsistemas não sabem se ou quando os eventos serão manipulados. Quando um subsistema gera um evento não sabe quais pontos subsistemas registraram interesse nesse evento. Em sistemas simples como os sistemas baseados em PC orientados a eventos de interface com o usuário. provavelmente devem ser orientados a eventos. teclado etc. uma chave de hardware transfere o controle imediatamente para seu tratador. As instâncias desses sistemas sejam diferentes em detalhes a estrutura comum de arquitetura pode ser reusada no desenvolvimento de novos sistemas. Um novo subsistema pode tratar classe especificas de eventos pode ser integrado por meio do registro de seus eventos no tratador de eventos. Os subsistemas podem ser implementados em maquinas distribuídas.declaram interesse. Os sistemas de tempo real requerem que eventos gerados externamente sejam manipulados.5 ARQUITETURAS DE REFERÊNCIA Eles podem ser aplicados em muitas classes de aplicações. Esses modelos de arquitetura específicos a determinado domínio de aplicação podem ser usados.

À medida que a tecnologia se desenvolvesse. Representam uma arquitetura idealizada que inclui todas as características que esses sistemas podem incorporar. Os modelos de referência são normalmente usados para comunicar conceitos de domínios e comparar ou avaliar possíveis arquiteturas. Eles são um meio de informação para os projetistas sobre a estrutura geral dessa classe de sistema. um camada poderia ser novamente implementada de maneira transparente sem afetar os sistemas que usassem . Sua principal função é ser um meio de discussão de arquitetura de domínio específico e de comparação de sistemas diferentes em um domínio. como sistemas de coleta de dados ou sistemas de monitoração. Eles englobam as características principais desses sistemas. Os genéricos podem ser reusados diretamente em projetos. pode haver modelos genéricos de arquiteturas de tipos de sistemas diferentes.chamados de arquitetura de domínio específico. as camada intermediárias. Não há distinção rígida entre esses tipos de modelo. As arquiteturas de referências não são geralmente consideradas um roteiro de implementação. Existem dois tipos de modelos de arquitetura de domínio específico: • Modelos genéricos: São abstração de uma serie de sistemas reais. Os projetistas do modelo OSI tinham um objetivo muito pratico ao definir um padrão de implementação de modo que sistemas em conformidade com o padrão pudessem se comunicar uns com os outros. O modelo OSI é um modelo de sete camadas para interconexão de sistemas abertos. Em sistemas de tempo real. Modelos genéricos podem também servir como modelos de referências. à transferência de informações semanticamente significativas de aplicação como documentos padronizados. As funções exatas das camadas não são importantes aqui. Os modelos de referencias são geralmente derivados de um estudo de domínio de aplicação. As camadas inferiores estão relacionadas à interconexão física. à transferência de dados e as camadas superiores. • Modelos de referência: São mais abstratos e descrevem uma classe maior de sistemas.

Apoiam a integração de processo. Apoiam a integração de apresentação. Significa que podemos formular algumas .as outras camadas. embora seja importante enfatizar que nem todo recurso de uma arquitetura de referencia pode ser incluído nos projetos reais de arquitetura. Deve também fornecer recurso de ‘plug-in’ para ferramentas CASE individuais que usam esses serviços. • Serviços de integração de dados: estes serviços fornecem recursos para o gerenciamento de grupos ou para definição de relacionamento entre eles. Apoiam a integração de controle. Os cinco níveis de serviços em um modelo CASE de referência são: • Serviços de repositórios de dados: estes serviços fornecem recursos para o armazenamento e o gerenciamento de itens de dados e seus relacionamentos. Os problemas da abordagem pro camadas para modelagem de arquitetura comprometeram esse objetivo. As grandes diferenças entre redes. • Serviços de mensagem: estes serviços fornecem recursos para a comunicação ferramenta – ferramenta. O modelo de referência nos mostra o que pode ser incluído em qualquer ambiente CASE em particular. Eles precisam projetar recursos não padronizados para aprimorar o desempenho do sistema. • Serviços de gerenciamento de tarefas: estes serviços fornecem recursos para a definição e aprovação de modelos de processo. interconexões simples podem ser impossíveis. Os desenvolvedores do sistema precisam implementar seus próprios recursos de alto níveis e ignorar camadas de modelo. Outros modelos de referências é um modelo para ambiente CASE que identifica cinco conjuntos de serviços que um ambiente CASE deve fornecer. ambiente – ferramenta e ambiente-ambiente. • Serviços de interfaces com usuário: estes serviços fornecem recursos para o desenvolvimento de interface com o usuário. Os serviços de repositórios de dados são à base de integração de dados no ambiente.

‘como são fornecidos os serviços de repositórios de dado?’ e ‘o sistema fornece gerenciamento de tarefa?’.questões sobre um projeto de sistema como por exemplo. Tem por finalidade principal dessa arquitetura de referência é ser um meio de classificação e comparação de ferramentas em ambientes CASE integrados. .