CENTRO DE CINCIAS EXATAS E TECNOLGICAS TECNOLOGIA EM ANLISE 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 obteno de mdia bimestral na disciplina de Engenharia de Software. Orientador: Prof. Luis Claudio Perini

Londrina 2012

SUMRIO

So sistemas grandes e decompostos em subsistemas que fornecem algum conjunto de servios relacionados. O processo inicial de projeto consiste em identificar esses subsistemas e estabelecer um framework para o controle e a comunicao. O processo envolve o estabelecimento de um framework bsico que identifica os principais componentes de um sistema e as comunicaes entre eles. Existem trs vantagens em projetar. Comunicao com stakeholders: a arquitetura apresentada em alto nvel do sistema e pode ser usada para enfocar a discusso entre diferentes stakeholders. Anlise de sistema: A arquitetura do sistema clara em um estgio inicial de desenvolvimento do sistema requer alguma anlise como as decises de projeto. Reuso em larga escala: uma descrio compacta e administrvel de como um sistema est organizado e de como os componentes operam entre si. O estgio de projeto de arquitetura fora os projetistas de software considerar principais aspectos do projeto logo no incio. Sugerem que a arquitetura possa servir como um plano de projeto para negociar requisitos de sistemas e como um meio de estruturao de discusses com os clientes, desenvolvedores e gerentes. A arquitetura de sistema afeta o desempenho, facilidade de distribuio e de manuteno de um sistema. O estilo e a estrutura especficos de uma aplicao podem, portanto depender dos requisitos no funcionais do sistema. Desempenho: deve ser projetada para localizar operaes criticas dentro de alguns subsistemas, como to pouca a comunicao quanto possvel entre eles. Proteo: estrutura em camada para a arquitetura e deve ser usada com os itens mais crticos protegidos por camadas mais internas e com um alto nvel de validao de proteo aplicado a essas camadas. Segurana: deve ser projetada de modo que as operaes relacionadas segurana estejam todas localizadas em um nico subsistema ou em um pequeno numero de subsistemas.

 Disponibilidade: o sistema.

deve

ser

projetada

para

incluir

componentes

redundantes possveis de substituir e atualizar componentes sem parar Facilidade de manuteno: deve ser projetada usando componentes de baixa granularidade e autocontidos que possam ser prontamente mudados. H uma sobreposio significativa entre os processos de engenharia de requisitos e projeto de arquitetura. Uma especificao de sistema no deve incluir quaisquer informaes do projeto, mas no usado na prtica, apenas para sistemas muito pequenos. A decomposio de arquitetura necessria estruturar e organizar a especificao. Um projeto de subsistema uma decomposio abstrata de um sistema em componentes de alta granularidade, cada um dos quais podendo ser um sistema substancial e independente. Diagramas de bloco so usados para descrever projetos de subsistemas em que cada caixa no diagrama representa um subsistema. Os diagramas de blocos apresentam um desenho de alto nvel da estrutura o sistema para que pessoas de reas diferentes envolvidas no processo de desenvolvimento do sistema possam compreender prontamente. O problema da deciso de como decompor um sistema em subsistema no fcil, os requisitos de sistemas so um fator principal onde se tenta criar um projeto em que haja uma correspondncia estrita entre os requisitos e os subsistemas, se os requisitos mudam provavelmente essa mudana ser localizada e no distribuda entre os vrios subsistemas.

11.1 DECISES DE PROJETO DE ARQUITETURA o processo criativo em que se tenta estabelecer uma organizao de sistema que satisfaa os requisitos do sistema. As atividades diferem radicalmente dependendo do tipo de sistema que ser desenvolvido, a origem e a experincia do arquiteto do sistema e os requisitos especficos do sistema. Pode-se pensar no processo de projeto de arquitetura sob uma perspectiva de deciso ao invs de uma perspectiva de atividade. Durante o

