Visões em Arquitetura de Software: Ane Cristina Varoto

Vises em arquitetura de software
Ane Cristina Varoto
DISSERTAO APRESENTADA AO INSTITUTO DE MATEMTICA DE ESTATSTICA DA UNIVERSIDADE DE SO PAULO PARA OBTENO DO GRAU DE MESTRE EM CINCIA DA COMPUTAO.
rea de Concentrao: Engenharia de Software Orientador: Prof. Dr. Hernn Astudillo
So Paulo, 14 de maro de 2002.
Este exemplar corresponde redao final da dissertao devidamente corrigida e defendida por Ane Cristina Varoto e aprovada pela comisso julgadora.
So Paulo, 14 de maro de 2002.
Banca examinadora: Prof. Dr. Hernn Astudillo (IME USP) Prof. Dr. Fbio Kon (IME USP) Prof. Dr. Reginaldo Arakaki (POLI USP)
Agradecimentos
Agradeo primeiramente a Deus por ser fonte inesgotvel de luz que ilumina e guia todos os meus passos, e por ter sido sustentao nestes anos de estudo que direcionaram a obteno deste ttulo. Agradeo minha grande famlia, em especial aos meus pais, Orlando e Dalva, por todo amor, apoio e incentivo que dedicaram a mim, apesar da distncia. Agradeo ao meu orientador, Hernn Astudillo, por acreditar no meu esforo e trabalho e tambm por me transmitir sua experincia e seus conhecimentos na rea de arquitetura de software. Agradeo ao professor e amigo Reginaldo Arakaki, pelo apoio e pelos momentos de discusso que muito contriburam para o resultado final desta dissertao. Agradeo aos amigos da Scopus que trabalham comigo, pelo apoio, pela troca de experincias e por suportarem meus momentos de estresses. Agradeo aos meus amigos que costumo chamar de famlia postia, Scheila, Roseane, Heitor, Sandro, Angeluce e Dufray, pelo carinho e incentivo. Finalmente, agradeo aos professores e funcionrios do IME e tambm aos companheiros de mestrado pelo apoio e incentivo mtuo.
Resumo
Muitos fatores podem causar o insucesso de sistemas de software e no so percebidos pelas pessoas envolvidas durante o desenvolvimento. Identificar tais fatores no trivial. Especificaes e implementaes calcadas apenas em requisitos funcionais no garantem o bom andamento do projeto e nem a robustez do sistema, principalmente quanto consideramos a vulnerabilidade do contexto e o dinamismo das definies. A preocupao em corresponder todos os requisitos necessrios - tanto os requisitos funcionais quanto os atributos de qualidade (ou requisitos no funcionais) com os subsistemas e componentes que compem este sistema deve ser constante. E fornecer subsdios para antecipar tomadas de decises importantes, minimizando riscos. A esta definio chamamos arquitetura de software. A arquitetura de um software pode ser observada sob diversas perspectivas ou vises, cada qual ressaltando aspectos especficos. As vises podem ser utilizadas como base para se definir a arquitetura de um software, considerando sua abrangncia no processo de desenvolvimento de sistemas, seu foco de atuao e seu impacto nos fatores de qualidade requeridos para a soluo do problema. Este documento traz a formalizao de alguns esquemas de vises em arquitetura, especificando a competncia, a abrangncia e os detalhes de cada viso. Tambm faz uma comparao entre as vises de cada esquema segundo os fatores de qualidade de McCall, podendo ser utilizada como um checklist para garantir os nveis de qualidade desejados para a soluo.
Abstract
Many factors that can cause the failure of software systems are not perceived by those involved during development. Identifying such factors is not trivial. Specifications and implementations based only on functional requirements guarantee neither the robustness of the system nor that the project will proceed smoothly, especially when we consider the context vulnerability and the definitions dynamism. The concern with matching all requirements both functional requirements and quality attributes (or non-functional requirements) with the subsystems and components that make up the system should be constant. This concern helps to anticipate important decisions, hence minimizing risks. The architecture of a software system can be observed from diverse perspectives or viewpoints, each of them emphasizing specific aspects. The viewpoints can be used as a base to define a software architecture, considering its influence on the system development process, its objectives and its impact on the quality factors required for the solution of the problem. This document presents the formalization of a few architectural viewpoint schemes, specifying the competence, scope and details of each viewpoint. It also makes a comparison between the viewpoints of each scheme according to the McCall quality factors. This comparison may be used as a checklist to guarantee the levels of quality desired for the solution.
ndice
1.
1.1. 1.2. 1.3.
INTRODUO .............................................................................................................. 1 PROPSITO E OBJETIVO DESTE DOCUMENTO ............................................................... 1 MOTIVAO .................................................................................................................. 1 ORGANIZAO E AUDINCIA DO DOCUMENTO ............................................................ 2 ARQUITETURA DE SOFTWARE.............................................................................. 5 CONCEITOS DE ARQUITETURA DE SOFTWARE .............................................................. 6 O PROCESSO DA ARQUITETURA DE SOFTWARE ........................................................... 7 A IMPORTNCIA DA ARQUITETURA ............................................................................. 9 Arquitetura e a Comunicao entre os Participantes ........................................... 9 Arquitetura e a Antecipao de Decises de Projeto.......................................... 10 Arquitetura e o Reuso.......................................................................................... 11 Localizao da Arquitetura no Processo de Desenvolvimento de Sistemas ....... 12 Influncias da Arquitetura no Processo de Desenvolvimento de Sistemas ......... 15
2.
2.1. 2.2. 2.3.
2.3.1. 2.3.2. 2.3.3. 2.4. 2.4.1. 2.4.2. 2.5.
ARQUITETURA DE SOFTWARE NO PROCESSO DE DESENVOLVIMENTO DE SISTEMAS 12
CONCLUSO DO CAPTULO ......................................................................................... 18 TCNICAS EM ARQUITETURA DE SOFTWARE............................................... 20 ARQUITETURA PARA UM SISTEMA E ARQUITETURAS DE REFERNCIA ...................... 22 Modelo de Referncia.......................................................................................... 22 Estilo de Arquitetura ........................................................................................... 22 Arquitetura de Referncia ................................................................................... 23 Diferenas entre os Conceitos............................................................................. 23 Organizao dos Estilos de Arquitetura ............................................................. 26 Alguns Estilos de Arquitetura.............................................................................. 27
3.
3.1.
3.1.1. 3.1.2. 3.1.3. 3.1.4. 3.2. 3.2.1. 3.2.2. 3.3. 3.4. 3.5.
ESTILOS DE ARQUITETURA ......................................................................................... 25
ARQUITETURA DE LINHA DE PRODUTOS .................................................................... 32 DESCRIO E AVALIAO DE ARQUITETURAS .......................................................... 36 CONCLUSO DO CAPTULO ......................................................................................... 38 VISES EM ARQUITETURA DE SOFTWARE..................................................... 40 CONCEITOS DE VISES................................................................................................ 41 O que so Vises ................................................................................................. 41
4.
4.1.
4.1.1.
4.1.2. 4.1.3. 4.2. 4.2.1. 4.2.2. 4.2.3. 4.2.4. 4.2.5. 4.3. 4.3.1. 4.3.2. 4.3.3. 4.4.
4.5.
O que so Esquemas de Vises ........................................................................... 42 Tipos de Vises .................................................................................................... 42 OMT..................................................................................................................... 45 Booch................................................................................................................... 48 4+1 (RUP) ...................................................................................................... 51 RM-ODP.............................................................................................................. 54 Zachman .............................................................................................................. 59 TAFIM ................................................................................................................. 63 TOGAF ................................................................................................................ 65 Holfmeister-Nord-Soni ........................................................................................ 66
PRINCIPAIS ESQUEMAS DE VISES EM ARQUITETURA DE SOFTWARE ....................... 44
ALGUNS OUTROS ESQUEMAS DE VISES MENOS DIFUNDIDOS ................................. 62
COMPARAO ENTRE OS PRINCIPAIS ESQUEMAS DE VISES ..................................... 68 RESUMO COMPARATIVO DOS PRINCIPAIS ESQUEMAS DE VISES .............................. 71 CONCLUSO DO CAPTULO ......................................................................................... 72 UTILIZAO DOS ESQUEMAS DE VISES........................................................ 73 ABRANGNCIA DOS ESQUEMAS DE VISES ................................................................ 74
4.6.
5.
5.1.
5.1.1. Esquema Conceitual para Comparar Esquemas de Vises Segundo a sua Abrangncia no Processo de Software .............................................................................. 74 5.1.2. 5.2. 5.2.1. 5.2.2. 5.3. 5.4. Comparao dos Esquemas Usando o Esquema Conceitual.............................. 76 Modelo de Qualidade de Software ...................................................................... 80 Comparao dos Esquemas de Vises Usando o Modelo de Qualidade ............ 82 IMPACTO DAS VISES NA QUALIDADE DO SOFTWARE ............................................... 80
CONSIDERAES FINAIS SOBRE AS COMPARAES ................................................... 88 CONCLUSO DO CAPTULO ......................................................................................... 89 CONCLUSES E TRABALHOS FUTUROS........................................................... 91
6.
ANEXO 1 FRAMEWORK DE ZACHMAN ....................................................................... 94 REFERNCIAS BIBLIOGRFICAS .................................................................................. 96
Lista de Figuras
FIGURA 2.1 PROCESSO DE DESENVOLVIMENTO DE SISTEMAS MODELO CASCATA ........ 14 FIGURA 2.2 A ARQUITETURA NO PROCESSO DE DESENVOLVIMENTO DE SISTEMAS ......... 15 FIGURA 2.3 CONTRIBUIES PARA DEFINIO DA ARQUITETURA .................................... 16 FIGURA 2.4 INFLUNCIA DA ARQUITETURA NAS DEMAIS FASES DO DESENVOLVIMENTO DE SISTEMAS ........................................................................................................ 18 FIGURA 3.1 RELACIONAMENTO ENTRE MODELO DE REFERNCIA, ESTILO DE ARQUITETURA
E ARQUITETURA DE REFERNCIA IMPLEMENTANDO UMA ARQUITETURA DE SOFTWARE [BASS98]. ..................................................................................... 23
FIGURA 3.2 UTILIZAO DE ESTILO DE ARQUITETURA, MODELO DE REFERNCIA E ARQUITETURA DE REFERNCIA NA DEFINIO DA ARQUITETURA DO SOFTWARE DE VISIBROKER. .......................................................................... 25 FIGURA 3.3 COMPARAO DE ARQUITETURA PARA CONSTRUO DE UM SISTEMA E PARA CONSTRUO DE VRIOS SISTEMAS. .............................................................. 33 FIGURA 3.4 INTERSEO CONCEITUAL ENTRE LINGUAGENS DE REQUISITOS, PROGRAMAO E MODELAGEM E ADL. ................................................................................... 37 FIGURA 4.1 DIMENSES DA OMT....................................................................................... 46 FIGURA 4.2 RELAO ENTRE AS REPRESENTAES DO ESQUEMA DE VISES OMT ........ 47 FIGURA 4.3 OS MODELOS DO PROJETO ORIENTADO A OBJETOS DE BOOCH........................ 50 FIGURA 4.4 VISES DO ESQUEMA 4+1 (RUP). ............................................................... 51 FIGURA 4.5 VISES DO ESQUEMA RM-ODP. ..................................................................... 55 FIGURA 4.6 VISES DO ESQUEMA DE HOLFMEISTER-NORD-SONI [HOLFMEISTER00]....... 67 FIGURA 4.7 ABRANGNCIA DE CONCEITOS X ORIGEM DOS CONCEITOS ............................ 70 FIGURA 4.8 RESUMO DAS COMPARAES ENTRE OS PRINCIPAIS ESQUEMAS DE VISES .. 71 FIGURA 5.1 FATORES DE QUALIDADE DE SOFTWARE DE MCCALL. ................................... 81 FIGURA A - 1 FRAMEWORK DE ZACHMAN .......................................................................... 95
Lista de Tabelas
TABELA 3.1 ESTILOS DA CATEGORIA FROM MUD TO STRUCTURE ....................................... 27 TABELA 3.2 ESTILO DA CATEGORIA SISTEMAS DISTRIBUDOS .......................................... 29 TABELA 3.3 ESTILOS DA CATEGORIA SISTEMAS INTERATIVOS .......................................... 30 TABELA 3.4 ESTILOS DA CATEGORIA SISTEMAS ADAPTVEIS........................................... 31 TABELA 3.5 CARACTERSTICAS E DIFICULDADES DE UMA ARQUITETURA DE LINHA DE PRODUTO ........................................................................................................ 35 TABELA 4.1 RESUMO DAS VISES DO ESQUEMA OMT...................................................... 48 TABELA 4.2 RESUMO DOS DIAGRAMAS DO ESQUEMA DE VISES DE BOOCH ................... 50 TABELA 4.3 RESUMO DAS VISES DO ESQUEMA 4+1 (RUP) ......................................... 54 TABELA 4.4 RESUMO DAS VISES DO ESQUEMA RM-ODP ............................................... 59 TABELA 4.5 RESUMO DAS VISES DO ESQUEMA DE ZACHMAN ........................................ 61 TABELA 5.1 RELEVNCIA DAS VISES NAS FASES DO PROCESSO DE DESENVOLVIMENTO DE SISTEMAS........................................................................................................ 77 TABELA 5.2 DESCRIO DOS FATORES DE QUALIDADE DE MCCALL................................ 81 TABELA 5.3 MATRIZ DE QUALIDADE DOS ESQUEMAS DE VISES ..................................... 83
IME USP
1. Introduo
1.1. Propsito e Objetivo deste Documento
O objetivo deste trabalho concentra-se em trs pontos principais a saber: 1. Apresentar a arquitetura de software atravs dos conceitos encontrados na literatura; 2. Apresentar os esquemas de vises em arquitetura de software, comparandoos conforme sua evoluo no tempo e sua abrangncia conceitual; e 3. Discutir a correlao dos esquemas de vises, considerando a colocao do esquema dentro do processo de desenvolvimento de software e tambm os fatores de qualidade que cada esquema aborda, conforme o modelo de qualidade de McCall.
1.2. Motivao
Ao se construir sistemas grandes e complexos, necessrio tomar uma srie de decises sobre o hardware e o software que sero utilizados. Para que estas decises sejam tomadas de forma consciente, preciso conhecer as funcionalidades do sistema que ser desenvolvido, os atributos de qualidade que o sistema requer e o ambiente no qual dever funcionar. Mas quando cada deciso deve ser tomada? Quem o responsvel pelas decises? Quais alternativas de solues devem ser consideradas? Como as alternativas devem ser escolhidas? As respostas para estas perguntas no so bvias e nem fceis de se obter. Por presso de mercado e no utilizao de tcnicas e mtodos de desenvolvimento de sistemas trazidos pela engenharia de software, os desenvolvedores buscam de imediato a implementao e a infra-estrutura na qual o sistema ir operar, desconsiderando a anlise e o projeto dos requisitos. Existem outros fatores que podem levar o sistema ao insucesso:
IME USP
Utilizao de novas tecnologias como soluo para o desenvolvimento, sem analisar o contexto, o domnio e a adequao ao problema;
Falta de flexibilidade para incorporar mudanas inesperadas de requisitos e futuras evolues, relegando prticas de reutilizao;
Preciosismo na especificao de requisitos funcionais apontados pelos usurios, desconsiderando aspectos implcitos de qualidade tais como portabilidade, testabilidade e segurana.
A preocupao est em resolver estes fatores atravs de descries de todos os elementos do sistema, a interao entre estes elementos, os padres que apiam tal composio e as restries, ou seja, definir a arquitetura de software. Com base na arquitetura, possvel obter um sistema robusto, com um nvel adequado de qualidade e que atende s expectativas dos usurios. A definio de uma arquitetura envolve vrias pessoas que desempenham diferentes papis, cada uma observando um aspecto de qualidade do sistema. As pessoas que exercem o mesmo papel no conseguem determinar todas as propriedades necessrias para se obter uma arquitetura robusta e eficiente. Por isso, a arquitetura deve ser observada sob diversos pontos de vista, ou seja, diversas vises. Cada viso ressalta os detalhes que lhe competem, ignorando os outros detalhes que sero ressaltados em outras vises. importante observar que a definio de uma arquitetura deve estar relacionada com a estratgia de obteno do sistema, ou seja, a arquitetura precisa estar em conformidade com o escopo necessrio para a primeira verso do sistema, mas suficientemente flexvel e preparada para incorporar e absorver as evolues subsequentes.
1.3. Organizao e Audincia do Documento

O captulo 2 traz uma viso geral da rea de arquitetura de software, mostrando que os conceitos e definies relacionados ao termo so recentes, embora as atividades j estejam bastante conhecidas. A novidade est no formalismo das definies e na organizao de tais atividades.
IME USP
O captulo 2 um captulo conceitual. Assim sendo, a audincia que pode se beneficiar da leitura so pessoas que conhecem ou trabalham com a cincia e engenharia da computao, mas no esto envolvidas especificamente com as atividades relacionadas arquitetura de software, ou ento no as visualizam de maneira formalizada. O captulo 3 apresenta conceitos mais avanados em arquitetura de software com o intuito de estabelecer terminologias e mostrar os mltiplos usos do termo. Neste captulo, feita a distino entre arquitetura de software, estilo de arquitetura, arquitetura de referncia e arquitetura de linha de produto alm de apresentar tambm alguns conceitos de qualidade que apiam a avaliao e validao da arquitetura. A audincia que pode se beneficiar da leitura do captulo 3 so as pessoas que j tm a noo do que arquitetura de software e precisam tornar as diferenas conceituais mais claras. O captulo 4 apresenta e compara alguns esquemas de vises encontrados na literatura. Neste captulo, so formalizados os conceitos relacionados a vises e esquemas de vises dentro do contexto de arquitetura de software, mostrando que a definio da arquitetura de um sistema envolve outras atividades alm da especificao da infraestrutura tcnica. O captulo 4 destina-se a pessoas que j conhecem e trabalham com arquitetura de software e que sentem a dificuldade em garantir que a arquitetura definida para um software realmente adequada como soluo do problema, atendendo a todos os requisitos necessrios. O captulo 5 apresenta uma discusso sobre critrios que podem ser utilizados para escolher o esquema mais adequado para cada caso. Este captulo coloca as vises dentro do processo de desenvolvimento de sistemas, mostrando sua abrangncia. Em seguida, coloca as vises no modelo de qualidade proposto por McCall [McCall94] [Pfleeger98]. A comparao entre as vises segundo sua localizao no processo de software e segundo alguns fatores de qualidade uma maneira de extrair informaes necessrias na definio de uma arquitetura.
IME USP
O captulo 5 est voltado para pessoas que vivem o problema de definir a arquitetura de um software e no sabem como se certificar da cobertura de todos os requisitos necessrios. O captulo 6 o resumo de todo o documento com indicaes e contribuies para novos trabalhos que podem ser feitos a partir desta tese. A audincia que pode se beneficiar da leitura do captulo 6 so os estudiosos da rea de engenharia de software que estejam se dedicando arquitetura.
IME USP
2. Arquitetura de Software
Objetivo do captulo Como a rea de pesquisa em arquitetura de software ainda muito imatura, existem algumas divergncias em relao s definies de arquitetura, principalmente por ser este termo muito abrangente, podendo significar vrias coisas. Por esta razo, o objetivo deste captulo introduzir conceitos em arquitetura de software como embasamento terico para entender as diferentes formas de se observar a arquitetura, atravs dos esquemas de vises, propsito maior deste trabalho. Motivao Com as experincias obtidas no desenvolvimento de software, as instituies e empresas que se dedicam construo de sistemas tm se preocupado com as questes de qualidade, definindo processos internos de desenvolvimento, incluindo tcnicas de modelagem e ferramentas de teste e ressaltando a importncia da documentao como registro das decises e definies adotadas e no como atividade burocrtica cujo sentimento de perda de tempo. O dinamismo dos requisitos traz impactos nas definies e especificaes j estabelecidas. A busca de solues e adaptaes para estes impactos so os dois grandes desafios que as organizaes desenvolvedoras de sistemas encontram. A arquitetura de um sistema, ou seja, sua estrutura e organizao em vrios componentes computacionais que possuem interao entre si, a busca da soluo tcnica para o problema de negcio. A definio desta arquitetura consiste na preocupao em corresponder todos os requisitos necessrios tanto os requisitos funcionais quanto os atributos de qualidade (ou requisitos no funcionais) com os subsistemas e componentes que compem este sistema. Isto implica em considerar nas decises arquiteturais outros fatores alm das informaes tecnolgicas e de infra-estrutura. Neste documento, entende-se componente computacional como sendo uma parte especfica do sistema que encapsula um contexto, seus casos de uso, modelos de anlise e projeto, especificaes de implementao e de teste e forma de interao com outros componentes computacionais. Este conceito difere de componente de software o qual trata da parte implementvel do sistema e que ir se tornar cdigo executvel.
IME USP
Um exemplo tpico da falta de uma boa arquitetura a utilizao da ferramenta IBM WebSphere [www10] como soluo arquitetural para uma aplicao de domnio web simplesmente por possuir servidor de aplicao separado de servidor web. Entretanto, deve-se levar em conta o custo da ferramenta, o porte da aplicao, o conhecimento da equipe de desenvolvimento, o ambiente de operao e a facilidade para integrao com sistemas legados. Organizao do captulo O item 2.1 apresenta a conceituao do termo arquitetura de software embora estes conceitos no levem a uma definio precisa. Porm, identifica a arquitetura como a descrio das muitas estruturas existentes em um sistema. O item 2.2 compreende as atividades necessrias para a definio da arquitetura de um software, identificando e descrevendo o papel que os participantes (stakeholders) desta definio desempenham. O item 2.3 ressalta a importncia em se ter uma arquitetura definida para apoiar a construo do sistema, facilitando a comunicao entre os participantes (stakeholders), antecipando decises de projeto e encaminhando o reuso. A interao entre usurios, arquitetos, analistas e desenvolvedores com o foco na arquitetura mantm o direcionamento das decises arquitetnicas que foram tomadas antecipadamente. O reuso encaminhado em vrios nveis: reutilizao no s de componentes de software, mas tambm de idias, modelos, estilos e padres relacionados arquitetura. O item 2.4 mostra a arquitetura de software como parte integrante da seqncia de atividades necessrias ao desenvolvimento de um sistema. A preocupao neste momento est em mostrar que a arquitetura exerce influncias sobre todas as fases da construo do sistema e principalmente sobre as metas de evoluo deste sistema perante os usurios e o mercado.
2.1. Conceitos de Arquitetura de Software

