ANÁLISE E PROJETO DE SISTEMAS 3 (ARQUITETURA) Unidade01

116 Anlise e projeto de sistemas 3 (Arquitetura) | Unidade 01
UNIDADE 1 CONTEXTO DA ARQUITETURA DE SOFTWARE

MDULO 1 O QUE ARQUITETURA DE SOFTWARE?
01
1 - ANTES DE INICIAR
Assim como na disciplina de Anlise e Projeto de Sistema 2, para realizarmos as atividades desta
disciplina, iremos precisar de um software de modelagem. H vrias opes gratuitas, como o software
livre Visual Paradigm. Outro software similar o Violet UML Editor, tambm gratuito.
Observaes:
1: caso voc j tenha feito a disciplina de Anlise e Projeto de Sistema 2, provavelmente voc j
utilizou um software para modelagem UML. Nesse caso, no ser necessrio instalar um novo
software. Basta voc utilizar o mesmo que j vinha utilizando.
2: no escopo desta disciplina realizar um treinamento de Visual Paradigm, Violet UML, Eclipse ou
qualquer outra ferramenta de UML. Para tanto, caso voc tenha dificuldade no uso dessas
ferramentas, pesquise no Youtube ou Google vdeos ou manuais de como utiliz-las.
Para que voc possa aproveitar ao mximo essa disciplina, necessrio o conhecimento prvio dos
seguintes assuntos:
Orientao a objeto: conceitos como classe, mtodo, evento, objeto, chamada, herana e
outros so fundamentais para a diagramao UML.
UML: Conhecer os diagramas existentes, sobretudo o diagrama de classe e de componentes

ser importante ao longo de nossa disciplina.
Esses contedos fazem parte do seu curso, ento aproveite para compreend-los bem!
02
2 - OS ENTENDIMENTOS FUNDAMENTAIS SOBRE A ARQUITETURA

Nos ltimos anos estamos presenciando o crescimento de uma disciplina imprescindvel para a
engenharia de software conhecida como Arquitetura de Software. Arquiteto de Software e Lder de
Arquitetura so papeis que esto cada vez mais presentes na indstria de software. Existe inclusive uma
associao internacional sobre arquitetura de software. Tudo bem, mas o que arquitetura de
software?
justamente a arquitetura de software que vamos explorar nesta disciplina.
2015 - AIEC - Associao Internacional de Educao Continuada
1
Em particular, sobre as principais questes no que se refere ao design e a tecnologia a serem

consideradas na construo de sistemas que processam mltiplas solicitaes simultneas de
usurios e outros sistemas de software. O objetivo descrever os elementos essenciais de
conhecimentos e habilidades fundamentais que so necessrios para ser um arquiteto de software na
indstria de tecnologia da informao (TI).
Ao falarmos de arquitetura, a primeira analogia que vem na mente a construo de edifcios. Os livros
de engenharia de software normalmente usam esta analogia para motivar as fases do ciclo de vida do
software tradicional.
Em uma concepo simplificada da arquitetura, os requisitos para um edifcio so coletados, um projeto

criado para atender a estes requisitos, o desenho refinado para produzir modelos elaborados. A
construo baseia-se nas plantas, e a estrutura resultante ento ocupada e usada.
Associao internacional
Voc pode conhecer a associao internacional sobre arquitetura de software acessando o site
http://www.iasahome.org/web/home/home).
03
Teoricamente, quando falamos de software, alguns passos podem ser previstos:
os requisitos so especificados,
um projeto de alto nvel criado,
algoritmos detalhados so desenvolvidos com base no design,
o cdigo escrito para implementar os algoritmos
finalmente, o sistema est implantado e usvel.
Para conceituarmos a arquitetura de software vamos recorrer ao IEEE. O motivo desta escolha o
propsito da criao do padro ISO/IEEE 1471-2000. Este padro tem justamente o objetivo de ajudar
no consenso entre autores, estudantes e profissionais sobre o que e para que serve arquitetura de
software.
A definio de arquitetura de software do IEEE, a qual adotaremos ao longo de nossa disciplina, a

seguinte:
Arquitetura de Software a organizao fundamental de um sistema, representada por seus

componentes, seus relacionamentos com o ambiente, e pelos princpios que conduzem seu design e
evoluo.
2
IEEE-1471
O IEEE Computer Society elaborou o padro IEEE-Std-1471-2000, que um conjunto de prticas
recomendadas para descrever arquiteturas de sistemas de informao.
04
Arquitetura de software envolve a integrao de metodologias e modelos de desenvolvimento de

software, mas no podemos confundi-la com metodologias para a anlise e projeto de sistema. A
arquitetura de software um corpo de mtodos e tcnicas que nos ajuda a gerenciar as complexidades
do desenvolvimento de software.
Evoluo de software o fenmeno de mudana que ocorre no software ao longo dos anos e das
mltiplas verses, desde seu incio at o completo abandono do sistema.
Essa mudana no est s relacionada com a adio e remoo de funcionalidades, mas tambm est
relacionada com a manuteno do cdigo ao longo do ciclo de vida do software. Essa manuteno pode
melhorar ou deteriorar tanto atributos externos de qualidade do software, os quais so percebidos
pelos usurios (desempenho, tolerncia a falhas, disponibilidade), quanto os atributos internos de
qualidade do software, os quais so percebidos pelos envolvidos no desenvolvimento (testabilidade,
legibilidade, reusabilidade).
Uma vez que um dos principais objetivos de se projetar uma arquitetura o de atingir a qualidade
desejada pelos interessados no sistema, se torna claro o papel da arquitetura em conduzir a evoluo
do software, uma vez que ela conter decises que contribuiro para a preservao da qualidade do
sistema durante seu ciclo de vida.
Existem trs entendimentos fundamentais sobre a arquitetura que ajudam a contextualiz-la em relao
engenharia de software:
1 Toda a aplicao tem uma arquitetura;
2 - Toda aplicao tem pelo menos uma arquitetura;
3 - Arquitetura no uma fase do desenvolvimento.
1 Toda a aplicao tem uma arquitetura;
Voltando a nossa analogia de um prdio, evidente que todo edifcio tem uma arquitetura. No
significa dizer que esta arquitetura funcional e que deixa os construtores orgulhosos, mas mesmo
assim, todo edifcil, seja ele feio ou bonito tem uma arquitetura.
3
O mesmo pode ser observado com os softwares. Atravs desta observao alguns questionamentos
so levantados: De onde vem a arquitetura desta aplicao? Quais as propriedades desta arquitetura?
Esta arquitetura boa ou ruim?
Mesmo com estes questionamentos inegvel que um software possui uma arquitetura.
2 - Toda aplicao tem pelo menos uma arquitetura;
O segundo conceito flui a partir do primeiro, em virtude de decises realizadas ao longo do projeto ou
de necessidades especfica possvel que uma aplicao no tenha uma nica arquitetura. Isso quer
dizer que possvel que uma aplicao tenha uma mistura de diferentes arquiteturas.
3 - Arquitetura no uma fase do desenvolvimento.
A Arquitetura de software refere-se essncia de uma aplicao, as principais decises de design, s

principais abstraes que caracterizam uma aplicao.
Em uma compreenso simplista, tradicional, e imprecisa, a arquitetura um produto especfico de

uma determinada fase do processo de desenvolvimento. Mas para que esta premissa seja atendida
seria necessrio conhecer todos os requisitos do projeto. Assim, se pensarmos na arquitetura como
4
um produto de uma fase limitando o seu momento de atuao, pricipalmente no incio de projeto,
estamos restringindo a arquitetura a apenas algumas decises de design. Em muitos casos, estas
decises necessitam ser violadas por necessidades posteriores identificadas ao longo do projeto.
Assim, temos que encarar a arquitetura de software como uma atividade que permeia todo o
processo de desenvolvimento.
05
3 - ARQUITETURA E SEU PAPEL NO DESENVOLVIMENTO DE SOFTWARE

Aps entendermos o conceito da arquitetura de software e de aprofundarmos nosso entendimento nos
conceitos fundamentais, vamos entender qual o papel da arquitetura de software em um contexto mais
amplo do desenvolvimento de sistemas e como, em uma abordagem mais moderna, as demais
disciplinas podem se beneficiar da arquitetura.
3.1 Requisitos
A arquitetura deve comear no incio de qualquer atividade de desenvolvimento de software. Noes de

estrutura, design e soluo so bastante apropriadas durante a atividade de anlise de requisitos.
Entretanto, a viso acadmica tradicional de anlise de requisitos e especificao de que a

atividade, e o documento de requisitos resultante, deve permanecer imaculada por qualquer
considerao de um projeto que pode ser usado para satisfazer os requisitos identificados.
De fato, alguns pesquisadores na comunidade requisitos so bastante radicais sobre este ponto.
Agora, imagine se os invetores das mquinas de lavar roupa levassem isso ao p da letra. Se
simplesmente automatizasse a soluo manual dos sculos passados, teramos mquinas que batiam
roupas nas pedras na beira do rio. Assim, fcil perceber que ter noes de estrutura e design um
ponto crtico durante a fase de anlise de requisitos.
06
Considere mais uma vez a analogia com os edifcios. Quando decidimos que precisamos de uma nova
casa ou apartamento, ou uma reforma em nossa moradia atual, iniciamos um processo de raciocnio
sobre as nossas necessidades, independentemente de como eles podem ser satisfeitos. Ns pensamos
na quantidade de quartos, no estilo de janelas, como ser a iluminao e assim por diante. Temos
experincia com habitao, e esta experincia nos permite raciocinar rapidamente e articuladamente
sobre nossos desejos.
Entretanto, sem o conhecimento necessrio, possvel fazermos anlises de custo e cronograma para
atender s necessidades? A resposta no.
5
Assim com o software. Especificao de requisitos de forma independente de qualquer preocupao

com o modo como esses requisitos podem ser atendidos leva dificuldade na avaliao da praticidade,
prazo para o desenvolvimento ou custo do projeto.
Vendo o que pode ser feito em outros sistemas, por outro lado, que
tipo de interfaces com o usurio est disponvel, o que o novo hardware
capaz de fazer, que tipo de servios podem ser prestados, pode
facilitar a implementao e pode servir para nortear a anlise e
requisitos.
07
3.2 Design
Design , por definio, a atividade que cria a arquitetura do software.
Esta arquitetura o resultado de um conjunto de decises de design. Estas decises abrangem questes
que surgem ao longo do processo de desenvolvimento.
Desta forma, so 3 as caractersticas que temos que levar em considerao:
1. Se considerarmos a fase de projeto tradicional de Design e Arquitetura no devemos encar-

la como um momento exclusivo, ou seja, o "lugar ou o tempo" quando a arquitetura do
sistema desenvolvida.
2. Como as principais decises de arquitetura so tomadas ao longo do processo de

desenvolvimento, o design deve ser encarado como um aspecto tambm de outras atividades
do desenvolvimento.
3. Um rico repertrio de tcnicas de design necessrio para auxiliar o arquiteto a tomar as

decises de design que devem compor a arquitetura. Riscos para o deploy, segurana,
escolhas de componentes open-souce ou proprietrio so aspectos que tambm devem ser
considerados para a definio da arquitetura.
08
3.3 Implementao
A tarefa de implementao criar cdigo-fonte executvel que seja fiel arquitetura e que
desenvolva plenamente todos os detalhes da aplicao.
6
No entanto, temos que considerar alguns aspectos adicionais ao longo da implementao.
Primeiro, a atividade de implementao pode modificar a arquitetura. Se as principais decises de

design so feitas ao trabalhar com o cdigo fonte, eles so parte da arquitetura tanto quanto qualquer
deciso principal feita muito mais cedo no processo.
Em segundo lugar, no podemos presumir que a arquitetura concluda antes do incio da

implementao. Na verdade, pode haver reviso da arquitetura enquanto o cdigo desenvolvido. O
que devemos considerar manter todas as decises registradas. Ou seja, a atividade de implementao
no pode virar as costas para as decises anteriores. As modificaes realizadas durante a fase de
implementao devem ser documentadas como parte da arquitetura do aplicativo.
No estamos falando, entretanto, que implementao no deve respeitar as decises arquiteturais

anteriores. A palavra de ordem para a criao da aplicao que ela deve ser fiel arquitetura.
Assim, para melhor entendermos, o que devemos levar em

considerao que a implementao deve seguir os elementos
estruturais encontradas na arquitectura e que todo o cdigo de fonte
corresponde a vrias partes da arquitetura.
Desta forma, o cdigo fonte no deve:
utilizar novos elementos que no tenham um correspondente na arquitetura definida.
conter novas conexes entre elementos da arquitetura que no so encontradas na

arquitetura.
09
3.4 Anlise e Teste
Anlise e os testes so atividades realizadas para avaliar a qualidade de um artefato.
Mas voc pode se perguntar: ento estas atividades devem ser realizadas apenas ao final do projeto?
O que deve ser levado em considerao que uma das virtudes de realizar a anlise antes da existncia
cdigo a economia gerada:
Quanto mais cedo for detectado um erro, menor o custo agregado para a correo.
7
Vamos avaliar inicialmente os benefcios da anlise. A arquitetura de um aplicativo pode ser examinada
considernado:
sua consistncia,
exatido,
e sua capacidade de atendimento aos requisitos no funcionais.
Se a arquitetura sobre a qual a implementao baseada de alta qualidade, a probabilidade de a

implementao ser de alta qualidade significativa.
Como um artefato formal, o modelo de arquitetura (documento que descreve a arquitetura do

software) pode ser examinado em relao a sua coerncia interna e correo: a verificao sinttica do
modelo pode identificar, por exemplo, componentes incompatveis, especificao incompleta das
propriedades, e padres de comunicao indesejveis. De forma mais significativa, a anlise de fluxo
pode ser usada para detectar falhas de segurana.
10
Em segundo lugar, o modelo de arquitetura pode ser examinado por coerncia com os requisitos. Ou
seja, os requisitos e a arquitetura devem ser consistentes entre si.
Em terceiro lugar, o modelo de arquitetura pode ser utilizado na determinao de estratgia de teste a
ser aplicada ao cdigo-fonte. Como a arquitetura fornece o projeto para o cdigo-fonte, a coerncia
entre elas essencial. Desta forma, a arquitetura serve como fonte de informaes para a definio de
testes baseados nas especificaes.
Na mesma linha, a arquitetura pode proporcionar um meio de antecipar os testes gerando reduo de
custos e contribuindo para diminuir o cronograma do projeto. Por exemplo, se um componente
especfico reutilizado em uma nova arquitetura, os testes unitrios podem ser reduzidos se a anlise
da arquitetura confirma que o contexto e as condies de utilizao deste componente so as mesmas
(ou mais limitado) do que o uso anterior.
Como observado, um desenvolvimento focado na arquitetura fornece

uma variedade de novas e significativas oportunidades para avaliar e,
consequentemente, possibilitar a melhoria da qualidade dos sistemas.
11
4 - O ARQUITETO DE SOFTWARE
4.1- Quem o arquiteto de Software
8
Vimos o que a arquitetura de software, mas quem responsvel por definir esta arquitetura?
A resposta para esta pergunta simples: O arquiteto de software. Mas o perfil deste profissional, bem
como sua responsabilidade no to simples assim.
Um arquiteto de software algum capaz de unir mtodo, intuio e reutilizao a fim de definir a
arquitetura vivel para um determinado projeto de software.
Mtodo refere-se a um A intuio a capacidade de

