1. 2. 3. 4. 5.

6. 7. 8.

9.

10. 11. 12.

13.

Introduo Desenvolvimento de Softwares orientado a objetos UML A unificao dos mtodos para a criao de um novo padro Uso da UML ases do Desenvolvimento de um Sistema em UML 1. Anlise de Requisitos 2. Anlise 3. Design (Projeto) 4. Programao 5. Testes A !otao da Lin"ua"em de Modela"em Unificada UML #is$es Modelos de %lementos 1. Classes 2. Objetos 3. Estados 4. Pacotes 5. Com onentes 6. Relacionamentos 7. !ecanismos "erais Dia"ramas 1. Diagrama #se$Case 2. Diagrama de Classes 3. Diagrama de Objetos 4. Diagrama de Estado 5. Diagrama de %equ&ncia 6. Diagrama de Colaborao 7. Diagrama de Ati'idade 8. Diagrama de Com onente 9. Diagrama de E(ecuo Um processo para utili&ar a UML ' uturo da UML Um estudo de caso em UML ( Sistema de )ontrole de )ontas )orrentes* +oupana e Aplica$es +r(fi,adas 1. Anlise de Requisitos 2. Anlise 3. Design 4. )m lementao 5. Testes )oncluso

-. Introduo O grande roblema do desen'ol'imento de no'os sistemas utili*ando a orientao a objetos nas +ases de anlise de requisitos, anlise de sistemas e design - que no e(iste uma notao adroni*ada e realmente e+ica* que abranja qualquer ti o de a licao que se deseje. Cada simbologia e(istente ossui seus r/ rios conceitos, gr+icos e terminologias, resultando numa grande con+uso, es ecialmente ara aqueles que querem utili*ar a orientao a objetos no s/ sabendo ara que lado a onta a seta de um relacionamento, mas sabendo criar modelos de qualidade ara ajud$los a construir e manter sistemas cada 'e* mais e+ica*es. 0uando a 1#ni+ied !odeling 2anguage1 (#!2) +oi lanada, muitos desen'ol'edores da rea da orientao a objetos +icaram entusiasmados j que essa adroni*ao ro osta ela #!2 era o ti o de +ora que eles sem re es eraram. A #!2 - muito mais que a adroni*ao de uma notao. 3 tamb-m o desen'ol'imento de no'os conceitos no normalmente usados. Por isso e muitas outras ra*4es, o bom entendimento da #!2 no - a enas a render a simbologia e o seu signi+icado, mas tamb-m signi+ica a render a modelar orientado a objetos no estado da arte. #!2 +oi desen'ol'ida or "rad5 6ooc7, 8ames Rumbaug7, e )'ar 8acobson que so con7ecidos como 1os tr&s amigos1. Eles ossuem uma e(tenso con7ecimento na rea de modelagem orientado a objetos j que as tr&s mais conceituadas metodologias de modelagem orientado a objetos +oram eles que desen'ol'eram e a #!2 - a juno do que 7a'ia de mel7or nestas tr&s metodologias adicionado no'os conceitos e 'is4es da linguagem. 9eremos caracter:sticas de cada uma destas metodologias no desen'ol'er deste trabal7o. 9eremos como a #!2 aborda o carter esttico e din;mico do sistema a ser analisado le'ando em considerao, j no er:odo de modelagem, todas as +uturas caracter:sticas do sistema em relao a utili*ao de 1 ac<ages1 r/ rios da linguagem a ser utili*ada, utili*ao do banco de dados bem como as di'ersas es eci+ica4es do sistema a ser desen'ol'ido de acordo com as m-tricas +inais do sistema. =o - intuito deste trabal7o de+inir e e( licar os signi+icados de classes, objetos, relacionamentos, +lu(os, mensagens e outras entidades comuns da orientao a objetos, e sim a resentarmos como essas entidades so criadas, simboli*adas, organi*adas e como sero utili*adas dentro de um desen'ol'imento utili*ando a #!2.

