CAPITULO 15

O MOVIMENTO
PARA OS OBJETOS

campo da Anlise e Projeto de Sistemas agora incorpora conceitos e tcnicas orientados a

objetos, que visualizam um sistema como uma coleo de objetos autocontidos que incluem dados

e processos. Os objetos podem ser construdos como peas individuais e, em seguida, reunidos
para compor um sistema, conduzindo a esforos de projetos reutilizveis e modulares. Em 1997, a
Linguagem Unificada de Modelagem [Unified Modeling Language UML) foi aceita como a linguagem-padro para o desenvolvimento de objetos. Este captulo descreve os quatro modelos UML
mais eficazes: o diagrama de casos de uso, o diagrama de classes, o diagrama de seqncias e o
diagrama de estado.

OBJETIVOS

Entender os conceitos bsicos da abordagem de objeto e da UML.

Estar apto a criar um diagrama de casos de uso.
Estar apto a criar um diagrama de classe.
Estar apto a criar um diagrama de seqncia.
Estar apto a criar um diagrama de estado.

ESTRUTURA DO CAPITULO
Introduo
A Abordagem de Objeto e a UML
Conceitos de Objeto
Uma Abordagem Orientada a Objeto para
Anlise e Projeto
Os Benefcios
Linguagem Unificada de Modelagem
{Unified Modeling Language UML)
Diagrama de Casos de Uso
Elementos de um Diagrama de Caso de
Uso
Criando um Diagrama de Caso de Uso

Diagrama de Classes
Elementos de um Diagrama de Classes
Simplificando os Diagramas de Classes
Criando um Diagrama de Classes
Diagrama de Seqncias
Elementos de um Diagrama de Seqncias
Criando um Diagrama de Seqncias
Diagrama de Estado
Elementos de um Diagrama de Estado
Criando um Diagrama de Estado
Resumo

INTRODUO
At este ponto, j apresentamos as habilidades de que voc precisar dispor para um projeto de
desenvolvimento de sistemas no mundo real. Voc pode ter certeza de que todos os projetos passam pelas quatro fases planejamento, anlise, projeto e implementao; todos os projetos exigem que voc rena requisitos, modele as necessidades da empresa e crie esquemas para o modo
como o sistema dever ser construdo; e todos os projetos requerem uma compreenso de conceitos de comportamento organizacionais, como gerenciamento de mudana e construo de equipe.
Isso verdade para projetos grandes e pequenos; personalizados ou pacotes; locais e internacionais.
Essas habilidades subjacentes permanecem, em grande medida, inalteradas ao longo do tempo, mas as tcnicas e as abordagens reais que os analistas e desenvolvedores usam podem mudar
e freqentemente mudam muito ao longo do tempo. Como j dissemos no Captulo 1, o
campo da anlise e do projeto de sistemas ainda tem muito espao para avanos: projetos ainda
alguns sistemas ainda falham ao atender a importantes necessidades do usurio. Assim, o estado
da rea de anlise e projeto de sistemas uma das que est em transio constante e avano contnuo. Os analistas e desenvolvedores aprendem com erros e sucessos do passado e evoluem suas
prticas para incorporar novas tcnicas e abordagens que funcionem melhor.
Hoje, a mudana mais emocionante para a anlise e o projeto de sistemas o movimento para
as tcnicas orientadas a objeto. As tcnicas orientadas a objeto vem um sistema como uma coleo de objetos autocontidos, que inclui dados e processos. Esses objetos podem ser construdos
como partes individuais e, em seguida, reunidos para compor um sistema. A beleza dos objetos
que eles podem ser reutilizados repetidamente em muitos sistemas diferentes e alterados sem afetar os outros componentes.
Embora algumas pessoas sintam que o movimento para objetos mudar radicalmente o campo
da anlise e do projeto de sistemas e o SDLC, vemos a incorporao dos objetos como um processo de evoluo no qual as tcnicas orientadas a objetos so gradualmente integradas no SDLC
predominante. Portanto, importante para voc, como analista, entender o que a orientao a
objeto e por que ela est provocando uma reviravolta no setor, assim como conhecer algumas tcnicas orientadas a objeto mais comuns que voc talvez precise usar em projetos.
Este captulo primeiramente fornecer os fundamentos da orientao a objeto e explicar os
diversos conceitos de objeto importantes apoiados pela Linguagem Unificada de Modelagem
(UML), que se tornou o conjunto de padres de tcnicas de modelagem de objetos usado por analistas e desenvolvedores de sistemas. Depois, explicaremos como desenhar quatro dos mais eficazes modelos da UML: o diagrama de casos de uso, o diagrama de classes, o diagrama de seqncias e o diagrama de estado.

A ABORDAGEM DE OBJETO E A UML

At recentemente, os analistas focalizavam dados ou processos de negcio ao desenvolver sistemas. A medida que se desenvolveram pelo SDLC, executando as tcnicas apresentadas nos Captulos 1-14, eles enfatizaram os dados para o sistema (abordagem de dados) ou os processos que
ele executaria (abordagem de processo). Em meados de 1980, os desenvolvedores perceberam que
a construo de sistemas poderia ser muito mais eficiente se os analistas trabalhassem com os dados
e os processos de um sistema simultaneamente e focalizassem a integrao dos dois. As equipes
de projeto comearam a usar uma abordagem de objeto, por meio da qual os mdulos autocontidos,
denominados objetos (contendo dados e processos), eram usados como blocos de construo de
sistemas. As sees seguintes descrevem primeiramente as caractersticas principais da abordagem de objeto, a anlise e o projeto orientados a objeto, os benefcios da abordagem de objeto e,
em seguida, a anlise e o projeto orientados a objeto usando UML.

Conceitos de Objeto
Objetos e Classes Um objeto uma pessoa, local, evento ou coisa sobre a qual queremos capturar
dados e definir processos. Se fssemos construir um sistema de consultas para um consultrio
mdico os objetos poderiam ser os mdicos, os pacientes e as consultas.

O Movimento poro os Objetos

421

Uma classe o modelo que usamos para definir e criar objetos. Cada objeto uma instncia de
uma classe isto , um membro especfico da classe. Por exemplo, podemos criar uma classe
chamada "paciente" com certos atributos de dados (p. ex., nomes, endereos e datas de nascimento) e processos (p. ex., inserir novos pacientes, atualizar informaes e excluir entradas). Os pacientes especficos, como Jim Maloney, Mary Wilson e Theresa Marks, so considerados instncias, ou objetos, da classe paciente (veja a Figura 15-1).
Cada objeto tem atributos que descrevem informaes sobre o objeto, como o nome, a data de
nascimento, o endereo e o nmero de telefone de um paciente. O estado de um objeto definido
pelo valor de seus atributos e seus relacionamentos com outros objetos em um ponto especfico
no tempo. Por exemplo, um paciente poder ter um estado de "novo" ou "atual", ou "antigo".
Cada objeto tem tambm comportamentos. Os comportamentos, implementados por mtodos,
especificam o que o objeto pode fazer. Um mtodo no nada mais do que uma ao ou processo
que um objeto pode executar. Por exemplo, um objeto consulta provavelmente pode marcar uma
nova consulta, excluir uma consulta e localizar a prxima consulta disponvel. Veja a Figura
15-2 para obter a ilustrao de uma classe e seus objetos.
Os objetos no precisam incluir chaves primrias ou chaves externas, como na construo de
modelos de dados relacionais.* Em vez disso, cada instncia de um objeto recebe um identificador nico (UID, unique identifier) dado pelo sistema quando criada. Esse UID freqentemente
oculto do usurio, e s usado pelo sistema para diferenciar uma instncia de objeto da outra,
mesmo que tenham os mesmos valores e mtodos. Portanto, se o sistema tiver criado dois pacientes, ambos com o nome John Smith e com o mesmo endereo (gmeos?), ele ainda assim ser
capaz de distinguir uma instncia de outra porque os UIDs sero diferentes.
Um dos aspectos mais confusos do desenvolvimento de sistemas orientados a objeto o fato
de que na maioria das linguagens de programao orientada a objeto tanto as classes quanto as
instncias de classe podem ter atributos e mtodos. Os atributos e mtodos de classes tendem a ser
usados para modelar atributos (ou mtodos) que lidam com questes relacionadas a todas as instncias de classe. Por exemplo, para criar um novo objeto paciente uma mensagem enviada para
a classe paciente a fim de criar uma nova instncia dele mesmo. Entretanto, a partir do ponto de
vista da anlise e do projeto de sistemas enfocaremos principalmente os atributos e mtodos dos
objetos, e no as classes.

115-1
(teses e Objetos

Objetos

Classes

Uma instncia da classe Paciente

Paciente
-Nome
- Data de Nascimento
- Endereo
-Telefone
+ Inserir ()()
+ Cancelar ()()

1
w

Consulta

Uma instncia de uma classe Consulta

- Nome do paciente
- Nome do mdico
-Data
- Hora
+ Inserir ()()
+ Cancelar ()()

Nome Theresa Marks

Data de Nascimento = 26 de maro de 1965
Endereo = 50 Winds Way, Ocean City, NJ 09009
Telefone = (804) 555-7889

:
:

Nome do paciente - John Smith

Nome do mdico = Dr. David Broussesau
Data = 17 de setembro de 2002
Hora 9-30 A M

Entretanto, baseados nas nossas experincias recomendamos que voc as inclua.

422

Captulo Quinze

FIGURA 1 5 - 2
Classes e Seus Objetos
Mtodos e Mensagens Como dissemos anteriormente, os mtodos implementam o comportamento do objeto. Os mtodos so muito parecidos com uma funo ou procedimento em uma linguagem de programao tradicional, como C, COBOL ou Pascal. As mensagens so as informaes
enviadas para os objetos para acionar os mtodos. Uma mensagem essencialmente uma chamada de funo ou procedimento de um objeto para outro. Por exemplo, se um paciente novo para
o consultrio do mdico, o sistema enviar uma mensagem de insero para o objeto paciente. 0
objeto paciente receber uma mensagem e far o necessrio para inserir o novo paciente no sistema (veja a Figura 15-3).
EncapsulamentO e OcultaO da Informao Encapsulamento significa combinar processo e dados
em um nico objeto. A ocultao de informao o princpio-chave dos sistemas orientados a
objetos, o que significa que apenas as informaes que so necessrias para que um objeto seja
usado se tornam visveis para o usurio do objeto. O modo exato como o objeto armazena os dados e como ele executa um mtodo no tem importncia, desde que o objeto se comporte da maneira esperada. Normalmente, isso significa que so conhecidas apenas as informaes necessrias para a mensagem que aciona um mtodo e as que so retornadas do objeto. Como tal, os objetos so tratados como caixas pretas.
O fato de que podemos usar um objeto chamando mtodos a chave para sua reutilizao, porque
isso protege os trabalhos internos do objeto de alteraes no sistema externo, e impede que o sistema seja afetado quando alteraes forem feitas em um objeto. Na Figura 15-3, observe como

FIGURA 1 5 - 3
Mensagens e Mtodos

Uma mensagem enviada ao aplicativo

O mtodo inserir do objeto responder

mensagem e inserir uma nova
instncia de paciente.

O Movimento paro os Objetos

423

uma mensagem (inserir novo paciente) enviada para um objeto ainda que os mtodos internos
necessrios para responder mensagem estejam ocultos de outras partes do sistema. Tudo que os
objetos precisam saber o conjunto de operaes, ou mtodos, que os outros objetos podem executar e o formato das mensagens que os acionam.
Herana A herana permite que os desenvolvedores definam novas classes reutilizando as classes
existentes e adicionando novos dados e/ou mtodos a eles. As classes so organizadas em uma
hierarquia, de modo que as superclasses (as classes mais gerais) estejam na parte superior e as
subclasses (as classes mais detalhadas que as reutilizam) estejam na parte inferior. Na Figura
15-4 a pessoa uma superclasse para as classes mdico e paciente. Mdico, por sua vez, uma
superclasse para o profissional geral e o especialista. Observe como uma classe (p. ex., mdico)
pode servir como uma superclasse e uma subclasse simultaneamente. O relacionamento entre a
classe e sua superclasse conhecido como relacionamento A-Kind-Of (AKO Um Tipo De). Por
exemplo, na Figura 15-4 um clnico geral um A-Kind-Of mdico que, por sua vez, uma AKind-Of pessoa.
As subclasses herdam os atributos e os mtodos das superclasses acima delas. Isto , cada subclasse contm atributos e mtodos de sua superclasse pai. Por exemplo, a Figura 15-4 mostra que
tanto o mdico quanto o paciente so subclasses de pessoa e, portanto, herdaro os atributos e os
mtodos da classe pessoa. A herana simplifica a definio de classes. Em vez de repetir os atributos e mtodos nas classes mdico e paciente separadamente, os atributos e mtodos comuns a
ambos so colocados na classe pessoa e herdados por aquelas classes abaixo dela. Observe como
as hierarquias das classes de objetos so muito mais eficientes do que os mesmos objetos sem
uma hierarquia na Figura 15-5.
A maioria das classes em toda uma hierarquia levar a instncias, e qualquer classe que tenha
instncias denominada classe concreta. Por exemplo, se Mary Wilson e Jim Maloney fossem
instncias da classe paciente, paciente seria considerada uma classe concreta. Algumas classes
no produzem instncias porque so usadas simplesmente como modelos para outras classes mais
especficas (especialmente aquelas localizadas na parte superior de uma hierarquia). Elas so classes
abstratas. Pessoa seria um exemplo de uma classe abstrata. Em vez de criar objetos a partir de
pessoa, poderemos criar instncias representando as classes mais especficas de mdico e pacien-

Classe abstrata

Classe abstrata

Classe concreta

Classe concreta

424

Captulo Quinze

FIGURA 15-5

Sem herana

Com herana

te, ambas do tipo "pessoa" (consulte a Figura 15-4). Que tipo de classe a classe clnico geral?
Por qu?
Poliltiorf isitlO Polimorfismo significa que a mesma mensagem pode ser interpretada diferentemente
por diferentes classes de objetos. Por exemplo, inserir um paciente significa algo diferente de inserir uma consulta. Dessa maneira, diferentes partes da informao precisam ser coletadas e armazenadas. Felizmente, no temos de nos preocupar com o modo como algo feito quando usamos objetos. Podemos simplesmente enviar uma mensagem para um objeto e esse objeto ser
responsvel pela interpretao apropriada da mensagem. Por exemplo, se enviarmos a mensagem
"desenhe a si prprio" a um objeto quadrado, um objeto crculo e um objeto tringulo, os resultados sero muito diferentes, muito embora a mensagem seja a mesma. Observe na Figura 15-6 como
cada objeto responde apropriadamente (e de modo diferente), muito embora a mensagem seja
idntica.

Uma Abordagem Orientada a Objeto para Anlise e Projeto

As abordagens orientadas a objeto para desenvolver sistemas de informaes podem usar qualquer uma das metodologias anteriores apresentadas no Captulo 1: desenvolvimento em cascata,
desenvolvimento paralelo, desenvolvimento em fases, prottipo, e assim por diante. Entretanto,
as abordagens orientadas a objeto so mais freqentemente associadas metodologia RAD de desenvolvimento em fases ou a uma metodologia gil de programao extrema. Normalmente, no
desenvolvimento orientado a objeto cada verso do sistema percorre todo o SDLC em um perodo
de uma a duas semanas ou um a dois meses, dependendo do tamanho do problema. Para ser capaz
de entregar sistemas em um perodo de tempo to pequeno, qualquer abordagem orientada a objeto para desenvolver sistemas de informao precisa ser (1) baseada em casos de uso, (2) centrada
na arquitetura e (3) iterativa e incrementai.
Baseada em casos de uso significa que os casos de uso so a ferramenta de modelagem principal usada para definir o comportamento do sistema. Eles tambm so usados para desenvolver os
critrios a fim de verificar e validar o sistema em todo o desenvolvimento. Os casos de uso so
transformados em diagramas de casos de uso, que so especificaes grficas do comportamento
do sistema a partir da perspectiva do(s) usurio(s). Eles so usados para identificar e comunicar os
requisitos de alto nvel da empresa para o sistema de forma muito parecida com os DFDs que so
usados para ilustrar graficamente os requisitos de alto nvel da empresa em um mundo no orientado a objeto. Todos os outros detalhes do sistema so derivados dos casos de uso do sistema.
Centrada na arquitetura significa que a arquitetura subjacente do sistema em desenvolvimento se baseia nas especificaes, na construo e na documentao do sistema. Existem trs vises
arquitetnicas separadas, mas inter-relacionadas, de um sistema: funcional, esttica e dinmica.

O ftoiimento para os Otyete

/. Uma mensagem de insero

enviada ao objeto paciente.

! Uma mensagem de insero

I aiiada para o objeto consulta.

2. O mtodo do objeto
responde mensagem.

2. O mtodo do objeto
responde mensagem.

425

3. O aplicativo responde apropriadamente.

3. O aplicativo responde apropriadamente.

U M 5-6
) e Encapsulamento

A viso funcional descreve o comportamento externo do sistema de acordo com a perspectiva do

usurio. Superficialmente, essa viso est relacionada s abordagens de modelagem de processo
na anlise e no projeto estruturado. Entretanto, como veremos, existem diferenas importantes entre
eles. A viso esttica descreve a estrutura do sistema em termos de atributos, mtodos, classes,
relacionamentos e mensagens. Essa viso muito similar s abordagens de modelagem de dados
na anlise e no projeto estruturado. A viso dinmica descreve o comportamento do sistema em
termos de mensagens passadas entre objetos e mudanas de estado dentro de um objeto. Essa viso combina de muitas maneiras as abordagens de modelagem de processo e de dados, no que a
execuo de um mtodo pode provocar mudanas de estado no objeto recebedor.
Os enfoques orientados a objeto enfatizam os desenvolvimentos iterativo e incrementai que
resistem a testes contnuos em toda a vida do projeto. Cada iterao do sistema traz o sistema cada
vez para mais perto das necessidades finais dos usurios.
A diferena principal entre as metodologias de anlise e projeto estruturados e enfoques orientados a objetos na nfase colocada na decomposio de um problema. Nos enfoques da anlise e do
projeto estruturados a nfase est em decompor o problema ao longo do processo ou de linhas funcionais. Isto , os problemas so decompostos em um conjunto de subprocessos que, por sua vez,
so decompostos em subprocessos adicionais. Isso continua at que nenhuma decomposio de processo faa mais sentido. Nos enfoques orientados a objeto a nfase est em decompor o objeto ou
classe. Nas tcnicas estruturadas, como DFDs, as informaes do sistema inteiro esto firmemente
acopladas em um diagrama, s vezes muito complexo, enquanto nos enfoques orientados a objeto
cada objeto pode ser visualizado separadamente, reduzindo assim a complexidade.

Os Benefcios
At aqui, descrevemos os vrios conceitos importantes que permeiam qualquer enfoque orientado a objeto para desenvolvimento de sistemas, mas voc talvez esteja imaginando como esses
conceitos afetam o desempenho de uma equipe de projeto. A resposta simples. Juntos, conceitos
como polimorfismos, encapsulamento e herana permitem que os analistas dividam um sistema
complexo em componentes menores e mais gerenciveis, trabalhem nos componentes individual-