A formalizao da arquitetura como uma disciplina de engenharia para o desenvolvimento de software comeou com Mary Shaw e David Garlan com a publicao do livro Software Architecture. Perspectives on an Emerging Discipline, em 1996 [Shaw96]. A necessidade de vrias vises e vrios nveis
IME USP
de abstrao na modelagem dos requisitos que sero implementados era percebida pelos projetistas, mas no registradas at ento. Com esta formalizao, surge tambm o papel do arquiteto de software. A definio clssica de arquitetura apresentada por Shaw et al. [Shaw96] diz que arquitetura de software define o que o sistema em termos de componentes computacionais e os relacionamentos entre estes componentes. Semelhante a esta definio, Bass et al. [Bass98] diz que arquitetura de software so as estruturas que incluem componentes, suas propriedades externas e os relacionamentos entre eles, constituindo uma abstrao do sistema. Esta abstrao suprime detalhes de componentes que no afetam a forma como eles so usados ou como eles usam outros componentes, auxiliando o gerenciamento da complexidade. Para Jazayeri et al. [Jazayeri00], a arquitetura de software colocada como uma ferramenta para lidar com a complexidade do software e enfatizam que arquitetura deve satisfazer os requisitos funcionais e no funcionais do sistema, incrementando a definio de que arquitetura de software o conjunto de componentes e seus relacionamentos. Portanto, possvel notar que a arquitetura de software mais do que a descrio dos componentes que a compem e do relacionamento entre eles. A arquitetura a interface entre duas partes distintas: o problema de negcio e a soluo tcnica [Astudillo98].
2.2. O Processo da Arquitetura de Software

O termo arquitetura de software usado para definir duas coisas distintas: o processo e o produto arquitetural. O processo de arquitetura de software compreende as atividades
complementares que so necessrias para a construo do software, entendendo que tais atividades serviro para realizar o projeto (design), implementar e evoluir o sistema. O produto arquitetural representa o resultado final das atividades que acontecem em cada etapa do processo de definio de uma arquitetura de software.
IME USP
O processo de arquitetura de software compreende muitas atividades, dentre as quais possvel destacar [Bass98]:
Elaborao do modelo de negcio para o sistema: o arquiteto deve contribuir com o seu conhecimento para analisar o custo do sistema, o tempo de desenvolvimento, as restries de mercado (pblico-alvo) e interfaces com outros sistemas para que a arquitetura possa alcanar os objetivos do negcio.
Entendimento dos requisitos: o arquiteto deve contribuir com as tcnicas de levantamento de requisitos a fim de obter o modelo do domnio.
Criao ou seleo de uma arquitetura, considerando:

- Identificao dos componentes e suas interaes; - Identificao das dependncias de construo; - Escolha de tecnologias que suportem a implementao.
Representao da arquitetura e divulgao: os participantes envolvidos precisam entender a arquitetura. Os desenvolvedores e testadores precisam entendo o trabalho que lhes foi atribudo e o gestor deve entender as implicaes do planejamento estratgico sugerido pelo arquiteto.
Implementao na arquitetura.
do
sistema
baseado
na
aquitetura:
os
desenvolvedores devem se restringir s estruturas e protocolos definidos
Anlise
ou
avaliao
da
arquitetura:
os
arquitetos
devem
supervisionar e verificar a adequao da arquitetura, registrando impactos, riscos e dificuldades. Estas informaes contribuem para a evoluo da arquitetura em verses posteriores do sistema. A partir destas atividades, pode-se observar que produtos tais como modelo do negcio, modelo do domnio de aplicao, modelo dos componentes computacionais e relacionamentos entre eles e a infra-estrutura tecnolgica so considerados modelos de arquitetura. Estes produtos devem refletir e justificas as decises arquiteturais.
IME USP
Para cada uma das atividades que o processo da arquitetura de software prope, h papis bem definidos que so associados s pessoas que participam deste processo. Os participantes (tambm referenciados como stakeholders) identificados so [Bennett96]:
Analista de requisitos: identificador de requisitos funcionais e no funcionais do sistema;
Arquiteto: criador da arquitetura do sistema (partio, preveno de mudanas e evolues, divulgao), identificador de outros requisitos no funcionais que a arquitetura deve atender e acompanhante do processo de desenvolvimento da arquitetura proposta; e
Projetista (designer) e/ou Desenvolvedor: implementador dos componentes propostos no particionamento de acordo com a plataforma tecnolgica escolhida.
Apesar de existirem vrios participantes com papis distintos na definio da arquitetura, os modelos arquiteturais devem ser finalizados pelo arquiteto lder ou por uma equipe pequena de arquitetos com um deles exercendo a liderana. A importncia disto se deve ao fato da arquitetura ser apoio e guia para a construo do sistema. Isto contribui para a evoluo da disciplina de arquitetura de software, mostrando que arquitetura mais do que o resultado de requisitos tcnicos que implicam no desenho de infraestrutura do sistema. Ela compreende outros tipos de estrutura. Isto significa que h mais que um tipo de componente, como mdulos implementveis e processo; mais que um tipo de interao entre os componentes, como subdiviso e sincronia; e mais que um contexto, como ambiente de desenvolvimento e ambiente de operao [Bass98].
2.3. A Importncia da Arquitetura

2.3.1. Arquitetura e a Comunicao entre os Participantes
Cada participante da construo do sistema est preocupado com caractersticas especficas que so afetadas pela arquitetura. Portanto,
IME USP
sua definio deve ser bem representada e documentada, usando uma notao a qual todos os participantes possam entender com facilidade. Isto no significa que o usurio final tenha que conhecer a notao na qual a arquitetura foi representada. Isto significa que a arquitetura do software representa uma abstrao comum em alto nvel de um sistema a qual a maioria dos participantes podem usar como base para criar um entendimento mtuo, formar consenso e comunicar-se uns com os outros [Bass98]. Um exemplo comum que ilustra a falta de divulgao da arquitetura e de comunicao entre os participantes o desenvolvedor que est preocupado em implementar o componente de software do ponto de vista funcional, mas esquece-se do padro de interface que permitir a integrao com outros componentes do sistema. A representao da arquitetura guia tais atividades e o ponto de referncia para o desenvolvedor em suas decises.
2.3.2. Arquitetura e a Antecipao de Decises de Projeto

As restries e regras tanto do negcio quanto aquelas que influenciam os aspectos tcnicos devem ser atendidas pela arquitetura pois ela constitui-se de um modelo simples e inteligente de como o sistema deve ser estruturado e como seus componentes trabalham juntos. A arquitetura constitui tambm um ponto de referncia comum para as demais atividades que so executadas posteriormente a sua definio. Isto significa que a arquitetura a manifestao antecipada das decises de projeto, preocupando-se com tempo de desenvolvimento, custo e manuteno, definio das restries de implementao e definio da estrutura organizacional, enfatizando os atributos de qualidade que o sistema requer e medindo atravs de avaliaes a empregabilidade das qualidades necessrias [Bass98]. Aps extensas anlises, avaliaes e revises da arquitetura, sua representao torna-se robusta o suficiente para guiar o projeto de implementao, os testes e a implantao do sistema. Esta representao
10
IME USP
precisa estar congelada, evitando que as mudanas e decises que podem ocorrer no meio das atividades de implementao coloquem em risco a construo do sistema.
2.3.3. Arquitetura e o Reuso

Uma vez que a arquitetura pode ser definida como um conjunto de componentes computacionais (ou subsistemas) e o relacionamento entre eles, o reuso considerado uma caracterstica muito forte no que diz respeito a tempo e custo de desenvolvimento do sistema. Se a arquitetura estiver bem organizada e estruturada, cada componente computacional ou parte dele pode ser construdo com vistas para o reuso. A seguir, ns introduzimos a definio de reuso, considerando vrios nveis de abstrao: 1. Reuso de idias arquitetnicas: consiste em uma das atividades de um bom arquiteto de software que se preocupa com a melhoria do seu trabalho e busca no registro de suas experincias as informaes pertinentes para discernir sobre o que se adere bem e o que no se adere bem como soluo tcnica e de negcios ao problema em questo. Est relacionado com a gesto do conhecimento. 2. Reuso de estilos e padres de arquitetura: consiste na utilizao de estilos e padres de arquitetura consagrados na literatura, adequando por semelhana o negcio representao tcnica disponvel. Os estilos e os padres fazem parte do kit do arquiteto como uma primeira referncia para a escolha da arquitetura. 3. Reuso de componentes de software: consiste no reuso de partes codificadas do sistema. Estas partes precisam encapsular funcionalidades e ter interfaces bem definidas de modo que possam ser facilmente aplicadas e substitudas. As partes podem ser desenvolvidas ou adquiridas.
11
IME USP
O reuso uma caracterstica de qualidade agregada definio da arquitetura. Portanto, ele no deve ser obtido por acaso. Uma das motivaes para a reutilizao o fato dos desenvolvedores darem pouca importncia similaridade funcional. Por presso de tempo de desenvolvimento, constroem sistemas pouco modularizados ou com mdulos muito acoplados, dificultando a manuteno [Hofmeister00]. medida que avana o desenvolvimento do sistema, novas partes vo sendo implementadas e consequentemente, a manuteno vai se tornando cada vez mais complexa. Aproveitar-se de estruturas ou componentes j prontos garante mais robustez para o sistema alm de aumentar o grau de abstrao, escondendo detalhes do problema que podem ser substitudos por uma soluo pronta. Um dos objetivos da arquitetura promover a reutilizao. Qualquer que seja o nvel do reuso, necessrio que o sistema ou a aplicao possa sofrer alteraes de forma localizada, sem afetar nenhuma outra parte, e que outras funcionalidades possam ser adicionadas sem impactos nas aplicaes j existentes, com fcil interao. A vida til do sistema que possui uma boa arquitetura aumentada em funo da facilidade na incorporao de mudanas [Jacobson97]. O emprego de reuso na arquitetura sugere uma implementao iterativa, com o mnimo necessrio para que uma primeira verso esteja pronta no menor tempo possvel. Assim, possvel avaliar a adequao e robustez da arquitetura em relao ao sistema, sem buscar de imediato a completude e perfeio desejados conforme os requisitos.
2.4. Arquitetura de Software no Processo de Desenvolvimento de Sistemas

2.4.1. Localizao da Arquitetura Desenvolvimento de Sistemas no Processo de
O processo clssico de desenvolvimento de sistemas chamado waterfall (ou cascata) [Pressman01] que encontrado na disciplina de Engenharia
12
IME USP
de Software possui uma seqncia de fases bem definidas que guiam o desenvolvimento de um sistema, conforme mostra a figura 2.1. Para que uma fase seja iniciada, necessrio que a fase anterior seja totalmente concluda. Mesmo com a execuo rigorosa das fases de engenharia de requisitos e de anlise, a experincia na construo de sistemas mostra que ainda existe uma lacuna de informaes a serem especificadas para prosseguir com a fase de projeto. Isto significa que especificar e modelar o que o sistema deve fazer no suficiente para saber como o sistema deve ser estruturado e organizado para satisfazer os requisitos funcionais e os atributos de qualidade.
13
IME USP
Engenharia de Requisitos Anlise
Projeto
Codificao
Teste
Operao
Figura 2.1 Processo de Desenvolvimento de Sistemas Modelo Cascata O aprendizado obtido com este trabalho de dissertao indica que a arquitetura de software prope vrias atividades que tentam suprir esta distncia entre as fases de anlise e projeto, dentre elas a elaborao de um modelo de domnio com o objetivo de ressaltar o escopo do sistema, a identificao das dependncias de construo e o mapeamento dos requisitos no funcionais que o sistema deve atender e que no foram totalmente especificados na fase de engenharia dos requisitos. A figura 2.2 mostra o ponto onde as atividades da arquitetura so mais visveis dentro do processo de desenvolvimento de sistemas. A diferena entre as fases de anlise e de projeto e as atividades de arquitetura s so evidentes quando se trata de sistemas grandes e complexos. Neste caso, o entendimento claro, o escopo e as possibilidades de evoluo so mais difceis de identificar dado o tamanho da incerteza que advm da falta de conhecimento do negcio. Para sistema pequenos, a transio entre as fases de engenharia de requisitos, anlise e projeto tranquila pois os modelos gerados nestas fases so suficientes para representar os requisitos necessrios, satisfazendo a construo do sistema.
14
IME USP
Engenharia de Requisitos
Arquitetura
Projeto
Anlise
Figura 2.2 A Arquitetura no Processo de Desenvolvimento de Sistemas Segundo Jazayeri et al. [Jazayeri00], muitos engenheiros acreditam que a arquitetura determinada pelos requisitos e por isso esperam que a fase de engenharia dos requisitos esteja finalizada para ento iniciar a definio da arquitetura. Porm, apenas uma frao dos requisitos especficos do sistema tm influncia na arquitetura. A identificao dos requisitos que so significantes para a arquitetura pode ser respondida atravs de um framework1 conceitual desenvolvido especialmente para um domnio especfico, uma vez que esta resposta muito dependente do domnio. Avanar para a fase de projeto ou mesmo iniciar a implementao do sistema no quer dizer que a definio da arquitetura esteja finalizada. Isto significa que o detalhamento obtido at ento j suficiente para prosseguir com o projeto de uma parte do sistema.
2.4.2. Influncias da Arquitetura Desenvolvimento de Sistemas
no
Processo
de
Para o arquiteto, a fase de engenharia de requisitos subsdio para a definio da arquitetura uma vez que traz o processo de negcio modelado, o planejamento estratgico das verses e os requisitos de cada uma delas (figura 2.3).
Alguns autores preferem utilizar o termo arcabouo como traduo para o portugus do termo framework. Neste documento, utilizaremos o termo original, em ingls.
15
IME USP
A arquitetura deve ser construda objetivando o sistema todo, mas com os elementos mnimos necessrios para implementar a primeira verso. Se a arquitetura tem o foco voltado apenas para as funcionalidades priorizadas para a primeira verso, a incorporao de mudanas ou novas funcionalidades para a prxima verso pode exigir uma alterao to grande que a arquitetura tenha que ser refeita. Isto implica em tempo e custo adicionais. Este cenrio bastante comum em funo da presso do mercado (timeto-market) pelo lanamento da verso. Os elementos mnimos para a primeira verso devem contemplar a propriedade de flexibilidade para incorporar as novidades que surgiro com a prxima verso. A cada verso, a arquitetura incrementada, mas sem ferir as verses anteriores de acordo com o processo de negcio previamente estabelecido. Relegar a flexibilidade pode parecer satisfatrio por representar economia de esforo e recursos, mas esta viso pontual significa apenas o adiamento de problemas futuros.
Figura 2.3 Contribuies para Definio da Arquitetura A fase de anlise fornece os objetos de negcio, sua descrio funcional, seus indicadores de desempenho, as restries e a representao comportamental do sistema, que so subsdios para o escopo da arquitetura, como mostra a figura 2.3.
16
IME USP
Problemas complexos precisam ser entendidos como um todo e por isso so particionados em subsistemas que podem ser mais facilmente gerenciados e detalhados [Pressman01]. A composio do todo feita estabelecendo-se interfaces entre os pedaos que podem tambm ser categorizados conforme sua atuao no modelo arquitetural. Alm disso, o estudo e escolha de alternativas tecnolgicas que podem ser validados atravs de prottipos do robustez s solues de projeto e consequentemente de implementao (figura 2.4). Prottipos devem ser instrumentos de arquitetura que antecipam decises de projeto. Os registros de validao do sistema atravs da execuo dos testes so informaes valiosas para garantir no s a qualidade do sistema, mas tambm da arquitetura. Os erros e falhas apontados no sistema indicam situaes de melhoria que podem ser implementadas nas prximas verses (figura 2.4). Na verdade, o esforo de avaliao e verificao da conformidade dos requisitos para com a arquitetura deve ser realizado o tempo todo, ou seja, a cada fase que se avana, o registro dos insucessos deve servir de subsdios para a melhoria ou evoluo da arquitetura atual. Isto mostra que a definio e manuteno da arquitetura um processo incremental e iterativo.
17
IME USP
Figura 2.4 Influncia da Arquitetura nas Demais Fases do Desenvolvimento de Sistemas
2.5. Concluso do Captulo

Apesar da falta de formalismo e das divergncias conceituais, a arquitetura de software definida como sendo o conjunto de componentes computacionais e as interaes entre estes componentes, compreendendo os padres que guiam o desenvolvimento do sistema e as restries relacionadas ao negcio. Mas, ao se definir a arquitetura para um determinado sistema, deve-se considerar a importncia em:
Buscar a reutilizao em todos os nveis de abstrao, ou seja, de idias e experincias obtidas anteriormente, de estilos e padres arquiteturais j difundidos e, por ltimo, de componentes de software;
Antecipar decises de projeto, aliviando as incertezas e riscos no momento da implementao;
Divulgar suas representaes e modelos para que sejam seguidos pelos participantes da equipe.
A evoluo da rea de engenharia de software e a busca de sistemas de software com graus de qualidade cada vez mais altos tem introduzido algumas atividades no processo de desenvolvimento de sistemas relacionadas arquitetura de
18
IME USP
software. Tais atividades caracterizam o processo de arquitetura e serviro como base e direcionamento na implementao do sistema. Desta forma, surge o papel de mais uma figura importante neste processo que o arquiteto de software, com a responsabilidade de traduzir as necessidades do usurio em um modelo arquitetural que ser seguido durante a construo do sistema. O prximo captulo dar continuidade conceituao em arquitetura de software, apresentando outras terminologias que ajudam a antecipar decises de projeto e a definir a arquitetura para um ou vrios sistemas.
19
IME USP
3. Tcnicas em Arquitetura de Software

