Você está na página 1de 578

Alberto Manuel Rodrigues da Silva

Carlos Alberto Escaleira Videira


UML, Metodologias e
Ferramentas CASE
Linguagem de Modelao UML, Metodologias e Ferramentas CASE
na Concepo e Desenvolvimento de Software



Edies Centro Atlntico
Portugal/2001


Reservados todos os direitos por Centro Atlntico, Lda.
Qualquer reproduo, incluindo fotocpia, s pode ser feita
com autorizao expressa dos editores da obra.


UML, Metodologias e Ferramentas CASE
Coleco: Tecnologias
Autores: Alberto Manuel Rodrigues da Silva
Carlos Alberto Escaleira Videira
Direco grfica: Centro Atlntico
Capa: Paulo Buchinho



Centro Atlntico, Lda., 2001
Ap. 413 - 4760 V. N. Famalico
Porto - Lisboa
Portugal
Tel. 808 20 22 21

geral@centroatlantico.pt
www.centroatlantico.pt


Fotolitos: Centro Atlntico
Impresso e acabamento: Inova
1 edio: Abril de 2001

ISBN: 972-8426-36-4
Depsito legal: 164.544/01












Marcas registadas: todos os termos mencionados neste livro conhecidos como sendo marcas
registadas de produtos e servios, foram apropriadamente capitalizados. A utilizao de um termo
neste livro no deve ser encarada como afectando a validade de alguma marca registada de produto
ou servio.
O Editor e os Autores no se responsabilizam por possveis danos morais ou fsicos causados pelas
instrues contidas no livro nem por endereos Internet que no correspondam s Home-Pages
pretendidas.




Graa, Joana e Joo Alberto
Alberto Silva


Elsa, Sofia e Guilherme
Carlos Videira


I I CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE



Pea, gratuitamente, os ficheiros com as Pea, gratuitamente, os ficheiros com as
solues dos exerccios mpares deste livro solues dos exerccios mpares deste livro




Receba gratuitamente, por e-mail, os ficheiros com as solues dos
exerccios mpares deste livro, para poder comparar com as suas
respostas. Para tal, envie a cpia da factura deste livro para o Centro
Atlntico, para o e-mail,

geral@centroatlantico.pt

ou por correio para,

Centro Atlntico
Ap. 413
4760 V. N. Famalico
I I I


Prefcio
Objectivos, Contexto e Motivao
O livro UML, Metodologias e Ferramentas CASE aborda tpicos
importantes para a generalidade dos intervenientes nas actividades
enquadradas na engenharia de software, designadamente as problem-
ticas (1) das linguagens de modelao de software, (2) do processo e
das metodologias de desenvolvimento de software, e (3) das ferramen-
tas CASE de suporte modelao e ao prprio desenvolvimento.
Pretende dar uma panormica abrangente sobre estes trs aspectos de
forma integrada e coerente. Embora o foco do livro seja nas fases de
concepo de sistemas de software, discute o seu enquadramento de
modo mais lato em reas como o planeamento estratgico de sistemas
de informao; as arquitecturas de sistemas de informao; ou mesmo
a engenharia de software.
O livro explica a necessidade da modelao no desenvolvimento de
software, o que o UML (Unified Modeling Language), como aplicar o
UML no contexto mais abrangente das metodologias e processos de
desenvolvimento, e como usar ferramentas CASE de forma a maximizar
e automatizar algumas das tarefas relacionadas com a modelao, por
exemplo, produo e gesto de documentao, gerao de cdigo,
gerao de esquemas de dados, reverse engineering, round-trip engine-
ering, mecanismos de extenso, etc.
A aprendizagem e adopo dos temas abordados neste livro constituem
uma vantagem decisiva para os intervenientes que os adoptarem con-
sistentemente. Entre outros, salientamos os seguintes benefcios: me-
lhor documentao dos sistemas e dos respectivos artefactos; aplicao
de tcnicas de modelao orientadas por objectos, mais fceis de en-
tender; reutilizao desde as fases preliminares da concepo at im-
plementao; rastreabilidade dos requisitos ao longo de todo o proces-
so; facilidade de comunicao entre todos os intervenientes envolvidos
I V CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

no processo; melhorias significativas em factores como sejam flexibilida-
de e produtividade; melhor gesto de requisitos; avaliao e manuten-
o de sistemas mais facilitadas. Estas caractersticas so naturalmente
interdependentes entre si; por exemplo, uma maior qualidade da docu-
mentao produzida possibilita uma melhor comunicao entre os inter-
venientes de um projecto, ou uma melhor manuteno entre eles.
Todavia, os assuntos tratados neste livro so difceis de adoptar nas
organizaes, por inmeras razes. Antes de mais porque o ritmo de
inovao tecnolgica nesta rea da engenharia tem-se processado a
um ritmo particularmente intenso.
A segunda razo deve-se ao facto dos tpicos abordados neste livro
exigirem uma formao significativa e principalmente uma adequada e
correspondente actuao. No basta dominar um conjunto alargado de
conceitos e notaes para especificar software, mas fundamental
aprender a aplic-los de forma consistente, repetida e sistemtica;
adapt-los s condicionantes e realidades de cada empresa, ou de cada
projecto em particular; e ainda partilhar tcnicas e mtodos entre todos
os indivduos da empresa, ou de cada projecto, para que a comunica-
o entre todos os intervenientes seja maximizada e eficiente.
A terceira razo, consequncia das razes anteriormente referidas, o
facto de ser oneroso a adopo efectiva e produtiva (dos tpicos abor-
dados neste livro) no seio das empresas. Oneroso em termos do tempo
inicial que necessrio despender em formao, em termos da resis-
tncia mudana, assim como o investimento necessrio na seleco
e aquisio de ferramentas CASE que potenciem significativamente as
suas vantagens.
Este livro surge na sequncia da experincia dos autores em activida-
des de investigao, mas principalmente em actividades de consultoria
e de docncia nas reas de engenharia de software e de sistemas de
informao.
Os temas abordados neste livro so na sua maioria influenciados pelo
trabalho de unificao e de evangelizao dos trs amigos: Grady
Booch, Ivar Jacobson e James Rumbaugh. Todavia, da nossa exclusi-
va responsabilidade o estilo do livro, assim como a sua estrutura, conte-
do, exemplos e exerccios propostos (tal como as correspondentes
V


gralhas e omisses decorrentes!). O livro condensa e integra informa-
o dispersa por alguns livros da rea, em particular os seguintes
ttulos: OMG Unified Modeling Language Specification [OMG99], The
Unified Modeling Language User Guide [Booch99], The Unified Software
Development Process [Jacobson99], Visual Modeling with Rational
Rose 2000 and UML [Quatrani00] e The Rational Unified Process [Kru-
chten00]. No entanto, h inmeros aspectos que o livro prope e discute
de forma nica, dificilmente encontrados em qualquer dos livros referi-
dos.
A nvel internacional, existe um nmero relevante de ttulos nesta rea;
contudo, h reconhecidamente na lngua Portuguesa uma lacuna muito
significativa. Paralelamente, e em consequncia da nossa experincia e
responsabilidade de docncia, superviso e coordenao de trabalhos
finais de curso e de investigao identificmos a necessidade e oportu-
nidade de produzirmos este livro com vista a apoiar a aprendizagem da
engenharia de software nos tpicos referidos.
A temtica tratada neste livro abrangente e a sua profundidade ,
propositadamente, de nvel intermdio. numeros assuntos podero ser
analisados e aprofundados complementarmente, entre os quais se des-
tacam a ttulo de exemplo os seguintes: arquitecturas de sistemas de
software [Hofmeister99]; processos de negcio em contextos organiza-
cionais [Penker00]; padres de anlise [Fowler96]; padres de desenho
em infra-estruturas de software (frameworks) [Souza99]; modelao de
dados [Muller00]; modelao de aplicaes segundo o paradigma dos
agentes de software [Odell00], modelao de aplicaes de tempo real
[Selic94], ou modelao de aplicaes interactivas [Nunes99]. Todos
estes tpicos so importantes nos seus respectivos contextos de aplica-
o; muitos so alvo de intensa actividade de estudo e investigao. To-
dos eles apresentam, contudo, um denominador comum: baseiam-se no
conhecimento introduzido, apresentado e discutido neste livro.
VI CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Audincia do Livro
O livro pretende servir como referncia de suporte a um nmero restrito
de disciplinas de nvel de ensino superior na rea de sistemas de infor-
mao. Consequentemente, o livro adopta um estilo tendencialmente
pedaggico atravs da apresentao e discusso de exemplos, da nar-
rativa de histrias e factos reais, ou pela proposta de exerccios acad-
micos.
O primeiro perfil de leitores deste livro vai directamente para os alunos
de licenciatura e de cursos de ps-graduao em engenharia inform-
tica ou em informtica de gesto. Pressupe-se que os leitores j as-
bem implementar aplicaes informticas; e que neste livro procuram
aprender a reflectir sobre o processo de desenvolvimento de software, e
aprender tcnicas e prticas consistentes e sistemticas para o realizar.
Adicionalmente, este livro relevante para um nmero mais alargado de
leitores, em particular para investigadores, gestores informticos,
responsveis pelo processo de desenvolvimento de software, analistas-
programadores, e outros que necessitem de especificar de forma mais
ou menos detalhada sistemas de software.
O livro pressupe um conjunto de pr-requisitos que o leitor dever
possuir para o poder usufruir devidamente. suposto o leitor possuir
um conhecimento razovel sobre as bases da informtica e dos siste-
mas de computadores, tais como noes essenciais de programao,
de bases de dados e de sistemas operativos.

Organizao do Livro
O livro encontra-se organizado em 4 partes, 14 captulos e 2 apndices
conforme se resume de seguida.
A Parte 1 (INTRODUO E VISO GERAL) apresenta os conceitos gerais,
viso histrica e enquadramento da realizao deste livro. Inclui os
captulos 1, 2 e 3.
A Parte 2 (LINGUAGEM DE MODELAO UML) constituda por 6
captulos complementares, sendo que o Captulo 4 d a viso histrica
e geral do UML e o Captulo 9 descreve sucintamente alguns aspectos
VI I


considerados avanados, no essenciais para o leitor que apenas
pretende usar e aplicar as caractersticas bsicas do UML. Os restantes
captulos (Captulos 5, 6, 7 e 8) constituem o centro desta parte do livro
e devero ser lidos de forma sequencial conforme proposto.
A Parte 3 (METODOLOGIAS DE DESENVOLVIMENTO DE SOFTWARE) apre-
senta a problemtica geral das metodologias e processos de desen-
volvimento de software, com exemplos concretos baseados em duas
propostas reais de metodologias, o RUP e o ICONIX, descritos respec-
tivamente nos Captulos 10 a 11.
A Parte 4 (FERRAMENTAS CASE) apresenta a problemtica das fer-
ramentas CASE descrevendo o seu significado, evoluo histrica e
discutindo mecanismos de caracterizao e avaliao (Captulo 12).
So apresentadas e analisadas duas ferramentas CASE, o Rose da Ra-
tional e o System Architect da Popkin, respectivamente nos Captulos
13 e 14.
No Apndice A (Guia de Recursos Electrnicos) apresenta-se de
modo classificado um conjunto significativo de recursos electrnicos so-
bre os temas abordados neste livro.
No Apndice B (Glossrio, Siglas e Abreviaturas) apresentam-se trs
tabelas com informao relativa ao glossrio, as siglas, e as abreviatu-
ras adoptadas ao longo de todo o livro.
Em Referncias listam-se, por ordem alfabtica, todas as referncias
bibliogrficas utilizadas ao longo do livro.
Por fim, inclui-se o ndice Remissivo que constitui um mecanismo tpi-
co de trabalho e de consulta neste gnero de literatura.

VI I I CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Notao Adoptada
Ao longo do livro so adoptadas genericamente as seguintes regras de
notao textual:
Nomes e expresses em ingls so escritas em itlico. As excep-
es so expresses vulgarmente adoptadas para o Portugus
(e.g., software, bit), expresses intensamente usadas ao longo do
texto (e.g., Internet, Web, applet, standard), ou nomes de empresas
ou produtos de origem anglo-saxnica (e.g., MS-Word, Rational
Rose).
Frases e expresses que se pretendam destacar so escritas com
nfase (i.e., negrito).
Exemplos de cdigo, pseudo cdigo, nomes de classes, ou endere-
os electrnicos so apresentados numa fonte de tamanho fixo (i.e.,
Courier).

Os exemplos apresentados neste livro aparecem enquadrados por uma
moldura correspondente, conforme ilustrado neste mesmo pargrafo.

H ao longo do livro um cuidado particular na devida introduo dos
inmeros conceitos que o mesmo analisa e discute. De forma a facilitar
a identificao desses conceitos, colocamos na margem esquerda do
respectivo texto a marca visual Conceito conforme apresentado neste
pargrafo. Recomenda-se ao leitor a utilizao do ndice remissivo para
consultar a definio de qualquer dos conceitos tratados neste livro.
Por fim, relativamente representao de diagramas ser utilizada,
sempre que for adequado, e por razes bvias, a linguagem UML.

I X


Agradecimentos

Um agradecimento muito especial minha famlia por todo o amor e
suporte que tive para poder realizar mais este trabalho, bem como pelas
inmeras horas roubadas ao seu convvio.
Um agradecimento tambm aos colegas do Judo Clube Portugal e ou-
tros amigos cujo convvio me proporcionou os momentos de relaxa-
mento necessrio para a produo deste livro.
Parte significativa da actividade que conduziu realizao deste livro foi
desenvolvida no mbito de duas instituies que procuram a excelncia
- o Departamento de Engenharia Informtica do Instituto Superior
Tcnico e o Instituto de Engenharia de Sistemas e Computadores, s
quais no posso deixar de enderear o meu expresso agradecimento,
bem como a todos os colegas e alunos com quem tive o privilgio de
conviver, aprender e ensinar durante este perodo. Em particular, aos
alunos da primeira e segunda edio da Ps-Graduao em Sistemas
de Informao (POSI1999 e POSI2000) do Instituto Superior Tcnico,
com os quais ensaiei e testei uma parte preliminar deste livro; ao ncleo
organizativo do POSI, nomeadamente aos Prof. Jos Tribolet e Prof.
Paulo Guedes, pelo convite que me enderearam; e ao meu monitor
desses cursos, Eng. Miguel Goulo, com quem discuti alguns dos
tpicos e exemplos apresentados.
Um agradecimento editora Centro Atlntico, na pessoa do Dr. Librio
Manuel Silva, pelo seu interesse imediato na publicao do livro e pela
sua activa e persistente atitude de estar no nosso pequeno mercado
nacional de literatura tcnico-cientfica.
Por fim, um agradecimento a todos os colegas que de uma forma ou
outra sugeriram, comentaram ou apenas criticaram partes preliminares
deste trabalho, ou com quem simplesmente fui partilhando a ideia do
livro.
Alberto Silva

X CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE



Quero em primeiro lugar agradecer minha famlia, pela sua dedicao,
carinho e apoio incondicional, sem a colaborao da qual dificilmente
teria participado neste projecto. Quero tambm agradecer aos meus
amigos, de cujo convvio tive que prescindir para poder completar este
livro.
Para a realizao bem sucedida deste meu projecto foi tambm decisiva
a contribuio de todos os meus colegas da Mentor IT, com os quais te-
nho abordado alguns temas que so explorados neste livro. A experin-
cia adquirida nos vrios projectos em que participei permitiram-me soli-
dificar conhecimentos e sustentar algumas opinies emitidas neste livro.
Um factor decisivo para a minha participao neste livro foi a
experincia como docente, especialmente na Universidade Autnoma
de Lisboa, onde tenho estado ligado a disciplinas relacionadas com os
temas abordados neste livro. Nesse sentido, gostaria de agradecer ao
Prof. Jos Lus Ferreira e ao Eng. Miguel Gonalves toda a colaborao
e incentivo que me tm dado, bem como o seu contributo em termos de
algumas opinies. Um agradecimento particular a todos os alunos das
vrias disciplinas que leccionei, pois o esforo de preparao das ms-
mas contribuiu para a evoluo do contedo de uma parte significativa
deste livro.
Um agradecimento tambm para outros colegas com quem mantive, ao
longo destes meses de trabalho, uma permuta de opinies e crticas
que me ajudaram a melhorar a qualidade da presente obra.
Finalmente, Editora Centro Atlntico e ao Dr. Librio Manuel Silva
deixo um agradecimento pelo seu interesse na publicao desta obra
tcnico-cientfica, valorizando a misso de educar para o futuro.
Carlos Videira
XI


Contactos
Comentrios tcnicos, sugestes, pedidos de livros ou pedidos de
esclarecimentos podem ser dirigidos ao Centro Atlntico (via
www.centroatlantico.pt ou geral@centroatl.pt) que os encaminhar aos
autores via correio electrnico se a sua colaborao for necessria.


Autores

Alberto Manuel Rodrigues da Silva professor auxiliar no
Departamento de Engenharia Informtica do IST/UTL, investigador
snior no INESC e consultor informtico em diferentes empresas e
instituies. Tem um doutoramento em Engenharia Informtica e Com-
putadores pelo IST/UTL, um mestrado em Engenharia Electrotcnica e
Computadores pelo IST/UTL e uma licenciatura em Engenharia Inform-
tica pela FCT/UNL. Lecciona actualmente cadeiras da rea de Sistemas
de Informao e de Engenharia de Software de nvel licenciatura, ps-
graduao e mestrado. Supervisiona a realizao de vrios trabalhos
finais de curso e de teses de mestrado. Tem interesses profissionais e
cientficos em sistemas de informao distribudos em larga escala e em
aplicaes Web; modelizao de software, processos de desenvolvi-
mento de software; e negcios suportados electronicamente. autor de
2 livros tcnicos e cerca de 30 artigos cientficos em revistas, confern-
cias e workshops nacionais e internacionais.


Carlos Alberto Escaleira Videira actualmente Consulting Manager
na MentorIT, empresa de consultoria estratgica na rea dos sistemas
de informao, e assistente no Departamento de Cincias e Tecnolo-
gias da UAL. Desempenhou funes de coordenao na rea de Infor-
XI I CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

mtica em diferentes empresas e participou em diversos projectos como
consultor. Tem um mestrado em Engenharia Electrotcnica e Computa-
dores pelo IST/UTL e uma licenciatura em Engenharia Informtica pela
FCT/UNL. Lecciona actualmente cadeiras da rea de Planeamento de
Sistemas de Informao, Engenharia de Software e Negcios Elec-
trnicos de nvel de licenciatura e ps-graduao. Tem interesses pro-
fissionais e cientficos em temas relacionados com Planeamento Estra-
tgico de Sistemas de Informao, Engenharia de Software, Sistemas
de Informao, Gesto de Projectos e Negcios Electrnicos.

Lisboa, Maro de 2001
Alberto Manuel Rodrigues da Silva
Carlos Alberto Escaleira Videira


ndice
Prefcio ii
ndice xiv
PARTE 1 INTRODUO E VISO GERAL ________ 1
Captulo 1 - Enquadramento e Conceitos Gerais______________ 5
1.1 Introduo__________________________________________ 5
1.2 O Impacto das Tecnologias de Informao________________ 6
1.3 Produto e Processo __________________________________ 9
1.4 Sistemas de Informao______________________________ 11
1.5 Arquitectura de Sistemas de Informao_________________ 13
1.6 Objectivos do Desenvolvimento de Sistemas de Informao_ 17
1.7 Problemas no Desenvolvimento de Sistemas de Informao_ 19
1.8 Planeamento Estratgico de Sistemas de Informao ______ 22
1.9 Engenharia de Software______________________________ 24
1.10 Concluso_________________________________________ 26
1.11 Exerccios_________________________________________ 27
Captulo 2 - O Processo de Desenvolvimento de Software ____ 29
2.1 Introduo_________________________________________ 29
2.2 Processos e Metodologias ____________________________ 31
2.3 Modelos e Modelao _______________________________ 34
2.3.1 Importncia da Modelao ________________________ 35
2.3.2 Princpios da Modelao _________________________ 36
2.4 Boas Prticas no Desenvolvimento de Software___________ 37
2.5 Fases do Processo de Desenvolvimento de Software ______ 40
2.5.1 Tarefas Transversais ____________________________ 46
2.5.2 Planeamento___________________________________ 47
2.5.3 Anlise________________________________________ 49
2.5.4 Desenho ______________________________________ 51
XV


2.5.5 Implementao _________________________________52
2.5.6 Testes ________________________________________53
2.5.7 Instalao _____________________________________56
2.5.8 Manuteno____________________________________57
2.6 Processos de Desenvolvimento de Software______________59
2.6.1 Processos em Cascata ___________________________59
2.6.2 Processos Iterativos e Incrementais_________________62
2.7 Concluso_________________________________________65
2.8 Exerccios _________________________________________66
Captulo 3 - Evoluo das Metodologias de Desenvolvimento de
Software 67
3.1 Introduo _________________________________________67
3.2 A Programao como Fonte de Inovao ________________69
3.3 O Desenvolvimento Ad-Hoc ___________________________73
3.4 As Metodologias Estruturadas _________________________75
3.4.1 Contexto e Motivao ____________________________75
3.4.2 Conceitos Bsicos_______________________________76
3.4.3 Tcnicas e Notaes mais Utilizadas ________________78
3.4.4 Principais Metodologias __________________________83
3.5 Metodologias Orientadas por Objectos __________________86
3.5.1 Contexto e Motivao ____________________________87
3.5.2 Conceitos Bsicos_______________________________88
3.5.3 Tcnicas e Notaes mais Utilizadas ________________98
3.5.4 Principais Metodologias __________________________99
3.6 Outras Metodologias________________________________101
3.7 Comparao de Metodologias ________________________102
3.7.1 Gesto de Requisitos e Facilidade de Manuteno____103
3.7.2 Representao da Realidade _____________________104
3.7.3 Outros Aspectos _______________________________106
3.8 Concluso________________________________________107
3.9 Exerccios ________________________________________108

XVI CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

PARTE 2 LINGUAGEM DE MODELAO UML __ 111
Captulo 4 - UML Viso Geral___________________________ 117
4.1 Introduo________________________________________ 117
4.2 Viso Histrica ____________________________________ 119
4.3 Tipos de Elementos Bsicos _________________________ 121
4.4 Tipos de Relaes _________________________________ 122
4.5 Tipos de Diagramas ________________________________ 123
4.5.1 Diagramas de Casos de Utilizao ________________ 124
4.5.2 Diagramas de Modelao da Estrutura _____________ 124
4.5.3 Diagramas de Modelao do Comportamento _______ 125
4.5.4 Diagramas de Arquitectura_______________________ 129
4.6 Mecanismos Comuns_______________________________ 130
4.6.1 Notas (Anotaes) _____________________________ 130
4.6.2 Mecanismos de Extenso________________________ 131
4.7 Tipos de Dados ___________________________________ 134
4.8 Organizao dos Artefactos - Pacotes _________________ 135
4.8.1 Representao Grfica__________________________ 136
4.8.2 Relaes entre Pacotes _________________________ 137
4.8.3 Tipos de Pacotes ______________________________ 140
4.8.4 Modelao de Grupos de Elementos _______________ 141
4.9 Exerccios________________________________________ 142
Captulo 5 - UML Casos de Utilizao ___________________ 143
5.1 Introduo________________________________________ 143
5.2 Casos de Utilizao ________________________________ 145
5.2.1 Casos de utilizao e Cenrios ___________________ 146
5.2.2 Relaes entre Casos de Utilizao________________ 148
5.3 Diagramas de Casos de Utilizao ____________________ 155
5.3.1 Actores ______________________________________ 155
5.3.2 Casos de Utilizao Abstractos e Concretos _________ 156
5.4 Proposta de Metodologia ____________________________ 157
5.5 Exerccios________________________________________ 162
Captulo 6 - UML Modelao da Estrutura________________ 165
6.1 Introduo________________________________________ 165
6.2 Classes __________________________________________ 166
6.3 Relaes_________________________________________ 169
XVI I


6.3.1 Relao de Dependncia ________________________169
6.3.2 Relao de Generalizao _______________________170
6.3.3 Relao de Associao__________________________171
6.4 Interfaces_________________________________________178
6.5 Instncias e Objectos _______________________________182
6.6 Diagramas de Classes e Diagramas de Objectos _________186
6.7 Exemplos e Recomendaes_________________________186
6.8 Exerccios ________________________________________192
Captulo 7 - UML Modelao do Comportamento __________197
7.1 Introduo ________________________________________197
7.2 Interaces _______________________________________198
7.2.1 Objectos e Ligaes ____________________________199
7.2.2 Mensagens e Estmulos _________________________200
7.2.3 Representao de Mensagens ____________________201
7.2.4 Tipos de Mensagens ____________________________202
7.3 Diagramas de Interaco ____________________________202
7.3.1 Diagramas de Sequncia ________________________204
7.3.2 Diagramas de Colaborao ______________________205
7.3.3 Equivalncia Semntica _________________________208
7.3.4 Diagramas de Interaco e de Casos de Utilizao____211
7.4 Diagramas de Estados ______________________________213
7.4.1 Estados ______________________________________215
7.4.2 Transies____________________________________215
7.4.3 Eventos ______________________________________217
7.4.4 Aces e Actividades ___________________________219
7.4.5 Sub-Estados __________________________________220
7.5 Diagramas de Actividades ___________________________222
7.5.1 Decises _____________________________________223
7.5.2 Caminhos Concorrentes _________________________224
7.5.3 Pistas (Swimlanes) _____________________________225
7.5.4 Actividades e Objectos __________________________227
7.5.5 Envio e Recepo de Sinais ______________________228
7.5.6 Utilizaes Tpicas______________________________230
7.6 Exerccios ________________________________________233

XVI I I CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE


Captulo 8 - UML Modelao da Arquitectura _____________ 237
8.1 Introduo________________________________________ 237
8.2 Componentes e Ns________________________________ 238
8.2.1 Componentes _________________________________ 238
8.2.2 Ns _________________________________________ 241
8.2.3 Relaes entre Ns e Componentes _______________ 242
8.3 Diagramas de Componentes _________________________ 243
8.4 Diagramas de Instalao ____________________________ 246
8.5 Exerccios________________________________________ 249
Captulo 9 - UML Aspectos Avanados __________________ 253
9.1 Introduo________________________________________ 253
9.2 A Arquitectura do UML ______________________________ 254
9.2.1 A Estrutura do UML a Quatro Camadas ____________ 254
9.2.2 A Camada Metamodelo _________________________ 256
9.3 Mecanismos de Extenso ___________________________ 261
9.4 Perfis UML _______________________________________ 263
9.4.1 Perfil para Processos de Desenvolvimento de Software 264
9.4.2 Perfil para Modelao de Negcios ________________ 269
9.4.3 Perfil para Modelao de Aplicaes Web___________ 271
9.5 Sistemas de Componentes e Reutilizao ______________ 273
9.5.1 Definio de Componente _______________________ 273
9.5.2 Famlias de Aplicaes__________________________ 273
9.5.3 Sistemas de Componentes_______________________ 274
9.5.4 Reutilizao___________________________________ 276
9.6 Tipos Parametrizveis ______________________________ 278
9.6.1 Classes Parametrizveis ________________________ 278
9.6.2 Padres de Desenho ___________________________ 280
9.7 XMI XML Metadata Interchange _____________________ 284
9.8 Concluso________________________________________ 285
9.9 Exerccios________________________________________ 287



XI X


PARTE 3 METODOLOGIAS DE DESENVOLVIMENTO
DE SOFTWARE__________________________ 289
Captulo 10 - Metodologia RUP____________________________293
10.1 Introduo ________________________________________293
10.2 Enquadramento____________________________________296
10.3 Caractersticas Principais ____________________________298
10.3.1 Metodologia Conduzida por Casos de Utilizao______299
10.3.2 Metodologia Centrada numa Arquitectura ___________300
10.3.3 Metodologia Iterativa e Incremental ________________301
10.4 As 4+1 Vises do RUP ______________________________302
10.5 Viso Geral _______________________________________304
10.5.1 Conceitos Gerais_______________________________304
10.5.2 Componente Dinmica __________________________305
10.5.3 Componente Esttica ___________________________306
10.6 Ciclos, Fases e Iteraes - A Componente Dinmica______307
10.6.1 Concepo____________________________________309
10.6.2 Elaborao____________________________________310
10.6.3 Construo ___________________________________311
10.6.4 Transio_____________________________________312
10.6.5 Comentrios Gerais_____________________________312
10.7 Workflows, Actividades e Artefactos - A Componente Esttica314
10.7.1 Workflow de Gesto do Projecto___________________315
10.7.2 Workflow de Modelao do Negcio _______________318
10.7.3 Workflow de Requisitos__________________________319
10.7.4 Workflow de Anlise e Desenho ___________________320
10.7.5 Workflow de Implementao______________________321
10.7.6 Workflow de Testes_____________________________322
10.7.7 Workflow de Instalao __________________________323
10.7.8 Workflow de Gesto da Configurao e das Alteraes 324
10.7.9 Workflow de Ambiente __________________________325
10.8 Enunciado do Caso de Estudo DGD ___________________327
10.8.1 Enunciado ____________________________________327
10.9 Resoluo do Caso de Estudo DGD ___________________330
10.10 Concluso________________________________________346
10.11 Exerccios ________________________________________347
XX CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Captulo 11 - Metodologia Iconix __________________________ 349
11.1 Introduo________________________________________ 349
11.2 Viso Geral_______________________________________ 350
11.2.1 Anlise de Requisitos ___________________________ 351
11.2.2 Anlise e Desenho Preliminar ____________________ 353
11.2.3 Desenho _____________________________________ 354
11.2.4 Implementao ________________________________ 355
11.3 Avisos do Processo ICONIX _________________________ 356
11.4 Enunciado do Caso de Estudo WebDEI ________________ 357
11.4.1 Introduo ____________________________________ 358
11.4.2 Arquitectura Geral ______________________________ 358
11.4.3 Tipos Bsicos de Informao (Modelo de Dados) _____ 360
11.4.4 Funcionalidade do Sistema ______________________ 361
11.5 Resoluo do Caso de Estudo WebDEI ________________ 364
11.5.1 Anlise de Requisitos ___________________________ 364
11.5.2 Anlise e Desenho Preliminar ____________________ 373
11.5.3 Desenho _____________________________________ 380
11.5.4 Implementao ________________________________ 385
11.6 Concluso________________________________________ 387
11.7 Exerccios________________________________________ 390
PARTE 4 FERRAMENTAS CASE____________ 391
Captulo 12 - Ferramentas CASE __________________________ 395
12.1 Introduo________________________________________ 395
12.2 Evoluo Histrica _________________________________ 398
12.3 Arquitectura das Ferramentas CASE___________________ 402
12.4 Mecanismos de Integrao entre Ferramentas___________ 404
12.5 Taxonomia das Ferramentas CASE ___________________ 406
12.6 Vantagens e Problemas das Ferramentas CASE_________ 409
12.7 Funcionalidades das Ferramentas CASE_______________ 410
12.8 Gerao Automtica de Artefactos ____________________ 416
12.8.1 Round-Trip Engineering _________________________ 416
12.8.2 Gerao de Documentao ______________________ 418
12.9 Avaliao de Ferramentas CASE _____________________ 418
XXI


12.10 Ferramentas de Modelao para UML__________________420
12.10.1 Modelao de Bases de Dados ___________________422
12.10.2 Modelao do Negcio __________________________423
12.11 Concluso________________________________________425
12.12 Exerccios ________________________________________426
Captulo 13 - Rational Rose_______________________________427
13.1 Introduo ________________________________________427
13.2 Interface Grfica ___________________________________431
13.3 Repositrio _______________________________________432
13.4 Vises e Diagramas UML ____________________________433
13.5 Modelao do Negcio ______________________________435
13.6 Mecanismos de Extensibilidade_______________________435
13.6.1 Extensibilidade dos Menus _______________________437
13.6.2 Scripts no Rose________________________________439
13.6.3 Rose Automation_______________________________439
13.6.4 Rose Add-Ins__________________________________440
13.6.5 Rose Extensibility Type Library____________________441
13.7 Gerao de Cdigo Caso de Estudo em Visual Basic ____441
13.7.1 Ferramentas Utilizadas __________________________442
13.7.2 Gerao de Cdigo _____________________________444
13.7.3 Reverse Engineering____________________________450
13.7.4 Relaes de Generalizao ______________________453
13.7.5 Comentrios Gerao de Cdigo ________________456
13.8 Gerao de Modelos de Dados _______________________457
13.8.1 Gerao de Modelos de Dados at ao Rose 2000 ____458
13.8.2 Gerao de Dados a partir do Rose 2001 ___________465
13.9 Gerao da Interface Homem-Mquina_________________468
13.10 Gerao de Documentao __________________________468
13.10.1 Ferramenta SoDA______________________________469
13.10.2 Rose Web Publisher ____________________________470
13.10.3 Scripts de gerao de relatrios ___________________471
13.11 Concluso________________________________________472
Captulo 14 - System Architect ____________________________473
14.1 Introduo ________________________________________473
14.2 Interface Grfica ___________________________________476
XXI I CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

14.3 Repositrio _______________________________________ 478
14.4 Tcnicas de Modelao _____________________________ 481
14.4.1 Configurao das Propriedades do Projecto _________ 482
14.4.2 O System Architect e o UML _____________________ 483
14.4.3 Outras Tcnicas de Modelao ___________________ 484
14.5 Modelao do Negcio______________________________ 486
14.6 Gerao de Cdigo - Caso de Estudo em Java __________ 489
14.6.1 Gerao de Cdigo_____________________________ 489
14.6.2 Reverse Engineering ___________________________ 497
14.7 Gerao de Modelos de Dados _______________________ 498
14.8 Gerao de Interfaces Homem-Mquina________________ 504
14.9 Mecanismos de Extensibilidade_______________________ 507
14.10 Gerao de Documentao__________________________ 509
14.11 Concluso________________________________________ 512
PENDCES, BIBLIOGRAFIA E NDICE REMISSIVO _ 515
Apndice A Guia de Recursos Electrnicos ________________ 517
Standards, Organizaes Normalizadoras e Iniciativas ________ 519
Empresas e Links Relevantes____________________________ 519
Leituras Recomendadas ________________________________ 520
Catlogos de Informao _______________________________ 522
Ferramentas CASE____________________________________ 523
Apndice B Glossrio, Siglas e Abreviaturas _______________ 525
B.1 Glossrio___________________________________________ 526
B.2 Siglas mais Usadas __________________________________ 528
B.3 Abreviaturas ________________________________________ 529
Referncias 531
ndice Remissivo_________________________________________ 545




Parte 1 Introduo
e Viso Geral
Uma empresa de software de sucesso aquela
que consistentemente produz software de
qualidade que vai ao encontro das
necessidades dos seus utilizadores. Uma
empresa que consegue desenvolver tal
software, de forma previsvel, cumprindo os
prazos, com uma gesto de recursos, quer
humanos quer materiais, eficiente e eficaz,
uma empresa que tem um negcio sustentado.
Grady Booch, James Rumbaugh,
Ivar Jacobson. The Unified Modeling
Language User Guide.
Fazer software no uma tarefa fcil. Fazer software de qualidade
ainda mais difcil. A generalidade dos resultados obtidos ao longo do
tempo tm sistematicamente apresentado padres de baixa qualidade,
de custos e prazos completamente ultrapassados. Neste aspecto, a
indstria de software deve ser caso nico na sociedade actual, pois
2 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

apesar da taxa de sucesso dos projectos ser relativamente baixa, o
interesse das organizaes pelo desenvolvimento de sistemas informti-
cos tem aumentado constantemente, no se vislumbrando qualquer
alternativa. Tudo isto porque as organizaes reconhecem que o recur-
so informao estratgico e fonte de vantagens competitivas impor-
tantes.
O facto dos resultados dos projectos informticos estarem normalmente
abaixo das expectativas e dos diversos problemas que de forma
consistente vm ocorrendo desde o incio da utilizao das tecnologias
de informao, torna extremamente relevantes as vrias iniciativas que
possam ser desenvolvidas com o objectivo de ultrapassar estes
problemas. Sobretudo, vale a pena analisar os diversos esforos que
foram efectuados ao longo do tempo, e perceber por que alguns no
foram totalmente efectivos na resoluo dos problemas, enquanto
outros, bem sucedidos, so apontados como melhores prticas a aplicar
sistematicamente.
Esta primeira parte do livro pretende dar um enquadramento das
questes relacionadas com o desenvolvimento de software, de forma a
aguar o apetite dos leitores para os captulos subsequentes do livro,
onde so apresentadas vrias ideias, tcnicas, mtodos e ferramentas
que os autores deste livro acreditam que podero desempenhar um pa-
pel decisivo na melhoria dos diversos problemas referidos na primeira
parte.
Organizao da Parte 1
O Captulo 1, Enquadramento e Conceitos Gerais, faz o enquadra-
mento e define o mbito do livro em questes mais vastas relacionadas
com as tecnologias de informao, de forma a transmitir a mensagem
ao utilizador que h questes importantes relacionadas com o desen-
volvimento de software cuja resoluo passa pela realizao de activi-
dades e aplicao de tcnicas que saem fora do mbito deste livro.
Apresenta ainda os problemas que os sistemas de informao enfren-
tam actualmente e algumas definies que so relevantes para a com-
preenso do livro.
3


O Captulo 2, O Processo de Desenvolvimento de Software, pretende
fornecer ao leitor uma viso geral sobre as actividades relacionadas
com o desenvolvimento de software, nomeadamente sobre a sua orga-
nizao, sequncia e objectivos a atingir. So ainda clarificados alguns
conceitos relacionados com as etapas do desenvolvimento de software.
O Captulo 3, Evoluo das Metodologias de Desenvolvimento de
Software, procura dar uma viso histrica de como o desenvolvimento
de software foi encarado ao longo do tempo, na perspectiva da aplica-
o de metodologias e respectivas tcnicas, e quais as principais moti-
vaes para os diversos saltos qualitativos que ocorreram.



CAPTULO 1 ENQUADRAMENTO E CONCEITOS GERAIS 5


Captulo 1 - ENQUADRAMENTO E CONCEITOS
GERAIS
Tpicos
Introduo
O Impacto das Tecnologias de Informao
Produto e Processo
Sistemas de Informao
Arquitectura de Sistemas de Informao
Objectivos do Desenvolvimento de Sistemas de Informao
Problemas no Desenvolvimento de Sistemas de Informao
Planeamento Estratgico de Sistemas de Informao
Engenharia de Software
Concluso
Exerccios

1.1 Introduo
O objectivo deste livro apresentar a linguagem de modelao UML
(Parte 2) e demonstrar a sua aplicao de forma a facilitar todo o
desenvolvimento de software, quer seja directamente como tcnica de
modelao de software, quer seja na sua utilizao em metodologias de
desenvolvimento (Parte 3) ou em ferramentas de apoio (Parte 4).
6 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

De forma a compreender as principais razes por que muitos de ns,
ligados rea acadmica e profissional das tecnologias de informao,
acreditamos que o UML representa j actualmente um papel relevante
no desenvolvimento de software, importante enquadrar o leitor deste
livro no que consideramos os principais problemas, objectivos e concei-
tos relacionados com os sistemas de informao e com o seu desen-
volvimento. Neste primeiro captulo, esta abordagem ser efectuada de
forma ainda muito genrica, e ser concretizada nos dois captulos se-
guintes.
ainda importante que o leitor compreenda a relevncia de outros
conceitos e actividades, que devem ser aplicados no mbito dos siste-
mas de informao, mas que no se encontram no mbito deste livro;
estamos a falar, por exemplo, das noes de arquitectura de sistemas
de informao e do planeamento estratgico de sistemas de informa-
o. So reas que esto ao nvel da concepo de sistemas de infor-
mao, com preocupaes de natureza estratgica e que apenas sero
brevemente equacionadas neste livro.
1.2 O Impacto das Tecnologias de Informao
hoje em dia lugar comum ouvir-se falar da importncia que a
informtica ocupa na nossa vida. O impacto e a rpida evoluo ao lon-
go dos ltimos 40 anos das tecnologias relacionadas com os sistemas
de informao tem colocado sucessivos desafios s empresas. De
forma a tirar partido das potencialidades destas tecnologias, neces-
srio um grande investimento em software e hardware. Este impacto
visvel no s nas grandes organizaes de mbito internacional, mas
atinge tambm as pequenas e mdias empresas.

Desde que surgiram, as tecnologias de informao potenciaram o
aparecimento de novas indstrias, como sejam as consultoras de
sistemas de informao ou as relacionadas com negcios na Internet,
ou reforaram a importncia de outras, nomeadamente as ligadas
indstria de telecomunicaes. Tm tambm provocado uma redefini-
o das responsabilidades e das interaces entre os parceiros da ca-
deia de valor de vrias indstrias. Nos anos mais recentes, as tecnolo-
CAPTULO 1 ENQUADRAMENTO E CONCEITOS GERAIS 7


gias de informao tm mesmo posto em causa modelos tradicionais de
fazer negcio.
Ao longo do tempo, o papel das tecnologias de informao nas
organizaes sofreu diversas alteraes. Actualmente, as tecnologias
de informao encontram-se na origem de mudanas significativas ao
nvel dos modelos de negcio das empresas, e constituem um elemento
fundamental para a obteno de vantagens estratgicas e competitivas.
Por isso, a respectiva implementao nas organizaes deve ser cuida-
dosamente planificada e estruturada, de modo a garantir o alinhamento
com os objectivos estratgicos do negcio.
A implementao de sistemas de informao requer um investimento
significativo (financeiro, tecnolgico e de recursos humanos), pelo que
estas intervenes devero merecer o apoio e o comprometimento das
administraes. A justificao destes volumes de investimento deve ser
efectuada demonstrando qualitativamente e quantitativamente o seu
valor estratgico e o impacto positivo nas organizaes.
No entanto, muitos gestores no conseguem perceber o verdadeiro
alcance de todas estas tecnologias, quer por questes de formao,
quer pela sua anterior experincia com sistemas antiquados e obsole-
tos, que constituam verdadeiros entraves satisfao dos requisitos do
negcio, e no funcionavam como potenciadores do seu crescimento.
Por outro lado, os intervenientes da rea de informtica criaram no pas-
sado uma imagem muito tcnica, pouco alinhada com as reais neces-
sidades do negcio, o que contribuiu decisivamente para a no carac-
terizao da informtica como uma rea estratgica dentro das empre-
sas.
8 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

A progressiva importncia que os sistemas de informao tm nas orga-
nizaes pode ser constatada atravs de diversas situaes:
No passado era comum o responsvel da informtica depender
hierarquicamente do director financeiro, enquanto este reportava
directamente administrao. Pelo contrrio, actualmente so cada
vez menos as organizaes em que esta situao se mantm, fican-
do a rea de informtica ao mesmo nvel que os restantes departa-
mentos e reportando directamente ao rgo que define as respec-
tivas estratgias, a administrao; a informtica passa assim a ser
considerada como uma rea estratgica.
A indstria de software, ou de forma mais geral todas as
relacionadas com as tecnologias de informao, actualmente uma
das mais importantes em todo o planeta e uma das principais res-
ponsveis pelo crescimento contnuo da economia mundial durante
a ltima dcada. Este fenmeno tambm visvel ao nvel das indi-
vidualidades, j que o homem mais rico do mundo actualmente um
dos principais responsveis pela maior empresa de software (esta-
mos obviamente a falar de Bill Gates e da Microsoft).
A crescente importncia das empresas relacionadas com a Nova
Economia (que de forma simplificada poderemos associar ao fen-
meno Internet), cujas aces so transaccionadas nos Estados Uni-
dos num bolsa de valores especfica (Nasdaq).
A importncia destas empresas tem motivado a crescente preocupa-
o dos governos em garantir o acesso livre ao mercado e a tentar
evitar posies monopolistas. o caso do presente litgio entre o
governo americano e a Microsoft, onde assistimos disputa em tor-
no de questes por vezes pouco racionais; no entanto, e indepen-
dentemente da nossa posio pessoal, o governo americano actua
de forma semelhante dos seus antecessores h algumas dcadas
atrs, em relao a empresas de outras indstrias chave, como
eram na altura a do petrleo e do ao.
Muitos outros exemplos poderiam ser dados, mas a concluso bvia
que nos tornmos dependentes das tecnologias de informao, quer do
ponto de vista pessoal quer profissional.

CAPTULO 1 ENQUADRAMENTO E CONCEITOS GERAIS 9


1.3 Produto e Processo
A importncia das tecnologias de informao na nossa vida sobretudo
concretizada pelas funcionalidades que so implementadas ao nvel do
software, e que so disponibilizadas com o suporte de um conjunto de
dispositivos diversos (hardware). O primeiro pode ser considerado o
componente lgico dos sistemas de informao, o segundo o compo-
nente fsico.
No existe uma definio rigorosa e inequvoca de software. Diversos
autores [Pressman2000, Schach1999] encaram o software como o
resultado final de um processo, ao qual designam por Engenharia de
Software. O que um facto que o software no ddiva da natureza,
nem objecto de uma produo numa linha de montagem, realizada de
forma perfeitamente automtica, sem qualquer interveno humana, cri-
ativa e subjectiva.
Quando falamos em "processo" esta palavra implica desde logo a
definio de um conjunto de actividades uniformizadas, a aplicar
sistematicamente, que se encontram agrupadas em fases. Cada uma
destas fases tem os seus intervenientes, aos quais so atribudas
responsabilidades, que possui diversos inputs e que produz outputs. Do
ponto de vista da garantia da qualidade do produto final (o software),
fundamental que o processo seja realizado segundo parmetros que
permitam tambm aferir a respectiva qualidade, isto , no conseguire-
mos optimizar o resultado final sem uma preocupao no processo que
o produz.
Se pensarmos que o desenvolvimento do software um processo que
deve ser baseado na aplicao de tcnicas e prticas rigorosas,
sistemticas, eficientes e controlveis, podemos concluir que este se
aproxima bastante de outras realizaes humanas, como a construo
de qualquer obra de engenharia civil (por exemplo, a construo da
ponte Vasco da Gama em Lisboa). Da o nome de "Engenharia de
Software" precisamente como tentativa de trazer para esta actividade a
preocupao da aplicao de tcnicas de engenharia ao desenvolvi-
mento de software, por exemplo, modelar antes de realizar; estimar
10 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

diversos factores antes de avanar; medir antes, durante e depois do
produto realizado; analisar factores de risco.
Para alm dos elementos j descritos, tal como nas outras engenharias,
tambm a realizao efectiva das funes de desenvolvimento de sof-
tware pressupe a utilizao de ferramentas de apoio a todo o proces-
so. O tempo em que o desenvolvimento era efectuado de forma com-
pletamente manual j no razovel actualmente (tal como ningum
constri uma casa, e muito menos uma ponte, unicamente custa do
seu esforo fsico). As caractersticas destas ferramentas podem ter um
impacto aprecivel no produto final (bem como no processo), e a de-
monstrao desse facto um dos objectivos deste livro.

No entanto, tambm importante esclarecer desde j que a produo
de software encerra em si mesma alguma subjectividade, devido ao
facto de ser realizada por seres humanos, que em diversos pontos
podem introduzir factores resultantes da opinio pessoal (e que at
certo ponto podem ser benficos, pois a criatividade pode levar
produo de software com melhor aceitao e desempenho). Neste
aspecto, o processo aproxima-se mais de uma actividade artstica do
que propriamente uma actividade de engenharia. por isso que ns
consideramos, tal como outros autores, que o ponto de equilbrio
correcto depende de cada caso, mas deve-se encontrar a meio caminho
entre a aplicao de tcnicas estruturadas (Engenharia) e introduo de
factores de criatividade (Arte).
Actualmente, e num contexto social e econmico em constante
mudana, espera-se que o software seja capaz de evoluir a um ritmo
que no ponha em causa o crescimento das organizaes. So por isso
fundamentais as seguintes caractersticas:
Flexibilidade, enquanto capacidade de evoluo face aos requisitos
de negcio.
Fiabilidade, o que implica que o nmero de problemas ocorrido seja
reduzido e no ponha em causa o funcionamento das organizaes.
Implementao das necessidades das organizaes
Nvel de desempenho adequado
CAPTULO 1 ENQUADRAMENTO E CONCEITOS GERAIS 11


Facilidade de utilizao, com uma interface amigvel e intuitiva para
o utilizador.
1.4 Sistemas de Informao
A viso mais tradicional sobre o conceito de software limita-se a
consider-lo como um conjunto de programas, constitudo por blocos de
cdigo. Outros autores englobam ainda neste conceito a documentao
de apoio que produzida. No entanto, quando falamos actualmente do
componente lgico que serve de suporte s necessidades das organiza-
es, o conceito mais abrangente normalmente utilizado o de siste-
mas de informao.
Tal como em muitas outras situaes no domnio da informtica, no
existe uma definio formal e consensual deste conceito. Neste livro
adoptaremos a seguinte definio: um sistema de informao um
conjunto integrado de recursos (humanos e tecnolgicos) cujo objectivo
satisfazer adequadamente a totalidade das necessidades de informa-
o de uma organizao e os respectivos processos de negcio. Nesta
definio o conceito processo de negcio pretende representar uma
sequncia de actividades, que processam vrios inputs e produzem
vrios outputs e que possuem objectivos. Pode ser realizado por pes-
soas e/ou de forma automtica. Exemplos de processos de negcio
incluem as compras de matrias-primas, a contratao de um empre-
gado ou a distribuio de produtos acabados.
Existem outras definies para o conceito de sistema de informao que
enumeram os respectivos componentes, nomeadamente pessoas,
hardware, software, redes e dados, sempre numa perspectiva integrada,
e de modo a suportar e melhorar as operaes dirias do negcio, bem
como a satisfazer as necessidades de informao dos gestores
[O'Brien00]. Finalmente, de referir que alguns autores no consideram a
parte de processos manuais como fazendo parte do sistema de informa-
o.
Os sistemas de informao so actualmente considerados essenciais
para suportar adequadamente estratgias de globalizao e de re-
engenharia de processos de negcio e para a obteno de vantagens
12 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

competitivas, com impacto ao nvel da reduo de custos, estratgias
de diferenciao e/ou de inovao, promovendo e facilitando as
relaes e negcio com parceiros e clientes. objectivo fundamental
dos sistemas de informao garantir o alinhamento das tecnologias da
informao com os objectivos estratgicos do negcio.
O impacto dos sistemas de informao nas organizaes inegvel e
inevitvel. Uma das mais antigas classificaes de sistemas de
informao foi proposta por Anthony em 1965 [Anthony65]. Esta
classificao agrupava os sistemas de informao em funo do nvel
das actividades de gesto dentro da organizao no qual o software tem
impacto:
Operacional, onde se incluam todos os sistemas de informao que
suportavam directamente as operaes do dia-a-dia. Estamos a
falar sobretudo de operaes que implicam alteraes na informa-
o.
Tctico, que inclui as funcionalidades de anlise de informao,
sobretudo orientadas para suportar o processo de tomada de deci-
ses com impacto na gesto de curto prazo.
Estratgico, essencialmente preocupado com questes de planea-
mento, em que o impacto se situa temporalmente no mdio e longo
prazo.

Tipo de Sistemas Exemplos
Operacionais Facturao, Controlo de encomendas,
Contabilidade geral, Controle de Stocks,
Salrios
Tcticos Anlise de vendas, Controle oramental,
Contabilidade analtica, Gesto do
inventrio, Anlise da qualidade
Estratgicos Previso de vendas, Planeamento da
alocao da produo, Planeamento
recursos humanos, Previso de receitas e
custos, Modelao financeira
Tabela 1.1: Exemplos de sistemas de informao segundo a
classificao de Anthony.
CAPTULO 1 ENQUADRAMENTO E CONCEITOS GERAIS 13


Muitas outras classificaes existem, segundo parmetros variados,
mas a sua apresentao sai fora do mbito deste livro.
1.5 Arquitectura de Sistemas de Informao
A crescente complexidade dos sistemas de informao e a dificuldade
de apresentao da sua estrutura aos diversos interessados, incluindo
utilizadores e informticos, motivou durante a dcada de 80 e incios da
dcada de 90 um conjunto de esforos no sentido de formalizar e unifor-
mizar a respectiva apresentao, de modo a garantir, adicionalmente, a
integrao dos diversos componentes de informao da organizao.
Em 1987, John Zachman publicou o artigo "A Framework for Information
Systems Architecture" [Zachman87], em que introduzia o conceito de
arquitectura de sistemas de informao. As ideias propostas resultaram
de conhecimentos e experincias de outras disciplinas mais antigas (ar-
quitectura, engenharia da produo) e rapidamente se tornaram numa
referncia para todos aqueles que tm algum interesse no tema da
arquitectura de sistemas de informao. Infelizmente, e apesar da rele-
vncia do tema, muitos destes conceitos continuam desconhecidos da
maioria do pblico informtico.
De acordo com este autor, a arquitectura o conjunto de represen-
taes descritivas (modelos) relevantes para a descrio de um objecto,
de forma a que este possa ser construdo de acordo com os requisitos
(de qualidade) e mantido ao longo da sua vida til.
Esta definio consideravelmente genrica e informal e no indica o
mbito do termo arquitectura; de facto, no caso da abordagem proposta
por Zachman, ela refere-se quer aos sistemas de informao quer
empresa, uma vez que o mesmo modelo apresenta relativamente a ca-
da conceito a perspectiva do negcio e dos sistemas de informao.
O Framework de Zachman uma estrutura lgica de classificao e
apresentao dos modelos de uma organizao relevantes para a res-
pectiva gesto, bem como para o desenvolvimento dos seus sistemas, e
pode ser observado na Figura 1.1. Nesta perspectiva, modelar um siste-
ma significa determinar e representar um conjunto de informao, sobre
14 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

vrios tpicos (colunas da matriz), relevante para vrios intervenientes
(linhas da matriz).

Figura 1.1: Framework de Zachman.
Este diagrama apresenta a relao entre as diferentes funes que
podem ser identificadas na organizao, e a viso e detalhe que tm (e
precisam de ter) sobre os diversos objectos e conceitos da organizao.
Assim, so considerados cinco perfis de intervenientes que se relacio-
nam com o sistema:
Planner, responsvel pelo planeamento estratgico da organizao.
Owner, responsvel pela operao do negcio.
Designer, responsvel pela elaborao da especificao funcional
do sistema.
Builder, responsvel pela elaborao da especificao tcnica do
sistema.
Sub-contractor, responsvel pela especificao detalhada e cons-
truo do sistema.
CAPTULO 1 ENQUADRAMENTO E CONCEITOS GERAIS 15


Os dois primeiros nveis so tipicamente utilizadores do sistema e rela-
cionados com as reas do negcio, enquanto os trs ltimos so inter-
venientes com perfil informtico. medida que se desce na hierarquia,
aumenta o nvel de detalhe a que a anlise e a modelao tm que ser
efectuadas. Cada um destes perfis tem uma viso diferente sobre um
conjunto de factores analisados pelo framework, designadamente:
Qual a constituio do sistema (What) - os dados?
Como que o sistema funciona (How) as funes?
Onde est localizado o sistema (Where) as relaes e as redes?
Quem so os interessados no sistema (Who) as pessoas?
Quando ocorrem factos relevantes no sistema (When) o tempo?
Porque que o sistema funciona assim (Why) as motivaes?
Este tipo de abordagem muito estruturada permite utilizar um nico
modelo para simplificar a compreenso e comunicao sobre a viso da
organizao; dar nfase anlise de variveis independentes; e manter
uma perspectiva disciplinada sobre relaes necessrias para preservar
a integridade dos conceitos da organizao. Pode ser utilizada nas
diferentes fases do ciclo de desenvolvimento de sistemas de informa-
o, desde o planeamento estratgico at ao desenho tcnico deta-
lhado.
Uma outra abordagem alternativa baseia-se no Framework de Index
[Wurman97], e considera que a arquitectura de sistemas de informao
um conjunto integrado e consistente de componentes, que so defini-
dos de forma a garantir o respectivo alinhamento com os objectivos de
negcio, e por isso so suportados por todos os elementos da organiza-
o. Estes componentes encontram-se normalmente organizados em
quatro grandes blocos:
Arquitectura aplicacional: conjunto de sistemas e aplicaes
necessrios para suportar os objectivos de negcio da organizao.
Arquitectura tecnolgica: componentes de infra-estrutura e mqui-
nas necessrios para suportar as funcionalidades e requisitos das
aplicaes identificadas.
Arquitectura de dados: conceitos e entidades necessrias execu-
o dos processos de negcio da organizao.
16 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Arquitectura organizacional: estrutura de recursos humanos neces-
sria para suportar adequadamente os restantes componentes dos
sistemas de informao.
A definio destes componentes deve obedecer a uma sequncia
lgica, que tem a ver com as precedncias e as interligaes que exis-
tem entre eles. Como o componente que suporta os objectivos de neg-
cio so as aplicaes, estas devem ser identificadas em primeiro lugar,
em paralelo com os conceitos (dados) que gerem. As componentes tec-
nolgica e organizacional sero as ltimas a ser definidas, de forma a
suportarem adequadamente as restantes.

Figura 1.2: Representaes da Arquitectura de Sistemas de Informao.
A Figura 1.2 ilustra de uma forma esquemtica e simblica a impor-
tncia da definio de uma arquitectura estvel em que os diversos
componentes esto relacionados entre si de forma equilibrada. A parte
esquerda da Figura 1.2 pretende representar uma arquitectura estvel,
em que os componentes esto solidamente integrados, ao contrrio do
que acontece na parte direita da mesma figura, em que a arquitectura
claramente instvel e o seu equilbrio deficiente.
CAPTULO 1 ENQUADRAMENTO E CONCEITOS GERAIS 17


1.6 Objectivos do Desenvolvimento de Sistemas
de Informao
Em 1983, Robert Block definiu um sistema de informao bem sucedido
como sendo aquele que produzido dentro do prazo e nos custos
estimados; fivel (sem erros e disponvel quando necessrio) e pode
ser mantido facilmente e a baixo custo; responde adequadamente aos
requisitos definidos; e satisfaz os utilizadores. Esta definio, demasia-
do restrita, leva concluso natural de que poucos sero os sistemas
que respeitam estes requisitos [Block83].
Ao longo do tempo, o papel do software e dos sistemas de informao
nas organizaes tem evoludo de forma a posicionar-se cada vez mais
como factor estratgico e competitivo. Nos primrdios da computao
(h apenas 50 anos atrs), o software era utilizado sobretudo para a
resoluo de problemas de clculo relacionados com questes militares
(por exemplo, clculo das trajectrias de projecteis). Os primeiros com-
putadores com aplicaes de natureza comercial eram utilizados pelas
grandes organizaes com o objectivo de automatizar algumas das
etapas dos processos de negcio e desta forma reduzir custos. A partir
deste momento a importncia e impacto dos sistemas de infor-mao
nas organizaes no tem parado de crescer, e podemos carac-teriz-la
resumidamente de acordo com o apresentado na Figura 1.3.

Figura 1.3: Factos relevantes na evoluo dos sistemas de informao.
18 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE


Outras classificaes foram elaboradas, nomeadamente a de Primozic
[Primozic90], que identifica cinco grandes ondas de inovao, de acordo
com a evoluo das tecnologias de informao e os benefcios crescen-
tes que oferecem s organizaes.

Onda de Inovao Utilizao Funcional Impacto na
Organizao
Reduzir Custos Administrativas Gesto de processos
Potenciar
Investimentos
Financeiras, Produo Gesto de recursos
Melhorar e aumentar
produtos e servios
Marketing, Distribuio,
Apoio ao Cliente
Crescimento e
aumento da quota de
mercado
Melhorar a eficcia
das decises
Decises Estratgicas Reengenharia da
organizao
Atingir o consumidor Funcionalidades nos
computadores dos
clientes
Reestruturao da
indstria
Tabela 1.2: Ondas de Inovao de Primozic.
Independentemente destas classificaes, existe um conjunto de razes
que levam as organizaes a investir em sistemas de informao e que
podemos indicar de seguida, de forma resumida:
Reduzir custos operacionais, atravs da automatizao e reformula-
o dos processos de negcio.
Satisfazer requisitos de informao dos utilizadores.
Contribuir para a criao de novos produtos e servios.
Melhorar o nvel de servio prestado aos clientes actuais e facilitar a
aquisio de novos clientes.
Melhorar e automatizar a relao com os parceiros de negcio.
Melhorar o desempenho de pessoas e mquinas.
CAPTULO 1 ENQUADRAMENTO E CONCEITOS GERAIS 19


1.7 Problemas no Desenvolvimento de Sistemas
de Informao
Historicamente, o software tem apresentado de forma sistemtica e
contnua os mesmos problemas. As razes que no passado justificaram
a adopo de mtodos de trabalho mais estruturados continuam a
verificar-se e por isso somos levados a concluir que estas iniciativas no
vieram, afinal, resolver de todo os problemas. Se pensarmos no impacto
na organizao, estes podem ser essencialmente agrupados em trs
nveis:
Falta de qualidade, traduzida na satisfao incompleta dos requisi-
tos e nos problemas que se verificam aps a instalao do produto.
Desvios dos prazos previamente estabelecidos para o desenvolvi-
mento de software.
Custos previamente definidos para o desenvolvimento de software
largamente ultrapassados.


A Tabela 1.3 ilustra como ao longo do tempo os diversos problemas tm
existido de forma contnua, e independentemente das iniciativas que
tm surgido, estas no eliminaram de forma alguma o problema.

1979 Em 57 projectos, 46% estavam atrasados (mdia de 7 meses) e 59%
encontravam-se acima do oramento [Lehman79].
1979 Em 9 projectos, um valor de investimento de $3.2M USD nunca foi
completado, $2M USD nunca foi utilizado, $1.3M USD foi abandonado,
$0.2M USD foram utilizados com algumas alteraes e apenas $0.1M
USD foi utilizado como entregue [General79].
1982 75% dos sistemas desenvolvidos nunca foram completados ou
utilizados [Gladden72].
1984 Em 2000 empresas, 40% dos sistemas falharam o atingimento dos
resultados esperados [Bikson84].
1987 75% dos sistemas de controle da produo e inventrio implemen-
tados tiveram problemas [Works87].
20 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

1988 Num universo de 34 analistas de sistemas, 70% consideraram que
entre 20% e 50% dos projectos falham, porque no so satisfeitos os
requisitos de negcio previstos [Lyytinen].
1994 Em 82 executivos entrevistados, 22% tinham abandonado mais de 5
projectos nos 5 anos anteriores e 69% abandonaram pelo menos 1
[Ewusi-Mensah].
1995 Em 143 projectos, 25% no respondiam aos requisitos [Phan95].
1995 Num universo de 365 empresas, 31% projectos cancelados antes do
fim, 53% ultrapassaram custos; s 12% de 3682 foram completados a
tempo e nos custos previstos [Johnson95].
Tabela 1.3: Estatsticas diversas obtidas ao longo do tempo sobre os
projectos de desenvolvimento de software.
Foi precisamente este tipo de problemas que motivou a designao de
"crise no software" j durante a dcada de 70, a qual foi reforada por
Fred Brooks no seu clebre artigo "No Silver Bullet" ("no existem balas
de prata") [Brooks86], no qual este refere que dificilmente se encontraria
uma cura milagrosa que pudesse resolver os problemas associados ao
processo de desenvolvimento de software.
Os problemas at agora referidos tm muito a ver com questes que se
verificam durante o processo de desenvolvimento de software, mas
igualmente graves so as situaes que podem ocorrer depois deste
processo estar concludo, e os sistemas entrarem em produo. Neste
caso, o adequado funcionamento dos sistemas crucial para a existn-
cia e sobrevivncia das organizaes e das pessoas envolvidas, a dife-
rentes nveis, envolvendo questes econmicas, de segurana, privaci-
dade, qualidade de vida, etc. Existem diversos casos clssicos que
apontam para as falhas do software em funcionamento:
Em 1979, ainda durante o perodo da guerra-fria, o mundo pode ter
estado beira de uma guerra nuclear quando o sistema americano
que controlava o espao areo detectou o lanamento de msseis
pela Unio Sovitica em direco aos Estados Unidos; de facto,
tratava-se de um ataque simulado, e apesar de no terem sido di-
vulgados muitos detalhes, parece legtimo supor que tal se tratou de
um erro do sistema [Neumann80].
CAPTULO 1 ENQUADRAMENTO E CONCEITOS GERAIS 21


Durante a guerra do Golfo, uma falha no software dos msseis
Patriot que os Estados Unidos enviaram para a zona da guerra no
foi atempadamente detectada, e a correco s chegou um dia aps
um ataque iraquiano com msseis ter causado a morte a cerca de
trinta soldados americanos [Mellor94].
Devido a um erro no software de controlo de um equipamento
mdico, pelo menos dois doentes morreram entre 1985 e 1987 em
consequncia de terem recebido doses exageradas de radiao
[Leveson93].
Problemas diversos no software de controlo da distribuio e
encaminhamento de bagagem do aeroporto de Denver, nos Estados
Unidos, provocaram custos superiores a 1 milho USD por dia
[Gibbs94].
Em 1995, estimativas diversas apontavam para que o custo dos
projectos de software que foram abandonados nos Estados Unidos
equivaleria a cerca de 80 mil milhes USD, qualquer coisa como 1%
do PIB americano [Johnson95].
Como se pode constatar dos exemplos anteriores, os problemas
resultantes do mau funcionamento ou do processo de desenvolvimento
de software podem ter impacto em duas reas crticas: questes finan-
ceiras por um lado, e vidas humanas por outro. Mesmo aps a entrada
em funcionamento do software, poder-se-ia pensar que o nmero de
problemas iria diminuir drasticamente e estabilizar num nvel muito
baixo, idealmente prximo de 0. Tal no acontece, o que tem muito a
ver com o facto de qualquer interveno posterior implementao do
software poder vir a gerar um conjunto de problemas no previstos, e
consequentemente um acrscimo de erros.
Diversas causas esto na origem deste crnico falhano dos projectos
de sistemas de informao, nomeadamente:
Falta de empenhamento dos rgos de topo das organizaes.
Falta de comprometimento e empenhamento dos utilizadores.
Incompreenso do valor dos sistemas de informao.
Falta de entendimento e de sintonia entre informticos e clientes uti-
lizadores do sistema, no mbito e requisitos do mesmo.
Deficincias vrias no processo de desenvolvimento.
22 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Falhas na coordenao do projecto, nomeadamente ao nvel da
definio dos objectivos e das prioridades e da elaborao de esti-
mativas.
Falta de qualidade e inadequao dos recursos envolvidos.
Mudanas frequentes dos requisitos do negcio e incapacidade de
lidar com esta situao.
Dificuldades na integrao de componentes.
Qualidade e desempenho do software deficiente, muito relacionados
com problemas ao nvel do controle de qualidade.
Incapacidade de identificar e controlar os riscos do projecto.
1.8 Planeamento Estratgico de Sistemas de
Informao
No passado, os sistemas de informao foram desenvolvidos simples-
mente para melhorar a eficincia de determinadas funes de negcio;
mais recentemente passaram a concentrar-se na obteno de vanta-
gens competitivas. Este facto justifica a incluso de consideraes so-
bre as tecnologias de informao na definio de estratgias do neg-
cio, tal como defendido por McFarlan [McFarlan83].
Um dos objectivos dos sistemas de informao a satisfao adequada
dos requisitos de negcio, garantindo assim o correcto alinhamento com
a estratgia da organizao. por isso importante que, antes de se
iniciar qualquer processo de desenvolvimento de componentes da
arquitectura de sistemas de informao, que a mesma seja pensada de
um ponto de vista global, garantindo assim a completa integrao entre
os componentes e a prioritizao da respectiva implementao.
esse o mbito do Planeamento Estratgico de Sistemas de
Informao, cujo principal resultado um Plano Estratgico de Sistemas
de Informao (ou Plano Director de Sistemas), que define os compo-
nentes do sistema de informao a implementar, e funciona como um
guia para todas as futuras intervenes na rea de informtica. Na
sequncia deste plano, devem ser identificadas e prioritizadas as
aces a desencadear para atingir a situao futura proposta. S depois
se entra no mbito do desenvolvimento dos sistemas de informao,
naquilo que normalmente se designa por Engenharia de Software. Por
CAPTULO 1 ENQUADRAMENTO E CONCEITOS GERAIS 23


esta razo, tambm frequente que a actividade de planeamento
estratgico seja designada por Engenharia de Sistemas, para traduzir a
ideia de uma perspectiva mais abrangente.
Este tipo de abordagem pode ser aplicado numa organizao j
existente, sendo nesse caso necessrio identificar o diferencial entre a
situao actual dos sistemas de informao e o conjunto de reco-
mendaes elaborado.
Podemos definir o Planeamento Estratgico de Sistemas de
Informao (PESI) como um processo cuja finalidade garantir o
alinhamento dos sistemas de informao com os objectivos do negcio
ou como Lederer referiu [Lederer88] "o PESI o processo de decidir os
objectivos para a organizao informtica e identificar as aplicaes
informticas potenciais que a organizao deve implementar".
Enquanto processo tem uma sequncia de fases, cada uma com activi-
dades e objectivos bem identificados (ver Figura 1.4).

Figura 1.4: Metodologia de Planeamento Estratgico de Sistemas de
Informao.
O objectivo deste processo realizar um conjunto de actividades de
levantamento de informao, do negcio e dos sistemas de informao,
durante as trs primeiras fases, de modo a que na quarta fase de
possam elaborar recomendaes sustentadas e que possibilita a
elaborao de planos do projecto. No final do processo de PESI dispe-
se de um plano estratgico de sistemas de informao bem documen-
tado, uma compreenso detalhada da situao actual do negcio e dos
sistemas de informao e uma definio da direco dos sistemas de
informao suportada por toda a organizao.
24 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

1.9 Engenharia de Software
Depois de definida uma estratgia global e identificados os componen-
tes que necessrio desenvolver, a sua concretizao passa para o
domnio de outra cincia, a Engenharia de Software. Esta inclui todas
as actividades que vo desde um planeamento inicial do projecto at
instalao do sistema em produo, e posterior suporte. Por isso, dis-
ciplinas como anlise de sistemas, gesto de projectos, programao,
controle de qualidade podero ser includas no mbito da Engenharia
de Software, conforme aqui a entendemos.
Uma das primeiras definies de Engenharia do Software foi dada por
Fritz Bauer, nos finais da dcada de 60, como sendo "a definio e
utilizao de princpios de engenharia slidos, de modo a desenvolver
software econmico, fivel e que trabalha eficientemente em mquinas
reais. Inclui pois um conjunto de mtodos, de ferramentas e de procedi-
mentos". No entanto, esta definio peca por no fazer qualquer refe-
rncia a aspectos tcnicos, no referir a importncia da satisfao do
cliente, do cumprimento de prazos, da utilizao de mtricas e no enfa-
tizar a importncia de se utilizar um processo maduro.
Uma das definies mais utilizada hoje em dia foi proposta pelo IEEE
em 1993, e defende que "a Engenharia de Software a aplicao de
um processo sistemtico, disciplinado, e quantificado ao desenvolvi-
mento, operao e manuteno de software; ou seja, a Engenharia de
Software a aplicao de tcnicas de engenharia ao software".

As actividades associadas Engenharia de Software podem ser
agrupadas em trs grandes fases, tendo em conta que o seu objectivo
o desenvolvimento e operao de um produto: concepo, implementa-
o e manuteno. Cada uma destas fases pode ainda ser dividida em
outras mais elementares (ver Captulo 2 para mais detalhes). Ao longo
de cada fase existem tarefas, subprodutos a desenvolver, pontos de
verificao e intervenientes. Existe tambm um conjunto de actividades
de suporte contnuas: gesto de projecto, controle de qualidade, gesto
da configurao, elaborao de documentao, elaborao de estimati-
vas, gesto do risco, entre outras. pois uma rea de conhecimento
CAPTULO 1 ENQUADRAMENTO E CONCEITOS GERAIS 25


muito vasta, o que torna ainda mais difcil a sua aplicao de forma
rigorosa e sistemtica.
Apesar de se reconhecer o valor de um planeamento global com uma
perspectiva integradora, muitas organizaes esto mais preocupadas
em resolver problemas imediatos e parciais, e por isso desencadeiam
projectos individuais, que muitas vezes contemplam apenas as neces-
sidades e requisitos de uma rea restrita da organizao. Assim, o es-
foro da implementao de sistemas de informao comea logo pelas
actividades que j se situam no domnio da engenharia de software.
A Figura 1.5 ilustra de uma forma esquemtica a discusso anterior
entre as grandes reas de Planeamento Estratgico de Sistemas de
Informao e de Engenharia de Software, e suas relaes. Atravs dela
podemos perceber que, por exemplo, a Engenharia de Software inclui
diversas questes que pertencem Gesto de Projectos (planeamento,
execuo e aompanhamento de um projecto), mas est fora do seu
mbito questes como gesto de recursos humanos. A figura ilustra
complementarmente o contexto e o foco primordial deste livro, desig-
nadamente os assuntos conotados com as abordagens orientadas por
objectos, e em particular o UML.

Figura 1.5: Relao entre PESI e Engenharia de Software, e o foco do
livro.
26 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Existem diversos produtos construdos pelo homem que apresentam
problemas, mas mais raramente que os que se verificam no software.
Por exemplo, um frigorfico pode falhar, mas menos do que um progra-
ma de contabilidade; uma ponte pode cair, mas tal com certeza me-
nos frequente do que a ocorrncia de problemas nos sistemas opera-
tivos dos computadores. A ideia de que a concepo, implementao e
manuteno do software poderiam ser realizadas aplicando tcnicas
tradicionais de engenharia levou a que j em 1967 um grupo de trabalho
da NATO propusesse pela primeira vez o termo Engenharia de
Software, e que este assunto fosse discutido em larga escala durante a
conferncia NATO Software Engineering Conference realizada na 1968.
A concluso que resultou desta reunio foi que se deveriam utilizar os
princpios e paradigmas de outras disciplinas de engenharia j bem
estabelecidas de modo a resolver o que na altura se designou por crise
do software (a qualidade do software era inaceitavelmente baixa e os
custos e prazos no eram cumpridos). Actualmente h quem considere
que a expresso mais adequada no seria crise mas sim depresso,
dada a durao que ela j tem e ao facto de no se vislumbrar uma so-
luo imediata.
1.10 Concluso
Este captulo de introduo tem como objectivo dar uma ideia dos
principais problemas e preocupaes que de um ponto de vista genrico
se colocam aos intervenientes no processo de gesto e desenvolvi-
mento informtico. Estes problemas tm sido uma constante desde o
incio do desenvolvimento de software, e independentemente das inicia-
tivas desenvolvidas, no foi possvel at data elimin-los integral-
mente.
Devido a esta falta de resultados, poderamos considerar que estva-
mos perante um facto consumado e inevitvel, e abandonar os esforos
no sentido de corrigir as falhas detectadas. A mensagem dos restantes
captulos, e do livro no seu todo, a de que a nossa postura no pode
nem deve ser esta, e que devemos continuar a procurar ultrapassar os
problemas existentes, tal como os cientistas em medicina no desistem
de procurar a cura para o cancro, apesar de j o tentarem h muitos
CAPTULO 1 ENQUADRAMENTO E CONCEITOS GERAIS 27


anos. Devemos recolher os exemplos das histrias de sucesso e daqui-
lo que se consideram as melhores prticas de desenvolvimento de sof-
tware. Nos prximos dois captulos iremos abordar estas questes de
um ponto de vista evolutivo e mais abrangente.
Tivemos tambm como objectivo a introduo e enquadramento sucinto
de alguns conceitos desta rea de engenharia, nomeadamente os com-
ceitos de sistemas de informao, arquitecturas de sistemas de informa-
o, planeamento estratgico de sistemas de informao, e engenharia
de software. Esta discusso de conceitos permitiu ainda definir e expli-
citar claramente o mbito e o contexto deste livro.

1.11 Exerccios
Ex.1. Explique, com base na definio de Anthony, a diferena entre
um sistema de informao operacional, tctico e estratgico. D
exemplos para clarificar a sua justificao.
Ex.2. Discuta a noo de sistema de informao face noo de
software. Com base na definio dada no livro pode-se ter um
sistema de informao sem software? Justifique.
Ex.3. Enumere os trs principais problemas relacionados com o
desenvolvimento de sistemas de informao. Enumere trs das
causas conhecidas.
Ex.4. Justifique a importncia do PESI (planeamento estratgico de
sistemas de informao).
Ex.5. A flexibilidade frequentemente referida como um dos atributos
relacionados com a existncia de qualidade num sistema de
informao. Discuta os aspectos positivos e identifique possveis
consequncias negativas.
28 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Ex.6. De um modo geral, as opinies expressas pelos executivos do
negcio sobre os informticos so criticas face ao seu conheci-
mento do negcio, mas no tecem grandes consideraes rela-
tivamente a questes de natureza tcnica. Indique algumas ra-
zes por que tal acontece.
Ex.7. Na sua opinio, existem situaes em que faz sentido ter um
processo conjunto de actividades de planeamento estratgico de
sistemas de informao e de engenharia de software? Justifique
a sua resposta.



Captulo 2 - O PROCESSO DE
DESENVOLVIMENTO DE SOFTWARE
Tpicos
Introduo
Processos e Metodologias
Modelos e Modelao
Boas Prticas no Desenvolvimento de Software
Fases do Processo de Desenvolvimento de Software
Processos de Desenvolvimento de Software
Concluso
Exerccios

2.1 Introduo
A produo de software frequentemente uma actividade no estrutura-
da, por vezes catica, sem orientaes de natureza estratgica e sem
planos de gesto e controle. Assim se justifica a denominao build and
fix (programar e corrigir). Como vimos no primeiro captulo, os proble-
mas associados ao desenvolvimento de software so de tal dimenso
que fundamental a definio e aplicao de princpios, regras e estra-
tgias que conduzam a melhorias significativas em todo o desenvolvi-
mento de software. Estes princpios devero nortear sempre a interven-
o do informtico na implementao de sistemas de informao.
30 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Em qualquer desenvolvimento de sistemas de informao necessrio
definir a interveno e conjugar correctamente as interaces entre as
pessoas, o processo aplicado, as caractersticas do produto e o projecto
que orienta as actividades a desenvolver. o que Roger Pressman
apelida dos "quatro P's associados ao desenvolvimento de software
[Pressman00]. S pessoas (informticos, gestores e utilizadores)
motivadas e comprometidas com o projecto garantem o respectivo
sucesso; s um processo com tcnicas e regras bem definidas permite
atingir os objectivos propostos; s compreendendo as necessidades re-
ais dos utilizadores se pode produzir um produto de qualidade; s com
um projecto credvel e controlado possvel cumprir prazos e custos
propostos. Independentemente do mtodo utilizado, estas devero ser
sempre preocupaes comuns a todas as implementaes de software.
Em 1996, Barry Boehm identificou sete questes que qualquer projecto
de sistemas de informao dever responder [Boehm96], e que so
frequentemente agrupadas no que se designou pelo principio W5H2:
Porque que o sistema vai ser desenvolvido (Why)?
O que vai / deve ser feito (What)?
Quando que vai ser feito (When)?
Quem o responsvel (Who)?
Onde que as responsabilidades esto localizadas (Where)?
Como que vai ser feito (How)?
Quanto vai custar em termos de recursos (How much)?
Neste captulo procuramos apresentar um conjunto de definies
formais relacionadas com o desenvolvimento de software, cuja compre-
enso fundamental, e so descritas em detalhe as actividades cuja
realizao, de um ponto de vista genrico, expectvel ao longo de
todo o perodo que vai desde a identificao de uma necessidade de um
utilizador at produo do software que ser a soluo.
Gostaramos desde j chamar a ateno do leitor para o facto da
definio de vrios dos conceitos apresentados no ser consensual. As
definies apresentadas reflectem a nossa viso, que tem a preocu-
pao de ser coerente e consistente, se basear em conhecimentos sli-
dos sustentados pela experincia prtica, para alm de procurar estar
CAPTULO 2 O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 31


alinhada com a opinio da maioria dos "pensadores" da Engenharia de
Software.
2.2 Processos e Metodologias
Quando se fala do desenvolvimento de software, so frequentemente
aplicadas expresses diferentes mas que muitas vezes representam a
mesma ideia. por isso fundamental a clarificao de alguns conceitos
bsicos adoptados neste livro, que se encontram, em geral, associados
s reas cientfica/tecnolgica de sistemas de informao e de enge-
nharia de software. Estes conceitos, de natureza tcnica, so fre-
quentemente mal entendidos e/ou mal aplicados. Estamos sobretudo a
referir-nos aos conceitos de processo, metodologia e ciclo de vida.
O processo de desenvolvimento de software um conceito de
mbito muito vasto, e pretende designar uma sequncia de actividades,
normalmente agrupadas em fases e tarefas, que so executadas de
forma sistemtica e uniformizada, que so realizadas por intervenientes
com responsabilidades bem definidas, e que a partir de um conjunto de
inputs produzem um conjunto de outputs. Um processo de desen-
volvimento de software tem, segundo Booch, quatro objectivos funda-
mentais [Booch94]:
Providenciar orientao sobre a sequncia de realizao das activi-
dades envolvidas.
Especificar os modelos descritivos do sistema que devem ser
desenvolvidos.
Dirigir as tarefas dos participantes e da equipa como um todo.
Providenciar critrios para monitorizao e avaliao dos modelos e
actividades do projecto.

Nesta perspectiva, o conceito de metodologia, para alm da sequncia
de etapas e procedimentos recomendados para serem aplicados duran-
te o processo de desenvolvimento de sistemas de informao (ou seja,
uma metodologia pressupe a existncia de um processo), acrescenta a
esta definio a utilizao de um conjunto de ferramentas, tcnicas e
notaes [Booch94]. Para alm disso, normal que inclua ainda refe-
32 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

rncias a diversos princpios e regras cujo objectivo concretizar na
prtica as orientaes mais tericas que so expressas no conceito de
processo, e nas quais podemos incluir:
Regras de elaborao de estimativas (custos, prazos).
Tcnicas para efectuar medies.
Procedimentos a seguir de forma a garantir a qualidade.
Programas de formao.
Modelos da documentao a produzir, vulgarmente designados por
templates.
Exemplos prticos detalhados.
Tcnicas para configurao da metodologia, que podero ser apli-
cadas de modo a possibilitar a sua adaptao a realidades espec-
ficas.
De acordo com estas definies de processo e metodologia, o conceito
de ciclo de vida pode ser encarado como um sinnimo de processo. A
expresso ciclo de vida mais antiga, aparecendo normalmente as-
sociada s abordagens tradicionais, enquanto o termo processo apare-
ce sobretudo no contexto das abordagens mais recentes (ver discusso
sobre o tema no Captulo 3).

Gostaramos aqui de realar mais uma vez que estes trs termos so
muitas vezes utilizados indistintamente, com o significado que ns atri-
bumos ao conceito metodologia (o mais abrangente de todos). Sobretu-
do no caso das abordagens que se baseiam no paradigma da orienta-
o por objectos (e em particular aquelas que utilizam UML para a
modelao), o conceito mais utilizado o de processo. Exemplos disso
so o RUP (Rational Unified Process) e o ICONIX, ambos apresentados
neste livro (Captulos 10 e 11 respectivamente), e que se definem como
processos, mas que segundo a definio por ns apresentada devero
ser considerados metodologias.
Alis, curioso verificar que segundo Philippe Kruchten, um processo
de desenvolvimento de software "um conjunto de passos parcialmente
ordenados concebidos de forma a atingir um objectivo, que no caso da
engenharia de software, o de construir ou alterar um produto de
software" [Krutchen00]. Como se v no faz qualquer referncia a tcni-
CAPTULO 2 O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 33


cas de modelao ou ferramentas utilizadas, e que no entanto so des-
critas no mbito do RUP, do qual um dos principais mentores.
A preocupao com a utilizao de abordagens sistemticas foi talvez
levada longe demais. Por exemplo, em meados da dcada 90 estimava-
se que existiam mais de 1000 metodologias de desenvolvimento de
sistemas de informao a serem utilizadas em todo o mundo [Jayara-
tna94]. Este nmero elevado no s dificulta a seleco e aplicao
sistemtica de uma metodologia, como muitas vezes apontado como
uma das razes pelo no atingimento do objectivo de uniformizao (co-
mo h muitos standards, na prtica no existe nenhum).
As metodologias actualmente existentes tiveram essencialmente duas
origens distintas: (1) um primeiro grupo inclui as que evoluiram de
experincias prticas, sobretudo das grandes consultoras de sistemas
de informao, baseiam-se na aplicao de diversas tcnicas, e normal-
mente deram origem a produtos comerciais; (2) um segundo grupo
inclui aquelas que resultaram de esforos de investigao em universi-
dades e que so frequentemente suportadas por conceitos tericos mui-
to prximos da matemtica; por vezes, apenas se encontram descritas
em livros e no so suportadas por ferramentas.

As metodologias so por natureza de mbito geral, isto , pretendem
ser aplicadas em diferentes tipos de projectos, em diferentes indstrias
e em vrias organizaes. Muitas das metodologias so relativamente
rgidas, pois baseiam-se numa filosofia de desenvolvimento nica com
standards, tcnicas e procedimentos uniformes, sem qualquer possibili-
dade de proceder a alteraes ou configuraes estruturais prpria
metodologia. Para ultrapassar este problema houve organizaes (so-
bretudo as mais ligadas indstria de desenvolvimento de software)
que criaram competncias em diversas metodologias, de modo a pode-
rem seleccionar a mais adequada para cada projecto concreto. Ideal-
mente, as abordagens metodolgicas deveriam ser flexveis, de modo a
permitirem a seleco de caminhos alternativos dentro de uma metodo-
logia ou mesmo a configurao ou adaptao da prpria metodologia.
34 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

2.3 Modelos e Modelao
Um modelo consiste na interpretao de um dado domnio do problema
(fragmento do mundo real sobre o qual as tarefas de modelao e
construo do sistema de informao incidem) segundo uma determi-
nada estrutura de conceitos. Como exemplos de modelos podemos citar
o modelo que resulta da anlise de sistemas e o modelo de implemen-
tao.
Um esquema a especificao de um modelo usando uma
determinada linguagem, a qual pode ser formal ou informal (por exem-
plo, linguagem natural), textual ou grfica. Quando a representao do
esquema grfica, designa-se usualmente por diagrama. Como exem-
plos de esquemas e de diagramas temos o esquema relacional do mo-
delo de dados de um sistema de crdito bancrio ou o diagrama de
classes de um sistema de facturao.
Um modelo sempre uma interpretao simplificada da realidade. A
cincia em geral, e a engenharia em particular, procurou desde sempre
representar a sua realidade atravs de modelos mais ou menos cor-
rectos, mais ou menos abrangentes, mais ou menos detalhados. A ideia
geral que prefervel um mau modelo que nenhum modelo na descri-
o de qualquer sistema.
Outro aspecto relacionado que um modelo apresenta apenas uma
viso ou cenrio de um fragmento do mundo real. por conseguinte
necessrio a produo de vrios modelos de forma a melhor repre-
sentar e compreender o sistema correspondente Por exemplo, a cons-
truo de uma obra de engenharia civil apresenta inmeros modelos,
cada qual correspondendo a uma interpretao ou viso da mesma
realidade. As plantas, os alados, as perspectivas ortogonais, as
maquetes, o desenho da rede elctrica, da rede de esgotos, da rede de
gua, da estrutura de beto, so diferentes representaes ou modelos
da mesma realidade.
A Figura 2.1 ilustra dois modelos complementares para uma mesma
realidade: uma perspectiva (no lado esquerdo) e um alado frontal (lado
direito da figura) da casa.
CAPTULO 2 O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 35



Figura 2.1: Diferentes modelos de uma mesma casa.
2.3.1 Importncia da Modelao
A modelao (ou modelizao) a arte e cincia de criar modelos de
uma determinada realidade. uma tcnica bem aceite e adoptada pela
generalidade das disciplinas de engenharia conhecidas. Permite a
partilha de conhecimento entre diferentes grupos de intervenientes
(tcnicos e no tcnicos), facilita e promove a comunicao entre todos.
Facilita a gesto mais eficaz e eficiente das equipas de projecto, ao dar
uma viso mais adequada sobre os vrios produtos a desenvolver, e
permite ainda que as previses de custos e prazos sejam efectuadas
segundo critrios mais realistas o que tambm contribui para a minimi-
zao dos riscos associados.
A engenharia informtica, embora sendo uma engenharia significativa-
mente mais recente que a engenharia civil, necessita igualmente de
adoptar notaes e linguagens de representao dos seus modelos. Tal
como nas restantes engenharias, tambm na engenharia informtica se
conseguem obter beneficos atravs da modelao, que segundo [Bo-
och99] incluem os seguintes:
Os modelos ajudam a visualizar um sistema, quer seja a sua situa-
o no passado, no presente ou no futuro.
Os modelos permitem especificar a estrutura ou o comportamento
de um sistema
Os modelos permitem controlar e guiar o processo de construo do
sistema.
Os modelos documentam as decises tomadas.
36 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

2.3.2 Princpios da Modelao
A experincia adquirida na actividade de modelao sugere que, inde-
pendentemente do projecto, se verificam sempre um conjunto de quatro
princpios bsicos [Booch99].
P1: A escolha dos modelos a criar tem uma profunda influncia no
modo como o problema encarado e consequentemente como a
soluo obtida.
Isto significa que um modelo adequado (em termos de expressividade,
abstraco ou abrangncia) ilustrar de forma correcta determinados
aspectos da construo de um sistema, oferecendo aos intervenientes
no processo uma clarificao e simplificao dos mesmos. Por outro
lado, um modelo inadequado ter como consequncia uma inerente
confuso e dificuldade de compreenso e comunicao.
P2: Cada modelo deve poder ser expresso em diferentes nveis de
preciso/abstraco.
O grau de detalhe que um modelo deve apresentar est dependente do
perfil do interveniente no projecto. Por exemplo, para o utilizador ou
cliente de um sistema, apenas dever ser relevante a perspectiva de
utilizao. Por outro lado, na perspectiva do analista e do programador
do sistema, j ser relevante a especificao de como que o sistema
dever ser implementado. Por exemplo, se o sistema a considerar for
um comando da televiso, o modelo para o utilizador final ser uma
descrio da sua utilizao, enquanto que para o tcnico, o modelo
dever especificar as mensagens trocadas entre diferentes aparelhos,
tempos de atraso para garantir a boa recepo das mensagens, etc.
P3: Os melhores modelos reflectem a realidade.
Este princpio um dos conhecidos calcanhares de Aquiles de
algumas tcnicas de modelao, em que existe uma manifesta separa-
o entre os modelos utilizados para descrever "o que o sistema faz" e
outros que detalham a forma "como o sistema faz", isto para j no falar
na realidade que pretendem representar. importante corrigir este pro-
blema, porque tal separao permite que a viso do sistema concebido
e a viso do sistema implementado possam divergir significativamente.
CAPTULO 2 O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 37


P4: Nenhum modelo suficiente por si s. Qualquer sistema no-
trivial representado de forma mais adequada atravs de pequeno
nmero de modelos, razoavelmente independentes.
Tal como em engenharia civil, em que um prdio representado por
vrios modelos complementares, tambm na engenharia de software
ocorrem situaes semelhantes. Na Parte 2 deste livro veremos que o
UML se baseia significativamente neste princpio, ao propor vrias
notaes para a produo de diferentes tipos de modelos. Note-se que
o razoavelmente independentes significa que os modelos devem
poder ser construdos de forma mais ou menos independente (at mes-
mo em paralelo), mas que devero manter algum nvel de integrao,
estilo, consistncia e coeso entre si. preciso no esquecer que o sis-
tema objecto de modelao comum a todos os modelos.
2.4 Boas Prticas no Desenvolvimento de
Software
A complexidade uma caracterstica inerente ao software. S um
nmero muito reduzido de sistemas e tendo em conta o seu mbito,
nmero de pessoas afectadas ou criticidade da informao no apre-
senta esta caracterstica (um bom exemplo disso um sistema de
gesto de contactos pessoais). Tal deve-se ao facto de, como Brooks
sugeriu no seu famoso artigo No Silver Bullet [Brooks86], a complexi-
dade do software uma propriedade essencial, intrinseca prpria
natureza do software, e no acidental, que ocorra esporadicamente. Se-
gundo Booch [Booch94], esta complexidade tem origem em quatro fac-
tores:
A complexidade do domnio do problema.
A dificuldade de gerir o processo de desenvolvimento.
A flexibilidade que possvel (ou no) implementar atravs de sof-
tware.
Os problemas de caracterizar o comportamento de sistemas dis-
cretos.
38 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

A incapacidade de controlar esta complexidade do software tem
conduzido a projectos que ultrapassam os custos, os prazos e que no
respeitam os requisitos definidos, tal como discutido no Captulo 1.
Courtois identificou vrios atributos de um sistema complexo [Cour-
tois85]:
Um sistema complexo composto por outros subsistemas
relacionados, e assim sucessivamente, at se atingir um nvel que
considerado elementar. Pode assim dizer-se que um sistema
complexo expresso atravs de uma hierarquia de elementos.
A seleco dos componentes elementares de um sistema complexo
arbitrria e depende de quem a efectua, pois no existem critrios
universais para o fazer.
Num sistema complexo, com muitos elementos, as relaes intra-
componentes so mais fortes do que as inter-componentes.
Cada subsistema normalmente composto por poucos componen-
tes diferentes.
Um sistema complexo que funciona invariavelmente uma evoluo
de um sistema simples que j funcionou; um sistema complexo
concebido de raiz normalmente no funciona e dificilmente pode ser
alterado de forma a que tal acontea.
Existe uma limitao natural da capacidade humana de lidar com a
complexidade: no conseguimos estar em dois locais ao mesmo tempo,
nem pensar em dois problemas simultaneamente. Por isso, Dijkstra
sugeriu a aplicao do famoso princpio da decomposio hierrqui-
ca, tambm conhecido por divide and conquer ("dividir para conquis-
tar"), atravs do qual um problema dividido em sub-problemas mais
elementares e assim sucessivamente, at que a sua resoluo seja
mais simples.
Tambm a aplicao de um mecanismo de abstraco favorece a
eliminao da complexidade: j que no possvel lidar com toda a
realidade dos sistemas complexos, o ser humano opta por "esquecer"
os detalhes menos importantes e focar a sua ateno nos mais
relevantes, lidando com um modelo simplificado da realidade, mas
considerado suficiente para entender e solucionar correctamente o
problema em anlise.
CAPTULO 2 O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 39


Para alm destas duas ideias, da decomposio hierrquica e da
abstraco, so frequentemente referidos na literatura outros princpios
considerados fundamentais para a produo de software de qualidade,
designadamente:
O desenvolvimento deve ser efectuado de forma iterativa, repetindo
as mesmas actividades em momentos temporais desfasados, mas
detalhando o mbito das funcionalidades do sistema (ver discusso
na Seco 2.6.2).
Efectuar uma gesto integrada dos requisitos, permitindo a verifi-
cao da rastreabilidade dos mesmos desde o momento da sua
identificao at respectiva implementao, facilitando todo o
processo de gesto de alteraes.
Utilizar arquitecturas baseadas em componentes reutilizveis, como
forma de diminuir o esforo de desenvolvimento e posterior manu-
teno.
Modelar o software atravs de diagramas grficos, mais facilmente
compreensveis e menos sujeitos a interpretaes subjectivas.
Efectuar a verificao sistemtica da qualidade, no apenas no final
do desenvolvimento.
Implementar um processo sistemtico de controlo de alteraes, de
forma a gerir adequadamente um problema incontornvel ("os requi-
sitos de negcio mudam frequentemente") e a definir a forma e o
momento em que essas alteraes sero contempladas no sistema.
Cada uma destas melhores prticas tem impacto nas outras. Por
exemplo, o desenvolvimento iterativo favorece a implementao de uma
poltica de controle de alteraes, uma vez que ao diminuir o tempo que
vai desde a identificao da necessidade at disponibilizao de uma
verso funcional (se bem que parcial) da aplicao, as alteraes que
entretanto ocorram podem ser incorporadas na nova iterao.

Existem outros princpios que devero ser aplicados no sentido de ga-
rantir o sucesso no desenvolvimento de software:
Conseguir e promover o envolvimento dos utilizadores.
Utilizar uma abordagem orientada para a resoluo de problemas.
40 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Definir e utilizar standards para o desenvolvimento e documentao.
Justificar o desenvolvimento de software como uma actividade
estratgica e como investimento financeiro.
Conceber sistemas de modo a facilitar a sua expanso e alterao.
Vale a pena referir que existiram diversas iniciativas que ao longo do
tempo foram desenvolvidas no sentido de melhorar o processo de de-
senvolvimento de software, nomeadamente:
As iniciativas realizadas pelo Software Engineering Institute, que tem
tido uma contribuio importante no estudo e definio de metodo-
logias, estratgias e tcnicas (para mais informaes consultar
[Paulk93] ou o endereo www.sei.cmu.edu).
As iniciativas relacionadas com a implementao de polticas de
qualidade, em particular da srie 9000 da ISO [ISO91].
A iniciativa SPICE (Software Process Improvement Capability
dEtermination) [Dorling91].
A descrio destas iniciativas sai fora do mbito deste livro, mas
recomendamos a consulta das fontes acima apresentadas aos leitores
mais interessados nestes temas.
2.5 Fases do Processo de Desenvolvimento de
Software
Uma das ideias dominantes para a melhoria do desenvolvimento de
software a necessidade de aplicar um processo com fases bem
definidas, que se subdividem em conceitos mais elementares (tarefas e
actividades). Esta noo de processo comeou a ser aplicada ao
desenvolvimento de software a partir do momento em que se tornou
bvio que as iniciativas desenvolvidas ao nvel das actividades de pro-
gramao (como foram a programao estruturada) no eram suficien-
tes para resolver os problemas que se levantavam no desenvolvimento
de software, atendendo ao seu crescimento em termos de complexi-
dade e dimenso.
Como vimos na Seco 2.2, a noo de processo consiste na definio
de um conjunto de fases sequenciais, cada uma com tarefas bem
definidas, nas quais participam pessoas com responsabilidades atribu-
CAPTULO 2 O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 41


das e com diferentes competncias, e que realizam diversas activida-
des; a natureza sequencial do processo implica que uma fase (bem
como tarefa e actividade, consoante o nvel de detalhe que estejamos a
considerar) tenha que estar terminada antes de outra comear. Cada
tarefa tem um conjunto de outputs bem definidos, que tm que ser
produzidos antes que se possa considerar a tarefa como concluda.
Nesta perspectiva, uma fase constituda por uma sequncia de
tarefas, e estas por sua vez so formadas por actividades. Os dois
primeiros so conceitos abstractos, introduzidos de forma a agregar as
actividades realizadas em funo de critrios relativamente aos quais as
actividades apresentam algumas semelhanas, como sejam objectivos
a atingir, tipo de trabalho efectuado, relaes e nvel de inter-
dependncia. As actividades correspondem de facto a trabalho realiza-
do, sendo pois a unidade mais elementar em que dividimos esta hierar-
quia de conceitos (se bem que alguns processos proponham ainda a
diviso de uma actividade em passos mais elementares), e aquela
que pode ser medida e estimada em termos de planeamento. Em cada
actividade so envolvidos diferentes membros de uma equipa, que
desempenham distintos papis, e so produzidos diferentes modelos
com variados nveis de abstraco.
Na Figura 2.2 pretendemos mostrar a hierarquia de conceitos e a sua
sequencialidade, de forma puramente abstracta e conceptual, e sem
considerar nenhum processo concreto existente. No mbito deste livro
iremos considerar que um processo se pode dividir em trs grandes
fases ou momentos que traduzem a sua evoluo temporal:
Concepo, cujo objectivo identificar "o que que o sistema
deve fazer", nomeadamente a informao a processar, as funciona-
lidades a implementar, as restries existentes, os critrios que
determinam o sucesso e a aceitao; devem ainda ser consideradas
e avaliadas diferentes alternativas e efectuada a respectiva selec-
o.
Implementao, em que o objectivo identificar "o como fazer o
sistema", e constru-lo de facto; nomeadamente, sero definidas e
construdas as estruturas de dados, os programas, os mdulos, as
interfaces (internas e externas), os testes a realizar; no final desta
fase dever ser disponibilizado o sistema de forma funcional.
42 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Manuteno, que inclui todas as alteraes posteriores aceitao
do produto pelo cliente final: correco de erros, introduo de me-
lhorias e/ou de novas funcionalidades.

Figura 2.2: Representao genrica da hierarquia de conceitos fase,
tarefa e actividade.
Se bem que a necessidade de aplicao de um processo estruturado ao
desenvolvimento de software seja consensual, o mesmo no se pode
dizer da sua definio, sobretudo na identificao das fases e tarefas
que o compem e respectiva sequncia. Ao efectuar esta classificao
temos como preocupao fundamental respeitar vrios critrios lgicos
(como sejam a semelhana entre os objectivos a atingir e o tipo de
actividades realizadas), para alm de procurarmos apresentar uma clas-
sificao sintonizada com a maioria dos autores da rea da Engenharia
de Software (veja-se por exemplo [Pressman00] ou [Schach99]). A
sequncia das fases considerada neste livro pode ser observada na
Figura 2.3, onde representamos tambm o nvel de detalhe das tarefas.
No entanto, no queremos perder a oportunidade de apresentar ao
leitor algumas das diferenas mais relevantes que pode encontrar nou-
tras classificaes. Por exemplo, h quem considere que o levanta-
mento dos requisitos do sistema e a respectiva especificao so tare-
fas distintas, enquanto outros autores juntam ambas na tarefa de an-
lise e consideram-na como duas actividade da referida tarefa (esta foi a
nossa opo, de acordo com os critrios acima apresentados).
CAPTULO 2 O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 43


H tambm quem considere que deve existir uma tarefa de testes
independente a seguir ao desenvolvimento do sistema, enquanto outros
argumentam que o controle de qualidade e a realizao de testes deve
ser uma preocupao constante e realizada ao longo de todo o ciclo.
Apesar de concordarmos com este princpio, optmos por considerar
uma tarefa de testes independente, dado o volume e o esforo que os
testes assumem no final da implementao, e tambm as especificida-
des destes testes relativamente ao controle de qualidade que efec-
tuado ao longo das restantes tarefas do ciclo.

Figura 2.3: Fases e tarefas do processo desenvolvimento de software.
H ainda quem opte por considerar que o desenho uma tarefa que
deve ser colocada na fase de concepo, uma vez que as actividades
realizadas so de definio e no propriamente de implementao. A
nossa posio que, apesar da validade desta observao, a tarefa de
desenho tem como objectivo definir como se vai fazer, e nesse sentido
deve ser colocada na implementao. No pelo facto da fase de
implementao ser de natureza eminentemente prtica e operacional
que no podem existir tarefas e actividades de planeamento e de defi-
nio da mesma.
44 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Tal como pode ser observado na Figura 2.3, as fases podem ser sub-
divididas em tarefas mais especficas:
Planeamento, correspondendo a uma identificao geral das
necessidades, identificao e seleco de alternativas e definio de
plano do trabalho.
Anlise, que inclui a identificao detalhada das funcionalidades do
sistema (Levantamento de Requisitos) e a respectiva descrio
(Especificao do Sistema) de modo a que os mesmos requisitos
possam ser validados pelos utilizadores finais do sistema.
Desenho, onde realizada a definio detalhada da arquitectura
global da soluo (mdulos, tabelas, interface, mquinas, etc.).
Desenvolvimento, tarefa na qual realizada a programao dos
diversos componentes do sistema.
Testes (ou Integrao), em que o sistema no seu global verifi-
cado com o objectivo de obter a aceitao do utilizador.
Instalao, tarefa onde so executadas as actividades relacionadas
com a disponibilizao do sistema para os seus utilizadores finais, e
que normalmente designada por entrada do sistema em produo.
Finalmente a Manuteno, o momento que corresponde ao tempo
de vida til do sistema e durante o qual sero efectuadas todas as
alteraes posteriores entrada em funcionamento do produto.

Figura 2.4: Do Problema para a Soluo.

CAPTULO 2 O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 45


A Figura 2.4 apresenta uma viso diferente sobre o objectivo da
aplicao de um processo de desenvolvimento de software: a partir do
enunciado de um problema aplica-se um conjunto de actividades de
anlise para determinar o domnio do problema; a partir do domnio
do problema aplica-se um conjunto de actividades de desenho para
determinar o domnio da soluo; a partir do domnio da soluo
aplica-se um conjunto de actividades de implementao para deter-
minar o domnio da realizao, que o produto final de um projecto.
Esta uma viso muito formal, mas que traduz com rigor o que de
facto realizado.

Figura 2.5: Custos relativos de diversas tarefas do processo de
desenvolvimento de software.
Segundo diversos estudos realizados e condensados em [Schach99],
os custos relativos de cada tarefa de um processo de desenvolvimento
de software, tal como se verificavam em finais da dcada de 70, podem
ser observados no grfico da Figura 2.5.
Tal como foi referido no Captulo 1, a manuteno do software sempre
foi a tarefa do processo de desenvolvimento de software que maior
esforo e custos relativos apresentava. Apesar das iniciativas de imple-
mentao de boas prticas no processo de desenvolvimento de sof-
tware que se procuraram introduzir, esta proporo continua a ser idn-
tica [Yourdon96].
46 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Passamos de seguida a analisar mais detalhadamente cada uma das
tarefas do processo de desenvolvimento de software.
2.5.1 Tarefas Transversais
Existem algumas tarefas importantes, que agrupam actividades repe-
tidas sistematicamente ao longo de todo o processo, ou parte deste,
como o caso da gesto do projecto ou a gesto de alteraes.
Gesto do Projecto
A tarefa de gesto do projecto agrupa um conjunto de actividades
relacionadas com a gesto de recursos humanos, de recursos
financeiros e o controle dos prazos de execuo das vrias tarefas.
caracterizada essencialmente pelos seguintes grandes grupos de
actividades: planeamento do projecto; controle e monitorizao da sua
execuo; interveno de modo a realizar medidas correctivas. este
nvel que tambm funciona como a interface oficial para fora da equipa
do projecto; o seu principal responsvel designa-se por gestor de
projecto e intervm directamente na elaborao dos diversos docu-
mentos de mbito global e estratgico: descrio da viso global do ne-
gcio; glossrio de termos do negcio; plano do projecto, avaliao do
projecto; plano de gesto de alteraes.
Gesto de Alteraes
Em qualquer projecto de sistemas de informao, fundamental que
estejam previstos mecanismos de controle das alteraes num
processo em curso, j que tal como dizia o filsofo grego Heraclito, "a
nica certeza a mudana permanente". A capacidade de monitoriza-
o das alteraes e do seu impacto no sistema d ao gestor do
projecto o meio para avaliar e controlar a qualidade do mesmo. reas
que apresentam alteraes frequentes e imprevisveis so normalmente
consideradas reas de risco e indiciam que a tarefa de anlise foi re-
alizada deficientemente.
CAPTULO 2 O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 47


2.5.2 Planeamento
Alguns autores no consideram o Planeamento como uma tarefa
integrante do processo de desenvolvimento de software, incluindo as
actividades por ns identificadas e englobadas nesta tarefa num mbito
de um planeamento global e estratgico dos sistemas informao da
organizao, e portanto no se enquadrando no mbito da Engenharia
de Software. Outros consideram-na como uma das tarefas horizontais e
permanentes ao longo do processo, fazendo parte da tarefa de gesto
de projectos. De facto, muitas das actividades e tcnicas aplicveis a
esta tarefa so tpicos de qualquer gesto de projectos.
Neste livro, ns consideramos uma tarefa de planeamento logo no incio
do processo, no s para apresentar a perspectiva mais abrangente,
mas sobretudo porque necessrio ter uma viso global sobre o mbito
do trabalho a realizar de modo a elaborar um planeamento e a efectuar
uma anlise de viabilidade do projecto. Este tipo de abordagem pode
significar que, a partir de um problema manifestado por um cliente, seja
detectada a necessidade de desencadear vrios projectos. A nossa
perspectiva que s temos um projecto depois do seu plano estar apro-
vado, e esse o principal objectivo desta tarefa.
Existem ainda vrias circunstncias particulares em que esta tarefa
deve ser realizada, por exemplo:
Num projecto que envolve a seleco de entidades para posterior
implementao do software, a elaborao de cadernos de encargos
e a avaliao de propostas pode ser englobada nesta tarefa.
Pode significar apenas uma investigao inicial, com recolha de
informao suficiente sobre o problema ou oportunidade de modo a
determinar se a situao actual justifica o desenvolvimento de uma
soluo suportada por um sistema de informao.
A grande preocupao desta fase que a partir de um levantamento de
alto nvel das necessidades do negcio seja possvel elaborar um plano
do projecto a executar nas fases subsequentes, com identificao de
actividades, recursos, prazos e custos. Para isso, existem um conjunto
de actividades que devero ser realizadas, designadamente:
Compreender a misso e organizao da empresa.
48 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Identificar e envolver todos interessados e afectados pela introduo
do sistema.
Obter uma viso de alto nvel do funcionamento do sistema actual,
caso ele exista.
Definir o mbito do sistema.
Elaborar uma descrio de alto nvel do problema.
Identificar restries, problemas e riscos do projecto.
Identificar alternativas de implementao, proceder sua avaliao
e seleco.
Apresentar resultados e recomendaes, com justificao tcnica,
funcional e financeira.
Elaborar e obter aprovao de um plano de projecto.
Definir o processo de controlo do projecto.
Como se constata desta lista (no exaustiva) de actividades a realizar,
muitas so actividades que qualquer gestor de projectos (independente-
mente da rea do conhecimento humano em que trabalhe) deve saber
executar. Por isso, tambm a maioria das tcnicas a utilizar no so
especficas dos sistemas de informao, mas comuns rea de gesto,
tais como: anlise financeira de custos e/ou benefcios; elaborao de
estimativas; elaborao de planos de projectos (identificao de tarefas,
elaborao de diagramas Pert e/ou Gantt); identificao de riscos e
medidas de os controlar; elaborao de rvores ou tabelas de deciso;
aplicao de tcnicas de modelao de processos.
No final da tarefa, e como consta da lista de actividades, dever ser
obtida a aprovao para continuar com o projecto, sendo fundamental
que esta concordncia seja obtida de todos os interessados no projecto,
em particular, do patrocinador do mesmo (o cliente/utilizador que tem
mais interesse na resoluo do problema e/ou que despoletou todo o
processo), pela rea de informtica e muitas vezes (em funo do
volume de investimentos ou das polticas internas estabelecidas) por
orgos superiores da organizao.
CAPTULO 2 O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 49


1 - Introduo (mbito e propsito do documento, Objectivos do projecto, Funes mais
relevantes, Questes de performance, Restries tcnicas e de gesto)
2 - Contexto do projecto (Viso estratgica do negcio, Descrio de funes)
3 - Especificaes de alto nvel dos requisitos
4 - Estimativas do projecto (Dados histricos utilizados nas estimativas, Tcnicas de
estimao)
5 - Riscos do projecto (Anlise de risco: Identificao, Estimao, Avaliao; Gesto do risco:
Opes para evitar risco, Procedimentos de monitorizao dos riscos)
6 - Recursos do projecto (Pessoas - Estrutura da equipa, Hardware e Software, Outros)
7 - Calendarizao (Work breakdown structure, Diagramas de Pert e de Gantt)
8 - Mecanismos de acompanhamento e controle
9 - Anlise custos / beneficios
10 - Anlise de alternativas

O principal output desta tarefa ser um plano de projecto (ver exemplo
acima), que dever reflectir sustentadamente a viso que se tem nesta
fase do processo sobre as actividades a desenvolver futuramente, quer
seja relativamente sua inventariao, recursos, prazos e custos
envolvidos, como tambm em relao aos benefcios potenciais que o
sistema apresentar no futuro para toda a organizao.
2.5.3 Anlise
A tarefa de anlise efectua o estudo detalhado do domnio do problema,
e culmina na elaborao de um documento onde os requisitos funcio-
nais da soluo a implementar e outras questes relevantes (por exem-
plo, restries, mbito, fluxos de informao) so enumerados. Tem
normalmente dois grandes momentos ou sub-tarefas (que tipicamente
so realizados em simultneo):
50 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Levantamento de Requisitos
Um requisito uma funcionalidade ou condio que o sistema dever
possuir. Para os identificar adequadamente, aplicado um conjunto de
tcnicas de modo a obter a percepo detalhada daquilo que o sistema
dever efectuar. Estas podero incluir a realizao de reunies com os
interessados, a elaborao de questionrios, a observao das activida-
des e do funcionamento do dia-a-dia, a recolha e anlise de documenta-
o diversa, a elaborao de pequenos prottipos do sistema que
permitam validar mais facilmente a percepo obtida (seguindo o princ-
pio que "uma imagem vale mais do que mil palavras"). Deve-se ter a
preocupao de encontrar a melhor soluo, pois s vezes aquilo que o
utilizador pede no sempre o que ele necessita (este facto est rela-
cionado com o seu desconhecimento do que se pode obter de um sis-
tema de informao). Outra questo a considerar tem a ver com a im-
portncia de identificar no apenas as funcionalidades actuais, mas so-
bretudo determinar a situao futura a atingir.
Especificao do Sistema
Contrariamente ao que se poderia julgar em primeira instncia, definir e
descrever os requisitos de um sistema no tarefa fcil (como sabe
qualquer indivduo que desenvolveu um sistema de software): as
interpretaes e representaes que cada indivduo tem relativamente a
um determinado sistema so quase sempre subjectivas ( a velha
histria do "copo meio vazio ou meio cheio"). O objectivo geral desta
sub-tarefa expressar sem ambiguidades o que o sistema deve fazer e
no como fazer o sistema.

O conjunto de todos os requisitos e funcionalidades de um sistema
reunido num documento designado por Especificao de Requisitos.
Se bem a designao mais utilizada seja esta, tal no quer dizer que no
relatrio apenas estejam enumerados os requisitos. normal incluir
outro tipo de informao, nomeadamente os fluxos de informao que
ocorrem no sistema, a identificao dos respectivos componentes e das
suas relaes, as restries do sistema, as reas internas e externas da
organizao afectadas.
CAPTULO 2 O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 51


Este documento deve ser visto como um contrato, da a importncia de
ser rigoroso, objectivo, coerente e o mais completo possvel. A especi-
ficao utiliza normalmente tcnicas de modelao de processos, de
definio de conceitos e de representao do comportamento do siste-
ma, que sero apresentadas no prximo captulo.
Tal como na tarefa anterior, no final desta tarefa de anlise deve-se
colocar a questo da continuidade do projecto, e obter das mesmas
pessoas anteriormente referidas a aprovao da especificao de requi-
sitos elaborada e do plano de projecto, agora revisto e detalhado.
2.5.4 Desenho
Como j vimos, o desenho pretende efectuar a definio do domnio da
soluo. Com base nos resultados produzidos pela tarefa de anlise,
procede-se especificao, formal ou informal, das caractersticas que
a implementao do sistema pretendido dever apresentar, assim como
a realizao de determinadas optimizaes consoante as caractersticas
da infra-estrutura tecnolgica de suporte. Esta inclui, por exemplo,
arquitecturas de computadores, tecnologias de bases de dados, siste-
mas de execuo de agentes, infraestruturas de objectos e/ou compo-
nentes, etc. tambm nesta tarefa que deve ficar completamente
definido o ambiente e as linguagens a utilizar no desenvolvimento.
Diz-se tambm com frequncia que o desenho a fase da especifica-
o tcnica, uma vez que so definidos os componentes aplicacionais
(objectos, mdulos, programas, servidores aplicacionais), tecnolgicos
(redes, mquinas, outros servidores) e os dados (estrutura de ficheiros
e/ou de bases de dados, servidores a utilizar). Toda esta definio
realizada de forma integrada; feita a descrio da lgica e dos algorit-
mos das aplicaes, a interface e os outputs do sistema so tambm
modelados.
Factores como o desempenho, a segurana e a operacionalidade do
sistema devero ser tidos em conta e utilizados (para alm dos tra-
dicionais critrios de custos e prazos) para seleccionar entre alterna-
tivas diversas. Devem tambm ser elaborados os planos de testes e de
migrao do sistema actual (ambos para executar numa fase posterior),
52 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

se bem que alguns autores protelem a elaborao destes planos para
mais tarde, imediatamente antes da sua realizao.
2.5.5 Implementao
A tarefa de implementao inclui todas as actividades de desenvolvi-
mento do sistema propriamente dito, ou seja, que esto relacionadas
com a concretizao do modelo de desenho produzido na tarefa
anterior. Os diversos componentes aplicacionais so codificados e
testados de forma isolada, garantindo assim a respectiva correco
interna; este tipo de testes designa-se normalmente por testes unitrios,
uma vez que incidem sobre parcelas do sistema, e so realizados por
cada programador de forma independente.
Preferencialmente, as actividades desta tarefa deveriam ser apoiadas
por ferramentas, que a partir da especificao do modelo de desenho
produzido seriam capazes de produzir automaticamente diversos
componentes do sistema. Esta possibilidade pode ser concretizada por
ferramentas e ambientes de desenvolvimento evoludos e integrados,
de forma que a tarefa seja executada com o menor esforo e no menor
perodo de tempo possvel. Actualmente assiste-se, no contexto dos
sistemas de informao cliente/servidor, crescente utilizao de
ambientes de desenvolvimento bastante produtivos (designados por
ambientes RAD Rapid Application Development), baseados em infra-
estruturas de objectos/componentes evoludos, complexos e providen-
ciando paradigmas de prototipagem e desenvolvimento visual. No
entanto, e apesar de todos os avanos verificados e de j existirem
algumas ferramentas CASE com essas funcionalidades, a verdade
que a sua utilizao no em geral adoptada (ver Parte 4 deste livro).
A crescente aquisio pelas organizaes de produtos previamente
desenvolvidos com funcionalidades mais ou menos uniformizadas para
a maioria das organizaes (designados por pacotes), fez com que o
tipo de actividades a executar ao longo desta tarefa tenha mudado de
alguma forma: a programao pura cedeu uma parte da sua importncia
em favor de esforos de integrao (entre os diversos componentes
"pr-fabricados"), de parametrizao (concretizao de parmetros ge-
nricos previstos na aplicao para os valores utilizados pela organiza-
CAPTULO 2 O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 53


o) e de customizao adicional (adaptao de funcionalidades j exis-
tentes s especificidades da organizao, podendo implicar desenvolvi-
mento).
2.5.6 Testes
Para alm dos j referidos testes unitrios, executados durante a
realizao da tarefa anterior, esta tarefa destina-se execuo dos
restantes tipos de testes. O objectivo avaliar a adequada correco e
funcionamento de todos os componentes do sistema, principalmente os
executveis. A verificao consiste na confirmao que a codificao/
implementao do sistema est conforme (correcta) a especificao
tcnica produzida na fase de desenho, que por sua vez resulta dos
requisitos especificados na anlise. Por isso se diz que importante
efectuar a rastreabilidade dos requisitos.
54 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE


Figura 2.6: Ambientes de desenvolvimento, testes e produo.
Estes testes devero ser executados em condies idnticas aquelas
que o sistema real ir possuir, mas fisicamente dever ser suportado
por outros componentes, de forma a que no existam interferncias
entre as actividades dos programadores e os testes dos utilizadores, e
sobretudo com o trabalho normal do dia-a-dia destes ltimos. Por isso,
muitas organizaes criaram uma separao mesmo ao nvel fsico
entre os componentes de natureza aplicacional que esto a ser desen-
volvidos, testados ou utilizados para suportar o negcio real da empre-
sa, nomeadamente atravs do suporte em mquinas e ambientes distin-
tos (ver Figura 2.6). O facto dos ambientes serem fisicamente separa-
dos no significa que no seja possvel aceder a vrios a partir do ms-
mo posto de trabalho.
Os testes a realizar podem ser classificados em diferentes categorias,
segundo as caractersticas do sistema que avaliam:
CAPTULO 2 O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 55


Testes de carga: permitem analisar e avaliar o comportamento do
sistema em situaes de utilizao intensiva e aferir as capacidades
de escalabilidade.
Testes de desempenho: permitem analisar o tempo de resposta do
sistema e, dum forma geral, verificar o nvel de utilizao de recur-
sos disponveis.
Testes de usabilidade: permitem analisar a adequabilidade do de-
senho das interfaces homem-mquina e constatar se o sistema f-
cil de utilizar.
Testes funcionais: permitem determinar a correco da implementa-
o de funcionalidades, conforme especificadas pelos correspon-
dentes requisitos funcionais.
Os testes podem ainda classificar-se segundo o mbito dos compo-
nentes do sistema que so alvo de verificao. Por exemplo:
Testes unitrios, j anteriormente referidos.
Testes de integrao: testes parcelares, que vrios programadores
realizam conjuntamente com vista a garantir que vrios compo-
nentes interactuam entre si de forma adequada.
Testes de sistema: testes globais em que todos os componentes do
sistema so integrados; possibilitam a verificao da conformidade
do sistema com todos os requisitos definidos.
Testes de aceitao: testes formais que os utilizadores realizam
sobre o sistema. Quando o sistema passa este (difcil!) teste, o
cliente dever aceitar o sistema como pronto e consequentemente
este pode ser colocado em produo, ou operao, efectiva.
Nos casos em que o desenvolvimento pretende substituir um sistema
existente, uma abordagem que muitas vezes utilizada para a verifica-
o do sistema consiste na repetio no novo sistema das actividades
realizadas no sistema antigo, de forma a validar os resultados obtidos.
Esta estratgia designada por paralelo de sistemas.
A verificao pode ser apoiada a diferentes nveis por ferramentas de
depurao (debugging) especficas e providenciadas conjuntamente e
de forma integrada (ou no) com o resto do pacote do ambiente de
desenvolvimento. Para alm das ferramentas existem hoje em dia
tcnicas mais formais de realizao de testes, cuja descrio vai muito
56 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

alm do mbito deste livro (para mais informao consultar [Pressman-
00]).

Figura 2.7: Tipos de testes e respectivo responsvel.
O objectivo fundamental desta tarefa conseguir a aceitao formal do
cliente relativamente adequao do sistema s suas necessidades, e
a aprovao pelo mesmo da deciso de colocar o sistema em funciona-
mento.
2.5.7 Instalao
A tarefa final da fase de implementao do sistema a respectiva
instalao em ambiente de produo, de forma a disponibilizar as
funcionalidades concebidas para os seus verdadeiros utilizadores. Esta
tarefa consiste na preparao e instalao do sistema na infra-estrutura
computacional destino e na sua subsequente operao regular. Envolve
um conjunto nem sempre entendido e quantificvel de tarefas, que mui-
tas vezes so esquecidas na altura da preparao do plano do projecto,
tais como:
Configurao e parametrizao do sistema implementado bem como
dos sistemas de suporte requeridos (por exemplo, sistemas de ges-
to de bases de dados, servidores aplicacionais, etc.).
Instalao dos componentes aplicacionais necessrios.
CAPTULO 2 O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 57


Definio de perfis, de utilizadores e de nveis de segurana.
Formao dos utilizadores no sistema.
Elaborao de documentao de operao, administrao e utiliza-
o do sistema.
Definio e implementao de polticas de segurana (por exemplo,
criao de cpias).
Caso exista j um (ou mais) sistemas em funcionamento necessrio
efectuar a migrao para o novo sistema, de acordo com o que foi
definido no plano anteriormente elaborado. Num momento previamente
acordado efectuada a migrao para o novo sistema, passando os uti-
lizadores a partir deste momento a trabalhar no novo ambiente, desig-
nado de produo.
2.5.8 Manuteno
Durante a vida til de qualquer sistema de software so detectados
problemas que no so devidamente verificados durante a fase de
implementao (designados por bugs). Surgem tambm inmeras
solicitaes internas e externas relativamente a pedidos de alterao de
requisitos que no foram contemplados originalmente na fase de
concepo, e que exigem a elaborao de novas verses/actualizaes
do software. Durante o tempo de vida til do software so ainda
detectados problemas que apenas podem ser identificados nesta fase;
esto normalmente relacionados com questes de desempenho do
sistema e apenas se tornam perceptveis com a sua crescente utiliza-
o. A Figura 2.8 mostra a proporo em que estas diversas situaes
ocorrem.
58 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE


Figura 2.8: Percentagem relativa das intervenes que ocorrem durante
a manuteno do software.
O objectivo da tarefa de manuteno de software garantir que a ocor-
rncia de alguma destas situaes convenientemente tratada. Actual-
mente, muitos autores no veem a manuteno como uma tarefa com
actividades prprias, mas sim como o perodo que se inicia imediata-
mente aps a entrada em produo do sistema, e que dura enquanto o
software se mantiver a funcionar. Isto porque as actividades a executar
sobre o sistema fazem de facto parte de outras tarefas j descritas
(anlise, desenvolvimento, testes, etc). Por isso, mais correcto consi-
derar que a manuteno desencadeia uma nova iterao de todo o pro-
cesso de desenvolvimento de software, perspectiva com a qual ns con-
cordamos.
Complementarmente manuteno so realizadas outras actividades
que garantem o bom funcionamento do sistema segundo diversos
critrios, e que tm uma interveno sobretudo a nvel tecnolgico. Es-
tamos a referir-nos ao conjunto de actividades que pode ser generica-
mente designado por operao do sistema, e que inclui, entre outras, a
realizao de cpias de segurana do sistema, a verificao dos par-
metros de desempenho, a definio de novos utilizadores, etc.
CAPTULO 2 O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 59


2.6 Processos de Desenvolvimento de Software
A descrio genrica das fases e tarefas dos processos efectuada na
seco anterior concretizada em modelos em que a sequncia e os
nomes das fases e tarefas assumem diversas especificidades. Indepen-
dentemente das particularidades de cada processo, podemos distingui-
los genericamente segundo duas grandes aproximaes: aqueles que
seguem uma aproximao segundo um modelo em cascata e os que
tm uma aproximao iterativa. Note-se que esta distino ortogonal
ao facto do processo usar uma abordagem estruturada ou orientada por
objectos, conforme se poder verificar pela apresentao a efectuar no
Captulo 3. Pode-se ter, por exemplo, um processo iterativo adoptando
uma abordagem estruturada, ou um processo em cascata adoptando
uma abordagem orientada por objectos, ou qualquer outra combinao.
Enquanto a iteratividade tem a ver com a sequncia das actividades, a
abordagem tem a ver com o paradigma, os conceitos base e a forma de
modelar e solucionar o problema.
2.6.1 Processos em Cascata
Os processos tradicionais de desenvolvimento de software so
caracterizados por adoptarem um modelo em cascata (ver Figura 2.9),
em que as actividades a executar so agrupadas em tarefas, executa-
das sequencialmente, de forma que uma tarefa s tem incio quando a
tarefa anterior tiver terminado.
60 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE


Figura 2.9: Processo em cascata.
O modelo em cascata tem a vantagem que s se avana para a tarefa
seguinte quando o cliente valida e aceita os produtos finais (documen-
tos, modelos, programas) da tarefa actual. Este modelo baseia-se no
pressuposto que o cliente participa activamente no projecto e que sabe
muito bem o que quer. Em situaes de desenvolvimento por uma
empresa de software responsvel pelo projecto existe a garantia, ou
defesa formal, que o cliente aceitou os referidos produtos. De facto, esta
salvaguarda formal d uma significativa proteco empresa de
software quando, como corrente, o cliente vem dizer que afinal no
aquilo que necessita. Mas, infelizmente, esta salvaguarda no evita
que o projecto no obtenha os resultados originalmente esperados, que
o cliente fique desapontado, e que se tenha desperdiado tempo e re-
cursos indevidamente.
O modelo em cascata apresenta ainda outras limitaes. Por exemplo,
promove a compartimentao dos esforos ao longo das diferentes
tarefas e consequentemente desencoraja a comunicao e partilha de
vises entre todos os intervenientes do projecto, por exemplo, entre os
analistas, os responsveis pelo desenho, os programadores, e os
utilizadores. Minimiza o impacto da compreenso adquirida no decurso
de um projecto, uma vez que se um processo no pode voltar atrs de
modo a alterar os modelos e as concluses das tarefas anteriores,
normal que as novas ideias sobre o sistema no sejam aproveitadas.
CAPTULO 2 O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 61


De forma a eliminar este problema foi definido um novo processo,
baseado no modelo clssico em cascata, e designado por modelo em
cascata revisto (ver Figura 2.10), que prev a possibilidade de a partir
de qualquer tarefa do ciclo se poder regressar a uma tarefa anterior de
forma a contemplar alteraes funcionais e/ou tcnicas que entretanto
tenham surgido, em virtude de um maior conhecimento que se tenha
obtido. O risco desta abordagem que, na ausncia de um processo de
gesto do projecto e de controle das alteraes bem definido, podemos
passar o tempo num ciclo sem fim, sem nunca se atingir o objectivo final
que disponibilizar um sistema a funcionar.

Figura 2.10: Processo em cascata revisto.
Ambos os modelos anteriores apresentam o problema da extenso do
perodo de tempo que decorre entre o incio do projecto e a entrega do
produto final, que pela sua durao no corresponde minimamente s
expectativas do cliente. Uma soluo encontrada para resolver parcial-
mente este problema consistiu na aplicao de tcnicas de prototipa-
gem logo no incio do processo, sendo este modelo designado por pro-
totipagem rpida. No elimina a necessidade de todas as restantes
tarefas sequenciais, mas permite que o cliente veja e valide um modelo
da interface (e das funcionalidades) que ir ter disponvel, reduzindo
tambm os problemas da comunicao.
62 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Como no h "rosas sem espinhos", preciso neste caso ter um
cuidado acrescido de forma a no ceder s naturais presses do cliente,
no sentido deste passar a utilizar de imediato o prottipo. que o
prottipo normalmente apenas constitudo por uma sequncia de
ecrs sem quaisquer validaes ou acesso a bases de dados, e a
disponibilizao destas funcionalidades requer tempo e um esforo
significativo. A satisfao da pretenso do cliente significaria comprome-
ter a qualidade do produto em detrimento de "ter qualquer coisa a
funcionar". Existe ainda o perigo de se perder a viso mais global e
abrangente do sistema e respectivas funcionalidades em detrimento de
uma viso mais restrita e imediatista baseada em sequncias de ecrs.
2.6.2 Processos Iterativos e Incrementais
Em contraste com os processos baseados no modelo em cascata, os
processos mais recentes de desenvolvimento de software promovem na
sua generalidade o modelo iterativo e incremental. Com estas ideias
encoraja-se a comunicao entre todos os intervenientes de modo a
produzir sistemas finais mais robustos e com qualidade superior. De
certa maneira, o processo em cascata revisto um precursor destes
processos iterativos.
Iterativo
A noo de processo iterativo corresponde ideia de melhorar (ou
refinar) pouco-a-pouco o sistema. Um excelente exemplo de aplicao
do processo iterativo encontra-se no trabalho artstico, em que o
resultado final de uma obra de arte sofre inmeras iteraes (algumas
das quais, por vezes, destrutivas para o seu resultado final). O mbito
do sistema no alterado, mas o seu detalhe vai aumentando em itera-
es sucessivas.
Para alm desta caracterstica, o desenvolvimento iterativo apresenta
ainda outras vantagens significativas para o desenvolvimento de sof-
tware [Kruchten00]:
Os riscos e dvidas com maior importncia so identificados no
incio do processo, nas primeiras iteraes, quando possvel tomar
medidas para os corrigir.
CAPTULO 2 O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 63


Esta abordagem encoraja a participao activa dos utilizadores de
modo a identificar os verdadeiros requisitos do sistema.
A execuo de testes contnuos e iterativos permite uma avaliao
objectiva do estado do projecto.
As inconsistncias entre a anlise, o desenho e a implementao
so identificadas atempadamente.
O esforo dos diversos elementos da equipa distribudo ao longo
do tempo.
A equipa pode aprender com experincias anteriores e melhorar
continuamente o processo.
Pode ser demonstrado inequivocamente a todos os envolvidos e
interessados no projecto o respectivo avano.
Incremental
A noo de processo incremental corresponde ideia de aumentar
(ou alargar) pouco-a-pouco o mbito do sistema. Uma boa imagem
para este atributo a de uma manso que foi construda por sucessivos
incrementos a partir de uma primeira casa com apenas duas divises.
Iterativo e Incremental
O princpio subjacente ao processo iterativo e incremental (ver Figura
2.11) que a equipa envolvida possa refinar e alargar pouco-a-pouco a
qualidade, detalhe e mbito do sistema envolvido. Por exemplo, numa
primeira iterao deve-se identificar a viso global e determinar a
viabilidade econmica do sistema; efectuar a maior parte da anlise e
um pouco de desenho e implementao. Numa segunda iterao, deve-
-se concluir a anlise, fazer uma parte significativa do desenho, e um
pouco mais de implementao. Numa terceira iterao, deve-se concluir
o desenho, fazer-se parte substancial da implementao, testar e inte-
grar um pouco; etc. Ou seja, a principal consequncia da aproximao
iterativa que os produtos finais de todo o processo vo sendo amadu-
recidos e completados ao longo do tempo, mas cada iterao produz
sempre um conjunto de produtos finais.
64 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE


Figura 2.11: Processo iterativo e incremental.
Existem ainda outras vantagens adicionais dos modelos iterativos e
incrementais, por oposio ao modelo em cascata, e entre estas
podem-se salientar as seguintes: possibilidade de avaliar mais cedo os
riscos e pontos crticos ou mais significativos do projecto, e identificar
medidas para os eliminar ou pelo menos controlar; definio de uma
arquitectura que melhor possa orientar todo o desenvolvimento; disponi-
bilizao natural de um conjunto de regras para melhor controlar os ine-
vitveis pedidos de alteraes futuras; e permite que os vrios interve-
nientes possam trabalhar mais efectivamente pela interaco e partilha
de comunicao da resultante.
Finalmente uma ltima nota. normal encontrarmos na literatura ape-
nas referncias ao termo iterativo, mas em muitas situaes a definio
que lhe est subjacente implica tambm a noo de processo incre-
mental, no sentido que apresentada neste livro.
Espiral
O modelo em espiral uma pequena variante do modelo iterativo e
incremental. Foi proposto por Barry Boehm [Boehm88] como resposta
CAPTULO 2 O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 65


s crticas que os processos existentes na altura no favoreciam a
utilizao de prototipagem e reutilizao de software. Por isso, e para
alm das tarefas e actividades previstas pelos outros processos, prope
logo de seguida tarefa de planeamento a realizao de uma tarefa de
prototipagem e de anlise do risco, como forma de eliminar os principais
problemas e identificar os requisitos do sistema.
2.7 Concluso
O objectivo deste captulo foi o de realar a importncia da aplicao de
mtodos e tcnicas que contribuam para a melhoria do processo de
desenvolvimento de software, nomeadamente a aplicao dos princ-
pios da abstraco e da decomposio hierrquica face complexidade
e dimenso crescentes do software, e a utilizao de um processo de
desenvolvimento uniformizado.
Foram apresentados diversos conceitos relacionados com o processo
de desenvolvimento de software sempre numa perspectiva genrica e
abstracta. Foi o que aconteceu com as definies dos conceitos de
metodologia e processo, e assim como a discusso relativa s noes
de fases, tarefas e actividades. Houve a preocupao de efectuar esta
apresentao sem estar condicionado por nenhuma abordagem meto-
dolgica concreta.
No prximo captulo vamos analisar como que ao longo do tempo
estes conceitos tm evoludo, e perceber o contexto em que surgem as
abordagens orientadas por objectos, e notaes e linguagens de mode-
lao como o caso do UML.

66 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

2.8 Exerccios
Ex.8. "O conceito de metodologia concretiza, pe em prtica, o
conceito terico de processo". Comente esta afirmao.
Ex.9. Indique algumas razes pelas quais a estrutura de um processo
de desenvolvimento tradicional criticada hoje em dia.
Ex.10. Muitas metodologias defendem actualmente a importncia de se
aplicarem sistematicamente tcnicas de controlo de qualidade, e
de se realizarem testes ao longo de todas as fases do ciclo de
vida, e no apenas posteriormente programao. Indique de
que modo que estas actividades podero ser concretizadas
nesses outros momentos.
Ex.11. Indique de que maneira que o desenvolvimento iterativo pode
contribuir para favorecer a aplicao sistemtica de tcnicas de
controlo de alteraes.
Ex.12. Na sequncia das crticas apontadas ao ciclo de vida em
cascata, foi sugerida a aplicao de tcnicas de prototipagem
como forma de ultrapassar esses problemas, o que resultou num
novo ciclo de desenvolvimento. Concorda que, apenas por este
facto, se possa considerar um novo ciclo? Justifique.
Ex.13. Quais as diferenas que existem entre as tarefas de anlise e de
especificao de requisitos? Estas duas tarefas so sempre in-
dependentes uma da outra, ou existem abordagens em que es-
to includas na mesma tarefa?
Ex.14. "O modelo em espiral no traz nenhum valor acrescentado aos
processos iterativos e incrementais". Comente esta afirmao.
Ex.15. Relativamente s tarefas de um processo de desenvolvimento
de software apresentadas na Figura 2.3, existiro situaes em
que algumas possam ser eliminadas? Justifique a sua afirma-
o.



Captulo 3 - EVOLUO DAS METODOLOGIAS
DE DESENVOLVIMENTO DE SOFTWARE
Tpicos
Introduo
A Programao como Fonte de Inovao
Desenvolvimento Ad-Hoc
As Metodologias Estruturadas
As Metodologias Orientadas por Objectos
Outras Metodologias
Comparao de Metodologias
Concluso
Exerccios

3.1 Introduo
No incio dos anos 60, Edsger Dijkstra afirmou que qualquer pedao de
cdigo essencialmente uma srie de instrues de natureza matem-
tica, e como tal possvel provar a sua correco [Dijkstra65]. Posterior-
mente, em 1969 no artigo intitulado Structured Programmming [Dijkstra-
69], ele realou a importncia da preocupao com a preveno de
erros, para alm de utilizar pela primeira vez a expresso "programao
estruturada".
68 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Como j referimos no Captulo 1, a expresso engenharia de software
foi pela primeira vez aplicada em 1967 numa conferncia da NATO, e
em 1971, Niklaus Wirth publicou o artigo "Program Development by
Stepwise Refinement" [Wirth71], com base no trabalho de Edsger
Dijkstra e Barry Bohm [Bohm66], defendendo a ideia da construo de
programas de forma incremental, custa de unidades mais elemen-
tares. Em 1972, David Parnas publicou o seu clebre artigo sobre
encapsulamento de informao [Parnas72], no qual reforava a ideia de
Wirth relativamente importncia de dividir um programa em unidades
mais elementares, cada uma delas apenas disponibilizando um conjunto
de funcionalidades, mas "escondendo" a respectiva implementao.
Todos estes exemplos reforam a importncia de conceitos propostos
desde finais da dcada de 60 e princpios da dcada de 70 e que
tiveram impacto na actividade e tcnicas de programao utilizadas. No
entanto, j em finais dos anos 60 se reconhecia que este esforo no
seria suficiente, e que era preciso rentabilizar o trabalho do programa-
dor atravs de medidas com impacto em reas que no apenas a
programao.
Larry Constantine tentou identificar mecanismos que possibilitassem
que a concepo inadequada de software fosse evitada desde o incio,
aquando da identificao de requisitos. Em conjunto com Wayne
Stevens e Glen Myers props o conceito de Composite Design,
renomeado para "desenho estruturado" [Stevens74], que procurava re-
presentar sob a forma de diagramas as aces de um programa que
posteriormente seriam codificadas. Esta foi uma das primeiras inicia-
tivas no sentido de definir um processo mais consistente e abrangente,
aplicado a todo o ciclo de desenvolvimento de software e cujos concei-
tos foram introduzidos no Captulo 2.
O objectivo deste captulo apresentar, de forma resumida, a evoluo
histrica dos processos de desenvolvimento de software, de forma a
enquadrar e compreender a importncia dos esforos recentes em torno
do paradigma da orientao por objectos e em particular da linguagem
UML. Apresentamos e discutimos com particular relevncia os proces-
sos que adoptam uma abordagem estruturada (Seco 3.4) e orientada
por objectos (Seco 3.5).
PARTE 2 LINGUAGEM DE MODELAO UML 69


3.2 A Programao como Fonte de Inovao
At muito recentemente os principais saltos qualitativos em termos de
conceitos com impacto significativo nas reas abrangidas pela enge-
nharia de software iniciaram-se sempre pela rea das linguagens de
programao.

Figura 3.1: Viso histrica dos mtodos de desenvolvimento de
software.
A Figura 3.1 ilustra a evoluo das principais tcnicas e abordagens que
ao longo do tempo tm ocupado lugar de destaque ao nvel da progra-
mao, consoante o grau de complexidade e da dimenso do software.
De acordo com estes parmetros, podemos identificar quatro fases prin-
cipais.
Num primeiro momento surgiram as linguagens de baixo nvel, muito
prximas da tecnologia e fortemente condicionadas por ela, na qual se
incluem as linguagens mquina, em que as instrues eram meras se-
quncias de bits. A primeira iniciativa no sentido de elevar a actividade
de programao surgiu com o aparecimento das linguagens assembly,
que utilizavam mnemnicas como forma de substituir o cdigo mquina.
70 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

A primeira alterao com impacto deu-se com o aparecimento das
primeiras linguagens simblicas (Fortran, Algol, Cobol), numa tentativa
de aproximar mais as tcnicas de programar do processo de raciocnio
humano. As primeiras linguagens eram utilizadas sobretudo para
clculos cientficos e de engenharia (Fortran), mas gradualmente foram
ganhando peso as linguagens para aplicaes comerciais (Cobol). Eram
linguagens eminentemente imperativas, em que as instrues diziam o
que se fazia. No entanto, a grande ausncia de regras sintcticas e
semnticas possibilitava a construo de programas difceis de
compreender. Data desta altura a expresso "cdigo esparguete", que
resultou da utilizao abusiva da instruo GOTO, e que resulta dos
inmeros saltos que um programa poderia apresentar!). Esta segunda
fase decorreu principalmente durante os anos 1960/70, e caracterizou-
se pelo desenvolvimento de aplicaes razoavelmente simples e de
pequena dimenso, mas em que as ferramentas de apoio eram ainda
relativamente incipientes, e os mtodos de desenvolvimento eram
essencialmente algortmicos.
A terceira fase, que se iniciou durante os anos 70, foi caracterizada pelo
desenvolvimento de sistemas de maior dimenso com base em lingua-
gens estruturadas de mais alto nvel (por exemplo, Pascal, C, 4GL), que
eram suportadas por mtodos estruturados.
Os programas construdos com recurso s linguagens estruturadas
apresentavam uma organizao em blocos de cdigo, constitudos
custa de construes simples (isto , sequncias, seleces e
repeties). O aumento da complexidade e dimenso dos programas
causou graves problemas nas tcnicas de programao, pois os
programas eram constitudos por uma sequncia de blocos de
instrues, todos localizados fisicamente no mesmo ficheiro, o que no
facilitava a decomposio do problema noutros mais elementares nem
suportava adequadamente o trabalho em equipa. O outro grande
problema residia na utilizao abusiva dos dados globais a um
programa, que possibilitavam que todas as instrues de um programa
acedessem a esses dados, tornando difcil perceber quem manipulava
que informao, e dificultando a verificao da consistncia do sistema.
Foi nesse sentido que a linguagem Modula-2 (definida pelo mesmo
autor da linguagem Pascal, Niklaus Wirth, e descrita de forma acessvel
PARTE 2 LINGUAGEM DE MODELAO UML 71


em [Walmsley90]) introduziu o conceito de mdulo, enquanto bloco de
cdigo no qual um programa se poderia decompor. A ideia era agrupar
num mdulo dados e cdigo, que estivessem relacionados de forma a
limitar as interaces entre mdulos invocao de funes. No
entanto era ainda possvel aceder do exterior aos dados declarados
dentro de um mdulo.
De forma a impossibilitar estes acessos, os tericos propuseram o
conceito de tipo de dados abstracto, cuja principal concretizao prtica
ocorreu na linguagem ADA [Booch93]. Estes novos tipos de dados
permitem "esconder" totalmente partes da sua implementao (quer ao
nvel dos dados quer do cdigo), e disponibilizam para o exterior o que
se designa por interface. Pela primeira vez, foi possvel definir uma
associao to forte entre dados e cdigo.
A evoluo dos conceitos referidos nos dois pargrafos anteriores em
termos de abstraco e de encapsulamento da informao conduziu
naturalmente ao aparecimento das linguagens orientadas por objectos
(por exemplo, Smalltalk, C++, Java, Object Pascal). A principal distino
entre os objectos e os tipos de dados abstractos o suporte noo de
herana pelos primeiros, o que no se verifica nos segundos (ver
Seco 3.5). Nesta fase, o desenvolvimento de software ainda mais
complexo e de maior dimenso, o que exige o suporte por parte de
tecnologias avanadas como sejam frameworks aplicacionais, frame-
works de middleware, componentes de software e utilizao de ambien-
tes de desenvolvimento.
Na Figura 3.2 apresentado um modelo simplificado que demonstra a
visibilidade dos dados e como estes se encontram relacionados com o
cdigo, relativamente a cada um dos conceitos acima referidos: (1)
programa, (2) mdulo, (3) tipos de dados abstractos e (4) objectos.
72 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE


Figura 3.2: A evoluo dos conceitos de abstraco nas linguagens de
programao.

Na Figura 3.3 pode ser observado um diagrama que resume a evoluo
das linguagens de programao nos ltimos 40 anos, e onde apenas
representamos as linguagens mais significativas para as abordagens de
desenvolvimento discutidas neste livro. Por isso, no feita qualquer
referncia a outros tipos de linguagens como sejam as relacionadas
com inteligncia artificial (por exemplo, Prolog) ou com processamento
simblico (por exemplo, Lisp).
PARTE 2 LINGUAGEM DE MODELAO UML 73



Figura 3.3: A evoluo das linguagens de programao.
Se ao nvel das linguagens a evoluo ao longo do tempo tem sido
significativa, o mesmo aconteceu em termos de outros conceitos da
engenharia de software, o que vamos analisar de seguida.
3.3 O Desenvolvimento Ad-Hoc
Em face das potencialidades limitadas disponibilizadas ao nvel das
linguagens de programao, e dos restantes componentes de suporte
tecnolgico (computadores, sistemas operativos, tecnologias de arma-
zenamento de informao), as primeiras aplicaes foram construdas
sem a utilizao de uma metodologia de desenvolvimento formal, cor-
respondendo ao que normalmente se designa por "programar e corrigir"
(do ingls "build and fix"). A ateno estava concentrada na progra-
mao e na resoluo das diversas restries de natureza tcnica,
nomeadamente nas capacidades limitadas do hardware da altura. As
profisses por excelncia na rea de informtica eram a do programa-
74 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

dor que desenvolvia e testava os programas e a do operador que os
executava.
Neste perodo, muitas organizaes implementaram sistemas em
ambientes proprietrios, tipo mainframe, utilizando a linguagem Cobol
para programar, e ficheiros para o armazenamento da informao; estes
desenvolvimentos eram caracterizados por:
Envolvimento limitado dos utilizadores.
Identificao de requisitos efectuada de forma inadequada.
Fraca utilizao de tcnicas de anlise e desenho, que quando
muito tinham uma perspectiva ad-hoc e eram de natureza emprica.
Inexistncia de ferramentas de apoio a todo o processo.
Tarefas de desenvolvimento muito demoradas.
Sistemas de acesso informao pouco flexveis.
Esta preocupao tecnolgica implicou que frequentemente os
requisitos dos utilizadores fossem relegados para segundo plano, o que
na altura no constitua um problema demasiado grave, uma vez que as
aplicaes eram simples, limitando-se a substituir (de forma limitada)
tarefas realizadas manualmente por processos automticos. medida
que a complexidade aumentou, tal situao tornou-se cada vez mais
problemtica, o que foi ainda agravado por outras situaes:
Os informticos eram reconhecidamente bons programadores, mas
raramente tinham a preocupao de compreender o negcio e de
utilizar um discurso e expresses aceites e compreendidas por
pessoas no tcnicas. As relaes interpessoais no eram as
melhores e ainda hoje vivemos as consequncias desses primeiros
tempos.
No eram aplicados tcnicas ou mecanismos de controlo e de
gesto de projecto, e por isso estes ultrapassavam frequentemente
custos e prazos estimados.
A fraca qualidade do produto final implicava correces frequentes,
o que justificava o significativo peso relativo das tarefas de
manuteno e a consequente diminuio do tempo disponvel para o
desenvolvimento de novas solues.
Apesar destes problemas todos, o ritmo de adopo de sistemas
informticos foi crescendo, o que s veio reforar a necessidade de re-
PARTE 2 LINGUAGEM DE MODELAO UML 75


ver a abordagem de desenvolvimento seguida de modo a introduzir e
aplicar um processo sistematizado e formalizado de desenvolvimento.
3.4 As Metodologias Estruturadas
Durante os anos 70 e 80 assistiu-se a um importante salto qualitativo
com a introduo de um conjunto de metodologias que se baseavam
essencialmente em tcnicas estruturadas de decomposio funcional.
Estas metodologias tinham por objectivo formalizar o processo de
identificao de requisitos, de modo a reduzir as possibilidades de m
interpretao dos mesmos e introduzir tcnicas baseadas nas melhores
prticas ao processo de anlise e desenho. A designao de metodolo-
gias estruturadas deriva da aplicao de um conjunto de princpios
semelhante ao utilizado pelas linguagens de programao com o ms-
mo nome, nomeadamente o principio da decomposio funcional.
3.4.1 Contexto e Motivao
Foi neste contexto que apareceram pela primeira vez os conceito ciclo
de vida e de metodologias de desenvolvimento de software, com uma
sequncia de fases e actividades, com inputs e outputs, regras, interve-
nientes, tcnicas, notaes, ferramentas, documentao, tcnicas de
gesto, etc, com o objectivo de prestar mais ateno ao processo glo-
bal, e menos programao. A maioria destas metodologias adoptaram
o modelo em cascata, apresentado na Seco 2.6 deste livro, em que
cada actividade tem que ser completada e finalizada antes que a activi-
dade seguinte possa ser iniciada.

As metodologias estruturadas tradicionais estavam essencialmente
orientadas segundo uma de duas abordagens: (1) uma mais orientada
para a decomposio funcional do sistema e a identificao dos respec-
tivos processos; (2) outra mais centrada nos conceitos e nos dados das
organizaes. Estas duas perspectivas so normalmente designadas
por anlise funcional e anlise orgnica.
76 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Na anlise funcional, funes, algoritmos e actividades so a
preocupao central do engenheiro de software, incidindo toda a anlise
nas funcionalidades que o sistema deve realizar e numa fase posterior
na definio de como essas funcionalidades sero implementadas. Esta
abordagem era facilmente concretizada (ou mesmo condicionada) pela
estrutura que as linguagens de programao tradicionais ofereciam,
com base na definio de blocos de cdigo que permitiam algum nvel
de autonomia e de encapsulamento de informao.
No entanto, a possibilidade dos dados serem globalmente visveis e
manipulados por todo o programa (o que era ento permitido pelas
linguagens de programao), reduzia significativamente essas carac-
tersticas. Esta estrutura era pouco flexvel, no sentido da incorporao
de novas funcionalidades e da correco de erros de implementao,
uma vez que alteraes num determinado ponto do programa poderiam
produzir consequncias importantes e no facilmente identificveis nou-
tros pontos do programa.
Na anlise orgnica, a ateno concentra-se nos dados, colocando os
conceitos e as entidades manipuladas no negcio como os elementos
mais importantes do desenvolvimento do sistema. Esta preocupao
incide sobretudo na compreenso e no agrupamento de dados comuns,
e na identificao de relaes entre esses grupos de informao (veja-
se por exemplo a Figura 3.9 e a discusso da Seco 3.7.1
relativamente a este assunto). A ideia que mesmo quando uma aplica-
o muda, os conceitos principais devem permanecer e continuar a ser
utilizados, sem alteraes significativas. A anlise de dados envolve a
recolha, validao e classificao das entidades, atributos e relaes
existentes num determinado domnio do problema.
3.4.2 Conceitos Bsicos
As metodologias estruturadas introduziram um conjunto de conceitos, a
maioria dos quais concretizados em diversos diagramas, dos quais
destacamos os seguintes:
PARTE 2 LINGUAGEM DE MODELAO UML 77


O conceito Processo (de negcio) uma sequncia de
actividades, que processam vrios inputs e produzem vrios
outputs. Cada processo pode ser subdividido em processos mais
elementares at se atingir um nvel que no possvel decompor
mais. uma definio muito semelhante de processo de
desenvolvimento de software, como seria de esperar.
Fluxo de Informao representa toda a circulao (e o respectivo
suporte) de informao que ocorre numa organizao de forma a
executar os processos de negcio.
Repositrio de dados representam os conceitos sobre os quais
importa organizao reter informao para utilizao futura.
Entidade representa todos os conceitos de negcio, entidades
fsicas ou abstractas, internas ou externas organizao, e que so
relevantes para o desempenho adequado da funo da organiza-
o.
Estado de uma entidade representado por um conjunto de
valores que os atributos da entidade podem assumir.
Evento um acontecimento que desencadeado internamente ou
externamente ao sistema, ou pode representar simplesmente a
passagem de tempo, e que despoleta uma mudana de estado.
Os trs primeiros conceitos so exclusivos das abordagens orientadas a
processos, enquanto os trs ltimos (mas sobretudo o quarto) so co-
muns aos mtodos orientados a processos e aos dados.

relativamente fcil a identificao destes conceitos numa situao
concreta, o problema conseguir obter uma descrio (isto , um
enunciado) bem organizada e objectiva dessa situao. Apresenta-se
de seguida um enunciado que descreve o funcionamento da gesto de
compras numa empresa, e nele so identificados os principais proces-
sos que ocorrem (e que se encontram sublinhados). Este exemplo ser
utilizado na Seco 3.4.3 para se clarificar as notaes mais frequentes
nestas metodologias.

78 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Pensemos no caso da gesto de compras de materiais de uma empre-
sa. Sempre que algum funcionrio tem necessidade de comprar bens
para as suas actividades, este preenche uma requisio, onde identifica
os bens em questo (com base na consulta de uma lista anteriormente
disponibilizada a todos os funcionrios), a qual envia para o seu direc-
tor. Este, depois de analisar o pedido, pode ou no autorizar o mesmo.
Neste segundo caso, o requisitante recebe uma notificao, e o proces-
so pra. No caso do pedido ser aprovado, o requisitante preenche uma
encomenda que envia para o fornecedor por ele seleccionado.
A entrada dos bens ocorre sempre no armazm, onde conferido o
material recebido com a guia de remessa que o acompanha, bem como
a(s) encomenda(s) que lhe deram origem (uma encomenda pode ser
satisfeita de vrias vezes). Aps a ltima entrega, que completa a
encomenda, a empresa confere a factura que entretanto lhe foi sido
enviada, relaciona-a com as encomendas respectivas, e se tudo estiver
correcto, emitido um meio de pagamento ao fornecedor (poder ser
em cheque ou por transferncia bancria).
No enunciado anterior encontram-se destacados os processos de
negcio referidos. Este conceito de processo de negcio , normal-
mente, o mais relevante no caso das metodologias estruturadas: os
processos so os primeiros a ser identificados e conduzem toda a an-
lise e especificao posterior.
3.4.3 Tcnicas e Notaes mais Utilizadas
As metodologias estruturadas propuseram diversos tipos de notaes,
sendo de destacar as seguintes representaes grficas e no-grficas:
Diagramas de fluxo de dados (data flow diagram): so
especificaes orientadas aos processos, em que se identificam
graficamente processos, entidades externas, fluxos de informao e
repositrios de dados. So os principais diagramas utilizados na
modelao de processos. Estes diagramas podem ser construdos
em vrios nveis, uma vez que existe a possibilidade de especificar
um processo atravs de um diagrama de maior detalhe. O diagrama
de fluxo de dados de primeiro nvel nalgumas metodologias
designado por diagrama de contexto.
PARTE 2 LINGUAGEM DE MODELAO UML 79


Diagramas entidade associao (entity relarionship diagram): so
especificaes grficas que representam as relaes estticas de
um sistema, designadamente as entidades, com os seus atributos, e
a forma como estas se encontram associadas.
Diagrama de transio de estados (state transition diagram):
uma representao grfica dos estados em que um sistema ou uma
entidade se pode encontrar ao longo da sua existncia, e dos
eventos que desencadeiam as transies entre estados.
Diagrama do ciclo de vida de entidade (entity life cycle): consiste
numa verso adaptada de um diagrama de estados, em que o
objectivo descrever a evoluo de uma entidade ao longo da sua
existncia, designadamente as operaes de criao, alteraes
significativas e eliminao do sistema.
Dicionrios de dados: so repositrios de definies de todos os
elementos e conceitos utilizados e manipulados pela organizao e
respectivos sistemas de informao e que incluem entre outros os
dados, ficheiros, processos e entidades.
Matrizes entidade-processo: so matrizes que demonstram as
relaes existentes entre as entidades e os processos, isto ,
permitem identificar que entidades intervm em que processos.
Fluxogramas: diagramas que expressam os passos de execuo
de algoritmos e processamentos realizados no sistema.

ainda de referir a tcnica da Normalizao, que consiste num
processo de construo do esquema de uma base de dados a partir da
lista de entidades e dos respectivos atributos, aplicando um conjunto de
regras designadas por formas normais do modelo relacional, cuja
preocupao eliminar redundncias na estrutura de dados e garantir a
integridade da informao. Para mais detalhe aconselhamos o leitor
interessado a consultar [Silberschatz98].
O elevado nmero de metodologias disponveis no mercado fez com
que a simbologia utilizada variasse normalmente conforme a metodolo-
gia adoptada. Por exemplo, na Figura 3.4 podemos observar como o
mesmo conceito "processo" representado por smbolos grficos dis-
tintos, conforme as metodologias de Yourdon e SSADM.
80 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE


Figura 3.4: "Processo" representado diferentemente segundo as
notaes de Yourdon e SSADM.
A Figura 3.5 ilustra como o enunciado da gesto de compras pode ser
representado atravs de um diagrama de fluxo de dados segundo a
notao de Yourdon. Nele podemos observar os processos (represen-
tados por ovais), as entidades intervenientes (rectngulos), os reposit-
rios de dados (rectngulos abertos lateralmente) e os fluxos de informa-
o (setas).

Figura 3.5: Diagrama de fluxo de dados do problema de gesto de
compras.
PARTE 2 LINGUAGEM DE MODELAO UML 81


Na figura anterior, poderamos representar alguns processos com um
nvel de detalhe superior, e para isso j dispomos de informao no
enunciado. Por exemplo, no caso do processo registo da requisio
(1.1), o respectivo detalhe poderia incluir, e por esta ordem, a deteco
da necessidade, a consulta lista de bens disponveis, o preenchimento
da requisio, e o envio para o director. Esta informao seria tambm
adequadamente representada por um diagrama de fluxo de dados, de
nvel mais detalhado.
Outro tipo de diagrama muito utilizado na literatura o diagrama
entidade associao (entity relationship diagram), que apresenta a viso
esttica do sistema, identificando as entidades sobre as quais interessa
guardar informao, bem como o respectivo relacionamento. Na Figura
3.6 apresentamos o que poderia ser um diagrama deste tipo para o
caso do problema da gesto de compras.
Qualquer relao expressa num diagrama entidade associao pode
ser sempre analisada na perspectiva de ambas as entidades
intervenientes, e implica a sua caracterizao segundo dois conceitos
adicionais: a cardinalidade (nmero mximo de ocorrncias de cada
uma na relao) e modularidade (nmero mnimo de ocorrncias de
cada uma, o que nos permite identificar quais so obrigatrias ou
opcionais). Por exemplo, na relao entre "requisies" e "encomendas"
do exemplo anterior, a cardinalidade desta relao, representada pelos
smbolos mais prximos de cada rectngulo, l-se "uma requisio pode
ser satisfeita por vrias encomendas"; a modularidade pode ser lida
"podemos ter uma requisio que no d origem a nenhuma
encomenda" ( o caso em que o director no aprova o pedido).
82 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE


Figura 3.6: Diagrama entidade associao para o exemplo da gesto de
compras.
Estes diagramas melhoraram o rigor da especificao, uma vez que
foram definidas algumas regras s quais necessrio obedecer na sua
elaborao. Adicionalmente, a representao grfica dos conceitos
facilitou a sua compreenso por todos os intervenientes no processo
(utilizadores e informticos). No entanto, continuam a apresentar algum
grau de subjectividade, at porque normalmente prevem a utilizao
de descries em linguagem natural para complementar a modelao
efectuada. Alm disto, a utilizao de alguns termos e smbolos j muito
prximos da tecnologia dificultou por vezes a compreenso dos diagra-
mas por parte de participantes no tcnicos.
Os diagramas at agora apresentados incluem-se no grupo das
notaes semi-formais, uma vez que tinham um conjunto de regras
associadas, e que deviam ser aplicadas na sua elaborao. No entanto,
no era possvel atravs destes diagramas garantir e demonstrar a
respectiva correco, face s funcionalidades identificadas. No sentido
de resolver este tipo de problema, foram propostas notaes formais,
que se caracterizam por adoptar conceitos muito prximos da matem-
tica, com o rigor e formalismo correspondentes, sendo deste modo
possvel demonstrar a correco da especificao, o que relevante
PARTE 2 LINGUAGEM DE MODELAO UML 83


num nmero restrito, mas importante, de domnios de aplicao como
seja a medicina, indstria militar ou a aeronutica. Algumas notaes
mais conhecidas so:
Redes de Petri: diagramas particularmente adequados para a
representao de sistemas com problemas de concorrncia e com
restries a nvel de sincronizao; utiliza conceitos como
transies, funes de input e de output [Leveson87].
Linguagem Z: linguagem de especificao formal, com simbologia e
conceitos matemticos e lgica de primeira ordem (conjuntos, tipos
de dados, constantes, definies de estado, estado inicial,
operaes) [Spivey88].
Sai fora do mbito deste livro aprofundar a aplicao das tcnicas
referidas. Para o leitor mais interessado aconselhamos a leitura da
bibliografia recomendada.
3.4.4 Principais Metodologias
Foi referido no Captulo 2 que o nmero de metodologias propostas
para o desenvolvimento de software atingiu um nmero demasiado ele-
vado, o que torna virtualmente impossvel a sua apresentao em qual-
quer livro. Por isso, enumeramos de seguida algumas das metodologias
estruturadas conhecidas que maior relevncia e divulgao tiveram.
Para alm destas, existiram outros contributos importantes que no
inclumos aqui por no apresentarem uma perspectiva integrada de todo
o processo de desenvolvimento, mas apenas sugerirem notaes ou
tcnicas de modelao. o caso, por exemplo, das propostas de Tom
DeMarco [DeMarco78] e de Meiler Page-Jones [Page-Jones80].

SSADM
A metodologia mais divulgada e que alcanou maior sucesso foi o
SSADM (Structured Systems Analysis and Design Methodology),
proposta em 1981 por Learmonth, e alvo de sucessivas revises, a
ltima das quais em meados da dcada de 90, com o aparecimento da
verso 4+ [Weaver98]. Durante muito tempo (e ainda hoje) foi conside-
84 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

rada a metodologia de referncia e ensinada em diversos cursos
universitrios. No Reino Unido, foi durante muito tempo obrigatria a
sua utilizao em todos os projectos relacionados com o desenvolvi-
mento de sistemas de informao a nvel governamental.
O SSADM prope a modelao de um sistema segundo trs perspec-
tivas complementares: (1) a sua funcionalidade; (2) a sua estrutura; e
(3) a sua evoluo ao longo do tempo. A primeira representada
atravs de diagramas de fluxo de dados (DFD), a segunda obtida
atravs de diagramas de entidade associao (DEA) e a terceira pelos
diagramas de ciclos de vida de entidades. Estas trs vises so
integradas; por exemplo, os DFD so comparados com os DEA, de
forma a garantir que cada entidade referida num DEA criada por
algum processo especificado num DFD.
uma metodologia concebida sobretudo para a anlise e desenho do
sistema, no contemplando as tarefas relacionadas com a implemen-
tao, testes e instalao do mesmo. Integra diversas notaes orienta-
das quer para a modelao dos processos quer dos dados. A sequncia
de actividades envolve:
A realizao de um estudo de viabilidade, de modo a avaliar at que
ponto o sistema tem custos aceitveis.
A anlise de requisitos do negcio.
A especificao dos mesmos requisitos.
A especificao lgica do sistema, de modo a determinar a forma
como os requisitos identificados so implementados.
O desenho fsico do sistema.
Para o leitor mais interessado aconselhamos uma leitura da referncia
anteriormente indicada.
STRADIS
Stradis (Structured analysis, design and implementation of information
systems) foi uma metodologia desenvolvida por Gane e Sarson em
finais da dcada de 70 [Gane82], baseada na filosofia de decomposio
funcional top-down, e suportada essencialmente pela utilizao de
diagramas de fluxos de dados.
PARTE 2 LINGUAGEM DE MODELAO UML 85


Yourdon Systems Method
Yourdon Systems Method, uma metodologia proposta por Edward
Yourdon, revista em 1993 e descrita com algumas actualizaes em
[Yourdon99]; semelhante Stradis pois recorre muito decomposio
funcional, mas tambm atribui uma importncia significativa estrutura
dos dados.
Engenharia de Informao
A "Engenharia de Informao", proposta por James Martin em 1989
[Martin89], integra muitos dos conceitos, melhores prticas, modelos e
tcnicas das metodologias estruturadas e do desenvolvimento de
software dos anos 80 numa abordagem coerente a todas as actividades
do processo de desenvolvimento de software. As suas razes esto no
trabalho originalmente desenvolvido pela IBM na sua metodologia
Business Systems Planning.
Ao contrrio das outras, a Engenharia da Informao tem uma
preocupao estratgica com a definio dos sistemas de informao, o
que expresso nos diferentes estgios de evoluo do processo desig-
nadamente: (1) planeamento estratgico dos sistemas de informao;
(2) anlise de reas do negcio; (3) desenho de sistemas e (4) imple-
mentao.
86 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

3.5 Metodologias Orientadas por Objectos
As tcnicas e metodologias estruturadas descritas na seco anterior
apresentam vrios problemas, entre os quais podemos destacar:
No conseguem lidar adequadamente com o problema da comple-
xidade e do tamanho crescente dos sistemas.
No resolvem o problema da crescente actividade de manuteno
do software.
Verifica-se com frequncia a m compreenso dos requisitos do
utilizador, por parte dos intervenientes tcnicos.
Permanece a dificuldade de lidar com alteraes aos requisitos.
A integrao e reutilizao de mdulos e componentes do sistema
no so fceis.
Os erros de concepo so descobertos tardiamente.
A qualidade do software baixa e o seu desempenho inadequado.
No fcil identificar quem fez o qu, quando e porqu.
A aplicao de diversas das melhores prticas actuais de engenharia de
software (ver Seco 2.4) veio solucionar algumas destas questes e
esteve na origem do conceito da orientao por objectos. No entanto,
importante reforar a ideia de que em muitos casos essas melhores
prticas podem ser seguidas independentemente de se utilizarem mto-
dos estruturados ou orientados por objectos.
A orientao por objectos, se bem que em termos prticos tenha sido
primeiramente concretizada ao nvel das linguagens de programao,
no tem impacto apenas a esse nvel. O conceito da orientao por
objectos (OO ou O-O, do ingls object-oriented) baseia-se de facto
numa nova forma de analisar o mundo. A abordagem seguida "repro-
duz" a forma como o ser humano se apercebe e expressa a realidade
que o rodeia. Ele classifica e subdivide o mundo em diferentes objectos,
com base nas diferenas e semelhanas existentes ao nvel das
caractersticas e comportamento dos mesmos objectos. As tcnicas
orientadas por objectos identificam e definem cada objecto de modo a
reutiliz-lo, da mesma forma que o ser humano acumula conhecimento
com base no previamente adquirido.
PARTE 2 LINGUAGEM DE MODELAO UML 87


Nas abordagens orientadas por objectos, a perspectiva de modelao
dos sistemas muda, uma vez que o mesmo conceito base utilizado ao
longo de todas as fases do processo, promovendo a reutilizao e o
encapsulamento da informao, e facilitando a manuteno.
As metodologias orientadas por objectos so por isso encaradas como
uma das mais recentes panaceias (ou silver bullets, segundo Brooks
[Brooks86]) para resolver os problemas do desenvolvimento de sof-
tware, uma vez que so abordagens mais naturais que as baseadas em
processos e dados, e os conceitos bsicos so simples e reproduzem o
mundo real.
A definio exacta do que se entende por orientao por objectos tem
motivado largas discusses ao longo das ltimas duas dcadas, e
recomendamos a leitura de algumas referncias ([Berard93], [Taylor90],
[Stroustrup88] e [Booch86]) para um melhor esclarecimento sobre este
assunto. No entanto, pensamos que uma das vises mais simplificadas
at hoje apresentada, e que expressa adequadamente o conceito foi
elaborada por Coad e Yourdon em 1991 [Coad91], e indicava que o
paradigma da orientao por objectos resultava da convergncia de
quatro outros conceitos, que sero definidos em seces mais frente:
objectos, classificao, herana e comunicao por mensagens.
3.5.1 Contexto e Motivao
As razes da engenharia de software orientada por objectos podem ser
encontradas no trabalho inicialmente desenvolvido na linguagem Simula
[BirtWhistle79] em finais dos anos 60, que como o nome indica, estava
particularmente vocacionada para a implementao de sistemas de si-
mulao.
Desde o incio dos anos 70 que trs ideias independentes ganharam
importncia, com o objectivo de facilitar todo o processo de
desenvolvimento de software, e que em ltima anlise esto na base da
estrutura de conceitos do paradigma da orientao por objectos.
Estamos a referir-nos aos conceitos de encapsulamento de informao,
de reutilizao de cdigo e da viso do mundo (e posterior modelao)
segundo um conjunto de objectos, e no segundo uma perspectiva
88 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

funcional. Estes conceitos esto na base da primeira linguagem
classificada como verdadeiramente suportando este paradigma, a
linguagem Smalltalk [Goldberg89], concebida nos laboratrios PARC da
Xerox. No entanto, e at meados da dcada de 80, a maioria das
iniciativas relacionadas com o paradigma da orientao por objectos
situava-se ao nvel da programao.
Tal como descrito no seu livro Object-Oriented Analysis [Coad91],
Peter Coad e Edward Yourdon identificam as motivaes principais para
a realizao de actividades de anlise segundo o paradigma da
orientao por objectos:
Poder tratar domnios de problemas mais complexos.
Melhorar a interaco entre o analista e o especialista do problema.
Aumentar a consistncia interna dos resultados da anlise.
Representar explicitamente aspectos comuns a diversos conceitos.
Construir especificaes capazes de resistir mudana.
Reutilizar resultados da anlise.
Conceber uma representao consistente para a anlise e desenho.
3.5.2 Conceitos Bsicos
As abordagens orientadas por objectos so muito ricas em termos da
terminologia utilizada. Podemos distinguir essencialmente dois grandes
grupos de conceitos: (1) os princpios, que constituem um conjunto de
ideias base de todo o paradigma, e alguns deles so mesmo os
requisitos necessrios para um sistema ser considerado orientado por
objectos; (2) e as restantes noes base, comuns a todos os sistemas
orientados por objectos.
PARTE 2 LINGUAGEM DE MODELAO UML 89


Princpios Orientadores do Paradigma
No grupo dos princpios orientadores e que definem o paradigma pode-
mos incluir os seguintes conceitos:
Encapsulamento da informao o processo de "esconder" todos
os detalhes de um objecto que no contribuem para as suas
caractersticas essenciais nem para a disponibilizao de funcio-
nalidades para o seu exterior. Pode ainda ser encarado como a
localizao de funcionalidades numa nica abstraco auto-contida,
que esconde a respectiva implementao e decises de desenho,
atravs da disponibilizao de uma interface pblica. O conjunto de
operaes que so acessveis do exterior constitui a interface do
objecto. Esta caracterstica permite a criao de objectos estveis e
reutilizveis, reproduzindo o mundo real de forma correcta.
Herana representa a definio de relaes entre classes atravs
da qual uma subclasse partilha, acrescenta ou redefine operaes e
atributos a partir de uma ou mais superclasses; uma subclasse
uma especializao de uma ou mais superclasses. uma forma de
aumentar a reutilizao do que comum, permitindo adicionalmente
acrescentar detalhes especficos. Este termo aparece associado s
noes de generalizao e de especializao.
Polimorfismo a capacidade de "esconder" vrias implementaes
distintas atravs de uma nica interface. Outra forma de definir esta
propriedade dizer que ela representa a capacidade de objectos
diferentes responderem de forma diferente mesma mensagem. Tal
concretizado pelo facto de uma operao aceitar argumentos de
tipos diferentes ou mesmo desconhecidos. utilizada em situaes
em que uma operao partilhada na maior parte dos casos, mas
em que pelo menos uma subclasse necessita de uma verso
especfica.
Abstraco a representao concisa duma ideia ou objecto mais
complexa, incidindo sobre as caractersticas essenciais do objecto.
As abordagens tradicionais concretizam esta ideia pelas abs-
traces funcionais (processos), enquanto os mtodos orientados
por objectos utilizam objectos.

90 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Os quatro princpios anteriores so considerados necessrios e sufici-
entes para considerar uma linguagem como sendo orientada por objec-
tos; aquelas que no suportam as noes de herana e/ou polimorfismo
so normalmente designadas por baseadas em objectos. Para alm
destes, existem ainda outras noes importantes:
Modularidade a decomposio lgica e fsica de conceitos em
unidades mais elementares, de forma a facilitar a aplicao dos
princpios da engenharia de software.
Concorrncia a propriedade que distingue um objecto activo de
outro no activo.
Persistncia a propriedade de um objecto atravs da qual a sua
existncia perdura no tempo e/ou no espao.
Outros Conceitos Chave do Paradigma da Orientao por
Objectos
Para alm dos princpios que funcionam como as grandes linhas
orientadoras do paradigma da orientao por objectos, existem outros
conceitos que so fundamentais para a boa compreenso do mesmo,
nomeadamente os conceitos de objectos e classes, para alm de outros
que esto directamente relacionados com estes.
O conceito bsico obviamente o de objecto, para o qual no existe
uma definio nica. Pelo contrrio, praticamente cada metodologia e
respectivo autor apresentam definies prprias, como se pode
observar de seguida:
Firesmith [Firesmith96]: um objecto pode ser definido como uma
abstraco de software que modela todos os aspectos relevantes de
uma nica entidade conceptual ou tangvel, que pertence ao
domnio da soluo.
Object Management Group: um objecto uma coisa, criada como
uma instncia de um tipo de objectos. Cada objecto tem uma
identidade nica distinta e independente de quaisquer das suas
caractersticas. Cada objecto tem uma ou mais operaes.
Berard [Berard93]: objectos so as entidades reais ou conceptuais
que podem ser encontradas no mundo que nos rodeia.
Booch [Booch94]: algo ao qual se pode fazer qualquer coisa; tem
estado, comportamento e identidade.
PARTE 2 LINGUAGEM DE MODELAO UML 91


Coad e Yourdon [Coad91]: uma abstraco de qualquer coisa no
domnio de um problema, reflectindo a capacidade do sistema de
manter informao sobre ele e de interagir com ele; um
encapsulamento de valores de atributos e dos seus servios
exclusivos.
Rumbaugh [Rumbaugh91]: um objecto um conceito, abstraco ou
coisa com fronteiras bem definidas e com significado para o
problema em questo; promove a reutilizao e funciona como uma
base concreta para a respectiva implementao em software.
Shlaer e Mellor [Shlaer88]: um objecto uma abstraco de um
conjunto de coisas do mundo real de tal forma que todos os
elementos do conjunto (instncias) tm as mesmas caractersticas e
respeitam as mesmas regras e polticas.
Resumidamente, e de forma a integrar estas diversas definies,
podemos dizer que os objectos representam entidades fsicas,
conceptuais ou apenas necessrias para a representao em computa-
dor (por exemplo, estruturas de dados); um objecto pode ser um concei-
to, uma abstraco ou uma entidade, com fronteiras bem definidas e
que tem um significado para um problema e respectiva soluo; um
objecto tem estado, comportamento e identidade.
Alguns autores enumeram as fontes onde pesquisar os possveis
candidatos a objectos, independentemente do problema a solucionar:
Shlaer e Mellor: entidades e coisas tangveis, funes de pessoas,
organizaes, incidentes, eventos, interaces, especificaes.
Coad e Yourdon: estruturas, outros sistemas, dispositivos, coisas ou
acontecimentos memorizados, funes desempenhadas, procedi-
mentos operacionais, locais geogrficos, unidades organizacionais.
Os atributos so propriedades nomeadas de um objecto que indicam
os valores possveis que esse atributo pode assumir ao longo do tempo;
o estado de um objecto definido pelo valor dos seus atributos.
O comportamento de um objecto definido como o conjunto de
aces que um objecto pode realizar de forma independente.
Normalmente existem dois termos para referir os mecanismos utilizados
para implementar este conceito: ao nvel da anlise o termos mais
utilizado o de operao ou servio, enquanto o termo mtodo se
92 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

refere normalmente implementao de uma operao ao nvel da
programao. A maioria das operaes realizadas responde a pergun-
tas ou alteram o estado do objecto. Na prtica, implementam um servio
e/ou funcionalidade que pode ser requerido por qualquer objecto que
faa parte do universo do problema.
Para melhor compreendermos os conceitos de estado e de comporta-
mento, utilizemos o exemplo de uma conta bancria. Neste caso, o seu
estado determinado pelos valores assumidos pelos atributos que so
necessrios para a caracterizar - titular, saldo - enquanto que o seu
comportamento determinado pelos servios que disponibiliza para
outros objectos interagirem com ela, nomeadamente depositar dinheiro,
levantar dinheiro e consultar o saldo da conta.
As classes so descries de grupos de objectos com propriedades
(atributos), comportamento (operaes) e relaes comuns. uma das
concretizaes do conceito abstraco no paradigma da orientao por
objectos. Uma classe pode ser vista como template para um determi-
nado objecto e todos os que lhe forem semelhantes, ou como uma
fbrica, que produz tantos objectos idnticos quanto necessrio.
Em geral, os atributos permitem identificar a classe, definir as
caractersticas especiais da classe, definir o estado da classe, reter
alguma informao sobre a classe e identificar o comportamento do
objecto. Para especificar detalhadamente um atributo deve-se identificar
o domnio dos seus valores, as unidades de medida, o valor por omis-
so, o valor inicial, as condies de leitura e escrita e eventuais condi-
es relacionadas com outros atributos do objecto ou da classe.
Dado um enunciado de um problema, a anlise orientada por objectos
procura identificar os objectos concretos e as respectivas classes, a
partir de todos os substantivos que dele sejam extrados. O seu objec-
tivo ltimo ser sempre identificar:
Um conjunto de classes que representem totalmente o domnio do
problema.
Os atributos de cada classe.
A interface e os servios de cada classe.
As diversas relaes entre classes.
Objectos concretos que seja necessrio particularizar.
PARTE 2 LINGUAGEM DE MODELAO UML 93


Cada metodologia prope diferentes formas de chegar a esta
informao, e normalmente referem alguns critrios. Por exemplo,
[Coad91] indica um conjunto de questes a colocar, de modo a averi-
guar se um substantivo do enunciado constitui um objecto ou classe:
A informao sobre o objecto tem que ser retida de modo a que o
sistema funcione adequadamente?
O objecto realiza operaes que alteram atributos de outros objec-
tos?
O objecto tem mais do que um atributo?
Outros objectos aparentemente idnticos disponibilizam operaes
idnticas?
O objecto produz ou consome informao essencial para o funciona-
mento do sistema?
Noutras situaes, so indicadas checklists de circunstncias em que
um potencial objecto no o deve ser, por exemplo:
Objectos ou classes com apenas um atributo.
Classes com apenas um objecto.
Objectos ou classes sem servios aplicveis, ou que no produzem
um resultado visvel para o problema em anlise.
Objectos ou classes que no sejam relevantes para a soluo do
problema.
Objectos ou classes que de facto correspondem a atributos de
outros objectos.
Se considerarmos novamente o enunciado do exemplo da gesto de
compras, podemos verificar que a nossa pesquisa passa a incidir sobre
outras palavras (substantivos em vez de verbos), devido mudana de
paradigma e aos conceitos base fundamentais que lhes esto subjacen-
tes (objectos em vez de processos).
94 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Pensemos no caso da gesto de compras de materiais de uma
empresa. Sempre que algum funcionrio tem necessidade de comprar
bens para as suas actividades, este preenche uma requisio onde
identifica os bens em questo (com base na consulta de uma lista
anteriormente disponibilizada a todos os funcionrios), a qual envia para
o seu director. Este, depois de analisar o pedido, pode ou no autorizar
o mesmo. Neste segundo caso, o requisitante recebe uma notificao, e
o processo pra. No caso do pedido ser aprovado, o requisitante
preenche uma encomenda que envia para o fornecedor por ele selec-
cionado.
A entrada dos bens ocorre sempre no armazm, onde conferido o
material recebido com a guia de remessa que o acompanha, bem como
a(s) encomenda(s) que lhe deram origem (uma encomenda pode ser
satisfeita de vrias vezes). Aps a ltima entrega, que completa a
encomenda, a empresa confere a factura que entretanto lhe foi sido
enviada, relaciona-a com as encomendas respectivas, e se tudo estiver
correcto, emitido um meio de pagamento ao fornecedor (poder ser
em cheque ou por transferncia bancria).

As operaes realizadas por objectos podem ser identificadas pela
pesquisa no enunciado do problema de verbos associados a cada ob-
jecto. Essas operaes podem ser agrupadas nas seguintes categorias:
Modificadores: operao que altera o estado de um objecto.
Selectores: operao que acede ao estado de um objecto.
Iteradores: operao que permite que todas as partes de um objecto
sejam acedidas segundo uma ordem bem definida.
Construtor: cria um objecto e/ou inicializa o seu estado.
Destrutor: liberta o estado de um objecto ou destri-o.
Os objectos funcionam como caixas negras, isto porque "escondem" os
detalhes da sua implementao aos objectos que a utilizam; o acesso
aos objectos efectuado atravs da interface por eles disponibilizada,
composta por operaes e por atributos. Os objectos comunicam entre
PARTE 2 LINGUAGEM DE MODELAO UML 95


si por mensagens, que no so mais do que a invocao de um mtodo
com o mesmo nome, no contexto do objecto receptor da mensagem.

Figura 3.7: Modelo de comunicao entre objectos por mensagens.
Na prtica, este modelo no mais do que a invocao de uma funo,
tal como nas abordagens tradicionais; a diferena que esta invocao
realizada no contexto de um objecto, o que significa que tem em conta
o seu estado, traduzido nos valores que os seus atributos assumem.
Por isso, o mesmo mtodo executado com os mesmos parmetros
sobre objectos diferentes, mas ambos instncias da mesma classe,
pode produzir resultados diferentes, como se verifica no exemplo se-
guinte.

Classe classeA
{
public:
int x;
int y;
int soma() { return (x + y ) ;}
}
...
classeA a;
classeA b;
a.x = 10 ;
a.y = 20 ;
96 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

b. x = 5 ;
b.y = 8 ;

...
a.soma => obtem-se o valor 30
b.soma => obtem-se o valor 13

Este conceito de comunicao por mensagens pode ser visto de forma
to abstracta que mesmo a soma de dois nmeros pode ser encarada
como uma operao de envio de uma mensagem a um objecto. Por
exemplo na operao 3 + 4, 3 o objecto receptor da mensagem, que
formada pelo selector + (que identifica o mtodo a invocar no objecto
receptor) e pelo objecto argumento 4. Uma mensagem sempre
formada por um selector e opcionalmente por um conjunto de parme-
tros.
A interface o conjunto de operaes e atributos disponibilizados por
uma classe, que consoante a visibilidade se pode dividir em trs partes:
pblica (visvel para todos os objectos do sistema); protegida (s visvel
pelas suas subclasses); privada (faz parte da interface mas no visvel
para nenhuma outra classe do sistema, s est disponvel na implemen-
tao da prpria classe).

Figura 3.8: Visibilidade de mtodos da interface.
PARTE 2 LINGUAGEM DE MODELAO UML 97


Entre as diversas classes de um sistema podem ser estabelecidas
diferentes tipos de relaes:
Associao: representam relaes estruturais entre objectos de
classes diferentes, e cuja informao que tem que ser preservada
durante algum tempo; expressa pelo verbo ter; podem-se sub-
dividir em
Agregao: a conhecida relao entre o todo e as partes (whole-
part); um exemplo possvel a relao "uma empresa tem empre-
gados".
Composio: forma de agregao em que a relao de pertena
forte e com tempos coincidentes; o objecto agregador responsvel
pela criao e destruio do objecto que entra na sua composio;
uma concretizao desta relao dizer que "o corpo humano tem
uma perna".
Dependncia: relao em que uma mudana de estado num
objecto (ocorrida pela recepo de uma mensagem) pode implicar o
envio de uma mensagem a outro objecto; por exemplo, um autom-
vel, para andar, precisa de se abastecer na bomba de gasolina.
Generalizao/Especializao: relaes entre classes que
partilham a estrutura e comportamento; implementam o conceito de
herana, que pode ser simples (uma classe tem apenas uma
superclasse) ou mltipla (uma classe pode ter vrias superclasses);
esta relao expressa pelo verbo ser, como no caso "um co um
animal".
Algumas abordagens orientadas por objectos procuram definir conceitos
que permitem agrupar classes; por exemplo, Wirfs-Brock considerou
que um sub-sistema um conjunto de classes (ou de outros sub-
sistemas) que colaboram entre si para realizar um conjunto de
responsabilidades. No existem na prtica, mas permitem a criao de
entidades conceptuais teis. Coad e Yourdon definem o conceito de
assunto (subject) de forma idntica. NO caso do UML, o utiliza-se o
conceito de pacote com um fim idntico. O principal objectivo deste tipo
de conceitos facilitar a compreenso da globalidade do sistema, ao
agrupar outros conceitos relacionados.
98 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

3.5.3 Tcnicas e Notaes mais Utilizadas
A proliferao das metodologias que tinham como base os conceitos da
orientao por objectos levou ao aparecimento de diversas notaes e
tcnicas de modelao, que muitas vezes so partilhadas entre vrias
delas. Os recentes esforos de unificao permitiram que algumas des-
sas tcnicas se tenham destacado.
As principais notaes utilizadas esto praticamente todas presentes na
metodologia da Rational, e fazem parte da linguagem de modelao
UML, pelo que sero apresentadas detalhadamente nos captulos que
constituem a Parte 2 deste livro. Resumidamente, indicamos de seguida
as principais notaes a considerar:
Diagrama de casos de utilizao
Diagrama de classes
CRC (Class-Relationship-Collaboiration) cards
Diagrama de pacotes
Diagrama de estados
Diagramas de interaco
Diagrama de actividades
Diagrama de eventos
Diagrama de contexto
Diagrama de fluxo de dados.
Independentemente dos nome dos diagramas utilizados por cada
metodologia, cada uma apresenta notaes para modelar a viso
esttica do sistema (a estrutura dos objectos, relaes de agregao e
de especializao, e a comunicao entre objectos) e outras notaes
para os conceitos dinmicos (interaces, mudanas de estado, se-
quncias de aces e mecanismos de temporizao).
PARTE 2 LINGUAGEM DE MODELAO UML 99


3.5.4 Principais Metodologias
Ao longo das dcadas de 1980 e de 1990 surgiram inmeras propostas
de metodologias, sobretudo concentradas nas tarefas de anlise e
desenho, utilizando os conceitos relacionados com o paradigma da
orientao por objectos. Sem pretender ser exaustivo, enumeramos de
seguida algumas das metodologias mais significativas, quer pela sua
utilizao, quer pela relevncia dos conceitos abordados.
Mtodo de Booch
O mtodo Booch foi proposto por Grady Booch em 1991 (cujo livro de
referncia teve uma segunda edio em 1994 [Booch94]), e baseia-se
na ideia da repetio de actividades de um processo de desenvolvi-
mento de modo a refinar o modelo em sucessivas iteraes. As suas
principais actividades esto orientadas para a identificao de classes e
objectos e respectivas caractersticas e para a determinao das rela-
es entre classes.
OMT (Object Modelling Technique)
O OMT foi proposto por James Rumbaugh em 1991 [Rumbaugh91], e
concentrou as suas propostas na anlise e desenho de software, s
quais aplicou tcnicas orientadas por objectos. A sua metodologia
apresentava essencialmente trs modelos principais: esttico ou de
objectos (onde se representavam classes, objectos, a hierarquia e
outras relaes), dinmico (apresentava o comportamento dos objectos
e do sistema global) e funcional (diagrama de fluxo de informao no
sistema semelhante aos diagramas de fluxos de dados).
OOSE (Object Oriented Software Engineering)
O OOSE foi proposto por Ivar Jacobson em 1992 [Jacobson92], resulta
da evoluo do modelo Objectory (tambm do mesmo autor) e a sua
maior contribuio foi a introduo da noo de caso de utilizao que
funciona como uma descrio da interaco entre o utilizador e o
sistema.
100 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

OOAD (Object Oriented Analysis and Design)
O OOAD foi proposto por Peter Coad e Edward Yourdon em 1991
[Coad91], apresentava como uma das suas principais vantagens o facto
de ser muito simples (ao nvel dos conceitos, actividades e diagramas) o
que o tornava um dos mais fceis de compreender. As suas principais
actividades relacioandas com a anlise so no fundo aquilo que todos
ns esperaramos realizar num processo que aplicasse as noes da
orientao por objectos:
Identificar objectos utilizando critrios simples (substantivos).
Definir uma estrutura de relaes generalizao-especificao.
Definir uma estrutura de relaes de associao (whole-part).
Identificar assuntos (subsistemas).
Definir os atributos.
Definir os servios.
Mtodo de Wirfs-Brock
A metodologia de Wirfs-Brock no efectua uma distino clara entre
anlise e desenho, e a sua principal contribuio foi a definio de um
diagrama designado por CRC cards (Class-Responsibility-Colaboration)
que procura identificar as classes do sistema, a sua interface e as
relaes entre elas. As principais actividades consistem em avaliar a
especificao do cliente; extrair classes candidatas por anlise da
especificao; identificar grupos de classes (superclasses); definir e
atribuir responsabilidades para cada classe; identificar relaes entre
classes; identificar colaboraes entre classes com base nas responsa-
bilidades; e construir representaes hierrquicas das classes
Para alm destas metodologias, sem dvida alguma que aquela que
actualmente mais relevante a proposta pela Rational (e que na
realidade se baseia em muitos dos conceitos aqui referidos) e que
apresentada em detalhe no captulo 10. Outras que vale a pena
mencionar so a de Shlaer e Mellor [Shlaer88], a de Edward Berard
[Berard93] e a de James Martin [Martin92].
PARTE 2 LINGUAGEM DE MODELAO UML 101


3.6 Outras Metodologias
Apesar dos benefcios que se reconhecem na utilizao de metodolo-
gias (independentemente do paradigma utilizado), elas no esto isen-
tas de crticas e de aspectos menos positivos:
Complexidade nos conceitos, tcnicas e aplicao.
Desconhecimento global da metodologia e falta de competncias
dos informticos para a sua execuo com qualidade.
Ferramentas que suportam a metodologia difceis de utilizar.
Constatao da ausncia de melhorias significativas no processo e
produto final.
Concentrao na anlise da situao actual, menor importncia aos
objectivos futuros.
Tempo que decorre at disponibilizao dos resultados finais.
Rigidez na aplicao dos mtodos e conceitos.
Como reaco a esta situao, um novo grupo de metodologias
comeou a aparecer nos ltimos anos, que implicam um nvel de
formalismo muito menor. Muitas delas advogam a no realizao de
actividades de anlise e desenho, e a produo de muito menos docu-
mentao por comparao com as metodologias estruturadas ou
orientadas por objectos. Defendem que a principal documentao de
um sistema , ou deveria ser, o cdigo fonte das aplicaes desenvol-
vidas. Comungam entre si a ideia de que as principais actividades a
realizar ao longo de todo o processo de desenvolvimento so essencial-
mente a programao e os testes.
Estes mtodos so bastante adaptveis, tambm como forma de
responder adequadamente aquilo que eles consideram ser a imprevi-
sibilidade dos requisitos ao longo do tempo. Concentram-se na satisfa-
o das necessidades das pessoas (informticos e utilizadores) e no
na definio de processos. Partilham a ideia do desenvolvimento itera-
tivo tpico das abordagens orientadas por objectos, e reforam a impor-
tncia da actividade de testes.
Apesar delas partilharem um conjunto de ideias base comuns, no
existe ainda uma designao formal para elas, a no ser o termo
102 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

lightweight (leve ou simplificado). So na sua maioria desconhecidas do
grande pblico informtico, apesar de algumas delas j estarem a ser
aplicadas h vrios anos. Algumas referncias relevantes nesta rea
so as abordagens XP - Extreme Programming [Beck99], Feature
Driven Development [Coad99] e DSDM - Dynamic System Development
Method.
Tal como referido por Fowler [Fowler00], em determinadas
circunstncias estes mtodos so particularmente aconselhveis,
sobretudo se estivermos a falar de sistemas pequenos ou com requisi-
tos incertos ou volteis, em que os programadores so responsveis,
experientes e se encontram motivados e em que os clientes so
igualmente participativos e responsveis, ou ainda quando a equipa de
desenvolvimento relativamente reduzida e estvel. Noutras situaes
ser prefervel um processo mais formal, nomeadamente sempre que o
projecto exigir a alocao de equipas de maior dimenso, ou existir um
contrato com mbito e preos fixos, ou em que o risco seja elevado e o
processo de controle do projecto deva ser reforado.
3.7 Comparao de Metodologias
A comparao das diversas metodologias actualmente existentes uma
tarefa complexa devido a um conjunto de dificuldades que se colocam e
das quais podemos destacar as seguintes:
No existem metodologias iguais e portanto em qualquer compara-
o estaremos sempre a comparar conceitos por vezes no compa-
rveis.
Muitas metodologias so influenciadas ou particularmente concebi-
das para serem utilizadas com linguagens de programao espe-
cficas.
Muitas metodologias assumem um contexto de aplicao onde no
existem os problemas que no mundo real tm que enfrentar.
A abrangncia das metodologias varia fortemente; algumas apenas
descrevem um processo, outras incluem tcnicas e notaes.
A comparao entre metodologias tem que considerar obrigatoria-
mente apenas um subconjunto das mesmas, e um subconjunto de
funcionalidades.
PARTE 2 LINGUAGEM DE MODELAO UML 103


A prpria definio do conceito metodologia pode ser limitativa.
Hoje em dia reconhece-se a vantagem clara do ponto de vista concep-
tual das abordagens orientadas por objectos face s estruturadas, pois
apresentam:
Um nico paradigma consistente ao longo de todo o processo, mais
prximo do processo cognitivo humano.
Facilitam a reutilizao no apenas do cdigo mas tambm da
arquitectura global do sistema, o que potencia o aumento de produti-
vidade dos informticos.
Apresentam modelos que reflectem mais adequadamente o mundo
real.
No existe separao entre dados e processos, o conceito unifica-
dor agrega as duas vises.
Os detalhes de implementao so escondidos do exterior pela
aplicao de tcnicas de encapsulamento da informao.
A facilidade de realizao das tarefas de manuteno maior, em
resultado das diversas caractersticas anteriormente enumeradas.
O sistema construdo consequentemente mais estvel.
Estas abordagens tm contudo os seus problemas, pois reconhece-se
que nem sempre fcil encontrar os objectos e classes apropriados no
domnio do problema, uma vez que a maioria dos informticos continua
a pensar em termos funcionais. Para alm disso, s recentemente
comearam a surgir no mercado ferramentas de apoio ao processo de
desenvolvimento segundo o paradigma da orientao por objectos.
Comparamos de seguida alguns aspectos concretos em como as
abordagens orientadas por objectos se revelam mais adequadas que as
estruturadas.
3.7.1 Gesto de Requisitos e Facilidade de Manuteno
A figura 3.9 ilustra a diferena entre os paradigmas do desenvolvimento
estruturado versus o desenvolvimento orientado por objectos. No
desenvolvimento estruturado, o sistema consiste num conjunto de
dados que so usados (em leitura e/ou escrita) por inmeras funes,
104 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

de forma mais ou menos independente. O sistema corresponde a uma
malha arbitrria de inmeras interdependncias entre funes e dados.
No desenvolvimento orientado por objectos, dados e funes so
agregados conjuntamente numa entidade lgica (o objecto) que provi-
dencia uma interface bem definida para outros objectos comunicarem
com ele. O sistema corresponde a uma malha de interdependncias en-
tre objectos.

Figura 3.9: Desenvolvimento estruturado versus desenvolvimento
orientado por objectos.
evidente que as abordagens orientadas por objectos facilitam
significativamente a gesto das alteraes de requisitos. Imagine-se as
implicaes que a alterao da estrutura dos dados implica em ambas
as abordagens. Na abordagem estruturada, seria necessrio adaptar
consistentemente todas as funes que acedessem estrutura de
dados envolvida, e, na pior das situaes, a todas as funes que de-
pendessem funcionalmente dessas primeiras funes.
Por outro lado, nas abordagens orientadas por objectos, apenas seria
necessrio alterar a estrutura de dados que supostamente era definida
no contexto interno de um determinado objecto. Caso essa alterao
no implicasse a alterao da interface providenciada pelo objecto, no
haveria mais nada a fazer!
3.7.2 Representao da Realidade
Nas abordageens orientada por objectos, as entidades do mundo real
so captadas directamente por objectos: um carro um objecto do tipo
carro, uma conta bancria um objecto do tipo conta bancria, etc.
PARTE 2 LINGUAGEM DE MODELAO UML 105


Tal como as entidades do mundo real, os objectos apresentam dados e
comportamento, bem como identidade prpria.

Figura 3.10: Especializao de contas bancrias na abordagem OO.
Nas abordagens estruturadas, uma conta bancria pode ser
representada atravs de um ou mais mdulos com funes especficas
que acedem a vrias estruturas de dados de forma independente.
Nestas abordagens, o foco na definio do modelo de dados da conta
bancria (isto , no desenho da base de dados que suporta contas
bancrias) ou, alternativamente, na definio dos processos/funes
que acedem e manipulam contas bancrias. Consequentemente a esta
abordagem, no fcil explicitar especializaes ou generalizaes
correspondentes a conceitos inerentes a entidades do mundo real que
existam ou que venham a existir.
Por exemplo, no trivial na abordagem estruturada introduzir-se
posteriormente a noo de contas bancrias especializadas, o que
simples na abordagem orientada por objectos, tal como representado
na Figura 3.10.
106 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

3.7.3 Outros Aspectos
O desenvolvimento de software segundo uma abordagem orientada por
objectos apresenta outras vantagens comparativamente com a aborda-
gem estruturada, resumidamente:
Providencia blocos de construo de alto nvel que reduzem os
custos de desenvolvimento, pela promoo da reutilizao e
encapsulamento de software. Este facto permite reduzir as interde-
pendncias e facilitar a manuteno posterior.
Facilita a transferncia de conhecimento atravs da adopo de
padres de desenho, reduzindo o custo de aprendizagem.
Providencia um framework (aplicacional ou de middleware) para
facilitar a extenso do sistema, reduzindo o custo de novas
verses.
Reduz o custo de alterao do sistema, em resposta s expec-
tativas e requisitos dos utilizadores
Todavia, e ainda que actualmente esta abordagem possa j ser
considerada estabelecida e madura, implica alguns cuidados na sua
aplicao, pelo facto de levantar algumas questes:
Exige uma nova forma de pensar o processo de desenvolvimento.
A orientao por objectos deve ser utilizada em todas as fases do
ciclo de vida do software. Por exemplo, no tem muito sentido usar-
se uma linguagem orientada por objectos a seguir a um ciclo de
anlise e desenho tradicional, ou vice-versa.
A gesto da empresa ou do projecto tem de comprar a mudana
para a filosofia orientada por objectos, em particular tem de definir
os objectivos comerciais para a mudana. Por exemplo, reduo dos
custos de manuteno do software.
A migrao para a orientao por objectos tem de ser devidamente
planeada para garantir a sua eficcia.
Apesar das vantagens sublinhadas da abordagem da orientao por
objectos no desenvolvimento de software, no se deve concluir que esta
sempre mais adequada que a aproximao estruturada. H vrias
situaes em que mais correcto seguir uma metodologia estruturada.
Por exemplo, se a linguagem de programao utilizada pela organiza-
o for Cobol, RPG ou C e o ambiente de desenvolvimento for estrutu-
rado, ento far mais sentido aplicar metodologias estruturadas ao
PARTE 2 LINGUAGEM DE MODELAO UML 107


longo de todas as fases do projecto. Caso contrrio, correr-se-ia no erro
(e no perigo!) de se realizar uma modelao com base em conceitos
orientados por objectos e depois ter de se recriar, ao nvel do desenho
(ou pior, ao nvel da codificao!) um modelo completamente distinto do
primeiro. Apesar de ser natural e bvio que mais consistente a
utilizao do mesmo paradigma ao longo de todo o ciclo, do ponto de
vista terico nada impede que se utilizem mtodos de anlise estrutura-
da, seguidos de uma implementao numa linguagem orientada por
objectos; o inverso pode tambm acontecer, isto , a utilizao de uma
linguagem tradicional na sequncia de uma anlise orientada por objec-
tos.
3.8 Concluso
Este captulo conclui a primeira parte do livro, na qual se deu uma viso
dos problemas da Engenharia de Software (Captulo 1), a definio de
conceitos e abordagens genricas ao desenvolvimento de software
(Captulo 2) e uma ideia resumida do caminho que foi seguido at
data em termos de evoluo dos conceitos e das metodologias prticas
(Captulo 3).
Neste ltimo captulo procurmos transmitir ao leitor a ideia de que as
abordagens orientadas por objectos apresentam vantagens significa-
tivas, mas que a proliferao de notaes e metodologias, bem como o
conhecimento especializado que necessrio para aplicar com sucesso
esta nova forma de encarar e modelar o mundo exterior, colocam
desafios significativos e constituem problemas importantes que preci-
so solucionar.
precisamente com esse objectivo que o resto do livro se concentra na
linguagem de modelao UML, e nos processos de desenvolvimento a
ela associados, quer porque esta de facto uma iniciativa unificadora
ao nvel das notaes, quer porque necessria a sua divulgao de
forma a que mais informticos adquiram os conhecimentos necessrios
para a sua correcta utilizao.
preciso estar atento s iniciativas metodolgicas mais recentes,
nomeadamente quelas que propem uma simplificao do processo
108 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

de desenvolvimento ao nvel de actividades, notaes e documentao
produzida. A grande maioria recorre ao UML para as actividades de
modelao que realiza, o que mais uma vez refora a nossa convico
que esta linguagem de notao representar cada vez mais um papel
significativo nas metodologias de desenvolvimento de software.
3.9 Exerccios
Ex.16. Imagine que o responsvel de uma biblioteca cujos livros
podem ser requisitados por diversos leitores previamente
registados, mediante a apresentao de uma guia de requisio.
Esta indica o prazo de devoluo, ao fim do qual o leitor tem que
devolver o livro, preenchendo uma guia de entrega. Para os
livros muito solicitados podero existir vrias cpias na
biblioteca, e se necessrio, podero ser adquiridas mais. Para
tal, o responsvel da biblioteca poder requisitar mais cpias
atravs de uma requisio, que ser autorizada pela direco,
de modo a que o responsvel da biblioteca possa encomendar
esses livros junto de um fornecedor, proceder ao respectivo
pagamento e dar entrada dos livros na biblioteca.
Se tivesse que efectuar a anlise deste caso segundo uma
abordagem estruturada, que tipo de informao do enunciado
seria mais relevante? E se a abordagem utilizada fosse
orientada por objectos? Justifique a sua resposta.
Efectue a modelao da estrutura esttica do sistema pelo
diagrama estruturado que achar mais conveniente, justificando
a sua resposta.
Efectue a modelao da estrutura esttica do sistema pelo
diagrama UML que achar mais conveniente, justificando a sua
resposta.
PARTE 2 LINGUAGEM DE MODELAO UML 109


Ex.17. Imagine que o responsvel pela gesto de informao sobre
alunos de uma universidade, sendo para isso relevante
reproduzir no sistema de informao as aces que normal-
mente ocorrem ao longo do ano na universidade: matrculas de
alunos num ano lectivo e em cadeiras; inscries nas aulas pr-
ticas; inscries em exames; pagamentos de propinas; consultas
de notas atribudas; pedidos de certificados.
Se tivesse que modelar o sistema anteriormente descrito,
indique qual (ou quais) o(s) diagrama(s) que utilizaria se
aplicasse uma abordagem estruturada e qual (ou quais)
utilizaria se aplicasse uma abordagem orientada por objectos,
justificando a sua resposta.
Efectue a modelao dos conceitos aqui representados pelos
diagramas estruturados que achar convenientes, justificando a
sua resposta.
Efectue a modelao dos conceitos aqui representados pelos
diagramas relacionados com abordagens orientadas por
objectos que achar convenientes, justificando a sua resposta.
Quais as principais alteraes que ocorreram no processo de
desenvolvimento de software com a introduo das aborda-
gens estruturadas?
110 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Ex.18. Uma das crticas que normalmente se aponta s metodologias
estruturadas de defenderem conceitos tericos que se afastam
da realidade prtica. Indique alguns exemplos deste desfasa-
mento.
Ex.19. Compare os conceitos utilizados nos principais diagramas utili-
zados nas abordagens estruturadas e nas abordagens orienta-
das por objectos, para modelar a dinmica de um sistema.
Ex.20. As abordagens orientadas por objectos, particularmente na
tarefa de implementao, so particularmente adequadas para a
implementao de processos iterativos. Justifique esta afirma-
o.
Ex.21. As metodologias estruturadas esto tipicamente divididas em
duas categorias principais, consoante a importncia que atribu-
em s principais tcnicas de modelao utilizadas. Indique quais
so essas categorias, e quais as principais caractersticas de
cada uma deles.
Ex.22. Porque que as metodologias de desenvolvimento de software
estruturadas tm este nome? Quais as motivaes que levaram
sua definio e aplicao?
Ex.23. Algumas das novas metodologias defendem o fim das activida-
des de anlise no processo de desenvolvimento de software. Ex-
presse a sua opinio, justificando-a.


Parte 2 Linguagem
de Modelao UML
Talvez isto seja um sinal disse o Ingls,
como quem pensa alto.
Quem falou em sinais? o interesse do
rapaz crescia a cada minuto.
Tudo na vida so sinais disse o Ingls,
desta vez fechando a revista que estava a
ler. O universo feito por uma lngua que
todo o mundo entende, mas que j se
esqueceu. Estou procura dessa
Linguagem Universal, alm de outras
coisas. Por isso estou aqui.
Paulo Coelho, O Alquimista.
O UML
O UML (Unified Modelling Language) uma linguagem diagramtica,
utilizvel para especificao, visualizao e documentao de sistemas
112 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

de software. O UML surge em 1997 na sequncia de um esforo de
unificao de trs das principais linguagens de modelao orientadas
por objectos (OMT, Booch e OOSE). Seguidamente, adquiriu o estatuto
de norma no mbito da OMG e da ISO, tendo vindo a ser adoptado
progressivamente pela indstria e academia em todo o mundo.
O UML apresenta, entre outras, as seguintes caractersticas principais:
(1) independente do domnio de aplicao (i.e., pode ser usado em
projectos de diferentes caractersticas, tais como sistemas cliente/
servidor tradicionais; sistemas baseados na Web; sistemas de informa-
o geogrficos; sistemas de tempo real); (2) independente do
processo ou metodologia de desenvolvimento; (3) independente das
ferramentas de modelao; (4) apresenta mecanismos potentes de
extenso; (5) agrega um conjunto muito significativo de diferentes
diagramas/tcnicas dispersos por diferentes linguagens (e.g., diagramas
de casos de utilizao, de classes, de objectos, de colaborao, de
actividades, de estados, de componentes, e de instalao).
Ao longo dos Captulos 4 a 9 da Parte 2 deste livro apresentamos a
linguagem UML com um compromisso assumido entre abrangncia e
detalhe. Por um lado, pretende-se que sejam apresentados e discutidos
todos os diagramas do UML; por outro lado, pretende-se apresentar os
seus principais detalhes e discutir a sua aplicabilidade.
O UML e os Domnios de Aplicao
Os exemplos ilustrados e os exerccios sugeridos apresentam um
compromisso entre situaes de modelao de casos gerais do dia-a-
dia (e.g., o exemplo da mquina de bebidas, ou os exerccios sobre o
universo do futebol) e de casos mais especficos do domnio de
sistemas de software (e.g., o exemplo dos diagramas de classes e de
interaco do acesso, via JDBC, a um gestor de base de dados, ou o
exerccio pedido para modelar o ciclo de vida de um servlet Java). O
objectivo de apresentar exemplos entre estes dois espectros mostrar
que o UML pode ser adoptado em diferentes domnios de aplicao, de
abstraco e de generalidade.
O UML uma linguagem grfica cujo objectivo principal promover e
facilitar a comunicao entre um grupo variado de intervenientes.
PARTE 2 LINGUAGEM DE MODELAO UML 113


Embora o foco deste livro tenha a ver com a modelao de software,
nunca demais sublinhar que o UML pode ser usado noutros contextos
e por intervenientes com diferentes formaes (e.g., por gestores, para
representarem a organizao das empresas e respectivos processos de
negcio; por juristas, para representarem as relaes entre leis).
Organizao da Parte 2
A Parte 2 constituda por 6 captulos complementares. O Captulo 4 d
a viso histrica e geral do UML e o Captulo 9 descreve sucintamente
alguns aspectos considerados avanados, no essenciais para o leitor
que apenas pretende usar e aplicar as caractersticas bsicas do UML.
Os restantes captulos (Captulos 5, 6, 7 e 8) constituem o centro desta
parte do livro e devero ser lidos de forma sequencial, conforme propos-
to.
O Captulo 4, UML Viso Geral, d uma viso geral do UML. Em
particular apresenta o seu enquadramento histrico, os seus objectivos
e principais aspectos que orientaram a sua arquitectura subjacente. So
apresentados sucintamente os seus principais conceitos, designada-
mente os tipos de elementos bsicos, de relaes e de diagramas. Por
fim, apresentam-se alguns dos mecanismos comuns UML (anotaes e
mecanismos de extenso) e consideraes relacionadas com a organi-
zao dos artefactos de um sistema atravs da noo de pacotes.
O Captulo 5, UML Casos de utilizao, comea por discutir a tarefa
de especificao e de gesto de requisitos de um sistema de software e
a sua relao com os diagramas de casos de utilizao. So definidos
os conceitos de caso de utilizao, cenrio, actor, relaes entre casos
de utilizao (relao de generalizao, incluso ou extenso) e entre
actores e casos de utilizao (relao de comunicao). So apresen-
tados modelos de especificao textual dos casos de utilizao, com
evidncia para a especificao das relaes de incluso e de extenso.
Por fim, discutido a aplicao dos diagramas de utilizao atravs do
exemplo da Mquina de Bebidas.
O Captulo 6, UML Modelao da Estrutura, aborda um aspecto
bsico na modelao de software, que a sua estrutura. Esta consiste,
114 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

segundo a abordagem orientada por objectos, na identificao de
classes e suas respectivas relaes. O UML providencia os seguintes
elementos que permitem a especificao da estrutura de um sistema de
software: classes, relaes, interfaces, objectos. Com base nestes ele-
mentos, podem-se definir dois tipos de diagramas com fins complemen-
tares: diagramas de classes e diagramas de objectos.
O Captulo 7, UML Modelao do Comportamento, parte do
pressuposto que a modelao da estrutura de um sistema conhecida,
e atenta sobre a respectiva modelao de comportamento, a qual
consiste, segundo a abordagem orientada por objectos, em dois tipos
distintos de especificaes. Por um lado, na modelao do comporta-
mento entre objectos, pela identificao dos seus padres de trocas de
mensagens (diagramas de interaco). Por outro lado, na modelao do
comportamento dentro de um objecto, pela identificao dos estados
que um objecto pode ter ao longo do seu ciclo de vida e dos eventos
que provocam mudanas nesses estados (diagramas de estados e de
actividades).
O Captulo 8, UML Modelao da Arquitectura, descreve aspectos
da fase de implementao e instalao de um sistema de software,
designadamente a estrutura e dependncias de cdigo fonte e de
mdulos executveis, tal como a sua respectiva instalao nas diferen-
tes plataformas computacionais subjacentes, atravs dos diagramas de
componentes e de instalao. Os diagramas de componentes so
usados para modelar a arquitectura de um sistema de software na
perspectiva dos seus componentes digitais, explicitando principalmente
as suas mltiplas dependncias. Por outro lado, os diagramas de
instalao so usados para modelar a arquitectura de um sistema
informtico da perspectiva dos seus componentes fsicos explicitando
as dependncias de comunicao, e especificando os componentes
instalados em cada n computacional.
O Captulo 9, UML Aspectos Avanados, apresenta alguns assuntos
que consideramos avanados, e que permitem ao utilizador do UML
uma sua profunda compreenso e porventura uma sua melhor
aplicao. Nomeadamente, apresentam-se os seguintes aspectos: (1) a
estrutura e arquitectura do UML, e em particular a organizao da
camada de metamodelo; (2) os mecanismos de extenso do UML; com
PARTE 2 LINGUAGEM DE MODELAO UML 115


alguns exemplos concretos de conjuntos de elementos que estendem o
UML, designados por perfis; (3) consideraes sobre as noes de
componente, sistemas de componentes (toolkits e frameworks), famlias
de aplicaes, e reutilizao; (4) tipos parametrizveis em UML, em
particular classes parametrizveis e colaboraes parametrizveis (no
contexto de padres de desenho); e (5) uma breve introduo e
motivao para o XMI, que o standard OMG para interoperao de
modelos UML, em XML.
116 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE





Captulo 4 - UML VISO GERAL
Tpicos
Introduo
Viso Histrica
Tipos de Elementos Bsicos
Tipos de Relaes
Tipos de Diagramas
Mecanismos Comuns
Tipos de Dados
Organizao dos Artefactos Pacotes
Exerccios

4.1 Introduo
O UML (Unified Modeling Language) uma linguagem para
especificao, construo, visualizao e documentao de artefactos
de um sistema de software. promovido pelo Object Management
Group (OMG), com contribuies e direitos de autoria das seguintes
empresas: Hewlett-Packard, IBM, ICON Computing, i-Logix, IntelliCorp,
Electronic Data Services, Microsoft, ObjecTime, Oracle, Platinum,
Ptech, Rational, Reich, Softeam, Sterling, Taskon A/S e Unisys.
O UML providencia as seguintes particularidades principais [OMG99]:
Semntica e notao para tratar um grande nmero de tpicos
actuais de modelao.
118 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Semntica para tratar tpicos de modelao futura, relacionados em
particular com a tecnologia de componentes, computao distribu-
da, frameworks e Internet.
Mecanismos de extenso de modo a permitir que futuras
aproximaes e notaes de modelao possam continuar a ser de-
senvolvidas sobre o UML.
Semntica e sintaxe para facilitar a troca de modelos entre fer-
ramentas distintas.
O UML alarga o mbito de aplicaes alvo comparativamente com
outros mtodos existentes, designadamente porque permite, por exem-
plo, a modelao de sistemas concorrentes, distribudos, para a Web,
sistemas de informao geogrficos, etc.
A nfase do UML na definio de uma linguagem de modelao
standard, e por conseguinte, o UML independente das linguagens de
programao, das ferramentas CASE, bem como dos processos de
desenvolvimento. O objectivo do UML que, dependendo do tipo de
projecto, da ferramenta de suporte, ou da organizao envolvida, devem
ser adoptados diferentes processos/metodologias, mantendo-se contu-
do a utilizao da mesma linguagem de modelao.
O UML independente das ferramentas de modelao. Apesar da
especificao do UML incluir sugestes para os fabricantes de fer-
ramentas adoptarem na apresentao dessas notaes (e.g., tpicos
como o desenho de diagramas, cor, navegao entre esquemas, etc.),
no aborda todos os requisitos necessrios por no ser esse, propor-
sitadamente, o seu objectivo.
Um princpio bsico no esforo de definio do UML foi a simplicidade.
Outro princpio foi a coerncia na unificao de diferentes elementos
existentes em vrios mtodos, entre outros Booch [Booch94], OMT
[Rumbaugh91] e OOSE [Jacobson92], e introduo de novos elementos
apenas quando tal fosse absolutamente necessrio, i.e., quando tais
elementos no existissem em mtodos anteriores.
Os novos elementos introduzidos no UML so:
Mecanismos de extenso
Elementos para modelar processos e threads
Elementos para modelar distribuio e concorrncia
CAPTULO 4 - UML VISO GERAL 119


Padres de desenho e colaboraes
Diagramas de actividades (para modelao de processos de neg-
cio)
Refinamento (para tratar relaes entre diferentes nveis de abs-
traco)
Interfaces e componentes
Linguagem de restries (Object Contraint Language)
O UML providencia os seguintes tipos de diagramas:
Diagramas de casos de utilizao
Diagramas de classes e diagramas de objectos
Diagramas de comportamento
Diagramas de estados (statechart)
Diagramas de actividades
Diagramas de interaco (diagramas de sequncia e diagramas
de colaborao)
Diagramas de arquitectura:
Diagramas de componentes
Diagramas de instalao
4.2 Viso Histrica
A Figura 4.1 d uma viso do enquadramento histrico relativamente ao
contexto das linguagens de modelao de software orientado por objec-
tos e, em particular, do UML.
Na primeira metade da dcada de 1990 assistiu-se a uma proliferao
de mtodos e notaes para modelao segundo a abordagem orienta-
do por objectos (fase da fragmentao). Por essa altura percebeu-se a
necessidade da existncia de uma linguagem que viesse a tornar-se
uma norma, que fosse aceite e utilizada quer pela indstria, quer pelos
ambientes acadmicos e de investigao.
Surgiram entretanto alguns esforos nesse sentido de normalizao,
sendo que o UML apareceu em 1996 melhor posicionado como a lingu-
agem unificadora de notaes, diagramas, e formas de representao
120 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

existentes em diferentes mtodos, em particular nos mtodos Booch,
OMT e OOSE (fase da unificao).

Figura 4.1: Viso histrica do UML.
Seguiu-se um esforo significativo nessa unificao com contributos de
vrios parceiros com vista normalizao no mbito da OMG, o que
aconteceu em 1997 (fase da standardizao).
Actualmente assiste-se divulgao e adopo generalizada do UML
como a linguagem de modelao de software segundo a abordagem
orientada por objectos. Assiste-se ao aparecimento de publicaes
especficas sobre UML; de teses, relatrios e artigos tcnico-cientficos
que usam o UML; de ferramentas CASE que suportam o UML, etc. (fase
da industrializao).
H dois aspectos importantes que se obtm com o UML: (1) terminam
as diferenas, geralmente inconsequentes, entre as linguagens de
modelao dos anteriores mtodos; e (2) unifica as distintas perspec-
tivas entre diferentes tipos de sistemas (e.g., modelao de negcio vs.
modelao de software), fases de um processo e conceitos internos.
Uma das preocupaes mais significativos no desenho e na especifica-
o do UML foi torn-lo extensvel e aberto a futuras evolues, que
CAPTULO 4 - UML VISO GERAL 121


inevitavelmente iro ocorrer. O objectivo que seja possvel estender o
UML sem ser necessrio redefinir o seu ncleo principal.
4.3 Tipos de Elementos Bsicos
A estrutura de conceitos do UML razoavelmente abrangente
consistindo num conjunto variado de notaes, as quais podem ser
aplicados em diferentes domnios de problemas e a diferentes nveis de
abstraco. A estrutura de conceitos do UML pode ser vista atravs das
seguintes noes: (1) coisas ou elementos bsicos, com base nos
quais se definem os modelos; (2) relaes, que relacionam elementos; e
(3) diagramas, que agrupam elementos.
Os elementos encontram-se organizados consoante a sua funciona-
lidade ou responsabilidade. Assim h elementos de estrutura, comporta-
mento, agrupamento e de anotao.
A Figura 4.2. ilustra o conjunto dos principais elementos de estrutura:
classes, classes activas, interfaces, casos de utilizao, actores, colabo-
raes, componentes e ns.


Figura 4.2: Resumo dos elementos de estrutura.
122 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

A Figura 4.3 ilustra outros elementos bsicos do UML, elementos de
comportamento (estados e mensagens), de agrupamento (pacotes) e de
anotao (anotaes ou notas).

Figura 4.3: Resumo dos elementos de comportamento, agrupamento e
anotao.
4.4 Tipos de Relaes
As relaes so conceitos gerais que apresentam uma sintaxe (neste
caso, uma notao) e uma semntica bem definida, e que permite o
estabelecimento de interdependncias entre os elementos bsicos aci-
ma introduzidos.

Figura 4.4: Resumo dos tipos de relaes standard.
A Figura 4.4 ilustra os principais tipos de relaes do UML,
nomeadamente relaes do tipo associao, dependncia, realizao,
CAPTULO 4 - UML VISO GERAL 123


generalizao e transio de estado. (Mais abaixo ser descrito em de-
talhe a semntica e aplicao destes diferentes tipos de relaes.)
4.5 Tipos de Diagramas
Os diagramas so conceitos que traduzem a possibilidade de agrupar
elementos bsicos e suas relaes de uma forma lgica ou de uma
forma estrutural. Existem diferentes tipos de diagramas em UML. Em
cada tipo de diagrama usado um subconjunto dos elementos bsicos
acima descritos, com diferentes tipos de relaes que tenha sentido
existir.
Por exemplo, um diagrama de classes UML composto por um conjun-
to de cones representantes de classes em simultneo (e opcional-
mente) com a representao explcita das suas relaes.
Com base no quarto princpio de modelao enumerado na Seco
2.3.2 (P4. Nenhum modelo suficiente por si s. Qualquer sistema
no-trivial melhor representado atravs de pequeno nmero de mode-
los razoavelmente independentes.), o UML define diferentes tipos de
diagramas, cuja utilizao e aplicao permitem dar vises complemen-
tares.
Diagramas de casos de utilizao, que representam a viso do
sistema na perspectiva do seu utilizador.
Diagramas de classes que permitem especificar a estrutura esttica
de um sistema segundo a abordagem orientada por objectos.
Diagramas de interaco entre objectos (diagramas de sequncia e
diagramas de colaborao) e diagramas de transio de estados e
diagramas de actividades, que permitem especificar a dinmica ou o
comportamento de um sistema segundo a abordagem orientada por
objectos.
Diagramas de componentes e diagramas de instalao, que do
uma viso da disposio dos componentes fsicos (software e hard-
ware) de um sistema.
124 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

4.5.1 Diagramas de Casos de Utilizao
Um diagrama de casos de utilizao descreve a relao entre actores e
casos de utilizao de um dado sistema (ver exemplo da Figura 4.5).
Este um diagrama que permite dar uma viso global e de alto nvel do
sistema, sendo fundamental a definio correcta da sua fronteira.

Figura 4.5: Exemplo de um diagrama de casos de utilizao.
Estes diagramas so utilizados preferencialmente na fase de
especificao de requisitos e na modelao de processos de negcio.
Estes diagramas so equivalentes aos homlogos existentes no mtodo
OOSE de Ivar Jacobson [Jacobson92].
4.5.2 Diagramas de Modelao da Estrutura
Os diagramas de classes do UML so uma integrao de diferentes
diagramas de classes existentes, nomeadamente no OMT
[Rumbaugh91], Booch [Booch94] e outros mtodos OO. Extenses
especficas de determinados processos (e.g. recorrendo a esteretipos
e correspondentes cones) podem ser definidos em vrios diagramas
para suportarem diferentes estilos de modelao.
CAPTULO 4 - UML VISO GERAL 125



Figura 4.6: Exemplo de um diagrama de classes.
Os diagramas de classes (ver exemplo da Figura 4.6) descrevem a
estrutura esttica de um sistema, em particular as entidades existentes,
as suas estruturas internas, e relaes entre si.
Um diagrama de objectos descreve um conjunto de instncias com-
patveis com determinado diagrama de classes. Permitem ilustrar os
detalhes de um sistema em determinado momento ao providenciarem
cenrios de possveis configuraes.
4.5.3 Diagramas de Modelao do Comportamento
Interaco entre Objectos
Os padres de interaco entre objectos so representados por
diagramas de interaco, os quais podem assumir duas formas comple-
mentares, cada um focando um aspecto distinto: diagramas de sequn-
cia e diagramas de colaborao.
126 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Diagramas de Sequncia
Os diagramas de sequncia ilustram interaces entre objectos num
determinado perodo de tempo (ver exemplo da Figura 4.7). Em
particular, os objectos so representados pelas suas linhas de vida e
interagem por troca de mensagens ao longo de um determinado perodo
de tempo.

Figura 4.7: Exemplo de um diagrama de sequncia.
CAPTULO 4 - UML VISO GERAL 127


Este tipo de diagrama baseia-se numa variedade de diagramas
homlogos existentes em distintos mtodos OO, segundo diferentes
designaes, como por exemplo interaction diagrams, message sequen-
ce charts, message trace, event trace, etc.
Diagramas de Colaborao
Os diagramas de colaborao ilustram interaces entre objectos com
nfase para a representao das ligaes entre objectos. Como os
diagramas de colaborao no mostram o tempo como um elemento
explcito (tal como acontece nos diagramas de sequncia), a sequncia
de mensagens e de actividades concorrentes determinada usando-se
nmeros sequenciais, com diferentes nveis hierrquicos. Colaboraes
so entidades de modelao principais e constituem geralmente a base
para a representao visual de padres de desenho (design patterns)
[Gamma94].
Este tipo de diagrama foi adoptado, entre outros, a partir do diagrama
de objectos de Booch [Booch94], e do diagrama de interaco de objec-
tos de Fusion [Malan96].
Diagramas de Transio de Estado
Os diagramas de transio de estado descrevem as sequncias de
estados que um objecto ou uma interaco pode passar ao longo da
sua existncia em resposta a estmulos recebidos, conjuntamente com
as suas respostas e aces.
So baseados nos statecharts de David Harel com pequenas adap-
taes [Harel87, Harel96].
Diagramas de Actividades
Os diagramas de actividades (ver exemplo da Figura 4.8) so um caso
particular dos diagramas de transio de estado, no qual a maioria dos
estados so substitudos pelos conceitos correspondentes a aces
e/ou actividades, e no qual as transies so desencadeadas devido
concluso de aces nos estados originais.
128 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE


Figura 4.8: Exemplo de um diagrama de actividades.
O objectivo deste diagrama representar os fluxos conduzidos por
processamento interno, em contraste com eventos externos represen-
tados tipicamente nos diagramas de estado.
Este tipo de diagramas pode ser encarados como um caso particular de
diagramas de estados e inspirados nos diagramas de workflow, fluxo-
gramas ou naqueles baseados em SDL (Specification and Description
Language) [ITU-T93].
CAPTULO 4 - UML VISO GERAL 129


4.5.4 Diagramas de Arquitectura
Os diagramas de arquitectura descrevem aspectos da fase de
implementao de um sistema de software, por exemplo, relativamente
estrutura e dependncias de mdulos de cdigo fonte e de mdulos
executveis. Estes diagramas apresentam-se sob duas formas: diagra-
mas de componentes e diagramas de instalao.
Diagramas de componentes
Os diagramas de componentes descrevem as dependncias entre
componentes de software, incluindo componentes de cdigo fonte, cdi-
go binrio e executveis.
Os diagramas de componentes so representados na forma de tipos e
no na forma de instncias. Para descrever-se instncias de componen-
tes, usam-se os diagramas de instalao.
Diagramas de Instalao
Os diagramas de instalao (deployment diagrams) descrevem a confi-
gurao de elementos de suporte de processamento, e de componentes
de software, processos e objectos existentes nesses elementos (ver
exemplo da Figura 4.9).
130 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE


Figura 4.9: Exemplo de um diagrama de instalao.
4.6 Mecanismos Comuns
O UML contm um conjunto de mecanismos comuns que so aplicados
de modo consistente ao longo dos seus diferentes diagramas.
Descreve-se de seguida dois dos mecanismos comuns mais usados:
anotaes e mecanismos de extenso.
4.6.1 Notas (Anotaes)
Notas ou anotaes so os adornos mais importantes que existem
autonomamente (i.e., sem estarem directamente associados a outros
elementos). Ver-se- mais frente a utilizao de outros adornos (por
exemplo, adornos para qualificar elementos participantes em relaes).
Uma nota ilustra um comentrio e no tem qualquer impacto semntico,
j que o seu contedo no altera o significado do modelo no qual ela se
encontra (ver Figuras 4.9 e 4.10). Por isso normal a utilizao de
notas para se descrever informalmente: requisitos, restries, observa-
es, revises ou explicaes.
CAPTULO 4 - UML VISO GERAL 131



Figura 4.10: Exemplo de notas.
Em geral devem ser tomadas em considerao as seguintes observa-
es na utilizao de notas:
Localizao: Devem ser colocadas graficamente perto dos elemen-
tos que descrevem.
Visibilidade: Podem-se esconder ou tornar visveis (isto dependendo
das ferramentas de suporte).
Extenso: Devem-se usar referncias (e.g., nomes de documentos
ou URL) caso se pretenda um comentrio mais extenso.
Evoluo: H medida que o modelo evolui as notas mais antigas
(cuja relevncia e utilidade deixem de ter sentido) devem ser
eliminadas dos modelos.
4.6.2 Mecanismos de Extenso
O UML providencia os seguintes mecanismos que permitem estender a
sua linguagem de forma consistente: esteretipos, marcas e restries.
Apresentam-se na Seco 9.3 mais detalhes sobre este assunto. Inte-
ressa desde j referir alguns aspectos na aplicao destes mecanismos,
designadamente deve-se:
Introduzir um nmero reduzido destes elementos.
Escolher nomes curtos e com significado para esteretipos e mar-
cas.
Sempre que a preciso puder ser relaxada, usar texto livre para
especificao das restries. Caso contrrio, usar a linguagem OCL.
O OCL (Object Constraint Language) [Warmer99] uma linguagem
para especificao formal de restries e parte integrante do UML
[OMG99].
132 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

A definio destes mecanismos de extenso do UML, em particular
a introduo de esteretipos, deve ser realizada por um nmero
restrito de especialistas em UML e deve ser devidamente documen-
tado.
Esteretipos
Um esteretipo um metatipo, isto , um tipo que descreve tipos.
Permite definir novos tipos de elementos sem se alterar o metamo-
delodo do UML, e por conseguinte permite estender o UML. O nome de
um esteretipo representado entre os caracteres e . Exemplos:
Na modelao de processos de negcio: trabalhador, docu-
mento, poltica.
Na modelao de aplicaes especficas: classes de interface,
controlo, e entidade.
Na modelao de aplicaes Web, usando o Web Application
Extension [Conallen00]): classes de Server Page, Client Page,
Form, Select Element.

Figura 4.11: Exemplo de esteretipos.
A Figura 4.11 ilustra trs formas complementares de apresentao de
esteretipos: com cone (e.g., SensorTemperatura); com nome (e.g.,
ModelElement); e com nome e cone (e.g., Overflow).
A definio de um esteretipo tem de ter em conta os seguintes aspec-
tos:
Propriedades (pode providenciar o seu prprio conjunto de marcas)
Semntica (pode providenciar as suas prprias restries)
Notao (pode providenciar o seu prprio cone)
CAPTULO 4 - UML VISO GERAL 133


A classe base do metamodelo que vai ser estendida (i.e., se o
esteretipo estende uma classe, uma associao, um componente,
etc.)
Marcas com Valor
Cada elemento em UML tem um conjunto de propriedades. Por
exemplo: as classes tm um nome, uma lista de atributos e uma lista de
operaes; as associaes tm um nome e dois ou mais elementos
participantes. Enquanto que os esteretipos permitem adicionar novos
elementos ao UML, as marcas com valor permitem adicionar novas
propriedades aos elementos, quer sejam elementos j existentes no
UML, quer sejam elementos definidos por recurso a novos esteretipos.
Uma marca com valor um conceito que deve ser entendido como
metadata (isto , dados que descrevem dados) pois o seu valor aplica-
se ao prprio elemento e no s suas instncias. Por exemplo, confor-
me ilustrado na Figura 4.12, pode-se especificar o nmero de proces-
sadores instalados em cada tipo de n, ou pode-se especificar se um
determinado componente para ser instalado/usado com perfil de clien-
te, servidor, ou ambos.

Figura 4.12: Exemplo de marcas com valor.
Um par marca e valor delimitado entre os caracteres { e }.
Exemplos de aplicaes usuais:
Para gerao de cdigo: E.g.: {language=Java}, {linker=Blinker}.
Na produo automtica de documentao.
Na gesto de configuraes: E.g.: {autor=AMRS}, {data=...}.
134 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Restries
As restries (constraints) permitem adicionar ou alterar a semntica
assumida por omisso de qualquer elemento UML. Uma restrio
consiste na especificao de uma condio delimitada pelos caracteres
{ e }. A condio pode ser especificada numa linguagem formal (e.g.,
OCL) ou informal (e.g., texto em portugus).
Uma restrio permite especificar condies que tm de ser validadas
para que o modelo esteja bem definido.

Figura 4.13: Exemplos de utilizao de restries.
A Figura 4.13 ilustra dois exemplos de especificao de restries. No
primeiro exemplo especifica-se em OCL que uma pessoa pode estar
casada apenas com outra pessoa do sexo oposto (Exemplo 1). No
segundo exemplo, especifica-se atravs da restrio {subset},
predefinida em UML, que os elementos da associao gerir tem de
existir obrigatoriamente na associao trabalhar, ou seja especifica-se
que uma pessoa para ser gestor de um departamento tem tambm de
ser, necessariamente, membro desse departamento (Exemplo 2).
4.7 Tipos de Dados
Um tipo de dado uma abstraco utilizada de forma implcita no UML.
Os tipos de dados no so elementos do modelo e por conseguinte no
lhe so associados esteretipos, marcas com valor ou restries. Um
tipo primitivo um tipo de dados que no tem uma subestrutura.
Exemplos de tipos de dados:
Primitivos: Integer, String, Time
CAPTULO 4 - UML VISO GERAL 135


Enumerados: Boolean, AggregationKind, VisibilityKind
Outros: Expression, Mapping, Name, Multiplicity
Note-se que os conceitos de nomes, expresses ou multiplicidade so
tipos de dados UML, definidos informalmente custa de outros tipos
primitivos. Por exemplo, o tipo Multiplicity definido como o com-
junto no vazio de inteiros (Integer) positivos, estendido com o carac-
ter *; o tipo Expression definido como uma sequncia de carac-
teres (String) cuja sintaxe no definida, propositadamente, pelo
UML.
Para mais detalhes consulte-se a Seco 9.2.2.
4.8 Organizao dos Artefactos Pacotes
Um pacote (package) em UML um elemento meramente organiza-
cional. Permite agregar diferentes elementos de um sistema em grupos
de forma que semntica ou estruturalmente faa sentido.
Um pacote pode conter outros elementos, incluindo: classes, interfaces,
componentes, ns, casos de utilizao, e mesmo outros pacotes. Por
outro lado, um elemento encontra-se definido em apenas um nico
pacote.
A necessidade da existncia de pacotes torna-se evidente na
modelao de sistemas de mdia/grande dimenso, em que, por razes
de ordem prtica, se torna impossvel modeliz-los de uma s vez. Os
principais benefcios da sua utilizao so: (1) facilita a gesto e procura
de artefactos; (2) evita os conflitos de nomes (e.g., X::A diferente de
X::Y:A, e diferente de Z::A); e (3) providencia um mecanismo de contro-
lo de acessos (visibilidade).
Elementos de diferentes tipos podem ter o mesmo nome dentro de um
pacote. Por exemplo, pode existir num pacote uma classe e um compo-
nente com o nome Entidade. Contudo, de modo a reduzir ou eliminar
as possveis confuses, sugere-se que tal prtica no seja adoptada.
136 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

4.8.1 Representao Grfica
Em UML os pacotes so representados graficamente por uma pasta
(tabbed folder) com duas zonas complementares: um pequeno rectn-
gulo (designado por tabulador ou tab), normalmente com o nome do
pacote; e um rectngulo maior onde normalmente se especificam os
elementos constituintes desse pacote ou, pelo menos, os seus elemen-
tos pblicos.

Figura 4.14: Exemplos de pacotes.
A Figura 4.14 ilustra alguns exemplos de representao de pacotes. No
exemplo (1) o pacote tem o nome Utilizadores e descreve os seus
elementos. Os smbolos +, - e # representam informao de visibi-
lidade, respectivamente visibilidade pblica, privada e protegida (ver
seco seguinte para mais detalhes).
O exemplo (2) ilustra uma forma alternativa de representar um pacote
em que no so apresentados os seus elementos. O nome do pacote
Regras de Negcio e encontra-se colocado no meio do rectngulo
maior.
Por fim, o exemplo (3) ilustra dois aspectos interessantes. Por um lado,
a possibilidade de relaes de hierarquia ou de incluso entre pacotes:
o pacote Docentes est contido no pacote DEI e pode ser identificado
univocamente pela concatenao dos vrios nomes separados pelo
CAPTULO 4 - UML VISO GERAL 137


smbolo ::. Outro aspecto interessante a possibilidade de caracterizar
o pacote atravs dos mecanismos comuns discutidos na Seco 4.6,
tais como especificao de marcas (e.g., {version=1.4}), estereti-
pos ou restries.
4.8.2 Relaes entre Pacotes
Os pacotes apresentam entre si diferentes tipos de relaes, em
particular relaes de importao, exportao e generalizao.
Visibilidade
Os smbolos +, - e # (ou similares, que as ferramentas CASE
proponham), semelhana do que acontece na especificao de atribu-
tos e operaes de classes, permitem indicar o tipo de visibilidade que
os elementos constituintes de um pacote apresentam.
Um elemento com visibilidade pblica (prefixado com o smbolo
+) pode ser usado/referenciado por qualquer outro elemento inde-
pendentemente do local onde definido.
Um elemento com visibilidade privada (prefixado com o smbolo -
) pode ser usado/referenciado por elementos definidos no mesmo
pacote.
Um elemento com visibilidade protegida (prefixado com o smbolo
#) pode ser usado/referenciado por um elemento definido no
mesmo pacote ou num outro pacote que seja uma especializao
(atravs da relao de herana) do primeiro.
semelhana do que acontece com algumas linguagens de
programao (e.g., C++) relativamente relao entre classes,
possvel definir-se uma relao de friend entre dois pacotes ( uma
relao de dependncia entre pacotes, com esteretipo friend). Neste
caso, um pacote que friend de outro pode aceder/referenciar todos os
seus elementos independentemente da sua visibilidade. Contudo este
tipo de dependncia deve ser evitado sempre que possvel porque viola
os princpios do encapsulamento e da minimizao de dependncias.
138 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Importao e Exportao
Um pacote faz a exportao, por definio, de todos os seus elementos
pblicos. Mas tal facto no implica que um elemento definido noutro
pacote possa aceder/referenciar um elemento exportado num outro
pacote. Para que tal pudesse ocorrer deveria existir explicitamente uma
relao de importao entre esses dois pacotes.

Figura 4.15: Relaes de importao/exportao entre pacotes.
Por exemplo, o elemento DataBase exportado no pacote DataServer
no pode ser referenciado por qualquer elemento definido em WebDEI
(ver Figura 4.15).
A relao de importao uma relao de dependncia entre pacotes,
especificando que o pacote base importa todos os elementos pblicos
definidos no pacote destino, ou seja, que os elementos pblicos
definidos no pacote destino podem ser usados por elementos no pacote
base. A relao de importao representada graficamente atravs de
uma linha dirigida, a tracejado, com esteretipo import.
Por exemplo, segundo a Figura 4.15, o pacote WebDEI importa (todos
os elementos pblicos definidos em) DEIServlets, e este por sua vez
importa todos os elementos pblicos definidos em
javax::serlets::http.
Note-se que a relao de importao no transitiva. No exemplo da
Figura 4.14, o WebDEI importa DEIServlets, e este importa
CAPTULO 4 - UML VISO GERAL 139


javax::serlets::http, no entanto WebDEI no importa o
javax::serlets::http. Isto significa que os elementos definidos em
WebDEI podem aceder aos elementos pblicos de DEIServlets, mas
no aos de javax::serlets::http. Para que tal fosse possvel,
dever-se-ia definir explicitamente uma relao de importao entre
esses dois pacotes.
Note-se, por fim, que a relao de importao no simtrica. Ou seja,
o facto dos elementos definidos em WebDEI poderem aceder aos
elementos pblicos de DEIServlets no implica que o inverso seja
verdade.
Preferencialmente, os elementos exportados por cada pacote devem
ser do tipo interface, uma vez que providenciam uma interface de pro-
gramao sem revelarem os detalhes de implementao e as relaes
de classes definidas internamente no respectivo pacote.
Generalizao
A relao de generalizao entre pacotes semelhante homloga
existente entre classes, e usada para a especificao de famlias de
pacotes, tpicas em sistemas complexos ou flexveis (e.g., significativa-
mente parametrizveis, multi-plataforma, multi-linguagem).

Figura 4.16: Relaes de generalizao entre pacotes.
140 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

A Figura 4.16 ilustra uma relao de generalizao entre pacotes. O
pacote WebServer tem duas classes pblicas (Page e Form) e uma
protegida (EventHandler) e especializado por dois pacotes distintos:
Servlets, que especializa o pacote de topo segundo a tecnologia da
Sun (Java Servlets); e ASP, que providencia a mesma funcionalidade
segundo a tecnologia da Microsoft (Active Server Pages).
4.8.3 Tipos de Pacotes
Na generalidade dos exerccios acadmicos a dimenso e/ou a
simplicidade do problema faz com que um pacote seja simplesmente
um pacote. Contudo, em situaes reais de modelao de sistemas de
software de mdia/grande dimenso, realizada por equipas de vrios
indivduos, torna-se necessrio tipificar os prprios pacotes.
A especificao actual do UML prope cinco esteretipos standard
aplicados a pacotes:
system: pacote que representa o sistema inteiro; tipicamente este
pacote agrega pacotes dos restantes tipos (subsistema, fachada,
etc.).
subsystem: pacote que representa uma parte constituinte do sis-
tema inteiro.
facade: pacote com elementos (tipicamente classes e interfaces)
que constituem a fachada (ou a interface de programao)
providenciada conjunta e coerentemente por outros pacotes. A
fachada permite esconder os detalhes de arquitectura e de
implementao de vrios elementos eventualmente organizados em
distintos pacotes. Os elementos definidos numa fachada apenas
referem outros elementos definidos noutros pacotes.
framework: um framework uma arquitectura de classes e
interfaces com inmeros pontos de variabilidade ou de extenso e
com estruturas de objectos padronizadas, conhecidas por padres
de desenho. O desenvolvimento de sistemas baseados em frame-
works e em componentes de software um tpico emergente
extremamente actual.
CAPTULO 4 - UML VISO GERAL 141


stub: um adaptador (stub) usado quando se pretende partir um
sistema em diferentes pacotes por motivos de diviso de trabalho,
quer em termos fsicos/espaciais, quer em termos temporais. Os
adaptadores permitem que duas equipas consigam trabalhar
paralelamente em diferentes locais, mas mantendo algum nvel de
interdependncia.
Em geral os pacotes mais usados so do tipo sistema e subsistema,
podendo contudo, surgir situaes em que um pacote claramente do
tipo fachada, adaptador ou framework. Por omisso assume-se que um
pacote do tipo sistema (se for de primeiro nvel) e subsistema (se for
de segundo ou mais nvel). Recomenda-se a consulta da Seco 9.5
para uma melhor compreenso dos tipos de pacotes acima referidos,
em particular, dos conceitos de framework, fachada e famlias de aplica-
o.
4.8.4 Modelao de Grupos de Elementos
Compete a cada processo de desenvolvimento de software formalizar
ou dar sugestes relativamente forma de organizar todo o processo
atravs de uma estrutura adequada de pacotes. Este aspecto anali-
sado na Parte 3 do livro.
Referem-se, no entanto, algumas das formas clssicas de organizao
dos artefactos de projectos em termos de pacotes:
Organizao por casos de utilizao: Esta a aproximao, por
exemplo, do ICONIX (ver Captulo 11) em que o sistema e respec-
tivos modelos se encontram distribudos por pacotes, consoante os
vrios casos de utilizao.
Organizao por tipos de modelos: Esta a aproximao, por
exemplo do RUP (ver Captulo 10), em que o sistema se encontra
dividido por diferentes pacotes consoante as diferentes vistas, ou
tipos de modelos produzidos. H por exemplo, um pacote (com uma
eventual hierarquia de pacotes) para o modelo de casos de
utilizao; outro para o modelo de anlise; outro para o modelo de
desenho; e outro ainda para o modelo de implementao.
Um aspecto correlacionado com o anterior, na definio e gesto dos
pacotes e dos seus correspondentes artefactos o esforo no sentido
142 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

da minimizao das dependncias entre si, assim como na minimizao
de dependncias entre os respectivos artefactos.






4.9 Exerccios
Ex.24. Das seguintes afirmaes assinale as que so verdadeiras:
O UML uma metodologia orientado por objectos.
O UML independente das ferramentas de modelao.
O UML um standard OMG.
O UML uma linguagem de programao robusta.
Ex.25. Quais so os dois aspectos importantes que se ganham com a
adopo do UML.
Ex.26. Quais so os principais tipos de relaes identificados na estru-
tura de conceitos do UML?
Ex.27. Com base em que princpio de modelao o UML prope vrios
tipos de diagramas (com base nos quais se podem produzir vi-
ses complementares de um sistema)?
Ex.28. O que uma marca com valor? Para que serve? D um exemplo
de aplicao.
Ex.29. O que um pacote UML? Enumere as trs principais motiva-
es/benefcios para a utilizao de pacotes.




Captulo 5 - UML CASOS DE UTILIZAO
Tpicos
Introduo
Casos de Utilizao
Diagramas de Casos de Utilizao
Proposta de Metodologia
Exerccios

5.1 Introduo
A engenharia de requisitos [Sommerville97, Kulak00, Cockburn00]
uma rea que se preocupa entre outros aspectos com a captura de
requisitos de um sistema de software, o seu armazenamento e respec-
tiva gesto.
Um requisito uma especificao de uma determinada aco ou
determinada condio que o sistema dever satisfazer. Um requisito
funcional descreve uma determinada aco (ou funo) que o sistema
dever suportar. Por outro lado, um requisito no funcional descreve um
aspecto (no funcional) que o sistema dever satisfazer. Requisitos
no funcionais tm a ver com aspectos gerais do sistema tais como:
desempenho, robustez, fiabilidade, distribuio, segurana, integrao
com a Internet, abertura, ou suporte de standards.
Por influncia de mtodos desenvolvidos na primeira metade da dcada
de 1990, em particular pelo mtodo de Ivar Jacobson, OOSE [Jacob-
144 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

son92], o UML inclui os diagramas de casos de utilizao (use cases)
que permitem a especificao de requisitos funcionais segundo uma
aproximao focada primordialmente nos utilizadores do sistema. A
modelao de requisitos funcionais (e mesmo o prprio desenvolvi-
mento de software) atravs de especificao de casos de utilizao
actualmente considerada como uma abordagem extremamente adequa-
da, quer por facilitar a comunicao entre a equipa de projecto e os
clientes/utilizadores, quer ainda por promover a comunicao, gesto e
conduo no desenvolvimento do prprio projecto.
Esta relao entre casos de utilizao e requisitos no pacfica e
clara. Antes pelo contrrio. H autores, por exemplo D. Kulak e E.
Guiney [Kulak00] ou C. Larman [Larman99], que consideram que os
casos de utilizao so uma boa forma de representar os requisitos. Por
outro lado, h outros autores, por exemplo D. Rosenberg [Rosenberg-
99], que consideram que requisitos e casos de utilizao so conceitos
distintos, existindo todavia relaes entre si, que devero ser captadas.

H alguns aspectos importantes na especificao de requisitos, que tm
a ver com a sua apresentao, organizao e nvel de detalhe.
Quanto sua apresentao e organizao, h autores que advogam
que os requisitos devem ser apresentados visualmente atravs de dia-
gramas de casos de utilizao e seguidamente cada caso em particular
dever ser especificado em detalhe atravs de uma descrio textual
(segundo um determinado formato definido e usado consistentemente
pela equipa de projecto) e, opcionalmente, atravs de um ou mais
diagramas de colaborao e/ou desenhos de prottipos de interfaces
homem-mquina (e.g., screenshots de prottipos de aplicaes).
Quando os requisitos so descritos textualmente, recomenda-se
normalmente que sejam numerados sequencialmente segundo, pelo
menos, duas sequncias distintas: uma para os requisitos funcionais e
outra para os requisitos no funcionais. Por outro lado, quando os requi-
sitos so baseados nos casos de utilizao, deve usar-se o elemento
pacote do UML como elemento estruturante.
A nossa opinio relativamente a estas duas posies que qualquer
uma vlida desde que seja assumida e usada consistentemente. Da
CAPTULO 5 - UML CASOS DE UTILIZAO 145


nossa experincia em projectos reais, conclumos que a aproximao
de representar e organizar os requisitos atravs de casos de utilizao
facilita, em geral, a comunicao com os utilizadores e clientes e torna
mais fcil e eficiente a sua captura e organizao.
O aspecto do nvel de detalhe da especificao de requisitos e casos de
utilizao tem a ver com o tipo de projecto em particular, o perfil e
exigncia do cliente, o tipo de sistema a especificar, etc. Consoante
essas variveis, perfeitamente possvel ter-se um caso de utilizao
tpico descrito em 1 a 3 pginas ou em 10 a 30 pginas; e, claro,
consequentemente possvel ter-se um sistema especificado numa
dezena ou em algumas centenas de pginas. O compromisso da
escolha de um nvel de detalhe adequado nem sempre fcil. Se
muito detalhado, o cliente acaba por responder um bom trabalho,
mas um pouco grande, talvez confuso, capaz de ter algumas
incoerncias, e claro que normalmente tem dificuldade de o digerir
convenientemente. Se, por outro lado, muito geral, o cliente responde
qualquer coisa como sim, isto que eu quero, mas no percebo muito
bem o que ir fazer, nem as capacidades que ir, de facto,
apresentar. A nossa experincia sugere que importante uma
reflexo, projecto a projecto, sobre o nvel de detalhe da especificao
de casos de utilizao. Em geral, prefervel a descrio de casos de
utilizao de forma no muito detalhada, variando entre uma a cinco
pginas.
5.2 Casos de Utilizao
Um caso de utilizao uma sequncia de aces que um ou mais
actores realizam num sistema de modo a obterem um resultado parti-
cular [OMG99].
O modelo de casos de utilizao permite capturar os requisitos de um
sistema atravs do detalhe de todos os cenrios que os utilizadores
podem realizar. Os casos de utilizao, mais que iniciar a modelao de
requisitos de um sistema, dirigem/conduzem todo o processo de
desenvolvimento.
146 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Um caso de utilizao representado graficamente atravs de uma oval
com uma frase que representa uma determinada aco. A frase deve
ser escrita na voz activa, com um verbo no infinitivo. Por exemplo,
Submeter Proposta, Criar factura, Calibrar roda ou Validar
utilizador conforme ilustrado na Figura 5.1.

Figura 5.1: Representao grfica de casos de utilizao.
Um caso de utilizao deve descrever o que faz um sistema (ou parte
deste), mas no como que tal realizado. O foco portanto na viso
externa do sistema, ou seja, na viso que os utilizadores tm dele.
5.2.1 Casos de utilizao e Cenrios
Um cenrio uma determinada sequncia de aces que ilustra um
comportamento do sistema. Numa definio mais abstracta, deve-se
entender um cenrio como uma instncia de um caso de utilizao,
sendo normal que um caso de utilizao possa ser descrito por dezenas
de possveis cenrios. Uma designao alternativa para cenrio por
vezes utilizada fluxo de aces.
Deve-se especificar o comportamento de um caso de utilizao descre-
vendo textualmente um ou mais fluxos de aces, de modo que um
utilizador no tcnico o possa entender sem dificuldade. Tal especifica-
o deve incluir:
Como e quando o caso de utilizao comea e termina
Quando que o caso de utilizao interactua com os actores
Que objectos so trocados
Cenrio principal, e
Cenrios alternativos (e.g., situaes de excepo)
CAPTULO 5 - UML CASOS DE UTILIZAO 147



Outras formas alternativas ou complementares, podem ainda incluir a
especificao de pr e ps condies, os actores que iniciam o caso de
utilizao, os actores que beneficiam com o caso de utilizao, um ou
mais diagramas de interaco, etc.
Como exemplo apresenta-se de seguida a especificao textual do caso
de utilizao Validar Utilizador ilustrado na Figura 5.1. Considere-se
que este caso de utilizao pertence a um sistema tipo caixa de multi-
banco.
Exemplo 5.1: Especificao textual do caso de utilizao Validar
Utilizador.
Nome: Validar Utilizador
Cenrio Principal
O caso de utilizao inicia-se quando o sistema apresenta um ecr a
pedir ao cliente o seu carto electrnico. O cliente introduz o seu carto
MB e, atravs de um pequeno teclado, o seu PIN. Note-se que o cliente
pode limpar a introduo do seu PIN inmeras vezes e reintroduzir um
novo nmero antes de activar o boto Entrar. O cliente activa o boto
Entrar para confirmar. O sistema l o PIN e a respectiva identificao
do carto MB, e verifica se vlido. Se o PIN for vlido o sistema aceita
a entrada e o caso de utilizao termina.
Cenrio Alternativo 1 (Cliente cancela operao)
O cliente pode cancelar a transao em qualquer momento activando o
boto Cancelar, implicando a reinicializao do caso de utilizao. No
realizada qualquer alterao conta do cliente.
Cenrio Alternativo 2 (PIN invlido)
Se o cliente introduz um PIN invlido, o carto MB ejectado e o caso
de utilizao reinicializado. Se tal ocorrer 3 vezes consecutivas, o
sistema cativa (i.e., recolhe) o carto MB e cancela a transao; no
permitindo qualquer interaco nos 2 minutos seguintes.
148 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Um aspecto importante na especificao do caso de utilizao tem a ver
com o nvel de detalhe do mesmo. A dimenso da especificao de um
caso de utilizao varia significativamente consoante o tipo de projecto
envolvido, os intervenientes do projecto, e as exigncias impostas pelos
clientes. Essa especificao normalmente textual, de modo mais ou
menos informal, mas pode ser complementada por diagramas de
interaco (para ajudar a clarificar as interaces entre os diferentes
intervenientes); ou at por prottipos de interfaces com utilizadores
(e.g., desenho de ecrs ou de listagens tipo).
Todavia, sempre que possvel, deve-se evitar adoptar uma linguagem
dependente da implementao e de aspectos tecnolgicos. Designada-
mente, deve-se evitar referir explicitamente: pessoas, em vez de papis
desempenhados; departamentos especficos de uma organizao;
componentes de interface com o utilizador (e.g., botes, menus, caixas
de texto, scrollbars); ou referncias a dispositivos hardware. Deve-se
igualmente evitar descries em formatos tcnicos ou formais, tais
como pseudocdigo ou especificaes em OCL [Warmer99], ou Z
[Diller94].
5.2.2 Relaes entre Casos de Utilizao
Os casos de utilizao podem encontrar-se relacionados atravs de trs
tipos de relaes: generalizao, incluso e extenso. Estas relaes
potenciam significativamente a reutilizao da especificao de
requisitos. Ou seja, estas relaes permitem ao analista aquilo que o
programador de linguagens orientadas por objectos normalmente
pratica: reutilizar trabalho j efectuado. Este um aspecto essencial da
filosofia dos casos de utilizao e que normalmente no facilmente
apreendido pelos praticantes inexperientes.
Repare-se que o objectivo, neste contexto, no a reutilizao de
cdigo, mas sim a reutilizao de especificaes (normalmente tex-
tuais), com todos os benefcios da decorrentes.
Generalizao
Uma relao de generalizao entre casos de utilizao permite
definir casos custa de outros j existentes, pelo mecanismo de especi-
CAPTULO 5 - UML CASOS DE UTILIZAO 149


alizao, ou alternativamente, permite definir casos mais abstractos a
partir de casos concretos pelo mecanismo da reduo ou generalizao.
O caso de utilizao filho herda o comportamento e semntica do seu
pai, pode substituir especificaes definidas no seu pai, bem como,
pode introduzir novas especificaes que lhe sejam especficas.

Figura 5.2: Relao de generalizao entre casos de utilizao.
A Figura 5.2 ilustra a relao de generalizao entre casos de
utilizao. Na prtica ilustra que o caso Validar Utilizador
especializado em outros dois, que utilizam diferentes mecanismos de
identificao do utilizador: Testar Password e Leitura com Smartcard.
Incluso
A relao de incluso (include) entre casos de utilizao
corresponde a uma relao tpica de delegao, significando que o caso
base incorpora o comportamento do outro caso relacionado. Usa-se a
relao de incluso para evitar a descrio dos mesmos fluxos de
aces inmeras vezes. A relao de incluso representada por uma
relao de dependncia (seta a tracejado) com o esteretipo include.
150 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE


Figura 5.3: Relao de incluso entre casos de utilizao.
A Figura 5.3 ilustra um exemplo de utilizao da relao de incluso.
Considere-se uma vez mais o exemplo da caixa de multibanco acima
apresentado. Os casos de utilizao Obter Extracto de Conta ou
Realizar Pagamentos exigem que seja realizada previamente uma
validao do respectivo utilizador. Para que essa funcionalidade no
seja especificada mais que uma vez, os casos anteriores incorporam-na
(como sua) ao estabelecerem uma relao de incluso com o caso
Validar Utilizador.
A questo importante que se coloca como indicar, em que ponto da
especificao, o caso de utilizao relacionado deve ser incorporado no
caso base. Este um aspecto essencial na compreenso e domnio dos
casos de utilizao. A explicitao desta informao deve ser efectuada
na especificao textual do caso de utilizao. O Exemplo 5.2 clarifica
esta questo com a descrio textual do caso Obter Extracto em que
evidente a indicao do ponto de incluso atravs do texto Incluir.
Exemplo 5.2: Especificao textual do caso de utilizao Obter
Extracto de Conta.
Nome: Obter Extracto de Conta
Cenrio Principal
Incluir caso de utilizao Validar Utilizador. Obter e verificar o nmero
da conta.. Seleccionar todas as linhas de movimentos realizados nos
CAPTULO 5 - UML CASOS DE UTILIZAO 151


ltimos 30 dias. Produzir uma lista resumo com esses movimentos,
apresentando a data, o tipo de movimento (dbito ou crdito), uma
breve descrio e o valor do movimento. Produzir o saldo corrente da
conta. Emitir um documento com essa informao, ejectando no
terminal de Multibanco o referido documento. Apresentar mensagem no
visor do terminal para o cliente retirar o extracto. Registar na conta do
cliente que esta operao foi realizada com sucesso.
Cenrio Alternativo 1


Extenso
Uma relao de extenso (extend) entre casos de utilizao signi-
fica que o caso base incorpora implicitamente o seu comportamento
num local especificado indirectamente pelo caso que usado. Ou seja,
o caso destino pode ser estendido com o comportamento de outro(s)
caso(s). Uma relao de extenso permite representar:
A parte de um caso que um utilizador v como opcional, ou como
existindo vrias alternativas.
Um subfluxo de aces que executado apenas se determinadas
condies se verificarem.
Vrios fluxos de aces que podem ser inseridos num determinado
ponto de extenso, de forma controlada, atravs de uma interaco
explcita com um actor.
O caso de utilizao destino estendido num ou mais pontos,
designados por pontos de extenso os quais so mecanismos de
variabilidade [Jacobson97]. Ou seja, so pontos de entrada do caso de
utilizao que lhe d algum nvel de configurabilidade e versatilidade.
(Nota: Os pontos de extenso so um dos mecanismos de variabilidade
mais comuns no desenho de sistemas de componentes, de frameworks
aplicacionais ou de frameworks de middleware, que exigem exacta-
mente um elevado grau de versatilidade.)
152 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE


Figura 5.4: Relao de extenso entre casos de utilizao.
Considere-se o caso Obter Extracto de Conta do exemplo anterior. Na
descrio textual do Exemplo 5.2, a especificao do nmero de dias
respeitantes seleco dos movimentos a visualizar era esttica (30
dias). Numa situao mais flexvel, o ideal que o cliente/utilizador
pudesse seleccionar o nmero de dias pretendido, ou simplesmente
activar um boto para indicar que pretendia seleccionar os movimentos
relativos aos ltimos 30 dias.
Figura 5.4 ilustra esta situao atravs da utilizao da relao de
extenso, representada por uma relao de dependncia (seta a
tracejado) com o esteretipo extend. Pelo facto do caso de utilizao
destino poder ter vrios pontos de extenso, especifica-se, na relao
de extenso, qual o ponto de extenso a que diz respeito (neste caso
(N. de dias)).
O Exemplo 5.3 ilustra a forma de representao textual dos pontos de
extenso nos casos de utilizao, bem como, a especificao textual de
um caso de utilizao que permite estender outro num determinado
ponto de extenso.




CAPTULO 5 - UML CASOS DE UTILIZAO 153



Exemplo 5.3: Especificao textual do caso de utilizao Obter
Extracto de Conta revisto.
Nome: Obter Extracto de Conta
Pontos de Extenso:
N. de dias
Cenrio Principal
Incluir caso de utilizao Validar Utilizador. Obter e verificar o nmero
da conta. Seleccionar o n. de dias com base no qual se produz o
extracto. (N. de dias). Por omisso so seleccionados os ltimos 30
dias. Produzir uma lista resumo com esses movimentos, apresentando
a data, o tipo de movimento (dbito ou crdito), uma breve descrio e o
valor do movimento. Produzir o saldo corrente da conta. Emitir um
documento com essa informao produzida ejectando no terminal de
Multibanco o referido documento. Apresentar mensagem no visor do
terminal para o cliente retirar o extracto. Registar na conta do cliente
que esta operao foi realizada com sucesso.

Cenrio Alternativo 1







154 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Exemplo 5.4: Especificao textual do caso de utilizao
Selecciona N. de Dias.
Nome: Selecciona N. de Dias
Tipo: Abstracto
Cenrio Principal
apresentado um ecr em que o utilizador pode especificar o n. de
dias desejado, atravs da marcao em vrios botes numricos (de 0
a 9). H uma caixa de texto construda dinamicamente que vai
apresentando o valor corrente. Por fim, o utilizador marca o boto
Confirmar e o valor construdo retornado ao caso destino no seu
respectivo ponto de extenso.

Cenrio Alternativo 1
Idntico ao cenrio principal. Em qualquer momento o utilizador pode
marcar sobre o boto Apagar de modo a apagar o algarismo
introduzido mais recentemente.
Cenrio Alternativo 2
Idntico ao cenrio principal. Quando o utilizador marca Confirmar e o
valor introduzido for superior a 59 dias apresentada uma mensagem
de aviso que o nmero mximo 59, e o caso reiniciado.
Cenrio Alternativo 3
Idntico ao cenrio principal. Em qualquer momento outilizador pode
seleccionar o boto Cancelar O caso termina e retornado o valor 1
(dia) por omisso.

Em situaes reais este tipo de relaes pode-se complicar significativa-
mente. Imagine-se por exemplo, que um outro ponto de extenso a
lngua escolhida que ter como consequncia que todas as interfaces
com o utilizador sejam compatveis com a lngua respectiva.
CAPTULO 5 - UML CASOS DE UTILIZAO 155


5.3 Diagramas de Casos de Utilizao
Um diagrama de casos de utilizao ilustra um conjunto de casos de
utilizao, de actores e suas relaes (ver Figura 5.5). As suas aplica-
es comuns so:
Para modelar o contexto de um sistema. Neste caso, a nfase
encontra-se na identificao da fronteira do sistema, dos seus ac-
tores e no significado das suas funes.
Para modelar os requisitos de um sistema. Consiste na identificao
do que o sistema deve fazer, independentemente de como o siste-
ma o deve realizar.
A ligao entre um actor e um caso de utilizao corresponde a uma
relao de comunicao (de esteretipo communicate) entre estes
dois elementos. representada por uma linha a cheio e em geral sem
setas, pois a comunicao entre o actor e o caso pode ser em ambos os
sentidos, ou pode nem sequer ser relevante (ou possvel) determinar
essa informao.

Figura 5.5: Diagrama de casos de utilizao.
5.3.1 Actores
Um actor o conceito que representa, em geral, um papel que um
utilizador desempenha relativamente ao sistema em anlise. Todavia,
um actor no necessariamente um papel de um utilizador; pode cor-
156 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

responder a um papel desempenhado por um outro sistema informtico,
por um equipamento hardware especializado, ou pela simples pas-
sagem de tempo. O conjunto total de actores de todos os casos de utili-
zao reflecte todos os elementos que interactuam com o sistema.
O cone do esteretipo actor representa por omisso a figura de um
indivduo, mas podem-se definir outros esteretipos (com respectivos
cones) para diferentes tipos de actores.
Um determinado utilizador pode desempenhar diferentes papis, poden-
do, por conseguinte, representar diferentes actores. Por exemplo, na
situao da caixa Multibanco, poder-se-o identificar pelo menos dois
actores: o cliente do banco, que acede ao sistema para realizar variadas
operaes bancrias; e o operador da agncia ou da caixa, que res-
ponsvel pela sua activao, por carregar dinheiro na mquina, etc.
Os actores podem encontrar-se relacionados atravs de relaes de
generalizao, conforme ilustrado na Figura 5.6, o que significa que o
actor-filho (na relao de generalizao) herda todas as funcionalidades
e todos os papis do seu actor-pai, podendo adicionalmente apresentar
as suas prprias funcionalidades.

Figura 5.6: Relao de hierarquia entre actores.
5.3.2 Casos de Utilizao Abstractos e Concretos
Por definio, um caso de utilizao abstracto um caso que no
apresente uma relao de comunicao com qualquer actor. Por outro
lado, um caso de utilizao concreto um caso que no abstracto.
CAPTULO 5 - UML CASOS DE UTILIZAO 157


O nome dos casos abstractos representado a itlico de forma a
distingui-los dos casos concretos (ver Figuras 5.8 e 5.9).
Este tipo de casos de utilizao so tipicamente casos envolvidos em
relaes de generalizao (e.g., o caso pai), incluso (o caso destino)
ou de extenso (o caso base) com outros casos de utilizao. O objec-
tivo destes casos abstractos dar ao modelo um nvel elevado de reuti-
lizao e de flexibilidade, como se viu na Seco 5.2.
5.4 Proposta de Metodologia
Apesar da estrutura de conceitos associada aos diagramas de casos de
utilizao ser relativamente simples, como se viu nas seces anterio-
res, a prtica vem mostrar que a sua aplicao no trivial, havendo
inmeras situaes de utilizao incorrecta. Propomos nesta seco
uma metodologia para desenho de diagramas de casos de utilizao de
forma a ajudar o leitor nesta actividade aparentemente fcil de realizar.
Para facilitar a discusso, considere-se o exemplo de um sistema
Mquina de Bebidas. Uma mquina de bebidas um sistema coloca-
do normalmente em locais estratgicos, por onde passa muita gente,
como sejam paragens de metro, recintos desportivos, escolas, etc.
A metodologia proposta consiste na aplicao sucessiva dos seguintes
passos:
1) Identificar os actores do sistema, ou seja, o perfil de indivduos e de
outros sistemas que interactuam com o sistema original.
2) Identificar, para cada actor, os seus casos de utilizao principais.
Note-se que podem existir casos que envolvam a participao de
mais que um actor.
3) Com base nos casos de utilizao originais, identificar, factorizar e
colocar em evidncia casos de utilizao que sejam recorrentes em
mais que um dos casos originais. Nessa situao, cria-se o novo
caso de utilizao (em geral um caso abstracto) e os casos
originais envolvidos estabelecem uma relao de incluso com o
dito caso. Repetir o processo at no se conseguir identificar
qualquer outro caso a reutilizar.
158 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

4) Para tratar casos de utilizao que pretendam ser flexveis e ver-
steis, definir pontos de extenso (ou de variabilidade) e conjunta-
mente definir um ou mais casos de utilizao (abstractos) que os
permitam estender nesses pontos. Nesta situao, cria-se uma rela-
o de extenso do caso abstracto para o caso estendido.
5) Especificar textualmente cada caso de utilizao segundo um
determinado formato previamente definido. No esquecer nesta
especificao textual a explicitao dos pontos de extenso e de
incluso anteriormente identificados.
Tendo em conta a metodologia proposta, o passo 1 comea com a
identificao dos actores do sistema bem como das suas principais ac-
tividades. Identificamos trs actores: (1) o cliente, que compra a bebida;
(2) o agente do fornecedor, que responsvel por carregar as bebidas
na mquina; e (3) o dono da mquina, que responsvel por retirar o
dinheiro da mquina.
No passo 2 foram identificados os principais casos. A Figura 5.7 ilustra
a verso preliminar do respectivo diagrama de casos de utilizao.
Neste passo crucial a escolha do nvel de granularidade adequado
para captar os casos envolvidos. Recorde-se a definio de caso de
utilizao para se realizar essa escolha. Note-se que um caso no
simplesmente uma aco, ou mesmo uma sequncia de aces,
mas sim uma sequncia de aces que um ou mais actores realizam
num sistema de modo a obterem um resultado particular.
Note-se que o caso Repor Bebidas realizado conjuntamente pelo
agente do fornecedor de bebidas e pelo dono da mquina, este ltimo
responsvel por abrir a mquina e supervisionar o processo envolvido.
CAPTULO 5 - UML CASOS DE UTILIZAO 159



Figura 5.7: Diagrama de casos de utilizao da Mquina de Bebidas
preliminar.
Passando para o passo 3 da metodologia acima enunciada, deve-se
identificar comportamentos comuns realizados por mais que um dos
casos do sistema. Neste exemplo, constata-se que os casos Repor
Bebidas e Retirar Dinheiro envolvem dois tipos de aces comuns
Abrir Mquina e Fechar Mquina. Este facto deve ser factorizado
atravs de dois casos de utilizao correspondentes e devem ser esta-
belecidas as respectivas relaes de incluso (ver Figura 5.8).
160 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE


Figura 5.8: Diagrama de casos de utilizao da Mquina de Bebidas
com incluso.
O passo 4 da metodologia pressupe que a anlise dos casos de
utilizao existentes e que seja avaliada a necessidade da criao de
pontos de extenso para um ou mais casos. No exemplo, vamos
considerar que o caso Repor Bebidas tem um ponto de extenso
designado por encher prateleira, que permite associar ao caso de
utilizao um ou mais casos abstractos que providenciem diferentes
algoritmos para a reposio de bebidas nas prateleiras.
CAPTULO 5 - UML CASOS DE UTILIZAO 161



Figura 5.9: Diagrama de casos de utilizao da Mquina de Bebidas
com extenso
A Figura 5.9 ilustra essa situao com o caso Repor Bebidas de
Acordo com as Vendas, a reposio de bebidas na mquina tem em
conta o nmero de bebidas vendidas, implicando que se colocam mais
latas das bebidas mais vendidas. Note-se que poder-se-iam definir
outros casos de extenso abstractos, que implementavam diferentes
algoritmos ou estratgias de reposio de bebidas; por exemplo: repor
bebidas de forma uniforme (o mesmo nmero de latas, por tipo de be-
bida); repor bebidas de acordo com a marca; etc.
162 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

5.5 Exerccios
Ex.30. Indique 2 vantagens da visualizao de um caso de utilizao.
Ex.31. Com base no exemplo da Mquina de Bebidas descrito na
Seco 5.4 complete a descrio dos requisitos do sistema ao
especificar textualmente os casos de utilizao definidos (passo
5 da metodologia proposta).
Ex.32. Esboce um diagrama de casos de utilizao para um controlo
remoto de TV. Garanta que inclui todas as funes do controlo
remoto como casos de utilizao do seu modelo. Descreva
textualmente os casos de utilizao Ligar TV e Seleccionar
Canal. Sugesto: Considere que a TV tem um sistema de
password, configurado opcionalmente, para que os pais tenham
a garantia que os filhos no passem muitas horas em frente ao
televisor!
Ex.33. Analise os processos RUP e ICONIX e discuta as suas
respectivas interpretaes relativamente aos conceitos requisi-
tos e casos de utilizao.
Ex.34. Discuta as vantagens/desvantagens da aplicao de diagramas
de casos de utilizao na produo de cadernos de encargo
e/ou propostas de sistemas de software.
Ex.35. Discuta as vantagens/desvantagens da adopo de um estilo de
escrita dos casos de utilizao na ptica dos seus utilizadores.
Sugesto: considere a possibilidade de gerao de documen-
tao.
Ex.36. Considere o sistema de uma equipa de futebol constitudo pelos
seguintes actores: jogador, treinador, atacante, guarda-redes,
mdio, defesa, presidente. Desenhe o respectivo diagrama de
casos de utilizao. Sugesto: considere por exemplo os seguin-
tes casos: jogar, treinar, defender a baliza, pagar ao jogador,
pagar ao treinador, vender jogador, contratar jogador, contratar
treinador, despedir treinador.
CAPTULO 5 - UML CASOS DE UTILIZAO 163


Ex.37. Faa um diagrama de casos de utilizao a partir do manual de
utilizador de uma determinada aplicao. Considere por exemplo
o Word da Microsoft ou outra qualquer aplicao do seu conheci-
mento.
164 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE



Captulo 6 - UML MODELAO DA
ESTRUTURA
Tpicos
Introduo
Classes
Relaes
Interfaces
Instncias e Objectos
Diagramas de Classes e Diagramas de Objectos
Exemplos e Recomendaes
Exerccios

6.1 Introduo
A modelao da estrutura de um sistema de software consiste principal-
mente, segundo a abordagem orientada por objectos, na identificao
de classes e suas respectivas relaes.
Um objecto reflecte em geral uma entidade do mundo real e apresenta
um estado e comportamento prprio. Os objectos interactuam entre si
por troca de mensagens. Uma classe consiste numa estrutura que
permite criar objectos semelhantes; i.e., que apresentem estado e com-
portamento semelhante. Neste sentido diz-se que uma classe uma
fbrica de objectos e que um objecto uma instncia de uma classe.
166 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

O UML providencia os seguintes elementos, que permitem a
especificao da estrutura ou esttica de um sistema de software:
classes, relaes, interfaces, objectos. Com base nestes elementos
podem-se definir dois tipos de diagramas com fins complementares: dia-
gramas de classes e diagramas de objectos, que so o foco dos concei-
tos em anlise neste captulo.
(Consulte-se o Captulo 3 e em particular a Seco 3.5 para mais
detalhes sobre estes conceitos e uma discusso geral sobre as metodo-
logias orientadas por objectos.)
6.2 Classes
Uma classe a descrio de um conjunto de objectos que partilham os
mesmos atributos, operaes, relaes e a mesma semntica. Uma
classe corresponde a algo tangvel ou a uma abstraco conceptual
existente no domnio do utilizador ou no domnio do engenheiro de sof-
tware.
Uma classe bem estruturada simples e facilmente entendida;
providencia uma abstraco definida a partir do vocabulrio do domnio
do problema ou do domnio da soluo; agrega um conjunto restrito e
bem definido de responsabilidades; e providencia uma separao clara
entre a especificao abstracta e a sua implementao.
Uma classe representada em UML por um rectngulo (ver Figura 6.1)
com uma, duas ou trs seces. Na primeira seco apresenta-se o
nome da classe, na segunda a sua lista de atributos, e na terceira a sua
lista de mtodos. Pode ainda ter, opcionalmente, uma quarta seco,
onde se poder especificar outra informao (e.g., a lista de responsa-
bilidades que a classe assume).
O nome de uma classe (tal como de qualquer outro elemento do UML)
pode ser apresentado na forma simples ou na sua forma completa.
Nesta ltima situao, o nome do elemento precedido pelo(s) nome(s)
do(s) pacote(s) onde se encontra definido, separado pela string ::.
CAPTULO 6 - UML MODELAO DA ESTRUTURA 167



Figura 6.1: Representao de uma classe em UML.
Nas segundas e terceiras seces do cone de classe apresentam-se
respectivamente os seus atributos e os seus mtodos, que podem
apresentar-se com maior ou menor detalhe (ver Figura 6.2).
Na definio de atributos podem-se visualizar apenas os seus nomes,
ou adicionalmente os respectivos tipos, ou ainda a visibilidade (e.g., se
um atributo pblico, privado, protegido) ou outras qualificaes (e.g.,
se varivel esttica). A definio completa de um atributo expressa
por:
visibility name [ multiplicity ] : type-expression = initial-value {
property-string }
A multiplicity permite especificar a multiplicidade de um atributo. Por
omisso assume-se multiplicidade 1..1 (exactamente um). O initial-value
permite especificar o valor inicial do atributo, i.e., o valor que o atributo
contm no momento da sua criao. Tambm um parmetro opcional
(bem como o sinal = que o precede). O property-string especifica valo-
res de propriedades que se podem aplicar ao elemento. Tambm um
parmetro opcional (bem como os parntesis-chavetas que o envol-
vem).
Na definio de operaes (ou mtodos) podem-se visualizar apenas os
seus nomes, ou adicionalmente as respectivas assinaturas, ou ainda
visibilidade (e.g., se operao pblica, privada, protegida) ou outras
qualificaes (e.g., se abstracta ou polimrfica). A definio completa
de uma operao expressa por:
visibility name ( parameter-list ) : return-type-expression { property-
string }
168 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE



Figura 6.2: Apresentao dos atributos e operaes de uma classe.
Podem-se definir subseces dentro da segunda ou terceira seco de
forma a melhor organizar e manter os atributos e operaes de uma
classe. Tal realizado com base na noo de esteretipo conforme ilus-
trado na Figura 6.3.

Figura 6.3: Usando esteretipos para organizar a lista de operaes de
uma classe.
CAPTULO 6 - UML MODELAO DA ESTRUTURA 169


6.3 Relaes
Uma relao em UML estabelece a ligao entre elementos e repre-
sentada graficamente por um determinado tipo de linha. Na modelao
orientada por objectos os trs tipos de relaes mais importantes so
(1) dependncias; (2) generalizaes; e (3) associaes, que de segui-
da se descrevem.
6.3.1 Relao de Dependncia
Uma relao de dependncia, ou simplesmente dependncia, indica
que a alterao na especificao de um elemento pode afectar outro
elemento que a usa, mas no necessariamente o oposto. A dependn-
cia representada em UML atravs de uma linha dirigida a tracejado.
No contexto de classes, usam-se dependncias para ilustrar que uma
classe usa outra classe como argumento na assinatura de uma das
suas operaes ou como tipo na definio dos seus atributos. Por
motivos de simplicidade e clareza no se explcita em geral este tipo de
relaes nos diagramas de classes, j que esse tipo de dependncia
encontra-se especificado implicitamente.
Contudo, em UML as dependncias so usadas, entre outros elemen-
tos, de modo mais pertinente, nomeadamente com elementos do tipo
pacotes e notas.
A Figura 6.4 ilustra um exemplo da relao de dependncia entre as
classes SensorTemperatura e Temperatura.

Figura 6.4: Dependncia entre classes.
170 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

6.3.2 Relao de Generalizao
Uma relao de generalizao, ou simplesmente generalizao, uma
relao entre um elemento geral (e.g., superclasse, super-caso-
utilizao, super-pacote) e um elemento mais especfico (e.g., sub-
classe, sub-caso-utilizao, sub-pacote). Geralmente conhecida como
uma relao do tipo is-a ou is-a-kind-of representada em UML por
uma linha dirigida a cheio com um tringulo a branco num seu extremo.
No contexto de classes usam-se generalizaes para ilustrar as rela-
es de herana conhecidas das linguagens de programao orienta-
das por objectos.
A herana providencia um mecanismo natural e potente de organizao
dos programas de software ao permitir: (1) que cada subclasse herde o
estado e comportamento de uma superclasse; (2) subclasses podem
adicionar o seu prprio estado e comportamento; e (3) as subclasses
podem ainda alterar os mtodos (i.e., comportamento) herdados, provi-
denciando implementaes especializadas desses mtodos.
Os benefcios conhecidos da herana tm a ver com (1) possibilidade
de reutilizao do cdigo definido na superclasse numa ou mais
subclasses; e (2) definio de frameworks (programas com estruturas
quase-completas) atravs de classes abstractas que definem comporta-
mentos genricos e/ou estilos de desenho comuns.
A Figura 6.5 exemplifica a aplicao da relao de generalizao entre
classes num sistema de representao de figuras geomtricas. A classe
FiguraGeomtrica especializada em duas hierarquias distintas,
mas no disjuntas, de subclasses. Por um lado, conforme a dimenso
forma, tem-se as subclasses Rectngulo, Crculo e Polgono (a
classe Rectngulo por sua vez uma generalizao da classe
Quadrado). Por outro lado, conforme a adopo ou no de etiqueta,
tem-se as subclasses ComEtiqueta e SemEtiqueta. Por fim, tem-se
a subclasse CrculoComEtiqueta que uma combinao entre as
duas dimenses.
Note-se neste exemplo que a FiguraGeomtrica uma classe
abstracta (por isso, o seu nome apresentado a itlico) que define o
comportamento geral de todas as suas subclasses.
CAPTULO 6 - UML MODELAO DA ESTRUTURA 171



Figura 6.5: Relao de generalizao entre classes.
Por omisso uma relao de generalizao representa uma decom-
posio disjunta ou exclusiva. No entanto outras semnticas podem
ocorrer, caso sejam especificadas atravs das seguintes restries:
Generalizao disjunta {disjoint}: o tipo de generalizao por
omisso, que especifica o facto de uma classe descendente de X
poder ser apenas descendente de uma das subclasses de X.
Generalizao sobreposta {overlapping}: especifica o facto de
uma classe descendente de X pertence ao produto cartesiano das
subclasses de X (no exemplo da Figura 6.5, a classe
CrculoComEtiqueta uma combinao das subclasses de
FiguraGeomtrica).
Generalizao completa {complete}: vs. incompleta
{incomplete}: especifica o facto de uma generalizao ser
completamente especificada (o caso da decomposio segundo a
dimenso etiqueta no exemplo da Figura 6.5) ou no.
6.3.3 Relao de Associao
Uma relao de associao, ou simplesmente associao, uma
relao estrutural que especifica que objectos de uma classe esto
ligados a objectos de outra.
172 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

A Figura 6.6 ilustra a associao de posse entre as classes
Utilizador e Password, com uma multiplicidade de 1 para muitos
(1-N). A associao indica que um utilizador tem vrias (0 ou mais)
passwords e que uma password pertence necessariamente a um utiliza-
dor.

Figura 6.6: Relao de associao entre classes.
Uma associao representada em UML por uma linha a cheio
complementada por um conjunto de adornos que especificam diferentes
informaes (ver Figura 6.7), tais como:
O nome;
O papel de cada participante na associao;
A multiplicidade de cada participante na associao;
O tipo de agregao.

Figura 6.7: Adornos comuns usados em relaes de associao.
As associaes podem ainda incluir outros adornos, cuja utilizao em
geral menos comum: navegao, visibilidade e qualificao.
CAPTULO 6 - UML MODELAO DA ESTRUTURA 173


Multiplicidade
A multiplicidade traduz o nmero de instncias de uma classe que se
podem relacionar (atravs da associao) com uma nica instncia
da(s) outra(s) classe(s) participante(s). Pode-se especificar em UML
qualquer tipo de multiplicidade. Por exemplo, multiplicidade muitos (*),
um ou mais (1..*), exactamente um (1), zero ou um (0..1), um deter-
minado nmero (e.g., 3), uma determinada gama (e.g., 2..6), ou ms-
mo uma multiplicidade mais complexa especificada atravs de listas
(e.g., 0..3, 5..7, 10..* para representar qualquer nmero de ob-
jectos excepto 4, 8 ou 9).
Navegao
A navegao traduz a forma como a partir de uma instncia de uma
classe se pode aceder a uma ou mais instncias de outra classe
relacionada pela associao. Por omisso a navegao numa
associao bidireccional. Contudo, h situaes, em particular j na
fase de desenho, que o que se pretende representar uma associao
unidireccional.

Figura 6.8: Navegao numa relao de associao.
Considere-se o diagrama da Figura 6.8 e que na fase de desenho
chegou-se concluso da seguinte situao: Dado um utilizador
consegue-se obter todas as respectivas instncias de password. Mas
dado uma password no possvel (ou relevante) obter-se o respectivo
utilizador. A Figura 6.8 ilustra a utilizao do adorno de navegao para
tratar esta situao.
174 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Agregao (Simples)
A associao entre classes sem agregao reflecte que ambas as
classes se encontram no mesmo nvel conceptual. Por outro lado, uma
relao de associao com agregao traduz que existe uma relao
do tipo is-part-of ou has-a, o que corresponde ao facto de uma
instncia de determinada classe possuir ou ser composta por vrias
instncias de outra classe. O adorno de agregao representado por
um losango colocado junto classe que representa o elemento agrega-
dor ou o todo.
A associao de agregao traduz apenas o facto de uma classe ser
composta por diferentes outras classes, suas componentes.
A Figura 6.9 ilustra a relao de agregao entre vrias classes. Na
prtica a descrio das diferentes componentes que compem um
computador pessoal (PC).

Figura 6.9: Agregao simples numa relao de associao.
Composio (Agregao Composta)
A composio, ou agregao composta, uma variante agregao
simples, em que adicionada a seguinte semntica: (1) forte pertena
do todo em relao parte, e (2) tempo de vida delimitado (as par-
tes no podem existir sem o todo). Adicionalmente, o todo respon-
svel pela disposio das suas partes, ou seja, o todo responsvel
pela criao e destruio das suas partes.
CAPTULO 6 - UML MODELAO DA ESTRUTURA 175


O adorno de agregao composta representado por um losango a
cheio colocado junto classe que representa o elemento agregador ou
o todo.

Figura 6.10: Agregao composta numa relao de associao.
A Figura 6.10 ilustra um exemplo de uma associao com agregao
composta, de forma a reflectir o facto que um Departamento no existe
fora do contexto de uma Empresa.
Associaes Qualificadas
Um qualificador um atributo, ou lista de atributos, cujos valores
servem para partir o conjunto de instncias associadas a uma instncia
ao longo de uma associao. Os qualificadores so atributos da as-
sociao [OMG99].
Um qualificador representado graficamente por um pequeno
rectngulo junto de um extremo de uma associao. O rectngulo
qualificador faz parte da associao e no do qualificador(es) que
contem. O qualificador colocado no extremo (da classe) origem da
associao. Uma instncia da classe origem, conjuntamente com um
valor do qualificador, permite seleccionar univocamente um subconjunto
das instncias da classe destino, i.e. da classe do outro extremo da
associao.
A multiplicidade afecta ao extremo destino denota a cardinalidade do
conjunto das instncias da classe destino, com base no par de infor-
mao: instncia de origem e valor do qualificador. Os valores comuns
so:
176 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

0..1: um nico valor pode ser seleccionado ou eventualmente
nenhum.
1: um nico valor tem de ser seleccionado.
*: o valor do qualificador um ndice que agrega as instncias
destino em diferentes subconjuntos.

Figura 6.11: Associao com qualificador.
A Figura 6.11 ilustra dois exemplos de associaes com qualificador
entre as classes Banco e Pessoa e entre TabuleiroXadrez e
Quadrado.
Associaes Reflexivas
Uma associao diz-se reflexiva quando estabelece uma relao
estrutural consigo prpria. Este tipo de associao acontece quando
uma classe tem objectos que desempenham diferentes papis. Por
exemplo, um ocupante de um carro pode desempenhar o papel de
condutor ou de passageiro (ver Figura 6.12).

Figura 6.12: Associao reflexiva.
CAPTULO 6 - UML MODELAO DA ESTRUTURA 177


Visualmente fcil identificar associaes reflexivas pelo facto de
corresponderem a linhas que tm origem e destino na mesma classe.
Classes-Associao
Numa relao de associao entre classes, a associao pode tambm
ter os seus prprios atributos (e eventualmente operaes), devendo
ser, por conseguinte, modelizada tambm como uma classe. Este tipo
de classes designa-se por classe-associao.
Considere-se o exemplo da Figura 6.13, em que a associao entre as
classes Pessoa e Empresa traduz as tarefas que cada empregado
realiza na empresa. Para cada tarefa mantido um conjunto de
atributos. A classe-associao Tarefa representada visualmente
como qualquer outra classe, mas apresenta uma linha a tracejado a
lig-la linha da associao.

Figura 6.13: Exemplo de uma classe-associao.
Associaes N-rias (N 3)
Associaes N-rias, com aridade maior ou igual a 3, so pouco
comuns na modelao de classes. Contudo, h situaes em que a
aplicao deste tipo de associaes vantajosa em termos da clareza
178 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

do modelo. Nestas circunstncias, a associao representada por um
losango com linhas para todas as suas classes participantes.
A multiplicidade em associaes n-rias pode ser especificada, mas
menos bvia que a multiplicidade em associaes binrias. A multiplici-
dade num papel representa o nmero de tuplos (de instncias) numa
associao quando os outro N-1 valores so fixos.
A Figura 6.14 ilustra um exemplo de uma associao n-ria, a
associao Tarefa e correspondente classe-associao, que relaciona
as classes Pessoa, Empresa e TipoTarefa. Caso a associao tenha
tambm atributos e/ou operaes prprias, cria-se uma classe-
associao, a qual ligada ao losango por uma linha a tracejado,
conforme ilustrado na Figura 6.14.

Figura 6.14: Associao ternria e uma classe-associao.
As associaes N-rias podem geralmente ser transformadas em vrias
relaes binrias entre a classe-associao e as restantes classes
participantes. No entanto, se for esta a estratgia adoptada deve ser as-
sinalado esse facto (por exemplo, atravs de um esteretipo ou de uma
anotao) junto classe-associao (ver Figura 6.14).
6.4 Interfaces
Uma interface um contrato na forma de uma coleco de especi-
ficaes de mtodos que providencia um mecanismo para separao
clara entre a vista externa e a vista interna de um determinado elemento
(ver Figura 6.15).
CAPTULO 6 - UML MODELAO DA ESTRUTURA 179



Figura 6.15: Noo de interface.
As interfaces permitem dar a conhecer um determinado elemento,
escondendo os seus detalhes internos, por exemplo, os detalhes de
implementao. Uma interface realizada (ou implementada) por uma
ou mais classes, as quais prometem implementar todos os mtodos
nela especificados. Note-se que em termos de lgebra computacional,
tanto as classes como as interfaces so consideradas ao mesmo nvel
como tipos.
Em termos gerais, o conceito de interface apresenta os seguintes bene-
fcios ao nvel de programao:
Captura de semelhanas entre classes no relacionadas sem forar
a criao de relaes artificiais entre elas.
Declarao de mtodos que uma ou mais classes esperam imple-
mentar.
Revelar a interface de programao de um objecto sem revelar a
sua classe. Ou seja, um objecto pode ser visto de diferentes pers-
pectivas (i.e., diferentes tipos) consoante as situaes.
O conceito de interface um mecanismo usual nas actuais linguagens
de programao baseadas em objectos, tais como Java, Object
Pascal/Delphi, Visual C++, Visual Basic, Corba IDL, COM IDL. um
conceito associado ao desenvolvimento de software baseado em
componentes de software. Por exemplo, o Java no tem herana
mltipla, o que significa que uma classe apenas estende exactamente
uma nica (super-)classe. Contudo, uma classe em Java pode imple-
180 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

mentar zero, uma ou mais interfaces, pelo que um objecto pode
providenciar vrios tipos.
Representao Grfica
Uma interface representada graficamente em UML como uma classe,
mas com esteretipo interface. Pode ser representada alternativa-
mente na forma compacta pelo seu cone correspondente (em geral
representado por um crculo). A Figura 6.16 ilustra duas representaes
alternativas para a interface Enumeration definida nas bibliotecas
standard do Java.

Figura 6.16: Vrias representaes para a interface Enumeration.
Relaes entre Interfaces, Classes e Componentes
Tal como acontece com as classes, uma interface pode participar em
relaes do tipo generalizao, associao, e dependncia. Adicional-
mente pode participar em relaes do tipo realizao.
Uma relao de realizao estabelece-se entre uma interface e uma
classe ou entre uma interface e um componente e pode ser
apresentada em UML por duas formas alternativas: na forma compacta
ou na forma expandida conforme ilustrado na Figura 6.17 relativamente
classe TargetTracker e interface Observer definidas num
pacote Java do JDK da Sun.
CAPTULO 6 - UML MODELAO DA ESTRUTURA 181



Figura 6.17: Utilizao de interfaces em diagramas de classe.
Outro tipo de relao entre classes e interfaces a relao de
dependncia, tambm ilustrada no exemplo da Figura 6.17. A classe
Tracker depende (ou usa alguma funcionalidade) da classe
TargetTracket atravs da interface Observer.
A Figura 6.18 ilustra um extracto de um diagrama de componentes, em
que apresenta o componente wordsmith.dll e todas as suas
interfaces exportadas: (1) IUnknown, que uma interface comum a
todos os componentes Active-X; (2) ISpell, interface com
funcionalidades para correco ortogrfica de documentos de texto; e
(3) IThesarus, interface com funcionalidades de thesaurus lingustico
(sinnimos, antnimos, etc.). Este exemplo ilustra a importncia da
noo e utilizao de interfaces: em funo do acesso ao componente
(ou classe), assim so providenciadas diferentes funcionalidades.

Figura 6.18: Utilizao de interfaces em diagramas de componentes.
182 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Outro aspecto fundamental no desenvolvimento de software baseado
em componentes, principalmente em contextos distribudos e empresa-
riais, tem a ver com a gesto de verses de componentes. Por exemplo,
a evoluo/alterao de um componente pode (e deve) ser realizada de
forma transparente, da perspectiva dos restantes componentes/classes
(seus clientes), o que possvel caso suporte todas as interfaces defini-
das em verses anteriores.
6.5 Instncias e Objectos
Uma instncia uma manifestao concreta de uma abstraco, qual
um conjunto de operaes pode ser aplicado, e que tem um estado que
regista os efeitos das operaes realizadas.
Em geral, um objecto designado por instncia e vice-versa; mas
rigorosamente so conceitos distintos. Por exemplo:
A instncia de uma associao uma ligao (link).
A instncia de um n um computador que se encontra fisicamente
num local.
A instncia de um caso de utilizao um cenrio.
Um objecto uma instncia de uma classe, herdando, por conseguinte,
todos os atributos e mtodos definidos na prpria classe e possuindo
uma representao de execuo prpria, a qual se pode designar
genericamente por estado, bem como uma identificao nica no
contexto da sua execuo. Um objecto em UML representado, tal
como uma classe, atravs de um rectngulo com uma, duas ou trs
seces consoante o interesse da informao a apresentar. No entanto,
contrariamente s classes, os nomes dos objectos so sublinhados e
sufixados pelo nome das classes respectivas, seguindo a notao:
Nome-do-objecto : Nome-da-classe
A Figura 6.19 ilustra diferentes exemplos de representao de objectos.
H trs objectos com nome (meuCliente, clienteA e ClienteB) e
dois objectos annimos, i.e., sem nome (instncias das classes
Loja::Virtual e AgentNews). A figura ilustra ainda a representao
de instncias mltiplas (AgentNews).
CAPTULO 6 - UML MODELAO DA ESTRUTURA 183



Figura 6.19: Representao grfica de objectos.
Operaes
Os objectos podem efectuar as operaes definidas nas suas classes.
Por exemplo, considerando a classe Factura com a operao
calculaIvaTotal, se existir o objecto fac, ento possvel invocar a
dita operao do seguinte modo: fac. CalculaIvaTotal().
Por ser redundante no se apresentam as operaes de um objecto na
sua representao grfica UML (podem-se contudo apresent-las em
diagramas de interaco ver Captulo 7).
Estado
O estado de um objecto dado pelos valores assumidos pelo conjunto
de atributos de um objecto. O estado de um objecto naturalmente um
facto dinmico, variando ao longo do tempo e do espao na medida em
que o objecto interactua com outros objectos.
184 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE


Figura 6.20: Objectos com estado.
A Figura 6.20 ilustra duas formas alternativas de representar o estado
de um objecto. O objecto ar apresenta o seu estado atravs da
enumerao de valores dos seus respectivos atributos. Note-se que a
identificao do tipo dos atributos pode ser realizada (e.g., id:NIF ou
t:TipoDocente) ou no (e.g., nome).
Nas situaes em que se associa uma mquina de estados a uma
determinada classe (e.g., sistemas conduzidos por eventos, ou
entidades que evoluem por vrios estados ao longo do seu ciclo de
vida) pode-se explicitar em determinado momento o estado corrente de
um objecto. Na Figura 6.20, o objecto termo encontra-se no estado em
discusso, que o nome de um dos estados possveis definidos na
mquina de estados associada classe Termo. Pelo facto de um objec-
to poder encontrar-se em vrios estados simultaneamente, possvel
enumerar uma lista de estados correntes.
Objectos Activos
Processos, fluxos de execuo, agentes de software e aplicaes so
exemplos de objectos particulares designados objectos activos
que apresentam uma viso da dinmica de um sistema. Os objectos
activos tm adicionalmente aos objectos (normais ou passivos) a parti-
cularidade de terem controlo sobre o seu prprio fluxo de execuo.
A especificao do UML sugere que quer as classes quer os objectos
activos sejam distinguidos dos restantes pela apresentao de linhas
com uma maior espessura (ver parte superior da Figura 6.21).
CAPTULO 6 - UML MODELAO DA ESTRUTURA 185



Figura 6.21: Representao grfica de objectos activos e objectos
compostos.
Objectos Compostos
Um objecto composto aquele que constitudo por outros
(sub)objectos. H inmeras situaes de objectos compostos, mas em
geral reflectem relaes de agregao (simples ou compostas) entre as
suas respectivas classes. Os objectos compostos so representados
como objectos normais, com a excepo dos seus atributos serem
substitudos por outros objectos, usando texto sublinhado ou atravs de
uma representao grfica.
A parte inferior da Figura 6.21 ilustra um objecto composto
relativamente a uma hipottica situao de uma empresa que contem
trs departamentos. (Consulte-se a Figura 6.10 para se entender as
relaes de agregao entre os objectos). A vantagem de se represen-
tar um conjunto relacionado (por agregao) de objectos atravs de um
objecto composto essencialmente por motivos de clareza e simplicida-
de dos diagramas produzidos, para alm de se explicitar desta forma o
nvel de coeso entre os objectos.
186 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

6.6 Diagramas de Classes e Diagramas de
Objectos
Um diagrama de classes ilustra um conjunto de classes, interfaces,
colaboraes e respectivas relaes, em geral de dependncia, genera-
lizao e de associao. Nas seces anteriores (Seco 6.3 e Seco
6.4) apresentaram-se vrios exemplos de diagramas de classes.
Os diagramas de classes so usados para modelar a estrutura de um
sistema. Estes modelos so tambm designados por vista do desenho
esttico do sistema e so usados tipicamente em trs situaes: (1)
para modelar o vocabulrio de um sistema; (2) para modelar colabora-
es simples; e (3) para modelar o desenho de um esquema de uma
base de dados.
Um diagrama de objectos ilustra um conjunto de objectos e respec-
tivas relaes num determinado momento. Permite captar uma imagem
ou fotografia momentnea sobre determinado sistema. Um diagrama de
objectos um grafo composto por objectos e ligaes (links) entre eles.
Note-se, como referido acima, que uma ligao uma instncia de uma
relao de associao.
Um diagrama de objectos no pode (nem deve pretender) especificar
completamente a estrutura de objectos de um dado sistema, j que para
cada classe ou conjunto de classes relacionadas, h uma infinidade de
potenciais combinaes entre as suas instncias. Por conseguinte, o
objectivo dos diagramas de objectos apenas expor conjuntos relevan-
tes de objectos de modo a melhorar o entendimento das suas funciona-
lidades e inter-relaes.
6.7 Exemplos e Recomendaes
De modo a clarificar o que so diagramas de objectos e as suas rela-
es com diagramas de classes, considere-se os seguintes exemplos
relativos a exerccios acadmicos razoavelmente simplificados: (6.1)
sistema de gesto de automveis; (6.2) sistema de gesto de compras;
e (6.3) sistema acadmico.
CAPTULO 6 - UML MODELAO DA ESTRUTURA 187


Exemplo 6.1: Diagrama de Classes/Objectos do Sistema de Gesto
de Automveis
Considere-se o seguinte enunciado: Uma pessoa pode ser proprietrio
de vrios veculos e estes so possudos apenas por uma nica pessoa.
Por outro lado, um veculo tem de possuir necessariamente um motor.
Um veculo identificado univocamente pela matrcula e possui ainda
outras informaes, tais como a cor, data de fabrico, marca e modelo.
Um motor identificado por um nmero de motor, tipo de combustvel e
cilindrada.
A Figura 6.22 ilustra o diagrama de classes correspondente ao
enunciado introduzido. Note-se que poderiam ser produzidas algumas
variantes a esta soluo. Por exemplo, poder-se-ia ter considerado a
marca, modelo e tipo de combustvel como classes no sistema.
Note-se que a relao entre motor e veculo de agregao (pois um
motor visto como um componente de um veculo), mas no deve ser
composio, ou agregao composta, pois podem existir motores sem
estarem directamente colocados nos veculos (esto algures em stock
espera, por exemplo, de serem adquiridos e substiturem um motor
gripado!).

Figura 6.22: Diagrama de classes do Exemplo 6.1.
Com base no enunciado e no diagrama de classes acima a Figura 6.23
apresenta o diagrama de objectos que traduz a seguinte situao: o Z
Maria dono de um Audi A3 TDi vermelho, com matricula 99-99-MM,
que tem um motor 1900cc, com nmero 9999. Note-se que no
diagrama de objectos apenas so representados objectos e ligaes, e
nestas ltimas no se apresentam quaisquer adornos do tipo
multiplicidade, agregao ou visibilidade. Pode-se quanto muito atribuir
um nome ligao para facilitar a sua legibilidade.
188 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE


Figura 6.23: Diagrama de objectos do Exemplo 6.1.
Fica como exerccio e reflexo a construo do diagrama de objectos
que traduza a seguinte situao: o Z Maria e a Rita so donos de um
Audi A3 Tdi vermelho, com matricula 99-99-MM, que tem um motor
1900cc, com nmero 9999. Que alteraes ao diagrama de classes
teriam de ser realizadas de modo a validar esta nova situao?



Exemplo 6.2: Diagrama de Classes/Objectos do Sistema de Gesto
de Compras.
Considere-se o seguinte enunciado: A empresa XPTO compra
produtos a diferentes fornecedores. Os produtos adquiridos so
identificados univocamente por um cdigo, tm uma descrio, e ainda
a identificao de um tipo de produto (e.g., alimentar, vesturio, linha
branca). Cada encomenda especifica um conjunto de produtos com
respectivas quantidades, o fornecedor, a data de aquisio, e a data de
entrega prevista.
A Figura 6.24 ilustra o diagrama de classes de alto nvel correspondente
ao enunciado introduzido.
CAPTULO 6 - UML MODELAO DA ESTRUTURA 189



Figura 6.24: Diagrama de classes do Exemplo 6.2.
Facto Real: A Figura 6.25 ( uma variante da Figura 6.24) ilustra dois
erros usuais na construo deste tipo de diagrama de classes de alto
nvel:
Introduo de classes especficas de estruturas de dados do tipo
contentores (e.g., listas, hashtables, conjuntos) ao nvel da anlise
do modelo de dados.
Especificar atributos de chaves estrangeiras entre classes. Esses
atributos existem, mas de forma implcita nas associaes envol-
vidas.
190 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE


Figura 6.25: Diagrama de classes do Exemplo 6.2, com erros usuais.
Com base no enunciado e no diagrama de classes da Figura 6.24
apresenta-se na Figura 6.26 o diagrama de objectos que traduz a
seguinte situao A Nestl satisfez a encomenda 333, em 99/10/14,
relativa data de encomenda de 99/8/31. A encomenda 333 tem 2
itens: (i) produto 123, chocolate BLO, Euro 30; 10000 unidades; e (ii)
produto 135, leite condensado 1/4, Euro 20, 50000 unidades. Ambos os
produtos so do tipo alimentar.

Figura 6.26: Diagrama de objectos do Exemplo 6.2.
Note-se uma vez mais que um diagrama de objectos no mais que
uma possvel configurao ou malha de objectos; portanto, apenas
um de uma infinidade de possveis disposies.
CAPTULO 6 - UML MODELAO DA ESTRUTURA 191



Exemplo 6.3: Diagrama de Classes/Objectos do Sistema
Acadmico.
Considere o seguinte diagrama de classes, ilustrado na Figura 6.27,
correspondente aos seguintes factos: (1) um docente dar aulas a vrios
alunos numa ou mais salas e (2) um docente, enquanto professor, ser
responsvel por outros docentes, designados por assistentes.

Figura 6.27: Diagrama de classes do Exemplo 6.3.
A Figura 6.28 ilustra dois diagramas de objectos desenvolvidos sobre o
diagrama de classes anterior, e relativamente aos dois cenrios seguin-
tes:
1. O docente Alberto d aulas na sala P01 a vrios alunos. Note-se
em particular a forma como se representa vrios alunos atravs da
especificao de instncias mltiplas e annimas da classe
Estudante. Outro aspecto relevante a forma como se representa
uma configurao de objectos cujas classes respectivas se encon-
tram numa relao N-ria.
2. O docente Alberto responsvel pelo docente (enquanto assisten-
te) Pedro.

Figura 6.28: Diagrama de objectos do Exemplo 6.3.
192 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

6.8 Exerccios
Ex.38. Usar classes para definir o glossrio do sistema Jogo de
Futebol descrito de seguida: O jogo de futebol realizado por
duas equipas de jogadores. Cada equipa composta por 11
jogadores, com diferentes funes: o guarda-redes, defesas,
mdios, atacantes, e pontas de lana. O ponta de lana um
atacante especial por ter especiais caractersticas de goleador...
O jogo realizado num campo com medidas regulamentares
(em comprimento e largura), tem duas balizas, cada qual em
extremos opostos do campo. Ganha o jogo a equipa que marcar
mais golos (i.e., colocar a bola) na baliza do adversrio. No jogo
apenas existe uma nica bola, que apresenta caractersticas
(peso, dimetro, ) regulamentares... O jogo de futebol me-
diado por uma equipa de 3 rbitros, em que um o rbitro
principal, e os outros dois so rbitros auxiliares.
Ex.39. Tendo em conta o sistema Jogo de Futebol descrito no exerc-
cio anterior e as classes identificadas estabelea agora as suas
relaes de forma a descrever o modelo de classes correspon-
dente.
Ex.40. Considere o diagrama de classes relativo ao sistema de Jogo
de Futebol produzido no exerccio anterior. Defina 4 pacotes
respectivamente para agrupar classes relativas a (1) equipas de
jogadores; (2) equipas de arbitragem; (3) clubes de futebol; e (4)
os jogos propriamente ditos. Defina o diagrama de pacotes
respectivo, evidenciando as classes exportadas e as dependn-
cias de importao correspondentes.
Ex.41. Tendo em conta o Exemplo 6.1, defina o diagrama de classes e
o diagrama de objectos que suportem as seguintes afirmaes:
(1) o empresa XPTO possui um Audi A6 TDi vermelho, com
matricula 99-99-AA, que tem um motor 1900cc, com nmero
9999.
(2) a Marta dona de um Ferrari F40 vermelho, com matricula
66-66-FF, mas sem motor.
CAPTULO 6 - UML MODELAO DA ESTRUTURA 193


(3) o Rui no tm qualquer carro.
Ex.42. Modelize atravs de um diagrama de classes o seguinte discur-
so: Uma mesa de caf constituda por um tampo e por quatro
pernas.
Ex.43. Considere o seguinte discurso relativamente a um sistema de
partidas de tnis: Num torneio de tnis, cada partida jogada
entre 2 jogadores. Pretende-se manter informao sobre o nome
e idade dos jogadores; data da partida e atribuio dos jogado-
res s partidas. O mximo de partidas que um jogador poder
realizar 6 e o mnimo 1. Pretende-se:
(1) O diagrama de classes correspondente.
(2) O diagrama de objectos que ilustre a seguinte situao: Os
jogadores Z Maria e Pedro Cunha disputaram uma partida
s 20:30 de 2001/10/10.
Ex.44. Observe atentamente o seguinte diagrama de classes e indique
textualmente o seu significado.


194 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Ex.45. Modelize atravs de um diagrama de classes UML os conceitos
relativos a um sistema bsico de Gesto de Facturas: Um
sistema de facturao mantm informao sobre clientes, sobre
tipos de produtos e de servios vendidos/prestados. Um cliente
identificado univocamente pelo NIF, e tem ainda nome, morada,
telefones, e tipo de cliente. Um cliente pode ter mais que uma
morada Uma factura identificada univocamente pelo
IDFactura, que um nmero sequencial. Tem ainda a informa-
o sobre data de facturao, cliente, valor total. Uma factura
tem vrias linhas, cada qual especificando a venda de um bem
ou servio Uma factura pode ser paga por uma ou mais pres-
taes. Cada pagamento parcial/total corresponde emisso de
respectivo recibo....
Ex.46. Considerando o modelo de classes resultante do exerccio
anterior (Gesto de Facturas) descreva atravs de diagramas
de objectos as seguintes situaes:
(1) O cliente IPP S.A., com NIF 123456789, com duas
moradas. A primeira na Praa da Alegria, 33, 1300-222
Lisboa e a segunda na Rua da Paz, 44, 4Esq, 2000-320
Santarm.
(2) A factura, n. 3445/2000, data de facturao em
28/11/2000, cliente IPP S.A., e valor total de 350,000$00,
constituda por duas linhas. A primeira linha de factura
consiste na venda de 200 caixas de parafusos de 20; a
segunda linha consiste na venda de 10 perfuradoras de
350W
Ex.47. Considere a seguinte extracto de cdigo Java relativo utilizao
de classes definidas no pacote java.sql.*, em particular das
classes DriverManager, Connection e Statement.
Considere ainda que o cdigo ilustrado est implementado na
classe Cliente. Desenhe o diagrama de classes de suporte e o
diagrama de objectos correspondente.

CAPTULO 6 - UML MODELAO DA ESTRUTURA 195


Connection con;
Statement stmt;
...
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
con =
DriverManager.getConnection("jdbc:odbc:BD1");
stmt = con.createStatement();
...
stmt.executeUpdate(INSERT );
...
stmt.executeUpdate(UPDATE );
196 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE





Captulo 7 - UML MODELAO DO
COMPORTAMENTO
Tpicos
Introduo
Interaces
Diagramas de Interaco
Diagramas de Estados
Diagramas de Actividades
Exerccios

7.1 Introduo
Em qualquer sistema minimamente interessante, os objectos no esto
estticos, mas interagem entre si por troca de mensagens [Booch99].
A modelao do comportamento de um sistema de software consiste,
segundo a abordagem orientada por objectos, em dois tipos distintos de
especificaes. Por um lado, na modelao do comportamento inter-
objectos, ou seja na identificao dos seus padres de trocas de
mensagens (diagramas de interaco). Por outro lado, na modelao
do comportamento intra-objecto, ou seja na identificao dos estados
em que um objecto se pode encontrar ao longo do seu ciclo de vida, dos
eventos envolvidos, bem como dos seus algoritmos de implementao
(diagramas de estados e de actividades).
198 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

A modelao de um sistema de software com base em diagramas de
classes e de objectos traduz apenas as suas relaes estruturais e es-
tticas. Nada revelado sobre o padro interno e externo do comporta-
mento dos objectos ou relativamente definio de determinado
algoritmo. O UML providencia os seguintes elementos que permitem a
especificao do comportamento de um sistema de software: objectos,
interaces, mensagens, estados, actividades, sinais e eventos. Com
base nestes elementos podem-se definir os seguintes tipos de diagra-
mas: diagramas de interaces, diagramas de estados e diagramas de
actividades.


7.2 Interaces
Uma interaco a especificao do comportamento de um conjunto
de instncias, representado pela sua troca de mensagens, num determi-
nado contexto, e com vista concretizao de um dado objectivo.
Embora uma interaco permita descrever o comportamento de
instncias genericamente (e.g., objectos, cenrios de casos de utiliza-
o, instncias de actores), passaremos a utilizar de ora em diante a
designao objecto de forma a simplificar a explanao.
As interaces so utilizadas para modelar o fluxo de controlo de uma
operao, classe, componente, caso de utilizao ou um sistema na sua
globalidade. Sempre que existe uma ligao (link) entre instncias, pode
ocorrer uma ou mais interaces.
Uma mensagem define uma comunicao particular entre instncias,
que especificada numa determinada interaco. Uma comunicao
pode ser, por exemplo: invocar uma operao; lanar um sinal; construir
ou destruir uma instncia. Uma mensagem especifica no apenas o tipo
de comunicao, mas tambm os papis do emissor e receptor, a aco
lanada, bem como o papel desempenhado pela ligao.
CAPTULO 7 - UML MODELAO DO COMPORTAMENTO 199


7.2.1 Objectos e Ligaes
Pode-se encarar um diagrama de objectos como a representao dos
aspectos estticos de uma interaco. Contudo, uma interaco vai
mais longe, ao introduzir uma sequncia dinmica de mensagens que
podem fluir entre esses objectos. Desta forma, os diagramas de
interaco devem ser considerados como uma extenso aos diagramas
de objectos.

Figura 7.1: Relaes entre diagramas de classes, de objectos e de
interaces.
A Figura 7.1 ilustra a relao entre os conceitos mensagem, ligao e
associao, tal como as relaes entre diagramas de classes, de objec-
tos e de interaco.
Uma ligao (link) entre objectos traduz a existncia de uma relao
semntica ou estrutural entre as suas respectivas classes. Sempre que
existe uma associao entre duas classes deve tambm existir uma
ligao entre instncias das classes respectivas. Uma ligao entre
objectos representada em UML atravs de uma linha a cheio, no
dirigida.
200 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

(Nota: Na ferramenta Rational Rose no existe possibilidade de
representar explicitamente diagramas de objectos. Tal situao per-
feitamente admissvel caso se atente na afirmao realizada anterior-
mente: os diagramas de objectos so um caso simplificado dos diagra-
mas de interaces.)
Facto Real: Num projecto de um curso de ps-graduao pedi aos
alunos para especificarem um sistema segundo diferentes perspectivas.
Entre outros, pedi para que fizessem um diagrama de objectos.
Resposta de alguns alunos: No fizemos pois a ferramenta (Rational
Rose) no permite realizar tal tipo de diagrama. Ou seja, os alunos
deviam ter produzido o diagrama de objectos pedido, usando o diagra-
ma de interaco (em particular um diagrama de colaborao), explici-
tando apenas objectos e suas ligaes.
7.2.2 Mensagens e Estmulos
Um estmulo uma comunicao entre dois objectos que veicula
informao com a expectativa que determinada actividade seja realiza-
da. Um estmulo provocar a invocao de uma operao, o envio de
um sinal, ou a criao ou destruio de um objecto.

Figura 7.2: Diagrama de interaces.
Uma mensagem a especificao de um estmulo, ou seja, especfica
os papis que os objectos emissor e receptor devem acordar para que
uma aco seja realizada. Regra geral, a recepo de uma mensagem
resulta na realizao de uma aco (que por sua vez pode provocar
uma mudana de estado) no objecto destino.
CAPTULO 7 - UML MODELAO DO COMPORTAMENTO 201


7.2.3 Representao de Mensagens
Em geral um estmulo representado por uma linha slida dirigida (i.e.,
uma seta) do objecto origem para o objecto destino. Pode-se, contudo,
usar variantes a esta representao principal para ilustrar diferentes ti-
pos de comunicaes (ver Figura 7.3):
Simples
Fluxo de controlo simples. Cada seta mostra o prximo passo numa
determinada sequncia. Quando no relevante identificar o tipo de
comunicao deve-se usar este tipo de seta.
Sncrona
Invocao de mtodo ou outro fluxo de controlo, dentro do fluxo
corrente. Pode ser usado em situaes normais de invocao de
mtodos. Pode tambm ser usado entre objectos activos concor-
rentes, quando um invoca um sinal e espera que o comportamento
destino termine.
Assncrona
Usado alternativamente seta do tipo simples para ilustrar explicita-
mente uma comunicao assncrona entre dois objectos numa se-
quncia procedimental.
Retorno
Retorno de uma invocao de mtodo.

Figura 7.3: Diferentes representaes de mensagens.
202 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Num fluxo de controlo procedimental, a seta de retorno pode (e deve)
ser omitida, j que corresponde implicitamente ao fim da respectiva
activao. O valor de retorno, caso exista pode ser ilustrado na seta
inicial. Por outro lado, num fluxo de controlo no-procedimental (e.g.,
em mensagens assncronas e processamento paralelo), o retorno deve
ser ilustrado explicitamente.
Num sistema concorrente, a seta simples representa passar o fluxo de
controlo para a outra actividade (semntica bloqueante) enquanto a seta
assncrona representa o envio de uma mensagem sem passar o seu
fluxo de controlo (semntica no bloqueante).
7.2.4 Tipos de Mensagens
Em UML esto predefinidos diferentes tipos de mensagens:
Call: Invoca uma operao de um objecto. o tipo de mensagem
mais comum (comunicao sncrona).
Return: Devolve um resultado/sinal para o objecto chamador.
Send: Envia um sinal para um objecto (comunicao assncrona).
Create: Cria um objecto.
Destroy: Destroi um objecto. Note-se que um objecto pode destruir-
se a si prprio.
A Figura 7.4 ilustra um exemplo de aplicao destes diferentes tipos de
mensagens. Note-se que apenas se representam explicitamente os
esteretipos das mensagens do tipo criao e destruio de objectos.
Todas os outros tipos (call, send e return) so implcitos a partir da sua
representao grfica. Note-se ainda na representao grfica particular
para a destruio de um objecto (X).
7.3 Diagramas de Interaco
Quando um objecto envia uma mensagem a outro objecto, este por sua
vez pode enviar uma outra mensagem a outro objecto, e assim suces-
sivamente. Criam-se deste modo sequncias de mensagens execu-
tadas, em geral, sobre o mesmo processo ou actividade de execuo.
CAPTULO 7 - UML MODELAO DO COMPORTAMENTO 203


Uma interaco representada por um diagrama de interaco. Os
diagramas de interaco so usados para especificar a realizao de
um caso de utilizao bem como a realizao de uma operao envol-
vendo diferentes objectos. Os diagramas de interaco podem ser apre-
sentados nas seguintes formas:
Diagrama de sequncia: um diagrama de interaco com nfase
na ordenao temporal das mensagens trocadas entre os objectos
(ver Figura 7.4).
Diagrama de colaborao: um diagrama de interaco com nfase
na organizao estrutural dos objectos que trocam mensagens entre
si (ver Figura 7.5).
Os diagramas de sequncia so particularmente teis para detalhar um
cenrio de um caso de utilizao, e so mais adequados para especi-
ficar situaes complexas, bem como mltiplos e concorrentes fluxos de
controlo. Por outro lado, os diagramas de colaborao ao colocarem a
nfase nas relaes estruturais entre as instncias de uma interaco,
so mais adequados no desenho de sistemas no concorrentes (i.e.,
desenho de interaces sequenciais ou procedimentais) e em particular
para ilustrar relaes entre objectos em padres de desenho
[Gamma94].
Uma coleco de restries standard pode ser usada para ilustrar o
momento de criao ou destruio de objectos ou ligaes durante uma
determinada execuo:
Objectos e ligaes criados durante uma execuo podem ser
designados por {new}.
Objectos e ligaes destrudos durante uma execuo podem ser
designados por {destroy}.
Objectos e ligaes criados durante uma execuo e seguidamente
destrudos podem ser designados por {transient}.
Podem-se introduzir nos diagramas de interaco vrias descries
(e.g., restries temporais, descries de aces durante determinada
activao), as quais devem ser colocadas na margem (esquerda ou
direita) ou junto s activaes ou transies que representam.
204 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

7.3.1 Diagramas de Sequncia
Um diagrama de sequncia ilustra uma interaco segundo uma viso
temporal. Um diagrama de sequncia representado atravs de duas
dimenses: a dimenso horizontal, que representa o conjunto de
objectos intervenientes; e a dimenso vertical que representa o tempo.
A apresentao destas dimenses pode ser invertida, se for conve-
niente. No existe qualquer significado na ordenao horizontal dos ob-
jectos intervenientes, ou seja, na sua disposio relativa.
Nos diagramas de sequncia as setas so desenhadas horizontalmente
de forma a representar a indivisibilidade da operao necessria para
enviar o estmulo. Esta assuno vlida para a generalidade das
situaes. Todavia, em situaes em que o tempo de envio do estmulo
no neglicencivel (e.g., pode ocorrer um outro estmulo em sentido
oposto), a seta deve ser representada de modo relativamente inclinada
para baixo (i.e., no sentido do tempo).
A Figura 7.4 ilustra um diagrama de sequncia em que so
representados diferentes tipos de mensagens. Note-se em particular a
criao e destruio do objecto :Assistente; a explicitao de focos
de controlo (ou zonas de activao), e o envio de mensagem assncro-
na notifica do objecto :Cliente para o objecto :AgnciaViagem.

Figura 7.4: Exemplo de um diagrama de sequncia.
CAPTULO 7 - UML MODELAO DO COMPORTAMENTO 205


7.3.2 Diagramas de Colaborao
Um diagrama de colaborao ilustra uma interaco organizada
espacialmente. De forma distinta dos diagramas de sequncia, um
diagrama de colaborao mostra as relaes entre objectos que
desempenham diferentes papis. Por outro lado, um diagrama de
colaborao no mostra o tempo como uma dimenso separada, pelo
que a sequncia de interaces e de actividades concorrentes repre-
sentada usando-se nmeros sequenciais.
A ordem de uma interaco descrita atravs de uma sequncia de
nmeros, normalmente com incio em 1. Num fluxo de controlo procedi-
mental, os nmeros de comunicao de uma subsequncia so repre-
sentados de acordo com o respectivo nvel de incluso. Para uma
sequncia de interaces no procedimental, i.e., entre objectos concor-
rentes, todos os nmeros de uma sequncia encontram-se ao mesmo
nvel.
A Figura 7.5 ilustra um exemplo de diagrama de colaborao na forma
de diagrama de instncias.

Figura 7.5: Exemplo de um diagrama de colaborao.
Um diagrama de colaborao pode ser representado por duas formas:
ao nvel de especificao (o diagrama ilustra os papis que as classes
e associaes desempenham, bem como as suas mensagens) ou ao
nvel de instncia (o diagrama ilustra objectos, ligaes e estmulos). A
primeira forma apresenta os papis e estrutura definida na colaborao
206 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

subjacente, enquanto que a segunda ilustra uma instncia que deve ser
conforme com os papis de uma colaborao.

Exemplo 7.1: Diagramas de Colaborao Pessoa com distintos
Papis.
Considere-se o seguinte enunciado: Num contexto acadmico, uma
pessoa pode desempenhar dois papis distintos. Por um lado, uma
pessoa, como professor, pode ser o regente ou coordenador de (zero
ou mais) disciplinas e pode ser responsvel pela superviso de (zero ou
mais) estudantes. Por outro lado, uma pessoa como estudante tem
necessariamente um tutor (o professor que o supervisiona), e inscreve-
se em (zero ou mais) disciplinas. Mostra-se neste exemplo as relaes
entre diagramas de classes, de colaborao de nvel especfico, e de
colaborao de nvel de instncias.
A Figura 7.6 ilustra o diagrama de classes correspondente ao enunciado
introduzido. Note-se a associao reflexiva supervisionar que
relaciona pessoa, no papel de professor, com pessoa, no papel de
estudante. Note-se tambm nas duas associaes (inscrever e
coordenar) entre as classes Pessoa e Cadeira.
CAPTULO 7 - UML MODELAO DO COMPORTAMENTO 207



Figura 7.6: Diagrama de classes do Exemplo 7.1.
A Figura 7.7 ilustra o diagrama de colaborao de nvel de
especificao. Note-se que so representados os papis que as classes
e associaes desempenham genericamente numa colaborao. Note-
se que cada rectngulo apresenta o nome de uma classe precedida
pelo caracter : e eventualmente pelo nome do papel que a classe
desempenha nessa colaborao precedida pelo caracter /. (Para mais
detalhes consulte-se [OMG99].)

Figura 7.7: Diagrama de colaborao de nvel de especificao do
Exemplo 7.1.
208 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Por fim, a Figura 7.8 ilustra um diagrama de colaborao, de nvel de
instncias, conforme com o anterior diagrama, correspondente
operao de obteno de todos os professores de um dado aluno (i.e.,
professores regentes em cadeiras inscritas pelo respectivo aluno) reali-
zada sobre instncias de professor enquanto tutor.

Figura 7.8: Diagrama de colaborao de nvel de instncias do Exemplo
7.1.
Note-se na representao da sequncia de execuo de operaes:
fluxo de controlo sequencial com uma iterao (envio da mensagem
regente para todas as instncias de Cadeira, correspondentes s
cadeiras em que os alunos se encontram inscritos).

7.3.3 Equivalncia Semntica
A equivalncia semntica entre os diagramas de sequncia e de
colaborao significa que estes representam (ou podem representar) a
mesma interaco. O Exemplo 7.2 ilustra a equivalncia semntica
entre estes tipos de diagramas. A ferramenta Rational Rose, por exem-
plo, gera automaticamente um diagrama a partir do outro e vice-versa.

CAPTULO 7 - UML MODELAO DO COMPORTAMENTO 209


Exemplo 7.2: Equivalncia entre Diagramas de Interaco Acesso
a BD em Java.
Considere o seguinte extracto de cdigo Java relativo utilizao de
classes definidas no pacote java.sql.*, em particular das classes
Connection e Statement. Pretende-se os respectivos diagramas de
sequncia e de colaborao.
Connection con; Statement stmt;
...
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
con =
DriverManager.getConnection("jdbc:odbc:BD1");
stmt = con.createStatement();
...
stmt.executeUpdate(INSERT );
stmt.executeUpdate(UPDATE );
Para resolver este exemplo, necessrio antes de mais definir o
diagrama de classes respectivo (ver Figura 7.9).
Existem trs classes principais: a classe DriverManager que
responsvel por gerir os detalhes de acesso a determinado sistema de
base de dados atravs de um determinado controlador e adicionalmente
permite criar conexes (atravs do mtodo esttico getConnection);
a classe Connection, responsvel por estabelecer uma ligao a
determinada base de dados; e a classe Statement que encapsula os
detalhes de uma instruo SQL. Sobre um DriverManager podem ser
criadas instncias de Connection, e sobre esta diferentes instncias
de Statement.

Figura 7.9: Diagrama de classes do Exemplo 7.2.
Com base no diagrama de classes, que ilustra as relaes estruturais
entre as diferentes classes pode-se definir os diagramas de interaco
correspondentes ao cdigo ilustrado.
210 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Note-se que neste exemplo temos explicitamente os objectos con e
stmt, (respectivamente instncias de Connection e de Statement);
e que no existe uma instncia explcita de DriverManager: j que a
prpria classe que providencia um mtodo-fbrica de ligaes.

Figura 7.10: Diagrama de sequncia do Exemplo 7.2.
Atente-se na equivalncia semntica entre ambos os diagramas (ver
Figuras 7.10 e 7.11). introduzido genericamente uma instncia da
classe Cliente de modo a ilustrar devidamente o padro de
interaco.

Figura 7.11: Diagrama de colaborao do Exemplo 7.2.
CAPTULO 7 - UML MODELAO DO COMPORTAMENTO 211


7.3.4 Diagramas de Interaco e de Casos de Utilizao
Viu-se no Exemplo 7.2 uma possvel utilizao dos diagramas de
interaco: para modelar (ao nvel de desenho) uma determinada
interaco, ou conjunto de interaces, entre vrias instncias.
Outra das aplicaes tpicas destes diagramas a especificao (ao
nvel de anlise) de um caso de utilizao. Ou seja, complementar-
mente especificao do caso de utilizao em linguagem natural (em
texto, mais ou menos estruturado), o mesmo poder, em determinadas
situaes, ser clarificado atravs de um ou mais diagramas de interac-
o.

Exemplo 7.3: Diagramas de Interaco para descrever Casos de
Utilizao.
Considere o exemplo do sistema da Mquina de Bebidas descrito na
Seco 5.4. Considere para simplificar o caso de utilizao Comprar
Bebida. Pretende-se neste exemplo especificar o cenrio ideal (em que
tudo corre bem, i.e., em que h bebida, h troco, etc.) deste caso
atravs de diagramas de interaco.

Figura 7.12: Diagrama de sequncia do Exemplo 7.3.
212 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Neste tipo de problema, necessrio identificarem-se os objectos que
devero de alguma forma interagir. Considere para o efeito que a m-
quina composta, entre outros, por trs objectos principais:
Interface: o painel de interface com o utilizador
Registadora: a caixa registadora, que guarda o dinheiro
Dispensa: a caixa/armrio que guarda as diferentes bebidas
Considere ainda que o cenrio a representar composto pela seguinte
sequncia de aces:
O cliente insere o dinheiro na ranhura no painel de interface da m-
quina
O cliente selecciona o tipo de bebida
O dinheiro vai at a caixa registradora, esta actualiza a sua reserva
de dinheiro
A interface pede a bebida dispensa
A dispensa envia a bebida seleccionada para o painel de interface.
A interface devolve a bebida ao cliente
Na sequncia destes dois passos fundamentais (identificao dos
objectos envolvidos e identificao da sequncia de aces) desenham-
se com facilidade os respectivos diagramas de colaborao (ver Figuras
7.12 e 7.13). Repare-se que estes diagramas ajudam a clarificar
interaces que normalmente no so to evidentes especificadas de
forma textual.
CAPTULO 7 - UML MODELAO DO COMPORTAMENTO 213



Figura 7.13: Diagrama de colaborao do Exemplo 7.3.

7.4 Diagramas de Estados
Um diagrama de estados (statechart), tambm conhecido por diagra-
ma de transio de estado ou por mquina de estados, permite modelar
o comportamento interno de um determinado objecto, subsistema ou
sistema global.
Estes diagramas representam os possveis estados de um objecto, as
correspondentes transies entre estados, os eventos que fazem
desencadear as transies, e as operaes (aces e actividades) que
so executadas dentro de um estado ou durante uma transio. Os
objectos evoluem ao longo do tempo atravs de um conjunto de estados
como resposta a eventos e passagem de tempo.
214 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE


Figura 7.14: Exemplo genrico de diagrama de estados.
A Figura 7.14 ilustra um diagrama de estados genrico, com um estado
inicial, o estado X e um estado final. Os estados so representados por
rectngulos com os cantos arredondados, excepto o estado inicial e
final que tm cones particulares. As transies so representadas
graficamente por uma linha a cheio dirigida. A figura ilustra a viso
detalhada de um estado, que para alm do nome, pode ainda incluir um
segundo compartimento com as aces e actividades realizadas.
Podem-se pensar em inmeras situaes, mais prticas ou mais
conceptuais, de exemplos de sistemas ou de objectos que evoluem ao
longo de distintos estados. Por exemplo:
(1) Uma lmpada: que evolui entre os estados acesa e apagada,
conforme se liga e desliga um interruptor (ver Figura 7.15).
(2) Uma mquina de lavar roupa: depois da passagem de um determi-
nado perodo de tempo, a mquina de lavar termina o seu programa
de lavagem, e inicia o de secagem.
(3) Uma instncia da classe javax.servlet.http.Servlet: evolui
ao longo de diferentes estados, tais como: em carregamento, inicia-
lizada, preparada para tratar pedido, destruda.
CAPTULO 7 - UML MODELAO DO COMPORTAMENTO 215



Figura 7.15: Diagrama de estados de uma lmpada.
7.4.1 Estados
Um estado uma situao registada por um objecto durante o seu
respectivo ciclo de vida, durante a qual uma condio verificada, vai
executando alguma actividade, ou simplesmente espera que deter-
minado evento ocorra.
Um estado tem diferentes partes, designadamente:
Nome: Uma string que distingue o estado de outros estados; um
estado sem nome designa-se por estado annimo.
Aces de entrada e de sada: Aces executadas, respectiva-
mente, no incio ( entrada) ou no fim ( sada) do estado.
Transies internas: transies que ocorrem mas que no alteram a
mudana de estado.
Sub-estados: uma estrutura aninhada de um estado, envolvendo
sub-estados disjuntos (i.e., sequencialmente activos) ou concor-
rentes (i.e., concorrentemente activos).
Eventos deferidos: uma lista de eventos que no so tratados no
estado corrente, mas tratados pelo objecto num seu outro estado.
7.4.2 Transies
Uma transio uma relao entre dois estados que especifica que um
objecto que se encontre no primeiro estado, realizar um conjunto de
aces e mudar para o segundo estado quando um determinado
216 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

evento ocorrer e determinadas condies se verificarem. Por exemplo,
uma lmpada pode transitar do estado acesa para o estado apagada
quando o evento desligar ocorrer (ver Figura 7.15).
Uma transio descrita integralmente pela seguinte sintaxe:
evento [condio com guarda] / aco
Contudo, podem existir transies com ou sem eventos, com ou sem
condies com guarda, e com ou sem aces.
Uma transio tem diferentes partes, designadamente:
O estado de origem e de destino, que a transio interliga.
Evento de gatilho (event trigger): o evento cuja recepo pelo
objecto no estado origem proporciona a realizao da transio,
caso a condio de guarda seja satisfeita.
Condio de guarda: expresso lgica que avaliada quando a
transio lanada pela recepo do evento de gatilho. Se a
expresso for avaliada verdadeira a transio ocorre, caso contrrio
a transio no ocorre e o evento perdido.
Aco (ver mais frente nesta seco).
possvel existirem situaes de transies sem gatilho (triggerless),
i.e. transies sem eventos de gatilho: so transies que ocorrem
apenas porque o estado origem termina a sua actividade normalmente.
Uma transio pode ter mltiplos estados-origem (representando a
juno de mltiplos estados concorrentes) bem como mltiplos estados-
destino (representando a diviso para mltiplos estados concorrentes),
no sendo no entanto comum este tipo de utilizao.
CAPTULO 7 - UML MODELAO DO COMPORTAMENTO 217



Figura 7.16: Diagrama de estados da classe Termo.
A Figura 7.16 ilustra vrios tipos de transies representados no
diagrama de estados das instncias da classe Termo. Esta classe
usada no contexto de um sistema de gesto de glossrio de termos
tcnicos informticos (GTTI). O objectivo do sistema GTTI permitir
num contexto restrito de participantes, a construo de um glossrio de
forma colaborativa. Cada membro deste sistema pode propor termos
(basicamente um termo em ingls e a sua respectiva traduo para
portugus), os quais ficam pendentes durante um determinado perodo
de discusso. Nesse perodo surgem comentrios positivos e negativos
de outros membros, no fim do qual segue-se um perodo de validao
que tem como consequncia aceitar ou recusar o termo proposto.
7.4.3 Eventos
Um evento uma ocorrncia de um estmulo que pode corresponder a
uma transio de estado. Existem quatro tipos de eventos:
Sinais
Invocao
Passagem de tempo
218 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Mudana de estado
Um sinal representa um objecto com nome que enviado (lanado)
assincronamente por um objecto e recebido (apanhado) por outro. O
mecanismo de excepes suportado pela generalidade das modernas
linguagens de programao (e.g., Java, C++, ObjectPascal) so os
exemplos mais usuais de sinais.
Um evento de invocao corresponde ao lanamento de uma
operao, tipicamente de modo sncrono.
Quer os eventos de invocao quer os sinais so representados
graficamente da mesma forma (e.g., evento de invocao Comentrio
favorvel da Figura 7.16). No entanto, a diferena deve ser clara a
partir da informao implcita do modelo: em geral, um sinal tratado
pela prpria mquina de estados, enquanto que evento de invocao
por um mtodo. Os sinais so trocados assincronamente entre objectos,
o que implica que estes mantm fluxos de actividades autnomos e
concorrentes; por outro lado, os eventos de invocao ocorrem entre
um ou mais objectos, com comunicao sncrona, o que implica que os
objectos intervenientes so passivos no sentido que a sua execuo
ocorre sobre o mesmo fluxo de actividade.
O evento de passagem de tempo representa simplesmente o evento
(natural e conhecido!) da passagem de tempo. Normalmente no se
especifica explicitamente este tipo de evento. Contudo, caso seja
relevante explicitar e caracterizar tal evento, pode-se usar a palavra-
chave after seguida por uma expresso que avalia o perodo de
tempo (e.g. after (1 dia) da Figura 7.16). Outros exemplos de mo-
delao de eventos de passagem de tempo: after (1 hora); after
(1 segundo aps a sada do estado Aceso).
O evento de mudana de estado representa uma mudana de estado
ou a satisfao de uma determinada condio. Modeliza-se este tipo de
evento usando a palavra-chave when seguida por uma determinada
expresso lgica. Outros exemplos de modelao de eventos de
mudana de estado: when time > 12:29; when (nrPropostas >
3); when(dataRegisto + perodoDiscusso >= dataActual).
CAPTULO 7 - UML MODELAO DO COMPORTAMENTO 219


7.4.4 Aces e Actividades
Uma aco uma computao atmica, ou seja, em que se assume
que a sua execuo se realiza num perodo de tempo instantneo e que
no interrompvel. Aces podem consistir em invocao de mtodos
(tipicamente sobre o prprio objecto da mquina de estados), criao ou
destruio de outro objecto, ou o envio de um sinal para outro objecto.
Num estado podem especificar-se aces de entrada, prefixadas com a
palavra chave entry; aces de sada, prefixadas com a palavra chave
exit; e ainda aces relativas a eventos desencadeados e tratados
dentro do estado (neste caso usa-se a notao evento / aco).
Ao contrrio, uma actividade uma computao no atmica, i.e. que
pode ser interrompvel por outros eventos. Corresponde normalmente a
uma operao complexa, eventualmente descrita por um outro
diagrama de estados incluso. As actividades so elementos bsicos dos
diagramas de actividades (ver Seco 7.5) mas tambm podem ser
referidas na especificao de um estado, sendo nesse caso prefixadas
com a palavra chave do (ver Figura 7.17).

Figura 7.17: Especificao de aces e actividades num estado.
Pode-se ainda especificar uma sequncia de aces realizveis num
determinado estado (e.g., do /
operao1();operao2();operao3()).
220 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

7.4.5 Sub-Estados
Um sub-estado um conceito avanado dos diagramas de estados do
UML. Um sub-estado um estado que se encontra definido dentro de
outro (super)estado. A ideia subjacente ao conceito de sub-estado a
abstraco: uma mquina de estados pode ser descrita com diferentes
nveis de abstraco e de detalhe conforme seja necessrio ou relevan-
te em cada momento.
Um estado que tenha um conjunto de sub-estados mais detalhados
designa-se por estado composto. Um estado composto pode conter
quer sub-estados concorrentes (ortogonais) quer sub-estados sequenci-
ais (disjuntos). Um estado pode ser decomposto em vrios nveis de in-
cluso.
O Exemplo 7.4 ilustra uma decomposio de estados em sub-estados.
Exemplo 7.4: Diagrama de Estados de um PC.
A Figura 7.18 d uma viso simplificada do ciclo de vida de um PC que
evolui ao longo de trs estados sequenciais: em inicializao,
trabalhando e fecho. A Figura 7.19 introduz uma primeira variante ao
exemplo base considerando que no PC se encontra instalado um
screen saver, que activado aps um determinado tempo de inactivi-
dade do acesso ao disco ou de operaes de entrada/sada.

Figura 7.18: Diagrama de estados de um PC (Exemplo 7.4).
CAPTULO 7 - UML MODELAO DO COMPORTAMENTO 221



Figura 7.19: Diagrama de estados de um PC, variante 1 (Exemplo 7.4).
A Figura 7.20 detalha o estado Trabalhando tendo em conta a
realizao concorrente de duas sub-mquinas de estado. Uma tem a
ver com o mecanismo de tratamento de eventos conduzidos pelo
utilizador (e.g., via teclado ou rato): o PC espera pelo input do utilizador,
seguidamente regista esse input e por fim faz a respectiva visualizao
no monitor. A outra mquina de estados tem a ver com a leitura do
tempo do relgio do PC e a correspondente actualizao no seu moni-
tor. Ambas as maquinas de estados actuam concorrentemente de forma
independente entre si.

Figura 7.20: Diagrama de estados de um PC, variante 2 (Exemplo 7.4).
222 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

7.5 Diagramas de Actividades
Um diagrama de actividades um caso particular de um diagrama de
estados, no qual todos ou a maioria dos estados so estados de
actividades e todas ou a maioria das transies so desencadeadas
pela concluso das actividades dos estados anteriores.
Ambos os tipos de diagramas so utilizados para modelar o tempo de
vida de um objecto ou sistema. Contudo, um diagrama de actividades
ilustra o fluxo de controlo entre actividades, enquanto que um diagrama
de estados ilustra o fluxo de controlo entre estados. Por outro lado, os
diagramas de interaco ilustram fluxos de controlo entre objectos.
Enquanto nos diagramas de interaco o foco na visualizao das
mensagens trocadas entre objectos, nos diagramas de actividades a
ateno incide na visualizao das operaes realizadas pelos objectos
intervenientes.
Uma actividade, como visto na Seco 7.4.4, corresponde a uma
execuo no atmica dentro de uma mquina de estados, ou doutra
forma, corresponde execuo de um conjunto de aces.
Os diagramas de actividades correspondem aos conhecidos fluxogra-
mas. Fornecem uma viso simplificada do fluxo de controlo de uma
operao ou de um processo de negcio, tambm designado por
workflow.

Figura 7.21: Exemplo genrico de diagrama de actividades.
A Figura 7.21 ilustra um exemplo genrico de um diagrama de
actividades.
Estes diagramas contm genericamente:
Estados-aco: execues atmicas, no interrompveis, com tempo
de execuo irrelevante.
Estados-actividade: execues no atmicas (decompostas), inter-
rompveis, em que o tempo de execuo normalmente relevante.
Transies.
CAPTULO 7 - UML MODELAO DO COMPORTAMENTO 223


Objectos.
Conforme ilustrado na Figura 7.22 no existe uma distino na
representao grfica entre estados-aco e estados-actividade,
excepto que os estados-actividade podem conter partes adicionais, tais
como especificao de aces de entrada e de sada e sub-mquinas
de estado. De ora em diante utilizar-se-, por motivos de simplicidade
de leitura do texto, o termo actividade para representar qualquer dos
estados referidos.

Figura 7.22: Estados-actividade versus estados-aco.
No desenho de diagramas de actividades (tal como nos diagramas de
estado) comum a utilizao de um conjunto de mecanismos que de
seguida se detalham, designadamente a especificao de tomada de
deciso, de concorrncia (i.e., a execuo de actividades concorrentes),
de troca de sinais entre diferentes mquinas de estado ou workflow, e
interaco com objectos.
7.5.1 Decises
A tomada de deciso um mecanismo comum no desenho de
diagramas de actividades (e de estado), que consiste em especificar
que actividade deve ser realizada aps a execuo da actividade
224 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

corrente. Tal especificao suportada por uma condio com guarda
(i.e., expresso lgica) que colocada de forma adjacente transio
de estado correspondente.
A figura 7.23 ilustra dois esquemas alternativos para a representao da
tomada de deciso relativamente ao processo levantar da cama. Os
esquemas so semanticamente equivalentes e representam o seguinte
fluxo de actividades: a seguir actividade Acordar algum pode deci-
dir Tomar pequeno-almoo ou Voltar para a cama mas no ambas
as actividades.

Figura 7.23: Deciso em diagramas de actividades.
Note-se que as transies entre as actividades referidas so
desencadeadas apenas na circunstncia de uma das condies com
guardas ser satisfeita, no exemplo ilustrado pelo facto de ter ou no
fome.
7.5.2 Caminhos Concorrentes
Considere-se que o processo de levantar da cama implica a execuo
das seguintes actividades tomar pequeno-almoo, fazer a higiene
matinal e cumprimentar a famlia. Considere-se que essas actividades
tm de se realizar obrigatoriamente, embora no seja relevante a sua
ordem de execuo.
CAPTULO 7 - UML MODELAO DO COMPORTAMENTO 225


O problema colocado representa uma situao tpica na modelao de
workflows: representar a execuo independente e concorrente de um
conjunto de actividades.

Figura 7.24: Concorrncia em diagramas de actividades.
O UML providencia a soluo a esta questo atravs dos conceitos de
difuso (fork) e de juno (join) de actividades, representados grafica-
mente por linhas a cheio conforme ilustrado na Figura 7.24. Esta linha
designa-se por barra de sincronizao.
Podem-se representar hierarquias de fluxos de actividades concor-
rentes, i.e., podem-se representar actividades e pares de linhas de
difuso/juno dentro de outros pares de linhas de difuso/juno.
Todavia, o nmero de linhas de difuso e de juno deve ser balan-
ceado correspondentemente.
7.5.3 Pistas (Swimlanes)
Na modelao de processos de negcio comum a realizao de
actividades por vrias entidades, participantes no dito processo. O UML
prope o conceito de pistas (swimlanes) como elemento que permite
agrupar as vrias actividades da responsabilidade de cada entidade
participante. Cada grupo separado por uma linha vertical.
226 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Cada pista tem um nome nico dentro do seu diagrama, que deve
corresponder ao nome da entidade participante, a qual deve ser uma
entidade do mundo real. Por exemplo, o nome de um perfil de utilizador,
o nome de uma organizao, ou o nome de um sistema de informao.
A Figura 7.25 representa o processo de negcio Preparar Proposta,
tpico de uma empresa de servios. So representadas trs entidades
participantes: o cliente, que solicita a proposta; o gestor comercial, que
prepara o oramento; e o gestor de produo, que pode eventualmente
intervir no processo, caso o servio solicitado exija aspectos especficos
da produo.

Figura 7.25: Diagramas de actividades com pistas.
Num diagrama de actividades com pistas, cada actividade pertence em
geral a uma nica pista, apenas as transies cruzam as pistas.
CAPTULO 7 - UML MODELAO DO COMPORTAMENTO 227


Contudo, podem existir situaes em que uma actividade realizada
por duas entidades. Nestes casos, a actividade representada sobre a
linha separadora em comum. Claro que esta soluo no
generalizvel: como representar actividades realizadas por mais que
trs entidades?; ou como representar actividades realizadas por duas
entidades que no se encontram graficamente adjacentes? (Este
aspecto uma limitao actual do UML, no tratado na especificao
1.3, existindo contudo algumas solues que podero vir a ser
adoptadas numa sua verso futura.)
7.5.4 Actividades e Objectos
Os diagramas de actividades podem explicitar relaes entre
actividades e objectos. Por exemplo, no diagrama da Figura 7.26
incluram-se relaes entre actividades e uma instncia da classe
Oramento. Estas relaes de dependncia permitem ilustrar o fluxo
de um objecto ao longo de um conjunto de actividades, representadas
por linhas dirigidas a tracejado.
Para alm de se ilustrar o fluxo de um objecto num diagrama de
actividades, podem ainda ilustrar-se os seus papis, atributos e estado.
No exemplo da Figura 7.26 apresenta-se o estado do objecto
:Oramento entre parntesis rectos, que ao longo do tempo se
encontra em aberto, preparado ou fechado.

228 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE


Figura 7.26: Diagramas de actividades com objectos.
7.5.5 Envio e Recepo de Sinais
O UML adopta os conceitos de evento de envio (output event) e
evento de recepo (input event) de sinais, os quais so usados,
respectivamente para explicitar a emisso e a recepo de um deter-
minado sinal. No sendo obrigatrio, a sua utilizao permite, contudo,
explicitar:
Relaes de dependncia (note-se a seta dirigida a tracejado entre
os eventos de envio e de recepo do sinal) entre distintas mqui-
nas de estado ou distintos diagramas de actividades pela troca de
eventos assncronos
CAPTULO 7 - UML MODELAO DO COMPORTAMENTO 229


Dentro da mesma mquina de estados, eventos que devero ocorrer
durante as respectivas transies de estados/actividades.
O evento de emisso representado graficamente por um polgono
convexo, enquanto que o evento de recepo representado por um
polgono cncavo.
A Figura 7.27 ilustra a emisso e recepo do sinal mudar(canal) entre
os diagramas de actividades correspondentes ao controlo de uma televi-
so.

Figura 7.27: Diagramas de actividades com smbolos para envio e
recepo de sinais.
230 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

7.5.6 Utilizaes Tpicas
Os diagramas de actividades so utilizados para modelar os aspectos
de comportamento de um sistema como um todo, de um subsistema, de
uma operao ou de uma classe. Pode-se tambm associar um diagra-
ma de actividades a um caso de utilizao ou a uma colaborao (para
modelar o comportamento de um conjunto de objectos).
No entanto, os diagramas de actividades so usados principalmente nas
duas situaes seguintes:
Para especificar operaes: Neste caso os diagramas de
actividades so usados como fluxogramas para especificar deta-
lhadamente um algoritmo. So particularmente usados os conceitos
de tomada de deciso, de difuso (fork) e de juno (join).
Para especificar workflows ou processos de negcio: Neste caso
o foco dos diagramas de actividades reside na identificao dos
actores intervenientes e a correspondente colaborao com o siste-
ma. So particularmente usados os conceitos das pistas e da mode-
lao do fluxo de objectos.
Apresentam-se de seguida dois exemplos que clarificam a aplicao
dos diagramas de actividades.

CAPTULO 7 - UML MODELAO DO COMPORTAMENTO 231


Exemplo 7.5: Diagrama de actividades da operao de Fibonacci.
Considere a funo Fibonacci no domnio dos nmeros inteiros dada
pela frmula:
fib(n) =1, se n 2; = fib(n-1)+ fib(n-2), se n> 2
A Figura 7.28 ilustra o diagrama de actividades (neste caso, tomando a
forma de fluxograma) correspondente ao algoritmo de implementao
da dita funo. Neste diagrama especificado um dado algoritmo, mas
outras variantes deste poderiam ser especificados. Por exemplo, poder-
se-ia apenas realizar um teste (n 2) no incio, em vez de dois (n=1 e
n=2), etc. (Fica como exerccio o desenho de outros algoritmos alterna-
tivos.) Note-se como se especifica iteraes custa de tomada de
decises, resultando graficamente em fluxos cclicos.

Figura 7.28: Diagrama de actividades da operao de Fibonacci
(Exemplo 7.5).

232 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Exemplo 7.6: Diagrama de actividades da disseminao de eventos
no WebDEI.
Considere o sistema WebDEI, que um sistema de informao de um
hipottico departamento de engenharia informtica (DEI), com interface
Web. (Para mais detalhes sobre o WebDEI consulte-se as Seces 11.4
e 11.5.)
Entre outros processos e funcionalidades, o WebDEI providencia o
processo de negcio designado por disseminao automtica de
eventos. A ideia geral, que os membros registados do WebDEI (em
geral, professores) podem submeter anncios de eventos que se
venham a realizar a curto/mdio prazo, e que podero ser pertinentes
para os restantes membros, ou eventualmente para o pblico em geral.
Complementarmente ao processo de submisso de anncios de
eventos, o processo de disseminao dos ditos eventos submetidos
realizado com uma determinada periodicidade e consiste no envio, por
e-mail ou SMS, de um sumrio de todos os eventos relevantes, a todos
os utilizadores registados que tenham manifestado o interesse em
receber este tipo de informao.
A Figura 7.29 ilustra atravs de um diagrama de actividades o processo
de negcio da disseminao automtica de eventos. Identificaram-se
trs intervenientes: o temporizador, que o responsvel por desenca-
dear periodicamente deste processo; o prprio sistema WebDEI,
responsvel pela generalidade das actividades do processo; e o
utilizador registado, que recebe o sumrio dos eventos relevantes para
perodo em causa.

CAPTULO 7 - UML MODELAO DO COMPORTAMENTO 233



Figura 7.29: Diagrama de actividades da proposta de um termo no
GTTI.

7.6 Exerccios
Ex.48. Considere o melhor cenrio para o caso de utilizao Enviar
Fax (o cenrio em que tudo corre bem). Considere um sistema
composto pelos seguintes objectos: mquina que envia; m-
quina que recebe; uma central que encaminha faxes e chama-
das telefnicas. Desenhe o diagrama de sequncia respectivo.
Ex.49. Considerem-se outros cenrios para o caso de utilizao
Comprar Bebida relativo ao sistema Mquina de Bebidas in-
troduzido anteriormente:
O utilizador introduziu mais dinheiro que o valor da bebida, e
a mquina tem dinheiro para troco
O utilizador introduziu mais dinheiro que o valor da bebida, e
a mquina no tem dinheiro para troco
234 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Desenhe os respectivos diagramas de sequncia e de colabora-
o.
Ex.50. Desenhe o diagrama de estados de uma tostadeira. Defina os
diferentes estados do po na tostadeira, sem esquecer de espe-
cificar os necessrios eventos, aces, e condies com guarda.
Ex.51. Desenhe o diagrama detalhado do estado Screen Saving de um
PC que inclua sub-estados concorrentes (ver Exemplo 7.4).
Considere, por exemplo, os estados responsveis por tratarem o
input do utilizador, outros responsveis pela gerao de imagens
e actualizao dinmica no monitor.
Ex.52. Desenhe o diagrama de estados da classe
javax.servlet.http.Servlet. Considere que um servlet
Java evolui ao longo de diferentes estados, tais como:
carregamento, inicializao, tratar pedido, destruio.
Ex.53. Idem ao exerccio anterior relativamente classe
java.applet.Applet.
Ex.54. Desenhe o diagrama de actividades correspondente ao
algoritmo do factorial de n (n! = 1 se n 1; n*(n-1)! se n > 1).
Ex.55. Desenhe o diagrama de actividades correspondente ao seguinte
processo de negcio: gesto de encontros com clientes:
1. Um vendedor telefona ao cliente e marca uma reunio.
2. Se a reunio na empresa, os tcnicos da empresa
preparam a sala de conferncias para a apresentao.
3. Se a reunio fora da empresa (no escritrio do cliente)
um consultor prepara a apresentao num computador
porttil.
4. O consultor e o vendedor renem-se com o cliente no
local e hora combinada.
5. O vendedor envia ao cliente uma carta a resumir o
sucesso da reunio.
6. Se a reunio resultou na identificao de um problema, o
consultor escreve uma proposta e envia-a para o cliente.
CAPTULO 7 - UML MODELAO DO COMPORTAMENTO 235


Ex.56. Modifique o diagrama de actividades da Figura 7.24 de modo a
especificar o processo levantar da cama com as seguintes
consideraes. A seguir actividade acordar um indivduo
realiza geralmente as seguintes actividades, sem uma ordem
predefinida: tomar pequeno-almoo, fazer a higiene matinal e
cumprimentar a famlia. Contudo, (1) apenas toma o pequeno-
almoo se no tiver pressa; e (2) apenas cumprimenta a famlia
se estiver bem disposto.
Ex.57. Considere o seguinte cdigo Java constitudo pelas classes
SimpleThread e TwoThreadsTest. Desenhe o diagrama de
classes que o suporta e o diagrama de colaborao
correspondente a instncias da classe TwoThreadsTest.

public class SimpleThread extends Thread {
public SimpleThread(String str) {
super(str);
}
public void run() {
for (int i = 0; i < 10; i++) {
System.out.println(i + " " + getName());
try {
sleep((long)(Math.random() * 1000));
} catch (InterruptedException e) {}
}
System.out.println("DONE! " + getName());
}
}
public class TwoThreadsTest {
public static void main (String[] args) {
SimpleThread jamaica, fiji;
jamaica= new SimpleThread("Jamaica");
fiji= new SimpleThread("Fiji")
jamaica.start();
fiji.start();
}
}
236 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE




Captulo 8 - UML MODELAO DA
ARQUITECTURA
Tpicos
Introduo
Componentes e Ns
Diagramas de Componentes
Diagramas de Instalao
Exerccios

8.1 Introduo
Os diagramas de arquitectura (ou diagramas de implementao)
1

descrevem aspectos da fase de implementao e instalao de um
sistema de software, designadamente a estrutura e dependncias de
cdigo fonte e de mdulos executveis tal como a sua respectiva
instalao nas diferentes plataformas compu-tacionais subjacentes.

1
A especificao 1.3 do UML designa-os por diagramas de implementao.
Todavia, a designao de diagramas de arquitectura parece-nos mais
adequada tendo em conta que estes diagramas podem ser aplicados no
desenho de diferentes tipos de arquitecturas. Por exemplo: arquitectura de
sistemas de informao (que a sua aplicao mais conhecida) ou arquitectura
de negcios e de organizaes.
238 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Estes diagramas apresentam-se sob duas formas: diagramas de com-
ponentes e diagramas de instalao.
Os diagramas de componentes so usados para modelar a arquitectura
de um sistema de software na perspectiva dos seus componentes digi-
tais (e.g., ficheiros de cdigo fonte, de executveis, de configurao, ta-
belas de dados, documentos de gesto do projecto), explicitando
principalmente as suas mltiplas dependncias.
Os diagramas de instalao, por outro lado, so usados para modelar a
arquitectura de um sistema informtico na perspectiva dos seus
componentes fsicos (e.g., computadores, adaptadores de rede,
impressoras, routers, cablagem), explicitando as suas dependncias de
comunicao. Permitem ainda identificar quais os componentes que so
instalados em cada n computacional.
Estes diagramas podem tambm ser aplicados na modelao de
negcios e de organizaes caso se considere que os componentes
digitais sejam procedimentos e regras de negcio e que os componen-
tes no digitais (i.e., os ns) constituam a infra-estrutura da organizao
atravs de um conjunto de recursos (humanos e outros) do negcio.
(Na nossa opinio os diagramas de implementao constituem a parte
mais limitada, mal explorada e compreendida do UML. H inmeros
aspectos de desenho e de organizao que a sua actual verso no
aborda, deixando-os em aberto, ao critrio que os seus utilizadores
venham a definir, caso a caso. No lado oposto desta abordagem de
flexibilidade e de no definio, encontra-se, por exemplo, o EAB
(Entreprise Application Blueprint) [Boar98] que prope uma notao
muito completa e rigorosa para desenho de arquitecturas de sistemas
de informao, em particular para o desenho de sistemas, plataformas e
suas inter-relaes.)
8.2 Componentes e Ns
8.2.1 Componentes
Um componente uma pea bsica na implementao de um sistema;
consiste, na prtica, num conjunto de artefactos fsicos em formato
CAPTULO 8 - UML MODELAO DA ARQUITECTURA 239


digital, por exemplo ficheiros de cdigo (fonte, binrio ou executveis)
ou ficheiros de documentos relativos ao negcio.
Definem-se pelo menos trs tipos distintos de componentes:
Componentes de instalao: constituem a base dos sistemas
executveis (e.g., DLL, executveis, controlos Active-X, classes
Java).
Componentes de trabalho: a partir dos quais so criados os
componentes de instalao (e.g., ficheiros com cdigo fonte, fichei-
ros de dados, documentos).
Componentes de execuo: criados como resultado da execuo
de um sistema (e.g., processos, threads, agentes de software).
Estes componentes so apenas representados nos diagramas de
instalao (ver mais frente).

Figura 8.1: Representao grfica de componentes.
Um componente de software uma parte fsica de um sistema: existe
de facto num determinado computador e no apenas na mente do
analista, como acontece com o conceito de classe. Adicionalmente, um
componente implementa uma ou mais classes, as quais so represen-
tadas dentro do cone de componente ou com relaes explcitas de
dependncia de implementao, conforme ilustrado na Figura 8.1.
240 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Elementos que residam num componente so apresentados dentro do
smbolo do componente respectivo. Pode-se, se for conveniente,
representar o tipo de visibilidade desses elementos semelhana do
que acontece com os pacotes. O significado da visibilidade depende do
tipo de componente. Por exemplo, se for um componente com cdigo
fonte, pode corresponder a controlar a acessibilidade aos seus constru-
tores internos; se for um componente com cdigo executvel, a visibili-
dade pode corresponder possibilidade de outros componentes execu-
tveis poderem aceder ou invocar o seu prprio cdigo.
O desenvolvimento de software baseado em componentes pressupe a
existncia de componentes com um sentido mais restrito que este
adoptado no UML. Ou seja, a noo de componente em UML lata,
mas inclui naturalmente a noo de componente de software
encontrada por exemplo nas propostas do Java Beans, Enterprise Java
Beans, ou Active-X. Um aspecto importante ligado noo de
componente tem a ver, como analisado na Seco 6.4, com a noo
de interface. Tipicamente, os componentes de software (no sentido
restrito acima referido) implementam uma ou mais interfaces e atravs
destas interfaces que providenciam as suas funcionalidades a outros
componentes. A Figura 8.2 ilustra a relao (de realizao) entre
componentes e interfaces, tal como a relao de dependncia entre
componentes, que se faz atravs do conceito de interface.

Figura 8.2: Componentes e Interfaces.
A especificao 1.3 do UML identifica os seguintes esteretipos para
componentes:
document: denota um documento.
CAPTULO 8 - UML MODELAO DA ARQUITECTURA 241


executable: denota um programa que possa ser executado
num n.
file: denota um documento contendo cdigo fonte ou dados.
library: denota uma biblioteca dinmica ou esttica.
table: denota uma tabela de uma base de dados.
8.2.2 Ns
Um n um objecto fsico que representa um recurso de
processamento, geralmente tendo capacidades de memria e de
processamento. Os ns podem consistir em recursos computacionais
(hardware), mas tambm em recursos humanos ou recursos de proces-
samento mecnico. Os ns podem ser representados como tipos e co-
mo instncias. Instncias de ns podem conter instncias de objectos e
de componentes.

Figura 8.3: Representao grfica de ns.
Um n representado como um cubo tridimensional conforme ilustrado
na Figura 8.3. Dois ns podem-se encontrar ligados atravs de relaes
de associao. Estas especificam a existncia de caminhos de comuni-
cao entre os correspondentes ns e podem ser caracterizadas por um
esteretipo, de modo a explicitar o tipo de comunicao envolvido (e.g.,
o tipo de canal ou o tipo de rede).
As propriedades dos ns (e.g., capacidade de memria principal,
nmero de processadores, data de aquisio, ) so representadas por
242 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

marcas com valores. Por outro lado, podem-se definir esteretipos, com
cones correspondentes, para modelar diferentes tipos de recursos de
processamento.
Para efeito dos exemplos descritos neste livro assume-se a existncia
de dois esteretipos de ns para representao de recursos computa-
cionais:
processor: denota um n que pode executar um componente
de software.
device: denota um n que no tem capacidade para executar
componentes de software; e.g., uma impressora, um scanner, ou um
monitor.
Assume-se, por omisso, que um n do esteretipo processor
(e.g., n Servidor da Figura 8.3).
8.2.3 Relaes entre Ns e Componentes
Um n pode conter componentes. Tal facto pode ser traduzido pela
incluso dos componentes no smbolo do n, ou pelo estabelecimento
de uma relao de dependncia, de esteretipo support entre o n
e os componentes suportados, conforme ilustrado na Figura 8.4.

Figura 8.4: Relao entre ns e componentes.
Ns e componentes partilham um conjunto de semelhanas e
diferenas. As semelhanas so que ambos podem (1) participar em
relaes de generalizao, dependncia e associao; (2) ser
aninhados; (3) ter instncias; e (4) participar em interaces. As
diferenas so que os (1) componentes so elementos que participam
CAPTULO 8 - UML MODELAO DA ARQUITECTURA 243


na execuo de um sistema; ns so elementos que suportam e exe-
cutam componentes; e que os (2) componentes representam agrupa-
mento fsico de elementos lgicos; ns representam a instalao fsica
de componentes.
8.3 Diagramas de Componentes
Um diagrama de componentes ilustra as dependncias entre vrios
componentes de software. Entre outros, incluem-se nesta definio lata:
artefactos de cdigo fonte, de cdigo binrio, de cdigo executvel,
procedimentos de negcio e documentos. Um mdulo de software pode
ser representado por um esteretipo, por exemplo, para ter uma apre-
sentao grfica distinta de outros tipos de componentes.
Um diagrama de componentes representa apenas tipos de componen-
tes e nunca instncias de componentes. Para ilustrar instncias de com-
ponentes deve ser usado um diagrama de instalao (possivelmente,
uma verso simplificada sem ns).
Entre outras motivaes para a construo de modelos de componen-
tes, salientam-se as seguintes:
Os clientes podem ver a estrutura final do sistema, mesmo antes
deste estar concludo.
A equipa de desenvolvimento tem uma viso da arquitectura fsica
do sistema, pelo que pode trabalhar de forma mais controlada e sis-
temtica.
Os escritores tcnicos (que produzem, por exemplo, a
documentao do sistema, manuais de utilizador, manuais tcnicos)
podem entender melhor o que esto a escrever, detalhar alguns
aspectos do sistema, mesmo antes de este se encontrar concludo.
Apresentam-se de seguida dois exemplos de aplicao de diagramas
de componentes: um que ilustra as dependncias de artefactos fsicos
referenciados numa pgina HTML; e um segundo exemplo que ilustra
as dependncias entre mdulos de instalao constituintes de uma
aplicao tpica do Windows.
244 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Exemplo 8.1: Diagrama de Componentes relativo a uma Pgina
HTML.
Considere a pgina Web Example1.html com uma referncia a um
applet Java e com o seguinte contedo:
<html>
<head>
<title>The Animator Applet (1.1) - example
1</title>
</head>
<body>
<h1>The Animator Applet (1.1) - example 1</h1>
<applet codebase="." code=Animator.class
width=460 height=160>
</applet>
<a href="Animator.java">The source.</a>
<hr>
</body>
</html>

O diagrama de componentes correspondente a este mini-sistema
consiste nos seguintes ficheiros: example1.html, Animator.class,
e Animator.java. A Figura 8.5 ilustra essas relaes de dependncia.
Note-se em particular a relao de dependncia explicita entre o
componente Animator.java e a interface Java MouseListener.
java definida no pacote java.awt.event.
CAPTULO 8 - UML MODELAO DA ARQUITECTURA 245



Figura 8.5: Diagrama de componentes do Exemplo 8.1.
Exemplo 8.2: Diagrama de Componentes relativo instalao de
uma aplicao.
Considere a aplicao WinCOR desenvolvida sobre ambiente MS-
Windows e responsvel pela gesto de (entrada e sada de) cor-
respondncia de uma organizao. A aplicao consiste num conjunto
variado de componentes de instalao, nomeadamente:
wincor.exe: ficheiro que contm o executvel da aplicao
pblib32.dll, sde32.dll, sdemdb32.dll: bibliotecas com
cdigo binrio que providenciam funcionalidades adicionais
wincor.hlp: ficheiro de ajuda sobre a aplicao.
wincor.ini: ficheiro de configurao da aplicao
entrada.db, saida.db: ficheiros/tabelas da base de dados de
suporte
A Figura 8.6 ilustra o respectivo diagrama de componentes para a
situao descrita. Note-se nas dependncias identificadas entre os
diferentes componentes de instalao. Estas dependncias referem que
o executvel wincor.exe (i.e., a aplicao WinCOR) apenas pode
correr se todos os restantes componentes tiverem sido instalados
246 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

adequadamente e que o mdulo sdemdb32.dll depende do mdulo
sde32.dll.


Figura 8.6: Diagrama de componentes do Exemplo 8.2.
Neste exemplo houve o cuidado particular de se explicitar os estere-
tipos dos diferentes componentes envolvidos.

8.4 Diagramas de Instalao
Um diagrama de instalao ilustra a configurao dos elementos de
processamento e dos componentes de software, processos e objectos
neles suportados. Instncias de componentes de software representam
manifestaes de execuo das unidades de cdigo.
Um diagrama de instalao (tambm designado nalgumas
circunstncias por diagramas de distribuio) consiste num conjunto
de ns ligados por associaes de comunicao. Os ns podem conter
instncias de componentes (de execuo), o que significa que um
CAPTULO 8 - UML MODELAO DA ARQUITECTURA 247


componente instalado e executado num n. Por outro lado, os
componentes so compostos por objectos.
Se utilizarmos os diagramas de instalao na modelao de processos
de negcios, os elementos de processamento so as unidades
organizacionais e os trabalhadores enquanto que os componentes de
software so os processos e documentos usados pelas unidades
organizacionais e pelos trabalhadores.
Seguem-se dois exemplos de diagramas de instalao. O primeiro
exemplo diz respeito a uma verso simplificada do servio 118 da
Portugal Telecom numa verso cliente/servidor. O segundo exemplo
representa o equipamento hardware tipicamente existente numa confi-
gurao domstica.
Exemplo 8.3: Diagrama de Instalao do servio 118 da PT.
Considere-se uma verso simplificada do servio 118 da Portugal
Telecom numa sua verso cliente/servidor em que o cliente uma
aplicao previamente instalada e configurada num PC com MS-
Windows. (Nota: existe tambm este servio na verso Web em
http://net118.telecom.pt).

Figura 8.7: Diagrama de instalao do Exemplo 8.3.
Pelo facto do diagrama de instalao apresentar componentes, todos os
elementos apresentados tm de ser instncias, neste caso so apre-
sentadas instncias de ns e de componentes. Outro aspecto relevante
248 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

deste exemplo a representao, neste diagrama de instalao, da
existncia de vrios PC atravs do caracter * colocado no canto supe-
rior direito do n PC.

Exemplo 8.4: Diagrama de Instalao do Sistema de Trabalho
Domstico.
A Figura 8.8 apresenta o diagrama de instalao correspondente a um
sistema de trabalho domstico constitudo por um PC, com alguns equi-
pamentos adicionais, por exemplo: uma impressora, um monitor, colu-
nas de som, e um modem. O modem permite a ligao Internet atra-
vs de um determinado ISP (Internet Service Provider).

Figura 8.8: Diagrama de instalao (de tipos) do Exemplo 8.4.
Caso se pretendesse ilustrar uma configurao particular do diagrama
apresentado e/ou ilustrar os componentes de software que deveriam
existir numa determinada configurao, ter-se-ia de desenhar um
diagrama de configurao de nvel de instncias. A Figura 8.9 ilustra
uma possvel configurao (instanciao) desenhada a partir do diagra-
ma da Figura 8.8.
CAPTULO 8 - UML MODELAO DA ARQUITECTURA 249



Figura 8.9: Diagrama de instalao (de instncias) do Exemplo 8.4.
8.5 Exerccios
Ex.58. Pretende-se o diagrama de componentes correspondente
aplicao ex-pipes desenvolvido em linguagem C, com os
seguintes mdulos: ex-pipes.c util.c server.c
client.c, e com dependncias definidas pelo seguinte
makefile:

CC = gcc
CFLAGS = -g
ex-pipes : ex-pipes.o util.o server.o client.o
$(CC) -g -o ex-pipes ex-pipes.o util.o server.o
client.o

Ex.59. Pretende-se o diagrama de componentes correspondente
pgina Web http://www.tvi.pt/ com o seguinte contedo
(tenha em considerao os componentes (ficheiros) representa-
dos a negrito.):

<html>
<head>
<meta http-equiv="content-type" content="text/html">
<title>TVI OnLine</title>
</head>

250 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

<frameset rows="296,*" border="0" frameborder="NO"
framespacing="0">
<frame src="index_hdr.html" name="hdr" noresize>
<frame src="index_ix.html" name="ix" noresize
scrolling="NO">
</frameset>
<noframes>
<bodbgcolor="#000000"
background="HmPG/directoIX_BG.jpg">
</body>
</noframes>
</html>

Ex.60. Pretende-se o diagrama de instalao da infra-estrutura compu-
tacional de apoio s suas aulas prticas. Considere apenas os
ns existentes e os seus tipos de comunicao.
Ex.61. Alterar o diagrama produzido no exerccio anterior de modo a
incluir a descrio dos postos de trabalho e os componentes de
software mais relevantes (e.g., servidor Web, ferramentas de
trabalho do tipo Rose ou VisualStudio, servidor BD, sistema
operativo).
Ex.62. Considere o servio 118 da PT conforme introduzido no Exemplo
8.3. Modifique o exemplo dado tendo em considerao que o
servio acedido atravs de um cliente/browser Web.
Ex.63. Pretende-se o diagrama de instalao para modelar a seguinte
situao:
Uma empresa industrial est estruturada em quatro
departamentos: produo, comercial, controlo da qualidade, e
administrativo-financeiro. Cada um destes departamentos tem
um director respectivo. O director-geral o responsvel pela
coordenao e superviso de todos os departamentos. O
departamento administrativo-financeiro est estruturado em duas
seces, respectivamente a seco administrativa e a seco
financeira.


CAPTULO 8 - UML MODELAO DA ARQUITECTURA 251


Sugestes:
(1) Considere que os recursos do negcio (unidades orgnicas e
as pessoas) so ns do diagrama a desenhar.
(2) Represente, atravs de esteretipos, o tipo das associaes
existentes entre ns.
252 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE




























Captulo 9 - UML ASPECTOS AVANADOS
Tpicos
Introduo
A Arquitectura do UML
Mecanismos de Extenso
Perfis UML
Sistemas de Componentes e Reutilizao
Tipos Parametrizveis
XMI XML Metadata Interchange
Concluso
9.1 Introduo
Vimos ao longo dos captulos anteriores os principais aspectos da
linguagem UML. Em particular, vimos a sua estrutura de conceitos e a
sua aplicao segundo diferentes perspectivas, designadamente segun-
do a perspectiva de modelao de casos de utilizao, estrutural, com-
portamental e arquitectural. Analismos, nos captulos anteriores, o
UML segundo a perspectiva da sua utilizao.
Neste captulo introduzimos alguns aspectos adicionais, que considera-
mos avanados, que permitem ao utilizador uma compreenso mais
profunda do UML e, por conseguinte, uma melhor aplicao. Nomeada-
mente, analisamos os seguintes aspectos:
A estrutura e arquitectura do UML (i.e. como que o prprio UML se
encontra definido e organizado).
254 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Mecanismos de extenso do UML (i.e. como estender o UML de
forma a contemplar exigncias de modelao mais recentes e
futuras). Sero apresentados alguns exemplos concretos de com-
juntos de elementos que estendem o UML, os quais so designados
por perfis.
Noes gerais sobre o conceito de componente, sistemas de
componentes (toolkits e frameworks), famlias de aplicaes e
reutilizao.
Como representar em UML tipos parametrizveis, em particular
classes parametrizveis e colaboraes parametrizveis (no
contexto de padres de desenho).
O standard OMG de interoperao de modelos UML em XML, o
XMI. O objectivo do XMI que os modelos UML possam ser
exportados/importados e, por conseguinte, usados por diferentes
ferramentas CASE de forma independente.
(Embora a leitura deste captulo no seja essencial para uma utilizao
corrente do UML, tal leitura permite dar uma panormica mais abran-
gente e profunda da sua arquitectura e correspondentes capacidades.)
9.2 A Arquitectura do UML
9.2.1 A Estrutura do UML a Quatro Camadas
O UML est estruturado numa arquitectura de quatro camadas
conforme sugerido na Figura 9.1: meta-metamodelo; metamodelo; mo-
delo; e objectos do utilizador.
CAPTULO 9 - UML ASPECTOS AVANADOS 255



Figura 9.1: A arquitectura do UML a quatro camadas.
Este tipo de arquitectura a quatro camadas apresenta uma infra-
estrutura adequada para a definio da semntica associada a modelos
complexos. As camadas distinguem-se pelo nvel de generalidade e de
abstraco dos seus elementos constituintes.
Na camada mais baixa da arquitectura Camada Objectos do
Utilizador encontram-se os elementos que constituem as instncias
concretas dos elementos representados num modelo definido pelo
utilizador do UML (i.e., o analista ou consultor, e no o utilizador do
sistema final): os objectos, os cenrios de um caso de utilizao, as
instncias de componentes, etc. Por exemplo, o objecto Termo0033, o
valor proposto, a operao muda_estado, ou a instncia do servlet
termoServlet0444 ilustram elementos desta camada.
Na segunda camada Camada Modelo encontram-se os elementos
que constituem as abstraces definidas pelo utilizador do UML no seu
processo de definio de modelos. Por exemplo, a classe Termo, o
atributo estado, a operao mudaEstado, o componente
TermoServlet ou o caso de utilizao Propor Termo ilustram
elementos desta camada.
Na terceira camada Camada Metamodelo encontram-se os
elementos que constituem as abstraces definidas pelos criadores do
UML, ou sejam, os elementos que constituem a estrutura de conceitos
256 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

do UML, com base nos quais se podem definir modelos (da a
designao de metamodelo). Por exemplo: Classe, Atributo,
Operao, Componente, N.
Estas trs primeiras camadas so aquelas a que a generalidade dos
utilizadores UML acabam por recorrer na maior parte das vezes, quer
como utilizadores (da terceira camada) quer como criadores (de
elementos das duas primeiras camadas). Por isso natural que se
coloque a questo: para qu a quarta camada? De facto, esta camada
Camada Meta-metamodelo ser raramente usada pelo utilizador
normal do UML. No entanto, necessria para os responsveis pelo
desenho e comparao deste tipo linguagens. Esta camada permite
definir os elementos que sero responsveis pela especificao de
metamodelos. Por exemplo: MetaClasse, MetaAtributo,
MetaOperao, MetaComponente, MetaN.
Sai fora dos objectivos deste livro aprofundar esta quarta camada da
arquitectura do UML. Por outro lado, ilustra-se na seco seguinte uma
panormica geral sobre a camada do metamodelo.
9.2.2 A Camada Metamodelo
O UML descrito atravs de um modelo, designado metamodelo por
ser um modelo que descreve outro modelo, tambm ele descrito em
UML. O metamodelo UML encontra-se estruturado nos seguintes
pacotes lgicos: Foundation, Behavioral Elements e Model
Management (ver Figura 9.2), os quais por sua vez so decompostos
noutros subpacotes.
CAPTULO 9 - UML ASPECTOS AVANADOS 257



Figura 9.2: Os pacotes de alto nvel do metamodelo UML.
O metamodelo descrito de forma semi-formal usando as seguintes
perspectivas: (1) sintaxe abstracta, (2) regras e (3) semntica. A sintaxe
abstracta providenciada atravs de um modelo descrito num
subconjunto do prprio UML, consistindo nos diagramas de classes
UML e por uma descrio em linguagem natural. As regras so
especificadas atravs de linguagem natural e da linguagem formal OCL.
Por ltimo, a semntica descrita principalmente em linguagem natural.
De facto, o metamodelo UML descrito por uma combinao de
notaes grficas, linguagem natural e linguagem formal, o que
segundo os seus proponentes oferece um compromisso adequado entre
expressividade, rigor e facilidade de leitura [OMG99].
Pacote Foundat i on
O pacote Foundation o componente da linguagem que especifica a
estrutura esttica dos modelos. Contem os seguintes pacotes Core,
Extension Mechanisms, e Data Types (ver Figura 9.3).
O pacote Core especifica os conceitos bsicos do metamodelo e define
a estrutura arquitectural que permite a associao de construtores
adicionais, tais como metaclasses, metaassociaes, e metaatributos.
258 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE


Figura 9.3: Os subpacotes do pacote Foundation.
O pacote Core define os principais construtores do metamodelo
(abstractos e concretos) necessrios ao desenvolvimento de modelos
de objectos. Os construtores abstractos so aqueles que no podem ser
usados directamente pelo utilizador e que apenas so concebidos para
dar estrutura e organizao ao metamodelo UML, tais como
ModelElement, GeneralizableElement e Classifier. Por outro
lado, os construtores concretos so aqueles que so usados (i.e.,
instanciveis) directamente pelo utilizador, tais como Class,
Attribute, Operation e Association.
Um classificador (classifier) um supertipo definido no metamodelo
UML que usado extensivamente ao longo da especificao do UML
sempre que se pretende referir um elemento que descreve estrutura e
comportamento, ou seja, sempre que se pretende referir indistintamente
a qualquer dos seguintes conceitos: classe, interface, tipo de dados,
caso de utilizao, actor, sinal, subsistema, n ou componente.
A Figura 9.4 ilustra o diagrama de classes dos classifiers definidos no
pacote Core|Foundation. (Note-se que a explicitao dos outros
classifiers, por exemplo actor ou caso de utilizao so definidos
noutros pacotes.) Segundo uma descrio mais rigorosa, Classifier
uma super metaclasse (meta, porque uma classe do metamodelo),
CAPTULO 9 - UML ASPECTOS AVANADOS 259


abstracta, que especializada por outras metaclasses, tais como
Class, Interface ou Node, em que estas so metaclasses concretas.

Figura 9.4: Os classifiers definidos no subpacote Core|Foundation.
O pacote Extension Mechanisms especifica como os elementos do
modelo podem ser configurados e estendidos com nova semntica.
Define a semntica de esteretipos, restries e marcas com valores
atravs da definio dos seguintes construtores concretos, respectiva-
mente Stereotype, Constraint e TaggedValue.
Por fim, o pacote Data Types define as estruturas de dados bsicas
da linguagem, tais como tipos de dados primitivos (e.g., Integer,
String, Time), enumerados (e.g., Boolean, AggregationKind,
VisibilityKind), e outros (e.g., Expression, Mapping, Name,
Multiplicity).

260 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Pacote Behavi or al El ement s
O pacote Behavioral Elements contem os subpacotes Common
Behavior, Collaboration, Use Cases, Activity Graphs, e
State Machines (ver Figura 9.5) que permitem representar o
comportamento e a dinmica de um sistema. Incluem os conceitos
discutidos ao longo dos Captulos 5 e 7, tal como os seus nomes
sugerem.

Figura 9.5: Os subpacotes do pacote Behavioral Elements.

Pacote Model Management
O pacote Model Management depende do pacote Foundation e
consiste num diagrama de classes que ilustra como os elementos
Model, Package e Subsystem se organizam e relacionam entre si.
Estes elementos servem principalmente como unidades de agrupa-
mento e de organizao dos outros elementos do modelo.
CAPTULO 9 - UML ASPECTOS AVANADOS 261


9.3 Mecanismos de Extenso
O UML providencia um nmero elevado de conceitos e notaes
particularmente concebidos de forma a satisfazer os requisitos tpicos
de modelao de software. Contudo, podem surgir situaes em que se
torna desejvel a introduo de conceitos e/ou de notaes adicionais
para alm dos definidos originalmente no momento da definio do
standard. Para contemplar tais situaes, conforme introduzido na
Seco 4.6.2, o UML providencia diversos mecanismos que permitem
estend-lo de forma consistente: restries, marcas e esteretipos.
Estes mecanismos permitem [OMG99]:
Introduzir novos elementos de modelao para uma maior
expressividade e compreenso dos modelos UML a criar.
Definir itens standard que no so considerados suficientemente
interessantes ou complexos para serem definidos directamente
como elementos do metamodelo UML.
Definir extenses especficas das linguagens de implementao ou
especficas dos processos de desenvolvimento.
Associar arbitrariamente informao semntica e outra aos elemen-
tos do modelo.
Estes mecanismos aplicam-se aos elementos do modelo, no s suas
instncias. Representam, portanto, extenses prpria linguagem que
permitem alterar a estrutura e semntica dos modelos criados.
A Figura 9.6 ilustra a sintaxe abstracta dos mecanismos de extenso do
UML. Note-se a definio e relao entre as metaclasses Stereotype,
Constraint e TaggedValue.
262 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE


Figura 9.6: Mecanismos de extenso.
Restries
Uma restrio consiste na especificao de semntica associada a um
(ou a um conjunto ordenado de) elemento(s) do modelo. Tal
especificao escrita numa determinada linguagem de restries, que
pode ser mais ou menos formal. Por exemplo: OCL, linguagem de
programao, notao matemtica ou linguagem natural. Pelo facto da
escolha da linguagem ser arbitrria, as restries so um mecanismo de
extenso [OMG99].
No metamodelo uma restrio (Constraint) deriva directamente de
um ModelElement descreve as restries semnticas que esse
ModelElement tem de satisfazer. Por outro lado, restries associadas
a um Stereotype aplicam-se a cada ModelElement ligados ao
Stereotype.
Marcas com Valor
Uma marca com valor um par <marca,valor> que permite associar
arbitrariamente informao a qualquer elemento do modelo. Uma marca
um nome arbitrrio, havendo contudo alguns nomes predefinidos
como elementos standard (e.g., new, destroyed, transient, self, disjoint,
xor). O significado de cada marca intencionalmente especfico do
CAPTULO 9 - UML ASPECTOS AVANADOS 263


contexto da sua utilizao, podendo ser determinado pelo seu utilizador
ou por convenes das ferramentas de suporte.
Esteretipos
Um esteretipo providencia um mecanismo de classificao de
elementos, tal que eles se comportem, de alguma forma, como se
fossem instncias de novos construtores definidos no metamodelo.
Um esteretipo pode especificar adicionalmente restries e marcas
com valor que sero aplicadas s suas instncias. Um esteretipo pode
ser usado para especificar diferenas de utilizao ou de semntica
entre dois elementos com uma estrutura relativamente semelhante.
Um esteretipo tem a indicao da sua classe base e, opcionalmente,
uma representao grfica (cone) correspondente. A classe base de
um esteretipo uma classe no metamodelo UML (i.e., no um
elemento de modelao criado pelo utilizador) tal como Class,
Association ou Refinement. Um esteretipo pode ser um subtipo
de um ou mais esteretipos existentes, dos quais herda as restries e
marcas com valor. Adicionalmente, um esteretipo pode adicionar as
suas prprias restries, a sua prpria lista de marcas com valor, e um
novo cone para representao visual.
Se um elemento do modelo (de nvel utilizador) classificado por um
determinado esteretipo, a classe base desse elemento tem de coincidir
com a classe base especificada para esse esteretipo. As restries e
marcas com valores so implicitamente associadas a esse elemento do
modelo.
9.4 Perfis UML
Os mecanismos de extenso ilustrados na Seco 9.3 devem ser
considerados, tal como discutido na Seco 4.6, apenas como ltimo
recurso. Pelas suas prprias caractersticas de especificidade, as
extenses no so normalmente compreendidas, suportadas e aceites
pela generalidade dos utilizadores UML. De forma a organizar e
264 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

promover uma evoluo mais pacfica destas extenses, os promotores
do UML propuseram o conceito de perfil.
Um perfil UML um nome dado a um conjunto predefinido de
esteretipos, marcas com valor, restries e cones que conjuntamente
especializam e configuram o UML para um determinado domnio de
aplicao ou um determinado processo de desenvolvimento. Note-se
que um perfil no estende o UML atravs da introduo de novos
conceitos de base.
Na especificao 1.3 do UML so descritos dois perfis, designados
como perfis standard: (1) perfil para processos de desenvolvimento de
software; e (2) perfil para modelao de processos e estruturas de ne-
gcios.
Apresentamos de seguida, a ttulo de exemplo, algumas consideraes
sobre os dois perfis referidos, bem como o perfil de modelao de
aplicaes Web baseado no trabalho de Jim Conollen [Conallen00].
Existe um razovel conjunto de outros esforos de extenso do UML
para vrios domnios de aplicao (note-se que nem todos esses
esforos sero reconhecidos pela OMG como perfis UML). Referem-se
a ttulo de exemplo: (1) as extenses de Eriksson-Penker para mode-
lao de negcio (Eriksson-Penker Business Extensions) [Penker00]
suportadas por exemplo pela ferramenta Qualiware; (2) as extenses
para modelao de negcio providenciadas na ferramenta ProVision
Workbench, da empresa Proforma [Proforma00]; (3) extenses para
modelao de dados, propostas pela Rational [Rational00]; ou (4)
extenses para modelao de aplicaes baseadas em agentes de
software [Odell00].
(Nota: Sai do mbito deste livro aprofundar a descrio dos perfis UML,
tal como detalhar a sua aplicao em situaes concretas.)
9.4.1 Perfil para Processos de Desenvolvimento de
Software
O perfil Processos de Desenvolvimento de Software consiste na
definio de um conjunto de esteretipos (actualmente no foram
definidos quaisquer marcas com valor ou restries) usados tipicamente
CAPTULO 9 - UML ASPECTOS AVANADOS 265


em processos de desenvolvimento de software inspirados no Unified
Process [Jacobson99], em particular pelo RUP ou o ICONIX (ver
Captulos 10 a 11).

Classe do Metamodelo Nome do Esteretipo
Model use-case model
Model analysis model
Model design model
Model implementation model
Package use-case system
Package analysis system
Subsystem design system
Subsystem implementation system
Package analysis package
Subsystem design subsystem
Subsystem implementation subsystem
Package use-case package
Package analysis service package
Subsystem design service subsystem
Class boundary
Class entity
Class control
Association communicate
Association subscribe
Collaboration use-case realization
Tabela 9.1: Resumo dos esteretipos definidos no perfil Processos de
Desenvolvimento de Software.

266 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Esteretipos de Modelos, Pacotes e Subsistemas
Um sistema modelado com base no Unified Process consiste em vrios
modelos relacionados. Esses modelos so caracterizados pela fase do
ciclo de vida que representam, designadamente: casos de utilizao;
anlise; desenho; e implementao.
Casos de Utilizao
O modelo de casos de utilizao (use case model) especifica os
servios que um sistema providencia do ponto de vista dos seus utiliza-
dores.
Um sistema de casos de utilizao (use case system) um pacote de
nvel inicial ou de topo, e contm outros pacotes (de esteretipo use
case package) e/ou casos de utilizao e relaes respectivas. Por
fim, um use case package um pacote que contm apenas casos de
utilizao e relaes.
Anlise
Um modelo de anlise (analysis model) um modelo cujo pacote de
mais alto nvel do esteretipo analysis system. Este pacote contm
pacotes de anlise (de esteretipo analysis package) e/ou pacotes de
servios (de esteretipo analysis service package) e/ou classes de
anlise (de esteretipos entity, boundary e control) e respectivas
relaes. Um pacote de anlise contm pacotes de anlise, pacotes de
servios de anlise, classes de anlise e relaes. Por fim, um pacote
de servio de anlise contm apenas classes de anlise e relaes.
Desenho
Um modelo de desenho (design model) um modelo cujo subsistema
de mais alto nvel do esteretipo design system. Um sistema de
desenho contm subsistemas de desenho (de esteretipo design
subsystem) e/ou subsistemas de servios de desenho (de esteretipo
design service subsystem) e/ou classes de desenho e respectivas
relaes. Um subsistema de desenho contm outros subsistemas de
desenho, subsistemas de servios de desenho, classes de desenho e
relaes. Por fim, um subsistema de servio de desenho contm
apenas classes de desenho e relaes.
CAPTULO 9 - UML ASPECTOS AVANADOS 267


Implementao
Um modelo de implementao (implementation model) um modelo
cujo subsistema de mais alto nvel do esteretipo implementation
system. Um sistema de implementao contm subsistemas de imple-
mentao (de esteretipo implementation subsystem) e/ou compo-
nentes e respectivas relaes. Um subsistema de implementao com-
tm outros subsistemas de implementao, componentes e relaes.
Esteretipos de Classe
Definem-se trs esteretipos para as classes de anlise: entity,
boundary e control (ver Figura 9.7). No Captulo 11 (Seco 11.5.3)
efectuada uma discusso mais detalhada da aplicao destes este-
retipos.
Para as classes de desenho no so definidos quaisquer esteretipos
particulares.
Entidade (entity)
Uma entidade (entity) uma classe passiva, no sentido que os seus
objectos no iniciam interaces por si prprios. Este tipo de objectos
participa em diferentes realizaes de casos de utilizao e geralmente
persiste para alm das interaces em que participa (i.e., so objectos
persistentes).

Figura 9.7: Exemplos de esteretipos de classes do perfil de Processos
de Desenvolvimento de Software.
268 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Controlo (control)
Um controlo (control) uma classe cujos objectos controlam as
interaces entre coleces de objectos. Geralmente este tipo de
classes tem um comportamento especfico para determinado caso de
utilizao e normalmente as suas instncias no persistem para alm
das interaces em que participam (i.e., so objectos no persistentes).
Fronteira (boundary)
Uma fronteira ou interface (boundary) uma classe que se encontra
na fronteira de um sistema, contudo, ainda dentro dele. A respon-
sabilidade destes objectos mediar a comunicao entre os actores
externos do sistema e os outros objectos internos ao sistema.
Esteretipos de Associao
So apenas definidos neste perfil UML dois esteretipos particulares
para associaes entre classes: communicate e subscribe.
Comunicao (communicate)
A comunicao (communicate) uma associao entre actores e
casos de utilizao, que traduz o envio de mensagens do actor para o
caso de utilizao e/ou vice-versa. Pode tambm ser usada entre as
classes de interface, controlo e entidade, e entre actores e classes de
interface. Se for relevante, pode-se explicitar a direco da
comunicao atravs de um adorno de navegabilidade (por omisso,
assume-se comunicao bidireccional).
Subscrio (subscribe)
A subscrio (subscribe) uma associao entre duas classes-
estado, cujos objectos da classe subscritora so notificados quando um
determinado evento ocorre nos objectos da classe destino (designada
por classe publicadora). A associao inclui a especificao do conjun-
to de eventos, cuja ocorrncia implica que o subscritor seja notificado.
CAPTULO 9 - UML ASPECTOS AVANADOS 269


9.4.2 Perfil para Modelao de Negcios
O perfil Modelao de Negcios consiste na definio de um conjunto
de esteretipos (no foram definidos quaisquer marcas com valor ou
restries) e ilustra as capacidades do UML para modelar no apenas
sistemas de software, mas outras realidades, neste caso o mundo das
organizaes.
A Tabela 9.2 resume os principais esteretipos definidos neste perfil
UML, destacando-se entre outros, os conceitos de unidade da organiza-
o (organization unit), unidade trabalho (work unit), trabalhador
(worker) e entidade (entity).

Classe do Metamodelo Nome do Esteretipo
Model use-case model
Package use-case system
Package use-case package
Model object model
Subsystem object system
Subsystem organization unit
Subsystem work unit
Class worker
Class case worker
Class internal worker
Class entity
Collaboration use-case realization
Association communicate
Association Subscribe
Tabela 9.2: Resumo dos esteretipos definidos no perfil Modelao de
Negcios.
No contexto deste perfil, um trabalhador (worker) actua dentro de um
determinado negcio, participa em casos de utilizao e interactua com
270 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

outros trabalhadores e entidades (entity). Os trabalhadores internos
(internal worker) interagem com outros trabalhadores dentro do
negcio, enquanto que os trabalhadores de interface (case worker)
interagem com os actores externos ao sistema.
Os objectos interagem segundo dois tipos de associaes: de
comunicao (communicate) e de subscrio (subscribe), segundo
o modelo de subscrio/publicao.
Um conjunto de entidades agregadas de forma combinada constitui uma
unidade de trabalho (work unit). Por fim, um conjunto de unidades de
trabalho, de classes e de associaes agregadas de forma combinada
constitui uma unidade organizacional (organization unit) de suporte
ao negcio.

Figura 9.8: Exemplos de esteretipos de classes do perfil de modelao
de negcios.
A Figura 9.8 ilustra a representao grfica de alguns dos esteretipos
definidos no perfil de modelao de negcios.
CAPTULO 9 - UML ASPECTOS AVANADOS 271


9.4.3 Perfil para Modelao de Aplicaes Web
Jim Conallen, no seu livro Building Web Applications with UML
[Conallen00], prope um processo de modelao de aplicaes Web
baseado em UML.
Aplicaes Web so aplicaes baseadas em diversos modelos
computacionais (e.g., computao no cliente, computao no servidor,
computao distribuda entre cliente e servidor) e tecnologias (e.g.,
HTTP, HTML, frames, ncoras, linguagens de scripting, DOM, XML,
Java/Beans, ActiveX/COM, objectos distribudos) que esto na base da
generalidade dos actuais sistemas de informao das organizaes em
todo o mundo.
Conollen prope um nmero significativo de extenses ao UML,
designado no seu conjunto como WAE (Web Application Extension),
designadamente os seguintes esteretipos, derivados a partir de:
Metaclasses Class: Server Page, Client Page, Form, Frameset,
Target, JavaScript Object, ClientScript Object.
Metaclasses Association: Link, Targeted Link, Frame Content,
Submit. Builds, Redirect, IIOP, RMI.
Metaclasses Attribute: Input Element, Select Element, Text Area
Element.
Metaclasses Component: Web Page, ASP Page, JSP Page, Servlet,
Script Library.
O processo de desenvolvimento deste tipo de aplicaes clssico nas
fases de especificao de requisitos e de anlise, mas inovador na
fase de desenho. nesta fase que aplicado o WAE de forma
adequada. Apresenta-se de seguida, a ttulo de exemplo, a definio do
esteretipo Client Page e do esteretipo Link [Conallen00].
Client Page (Pgina Cliente)
Classe base
Class
Descrio Uma instncia de uma client page uma pgina
Web formatada em HTML, sendo uma
combinao entre dados, apresentao e mesmo
lgica. Estes elementos so apresentados pelos
browsers Web e podem conter scripts que sero
interpretados pelos mesmos. As funes destes
272 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

interpretados pelos mesmos. As funes destes
elementos correspondem s funes definidas nas
suas tags de script. Os atributos destes elementos
correspondem s variveis declaradas nas suas
tags de script, acessveis por qualquer funo da
pgina (page scope). As pginas cliente podem ter
associaes com outras pginas cliente ou
pginas servidor.
cone

Restries Nenhuma
Marcas com valor TitleTag: O ttulo da pgina.
BaseTag: O URL base para resoluo de
endereos de URL relativos.
BodyTag: O conjunto de atributos definidos na tag
<body>, os quais definem os atributos do texto por
omisso e de cores.
Link (Ligao)
Classe base
Association
Descrio Uma ligao (link) uma referncia de uma pgina
cliente para outra pgina (page). Num diagrama de
classes, uma ligao uma associao entre uma
client page e outra client page ou server page.
Uma ligao corresponde directamente tag ncora
(i.e., <a>) do HTML.
cone Nenhum
Restries Nenhuma
Marcas com valor Parameters: Uma lista de nomes de parmetros
que devero ser no pedido para a pgina ligada.

Note-se, como anteriormente referido, que a definio de um
esteretipo envolve a especificao da sua classe base (definido no
metamodelo), uma descrio informal, e eventualmente de um cone, e
de restries e marcas com valor correspondentes.
CAPTULO 9 - UML ASPECTOS AVANADOS 273


9.5 Sistemas de Componentes e Reutilizao
9.5.1 Definio de Componente
A noo geral de componente corresponde a uma entidade que possa
ser reutilizada. Assim um componente no se limita apenas e neces-
sariamente viso arquitectural ao nvel de implementao (e.g.,
segundo as especificaes Java Beans, Active-X, ou CORBA) por que
geralmente designado e reconhecido, mas tambm, por exemplo, por
um conjunto de classes C++ (nvel implementao)
um conjunto de casos de utilizao (nvel de especificao de re-
quisitos)
um conjunto de diagramas de classes (nvel de anlise ou de de-
senho)
desde que tenham sido definidos de forma a serem reutilizveis.
9.5.2 Famlias de Aplicaes
Devem ser reconhecidas famlias de aplicaes e definidas arqui-
tecturas de sistemas de componentes especificamente desenhadas e
implementadas para suportar essas respectivas famlias.

Figura 9.9: Um framework suportando o desenvolvimento de uma
famlia de aplicaes.
274 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

A Figura 9.9 ilustra um exemplo de uma aplicao (de esteretipo
system) que (re)utiliza os componentes de um determinado sistema
de componentes (de esteretipo framework) atravs de um pacote de
interface, conhecido genericamente por fachada (de esteretipo faca-
de).
Uma fachada permite esconder os detalhes de concepo e imple-
mentao de um determinado sistema de componentes, oferecendo
uma interface mais coerente e mais simples de usar (importar) pelas
aplicaes especficas.
9.5.3 Sistemas de Componentes
Distinguem-se dois tipos principais de sistemas de componentes: tool-
kits e frameworks.
Um toolkit (biblioteca de componentes) consiste num conjunto bem
definido, integrado e reutilizvel de tipos que providenciam
funcionalidades de propsitos gerais. Um conjunto de classes
reutilizveis que permite, por exemplo, a gesto de listas, pilhas, tabelas
de hash um toolkit. O JGL, Generic Collection Library for Java (ver
mais informao em www.objectspace.com), um exemplo de um
toolkit para o sistema Java ao providenciar um conjunto de tipos
reutilizveis tais como: contentores (e.g., queue, map, set, array);
algoritmos genricos (e.g., ordenao, filtro); objectos-funes; e
iteradores. As bibliotecas de I/O ou STL (Standard Template Library)
[Plauger96] para C++ so outros exemplos. Os toolkits no impem um
desenho particular das aplicaes; eles apenas providenciam
funcionalidades genricas que as aplicaes podem utilizar, sendo
portanto, que o seu foco consiste na reutilizao de cdigo. O toolkit o
equivalente OO s bibliotecas de sub-rotinas da programao estrutura-
da.
Um framework (infra-estrutura) software um conjunto de classes
cooperantes que providencia funcionalidades comuns e reutilizveis
para um determinada famlia de (sistemas de) aplicaes. Uma infra-
estrutura providencia mecanismos para criao de aplicaes parti-
culares a partir da especializao de aplicaes reutilizveis e semi-
completas. Exemplos de infra-estruturas so, entre outras:
CAPTULO 9 - UML ASPECTOS AVANADOS 275


MFC (Microsoft Foundation Classes) da Microsoft, para
desenvolvimento de aplicaes para MS-Windows.
Infra-estruturas de middleware, tais como o RMI da Sun, o DCOM
da Microsoft, OrbixWeb da Iona, ou a VisiBroker da Inprise.
Infra-estruturas aplicacionais, tais como os sistemas de gesto
empresarial conhecidos como ERP (entreprise resource planning)
de empresas como a SAP, Oracle, ou PeopleSoft.
Uma infra-estrutura de software define a arquitectura de um aplicao,
ou seja, define a estrutura e organizao global da aplicao, define
como as classes e objectos podem colaborar, e define os prprios
fluxos de execuo possveis. Uma infra-estrutura predefine os prin-
cipais parmetros do desenho de uma aplicao, deixando apenas para
o desenhador/programador de uma aplicao as tarefas exclusivamente
especficas da aplicao. Desta forma a nfase de uma infra-estrutura
consiste na reutilizao do desenho (de famlias de aplicaes).
A reutilizao nestes sistemas apresenta tipicamente uma inverso de
controlo entre a aplicao especfica e a infra-estrutura sobre a qual
aquela se baseia. Numa aplicao normal (i.e., sem ser suportada por
uma infra-estrutura) o programador define explicitamente o corpo do
programa principal, invocando a partir deste as rotinas, ou mtodos de
objectos, que pretende (re)usar. Por outro lado, nas aplicaes supor-
tadas em infra-estruturas, o programador reutiliza o corpo principal (i.e.,
a estrutura e comportamento), previamente definido, apenas desem-
volvendo o cdigo especfico que o outro invoca transparentemente.
Os tipos exportados ou visveis por uma infra-estrutura encontram-se
organizados em um ou mais pacotes, ou interfaces, designados por
fachadas. Alguns desses tipos correspondem a classes abstractas que
devero ser redefinidas e/ou implementadas numa determinada
(instncia de) aplicao, enquanto que outros tipos correspondem a
classes concretas, com mtodos finais, associadas a operaes
predefinidas, mas tambm com mtodos que devero/podero ser
redefinidos de forma que se possa adaptar os processos de negcio a
cada aplicao em particular. Estes ltimos mtodos so desenca-
deados/invocados em determinado ponto da execuo da aplicao
276 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

transparentemente ao programador da aplicao, e so geralmente
conhecidos por mtodos invertidos (callbacks).
As aplicaes concebidas e desenvolvidas com base em infra-
estruturas so mais rpidas de desenvolver pois o programador
apenas tem de definir o cdigo dos mtodos invertidos necessrios e/ou
especializar classes abstractas ; e apresentam estruturas semelhantes
entre aplicaes da mesma famlia, o que permite (1) uma mais fcil
manuteno; e (2) uma mais fcil utilizao por parte dos seus
utilizadores. Por outro lado, o programador perde a viso do todo,
perde alguma liberdade criativa j que um nmero significativo de
decises de desenho j foram previamente realizadas.
9.5.4 Reutilizao
A reutilizao no processo de desenvolvimento de software deve ser um
objectivo em qualquer das fases envolvidas, comeando desde logo,
pela especificao de requisitos, at fase de testes, passando pela
fase de desenvolvimento, desenho e anlise.
Introduz-se de seguida algumas noes gerais, mas fundamentais para
uma adopo de uma aproximao de reutilizao no processo de
desenvolvimento de software conforme sugerido em [Jacobson97].
Especializao de Componentes
De modo que um sistema de componentes possa ser efectivamente
reutilizvel necessrio que vrias das suas componentes exportadas
apresentem um determinado grau de variabilidade, i.e., que possam
ser de alguma forma extensveis. Diferentes tipos de mecanismos de
variabilidade providenciam distintos modos de especializao de com-
ponentes.
Uma componente importada pode ser abstracta ou concreta.
Componentes concretas podem ser reutilizveis directamente sem
qualquer alterao. Basicamente uma componente concreta para ser
reutilizada basta que seja importada bem como a todas as componentes
que ela utilize. Componentes abstractas so de alguma forma
componentes incompletas ou genricas, que tm de ser especializadas
CAPTULO 9 - UML ASPECTOS AVANADOS 277


antes de poderem ser utilizadas (e.g., supertipos, classes abstractas,
templates com parmetros).
Designa-se por pontos de variao de uma componente s
possibilidades de variabilidade dessa componente. Uma variante uma
concretizao dessa possibilidade. Uma componente abstracta
especializada atravs da afectao de uma ou mais variantes aos seus
pontos de variao. Essa afectao consiste na integrao da determi-
nada variante na componente envolvida, cuja semntica depende do
mecanismo de variabilidade especfico. O conceito de ponto de
extenso, referido no Captulo 5 a propsito da relao de extenso
entre casos de utilizao, um possvel exemplo do conceito de ponto
de variao.
Mecanismos de Variabilidade
Componentes abstractas so especificadas atravs de mecanismos de
variabilidade, de entre os quais se destacam:
Herana: Permite a criao de tipos por especializao de outros
tipos (mais) abstractos nos seus pontos de variao. Um mtodo
virtual pode ser entendido como um ponto de variao que pode ser
especializado atravs de herana.
Parametrizao: o mecanismo tpico usado para concretizao de
templates e de macros.
Linguagens de configurao: Este mecanismo usado para, de
forma declarativa ou procedimental, se definirem relaes entre
componentes e respectivas variantes em configuraes completas
ou finais.
Gerao automtica: Mecanismo de construo de componentes e
suas relaes a partir de representaes de alto nvel definidas em
templates ou linguagens especficas (e.g., wizards, builders, gera-
dores de ecrs a partir de scripts).
Extenses e pontos de extenso: Mecanismo usado em compo-
nentes de casos de utilizao e em componentes de objectos, que
consiste na associao de variantes (extenses) a pontos de
variao (pontos de extenso).
278 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Note-se que estes mecanismos de variabilidade no so exclusivos
entre si. Pelo contrrio, normal a utilizao de vrios mecanismos em
conjunto. Em [Jacobson97] proposta com detalhe uma abordagem de
reutilizao de software, ao longo das diferentes fases do seu ciclo de
vida, baseada principalmente nos mecanismos de variabilidade aqui
referidos, que agregam de facto a generalidade dos mecanismos co-
nhecidos.
9.6 Tipos Parametrizveis
A noo de tipos parametrizveis surgiu nalgumas linguagens de
programao como um mecanismo complexo para reutilizao de
cdigo. Por exemplo, esta noo designada (e concretizada) em C++,
por templates [Ellis90]; em Ada, por generics [DoD80]; ou em ML, por
funes e tipos de dados polimrficos [Ullman94].
A noo de tipo parametrizvel usada para permitir que um conceito
geral seja instanciado por um ou mais tipos especficos. Por exemplo,
pode-se definir um pacote ou uma classe para implementar um tipo de
lista genrica, e instanci-lo depois de forma a produzir-se listas de
inteiros, listas de imagens, listas de registos de base de dados, etc.
Este mecanismo particularmente til no desenho e implementao de
toolkits e frameworks reutilizveis. Por exemplo, a biblioteca STL
(Standard Template Library) [Plauger96] usa templates C++ extensiva-
mente.
O UML permite o desenho de tipos parametrizveis. Em particular,
qualquer classifier pode ser parametrizvel, ou seja, pode-se ter
classes, interfaces, componentes, ns (...) parametrizveis. Pode-se
ainda parametrizar um grupo de classifiers que colaborarem entre si.
Apresentamos nesta seco, a ttulo de exemplo, classes parametri-
zveis e colaboraes parametrizveis (normalmente conhecidas por
padres de desenho).
9.6.1 Classes Parametrizveis
A Figura 9.10 ilustra a representao UML de uma classe Classe
parametrizvel com os parmetros T1, T2, Tn no definidos. Ilustra
CAPTULO 9 - UML ASPECTOS AVANADOS 279


ainda um esboo da classe Vector com o correspondente cdigo em
C++.
Podem-se conceber inmeras aplicaes de classes parametrizveis.
Uma aplicao tpica a definio de estruturas de dados genricas, do
tipo contentores, tais como listas, vectores, pilhas, ou hashtables; outra
aplicao a dos algoritmos genricos do tipo iteradores, algoritmos de
cpia, contagem, procura, filtro, ordenao, etc.

Figura 9.10: Representao UML de uma classe parametrizvel.
A Figura 9.11 ilustra a classe parametrizvel Vector com o parmetro
formal T. Para cada classe C, a classe Vector<C> uma classe de
vectores de objectos do tipo C, determinada pela instanciao da classe
Vector com a classe actual C no lugar do parmetro formal T. Essa
instanciao representada em UML por uma relao (de dependncia)
de esteretipo bind.
As classes VectorInteger e VectorImage so criadas a partir da
classe Vector pela substituio do parmetro formal T por,
respectivamente, os tipos Integer e Image. Notem-se nas duas
formas equivalentes de se definirem classes a partir de uma classe
parametrizvel. Por exemplo, as classes VectorInteger e
Vector<Integer> so equivalentes, sendo a primeira definida por
ligao explcita e a segunda por ligao implcita.
280 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE


Figura 9.11: Exemplo da classe parametrizvel Vector<T>.
9.6.2 Padres de Desenho
Um padro descreve um problema que ocorre inmeras vezes em
determinado contexto, e descreve ainda a soluo para esse problema,
de modo que essa soluo possa ser utilizada sistematicamente em
distintas situaes [Alexander77]. Embora Alexander se referisse a
padres no mbito da engenharia civil, esse conceito foi adoptado para
a engenharia informtica, particularmente em padres baseados em
objectos e interfaces.
Um padro de desenho a adaptao do conceito de padro,
proposto por Alexander, particularmente usado na fase de desenho
segundo as abordagens orientadas por objectos. Ou seja, em que os
padres baseiam-se em objectos e interfaces. Um padro de desenho
pode ser especificado atravs de quatro elementos essenciais [Gamma-
94]: (1) um nome, que permite facilmente a sua identificao e refern-
cia; (2) a descrio do problema a que o padro dever ser aplicado; (3)
a soluo, que consiste no desenho dos elementos constituintes e
respectivas relaes, responsabilidades, e colaboraes; e (4) as
consequncias da aplicao do padro, designadamente a identificao
das vantagens e desvantagens envolvidas.
CAPTULO 9 - UML ASPECTOS AVANADOS 281


Os padres de desenho aplicados ao desenvolvimento de software
apresentam inmeras vantagens, de entre as quais se destaca a
identificao de solues bem definidas para classes de problemas
semelhantes, assim como, o facto de permitir a definio de construto-
res de desenho com um nvel semntico elevado e facilmente reconhe-
cidos por uma comunidade alargada de utilizadores.
De forma a esclarecer sucintamente o que so padres de desenho e
como so representados em UML introduz-se o padro de desenho
COMPOSTO (Composite), descrito no clebre livro do GoF (Gang of Four)
[Gamma94].
O padro de desenho COMPOSTO usado para providenciar um acesso
uniforme a estruturas de objectos compostas, permitindo que os seus
clientes tratem da mesma forma quer objectos individuais quer objectos
compostos.
Para motivao deste padro, considere-se a construo de aplicaes
grficas (e.g., editores grficos) em que os utilizadores podem construir
desenhos complexos a partir de componentes relativamente simples.
Um utilizador pode agrupar componentes em componentes maiores, e
estes, por sua vez, podem ser agrupados para constituir componentes
ainda maiores. Uma aproximao simples para implementar este tipo de
situaes poderia consistir na definio de classes para primitivas
grficas do tipo Texto ou Linha, e de outras classes que funcionariam
como contentores dessas classes primitivas. Contudo, esta
aproximao apresenta o seguinte problema: o cdigo que manipula
essas classes tem de tratar de forma diferente elementos primitivos e
elementos contentores, mesmo que os seus utilizadores os tratem de
forma indistinta. A distino entre estes dois tipos de elementos torna a
aplicao mais complexa e difcil de manter. O padro COMPOSTO
descreve como usar a composio de forma recursiva de modo que os
(objectos) clientes no tenham que fazer qualquer distino entre
elementos primitivos e compostos.
A chave do padro COMPOSTO uma classe abstracta que representa
quer elementos primitivos quer elementos compostos. A Figura 9.12
ilustra o diagrama de classes correspondendo aplicao deste padro
282 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

ao exemplo sugerido, em que a classe abstracta Graphic com
operaes comuns a todos os elementos grficos (e.g., draw()) bem
como operaes comuns a todos os elementos compostos, tais como
operaes para acesso e gesto aos seus filhos (e.g., add(),
remove(), getChild()).

Figura 9.12: Aplicao do padro COMPOSTO no contexto de editores
grficos.
A Figura 9.13 apresenta o diagrama de classes correspondente
estrutura (genrica) do padro COMPOSTO.

Figura 9.13: Estrutura genrica do padro COMPOSTO.
Note-se que o padro pressupe uma colaborao definida entre os
seguintes tipos de objectos (designados como participantes da colabo-
rao):
CAPTULO 9 - UML ASPECTOS AVANADOS 283


Componente: declara a interface para os objectos primitivos e
compostos, seus descendentes; pode eventualmente implementar
comportamento por omisso para algumas das operaes (e.g.,
Graphic).
ElementoPrimitivo: representa os elementos primitivos da
composio; define o comportamento para os elementos primitivos
(e.g., Text, Line, Rectangule).
ElementoComposto: representa os elementos compostos; define o
comportamento para os elementos compostos (e.g., Picture).
Cliente: acede e manipula a composio de objectos atravs da
interface de Componente.
Uma colaborao representada em UML conforme ilustrado nas
Figura 9.14 e 9.15, em que o nome da colaborao apresentado numa
oval com linha a tracejado, e so evidenciados os seus participantes
atravs de relaes de dependncia, devidamente qualificadas com (o
nome do) papel desempenhado.

Figura 9.14: Diagrama de classes e colaborao relativa ao contexto de
editores grficos.
A Figura 9.15 ilustra o real interesse dos padres de desenho por
permitir aplicar a mesma soluo, a problemas similares que se mani-
festam em diferentes contextos ou domnios de aplicao.
284 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE


Figura 9.15: Diagrama de classes e colaborao relativa ao contexto de
ferramentas CASE.
Neste caso, consideramos uma aplicao (e.g., qualquer das
ferramentas CASE que so abordadas na Parte 4 do livro) que manipula
extensivamente elementos de modelao, alguns dos quais primitivos
(e.g., classes, interfaces, ns) e outros compostos (e.g., diagramas de
classes, diagramas de componentes). Atente-se que o problema ,
salvaguardando os detalhes especficos e o contexto de aplicao,
semelhante ao descrito anteriormente, pelo que tem sentido a aplicao
do padro COMPOSTO. O aspecto crucial, a identificao da classe
abstracta que desempenha o papel de componente e das suas
operaes envolvidas, todos os restantes detalhes estruturais, com-
portamentais e consequncias esto j especificados no padro de
desenho.
9.7 XMI XML Metadata Interchange
O XMI (XML Metadata Interchange) o standard da OMG para
interoperao de metadata [OMG98]. O XMI foi aplicado inicialmente na
metadata de modelao (i.e., de modelos de UML) e de programao,
mas est tambm em curso uma iniciativa para modelar outros
domnios de aplicao e de tecnologia tais como datawarehousing e
componentes.
No respeitante modelao, o XMI especifica uma estrutura de
representao de modelos UML conforme o metamodelo UML. O
CAPTULO 9 - UML ASPECTOS AVANADOS 285


principal objectivo do XMI permitir a interoperao e utilizao dos
modelos UML de forma independente das plataformas, linguagens,
repositrios e ferramentas CASE.
O XMI definido segundo um extenso documento DTD XML, de 121
pginas. que permite que os modelos sejam representados num formato
ASCII, facilmente trocados entre diferentes aplicaes e eventualmente
legveis por indivduos tcnicos.

Figura 9.15: Exemplo de um modelo UML representado em XMI.
A Figura 9.15 ilustra, a ttulo de exemplo, um modelo UML constitudo
pela classe Cliente definida no pacote Negcio, e a sua respectiva
representao em XMI.
9.8 Concluso
Neste captulo apresentou-se sucintamente alguns aspectos pouco
conhecidos do UML, nomeadamente: (1) a organizao e descrio do
prprio UML segundo uma arquitectura a quatro camadas; (2) os
mecanismos de extenso do UML e o conceito de perfil UML; (3)
noes gerais sobre os conceitos de componente, sistemas de
componentes e reutilizao; (4) tipos parametrizveis em UML, em
particular classes parametrizveis e colaboraes parametrizveis no
contexto de padres de desenho; e (5) a motivao e contexto prtico
do XMI enquanto standard para interoperao de modelos UML. Para
286 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

alm destes aspectos, existem outros que propositadamente no foram
tratados neste livro de forma a no estender significativamente o
componente da linguagem UML. Enumeram-se, no entanto, alguns
desses aspectos avanados que permitem aumentar ainda mais a
flexibilidade e potencialidade do UML, designadamente:
Linguagem OCL (Object Constraint Language).
Classes de funes utilitrias (utility classes).
Diagramas de colaborao (particularmente, diagramas de
sequncia) com mltiplos cenrios.
Mapeamento de diagramas de classes em diagramas/esquemas de
dados, para definio de bases de dados (ver, a este respeito, as
Seces 13.X e 14.Y).
Mecanismos de definio de esteretipos [Berner99].
A especificao MOF (Meta Object Facility), promovida pela OMG,
para definio, manipulao e troca de modelos e meta-modelos em
contextos abertos.
A perspectiva de casos de utilizao proposta por Alistair Cockburn
[Cockburn00].
Acima de tudo, conclui-se neste captulo a apresentao e discusso do
UML enquanto linguagem agregadora/unificadora (com uma sintaxe e
semntica consistente) de vrias notaes existentes anteriormente
nesta rea da engenharia.
A apresentao desta parte (Parte 2) seguiu propositadamente uma
abordagem didctica e independente de quaisquer processos ou
metodologias de desenvolvimento de software. Ver-se- nos dois
prximos captulos (Parte 3) como aplicar as diferentes notaes UML
tendo em conta os prprios processos de desenvolvimento de software.
CAPTULO 9 - UML ASPECTOS AVANADOS 287


9.9 Exerccios
Ex.64. Tendo em conta a arquitectura a quatro camadas do UML, diga
a que camada pertence cada um dos seguintes elementos: (i)
Class; (ii) MetaClass; (iii) myServlet002; (iv) MyServlet.
Ex.65. O que um Classifier? Um caso de utilizador um
classificador?
Ex.66. Um esteretipo pode estender um elemento do tipo associao?
D um exemplo e justifique a sua resposta.
Ex.67. O que so e para que servem os perfis UML?
Ex.68. O que a classe base de um esteretipo? Qual a classe base
do esteretipo entity, definido no perfil UML para processos de
desenvolvimento de software?
Ex.69. Considere o padro de desenho COMPOSTO descrito na Seco
9.6.2; aplique-o para modelar a estrutura de elementos
compostos e primitivos de um documento XML.
Ex.70. O que o XMI? Explique a motivao do seu aparecimento.
288 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE



Parte 3
Metodologias de
Desenvolvimento de
Software
O que um ritual? perguntou o
Principezinho.
Tambm uma coisa que toda a gente se
esqueceu respondeu a raposa. o que
faz com que um dia seja diferente dos
outros dias e uma hora, diferente das outras
horas. Os meus caadores, por exemplo,
tm um ritual. quinta-feira, vo ao baile
com as raparigas da aldeia. Assim a quinta-
feira um dia maravilhoso. Eu posso ir
passear para as vinhas. Se os caadores
fossem para o baile num dia qualquer, os
dias eram todos iguais uns aos outros e eu
nunca tinha frias.
Antoine de Saint-Exupry, O Principezinho.
290 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

A Necessidade de uma Metodologia
A Parte 3 marca o retomar do livro na anlise dos conceitos mais
abrangentes da engenharia de software. Depois de termos apresentado
a linguagem UML, descrita ao longo da Parte 2, colocam-se
naturalmente, entre outras, as seguintes questes: Como que usamos
o UML para modelar sistemas de software? Quando que devemos
usar os diagramas de interaco, ou de actividades, ou de
componentes? Em que fase? Com que nvel de detalhe? Que relao
existe entre diagramas de casos de utilizao e diagramas de
interaco? Para auxiliar esta reflexo, considere-se que pedamos ao
leitor para modelar adequadamente, usando o UML, os casos de estudo
apresentados nas Seces 10.8 e 11.4. O leitor, por certo se sentiria
desconfortvel com este pedido. Porqu? Porque no sabe ainda que
passos deve seguir, que tipos de diagramas deve usar em cada passo,
como relacion-los, etc. Ou seja porque precisa conhecer e aplicar uma
determinada metodologia que o ajude no processo de desenvolvimento
(ou simplesmente de modelao) de software.
O que uma Metodologia?
Tal como discutido no Captulo 2, o processo de desenvolvimento de
software consiste genericamente num conjunto de fases, tarefas e
actividades, realizadas por intervenientes que desempenham vrias
funes de modo a elaborarem diversos artefactos e que conjuntamente
contribuem para a produo de um sistema de software. A metodologia
adiciona a este conceito a noo de tcnicas, notaes e utilizao de
ferramentas.
O processo de desenvolvimento de software um acto complexo, com
mltiplas variveis e inmeras vezes com qualidade reduzida,
ultrapassando os prazos e os oramentos previstos. No h receitas
milagrosas, por isso um processo deve ser adaptado e configurado
conforme o perfil das empresas, dos projectos e dos intervenientes
envolvidos. No acreditamos na produo de software em massa e
automatizada; e ser sempre uma combinao entre engenharia e
arte.


Nesta terceira parte do livro, aprofundamos a problemtica das
metodologias de desenvolvimento de software atravs da anlise e
discusso de duas propostas concretas que adoptam o UML como
linguagem de modelao: o RUP e o ICONIX. De referir que os autores
destas propostas classificam-nas como processos e no como
metodologias, mas remetemos o leitor para o Captulo 2 para
esclarecimentos sobre este assunto.
Organizao da Parte 3
O Captulo 10, Metodologia RUP, apresenta o Rational Unified
Process, uma metodologia completa aplicada ao desenvolvimento de
software. Encontra-se fortemente integrado com o UML, ou no tivesse
resultado da continuao dos esforos dos mesmos autores. O RUP
segue um modelo iterativo e incremental, centrado numa arquitectura e
conduzido por casos de utilizao. uma metodologia que se baseia no
paradigma da orientao por objectos, e a abrangncia das suas
propostas contempla a possibilidade de adaptao realidade de cada
projecto ou organizao.
Neste captulo, apresenta-se uma panormica geral do RUP, em
particular as suas diferentes vises: a viso dinmica (baseada em
ciclos, fases e iteraes) e a viso esttica (baseada em workflows,
actividades e artefactos). Por fim, discute-se o RUP atravs da sua
aplicao a um caso prtico, de dimenso e complexidade no trivial.
O Captulo 11, Metodologia ICONIX, apresenta a metodologia ICONIX,
para desenvolvimento de software segundo uma abordagem muito
prtica, algures entre a complexidade e abrangncia do RUP e a
simplicidade e o pragmatismo do Extreme Programming. O ICONIX
conduzido por casos de utilizao, iterativo e incremental, tal como o
RUP, mas sem a complexidade que este preconiza. Por outro lado,
relativamente pequeno e simples, tal como o XP, mas sem eliminar as
tarefas de anlise e de desenho que aquele no contempla. Discute-se
o ICONIX atravs da sua aplicao na modelao do caso de estudo
WebDEI, o qual consiste num sistema de informao Web a quatro
camadas, desenvolvido exclusivamente com tecnologia Java.
292 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE




Captulo 10 - METODOLOGIA RUP
Tpicos
Introduo
Enquadramento
Caractersticas Principais
As 4+1 Vises
Viso Geral
Ciclos, Fases e Iteraes - A Componente Dinmica
Workflows, Actividades e Artefactos A Componente Esttica
Enunciado do Caso de Estudo DGD
Resoluo do Caso de Estudo DGD
Concluso
Exerccios
10.1 Introduo
Durante a dcada de 90, tornou-se bvia para muitos tericos da
engenharia de software a vantagem do paradigma da orientao por
objectos e, nesse sentido, comearam a proliferar as metodologias que
tinham por base os respectivos conceitos. O exagerado nmero de
metodologias que entretanto foram propostas fez recordar a experincia
negativa que j tinha ocorrido com as metodologias estruturadas, pelo
que ganhou fora a ideia da criao de uma metodologia de
desenvolvimento de software unificada, que tirasse partido da experi-
ncia e dos conceitos da linguagem UML. Assim, a ideia de uma meto-
294 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

dologia e processo unificados foram mais uma consequncia natural da
aproximao dos trs amigos e que j tinha conduzido definio do
UML.
Baseado na noo de metodologia unificada existem actualmente vrias
propostas de metodologias de desenvolvimento de software, umas mais
tericas, abrangentes e completas, como o caso do USDP (Unified
Software Development Process) [Jacobson99] e o RUP (Rational
Unified Process) [Kruchten00]; outras mais prticas e simples como o
caso do ICONIX [Rosenberg99] ou do GRASP [Larman98].
A forte integrao com o UML notria ao longo de todo o processo,
mas importa referir que o UML e o RUP tm mbitos de interveno
distintos: o UML uma linguagem de notao e de modelao,
enquanto que o RUP uma metodologia de desenvolvimento completa.
A analogia fornecida por Philippe Kruchten [Kruchten00] permite
esclarecer melhor a importncia do RUP: o UML funciona como um
conjunto de palavras e de regras que definem a forma como devem ser
combinadas para formar frases. No entanto, se quisermos escrever um
livro, necessrio outro tipo de regras, nomeadamente relativas
formatao de captulos, criao de um ndice, identificao de
palavras chave e pesquisa de bibliografia. esta a funo que o RUP
representa.
O RUP uma metodologia (se bem que os seus autores a designem
como processo veja-se a Seco 2.2 para mais esclarecimentos) de
engenharia de software desenvolvida e comercializada pela empresa
Rational Software. Tendo em conta que a construo de software de
qualidade de uma forma repetitiva e previsvel difcil, e que as causas
dos problemas associados a este tipo de desenvolvimento tm sido uma
constante ao longo do tempo, o RUP prope vrias boas prticas
(referidas na Seco 2.4) para o desenvolvimento de software e aplica-
as de forma integrada.
O RUP mais do que uma "simples" metodologia de desenvolvimento
de software, uma vez que pode funcionar como um conjunto de
princpios genricos utilizado para instanciar e configurar vrias
metodologias concretas, conforme o tipo de organizao, o domnio de
aplicao, o nvel de competncias, etc.
CAPTULO 10 METODOLOGIA RUP 295


O RUP, enquanto produto, apresentado resumidamente no livro The
Rational Unified Process An Introduction [Kruchten00] e de forma
detalhada numa knowlegde base disponvel online
(www.rational.com/products/rup/index.jsp) ou em CD-ROM, ambos
comercializados pela Rational. O produto RUP encontra-se integrado
com ferramentas da mesma empresa que se destinam a suportar outras
actividades do processo de desenvolvimento, tais como gesto de
requisitos (RequisitePro), controle das alteraes (ClearQuest), modela-
o do sistema (Rose). Como qualquer outro produto de software, so
produzidas frequentemente novas verses de forma a acompanhar a
evoluo do mercado.
Na Figura 10.1 podemos observar o aspecto da interface do produto
RUP, que apresenta semelhanas com o Microsoft Explorer, o que
compreensvel: uma vez que se trata de uma ferramenta que disponi-
biliza uma quantidade de informao elevada, as suas funcionalidades
devero estar optimizadas para facilitar a pesquisa dessa mesma infor-
mao.


Figura 10.1: Aspecto grfico do RUP.
296 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Para alm da sua verso base, encontram-se disponveis variantes j
adaptadas para situaes concretas do desenvolvimento de software;
por exemplo, para pequenos projectos ou projectos na rea do negcio
electrnico. So tambm includos templates para ligao a outras
ferramentas da Rational ou de outros fabricantes, de modo a facilitar a
produo dos artefactos do RUP.
Este captulo descreve o RUP enquanto metodologia de desenvolvi-
mento. Contudo, dada a sua complexidade e dimenso, so
apresentadas as ideias principais de forma resumida e so demonstra-
dos alguns aspectos concretos da sua aplicao, atravs de um caso
prtico, concentrando a anlise nas actividades realizadas. Aborda-se
superficialmente a documentao e modelos produzidos, j referidos
extensamente noutros captulos, que por isso no so aqui apresen-
tados.
10.2 Enquadramento
O RUP, apesar de existir h muito pouco tempo (mais concretamente
desde 1998), tem na sua origem ideias e experincias que remontam h
mais de trinta anos, nomeadamente nas abordagens seguidas na
Ericsson, onde trabalhou Ivar Jacobson. J em 1967 esta empresa
modelava todo o seu sistema em vrios blocos relacionados,
construdos numa estrutura hierrquica, utilizando conceitos muito prxi-
mos do UML [Jacobson85]. No entanto, as abordagens com maior
influncia directa no RUP surgiram a partir de finais da dcada de 80,
como ilustrado na Figura 10.2.


Figura 10.2 : Evoluo do RUP.
CAPTULO 10 METODOLOGIA RUP 297


Em 1987, Ivar Jacobson deixou a Ericsson e fundou a empresa
Objectory AB, onde at 1995 desenvolveu o Objectory Process, altura
em que esta empresa foi adquirida pela Rational. Para alm de outros
conceitos de anlise e desenho orientado por objectos, foi no contexto
do Objectory Process que pela primeira vez se definiu o conceito casos
de utilizao [Jacobson92].
Pelo seu lado, a Rational vinha desenvolvendo desde 1981, e com
maior nfase a partir do incio da dcada de 90, um conjunto de
iniciativas com o objectivo de conceber um ambiente interactivo que
permitisse aumentar a produtividade do desenvolvimento de sistemas
complexos [Archer86]. As ideias mais significativas tinham a ver com a
necessidade da aplicao de um processo iterativo e a definio de
uma arquitectura baseada em componentes. Estas iniciativas condu-
ziram elaborao da Rational Approach, sendo Philippe Kruchten um
dos seus principais mentores.
A proliferao das metodologias baseadas nos conceitos da orientao
por objectos e de desenvolvimento iterativo tornou bvia a necessidade
de uniformizar as mesmas, o que foi facilitado com a entrada para a
Rational de alguns dos principais "tericos" das metodologias existentes
na altura, nomeadamente a dos "trs amigos" (Grady Booch, James
Rumbaugh e Ivar Jacobson) e a conjugao das ideias das suas
abordagens (Booch Method, Object Modeling Technique e Objectory
respectivamente) com as da Rational.
Esta integrao deu origem ao que na altura se designou por Rational
Objectory Process, cuja designao, a partir de 1998, passou a ser
Rational Unified Process, sobretudo devido ao nmero de contribuies
adicionais que entretanto foram integradas (e que mesmo os principais
autores indicam no saber ao certo quantas e quais foram!). Estas
contribuies abrangem reas to diversas como a gesto de requisitos
(incorporada com a aquisio da empresa Requisite) e o controle de
qualidade (com a aquisio da SQA).
Com a integrao das ideias propostas no UML 1.3 e a incluso de
especificidades de desenvolvimento para as tecnologias Internet, o RUP
evoluiu para a verso 5.5 em 1999, tendo sido disponibilizada durante o
298 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

ano 2000 a verso RUP 2000. Esta a verso do produto (e da
metodologia) que iremos analisar neste captulo.
O RUP hoje em dia utilizado por diversas organizaes, de vrias
indstrias e em projectos de dimenso varivel, com particular destaque
em projectos de negcio electrnico. Segundo [Kruchten00], em finais
de 1999 mais de mil organizaes de grande dimenso tinham j adop-
tado o RUP.
10.3 Caractersticas Principais
O RUP suporta diversas boas prticas do desenvolvimento de software
em particular aquelas que foram identificadas no Captulo 2: (1) uma
metodologia de desenvolvimento de software iterativa; (2) prope a
gesto integrada de requisitos desde a sua identificao at
implementao; (3) prope o desenvolvimento de software baseado em
arquitecturas de software e em componentes; (4) defende a modelao
visual; e (5) o controle de qualidade permanente. Para alm destas
caractersticas, o RUP integra outras ideias fundamentais, nomeada-
mente o facto de ser orientado por casos de utilizao.
CAPTULO 10 METODOLOGIA RUP 299


10.3.1 Metodologia Conduzida por Casos de Utilizao
No Captulo 5 analismos como um sistema pode ser especificado, na
perspectiva dos seus utilizadores, atravs de casos de utilizao, pelo
facto destes diagramas permitirem capturar os requisitos funcionais.

Figura 10:3 : Metodologia Conduzida por Casos de Utilizao.
No caso do RUP, tal como noutras metodologias que recorrem ao UML,
a inovao reside no facto dos casos de utilizao, para alm de
especificarem os requisitos do sistema, conduzirem tambm o seu
prprio desenho, implementao e teste, ou seja, todo o processo de
desenvolvimento. Dito de outra forma, significa que o processo de
desenvolvimento segue um fluxo, em que os casos de utilizao so
especificados, desenhados, implementados, e no fim so a fonte a partir
dos quais os testes so definidos e realizados. A Figura 10.3 ilustra este
facto: todos os modelos construdos ao longo das diversas tarefas do
RUP so elaborados a partir do modelo de casos de utilizao,
produzido durante a tarefa de levantamento de requisitos.
300 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Embora seja verdade que os casos de utilizao conduzem a
metodologia, eles no so seleccionados ao acaso e de forma isolada:
os casos de utilizao baseiam-se na arquitectura do sistema, e a
arquitectura influencia a definio e seleco dos casos de utilizao,
segundo uma aproximao iterativa e incremental.
10.3.2 Metodologia Centrada numa Arquitectura
A funo da arquitectura de software reflectir decises sobre a
organizao do sistema de software, nomeadamente:
Os elementos estruturais (e suas interfaces) que compem o sis-
tema.
O seu comportamento especificado atravs de colaboraes entre
eles.
A composio dos elementos estruturais e de comportamento em
subsistemas progressivamente maiores.
O estilo arquitectural, que guia esta organizao, os elementos e
suas interfaces, as suas colaboraes e a sua composio.
A arquitectura de software decide ainda sobre restries e compromis-
sos relativos a diferentes aspectos do sistema, tais como: utilizao,
funcionalidades, desempenho, tolerncia a alteraes, reutilizao,
compreenso, economia e esttica.
A arquitectura de software representada fisicamente atravs de um
conjunto de vises sobre distintos tipos de modelos, elaborados quer
em funo dos intervenientes e destinatrios, quer do momento em que
so produzidos. Assim, podemos ter a viso do modelo de casos de
utilizao; a viso do modelo de anlise; a viso do modelo de desenho;
a viso do modelo de implementao; e a viso do modelo de instala-
o. Estas diferentes vises evidenciam e apresentam o estilo arquitec-
tural que o sistema dever apresentar.
A arquitectura de software permite implementar os casos de utilizao
requeridos, com uma adequada relao custo-benefcio, tendo em conta
a experincia acumulada (por exemplo, anteriores arquitecturas e
padres arquitecturais) e um conjunto definido de restries conforme
ilustrado na Figura 10.4.
CAPTULO 10 METODOLOGIA RUP 301



Figura 10.4: Os condicionalismos de uma arquitectura de software.
Por outro lado, os casos de utilizao so desenvolvidos com base na
informao fornecida pelos clientes e utilizadores, mas tambm so
fortemente condicionados pela arquitectura subjacente que exista ou
que venha a existir (Figura 10.4).

Figura 10.5: As condicionantes dos casos de utilizao.
10.3.3 Metodologia Iterativa e Incremental
Na Seco 2.6 discutimos as diferenas existentes entre os processos
que implementavam um modelo em cascata e os processos iterativos e
incrementais. As metodologias unificadas sugerem uma aproximao
iterativa e incremental para projectos de mdia a grande dimenso,
reduzindo os de pequena dimenso a apenas uma iterao. A
justificao para esta proposta o facto de um projecto ser mais
facilmente gerido e executado se for dividido em vrias partes ou mini-
projectos, em que cada mini-projecto uma iterao que resulta num
incremento, que dever ser devidamente planeado, controlado e
executado (atravs de anlise, desenho, implementao e testes).
Um aspecto importante a identificao do mbito e do detalhe do
trabalho a ser realizado em cada iterao, o que depende de dois
factores: por um lado, os casos de utilizao seleccionados para cada
iterao; por outro lado, os factores de risco mais importantes que
devero ser analisados e resolvidos o mais cedo possvel.
302 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Por isso, em cada iterao os participantes devem identificar e
especificar os casos de utilizao relevantes; efectuar o desenho com
base numa determinada arquitectura de software; implementar o
desenho atravs de um conjunto de componentes; e verificar se os
componentes esto em conformidade com as especificaes dos casos
de utilizao. Note-se que estas trs caractersticas do RUP
conduzido por casos de utilizao, centrado numa arquitectura e
iterativo e incremental esto eminentemente relacionadas.
10.4 As 4+1 Vises do RUP
Existem diferentes perspectivas segundo as quais o processo de
desenvolvimento de software e o produto dele resultante podem ser
encarados, sobretudo tendo em conta os interesses particulares dos
diversos intervenientes no processo, que resultam das suas funes na
organizao. A definio de uma arquitectura slida a chave de
sucesso para qualquer projecto que utilize uma abordagem orientada
por objectos, segundo Booch [Booch95]. O RUP apresenta um modelo
segundo o qual considera a existncia de 4+1 vises do sistema,
definidas ao longo do processo, e cuja representao pode ser obser-
vada na Figura 10.6. Cada viso concretizada atravs de diversos
diagramas do UML.

Figura 10.6: As 4+1 Vises do RUP.
Para os utilizadores o mais importante a satisfao dos seus
requisitos funcionais, expressos numa viso lgica (Logical View) do
sistema. A este nvel necessrio garantir que se tem informao sobre
o que o sistema deve fazer. A arquitectura lgica do sistema represen-
tada atravs dos diagramas de classes que modelam as principais abs-
traces do sistema (classes, relaes e pacotes).
CAPTULO 10 METODOLOGIA RUP 303


Para os intervenientes tcnicos que participam no desenvolvimento do
sistema, interessa ter a viso da organizao do mesmo em termos dos
mdulos de software (desde o cdigo fonte at aos executveis), bem
como resolver questes relacionadas com a gesto da configurao, a
facilidade do desenvolvimento, a reutilizao e restries relacionadas
com as linguagens de programao. Esta a viso de implementao
(Implementation View), que reflecte a estrutura esttica do sistema. Os
principais elementos de modelao nesta viso incluem os pacotes e os
diagramas de componentes.
A viso de processamento (Process View) do sistema preocupa-se em
representar os conceitos relacionados com a implementao do sistema
no seu ambiente de produo. Estamos a falar de conceitos como
tarefas, actividades e processos, bem como com as suas interaces.
Nesta viso, so consideradas questes como paralelismo e
concorrncia na execuo, tolerncia a falhas, distribuio de objectos,
tempos de resposta e escalabilidade, desempenho, fiabilidade e integri-
dade do sistema. Esta viso modelada por diagramas de componen-
tes.
A viso de instalao (Deployment View) representa a correspondncia
entre os componentes desenvolvidos pelo projecto e o respectivo
suporte tecnolgico, modelando a configurao dos elementos de
processamento em tempo de execuo. As principais preocupaes so
questes como a migrao e instalao do sistema e o respectivo
desempenho, disponibilidade, fiabilidade e escalabilidade. So utiliza-
dos diagramas de componentes e de instalao, que permitem visuali-
zar a localizao fsica de componentes na infra-estrutura fsica e/ou
computacional da organizao.
Finalmente, a viso dos casos de utilizao (Use Case View) tem em
considerao os casos de utilizao importantes, de forma a definir, por
um lado, a arquitectura nas fases iniciais do processo e, por outro, a
validar mais tarde a percepo das restantes vises. Funciona assim
como a viso integradora de todas as restantes, e refora a ideia do
RUP enquanto metodologia conduzida por casos de utilizao, que so
naturalmente os principais diagramas de modelao desta viso.
304 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

10.5 Viso Geral
10.5.1 Conceitos Gerais
Uma metodologia, de acordo com a definio apresentada no Captulo
2, deve definir quem faz o qu, quando e como. Estas quatro
palavras-chave correspondem a alguns conceitos base utilizados pelo
RUP, que importa desde j clarificar:
Um interveniente (quem), que na terminologia RUP se designa por
worker: conceito que define o comportamento e as responsabili-
dades de um ou mais indivduos. Como exemplos, temos o analista
de sistemas, o programador, o elemento que efectua os testes.
Uma actividade (como): unidade de trabalho que um interveniente
pode ser chamado a realizar. A sua granularidade varia de algumas
horas at vrios dias e a unidade de planeamento mais elementar,
se bem que, do ponto de vista de aces a executar, podem ser
ainda divididas em passos mais elementares. Como exemplos de
actividades podemos indicar o planeamento de uma iterao ou a
identificao de casos de utilizao e de actores.
Um artefacto (o qu): qualquer informao que produzida,
alterada ou utilizada por um ou mais intervenientes durante uma
actividade. Como exemplo de artefactos temos os modelos, docu-
mentos, planos, cdigo fonte e executveis. Cada artefacto pode ser
elaborado com o apoio de ferramentas distintas.
Uma tarefa (quando), que na terminologia RUP se designa por
workflow: uma sequncia de actividades que produz um resultado
observvel. Utilizando a notao UML, um workflow normalmente
representado por um diagrama de actividades.

Figura 10.7: Conceitos importantes do RUP.
CAPTULO 10 METODOLOGIA RUP 305


A arquitectura do RUP encontra-se estruturada segundo duas dimen-
ses, que reflectem as duas vises atravs das quais um sistema pode
ser descrito (ver Figura 10.8)
Componente dinmica que reflecte a evoluo temporal de um
projecto, expressa em ciclos, fases, iteraes e objectivos a atingir.
Componente esttica que reflecte quais as tarefas (workflows) e
actividades realizadas, os outputs produzidos (artefactos), e os
intervenientes.

Figura 10.8: As dimenses do RUP.
10.5.2 Componente Dinmica
Quando se considera a componente dinmica do RUP, podemos
encarar um projecto como uma sequncia de fases, cada qual com v-
rias iteraes. Segundo o RUP, as fases so as seguintes:
Concepo (Inception): pretende obter uma viso global do sistema,
eliminar os riscos mais importantes e efectuar a definio do mbito
do projecto.
Elaborao (Elaboration): tem por objectivo especificar as funciona-
lidades e desenhar a arquitectura.
Construo (Construction): pretende implementar e testar o sof-
tware.
Transio (Transition): pretende distribuir o produto ao cliente final,
bem como efectuar todas as actividades necessrias (e.g.,
formao) para garantir o respectivo sucesso.
Cada fase concluda com um ponto de controle (milestone) bem
definido, no qual os resultados obtidos so comparados com objectivos
principais, e onde devem ser tomadas algumas decises crticas. As
mesmas actividades so executadas repetidamente em diversas
306 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

iteraes, cada uma aumentando o nvel de detalhe e/ou de abrangn-
cia.

Figura 10.9: Fases, iteraes e milestones.
10.5.3 Componente Esttica
A viso esttica do RUP descreve as tarefas (workflows) e as
actividades realizadas, bem como os artefactos produzidos e os
respectivos intervenientes. Esta viso encontra-se centrada no conceito
de workflow acima descrito. No RUP os workflows encontram-se
divididos em workflows de processamento e workflows de suporte. No
primeiro grupo incluem-se os workflows de:
Modelao de Processos de Negcio (Business Modeling): inclui as
actividades necessrias para compreender os processos de negcio
da organizao.
Requisitos (Requirements): agrupa o conjunto de actividades
relacionadas com a identificao e modelao dos requisitos do
sistema.
Anlise e Desenho (Analysis and Design): actividades de definio
do modo como o sistema ser construdo na fase de implemen-
tao.
CAPTULO 10 METODOLOGIA RUP 307


Implementao (Implementation): actividades de produo de
cdigo e testes unitrios.
Testes (Test): actividades de verificao de todo o sistema.
Instalao (Deployment): actividades de disponibilizao do sistema
para os seus utilizadores finais.
Os workflows de suporte agrupam actividades que decorrem ao longo
de todo o projecto, que no contribuem directamente para o produto
final, mas so essenciais para garantir o respectivo sucesso, como
sejam a gesto do projecto (Project Management), a gesto da
configurao e das alteraes (Configuration and Change Management)
e a definio do ambiente de desenvolvimento (Environment).
de realar a forma como os conceitos fase, tarefa e actividade se
encontram relacionados no RUP comparativamente s metodologias
tradicionais. Nestas ltimas, a relao entre estes trs conceitos
claramente de natureza hierrquica e sequencial: uma fase um
sequncia de tarefas, as quais so uma sequncia de actividades. Por
exemplo, a fase de concepo inclui a tarefa de planeamento, que tem,
entre outras, a actividade de elaborao do plano do projecto. Em
nenhuma circunstncia, nas metodologias tradicionais, podemos ter
situaes em que uma tarefa se prolonga durante vrias fases.
A viso do RUP, conforme descrito, inovadora, indo contra as formas
mais institudas e tradicionais de pensar o processo de desenvolvimento
de software. Uma fase decorre em vrias iteraes, o que desde logo
introduz algumas diferenas relativamente s abordagens tradicionais.
No entanto, a principal inovao resulta do facto de uma tarefa se
estender, ao longo do tempo, por vrias fases, e por conseguinte as
mesmas actividades de uma tarefa so repetidas em vrias iteraes.
10.6 Ciclos, Fases e Iteraes - A Componente
Dinmica
Diz-se que esta a viso dinmica do RUP porque ela agrupa os com-
ceitos que representam a evoluo de um projecto ao longo do tempo.
308 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Em termos da hierarquia de conceitos, o mais abrangente de todos o
ciclo, que pode ser definido como uma sequncia das quatro fases do
RUP (concepo, elaborao, construo e transio). Um ciclo produz
sempre uma verso funcional disponibilizvel para o cliente final. Se,
nalguns casos, os projectos podero apresentar apenas um ciclo,
normal que logo no incio de um projecto seja possvel ou mesmo
necessrio prever a ocorrncia de vrios ciclos:
No desenvolvimento de sistemas complexos, vale a pena ir
disponibilizando para os utilizadores finais verses incrementais de
funcionalidades.
No caso de projectos de software comercial, os ciclos subsequentes
representaro a tarefa de manuteno correctiva e evolutiva, que,
no fundo, no mais do que a aplicao de todas as actividades j
realizadas no primeiro ciclo, algumas com intensidade diferente.
Uma fase o perodo de tempo que decorre entre dois pontos de
controle planeados (milestones), durante o qual um conjunto bem defini-
do de objectivos alcanado, so produzidos artefactos, e so tomadas
decises sobre a continuidade do projecto.
Do ponto de vista formal, no so especificadas actividades relativa-
mente s fases, mas sim aos workflows, que so parte integrante da
outra viso, a viso esttica. Relativamente a cada fase, so especifica-
dos o conjunto de objectivos a atingir atravs da execuo de activida-
des de um ou mais workflows, ao longo de uma ou mais iteraes, e os
respectivos critrios de avaliao. Nesta perspectiva, bvio que duran-
te o perodo de tempo de uma fase ocorrero actividades, mas esta re-
lao indirecta, atravs dos respectivos workflows.
Esta uma viso muito mais natural e realista, visto que normal que a
mesma actividade seja ciclicamente realizada ao longo de um processo,
nomeadamente:
A identificao e modelao de requisitos ocorre sobretudo no incio
do processo, mas pode tambm ser efectuada j durante a
implementao (como todas os elementos que esto ligados rea
de desenvolvimento de sistemas de informao sabem que assim
que acontece na realidade).
A codificao pode ser realizada desde o incio das tarefas de
anlise, para a elaborao de prottipos e anlise de riscos prvia.
CAPTULO 10 METODOLOGIA RUP 309



Figura 10.10: Percentagem de finalizao de cada workflow no final de
cada fase.
Cada fase pode ser realizada em diversas iteraes, cada uma
constituindo-se como uma sequncia de actividades, que resulta numa
verso interna ou externa (no caso da ltima iterao da fase de
transio) de um produto executvel, e que cresce incrementalmente ao
longo das vrias iteraes. Com esta abordagem, os riscos so
resolvidos antecipadamente tomada de decises da arquitectura, as
alteraes so geridas mais facilmente e a reutilizao de artefactos
mais elevada, o que possibilita uma qualidade global superior.
Analisamos de seguida cada uma das fases do RUP.
10.6.1 Concepo
Durante a fase de concepo, os objectivos so: (1) definir o business
case (justificao de negcio) do projecto, incluindo questes como os
critrios de sucesso, a anlise de risco, os recursos necessrios e (2)
elaborar um plano das fases seguintes com os principais pontos de
deciso. ainda nesta fase que delimitado o mbito do projecto e so
identificadas todas as entidades externas com as quais o sistema inte-
310 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

rage. Todos os casos de utilizao devem ser identificados e os apa-
rentemente mais relevantes devero ser descritos.
Os principais resultados a obter no final desta fase so:
Documento com a viso geral do problema: requisitos principais,
funcionalidades mais significativas, restries importantes.
Modelo de casos de utilizao, dos quais tipicamente entre 10% a
20% do total devero estar especificados.
Glossrio inicial do projecto.
Relatrio inicial de avaliao do risco.
Justificao de negcio (business case) inicial.
Plano de projecto.
Prottipos iniciais.
Cada fase tem critrios de avaliao, a aplicar no seu final, de modo a
confirmar a realizao dos objectivos. No caso da fase de concepo,
estes incluem:
Aprovao dos patrocinadores e interessados no sistema relativa-
mente ao mbito e s estimativas de custos e prazos elaboradas.
Compreenso dos requisitos evidenciada pela equipa do projecto,
atravs dos primeiros casos de utilizao elaborados.
Credibilidade das estimativas de custos e prazos e do processo de
desenvolvimento definido.
Adequabilidade (ao nvel da abrangncia e do detalhe) dos protti-
pos da arquitectura desenvolvidos.
Comparao entre gastos planeados e efectivamente realizados.
10.6.2 Elaborao
A fase de elaborao tem como preocupao central analisar o domnio
do problema detalhadamente, de forma a definir uma arquitectura de
componentes do sistema slida e robusta e a pormenorizar o plano do
projecto, em resultado do conhecimento entretanto adquirido. Com
estes objectivos atingidos, possvel identificar as medidas que
permitam eliminar os riscos mais significativos. Em termos prticos,
ainda objectivo desta fase construir o prottipo da arquitectura (numa ou
CAPTULO 10 METODOLOGIA RUP 311


mais iteraes da fase) e identificar todos os actores e casos de utiliza-
o, descrevendo a sua grande maioria. Por isso, alguns dos principais
resultados a obter nesta fase so:
Modelo de casos de utilizao (considera-se que pelo menos 80%
do total dos casos de utilizao devero estar especificados).
Requisitos totais do sistema, incluindo os funcionais e no funcio-
nais.
Descrio da arquitectura de software.
Prottipo executvel da arquitectura.
Lista de riscos e business case revistos.
Plano de projecto revisto.
Manual do utilizador (preliminar).
No final desta fase so examinados o mbito e os objectivos detalhados
do sistema, seleccionada a arquitectura e so identificadas medidas
para solucionar (ou pelo menos atenuar) os principais riscos. Os crit-
rios de avaliao para verificar a satisfao dos resultados face aos ob-
jectivos incluem:
Estabilidade da viso do produto e da arquitectura.
Resoluo dos principais riscos do sistema.
Detalhe e estabilidade do planeamento para a fase de construo e
credibilidade das estimativas efectuadas.
Aprovao pelos interessados no sistema que a percepo
actualmente existente do mesmo por parte da equipa do projectos,
pode ser atingida com o plano do projecto e no contexto da arquitec-
tura proposta.
Comparao entre gastos planeados e efectivamente realizados.
10.6.3 Construo
objectivo principal da fase de construo efectuar o desenvolvimento
e integrao de componentes no produto final, bem como testes
exaustivos a todas as funcionalidades. prestada particular ateno ao
controle de custos, prazos e qualidade do produto. No final desta fase
existe um produto que pode ser disponibilizado aos utilizadores, que
312 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

inclui os diversos componentes de software integrados e instalados nas
plataformas identificadas.
De modo a garantir que todos os componentes tecnolgicos esto
prontos para a entrada em produo, sem riscos elevados, e que o
produto se encontra suficientemente estvel e maduro para ser utiliza-
do. Mais uma vez, tambm necessrio comparar os gastos planeados
e os efectivamente realizados, de forma a identificar e analisar
eventuais desvios.
10.6.4 Transio
objectivo desta fase efectuar a disponibilizao do software para o
utilizador. Para que tal acontea, necessrio garantir a conformidade
do sistema produzido relativamente aos requisitos inicialmente
definidos, que o conjunto de funcionalidades identificadas tenha sido
desenvolvido e que o seu todo constitui um sistema funcional; ainda
necessrio garantir que a documentao do utilizador foi elaborada. Por
isso, o sistema deve ser validado em relao s expectativas dos
utilizadores (o que pode envolver a realizao de processamentos
paralelos), as bases de dados operacionais devem ser convertidas, os
utilizadores devem receber formao e finalmente o produto deve ser
instalado ou distribudo. Os principais critrios de avaliao so a
satisfao do utilizador e a comparao entre as estimativas inicial-
mente previstas e o que efectivamente foi realizado.
10.6.5 Comentrios Gerais
A abordagem iterativa fcil de representar mas no de aplicar. O
processo iterativo encontra-se organizado em fases, mas ao contrrio
das abordagens tradicionais ortogonal s tarefas que compreende. A
aplicao destas quatro fases constitui o que se designa por um ciclo
de desenvolvimento, o qual produz uma verso do software
disponibilizvel para o cliente. Cada produto ter sempre um ciclo
inicial, e a no ser que o desenvolvimento pare (o que pouco
provvel, quanto mais no seja porque se entra na fase de
CAPTULO 10 METODOLOGIA RUP 313


manuteno), podero existir posteriores ciclos de evoluo, que pro-
duzem novas verses.
Para alm dos ciclos e das fases, cada uma das fases pode ainda ser
dividida em iteraes, nas quais se aplicam sucessivamente actividades
que esto previstas nos vrios workflows (ver Seco 10.7), com graus
de intensidade diversos consoante a fase e a iterao. Assim, na
iterao da fase de concepo (tipicamente apenas uma), procura-se
obter uma viso global dos requisitos e determinar o mbito e o esforo
de trabalho a realizar. Nas iteraes da fase de elaborao, o principal
objectivo identificar os requisitos, e por isso as principais actividades
pertencem ao workflow de requisitos. No entanto, este objectivo da fase
de elaborao tambm atingido com actividades do workflow de
anlise e desenho e do workflow de implementao, como sejam a
produo de prottipos e a eliminao de riscos tcnicos atravs da
seleco de alternativas.
Nas diversas iteraes da fase de construo, e uma vez que o
objectivo construir um primeiro produto operacional, as actividades do
workflow de implementao vo aumentando de importncia relativa, o
que no significa que algumas decises sobre a arquitectura dos
componentes no tenham que ser revistas em funo de problemas s
identificados nesta fase, e da existirem tambm actividades dos
wokflows de requisitos e de desenho. Finalmente, as iteraes da fase
de transio procuram disponibilizar o produto para o seu utilizador final,
sendo por isso natural que as actividades principais sejam dos
workflows de testes e de instalao. Contudo, as correces a efectuar
podem implicar ainda a reviso da estrutura do sistema (actividades do
workflow de desenho) e a codificao de componentes (actividades do
workflow de implementao).
Esta abordagem iterativa permite que os riscos sejam identificados e
controlados atempadamente no processo de desenvolvimento, que as
alteraes sejam de facto melhor controladas, que a reutilizao dos
diversos artefactos, a qualidade do produto e a produtividade dos tcni-
cos informticos sejam superiores.
314 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

10.7 Workflows, Actividades e Artefactos A
Componente Esttica
A especificao da estrutura esttica do RUP envolve a descrio de
quem (Interveniente - Worker) faz o qu (Artefactos), como (Activida-
des) e quando (Workflows). O modelo do RUP prev a existncia de
seis workflows principais, que agrupam as actividades directamente re-
lacionadas com a produo do produto final:
Modelao do negcio
Requisitos
Anlise e Desenho
Implementao
Testes
Instalao.
Prev ainda a existncia de trs workflows de suporte, que incluem
actividades de apoio executadas ao longo de todo o processo, que so
essenciais para garantir o sucesso do mesmo:
Gesto de projectos
Configurao e gesto de alteraes
Definio do Ambiente
Ao contrrio das abordagens tradicionais, estes workflows no s no
so sequenciais, como so repetidos diversas vezes ao longo das
vrias fases do processo, em vrias iteraes, possivelmente realizando
actividades diferentes ou com um grau varivel de intensidade e deta-
lhe.
Podemos dizer que o workflow completo de um projecto inclui estes
nove workflows individuais, repetidos com nfase e intensidade varivel
ao longo de cada fase e iterao. A realizao das vrias actividades
produz diversos artefactos, os mais significativos dos quais so apre-
sentados na Figura 10.11.
O RUP tem um conjunto muito extenso de diagramas para especificar
as actividades realizadas por cada interveniente e os artefactos
produzidos, bem como a respectiva sequncia temporal. O volume de
informao a representar faz com que no seja praticvel a sua incluso
CAPTULO 10 METODOLOGIA RUP 315


neste livro, e por isso optmos por apresentar simplificadamente apenas
as actividades e os intervenientes por elas responsveis.

Figura 10.11: Principais artefactos produzidos no mbito do RUP.
De forma a clarificarmos inicialmente o desenrolar do processo, e a
aplicarmos o mesmo ao caso prtico, comecemos por abordar o work-
flow de gesto do projecto.
10.7.1 Workflow de Gesto do Projecto
Este workflow especifica um conjunto de princpios a aplicar na gesto
de projectos de software, sobretudo ao nvel do planeamento, alocao
de recursos, acompanhamento e controle do projecto, e na identificao
e controle dos riscos dos projectos. No contempla aspectos gerais, que
qualquer gestor de projecto deve saber aplicar (no sendo especficos
de projectos de desenvolvimento de software), nomeadamente gesto
316 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

de recursos humanos, elaborao de oramentos e gesto de relaes
entre clientes e fornecedores.
Se as vantagens da aplicao de um processo iterativo so bvias, o
mesmo no acontece com as decises relacionadas com o nmero de
iteraes a realizar, a durao de cada uma, os objectivos a atingir ou a
intensidade das actividades de cada workflow. A evoluo de um projec-
to, segundo a abordagem preconizada pelo RUP, torna impraticvel a
elaborao de um plano detalhado e minimamente credvel logo no
arranque do projecto, uma vez que o nvel de conhecimento sobre o
problema em anlise vai aumentando no decorrer do projecto. Por isso,
a estratgia preconizada pelo RUP assenta na existncia de dois pla-
nos:
Plano de fases: um plano de alto nvel, elaborado inicialmente para
as fases, e revisto periodicamente.
Planos de iteraes: um plano por cada iterao elaborado mais
prximo do momento da sua execuo.
O primeiro inclui as datas dos principais objectivos a atingir (milestones)
em cada uma das quatro fases, e dos objectivos intermdios que
correspondem s datas de fim de cada iterao. Para alm destas
questes temporais, inclui ainda informao de alto nvel sobre a
alocao de recursos ao longo do tempo. um documento de pequena
dimenso (2 pginas no mximo), elaborado no incio da fase de
concepo; pode ser revisto sempre que necessrio.
Adicionalmente ao plano de fases dever ser elaborado um plano por
cada iterao, utilizando as notaes usuais (diagramas de Pert, Gantt,
etc). Normalmente, e em cada momento, devero estar elaborados dois
planos deste tipo, um da iterao actual e outro da imediatamente
seguinte, uma vez que para as restantes iteraes existir sempre no
futuro informao mais correcta para proceder respectiva elaborao.
Os planos das iteraes definem as actividades a um nvel mais
elementar (concretizando orientaes genricas propostas pelos
workflows do RUP) e a alocao de recursos correspondente.
CAPTULO 10 METODOLOGIA RUP 317



Figura 10.12: Actividades do workflow de Gesto de Projecto realizadas
pelo Gestor do Projecto.
O principal interveniente neste workflow claramente o gestor do
projecto, que responsvel pela elaborao da grande maioria dos
artefactos, sendo de destacar os seguintes (ver Figura 10.12):
"Business Case".
"Planos de Fases".
"Planos das Iteraes".
"Plano de Desenvolvimento do Projecto", que inclui o Plano de
Aceitao do Produto Final, a Lista de Riscos e o Plano de Gesto
dos mesmos, o Plano de Resoluo dos Problemas e o Plano de
Elaborao de Mtricas.
Tal como representado na Figura 10.12, as actividades realizadas pelo
gestor de projecto ao longo deste workflow podem ser agrupadas em
funo dos momentos em que ocorrem. Para alm do gestor de projecto
existe ainda a figura do auditor ou revisor do projecto, que realiza
diversas actividades cujo objectivo garantir a qualidade de cada um
dos artefactos produzidos, e cujas actividades esto representadas na
Figura 10.13.
318 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE


Figura 10.13: Actividades do workflow de Gesto de Projecto realizadas
pelo Auditor do Projecto.
A elaborao de planos credveis est relacionada com a determinao
da relao correcta entre recursos, prazos e mbito. Estes parmetros
do projecto podem ser definidos por comparao com experincias do
passado de modo a decidir o esforo e a durao relativa das diversas
fases, bem como do nmero de iteraes e durao de cada uma.
Estas questes sero discutidas detalhadamente no final deste captulo
com a apresentao de um caso prtico (ver Seco 10.8).
10.7.2 Workflow de Modelao do Negcio
As actividades realizadas neste workflow tm por objectivo
compreender o funcionamento da organizao, identificar problemas e
oportunidades de melhoria e garantir uma base de entendimento
comum entre utilizadores e informticos, a partir da qual os requisitos do
sistema podem ser identificados. Os principais artefactos a produzir so:
um documento que reflecte a percepo adquirida sobre o negcio;
diagramas de casos de utilizao relacionados com negcio; e um mo-
delo dos objectos do negcio.
As principais actividades a realizar durante este workflow podem ser
observadas na Figura 10.14.

Figura 10.14: Actividades do workflow de Modelao de Processos do
Negcio.
As actividades deste workflow podem ser realizadas mesmo quando o
objectivo no seja o desenvolvimento de software, mas necessrio
compreender melhor o negcio de modo a, eventualmente, reformular
CAPTULO 10 METODOLOGIA RUP 319


alguns dos seus processos. A utilizao de tcnicas de modelao do
negcio (casos de utilizao) idnticas s utilizadas para a captura dos
requisitos, facilita o mapeamento entre ambos os modelos. Na perspec-
tiva de desenvolvimento de software, este workflow considerado op-
cional.
10.7.3 Workflow de Requisitos
As actividades realizadas neste workflow tm como objectivo principal
efectuar a descrio das funcionalidades do sistema e obter o
respectivo consenso dos utilizadores. Esta descrio permite delimitar o
mbito do sistema, e constitui a base para a definio dos componentes
tecnolgicos e para a elaborao das estimativas de custos e esforo
para efectuar o seu desenvolvimento. Estes requisitos no so apenas
de natureza funcional, isto , que resultam das necessidades dos utiliza-
dores e dos processos de negcio; outras categorias de requisitos deve-
ro ser identificadas atravs das actividades realizadas neste workflow,
nomeadamente:
Facilidade de utilizao do sistema, envolvendo factores como
aspectos da interface homem-mquina e elaborao de documenta-
o.
Fiabilidade: tem a ver com a previsibilidade do funcionamento,
gravidade dos erros e preciso do sistema.
Desempenho: impe restries de natureza quantitativa aos requi-
sitos funcionais, podendo reflectir-se em aspectos tecnolgicos (por
exemplo, durao de uma operao ou memria utilizada).
Capacidade de suporte: relacionado com o controle de qualidade, a
manuteno e o suporte ao sistema aps entrada em produo.
O diagrama que, por excelncia, deve ser utilizado para modelar as
interaces dos utilizadores com o sistema o diagrama de casos de
utilizao. Para identificar os requisitos do sistema, so produzidos (ou
alterados) diversos artefactos:
As necessidades e funcionalidades principais so descritas no docu-
mento da viso, que fornece uma descrio de alto nvel do sistema.
320 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

O detalhe dos requisitos de natureza funcional representado num
modelo de casos de utilizao e os restantes so especificados em
"Especificaes Suplementares".
Para alm de outros artefactos, so ainda produzidos o "Glossrio" e o
"Prottipo da Interface", a validar com os utilizadores. Na produo des-
tes artefactos encontram-se envolvidos analistas de sistemas, especia-
listas em casos de utilizao e especialistas em desenho da interface.
As actividades realizadas por estes intervenientes podem ser obser-
vadas na Figura 10.15.

Figura 10.15: Actividades do workflow de Requisitos.
10.7.4 Workflow de Anlise e Desenho
As actividades deste workflow permitem elaborar a especificao
tcnica do sistema, a partir das especificaes funcionais e
suplementares produzidas pelo workflow anterior. Est, pois, em causa
a identificao de uma estratgia e de uma arquitectura para o sistema
futuro, que podem ser ajustadas de forma iterativa. Enquanto a anlise
se concentra na identificao de um conjunto de classes e sistemas que
permitem representar os requisitos dos utilizadores (esquecendo por
vezes alguns dos requisitos no funcionais), o desenho utiliza o
resultado da anlise e integra as restries resultantes dos requisitos
no-funcionais, e do ambiente e da arquitectura tecnolgica, de forma a
garantir a satisfao de todos os requisitos.
Os principais intervenientes neste workflow so o arquitecto de software
e diversos elementos especializados em tarefas de especificao. So
estes intervenientes que esto envolvidos na construo dos principais
artefactos do workflow, o "Modelo do Desenho" e o "Documento da
Arquitectura de Software".
CAPTULO 10 METODOLOGIA RUP 321



Figura 10.16: Actividades do workflow de Anlise e Desenho.
10.7.5 Workflow de Implementao
Atravs deste workflow pretende-se definir a estrutura do sistema e
implementar os respectivos componentes; testar individualmente cada
um; e efectuar a integrao dos vrios componentes, de modo a cons-
truir um sistema executvel. So por isso realizadas tarefas associadas
programao e integrao, o que torna necessria a participao de
intervenientes do tipo programador e integrador de sistemas, com o
apoio do arquitecto e do revisor de cdigo. Os principais artefactos a
produzir por este workflow so os seguintes:
"Componentes", que so unidades de cdigo, elementares ou que
resultam da agregao de outros componentes.
322 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

"Subsistemas de Implementao", constitudos por uma coleco de
componentes e outros subsistemas de implementao. O seu
conjunto constitui o sistema global.
"Plano de integrao" de uma release parcial, que define a ordem de
desenvolvimento e de integrao de componentes.
As principais actividades realizadas esto representadas no diagrama
da Figura 10.17.

Figura 10.17: Actividades do workflow de Implementao.
10.7.6 Workflow de Testes
Este workflow garante: (1) a integrao entre os componentes imple-
mentados; (2) a correco dos erros detectados antes da instalao do
sistema; (3) a conformidade entre o sistema implementado e os requisi-
tos definidos pelos utilizadores.
A preocupao de garantir a qualidade do produto final, atravs da
realizao de testes frequentes, leva a que os mesmos possam ser
realizados desde muito cedo no desenrolar do projecto. Por exemplo,
podem ser efectuados testes aos prottipos desenvolvidos logo na fase
de elaborao, o que justifica a existncia deste workflow nessa fase.
As actividades previstas neste workflow garantem a realizao de
diversos tipos de testes, nomeadamente de integrao, de sistema e de
aceitao, para alm de outros relacionados com questes de natureza
tecnolgica (de carga, de instalao, de desempenho).
Esto envolvidos neste workflow dois tipos de intervenientes, respon-
sveis pelo planeamento e pela execuo de testes, e que produzem
diversos artefactos, nomeadamente o "Plano de Testes", o "Modelo de
Testes" (representao do que ser testado e de como ser feito) e os
"Resultados dos Testes".
CAPTULO 10 METODOLOGIA RUP 323


As actividades do workflow de Testes podem ser observadas na Figura
10.18:

Figura 10.18: Actividades do workflow de Testes.
10.7.7 Workflow de Instalao
De forma a garantir o sucesso do sistema desenvolvido, essencial
efectuar a sua disponibilizao para os seus utilizadores finais da forma
mais adequada e com o mnimo impacto no seu trabalho. este o
objectivo do workflow de instalao. De modo a que o objectivo seja
alcanado, est prevista a realizao de diversas actividades de apoio,
como sejam a produo de manuais de formao e de utilizao do
sistema. Uma lista mais completa de actividades pode ser observada na
Figura 10.19.
324 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE


Figura 10.19: Actividades do workflow de Instalao.
O nvel de abrangncia do RUP pode ser observado tambm neste
workflow, uma vez que prev actividades diferentes, consoante a forma
como a produo e disponibilizao do software efectuada: atravs de
mecanismos de download do software, ou atravs de produo em
massa numa fbrica.
10.7.8 Workflow de Gesto da Configurao e das
Alteraes
O workflow de gesto da configurao e das alteraes tem por
objectivo garantir e manter a integridade e consistncia dos vrios
artefactos produzidos ao longo do processo. Neste mbito, podemos
estar a falar quer dos requisitos dos utilizadores, quer dos modelos
desenvolvidos ou do cdigo propriamente dito.
Os principais intervenientes neste workflow so o gestor de
configurao e o gestor de controle de alteraes, sendo naturalmente
envolvidos outros elementos (implementadores, integradores, arquitec-
CAPTULO 10 METODOLOGIA RUP 325


to, e qualquer outro interveniente que possa solicitar alteraes). Os
principais artefactos produzidos durante este workflow so o "Plano de
Gesto de Configurao" e os "Pedidos de Alteraes". As actividades
previstas so apresentadas na Figura 10.20.

Figura 10.20: Actividades do workflow de Gesto da Configurao e das
Alteraes.
10.7.9 Workflow de Ambiente
O workflow de ambiente tem por objectivo dar apoio aos intervenientes
informticos que esto relacionados com o desenvolvimento do sof-
tware e com a utilizao de ferramentas e aplicao do processo
metodolgico. Consequentemente, este workflow prev a aplicao de
princpios relativos seleco e aquisio de ferramentas, configura-
o, gesto e melhorias a aplicar ao processo.
Como se pode observar na Figura 10.8, as actividades deste workflow
esto concentradas sobretudo no incio do projecto, uma vez que
326 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

actividades como seleco de ferramentas e a definio dos princpios
metodolgicos tero que ser realizadas nesta altura. As suas activida-
des so representadas no diagrama da Figura 10.21.


Figura 10.21: Actividades do workflow de Ambiente.
CAPTULO 10 METODOLOGIA RUP 327


10.8 Enunciado do Caso de Estudo DGD
De forma a demonstrar na prtica como podem ser concretizados
alguns dos principais conceitos do RUP, vamos introduzir de seguida
um caso prtico fictcio (qualquer semelhana com a realidade mera
coincidncia!), e com base nele vamos discutir a aplicao do RUP.
Nesta discusso, procuramos sobretudo demonstrar como se planeiam
e desenrolam as actividades, os workflows e as iteraes ao longo de
um projecto, sem referir questes de modelao, que foram j
apresentadas na Parte 2, e que sero o principal foco do captulo se-
guinte, dedicado ao ICONIX.
10.8.1 Enunciado
Suponha-se a existncia de um organismo pblico responsvel pela
atribuio e gesto de toda a documentao, de natureza oficial e legal,
que um cidado tem. Vamos atribuir a esse organismo a designao de
Direco Geral da Documentao (DGD). Entre a documentao
abrangida podemos salientar o bilhete de identidade, o passaporte, o
carto de contribuinte, o carto de eleitor, a carta de conduo, o carto
do servio nacional de sade. Toda a informao que se descreve de
seguida, se bem que apresentando alguma lgica, no pretende
associar-se (ou induzir!) a nenhum organismo em concreto.
A DGD foi criada na sequncia da fuso de vrios organismos que
anteriormente se encontravam na dependncia de diversos ministrios,
e cuja cultura organizacional de cada um e o ambiente tecnolgico dos
sistemas de informao respectivos eram muito diversos.
Para alm disso, a disperso geogrfica ainda hoje uma realidade;
mesmo na cidade de Lisboa, onde se situavam as sedes de todos os
organismos originais, no foi possvel at data efectuar a sua
concentrao num nico edifcio. Em localidades do interior do pas,
existem diversos edifcios da DGD, mas cada um apenas trata de um
documento especfico.
A integrao, que se esperava que trouxesse benefcios bvios para o
cidado, uma vez que passou a existir apenas um nico organismo para
328 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

tratar de qualquer assunto relacionado com documentao, no
produziu os resultados desejados. Os sistemas de informao originais
permanecem separados, e so tecnologicamente muito diversos, desde
os ambientes mainframe IBM para a gesto das cartas de conduo,
at aos sistemas Unix para o bilhete de identidade, passando por outro
tipo de ambientes (VAX, AS/400, plataformas Windows, etc).
Na altura da criao da DGD, foi lanado um projecto de uniformizao
dos sistemas (o projecto piloto inicial apenas inclua dois) que falhou,
com custos elevados. As questes culturais, a inrcia poltica, o receio
da perda de privilgios adquiridos, a falta de empenhamento dos
elementos das duas reas, os problemas tecnolgicos e a incapacidade
interna de gesto de projecto (tratou-se de um projecto realizado com
recursos exclusivamente da DGD) podem ser apresentadas como as
principais razes que motivaram este falhano.
Os recursos humanos existentes na rea de informtica, apesar de
estarem hoje colocados todos no mesmo departamento, continuam
afectos aos sistemas onde originalmente trabalhavam. A mdia de ida-
des dos trabalhadores ultrapassa os 45 anos, a maioria dos quais nunca
trabalhou noutras organizaes.
atravs da DGD que o cidado se relaciona com o Estado sobre
quaisquer assuntos relacionados com documentos. Os principais
processos de negcio so os seguintes:
Registo do pedido de emisso do documento. Envolve a recepo
do pedido explicitamente efectuado pelo cidado ao balco de uma
das inmeras delegaes da DGD. Implica apenas receber a
documentao que mais tarde introduzida pelos funcionrios da
DGD no sistema de informao, sem qualquer controle de prazos
desde a entrega at ao registo do processo. O cidado tem que
comprar impressos especficos para cada documento, preench-los,
e depois de efectuar o pedido, recebe um comprovativo da entrega e
nalguns casos efectua um pagamento (por exemplo, no caso do
passaporte).
CAPTULO 10 METODOLOGIA RUP 329


Validao da possibilidade de emisso do documento. Por exemplo,
no caso do pedido do passaporte verificado o registo criminal do
cidado; no caso do pedido do carto da segurana social,
contactado o Ministrio da Sade para determinar se a pessoa em
causa est ou esteve abrangida por outro sistema de segurana
social. Por estas e outras razes que implicam um tratamento
diferenciado segundo o tipo do documento, os prazos de entrega
no so uniformes.
Nalguns casos, existe a possibilidade da DGD emitir um documento
provisrio. o que acontece no caso do carto de contribuinte.
A emisso do documento propriamente dita. Nalguns casos, o
documento fsico produzido na prpria DGD, noutros casos este
produzido externamente e enviado posteriormente para a DGD. O
documento sempre fotocopiado e a fotocpia armazenada junto do
restante processo. No existem funcionalidades de digitalizao
implementadas.
O envio do documento, ou de um aviso para o cidado, quando o
documento estiver pronto, a solicitar ao cidado o levantamento do
documento. No caso em que o documento logo enviado, sempre
acompanhado por um aviso de recepo.
A renovao do documento, nos casos em que se aplica
(passaporte, bilhete de identidade), e cuja iniciativa parte sempre do
cidado. No actualmente feito nenhum controle de documentos
fora de prazo, nem dos processos fsicos que os suportam. Esta
quantidade de papel est armazenada em cinco localizaes de
grande dimenso, e espalhadas pelos arredores de Lisboa. Quando
necessrio esclarecer alguma questo, preciso requisitar o
processo fsico, sendo frequentes as situaes em que se perdem
documentos, ou em que, pelo menos, estes no so localizveis.
O registo de averbamentos para alguns documentos. Por exemplo,
no caso da carta de conduo, a DGD recebe informao da polcia
sobre as multas e penas em que um condutor incorreu. Esta
informao chega sob a forma de papel, pelo que necessrio
efectuar a sua introduo no sistema. O volume que esta informao
atinge faz com que exista normalmente um atraso de vrios meses.
Pedidos diversos de informao, que o cidado efectua DGD
sobre o estado dos seus documentos, ou esclarecimentos sobre
procedimentos a realizar.
330 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Para alm da informao especificamente relacionada com cada um
dos documentos, a DGD recolhe e regista informao sobre o cadastro
do cidado, que lhe chega de diversas fontes (policia, tribunal,
ministrios), e que o cidado pode solicitar atravs de um pedido de
Certido do Cidado. Esta informao inclui multas, condenaes,
louvores, condecoraes, medalhas e ttulos atribudos. Uma parte
significativa desta informao consta do Dirio da Repblica, que no
se encontra digitalizado.
Todos estes problemas levaram a tutela governamental a considerar
insustentvel a manuteno da situao, e em funo da aparente
incapacidade interna de solucionar os problemas, foi decidido contratar
uma empresa externa para implementar um sistema de informao
global, integrado, cujo principal objectivo servir e simplificar a relao
com o cidado. Nesse sentido, um dos pressupostos do projecto era a
utilizao da Internet atravs da disponibilizao de diversos servios.
Perante este problema de alguma complexidade, a empresa selec-
cionada resolveu aplicar o RUP ao longo do projecto.
10.9 Resoluo do Caso de Estudo DGD
O primeiro grande desafio que se coloca, e que se procura resolver
durante a primeira e (normalmente) nica iterao da fase de concep-
o, a elaborao do artefacto plano do projecto. Tal pressupe a
correcta definio do nmero de ciclos que o projecto ter, da durao
do primeiro ciclo, do nmero de iteraes e respectiva durao. Para
isso, inicialmente elaborado um plano da primeira iterao, onde
so identificadas as actividades a realizar para obter um conhecimento
de alto nvel do negcio. Por conseguinte, as primeiras actividades a
realizar pertencem ao workflow de requisitos, e incluem:
Elaborar o documento da viso do negcio. uma actividade
que deve ser realizada conjuntamente pelos analistas de sistemas e
pelos utilizadores, sendo produzido o artefacto viso do negcio.
Identificar as necessidades e as expectativas dos utilizadores,
que deve resultar no artefacto necessidades dos utilizadores.
CAPTULO 10 METODOLOGIA RUP 331


Identificar os principais casos de utilizao. Atravs de reunies
com os utilizadores chave de cada departamento, previamente
nomeados, e de questionrios que procuravam identificar as
principais lacunas dos utilizadores. Como resultado desta actividade
ser iniciada a produo do modelo de casos de utilizao.
Iniciar a elaborao de um glossrio de termos, de modo a
simplificar e manter consistente o modelo de casos de utilizao.
Elaborar o business case e a lista de riscos (que so tambm
dois artefactos produzidos), como consequncia da percepo que
entretanto foi obtida das actividades anteriores.
Descrever cada uma das actividades anteriores, bem como o contedo
dos respectivos artefactos seria demasiado detalhe para incluir neste
exemplo. No entanto, mesmo assim gostaramos de apresentar alguma
informao relevante sobre estes artefactos, de modo a transmitir ao
leitor a percepo sobre o respectivo contedo.
Viso do Negcio
O objectivo deste documento recolher, analisar e definir as funci-
onalidades e requisitos de alto nvel do sistema.

No caso concreto do problema aqui exposto, ele deveria incluir uma
seco onde fossem abordados, mais extensamente, e entre outros, os
seguintes tpicos.
Problema: A DGD um organismo pblico cujo objectivo gerir todas
as relaes entre o Estado e o cidado, relacionadas com assuntos de
documentao. Resultou da fuso de diversos organismos existentes, e
cuja integrao, quer ao nvel do negcio quer dos sistemas de
informao nunca foi efectivamente conseguida. Muitos processos de
negcio apresentam claras ineficincias. Os sistemas de informao
no so adequados para a prestao de servios de qualidade ao
cliente final
Afectados: Este problema afecta quer o trabalho dos recursos internos
da DGD, quer o cidado que com ela contacta
332 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Impacto: Custos financeiros no optimizados. Recursos humanos em
excesso e mal aproveitados, realizam muito trabalho manual, concen-
trados em tarefas de menor valor acrescentado. Elevado volume de do-
cumentao em papel
Sistemas actuais: Um conjunto de ambientes tecnologicamente
heterogneo, muitos deles ultrapassados, desenvolvidos internamente,
com pouca flexibilidade.
Interessados: Deveriam ser referidas pessoas tais como o Secretrio
de Estado responsvel, o Director Geral, os Chefes dos Departamentos,
e caracterizadas as suas posies e interesses no sistema. O outro
grande interessado seria sempre o cidado
Soluo: Sistema de informao integrado, atravs de diversos canais
(balco, telefone e Internet). Privilegiar critrios de qualidade do atendi-
mento e tempo de resposta. Automatizao de tarefas rotineiras, liberta-
o de recursos para outras tarefas de maior valor acrescentado


Lista de Riscos
A lista de riscos deve enumerar todos os riscos que, potencialmente,
possam ocorrer ao longo do projecto. Como exemplo, no caso da DGD
poderamos identificar o risco Recursos Humanos pouco motivados.

Ranking do Risco: Muito elevado.
Descrio: Os Recursos Humanos (RH) disponveis apresentam
deficincias graves, mesmo inultrapassveis, em termos do conheci-
mento de tecnologia, da aplicao de metodologias de desenvolvimento
bem definidas (como o caso do RUP), e mostram pouca abertura a
novas ideias.
Impacto: O fraco envolvimento dos RH actualmente existentes no
projecto pode comprometer o sucesso da migrao para um novo siste-
CAPTULO 10 METODOLOGIA RUP 333


ma, caso assumam uma posio reactiva ("eu s dou o que me
pedirem").
Indicadores: Para avaliar a existncia do risco, poderamos utilizar
grandezas como tempos de atraso no fornecimento de informao pedi-
da.
Estratgias para Evitar Riscos: Introduzir medidas associadas a
recompensas financeiras, que promovam a cooperao de todos, por
exemplo "se o projecto terminar no prazo previsto todos os funcionrios
recebero trs salrios adicionais".
Plano de Contingncia: Na impossibilidade de contar com a
colaborao dos elementos actualmente existentes para explicar a
estrutura de dados, pode justificar-se a introduo de alguma informa-
o mo, a partir dos processos em papel, ou por tcnicas de OCR
(optical character recognition), uma vez que esta ltima ser sempre
necessria no sistema em produo.

Estes riscos no so apenas do negcio, e podem tambm ser de
natureza tecnolgica. Por exemplo, na DGD, a utilizao de tecnologias
Internet, um dos pressupostos da soluo, poderia apresentar
problemas de desempenho e escalabilidade graves, dado o volume de
informao a tratar, e caso a arquitectura no fosse adequadamente
definida. Por isso, este risco deveria ser identificado desde o incio do
projecto, e para avaliar o seu impacto, poderia ser elaborado um
pequeno prottipo de uma funcionalidade de consulta de dados de
processos de cartas de conduo, num ambiente de testes semelhante
ao ambiente final de produo. Tal permitiria verificar que estas
tecnologias no apresentavam os problemas inicialmente previstos,
desde que fossem seguidos um conjunto de princpios, tcnicas e boas
regras de programao.

334 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Plano das Fases
Com esta informao recolhida (e recordemos que ainda estamos na
iterao da fase de concepo), seria chegada a altura de avaliar se a
viso de alto nvel obtida pode ser justificada financeiramente,
considerando para isso os investimentos a realizar, as estimativas de
recursos, os critrios de sucesso. Entramos assim nas actividades do
workflow de Gesto de Projectos. Esta avaliao permite detalhar o
Business Case e a Lista de Riscos, e elaborar o Plano das Fases,
que apresenta uma primeira estimativa para as datas de incio e fim de
cada uma das 4 fases, bem como dos principais pontos de controlo.
Na sequncia deste plano, deveria ser possvel obter uma aprovao
prvia dos interessados, relativamente viso e viabilidade do
projecto. A partir destas so prioritizados os casos de utilizao e as
funcionalidades, e o plano inicial detalhado, sendo definidas o n-
mero de iteraes para cada fase. Vejamos pois, em termos concretos,
como poderia ser efectuado este planeamento no caso da DGD.

A dimenso do projecto da DGD implicou um esforo aprecivel, e um
nmero de recursos tcnicos e humanos elevado. A partir do conjunto
de funcionalidades identificadas, foi aplicado um modelo de estimativa
de custos baseado no COCOMO II (para o leitor mais interessado,
recomenda-se a leitura de [Bohem00]), e constatou-se que a durao
global estimada ultrapassaria os trs anos de desenvolvimento, com
uma equipa que atingiria no mximo 60 elementos. Estas estimativas
permitiram tambm rever os custos financeiros do projecto.
Dado o prazo global estimado, optou-se por disponibilizar o sistema de
forma incremental, completamente funcional em cada verso. Foram
definidos trs ciclos, de acordo com a seguinte lgica:
Primeiro ciclo: Implementao de todas funcionalidades de natu-
reza operacional realizadas pelo pessoal da DGD, com substituio
completa de todos os sistemas existentes. A estimativa apontava
para um ano e meio de durao.
CAPTULO 10 METODOLOGIA RUP 335


Segundo ciclo: Implementao de todas funcionalidades relaciona-
das com a gesto integrada de canais alternativos para o contacto
com o cliente, nomeadamente Internet e telefone. A estimativa
apontava para um ano de durao.
Terceiro ciclo: Implementao de um sistema de informao de
gesto, a partir do qual os quadros da DGD poderiam extrair
informao agregada, estimativas, indicadores diversos, e fornecer
alguma dessa informao ao cidado. A estimativa de durao
deste ciclo apontava para meio ano.
A deciso sobre as funcionalidades a implementar em cada ciclo foi
baseada em critrios de urgncia das mesmas e em questes bvias de
precedncia: em nenhuma circunstncia possvel obter informao de
gesto, sem que a informao de natureza operacional esteja disponvel.
Plano para o Primeiro Ciclo
Depois destas decises, o prximo passo elaborar um plano para o
primeiro ciclo, o que envolve a definio de:
Durao e esforo de cada fase.
Nmero de iteraes em cada fase.
Durao de cada iterao.
Estas decises so sempre tomadas com base na informao espe-
cfica de cada projecto, processada pelo modelo de estimativa de cus-
tos, que tem em conta dados histricos. Estes mesmos dados indicam
que, em termos mdios, o esforo e a durao tpicas de cada fase obe-
decem a um padro que pode ser observado na Tabela 10.1 [Kruchten00].


Fase Durao Esforo
Concepo 10% 5%
Elaborao 30% 20%
Construo 50% 65%
Transio 10% 10%
336 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Tabela 10.1: Padro da durao e esforo relativos das fases do RUP
No entanto, o RUP prev a aplicao de alguns factores de correco
consoante se verifiquem ou no determinadas situaes, algumas das
quais ocorrem neste projecto:
Dado o tipo de cultura existente na DGD, a diversidade de pessoas
(e de interesses) com que era necessrio contactar, a determinao
do mbito do projecto seria previsivelmente uma actividade difcil.
Nestas circunstncias, aumentou-se a durao e o esforo relativos
da fase de concepo.
Como na DGD no existe qualquer noo de arquitectura, os riscos
do projecto so elevados e os recursos humanos apresentam
lacunas importantes ao nvel da tecnologia a utilizar, a durao
relativa da fase de elaborao foi aumentada.
Como no processo de migrao seria necessrio substituir um
conjunto elevado de aplicaes em ambientes muito distintos, a
durao relativa da fase de transio foi tambm aumentada.

No segundo ciclo, e como os principais problemas (riscos do projecto,
definio da arquitectura) j esto resolvidos, a situao precisamente
ao contrrio, isto , a durao e o esforo relativos das fases de com-
cepo e de elaborao deve ser reduzida.

Assim, para o primeiro ciclo deste projecto utilizar-se-iam as seguintes
grandezas:


Fase Durao
Relativa
Esforo
Relativo
Durao
Absoluta
(em dias)
Concepo 15% 10% 54
Elaborao 35% 30% 126
Construo 35% 45% 126
CAPTULO 10 METODOLOGIA RUP 337


Transio 15% 15% 54
Tabela 10.2: Proposta da durao e esforo relativos das fases do
primeiro ciclo do RUP no caso da DGD.
Durao e Nmero de Iteraes
A recomendao do RUP aponta para que a durao de uma iterao
se situe entre 2 a 6 semanas, mas bvio que tal depende de cada
projecto. Os dados histricos permitem afirmar que este valor depende
essencialmente do nmero de pessoas envolvidas, do nmero de linhas
de cdigo a produzir, da familiaridade de toda a equipa com o processo
de desenvolvimento iterativo, do nvel de automatizao. Kruchten
disponibiliza indicadores de estimativa da durao de uma iterao, em
funo quer do nmero de linhas de cdigo a desenvolver, quer do
nmero de pessoas [Kruchten00].

Linhas de
Cdigo
Nmero de
Pessoas
Durao de
uma iterao
5000 4 2 semanas
20000 10 1 ms
100000 40 3 meses
1000000 150 8 meses
Tabela 10.3: Durao de uma iterao em funo de outros factores.
Se bem que estes dados no possam ser aplicados de forma
indiscriminada, podem ser considerados uma boa referncia. No caso
da DGD, foram utilizados para identificar a durao de cada iterao
(Tabela 10.4).
Fase Durao das
Iteraes
Nmero de
Iteraes
Concepo 3 meses 1
338 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Elaborao 3 meses 2
Construo 2 meses 3
Transio 5 semanas 2
Tabela 10.4: Durao e nmero de iteraes no caso da DGD.
Com estes dados a previso relativamente ao nmero de iteraes
tornou-se relativamente fcil:
Uma iterao preliminar, para a fase de concepo, que no
produziria nenhum produto final funcional, mas em que a
preocupao principal era a identificao e resoluo dos principais
riscos do projecto. Dada a sua dimenso, era de esperar que a
resoluo de alguns destes riscos pudesse implicar a tomada de
decises importantes, a nvel poltico, e da a durao da iterao. A
obteno de uma viso detalhada, para alm de permitir identificar
os riscos do projecto, possibilitaria ainda a elaborao de prottipos
pontuais para avaliao de alguns riscos (de natureza tecnolgica).
No entanto, neste momento do processo, natural que muitos dos
riscos sejam de natureza humana e de negcio, e menos de
natureza tcnica.
Na fase de elaborao, e uma vez que no existe qualquer noo de
arquitectura, e tendo em conta a falta de preparao do tipo de
recursos envolvidos, foi decidida a realizao de duas iteraes.
Esta estratgia tem como vantagem poder elaborar um prottipo
funcional, que elimina parte significativa dos riscos logo na primeira
iterao desta fase, e cujos erros de arquitectura podero ser
corrigidos durante a segunda. Alm disso, o contacto com uma
interface visual do sistema, se bem que ainda de reduzido detalhe,
durante a primeira iterao, ajudar os utilizadores a especificar
melhor o sistema durante a segunda iterao.
Na fase de construo, tal como apresentado por omisso pelo
RUP, esto previstas trs iteraes, as duas primeiras essencial-
mente concentradas na implementao dos componentes do sis-
tema, e a terceira mais direccionada para os testes e integrao do
mesmo.
Na fase de transio, e dada a complexidade da migrao, esto
previstas duas iteraes, a ltima das quais quase exclusivamente
concentrada em actividades de migrao do sistema.
CAPTULO 10 METODOLOGIA RUP 339


Como resultado desta iterao, obtm-se uma viso inicial do mbito
do projecto, o business case do mesmo e um plano do projecto
(plano das fases). Uma das principais novidades do RUP em relao
maioria das metodologias que se aplicam a todo o processo de
desenvolvimento que o RUP reconhece que as estimativas iniciais do
plano do projecto so aproximadas e devem ser continuamente refina-
das.
Primeira Iterao da Fase de Elaborao
No incio desta iterao, deve ser elaborado o respectivo plano,
actividade que como vimos pertence ao workflow de Gesto de
Projectos. A elaborao do plano de qualquer iterao deve seguir os
seguintes passos:
Identificar critrios objectivos para o sucesso da iterao.
Identificar os artefactos a produzir ou alterar de forma a garantir o
sucesso.
Identificar as actividades do RUP que devem ser realizadas para
produzir os artefactos.
Utilizar estimativas para identificar a durao e o esforo de cada
actividade.
Nas iteraes da fase de elaborao, os principais factores a ter em
conta para o respectivo sucesso so riscos, cobertura de requisitos e
criticidade. Os riscos assumem um papel fundamental, pelo que deve-
ro estar previstas actividades durante esta iterao para os eliminar.

340 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Por exemplo, no caso da DGD a disponibilizao de documentos
digitalizados, atravs de tecnologias Internet, poderia apresentar
problemas de integrao graves, caso no fosse possvel integrar o
sistema de gesto operacional e as tecnologias de gesto documental.
Por isso, foi previsto um cenrio para verificar esta integrao, atravs
do desenvolvimento de um prottipo.
A criticidade significa que devero ser consideradas actividades para
detalhar as principais funcionalidades do sistema.
No caso da DGD, elas incluiriam todos os servios que esta presta
directamente ao cliente (pedidos de documentos, entrega de documen-
tos, servios de esclarecimento) e todas as actividades internas que so
necessrias para o suporte adequado desse servio. No entanto, os
processos contabilsticos e de gesto de recursos humanos poderiam
ser deixados para a segunda iterao da fase de elaborao.

A estratgia de anlise dos requisitos do sistema deve abordar primeiro
os problemas mais genricos, deixando para iteraes subsequentes
decises que envolvem demasiado detalhe.
Tendo estas orientaes em conta, e relativamente DGD, alguns
objectivos poderiam ser definidos para esta iterao:
Conceber o sistema de forma a permitir que mais de 1000
funcionrios em todo o pas possam estar simultaneamente no
sistema a registar pedidos de documentos, e que outros 2000
possam estar a consultar informao sobre processos existentes.
Este cenrio implicaria alguns testes de natureza tecnolgica, que
envolveriam a realizao de testes de volume de carga e tempos de
resposta para avaliar os aspectos de desempenho, disponibilidade e
escalabilidade do sistema.
Conceber o sistema de modo a eliminar a separao actualmente
existente entre a recepo dos documentos ao balco e a respectiva
introduo no sistema.
CAPTULO 10 METODOLOGIA RUP 341


Prever uma arquitectura que permita aos utilizadores terem um nvel
de desempenho aplicacional idntico (variao mxima entre 10%
em relao aos nveis mdios), independentemente da sua
localizao no pas. Este cenrio implicaria a realizao de testes ao
nvel da infra-estrutura tecnolgica de comunicaes.
Identificar e modelar todos os casos de utilizao que envolvam o
actor cidado. Apesar de termos colocado este objectivo em ltimo
lugar, ele o mais bvio de todos, uma vez que o objectivo da fase
de elaborao precisamente a identificao dos requisitos do
sistema, e era pressuposto da primeira iterao concentrar a sua
ateno em todos os processos que envolvessem o cidado.
A definio destes objectivos permite identificar as actividades a realizar
e elaborar o Plano da Iterao. A informao recolhida permite detalhar
ainda mais a Lista de Riscos, e rever o Plano das Fases iniciado du-
rante a fase de Elaborao.
De seguida, tomada uma deciso sobre quais os casos de utilizao
relevantes e que condicionaro o desenvolvimento da arquitectura
(actividade do workflow de requisitos).

No caso da DGD sero, claramente aqueles que esto relacionados
com a gesto das interaces com o cidado, como resumidamente se
apresenta na Figura 10.22.
342 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE


Figura 10.22: Casos de utilizao que envolvem o cidado.
Estes casos de utilizao devero ser descritos em detalhe, e a
informao obtida deve ser reflectida no Modelo de Casos de
Utilizao, no caso de se tratarem de requisitos funcionais, ou no
documento Especificao Suplementar, caso sejam de outra nature-
za.

No caso da DGD poderemos identificar outros requisitos que no so de
natureza funcional:
O nmero de utilizadores a introduzir informao no sistema pode
ser superior a 1000.
O nmero de utilizadores a consultar informao no sistema pode
ser superior a 2000.
O tempo de resposta a qualquer consulta no pode ser superior a 10
segundos.

CAPTULO 10 METODOLOGIA RUP 343


Com esta informao adicional, revisto o Plano da Iterao e a Lista
de Riscos, se assim se justificar. A partir dos casos de utilizao j
especificados, iniciada a concepo de um Prottipo da Interface do
Sistema, que apresentado aos utilizadores para recolher os seus
comentrios.

No caso da DGD a interface a desenvolver nesta iterao poderia
incluir:
Um ecr de registo de pedidos de documentos, com dados comuns
a qualquer documento. A partir deste ecr seriam apresentados
outros especficos para cada documento.
Um ecr de registo de pedidos de informao dos cidados.
Um ecr de consulta de informao sobre um cidado, com diversas
possibilidades de pesquisa.
Um ecr para registar os diversos pagamentos de taxas que o ci-
dado pode efectuar.
.

De seguida so iniciadas actividades do workflow de Anlise e
Desenho, nomeadamente identificar classes bvias, efectuar
prototipagem inicial dos subsistemas e analisar casos de utilizao
em detalhe. Estas actividades levam elaborao do Documento da
Arquitectura do Software e identificao das classes e objectos
correspondentes aos casos de utilizao desta iterao. Estas classes
so posteriormente refinadas, atravs da identificao das suas
responsabilidades, atributos e relaes. As classes consideradas do
ponto de vista da arquitectura como relevantes so includas no
Documento da Arquitectura do Software. Finalmente criada a
hierarquia de conceitos associados s classes: estas so atribudas a
pacotes e estes a subsistemas.

344 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

No caso da DGD as classes mais importantes e que imediatamente
podem ser identificadas como condicionantes de toda a arquitectura
sero as de Cidado, Documento (e suas subclasses) e Operaes.

As actividades do workflow de Anlise e Desenho continuam com o
refinamento da arquitectura, que ajustada ao ambiente de
implementao seleccionado (sistemas operativos, bases de dados,
servidores aplicacionais, etc). Atravs de diagramas de interaco
modelada a forma como as classes so instanciadas em objectos, pela
descrio de como os casos se utilizao ou cenrios seleccionados
so realizados em termos de objectos que interagem entre si. Os
requisitos de desenho de cada objecto so reflectidos nos diagramas de
interaco, que por sua vez condicionaro a definio das interfaces
das classes, havendo pois a necessidade de rever a viso lgica do
sistema.
Finalmente, so pela primeira vez analisadas as questes relacionadas
com a distribuio dos componentes da arquitectura, com o
processamento e com a infra-estrutura tecnolgica. De modo a
garantir a consistncia de todo o modelo, a arquitectura revista.
As actividades seguintes pertencem ao workflow de Implementao:
Anlise da implementao da arquitectura em termos fsicos,
definindo a viso de implementao.
Planeamento da sequncia da implementao dos subsistemas, de
modo a que possam ser integrados num prottipo da arquitectura.
De seguida efectuado o planeamento dos testes de integrao e de
sistema, que so actividades previstas no workflow de Testes, sendo
produzido o Plano de Testes. So tambm descritos os testes a
efectuar, quer em termos de valores quer de procedimentos.
Procede-se implementao das classes e respectiva integrao
(workflow de Implementao), o que efectuado de forma incremental.
A arquitectura final, correspondente ao sistema final previsto nesta
iterao (que, recorde-se, um sistema funcional mas incompleto),
CAPTULO 10 METODOLOGIA RUP 345


testada (workflow de Testes) e os resultados so analisados de forma a
garantir que os objectivos dos testes foram atingidos. O prottipo
apresentado aos utilizadores para recolha de comentrios e de suges-
tes.
A iterao termina com a avaliao dos resultados obtidos,
nomeadamente a comparao do trabalho realizado com o previsto (em
termos de prazos e custos). Em funo do trabalho identificado como
sendo necessrio realizar, pode-se planear mais adequadamente a
iterao seguinte. A Lista de Riscos e o Plano de Projecto podero
ser revistos.
Primeira Iterao da Fase de Construo
Para a fase de construo, os principais objectivos deixam de ser
condicionados pelos riscos do projecto, mas sobretudo pela garantia de
implementao dos casos de utilizao. O planeamento deve reflectir a
respectiva criticidade, devendo ser implementados em primeiro lugar os
casos de utilizao mais crticos, de modo a possibilitar a sua
verificao mais cedo e em vrias iteraes da fase de construo.

No caso da DGD, para a primeira iterao da fase de construo
deveriam ser seleccionados os seguintes casos de utilizao:
Entrega de documentos pelo cidado.
Pedido de informao do cidado.

Poderamos (e, num caso concreto, deveramos) continuar com a
anlise das restantes iteraes. No entanto, quer por questes de
espao, quer pelo detalhe em que cada vez mais nos envolvemos
medida que avanamos no processo RUP, com a necessidade de
definir vrias questes de natureza tecnolgica, optmos por terminar o
exemplo neste ponto. Esperemos que em projectos da vida real o leitor
no faa o mesmo!
346 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE


10.10 Concluso
Neste captulo apresentou-se uma panormica geral sobre o Rational
Unified Process, RUP, que dada a sua dimenso e complexidade foi
necessariamente incompleta. No entanto, esta descrio transmite ao
leitor as caractersticas e conceitos bsicos da metodologia, a forma
como est organizada e como pode ser aplicada.
Apesar da quantidade de conceitos, procurmos demonstrar com um
exemplo credvel, como o RUP pode ser posto em prtica, dando relevo
s actividades realizadas e aos artefactos produzidos. Este exemplo
apresentava um grau de complexidade elevada, no s pela dimenso
do esforo a realizar, como tambm devido a todos os problemas de
natureza no tcnica que lhe estavam associados. precisamente nes-
te tipo de situaes que a abrangncia do RUP se revela particular-
mente til, uma vez que considera actividades para tratamento da maio-
ria destes problemas.
A complexidade do RUP no deve "assustar" o leitor e desmotiv-lo na
adopo do mesmo como metodologia de desenvolvimento a aplicar de
forma sistemtica. Como dissemos no incio deste captulo, o RUP um
framework metodolgico muito completo, que pode e deve ser adaptado
ou instanciado realidade concreta de diferentes organizaes e tipos
de projecto. Os prprios proponentes do RUP assim o entendem, para
alm de outros autores, tais como Martin Fowler [Fowler00] e Gary
Evans [Evans01].
O trabalho futuro ser naturalmente a definio e proposta de instncias
do RUP, ou seja, de metodologias baseadas no RUP, mas mais
simples, mais especializadas e, por conseguinte, melhor adaptadas a
distintas organizaes e a diferentes tipos de projectos. , na nossa
opinio, perfeitamente aceitvel o aparecimento, a curto e/ou mdio
prazo, de processos "baseados no RUP", que possam "competir"
favoravelmente com o conjunto de metodologias lightweight que esto a
ganhar adeptos junto da comunidade informtica, entre as quais se
destaca o ICONIX, que apresentado no captulo seguinte.
CAPTULO 10 METODOLOGIA RUP 347


10.11 Exerccios
Ex.71. Tendo em conta os seus conhecimentos sobre o RUP, quais so
os tipos de empresas que maior partido podero tirar desta me-
todologia de desenvolvimento? Justifique a sua afirmao
Ex.72. Complete o diagrama de casos de utilizao apresentado na
Figura 10.22, relativamente ao actor Cidado.
Ex.73. Relativamente metodologia de desenvolvimento RUP, aplicam-
se normalmente critrios uniformes para definir o tempo de
durao da fase de concepo, em funo de experincias do
passado, e introduzem-se alguns factores de ajustamento que
podem aumentar ou diminuir esse tempo. Para alm dos fac-
tores referidos no livro, indique outros que na sua opinio pode-
ro influenciar os valores das referidas estimativas.
Ex.74. Identifique quais os principais riscos que o projecto poder
apresentar, e proponha algumas medidas de correco.
Ex.75. Elabore o diagrama de classes simplificado referente ao caso de
estudo apresentado.
Ex.76. Imagine o desenvolvimento de um sistema de informao de
complexidade relativamente baixa, cuja durao total no exce-
deria trs meses. Seria possvel (e desejvel) aplicar o RUP?
Em caso afirmativo, que alteraes (ou adaptaes) introduziria?
Ex.77. O RUP refere que a aplicao do workflow de modelao do
negcio opcional. Em que circunstncias que recomendaria
a sua incluso num projecto de desenvolvimento de software.

348 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE




Captulo 11 - METODOLOGIA ICONIX
Tpicos
Introduo
Viso Geral
Avisos da Metodologia Iconix
Enunciado do Caso de Estudo WebDEI
Resoluo do Caso de Estudo WebDEI
Concluso


11.1 Introduo
O ICONIX uma metodologia de desenvolvimento de software
promovido pela empresa ICONIX Software Engineering, cujo foco de
negcio reside na formao e produo de material para educao em
tecnologias de objectos, em particular em CORBA, COM, Java e UML.
O principal evangelista do ICONIX Doug Rosenberg, autor do livro
Use Case Driven Object Modeling with UML: A Practical Approach
[Rosenberg99] com base no qual este captulo foi desenvolvido. Est
prevista a edio de um novo livro dos mesmos autores, intitulado
Applied Use Case Driven Object Modeling, para o princpio do
segundo trimestre de 2001. (Mais informaes sobre o ICONIX e res-
pectivos servios e produtos podem ser obtidas em www.iconixsw.com)
350 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

O ICONIX define-se como um processo de desenvolvimento de
software prtico, algures entre a complexidade e abrangncia do RUP
(Rational Unified Process) e a simplicidade e o pragmatismo do XP
(Extreme Programming).
O ICONIX conduzido por casos de utilizao, iterativo e incremental,
tal como o RUP, mas sem a complexidade que este preconiza. Por
outro lado, relativamente pequeno e simples, tal como o XP, mas sem
eliminar as tarefas de anlise e de desenho que aquele no contempla.
Por fim, o ICONIX usa o UML como linguagem de modelao e apre-
senta um alto grau de rastreabilidade
1
(traceability).
Discutimos neste captulo os principais aspectos do ICONIX, primeiro
segundo a apresentao da sua viso geral, e seguidamente atravs da
sua aplicao na modelao do caso de estudo WebDEI. O WebDEI
consiste num sistema de informao Web a quatro camadas, desen-
volvido exclusivamente com tecnologia Java.
11.2 Viso Geral
O ICONIX uma metodologia de desenvolvimento de software,
englobando as seguintes tarefas principais: (1) anlise de requisitos; (2)
anlise e desenho preliminar; (3) desenho; e (4) implementao, confor-
me se introduz sumariamente de seguida.
A metodologia consiste na produo de um conjunto de artefactos que
retratam as vises dinmica e esttica de um sistema, e que vo sendo
desenvolvidos incrementalmente e em paralelo, os modelos da esttica
e os modelos da dinmica.
A Figura 11.1 ilustra a viso geral do ICONIX. Esta figura revela um
aspecto importante da utilizao do UML: o facto da implementao de
um sistema apenas depender da verso detalhada do diagrama de

1
Rastreabilidade a capacidade de se seguir as relaes entre os diferentes
artefactos produzidos no processo de desenvolvimento de software, de forma a
poder-se averiguar, por exemplo, o impacto que uma determinada alterao de
um requisito tem em todos os restantes artefactos (modelos de anlise, dese-
nho, e mesmo de implementao).
CAPTULO 11 METODOLOGIA ICONIX 351


classes final. (Parece bvio, mas muitos indivduos pensam ainda que
se poderiam usar, por exemplo, diagramas de sequncia para gerar
cdigo automaticamente!)

Figura 11.1: Viso geral do ICONIX.
11.2.1 Anlise de Requisitos
A tarefa de anlise de requisitos consiste na realizao das seguintes
actividades (ver Figura 11.2):
Identificar os objectos do mundo real e todas as relaes de
generalizao, associao e agregao entre esses objectos. De-
senhar o correspondente diagrama de classes de alto nvel, desig-
nado por modelo de domnio.
Se for razovel (e.g., se for pertinente ou se houver oramento para
tal actividade), desenvolver prottipos de interface homem-mquina
(GUI), diagramas de navegao, etc., de forma que os utilizadores e
clientes possam entender melhor o sistema pretendido.
Identificar os casos de utilizao envolvidos no sistema. Desenhar
os diagramas de casos de utilizao realando os actores envolvi-
dos e as suas relaes.
352 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Organizar em grupos os casos de utilizao. Capturar essa organi-
zao atravs de diagramas de pacotes (packages).
Associar requisitos funcionais aos casos de utilizao e aos objectos
do domnio.

Figura 11.2: ICONIX Actividades da tarefa de anlise de requisitos.
Observao: O ICONIX distingue explicitamente um requisito de um
caso de utilizao. Em particular, o seu autor distingue-os da seguinte
forma:
Um caso de utilizao descreve uma unidade de comportamento.
Um requisito descreve uma regra que governa o comportamento.
Um caso de utilizao satisfaz um ou mais requisitos funcionais.
Um requisito funcional pode ser satisfeito por um ou mais casos de
utilizao.
CAPTULO 11 METODOLOGIA ICONIX 353


Ou seja, segundo o ICONIX, h uma relao de muitos-para-muitos
entre casos de utilizao e requisitos, pelo que tem sentido a ltima
actividade desta tarefa, de associao entre estes dois conceitos. Note-
se que existem outros autores que consideram, por outro lado, os casos
de utilizao o mecanismo ideal para se especificarem os prprios
requisitos de um sistema. (Esta relao entre casos de utilizao e
requisitos um assunto em discusso na comunidade OO, no exis-
tindo at ao momento qualquer consenso.)
11.2.2 Anlise e Desenho Preliminar
A tarefa de anlise e desenho preliminar consiste na realizao das
seguintes actividades (ver Figura 11.3):
Fazer as descries dos casos de utilizao com os cenrios princi-
pais, cenrios alternativos e cenrios de excepes.
Fazer a anlise de robustez. Para cada caso de utilizao:
Identificar um primeiro conjunto de objectos. Usar os esteretipos
de classes definidos no perfil Processos de Desenvolvimento de
Software especificado no UML 1.3 (boundary, control, e entity).
Actualizar o diagrama de classes do modelo do domnio, com os
novos objectos e atributos entretanto descobertos.
Terminar a actualizao do diagrama de classes de modo a reflectir
a concluso da fase de anlise.
354 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE


Figura 11.3: ICONIX- Actividades da tarefa de anlise e desenho
preliminar.
11.2.3 Desenho
A tarefa de desenho consiste na realizao das seguintes actividades
(ver Figura 11.4):
Especificar o comportamento. Para cada caso de utilizao:
Identificar os objectos, as mensagens trocadas entre objectos e
os mtodos associados que so invocados. Desenhar um diagra-
ma de sequncia com o texto do caso de utilizao do lado es-
querdo, e informao do desenho do lado direito. Continuar a
actualizar o diagrama de classes com os objectos e atributos en-
tretanto descobertos.
Se for relevante, usar diagrama de colaborao para ilustrar as
transaces principais entre objectos.
Terminar o modelo esttico, adicionando informao detalhada so-
bre o desenho (e.g., visibilidade e padres de desenho)
Verificar que o desenho satisfaz todos os requisitos identificados.
CAPTULO 11 METODOLOGIA ICONIX 355



Figura 11.4: ICONIX Actividades da tarefa de desenho.
11.2.4 Implementao
A tarefa de implementao consiste na realizao das seguintes activi-
dades (ver Figura 11.5):
Consoante as necessidades, produzir diagramas de arquitectura,
tais como, diagramas de instalao e de componentes, que apoiem
a tarefa de implementao.
Escrever e, eventualmente, gerar o cdigo.
Realizar testes unitrios e de integrao.
Realizar testes de sistema e de aceitao do utilizador.
356 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE


Figura 11.5: ICONIX Actividades da tarefa de implementao.
11.3 Avisos do Processo ICONIX
O ICONIX lana um conjunto de avisos relativamente a problemas e d-
vidas comuns, que devero ser tidos em conta pelos intervenientes do
processo.
Os avisos relacionados com a realizao da tarefa de anlise de
requisitos tm como principal objectivo evitar a perda de tempo com de-
talhes desnecessrios. Designadamente:
Na produo dos modelos de domnio:
No perder demasiado tempo com a inspeco gramatical.
No enderear o desenho da multiplicidade demasiado cedo no
projecto.
Enderear a agregao e composio apenas na fase do de-
senho detalhado.
Na produo dos modelos de casos de utilizao:
No comear a escrever os casos de utilizao at se conhecer
bem como que os utilizadores iro actuar.
No passar semanas a construir modelos de casos de utilizao
elaborados e bem desenhados, mas a partir dos quais no
possvel construir-se um adequado desenho de classes.
CAPTULO 11 METODOLOGIA ICONIX 357


No perder muito tempo em discusses sobre quando e onde
usar relaes include ou extend.
No usar templates textuais de casos de utilizao muito longos
ou complexos.
Avisos a ter em conta na realizao da tarefa de anlise e desenho
preliminar:
No procurar fazer desenho detalhado nos diagramas de robus-
tez
No perder tempo a tentar aperfeioar os diagramas de robustez
medida que o desenho evolui.
Avisos a ter em conta na realizao da tarefa de desenho:
Na produo dos diagramas de sequncia:
No procurar associar comportamento aos objectos antes de se
ter um ideia concreta sobre o seu significado e interesse para o
sistema.
No comear a desenhar um diagrama de sequncia antes de se
ter completado o diagrama de robustez correspondente.
No focar a ateno (e esforo) na definio de mtodos get e
set em detrimento dos mtodos reais. (Estes mtodos de aces-
so e alterao dos atributos podem ser facilmente gerados auto-
maticamente a partir de uma ferramenta CASE.)
Na produo dos diagramas de estado:
No desenhar diagramas de estados para objectos com apenas
dois estados.
No modelar o que no necessrio modelar.
No desenhar diagramas de estados s porque se consegue
desenh-los.
11.4 Enunciado do Caso de Estudo WebDEI
O caso de estudo WebDEI consiste num sistema de informao Web
para gerir alguns processos de negcio de um departamento de
engenharia informtica de uma instituio de ensino superior, que
passaremos a designar apenas por DEI, e o respectivo sistema de
358 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

informao por WebDEI. Considere-se que tanto o DEI como o
WebDEI so realidades fictcias e que o WebDEI aqui apresentado ,
por motivos didcticos, uma natural simplificao da realidade.
Descreve-se de seguida, de forma propositadamente pouco estruturada,
os requisitos e arquitectura do WebDEI, assim como o modelo de dados
e a funcionalidade pretendida.
Pede-se que o leitor desenvolva o referido sistema por aplicao do
processo ICONIX. (Ou que pelo menos reflicta sobre o seu processo de
desenvolvimento.) As tarefas mais importantes contempladas neste livro
referem-se fase de concepo, em particular s tarefas de identifica-
o de requisitos, de anlise e de desenho.
11.4.1 Introduo
O DEI tem por misso promover, organizar e realizar actividades de
ensino (licenciaturas, mestrados, doutoramentos, ps-graduaes, cur-
sos e/ou seminrios de curta durao, de carcter profissionalizante),
de investigao e de desenvolvimento, bem como actividades de com-
sultoria ligadas ao tecido social e econmico.
Integram o DEI um conjunto de membros docentes, os quais pertencem
a reas cientficas. Cada rea cientfica coordenada por um professor
e constituda por vrios docentes (professores e assistentes).
Adicionalmente, a rea cientfica atribudo um conjunto de disciplinas,
pelo qual responsvel, que podem ser leccionadas em diferentes li-
cenciaturas ou outros tipos de cursos.
O DEI ainda responsvel pela promoo e organizao de diversos
eventos de carcter cientfico e profissional bem como por promover
mecanismos de disseminao automtica de informao.
11.4.2 Arquitectura Geral
Nesta seco so descritos os aspectos bsicos da arquitectura do
WebDEI. As questes em aberto devero ser alvo de reflexo do leitor
de modo a tomar as suas decises fundamentadamente. O sistema
CAPTULO 11 METODOLOGIA ICONIX 359


deve funcionar num ambiente aberto e distribudo, como a Internet, de
acordo com a arquitectura geral conforme ilustrado na Figura 11.6.

Figura 11.6: Arquitectura geral do WebDEI.
O WebDEI apresenta uma arquitectura a quatro camadas, a primeira
das quais caracterizada pelo cliente Web, com capacidades de
apresentao de pginas HTML; a segunda camada consiste em
componentes servlets Java (executadas no contexto de um servidor
Web) que produzem pginas HTML dinamicamente; a terceira camada
consiste no servidor aplicacional Java, que mantm a lgica dos
processos e medeia o acesso base de dados; e por fim, a quarta
camada consiste num sistema de gesto de base de dados, respon-
svel pela operao da base de dados envolvida.
Assume-se que todas as comunicaes entre os utilizadores e a
mquina do servidor so efectuadas via HTTP; que a comunicao
entre os servlets e o servidor Java se realiza via Java RMI (Remote
Method Invocation); e que a comunicao entre o servidor Java e o
gestor da base de dados se realiza via JDBC (Java Data Base
Connectiviy).
Utilizadores/Actores
O WebDEI deve suportar os seguintes tipos de utilizadores:
360 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Utilizador annimo: Conjunto de utilizadores no registado no
sistema, i.e., pblico em geral. Estes utilizadores apenas tm acesso
a informao que lhes transmitida atravs de documentos HTML.
Estes documentos so mantidos e/ou gerados por um programa
associado ao servidor Web. Tipicamente, os documentos gerados
devero corresponder a informao que no seja crtica e confiden-
cial como por exemplo: consulta de informao sobre reas cientfi-
cas, sobre docentes, sobre disciplinas, etc.
Docente: Utilizadores que acedem ao sistema atravs de pginas
HTML geradas dinamicamente (pelos servlets). Podem configurar a
sua pgina pessoal atravs de um formulrio que lhes apresen-
tado. Podem registar eventos/notcias. Podem receber informao
periodicamente.
Gestor: Utilizadores responsveis pela gesto e configurao da
informao do sistema. Estes acedem ao sistema localmente.
Tipicamente, os gestores so responsveis pela gesto (assume-se
as operaes usuais de introduo, remoo e alterao) de
utilizadores, reas cientficas, disciplinas, docentes, etc. So ainda
responsveis pela gesto de todos os parmetros de configurao
envolvidos (e.g., definio da periodicidade do envio automtico de
informao de eventos/notcias).
11.4.3 Tipos Bsicos de Informao (Modelo de Dados)
A base de dados deve ser gerida por um SGBD relacional, sendo
acedida via JDBC. Considere, pelo menos, os seguintes tipos bsicos
de informao, que devero ser mantidos na BD do sistema. (Note-se
que PK denota Primary Key)
rea Cientfica
identificao da rea cientfica (PK)
informao geral: nome, objectivos, link para pgina especfica
Curso
identificao do curso (PK)
sigla, nome, logtipo
objectivos
Docente
identificao do docente (PK)
CAPTULO 11 METODOLOGIA ICONIX 361


nome, morada, link para Web site pessoal, e-mail
grau acadmico (e.g., licenciatura, mestrado, doutoramento)
grau na carreira (e.g., ASG, AST, PAX, PAS, PCT)
informao para autenticao: login, pwd
recebe evento automaticamente (sim/no)
mecanismo de recepo dos eventos (e-mail/SMS)
Disciplina
identificao da disciplina (PK)
identificao do curso, sigla
nome, logtipo
identificao da rea cientfica
identificao do docente responsvel
link para website da disciplina
Eventos
identificao de evento (PK)
informao geral: ttulo, data registo/anncio, data incio, data fim
de validade
identificao do membro (que regista o evento)
descrio do evento/notcia, url para mais detalhes
tipo de evento
mbito de disseminao (privado, pblico)
11.4.4 Funcionalidade do Sistema
Disseminao automtica de informao
Qualquer docente pode registar eventos/notcias, sendo relevantes a
data em que o evento dever ser divulgado (data incio) bem como a
sua data de validade (i.e., a data a partir da qual, a sua divulgao
dever cessar). Adicionalmente, indica o mbito de disseminao: se ao
pblico geral ou se apenas restrito aos docentes.
A divulgao desses eventos realizada por duas formas complemen-
tares. Por um lado, por consulta dos detalhes dos eventos/notcias
362 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

numa determinada zona do WebDEI atravs de pginas HTML ou WAP.
Por outro lado, por disseminao, i.e., por envio de mensagens, sejam
elas de e-mail ou SMS (short message service), salvaguardando-se
necessariamente as questes de acessibilidade. Apenas devero
encontrar-se publicados eventos cujo perodo de validade no tenha
expirado. A disseminao de informao de eventos por mensagem
consiste no envio peridico (e.g., mensal, parmetro a configurar) de
uma mensagem que resume os eventos vlidos para esse perodo.
Apenas devem ser enviadas mensagens aos docentes que tenham
assinalado esse desejo.
Operaes Providenciadas pelo Sistema
O WebDEI dever providenciar vrias operaes tpicas de aplicaes
congneres. Descreve-se com as letras A, D e G os tipos de acessos
correspondentes aos utilizadores referidos anteriormente (respectiva-
mente Annimo, Docente e Gestor). Todos os utilizadores usam uma
interface baseada em HTML (esttico ou gerado dinamicamente).
Consultas Gerais
Qualquer utilizador (annimo ou docente) pode consultar a informao
descrita acima. A ttulo de exemplo, enumeram-se algumas das com-
sultas tpicas a suportar (com a assinatura dos mtodos suportados pelo
servidor aplicacional).
Obter a lista de todas as reas cientficas (A,D)
Enumeration obterAreasCientificas()
Obter a lista de todas as disciplinas de uma rea cientfica (A,D)
Enumeration obterDisciplinasArea (int
idAreaCientifica)
Obter a lista de todos os docentes de uma rea cientfica (A,D)
Enumeration obterDocentes(int idAreaCientifica)
Obter a lista de todas as disciplinas de um curso (A,D)
Enumeration obterDisciplinasCurso (int idCurso)
Informaes gerais sobre um docente (A,D)
Object obterDocente(int idDocente)
Informaes gerais sobre uma disciplina (A,D)
CAPTULO 11 METODOLOGIA ICONIX 363


Object obterDisciplina(int idDisciplina)
Todos os eventos disponveis (A,D)
Enumeration obterEventos (int idMembro)
Todos os eventos disponveis, de acesso restrito a docentes (D)
Enumeration obterEventosPrivadosDocentes()
Esta informao ser enviada automaticamente por correio electrnico
para todos os membros do DEI (que tenham obviamente endereo de e-
mail).
Gesto de reas cientficas, cursos, docentes, disciplinas e
membros-utilizadores
Operaes realizadas pelo gestor do WebDEI: considere-se apenas
operaes de introduo e remoo. A ttulo de exemplo devero ser
suportadas as seguintes operaes (G).
int adicionaAreaCientifica(AreaCientifica
areaCientifica)
int adicionaCurso(Curso curso)
int adicionaDocente(Docente docente)
int adicionaDisciplina(Disciplina disciplina)
int adicionaMembro(Membro membro)
Esta informao dever estar necessariamente correlacionada. Por
exemplo devero existir outros mtodos para criarem associaes entre
reas cientficas e disciplinas, ou entre reas cientficas e docentes.
Outras operaes
Cada docente (D) dever poder actualizar a sua ficha pessoal. Esta
funcionalidade corresponder gerao e tratamento de um formulrio
HTML correspondente.
Todos os docentes (D) podem registar eventos numa rea definida para
o efeito.
int adicionaEvento(Objecto evento)
364 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

11.5 Resoluo do Caso de Estudo WebDEI
Apresenta-se de seguida a aplicao do processo ICONIX ao caso de
estudo WebDEI, conforme apresentado informalmente na seco ante-
rior.
11.5.1 Anlise de Requisitos
Modelo do Domnio: Diagrama de Classes de Alto Nvel
Esta primeira actividade consiste na identificao de todos os objectos
do mundo real e de todas as relaes de generalizao, associao e
agregao existentes entre esses objectos. O resultado desta actividade
o correspondente diagrama de classes de alto nvel. Em geral, as
melhores formas para o desenvolvimento desta actividade consistem (1)
na leitura e interpretao de documentos, caso existam, que contenham
o problema e os requisitos de alto nvel; e (2) na realizao de um
conjunto restrito de entrevistas com utilizadores e peritos do domnio do
problema.
Identificao das Classes
Considere-se para o efeito, o seguinte extracto de texto relativo
especificao do sistema WebDEI. Uma prtica comum consiste em
sublinhar os nomes e substantivos, que correspondem a candidatos a
classes (ou nalguns casos, a atributos) no modelo do domnio a conce-
ber.

O DEI tem por misso promover, organizar e realizar actividades de
ensino (licenciaturas, mestrados, doutoramentos, ps-graduaes,
cursos e/ou seminrios de curta durao, de carcter
profissionalizante), de investigao e de desenvolvimento, bem como
actividades de consultoria ligadas ao tecido social e econmico.
O DEI constitudo por um conjunto de membros docentes, os quais se
encontram organizado em reas cientficas. Cada rea cientfica
CAPTULO 11 METODOLOGIA ICONIX 365


liderada por um professor e constituda por vrios docentes
(professores e assistentes). Adicionalmente, cada rea cientfica
responsvel explicitamente por um conjunto de disciplinas que podem
ser leccionadas em diferentes licenciaturas ou outros tipos de cursos.
O DEI responsvel ainda pela promoo e organizao de diversos
eventos de carcter cientfico e profissional bem como por promover
mecanismos de disseminao automtica de informao.

Atente-se em alguns dos problemas que este texto levanta. Por
exemplo:

Nome do sistema: e.g., DEI: o nome do sistema organizacional
onde se encontra o sistema computacional WebDEI. Por com-
seguinte, por definio, nunca se deve representar atravs de uma
classe todo ou parte do sistema que se pretende tratar.
Nomes no relevantes ou demasiado vagos: e.g., tecido social e
econmico ou carcter cientfico e profissional; no so relevantes
para o sistema.
Sinnimos: e.g., actividade de ensino e curso so nomes alterna-
tivos; soluo: escolher uma alternativa e us-la consistentemente.
Falta de informao: e.g., qual a diferena entre um docente e um
professor? E entre um docente e um membro? Vamos assumir de
ora em diante que um professor um tipo particular de docente
que doutorado, e que todo o docente um utilizador registado
(membro) do WebDEI.
Falta de informao: e.g., licenciaturas, mestrados, doutora-
mentos, ps-graduaes, e cursos/seminrios rpidos de carc-
ter profissionalizante correspondem ou no ao mesmo conceito:
curso? Vamos assumir neste contexto que sim.
Como resultado da anlise do texto anterior, e tendo em conta a
discusso prvia, identificamos as seguintes classes: Utilizador,
Docente, GrauAcadmico, Curso, TipoCurso, AreaCientifica,
Disciplina, Evento, ActividadeID, ActividadeConsultoria.

366 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Identificao das Relaes
Com base nas classes acima enumeradas, o passo seguinte consiste
na identificao das relaes entre as mesmas, em particular as
relaes de generalizao e de associao. As generalizaes retratam
relaes de pai-filho ou de especializao de tipos entre as classes
envolvidas. As relaes de associao so captadas a partir de verbos
e expresses verbais identificadas no texto, bem como a partir do
conhecimento que existe sobre o domnio do problema. Ilustra-se de
seguida um extracto de texto com as formas verbais que devero
indiciar relaes de associao entre classes.
O DEI constitudo por um conjunto de membros docentes, os quais
pertencem a reas cientficas. Cada rea cientfica liderada por um
professor e constituda por vrios docentes (professores e assisten-
tes). Adicionalmente, cada rea cientfica responsvel explicitamente
por um conjunto de disciplinas que podem ser leccionadas em dife-
rentes licenciaturas ou outros tipos de cursos.

Para alm das classes anteriormente identificadas, introduziu-se neste
diagrama a classe ParmetrosConfigurao de modo a suportar
parmetros vrios do sistema, nomeadamente, a periodicidade da
disseminao de eventos.

CAPTULO 11 METODOLOGIA ICONIX 367



Figura 11.7: WebDEI Diagrama de classes de alto nvel.
Conforme ilustrado na Figura 11.7 no conveniente, nesta fase,
enderear os aspectos da (1) multiplicidade das relaes; (2) especificar
se as relaes so do tipo agregao ou composio; ou (3) especificar
as operaes das classes. Por outro lado, a especificao dos atributos
das classes j perfeitamente conveniente (embora no sejam
ilustrados na Figura 11.7 por motivos de legibilidade). Tais detalhes so
normalmente diferidos para a fase seguinte. A principal vantagem de
diferir a especificao desses detalhes para mais tarde, acelerar a
realizao da modelao do domnio e evoluir para as fases seguintes.
Prototipagem de GUI
O WebDEI um sistema com interface Web, pelo que neste contexto e
nesta fase pode fazer todo sentido o desenho do seu modelo de
navegao, o desenho de algumas pginas HTML representativas, e
ainda a especificao de guias de estilos de desenho que devero ser
adoptados consistentemente ao longo de todas as interfaces
368 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

produzidas. (Os detalhes desta actividade saem do mbito deste livro,
para mais informaes consulte-se por exemplo [Dix98].)
Diagramas de Casos de Utilizao
Esta actividade consiste na identificao da funcionalidade do sistema
na ptica dos seus utilizadores, o que passa pela identificao dos ac-
tores envolvidos, e pela estruturao dos casos de utilizao em
agrupamentos lgicos, atravs de diagramas de pacotes.

Figura 11.8: WebDEI Diagrama de pacotes.
A Figura 11.8 ilustra os diagramas de pacotes assim como os actores
identificados para o WebDEI. Definimos dois pacotes principais: o
pacote Gesto do WebDEI, que contm todos os casos que o gestor
dever realizar; e o pacote Utilizao do WebDEI, que contm todos
os casos que o utilizador annimo (UAnnimo) e o utilizador registado
(Udocente) devero realizar. Neste ltimo pacote, encontra-se
explicitado o actor Temporizador, necessrio para desencadear o caso
de utilizao associado disseminao automtica de eventos (ver
mais frente). Outro aspecto a destacar a relao de generalizao
entre os actores UAnnimo e UDocente, ou seja, o docente
encarado como uma especializao do utilizador annimo pelo facto de
herdar todas as funcionalidades especificadas atravs do respectivo
conjunto de casos de utilizao.
CAPTULO 11 METODOLOGIA ICONIX 369


As Figuras 11.9, 11.10 e 11.11 apresentam os casos de utilizao,
respectivamente, do gestor, do utilizador annimo e do docente do
WebDEI.

Figura 11.9: WebDEI Diagrama casos de utilizao do gestor.
370 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE


Figura 11.10: WebDEI Diagrama casos de utilizao do utilizador
annimo.
A Figura 11.10 ilustra os casos de utilizao especficos para o
utilizador annimo (e por herana, tambm para o utilizador-docente).
Note-se que, contrariamente ao apresentado na Figura 11.9 (que se
adoptou uma abordagem de derivao de casos de utilizao a partir de
um caso abstracto Gerir Informao), neste diagrama existe um caso
abrangente Consultar Informao Geral que usa a funcionalidade dos
diferentes tipos de consultas (e.g., de docentes, de cursos) atravs de
uma relao de incluso (esteretipo include)

Outra observao pertinente deve-se ao facto do ICONIX propor outros
tipos de relaes entre casos de utilizaes. Em vez de usar as
relaes include e extend (ver Captulo 5), o ICONIX prope a
utilizao de relaes do tipo precedes e invokes. (De qualquer
forma, no nos iremos alongar sobre esta discusso e manteremos nos
CAPTULO 11 METODOLOGIA ICONIX 371


exemplos seguintes as relaes clssicas propostas na especificao
oficial do UML.)
O caso Disseminao de Informao da Figura 11.11 consiste no
envio peridico de informao (ou de um resumo de informao) relativa
a todos os eventos que estejam no estado em divulgao. Este caso
desencadeado por aco da passagem de tempo, pelo que se
representa o actor Temporizador. Por outro lado, os beneficirios
deste caso de utilizao so os docentes (que tenham configurado
previamente o seu desejo de receberem tais mensagens peridicas).
Por fim, note-se a variabilidade deste caso ao permitir dois mecanismos
alternativos de envio das mensagens, por e-mail ou por SMS, o qual
representado por dois casos abstractos (i.e., Via E-mail e Via SMS)
que estendem o caso destino no seu ponto de extenso.


Figura 11.11: WebDEI Diagrama casos de utilizao do docente.

372 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Requisitos Funcionais
No ICONIX, tal como referido anteriormente, requisitos e casos de
utilizao so conceitos distintos, existindo uma relao de muitos-para-
muitos entre si.
A ttulo de exemplo, considere-se a seguinte lista, necessariamente
incompleta, de requisitos (leis que governam o comportamento do
sistema) do WebDEI:
R101: O presidente do DEI tem de ser um professor com categoria
acadmica catedrtico ou associado.
R102: O coordenador/responsvel por qualquer rea cientfica tem de
ser professor com categoria acadmica auxiliar ou superior.
R201: Apenas podem receber notificao de eventos os docentes que
tenham previamente assinalado o seu desejo, bem como
indicado qual o mecanismo de recepo desejado (E-mail ou
SMS).
R202: A periodicidade da disseminao dos eventos no pode ser
superior a trs meses e inferior a uma semana.
R203: Apenas os docentes podem submeter registo de eventos.

A Figura 11.12 ilustra a associao entre requisitos, casos de utilizao
e objectos do domnio, em particular entre o requisito R202, o caso de
utilizao Configurar WebDEI e a classe
ParmetrosConfigurao. Esta associao revela que o requisito
R202 tem impacto na descrio do caso Configurar WebDEI assim
como no comportamento da classe ParmetrosConfigurao.

CAPTULO 11 METODOLOGIA ICONIX 373



Figura 11.12: WebDEI Associao entre requisitos, casos de
utilizao e objectos do domnio.
11.5.2 Anlise e Desenho Preliminar
Detalhe dos Casos de Utilizao
A primeira actividade da tarefa de anlise e desenho preliminar consiste
em detalhar os casos de utilizao anteriormente identificados. Para tal,
so descritos textualmente todos os cenrios correspondentes a cada
caso de utilizao, sendo em geral contemplados os cenrios principais,
alternativos e de excepo.
Nesta actividade, a principal sugesto do ICONIX que no se deve
despender muito tempo com a descrio textual, e que se pode usar um
estilo de escrita qualquer, que seja conveniente no contexto do projecto,
desde que usado consistentemente.
Como exemplo, vamos apresentar a descrio textual de apenas um
caso de utilizao, designadamente do caso Registar Evento.

Nome: Registar Evento
Actores: Udocente
Objectivo: Registar o anncio de um evento (e.g., conferncia, reunio,
notcia) relevante para a comunidade do DEI.
Cenrio Principal (descrio de alto nvel):
1) Incluir o caso de utilizao Validar Acesso.
374 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

2) O utilizador-docente (UDocente), aps a sua validao pelo sistema,
recebe do sistema o formulrio "Registo de Evento".
3) O UDocente preenche adequadamente o formulrio recebido, em
particular especificando: o ttulo; uma breve descrio; um url para
mais detalhes; a data de incio e de fim do evento; e especfica o
mbito da sua divulgao (se mbito pblico, se mbito restrito
(apenas para docentes)).
4) O UDocente submete a informao introduzida.
5) O sistema recebe a informao introduzida, valida-a (por exemplo,
no permitindo a introduo de dois eventos com o mesmo ttulo), e
guarda a informao numa base de dados. Para alm da informao
introduzida pelo UDocente, o sistema adiciona ainda a data de
registo e a identificao do docente interveniente.
6) O sistema notifica adequadamente o UDocente que o registo foi rea-
lizado com sucesso.

Cenrio Alternativo 1 (Desistncia de preenchimento do
formulrio):
Idem aos passos 1), 2) e 3) do Fluxo Principal.
4) O UDocente no submete o formulrio num perodo de 1 hora, a
partir do momento que o formulrio foi enviado pelo sistema. O
sistema aborta a transao e o caso de utilizao reinicializado.

Cenrio Alternativo 2 (Informao invlida):
Idem aos passos 1), 2) 3) e 4) do Fluxo Principal.
5) O sistema recebe a informao introduzido, mas esta no passa nos
testes de validao.
6) O sistema notifica adequadamente o UDocente que o registo no foi
realizado.

CAPTULO 11 METODOLOGIA ICONIX 375


Anlise de Robustez
A anlise de robustez uma actividade importante no ICONIX. Este tipo
de actividade foi inicialmente proposto por Ivar Jacobson, de forma a
permitir ilustrar graficamente as interaces entre objectos participantes
num caso de utilizao. Foram definidos trs tipos de objectos, os quais
se encontram definidos no perfil Processos de Desenvolvimento de
Software especificado no UML 1.3 (ver Seco 9.4.1):
Objectos de fronteira/interface (boundary), permitem aos actores
comunicarem com o sistema. Exemplos comuns deste tipo de
objecto so janelas, ecrs, pginas Web, janelas de dilogo.
Objectos de entidade (entity), correspondem geralmente aos
objectos identificados no modelo do domnio. Estes objectos so
geralmente mapeados em tabelas de bases de dados ou ficheiros
que guardam a informao necessria.
Objectos de controlo (control), funcionam como integradores entre
os objectos de fronteira e os objectos de entidade. O objectivo
destes objectos conterem as regras de negcio e as polticas de
funcionamento de modo a potenciarem a independncia das
interfaces com os utilizadores, por um lado, e dos esquemas das
bases de dados, por outro. Estes objectos terminam ocasionalmente
como objectos no modelo esttico; mas mais geralmente, acabam
por ser convertidos em mtodos de objectos de entidade ou de
objectos de fronteira.

Figura 11.13: Tipos de objectos usados os diagramas de robustez.
A anlise de robustez desempenha no ICONIX um papel charneira na
passagem entre a anlise (o qu) e o desenho (o como), tendo as
seguintes funes principais:
376 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Teste de razoabilidade: permite validar se a descrio textual de um
caso de utilizao tem sentido e se a especificao do comporta-
mento do sistema razovel, dado o conjunto de objectos identi-
ficados.
Teste de completude: permite validar se todos os cursos de
execuo de um sistema so descritos atravs de casos de utili-
zao.
Descoberta de objectos: permite identificar novos objectos que no
foram descobertos anteriormente durante a modelao do domnio.
Uma sugesto do ICONIX desenvolver os diagramas de anlise de
robustez antes, ou em paralelo, com a descrio textual dos casos de
utilizao, de modo a influenciar a identificao dos objectos interveni-
entes e a escolha dos nomes usados. A ideia geral que os nomes ge-
nricos devero ser substitudos por nomes de objectos que aparecem
nos diagramas de robustez. Outra sugesto relevante evitar fazer
desenho detalhado nesta fase e nestes tipos de diagramas. O seu
principal objectivo captar, para cada caso de utilizao, os principais
objectos e respectivas relaes de comunicao estabelecidas entre os
mesmos.

Figura 11.14: Regras de desenho dos diagramas de robustez.
CAPTULO 11 METODOLOGIA ICONIX 377


O ICONIX preconiza um conjunto de regras para auxiliar o desenho de
diagramas de robustez, em particular so definidas as seguintes regras
(ver Figura 11.14):
Os actores podem comunicar com o sistema atravs de objectos
fronteira.
Os objectos fronteira comunicam apenas com actores e objectos de
controlo.
Os objectos entidade comunicam apenas com objectos de controlo.
Os objectos de controlo comunicam apenas com objectos de frontei-
ra e de entidade.

Apresenta-se na Figura 11.15, a ttulo de exemplo, o diagrama de
robustez relativo ao caso de utilizao Registar Evento. Note-se nas
interaces entre os diferentes tipos de objectos, que traduzem em ter-
mos gerais o comportamento deste caso. Observe-se ainda as relaes
de agregao entre a pgina de registo de eventos e os seus respec-
tivos botes.

Figura 11.15: WebDEI Diagrama de robustez do caso Registar
Evento.
378 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Outro aspecto ilustrado na Figura 11.15, que o ICONIX sugere, a
possibilidade de representao explicita da invocao de um caso de
utilizao (e.g., Consultar Eventos) a partir de um objecto fronteira.

Actualizar o Diagrama de Classes
Na realizao dos diagramas de robustez, por cada caso de utilizao,
foram usadas classes anteriormente definidas (e.g., a classe Evento),
mas foram tambm descobertas novas classes (e.g.,
RegistaEventoPgina, ValidaEvento), assim como atributos, que
devero actualizar o diagrama de classes anteriormente construdo.
O mecanismo de actualizao do diagrama de classes deve ser
realizado de forma cuidadosa de modo a evitar introduzir-se classes que
mais tarde sero transformadas em mtodos (e.g., a classe
ValidaEvento).

Nesta fase, percebemos tambm que no h qualquer caso de
utilizao relacionado com as classes ActividadeConsultoria e
ActividadeID, pelo que as iremos eliminar do diagrama de classes
original. A Figura 11.16 ilustra o diagrama de classes resultante desta
actividade. Por motivos de simplicidade e facilidade de leitura no se
introduziram as outras classes correspondentes aos objectos de
fronteira identificados nos diagramas de robustez.

CAPTULO 11 METODOLOGIA ICONIX 379



Figura 11.16: WebDEI Diagrama de classes no final do desenho
preliminar.

380 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

11.5.3 Desenho
O principal objectivo desta actividade detalhar o desenho do sistema
tendo em considerao a infra-estrutura computacional de suporte e a
tecnologia de desenvolvimento envolvida.

Neste caso de estudo, a infra-estrutura computacional corresponde
arquitectura a quatro camadas descrita no enunciado (ver Seco 11.4),
e a tecnologia de desenvolvimento consiste num conjunto de pginas
HTML geradas dinamicamente a partir de servlets Java, numa aplicao
servidor multiactividade desenvolvida em Java, e numa base de dados
suportada por um gestor de base de dados no determinado priori.
Complementarmente, o cliente webcomunica com o servidor Web e os
servlets atravs do protocolo HTTP, os servlets comunicam com o
servidor Java atravs do protocolo RMI (Java Remote Method
Invocation), e o servidor comunica com o gestor de base de dados atra-
vs do JDBC (Java Data Base Connectivity).

Especificar o Comportamento
A primeira actividade desta tarefa consiste na especificao do
comportamento do sistema. Tal especificao conduzida pelos casos
de utilizao anteriormente identificados e descritos atravs dos respe-
ctivos diagramas de robustez e descries textuais.
O comportamento de um caso de utilizao especificado anteriormente
atravs de um diagrama de robustez agora detalhado atravs de um
diagrama de sequncia. Este diagrama deve usar a generalidade dos
objectos e actores representados no diagrama de robustez, mas agora
evidenciando o fluxo de mensagens trocadas entre si.
O ICONIX sugere a seguinte sequncias de passos:
1. Copiar o texto do caso de utilizao para a margem esquerda do
diagrama de sequncia.
CAPTULO 11 METODOLOGIA ICONIX 381


2. Adicionar os objectos de entidade.
3. Adicionar os objectos de fronteira.
4. Analisar e descobrir para cada objecto de controlo, em que objectos
o seu comportamento deve ser atribudo. (Ou seja, em geral, no se
representam os objectos de controlo, j que o seu comportamento
corresponde a operaes suportadas pelos outros objectos partici-
pantes.)


No caso do WebDEI, vamos assumir que a validao e a criao de um
evento ser realizada no contexto do servidor Java (e.g., classe
DEIServer), na classe Evento. Assumimos ainda que as pginas
HTML so geradas dinamicamente a partir de servlets correspondentes
(e.g., classe EventoServlet). A Figura 11.17 ilustra o diagrama de
sequncia relativo ao caso de utilizao Registar Evento.

Figura 11.17: WebDEI Diagrama de sequncia do caso Registar
Evento.
Note-se que o diagrama ilustra tambm a relao entre a classe
Evento e a hipottica classe DEIDB que sabe guardar os diferentes
objectos geridos no servidor Java. Esta ltima classe esconde
382 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

propositadamente todos os detalhes das relaes entre o servidor Java
e o gestor de base de dados.
Isto um exemplo hipottico, mas ilustra claramente algumas decises
de desenho, que tero impacto importante ao nvel da implementao.
Entre outros, um aspecto relevante tem a ver com o facto das classes
responsveis pela produo da interface com o utilizador, os servlets,
no usarem directamente as classes de entidade (como por exemplo, a
classe Evento) o que implica que a comunicao entre os servlets e o
servidor Java ser sobre RMI mas com um protocolo de baixo nvel, por
exemplo por troca de strings, em vez de troca de objectos serializados.

Nesta actividade de especificao do comportamento, e se for
relevante, pode-se usar tambm diagramas de colaborao para ilustrar
as transaces principais entre objectos, em particular em situaes
com padres de desenho. Pode tambm ser considerado nesta fase o
desenho de diagramas de estados ou de diagramas de actividade.
Contudo, este tipo de diagramas no so particularmente importantes
no ICONIX. Em particular o ICONIX d nfase utilizao de diagramas
de estados associados a casos de utilizao em vez de, como mais
comum, a objectos/classes.

A Figura 12.18 ilustra, a ttulo de exemplo, o diagrama de estados
correspondente classe Evento.
CAPTULO 11 METODOLOGIA ICONIX 383



Figura 11.18: WebDEI diagrama de estados da classe Evento.
Um evento passa ao longo da sua vida por trs estados. Aps a sua
criao fica no estado Registado. Quando a data de incio de
divulgao do evento igual ou superior data corrente (i.e., data do
sistema), o evento evoluie para o estado Em Divulgao, podendo ser
ento consultado via Web. Ainda nesse estado, a informao sobre o
evento enviada periodicamente segundo o parmetro
dataDisseminao definido na classe ParmetrosConfigurao.
Por fim, quando se atinge a data de fim do evento, este passa para o
estado Expirado.


Terminar o Modelo Esttico
A segunda actividade desta tarefa consiste em terminar o modelo
esttico, adicionando informao detalhada com base nos diagramas de
interaco que entretanto tenham sido desenvolvidos, que obviamente
identificaram as operaes que devero fazer parte das classes
384 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

correspondentes. Adicionalmente, o diagrama de classes dever incluir
todos os atributos, operaes, adornos de visibilidade e de navegabili-
dade.
A definio e utilizao de padres de desenho de forma consistente
tambm corrente nesta fase final do desenho dos diagramas de classe.

A Figura 11.19 apresenta um esboo relevante do diagrama de classes
do WebDEI, resultante desta actividade de desenho.

Figura 11.19: WebDEI esboo do diagrama de classes da fase de
desenho.
Alguns aspectos merecem ser referidos relativamente ao diagrama da
Figura 11.19:
O servidor Java consiste na classe WebDEIServer, que mantm
estruturas de dados (no diagrama no est explcito que tipos de
estruturas de dados so definidas, se listas, se tabelas de acesso
associativo (hashtables), se vectores dinmicos, etc.) com os
principais objectos identificados no modelo do domnio.
O servidor Java providencia um ponto de acesso, via RMI, ao
implementar e publicar a interface remota WebDEI.
CAPTULO 11 METODOLOGIA ICONIX 385


O servidor Java responsvel por estabelecer conexes, via JDBC,
com a base de dados DEIDB; para tal mantm variveis internas do
tipo java.sql.Connection e java.sql.Statement.
Os servlets so derivados a partir da classe abstracta
WebDEIServlet que impe um determinado estilo arquitectural,
em particular contm uma referncia para o servidor Java (vrivel
servidor), atravs da interface remota WebDEI.

Verificar Requisitos
Para terminar a tarefa de desenho, ou por outra forma, antes de se
iniciar a implementao propriamente dita, o ICONIX sugere que se
verifique se o desenho satisfaz todos os requisitos identificados. Em
particular, o ICONIX sugere a aplicao da seguinte metodologia:
1. Produzir a lista de requisitos.
2. Escrever o manual de utilizador do sistema, na forma de casos de
utilizao.
3. Iterar com os utilizadores e clientes at se conseguir fechar os
itens 1 e 2.
4. Certificar que se consegue determinar, para cada requisito, o seu
impacto em que parte do desenho, e vice-versa.
5. Determinar, a partir das diferentes partes do desenho, que requisitos
esto envolvidos.
11.5.4 Implementao
O ICONIX refere explicitamente que considera a tarefa de
implementao como fora do seu mbito e foco de interesse. No deixa
contudo de providenciar um nmero restrito de sugestes que merecem
alguma referncia.
Designadamente, o ICONIX tece um conjunto de observaes relativas
atribuio de tarefas e actividades a diferentes intervenientes do
processo. Por exemplo, sugere (1) que os casos de utilizao sejam
386 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

desenvolvidos por indivduos com experincia no desenho de GUI ou
por escritores tcnicos com experincia na produo de manuais de
utilizador; (2) que os modelos de domnio e diagramas detalhados de
classes sejam desenvolvidos por indivduos com experincia no
desenho de bases de dados; (3) que os programadores de sistema
devem focar-se em aspectos tais como desempenho, segurana, e
serem os responsveis pelo desenho dos diagramas de estados e de
colaborao. sugerido que a tarefa do desenho detalhado (em
particular o desenho de diagramas de sequncia) seja realizado, ou
pelo menos supervisionado, por indivduos seniores com experincia
em modelao OO.
O ICONIX refere a possibilidade de se desenharem nesta fase
diagramas de arquitectura de forma a clarificarem alguns detalhes da
instalao e da implementao propriamente dita. Por exemplo, o
ICONIX sugere a utilizao de diagrama de componentes para se
ilustrar o mapeamento entre as classes e os componentes, ou seja,
para ilustrar como que as classes se devero encontrar organizadas
atravs da noo de componentes de trabalho. Por exemplo, pode-se
explicitar, para cada componente, que classes que aquele imple-
menta.

A Figura 11.20 ilustra o diagrama de componentes de instalao
constituinte do WebDEI. Note-se em particular a explicitao da sua
arquitectura a quatro camadas: cliente universal, UI (user interface),
lgica e dados; tal como as relaes existentes entre os diversos
componentes do sistema: http, rmi e jdbc. (Sugere-se ao leitor mais
atento, uma anlise e comparao entre as Figuras 12.20 e 12.6
esperando que as concluses sejam, neste momento, bvias!)
CAPTULO 11 METODOLOGIA ICONIX 387



Figura 11.20: WebDEI esboo do diagrama de componentes de
instalao.
Sai fora do mbito do livro a discusso e anlise dos detalhes de
implementao e codificao deste caso de estudo. Tambm no foi
nosso propsito, neste livro, realizar o documento de anlise e desenho
do sistema WebDEI na sua totalidade; mas apenas usar o exemplo
WebDEI para ilustrar e discutir a aplicao do processo ICONIX.
11.6 Concluso
Neste captulo respondemos questo colocada anteriormente: como
usar o UML no processo de desenvolvimento de software? Apresent-
mos o ICONIX, que como vimos um processo iterativo e incremental,
conduzido por casos de utilizao e com modelao visual baseada em
UML.
Podemos dizer que o ICONIX um processo que, atravs de uma
abordagem essencialmente prtica, ensina a modelar um sistema de
388 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

software segundo o paradigma OO. O objectivo global do ICONIX , a
partir de um conjunto de requisitos inicialmente definido, a construo
do modelo de classes que suporte a implementao de determinado
sistema.
Neste processo, sem dvida que os seus aspectos principais consistem
na identificao e representao do modelo do domnio (uma verso
inicial e de alto nvel do diagrama de classes) e dos casos de utilizao.
A partir destes dois modelos tudo se desenrola iterativa e
incrementalmente: cada caso de utilizao detalhado atravs de uma
descrio textual e respectivo diagrama de robustez. So identificados
novos objectos e detalhes, os quais so adicionados ao diagrama de
classes. Seguidamente desenham-se os diagramas de sequncia (com
um significativo nvel de detalhe) identificando-se o comportamento (i.e.,
as operaes) dos objectos intervenientes. Essas operaes so adicio-
nadas numa verso detalhada e final dos diagramas de classes.
A ideia chave do ICONIX poder-se- identificar como fazer (i.e.
modelar) o menos possvel, no mais curto perodo de tempo, de forma a
concretizar um bom sistema. O ICONIX no privilegia explicitamente a
utilizao de vrios diagramas UML, em particular no privilegia os
diagramas de estado, de actividade, de arquitectura, e mesmo os
diagramas de colaborao. Tal posio parece-nos adequada num
processo que se pretende prtico e simples. No entanto, outros
processos igualmente simples e prticos sugerem a utilizao de outros
diagramas do UML. Por exemplo, o GRAPPLE [McConnell96] sugere
explicitamente o desenho de diagramas de actividades para modelar
processos de negcio na fase preliminar do processo de software, o que
na nossa opinio e experincia pode ser benfico.
Outra ideia forte do ICONIX a distino entre requisitos e casos de
utilizao. Para os seus autores, um requisito um requisito e um caso
de utilizao um caso de utilizao. So conceitos distintos, existindo
uma relao de muitos-para-muitos entre si. Esta posio vai no sentido
contrrio de vrias outras propostas, que consideram que os requisitos
de um sistema podem ser representados e mantidos, com significativos
benefcios, atravs dos casos de utilizao. Uma desvantagem bvia
desta posio do ICONIX obrigar equipa do projecto a identificao
e gesto de listas de requisitos, assim como gesto das relaes
CAPTULO 11 METODOLOGIA ICONIX 389


entre requisitos e casos de utilizao, o que implica um esforo e
volume de trabalho mais significativo, o que na nossa opinio deveria
ser evitado num processo que se pretende rpido e simples.
390 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

11.7 Exerccios
Ex.78. Tendo em conta os seus conhecimentos sobre o ICONIX, quais
so os tipos de empresas que maior partido podero tirar desta
metodologia de desenvolvimento?
Ex.79. Quais so as principais caractersticas do ICONIX?
Ex.80. Quais so os diagramas UML cuja aplicao no relevante
segundo o ICONIX?
Ex.81. Quais so os principais tipos de objectos usados na actividade
de anlise de robustez?
Ex.82. O que so diagramas de robustez? Qual a sua importncia no
contexto do ICONIX?
Ex.83. Qual a tomada de posio do ICONIX relativamente relao
entre casos de utilizao e requisitos? Discuta justificadamente
se concorda ou no com essa posio.
Ex.84. Faa a descrio textual dos casos de utilizao apresentados
na Figura 11.11, relativamente ao caso de estudo WebDEI.
Ex.85. Qual a sequncia de passos preconizada no ICONIX para se
passar de um diagrama de robustez (conjuntamente com a
descrio textual do caso de utilizao) para um diagrama de
sequncia?
Ex.86. Modifique o diagrama de classes da fase de desenho, apresen-
tado na Figura 11.19, relativamente ao caso de estudo WebDEI,
considerando que tanto os servlets (derivados a partir da classe
WebDEIServlet) como o WebDEIServer tm acesso s
classes de entidade (e.g., Evento, Docente,
AreaCientifica), e que em vez de trocarem strings, trocas
instncias dessas classes serializadas.


Parte 4
Ferramentas CASE
A maioria das pessoas presume que o mundo
que conhece durar indefinidamente. Essas
pessoas tm dificuldade em imaginar um modo
de vida verdadeiramente diferente para elas
prprias, quanto mais uma civilizao
totalmente nova. Claro que reconhecem que as
coisas esto a mudar. Mas presumem que as
mudanas presentes passaro de qualquer
modo sem lhes tocar e que nada abalar o
quadro econmico familiar nem a estrutura
poltica. Esperam confiantemente que o futuro
continue o presente.
Alvin Toffler, A Terceira Vaga, 1980.
As Ferramentas CASE
A tradicional expresso "em casa de ferreiro espeto de pau" pode
aplicar-se com alguma propriedade aos informticos: tal como o ferreiro
no utilizava utenslios para facilitar o seu trabalho, uma parte
significativa da actividade de desenvolvimento de software foi sempre
392 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

realizada com apoio reduzido de ferramentas. Nos ltimos anos tem-se
procurado corrigir esta situao, e um bom exemplo disso a utilizao
de ambientes de desenvolvimento integrados. No entanto, a maioria
destes ambientes concentram a sua ateno na fase de implementao
do software, proporcionando um reduzido suporte sua fase de
concepo.
Quando surgiu a ideia de escrever este livro, a estrutura que nos
pareceu mais adequada apontava para a organizao do livro em
quatro partes: (1) uma introduo, onde fossem analisadas as questes
mais abrangentes da engenharia de software, de modo a enquadrar o
leitor; (2) apresentao detalhada da linguagem UML; (3) descrio do
impacto do UML ao nvel das metodologias de desenvolvimento de
software e (4) utilizao do UML em ferramentas de modelao.
O objectivo da Parte 4 esclarecer um conjunto de conceitos genricos
e o mbito de interveno destas ferramentas de modelao. De forma
a concretizar alguns destes conceitos, e tendo em conta que o livro
incide sobre o UML, procurmos identificar no mercado algumas fer-
ramentas que utilizam de base esta linguagem de modelao.
Os produtos seleccionados foram o Rose, por ser a ferramenta de
modelao da empresa Rational, onde foi produzida a especificao do
UML, e o System Architect, uma ferramenta existente no mercado h
muito tempo. e numa posio destacada, que suporta outras tcnicas
de modelao, mas que actualmente disponibiliza tambm modelao
em UML. Para alm destes critrios, outros foram utilizados:
O pressuposto de que gostaramos de apresentar uma ferramenta
UML pura, isto , que apenas (ou quase) suporta o UML como
tcnica de modelao (o caso do Rose) e outra que tivesse um
passado de sucesso na aplicao das notaes e metodologias
estruturadas (o caso do System Architect).
A preocupao de seleccionar ferramentas lderes do mercado de
modelao, como so reconhecidamente o Rose e o System
Architect.
A facilidade da obteno das respectivas licenas para a maioria
dos utilizadores, isto , a preocupao de seleccionar ferramentas
que possam ser utilizadas em computadores pessoais.



Os captulos relativos s duas ferramentas analisadas no pretendem
substituir os manuais dos produtos, pelo que o leitor no ir aqui
encontrar informao detalhada sobre o contedo dos menus ou da
toolbar respectiva, ou uma descrio de todas as opes disponveis.
Igualmente, tambm no pretendem ser uma avaliao completa e
formal de cada produto, pois no vamos analisar muitos aspectos que
para tal seriam relevantes (por exemplo, os passos do processo de
instalao da ferramenta, mecanismos de suporte disponibilizados pelo
fornecedor, desempenho do produto).
O nosso objectivo principal com estes dois ltimos captulos do livro
apresentar duas ferramentas que tm concentrado a sua ateno em
tcnicas de modelao, e em particular, no UML. Nesses captulos
demonstra-se como que as duas ferramentas seleccionadas se
comportam em relao a alguns critrios, que podero ser factores
diferenciadores numa deciso de utilizao e/ou aquisio, e dos quais
destacamos os seguintes:
Modelao de processos de negcio.
Gerao automtica de documentao.
Processo de round-trip engineering, quer para o cdigo de
aplicaes quer para a gerao de scripts de bases de dados.
Mecanismos de extensibilidade disponibilizados pela ferramenta.
Organizao da Parte 4
O Captulo 12, Ferramentas CASE, tem por objectivo definir o(s)
significado(s) do acrnimo CASE, apresentar diversos conceitos
tericos, descrever a evoluo deste tipo de ferramentas e introduzir
uma taxonomia das ferramentas CASE. So tambm referidas as
funcionalidades mais relevantes que as ferramentas de modelao
providenciam e abordadas algumas questes importantes que se
colocam s ferramentas de modelao em UML.
O Captulo 13, Rose, descreve resumidamente a evoluo e as
caractersticas gerais do Rose, e de seguida apresenta mais detalhada-
mente, recorrendo a exemplos prticos, a forma como este produto
resolve algumas questes importantes neste tipo de ferramentas, com
UML.
394 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

O Captulo 14, System Architect, segue uma estrutura idntica ao
captulo anterior, se bem que pelo facto de utilizar outras tcnicas de
modelao para alm do UML, estas tambm sero brevemente anali-
sadas, at porque nalguns casos o System Architect utiliza-as para
resolver alguns problemas sem recorrer ao UML.























Captulo 12 - FERRAMENTAS CASE
Tpicos
Introduo
Evoluo Histrica
Arquitectura das Ferramentas CASE
Mecanismos de Integrao entre Ferramentas
Taxonomia das Ferramentas CASE
Vantagens e Problemas das Ferramentas CASE
Funcionalidades das Ferramentas CASE
Gerao Automtica de Artefactos
Avaliao de Ferramentas CASE
Ferramentas de Modelao para UML
Concluso
Exerccios

12.1 Introduo
O acrnimo CASE tem tido, ao longo do tempo, diversas interpretaes,
se bem que a mais utilizada e referida na literatura a de Computer
Aided Software Engineering, o que, numa traduo literal, significa
"Engenharia de Software Auxiliada por Computador". Se relativamente
ao significado das letras iniciais C e E existe algum consenso, o
mesmo no acontece com as outras duas letras, cujos diferentes signifi-
cados podem ser observados Figura 12.1.
396 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE


Figura 12.1: Significado do Acrnimo CASE.
A letra A tem sido utilizada frequentemente para significar tambm
Assisted ou Automated; no primeiro caso, a palavra pode ser encarada
como sinnimo de Aided, enquanto que no segundo caso a ideia
realar a importncia da utilizao de meios informticos nas
actividades relacionadas com a engenharia de software, de modo a que
essas actividades sejam realizadas de forma automtica. No entanto, e
independentemente da utilizao de qualquer dos trs significados, a
distino no neste caso muito significativa.
A maior divergncia tem a ver com o significado da letra S, uma vez
que a alternativa Systems. A palavra "Sistema" d uma abrangncia
maior ao conceito CASE, uma vez que passaramos a incluir no
apenas questes relacionadas com a Engenharia de Software, e
portanto cujo objectivo ltimo tem a ver com o desenvolvimento de
software, mas tambm aspectos relacionados com as questes do
Sistema de Informao no seu todo, e que no Captulo 1 inclumos no
mbito do Planeamento Estratgico de Sistemas de Informao e da
definio da Arquitectura de Sistemas de Informao.
Na nossa perspectiva, mais importante do que o significado das quatro
letras a definio do que se entende por CASE. Numa primeira
anlise, o termo CASE no fala explicitamente de ferramentas, mas se
pensarmos na expresso "auxiliado por computador", tal s pode ser
conseguido pela utilizao de ferramentas informticas.
Antes de apresentamos a nossa definio do conceito CASE, vale a pe-
na constatarmos as opinies que outros "pensadores" sobre o assunto
emitiram anteriormente:
B. Terry [Terry90]: "CASE designa um conjunto de ferramentas que
auxiliam um programador ou um gestor de projectos durante uma ou
mais fases do processo de desenvolvimento de software, incluindo a
manuteno".
CAPTULO 12 FERRAMENTAS CASE 397


Carma McClure [McClure89]: "Uma combinao de ferramentas de
software e de metodologias de desenvolvimento estruturadas". Esta
definio reflecte claramente o momento histrico em que foi
elaborada, uma vez que utiliza a expresso "metodologias estrutu-
radas" para definir CASE, pois data em que a definio foi elabo-
rada, no existiam outras metodologias com expresso.
Software Engineering Institute (www.sei.cmu.edu): "CASE a
utilizao de meios de suporte baseados em computador no proces-
so de desenvolvimento de software".
No mbito deste livro, definimos CASE como um conjunto de tcnicas e
ferramentas informticas que auxiliam o engenheiro de software no
desenvolvimento de aplicaes, com o objectivo de diminuir o
respectivo esforo e complexidade, de melhorar o controle do projecto,
de aplicar sistematicamente um processo uniformizado e de automatizar
algumas actividades, nomeadamente a verificao da consistncia e
qualidade do produto final e a gerao de artefactos. Uma ferramenta
CASE no mais do que um produto informtico destinado a suportar
uma ou mais actividades de engenharia de software, relacionadas com
uma (ou mais) metodologia(s) de desenvolvimento.
Tendo em conta esta definio, e o mbito da Engenharia de Software
referido no Captulo 1, devemos incluir no universo das ferramentas
CASE aplicaes com funcionalidades tradicionalmente no includas.
Um bom exemplo disto so ferramentas que auxiliam a gesto de
projectos. No entanto, e dado que o foco do livro o UML, iremos
concentrar a anlise a efectuar nas ferramentas cujas funcionalidades
podero ser cobertas pelo UML, que tipicamente so as da rea de
modelao. Esta anlise ser concretizada nos captulos 13 e 14, com o
estudo de duas ferramentas especficas.
Um dos principais objectivos que h muito tempo se procura atingir com
estas ferramentas a implementao de um ambiente integrado que
permita a aplicao de uma abordagem concept to code (isto , "desde
a concepo at implementao") para o desenvolvimento de
sistemas de informao. No entanto, este objectivo foi frequentemente
comprometido por diversas razes. Uma das mais relevantes tem a ver
com a incapacidade de suportar, de forma integrada, todas as activi-
398 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

dades das vrias fases do processo, e sobretudo de automatizar vrias
delas (nomeadamente a gerao automtica de cdigo).
As alteraes significativas ao nvel da tecnologia, dos mtodos de
anlise e desenho, e a crescente preocupao com a modelao do
negcio ao mais alto nvel, so algumas das razes que vieram trazer
preocupaes acrescidas e reforar a necessidade da implementao
do conceito concept to code.
Os estudos existentes no mercado no so consistentes sobre as
vantagens da utilizao deste tipo de aplicaes. Se alguns ([Banker91],
[Finlay94], [Iivari96]) apontam para aumentos de produtividade com a
introduo de produtos CASE, outros ([Orlikowski93], [Vessey92]) che-
gam concluso de que estes benefcios so difceis de atingir e quan-
tificar.
12.2 Evoluo Histrica
Em termos histricos, desde muito cedo que se tornou evidente a
necessidade da utilizao de ferramentas para auxilio do programador
no desenvolvimento de software. Por muito elementares e primitivas
que fossem, j as primeiras aplicaes necessitavam de suporte de
outras ferramentas para serem desenvolvidas e executadas. Numa
primeira fase, estamos a falar de ferramentas onde se incluam os
tradutores, compiladores, assembladores, pr-processadores, linkers e
loaders. Numa segunda fase, algumas evolues tecnolgicas, entre as
quais se destaca a possibilidade da partilha do tempo de computao,
levaram ao desenvolvimento de outras ferramentas que complemen-
taram as anteriores, tais como os editores de texto, debuggers, verifica-
dores de cdigo e software para controle de verses.
No incio da dcada de 70, surgiu no mercado o sistema operativo UNIX
e respectivos utilitrios, que so frequentemente apontados como um
dos primeiros conjuntos de ferramentas integradas de apoio ao
desenvolvimento. Apesar da sua simplicidade, este conjunto de utilit-
rios disponibilizava um ambiente integrado e uniforme, simples de
utilizar por um tcnico informtico. No entanto, alguns tericos mais
puristas teriam alguma dificuldade em classificar o conjunto destes
utilitrios como uma ferramenta CASE.
CAPTULO 12 FERRAMENTAS CASE 399


Apenas no incio da dcada de 80 que surgem no mercado as
primeiras ferramentas que se consideram actualmente como integrando
o universo CASE. O Excelerator, uma das primeiras ferramentas CASE
unanimemente considerada como tal, surgiu em 1984. A crescente
importncia que foram tendo no processo de desenvolvimento est
directamente relacionada com um conjunto de factores decisivos que
contriburam para o crescente sentimento da necessidade deste tipo de
ferramentas:
A mudana do nfase das actividades de programao para
actividades de anlise e desenho de software, de modo a possibilitar
a ultrapassagem dos diversos problemas que se reconheciam aos
mtodos de trabalho ad-hoc (ver Seco 3.3).
Utilizao de computadores pessoais e de interfaces de trabalho
grficas.
O aparecimento de diversas tcnicas de modelao de sistemas,
que implicavam o desenho de diagramas grficos (tais como os
fluxogramas ou diagramas de fluxos de dados), em que a
representao destas notaes em papel, ou em ambientes
orientados ao caracter, se tornava impraticvel medida que a res-
pectiva complexidade aumentava (quaisquer correces que fossem
necessrias implicavam sempre refazer tudo de novo).
O aumento da complexidade e do tamanho do software, associado
s maiores capacidades do hardware.
As ferramentas desta fase tiveram essencialmente trs grandes preocu-
paes: ajudar na elaborao da documentao, na produo de dia-
gramas e no suporte das actividades de anlise e desenho.
De realar que por esta altura comearam a surgir ferramentas que
suportavam tcnicas e notaes apenas de uma nica metodologia,
enquanto outras mais abrangentes, incluam suporte para diferentes
notaes. No primeiro caso, incluem-se sobretudo ferramentas das
grandes consultoras internacionais.
Durante a dcada de 80, assistimos crescente incorporao de
funcionalidades automticas, nomeadamente a verificao da consis-
tncia entre modelos e a gerao de modelos de desenho a partir de
modelos de anlise. Em finais dos anos 80, surgiram as primeiras fer-
400 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

ramentas de gerao automtica de cdigo, a partir das especificaes
de desenho, e com suporte ao trabalho em equipa. Data tambm desta
altura o aparecimento de ferramentas de outras reas e que ns
consideramos integradas no universo das ferramentas CASE, tais como
ferramentas para gesto de projectos, elaborao de estimativas ou su-
porte realizao de testes.

Figura 12.2: Evoluo das ferramentas de apoio ao desenvolvimento de
software.
No incio dos anos 90, muitas das ferramentas CASE passaram a ser
designadas por ferramentas RAD (Rapid Application Development), o
que traduzia a preocupao de aumentar o ritmo do desenvolvimento
aplicacional. Exemplos destas ferramentas foram (e algumas ainda so)
o Visual Basic, Sql Windows, Dephi, Powerbuilder, Oracle Designer e
Oracle Developer, que esto frequentemente vocacionadas para auxiliar
o desenvolvimento de software para ambientes cliente-servidor.
A partir de meados dos anos 90, com a crescente importncia das
abordagens orientadas por objectos e o desenvolvimento de compo-
nentes, a terminologia utilizada por alguns autores passou a ser fer-
ramentas de modelao visual. No entanto, a expresso CASE perma-
nece, no nosso entender, como a mais abrangente de todas.
A evoluo dos conceitos e ferramentas CASE nem sempre foi um
caminho simples e bem sucedido. Por exemplo, a iniciativa da IBM
designada por AD/Cycle fracassou em 1992. Esta iniciativa tinha por
objectivo definir um conjunto de especificaes standard, que permitis-
sem a todas as ferramentas de desenvolvimento comunicar entre si.
Igualmente, a grande maioria dos primeiros fabricantes deste tipo de
ferramentas j no existe ou foi adquirida por outras empresas.
Mais recentemente, a introduo dos conceitos da orientao por
objectos veio de alguma forma revolucionar o mercado, quer porque
CAPTULO 12 FERRAMENTAS CASE 401


uma parte significativa das ferramentas tradicionais teve que se
"reinventar", e incorporar novas tcnicas de modelao integradas (ou
no) com as abordagens estruturadas j existentes ( o caso do System
Architect da Popkin Software); quer porque surgiram no mercado novas
ferramentas que suportam exclusivamente este paradigma ( o caso da
ferramenta Rose da Rational). Neste contexto, assume particular
destaque o UML, que vem assumindo um papel crescente ao nvel das
notaes de modelao. Hoje em dia, praticamente todas as ferramen-
tas que detm uma quota de mercado mais significativa incorporam
algum suporte para o UML.
Esta uma das "reas quentes" das ferramentas CASE que se com-
centram na modelao de software: a dvida sobre a preponderncia de
determinadas notaes e consequente implementao pelas ferramen-
tas. A nossa opinio que as metodologias e notaes orientadas por
objectos, e em particular o UML, acabaro por se tornar preponderantes
no futuro, ao nvel da especificao de software.
Outras preocupaes importantes so a incluso de funcionalidades de
modelao de processos de negcio, ou a disponibilizao de ambien-
tes de programao integrados com as ferramentas de modelao. Esta
ltima fase marca tambm a crescente preocupao com o desenvolvi-
mento de funcionalidades de apoio ao trabalho em equipa e gesto de
projectos. Esta variedade de funcionalidades e de ferramentas coloca
outros desafios adicionais, tais como os aspectos de extensibilidade e
de abertura ou mecanismos de integrao (ver Seco 9.7 a propsito
do XMI).
A tendncia para a aquisio e fuso de empresas que actuam na rea
de modelao, e que j vem desde h alguns anos, continuar. Uma
das sequncias mais curiosa foi a que culminou na aquisio da Sterling
Software pela Computer Associates em 2000, e que teve vrios passos
intermdios:
Em 1996, dois dos fabricantes mais relevantes de produtos CASE
da altura, a Cadre e a Bachman, juntaram-se numa nova companhia
designada por Cayenne.
A Cayenne foi por sua vez adquirida pela Sterling Software em
1998.
402 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

A Sterling Software j tinha adquirido a Knowledgeware em 1994.
Tambm em 2000, a Computer Associates adquiriu a Platinum.
A Platinum j tinha anteriormente adquirido a LogicWorks.
Todas estes fabricantes disponibilizavam data da sua aquisio
produtos relevantes no mercado, que so actualmente todos comerciali-
zados pela Computer Associates.
12.3 Arquitectura das Ferramentas CASE
A maioria das ferramentas CASE especializa-se sobretudo numa tarefa
especfica do processo de desenvolvimento de software. Algumas
concentram-se na disponibilizao de funcionalidades relevantes para a
fase de concepo (por exemplo, elaborao de diversos diagramas),
enquanto outras esto particularmente direccionadas para a fase de
implementao (por exemplo, desenvolvimento visual, gerao de cdi-
go e apoio realizao de testes).
Seguindo uma estratgia best-of-breed, que significa seleccionar a
melhor ferramenta para cada funcionalidade, e dada a abrangncia da
definio de CASE, estas ferramentas no tm necessariamente que
pertencer todas ao mesmo fornecedor. Por isso, tornou-se necessrio
desenvolver mecanismos que facilitassem a integrao e partilha de
informao entre elas, uma vez que a mesma informao pode ser
relevante para mais do que uma ferramenta. Um bom exemplo disso a
informao sobre os componentes de uma aplicao, que produzida
por uma ferramenta de anlise e desenho, e que essencial para um
utilitrio que tenha como objectivo parametrizar e executar testes de for-
ma automatizada.
A arquitectura tpica das ferramentas CASE (ou pelo menos uma que se
considera mais adequada para este tipo de aplicaes) constituda por
um conjunto de aplicaes / componentes, suportados por um reposit-
rio integrado, como se representa na Figura 12.3.
CAPTULO 12 FERRAMENTAS CASE 403



Figura 12.3: Arquitectura genrica das ferramentas CASE.
Repositrio
O termo repositrio designa o componente da arquitectura das
ferramentas CASE que utilizado como meio de armazenamento, ges-
to e partilha de objectos, modelos, documentos, ou quaisquer outros
artefactos, produzidos por algum dos restantes componentes que com-
pletam a arquitectura.
Na prtica, o papel do repositrio pode ser concretizado atravs de uma
base de dados, como o caso tpico dos fornecedores que possuem
simultaneamente produtos CASE e bases de dados (casos da Oracle e
da Sybase), mas muitos produtos utilizam um simples sistema de ges-
to de ficheiros, alguns com formatos proprietrios.
O repositrio de uma ferramenta CASE particularmente relevante,
uma vez que facilita a gesto de modelos elaborados, e a respectiva
reutilizao, disponibilizando para isso mecanismos potentes de pes-
quisa. Tipicamente, o seu contedo incluir:
Templates de mbito variado, nomeadamente de diagramas e de
documentos, que facilitam a elaborao de artefactos concretos a
partir de modelos genricos.
Templates e frameworks aplicacionais, a partir dos quais podem ser
construdos "esqueletos" de aplicaes em funo de um conjunto
de parmetros.
Bibliotecas de objectos, classes e componentes, que para alm de
eventuais componentes que possam vir inicialmente com as fer-
ramentas, permitem a integrao de outros desenvolvidos ao longo
do tempo.
Diagramas diversos que resultam da modelao do sistema.
Cdigo fonte, programas executveis e aplicaes empacotadas
prontas para distribuir aos utilizadores finais.
404 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Ficheiros de dados para testes e scripts de execuo dos mesmos.
O repositrio apresenta as funcionalidades tpicas de um sistema de
gesto de bases de dados, nomeadamente no que diz respeito a:
Garantia de integridade de dados.
Partilha de informao.
Suporte ao trabalho concorrente de vrios utilizadores.
Facilidades de realizao de operaes de pesquisa.
O repositrio um componente crtico ao providenciar mecanismos e
estruturas de dados para a integrao entre as ferramentas,
constituindo-se como o meio de armazenamento comum, para todos os
artefactos. No entanto, e de modo a garantir o sucesso do repositrio,
enquanto facilitador da partilha de informao, necessrio que sejam
definidos adicionalmente os seguintes aspectos:
Um formato comum para troca de informao descritiva dos artefac-
tos.
Uma interface comum para aceder e utilizar os artefactos.
12.4 Mecanismos de Integrao entre Ferramentas
Para alm do repositrio (ou complementarmente), existem outras
possibilidades para realizar a integrao entre ferramentas CASE. A
alternativa mais simplista de partilha de informao entre duas
ferramentas distintas consiste na exportao e importao de dados
utilizando formatos relativamente universais (por exemplo, campos de
texto separados por vrgulas, segundo formato tipo CSV). Esta alternati-
va, no entanto, no garante qualquer integridade da informao, uma
vez que o mesmo conceito se encontra potencialmente duplicado, no
sendo possvel garantir a coerncia da informao: quaisquer altera-
es numa das cpias no so reflectidas nas restantes.
Outra alternativa tem a ver com a construo de componentes
partilhados, em linguagens como C++, Java ou Visual Basic, que podem
ser utilizados por vrias ferramentas para acesso a funcionalidades
comuns. Por exemplo, a funcionalidade de pesquisa de objectos e a
implementao de mecanismos de suporte ao trabalho de vrios
CAPTULO 12 FERRAMENTAS CASE 405


utilizadores, so relevantes para vrias ferramentas, e podem ser imple-
mentadas por um componente comum.
Uma vez que, hoje em dia, proliferam ferramentas desenvolvidas por
diversos fabricantes, partida no integrveis, um dos mecanismos
mais interessantes para facilitar a integrao entre ferramentas a
utilizao de um repositrio "independente", que facilmente suporta o
armazenamento de diversos componentes; um bom exemplo disso foi o
produto que a Microsoft desenvolveu com o nome de Repository, e que
actualmente se encontra integrado no SQL Server 2000 Meta Data
Services. Esta neutralidade, recorrendo a standards de armazenamento
e acesso aos objectos, permite aos fabricantes utilizarem esta
tecnologia para o desenvolvimento e reutilizao de componentes best-
of-breed, e aos clientes obterem o melhor dos dois mundos: (1) as
melhores ferramentas, (2) integradas entre si. Os Meta Data Services
da Microsoft incluem:
Um modelo de descries partilhveis e reutilizveis, Open
Information Model, com a definio de diversos tipos e relaes, e
que se encontra descrito em UML.
Um conjunto de interfaces uniformizadas, para acesso a metadados,
atravs de COM e XML, e que pode ser utilizado para definir
modelos de informao.
Um sistema de gesto de objectos do repositrio, em que interfaces
COM e SQL podem ser utilizadas para aceder aos objectos arma-
zenados em SQL Server.
O Software Development Kit, verso 3.0, relativo aos Meta Data
Services est disponvel para download num dos sites da Microsoft
(msdn.microsoft.com/downloads).
O CASE Data Interchange Format (CDIF) outra iniciativa desenvolvida
nesta rea, conduzida pela Electronic Industries Association. O CDIF
comeou a ser desenvolvido em 1987, tendo sido originalmente
publicado em 1991 e revisto em 1994 e em 1997, de forma a incorporar
contributos posteriores. O CDIF consiste numa famlia de standards,
que definem: (1) uma arquitectura nica para a troca de informao
entre ferramentas de modelao de diferentes fabricantes, e (2) as
interfaces entre os componentes que implementam esta arquitectura.
406 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

(Para mais informao sobre esta iniciativa consulte-se
www.eigroup.org/cdif)
Durante a dcada de 90 muitas ferramentas aderiram a este standard,
mas com a crescente utilizao das notaes orientadas por objectos, e
em particular com o UML, perdeu um pouco da importncia (e do
sucesso) que lhe era atribuda inicialmente. Para isso muito contribuiu o
desenvolvimento do XMI, j referido na Seco 9.7, como novo
standard de integrao entre ferramentas que suportam UML, e base-
ado em XML.
12.5 Taxonomia das Ferramentas CASE
A incluso de um produto no universo das ferramentas CASE depende
da abrangncia da definio considerada. Por exemplo, uma parte
significativa dos informticos teria dificuldade em considerar um
"simples" editor de texto como uma ferramenta CASE. Normalmente,
pensamos sempre em ferramentas de suporte a actividades mais
"nobres", e a edio de cdigo no traz aparentemente qualquer valor
acrescentado ao desenvolvimento de software. No entanto, se
pensarmos no significado exacto do termo, e que sem um editor de
texto no seria possvel produzir um programa (para alm de que ele
pode mesmo automatizar algumas tarefas, como sejam a substituio
de palavras), seremos levados a reconsiderar e a inclui-lo nesta clas-
sificao.
Os critrios utilizados para classificar as ferramentas CASE so muito
diversos. Os mais significativos incluem: (1) a anlise das funcionalida-
des disponveis; (2) o papel que representam para os gestores ou para
elementos tcnicos; (3) a possibilidade de serem utilizados nas vrias
fases do processo de desenvolvimento de software.
Tendo em conta a proliferao de aplicaes nesta rea, uma taxono-
mia das ferramentas CASE particularmente importante, pois facilita a
compreenso da abrangncia de uma determinada ferramenta e da sua
aplicabilidade nas fases e actividades do processo de desenvolvimento
de software. Para alm destes questes, a classificao destas fer-
ramentas facilita ainda a realizao de anlises comparativas.
CAPTULO 12 FERRAMENTAS CASE 407


Uma primeira classificao das ferramentas CASE pode ser efectuada
com base nos seguintes critrios:
Fases do processo de desenvolvimento s quais as ferramentas se
aplicam:
Ferramentas Upper-Case so aplicaes que se especializaram
na fase de concepo do software (ferramentas de anlise e
especificao e/ou modelao de requisitos).
Ferramentas Lower-Case so aplicaes utilizadas na fase de
implementao (ferramentas de desenho tcnico, de edio e
compilao de cdigo e de testes).
Utilizao das ferramentas em actividades especificas de uma
fase/tarefa ou concebidas para actividades que se desenrolam ao
longo de todo o ciclo: um exemplo tpico das primeiras so as
ferramentas que implementam ambientes de desenvolvimento, en-
quanto que nas segundas se pode incluir uma ferramenta de gesto
de projectos.
Uma outra classificao mais detalhada agrupa as ferramentas nas
seguintes categorias:
Modelao de processos de negcio: ferramentas orientadas para
a anlise e especificao dos processos de negcio, que permitem
verificar como os objectivos estratgicos de negcio so
concretizados em processos. Para alm de utilizarem diversas
notaes e diagramas para a representao de informao do
negcio (cadeia de valor, responsabilidades e funes da
organizao), recorrem com frequncia a tcnicas de simulao e
anlise de custos (por exemplo, anlise ABC). Estas funcionalidades
possibilitam a utilizao destas ferramentas para compreender o
funcionamento da empresa e identificar problemas ou oportunidades
de melhoria (e no para o desenvolvimento de software). Esta
categoria no por vezes considerada como integrando o universo
das ferramentas CASE. Exemplos: Aris Toolset (www.ids-
scheer.com), Mega Suite (www.mega.com), Provision
(www.proformacorp.com).
408 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Modelao de anlise e desenho do sistema: esta a categoria
onde se pode incluir a maioria das ferramentas CASE. Permitem
normalmente relacionar modelos de processos com os modelos e
requisitos a implementar nos sistemas de informao, recorrendo a
tcnicas referidas no Captulo 3. nesta rea que o paradigma da
orientao por objectos e o UML maior impacto tm tido. Como
exemplos desta categoria de ferramentas, que suportam o
paradigma da orientao por objectos, temos o Rose
(www.rational.com), o Paradigm Plus (www.cai.com), o GDPro
(www.advancedsw.com). Se considerarmos as ferramentas que
adicionalmente suportam abordagens estruturadas temos o System
Architect (www.popkin.com), o PowerDesigner (www.sybase.com) e
o Silverrun (www.silverrun.com).
Desenho de bases de dados: aparecem na sequncia das
ferramentas anteriores (muitas vezes de forma integrada), mas
especializaram-se na definio lgica e fsica da estrutura das bases
de dados. Exemplos: System Architect (www.popkin.com) o
PowerDesigner (www.sybase.com) e o Erwin (www.cai.com).
Programao de aplicaes: ferramentas que normalmente
incluem num ambiente nico e integrado (se bem que as mais
antigas podem ainda funcionar de forma autnoma) funcionalidades
de edio de programas, de concepo da interface, e outros
programas tais como os interpretadores, compiladores, geradores
de cdigo e debuggers. Exemplos: Visual Basic e Visual C++
(www.microsoft.com), Delphi (www.borland.com) e Powerbuilder
(www.sybase.com).
Gesto de alteraes no software: suportam o trabalho em
equipa, e implementam funcionalidades de gesto de verses, de
mecanismos de check-in e check-out (operaes que garantem que
apenas uma pessoa acede com permisses de alterao a um
determinado artefacto do sistema), de gesto da configurao e
distribuio do software. Exemplos: Visual Sourcesafe
(www.microsoft.com) e ClearQuest (www.rational.com).
Testes: esta categoria compreende ferramentas que permitem a
definio de regras de testes, a gerao de scripts para posterior
execuo de testes, a definio de dados para testes, o controle e a
gesto de erros, e a obteno de estatsticas relacionadas com esta
informao. Exemplos: Suite TestStudio (www.rational.com) e
TestWorks (www.soft.com).
CAPTULO 12 FERRAMENTAS CASE 409


Orientadas para a Gesto de Projectos: so ferramentas cujas
principais funcionalidades se destinam a facilitar as tarefas de
gesto e coordenao dos projectos, com recurso a tcnicas tais
como o planeamento e estimativa de tempos, custos e recursos, a
utilizao e afectao de recursos ao projecto, definio de
responsabilidades. Por vezes, incluem ainda facilidades de auxlio
na aplicao de uma metodologia de desenvolvimento de software
(muitas vezes disponibilizando informao sobre melhores prticas,
casos de estudo, e uma knowledge base sobre todo o processo).
Exemplos: Project (www.microsoft.com) e Juggler
(www.cse.dcu.ie/catalyst).
12.6 Vantagens e Problemas das Ferramentas
CASE
A introduo de ferramentas CASE numa organizao pressupe uma
predisposio para a aplicao de regras e princpios a todo o processo
de desenvolvimento, sendo esta pr-condio j de si um aspecto
positivo no processo de melhoria do desenvolvimento de software numa
organizao. Podemos identificar algumas das principais vantagens que
resultam da aplicao deste tipo de ferramentas:
Uniformizao do processo de desenvolvimento, das actividades
realizadas, e dos artefactos produzidos.
Reutilizao de vrios artefactos ao longo do mesmo projecto, e
entre projectos, promovendo o consequente aumento da produtivi-
dade.
Automatizao de actividades, com particular destaque ao nvel da
gerao de cdigo e de documentao.
Diminuio do tempo de desenvolvimento, recorrendo gerao
automtica de diversos artefactos do projecto, ou reutilizao de
outros previamente existentes.
Integrao de artefactos produzidos em diferentes fases do ciclo de
desenvolvimento de software, em que os outputs de uma ferramenta
so utilizados como inputs de outra. Um bom exemplo a
possibilidade de um diagrama de classes originar o esquema
relacional de uma base de dados.
410 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Demonstrao da consistncia entre os diversos modelos e
possibilidade de verificar a correco do software.
Qualidade do produto final superior, pois a utilizao de ferramentas
impe um rigor que obriga a uma abordagem mais estruturada no
processo de desenvolvimento.
No entanto, nem tudo so aspectos positivos, e estas vantagens podem
mesmo ser contrariadas por alguns problemas. No passado, verificou-se
frequentemente que os resultados obtidos no estavam de acordo com
as elevadas expectativas criadas, o que provocou o fracasso da
introduo das ferramentas CASE nas organizaes. Um dos factores
mais referidos como responsvel por esta situao o elevado tempo
de aprendizagem, por vezes requerido para tirar o melhor partido destas
ferramentas, e que no compatvel com as exigncias das organiza-
es apresentarem resultados o mais rapidamente possvel.
Outros problemas detectados incluem a impossibilidade de, numa
abordagem mais estratgica, mapear os processos de negcio (modela-
dos em notaes facilmente compreensveis pelos utilizadores) em
requisitos de informao. A integrao entre o desenho lgico de uma
base de dados e a respectiva estrutura fsica tambm uma das reas
que ainda necessrio melhorar, pois frequente que as ferramentas
apenas permitam a definio de um esquema da base de dados, sem
ter em conta a respectiva estrutura e organizao nos suportes fsicos
(esta questo ainda mais relevante no caso das ferramentas que
suportam UML, como veremos nos captulos seguintes). Uma rea que
ainda hoje constitui um dos principais mitos do software a da gerao
automtica de cdigo: desde h muito tempo tem sido um dos principais
objectivos que se procura atingir com as ferramentas CASE, mas onde
ainda no foram obtidos resultados completamente satisfatrios.
12.7 Funcionalidades das Ferramentas CASE
A estratgia de introduo das ferramentas CASE numa organizao
pode ser diversa, nomeadamente:
Suite: seleco de um conjunto integrado de ferramentas, todas do
mesmo fornecedor.
CAPTULO 12 FERRAMENTAS CASE 411


Best-of-breed: seleco das melhores ferramentas para cada
funcionalidade, suportadas por um repositrio integrado.
Pontual: seleco de ferramentas para cobrir reas pontuais.
Existem algumas funcionalidades que a maioria das ferramentas
disponibiliza, independentemente da sua rea de interveno, e que
esto relacionadas com a gesto e controle do acesso informao:
Definio de grupos e de perfis de utilizadores.
Possibilidade de manter um registo de todas as alteraes
efectuadas, associado ao controle de verses e disponibilizao
de mecanismos de check-in e check-out.
Suporte ao trabalho de equipas e a um ambiente multi-utilizador.
Possibilidade de implementar a noo de projecto e reutilizao de
artefactos de outros projectos j realizados.
No entanto, natural que as funcionalidades mais significativas de cada
ferramenta sejam especializadas consoante a sua rea de aplicao. A
ttulo de exemplo, poderemos referir que uma ferramenta direccionada
para as actividades relacionadas com gesto de projectos dever apre-
sentar, entre outras, as seguintes funcionalidades:
Possibilidade de representar as noes de fase, tarefa e actividade
que so executadas ao longo de um projecto.
Representao de diversos diagramas tpicos da gesto de projec-
tos (diagramas de Pert, Gantt, matrizes de alocao de recursos).
Possibilidade de comparar o esforo planeado com o efectivamente
realizado.
Possibilidade de atribuir actividades a recursos, e analisar a
alocao de cada um dos recursos.
Possibilidade do responsvel pela execuo de uma actividade
introduzir informao sobre o trabalho que foi efectuado.
Possibilidade de utilizar dados histricos para elaborar estimativas
para um novo projecto.
Possibilidade de analisar no apenas as questes de prazos, mas
tambm as financeiras.
Uma vez que considermos uma definio muito abrangente do
conceito CASE, seria necessrio elaborar uma lista especfica para
cada tipo de ferramenta. Esta descrio de tal modo exaustiva que sai
412 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

fora do mbito deste livro, at porque o seu objectivo analisar aquelas
que esto relacionadas com a utilizao do UML.
Por isso vamos concentrar a nossa anlise nas caractersticas de
natureza funcional relacionadas com as ferramentas de modelao.
Optmos pela apresentao de uma lista de funcionalidades, tipo
check-list, que pode funcionar como um conjunto de critrios de
avaliao e seleco das diversas ferramentas de modelao, e como
uma tentativa de sensibilizar o leitor para as reais capacidades que
pode e deve esperar deste tipo de ferramentas. Esta lista de funciona-
lidades servir nos prximos dois captulos para apresentar e discutir al-
gumas caractersticas das duas ferramentas em anlise.
A lista de funcionalidades que se segue no de modo algum
exaustiva, nem to pouco esttica. A evoluo dos conceitos e da
prpria tecnologia implicar com certeza a introduo e/ou eliminao
de novas funcionalidades. Esta lista encontra-se organizada por gran-
des grupos de funcionalidades, de forma a facilitar a sua compreenso.

Critrios de Modelao
Suporte a um ou mais mtodos ou paradigmas metodolgicos.
Neste caso, o suporte linguagem UML deve cada vez mais ser
considerado um requisito fundamental.
Ferramenta orientada para a aplicao de tcnicas de modelao ou
de uma metodologia completa. Neste caso, interessa determinar a
eventual capacidade de customizao da mesma.
Tipos de modelao suportados: modelao de dados, diagramas
funcionais, modelao em UML, modelao do negcio, modelao
de instalao/distribuio de componentes.
Nvel de cobertura s vrias tarefas do processo de desenvolvi-
mento.
Separao e integrao entre modelao de nvel conceptual
(conceitos do negcio e de anlise) e de implementao (desenho e
programao).
CAPTULO 12 FERRAMENTAS CASE 413


Integrao de diversos modelos e capacidade de definir sub-
modelos, possibilitando a existncia de diversos nveis de abstrac-
o.
Integrao e sincronizao entre modelos e interfaces, suportando a
devida rastreabilidade (traceability).
Rastreabilidade dos artefactos ao longo de todo o processo (por
exemplo, desde o conceito de negcio at tabela da base de da-
dos, passando pela entidade da anlise).
Possibilidade de converter um modelo entre notaes distintas.
Possibilidade de estender as representaes grficas, quer ao nvel
dos conceitos quer do aspecto visual (por exemplo, suporte
definio de esteretipos).
Automatizao de actividades de produo de modelos a partir de
outros existentes.
Verificao da consistncia entre modelos.
Repositrio
Tecnologia de implementao do repositrio: produto comercial
disponvel no mercado, base de dados proprietria, ficheiro de texto.
Nvel de especializao do repositrio, podendo suportar apenas
uma ferramenta ou possibilitar o acesso por vrias ferramentas de
modelao.
Estrutura do repositrio aberta e conhecida, acessvel atravs de
uma interface (SQL, COM, XML).
Possibilidade de estender a estrutura do repositrio.
Facilidade de administrao de modo a garantir a segurana do re-
positrio.
Suporte a verses.
Suporte ao trabalho em equipa.
Gerao de Cdigo
Possibilidade de anlise e verificao da estrutura de um programa.
Possibilidade de automatizar a produo do cdigo.
Linguagens de programao suportadas para gerao de cdigo
(por exemplo, C++, Java, Visual Basic).
414 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Suporte para o reverse-engineering de aplicaes existentes.
Suporte para o forward-engineering (gerao de cdigo).
Suporta desenvolvimento cclico de cdigo (round-trip engineering),
com introduo de marcas e sem perda de informao.
Possibilidade de integrao com ferramentas de gesto de configu-
raes.
Possibilidade de gerao de interface grfica.
Gerao de documentao de validao do processo.
Gesto de Configurao e das Alteraes
Comparao de alteraes entre verses e produo de scripts que
reproduzam essas alteraes.
Produo de relatrios de anlise de impacto das alteraes a efec-
tuar.
Disponibilizao de mecanismos de check-in e check-out de compo-
nentes.
Definio de nveis de segurana e auditoria aos modelos.
Modelizao de Dados
Integrao entre os modelos de anlise e a estrutura de uma base
de dados. Se pensarmos no caso do UML, estamos a falar de
diagramas de classes.
Suporte para Reverse Engineering de bases de dados.
Suporte para gerao de outros objectos de uma base de dados
(por exemplo, triggers e stored-procedures).
Manuteno de integridade referencial.
Gerao de esquemas de bases de dados, sendo particularmente
relevante o suporte para o modelo relacional.
Lista de bases de dados suportadas (Oracle, Sql Server, DB2,
Informix, ). conveniente o suporte de vrios dialectos de
DDL/SQL, nomeadamente para os sistemas de gesto de bases de
dados mais utilizados.
Documentao
CAPTULO 12 FERRAMENTAS CASE 415


Gerao automtica de relatrios e de documentao geral de
projectos: estatsticas, dicionrio de dados, modelos elaborados,
inconsistncias, rastreabilidade, operaes realizadas.
Possibilidade de publicao dos modelos em interface Web.
Nvel de detalhe que se pode definir para cada atributo/elemento
manipulado pela ferramenta (por exemplo, descrio, pr e ps-
condies, etc.).
Suporta gerao automtica de documentos com base em
templates.
Possibilidades de configurar a gerao de documentao.
Extensibilidade
Existncia de linguagem de scripting e tipo de capacidades
providenciadas (por exemplo, para configurao da ferramenta,
gerao de cdigo, produo de relatrios, verificao da consis-
tncia).
Capacidade de integrao com outras ferramentas e processo como
tal realizado.
Possibilidade de estender a ferramenta ao nvel da documentao
gerada.
Possibilidade de introduzir na ferramenta novos conceitos.

Outras Questes Genricas
Facilidade de utilizao (ajuda, manuais, controle de consistncias,
relatrios).
Funcionalidades de importao e exportao.
Definio de regras de validao.
Abrangncia de conceitos e de componentes suportados, e nvel de
detalhe de cada um.
Obrigatoriedade de utilizao e aplicao de standards.
Suporte a modelos de elevada dimenso (por exemplo, o nmero de
processos ou de entidades num diagrama).
416 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

12.8 Gerao Automtica de Artefactos
Como vimos anteriormente, uma das vantagens apontadas s fer-
ramentas CASE a disponibilizao de diversos mecanismos de
automatizao de tarefas. Neste aspecto, so particularmente interes-
santes as funcionalidades que esto relacionadas com a gerao de
cdigo e de documentao, e que passamos a descrever de seguida.
12.8.1 Round-Trip Engineering
A aplicao do princpio "concept to code" significa na prtica que
deveria ser possvel a partir da especificao dos requisitos de um pro-
blema, definir e implementar a respectiva soluo.
De forma a garantir a correco e a minimizao da interveno
humana, o ideal seria efectuar as fases posteriores de forma
automtica. A este processo chamamos Forward Engineering. No
entanto, em noutros casos interessante ter a possibilidade de efectuar
o percurso inverso, isto , a partir de cdigo previamente existente,
produzir os modelos de desenho e de anlise correspondentes. A este
ciclo designamos por Reverse Engineering, e ao conjunto dos dois por
Round-Trip Engineering (ver Figura 12.4).

Figura 12.4 : Round-Trip Engineering
Quando os dois conceitos comearam a merecer a ateno da comuni-
dade informtica, eram encarados de forma independente, mas actual-
mente so vistos numa perspectiva integrada.
O Forward Engineering tem bastante utilidade da primeira vez que o
cdigo gerado, mas normalmente ocorrem algumas alteraes duran-
te o desenvolvimento que so realizadas directamente no cdigo, sem a
CAPTULO 12 FERRAMENTAS CASE 417


correspondente actualizao nos modelos. O Reverse Engineering per-
mite sincronizar os modelos de desenho e de anlise a partir do cdigo
fonte.
A funcionalidade de Reverse Engineering permite igualmente
documentar e clarificar o funcionamento de aplicaes antigas (legadas)
para as quais no existe qualquer documentao, e/ou quando as
pessoas responsveis pelo seu desenvolvimento j no esto dispon-
veis. A partir do modelo gerado, podero ser efectuadas alteraes de
natureza conceptual que, atravs de mecanismos de Forward Engine-
ering, sero reflectidas novamente no cdigo.
O processo de Reverse Engineering consiste na anlise de um
determinado bloco de cdigo, de modo a capturar a informao relevan-
te para a descrio de um sistema e na sua consequente representao
grfica atravs de modelos perceptveis para os engenheiros de sof-
tware. A partir do input de cdigo fonte (ou esquemas da base de
dados) so gerados modelos grficos de anlise e desenho, informao
sobre a utilizao de funes, etc. Estas ferramentas podem ir um
pouco mais longe e permitir a reestruturao de cdigo: a partir da
anlise da sintaxe de um programa, pode ser gerado um fluxograma,
que aps validao ou alterao, pode gerar um novo programa, desta
vez obedecendo s boas prticas da programao. Esta uma
abordagem que pode facilitar a converso de cdigo legado.
O conceito de Round-Trip Engineering, pode ser analisado segundo o
comportamento em vrias relaes:
Relao entre modelos lgicos de dados e esquemas de bases de
dados.
Relao entre modelos de processos e cdigo de componentes.
Relao ente diagramas de classes e esqueletos / cdigo de classes
ou esquemas das bases de dados.
As ferramentas do primeiro grupo tm tido maior sucesso do que as
restantes, uma vez que o nmero de conceitos das linguagens de
programao muito superior aos conceitos associados estrutura de
uma base de dados. Alm disso, o modelo relacional , actualmente,
um standard praticamente universal, enquanto que o nmero de
418 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

linguagens de programao muito elevado, para que se possa
apresentar uma oferta abrangente. Na Figura 12.5 apresenta-se uma
concretizao do processo de Round-Trip Engineering, ao nvel de
diversos diagramas relacionados com a gerao de cdigo.

Figura 12.5: Round-Trip Engineering de Processos
12.8.2 Gerao de Documentao
A gerao de documentao de uma forma automtica uma
funcionalidade importante em qualquer ferramenta CASE. Quando se
desenvolve um projecto de raiz, a possibilidade de gerar documentao
automaticamente permite libertar a equipa de projecto de uma tarefa
demorada e que muitas vezes no chega a ser devidamente concluda.
Por outro lado, existem projectos e aplicaes para as quais no existe
qualquer documentao. Neste caso, a integrao de tcnicas de
Reverse Engineering, poder possibilitar a gerao da documentao
necessria. expectvel que as ferramentas CASE disponibilizem um
conjunto diverso de funcionalidades de gerao de documentao, tais
como:
Documentao de modelos e de cdigo fonte.
Gerao de mltiplos formatos de documentos ( Html, Word, etc... ).
Gerao de documentao com base em Templates.
Possibilidade de configurao da gerao de documentos.
Possibilidade de personalizao e extenso do processo de gerao
de documentao atravs de linguagens de scripting.
12.9 Avaliao de Ferramentas CASE
Normalmente, a primeira recomendao sobre a seleco de
ferramentas CASE seria a utilizao de um conjunto limitado de
ferramentas, de preferncia apenas uma, que integrasse as diversas
funcionalidades necessrias, de forma a rentabilizar o investimento e a
CAPTULO 12 FERRAMENTAS CASE 419


garantir, ou pelo menos facilitar, a integrao. Contudo, podem existir
razes que justifiquem que algumas organizaes optem por estratgias
diferentes.
Por exemplo, a organizao pode ao longo do tempo ter adquirido
diversas ferramentas CASE, que actuam em diferentes fases do proces-
so de desenvolvimento (uma ferramenta de modelao, uma de gesto
de projectos, outra de gesto de configurao e controle de verses,
outra de programao).
Outro exemplo tem a ver com a possibilidade de existir numa
organizao uma ferramenta com funcionalidades de anlise e desenho
de software, integradas com a gerao de cdigo de modo a facilitar o
trabalho dos programadores. Paralelamente, existe um ambiente desti-
nado a utilizadores finais com capacidade de explorao de informao,
que utiliza tcnicas de quarta gerao e que possibilita a construo de
relatrios com relativa autonomia. Neste caso, a utilizao de uma nica
ferramenta de "desenvolvimento" de software no faria qualquer sem-
tido.
Os critrios de avaliao so diversos e devem ser aplicados
realidade concreta de uma organizao. No entanto, o processo de
seleco deve ser semelhante s avaliaes de outras aplicaes
criticas para o negcio de uma organizao, e designadamente deve
incluir: (1) elaborao de uma grelha de critrios adaptada realidade
da organizao, agregados por grandes grupos, e onde devero estar
critrios funcionais, tecnolgicos, financeiros e de suporte do forne-
cedor; (2) atribuio de factores de peso a cada critrio, consoante a
respectiva importncia para a organizao; (3) avaliao e classificao
com base em informao recolhida e em demonstraes; (4) seleco
com base na avaliao efectuada.
Para o sucesso do projecto de seleco ainda essencial que exista
um consenso na organizao relativamente utilizao e aos objectivos
que se pretendem atingir com a ferramenta: se a organizao enfrenta
problemas importantes a nvel do controle e gesto de projectos, no
com a aquisio de uma ferramenta de automatizao de testes que
eles sero resolvidos (de facto, tambm no o sero totalmente com um
420 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

programa de gesto de projectos, pois com certeza existiro outros fac-
tores a rever).
Os critrios de natureza funcional foram abordados anteriormente. Os
critrios de seleco de natureza tecnolgica, financeiros e de suporte
do fornecedor so genricos a qualquer seleco de aplicaes, e entre
vrios podemos destacar:
Financeiros
Preos das licenas.
Custos de implementao.
Custos de manuteno.
Tecnolgicos
Sistemas operativos suportados.
Bases de dados sobre as quais trabalham.
Outros requisitos de hardware (RAM, processador, capacidade em
disco).
Desempenho da ferramenta.
Escalabilidade.
Suporte
Material de suporte disponvel (CD, manuais, tutoriais, ficheiros de
help, etc.).
Material de apoio traduzido.
Suporte local disponvel.
Facilidade de utilizao.
12.10 Ferramentas de Modelao para UML
Sendo este um livro direccionado para apresentao da linguagem de
modelao UML, natural que abordemos neste captulo algumas
questes relacionadas especificamente com as ferramentas de modela-
o que utilizam UML. Isto para alm de tudo o que j referimos, e
aplicvel de forma genrica a qualquer tipo de ferramenta.
As ferramentas de modelao para UML podem ser divididas em duas
categorias principais, consoante a antiguidade e notaes suportadas:
CAPTULO 12 FERRAMENTAS CASE 421


Ferramentas relativamente recentes, que concentram a sua ateno
na modelao de software em UML, ou pelo menos, no realam o
suporte que tm para outras notaes. Como exemplos deste grupo
temos o Rose da Rational, o GDPro da Advanced Software
Technologies e o Paradigm Plus da Computer Associates.
Ferramentas mais antigas, que tradicionalmente ocuparam posies
de destaque no mercado, atravs da utilizao de notaes estrutu-
radas, e que gradualmente foram incorporando tambm o UML,
sendo hoje em dia uma das notaes que mais destacam. Um bom
exemplo desta categoria o System Architect.
Tipicamente, as ferramentas do primeiro grupo exploram as
capacidades do UML at ao limite, incluindo suporte para os aspectos
mais avanados do UML (descritos no Captulo 9). As do segundo gru-
po so muitas vezes ferramentas de "elaborao de diagramas", recor-
rendo a diagramas que j suportavam para as reas em que o UML no
, de base, to poderoso e completo.
Para alm do suporte elaborao de diagramas, as ferramentas de
modelao para UML concentram actualmente a sua preocupao num
conjunto de funcionalidades, entre as quais se destacam:
Mecanismos de Round-Trip Engineering, com particular destaque
para o suporte de linguagens como Java, C++ ou Visual Basic.
Produo de documentao, nomeadamente em formatos public-
veis na Internet (HTML).
Mecanismos de extensibilidade dsiponveis, recorrendo a linguagens
de elaborao de scripts.
Integrao entre diagramas. Por exemplo, possibilidade de indicar
que as mensagens entre objectos dos diagramas de sequncia
correspondem a mtodos de classes, ou que uma classe num
diagrama de classes corresponde a um actor num diagrama de
casos de utilizao, ou ainda a gerao automtica de diagramas de
colaborao a partir dos diagramas de sequncia, e vice-versa.
Suporte para XMI, o standard da OMG para integrao entre fer-
ramentas que suportam UML.
H algumas reas, importantes na modelao de software, e que o UML
no suporta de base (mas que atravs de mecanismos de extenso
422 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

cada ferramenta pode incluir), e que importante analisar numa fer-
ramenta que utiliza o UML. Em particular gostaramos de abordar duas
dessas reas: modelao de bases de dados e modelao do negcio.
12.10.1 Modelao de Bases de Dados
At data, o UML no suporta de base a modelao de bases de dados
de forma directa. Os conceitos estticos que o UML representa
(pacotes, classes, atributos) podem ser mapeados em conceitos do
mundo das bases de dados relacionais (bases de dados, tabelas,
colunas), mas so por natureza bastante diferentes. Um dos principais
problemas tem a ver com a concretizao das diversas relaes pos-
sveis entre classes, nas relaes entre tabelas (abordaremos mais de-
talhadamente esta questo nos captulos seguintes).
No entanto, e como uma das reas fundamentais de modelao a
gerao de esquemas de bases de dados, independentemente da
ausncia de suporte de base para tal no UML, a ferramenta de modela-
o deve permitir a integrao com funcionalidades de modelao de
dados. Para isso, pode seguir uma entre vrias alternativas:
Disponibilizar mecanismos que possibilitem a transformao de um
modelo de objectos ou diagrama de classes, num diagrama de
dados (diagrama entidade associao), ou mesmo num esquema de
manipulao da base de dados. A primeira hiptese normalmente
seguida pelas ferramentas que tambm possibilitam a aplicao de
tcnicas de modelao de dados (como o System Architect),
enquanto a segunda (a gerao do esquema) a opo das fer-
ramentas que apenas permitem a modelao em UML.
Exportar metadados sobre o modelo de objectos para uma
ferramenta de modelao de dados, que possibilite a sua importa-
o e utilizao como base para um modelo de dados.
Se estivermos a falar de um conjunto de ferramentas integradas,
expectvel que seja possvel manter a sincronizao entre modelos de
objectos e de dados ao longo de todo o processo de desenvolvimento.
A ltima verso do Rose (Rose 2001), reconhecendo as limitaes ao
nvel da modelao de dados do UML, veio propor uma extenso ao
CAPTULO 12 FERRAMENTAS CASE 423


UML, designada por UML Data Modeling Profile, especificamente com-
cebida para enderear este problema, e analisada no prximo captulo.
12.10.2 Modelao do Negcio
Tal como vimos no Captulo 10, o RUP prev a aplicao de um
conjunto de actividades que se destinam modelao do negcio. A
sua representao e especificao recorre sobretudo a diversos tipos
de artefactos documentais e aos diagramas de casos de utilizao do
negcio. Nesta perspectiva, a modelao de processos de negcio
efectuada em UML atravs do mesmo diagrama utilizado para a especi-
ficao dos requisitos do software: o diagrama de casos de utilizao.
No entanto, quando se fala em modelao do negcio pensa-se no
apenas em representar graficamente o fluxo de trabalho dentro da
organizao e as diversas actividades realizadas, mas tambm em
poder associar alguns parmetros (nomeadamente, o nmero e o perfil
de recursos utilizados, o tempo de durao) de modo a poder identificar
onde se situam os problemas, as ineficincias e as oportunidades a
explorar, e mesmo a simular o impacto da realizao (ou no) de deter-
minadas actividades.
Alguns dos artefactos previstos no RUP podem complementar a
notao UML base para fornecer a informao que tradicionalmente se
pretende ao nvel dos processos de negcio, nomeadamente: a identifi-
cao da cadeia de valor; dos produtos e/ou servios da organizao;
dos mercados em que actua. No entanto, mesmo este conjunto
insuficiente quando se pretendem avaliar grandezas de natureza quanti-
tativa (tempo, custo e qualidade do produto) e realizar simulaes ou
anlise segundo critrios ABC (Activity Based Costing).
As abordagens contabilsticas tradicionais no reflectem a utilizao real
dos recursos, uma vez que a preocupao est no que se produz e no
em como tal acontece. A anlise ABC assume que as actividades cau-
sam custos porque consomem recursos. Auxilia na anlise da eficcia e
da eficincia da utilizao dos recursos, e na determinao de como as
actividades na empresa contribuem para o custo do negcio.
424 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

A simulao de processos parte do pressuposto que uma organizao
resulta de uma srie de processos inter-relacionados, e que estes
processos consistem em actividades que convertem inputs em outputs.
A simulao de processos de negcio analisa a informao de custos
com base nas actividades: a partir da visualizao da execuo de
actividades ao longo do tempo, e das respostas que desencadeiam,
permite identificar os problemas e os pontos de estrangulamento exis-
tentes, e as oportunidades de melhoria.
A ausncia de suporte especifico para tcnicas como simulao e
anlise de custos um problema partilhado pela maioria das fer-
ramentas comerciais de modelao em UML, uma vez que quase todas
foram concebidas para a modelao do software e no dos processos
de negcio. No entanto, as caractersticas de extensibilidade do UML
permitem que esta linguagem seja adaptada na modelao de proces-
sos de negcio, utilizando os mecanismos de extenso providenciados
(ver Seco 9.3):
Adicionalmente, tm sido propostas algumas extenses ao UML,
especficas para modelao do negcio, a mais conhecida das quais
talvez seja a proposta por Eriksson e Penker e designada por Eriksson-
Penker Business Extensions [Penker00]. Estas extenses so j
suportadas por algumas ferramentas que as implementam, tal como a
Qualiware (www.qualiware.com). Outras ferramentas, nomeadamente o
Provision da empresa Proforma (www.proformacorp.com), adoptam um
misto de notao UML, eventualmente estendida, e de outros diagra-
mas mais tradicionais para representar e especificar os processos de
negcio.
Uma outra hiptese para solucionar esta lacuna recorrer aos
mecanismos de extensilidade para implementar scripts que permitam a
criao de interfaces com ferramentas j existentes e especializadas
nesta rea.
Apesar de tudo, os diagramas de base previstos no UML revelam-se
importantes para a modelao dos processos de negcio. Por exemplo,
para alm dos casos de utilizao, os diagramas de actividade e os
diagramas de sequncia so adequados para a representao do fluxo
de trabalho dentro de uma organizao; os diagramas de classes e de
CAPTULO 12 FERRAMENTAS CASE 425


objectos podem ser utilizados para representar informao de natureza
esttica das organizaes, como sejam os seus objectivos ou os seus
conceitos de negcio e respectivas relaes.
12.11 Concluso
Discutiu-se neste captulo que a utilizao de ferramentas de
modelao permite suportar todo o processo de forma mais sistemtica,
consistente, eficiente e controlvel. De facto, parece-nos que, no
sendo obrigatria a adopo de tais ferramentas, elas oferecem uma
mais valia considervel, principalmente nas tarefas de anlise e
desenho, quer na realizao de novos projectos, quer em projectos de
reengenharia, quer ainda como forma de controlo e avaliao de projec-
tos que se encontrem na sua fase de implementao.
Algumas tendncias que se tm observado nos ltimos anos com as
ferramentas CASE so idnticas a outras reas dos sistemas de
informao, e assim no futuro imediato previsvel que se continuem a
verificar:
Consolidao do mercado, quer por aquisies quer pelo desapa-
recimento de fabricantes economicamente inviveis.
Posicionamento das grandes companhias que tambm tm ofertas
nesta rea. Particularmente importantes sero os comportamentos
da Oracle, da Sybase, Rational e da Computer Associates.
Crescimento das ferramentas que suportam as abordagens orienta-
das por objectos, em detrimento das estruturadas, quer por aquisi-
es quer pelo aparecimento de fornecedores especificamente vo-
cacionados para este paradigma.
nosssa opinio que a crescente utilizao das linguagens orientadas
por objectos e de ambientes de desenvolvimento de componentes ir
com certeza facilitar o crescimento da quota de mercado das ferramen-
tas que utilizam a modelao segundo abordagens orientadas por ob-
jectos, e neste particular, a linguagem UML assume papel de destaque.
No final do livro, apresentamos uma lista de ferramentas que
consideramos mais relevantes no mercado actual, e um conjunto de
426 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

recursos disponveis na Internet onde o leitor mais interessado poder
consultar alguma informao adicional.
12.12 Exerccios
Ex.87. Qual a importncia da definio e aplicao dos standards de
integrao de ferramentas? Quais as razes pelas quais, na sua
opinio, eles tm falhado na realizao dos objectivos propostos.
Ex.88. Um dos grandes objectivos h muito tempo perseguido pelas
ferramentas CASE a gerao automtica de cdigo. No
entanto, at data estas iniciativas no tm tido o impacto espe-
rado. Indique algumas razes pelas quais tal pode ter aconteci-
do.
Ex.89. De que modo a evoluo da tecnologia tem condicionado o su-
cesso das ferramentas CASE?
Ex.90. Segundo a taxonomia de ferramentas CASE apresentada neste
captulo, classifique em termos de importncia (fundamental,
importante, pouco importante, sem relevncia) cada uma das
categorias apresentadas, justificando a sua resposta.
Ex.91. Pensa que seria possvel utilizar uma ferramenta de modelao
de processos, segundo as abordagens tradicionais, para supor-
tar o processo RUP? Justifique a sua resposta.










Captulo 13 - RATIONAL ROSE
Tpicos
Introduo
Interface Grfica
Repositrio
Vises e Diagramas UML
Modelao do Negcio
Mecanismos de Extensibilidade
Gerao de Cdigo Caso de Estudo em Visual Basic
Gerao de Modelos de Dados
Gerao da Interface Homem-Mquina
Gerao de Documentao
Concluso

13.1 Introduo
O Rose a ferramenta de modelao visual produzida pela Rational, a
mesma empresa que definiu inicialmente a linguagem UML. de todas
as ferramentas que apenas suportam UML (se bem que o Rose suporte
ainda outras notaes orientadas por objectos) a mais utilizada, sendo
considerada internacionalmente como uma referncia de grande rele-
vncia e notoriedade.
Para a elaborao deste captulo recorremos verso Rose 2000 para
a plataforma Windows. Durante a elaborao deste livro, saiu uma nova
428 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

verso da ferramenta, que no foi possvel utilizar. No entanto, existem
seces deste captulo que se referem com maior detalhe a funciona-
lidades desta nova verso, mas que no chegaram a ser testadas e
avaliadas na prtica. Para o leitor mais interessado, est disponvel uma
verso de avaliao na pgina do fabricante (www.rational.com) para
download.
O Rose faz parte de uma suite completa de produtos perfeitamente
integrados, que disponibilizada em vrias edies, com o objectivo de
suportar diferentes funes associadas ao processo de desenvolvi-
mento de software: analistas, programadores, arquitectos de software e
equipas de teste. O objectivo desta suite unificar, optimizar e simplifi-
car o processo de desenvolvimento de software. Entre as vrias
ferramentas destacam-se: (1) Rational Unified Process, para auxiliar na
aplicao da metodologia RUP, (2) RequisitePro, para gesto e controle
de requisitos, (3) ClearQuest, para controle de alteraes, (4) SoDa,
para apoio elaborao de documentao e (5) Rose, para modelao
visual do software utilizando a linguagem UML.
Ao contrrio de outras ferramentas nesta rea, o Rose foi concebido
para facilitar o desenvolvimento de componentes, com suporte nativo
para arquitecturas importantes no mercado actual, como sejam
Windows DNA ou Enterprise Javabeans. Neste caso, no incio da
sesso de trabalho, possvel especificar um framework, que inclui um
conjunto de elementos de vrios modelos previamente elaborados, e
que normalmente so necessrios para alguns sistemas especficos,
possibilitando a sua reutilizao pelo utilizador (Figura 13.1).
CAPTULO 13 RATIONAL ROSE 429



Figura 13.1: Frameworks previamente elaborados no Rose.
Como se pode constatar na figura anterior, est tambm disponvel um
framework para Oracle8, cuja grande vantagem incluir logo partida o
conjunto dos tipos de dados dessa base de dados, concretizados sob a
forma de classes. Outro exemplo so os frameworks para Visual Basic,
que adicionam ao projecto referncias para as bibliotecas dinmicas
mais utilizadas nesse produto.
O Rose est disponvel comercialmente em diversas edies, cujas
diferenas se situam ao nvel das funcionalidades disponibilizadas, ou
das plataformas tecnolgicas suportadas (existem verses de Rose
distintas para sistemas Windows e Unix). de salientar ainda a
existncia de um produto designado por Microsoft Visual Modeler,
comercializado em conjunto com outras ferramentas da Microsoft, mas
430 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

que , na realidade, um subset do Rose. Este facto representa no s
uma estratgia comercial da Rational no sentido de atingir um pblico
alvo mais vasto, mas tambm a concretizao da estreita relao
actualmente existente entre as duas empresas.
O Rose surgiu em 1992 como uma ferramenta de apoio ao
desenvolvimento orientado por objectos, suportando nessa altura a
modelao de software com base na notao de Booch (que, por essa
altura, j estava na Rational). A partir do momento em que o UML foi
definido, a ferramenta adoptou-o como a notao preferencial, na qual
tem apostado nas suas sucessivas verses.
Tal no significa que exista uma correspondncia directa entre as
verses do UML e as do Rose. Por exemplo, a primeira verso do Rose
com algum suporte para o UML foi a verso 4, que, contudo, no
implementava na totalidade a especificao do UML 1.0 j em vigor na
altura. A verso Rose 98 suportava o UML 1.1, que j inclua diagramas
de actividade, mas que no estavam disponveis na ferramenta.
A Rational refere a existncia de um conjunto de vantagens na utiliza-
o do Rose, nomeadamente:
Integrao forte com uma metodologia completa de desenvolvi-
mento de software, de modo a aumentar a produtividade de toda a
equipa de desenvolvimento.
Desenvolvimento baseado no conceito de casos de utilizao,
resultando numa maior qualidade do software.
Utilizao de uma linguagem de modelao cada vez mais divul-
gada, o que facilita a comunicao entre elementos de uma equipa
de desenvolvimento.
Funcionalidades de reverse engineering que permitem a integrao
de sistemas previamente existentes.
Sincronizao de modelos e do cdigo ao longo de todo o ciclo de
desenvolvimento. Por exemplo, possvel: elaborar um modelo
inicial; produzir um prottipo automaticamente a partir do modelo;
apresentar o prottipo aos utilizadores; incorporar as sugestes de
alterao directamente no prottipo; e finalmente, reflectir essas
alteraes de forma automtica no modelo.
CAPTULO 13 RATIONAL ROSE 431


13.2 Interface Grfica
O aspecto grfico inicial da ferramenta muito simples, perfeitamente
integrado com os standards do Windows, o que facilita a sua utilizao
por quem conhea previamente UML, como se pode verificar na Figura
13.2.

Figura 13.2: Interface grfica do Rose
Para alm dos menus, com aspecto semelhante aos de qualquer
produto Windows, e de uma toolbar por omisso, facilmente compre-
ensvel por parte dos utilizadores, inclui ainda as seguintes reas:
Toolbox, onde se encontram os objectos que podem ser colocados
nos diversos diagramas, e que se ajusta automaticamente em fun-
o do tipo de diagrama activo.
Browser de objectos, no qual se encontram enumerados todos os
artefactos manipulados pelo Rose (nomeadamente, conceitos e
diagramas), devidamente hierarquizados. Permite a visualizao dos
nomes e dos cones que representam diagramas e elementos do
modelo.
Janela de diagramas, que funciona como uma janela MDI (Multiple
Document Interface) dentro da qual podem ser abertas outras jane-
las, onde so elaborados os vrios diagramas de um modelo.
Janela de documentao, onde visualizada e editada a documen-
tao associada a cada elemento de um modelo, sem ter que abrir a
respectiva janela de especificao.
Janela de log, onde podem ser visualizados eventos que so desen-
cadeados pelo Rose, com impacto no repositrio.
432 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

13.3 Repositrio
O Rose armazena todos os artefactos que gere num repositrio,
podendo nalguns casos incluir referncias para documentos externos,
que no ficam armazenados fisicamente no repositrio. O repositrio
concretizado sob a forma de um ficheiro nico, designado ficheiro petal,
acessvel directamente pelo sistema operativo, o que coloca algumas
limitaes, no s sua capacidade de crescimento, mas sobretudo
segurana da informao armazenada.
Um ficheiro petal disponibiliza a funcionalidade de armazenamento
permanente de um ou mais elementos do modelo. No caso em que um
ficheiro petal contem um modelo completo, normalmente utilizada a
extenso mdl. Estes ficheiros encontram-se armazenados em formato
ASCII, o que facilita a transferncia de modelos (completos ou parciais)
entre as diferentes verses do produto, mesmo entre plataformas
tecnolgicas distintas, mas ao mesmo tempo possibilita a realizao de
alteraes directamente no ficheiro, sem qualquer proteco. A
estrutura do ficheiro foi elaborada numa lgica de descrio de objectos,
enumerando as suas propriedades e os valores assumidos por cada
uma.
Adicionalmente, o Rose permite a importao e exportao de modelos
para o Microsoft Repository, o que possibilita a partilha de modelos com
outras ferramentas de modelao.
No caso em que se utiliza a ferramenta num ambiente de desenvolvi-
mento multi-utilizador, e de modo a facilitar a utilizao de diferentes
artefactos do modelo por vrios utilizadores em simultneo, o Rose pos-
sibilita o armazenamento dos artefactos em ficheiros separados, com
extenso diferente. Estes ficheiros ficam armazenados todos na mesma
directoria, sendo de destacar os seguintes:
O ficheiro que contem o ncleo do modelo utiliza a extenso mdl.
Os ficheiros que contm elementos do modelo controlados e que
so packages lgicos utilizam a extenso cat.
Os ficheiros que contm elementos do modelo controlados e que
so packages de componentes utilizam a extenso sub.
CAPTULO 13 RATIONAL ROSE 433


O ficheiro que contm o diagrama de distribuio do modelo utiliza a
extenso prc.
O ficheiro que contem o conjunto de propriedades do modelo utiliza
a extenso prp.
No caso dos elementos do modelo no serem unidades controladas, en-
to normalmente utiliza-se a extenso ptl para designar o respectivo
ficheiro.
De referir que esto disponveis algumas funcionalidades de apoio ao
trabalho em equipa, muitas das quais so suportadas com recurso s
funcionalidades do produto Microsoft Sourcesafe, designadamente:
Possibilidade de controlar verses do modelo, e de comparar
alteraes efectuadas entre diferentes verses.
Mecanismos de check-in e check-out.
Verificao de quem fez o qu e quando.
13.4 Vises e Diagramas UML
Ao contrrio de outras ferramentas de modelao em UML, sobretudo
orientadas para a produo de diagramas, o Rose implementa o
conceito das vises de um sistema (descrito na Seco 10.4), o qual
fundamental perceber antes de se analisar as tcnicas de modelao
disponibilizadas. Na prtica, este conceito funciona como uma primeira
classificao, que permite agrupar todos os artefactos que o Rose gere.
O Rose considera a existncia de quatro vises de um sistema de sof-
tware:
Viso de casos de utilizao.
Viso lgica.
Viso dos componentes fsicos.
Viso de instalao.
A viso dos casos de utilizao auxilia na compreenso da utilizao
do sistema, uma vez que representa as interaces entre os actores e
os casos de utilizao. Os diagramas utilizados, segundo esta viso,
so os diagramas de casos de utilizao, os diagramas de sequncia,
434 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

os diagramas de colaborao e os diagramas de actividade. Tem, por
omisso, um diagrama Main que pode ser complementado com outros
diagramas, de maior detalhe, ao longo de todo o processo.
A viso lgica do sistema analisa-o de um ponto de vista esttico, e
representa a sua concretizao em termos de classes e respectivas
relaes, expressas nos diagramas de classes, nos diagramas de
objectos e nos diagramas de estados. Tambm tem, por omisso, um
diagrama Main.
A viso dos componentes apresenta a organizao do software do
sistema, incluindo informao sobre o cdigo fonte, executveis e
bibliotecas do sistema. Esta viso apenas inclui os diagramas de com-
ponentes, que por omisso tambm tem um diagrama Main.
Por fim, a viso de instalao apresenta o modo como realizada a
distribuio de componentes executveis pelos diferentes ns (plata-
formas computacionais) de suporte. Apenas inclui o diagrama de insta-
lao, que pode ser til num ambiente de arquitectura distribuda, em
que possvel ter aplicaes e servidores em localizaes diferentes.
Por conseguinte, e embora sob diferentes vises, o Rose suporta todos
os diagramas previstos na linguagem de modelao UML, nomeada-
mente diagramas de:
Casos de utilizao.
Classes.
Colaborao.
Sequncia.
Actividade.
Componentes.
Estados.
Diagrama de instalao.
Apesar do Rose ser conhecido essencialmente pela utilizao da
linguagem de modelao UML, esto disponveis outras notaes,
nomeadamente a de Booch e a OMT. Para alm da contribuio que
estas duas abordagens tiveram na definio inicial do UML, a
justificao para a incluso destas abordagens est relacionada com a
CAPTULO 13 RATIONAL ROSE 435


facilitao da converso, para o UML, de projectos e recursos humanos
habituados utilizao destas notaes.
13.5 Modelao do Negcio
Nesta rea, tal como nas restantes reas de modelao, o Rose
restringe a sua actividade de modelao ao suporte disponibilizado pelo
UML, o que significa que no tem nenhuma funcionalidade especfica
para a representao de processos de negcio que possibilitem a apli-
cao de tcnicas de simulao, de anlise de impacto de alteraes
aos processos de negcio e de identificao de custos segundo pers-
pectivas baseadas na realizao de actividades.
Contudo, e atravs dos mecanismos de extensibilidade que o UML
implementa (ver Seco 13.6), possvel representar adequadamente
os conceitos de negcio, recorrendo aos diagramas de base do UML,
nomeadamente os diagramas de casos de utilizao, os diagramas de
actividades e os diagramas de sequncia para a representao do fluxo
de trabalho numa organizao e os diagramas de classes para
representar qualquer informao de natureza esttica das organizaes.
Adicionalmente, ainda possvel recorrer aos mecanismos de extensi-
bilidade para implementar scripts que permitam a criao de interfaces
com ferramentas j existentes e especializadas nesta rea.
13.6 Mecanismos de Extensibilidade
A adequao das ferramentas de modelao s necessidades
especficas de cada organizao , hoje em dia, virtualmente impos-
svel, em funo das inmeras alternativas que se colocam. Por isso, o
Rose permite efectuar a personalizao das suas capacidades, de mo-
do a adapt-las s necessidades especficas de desenvolvimento de
uma determinada organizao e/ou projecto, atravs das seguintes pos-
sibilidades:
Personalizao de menus do Rose.
436 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Automatizao de funes manuais recorrendo construo de
scripts. Estes podem ser utilizados, por exemplo, para a criao de
classes e diagramas; actualizaes do modelo; gerao de docu-
mentao.
Execuo de funes do Rose a partir de outras aplicaes,
recorrendo ao Rose Automation object (RoseApp).
Acesso a classes, propriedades e mtodos do Rose, directamente
no ambiente de desenvolvimento da organizao, atravs de
referncias Rose Extensibility Type Library nesse ambiente.
Activao de add-ins no Rose, usando o Add-In Manager.
Para alm de estar concebido para a produo de software baseado em
componentes, o Rose ele prprio baseado em componentes, cuja
estrutura definida pelo modelo Rose Extensibility Interface (REI). A
Figura 13.3 ilustra a forma como a funcionalidade do Rose pode ser es-
tendida, ao representar os seus diversos componentes:
Aplicao Rose: inclui os objectos que disponibilizam a interface
para acesso s funcionalidades internas da aplicao.
Interface de Extensibilidade do Rose: o conjunto de interfaces
partilhadas entre o Rose Script e a Rose Automation (OLE), para
acesso s funcionalidades da aplicao Rose.
Rose Script: inclui o conjunto de objectos do Rose Script que
permitem a utilizao de scripts para a automatizao de funciona-
lidades do Rose.
Rose Automation: o conjunto de objectos do Rose Automation
que permitem que o Rose funcione como controlador ou como servi-
dor OLE.
Diagramas: so os objectos da Rose Extensibility que providenciam
a interface com os diagramas e vises da aplicao.
Elementos do Modelo: so os objectos da Rose Extensibility que
providenciam a interface com os elementos dos modelos Rose.

Figura 13.3: Mecanismos de extensibilidade do Rose.
CAPTULO 13 RATIONAL ROSE 437


Concretamente, quem quiser utilizar a interface de extensibilidade do
Rose (REI) pode recorrer a um conjunto de classes que se encontram
agrupadas, e das quais se destacam os seguintes grupos:
Application Classes: classes que realizam operaes ao nvel do
modelo no seu todo (por exemplo, criao de novos modelos ou a
seleco de um modelo existente).
Use Case Classes: classes que disponibilizam um conjunto de
propriedades e mtodos que permitem a definio e manipulao
dos diagramas de casos de utilizao de um modelo.
Model Classes: classes que providenciam acesso s propriedades e
mtodos dos objectos de um modelo.
Logical Classes: permitem definir e manipular as classes de um
modelo, definir e consultar caractersticas e relaes de classes e
manipular diagramas de classes.
Physical Classes: classes que disponibilizam as propriedades e
mtodos necessrios para se poder criar e manipular mdulos.
Deployment Classes: classes que permitem a manipulao das
caractersticas dos elementos de processamento de um modelo, dos
dispositivos fsicos sem capacidade de execuo, dos fluxos de
execuo e a representao visual de dispositivos e processadores.
Da mesma forma que quaisquer outras classes, tambm as includas
nas categorias acima enumeradas disponibilizam um conjunto de
atributos e mtodos que podem ser acedidos, a partir de outros
programas ou em scripts do Rose.
Apresentamos de seguida algumas das funcionalidades de extensibi-
lidade referidas anteriormente, deixando a parte especificamente relaci-
onada com a gerao de cdigo e de esquemas de bases de dados
para a Seco 13.7.
13.6.1 Extensibilidade dos Menus
A configurao de menus o mecanismo mais simples disponibilizado
pelo Rose para adicionar novas funcionalidades ferramenta. Podem
acrescentar aos menus existentes novas opes, alterando para isso o
contedo do ficheiro Rose.mnu. Estas extenses podem incluir a
438 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

definio de novos submenus, ou de opes de menu, que executem
(1) scripts do Rose; (2) comandos de sistema; ou (3) programas exter-
nos. Podem tambm ser adicionados separadores entre opes dos
menus.
Por exemplo, caso se pretendesse desenvolver documentao espec-
fica para obter informao do modelo, nomeadamente uma lista com
todas as classes ou casos de utilizao, poderiam ser acrescentadas
duas novas opes ao menu Report (Figura 13.4), que invocariam
scripts especificamente desenvolvidos para esse efeito.

Figura 13.4: Configurao dos menus do Rose.
Esta alterao dos menus foi produzida atravs da modificao do
cdigo do ficheiro rose.mnu, tal como pode ser observado de seguida.

Menu Report
{
option "Show &Participants in UC..."

{
enable %selected_items:empty:false
RoseScript $SCRIPT_PATH\participants.ebx
}
option "&Documentation Report..."
{
RoseScript $SCRIPT_PATH\reportgen.ebx
}
Menu "Relatorios Especificos"
{
Option "Lista de Classes"
{
RoseScript $SCRIPT_PATH\listaclasses.ebx
}
Option "Lista de Casos de Utilizao"
{
RoseScript $SCRIPT_PATH\listausecases.ebx
}
}
}
CAPTULO 13 RATIONAL ROSE 439


13.6.2 Scripts no Rose
A linguagem de scripting utilizada pelo Rose designa-se por RoseScript,
e uma verso estendida da linguagem BasicScript da empresa
Summit (informao adicional sobre esta linguagem pode ser encontra-
da online em basicscript.summsoft.com). As extenses de scripting do
Rose possibilitam a automatizao de funes especficas ou a
implementao de outras no disponveis atravs da interface do Rose.

Figura 13.5: Editor de scripts.
O Rose disponibiliza um editor de scripts, integrado no ambiente, que
possibilita a criao de novos scripts ou a alterao de outros
existentes. Para o leitor mais interessado, aconselhamos a consulta do
manual de referncia do RoseScript que acompanha o produto .
Na Figura 13.5 podemos observar o editor de scripts integrado no Rose,
bem como o aspecto da sintaxe da linguagem, utilizando como exemplo
o script para a gerao de esquemas de bases de dados utilizado pelo
Rose.
13.6.3 Rose Automation
A disponibilizao de funcionalidades OLE para integrao com
ferramentas de outros fornecedores providenciada pelo Rose atravs
do mecanismo Rose Automation, o qual oferece duas alternativas:
440 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Aplicao Rose actua como cliente OLE: Atravs da invocao de
um objecto OLE num script do Rose, e tirando partido do
funcionamento do Rose enquanto automation controller. Esta
funcionalidade permite que o Rose possa executar funes de
aplicaes Windows, tais como o Word e o Excel, atravs dos
mecanismos tpicos de OLE automation.
Aplicao Rose actua como servidor OLE: Atravs da invocao
por outra aplicao, que tambm suporte OLE, de operaes
disponibilizadas pelo OLE automation object do Rose. Por exemplo,
pode desenvolver-se em Visual Basic um programa que execute o
Rose, abra um modelo e obtenha informao, que depois utilize
para criar um relatrio em formato Excel.
A Rose Automation est disponvel para qualquer aplicao e
linguagem que possa invocar objectos COM, atravs do conjunto de
classes e interfaces da REI, como foi descrito na Seco 13.6.
13.6.4 Rose Add-Ins
Tal como a maioria dos ambientes de desenvolvimento cliente-servidor,
tambm o Rational Rose tem a possibilidade de acrescentar extenses
ao produto base, atravs da sua caracterizao como componente add-
in no ambiente do produto. As funcionalidades destes add-ins so
acessveis atravs de invocaes ao objecto RoseAddInManager.

Figura 13.6: Rose Add-in Manager.
CAPTULO 13 RATIONAL ROSE 441


No ambiente integrado do Rose, existe a possibilidade de indicar quais
os add-ins que se pretendem utilizar, atravs de referncias no Add-In
Manager (Figura 13.6).
Muitos destes add-ins so utilizados para suportar processos de forward
e reverse engineering.
13.6.5 Rose Extensibility Type Library
O Rose possibilita a utilizao da Rose Extensibility Interface (REI) a
partir de um ambiente de desenvolvimento, recorrendo a mecanismos
de referncia de bibliotecas de tipos. Por exemplo, a REI permite que os
programadores utilizem no Visual Basic os nomes das classes do Rose,
directamente no cdigo que desenvolvem, em vez de referir uma classe
genrica. Deste modo, a verificao da sintaxe das propriedades e
mtodos e a deteco de eventuais erros efectuada em tempo de
compilao (static binding) e no no momento de execuo do cdigo
(dynamic binding).
13.7 Gerao de Cdigo Caso de Estudo em
Visual Basic
Tal como a maioria das linguagens de modelao, tambm o UML no
especifica partida regras para a gerao de cdigo. Estas podem ser
eventualmente implementadas ao nvel de cada ferramenta que utilize
UML. No Rose, esta funcionalidade suportada por diversos mecanis-
mos de extensibilidade, nomeadamente add-ins e scripts.
O Rose disponibiliza funcionalidades de gerao de cdigo para as
linguagens C++, Java, Corba-IDL e Visual Basic. Para todas elas tem
mecanismos que suportam a gerao de cdigo (forward engineering) e
tambm reverse engineering. O suporte a round-trip engineering
levado a cabo atravs de marcas colocadas no cdigo gerado/
carregado e de variveis especiais (comentadas no cdigo, mas pro-
cessadas pela ferramenta). Para alm destas linguagens, suportadas de
base, possvel desenvolver scripts para suportar a gerao de cdigo
e reverse engineering para outras linguagens.
442 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

O Rose efectua todo o processo de gerao de cdigo a partir do
conceito de classe, isto , com base na especificao de cada classe
(atributos, operaes e relaes), e em funo de valores atribudos a
diversas propriedades associadas ao modelo. De modo a exemplificar
este processo, iremos utilizar as funcionalidades que o Rose dispe
para facilitar o desenvolvimento em Visual Basic. Estas baseiam-se num
add-in que permite a modelao, gerao e o reverse-engineering do
cdigo em Visual Basic. O processo segue um conjunto de passos se-
quenciais, que procuraremos demonstrar de seguida:
Criar na Logical View as classes (com os respectivos atributos e
operaes) e especificar as relaes entre elas.
Criar na Implementation View um componente e indicar que este
estar associado a um projecto Visual Basic.
Associar as classes em causa ao componente.
Parametrizar atributos e operaes de cada classe, em funo de
informao especifica do Visual Basic.
Criar o projecto no Visual Basic.
Gerar o cdigo.
Note-se que as regras de gerao de cdigo para outras linguagens
suportadas so muito semelhantes s que iro ser apresentadas para a
linguagem Visual Basic.
13.7.1 Ferramentas Utilizadas
A integrao entre o Rose e o Visual Basic muito forte. Esto
disponveis diversas ferramentas para auxiliar as vrias actividades
associadas gerao de cdigo e reverse engineering para as aplica-
es em Visual Basic:
Component Assignment Tool.
Code Update Tool.
Model Update Tool.
Model Assistant.
Type Library Importer.
CAPTULO 13 RATIONAL ROSE 443


A Component Assignment Tool providencia uma interface fcil de utilizar
para:
Criar novos componentes no modelo.
Atribuir classes a componentes.
Associar um componente a um projecto Visual Basic.
O Model Assistant fornece uma forma alternativa para:
Definir, no modelo, atributos e operaes especficos para a gerao
de cdigo em Visual Basic.
Customizar o cdigo a gerar para uma classe.
Atravs da Code Update Tool possvel gerar o cdigo fonte dos
componentes de um projecto em Visual Basic a partir da informao
contida no modelo e tambm:
Visualizar previamente o cdigo a ser gerado para cada classe.
Especificar detalhadamente o mapeamento entre classes no modelo
e o cdigo, atravs de integrao com o Model Assistant.
Manter o modelo e o cdigo sincronizados, medida que se detecta
que alguns elementos do projecto foram alterados no modelo.
Atravs da Model Update Tool possvel efectuar o reverse engineering
de um projecto Visual Basic, criando um novo modelo ou alterando um
modelo j existente, neste caso fazendo reflectir no modelo alteraes
efectuadas ao nvel do cdigo.
Por fim, atravs do Type Library Importer possvel importar para o
modelo informao sobre componentes COM, que exista numa
biblioteca de tipos (type library) e que seja referenciada por um projecto
Visual Basic. Esta informao necessria para fornecer uma des-
crio, independente da linguagem, das interfaces e dos tipos de dados
que um componente COM expe para o exterior.
A cada item de cdigo gerado atribudo um identificador do modelo
(model ID). Esta associao possibilita a identificao unvoca de cada
elemento do modelo, independentemente de alteraes efectuadas ao
seu nome, directamente no cdigo. Esta informao no tem qualquer
significado para o Visual Basic mas fundamental para o Rose efectuar
o processo de round-trip engineering correctamente. Por isso, estes
444 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

identificadores no devem em nenhuma circunstncia ser alterados. As
ferramentas Code Update Tool e Model Update Tool utilizam estes
identificadores para sincronizar o modelo com o cdigo.
Para demonstrar todo este processo vamos utilizar novamente os
conceitos do exemplo das compras referido no Captulo 3, considerando
uma verso simplificada do mesmo e utilizando subconjuntos da infor-
mao expressa para diferentes casos prticos.
13.7.2 Gerao de Cdigo
Definio de Componentes
Uma das primeiras aces a executar criar na Component View um
componente, cujo esteretipo seja do tipo programa, e dizer que a
linguagem do mesmo ser Visual Basic. Esta informao fundamental
para a correcta gerao de cdigo, uma vez que mais tarde sero as-
sociadas classes a cada componente.

Figura 13.7: Mapeamento entre classes, componentes e projectos
Visual Basic.
CAPTULO 13 RATIONAL ROSE 445


Dado que o objectivo gerar um programa executvel, a escolha lgica
para o esteretipo do componente ser Standard Exe (outras opes
seriam Activex Exe, Activex Dll, etc). Para alm do esteretipo e da
linguagem, no tabulador Visual Basic da especificao do componente
apresentado um conjunto de propriedades, das quais a mais significa-
tiva ProjectFile, onde se especifica o nome do projecto Visual Basic
que estar associado ao componente (Figura 13.8).

Figura 13.8: Especificao das propriedades de um componente
relevantes para a gerao de cdigo em Visual Basic.
Definio de Classes
De forma paralela e independente, importante que as classes sejam
definidas e as respectivas especificaes sejam elaboradas. No caso do
exemplo em anlise, vamos considerar apenas as classes
Fornecedores, Encomendas e Linhas_Encomenda, segundo o
modelo expresso na Figura 13.9. Para alm de outras situaes, com
estas classes podemos demonstrar como so resolvidas as relaes de
associao do tipo 1 para 1 (entre Encomendas e Fornecedor) e de 1
para N (entre Encomendas e Linhas_Encomenda).
446 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE


Figura 13.9: Diagrama de classes e especificao da classe
Encomenda.
Na definio de uma classe importante ter em ateno o seguinte:
A correcta especificao do seu esteretipo, que est relacionado
com o tipo de componente a gerar no Visual Basic.
A correcta especificao de todos os seus atributos.
A correcta especificao de todos os seus mtodos.
A definio das relaes existentes entre as classes.
A atribuio de valores a algumas propriedades que constam do
tabulador Visual Basic e que tm a ver com questes especficas da
gerao para esta linguagem.
O esteretipo de uma classe funciona como um template, que define o
tipo de objecto do projecto Visual Basic no qual ser mapeado, por
exemplo, um class module ou um form. O template inicializa a classe
com os membros que so tpicos para esse tipo de project item. Para
gerar cdigo Visual Basic para uma classe do modelo, a classe tem de
CAPTULO 13 RATIONAL ROSE 447


estar atribuda a um componente, sendo o Visual Basic a linguagem de
implementao desse componente.
O Rose permite ao utilizador definir diversas propriedades de um mto-
do, quer na respectiva especificao directa, quer atravs do Model As-
sistant:
Um mtodo pode ser classificado como Declare, Event ou ainda
como propriedade (Property Get, Property Set ou Property Let).
Os mtodos podem ser declarados como Public (acessveis a partir
de outros mdulos, e concretizado numa funo ou subrotina
public); Private (no acessveis a partir de outros mdulos, e
concretizados numa funo ou subrotina private); Protected (aces-
sveis a partir de outros mdulos do prprio projecto, e concretiza-
dos numa funo ou subrotina friend).
Os parmetros do mtodo so declarados com um nome e um tipo
de parmetro. A definio do tipo pode ser omitida.
Os mtodos podem ser estticos, indicando que as variveis locais
do procedimento so preservadas entre sucessivas invocaes.
Uma associao uma relao bidireccional entre classes, que denota
uma dependncia semntica entre elas. As associaes podem ser des-
critas em detalhe, atravs de diversas propriedades disponveis na res-
pectiva especificao e que so utilizadas pelo gerador de cdigo Visual
Basic para determinar o cdigo a gerar. Nomeadamente, relevante de-
finir a direco da associao, as funes desempenhadas pelas clas-
ses envolvidas, a multiplicidade e navegabilidade da relao.
Por exemplo, na relao entre Encomenda e Fornecedor necessrio
especificar a funo da classe Fornecedor nesta relao (designada
no exemplo por mFornecedor), mas no a da classe Encomenda. As-
sim, o cdigo gerado ter uma varivel na classe Encomenda que re-
presenta um Fornecedor, enquanto o inverso no acontece.
Gerao de Cdigo
Quando esta informao estiver toda correctamente registada,
necessrio passar gerao do cdigo propriamente dito, atravs da
ferramenta Code Update Tool (Figura 13.10). Durante este processo de
448 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

gerao, o Visual Basic tem que estar activo, o que garantido de for-
ma automtica pelo Rose.

Figura 13.10: Gerao de cdigo para Visual Basic.
Durante a gerao do cdigo o modelo ligeiramente alterado, de
forma automtica, de modo a incluir informao sobre tratamento de
erros. Como se pode constatar na Figura 13.11, so acrescentados a
cada classe um atributo e uma operao, e ainda includo um pacote
designado por Debug que contem classes que declaram constantes e
definem operaes para tratamento de erros.
CAPTULO 13 RATIONAL ROSE 449



Figura 13.11: Alteraes ao modelo depois da gerao.
Para cada classe, usando o mapeamento por omisso, o Rose gera a
seguinte informao no cdigo:
Definio de um componente do Visual Basic, a partir do nome e
das propriedades da classe no modelo.
Comentrio, produzido a partir da documentao da especificao
da classe.
Variveis do mdulo, que so geradas a partir das relaes de
associao, agregao e propriedades de classe.
Especificao de mtodos e/ou procedimentos (consoante se esteja
a gerar uma classe Visual Basic ou outro tipo de objecto), incluindo
o esqueleto do corpo do mtodo e eventual cdigo definido pelo
utilizador na especificao de cada mtodo.
Cdigo de Debug, que por omisso automaticamente gerado para
o tratamento de erros dos vrios mtodos.
450 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

No Visual Basic, so automaticamente gerados os ficheiros correspon-
dentes s vrias classes do modelo Adicionalmente, so criados alguns
componentes que no faziam parte do modelo, e que esto
relacionados com tratamento de erros. Enquanto as classes do modelo
so mapeadas em classes do Visual Basic, estes novos componentes,
devido ao seu esteretipo ser ClassUtility, so concretizados por
mdulos. A Figura 13.12 reproduz o ambiente do Visual Basic para o
projecto em anlise, aps a gerao do cdigo, destacando-se o
aspecto do cdigo da classe Encomenda.

Figura 13.12: Ambiente do Visual Basic aps a gerao do projecto
13.7.3 Reverse Engineering
O cdigo gerado pelo Rose corresponde, neste caso, integralmente
forma como o modelo deve ser concretizado num projecto Visual Basic.
Imaginemos agora que pretendamos efectuar as seguintes alteraes
CAPTULO 13 RATIONAL ROSE 451


directamente no cdigo, com o objectivo que fossem posteriormente re-
percutidas no modelo:
Programao da propriedade valortotal da classe Encomenda,
que calcula o custo total da encomenda.
Criao de uma nova propriedade na classe Linhas_Encomenda
para calcular o valor total de cada linha da encomenda.

Figura 13.13: Alteraes no cdigo das classes Encomenda e
Linhas_Encomenda.
O processo de reverse engineering no Visual Basic suportado pela
Model Update Tool, que actualiza adequadamente o modelo em funo
das alteraes efectuadas ao cdigo. Neste caso, tal significa a criao
de uma nova operao na classe Linhas_Encomenda (valorlinha) que
classificada correctamente em termos ao seu esteretipo. Para alm
disso, importada do Visual Basic toda a informao relativa aos com-
ponentes COM que o projecto referenciou quando foi gerado (Figura
13.14).
452 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Para que o cdigo dos diferentes mtodos fique sincronizado entre o
projecto Visual Basic e o modelo necessrio ter em ateno as
propriedades ReplaceExistingBody e DefaultBody, que constam da
especificao de cada operao das classes do modelo. A primeira
permite indicar a pretenso de definir cdigo especfico para a
operao, e a segunda permite escrever esse cdigo. tambm nesta
propriedade que colocado o cdigo importado dos componentes
Visual Basic, e introduzido directamente nesse ambiente. De progra-
mao.

Figura 13.14 : Alteraes ao modelo aps o processo de Reverse
Engineering.
CAPTULO 13 RATIONAL ROSE 453


Com esta sequncia de passos, em que (1) foi elaborado um diagrama
de classes; (2) foi gerado cdigo a partir desse diagrama; (3) foram
efectuadas alteraes directamente no cdigo e (4) foi importado o
cdigo de novo para o modelo, reproduzimos o processo de round-trip
engineering. Neste exemplo, pudemos constatar que o Rose se compor-
tou adequadamente ao longo de todos os passos.
13.7.4 Relaes de Generalizao
Uma situao que interessante analisar tem a ver com o comporta-
mento do Rose na gerao de cdigo para uma relao de generaliza-
o, e nomeadamente como os atributos e operaes pblicas, privadas
e protegidas so mapeados no Visual Basic.

Figura 13.15: Exemplo de uma relao de generalizao.
Uma relao deste tipo mapeada no Visual Basic atravs da instruo
implements. Para alm deste facto, criada na subclasse uma cpia
dos mtodos pblicos da superclasse, e os atributos pblicos desta
classe so disponibilizados para o exterior atravs de duas proprie-
dades do Visual Basic, com o mesmo nome, uma "Property Get" e outra
"Property Let", em funo do especificado no seu esteretipo. Estas
alteraes so, no decurso do processo da gerao de cdigo, reflec-
tidas no modelo (Figura 13.16).

Figura 13.16: Modelo depois do cdigo gerado.

O cdigo das duas classes ficou com o seguinte aspecto (para alm do
que foi gerado para tratamento de erros):

454 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Superclasse
Option Explicit

'##ModelId=3A8FB55B007B
Public atributo_publico As Integer

'##ModelId=3A8FB5680174
Private atributo_privado As Integer

'##ModelId=3A8FB59C0150
Public Sub operacao_publica()
On Error GoTo operacao_publicaErr

'## Your code goes here ...

Exit Sub
operacao_publicaErr:
Call RaiseError(MyUnhandledError, "operacao_publica Sub")
End Sub

'##ModelId=3A8FB5AB036F
Private Sub operacao_privada()
On Error GoTo operacao_privadaErr

'## Your code goes here ...

Exit Sub
operacao_privadaErr:
Call RaiseError(MyUnhandledError, "operacao_privada Sub")
End Sub

'##ModelId=3A8FB5B501ED
Friend Sub operacao_protected()
On Error GoTo operacao_protectedErr

'## Your code goes here ...

Exit Sub
operacao_protectedErr:
Call RaiseError(MyUnhandledError, "operacao_protected Sub")
End Sub









CAPTULO 13 RATIONAL ROSE 455


Subclasse
Option Explicit

'##ModelId=3A8FB2C901C9
Implements superclasse

'##ModelId=3A8FB64C03CA
Private atributo_subclasse As Integer

'##ModelId=3A8FB622003B
Public Sub operacao_subclasse()
On Error GoTo operacao_subclasseErr
'## Your code goes here ...

Exit Sub
operacao_subclasseErr:
Call RaiseError(MyUnhandledError, "operacao_subclasse Sub")
End Sub

'##ModelId=3A8FBE03026C
Private Sub superclasse_operacao_publica()
On Error GoTo superclasse_operacao_publicaErr
'## Your code goes here ...

Exit Sub
superclasse_operacao_publicaErr:
Call RaiseError(MyUnhandledError,
"superclasse_operacao_publica Sub")
End Sub

'##ModelId=3A8FBE04010F
Private Property Get superclasse_atributo_publico() As Integer
On Error GoTo superclasse_atributo_publicoErr
'## Your code goes here ...

Exit Property
superclasse_atributo_publicoErr:
Call RaiseError(MyUnhandledError,
"superclasse_atributo_publico Property")
End Property

'##ModelId=3A8FBE04028B
Private Property Let superclasse_atributo_publico(ByVal RHS As
Integer)
On Error GoTo superclasse_atributo_publicoErr
'## Your code goes here ...

Exit Property
superclasse_atributo_publicoErr:
456 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Call RaiseError(MyUnhandledError,
"superclasse_atributo_publico Property")
End Property

Podemos observar que tudo o que herdado da superclasse fica na
subclasse com visibilidade privada, o que no deveria acontecer.
Adicionalmente, o mtodo para tratar erros da superclasse e tambm
"herdado" pela subclasse, o que no faz qualquer sentido. Podemos
pois concluir que a gerao de cdigo numa relao de generalizao
no efectuada de forma adequada.
13.7.5 Comentrios Gerao de Cdigo
As funcionalidades de gerao de cdigo e de reverse engineering do
Rose so, de um modo geral, bastantes completas e robustas. As
regras de mapeamento de Visual Basic para Rose para suportar o
processo de reverse engineering encontram-se tambm bem definidas,
e podem ser consultadas detalhadamente nos manuais de referncia do
produto. O conceito de esteretipo assume em todo o processo uma
importncia muito relevante, pois com base nele que efectuado o
mapeamento entre os artefactos do Rose e os componentes do Visual
Basic.
No entanto, existem alguns problemas que no so adequadamente
solucionados. Um tem a ver com a inexistncia de suporte para a
gerao da interface grfica, o que particularmente importante no
caso de ferramentas de modelao que geram cdigo para ambientes
de desenvolvimento grficos, como o caso do Visual Basic. No caso
desta ferramenta, o Rose permite gerar o cdigo para um componente
do tipo "Form", a partir de uma classe com o esteretipo "Form", no en-
tanto toda a parte visual no pode ser gerada.
Um outro aspecto tem a ver com algumas deficincias no processo de
gerao e reverse engineering, relacionadas com o correcto mapea-
mento de relaes do modelo no cdigo. o caso das relaes de
generalizao, cuja concretizao em Visual Basic implica a gerao de
cdigo com certas inconsistncias. No entanto, nossa opinio que tal
CAPTULO 13 RATIONAL ROSE 457


acontece porque o Visual Basic no uma linguagem verdadeiramente
orientada por objectos, tal como a definimos na Seco 3.5, mas
apenas baseada em componentes. Neste sentido, no suporta ade-
quadamente certas funcionalidades como sejam a definio de herana
e o polimorfismo. Este tipo de problemas no acontece, por exemplo,
em Java ou C++.
13.8 Gerao de Modelos de Dados
O Rose disponibiliza vrias funcionalidades para a gerao de
esquemas de bases de dados, essencialmente divididas num processo
de gerao genrico para vrias bases de dados que suportem o SQL
standard, normalizado pela organizao ANSI, e num outro, mais com-
pleto, mas especifico para Oracle verso 8.
No primeiro caso as funcionalidades de modelao esto relacionadas
com o trabalho realizado pelo comit ANSI/SPARC, que, numa tentativa
de normalizar a arquitectura dos modelos de dados das bases de da-
dos, props que estes fossem divididos em trs nveis:
O nvel externo o que est mais prximo do utilizador, e preocupa-
se em especificar a percepo que os utilizadores tm dos dados,
atravs das aplicaes e das interaces que efectuam com os da-
dos.
O nvel interno o que est mais prximo do dispositivo fsico de
armazenamento, sendo, por vezes, referido como nvel fsico.
O nvel conceptual uma forma de estabelecer uma correspondn-
cia entre os outros dois nveis, e concretizado atravs da Data
Definition Language (DDL).
A verso actual do UML no contempla quaisquer mecanismos de base
para a produo de informao para os nveis fsico e conceptual. No
nvel externo, esta linguagem bastante completa: so utilizados os
diagramas de classes e de colaborao, que permitem identificar os
conceitos e as entidades da organizao e respectivas relaes.
Percebendo a importncia que a modelao de dados, ao nvel
conceptual, assume nas ferramentas CASE, a Rational disponibiliza at
verso Rose 2000 um add-in atravs do qual possvel gerar
458 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

esquemas DDL de criao da base de dados para Oracle, SQL Server,
Sybase, Watcom e ANSI SQL. Suporta tambm funcionalidades mais
especficas no caso da base de dados Oracle, atravs de um gerador
especfico. Adicionalmente, existe a possibilidade de desenvolver uma
interface com outras ferramentas mais especializadas nesta rea, como
o caso do ERwin (www.cai.com).
No entanto, e como esta opo no produz resultados completamente
satisfatrios, devido diferena existente entre os conceitos de modela-
o UML e os relacionados com bases de dados, a Rational optou re-
centemente por propor na verso Rose 2001 (que saiu durante a
concluso deste livro e que portanto no foi possvel avaliar) o UML
Profile for Data Modeling [Rational00]. Um perfil UML, tal como foi
definido na Seco 9.4, um mtodo aprovado pela OMG para
adicionar funcionalidades ao UML numa rea especfica, sem neces-
sidade de alterar o metamodelo UML. Este perfil no se encontra re-
conhecido pela OMG.
At verso 2000, o Rose no suportava a funcionalidade de reverse
engeneering a partir de um esquema da base de dados, com a ex-
cepo de funcionalidades especficas para Oracle.
13.8.1 Gerao de Modelos de Dados at ao Rose
2000
Tal como na gerao de cdigo, tambm os modelos de dados das
bases de dados so gerados a partir do conceito de classe, que
concretizado no conceito de tabela, e dos respectivos atributos que
constituem as colunas das tabelas. As relaes entre as classes
permitem definir chaves externas, sendo esta uma das reas em que o
Rose mais lacunas apresentava.
No caso especfico do Oracle 8 so ainda suportadas algumas
funcionalidades adicionais, nomeadamente: (1) a possibilidade de
importar os tipos de dados suportados no SGBD Oracle (a partir do
framework referido na Seco 13.1); (2) a verificao do cdigo de um
esquema e posterior gerao; e (3) importao da estrutura de uma
base de dados existente.
CAPTULO 13 RATIONAL ROSE 459


Os passos necessrios para a gerao de um esquema de uma base
de dados so os seguintes:
Definio das classes, respectivos atributos e relaes. As classes
para as quais se pretender gerar uma tabela devero ser definidas
como persistentes.
Definio de um conjunto de propriedades gerais, que afectam a
gerao do referido esquema e que so designadas por proprie-
dades do projecto. Estas caractersticas devero ser alteradas na
opo Tools-Options, no tabulador intitulado DDL, e seleccionando
na combobox Type a opo "Project" (ver Figura 13.17).
Definio de propriedades de diversos tipos de dados, que
interessam para mapear os atributos das classes em colunas de
tabelas (por exemplo, chaves primrias). Esta parametrizao prvia
deve ser efectuada na mesma opo indicada no ponto anterior,
seleccionando na combobox Type a opo Attribute.
Seleco das classes para as quais se pretende gerar o cdigo de
criao da estrutura das bases de dados.
Gerao do cdigo do esquema de criao de tabelas, para uma
base de dados a indicar.
Definio de Propriedades Gerais

Figura 13.17: Especificao de parmetros para a gerao do script de
uma base de dados em Sql Server.
As propriedades do projecto cuja especificao relevante incluem, en-
tre outras (Figura 13.17):
DataBase: indica o tipo de sistema de gesto de bases de dados por
omisso, para o qual o esquema ser gerado. Os valores possveis
so Oracle, SQL Server, Sybase, Watcom e ANSI SQL.
460 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

PrimaryKeyColumnName: a extenso concatenada ao nome da
classe para a criao do nome da chave primria, no caso em que a
chave primria atribuda pelo Rose.
PrimaryKeyColumnType: o tipo de dados utilizado para a chave
primria gerada pelo Rose.
ViewName: possibilita a definio (opcional) do prefixo a concatenar
a todas as vistas geradas: Se no for definido, no concatenado
nenhum prefixo.
TableName: possibilita a definio (opcional) do prefixo a concate-
nar a todas as tabelas geradas. Se no for definido, no concate-
nado nenhum prefixo.
InheritSuffix: um sufixo adicional (opcional) a ser concatenado aos
nomes das vistas que so produzidas para mapeamento de heran-
a.
DropClause: um valor lgico que, se for verdadeiro, cria um
comando DROP TABLE antes de cada comando CREATE TABLE.
DDLScriptFileName: o nome atribudo, por omisso, ao ficheiro a
gerar e que contem o script DDL.

Definio de Tipos de Dados
O passo da especificao de tipos de dados a utilizar e a associar a
cada atributo particularmente importante, pois a gerao dos
esquemas DDL no tem em conta o tipo de dados dos atributos da
classe, mas aquele que estiver especificado na informao que consta
do tabulador DDL. Por omisso, utilizado um conjunto de valores que
gera o tipo de dados VARCHAR (apesar de se seleccionar a base a
dados para a qual o esquema gerado, o Rose no possui, por
omisso, qualquer informao de validao relativamente aos tipos de
dados suportados por cada SGBD).
CAPTULO 13 RATIONAL ROSE 461



Figura 13.18: Conjunto de atributos que podem ser aplicados a um tipo
de dados
A definio de um conjunto de atributes sets correcto permite tirar maior
partido da gerao automtica e com menos alteraes manuais; estes
atributos incluem (ver Figura 13.18):
ColumnType: permite indicar o tipo de dados da coluna.
Length: indica o tamanho do tipo de dados da coluna, se aplicvel.
NullsOk: indica se a coluna permite valores nulos.
PrimaryKey: indica se a coluna chave primria.
Unique: indica se os valores da coluna devero ser nicos.
Exemplo 1: Gerao de uma Classe
De forma a exemplificar a gerao de cdigo de criao de uma base
de dados, analisemos como o Rose trata um conjunto de situaes
relativamente simples, com base no diagrama de classes da Figura
13.19. No primeiro caso vamos considerar apenas uma tabela, manten-
do a associao do atribute set atribudo por omisso a todos os atribu-
462 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

tos da classe, e corrigindo de seguida esta situao. O SGBD escolhido
para gerao foi o Sql Server.

Figura 13.19: Exemplo de relao entre as classes Requisio e
Linhas_Requiso.
Se considerarmos apenas a classe Requisicao e gerarmos o cdigo
de criao da tabela correspondente aps termos definido os seus atri-
butos e indicando os tipos de dados, obtm-se o esquema da tabela
que consta no exemplo seguinte.

DROP TABLE Requisicao
go

CREATE TABLE T_Requisicao(
numero VARCHAR,
data VARCHAR,
total VARCHAR,
nome_requisitante VARCHAR,
RequisicaoId NUMBER(8),
PRIMARY KEY(RequisicaoId))
go

Como se constata, os tipos de dados das colunas no correspondem
aos homlogos definidos na classe. Isto acontece porque preciso
alterar os atribute sets para cada atributo da classe, o que efectuado
na respectiva especificao, no tabulador DDL (Figura 13.20). Alm
disso, e como no tinha sido definido nenhum atributo do modelo como
chave primria, o Rose encarregou-se de adicionar um novo atributo
tabela T_Requisicao, que funciona como chave primria.
CAPTULO 13 RATIONAL ROSE 463



Figura 13.20: Alterao das propriedades dos atributos para a criao
da tabela.
Na Figura 13.20, existe uma sequncia na ordem dos ecrs, da
esquerda para a direita: o primeiro ecr o da especificao dos atribu-
tos da classe Requisicao; o segundo o da especificao do atributo
numero, que pretendemos que seja a chave primria; e o terceiro o
ecr de definio das propriedades comuns a um determinado conjunto
de atributos, que neste caso definimos como sendo "todos os atributos
que so chaves primrias".

Com a alterao dos attribute sets para cada atributo, a gerao do
esquema DDL para a tabela Requisicao produz os seguintes resul-
tados:


464 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

DROP TABLE T_Requisicao
go
CREATE TABLE T_Requisicao(
numero INTEGER NOT NULL,
data DATETIME,
total INTEGER,
nome_requisitante VARCHAR,
PRIMARY KEY(numero))
go

Exemplo 2: Gerao de Classes Relacionadas
Se a gerao de tabelas isoladas obedece s regras habituais do
modelo relacional, j o mesmo no se pode dizer a partir do momento
em que se definem relaes entre classes, particularmente as relaes
de associao e de generalizao. Numa relao de associao, so
geradas duas tabelas, uma para cada classe. Em cada tabela so
colocadas referncias para a chave primria da outra tabela, como se
ilustra de seguida.

DROP TABLE T_Linhas_Requisicao
go
CREATE TABLE T_Linhas_Requisicao(
numero_linha VARCHAR,
codigo_produto INTEGER,
quantidade INTEGER,
valor_unitario INTEGER,
valor_total INTEGER,
numero INTEGER NOT NULL,
FOREIGN KEY (numero) REFERENCES T_Requisicao,
Linhas_RequisicaoId INT,
PRIMARY KEY(Linhas_RequisicaoId))
go

DROP TABLE T_Requisicao
go
CREATE TABLE T_Requisicao(
numero INTEGER NOT NULL,
data DATETIME,
total INTEGER,
CAPTULO 13 RATIONAL ROSE 465


nome_requisitante VARCHAR,
TEM INT REFERENCES T_Linhas_Requisicao(Linhas_RequisicaoId),
PRIMARY KEY(numero))
go

Para alm dos problemas de coerncia a nvel do modelo relacional,
existem tambm outras situaes em que a gerao no se comporta
adequadamente, tais como:
Na gerao de cdigo para suportar relaes de generalizao.
Neste caso, criada uma vista que relaciona as duas tabelas,
quando na realidade o que seria de esperar era a incluso da chave
primria da tabela da superclasse na tabela da subclasse.
Quando se pretende utilizar a mesma classe para gerar cdigo para
uma linguagem de programao, e para a criao do esquema DDL
correspondente. Isto porque no possvel especificar simultanea-
mente propriedades de gerao para as duas situaes, uma vez
que uma classe s pode estar associada a um componente.
13.8.2 Gerao de Dados a partir do Rose 2001
Precisamente para solucionar os problemas e lacunas identificados, a
partir da verso 2001 o Rose inclui um componente designado Data
Modeler, no sentido de facilitar a modelao especfica de dados. O
UML Data Modeling Profile suportado pelo Data Modeler baseia-se na
definio de esteretipos adicionados s estruturas UML existentes:
Esteretipos acrescentados s estruturas do UML como sejam os
componentes, os pacotes e as classes que permitem a modelao
de bases de dados, esquemas e tabelas.
Esteretipos acrescentados s associaes do UML que permitem a
modelao de relaes.
Esteretipos acrescentados s operaes do UML que permitem a
modelao de chaves primrias, chaves externas, restries de va-
lores nicos, triggers e stored procedures.
466 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

ainda adicionado um novo tipo de diagrama, o diagrama do modelo
de dados, que uma forma lgica de apresentar tabelas, colunas e
relaes criadas a partir da informao que consta do modelo de objec-
tos. Este diagrama gerado a partir de um diagrama de classes, sendo
includas todas as classes definidas como persistentes. Para cada
diagrama do modelo de dados, possvel especificar as propriedades
das tabelas e das colunas, e uma vez que o mapeamento entre
modelos de objectos e de dados no completo, necessrio, por
vezes, efectuar algumas alteraes directamente no modelo de dados,
de forma a normaliz-lo. A partir deste diagrama pode-se gerar um es-
quema da base de dados. Podem ainda ser adicionadas outras proprie-
dades, como restries (constraints) e ndices, que so conceitos espe-
cficos do mundo das bases de dados.
Esta ltima verso do Rose permite efectuar reverse engineering da
estrutura de uma base de dados, e reflecti-la num diagrama de dados.
Ao nvel da estrutura, o mapeamento entre o modelo aplicacional e o
modelo de dados relativamente intuitivo:
A base de dados encontra-se associada a um componente na
component view do Rose (de forma consistente com o que acontece
actualmente com um projecto Visual Basic, tambm associado a um
componente).
Um pacote mapeado num esquema, e este mapeamento que
suporta directamente todo o processo de forward e reverse
engineering da base de dados.
As classes so mapeadas em tabelas, normalmente numa relao
de uma tabela para cada classe, mas que pode ser diferente no
caso de classes com associaes.
Os atributos so mapeados em colunas de uma tabela, sendo
importante a converso dos tipos de dados entre o nvel aplicacional
e os utilizados nas bases de dados, que variam ligeiramente entre
diferentes servidores de bases de dados.
O mapeamento das relaes de associao para as bases de dados
pode ser mais complexo, consoante o tipo de cardinalidade da relao.
Assim:
CAPTULO 13 RATIONAL ROSE 467


Associaes de 1 para 1 entre duas classes do origem a duas
tabelas em que a chave primria de uma tambm chave externa
da outra.
Associaes de 1 para N entre duas classes do origem a duas
tabelas em que a chave primria da tabela principal colocada co-
mo chave externa na outra.
Associaes de M para N entre duas classes do origem a trs
tabelas em que as chaves primrias das tabelas que mapeiam
directamente as classes so colocadas numa terceira tabela, tal
como aconteceria num processo de normalizao do modelo
relacional, garantindo assim a integridade do modelo.
A generalizao entre duas classes (superclasse e subclasse)
mapeada em duas tabelas, em que a chave primria da tabela cor-
respondente superclasse tambm chave primria e externa da outra
tabela.
Estes factos permitem-nos concluir que, pelo menos do ponto de vista
terico e dos conceitos, a ltima verso do Rose veio corrigir os proble-
mas existentes na verso Rose 2000.
468 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

13.9 Gerao da Interface Homem-Mquina
O UML no tem funcionalidades especficas para a gerao da interface
de programas para os utilizadores, quer esta seja grfica quer orientada
ao caracter. No caso especfico do Visual Basic, dispe da possibilidade
de caracterizar o esteretipo de uma classe como sendo do tipo "Form",
verificando-se que de facto gerado correctamente um componente
Form do Visual Basic, com os mtodos que tiverem sido definidos.
Podem ainda ser definidos os controles que ficaro associados ao
Form, ao nvel do modelo, tambm com esteretipos prprios. Contudo,
a parte grfica, de colocao dos controles no Form ter que ser
efectuada no Visual Basic.
13.10 Gerao de Documentao
A documentao uma parte importante do processo de
desenvolvimento de software. O Rose oferece diversas possibilidades
de elaborao de documentao, nomeadamente: (1) a utilizao de
relatrios pr-definidos; (2) a criao de novos relatrios atravs de
scripts; (3) a utilizao de ferramentas especificas para a produo de
relatrios; e (4) a gerao de informao para publicao na Internet.
Os relatrios pr-definidos, em nmero no muito elevado, apresentam
o seu output em formato Word, e incluem informao sobre o esquema
dos modelos, classes, comentrios, operaes, atributos, etc. Existem
tambm vrios relatrios especficos para a base de dados Oracle. Para
completar este conjunto, o Rose disponibiliza vrias ferramentas adicio-
nais que permitem completar as suas capacidades, designadamente:
Rose Web Publisher: para gerao de documentao em formato
HTML.
SoDA: ferramenta da Rational para produo de documentao.
Scripts de gerao de relatrios, com a possibilidade de gerao de
relatrios para outros formatos, como por exemplo Excel.
Se bem que a documentao base seja muito simples, os relatrios
produzidos so relativamente completos em termos do contedo dos
diversos modelos. A gerao efectuada a partir da informao introdu-
zida na janela apresentada na Figura 13.21.
CAPTULO 13 RATIONAL ROSE 469



Figura 13.21: Gerao de documentao do Rose.
13.10.1 Ferramenta SoDA
O Rose pode interagir de forma controlada com ferramentas de
documentao externas. O sistema proposto pela Rational designado
por SoDA (www.rational.com/products/soda), o qual automatiza a
produo da documentao do software, reduzindo substancialmente o
esforo necessrio para a sua elaborao. Segundo a Rational, o SoDA
pode ser integrado com qualquer outra ferramenta, de modo a satisfazer
todas as necessidades de documentao de um projecto.
Para alm de caractersticas como a flexibilidade e a automatizao, a
ferramenta SoDA apresenta ainda as seguintes funcionalidades:
Personalizao de templates de documentos, usando caractersticas
WYSIWYG e caixas de dilogo grficas.
Gerao de documentos a partir de outras ferramentas de
engenharia de software, de forma automtica, a partir de regras con-
figurveis.
Edio de documentos, recorrendo a funcionalidades poderosas de
publicao, de manipulao de texto, incluso de grficos e tabelas
adicionais, etc.
Reviso de documentos.
Publicao de documentos estabilizados.
Integrao com processadores de texto, nomeadamente com o
Word.
Preservao, entre verses sucessivas de um dados documento, de
informao introduzida de forma manual, directamente no docu-
mento.
470 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

Extraco de dados de vrias fontes.
Suporte a diversos standards, nomeadamente, ISO 9000.
Uma das caractersticas diferenciadoras do SoDA a capacidade de
efectuar alteraes, associada possibilidade de desenvolver docu-
mentos de forma iterativa, em simultneo com o desenvolvimento do
prprio sistema. Para alm das caractersticas j enumeradas, o SoDA
apresenta os seguintes benefcios:
Reduz o trabalho manual de edio necessrio para criar e manter
documentao.
Reduz o tempo de produo da documentao.
Aplica uma abordagem iterativa elaborao de documentao.
Mantem a consistncia entre os documentos e a informao de mo-
delao.
Facilita a manuteno de documentao.
13.10.2 Rose Web Publisher
O Rose Web Publisher permite criar uma verso HTML de um modelo
do Rose. Deste modo, possvel visualizar toda a informao de um
modelo, utilizando um browser Internet. Igualmente, possvel publicar
iteraes sucessivas de um modelo, de modo a rever ou a partilhar a
informao. O Rose Web Publisher reproduz os vrios elementos pre-
sentes no Modelo, incluindo diagramas, classes, pacotes, relaes, atri-
butos e operaes.

Figura 13.22: Rose Web Publisher.
O Web Publisher pode ser configurado de modo a publicar apenas um
subconjunto da informao do modelo. Por exemplo, pode-se selec-
CAPTULO 13 RATIONAL ROSE 471


cionar o conjunto de vises que se pretende publicar, o nvel de detalhe
a incluir, a notao a utilizar (ver Figura 13.22).
13.10.3 Scripts de gerao de relatrios
Atravs de programao, possvel melhorar algumas das capacidades
de gerao de documentao do Rose. De facto, j os relatrios base
disponveis no so mais do que um conjunto de scripts, desenvolvidos
em RoseScript.
O exemplo seguinte apresenta um script RoseScript, que efectua a
gerao automtica de documentao de todas as classes de um
determinado modelo.

'-----------------------------------------------------------------
'ExportDoc.ebs
'
' This script exports documentation from a rose model to a
text file. The file is
' created with the following format:
'
' "Classname", "Class documentation"
' "Next class name", "Class documentation"...
'
'-----------------------------------------------------------------
Sub ExportClassDocumentation (FileName As String)
Dim AllClasses As ClassCollection
Dim theClass As Class

Set AllClasses = RoseApp.CurrentModel.GetAllClasses ()

Viewport.Open
Open FileName$ For Output Access Write As #1
For ClsID = 1 To AllClasses.Count
Set theClass = AllClasses.GetAt (ClsID)
Write #1, theClass.Name, theClass.Documentation
Next ClsID
Close #1
Print "Done!"
End Sub

Sub Main
472 CENTRO ATLNTICO COLECO TECNOLOGIAS UML, METODOLOGIAS E FERRAMENTAS CASE

FileName$ = SaveFileName$ ("Export Class Documentation",
"Text files:*.txt")

If FileName$ <> "" Then ExportClassDocumentation
FileName$
End Sub

13.11 Concluso
O Rose sem dvida uma ferramenta a considerar por quem pretende
utilizar a linguagem UML para a modelao de software. uma
ferramenta completa e robusta, em termos da aplicao das regras e
princpios do UML, bem como do desenho dos diversos diagramas. A
sua aprendizagem bsica intuitiva e rpida. Outro ponto forte eviden-
ciado pelo Rose a sua capacidade de extensibilidade, dificilmente rea-
lizvel com outras ferramentas.
Por outro lado, as suas maiores lacunas situam-se em reas para as
quais o prprio UML no dispe de suporte, nomeadamente: (1) a
modelao de pro