mente e renam os componente de volta mais facilmente para compor o sistema. Essa modulandade
torna o desenvolvimento de sistema mais fcil de compreender, de compartilhar entre os membros de uma equipe de projeto e de comunicar para os usurios, que precisam fornecer requisitos
e confirmar se o sistema est atendendo aos requisitos durante todo o SDLC.
Modularizando o desenvolvimento do sistema, a equipe de projeto est na verdade criando partes
reutilizveis que podem ser juntadas em outros esforos de sistemas ou usadas como pontos de
partida de outros projetos. Por ltimo, isso pode economizar tempo, porque novos projetos no
precisam ser iniciados do zero e as curvas de aprendizado no so mais to acentuadas.
Finalmente, muitas pessoas argumentam que "pensar em objeto" uma maneira muito mais
fundada de pensar sobre o mundo real. Os usurios normalmente no pensam em termos de dados
ou processos; eles vem suas empresas como uma coleo de unidades lgicas que contm ambos
portanto, a comunicao em termos de objetos melhora a interao entre o usurio e o analista
e o desenvolvedor. A Figura 15-7 resume os conceitos principais do enfoque de objeto e como
cada um deles contribui para os benefcios que acabamos de descrever.

Linguagem Unificada de Modelagem

{Unified Modeling Language UML)
At 1990, os conceitos de objetos eram implementados de diferentes maneiras por diferentes
empresas e fornecedores de ferramentas; portanto, os mtodos orientados a objetos eram muito
lentos para se tornarem largamente usados. Mas em 1990 a Rational Software reuniu trs lderes
do setor para criar um enfoque nico para o desenvolvimento de objeto. Grady Booch, Ivar Jacobson
e James Rumbaugh trabalharam com outros desenvolvedores a fim de criar um conjunto de padres de tcnicas de diagramao conhecido como Unified Modeling Language, ou UML (Linguagem de Modelagem Unificada)*. O objetivo da UML proporcionar um vocabulrio comum
dos termos baseados em objeto e tcnicas de diagramao que seja rico o suficiente para modelar
qualquer projeto de desenvolvimento de sistema, desde a anlise at a implementao.
Em novembro de 1997, o Object Management Group (OMG) aceitou formalmente a UML como
o padro para todos os desenvolvedores de objetos. Uma variedade de pacotes de softwares CASE,
como o Rational Rose, da Rational Software Corporation, o Paradigm Plus, da Platinum Technology, o Visible Analyst, da Visible System, o VISIO, da Microsoft Corporation, e o Together Control
Center, da Togethersoft's, trabalham com todos ou alguns dos componentes UML.
Tcnicas de Diagramao UML A UML define um conjunto de nove tcnicas de diagramao de
objetos usadas para modelar um sistema (veja a Figura 15-8). Todas as nove tcnicas de diagramao
usam as mesmas sintaxe e notao, facilitando o aprendizado da linguagem para analistas e
desenvolvedores. As mesmas tcnicas de diagramao so usadas em todas as fases do SDLC
(embora alguns diagramas se tornem mais importantes em algumas fases), com os diagramas se
tornando mais detalhados medida que se deslocam do projeto lgico para o projeto fsico e incluindo detalhes de implementao do sistema. No geral, a notao consistente, a integrao entre
as tcnicas de diagramao e a aplicao de diagramas entre todas as fases do SDLC fazem da
UML uma linguagem poderosa para analistas e desenvolvedores.
O bloco de construo principal da UML o caso de uso. A UML exige que os analistas e
desenvolvedores dividam o sistema em casos de uso, pequenas partes lgicas de sistema, e lidem
com cada uma delas separadamente (ao contrrio da abordagem SDLC tradicional, que requer que
os analistas desenvolvam DFDs e ERDs que tentam abranger o sistema inteiro em um diagrama).
Essa utilizao de muitos casos de uso pequenos torna a UML ideal para representar sistemas
complexos, porque os analistas e projetistas podem enfocar pequenas vises do sistema sem serem inundados pelos detalhes do desenho grande. Entretanto, como os diagramas so fortemente
integrados sinttica e conceitualmente, o modelo UML subjacente representado por todos os diagramas representa o sistema como um todo integrado.
A UML no uma metodologia porque no estabelece formalmente como aplicar as tcnicas
de diagramao. Muitas empresas esto experimentando a UML e tentando entender como incorporar suas tcnicas de diagramao em suas metodologias de anlise e projeto de sistemas. Em
muitos casos, os diagramas UML simplesmente substituem as tcnicas estruturadas mais antigas
*Para obter uma descrio completa de todas as tcnicas de diagramao UML, consulte http://www.rational.com/uml.

O Movimento para os Objetos

Conceito
Classes, objetos, mtodos
e mensagens

Eicapsulamento e ocultao

Admite...

rieiona

o':morfismo

! Baseado em casos de uso

Centrado em are uitetura e

vises funciona , esttica
e dinmica

Desenvolvimento iterativo
e incrementai

Leva a...

Uma maneira mais fundamentada de

as pessoas pensarem sobre suas
empresas
Unidades altamente coesas que
contm dados e processos

Melhor comunicao entre o usurio e o

analista ou desenvolvedor
Objetos reutilizveis
Benefcios de ter um sistema altamente
coeso (consulte coeso, no Captulo 1 2)

Unidades livremente acopladas

Objetos reutilizveis
Menos efeitos de propagao das
alteraes feitas em um objeto ou no
prprio sistema
Benefcios de ter um projeto de sistema
livremente acoplado (consultar acoplamento,
no Captulo 1 2)

Permite que usemos classes como

modelos-padro a partir dos quais
outras classes podem ser construdas

Menos redundncia
Criao mais rpida de novas classes
Padres e consistncia em e entre esforos
de desenvolvimento
Facilidade nas excees de suporte

Mensagens mnimas que so

interpretadas pelos prprios objetos

Programao de eventos mais simples

Facilidade na substituio ou alterao de
objetos em um sistema
Menos efeitos de propagao das alteraes
feitas em um objeto ou no prprio sistema

Permite que usurios e analistas

enfoquem o modo como um usurio
interagir com o sistema para executar
uma nica atividade

Melhor compreenso e reunio das

necessidades do usurio
Melhor comunicao entre usurio e analista

Visualizao do sistema em
desenvolvimento a partir de diversos
pontos de vista

Melhor compreenso e modelagem das

necessidades do usurio
Descrio mais completa do sistema de
informaes

Teste e aperfeioamento contnuos

do sistema em desenvolvimento

Satisfao real das necessidades dos

usurios
Sistemas com mais qualidade

de informao

427

L 15-7

Benefcios do Enfoque de Objeto

(p. ex., os diagramas de classes substituem os ERDs). Isto , o SDLC bsico permanece o mesmo,
mas uma etapa simplesmente executada usando uma tcnica de diagramao diferente. Entretanto, recomendo que se voc for usar a UML deve seguir a metodologia ajustada s tcnicas orientadas a objeto, como o rational unifiedprocess (RUP, processo racional unificado).
0 Processo Racional Unificado [Rational Unified Process) Outras empresas esto adotando novas
tecnologias criadas especialmente para a UML. A Rational Software Corporation, por exemplo,
criou uma metodologia denominada processo racional unificado (rational unified process RUP)
que define como aplicar a UML. O RUP uma abordagem rpida de desenvolvimento de aplicativos
para construir sistemas descritos no Captulo 1 (veja as Figuras 15-9 e 1-5). A primeira etapa da
metodologia a construo de casos de uso para o sistema, que identificam e comunicam os requisitos de alto nvel da empresa para o sistema. Essa etapa direciona o restante do SDLC. Em
seguida, os analistas desenham os diagramas de anlise, posteriormente construindo a anlise at
o projeto e o desenvolvimento. Os diagramas UML partem do conceituai e abstrato e incluem
detalhes que finalmente levaro gerao e ao desenvolvimento do cdigo. Os diagramas comeam mostrando o que para mostrar o como.
O RUP enfatiza o desenvolvimento e o prottipo incrementai e iterativo que passa pelo teste
contnuo por toda a vida do projeto. Na Figura 15-9, cada iterao do sistema o traz cada vez mais
para as necessidades reais dos usurios. Os nove diagramas UML so desenhados e alterados em
todo o processo.

428

Capitulo Quinze

Nome do
Diagrama

O que o
Diagrama
Mostra

O que o
Diagrama
Costuma Fazer

O Diagrama
E Similar a

Fases do Ciclo
de V i d a do
Desenvolvimento
de Sistemas

Diagrama de
casos de uso

A interao entre os
usurios externos e
o sistema

Captura os requisitos
da empresa para o
sistema

Diagrama de
contexto

Os casos de uso
orientam todo o
processo de
desenvolvimento

Diagrama de
classes

A natureza esttica de
um sistema em nvel
de classe

Ilustra os relacionamentos
entre classes modeladas
no sistema

Modelo de data

Anlise, projeto

Diagrama de
objetos

A natureza esttica de
um sistema em nvel
de objeto

Ilustra os relacionamentos
entre objetos
modelados no
sistema; usado quando
instncias reais das
classes quiserem
comunicar melhor o
modelo

Modelo de data

Anlise, projeto

Diagrama de
seqncias

A interao entre classes

para um determinado
caso de uso, organizado
por seqncia de tempo

Modela o comportamento
das classes dentro de
um caso de uso

Modelo de
processo

Anlise, projeto

Diagrama de
colaboraes

A interao entre classes

para um determinado
caso de uso, no
organizado por
seqncia de tempo

Modela o comportamento
das classes dentro de
um caso de uso

Modelo de
processo

Anlise, projeto

Diagrama de
estado

Seqncia de estados
que um objeto pode
assumir, os eventos que
fazem um objeto passar
de estado para estado
e as atividades e aes
significativas que
ocorrem como resultado

Examina o comportamento
das classes dentro de
um caso de uso

Diagrama de
atividades

Um processo empresarial
especfico ou a dinmica
de um grupo de objetos;
fornece uma viso dos
fluxos e o que est
ocorrendo dentro de um
caso de uso ou entre
vrias classes

Ilustra o fluxo de
atividades em um
caso de uso

Anlise, projeto

Diagrama de
componentes

Os componentes fsicos
(ou seja, arquivos exe,
arquivos dll) em um
projeto e onde eles
esto localizados

Ilustra a estrutura fsica

do software

Anlise
arquitetnica,
projeto,
implementao

Diagrama de
distribuio

A estrutura do sistema
em tempo de execuo;
por exemplo, ele pode
mostrar como os
mdulos fsicos do
cdigo so distribudos
entre as vrias
plataformas de hardware

Mostra o mapeamento
do software para os
componentes de
hardware

Anlise
arquitetnica,
projeto,
implementao

FIGURA 1 5 - 8
Diagramas da Linguagem de Modelagem Unificada

Anlise, projeto

O Movimento poro os Objetos

429

Iterao
3
L

15-9

UmoAdaptao da Metodologia de
Desenvolvimento em Fases do Processo

Aspectos Principais Pode-se gastar um livro inteiro explicando como usar a UML para desenvolver sistemas, mas no tenho esse espao aqui. Felizmente, quatro tcnicas de diagramao UML
dominaram os projetos orientados a objetos: os diagramas de casos de uso, os diagramas de classes, os diagramas de seqncias e os diagramas de estado. As outras tcnicas de diagramao so
teis para suas finalidades especficas, mas essas quatro tcnicas formam o ncleo da UML conforme usadas na prtica hoje, e sero o foco deste captulo.
As quatro tcnicas de diagramao so integradas e usadas em conjunto para substituir os DFDs
e ERDs no SDLC tradicional (veja a Figura 15-10). O diagrama de caso de uso normalmente
usado para resumir o conjunto de casos de uso para uma parte lgica do sistema (ou o sistema
todo). Depois, os diagramas de classe, os diagramas de seqncias e os diagramas de estado so
usados para definir ainda mais o sistema em desenvolvimento a partir de vrias perspectivas. O
diagrama de caso de uso sempre criado em primeiro lugar, mas a ordem na qual os outros diagramas so criados depende do projeto e das preferncias pessoais dos analistas. A maioria dos
analistas comea com os diagramas de classe (que mostram quais so os objetos contidos e como
eles esto relacionados, de modo muito parecido com os ERDs) ou os diagramas de seqncias
(que mostram como os objetos interagem dinamicamente, o que muito parecido com os DFDs);
mas, na prtica, o processo iterativo. O desenvolvimento de diagramas de seqncias freqentemente leva a alteraes nos diagramas de classes e vice-versa; portanto, os analistas freqentemente alternam entre os dois, melhorando um de cada vez medida que definem o sistema. De
modo geral, os diagramas de estado so desenvolvidos posteriormente, aps os diagramas de classes terem sido refinados. Neste captulo, comearemos com o diagrama de casos de uso, passaremos para os diagramas de classes e terminaremos com os diagramas de seqncias e os de estado.

430

Capitulo Quinze

O Caso de Uso a base da UML e o Diagrama de

Caso de Uso contm os casos de uso.

Um Diagrama de Estado criado para cada caso complexo no Diagrama de Classes.

FIGURA 1 5 - 1 0
A Integrao dos Quatro Diagramas da UML (Unified Modeling Language)

O Movimento pato os Objetos

431

DIAGRAMA DE CASOS DE USO

Os casos de uso so os principais condutores das tcnicas de diagramao UML. O caso de uso
comunica em um nvel alto o que o sistema precisa fazer, e cada uma das tcnicas de diagramao
UML construda com base nisso, apresentando a funcionalidade de diferentes maneiras, cada
uma delas com uma finalidade diferente (conforme descrito na Figura 15-8). Nas etapas iniciais
da anlise, o analista primeiramente identifica um caso de uso para cada parte principal do sistema e cria a documentao referente, o relatrio de caso de uso, para descrever cada funo detalhadamente. Um caso de uso pode representar diversos "caminhos" que um usurio pode tomar
ao interagir com o sistema; cada caminho referenciado como um cenrio. Os casos de uso e os
diagramas de caso de uso suportam a viso funcional j descrita. Talvez voc queira parar um
pouco e rever o Captulo 5 sobre casos de uso, antes de continuar com o restante do captulo.
Por enquanto, aprenderemos como o caso de uso o bloco de construo para o diagrama de
caso de uso, que resume todos os casos de uso (para a parte do sistema que est sendo modelada)
em uma nica figura. Um analista pode usar o diagrama de caso de uso para compreender melhor
a funcionalidade do sistema em um nvel muito alto. Normalmente, o diagrama de caso de uso
desenhado primeiro no SDLC, quando o analista est reunindo e definindo os requisitos para o
sistema, porque ele fornece um modo simples e direto de comunicar aos usurios exatamente o
que o sistema far (isto , no mesmo ponto do SDLC como criaramos um DFD).
Esta seo descrever primeiramente a sintaxe usada no diagrama de caso de uso e, em seguida, demonstrar como constru-lo usando um exemplo da CD Selections.

Elementos de um Diagrama de Caso de Uso

Um diagrama de caso de uso ilustra de maneira muito simples as funes principais do sistema e os
diferentes tipos de usurios que interagiro com ele. Por exemplo, a Figura 15-11 apresenta um diagrama de caso de uso para um sistema de consultas em um consultrio mdico. Podemos ver no
diagrama que os pacientes, os mdicos e o pessoal administrativo usaro o sistema de consultas para
marcar consultas, registrar disponibilidades e produzir informaes de agenda, respectivamente.
Ator As figuras rotuladas no diagrama representam os atores (veja a Figura 15-12). Um ator similar a uma entidade externa encontrada em DFDs ele uma pessoa ou outro sistema com o qual o
sistema interage e do qual deriva valor. Um ator no um usurio especfico, mas uma funo que
um usurio pode desempenhar enquanto interage com o sistema. Os atores so externos ao sistema,
portanto se estivssemos modelando um sistema de consultas do consultrio mdico um funcionrio de entrada de dados (ou uma enfermeira que digita as informaes do paciente) no seria considerado um ator, porque estaria dentro do escopo do sistema propriamente dito (essa a mesma regra

432

Captulo Quinze

FIGURA 1 5 - 1 2
Sintax| do Diagrama de Caso de Uso

Termo e Definio
Um ator
uma pessoa ou sistema do qual o benefcio derivado, e externo ao
sistema
rotulado com sua funo
Pode ser associado a outros atores usando uma associao
especalizao/superclasse, indicada por uma seta com uma ponta vazada
colocado fora dos limites do sistema

Smbolo

Nome do papel do ator

Um caso de uso
Representa uma parte importante da funcionalidade do sistema
Pode estender outro caso de uso
Pode usar outro caso de uso
colocado dentro dos limites do sistema
rotulado com uma frase nome-verbo descritiva

/
Nome do \
V caso de uso J

Um limite do sistema
Inclui o nome do sistema dentro ou acima dele
Representa o escopo do sistema

Nome do sistema

Uma associao
Vincula um ator ao(s) caso{s) de uso com
o qual ele interage

para as entidades externas do DFD). O diagrama da Figura 15-11 mostra que trs atores interagiro
com o sistema de consultas (um paciente, um mdico e um administrador).
s vezes, um ator desempenha uma funo especializada de um tipo mais geral de ator. Por
exemplo, pode acontecer de um novo paciente interagir com o sistema de uma maneira um pouco
diferente de um paciente geral. Nesse caso, um ator especializado (ou seja, novo um paciente)
pode ser colocado no modelo, mostrado por uma linha com um tringulo vazio no final da
superclasse mais geral do ator (isto , paciente). O ator especializado herdar o comportamento
da superclasse e o estender de alguma maneira (veja a Figura 15-13). Voc pode imaginar como
um novo paciente pode se comportar de maneira diferente de um paciente existente?
Caso de Uso Um caso de uso, representado por uma elipse, um processo principal que o sistema
executar que beneficia um ator(es) de alguma maneira (veja a Figura 15-12), e rotulado por
uma frase que usa um verbo descritivo (muito parecido com um processo DFD). Podemos dizer a
partir da Figura 15-13 que o sistema tem trs casos de uso principais: marcar consulta, produzir
informaes de agenda e registrar disponibilidade.

Sistema de Consultas

Novo
paciente

FIGURA 1 5 - 1 3
Diagrama de Caso de Uso com Ator
Especializado

Mdico

O Movimento paro os Objetos

433

H ocasies em que um caso de uso usar ou estender a funcionalidade de outro caso de uso
no diagrama, e isso mostrado usando as associaes inclui ou estende. mais fcil entender
essas associaes com a ajuda de exemplos. Vamos presumir que cada vez que os pacientes marcam uma consulta eles so solicitados a confirmar seus contatos e suas informaes bsicas para
garantir que o sistema sempre contenha as informaes mais atualizadas sobre seus pacientes.
Portanto, podemos incluir um caso de uso denominado atualizar informaes de paciente que
estende o caso de uso marcar consulta para incluir a funcionalidade que acabamos de descrever.
Observe como uma seta vazia foi desenhada na Figura 15-14, entre "atualizar informaes de
paciente" e "marcar consulta", a fim de indicar o relacionamento estende.
Da mesma maneira, h ocasies em que um nico caso de uso pode conter funes comuns que
so usadas por outros casos de uso. Por exemplo, suponha que haja um caso de uso denominado
administrar agenda que execute algumas tarefas de rotina necessrias para atualizar a agenda de
consultas do consultrio mdico, e os dois casos de uso registrar disponibilidade e produzir informaes de agenda executem as tarefas de rotina. A Figura 15-14 mostra como podemos projetar o sistema para que administrar agenda seja um caso de uso compartilhado pelos outros. Uma
seta vazada novamente usada para indicar a associao inclui.
Limite 00 Sistema Os casos de uso so colocados dentro de um limite do sistema, que uma caixa
que representa o sistema e delineia claramente que partes do diagrama so externas ou internas a
ele (veja a Figura 15-12). O nome do sistema pode aparecer dentro ou acima da caixa.
Associao Finalmente, os casos de uso so conectados a atores por meio de associaes, que
mostram com que casos de uso os atores interagem (consulte a Figura 15-12). Uma associao
representada por uma linha desenhada a partir de um ator at um caso de uso, e normalmente
mostrada como uma relao um para um sem direo.