conjunto de tcnicas que conceber, entender e aplicar Reutilizao refere-se
podem ser executadas vrias ideias sem necessariamente reutilizao de solues que
vezes para resolver um ser capaz de se comunicar ou foram mostrados bem
problema particular, ou explicar toda a lgica por trs sucedida no passado.
categoria de problema. delas.
12
A essncia do trabalho de um arquiteto de software ser capaz de aplicar e encontrar o equilbrio certo
entre estes trs "fontes" da arquitetura.
Assim podemos afirmar que o papel de um arquiteto de software de grande responsabilidade em um

projeto de software. At mesmo o sucesso do projeto vai ser influenciado diretamente pela soluo
arquitetnica empregada.
Em virtude da importncia e responsabilidade exercida por este profissional natural persarmos que
esse papel deve sempre ser exercido por algum que tenha autoridade e liderana. Entretanto, em
muitas organizaes de desenvolvimento de software a responsabilidade no acompanhada com
autoridade especfica. Desta forma, a fim de fazer o seu trabalho de forma eficaz, o arquiteto deve,
ento, encontrar uma outra maneira de exercer influncia e liderana.
Ele deve possuir uma srie de habilidades, tais como:
Designer de software;
Especialista de domnio;
Tcnico;
Especialista em padres;
Economista.
9
Designer de software
Um arquiteto de software deve ser um excelente designer de sistemas de software. Ele deve ser
capaz de reconhecer, reutilizar, ou criar solues de design eficazes e aplic-las de forma adequada.
Ele deve estar familiarizado com os estilos arquitetnicos fundamentais e padres que esto na base
da disciplina de arquitetura de software. Um arquiteto pode at ter alguns padres que fazem parte
de seu arsenal privado de ferramentas de design, acumulado ao longo do tempo. Por outro lado, um
arquiteto tambm deve ser capaz de reconhecer projetos ineficazes, estilos imprprios e padres, e
decises de design sem a flexibilidade adequada.
Especialista de domnio
Muitas organizaes de desenvolvimento de software produzir vrios sistemas dentro do mesmo

domnio de aplicao. Por exemplo, a Microsoft trabalha principalmente dentro do domnio de
aplicativos para desktop. O domnio principal do Google a disseminao de informao atravs da
Internet; j a Boeing e tem um extenso foco em sistemas embarcados; NASA sistemas espaciais.
Assim, quanto mais especialista em um domnio, melhor ser o arquiteto.
Tcnico
Um arquiteto de software deve saber que suas solues realmente vai funcionar quando for
desenvolvida. Assim, um arquiteto de software precisa garantir que a tecnologia de software
existente capaz de suportar a implementao da arquitetura definida. Um design bonito no intil
se no pode ser implementado.
Especialista em padres
As exigncias para a contratao de uma empresa de desenvolvimento esto cada vez mais rigorosas.
Por este motivo, crtico que um arquiteto tenha domnio dos padres de mercado. Por exemplo,
para poder ser contratada pelo governo americano uma empresa de desenvolvimento deve ser
certificada CMMI 5. Um arquiteto deve ter conhecimento deste padro.
Economista
Um grande designer de software no necessariamente um grande arquiteto de software. Um bom

arquiteto no pode se ater APENAS s melhores tcnicas, os seus desenhos devem ser sobretudo
realistas, economicamente vivel, tecnologicamente implementvel, e com o menor risco para o
projeto. Em outras palavras, um arquiteto deve ser mais do que apenas uma (grande) designer. Um
arquiteto deve elaborar uma arquitetura que efetivamente resolve o problema em questo,
respeitando simultaneamente as restries impostas ao projeto.
10
13
4.2- O que um arquiteto de software faz?
O trabalho de um arquiteto de software exige uma srie de habilidades. Assim como um designer de
software exige um talento especfico, um arquiteto vai gastar muito de seu tempo fazendo outras coisas.
H quatro tarefas que um arquiteto necessita executar independe do tipo de projeto, do seu nvel de
experincia, o tipo de organizao, do domnio do aplicativo, ou do segmento de indstria em que
trabalha. So elas:
Desenvolver estratgia do projeto
Um arquiteto talentoso ser capaz de produzir excelentes solues tcnicas para os problemas que
lhe forem apresentado. Mas, apesar de crtico para o trabalho de um arquiteto, isso no o bastante.
Um arquiteto deve ajudar a desenvolver uma estratgia vivel para o projeto. Uma estratgia que, se
implementada corretamente, resultar em um produto tecnicamente bom, mas tambm que agregue
valor para a organizao.
Design de sistemas
Uma parte central da definio de uma estratgia para o projeto definir a arquitetora para o
projeto. De posse das principais restries impostas pelo projeto, o arquiteto deve definir como os
desafios sero superados atravs de uma arquitetura robusta e flexvel.
Comunicao com os interessados
Durante o projeto de definir a estratgia para o projeto e fazer o design da arquitetura, o arquiteto
dever constantemente com os diferentes interessados pelo projeto. Entre os interessados incluem-
se os desenvolvedores, testadores, gerentes de diferentes nveis, clientes, lderes tcnicos e os
usurios.
Liderar
Um arquiteto deve tomar vrias decises que so fundamentais para o sucesso do projeto. Algumas
destas decises podem ser impopulares, mas ele deve garantir que os principais interessados
compraram esta deciso. Para que isso seja possvel imprescindvel que o arquiteto seja um lder.
Durante todo o projeto, o arquiteto deve colocar os interessem do projeto sobre os seus prprios
interesses e liderar atravs de exemplo.
No cumprimento destas tarefas, o arquiteto ter que aplicar, combinar e at aprimorar o conjunto de
habilidades descritas na seo anterior.
11
14
5 - CONCEITOS BSICOS
Quando tratamos da arquitetura, uma srie de termos e conceitos fundamental para o completo
entendimento desta importante disciplina da engenharia de software. Desta forma, vamos explorar
estes conceitos para aprimorar o nosso entendimento.
Arquitetura
Tcnico
Um arquiteto de software deve saber que suas solues realmente vai funcionar quando for
desenvolvida. Assim, um arquiteto de software precisa garantir que a tecnologia de software
existente capaz de suportar a implementao da arquitetura definida. Um design bonito no intil
se no pode ser implementado.
Arquitetura de Referncia
A arquitetura de referncia um conjunto de princpios de design aplicveis simultaneamente em

diferentes sistemas relacionados tipicamente, que compartilham o mesmo domnio de aplicao.
Arquitetura Prescritiva
A arquitetura prescritiva a arquitetura como concebida para o sistema, ou seja, a arquitetura

idealizada pelos arquitetos que deve direcionar o desenvolvimento do software.
A arquitetura prescritiva no precisa necessariamente existir de uma forma tangvel, podendo inclusive
estar apenas nas mentes dos arquitetos. Entretanto sempre recomendvelque ela seja capturada em
uma notao ou outra forma de documentao. Saiba+
Saiba+
importante notar que documentar a arquitetura prescritiva no suficiente. O leitor deve lembrar
que a arquitetura no apenas uma fase no processo de desenvolvimento de um sistema de
software, mas sim constitui a base fundamental para o sistema. Assim, a qualquer momento durante
o processo de desenvolvimento, as decises de projeto de arquitetura, que so parte da arquitetura
prescritiva, sero refinadas e documentadas.
15
Arquitetura Descritiva
12
A arquitetura descritiva referida como tal quando descreve a forma como o sistema foi
implementado. A arquitetura descritiva , portanto, a arquitetura conforme realizada no sistema.
Durante o tempo de vida de um sistema de software podero existir

diferentes arquiteturas prescritivas e descritivas. Cada par
correspondente de tais arquiteturas representa a arquitetura do
software em um dado momento.
Degradao Arquitetnica
a diferena entre as arquiteturas descritiva e prescritiva.
Em um cenrio ideal, as duas arquiteturas, prescritiva e descritiva, sempre sero iguais. Entretanto, na
maioria das vezes isso no verdade. A diferena entre elas pode ocorrer por diversas razes:
Desenvolvedor que no se preocupa em documentar o que est fazendo;
Percepo de prazos curtos que impedem pensar na atualizao da documentao;
Falta de uma arquitetura prescritiva documentada;
Necessidade ou desejo de otimizar o sistema "que s pode ser feito no cdigo"; e
Tcnicas inadequadas que no se deseja documentar.
16
Perspectivas arquitetnicas
Podemos definir as pespectivas como um conjunto de decises de projeto de arquitetura.
A noo de uma perspectiva arquitetnica destacar alguns aspectos de uma arquitetura enquanto
outros aspectos so identificados.
As arquiteturas de software abrangem as decises tomadas por uma grande variedade de interessados
em diferentes nveis de detalhe e abstrao. O objetivo focar a ateno, por exemplo, para fins de
anlise, a um subconjunto das decises.
Outra perspectiva a implementao. Um sistema de software no pode cumprir seu propsito at que
seja implantada, ou seja, at que seus mdulos executveis sejam fisicamente colocados sobre os
dispositivos de hardware em que se destinam a ser executados.
A perspectiva de implantao de uma arquitetura pode ser fundamental para avaliar se o sistema ser
capaz de satisfazer as suas necessidades. Por exemplo, colocar muitos componentes grandes em um
13
pequeno dispositivo com memria e potncia da CPU limitadas, ou a transferncia de grandes volumes
de dados atravs de uma conexo de rede com baixa largura de banda vai impactar negativamente o
sistema.
17
Componentes
Componentes de software so elementos que encapsulam o processamento e os dados na

arquitetura de um sistema.
As decises que compem a arquitetura de um sistema de software abrangem uma interao rica e a
composio de muitos elementos diferentes. Estes elementos abrangem as preocupaes principais do
sistema, incluindo:
Processamento;
Estado;
Interao.
Um componente de software uma entidade arquitetnica que:
Incorpora um subconjunto da funcionalidade e de dados do sistema;
Restringe o acesso a esse subconjunto atravs de uma interface explicitamente definida;
Tem dependncias explicitamente definidas no seu contexto de execuo.
Processamento
Que tambm pode ser referido como a funcionalidade ou o comportamento.
Estado
Que tambm pode ser referido como a informao ou dados.
Interao
Que tambm pode ser referida como a interligao, a comunicao, coordenao, ou mediao.
14
18
Conectores
Um conector um elemento arquitetnico encarregado de efetuar e regular as interaes entre os

componentes de software.
Outro aspecto fundamental de sistemas de software a interao entre os blocos de construo do

sistema. Muitos sistemas modernos so construdos a partir de um grande nmero de componentes
complexos, distribudos em vrios hosts, que so atualizados dinamicamente durante um determinado
perodo de tempo. Em tais sistemas, garantir interaes adequadas entre os componentes pode tornar-
se ainda mais importante e desafiador para os desenvolvedores do que a funcionalidade dos
componentes em si; em outras palavras, as interaes do sistema se tornam a principal preocupao
arquitetnica.
Conectores de software so a abstrao arquitetnica encarregada de gerenciar as interaes de

componentes.
Configurao
Uma configurao arquitetnica um conjunto de associaes especficas entre os componentes e

conectores de arquitetura de um sistema de software.
19
Estilo Arquitetural
Um estilo arquitetnico uma coleo nomeada de decises de projeto de arquitetura que:
So aplicveis em um determinado contexto de desenvolvimento,
Limitam as decises de projeto de arquitetura que so especficos para um determinado

sistema dentro desse contexto,
Provocam qualidades benficas em cada sistema resultante.
Com o desenvolvimento de muitos sistemas para uma enorme gama de domnios de aplicao, o que se
tem observado que, sob determinadas circunstncias, certas escolhas de design regularmente
resultam em solues de sucesso. Em comparao a alternativas possveis, essa soluo mais elegante,
eficaz, eficiente, confivel e escalvel.
15
Esta lista de decises de arquitetura de design, portanto, no especfica para um determinado sistema
(ou classe de sistemas). Pelo contrrio, estas decises de arquitetura so aplicveis a qualquer sistema
que compartilha o contexto de prestao de servios distribudos.
Padro Arquitetural
Estilos arquitetnicos fornecem decises gerais de design que podem restringir ou podem necessitar de
refinamentos para que possa ser aplicados a um sistema.
J um padro de arquitetura fornece um conjunto de decises de design especfico que foram

identificadas como eficazes para a organizao de certas classes de sistemas de software.
Assim, um padro de arquitetura uma coleo de decises de projeto de arquitetura que so

aplicveis a um problema recorrente de design, parametrizados para explicar diferentes contextos de
desenvolvimento de software em que o problema aparece.
20
Modelos
Um modelo de arquitetura um artefato que capta algumas ou todas as decises de design que
compem a arquitetura de um sistema. Modelo arquitetnico a documentao dessas decises de
design.
Um modelo um resultado da atividade de modelagem, o que constitui uma parte significativa das
responsabilidades de um arquiteto software. Um sistema pode ter diversos modelos distintos
associados. Os modelos podem variar na quantidade de detalhes que eles capturar, na perspectiva
especfica arquitetnica que eles capturam, no tipo de notao que eles usam, e assim por diante.
O modelo arquitetural usado como a base para a maioria das outras

atividades no processo de desenvolvimento de software baseado em
arquitetura, como a anlise e a implementao do sistema.
21
RESUMO
Neste mdulo vimos que a Arquitetura de Software a organizao fundamental de um sistema,
representada por seus componentes, seus relacionamentos com o ambiente, e pelos princpios que
conduzem seu design e evoluo.
16
Tambm vimos como uma viso adequada da arquitetura de software afeta todos os aspectos das
atividades de engenharia de software. Esta influncia se d da seguinte forma:
A atividade requisitos vista como uma parceira da atividade de arquitetura, em que produtos e
projetos anteriores fornecem o vocabulrio para articular novas exigncias, e em que novas
idias de design fornecer a inspirao para estratgias e exigncias para o detalhamento dos
requisitos do produto.
A atividade de projeto enriquecida por tcnicas que exploram os conhecimentos adquiridos no

desenvolvimento de produtos anteriores.
A atividade de implementao centrado na criao de uma implementao fiel da arquitetura

e utiliza uma variedade de tcnicas para alcanar isso de uma forma eficaz em termos de custos,
As atividades de anlise e de teste pode ser focada e orientada pela arquitetura, que oferece a
perspectiva de deteco mais precoce de erros e exames mais eficientes e eficazes do produto.
Qualidade superior a um preo mais baixo deve ser o resultado.
Foram apresentadas as principais responsabilidade de um arquiteto de software e o perfil deste

importante profissional.
Foram explorados ainda alguns conceitos bsicos da arquitetura de software como:
Arquitetura de Referncia, Arquitetura Prescritiva, Arquitetura Descritiva, Degradao Arquitetnica,

Perspectivas arquitetnicos, Componentes, Conectores, Configurao, Estilo Arquitetural, Padro
Arquitetural e Modelos.

MDULO 2 O QUE ARQUITETURA DE SOFTWARE?
01
1 - CARACTERSTICAS DA ARQUITETURA DE SOFTWARE