processo, os arquitetos de sistema precisam tomar uma srie de decises que afetam profundamente o sistema e o seu processo de desenvolvimento. Respondendo a algumas questes fundamentais como: Existe uma arquitetura genrica de aplicao que possa funcionar como um modelo para o sistema que esta sendo projetado. Como o sistema est distribudo ao longo de vrios processadores? Qual ou quais estilos de arquitetura so apropriados para o sistema? Qual ser a abordagem fundamental usada para estruturar o sistema? Como as unidades estruturais de um sistema sero decompostas em mdulos? Qual estratgia ser usada para controlar a operao 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, frequentemente sistemas de um mesmo domnio de aplicao tem arquiteturas similares que refletem os conceitos fundamentais de domnio, podem ser bastante genricas como a arquitetura de sistemas de gerenciamento de informaes, ou muito mais especificas. Ao projetar uma arquitetura de sistema, preciso decidir o seu sistema e as classes mais amplas de aplicao tem em comum e decidir quanto conhecimento dessas arquitetura de aplicao pode reusar. Em sistema embutidos e sistemas projetados para computadores pessoais, h somente um processador, preciso projetar uma arquitetura distribuda para o sistema. Portanto, sistemas muito grandes so, atualmente sistema distribudos em que o software e distribudo por meio de computadores diferentes. A arquitetura de um sistema de software de sistema distribuda e pode ser baseada em um modelo ou estilo de arquitetura especifica. Um estilo de arquitetura um padro de organizao de sistema como uma organizao cliente servidor ou uma arquitetura em camadas. Diferentes partes do sistema podem ser projetadas usando estilos diferentes de arquitetura. Alguns casos a arquitetura pode ser composta criada pela combinao de estilos de arquitetura diferentes.

 preciso escolher a estrutura mais apropriada como a estrutura cliente servidor ou em camadas que permita atender aos requisitos sistema. preciso tomar deciso sobre a estratgia de decomposio de subsistemas em componentes ou mdulos. No processo de modelagem de controle, deve tomar decises como a execuo de subsistemas controlada. A avaliao do projeto de arquitetura difcil, pois o verdadeiro teste de uma arquitetura recai sobre quem bem ela atende os requisitos funcionais e no funcionais depois de implantadas. O processo de projeto de arquitetura um documento, ele pode incluir varias representaes grficas do sistema junto com um texto descritivo associado. Deve ser descrito como o sistema est estruturado em subsistemas, a abordagem adotada e como cada subsistema est estruturada em mdulos. Os modelos de arquitetura podem ser desenvolvidos podem incluir: Um modelo esttico de estrutura: Que mostra os subsistemas ou componentes desenvolvidos como unidades separadas. Um modelo dinmico de processo: Que mostra como o sistema esta organizado em processos em tempo de execuo. Um modelo de interface: Que define os servios oferecidos por cada subsistema por meio de suas interfaces publicas. Modelos de relacionamento: Que mostram os relacionamentos, tal com fluxo de dados, entre os subsistemas. Um modelo de distribuio: que mostra como os subsistemas podem ser distribudos pelos computadores. Alguns pesquisadores propuseram o uso de ADL Linguagem de descrio de arquiteturas para descrever arquiteturas de sistemas. Os elementos bsicos so componentes e conectores e incluem regras e guias para arquiteturas bem formadas, mas as ADLs podem ser compreendidas somente por especialistas em linguagens e so inacessveis para especialistas em domnios e aplicaes. Modelos informais e notaes como a UML permanecero como as notaes mais comumente usadas para descrio de arquiteturas.

11.2 ORGANIZAES DE SISTEMA Reflete a estratgia bsica usada para estrutur-lo. preciso tomar deciso sobre modelo geral organizacional de um sistema com antecedncia no processo de projeto de arquitetura. A organizao do sistema pode refletir-se diretamente na estrutura do subsistema. frequente que o modelo de subsistema inclua mais detalhes que o modelo de organizao e nem sempre h um mapeamento simples dos sistemas para a estrutura organizacional. Sero apresentados trs estilos organizacionais que so utilizados.