Criando um Diagrama de Caso de Uso

Vamos demonstrar como desenhar um diagrama de caso de uso utilizando o sistema da Internet
da CD Selections. Voc poder observar que o diagrama de caso de uso comunica informaes
muito similares s encontradas no contexto do DFD e de diagramas nvel 0. Na verdade, voc
talvez queira comparar o diagrama de caso de uso que estamos prestes a desenhar com os diagramas que foram criados no Captulo 6.
Identificar Casos de Uso Antes que um diagrama de casos de uso possa ser criado, recomendvel
que se execute um processo de identificao dos casos de uso que correspondam funcionalidade
principal do sistema e que seja reunida a documentao de cada um deles. A maneira de criar casos

Sistema de Consultas

FIGURA 1 5 - 1 4
Associaes Estende e Inclui

434

Capitulo Quinze

Nome do caso de uso:

f a z e r s o l i c i t a e s de C P s

Nmero da ID:

Descrio resumida:
d e s c r e v e como os c l i e n t e s p o d e m p e s q u i s a r o Web s i t e e f a z e r s o l i c i t a e s
p a r a r e s e r v a r CDs em estoc\ue ou f a z e r p e d i d o s e s p e c i a i s
Acionador: c l i e n t e p e s q u i s a Web e f a z s o l i c i t a o sara r e s e r v a r um CD ou p e d i r um CD especial
Tipo:

Q E x t e r n O Temporal

Entradas Principais:

Sadas Principais:

Descrio

Origem

Descrio

Destino

Pesquisar solicitao

Cliente

Pedido especial

BPs de pedidos esp.

CPs selec. por solicitao

Cliente

Reserva para CP em estoque

BD de res, na loja

Informaes do cilente

Cliente

CPs corresp. solic. de pesquisa Cliente

Materiais promocionais

BP Marketing

CDs solicitados

Solicitao de inf. de CO

Cliente

Informaes de CP

Cliente

Estoque de CP

BP Estoque

Materiais promocionais

Ciente

Cliente ;

|
Etapas
Principais:

Nmero da ID:

Nome do caso de uso: atualizar materiais promocionais

Descrio resumida: adicionar, excluir e modificar o material promocional adicional dos fornecedores (p.
ex., revistas, clipes de msica)
Acionador: materiais de fornecedores, distribuidores, atacadistas, gravadoras e artigos em revistas
comerciais

_____
______
_____
_
Tipo:

C j f r t e r n c T ^ Temporal
Sadas Principais:

Entradas Principais:
Origem

Descrio

Descrio

Destino

Materiais promocionais

Fornecedor

Materials

Materiais promocionais

Gerente de marketing

Relatrio de mat. promoc.

Informaes de CP

BP de CP

informaes de fornecedor

Fornecedor

promocionais

BP de marketing

Ger. de marketing

Nmero da ID:

Nome do caso de uso: p r o c e s s a r r e s e r v a s na loia

Descrio resumida: a l e r t a r a equipe da loja p a r a t i r a r um CD s o l i c i t a d o da p r a t e l e i r a e c o l o c - l o

na seo de pedidos especiais
Etapas

Acionador: s o l i c i t a o d e reserva d o c a s o d e u s o p a r a f a z e r s o l i c i t a o

Principais:
Tipo: C ^ ^ t e r n c T ^ ) Temporal
Entradas Principais:

Sadas Principais:

Descrio

Origem

Destino

BP de reserva na loja

Rtulo da reserva

Equipe na loja

Confirmao de reserva

Equipe na loja

Alerta de solic. de reserva

Equipe na loja

Confirmao de reserva

BP de reserva na loja

Ajuste de estoque

BP de estoque

Etapas Principais Executadas

FIGURA 1 5 - 1 5
Casos de Uso Finais da CD Selections

Descrio

Solicitao de reserva

Informaes para Etapas

O Movimento poro os Objetos

435

15-1 IDENTIFICANDO ASSOCIAES DE CASO DE USO E ATORES ESPECIALIZADOS

VEZ
O diagrama de casos de uso do sistema de Internet no inclui
associaes de caso de uso especiais (p. ex., estende ou inclui)
ou atores especializados. Veja se consegue pensar em um exemplo para cada um desses casos especiais cuja incluso no dia-

grama de casos de uso possa ser til para a CD Selections.

Descreva como o esforo de desenvolvimento pode se beneficiar da incluso de seus exemplos.

.. _ .

de uso foi explicada no Captulo 5, e recomendamos que voc consulte aquele captulo agora, se
quiser refrescar sua memria. Caso ainda se lembre, estvamos considerando que o sistema de
Internet da CD Selections precisaria admitir os trs casos de uso que so apresentados na Figura
15-15.
Desenhar 0 Limite do Sistema Primeiro, insira uma caixa no diagrama de casos de uso para representar o sistema e inclua o nome dele dentro ou acima da caixa. Isso formar o limite do sistema,
separando os casos de uso (especificamente, a funcionalidade do sistema) dos atores (isto , as
funes dos usurios externos).
Inserir OS Casos de Uso no Diagrama A prxima etapa adicionar os casos de uso dentro do limite
do sistema. No deve haver mais do que seis a oito casos de uso no modelo; portanto, se voc
identificar mais do que oito deve agrup-los em pacotes (especificamente, grupos lgicos de casos de uso) para facilitar a leitura dos diagramas e manter os modelos em um nvel aceitvel de
complexidade.
Nesse momento, associaes especiais de casos de uso (inclui ou estende) devem ser adicionadas ao modelo. Elas podero ser identificadas se procurarmos os casos de uso que possam apresentar uma funcionalidade em comum que outros casos de uso precisem (isto , uma associao
inclui) ou casos de uso que acrescentem a outros uma funcionalidade adicional (ou seja, uma associao estende). O modelo atual no inclui exemplos dessas associaes.
Identificar OS Atores Uma vez que os casos de uso tenham sido inseridos no diagrama, voc ter de
identificar os atores. Recomendamos que voc examine as origens e os destinos das principais
entradas e sadas identificadas nos casos de uso. Embora algumas origens e destinos citem componentes internos do sistema (p. ex., banco de dados de materiais promocionais, banco de dados
de informaes de CDs), muitas outras fazem referncia a atores (como cliente, fornecedor). Examine os relatrios dos casos de uso da Figura 15-15 e veja se consegue identificar os atores que
pertencem ao diagrama de caso de uso.
Voc deve ter listado sistema de pedidos especiais, gerente de marketing, cliente da equipe
local e fornecedor. Ainda no h atores especializados que precisem ser includos.
Adicionar Associaes A ltima etapa desenhar linhas conectando os atores aos casos de uso com os
quais eles interagem. Nenhum pedido sugerido pelo diagrama, e os itens adicionados no decorrer
do trabalho no precisam ser inseridos em uma ordem especfica; portanto, voc pode preferir reorganizar um pouco os smbolos para reduzir a quantidade de linhas cruzadas, de modo que o diagrama fique menos confuso. A Figura 15-16 apresenta o diagrama de casos de uso que criamos.

DIAGRAMA DE CLASSES
A prxima tcnica importante de diagramao o diagrama de classes. O diagrama de classes
um modelo esttico que d suporte visualizao esttica do sistema que est sendo desenvolvido. Ele mostra as classes e os relacionamentos entre classes que permanecem constantes no sistema com o passar do tempo. O diagrama de classes muito semelhante ao diagrama de relacionamento de entidades (ERD, entity relationship diagram) do Captulo 7; no entanto, ele representa
classes, que incluem atributos, comportamentos e estados, enquanto as entidades do ERD s incluem atributos. O escopo de um diagrama de classes, assim como o ERD, abrange todo o siste-

436

Capitulo Quinze

Sistema de Internet

FIGURA 15-16

Sistema de Internet da CD Selections

ma. Primeiramente as sees a seguir apresentaro a sintaxe do diagrama de classes, e depois a

maneira como um diagrama de classes desenhado.

Elementos de um Diagrama de Classes

A Figura 15-17 mostra um diagrama de classes que foi criado para refletir as classes e os relacionamentos que so necessrios ao conjunto de casos de uso que descrevem o sistema de consultas
dos Captulos 5 e 6.
Classe O principal bloco de construo de um diagrama de classes a classe, que armazena e
gerencia informaes do sistema (veja a Figura 15-18). Durante a anlise, as classes faro referncia a pessoas, locais, eventos e tudo mais sobre o que o sistema capturar informaes. Posteriormente, durante as fases de projeto e implementao, as classes podero fazer referncia a elementos especficos da implementao, como janelas, formulrios e outros objetos usados na construo do sistema. Cada classe desenhada com o uso de retngulos divididos em trs partes com
o nome da classe na diviso superior, os atributos no meio e os mtodos (tambm chamados de
operaes) na parte inferior. Voc deve conseguir identificar que Pessoa, Funcionrio, Doutor,
Enfermeira, Equipe Administrativa, Equipe Mdica, Paciente, Histrico Mdico, Consulta, Conta, Tratamento, Doena e Sintoma so classes na Figura 15-17. Os atributos de uma classe e seus
valores definem o estado de cada objeto que criado a partir da classe, e o comportamento representado pelos mtodos.
Os atributos so propriedades da classe sobre a qual desejamos capturar informaes (veja a
Figura 15-18). Observe que a classe Pessoa da Figura 15-17 contm os atributos sobrenome, pri-

15-2 DESENHANDO UM DIAGRAMA DE CASOS DE USO

VEZ
Crie um diagrama de casos de uso para o sistema descrito a
seguir:
Os proprietrios de apartamentos preenchem formulrios informativos sobre as unidades para alugar que tm disponveis
(p. ex., local, quantidade de quartos, aluguel mensal) que so
inseridos em um banco de dados. Os alunos podem pesquisar
esse banco de dados pela W e b para encontrar apartamentos

que atendam suas necessidades (p. ex., um apartamento de dois

quartos por $ 4 0 0 ou menos, por ms, dentro de 8 0 0 metros do
campus). Em seguida, eles podero contatar os proprietrios
diretamente para ver o apartamento e possivelmente alug-lo.
Os proprietrios ligaro para o servio para que este exclua o
apartamento de sua listagem quando ele estiver alugado.

FIGURA 1 5 - 1 7
Diagrama de Classes do Gerenciamento
de Consultas

meiro nome, endereo, telefone, data de nascimento e idade. Haver situaes em que voc pode
querer armazenar atributos derivados, que so atributos que podem ser calculados ou derivados a
partir de outros atributos e, portanto, no so armazenados. Os atributos derivados so indicados
pela insero de uma barra (/) na frente do nome do atributo. Observe que a classe pessoa contm
um atributo derivado chamado "/idade", que pode ser obtido subtraindo-se a data de nascimento
da pessoa da data atual. Tambm possvel mostrar a visibilidade do atributo no diagrama. Ela
est relacionada ao nvel de informaes ocultas a serem agregadas ao atributo. A visibilidade de
um atributo pode ser pblica (+), protegida (#) ou privada (). Um atributo pblico aquele que
no est oculto para nenhum outro objeto. Dessa forma, outros objetos podem alterar seu valor.
Um atributo protegido o que fica oculto para todas as outras classes, exceto suas subclasses
imediatas. Um atributo privado o que fica oculto para todas as outras classes. A visibilidadepadro de um atributo normalmente privada.
Os mtodos so aes ou funes que uma classe pode executar (veja a Figura 15-18). As funes que esto disponveis para todas as classes (p. ex., criar uma nova instncia, devolver um
valor para um atributo especfico, configurar um valor para um atributo especfico ou excluir
uma instncia) no so exibidas explicitamente dentro do retngulo da classe. Em vez disso, s os
mtodos que forem exclusivos para a classe sero includos, como os mtodos "cancelar sem aviso" e "gerar taxa de cancelamento" da Figura 15-17. Observe que as duas operaes so seguidas

438

Capitulo Quinze

FIGURA 1 5 - 1 8
Sintaxe do Diagrama de Classes

1
Termo e Definio

Smbolo

Uma classe
Representa um tipo de pessoa, local ou coisa que o sistema deve capturar e
armazenar informaes
Tem um nome inserido em negrito e centralizado em seu compartimento
superior
Apresenta uma lista de atributos em seu compartimento do melo
Tem uma lista de operaes em seu compartimento inferior
No exibe explicitamente operaes que estejam disponveis para todas as
classes

Nome do atributo
/nome do atributo derivado ,

Um atributo
Representa propriedades que descrevem o estado de um objeto
Pode ser derivado de outros atributos, o que representado pela insero de
uma barra antes do nome do atributo

Nome do atributo
/nome do atributo derivado

Um mtodo
Representa as aes ou funes que uma classe pode executar
Pode ser classificado como uma operao construtora, de consulta ou de
atualizao
Inclui parnteses que podem conter parmetros especiais ou informaes
necessrias execuo do mtodo
Uma associao
Representa um relacionamento entre vrias classes ou de uma classe com
ela mesma
nomeada com o uso de uma sentena verbal ou o nome de uma funo, o
que melhor representar o relacionamento
Pode existir entre uma ou mais classes
Contm smbolos de multiplicidade, que representam as quantidades mnima
e mxima pelas quais a instncia de uma classe pode ser associada
instncia da classe relacionada

s da classe

Nome da operao()

Nome do mtodo()

' sentena verbal

-1

por parnteses. Os mtodos devem ser exibidos com parnteses que estejam vazios ou preenchidos com algum valor que represente um parmetro que o mtodo precise para agir. Como ocorre
com os atributos, a visibilidade de uma operao pode ser designada como pblica, protegida ou
privada. Normalmente a visibilidade-padro para uma operao pblica.
H trs tipos de mtodos que uma classe pode conter: construtor, consulta e atualizao. O
mtodo construtor cria uma nova instncia de uma classe. Por exemplo, a classe paciente pode ter
um mtodo chamado inserir() que crie uma nova instncia dela. J que um mtodo disponvel para
todas as classes (p. ex., criar uma nova instncia) no exibido nos diagramas de classe, voc no
ver os mtodos construtores na Figura 15-17.
Um mtodo de consulta gera informaes sobre o estado de um objeto disponvel para outros
objetos, mas ele no alterar o objeto de forma alguma. Por exemplo, o mtodo "calcular ltima
visita()", que determina quando um paciente visitou pela ltima vez o consultrio mdico, resultar no objeto sendo acessado pelo sistema, mas no far nenhuma alterao em suas informaes. Se um mtodo de consulta simplesmente solicitar informaes de atributos da classe (p. ex.,
nome, endereo ou telefone de um paciente), ele no ser exibido no diagrama porque partimos
da premissa de que todos os objetos tm operaes que produzem os valores de seus atributos.
Um mtodo de atualizao alterar o valor de algum ou de todos os atributos do objeto, o que
pode resultar em uma alterao no estado do objeto. Considere a alterao do status de um paciente de novo para existente com um mtodo chamado "mudar statusQ" ou a associao de um
paciente que tenha uma consulta especfica com consulta agendada (consulta).
Relacionamentos Uma finalidade primria do diagrama de classes exibir os relacionamentos, ou
associaes, que as classes apresentam entre si. Eles so representados no diagrama pelo desenho
de linhas entre as classes (veja a Figura 15-18). Essas associaes so muito semelhantes aos relacionamentos encontrados no ERD. Os relacionamentos so mantidos por referncias, que so
semelhantes aos ponteiros e armazenadas internamente pelo sistema (diferente dos modelos relacionais, em que os relacionamentos so mantidos com o uso de chaves externas e primrias).
Quando vrias classes compartilham um relacionamento (ou uma classe compartilha um relacionamento com ela mesma), uma linha desenhada e rotulada com o nome do relacionamento

O Movimento poro os Objetos

439

ou das funes que as classes executam no relacionamento. Por exemplo, na Figura 15-17 as classes paciente e consulta so associadas sempre que um paciente agendar uma consulta. Portanto,
uma linha denominada agenda conecta paciente e consulta, representando exatamente como as
duas classes esto relacionadas entre si. Alm disso, observe que h um pequeno tringulo slido
ao lado do nome do relacionamento. O tringulo permite que uma direo seja associada ao nome
do relacionamento. Na Figura 15-17 o relacionamento agenda apresenta um tringulo, indicando
que esse relacionamento deve ser lido na forma paciente agenda consulta. A incluso do tringulo apenas melhora a legibilidade do diagrama.
H situaes em que uma classe se relaciona com ela mesma, como no caso de um paciente
que o titular principal do seguro de outros pacientes (sua esposa e filhos, p. ex.). Na Figura
15-17, observe que uma linha foi desenhada ligando a classe paciente a ela mesma e denominada
titular principal do seguro, para representar a funo que a classe desempenha no relacionamento. Observe que um sinal de adio (" + ") foi inserido antes do nome para demonstrar que se trata
de uma funo, e no do nome do relacionamento. Ao rotular uma associao, use o nome de um
relacionamento ou de uma funo (porm no os dois), escolhendo aquele que demonstrar uma
representao mais completa do modelo.
Os relacionamentos tambm apresentam multiplicidade, que mostra como a instncia de um objeto pode ser associada a outras instncias. Nmeros so inseridos no trajeto da associao no formato quantidade mnima quantidade mxima para representar o mnimo e o mximo de instncias
que podem estar relacionadas por meio dela (veja a Figura 15-19). Isso idntico modalidade e
cardinalidade de um relacionamento no ERD. Os nmeros especificam o relacionamento a partir da
extremidade da classe na linha do relacionamento at a extremidade que apresenta o nmero. Por
exemplo, na Figura 15-17 h um "0.." na extremidade da consulta do relacionamento paciente agenda consulta. Isso significa que um paciente pode estar associado ao algarismo zero a partir de muitas
consultas diferentes. Na extremidade do paciente, nesse mesmo relacionamento, h um nmero " 1 " ,
significando que uma consulta deve estar associada a um e somente um (1) paciente.
H situaes em que o prprio relacionamento possui propriedades associadas, principalmente
quando suas classes compartilham um relacionamento muitos para muitos. Nesses casos, formada uma classe, denominada classe de associao, que possui seus prprios atributos e mtodos. Isso muito semelhante entidade de interseo que inserida em um ERD. Ela exibida
como um retngulo ligado ao caminho da associao por uma linha tracejada com o nome do retngulo igual ao da associao; a ttulo de exemplo, veja a associao tratamento da Figura 15-17.
FIGURA 1 5 - 1 9
plicidade
Instncia(s)

Representao da(s) Instncia(s)

Diagrama Envolvendo Instncia(s)

Exatamente
uma

Nenhuma ou
mais

0..*

Uma ou mais

1..*

Nenhuma ou
mais

0..1

Funcionrio '

Intervalo
especificado

2..4

Funcionrio "

Vrios
intervalos
intercalados

1..3.5

Departamento

Funcionrio 1

Chefe

Funcionrio

""

Explicao do Diagrama

Chefe

Um departamento tem um e
somente um chefe.

"

Filho

Um funcionrio tem de nenhum

a muitos filhos.

2 4

1..3,5

Fuiiciuniiu

Um chefe responsvel por

um ou mais funcionrios.

Esposa

Um funcionrio pode no ser

casado ou ter uma esposa.

Folias

Um funcionrio pode tirar de

duas a quatro frias a cada arto^

Comit

Um funcionrio pode ser

membro de um a trs ou cinco
comits.

440

Capitulo Quinze