Objetivo do captulo O objetivo deste captulo apresentar outros conceitos relacionados arquitetura de software que, devido sua importncia e contribuio, so utilizados como tcnicas que auxiliam a definio de arquitetura. Tais conceitos trazem as diferenas entre estilo de arquitetura, arquitetura de referncia, modelo de referncia e arquitetura de linha de produto, esclarecendo que a construo de um sistema baseado em uma arquitetura especfica diferente da construo de vrios sistemas que colaboram para formar uma famlia de produtos. Neste caso, a arquitetura deve ser mais abrangente para todos os sistemas da famlia. Entretanto, qualquer que seja a tcnica utilizada e forma na qual a arquitetura ser definida, existem linguagens de descrio de arquiteturas que podem ser utilizadas para expressar e representar as estruturas e comportamentos arquiteturais. O conceito relacionado a estas linguagens o outro objetivo deste captulo. Motivao A arquitetura definida para um sistema pode ter sucesso assim como pode no ter. A utilizao das experincias anteriores de arquitetos e a semelhana existente entre arquiteturas trazem benefcios substanciais no que diz respeito reutilizao e adoo de estratgias previamente validadas [Bass98]. Tais estratgias que do certo se tornam princpios e padres que somente podem ser formalizados devido maturidade obtida atravs da prtica. Assim sendo, a definio da arquitetura de um sistema no precisa e nem deve partir do zero. Uma vez que esta definio est baseada na escolha de alternativas mais adequadas ao domnio da aplicao, conhecendo conceitualmente as tcnicas existentes, os arquitetos no ficam presos a tecnologias e ferramentas de mercado, o que fatalmente pode comprometer a soluo para o sistema. O incentivo utilizao de frameworks, estilos, padres e linguagens de descrio de componentes previamente definidos caracterizam uma forma de se chegar a uma arquitetura que facilita o entendimento e comunicao entre os participantes do
20
IME USP
desenvolvimento. Alm disso, j ter um ponto de partida imprescindvel para agilizar a definio da arquitetura e, ao mesmo tempo, contribuir com maior robustez e qualidade. Este captulo discute tcnicas tais como modelos de referncia, arquiteturas de referncia e estilos arquiteturais, as quais definem um vocabulrio de estruturas, componentes e conectores juntamente com um conjunto de regras e restries que podem ser adaptados para se definir a arquitetura de um dado sistema. A utilidade destas tcnicas vista medida que elas estabelecem os primeiros passos no processo de definio da arquitetura, consistindo na escolha estrutural que se adequa ao domnio no qual a aplicao est inserida. Organizao do captulo O item 3.1 apresenta as diferenas conceituais entre estilo de arquitetura, modelo de referncia, arquitetura de referncia e arquitetura de um sistema simples e arquitetura de uma famlia de sistemas. O item 3.2 apresenta alguns estilos de arquitetura segundo a viso de Buschmann et al. [Buschmann96], descrevendo as suas caractersticas estruturais. A contribuio com as vantagens e desvantagens de cada estilo complementam o checklist de escolha do arquiteto. O item 3.3 fala sobre arquitetura de linha de produtos, explicitando a diferena entre definir a arquitetura para um sistema especfico e definir a arquitetura para uma famlia de sistemas com semelhanas entre si. O item 3.4 discute os meios de descrever arquitetura, apresentando a definio de linguagem de descrio de arquitetura. Este item apresenta tambm os meios de avaliar a adequao da arquitetura como soluo para construir o sistema.
21
IME USP
3.1. Arquitetura para um Sistema e Arquiteturas de Referncia

Os modelos de referncia, os estilos de arquitetura e as arquiteturas de referncia so passos teis na definio da arquitetura de um sistema, indicando a priori algumas decises importantes. Mas nenhum deles arquitetura de software [Bass98]. O que eles so afinal? O que difere um do outro? Nos pargrafos a seguir, so descritos os conceitos relacionados a estes termos.
3.1.1. Modelo de Referncia

Um modelo de referncia consiste na decomposio padronizada do problema em partes conhecidas que cooperam entre si em prol de uma soluo. Geralmente, estes problemas so de domnio bastante amadurecido e trazem a experincia de analistas de negcio em conjunto com desenvolvedores [Bass98]. O modelo de referncia de um determinado domnio surge durante o processo de amadurecimento da soluo em funo da necessidade de representaes mais abstratas que caracterizam o domnio.
3.1.2. Estilo de Arquitetura

Os estilos de arquitetura expressam esquemas de organizao estrutural de sistemas, fornecendo um conjunto de componentes do sistema, suas responsabilidades e a forma de interao entre eles, estabelecendo um padro de utilizao [Buschmann96]. Cada estilo de arquitetura lida com diferentes tipos de atributos de qualidade. Para obter a definio de uma arquitetura a partir dos estilos existentes, basta saber quais os atributos mais relevantes para a soluo e confront-los com os atributos que o estilo atende.
22
IME USP
3.1.3. Arquitetura de Referncia

Uma arquitetura de referncia consiste em componentes de software e os relacionamentos entre eles que implementam funcionalidades relativas s partes definidas no modelo de referncia. Cada uma destas partes pode ser implementada em apenas um ou vrios componentes de software, ou seja, o mapeamento das funcionalidades do modelo de referncia em componentes da arquitetura de referncia nem sempre um para um [Bass98]. As arquiteturas de referncia so aplicveis a um domnio particular.
3.1.4. Diferenas entre os Conceitos

A maturidade de domnios tais como compiladores, sistemas gerenciadores de base de dados e sistemas operacionais vista atravs da documentao bem padronizada de suas arquiteturas. Assim sendo, o trabalho dos arquitetos simplificado, pois eles no precisam investir na definio da arquitetura e sim na projeo das propriedades arquiteturais das arquiteturas de referncia que mais se assemelham a sua necessidade. Na maioria das vezes, so adotadas solues encontradas em livros e manuais que documentam tais arquiteturas.
Modelo de referncia Arquitetura do sistema
Arquitetura de referncia Estilo de arquitetura
Arquitetura de software
Figura 3.1 Relacionamento entre modelo de referncia, estilo de arquitetura e arquitetura de referncia implementando uma arquitetura de software [Bass98].
23
IME USP
Os modelos de referncia agregam soluo aos problemas do ponto de vista de negcio e que arquiteturas de referncia apresentam a soluo do ponto de vista tcnico, mas baseando-se na soluo de negcio, ou seja, no modelo de referncia determinado para o domnio. Um estilo de arquitetura tambm usado juntamente com o modelo de referncia para a definio da arquitetura de referncia que ir apoiar a definio da arquitetura de software, como mostra a figura 3.1. Concluindo a definio, pode-se dizer que modelos de referncia, estilos de arquitetura e arquiteturas de referncia no so arquiteturas de software. So passos teis voltados para a definio da arquitetura de um software. Cada qual constitui-se de um conjunto de decises antecipadas de projeto e direciona o fundamento bsico para os prximos passos [Bass98]. Tais tcnicas podem ser usadas para definir a arquitetura para a construo de um sistema simples bem como a arquitetura para a construo de uma famlia de sistemas. Em arquiteturas de famlia de sistemas, cada sistema da famlia possui caractersticas particulares que diferenciam suas arquiteturas especficas, mas as caractersticas genricas so compartilhadas pela arquitetura definida para a famlia. As arquiteturas especficas de cada sistema da famlia no so definidas isoladamente. Elas so derivaes da arquitetura definida para a famlia toda. Esta definio ser melhor detalhada no item 3.3.
24
IME USP
A rquitetura de S oftware: V is iB rok er
E s tilo de arquitetura: B rok er
A rquitetura de Refernc ia: CORB A
Mod elo de refer nci a: Si s te m as d e Ob je to s D is trib ud os
Figura 3.2 Utilizao de Estilo de Arquitetura, Modelo de Referncia e Arquitetura de Referncia na Definio da Arquitetura do Software de VisiBroker. A figura 3.2 apresenta um exemplo da utilizao das definies vistas acima. Neste exemplo, a arquitetura do produto VisiBroker do fabricante Borland, agora chamada Inprise, est baseada na arquitetura de referncia CORBA. Esta, por sua vez, uma arquitetura constituda pelo estilo de arquitetura Broker (ver tabela 3.2 do item 3.2.2 deste captulo) e pelo modelo de referncia de sistemas de objetos distribudos [Orfali98] [www5] [www6].
3.2. Estilos de Arquitetura

Conforme descrito no item 3.1.2, um estilo de arquitetura a descrio de tipos de componentes, dos padres que guiam a interao entre eles e de suas restries. A escolha de um estilo deve ser guiada pelas propriedades gerais que a aplicao requer e mais ainda, pelos requisitos no funcionais como portabilidade e confiabilidade. Alm disso, os estilos podem ser combinados entre si para suportar os requisitos necessrios e apoiar a definio de uma arquitetura mais adequada para o problema. necessrio observar que a arquitetura no definida apenas pela adoo de um ou vrios estilos. Eles so apenas um primeiro passo para especificar a estrutura fundamental de um sistema.
25
IME USP
O particionamento do sistema em componentes de software conforme definio de arquitetura de software que feito pela maioria dos desenvolvedores est baseado na intuio, sem registro das decises de projeto que so tomadas para solucionar o problema.
3.2.1. Organizao dos Estilos de Arquitetura

Os estilos podem ser agrupados em categorias, de acordo com as similaridades entre eles, conforme descrito abaixo [Buschmann96]:
From mud to structure: oferece decomposio controlada das tarefas em subtarefas cooperativas. Antes de projetar um sistema, coleta-se os requisitos, transformando-os em especificaes. considerado que os requisitos esto bem definidos e estveis. Inclui os padres Camada (Layers), Canos e Filtros (Pipes and Filters) e Blackboard que esto descritos na tabela 3.1.
Sistemas distribudos: fornece uma completa estrutura para aplicaes distribudas. Inclui o padro Broker que est descrito na tabela 3.2.
Sistemas interativos: oferece suporte para a estruturao de sistemas que caracterizam-se como interao homem-mquina. Inclui os padres Model-View-Controller e Presentation-Abstraction-Control que esto descritos na tabela 3.3.
Sistemas adaptveis: oferece suporte para a extenso e adaptao de aplicaes a tecnologias e mudanas de requisitos funcionais. Inclui os padres Reflexo (Reflection) e Micro-ncleo (Microkernel) que esto descritos na tabela 3.4.
26
IME USP
3.2.2. Alguns Estilos de Arquitetura

As tabelas a seguir apresentam alguns estilos de arquitetura e suas principais caractersticas [Buschmann96]. Tais estilos esto organizados conforme as categorias vistas no item 3.2.1. Tabela 3.1 Estilos da categoria From mud to structure
Estilo Camada (Layer) Categoria: From mud to structure
Descrio Auxilia na aplicao de estruturas que podem ser decompostas em grupos de
subtarefas pertencentes a um nvel particular de abstrao.

Estrutura - Cada camada pode ser composta por vrios componentes que interagem entre si ou com os componentes da camada seguinte. - As requisies so movidas do nvel mais alto para o nvel mais baixo. As respostas para as requisies ou notificaes de eventos trafegam no sentido oposto. - Cada camada pode ser descrita utilizando a representao CRC2. Estilo Vantagem Desvantagem - Reuso de camadas; - Mudana de comportamento em cascata (que ocorre - Suporte a quando uma mudana afeta padronizao; mais de uma camada); - Dependncias - Baixa eficincia; mantidas localmente. - Impacto no desempenho; - Dificuldade em estabelecer a granularidade correta das camadas.
Pipes e Filtros (Pipes and Filters)
Categoria: From mud to structure
Descrio Fornece uma estrutura para sistemas que processam uma cadeia de dados.
Cada passo encapsulado em um componente chamado filtro. Os dados passam atravs dos pipes que ficam entre filtros adjacentes.
Estrutura - Os componentes filtro so a unidade de processamento que trata, refina e transforma os dados de entrada. - Os pipes so a conexo entre os filtros. - Os dados de entrada so as entradas do sistema e devem ser do mesmo tipo. - Os dados de sada so o resultado do pipeline. - Cada filtro, pipe, dado de entrada e dado de sada pode ser descrito ili d
2
Vantagem - No so necessrios arquivos intermedirios; - Flexibilidade para troca de filtros; - Flexibilidade para recombinao de filtros; - Reuso de filtros; - Rpida prototipao de pipelines; - Eficincia em processamento
Desvantagem - Compartilhamento de informaes caro e inflexvel; - Ocorre overhead na transformao dos dados - Tratamento de erros difcil de ser obtido.
A sigla CRC significa Class-Responsability-Collaborator e refere-se a uma notao simples e informal para descrever objetos e componentes de uma aplicao atravs de trs campos: (1) nome do componente, (2) sua responsabilidade, (3) nome dos outros componentes com os quais h alguma colaborao [Buschmann96].
27
IME USP
utilizando a representao CRC. Estilo Blackboard
paralelo. Categoria: From mud to structure
Descrio til para problemas que no possuem estratgias de solues
determinsticas conhecidas e so baseados em solues aproximadas ou parciais. So caracterizados por problemas que, quando decompostos em subproblemas, abrangem muitos campos de conhecimento. A soluo para problemas parciais necessita de diferentes paradigmas e representaes.
Estrutura - O sistema divido em: um componente blackboard, uma base de conhecimentos e um componente de controle. - O blackboard uma central de armazenamento dos dados o vocabulrio. - O componente de controle monitora as mudanas no blackboard e decide qual ao deve ser tomada. - A base de conhecimentos consiste em subsistemas separados e independentes, cada qual resolvendo aspectos especficos do problema. Vantagem - Ajuda a resolver problemas de experimentao; - Suporte a mudanas e manuteno; - Reuso de conhecimentos; - Suporte a tolerncia a falhas e robustez. Desvantagem - Dificuldades para testar por no ter algoritmos determinsticos; - Nenhuma boa soluo garantida; - Dificuldade em estabelecer uma boa estratgia de controle; - Baixa eficincia e alto esforo de desenvolvimento; - No suporta paralelismo.
28
IME USP
Tabela 3.2 Estilo da categoria Sistemas Distribudos

Estilo Broker Categoria: Sistemas Distribudos
Descrio utilizado em sistemas cuja estrutura distribuda com desacoplamento de
componentes que interagem atravs de invocao remota de servios. O componente broker responsvel por coordenar a comunicao.
Estrutura - O servidor possui objetos que expem sua funcionalidade atravs de interfaces com operaes e atributos. - Os clientes so aplicaes que acessam os servios de pelo menos um servidor. - O broker mensageiro responsvel pela transmisso de requisies do cliente para o servidor e transmisso de respostas e excees do servidor para o cliente. - Os bridges so componentes que escondem detalhes de implementao quando dois brokers interoperam. - O proxy do lado do cliente a camada entre cliente e broker que esconde detalhes de implementao do cliente tais como a transparncia na qual um objeto remoto aparece para o cliente como local, mecanismos de comunicao usados para transferncia entre clientes e broker, criao e remoo de blocos de memria e marshaling de parmetros e resultados. - O proxy do lado do servidor anlogo ao proxy do lado do cliente e responsvel por receber requisies, desempacotar mensagens, unmarshaling parmetros e chamar servios apropriados. Vantagem Desvantagem - Transparncia para o - Eficincia restrita uma vez que cliente na localizao os servidores so localizados do servidor; dinamicamente; - Facilidade de troca e - Baixa tolerncia a falhas; evoluo de - Teste e debug so dificultados componentes uma por envolver muitos vez que suas componentes. interfaces no mudem; - Portabilidade em funo do broker; - Interoperabilidade entre diferentes brokers; - Reuso dos servios j existentes quando da construo de novas aplicaes cliente.
29
IME USP
Tabela 3.3 Estilos da categoria Sistemas Interativos

Estilo Model-View-Controller (MVC) Categoria: Sistemas Interativos
Descrio Divide aplicao interativa em trs componentes: o modelo (model) contm
funcionalidades e dados; vises (views) mostram informaes para o usurio; controladores (controllers) manipulam as entradas. Um mecanismo de propagao de mudanas garante a consistncia entre a interface do usurio e o modelo.
Estrutura O componente model encapsula dados e funcionalidade e independente de representaes especficas de sada ou comportamento de entrada. O componente view mostra as informaes para o usurio, obtendo dados do modelo. Pode haver muitas vises do modelo. Cada viso est associada a um controlador (controller) que recebe entradas geralmente como eventos. O usurio interage com o sistema apenas atravs de controladores. Vantagem Mltiplas vises do mesmo modelo; Vises sincronizadas; Vises e controladores podem ser trocados no modelo; Adaptabilidade de look and fell. Desvantagem Aumento da complexidade sem obter muita flexibilidade; Nmero excessivo de mudanas; ntima conexo entre viso e controlador; Acoplamento de vises e controladores ao modelo; Ineficincia de acesso a dados na viso; Dificuldades de uso com ferramentas modernas de interface com usurio.
Estilo
Presentation-Abstraction-Control (PAC)
Categoria: Sistemas Interativos
Descrio Define uma estrutura para sistemas interativos na forma de uma hierarquia de
agentes cooperantes. Cada agente responsvel por um aspecto especfico das funcionalidades da aplicao e consiste nos componentes apresentao (presentation), abstrao (abstraction) e controle (control). Esta subdiviso separa aspectos de interao homem-mquina dos agentes do seu ncleo funcional e sua comunicao com outros agentes.
Estrutura - O agente do topo do nvel hierrquico fornece o ncleo funcional do sistema. Possui partes da interface que no podem ser atribudas a subtarefas particulares. - Demais agentes dependem ou operam neste ncleo. - Agentes do nvel mais baixo representam conceitos semnticos nos quais os usurios do sistema podem agir e suportam todas as operaes que o usurio desenvolver. - Agentes do nvel intermedirio representam combinaes de relacionamentos entre agentes do nvel mais baixo (agente pode manter muitas vises do mesmo dado). Vantagem Desvantagem - Conceitos semnticos - Aumento na complexidade do diferentes so sistema; representados por - O componente controle agentes separados; complexo por ser um mediador - Suporte a mudanas e entre a apresentao e a evoluo; abstrao; - Suporte a multitarefa. - Impacto na eficincia do sistema devido a overhead que pode ocorrer.
30
IME USP
Tabela 3.4 Estilos da categoria Sistemas Adaptveis

Estilo Micro-ncleo (Microkernel) Categoria: Sistemas Adaptveis
Descrio Aplica-se a sistemas que devem se adaptar s mudanas de requisitos. A
plataforma de aplicao depende da capacidade de executar aplicaes escritas para um padro existente. Para tanto, a plataforma deve ser capaz de emular as outras plataformas para as quais a aplicao est sendo desenvolvida.
Estrutura - O microkernel o principal componente e possui servios que facilitam comunicao e manipulao de recursos e servem como base para construir funcionalidades mais complexas. - O servidor interno amplia as funcionalidades do microkernel, encapsulando algumas dependncias bsicas de sistemas de hardware e software. - Um servidor externo expe suas funcionalidades atravs de interfaces da mesma forma que o microkernel faz, recebendo requisies de servios de aplicaes cliente e usando as facilidades de comunicao fornecidas pelo microkernel. - O cliente uma aplicao associada a apenas um servidor externo, acessando sua interface. - Os adaptadores representam a interface entre clientes e seus servidores externos. Facilita a portabilidade. Estilo Reflexo (Reflection) Vantagem - Portabilidade; - Flexibilidade e extensibilidade atravs da implementao de um novo servidor externo; - Separao de regras e mecanismos, aumentando a facilidade de manuteno; - Escalabilidade; - Confiana; - Transparncia. Desvantagem - O desempenho o preo pela flexibilidade e extensibilidade; - Complexidade em projetar e implementar.
Categoria: Sistemas Adaptveis
Descrio Fornece um mecanismo para mudar estrutura e comportamento de sistemas
dinamicamente. A aplicao dividida em duas partes: um meta-nvel que fornece informaes sobre propriedades do sistema e o torna ciente das informaes; um nvel base que inclui lgica da aplicao. Mudanas nas informaes do meta-nvel afetam o comportamento do nvel base.
Estrutura Vantagem Desvantagem - Modificaes no metanvel podem causar danos; - Crescente aumento no nmero de objetos; - Baixa eficincia devido ao relacionamento entre o meta-nvel e o nvel base; - No oferece todas as mudanas necessrias; - No disponvel em todas - O meta-nvel um conjunto de meta- Modificao do objetos, cada qual encapsulando sistema no necessita informaes sobre um aspecto da alteraes no cdigo, estrutura, comportamento ou estado do pois a mudana fica nvel base. no meta-nvel; - O nvel base modela e implementa a - Alterar o sistema lgica da aplicao e representam os fcil; vrios servios que o sistema oferece - Permite muitos tipos bem como o modelo de dados bsico. de mudanas. Alm disso, o nvel base especifica a colaborao e o relacionamento entre
31
IME USP
seus componentes. Usa as informaes e servios fornecidos pelo meta-objeto, obtendo flexibilidade (cdigo independe de aspectos que podem ser mudados ou adaptados). - O protocolo de meta-objetos (MOP) serve como interface para o meta-nvel e torna-o acessvel implementao do sistema. - Clientes do MOP (componentes do nvel base, outras aplicaes ou usurios privilegiados) podem especificar modificaes para metaobjetos ou seus relacionamentos usando o nvel base. Ele mesmo responsvel por desenvolver estas mudanas. Isto explicita controle sobre as prprias modificaes.
as linguagens de programao.
3.3. Arquitetura de Linha de Produtos