11.2.1 O modelo repositrio Os subsistemas constituem um sistema que devem trocar informaes de modo que possam trabalhar juntos eficientemente. Existem duas maneiras pelas quais isso pode ser feito. Todos os dados compartilhados so mantidos em um banco de dados podendo ser acessado por um subsistema. O sistema baseado em um banco de dados compartilhado algumas vezes denominado modelo repositrio. Cada subsistema mantm seu prprio banco de dados. Os dados so trocados com outros subsistemas por meio da passagem de mensagem entre eles. A maioria dos sistemas que usam grande quantidade de dados organizada em um banco de dados ou repositrio compartilhado. Portanto adequado para aplicaes em que os dados so gerados por um subsistema e usado por outro. Nesse tipo de sistema incluem sistemas de comando e controle de informaes gerenciais, sistemas CAD e os conjuntos de ferramentas CASE. Segue as vantagens e Desvantagens de um repositrio compartilhado: a maneira eficiente de compartilhar grandes quantidades de dados. No h necessidade de transmitir dados explicitamente de um subsistema para outro.

Os subsistemas devem estar de acordo com o modelo de dados de repositrio. um compromisso entre as necessidades especificas de cada ferramenta.

Os subsistemas que produzem dados no precisam sabem como esses dados so usados por outros subsistemas. A evoluo pode ser difcil quando um grande volume de informao gerado de acordo com o modelo de dados estabelecidos. Atividades como back-ups, proteo, controle de acesso e recuperao de erros so centralizadas. Elas so de responsabilidade do gerenciador de repositrio.

Subsistemas diferentes podem ter requisitos diferentes para polticas de proteo, recuperao e back-ups. Modelo de compartilhamento visvel pro meio do esquema de repositrio. Novas ferramentas podem ser integradas diretamente considerando que sejam compatveis com o modelo de dados estabelecido.

Pode ser difcil distribuir o repositrio por uma srie de mquinas, embora seja possvel distribuir um repositrio centralizado, pode haver problemas com redundncia e inconsistncia de dados. O repositrio passivo e o controle de responsabilidade dos

subsistemas que o usam. Foi feito uma abordagem alternativa para sistemas de IA que usam o modelo blackboard, que dispara os subsistemas quando um determinado dado torna-se disponvel, mais adequado quando a forma dos dados do repositrio bem menos estruturada.

11.2.2 O modelo cliente servidor um modelo em que o sistema organizado como um conjunto de servios servidores e clientes associados que acessam e usam os servios. Principais componentes so: Um conjunto de servidores que oferecem servios para outros subsistemas. Como exemplo tem os servidores de impressora,

servidores de arquivos e servidores de compiladores. Um conjunto de cliente que solicita os servios oferecidos pelos servidores. Normalmente so subsistemas independentes. Uma rede que permite aos clientes acessarem esses servios. No estritamente necessrio quando ambos, clientes e servidores, podem ser executados em uma nica maquina. Os clientes precisam saber os nomes dos servidores disponveis e os servios que eles fornecem. No entanto servidores no precisam saber identidades dos clientes ou quantos clientes existem. Os clientes acessam os servios fornecidos pelo servidor meio de chamadas remotas de procedimento usando um protocolo request reply como protocolo HTTP usando na web. O catalogo deve ser capaz de lidar com vrias consultas e fornecer links para sistema web de informaes com dados do filmo e videoclipe, e um sistema e-commerce que apoia a venda de filmes e videoclipes. O programa cliente simplesmente uma interface com o usurio, construda com o uso de um navegador web para esses servios. A vantagem mais importante de um modelo cliente servidor que ele uma arquitetura distribuda. Mudana em clientes e servidores pode ser existente podem ser necessrias para obter os plenos benefcios da integrao de um novo servidor.

11.2.3 O modelo em camadas Denominado modelo de mquina abstrata, organiza um sistema em camadas, cada uma das quais fornecendo um conjunto de servios. Cada camada pode ser imaginada como uma mquina abstrata cuja linguagem de mquina definida pelos servios fornecidos pela camada. Um exemplo de modelo de camada o modelo de referncia OSI de protocolos de rede. O Sistema de gerenciamento de configurao gerencia verses