Considere o caso da captura de informaes sobre doenas e sintomas. Uma doena (p. ex., a gripe)
pode estar associada a muitos sintomas (como dor de garganta e febre), e um sintoma (dor de garganta) pode estar associado a muitas doenas (como gripe, faringite e o resfriado comum). A Figura
15-17 mostra como uma classe de associao pode capturar informaes sobre tratamentos que podem ser diferentes, dependendo das vrias combinaes. Por exemplo, uma dor de garganta causada
por faringite demandar antibiticos, enquanto o tratamento de uma dor de garganta proveniente de
gripe ou resfriado poderia ser feito com pastilhas expectorantes ou ch quente. Na maioria das vezes, as classes se relacionam por meio de uma associao "normal", mas h dois casos especiais de
associao que voc ver surgir com bastante freqncia: a generalizao e a agregao.
Generalizao e Agregao A generalizao mostra que uma classe (subclasse) herda caractersticas de outra classe (superclasse), significando que as propriedades e operaes da superclasse
tambm so vlidas para objetos da subclasse. O trajeto da generalizao exibido com uma linha
slida partindo da subclasse para a superclasse e uma seta vazada apontando para a superclasse.
Por exemplo, a Figura 15-17 demonstra que mdicos, enfermeiras e equipe administrativa so
todos tipos de, funcionrios, e que esses e os pacientes so tipos de pessoas. O relacionamento de
generalizao ocorrer quando voc precisar usar palavras como " um tipo de" para descrever o
relacionamento.
A agregao usada quando as classes realmente possuem outras classes. Por exemplo, considere um consultrio mdico que tenha decidido criar equipes de assistncia mdica que incluam
mdicos, enfermeiras e pessoal administrativo. Quando os pacientes chegam ao consultrio so
encaminhados a uma equipe de assistncia mdica que cuidar de suas necessidades durante as
consultas. A Figura 15-17 mostra como esse relacionamento representado no diagrama de classes. Um losango inserido bem prximo da classe representando a agregao (equipe mdica), t
linhas so desenhadas a partir dele para conectar as classes que servem como suas partes (mdicos, enfermeiras e equipe administrativa). Normalmente, os relacionamentos de agregao sero
identificados quando voc precisar usar palavras como "faz parte de" ou " composto de" para
descrever o relacionamento.

Simplificando os Diagramas de Classes

Quando um diagrama de classes for desenhado com todas as classes e relacionamentos em um
sistema do mundo real, ele pode se tornar muito complexo. Quando isso ocorre, s vezes necessrio simplificar o diagrama usando um contexto para limitar a quantidade de informaes exibidas. Os contextos so simplesmente subconjuntos das informaes contidas no modelo completo.
Por exemplo, um contexto de caso de uso mostra somente as classes e relacionamentos que so
necessrios a um caso de uso especfico. Outro contexto poderia exibir somente um tipo especfico de relacionamento, como uma agregao, associao ou generalizao. Um terceiro tipo de
contexto poderia restringir as informaes exibidas apenas quelas associadas a uma classe especfica, como seu nome, atributos e/ou mtodos.
Uma segunda abordagem para simplificar os diagramas de classes por meio do uso de pacotes (isto , grupos lgicos de classes). Para tornar os diagramas mais fceis de ler e manter os
modelos em um nvel aceitvel de complexidade, voc pode agrupar em pacotes as classes relacionadas. Os pacotes so estruturas gerais que podem ser aplicadas a qualquer elemento dos modelos UML. J os discutimos anteriormente como uma maneira de simplificar os diagramas de casos de uso, e eles tambm podem ser usados para simplificar os diagramas de classes.

Criando um Diagrama de Classes

Criar um diagrama de classes (como qualquer diagrama UML) um processo iterativo em que o
analista comea desenhando um esboo do diagrama e o aperfeioa com o tempo. Conduziremos
voc na iterao da criao de um diagrama de classes, esperando que o diagrama se altere drasticamente conforme voc se comunica com os usurios e aumenta sua compreenso do sistema.
Identificar Classes As etapas na criao de um diagrama de classes so bem semelhantes s que
aprendemos para criar um ERD. Primeiro voc ter de identificar que classes devem ser inseridas
no diagrama. Lembre-se, como os ERDs, os diagramas de classes exibem as classes que so ne-

O Movimento pato os Objetos

441

Substantivos > sugerem objetos ou classes

Um substantivo comum ou imprprio sugere uma classe

Por exemplo, "um funcionrio atende o cliente" sugere duas classes

de objetos, funcionrio e cliente

de objetos
Um substantivo prprio ou uma referncia direta sugere

Por exemplo, "John abordou os problemas levantados por Susan"

sugere duas instncias de um objeto, John e Susan

a instncia de uma classe

Um substantivo coletivo sugere uma classe de objetos

Por exemplo, "A lista de alunos no foi verificada" sugere que uma lista

composta de grupos de instncias de outra classe

de alunos um objeto que possui seus prprios atributos e mtodos

V e r b o s sugerem relacionamentos ou operaes

Um verbo de ao sugere uma operao

Por exemplo, "Colocar pedidos de compra de arquivos" sugere uma

Um verbo de estado sugere um relacionamento de

classificao entre um objeto e sua classe

Por exemplo, "Joe um cachorro" sugere que Joe uma instncia da

Um verbo de posse sugere um relacionamento de

Por exemplo, "o carro tem um motor" sugere uma associao de

operao de "arquivo"

agregao ou associao

classe cachorro
agregao entre carro e motor

Um verbo transifivo sugere uma operao

Por exemplo, "Frank enviou um pedido para Donna" sugere que Frank
e Donna so instncias de alguma classe que possui uma operao
relacionada com o envio de um pedido

Um predicado ou sentena verbal descritiva sugere

uma operao

Por exemplo, "se os dois funcionrios estiverem em departamentos

diferentes, ento..." sugere uma operao para verificar se os
funcionrios esto ou no em departamentos diferentes

Adjetivos > sugerem atributos de uma classe

Um adjetivo sugere o atributo de um objeto

Por exemplo, "agora todos os clientes de 55 anos so candidatos ao

desconto snior" sugere que a idade um atributo

A d v r b i o s > sugerem o atributo de um relacionamento ou

operao
Um advrbio sugere o atributo de um relacionamento
ou o atributo de uma operao

Por exemplo, "John dirige muito rpido" sugere um atributo velocidade

associado operao de dirigir

Essas diretrizes foram baseadas em Russell J. Abott, "Program Design by Informal English Descriptions, Communications of the A C M , 26( 1 11, 1983, p.
882-94; Peter P-S Chen, "English Sentence Structure and Entity-Relationship Diagrams", Information Sciences: An International Journal. 29(2-3), 1983,
p. 1 27-1 4 9 ; e lan Graham, Migrating to Object Technology, Reading, MA: Addison-Wesley, 1 9 9 5 .

FIGURA 1 5 - 2 0
Diretrizes para a Anlise Textual

FIGURA 1 5 - 2 1
Atributos Iniciais do Diagrama de Classes

'Do ingls Stock Keeping Unit - identificador numrico para referncia, um produto especfico em estoque ou em
um catlogo. (N.E.)

cessrias ao sistema como um todo. No entanto, para fins de demonstrao s examinaremos um

caso de uso: cliente faz pedido.
Muitas abordagens diferentes tm sido sugeridas para ajudar o analista a identificar um conjunto de classes candidatas ao diagrama de classes. A abordagem mais comum a anlise textual,
a anlise do texto dos casos de uso. O analista inicia revendo os casos de uso e os diagramas de
casos de uso. As descries de texto dos casos de uso so examinadas para a identificao de potenciais objetos, atributos, mtodos e relacionamentos. Os substantivos do caso de uso sugerem
possveis classes, enquanto os verbos sugerem mtodos e relacionamentos em potencial. A Figura 15-20 apresenta um resumo com diretrizes que achamos teis.
Identificar Atributos e Mtodos Suponho que voc tenha definido que o diagrama de classes ter
de incluir as classes que representam CD, Estoque, Material Promocional, Reserva Local, Fornecedor e Cliente. A prxima etapa definir os tipos de informao que desejamos capturar sobre
cada classe. O caso de uso tambm fornece uma pista para o tipo de informao que precisa ser
capturada, na seo denominada "Informaes para as etapas". Em algumas situaes, as tcnicas
de coleta de requisitos do Captulo 4 tambm so necessrias. Nesse momento, tente listar alguns
trechos de informao que podemos querer capturar para cada classe pode ajudar reler a descrio do caso de uso Anotar Solicitaes (Figura 5-5) e os resumos dos casos de uso Manuteno
de Material Promocional e Processo de Compras do Estoque (Figura 5-6)* do Captulo 5. Um problema bvio que o relatrio do caso de uso da Figura 5-5 foi redigido para ser usado em um
ambiente estruturado, e no em um ambiente orientado a objetos, mas voc deve conseguir fazer
a converso. Faa uma pausa e adicione os atributos s classes.
A essa altura, tambm queremos considerar quais mtodos especiais cada classe ter de conter
(lembre-se de que todas as classes podem executar mtodos bsicos, como inserir uma nova instncia, portanto eles no so includos no diagrama). A Figura 15-21 mostra o "primeiro esboo"
dos atributos do diagrama de classes. Voc consegue pensar em outros atributos que poderamos
ter includo em alguma dessas classes?
Desenhar os Relacionamentos entre as Classes Os relacionamentos so adicionados ao diagrama
de classes com o desenho das linhas de associao. Percorra cada classe e determine as outras
classes com as quais ela se relaciona, o nome do relacionamento (ou a funo que ela executa) e
a quantidade de instncias que podem participar da associao. Por exemplo, a classe cliente est
relacionada classe reserva local porque o cliente faz uma reserva local. Um cliente pode no
fazer nenhuma ou fazer muitas reservas locais (multiplicidade = 0..*), e uma reserva local pode
estar associada a um e somente um cliente (multiplicidade = 1 ) . Agora faa uma pausa para formular as associaes de Reserva Local, Estoque, CD, Material Promocional e Fornecedor. A Figura
15-22 mostra o diagrama que criamos at agora. Observe que inclumos relacionamentos entre
CD e Material Promocional, CD e Estoque, Estoque e Reserva Local, Reserva Local e Cliente, e
Fornecedor e Material Promocional.
Para concluir, voc deve procurar no modelo oportunidades de usar associaes de agregao
ou generalizao. Por exemplo, se a CD Selections decidisse que o material promocional seria
mais bem visualizado como um conjunto de diferentes tipos de materiais promocionais (p. ex
informaes de artistas, clipes de propaganda e resenhas), talvez fosse melhor modelar a classe
material promocional como uma agregao que inclusse outras classes. Alm disso, a CD
Selections pode querer deixar em aberto a possibilidade de vender outros itens que no sejam CDs.
O diagrama de classes poderia incluir uma classe denominadaprodato, que generalizasse os CDs.
Dessa forma, outros tipos de produtos (como livros, vdeo, roupas) poderiam facilmente ser incorporados ao sistema com a incluso de subclasses adicionais na superclasse produto. A Figura
15-23 mostra as associaes de agregao e generalizao que inclumos.

DIAGRAMA DE SEQNCIAS
A prxima tcnica principal de diagramao UML o diagrama de seqncias. Um diagrama de
seqncias ilustra os objetos que participam de um caso de uso e as mensagens que so passadas

*J que no conclumos as descries desses dois casos de uso, voc tambm deve rever os Requisitos Funcionais Revisados (Figura 5-8).

O Movimento para os Objetos

FIGURA 15-22

Atributos e Mtodos Revisados

fornece

o ..*

~T

descreve

0..*

/\ /\ /\

FIGURA 1 5 - 2 3
Diagrama de Classes Final

reservado por

443

444

Captulo Quinze

15-3 DESENHANDO UM DIAGRAMA DE CLASSES

VEZ
No quadro "Sua Vez 15-2" voc criou um diagrama de ca- ses para o servio de hospedagem no campus. Veja se consesos de uso para o servio de hospedagem no campus que ajuda gue identificar pelo menos um possvel atributo derivado, uma
os alunos a encontrarem apartamentos. Com base nos casos de associao de agregao e uma associao de generalizao
uso e no diagrama de casos de uso, crie um diagrama de cias- para o diagrama.

entre eles ao longo do tempo para apenas um caso de uso. um modelo dinmico, que d suporte
visualizao dinmica do sistema que est sendo desenvolvido. Mostra a seqncia explcita de
mensagens que so passadas entre objetos em uma iterao definida. J que os diagramas de seqncias enfatizam a ordenao com base no momento da atividade que ocorre entre um conjunto
de objetos, eles so muito teis para a compreenso de especificaes no tempo exato e de casos
de uso complexos.
O diagrama de seqncias pode ser um diagrama genrico que mostre todos os cenrios* possveis em um caso de uso, mas geralmente o analista desenvolve um conjunto de diagramas de
seqncia, cada um representando um nico cenrio dentro do caso de uso. Se voc estiver interessado em compreender o fluxo de controle de um cenrio baseando-se no tempo, deve usar um
diagrama de seqncias para representar essa informao. Os diagramas so usados em toda a fase
de anlise e projeto; no entanto, os diagramas de projeto so muito especficos da implementao,
geralmente incluindo objetos de banco de dados ou componentes especficos de interfaces grficas de usurio como classes. Primeiro, as sees a seguir apresentaro a sintaxe do diagrama de
seqncias e, em seguida, demonstraro como ele deve ser desenhado.
Elementos de um Diagrama de Seqncias A Figura 15-24 apresenta o exemplo de um diagrama de
seqncias representando os objetos e as mensagens do caso de uso "Marcar Consulta", que descreve o processo em que um paciente gera uma nova consulta e cancela ou remarca uma consulta no
sistema do consultrio mdico. Nesse exemplo especfico, o processo gerar consulta representado.
Os objetos que participam da seqncia so inseridos alinhados na parte superior do diagrama usando retngulos rotulados (veja a Figura 15-25). Observe que os objetos da Figura 15-24
so umPaciente, umaRecepcionista, Pacientes, ContasPendentes, Consultas e umaConsulta. Eles
no foram inseridos em nenhuma ordem especfica, embora seja interessante sua organizao de
alguma maneira lgica, como a ordem em que participam da seqncia. Em cada um dos objetos, o nome da classe dos quais so uma instncia fornecido aps seu nome (p. ex.,
Pacientes:Lista significa que Pacientes uma instncia da classe Lista que contm objetos paciente individuais).
Uma linha tracejada se prolonga verticalmente abaixo de cada ator e objeto para representar a
linha de vida dos atores/objetos com o passar do tempo (veja a Figura 15-24). H situaes em
que o objeto cria um objeto temporrio e, nesse caso, um X inserido no final da linha de vida no
ponto em que o objeto destrudo (no exibido). Por exemplo, considere o objeto carrinho de
compras de um aplicativo comercial na Web. O carrinho de compras usado para capturar temporariamente itens das linhas de um pedido, mas uma vez que o pedido for confirmado ele no ser
mais necessrio. Nesse caso, um X seria inserido no ponto em que o objeto carrinho de compras
fosse eliminado. Quando os objetos continuam a existir no sistema depois de serem usados no
diagrama de seqncias, a linha de vida segue at a parte inferior do diagrama ( isso que ocorre
com todos os objetos da Figura 15-24).
Uma caixa retangular fina, denominada foco de controle, sobreposta linha de vida para
mostrar quando as classes esto enviando e recebendo mensagens (veja a Figura 15-25). A mensagem uma comunicao entre objetos que transmite informaes no intuito de que a atividade
seja executada, e as mensagens passadas entre objetos so exibidas com o uso de linhas slidas,
denominadas vnculos, que conectam dois objetos (veja a Figura 15-25). A seta do vnculo mostra
por qual caminho a mensagem est sendo passada, e o valor de qualquer argumento existente na

*Lembre-se de que um cenrio o nico caminho que pode ser seguido em um caso de uso.

O Movimento para os Objetos

445

FIGURA 1 5 - 2 4
Diagrama de Seqncias

FIGURA 1 5 - 2 5
Sintaxe do Diagrama de Seqncias

Termo e Definio

Smbolo

Um ator
uma pessoa ou sistema que obtm benefcios do sistema e externo a
ele
Participa de uma seqncia enviando e/ou recebendo mensagens
inserido ao longo da parte superior do diagrama
umAtor

&
a
o
le
>
r
as
nc
rre
ari
en
adi
ias
str

Um objeto:
Participa de uma seqncia enviando e/ou recebendo mensagens
inserido ao longo da parte superior do diagrama

umObjeto:
umaClasse

Uma linha de vida:

Representa a existncia de um objeto durante uma seqncia
Contm um X no momento em que a classe no interage mais

Um foco de controle:
um retngulo longo e estreito inserido acima de uma linha de vida
Representa quando um objeto est enviando ou recebendo mensagens

Uma mensagem:
Transmite informaes de um objeto para outro
Destruio do objeto:
Um X inserido no final da linha de vida de um objeto para mostrar que ele
est deixando de existir

umaMensagem() k

446

Capitulo Quinze

mensagem ser inserido nos parnteses prximos ao nome da mensagem. A ordem das mensagens tem origem na parte superior da pgina, portanto as mensagens localizadas na parte mais alta
do diagrama representam as que ocorrem antes na seqncia, ao contrrio das mensagens mais
abaixo, que ocorrem posteriormente. Na Figura 15-24, ProcurarPaciente uma mensagem enviada do objeto umaRecepcionista ao objeto Pacientes, que um continer dos pacientes atuais para
determinar se o objeto umPaciente um paciente existente.
H situaes em que uma mensagem s enviada se uma condio for atendida. Nesses casos,
a condio inserida entre um par de [], por exemplo, [umPaciente Existe] ProcurarContas(). A
condio inserida na frente do nome da mensagem. No entanto, quando usamos um diagrama de
seqncias para modelar um cenrio especfico normalmente as condies no so exibidas em
nenhum diagrama individual. Em vez disso, as condies so sugeridas somente pela existncia
de diferentes diagramas de seqncias. Para concluir, possvel exibir explicitamente o retorno
de uma mensagem com um vnculo de retorno, uma mensagem tracejada. Porm, adicionar vnculos de retorno pode tornar o diagrama confuso. Assim, a menos que os vnculos de retorno adicionem muitas informaes ao diagrama, eles devem ser omitidos.
Em alguns casos, um objeto cria outro objeto. Isso mostrado pela mensagem sendo enviada
diretamente a um objeto, em vez de sua linha de vida. Na Figura 15-24, o objeto umaRecepcionista
cria o objeto umaConsulta.

Criando um Diagrama de Seqncias

