Análise e Design: Visão Geral

Transcrição

1 Análise e Design: Visã Geral As finalidades da disciplina Análise e Design sã: Transfrmar s requisits em um design d sistema a ser criad. Desenvlver uma arquitetura sfisticada para sistema. Adaptar design para que crrespnda a ambiente de implementaçã, prjetand- para fins de desempenh. Definir uma Sugestã de Arquitetura Finalidade Criar um esbç inicial da arquitetura d sistema Definir um cnjunt inicial de elements significativs em terms de arquitetura que servirá cm base para a análise Definir um cnjunt inicial de mecanisms de análise Definir a dispsiçã em camadas e rganizaçã iniciais d sistema Definir as realizações de cas de us que serã tratadas na iteraçã atual Identificar as classes de análise ds cass de us significativs em terms de arquitetura Atualizar as realizações de cas de us cm as interações das classes de análise 1

2 Cm Definir a Equipe Essas atividades sã melhr realizadas pr uma equipe pequena cmpsta pr participantes de várias funções. As questões que, em geral, sã significativas em terms de arquitetura incluem desempenh, escalnament, a sincrnizaçã de prcesss e threads, e a distribuiçã. A equipe deve também incluir membrs que tenham experiência em dmíni e que pssam identificar as principais abstrações. Além diss, a equipe deve ter experiência na rganizaçã d mdel e na dispsiçã em camadas. Ela precisará reunir tds esses threads discrepantes em uma arquitetura cesa e cerente (embra preliminar). Orientações de Trabalh O trabalh é melhr realizad em várias sessões, talvez executad em alguns dias (u em semanas e meses, n cas de sistemas grandes). Atividade: Análise Arquitetural A análise arquitetural cncentra-se em definir uma sugestã de arquitetura e restringir as técnicas de arquitetura a serem utilizadas n sistema. Ela cnta cm a experiência btida cm sistemas u dmínis de prblema semelhantes para restringir e enfcar a arquitetura de md que esfrç nã seja desperdiçad na 'redescberta arquitetural'. Em sistemas ns quais já existe uma arquitetura bem-definida, é pssível mitir a análise arquitetural, que é vantajsa principalmente quand se está desenvlvend sistemas nvs e inédits. 2