de objetos e fornece recursos gerais de gerenciamento de configurao. usado para um sistema de gerenciamento de objetos que armazena informaes e servios de gerenciamento para itens ou objetos de configurao. Esse sistema construdo sobre um sistema de banco de dados para fornecer armazenamento e servios bsicos de dados, como gerenciamento de transaes, rollback e recuperao, e controle de acesso. O gerenciamento de banco de dados usa recursos bsicos do sistema operacional e repositrio de arquivos em sua implantao. A abordagem em camada apoia o desenvolvimento incremental de sistemas. medida que uma camada desenvolvida alguns servios fornecidos por essa camada podem ser disponibilizados para os usurios. Desde que sua interface permanea inalterada, uma camada poder ser substituda por outra equivalente. A desvantagem da abordagem em camadas que a estruturao de sistemas maneira pode ser difcil. Camadas mais internas podem fornecer recursos bsicos como gerenciamento de arquivos, necessrios em todos os nveis. O desempenho pode ser um problema devido aos vrios nveis de interpretao de comandos algumas vezes exigidos. 11.3 ESTILOS DE DECOMPOSIO MODULAR uma tomada de deciso sobre a abordagem a ser usada na decomposio de subsistemas em mdulos. Os componentes em mdulo so geralmente menores do que os subsistemas que permitem a utilizao de estilos alternativos de decomposio. Podemos pensar nos subsistemas e mdulos da seguinte maneira: Um subsistema um sistema em si cuja operao no depende de servios fornecidos por outros subsistemas. So decompostos em mdulos e definem interfaces que so usadas para comunicao. Um mdulo normalmente um componente de um sistema que Fornece um ou mais servios para outros mdulos. Os mdulos so compostos em srie de outros componentes mais simples do sistema. Existem duas estratgias principais que pode usar para

decompor um subsistema em mdulo. Decomposio orientada a objeto: onde compe um sistema em um conjunto de objetos que se comunicam. Pipelining: Orientado a funo na qual decompes um sistema em modulo funcionais que aceitam dados de entrada e transforma os em dados de sada. Em orientado a objetos, os mdulos so objetos com estado privado e operaes definidas sobre esse estado. No modelo pipelining, os mdulos so transformaes funcionais. Deve evitar decises prematuras sobre a simultaneidade de um sistema. A vantagem de evitar um projeto de sistema concorrente que programas sequencias so mais fceis de projetar, implementar e testar do que sistemas paralelos.

11.3.1 Decomposio orientada a objetos um sistema em um conjunto de objetos no firmemente acoplados com interfaces bem definidas. Uma decomposio orientada a objetos est relacionada a classes de objetos, seus atributos e suas operaes. Quando implementados os objetos so criados a partir dessas classes e algum modelo de controle usado para coordenar as operaes de objetos. Os objetos so representaes de entidades do mundo real e, assim, a estrutura do sistema rapidamente entendida. Essas entidades so usadas em sistemas diferentes, os objetos podem ser reusados. Linguagem de programao orientada a objetos foram desenvolvidas de modo a permitirem implementao direta de componentes de arquitetura. A abordagem orientada a objetos tem desvantagens. Os objetos devem fazer referncias ao nome e a interface de outros objetos.