A melhor maneira de aprender a criar um diagrama de seqncias desenhar um. Usaremos o cenrio que resulta na insero de um pedido especial extrado do caso de uso "Registrar Solicitaes de
CD", criado no Captulo 5 e ilustrado na Figura 5-5. A Figura 15-26 lista as principais etapas que
esse diagrama de seqncias do "pedido especial" precisar representar. As etapas da criao de um
diagrama de seqncias so um pouco parecidas com as que aprendemos para criar DFDs.
Identificar Objetos A primeira etapa identificar as instncias das classes que participam da seqncia que est sendo modelada; isto , os objetos que interagem entre si durante a seqncia do
caso de uso. Pense nos principais tipos de informao que precisam ser capturados pelo sistema.
Normalmente, os objetos podem ser extrados do relatrio de caso de uso criado durante o desenvolvimento do diagrama de casos de uso (veja o Captulo 5). As origens e os destinos do caso de
uso (especificamente as entidades externas ou depsitos de dados) so em geral um bom ponto de
partida para a identificao das classes. Alm disso, as classes podem ser atores externos que foram representados no diagrama de casos de uso.
Por exemplo, as instncias das classes usadas no cenrio Cliente Faz Pedido incluem Cliente,
CD, Material Promocional, Estoque e Sistema de Pedidos Especiais. Todas elas devem ser inseridas em caixas e listadas ao longo da parte superior do desenho (veja a Figura 15-27). As instncias de Cliente, CD, Estoque e Material Promocional correspondem aos depsitos de dados que
precisaremos ter no sistema, enquanto as instncias de Sistema de Pedidos Especiais representam
atores externos que apareceram no diagrama de casos de uso. J que essas ltimas instncias interagem na seqncia, queremos inclu-las no diagrama.
Lembre-se de que nesse momento voc est apenas tentando identificar os objetos que fazem
parte de um cenrio especfico de um caso de uso. Portanto, no se preocupe muito em identificar
perfeitamente todos os objetos do caso de uso. Outros diagramas de seqncias baseados em cenrio podem revelar objetos adicionais. Alm disso, o diagrama de classes criado na seo anterior deste captulo descreveu como as classes so definidas e aperfeioadas. Geralmente, porm, o
diagrama de classes revisado com base no diagrama de seqncias criado, j que os analistas
obtm uma compreenso melhor das classes depois que as desenvolvem.

FIGURA 1 5 - 2 6
Etapas do Cenrio Cliente Faz Pedido que
Resulta em um Pedido Especial

1.
2.
3.
4.
5.

Usurio solicita informaes de CDs

Usurio solicita informaes sobre que loja(s) tem o CD
Usurio insere o CD no carrinho de compras
Usurio paga e fornece informaes do cliente
Um pedido especial feito

O Movimento por os Objetos

447

FIGURA 1 5 - 2 7

Diagrama de Seqncias do Cenrio

Cliente Faz Pedido

Adicionar Mensagens Em seguida, desenhe setas para representar as mensagens que esto sendo passadas de objeto a objeto, apontando-as na direo da transmisso da mensagem. As setas devem ser
inseridas em ordem a partir da primeira mensagem (da parte superior) at a ltima (da parte inferior)
para mostrar a seqncia no tempo. Qualquer parmetro passado junto com as mensagens deve ser
inserido nos parnteses prximos ao nome da mensagem. Se estiver sendo esperado o retorno de
uma mensagem como resposta a outra mensagem, a mensagem de retorno no deve ser exibida explicitamente no diagrama. Examine as etapas da Figura 15-26 e veja se consegue determinar a maneira como as mensagens devem ser adicionadas ao diagrama de seqncias. A Figura 15-27 mostra
nossos resultados. Observe que no inclumos mensagens retornando a Cliente em resposta a Solicitar CD e Verificar Disponibilidade. Nesses casos, pressupe-se que o Cliente receber mensagens
de resposta sobre o CD solicitado e sua disponibilidade, respectivamente.
inserir a Linha de Vida e 0 Foco de Controle Para concluir, voc ter de mostrar quando os objetos
esto participando da seqncia. Uma linha tracejada vertical adicionada abaixo de cada objeto
para representar sua existncia durante a seqncia, e um X deve ser inserido abaixo dos objetos
no momento da linha de vida em que eles no estiverem mais interagindo com outros objetos.
Voc deve desenhar uma caixa retangular estreita acima das linhas de vida para representar quando os objetos esto enviando e recebendo mensagens. Veja a Figura 15-27 para ver o diagrama de
seqncias concludo.

15-4 DESENHANDO UM DIAGRAMA DE SEQNCIAS

VEZ
No quadro "Sua Vez 15-3" voc foi solicitado a desenhar um diagrama de casos de uso para o sistema de hospedagem no
campus. Selecione um dos casos de uso do diagrama e crie um diagrama de seqncias que represente a interao entre os
objetos do caso de uso.

448

Capitulo Quinze

DIAGRAMA DE ESTADO
Algumas das classes dos diagramas de classes so bastante dinmicas por passarem por vrios
estados durante sua existncia. Por exemplo, com o tempo um paciente pode passar de "novo"
para "existente", "antigo" e assim por diante, de acordo com seu status no consultrio mdico. O
diagrama de estado um modelo dinmico que mostra os diferentes estados pelos quais a mesma
classe passa durante sua existncia de acordo com os eventos, junto a suas respostas e aes.
Normalmente, os diagramas de estado no so usados para todas as classes, mas apenas para melhor
definir classes complexas, ajudando a simplificar o projeto de algoritmos para seus mtodos. O
diagrama de estado exibe os diferentes estados da classe e que eventos fazem com que ela passe
de um estado para outro. Em comparao com os diagramas de seqncias, os diagramas de estado devem ser usados se voc estiver interessado em compreender os aspectos dinmicos apenas
de uma classe e como suas instncias evoluem com o tempo, e no em como um cenrio de caso
de uso especfico executado em um conjunto de classes.

Elementos de um Diagrama de Estado

A Figura 15-28 mostra o exemplo de um diagrama de estado que representa a classe paciente no
contexto de um ambiente hospitalar. Analisando esse diagrama, podemos dizer que um paciente d
entrada no hospital e admitido depois de se registrar. Se o mdico achar que o paciente est com
sade ele liberado, no sendo mais considerado um paciente aps se passarem duas semanas. Se o
paciente for considerado doente, permanecer sob observao at que o diagnstico se altere.
Estado O estado um conjunto de valores que descrevem um objeto em um momento especfico no
tempo e representa uma circunstncia na vida de um objeto em que ele satisfaz alguma condio, executa alguma ao ou aguarda algo ocorrer (veja a Figura 15-29). Na Figura 15-28, os estados incluem
entrada, admitido, liberado e sob observao. O estado representado por um smbolo de estado,
que um retngulo com ngulos arredondados e um nome descritivo que informa o estado especfico.
H duas excees. Um estado inicial mostrado com o uso de um pequeno crculo slido, e o estado
final de um objeto exibido como um crculo ao redor de outro crculo slido menor. Essas excees
demonstram o momento de incio e trmino da existncia de um objeto, respectivamente.
Os atributos ou propriedades de um objeto afetam o estado em que ele se encontra; no entanto,
nem todos os atributos ou sua alterao faro diferena. Por exemplo, considere o endereo de um
paciente. Na Figura 15-28 esses atributos fazem muito pouca diferena no que se refere a alterar o
estado de um paciente. Porm, se os estados se baseassem na localizao geogrfica do paciente (p.
ex., pacientes residentes na cidade seriam tratados diferentemente de pacientes externos), as alteraes no endereo do paciente poderiam implicar alteraes no estado. No diagrama atual, os atributos que influenciam as mudanas no estado so o status e o diagnstico do paciente no hospital.

Evento O evento algo que ocorre em um determinado momento no tempo e altera um valor(es)
que descreve um objeto que, por sua vez, altera o estado do objeto. Ele pode ser uma condio
designada que se mostra verdadeira, o recebimento da chamada de um mtodo por um objeto e a
passagem de um perodo de tempo designado. O estado do objeto determina exatamente qual ser
a resposta. Na Figura 15-28, registrar-se no hospital, um diagnstico que demonstre sade e a passagem de um perodo de duas semanas so eventos que causam alteraes no estado do paciente.

[Diagnstico
= saudvel]

FIGURA 1 5 - 2 8
Diagrama de Estado de um Paciente no
Hospital

O Movimento por os Objetos

FIGURA 1 5 - 2 9

Sintaxe do Diagrama de Estado

Termo e Definio

449

Smbolo

Um estado
exibido como um retngulo com ngulos arredondados
Tem um nome que representa o estado de um objeto

Um estado inicial
exibido como um pequeno crculo slido
Representa o ponto em que um objeto comea a existir
Um estado final
exibido como um crculo ao redor de um pequeno crculo slido (o centro
de um alvo)
Representa a concluso da atividade
Um evento
uma ocorrncia perceptvel que aciona uma alterao no estado
Pode ser uma condio designada que resultou como verdadeira, o
recebimento de um sinal explcito de um objeto para outro ou a passagem
de um perodo de tempo designado
usado para nomear uma transio

Nome do evento

Uma transio
Indica que um objeto no primeiro estado entrar no segundo estado
acionada pela ocorrncia do evento com o nome da transio
exibida como uma seta slida de um estado para outro, rotulada com o
nome do evento

Setas so usadas para conectar os smbolos de estado, representando as transies entre estados. A transio um relacionamento que representa o movimento do objeto de um estado para
outro. Algumas transies tero uma condio de segurana. A condio de segurana uma
expresso booleana que inclui valores de atributo, que s permitem uma transio se a condio
for verdadeira. Cada seta rotulada com o nome do evento apropriado e qualquer parmetro ou
condio que possa ser aplicvel. Por exemplo, as duas transies de admitido para liberado e
para sob observao contm condies de segurana.

Criando um Diagrama de Estado

Os diagramas de estado so desenhados para representar apenas uma classe do diagrama de classes. Normalmente, as classes so muito dinmicas e complexas, requerendo uma demonstrao
adequada de seus estados com o passar do tempo e eventos acionando mudanas. Voc deve examinar seu diagrama de classes e desenhar um diagrama de estado para cada uma delas. Investiguemos o estado da classe pedido especial do sistema de Internet da CD Selections.
Identificar OS Estados A primeira etapa identificar os diversos estados que um pedido ter no
decorrer de sua existncia. Essas informaes so obtidas pela leitura dos relatrios de caso de
uso, de conversas com os usurios e com base nas tcnicas de coleta de requisitos que voc apren-

1. O cliente adiciona itens ao carrinho de compras, alguns dos quais podem acabar sendo pedidos
especiais, outros podem ser reservas locais
2. O cliente encerra as compras e envia o pedido especial ao terminar
3. O item do pedido especial transferido de outra loja (se a outra loja o tiver em estoque) ou o pedido
feito ao fornecedor do CD
4. O item do pedido especial enviado para a loja pela outra loja que o tinha ou pelo fornecedor
5. A loja recebe o item do pedido especial e o armazena para o cliente
6. O cliente apanha o item do pedido especial e paga por ele

FIGURA 1 5 - 3 0
A Vida de um Pedido Especial

7. O pedido especial encerrado

450

Captulo Quinze

FIGURA 15-31

Diagrama de Estado de um Pedido

Especial

deu no Captulo 4. Voc deve comear redigindo as etapas do que ocorre com um pedido com o
passar do tempo, do incio ao fim, de forma semelhante criao da seo de "principais etapas
executadas" de um relatrio de caso de uso. A Figura 15-30 mostra um pedido do incio ao fim,
partindo da perspectiva do pedido.
Identificar as Transies A prxima etapa identificar a seqncia de estados pela qual um objeto
pedido passar durante sua existncia e, em seguida, determinar exatamente o que faz cada estado
ocorrer. Insira smbolos no diagrama para representar os estados e nomeie as transies para descrever os eventos que esto ocorrendo para causar as alteraes no estado. Por exemplo, o evento
Cliente paga a conta, gerando pedido especial passa o pedido do estado inicial para o estado enviado
(veja a Figura 15-31). Durante o estado enviado, o banco de dados do estoque ser verificado para
sabermos se alguma loja da CD Selections possui os itens do pedido especial. A condio de segurana Em estoque=sim impedir o pedido de passar do estado enviado para o estado transferncia solicitada a menos que o CD exista no estoque de alguma loja da CD Selections. Alm
disso, a condio de segurana Em estoque=no impedir o pedido de passar do estado enviado
para o estado fazer pedido, a menos que o CD no exista no estoque de nenhuma loja. Dessa forma, entre as duas condies de segurana o pedido ficar preso no estado enviado at que a verificao no estoque tenha sido concluda.

15-5 DESENHANDO UM DIAGRAMA DE ESTADO

VEZ
Voc tem trabalhado com o sistema do servio de hospedagem no campus que ajuda os alunos a encontrar apartamentos.
Uma das classes dinmicas desse sistema provavelmente a
classe apartamento. Desenhe um diagrama de estado para

mostrar os diversos estados pelos quais a classe apartamento

passa durante toda a sua existncia. Voc consegue identificar
outras classes que seriam boas candidatas a um diagrama de
estado?

RESUMO
Atualmente, a mudana mais interessante na anlise e no projeto de sistemas a migrao para
tcnicas orientadas a objetos, que consideram um sistema como um conjunto de objetos
autocontidos apresentando tanto dados quanto processos. No entanto, os conceitos por trs das
tcnicas orientadas a objetos so idias simples, que evoluram das abordagens tradicionais de
desenvolvimento de sistemas, ou idias antigas que agora se tornaram prticas devido razo
entre custo e desempenho de hardware dos computadores modernos em comparao com as
obtidas no passado. Hoje em dia, o custo de desenvolvimento de softwares modernos composto principalmente pelo custo associado aos prprios desenvolvedores, e no aos computadores.

O Movimento por os Objetos

451

Dessa forma, as abordagens orientadas a objetos para o desenvolvimento de sistemas de informaes so muito promissoras para o controle desses custos.
Um objeto uma pessoa, lugar ou coisa sobre a qual queremos capturar informaes. Cada
objeto possui atributos que descrevem informaes sobre ele e comportamentos que so descritos
por mtodos que especificam o que um objeto pode fazer. Os objetos so agrupados em classes,
que so conjuntos de objetos que compartilham atributos e mtodos em comum. As classes podem ser organizadas de uma maneira hierrquica em que as de nvel inferior, ou subclasses, herdem atributos e mtodos das superclasses superiores a elas para reduzir a redundncia no desenvolvimento. Os objetos se comunicam entre si enviando mensagens que acionam mtodos. O
polimorfismo permite que uma mensagem seja interpretada diferentemente por tipos distintos de
objetos. Essa forma de comunicao nos permite tratar os objetos como caixas pretas e ignorar
seu funcionamento interno. O encapsulamento e a ocultao de informaes permitem que um
objeto esconda dos outros objetos seus processos internos e dados.
A anlise e o projeto orientados a objetos com o uso da UML permitem que o analista decomponha problemas complexos em componentes menores e mais gerenciveis empregando o conjunto de
uma notao geralmente aceita. A UML um conjunto-padro de tcnicas de diagramao que fornece uma representao grfica sofisticada o bastante para modelar qualquer projeto de desenvolvimento de sistemas da anlise implementao. Normalmente, as abordagens atuais de anlise e projeto mais orientadas a objetos usam a UML para representar um sistema em desenvolvimento. Para
concluir, muitas pessoas acreditam que os usurios no pensam em termos de dados ou processos
mas, em vez disso, em termos de um conjunto de objetos em colaborao. Dessa forma, a anlise e
o projeto orientados a objetos com o uso de UML permitem ao analista interagir com o usurio
empregando objetos do ambiente dele, em vez de um conjunto de processos e dados separados.
Diagramas de Casos de Uso

Um diagrama de caso de uso ilustra as principais funes de um sistema e os diferentes tipos de

usurios que interagem com ele. O diagrama inclui atores, que so as pessoas ou coisas que geram
valor com base no sistema, e casos de uso, que representam a funcionalidade do sistema. Os atores e casos de uso so separados pelo limite do sistema e conectados por linhas que representam
associaes. s vezes, os atores so verses especializadas de atores mais gerais. De maneira semelhante, os casos de uso podem estender ou incluir outros casos de uso. A construo dos diagramas de casos de uso um processo de cinco etapas em que o analista identifica os casos de uso,
desenha o limite do sistema, adiciona os casos de uso ao diagrama, identifica os atores e, para
concluir, adiciona as associaes apropriadas para conectar os casos de uso e atores.
Diagrama de Classes

O diagrama de classes mostra as classes e os relacionamentos entre classes que permanecem constantes no sistema com o passar do tempo. O principal bloco de construo do diagrama de classes
a classe, que armazena e gerencia informaes do sistema. As classes possuem atributos que
capturam informaes sobre elas, e mtodos, que so aes que uma classe pode executar. H trs
tipos de mtodos: construtor, consulta e atualizao. As classes se relacionam pela associao,
que tem um nome, e pela multiplicidade, que representa o mnimo e o mximo de instncias que
participam do relacionamento. Duas associaes especiais, a agregao e a generalizao, so
usadas quando as classes so compostas de outras classes ou quando uma subclasse herda propriedades e comportamentos de uma superclasse, respectivamente. Os diagramas de classes so criados primeiro com a identificao das classes, alm de seus atributos e operaes. Em seguida, os
relacionamentos so desenhados entre as classes para exibir associaes. Notaes especiais so
usadas para representar associaes de agregao e generalizao.
Diagrama de Seqncias

O diagrama de seqncias um modelo dinmico que ilustra as instncias de classes que participam de um caso de uso e as mensagens que so passadas entre elas com o passar do tempo. Os
objetos so inseridos horizontalmente ao longo da parte superior do diagrama de seqncias, cada
um tendo abaixo de si uma linha vertical tracejada denominada linha de vida. O foco de controle,
representado por um retngulo fino, inserido sobre a linha de vida para mostrar quando os objetos esto enviando ou recebendo mensagens. A mensagem uma comunicao entre objetos que
transmite informaes esperando que uma atividade seja executada, e exibida na forma de uma
seta que conecta dois objetos e aponta na direo para a qual a mensagem est sendo passada.

452

Capitulo Quinze

Para criar um diagrama de seqncias, primeiro identifique as classes que participam do caso de
uso e, em seguida, adicione as mensagens que so passadas entre elas. Para concluir, voc ter de
adicionar a linha de vida e o foco de controle. Os diagramas de seqncias sero teis para o entendimento das especificaes em tempo real e nos cenrios complexos de um caso de uso.
Diagrama de Estado

O diagrama de estado mostra os diferentes estados pelos quais uma nica instncia da classe passa durante sua existncia em resposta a eventos, alm das respostas e aes. O estado um conjunto de valores que descreve o objeto em um momento especfico no tempo, e representa uma
circunstncia na vida de um objeto em que ele satisfaz alguma condio, executa alguma ao ou
aguarda algo ocorrer. O evento algo que ocorre em um determinado momento no tempo e altera
um valor(es) que descreve um objeto, o que por sua vez altera o estado do objeto. Quando os objetos passam de um estado para outro, passam por transies. Quando desenhamos um diagrama
de estado, primeiro retngulos com ngulos arredondados so inseridos no modelo para representar os diversos estados que a classe assumir. Em seguida, setas so desenhadas entre os retngulos para representar as transies, e os nomes dos eventos so escritos acima das setas para descrever o evento que fez com que a transio ocorresse.

TERMOS IMPORTANTES
A-Kinf-Of (AKO Um-Tipo-De)
Abordagem orientada a objetos
Anlise textual
Associao
Associao de agregao
Associao de generalizao
Associao estende
Associao inclui
Ator
Ator especializado
Atributo
Atributo derivado
Baseado em casos de uso
Caso de uso
Cenrio
Centrado na arquitetura
Chave estrangeira
Chave primria
Classe
Classe abstrata
Classe concreta
Classe de associao
Comportamento
Condio
Condio de segurana
Diagrama de casos de uso

Diagrama de classes
Diagrama de estado
Diagrama de seqncia de instncias
Diagrama de seqncias
Diagrama de seqncias genrico
Encapsulamento
Estado
Estado final
Estado inicial
Evento
Foco de controle
Funo
Herana
Herdar
Identificador exclusivo (UID, unique
identifier)
Incrementai
Instncia
Iterativo
Limite do sistema
Linguagem de Modelagem Unificada
(Unified Modeling Language UML)
Linha de vida
Mensagem
Mtodo
Mtodo construtor

