Apostila Projeto 02 Falbo Mona

UFES - Universidade Federal do Esprito Santo
Engenharia de Software
Notas de Aula
PARTE II
Ricardo de Almeida Falbo

Monalessa Perini Barcellos
Curso: Engenharia da Computao
Adaptao, em 2011, por Monalessa Perini Barcellos das Notas de Aula de

Engenharia de Requisitos e Projeto de Sistemas de Ricardo de Almeida Falbo
Observao: Este material aborda contedos que vo alm do programa da

disciplina Engenharia de Software para o curso Engenharia da Computao.
No entanto, optou-se por incluir esses contedos para que alunos
que tenham interesse em se aprofundar no tema possam usar
este material como uma referncia.
NDICE
Organizao do Texto .............................................................................................................. 4
Captulo 5 Especificao e Anlise de Requisitos .............................................................. 5
5.1 Engenharia de Requisitos de Software .......................................................................... 5
5.1.1 - Requisito e Tipos de Requisitos .............................................................................. 5
5.1.2 - O Processo da Engenharia de Requisitos ................................................................ 6
5.2 O Paradigma Orientado a Objetos ................................................................................. 8
5.2.1 Princpios para Administrao da Complexidade .................................................. 8
5.2.2 Principais Conceitos da Orientao a Objetos ..................................................... 11
5.3 - Levantamento e Registro de Requisitos ....................................................................... 15
5.3.1 O Documento de Requisitos .................................................................................... 16
Escrevendo Requisitos Funcionais ............................................................................... 18
Escrevendo Requisitos No Funcionais ....................................................................... 19
Escrevendo Regras de Negcio .................................................................................... 20
5.3.3 O Documento de Especificao de Requisitos ..................................................... 23
5.4 Modelagem de Casos de Uso ........................................................................................ 25
5.4.1 Atores ...................................................................................................................... 26
5.4.2 Casos de Uso ........................................................................................................ 27
5.4.3 - Diagramas de Casos de Uso .................................................................................. 28
5.4.4 - Descrevendo Casos de Uso ................................................................................... 30
5.4.5 Descrevendo os Fluxos de Eventos ...................................................................... 32
5.4.6 Descrevendo Informaes Complementares ........................................................ 39
5.4.7 - Relacionamentos entre Casos de Uso ................................................................... 40
Incluso ........................................................................................................................ 40
Extenso ....................................................................................................................... 43
Generalizao / Especializao ................................................................................... 46
Diretrizes para o Uso dos Tipos de Relacionamentos entre Casos de Uso ................. 48
5.5 Modelagem Conceitual Estrutural ............................................................................... 49
5.5.1 Identificao de Classes .......................................................................................... 50
5.5.2 - Identificao de Atributos e Associaes ............................................................. 53
Atributos ....................................................................................................................... 54
Associaes .................................................................................................................. 57
5.5.3 Especificao de Hierarquias de Generalizao / Especializao ........................ 66
5.6 - Modelagem Dinmica .................................................................................................. 68
5.6.1 Diagrama de Estados ............................................................................................ 69
Captulo 6 Projeto de Sistemas .......................................................................................... 82
6.1 Aspectos Relevantes ao Projeto de Software ................................................................. 83
6.1.1 Qualidade do Projeto de Software ........................................................................... 84
6.1.2 Arquitetura de Software .......................................................................................... 85
6.1.3 Padres (Patterns) ................................................................................................... 88
6.1.4 Documentao de Projeto........................................................................................ 89
6.2 Projetando a Arquitetura de Software ............................................................................ 90
6.3 A Camada de Domnio do Problema.............................................................................. 91

6.3.1 Padres Arquitetnicos para o Projeto da Lgica de Negcio ............................... 92
Padro Modelo de Domnio ......................................................................................... 92
Padro Camada de Servio.......................................................................................... 93
6.3.2 Componente de Domnio do Problema (CDP) ........................................................ 95
6.3.3 Componente de Gerncia de Tarefas (CGT) ........................................................... 98
6.4 A Camada de Interface com o Usurio .......................................................................... 99
6.4.1 O Padro Modelo-Viso-Controlador (MVC) ........................................................ 99
6.4.2 Componente de Interao Humana (CIH) ............................................................. 101
6.4.3 Componente de Controle de Interao (CCI) ........................................................ 104
6.5 A Camada de Gerncia de Dados (CGD) ..................................................................... 104
6.5.1 Padres Arquitetnicos para a Camada de Gerncia de Dados.......................... 105
O Padro Data Mapper ............................................................................................. 105
O Padro DAO ........................................................................................................... 106
Captulo 7 Implementao e Testes ................................................................................. 109
7.1 - Implementao ........................................................................................................... 109
7.2 - Testes ......................................................................................................................... 110
7.2.1 Tcnicas de Teste ............................................................................................... 111
7.2.2 Estratgias de Teste ............................................................................................ 113
Captulo 8 Entrega e Manuteno ................................................................................... 116
8.1 - Entrega ....................................................................................................................... 116
8.2 - Manuteno ................................................................................................................ 116
Engenharia de Software: Notas de Aula

Organizao do Texto
Este material parte integrante das Notas de Aula da disciplina Engenharia de Software,
as quais encontram-se divididas em duas partes.
Na Parte I foram abordados o processo de software em si e as atividades de
gerncia de projetos e de garantia da qualidade. Os captulos da Parte I so:
Captulo 1 Introduo captulo de introduo ao contedo.
Captulo 2 Processo de Software enfoca os processos de software, os

elementos que compem um processo, a definio de processos para
projetos, modelos de processo, normas e modelos de qualidade de processo
de software e a automatizao do processo de software.
Captulo 3 Gerncia de Projetos so abordadas as principais atividades da

gerncia de projetos, a saber: definio do escopo do projeto, estimativas,
anlise de riscos, elaborao de cronograma, elaborao do plano de projeto
e acompanhamento de projetos.
Captulo 4 Gerncia da Qualidade trata de algumas atividades

relacionadas garantia da qualidade, incluindo a medio e mtricas
associadas, revises e inspees e a gerncia de configurao de software.
Este material constitui a Parte II das Notas de Aula de Engenharia de Software e

aborda as atividades de desenvolvimento. Contm quatro captulos:
Captulo 5 Especificao e Anlise de Requisitos so discutidos o que

um requisito de software e tipos de requisitos. Em seguida, so abordadas a
especificao e a anlise de requisitos. oferecida uma viso geral da
abordagem de Anlise Orientada a Objetos. As tcnicas de modelagem de
casos de uso, modelagem estrutural e modelagem de estados so
apresentadas.
Captulo 6 Projeto de Sistema aborda os conceitos bsicos de projeto de

sistemas, tratando da arquitetura do sistema a ser desenvolvido e do projeto
de seus componentes. Tambm so discutidos o projeto de dados e o projeto
de interface com o usurio.
Captulo 7 Implementao e Testes so enfocadas as atividades de

implementao e testes, sendo esta ltima tratada em diferentes nveis, a
saber: teste de unidade, teste de integrao, teste de validao e teste de
sistema.
Captulo 8 Entrega e Manuteno discute as questes relacionadas

entrega do sistema para o cliente, tais como o treinamento e a documentao
de entrega, e a atividade de manuteno do sistema.
_________________________________________________________________________________________________________
(Adaptao por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo)
Captulo 5 Especificao e Anlise de Requisitos

Uma vez estudadas as atividades de gerncia de projetos (Captulo 3) e de
garantia de qualidade (Captulo 4), podemos passar a discutir as atividades do processo
de desenvolvimento de software, ou seja, aquelas atividades que contribuem
diretamente para o desenvolvimento do produto de software a ser entregue ao cliente e
que, portanto, formam a espinha dorsal do desenvolvimento.
No que tange s atividades tcnicas do desenvolvimento de software, a primeira
coisa a ser feita capturar os requisitos que o sistema a ser desenvolvido tem de tratar.
Um completo entendimento dos requisitos do software essencial para o sucesso de um
esforo de desenvolvimento de software. A Engenharia de Requisitos um processo de
descoberta, refinamento, modelagem e especificao. O escopo do software definido no
planejamento do projeto refinado em detalhe, as funes e o desempenho do software
so especificados, as interfaces com outros sistemas so indicadas e restries que o
software deve atender so estabelecidas. Modelos dos dados requeridos, do controle e
do comportamento operacional so construdos. Finalmente, critrios para a avaliao
da qualidade em atividades subsequentes so estabelecidos.
Este captulo bastante extenso e encontra-se assim organizado: na seo 5.1
so apresentados o conceito de requisitos e o processo de Engenharia de Requisitos; na
seo 5.2 o paradigma orientado a objetos, luz do qual as atividades do processo de
desenvolvimento so discutidas neste texto, apresentado; na seo 5.3 so discutidos o
levantamento e registro dos requisitos; a seo 5.4 trata da modelagem de caso de uso; a
seo 5.5 trata da modelagem conceitual estrutura; e, por fim, a seo 5.6 aborda os
diagramas de estados.
5.1 Engenharia de Requisitos de Software

Uma das principais medidas do sucesso de um software o grau no qual ele
atende aos objetivos e requisitos para os quais foi construdo. De forma geral, a
Engenharia de Requisitos de Software o processo de identificar todos os envolvidos,
descobrir seus objetivos e necessidades e document-los de forma apropriada para
anlise, comunicao e posterior implementao (TOGNERI, 2002). Mas antes de
voltar a ateno para as atividades do processo de Engenharia de Requisitos,
importante entender o que um requisito.
5.1.1 - Requisito e Tipos de Requisitos
As descries das funes que um sistema deve incorporar e das restries que
devem ser satisfeitas so os requisitos para o sistema. Isto , os requisitos de um sistema
definem o que o sistema deve fazer e as circunstncias sob as quais deve operar. Em
outras palavras, os requisitos definem os servios que o sistema deve fornecer e
dispem sobre as restries operao do mesmo (SOMMERVILLE, 2007).
Requisitos so, normalmente, classificados em requisitos funcionais e
requisitos no funcionais. Requisitos funcionais, como o prprio nome indica,
apontam as funes que o sistema deve fornecer e como o sistema deve se comportar
em determinadas situaes. J os requisitos no funcionais descrevem restries sobre
_________________________________________________________________________________________________________
as funes oferecidas, tais como restries de tempo, de uso de recursos etc. Alguns
requisitos no funcionais dizem respeito ao sistema como um todo e no a
funcionalidade especfica. Dependendo da natureza, os requisitos no funcionais podem
ser classificados de diferentes maneiras, tais como requisitos de desempenho, requisitos
de portabilidade, requisitos legais, requisitos de conformidade etc (SOMMERVILLE,
2007).
5.1.2 - O Processo da Engenharia de Requisitos
O processo de descobrir, analisar, documentar e verificar / validar requisitos
chamado de processo de engenharia de requisitos (SOMMERVILLE, 2007). Os
processos de engenharia de requisitos variam muito de uma organizao para outra,
mas, de maneira geral, a maioria dos processos de Engenharia de Requisitos composta
das seguintes atividades (TOGNERI, 2002):
Levantamento (ou Descoberta ou Elicitao) de Requisitos: Nesta fase, os

usurios, clientes e especialistas de domnio so identificados e trabalham junto
com os engenheiros de requisitos para descobrir, articular e entender a
organizao como um todo, o domnio da aplicao, os processos de negcio
especficos, as necessidades que o software deve atender e os problemas e
deficincias dos sistemas atuais. Os diferentes pontos de vista dos participantes
do processo, bem como as oportunidades de melhoria e restries existentes, os
problemas a serem resolvidos, o desempenho requerido e as restries tambm
devem ser levantados.
Anlise de Requisitos: visa a estabelecer um conjunto acordado de requisitos

consistentes e sem ambiguidades, que possa ser usado como base para o
desenvolvimento do software. Para tal, diversos tipos de modelos so
construdos. Geralmente, a anlise de requisitos inclui tambm a negociao
para resolver conflitos detectados.
Documentao de Requisitos: a atividade de representar os resultados da

Engenharia de Requisitos em um documento (ou conjunto de documentos),
contendo os requisitos do software.
Verificao e Validao de Requisitos: A verificao de requisitos avalia se o

documento de Especificao de Requisitos est sendo construdo de forma
correta, de acordo com padres previamente definidos, sem conter requisitos
ambguos, incompletos ou, ainda, requisitos incoerentes ou impossveis de
serem testados. J a validao diz respeito a avaliar se esse documento est
correto, ou seja, se os requisitos e modelos documentados atendem s reais
necessidades e requisitos dos usurios / cliente.
Gerncia de Requisitos: se preocupa em gerenciar as mudanas nos requisitos j

acordados, manter uma trilha dessas mudanas, gerenciar os relacionamentos
entre os requisitos e as dependncias entre o documento de requisitos e os
demais artefatos produzidos no processo de software, de forma a garantir que
mudanas nos requisitos sejam feitas de maneira controlada e documentada.
possvel notar que, das cinco atividades do processo de Engenharia de

Requisitos anteriormente listadas, as trs ltimas so, na realidade, instanciaes para a
Engenharia de Requisitos de atividades genricas j discutidas no captulo 4, a saber:
_________________________________________________________________________________________________________
documentao, garantia da qualidade e gerncia de configurao. Assim sendo, neste

captulo, somente as duas primeiras atividades (Levantamento e Anlise de Requisitos)
so discutidas.
O levantamento de requisitos uma atividade complexa que no se resume
somente a perguntar s pessoas o que elas desejam e tambm no uma simples
transferncia de conhecimento. Vrias tcnicas de levantamento de requisitos so
normalmente empregadas pelos engenheiros de requisitos (ou analistas de sistemas),
dentre elas entrevistas, questionrios, prototipao, investigao de documentos,
observao, dinmicas de grupo etc.
Uma caracterstica fundamental da atividade de levantamento de requisitos o
seu enfoque em uma viso do cliente / usurio. Em outras palavras, est-se olhando para
o sistema a ser desenvolvido por uma perspectiva externa. Ainda no se est procurando
definir a estrutura interna do sistema, mas sim procurando saber que funcionalidades o
sistema deve oferecer ao usurio e que restries elas devem satisfazer.
A anlise de requisitos (muitas vezes chamada anlise de sistemas), por outro
lado, enfoca a estrutura interna do sistema. Ou seja, procura-se definir o que o sistema
tem de ter internamente para tratar adequadamente os requisitos levantados. Assim
sendo, a anlise de requisitos , em ltima instncia, uma atividade de construo de
modelos. Um modelo uma representao de alguma coisa do mundo real, uma
abstrao da realidade, e, portanto, representa uma seleo de caractersticas do mundo
real relevantes para o propsito do sistema em questo.
Modelos so fundamentais no desenvolvimento de sistemas. Tipicamente eles
so construdos para:
possibilitar o estudo do comportamento do sistema;
facilitar a comunicao entre os componentes da equipe de desenvolvimento

e clientes e usurios;
possibilitar a discusso de correes e modificaes com o usurio;
formar a documentao do sistema.
Um modelo enfatiza um conjunto de caractersticas da realidade, que

corresponde dimenso do modelo. Alm da dimenso que um modelo enfatiza,
modelos possuem nveis de abstrao. O nvel de abstrao de um modelo diz respeito
ao grau de detalhamento com que as caractersticas do sistema so representadas. Em
cada nvel h uma nfase seletiva nos detalhes representados. No caso do
desenvolvimento de sistemas, geralmente, so considerados trs nveis:
conceitual: considera caractersticas do sistema independentes do ambiente

computacional (hardware e software) no qual o sistema ser implementado.
Essas caractersticas so dependentes unicamente das necessidades do usurio.
Modelos conceituais so construdos na atividade de anlise de requisitos.
lgico: caractersticas dependentes de um determinado tipo de sistema

computacional. Essas caractersticas so, contudo, independentes de produtos
especficos. Tais modelos so tpicos da fase de projeto.
fsico: caractersticas dependentes de um sistema computacional especfico, isto

, uma linguagem e um compilador especfico, um sistema gerenciador de
bancos de dados especfico, o hardware de um determinado fabricante etc. Tais
_________________________________________________________________________________________________________
modelos podem ser construdos tanto na fase de projeto quanto na fase de

implementao.
Conforme apontado acima, nas primeiras etapas do processo de
desenvolvimento (levantamento e anlise de requisitos), o engenheiro de software
representa o sistema atravs de modelos conceituais. Nas etapas posteriores, as
caractersticas lgicas e fsicas so representadas em novos modelos.
Para conduzir o processo de engenharia de requisitos, sobretudo a modelagem
conceitual, necessrio adotar um paradigma de desenvolvimento. Paradigmas de
desenvolvimento estabelecem a forma de se ver o mundo e, portanto, definem as
caractersticas bsicas dos modelos a serem construdos. Por exemplo, o paradigma
orientado a objetos parte do pressuposto que o mundo povoado por objetos, ou seja, a
abstrao bsica para se representar as coisas do mundo so os objetos. J o paradigma
estruturado adota uma viso de desenvolvimento baseada em um modelo entradaprocessamento-sada. No paradigma estruturado, os dados so considerados
separadamente das funes que os transformam e a decomposio funcional usada
intensamente.
Neste texto, discutimos as atividades do processo de desenvolvimento de
software luz do paradigma orientado a objetos. Assim sendo, as atividades de
levantamento e anlise de requisitos so conduzidas tomando por base esse paradigma.
Na prxima seo so apresentados os principais conceitos do paradigma orientado a
objetos.
5.2 O Paradigma Orientado a Objetos

Um dos paradigmas de desenvolvimento mais adotados atualmente a
orientao a objetos. Segundo esse paradigma, o mundo visto como sendo composto
por objetos, onde um objeto uma entidade que combina estrutura de dados e
comportamento funcional. No paradigma orientado a objetos, os sistemas so
modelados como um nmero de objetos que interagem.
A orientao a objetos oferece um nmero de conceitos bastante apropriados
para a modelagem de sistemas. Os modelos baseados em objetos so teis para a
compreenso de problemas, para a comunicao com os especialistas e usurios das
aplicaes, e para a realizao das tarefas ao longo do processo de desenvolvimento de
software. Em um sistema construdo segundo o paradigma orientado a objetos (OO),
componentes so partes encapsuladas de dados e funes, que podem herdar atributos e
comportamento de outros componentes da mesma natureza e cujos componentes
comunicam-se entre si por meio de mensagens (YOURDON, 1994). O paradigma OO
utiliza uma perspectiva humana de observao da realidade, incluindo objetos,
classificao e compreenso hierrquica.
Para fazer bom uso do paradigma OO, importante conhecer os princpios
adotados por ele na administrao da complexidade, bem como seus principais
conceitos.
5.2.1 Princpios para Administrao da Complexidade
O mundo real algo extremamente complexo. Quanto mais de perto o
observamos, mais claramente percebemos sua complexidade. A orientao a objetos
_________________________________________________________________________________________________________

tenta gerenciar a complexidade inerente dos problemas do mundo real, abstraindo

conhecimento relevante e encapsulando-o dentro de objetos. De fato, alguns princpios
bsicos gerais para a administrao da complexidade norteiam o paradigma orientado a
objetos, entre eles abstrao, encapsulamento e modularidade.
Abstrao
Uma das principais formas do ser humano lidar com a complexidade atravs
do uso de abstraes. As pessoas tipicamente tentam compreender o mundo,
construindo modelos mentais de partes dele. Tais modelos so uma viso simplificada
de algo, onde apenas os elementos relevantes so considerados. Modelos, portanto, so
mais simples do que os complexos sistemas que eles modelam.
Seja o exemplo de um mapa representando um modelo de um territrio. Um
mapa til porque abstrai apenas as caractersticas do territrio que se deseja modelar.
Se um mapa inclusse todos os detalhes do territrio, provavelmente teria o mesmo
tamanho do territrio e, portanto, no serviria a seu propsito.
Da mesma forma que um mapa precisa ser significativamente menor que o
territrio que mapeia, incluindo apenas as informaes selecionadas, um modelo deve
abstrair apenas as caractersticas relevantes de um sistema para seu entendimento.
Assim, pode-se definir abstrao como sendo o princpio de ignorar aspectos no
relevantes de um assunto, segundo a perspectiva de um observador, tornando possvel
uma concentrao maior nos aspectos principais do mesmo. De fato, a abstrao
consiste na seleo que um observador faz de alguns aspectos de um assunto, em
detrimento de outros que no demonstram ser relevantes para o propsito em questo. A
Figura 5.1 ilustra o conceito de abstrao.
Mapa Rodovirio
So Paulo
Mapa de Temperaturas
Figura 5.1 Ilustrao do Conceito de Abstrao.

Um conjunto de abstraes pode formar uma hierarquia e, pela identificao
dessas hierarquias, possvel simplificar significativamente o entendimento sobre um
problema (BOOCH, 1994). Assim, hierarquia uma forma interessante de arrumar as
abstraes.
_________________________________________________________________________________________________________
10
Encapsulamento
No mundo real, um objeto pode interagir com outro sem conhecer seu
funcionamento interno. Uma pessoa, por exemplo, utiliza um forno de microondas sem
saber efetivamente qual a sua estrutura interna ou como seus mecanismos internos so
ativados. Para utiliz-lo, basta saber usar seu painel de controle (a interface do aparelho)
para realizar as operaes de ligar/desligar, informar o tempo de cozimento etc. Como
essas operaes produzem os resultados, no interessa ao cozinheiro. A Figura 5.2
ilustra o conceito de encapsulamento.
Estrutura Interna
Interface
Figura 5.2 Ilustrao do Conceito de Encapsulamento.

O encapsulamento consiste na separao dos aspectos externos de um objeto,
acessveis por outros objetos, de seus detalhes internos de implementao, que ficam
ocultos dos demais objetos (BLAHA; RUMBAUGH, 2006). A interface de um objeto
deve ser definida de forma a revelar o menos possvel sobre o seu funcionamento
interno.
Abstrao e encapsulamento so conceitos complementares: enquanto a
abstrao enfoca o comportamento observvel de um objeto, o encapsulamento oculta a
implementao que origina esse comportamento. Encapsulamento frequentemente
conseguido atravs da ocultao de informao, isto , escondendo detalhes que no
contribuem para suas caractersticas essenciais. Tipicamente, em um sistema orientado a
objetos, a estrutura de um objeto e a implementao de seus mtodos so encapsuladas
(BOOCH, 1994). Assim, o encapsulamento serve para separar a interface contratual de
uma abstrao e sua implementao. Os usurios tm conhecimento apenas das
operaes que podem ser requisitadas e precisam estar cientes apenas do qu as
operaes realizam e no como elas esto implementadas.
A principal motivao para o encapsulamento facilitar a reutilizao de objetos
e garantir estabilidade aos sistemas. Um encapsulamento bem feito pode servir de base
para a localizao de decises de projeto que necessitam ser alteradas. Uma operao
pode ter sido implementada de maneira ineficiente e, portanto, pode ser necessrio
escolher um novo algoritmo. Se a operao est encapsulada, apenas o objeto que a
define precisa ser modificado, garantindo estabilidade ao sistema.
_________________________________________________________________________________________________________
11
Modularidade
Os mtodos de desenvolvimento de software buscam obter sistemas modulares,
isto , construdos a partir de elementos que sejam autnomos e conectados por uma
estrutura simples e coerente. Modularidade visa obteno de sistemas decompostos
em um conjunto de mdulos coesos e fracamente acoplados e crucial para se obter
reusabilidade e facilidade de extenso.
Abstrao, encapsulamento e modularidade so princpios sinergticos, isto , ao
se trabalhar bem com um deles, esto-se aperfeioando os outros tambm.
5.2.2 Principais Conceitos da Orientao a Objetos
De maneira simples, o paradigma OO traz uma viso de mundo em que os
fenmenos e domnios so vistos como colees de objetos interagindo entre si. Essa
forma simples de se colocar a viso do paradigma OO esconde conceitos importantes da
orientao a objetos que so a base para o desenvolvimento OO, tais como classes,
associaes, generalizao etc. A seguir os principais conceitos da orientao a objetos
so discutidos.
Objetos
O mundo real povoado por entidades que interagem entre si, onde cada uma
delas desempenha um papel especfico. Na orientao a objetos, essas entidades so
ditas objetos. Objetos podem ser coisas concretas ou abstratas, tais como um carro, uma
reserva de passagem area, uma organizao etc.
Do ponto de vista da modelagem de sistemas, um objeto uma entidade que
incorpora uma abstrao relevante no contexto de uma aplicao. Um objeto possui um
estado (informao), exibe um comportamento bem definido (dado por um nmero de
operaes para examinar ou alterar seu estado) e tem identidade nica.
O estado de um objeto compreende o conjunto de suas propriedades, associadas
a seus valores correntes. Propriedades de objetos so geralmente referenciadas como
atributos e associaes. Portanto, o estado de um objeto diz respeito aos seus
atributos/associaes e aos valores a eles associados.
A abstrao incorporada por um objeto caracterizada por um conjunto de
servios ou operaes que outros objetos, ditos clientes, podem requisitar. Operaes
so usadas para recuperar ou manipular a informao de estado de um objeto e se
referem apenas s estruturas de dados do prprio objeto, no devendo acessar
diretamente estruturas de outros objetos. Caso a informao necessria para a realizao
de uma operao no esteja disponvel, o objeto ter de colaborar com outros objetos.
A comunicao entre objetos d-se por meio de troca de mensagens. Para
requisitar uma operao de um objeto, necessrio enviar uma mensagem para ele.
Uma mensagem consiste do nome da operao sendo requisitada e os argumentos
requeridos. Assim, o comportamento de um objeto representa como esse objeto reage s
mensagens a ele enviadas. Em outras palavras, o conjunto de mensagens a que um
objeto pode responder representa o seu comportamento. Um objeto , pois, uma
entidade que tem seu estado representado por um conjunto de atributos (uma estrutura
de informao) e seu comportamento representado por um conjunto de operaes.
_________________________________________________________________________________________________________
12
Cada objeto tem uma identidade prpria, que lhe inerente. Todos os objetos
tm existncia prpria, ou seja, dois objetos so distintos, mesmo se seus estados e
comportamentos forem iguais. A identidade de um objeto transcende os valores
correntes de suas propriedades.
Classes
No mundo real, diferentes objetos desempenham um mesmo papel. Seja o caso
de duas cadeiras. Apesar de serem objetos diferentes, elas compartilham uma mesma
estrutura e um mesmo comportamento. Entretanto, no h necessidade de se despender
tempo modelando cada cadeira. Basta definir, em um nico lugar, um modelo
descrevendo a estrutura e o comportamento desses objetos. A esse modelo d-se o nome
de classe. Uma classe descreve um conjunto de objetos com as mesmas propriedades
(atributos e associaes), o mesmo comportamento (operaes) e a mesma semntica.
Objetos que se comportam da maneira especificada pela classe so ditos instncias
dessa classe.
Todo objeto pertence a uma classe, ou seja, instncia de uma classe. De fato, a
orientao a objetos norteia o processo de desenvolvimento atravs da classificao de
objetos, isto , objetos so agrupados em classes, em funo de exibirem facetas
similares, sem, no entanto, perda de sua individualidade, como ilustra a Figura 5.3.
Assim, do ponto de vista estrutural, a modelagem orientada a objetos consiste,
basicamente, na definio de classes. O comportamento e a estrutura de informao de
uma instncia so definidos pela sua classe.
Objetos com propriedades e comportamento idnticos so descritos como
instncias de uma mesma classe, de modo que a descrio de suas propriedades possa
ser feita uma nica vez, de forma concisa, independentemente do nmero de objetos que
tenham tais propriedades em comum. Deste modo, uma classe captura a semntica das
caractersticas comuns a todas as suas instncias.
Enquanto um objeto individual uma entidade real, que executa algum papel no
sistema como um todo, uma classe captura a estrutura e comportamento comum a todos
os objetos que ela descreve. Assim, uma classe serve como uma espcie de contrato que
deve ser estabelecido entre uma abstrao e todos os seus clientes.
Figura 5.3 Ilustrao do conceito de Classificao (BOOCH, 1994).
_________________________________________________________________________________________________________


13
Ligaes e Associaes
Em qualquer sistema, objetos relacionam-se uns com os outros. Por exemplo, em
o empregado Joo trabalha no Departamento de Pessoal, temos um relacionamento
entre o objeto empregado Joo e o objeto Departamento de Pessoal.
Ligaes e associaes so meios de se representar relacionamentos entre
objetos e entre classes, respectivamente. Uma ligao uma conexo entre objetos. No
exemplo anterior, h uma ligao entre os objetos Joo e Departamento de Pessoal.
Uma associao, por sua vez, descreve um conjunto de ligaes com estrutura e
semntica comuns. No exemplo anterior, h uma associao entre as classes Empregado
e Departamento. Todas as ligaes de uma associao interligam objetos das mesmas
classes e, assim, uma associao descreve um conjunto de potenciais ligaes da mesma
maneira que uma classe descreve um conjunto de potenciais objetos (BLAHA;
RUMBAUGH, 2006).
Uma associao comum entre duas classes representa um relacionamento
estrutural entre pares, significando que essas duas classes esto em um mesmo nvel,
sem que uma seja mais importante do que a outra. Alm das associaes comuns, a
UML considera dois tipos de associaes especiais entre objetos: composio e
agregao. Ambos representam relaes todo-parte. A agregao uma forma especial
de associao que especifica um relacionamento entre um objeto agregado (o todo) e
seus componentes (as partes). A composio, por sua vez, uma forma de agregao na
qual o tempo de vida entre todo e partes coincidente. As partes podem at ser criadas
aps a criao do todo, mas uma vez criadas, vivem e morrem com o todo. Uma parte
pode ainda ser removida explicitamente antes da morte do todo (BOOCH;
RUMBAUGH; JACOBSON, 2006).
Generalizao / Especializao
Muitas vezes, um conceito geral pode ser especializado, adicionando-se novas
caractersticas. Seja o exemplo do conceito de estudante no contexto de uma
universidade. De modo geral, h caractersticas que so intrnsecas a quaisquer
estudantes da universidade. Entretanto, possvel especializar este conceito para
mostrar especificidades de subtipos de estudantes, tais como estudantes de graduao e
estudantes de ps-graduao.
Da maneira inversa, pode-se extrair de um conjunto de conceitos, caractersticas
comuns que, quando generalizadas, formam um conceito geral. Por exemplo, ao se
avaliar os conceitos de carros, motos, caminhes e nibus, pode-se notar que eles tm
caractersticas comuns que podem ser generalizadas em um supertipo veculo automotor
terrestre.
As abstraes de especializao e generalizao so muito teis para a
estruturao de sistemas. Com elas, possvel construir hierarquias de classes. A
herana um mecanismo para modelar similaridades entre classes, representando as
abstraes de generalizao e especializao. Atravs da herana, possvel tornar
explcitos propriedades e operaes comuns em uma hierarquia de classes. O
mecanismo de herana possibilita reutilizao, captura explcita de caractersticas
comuns e definio incremental de classes.
No que se refere definio incremental de classes, a herana permite conceber
uma nova classe como um refinamento de outras classes. A nova classe pode herdar as
similaridades e definir apenas as novas caractersticas.
_________________________________________________________________________________________________________
14
A herana , portanto, um relacionamento entre classes (em contraposio s

associaes que representam relacionamentos entre objetos das classes), no qual uma
classe compartilha a estrutura e comportamento definido em uma ou mais outras
classes. A classe que herda caractersticas1 chamada subclasse e a que fornece as
caractersticas, superclasse. Desta forma, a herana representa uma hierarquia de
abstraes na qual uma subclasse herda de uma ou mais superclasses.
Tipicamente, uma subclasse aumenta ou redefine caractersticas de suas
superclasses. Assim, se uma classe B herda de uma classe A, todas as caractersticas
descritas em A tornam-se automaticamente parte de B, que ainda livre para acrescentar
novas caractersticas para seus propsitos especficos.
A generalizao permite abstrair, a partir de um conjunto de classes, uma classe
mais geral contendo todas as caractersticas comuns. A especializao a operao
inversa e, portanto, permite especializar uma classe em um nmero de subclasses,
explicitando as diferenas entre as novas subclasses. Deste modo possvel compor a
hierarquia de classes. Esses tipos de relacionamento so conhecidos tambm como
relacionamentos um tipo de, onde um objeto da subclasse tambm um tipo de
objeto da superclasse. Neste caso uma instncia da subclasse dita uma instncia
indireta da superclasse.
Mensagens e Mtodos
A abstrao incorporada por um objeto caracterizada por um conjunto de
operaes que podem ser requisitadas por outros objetos, ditos clientes. Mtodos so
implementaes reais de operaes. Para que um objeto realize alguma tarefa,
necessrio enviar a ele uma mensagem, solicitando a execuo de um mtodo
especfico. Um cliente s pode acessar um objeto atravs da emisso de mensagens, isto
, ele no pode acessar ou manipular diretamente os dados associados ao objeto. Os
objetos podem ser complexos e o cliente no precisa tomar conhecimento de sua
complexidade interna. O cliente precisa saber apenas como se comunicar com o objeto e
como ele reage. Assim, garante-se o encapsulamento.
As mensagens so o meio de comunicao entre objetos e so responsveis pela
ativao de todo e qualquer processamento. Dessa forma, possvel garantir que
clientes no sero afetados por alteraes nas implementaes de um objeto que no
alterem o comportamento esperado de seus servios.
Classes e Operaes Abstratas
Nem todas as classes so projetadas para instanciar objetos. Algumas so usadas
simplesmente para organizar caractersticas comuns a diversas classes. Tais classes so
ditas classes abstratas. Uma classe abstrata desenvolvida basicamente para ser
herdada por outras classes. Ela existe meramente para que um comportamento comum a
um conjunto de classes possa ser colocado em uma localizao comum e definido uma
nica vez. Assim, uma classe abstrata no possui instncias diretas, mas suas classes
descendentes concretas, sim. Uma classe concreta uma classe instancivel, isto , que
pode ter instncias diretas. Uma classe abstrata pode ter subclasses tambm abstratas,
mas as classes-folhas na rvore de herana devem ser classes concretas.
1
O termo caracterstica usado aqui para designar estrutura (atributos e associaes) e comportamento
(operaes).
_________________________________________________________________________________________________________
15
Classes abstratas podem ser projetadas de duas maneiras distintas. Primeiro, elas
podem prover implementaes completamente funcionais do comportamento que
pretendem capturar. Alternativamente, elas podem prover apenas definio de um
protocolo para uma operao sem apresentar um mtodo correspondente. Tal operao
dita uma operao genrica ou abstrata. Neste caso, a classe abstrata no
completamente implementada e todas as suas subclasses concretas so obrigadas a
prover uma implementao para suas operaes abstratas. Assim, diz-se que uma
operao abstrata define apenas a assinatura2 a ser usada nas implementaes que as
subclasses devero prover, garantindo, assim, uma interface consistente. Mtodos que
implementam uma operao genrica tm a mesma semntica.
Uma classe concreta no pode conter operaes abstratas, porque seno seus
objetos teriam operaes indefinidas. Analogamente, toda classe que possuir uma
operao genrica no pode ter instncias diretas e, portanto, obrigatoriamente uma
classe abstrata.
5.3 - Levantamento e Registro de Requisitos

Uma vez que levantar requisitos no tarefa fcil, imprescindvel que essa
atividade seja cuidadosamente conduzida, fazendo uso de diversas tcnicas. Dentre as
diversas tcnicas que podem ser aplicadas para o levantamento de requisitos, destacamse: entrevistas, questionrios, observao, investigao de documentos, prototipagem,
cenrios, abordagens em grupo, abordagens baseadas em objetivos e reutilizao de
requisitos.
Os resultados do levantamento de requisitos tm de ser registrados em um
documento, de modo que possam ser verificados, validados e utilizados como base para
outras atividades do processo de software. Para que sejam teis, os requisitos tm de ser
escritos em um formato compreensvel por todos os interessados. Alm disso, esses
interessados devem interpret-los uniformemente.
Normalmente, requisitos so documentados usando alguma combinao de
linguagem natural, modelos, tabelas e outros elementos. A linguagem natural quase
sempre imprescindvel, uma vez que a forma bsica de comunicao compreensvel
por todos os interessados. Contudo, ela geralmente abre espaos para ambiguidades e
m interpretao. Assim, interessante procurar estruturar o uso da linguagem natural e
complementar a descrio dos requisitos com outros elementos.
Neste texto, sugerimos elaborar dois documentos: o Documento de Definio de
Requisitos (ou somente Documento de Requisitos) e o Documento de Especificao
de Requisitos. O Documento de Requisitos mais sucinto, escrito em um nvel mais
apropriado para o cliente e contempla apenas os requisitos de usurio. O Documento de
Especificao de Requisitos mais detalhado, escrito a partir da perspectiva dos
desenvolvedores (PFLEEGER, 2004), normalmente contendo diversos modelos para
descrever requisitos de sistema.
Os requisitos de usurio devem ser descritos de modo a serem compreensveis
pelos interessados no sistema que no possuem conhecimento tcnico detalhado. Eles
devem especificar apenas o comportamento externo do sistema, em uma linguagem
nome da operao, parmetros e retorno.