11.3.2 PIPELINING ORIENTADO A FUNES As funes ou modelo de fluxo de dados, as transformaes funcionais processam suas camadas e produzem sadas. Os dados fluem de uma para outra funo e so transformados ao moverem-se sequencialmente. Os dados podem ser processados por cada transformao item por item ou em um nico lote. As transformaes so representadas como processos separados esse modelo algumas vezes chamado estilo duto (PIPE) e filtro, segundo a terminologia usada no sistema Unix. O sistema Unix fornece dutos que agem como condutores de dados e um conjunto de comandos que so transformaes funcionais. O termo filtro usado porque uma transformao filtra os dados que pode processar a partir do caminho de dados de entrada. As vantagens dessa arquitetura so: Ela apoia o reuso de transformaes. Ela intuitiva, no sentido de que muitas pessoas pensam em seu trabalho em termos de processamento de entrada e sada. A evoluo do sistema pela adio de novas transformaes e geralmente direta. Ela simples de ser implementada tanto quanto um sistema concorrente ou sequencial. O principal problema desse estilo que ele necessita ser um formato comum para transferncia de dados que possa ser reconhecido por todas as transformaes. As transformaes devem estar de acordo com suas transformaes de comunicao sobre o formato de dados que sero processados ou, ento deve ser imposto um formato padro para todos os dados comunicados. As transformaes devem analisar sua entrada e ajustar sua sada de acordo com a forma estabelecida. Com isso aumenta o overhead dos sistemas e pode significar a impossibilidade de integrar transformaes que usam formatos de dados incompatveis. Sistemas interativos so difceis de escrever usando o modelo de pipelining por causa da necessidade de uma sequencia de dados ser

processada. A entrada e a sada de textos simples podem ser modeladas dessa maneira, interface grficas com o usurio tem formatos e controlo de entradas/sadas mais complexos, baseando em eventos como cliques com o mouse ou selees de menus. 11.4 MODELOS DE CONTROLE Os modelos de estruturao esto relacionados como um sistema decomposto em subsistemas. Para funcionar como um sistema, os subsistemas devem ser controlados de maneira que seus servios sejam entregues no lugar certo e no tempo certo. Modelos estruturais no incluem (nem devem incluir) informaes de controle. O arquiteto deve organizar os subsistemas de acordo com algum modelo de controle que suplementa o modelo de estrutura usado. Modelos de controles no nvel de arquitetura lidam com o fluxo de controle entre subsistemas. Existem dois estilos genricos de controle usados pelo sistema de software: Controle centralizado: um subsistema que tem responsabilidade geral pelo controle e inicia e para outros sistemas. Pode tambm passar o controle a outro subsistema, mas esperar que essa responsabilidade de controle seja devolvida a ele. Controle baseado a eventos: As informaes de controle em vez de ser incorporado em um subsistema, cada subsistema podem responder a eventos gerados externamente. Modelos de controle so usados em conjunto com estilo de estrutura. Os estilos de estrutura podem ser implementados por meio de controle centralizado ou baseado em eventos.

11.4.1 Controle centralizado No modelo centralizado um subsistema designado como controlador de sistema e tem a responsabilidade pelo gerenciamento da execuo de outros subsistemas. Os modelos de controle centralizado dividemse em duas classes dependendo de se os subsistemas controlados forem

executados sequencial ou paralelamente. O modelo chamadaretorno: conhecido modelo top-down de sub-rotina em que o controle comea no topo da hierarquia de sub-rotina e atravs de chamadas de sub-rotinas, passa para os nveis mais baixos na rvore. Aplicvel somente em sistemas sequenciais. O modelo gerenciador: este modelo aplicvel a sistemas concorrentes. projetado como um gerenciador de sistemas e controla o incio, a parada e a coordenao de outros processos de sistemas. Um processo um subsistema ou um modulo que pode ser executado paralelamente com outros processos. O modelo chamada-retorno pode ser usado no nvel de mdulo para controlar funes e objetos. As sub-rotinas em uma linguagem de programao chamada por outras sub- rotinas so naturalmente funcionais. Em muitos sistemas orientados objetos, as operaes que envolvem objetos (mtodos) so implementadas como procedimentos ou funes. Quando um objeto Java requisita um servio para outro objeto, ele o faz chamando um mtodo associado. A natureza rgida e restritiva desse modelo ao mesmo tempo um ponto forte e fraco. Ponto forte porque relativamente simples analisar fluxos de controle e testar como o sistema responder a entradas especficas. Um ponto fraco porque, em operao normal, difcil lidar com as excees. O modelo controle centralizado de gerenciamento muitas vezes, usado em sistemas de tempo real simples sem muitas restries rgidas de tempo. O controlador central gerencia a execuo de um conjunto de processos associados a sensores e atuadores. O processo controlador do sistema decide quando os processos devem ser iniciados ou interrompidos dependendo das variveis de estado do sistema. Ele verifica se outros processos produziram informaes a serem processadas ou passadas a eles para processamento. O controlador geralmente esta em loop contnuo, varrendo os sensores e outros processos em busca de eventos ou mudanas de estado.