Em nosso mdulo anterior definimos a arquitetura de software como a organizao fundamental de um
sistema, representada por seus componentes, seus relacionamentos com o ambiente, e pelos princpios
que conduzem seu design e evoluo. Analisando esta definio com um pouco mais de ateno,
podemos extrair algumas das caractersticas fundamentais da arquitetura de software. Estas
caractersticas que abordaremos a seguir.
1.1- Arquitetura define a estrutura
17
Muito do tempo de um arquiteto est ocupado em estruturar de forma sensata uma aplicao atravs
de um conjunto de componentes inter-relacionados, mdulos, objetos ou qualquer unidade de
particionamento software.
Uma arquitetura deve ser projetada para atender s necessidades especficas e s restries da
aplicao a que se destina.
Por exemplo, um requisito para um sistema de gerenciamento de informaes: pode ser que este
aplicativo seja distribudo em diferentes localizaes e que uma determinada funcionalidade, bem como
seus dados, deve estar concentrada em um local nico. Outro requisito que as funcionalidades do
aplicativo devem estar acessveis a partir de um navegador web. Todas estas necessidades podem impor
algum tipo de restrio estrutural para a aplicao e, simultaneamente, possiblitar uma arquitetura
onde existe uma coleo de componentes relacionados.
Ao particionar um aplicativo, o arquiteto atribui responsabilidades para cada componente. Estas

responsabilidades definem as tarefas que cada componente tem dentro do aplicativo. Deste modo, cada
componente desempenha um papel especfico na aplicao, e o conjunto global do componente que
compreende a arquitetura para fornecer as funcionalidades requeridas para o sistema.
02
A questo estrutural fundamental para quase todas as aplicaes minimizar as dependncias entre os
componentes, criando uma arquitetura de baixo acoplamento. Existe uma dependncia entre os
componentes quando uma mudana em um potencialmente fora uma alterao nos outros. Ao
eliminar dependncias desnecessrias, alteraes so localizadas e no se propagam ao longo de uma
arquitetura. Veja a figura a seguir.
Dois exemplos de dependncias de componentes
18
Para simplificar, as dependncias excessivas so simplesmente uma coisa ruim. Dentre as caractersticas
negativas de uma dependncia excessiva encontram-se:
Mais difcil fazer mudanas nos sistemas;
Mais caro os testes das alteraes;
Aumentam o tempo de construo; e
Tornam o desenvolvimento em equipe concorrente mais difcil.
03
1.2 - Comunicao Especfica entre os Componentes da Arquitetura
Quando um aplicativo dividido em um conjunto de componentes, torna-se necessrio pensar sobre

como esses componentes iro se comunicar. Os componentes em uma aplicao podem existir no
mesmo endereo, e se comunicar atravs de chamadas de mtodo simples. Eles podem ser executados
em diferentes segmentos ou processos, e se comunicar atravs de mecanismos de sincronizao. Ou
mltiplos componentes podem precisar ser simultaneamente informados quando ocorre uma ao no
ambiente da aplicao. Existem diferentes possibilidades.
Uma srie de estruturas utilizadas com sucesso na comunicao de certos tipos de comunicao entre
componente foi catalogada atravs de padres. Esses padres so essencialmente plantas de
arquitetura reutilizveis que descrevem a estrutura e interao entre colees de componentes
participantes.
Cada padro tem caractersticas que o tornam adequado para usar em tipos particulares satisfazendo-se
certos requisitos de arquitetura.
Por exemplo, o padro conhecido como cliente-servidor tem vrias caractersticas teis, tais como
servidores que suportam um ou mais clientes atravs de uma interface publicada e uma comunicao
sncrona de solicitao e resposta entre os clientes e o servidor. Opcionalmente, os clientes podem
estabelecer sesses com servidores, o que pode manter o estado sobre os seus clientes conectados.
Arquiteturas cliente-servidor tambm devem fornecer um mecanismo para que os clientes localizem
servidores, tratem erros e, opcionalmente, oferecer segurana no acesso ao servidor.
04
19
O poder dos padres de arquitetura decorre de sua utilidade e

capacidade de transmitir informaes para o projeto. Se usados
adequadamente em uma arquitetura, voc alavancar o conhecimento
de design existente usando padres.
Grandes sistemas tendem a usar vrios padres combinados de maneira que satisfaam os requisitos de
arquitetura.
Quando uma arquitetura Quando um arquiteto diz que seu

baseada em padres, tambm sistema baseado em uma
se torna mais fcil para os arquitetura cliente-servidor de
membros da equipe entender o trs camadas, imediatamente
design, como o padro infere uma quantidade considervel de
estrutura de componentes, informaes sobre o design deste
comunicaes e mecanismos sistema pode ser identificada. De
abstratos que devem ser fato, este um poderoso
fornecidos. mecanismo de comunicao.
Vamos explorar os principais padres de arquitetura em um mdulo posterior de nosso curso.
05
1.3- Arquitetura de requisitos no funcionais
Os requisitos no funcionais so aqueles que no aparecem nos casos de uso. Ao invs de definir o
que o aplicativo faz, eles esto preocupados com a forma como a aplicao fornece a funcionalidade
necessria.
H trs reas distintas de requisitos no funcionais:
Restries tcnicas
Estas sero familiares a todos. As restries tcnicas limitam as opes de projeto, especificando
certas tecnologias que o aplicativo deve usar. "O projeto s dispe de desenvolvedores Java, por isso
devemos desenvolver em Java". "O cliente s tem suporte para o Banco de Dados DB2".
Restries de negcios
20
Estas restries esto ligadas mais s empresa como um todo e no a razes tcnicas. Por exemplo, "A
fim de aumentar a nossa base de clientes em potencial, temos de interagir com aplicativos
disponveis em IOS". Outro exemplo "O fornecedor de nosso middleware elevou os preos a nvies
proibitivos, por isso estamos migrando para uma verso open source".
Atributos de qualidade
Definem requisitos de um aplicativo em termos de escalabilidade, disponibilidade, facilidade de

mudana, portabilidade, usabilidade, desempenho e assim por diante. Atributos de qualidade
abordar questes de interesse para usurios do aplicativo, bem como outras partes interessadas,
como a prpria equipe do projeto ou o patrocinador do projeto.
Uma arquitetura de aplicao deve, portanto, abordar explicitamente

estes aspectos do design. Arquitetos precisam entender os requisitos
funcionais, e criar uma plataforma que os contemple e cumpra
simultaneamente os requisitos no-funcionais.
06
1.4- Arquitetura uma abstrao
Uma das descries mais teis, mas muitas vezes inexistentes, a partir de uma perspectiva arquitetnica
algo que coloquialmente conhecido como marketecture.
A marketecture uma documentao, geralmente de uma pgina, que representa de forma informal
a estrutura e as interaes do sistema. Ela mostra os principais componentes e suas relaes e tem
algumas caixas de texto que retratam as filosofias de design incorporadas na arquitetura.
Trata-se de um excelente veculo para facilitar a discusso pelas partes interessadas durante a
concepo, construo, reviso, e, at mesmo, no processo de vendas. fcil de entender e explicar e
serve como um ponto de partida para uma anlise mais profunda.
A marketecture cuidadosamente trabalhada particularmente til porque uma descrio abstrata do

sistema. Na realidade, qualquer descrio arquitetnica deve empregar abstrao, a fim de ser
compreensvel pelos membros da equipe e partes interessadas no projeto. Isto significa que detalhes
desnecessrios so reprimidos ou ignorados, a fim de concentrar a ateno e anlise sobre as questes
arquitetnicas marcantes. Isso geralmente feito atravs da descrio dos componentes na arquitetura
como caixas pretas, especificando apenas as suas propriedades externamente visveis.
21
07
Um dos mecanismos mais poderosos para descrever uma arquitetura a decomposio hierrquica.
Os componentes que aparecem em um nvel de descrio so decompostos em mais detalhe na

documentao que acompanha o design.
Como um exemplo, a imagem abaixo descreve uma hierarquia de dois nveis muito simples usando uma
notao informal, com dois dos componentes no diagrama de nvel superior decomposta.
Ilustrao: refazer a imagem, mantendo as informaes e aumentando a fonte para facilitar a leitura.
Descrevendo uma arquitetura hierrquica
Diferentes nveis de descrio na hierarquia tendem a ser de interesse para diferentes desenvolvedores
em um projeto. Na imagem, provvel que os trs componentes na descrio de nvel superior sejam
projetados e construdos por diferentes equipes de trabalho. A arquitetura exibe as responsabilidades
de cada equipe, definindo as dependncias entre eles.
08
Neste exemplo hipottico, o arquiteto refinou a concepo de dois dos componentes, presumivelmente
porque alguns requisitos no funcionais necessitam de definies adicionais. Uma hiptese que um
servio de segurana existente deve ser utilizado, ou o broker deve fornecer uma funo de roteamento
de mensagens especficas exigindo um servio de diretrio que tem um nvel conhecido de pedido de
transferncia. Independentemente disso, este aperfeioamento cria uma estrutura que define e limita a
concepo mais detalhada desses componentes.
Observe que na arquitetura simples da figura anterior no houve a decomposio do componente

cliente. Isto se deve ao fato de que o comportamento do cliente no significativo em relao aos
requisitos no-funcionais gerais do aplicativo. A forma como o cliente obtm a informao que
enviada para o broker no uma questo que diz respeito ao arquiteto, e, consequentemente, o projeto
detalhado deixado em aberto para a equipe de desenvolvimento do componente.
O componente cliente poderia ser o mais complexo na aplicao. Ele pode ter uma arquitetura
interna definida por sua equipe de projeto, que atende s metas de qualidade especficas. No
entanto, estas so preocupaes localizadas em que o arquiteto pode deixar para a equipe de design
do cliente resolver.
Este um exemplo de como suprimir detalhes desnecessrios na arquitetura.
22
figura
Produo: inserir como link a imagem Descrevendo uma arquitetura hierrquica da tela anterior.
09
2 - VISES DE ARQUITETURA DE SOFTWARE

A arquitetura de software algo complexo de se representar e, consequentemente, de se documentar.
Por este motivo, possvel identificarmos diferentes maneiras de olhar e compreender uma arquitetura.
Voltando a nossa analogia com a construo civil, as vises da arquitetura de software seriam as
diferentes plantas existentes para a construo de uma casa ou um prdio.
Em 1995 Philippe Krutchen em seu artigo 4 + 1 Model View traz luz uma maneira de descrever e
compreender uma arquitetura atravs de quatro pontos de vista:
Viso lgica
Viso de processo
Viso fsica
Viso de desenvolvimento
Estes pontos de vista so amarrados pelos casos de uso arquiteturalmente significativos (muitas vezes
chamado de cenrios). Estes basicamente capturam os requisitos para a arquitetura e, portanto, esto
relacionadas a mais de um ponto de vista em particular.
Ao trabalhar com as etapas em um caso de uso, a arquitetura pode ser "testada", explicando como os
elementos de design na arquitetura respondem ao comportamento exigido no caso de uso.
Viso lgica
Esta viso descreve os elementos significativos da arquitetura e as relaes entre eles. A viso lgica
essencialmente captura a estrutura do aplicativo usando diagramas de classe ou equivalentes.
Viso de processo
Esta viso se concentra em descrever os elementos de concorrncia e de comunicao de uma

arquitetura. Em aplicaes de TI, as principais preocupaes esto descrevendo componentes de
segmentos multithreaded e os mecanismos de comunicao sncrona ou assncrona usado.
23
Viso fsica
Esta viso descreve como os principais processos e componentes so mapeados para o hardware da
aplicao. Ele pode mostrar, por exemplo, como os servidores de banco de dados e web so
distribudos atravs de um nmero de servidores.
Viso de desenvolvimento
Esta viso capta a organizao interna dos componentes de software, tipicamente como eles so
mantidos em um ambiente de desenvolvimento ou ferramenta de gerenciamento de configurao.
Por exemplo, a descrio de uma hierarquia de pacote e classe de uma aplicao Java representa o
ponto de vista do desenvolvimento de uma arquitetura.
10
Desde a descrio realizada por Krutchen, tem havido muita reflexo, experincia e desenvolvimento na
rea de vises de arquitetura. Um trabalho que merece destaque o realizado pelo SEI.
Conhecido como abordagem "Views and Beyond", este trabalho recomenda a captura de um modelo de
arquitetura usando trs diferentes pontos de vista:
Mdulo
Esta uma viso estrutural da arquitetura, que compreende os mdulos de cdigo como classes,
pacotes e subsistemas no design. Ele tambm capta mdulo de decomposio, herana, associaes e
agregaes.
Componente e conector
Esta viso descreve os aspectos comportamentais da arquitetura. Componentes so tipicamente

objetos, linhas, ou processos, e os conectores descrever como os componentes interagem.
Conectores comuns so tomadas, middleware como CORBA ou memria compartilhada.
Alocao
Esta viso mostra como os processos na arquitetura so mapeados para hardware, e como eles se
comunicam atravs de redes e bases de dados. Ela tambm captura uma vista para o cdigo-fonte
dos sistemas de gerenciamento de configurao, e que no grupo de desenvolvimento tem a
responsabilidade de cada um dos mdulos.
SEI
24
Software Engineering Institute (SEI) um centro de pesquisa e desenvolvimento patrocinado pelo

Departamento de Defesa dos Estados Unidos da Amrica que prov uma prtica avanada de
engenharia de software qualificando graus de qualidade de software.
11
3 - ARQUITETURA E TECNOLOGIA
Os arquitetos devem tomar decises de design no incio de um ciclo de vida do projeto. Muitos destas
decises so difceis de serem validadas e testadas at que o sistema, ou pelo menos parte do sistema,
seja efetivamente construda. Realizar a prototipao criteriosa de componentes chaves para a
arquitetura pode ajudar a aumentar a confiana em uma determinada abordagem de design, mas s
vezes ainda difcil ter certeza do sucesso de uma escolha de design especial em um determinado
contexto de aplicao.
Devido dificuldade de validar decises iniciais do projeto, os arquitetos podem optar, de forma
sensata, por abordagens experimentadas e testadas para solucionar certas classes de problemas. Este
um dos grandes valores de padres de arquitetura. Eles permitem aos arquitetos reduzir riscos,
aproveitando projetos bem sucedidos com atributos de engenharia conhecidos.
Os padres so uma representao abstrada de uma arquitetura, uma vez que eles podem ser atingidos
de vrias formas durante a implementao. Por exemplo, a arquitetura padro de publicao-assinatura
(publishsubscribe) descreve um mecanismo abstrato de baixo acoplamento, comunicaes muitos-
para-muitos (many-to-many) entre editores de mensagens e assinantes que desejam receber
mensagens. No entanto, no especificam como publicaes e assinaturas so gerenciadas, que
protocolos de comunicao so utilizados, quais os tipos de mensagens podem ser enviados, e assim por
diante. Estes so todos considerados detalhes de implementao.
Em virtude deste nvel abstrato, no meio acadmico, h uma srie de discues a respeito de modelos
arquiteturais. Alguns destes modelos nem mesmo so capazes de serem implementados de forma
concreta pelos engenheiros de software.
Felizmente, a indstria de software teve um direcionamento mais prtico. Padres de arquitetura