_________________________________________________________________________________________________________
16
simples, direta e sem usar terminologia especfica de software (SOMMERVILLE,

2007).
5.3.1 O Documento de Requisitos
O Documento de Definio de Requisitos (ou simplesmente Documento de
Requisitos) tem como propsito descrever os requisitos de usurio, tendo como pblico
alvo clientes, usurios, gerentes (de cliente e de fornecedor) e desenvolvedores.
H muitos formatos distintos propostos na literatura para documentos de
requisitos. Neste texto, proposta uma estrutura bastante simples para esse tipo de
documento, contendo apenas quatro sees:
1. Introduo: breve introduo ao documento, descrevendo seu propsito e
estrutura.
2. Descrio do Propsito do Sistema: descreve o propsito geral do sistema.
3. Descrio do Minimundo: apresenta, em um texto corrido, uma viso geral
do domnio, do problema a ser resolvido e dos processos de negcio
apoiados, bem como as principais ideias do cliente sobre o sistema a ser
desenvolvido.
4. Requisitos de Usurio: apresenta os requisitos de usurio em linguagem
natural. Trs conjuntos de requisitos devem ser descritos nesta seo:
requisitos funcionais, requisitos no funcionais e regras de negcio.
As trs primeiras sees no tm nenhuma estrutura especial, sendo apresentadas
na forma de um texto corrido. A introduo deve ser breve e basicamente descrever o
propsito e a estrutura do documento, podendo seguir um padro preestabelecido pela
organizao. A descrio do propsito do sistema deve ser direta e objetiva, tipicamente
em um nico pargrafo. J a descrio do minimundo um pouco maior, algo entre uma
e duas pginas, descrevendo aspectos gerais e relevantes para um primeiro
entendimento do domnio, do problema a ser resolvido e dos processos de negcio
apoiados. Contm as principais ideias do cliente sobre o sistema a ser desenvolvido,
obtidas no levantamento preliminar e exploratrio do sistema. No se devem incluir
detalhes.
A seo 4, por sua vez, no deve ter um formato livre. Ao contrrio, deve seguir
um formato estabelecido pela organizao, contendo, dentre outros: identificador do
requisito, descrio, tipo, origem, prioridade, responsvel, interessados, dependncias
em relao a outros requisitos e requisitos conflitantes. A definio de padres
organizacionais para a definio de requisitos essencial para garantir uniformidade e
evitar omisso de informaes importantes acerca dos requisitos (SOMMERVILLE,
2007; WIEGERS, 2003). Como consequncia, o padro pode ser usado como um guia
para a verificao de requisitos. A Tabela 5.1 apresenta o padro tabular sugerido neste
texto. Sugerem-se agrupar requisitos de um mesmo tipo em diferentes tabelas. Assim, a
informao do tipo do requisito no aparece explicitamente no padro proposto. Alm
disso, informaes complementares podem ser adicionadas em funo do tipo de
requisito. A seguir, discute-se como cada um dos itens da tabela pode ser tratado,
segundo uma perspectiva geral. Na sequncia, so tecidas consideraes mais
especficas sobre a especificao dos diferentes tipos de requisitos.
_________________________________________________________________________________________________________
17
Tabela 5.1 Tabela de Requisitos.

Identificador
Descrio
Origem
Prioridade
Responsvel
Interessados
Dependncias
Conflitos
Os requisitos devem possuir identificadores nicos para permitir a identificao

e o rastreamento na gerncia de requisitos. H diversas propostas de esquemas de
rotulagem de requisitos. Neste texto, recomenda-se usar um esquema de numerao
sequencial por tipo de requisito, sendo usados os seguintes prefixos para designar os
diferentes tipos de requisitos: RF requisitos funcionais; RNF requisitos no
funcionais; RN regras de negcio. Para outros esquemas de rotulagem, vide
(WIEGERS, 2003). importante destacar que, quando um requisito eliminado, seu
identificador no pode ser atribudo a outro requisito.
A descrio do requisito normalmente feita na forma de uma sentena em
linguagem natural. Ainda que expressa em linguagem natural, importante adotar um
estilo consistente e usar a terminologia do usurio ao invs do jargo tpico da
computao. Em relao ao estilo, recomenda-se utilizar sentenas em um dos seguintes
formatos para descrever requisitos funcionais e no funcionais:
O sistema deve <verbo indicando ao, seguido de complemento>: use o

verbo dever para designar uma funo ou caracterstica requerida para o
sistema, ou seja, para descrever um requisito obrigatrio. Exemplos: O
sistema deve efetuar o controle dos clientes da empresa. O sistema deve
processar um pedido do cliente em um tempo inferior a cinco segundos,
contado a partir da entrada de dados.
O sistema pode <verbo indicando ao, seguido de complemento>: use o

verbo poder para designar uma funo ou caracterstica desejvel para o
sistema, ou seja, para descrever um requisito desejvel, mas no essencial.
Exemplos: O sistema pode notificar usurios em dbito. O sistema pode
sugerir outros produtos para compra, com base em produtos colocados no
carrinho de compras do usurio.
Em algumas situaes, pode-se querer explicitar que alguma funcionalidade ou

caracterstica no deve ser tratada pelo sistema. Neste caso, indica-se uma sentena com
a seguinte estrutura: O sistema no deve <verbo indicando ao, seguido de
complemento>.
Wiegers (2003) recomenda diversas diretrizes para a redao de requisitos,
dentre elas:
Escreva frases completas, com a gramtica, ortografia e pontuao correta.

Procure manter frases e pargrafos curtos e diretos.
Use os termos consistentemente. Defina-os em um glossrio.
Prefira a voz ativa (o sistema deve fazer alguma coisa) voz passiva (alguma
coisa deve ser feita).
Sempre que possvel, identifique o tipo de usurio. Evite descries

genricas como o usurio deve [...]. Se o usurio no caso for, por exemplo,
o caixa do banco, indique claramente o caixa do banco deve [...].
_________________________________________________________________________________________________________
18
Evite termos vagos, que conduzam a requisitos ambguos e no testveis, tais

como rpido, adequado, fcil de usar etc.
Escreva requisitos em um nvel consistente de detalhe.
O nvel de especificao de um requisito deve ser tal que, se o requisito

satisfeito, a necessidade do cliente atendida. Contudo, evite restringir
desnecessariamente o projeto (design).
Escreva requisitos individualmente testveis. Um requisito bem escrito deve

permitir a definio de um pequeno conjunto de testes para verificar se o
requisito foi corretamente implementado.
Evite longos pargrafos narrativos que contenham mltiplos requisitos.

Divida um requisito desta natureza em vrios menores.
Conforme apontado anteriormente, requisitos devem ser testveis. Robertson e

Robertson (2006) sugerem trs maneiras de tornar os requisitos testveis:
Especificar uma descrio quantitativa de cada advrbio ou adjetivo, de

modo que o significado dos qualificadores fique claro e no ambguo.
Trocar os pronomes pelos nomes das entidades.
Garantir que todo nome (termo) importante seja definido em um glossrio no

documento de requisitos.
A origem de um requisito deve apontar a partir de que entidade (pessoa,

documento, atividade) o requisito foi identificado. Um requisito identificado durante
uma investigao de documentos, p.ex., tem como origem o(s) documento(s)
inspecionado(s). J um requisito levantado em uma entrevista com um certo usurio tem
como origem o prprio usurio. A informao de origem importante para se conseguir
a rastrear requisitos para a sua origem, prtica muito recomendada no contexto da
gerncia de requisitos.
Requisitos podem ter importncia relativa diferente uns em relao aos outros.
Assim, importante que o cliente e outros interessados estabeleam conjuntamente a
prioridade de cada requisito.
muito importante saber quem o analista responsvel por um requisito, bem
como quem so os interessados (clientes, usurios etc.) naquele requisito. So eles que
estaro envolvidos nas discusses relativas ao requisito, incluindo a tentativa de acabar
com conflitos e a definio de prioridades. Assim, deve-se registrar o nome e o papel do
responsvel e dos interessados em cada requisito.
Um requisito pode depender de outros ou conflitar com outros. Quando as
dependncias e conflitos forem detectados, devem-se listar os respectivos
identificadores nas colunas de dependncias e conflitos.
Escrevendo Requisitos Funcionais
As diretrizes apresentadas anteriormente aplicam-se integralmente a requisitos
funcionais. Assim, no h outras diretrizes especficas para os requisitos funcionais.
Deve-se realar apenas que, quando expressos como requisitos de usurio, requisitos
funcionais so geralmente descritos de forma abstrata, no cabendo neste momento
_________________________________________________________________________________________________________
19
entrar em detalhes. Detalhes vo ser naturalmente adicionados quando esses mesmos

requisitos forem descritos na forma de requisitos de sistema.
Uma alternativa largamente empregada para especificar requisitos funcionais no
nvel de requisitos de sistema a modelagem. Uma das tcnicas mais comumente
utilizadas para descrever requisitos funcionais como requisitos de sistema a
modelagem de casos de uso.
Escrevendo Requisitos No Funcionais
Clientes e usurios naturalmente enfocam a especificao de requisitos
funcionais. Entretanto para um sistema ser bem sucedido, necessrio mais do que
entregar a funcionalidade correta. Usurios tambm tm expectativas sobre quo bem o
sistema vai funcionar. Caractersticas que entram nessas expectativas incluem: quo
fcil usar o sistema, quo rapidamente ele roda, com que frequncia ele falha e como
ele trata condies inesperadas. Essas caractersticas, coletivamente conhecidas como
atributos de qualidade do produto de software, so parte dos requisitos no funcionais
do sistema. Essas expectativas de qualidade do produto tm de ser exploradas durante o
levantamento de requisitos (WIEGERS, 2003).
Clientes geralmente no apontam suas expectativas de qualidade explicitamente.
Contudo, informaes providas por eles durante o levantamento de requisitos fornecem
algumas pistas sobre o que eles tm em mente. Assim, necessrio definir com preciso
o que os usurios pensam quando eles dizem que o sistema deve ser amigvel, rpido,
confivel ou robusto (WIEGERS, 2003).
H muitos atributos de qualidade que podem ser importantes para um sistema.
Uma boa estratgia para levantar requisitos no funcionais de produto consiste em
explorar uma lista de potenciais atributos de qualidade que a grande maioria dos
sistemas deve apresentar em algum nvel. Por exemplo, o modelo de qualidade externa e
interna de produtos de software definido na norma ISO/IEC 9126-1, utilizado como
referncia para a avaliao de produtos de software, define seis caractersticas de
qualidade, desdobradas em subcaractersticas, a saber (ISO/IEC, 2001):
Funcionalidade: refere-se existncia de um conjunto de funes que

satisfaz s necessidades explcitas e implcitas e suas propriedades
especficas. Tem como subcaractersticas: adequao, acurcia,
interoperabilidade, segurana de acesso e conformidade.
Confiabilidade: diz respeito capacidade do software manter seu nvel de

desempenho, sob condies estabelecidas, por um perodo de tempo. Tem
como subcaractersticas: maturidade, tolerncia a falhas, recuperabilidade e
conformidade.
Usabilidade: refere-se ao esforo necessrio para se utilizar um produto de

software, bem como o julgamento individual de tal uso por um conjunto de
usurios. Tem como subcaractersticas: inteligibilidade, apreensibilidade,
operacionalidade, atratividade e conformidade.
Eficincia: diz respeito ao relacionamento entre o nvel de desempenho do

software e a quantidade de recursos utilizados sob condies estabelecidas.
Tem como subcaractersticas: comportamento em relao ao tempo,
comportamento em relao aos recursos e conformidade.
_________________________________________________________________________________________________________


20
Manutenibilidade: concerne ao esforo necessrio para se fazer modificaes

no software. Tem como subcaractersticas: analisabilidade, modificabilidade,
estabilidade, testabilidade e conformidade.
Portabilidade: refere-se capacidade do software ser transferido de um

ambiente para outro. Tem como subcaractersticas: adaptabilidade,
capacidade para ser instalado, coexistncia, capacidade para substituir e
conformidade.
interessante observar que, mesmo dentre as subcaractersticas de

funcionalidade, h atributos que geralmente no so pensados pelos usurios como
funes que o sistema deve prover, tais como interoperabilidade e segurana de acesso.
Assim, importante avaliar em que grau o sistema em questo necessita apresentar tais
caractersticas.
Escrevendo Regras de Negcio
Toda organizao opera de acordo com um extenso conjunto de polticas
corporativas, leis, padres industriais e regulamentaes governamentais. Tais
princpios de controle so coletivamente designados por regras de negcio. Uma regra
de negcio uma declarao que define ou restringe algum aspecto do negcio, com o
propsito de estabelecer sua estrutura ou controlar ou influenciar o comportamento do
negcio (WIEGERS, 2003).
Sistemas de informao tipicamente precisam fazer cumprir as regras de
negcio. Ao contrrio dos requisitos funcionais e no funcionais, a maioria das regras
de negcio origina-se fora do contexto de um sistema especfico. Assim, as regras a
serem tratadas pelo sistema precisam ser identificadas, documentadas e associadas aos
requisitos do sistema em questo (WIEGERS, 2003).
Wiegers identifica cinco tipos principais de regras de negcio, cada um deles
apresentando uma forma tpica de ser escrito:
Fatos ou invariantes: declaraes que so verdade sobre o negcio.

Geralmente descrevem associaes ou relacionamentos entre importantes
termos do negcio. Ex.: Todo pedido tem uma taxa de remessa.
Restries: como o prprio nome indica, restringem as aes que o sistema

ou seus usurios podem realizar. Algumas palavras ou frases sugerem a
descrio de uma restrio, tais como deve, no deve, no pode e somente.
Ex.: Um aluno s pode tomar emprestado, concomitantemente, de um a trs
livros.
Ativadores de Aes: so regras que disparam alguma ao sob condies

especficas. Uma declarao na forma Se <alguma condio verdadeira ou
algum evento ocorre>, ento <algo acontece> indicada para descrever
ativadores de aes. Ex.: Se a data para retirada do livro ultrapassada e o
livro no retirado, ento a reserva cancelada. Quando as condies que
levam s aes so uma complexa combinao de mltiplas condies
individuais, ento o uso de tabelas de deciso ou rvores de deciso
indicado. As figuras 5.4 e 5.5 ilustram uma mesma regra de ativao de
aes descrita por meio de uma rvore de deciso e de uma tabela de
deciso, respectivamente.
_________________________________________________________________________________________________________

21
Tratamento
Prioritrio
Sem atraso de
pagamento
registrado
Volume de
negcios
R$ 1 milho
Tempo de
trabalho
20 anos
Com atraso
de pagamento
registrado
Prioritrio
Tempo de
trabalho <
20 anos
Volume de
negcios <
R$ 1 milho
Normal
Normal
Figura 5.4 Exemplo de rvore de Deciso.
Tratamento de Clientes
Volume de Negcios R$ 1 milho?
Atraso de pagamento registrado?
Tempo de trabalho 20 anos?
Tratamento Prioritrio
X
X
Tratamento Normal
Figura 5.5 Exemplo de Tabela de Deciso.
Inferncias: so regras que derivam novos fatos a partir de outros fatos ou

clculos. So normalmente escritas no padro se / ento, como as regras
ativadoras de ao, mas a clusula ento implica um fato ou nova informao
e no uma ao a ser tomada. Ex.: Se o usurio no devolve um livro dentro
do prazo estabelecido, ento ele torna-se um usurio inadimplente.
Computaes: so regras de negcio que definem clculos a serem

realizados usando algoritmos ou frmulas matemticas especficos. Podem
ser expressas como frmulas matemticas, descrio textual, tabelas, etc.
Ex.: Aplica-se um desconto progressivo se mais do que 10 unidades forem
adquiridas. De 10 a 19 unidades, o desconto de 10%. A compra de 20 ou
mais unidades tem um desconto de 25%. A Figura 5.6 mostra essa mesma
regra expressa no formato de uma tabela.
Nmero de Itens Adquiridos
Percentual de Desconto
1a9
10 a 19
10%
20 ou mais
25%
Figura 5.6 Exemplo de Regra de Clculo.

_________________________________________________________________________________________________________
22
Ao contrrio de requisitos funcionais e no funcionais, regras de negcio no so

passveis de serem capturadas por meio de perguntas simples e diretas, tal como Quais
so suas regras de negcio?. Regras de negcio emergem durante a discusso de
requisitos, sobretudo quando se procura entender a base lgica por detrs de requisitos e
restries apontados pelos interessados (WIEGERS, 2003). Assim, no se deve pensar
que ser possvel levantar muitas regras de negcio em um levantamento preliminar de
requisitos. Pelo contrrio, as regras de negcio vo surgir principalmente durante o
levantamento detalhado dos requisitos. Wiegers (2003) aponta diversas potenciais
origens para regras de negcio e sugere tipos de questes que o analista pode fazer para
tentar capturar regras advindas dessas origens:
Polticas: Por que necessrio fazer isso desse jeito?
Regulamentaes: O que o governo requer?
Frmulas: Como este valor calculado?
Modelos de Dados: Como essas entidades de dados esto relacionadas?
Ciclo de Vida de Objetos: O que causa uma mudana no estado desse

objeto?
Decises de Atores: O que o usurio pode fazer a seguir?
Decises de Sistema: Como o sistema sabe o que fazer a seguir?
Eventos: O que pode (e no pode) acontecer?
Regras de negcio normalmente tm estreita relao com requisitos funcionais.

Uma regra de negcio pode ser tratada no contexto de uma certa funcionalidade. Neste
caso, a regra de negcio deve ser listada na coluna de dependncias do requisito
funcional (vide Tabela 5.1). H casos em que uma regra de negcio conduz a um
requisito funcional para fazer cumprir a regra. Neste caso, a regra de negcio
considerada a origem do requisito funcional (WIEGERS, 2003).
importante destacar a importncia das regras (restries) obtidas a partir de
modelos de dados, ditas restries de integridade. Elas complementam as informaes
do modelo de dados e capturam restries entre elementos de um modelo de dados que
no so passveis de serem capturadas pelas notaes grficas utilizadas em modelos
desse tipo. Tais regras devem ser documentadas junto com os modelos de dados. Seja o
exemplo do modelo de dados da Figura 5.7. Esse fragmento de modelo indica que: (i)
um aluno cursa um curso; (ii) um aluno pode se matricular em nenhuma ou vrias
turmas; (iii) um curso possui um conjunto de disciplinas em sua matriz curricular; (iv)
uma turma de uma disciplina especfica. Contudo, nada diz sobre restries entre o
estabelecimento dessas vrias relaes. Suponha que o negcio indique que a seguinte
restrio deve ser considerada: Um aluno s pode ser matricular em turmas de
disciplinas que compem a grade curricular do curso que esse aluno cursa. Essa
restrio tem de ser escrita para complementar o modelo.
_________________________________________________________________________________________________________
23
Figura 5.7 Exemplo de Fragmento de Modelo de Dados com Restrio de

Integridade.
Outro tipo de restrio importante so as regras que impem restries sobre
funcionalidades de insero, atualizao ou excluso de dados, devido a
relacionamentos de existentes entre as entidades. Voltando ao exemplo da Figura 5.7, a
excluso de disciplinas no deve ser livre, uma vez que turmas so existencialmente
dependentes de disciplinas. Assim, a seguinte regra de integridade referencial de dados
deve ser considerada: Ao excluir uma disciplina, devem-se excluir todas as turmas a ela
relacionadas. Essas regras so denominadas neste texto como restries de
processamento e, uma vez que dizem respeito a funcionalidades, devem ser
documentadas junto com a descrio do caso de uso que detalha a respectiva
funcionalidade.
5.3.3 O Documento de Especificao de Requisitos
Os requisitos de sistema, assim como foi o caso dos requisitos de usurio, tm de
ser especificados em um documento, de modo a poderem ser verificados e validados e
posteriormente usados como base para as atividades subsequentes do desenvolvimento
de software. O Documento de Especificao de Requisitos tem como propsito registrar
os requisitos escritos a partir da perspectiva do desenvolvedor e, portanto, deve incluir
os vrios modelos conceituais desenvolvidos, bem como a especificao dos requisitos
no funcionais detalhados usando critrios de aceitao ou cenrios de atributos de
qualidade.
Diferentes formatos podem ser propostos para documentos de especificao
requisitos, bem como mais de um documento pode ser usado para documentar os
requisitos de sistema. Neste texto, prope-se o uso de um nico documento, contendo as
seguintes informaes:
1. Introduo: breve introduo ao documento, descrevendo seu propsito e
estrutura.
2. Modelo de Casos de Uso: apresenta o modelo de casos de uso do sistema,
incluindo os diagramas de casos de uso e as descries de casos de uso
associadas.
3. Modelo Estrutural: apresenta o modelo estrutural do sistema, incluindo os
diagramas de classes do sistema.
_________________________________________________________________________________________________________
24
4. Modelo Dinmico: apresenta os modelos comportamentais dinmicos do

sistema, incluindo os diagramas de estados, diagramas de interao e
diagramas de atividades3.
5. Dicionrio do Projeto: apresenta as definies dos principais conceitos
capturados pelos diversos modelos e restries de integridade a serem
consideradas, servindo como um glossrio do projeto.
6. Especificao dos Requisitos No Funcionais: apresenta os requisitos no
funcionais descritos no nvel de sistema, o que inclui critrios de aceitao e
cenrios de atributos de qualidade.
importante frisar que dificilmente um sistema simples o bastante para ser
modelado como um todo. Quase sempre til dividir um sistema em unidades menores,
mais fceis de serem gerenciveis, ditas subsistemas. til organizar a especificao de
requisitos por subsistemas e, portanto, cada uma das sees propostas acima pode ser
subdividida por subsistemas.
Um modelo estrutural para uma aplicao complexa, por exemplo, pode ter
centenas de classes e, portanto, pode ser necessrio definir uma representao concisa
capaz de orientar um leitor em um modelo dessa natureza. O agrupamento de elementos
de modelo em subsistemas serve basicamente a este propsito, podendo ser til tambm
para a organizao de grupos de trabalho em projetos extensos. A base principal para a
identificao de subsistemas a complexidade do domnio do problema. Atravs da
identificao e agrupamento de elementos de modelo em subsistemas, possvel
controlar a visibilidade do leitor e, assim, tornar os modelos mais compreensveis.
A UML (Unified Modeling Language)4 prov um tipo principal de item de
agrupamento, denominado pacote, que um mecanismo de propsito geral para a
organizao de elementos da modelagem em grupos. Um diagrama de pacotes mostra a
decomposio de um modelo em unidades menores e suas dependncias, como ilustra a
Figura 5.8. A linha pontilhada direcionada indica que o pacote origem (no exemplo, o
pacote Atendimento a Cliente) depende do pacote destino (no exemplo, o pacote
Controle de Acervo).
Figura 5.8 Exemplo de um Diagrama de Pacotes.

Nas prximas sees so realizadas as discusses necessrias para que sejam
elaborados os Modelos de Casos de Uso, os Modelos Estruturais e os Diagramas de
Estados (modelo dinmico).
Neste material, no que diz respeito modelagem dinmica, sero abordados apenas os diagramas de
estados.
4
A UML uma linguagem grfica padro para especificar, visualizar, documentar e construir artefatos
de sistemas de software (BOOCH; RUMBAUGH; JACOBSON, 2006). Tipicamente, a linguagem
utilizada na criao dos modelos gerados durante as etapas de especificao e anlise de requisitos e
projeto de sistema.
_________________________________________________________________________________________________________
25
5.4 Modelagem de Casos de Uso

Modelos de caso de uso (use cases) so modelos passveis de compreenso tanto
por desenvolvedores analistas, projetistas, programadores e testadores como pela
comunidade usuria clientes e usurios. Como o prprio nome sugere, um caso de uso
uma maneira de usar o sistema. Usurios interagem com o sistema, interagindo com
seus casos de uso. Tomados em conjunto, os casos de uso de um sistema representam a
sua funcionalidade. Casos de uso so, portanto, os itens que o desenvolvedor negocia
com seus clientes.
O propsito do modelo de casos de uso capturar e descrever a funcionalidade
que um sistema deve prover. Um sistema geralmente serve a vrios atores, para os quais
ele prov diferentes servios. Tipicamente, a funcionalidade a ser provida por um
sistema muito grande para ser analisada como uma nica unidade e, portanto,
importante ter um mecanismo de dividir essa funcionalidade em partes menores e mais
gerenciveis. O conceito de caso de uso muito til para esse propsito (OLIV, 2007).
importante ter em mente que casos de uso so fundamentalmente uma
ferramenta textual. Ainda que casos de uso sejam tambm descritos graficamente (p.ex.,
fluxogramas ou algum diagrama da UML, dentre eles diagramas de casos de uso,
diagramas de sequncia e diagramas de atividades), no se deve perder de vista a
natureza textual dos casos de uso. Olhando casos de uso apenas a partir da UML, que
no trata do contedo ou da escrita de casos de uso, pode-se pensar, equivocadamente,
que casos de uso so uma construo grfica ao invs de textual.
Em essncia, casos de uso servem como um meio de comunicao entre pessoas,
algumas delas sem nenhum treinamento especial e, portanto, o uso de texto para
especificar casos de uso geralmente a melhor escolha. Casos de uso so amplamente
usados no desenvolvimento de sistemas, porque, por meio sobretudo de suas descries
textuais, usurios e clientes conseguem visualizar qual a funcionalidade a ser provida
pelo sistema, conseguindo reagir mais rapidamente no sentido de refinar, alterar ou
rejeitar as funes previstas para o sistema (COCKBURN, 2005). Assim, um modelo de
casos de uso inclui duas partes principais: (i) os diagramas de casos de uso e (ii) as
descries de atores e de casos de uso, sendo que essas ltimas podem ser
complementadas com outros diagramas associados, tais como os diagramas de atividade
e de sequncia da UML.
Outro aspecto a ser realado que os modelos de caso de uso so independentes
do mtodo de anlise a ser usado e at mesmo do paradigma de desenvolvimento.
Assim, pode-se utilizar a modelagem de casos de uso tanto no contexto do
desenvolvimento orientado a objetos (foco deste texto), como em projetos
desenvolvidos segundo o paradigma estruturado. De fato, o uso de modelos de caso de
uso pode ser ainda mais amplo. Casos de uso podem ser usados, por exemplo, para
documentar processos de negcio de uma organizao. Contudo, neste texto, explora-se
a utilizao de casos de uso para modelar e documentar requisitos funcionais de
sistemas. Assim, geralmente so interessados5 (stakeholders) nos casos de uso: as
pessoas que usaro o sistema (usurios), o cliente que requer o sistema, outros sistemas
com os quais o sistema em questo ter de interagir e outros membros da organizao
(ou at mesmo de fora dela) que tm restries que o sistema precisa garantir.
Algum ou algo com interesse no comportamento do sistema sob discusso (COCKBURN, 2005).
_________________________________________________________________________________________________________


26
5.4.1 Atores
D-se nome de ator a um papel desempenhado por entidades fsicas (pessoas,
organizaes ou outros sistemas) que interagem com o sistema em questo da mesma
maneira, procurando atingir os mesmos objetivos. Uma mesma entidade fsica pode
desempenhar diferentes papis no mesmo sistema, bem como um dado papel pode ser
desempenhado por diferentes entidades (OLIV, 2007).
Atores so externos ao sistema. Um ator se comunica diretamente com o
sistema, mas no parte dele. A modelagem dos atores ajuda a definir as fronteiras do
sistema, isto , o conjunto de atores de um sistema delimita o ambiente externo desse
sistema, representando o conjunto completo de entidades para as quais o sistema pode
servir (BLAHA; RUMBAUGH, 2006; OLIV, 2007).
Uma dvida que sempre passa pela cabea de um iniciante em modelagem de
casos de uso saber se o ator a pessoa que efetivamente opera o sistema (p.ex., o
atendente de uma locadora de automveis) ou se a pessoa interessada no resultado do
processo (p.ex., o cliente que efetivamente loca o automvel e atendido pelo
atendente). Essa definio depende, em essncia, da fronteira estabelecida para o
sistema. Sistemas de informao podem ter diferentes nveis de automatizao. Por
exemplo, se um sistema roda na Internet, seu nvel de automatizao maior do que se
ele requer um operador. Assim, importante capturar qual o nvel de automatizao
requerido e levar em conta o real limite do sistema (WAZLAWICK, 2004). Se o caso de
uso roda na Internet (p.ex., um caso de uso de reserva de automvel), ento o cliente o
ator efetivamente. Se o caso de uso requer um operador (p.ex., um caso de uso de
locao de automvel, disponvel apenas na locadora e para ser usado por atendentes),
ento o operador o ator.
Quando se for considerar um sistema como sendo um ator, deve-se tomar o
cuidado para no confundir a ideia de sistema externo (ator) com produtos usados na
implementao do sistema em desenvolvimento. Para que um sistema possa ser
considerado um ator, ele deve ser um sistema de informao completo (e no apenas
uma biblioteca de classes, por exemplo). Alm disso, ele deve estar fora do escopo do
desenvolvimento do sistema atual. O analista no ter a oportunidade de alterar as
funes do sistema externo, devendo adequar a comunicao s caractersticas do
mesmo (WAZLAWICK, 2004).
Um ator primrio um ator que possui metas a serem cumpridas atravs do uso
de servios do sistema e que, tipicamente, inicia a interao com o sistema (OLIV,
2007). Um ator secundrio um ator externo que interage com o sistema para prover
um servio para este ltimo. A identificao de atores secundrios importante, uma
vez que ela permite identificar interfaces externas que o sistema usar e os protocolos
que regem as interaes ocorrendo atravs delas (COCKBURN, 2005).
De maneira geral, o ator primrio o usurio direto do sistema ou outro sistema
computacional que requisita um servio do sistema em desenvolvimento. O sistema
responde requisio procurando atend-la, ao mesmo tempo em que protege os
interesses de todos os demais interessados no caso de uso. Entretanto, h situaes em
que o iniciador do caso de uso no o ator primrio. O tempo, por exemplo, pode ser o
acionador de um caso de uso. Um caso de uso que roda todo dia meia noite ou ao final
do ms tem o tempo como acionador. Mas o caso de uso ainda visa atingir um objetivo
de um ator e esse ator considerado o ator primrio do caso de uso, ainda que ele no
interaja efetivamente com o sistema (COCKBURN, 2005).
_________________________________________________________________________________________________________
27
Para nomear atores, recomenda-se o uso de substantivos no singular, iniciados

com letra maiscula, possivelmente combinados com adjetivos. Exemplos: Cliente,
Bibliotecrio, Correntista, Correntista Titular etc.
5.4.2 Casos de Uso
Um caso de uso uma poro coerente da funcionalidade que um sistema pode
fornecer para atores interagindo com ele (BLAHA; RUMBAUGH, 2006). Um caso de
uso corresponde a um conjunto de aes realizadas pelo sistema (ou por meio da
interao com o sistema), que produz um resultado observvel, com valor para um ou
mais atores do sistema. Geralmente, esse valor a realizao de uma meta de negcio
ou tarefa (OLIV, 2007). Assim, um caso de uso captura alguma funo visvel ao ator
e, em especial, busca atingir uma meta desse ator.
Deve-se considerar que um caso de uso corresponde a uma transao completa,
ou seja, um usurio poderia ativar o sistema, executar o caso de uso e desativar o
sistema logo em seguida, e a operao estaria completa e consistente e atenderia a uma
meta desse usurio (WAZLAWICK, 2004).
Ser uma transao completa uma caracterstica essencial de um caso de uso 6,
pois somente transaes completas so capazes de atingir um objetivo do usurio. Casos
de uso que necessitam de mltiplas sees no passam nesse critrio e devem ser
divididos em casos de uso menores. Seja o exemplo de um caso de uso de concesso de
emprstimo. Inicialmente, um atendente interagindo com um cliente informa os dados
necessrios para a avaliao do pedido de emprstimo. O pedido de emprstimo ,
ento, enviado para anlise por um analista de crdito. Uma vez analisado e aprovado, o
emprstimo concedido, quando o dinheiro entregue ao cliente e um contrato
assinado, dentre outros. Esse processo pode levar vrios dias e no realizado em uma
seo nica. Assim, o caso de uso de concesso de emprstimo deveria ser subdividido
em casos de uso menores, tais como casos de uso para efetuar pedido de emprstimo,
analisar pedido de emprstimo e formalizar concesso de emprstimo.
Por outro lado, casos de uso muito pequenos, que no caracterizam uma
transao completa, devem ser considerados passos de um caso de uso maior 7. Seja o
exemplo de uma biblioteca a qual cobra multa na devoluo de livros em atraso. Um
caso de uso especfico para apenas calcular o valor da multa no relevante, pois no
caracteriza uma transao completa capaz de atingir um objetivo do usurio. O objetivo
do usurio efetuar a devoluo e, neste contexto, uma regra de negcio (a que
estabelece a multa) tem de ser levada em conta. Assim, calcular a multa apenas um
passo do caso de uso que efetua a devoluo, o qual captura uma ao do sistema para
garantir a regra de negcio e, portanto, satisfazer um interesse da biblioteca como
organizao.
Um caso de uso rene todo o comportamento relevante de uma parte da
funcionalidade do sistema. Isso inclui o comportamento principal normal, as variaes
de comportamento normais, as condies de exceo e o cancelamento de uma
requisio. O conjunto de casos de uso captura a funcionalidade completa do sistema
(BLAHA; RUMBAUGH, 2006).
6
Esta regra tem como exceo os casos de uso de incluso e extenso, conforme discutido mais adiante
na seo que trata de relacionamentos entre casos de uso.
7
As mesmas excees da nota anterior se aplicam aqui, conforme discutido mais adiante.
_________________________________________________________________________________________________________


28
Casos de uso fornecem uma abordagem para os desenvolvedores chegarem a

uma compreenso comum com os usurios finais e especialistas do domnio, acerca da
funcionalidade a ser provida pelo sistema (BOOCH; RUMBAUGH; JACOBSON,
2006).
Os objetivos dos atores so um bom ponto de partida para a identificao de
casos de uso. Pode-se propor um caso de uso para satisfazer cada um dos objetivos de
cada um dos atores. A partir desses objetivos, podem-se estudar as possveis interaes
do ator com o sistema e refinar o modelo de casos de uso.
Cada caso de uso tem um nome. Esse nome deve capturar a essncia do caso de
uso. Para nomear casos de uso sugere-se usar frases iniciadas com verbos no infinitivo,
seguidos de complementos, que representem a meta ou tarefa a ser realizada com o caso
de uso. As primeiras letras (exceto preposies) de cada palavra devem ser grafadas em
letra maiscula. Exemplos: Cadastrar Cliente, Devolver Livro, Efetuar Pagamento de
Fatura etc.
Um caso de uso pode ser visto como um tipo cujas instncias so cenrios. Um
cenrio uma execuo de um caso de uso com entidades fsicas particulares
desempenhando os papis dos atores e em um particular estado do domnio de
informao. Um cenrio, portanto, exercita um certo caminho dentro do conjunto de
aes de um caso de uso (OLIV, 2007).
Alguns cenrios mostram o objetivo do caso de uso sendo alcanado; outros
terminam com o caso de uso sendo abandonado (COCKBURN, 2005). Mesmo quando
o objetivo de um caso de uso alcanado, ele pode ser atingido seguindo diferentes
caminhos. Assim, um caso de uso deve comportar todas essas situaes. Para tal, um
caso de uso normalmente descrito por um conjunto de fluxos de eventos, capturando o
fluxo de eventos principal, i.e., o fluxo de eventos tpico que conduz ao objetivo do caso
de uso, e fluxos de eventos alternativos, descrevendo excees ou variantes do fluxo
principal.
5.4.3 - Diagramas de Casos de Uso
Basicamente, um diagrama de casos de uso mostra um conjunto de casos de uso
e atores e seus relacionamentos, sendo utilizado para ilustrar uma viso esttica das
maneiras possveis de se usar o sistema (BOOCH; RUMBAUGH; JACOBSON, 2006).
Os diagramas de casos de uso da UML podem conter os seguintes elementos de
modelo, ilustrados na Figura 5.9 (BOOCH; RUMBAUGH; JACOBSON, 2006):
Assunto: o assunto delimita a fronteira de um diagrama de casos de uso,

sendo normalmente o sistema ou um subsistema. Os casos de uso de um
assunto descrevem o comportamento completo do assunto. O assunto
exibido em um diagrama de casos de uso como um retngulo envolvendo os
casos de uso que o compem. O nome do assunto (sistema ou subsistema)
pode ser mostrado dentro do retngulo.
Ator: representa um conjunto coerente de papis que os usurios ou outros

sistemas desempenham quando interagem com os casos de uso. Tipicamente,
um ator representa um papel que um ser humano, um dispositivo de
hardware ou outro sistema desempenha com o sistema em questo. Atores
no so parte do sistema. Eles residem fora do sistema. Atores so
_________________________________________________________________________________________________________
29
representados por um cone de homem, com o nome colocado abaixo do

cone.
Caso de Uso: representa uma funcionalidade que o sistema deve prover.

Casos de uso so parte do sistema e, portanto, residem dentro dele. Um caso
de uso representado por uma elipse com o nome do caso de uso dentro ou
abaixo dela.
Relacionamentos de Dependncia, Generalizao e Associao: so usados

para estabelecer relacionamentos entre atores, entre atores e casos de uso, e
entre casos de uso.
Figura 5.9 - Diagrama de Casos de Uso Conceitos e Notao.