Definir a arquitetura de um sistema significa alto investimento de tempo e esforo. Manter a arquitetura de um sistema que sofre constantes atualizaes ou que se diversifica tambm significa alto investimento. A arquitetura de linha de produtos ou arquitetura de famlia de sistemas define os conceitos, estruturas, componentes e restries necessrios para obter uma variao de caractersticas em vrios produtos (ou sistemas) enquanto fornece o mximo de compartilhamento das partes na implementao. A quantidade de diferenas ou de dependncias entre os produtos refletem na complexidade da arquitetura [Jazayeri00]. A identificao prvia de evolues, atualizaes e diversificaes em um sistema ajuda a estabelecer uma estratgia que influencia e ajuda a direcionar a arquitetura. Um sistema pode ser representado por vrios produtos, estabelecendo-se uma linha de produtos com caractersticas e propriedades semelhantes. Desta forma, os produtos desta linha podem compartilhar de uma mesma arquitetura construda especificamente para esta linha em vez de existir vrias arquiteturas, uma para cada produto.
32
IME USP
Construir uma arquitetura para uma linha de produtos significa envolver esforos para maximizar o uso da mesma arquitetura para vrios sistemas semelhantes como pode ser observado na figura 3.3 apresentada a seguir.
Uma Arquitetura Um sistema
Vrias Arquiteturas
Vrios Sistemas
Uma Arquitetura
Vrios Sistemas
Figura 3.3 Comparao de arquitetura para construo de um sistema e para construo de vrios sistemas. Segundo Jazayeri [Jazayeri00], as atividades que envolvem a definio da arquitetura de uma linha de produtos so: 1. Capturar de requisitos que impactam na arquitetura: listar todos os produtos candidatos a participarem da linha, identificar as propriedades genricas que existem entre produtos candidatos, evidenciando as semelhanas, definir o escopo da linha de produtos e a estratgia de produo. 2. Analisar a robustez dos produtos candidatos em conformidade com as evolues futuras: identificar as restries nos produtos candidatos. 3. Projetar as camadas de acordo com nveis de abstrao, localizando a arquitetura genrica da linha e a arquitetura de cada produto candidato; projetar tambm os componentes genricos. 4. Implementar a arquitetura. 5. Testar a conformidade da arquitetura, verificando os riscos que afetam o escopo, as propriedades genricas e a estratgia estabelecida.
33
IME USP
O estabelecimento de uma arquitetura de linha de produtos envolve vrios participantes (stakeholders), com papis bem especficos, a saber [Jazayeri00]:
Profissional de marketing: tem a responsabilidade de analisar o mercado, verificando a necessidade e a conformidade do produto. Na maioria das vezes, o profissional de marketing o criador da linha de produtos e participa da fase inicial de engenharia de requisitos com a viso de manter o foco na estratgia.
Administrador da linha de produtos: tem a responsabilidade de manter a arquitetura da linha e os produtos em conformidade com ela. Participa da fase inicial de engenharia de requisitos.
Arquiteto da linha de produtos: tem a responsabilidade de construir a arquitetura genrica que vai apoiar o desenvolvimento dos produtos que participam da linha. Participa da fase de arquitetura.
Construtor de propriedades genricas: tem a responsabilidade de identificar e listar todas as propriedades genricas que faro parte da linha de produtos a partir das especificaes dos produtos que a arquitetura deve atender. Participa da fase de projeto e implementao dos produtos.
Construtor dos produtos: tem a responsabilidade de desenvolver os produtos, utilizando as propriedades genricas. Participa da fase de projeto e implementao dos produtos.
A tabela 3.5 abaixo apresenta algumas caractersticas peculiares de arquitetura de linha de produtos e resume as vantagens e as desvantagens associadas a tais caractersticas.
34
IME USP
Tabela 3.5 Caractersticas e dificuldades de uma arquitetura de linha de produto

Item Caracterstica Vantagem - A estratgia de negcio Desvantagem - Alto gerenciamento de
Deciso estratgica de negcio
induz a organizao de equipes e planejamentos formais (business plan).
mudanas em funo do mercado.

- Alterao de produtos
sem refletir na arquitetura relega a estratgia de negcio. 2 Time to market

- Agilidade ao disponibilizar - A presso do mercado
novos produtos no mercado em funo do reuso e direcionamento das atividades.

- O foco na evoluo e na
pode prejudicar a manuteno tanto dos produtos quanto da arquitetura que os suporta.
- Pode haver
facilidade em absorver mudanas torna a arquitetura mais flexvel.
incompatibilidade entre produtos que reutilizam o mesmo componente que sofrer manuteno.
- A estrutura
Influncia sobre o modelo organizacional da empresa
- A empresa organiza seu
processo interno e suas atividades em funo da linha de produtos.

- necessria uma equipe
organizacional da empresa pode sofrer mudanas se mudar a linha de produtos.

- Empresas com pouca
dedicada soluo de novidades e evolues para no ferir a arquitetura.

- necessria uma equipe
dedicada ao reuso que gerencie os componentes e dissemine a prtica. 4 Sincronia entre produtos e arquitetura
- A sincronia permite
maturidade sofrero com falta de padro, ferramentas e tcnicas de documentao.
- Novas funcionalidades
agilidade ao disponibilizar novos produtos e ao evoluir os produtos ou arquiteturas existentes.
de um produto podem estar fora do escopo da arquitetura.

- Atributos de qualidade
podem ser conflitantes no mesmo componente (por exemplo: rapidez X tamanho do cdigo). 5 Alto investimento inicial
- O alto investimento - No existem bons
revertido em alto retorno em longo prazo.
modelos que mostrem a relao custoXbenefcio.
35
IME USP
3.4. Descrio e Avaliao de Arquiteturas

Um estilo de arquitetura, uma arquitetura de referncia, a arquitetura particular de um software ou a arquitetura de uma linha de produtos podem ser descritas atravs de uma linguagem de descrio de arquitetura (architecture description language ADL). Tais linguagens fornecem um caminho para especificar os componentes computacionais e suas interconexes [Holfmeister00]. Geralmente, as arquiteturas tm sido representadas por diagramas de caixas e linhas onde a natureza dos componentes, suas propriedades, a semntica das conexes e o comportamento do sistema como um todo so pobremente definidas [Bass98]. Em se tratando de arquitetura de linha de produtos, uma ADL deve fornecer uma maneira de especificar como produtos individuais podem variar atravs da linha de produtos. Para Bass et al. [Bass98], as ADL esto situadas na interseo conceitual entre requisitos, programao e linguagens de modelagem, sendo diferentes destes trs (figura 3.4). As diferenas so as seguintes:
ADL diferem de linguagens para descrever requisitos pois estas descrevem espao de problemas e ADL buscam o espao de soluo.
ADL diferem de linguagens para descrever programao pois estas fazem amarrao das abstraes arquiteturais para pontos de soluo especficos e ADL omitem ou variam tais amarraes.
ADL diferem de linguagens de modelagem pois estas preocupam-se mais com o comportamento do todo do que das partes e as ADL concentram-se na representao de componentes e suas interconexes.
36
IME USP
Linguagem para requisitos
ADL
Linguagem para programao
Linguagem de modelagem
Figura 3.4 Interseo conceitual entre linguagens de requisitos, programao e modelagem e ADL. Os itens que esto listados a seguir representam um conjunto mnimo de requisitos para que uma linguagem possa ser uma ADL [Bass98]:
Comunicao: a ADL deve descrever adequadamente as estruturas estticas e dinmicas da arquitetura, permitindo a comunicao entre os participantes.
Processo: a ADL deve suportar as atividades de criao, refinamento e validao da arquitetura.
Estilo: a ADL deve ser capaz de representar a maioria dos estilos de arquitetura.
Abstrao: a ADL deve ser capaz de representar estruturas do sistema que expressam informao arquitetural, omitindo informaes de implementao ou que no se referem arquitetura.
Continuidade: a ADL deve ser a base para promover a implementao. Verificao: a ADL deve ser capaz de gerar rapidamente um prottipo de implementao para anlise das informaes no nvel arquitetural (capacidade analtica).
Uma vez estabelecido que a arquitetura antecipa importantes decises para o projeto do sistema, ela deve ser avaliada no que diz respeito aos requisitos que ela satisfaz. A capacidade analtica para tal avaliao fornecida pela ADL est concentrada em propriedades como desempenho de execuo, comportamento (usabilidade) e comunicao entre os componentes computacionais.
37
IME USP
Existem outras tcnicas que fazem a anlise para avaliar os demais atributos de qualidade que so menos bvios para o sistema, tais como modificabilidade, portabilidade, reusabilidade, integrabilidade e testabilidade. Dentre as tcnicas existentes, trs esto citadas a seguir [Bass98]:
Tcnica baseada em cenrios: descreve uma situao especfica de interao do usurio com o sistema.
Tcnica baseada em questionrio: lista questes gerais que se aplicam forma na qual a arquitetura foi gerada e documentada. A utilidade do questionrio est relacionada ao domnio de interesse que pode ser caracterizado.
Tcnica baseada em checklist: lista questes mais detalhadas as quais esto relacionadas a um domnio especfico de sistemas. O checklist est mais focado em atributos de qualidade particulares do sistema.
A escolha da ADL que mais se adequa representao de uma arquitetura pode estar baseada no esquema de vises (captulo 4) que ser utilizado na definio da arquitetura. Tambm o esquema de vises pode ser aliado na avaliao da aderncia da arquitetura descrita atravs da ADL como forma de garantir que os requisitos (tanto os funcionais quanto os atributos de qualidade) necessrios esto cobertos pela representao.

Este captulo apresentou uma viso geral das diferenas conceituais relacionadas arquitetura de software, mostrando que sua definio pode estar baseada em arquiteturas de referncia que identificam um domnio especfico de aplicao, trazendo abstraes j estabelecidas em sua representao. Alm disso, os estilos de arquitetura ajudam a estabelecer a definio atravs das composies estruturais que organizam os componentes computacionais e suas interconexes. As tabelas apresentadas no item 3.2.2 resumem alguns dos estilos de arquitetura mais comuns. Vale ressaltar que definir a arquitetura para um sistema e definir arquitetura para uma famlia de sistemas implica em processos distintos, pois este segundo
38
IME USP
tipo envolve esforos para maximizar o uso da mesma arquitetura em vrios sistemas semelhantes. Porm, esta abordagem pode ser mais vantajosa ao considerar que o desenvolvimento de variaes da mesma arquitetura pode ter obter maior sucesso do que o desenvolvimento de produtos variados. As linguagens de descrio de arquitetura (ADL) so especialmente projetadas para representar estruturas e comportamentos arquiteturais, fornecendo subsdios para avaliaes da arquitetura representada. Apesar das ADLs existentes hoje serem pouco difundidas, muitas delas so apoiadas por ferramentas automticas. No captulo seguinte, abordar os conceitos de vises e de esquemas de vises em arquitetura de software, descrevendo alguns esquemas mais comuns.
39
IME USP
4. Vises em Arquitetura de Software

Objetivo do captulo Este captulo tem como objetivo entender o que so as vises, ou seja, as vrias formas de se observar a arquitetura, cada forma atribuda a um papel desempenhado por um participante. As vises so apresentadas conforme sua organizao dentro de esquemas, cada qual seguindo a linha de um autor ou grupo de autores. Motivao A necessidade de executar as atividades de arquitetura realmente surge quando o sistema a ser desenvolvido grande e complexo. Neste tipo de sistema, muitos detalhes e restries devem ser considerados, o que exige vrias camadas de abstrao. A equipe de desenvolvimento envolve muitas pessoas com funes especficas. A preocupao com as questes de reutilizao aumentada em funo do custo e do tempo de desenvolvimento. Cada pessoa envolvida no processo de desenvolvimento fornece um tipo de contribuio importante que se traduz numa viso diferente do sistema. Conseguir capturar e representar cada uma destas contribuies um grande desafio. papel do arquiteto entender estas diferentes vises e, representando-as nos modelos de arquitetura. Uma das funes da arquitetura antecipar a soluo de problemas que s surgem geralmente quando o sistema est sendo implementado ou j est em operao. As vises so a forma de identificar todas as necessidades dos participantes (stakeholders), verificar quais problemas essas necessidades trazem e atribuir-lhes uma soluo. As vises podem ser o ponto de partida para capturar os requisitos necessrios tanto ao sistema quanto a sua arquitetura e garantir um nvel de cobertura no levantamento das informaes. Organizao do captulo O item 4.1 apresenta os conceitos que definem o que so as vises, o que so os esquemas de vises e quais so os tipos de vises em arquitetura de software. O item 4.2 discute os principais esquemas de vises em arquitetura de software que podem ser encontrados na literatura.
40
IME USP
O item 4.3 apresenta alguns outros esquemas de vises que so considerados menos relevantes no contexto deste trabalho. O item 4.4 faz uma comparao entre os esquemas de vises mais importantes apresentados no item 4.2, mostrando as semelhanas e diferenas entre eles do ponto de vista de evoluo conceitual e evoluo temporal (cronolgica).
4.1. Conceitos de Vises

Como j foi abordado nos captulos anteriores, a arquitetura traz muitos benefcios, inclusive a facilidade na comunicao entre os participantes do desenvolvimento do sistema porque permite um entendimento comum do problema. Cada participante tem uma viso do sistema e todos eles, mesmo com vises diferentes, devem ter um mesmo entendimento sobre as representaes que fazem da arquitetura.
4.1.1. O que so Vises

Vises so diferentes formas de observar um mesmo problema com a finalidade de melhor entend-lo para ento, atribuir-lhe a soluo mais adequada. Tais formas esto relacionadas: 1. ao modo como as pessoas que desempenham papis diferentes dentro do processo de desenvolvimento de software vem o problema. 2. ao modo como cada entidade (componente) da arquitetura de software pode ser observada (perspectivas diferentes). Existem vrias formas de se observar o sistema em construo. As pessoas envolvidas no processo de desenvolvimento do software tm vises diferentes que ressaltam as propriedades relevantes do sistema que lhes interessa e omite as propriedades no relevantes. H informaes que so independentes umas das outras e no possvel represent-las em um mesmo diagrama. As vises so a forma de
41
IME USP
detalhar e representar separadamente cada uma destas informaes dissociadas. A arquitetura de um sistema definida com base tambm nos atributos de qualidade que ficam implcitos ao se fazer o levantamento dos requisitos. Ou seja, os atributos de qualidade so aqueles que a arquitetura deve satisfazer independente das tarefas explcitas que sero atendidas pelo sistema, tais como escalabilidade, desempenho e disponibilidade. Na elaborao da arquitetura, todos os requisitos (funcionais e no funcionais) precisam ser considerados e representados de alguma forma, necessitando de mais ateno do que a simples escolha de tecnologia e identificao destes requisitos. Viso a representao de um aspecto do sistema e o objetivo em entend-la est em organizar e classificar tal representao descritiva das partes complexas do problema e relevantes ao desenvolvimento.
4.1.2. O que so Esquemas de Vises

Esquemas de vises so um conjunto de vises cuja finalidade agrupar formas diferentes de observar a mesma coisa de modo a descrever um todo, qualquer que seja o grau de abrangncia dentro do contexto ao qual aplicado. Um esquema pode se referir s idias de determinado autor (ou grupo) ou ento a algum domnio especfico de aplicao.
4.1.3. Tipos de Vises

Nesta seo, introduzimos uma forma de mostrar que h duas razes para a existncia de vises. Tais razes so traduzidas em dois tipos fundamentais de vises, conforme segue: 1. Vises de complemento: descreve aspectos complementares provenientes da observao de algum aspecto. Por exemplo as dimenses esttica, dinmica e funcional de um modelo obtido na
42
IME USP
fase de projeto. Tipicamente, estes aspectos observados so um item de software (diagrama). 2. Vises de compreenso: descreve diferentes compreenses do problema que ocorrem naturalmente no decorrer do processo de desenvolvimento do sistema. Isto , cada viso ressalta os aspectos principais que devem ser analisados nas vrias fases do processo de desenvolvimento. No que se refere a pessoas, possvel observar que as vises de complemento so voltadas para as pessoas que desempenham o mesmo papel dentro do processo de desenvolvimento de software. Por exemplo, os projetistas de uma equipe tm observaes diferentes no modelo de projeto. As vises de compreenso esto baseadas em especialistas com diferentes perfis, cada qual desempenhando atividades relativas a fase do processo de desenvolvimento em que esto inseridos. Por exemplo, o projetista tem preocupaes diferentes das preocupaes do implementador. No que se refere independncia de informaes, as vises de complemento tratam de informaes altamente dependentes entre si, ou seja, so formas diferentes de analisar as mesmas informaes. Por exemplo, na notao OMT [Rumbaugh91], o modelo dinmico representado por trs diagramas: diagrama de eventos, diagrama de fluxo de eventos e diagrama de estados. So trs formas distintas de observar os aspectos dinmicos do sistema, concentrados na fase de anlise do processo de desenvolvimento de software. Ainda referente independncia de informaes, as vises de compreenso tratam de informaes completamente independentes que so representadas em modelos diferentes devido ao alto grau de dissociao. Por exemplo, as informaes tratadas no modelo de projeto tm um enfoque diferente daquelas tratadas no modelo de implementao. No que se refere cobertura dos requisitos, as vises de complemento tm como objetivo aprofundar nos detalhes de representao de cada
43
IME USP
fase do processo de desenvolvimento. As vises de compreenso procuram garantir que todos os requisitos necessrios ao sistema esto representados, cada qual em seu modelo. A grosso modo, como se existissem subvises, onde as vises de complemento tratam das vises que so possveis dentro de cada uma das vises de compreenso.
4.2. Principais Esquemas de Vises em Arquitetura de Software

H propriedades que a arquitetura deve tratar que no so apenas as funcionalidades do sistema. Existem outras propriedades tais como distribuio fsica e comunicao. Observando este fato, o modelo arquitetural deve ser construdo considerando vrios pontos de vista. Cada participante possui uma viso diferente sobre a representao da arquitetura, segundo critrios variados. O objetivo de observar o problema com outros olhos est em organizar e classificar a representao descritiva das partes complexas do problema. No h uma representao simples para a arquitetura: h vrias representaes, com diferentes perspectivas e regras. Representar a arquitetura em vrias vises, utilizando vrios modelos, produz um resultado mais consistente uma vez que h muita informao dissociada para retratar em um nico modelo. As informaes podem ser referentes a fluxo de dados, fluxo de controle, dependncias fsicas, restries do ambiente. Cada esquema tem vises e cada viso tem associada uma ou mais representaes, normalmente diagramas. Os principais esquemas de vises descritos neste captulo so os mais comuns e mais utilizados pela indstria de software, representando um conjunto significativo de conceitos para o estudo realizado. So eles:

As vises da OMT [Rumbaugh91]; As vises de Booch [Booch91]; As vises de 4+1 (RUP) [Kruchten00];
44
IME USP
As vises do RM-ODP [Beitz97]; As vises de Zachman [Zachman97].
4.2.1. OMT
A OMT [Rumbaugh91] descreve bem alguns modelos do sistema sob a perspectiva do que o sistema deve fazer, sem a preocupao de como se deve fazer. Todos os modelos esto bem concentrados na fase de anlise da engenharia de software e baseiam-se no levantamento prvio dos requisitos. A figura 4.1 apresenta as trs vises da metodologia OMT:

Viso esttica; Viso dinmica; Viso funcional.
O esquema apresentado pela OMT possui como principal objetivo descrever o sistema, considerando o escopo e os requisitos funcionais previamente definidos.
45
IME USP
Figura 4.1 Dimenses da OMT
4.2.1.1. Viso Esttica Esta viso representada com o diagrama denominado modelo de objetos para retratar a estrutura esttica do sistema ou do mundo real e o organiza em partes que podem ser manipuladas, ou seja, este modelo composto das classes de objetos e os relacionamentos existentes entre estas classes. O modelo fruto da comunicao entre usurios conhecedores do domnio do problema, analistas e projetistas de software. Esta viso representada pelo diagrama de classes, podendo considerar a notao OMT ou UML. 4.2.1.2. Viso Dinmica Esta viso mostra o comportamento do sistema em relao ao tempo e aos objetos que o constituem e que foram definidos na viso anterior. A importncia esta viso est em tratar a seqncia de interaes entre os objetos em eventos distintos. Esta viso usa trs diagramas: diagrama de eventos (cenrios), diagrama de fluxo de eventos e diagrama de estados, considerando a notao OMT. Considerando a notao UML, os diagramas correspondentes so: diagrama de sequncias, diagrama de colaborao e diagrama de transio de estados. 4.2.1.3. Viso Funcional Esta viso mostra como as informaes so processadas, sem preocupaes com a seqncia, as decises ou estrutura do objeto, mas considerando a dependncia entre as informaes e as funes que as
46
IME USP
relacionam. As funes so expressas em linguagem natural, equaes matemticas ou pseudocdigo. O diagrama que representa esta viso o diagrama de fluxo de dados, na notao OMT. Os processos nos diagramas de fluxo de dados correspondem s atividades ou aes nos diagramas de estados da viso dinmica. Os fluxos correspondem a objetos ou valores de atributos do diagrama de objetos da viso esttica. 4.2.1.4. Concluso do Esquema O esquema OMT ressalta , em separado, os detalhes esttico, dinmico e funcional dos objetos identificados no sistema. Ou seja, cada objeto possui sua estrutura e sua descrio definidas do ponto de vista esttico, dinmico e funcional. Os aspectos estticos demonstram a organizao estrutural do sistema, guiando a identificao de componentes de software que sero implementados. A evoluo dos aspectos dinmicos validam e complementam a estrutura esttica e a evoluo dos aspectos funcionais validam e complementam tanto a estrutura esttica quanto a estrutura dinmica, conforme pode ser visto na figura 4.2.
Figura 4.2 Relao entre as Representaes do Esquema de Vises OMT
47
IME USP
Os aspectos que so representados pela viso dinmica tambm fornecem subsdios para a preparao dos casos de testes que serviro para validar os requisitos funcionais (aspectos relacionados ao negcio) quando o sistema estiver pronto. A tabela 4.1 mostra os principais requisitos de cada viso do esquema OMT e tambm o papel desempenhado pelo participante principal na viso considerada. Tabela 4.1 Resumo das Vises do Esquema OMT
Requisito Principal Viso Esttica Participante Principal
Estrutura e organizao dos elementos que representam o mundo real Comportamento dos objetos Interao entre os objetos no tempo
Usurio final Conhecedores do domnio do problema Analista de sistema
Viso Dinmica
Viso Funcional
Processamento das informaes Fluxo dos dados entre as funes do objeto
Analista de sistema Projetista
4.2.2. Booch
Em sua metodologia de modelagem orientada a objetos, Booch [Booch91] coloca o esquema de vises com o foco nas atividades da fase de projeto do ciclo de desenvolvimento de software, considerando o seguinte processo incremental e iterativo:
Identificao das classes e objetos em um dado nvel de abstrao;
Identificao da semntica de tais classes e objetos; Identificao do relacionamento entre tais classes e objetos; Mapear a implementao de tais classes e objetos.
As vises do esquema de Booch so:
48
IME USP
Viso lgica; Viso fsica.
4.2.2.1. Viso Lgica Esta viso descreve a existncia e o propsito das principais abstraes que formam o projeto. representada por dois diagramas que definem a estrutura esttica do sistema: diagrama de classes e diagrama de objetos, conforme a notao de Booch. Os responsveis pelas atividades relacionadas a esta viso so os usurios conhecedores do domnio do problema, os analistas e projetistas de software. 4.2.2.2. Viso Fsica Esta viso descreve os componentes de hardware e software de uma implementao. representada por dois diagramas que complementam a estrutura esttica do sistema: diagrama de mdulos e diagrama de processos, conforme a notao de Booch. 4.2.2.3. Semntica Esttica e Dinmica Apesar da separao da complexidade do sistema nas vises lgica e fsica, existem eventos que acontecem dinamicamente entre as classes e os objetos. Para cada viso, h uma separao da representao em esttica e dinmica, acrescentando mais dois diagramas: diagrama de transio de estados e o diagrama de tempo. Cada classe pode ter um diagrama de transio de estados para indicar como os eventos externos afetam o estado de uma instncia da classe no tempo. O diagrama de tempo usado para mostrar a ordem de mensagens que os objetos trocam atravs do tempo. Tal diagrama tambm pode ser usado para documentar como os processos do diagrama de processos so sincronizados. A figura 4.3 mostra a relao entre as semnticas e as vises do esquema de Booch.
49
IME USP
Semntica dinmica Semntica esttica Estrutura de Classe Viso lgica Estrutura de Objeto Arquitetura de Mdulo Viso fsica Arquitetura de Processo
Figura 4.3 Os modelos do projeto orientado a objetos de Booch
4.2.2.4. Concluso do Esquema O esquema de vises de Booch considera a distino entre classes e objetos e possui diagramas independentes para cada um destes tipos de estruturas (diagrama de classes e diagrama de objetos). As vises determinam uma seqncia de atividades que ocorrem no tempo, ou seja, uma evoluo incremental dos conceitos do negcio e suas representaes. Primeiro devem ser pensados os detalhes da viso lgica para em seguida se pensar nos detalhes da viso fsica. As semnticas determinam a representao esttica e dinmica de ambas as vises. A tabela 4.2 mostra o resumo dos diagramas considerando as vises e as semnticas. Tabela 4.2 Resumo dos Diagramas do Esquema de Vises de Booch
Semntica esttica Viso lgica Semntica dinmica
Diagrama de classes Diagrama de objetos
Diagrama de transio de estados Diagrama de tempo Diagrama de processos
Viso fsica
Diagrama de mdulos
50
IME USP
4.2.3. 4+1 (RUP)

As vises deste esquema so descritas conforme o Rational Unified Process (RUP) [Kruchten00], um processo de engenharia de software que fornece uma disciplina para atribuio de tarefas e responsabilidades na organizao do desenvolvimento, com o objetivo de garantir produo de software de alta qualidade que atenda s necessidades do usurio, inclusive em planejamento e custo. Vrios propsitos so atendidos pelas vises do esquema 4+1(RUP), dentre os quais so destacados os seguintes:

Abordar a organizao lgica do sistema; Organizar suas funcionalidades; Abordar os aspectos de concorrncia; Descrever a distribuio fsica do software na plataforma utilizada.
As vises, conforme mostra a figura 4.4, so:

Viso lgica; Viso de processo; Viso de desenvolvimento; Viso de implementao; Viso de casos de uso.
Figura 4.4 Vises do Esquema 4+1 (RUP).
51
IME USP
4.2.3.1. Viso Lgica Esta viso est voltada para os requisitos funcionais que o sistema deve atender. Como est fortemente ligada ao problema do negcio em si, atravs desta viso que o arquiteto comunica-se de forma mais fcil com o conhecedor do negcio. Devido ao seu alto nvel de abstrao, independente de decises de projeto e implementao, utilizando-se do diagrama de classes. 4.2.3.2. Viso de Processo Esta viso est voltada para os aspectos de concorrncia do sistema em tempo de execuo, preocupando-se em como ele se comporta, quais mecanismos de comunicao so utilizados para troca eficiente de dados, qual o desempenho, o grau de confiabilidade, a tolerncia a falhas e distribuio dos elementos entre as partes que constituem o software. 4.2.3.3. Viso de Desenvolvimento Esta viso cuida de outros atributos de qualidade relacionados dualidade software-hardware, mapeando os componentes e subsistemas plataforma de software e aos equipamentos da infra-estrutura tcnica, com o objetivo de colocar o sistema em operao, ou seja, disponibiliz-lo para uso. O ambiente fsico para a execuo do sistema pode mudar: ambiente para desenvolvimento, teste e produo. Devido a estas alteraes, o ambiente fsico deve ser altamente flexvel e prover o mnimo de impacto. 4.2.3.4. Viso de Implementao Esta viso possui o foco na organizao dos mdulos estticos do sistema. utilizada para saber como distribuir o trabalho de implementao e manuteno do sistema entre as pessoas que constituem a equipe de desenvolvimento, inclusive considerando aspectos de reuso, subcontratao de desenvolvimento de software e aquisio de componentes prontos.
52
IME USP
4.2.3.5. Viso de Casos de Uso Os casos de uso so utilizados para mapear o relacionamento das vises, como mostra a figura 4.4, enfatizando que seus elementos sempre interagem, apesar de apresentarem estruturas diferentes. Os cenrios (situaes) representados pelos casos de uso so empregados para direcionar descobertas e projetos de arquitetura nas fases de concepo e elaborao estabelecidas pelo RUP. Como os cenrios tentam simular situaes reais e dinmicas, possvel empregar casos de teste para validao da arquitetura ainda em papel ou em prottipo. 4.2.3.6. Concluso do Esquema Originalmente, as vises deste esquema foram descritas em 1995 por Philippe Kruchten [Kruchten95], antes mesmo do lanamento do Processo Unificado de Desenvolvimento de Software [Jacobson98]. Este processo significa a descrio mais genrica do RUP. A evoluo deste esquema trouxe algumas diferenas sutis de conceitualizao que esto incorporadas no RUP, ou seja, este esquema de vises tornou-se parte do RUP. Uma destas diferenas est na viso de casos de uso que era anteriormente conhecida como Cenrio. Neste esquema, as vises so coordenadas com o objetivo de representar a arquitetura como um modelo de abstrao que possui o foco na estrutura nos elementos essenciais, sugerindo a notao UML [Booch98] como principal mecanismo de representao dos propsitos das vises. Apesar da viso de casos de uso, mais voltada para a modelagem das funcionalidades requisitadas pelo usurio final, este esquema no trata do processo do negcio, ponto chave para identificar os requisitos e estabelecer as estratgias de obteno do sistema. A tabela 4.3 apresenta os principais requisitos de cada viso do esquema e tambm o papel desempenhado pelo principal participante.
53
IME USP
Tabela 4.3 Resumo das Vises do Esquema 4+1 (RUP)

Requisito Principal Viso Lgica Viso de Processo Participante Principal
Funcionalidade Desempenho Escalabilidade Transferncia de dados (taxa)
Usurio final Integrador de sistema
Viso de Desenvolvimento
Topologia do sistema Distribuio e instalao Comunicao Gerenciamento do software
Engenheiro de sistema
Viso de Implementao
Programador Analista de sistema Analista de teste
Viso de Casos de Uso Comportamento
4.2.4. RM-ODP
O esquema Reference Model for Open Distributed Processing (RMODP) consiste de um esforo conjunto da ISO/IEC e ITU-T [RMODP97] em atividades de padronizao para descrever sistemas de processamento distribudo, fornecendo uma metodologia orientada a objetos para especificao dos requisitos deste domnio de aplicao. A metodologia baseada nos conceitos de vises (so cinco vises) e tambm em um vocabulrio denominado transparncias (so oito) que identifica problemas especficos de sistemas distribudos. A arquitetura do padro RM-ODP fornece:
Interproduo, ou seja, troca de informaes e uso conveniente de funcionalidades atravs de sistemas distribudos, uma vez estabelecidas as interfaces de comunicao/utilizao;
54
IME USP
Transparncia na distribuio, ou seja, esconde conseqncias de distribuio do programador, reduzindo a complexidade da programao.
Portabilidade e interoperabilidade de aplicaes atravs de plataformas heterogneas.
Viso da Empresa
poltica
Viso da Informao Viso da Computao
Viso da Engenharia
Viso da Tecnologia
Figura 4.5 Vises do esquema RM-ODP. As vises do esquema RM-ODP so cinco, cada qual possuindo conceito, estrutura e regras [Beitz97]:

Viso da empresa; Viso da informao; Viso computacional; Viso de engenharia; Viso tecnolgica.
A utilizao de vises est na necessidade de tornar a especificao grande e complexa de sistemas distribudos em pedaos gerenciveis que podem ser focados nas dificuldades mais relevantes dos
55
IME USP
participantes do desenvolvimento do sistema [Blair97]. A figura 4.5 mostra as vises, co-relacionadas entre si. 4.2.4.1. Viso da Empresa Esta viso refere-se ao propsito, escopo e restries que regem o negcio. usada para extrair requisitos e estruturas da organizao da empresa, concentrada nas aes desempenhadas que mudam a poltica e as restries do negcio (por exemplo, criar uma obrigao ou revogar uma permisso). Tal poltica determinada pela empresa e no imposta por questes tecnolgicas. Por exemplo, uma pessoa no pode ser limitada a ter apenas uma conta bancria porque mais fcil para o programador implementar no sistema. O modelo de empresa sustenta estas polticas e restries, incluindo agentes, artifcios, regras, comunidades e federao. 4.2.4.2. Viso da Informao Esta viso refere-se semntica e ao processo de informao. usada para descrever a informao requisitada pelo sistema atravs de representaes denominadas esquemas que especificam o estado e a estrutura dos objetos. O modelo de informao inclui o conceito de objetos compostos. Neste modelo, h trs tipos de esquemas: esttico (captura o estado e estrutura de um objeto em alguma instncia), invariante (restringe o estado e estrutura de um objeto no tempo) e dinmico (define uma mudana permitida no estado e estrutura de um objeto, restringindo-se ao esquema invariante). 4.2.4.3. Viso de Computao Esta viso usada para especificar a decomposio das funcionalidades de uma aplicao ODP de uma maneira transparente, considerando o particionamento lgico do sistema distribudo em vrios objetos que interagem entre si. Alm disso, encapsula dados e processamento e oferece uma ou vrias interfaces para interao com outros objetos. Os objetos desta viso podem ser aplicaes ou objetos de infra-estrutura.
56
IME USP
O modelo de computao representado por:
Interface: h trs formas de interao entre os objetos: operacional (modelo cliente-servidor para computao distribuda: cliente invoca operao na interface do servidor), orientada a cadeia (cadeias contnuas de informao fluem entre produtor e consumidor: cadeia de udio e vdeo) e orientada a sinal (fornece aes de comunicao em nvel muito baixo: servios OSI).
Atividade: as aes que um objeto pode sofrer so: criao e destruio do objeto; criao e destruio de uma interface; ligao com a interface; leitura e escrita do estado do objeto; invocao de uma operao na interface operacional; produo e consumo de um fluxo na interface em cadeia; iniciao ou resposta a um sinal na interface orientada a sinal. Tais aes podem ser seqenciadas ou paralelizadas.
Contrato de ambiente: pode ser expresso em termos do nvel de transparncia na distribuio e da qualidade de servios oferecidos pelas interfaces (segurana no transporte de informaes, por exemplo).
4.2.4.4. Viso de engenharia Esta viso refere-se infraestrutura necessria para suportar a distribuio. usada para descrever o projeto (design) dos aspectos orientados a distribuio do sistema ODP, mas no se concentra na semntica da aplicao ODP, exceto para determinar seus requisitos de distribuio e transparncia. O modelo correspondente a esta viso inclui objetos e canais. Os objetos podem ser divididos em duas categorias: objetos bsicos (correspondem aos objetos na especificao da viso computacional) e objetos de infra-estrutura (por exemplo, protocolos). Um canal corresponde a uma ligao ou objeto de ligao na especificao da viso computacional, ou seja, so mecanismos de comunicao e contm ou controla as funes de transparncia.
57
IME USP
4.2.4.5. Viso tecnolgica Esta viso refere-se escolha de tecnologias, descrevendo a implementao do sistema ODP e considerando os aspectos de identificao, distribuio e instalao de tecnologias de hardware e software especficas que suportam e constituem o sistema. O modelo correspondente a esta viso serve mais para justificar do que descrever subsdeos para seleo de tecnologias de mercado. 4.2.4.6. Concluso do Esquema O esquema RM-ODP especfico para ambientes de processamento distribudo e considera as vises como uma descrio completa e autocontida dos requisitos do sistema em diferentes nveis de detalhamento, conforme a audincia particular de pessoas envolvidas no processo. Alm disso, o objetivo deste esquema organizar os pedaos de um sistema ODP em um todo coerente e no padronizar componentes ou influenciar escolhas de tecnologias. O termo modelo da viso utilizado na descrio das vises no prescreve sintaxe e nem semntica especficas. No entanto, fornece uma terminologia bsica que necessria para modelar os interesses de cada viso [Blair97]. Este esquema tambm utiliza um conceito extendido de objeto oriundo das tcnicas tradicionais de orientao a objetos para atender s complexidades e particularidades do domnio de sistemas distribudos. A tabela 4.4 apresenta um resumo dos principais requisitos de cada viso do esquema RM-ODP e tambm o papel desempenhado pelo principal participante.
58
IME USP
Tabela 4.4 Resumo das Vises do Esquema RM-ODP

Requisito Principal Viso da Empresa Viso da Informao Viso da Computao Viso da Engenharia Participante Principal
Escopo e restries do negcio Esquema da informao (processo e semntica) Decomposio das funcionalidades Infra-estrutura Mecanismos de comunicao
Analista de negcio da empresa Usurio final Analista de sistema Engenheiro de sistema
Viso da Tecnologia
Escolha de tecnologias Implementao do framework distribudo
Projetista
4.2.5. Zachman
John Zachman [Zachman97] props um framework para elaborao da arquitetura de sistemas o qual apresenta mais do que vises diferentes sobre a arquitetura. O framework, como pode ver visto na figura A.1 do Anexo 1, consiste da viso dos vrios participantes interessados no desenvolvimento do sistema e est vinculada a seis caractersticas chamadas de abstratas, conforme segue: 1. DO QUE o produto feito; 2. COMO o produto trabalha; 3. ONDE os componentes esto relativamente uns aos outros; 4. QUEM faz o que, relacionado ao produto; 5. QUANDO as coisas acontecem; 6. POR QUE so feitas vrias escolhas.
59
IME USP
Desta forma, tenta-se isolar as caractersticas do objeto ou descrio da representao arquitetural em questo, descrevendo uma de cada vez e reduzindo a complexidade. O termo abstrao vem do processo de extrair do total, um subconjunto mais simples com o foco em algum item particular, contendo um plano global bem como detalhes tcnicos. As vises do esquema de Zachman so [Hay97a]:

Viso contextual; Viso conceitual; Viso lgica; Viso fsica; Viso de construo; Viso do sistema pronto.
4.2.5.1. Viso Contextual Esta viso define o propsito e o escopo do negcio em relao s diretivas tomadas pela empresa. Para qualquer esforo de desenvolvimento de sistemas, necessrio estabelecer o contexto. 4.2.5.2. Viso Conceitual Esta viso define, em termos de negcio, a natureza do negcio, incluindo sua estrutura, funes, organizao e restries. O plano estratgico da empresa (business plan) para obteno do sistema de software que atenda s necessidades do negcio a premissa para esta viso. 4.2.5.3. Viso Lgica Esta viso define o negcio descrito na viso conceitual em estruturas mais rigorosos de organizao da informao. Por exemplo, a viso conceitual descreve as funes de negcio e, em contrapartida, a viso lgica descreve as mesmas funes sob a perspectiva de transformao dos dados.
60
IME USP
4.2.5.4. Viso Fsica Esta viso descreve como a tecnologia pode ser usada para atender as necessidades do sistema identificadas previamente. Neste momento, interfaces com o usurio so definidas, linguagens so selecionadas, estruturas so definidas, modelos e escolhas de bases de dados so feitas. 4.2.5.5. Viso de Construo Esta a viso das especificaes do programa, da base de dados, do ambiente de rede. Todas estas especificaes so realizadas em termos das linguagens selecionadas na viso anterior. 4.2.5.6. Viso do Sistema Pronto Esta viso representa o sistema implementado e em funcionamento, fazendo parte da organizao. Os aspectos como treinamento de pessoas e adequao aos eventos e regras de negcio tambm constituem esta viso. 4.2.5.7. Concluso do Esquema As vises do esquema de Zachman so descritas com o foco nos participantes do processo de desenvolvimento, incluindo os seguintes: os responsveis pelo negcio da empresa, as pessoas que executam as atividades direcionadas ao negcio, os analistas de sistema que querem representar o negcio de uma forma disciplinada, os projetistas que aplicam tecnologias especficas para solucionar os problemas do negcio, os implementadores do sistema e por fim o sistema mesmo. Este esquema no fornece linguagem para modelar as coisas que descreve e nem processo para definio da arquitetura. Porm, constitui a base de um framework (Anexo 1) que representa caractersticas que possuem cruzamento de informaes entre si. A tabela 4.5 resume os principais requisitos de cada viso do esquema e tambm o papel desempenhado pelo principal participante. Tabela 4.5 Resumo das Vises do Esquema de Zachman
61
IME USP
Requisito Principal Viso Contextual
Participante Principal
Propsito do negcio Diretrizes da empresa Estrutura, funes e organizao do negcio Requisitos e funcionalidades Infra-estrutura Aspectos tecnolgicos Especificaes do sistema
Analista de negcio da empresa Analista de negcio Usurio final Engenheiro de sistema Analista de sistema Projetista
Viso Conceitual Viso Lgica Viso Fsica
Viso de Construo
Viso do Sistema Pronto
Evoluo e melhorias do Analista de negcio sistema Usurio final Avaliao da adequao Arquiteto da arquitetura
4.3. Alguns Outros Esquemas de Vises Menos Difundidos

Existem vrias outras frentes de pesquisas na rea de arquitetura de software que tambm consideram os conceitos relacionados a vises. Esta seo trata de trs outros esquemas de vises que so menos difundidos na indstria de software, mas que possuem sua importncia e, em alguns casos, sua descrio semelhante a algumas das vises j apresentadas no item anterior. Os esquemas apresentados so: 1. TAFIM [www9]; 2. TOGAF [www8]; 3. Holfmeister-Soni-Nord [Holfmeister00].
62
IME USP
4.3.1. TAFIM
A sigla TAFIM [www9] significa Technical Architecture Framework for Information Management, um framework construdo para o desenvolvimento de arquiteturas de sistemas de informao do Departamento de Defesa Americano (DoD). Fornece servios, padres, conceitos de projeto (design), componentes e configuraes que podem ser usados para guiar a definio de arquiteturas de domnio especfico. As vises deste esquema so:

Viso de computao; Viso de gerenciamento de dados; Viso de comunicao; Viso de segurana.
4.3.1.1. Viso de Computao Esta viso trata dos aspectos da arquitetura tcnica, compreendendo os interesses dos engenheiros de sistema e software. A sua abrangncia depende do ambiente e da plataforma computacional do sistema, existindo modelos especficos para cada caso, como descrito a seguir.
Modelo Cliente/Servidor, onde os computadores clientes fazem requisies de servios e informaes oferecidas pelo computador servidor, inclusive dados armazenados em base de dados.
Modelo
Baseado um
em
Hospedagem de
(host),
onde
processamento todo centralizado na mquina hospedeira (tipicamente computador grande porte), sendo requisitado por terminais burros.
Modelo Hierrquico Meste-Escrevo(master-slave), onde os computadores escravos (slave) so ligados aos computadores mestre (master) e desempenham processamento somente quando demandado pelo mestre. Podem existir vrias camadas, onde os computadores mestre de uma camada so utilizados
63
IME USP
como coputadores escravos pela camada imediatamente anterior.
Modelo Peer-to-Peer, onde os computadores so considerados servidores quando recebem e respondem as requisies de servios e so considerados clientes quando solicitam os servios.
Modelo de Objetos Distribudos, onde os servios de requisio so tratados como objetos, utilizando interfaces de comunicao bem definidas e encapsulando detalhes de configurao dos objetos.
4.3.1.2. Viso de Gerenciamento de Dados Esta viso refere-se a servios de administrao e gerenciamento de dados, incluindo aspectos de armazenamento, recuperao, manipulao, backup, integridade e segurana no acesso, tanto para dados centralizados quanto para dados distribudos. 4.3.1.3. Viso de Comunicao Esta viso refere-se aos aspectos de comunicao entre componentes que compem o sistema, considerando a distribuio geogrfica da infra-estrutura. Neste sentido, interfaces padronizadas facilitam a portabilidade, interoperabilidade e a flexibilidade entre as redes geograficamente distribudas. 4.3.1.4. Viso de Segurana Esta viso refere-se aos aspectos de segurana, considerando as seguintes caractersticas: controle de acesso s informaes, integridade das informaes que trafegam pela rede de comunicao, uniformidade dos mecanismos de proteo e segurana e distribuio adequada das camadas de segurana (hardware e software).
64
IME USP
4.3.2. TOGAF
A sigla TOGAF [www8] siginfica The Open Group Achitecture Framework e constitui-se de um framework para definio de arquiteturas de sistemas de informao, incluindo mtodo de desenvolvimento para atender s necessidades do negcio. Foi desenvolvido pelos membros do The Open Group com base no TAFIM [www9]. As vises deste esquema esto baseadas em observaes de diferentes pessoas que desempanham papis distintos na definio de uma arquitetura. As vises so as seguintes:

Viso de negcio Viso de engenharia Viso de operao Viso de aquisio
4.3.2.1. Viso de Negcio Esta viso compreende os interesses dos usurios do sistema com foco nos aspectos funcionais, descrevendo os fluxos de informao entre pessoas e o processo de negcio baseados em anlises do ambiente existente, dos requisitos e restries que afetam o novo sistema. Tambm considera os aspectos de usabilidade e desempenho. 4.3.2.2. Viso de Engenharia Esta viso compreende os interesses de engenheiros de sistema e de software responsveis por desenvolver e integrar vrios componentes do sistema. O foco desta viso o modo em como o sistema ser implementado, considerando os aspectos de segurana, armazenamento de dados e rede de comunicao (distribuio geogrfica). 4.3.2.3. Viso de Operao Esta viso compreende os interesses dos administradores e gerentes do sistema responsveis em manter o sistema disponvel e operando
65
IME USP
corretamente. Tambm considera os aspectos de inicializao do sistema, upgrading, desempenho, monitorao da segurana e gerenciamento de falhas. 4.3.2.4. Viso de Aquisio Esta viso compreende os interesses do pessoal responsvel pelo benchmark e cotao de componentes de hardware e software que sero necessrios para compor o sistema, mantendo a adequao arquitetura.
4.3.3. Holfmeister-Nord-Soni
O esquema de vises de Holfmeister, Nord e Soni [Holfmeister00] nasceu do estudo de princpios e semelhanas em domnios de aplicao com o objetivo de obter subsdios que levassem a uma boa arquitetura de software. As vises esto baseadas no que os autores observaram na prtica. Cada uma delas descreve um tipo diferente de estrutura e mapeia interesses diferentes de engenharia, auxiliando no gerenciamento da complexidade do sistema. As vises consideradas neste esquema so (figura 4.6):

Viso de Cdigo; Viso de Mdulo; Viso de Execuo; Viso Conceitual.
66
IME USP
Figura 4.6 Vises do Esquema de Holfmeister-Nord-Soni [Holfmeister00].
4.3.3.1. Viso de Cdigo Esta viso refere-se ao modo como o cdigo-fonte est organizado, considerando cdigo de objetos, bibliotecas, cdigo binrio, controle de verses, controle de arquivos e distribuio dos diretrios. Esta organizao afeta diretamente a reusabilidade do cdigo e, consequentemente, o tempo de desenvolvimento do sistema. 4.3.3.2. Viso de Mdulo Esta viso refere-se decomposio do sistema e o particionamento dos mdulos em camadas com o objetivo de diminuir a complexidade do trabalho em construi-lo atravs do aumento da escalabilidade (tanto em funcionalidades quanto em programadores). A utilizao de conceitos oriundos da tecnologia orientada a objetos como encapsulamento, abstrao, interface de comunicao so discutidos nesta viso. 4.3.3.3. Viso de Execuo Esta viso refere-se aos aspectos dinmicos do sistema, preocupando-se em como os mdulos so mapeados aos elementos fornecidos pela plataforma operacional (distribuda, centralizada) e aos elementos da
67
IME USP
arquitetura de hardware. Dentre os aspectos de qualidade considerados esto: desempenho, requisitos de reconfigurao, concorrncia, replicao, tolerncia a falhas e capacidade de absorver mudanas. 4.3.3.4. Viso Conceitual Esta viso refere-se ao domnio de aplicao, mapeando as funcionalidades do sistema aos elementos arquiteturais demoninados componentes conceituais. A coordenao e troca de dados manipulada pelos elementos denominados conectores. Os problemas e solues desta viso devem ser tratados com independncia de tecnologias de hardware e software e com atributos que possam guiar as outras vises.
4.4. Comparao entre os Principais Esquemas de Vises

Cada esquema de vises tem como objetivo observar um determinado aspecto da arquitetura, considerando vrias perspectivas. Apesar das vises apresentarem semelhanas conceituais em sua descrio, como pde ser observado nas sees anteriores, elas ressaltam aspectos de partes diferentes da arquitetura, dependendo da sua localizao dentro do processo de desenvolvimento. Os detalhes que dizem respeito a semelhanas e divergncias entre as vises so discutidos a seguir, ressaltando os aspectos que do a evoluo incremental no que se refere aos conceitos que definem os esquemas. O esquema de Booch [Booch91] apresenta, alm da caracterstica de complemento conceitual entre as vises, a caracterstica de procedimento para a execuo das atividades de modelagem, ditando o que deve ser feito primeiro e o que deve ser feito em seguida. A abordagem deste esquema est em identificar pequenas partes do sistema e model-las semelhante a OMT, considerando os aspectos esttico, dinmico e funcional, mas com distino clara entre os detalhes lgicos e fsicos de cada parte. Tanto o esquema OMT [Rumbaugh91] quanto o esquema de Booch [Booch91] consideram que o modelo do processo de negcio que o sistema automatizado
68
IME USP
ir apoiar e tambm o escopo deste sistema j foram anteriormente definidos do ponto de vista de negcio. Conceitualmente, as vises do esquema 4+1 (RUP) [Kruchten00] so uma extenso dos esquemas OMT e Booch. O foco de observao considerado o prprio sistema como um todo e deste foco so extrados no somente os aspectos esttico, dinmico e funcional como tambm as informaes relacionadas aos detalhes da fase de projeto (design) e aos ambientes fsicos de desenvolvimento, teste e operao. Os detalhes de projeto so referentes identificao, especificao e organizao dos componentes de software que guiam e orientam a fase de implementao. A notao UML [Booch98] sugerida como linguagem para representar os modelos retratados pelas vises do esquema 4+1 (RUP). Os esquemas OMT e de Booch sugerem diagramas equivalentes aos diagramas da notao UML, o que bastante natural, uma vez que a UML originalmente uma evoluo de trs frentes de estudos em tecnologias orientadas a objetos. Duas destas frentes so Booch e OMT. A outra frente refere-se ao Objectory [Jacobson92] [Jacobson95], um processo de desenvolvimento orientado a objetos cujo mentor Ivar Jacobson. Os diagramas, tanto da notao UML quanto aqueles dos esquemas de Booch e OMT, representam um nvel mais baixo de abstrao em comparao com o objetivo do esquema 4+1(RUP) que so as perspectivas do sistema como um todo. Portanto, as vises da OMT e de Booch podem ser consideradas subvises em relao s vises do esquema 4+1 (RUP). O esquema RM-ODP [Blair97] tambm tem os esquemas da OMT e de Booch como subvises que aparecem nas vises de informao e computao. Este esquema possui perspectivas mais abrangente dentro do processo de desenvolvimento de sistemas do que o 4+1 (RUP) pois preocupa-se com o processo do negcio e suas restries em conformidade com a empresa ou organizao para a qual o sistema est sendo construdo. Os aspectos do processo de negcio devem ser definidos antes mesmo do levantamento dos requisitos funcionais. O esquema 4+1 (RUP) considera que este processo j est definido e sua preocupao comea com o levantamento dos requisitos.
69
IME USP
Em contrapartida, o esquema 4+1 (RUP), atravs da perspectiva de casos de uso, fornece indcios que sustentam a especificao e execuo dos testes relacionados aos aspectos funcionais. O esquema de vises de Zachman [Zachman97] o mais abrangente dentro do processo de desenvolvimento pois, alm de cobrir os aspectos de negcio (processo e requisitos), considerando o ambiente e estrutura organizacional da empresa, este esquema tambm se preocupa com os aspectos e os benefcios trazidos para a empresa pelo sistema depois que ele est pronto e operacional. Neste esquema, no h um mtodo que guie a definio da arquitetura. O framework no qual as vises esto contidas no fornece um processo para desenvolv-las e nem a ordem na qual elas devem ser consideradas. Esta deficincia superada no captulo que segue, mais especificamente na tabela 5.1, a qual apresenta a relevncia das vises nas fases do processo clssico de desenvolvimento de sistemas. Vale notar que este incremento de evoluo conceitual no est relacionado com a ordem cronolgica do surgimento dos esquemas. A figura 4.7 resume a discusso apresentada acima, mostrando a abrangncia de conceitos entre os esquemas e a origem destes dos conceitos.
Abrangncia dos conceitos Origem dos conceitos
Zachman RM-ODP
Evoluo conceitual
RM-ODP 4+1
Evoluo temporal
1997
4+1 Booch OMT
Booch OMT Zachman
1991
1987
Figura 4.7 Abrangncia de conceitos X origem dos conceitos
70
IME USP
4.5. Resumo Comparativo dos Principais Esquemas de Vises

A figura 4.8 a seguir, apresenta um resumo das comparaes feitas entre os principais esquemas de vises, organizando-as conforme caractersticas categorizadas por afinidade de conceitos.
Figura 4.8 Resumo das Comparaes entre os Principais Esquemas de Vises
71
IME USP

Este captulo apresentou as definies relativas s vises arquiteturais e tambm os principais esquemas de vises conforme a formalizao feita por vrios autores. Ressaltando que a complexidade em se definir uma arquitetura pode ser quebrada atravs da observao de seus aspectos sob vrios pontos de vista. Cada viso, independente esquema ao qual pertence, evidencia alguns aspectos relevantes ao seu contexto e esconde os outros aspectos menos relevantes. Este o tipo de viso de compreenso. Tais aspectos arquiteturais no evidenciados em uma determinada viso, sero evidenciados em outra viso que complementa o esquema. Este o tipo de viso de complemento. Os esquemas de vises apresentados contribuem com a definio de uma arquitetura tambm atravs da identificao de responsveis pelo levantamento e modelagem dos aspectos em evidncia e de possveis notaes para representar tais modelos. A viso de um esquema pode ser to abrangente dentro do processo de desenvolvimento de sistemas ao ponto de absorver uma ou mais vises de outro esquema. Abusivamente, como se existissem subvises. Este um dos assuntos que sero discutidos no prximo captulo.
72
IME USP
5. Utilizao dos Esquemas de Vises

Objetivo do captulo O objetivo deste captulo correlacionar os esquemas de vises com as fases do processo de desenvolvimento de sistemas e com os fatores de qualidade, gerando discusses que norteiam a escolha do esquema de vises mais adequado para definir a arquitetura de um sistema. Esta discusso ser feita considerando a abrangncia, o impacto na qualidade e o foco de atuao dos esquemas com base no processo de desenvolvimento. Motivao Nos captulos anteriores, foi possvel perceber que definir uma boa arquitetura fundamental para a sade do sistema, tanto no desenvolvimento quanto nas suas posteriores manutenes (corretivas ou evolutivas). durante a definio da arquitetura que as restries referentes ao desempenho, portabilidade, segurana e demais requisitos no funcionais relacionados ao negcio precisam ser identificados e solucionados. Os esquemas de vises apresentados levantam vrios aspectos sobre a arquitetura que devem ser considerados na sua especificao. O intuito est em validar as decises tomadas e garantir a cobertura dos requisitos necessrios. O escopo dos esquemas de vises dentro do processo de desenvolvimento de sistemas indica a abrangncia do esquema. Sabendo desta abrangncia, pode-se escolher o esquema com o foco adequado na definio da arquitetura. Os esquemas sugerem notaes que j so conhecidas e comercialmente difundidas para representar os modelos arquiteturais. Porm, qualquer notao que se adeque aos aspectos descritos nas vises pode ser utilizada devido abstrao encontrada nas vises, ou seja, os esquemas de vises no restringem a notao. Por exemplo, possvel utilizar alguns diagramas da notao UML para representar as perspectivas abordadas no esquema da OMT, embora este esquema sugira notao prpria da sua metodologia. Organizao do captulo O item 5.1 discute os esquemas de viso apresentados no captulo 4, considerando sua abrangncia no processo de desenvolvimento. Esta forma de organizao influencia o arquiteto ao utilizar o esquema para apoiar a definio da arquitetura.
73
IME USP
O item 5.2 discute os esquemas de viso apresentados no captulo 4, considerando os requisitos de qualidade que cada um atende. O modelo de qualidade utilizado nesta comparao o modelo de McCall [McCall94] [Pfleeger98]. O item 5.3 apresenta algumas consideraes finais sobre o estudo comparativo dos esquemas de vises, considerando sua abrangncia no processo de desenvolvimento de sistemas e seu impacto nos fatores de qualidade desejados para a arquitetura que est sendo definida.
5.1. Abrangncia dos Esquemas de Vises