3 Desenvlver a Visã Geral da Arquitetura A visã geral da arquitetura é criada n iníci d cicl de vida de um prjet, pssivelmente já na fase de iniciaçã, visand facilitar planejament d sistema, investigand e avaliand pções de arquitetura de nível superir. Busca, também, transmitir para patrcinadr, às equipes de desenvlviment e utrs envlvids, um entendiment inicial da estrutura de nível superir d sistema desejad. Basicamente, tem cm finalidade: Identificar s recurss que pdem ser relevantes para prjet. Analisar s ajustes necessáris e as lacunas existentes entre s recurss e s requisits d prjet. Decidir pr basear u nã áreas d sistema ns recurss. Lcalizar e listar s recurss que pdem ser reutilizads n prjet. Executar uma avaliaçã preliminar para se certificar de que suprte necessári está dispnível. Atividade: Analisar Cass de Us Identificar as classes que realizam flux de events de um cas de us. Distribuir cmprtament d cas de us entre essas classes utilizand realizações de cass de us. Identificar as respnsabilidades, s atributs e as assciações das classes. Observar a utilizaçã ds mecanisms de arquitetura. CONCEITOS ARQUITETURA DE SOFTWARE Intrduçã A arquitetura de sftware é um cnceit de fácil cmpreensã e que a mairia ds engenheirs entende de md intuitiv, especialmente quand se tem um puc de experiência. N entant, é difícil defini-l cm precisã. Em particular, é difícil desenhar uma linha bem definida entre design e a arquitetura a arquitetura é um aspect d design que se cncentra em alguns recurss específics. Em An Intrductin t Sftware Architecture, David Garlan e Mary Shaw sugerem que a arquitetura de sftware é um nível de design vltad para questões que vã: "além ds algritms e das estruturas de dads da cmputaçã. A prjeçã e a especificaçã da estrutura geral d sistema emergem cm um nv tip de prblema. As questões estruturais incluem rganizaçã ttal e estrutura de cntrle glbal; prtcls de cmunicaçã, sincrnizaçã e acess a dads; atribuiçã de funcinalidade a elements de design; distribuiçã física; cmpsiçã de elements de design; escalnament e desempenh; e seleçã entre as alternativas de design." [Descriçã da Arquitetura 3

4 Para falar e tirar cnclusões sbre a arquitetura d sftware, primeir defina uma representaçã de arquitetura, uma frma de descrever aspects imprtantes de uma arquitetura. N RUP, essa descriçã é capturada em Visões de Arquitetura Optams pr representar a arquitetura de sftware em várias visões de arquitetura. Cada visã de arquitetura abrda um determinad cnjunt de questões específicas ds envlvids n prcess de desenvlviment: usuáris finais, designers, gerentes, engenheirs de sistema, mantenedres, etc. As visões capturam as principais decisões de design estruturais mstrand cm a arquitetura de sftware é decmpsta em Um Cnjunt Típic de Visões de Arquitetura A arquitetura é representada pr uma série de visões de arquitetura diferentes, que, em sua essência, sã fragments que ilustram s elements "significativs em terms de arquitetura" ds mdels. N RUP, vcê parte de um cnjunt típic de visões, denminad "mdel de visã 4+1" [Enfque da Arquitetura Embra as visões acima pssam representar td design de um sistema, a arquitetura se precupa smente cm alguns aspects específics: A estrutura d mdel s padrões rganizacinais, pr exempl, a Padrões de Arquitetura Os Estrutura Categria Sistemas Distribuíds Sistemas Interativs Sistemas Adaptáveis Camadas Pipes e Filtrs Quadr-negr Brker Padrã Mdel-Visã-Cntrladr Apresentaçã-Abstraçã-Cntrle Reflex Micrkernel Duas dessas categrias sã apresentadas mais detalhadamente aqui, a fim de esclarecer essas idéias. Para bter uma abrdagem cmpleta, cnsulte [Um sistema que deve reslver as questões em diferentes níveis de abstraçã. Pr exempl: as questões de cntrle de hardware, as questões de serviçs cmuns e as questões específicas de dmíni. Seria extremamente indesejável escrever cmpnentes verticais que lidem cm essas questões em tds s níveis. Uma mesma questã deveria ser reslvida (pssivelmente de maneira incnsistente) várias vezes em diferentes cmpnentes. Frça As partes d sistema devem ser substituíveis 4

5 As alterações efetuadas ns cmpnentes nã devem ser irregulares Respnsabilidades similares devem ser agrupadas juntas Tamanh ds cmpnentes cmpnentes cmplexs talvez precisem ser decmpsts Sluçã Estruture s sistemas em grups de cmpnentes que frmem camadas umas sbre as utras. Faça cm que as camadas superires utilizem s serviçs smente das camadas abaix (nunca das camadas acima). Tente nã usar serviçs que nã sejam s da camada diretamente abaix (nã pule camadas, a mens que as camadas intermediárias smente adicinem cmpnentes de acess). Exempls: 1. Camadas Genéricas Uma arquitetura estritamente em camadas estabelece que s elements de design (classes, cmpnentes, pactes, subsistemas) usem smente s serviçs da camada abaix delas. Os serviçs pdem incluir tratament de events, tratament de errs, acess a banc de dads, etc. Ela cntém mecanisms mais palpáveis, em psiçã às chamadas em nível de sistema peracinal brut dcumentadas na camada inferir. 2. Camadas de Sistema de Negócis 5

6 O diagrama acima mstra um utr exempl de divisã em camadas, nde há camadas verticais específicas de aplicativ e camadas hrizntais de infra-estrutura. Observe que a meta é ter "chaminés" de negócis muit curtas e estimular a freqüência entre aplicativs. D cntrári, é prvável que várias pessas reslvam mesm prblema, pssivelmente de maneira diferente. Quadr-negr Cntext Um dmíni em que nenhuma abrdagem fechada (algrítmica) para reslver um prblema é cnhecida u viável. Os exempls sã s sistemas de IA, recnheciment de vz e s sistemas de inspeçã. Prblema Váris agentes de resluçã de prblemas (agentes de cnheciment) devem cperar para slucinar um prblema que nã pde ser reslvid pr um só agente. Os resultads d trabalh de cada agente devem estar acessíveis a tds s utrs agentes. Assim, eles pderã avaliar se pdem u nã cntribuir para encntrar uma sluçã e divulgar s resultads de seus trabalhs. Frça A seqüência em que s agentes de cnheciment pdem cntribuir para slucinar prblema nã é determinista e talvez dependa das estratégias de sluçã de prblemas 6

7 A clabraçã de váris agentes (resultads u sluções parciais) pde ter diferentes representações Os agentes nã sabem da existência de cada um ds utrs agentes, mas pdem avaliar as cntribuições divulgadas de cada um deles Sluçã Uma série de agentes de cnheciment tem acess a um armazenament de dads cmpartilhads denminad Quadr-negr. O quadr-negr frnece uma interface para inspecinar e atualizar seu cnteúd. O módul/bjet Cntrle ativa s agentes seguind algumas estratégias. Após a ativaçã, um agente inspecina esse quadr-negr para ver se ele pde cntribuir na resluçã d prblema. Se agente determinar que é pssível cntribuir, bjet Cntrle permitirá que s agentes clquem sua sluçã parcial (u final) n quadr. Exempl: Este exempl mstra a visã estrutural u estática mdelada através da UML. Ele será parte de uma clabraçã parametrizada, que será restringida a parâmetrs reais para instanciar padrã. Estil da Arquitetura Uma arquitetura de sftware, u smente uma visã de arquitetura, pde ter um atribut chamad estil de arquitetura, que reduz cnjunt de frmuláris que pdem ser esclhids e impõe um determinad grau de unifrmidade à arquitetura. O estil pde ser definid pr um cnjunt de padrões, u pela esclha de cmpnentes u cnectres específics que funcinarã cm s tijls básics da cnstruçã. Em um determinad sistema, alguns estils pdem ser capturads cm parte da descriçã da arquitetura em um guia de estil de arquitetura parte de um dcument de Plantas da Arquitetura A representaçã gráfica de uma visã de arquitetura é denminada planta da arquitetura. Nas várias visões descritas acima, as plantas sã cmpstas pels seguintes diagramas da Unified Mdeling Language [O Prcess de Desenvlviment da Arquitetura N RUP, a arquitetura é basicamente um resultad d 7

8 Abrdagens Cmuns da Divisã em Camadas A divisã em camadas representa um agrupament rdenad de funcinalidades, send que: (a) a funcinalidade específica de aplicativ está lcalizada nas camadas superires, (b) a funcinalidade que abrange s dmínis de aplicativs se encntra nas camadas intermediárias e (c) a funcinalidade específica d ambiente de implantaçã está nas camadas inferires. O númer e a cmpsiçã das camadas dependem da cmplexidade d dmíni d prblema e d espaç para sluçã: Em geral, há apenas uma única camada específica de aplicativ. Ns dmínis em que sistemas anterires fram desenvlvids u sistemas de grande prte sã cmpsts de sistemas interperacinais menres, há uma grande necessidade de cmpartilhar as infrmações entre as equipes de design. Cnseqüentemente, para mair clareza, é prvável que a camada específica de negócis exista parcialmente e esteja estruturada em várias camadas. Os espaçs para sluçã que sã suprtads pr prduts de middleware e ns quais sftware de sistema cmplex desempenha um papel imprtante terã camadas inferires bem desenvlvidas, talvez cm várias camadas de middleware e sftware de sistema. Os subsistemas devem ser rganizads em camadas cm subsistemas específics de aplicativ lcalizads nas camadas superires da arquitetura, subsistemas específics de peraçã e hardware nas camadas inferires da arquitetura, e serviçs para fins genérics nas camadas de middleware. Veja a seguir um exempl de arquitetura cm quatr camadas: A camada superir, camada de aplicativ, cntém serviçs específics de aplicativ. A camada seguinte (camada específica de negócis) cntém cmpnentes específics de negócis, usads em diverss aplicativs. A camada de middleware cntém cmpnentes cm cnstrutres GUI, interfaces para sistemas de gerenciament de banc de dads, serviçs de sistemas peracinais que nã dependem de platafrma e cmpnentes OLE, cm planilhas e editres de diagramas. A camada inferir (camada de sftware de sistema) cntém cmpnentes cm sistemas peracinais, bancs de dads, interfaces para hardware específic, etc. 8

9 Uma estrutura dividida em camadas, desde nível mais genéric de funcinalidade até s níveis mais específics de funcinalidade. Diretrizes da Divisã em Camadas A divisã em camadas permite um particinament lógic de subsistemas em diverss cnjunts, cm determinadas regras sbre cm estabelecer relacinaments entre camadas. Essa divisã permite restringir dependências entre subsistemas, fazend cm que sistema seja acplad mais livremente e, dessa frma, mantid cm mais facilidade. Os critéris para agrupar subsistemas seguem alguns padrões: Visibilidade. Os subsistemas só pdem depender de subsistemas na mesma camada e na camada inferir seguinte. Vlatilidade. Nas camadas superires, insira elements que variam quand s requisits de usuári sã alterads. Nas camadas inferires, insira elements que variam quand a platafrma de implementaçã (hardware, idima, sistema peracinal, banc de dads, etc.) é alterada. Entre essas camadas, insira elements que geralmente se aplicam a diverss tips de sistemas e ambientes de implementaçã. Acrescente camadas quand partições adicinais nessas categrias amplas ajudarem a rganizar mdel. Generalidade. Elements abstrats d mdel cstumam ser inserids em camadas inferires n mdel. Se nã frem específics da implementaçã, ficarã geralmente próxims das camadas intermediárias. Númer de Camadas. Para um sistema pequen, três camadas sã suficientes. Para um sistema cmplex, cinc a sete camadas cstumam ser suficientes. Para qualquer grau de cmplexidade, us de mais de dez camadas deve ser vist cm suspeita, que deverá aumentar cm númer de camadas. Algumas regras práticas sã apresentadas abaix: 9

10 Númer de Classes Númer de Camadas 0-10 A divisã em camadas nã é necessária camadas camadas camadas Subsistemas e pactes em uma camada específica devem depender apenas de subsistemas na mesma camada e na camada inferir seguinte. Se essa restriçã de dependências nã fr bedecida, a arquitetura será deterirada e sistema se trnará frágil e de difícil manutençã. As exceções incluem cass em que s subsistemas precisam de acess diret a serviçs de camadas inferires: cnvém tmar uma decisã cnsciente sbre cm lidar cm serviçs primitivs necessáris em td sistema, cm imprimir, enviar mensagens, etc. Nã cmpensa restringir mensagens a camadas inferires, se a sluçã fr implementar acesss de chamadas nas camadas intermediárias. Padrões de Particinament Nas camadas superires d sistema, partições adicinais pdem ajudar a rganizar mdel. As seguintes diretrizes para particinament apresentam questões distintas a serem cnsideradas: Organizaçã d usuári. Os subsistemas pdem ser rganizads em linhas que refletem a rganizaçã da funcinalidade na rganizaçã de negócis (pr exempl, particinament crre em linhas de departaments). Em geral, esse particinament crre n iníci d design prque um mdel de empresa existente pssui uma estrutura altamente particinada n nível da rganizaçã. Esse padrã de rganizaçã cstuma afetar smente as pucas camadas superires de serviçs específics de aplicativ e nrmalmente desaparece à medida que design evlui. O particinament em linhas da rganizaçã d usuári pde ser um ótim pnt de partida para mdel. A estrutura da rganizaçã d usuári nã é estável durante muit temp (devid à rerganizaçã de negócis) nem é uma base satisfatória a lng praz para particinament d sistema. A rganizaçã interna d sistema deve permitir que ele se desenvlva e seja mantid independentemente da rganizaçã d negóci que ele suprta. Áreas de cmpetência e/u habilidades. É pssível rganizar subsistemas de md que particinem respnsabilidades de partes d mdel entre grups distints da rganizaçã de desenvlviment. Em geral, iss crre nas camadas intermediárias e inferires d sistema e reflete a necessidade de especializaçã de habilidades durante desenvlviment e suprte da tecnlgia de infra-estrutura cmplexa. Alguns exempls desse tip de tecnlgia sã gerenciament de distribuiçã e rede, gerenciament de banc de dads, gerenciament de cmunicaçã, cntrle de prcesss, etc. O particinament em linhas de cmpetência também pde crrer nas camadas superires, nas quais é necessária uma cmpetência especial n dmíni d prblema para entender e suprtar a funcinalidade básica de negócis. Alguns 10

11 exempls incluem gerenciament de chamadas de telecmunicações, negciaçã de valres mbiliáris, prcessament de indenizações de segur, cntrle de tráfeg aére, etc. Distribuiçã d sistema. Em qualquer uma das camadas d sistema, é pssível particiná-las "hrizntalmente" para refletir a distribuiçã física da funcinalidade. O particinament para refletir a distribuiçã pde ajudar a visualizar a cmunicaçã de rede que crrerá assim que sistema fr executad. N entant, esse particinament também pde dificultar a realizaçã de mudanças n sistema, se Mdel de Implantaçã fr alterad de frma significativa. Áreas de sigil. Alguns aplicativs, principalmente aqueles que exigem autrizaçã de segurança especial para serem desenvlvids e/u suprtads, requerem partições adicinais nas linhas de privilégi de acess à segurança. O sftware que cntrla acess a áreas de sigil deve ser desenvlvid e mantid pr pessal autrizad. Se númer de pessas n prjet cm esse cnheciment fr limitad, a funcinalidade que exige autrizaçã especial deverá ser particinada em subsistemas que serã desenvlvids sem depender de utrs subsistemas, send as interfaces para as áreas de sigil únic aspect visível desses subsistemas. Áreas de variabilidade. A funcinalidade que tende a ser pcinal e, prtant, liberada apenas em algumas variantes d sistema, deve ser rganizada em subsistemas independentes que sã desenvlvids e apresentads sem depender da funcinalidade brigatória d sistema. ARQUITETO DE SOFTWARE O papel arquitet de sftware lidera e crdena as atividades e s artefats técnics n decrrer d prjet. O arquitet de sftware estabelece a estrutura geral de cada visã de arquitetura: a decmpsiçã da visã, agrupament ds elements e as interfaces entre esses principais agrupaments. Prtant, cmparad as utrs papéis, a visã d arquitet de sftware é ampla, e nã detalhada. 11

12 Equipe "O arquitet ideal deve ser uma pessa erudita, um matemátic, familiarizad cm estuds histórics, um estudis aplicad de filsfia, cnhecedr de música, que nã descnheça medicina, detentr de saber jurídic e familiarizad cm astrnmia e cálculs astrnômics." - Vitruvius, há aprximadamente 25 ans a.c. Em resum, arquitet de sftware deve ter grande cnheciment geral, pssuir maturidade, visã e prfunda experiência que permita identificar prblemas rapidamente e dar piniões sensatas e criterisas na falta de infrmações cmpletas. Mais especificamente, arquitet de sftware u s membrs da equipe de arquitetura devem cmbinar as seguintes habilidades: Experiência n dmíni d prblema, cnhecend ttalmente s requisits, e n dmíni de engenharia de sftware. Se há uma equipe, essas qualidades pdem se achar distribuídas entre s seus membrs, mas deve existir pel mens um arquitet de sftware que fereça a visã glbal d prjet. Liderança para cnduzir esfrç técnic entre as várias equipes, tmar decisões imprtantes sb pressã e fazer cm que essas decisões sejam cumpridas à risca. Para melhr eficiência, arquitet de sftware e gerente de prjet devem trabalhar junts, cm arquitet de sftware respnsável pelas questões técnicas e gerente de prjet cuidand ds assunts administrativs. O arquitet de sftware deve ter pder para tmar decisões técnicas. Cmunicaçã para cnquistar cnfiança, persuadir, mtivar e servir cm mentr. O arquitet de sftware nã pde liderar pr decret, mas smente cm cnsentiment ds utrs membrs da equipe d prjet. Para desempenhar seu papel cm eficiência, arquitet de sftware deve cnquistar respeit da equipe d prjet, d gerente d prjet, d cliente, da cmunidade de usuáris e da equipe de gerenciament. Orientaçã pr metas e Pratividade cm enfque inexrável ns resultads. O arquitet de sftware é a frça técnica rientadra existente pr trás d prjet, nã um visinári u snhadr. A carreira de um arquitet de sftware bem-sucedid cnsiste em 12

13 uma lnga série de decisões insatisfatórias, tmadas cm incerteza e sb pressã. Smente aqueles que se cncentram em fazer que deve ser feit terã êxit nesse ambiente d prjet. 13