amplamente utilizados so suportados em uma variedade de estruturas pr-construdas e disponveis,
seja atravs de tecnologia comercial, seja por meio de tecnologia open source. Saiba+
Saiba+
De qualquer forma, se um projeto necessita de uma estrutura de publicao-assinatura (publish

subscribe) de mensagens, broker de mensagem ou de uma arquitetura de trs camadas, as opes de
tecnologia disponveis so muitas e variadas. Este um exemplo de tecnologias que fornecem
infraestruturas de software reutilizveis e comprovadas tecnologicamente.
25
12
Como retrata a imagem abaixo, vrias classes de tecnologias so utilizadas na prtica para fornecer
implementaes de padres de arquitetura para uso em sistemas de TI. Dentro de cada classe, produtos
comerciais ou open source podem ser utilizados. Embora estes produtos sejam similares, eles possuem
diferentes conjuntos de recursos e, por este motivo, so utilizados de forma diferente e tm diferentes
restries em relao a sua utilizao.
Ilustrao: refazer a imagem, mantendo as informaes e aumentando a fonte para facilitar a leitura.
Abstrao
Padres de Arquitetura
Servidor de Aplicao Mensageria Broker de Mensagens Broker de Objetos Orquestrao de Processos
Tecnologias Disponveis no Mercado
Mapeamento entre os padres de arquitetura e tecnologias concretas
A diversidade de tecnologia disponvel no mercado muito grande. Esta diversidade traz vantagens e
desvantagens. A concorrncia entre fornecedores de produtos apresenta constantes inovaes,
melhores conjuntos de recursos e implementaes, e preos mais competitivos, mas tambm dificulta a
seleo de um produto que possui atributos de qualidade que satisfazem os requisitos da aplicao.
O desafio do arquiteto est em compreender os benefcios e os pontos

fracos no incio do ciclo de desenvolvimento de um projeto e escolher a
mais adequada para o seu projeto. Esta no uma tarefa fcil e os
riscos e custos associados seleo de uma tecnologia inadequada so
elevados. A histria da indstria de software est cheio de escolha mal
feita e, consequentemente, de projetos fracassados.
Aplicao
Todas as aplicaes so diferentes em alguns aspectos, e raramente existe um produto que atenda
por completo todas as necessidades do projeto. Diferentes implementaes de tecnologia tm
diferentes conjuntos de pontos fortes e fracos e custos e, consequentemente, sero mais adequados
para alguns tipos de aplicaes do que outros.
13
4 - Arquitetura de Software em Projetos geis
26
Atualmente, muito tem se falado de mtodos geis de desenvolvimento de software. O mercado

identificou estas metodologias como a soluo para entregar projetos de software que efetivamente
entregam valor para o usurio final de maneira contnua e de forma mais rpido. Mtodos geis de
desenvolvimento de software prometem apoiar feedback contnuo e absorver mudanas nos requisitos
em todo o ciclo de vida de desenvolvimento de software, atravs de uma estreita colaborao entre
clientes e desenvolvedores e permite entregas frequentes de recursos de software necessrios para um
sistema.
Os mtodos geis de desenvolvimento de software so baseados no Agile Manifesto, que foi publicado
por um grupo de desenvolvedores e consultores de software em 2001. Este manifesto descreve os
valores fundamentais que sustentam pontos de vista da comunidade gil sobre diferentes aspectos dos
processos de desenvolvimento de software, pessoas, prticas e artefatos.
Alguns dos mtodos geis de desenvolvimento de software mais conhecidos so:
Extreme Programming (XP) e

Scrum.
Por este motivo, vamos limitar nossa discusso a respeito dos princpios e prticas de arquitetura para
estas duas metodologias. Com isso, esperamos fornecer uma discusso mais especfica, coerente e
profunda de como fazer mtodos geis e prticas de arquitetura trabalhar em harmonia para alavancar
as vantagens de ambas as disciplinas para o desenvolvimento de alta qualidade e software de baixo
custo forma iterativa e incremental, sem atrasos desnecessrios e riscos do projeto.
14
4.1 Scrum
Scrum tem emergido como um dos principais, se no a principal metodologia gil de desenvolvimento
de sistema.
Scrum um termo usado no jogo do rugby que significa "fazer uma bola fora do jogo voltar para o
jogo" atravs de esforos da equipe. No desenvolvimento de software, Scrum uma abordagem de
gerenciamento de projeto iterativo e incremental que fornece uma simples inspeo e adaptao ao
invs de tcnicas especficas.
27
A formao scrum no rugby utilizada para reincio do jogo em certos casos.
15
Projetos baseados em Scrum entregam software em incrementos chamados sprints (geralmente 3-4
iteraes semana, ou at duas semanas em alguns casos). Cada sprint comea com o planejamento,
durante o qual as histrias de usurio so tomadas a partir backlogs com base nas prioridades, e
termina com uma reviso sprint. esperado que a atividade de planejamento dure por algumas horas
(por exemplo, 4 horas). A reunio de reviso do sprint tambm pode durar cerca de 4 horas. Todos os
principais interessados so esperados para participar do planejamento do sprint e das reunies de
reviso do sprint, realizadas no incio e no fim de cada sprint, respectivamente.
Uma equipe scrum realiza uma breve reunio (por exemplo, no mximo 15 minutos) no incio de cada
dia. Esta reunio chamada de "reunio diria do scrum", e destinada a permitir que cada membro da
equipe responda a apenas trs perguntas:
O que eu fiz ontem?
O que farei hoje?
Quais so impedimentos para o meu trabalho?
Cada projeto scrum dever ter, pelo menos, trs artefatos:
backlog de produtos,
28
backlog de sprint,
e o grfico de burn-down, que tem como objetivo fornecer um relatrio da situao em termos
de trabalho acumulado ainda a ser feito.
A comunidade de arquitetura de software tem emprestado o termo backlog e props que o processo de
arquitetura tambm deve manter um backlog para projetar e avaliar a arquitetura do software de forma
iterativa.
Os backlogs do Scrum consistem em requisitos que precisam ser implementados durante os ciclos de
sprint atuais ou futuras. Assim, definir um backlogs de arquitetura traz uma abordagem iterativa e
incremental para a arquitetura.
Sprint
Um sprint a unidade bsica de desenvolvimento em Scrum. Sprints tendem a durar entre uma
semana e um ms, e so um esforo dentro de uma faixa de tempo (ou seja, restrito a uma durao
especfica) de comprimento constante. Cada sprint precedido por uma reunio de planejamento
(Sprint Planning), onde as tarefas para o sprint so identificadas e um compromisso estimado para o
objetivo do sprint definido e seguido por uma reunio de reviso ou de retrospectiva, onde o
progresso revisto e lies para os prximos sprints so identificadas.
16
4.2- Programao Extrema (XP eXtream Programming)
Programao Extrema ou simplesmente XP outra abordagem gil muito popular que foi desenvolvida
com base em princpios e prticas adotadas em nveis extremos de senso comum. Como outros mtodos
geis, o XP tambm defende iteraes curtas e lanamentos frequentes de cdigo com o objetivo de
aumentar a produtividade e acomodar as mudanas de requisitos.
XP foi projetado para equipes de oito a dez desenvolvedores que trabalham com a linguagem de
programao orientada a objeto. A abordagem rapidamente se tornou popular, entre os
desenvolvedores de software que no estavam satisfeitos com as abordagens de desenvolvimento de
software tradicionais.
Entre as principais prticas XP encontram-se:
Jogo de planejamento;
Pequenas entregas;
29
Projeto simples;
Testes;
Refatorao;
Programao em pares;
Integrao contnua;
Propriedade coletiva;
Cliente no local;
Quarenta horas por semana;
Apenas governa.
XP
Os cinco valores fundamentais da metodologia XP so: comunicao, simplicidade, feedback,

coragem e respeito. A partir desses valores, possui como princpios bsicos: feedback rpido,
presumir simplicidade, mudanas incrementais, abraar mudanas e trabalho de qualidade.
Jogo de planejamento
Uma estreita interao entre clientes e desenvolvedores incentivada para estimar e priorizar
requisitos para o prximo lanamento. Os requisitos so capturados como histrias dos usurios
sobre cartes de histria. Os programadores so esperados para planejar e entregar apenas as
histrias do usurio acordados com os clientes.
Pequenas entregas
Uma verso inicial de um sistema liberada para operao aps algumas iteraes. Novos recursos
so entregues em verses subsequentes em uma base diria ou semanal.
Projeto simples
XP incentiva os desenvolvedores a manter o projeto de um sistema to simples quanto possvel.
Testes
30
O primeiro teste significa que os desenvolvedores escrevem testes de aceitao para o seu cdigo
antes de escrever o cdigo em si. Os clientes escrevem testes funcionais para cada iterao, e no fim
de cada iterao, esperado que todos os testes sejam executados com xito.
Refatorao
O projeto de um sistema evoluiu, transformando o design do sistema de uma forma que todos os
casos de teste sejam executados com xito.
Programao em pares
O cdigo de produo escrito por dois desenvolvedores.
Integrao contnua
Tudo novo cdigo integrado ao sistema de forma constante. Todos os testes funcionais ainda
devem ocorrer aps a integrao ou o novo cdigo descartado.
Propriedade coletiva
Todos os desenvolvedores trabalhando em conjunto. Isso significa que qualquer desenvolvedor pode
fazer alteraes em qualquer parte do cdigo a qualquer momento tal for considerado necessrio.
Cliente no local
Um cliente senta-se com a equipe de desenvolvimento o tempo todo. O cliente responde a perguntas
no local, realiza testes de aceitao, e assegura o progresso no desenvolvimento.
Quarenta horas por semana
Se algum da equipe de desenvolvimento tem que trabalhar horas extras em duas semanas
consecutivas, um sinal de um grande problema. Os requisitos devem ser selecionados para cada
iterao de uma forma que os desenvolvedores no necessitem trabalhar horas extras.
Apenas governa
Os membros de uma equipe de subscrever um conjunto de regras. As regras podem ser alteradas a
qualquer momento, desde que haja um consenso sobre a forma de avaliar os efeitos da mudana.
17
31
4.3- Fazendo a arquitetura e as abordagens agis funcionarem
Com a popularizao das metodologias geis, est ocorrendo um reconhecimento crescente da

importncia de prestar mais ateno aos aspectos arquitetnicos. Assim, est aumentando o nmero
de esforos destinados a identificar os desafios tcnicos e organizacionais envolvidos na integrao de
abordagens geis de desenvolvimento de software em mtodos tradicionais.
Esses esforos resultaram em vrias propostas para combinar os pontos fortes dos elementos centrais
de cada abordagem de desenvolvimento de software.
Mesmo com estes esforos, ainda existem lacunas a serem preenchidas quando falamos em integrar
processos geis e processo mais centrados em arquitetura.
Pode-se argumentar que um dos pr-requisitos importantes para eliminar a lacuna existente entre as
abordagens gil e arquitetnica construir e divulgar uma base de conhecimento sobre os pontos de
conflito e de conciliao entre os princpios. Tal base de conhecimento deve incluir tambm os
desafios, os problemas e riscos que as equipes de desenvolvimento de software enfrentam quando
tentam seguir os princpios de projetos geis que no incorporam as prticas de uma abordagem
centrada em arquitetura.
18
Vrias observaes foram feitas sobre a combinao de abordagens geis e arquitetnicas, alguns
desses resultados foram compilados atravs de prticas geis bem conhecidas, juntamente com prticas
arquitetnicas para mostrar que muitas das prticas geis tm princpios ou prticas equivalentes, e
estas podem ser facilmente adaptadas e aplicadas em ambientes geis.
Observe a tabela a seguir.
Prticas geis Abordagem arquitetural
A natureza iterativa do design de uma arquitetura de software pode ser

Sprint tratada atravs de um backlog das preocupaes arquiteturais serem
tratadas.
Sprint planning Priorizao de requisitos significantes arquiteturalmente para cada iterao.
Sprint review Reviso arquitetural
32
Compartilhar a lgica e o conhecimento da arquitetura atravs de reunio

Daily meetings
de grupo arquitetural
Envolver os principais interessados durante a definio da arquitetura o

Onsite customer
mximo possvel
Architecture-level integration and interoperabilityquality attribute

Continuous approaches
integration Integrao em nvel de arquitetura e interoperabilidade com uma
abordagem de atributos de qualidade.
Refatorao em nvel de arquitetura usando padres e estilos de

Refactoring
arquitetura.
Design baseado em padres para garantir sua simplicidade e que seja bem
Simple design
conhecido
Collective code Garantir que os principais interessados comprem a ideia das principais
ownership decises arquiteturais
Utilizao de templates e padres arquiteturais para facilitar a apoio e

Coding standards
padronizao
Test-driven
Testes baseados na arquitetura
development
19
Para garantir uma integrao entre metodologias geis e uma abordagem centrada em arquitetura,
tem se observado uma nfase crescente sobre o papel vital dos arquitetos de software.
Os arquitetos devem agir como facilitadores dos projetos de desenvolvimento de software e como os
representantes de atributos de qualidade global de um sistema.
Para agir como facilitador, o arquiteto deve ter as seguintes caractersticas:
Ter uma boa compreenso das abordagens geis.

Saber como convencer o proprietrio do produto (product owner) a respeito de uma
deciso de design em situaes conflitantes.
Conhecer a arquitetura global, recursos necessrios e o estado de implementao.
Documentar e comunicar a arquitetura a todas as partes interessadas.
Deve estar disposto a exercer mltiplos papeis como: arquiteto de soluo, arquiteto de
software, desenvolvedor etc.
33
Liderar um esforo para institucionalizar o papel de arquitetos como facilitadores e

prestadores de servios para os projetos.
20
importante ter em mente que os arquitetos de software geralmente

projetam a arquitetura, mas so os desenvolvedores que materializam a
arquitetura projetada. Os desenvolvedores de software devem ser
igualmente responsveis pelo tratamento da arquitetura como uma
entidade de primeira classe que fornece o projeto de todo o sistema.
Assim, o papel dos desenvolvedores de software igualmente
importante no sucesso da combinao das abordagens geis e
arquitetural.
A integrao das metodologias geis e da arquitetura de software no algo dominado pelo mercado
onde j existe um conjunto de prticas bem definidas e consolidadas. Entretanto, histrias de sucesso
tm crescido e medida que o nmero de projetos bem sucedidos aumenta, as melhores prticas
tambm aumentam.
Nesa disciplina tivemos apenas uma pequena introduo sobre o assunto. Desta forma, importante
que vocs pesquisem e se aprofundem neste assunto que, sem dvida, vai se tornar cada vez mais
relevante na rea de tecnologia, sobretudo em relao aos processos de desenvolvimento de software.
21
RESUMO
Neste mdulo podemos explorar com um pouco mais de profundidade o conceito de arquitetura de
software. Onde podemos observar que durante a definio da estrutura do sistema busca-se minimizar
as dependncias entre os componentes, criando uma arquitetura de baixo acoplamento.
Vimos tambm que, se usados adequadamente em uma arquitetura, a utilizao de padres alavanca o
conhecimento de design e torna mais fcil entender o design do sitema.
Foi abordado tambm que a arquitetura de software deve abordar explicitamente os aspectos no
funcionais de um ssitema.
Vimos que um dos mecanismos mais poderosos para descrever uma arquitetura a decomposio
hierrquica, onde inicialmente temos uma documentao informal com a estrutura e as interaes do
sistema de forma mais ampla e estes componentes so decompostos em mais detalhe na
documentao que acompanha o design.
34
As diferentes formas de visualizarmos a arquitetura so denominadas vises, as quais esto divididas