/. Desenvolvimento de Softwares orientado a objetos Os conceitos da orientao a objetos j '&m sido discutidos 7 muito tem o, desde o lanamento da >? linguagem orientada a objetos, a %)!#2A. 9rios 1 a as1 da engen7aria de so+t@are mundial como Peter Coad, Ed@ard Aourdon e Roger Pressman abordaram e(tensamente a anlise orientada a objetos como realmente um grande a'ano no desen'ol'imento de sistemas. !as mesmo assim, eles citam que no e(iste (ou que no e(istia no momento de suas ublica4es) uma linguagem que ossibilitasse o desen'ol'imento de qualquer so+t@are utili*ando a anlise orientada a objetos. Os conceitos que Coad, Aourdon, Pressman e tantos outros abordaram, discutiram e de+iniram em suas ublica4es +oram queB A orientao a objetos - uma tecnologia ara a roduo de modelos que es eci+iquem o dom:nio do roblema de um sistema. 0uando constru:dos corretamente, sistemas orientados a objetos so +le(:'eis a mudanas, ossuem estruturas bem con7ecidas e ro'&m a o ortunidade de criar e im lementar com onentes totalmente reutili*'eis. !odelos orientado a objetos so im lementados con'enientemente utili*ando uma linguagem de rogramao orientada a objetos. A engen7aria de so+t@are orientada a objetos - muito mais que utili*ar mecanismos de sua linguagem de rogramao, - saber utili*ar da mel7or +orma oss:'el todas as t-cnicas da modelagem orientada a objetos.. A orientao a objetos no - s/ teoria, mas uma tecnologia de e+ici&ncia e qualidade com ro'adas usada em inCmeros rojetos e ara construo de di+erentes ti o de sistemas.

A orientao a objetos requer um m-todo que integre o rocesso de desen'ol'imento e a linguagem de modelagem com a construo de t-cnicas e +erramentas adequadas

0. UML A unificao dos mtodos para a criao de um novo padro A #!2 - uma tentati'a de adroni*ar a modelagem orientada a objetos de uma +orma que qualquer sistema, seja qual +or o ti o, ossa ser modelado corretamente, com consist&ncia, +cil de se comunicar com outras a lica4es, sim les de ser atuali*ado e com reens:'el. E(istem 'rias metodologias de modelagem orientada a objetos que at- o surgimento da #!2 causa'am uma guerra entre a comunidade de desen'ol'edores orientado a objetos. A #!2 acabou com esta guerra tra*endo as mel7ores id-ias de cada uma destas metodologias, e mostrando como de'eria ser a migrao de cada uma ara a #!2. Dalaremos sobre algumas das rinci ais metodologias que se tornaram o ulares nos anos EFB 6ooc7 G O m-todo de "rad5 6ooc7 ara desen'ol'imento orientado a objetos est dis on:'el em muitas 'ers4es. 6ooc7 de+iniu a noo de que um sistema - analisado a artir de um nCmero de 'is4es, onde cada 'iso - descrita or um nCmero de modelos e diagramas. O !-todo de 6ooc7 tra*ia uma simbologia com le(a de ser desen7ada a mo, contin7a tamb-m o rocesso elo qual sistemas so analisados or macro e micro 'is4es. O!T G T-cnica de !odelagem de Objetos (Object !odelling Tec7nique) - um m-todo desen'ol'ido ela "E ("eneral Electric) onde 8ames Rumbaug7 trabal7a'a. O m-todo es ecialmente 'oltado ara o teste dos modelos, baseado nas es eci+ica4es da anlise de requisitos do sistema. O modelo total do sistema baseado no m-todo O!T - com osto ela juno dos modelos de objetos, +uncional e use$cases. OO%EHObjector5 G Os m-todos OO%E e o Objector5 +oram desen'ol'idos baseados no mesmo onto de 'ista +ormado or )'ar 8acobson. O m-todo OO%E - a 'iso de 8acobson de um m-todo orientado a objetos, j o Objector5 - usado ara a construo de sistemas to di'ersos quanto eles +orem. Ambos os m-todos so baseados na utili*ao de use$ cases, que de+inem os requisitos iniciais do sistema, 'istos or um ator e(terno. O m-todo Objector5 tamb-m +oi ada tado ara a engen7aria de neg/cios, onde - usado ara modelar e mel7orar os rocessos en'ol'idos no +uncionamento de em resas.

Cada um destes m-todos ossui sua r/ ria notao (seus r/ rios s:mbolos ara re resentar modelos orientado a objetos), rocessos (que ati'idades so desen'ol'idas em di+erentes artes do desen'ol'imento), e +erramentas (as +erramentas CA%E que su ortam cada uma destas nota4es e rocessos). Diante desta di'ersidade de conceitos, 1os tr&s amigos1, "rad5 6ooc7, 8ames Rumbaug7 e )'ar 8acobson decidiram criar uma 2inguagem de !odelagem #ni+icada. Eles dis onibili*aram inCmeras 'ers4es reliminares da #!2 ara a comunidade de desen'ol'edores e a res osta incrementou muitas no'as id-ias que mel7oraram ainda mais a linguagem. Os objeti'os da #!2 soB A modelagem de sistemas (no a enas de so+t@are) usando os conceitos da orientao a objetosI

Estabelecer uma unio +a*endo com que m-todos conceituais sejam tamb-m e(ecut'eisI Criar uma linguagem de modelagem us'el tanto elo 7omem quanto ela mquina.

A #!2 est destinada a ser dominante, a linguagem de modelagem comum a ser usada nas indCstrias. Ela est totalmente baseada em conceitos e adr4es e(tensi'amente testados ro'enientes das metodologias e(istentes anteriormente, e tamb-m - muito bem documentada com toda a es eci+icao da sem;ntica da linguagem re resentada em meta$modelos

1. Uso da UML A #!2 - usada no desen'ol'imento dos mais di'ersos ti os de sistemas. Ela abrange sem re qualquer caracter:stica de um sistema em um de seus diagramas e - tamb-m a licada em di+erentes +ases do desen'ol'imento de um sistema, desde a es eci+icao da anlise de requisitos at- a +inali*ao com a +ase de testes. O objeti'o da #!2 - descre'er qualquer ti o de sistema, em termos de diagramas orientado a objetos. =aturalmente, o uso mais comum - ara criar modelos de sistemas de so+t@are, mas a #!2 tamb-m - usada ara re resentar sistemas mec;nicos sem nen7um so+t@are. Aqui esto alguns ti os di+erentes de sistemas com suas caracter:sticas mais comunsB %istemas de )n+ormaoB Arma*enar, esquisar, editar e mostrar in+orma4es ara os usurios. !anter grandes quantidades de dados com relacionamentos com le(os, que so guardados em bancos de dados relacionais ou orientados a objetos. %istemas T-cnicosB !anter e controlar equi amentos t-cnicos como de telecomunica4es, equi amentos militares ou rocessos industriais. Eles de'em ossuir inter+aces es eciais do equi amento e menos rogramao de so+t@are de que os sistemas de in+ormao. %istemas T-cnicos so geralmente sistemas real$time. %istemas Real$time )ntegradosB E(ecutados em sim les eas de 7ard@are integrados a tele+ones celulares, carros, alarmes etc. Estes sistemas im lementam rogramao de bai(o n:'el e requerem su orte real$time. %istemas Distribu:dosB Distribu:dos em mquinas onde os dados so trans+eridos +acilmente de uma mquina ara outra. Eles requerem mecanismos de comunicao sincroni*ados ara garantir a integridade dos dados e geralmente so constru:dos em mecanismos de objetos como COR6A, CO!HDCO! ou 8a'a 6eansHR!). %istemas de %o+t@areB De+inem uma in+ra$estrutura t-cnica que outros so+t@ares utili*am. %istemas O eracionais, bancos de dados, e a4es de usurios que e(ecutam a4es de bai(o n:'el no 7ard@are, ao mesmo tem o que dis onibili*am inter+aces gen-ricas de uso de outros so+t@ares. %istemas de =eg/ciosB descre'e os objeti'os, es eci+ica4es ( essoas, com utadores etc.), as regras (leis, estrat-gias de neg/cios etc.), e o atual trabal7o desem en7ado nos rocessos do neg/cio.

3 im ortante erceber que a maioria dos sistemas no ossuem a enas uma destas caracter:sticas acima relacionadas, mas 'rias delas ao mesmo tem o. %istemas de in+orma4es de 7oje, or e(em lo, odem ter tanto caracter:sticas distribu:das como real$time. E a #!2 su orta modelagens de todos estes ti os de sistemas.

2. ases do Desenvolvimento de um Sistema em UML E(istem cinco +ases no desen'ol'imento de sistemas de so+t@areB anlise de requisitos, anlise, design ( rojeto), rogramao e testes. Estas cinco +ases no de'em ser e(ecutadas na ordem descrita acima, mas concomitantemente de +orma que roblemas detectados numa certa +ase modi+iquem e mel7orem as +ases desen'ol'idas anteriormente de +orma que o resultado global gere um roduto de alta qualidade e er+ormance. A seguir +alaremos sobre cada +ase do desen'ol'imento de um sistema em #!2B 5.1. Anlise de Requisitos Esta +ase ca tura as inten4es e necessidades dos usurios do sistema a ser desen'ol'ido atra'-s do uso de +un4es c7amadas 1use$cases1. Atra'-s do desen'ol'imento de 1use$case1, as entidades e(ternas ao sistema (em #!2 c7amados de 1atores e(ternos1) que interagem e ossuem interesse no sistema so modelados entre as +un4es que eles requerem, +un4es estas c7amadas de 1use$cases1. Os atores e(ternos e os 1use$cases1 so modelados com relacionamentos que ossuem comunicao associati'a entre eles ou so desmembrados em 7ierarquia. Cada 1use$case1 modelado - descrito atra'-s de um te(to, e este es eci+ica os requerimentos do ator e(terno que utili*ar este 1use$case1. O diagrama de 1use$cases1 mostrar o que os atores e(ternos, ou seja, os usurios do +uturo sistema de'ero es erar do a licati'o, con7ecendo toda sua +uncionalidade sem im ortar como esta ser im lementada. A anlise de requisitos tamb-m ode ser desen'ol'ida baseada em rocessos de neg/cios, e no a enas ara sistemas de so+t@are. 5.2. Anlise A +ase de anlise est reocu ada com as rimeiras abstra4es (classes e objetos) e mecanismos que estaro resentes no dom:nio do roblema. As classes so modeladas e ligadas atra'-s de relacionamentos com outras classes, e so descritas no Diagrama de Classe. As colabora4es entre classes tamb-m so mostradas neste diagrama ara desen'ol'er os 1use$cases1 modelados anteriormente, estas colabora4es so criadas atra'-s de modelos din;micos em #!2. =a anlise, s/ sero modeladas classes que ertenam ao dom:nio rinci al do roblema do so+t@are, ou seja, classes t-cnicas que gerenciem banco de dados, inter+ace, comunicao, concorr&ncia e outros no estaro resentes neste diagrama. 5.3. Design (Projeto) =a +ase de design, o resultado da anlise - e( andido em solu4es t-cnicas. =o'as classes sero adicionadas ara ro'er uma in+ra$estrutura t-cnicaB a inter+ace do usurio e de eri+-ricos, gerenciamento de banco de dados, comunicao com outros sistemas, dentre outros. As classes do dom:nio do roblema modeladas na +ase de anlise so mescladas nessa no'a in+ra$estrutura t-cnica tornando oss:'el alterar tanto o dom:nio do roblema quanto a in+ra$estrutura. O design resulta no detal7amento das es eci+ica4es ara a +ase de rogramao do sistema. 5.4. Programao

=a +ase de rogramao, as classes ro'enientes do design so con'ertidas ara o c/digo da linguagem orientada a objetos escol7ida (a utili*ao de linguagens rocedurais - e(tremamente no recomendada). De endendo da ca acidade da linguagem usada, essa con'erso ode ser uma tare+a +cil ou muito com licada. =o momento da criao de modelos de anlise e design em #!2, - mel7or e'itar tradu*i$los mentalmente em c/digo. =as +ases anteriores, os modelos criados so o signi+icado do entendimento e da estrutura do sistema, ento, no momento da gerao do c/digo onde o analista conclua anteci adamente sobre modi+ica4es em seu conteCdo, seus modelos no estaro mais demonstrando o real er+il do sistema. A rogramao - uma +ase se arada e distinta onde os modelos criados so con'ertidos em c/digo. 5.5. estes #m sistema normalmente - rodado em testes de unidade, integrao, e aceitao. Os testes de unidade so ara classes indi'iduais ou gru os de classes e so geralmente testados elo rogramador. Os testes de integrao so a licados j usando as classes e com onentes integrados ara se con+irmar se as classes esto coo erando uma com as outras como es eci+icado nos modelos. Os testes de aceitao obser'am o sistema como uma 1 cai(a reta1 e 'eri+icam se o sistema est +uncionando como o es eci+icado nos rimeiros diagramas de 1use$ cases1. O sistema ser testado elo usurio +inal e 'eri+icar se os resultados mostrados esto realmente de acordo com as inten4es do usurio +inal.

3. A !otao da Lin"ua"em de Modela"em Unificada UML Tendo em mente as cinco +ases do desen'ol'imento de so+t@ares, as +ases de anlise de requisitos, anlise e design utili*am$se em seu desen'ol'imento cinco ti os de 'is4es, no'e ti os de diagramas e 'rios modelos de elementos que sero utili*ados na criao dos diagramas e mecanismos gerais que todos em conjunto es eci+icam e e(em li+icam a de+inio do sistema, tanto a de+inio no que di* res eito J +uncionalidade esttica e din;mica do desen'ol'imento de um sistema. Antes de abordarmos cada um destes com onentes se aradamente, de+iniremos as artes que com 4em a #!2B 9is4esB As 9is4es mostram di+erentes as ectos do sistema que est sendo modelado. A 'iso no - um gr+ico, mas uma abstrao consistindo em uma s-rie de diagramas. De+inindo um nCmero de 'is4es, cada uma mostrar as ectos articulares do sistema, dando en+oque a ;ngulos e n:'eis de abstra4es di+erentes e uma +igura com leta do sistema oder ser constru:da. As 'is4es tamb-m odem ser'ir de ligao entre a linguagem de modelagem e o m-todoH rocesso de desen'ol'imento escol7ido. !odelos de ElementosB Os conceitos usados nos diagramas so modelos de elementos que re resentam de+ini4es comuns da orientao a objetos como as classes, objetos, mensagem, relacionamentos entre classes incluindo associa4es, de end&ncias e 7eranas. !ecanismos "eraisB Os mecanismos gerais ro'-m comentrios su lementares, in+orma4es, ou sem;ntica sobre os elementos que com 4em os modelosI eles ro'-m tamb-m mecanismos de e(tenso ara ada tar ou estender a #!2 ara um m-todoH rocesso, organi*ao ou usurio es ec:+ico. DiagramasB Os diagramas so os gr+icos que descre'em o conteCdo em uma 'iso. #!2 ossui no'e ti o de diagramas que so usados em combinao ara ro'er todas as 'is4es do sistema.

10

4. #is$es O desen'ol'imento de um sistema com le(o no - uma tare+a +cil. O ideal seria que o sistema inteiro udesse ser descrito em um Cnico gr+ico e que este re resentasse or com leto as reais inten4es do sistema sem ambiguidades, sendo +acilmente inter ret'el. )n+eli*mente, isso im oss:'el. #m Cnico gr+ico - inca a* de ca turar todas as in+orma4es necessrias ara descre'er um sistema. #m sistema - com osto or di'ersos as ectosB +uncional (que - sua estrutura esttica e suas intera4es din;micas), no +uncional (requisitos de tem o, con+iabilidade, desen'ol'imento, etc.) e as ectos organi*acionais (organi*ao do trabal7o, ma eamento dos m/dulos de c/digo, etc.). Ento o sistema - descrito em um certo nCmero de 'is4es, cada uma re resentando uma rojeo da descrio com leta e mostrando as ectos articulares do sistema. Cada 'iso - descrita or um nCmero de diagramas que cont-m in+orma4es que do &n+ase aos as ectos articulares do sistema. E(iste em alguns casos uma certa sobre osio entre os diagramas o que signi+ica que um deste ode +a*er arte de mais de uma 'iso. Os diagramas que com 4em as 'is4es cont-m os modelos de elementos do sistema. As 'is4es que com 4em um sistema soB

9iso 1use$case1B Descre'e a +uncionalidade do sistema desem en7ada elos atores e(ternos do sistema (usurios). A 'iso use$case - central, j que seu conteCdo - base do desen'ol'imento das outras 'is4es do sistema. Essa 'iso - montada sobre os diagramas de use$case e e'entualmente diagramas de ati'idade. 9iso 2/gicaB Descre'e como a +uncionalidade do sistema ser im lementada. 3 +eita rinci almente elos analistas e desen'ol'edores. Em contraste com a 'iso use$case, a 'iso l/gica obser'a e estuda o sistema internamente. Ela descre'e e es eci+ica a

11

estrutura esttica do sistema (classes, objetos, e relacionamentos) e as colabora4es din;micas quando os objetos en'iarem mensagens uns ara os outros ara reali*arem as +un4es do sistema. Pro riedades como ersist&ncia e concorr&ncia so de+inidas nesta +ase, bem como as inter+aces e as estruturas de classes. A estrutura esttica - descrita elos diagramas de classes e objetos. O modelamento din;mico - descrito elos diagramas de estado, sequencia, colaborao e ati'idade. 9iso de Com onentesB 3 uma descrio da im lementao dos m/dulos e suas de end&ncias. 3 rinci almente e(ecutado or desen'ol'edores, e consiste nos com onentes dos diagramas. 9iso de concorr&nciaB Trata a di'iso do sistema em rocessos e rocessadores. Este as ecto, que - uma ro riedade no +uncional do sistema, ermite uma mel7or utili*ao do ambiente onde o sistema se encontrar, se o mesmo ossui e(ecu4es aralelas, e se e(iste dentro do sistema um gerenciamento de e'entos ass:ncronos. #ma 'e* di'idido o sistema em lin7as de e(ecuo de rocessos concorrentes (t7reads), esta 'iso de concorr&ncia de'er mostrar como se d a comunicao e a concorr&ncia destas t7reads. A 'iso de concorr&ncia - su ortada elos diagramas din;micos, que so os diagramas de estado, sequencia, colaborao e ati'idade, e elos diagramas de im lementao, que so os diagramas de com onente e e(ecuo. 9iso de Organi*aoB Dinalmente, a 'iso de organi*ao mostra a organi*ao +:sica do sistema, os com utadores, os eri+-ricos e como eles se conectam entre si. Esta 'iso ser e(ecutada elos desen'ol'edores, integradores e testadores, e ser re resentada elo diagrama de e(ecuo.

12

5. Modelos de %lementos Os conceitos usados nos diagramas so c7amados de modelos de elementos. #m modelo de elemento - de+inido com a sem;ntica, a de+inio +ormal do elemento com o e(ato signi+icado do que ele re resenta sem de+ini4es du'idosas ou amb:guas e tamb-m de+ine sua re resentao gr+ica que - mostrada nos diagramas da #!2. #m elemento ode e(istir em di'ersos ti os de diagramas, mas e(istem regras que de+inem que elementos odem ser mostrados em que ti os de diagramas. Alguns e(em los de modelos de elementos so as classes, objetos, estados, acotes e com onentes. Os relacionamentos tamb-m so modelos de elementos, e so usados ara conectar outros modelos de elementos entre si. Todos os modelos de elementos sero de+inidos e e(em li+icados a seguir. !.1. "lasses #ma classe - a descrio de um ti o de objeto. Todos os objetos so inst;ncias de classes, onde a classe descre'e as ro riedades e com ortamentos daquele objeto. Objetos s/ odem ser instanciados de classes. #sam$se classes ara classi+icar os objetos que identi+icamos no mundo real. Tomando como e(em lo C7arles Dar@in, que usou classes ara classi+icar os animais con7ecidos, e combinou suas classes or 7erana ara descre'er a 1Teoria da E'oluo1. A t-cnica de 7erana entre classes - tamb-m usada em orientao a objetos. #ma classe ode ser a descrio de um objeto em qualquer ti o de sistema G sistemas de in+ormao, t-cnicos, integrados real$time, distribu:dos, so+t@are etc. =um sistema de so+t@are, or e(em lo, e(istem classes que re resentam entidades de so+t@are num sistema o eracional como arqui'os, rogramas e(ecut'eis, janelas, barras de rolagem, etc. )denti+icar as classes de um sistema ode ser com licado, e de'e ser +eito or e( erts no dom:nio do roblema a que o so+t@are modelado se baseia. As classes de'em ser retiradas do dom:nio do roblema e serem nomeadas elo que elas re resentam no sistema. 0uando rocuramos de+inir as classes de um sistema, e(istem algumas quest4es que odem ajudar a identi+ic$lasB E(istem in+orma4es que de'em ser arma*enadas ou analisadasK %e e(istir alguma in+ormao que ten7a que ser guardada, trans+ormada ou analisada de alguma +orma, ento - uma oss:'el candidata ara ser uma classe. E(istem sistemas e(ternos ao modeladoK %e e(istir, eles de'ero ser 'istos como classes elo sistema ara que ossa interagir com outros e(ternos. E(istem classes de bibliotecas, com onentes ou modelos e(ternos a serem utili*ados elo sistema modeladoK %e sim, normalmente essas classes, com onentes e modelos contero classes candidatas ao nosso sistema. 0ual o a el dos atores dentro do sistemaK Tal'e* o a el deles ossa ser 'isto como classes, or e(em lo, usurio, o erador, cliente e da: or diante.

13

Em #!2 as classes so re resentadas or um ret;ngulo di'idido em tr&s com artimentosB o com artimento de nome, que conter a enas o nome da classe modelada, o de atributos, que ossuir a relao de atributos que a classe ossui em sua estrutura interna, e o com artimento de o era4es, que sero o m-todos de mani ulao de dados e de comunicao de uma classe com outras do sistema. A sinta(e usada em cada um destes com artimentos - inde endente de qualquer linguagem de rogramao, embora ode ser usadas outras sinta(es como a do CLL, 8a'a, e etc.

!.2. #$jetos #m objeto - um elemento que odemos mani ular, acom an7ar seu com ortamento, criar, destruir etc. #m objeto e(iste no mundo real. Pode ser uma arte de qualquer ti o de sistema, or e(em lo, uma mquina, uma organi*ao, ou neg/cio. E(istem objetos que no encontramos no mundo real, mas que odem ser 'istos de deri'a4es de estudos da estrutura e com ortamento de outros objetos do mundo real. Em #!2 um objeto - mostrado como uma classe s/ que seu nome (do objeto) - sublin7ado, e o nome do objeto ode ser mostrado o cionalmente recedido do nome da classe.

!.3. %stados Todos os objetos ossuem um estado que signi+ica o resultado de ati'idades e(ecutadas elo objeto, e - normalmente determinada elos 'alores de seus atributos e liga4es com outros objetos. #m objeto muda de estado quando acontece algo, o +ato de acontecer alguma coisa com o objeto - c7amado de e'ento. Atra'-s da anlise da mudana de estados dos ti os de objetos de um sistema, odemos re'er todos os oss:'eis com ortamentos de um objetos de acordo com os e'entos que o mesmo ossa so+rer.

14

#m estado, em sua notao, ode conter tr&s com artimentos. O rimeiro mostra o nome do estado. O segundo - o cional e mostra a 'ari'el do estado, onde os atributos do objeto em questo odem ser listados e atuali*ados. Os atributos so aqueles mostrados na re resentao da classe, e em algumas 'e*es, odem ser mostradas tamb-m as 'ari'eis tem orrias, que so muito Cteis em diagramas de estado, j que atra'-s da obser';ncia de seus 'alores odemos erceber a sua in+lu&ncia na mudana de estados de um objeto. O terceiro com artimento o cional e - c7amado de com artimento de ati'idade, onde e'entos e a4es odem ser listadas. Tr&s e'entos adr4es odem ser mostrados no com artimento de ati'idades de um estadoB entrar, sair e +a*er. O e'ento entrar ode ser usado ara de+inir ati'idades no momento em que o objeto entra naquele estado. O e'ento sair, de+ine ati'idades que o objeto e(ecuta antes de assar ara o r/(imo estado e o e'ento +a*er de+ine as ati'idades do objeto enquanto se encontra naquele estado. !.4. Pa&otes Pacote - um mecanismo de agru amento, onde todos os modelos de elementos odem ser agru ados. Em #!2, um acote - de+inido comoB 1#m mecanismo de ro /sito geral ara organi*ar elementos semanticamente relacionados em gru os.1 Todos os modelos de elementos que so ligados ou re+erenciados or um acote so c7amados de 1ConteCdo do acote1. #m acote ossui 'rios modelos de elementos, e isto signi+ica que estes no odem ser inclu:dos em outros acotes.

Pacotes odem im ortar modelos de elementos de outros acotes. 0uando um modelo de elemento - im ortado, re+ere$se a enas ao acote que ossui o elemento. =a grande maioria dos

15

casos, os acotes ossuem relacionamentos com outros acotes. Embora estes no ossuam sem;nticas de+inidas ara suas inst;ncias. Os relacionamentos ermitidos entre acotes so de de end&ncia, re+inamento e generali*ao (7erana). O acote tem uma grande similaridade com a agregao (relacionamento que ser tratado em seguida). O +ato de um acote ser com osto de modelos de elementos cria uma agregao de com osio. %e este +or destru:do, todo o seu conteCdo tamb-m ser. !.5. "om'onentes #m com onente ode ser tanto um c/digo em linguagem de rogramao como um c/digo e(ecut'el j com ilado. Por e(em lo, em um sistema desen'ol'ido em 8a'a, cada arqui'o .java ou .class - um com onente do sistema, e ser mostrado no diagrama de com onentes que os utili*a.

!.(. Rela&ionamentos Os relacionamentos ligam as classesHobjetos entre si criando rela4es l/gicas entre estas entidades. Os relacionamentos odem ser dos seguintes ti osB AssociaoB 3 uma cone(o entre classes, e tamb-m signi+ica que - uma cone(o entre objetos daquelas classes. Em #!2, uma associao - de+inida com um relacionamento que descre'e uma s-rie de liga4es, onde a ligao - de+inida como a sem;ntica entre as du las de objetos ligados. "enerali*aoB 3 um relacionamento de um elemento mais geral e outro mais es ec:+ico. O elemento mais es ec:+ico ode conter a enas in+orma4es adicionais. #ma inst;ncia (um objeto - uma inst;ncia de uma classe) do elemento mais es ec:+ico ode ser usada onde o elemento mais geral seja ermitido. De end&ncia e Re+inamentosB De end&ncia - um relacionamento entre elementos, um inde endente e outro de endente. #ma modi+icao - um elemento inde endente a+etar diretamente elementos de endentes do anterior. Re+inamento - um relacionamento entre duas descri4es de uma mesma entidade, mas em n:'eis di+erentes de abstrao.

Abordaremos agora cada ti o de relacionamento e suas res ecti'as sub$di'is4esB

16

5.3.- Associa$es #ma associao re resenta que duas classes ossuem uma ligao (lin<) entre elas, signi+icando or e(em lo que elas 1con7ecem uma a outra1, 1esto conectadas com1, 1 ara cada M e(iste um A1 e assim or diante. Classes e associa4es so muito oderosas quando modeladas em sistemas com le(os. Associa$es !ormais O ti o mais comum de associao - a enas uma cone(o entre classes. 3 re resentada or uma lin7a s/lida entre duas classes. A associao ossui um nome (junto J lin7a que re resenta a associao), normalmente um 'erbo, mas substanti'os tamb-m so ermitidos. Pode$se tamb-m colocar uma seta no +inal da associao indicando que esta s/ ode ser usada ara o lado onde a seta a onta. !as associa4es tamb-m odem ossuir dois nomes, signi+icando um nome ara cada sentido da associao. Para e( ressar a multi licidade entre os relacionamentos, um inter'alo indica quantos objetos esto relacionados no lin<. O inter'alo ode ser de *ero ara um (F..>), *ero ara 'rios (F..N ou a enas N), um ara 'rios (>..N), dois (O), cinco ara >> (P..>>) e assim or diante. 3 tamb-m oss:'el e( ressar uma s-rie de nCmeros como (>, Q, R..>O). %e no +or descrito nen7uma multi licidade, ento - considerado o adro de um ara um (>..> ou a enas >).

=o e(em lo acima 'emos um relacionamento entre as classes Cliente e Conta Corrente se relacionam or associao. Associao 6ecursiva 3 oss:'el conectar uma classe a ela mesma atra'-s de uma associao e que ainda re resenta semanticamente a cone(o entre dois objetos, mas os objetos conectados so da mesma classe. #ma associao deste ti o - c7amada de associao recursi'a.

Associao 7ualificada Associa4es quali+icadas so usadas com associa4es de um ara 'rios (>..N) ou 'rios ara 'rios (N). O 1quali+icador1 (identi+icador da associao quali+icada) es eci+ica como um determinado objeto no +inal da associao 1n1 - identi+icado, e ode ser 'isto como um ti o de

17

c7a'e ara se arar todos os objetos na associao. O identi+icador - desen7ado como uma equena cai(a no +inal da associao junto J classe de onde a na'egao de'e ser +eita.

Associao %,clusiva Em alguns modelos nem todas as combina4es so 'lidas, e isto ode causar roblemas que de'em ser tratados. #ma associao e(clusi'a - uma restrio em duas ou mais associa4es. Ela es eci+ica que objetos de uma classe odem artici ar de no m(imo uma das associa4es em um dado momento. #ma associao e(clusi'a - re resentada or uma lin7a tracejada entre as associa4es que so arte da associao e(clusi'a, com a es eci+icao 1SouT1 sobre a lin7a tracejada.

=o diagrama acima um contrato no ode se re+erir a uma essoa e a uma em resa ao mesmo tem o, signi+icando que o relacionamento - e(clusi'o a somente uma das duas classes. Associao 'rdenada As associa4es entre objetos odem ter uma ordem im l:cita. O adro ara uma associao desordenada (ou sem nen7uma ordem es ec:+ica). !as uma ordem ode ser es eci+icada atra'-s da associao ordenada. Este ti o de associao ode ser muito Ctil em casos como esteB janelas de um sistema t&m que ser ordenadas na tela (uma est no to o, uma est no +undo e assim or diante). A associao ordenada ode ser escrita a enas colocando 1SordenadaT1 junto a lin7a de associao entre as duas classes. Associao de )lasse #ma classe ode ser associada a uma outra associao. Este ti o de associao no - conectada a nen7uma das e(tremidades da associao j e(istente, mas na r/ ria lin7a da associao. Esta associao ser'e ara se adicionar in+orma4es e(tra a associao j e(istente.

18

A associao da classe Dila com a associao das classes Cliente e Processo ode ser estendida com o era4es de adicionar rocessos na +ila, ara ler e remo'er da +ila e de ler o seu taman7o. %e o era4es ou atributos so adicionados a associao, ela de'e ser mostrada como uma classe. Associao 8ern9ria !ais de duas classes odem ser associadas entre si, a associao ternria associa tr&s classes. Ela - mostrada como um grade losango (diamante) e ainda su orta uma associao de classe ligada a ela, traaria$se, ento, uma lin7a tracejada a artir do losango ara a classe onde seria +eita a associao ternria.

=o e(em lo acima a associao ternria es eci+ica que um cliente oder ossuir > ou mais contratos e cada contrato ser com osto de > ou 'rias regras contratuais. A"re"ao A agregao - um caso articular da associao. A agregao indica que uma das classes do relacionamento - uma arte, ou est contida em outra classe. As ala'ras c7a'es usadas ara identi+icar uma agregao soB 1consiste em1, 1cont-m1, 1- arte de1.

E(istem ti os es eciais de agregao que so as agrega4es com artil7adas e as com ostas. Agregao Com artil7adaB 3 dita com artil7ada quando uma das classes - uma arte, ou est contida na outra, mas esta arte ode +a*er estar contida na outra 'rias 'e*es em um mesmo momento.

19

=o e(em lo acima uma essoa ode ser membro de um time ou 'rios times e em determinado momento. Agregao de Com osioB 3 uma agregao onde uma classe que est contida na outra 1'i'e1 e constitui a outra. %e o objeto da classe que cont-m +or destru:do, as classes da agregao de com osio sero destru:das juntamente j que as mesmas +a*em arte da outra.

5.3./. :enerali&a$es A generali*ao - um relacionamento entre um elemento geral e um outro mais es ec:+ico. O elemento mais es ec:+ico ossui todas as caracter:sticas do elemento geral e cont-m ainda mais articularidades. #m objeto mais es ec:+ico ode ser usado como uma inst;ncia do elemento mais geral. A generali*ao, tamb-m c7amada de 7erana, ermite a criao de elementos es eciali*ados em outros. E(istem alguns ti os de generali*a4es que 'ariam em sua utili*ao a artir da situao. %o elasB generali*ao normal e restrita. As generali*a4es restritas se di'idem em generali*ao de sobre osio, disjunti'a, com leta e incom leta. :enerali&ao !ormal =a generali*ao normal a classe mais es ec:+ica, c7amada de subclasse, 7erda tudo da classe mais geral, c7amada de su erclasse. Os atributos, o era4es e todas as associa4es so 7erdadas.

#ma classe ode ser tanto uma subclasse quanto uma su erclasse, se ela esti'er numa 7ierarquia de classes que - um gr+ico onde as classes esto ligadas atra'-s de generali*a4es. A generali*ao normal - re resentada or uma lin7a entre as duas classes que +a*em o relacionamento, sendo que coloca$se um seta no lado da lin7a onde encontra$se a su erclasse indicando a generali*ao.

20

:enerali&ao 6estrita #ma restrio a licada a uma generali*ao es eci+ica in+orma4es mais recisas sobre como a generali*ao de'e ser usada e estendida no +uturo. As restri4es a seguir de+inem as generali*a4es restritas com mais de uma subclasseB "enerali*a4es de %obre osio e Disjunti'aB "enerali*ao de sobre osio signi+ica que quando subclasses 7erdam de uma su erclasse or sobre osio, no'as subclasses destas odem 7erdar de mais de uma subclasse. A generali*ao disjunti'a - e(atamente o contrrio da sobre osio e a generali*ao - utili*ada como adro.

"enerali*a4es Com leta e )ncom letaB #ma restrio simboli*ando que uma generali*ao - com leta signi+ica que todas as subclasses j +oram es eci+icadas, e no e(iste mais ossibilidade de outra generali*ao a artir daquele onto. A generali*ao incom leta - e(atamente o contrrio da com leta e - assumida como adro da linguagem.

5.3.0. Depend;ncia e 6efinamentos Al-m das associa4es e generali*a4es, e(istem ainda dois ti os de relacionamentos em #!2. O relacionamento de de end&ncia - uma cone(o sem;ntica entre dois modelos de elementos, um

21

inde endente e outro de endente. #ma mudana no elemento inde endente ir a+etar o modelo de endente. Como no caso anterior com generali*a4es, os modelos de elementos odem ser uma classe, um acote, um use$case e assim or diante. 0uando uma classe recebe um objeto de outra classe como ar;metro, uma classe acessa o objeto global da outra. =esse caso e(iste uma de end&ncia entre estas duas classes, a esar de no ser e( l:cita. #ma relao de de end&ncia - simboli*ada or uma lin7a tracejada com uma seta no +inal de um dos lados do relacionamento. E sobre essa lin7a o ti o de de end&ncia que e(iste entre as duas classes. As classes 1Amigas1 ro'enientes do CLL so um e(em lo de um relacionamento de de end&ncia.

Os re+inamentos so um ti o de relacionamento entre duas descri4es de uma mesma coisa, mas em n:'eis de abstrao di+erentes e odem ser usados ara modelar di+erentes im lementa4es de uma mesma coisa (uma im lementao sim les e outra mais com le(a, mas tamb-m mais e+iciente). Os re+inamentos so simboli*ados or uma lin7a tracejada com um tri;ngulo no +inal de um dos lados do relacionamento e so usados em modelos de coordenao. Em grandes rojetos, todos os modelos que so +eitos de'em ser coordenados. Coordenao de modelos ode ser usada ara mostrar modelos em di+erentes n:'eis de abstrao que se relacionam e mostram tamb-m como modelos em di+erentes +ases de desen'ol'imento se relacionam.

!.). *e&anismos +erais A #!2 utili*a alguns mecanismos em seus diagramas ara tratar in+orma4es adicionais. OrnamentosB Ornamentos gr+icos so ane(ados aos modelos de elementos em diagramas e adicionam sem;nticas ao elemento. #m e(em lo de um ornamento - o da t-cnica de se arar um ti o de uma inst;ncia. 0uando um elemento re resenta um ti o, seu nome - mostrado em negrito. 0uando o mesmo elemento re resenta a inst;ncia de um ti o, seu nome - escrito sublin7ado e ode signi+icar tanto o nome da inst;ncia quanto o nome do ti o. Outros ornamentos so os de es eci+icao de multi licidade de relacionamentos, onde a multi licidade - um nCmero ou um inter'alo que indica quantas inst;ncias de um ti o conectado ode estar en'ol'ido na relao. =otasB =em tudo ode ser de+inido em uma linguagem de modelagem, sem im ortar o quanto e(tensa ela seja. Para ermitir adicionar in+orma4es a um modelo no oderia ser re resentado de outra +orma, #!2 ro'& a ca acidade de adicionar =otas. #ma =ota ode ser colocada em qualquer lugar em um diagrama, e ode conter qualquer ti o de in+ormao.

22

<. Dia"ramas Os diagramas utili*ados ela #!2 so com ostos de no'e ti osB diagrama de use case, de classes, de objeto, de estado, de sequ&ncia, de colaborao, de ati'idade, de com onente e o de e(ecuo. Todos os sistemas ossuem uma estrutura esttica e um com ortamento din;mico. A #!2 su orta modelos estticos (estrutura esttica), din;micos (com ortamento din;mico) e +uncional. A !odelagem esttica - su ortada elo diagrama de classes e de objetos, que consiste nas classes e seus relacionamentos. Os relacionamentos odem ser de associa4es, 7erana (generali*ao), de end&ncia ou re+inamentos. Os modelamentos din;micos so su ortados elos diagramas de estado, sequ&ncia, colaborao e ati'idade. E o modelamento +uncional - su ortado elos diagramas de com onente e e(ecuo. Abordaremos agora cada um destes ti os de diagramaB ,.1. Diagrama -se."ase A modelagem de um diagrama use$case - uma t-cnica usada ara descre'er e de+inir os requisitos +uncionais de um sistema. Eles so escritos em termos de atores e(ternos, use$cases e o sistema modelado. Os atores re resentam o a el de uma entidade e(terna ao sistema como um usurio, um 7ard@are, ou outro sistema que interage com o sistema modelado. Os atores iniciam a comunicao com o sistema atra'-s dos use$cases, onde o use$case re resenta uma sequ&ncia de a4es e(ecutadas elo sistema e recebe do ator que l7e utili*a dados tang:'eis de um ti o ou +ormato j con7ecido, e o 'alor de res osta da e(ecuo de um use$case (conteCdo) tamb-m j de um ti o con7ecido, tudo isso - de+inido juntamente com o use$case atra'-s de te(to de documentao. Atores e use$cases so classes. #m ator - conectado a um ou mais use$cases atra'-s de associa4es, e tanto atores quanto use$cases odem ossuir relacionamentos de generali*ao que de+inem um com ortamento comum de 7erana em su erclasses es eciali*adas em subclasses. O uso de use$cases em colabora4es - muito im ortante, onde estas so a descrio de um conte(to mostrando classesHobjetos, seus relacionamentos e sua interao e(em li+icando como as classesHobjetos interagem ara e(ecutar uma ati'idade es ec:+ica no sistema. #ma colaborao - descrita or diagramas de ati'idades e um diagrama de colaborao. 0uando um use$case - im lementado, a res onsabilidade de cada asso da e(ecuo de'e ser associada Js classes que artici am da colaborao, ti icamente es eci+icando as o era4es necessrias dentro destas classes juntamente com a de+inio de como elas iro interagir. #m

23

cenrio - uma inst;ncia de um use$case, ou de uma colaborao, mostrando o camin7o es ec:+ico de cada ao. Por isso, o cenrio - um im ortante e(em lo de um use$case ou de uma colaborao. 0uando 'isto a n:'el de um use$case, a enas a interao entre o ator e(terno e o use$case - 'ista, mas j obser'ando a n:'el de uma colaborao, toda as intera4es e assos da e(ecuo que im lementam o sistema sero descritos e es eci+icados.

O diagrama de use$cases acima demonstra as +un4es de um ator e(terno de um sistema de controle bancrio de um banco +ict:cio que +oi modelado no estudo de caso no +inal deste trabal7o. O diagrama es eci+ica que +un4es o administrador do banco oder desem en7ar. Pode$se erceber que no e(iste nen7uma reocu ao com a im lementao de cada uma destas +un4es, j que este diagrama a enas se resume a determinar que +un4es de'ero ser su ortadas elo sistema modelado. ,.2 Diagrama de "lasses O diagrama de classes demonstra a estrutura esttica das classes de um sistema onde estas re resentam as 1coisas1 que so gerenciadas ela a licao modelada. Classes odem se relacionar com outras atra'-s de di'ersas maneirasB associao (conectadas entre si), de end&ncia (uma classe de ende ou usa outra classe), es eciali*ao (uma classe - uma es eciali*ao de outra classe), ou em acotes (classes agru adas or caracter:sticas similares). Todos estes relacionamentos so mostrados no diagrama de classes juntamente com as suas estruturas internas, que so os atributos e o era4es. O diagrama de classes - considerado esttico j que a estrutura descrita - sem re 'lida em qualquer onto do ciclo de 'ida do sistema. #m sistema normalmente ossui alguns diagramas de classes, j que no so todas as classes que esto inseridas em um Cnico diagrama e uma certa classes ode artici ar de 'rios diagramas de classes.

24

#ma classe num diagrama ode ser diretamente im lementada utili*ando$se uma linguagem de rogramao orientada a objetos que ten7a su orte direto ara construo de classes. Para criar um diagrama de classes, as classes t&m que estar identi+icadas, descritas e relacionadas entre si. ,.3. Diagrama de #$jetos O diagrama de objetos - uma 'ariao do diagrama de classes e utili*a quase a mesma notao. A di+erena - que o diagrama de objetos mostra os objetos que +oram instanciados das classes. O diagrama de objetos - como se +osse o er+il do sistema em um certo momento de sua e(ecuo. A mesma notao do diagrama de classes - utili*ada com O e(ce4esB os objetos so escritos com seus nomes sublin7ados e todas as inst;ncias num relacionamento so mostradas. Os diagramas de objetos no so to im ortantes como os diagramas de classes, mas eles so muito Cteis ara e(em li+icar diagramas com le(os de classes ajudando muito em sua com reenso. Diagramas de objetos tamb-m so usados como arte dos diagramas de colaborao, onde a colaborao din;mica entre os objetos do sistema so mostrados.

,.4. Diagrama de %stado O diagrama de estado - ti icamente um com lemento ara a descrio das classes. Este diagrama mostra todos os estados oss:'eis que objetos de uma certa classe odem se encontrar e mostra tamb-m quais so os e'entos do sistemas que ro'ocam tais mudanas. Os diagramas

25

de estado no so escritos ara todas as classes de um sistema, mas a enas ara aquelas que ossuem um nCmero de+inido de estados con7ecidos e onde o com ortamento das classes a+etado e modi+icado elos di+erentes estados. Diagramas de estado ca turam o ciclo de 'ida dos objetos, subsistemas e sistemas. Eles mostram os estados que um objeto ode ossuir e como os e'entos (mensagens recebidas, timer, erros, e condi4es sendo satis+eitas) a+etam estes estados ao assar do tem o.

Diagramas de estado ossuem um onto de in:cio e 'rios ontos de +inali*ao. #m onto de in:cio (estado inicial) - mostrado como um c:rculo todo reenc7ido, e um onto de +inali*ao (estado +inal) - mostrado como um c:rculo em 'olta de um outro c:rculo menor reenc7ido. #m estado - mostrado como um ret;ngulo com cantos arredondados. Entre os estados esto as transi4es, mostrados como uma lin7a com uma seta no +inal de um dos estados. A transio ode ser nomeada com o seu e'ento causador. 0uando o e'ento acontece, a transio de um estado ara outro - e(ecutada ou dis arada. #ma transio de estado normalmente ossui um e'ento ligado a ela. %e um e'ento - ane(ado a uma transio, esta ser e(ecutada quando o e'ento ocorrer. %e uma transio no ossuir um e'ento ligado a ela, a mesma ocorrer quando a ao interna do c/digo do estado +or e(ecutada (se e(istir a4es internas como entrar, sair, +a*er ou outras a4es de+inidas elo desen'ol'edor). Ento quando todas as a4es +orem e(ecutadas elo estado, a transio ser dis arada e sero iniciadas as ati'idades do r/(imo estado no diagrama de estados. ,.5. Diagrama de /equ0n&ia #m diagrama de sequ&ncia mostra a colaborao din;mica entre os 'rios objetos de um sistema. O mais im ortante as ecto deste diagrama - que a artir dele ercebe$se a sequ&ncia de mensagens en'iadas entre os objetos. Ele mostra a interao entre os objetos, alguma coisa que acontecer em um onto es ec:+ico da e(ecuo do sistema. O diagrama de sequ&ncia consiste em um nCmero de objetos mostrado em lin7as 'erticais. O decorrer do tem o - 'isuali*ado obser'ando$se o diagrama no sentido 'ertical de cima ara bai(o. As mensagens en'iadas or cada objeto so simboli*adas or setas entre os objetos que se relacionam. Diagramas de sequ&ncia ossuem dois ei(osB o ei(o 'ertical, que mostra o tem o e o ei(o 7ori*ontal, que mostra os objetos en'ol'idos na sequ&ncia de uma certa ati'idade. Eles tamb-m mostram as intera4es ara um cenrio es ec:+ico de uma certa ati'idade do sistema.

26

=o ei(o 7ori*ontal esto os objetos en'ol'idos na sequ&ncia. Cada um - re resentado or um ret;ngulo de objeto (similar ao diagrama de objetos) e uma lin7a 'ertical ontil7ada c7amada de lin7a de 'ida do objeto, indicando a e(ecuo do objeto durante a sequ&ncia, como e(em lo citamosB mensagens recebidas ou en'iadas e ati'ao de objetos. A comunicao entre os objetos - re resentada como lin7a com setas 7ori*ontais simboli*ando as mensagens entre as lin7as de 'ida dos objetos. A seta es eci+ica se a mensagem - s:ncrona, ass:ncrona ou sim les. As mensagens odem ossuir tamb-m nCmeros sequenciais, eles so utili*ados ara tornar mais e( l:cito as sequ&ncia no diagrama. Em alguns sistemas, objetos rodam concorrentemente, cada um com sua lin7a de e(ecuo (t7read). %e o sistema usa lin7as concorrentes de controle, isto - mostrado como ati'ao, mensagens ass:ncronas, ou objetos ass:ncronos.

Os diagramas de sequ&ncia odem mostrar objetos que so criados ou destru:dos como arte do cenrio documentado elo diagrama. #m objeto ode criar outros objetos atra'-s de mensagens. A mensagem que cria ou destroi um objeto - geralmente s:ncrona, re resentada or uma seta s/lida. ,.(. Diagrama de "ola$orao #m diagrama de colaborao mostra de maneira semel7ante ao diagrama de sequencia, a colaborao din;mica entre os objetos. =ormalmente ode$se escol7er entre utili*ar o diagrama de colaborao ou o diagrama de sequ&ncia. =o diagrama de colaborao, al-m de mostrar a troca de mensagens entre os objetos, ercebe$se tamb-m os objetos com os seus relacionamentos. A interao de mensagens - mostrada em ambos os diagramas. %e a &n+ase do diagrama +or o decorrer do tem o, - mel7or escol7er o diagrama de sequ&ncia, mas se a &n+ase +or o conte(to do sistema, - mel7or dar rioridade ao diagrama de colaborao. O diagrama de colaborao - desen7ado como um diagrama de objeto, onde os di'ersos objetos so mostrados juntamente com seus relacionamentos. As setas de mensagens so desen7adas entre os objetos ara mostrar o +lu(o de mensagens entre eles. As mensagens so nomeadas, que entre outras coisas mostram a ordem em que as mensagens so en'iadas. Tamb-m odem mostrar condi4es, intera4es, 'alores de res osta, e etc. O diagrama de colaborao tamb-m ode conter objetos ati'os, que e(ecutam aralelamente com outros.

27

,.). Diagrama de Ati1idade Diagramas de ati'idade ca turam a4es e seus resultados. Eles +ocam o trabal7o e(ecutado na im lementao de uma o erao (m-todo), e suas ati'idades numa inst;ncia de um objeto. O diagrama de ati'idade - uma 'ariao do diagrama de estado e ossui um ro /sito um ouco di+erente do diagrama de estado, que - o de ca turar a4es (trabal7o e ati'idades que sero e(ecutados) e seus resultados em termos das mudanas de estados dos objetos. Os estados no diagrama de ati'idade mudam ara um r/(imo estgio quando uma ao e(ecutada (sem ser necessrio es eci+icar nen7um e'ento como no diagrama de estado). Outra di+erena entre o diagrama de ati'idade e o de estado - que odem ser colocadas como 1s@imlanes1. #ma s@imlane agru a ati'idades, com res eito a quem - res ons'el e onde estas ati'idades residem na organi*ao, e - re resentada or ret;ngulos que englobam todos os objetos que esto ligados a ela (s@imlane). #m diagrama de ati'idade - uma maneira alternati'a de se mostrar intera4es, com a ossibilidade de e( ressar como as a4es so e(ecutadas, o que elas +a*em (mudanas dos estados dos objetos), quando elas so e(ecutadas (sequ&ncia das a4es), e onde elas acontecem (s@imlanes). #m diagrama de ati'idade ode ser usado com di+erentes ro /sitos inclusi'eB Para ca turar os trabal7os que sero e(ecutados quando uma o erao - dis arada (a4es). Este - o uso mais comum ara o diagrama de ati'idade. Para ca turar o trabal7o interno em um objeto. Para mostrar como um gru o de a4es relacionadas odem ser e(ecutadas, e como elas 'o a+etar os objetos em torno delas. Para mostrar como uma inst;ncia ode ser e(ecutada em termos de a4es e objetos. Para mostrar como um neg/cio +unciona em termos de trabal7adores (atores), +lu(os de trabal7o, organi*ao, e objetos (+atores +:sicos e intelectuais usados no neg/cio).

O diagrama de ati'idade mostra o +lu(o sequencial das ati'idades, - normalmente utili*ado ara demonstrar as ati'idades e(ecutadas or uma o erao es ec:+ica do sistema. Consistem em estados de ao, que cont-m a es eci+icao de uma ati'idade a ser desem en7ada or uma o erao do sistema. Decis4es e condi4es, como e(ecuo aralela, tamb-m odem ser mostrados na diagrama de ati'idade. O diagrama tamb-m ode conter es eci+ica4es de mensagens en'iadas e recebidas como artes de a4es e(ecutadas.

28

,.!. Diagrama de "om'onente O diagrama de com onente e o de e(ecuo so diagramas que mostram o sistema or um lado +uncional, e( ondo as rela4es entre seus com onentes e a organi*ao de seus m/dulos durante sua e(ecuo. O diagrama de com onente descre'e os com onentes de so+t@are e suas de end&ncias entre si, re resentando a estrutura do c/digo gerado. Os com onentes so a im lementao na arquitetura +:sica dos conceitos e da +uncionalidade de+inidos na arquitetura l/gica (classes, objetos e seus relacionamentos). Eles so ti icamente os arqui'os im lementados no ambiente de desen'ol'imento. #m com onente - mostrado em #!2 como um ret;ngulo com uma eli se e dois ret;ngulos menores do seu lado esquerdo. O nome do com onente - escrito abai(o ou dentro de seu s:mbolo. Com onentes so ti os, mas a enas com onentes e(ecut'eis odem ter inst;ncias. #m diagrama de com onente mostra a enas com onentes como ti os. Para mostrar inst;ncias de com onentes, de'e ser usado um diagrama de e(ecuo, onde as inst;ncias e(ecut'eis so alocadas em nodes. A de end&ncia entre com onentes ode ser mostrada como uma lin7a tracejada com uma seta, simboli*ando que um com onente recisa do outro ara ossuir uma de+inio com leta. Com o diagrama de com onentes - +acilmente 'is:'el detectar que arqui'os .dll so necessrios ara e(ecutar a a licao.

29

Com onentes odem de+inir inter+aces que so 'is:'eis ara outros com onentes. As inter+aces odem ser tanto de+inidas ao n:'el de codi+icao (como em 8a'a) quanto em inter+aces binrias usadas em run$time (como em O2E). #ma inter+ace - mostrada como uma lin7a artindo do com onente e com um c:rculo na outra e(tremidade. O nome - colocado junto do c:rculo no +inal da lin7a. De end&ncias entre com onentes odem ento a ontar ara a inter+ace do com onente que est sendo usada. ,.,. Diagrama de %2e&uo O diagrama de e(ecuo mostra a arquitetura +:sica do 7ard@are e do so+t@are no sistema. Pode mostrar os atuais com utadores e eri+-ricos, juntamente com as cone(4es que eles estabelecem entre si e ode mostrar tamb-m os ti os de cone(4es entre esses com utadores e eri+-ricos. Es eci+ica$se tamb-m os com onentes e(ecut'eis e objetos que so alocados ara mostrar quais unidades de so+t@are so e(ecutados e em que destes com utadores so e(ecutados. O diagrama de e(ecuo demonstra a arquitetura run$time de rocessadores, com onentes +:sicos (de'ices), e de so+t@are que rodam no ambiente onde o sistema desen'ol'ido ser utili*ado. 3 a Cltima descrio +:sica da to ologia do sistema, descre'endo a estrutura de 7ard@are e so+t@are que e(ecutam em cada unidade. O diagrama de e(ecuo - com osto or com onentes, que ossuem a mesma simbologia dos com onentes do diagrama de com onentes, nodes, que signi+icam objetos +:sicos que +a*em arte do sistema, odendo ser uma mquina cliente numa 2A=, uma mquina ser'idora, uma im ressora, um roteador, etc., e cone(4es entre estes nodes e com onentes que juntos com 4em toda a arquitetura +:sica do sistema.

30

31

-=. Um processo para utili&ar a UML A #!2 cont-m nota4es e regras que tornam oss:'el e( ressar modelos orientados a objetos. !as ela no rescre'e como o trabal7o tem que ser +eito, ou seja, no ossui um rocesso de como o trabal7o tem que ser desen'ol'ido. 8 que a #!2 +oi desen'ol'ida ara ser usada em di'ersos m-todos de desen'ol'imento. Para usar a #!2 com sucesso - necessrio adotar algum ti o de m-todo de desen'ol'imento, es ecialmente em sistema de grande orte onde a organi*ao de tare+as - essencial. A utili*ao de um rocesso de desen'ol'imento torna mais e+iciente calcular o rogresso do rojeto, controlar e mel7orar o trabal7o. #m rocesso de desen'ol'imento descre'e 1o que +a*er1, 1como +a*er1, 1quando +a*er1, e 1 orque de'e ser +eito1. Este tamb-m descre'e um nCmero de ati'idades que de'em ser e(ecutadas em uma certa ordem. 0uando so de+inidas e relacionadas as ati'idades de um rocesso, um objeti'o es ec:+ico - alcanado. Em seu uso normal, a ala'ra 1 rocesso1 signi+ica uma relao de ati'idades que de'em ser e(ecutadas em uma certa ordem sem im ortar o objeti'o, regras ou material a ser usado. =o rocesso de desen'ol'imento da engen7aria de so+t@are, - necessrio saber o objeti'o +inal do rocesso, de+inir regras a serem seguidas e adotar um m-todo +i(o de desen'ol'imento. #m m-todo ( rocesso) tradicional de desen'ol'imento orientado a objetos - di'idido em anlise de requisitos, anlise, design ( rojeto), im lementao, e testes. A anlise de requisitos ca tura as necessidades bsicas +uncionais e no$+uncionais do sistema que de'e ser desen'ol'ido. A anlise modela o roblema rinci al (classes, objetos) e cria um modelo ideal do sistema sem le'ar em conta requisitos t-cnicos do sistema. O design e( ande e ada ta os modelos da anlise ara um ambiente t-cnico, onde as solu4es t-cnicas so trabal7adas em detal7es. A im lementao consiste em codi+icar em linguagem de rogramao e banco de dados os modelos criados. E as ati'idades de testes de'em testar o sistema em di+erentes n:'eis, 'eri+icando se o mesmo corres onde as e( ectati'as do usurio. E(iste um rocesso desen'ol'ido ela Rational )nc., mesma em resa que desen'ol'eu a #!2, que monta duas 'is4es do desen'ol'imento de um sistemaB 'iso gerencial e t-cnica. A 'iso t-cnica utili*a as tradicionais ati'idades de anlise, design e im lementao, enquanto a 'iso gerencial utili*a as seguintes +ases no desen'ol'imento de cada gerao do sistema. )n:cioB De+ine o esco o e objeti'o do rojetoI ElaboraoB Desen'ol'e o roduto em detal7es atra'-s de uma s-rie de intera4es. )sto en'ol'e mais anlise, design e rogramaoI TransioB "era o sistema ara o usurio +inal, incluindo as ati'idades de mar<eting, su orte, documentao e treinamento.

Cada +ase no ciclo - e(ecutada em s-ries de intera4es que odem sobre or outras +ases. Cada interao consiste ti icamente em ati'idades tradicionais como anlise e design, mas em di+erentes ro or4es de endendo da +ase em que esteja a gerao do sistema em desen'ol'imento. Derramentas modernas de'em dar su orte no a enas ara linguagens de modelagem e rogramao, mas de'em su ortar um m-todo de desen'ol'imento de sistemas tamb-m. )sso inclui con7ecimento das +ases em um rocesso, ajuda online, e aconsel7amentos do que +a*er em

32

cada +ase do desen'ol'imento, su orte a desen'ol'imento interati'o e +cil integrao com outras +erramentas.

33

--. ' uturo da UML Embora a #!2 de+ina uma linguagem recisa, ela no - uma barreira ara +uturos a er+eioamentos nos conceitos de modelagem. O desen'ol'imento da #!2 +oi baseado em t-cnicas antigas e marcantes da orientao a objetos, mas muitas outras in+luenciaro a linguagem em suas r/(imas 'ers4es. !uitas t-cnicas a'anadas de modelagem odem ser de+inidas usando #!2 como base, odendo ser estendida sem se +a*er necessrio rede+inir a sua estrutura interna. A #!2 ser a base ara muitas +erramentas de desen'ol'imento, incluindo modelagem 'isual, simula4es e ambientes de desen'ol'imento. Em bre'e +erramentas de integrao e adr4es de im lementao baseados em #!2 estaro dis on:'eis ara qualquer um. A #!2 integrou muitas id-ias ad'ersas, e esta integrao 'ai acelerar o uso do desen'ol'imento de so+t@ares orientados a objetos.

34

-/. Um estudo de caso em UML Diante do a resentado no decorrer do trabal7o, a licaremos aqui grande arte dos conceitos abordados diante de uma a licao da #!2 num roblema +ict:cio que oder ser de grande ajuda no mel7or entendimento das otencialidades da linguagem de modelagem uni+icada. O estudo de caso dar mais &n+ase na +ases de anlise de requisitos, anlise e design, j que as rinci ais abstra4es dos modelos do sistema se encontram nestas +ases do desen'ol'imento. Desen'ol'eremos uma modelagem em #!2 ara criarmos um sistema de manuteno e controle de contas correntes e a lica4es +inanceiras de um banco +ict:cio. Antes de dar in:cio J rimeira +ase da modelagem, +aremos algumas considera4es sobre o que o sistema se ro 4e a +a*er e outras obser'a4es que consideramos de suma im ort;ncia ara o bom entendimento do roblema. O sistema su ortar um cadastro de clientes, onde cada cliente cadastrado oder ter 'rias contas correntes, 'rios de endentes ligados a ele, e 'rias contas de ou ana. Cada de endente oder ossuir 'rias contas de ou ana, mas no odero ter uma conta corrente r/ ria. Entendemos ou ana como uma conta que ossui um 'alor, um ra*o de a licao a uma ta(a de juros (de+inida no 'encimento da ou ana). Entendemos A lica4es Pr-$+i(adas como uma a licao de um 'alor, em um ra*o r-$ determinado a uma ta(a de juros re'iamente de+inida. Tanto a conta corrente quanto a ou ana de'ero manter um 7ist/rico de todas as mo'imenta4es de cr-dito, d-bito, trans+er&ncias e a lica4es de r-$+i(ados ( r-$+i(ados a enas ara conta corrente). #ma conta corrente oder ter 'rias a lica4es r-$+i(adas ligadas a ela.

12.1. Anlise de Requisitos De acordo com nossa ro osta o sistema im lementar +un4es bsicas que sero desem en7adas ela Administrao do banco e elos seus clientes. As rinci ais +un4es do sistema soB Cadastrar no'o cliente E(cluir ou editar cliente Cadastrar de endente E(cluir ou editar de endente Abrir conta corrente

35

Dec7ar conta corrente Abrir ou ana Dec7ar ou ana !o'imentar conta corrente A licar em r-$+i(ados Consultar 7ist/rico de conta corrente ou ou ana Cadastrar Ag&ncia E(cluir ou Editar Ag&ncia

Tendo em mos esta relao de ati'idades, j odemos modelar o diagrama de use$case do sistema.

36

12.2. Anlise =a +ase de anlise, tendo em mos o diagrama de use$case, odemos de+inir o diagrama de classes do sistema. Este rimeiro diagrama da +ase de anlise de'er ser totalmente des reocu ado de qualquer ti o de t-cnica relacionada a im lementao do sistema, ou seja, m-todos e atributos de acesso a banco de dados, estrutura de mensagens entre objetos, etc. no de'ero a arecer nesse rimeiro diagrama, a enas os ti os de objetos bsicos do sistema. Analisamos e ercebemos que e(istiro U classes no sistema e que se relacionaro segundo o diagrama de classes a seguir.

37

8 temos em mos as +un4es rimordiais do sistema (diagrama de use$cases) e o diagrama de classes da anlise do dom:nio do roblema, artiremos agora ara traar como estas classes iro

38

interagir ara reali*ar as +un4es do sistema. 2embramos que ainda nesta +ase nen7um ti o de t-cnica de im lementao de'e ser considerada. Para modelarmos como os objetos do sistema iro interagir entre si, utili*amos o diagrama de sequ&ncia ou o de colaborao. E modelaremos um diagrama ara cada +uno (use$case) de+inida no diagrama de use$cases. Escol7emos o diagrama de sequ&ncia ara dar mais &n+ase a ordem cronol/gica das intera4es entre os objetos. 8 se +a* necessrio utili*ar id-ias bsicas da modelagem da inter+ace do sistema como as janelas. !as esses objetos de inter+ace sero totalmente detal7ados na +ase de design.

=esta +ase modela$se tamb-m o diagrama de estado das classes. !as este se enquadra em situa4es onde o com ortamento dos objetos - im ortante ara a licao. Em casos de modelagens de sistemas ara equi amentos mec;nicos. 12.3. Design =esta +ase comearemos a im lementar em nossos modelos os mel7oramentos e t-cnicas de como realmente cada +unco do sistema ser concebida. %ero modelos mais detal7ados com &n+ase nas solu4es ara arma*enamento dos dados, +un4es rimordiais do sistema e inter+ace com o usurio. A +ase de design ode ser di'idida em outras duas +asesB Design da arquiteturaB Este - o design de alto n:'el onde os acotes (subsistemas) so de+inidos, incluindo as de end&ncias e mecanismos de comunicao entre eles. =aturalmente, o objeti'o - criar uma arquitetura sim les e clara, onde as de end&ncias sejam oucas e que ossam ser bidirecionais sem re que oss:'el. Design detal7adoB Esta arte detal7a o conteCdo dos acotes, ento todas classes sero totalmente descritas ara mostrar es eci+ica4es claras ara o rogramador que ir gerar o c/digo da classe. !odelos din;micos do #!2 so usados ara demonstrar como os objetos se com ortam em di+erentes situa4es.

Desi"n da ar>uitetura

39

#ma arquitetura bem rojetada - a base ara +uturas e( ans4es e modi+ica4es no sistema. Os acotes odem ser res ons'eis or +un4es l/gicas ou t-cnicas do sistema. 3 de 'ital im ort;ncia se arar a l/gica da a licao da l/gica t-cnica. )sso +acilitar muito +uturas mudanas no sistema. Em nosso caso de estudo, identi+icamos Q acotes (subsistemas)B

Pacote da )nter+ace do #surioB Estaro contidas as classes ara a criao da inter+ace do usurio, ara ossibilitar que estes acessem e entrem com no'os dados no sistema. Estas classes so baseadas no acote 8a'a AVT, que - o adro 8a'a ara criao de inter+aces. Este acote coo era com o acote de objetos do sistema, que cont-m as classes onde os dados esto guardados. O acote de inter+ace c7ama o era4es no acote de objetos do sistema ara acessar e inserir no'os dados. Pacote de Objetos do %istemaB Este acote inclui classes bsicas, ou seja, classes que +oram desen'ol'idas e(atamente ara tornar o sistema em desen'ol'imento +uncional. Estas classes so detal7adas no design, ento so inclu:dos o era4es e m-todos em sua estrutura e o su orte J Persist&ncia - adicionado. O acote de objetos de'e interagir com o de banco de dados e todas as suas classes de'em 7erdar da classe Persistente do acote de banco de dados Pacote de 6anco de DadosB Este acote dis onibili*a ser'ios ara as classes do acote de objetos +a*endo com que os dados arma*enados no sistema sejam gra'ados em disco. Pacote de #tilidadesB Este cont-m ser'ios que so usados or todos os outros acotes do sistema. Atualmente a classe Obj)d - a Cnica no acote, e - usada ara re+erenciar os objetos ersistentes em todo o sistema.

Desi"n detal?ado O ro /sito do design detal7ado - descre'er as no'as classes t-cnicas do sistema, como classes de criao da inter+ace, de banco de dados e ara e( andir e detal7ar a descrio das classes de objetos, que j +oram de+inidas na +ase de anlise.

40

Tudo isto - +eito com a criao de no'os diagramas de classes, de estado, e din;micos. %ero os mesmos diagramas criados na +ase de anlise, mas - um n:'el de detal7amento t-cnico mais ele'ado. As descri4es de use$cases ro'enientes da +ase de anlise so usados ara 'eri+icar se estes esto sendo su ortados elos diagramas gerados na +ase de design, e diagramas de sequencia so usados ara ilustrar como cada use$case - tecnicamente im lementada no sistema. C7egamos a um diagrama de classes mais e'olu:do com a incluso de ersist&ncia.

41

42

Criamos os diagramas de sequencia ara +un4es do sistema, descritas no diagrama de use$ cases, j ossuindo os ar;metros ara cada mensagem entre os objetos. O la5out das janelas de'e ser criado com alguma +erramenta 'isual de acordo com a re+er&ncia do desen'ol'edor. Derramentas 'isuais j geram o c/digo necessrio ara a criao de janelas. Algumas +erramentas j su ortam a adio de controladores de e'entos ara e'entos dis arados or usurios como cliques em bot4es. O ambiente gera um m-todo Wo<buttonXClic<edY que ser c7amado quando o boto 1OZ1 +or ressionado. A a licao resultante da inter+ace de usurio - uma janela rinci al com um menu de o 4es. Cada o o escol7ida do menu mostrar uma janela no'a que juntas sero res ons'eis or receber as in+orma4es do usurio e e(ecutar a +uno a qual se ro 4em a +a*er. 12.4. 3m'lementao A +ase de construo ou im lementao - quando as classes so codi+icadas. Os requisitos es eci+icam que o sistema de'e ser ca a* de rodar em di'ersos ti o de rocessadores e sistemas o eracionais, ento a linguagem escol7ida +oi 8a'a. Pelo +ato de em 8a'a cada arqui'o oder conter uma e somente uma classe, odemos +acilmente escre'er um diagrama de com onentes contendo um ma eamento das classes ro'enientes da 'iso l/gica. Agora codi+icamos cada classe do acote de objetos do sistema, a inter+ace, o banco de dados e o acote de utilidades. A codi+icao de'e ser baseada nos modelos desen'ol'idos nas +ases de anlise de requisitos, anlise e design, mais recisamente nas es eci+ica4es de classes, diagramas de classes, de estado, din;micos, de use$cases e es eci+icao. E(istiro algumas de+ici&ncias durante a +ase de codi+icao. A necessidade da criao de no'as o era4es e modi+ica4es em o era4es j e(istentes sero identi+icadas, signi+icando que o desen'ol'edor ter que mudar seus modelos da +ase de design. )sto ocorre em todos os rojetos. O que - mais im ortante - que sejam sincroni*ados a modelagem de design com a codi+icao, desta +orma os modelos odero ser usados como documentao +inal do sistema. 12.5. estes A a licao de'er ser testada. De'e$se 'eri+icar se o rograma su orta toda a +uncionalidade que l7e +oi es eci+icada na +ase de anlise de requisitos com o diagrama de use$cases. A a licao de'e ser tamb-m testada da +orma mais in+ormal colocando$se o sistema nas mos dos usurios.

43

-0. )oncluso O criao de uma linguagem ara a comunidade de desen'ol'edores em orientao a objetos era uma necessidade antiga. A #!2 realmente incor orou muitos recursos com do a linguagem uma e(tensibilidade muito grande. Os organi*ao da modelagem em 'is4es e a di'iso dos diagramas es eci+icando caracter:sticas estticas e din;micas do sistema tornou a #!2 +cil de ser utili*ada e +e* com que qualquer ti o de com ortamento ossa ser 'isuali*ado em diagramas. A modelagem 'isual orientada a objetos agora ossui um adro, e esse adro - e(tremamente sim les de ser escrito a mo, sendo robusto ara es eci+icar e descre'er a grande maioria das +un4es, relacionamentos e t-cnicas de desen'ol'imento orientado a objetos que 7oje so utili*ados. =o'as t-cnicas iro surgir e a #!2 tamb-m estar re arada j que tudo estar baseado nas id-ias elementares da orientao a objetos. %em dC'ida alguma a #!2 +acilitar Js grandes em resas de desen'ol'imento de so+t@are uma maior comunicao e a ro'eitamento dos modelos desen'ol'idos elos seus 'rios analistas en'ol'idos no rocesso de roduo de so+t@are j que a linguagem que ser utili*ada or todos ser a mesma, acabando assim com qualquer roblema de inter retao e mal$entendimento de modelos criados or outros desen'ol'edores. Os modelos criados 7oje odero ser +acilmente analisados or +uturas gera4es de desen'ol'edores acabando com a di'ersidade de ti os de nomenclaturas de modelos, o grande em ecil7o do desen'ol'imento de so+t@ares orientados a objetos. Os +abricantes de +erramentas CA%E agora su ortaro a #!2 em seus so+t@ares e a +ase de codi+icao ser cada 'e* mais substitu:da ela gerao de c/digo automtico desem en7ada elas +erramentas CA%E.

44