1.

Introduo
2. Desenvolvimento de Softwares orientado a objetos
3. UML A unificao dos mtodos para a criao de um novo padro
4. Uso da UML
5. ases do Desenvolvimento de um Sistema em UML
1. Anlise de Requisitos
2. Anlise
3. Design (Projeto)
4. Programao
5. Testes
6. A !otao da Lin"ua"em de Modela"em Unificada UML
7. #is$es
8. Modelos de %lementos
1. Classes
2. Objetos
3. Estados
4. Pacotes
5. Comonentes
6. Relacionamentos
7. !ecanismos "erais
9. 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 Comonente
9. Diagrama de E(ecuo
10. Um processo para utili&ar a UML
11. ' uturo da UML
12. 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. )mlementao
5. Testes
13. )oncluso
2
-. 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 tio de alicao que se deseje. Cada
simbologia e(istente ossui seus r/rios conceitos, gr+icos e terminologias, resultando numa
grande con+uso, esecialmente ara aqueles que querem utili*ar a orientao a objetos no s/
sabendo ara que lado aonta 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 roosta ela #!2 era o
tio de +ora que eles semre eseraram.
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 - aenas arender a simbologia e o seu signi+icado, mas tamb-m signi+ica arender 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 1ac<ages1 r/rios da linguagem a ser utili*ada, utili*ao do banco de dados bem
como as di'ersas eseci+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 aresentarmos como
essas entidades so criadas, simboli*adas, organi*adas e como sero utili*adas dentro de um
desen'ol'imento utili*ando a #!2.
3
/. Desenvolvimento de Softwares orientado a objetos
Os conceitos da orientao a objetos j '&m sido discutidos 7 muito temo, desde o lanamento
da >? linguagem orientada a objetos, a %)!#2A. 9rios 1aas1 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 eseci+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 oortunidade de criar e
imlementar comonentes totalmente reutili*'eis.
!odelos orientado a objetos so imlementados 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
comro'adas usada em inCmeros rojetos e ara construo de di+erentes tio 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
4
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 tio, ossa ser modelado corretamente, com consist&ncia, +cil de
se comunicar com outras alica4es, simles de ser atuali*ado e comreens:'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 rinciais metodologias que se tornaram oulares nos anos EFB
6ooc7 G O m-todo de "rad5 6ooc7 ara desen'ol'imento orientado a objetos est
dison:'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 comle(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 -
esecialmente 'oltado ara o teste dos modelos, baseado nas eseci+ica4es da anlise
de requisitos do sistema. O modelo total do sistema baseado no m-todo O!T - comosto
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 adatado ara a engen7aria de neg/cios, onde - usado ara
modelar e mel7orar os rocessos en'ol'idos no +uncionamento de emresas.
Cada um destes m-todos ossui sua r/ria notao (seus r/rios s:mbolos ara reresentar
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 suortam 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 disonibili*aram
inCmeras 'ers4es reliminares da #!2 ara a comunidade de desen'ol'edores e a resosta
incrementou muitas no'as id-ias que mel7oraram ainda mais a linguagem.
Os objeti'os da #!2 soB
A modelagem de sistemas (no aenas de so+t@are) usando os conceitos da orientao a
objetosI
5
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 eseci+icao da sem;ntica da linguagem reresentada em meta$modelos
6
1. Uso da UML
A #!2 - usada no desen'ol'imento dos mais di'ersos tios de sistemas. Ela abrange semre
qualquer caracter:stica de um sistema em um de seus diagramas e - tamb-m alicada em
di+erentes +ases do desen'ol'imento de um sistema, desde a eseci+icao da anlise de
requisitos at- a +inali*ao com a +ase de testes.
O objeti'o da #!2 - descre'er qualquer tio 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 reresentar sistemas mec;nicos sem nen7um so+t@are. Aqui esto
alguns tios 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 comle(os, que so
guardados em bancos de dados relacionais ou orientados a objetos.
%istemas T-cnicosB !anter e controlar equiamentos t-cnicos como de telecomunica4es,
equiamentos militares ou rocessos industriais. Eles de'em ossuir inter+aces eseciais
do equiamento 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 simles eas de 7ard@are integrados a
tele+ones celulares, carros, alarmes etc. Estes sistemas imlementam rogramao de
bai(o n:'el e requerem suorte 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 Oeracionais, bancos de dados, e a4es de usurios que e(ecutam a4es de
bai(o n:'el no 7ard@are, ao mesmo temo que disonibili*am inter+aces gen-ricas de uso
de outros so+t@ares.
%istemas de =eg/ciosB descre'e os objeti'os, eseci+ica4es (essoas, comutadores
etc.), as regras (leis, estrat-gias de neg/cios etc.), e o atual trabal7o desemen7ado nos
rocessos do neg/cio.
3 imortante erceber que a maioria dos sistemas no ossuem aenas uma destas
caracter:sticas acima relacionadas, mas 'rias delas ao mesmo temo. %istemas de in+orma4es
de 7oje, or e(emlo, odem ter tanto caracter:sticas distribu:das como real$time. E a #!2 suorta
modelagens de todos estes tios de sistemas.
7
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 catura 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 eseci+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 eserar do alicati'o,
con7ecendo toda sua +uncionalidade sem imortar como esta ser imlementada. A anlise de
requisitos tamb-m ode ser desen'ol'ida baseada em rocessos de neg/cios, e no aenas ara
sistemas de so+t@are.
5.2. Anlise
A +ase de anlise est reocuada 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 rincial 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 eseci+ica4es ara a +ase de rogramao do sistema.
5.4. Programao
8
=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). Deendendo da caacidade da linguagem usada, essa con'erso ode ser
uma tare+a +cil ou muito comlicada. =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 anteciadamente sobre modi+ica4es em seu conteCdo, seus
modelos no estaro mais demonstrando o real er+il do sistema. A rogramao - uma +ase
searada 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 gruos de classes e so geralmente testados elo
rogramador. Os testes de integrao so alicados j usando as classes e comonentes
integrados ara se con+irmar se as classes esto cooerando uma com as outras como
eseci+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 eseci+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.
9
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 tios de 'is4es, no'e tios
de diagramas e 'rios modelos de elementos que sero utili*ados na criao dos diagramas e
mecanismos gerais que todos em conjunto eseci+icam e e(emli+icam a de+inio do sistema,
tanto a de+inio no que di* reseito J +uncionalidade esttica e din;mica do desen'ol'imento de
um sistema.
Antes de abordarmos cada um destes comonentes searadamente, de+iniremos as artes que
com4em a #!2B
9is4esB As 9is4es mostram di+erentes asectos 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 asectos articulares do sistema,
dando en+oque a ;ngulos e n:'eis de abstra4es di+erentes e uma +igura comleta do
sistema oder ser constru:da. As 'is4es tamb-m odem ser'ir de ligao entre a
linguagem de modelagem e o m-todoHrocesso de desen'ol'imento escol7ido.
!odelos de ElementosB Os conceitos usados nos diagramas so modelos de elementos
que reresentam de+ini4es comuns da orientao a objetos como as classes, objetos,
mensagem, relacionamentos entre classes incluindo associa4es, deend&ncias e
7eranas.
!ecanismos "eraisB Os mecanismos gerais ro'-m comentrios sulementares,
in+orma4es, ou sem;ntica sobre os elementos que com4em os modelosI eles ro'-m
tamb-m mecanismos de e(tenso ara adatar ou estender a #!2 ara um
m-todoHrocesso, organi*ao ou usurio esec:+ico.
DiagramasB Os diagramas so os gr+icos que descre'em o conteCdo em uma 'iso. #!2
ossui no'e tio 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 comle(o no - uma tare+a +cil. O ideal seria que o sistema
inteiro udesse ser descrito em um Cnico gr+ico e que este reresentasse or comleto as reais
inten4es do sistema sem ambiguidades, sendo +acilmente interret'el. )n+eli*mente, isso -
imoss:'el. #m Cnico gr+ico - incaa* de caturar todas as in+orma4es necessrias ara
descre'er um sistema.
#m sistema - comosto or di'ersos asectosB +uncional (que - sua estrutura esttica e suas
intera4es din;micas), no +uncional (requisitos de temo, con+iabilidade, desen'ol'imento, etc.) e
asectos organi*acionais (organi*ao do trabal7o, maeamento dos m/dulos de c/digo, etc.).
Ento o sistema - descrito em um certo nCmero de 'is4es, cada uma reresentando uma rojeo
da descrio comleta e mostrando asectos articulares do sistema.
Cada 'iso - descrita or um nCmero de diagramas que cont-m in+orma4es que do &n+ase aos
asectos articulares do sistema. E(iste em alguns casos uma certa sobreosio entre os
diagramas o que signi+ica que um deste ode +a*er arte de mais de uma 'iso. Os diagramas que
com4em as 'is4es cont-m os modelos de elementos do sistema. As 'is4es que com4em um
sistema soB
9iso 1use$case1B Descre'e a +uncionalidade do sistema desemen7ada 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 imlementada. 3 +eita
rincialmente 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 eseci+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. Proriedades 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 ComonentesB 3 uma descrio da imlementao dos m/dulos e suas
deend&ncias. 3 rincialmente e(ecutado or desen'ol'edores, e consiste nos
comonentes dos diagramas.
9iso de concorr&nciaB Trata a di'iso do sistema em rocessos e rocessadores. Este
asecto, que - uma roriedade 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 - suortada elos diagramas din;micos, que so os diagramas de
estado, sequencia, colaborao e ati'idade, e elos diagramas de imlementao, que so
os diagramas de comonente e e(ecuo.
9iso de Organi*aoB Dinalmente, a 'iso de organi*ao mostra a organi*ao +:sica do
sistema, os comutadores, os eri+-ricos e como eles se conectam entre si. Esta 'iso
ser e(ecutada elos desen'ol'edores, integradores e testadores, e ser reresentada
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 reresenta sem de+ini4es du'idosas ou amb:guas e tamb-m de+ine sua reresentao
gr+ica que - mostrada nos diagramas da #!2. #m elemento ode e(istir em di'ersos tios de
diagramas, mas e(istem regras que de+inem que elementos odem ser mostrados em que tios de
diagramas. Alguns e(emlos de modelos de elementos so as classes, objetos, estados, acotes e
comonentes. 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(emli+icados a seguir.
!.1. "lasses
#ma classe - a descrio de um tio de objeto. Todos os objetos so inst;ncias de classes, onde a
classe descre'e as roriedades e comortamentos 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(emlo 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 tio 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(emlo, e(istem classes que reresentam entidades de so+t@are num sistema oeracional como
arqui'os, rogramas e(ecut'eis, janelas, barras de rolagem, etc.
)denti+icar as classes de um sistema ode ser comlicado, 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 reresentam 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, comonentes ou modelos e(ternos a serem utili*ados elo
sistema modeladoK %e sim, normalmente essas classes, comonentes e modelos contero
classes candidatas ao nosso sistema.
0ual o ael dos atores dentro do sistemaK Tal'e* o ael deles ossa ser 'isto como
classes, or e(emlo, usurio, oerador, cliente e da: or diante.
13
Em #!2 as classes so reresentadas or um ret;ngulo di'idido em tr&s comartimentosB o
comartimento de nome, que conter aenas o nome da classe modelada, o de atributos, que
ossuir a relao de atributos que a classe ossui em sua estrutura interna, e o comartimento de
oera4es, que sero o m-todos de maniulao de dados e de comunicao de uma classe com
outras do sistema. A sinta(e usada em cada um destes comartimentos - indeendente 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 maniular, acoman7ar seu comortamento, criar, destruir
etc. #m objeto e(iste no mundo real. Pode ser uma arte de qualquer tio de sistema, or
e(emlo, 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 comortamento 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 ocionalmente 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 tios de objetos de um
sistema, odemos re'er todos os oss:'eis comortamentos 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 comartimentos. O rimeiro mostra o nome do
estado. O segundo - ocional 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 reresentao
da classe, e em algumas 'e*es, odem ser mostradas tamb-m as 'ari'eis temorrias, 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 comartimento -
ocional e - c7amado de comartimento de ati'idade, onde e'entos e a4es odem ser listadas.
Tr&s e'entos adr4es odem ser mostrados no comartimento 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 agruamento, onde todos os modelos de elementos odem ser
agruados. Em #!2, um acote - de+inido comoB 1#m mecanismo de ro/sito geral ara
organi*ar elementos semanticamente relacionados em gruos.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 imortar modelos de elementos de outros acotes. 0uando um modelo de
elemento - imortado, re+ere$se aenas 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
deend&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 comosto de modelos de elementos cria uma agregao de
comosio. %e este +or destru:do, todo o seu conteCdo tamb-m ser.
!.5. "om'onentes
#m comonente ode ser tanto um c/digo em linguagem de rogramao como um c/digo
e(ecut'el j comilado. Por e(emlo, em um sistema desen'ol'ido em 8a'a, cada arqui'o .java
ou .class - um comonente do sistema, e ser mostrado no diagrama de comonentes 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 tiosB
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
dulas de objetos ligados.
"enerali*aoB 3 um relacionamento de um elemento mais geral e outro mais esec:+ico.
O elemento mais esec:+ico ode conter aenas in+orma4es adicionais. #ma inst;ncia
(um objeto - uma inst;ncia de uma classe) do elemento mais esec:+ico ode ser usada
onde o elemento mais geral seja ermitido.
Deend&ncia e Re+inamentosB Deend&ncia - um relacionamento entre elementos, um
indeendente e outro deendente. #ma modi+icao - um elemento indeendente a+etar
diretamente elementos deendentes do anterior. Re+inamento - um relacionamento entre
duas descri4es de uma mesma entidade, mas em n:'eis di+erentes de abstrao.
Abordaremos agora cada tio de relacionamento e suas resecti'as sub$di'is4esB
16
5.3.- Associa$es
#ma associao reresenta que duas classes ossuem uma ligao (lin<) entre elas, signi+icando
or e(emlo que elas 1con7ecem uma a outra1, 1esto conectadas com1, 1ara cada M e(iste um
A1 e assim or diante. Classes e associa4es so muito oderosas quando modeladas em
sistemas comle(os.
Associa$es !ormais
O tio mais comum de associao - aenas uma cone(o entre classes. 3 reresentada or uma
lin7a s/lida entre duas classes. A associao ossui um nome (junto J lin7a que reresenta 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 aonta. !as associa4es tamb-m odem ossuir dois nomes, signi+icando
um nome ara cada sentido da associao.
Para e(ressar a multilicidade 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
aenas 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
multilicidade, ento - considerado o adro de um ara um (>..> ou aenas >).
=o e(emlo 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 reresenta
semanticamente a cone(o entre dois objetos, mas os objetos conectados so da mesma classe.
#ma associao deste tio - 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) eseci+ica como um
determinado objeto no +inal da associao 1n1 - identi+icado, e ode ser 'isto como um tio de
17
c7a'e ara searar 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
eseci+ica que objetos de uma classe odem articiar de no m(imo uma das associa4es em um
dado momento. #ma associao e(clusi'a - reresentada or uma lin7a tracejada entre as
associa4es que so arte da associao e(clusi'a, com a eseci+icao 1SouT1 sobre a lin7a
tracejada.
=o diagrama acima um contrato no ode se re+erir a uma essoa e a uma emresa ao mesmo
temo, signi+icando que o relacionamento - e(clusi'o a somente uma das duas classes.
Associao 'rdenada
As associa4es entre objetos odem ter uma ordem iml:cita. O adro ara uma associao -
desordenada (ou sem nen7uma ordem esec:+ica). !as uma ordem ode ser eseci+icada atra'-s
da associao ordenada. Este tio de associao ode ser muito Ctil em casos como esteB janelas
de um sistema t&m que ser ordenadas na tela (uma est no too, uma est no +undo e assim or
diante). A associao ordenada ode ser escrita aenas colocando 1SordenadaT1 junto a lin7a de
associao entre as duas classes.
Associao de )lasse
#ma classe ode ser associada a uma outra associao. Este tio 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 oera4es de adicionar rocessos na +ila, ara ler e remo'er da +ila e de ler o seu taman7o.
%e oera4es 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 suorta 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(emlo acima a associao ternria eseci+ica que um cliente oder ossuir > ou mais
contratos e cada contrato ser comosto 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 tios eseciais de agregao que so as agrega4es comartil7adas e as comostas.
Agregao Comartil7adaB 3 dita comartil7ada 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(emlo acima uma essoa ode ser membro de um time ou 'rios times e em
determinado momento.
Agregao de ComosioB 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 comosio 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 esec:+ico. O
elemento mais esec:+ico ossui todas as caracter:sticas do elemento geral e cont-m ainda mais
articularidades. #m objeto mais esec:+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
eseciali*ados em outros.
E(istem alguns tios 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
sobreosio, disjunti'a, comleta e incomleta.
:enerali&ao !ormal
=a generali*ao normal a classe mais esec:+ica, c7amada de subclasse, 7erda tudo da classe
mais geral, c7amada de suerclasse. Os atributos, oera4es e todas as associa4es so
7erdadas.
#ma classe ode ser tanto uma subclasse quanto uma suerclasse, 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 - reresentada 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 suerclasse
indicando a generali*ao.
20
:enerali&ao 6estrita
#ma restrio alicada a uma generali*ao eseci+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 %obreosio e Disjunti'aB "enerali*ao de sobreosio signi+ica
que quando subclasses 7erdam de uma suerclasse or sobreosio, no'as subclasses
destas odem 7erdar de mais de uma subclasse. A generali*ao disjunti'a - e(atamente
o contrrio da sobreosio e a generali*ao - utili*ada como adro.
"enerali*a4es Comleta e )ncomletaB #ma restrio simboli*ando que uma
generali*ao - comleta signi+ica que todas as subclasses j +oram eseci+icadas, e no
e(iste mais ossibilidade de outra generali*ao a artir daquele onto. A generali*ao
incomleta - e(atamente o contrrio da comleta e - assumida como adro da
linguagem.
5.3.0. Depend;ncia e 6efinamentos
Al-m das associa4es e generali*a4es, e(istem ainda dois tios de relacionamentos em #!2. O
relacionamento de deend&ncia - uma cone(o sem;ntica entre dois modelos de elementos, um
21
indeendente e outro deendente. #ma mudana no elemento indeendente ir a+etar o modelo
deendente. 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
deend&ncia entre estas duas classes, aesar de no ser e(l:cita.
#ma relao de deend&ncia - simboli*ada or uma lin7a tracejada com uma seta no +inal de um
dos lados do relacionamento. E sobre essa lin7a o tio de deend&ncia que e(iste entre as duas
classes. As classes 1Amigas1 ro'enientes do CLL so um e(emlo de um relacionamento de
deend&ncia.
Os re+inamentos so um tio 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 imlementa4es de
uma mesma coisa (uma imlementao simles e outra mais comle(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(emlo de um ornamento - o da
t-cnica de searar um tio de uma inst;ncia. 0uando um elemento reresenta um tio, seu
nome - mostrado em negrito. 0uando o mesmo elemento reresenta a inst;ncia de um
tio, seu nome - escrito sublin7ado e ode signi+icar tanto o nome da inst;ncia quanto o
nome do tio. Outros ornamentos so os de eseci+icao de multilicidade de
relacionamentos, onde a multilicidade - um nCmero ou um inter'alo que indica quantas
inst;ncias de um tio conectado ode estar en'ol'ido na relao.
=otasB =em tudo ode ser de+inido em uma linguagem de modelagem, sem imortar o
quanto e(tensa ela seja. Para ermitir adicionar in+orma4es a um modelo no oderia ser
reresentado de outra +orma, #!2 ro'& a caacidade de adicionar =otas. #ma =ota ode
ser colocada em qualquer lugar em um diagrama, e ode conter qualquer tio de
in+ormao.
22
<. Dia"ramas
Os diagramas utili*ados ela #!2 so comostos de no'e tiosB diagrama de use case, de
classes, de objeto, de estado, de sequ&ncia, de colaborao, de ati'idade, de comonente e o de
e(ecuo.
Todos os sistemas ossuem uma estrutura esttica e um comortamento din;mico. A #!2 suorta
modelos estticos (estrutura esttica), din;micos (comortamento din;mico) e +uncional. A
!odelagem esttica - suortada elo diagrama de classes e de objetos, que consiste nas classes
e seus relacionamentos. Os relacionamentos odem ser de associa4es, 7erana (generali*ao),
deend&ncia ou re+inamentos. Os modelamentos din;micos so suortados elos diagramas de
estado, sequ&ncia, colaborao e ati'idade. E o modelamento +uncional - suortado elos
diagramas de comonente e e(ecuo. Abordaremos agora cada um destes tios 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 reresentam o ael 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 reresenta uma sequ&ncia
de a4es e(ecutadas elo sistema e recebe do ator que l7e utili*a dados tang:'eis de um tio ou
+ormato j con7ecido, e o 'alor de resosta da e(ecuo de um use$case (conteCdo) tamb-m j -
de um tio 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 comortamento comum de 7erana em suerclasses eseciali*adas em
subclasses.
O uso de use$cases em colabora4es - muito imortante, onde estas so a descrio de um
conte(to mostrando classesHobjetos, seus relacionamentos e sua interao e(emli+icando como
as classesHobjetos interagem ara e(ecutar uma ati'idade esec:+ica no sistema. #ma colaborao
- descrita or diagramas de ati'idades e um diagrama de colaborao.
0uando um use$case - imlementado, a resonsabilidade de cada asso da e(ecuo de'e ser
associada Js classes que articiam da colaborao, tiicamente eseci+icando as oera4es
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 esec:+ico
de cada ao. Por isso, o cenrio - um imortante e(emlo de um use$case ou de uma
colaborao. 0uando 'isto a n:'el de um use$case, aenas 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 imlementam o sistema sero descritos e eseci+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 eseci+ica que +un4es o administrador do banco oder desemen7ar. Pode$se
erceber que no e(iste nen7uma reocuao com a imlementao de cada uma destas
+un4es, j que este diagrama aenas se resume a determinar que +un4es de'ero ser
suortadas elo sistema modelado.
,.2 Diagrama de "lasses
O diagrama de classes demonstra a estrutura esttica das classes de um sistema onde estas
reresentam as 1coisas1 que so gerenciadas ela alicao modelada. Classes odem se
relacionar com outras atra'-s de di'ersas maneirasB associao (conectadas entre si),
deend&ncia (uma classe deende ou usa outra classe), eseciali*ao (uma classe - uma
eseciali*ao de outra classe), ou em acotes (classes agruadas or caracter:sticas similares).
Todos estes relacionamentos so mostrados no diagrama de classes juntamente com as suas
estruturas internas, que so os atributos e oera4es. O diagrama de classes - considerado
esttico j que a estrutura descrita - semre '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 articiar de 'rios
diagramas de classes.
24
#ma classe num diagrama ode ser diretamente imlementada utili*ando$se uma linguagem de
rogramao orientada a objetos que ten7a suorte 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 imortantes como os diagramas de classes, mas eles so muito Cteis ara
e(emli+icar diagramas comle(os de classes ajudando muito em sua comreenso. 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 - tiicamente um comlemento 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 aenas ara aquelas que
ossuem um nCmero de+inido de estados con7ecidos e onde o comortamento das classes -
a+etado e modi+icado elos di+erentes estados.
Diagramas de estado caturam 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 temo.
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 disarada.
#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 disarada 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 imortante asecto 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 esec:+ico da e(ecuo do sistema. O diagrama de sequ&ncia consiste
em um nCmero de objetos mostrado em lin7as 'erticais. O decorrer do temo - '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 temo 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 esec:+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 - reresentado 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(emlo
citamosB mensagens recebidas ou en'iadas e ati'ao de objetos. A comunicao entre os objetos
- reresentada como lin7a com setas 7ori*ontais simboli*ando as mensagens entre as lin7as de
'ida dos objetos. A seta eseci+ica se a mensagem - s:ncrona, ass:ncrona ou simles. 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, reresentada 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 temo, - 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 resosta, 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 caturam a4es e seus resultados. Eles +ocam o trabal7o e(ecutado na
imlementao de uma oerao (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 caturar 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 eseci+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 agrua ati'idades, com reseito a quem - resons'el e onde estas
ati'idades residem na organi*ao, e - reresentada 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 caturar os trabal7os que sero e(ecutados quando uma oerao - disarada
(a4es). Este - o uso mais comum ara o diagrama de ati'idade.
Para caturar o trabal7o interno em um objeto.
Para mostrar como um gruo 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 oerao esec:+ica do sistema. Consistem em
estados de ao, que cont-m a eseci+icao de uma ati'idade a ser desemen7ada or uma
oerao 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 eseci+ica4es de
mensagens en'iadas e recebidas como artes de a4es e(ecutadas.
28
,.!. Diagrama de "om'onente
O diagrama de comonente e o de e(ecuo so diagramas que mostram o sistema or um lado
+uncional, e(ondo as rela4es entre seus comonentes e a organi*ao de seus m/dulos durante
sua e(ecuo.
O diagrama de comonente descre'e os comonentes de so+t@are e suas deend&ncias entre si,
reresentando a estrutura do c/digo gerado. Os comonentes so a imlementao na arquitetura
+:sica dos conceitos e da +uncionalidade de+inidos na arquitetura l/gica (classes, objetos e seus
relacionamentos). Eles so tiicamente os arqui'os imlementados no ambiente de
desen'ol'imento.
#m comonente - mostrado em #!2 como um ret;ngulo com uma elise e dois ret;ngulos
menores do seu lado esquerdo. O nome do comonente - escrito abai(o ou dentro de seu s:mbolo.
Comonentes so tios, mas aenas comonentes e(ecut'eis odem ter inst;ncias. #m
diagrama de comonente mostra aenas comonentes como tios. Para mostrar inst;ncias de
comonentes, de'e ser usado um diagrama de e(ecuo, onde as inst;ncias e(ecut'eis so
alocadas em nodes.
A deend&ncia entre comonentes ode ser mostrada como uma lin7a tracejada com uma seta,
simboli*ando que um comonente recisa do outro ara ossuir uma de+inio comleta. Com o
diagrama de comonentes - +acilmente 'is:'el detectar que arqui'os .dll so necessrios ara
e(ecutar a alicao.
29
Comonentes odem de+inir inter+aces que so 'is:'eis ara outros comonentes. 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
comonente e com um c:rculo na outra e(tremidade. O nome - colocado junto do c:rculo no +inal
da lin7a. Deend&ncias entre comonentes odem ento aontar ara a inter+ace do comonente
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 comutadores e eri+-ricos, juntamente com as cone(4es que eles estabelecem
entre si e ode mostrar tamb-m os tios de cone(4es entre esses comutadores e eri+-ricos.
Eseci+ica$se tamb-m os comonentes e(ecut'eis e objetos que so alocados ara mostrar quais
unidades de so+t@are so e(ecutados e em que destes comutadores so e(ecutados.
O diagrama de e(ecuo demonstra a arquitetura run$time de rocessadores, comonentes +: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 toologia do sistema, descre'endo a estrutura de 7ard@are e so+t@are
que e(ecutam em cada unidade.
O diagrama de e(ecuo - comosto or comonentes, que ossuem a mesma simbologia dos
comonentes do diagrama de comonentes, nodes, que signi+icam objetos +:sicos que +a*em arte
do sistema, odendo ser uma mquina cliente numa 2A=, uma mquina ser'idora, uma
imressora, um roteador, etc., e cone(4es entre estes nodes e comonentes que juntos com4em
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 tio de m-todo de desen'ol'imento,
esecialmente 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 1orque
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
esec:+ico - alcanado.
Em seu uso normal, a ala'ra 1rocesso1 signi+ica uma relao de ati'idades que de'em ser
e(ecutadas em uma certa ordem sem imortar 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), imlementao, e testes. A anlise de requisitos catura as
necessidades bsicas +uncionais e no$+uncionais do sistema que de'e ser desen'ol'ido. A anlise
modela o roblema rincial (classes, objetos) e cria um modelo ideal do sistema sem le'ar em
conta requisitos t-cnicos do sistema. O design e(ande e adata os modelos da anlise ara um
ambiente t-cnico, onde as solu4es t-cnicas so trabal7adas em detal7es. A imlementao
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
corresonde as e(ectati'as do usurio.
E(iste um rocesso desen'ol'ido ela Rational )nc., mesma emresa 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 imlementao, enquanto a 'iso gerencial
utili*a as seguintes +ases no desen'ol'imento de cada gerao do sistema.
)n:cioB De+ine o escoo 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,
suorte, documentao e treinamento.
Cada +ase no ciclo - e(ecutada em s-ries de intera4es que odem sobreor outras +ases. Cada
interao consiste tiicamente em ati'idades tradicionais como anlise e design, mas em
di+erentes roor4es deendendo da +ase em que esteja a gerao do sistema em
desen'ol'imento.
Derramentas modernas de'em dar suorte no aenas ara linguagens de modelagem e
rogramao, mas de'em suortar 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, suorte 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
aer+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
imlementao baseados em #!2 estaro dison:'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 aresentado no decorrer do trabal7o, alicaremos aqui grande arte dos conceitos
abordados diante de uma alicao 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
rinciais 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 alica4es +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 ro4e a +a*er e outras obser'a4es que consideramos de suma imort;ncia ara o
bom entendimento do roblema.
O sistema suortar um cadastro de clientes, onde cada cliente cadastrado oder ter
'rias contas correntes, 'rios deendentes ligados a ele, e 'rias contas de ouana.
Cada deendente oder ossuir 'rias contas de ouana, mas no odero ter uma
conta corrente r/ria.
Entendemos ouana como uma conta que ossui um 'alor, um ra*o de alicao a
uma ta(a de juros (de+inida no 'encimento da ouana).
Entendemos Alica4es Pr-$+i(adas como uma alicao 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 ouana de'ero manter um 7ist/rico de todas as
mo'imenta4es de cr-dito, d-bito, trans+er&ncias e alica4es de r-$+i(ados (r-$+i(ados
aenas ara conta corrente).
#ma conta corrente oder ter 'rias alica4es r-$+i(adas ligadas a ela.
12.1. Anlise de Requisitos
De acordo com nossa roosta o sistema imlementar +un4es bsicas que sero
desemen7adas ela Administrao do banco e elos seus clientes. As rinciais +un4es do
sistema soB
Cadastrar no'o cliente
E(cluir ou editar cliente
Cadastrar deendente
E(cluir ou editar deendente
Abrir conta corrente
35
Dec7ar conta corrente
Abrir ouana
Dec7ar ouana
!o'imentar conta corrente
Alicar em r-$+i(ados
Consultar 7ist/rico de conta corrente ou ouana
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
desreocuado de qualquer tio de t-cnica relacionada a imlementao do sistema, ou seja,
m-todos e atributos de acesso a banco de dados, estrutura de mensagens entre objetos, etc. no
de'ero aarecer nesse rimeiro diagrama, aenas os tios 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 tio de
t-cnica de imlementao 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 comortamento dos objetos - imortante ara alicao. Em casos de
modelagens de sistemas ara equiamentos mec;nicos.
12.3. Design
=esta +ase comearemos a imlementar 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 deend&ncias e mecanismos de comunicao entre eles.
=aturalmente, o objeti'o - criar uma arquitetura simles e clara, onde as deend&ncias
sejam oucas e que ossam ser bidirecionais semre que oss:'el.
Design detal7adoB Esta arte detal7a o conteCdo dos acotes, ento todas classes sero
totalmente descritas ara mostrar eseci+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 comortam 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 resons'eis or +un4es l/gicas ou t-cnicas do sistema. 3 de 'ital imort;ncia
searar a l/gica da alicao 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 cooera com o acote de objetos do sistema, que cont-m as
classes onde os dados esto guardados. O acote de inter+ace c7ama oera4es 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 oera4es e m-todos em sua
estrutura e o suorte 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 disonibili*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 suortados elos diagramas gerados na +ase de design, e diagramas de sequencia
so usados ara ilustrar como cada use$case - tecnicamente imlementada 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 suortam a adio de controladores de e'entos ara e'entos disarados
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 alicao resultante da inter+ace de usurio - uma janela rincial com um menu de o4es.
Cada oo escol7ida do menu mostrar uma janela no'a que juntas sero resons'eis or
receber as in+orma4es do usurio e e(ecutar a +uno a qual se ro4em a +a*er.
12.4. 3m'lementao
A +ase de construo ou imlementao - quando as classes so codi+icadas. Os requisitos
eseci+icam que o sistema de'e ser caa* de rodar em di'ersos tio de rocessadores e sistemas
oeracionais, 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 comonentes contendo um maeamento 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 eseci+ica4es de classes,
diagramas de classes, de estado, din;micos, de use$cases e eseci+icao.
E(istiro algumas de+ici&ncias durante a +ase de codi+icao. A necessidade da criao de no'as
oera4es e modi+ica4es em oera4es 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 imortante - 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 alicao de'er ser testada. De'e$se 'eri+icar se o rograma suorta toda a +uncionalidade que
l7e +oi eseci+icada na +ase de anlise de requisitos com o diagrama de use$cases. A alicao
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 incororou muitos recursos com do a linguagem uma
e(tensibilidade muito grande.
Os organi*ao da modelagem em 'is4es e a di'iso dos diagramas eseci+icando caracter:sticas
estticas e din;micas do sistema tornou a #!2 +cil de ser utili*ada e +e* com que qualquer tio de
comortamento ossa ser 'isuali*ado em diagramas.
A modelagem 'isual orientada a objetos agora ossui um adro, e esse adro - e(tremamente
simles de ser escrito a mo, sendo robusto ara eseci+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 rearada j que tudo estar
baseado nas id-ias elementares da orientao a objetos.
%em dC'ida alguma a #!2 +acilitar Js grandes emresas de desen'ol'imento de so+t@are uma
maior comunicao e aro'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 interretao 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 tios de
nomenclaturas de modelos, o grande emecil7o do desen'ol'imento de so+t@ares orientados a
objetos.
Os +abricantes de +erramentas CA%E agora suortaro 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 desemen7ada
elas +erramentas CA%E.
44