em: Viso lgica, Viso de processo, Viso fsica e Viso de desenvolvimento.
Vimos tambm que a indstria de software teve um direcionamento prtico onde uma infinidade de
estruturas pr-construdas esto disponveis seja atravs de tecnologias comerciais ou atravs de
tecnologia open source.
Foi abordado tambm que, medida que as metodologias geis tornam-se mais populares,
importante que a arquitetura e estas metodologias possam se unir para trazer os benefcios de ambas
abordagem para os projetos de desenvolvimento de software.

MDULO 3 ARQUITETURA CORPORATIVA X ARQUITETURA DE SOFTWARE
01
1- O QUE ENTERPRISE ARCHITECTURE?

Nossa disciplina diz respeito arquitetura de software. Entretanto, na rea de tecnologia da informao
temos outro tipo de arquitetura, a arquitetura corporativa. Nesta etapa do nosso estudo vamos
explorar a arquitetura corporativa, os principais frameworks e como a arquitetura de software est
relacionada arquitetura corporativa.
A arquitetura corporativa pode ser vista como um modelo para o posicionamento ideal de recursos no
ambiente de TI para o apoio fundamental da funo de negcios.
O objetivo da arquitetura corporativa criar um ambiente de TI unificado (sistemas de hadware e

software padronizados) em toda a empresa ou todas as unidades de negcios da empresa direcionadas
ao negcio da organizao e sua estratgia.
Mais especificamente, os objetivos so promover o alinhamento, a normalizao, a reutilizao de

ativos de TI existentes, bem como compartilhar os mtodos comuns para a gesto de projetos e
desenvolvimento de software em toda a organizao. O resultado final, teoricamente, que a
arquitetura corporativa far a TI da organizao mais barata, mais alinhada estrategicamente
organizao e mais gil.
A finalidade da arquitetura corporativa criar um mapa de ativos de TI e processos de negcios e um

conjunto de princpios de governana que impulsionem uma discusso em curso sobre a estratgia de
negcio e como ela pode ser expressa atravs da TI.
35
02
Na literatura possvel encontrar diferentes sugestes de como uma arquitetura corporativa deve ser
elaborada. No entanto, em todas estas sugestes, ou pelo menos na maioria, quatro domnios
fundamentais so comuns:
Arquitetura de negcios
Documentao que descreve os processos de negcios mais importantes da empresa.
Arquitetura de informao
Identifica onde os blocos de informao importantes, como um registro de cliente, so mantidos e

como um tipicamente acess-los.
Arquitetura do sistema de aplicao
Um mapa das relaes de aplicaes de software para o outro.
Arquitetura de tecnologia de infraestrutura
Um modelo para a gama de hadware, sistemas de armazenamento e redes. A arquitetura de negcios

o mais crtico, mas tambm o mais difcil de implementar, de acordo com profissionais da indstria.
Os domnios apresentados para a arquitetura empresarial, principalmente quando organizados em

camadas, provaram ser teis porque tm a vantagem de proporcionar uma viso mais contida e mais
focada em um domnio, o que evita uma viso sobreposta do ambiente de TI da organizao.
03
H uma srie de modelos de arquitetura corporativa disponveis no mercado. Veja alguns deles.
No entanto, no existe um consenso sobre qual modelo o mais completo e qual deve ser utilizado
pelas empresas. Para tornar a misso de selecionar um modelo a ser adotado ainda mais difcil, novos
modelos esto surgindo ao longo do tempo. Existe inclusive um livro com o ttulo Como sobreviver na
selva de Frameworks para Arquitetura Empresarial: Criando ou Escolhendo um Framework de
Arquitetura Empresa.
36
Fundamentalmente, todos os modelos buscam, de alguma maneira fazer uso da noo de servio e
arquitetura genrica onde as funes esto agrupadas em mdulos de servios reutilizveis. Os recursos
mais complexos so construdos a partir da utilizao adequada destes mdulos mais bsicos.
Alguns dos modelos de arquitetura empresarial tm sua origem no modelo cliente-sevidor desenvolvido
no final de 1980 e incio de 1990. No entanto, alguns dos conceitos foram modernizados; por exemplo, o
cliente pode ser um dispositivo de acesso baseado em browser, o servidor pode ser um servidor Web, e
o protocolo de comunicao poderia ser o HTTP (Hypertext Transfer Protocol); ou ambas as entidades
poderiam ser um servidor executando algum Web Service.
No entanto, ns profissionais de TI, temos que ter uma viso mais

pragmtica e menos acadmica sobre estes modelos. Caso contrrio,
pode-se acabar por gastar uma enorme quantidade de tempo ao longo
de vrios anos para desenvolver um modelo a ser utilizado e, pior, que
tem pouco de concreto para mostrar.
Veja alguns deles.
A seguir exibida uma lista de modelos de arquitetura corporativa:
Zachman Enterprise Architecture Framework (ZIFA)

The Open Group Architecture Framework (TOGAF)
Extended Enterprise Architecture Framework (E2AF)
Enterprise Architecture Planning (EAP)
Federal Enterprise Architecture Framework (FEAF)
Treasury Enterprise Architecture Framework (TEAF)
Integrated Architecture Framework (IAF)
Joint Technical Architecture (JTA)
Command, Control, Communications, Computers, Intelligence, Surveillance, and
Reconnaissance (C4ISR) and DoD Architecture Framework (DoDAF)
Department of Defense Technical Reference Model (DoD TRM)
Technical Architecture Framework for Information Management (TAFIM)
Computer Integrated Manufacturing Open System Architecture (CIMOSA)
Purdue Enterprise Reference Architecture (PERA)
Standards and Architecture for eGovernment Applications (SAGA)
European UnionIDABC & European Interoperability Framework
ISO/IEC 14252 (IEEE Std 1003.0)
IEEE Std 1471-2000 IEEE Recommended Practice for Architectural Description
04
37
A tentativa para modelar uma empresa inteira com qualquer um dos modelos disponveis no mercado
pode ser um esforo extremamente entediante e pode se tornar um ponto discutvel quando o
ambiente de negcios e mesmo o mercado muda constantemente.
Por causa do esforo envolvido, uma empresa pode investir grande

quantidade de tempo na realizao de sua arquitetura corporativa e, no
momento que a concluir, pode descobrir que ela j est desatualizada.
Assim, o que temos que buscar uma boa modelagem. O esforo para
se produzir um modelo perfeito, extremamente preciso pode se
mostrar um grande desperdcio.
Em virtude de todo o contexto apresentado, no so apenas as grandes organizaes que adotaram a

arquitetura empresarial. As pequenas organizaes tambm esto adotando essa abordagem. No
entanto, o prazo com que a arquitetura corporativa necessita ser revisado e atualizado tambm se torna
menor que empresas de grande porte.
Toda organizao que procura gerir a sua complexidade de TI de forma eficaz, em termos de custo para
implantao do sistema rpido, deve considerar fazer os investimentos adequados na arquitetura
corporativa.
05
2- MOTIVAES PARA TER UMA ARQUITETURA CORPORATIVA

A principal razo para o desenvolvimento de uma arquitetura corporativa apoiar o lado comercial da
organizao, fornecendo a tecnologia fundamental e estrutura de processo para uma estratgia de TI.
Este, por sua vez, torna um ativo sensvel para uma estratgia de negcios bem sucedida e atualizada.
Como a tecnologia da informao estendeu seu alcance em todas as reas da empresa e os sistemas,
aplicativos, bancos de dados, servidores, redes e dispositivos de armazenamento tornam-se altamente
interligados e interdependentes na lgica e no nvel fsico, os profissionais de TI precisam reconhecer a
crescente importncia da arquitetura empresarial para o contnuo sucesso e crescimento da empresa.
Quando feita corretamente, a arquitetura empresarial fornece uma avaliao sistemtica e uma
descrio de como a funo de negcios opera no momento atual:
ela fornece um "projeto" de como deve operar no futuro,

e um roteiro para chegar ao estado de destino.
38
Trabalhar a arquitetura corporativa importante por pelo menos trs razes:
a) permite a comunicao entre os stakeholders,

b) facilita as decises iniciais do projeto, e
c) cria uma abstrao transfervel de uma descrio do sistema / ambiente.
A arquitetura corporativa ir ajudar as empresas a gerenciar seus custos de TI; ele ajuda a organizao a
decidir onde fazer novos investimentos em TI, ou seja, o que deve ser conservado e o que deve ser
aposentado ou reconstrudo, sejam aplicativos ou infraestrutura.
06
Mesmo entendendo a importncia e a motivao de se ter uma arquitetura comporativa, ter um

conjunto de declaraes escritas rotuladas como princpios no significa que os princpios sejam bons,
ainda que as pessoas na organizao concordar com ele. Um bom conjunto de princpios se baseia em
crenas e valores da organizao e expresso numa linguagem que o lado comercial da empresa
entende e usa. Por outro lado, importante que o lado do negcio entenda o oramento da rea de TI e
o motivo pelo qual os recursos esto sendo destinados a esta rea.
Os princpios da arquitetura corporativa precisam conduzir o comportamento dentro da organizao de

TI. Princpios devem ser em nmero reduzido, ser voltada para o futuro, e ser aprovado e defendido
pelos gestores de TI e de negcio. Eles fornecem uma base para a tomada de decises de Arquitetura e
Planejamento, elaborao de polticas, procedimentos e padres, e apoiam a resoluo de situaes
contraditrias.
Um conjunto de princpios ruim cair rapidamente em desuso, e as polticas e normas soaro como
arbitrrias e, portanto, carecero de credibilidade. Existem vrios critrios que caracterizam um bom
conjunto de princpios. So eles:
Compreensibilidade
Robustez
Abrangncia
Consistncia
Estabilidade
Compreensibilidade
Os princpios subjacentes podem ser rapidamente apreendidos e compreendidos por pessoas em

toda a organizao. A inteno do princpio clara e inequvoca, de modo que as violaes sejam
reduzidas.
39
Robustez
Subsidia a tomada de deciso de boa qualidade sobre os planos a serem realizados, e sobre as
polticas e normas a serem criadas. Cada princpio deve ser suficientemente preciso para apoiar a
tomada de decises consistentes em situaes complexas e potencialmente controversas.
Abrangncia
Todo princpio potencialmente importante que rege a gesto de informao e tecnologia para a
organizao est definido. Os princpios devem cobrir todas as situaes percebidas.
Consistncia
Os princpios no devem ser contraditrios ao ponto em que aderir a um princpio violaria o esprito
de outro. Cada palavra em um princpio deve ser cuidadosamente escolhida para permitir uma
interpretao coerente, mas flexvel.
Estabilidade
Princpios devem ser duradouros, ainda capazes de acomodar as mudanas. Deve ser estabelecido um
processo de emenda para adicionar, remover ou alterar princpios depois de serem ratificados
inicialmente.
07
A estratgia de uma arquitetura corporativa, ainda traz vantagens tcnicas capazes de proporcionar
vantagens competitivas importantes, como:
Uma operao de TI mais eficiente.

Menores custos de desenvolvimento de software, suporte e manuteno.
O aumento da portabilidade de aplicaes.
Melhor interoperabilidade e sistema mais fcil e gerenciamento de rede.
Uma melhor capacidade para abordar questes crticas em toda a empresa, como a
segurana.
Atualizao mais fcil e troca de componentes do sistema.
Melhor retorno sobre o investimento existente e reduo do risco para futuros
investimentos.
Complexidade reduzida em infraestrutura de TI.
O mximo retorno sobre o investimento em infraestrutura de TI existente.
A flexibilidade de fazer, comprar, ou terceirizar solues de TI.
Reduo do risco global em novos investimentos e os custos de propriedade de TI.
Aquisies mais rpidas, mais simples, mais baratas.
40
Decises de compra mais simples, porque a informao que rege os contratos est
prontamente disponvel em um plano coerente.
08
3- PRINCIPAIS FRAMEWORKS DO MERCADO

Atualmente, os modelos mais utilizados pela indstria so Zachman, seguido por TOGAF e DoDAF.
Vamos explorar cada um destes modelos. importante ressaltar que o objetivo apenas apresentar
brevemente cada um destes frameworks.
3.1 ZACKMAN
Este framework recebeu o nome de seu criador John Zachman, que foi o primeiro a desenvolver o
conceito de arquitetura corporativa nos anos 80, enquanto trabalhava na IBM. Mas este modelo tem
sido atualizado constantemente desde a sua criao.
O Framework Zachman uma estrutura fundamental que define uma maneira estruturada e formal
para descrever uma arquitetura corporativa.
Este modelo define a infraestrutura de informao de uma empresa a partir de uma matrix de duas
dimenses. A primeira vem das questes primordiais: O que, Quem, Quando, Onde, e Por que. A
segunda vem da perspectiva dos principais stakeholders (interessados):
Planejador,
Proprietrio,
Projetista,
Construtores,
Subcontratados, e
Sistema de trabalho.
No h orientao em sequncia, processo ou aplicao do quadro. O foco est em garantir que todos
os aspectos de uma empresa sejam bem organizados e apresentem relaes claras que assegurem um
sistema completo, independentemente da ordem em que esto estabelecidas.
09
3.1.2 Estrutura do Framework
O Framework Zachman pretende proporcionar uma compreenso de qualquer aspecto particular de um
41
sistema em qualquer ponto do seu desenvolvimento. A ferramenta pode ser til na tomada de decises
sobre as alteraes ou ampliaes no que se refere tecnologia de informao para a organizao.
A ideia bsica por trs do Framework Zachman que a mesma coisa, seja ela simples ou complexa,
possa ser descrita para fins diferentes de formas diferentes, inclusive utilizando diferentes tipos de
descries (por exemplo, textual, grfica). Como uma matriz de duas dimenses com 6 linhas e 6
colunas, o Framework Zachman fornece trinta e seis categorias para descrever completamente a
arquitetura corporativa.
Ele permite que pessoas diferentes olhem para a mesma coisa de diferentes perspectivas. Isso cria uma
viso holstica do ambiente.
Modelo Zachman
As duas primeiras linhas so intensamente orientadas para negcios e podem ser expressas em
vocabulrios orientados a negcios, enquanto que as quatro linhas inferiores esto no domnio tcnico.
42
Conceitos de negcio da linha superior devem ser incorporados a objetos de negcios e componentes
nas linhas de fundo. Os conceitos de negcio podem ser refinados ao longo do tempo, mas seus
relacionamentos no devem ser alterados.
Os requisitos so capturados por coluna, e os agentes so associados com a coluna. Como a ordem das
colunas no tem nenhum significado estabelecido, eles poderiam ser reorganizados para acompanhar a
necessidade da empresa.
Escopo
Corresponde a um resumo executivo de um planejador que quer uma estimativa do
tamanho, custo e funcionalidade do sistema.
Modelo de negcio
Mostra todas as entidades e processos de negcio e como eles interagem.
Modelo do sistema
Usado por um analista de sistemas que devem determinar os elementos de dados e
funes de software que representam o modelo de negcio.
Modelo de tecnologia
Considera as limitaes das ferramentas, tecnologia e materiais.
Componentes
Representam mdulos individuais, independentes, que podem ser atribudoss aos
empreiteiros para a implementao.
Sistema de trabalho
Descreve o sistema operacional.
Quando
Representa o tempo, ou as relaes de eventos que estabelecem critrios de
desempenho e nveis quantitativos para os recursos da empresa. Isso til para a
concepo do plano- mestre, a arquitetura de processamento, arquitetura de controle e
dispositivos de temporizao.
43
Quem
Representa os povos relacionamentos dentro da empresa. O projeto da organizao
empresarial tem a ver com a atribuio de trabalho e da estrutura de autoridade e
responsabilidade. A dimenso vertical representa delegao de autoridade, ea horizontal
representa a atribuio de responsabilidade.
Por que
Descreve as motivaes da empresa. Isso revela os objetivos da empresa e objetivos,
plano de negcios, arquitetura de conhecimento, e conhecimento de design.
O que
Descreve as entidades envolvidas em cada perspectiva da empresa. Exemplos incluem
objetos de negcios, dados do sistema, tabelas relacionais ou definies de campo.
Como
Mostra as funes dentro de cada perspectiva. Exemplos incluem processos de negcio,
funo de aplicao de software, funo de hadware de computador e malha de controle de
idioma.
Onde
Mostra locais e interligaes dentro da empresa. Isso inclui os principais locais de visita geogrficas,
sees separadas dentro de uma rede logstica, alocao de ns do sistema, ou at mesmo endereos
de memria dentro do sistema.
10
O Framework tem um conjunto de 7 regras bsicas:
Regra 1 - As colunas no tm Ordem
As colunas so intercambiveis, mas no podem ser reduzidas ou criadas.
Regra 2 - Cada coluna tem um modelo genrico simples
44
Cada coluna pode ter sua prpria meta-modelo.
Regra 3 - O modelo bsico de cada coluna deve ser exclusivo
O modelo bsico de cada coluna, os objetos de relacionamento e a estrutura so nicas. Cada objeto
de relacionamento interdependente, mas o objetivo da representao nico.
Regra 4 - Cada linha descreve uma perspectiva distinta, nica
Cada linha descreve o ponto de vista de um grupo empresarial em particular e exclusivo para ele.
Todas as linhas so geralmente presentes na maioria das organizaes hierrquicas.
Regra 5 - Cada clula nica
A combinao de 2,3 e 4 devem produzir clulas nicas, onde cada clula representa um caso
particular.
Regra 6 - O composto ou a integrao de todos os modelos de clulas em uma linha constitui um