11.4.2 Sistemas orientados a eventos Neste contexto o termo evento no significa somente um sinal binrio. Pode ser um sinal que pode assumir uma gama de valores ou uma entrada de comando baseado em um menu. A distino entre um evento e uma entrada simples que a ocorrncia do evento esta fora do controle do processo que manipula esse evento. Existem muitos tipos sistemas orientados a eventos. Incluem editores em que os eventos de interface com o usurio significam comandos de edio, sistema de produo baseados em regras como os usados em IA (inteligncia Artificial), nos quais uma condio ai tornar-se verdadeira causa uma ao a ser disparada, e objetos ativos nos quais a mudana de um valor de um atributo de objetos dispara algumas aes. Nesta seo abordo dois modelos de controle orientados a eventos: Modelos de broadcast: neste modelo, um evento transmitido a todos os subsistemas. Qualquer subsistema programado para manipular esse evento pode responder a ele. Modelos orientados a interrupes: so usados exclusivamente em sistema de tempo real nos quais interrupes externas so detectadas por um tratador de interrupes. Estas so passadas para algum outro componente para processamento. Modelos de broadcast so eficazes na integrao de sistemas distribudos em diferentes computadores de rede. Modelos orientados a interrupes so usados em sistemas de tempo real com requisitos rigorosos de tempo. Em broadcast os sistemas registram um interesse em eventos especficos. Quando esses eventos ocorrem, o controle transferido para o subsistema que pode tratar o evento. Todos os eventos podem ser transmitidos a todos os subsistemas, mas isso impe um grande overhead de processamento. Os subsistemas geram eventos que indicam que algum dado est disponvel para processamento. O tratador de evento detecta os eventos, consulta o registrador de eventos e passa o evento aos subsistemas que

declaram interesse. Em sistemas simples como os sistemas baseados em PC orientados a eventos de interface com o usurio, existem subsistemas explcitos do tipo evento ouvinte que escutam os eventos do mouse, teclado etc. A vantagem dessa abordagem de broadcast que a evoluo que e relativamente simples. Um novo subsistema pode tratar classe especificas de eventos pode ser integrado por meio do registro de seus eventos no tratador de eventos. Qualquer subsistema pode ativar qualquer outro subsistema sem saber seu nome ou sua localizao. Os subsistemas podem ser implementados em maquinas distribudas. A desvantagem desse modelo que os subsistemas no sabem se ou quando os eventos sero manipulados. Quando um subsistema gera um evento no sabe quais pontos subsistemas registraram interesse nesse evento. Os sistemas de tempo real requerem que eventos gerados externamente sejam manipulados, provavelmente devem ser orientados a eventos. Cada tipo de interrupo de determinado tipo recebida, uma chave de hardware transfere o controle imediatamente para seu tratador. Esse modelo usado em sistemas de tempo real em que uma resposta imediata a algum evento necessrio. A vantagem da abordagem que ela permite resposta muito rpidas aos eventos por serem implementados. A desvantagem a complexidade da programao e a dificuldade de validao. Podem obter melhores resultados com essa limitao pelo mapeamento dos vrios tipos de eventos em uma nica interrupo.

11.5 ARQUITETURAS DE REFERNCIA Eles podem ser aplicados em muitas classes de aplicaes. Esses modelos de arquitetura especficos a determinado domnio de aplicao podem ser usados. As instncias desses sistemas sejam diferentes em detalhes a estrutura comum de arquitetura pode ser reusada no desenvolvimento de novos sistemas. Esses modelos de arquitetura so