Mtodo de atualizao
Mtodo de consulta
Modelo dinmico
Modelo esttico
Multiplicidade
Objeto
Objeto temporrio
Ocultao de informaes
Pacote
Polimorfismo
Privado
Processo Racional Unificado (RUP,
Rational Unified Process)
Protegido
Pblico
Referncias
Smbolo de estado
Subclasse
Superclasse
Transies
Vnculos
Visibilidade
Visualizao
Visualizao dinmica
Visualizao esttica
Visualizao funcional

PERGUNTAS
Diferencie os itens dos conjuntos de termos a seguir:
Objeto; classe; instncia; diagrama de relacionamento de
entidades (ERD); entidade
Propriedade; mtodo; atributo
Estado; comportamento
Identificador exclusivo; chave primria; chave estrangeira

Superclasse; subclasse
Classe concreta; classe abstrata
Mtodo; mensagem
Encapsulamento; herana; polimorfismo
2. Em que a abordagem orientada a objetos diferente das
abordagens orientadas a dados e processos no desenvolvimento de sistemas?

O Movimento poro os Objetos

3. Como a abordagem orientada a objetos pode melhorar o

processo de desenvolvimento de sistemas?
4. Descreva como a abordagem orientada a objetos d suporte
aos conceitos de coeso e acoplamento em projetos de programas que foram apresentados no Captulo 12.
5. O que a Linguagem de Modelagem Unificada (UML)?
Como ela d suporte abordagem orientada a objetos no desenvolvimento de sistemas?
6. Descreva as etapas da criao de um diagrama de casos de
uso.
7. Como voc pode empregar o relatrio de caso de uso para
desenvolver um diagrama de casos de uso?
8. Em que o diagrama de casos de uso semelhante aos diagramas de fluxo de dados (DFDs) de contexto e de nvel 0?
Em que ele diferente?
9. D dois exemplos de associaes estende em um diagrama
de casos de uso. Cite dois exemplos de associao inclui.
10. Quais dos itens a seguir poderiam ser um ator encontrado
em um diagrama de casos de uso? Por qu?
Sita. Mary Smith
Fornecedor
Cliente
Cliente da Internet
Sr. John Seals
Atendente digitador de dados
Administrador do banco de dados
11. Considere um processo chamado validar histrico de crdito, que usado para validar o histrico do crdito de clientes que desejam fazer um emprstimo. Explique como ele
pode ser o exemplo da associao inclui de um diagrama de
casos de uso. Descreva como seria o exemplo de uma associao estende. Como analista, de que forma voc saberia
qual interpretao a correta?
12. D exemplos de um modelo esttico e um dinmico em
UML. Em que os dois tipos de modelo so diferentes?
13. Descreva os principais blocos de construo do diagrama de
seqncias e como eles so representados no modelo.
14. As linhas de vida sempre continuam a descer at o final da
pgina de um diagrama de seqncias? Explique.
15. Descreva as etapas usadas na criao de um diagrama de
seqncias.
16. Em que um diagrama de classes diferente de um ERD?
17. D trs exemplos dos atributos derivados que podem existir
em um diagrama de classes. Como eles seriam representados no modelo?
18. Identifique os mtodos a seguir como construtor, de consulta
ou de atualizao. Que operaes no precisariam ser mostradas no retngulo da classe?
Calcular aumento salarial do funcionrio (percentual de
aumento)
Inserir funcionrio()
Inserir esposa()
Calcular dias em que esteve doente()
Localizar nome do funcionrio()
Encontrar endereo do funcionrio()
Aumentar quantidade de dias de frias do funcionrio()
Alterar endereo do funcionrio()
Inserir solicitao de frias (dia das frias)

453

19. Desenhe as associaes que so descritas nas regras dos

negcios a seguir. Inclua as multiplicidades de cada relacionamento.
Um paciente s deve ser atribudo a um mdico e um
mdico pode ter um ou mais pacientes.
Um funcionrio tem um ramal telefnico, e um nico
ramal telefnico atribudo a um funcionrio.
Um cinema exibe pelo menos um filme, e um filme pode
ser exibido em at quatro outros cinemas da cidade.
Um filme tem uma estrela, dois coadjuvantes ou mais de
10 pessoas atuando juntas. Uma estrela deve estar em pelo
menos um filme.
20. Quais so os dois tipos de nomes que um diagrama de classes pode ter para cada associao? Quando cada tipo de nome
usado?
21. Por que a classe de associao usada em um diagrama de
classes? D o exemplo de uma classe de associao encontrada em um diagrama de classes que capture alguns alunos
e os cursos que fizeram.
22. D dois exemplos de associao de agregao e de generalizao. Como cada tipo de associao representado em
um diagrama de classes?
23. Os estados so sempre representados com o uso de retngulos arredondados em um diagrama de estado? Explique.
24. Que trs tipos de eventos podem levar a transies de estado em um diagrama de estado?
25. Descreva o tipo de classe que seria mais bem representado
em um diagrama de estado. D dois exemplos de classes que
seriam boas candidatas aos diagramas de estado.
26. Compare e diferencie o processo racional unificado (RUP)
da UML.
27. Descreva a maneira como o RUP implementado em um
projeto de sistema.
28. Identifique o(s) modelo(s) que contm(m) cada um dos
componentes a seguir:
Associao de agregao
Classe
Atributos derivados
Associao estende
Foco de controle
Condio de segurana
Estado inicial
Vnculos
Mensagem
Multiplicidade
Ator especializado
Limite do sistema
Mtodo de atualizao
29. Na sua opinio, quais so os trs erros comuns que analistas
iniciantes cometem no uso de tcnicas UML?
30. Voc acha que a UML se tornar mais popular do que as
tcnicas estruturadas tradicionais discutidas anteriormente?
Explique por qu.
31. Alguns especialistas alegam que as tcnicas orientadas a
objetos so mais simples para os iniciantes compreenderem
e usarem do que os DFDs e ERDs. Voc concorda? Explique por qu.

454

Captulo Quinze

EXERCCIOS
A. Acesse o Web site da Rational Software (www.rational.com)
e seu repositrio de informaes sobre a Linguagem de Modelagem Unificada (UML). Escreva um breve pargrafo informativo sobre o estado atual da UML (a verso atual e quando ela ser lanada, melhorias futuras etc).
B. Pesquise o Object Management Group (OMG). Escreva um
memorando breve resumindo o que ele representa, sua finalidade e sua influncia na UML e na abordagem orientada a objetos para o desenvolvimento de sistemas. (Sugesto: um recurso interessante www.omg.org.)
C. Pesquise o processo racional unificado (RUP). Descreva os
principais benefcios do RUP e as etapas que ele contm.
Compare-o com uma das outras metodologias descritas no Captulo 1.
D. Pesquise as ferramentas CASE (computer-aided software
engineering) que trabalham com UML (p. ex., o Rational
Rose, da Rational Software, o VISIO, da Microsoft) e descreva com que nvel de sucesso. Que ferramenta CASE voc
recomendaria a uma equipe prestes a iniciar um projeto usando
a abordagem orientada a objetos? Por qu?
E. Considere um sistema usado para gerenciar uma pequena loja
de roupas. Sua funcionalidade principal fazer a manuteno do inventrio, vender itens aos clientes e produzir relatrios de vendas para a gerncia. Liste exemplos de cada um
dos itens a seguir que possa ser encontrado no diagrama de
casos de uso que modele um sistema assim: caso de uso; caso
de uso estende; caso de uso inclui; ator; ator especializado.
F. Crie um diagrama de casos de uso que ilustre os casos de uso
do sistema de consultrio odontolgico a seguir. Sempre que
novos pacientes so vistos pela primeira vez, eles preenchem
um formulrio de informaes do paciente que solicita seu
nome, endereo, nmero de telefone e um breve histrico
mdico, que armazenado no arquivo de informaes do
paciente. Quando um paciente liga para agendar uma nova
consulta ou alterar uma consulta existente a recepcionista
procura no arquivo de consultas um horrio disponvel. Quando um horrio adequado encontrado para o paciente, a consulta agendada. Se for um paciente novo, uma entrada incompleta ser criada no arquivo de pacientes: a informao
completa ser coletada quando o paciente chegar para a consulta. J que em geral as consultas so marcadas antecipadamente, a recepcionista costuma enviar um lembrete para cada
paciente duas semanas antes da consulta.
G. Crie um diagrama de casos de uso que ilustre os casos de uso
do sistema de registro online da universidade a seguir. O sistema deve permitir que os membros da equipe de cada departamento acadmico examinem os cursos oferecidos por seu
departamento, adicionem e removam cursos e alterem as informaes sobre eles (p. ex., a quantidade mxima de alunos
permitidos). Ele deve permitir que os alunos examinem os
cursos disponveis atualmente, adicionem e eliminem cursos
de seus programas e examinem os cursos nos quais esto
matriculados. A equipe do departamento deve poder imprimir vrios relatrios sobre os cursos e os alunos matriculados neles. O sistema deve assegurar que nenhum aluno faa
cursos demais e que os alunos que tenham alguma mensali-

dade pendente no tenham permisso para se registrar (suponhamos que um depsito de dados de mensalidades seja mantido pelo departamento financeiro da universidade, que o sistema de registro acessa mas no altera).
H. Crie um diagrama de casos de uso que ilustre os casos de uso
do sistema a seguir. A empresa A Real State Inc. (AREI) vende
casas. As pessoas que querem vender suas casas assinam um
contrato com a AREI e fornecem informaes sobre sua casa.
Essas informaes so mantidas pela AREI em um banco de
dados, e um subconjunto delas enviado para o servio de
listagem mltipla da cidade, usado por todos os agentes imobilirios. A AREI trabalha com dois tipos de potenciais compradores. Alguns compradores tm interesse em uma casa
especfica. Nesse caso, a AREI imprime informaes de seu
banco de dados, que o agente imobilirio usar para ajudar a
mostrar a casa ao comprador (um processo fora do escopo do
sistema a ser modelado). Outros compradores procuram o
aconselhamento da AREI para encontrar uma casa que atenda as suas necessidades. Nesse caso, o comprador preenche
um formulrio de informaes do comprador, que inserido
em um banco de dados de compradores, e os agentes imobilirios da AREI usam as informaes para procurar no banco
de dados da empresa e no servio de listagens diversas casas
que atendam as suas necessidades. Os resultados dessas pesquisas so impressos e usados para ajudar o agente imobilirio a mostrar casas para o comprador.
I. Crie um diagrama de seqncias para cada uma das descries de cenrio a seguir relacionadas ao sistema de uma locadora de vdeos. A empresa A Video Store (AVS) gerencia
uma cadeia de locadoras de vdeo bem comuns:
Todo cliente precisa ter um carto de cliente vlido da AVS
para alugar um vdeo. Os clientes podero alugar vdeos
por trs dias a cada vez. Sempre que um cliente alugar um
vdeo, o sistema precisar se certificar se ele no tem nenhum vdeo pendente. Se houver vdeos pendentes, eles
tero de ser devolvidos e uma taxa de atraso precisar ser
paga antes de o cliente poder alugar mais vdeos.
Se o cliente tiver devolvido vdeos atrasados mas no tiver pago a taxa de atraso, esta ter de ser paga antes que
novos vdeos possam ser alugados. Se o cliente for novo,
as duas primeiras taxas de atraso podero ser esquecidas,
e ele poder alugar o vdeo.
Toda manh, o gerente da loja imprime um relatrio que
lista vdeos atrasados; se um vdeo estiver atrasado dois dias
ou mais, o gerente ligar para o cliente para lembr-lo de
devolver o vdeo.
J. Crie um diagrama de seqncias para cada uma das descries de cenrio a seguir, relacionadas ao sistema de associao a um plano de sade:
Quando os membros se associam ao plano de sade, pagam uma taxa por determinado perodo de tempo. O plano deseja enviar lembretes aos membros solicitando que
eles renovem suas inscries um ms antes de elas expirarem. Quase metade dos membros recebe pesquisas de
acompanhamento para preencher informando o motivo por
que decidiram no renovar, para que o plano possa saber

O Movimento poro os Objetos

como aumentar a reteno. Se o membro no renovou por

causa do custo, um desconto especial ser oferecido a esse
cliente. Normalmente, 25% das contas so reativadas graas a essa oferta.
Sempre que um membro chega ao consultrio, um atendente pega seu carto e o passa em uma leitora para se
certificar de que a pessoa um membro ativo. Se o membro no for ativo, o sistema mostrar quanto custa a renovao da inscrio. Ser oferecida ao cliente a oportunidade de pagar a taxa e usar o consultrio, e o sistema registrar a reativao da conta para que uma ateno especial possa ser dispensada a esse cliente quando a prxima
rodada de renovaes ocorrer.
K. Crie diagramas de classes que descrevam as classes e relacionamentos representados nos cenrios a seguir:
Pesquisadores so inseridos em um banco de dados que
mantido pelo estado da Gergia. As informaes de interesse incluem nome do pesquisador, formao, cargo, data
em que ingressou no cargo atual, quantos anos est no cargo atual; nome da universidade, local e matrcula; e assuntos da pesquisa. Os pesquisadores esto associados a
uma instituio, e cada pesquisador pode ter at cinco
assuntos de pesquisa. Mais de um pesquisador pode ter o
mesmo interesse, e o sistema rastreia o conjunto de melhores pesquisadores por assunto. O sistema deve poder
inserir novos pesquisadores, universidades e assuntos de
pesquisa; produzir informaes, como a quantidade de
pesquisadores de cada universidade, informaes de contato dos pesquisadores e assuntos de pesquisa que no tenham pesquisadores associados, alm de alterar a classificao dos pesquisadores nos diversos assuntos de pesquisa.
Uma loja de departamentos tem um registro de noivas.
Esse registro mantm informaes sobre a noiva, os produtos que a loja entrega e os produtos para os quais cada
cliente se registra. Alguns produtos incluem vrios itens
relacionados; por exemplo, os conjuntos de pratos incluem pratos, utenslios de mesa para especialidades e baixelas. Normalmente os clientes se registram para receber
uma grande quantidade de produtos, e muitos clientes se
registram para receber os mesmos produtos. Desenhe o
diagrama de classes e d pelo menos dois exemplos de
operaes de consulta e atualizao que poderiam ser inseridas em algum local do modelo.
A loja de Jim Smith vende Fords, Hondas e Toyotas. Ela
mantm informaes sobre cada fabricante de carros com
o qual os funcionrios lidam para que eles possam entrar
em contato facilmente com os fabricantes. A loja tambm
mantm informaes bsicas sobre os modelos de carros
que compra de cada fabricante. Ela tem informaes do
tipo preo de tabela, o preo que pagou para obter o modelo e o nome e a srie do modelo (p. ex., Honda Civic
LX). Tambm armazena informaes sobre todas as vendas que os funcionrios fizeram (p. ex., a loja registra o
nome do comprador, o carro que ele comprou e a quantia
que pagou pelo carro). Para contatar os compradores no
futuro, a loja tambm mantm informaes de contato
(como endereo e nmero do telefone).

455

L. Considere o envio em primeira classe de uma carta para um

amigo com quem voc se corresponde internacionalmente.
Descreva o processo que a carta percorrer para ir da criao
inicial at ser lida por seu amigo, partindo da perspectiva da
carta. Desenhe um diagrama de estado que represente os estados que a carta percorrer.
M. Considere a locadora de vdeos que foi descrita na pergunta
1. Desenhe um diagrama de estado que descreva os diversos
estados que um vdeo percorrer do momento em que for
colocado na prateleira at o aluguel e o processo de devoluo.
N. Desenhe um diagrama de estado que descreva os diversos
estados que uma autorizao de viagem poder percorrer em
seu processo de aprovao. Um formulrio de autorizao de
viagem usado na maioria das empresas para aprovao de
despesas de viagem de funcionrios. Normalmente, o funcionrio preenche um formulrio em branco e o envia para seu
chefe assinar. Se a quantia for pequena (abaixo de U$300),
ento o chefe assinar o formulrio e o enviar para a seo
de Contas a Pagar para ser inserido no sistema de contabilidade. O sistema emitir um cheque com a quantia exata que
ser enviada ao funcionrio, e depois que ele for sacado o
formulrio ser arquivado com o cheque compensado. Se o
cheque no for sacado dentro de 90 dias, o formulrio de viagem expirar. Quando o valor do recibo de viagem tiver uma
quantia alta (acima de U$300) o chefe assinar o formulrio
e o enviar para o chefe do departamento financeiro, junto com
um pargrafo explicando a finalidade da viagem, e este assinar o formulrio e o enviar para Contas a Pagar. claro que
tanto o chefe de quem vai viajar quanto o chefe do departamento financeiro podem no aprovar o formulrio de autorizao de viagem, se no acharem as despesas aceitveis. Nesse
caso, o funcionrio poder alterar o formulrio para incluir
uma explicao melhor ou decidir pagar as despesas.
O. Identifique os casos de uso do sistema a seguir. A Picnics R
Us (PRU) uma pequena empresa de fornecimento de comida com cinco funcionrios. Durante um tpico fim de semana
de vero, a PRU organiza 15 piqueniques para 20 ou 50 pessoas cada. O negcio cresceu rapidamente no ltimo ano, e o
proprietrio quer instalar um novo sistema de computador para
o gerenciamento do processo de pedidos e compras. A PRU
tem um conjunto de 10 menus-padro. Quando possveis clientes ligam, a recepcionista descreve os menus para eles. Se
o cliente decidir reservar um piquenique, a recepcionista registrar suas informaes (nome, endereo, nmero de telefone etc.) e as informaes sobre o piquenique (local, data,
hora, qual dos menus-padro, preo total) em um contrato. Em
seguida, ser enviado ao cliente um fax com a cpia do contrato que ele ter de assinar e devolver junto com um depsito (geralmente com carto de crdito ou cheque), antes que o
piquenique seja oficialmente reservado. O resto do dinheiro
ser recebido quando o piquenique for organizado. H situaes em que o cliente pode querer algo especial (p. ex., bolo
de aniversrio). Nesse caso, a recepcionista anota a informao e a passa para o proprietrio, que determina o custo; em
seguida, a recepcionista liga novamente para o cliente com a
informao do preo. H vezes em que o cliente aceita o preo; em outras, ele solicita algumas alteraes, que tm de re-

456

Captulo Quinze

tornar ao proprietrio para uma nova estimativa de custo. Toda

semana o proprietrio examina os piqueniques agendados para
a semana em questo e faz o pedido dos suprimentos (p. ex.,
pratos) e da comida (p. ex., po, galinha) necessrios para que
eles sejam realizados. O proprietrio gostaria de usar o sistema tambm em marketing. Ele deve poder rastrear como os
clientes conheceram a PRU e identificar clientes recorrentes,
para que a PRU possa enviar ofertas especiais para eles. O
proprietrio tambm quer controlar os piqueniques para os
quais a PRU enviou um contrato, mas o cliente no assinou
nem reservou realmente um piquenique.
Crie o diagrama de casos de uso para o sistema da PRU.
Selecione um diagrama de casos de uso e crie um diagrama de seqncias.
Crie um diagrama de classes para o sistema da PRU.
Crie um diagrama de estado para representar uma das classes do diagrama de classes anterior.
P. Identifique os casos de uso do sistema a seguir. O Of-theMonth Club (OTMC) uma jovem empresa inovadora que
vende cotas para pessoas que tenham interesse em certos produtos. Elas pagam taxas de associao por um ano e todo ms
recebem um produto pelo correio. Por exemplo, a OTMC tem
uma cota mensal de caf que envia aos membros 500 gramas
de caf especial todo ms. Atualmente ela oferece seis tipos
de cotas (caf, vinho, cerveja, charutos, flores e jogos de computador), cada uma tendo um preo diferente. Em geral os
clientes compram apenas uma, mas alguns pertencem a duas
cotas ou mais. Quando as pessoas se associam OTMC a recepcionista registra nome, endereo postal, nmero de telefone, endereo eletrnico, informaes de carto de crdito,
data de incio e servio(s) da cota (p. ex., caf). Alguns clientes solicitam uma cota dupla ou tripla (um quilo de caf, trs
caixas de cerveja). A cota de jogos de computador funciona
de maneira um pouco diferente das outras. Nesse caso, o membro tambm precisa selecionar o tipo de jogo (ao, fliperama,
fantasia/fico cientfica, educacional etc.) e a faixa etria. A
OTMC est planejando expandir bastante os tipos de cotas que
oferece (p. ex., videogames, filmes, brinquedos, queijos, frutas, vegetais), portanto o sistema precisa acomodar essa expanso futura. Tambm est planejando oferecer cotas para
trs e seis meses.
Crie o diagrama de casos de uso para o sistema da OTMC.