Atores s podem estar conectados a casos de uso por meio de associaes. Uma
associao entre um ator e um caso de uso significa que estmulos podem ser enviados
entre atores e casos de uso. A associao entre um ator e um caso de uso indica que o
ator e o caso de uso se comunicam entre si, cada um com a possibilidade de enviar e
receber mensagens (BOOCH; RUMBAUGH; JACOBSON, 2006).
Atores podem ser organizados em hierarquias de generalizao / especializao,
de modo a capturar que um ator filho herda o significado e as associaes com casos de
uso de seu pai, especializando esse significado e potencialmente adicionando outras
associaes como outros casos de uso.
A Figura 5.10 mostra um diagrama de casos de uso para um sistema de caixa
automtico. Nesse diagrama, o assunto o sistema como um todo. Os atores so: os
clientes do banco, o sistema bancrio e os responsveis pela manuteno do numerrio
no caixa eletrnico. Cliente e mantenedor so atores primrios, uma vez que tm
objetivos a serem atingidos pelo uso do sistema. O sistema bancrio um ator, pois o
sistema do caixa automtico precisa interagir com o sistema bancrio para realizar os
casos de uso Efetuar Saque, Emitir Extrato e Efetuar Pagamento.
_________________________________________________________________________________________________________
30
Figura 5.10 - Diagrama de Casos de Uso Caixa Automtico.

Um caso de uso descreve o que um sistema deve fazer. O diagrama de casos de
uso prov uma viso apenas parcial disso, uma vez que mostra as funcionalidades por
perspectiva externa. necessrio, ainda, capturar uma viso interna de cada caso de
uso, especificando o comportamento do caso de uso pela descrio do fluxo de eventos
que ocorre internamente (passos do caso de uso). Assim, uma parte fundamental do
modelo de casos de uso a descrio dos casos de uso.
5.4.4 - Descrevendo Casos de Uso
Um caso de uso deve descrever o que um sistema faz. Exceto para situaes
muito simples, um diagrama de casos de uso insuficiente para este propsito. Assim,
deve-se especificar o comportamento de um caso de uso pela descrio textual de seu
fluxo de eventos, de modo que outros interessados possam compreend-lo.
A especificao ou descrio de um caso de uso deve conter, dentre outras
informaes, um conjunto de sentenas, cada uma delas escrita em uma forma
gramatical designando um passo simples, de modo que aprender a ler um caso de uso
no requeira mais do que uns poucos minutos. Dependendo da situao, diferentes
estilos de escrita podem ser adotados (COCKBURN, 2005).
Cada passo do fluxo de eventos de um caso de uso tipicamente descreve uma das
seguintes situaes: (i) uma interao entre um ator e o sistema, (ii) uma ao que o
sistema realiza para atingir o objetivo do ator primrio ou (iii) uma ao que o sistema
realiza para proteger os interesses de um interessado. Essas aes podem incluir
validaes e mudanas do estado interno do sistema (COCKBURN, 2005).
No h um padro definido para especificar casos de uso. Diferentes autores
propem diferentes estruturas, formatos e contedos para descries de casos de uso,
alguns mais indicados para casos de uso essenciais e mais complexos, outros para casos
de uso cadastrais e mais simples. Mais alm, pode ser til utilizar mais de um formato
dentro do mesmo projeto, em funo das peculiaridades de cada caso de uso. De todo
_________________________________________________________________________________________________________
31
modo, recomendvel que a organizao defina modelos de descrio de casos de uso a

serem adotados em seus projetos, devendo definir tantos modelos quantos julgar
necessrios.
As seguintes informaes so um bom ponto de partida para a definio de um
modelo de descrio de casos de uso:
Nome: nome do caso de uso, capturando a sua essncia
Escopo: diz respeito ao que est sendo documentado pelo caso de uso.
Tipicamente pode ser um processo de negcio, um sistema ou um
subsistema. Vale lembrar que este texto no aborda a utilizao de casos de
uso para a modelagem de processos de negcio. Assim, o escopo vai apontar
o sistema / subsistema do qual o caso de uso faz parte.
Descrio do Propsito: uma descrio sucinta do caso de uso, na forma de

um nico pargrafo, procurando descrever o objetivo do caso de uso.
Ator Primrio: nome do ator primrio, ou seja, o interessado que tem um

objetivo em relao ao sistema, o qual pode ser atingido pela execuo do
caso de uso.
Interessados e Interesses: um interessado algum ou algo (um outro

sistema) que tem um interesse no comportamento do caso de uso sendo
descrito. Nesta seo so descritos cada um dos interessados no sistema e
qual o seu interesse no caso de uso, incluindo o ator primrio.
Pr-condies: o que deve ser verdadeiro antes da execuo do caso de uso.

Se as pr-condies no forem satisfeitas, o caso de uso no pode ser
realizado.
Ps-condies: o que deve ser verdadeiro aps a execuo do caso de uso,

considerando que o fluxo de eventos normal realizado com sucesso.
Fluxo de Eventos Normal: descreve os passos do caso de uso realizados em

situaes normais, considerando que nada acontece de errado e levando em
conta a maneira mais comum do caso de uso ser realizado.
Fluxo de Eventos Alternativos: descreve formas alternativas de realizar

certos passos do caso de uso. H duas formas alternativas principais: fluxos
variantes, que so considerados dentro da normalidade do caso de uso; e
fluxos de exceo, que se referem ao tratamento de erros durante a execuo
de um passo do fluxo normal (ou de um fluxo variante ou at mesmo de um
outro fluxo de exceo).
Requisitos Relacionados: listagem dos identificadores dos requisitos

(funcionais, no funcionais e regras de negcio) tratados pelo caso de uso
sendo descrito, de modo a permitir rastrear os requisitos. Casos de uso
podem ser usados para conectar vrios requisitos, de tipos diferentes. Assim,
essa listagem ajuda a manter um rastro entre requisitos funcionais, no
funcionais e regras de negcio, alm de permitir verificar se algum requisito
deixou de ser tratado.
Classes / Entidades: classes (no paradigma orientado a objetos) ou entidades

(no paradigma estruturado) necessrias para tratar o caso de uso sendo
descrito. Esta seo normalmente preenchida durante a modelagem
_________________________________________________________________________________________________________


32
conceitual estrutural e igualmente importante para permitir rastrear

requisitos para as etapas subsequentes do desenvolvimento (projeto e
implementao, sobretudo).
5.4.5 Descrevendo os Fluxos de Eventos
Uma vez que o conjunto inicial de casos de uso estiver estabilizado, cada um
deles deve ser descrito em mais detalhes. Primeiro, deve-se descrever o fluxo de eventos
principal (ou curso bsico), isto , o curso de eventos mais importante, que
normalmente ocorre. O fluxo de eventos normal (ou principal) uma informao
essencial na descrio de um caso de uso e no pode ser omitido em nenhuma
circunstncia. O fluxo de eventos normal , portanto, a principal seo de uma descrio
de caso de uso, a qual descreve o processo quando tudo d certo, ou seja, sem a
ocorrncia de nenhuma exceo (WAZLAWICK, 2004).
Variantes do curso bsico de eventos e tratamento de excees que possam vir a
ocorrer devem ser descritos em cursos alternativos. Normalmente, um caso de uso
possui apenas um nico curso bsico, mas diversos cursos alternativos. Seja o exemplo
de um sistema de caixa automtico de banco, cujo diagrama de casos de uso mostrado
na Figura 5.10. O caso de uso Efetuar Saque poderia ser descrito como mostrado na
Figura 5.11.
Como visto nesse exemplo, um caso de uso pode ter um nmero de cursos
alternativos que podem levar o caso de uso por diferentes caminhos. Tanto quanto
possvel, esses cursos alternativos, muitos deles cursos de exceo, devem ser
identificados durante a especificao do fluxo de eventos normal de um caso do uso.
Vale realar que uma exceo no necessariamente um evento que ocorre
muito raramente, mas sim um evento capaz de impedir o prosseguimento do caso de
uso, se no for devidamente tratado. Uma exceo tambm no algo que impede o
caso de uso de ser iniciado, mas algo que impede a sua concluso. Condies que
impedem um caso de uso de ser iniciado devem ser tratadas como pr-condies. As
pr-condies nunca devem ser testadas durante o processo do caso de uso, pois, por
definio, elas impedem que o caso de uso seja iniciado. Logo, seria inconsistente
imaginar que elas pudessem ocorrer durante a execuo do caso de uso. Se uma prcondio falsa, ento o caso de uso no pode ser iniciado (WAZLAWICK, 2004).
Observa-se que a maioria das excees ocorre nos passos em que alguma
informao passada dos atores para o sistema. Isso porque, quando uma informao
passada para o sistema, muitas vezes ele realiza validaes. Quando uma dessas
validaes falha, tipicamente ocorre uma exceo (WAZLAWICK, 2004).
_________________________________________________________________________________________________________
33
Nome: Efetuar Saque

Escopo: Sistema de Caixa Automtico
Descrio do Propsito: Este caso de uso permite que um cliente do banco efetue um
saque, retirando dinheiro de sua conta bancria.
Ator Primrio: Cliente
Interessados e Interesses:
Cliente: deseja efetuar um saque.
Banco: garantir que apenas o prprio cliente efetuar saques e que os valores dos
saques sejam compatveis com o limite de crdito do cliente.
Pr-condies: O caixa automtico deve estar conectado ao sistema bancrio.
Ps-condies: O saque efetuado, debitando o valor da conta do cliente e entregando
o mesmo valor para o cliente em espcie.
Fluxo de Eventos Normal
O cliente insere seu carto no caixa automtico, que analisa o carto e verifica se
ele aceitvel. Se o carto aceitvel, o caixa automtico solicita que o cliente informe
a senha. O cliente informa a senha. O caixa automtico envia os dados do carto e da
senha para o sistema bancrio para validao. Se a senha estiver correta, o caixa solicita
que o cliente informe o tipo de transao a ser efetuada. O cliente seleciona a opo
saque e o caixa solicita que seja informada a quantia. O cliente informa a quantia a ser
sacada. O caixa envia uma requisio para o sistema bancrio para que seja efetuado um
saque na quantia especificada. Se o saque autorizado, as notas so preparadas e
liberadas.
Fluxos de Eventos de Exceo
O carto no aceitvel: Se o carto no aceitvel, seja porque sua tarja
magntica no passvel de leitura seja porque de um tipo incompatvel, uma
mensagem de erro de leitura mostrada.
Senha incorreta: Se a senha informada est incorreta, uma mensagem mostrada
para o cliente que poder entrar com a senha novamente. Caso o cliente informe
trs vezes senha incorreta, o carto dever ser bloqueado.
Saque no autorizado: Se o saque no for aceito pelo sistema bancrio, uma
mensagem de erro exibida e a operao abortada.
No h dinheiro suficiente disponvel no caixa eletrnico: Uma mensagem de
erro exibida e a operao abortada.
Cancelamento: O cliente pode cancelar a transao a qualquer momento,
enquanto o saque no for autorizado pelo sistema bancrio.
Requisitos Relacionados: RF01, RN01, RNF01, RNF028
Classes: Cliente, Conta, Carto, Transao, Saque.
Figura 5.11 Descrio do Caso de Uso Efetuar Saque.
8
So as seguintes as descries dos requisitos listados: RF01 O sistema de caixa automtico deve
permitir que clientes efetuem saques em dinheiro; RN01 No devem ser permitidas transaes que
deixem a conta do cliente com saldo inferior ao de seu limite de crdito; RNF01 O sistema de caixa
automtico deve estar integrado ao sistema bancrio; RNF02 As operaes realizadas no caixa
automtico devem dar respostas em at 10s a partir da entrada de dados.
_________________________________________________________________________________________________________


34
Em sistemas de mdio a grande porte, pode ser til considerar a fuso de casos
de uso fortemente relacionados em um nico caso de uso, contendo mais de um fluxo de
eventos normal. Em muitos sistemas necessrio dar ao usurio a possibilidade de
cancelar ou alterar dados de uma transao efetuada anteriormente com sucesso. Se
cada uma dessas possibilidades for considerada como um caso de uso isolado, o nmero
de casos de uso pode crescer demasiadamente, aumentando desnecessariamente a
complexidade do modelo de casos de uso. Alm disso, o fluxo de eventos normal de um
caso de uso desse tipo tende a ser muito simples, no justificando documentar todo um
conjunto de informaes para adicionar apenas duas ou trs linhas descrevendo os
passos do caso de uso. Assim, em situaes dessa natureza, interessante considerar
apenas um caso de uso, contendo diversos fluxos de eventos principais. Essa abordagem
bastante recomendada para casos de uso cadastrais, em que um nico caso de uso
inclui fluxos de eventos normais para criar, alterar, consultar e excluir entidades.
Fluxos de eventos normais podem ser descritos de diferentes maneiras,
dependendo do nvel de formalidade que se deseja para as descries. Dentre os
formatos possveis, h dois principais:
Livre: o fluxo de eventos normal escrito na forma de um texto corrido,

como no exemplo da Figura 5.11.
Enumerado: cada passo do fluxo de eventos normal numerado, de modo

que possa ser referenciado nos fluxos de eventos alternativos ou em outros
pontos do fluxo de eventos normal. A Figura 5.12 reapresenta o exemplo da
Figura 5.11 neste formato. As sees iniciais foram omitidas por serem
iguais s da Figura 5.11. Neste texto, advogamos em favor do uso do
formato enumerado.
Cada exceo deve ser tratada por um fluxo alternativo de exceo. Fluxos
alternativos de exceo devem ser descritos contendo as seguintes informaes
(WAZLAWICK, 2004): um identificador, uma descrio sucinta da exceo que
ocorreu, os passos para tratar a exceo (aes corretivas) e uma indicao de como o
caso de uso retorna ao fluxo principal (se for o caso) aps a execuo das aes
corretivas.
Quando um formato de descrio enumerado utilizado, no necessrio
colocar uma verificao como uma condicional no fluxo principal. Por exemplo, no
caso da Figura 5.12, o passo 3 no deve ser escrito como 3. Se o carto vlido, o
caixa automtico solicita que o cliente informe a senha.. Basta o fluxo alternativo, no
exemplo, o fluxo 2a.
Ainda quando o formato de descrio enumerado utilizado, o identificador da
exceo deve conter a linha do fluxo de eventos principal (ou eventualmente de algum
outro fluxo de eventos alternativo) no qual a exceo ocorreu e uma letra para
identificar a prpria exceo (WAZLAWICK, 2004), como ilustra o exemplo da Figura
5.12.
Uma informao que precisa estar presente na descrio de um fluxo de eventos
de exceo diz respeito a como finalizar o tratamento de uma exceo. Wazlawick
(2004) aponta quatro formas bsicas para finalizar o tratamento de uma exceo:
_________________________________________________________________________________________________________
35
Voltar ao incio do caso de uso, o que no muito comum nem prtico.
Voltar ao incio do passo em que ocorreu a exceo e execut-lo novamente.

Esta a situao mais comum.
Voltar para algum um passo posterior. Esta situao ocorre quando as aes
corretivas realizam o trabalho que o passo (ou a sequncia de passos)
posterior deveria executar. Neste caso, importante verificar se novas
excees no poderiam ocorrer.
Abortar o caso de uso. Neste caso, no se retorna ao fluxo principal e o caso

de uso no atinge seus objetivos.
Nome: Efetuar Saque

1.
2.
3.
4.
5.
O cliente insere seu carto no caixa automtico.

O caixa automtico analisa o carto e verifica se ele aceitvel.
O caixa automtico solicita que o cliente informe a senha.
O cliente informa a senha.
O caixa automtico envia os dados do carto e da senha para o sistema
bancrio para validao.
6. O caixa automtico solicita que o cliente informe o tipo de transao a ser
efetuada.
7. O cliente seleciona a opo saque.
8. O caixa automtico solicita que seja informada a quantia.
9. O cliente informa a quantia a ser sacada.
10. O caixa automtico envia uma requisio para o sistema bancrio para que
seja efetuado um saque na quantia especificada.
11. As notas so preparadas e liberadas.
2a O carto no aceitvel: Se o carto no aceitvel, seja porque sua tarja
magntica no passvel de leitura seja porque de um tipo incompatvel,
uma mensagem de erro de leitura mostrada e se retorna ao passo 1.
5a Senha incorreta:
5a.1 1 e 2 tentativas: Uma mensagem de erro mostrada para o cliente.
Retornar ao passo 3.
5a.2 3 tentativa: bloquear o carto e abortar a transao.
10a - Saque no autorizado: Uma mensagem de erro exibida e a operao
abortada.
11a - No h dinheiro suficiente disponvel no caixa eletrnico: Uma mensagem
de erro exibida e a operao abortada.
1 a 9: Cancelamento: O cliente pode cancelar a transao, enquanto o saque no
for autorizado pelo sistema bancrio. A transao abortada.
Figura 5.12 Descrio do Caso de Uso Efetuar Saque Formato Enumerado.
Alm dos fluxos de exceo, h outro tipo de fluxo de eventos alternativo: os
fluxos variantes. Fluxos variantes so considerados dentro da normalidade do caso de
_________________________________________________________________________________________________________
36
uso e indicam formas diferentes, mas igualmente normais, de se realizar uma certa
poro de um caso de uso. Seja o caso de um sistema de um supermercado, mais
especificamente um caso de uso para efetuar uma compra. Um passo importante desse
caso de uso a realizao do pagamento, o qual pode se dar de trs maneiras distintas:
pagamento em dinheiro, pagamento em cheque, pagamento em carto. Nenhuma dessas
formas de pagamento constitui uma exceo. So todas maneiras diferentes, mas
normais, de realizar um certo passo do caso de uso e, portanto, pode-se dizer que o
fluxo principal possui trs variaes. A descrio de um fluxo variante deve conter: um
identificador, uma descrio sucinta do passo especializado e os passos enumerados,
como ilustra a Figura 5.13.
Nome: Efetuar Compra
...
1. De posse do valor a ser pago, o atendente informa a forma de pagamento.
2. Efetuar o pagamento:
2a. Em dinheiro
2b. Em cheque
2c. Em carto
3. O pagamento registrado.
Fluxos de Eventos Variantes
2a Pagamento em Dinheiro:
2a.1 O atendente informa a quantia em dinheiro entregue pelo cliente.
2a.2 O sistema informa o valor do troco a ser dado ao cliente.
2b Pagamento em Cheque:
2b.1 O atendente informa os dados do cheque, a saber: banco, agncia, conta e
valor.
2c Pagamento em Carto:
2c.1 O atendente informa os dados do carto e o valor da compra.
2.c.2 O sistema envia os dados informados no passo anterior, junto com a
identificao da loja para o servio de autorizao do Sistema de Operadoras de
Carto de Crdito.
2c.3 O Sistema de Operadoras de Carto de Crdito autoriza a compra e envia o
cdigo da autorizao.
Figura 5.13 Descrio Parcial do Caso de Uso Efetuar Compra com Variantes.
Por fim, em diversas situaes, pode ser desnecessariamente trabalhoso
especificar casos de uso segundo um formato completo, seja usando uma descrio dos
fluxos de eventos no formato livre seja no formato enumerado. Para esses casos, um
formato simplificado, na forma de uma tabela, pode ser usado. O formato tabular
normalmente empregado para casos de uso que possuem uma estrutura de interao
simples, seguindo uma mesma estrutura geral, tais como casos de uso cadastrais (ou
_________________________________________________________________________________________________________
37
CRUD9) e consultas. Casos de uso cadastrais de baixa complexidade tipicamente

envolvem incluso, alterao, consulta e excluso de entidades e seguem o padro de
descrio mostrado na Figura 5.14.
Fluxos de Eventos Normais
Criar [Novo Objeto]
O [ator] informa os dados do [novo objeto], a saber: [atributos e associaes do
objeto]. Caso os dados sejam vlidos, as informaes so registradas.
Alterar Dados
O [ator] informa o [objeto] do qual deseja alterar dados e os novos dados. Os novos
dados so validados e a alterao registrada.
Consultar Dados
O [ator] informa o [objeto] que deseja consultar. Os dados do [objeto] so
apresentados.
Excluir [Objeto]
O [ator] informa o [objeto] que deseja excluir. Os dados do [objeto] so apresentados
e solicitada uma confirmao. Se a excluso for confirmada, o [objeto] excludo.
Incluir [Novo Objeto] / Alterar Dados
Dados do [objeto] invlidos: uma mensagem de erro exibida, solicitando correo
da informao invlida.
Figura 5.14 Padro Tpico de Descrio de Casos de Uso Cadastrais.
Assim, para simplificar a descrio de casos de uso cadastrais, recomenda-se
utilizar o modelo tabular mostrado na Tabela 5.2. Quando essa tabela for empregada,
estar-se- assumindo que o caso de uso envolve os fluxos de eventos indicados (I para
incluso, A para alterao, C para consulta e E para excluso), com a descrio base
mostrada na Figura 5.14.
Tabela 5.2 Modelo de Descrio de Casos de Uso Cadastrais
Caso de Uso
Aes Possveis
Observaes Requisitos
<nome do caso de uso>
< I, A, C, E >
Classes
A coluna Observaes usada para listar informaes importantes relacionadas

s aes, tais como os itens informados na incluso, uma restrio a ser considerada
para que a excluso possa ser feita, uma informao que no pode ser alterada ou uma
informao do objeto que no apresentada na consulta. Deve-se indicar antes da
CRUD do ingls: Create, Read, Update and Delete; em portugus: Criar, Consultar, Atualizar e
Excluir, ou seja, casos de uso que proveem as funes bsicas de manipulao de dados de uma entidade
de interesse do sistema.
_________________________________________________________________________________________________________

38
observao a qual ao ela se refere ([I] para incluso, [A] para alterao, [C] para
consulta e [E] para excluso).
As colunas Requisitos e Classes indicam, respectivamente, os requisitos que
esto sendo (ou que devem ser) tratados pelo caso de uso e as classes do domnio do
problema necessrias para a realizao do caso de uso. O objetivo dessas colunas
manter a rastreabilidade dos casos de uso para requisitos e classes, respectivamente, de
maneira anloga ao recomendado no formato completo.
A Tabela 5.3 ilustra a descrio de casos de usos cadastrais do subsistema
Controle de Acervo de uma videolocadora.
Tabela 5.3 Descrio de Casos de Uso Cadastrais Controle de Acervo de
Videolocadora
Caso de Uso
Cadastrar
Filme
Aes
Possveis
I, A, C, E
Cadastrar Item
I, A, C, E
Cadastrar
Distribuidora
I, A, C, E
Cadastrar Tipo
de Mdia
I, A, C, E
Observaes
Requisitos
Classes
[I] Informar: ttulo original, ttulo em

portugus, pas, ano, diretores, atores,
sinopse,
durao,
gnero,
distribuidora, tipo de udio (p.ex.,
Dolby Digital 2.0), idioma do udio e
idioma da legenda.
[E] No permitida a excluso de
filmes que tenham itens associados.
[E] Ao excluir um filme, devem-se
excluir as reservas associadas.
[I] Informar: filme, tipo de mdia,
data de aquisio e nmero de srie.
[E] No permitido excluir um item
que tenha locaes associadas.
[I] Informar: razo social, CNPJ,
endereo, telefone e pessoa de
contato.
[E] No permitido excluir uma
distribuidora que tenha filmes
associados.
[I] Informar: nome e valor de locao.
[E] No permitido excluir um tipo
de mdia que tenha itens associados.
[E] Ao excluir um tipo de mdia,
devem-se excluir as reservas que
especificam apenas esse tipo de
mdia.
RF9, RNF1
Filme,
Distribuidora
RF9,
RNF1,
RNF3
Item,
Filme,
TipoMidia
RF10,
RNF1
Distribuidora
RF9, RNF1
TipoMidia
Para casos de uso de consulta mais abrangente do que a consulta de um nico

objeto (j tratada como parte dos casos de uso cadastrais), mas ainda de baixa
complexidade (tais como consultas que combinam informaes de vrios objetos
envolvendo filtros), sugere-se utilizar o formato tabular mostrado na Tabela 5.4.
Tabela 5.4 Modelo de Descrio de Casos de Uso de Consulta
Caso de Uso
Observaes Requisitos Classes
<nome do caso de uso>
_________________________________________________________________________________________________________
39
A coluna Observaes deve ser usada para listar informaes importantes

relacionadas consulta, tais como dados que podem ser informados para a pesquisa,
totalizaes feitas em relatrios etc.
As colunas Requisitos e Classes tm a mesma funo de suas homnimas no
modelo da Tabela 5.2, ou seja, indicam, respectivamente, os requisitos que esto sendo
tratados (ou que devem ser) pelo caso de uso e as classes do domnio do problema
necessrias para a realizao do mesmo.
A Tabela 5.5 ilustra a descrio de um caso de usos de consulta do subsistema
Controle de Acervo de uma videolocadora.
Tabela 5.5 Descrio de Casos de Uso de Consulta Controle de Acervo de
Videolocadora
Caso de Uso
Consultar Acervo
Observaes
As consultas ao acervo podero ser
feitas informando uma (ou uma
combinao)
das
seguintes
informaes: ttulo (ou parte dele),
original ou em portugus, gnero, tipo
de mdia disponvel, ator, diretor,
nacionalidade e lanamentos.
Requisitos
Classes
RF11, RNF1, Filme, Item,
RNF2
TipoMidia,
Distribuidora
5.4.6 Descrevendo Informaes Complementares

As descries dos fluxos de eventos principal, variantes e de exceo so
cruciais em uma descrio de casos de uso. Contudo, h outras informaes
complementares que so bastante teis e, portanto, que devem ser levantadas e
documentadas como, por exemplo: pr-condies, ps-condies, requisitos
relacionados e classes relacionadas.
Pr-condies estabelecem o que precisa ser verdadeiro antes de se iniciar um
caso de uso. Ps-condies, por sua vez, estabelecem o que ser verdadeiro aps a
execuo do caso de uso. Pr-condies precisam ser verdadeiras para que o caso de uso
possa ser iniciado. No se deve confundi-las com excees. Pr-condies no so
testadas durante a execuo do caso de uso (como ocorre com as condies que geram
excees). Ao contrrio, elas so testadas antes de iniciar o caso de uso. Se a prcondio falsa, ento no possvel executar o caso de uso. Para documentar as prcondies, recomenda-se listar as condies que tm de ser satisfeitas na seo Prcondies. Pr-condies devem ser escritas como uma simples assero sobre o
estado do mundo no momento em que o caso de uso inicia (COCKBURN, 2005).
Muitas vezes, uma pr-condio para ser atendida requer que um outro caso de
uso j executado tenha estabelecido essa pr-condio. Contudo, um erro bastante
comum escrever como uma pr-condio algo que frequentemente, mas no
necessariamente, verdadeiro (COCKBURN, 2005). Seja o caso de uma locadora de
vdeos em que clientes em atraso no podem locar novos itens at que regularize suas
pendncias. Neste caso, uma pr-condio do tipo cliente no est em atraso como
pr-condio de um caso de uso efetuar locao inadequada. Observe que a
identificao do cliente parte do caso de uso efetuar locao e, portanto, no possvel
garantir que o cliente no est em atraso antes de iniciar o caso de uso. Esta situao
tem de ser tratada como uma exceo e no como uma pr-condio.
_________________________________________________________________________________________________________
40
As sees de requisitos e classes relacionados so importantes para a gerncia de

requisitos. A primeira estabelece um rastro entre casos de uso e os requisitos de usurio
documentados no Documento de Requisitos, permitindo, em um primeiro momento,
analisar se algum requisito no foi tratado. Em um segundo momento, quando uma
alterao em um requisito solicitada, possvel usar essa informao para analisar o
impacto da alterao. Para documentar os requisitos relacionados, recomenda-se listar
os identificadores de cada um dos requisitos na seo de Requisitos Relacionados.
A seo de classes relacionadas indica quais so as classes do modelo conceitual
estrutural necessrias para a realizao do caso de uso. Essa seo permite rastrear casos
de uso para classes em vrios nveis, uma vez que h uma grande tendncia de as
mesmas classes do modelo conceitual estrutural estarem presentes nos modelos de
projeto e no cdigo fonte. Para documentar as classes relacionadas, recomenda-se listar
o nome de cada uma das classes envolvidas na seo de Classes Relacionadas. Vale
ressaltar que essa informao tipicamente preenchida durante a modelagem conceitual
estrutural ou at mesmo depois, durante a elaborao de modelos de interao. A partir
das informaes de requisitos e classes relacionados, pode-se, por exemplo, construir
matrizes de rastreabilidade.
5.4.7 - Relacionamentos entre Casos de Uso
Para permitir uma modelagem mais apurada dos casos de uso em um diagrama,
trs tipos de relacionamentos entre casos de uso podem ser empregados. Casos de uso
podem ser descritos como verses especializadas de outros casos de uso
(relacionamento de generalizao/ especializao); casos de uso podem ser includos
como parte de outro caso de uso (relacionamento de incluso); ou casos de uso podem
estender o comportamento de um outro caso de uso (relacionamento de extenso). O
objetivo desses relacionamentos tornar um modelo mais compreensvel, evitar
redundncias entre casos de uso e permitir descrever casos de uso em camadas. A seguir
esses tipos de relacionamentos so abordados.
Incluso
Uma associao de incluso de um caso de uso base para um caso de uso de
incluso significa que o comportamento definido no caso de uso de incluso
incorporado ao comportamento do caso de uso base. Ou seja, a relao de incluso
incorpora um caso de uso (o caso de uso includo) dentro da sequncia de
comportamento de outro caso de uso (o caso de uso base) (BLAHA; RUMBAUGH,
2006; OLIV, 2007).
Esse tipo de associao til para extrair comportamento comum a vrios casos
de uso em uma nica descrio, de modo que esse comportamento no tenha de ser
descrito repetidamente. O caso de uso de incluso pode ou no ser passvel de utilizao
isoladamente. Assim, ele pode ser apenas um fragmento de uma funcionalidade, no
precisando ser uma transao completa. A parte comum includa por todos os casos de
uso base que tm esse caso de uso de incluso em comum e a execuo do caso de uso
de incluso anloga a uma chamada de subrotina (OLIV, 2007).
Na UML, o relacionamento de incluso entre casos de uso mostrado como uma
dependncia (seta pontilhada) estereotipada com a palavra-chave include, partindo do
caso de uso base para o caso de uso de incluso, como ilustra a Figura 5.15.
_________________________________________________________________________________________________________
41
Figura 5.15 Associao de Incluso na UML

Uma associao de incluso deve ser referenciada tambm na descrio do caso
de uso base. O local em que esse comportamento includo deve ser indicado na
descrio do caso de uso base, atravs de uma referncia explcita chamada ao caso de
uso includo. Assim, a descrio do fluxo de eventos (principal ou alternativo) do caso
de uso base deve conter um passo que envolva a chamada ao caso de uso includo,
referenciada por Incluir nome do caso de uso includo. Para destacar referncias de
um caso de uso para outro, sugere-se que o nome do caso de uso referenciado seja
sublinhado e escrito em itlico.
No exemplo do caixa automtico, todos os trs casos de uso tm em comum uma
poro que diz respeito validao inicial do carto. Neste caso, um relacionamento de
incluso deve ser empregado, conforme mostra a Figura 5.16.
Figura 5.16 - Diagrama de Casos de Uso Caixa Automtico com Incluso.

O caso de uso Validar Carto extrai o comportamento descrito na Figura 5.17.
Ao isolar este comportamento no caso de uso de Validar Cliente, o caso de uso Efetuar
Saque passaria a apresentar a descrio mostrada na Figura 5.18.
Deve-se observar que no necessariamente o comportamento do caso de uso
includo precisa ser executado todas as vezes que o caso de uso base realizado. Assim,
possvel que a incluso esteja associada a alguma condio. O caso de uso includo
inserido em um local especfico dentro da sequncia do caso de uso base, da mesma
forma que uma subrotina chamada de um local especfico dentro de outra subrotina
(BLAHA; RUMBAUGH, 2006).
_________________________________________________________________________________________________________
42
Nome: Validar Carto

1.
2.
3.
4.
5.
O cliente insere o carto no caixa automtico.

O caixa automtico analisa o carto e verifica se ele aceitvel.
O caixa automtico solicita que o cliente informe a senha.
O cliente informa a senha.
O caixa automtico envia os dados do carto e da senha para o sistema
efetuada.
5a Senha incorreta:
1 a 5: Cancelamento: O cliente solicita o cancelamento da transao e a
transao abortada.
Figura 5.17 Descrio do Caso de Uso Validar Carto
Nome: Efetuar Saque
1.
2.
3.
4.
5.
Incluir Validar Carto.

O cliente seleciona a opo saque.
O caixa automtico solicita que seja informada a quantia.
O cliente informa a quantia a ser sacada.
O caixa automtico envia uma requisio para o sistema bancrio para que
6. As notas so preparadas e liberadas.
abortada.
Figura 5.18 Descrio do Caso de Uso Efetuar Saque com incluso.
Por fim, importante frisar que no h um consenso sobre a possibilidade (ou
no) de um caso de uso includo poder ser utilizado isoladamente. Diversos autores,
dentre eles Oliv (2007) e Blaha e Rumbaugh (2006), admitem essa possibilidade;
_________________________________________________________________________________________________________
43
outros no. Em (BOOCH; RUMBAUGH; JACOBSON, 2006), diz-se explicitamente

que um caso de uso includo nunca permanece isolado, mas apenas instanciado como
parte de alguma base maior que o inclui. Neste texto, admitimos a possibilidade de um
caso de uso includo poder ser utilizado isoladamente, pois isso permite representar
situaes em que um caso de uso chama outro caso de uso (como uma chamada de
subrotina), mas este ltimo pode tambm ser realizado isoladamente. A Figura 5.19
ilustra uma situao bastante comum, em que, ao se realizar um processo de negcio (no
caso a reserva de um carro em um sistema de locao de automveis), caso uma
informao necessria para esse processo (no caso o cliente) no esteja disponvel, ela
pode ser inserida no sistema. Contudo, o cadastro da informao tambm pode ser feito
dissociado do processo de negcio que o inclui (no caso, o cliente pode se cadastrar fora
do contexto da reserva de um carro). Ao no se admitir a possibilidade de um caso de
uso includo poder ser utilizado isoladamente, no possvel modelar situaes desta
natureza, as quais so bastante frequentes.
Figura 5.19 Exemplo de Associao de Incluso.

Extenso
Uma associao de extenso entre um caso de uso de extenso e um caso de uso
base significa que o comportamento definido no caso de uso de extenso pode ser
inserido dentro do comportamento definido no caso de uso base, em um local
especificado indiretamente pelo caso de uso de extenso. A extenso ocorre em um ou
mais pontos de extenso especficos definidos no caso de uso base. A extenso pode ser
condicional. Neste caso, a extenso ocorre apenas se a condio verdadeira quando o
ponto de extenso especificado atingido. O caso de uso base definido de forma
independente do caso de uso de extenso e significativo independentemente do caso
de uso de extenso (OLIV, 2007; BOOCH; RUMBAUGH; JACOBSON, 2006).
Um caso de uso pode ter vrios pontos de extenso e esses pontos so
referenciados por seus nomes (BOOCH; RUMBAUGH; JACOBSON, 2006). O caso de
uso base apenas indica seus pontos de extenso. O caso de uso de extenso especifica
em qual ponto de extenso ele ser inserido. Por isso, diz-se que o caso de uso de
extenso especifica indiretamente o local onde seu comportamento ser inserido.
A associao de extenso como uma relao de incluso olhada da direo
oposta, em que a extenso se incorpora ao caso de uso base, em vez de o caso de uso
base incorporar explicitamente a extenso. Ela conecta um caso de uso de extenso a
um caso de uso base. O caso de uso de extenso geralmente um fragmento, ou seja, ele
no aparece sozinho como uma sequncia de comportamentos. Alm disso, na maioria
das vezes, a relao de extenso possui uma condio associada e, neste caso, o
comportamento de extenso ocorre apenas se a condio for verdadeira. O caso de uso
_________________________________________________________________________________________________________
44
base, por sua vez, precisa ser, obrigatoriamente, um caso de uso vlido na ausncia de
quaisquer extenses (BLAHA; RUMBAUGH, 2006).
Na UML, a associao de extenso entre casos de uso mostrada como uma
dependncia (seta pontilhada) estereotipada com a palavra chave extend, partindo do
caso de uso de extenso para o caso de uso base, como ilustra a Figura 5.20. Pontos de
extenso podem ser indicados no compartimento da elipse do caso de uso, denominado
extension points (pontos de extenso). Opcionalmente, a condio a ser satisfeita e a
referncia ao ponto de extenso podem ser mostradas por meio de uma nota 10 anexada
associao de extenso (OLIV, 2007). Assim, no exemplo da Figura 5.20, o Caso de
Uso de Extenso 1 executado quando o ponto de extenso 1 do Caso de Uso Base for
atingido, se a condio for verdadeira.
Figura 5.20 Associao de Extenso na UML