modelo completo a partir da perspectiva da referida linha
Pela mesma razo, como por no adicionar linhas e colunas, mudando os nomes podem alterar a
estrutura lgica fundamental do quadro.
Regra 7 - A lgica recursivo
A lgica relacional entre duas instncias da mesma entidade.
11
3.2 The Open Group Architectural Framework - TOGAF
The Open Group Architectural Framework, ou simplesmente TOGAF, foi criado pelo The Open Group no
incio dos anos 90.
TOGAF desempenha um papel importante para ajudar a sistematizar o processo de desenvolvimento de

arquitetura, permitindo que os usurios possam construir solues baseadas em sistemas abertos para
as suas necessidades de negcios. Empresas que no adotam em uma arquitetura corporativa acabam
adotando uma soluo de um nico fornecedor na busca de uma soluo integrada. Com isso a empresa
deixa de obter os benefcios, inclusive financeiros, de ter diferentes fornecedores de sistemas possveis
de serem integrados atravs de uma arquitetura verdadeiramente aberta.
45
Normalmente, uma arquitetura desenvolvida porque as pessoas tm preocupaes fundamentais que

precisam ser abordadas pelos sistemas de TI dentro da organizao. Tais pessoas so comumente
referidas como as partes interessadas no sistema.
O papel do arquiteto observar e atender s preocupaes externadas

pelos usurios dos sistemas de TI. O arquiteto atende s preocupaes
dos usurios identificando e refinando seus requisitos, apresentando
diferentes vises da arquitetura que mostram como as preocupaes e
as necessidades vo sero atendidas, e mostrando as mudanas e
concesses necessrias para que preocupaes potencialmente
conflitantes possam ser atendidas. Sem a participao do arquiteto
improvvel que todas as preocupaes e requisitos sejam atendidos.
The Open Group
The Open Group um consrcio de empresas de tecnologia. Atualmente, conta com mais de 400
membros. Os servios prestados incluem estratgia, gesto, inovao e investigao, normas,
certificao e desenvolvimento de testes. Entre os membros encontram-se empresas como IBM, HP,
Oracle, SAP, Nasa e Departamento de Defesa Americano.
12
TOGAF composto de trs partes principais:
A) O TOGAF Architecture Development Method (ADM), que explica como obter uma arquitetura
empresarial especfica da organizao que aborda os requisitos de negcios. A ADM fornece o seguinte:
Uma maneira confivel e comprovada de desenvolvimento da arquitetura;
Vises de arquitetura que permitem ao arquiteto garantir que um conjunto complexo de

requisitos seja tratado de forma adequada;
Vnculos a estudos de casos prticos;
Orientaes sobre ferramentas para arquitetura de desenvolvimento.
B) A Enterprise Continuum, um "repositrio virtual" de todos os ativos de modelos de arquitetura,

padres, descries arquitetura etc., que existem tanto dentro da empresa quanto na indstria de TI em
geral, que a empresa considera ter disponvel para o desenvolvimento de arquiteturas.
46
O TOGAF fornece dois modelos de referncia para considerao:
Modelo de Arquitetura Modelo de Soluo
C) O TOGAF Resource Base, que um conjunto de recursos-diretrizes, modelos, informaes de fundo

etc., para ajudar o arquiteto no uso da ADM.
TOGAF publicado pela The Open Group em seu Web site pblico, e pode ser reproduzido livremente
por qualquer empresa que deseje utiliz-lo para desenvolver uma arquitetura corporativa para uso
dentro dessa empresa. Basicamente, as informaes sobre os benefcios e limitaes da aplicao
existente, juntamente com os requisitos para a mudana, so combinados usando os mtodos
descritos no TOGAF ADM, resultando em uma "arquitetura de destino" ou conjunto de arquiteturas
de destino.
Modelo de Arquitetura
So servios e funes genricas que fornecem uma base sobre a qual arquiteturas especficas e
blocos de construo de arquitetura podem ser construdos. Esta arquitetura, por sua vez inclui:
Modelo de Referncia Tcnica (TRM), que fornece um modelo e taxonomia de servios de

plataforma genricos; e
Padres Information Base (SIB), uma base de dados de padres industriais abertos que
podem ser usados para definir os servios particulares e outros componentes de uma
arquitetura especfico da empresa.
Modelo de Soluo
especificamente destinado a ajudar o desenvolvimento de arquiteturas que permitem e apiam a

viso de "fluxo de informao sem fronteiras."
13
3.3- The Department of Defense Architecture Framework (DoDAF)
Em meados da dcada de 1990, em resposta s exigncias relacionadas com a articulao multisservio

e operaes militares multinacionais, o Departamento de defesa discernido com a necessidade de uma
formulao de um padro arquitetnico para garantir que os sistemas militar poderia interoperar.
47
O objetivo do DoDAF verificar que as descries arquitetnicas desenvolvidas pelos vrios

comandos, servios e agncias so compatveis e que, dos pontos de vista tcnicos, as arquiteturas
so utilizveis e integrvel em vrios domnios organizacionais. Este quadro aborda o domnio militar
e usado principalmente pelo Departamento de Defesa.
Semelhante a qualquer outra estrutura de arquitetura, ele fornece as regras e orientaes para o
desenvolvimento e apresentao de descries de arquitetura corporativa, incluindo artefatos. Ele
fornece contribuio sobre a forma de descrever arquiteturas, mas que no fornece mecanismos em
como construir e implementar uma arquitetura especfica ou como desenvolver sistemas ou um
processo para aquisio de sistemas.
DoDAF est organizado em trs partes:
Volume Volume Volume

I II III
Volume I
Fornece orientao geral sobre a necessidade e a utilizao de denominaes de arquitetura em DoD.
Volume II
Apresenta definies dos 26 produtos contidos nos trs vises do modelo.
Volume III
um Deskbook que fornece exemplos de arquiteturas que so compatveis, abordagens para a

realizao de desenvolvimento arquitetura, e outras informaes de suporte. Para estar em
conformidade com o framework, descries arquitetura deve incluir o conjunto adequado de
produtos e usar os termos e definies comuns especificados no quadro.
14
Como se observa, as descries arquitetnicas de DoDAF requerem o uso de mltiplas vises, cada uma
das quais transmite diferentes aspectos da arquitetura. A arquitetura integrada do DoDAF dispe das
seguintes vises:
Viso operacional;
48
Viso de Sistemas;
Viso de Normas Tcnicas.
Todas as vises ampliam as outras vises, fornecendo contexto, descries e um dicionrio integrado de
termos.
Viso operacional
Descreve o que est acontecendo no mundo real que est a ser apoiado ou habilitado por sistemas
representados na arquitetura. Atividades realizadas como parte de misses do DoD e as trocas de
informaes entre os profissionais associados ou organizaes so os itens principais modelados em
vista operacional. O ponto de vista operacional revela requerimentos para a capacidade e
interoperabilidade.
Viso de Sistemas
49
Descreve existentes e futuros sistemas e interligaes fsicas que suportam as necessidades DoD
documentados na viso operacional.
Viso de Normas Tcnicas
Composta por catlogos padro (comercial off-the-shelf [COTS], o governo off-the-shelf [GOTS]),
peas do sistema ou componentes e suas interconexes. Essa viso aumenta os sistemas de visualizar
com detalhes tcnicos e as previses de evoluo da tecnologia padro.
15
4- ARQUITETURA CORPORATIVA X ARQUITETURA DE SOFTWARE

O que difere a arquitetura corporativa da arquitetura de software? Conhecer a existncia destes dois
conceitos e identificar qual o escopo de cada um um conhecimento importante para todo profissional
de TI.
CEOs de hoje sabem que a gesto eficaz e a explorao da informao atravs da TI so a chave para o
sucesso do negcio, e os meios indispensveis para alcanar vantagem competitiva.
A arquitetura empresarial aborda esta necessidade, fornecendo um contexto estratgico para a

evoluo do sistema de TI em resposta s necessidades em constante mudana do ambiente de
negcios. Alm disso, uma boa arquitetura corporativa permite que se atinja o equilbrio certo entre a
eficincia de TI e inovao empresarial.
Ela permite s unidades de negcios individuais inovar em segurana na sua busca de vantagem
competitiva. Ao mesmo tempo, assegura as necessidades da organizao de uma estratgia integrada
de TI, permitindo a sinergia mais prxima possvel em toda a empresa.
J a arquitetura de software a disciplina que faz parte da esteira de desenvolvimento de software

responsvel por definir e descrever o comportamento do sistema.
A arquitetura de software serve como modelo para o sistema e do projeto que visa desenvolv-lo,
definindo as atribuies do trabalho que devem ser realizado pela equipe de design e implementao. A
arquitetura a principal responsvel pelas dimenes da qualidade do sistema, tais como desempenho,
facilidade em absorver as mudanas e segurana, nenhuma das quais pode ser alcanada sem uma viso
de arquitetura unificada.
50
Arquitetura a forma para realizar a anlise, cedo no desenvolvimento

de software, para se certificar de que uma abordagem de projeto ir
produzir um sistema aceitvel. Atravs da construo de arquitetura
eficaz, voc pode identificar os riscos do projeto e mitig-los logo no
incio do processo de desenvolvimento.
16
4.1- A diferena do Arquiteto de Software e do Arquiteto Corporativo
Aps verificar a diferena entre a arquitetura corporativa e a arquitetura de software natural

identificarmos que so necessrios profissionais com perfis diferentes para exercer e executar cada tipo
de arquitetura.
Arquiteto de Software (como o nome J o arquiteto corporativo um papel de

sugere) se concentra em software, ou seja, planejamento que responsvel por
em um assunto especfico. Este profissional identificar o estado futuro do ambiente de TI
responsvel pela qualidade do sistema, da de uma organizao e envolver os recursos
soluo a ser entregue para a empresa. necessrios para ajudar a equipe do projeto
guia para entregar em direo a ela.
Assim, o arquiteto de software e o arquiteto corporativo so papeis muito diferentes, onde o primeiro,
foca na entrega de solues e o seguindo concentra-se em apoiar os projetos atravs da documentao
de estado futuro e est envolvido em atividades de governana.
17
RESUMO
Vimos que a arquitetura corporativa um modelo para o posicionamento ideal de recursos no ambiente
de TI de uma empresa.
Existe uma srie de modelos de arquitetura corporativa disponveis no mercado. Entretanto, no existe
um consenso sobre qual modelo o mais completo e qual o que deve ser utilizado pelas empresas.
O investimento na definio de uma arquitetura corporativa e importantes, pois proporciona:
Uma operao de TI mais eficiente;
51
Menores custos de desenvolvimento de software, suporte e manuteno;
O aumento da portabilidade de aplicaes;
Melhor interoperabilidade, sistema e gerenciamento de rede mais fceis.
Uma melhor capacidade para abordar questes crticas em toda a empresa, como a segurana;
Atualizao mais fcil e troca de componentes do sistema;
Melhor retorno sobre o investimento existente e reduo do risco para futuros investimentos;
Complexidade reduzida em infraestrutura de TI;
O mximo retorno sobre o investimento em infra-estrutura de TI existente;
A flexibilidade de fazer, comprar, ou terceirizar solues de TI;
Reduo do risco global em novos investimentos e os custos de propriedade de TI;
Aquisies mais rpida, mais simples, mais barata;
Decises de compra mais simples.
Atualmente, os modelos mais utilizados pela indstria so Zachman, TOGAF e DoDAF.
Vimos que enquanto a arquitetura corporativa fornecendo um contexto estratgico para a evoluo do
sistema de TI em resposta s necessidades em constante mudana do ambiente de negcios a
arquitetura de software tem a responsabilidade de definir e descrever o comportamento do sistema.
Por fim, foi estudado que o arquiteto de software e o arquiteto corporativo so papeis muito diferentes,
onde o primeiro foca na entrega de solues e o segundo, concentra-se em atividades de governana de
TI.

MDULO 4 PADRES DE ARQUITETURA DE SOFTWARE
01
1- SISTEMAS CENTRADOS NOS DADOS

J estudamos o que a arquitetura de software e sua importncia. Durante nosso estudo vimos que
sistemas de software precisam ser cuidadosamente arquitetados e avaliados a partir de vrias
52
perspectivas para abordar adequadamente vrias preocupaes que afetam a qualidade do produto
final.
Durante o processo para definir a arquitetura de um sistema necessrio resolver problemas de design
de diferentes naturezas, como problemas que lidam com a estrutura do sistema lgico ou problemas
que lidam com o sistema dinmico, simultaneamente. Em todos os casos, essencial identificar os
componentes necessrios, as interfaces e as responsabilidades de cada componente. importante
tambm modelar interaes comportamentais entre eles antes de passar para o projeto detalhado.
A partir desta perspectiva, importante usar a experincia passada com decomposies lgicas
juntamente com suas interfaces ao projetar sistemas de software. Para este fim, os conceitos de estilos
arquitetnicos e padres arquitetnicos surgiram como a principal abordagem para alcanar a
reutilizao de arquitetura. Estes conceitos so fundamentais para a criao eficiente de arquiteturas de
software, fornecendo uma estratgia global para a concepo de famlias de sistemas de software.
Os diferentes estilos fornecem solues arquitetnicas, genricos e reutilizveis de uma forma que
possa ser facilmente compreendida e aplicada a novos problemas que exigem caractersticas
arquitetnicas semelhantes.
Desta forma, um padro descreve uma soluo para um problema que ocorre com frequncia
durante o desenvolvimento de software, podendo ser considerado como um par
problema/soluo. Um padro um conjunto de informaes instrutivas que possui um nome e
que capta a estrutura essencial e o raciocnio de uma famlia de solues comprovadamente bem
sucedidas para um problema repetido que ocorre sob um determinado contexto e um conjunto de
repercusses.
A escolha da aplicao de padres de arquitetura para projetar algum elemento arquitetnico depende
do tipo particular de sistema, requisitos e atributos de qualidade desejados. Estas caractersticas ajudam
a orientar a seleo de um padro especfico em detrimento de outro. Em outros casos, diferentes
padres podem ser utilizados em conjunto para satisfazer as caractersticas de um sistema deixando a
cargo da equipe de design escolher o padro mais apropriado para o projeto. Projetistas familiarizados
com certos padres podem inclusive aplic-los imediatamente a problemas de projeto, sem ter que
redescobri-los.
Alguns padres arquitetnicos so encontrados no mais alto nvel de decomposio do sistema, sendo
muito abstratos para produzir um projeto concreto do sistema; portanto, esses padres no esto
vinculados a uma implementao do sistema particular, mas podem ser associados a tipos (ou famlias)
de sistemas de modo que sua soluo possa ser reutilizada em vrios sistemas do mesmo tipo.
As diversas classificaes de padres so apresentadas na tabela a seguir.
53
Tipo Descrio
Sistemas que servem como um repositrio centralizado para dados,