5.1.1. Esquema Conceitual para Comparar Esquemas de Vises Segundo a sua Abrangncia no Processo de Software
O esquema conceitual consiste na organizao estrutural dos esquemas de vises dentro do processo de desenvolvimento, ou seja, a distribuio das vises entre as fases do processo de acordo com os aspectos que cada uma delas descreve. Atravs desta distribuio, possvel perceber a abrangncia do esquema e o quanto os aspectos descritos em suas vises atendem cada uma das fases do processo, conforme o nvel de abstrao no qual esto apoiadas. O objetivo do esquema conceitual proporcionar subsdios para a escolha adequada do esquema de vises a ser utilizado na definio da arquitetura do problema que se quer resolver. Aliando as diferentes perspectivas apresentadas nas vises com o processo de desenvolvimento, tem-se a garantia de transio adequada entre as fases pois o esquema conceitual mostra a sequncia na qual as informaes devem ser modeladas conforme seu nvel de abstrao. Isto ocorre pois cada viso tem uma determinada cobertura em relao s fases do processo. O processo de desenvolvimento considera as seguintes fases, conforme figura 2.1 (vide captulo 2 deste documento) [Pressman01]:
74
IME USP
Engenharia de requisitos/informaes: fase que estabelece os requisitos necessrios conforme a estratgia e a rea de atuao do negcio e identifica a interao do sistema com outros elementos externos, tais como hardware, pessoas, base de dados ou outros sistemas. Neste trabalho, esta fase dividada em duas etapas: processo de negcio e levantamento de requisitos;
Anlise de requisitos: fase que estabelece o entendimento da natureza do sistema a ser construdo, o domnio de informaes, as funcionalidades solicitadas e o comportamento em relao ao negcio;
Projeto: fase na qual se transforma requisitos em uma representao do software que pode ter medidas de qualidade antes da codificao iniciar;
Codificao: fase na qual se transforma o projeto em cdigo legvel por mquina;
Teste: fase na qual se testa o cdigo gerado, com foco tanto na lgica interna do software quanto nas funcionalidades externas;
Operao: fase na qual se identificam as mudanas e manutenes (corretivas, evolutivas ou adaptativas) necessrias no software.
Apesar do modelo de processo adotado para explicao do esquema conceitual ser linearmente sequencial, o desenvolvimento no implica que, ao final, o software estar completamente pronto. O processo, para fornecer verses rpidas e cada vez mais robustas, deve ser iterativo e incremental, aliando-se s fases do modelo cascata (figura 2.1, captulo 2).
75
IME USP
5.1.2. Comparao Conceitual
dos
Esquemas
Usando
Esquema
O esquema conceitual traduz a abrangncia do esquemas de vises, mostrando que os esquemas so ortogonais na descrio da arquitetura que eles abordam. A comparao dos esquemas de vises que feita neste item considera o quanto as vises de um esquema atendem s especificaes de cada fase do processo de desenvolvimento. A tabela 5.1 a seguir mostra a abrangncia dos esquemas dentro do processo de desenvolvimento de sistemas, enfatizando em quais fases so consideradas as vises.
76
IME USP
Tabela 5.1 Relevncia das Vises nas Fases do Processo de Desenvolvimento de Sistemas.
5.1.2.1. Os Esquemas OMT e BOOCH Os esquemas OMT e Booch esto sendo comparados nesta mesma seo uma vez que eles apresentam muitas caractersticas semelhantes em relao ao esquema conceitual. Os esquemas OMT e Booch compreendem as fases de anlise e projeto, considerando que o processo de negcio e os requisitos j esto devidamente modelados. Isto significa que a modelagem arquitetural precisa ser complementada para cobrir a fase de engenharia de
77
IME USP
requisitos e se estender para as fases de codificao, teste e operao. No entanto, para domnios de aplicao cuja complexidade de negcio pequena ou j est bastante conhecida, tais esquemas so bem aplicveis. Os aspectos dinmicos dos esquemas OMT e Booch podem ser utilizados como subsdios para a fase de teste, mas esta considerao no est claramente identificada na descrio das vises. Ela implcita e depende da metodologia utilizada na empresa para que este vnculo seja feito. 5.1.2.2. O Esquema 4+1 (RUP) Em comparao com OMT e Booch, o esquema 4+1 (RUP) abrange mais fases do processo de desenvolvimento, identificando aspectos que envolvem o levantamento das funcionalidades, a distribuio fsica dos elementos que compem o software e a preocupao com ambientes distintos e especficos para desenvolvimento, teste e operao. O RUP, processo para o qual as vises deste esquema foram criadas, trata os aspectos com a preocupao de modificabilidade e manuteno. Mas isto no claro na descrio das vises. A viso de casos de uso do esquema 4+1(RUP) utilizada na fase de levantamento dos requisitos como identificador de situaes que podem ocorrer no sistema. Esta viso apresenta situaes que so subsdios para a execuo dos testes que validam a aderncia dos requisitos ao sistema. 5.1.2.3. O esquema RM-ODP O esquema RM-ODP possui, na viso da empresa, os aspectos relacionados ao negcio e suas restries, peocupando-se em como a soluo distribuda deve se adequar s questes polticas e organizacionais da empresa para a qual o sistema est sendo construdo. Esta viso est localizada na etapa de modelagem do processo negcio da fase de engenharia de requisitos, ou seja, consiste na primeira atividade ao se definir a arquitetura.
78
IME USP
A conformidade dos requisitos especificados com a sua implementao um item mencionado para o padro de modelagem de sistemas distribudos, mas no referenciado em nenhuma das vises do esquema RM-ODP. Por isso, no h viso correspondente fase de teste. A mesma interpretao dada aos aspectos de modificabilidade e manuteno, assim como ocorre no esquema 4+1 (RUP), no havendo correspondncia de viso na fase de operao. 5.1.2.4. O esquema de Zachman O esquema de Zachman o mais abrangente de todos os principais esquemas, possuindo uma viso correspondente a cada fase do processo de desenvolvimento. Este esquema no fornece linguagem para representao dos aspectos que aborda e nem processo especfico de utilizao. Porm, atravs de um framework (vide Anexo 1), as vises so organizadas conforme seu nvel de abstrao. O foco do esquema de Zachman voltado para classificar e organizar os requisitos complexos dos negcios de uma empresa. As vises deste esquema descrevem informaes que vo alm do processo de desenvolvimento considerado, identificando aspectos que servem para a arquitetura de negcios da empresa e no somente para a arquitetura de um dos sistemas utilizados na empresa. Assim como a viso de casos de uso do esquema 4+1 (RUP), a viso conceitual do esquema de Zachman utilizada na fase de testes. A escolha de um dos esquemas como base para definio da arquitetura depende da complexidade do domnio de aplicao do negcio e tambm do nvel de maturidade da equipe de desenvolvimento.
79
IME USP
5.2. Impacto das Vises na Qualidade do Software

5.2.1. Modelo de Qualidade de Software
A garantia da qualidade de um software depende da qualidade da arquitetura definida para este software. Para Pressman [Pressman01], h trs pontos importantes relacionados qualidade: 1. Requisitos de software so a base para medidas de qualidade. Falta de aderncia da arquitetura aos requisitos significa falta de qualidade; 2. Padres especficos estabelecem um conjunto de critrios que guiam a definio da arquitetura. Se os critrios no so seguidos, o resultado no ter qualidade. 3. H os atributos de qualidade (requisitos no funcionais) que nem sempre so mensionados. Se a arquitetura apresenta os requisitos explcitos, mas no apresenta algum dos requisitos implcitos, a qualidade ser duvidosa. Os fatores de qualidade propostos por McCall [McCall94] [Pfleeger98] constituem uma categorizao de fatores que afetam a qualidade do software e esto diretamente ligados arquitetura. Estes fatores, conforme mosta a figura 5.1, preocupa-se com trs aspectos importantes do software:

Caractersticas operacionais do software; Sua capacidade de absorver mudanas; Sua facilidade de adaptao a novos ambientes.
80
IME USP
Figura 5.1 Fatores de qualidade de software de McCall. Os fatores de qualidade so aqueles apresentados na tabela 5.1 a seguir. Tabela 5.2 Descrio dos Fatores de Qualidade de McCall.
Fatores de Qualidade Operao Corretude Descrio
Fator no qual um software satisfaz sua especificao e os objetivos do usurio final. Fator no qual um software executa sua funco com a preciso necessria, livre de falhas (tolerncia a falhas). Esforo necessrio para aprender, operar, preparar as entradas e interpretar as sadas do software. Fator no qual o acesso aos dados e s funcionalidades do software controlado, no permitindo a utilizao incorreta (robustez) ou por pessoas no autorizadas e garantindo a restaurao dos dados em caso de falha inevitvel. Fator que refere-se quantidade de recursos de computao e cdigo necessrios para o software desempenhar sua funo. Esforo requerido para adaptar um software a vrios ambientes de hardware/software diferentes (plataformas de hardware, sistemas operacionais, compiladores). Fator no qual um software (ou parte dele) pode ser reutilizado em outras aplicaes, conforme o escopo das funes executadas.
Segurana
Usabilidade
Integridade
Eficincia
Transio
Portabilidade
Reusabilidade
81
IME USP
Interoperabilidade
Esforo requerido para juntar um software a outro, atravs acessos bem definidos a funcionalidades externamente visveis. Esforo requerido para localizar e corrigir um erro em um software bem como identificar formas de alterar funes ou agregar novas funes com o objetivo de evoluo, com o mnimo de impacto. Esforo requerido para modificar um software que est em produo. Esforo requerido para testar um software com o objetivo de garantir que ele desempenhe as funes atribudas.
Reviso/ Manuteno
Manutenibilidade
Flexibilidade
Testabilidade
difcil, e em alguns casos, impossvel desenvolver medidas diretas para estes fatores de qualidade. Uma forma de garantir que todos estes fatores esto mapeados no modelo arquitetural atravs de revises baseados em checklist.
5.2.2. Comparao dos Esquemas de Vises Usando o Modelo de Qualidade

A necessidade de se construir um sistema determina qualidades que devem ser acomodadas pela arquitetura. O atendimento aos requisitos funcionais a condio bsica para os servios e habilidades do sistema. Porm, muitos destes sistemas so reprojetados no por causa de deficincias em suas funcionalidades, mas devido dificuldade de serem mantidos, ou pela deficincia no desempenho e na segurana [Bass98]. Segundo o modelo de qualidade de McCall [McCall94] [Pfleeger98], uma arquitetura pode ser avaliada conforme os atibutos de qualidade (requisitos no funcionais) que ela aborda. A escolha de um esquema de vises arquiteturais como apoio e base para a representao do modelo da arquitetura deve garantir a adequao do resultado obtido.
82
IME USP
O modelo de McCall utilizado para mostrar, dentre os seus aspectos de qualidade, quais deles so abordados pelas vises dos principais esquemas descritos no captulo 4. A tabela 5.3 apresenta o resumo da comparao com a relevnca de cada esquema de vises em funo dos fatores de qualidade do modelo de McCall. Tabela 5.3 Matriz de Qualidade dos Esquemas de Vises
Fatores de Qualidade Operao
Corretude
Esquemas de Vises OMT

--
Booch
--
4+1 (RUP)
Vises lgica e de casos de uso Viso de desenvolvimento Viso de casos de uso Vises de processo e de implementao
RM-ODP
Vises da empresa e da informao Viso de engenharia --
Zachman
Vises contextual e conceitual Viso fsica Vises conceitual e lgica Vises lgica, fsica e de construo Viso de construo Viso fsica Vises lgica e do sistema pronto Viso fsica Viso lgica Viso do sistema pronto Viso conceitual
Segurana Usabilidade
-Viso dinmica Vises esttica, dinmica e funcional Viso esttica ---
-Viso lgica Vises lgica e fsica Viso fsica
Integridade
Vises da informao e computao
Eficincia
Vises de Vises da processo e computao e desenvolvimento engenharia Viso de implementao Vises de processo e de implementao Viso de desenvolvimento --Viso de casos de uso Viso tecnolgica Viso de computao Viso de engenharia --Viso tecnolgica
Transio
Portabilidade Reusabilidade
---
Interoperabilidade
-----
-----
Reviso/ Manuteno
Manutenibilidade Flexibilidade Testabilidade
5.2.2.1. Os Esquemas OMT e BOOCH Os esquemas OMT e Booch esto sendo comparados nesta mesma seo uma vez que eles apresentam muitas semelhantes em relao aos fatores de qualidade considerados.
83
IME USP
Os esquemas OMT e Booch possuem o fator de usabilidade descritos pelas vises dinmica e lgica, respectivamente, devido interao sequencial entre os objetos, demontradas pelas situaes de negcio que representam.Tambm apresentam o fator integridade em todas as vises. O fator eficincia aparece nas vises esttica (OMT) e fsica (Booch) pois elas trazem aspectos de encapsulamento e distribuio da complexidade estrutural do negcio em relao ao esforo de computao. 5.2.2.2. O Esquema 4+1 (RUP) Para o esquema 4+1(RUP), a qualidade est relacionada :
Corretude atendida pelas vises lgica e de casos de uso pois elas concentram os aspectos de especificao das funcionalidades requeridas ao software, com o objetivo de atender s necessidades do usurio final.
Segurana atendida pela viso de desenvolvimento uma vez que est voltada para as decises de projeto que auxiliam a implementao.
Usabilidade atendida pela viso de casos de uso pois esta viso apresenta as situaes comportamentais do software no nvel do usurio final.
Integridade atendida pelas vises de processo e de implementao pois estas vises tratam dos aspectos de robustez do software.
Eficincia
atendida
pelas
vises
de
processo
desenvolvimento. A primeira trata dos aspectos de desempenho, escalabilidade e transferncia de dados e a segunda trata da topologia do software e a distribuio dos seus componentes nos ambientes de hardware/software.
Portabilidade atendida pela viso de implementao tambm pela distribuio dos componentes do software nos ambientes de hardware/software.
84
IME USP
Reusabilidade atendida pela viso de processo em funo da integrao entre sistemas e pela viso de implementao em funo do gerenciamento de atividades da equipe (subcontratao, aquisio de componentes).
Interoperabilidade atendida pela viso de desenvolvimento por tratar das decises tecnolgicas e abrangncia do software em multi-meios.
Testabilidade atendida pela viso de casos de uso uma vez que compreende o comportamento do software em relao s funcionalidades.
Os fatores de manutenibilidade e flexibilidade no esto presentes na descrio das vises do esquema 4+1 (RUP). Eles aparecem implicitamente medida que os demais fatores so atendidos. 5.2.2.3. O Esquema RM-ODP Para o esquema RM-ODP, a qualidade relacionada :
Corretude atendida pelas vises da empresa e da informao pois elas tratam, respectivamente, do contexto do negcio e do fluxo de informaes que satisfazem os interesses deste contexto.
Segurana atendida pela viso de engenharia uma vez que est voltada para as decises de projeto que auxiliam a implementao, assim como ocorre na viso de desenvolvimento do esquema 4+1(RUP).
Integridade atendida pela viso da informao, uma vez que compreende os fluxos e os processos de manipulao de informaes, e pela viso de computao pois trata dos aspectos lgicos do software relacionados robustez.
Eficincia atendida pelas vises de computao e engenharia, pois tratam distribuio dos componentes. A primeira, considerando os aspectos lgicos e a segunda considerando os aspectos fsicos (infraestrutura).
85
IME USP
Portabilidade atendida pela viso tecnolgica pois esta viso trata das justificativas de escolhas de tecnologias de hardware e software.
Reusabilidade atendida pela viso de computao em funo da distribuio lgica dos componentes que constituem o software.
Interoperabilidade atendida pela viso tecnolgica por tratar dos das decises tecnolgicas e abrangncia do software em multi-meios.
Flexibilidade atendida pela viso de computao em funo da distribuio lgica dos componentes que constituem o software
O fator de usabilidade no est presente na descrio das vises do esquema RM-ODP pois seu foco est mais voltado para distribuio dos componentes que constituem o software do que para as necessidades de negcio. Os fatores de manutenibilidade e testabilidade, assim como nas vises do esquema 4+1 (RUP), aparecem implicitamente apenas, medida que os demais fatores so atendidos. 5.2.2.4. O Esquema de Zachman Para o esquema de Zachman, a qualidade relacionada :
Corretude atendida pelas vises contextual e conceitual pois elas tratam, respectivamente, do contexto e escopo do negcio e do plano estratgico da empresa para obteno do sistema (business plan).
Segurana atendida pela viso fsica uma vez que trata das estruturas de projeto e de como ser o comportamento do software (a ocorrncia equivalente aos esquemas 4+1(RUP) e RM-ODP).
Usabilidade atendida pela viso conceitual uma vez que trata dos modelos de processo de negcio e das caractersticas de
86
IME USP
acessibilidade e pela viso lgica devido ao modelo de interface homem-mquina.
Integridade atendida pelas vises lgica, fsica e de construo pois todas compreendem os modelos dos dados e dos processos de manipulao de tais dados relacionados robustez.
Eficincia atendida pela viso de construo, pois trata da distribuio dos componentes e da especificao das regras de negcio na lgica de programao.
Portabilidade atendida pela viso fsica pois esta viso trata do modelo tecnolgico de hardware e software.
Reusabilidade atendida pelas vises lgica e do sistema pronto, pois a primeira viso trata do modelo de regras do negcio e a segunda trata da operacionalizao do sistema, potencializando o reuso em outros software ou em prximas verses do mesmo software.
Interoperabilidade atendida pela viso fsica por tratar das decises tecnolgicas e abrangncia do software em multimeios, assim como ocorre no esquema RM-ODP.
Manutenibilidade atendida pela viso lgica por tratar da modelagem das regras de negcio em componentes e modelos de dados.
Flexibilidade tratada pela viso do sistema pronto que possui os aspectos relacionados ao ps-implantao, como incorporao de novas funcionalidades e correo de defeitos.
Testabilidade tratada pela viso conceitual que trata do modelo do processo de negcio e sua conformidade com o plano estratgico da empresa.
O esquema de Zachman possui vises em todos os fatores de qualidade do modelo de McCall. Porm, a descrio das suas vises so genricas o suficiente para garantir esta abrangncia, o que no significa que este esquema seja o mais adequado por possuir maior cobertura.
87
IME USP
Outros modelos de qualidade podem ser utilizados para verificar a aderncia dos atributos de qualidade na arquitetura. Um deles o Software Architecture Analysis Method SAAM [Bass98], um mtodo de anlise arquitetural que verifica os atributos de qualidade atendidos pela arquitetura e determina o grau no qual eles so atendidos.
5.3. Consideraes Finais sobre as Comparaes

Em geral, as vises preocupam-se mais com a definio da arquitetura do que com a sua modificao e evoluo. Subentende-se que uma arquitetura bem preparada para oferecer uma boa a manutenibilidade tende a facilitar a localizao de mudanas (para correo de defeitos ou incorporao de nova funcionalidade) com impacto mnimo nos outros componentes envolvidos. H sistemas que so simples em funcionalidade, mas que requerem alto esforo em segurana e integridade dos dados devido criticidade e sigilo das informaes de negcio. Os esquemas no so suficientes por si s. Eles dependem do domnio da aplicao. O esquema RM-OPD, por exemplo, possui aspectos muito adequados para os fatores de portabilidade e interoperabilidade, mas no possui uma viso representativa para o fator usabilidade. Esta caracterstica aceitvel pois o esquema tem o foco em sistemas distribudos. J o esquema de Zachman, ainda que seja o mais abrangente tanto no processo de desenvolvimento quanto nos fatores de qualidade que so descritos em suas vises, ele bastante genrico, tornando sua utilizao complexa e burocrtica, principalmente nos domnios de aplicao bem definidos. Em contrapartida, as vises apresentadas pelos esquemas OMT e Booch so menos abrangentes, mas so mais simples de aplicar. Isto implica que, para domnios de aplicao com pouca complexidade ou com maior maturidade em relao ao processo de negcio, estes esquemas so bastante adequados. Outra considerao que vale ressaltar que tais esquemas menos abrangentes podem ser utilizados dentro dos esquemas mais abrangentes, como subvises, conforme abordado no item 4.4.
88
IME USP
Portanto, ao se escolher um esquema de vises para apoiar a definio da arquitetura, deve-se levar em conta alguns critrios, tais como:

A complexidade e a maturidade do domnio de aplicao; A relao custo-benefcio, considerando o conhecimento da equipe em relao ao processo de desenvolvimento de sistemas e aos princpios de qualidade;
Suporte s fases do processo de desenvolvimento, considerando a fase onde o detalhamento e a especificao se fazem mais necessrias;
Impacto nas qualidades desejadas, considerando as caractersticas da aplicao que esto mais relacionadas aos requisitos no funcionais.
5.4. Concluso do captulo