Uma importante diferena entre as associaes de incluso e extenso que, na
primeira o caso de uso base est ciente do caso de uso de incluso, enquanto na segunda
o caso de uso base no est ciente dos possveis casos de uso de extenso (OLIV,
2007).
Assim como no caso da incluso, uma associao de extenso deve ser
referenciada na descrio do caso de uso base. Neste caso, contudo, o caso de uso base
apenas aponta o ponto de extenso, sem fazer uma referncia explcita ao caso de uso de
extenso. O local de cada um dos pontos de extenso deve ser indicado na descrio do
caso de uso base, atravs de uma referncia ao nome do ponto de extenso seguido de :
ponto de extenso. Assim, a descrio do fluxo de eventos (principal ou alternativo) do
caso de uso base deve conter indicaes explcitas para cada ponto de extenso.
No exemplo do caixa automtico, suponha que se deseja coletar dados
estatsticos sobre os valores das notas entregues nos saques, de modo a permitir
alimentar o caixa eletrnico com as notas mais adequadas para saque. Poder-se-ia,
ento, estender o caso de uso Efetuar Saque, de modo que, quando necessrio, outro
caso de uso, denominado Coletar Estatsticas de Notas, contasse e acumulasse o tipo
das notas entregues em um saque, conforme mostra a Figura 5.21. A Figura 5.22 mostra
10
Nota o nico item de anotao da UML. Notas so usadas para explicar partes de um modelo da
UML. So comentrios includos para descrever, esclarecer ou fazer alguma observao sobre qualquer
elemento do modelo. Assim, uma nota apenas um smbolo para representar restries e comentrios
anexados a um elemento ou a uma coleo de elementos. Graficamente, uma nota representada por um
retngulo com um dos cantos com uma dobra de pgina, acompanhado por texto e anexada ao(s)
elemento(s) anotados por meio de linha(s) pontilhada(s) (BOOCH; RUMBAUGH; JACOBSON, 2006).
No exemplo da Figura 5.20, a nota est anexada ao relacionamento de extenso, adicionando-lhe
informaes sobre o ponto de extenso e a condio associados extenso.
_________________________________________________________________________________________________________
45
a descrio do caso de uso Efetuar Saque indicando o ponto de extenso entrega do

dinheiro.
Figura 5.21 - Diagrama de Casos de Uso Caixa Automtico com Extenso.
Nome: Efetuar Saque

1.
2.
3.
4.
5.
Incluir Validar Carto.

O cliente seleciona a opo saque.
O caixa automtico solicita que seja informada a quantia.
O cliente informa a quantia a ser sacada.
O caixa automtico envia uma requisio para o sistema bancrio para que
6. As notas so preparadas.
entrega do dinheiro: ponto de extenso.
7. As notas so liberadas
abortada.
Figura 5.22 Descrio do Caso de Uso Efetuar Saque com incluso.
_________________________________________________________________________________________________________
46
Generalizao / Especializao
Um relacionamento de generalizao / especializao entre um caso de uso pai e
um caso de uso filho significa que o caso de uso filho herda o comportamento e o
significado do caso de uso pai, acrescentando ou sobrescrevendo seu comportamento
(OLIV, 2007; BOOCH; RUMBAUGH; JACOBSON, 2006). Na UML,
relacionamentos de generalizao / especializao so representados como uma linha
cheia direcionada com uma seta aberta (smbolo de herana), como ilustra a Figura 5.22.
Figura 5.22 Associao de Generalizao / Especializao entre Casos de Uso na

UML.
Voltando ao exemplo do sistema de caixa automtico, suponha que haja duas
formas adotadas para se validar o carto: a primeira atravs de senha, como descrito
anteriormente, e a segunda por meio de anlise da retina do cliente. Neste caso,
poderiam ser criadas duas especializaes do caso de uso Validar Cliente, como mostra
a Figura 5.23.
Figura 5.23 Exemplo de Generalizao / Especializao entre Casos de Uso

A descrio do caso de uso pai teria de ser generalizada para acomodar
diferentes tipos de validao. Esses tipos de validao seriam especializados nas
descries dos casos de uso filhos. A Figura 5.24 mostra as descries desses trs casos
de uso.
A generalizao / especializao aplicvel quando um caso de uso possui
diversas variaes. O comportamento comum pode ser modelado como um caso de uso
abstrato e especializado para as diferentes variaes (BLAHA; RUMBAUGH, 2006).
Contudo, avalie se no fica mais simples e direto descrever essas variaes como fluxos
alternativos variantes na descrio de casos de uso. Quando forem poucas e pequenas as
variaes, muito provavelmente ser mais fcil captur-las na descrio, ao invs de
criar hierarquias de casos de uso. A Figura 5.25 mostra uma soluo anloga da Figura
5.24, sem usar, no entanto, especializaes do caso de uso.
_________________________________________________________________________________________________________
47
Nome: Validar Carto

1. O cliente insere o carto no caixa automtico.
2. O caixa automtico analisa o carto e verifica se ele aceitvel.
3. O caixa automtico solicita informao para identificao do cliente.
4. O cliente informa sua identificao.
5. O caixa automtico envia os dados do carto e da identificao para o
sistema bancrio para validao.
efetuada.
5a Dados de Identificao Incorretos:
transao abortada.
Nome: Validar Carto por Anlise de Retina
3. O caixa automtico solicita que o cliente se posicione corretamente para a
captura da imagem da retina.
4. O caixa automtico retira uma foto da retina do cliente.
5. O caixa automtico envia os dados do carto e a foto da retina para o sistema
Nome: Validar Carto por Autenticao de Senha
3. O caixa automtico solicita a senha.
4. O cliente informa a senha.
5. O caixa automtico envia os dados do carto e a senha para o sistema
Figura 5.24 Descrio do Caso de Uso Validar Carto e suas Especializaes.
_________________________________________________________________________________________________________
48
Nome: Validar Carto

1. O cliente insere o carto no caixa automtico.
2. O caixa automtico analisa o carto e verifica se ele aceitvel.
3. Validar carto.
efetuada.
Fluxos de Eventos Variantes
3a Validar carto por autenticao de senha:
3a.1 O caixa automtico solicita a senha.
3a.2 O cliente informa a senha.
3a.3 O caixa automtico envia os dados do carto e a senha para o
sistema bancrio para validao.
3b Validar carto por anlise de retina:
3b.1 O caixa automtico solicita que o cliente se posicione corretamente
para a captura da imagem da retina.
3b.2 O caixa automtico retira uma foto da retina do cliente.
3b.3 O caixa automtico envia os dados do carto e a foto da retina para
o sistema bancrio para validao.
5a Dados de Identificao Incorretos:
transao abortada.
Figura 5.25 Descrio do Caso de Uso Validar Carto com Variantes.
Diretrizes para o Uso dos Tipos de Relacionamentos entre Casos de Uso
Os relacionamentos entre casos de uso devem ser utilizados com cuidado para
evitar a introduo de complexidade desnecessria. As seguintes orientaes so teis
para ajudar a decidir quando usar relacionamentos entre casos de uso em um diagrama
de casos de uso:
A incluso tipicamente aplicvel quando se deseja capturar um fragmento

de comportamento comum a vrios casos de uso. Na maioria das vezes, o
_________________________________________________________________________________________________________
49
caso de uso de incluso uma atividade significativa, mas no como um fim

em si mesma (BLAHA; RUMBAUGH, 2006). Ou seja, o caso de uso de
incluso no precisa ser uma transao completa.
Um relacionamento de incluso empregado quando h uma poro de

comportamento que similar ao longo de um ou mais casos de uso e no se
deseja repetir a sua descrio. Para evitar redundncia e assegurar reso,
extrai-se essa descrio e se compartilha a mesma entre diferentes casos de
uso.Desta maneira, utiliza-se a incluso para evitar ter de descrever o mesmo
fragmento de comportamento vrias vezes, capturando o comportamento
comum em um caso de uso prprio (BOOCH; RUMBAUGH; JACOBSON,
2006).
No se deve utilizar o relacionamento de generalizao / especializao para

compartilhar fragmentos de comportamento. Para este propsito, deve-se
usar a relao de incluso (BLAHA; RUMBAUGH, 2006).
A relao de extenso bastante til em situaes em que se pode definir um

caso de uso significativo com recursos adicionais. O comportamento bsico
capturado no caso de uso base e os recursos adicionais nos casos de uso de
extenso. Use a relao de extenso quando o sistema puder ser usado em
diferentes configuraes, algumas com os recursos adicionais e outras sem
eles (BLAHA; RUMBAUGH, 2006).
Tanto a incluso quanto a extenso podem ser usadas para dividir o

comportamento em partes menores. A incluso, entretanto, implica que o
comportamento includo uma parte necessria de um sistema configurado,
mesmo que seu comportamento no seja executado todas as vezes, ou seja,
mesmo que o comportamento includo esteja associado a uma condio. A
extenso, por sua vez, implica que o sistema sem o comportamento
adicionado pela extenso significativo (BLAHA; RUMBAUGH, 2006).
5.5 Modelagem Conceitual Estrutural

O modelo conceitual estrutural de um sistema tem por objetivo descrever as
informaes que esse sistema deve representar e gerenciar.Modelos conceituais devem
ser concebidos com foco no domnio do problema e no no domnio da soluo e, por
conseguinte, um modelo conceitual estrutural um artefato do domnio do problema e
no do domnio da soluo.
As informaes a serem capturadas em um modelo conceitual estrutural devem
existir independentemente da existncia de um sistema computacional para trat-las. Ele
deve ser independe da soluo computacional a ser adotada para resolver o problema e
deve conter apenas os elementos de informao referentes ao domnio do problema em
questo. Elementos da soluo, tais como interfaces, formas de armazenamento e
comunicao, devem ser tratados apenas na fase de projeto (WAZLAWICK, 2004).
Uma vez que requisitos no-funcionais de produto (atributos de qualidade) so
inerentes soluo computacional, geralmente eles no so tratados na modelagem
conceitual. Ou seja, no se consideram elementos de informao para tratar aspectos
como desempenho, segurana de acesso, confiabilidade, formas de armazenamento etc.
_________________________________________________________________________________________________________
50
Esses atributos de qualidade do produto so considerados posteriormente, na fase de

projeto.
Os elementos de informao bsicos da modelagem conceitual estrutural so os
tipos de entidades e os tipos de relacionamentos. A identificao de quais os tipos de
entidades e os tipos de relacionamentos que so relevantes para um particular sistema de
informao uma meta crucial da modelagem conceitual (OLIV, 2007).
Na modelagem conceitual segundo o paradigma orientado a objetos, tipos de
entidades so modelados como classes. Tipos de relacionamentos so modelados como
atributos e associaes. Assim, o propsito da modelagem conceitual estrutural
orientada a objetos definir as classes, atributos e associaes que so relevantes para
tratar o problema a ser resolvido. Para tal, as seguintes tarefas devem ser realizadas:
Identificao de Classes
Identificao de Atributos e Associaes
Especificao de Hierarquias de Generalizao/Especializao
importante notar que essas atividades so dependentes umas das outras e que,
durante o desenvolvimento, elas so realizadas, tipicamente, de forma paralela e
iterativa, sempre visando ao entendimento do domnio do problema, desconsiderando
aspectos de implementao.
5.5.1 Identificao de Classes
Classificao o meio pelo qual os seres humanos estruturam a sua percepo
do mundo e seu conhecimento sobre ele. Sem ela, no possvel nem entender o mundo
a nossa volta nem agir sobre ele. Classificao assume a existncia de tipos e de objetos
a serem classificados nesses tipos. Classificar consiste, ento, em determinar se um
objeto ou no uma instncia de um tipo. A classificao nos permite estruturar
conhecimento sobre as coisas em dois nveis: tipos e instncias. No nvel de tipos,
procuramos encontrar as propriedades comuns a todas as instncias de um tipo. No
nvel de instncia, procuramos identificar o tipo do qual o objeto uma instncia e os
valores particulares das propriedades desse objeto (OLIV, 2007).
Tipos de entidade so um dos mais importantes elementos em modelos
conceituais. Definir os tipos de entidade relevantes para um particular sistema de
informao uma tarefa crucial na modelagem conceitual. Um tipo de entidade pode ser
definido como um tipo cujas instncias em um dado momento so objetos individuais
identificveis que se consideram existir no domnio naquele momento. Um objeto pode
ser instncia de vrios tipos ao mesmo tempo (OLIV, 2007). Por exemplo, seja o caso
dos tipos Estudante e Funcionrio em um sistema de uma universidade. Uma mesma
pessoa, por exemplo Joo, pode ser ao mesmo tempo um estudante e um funcionrio
dessa universidade.
Na orientao a objetos, tipos de entidade so representados por classes,
enquanto as instncias de um tipo de entidade so objetos. Assim, uma atividade crucial
da modelagem conceitual estrutural segundo o paradigma orientado a objetos (OO) a
identificao de classes. Na UML, classes so representadas por um retngulo com trs
compartimentos: o compartimento superior relativo ao nome da classe; o
compartimento do meio dedicado especificao dos atributos da classe; e o
_________________________________________________________________________________________________________
51
compartimento inferior dedicado especificao das operaes da classe. A Figura

5.26 mostra a notao de classe na UML.
Figura 5.26 Notao de Classes na UML.

Para nomear classes, sugere-se iniciar com um substantivo no singular, o qual
pode ser combinado com complementos ou adjetivos, omitindo-se preposies. O nome
da classe deve ser iniciado com letra maiscula, bem como os nomes dos
complementos, sem dar um espao em relao palavra anterior. Acentos no devem
ser utilizados. Ex.: Cliente, PessoaFisica, ItemPedido.
Tomando por base os requisitos iniciais do usurio e, sobretudo, o modelo de
casos de uso, possvel iniciar o trabalho de modelagem da estrutura do sistema. Esse
trabalho comea com a descoberta de quais classes devem ser includas no modelo. O
cerne de um modelo OO exatamente o seu conjunto de classes.
Durante a anlise de requisitos, tipicamente o analista estuda, filtra e modela o
domnio do problema. Dizemos que o analista filtra o domnio, pois apenas uma parte
desse domnio far parte das responsabilidades do sistema. Assim, um domnio de
problemas pode incluir vrias informaes, mas as responsabilidades de um sistema
nesse domnio podem incluir apenas uma pequena parcela deste conjunto.
As classes de um modelo representam a expresso inicial do sistema. As
atividades subsequentes da modelagem estrutural buscam obter uma descrio cada vez
mais detalhada, em termos de associaes e atributos. Contudo, deve-se observar que,
medida que atributos e associaes vo sendo identificados, se ganha maior
entendimento a respeito do domnio e naturalmente novas classes surgem. Assim, as
atividades da modelagem conceitual so iterativas e com alto grau de paralelismo,
devendo ser realizadas concomitantemente.
Conforme apontado anteriormente, dois importantes insumos para a atividade de
identificao de classes so o Documento de Requisitos e o Modelo de Casos de Uso.
Uma maneira bastante prtica e eficaz de trabalhar a identificao de classes consiste
em olhar esses dois documentos, em especial a descrio do minimundo e as descries
de casos de uso, procura de classes.
Diversos autores, dentre eles Jacobson (1992) e Wazlawick (2004), sugerem que
uma boa estratgia para identificar classes consiste em ler esses documentos procurando
por substantivos. Esses autores argumentam que uma classe , tipicamente, descrita por
um nome no domnio e, portanto, aprender sobre a terminologia do domnio do
problema um bom ponto de partida. Ainda que um bom ponto de partida, essa
heurstica ainda muito vaga. Se o analista segui-la fielmente, muito provavelmente ele
ter uma extensa lista de potenciais classes, sendo que muitas delas podem, na verdade,
se referir a atributos de outras classes. Alm disso, pode ser que importantes classes no
sejam capturadas, notadamente aquelas que se referem ao registro de eventos de
negcio, uma vez que esses eventos muitas vezes so descritos na forma de verbos. Seja
o seguinte exemplo de uma descrio de um domnio de locao de automveis:
clientes locam carros. Seriam consideradas potenciais classes: Cliente e Carro.
_________________________________________________________________________________________________________


52
Contudo, a locao um evento de negcio importante que precisa ser registrado e,

usando a estratgia de identificar classes a partir de substantivos, Locao no entraria
na lista de potenciais classes.
Assim, neste texto sugere-se que, ao examinar documentos de requisitos e
modelos de casos de uso, os seguintes elementos sejam considerados como candidatos a
classes:
Agentes: entidades do domnio do problema que tm a capacidade de agir
com inteno de atingir uma meta. Em sistemas de informao, h dois tipos
principais de agentes: os agentes fsicos (tipicamente pessoas) e os agentes
sociais (organizaes, unidades organizacionais, sociedades etc.). Em relao
s pessoas, deve-se olhar para os papis desempenhados pelas diferentes
pessoas no domnio do problema.
Objetos: entidades sem a capacidade de agir, mas que fazem parte do domnio
de informao do problema. Podem ser tambm classificados em fsicos
(p.ex., carros, livros, imveis) e sociais (p.ex., cursos, disciplinas, leis).
Entretanto, h tambm outros tipos de objetos, tais como objetos de carter
descrito usado para organizar e descrever outros objetos de um domnio
(p.ex., modelos de carro), algumas vezes denominados objetos de
especificao. Objetos sociais e de descrio (ou especificao) tendem a ser
coisas menos tangveis, mas so to importantes para a modelagem conceitual
quanto os objetos fsicos e, portanto, palpveis.
Eventos: representam a ocorrncia de aes no domnio do problema que
precisam ser registradas e lembradas pelo sistema. Eventos acontecem no
tempo e, portanto, a representao de eventos normalmente envolve a
necessidade de registrar, dentre outros, quando o evento ocorreu. Deve-se
observar que muitos eventos ocorrem no domnio do problema, mas grande
parte deles no precisa ser lembrada. Para capturar os eventos que precisam
ser lembrados e, portanto, registrados, devem-se focalizar os principais
eventos de negcio do domnio do problema. Assim, em um sistema de
locao de automveis, so potenciais classes de eventos: Locao,
Devoluo e Reserva. Por outro lado, a ocorrncia de eventos cadastrais, tais
como os cadastros de clientes e carros, tende a ser de pouca importncia, no
sendo necessrio lembrar a ocorrncia desses eventos.
Seja qual for a estratgia usada para identificar classes, sempre importante que
o analista tenha em mente os objetivos do sistema durante a modelagem conceitual. No
se devem representar informaes irrelevantes para o sistema e, portanto, a relevncia
para o sistema o principal critrio a ser adotado para decidir se um determinado
elemento deve ou no ser includo no modelo conceitual estrutural do sistema.
O resultado principal da atividade de identificao de classes a obteno de
uma lista de potenciais classes para o sistema em estudo. Um modelo conceitual
estrutural para uma aplicao complexa pode ter dezenas de classes e, portanto, pode ser
necessrio definir uma representao concisa capaz de orientar um leitor em um modelo
desta natureza. O agrupamento de classes em subsistemas serve basicamente a este
propsito, podendo ser til tambm para a organizao de grupos de trabalho em
projetos extensos. Atravs da identificao e agrupamento de classes em subsistemas,
possvel controlar a visibilidade do leitor e, assim, tornar o modelo mais compreensvel.
_________________________________________________________________________________________________________
53
Assim, da mesma maneira que casos de uso so agrupados em pacotes, classes tambm
devem ser.
Quando uma coleo de classes colabora entre si para realizar um conjunto
coeso de responsabilidades (casos de uso), elas podem ser vistas como um subsistema.
Assim, um subsistema uma abstrao que prov uma referncia para mais detalhes em
um modelo de anlise, incluindo tanto casos de uso quanto classes. O agrupamento de
classes em subsistemas permite apresentar o modelo global em uma perspectiva mais
alta. Esse nvel ajuda o leitor a rever o modelo, bem como constitui um bom critrio
para organizar a documentao.
Uma vez identificadas as potenciais classes, deve-se proceder uma avaliao
para decidir o que efetivamente considerar ou rejeitar. Conforme discutido
anteriormente, a relevncia para o sistema deve ser o critrio principal. Alm desse
critrio, os seguintes tambm devem ser considerados nessa avaliao:
Estrutura complexa: o sistema precisa tratar informaes sobre os objetos da
classe? Tipicamente, uma classe deve ter, pelo menos, dois atributos. Se uma
classe apresentar apenas um atributo, avalie se no melhor trat-la como um
atributo de uma classe existente11.
Atributos e associaes comuns: os atributos e as associaes da classe
devem ser aplicveis a todas as suas instncias, isto , a todos os objetos da
classe.
Classes no redundantes: duas classes so redundantes quando elas tm
sempre a mesma populao12. Seja o exemplo de um modelo conceitual que
tenha as classes Pessoa e Funcionrio. Se o sistema est interessado apenas
nas pessoas empregadas na organizao (ou seja, funcionrios), ento a
populao dessas duas classes ser sempre a mesma. A introduo de classes
redundantes afeta e simplicidade do modelo e, portanto, um modelo
conceitual no deve incluir classes redundantes.
Existncia de instncias: toda classe deve possuir uma populao no vazia.
Uma potencial classe que possui uma nica instncia tambm no deve ser
considerada uma classe. Tipicamente uma classe possui vrias instncias e a
populao da classe varia ao longo do tempo.
5.5.2 - Identificao de Atributos e Associaes
Conforme apontado anteriormente, uma classe tpica de um modelo conceitual
estrutural deve apresentar estrutura complexa. A estrutura de uma classe corresponde a
seus atributos e associaes.
Conceitualmente, no h diferena entre atributos e associaes. Atributos so,
na verdade, tipos de relacionamentos binrios. Em um tipo de relacionamento binrio,
h dois participantes. Em alguns tipos de relacionamentos, esses participantes so
considerados colegas, porque eles desempenham funes anlogas e nenhum deles
subordinado ao outro. Seja o caso do tipo de relacionamento aluno cursa um curso.
11
Uma classe que possui um nico atributo, mas vrias associaes, tambm satisfaz a esse critrio.
A populao de uma classe em um dado momento o conjunto de instncias que existem no domnio
naquele momento (OLIV, 2007).
12
_________________________________________________________________________________________________________
54
Um aluno no pode cursar sem haver um curso, bem como um curso no pode ser
cursado se no houver um aluno. A ordem dos participantes no modelo no implica uma
relao de prioridade ou subordinao entre eles (OLIV, 2007). Na orientao a
objetos, esse tipo de relacionamento modelado como uma associao.
Entretanto, h alguns tipos de relacionamentos nos quais usurios e analistas
consideram um participante como sendo uma caracterstica do outro. Seja o exemplo do
tipo de relacionamento filme possui gnero. Algum pode argumentar que o
participante gnero uma caracterstica de filme e, portanto, subordinado a este. Esse
tipo de relacionamento modelado como um atributo. Assim, um atributo um tipo de
relacionamento binrio em que um participante considerado uma caracterstica de
outro. Por conseguinte, um atributo igual a uma associao, exceto pelo fato de
usurios e analistas adicionarem a interpretao que um dos participantes subordinado
ao outro (OLIV, 2007).
De uma perspectiva mais prtica, atributos podem ser vistos como informaes
alfanumricas ligadas a um conceito. Associaes, por sua vez, consistem em um tipo
de informao que liga diferentes conceitos entre si (WAZLAWICK, 2004). Atributos
ligam classes do domnio do problema a tipos de dados.
Tipos de dados podem ser primitivos ou especficos de domnio. Os tipos de
dados primitivos so aplicveis aos vrios domnios e sistemas, tais como strings, datas,
inteiros e reais, e so considerados como sendo predefinidos. Os tipos de dados
especficos de um domnio de aplicao, por outro lado, precisam ser definidos. So
exemplos de tipos de dados especficos: CPF, ISBN de livros, endereo etc.
Neste texto so considerados os seguintes tipos de dados primitivos:
String: cadeia de caracteres;
boolean: admite apenas os valores verdadeiro e falso;
Integer (ou int): nmeros inteiros;
Float (ou float): nmeros reais;
Currency: valor em moeda (reais, dlares etc.);
Date: datas, com informao de dia, ms e ano;
Time: horas em um dia, com informao de hora, minuto e segundo;
DateTime: combinao dos dois anteriores;
YearMonth: informao de tempo contendo apenas ms e ano;
Year: informao de tempo contendo apenas ano.
Atributos
Um atributo uma informao de estado para a qual cada objeto em uma classe
tem o seu prprio valor. Os atributos adicionam detalhes s abstraes e so
apresentados na parte central do smbolo de classe.
Conforme discutido anteriormente, atributos possuem um tipo de dado, que pode
ser primitivo ou especfico de domnio. Ao identificar um atributo como sendo
relevante, deve-se definir qual o seu tipo de dado. Caso nenhum dos tipos de dados
_________________________________________________________________________________________________________
55
primitivos se aplique, deve-se definir, ento, um tipo de dados especfico. Por exemplo,
em domnios que lidem com livros, necessrio definir o tipo ISBN 13, cujas instncias
so ISBNs vlidos. Em domnios que lidem com pessoas fsicas e jurdicas, CPF e
CNPJ tambm devem ser definidos como tipos de dados especficos. Usar um tipo de
dados primitivo nestes casos, tais como String ou int, insuficiente, pois no so
quaisquer cadeias de caracteres ou nmeros que se caracterizam como ISBNs, CPFs ou
CNPJs vlidos.
Tipos de dados especficos podem apresentar propriedades. Por exemplo, CPF
um nmero de 11 dgitos, que pode ser dividido em duas partes: os 9 primeiros dgitos e
os dois ltimos, que so dgitos verificadores.
Um tipo de dados especial a enumerao. Na enumerao, os valores do tipo
so enumerados explicitamente na forma de literais, como o caso do tipo DiaSemana,
que tipicamente definido como um tipo de dados compreendendo sete valores:
Segunda, Tera, Quarta, Quinta, Sexta, Sbado e Domingo. importante observar que
tipos de dados enumerados s devem ser usados quando se sabe priori quais so os
seus valores e eles so fixos. Assim, so bons candidatos a tipos enumerados
informaes como sexo (M/F), estado civil etc.
Tipos de dados geralmente no so representados graficamente em um modelo
conceitual estrutural, de modo a torn-lo mais simples. Na maioria das situaes, basta
descrever os tipos de dados especficos de domnio no Dicionrio de Dados do Projeto.
Contudo, se necessrio, eles podem ser representados graficamente usando o smbolo de
classe estereotipado com a palavra chave <<dataType>>. Tipos enumerados tambm
podem ser representados usando o smbolo de classe, mas com o esteretipo
<<enumeration>>, sendo que ao invs de apresentar atributos de um tipo de dados,
enumeram-se os valores possveis da enumerao. A Figura 5.27 ilustra a notao de
tipos de dados na UML.
Figura 5.27 Notao de Tipos de Dados na UML.

Uma dvida tpica e recorrente na modelagem estrutural se um determinado
item de informao deve ser modelado como uma classe ou como um atributo. Para que
o item seja considerado uma classe, ele tem de passar nos critrios de incluso no
modelo discutidos na seo anterior. Entretanto, h alguns itens de informao que
passam nesses critrios, mas que ainda assim podem ser melhor modelados como
atributos, tendo como tipo um tipo de dado complexo, especfico de domnio. Um
13
O ISBN - International Standard Book Number - um sistema internacional padronizado que identifica
numericamente os livros segundo o ttulo, o autor, o pas, a editora, individualizando-os inclusive por
edio. Utilizado tambm para identificar software, seu sistema numrico pode ser convertido em cdigo
de barras.
_________________________________________________________________________________________________________
56
atributo deve capturar um conceito atmico, i.e., um nico valor ou um agrupamento de

valores fortemente relacionados que sirva para descrever um outro objeto. Alm disso,
para que um item de estrutura complexa seja modelado como um atributo, ele deve ser
compreensvel pelos interessados simplesmente pelo seu nome.
bom realar que, com o tempo, as classes do domnio do problema tendem a
permanecer relativamente estveis, enquanto os atributos provavelmente se alteram.
Atributos podem ser bastante volteis, em funo de alteraes nas responsabilidades do
sistema.
muito importante lembrar tambm que, uma vez que atributos e associaes
so tipos de relacionamentos, no devemos incluir na lista de atributos de uma classe,
atributos representando associaes (ou atributos representando chaves estrangeiras
como a classe fosse uma tabela de um banco de dados relacional). Associaes j tm
sua presena indicada pela notao de associao, ou seja pelas linhas que conectam as
classes que se relacionam.
Um aspecto bastante importante na especificao de atributos a escolha de
nomes. Deve-se procurar utilizar o vocabulrio tpico do domnio do problema, usando
nomes legveis e abrangentes. Para nomear atributos, sugerem-se nomes iniciando com
substantivo, o qual pode ser combinado com complementos ou adjetivos, omitindo-se
preposies. O nome do atributo deve ser iniciado com letra minscula, enquanto os
nomes dos complementos devem iniciar com letras maisculas, sem dar um espao em
relao palavra anterior. Acentos no devem ser utilizados. Atributos monovalorados
devem iniciar com substantivo no singular (p.ex., nome, razaoSocial), enquanto
atributos multivalorados devem iniciar com o substantivo no plural (p.ex., telefones).
A sintaxe de atributos na UML, em sua forma plena, a seguinte (BOOCH;
RUMBAUGH; JACOBSON, 2006):
visibilidade nome: tipo [multiplicidade] = valorInicial {propriedades}
A visibilidade de um atributo indica em que situaes esse atributo visvel por

outras classes. Na UML h quatro nveis de visibilidade, os quais so marcados pelos
seguintes smbolos:
+ pblico : o atributo pode ser acessado por qualquer classe;
# protegido: o atributo s passvel de acesso pela prpria classe ou por uma de
suas especializaes;
- privado: o atributo s pode ser acessado pela prpria classe;
~ pacote: o atributo s pode ser acessado por classes declaradas dentro do
mesmo pacote da classe a que pertence o atributo.
A informao de visibilidade inerente fase de projeto e no deve ser expressa
em um modelo conceitual. Assim, em um modelo conceitual, atributos devem ser
especificados sem nenhum smbolo antecedendo o nome.
O tipo indica o tipo de dado do atributo, o qual deve ser um tipo de dado
primitivo ou um tipo de dado especfico de domnio. Tipos de dados especficos de
domnio devem ser definidos no Dicionrio de Dados do Projeto. Para tornar os
modelos conceituais mais simples, de modo a facilitar a comunicao com clientes e
usurios, tipos de dados de atributos podem ser omitidos do diagrama de classes.
_________________________________________________________________________________________________________
57
A multiplicidade a especificao do intervalo permitido de itens que o atributo

pode abrigar. O padro que cada atributo tenha um e somente um valor para o atributo.
Quando um atributo for opcional ou quando puder ter mais do que uma ocorrncia, a
multiplicidade deve ser informada, indicando o valor mnimo e o valor mximo, da
seguinte forma:
valor_mnimo .. valor_mximo
A seguir, so dados alguns exemplos:
nome: String instncias da classe tm obrigatoriamente um e somente um

nome.
carteira: String [0..1] instncias da classe tm uma ou nenhuma carteira.
telefones: Telefone [0..*] instncias da classe tm um ou vrios telefones.
pessoasContato: String [2] instncias da classe tm exatamente duas

pessoas de contato.
Atributos podem ter um valor padro inicial, ou seja, um valor que, quando no
informado outro valor, ser atribudo ao atributo. O campo valorInicial descreve
exatamente este valor. O exemplo abaixo ilustra o uso de valor inicial.
origem: Ponto = (0,0) a origem, quando no informado outro valor, ser o ponto
(0,0)
Finalmente, podem ser indicadas propriedades dos atributos. Uma propriedade
que pode ser interessante mostrar em um modelo conceitual a propriedade readonly, a
qual indica que o valor do atributo no pode ser alterado aps a inicializao do objeto.
No exemplo abaixo, est-se indicando que o valor do atributo numeroSocio de um scio
de um clube no pode ser alterado.
numSocio: int {readonly}
Alm das informaes tratadas na declarao de um atributo seguindo a sintaxe
da UML, outras informaes de domnio, quando pertinentes, podem ser adicionadas no
Dicionrio de Dados do Projeto, tais como unidade de medida, intervalo de valores
possveis, limite, preciso etc.
Associaes
Uma associao um tipo de relacionamento que ocorre entre instncias de duas
ou mais classes. Assim como classes, associaes so tipos. Ou seja, uma associao
modela um tipo de relacionamento que pode ocorrer entre instncias das classes
envolvidas. Uma instncia de uma associao (dita uma ligao) conecta instncias
especficas das classes envolvidas na associao. Seja o exemplo de um domnio em
que clientes efetuam pedidos. Esse tipo de relacionamento pode ser modelado como
uma associao Cliente efetua Pedido. Seja Pedro uma instncia de Cliente e Pedido100
uma instncia de Pedido. Se foi Pedro quem efetuou o Pedido100, ento a ligao
(Pedro, Pedido100) uma instncia da associao Cliente efetua Pedido.
Associaes podem ser nomeadas. Neste texto sugere-se o uso de verbos
conjugados, indicando o sentido de leitura. Ex.: Cliente (classe) efetua > (associao)
Locao (classe). Cada classe envolvida na associao desempenha um papel, ao qual
pode ser dado um nome. Cada classe envolvida na associao possui tambm uma
_________________________________________________________________________________________________________
58
multiplicidade14 nessa associao, que indica quantos objetos podem participar de uma
instncia dessa associao. A notao da UML tipicamente usada para representar
associaes em um modelo conceitual ilustrada na Figura 6.3.
Figura 5.28 Notao de Associaes na UML.

Na ilustrao da figura, um objeto da Classe1 se relaciona com no mnimo c e no
mximo d objetos da Classe2. J um objeto da Classe2 se relaciona com no mnimo a e
no mximo b objetos da Classe1. Objetos da Classe1 desempenham o papel de
papelClasse1 nesta associao, enquanto objetos da Classe2 desempenham o papel de
papelClasse2 nessa mesma associao.
importante, neste ponto, frisar a diferena entre sentido de leitura (ou direo
do nome) de uma associao com a navegao da associao. O sentido de leitura diz
apenas em que direo ler o nome da associao, mas nada diz sobre a navegabilidade
da associao. A navegabilidade (linha de associao com seta direcionada) usada
para limitar a navegao de uma associao a uma nica direo e um recurso a ser
usado apenas na fase de projeto. Em um modelo conceitual, todas as associaes so
no direcionais, ou seja, navegveis nos dois sentidos.
Ainda que nomes de associaes e papis sejam opcionais, recomenda-se us-los
para tornar o modelo mais claro. Alm disso, h algumas situaes em que fica invivel
ler um modelo se no houver a especificao do nome da associao ou de algum de
seus papis.
Seja o exemplo da Figura 5.29. Em uma empresa, um empregado est lotado em
um departamento e, opcionalmente, pode chefi-lo. Um departamento, por sua vez,
pode ter vrios empregados nele lotados, mas apenas um chefe. Sem nomear essas
associaes, o modelo fica confuso. Rotulando os papis e as associaes, o modelo
torna-se muito mais claro. Na figura 5.29, um departamento exerce o papel de
departamento de lotao do empregado e, neste caso, um empregado tem um e somente
um departamento de lotao. No outro relacionamento, um empregado exerce o papel
de chefe e, portanto, um departamento possui um e somente um chefe.
Figura 5.29 Exemplo: Nomeando Associaes.

14
Multiplicidades em uma associao so anlogas s multiplicidades em atributos e especificam as

quantidades mnima e mxima de objetos que podem participar da associao. Quando nada for dito, o
padro 1..1 como no caso de atributos. Contudo, para deixar os modelos claros, recomenda-se sempre
especificar explicitamente as multiplicidades das associaes.
_________________________________________________________________________________________________________
59
Ao contrrio das classes e dos atributos que podem ser encontrados facilmente a
partir da leitura dos textos da descrio do minimundo e das descries de casos de uso,
muitas vezes, as informaes sobre associaes no aparecem to explicitamente. Casos
de uso descrevem aes de interao entre atores e sistema e, por isso, acabam
mencionando principalmente operaes. Operaes transformam a informao,
passando um objeto de um estado para outro, por meio da alterao dos seus valores de
atributos e associaes. Uma associao, por sua vez, uma relao esttica que pode
existir entre duas classes. Assim, as descries de casos de uso esto repletas de
operaes, mas no de associaes (WAZLAWICK, 2004).
Contudo, conforme discutido na seo anterior, h alguns eventos que precisam
ter sua ocorrncia registrada e, portanto, so tipicamente mapeados como classes. Esses
eventos esto descritos nos casos de uso e podem ter sido capturados como associaes.
Seja o exemplo de uma concessionria de automveis. Neste domnio, clientes
compram carros, como ilustra a parte (a) da Figura 5.30. Contudo, a compra um
evento importante para o negcio e precisa ser registrado. Neste caso, como ilustra a
parte (b) da Figura 5.30, a compra deve ser tratada como uma classe e no como uma
associao.
Figura 5.30 Exemplo: Associao x Classe de Evento Lembrado.