Selecione um diagrama de casos de uso e crie um diagrama de seqncias.

Crie um diagrama de classes para o sistema da OTMC.
Crie um diagrama de estado para representar uma das classes do diagrama de classes anterior.
Q. Pense em sua escola ou na biblioteca local e nos processos
envolvidos na retirada de livros, cadastro de novos usurios
de emprstimo e envio de lembretes sobre pendncias partindo da perspectiva da biblioteca. Descreva trs casos de uso
que representem essas trs funes.
Crie o diagrama de casos de uso para o sistema da biblioteca.
Selecione um diagrama de casos de uso e crie um diagrama de seqncias.
Crie um diagrama de classes para o sistema da biblioteca.
Crie um diagrama de estado para representar uma das classes do diagrama de classes anterior.
R. Pense no sistema que manipula a admisso de alunos em sua
universidade. A funo principal do sistema deve ser de rastrear o aluno da solicitao de informaes ao processo de admisso, at que sua admisso na escola seja aprovada ou rejeitada. Crie um relatrio de caso de uso que possa descrever
o caso de uso "admitir aluno".
Crie um diagrama de casos de uso para esse caso de uso.
Suponha que os alunos graduados so tratados diferentemente dos outros. Alm disso, o caso de uso genrico atualizar informaes do aluno est disponvel para seu sistema usar.
Selecione um diagrama de casos de uso e crie um diagrama de seqncias. Suponha que um objeto temporrio aluno usado pelo sistema para armazenar informaes sobre as pessoas antes de elas enviarem um pedido de admisso. Depois que o pedido enviado, elas so consideradas
alunas.
Crie um diagrama de classes para o sistema de admisso
de alunos. O pedido de admisso inclui contedo do formulrio, informaes SAT e referncias. Sobre os alunos
graduados, so coletadas informaes adicionais, como o
ano de graduao de seus pais, informaes de contato e
especializaes universitrias.
Crie um diagrama de estado para descrever como os alunos so encaminhados ao longo do processo de admisso.

MINKASOS
1. O novo sistema de informaes da Jones Legal Investigation
Services ser desenvolvido com o uso de objetos. Os dados
a serem gerenciados por esse sistema sero complexos, consistindo em grandes quantidades de texto, datas, nmeros,
imagens grficas, clipes de vdeo e udio. As principais funes do sistema sero estabelecer uma investigao quando
surgirem solicitaes de advogados clientes, registrar os procedimentos investigativos que sero conduzidos e as informaes que forem coletadas durante uma investigao, e
gerar as contas dos servios de investigao. Desenvolva um
diagrama de casos de uso para esse novo sistema.

2. A investigao de casos passa por vrios estados no sistema

da Jones Legal Investigation Services. Primeiro, ela estabelecida quando o advogado solicita que uma investigao seja
conduzida. Quando o detetive comea a executar as diversas
tcnicas investigativas, a investigao do caso se torna ativa.
O advogado cliente pode comear a negociar um acordo ou o
caso pode ir a julgamento. As negociaes de acordo podem
resultar em um acordo, ou o caso pode ter de ir a julgamento
se as negociaes falharem. Para concluir, a investigao do
caso encerrada quando este termina com um acordo negociado ou com o veredicto judicial. Desenvolva um diagrama
de estado para essa situao.

Abordagem
de objeto. Veja tambm Linguagem de modelagem
unificada (UML)
abordagem para anlise e projeto e a, 424
benefcios da, 425, 427
encapsu lamento e ocultao da informao
e a, 422
herana e a, 423, 424
mtodos e mensagens e a, 422
objetos e classes e a, 421
poimorfismo e a, 424, 425
do ponto de funo, estimativa, 52-56
modular para o projeto de programa, 338
Abrangncia da anlise, seleo da tcnica de anlise de
requisitos e, 95
Aceitao
motivao, 404
treinamento para habilitar a, 405
Acionadores nos casos de uso, 123
externos, 123
temporais, 123
Aes da interface, 274
Acordo por tempo indeterminado, 211
Agendas de entrevistas, 96
Agentes da mudana, 15, 399
Agregao de classes, 440
Agrupamento, 325
interarquivos, 325
intra-arquivos, 325
Algoritmos de criptografia
assimtrica, 246
simtrica, 246
Alocao de recursos, poltica de gerenciamento e, 401
Ampliao do escopo, 62
Anlise
da causa-raiz na BPA, 90
da parte interessada, 38
de custo e benefcio. Veja tambm Viabilidade
econmica, 401-403
de desempenho informal, 130
de documento, para a captura de requisitos, 106
de durao no BPI, 90
de infra-estrutura como papel da equipe de
projeto, 17
de problemas na BPA, 89
de requisitos, 89-95, 111
BPA para, 88, 89
BPI para, 88, 90-93
BPR para, 88
de resultados
BPR para, 93
selecionando tcnicas de, 94
de tecnologia na BPR, 93
de viabilidade, 5, 31-43
econmica e, 33-38
organizacional e, 38-40
tcnica e, 31
do gerenciamento da mudana como papel da equipe
de projeto, 16, 17
e projeto inicial, 6
textual com casos de uso, 442
Analistas
de negcios como papel da equipe de projeto, 16, 17
de sistemas

na equipe de projeto, 16
papel principal desempenhado pelo, 2
Anotaes de entrevistas, 100
APC - adjusted project complexity (complexidade do
projeto ajustado), 54
reas de assunto de ERDs, 191
Armazenagem de dados
como funo de software, 237
eficincia da, 320
Arquitetura
baseada em cliente, 238
baseada em servidor, 237
cliente-servidor, 238, 242
de duas camadas, 240
de n camadas, 240
de trs camadas, 240
Arquivos, 311,318
de auditoria, 313
de histrico, 313
de pesquisa, 311
de transao, 311
Arquivos-mestres, 311
rvores de deciso, 152
Associaes nos diagramas de caso de uso, 433, 435
estende, 433
inclui, 433
Atividades
do projeto, coordenao das, 68-71
documentao e, 70
ferramentas CASE para a, 68
gerenciamento de riscos e, 70
padres e, 69
na BPR, eliminao de, 93
posteriores implementao, 407-413
avaliao de projeto como, 410
manuteno de sistema como, 408-410
suporte ao sistema como, 407
Atores nos diagramas de caso de uso, 431, 433-435
Atributos, 421
derivados, 435-442
identificando, 183, 185, 442
nos ERDs, 176
privados, 437
projetados, 437
pblicos, 437
repetidos (grupos), 191
visibilidade de, 437
Autenticao, 246
Automao
dos dados na origem, 285
dos processos operacionais (BPA - business process
automation), 88, 89
anlise da causa-raiz na, 90
anlise de problemas na, 89
Autoridade de certificao - AC (CA - certificate
authority), 247
Avaliao
analtica (heurstica) de interfaces, 277
da equipe de projeto, 411
da interface com o usurio, 270, 276-278, 300
de desempenho informal, no BPI, 92
do projeto, 393, 410
do risco, 70
do sistema, 411
interativa de interfaces, 277
prtica de interfaces, 277

B
Bancos de dados, 310, 313-317
de objetos, 316
de rede, 313
hierrquicos, 313
multidimensionais, 317, 318
preexistentes, 313, 318
relacionais, 315, 317, 325
Barras de ferramentas, 282
Benefcios
do novo sistema, avaliao, 401-403
intangveis, 34, 35
tangveis, 34
Botes, 262
de opo, 287, 288
BPA. Veja Automao dos processos operacionais (BPA
- business process automation)
BPI. Veja Melhoria dos processos operacionais (BPI business process improvement)
BPR. Veja Reengenharia dos processos operacionais (BPR
- business process reengineering)

CA - certificate authority (autoridade de certificao

- AC), 247
Caixas
de combinao, 288
de listagens
na tela, 287, 288
suspensas, 287, 288
de nmero, 286
de seleo, 287, 288
de texto, 286
nos grficos PERT, 59
Caminho crtico, 59
Captura de dados na origem, 284
Cardinalidade de relacionamentos, 178
Carga de informaes, gerenciamento, 290
Cartes inteligentes, 286
Casos
de teste, 373
de uso, 121-137
confirmando, 127, 135, 137
construindo, 124-128
detalhes nos, 123
entradas e sadas em, 123
exemplos, 123
identificando, 125, 128-131, 435
as etapas principais de, 126, 130
elementos nas etapas de, 127, 132, 134
informaes bsicas nos, 123
na abordagem de objeto, 424, 427
nos diagramas de casos de uso, 432, 435
pacotes de, 126
revisando a definio de requisitos e, 136, 137
CBT - computer-based trainng (treinamento baseado em
computador para habilitar a aceitao), 406
Cenrios
de uso, pra o projeto de interface com o
usurio, 270, 271,294
operacionais. Veja Casos de uso
Centrado em arquitetura, 424, 427
Chave(s)

458

ndice

estrangeira, 3 15
externas, 224
primrias, 223, 315
CaVe, N\iai o te^woW\YWi&j& a sistemas. ^CftJC
- systems developmentnfe cycle), 2-7, 84
fases do, 3-5
Classes, 421, 427
abstratas na abordagem de objeto, 423
de associao, 440
de objeto, 316
desenhando relacionamentos entre, 442
identificando, 440
nos diagramas de classe, 435-442
Clientes
gordo, 239
magro, 239
Coeso
coincidente de mdulos, 349
de mdulos, 349
do grupo, 67
funcional de mdulos, 349
temporal de mdulos, 349
Coleta de requisitos, 95-111
anlise de documento para, 106
desenvolvimento conjunto de aplicaes
para, 101-104
entrevistas para, 96-101
observao para, 107
questionrios para, 104-106
selecionando tcnicas para, 109-111
Comits
de aprovao, 5, 28
de sugestes, 5
Complexidade do projeto ajustado (APC - adjusted
project complexity), 54
Componentes arquitetnicos do software, 236
Comportamentos, 421
Computadores-clientes, 237
Condio(es)
de segurana, 449
nos diagramas de seqncias, 446
Conectores
fora de pgina, 343
na pgina, 343, 347
nos grficos de estrutura, 343
Configurao do projeto, 67
Conformidade estratgica, 38
Conjugados
de contedo, 351
de controle, 343
de dados, 343, 352
nos grficos de estrutura, 343, 347, 351
Conscincia
do contedo, projeto de interface com o usurio e a,
263, 266
no projeto de interface com o usurio, 263, 269
Construo. Veja tambm Documentao;
Gerenciando a programao; Testes; Documentao
do usurio, 370
do sistema, 7
erros comuns na, 373
Contextos para simplificar os diagramas de classe, 440
Contratos
de preo fixo, 211
de valor agregado, 211,212
Controle(s)
de alteraes, 372
de navegao de documentao, 379
de segurana, 245-246
deslizantes, 287, 288
Converso, 393-398, 412
direta, 394
do sistema como um todo, 396
em fases, 395
mdulos e, 396
paralela, 395
piloto, 395
selecionando a estratgia para a, 396-398
simultnea, 395
Criptografia, 246
de chave pblica, 247
Cronograma, estratgias de projeto e o, 213,214
Custo(s)
baseado na atividade na BPI, 92
de desenvolvimento, 34
do projeto, seleo da tcnica de anlise de
requisitos e, 95
estratgias de converso e, 397
intangveis, 34, 35
operacionais, 34

interpretao, 175
lgicos, 206
sintaxe avanada e, 186

\y
Dados
no-processados, 327
Datamarts, 317
DBMSs. Veja Sistemas de gerenciamento de banco de
dados
empresarial, 310
para o usurio final, 310
''Decompondo diagramas de fluxo de dados, 149
Definio de requisitos, 86-88
revisando, 136, 137
Dependncia
da tarefa, 57
parcial, 193
transitiva, 195
Depsitos de dados, 146
Descongelamento, 392
Desenvolvimento
gil, 14
de aplicao rpida (RAD - rapid application
development), 9-14
de aplicaes conjuntas (JAD - joint application
development)
acompanhamento ps-sesso, 104
conduzindo sesses para, 103
eletrnico, 101
gerenciamento de problemas para, 105
para coleta de requisitos, 101-104
planejando sesses para, 102
preparao para sesses de, 103
selecionando participantes para, 102
incrementai na abordagem de objeto, 425, 427
iterativo na abordagem de objeto, 427
Desnormalizao, 322-325
Determinao de requisitos, 83-115
criando a, 88
definindo requisitos e a, 86-88, 111, 112
determinando requisitos e a, 87-88
identificando requisitos e a, 87
proposta de sistema e a, 84, 113
tcnicas de anlise para. Veja Anlise de requisitos
tcnicas de coleta de requisitos para a. Veja Coleta de
requisitos
DFDs. Veja Diagramas de fluxo de dados
Diagramas
de atividade, UML, 428
de casos de uso, UML, 424, 428, 431-435
criando, 433
elementos de, 431-433
de classe, UML, 428, 436-440
criando, 440-442
elementos dos, 436
simplificando, 440
de colaboraes, UML, 428
de componentes, UML, 428
de contexto, 148, 154, 156f, 163
de distribuio, UML, 428
de estado, UML, 428, 448-450
criando, 449
elementos de, 448
de estrutura de interface (ISDs - interface structure
diagrams), 270, 272
de fluxo de dados (DFDs), 143-169
criando fragmentos de, 155, 165, 166
definindo processos operacionais usando, 148-151
descries de processos para os, 148-154
diagramas de contexto para os, 148,154,156f, 163
elementos de, 146
examinando a consistncia de diagramas de
relacionamento de entidades com os, 195
fsico, 206, 218-220
interpretao, 144-146
lgico, 206, 218
validao, 160-163, 169
de objetos, UML, 428
de relacionamento de entidades (ERDs - entity
relationship diagrams), 173-197
construindo, 181-184
dicionrio de dados e, 179, 180, 182
elementos de, 175-179
entidades
dependentes e, 188
independentes e, 186
fsicos, 206, 222-226
identificando
atributos e, 183, 185
entidades e, 181-184
relacionamentos e, 184, 185, 187f

de seqncias, UML, 428, 442-447

criando, 446
elementos dos, 444-447
genricos, 444
nvel
0, 148, 158, 159, 165, 167
1, 148, 150, 157-160, 166, 168
2,150
Dicionrios de dados, 69, 179, 180, 182
Digitao, reduzindo, 286
Digitador, 285
Direes
funcionais, 64
tcnicas, 64
Diretrizes de projeto, validando ERDs e, 191, 193
Divises dos fluxos de dados, 150
Documentao, 70, 378-384, 386
do usurio, 378-384, 386
escrevendo tpicos para, 381, 383
identificando termos de navegao para a, 382
projetando a estrutura para a, 380
tipos de, 379
sistema, 377
Documentos
de consulta, 380
de retorno, 291,293
no SDLC, 3-4
DSSs - decision support systems (sistemas de suporte de
deciso), 317

E
Encapsulamento, 316
na abordagem de objeto, 422, 427
Ensaio do sistema, 84
Entidade(s), 175, 177
de interseo, 188
dependente, 188
externas, 147
identificando, 181-184
independente, 186
Entidade-filho, 177
Endade-pai, 177
Entradas
em leque (fan-in), 351, 353
na especificao do programa, 356
nos casos de uso, 123
Entrevistas
acompanhamento aps a, 100
bottom-up, 98
captura de requisitos para, 96-101
conduo de, 100
estruturadas, 98
no estruturadas, 98
planejando perguntas para, 97
preparao para, 99
selecionando entrevistados para, 96
top-down, 98
Equipe de projeto
criao da, 63-68
gerenciamento de conflitos e, 67
motivao e, 66
planejamento da equipe para, 63-68
habilidades e papis da, 15-18
ERP - enterprise resource planning (planejamento de
recursos de empresas), 209
Erros
de semntica, 160
de sintaxe, 160
de software, 410,411
na navegao, evitando que o usurio cometa, 278
simplificando a recuperao de, 279
Esboo seqencial, 275
Esforo, 55
do usurio, minimizando no projeto de interface com
o usurio, 263, 270
Especificao(es)
de hardware, 207
para projeto de arquitetura, 252
de programas, 352, 354-359
entradas e, 356
eventos e, 355, 356
informaes de programa e, 355
pseudocdigo e, 356
sadas e, 356

ndice
de software, 207
para o projeto de arquitetura, 252
do sistema, 6, 207
Estado, 421
nos diagramas de, 48
final, 448
inicial, 448
Esttica, projeto de interface com o usurio e a, 263, 266
Estimativas, 51
abordagem do ponto de funo para, 52-56
de esforo necessrio, 55
do tamanho
da armazenagem, 326-328, 330
do sistema, 52-55
do tempo necessrio, 56
do valor agregado ao sistema para o projeto de
arquitetura, 245-246
refinando estimativas e, 60-62
volumtricas, 326
Estratgia
de anlise, 5
de informaes para motivar a aceitao, 404
de projeto, 207-217
de desenvolvimento personalizado, 207
caractersticas de, 212-214
de software comercial pronto, 209
caractersticas da, 212-214
de terceirizao, 210-212
caractersticas da, 212-214
matriz alternativa para comparar a, 214-216
softwares comerciais como, 209
terceirizao como, 210-212
poltica para motivar a aceitao, 404
Estrutura
da interface, projeto de interface com o usurio e a,
270, 272, 294-298
de diviso de trabalho, 57
de transao, 343-345
de transformao, 345
Estudo de Viabilidade, 31
Etapas do SDLC, 3-4
Eventos
nas especificaes de programa, 355
nos diagramas de estado, 448
Experincia
do usurio, projeto de interface com o usurio
e a, 263, 268
interna, estratgias de projeto e a, 2)2
Extreme programming - XP, 13

F
FAQs - frequently asked questions (perguntas
freqentes), 407
Fase
de anlise do SDLC, 4, 6
de implementao do SDLC, 4, 6
de planejamento do SDLC, 4-5
de projeto, 206
do SDLC, 4, 6
Fatorao, 349
Ferramentas de engenharia de software auxiliada
por computador (CASE - computer-aided software
engineering), 68, 146, 154, 174, 181
Fichrios de projeto, 70
Fluxos de dados, 126, 146
Focos de controle nos diagramas de seqncia, 444, 447
Formatos de armazenagem de dados, 310
arquivos como, 310-319
bancos de dados como, 313-317
selecionando, 317-319, 328
Formulrios, 262
Fragmentos de DFD, 155, 165, 166