Centrado nos Dados
permitindo que os clientes acessem e mantenham os dados.
Sistemas orientados em torno do transporte e transformao de um fluxo

Fluxo de Dados
de dados.
Os sistemas que envolvem principalmente a interao entre vrias unidades

Distribudo
de processamento independentes ligados atravs de uma rede.
Interativo Sistemas que servem ao usurio ou so voltados ao usurio.
Os sistemas nos quais componentes podem ser estruturados como uma

Hierrquico hierarquia (vertical e horizontal) para refletir diferentes nveis de abstrao
e responsabilidade.
Para melhor entendermos esta classificao, vamos explorar cada um destes tipos de padres.
Abstratos
Existem padres arquiteturais em que o nvel de abstrao bastante alto, tais como: padres de
anlise, padres de projeto, padres de cdigo, entre outros.
02
Sistemas centrados nos dados so sistemas decompostos principalmente em torno de repositrio

central de dados. Portanto, as responsabilidades tpicas encontradas nos componentes do sistema
centrado em dados incluem um gerenciador de dados centralizado e vrios componentes de trabalho.
Os controles componente gerenciador de dados, fornece e gerencia o acesso aos dados do sistema,
enquanto que os componentes de trabalho executam operaes e executam o trabalho com base nos
dados.
A comunicao em sistemas centrados nos dados caracterizada por uma comunicao um para um
bidirecional entre os componentes de trabalho e os componentes do gerenciador de dados. Assim, os
componentes de trabalhado no interagem uns com os outros diretamente. Toda a comunicao passa
pelo gerenciador de dados.
54
Exemplos de sistemas centrados nos dados incluem sistemas especialistas, que interagem com um
sistema de gerenciamento de banco de dados para armazenar e recuperar informaes de base de
conhecimento.
Um exemplo de um padro de arquitetura para sistemas centrados nos dados inclui o padro de
arquitetura quadro-negro (Blackboard Pattern), que ser apresentado a seguir.
03
1.1- Blackboard Pattern arquitetura quadro-negro
Para entendermos o funcionamento do padro de arquitetura quadro-negro vamos imaginar um grupo

de cientistas tentando resolver um problema complexo.
55
04
De posse deste entendimento, podemos definir que o padro de arquitetura quadro negro se
decompe em componentes de sistemas de software que funcionam em torno de um componente
central de dados, o quadro negro, para fornecer solues para problemas complexos. Estes
componentes funcionam independentemente uns dos outros para fornecer solues para problemas.
No h uma sequncia de operaes pr-determinada ou correta para alcanar a soluo do
problema. O acesso ao componente central de dados pode ser feito por meio de uma referncia
direta memria ou consultas ao banco de dados.
56
Esse estilo faz uso de um repositrio central de dados circundado por um conjunto de componentes (ou
clulas) de informaes. Esses componentes contm informaes necessrias soluo de problemas.
Os dados da soluo de problemas so mantidos na base de dados compartilhada.
A figura abaixo demonstra como este padro organizado em termos de componentes.
05
As principais vantagens da utilizao do padro de arquitetura quadro negro incluem sua mutabilidade,
reutilizao e facilidade de manuteno. Estas propriedades de qualidade vm como resultado de
compartimentar fontes de conhecimento e estabelecer um mtodo normalizado para a utilizao do
repositrio central. Uma vez que cada agente precisa saber s a forma de comunicar com o quadro
negro, novos agentes podem ser introduzidos sem muito esforo para melhorar as capacidades do
sistema.
Alm disso, por compartimentar fontes de conhecimento, mudanas no sistema so tambm

compartimentadas. Portanto, as mudanas em um agente no afetam outros agentes do sistema.
Finalmente, compartimentalizao de agentes suporta fcil reutilizao em futuros sistemas.
As propriedades de qualidade do padro de arquitetura quadro-negro so apresentadas a seguir:
Mutabilidade
57
Os agentes so compartimentados e independentes uns dos outros. Assim, fcil de adicionar ou

remover os agentes para ajustar os novos sistemas.
Reutilizao
Componentes especializados podem ser reutilizado facilmente em outras aplicaes.
Facilidade de manuteno
Devido independncia dos agentes, a manuteno de componentes existentes torna-se mais fcil.
06
2 - SISTEMA DE FLUXO DE DADOS

Um sistema de fluxo de dados tem como premissa o transporte e a transformao de dados para
atender aos requisitos especficos de um sistema. Desta forma, este tipo de sistema pode ser
decomposto em
componentes de trabalho e
componentes de transportes.
Como o prprio nome sugere, os componentes de trabalho so responsveis por realizar as

transformaes dos dados que necessitam ocorrer antes que estes dados possam ser transportados
para os outros compoentes.
Exemplos de trabalhos ocorridos nestes tipos de componentes so: criptografia, descriptografia,

compresso e descompresso.
Os componentes de transporte, por sua vez, so responsveis por realizar a gesto e controle dos
mecanismos de transporte de dados, que podem incluir a comunicao entre processos, comunicao
baseada em soquete e interfaces seriais.
Os componentes de trabalho e os componentes de transporte se combinam para formar elementos

arquitetnicos dos sistemas de fluxo de dados. Sistemas de fluxo de dados fornecem os meios para a
transformao de dados, que ocorrem em srie ou em paralelo, o que ajuda a melhorar o desempenho
do sistema atravs da adio de simultaneidade para o sistema. Um exemplo de um padro de
58
arquitetura para sistemas de fluxo de dados o padro de arquitetura Pipe e Filter, que veremos a
seguir.
07
2.1- Pipe e Filter Pattern
O padro de arquitetura Pipe (tubo) e Filter (filtro) se decompe em componentes que realizam duas
funes principais:
processamento e transformao de dados e
transferncia de dados entre componentes.
Componentes responsveis pelo processamento de dados e de transformao so referidos como

filtros, enquanto componentes que transferncia de dados entre componentes so referidos como
tubos.
Em conjunto, estes componentes so combinados de vrias formas para criar uma famlia de sistemas
relacionados que processam correntes de dados. Os tubos e filtros como padro de arquitetura so
comumente vistos em sistemas de fluxo de dados, onde as entradas de dados precisam ser
transformadas em sada de dados atravs de uma srie de componentes de clculo ou manipuladores.
A estrutura de Pipe e Filter est presentada na figura abaixo.
As principais caractersticas que constituem as vantagens do padro arquitetural Pipe (tubo) e Filter
(filtro) so apresentadas a seguir:
59
Extensibilidade
Filtros de processamento podem ser adicionados facilmente para proporcionar mais capacidades.
Eficincia
Ao ligar os filtros em paralelo, simultaneidade pode ser alcanada para reduzir a latncia no sistema.
Reutilizao
Por compartimentar tubos e filtros, eles podem ser reutilizados em outros sistemas.
Modificabilidade
Os filtros so compartimentados e independentes um do outro; por conseguinte, fcil de adicionar

ou remover filtros para melhorar o sistema.
Segurana
Em qualquer ponto durante o fluxo de dados, os componentes de segurana podem ser injectados
para o fluxo de trabalho para proporcionar diferentes tipos de mecanismos de segurana para os
dados.
Manutenibilidade
Permite a separao de preocupaes e independncia dos filtros e tubos; por conseguinte, a

manuteno de componentes existentes torna-se mais fcil.
08
3 - SISTEMA DISTRIBUDO
Os sistemas distribudos so vulgarmente conhecidos como sistemas decompostos em vrios processos
que colaboram atravs da rede. Este padro amplamente difundido atualmente graas a tecnologias
como: internet mvel e sem fio.
Em alguns sistemas distribudos, um ou mais processos distribudos executam o trabalho em nome de

usurios do cliente e fornece uma ponte para algum computador servidor, geralmente localizado
remotamente e executam o trabalho delegado a ele por parte do cliente. Uma vez concludo, os
resultados so normalmente retornados para os clientes para visualizao e processamento
posterior.
60
Outros sistemas distribudos podem ser compostos por ns com capacidades semelhantes e
colaborando entre si para fornecer servios avanados. Estas formas de sistemas distribudos so bem
conhecidas, no sentido de que a sua arquitetura de implantao envolve, tipicamente, mltiplos ns. No
entanto, com o advento de mltiplas arquiteturas de CPU, arquiteturas distribudas tambm so
relevantes para software que executado em um nico n com capacidade de multiprocessador.
As principais preocupaes para sistemas distribudos podem incluir:
desempenho,
confiabilidade,
disponibilidade,
segurana e
interoperabilidade.
Padres arquitetnicos comuns para estes sistemas incluem: Cliente Servidor e Broker.
09
3.1- Padro Cliente-Servidor
A arquitetura cliente-servidor um padro popular, presente na arquitetura de sistemas modernos de

hoje. Ele decompe sistemas de software em dois componentes principais: o cliente e o servidor. Esses
componentes so manifestados como processos individuais que podem ser distribudos atravs da rede
ou dentro de um nico n.
Sistemas cliente-servidor no so determinados apenas por processos de separao ou atravs da

distribuio de processos em toda a rede, mas por ter um processo, o cliente, dependente dos
servios prestados por outro processo, o servidor.
O exemplo mais difundido de um sistema cliente-servidor hoje inclui o cliente navegador e o servidor
web. Ao procurar um determinado site usando o navegador web, uma conexo feita para o servidor,
solicitaes so enviadas e recebidas e o servidor processa as solicitaes e envia as respostas ao
cliente. Note que isto verdadeiro independentemente do local onde se encontra o cliente, podendo
inclusive estar no mesmo n que o servidor. O importante que este cliente possa se conectar ao
servidor. A figura a seguir apresenta o padro de arquitetura cliente-servidor.
10
61
Sistemas cliente-servidor so particularmente teis para sistemas distribudos a uma grande base de
clientes, uma vez que fornecem a localizao de dados em um lugar central. Portanto, fazer atualizaes
ou adicionar novas informaes num local centralizado o suficiente para uma multido de clientes
receber tais informaes. As vantagens associadas aos sistemas cliente-servidor so identificadas a
seguir:
Interoperabilidade
Permite que os clientes em diferentes plataformas possam se comunicar com servidores de

diferentes plataformas.
Modificabilidade
Permite mudanas centralizadas no servidor e distribuio rpida entre muitos clientes.
Disponibilidade
Ao separar os dados do servidor, vrios ns de servidor podem ser conectados como cpia de
segurana para aumentar os dados do servidor ou a disponibilidade dos servios.
Reutilizao
Ao separar servidor de clientes, servios ou dados fornecidos pelo servidor podem ser reutilizados em
diferentes aplicaes.
11
3.2- Padro Broker
O padro de arquitetura Broker fornece mecanismos para alcanar uma melhor flexibilidade entre
clientes e servidores em um ambiente distribudo. No padro de arquitetura cliente-servidor, os
clientes acessam diretamente os servios de servidores, o que pode obrig-los a estabelecer uma
conexo direta ou utilizar outros mecanismos de comunicao entre processos para se comunicar
com o servidor.
Isso resulta em um maior grau de acoplamento entre clientes e servidores, o que leva complexidade
dos sistemas esperados para evoluir, fornecendo servios a partir de diferentes servidores hospedados
em locais diferentes. Em alguns casos, terminais de cliente precisam ser capazes de acessar os servios
de vrios servidores sem conhecer as suas localizaes reais ou detalhes particulares de comunicao
para ter acesso a esses servios. Isso leva a sistemas com maior interoperabilidade e flexibilidade.
62
O padro de arquitetura Broker tem como objetivo diminuir a dependncia entre os clientes e os
servidores para que um cliente possa acessar de maneira transparente os servios de diferentes
servidores.
Em vez de acessar diretamente um servidor, os clientes acessam suas funcionalidades atravs de um

componente do broker, que localiza servidores apropriados, encaminha as solicitaes, e transmite
respostas (incluindo excees) de volta para clientes. Com este mecanismo, os clientes podem solicitar
servios como se eles fossem fornecidos localmente no mesmo n que o servidor, quando esto de fato
em ns diferentes.
12
Os principais participantes do padro arquitetnico Broker so apresentados a seguir:
Cliente As aplicaes que utilizam os servios prestados por um ou mais servidores.
Componente que fornece transparncia (pelo cliente) entre os componentes

Clientproxy
remotos e locais para que os componentes remotos apaream como locais.
Corretor Componente que faz a mediao entre os componentes de cliente e servidor.
Componente que fornece transparncia (no servidor) entre os componentes

ServerProxy
remotos e locais para que os componentes remotos apaream como locais.
Prestao de servios aos clientes; tambm pode atuar como cliente para o
Servidor
corretor.
Ponte Componente opcional para encapsular a interoperao entre os corretores
12
63
As vantagens deste padro arquitetural esto listadas a seguir:
Interoperabilidade
Permite que os clientes em diferentes plataformas para interoperar com servidores de diferentes
plataformas; tambm permite que os clientes para interoperar (transparente) com vrios servidores
Modificabilidade
Permite mudanas centralizadas no servidor e distribuio rpida entre muitos clientes
Portabilidade
Por portar o corretor para diferentes plataformas, os servios prestados pelo sistema podem ser
facilmente adquiridas por novos clientes em diferentes plataformas
Reutilizao
Corretores muitas chamadas do sistema abstratos necessrios para a prestao de comunicao

entre os ns; ao usar corretores, muitos servios complexos podem ser reutilizados em outras
aplicaes que requerem operaes distribudas semelhantes
13
4 - SISTEMAS INTERATIVOS
Sistemas interativos so sistemas que suportam interaes do usurio, geralmente por meio de
interfaces de usurio.
Ao projetar sistemas interativos, alternativas de projeto concentram em dois atributos de qualidade