As comparaes entre os esquemas de vises apresentadas neste captulo esto baseadas em dois nveis de abrangncia:
sua localizao no processo de desenvolvimento que dita o nvel de complexidade do esquema;
sua aderncia aos fatores de qualidade que dita o quanto a viso atende aos requisitos implcitos do sistema.
Neste captulo, a localizao das vises no processo de desenvolvimento considerou as fases do modelo cascata, conforme figura 2.1 do captulo 2. Embora tais fases sejam lineramente sequenciais, a arquitetura deve considerar que requisitos so mutveis, por natureza. Assim sendo, vrias verses podem ser estabelecidas considerando que o modelo cascata repetido em cada ciclo que finaliza uma verso, como ocorre no modelo espiral [Pressman01]. importante para a definio da arquitetura saber em qual momento do ciclo de desenvolvimento os aspectos definidos em uma viso devem ser considerados, pois a seleo do esquema de viso deve ser determinado pelo propsito da arquitetura. Seguindo o modelo de qualidade de McCall, as vises so comparadas atravs dos fatores de qualidade, mostrando seu impacto na definio da arquitetura.
89
IME USP
Qualquer que seja o esquema de viso utilizado para definir a arquitetura de um sistema, os atributos de qualidade devem ser considerados conforme a exigncia do domnio de aplicao. As tcnicas de abstrao, encapsulamento, modularizao, acoplamento e coeso, diviso e conquista e distino entre interface e implementao esto presentes em todas as vises.
90
IME USP
6. Concluses e Trabalhos Futuros

A arquitetura de software uma disciplina recm estabelecida, em ascendncia no mercado e nas reas acadmicas, na qual tm sido feitos muitos estudos com o objetivo de melhorar a qualidade dos produtos de software que so construdos. Sua definio consiste em quebrar a complexidade do problema em partes menores, denominadas componentes ou subsistemas, explicitando o relacionamento entre estas partes. Os componentes podem ser pedaos de cdigo, um sistema externo, elementos de hardware, protocolos de comunicao, entre outros. Isto significa que arquitetura de software representa muito mais do que a infra-estrutura tcnica necessria para desenvolver sistemas, como o entendimento comum hoje em dia. Sua importncia surge pois:
Possui um nvel de abstrao da complexidade do problema que facilita a comunicao entre os participantes do desenvolvimento do sistema;
Antecipa decises de projeto, estabelecendo as restries do ponto de vista do negcio e do ponto de vista tcnico;
Incentiva o reuso atravs da utilizao de componentes prontos e tambm atravs dos estilos e padres arquiteturais.
Os estilos de arquitetura oferecem muitos recursos que orientam as atividades do arquiteto, descrevendo domnios de aplicao, tipos e padres para o particionamento dos componentes e motivaes para o reuso. Estes recursos e tambm as definies relacionadas arquitetura de referncia e modelos de referncia indicam que a definio de uma arquitetura no precisa partir do zero. Ela pode e deve utilizar tais recursos e tcnicas como ponto de partida. Cada pessoa envolvida no processo de desenvolvimento do sistema desempenha um papel especfico o qual fornece um tipo de contribuio, caracterizando uma forma diferente de observao do sistema. Conseguir capturar e representar cada uma destas contribuies um grande desafio. As vrias perspectivas consistem nas vises da arquitetura, cada qual ressaltando em detalhes os aspectos de seu interesse e escondendo os demais, complementando-se umas as outras de modo a obter a representao do todo. As vises so um meio til para garantir que a arquitetura definida para um sistema pode ser observada atravs de diferentes perspectivas, sem lacunas na especificao. O objetivo
91
IME USP
principal da arquitetura de software satisfazer os requisitos necessrios para atender o negcio. Tais requisitos ocorrem em momentos distintos durante o desenvolvimento do sistema. Por isso, importante saber em qual fase do processo a viso de um esquema deve ser utilizada. Por outro lado, a arquitetura deve satisfazer os requisitos necessrios para o sistema. Dentre os requisitos, h aqueles que so identificados pelos participantes que so responsveis pelo negcio e desejam uma soluo computacional para o problema que enfrentam. Estes requisitos esto ligados s funcionalidades que o sistema deve atender. Porm, h outros requisitos implcitos, denominados requisitos no funcionais ou atributos de qualidade que devem ser identificados e compreendidos pelos arquitetos, analistas e projetistas de sistemas. Existem ainda, na imatura rea de arquitetura de software, vrias questes em aberto para serem respondidas e que esto relacionadas s vises, entre elas:
possvel estabelecer critrios mais abrangentes e mais detalhados que direcionam a escolha de um dos esquemas de vises?
A quais categorias de domnios de aplicao cada esquema de vises mais atende, considerando os tipos de viso do item 4.1.3, ou seja, a viso de complemento e a viso de compreenso?
possvel estabelecer um roteiro para definir a arquitetura de software utilizando os esquemas de vises e considerando um dado domnio de aplicao?
Como os esquemas de vises podem ser utilizados para avaliar a arquitetura definida para um sistema e quais os indicadores e as medies que melhor verificam a aderncia dos atributos de qualidade nesta arquitetura?
possvel relacionar as vises com as linguagens de definio de arquitetura (architecture description language ADL), uma vez que as vises significam abstraes sob diferentes perspectivas?
possvel mapear os esquemas de vises a outros modelos de processo de desenvolvimento de sistemas?
92
IME USP
Possveis respostas para estas questes significam discusses para trabalhos futuros. No entanto, importante que este trabalho de dissertao pode subsidiar outras duas frentes de estudo: 1. Definio de um modelo de maturidade e capacidade especfico para arquitetura, estabelecendo um processo para definir arquitetura com metas de qualidade; e 2. Especializao das atividades dos arquitetos de software, formalizando sua profisso atravs de treinamentos tericos e prticos.
93
IME USP
Anexo 1 Framework de Zachman

O propsito do framework de Zachman [Zachman97] fornecer uma estrutura bsica que suporta a organizao, acesso, integrao, interpretao, desenvolvimento, gerenciamento e mudanas de um conjunto de representaes arquiteturais dos sistemas de informao da empresa. Como mostra a figura A-1 a seguir, o eixo vertical fornece as vises potenciais para o incio das atividades que o arquiteto deve considerar. O eixo horizontal pode ser interpretado como fornecedor de uma taxonomia genrica de interesses.
94
IME USP
ENTERPRISE ARC H ITEC TU RE - A FRAM EW O RK

DATA
What
TM
FUNCTIO N
List of Processes the Business Performs
How
NET W ORK
Where
PEO PLE
List of Organizations Important to the Business
Who
T IME
When
MOT IVATIO N
Why SCOPE (CO NT EXTUAL)
SCO PE (CONT EXTUAL)
List of Things Important to the Business
List of Locations in which the Business Operates
List of Events Significant to the Business
List of Business G oals/Strat
Planner
ENTITY = Class of Business Thing
Function = Class of Business Process
Node = M ajor Business Location
People = Major Organizations e.g. W ork Flow M odel
Time = Major Business Event
Ends/M eans=Major Bus. Goal/ Critical Success Factor
Planner
ENTERPRISE MODEL (CONCEPT UAL)
e.g. Semantic Model
e.g. Business Process Model
e.g. Business Logistics System
e.g. Master Schedule
e.g. Business Plan
ENTERPRISE MODEL (CONCEPT UAL)
Owner
Ent = Business Entity Reln = Business Relationship e.g. Logical Data Model
Proc. = Business Process I/O = Business Resources e.g. Application Architecture
Node = Business Location Link = Business Linkage e.g. Distributed System Architecture
People = Organization Unit W ork = W ork Product
Time = Business Event Cycle = Business Cycle
End = Business Objective M eans = Business Strategy e.g., Business Rule Model
Owner
SYSTEM MODEL (LO GICAL)
e.g. Human Interface Architecture
e.g. Processing Structure
SYSTEM MODEL (LO GICAL)
Designer TECHNOLO GY MODEL (PHYSICAL)
Ent = Data Entity Reln = Data Relationship e.g. Physical Data Model
Proc .= Application Function I/O = User Views e.g. System Design
Node = I/S Function (Processor, Storage, etc) Link = Line Characteristics e.g. Technology Architecture
People = Role W ork = Deliverable e.g. Presentation Architecture
Time = System Event Cycle = Processing Cycle
End = Structural Assertion Means =Action Assertion
Designer TECHNOLOGY MODEL (PHYSICAL)
e.g. Control Structure
e.g. Rule Design
Builder DETAILED REPRESENTAT IONS (O UT -OFCONTEXT ) SubContractor FUNCTIONING ENT ERPRISE
Ent = Segment/Table/etc. Reln = Pointer/Key/etc.
Proc.= Computer Function I/O = Data Elements/Sets e.g. Program
Node = Hardware/System Software Link = Line Specifications e.g. Network Architecture
People = User W ork = Screen Format
Time = Execute Cycle = Component Cycle e.g. Timing Definition
End = Condition Means = Action e.g. Rule Specification
Builder
e.g. Data Definition
e.g. Security Architecture
DETAILED REPRESENTATIO NS (O UT-OF CO NTEXT )

SubContractor
Ent = Field Reln = Address
Proc.= Language Stmt I/O = Control Block e.g. FUNCTION
Node = Addresses Link = Protocols e.g. NETW ORK
People = Identity W ork = Job
Time = Interrupt Cycle = Machine Cycle e.g. SCHEDULE
End = Sub-condition Means = Step

e.g. STRATEGY
e.g. DATA
e.g. O RGANIZATIO N
FUNCT IO NING ENT ERPRISE
John A. Zachman, Zachman International (810) 231-0531
Figura A-1 Framework de Zachman

95
IME USP
Referncias Bibliogrficas
[Astudillo98] [Bass98] [Blair97] [Beitz97] Hernn Astudillo, Stuart Hammer; Understanding the Architects Job, Software Architecture Workshop of OOPSLA98, 1998. Len Bass, Paul Clements, Rick Kazman; Software Architecture in Pratice, Addison Wesley, 1998. Gordon Blair, Jean-Bernard Stefani; Open Distributed Processing and Multimedia, Addison Wesley, 1997. Ashley Beitz, Andrew Berry, Andrew Lister, Kerry Raymond; Introduction to Open Distributed Processing, CRC for Distribuited Systems Technology, Centre for Information Technology Research, University of Queensland, Austrlia,1997. Douglas Bennett; Designing Hard Software: The Essential Tasks, Manning, 1996. Grady Booch; Oriented Object Design Benjamin/Cummings Publishing Company, 1991. with Applications,
[Bennett96] [Booch91] [Booch98] [Bosch99a]
Grady Booch, James Rumbaugh, Ivar Jacobson; The Unified Modeling Language User Guide, Addison Wesley, 1998. Jan Bosch; Evolution and Composition of Reusable Assets in Product-Line Architectures: A Case Study, University of Karlskrona Ronneby Sweden, 1999. www.dcs.ed.ac.uk/home/pxs/product-line.html Jan Bosch; Product-Line Architectures Industry: A Case Study, University of Karlskrona Ronneby Sweden, 1999. www.dcs.ed.ac.uk/home/pxs/product-line.html
[Bosch99b]
[Buschmann96] Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, Michel Stal, A System of Patterns. Pattern-Oriented Software Architecture, Wiley, 1996. [Clements96] Paul Clements, Linda Northrop; Software Architecture: An Executive Overview, CMU/SEI-96-TR-003, Maro de 1996. www.sei.cmu.edu/architecture/projects.html [DSouza98] [DeBaud99] Desmond Francis DSouza, Alan Cameron Wills; Objects, Components and Frameworks with UML: The Catalysis Approach, Addison Wesley, 1998. Jean-Marc DeBaud, Klaus Schimid; A Systematic Approach to Derive the Scope of Software Product Lines, Lucent Tecnologies EUA/Fraunhofer Institute for Experimental Software Engineering Alemanha. ACM, 1999. David M.Dikel, David Kane, James R. Wilson; Software Architecture: Organizacional Principles and Patterns, Prentice Hall, 2001.
[Dikel01]
96
IME USP
Vises em Arquitetura de Software
[Gamma95]
Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Grady Booch (Designer), Design Patterns Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995. David Hay; The Zachman Framework: An Introduction, Essential Estrategies, Inc., 1997. www.essentialstrategies.com/publications David Hay; The Zachman Framework: Objects and Business Views, Essential Estrategies, Inc., 1997. www.essentialstrategies.com/publications
[Hay97a]
[Hay97b]
[Hofmeister00] Christine Hofmeister, Robert Nord, Dilip Soni; Applied Software Architecture, Addison Wesley, 2000. [IEEE Std 830] IEEE Recommended Practice for Software Requirements Specifications; IEEE Computer Society, 1998. [ISO/IEC9126] [Jacobson92] ISO/IEC-9126 Information Technology Software product evaluation Quality characteristics and guidelines for their use; 1991 (E). Ivar Jacobson, Magnus Christerson, Patrik Jonsson, Gunnar vergaard; Object-Oriented Software Engineering: A Use-Case Driven Approach, Addison Wesley, 1992. Ivar Jacobson, Maria Ericsson, Agneta Jacobson; The Object Advantage: Business Process Reengineering with Object Technology, Addison Wesley, 1995. Ivar Jacobson, Martin Griss, Patrik Jonsson; Software Reuse: Architecture, Process and Organization for Business Success, Addison Wesley, 1997. Ivar Jacobson, Grady Booch, James Rumbaugh; The Unified Software Development Process, Addison Wesley, 1998. Mehdi Jazayeri, Alexander Ran, Frank van der Linden; Software Architecture for Product Families, Addison Wesley, 2000. Phillipe Kruchten; The Rational Unified Process: An Introduction. Second Edition, Addison Wesley, 2000. www.rational.com/whitepapers [Kruchten95] [Lim98] [McCall85] Philippe Kruchten; The 4+1 (RUP) View Model of Architecture, Rational Software Corp, 1995. Wayne C. Lim; Managing Software Reuse, Prentice Hall, 1998. James A. McCall, D. Markham, M. Stosick and R. McGindly, "The Automated Measurement of Software Quality," Tutorial on Software Quality Assurance A Practical Approach, ed. T.S. Chow, IEEE Computer Society Press (pp. 388 394), New York, 1985. James A. McCall; Quality Factors, Encyclopedia of Software Engineering, John Wiley & Sons (pp 959-969), 1994.
[Jacobson95]
[Jacobson97] [Jacobson98] [Jazayeri00] [Kruchten00]
[McCall94]
97
IME USP
[Orfali98] [Pfleeger98] [Pressman01] [Raymond97]
Robert Orfali, Dan Harkey; Client/Server Programing with Java and CORBA. Second Edition; Wiley, 1998. Shari Lawrence Pfleeger; Software Engineering: Theory and Pratice, Prentice Hall, 1998. Roger Pressman; Software Engineering: A Practitioners Approach, Fifth Edition, McGraw Hill, 2001. Kerry Raymond; Reference Model of Open Distributed Processing (RMODP): Introduction, CRC for Distribuited Systems Technology, Centre for Information Technology Research, University of Queensland, Austrlia, 1997. Reference Model of Open Distributed Processing, ITU-T X.901 | NA/IEC 10746-1 ODP Reference Model Part 1 Overview, 1995. James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, William Lorenson; Object-Oriented Modeling and Design; Prentice Hall, 1991. James Rumbaugh, Ivar Jacobson, Grady Booch; The Unified Modeling Language Reference Manual, Addison Wesley, 1998. Marc T. Swell, Laura M. Swell; The Software Architects Profession: An Introduction, Prentice Hall, 2001. Mary Shaw, David Garlan; Software Architecture. Perspectives on an Emerging Discipline, Prentice Hall, 1996. Clemens Szyperski; Component Software: Beyond Object-Oriented Programming, Addison-Wesley, 1998. Bernard Witt, F. Terry Baker, Everett Merritt; Software Architecture and Design: Principles, Models and Methods, Van Nostrand Reinholt Computer Library (VNR), 1994. John Zachman; A Framework for Information Systems Architecture, IBM Systems Journal, vol 26, no. 3, 1987. John Zachman; Enterprise Architecture: The Issue of the Century, Database Programming and Design Magazine, Maro de 1997. The Product Line Practice (PLP) Iniciative. Software Engineering Institute SEI, Carnegie Mellon University USA. www.dcs.ed.ac.uk/home/pxs/product-line.html Software Architecture Papers. Software Engineering Research Laboratory SERL, University of Colorado USA. www.cs.colorado.edu/users/serl/arch/Papers.html IEEE Recommended Practice for Architectural Description of SoftwareIntensive Systems (IEEE Std 1471). www.pithecanthropus.com/~awg/
[RM-ODP95] [Rumbaugh91]
[Rumbaugh98] [Sewell01] [Shaw96] [Szyperski98] [Witt94]
[Zachman87] [Zachman97] [www1]
[www2]
[www3]
98
IME USP
[www4] [www5] [www6] [www7] [www8] [www9] [www10]
The Martin Fowler Articles. http://martinfowler.com/articles.html Borland/Visigenic VisiBroker. www.visigenic.com/prod Object Management Group OMG. www.omg.org Zachman Institute for Framework Architecture (ZIFA). www.zifa.com TOGAF The Open Group Architectural Framework Version 7. www.opengroup.org/architecture/togaf TAFIM Technical Architecture Framework for Information Management. www-library.itsi.disa.mil/tafim/tafim.html IBM WebSphere Software Plataform www.ibm.com/websphere
99

Visões em Arquitetura de Software: Ane Cristina Varoto

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Visões em Arquitetura de Software: Ane Cristina Varoto

Uploaded by

Copyright:

Available Formats

Vises em arquitetura de software

Ane Cristina Varoto

rea de Concentrao: Engenharia de Software Orientador: Prof. Dr. Hernn Astudillo

So Paulo, 14 de maro de 2002.

Vises em arquitetura de software

So Paulo, 14 de maro de 2002.

2.3.1. 2.3.2. 2.3.3. 2.4. 2.4.1. 2.4.2. 2.5.

ARQUITETURA DE SOFTWARE NO PROCESSO DE DESENVOLVIMENTO DE SISTEMAS 12

ESTILOS DE ARQUITETURA ......................................................................................... 25

PRINCIPAIS ESQUEMAS DE VISES EM ARQUITETURA DE SOFTWARE ....................... 44

ALGUNS OUTROS ESQUEMAS DE VISES MENOS DIFUNDIDOS ................................. 62

ANEXO 1 FRAMEWORK DE ZACHMAN ....................................................................... 94 REFERNCIAS BIBLIOGRFICAS .................................................................................. 96

Vises em arquitetura de software

Vises em arquitetura de software

1.3. Organizao e Audincia do Documento

Vises em arquitetura de software

Vises em arquitetura de software

Vises em arquitetura de software

Vises em arquitetura de software

2.1. Conceitos de Arquitetura de Software

Vises em arquitetura de software

2.2. O Processo da Arquitetura de Software

Vises em arquitetura de software

Criao ou seleo de uma arquitetura, considerando:

desenvolvedores devem se restringir s estruturas e protocolos definidos

Vises em arquitetura de software

Analista de requisitos: identificador de requisitos funcionais e no funcionais do sistema;

2.3. A Importncia da Arquitetura

Vises em arquitetura de software

2.3.2. Arquitetura e a Antecipao de Decises de Projeto

Vises em arquitetura de software

2.3.3. Arquitetura e o Reuso

Vises em arquitetura de software

2.4. Arquitetura de Software no Processo de Desenvolvimento de Sistemas

Vises em arquitetura de software

Vises em arquitetura de software

Engenharia de Requisitos Anlise

Vises em arquitetura de software

2.4.2. Influncias da Arquitetura Desenvolvimento de Sistemas

Vises em arquitetura de software

Vises em arquitetura de software

Vises em arquitetura de software

Figura 2.4 Influncia da Arquitetura nas Demais Fases do Desenvolvimento de Sistemas

2.5. Concluso do Captulo

Antecipar decises de projeto, aliviando as incertezas e riscos no momento da implementao;

Vises em arquitetura de software

Vises em arquitetura de software

3. Tcnicas em Arquitetura de Software

Vises em arquitetura de software

Vises em arquitetura de software

3.1. Arquitetura para um Sistema e Arquiteturas de Referncia

3.1.1. Modelo de Referncia

3.1.2. Estilo de Arquitetura

Vises em arquitetura de software

3.1.3. Arquitetura de Referncia

3.1.4. Diferenas entre os Conceitos

Modelo de referncia Arquitetura do sistema

Arquitetura de referncia Estilo de arquitetura

Vises em arquitetura de software

Vises em arquitetura de software

A rquitetura de S oftware: V is iB rok er

E s tilo de arquitetura: B rok er

A rquitetura de Refernc ia: CORB A