G
Generalizao de classes, 440
Gerenciamento
da mudana, 398-407, 412
avaliao de custos e benefcios e o, 401-403
motivando a aceitao e o, 404
resistncia mudana e o, 399, 404
revisando as polticas de gerenciamento e o, 400
treinando para habilitar a aceitao e o, 405
de conflitos, selecionando a equipe e, 67
de portflio, 43
de projeto, 5, 49-77
coordenando as atividades de projeto e o, 50-71,75
erros clssicos no, 72

estratgias de projeto e o, 213

identificao do tamanho do projeto e o, 50-56
plano de trabalho e o, 56-63
projetos de seleo de pessoal e o, 64-68, 73, 75
do cronograma, 372
do escopo, 62
do risco, 70
organizacional como parte interessada, 39
Gerenciando a programao, 370-372, 384
coordenando atividades e, 371
designando programadores e, 371
programando e, 372
Gerentes de projeto, 5, 50
como papel da equipe de projeto, 16-17
Grficos, 291, 293
de estrutura, 337-359
avaliando visando qualidade, 352, 440
conjugados e os, 343, 347, 351
criao, 343-345
diretrizes de projeto para os, 349-354
mdulos e os, 342, 346
revisando, 348
de Gantt, 58
PERT, 59
Grupo de operaes, 407
GUIs (interfaces grficas com o usurio), 262

H
Habilidades
de anlise crtica, 89
interpessoais, 65, 99
tcnicas, 65
Hardware, 237
Herana na abordagem de objeto, 423, 424, 427
Hyperlinks incorporados, 282

I
1-CASE (Integrated CASE), 68
cones de interface, 274
Identificao
de tarefa para o plano de trabalho, 57-63
do projeto, 26-31
solicitao de sistema e a, 30
Identificadores
nos ERDs, 176
concatenados, 177
nicos (UIDs - unique identifiers), 421
Indexao, 325
Informaes em tempo real, 284
Infra-estrutura de chave pblica (PKI - public key
infrastructure), 247
Iniciao do projeto
anlise de viabilidade e. Veja Anlise de viabilidade
seleo de projeto e a, 42-45
Incio do projeto, 25-46
identificao do projeto e a, 26-31
Instalao. Veja tambm Gerenciamento da mudana;
Converso; Atividades posteriores
implementao, 7, 391-413
Instanciao, 316
Instncias, 421
nos ERDs, 176
Institucionalizao de uso de novos sistemas, 407
Instrues
de ao, 151
"for", 151
"If\ 151
"While", 151
Integrao de sistemas, 210
Integrated CASE (I-CASE), 68
Integridade referencial, 224, 315
Interfaces
com o usurio, 262
planejamento de recursos de empresas, 285
do sistema. Veja tambm Projeto de interface, 262
grficas com o usurio (GUIs - graphical user
interfaces), 262
Interrupes do fornecimento de energia, custos de, 247
ISD - interface structure diagrams (diagramas de estrutura
de interface), 270, 272
terativo na abordagem de objeto, 425

J
JAD eletrnica (e-JAD), 101
Junes dos fluxos de dados, 150

459

L
Layout
nos diagramas de fluxo de dados, 156
projeto de interface com o usurio e, 263, 264f
Leitores de faixas magnticas, 285
Limite
do sistema nos diagramas de casos de uso, 433
homem-mquina, 218
Linguagem(ens)
de comando para controles de navegao, 279
de modelagem unificada (UML - unified modeling
language)
aspectos principais da, 429, 430
diagrama(s)
de atividades e a, 428
de caso de uso e a, 431-435
de classes e a, 428,435
de colaborao e a, 428
de componentes e a, 428
de distribuio e a, 428
de estado e a, 428
de objetos e a, 428
de seqncia e a, 428, 444-447
processo racional unificado e a, 427, 431
tcnicas de diagramao e a, 429
diagramas de estado e a, 448-450
natural para os controles de navegao, 279
para controles de navegao, 279
unificada de modelagem (UML - unified modeling
language), 426-430
Linha(s)
condicionais nos grficos de estrutura, 342
da vida nos diagramas de seqncias, 444, 447
Listas de vnculos, 311
Lgica
de acesso aos dados como funo de software, 237
de aplicao como funo de software, 237
de apresentao como funo de software, 237
Logs de programa, 372
Loops nos grficos de estrutura, 342
Lower-CASE, 68

M
Mainframes, 237
Manipulao direta, para navegao, 281
Manuais de procedimentos, 380
Manuteno de sistemas, 393, 408-410
Mapas de imagem, 282
Matrizes
alternativas para a seleo de estratgia de
projeto, 214-216
CRUD, 226-228
Mecanismo(s)
de entrada, 262, 284-290
princpios bsicos de, 284-290
tipos de, 286
validao de entrada e, 289, 290
de navegao, 262, 278-284
mensagens e, 283
princpios bsicos de, 278
tipos de controles para, 279-282
de sada, 262, 290-294
princpios bsicos de, 290
tipos de, 291,293
Mediador de JADs, 101
Medidas, poltica de gerenciamento, 401
Melhoria dos processos operacionais (BPI - business
process improvement), 88, 90-93
anlise de desempenho na, 92
anlise de durao na, 90
custo baseado na atividade na, 92
Membros de bancos de dados, 313
Mensagens, 283
de ajuda, 283
de confirmao, 283
de demora, 283
de erro, 283
na abordagem de objeto, 422, 427
nos diagramas de seqncias, 447
Menus, 262, 279-282
de guias, 282
hyperlink, 282
pop-up, 282
suspensos, 281
Metadados, 179, 182
Mtodo(s)
construtor, 438
de atualizao, 438

460

ndice

de consulta, 438
de fluxo de caixa, 36
identificando, 442
n& abordagem de objeto, 422
Metodologia(s). Veja Metodologias de desenvolvimento
de sistemas
de desenvolvimento de sistemas, 7-15
centradas em dados, 7
de desenvolvimento gil, 13, 14
de projeto estruturado, 8, 14
em cascata, 8, 14
em fases, 10-14
orientadas a objetos, 7
paralelo, 9, 14
selecionando, 14
de prototipao, 10, 14
de RAD - rapid applicaon development
(desenvolvimento de aplicao rpida), 9-14
Microcomputadores, 237
Middleware, 239
Minicomputadores, 237
Modalidades de relacionamentos, 178
Modelagem
de dados. Veja tambm Diagramas de relacionamento
de entidades (ERDs - entity relationship
diagrams), 173
papel do usurio na, 187
de processos. Veja tambm Diagramas de fluxo de
dados (DFDs), 143
orientada a eventos, 122
Modelo(s)
de dados, 5
fsico, 144, 174, 206, 218
lgico, 206
de interface, 274, 298, 300
de processos, 5
estticos, 435
furaco, 60
lgicos de processos, 144
Mdulos
coeso de, 349
converso e, 396
de biblioteca, 342
de controle, 342
nos grficos de estrutura, 342, 343, 346
subordinados, 342
Motivao
para aceitar o novo sistema, promovendo, 404
seleo da equipe e a, 66
Movimento para o objeto. Veja tambm Linguagem de
modelagem unificada (UML), 419-420
Mudana, processo de, 392
Multiplicidade de relacionamentos, 439

N
Necessidades
da empresa, 26
estratgias de projeto e, 212
operacionais, 29
estratgias de projeto e, 212
Normalizao, 191-195,322
primeira forma normal e a, 191-194
segunda forma normal e a, 193-194
terceira forma normal e a, 195
Normas implcitas, projeto de arquitetura e, 250
Ns em grficos PERT, 59
NPV - net present value (valor presente lquido), 36

O
Objetos, 421, 427
de interface, 274
identificando, 446
temporrios nos diagramas de seqncias, 444
Observao para coleta de requisitos, 107
Ocultao da informao na abordagem de objeto, 422,427
OODBMs - object-oriented database management
systems (sistemas de gerenciamento de banco de dados
orientado a objeto), 316, 318
hbrida, 316
Ordem gramatical
ao-objeto, 279
consistncia da, 279
objeto-ao, 279
Otimizao da armazenagem de dados, 320-328, 330
eficincia e a, 320
estimativa de tamanho da armazenagem e a, 326-328,330
velocidade de acesso e a, 321-326

P
Pacotes de casos de uso, 126
Padres, 69
de cdigos, 69
de documentos, 69
de interface
com o usurio, 69
projeto de interface com o usurio e os, 273-275,
298, 299
de procedimento, 69
do requisito de especificao, 69
Pginas Web, 262
Papel desempenhado pelos casos de uso, 127
Partes interessadas, 38
Patrocinadores do projeto como parte interessada, 39
Perguntas
abertas, 97
analticas, 97
fechadas, 97
freqentes (FAQs - frequently asked questions), 407
para entrevistas, 97
Pessoal de suporte nvel
1,407
2,407
PKI - public key infrastructure (infra-estrutura de chave
pblica), 247
Planejamento
da capacidade, 243-244
da equipe, 64-66
de recursos de empresas (ERP - enterprise resource
planning), 209
interfaces com o usurio, 285
Plano(s)
de migrao, 392
de suporte, 7
de testes, 373
de trabalho, 5, 57-63
do projeto, 5, 57
gerenciando o escopo e, 62
grficos
deGantte, 58
PERT e, 59
identificao de tarefas para, 57
refinando estimativas e, 60-62
tempo fixo e, 63
de treinamento, 7
Polimorfismo na abordagem de objeto, 424, 425, 427
Polticas de gerenciamento, revisando, 400
Ponteiros, 313
Ponto de equilbrio, determinando, 37
Pontos de vista
fragmentos de DFDs e, 156
nos casos de uso, 123
Portugus estruturado, 151
Possvel adotante, 399
Primeira forma normal (INF), normalizao, 191-194
Primeiro proponente, 27
Procedimentos operacionais padres (SOPs - standard
operating procedures), 400
Processamento
de transao, 284
em lotes, 284
on line, 284
Processo(s)
aferentes, 343
centrais, 343
descries de, 151-154
eferentes, 343
fsicos, 206
lgicos, 206
nos diagramas de fluxo de dados, 146
nos grficos de estrutura, 343
operacionais, usando diagramas de fluxo de dados
para definir, 148-151
racional unificado (RUP - rational unified process), 427
Programao, gerenciamento. Veja Gerenciando a
programao
Programas orientados a eventos, 355
Projeto
de armazenagem de dados, 6
de arquitetura, 6, 207, 235-255
elementos do, 236
especificao de hardware e software para o, 252
requisitos
culturais e polticos para o, 248-251
de desempenho para o, 243-244, 250
de segurana para o, 244-248, 251
operacionais para o, 242, 250
de esquema estrela, 323, 325

de interface, 6
de interface com o usurio, 261-301
avaliao da interface e o, 270, 276-278, 300
conscincia do contedo e o, 263, 266
consistncia no, 263, 269
de componentes
de entrada, 284-290
de navegao, 278-284
de sada, 290-294
desenvolvimento de cenrio de uso para o,
270,271,294
esttica e o, 263, 266
experincia do usurio e o, 263, 268
layout e o, 263, 264f
minimizando o esforo do usurio e o, 263, 270
modelos de interface para o, 274, 298, 300
projeto
de estrutura de interface para o, 270, 272,
294-298
de padres de interface para o, 270, 273-278,
298, 299
prototipao de projeto e o, 270,275-278,298,300
de programa. Veja tambm Especificaes de
programas; Grficos de estrutura, 6, 337-359
abordagem
modular para o, 338
top-down, modular para o, 338
de texto para interface, 266
definio de, 26
do sistema. Veja tambm Estratgia de projeto, 205-228
erros clssicos no, 208
Propostas de sistemas, 5, 84, 113
Prototipao
descartvel, 12, 14
projeto de interface com o usurio e a, 275-278,298,300
Prottipos
de sistemas, 12
do projeto, 13
projeto de interface com o usurio e os, 270, 275278, 298, 300
em HTML, 275
em linguagem, 275
Pseudocdigo na especificao de programa, 356

Q
Questionrios
acompanhamento de, 106
administrando, 106
esquematizando, 106
para coleta de requisitos, 104-106
selecionando participantes de, 104

R
Recompensas, poltica de gerenciamento e, 401
Recongelamento, 392
Reconhecimento ptico de caractere, 285
Redes, 237
Redimensionabilidade das arquiteturas cliente-servidor, 239
Reengenharia dos processos operacionais (BPR - business
process reengineering), 88, 93
anlise
de resultados na, 93
de tecnologia na, 93
eliminao de atividade na, 93
Referncias, relacionamentos e, 438
Regra(s)
de fundo para a sesso JAD, 103
dos trs cliques, 270
operacionais, 175
Relacionamentos
A-Kind-Of (AKO), 423
cardinalidade de, 178
entre entidades, 177
identificando, 184, 185, 187f
modalidades de, 178
no-identificados, 186
nos diagramas de classes, 438
Relatando estruturas, 64
Relatrios, 262
compreendendo o uso de, 290
de entrevistas, 100
de excees, 291
de problemas, 407
de resumo, 291,293
detalhados, 291,293
em lotes, 262, 290
em tempo real, 290

ndice
tipos de, 291,293
Repetio
nos diagramas de fluxo de dados, 157
nos grficos de estrutura, 340
Repositrio
CASE, 69
de informaes, 69
Requisitos
culturais para o projeto de arquitetura, 248-251
da empresa (de negcios), 27, 29, 85
de ambiente tcnico parao projeto de arquitetura, 242-243
de atualizao para o projeto de arquitetura, 242-243
de autenticao para o projeto de arquitetura, 245-247
de capacidade para o projeto de arquitetura, 243-244
de confiabilidade para o projeto de arquitetura, 243-244
de controle de acesso para o projeto de
arquitetura, 245-246
de controle de vrus para o projeto de
arquitetura, 245-246, 248
de criptografia para o projeto de arquitetura, 245-247
de desempenho para o projeto de
arquitetura, 243-244, 250
de disponibilidade para o projeto de arquitetura, 243-244
de integrao do sistema para o projeto de
arquitetura, 242-243
de personalizao para o projeto de arquitetura, 248
de portabilidade para o projeto de arquitetura, 242-243
de segurana para o projeto de arquitetura, 244-248,251
de sistema, 3, 85, 206
de velocidade para o projeto de arquitetura, 243-244
definio de, 86
determinando, 87-88
funcionais, 85
legais para o projeto de arquitetura, 250
multilnges para o projeto de arquitetura, 248
no-funcionais, 85, 86
operacionais para o projeto de arquitetura, 242, 250
polticos para o projeto de arquitetura, 248-251
Resistncia mudana, 399, 404
Responsveis
pela mudana, 398
pelo projeto, 26, 27, 29
Retomo do investimento (ROI - return on investment), 37
Reunies de trabalho, 73
Reversibilidade de algoritmos de criptografia de chave
pblica, 247
RFI - request for information (solicitao de
informaes), 216
RFP - request for proposal (solicitao de proposta), 215
Risco
estratgias de converso e, 397
seleo da tcnica de anlise de requisitos e, 95
ROI - return on investment (retorno do investimento), 37
Rtulos, 373
RUP - rational unified process (processo racional
unificado), 427, 431

s
Sadas
em leque (fan-out), 353, 354
na especificao de programa, 356
nos casos de uso, 123
SDLC. Veja Ciclo de vida do desenvolvimento de sistemas
Segunda forma normal (2NF), 193-194
Seleo
de projeto, 207-217
nos grficos de estrutura, 340
Seqncia nos grficos de estrutura, 340
Servidores, 237
Simbolismos de interface, 273
Smbolos de estado, 448
Sintaxe avanada, 186
Sistema(s)
crtico de misso, 245
de aplicaes, formatos de armazenagem e, 319

de gerenciamento de banco de dados (DBMs database management systems), 300, 318

de gerenciamento de banco de dados orientados a
objetos (OODBMSs - object-oriented database
management systems), 316, 318
de processamento de transao, formatos de
armazenagem e, 319
de suporte de deciso (DSSs - decision support
systems), 317
efetuando a transao para o novo, 392
formal, 107
futuro, 5
informal, 107
multilnges
discretos, 248
simultneos, 248
no estado, 5
Sobrecarga, requisitos do DBMS para a, 327
Software
erros de, 410, 411
funes de, 237
de gerenciamento de projeto, 50
Solicitao(es)
de informaes (RFI - request for information), 216
de proposta (RFP - request for proposal), 215
de mudanas, 408
de sistema, 28, 30, 408
SOPs - standard operating procedures (procedimentos
operacionais padres), 400
SQL - Structured Query Language, 315
Subclasses na abordagem de objeto, 423
Superclasses na abordagem de objeto, 423
Suporte
ao sistema, 393, 407
tcnico, 407

T
Tabelas
de deciso, 152
de pesquisa, 323
TAFP - total adjusted function points (total de pontos de
funo ajustados), 54
Tamanho
do projeto
identificando o, 50-56
viabilidade e, 32
do sistema, estimando, 52-55
Tarefas
crticas, 59
do plano de trabalho, 57
Tcnicas no SDLC, 3-4
Tecnologia emergente, 27
Tempo
estratgias de converso e o, 398
fixo, 63
Tendenciosidade, reduzindo, 291
Terceira forma normal (3NF), 195
Terminais, 237
Teste(s), 373-377, 385
aceitao, 378
alfa, 377
beta, 377
da caixa branca, 376, 377
da caixa preta, 376,, 377
de aceitao, 377
de unidade, 376, 376f, 377
de usabilidade de interfaces, 277
integrao, 376, 378
para unidades individuais, 376, 376f, 377
planejando, 373-377
sistema, 376, 378
Tipo de dados, formatos de dados e, 317
Top-down, abordagem modular para o projeto de
programa, 338
Tpicos de documentao, 380

461

Totais de pontos de funo no-ajustados (TUFP - total

unadjusted function points), 54
Total de pontos de funo ajustados (TAFP - total adjusted
function points), 54
Transies nos diagramas de estado, 450
Treinamento baseado em computador (CBT - computerbased training) para habilitar a aceitao, 405, 406
em grupo, 406
individual, 406
Trocas, 43, 50
TUFP - total unadjusted function points (total de pontos
de funo no-ajustados), 54
Tutoriais, 380

u
UIDs - unique identifier (identificadores nicos), 421
Upper CASE, 68
Usurios
do sistema como partes interessadas, 39
espontneos, 404
relutantes, 404
resistentes, 404

V
Validao
de entrada, 289, 290
deERDs, 189-197
diretrizes de projeto e a, 191, 193
normalizao e a, 191-195
verificando a consistncia entre ERDs e DFDs e
a, 195
Valor(es)
agregado, 27, 29
atribuindo a custos e benefcios, 34-36
hardcoded, 374
intangvel, 27
potencial agregado, seleo da tcnica de anlise de
requisitos e o, 94
presente lquido (NPV - net present value), 36
tangvel, 27
vlidos, 223
Valores-padro, 223, 286
Varreduras de tabelas, 325
Velocidade de acesso, otimizao, 321-326
Verificaes
de banco de dados, 289
de consistncia, 289
de formato, 289
de integridade, 289
de limites, 289
do dgito de verificao, 289
Viabilidade
econmica, 33-38
atribuindo valores a custos e benefcios e, 34-36
determinao
do ponto de equilbrio e, 37
do fluxo de caixa e, 36
do valor presente lquido e o retorno do
investimento e, 36
identificao de custo/benefcio e, 34
organizacional, 38-40
tcnica, 31
Vnculos em diagramas de seqncias, 444
Viso
dinmica na abordagem de objeto, 425, 427
esttica na abordagem de objeto, 425, 427
funcional na abordagem de objeto, 425, 427
Visibilidade de atributos, 437
Visualizao, 130

X
XP - Extreme programming, 13