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
2
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
3
-. 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.
/. 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.
4
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
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
5
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.
6
Os objeti'os da #!2 soB
A modelagem de sistemas (no aenas 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 eseci+icao da sem;ntica da linguagem reresentada em meta$modelos
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.
7
%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.
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)
8
=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
=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.
9
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.
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
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.
11
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.
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
12
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.
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.
13
!.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.
#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.
14
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 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.
15
!.(. 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
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 >).
16
=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
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.
17
=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.
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
18
!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.
=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.
19
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.
: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
20
"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 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.
21
#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.
23
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 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
25
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 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.
26
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.
=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.
27
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.
,.). 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.
28
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.
,.!. 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.
29
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.
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
-=. 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.
31
)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 cada +ase do desen'ol'imento, suorte a desen'ol'imento interati'o e +cil integrao com
outras +erramentas.
--. ' 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.
-/. 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.
32
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
Dec7ar conta corrente
Abrir ouana
Dec7ar ouana
!o'imentar conta corrente
Alicar em r-$+i(ados
Consultar 7ist/rico de conta corrente ou ouana
33
Cadastrar Ag&ncia
E(cluir ou Editar Ag&ncia
34
Tendo em mos esta relao de ati'idades, j odemos modelar o diagrama de use$case do
sistema.
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.
35
Analisamos e ercebemos que e(istiro U classes no sistema e que se relacionaro segundo o
diagrama de classes a seguir.
36
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 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
37
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
#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.
38
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.
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.
39
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.
40
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.
-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.
41
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.
42