chamados de arquitetura de domnio especfico. Existem dois tipos de modelos de arquitetura de domnio especfico: Modelos genricos: So abstrao de uma serie de sistemas reais. Eles englobam as caractersticas principais desses sistemas. Em sistemas de tempo real, pode haver modelos genricos de arquiteturas de tipos de sistemas diferentes, como sistemas de coleta de dados ou sistemas de monitorao. Modelos de referncia: So mais abstratos e descrevem uma classe maior de sistemas. Eles so um meio de informao para os projetistas sobre a estrutura geral dessa classe de sistema. Os modelos de referencias so geralmente derivados de um estudo de domnio de aplicao. Representam uma arquitetura idealizada que inclui todas as caractersticas que esses sistemas podem incorporar. No h distino rgida entre esses tipos de modelo. Modelos genricos podem tambm servir como modelos de referncias. Os genricos podem ser reusados diretamente em projetos. Os modelos de referncia so normalmente usados para comunicar conceitos de domnios e comparar ou avaliar possveis arquiteturas. As arquiteturas de referncias no so geralmente consideradas um roteiro de implementao. Sua principal funo ser um meio de discusso de arquitetura de domnio especfico e de comparao de sistemas diferentes em um domnio. O modelo OSI um modelo de sete camadas para interconexo de sistemas abertos. As funes exatas das camadas no so importantes aqui. As camadas inferiores esto relacionadas interconexo fsica; as camada intermedirias, transferncia de dados e as camadas superiores, transferncia de informaes semanticamente significativas de aplicao como documentos padronizados. Os projetistas do modelo OSI tinham um objetivo muito pratico ao definir um padro de implementao de modo que sistemas em conformidade com o padro pudessem se comunicar uns com os outros. medida que a tecnologia se desenvolvesse, um camada poderia ser novamente implementada de maneira transparente sem afetar os sistemas que usassem

as outras camadas. Os problemas da abordagem pro camadas para modelagem de arquitetura comprometeram esse objetivo. As grandes diferenas entre redes, interconexes simples podem ser impossveis. Os desenvolvedores do sistema precisam implementar seus prprios recursos de alto nveis e ignorar camadas de modelo. Eles precisam projetar recursos no padronizados para aprimorar o desempenho do sistema. Outros modelos de referncias um modelo para ambiente CASE que identifica cinco conjuntos de servios que um ambiente CASE deve fornecer. Deve tambm fornecer recurso de plug-in para ferramentas CASE individuais que usam esses servios. Os cinco nveis de servios em um modelo CASE de referncia so: Servios de repositrios de dados: estes servios fornecem recursos para o armazenamento e o gerenciamento de itens de dados e seus relacionamentos. Servios de integrao de dados: estes servios fornecem recursos para o gerenciamento de grupos ou para definio de relacionamento entre eles. Os servios de repositrios de dados so base de integrao de dados no ambiente. Servios de gerenciamento de tarefas: estes servios fornecem recursos para a definio e aprovao de modelos de processo. Apoiam a integrao de processo. Servios de mensagem: estes servios fornecem recursos para a comunicao ferramenta ferramenta, ambiente ferramenta e ambiente-ambiente. Apoiam a integrao de controle. Servios de interfaces com usurio: estes servios fornecem recursos para o desenvolvimento de interface com o usurio. Apoiam a integrao de apresentao. O modelo de referncia nos mostra o que pode ser includo em qualquer ambiente CASE em particular, embora seja importante enfatizar que nem todo recurso de uma arquitetura de referencia pode ser includo nos projetos reais de arquitetura. Significa que podemos formular algumas

questes sobre um projeto de sistema como por exemplo, como so fornecidos os servios de repositrios de dado? e o sistema fornece gerenciamento de tarefa?. Tem por finalidade principal dessa arquitetura de referncia ser um meio de classificao e comparao de ferramentas em ambientes CASE integrados.