O MOVIMENTO
PARA OS OBJETOS
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
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.
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.
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
1
w
Consulta
- Nome do paciente
- Nome do mdico
-Data
- Hora
+ Inserir ()()
+ Cancelar ()()
:
:
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
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.
2. O mtodo do objeto
responde mensagem.
2. O mtodo do objeto
responde mensagem.
425
U M 5-6
) e Encapsulamento
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.
Conceito
Classes, objetos, mtodos
e mensagens
Eicapsulamento e ocultao
Admite...
rieiona
o':morfismo
Desenvolvimento iterativo
e incrementai
Leva a...
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)
Menos redundncia
Criao mais rpida de novas classes
Padres e consistncia em e entre esforos
de desenvolvimento
Facilidade nas excees de suporte
Visualizao do sistema em
desenvolvimento a partir de diversos
pontos de vista
de informao
427
L 15-7
(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
Modela o comportamento
das classes dentro de
um caso de uso
Modelo de
processo
Anlise, projeto
Diagrama de
colaboraes
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
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
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
431
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
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
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.
Sistema de Consultas
FIGURA 1 5 - 1 4
Associaes Estende e Inclui
434
Capitulo Quinze
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
Cliente
BD de res, na loja
Informaes do cilente
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:
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
Informaes de CP
BP de CP
informaes de fornecedor
Fornecedor
promocionais
BP de marketing
Ger. de marketing
Nmero da ID:
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
Equipe na loja
Confirmao de reserva
BP de reserva na loja
Ajuste de estoque
BP de estoque
FIGURA 1 5 - 1 5
Casos de Uso Finais da CD Selections
Descrio
Solicitao de reserva
435
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-
.. _ .
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
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()
-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
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)
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
2 4
1..3,5
Fuiiciuniiu
Esposa
Folias
Comit
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.
441
de objetos
Um substantivo prprio ou uma referncia direta sugere
Por exemplo, "A lista de alunos no foi verificada" sugere que uma lista
operao de "arquivo"
agregao ou associao
classe cachorro
agregao entre carro e motor
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
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.)
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).
FIGURA 15-22
fornece
o ..*
~T
descreve
0..*
/\ /\ /\
FIGURA 1 5 - 2 3
Diagrama de Classes Final
reservado por
443
444
Captulo Quinze
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.
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
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.
FIGURA 1 5 - 2 6
Etapas do Cenrio Cliente Faz Pedido que
Resulta em um Pedido Especial
1.
2.
3.
4.
5.
447
FIGURA 1 5 - 2 7
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.
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.
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
FIGURA 1 5 - 2 9
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.
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
450
Captulo Quinze
FIGURA 15-31
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.
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
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.
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
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?
453
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
455
456
Captulo Quinze
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.
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)
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
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
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
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
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