Deve-se notar pelo exemplo acima que o evento representado por uma classe,
enquanto as associaes continuam representando relacionamentos estticos entre as
classes e no operaes ou transformaes (WAZLAWICK, 2004). Assim, deve-se
tomar cuidado com a representao de eventos como associaes, questionando sempre
se aquela associao relevante para o sistema em questo.
Seja o exemplo da Figura 5.31. Nesse exemplo, o caso de uso aponta que
funcionrios so responsveis por cadastrar livros em uma biblioteca. Seria necessrio,
pois, criar uma associao Funcionrio cadastra Livro no modelo estrutural? A
resposta, na maioria dos casos, no. Apenas se explicitamente expresso pelo cliente
em um requisito que necessrio saber exatamente qual funcionrio fez o cadastro de
um dado livro (o que muito improvvel de acontecer), que tal relao deveria ser
considerada. Mesmo se houver a necessidade de auditoria de uso do sistema (requisito
no funcional relativo segurana), no h a necessidade de modelar esta associao,
pois requisitos no funcionais no devem ser considerados no modelo conceitual, uma
vez que solues bastante distintas do uso dessa associao poderiam ser adotadas.
_________________________________________________________________________________________________________
60
Figura 5.31 Exemplo: Associao x Caso de Uso.

Na modelagem conceitual fundamental saber a quantidade de objetos que uma
associao admite em cada um de seus papis, o que capturado pelas multiplicidades
da associao. Esta informao bastante dependente da natureza do problema e do real
significado da associao (o que se quer representar efetivamente), especialmente no
que se refere associao representar apenas o presente ou o histrico (WAZLAWICK,
2004).
Retomemos o exemplo da Figura 5.29, no qual se diz que um empregado est
lotado em um departamento e, opcionalmente, pode chefi-lo. Para definir precisamente
as multiplicidades, necessrio investigar os seguintes aspectos: Um empregado pode
mudar de lotao? Se sim, necessrio registrar apenas a lotao atual ou necessrio
registrar o histrico de lotaes dos empregados (ou seja, registrar o evento de lotao
de um empregado em um departamento)? Um departamento pode, ao longo do tempo,
mudar de chefe? Se sim, necessrio saber quem o histrico de chefias do
departamento (ou seja, registrar o evento de nomeao do chefe do departamento)?
Como colocado no modelo da Figura 5.29, est-se representando apenas a
situao presente. Se houver mudana de chefe de um departamento ou do
departamento de lotao de um empregado, perder-se- a informao histrica. Na
maioria das vezes, essa no uma soluo aceitvel. Na maioria dos domnios, as
pessoas querem saber a informao histrica. Assim, nota-se que parte das
responsabilidades do sistema registrar a ocorrncia dos eventos de nomeao do chefe e
de lotao de empregados. Assim, um modelo mais fidedigno a essa realidade o
modelo da Figura 5.32, o qual introduz as classes do tipo evento lembrado
NomeacaoChefia e Lotacao.
Figura 5.32 Registrando Histricos.

_________________________________________________________________________________________________________
61
Ainda que este modelo seja mais fidedigno realidade, ele ainda apresenta
problemas. Por exemplo, o modelo diz que um empregado pode ter uma ou mais
locaes. Mas o empregado pode ter mais de uma lotao vigente? O mesmo vale para o
caso da nomeao de chefia. Um empregado pode ser chefe de mais de um
departamento ao mesmo tempo? Um departamento pode ter mais do que um chefe
nomeado ao mesmo tempo? Infelizmente, o modelo incapaz de responder a essas
perguntas. Para eliminar essas ambiguidades, necessrio capturar regras de negcio do
tipo restries de integridade. No exemplo acima, as seguintes regras se aplicam:
Um empregado s pode estar lotado em um nico departamento em um dado

momento.
Um empregado s pode estar designado como chefe de um nico

departamento em um dado momento.
Um departamento s pode ter um empregado designado como chefe em um