principais: usabilidade e modificabilidade.
Usabilidade refere-se meta de qualidade que visa minimizar o grau de complexidade envolvido no
aprendizado e na utilizao do sistema. Sistemas so projetados de tal forma que os usurios possam
rapidamente tornar-se proficientes no sistema; eles tambm respondem a solicitaes de usurios
rapidamente para suportar os requisitos de alta interatividade.
Para maximizar a modificabilidade em sistemas interativos, a interface grfica de usurio deve ser
desacoplada do ncleo do sistema funcional. Ao fazer isso, o ncleo-funcional se torna mais estvel uma
64
vez que a interface de usurio mais propensa mudana. O padro de arquitetura iterativo o MVC
Model-View-Controller, que ser apresentado a seguir.
14
4.1- Padro Modelo-Viso-Controlador (Model-View-Controller)
O padro de arquitetura MVC usado em aplicaes interativas que exigem flexibilidade na interface do
sistema. Com o MVC, os sistemas so decompostos em trs componentes principais que lidam de forma
independente:
componente de entrada,
processamento e
sada do sistema.
Ao separar a sada do sistema de suas funes de processamento centrais, diferentes representaes do

ncleo do sistema podem ser facilmente suportadas.
Os principais componentes do padro de arquitetura MVC so:
Modelo;
Viso;
Controlador.
Os compoentes viso e controlador trabalham em conjunto como parte da interface do usurio para
aceitar a entrada do usurio e transformar essa entrada para um formato compatvel com o
componente do modelo. Em algumas variantes do MVC, a responsabilidade dos controladores e vises
fundida em um componente.
Modelo
Componente que representa o ncleo dos sistemas.
Viso
Componente que representa a apresento do sistema. A interface do usurio.
Controlador
Componente (associado com uma viso) que lida com entradas do usurio
65
15
A relao entre os componentes modelo, viso e controlador pode variar dependendo da aplicao; no
entanto, no mnimo, projetos MVC fornecem relaes que permitem mudanas no modelo para
adequar-se ao seu ponto de vista e, quando necessrio, aos controladores. Desta forma, os sistemas
MVC fornecem uma abordagem sistemtica, flexvel e controlada por aceitar entradas e proporcionar
sadas do sistema.
Como um padro de arquitetura, MVC define as interfaces necessrias

para os mecanismos de propagao entre os componentes modelo,
viso e controlador. No entanto, no so especificados os detalhes de
como o mecanismo de propagao de mudana de fato
implementado. Os pormenores de tais mecanismos so deixados a
cargo do projeto.
16
5 - SISTEMAS HIERRQUICOS
Sistemas hierrquicos so sistemas nos quais componentes podem ser estruturados de forma
hierrquica, de modo que os componentes existem em diferentes nveis de abstrao e cada nvel
aborda uma preocupao particular do sistema de software.
Conceitualmente, os componentes que residem em nveis mais altos da hierarquia encaminham suas
requisies para os componentes de nveis abaixo. Em alguns casos, o acesso aos servios prestados nos
diferentes nveis podem ser unificados, permitindo compartimentar e aumentar a capacidade de
reutilizao dos seus servios. Em outros casos, a estrutura hierrquica mapeada para o tratamento de
dados, resultando em um conjunto de componentes funcionais coesos em nveis adequados de
abstrao para a criao de sistemas modulares.
Em qualquer caso, a concepo de sistemas em forma hierrquica normalmente leva a sistemas bem
estruturados e modulares. Dois padres arquitetnicos comuns para os sistemas hierrquicos so:
Programa principal e sub-rotina;
Camadas.
Ambos os padres sero apresentados a seguir.
66
17
5.1- Programa principal e sub-rotinas
O padro arquitetnico de programa principal e sub-rotina popular em sistemas que so projetados

usando a estratgia de design estruturado (ou funcional).
Nestes sistemas, um componente principal contm os principais dados para o programa, que
compartilhado entre os componentes que residem em nveis mais baixos da hierarquia. Cada nvel da
hierarquia representa refinamentos do sistema, de modo que o nvel n fornece o nvel principal; nvel
n + 1 fornece refinamentos de servios; n + 2 fornece mesmo refinamentos, e assim por diante. Este
processo continua at que o sistema seja decomposto em um conjunto apropriado de componentes
ou sub-rotinas.
Os principais componentes identificados no padro de arquitetura de programa principal e sub-rotina

incluem um componente principal, que armazena todos os dados, e vrios subcomponentes que
realizam operaes detalhadas do sistema.
Os sistemas baseados nesse padro de arquitetura tm como principal benefcio sua decomposio
estruturada. Esta decomposio proporciona componentes independentes e com uma nica finalidade,
o que torna mais fcil de entender, gerenciar, depurar e reutilizar.
Os principais benefcios associados ao padro de arquitetura de programa principal e sub-rotina

principal so:
Modificabilidade.
Reusabilidade.
Modificabilidade
Ao se decompor o sistema em componentes de finalidade nica independentes, cada componente

torna-se mais fcil de entender e gerenciar.
Reusabilidade
Componentes independentes podem ser reutilizados em outros sistemas.
67
18
5.2- Padro de Camadas
O padro de arquitetura de programa principal e sub-rotina conduz a estruturas hierrquicas que se

expandem verticalmente e horizontalmente, com cada nvel de hierarquia contendo um ou mais
componentes que podem interagir com um ou mais componentes com nveis mais baixos da hierarquia.
Uma forma mais restrita da estrutura hierrquica envolve que cada camada pode ter um componente
principal, que pode ser composto internamente de vrios componentes, que fornece uma interface
unificada para comunicao com componentes que residem imediatamente abaixo na estrutura de
hierarquia. Esta forma de colaborao restrita definida como arquitetura em camadas.
Com o padro de arquitetura em camadas, o trabalho realizado para implementar uma funo do
sistema mais compartimentada do que no programa principal e sub-rotina. Ele usado quando os
sistema pode ser decomposto em camadas coesas com uma forma estruturada de interface entre as
camadas.
A arquitectura em camadas amplamente utilizada em sistemas como a pilha de comunicao de um

sistema operacional, onde cada camada uma abstrao das principais funes de comunicao do
sistema operacional. Cada camada tambm depende do servios de outras camadas diretamente abaixo
para criar pacotes de comunicao e para proporcionar qualidade de servio, servios de roteamento,
comunicao ponto a ponto e transmisso usando as diferentes camadas fsicas. Desta forma, as regras
podem ser impostas a arquitetura lgica do sistema para restringir o acesso entre os componentes,
diminuindo o acoplamento e aumentando a sua manutenibilidade e portabilidade.
19
As principais vantagens do padro em camadas so:
Modificabilidade
As dependncias so mantidas localmente dentro de componentes de uma mesma camada. Como os

componentes podem acessar outros componentes somente atravs de uma interface bem definida e
unificada, o sistema pode ser facilmente modificado, trocando componentes da camada por outros
componentes melhorados.
Portabilidade
Servios que lidam diretamente com uma interface de programao de aplicativo (API) podem ser
encapsulados usando um componente de camada de sistema. Camadas de nvel superior contam com
68
este componente para a prestao de servios do sistema para a aplicao. Portanto, por dispor de
uma camada de API para outras plataformas, os sistemas se tornam mais portteis.
Segurana
A estrutura hierrquica controlada de sistemas em camadas permite a fcil incorporao de

componentes de segurana para criptografar ou descriptografar os dados de entrada ou sada.
Reutilizao
Ao compartimentar os servios de cada camada, torna-se mais fcil reutilizar.
20
RESUMO
Este mdulo estudamos os padres de arquitetura Centrados nos Dados, Fluxo de Dados, Sistema
Distribudo, Sistemas interativos e Sistemas Hierrquicos.
Para atingir este objetivo, iniciamos entendendo o que so estilos arquitetnicos e padres
arquitetnicos. Os estilos arquitetnicos fornecem solues arquitetnicas, genricos e reutilizveis de
uma forma que possa ser facilmente compreendida e aplicada a novos problemas que exigem
caractersticas arquitetnicas semelhantes. J os padro descreve uma soluo para um problema que
ocorre com frequncia durante o desenvolvimento de software, podendo ser considerado como um par
problema/soluo.
Nos Sistemas centrados nos dados vimos que estes sistemas so decompostos principalmente em torno
de repositrio central de dados. Portanto, as responsabilidades tpicas encontradas nos componentes
do sistema centrado em dados incluem um gerenciador de dados centralizado e vrios componentes de
trabalho. Como exemplos deste tipo de padro foi apresentado o padro quadro-negro. Neste padro,
componentes de sistemas funcionam em torno de um componente central de dados, o quadro negro,
para fornecer solues para problemas complexos.
Nos Sistema de Fluxo de Dados vimos que tem como premissa o transporte e a transformao de dados
para atender aos requisitos especficos de um sistema. Desta forma, ete tipo de sistema pode ser
decomposto em componentes de trabalho e nos componentes de transportes. Como exemplos deste
tipo de padro foi apresentado o padro Filtro e tupo. O padro de arquitetura Pipe (tubo) e Filter
(filtro) se decompe em componentes que realizam duas funes principais: processamento e
transformao de dados e transferncia de dados entre componentes.
21
69
Os Sistemas Distribudos so conhecidos como sistemas decompostos em vrios processos que

colaboram atravs da rede. Este padro amplamente difundido atualmente graas a tecnologias como:
internet mvel e sem fio. Neste padro estudamos o Padro Cliente-Servidor, que decompe sistemas
de software em dois componentes principais: o cliente e o servidor. Esses componentes so
manifestados como processos individuais que podem ser distribudos atravs da rede ou dentro de um
nico n (computador). Vimos tambm o Padro Broker, que fornece mecanismos para alcanar uma
melhor flexibilidade entre clientes e servidores em um ambiente distribudo.
Os Sistemas interativos so sistemas que suportam interaes do usurio, geralmente por meio de
interfaces de usurio. Neste padro estudamos o Padro Modelo-Viso-Controlador (Model-View-
Controller). O MVC usado em aplicaes interativas que exigem flexibilidade na interface do sistema.
Com o MVC, os sistemas so decompostos em trs componentes principais que lidam de forma
independente: componente de entrada, processamento e sada do sistema.
Os Sistemas hierrquicos so sistemas nos quais componentes podem ser estruturados de forma
hierrquica, de modo que os componentes existem em diferentes nveis de abstrao e cada nvel
aborda uma preocupao particular do sistema de software. Estudamos aqui o padro arquitetnico de
programa principal e sub-rotina muito popular em sistemas que so projetados usando a estratgia de
design estruturado (ou funcional). Nestes sistemas, um componente principal contm os principais
dados para o programa, que compartilhado entre os componentes que residem em nveis mais baixos
da hierarquia.
Ainda em sistemas hierrquicos, estudamos, por fim, a arquitetura em camadas onde uma forma mais
restrita da estrutura hierrquica envolve que cada camada pode ter um componente principal, que pode
ser composto internamente de vrios componentes, que fornece uma interface unificada para
comunicao com componentes que residem imediatamente abaixo na estrutura de hierarquia.
70

ANÁLISE E PROJETO DE SISTEMAS 3 (ARQUITETURA) Unidade01

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

ANÁLISE E PROJETO DE SISTEMAS 3 (ARQUITETURA) Unidade01

Uploaded by

Copyright:

Available Formats

116 Anlise e projeto de sistemas 3 (Arquitetura) | Unidade 01

UNIDADE 1 CONTEXTO DA ARQUITETURA DE SOFTWARE

UML: Conhecer os diagramas existentes, sobretudo o diagrama de classe e de componentes

2 - OS ENTENDIMENTOS FUNDAMENTAIS SOBRE A ARQUITETURA

justamente a arquitetura de software que vamos explorar nesta disciplina.

2015 - AIEC - Associao Internacional de Educao Continuada

Em particular, sobre as principais questes no que se refere ao design e a tecnologia a serem

Em uma concepo simplificada da arquitetura, os requisitos para um edifcio so coletados, um projeto

Teoricamente, quando falamos de software, alguns passos podem ser previstos:

A definio de arquitetura de software do IEEE, a qual adotaremos ao longo de nossa disciplina, a

Arquitetura de Software a organizao fundamental de um sistema, representada por seus

2015 - AIEC - Associao Internacional de Educao Continuada

Arquitetura de software envolve a integrao de metodologias e modelos de desenvolvimento de

1 Toda a aplicao tem uma arquitetura;

2 - Toda aplicao tem pelo menos uma arquitetura;

3 - Arquitetura no uma fase do desenvolvimento.

1 Toda a aplicao tem uma arquitetura;

2015 - AIEC - Associao Internacional de Educao Continuada

2 - Toda aplicao tem pelo menos uma arquitetura;

3 - Arquitetura no uma fase do desenvolvimento.

A Arquitetura de software refere-se essncia de uma aplicao, as principais decises de design, s

Em uma compreenso simplista, tradicional, e imprecisa, a arquitetura um produto especfico de

2015 - AIEC - Associao Internacional de Educao Continuada

3 - ARQUITETURA E SEU PAPEL NO DESENVOLVIMENTO DE SOFTWARE

A arquitetura deve comear no incio de qualquer atividade de desenvolvimento de software. Noes de

Entretanto, a viso acadmica tradicional de anlise de requisitos e especificao de que a

2015 - AIEC - Associao Internacional de Educao Continuada

Assim com o software. Especificao de requisitos de forma independente de qualquer preocupao

Design , por definio, a atividade que cria a arquitetura do software.

Desta forma, so 3 as caractersticas que temos que levar em considerao:

1. Se considerarmos a fase de projeto tradicional de Design e Arquitetura no devemos encar-

2. Como as principais decises de arquitetura so tomadas ao longo do processo de

3. Um rico repertrio de tcnicas de design necessrio para auxiliar o arquiteto a tomar as

2015 - AIEC - Associao Internacional de Educao Continuada

No entanto, temos que considerar alguns aspectos adicionais ao longo da implementao.

Primeiro, a atividade de implementao pode modificar a arquitetura. Se as principais decises de

Em segundo lugar, no podemos presumir que a arquitetura concluda antes do incio da

No estamos falando, entretanto, que implementao no deve respeitar as decises arquiteturais

Assim, para melhor entendermos, o que devemos levar em

Desta forma, o cdigo fonte no deve:

utilizar novos elementos que no tenham um correspondente na arquitetura definida.

conter novas conexes entre elementos da arquitetura que no so encontradas na

3.4 Anlise e Teste

Anlise e os testes so atividades realizadas para avaliar a qualidade de um artefato.

2015 - AIEC - Associao Internacional de Educao Continuada

e sua capacidade de atendimento aos requisitos no funcionais.

Se a arquitetura sobre a qual a implementao baseada de alta qualidade, a probabilidade de a

Como um artefato formal, o modelo de arquitetura (documento que descreve a arquitetura do

Como observado, um desenvolvimento focado na arquitetura fornece

2015 - AIEC - Associao Internacional de Educao Continuada

Mtodo refere-se a um A intuio a capacidade de

Assim podemos afirmar que o papel de um arquiteto de software de grande responsabilidade em um

Ele deve possuir uma srie de habilidades, tais como:

2015 - AIEC - Associao Internacional de Educao Continuada

Muitas organizaes de desenvolvimento de software produzir vrios sistemas dentro do mesmo

Assim, quanto mais especialista em um domnio, melhor ser o arquiteto.

Um grande designer de software no necessariamente um grande arquiteto de software. Um bom

2015 - AIEC - Associao Internacional de Educao Continuada

4.2- O que um arquiteto de software faz?

Desenvolver estratgia do projeto

Comunicao com os interessados

2015 - AIEC - Associao Internacional de Educao Continuada

A arquitetura de referncia um conjunto de princpios de design aplicveis simultaneamente em