dado momento.
Observe que, como um departamento pode ter vrios empregados nele lotados ao
mesmo tempo, no necessrio escrever uma restrio de integridade, pois este o caso
mais geral (sem restrio). Assim, restries de integridade devem ser escritas apenas
para as associaes que so passveis de restries.
Restries de integridade so regras de negcio e poderiam ser lanadas no
Documento de Requisitos. Contudo, como elas so importantes para a compreenso e
eliminao de ambiguidades do modelo conceitual, til descrev-las no prprio
modelo conceitual.
Alm das restries de integridade relativas s multiplicidades n, diversas outras
restries podem ser importantes para tornar o modelo mais fiel realidade. Ainda no
exemplo da Figura 5.32, poder-se-ia querer dizer que um empregado s pode ser
nomeado como chefe de um departamento, se ele estiver lotado nesse departamento.
Restries deste tipo so comuns em pores fechadas de um diagrama de classes.
Assim, toda vez que se detectar uma poro fechada em um diagrama de classes, vale a
pena analis-la para avaliar se h ali uma restrio de integridade ou no. Havendo,
deve-se escrev-la.
Restries de integridade tambm podem falar sobre atributos das classes. Por
exemplo, a data da portaria de nomeao de um empregado e como chefe de um
departamento d deve ser igual ou posterior data da portaria de lotao do empregado e
no departamento d.
Geralmente, restries de integridade so escritas em linguagem natural, uma
vez que no so passveis de modelagem grfica. Contudo, conforme j discutido
anteriormente, o uso de linguagem natural pode levar a ambiguidades. Visando suprir
essa lacuna na UML, o OMG15 incorporou ao padro uma linguagem para especificao
formal de restries, a OCL (Object Constraint Language). Contudo, restries escritas
em OCL dificilmente sero entendidas por clientes e usurios, o que dificulta a
validao das mesmas. Assim, neste texto, sugere-se escrever as restries de
integridade em linguagem natural mesmo.
15
Object Management Group (http://www.omg.org/) uma organizao internacional que gerencia

padres abertos relativos ao desenvolvimento orientado a objetos, dentre eles a UML.
_________________________________________________________________________________________________________
62
Vale ressaltar que a UML prov alguns mecanismos para representar restries
de integridade em um modelo grfico. As prprias multiplicidades so uma forma de
capturar restries de integridade (ditas restries de integridade de cardinalidade).
Alm das multiplicidades, a UML prov o recurso de restries, as quais so
representadas entre chaves ({restrio}). Restries podem ser usadas, dentre outros,
para restringir a ocorrncia de associaes. Seja o seguinte exemplo: em uma
concessionria de automveis compras podem ser financiadas ou por financeiras ou por
bancos. Para capturar essa restrio, pode-se usar a restrio xor da UML, como ilustra
a Figura 5.33.
Figura 5.33 Restrio XOR entre Associaes.

Nesta figura, uma compra ou est relacionada a um banco ou a uma financeira.
No possvel que uma compra esteja associada aos dois ao mesmo. Como as
multiplicidades mnimas do lado de banco e financeira so zero, uma compra pode no
ser financiada.
Ainda em relao s multiplicidades, vale frisar que associaes muitos-paramuitos so perfeitamente legais em um modelo orientado a objetos, como ilustra o
exemplo da Figura 5.34. Nesse exemplo, est-se dizendo que disciplinas podem possuir
vrios pr-requisitos e podem ser pr-requisitos para vrias outras disciplinas.
Figura 5.34 Associao Muitos-para-Muitos.

Deve-se observar, no entanto, que muitas vezes, uma associao muitos-paramuitos oculta a necessidade de uma classe do tipo evento a ser lembrado. Seja o
seguinte exemplo: em uma organizao, empregados so alocados a projetos. Um
empregado pode ser alocado a vrios projeto, enquanto um projeto pode ter vrios
empregados a ele alocados. Tomando por base este fato, seria natural se chegar ao
modelo da Figura 5.35(a). Contudo, se quisermos registrar as datas de incio e fim do
perodo em que o empregado esteve alocado ao projeto, esse modelo insuficiente e
deve ser alterado para comportar uma classe do tipo evento lembrado Alocacao, como
mostra a Figura 5.35(b).
_________________________________________________________________________________________________________
63
Figura 5.35 Associao Muitos-para-Muitos e Classes de Evento Lembrado.

De fato, o problema por detrs do modelo da Figura 5.35(a) o mesmo
anteriormente discutido na Figura 5.32: a necessidade ou no de se representar
informao histrica. Contudo, de maneira mais abrangente, pode-se pensar que se uma
associao apresenta atributos, melhor trat-la como uma nova classe. Seja o seguinte
exemplo: em uma loja, um cliente efetua um pedido, discriminando vrios produtos,
cada um deles em uma certa quantidade. O modelo da Figura 5.36(a) procura
representar essa situao, mas uma questo permanece em aberto: onde representar a
informao da quantidade pedida de cada produto? Essa informao no pode ficar em
Produto, pois diferentes pedidos pedem quantidades diferentes de um mesmo produto.
Tambm no pode ficar em Pedido, pois um mesmo pedido tipicamente especifica
diferentes quantidades de diferentes produtos. De fato, quantidade no nem um
atributo da classe Pedido nem um atributo da classe Produto, mas sim um atributo da
associao especifica. Assim, uma soluo possvel introduzir uma classe ItemPedido,
reificando16 essa associao, como ilustra a Figura 5.36(b).
Figura 5.36 Reificando uma Associao.

A UML oferece uma primitiva de modelagem, chamada classe de associao,
que pode ser usada para tratar a reificao de associaes (OLIV, 2007). Uma classe
de associao pode ser vista como uma associao que tem propriedades de classe
(BOOCH; RUMBAUGH; JACOBSON, 2006). A Figura 6.12 mostra o exemplo
anterior, sendo modelado como uma classe de associao, segundo a notao da UML.
16
Reificar uma associao consiste em ver essa associao como uma classe. A palavra reificao vem
da palavra do latim res, que significa coisa. Reificao corresponde ao que em linguagem natural se
chama nominalizao, que basicamente consiste em transformar um verbo em um substantivo (OLIV,
2007).
_________________________________________________________________________________________________________
64
Figura 5.37 Notao da UML para Classes Associativas.

Classes associativas so ainda representaes de associaes. Assim como uma
instncia de uma associao, uma instncia de uma classe associativa um par ordenado
conectando duas instncias das classes envolvidas na associao. Assim, se Pedido100
uma instncia de Pedido, Lpis uma instncia de Produto e o Pedido100 especifica 5
Lpis, ento uma instncia de ItemPedido a tupla ((Pedido100, Lpis), 5).
Classes associativas podem ser usadas tambm para representar eventos cuja
ocorrncia precisa ser lembrada, como nos exemplos das figuras 5.32 e 5.35. Entretanto,
importante observar que o uso de classes associativas nesses casos pode levar a
problemas de modelagem. Seja o seguinte contexto: em um hospital, pacientes so
tratados em unidades mdicas. Um paciente pode ser tratado em diversas unidades
mdicas diferentes, as quais podem abrigar diversos pacientes sendo tratados. A Figura
5.38(a) mostra um modelo que busca representar essa situao usando uma classe de
associao. Como uma classe associativa, as instncias de Tratamento so pares
ordenados (Paciente, Unidade Mdica). Assim, cada vez que um paciente tratado em
uma unidade mdica diferente tem-se um tratamento. Essa pode, contudo, no ser
precisamente a concepo do problema original. Poder-se-ia imaginar que um
tratamento um tratamento de um paciente em vrias unidades mdicas. A classe de
associao no captura isso. Assim, um modelo mais fiel ao domnio aquele que
representa Tratamento como uma classe do tipo evento a ser lembrado e que est
relacionada com Paciente e Unidade Mdica da forma mostrada na Figura 5.38(b).
Figura 5.38 Classes Associativas x Classes do Tipo Evento a Ser Lembrado.

At o momento, todas as associaes mostradas foram associaes binrias, i.e.,
associaes envolvendo duas classes. Mesmo o exemplo da Figura 5.34 (Disciplina tem
como pr-requisito Disciplina) ainda uma associao binria, na qual a mesma classe
_________________________________________________________________________________________________________
65
desempenha dois papis diferentes (disciplina que possui pr-requisito e disciplina que
pr-requisito). Entretanto, associaes n-rias so tambm possveis, ainda que bem
menos corriqueiramente encontradas. Uma associao ternria, por exemplo, envolve
trs classes, como ilustra o exemplo da Figura 5.39. Nesse exemplo, est-se dizendo que
fornecedores podem fornecer produtos para certos clientes.
Figura 5.39 Associao Ternria.

Na UML, associaes n-rias so mostradas como losangos conectados s
classes envolvidas na associao por meio de linhas slidas, como mostra a Figura 5.39.
O nome da associao colocado dentro ou em cima do losango, sem direo de leitura.
Normalmente, multiplicidades no so mostradas, dada a dificuldade de interpret-las.
Finalmente, algumas associaes podem ser consideradas mais fortes do que as
outras, no sentido de que elas, na verdade, definem um objeto como sendo composto
por outros (WAZLAWICK, 2004). Essas associaes todo-parte podem ser de dois
tipos principais: agregao e composio.
A composio o tipo mais forte de associao todo-parte. Ela indica que um
objeto-parte s pode ser parte de um nico todo. J a agregao no implica nessa
exclusividade. Um carro, por exemplo, tem como partes um motor e quatro ou cinco
rodas. Motor e rodas, ao serem partes de um carro, no podem ser partes de outros
carros simultaneamente. Assim, esta uma relao de composio, como ilustra a
Figura 5.40(a). O exemplo da Figura 5.40(b) ilustra o caso de comisses compostas por
professores. Nesse caso, um professor pode participar de mais de uma comisso
simultaneamente e, portanto, trata-se uma relao de agregao. Na UML, um losango
branco na extremidade da associao relativa ao todo indica uma agregao. J um
losango preto indica uma composio.
Figura 5.40 Agregao e Composio.
_________________________________________________________________________________________________________
66
Relaes todo-parte podem ser empregadas em situaes como:
Quando h clareza de que um objeto complexo composto de outros objetos

(componente de). Ex.: Motor um componente de um carro.
Para designar membros de colees (membro de). Ex.: Pesquisadores so

membros de Grupos de Pesquisa.
Muitas vezes pode ser difcil perceber a diferena entre uma agregao /
composio e uma associao comum. Quando houver essa dvida, melhor
representar a situao usando uma associao comum, tendo em vista que ela impe
menos restries.
5.5.3 Especificao de Hierarquias de Generalizao / Especializao
Um dos principais mecanismos de estruturao de conceitos a generalizao /
especializao. Com este mecanismo possvel capturar similaridades entre classes,
dispondo-as em hierarquias de classes. No contexto da orientao a objetos, esse tipo de
relacionamento tambm conhecido como herana.
importante notar que a herana tem uma natureza bastante diferente das
associaes. Associaes representam possveis ligaes entre instncias das classes
envolvidas. J a relao de herana uma relao entre classes e no entre instncias.
Ao se considerar uma classe B como sendo uma subclasse de outra classe A est-se
assumindo que todas as instncias de B so tambm instncias de A. Assim, ao se dizer
que a classe EstudanteGraduacao herda da classe Estudante, est-se indicando que
todos os estudantes de graduao so estudantes. Em resumo, deve-se interpretar a
relao de herana como uma relao de subtipo entre classes. A Figura 5.41 mostra a
notao da UML para representar herana.
Figura 5.41 Notao de Herana da UML.

A relao de herana aplicvel quando for necessrio fatorar os elementos de
informaes (atributos e associaes) de uma classe. Quando um conjunto de classes
possuir semelhanas e diferenas, ento elas podem ser organizadas em uma hierarquia
de classes, de forma a agrupar em uma superclasse os elementos de informao comuns,
deixando as especificidades nas subclasses.
De maneira geral, no faz sentido criar hierarquias de classes, quando as
especializaes (subclasses) no tiverem nenhum elemento de informao diferente.
Quando isso ocorrer, normalmente suficiente criar um atributo tipo, para indicar os
possveis subtipos da generalizao. Seja o caso de um domnio em que se faz distino
entre clientes normais e clientes especiais, dos quais se quer saber exatamente as
mesmas informaes. Neste caso, criar uma hierarquia de classes, como ilustra a Figura
_________________________________________________________________________________________________________
67
5.42(a), desnecessrio. Uma soluo como a apresentada na Figura 5.42(b), em que o

atributo tipo pode ser de um tipo enumerado com os seguintes valores {Normal,
Especial}, modela satisfatoriamente o problema e mais simples e, portanto, mais
indicada.
Figura 5.42 Uso ou no de Herana.

Tambm no faz sentido criar uma hierarquia de classes em que a superclasse
no tem nenhum atributo ou associao. Informaes de estados pelos quais um objeto
passa tambm no devem ser confundidas com subclasses. Por exemplo, um carro de
uma locadora de automveis pode estar locado, disponvel ou em manuteno. Estes so
estados e no subtipos de carro.
De fato, interessante considerar alguns critrios para incluir uma subclasse (ou
superclasse) em um modelo conceitual. O principal deles o fato da especializao (ou
generalizao) estar dentro do domnio de responsabilidade do sistema. Apenas
subclasses (superclasses) relevantes para o sistema em questo devem ser consideradas.
Alm desse critrio bsico, os seguintes critrios devem ser usados para analisar
hierarquias de herana:
Uma hierarquia de classes deve modelar relaes -um-tipo-de, ou seja,

toda subclasse deve ser um subtipo especfico de sua superclasse.
Uma subclasse deve possuir todas as propriedades (atributos e associaes)
definidas por suas superclasses e adicionar mais alguma coisa (algum outro
atributo ou associao).
Todas as instncias de uma subclasse tm de ser tambm instncias da
superclasse.
Ateno especial deve ser dada nomeao de classes em uma hierarquia de

classes. Cada especializao deve ser nomeada de forma a ser auto-explicativa. Um
nome apropriado para a especializao pode ser formado pelo nome de sua superclasse,
_________________________________________________________________________________________________________


68
acompanhado por um qualificador que descreve a natureza da especializao. Por

exemplo, EstudanteGraduacao para designar um subtipo de Estudante.
Hierarquias de classes no devem ser usadas de forma no criteriosa,
simplesmente para compartilhar algumas propriedades. Seja o caso de uma loja de
animais, em que se deseja saber as seguintes informaes sobre clientes e animais:
nome, data de nascimento e endereo. No faz nenhum sentido considerar que Cliente
uma subclasse de Animal ou vice-versa, apenas para reusar um conjunto de atributos
que, coincidentemente, igual.
No que se refere modelagem de superclasses, deve-se observar se uma
superclasse concreta ou abstrata. Se a superclasse puder ter instncias prprias, que
no so instncias de nenhuma de suas subclasses, ento ela uma classe concreta. Por
outro lado, se no for possvel instanciar diretamente a superclasse, ou seja, se todas as
instncias da superclasse so antes instncias das suas subclasses, ento a superclasse
abstrata. Classes abstratas so representadas na UML com seu nome escrito em itlico e
no devem herdar de classes concretas.
Quando modeladas hierarquias de herana, necessrio posicionar atributos e
associaes adequadamente. Cada atributo ou associao deve ser colocado na classe
mais adequada. Atributos e associaes genricos, que se aplicam a todas as subclasses,
devem ser posicionados no topo da estrutura, de modo a serem aplicveis a todas as
especializaes. De maneira mais geral, se um atributo ou associao aplicvel a um
nvel inteiro de especializaes, ento ele deve ser posicionado na generalizao
correspondente. Por outro lado, se algumas vezes um atributo ou associao tiver um
valor significativo, mas em outras ele no for aplicvel, deve-se rever seu
posicionamento ou mesmo a estrutura de generalizao-especializao adotada.
Inevitavelmente, o processo detalhado de designar atributos e associaes a
classes conduz a um entendimento mais completo da hierarquia de herana do que era
possvel em um estgio anterior. Assim, deve-se esperar que o trabalho de
reposicionamento de atributos e associaes conduza a uma reviso de uma hierarquia
de classes.
Por fim vale a pena mencionar que, durante anos, o mecanismo de herana foi
considerado o grande diferencial da orientao a objetos. Contudo, com o passar do
tempo, essa nfase foi perdendo fora, pois se percebeu que o uso da herana nem
sempre conduz melhor soluo de um problema de modelagem. Hoje a herana
considerada apenas mais uma ferramenta de modelagem, utilizada basicamente para
fatorar informaes, as quais, de outra forma, ficariam repetidas em diferentes classes
(WAZLAWICK, 2004).
5.6 - Modelagem Dinmica

Um sistema de informao realiza aes. O efeito de uma ao pode ser uma
alterao em sua base de informao e/ou a comunicao de alguma informao ou
comando para um ou mais destinatrios. Um evento de requisio de ao (ou
simplesmente uma requisio) uma solicitao para o sistema realizar uma ao. O
esquema comportamental de um sistema visa especificar essas aes (OLIV, 2007).
Uma parte importante do modelo comportamental de um sistema o modelo de
casos de uso, o qual fornece uma viso das funcionalidades que o sistema deve prover.
O modelo conceitual estrutural define os tipos de entidades (classes) e de
_________________________________________________________________________________________________________


69
relacionamentos (atributos e associaes) do domnio do problema que o sistema deve

representar para poder prover as funcionalidades descritas no modelo de casos de uso.
Durante a realizao de um caso de uso, atores geram eventos de requisio de aes
para o sistema, solicitando a execuo de alguma ao. O sistema realiza aes e ele
prprio pode gerar outras requisies de ao. necessrio, pois, modelar essas
requisies de aes, as correspondentes aes a serem realizadas pelo sistema e seus
efeitos. Este o propsito da modelagem dinmica.
Em uma abordagem orientada a objetos, requisies de ao correspondem a
mensagens trocadas entre objetos. As aes propriamente ditas e seus efeitos so
tratados pelas operaes das classes17. Assim, a modelagem dinmica est relacionada
com as trocas de mensagens entre objetos e a modelagem das operaes das classes.
Os diagramas de classes gerados pela atividade de modelagem conceitual
estrutural representam apenas os elementos estticos de um modelo de anlise orientada
a objetos. preciso, ainda, modelar o comportamento dinmico da aplicao. Para tal,
necessrio representar o comportamento do sistema como uma funo do tempo e de
eventos especficos. Um modelo de dinmico indica como o sistema ir responder a
eventos ou estmulos externos e auxilia o processo de descoberta das operaes das
classes do sistema.
Para apoiar a modelagem da dinmica de sistemas, a UML oferece trs tipos de
diagramas (BOOCH; RUMBAUGH; JACOBSON, 2006): Diagrama de Grfico de
Estados, Diagrama de Interao e Diagrama de Atividades. Neste material discutida
apenas a modelagem de estados.
5.6.1 Diagrama de Estados
Um diagrama de estados mostra uma mquina de estados que consiste dos
estados pelos quais objetos de uma particular classe podem passar ao longo de seu ciclo
de vida e as transies possveis entre esses estados, as quais so resultados de eventos
que atingem esses objetos. Diagramas de grfico de estados (ou diagramas de
transio de estados) so usados principalmente para modelar o comportamento de
uma classe, dando nfase ao comportamento especfico de seus objetos.
Classes com estados (ou modais) so classes cujas instncias podem mudar de
um estado para outro ao longo de sua existncia, mudando possivelmente sua estrutura,
seus valores de atributos ou comportamento dos mtodos (WAZLAWICK, 2004).
Classes modais podem ser modeladas como mquinas de estados finitos. Uma
mquina de estados finitos uma mquina que, em um dado momento, est em um e
somente um de um nmero finito de estados (OLIV, 2007). Os estados de uma
mquina de estados de uma classe modal correspondem s situaes relevantes em que
as instncias dessa classe podem estar durante sua existncia. Um estado considerado
relevante quando ele ajuda a definir restries ou efeitos dos eventos.
Em qualquer estado, uma mquina de estados pode receber estmulos. Quando a
mquina recebe um estmulo, ela pode realizar uma transio de seu estado corrente
(dito estado origem) para um outro estado (dito estado destino), sendo que se assume
17
De fato, abordagens distintas podem ser usadas, tal como representar tipos de requisies como classes,
ditas classes de evento, e os seus efeitos como operaes das correspondentes classes de evento, tal como
faz Oliv (2007).
_________________________________________________________________________________________________________
70
que as transies so instantneas. A definio do estado destino depende do estado

origem e do estmulo recebido. Alm disso, os estado origem e destino em uma
transio podem ser o mesmo. Neste caso, a transio dita uma autotransio (OLIV,
2007).
Diagramas de Transies de Estados so usados modelar o comportamento de
instncias de uma classe modal como uma mquina de estados. Todas as instncias da
classe comportam-se da mesma maneira. Em outras palavras, cada diagrama de estados
construdo para uma nica classe, com o objetivo de mostrar o comportamento ao
longo do tempo de vida de seus objetos. Diagramas de estados descrevem os possveis
estados pelos quais objetos da classe podem passar e as alteraes dos estados como
resultado de eventos (estmulos) que atingem esses objetos. Uma mquina de estado
especifica a ordem vlida dos estados pelos quais os objetos da classe podem passar ao
longo de seu ciclo de vida. A Figura 5.43 mostra a notao bsica da UML para
diagramas de grfico de estados.
Figura 5.43 - Notao Bsica da UML para Diagramas de Grfico de Estados.

Um estado uma situao na vida de um objeto durante a qual o objeto satisfaz
alguma condio, realiza alguma atividade ou aguarda a ocorrncia de um evento
(BOOCH; RUMBAUGH; JACOBSON, 2006). Estados so representados por
retngulos com os cantos arredondados, sendo que o nome de um estado deve ser nico
em uma mquina de estados. Uma regra prtica para nomear estados consiste em
atribuir um nome tal que sejam significativas sentenas do tipo o <<objeto>> est
<<nome do estado>> ou o <<objeto>> est no estado <<nome do estado>>. Por
exemplo, em um sistema de locadora de automveis, um estado possvel de objetos da
classe Carro seria Disponvel. A sentena o carro est disponvel tem um
significado claro (OLIV, 2007).
Quando um objeto fica realizando uma atividade durante todo o tempo em que
permanece em um certo estado, deve-se indicar essa atividade no compartimento de
aes do respectivo estado. importante realar que uma atividade tem durao
significativa e, quando concluda, tipicamente a concluso provoca uma transio para
um novo estado. A notao da UML para representar atividades de um estado : do /
<<nomeAtividade>>.
Transies so representadas por meio de setas rotuladas. Uma transio envolve
um estado origem, um estado destino e normalmente um evento, dito o gatilho da
transio. Quando a mquina de estados se encontra no estado origem e recebe o evento
_________________________________________________________________________________________________________
71
gatilho, ento o evento dispara a transio e a mquina de estados vai para o estado
destino. Se uma mquina recebe um evento que no um gatilho para nenhuma
transio, ento ela no afetada pelo evento (OLIV, 2007).
Uma transio pode ter uma condio de guarda associada. s vezes, h duas ou
mais transies com o mesmo estado origem e o mesmo evento gatilho, mas com
condies de guarda diferentes. Neste caso, a transio disparada somente quando o
evento gatilho ocorre e a condio de guarda verdadeira (OLIV, 2007). Quando uma
transio no possuir uma condio de guarda associada, ento ela ocorrer sempre que
o evento ocorrer.
Por fim, quando uma transio disparada, uma ao instantnea pode ser
realizada. Assim, o rtulo de uma transio pode ter at trs partes, todas elas opcionais:
evento [condioGuarda] / ao
Basicamente, a semntica de um diagrama de estados a seguinte: quando o
evento ocorre, se a condio de guarda verdadeira, a transio dispara e a ao
realizada instantaneamente. O objeto passa, ento, do estado origem para o estado
destino. Se o estado destino possuir uma atividade a ser realizada, ela iniciada.
O fato de uma transio no possuir um evento associado normalmente aponta
para a existncia de um evento implcito. Isso tipicamente ocorre em trs situaes: (i) o
evento implcito a concluso da atividade do estado origem e a transio ocorrer to
logo a atividade associada ao estado origem tiver sido concluda; (ii) o evento implcito
temporal, sendo disparado pela passagem do tempo; (iii) o evento implcito torna a
condio de guarda verdadeira na base de informaes do sistema, mas o evento em si
no modelado.
Embora ambos os termos ao e atividade denotem processos, eles no devem
ser confundidos. Aes so consideradas processos instantneos; atividades, por sua
vez, esto sempre associadas a estados e tm durao no tempo. Vale a pena observar
que, no mundo real, no h processos efetivamente instantneos. Por mais rpida que
seja, uma ao ocorrer sempre em um intervalo de tempo. Esta simplificao de se
considerar aes instantneas no modelo conceitual pode ser associada ideia de que a
ao ocorre to rapidamente que no possvel interromp-la. Em contraste, uma
atividade passvel de interrupo, sendo possvel, por exemplo, que um evento ocorra,
interrompa a atividade e provoque uma mudana no estado do objeto antes da concluso
da atividade.
s vezes quer se modelar situaes em que uma ao instantnea realizada
quando se entra ou sai de um estado, qualquer que seja a transio que o leve ou o retire
desse estado. Seja o exemplo de um elevador. Neste contexto, ao parar em um certo
andar, o elevador abre a porta. Suponha que a abertura da porta do elevador seja um
processo que no possa ser interrompido e, portanto, que se opte por model-lo como
uma ao. Essa ao dever ocorrer sempre que o elevador entrar no estado Parado e
deve ser indicada no compartimento de aes desse estado como sendo uma ao de
entrada no estado. A notao da UML para representar aes de entrada em um estado
: entry / <<nomeAo>>. Para representar aes de sada de um estado a notao :
exit / <<nomeAo>>.
Restam ainda na Figura 5.43 dois tipos especiais de estados: os ditos estados
inicial e final. Conforme citado anteriormente, um objeto est sempre em um e somente
um estado. Isso implica que, ao ser instanciado, o objeto precisa estar em algum estado.
_________________________________________________________________________________________________________
72
O estado inicial precisamente esse estado. Graficamente, um estado inicial mostrado

como um pequeno crculo preenchido na cor preta. Seu significado o seguinte: quando
o objeto criado, ele colocado no estado inicial e sua transio de sada
automaticamente disparada, movendo o objeto para um dos estados da mquina de
estados (no caso da Figura 5.43, para o Estado1). Toda mquina de estados tem de ter
um (e somente um) estado inicial. Note que o estado inicial no se comporta como um
estado normal18, uma vez que objetos no se mantm nele por um perodo de tempo. Ao
contrrio, uma vez que eles entram no estado inicial, sua transio de sada
imediatamente disparada e o estado inicial abandonado. A transio de sada do estado
inicial tem como evento gatilho implcito o evento responsvel pela criao do objeto
(OLIV, 2007) e, na UML, esse evento no explicitamente representado. Estados
iniciais tm apenas transies de sada. As transies de sada de um estado inicial
podem ter condies de guarda e/ou aes associadas. Quando houver condies de
guarda, deve-se garantir que sempre pelo menos uma das transies de sada poder ser
disparada.
Quando um objeto deixa de existir, obviamente ele deixa de estar em qualquer
um dos estados. Isso pode ser dito no diagrama por meio de uma transio para o estado
final. O estado final indica, na verdade, que o objeto deixou de existir. Na UML um
estado final representado como um crculo preto preenchido com outro crculo no
preenchido ao seu redor, como mostra a Figura 5.43. As transies para o estado final
definem os estados em que possvel excluir o objeto. Classes cujos objetos no podem
ser excludos, portanto, no possuem um estado final (OLIV, 2007). Assim como o
estado inicial, o estado final no se comporta como um estado normal, uma vez que o
objeto tambm no permanece nesse estado (j que o objeto no existe mais). Ao
contrrio do estado inicial, contudo, uma mquina de estados pode ter vrios estados
finais. Alm disso, deve-se representar o evento que elimina o objeto (na Figura 5.43,
eventoDestruio).
importante indicar no diagrama de estados os eventos maiores (eventos de
domnio e requisies de aes) e no os eventos estruturais que efetivamente alteram o
estado do objeto. Assim, neste texto sugere-se indicar como eventos de transies de
uma mquina de estados as requisies de realizao de casos de uso do sistema (ou de
fluxos de eventos especficos, quando um caso de uso tiver mais de um fluxo de eventos
normal). Para facilitar a rastreabilidade, sugere-se usar como nome do evento
exatamente o mesmo nome do caso de uso (ou do fluxo de eventos). Seja o exemplo de
uma locadora de automveis, que possua, dentre outros, os casos de uso mostrados na
Figura 5.44, os quais possuem os fluxos de eventos mostrados nas notas anexadas aos
casos de uso.
18
Por no se comportar como um estado normal, o estado inicial considerado um pseudoestado no

metamodelo da UML.
_________________________________________________________________________________________________________
73
Figura 5.44 Locadora de Automveis - Casos de Uso e Fluxos de Eventos

Associados.
A classe Carro tem o seu comportamento definido pela mquina de estados do
diagrama de grfico de estados da Figura 5.45. Ao ser adquirido (fluxo de eventos
Comprar Carro, do caso de uso Negociar Carro), o carro colocado Em Preparao.
Quando liberado para uso (fluxo de eventos Liberar Carro para Uso, do caso de uso
Efetuar Manuteno de Carro), o carro fica Disponvel. Quando o cliente retira o carro
(fluxo de eventos Retirar Carro, do caso de uso Efetuar Locao), este fica Em Uso.
Quando devolvido (fluxo de eventos Devolver Carro, do caso de uso Efetuar
Locao), o carro fica novamente Em Preparao. Quando Disponvel, um carro pode
ser transferido de uma localidade para outra (fluxo de eventos Transferir Carro para
Outra Localidade do caso de uso Transferir Carro). Durante o trnsito de uma
localidade para outra, o carro est Em Trnsito, at ser recebido na localidade destino
(fluxo de eventos Receber Carro Vindo de Outra Localidade, do caso de uso Transferir
Carro), quando novamente colocado Em Preparao. Finalmente, carros Em
Preparao podem ser vendidos (fluxo de eventos Vender Carro, do caso de uso
Negociar Carro), quando deixam de pertencer locadora e so eliminados de sua base
de informaes.
_________________________________________________________________________________________________________


74
Figura 5.45 Diagrama de Grfico de Estados da Classe Carro Disponibilidade

(adaptado de (OLIV, 2007)).
Nem todas as classes precisam ser modeladas como mquinas de estados.
Apenas classes modais, i.e., que apresentam comportamento varivel em funo do
estado de seus objetos, necessitam ser modeladas como mquinas de estados. Alm
disso, para os diagramas de estados serem efetivamente teis, recomenda-se modelar
uma mquina de estados somente se a classe em questo tiver trs ou mais estados
relevantes. Se uma classe possuir apenas dois estados relevantes, ainda cabe
desenvolver uma mquina de estados. Contudo, de maneira geral, o diagrama tende a
ser muito simples e a acrescentar pouca informao relevante que justifique o esforo de
elaborao e manuteno do correspondente diagrama. Neste caso, os estados e
transies podem ser levantados, sem no entanto elaborar um diagrama de estados.
Para algumas classes, pode ser til desenvolver mais do que um diagrama de
estados, cada qual modelando o comportamento dos objetos da classe por uma
perspectiva diferente. Em um determinado momento, um objeto est em um (e somente
um) estado em cada uma de suas mquinas de estado. Cada diagrama define seu prprio
conjunto de estados nos quais um objeto pode estar, a partir de diferentes pontos de
vista (OLIV, 2007). Seja novamente o exemplo da classe Carro. A Figura 5.45 mostra
os possveis estados de um carro segundo um ponto de vista de disponibilidade.
Entretanto, independentemente da disponibilidade, do ponto de vista de
negociabilidade, um carro pode estar em dois estados (No Venda, Venda), como
mostra a Figura 5.46.
Vale ressaltar que os diferentes diagramas de estados de uma mesma classe no
devem ter estados comuns. Cada diagrama deve ter seu prprio conjunto de estados e
cada estado pertence a somente um diagrama de estados. J os eventos podem aparecer
em diferentes diagramas de estados, inclusive de classes diferentes. Quando um evento
aparecer em mais de um diagrama de estados, sua ocorrncia vai disparar as
_________________________________________________________________________________________________________


75
correspondentes transies em cada uma das mquinas de estados em que ele aparecer
(OLIV, 2007).
Figura 5.46 Diagrama de Grfico de Estados da Classe Carro Negociabilidade

(adaptado de (OLIV, 2007)).
A Figura 5.46 mostra duas transies em que os eventos no so declarados
explicitamente. No primeiro caso (quilometragem > 50000Km), o evento implcito
torna a condio de guarda verdadeira na base de informaes do sistema. Esse evento
corresponde ao registro no sistema de qual a quilometragem corrente do carro. Caso
esse registro ocorra sempre no ato da devoluo do carro pelo cliente (fluxo de eventos
Devolver Carro, do caso de uso Efetuar Locao) e/ou no ato do recebimento do carro
vindo de outra localidade (fluxo de eventos Receber Carro Vindo de Outra Localidade,
do caso de uso Transferir Carro), esses eventos poderiam ser explicitamente
declarados. Contudo, se o registro pode ocorrer em vrios eventos diferentes, melhor
deixar o evento implcito. O segundo caso (dataCorrente dataAquisicao > 1 ano) tratase de um evento temporal, disparado pela passagem do tempo.
Todos os estados mostrados at ento so estados simples, i.e., estados que no
possuem subestados. Entretanto, h tambm estados compostos, os quais podem ser
decompostos em um conjunto de subestados disjuntos e mutuamente exclusivos e um
conjunto de transies (OLIV, 2007). Um subestado um estado aninhado em outro
estado. O uso de estados compostos e subestados bastante til para simplificar a
modelagem de comportamentos complexos. Seja o exemplo da Figura 5.45, que trata da
disponibilidade de um carro. Suponha que seja necessrio distinguir trs subestados do
estado Em Uso, a saber: Em Uso Normal, quando o carro no est quebrado nem em
atraso; Quebrado, quando o cliente reportar um defeito no carro; e Em Atraso, quando o
carro no foi devolvido na data de devoluo prevista e no est quebrado. A Figura
5.47 mostra a mquina de estados da classe Carro considerando, agora, que, quando um
carro est em uso, ele pode estar nesses trs subestados.
_________________________________________________________________________________________________________
76
Figura 5.47 Diagrama de Estados da Classe Carro (Disponibilidade) com

Subestados de Em Uso (adaptado de (OLIV, 2007)).
Nesse diagrama, no est sendo mostrado que os estados Em Uso Normal, Em
Atraso e Quebrado so, de fato, subestados do estado Em Uso e, portanto, transies
comuns (por exemplo, aquelas provocadas pelo evento Devolver Carro) so repetidas.
Isso torna o modelo mais complexo e fica claro que esta soluo representando
diretamente os subestados (e omitindo o estado composto) no escalvel para sistemas
que possuem muitos subestados, levando a diagramas confusos e desestruturados
(OLIV, 2007). A Figura 5.48 mostra uma soluo mais indicada, em que tanto o
estado composto quanto seus subestados so mostrados no mesmo diagrama. Uma outra
opo ocultar a decomposio do estado composto, mantendo o diagrama como o
mostrado na Figura 5.45, e mostrar essa decomposio em um diagrama de estados
separado.
Se um objeto est em um estado composto, ento ele deve estar tambm em um
de seus subestados. Assim, um estado composto pode possuir um estado inicial para
indicar o subestado padro do estado composto, como representado na Figura 5.48.
Entretanto, deve-se considerar que as transies podem comear e terminar em qualquer
nvel. Ou seja, uma transio pode ir (ou partir) diretamente de um subestado (OLIV,
2007). Assim, uma outra opo para o diagrama da Figura 5.48 seria fazer a transio
nomeada pelo evento Retirar Carro chegar diretamente ao subestado Em Uso Normal,
ao invs de chegar ao estado composto Em Uso.
_________________________________________________________________________________________________________


77
Figura 5.48 Diagrama de Estados da Classe Carro (Disponibilidade) com Estado

Composto Em Uso (adaptado de (OLIV, 2007)).
O estado de um objeto deve ser mapeado no esquema estrutural. De maneira
geral, o estado pode ser modelado por meio de um atributo. Esse atributo deve ser
monovalorado e obrigatrio ([1..1]). O conjunto de valores possveis do atributo o
conjunto dos estados possveis, conforme descrito pela mquina de estados (OLIV,
2007). Assim, bastante natural que o tipo de dados desse atributo seja definido como
um tipo de dados enumerado. Um nome adequado para esse atributo estado.
Contudo, outros nomes mais significativos para o domnio podem ser atribudos. Em
especial, quando uma classe possuir mais do que uma mquina de estado e, por
conseguinte, mais do que um atributo de estado for necessrio, o nome do atributo de
estado deve indicar a perspectiva capturada pela correspondente mquina de estados.
interessante observar que algumas transies podem mudar a estrutura da
classe. Quando os diferentes estados de um objeto no afetam a sua estrutura, mas
apenas, possivelmente, os valores de seus atributos e associaes, diz-se que a transio
estvel e os diferentes estados podem ser mapeados para um simples atributo
(WAZLAWICK, 2004), conforme discutido anteriormente.
_________________________________________________________________________________________________________
78
Entretanto, h situaes em que, conforme um objeto vai passando de um estado

para outro, ele vai ganhando novos atributos ou associaes, ou seja, h uma mudana
na estrutura da classe. Seja o exemplo de uma locao de carro. Como mostra a Figura
5.49, quando uma locao criada, ela est ativa, em curso normal. Quando o carro no
devolvido at a data de devoluo prevista, a locao passa a ativa com prazo
expirado. Se a locao estendida, ela volta a ficar em curso normal. Quando o carro
devolvido, a locao fica pendente. Finalmente, quando o pagamento efetuado, a
locao concluda.
Figura 5.49 Diagrama de Estados da Classe Locao.

Locaes ativas (e em seus subestados, obviamente) tm como atributos: data de
locao, data de devoluo prevista, valor devido e cauo. Quando no estado pendente,
necessrio registrar a data de devoluo efetiva e os problemas observados no carro
devolvido. Finalmente, quando o pagamento efetuado, preciso registrar a data do
pagamento, o valor e a forma de pagamento. Diz-se que as transies dos estados de
Ativa para Pendente e de Pendente para Concluda so monotnicas19, porque a cada
mudana de estado, novos relacionamentos (atributos ou associaes) so acrescentados
(mas nenhum retirado).
Uma soluo frequentemente usada para capturar essa situao no modelo
conceitual estrutural consiste em criar uma nica classe (Locacao) e fazer com que
certos atributos sejam nulos at que o objeto mude de estado, como ilustra a Figura
5.50. Essa forma de modelagem, contudo, pode no ser uma boa opo, uma vez que
gera classes complexas com regras de consistncia que tm de ser verificadas muitas
vezes para evitar a execuo de um mtodo que atribui um valor a um atributo
especfico de um estado (WAZLAWICK, 2004), tal como dataPagamento.
19
Monotnico diz respeito a algo que ocorre de maneira contnua. Neste caso, a continuidade advm do
fato de um objeto continuamente ganhar novos atributos e associaes, sem perder os que j possua.
_________________________________________________________________________________________________________
79
Figura 5.50 Classe Locao com atributos inerentes a diferentes estados.

possvel modelar essa situao desdobrando o conceito original em trs: um
representando a locao efetivamente, outro representando a devoluo e outro
representando o pagamento. Desta forma, captura-se claramente os eventos de locao,
devoluo e pagamento, colocando as informaes de cada evento na classe
correspondente, como ilustra a Figura 5.51.
Figura 5.51 Distribuindo as responsabilidades.

Finalmente, vale pena comentar que estados de uma classe modal podem ser
tratados por meio de operaes ao invs de atributos. Seja o exemplo anterior de
locaes de carros (Figura 5.51). O estado de uma locao pode ser computado a partir
dos atributos e associaes da classe Locacao, sem haver a necessidade de um atributo
estado. Se uma locao no tem uma devoluo associada, ento ela est ativa. Estando
ativa, se a data corrente menor ou igual data de devoluo prevista, ento a locao
est em curso normal; caso contrrio, ela est com prazo expirado. Se uma locao
possui uma devoluo, mas no possui um pagamento associado, ento ela est
pendente. Finalmente, se a locao possui um pagamento associado, ento ela est
concluda. Em casos como este, pode-se optar por tratar estado como uma operao e
no como um atributo. Opcionalmente, pode-se utilizar a operao para calcular o valor
de um atributo derivado20 estado. Atributos derivados so representados na UML
precedidos por uma barra (no exemplo, /estado).
20
Um atributo derivado quando seu valor pode ser deduzido ou calculado a partir de outras informaes
(atributos e associaes) j existentes no modelo estrutural.
_________________________________________________________________________________________________________


80
Leitura Complementar
Engenharia de Requisitos
Em (SOMMERVILLE, 2007), a parte 2 Requisitos como o prprio nome
indica, dedicada ao tema. Merecem ateno especial os captulos 6 e 7. O Captulo 6
Requisitos de Software trata de tipos e nveis de requisitos, bem como da
documentao de requisitos. O Captulo 7 Processos de Engenharia de Requisitos
apresenta e discute um processo de engenharia de requisitos (tambm muito similar ao
apresentado neste texto) e suas atividades.
Em (PFLEEGER, 2004), o Captulo 4 Identificando Requisitos tem uma boa
discusso sobre requisitos. Em relao aos temas abordados nestas notas de aula,
merecem destaque as sees 4.1, 4.2, 4.3, 4.6, 4.7, 4.8 e 4.9, as quais tratam dos
seguintes assuntos: requisitos, processo de requisitos, tipos de documentos de requisitos,
tipos de requisitos, caractersticas de requisitos (sees 4.1, 4.2 e 4.3), prototipagem de
requisitos (seo 4.6), documentao de requisitos (seo 4.7), participantes no processo
de requisitos (seo 4.8) e validao de requisitos (seo 4.9).
Em (PRESSMAN, 2006), o Captulo 7 Engenharia de Requisitos aborda
vrios dos temas discutidos neste captulo, com destaque para as sees 7.2 (Tarefas da
Engenharia de Requisitos), 7.3 (Incio do Processo de Engenharia de Requisitos), 7.4
(Levantamento de Requisitos), 7.7 (Negociao de Requisitos) e 7.8 (Validao de
Requisitos).
Modelagem de Casos de Uso
Os captulos 7 e 8 de (BLAHA; RUMBAUGH, 2006) Modelagem de
Interaes e Modelagem Avanada de Interaes, respectivamente abordam a
modelagem de casos de uso. Mais especificamente, recomenda-se a leitura da seo 7.1
(Modelos de Casos de Uso), que d uma viso geral de atores, casos de uso e diagramas
de casos de uso, e da seo 8.1 (Relaes entre Casos de Uso), que discute as relaes
de incluso, extenso e generalizao e especializao entre casos de uso.
O Captulo 15 de (OLIV, 2007) Use Cases d uma viso geral da
modelagem de casos de uso, discutindo de maneira breve, mas bastante didtica, os
conceitos de ator e de caso de uso, a especificao de casos de uso e os relacionamentos
entre casos de uso.
O livro Escrevendo Casos de Uso Eficazes: Um guia prtico para
desenvolvedores de software (COCKBURN, 2005) inteiramente dedicado ao
processo de escrita de casos de uso. Esse livro uma tima referncia para os
interessados em aperfeioar seu processo de escrita de casos de uso, contendo diversas
diretrizes incorporadas nestas notas de aula.
Em (WAZLAWICK, 2004), tanto o Captulo 2 (Concepo) quanto o Captulo 3
(Expanso dos Casos de Uso) abordam a modelagem de casos de uso.
Em (BOOCH; RUMBAUGH; JACOBSON, 2006), merecem ateno os
captulos 17 (Casos de Uso) e 18 (Diagramas de Casos de Uso). As notaes da UML
para diagramas de casos de uso so tratadas com mais detalhes do que nas demais
referncias citadas anteriormente, precisamente por se tratar este de um livro sobre a
UML.
_________________________________________________________________________________________________________
81
Modelagem Conceitual Estrutural

O Captulo 5 de (WAZLAWICK, 2004) Modelagem Conceitual d uma
viso geral da modelagem estrutural, discutindo de maneira bastante didtica, diversos
de seus aspectos.
captulos 4 (Classes), 5 (Relacionamentos), 8 (Diagramas de Classes), 9 (Classes
Avanadas) e 10 (Relacionamentos Avanados). As notaes da UML para diagramas
de classes so tratadas com mais detalhes do que nas demais referncias citadas
anteriormente, precisamente por se tratar este de um livro sobre a UML.
Diagrama de Estados
captulos 22 (Mquinas de Estados) e 25 (Diagramas de Grficos de Estados). As
notaes da UML para os diagramas abordados neste captulo so tratadas com bastante
detalhes, uma vez que este um livro sobre a UML. Alm desses captulos, merece
ateno a parte do Captulo 9 (Classes Avanadas) que trata da sintaxe de operaes.
Finalmente, em (BLAHA; RUMBAUGH, 2006), os captulos 5, 6 e 12 abordam
o desenvolvimento de diagramas de estados.
Referncias do Captulo
BLAHA, M., RUMBAUGH, J., Modelagem e Projetos Baseados em Objetos com UML
2, Elsevier, 2006.
BOOCH, G., Object-Oriented Analysis and Design with Applications, 2nd edition,
Benjamin/Cummings Publishing Company, Inc, 1994.
BOOCH, G., RUMBAUGH, J., JACOBSON, I., UML Guia do Usurio, 2a edio,
Elsevier Editora, 2006.
COCKBURN, A., Escrevendo Casos de Uso Eficazes: Um guia prtico para
desenvolvedores de software, Porto Alegre: Bookman, 2005.
OLIV, A., Conceptual Modeling of Information Systems, Springer, 2007.
PFLEEGER, S.L., Engenharia de Software: Teoria e Prtica, So Paulo: Prentice Hall,
2 edio, 2004.
PRESSMAN, R.S., Engenharia de Software, McGraw-Hill, 6 edio, 2006.
SOMMERVILLE, I., Engenharia de Software, 8 Edio. So Paulo: Pearson
Addison Wesley, 2007.
TOGNERI, D.F., Apoio Automatizado Engenharia de Requisitos Cooperativa.
Dissertao (Mestrado em Informtica), Universidade Federal do Esprito Santo
(UFES), Vitria, 2002.
WAZLAWICK, R.S., Anlise e Projeto de Sistemas de Informao Orientados a
Objetos, Elsevier, 2004.
WIEGERS, K.E., Software Requirements: Practical techniques for gathering and
managing requirements throughout the product development cycle. 2nd Edition,
Microsoft Press, Redmond, Washington, 2003.
YOURDON, E., Object-Oriented Systems Design: an Integrated Approach, Yourdon
Press Computing Series, Prentice Hall, 1994.
_________________________________________________________________________________________________________
Captulo 6 Projeto de Sistemas

82

O objetivo da fase de projeto (ou design) produzir uma soluo para o
problema identificado e modelado na fase de anlise, incorporando a tecnologia aos
requisitos essenciais do usurio e projetando o que ser construdo na implementao.
Sendo assim, necessrio conhecer a tecnologia disponvel e os ambientes de software
onde o sistema ser desenvolvido e implantado. Durante o projeto, deve-se decidir
como o problema ser resolvido, comeando em um alto nvel de abstrao, prximo da
anlise, detalhando depois at um nvel de abstrao prximo da implementao.
O projeto de software encontra-se no ncleo tcnico do processo de
desenvolvimento de software e aplicado independentemente do modelo de ciclo de
vida e paradigma adotados. iniciado assim que os requisitos do software tiverem sido
modelados e especificados pelo menos parcialmente e a ltima atividade de
modelagem. Por outro lado, corresponde primeira atividade que leva em conta
consideraes de carter tecnolgico (PRESSMAN, 2006).
Enquanto a fase de anlise pressupe que a tecnologia perfeita (capacidade
ilimitada de processamento com velocidade instantnea, capacidade ilimitada de
armazenamento, custo zero e no passvel de falha), a fase de projeto envolve a
modelagem de como o sistema ser implementado com a adio dos requisitos
tecnolgicos ou no funcionais. Assim, como bem disse Mitch Kapor, citado por
Pressman (2006), o projeto onde voc se instala com um p em dois mundos o
mundo da tecnologia e o mundo das pessoas e objetivos humanos e voc tenta juntar
os dois. A Figura 6.1 procura ilustrar essa situao. O projeto , portanto, a fase do
processo de software na qual os requisitos do cliente, as necessidades do negcio e as
consideraes tcnicas se juntam na formulao de um produto ou sistema
(PRESSMAN, 2006).
Domnio do
Problema
Mundo Real
Anlise e
Especificao
de Requisitos
(o que)
Projeto
(como)
Domnio
da
Soluo
Mundo
Computacional
Implementao
Figura 6.1 Viso geral da fase de Projeto.
_________________________________________________________________________________________________________
(Adaptao por Monalessa Perini Barcellos das Notas de Aula de Projeto de Sistemas de Ricardo de Almeida Falbo)


83
O projeto (design) um processo de refinamento. Inicialmente, o projeto

representado em um nvel alto de abstrao, enfocando a estrutura geral do sistema.
Definida a arquitetura, o projeto passa a tratar do detalhamento de seus elementos. Esses
refinamentos conduzem a representaes de menores nveis de abstrao, at se chegar
ao projeto de algoritmos e estruturas de dados. Assim, independentemente do paradigma
adotado, o processo de projeto envolve as seguintes atividades:
Projeto da Arquitetura do Software: visa definir os elementos estruturais do

software e seus relacionamentos.
Projeto dos Elementos da Arquitetura: visa projetar em um maior nvel de

detalhes cada um dos elementos estruturais definidos na arquitetura, o que
envolve a decomposio de mdulos em outros mdulos menores.
Projeto de Interfaces: tem por objetivo descrever como dever se dar a

comunicao entre os elementos da arquitetura (interfaces internas), a
comunicao do sistema em desenvolvimento com outros sistemas (interfaces
externas) e com as pessoas que vo utiliz-lo (interface com o usurio).
Projeto Detalhado: visa refinar e detalhar a descrio procedimental e das

estruturas de dados dos elementos mais bsicos da arquitetura do software.
Tendo em vista que a orientao a objetos um dos paradigmas mais utilizados

atualmente no desenvolvimento de sistemas, este texto aborda o projeto de software
orientado a objetos. Alm disso, o foco deste texto so os sistemas de informao.
Considerando essa classe de sistemas, de maneira geral, os seguintes elementos esto
presentes na arquitetura de um sistema:
Lgica de Domnio: o elemento da arquitetura que trata de toda a lgica do

sistema, englobando tanto aspectos estruturais (classes de domnio derivadas dos
modelos conceituais estruturais da fase de anlise), quanto comportamentais
(classes de processo que tratam das funcionalidades descritas pelos casos de
uso).
Interface com o Usurio: o elemento da arquitetura que trata da interao

humano-computador. Envolve tanto as interfaces propriamente ditas (objetos
grficos responsveis por receber dados e comandos do usurio e apresentar
resultados) quanto o controle da interao, abrindo e fechando janelas,
habilitando ou desabilitando botes etc (WAZLAWICK, 2004).
Persistncia: o elemento da arquitetura responsvel pelo armazenamento e

recuperao de dados em memria secundria (classes que representam e isolam
os depsitos de dados do restante do sistema).
6.1 Aspectos Relevantes ao Projeto de Software

Nesta seo so discutidos alguns aspectos relevantes quando se fala em Projeto de
Software: qualidade, arquitetura, padres e documentao.
_________________________________________________________________________________________________________


84
6.1.1 Qualidade do Projeto de Software

Um bom projeto de software deve apresentar determinadas caractersticas de
qualidade, tais como facilidade de entendimento, facilidade de implementao,
facilidade de realizao de testes, facilidade de modificao e traduo correta das
especificaes de requisitos e de anlise (PFLEEGER, 2004). Para se obter bons
projetos, necessrio considerar alguns aspectos intimamente relacionados com a
qualidade dos projetos, dentre eles (PRESSMAN, 2006):
Nveis de Abstrao: a abstrao um dos modos fundamentais pelos quais os

seres humanos enfrentam a complexidade. Assim, um bom projeto deve
considerar vrios nveis de abstrao, comeando com em um nvel mais alto,
prximo da fase de anlise. medida que se avana no processo de projeto, o
nvel de abstrao deve ser reduzido. Dito de outra maneira, o projeto deve ser
um processo de refinamento, no qual o projeto vai sendo conduzido de nveis
mais altos para nveis mais baixos de abstrao.
Modularidade: um bom projeto deve estruturar um sistema como mdulos ou

componentes coesos e fracamente acoplados. A modularidade o atributo
individual que permite a um projeto de sistema ser intelectualmente gerencivel.
A estratgia dividir para conquistar reconhecidamente til no projeto de
software, pois mais fcil resolver um problema complexo quando o mesmo
dividido em partes menores gerenciveis
Ocultao de Informaes: o conceito de modularidade leva o projetista a uma

questo fundamental: at que nvel a decomposio deve ser aplicada? Em
outras palavras, quo modular deve ser o software? O princpio da ocultao de
informaes sugere que os mdulos / componentes sejam caracterizados pelas
decises de projeto que cada um deles esconde dos demais. Mdulos devem ser
projetados e especificados de modo que as informaes neles contidas (dados e
algoritmos) sejam inacessveis a outros mdulos, sendo necessrio conhecer
apenas a sua interface. Ou seja, a ocultao de informao trabalha
encapsulando detalhes que provavelmente sero alterados independentemente
em diferentes mdulos. A interface de um mdulo revela apenas aqueles
aspectos considerados improvveis de mudar (BASS; CLEMENTS; KAZMAN,
2003).
Independncia Funcional: a independncia funcional uma decorrncia direta

da modularidade e dos conceitos de abstrao e ocultao de informaes. Ela
obtida pelo desenvolvimento de mdulos com finalidade nica e pequena
interao com outros mdulos, isto , mdulos devem cumprir uma funo bem
estabelecida, minimizando interaes com outros mdulos. Mdulos
funcionalmente independentes so mais fceis de entender, desenvolver, testar e
alterar. Efeitos colaterais causados pela modificao de um mdulo so
limitados e, por conseguinte, a propagao de erros reduzida.
A
independncia funcional pode ser avaliada usando dois critrios de qualidade:
coeso e acoplamento. A coeso se refere ao elo de ligao com o qual um
mdulo construdo. Uma classe, p.ex., dita coesa quando tem um conjunto
pequeno e focado de responsabilidades e aplica seus atributos e mtodos
especificamente para implementar essas responsabilidades. J o acoplamento diz
respeito ao grau de interdependncia entre dois mdulos. O objetivo minimizar
o acoplamento, isto , tornar os mdulos to independentes quanto possvel.
_________________________________________________________________________________________________________

85
Idealmente, classes de projeto em um subsistema deveriam ter conhecimento

limitado de classes de outros subsistemas. Coeso e acoplamento so
interdependentes e, portanto, uma boa coeso deve conduzir a um pequeno
acoplamento. A Figura 6.2 procura ilustrar esse fato.
Baixa Coeso
Fbrica de
Refrigerantes
Baixa Coeso
Alto
Acoplamento
Serra
Vila Velha
Conjunto
Habitacional
da Siderrgica
Trfego Intenso
Alta Coeso
Fbrica de
Refrigerantes
Fbrica de
Garrafas
Plsticas
Alta Coeso
Baixo
Acoplamento
Vila Velha
Fbrica de
Garrafas
Plsticas
Siderrgica
Siderrgica
Serra
Pouco
Trfego
Conjunto
Habitacional
da Siderrgica
Figura 6.2 Coeso e Acoplamento.

6.1.2 Arquitetura de Software
De acordo com Bass, Clements e Kazman (2003), a arquitetura de software de um
sistema computacional a estrutura (ou estruturas) do sistema que compreende
elementos de software, propriedades externamente visveis desses elementos e os
relacionamentos entre eles. A arquitetura define elementos de software, ou mdulos, e
envolve informao sobre como eles se relacionam uns com os outros. Uma arquitetura
pode envolver mais de um tipo de estrutura, com diferentes tipos de elementos e de
relacionamentos entre elementos. A arquitetura omite certas informaes sobre os
elementos que no pertencem s suas interaes. As propriedades externamente visveis
indicam as suposies que os demais elementos podem fazer sobre um elemento, tais
como servios providos e caractersticas de qualidade esperadas. Assim, uma arquitetura
_________________________________________________________________________________________________________


86
antes de tudo uma abstrao de um sistema que suprime detalhes dos elementos que
no afetam como eles so usados, como se relacionam, como interagem e como usam
outros elementos. Na maioria das vezes, a arquitetura usada para descrever aspectos
estruturais de um sistema.
Em quase todos os sistemas modernos, elementos interagem com outros por meio
de interfaces que dividem detalhes sobre um elemento em partes pblica e privada. A
arquitetura est preocupada com a parte pblica dessa diviso. Detalhes privados,
aqueles que tm a ver somente com a implementao interna, no so arquiteturais
(BASS; CLEMENTS; KAZMAN, 2003).
At o projeto arquitetnico, aspectos relacionados ao hardware e plataforma de
implementao ainda no foram tratados, j que a fase de anlise pressupe tecnologia
perfeita. Este o momento para resolver como um modelo ideal vai executar em uma
plataforma restrita. importante realar que no existe a soluo perfeita. O projeto da
arquitetura uma tarefa de negociao, onde se faz compromissos entre solues subtimas. O modelo de arquitetura mapeia os requisitos essenciais da fase de anlise em
uma arquitetura tcnica. Uma vez que muitas arquiteturas diferentes so possveis, o
propsito do projeto arquitetnico escolher a configurao mais adequada. Alm
disso, fatores que transcendem aspectos puramente tcnicos devem ser considerados.
Normalmente, o projeto da arquitetura discutido luz dos requisitos do sistema,
ou seja, se os requisitos so conhecidos, ento se pode projetar a arquitetura do sistema.
Contudo, deve-se considerar o projeto arquitetnico como algo mais abrangente,
envolvendo aspectos tcnicos, sociais e de negcio. Todos esses fatores (e no somente
os requisitos do sistema) influenciam a arquitetura de software. Esta, por sua vez, afeta
o ambiente da organizao (incluindo ambientes tcnico, social e de negcio) que vai
influenciar arquiteturas futuras, criando um ciclo de realimentao contnua. Por
exemplo, se os projetistas encarregados do projeto de um novo sistema obtiveram bons
resultados em projetos de sistemas anteriores usando uma particular abordagem de
arquitetura, ento natural que eles tentem a mesma abordagem no novo projeto. Por
outro lado, se suas experincias anteriores com essa abordagem foram desastrosas, os
projetistas vo relutar em tent-la outra vez, mesmo que ela se apresente como uma
soluo adequada. Assim, as escolhas so guiadas, tambm, pela formao e
experincia dos projetistas (BASS; CLEMENTS; KAZMAN, 2003).
Outro fator que afeta a escolha da arquitetura o ambiente tcnico (ou plataforma
de implementao) corrente. Muitas vezes, h para esse ambiente um conjunto
dominante de padres, prticas e tcnicas que aceito pela comunidade de arquitetos ou
pela organizao de desenvolvimento. Por fim, a arquitetura influenciada tambm pela
estrutura e natureza da organizao de desenvolvimento (BASS; CLEMENTS;
KAZMAN, 2003).
Assim, no projeto da arquitetura de software, projetistas so influenciados por
requisitos para o sistema, estrutura e metas da organizao de desenvolvimento,
ambiente tcnico disponvel e por suas prprias experincias e formao. Alm disso, os
relacionamentos entre metas de negcio, requisitos de sistemas, experincia dos
projetistas, arquiteturas e sistemas implantados geram diversos laos de realimentao
que podem ser gerenciado pela organizao.
Muitas pessoas tm interesse na arquitetura de software, tais como clientes,
usurios finais, desenvolvedores, gerentes de projeto e mantenedores. Alguns desses
interesses so conflitantes e o projetista frequentemente tem de mediar conflitos at
_________________________________________________________________________________________________________


87
chegar configurao que atenda de forma mais adequada a todos os interesses. Neste
contexto, arquiteturas de software so importantes principalmente porque (BASS;
CLEMENTS; KAZMAN, 2003):
Representam uma abstrao comum do sistema que pode ser usada para
compreenso mtua, negociao, consenso e comunicao entre os
interessados. A arquitetura prov uma linguagem comum na qual diferentes
preocupaes podem ser expressas, negociadas e resolvidas em um nvel que
seja intelectualmente gerencivel.
Manifestam as primeiras decises de projeto. Essas decises definem

restries sobre a implementao e a estrutura organizacional do projeto. A
implementao tem de ser dividida nos elementos prescritos pela arquitetura.
Os elementos tm de interagir conforme o prescrito e cada elemento tem de
cumprir sua responsabilidade conforme ditado pela arquitetura. Tambm a
estrutura organizacional do projeto, e s vezes at a estrutura da organizao
como um todo, torna-se amarrada estrutura proposta pela arquitetura. Neste
sentido, a arquitetura pode ajudar a obter estimativas e cronogramas mais
precisos, bem como pode ajudar na prototipagem do sistema. Alm disso, a
extenso na qual o sistema vai ser capaz de satisfazer os atributos de qualidade
requeridos substancialmente determinada pela arquitetura. Particularmente a
manutenibilidade fortemente afetada pela arquitetura. Uma arquitetura
reparte possveis alteraes em trs categorias: locais (confinadas em um
nico elemento), no locais (requerem a alterao de vrios elementos, mas
mantm intacta a abordagem arquitetnica subjacente) e arquitetnicas
(afetam a estrutura do sistema e podem requerer alteraes ao longo de todo o
sistema). Obviamente, alteraes locais so as mais desejveis e, portanto,
uma arquitetura efetiva deve propiciar que as alteraes mais provveis sejam
as mais fceis de fazer.
Constituem um modelo relativamente pequeno e intelectualmente

compreensvel de como o sistema estruturado e como seus elementos
trabalham em conjunto. Alm disso, esse modelo transfervel para outros
sistemas, em especial para aqueles que exibem requisitos funcionais e no
funcionais similares, promovendo reso em larga escala. Um desenvolvimento
baseado na arquitetura frenquentemente enfoca a composio ou montagem de
elementos que provavelmente foram desenvolvidos separadamente, at mesmo
de forma independente. Essa composio possvel porque a arquitetura
define os elementos que devem ser incorporados no sistema. Alm disso, a
arquitetura restringe possveis substituies de elementos segundo a forma
como eles interagem com o ambiente, recebem e entregam o controle, que
dados consomem e produzem, como acessam esses dados e quais protocolos
usam para se comunicar e compartilhar recursos.
importante que o projetista seja capaz de reconhecer estruturas comuns

utilizadas em sistemas j desenvolvidos, de modo a poder compreender as relaes
existentes e desenvolver novos sistemas como variaes dos sistemas existentes. O
entendimento de arquiteturas de software existentes permite que os projetistas avaliem
alternativas de projeto. Neste contexto, uma representao da arquitetura essencial
para permitir descrever propriedades de um sistema complexo, bem como uma anlise
da arquitetura proposta (MENDES, 2002).
_________________________________________________________________________________________________________
88
Muitas vezes, arquiteturas so representadas na forma de diagramas contendo

caixas (representando elementos) e linhas (representando relacionamentos). Entretanto,
tais diagramas no dizem muita coisa sobre o que so os elementos e como eles
cooperam para realizar o propsito do sistema e, portanto, no capturam importantes
informaes de arquitetura (BASS; CLEMENTS; KAZMAN, 2003). Por exemplo, em
uma viso de decomposio de mdulos, importante distinguir quando um mdulo
decomposto em outros mdulos e quando um mdulo simplesmente usa outros
mdulos. J em uma arquitetura cliente-servidor, importante apontar quando um
mdulo considerado cliente e quando ele considerado servidor. Assim, idealmente, a
representao de uma arquitetura deve incorporar informaes acerca dos tipos dos
elementos e dos relacionamentos.
6.1.3
Padres (Patterns)
Todo projeto de desenvolvimento , de alguma maneira, novo, na medida em que se

quer desenvolver um novo sistema, seja porque ainda no existe um sistema para
resolver o problema que est sendo tratado, seja porque h aspectos indesejveis nos
sistemas existentes. Isso no quer dizer que o projeto tenha que ser desenvolvido a partir
do zero. Muito pelo contrrio. A reutilizao um aspecto fundamental no
desenvolvimento de software. Muitos sistemas previamente desenvolvidos so similares
ao sistema em desenvolvimento e h muito conhecimento que pode ser reaplicado para
solucionar questes recorrentes no projeto de software. Os padres (patterns) visam
capturar esse conhecimento, procurando torn-lo mais geral e amplamente aplicvel,
desvinculando-o das especificidades de um determinado projeto ou sistema.
Um padro uma soluo testada e aprovada para um problema geral.
Diferentes padres se destinam a diferentes fases do ciclo de vida: anlise, arquitetura,
projeto e implementao. Um padro vem com diretrizes sobre quando us-lo, bem
como vantagens e desvantagens de seu uso. Um padro j foi cuidadosamente
considerado por outras pessoas e aplicado diversas vezes na soluo de problemas
anteriores de mesma natureza. Assim, tende a ser uma soluo de qualidade, com
maiores chances de estar correto e estvel do que uma soluo nova, especfica, ainda
no testada (BLAHA; RUMBAUGH, 2006).
Um padro normalmente tem o formato de um par nomeado problema/soluo,
que pode ser utilizado em novos contextos, com orientaes sobre com utiliz-lo nessas
novas situaes (LARMAN, 2007). O objetivo de um padro de projeto registrar uma
experincia no projeto de software, que possa ser efetivamente utilizado por projetistas.
Cada padro sistematicamente nomeia, explica e avalia uma importante situao de
projeto que ocorre repetidamente em sistemas (GAMMA et al., 1995).
Um projetista familiarizado com padres pode aplic-los diretamente a
problemas sem ter que redescobrir as abstraes e os objetos que as capturam. Uma vez
que um padro aplicado, muitas decises de projeto decorrem automaticamente.
Em geral, um padro tem os seguintes elementos (GAMMA et al., 1995)
(BUSCHMANN et al., 1996):
Nome: identificao de uma ou duas palavras, utilizada para nomear o
padro.
Contexto: uma situao que d origem a um problema.
_________________________________________________________________________________________________________
89
Problema: explica o problema que surge repetidamente no dado contexto.

Soluo: descreve uma soluo comprovada para o problema, incluindo os
elementos que compem o projeto, seus relacionamentos, responsabilidades e
colaboraes. importante observar que no descreve um particular projeto
concreto ou implementao. Um padro prov uma descrio abstrata de um
problema de projeto e como uma organizao geral de elementos resolve esse
problema.
Consequncias: so os resultados e os comprometimentos feitos ao se aplicar
o padro.
No que concerne aos padres relacionados fase de projeto, h trs grandes
categorias a serem consideradas:
Padres Arquitetnicos: definem uma estrutura global do sistema. Um

padro arquitetnico indica um conjunto predefinido de subsistemas,
especifica as suas responsabilidades e inclui regras e orientaes para
estabelecer os relacionamentos entre eles. So aplicados na atividade de
projeto da arquitetura de software e podem ser vistos como modelos
(templates) para arquiteturas de software concretas (BUSCHMANN et al.,
1996).
Padres de Projeto (Design Patterns): atendem a uma situao especfica de

projeto, mostrando classes e relacionamentos, seus papis e suas
colaboraes e tambm a distribuio de responsabilidades. Um padro de
projeto prov um esquema para refinar subsistemas ou componentes de
sistema de software, ou os relacionamentos entre eles. Ele descreve uma
estrutura comumente recorrente de componentes que se comunicam, a qual
resolve um problema de projeto geral dentro de um particular contexto
(GAMMA et al., 1995).
Idiomas: representam o nvel mais baixo de padres, endereando aspectos

tanto de projeto quanto de implementao. Um idioma um padro de baixo
nvel, especfico de uma linguagem de programao, descrevendo como
implementar aspectos particulares de componentes ou os relacionamentos
entre eles usando as caractersticas de uma dada linguagem (BUSCHMANN
et al., 1996).
6.1.4 Documentao de Projeto

Uma vez que o projeto de software encontra-se no ncleo tcnico do processo de
desenvolvimento, sua documentao tem grande importncia para o sucesso do projeto
e para a manuteno futura do sistema. Diferentes interessados vo requerer
informaes diferentes e a documentao de projeto crucial para a comunicao.
Analistas, projetistas e clientes vo precisar negociar para estabelecer prioridades entre
requisitos conflitantes; programadores e testadores vo utilizar essa documentao para
implementar e testar o sistema; gerentes de projeto vo usar informaes da
decomposio do sistema para definir e alocar equipes de trabalho; mantenedores vo
recorrer a essa documentao na hora de avaliar e realizar uma alterao.
Uma vez que o projeto um processo de refinamento, a sua documentao
tambm deve prover representaes em diferentes nveis de abstrao. Alm disso, o
_________________________________________________________________________________________________________


90
projeto de um sistema uma entidade complexa que no pode ser descrita em uma
nica perspectiva. Ao contrrio, mltiplas vises so essenciais e a documentao deve
abranger aquelas vises consideradas relevantes. De fato, como muitas vises so
possveis, a documentao uma atividade que envolve a escolha das vises relevantes,
a documentao das vises selecionadas e a documentao de informaes que se
aplicam a mais do que uma viso (BASS; CLEMENTS; KAZMAN, 2003). A escolha
das vises dependente de vrios fatores, dentre eles, do tipo de sistema sendo
desenvolvido, dos atributos de qualidade considerados e da audincia da documentao
de projeto. Diferentes vises realam diferentes elementos de um sistema.
6.2 Projetando a Arquitetura de Software

Projetar a arquitetura de um software requer o levantamento de informaes
relativas plataforma de computao do sistema, as quais se somaro ao conhecimento
acerca dos requisitos funcionais e no funcionais, para dar embasar as decises relativas
arquitetura do sistema que est sendo projetado. De maneira geral, o processo de
projetar envolve, dentre outros, os seguintes passos:
1. Levantar informaes acerca da plataforma de computao do sistema,
incluindo linguagem de programao a ser adotada, mecanismo de
persistncia e necessidades de distribuio geogrfica.
2. Com base nos requisitos, iniciar a decomposio do sistema em subsistemas,
considerando preferencialmente uma decomposio pelo domnio do
problema. Se na fase de anlise j tiver sido estabelecida uma decomposio
inicial em subsistemas, esta dever ser utilizada. Neste momento, deve-se
escolher um estilo arquitetnico (ou uma combinao adequada de estilos
arquitetnicos) para organizar a estrutura geral do sistema.
3. Estabelecer uma arquitetura base, identificando tipos de mdulos e tipos de
relacionamentos entre eles, dados essencialmente pela combinao de estilos
arquitetnicos escolhidos.
4. Alocar requisitos funcionais (casos de uso) e no funcionais aos
componentes da arquitetura.
5. Avaliar a arquitetura, procurando identificar se ela acomoda os requisitos e
restries identificados.
6. Uma vez definida a arquitetura em seu nvel mais alto, passar ao projeto de
seus elementos. Padres arquitetnicos so instrumentos muito valiosos para
auxiliar o projeto dos componentes da arquitetura.
Em relao ao passo 2, um estilo arquitetnico que combina parties e camadas
tende a ser um bom ponto de partida para a estruturao global de sistemas de
informao.
Parties podem ser derivadas a partir do domnio do problema, levando-se

em conta funcionalidades coesas, visando criao de subsistemas fracamente
acoplados. Idealmente, alguma diviso em subsistemas deve ter sido feita na
fase de anlise e a mesma deve ser aqui preservada.
As parties podem ser estruturadas em camadas e novamente um bom ponto

de partida considerar camadas tpicas de um sistema de informao
_________________________________________________________________________________________________________

91
(Interface com o Usurio, Domnio do Problema e Gerncia de Dados),

mostradas na Figura 6.3.
If ....
Then ....
Else ....
If ....
Then ....
Else ....
Camada de
Domnio do
Problema
Camada de
Interface com o
Usurio
Camada de
Gerncia de
Dados
Figura 6.3 Camadas tpicas em sistemas de informao.

Nas prximas sees so apresentadas discusses relacionadas ao projeto de
cada uma dessas camadas.
6.3 A Camada de Domnio do Problema

A camada de lgica de negcio engloba o conjunto de classes que vai realizar toda
a lgica do sistema de informao. As demais camadas so derivadas ou dependentes da
camada de domnio (WAZLAWICK, 2004) e, portanto, interessante iniciar o projeto
dos componentes da arquitetura do sistema pela camada da lgica de negcio.
Os modelos construdos na fase de anlise so os principais insumos para o
projeto dessa camada, em especial o modelo conceitual e o modelo de casos de uso. Os
diagramas de classes da fase de anlise sero a base para a construo dos diagramas de
classes da fase de projeto. De fato, a verso inicial do modelo estrutural de projeto
(diagramas de classes de projeto) da lgica de negcio ser uma cpia do modelo
conceitual estrutural. Durante o projeto, esse modelo ser objeto de refinamento,
visando incorporar informaes importantes para a implementao, tais como
distribuio de responsabilidades entre as classes (definio de mtodos das classes) e
definio de navegabilidades, visibilidades e tipos de dados. Alm disso, alteraes na
estrutura do diagrama de classes podem ser necessrias para tratar requisitos no
funcionais, tais como usabilidade e desempenho.
Para organizar a lgica de negcio, um bom ponto de partida so os padres
arquitetnicos relativos a essa camada. No contexto do desenvolvimento de Sistemas de
Informao Orientados a Objetos, merecem destaque os padres Modelo de Domnio e
Camada de Servio.
_________________________________________________________________________________________________________
92
Uma questo bastante importante tratada por esses padres a distribuio de

responsabilidades ao longo das classes que compem o sistema. No mundo de objetos,
uma funcionalidade realizada atravs de uma rede de objetos interconectados,
colaborando entre si. Objetos encapsulam dados e comportamento. O posicionamento
correto do comportamento na rede de objetos um dos principais problemas a serem
enfrentados durante o projeto da lgica de negcio. Neste contexto, um desafio a mais
se coloca: que classes vo comportar as funcionalidades descritas pelos casos de uso?
Duas formas bsicas so comumente adotadas:
Distribuir as responsabilidades para a execuo dos casos de uso ao longo

dos objetos do domnio do problema: essa abordagem refletida no padro
Modelo de Domnio e considera que as funcionalidades relativas aos casos
de uso do sistema estaro distribudas nas classes previamente identificadas
na fase de anlise (Componente Domnio do Problema).
Considerar que a lgica de negcio , na verdade, composta por dois tipos de

lgica: a lgica de domnio do problema (Componente de Domnio do
Problema), que tem a ver puramente com as classes previamente
identificadas na fase de anlise; e lgica da aplicao (Componente de
Gerncia de Tarefas), que se refere s funcionalidades descritas pelos casos
de uso. Esta segunda opo a essncia do padro Camada de Servio.
A seguir so apresentados os padres Modelo de Domnio e Camada de Servio.

Depois, so apresentados o Componente Domnio do Problema, necessrio tanto para o
padro Modelo de Domnio quanto para o padro Camada de Servio, e o Componente
de Gerncia de Tarefas, necessrio apenas no padro Camada de Servio.
6.3.1 Padres Arquitetnicos para o Projeto da Lgica de Negcio
Um importante aspecto do projeto da Camada de Lgica de Negcio diz respeito
organizao das classes e distribuio de responsabilidades entre elas, o que vai definir,
em ltima instncia, os mtodos de cada classe dessa camada. Nesse contexto, dpos
padres arquitetnicos merecem destaque: Modelo de Domnio e Camada de Servio.
De forma resumida, no padro Modelo de Domnio, as responsabilidades so
distribudas nos objetos do domnio do problema e a lgica de aplicao pulverizada
nesses objetos, sendo que cada objeto tem uma parte da lgica que relevante a ele. J
na abordagem do padro Camada de Servio, um conjunto de objetos controladores de
casos de uso21 fica responsvel por tratar a lgica de aplicao, controlando o fluxo de
eventos dentro do caso de uso. Grande parte da lgica de negcio ainda fica a cargo dos
objetos do domnio do problema. Cabe aos controladores de casos de uso apenas
centralizar o controle sobre a execuo do caso de uso. Assim, a camada de servio
construda, de fato, sobre a camada de domnio.
A seguir os padres so apresentados em mais detalhes.
Padro Modelo de Domnio
O padro Modelo de Domnio preconiza que o prprio modelo de objetos do
domnio incorpore dados e comportamento. Um modelo de domnio estabelece uma
21
Classes controladoras de caso de uso so classes que centralizam as interaes no contexto de casos de
uso especficos e no so consideradas controladores no sentido usado no padro MVC.
_________________________________________________________________________________________________________


93
rede de objetos interconectados, onde cada objeto representa alguma entidade

significativa no mundo real. Colocar um modelo de domnio em uma aplicao envolve
inserir uma camada de objetos que modela a rea de negcio da aplicao. Os objetos
dessa camada vo ser abstraes de entidades do negcio que capturam regras que o
negcio utiliza. Os dados e os processos so combinados para agrupar os processos
prximos dos dados com os quais eles trabalham (FOWLER, 2003). Neste sentido,
pode-se dizer que o padro Modelo de Domnio captura a essncia da orientao a
objetos. Como benefcios, tm-se os benefcios propalados pela orientao a objetos,
tais como evitar duplicao da lgica de negcio e gerenciar a complexidade usando
design patterns clssicos.
Wazlawick (2004) prope uma maneira interessante de aplicar esse padro que
consiste em considerar uma classe controladora do sistema no modelo de domnio do
problema, relacionando-a a todos os conceitos independentes, correspondentes aos
cadastros do sistema, ou seja, os elementos a serem cadastrados para a operao do
sistema22. O fluxo de controle sempre inicia em uma instncia da classe controladora.
Essa classe recebe as requisies da interface e, para trat-las, o controlador invoca
mtodos das classes do domnio do problema, em uma abordagem chamada de
delegao. A delegao consiste em capturar uma operao que trata uma mensagem
em um objeto e reenviar essa mensagem para um outro objeto associado ao primeiro
que seja capaz de tratar a requisio. Neste caso, a execuo delegada para objetos do
domnio do problema, procurando efetuar uma cadeia de delegao sobre as linhas de
visibilidade das associaes j existentes, at se atingir um objeto capaz de atender
requisio. Novas linhas de visibilidade s devem ser criadas quando isso for
estritamente necessrio. Deste modo, mantm-se fraco o acoplamento entre as classes,
conforme preconiza o padro de projeto acoplamento fraco (LARMAN, 2004). Assim,
partindo-se do controlador do sistema, deve-se identificar qual o objeto a ele
relacionado que melhor pode tratar a requisio e delegar essa responsabilidade a ele.
Esse objeto, por sua vez, vai colaborar com outros objetos para a realizao da
funcionalidade.
De maneira geral, um objeto s deve mandar mensagens para outros objetos que
estejam a ele associados ou que foram passados como parmetro no mtodo que est
sendo executado. Nessa abordagem, deve-se evitar obter um objeto como retorno de um
mtodo (visibilidade local) para mandar mensagens a ele (WAZLAWICK, 2004),
conforme apontado pelo padro no fale com estranhos (LARMAN, 2004).
Padro Camada de Servio
A motivao principal para esse padro o fato de algumas funcionalidades no
serem facilmente distribudas nas classes de domnio do problema, principalmente
aquelas que operam sobre vrios objetos. Uma possibilidade para resolver tal problema
pulverizar esse comportamento ao longo dos vrios objetos do domnio do problema,
conforme preconiza o padro Modelo de Domnio. Contudo, esta pode no ser uma boa
soluo segundo uma perspectiva de manutenibilidade. Uma alterao em tal
funcionalidade poderia afetar diversos objetos e, assim, ser difcil de ser incorporada.
22
Vale ressaltar que, embora a classe controladora de sistema seja modelada no diagrama de classes do
domnio do problema, ela corresponde, de fato, ao pacote de interface com o usurio, tendo em vista que
ela um controlador no sentido adotado pelo padro MVC.
_________________________________________________________________________________________________________
94
Uma abordagem alternativa consiste em criar classes controladoras de casos de

uso (gerenciadores ou coordenadores de tarefas)23, responsveis pela realizao de
tarefas sobre um determinado conjunto de objetos. Tipicamente, esses gerenciadores
agem como aglutinadores, unindo outros objetos para dar forma a um caso de uso.
Consequentemente, gerenciadores de tarefa so normalmente encontrados diretamente a
partir dos casos de uso.
Os tipos de funcionalidade tipicamente atribudos a gerenciadores de tarefa
incluem comportamento relacionado a transaes e sequncias de controle especficas
de um caso de uso.
O padro Camada de Servio (FOWLER, 2003) define uma fronteira da
aplicao usando uma camada de servios que estabelece um conjunto de operaes
disponveis e coordena as respostas da aplicao para cada uma das operaes. A
camada de servio encapsula a lgica de negcio da aplicao, controlando transaes e
coordenando respostas na implementao de suas operaes. A argumentao em favor
desse padro que misturar lgica de domnio e lgica de aplicao nas mesmas classes
torna essas classes menos reutilizveis transversalmente em diferentes aplicaes, bem
como pode dificultar a manuteno da lgica de aplicao, uma vez que a lgica dos
casos de uso no diretamente perceptvel em nenhuma classe.
A identificao das operaes necessrias na camada de servio fortemente
apoiada nos casos de uso do sistema. Uma opo considerar que cada caso de uso vai
dar origem a uma classe de servios, dita classe controladora de caso de uso. Por
exemplo, um caso de uso de cadastro, envolvendo funcionalidades de incluso,
alterao, consulta e excluso, pode ser mapeado em uma classe com operaes para
tratar essas funcionalidades. Contudo, no h uma prescrio clara, apenas heursticas.
Para uma aplicao relativamente pequena, pode ser suficiente ter uma nica classe
provendo todas as operaes. Para sistemas maiores, compostos de vrios subsistemas,
pode-se ter uma classe por subsistema (FOWLER, 2003).
A camada de servio pode ser implementada de duas formas bsicas:
Fachada de Domnio: nessa abordagem, a camada de servio implementada

como um conjunto fino de fachadas sobre um modelo de domnio (no
sentido do padro Modelo de Domnio). As classes implementando as
fachadas no implementam nenhuma lgica de negcio. Esta implementada
pela camada de domnio. As fachadas estabelecem apenas uma fronteira e
um conjunto de operaes atravs das quais suas camadas clientes
(tipicamente interfaces com o usurio e pontos de integrao com outros
sistemas) vo interagir com a lgica de negcio.
Script de Operao: nessa abordagem, a camada de servio implementada

como um conjunto de classes que implementa diretamente a lgica de
aplicao. Contudo, vale frisar que, para implementar a lgica de aplicao,
as classes dessa camada delegam diversas responsabilidades para os objetos
do domnio do problema.
No se deve confundir uma abordagem de Camada de Servios com uma

abordagem de Modelo de Domnio Anmico (Anemic Domain Model) (FOWLER,
2003a), na qual os objetos do domnio do problema apresentam comportamento vazio.
23
Vale lembrar que classes gerenciadoras de casos de uso no so controladores no sentido do padro
MVC.
_________________________________________________________________________________________________________


95
Nessa abordagem, as classes de anlise so divididas em classes de dados (ditos objetos

de valor Value Objects VOs) e classes de lgica (ditos objetos de negcio
Business Objects BOs), que separam o comportamento do estado dos objetos. Os VOs
tm apenas o comportamento bsico para alterar e manipular seu estado (mtodos
construtor e destrutor e mtodos get e set). Os BOs ficam com os outros
comportamentos, tais como clculos, validaes e regras de negcio. De maneira geral,
a abordagem de Modelo de Domnio Anmico deve ser evitada, sendo, por isso,
considerada um anti-padro. Essa abordagem tem diversos problemas. Primeiro, no h
encapsulamento, j que dificilmente um VO vai ser utilizado apenas por um BO.
Segundo, a vantagem de se ter um modelo de domnio rico anulada, j que a
proximidade com as abstraes do mundo real destruda. No mundo real no existe
lgica de um lado e dados de outro, mas sim ambos combinados em um mesmo
conceito. Outro problema a manuteno de um sistema construdo desta maneira. Os
BOs possuem um acoplamento muito alto com os VOs e a mudana em um afeta
drasticamente o outro (FRAGMENTAL, 2007).
Uma maneira de se implementar o padro Camada de Servio consiste em ter uma
ou mais classes controladoras de casos de uso (veja discusso na seo 4.4), as quais
encapsulam a lgica da aplicao. Para realizar um caso de uso, a classe controladora de
caso de uso invoca mtodos da camada de domnio do problema, tal como ocorre no
padro Modelo de Domnio. A diferena entre os dois padres reside, neste caso, no
fato da classe gerenciadora de tarefa centralizar o controle do caso de uso, evitando
delegar responsabilidades a classes que no tm como trat-las. Para tal, aceita-se que a
classe gerenciadora de tarefa obtenha um objeto como retorno de um mtodo
(visibilidade local) e mande mensagens a ele. Assim, a classe gerenciadora de tarefa
pode ter referncia a diversos objetos do domnio, tipicamente aqueles envolvidos na
realizao do caso de uso correspondente.
6.3.2 Componente de Domnio do Problema (CDP)
No projeto orientado a objetos, os modelos conceituais estruturais (diagramas de
classes) produzidos na fase de anlise fazem parte do Componente de Domnio do
Problema (CDP). Como ponto de partida para a elaborao do diagrama de classes do
CDP, deve-se utilizar uma cpia do diagrama de classes de anlise. A partir dessa cpia,
alteraes sero feitas para incorporar as decises de projeto. Vale ressaltar que o
trabalho deve ser efetuado em uma cpia, mantendo o modelo conceitual original
intacto para efeito de documentao e manuteno do sistema.
Para se poder conduzir o projeto do CDP de maneira satisfatria, algumas
informaes acerca da plataforma de implementao so essenciais, dentre elas a
linguagem de programao e o mecanismo de persistncia de objetos a serem adotados.
Alm disso, informaes relativas aos requisitos no funcionais e suas prioridades so
igualmente vitais para se tomar decises importantes relativas ao projeto do CDP.
As alteraes bsicas a serem incorporadas em um diagrama de classes do CDP
so:
Adio de informaes relativas a tipos de dados de atributos: Na fase de
anlise, comum no especificar tipos de dados para atributos. Na fase de projeto,
contudo, essa uma informao imprescindvel. De modo geral, os atributos so
mapeados em variveis de um tipo de dados provido pela linguagem de implementao,
_________________________________________________________________________________________________________


96
tal como string, inteiro ou booleano. Contudo, muitas vezes, atributos podem dar
origem a novas classes (ou tipos de dados enumerados) para atender a requisitos de
qualidade, tais como usabilidade, manutenibilidade e reusabilidade.
Adio de navegabilidades nas associaes: Na fase de anlise, as associaes
so consideradas navegveis nos dois sentidos. O mesmo no ocorre na fase de projeto.
Pode-se definir que certas associaes so navegveis apenas em um sentido, indicando
que apenas um dos objetos ter uma referncia para o outro (ou para colees de
objetos, no caso de associaes com multiplicidade *). Esta deciso pode ser
influenciada pelo mecanismo de persistncia de objetos a ser adotado, sobretudo quando
esse mecanismo envolve um Sistema Gerenciador de Banco de Dados Relacional.
Adio de informaes de visibilidade de atributos e associaes: De maneira
geral, na fase de anlise no se especifica a visibilidade de atributos e associaes.
Como discutido no item acima, as associaes so tipicamente consideradas navegveis
e visveis nos dois sentidos. J os atributos so considerados pblicos. Porm essa no
uma boa estratgia para a fase de projeto. Ocultar informaes um importante
princpio de projeto. Assim, atributos s devem poder ser acessados pela prpria classe
ou por suas subclasses. Uma classe no deve ter acesso aos atributos de uma classe a ela
associada. Como consequncia disso, cada classe deve ter operaes para consultar
(tipicamente nomeadas como get) e atribuir / alterar valor (normalmente nomeada como
set) de cada um de seus atributos e associaes navegveis. Essas operaes, contudo,
no precisam ser mostradas no diagrama de classes, visto que elas podem ser deduzidas
pela prpria existncia dos atributos e associaes (WAZLAWICK, 2004).
Adio de mtodos s classes: Muitas vezes, as classes de um diagrama de
classes de anlise no tm informao acerca das suas operaes. Mesmo quando elas
tm, essa informao pode ser insuficiente, tendo em vista que no projeto que se
decide efetivamente como abordar a distribuio de responsabilidades para a realizao
de funcionalidades. Assim, durante o projeto do CDP ateno especial deve ser dada
definio de mtodos nas classes. Para apoiar esta etapa, diagramas de sequncia podem
ser utilizados para modelar a interao entre objetos na realizao de funcionalidades do
sistema. A escolha de um padro arquitetnico para o projeto do CDP tambm tem
influncia na distribuio de responsabilidades. Vale ressaltar que j se assume que
algumas operaes, consideradas bsicas, existem e, portanto, no precisam ser
representadas no diagrama de classes. Essas operaes so as operaes de criao e
destruio de instncias, alm das operaes de consulta e atribuio / alterao de
valores de atributos e associaes, conforme discutido no item anterior. No diagrama de
classes devem aparecer apenas os mtodos que no podem ser deduzidos
(WAZLAWICK, 2004).
Eliminao de classes associativas: Caso o diagrama de classes de anlise
contenha classes associativas, recomenda-se substitu-las por classes normais, criando
novas associaes. Isso importante, pois as linguagens de programao no tm
construtores capazes de implementar diretamente esses elementos de modelo.
Alm das alteraes bsicas a que todos os diagramas de classes do CDP estaro
sujeitos, outras fontes de alterao incluem:
Reutilizar projetos anteriores e classes j programadas: importante que na
fase de projeto seja levada em conta a possibilidade de se reutilizar classes j projetadas
e programadas (desenvolvimento com reso), bem como a possibilidade de se
desenvolver classes para reutilizao futura (desenvolvimento para reso). Tipicamente,
_________________________________________________________________________________________________________


97
ajustes feitos para incorporar tais classes envolvem alteraes na estrutura do modelo,
podendo atingir hierarquias de generalizao-especializao do modelo, de modo a
tratar as classes do domnio do problema como subclasses de classes de biblioteca prexistentes. Tambm ao incorporar um padro de projeto (design pattern), muito
provavelmente a estrutura do diagrama de classes de projeto sofrer alteraes.
Ajustar hierarquias de generalizao-especializao: muitas vezes, as
hierarquias de herana da fase de anlise no so adequadas para a fase de projeto.
Dentre os fatores que podem provocar mudanas na hierarquia de herana destacam-se
o mecanismo de herana suportado pela linguagem de programao a ser usada na
implementao e a definio de operaes.
o Ajustar hierarquias de generalizao-especializao para adequao ao
mecanismo de herana suportado pela linguagem de programao a ser
usada na implementao: se, por exemplo, o modelo de anlise envolve
herana mltipla e a linguagem de implementao no oferece tal recurso,
alteraes no modelo so necessrias. Quando se estiver avaliando
hierarquias de classes para eliminar relaes de herana mltipla, deve-se
considerar se uma abordagem de delegao no mais adequada do que o
estabelecimento de uma relao de herana.
o Ajustar hierarquias de generalizao-especializao para aproveitar
oportunidades decorrentes da definio de operaes: as definies de
operaes nas classes podem tambm conduzir a alteraes na hierarquia de
generalizao-especializao. De fato, pode ser que durante a fase de anlise
no sejam exploradas todas as oportunidades de herana. til reexaminar o
diagrama de projeto procurando observar se determinadas classes tm
comportamento parcialmente comum, abrindo-se espao para a criao de
uma superclasse encapsulando as propriedades (atributos e operaes)
compartilhadas, abstraindo o comportamento comum. Conforme discutido
anteriormente, a reutilizao pode ser um fator motivador para a criao de
novas superclasses. Contudo, deve-se tomar cuidado com a refatorao da
hierarquia de classes. Criar uma nova classe para abstrair comportamento
comum somente se justifica quando h, de fato, uma relao de subtipo entre
as classes existentes e a nova classe criada; ou seja, pode-se dizer que a
subclasse semanticamente um subtipo da superclasse. No se deve alterar a
hierarquia de classes simplesmente para herdar uma parte do
comportamento, quando as classes envolvidas no guardam entre si uma
relao efetivamente de subtipo, em uma abordagem de herana de
implementao (BLAHA; RUMBAUGH, 2006).
Ajustar o modelo para melhorar o desempenho: Visando melhorar o
desempenho do sistema, o projetista pode alterar o diagrama de classes do CDP para
melhor acomodar os ajustes necessrios. Atributos e associaes redundantes podem ser
adicionados para evitar recomputao, bem como podem ser criadas novas classes para
registrar estados intermedirios de um processo.
Ajustar o modelo para facilitar o projeto de interfaces com o usurio
amigveis: com o objetivo de incorporar o atributo de qualidade usabilidade, pode ser
importante considerar novas classes (ou tipos enumerados de dados) que facilitem a
apresentao de listas para seleo do usurio.
_________________________________________________________________________________________________________


98
Ajustar o modelo para incorporar aspectos relacionados segurana: tticas

como autenticao e autorizao requerem novas funcionalidades que, por sua, vez,
requerem novas classes do CDP. Em casos como esse, pode ser til separar as classes
relativas a essas funcionalidades em um novo pacote, visando ao reso.
Alm dos ajustes discutidos anteriormente, vrios deles relacionados a atributos
de qualidade (a saber, reusabilidade, desempenho, usabilidade e segurana), o CDP
pode ser alterado, ainda, para comportar outros requisitos no funcionais, tais como
testabilidade, confiabilidade etc.
Como dito anteriormente, O CDP um componente obrigatrio, tanto quando se
adota o padro Modelo de Domnio quanto quando se adota o padro Camada de
Servio. No padro Modelo de Domnio, o CDP a prpria camada de lgica de
negcio, tendo em vista que no h classes gerenciadoras de tarefas (controladoras de
casos de uso). No caso do padro Camada de Servio, alm do CDP, a camada de lgica
de negcio tem outro componente, o Componente de Gerncia de Tarefas, discutido a
seguir.
6.3.3 Componente de Gerncia de Tarefas
O Componente de Gerncia de Tarefas (CGT) compreende a definio das
classes gerenciadoras de tarefas e seu projeto est intimamente relacionado ao modelo
de casos de uso.
Em um esboo preliminar, pode-se atribuir um gerenciador de tarefa para cada
caso de uso, sendo que os seus fluxos de eventos principais do origem a operaes da
classe que representa o caso de uso (classe controladora de caso de uso). Se a
abordagem de Script de Operao do padro Camada de Servio for adotada, a
manutenibilidade pode ser facilitada, uma vez que, detectado um problema em um caso
de uso, fcil identificar a classe que trata do mesmo. Um possvel problema, contudo,
o desempenho: para sistemas grandes, com muitos casos de uso, haver muitas classes
de gerncia de tarefa e, para realizar uma tarefa complexa, pode ser necessria muita
comunicao entre essas classes.
Uma soluo diametralmente oposta consiste em definir uma nica classe de
aplicao para todo o sistema. Neste caso, os cenrios de todos os casos de uso do
origem a operaes dessa classe. Fica evidente que, exceto para sistemas muito
pequenos, essa classe tende a ter muitas operaes. Caso a abordagem de Script de
Operao do padro Camada de Servio seja adotada, essa classe ser extremamente
complexa e, portanto, essa opo tende a no ser prtica. Quando a abordagem de
Fachada de Domnio do padro Camada de Servio utilizada, ainda que a classe
gerenciadora de tarefas tenha muitas operaes, isso pode no ser um problema
efetivamente, uma vez que essa classe apenas delega a responsabilidade pela execuo
das operaes para objetos do domnio do problema.
No caso da abordagem de Script de Operao do padro Camada de Servio,
normalmente, uma soluo intermediria entre as duas anteriormente apresentadas
conduz a melhores resultados. Nessa abordagem, casos de uso complexos so
designados a classes de gerncia de tarefas especficas. Casos de uso mais simples e de
alguma forma relacionados so tratados por uma mesma classe de gerncia de tarefas.
O conjunto de tarefas a serem apoiadas pelo sistema oferece um recurso bastante
til para a definio das janelas, menus e outros componentes de interface com o
_________________________________________________________________________________________________________
99
usurio necessrios para cada uma dessas tarefas. Assim os projetos dos componentes
de gerncia de tarefa e de apresentao (seo adiante) esto bastante relacionados e
devem ser realizados conjuntamente, uma vez que, muitas vezes, so as tarefas que
determinam a necessidade de elementos de interface com o usurio para sua execuo.
6.4 A Camada de Interface com o Usurio (CIU)

Sistemas, em especial os sistemas de informao, so desenvolvidos para serem
utilizados por pessoas. Assim, um aspecto fundamental no projeto de sistemas a
interface com o usurio (IU). O projeto da IU estabelece uma forma de comunicao
entre as pessoas e o sistema computacional. A IU define como um usurio comandar o
sistema e como o sistema apresentar as informaes a ele.
A camada de IU envolve dois tipos de funcionalidades:
Viso: refere-se aos objetos grficos usados na interao com o usurio;
Controle de Interao: diz respeito ao controle da lgica da interface,

envolvendo a ativao dos objetos grficos (p.ex., abrir ou fechar uma janela,
habilitar ou desabilitar um item de menu etc.) e o disparo de aes.
Um dos princpios fundamentais para um bom projeto de software a separao

da apresentao (camada de IU) da lgica de negcio. Essa separao importante por
diversas razes, dentre elas (FOWLER, 2003):
O projeto de IU e o projeto da lgica de negcio tratam de diferentes

preocupaes. No primeiro, o foco est nos mecanismos de interao e em
como dispor uma boa IU. O segundo concentra-se em conceitos e polticas
de negcio.
Usurios podem querer ver as mesmas informaes de diferentes maneiras

(p.ex., usando diferentes interfaces, tais como interfaces ricas de sistemas
desktop, navegadores Web, interfaces de linha de comando etc.). Neste
contexto, separar a IU da lgica de negcio permite o desenvolvimento de
mltiplas apresentaes.
Objetos no visuais so geralmente mais fceis de testar do que objetos

visuais. Ao separar objetos da lgica de negcio de objetos de IU, possvel
testar os primeiros sem envolver os ltimos.
Dada a importncia dessa separao, importante usar algum padro

arquitetnico que trabalhe essa separao, tal como o padro Modelo-VisoControlador (MVC) (FOWLER, 2003).
6.4.1 O Padro Modelo-Viso-Controlador (MVC)
O padro Modelo-Viso-Controlador (MVC) considera trs papis relacionados
interao humano-computador. O modelo refere-se aos objetos que representam
alguma informao sobre o negcio e corresponde, de fato, a objetos da camada de
Lgica de Negcio. A viso refere-se entrada e a exibio de informaes na IU.
Qualquer requisio tratada pelo terceiro papel: o controlador. Este pega a entrada do
usurio, envia uma requisio para a camada de lgica de negcio, receber sua resposta
e solicita que a viso se atualize conforme apropriado. Assim, a IU uma combinao
_________________________________________________________________________________________________________
100
de viso e controlador (FOWLER, 2003). Em outras palavras, elementos da viso

representam informaes de modelo e as exibem ao usurio, que pode enviar, por meio
da viso, requisies ao sistema. Essas requisies so tratadas pelo controlador, que as
repassa para classes do modelo. Uma vez alterado o estado dos elementos do modelo, o
controlador pode, se apropriado, selecionar outros ou alterar elementos de viso a serem
exibidos ao usurio. Assim, o controlador situa-se entre o modelo e a viso, isolando-os
um do outro.
Neste ponto importante distinguir o controlador do padro MVC do
controlador de caso de uso do Componente de Gerncia de Tarefas. Este ltimo
representa uma classe da lgica de negcio, que encapsula a lgica de um caso de uso.
J um controlador do padro MVC um controlador de interao, ou seja, ele controla a
lgica de interface, abrindo e fechando janelas, habilitando ou desabilitando botes,
enviando requisies etc. Para diferenci-los, neste texto utilizamos o termo controlador
de interao para designar os controladores de interface.
O padro MVC trabalha dois tipos de separao. Primeiro, separa a apresentao
(viso) da lgica de negcio (modelo), conforme advogado pelas boas prticas de
projeto. Segundo, mantm tambm separados o controlador e a viso. Essa segunda
separao (entre a viso e o controlador) menos importante que a primeira (entre a
viso e a lgica de negcio). A maioria dos sistemas tem um nico controlador por
viso e, por isso, a separao entre a viso e o controlador muitas vezes no feita. Em
sistemas de interfaces ricas desktop ela muitas vezes desprezada. Contudo, em
interfaces Web, essa separao comum, j que a parte de viso front end
naturalmente separada do controlador. De fato, a maioria dos padres de projeto de
interfaces Web baseada nesse princpio (FOWLER, 2003). A Figura 5.2 mostra um
diagrama de pacotes ilustrando o padro MVC.
Figura 6.4 O Padro MVC.

A separao entre viso e controlador d origem a dois tipos de classes que
podem ser organizados em dois pacotes na camada de interface com o usurio: o
Componente de Interao Humana (CIH), que responsvel pelas interfaces com o
usurio propriamente ditas (janelas, painis, botes, menus etc.) e representa a viso no
modelo MVC; e o Componente de Controle de Interao (CCI), que responsvel por
controlar a interao, recebendo requisies da interface, disparando operaes da
lgica de negcio e atualizando a viso com base no retorno dessas operaes. O CCI ,
portanto, o controlador do modelo MVC.
importante frisar que, mesmo quando se opta por no fazer a separao fsica
em pacotes de viso e controlador, til ter classes distintas para desempenhar esses
_________________________________________________________________________________________________________


101
papis. As classes controladoras de interao devem ser marcadas com o esteretipo

<<control>> para diferenci-las das classes de viso, que devem ser marcadas com o
esteretipo <<boundary>>.
No que se refere interao entre as camadas de IU e Lgica de Negcio
(modelo), ela se d de maneiras distintas em funo do padro arquitetnico adotado
nesta ltima. Quando o padro Modelo de Domnio adotado, os controladores de
interao enviam as requisies diretamente para os objetos do domnio do problema
(CDP), uma vez que neste caso no existem objetos gerenciadores de tarefa (CGT).
Quando o padro Camada de Servio adotado, as requisies dos controladores de
interao so enviadas para os objetos gerenciadores de tarefas (CGT).
6.4.2 Componente de Interao Humana (CIH)
A poro do sistema que lida com a viso da interface com o usurio deve ser
mantida to independente e separada do resto da arquitetura do software quanto
possvel. Aspectos de interface com o usurio provavelmente sero alvo de alteraes
ao longo da vida do sistema e essas alteraes devem ter um impacto mnimo nas
demais partes do sistema.
O Componente de Interao Humana (CIH) trata do projeto da interao
humano-computador, definindo formato de janelas, formulrios, relatrios, entre outros.
Durante o projeto do CIH, muito til construir prottipos, de modo a apoiar a seleo
e o desenvolvimento dos mecanismos de interao a serem usados.
Como discutido anteriormente, o ponto de partida para o projeto da CIH o
modelo de casos de uso e as descries de atores e casos de uso. Com base nos casos de
uso, deve-se projetar uma hierarquia de comandos, definindo barras de menus, menus
pull-down, cones etc., que levem execuo dos casos de uso quando acionados pelo
usurio. A hierarquia de comandos deve respeitar convenes e estilos existentes com
os quais o usurio j esteja familiarizado. Note que a hierarquia de comandos , de fato,
um meio de apresentar ao usurio as vrias funcionalidades disponveis no sistema.
Assim, a hierarquia de comandos deve permitir o acesso aos casos de uso do sistema.
Uma vez definida a hierarquia de comandos, as interaes detalhadas entre o
usurio e o sistema devem ser projetadas. Neste momento, til observar atentamente
tticas de usabilidade, discutidas logo adiante.
Normalmente, no necessrio projetar as classes bsicas de interfaces grficas
com o usurio. Existem vrios ambientes de desenvolvimento de interfaces, oferecendo
classes reutilizveis (janelas, cones, botes etc.) e, portanto, basta especializar as
classes e instanciar os objetos que possuem as caractersticas apropriadas para o
problema em questo. Hierarquias de classes de viso podem ser desenvolvidas visando
uniformidade da apresentao e ao reso.
Tticas de Usabilidade
Diversas tticas relativas usabilidade podem ser aplicadas durante o projeto de
IU. Algumas dessas tticas gerais incluem:
_________________________________________________________________________________________________________
102
Facilidade de Ajuda: Ajuda fundamental para os usurios, sobretudo

aqueles novatos ou conhecedores, mas espordicos. Para projetar
adequadamente uma facilidade de ajuda necessrio definir, dentre outros:
quando a ajuda estar disponvel e para que funes do sistema;
como ativar (boto, tecla de funo, menu);
como representar (janela separada, local fixo da tela);
como retornar interao normal (boto, tecla de funo);
como estruturar a informao (estrutura

hipertexto).
plana, hierrquica,
Mensagens de Erro e Avisos: Mais at do que a ajuda, as mensagens de erro e

avisos so fundamentais para uma boa interao humano-computador. Ao
definir mensagens de erro e avisos considere as seguintes diretrizes:
Descreva o problema com um vocabulrio passvel de entendimento

pelo usurio.
Sempre que possvel, proveja assistncia para recuperar o erro.
Quando for o caso, indique as consequncias negativas do erro.
Para facilitar a percepo da mensagem por parte do usurio, pode ser

til que a mesma seja acompanhada de uma dica visual ou sonora.
No censure o usurio.
Tipos de Comandos: Diferentes grupos de usurios tm diferentes

necessidades de interao. Em muitas situaes til prover ao usurio mais
de uma forma de interao. Nestes casos, necessrio definir e avaliar:
se toda opo de menu ter um comando correspondente;
a forma do comando, tais como controle de sequncia (p.ex., ^Q),

teclas de funo (p.ex., F1) e comandos digitados;
quo difcil aprender e lembrar o comando;
possibilidade de customizao de comandos (macros);
padres para todo sistema e conformidade com outros padres, tal

como o definido pelo sistema operacional ou por produtos de
software tipicamente utilizados pelos usurios.
Tempo de Resposta: importante mostrar o progresso do processamento

para os usurios, principalmente para eventos com tempo de resposta longo
ou com grande variao de tempos de resposta.
Levando-se em conta princpios gerais de projeto de IU, algumas orientaes

adicionais devem ser consideradas, dentre elas:
Seja consistente. Use formatos consistentes para seleo de menus, entrada de
comandos, apresentao de dados etc.
Oferea retorno significativo ao usurio.
_________________________________________________________________________________________________________
103
Pea confirmao para aes destrutivas, tais como aes para apagar ou
sobrepor informaes, terminar a seo corrente do aplicativo.
Permita reverso fcil da maioria das aes (funo Desfazer).
Reduza a quantidade de informao que precisa ser memorizada entre aes.
Busque eficincia no dilogo (movimentao, teclas a serem apertadas).
Trate possveis erros do usurio. O sistema deve se proteger de erros, casuais
ou no, provocados pelo usurio.
Classifique atividades por funo e organize geograficamente a tela de
acordo. Menus do tipo pull-down so uma boa opo.
Proveja facilidades de ajuda sensveis ao contexto.
Use verbos de ao simples ou frases curtas para nomear funes e
comandos.
No que se refere apresentao de informaes, considere as seguintes
diretrizes:
Mostre apenas informaes relevantes ao contexto corrente.
Use formatos de apresentao que permitam assimilao rpida da
informao, tais como grficos e figuras.
Use rtulos consistentes, abreviaturas padro e cores previsveis.
Produza mensagens de erro significativas.
Projete adequadamente o layout de informaes textuais. Leve em
considerao o bom uso de letras maisculas e minsculas, identao,
agrupamento de informaes etc.
Separe diferentes tipos de informao. Painis ou mesmo janelas podem ser
usadas para este fim.
Use formas de representao anlogas s do mundo real para facilitar a
assimilao da informao. Para tal considere o uso de figuras, cores etc.
No que se refere entrada de dados, considere as seguintes diretrizes:
Minimize o nmero de aes de entrada requeridas e possveis erros. Para tal
considere a seleo de dados a partir de um conjunto pr-definido de valores
de entrada, o uso de valores default e macros etc.
Mantenha consistncia entre apresentao e entrada de dados; ou seja,
mantenha as mesmas caractersticas visuais, dentre elas tamanho do texto, cor
e localizao.
Permita ao usurio customizar a entrada para seu uso, quando possvel,
dando-lhe liberdade para definir comandos customizados, dispensar algumas
mensagens de aviso e verificaes de aes, dentre outros.
Flexibilize a interao, permitindo afin-la ao modo de entrada preferido do
usurio (comandos, botes, plug-and-play, digitao etc.).
_________________________________________________________________________________________________________
104
Desative comandos inapropriados para o contexto das aes correntes.

Proveja ajuda significativa para assistir as aes de entrada de dados.
Nunca requeira que o usurio entre com uma informao que possa ser
adquirida automaticamente pelo sistema ou computada por ele.
6.4.3 Componente de Controle de Interao (CCI)
O Componente de Controle de Interao (CCI) trata das classes responsveis por
controlar a interao (ativao / desativao dos objetos do CIH) e enviar requisies
para os objetos da Lgica de Negcio.
Em sistemas rodando em plataforma desktop, deve haver pelo menos uma classe
controladora, dita classe controladora de sistema, representando o sistema como um
todo. Os objetos dessa classe representam as vrias sesses (execues) do sistema.
Neste caso, necessrio levar em conta, ainda, quantos executveis devem ser gerados
para o sistema. Se mais do que um for necessrio, cada executvel ter de dar origem a
uma classe controladora. Esta, contudo, apenas uma abordagem possvel.
Analogamente ao projeto do CGT (veja seo 4.4), possvel definir um nmero
arbitrrio de controladores de interao. Uma opo em linha com o projeto da CGT
definir um controlador de interao para cada caso de uso. Contudo, uma vez que as
classes controladoras de interao tendem a ser muito simples, essa abordagem pode ser
exagerada. Assim, ainda que haja uma analogia entre o projeto do CCI e o projeto do
CGT, as motivaes so bastante diferentes e a escolha dos controladores de interao
tende a ser diferente da escolha dos gerenciadores de tarefas.
6.5 A Camada de Gerncia de Dados (CGD)

A maioria dos sistemas requer alguma forma de armazenamento de dados. Para
tal, h vrias alternativas, dentre elas a persistncia em arquivos e bancos de dados. Em
especial os sistemas de informao envolvem grandes quantidades de dados e fazem uso
de sistemas gerenciadores de bancos de dados (SGBDs). H diversos tipos de SGBDs,
dentre eles os relacionais e os orientados a objetos, sendo os primeiros os mais
utilizados atualmente no desenvolvimento de sistemas de informao.
Quando SGBDs Relacionais so utilizados, necessrio um mapeamento entre
as estruturas de dados dos modelos orientado a objetos e relacional, de modo que
objetos possam ser armazenados em tabelas. Dentre as principais diferenas entre esses
modelos, destacam-se as diferentes formas como objetos e tabelas tratam ligaes e na
ausncia do mecanismo de herana no modelo relacional. Essas diferenas levam
necessidade de reverses das estruturas de dados entre objetos e tabelas, tratadas como
mapeamento objeto-relacional.
Alm das diferenas estruturais, outros aspectos tm de ser tratados durante o
projeto da persistncia, dentre eles o modo como a camada de lgica de negcio se
comunica com o banco de dados, o problema comportamental que diz respeito a como
obter vrios objetos do banco e como salv-los, e o tratamento de conexes com o
banco de dados e transaes (FOWLER, 2003).
importante enfatizar que muitos desses problemas so tratados por frameworks
de persistncia de objetos em bancos de dados relacionais (ou frameworks de
_________________________________________________________________________________________________________
105
mapeamento objeto-relacional), tal como o Hibernate24. Os desenvolvedores desses

frameworks tm despendido muitos esforos trabalhando nesses problemas e tais
ferramentas so bem mais sofisticadas do que a maioria das solues especficas que
podem ser construdas mo. Contudo, mesmo quando um framework de mapeamento
objeto-relacional (O/R) utilizado, importante estar ciente dos padres usados. Boas
ferramentas de mapeamento O/R do vrias opes de mapeamento para um banco de
dados e esses padres vo ajud-lo a entender quando selecionar as diferentes opes
(FOWLER, 2003).
A seguir aso apresentados alguns padres para o projeto do Componente de
Gerncia de Dados.
6.5.1 Padres Arquitetnicos para a Camada de Gerncia de Dados
A Camada de Persistncia (ou Camada de Gerncia de Dados ou, ainda,
Componente de Gerncia de Dados - CGD) prov a infraestrutura bsica para o
armazenamento e a recuperao de objetos no sistema. Sua finalidade isolar os
impactos da tecnologia de gerenciamento de dados sobre a arquitetura do software
(COAD; YOURDON, 1993).
A despeito da opo de persistncia adotada (SGBD relacional, SGBD orientado
a objetos, arquivos), h uma importante questo a ser considerada no projeto do CGD:
Que classes devem suportar a persistncia dos objetos?
Uma abordagem consiste em isolar completamente a lgica de negcio e o
banco de dados, criando uma camada responsvel pelo mapeamento entre objetos do
domnio e tabelas do banco de dados. Os padres Mapeador de Dados (Data Mapper)
(FOWLER, 2003) e Objeto de Acesso a Dados (Data Access Object - DAO) (BAUER;
KING, 2007) adotam esta filosofia, de modo que apenas uma parte da arquitetura de
software fica ciente da tecnologia de persistncia adotada. Essa parte, o Componente de
Gerncia de Dados (CGD), serve como uma camada intermediria separando objetos do
domnio de objetos de gerncia de dados. Via conexes de mensagem, o CGD l e
escreve dados, estabelecendo uma comunicao entre a base de dados e os objetos do
sistema. Qualquer cdigo SQL25 est confinado nessas classes, de modo que no cdigo
desse tipo em outras classes da arquitetura do software.
O Padro Data Mapper
O padro Mapeador de Dados (FOWLER, 2003) prescreve uma camada de
objetos mapeadores que transferem dados entre objetos em memria e o banco de
dados, mantendo-os independentes um do outro e dos mapeadores em si. Os objetos em
memria no tm qualquer conhecimento acerca do esquema do banco de dados e no
precisam de nenhuma interface para cdigo SQL. De fato, eles no precisam saber
sequer que h um banco de dados. O banco de dados, por sua vez, desconhece
completamente os objetos que o utilizam.
24
http://www.hibernate.org/
SQL a abreviatura de Structured Query Language (Linguagem Estruturada de Consulta), a linguagem
de consulta dos bancos de dados relacionais.
25
_________________________________________________________________________________________________________
106
Em sua verso mais simples, para cada classe a ser persistida em uma tabela, h
uma correspondente classe mapeadora. Seja o exemplo da Figura 6.6. Nesse exemplo, a
classe mapeadora PersonMapper intermedeia a classe Person da lgica de negcio e o
acesso a seus dados no banco de dados, na correspondente tabela (FOWLER, 2003).
Figura 6.5 Padro Data Mapper (FOWLER, 2003).

O Padro DAO
O padro DAO define uma interface de operaes de persistncia, incluindo
mtodos para criar, recuperar, alterar, excluir e diversos tipos de consulta, relativa a
uma particular entidade persistente, agrupando o cdigo relacionado persistncia
daquela entidade (BAUER; KING, 2007). A estrutura bsica do padro, como proposto
em (BAUER; KING, 2007), apresentada na Figura 6.7.
Figura 6.6 Padro DAO (BAUER; KING, 2007).

Seguindo esse padro, a camada de persistncia implementada por duas
hierarquias paralelas: interfaces esquerda e implementaes direita. As operaes
bsicas de armazenamento e recuperao de objetos so agrupadas em uma interface
genrica (GenericDAO) e uma superclasse genrica (no exemplo da Figura 6.6,
_________________________________________________________________________________________________________
107
GenericDAOHibernate). Esta ltima implementa as operaes com uma particular

soluo de persistncia (no caso, Hibernate). A interface genrica estendida por
interfaces para entidades especficas que requerem operaes adicionais de acesso a
dados. O mesmo ocorre com a hierarquia de classes de implementao. Uma
caracterstica marcante desta soluo que possvel ter vrias implementaes de uma
mesma interface DAO (BAUER; KING, 2007).
Leitura Complementar
No Captulo 7 de (WAZLAWICK, 2004) Projeto da Camada de Domnio,
aspectos do projeto da Lgica de Negcio so discutidos, incluindo modelos de domnio
ricos e padres de projeto associados, possveis modificaes a serem feitas nos
diagramas de classes de projeto.
Em (FOWLER, 2003), o Captulo 2 Organizing Domain Logic discute a
organizao da camada de lgica de negcio. No Captulo 9 Domain Logic Patterns
so apresentados padres para a camada lgica de negcio.
Em (FOWLER, 2003), o Captulo 4 Web Presentation discute diversos
aspectos do projeto da interface com o usurio de aplicaes Web. Os padres
discutidos nesse captulo so posteriormente apresentados em detalhes no Captulo 14
Web Presentation Patterns.
Em (PRESSMAN, 2006), o Captulo 12 Projeto de Interface com o Usurio
discute princpios gerais do projeto da IU (seo 12.1) e o processo de anlise, projeto e
avaliao de IU (sees 12.2 a 12.5).
O Captulo 9 de (WAZLAWICK, 2004) Projeto da Camada de Interface, trata
do projeto da camada de Interface com o Usurio focalizando aspectos da navegao do
sistema e controle de segurana.
Em (FOWLER, 2003), o Captulo 3 Mapping to Relational Databases
discute diversos aspectos do projeto da persistncia de objetos em bancos de dados
relacionais.
O Captulo 10 de (WAZLAWICK, 2004) Projeto da Camada de Persistncia,
trata do projeto da camada de persistncia, incluindo equivalncias entre modelos de
classes e modelos relacionais e aspectos relativos a como e quando os objetos sero
salvos e carregados do banco de dados.
Bauer e King (2007) discutem vrios aspectos do projeto da camada de
persistncia, indo desde mapeamento O/R at detalhes de implementao usando o
framework Hibernate.
Referncias do Captulo
BAUER, C., KING, G., Java Persistence with Hibernate, Manning, 2007.
BUSCHMANN, F., MEUNIER, R., ROHNERT, H., SOMMERLAD, P., STAL, M.,
Pattern-Oriented Software Architecture: A System of Patterns, Volume 1, Wiley,
1996.
COAD, P., YOURDON, E., Projeto Baseado em Objetos, Editora Campus, 1993.
_________________________________________________________________________________________________________
108
FOWLER, M., Patterns of Enterprise Application Architecture, Addison-Wesley, 2003.

2 edio, 2004.
SOUZA, V.E.S., FrameWeb: um Mtodo baseado em Frameworks para o Projeto de
Sistemas de Informao Web, Dissertao de Mestrado, Programa de PsGraduao em Informtica, UFES, Universidade Federal do Esprito Santo, 2005.
WAZLAWICK, R.S., Anlise e Projeto de Sistemas de Informao Orientados a
Objetos, Elsevier, 2004.
_________________________________________________________________________________________________________

Captulo 7 Implementao e Testes

109

Uma vez projetado o sistema, necessrio escrever os programas que
implementem esse projeto e test-los.
7.1 - Implementao
Ainda que um projeto bem elaborado facilite sobremaneira a implementao,
essa tarefa no necessariamente fcil. Muitas vezes, os projetistas no conhecem em
detalhes a plataforma de implementao e, portanto, no so capazes de (ou no
desejam) chegar a um projeto algortmico passvel de implementao direta. Alm
disso, questes relacionadas legibilidade, alterabilidade e reutilizao tm de ser
levadas em conta.
Deve-se considerar, ainda, que programadores, geralmente, trabalham em
equipe, necessitando integrar, testar e alterar cdigo produzido por outros. Assim,
muito importante que haja padres organizacionais para a fase de implementao. Esses
padres devem ser seguidos por todos os programadores e devem estabelecer, dentre
outros, padres de nomes de variveis, formato de cabealhos de programas e formato
de comentrios, recuos e espaamento, de modo que o cdigo e a documentao a ele
associada sejam claros para quaisquer membros da organizao.
Padres para cabealho, por exemplo, podem informar o que o cdigo
(programa, mdulo ou componente) faz, quem o escreveu, como ele se encaixa no
projeto geral do sistema, quando foi escrito e revisado, apoios para teste, entrada e sada
esperadas etc. Essas informaes so de grande valia para a integrao, testes,
manuteno e reutilizao (PFLEEGER, 2004).
Alm dos comentrios feitos no cabealho dos programas, comentrios
adicionais ao longo do cdigo so tambm importantes, ajudando a compreender como
o componente implementado.
Por fim, o uso de nomes significativos para variveis, indicando sua utilizao e
significado, imprescindvel, bem como o uso adequado de recuo e espaamento entre
linhas de cdigo, que ajudam a visualizar a estrutura de controle do programa
(PFLEEGER, 2004).
Alm da documentao interna, escrita no prprio cdigo, importante que o
cdigo de um sistema possua tambm uma documentao externa, incluindo uma viso
geral dos componentes do sistema, grupos de componentes e da inter-relao entre eles
(PFLEEGER, 2004).
Ainda que padres sejam muito importantes, deve-se ressaltar que a
correspondncia entre os componentes do projeto e o cdigo fundamental,
caracterizando-se como a mais importante questo a ser tratada. O projeto o guia para
a implementao, ainda que o programador deva ter certa flexibilidade para
implement-lo como cdigo (PFLEEGER, 2004).
Como resultado de uma implementao bem-sucedida, as unidades de software
devem ser codificadas e critrios de verificao das mesmas devem ser definidos.
_________________________________________________________________________________________________________
(Adaptao por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Software de Ricardo de Almeida Falbo)


110
7.2 - Testes
Uma vez implementado o cdigo de uma aplicao, o mesmo deve ser testado
para descobrir tantos defeitos quanto possvel, antes da entrega do produto de software
ao seu cliente.
Conforme discutido no Captulo 4 (Parte I do material), o teste uma atividade
de verificao e validao do software e consiste na anlise dinmica do mesmo, isto ,
na execuo do produto de software com o objetivo de verificar a presena de defeitos
no produto e aumentar a confiana de que o mesmo est correto (MALDONADO e
FABBRI, 2001).
Vale ressaltar que, mesmo se um teste no detectar defeitos, isso no quer dizer
necessariamente que o produto um produto de boa qualidade. Muitas vezes, a
atividade de teste empregada pode ter sido conduzida sem planejamento, sem critrios e
sem uma sistemtica bem definida, sendo, portanto, os testes de baixa qualidade
(MALDONADO e FABBRI, 2001).
Assim, o objetivo projetar testes que potencialmente descubram diferentes
classes de erros e faz-lo com uma quantidade mnima de esforo (PRESSMAN, 2006).
Ainda que os testes no possam demonstrar a ausncia de defeitos, como benefcio
secundrio, podem indicar que as funes do software parecem estar funcionando de
acordo com o especificado.
A idia bsica dos testes que os defeitos podem se manifestar por meio de
falhas observadas durante a execuo do software. Essas falhas podem ser resultado de
uma especificao errada ou falta de requisito, de um requisito impossvel de
implementar considerando o hardware e o software estabelecidos, o projeto pode conter
defeitos ou o cdigo pode estar errado. Assim, uma falha o resultado de um ou mais
defeitos (PFLEEGER, 2004).
So importantes princpios de testes a serem observados (PRESSMAN, 2006;
PFLEEGER, 2004 ):
Teste completo no possvel, ou seja, mesmo para sistemas de tamanho

moderado, pode ser impossvel executar todas as combinaes de caminhos
durante o teste.
Teste envolve vrios estgios. Geralmente, primeiro, cada mdulo testado

isoladamente dos demais mdulos do sistema (teste de unidade). medida
que os testes progridem, o foco se desloca para a integrao dos mdulos
(teste de integrao), at se chegar ao sistema como um todo (teste de
sistema).
Teste deve ser conduzido por terceiros. Os testes conduzidos por outras
pessoas que no aquelas que produziram o cdigo tm maior probabilidade
de encontrar defeitos. O desenvolvedor que produziu o cdigo pode estar
muito envolvido com ele para poder detectar defeitos mais sutis.
Testes devem ser planejados bem antes de serem realizados. Um plano de

testes deve ser utilizado para guiar todas as atividades de teste e deve incluir
objetivos do teste, abordando cada tipo (unidade, integrao e sistema),
como sero executados e quais critrios a serem utilizados para determinar
_________________________________________________________________________________________________________


111
quando o teste est completo. Uma vez que os testes esto relacionados aos
requisitos dos clientes e usurios, o planejamento dos testes pode comear
to logo a especificao de requisitos tenha sido elaborada. medida que o
processo de desenvolvimento avana (anlise, projeto e implementao),
novos testes vo sendo planejados e incorporados ao plano de testes.
O processo de teste envolve quatro atividades principais (PFLEEGER, 2004,
MALDONADO e FABBRI, 2001):
Planejamento de Testes: trata da definio das atividades de teste, das

estimativas dos recursos necessrios para realiz-las, dos objetivos,
estratgias e tcnicas de teste a serem adotadas e dos critrios para
determinar quando uma atividade de teste est completa.
Projeto de Casos de Testes: a atividade chave para um teste bem-sucedido,

ou seja, para se descobrir a maior quantidade de defeitos com o menor
esforo possvel. Os casos de teste devem ser cuidadosamente projetados e
avaliados para tentar se obter um conjunto de casos de teste que seja
representativo e envolva as vrias possibilidades de exerccio das funes do
software (cobertura dos testes). Existe uma grande quantidade de tcnicas de
teste para apoiar os testadores a projetar casos de teste, oferecendo uma
abordagem sistemtica para o teste de software.
Execuo dos testes: consiste na execuo dos casos de teste e registro de

seus resultados.
Avaliao dos resultados: detectadas falhas, os defeitos devero ser

procurados. No detectadas falhas, deve-se fazer uma avaliao final da
qualidade dos casos de teste e definir pelo encerramento ou no de uma
atividade de teste.
7.2.1 Tcnicas de Teste

Para testar um mdulo, necessrio definir um caso de teste, executar o mdulo
com os dados de entrada definidos por esse caso de teste e analisar a sada. Um teste
um conjunto limitado de casos de teste, definido a partir do objetivo do teste
(PFLEEGER, 2004).
Diversas tcnicas de teste tm sido propostas visando apoiar o projeto de casos
de teste. Essas tcnicas podem ser classificadas, segundo a origem das informaes
utilizadas para estabelecer os objetivos de teste, em, dentre outras categorias, tcnicas
funcional, estrutural ou baseadas em mquinas de estado (MALDONADO e FABBRI,
2001).
Os testes funcionais ou caixa-preta utilizam as especificaes (de requisitos,
anlise e projeto) para definir os objetivos do teste e, portanto, para guiar o projeto de
casos de teste. O conhecimento sobre uma determinada implementao no usado
(MALDONADO e FABBRI, 2001). Assim, os testes so conduzidos na interface do
software. Os testes caixa-preta so empregados para demonstrar que as funes do
software esto operacionais, que a entrada adequadamente aceita e a sada
corretamente produzida e que a integridade da informao externa (uma base de dados,
por exemplo) mantida (PRESSMAN, 2006).
_________________________________________________________________________________________________________


112
Os testes estruturais ou caixa-branca estabelecem os objetivos do teste com base

em uma determinada implementao, verificando detalhes do cdigo. Caminhos lgicos
internos so testados, definindo casos de testes que exercitem conjuntos especficos de
condies ou laos (PRESSMAN, 2006).
Os testes baseados em mquinas de estado so projetados utilizando o
conhecimento subjacente estrutura de uma mquina de estados para determinar os
objetivos do teste (MALDONADO e FABBRI, 2001).
importante ressaltar que tcnicas de teste devem ser utilizadas de forma
complementar, j que elas tm propsitos distintos e detectam categorias de erros
distintas (MALDONADO e FABBRI, 2001). primeira vista, pode parecer que
realizando testes caixa branca rigorosos poderamos chegar a programas corretos.
Contudo, conforme anteriormente mencionado, isso no prtico, uma vez que todas as
combinaes possveis de caminhos e valores de variveis teriam de ser exercitadas, o
que impossvel. Isso no quer dizer, entretanto, que os testes caixa-branca no so
teis. Testes caixa-branca podem ser usados, por exemplo, para garantir que todos os
caminhos independentes26 de um mdulo tenham sido exercitados pelo menos uma vez
(PRESSMAN, 2006).
H diversas tcnicas de testes caixa-branca, cada uma delas procurando apoiar o
projeto de casos de teste focando em algum ou vrios aspectos da implementao.
Dentre elas, podem ser citadas (PRESSMAN, 2006):
Testes de estrutura de controle: como o prprio nome diz, enfocam as

estruturas de controle de um mdulo, tais como comandos, condies e
laos. Teste de condio um tipo de teste de estrutura de controle que
exercita as condies lgicas contidas em um mdulo. Um teste de fluxo de
dados, por sua vez, seleciona caminhos de teste tomando por base a
localizao das definies e dos usos das variveis nos mdulos. Testes de
ciclo ou lao focalizam exclusivamente os laos (loops).
Teste de caminho bsico: define uma medida de complexidade lgica de

um mdulo e usa essa medida como guia para definir um conjunto bsico de
caminhos de execuo.
Assim como h diversas tcnicas de teste caixa-branca, o mesmo acontece em

relao ao teste caixa-preta. Dentre as diversas tcnicas de teste caixa-preta, podem ser
citadas (PRESSMAN, 2006):
Particionamento de equivalncia: divide o domnio de entrada de um

mdulo em classes de equivalncia, a partir das quais casos de teste so
derivados. A meta minimizar o nmero de casos de teste, ficando apenas
com um caso de teste para cada classe, uma vez que, a princpio, todos os
elementos de uma mesma classe devem se comportar de maneira
equivalente.
Anlise de valor limite: a prtica mostra que um grande nmero de erros

tende a ocorrer nas fronteiras do domnio de entrada de um mdulo. Tendo
isso em mente, a anlise de valor limite leva seleo de casos de teste que
exercitem os valores limtrofes.
26
Um caminho independente qualquer caminho ao longo de um mdulo que introduz pelo menos um
novo comando de processamento ou condio (PRESSMAN, 2006).
_________________________________________________________________________________________________________


113
7.2.2 Estratgias de Teste

O projeto efetivo de casos de teste importante, mas no suficiente para o
sucesso da atividade de testes. A estratgia, isto , a srie planejada de realizao dos
testes, tambm crucial (PRESSMAN, 2006). Basicamente, h trs grandes fases de
teste (MALDONADO e FABBRI, 2001):
Teste de Unidade: tem por objetivo testar a menor unidade do projeto (um
componente de software que no pode ser subdividido), procurando
identificar erros de lgica e de implementao em cada mdulo
separadamente. No paradigma estruturado, a menor unidade refere-se a um
procedimento ou funo.
Teste de Integrao: visa a descobrir erros associados s interfaces entre os

mdulos quando esses so integrados para formar estrutura do produto de
software.
Teste de Sistema: tem por objetivo identificar erros de funes (requisitos

funcionais) e caractersticas de desempenho (requisito no funcional) que
no estejam de acordo com as especificaes.
Tomando por base essas fases, a atividade de teste pode ser estruturada de modo
que, em cada fase, diferentes tipos de erros e aspectos do software sejam considerados
(MALDONADO e FABBRI, 2001). Tipicamente, os primeiros testes focalizam
componentes individuais e aplicam testes caixa-branca e caixa-preta para descobrir
erros. Aps os componentes individuais terem sido testados, eles precisam ser
integrados, at se obter o sistema por inteiro. Na integrao, o foco o projeto e a
arquitetura do sistema. Finalmente, uma srie de testes de alto nvel executada quando
o sistema estiver operacional, visando a descobrir erros nos requisitos (PRESSMAN,
2006, PFLEEGER, 2004).
No teste de unidade, faz-se necessrio construir pequenos componentes para
permitir testar os mdulos individualmente, os ditos drivers e stubs. Um driver um
programa responsvel pela ativao e coordenao do teste de uma unidade. Ele
responsvel por receber os dados de teste fornecidos pelo testador, passar esses dados
para a unidade sendo testada, obter os resultados produzidos por essa unidade e
apresent-los ao testador. Um stub uma unidade que substitui, na hora do teste, uma
outra unidade chamada pela unidade que est sendo testada. Em geral, um stub simula o
comportamento da unidade chamada com o mnimo de computao ou manipulao de
dados (MALDONADO e FABBRI, 2001).
A abordagem de integrao de mdulos pode ter impacto na quantidade de
drivers e stubs a ser construda. Sejam as seguintes abordagens:
Integrao ascendente ou bottom-up: Nessa abordagem, primeiramente,

cada mdulo no nvel inferior da hierarquia do sistema testado
individualmente. A seguir, so testados os mdulos que chamam esses
mdulos previamente testados. Esse procedimento repetido at que todos
os mdulos tenham sido testados (PFLEEGER, 2004). Neste caso, apenas
drivers so necessrios. Seja o exemplo da figura 7.1. Usando a abordagem
de integrao ascendente, os mdulos seriam testados da seguinte forma.
Inicialmente, seriam testados os mdulos do nvel inferior (E, F e G). Para
_________________________________________________________________________________________________________

114
cada um desses testes, um driver teria de ser construdo. Concludos esses

testes, passaramos ao nvel imediatamente acima, testando seus mdulos (B,
C e D) combinados com os mdulos por eles chamados. Neste caso,
testamos juntos B, E e F bem como C e G. Novamente, trs drivers seriam
necessrios. Por fim, testaramos todos os mdulos juntos.
A
Figura 7.1 Exemplo de uma hierarquia de mdulos.
Integrao descendente ou top-down: A abordagem, neste caso,

precisamente o contrrio da anterior. Inicialmente, o nvel superior
(geralmente um mdulo de controle) testado sozinho. Em seguida, todos os
mdulos chamados por pelo mdulo testado so combinados e testados como
uma grande unidade. Essa abordagem repetida at que todos os mdulos
tenham sido incorporados (PFLEEGER, 2004). Neste caso, apenas stubs so
necessrios. Tomando o exemplo da figura 7.1, o teste iniciaria pelo mdulo
A e trs stubs (para B, C e D) seriam necessrios. Na seqncia seriam
testados juntos A, B, C e D, sendo necessrios stubs para E, F e G. Por fim, o
sistema inteiro seria testado.
Muitas outras abordagens, algumas usando as apresentadas anteriormente,

podem ser adotadas, tal como a integrao sanduche (PFLEEGER, 2004), que
considera uma camada alvo no meio da hierarquia e utiliza as abordagens ascendente e
descendente, respectivamente para as camadas localizadas abaixo e acima da camada
alvo. Outra possibilidade testar individualmente cada mdulo e s depois de testados
individualmente integr-los (teste big-band). Neste caso, tanto drivers quanto stubs tm
de ser construdos para cada mdulo, o que leva a muito mais codificao e problemas
em potencial (PFLEEGER, 2004).
Uma vez integrados todos os mdulos do sistema, parte-se para os testes de
sistema, quando se busca observar se o software funciona conforme esperado pelo
cliente. Por isso mesmo, muitas vezes, os testes de sistema so chamados de testes de
validao. Os testes de sistema incluem diversos tipos de teste, realizados na seguinte
ordem (PFLEEGER, 2004):
Teste funcional: verifica se o sistema integrado realiza as funes

especificadas nos requisitos;
Teste de desempenho: verifica se o sistema integrado atende os requisitos

no funcionais do sistema (eficincia, segurana, confiabilidade etc);
Teste de aceitao: os testes funcional e de desempenho so ainda realizados

por desenvolvedores, entretanto necessrio que o sistema seja testado pelos
clientes. No teste de aceitao, os clientes testam o sistema a fim de garantir
_________________________________________________________________________________________________________
115
que o mesmo satisfaz suas necessidades. Vale destacar que o que foi
especificado pelos desenvolvedores pode ser diferente do que queria o
cliente. Assim, o teste de aceitao assegura que o sistema solicitado o que
foi construdo.
Teste de instalao: algumas vezes o teste de aceitao feito no ambiente

real de funcionamento, outras no. Quando o teste de aceitao for feito em
um ambiente de teste diferente do local em que ser instalado, necessrio
realizar testes de instalao.
Referncias
PFLEEGER, S.L., Engenharia de Software: Teoria e Prtica, So Paulo: Prentice
Hall, 2 edio, 2004.
MALDONADO, J. C., FABBRI, S.C.P.F., Teste de Software. In: Qualidade de
Software: Teoria e Prtica, Eds. A.R.C. Rocha, J.C. Maldonado, K. Weber,
Prentice Hall, 2001.
_________________________________________________________________________________________________________

Captulo 8 Entrega e Manuteno

116

Concludos os testes, sistema aceito e instalado, estamos chegando ao fim do
processo de desenvolvimento de software. A entrega a ltima etapa desse processo.
Uma vez entregue, o sistema passa a estar em operao e eventuais mudanas, sejam de
carter corretivo, sejam de carter de evoluo, caracterizam-se como uma manuteno.
8.1 - Entrega
A entrega no meramente uma formalidade. No momento em que o sistema
instalado no local de operao e devidamente aceito, necessrio, ainda, ajudar os
usurios a entenderem e a se sentirem mais familiarizados com o sistema. Neste
momento, duas questes so cruciais para uma transferncia bem-sucedida: treinamento
e documentao (PFLEEGER, 2004).
A operao do sistema extremamente dependente de pessoal com
conhecimento e qualificao. Portanto, essencial que o treinamento de pessoal seja
realizado para que os usurios e operadores possam operar o sistema adequadamente.
A documentao que acompanha o sistema tambm tem papel crucial na entrega,
afinal ela ser utilizada como material de referncia para a soluo de problemas ou
como informaes adicionais. Essa documentao inclui, dentre outros, manuais do
usurio e do operador, guia geral do sistema, tutoriais, ajuda (help), preferencialmente
on-line e guias de referncia rpida (PFLEEGER, 2004).
8.2 - Manuteno
O desenvolvimento de um sistema termina quando o produto entregue para o
cliente e entra em operao. A partir da, deve-se garantir que o sistema continuar a ser
til e atendendo s necessidades do usurio, o que pode demandar alteraes no mesmo.
Comea, ento, a fase de manuteno (SANCHES, 2001).
H muitas causas para a manuteno, dentre elas (SANCHES, 2001): falhas no
processamento devido a erros no software, falhas de desempenho, alteraes no
ambiente de dados, alteraes no ambiente de processamento, necessidade de
modificaes em funes existentes e necessidade de incluso de novas capacidades.
Ao contrrio do que podemos pensar, a manuteno no uma atividade trivial
nem de pouca relevncia. Ela uma atividade importantssima e de intensa necessidade
de conhecimento. O mantenedor precisa conhecer o sistema, o domnio de aplicao, os
requisitos do sistema, a organizao que utiliza o mesmo, prticas de engenharia de
software passadas e atuais, a arquitetura do sistema, algoritmos usados etc.
O processo de manuteno semelhante, mas no igual, ao processo de
desenvolvimento e pode envolver atividades de levantamento de requisitos, anlise,
projeto, implementao e testes, agora no contexto de um software existente. Essa
_________________________________________________________________________________________________________
117
semelhana pode ser maior ou menor, dependendo do tipo de manuteno a ser

realizada.
Pfleeger (PFLEEGER, 2004) aponta os seguintes tipos de manuteno:
Manuteno corretiva: trata de problemas decorrentes de defeitos.

medida que falhas ocorrem, elas so relatadas equipe de manuteno, que
se encarrega de encontrar o defeito que causou a falha e faz as correes (nos
requisitos, anlise, projeto ou implementao), conforme o necessrio. Esse
reparo inicial pode ser temporrio, visando manter o sistema funcionando.
Quando esse for o caso, mudanas mais complexas podem ser
implementadas posteriormente.
Manuteno adaptativa: s vezes, uma mudana no ambiente do sistema,

incluindo hardware e software de apoio, pode implicar em uma necessidade
de adaptao.
Manuteno perfectiva: consiste em realizar mudanas para melhorar

algum aspecto do sistema, mesmo quando nenhuma das mudanas for
conseqncia de defeitos. Isso inclui a adio de novas capacidades bem
como ampliaes gerais.
Manuteno preventiva: consiste em realizar mudanas a fim de prevenir

falhas. Geralmente ocorre quando um mantenedor descobre um defeito que
ainda no causou falha e decide corrigi-lo antes que ele gere uma falha.
Referncias
2 edio, 2004.
SANCHES, R., Processo de Manuteno. In: Qualidade de Software: Teoria e
Prtica, Eds. A.R.C. Rocha, J.C. Maldonado, K. Weber, Prentice Hall, 2001.
_________________________________________________________________________________________________________

Apostila Projeto 02 Falbo Mona

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Apostila Projeto 02 Falbo Mona

Enviado por

Direitos autorais:

Formatos disponíveis

UFES - Universidade Federal do Esprito Santo

Ricardo de Almeida Falbo

Curso: Engenharia da Computao

Adaptao, em 2011, por Monalessa Perini Barcellos das Notas de Aula de

Observao: Este material aborda contedos que vo alm do programa da

6.3 A Camada de Domnio do Problema.............................................................................. 91

Engenharia de Software: Notas de Aula

Captulo 1 Introduo captulo de introduo ao contedo.

Captulo 2 Processo de Software enfoca os processos de software, os

Captulo 3 Gerncia de Projetos so abordadas as principais atividades da

Captulo 4 Gerncia da Qualidade trata de algumas atividades

Este material constitui a Parte II das Notas de Aula de Engenharia de Software e

Captulo 5 Especificao e Anlise de Requisitos so discutidos o que

Captulo 6 Projeto de Sistema aborda os conceitos bsicos de projeto de

Captulo 7 Implementao e Testes so enfocadas as atividades de

Captulo 8 Entrega e Manuteno discute as questes relacionadas

Engenharia de Software: Notas de Aula

Captulo 5 Especificao e Anlise de Requisitos

UFES - Universidade Federal do Esprito Santo

Captulo 5 Especificao e Anlise de Requisitos

5.1 Engenharia de Requisitos de Software

Engenharia de Software: Notas de Aula

Captulo 5 Especificao e Anlise de Requisitos

UFES - Universidade Federal do Esprito Santo

Levantamento (ou Descoberta ou Elicitao) de Requisitos: Nesta fase, os

Anlise de Requisitos: visa a estabelecer um conjunto acordado de requisitos

Documentao de Requisitos: a atividade de representar os resultados da

Verificao e Validao de Requisitos: A verificao de requisitos avalia se o

Gerncia de Requisitos: se preocupa em gerenciar as mudanas nos requisitos j

possvel notar que, das cinco atividades do processo de Engenharia de

Engenharia de Software: Notas de Aula

Captulo 5 Especificao e Anlise de Requisitos

UFES - Universidade Federal do Esprito Santo

documentao, garantia da qualidade e gerncia de configurao. Assim sendo, neste

possibilitar o estudo do comportamento do sistema;

facilitar a comunicao entre os componentes da equipe de desenvolvimento

possibilitar a discusso de correes e modificaes com o usurio;

formar a documentao do sistema.

Um modelo enfatiza um conjunto de caractersticas da realidade, que

conceitual: considera caractersticas do sistema independentes do ambiente

lgico: caractersticas dependentes de um determinado tipo de sistema

fsico: caractersticas dependentes de um sistema computacional especfico, isto

Engenharia de Software: Notas de Aula

Captulo 5 Especificao e Anlise de Requisitos

UFES - Universidade Federal do Esprito Santo

modelos podem ser construdos tanto na fase de projeto quanto na fase de

5.2 O Paradigma Orientado a Objetos

Captulo 5 Especificao e Anlise de Requisitos

Engenharia de Software: Notas de Aula

tenta gerenciar a complexidade inerente dos problemas do mundo real, abstraindo

Figura 5.1 Ilustrao do Conceito de Abstrao.

Engenharia de Software: Notas de Aula

Captulo 5 Especificao e Anlise de Requisitos

UFES - Universidade Federal do Esprito Santo

Figura 5.2 Ilustrao do Conceito de Encapsulamento.

Engenharia de Software: Notas de Aula

Captulo 5 Especificao e Anlise de Requisitos

UFES - Universidade Federal do Esprito Santo

Engenharia de Software: Notas de Aula

Captulo 5 Especificao e Anlise de Requisitos

UFES - Universidade Federal do Esprito Santo

Figura 5.3 Ilustrao do conceito de Classificao (BOOCH, 1994).

Engenharia de Software: Notas de Aula

Captulo 5 Especificao e Anlise de Requisitos