Engenharia de Software II- Parte 1

Descrio do sistema-exemplo Revista Digital

O objetivo deste sistema permitir a professores e alunos uma ferramenta para
submisso e acesso a artigos produzidos por professores da PUC Minas
pertencentes aos diversos cursos da mesma. As funcionalidades requeridas so as
seguintes:
-Autenticao de usurios em trs nveis: leitor, autor e administrador.
-Pesquisar documentos por ttulo, nome do autor, cdigo RT e palavras-chaves.
-Fazer o download de documentos pesquisados.
-Submisso (upload) de arquivos para reviso.
-Publicao de arquivos em cadernos peridicos.
-Definir revisores de documentos.
-Registrar autores e revisores de documentos.
-Permitir o registro da reviso do documento.
-Permitir a incluso/excluso/busca/alterao de administradores, leitores,
revisores, cursos e tpicos (assuntos)

1-Processo de desenvolvimento adotado

Um processo , em essncia, uma cadeia de atividades a serem realizadas
durante o desenvolvimento do software. O processo que aqui propomos apresenta
atividades para as disciplinas de Requisitos, Anlise, Projeto e Implementao do
Rational Unified Process (RUP). As outras disciplinas, ainda que importantes e
essenciais, no esto no escopo deste curso.
A arquitetura 3 camadas ideal a aplicaes web. O processo aqui apresentado
distribui as atividades nas 3 camadas (apresentao, negcio e persistncia), fato
que permite explorar o desenvolvimento independente por equipes distintas.
Assim sendo, as atividades esto distribudas em duas dimenses: as etapas do
RUP e a camada onde se localizam.

2-Etapa de Concepo/Elaborao
Esta a primeira etapa do processo de desenvolvimento adotado e
corresponde essencialmente a atividades que visem:
-Analisar a viabilidade do projeto.
-Identificar a estrutura e a dinmica da organizao na qual o sistema
vai ser instalado.
-Identificar os problemas da organizao e propor melhorias.
-Levantar requisitos.
-Especificar os requisitos levantados.
Neste curso, detalhamos as atividades relacionadas a especificao de
requisitos. As outras fogem ao escopo deste curso.

2.1-UML- Modelo de Casos de Uso

2.1.1-Definies
O modelo de casos de uso constitui o principal artefato da UML, pois utilizado
em todas as fases do desenvolvimento da aplicao, servindo de base para
determinao de:
-Classes na fase de anlise
-Operaes, na fase de projeto
-Testes de verificao e validao de requisitos.
-Manual do usurio
Na essncia,um caso de uso uma interao entre um usurio e um sistema
computacional, de tal forma que sejam representadas todas as funes visveis
ao usurio, bem como seus objetivos. Um ator um papel que um usurio
representa com respeito ao sistema. Normalmente um caso de uso utilizado
por um ator. Um nico ator pode utilizar vrios casos de uso, da mesma forma,
um caso de uso pode interagir com vrios atores. No precisam
necessariamente ser humanos. Podem, por exemplo ser sistemas externos que
utilizam informaes do sistema sendo modelado.Os atores podem ter vrios
papis com relao ao caso de uso. Eles podem obter valores ou podem
apenas participar do mesmo. O diagrama de casos de uso representam as
interaes entre casos de uso e atores. Estas interaes so representadas por
setas ligando o caso de uso ao ator. A Figura 2.1 mostra a notao utilizada no
modelo de casos de uso.
Um caso de uso um processo relativamente grande. Isto significa que envolve
normalmente muitos passos, no sendo nunca constitudo por um nico passo
ou atividade individual. Seu detalhamento feito por meio de descries
textuais que podem ser sucessivamente refinadas durante o processo de
desenvolvimento, comeando por descries de alto nvel (casos de uso de alto
nvel) e chegando a descries minuciosas (casos de uso reais), melhor
descritas adiante.

autor

Submeter Documento

Figura 2.1- Notao da UML para ator (autor), interao (seta) e caso de uso
(Submeter Documento)
2.1.2-Relaes entre casos de uso
As relaes entre casos de uso podem ser do tipo usa ou estende.
A relao estende (extends) utilizada para indicar que determinado caso de
uso pode ser inserido em outro, estendendo sua descrio. Ambos sero
totalmente independentes, ou seja, funcionalidades adicionais de extenso
podem ser adicionadas sem qualquer alterao no caso de uso estendido, ou
seja, este completo. As situaes em que normalmente se usa a ligao
estende so as seguintes:
-Para modelar variaes com que um caso de uso pode ser executado.
Neste caso, na descrio do use case estendido deve-se colocar referncias aos
casos de uso extensores, no seguinte formato:

Caso <condio> iniciar < nome do caso de uso extensor>

-Para modelar situaes excepcionais que somente ocorram em certos
casos. Neste caso, a primeira linha da descrio do caso de uso que estende
tem o seguinte formato padro:

Caso de uso <nome> uma situao excepcional de<nome do caso de

uso estendido> na linha <nmero da linha> quando <evento do qual deriva a
situao excepcional>
-Para modelar a situao em que vrios casos de uso podem ser
inseridos em outro, como em um sistema de menus, por exemplo.
Na Figura 2.2 o caso de uso Pesquisar tem sua funcionalidade estendida por
variaes que correspondem s diversas formas possveis de pesquisa.

<<extend>>
Pesquisar por Ttulo
Pesquisar

<<extend>>
<<extend>>

<<extend>>

Pesquisar por Cdigo RT

Pesquisar por Autor
Pesquisar por Palavra-Chave

Figura 2.2-Utilizao da ligao estende (extend)

A relao usa (uses ou include) denota a relao de um caso de uso com outro
cujo comportamento complexo e comum a vrios casos de uso. Assim sendo,
ocorre a reutilizao de um caso de uso, por outros que necessitem de sua
funcionalidade. Se um caso de uso A usa um caso de uso B, no momento em
que B invocado, a execuo de A pra, inicia-se a execuo de B e, ao
trmino desta, a execuo retorna para A no ponto em que foi interrompida
para a execuo de B.
A Figura 2.3 mostra a utilizao da ligao usa (include). Os casos de uso de
cadastro tm uma funcionalidade que se repete em todos eles, representada
pelo caso de uso Cadastrar. Este caso de uso permite inserir, alterar, excluir e
pesquisar dados no banco de dados.

Cadastrar
<<include>>
<<include>>

Cadastrar Administradores

Cadastrar Rev isores

<<include>>

Cadastrar Autores

<<include>>

<<include>>

<<include>>

Cadastrar Cursos

Cadastrar Tpicos

Cadastrar Leitores

Figura 2.3 Utilizao da relao usa (include)

2.1.3-Herana entre atores
Atores que tm um papel em comum podem ser representados no diagrama de
casos de uso pela notao mostrada na Figura 2.3. Nela, os atores autor, leitor,
revisor e administrador tm papis em comum, que so denotados pelo ator
usurio. Na Figura 2.5, podemos ver que um dos papis em comum acessar
os casos de uso Pesquisar e Autenticar. Repare que conseguimos com esta
notao economizar um nmero substancial de linhas que seriam necessrias
para conectar cada um dos quatro atores aos dois casos de uso.

10

Usurio

leitor

autor

revisor

Administrador

Figura 2.4-Herana entre atores

Autenticar
Pesquisar

Usurio

autor

leitor

revisor

Administrador

Figura 2.5-O ator usurio acessa os casos de uso Pesquisar e Autenticar,

comuns aos 4 atores filhos.

2.2-Atividade Levantar Requisitos

2.2.1-Definio:Requisitos

11

Em essncia, um requisito uma necessidade do usurio. Levantar requisitos

uma atividade rdua, que envolve normalmente uma grande interao entre o
analista e o usurio, exigindo tcnicas especficas (que no esto no escopo
deste livro). Devem ser definidos de maneira clara e objetiva, sem
ambiguidades.
Projetos bem sucedidos advm de requisitos bem definidos. Requisitos de alta
qualidade tm as seguintes caractersticas:
-So corretos, ou seja, correspondem realmente ao que o usurio quer;
-So completos, ou seja, representam tudo o que o usurio necessita;
-So consistentes, ou seja, no existe conflito entre eles;
-So testveis, ou seja, so passveis de serem verificados quanto a quaisquer
destas caractersticas;
-So alterveis, ou seja, podem ser modificados sem que isto cause transtorno
ao desenvolvimento em si ou a outros requisitos.
-So precisos, ou seja, sua interpretao livre de ambigidades.
Segundo [SOM01], requisitos de sistemas de software so classificados como:
-Funcionais: correspondem s funes que o sistema deve possuir, reaes a
determinadas entradas e o comportamento em situaes especficas.
-No funcionais: so restries de tempo, memria, segurana, desempenho,
qualidade, dentre outros.
-Requisitos de domnio: so requisitos relativos ao domnio de aplicao do
sistema, refletindo suas caractersticas.
2.2.2-O levantamento de requisitos
Esta atividade extensa e seu detalhamento foge ao escopo deste curso. Em
essncia, a atividade de levantamento de requisitos se faz mediante a
utilizao de:
-Entrevistas com o usurio: consiste em um dilogo entre o entrevistador e o
entrevistado, dentro de um roteiro previamente elaborado. A entrevista deve
ser adaptada ao nvel profissional, cultural e social do entrevistado.
-Anlise documental: consiste na anlise de formulrios, relatrios, contratos e
documentos essenciais ao usurio;
-Questionrios: so questes sistematizadas e bem direcionadas, dispostas em
impressos padronizados, a serem aplicadas aos usurios do sistema. uma
alternativa entrevista principalmente em situaes em que os elementos do
universo desejado sejam muitos, ou ainda, estejam geograficamente dispersos,
quando h pouco tempo,ou quando as respostas exijam clculo ou um tempo
maior para serem respondidas.
-Observao direta: serve para complementar ou enriquecer as concluses
obtidas atravs dos meios anteriores, atravs da observao direta do meio que
est sob levantamento.
-Reunies JAD- so reunies realizadas para que os requisitos sejam obtidos
por um grupo de pessoas composto por usurios, analistas e especialistas do
domnio do problema.

12

2.3-Atividade obter os atores, casos de uso e relaes

Os passos a seguir direcionam na obteno sistemtica de casos de uso, atores
e interaes:
1-Definem-se os atores que iro interagir com o sistema. Atores podem ser:
-Papis a serem realizados pelo usurio
-Unidades organizacionais
-Grupos de usurios
-Dispositivos de hardware
-Sistemas externos com os quais interagir
No exemplo da Revista Digital os atores realizam papis dentro do domnio do
problema. Estes papis so os seguintes:
Autor: responsvel pela submisso de artigos a serem publicados pela revista.
Leitor: pesquisa artigos e faz download dos mesmos.
Revisor: responsvel por fazer as revises dos artigos submetidos pelos
autores.
Administrador: responsvel por cadastrar todos os dados do sistema, montar
cadernos e distribuir os artigos pelos revisores.
Usurio: corresponde aos papis comuns realizados pelos atores acima, como
autenticar, fazer pesquisa e fazer download de documentos.
2-A partir do levantamento de requisitos, capturam-se os principais eventos
externos do sistema, sob a viso do usurio. Um evento externo corresponde a
uma ao que do usurio ao utilizar o sistema.
No caso da Revista Digital, temos:
1-Usurio faz autenticao.
2-Usurio faz pesquisa por ttulo.
3-Usurio faz pesquisa por nome do autor.
4-Usurio faz pesquisa por cdigo RT.
5-Usurio faz pesquisa por palavra-chave.
6- Usurio faz download de documentos.
7-Autor submete documentos.
8-Autor registra autores do documento.
9-Autor exclui autores do documento.
10-Revisor faz revises de documentos.
11-Administrador aloca revisores a documentos.
12-Administrador monta cadernos.
13-Administrador cadastra administradores.
14--Administrador cadastra revisores.
15-Administrador cadastra autores.
16-Administrador cadastra cursos.
17-Administrador cadastra tpicos.
18-Administrador cadastra leitores.
13

3-Cada evento da lista de eventos d origem a um caso de uso e s relaes

entre o ator e o caso de uso.
Cada evento acima d origem a um caso de uso:
Casos de uso
Autenticar
Pesquisar por ttulo
Pesquisar por nome do autor
Pesquisar por cdigo RT
Pesquisar por palavra-chave
Fazer download de documentos
Submeter documentos
Registrar autores
Excluir autores
Fazer revises de documentos
Alocar revisores a documentos
Montar cadernos
Cadastrar administradores
Cadastrar revisores
Cadastrar autores
Cadastrar cursos
Cadastrar tpicos
Cadastrar leitores

Atores
Usurio
Usurio
Usurio
Usurio
Usurio
Usurio
Autor
Autor
Autor
Revisor
Administrador
Administrador
Administrador
Administrador
Administrador
Administrador
Administrador
Administrador

4-Desmembrar casos de uso com alto grau de complexidade, ou agregar casos

de uso que sejam simples e vinculveis a outros.
No exemplo, os casos de uso excluir autores e registrar autores so partes do
processo de submisso de um documento, por isso sero agregados ao caso de
uso submeter documentos. Na descrio deste ltimo far-se- referncia aos
agregados em subsees.
5-Criam-se, onde necessrio, generalizaes <EXTENDS> ou reutilizaes
<INCLUDE> de forma a tornar o diagrama mais robusto.
No exemplo, os casos de uso de pesquisa podem ser ligados ao caso de uso
denominado pesquisar que ser estendido por eles (ligao extend).
Podemos criar um caso de uso comum aos casos de uso de cadastro,
denominado Cadastrar, conectado a eles por ligaes usa(include). Ele vai
agregar funcionalidades comuns a todos eles, quais sejam, incluir, excluir, e
pesquisar dados.
Na Figura 2.6 temos o Diagrama de Casos de Uso resultante da realizao das
atividades supra descritas.

14

<<extend>>
<<include>>
Pesquisar por Ttulo

Autenticar

Pesquisar
<<extend>>

<<extend>>
Usurio

Obter Documentos a Revisar

<<extend>>
Pesquisar por Cdigo RT

Pesquisar por Autor

Pesquisar por Palavra-Chave
autor

leitor

revisor

Administrador

Registrar revises de Documentos

Montar Cadernos
Fazer Download Documentos

Submeter Documento

Cadastrar
<<include>>
<<include>>

<<include>> <<include>>
<<include>>

Cadastrar Administradores Cadastrar Revisores Cadastrar Autores Cadastrar Cursos Cadastrar Tpicos Cadastrar Leitores

Figura 2.6-Diagrama de casos de uso da Revista Digital

2.4-Atividade Definir Casos de Uso de alto nvel

Os chamados casos de uso de alto nvel [LAR00], contm um texto narrativo
sucinto que descreve o processo ao qual se referem. Constituem uma primeira
abordagem acerca da funcionalidade do caso de uso, que servir como base
para refinamentos efetuados em etapas posteriores (casos de uso expandidos e
reais).
Seja por exemplo o caso de uso Submeter Documento. Sua descrio de alto
nvel a seguinte:

O autor seleciona o documento a ser submetido a reviso. Em seguida

comanda o registro de dados bsicos, de autores e finalmente envia este
documento para o setor de revises da revista digital.
Repare que se pretende com esta descrio uma viso geral do processo, sem
detalhes de como a seleo e o envio sero efetivados.

2.5-Atividade Definir Casos de Uso Expandidos

15

Um caso de uso expandido [LAR00] constitui uma verso mais detalhada do

caso de uso de alto nvel, permitindo uma compreenso mais profunda dos
processos e dos requisitos. A descrio feita na forma de fluxo de eventos.
Um fluxo de eventos uma seqncia de aes que realizam a funcionalidade
representada pelo caso de uso. Na abordagem aqui descrita, distinguimos dois
tipos de fluxo de eventos: as aes realizadas pelo ator e a resposta do sistema
a estas aes. Estes fluxos so numerados seqencialmente e dispostos em
duas colunas paralelas. Abaixo temos o modelo de descrio do caso de uso
expandido:
Na parte superior da descrio temos um resumo do caso de uso:

Caso de uso : nome do caso de uso.

Atores: lista de atores que interagem com este caso de uso.
Finalidade: objetivo do caso de uso.
Viso geral: descrio sucinta, a mesma utilizada no de alto nvel.
Pr-condies: lista de condies que tenham sido satisfeitas para que o caso
de uso seja executado.
Ps-condies: lista de condies obtidas aps a realizao do caso de uso.
Na parte mdia temos a seqncia de eventos, que vai descrever as aes do
ator e a resposta do sistema s mesmas. Normalmente esta seqncia de
eventos tpica, no descrevendo situaes alternativas. O formato desta seo
o seguinte:
Seqncia tpica de eventos
Ao do ator
Descrio das aes numeradas
dos atores.

Respostas do Sistema
Respostas numeradas do sistema

Se houver pontos de deciso dentro da seqncia tpica de eventos duas

situaes devem ser consideradas:
-Se um dos ramos de deciso for um caso bastante tpico e os outros forem
situaes raras ento o ramo tpico permanece na seqncia tpica e as
alternativas so descritas numa seo denominada Alternativas:
Seqncias alternativas
Enumerar as aes alternativas.
-Se os pontos de deciso representam situaes equiprovveis, criam-se
subsees, que vo possuir, cada uma, sua seqncia tpica de eventos. Na
seo principal criam-se desvios para as subsees, utilizando-se a estrutura
condicional Se <condio> ver seo <nome da subseo>.Esta subsees
podem, inclusive ter tambm seqncias alternativas. Se estas subsees forem
16

comuns a vrios casos de uso, podem se tornar casos de uso independentes,

conectados ao principal por meio das relaes usa. Na descrio do caso de
uso, ao invs da expresso ver seo <nome da subseo>, colocamos iniciar

<nome do caso de uso>.

A seguir temos um exemplo de uma descrio expandida para o caso de uso
Submeter Documento.

Caso de uso : Submeter Documentos

Atores: autor
Finalidade: Enviar documento para equipe de reviso.
Viso geral: O autor seleciona o documento a ser submetido a reviso. Em
seguida comanda o registro de dados bsicos, de autores e finalmente envia
este documento para o setor de revises da revista digital.
Pr-condies: Autor cadastrado no sistema. Autor preencheu dados do
documento a ser submetido. Documento disponvel para envio.
Ps-condies: Documento enviado e armazenado para que possa ser revisado.

Seqncia tpica de Eventos

Aes do ator
1-Iniciar caso de uso Pesquisar por

Resposta do Sistema

Ttulo
2-Se no
documento

houver cadastrado o
ver seo
Cadastrar

Dados Documento
3-Se
no houver registrado os
autores do documento, ver seo

Registrar Autores do Documento

4-O autor, ento comanda o envio do 5-Grava o documento submetido no
documento.
servidor, para ser posteriormente
revisado.
Seqncias alternativas
Linha 5: Problemas no envio (upload) do documento. Indicar erro de
comunicao.
Subseo Cadastrar Dados Documento
Seqncia tpica de Eventos
Aes do ator
1-Depois que o sistema retornou a
lista de documentos do autor, este, se

Resposta do Sistema

17

j no houver feito, pode:

a-Selecionar um documento para
alterar dados. Aps seleo feita,
iniciar Cadastrar, enviando para
alterao os dados Cdigo RT, Ttulo,

Resumo, Data de Submisso, Tpico e

Palavras-chaves.
b-Selecionar opo para inserir dados
de um novo documento. Iniciar
Cadastrar para inserir os dados Cdigo

RT, Ttulo, Resumo, Data de

Submisso, Tpico e Palavras-chaves.

Observao: repare que nesta subseo estamos invocando o caso de uso

Cadastrar, que se relaciona com o caso de uso Submeter Documentos por meio
de uma relao usa (include-ver diagrama completo e descrio do caso de uso
Cadastrar no prximo item).
Subseo Registrar Autores do Documento
Aes do ator
1-O autor deve inicialmente pesquisar
o nome do(s) autor(es) do documento.
Para tal pode:
1.a.1-Deixar o campo de nome em
branco e solicitar a pesquisa
1.b.1-Digitar o nome do autor ou uma
parte do mesmo e solicitar a pesquisa.

2-Para cada autor do documento:

2.a.1 Seleciona seu nome da lista e
solicita sua incluso.
2.b.1-Se desejar excluir um autor,
seleciona e solicita sua excluso.

Resposta do Sistema

1.a.2 Retornar a lista de todos os

autores cadastrados no sistema
1.b.2- Retornar o(s) nome(s) dos
autores encontrados no banco que
mais se assemelhem ao solicitado.

2.a.2-Inserir autor na lista de autores

do documento.
2.b.2-Excluir o autor da lista de
autores.

Observao: Na linha 2, repare que utilizamos uma estrutura de repetio,

indicando que aes subseqentes podem ser feitas tantas vezes quantos
forem os autores a serem registrados. Repare tambm na sugesto para
estruturas de deciso nas linhas 1.a.1 e 2.a.1
Seqncia alternativa
Linha 2.1- Autor selecionado j est na lista de autores. Sistema emite
mensagem informando que autor j foi includo.

18

19

3 -Etapa de Concepo-Anlise
Na etapa anterior obtivemos como artefatos principais o diagrama de casos de
uso estendidos e as descries dos casos de uso. Nesta etapa iniciamos o
desenvolvimento incremental, em que cada caso de uso refinado de forma a
produzirem-se descries reais.
3.1-UML Diagramas de Classes e Objetos
3.1.1-Definio
Um objeto um conceito pertinente a um domnio especfico, abstrado na
forma de procedimentos, operaes que so capazes de executar, e atributos
que o caracterizam. As operaes so invocadas atravs de mensagens
trocadas entre objetos, ou seja um objeto colabora com outro executando uma
operao que de sua responsabilidade, que lhe foi solicitada.
Uma classe uma representao de um conjunto de objetos que agregam
caractersticas semelhantes. O diagrama de classes o artefato da UML que
mostra as diversas classes que compem o sistema e, principalmente, as
relaes entre estas. Fornece, portanto, uma viso esttica do sistema sob
modelamento. Os diagramas de classes so produzidos em diversos nveis, num
processo incremental. Os tipos de diagramas seguintes traduzem nveis de
abstrao distintos, que se superpem:
-Diagrama de Classes de Domnio de Problema: traduz abstraes
especficas de classes que so nativamente pertinentes ao domnio no qual o
sistema se insere.
-Diagrama de Classes de Anlise: contm o diagrama anterior e
abstraes e consideraes especficas propostas pelo processo de anlise.
-Diagrama de Classes de Projeto: o diagrama de anlise modificado e
acrescido de abstraes e consideraes especficas propostas pelo processo de
projeto.
O diagrama de objetos, por sua vez, modela instncias de classes contidas em
um diagrama de classes. Portanto, eles denotam o estado de um determinado
diagrama de classes em um ponto determinado no tempo.
Nos itens seguintes apresentaremos a notao que a UML prope para
diagramas de classes e de objetos em seus diversos nveis. Mais adiante,
descreveremos o processo de criao de cada um dos nveis de abstrao
acima citados.

3.1.2-Notao

20

3.1.2.1-Classes e Objetos
Classes e objetos so representados por retngulos contendo um nome
identificador. As particularidades de notao so as seguintes:
-Quando deseja-se representar um objeto sem referncia classe qual
pertence, colocamos seu nome sublinhado dentro do retngulo:
AutorDoc

Figura 3.1: Notao para objeto sem referncia a sua classe

-Quando deseja-se representar um objeto e a classe qual pertence, utiliza-se
a notao <nome objeto>:<classe>:
AutorDoc: Autor

Figura 3.2: Notao para objeto com referncia classe qual pertence
-Quando deseja-se representar o objeto, no sendo relevante o nome de sua
instncia, representa-se apenas o nome da classe qual pertence, precedido
por um sinal de dois pontos:
:Autor

Figura 3.3: Notao para objeto com omisso do nome de sua instncia.

-Uma classe representada por um retngulo dividido em at trs sees. Na

seo superior colocado o nome da classe. Nas sees seguintes alocam-se,
respectivamente de cima para baixo:

-Atributos: constituem a caracterizao dos objetos-instncias das

classes. A sintaxe para representar atributos a seguinte:

visibilidade nome : tipo = valor default

onde

visibilidade: veja o conceito abaixo em operaes

nome: identificador do atributo
tipo : tipo do identificador

21

Visibilidade e tipo so opcionais.

Autor
Codigo
Nome
Login
CodCurso
Email
Senha

Figura 3.4- Atributos de classe

A sintaxe para representar atributos a seguinte:

visibilidade nome : tipo = valor default

onde

visibilidade: +(pblica),#(protegida) ou -(privada)

nome: identificador do atributo
tipo : tipo de dado do identificador
-Operaes: Denotam as aes passveis de serem realizadas por
qualquer objeto pertencente classe. So representadas segundo a seguinte
sintaxe:

visibilidade nome(lista de parmetros): tipo de retorno {valores aplicveis}

onde

visibilidade : +(pblica),#(protegida) ou -(privada)

nome: string com o nome da operao
lista de parmetros : lista de argumentos com a mesma sintaxe dos atributos.
tipo de retorno: tipo de dado de retorno, quando for o caso.
valores aplicveis: lista de valores aplicveis operao.
Autor
Incluir()
Excluir()
Alterar()

Figura 3.5- Operaes de classe

As sees de atributos e operaes no necessitam obrigatoriamente ser
mostradas no diagrama de classes.

22

3.1.2.2-Associaes
Associaes so, na essncia, relacionamentos estruturais entre classes de
tipos diferentes. Os diversos tipos suportados pela UML esto relacionados nos
subitens a seguir.
3.1.2.2.1-Associaes de ocorrncia
Corresponde a associaes entre classes que descrevem o nmero de
ocorrncias (cardinalidade) de uma em relao a outra. A Figura 3.6 a seguir
mostra algumas cardinalidades comuns a associaes de ocorrncia.
Autor
1..n

Um ou mais
Curso

0..1

Zero ou 1

Topico
1

Exatamente 1

Figura 3.6-Algumas associaes entre classes

Observao A cardinalidade 0..n muitas vezes substituda por um * na
notao da UML.

3.1.2.2.2-Associaes todo-parte
Correspondem a relaes entre uma classe (todo) e suas partes constituintes.
Identificamos dois tipos de associaes todo-parte:

Agregao: as partes podem existir sem o todo (Figura 3.7).

23

Caderno
1

1..n
Documento

Figura 3.7- Exemplo de agregao. Documento existe independentemente da

existncia de caderno.
Composio: as partes dependem do todo para existir. O fim do todo significa o
fim das partes (Figura 3.8).

Figura 3.8- Exemplo de composio: a parte Itens depende do todo Lista para
existir: a eliminao de Lista provoca a eliminao de Itens.

3.1.2.2.3-Associaes mltiplas
So associaes que ocorrem entre trs ou mais classes. Cada instncia deste
tipo de associao uma n-tupla de valores das respectivas classes. Na Figura
3.9, temos sua representao.

Aluno
1..n
1..n
Turma

1..n
Disciplina

24

Figura 3.9-Associao ternria

3.1.2.2.4-Navegabilidade
A navegabilidade entre duas classes define a visibilidade que as respectivas
instncias vo ter entre si. representada por uma seta na associao entre as
classes. A classe na origem tem visibilidade sobre a classe do destino, sem
reciprocidade. Na Figura 3.10, a classe Autor tem visibilidade sobre as
instncias de Curso, ou seja, tem referncias a instncias de curso. Por sua vez,
Curso no tem nenhuma visibilidade sobre instncias de autor.

Autor

Curso
1..n

0..1

Figura 3.10- Navegabilidade entre duas classes

3.1.2.2.5-Generalizaes-especializaes
So associaes entre classes que guardam entre si relaes de herana, ou
seja, uma classe pode herdar de outra, atributos e operaes que lhe sejam
visveis (que sejam de nvel de encapsulamento protegido ou pblico). Na
Figura 3.11 temos um exemplo em que 3 classes (Autor, Leitor, Revisor)
herdam caractersticas da classe usurio. Discriminador corresponde a um
nome que se d para a relao de herana dentro do contexto do domnio de
problema. Por exemplo, no contexto da Revista Digital, poderia ser papel.
Restries podem ser alocadas generalizao, colocadas entre chaves, sobre
uma linha pontilhada (ver Figura 3.11). Podem ser dos seguintes tipos:
{Sobreposio} : subclasses podem ocorrer simultaneamente.
{Disjuno}: subclasses so mutuamente exclusivas.
{Completo}: todas as subclasses esto representadas.
{Incompleto}: algumas subclasses foram representadas.

Usuario
Discriminador
--------------------------------------------- {Restrio}

Autor

Leitor

Revisor

25

Figura 3.11- Estrutura Generalizao-Especializao

A herana mltipla pode ser representada conforme mostrado na Figura 3.12. A
classe TextBox herda caractersticas de um editor de textos e de uma janela.
Texto

Janela

TextBox

Figura 3.12-Estrutura Generalizao-Especializao para herana mltipla

3.1.2.3-Mecanismos de extenso
Apesar de bastante completa, a UML no capaz de representar todas as
nuances de um ambiente ou modelo em todos os domnios possveis. Por esse
motivo a UML possui os chamados mecanismos de extenso, descritos a seguir.
3.1.2.3.1-Regras de restrio
A UML prov regras de restrio a serem aplicadas a classes e seus
constituintes (atributos e procedimentos).As associaes, atributos e
generalizaes em si j especificam restries, mas nem todas podem ser
expressas por meio de tais estruturas. A UML no define uma sintaxe rgida
para especificar restries, apenas determina que devem ser colocadas entre
chaves({}).
Estas restries podem ser definidas utilizando-se linguagens informal ou
formal, predicados ou fragmentos de cdigo-fonte. Na Figura 3.13 abaixo
temos um exemplo de uso das mesmas. O valor do atributo ComRes sendo 3,
determina a colocao da data de hoje (DATAHOJE) no campo DocDatApr. (No
contexto do sistema Revista Digital corresponde a alocar a data de hoje data
de aprovao do documento, caso ele tenha sido aprovado na ltima reviso).

ComentariosCorrecoes
ComRes

0..n

Documento
DocDatApr

{if ComRes="3" then DocDatApr= DATAHOJE}

Figura 3.13-Regra de Restrio aplicada aos atributos ComRes e DocDatApr. Se

o valor de ComRes for 3 faz DocCatApr ser igual a DATAHOJE
26

3.1.2.3.2-Esteretipos
O esteretipo uma extenso ao vocabulrio da UML cujo objetivo a criao
de novos blocos de construo a partir dos existentes [BOO99]. A forma mais
comum a utilizada para designar determinada classificao de alto nvel para
objetos ou classes que possuam naturezas ou objetivos afins. Por exemplo,na
abordagem original de Jacobson, objetos so classificados em trs tipos:
objetos de interface, objetos de controle e objetos-entidades. So sugeridas
regras para comunicao entre estes objetos e cada um representado por um
cone diferente. Na UML isto no existe e estes tipos de objetos tornaram-se
esteretipos.
Esteretipos so usualmente mostrados entre os sinais << e >>, como por
exemplo, em <<controle>> (ver Figura 3.14).
<<controle>>
ControleSubmissaoDoc

Figura 3.14-Representao de esteretipo de classe de controle.

Um outro exemplo notvel de esteretipo o <<metaclasse>>, que denota a
classe da qual suas instncias tambm so classes.

3.1.2.4-Classificao Mltipla

\
A classificao mltipla refere-se situao em que uma classe me possui
classes derivadas em contextos diferentes. Utiliza-se o discriminador para
designar o contexto em que uma herana especfica est includa. Na Figura
3.16, no contexto do cargo em que ocupa na empresa, Funcionrio pode ser
classificado como Analista, Programador e Gerente. J no contexto do
departamento de recursos humanos, definem-se subclasses para discriminar a
forma na qual a contratao do funcionrio foi efetuada, ou seja, como
Celetista ou Consultor.

27

Celetista

Consultor

Contratao

Funcionario

Cargo

Analista

Programador

Gerente

Figura 3.16- Exemplo de classificao mltipla

3.1.2.5-Classificao Dinmica
Ocorre quando h a possibilidade de um objeto modificar seu tipo na estrutura
de subclasse. Na Figura 3.17 a seguir, o funcionrio pode modificar seu cargo
na empresa, evoluindo de programador para analista e deste para gerente. O
denotador de esteretipo <<dinmica>> designa este tipo de classificao.
Funcionario

Cargo
<<dinmica>>

Analista

Programador

Gerente

Figura 3.17- Exemplo de classificao dinmica

3.1.2.6-Notao para classes abstratas
J vimos que classes abstratas no possuem instncias. Elas so denotadas
colocando-se a palavra abstrata entre chaves ({abstrata}) logo abaixo do nome
da classe. Na Figura 3.18, a classe BasePersistencia abstrata, ou seja, no
existem instncias de objetos dela derivados.

BasePersistencia
{Abstrata}

AutorBean

CursoBean

28

Figura 3.18- Exemplo de classe abstrata

3.1.2.7-Notao para interfaces
No contexto de linguagens de programao, uma interface uma classe sem
implementao, no possuindo atributos e contendo apenas a declarao das
operaes. Uma ou mais classes implementam as operaes especificadas na
interface. A notao para designar uma interface coloca o esteretipo
<<interface>> sobre o nome da mesma. Na Figura 3.19, a interface Janela
implementada pelas classes Caixa e Dilogo. Repare na associao pontilhada:
corresponde representao para implementao da interface. Na Figura 3.20
apresentamos outra notao para interface: a classe ConnectionHolder
implementa a interface HttpSessionBindingListener.

<<Interface>>

Janela

Caixa

Dilogo

Figura 3.19 - Notao para interface e implementao da interface

ConnectionHolder
HttpSessionBi
ndingListener

Figura 3.20 Outra notao para Interface

3.1.2.8-Classes Associativas
As classes associativas so derivadas de uma associao.Neste caso, esta
possuir atributos e operaes. Classes associativas ocorrem na situao em
que a associao entre as classes existe no domnio do problema. Na Figura
3.21, existe um relacionamento 0 ou 1 para muitos entre Empresa e Pessoa. No
domnio do problema, esta relao o Emprego da pessoa (classe associativa),
caracterizado pelos atributos Cargo e Salrio.

29

Empresa

Pessoa
0..1

1..n

Emprego
Cargo
Salario

Figura 3.21-Classe associativa

3.1.2.9-Classes Parametrizadas
Uma classe parametrizada um gabarito para criao de classes que seguem
seu formato. Ela declara parmetros padres que permitiro a sua adaptao a
contextos especficos. Na Figura 3.22 temos sua notao.
Par.
NomeClasse

Figura 3.22-Classe Parametrizada.

3.1.2.10-Atributos Derivados

Atributos Derivados so aqueles que podem ser calculados a partir de outros

atributos. Por exemplo, um atributo idade pode ser derivado a partir do atributo
data de nascimento. Tais atributos so denotados por uma barra (/) colocada
antes de seu nome.A forma de derivao pode ser explicitada a partir de uma
regra de restrio alocada ao p da classe.
3.1.2.11- Instanciao
Esta notao representa a possibilidade de uma classe instanciar outra. A seta
tracejada parte da classe que cria a instncia.
ControlePesquisa

Leitor

Figura 3.23-Classe ControlePesquisa instancia classe Leitor

3.1.2.12-Alocando notas ao diagrama
possvel alocarem-se notas e observaes no diagrama de classes. Na Figura
3.24 temos uma nota que se refere a um pseudocdigo alocado a uma
operao.

30

Para cada documento

doc[i]=documento.get

Caderno

Figura 3.24-Nota de pseudocdigo alocada a uma classe

3.2-UML Diagramas de Pacotes
Pacotes so artefatos da UML que permitem dividir um determinado modelo de
classes em subsistemas. Cada um destes subsistemas contm classes que
guardam afinidades funcionais entre si e este o critrio utilizado para
particionamento. Os diagramas de pacotes denotam as relaes de
dependncia entre os diversos pacotes do sistema: setas tracejadas conectam
pacotes entre si, de forma que o pacote na origem acessa classes do pacote do
destino.
Pacotes so uma ferramenta vital a projetos grandes. Devem ser utilizados
quando um diagrama de classes que englobe todo o sistema no for visvel em
uma folha A3. Podem ser mostrados em diagramas de classes, quando desejase evidenciar que classes acessam pacotes contidos na aplicao.
Na Figura 3.23, os pacotes Controle, Interface e Banco de Dados contm
classes que implementam as camadas respectivas da arquitetura 3 camadas. O
pacote Controle visualiza as classes do pacote Interface e o Pacote Banco de
Dados visualizado pelos outros dois pacotes.

Controle

Interface

Banco de
Dados

Figura 3.23 Exemplo de Diagrama de Pacotes

3.3-UML-Diagramas de Transio de Estados(DTE)
Os Diagramas de Transio de Estados descrevem os estados possveis que um
objeto em particular pode assumir e como estes estados so modificados em
funo de eventos que afetam o objeto. Diagramas de Estados so desenhados
para uma nica classe para mostrar o comportamento de um nico objeto.
31

A Figura 3.24 exemplifica um DTE para o objeto Documento da Revista Digital.

Nele vemos as notaes para estado, eventos, aes e condies. O nome do
estado colocado no topo do retngulo de bordas arredondadas. Sob este
nome pode-se colocar, separada dele por uma linha horizontal, uma ao que
esteja sendo realizada enquanto o objeto estiver naquele estado. No exemplo,
o objeto est no estado Submetido esperando definio de revisores e,
enquanto nele, a ao Determinar revisores est sendo executada.Repare que
a ao precedida por do/. Temos uma transio deste ltimo estado para
Aguardando Reviso, que ocorre quando a condio Revisores definidos
(colocada entre colchetes) verificada. Esta condio dispara a ao Enviar
para reviso , colocada sob a barra (/). Por conveno, este tipo de ao
ocorre instantaneamente. Entre estados podem ocorrer eventos que provocam
transio, como o evento Revisor Iniciar Reviso mostrado na transio entre
Aguardando Reviso e Em reviso. No evento Em Reviso temos um
exemplo de estrutura de deciso: a execuo da ao Efetuar Reviso pode
causar a transio para o estado Reviso Concluda Reprovado, caso a
condio Documento Reprovado ocorra, ou para
Reviso Concluda
Aprovado, caso a condio Documento aprovado seja satisfeita. Repare
tambm nos cones utilizados para determinar o incio e o fim do diagrama.
DTEs podem ser multinivelados, ou seja, um estado pode dar origem a um
subdiagrama contendo subestados pelos quais um objeto passa (denominam-se
tais estados aninhados).

32

Incio do
Diagrama

Transio:condio/ao

Autor Submeteu Documento

Submetido esperando
definio de revisores

Aguardando
Reviso

[ Revisores Definidos ] / Enviar Para Reviso

do/ Determinar revisores

Revisor Iniciar Reviso
Estado

Em reviso

Evento

[ Documento reprovado ]
Reviso Concluda
Reprovado

do/ Efetuar Reviso

Revisor Iniciar Nova Reviso
[ Documento aprovado ]
Reviso Concluda
Aprovado
do/ Alocar a caderno

Alocado

Alocado ao
Caderno

Fim do
Diagrama

Figura 3.24-DTE que mostra o ciclo do objeto Documento

3.3 Conceito: Esteretipos de Jacobson

33

A arquitetura de classes utilizada neste trabalho embasa-se em esteretipos de

classes propostos por Ivar Jacobson [JAC94] que permite uma organizao
criteriosa das classes, de forma que a atividade de desenvolvimento possa ser
particionada e distribuda entre equipes distintas. Os esteretipos so os
seguintes:
-Classes entidade so classes persistentes, normalmente pertencentes ao
domnio da aplicao (ou seja, ao contexto da aplicao) e, na maioria das
situaes, mapeadas a tabelas do banco de dados.
-Classes de interface- implementam a interao entre o sistema(casos de uso) e
os atores do mesmo.
-Classes de controle contm mtodos que implementam o fluxo de eventos
de um caso de uso, ou seja, possuem encapsuladas todas as regras de negcio
da aplicao e, ainda, podem despachar requisies do usurio para aes a
serem realizadas pelo sistema.
Parece bastante bvio que estes esteretipos esto relacionados,
respectivamente, s camadas de persistncia, de apresentao e de negcio do
modelo 3 camadas descrito no primeiro captulo.
A notao da UML aceita a colocao de cones para representao de
esteretipos. Os propostos por Jacobson so apresentados na Figura 3.25.

Objeto Entidade

Objeto de Interface Objeto de Controle

Figura 3.25 cones utilizados para esteretipos de Jacobson

3.4-Atividade definir classes de domnio do problema
Esta atividade, conforme visto na Figura 2.1, pode ser realizada logo aps a
definio dos casos de uso expandidos. As classes de domnio de problema so
conceitos pertencentes ao mundo real, que participam ativamente na
consecuo de tarefas neste domnio.
3.3.1-Obtendo classes de domnio do problema por categorias
Classes de domnio de problema podem ser obtidas atravs de um brainstorm
inicial, em que um grande nmero de candidatas so capturadas dentro das
categorias mostradas a seguir. A ordem apresentada sugere inicialmente as
categorias onde esto normalmente o maior nmero de classes provveis de se
tornarem classes de domnio de problema:

Papis realizados dentro do contexto da aplicao: autor, revisor, administrador

Coisas fsicas ou tangveis: documentos, caderno
Coisas intangveis: reviso
Lugares: loja, secretaria
34

Organizaes: Departamento de vendas

Relatrios: administrativos, gerenciais, etc.
As classes obtidas so avaliadas para:
-Verificar se so realmente relevantes no domnio do problema.
-Verificar se no so atributos de outros conceitos. [LAR00] sugere que se um
conceito no mundo real no for pensado como um texto ou um nmero, ento
muito provavelmente uma classe.
Como exemplo, seja a descrio do caso de uso Fazer Revises de
Documentos:
Aes do ator
Resposta do Sistema
1-O revisor seleciona de uma lista 2-Abre tela para registro de reviso do
(que contm somente os documentos documento.
alocados ao mesmo) o documento a
revisar.
3-O revisor pode:
Fazer
Download
3.1-Solicitar download do documento. 3.2-Iniciar

Documentos.
3.3-Preencher tabela, atribuindo nota
a quesitos de avaliao.
3.4-Registrar resultado da avaliao:

aceito, no aceito, aceito com nova

reviso, no aceito com nova reviso.
3.5-Preencher
campo
contendo
comentrios e correes.
3.6-Preencher data da reviso.
4-Finalizada a reviso, o usurio pode:
3.a.2-Se reviso tiver status de aceita,
3.a.1-Submeter a reviso ao sistema.
registra no documento sua data de
aprovao.
3.a.3-Grava reviso.
3.b.1-Criar uma nova reviso do 3.b.2-Se reviso tiver status de aceita,
documento.
registra no documento sua data de
aprovao.
3.b.3-Grava reviso.
3.b.4-Abre tela para registro da nova
reviso e inicia novamente este caso
de uso.

Identificamos as seguintes categorias de substantivos e as respectivas classes

candidatas:

Papis: revisor
35

Coisas fsicas: documento,tela

Coisas intangveis: download, reviso, quesitos de avaliao, resultado da
avaliao, campo comentrios e correes, data da reviso, sistema.
Revisor um ator, mas certamente ser uma classe do sistema, pois dever
estar cadastrado no sistema e estar ligado a revises de documento.
Documento ser uma classe do sistema pois um dos principais conceitos do
mesmo, a razo de ser da revista.
Tela no ser uma classe do sistema porque uma apenas um dispositivo de
interface de interao, como tambm o um mouse, um teclado, etc.
Download: nesta primeira abordagem uma classe do sistema, pois representa
um conceito importante do domnio do problema.
Reviso um conceito importante do sistema. classe do mesmo.

Quesitos de avaliao, resultado da avaliao, campo comentrios e correes

e data da reviso no tm muita razo para que sejam considerados classes:
so melhor alocados como atributos de outra classe, muito provavelmente da
classe reviso.
Sistema obviamente deve ser descartado, pois no pode ser uma classe de si
mesmo.
Portanto, da anlise deste caso de uso obtivemos as classes Revisor,
Documento, Download e Reviso.

3.3.2-Obtendo classes de domnio de problema por substantivos

Substantivos presentes nas descries de casos de uso podem ser capturados e
utilizados como abordagem inicial para obteno de classes de domnio de
problema. Dois cuidados devem ser tomados em se utilizando esta abordagem:
-Palavras em linguagem natural podem ser ambguas;
-Substantivos podem ser tambm atributos de classes.

3.3.3-Definindo as classes de domnio que sero persistentes(classes

entidade)
As classes de domnio de problema cujo estado dos objetos deva ser
preservado so classificadas como persistentes (entidade).A maior parte das
classes de domnio de problema certamente ser persistente. Estas classes
encapsulam apenas mtodos para armazenamento e recuperao de
informaes.

36

No nosso exemplo temos que, a partir da descrio estendida dos casos de uso,
identificamos as classes de domnio de problema mostradas na abaixo
.Utilizamos o processo descrito no item 3.3.1.
Topico

Leitor

Caderno

Curso

Autor

Revisor

Documento

Administrador

Download

Revisao

3.5 Atividade Produzir diagrama de classes de domnio do problema

O diagrama de classes de domnio de problema um excelente artefato para a
representao de conceitos com os quais o sistema vai trabalhar,
representando seus atributos e o relacionamento entre eles. Nos subitens a
seguir detalhamos os passos necessrios consecuo desta atividade.

3.5.1-Adicionar associaes
Criam-se associaes para determinar dependncias entre classes, ou seja, a
necessidade que determinada classe tem de conhecimento acerca de instncias
de outras classes do modelo. Por exemplo, a classe Reviso necessita de
conhecimento acerca de instncia da classe Documento, pois uma Reviso
somente tem sentido quando vinculada a um Documento. Um Documento, por
sua vez, pode estar relacionado a mais de uma instncia de Reviso. Portanto,
vislumbra-se desta forma uma associao de dependncia entre Reviso e
Documento. Em nvel de projeto conceitual, adicionamos as seguintes
categorias de associaes(inspirado em [LAR00]):
Categoria
Conhecimento necessrio

Todo e parte

Uso

Dependncia

Comunicao

Descrio
Uma classe necessita conhecer a
ocorrncia de outra.Ex: Autor e
Documento
Uma classe uma parte lgica ou
fsica de outra, est contida em outra
ou ainda, possuda por outra. Ex:
Caderno e Documento
Uma classe utiliza algo de outra.
Ex: Item de Pedido e Produto (Item de
Pedido usa o preo de Produto)
Uma classe depende de outra para
que seu conceito faa sentido.Ex:
Reviso e Documento
Uma classe se comunica com a outra.

37

Ex: Cliente e Caixa

Um objeto se relaciona com uma
determinada transao. Ex: Cliente
(objeto) com Pagamento (transao)
Uma transao se relaciona com outra.
Ex:Pagamento com Venda
Uma classe define a associao entre
duas ou mais outras. Ex: Reviso
uma classe associativa entre Revisor e
Documento

Objeto-Transao

Inter-transaes
Classe associativa

Aps definirem-se as associaes, deve-se explicitar nos extremos o nmero

de instncias da outra classe com as quais a classe em considerao se
relaciona (multiplicidade ou cardinalidade). Pode-se tambm nomear uma
associao, adotando-se como formato padro uma frase verbal ou um verbo.
Na Figura 3.26 temos a associao entre Revisor e Documento. Repare na
cardinalidade entre as classes: Revisor revisa vrios Documentos e vice-versa. A
associao foi nomeada de forma a incrementar o nvel de compreenso do
contexto da mesma.
Revisa
Revisor

Documento
1..n

1..n

Figura 3.26- Uma associao nomeada e com cardinalidade definida

No exemplo Revista Digital, identificamos as seguintes associaes entre as

classes:

Categoria
Conhecimento necessrio

Todo e parte
Classe Associativa

Associaes
Autor e Documento, Documento e
Download, Autor e Curso, Curso e
Tpico, Curso e Revisor,Tpico e
Documento
Caderno e Documento
Reviso associa Revisor e Documento

A figura abaixo mostra o diagrama de classes de domnio de problema obtido

aps a adio das associaes acima definidas:

38

Leitor

Caderno

Administrador

0..n

1..n
1..n

Autor

Documento
1..n

1..n
1..n

Topico

0..n

Download

1..n

Revisao

1..n
1
Curso

1..n
Revisor

1
1

0..n

3.5.2-Adicionar atributos
Atributos so caractersticas cujos valores determinam o estado atual de um
objeto, ou seja, identificam uma instncia de uma classe. Em um grande
nmero de situaes, classes possuem um nmero considervel de atributos, e
a tarefa do analista consiste em determinar aqueles que sejam relevantes no
domnio do problema.
Atributos devem ser preferencialmente tipos de dados simples e o que ocorre
na maioria esmagadora das vezes. Quando forem compostos, ou seja, se
dividem em dois ou mais atributos, melhor consider-los como classes
parte.
Atributos no devem ser usados como chave de associao entre classes, ou
seja, como chave estrangeira, tal como acontece em um modelo de dados
relacional, em um diagrama de classes. No prximo item, quando descrevermos
o processo de mapeamento para um modelo de dados, veremos o
aparecimento de tais chaves estrangeiras.
Toda classe deve possuir um atributo que designe a identidade de suas
instncias. Normalmente, tais atributos so cdigos ou nomes. As boas prticas
de modelagem determinam que uma classe deve possuir um nico atributo
identificador, de forma a se diminuir a probabilidade de ocorrncia de
inconsistncias e ambigidades.
Na figura abaixo temos a verso do diagrama de classes do exemplo,acrescido
dos atributos. Repare que no existem chaves estrangeiras no diagrama de
classes. Elas aparecem aps o mapeamento do mesmo para banco de dados.

39

Leitor
LEICOD
LEINOM
LEINOMUSU
LEISEN
LEIEMA

Caderno
CADCOD
CADANOMES
CADTIT
0..n

1..n
Documento
Autor
DOCCODRT
AUTCOD
DOCTIT
1..n AUTNOM
DOCNOMARQ
AUTNOMUSU 1..n 1..n DOCTAMARQ
AUTSEN
DOCDATSUB
AUTEMA
DOCDATAPR
1..n DOCPALCH
1..n
Topico
TOPCOD
TOPNOM
1
1
Curso
CURCOD
1
CURNOM

1..n

Administrador
ADMCOD
ADMNOM
ADMNOMUSU
ADMSEN
ADMEMA

Download
0..n DOWNCOD

1
1..n
Revisor
REVCOD
REVNOM
0..n REVNOMUSU
REVSEN
REVEMA

Revisao
COMCORREVNOM
DOCCODRT
REVCOD
COMDATREV
COM1
COM2
COM3
COM4
COM5
COM6
COM7
COM8
COM9
COMRES
COMCOR

Diagrama de Classes de Domnio de Problema com atributos

3.6 Atividade: Produzir DER a partir do diagrama de classes de

domnio do problema
Neste ponto, os objetos de domnio de problema persistentes j esto definidos
e relacionados entre si. Podemos ento, criar o Diagrama de EntidadeRelacionamento do sistema, utilizando tcnicas simples de mapeamento entre
os diagramas, aqui descritas.
A necessidade de armazenamento persistente na forma de um banco de dados
relacional indicada pelos seguintes fatos[JAC94] :
-Informao contida nos objetos necessita ser persistente
-Mais de uma aplicao compartilha (parte dos) dados
-Estruturas de informao possuem grande nmero de instncias
-Existem buscas complexas na estrutura de informao
-Necessidade de gerao avanada de relatrios a partir da informao
armazenada
40

-Manipulao freqente de transaes do usurio

Deve-se decidir a partir do diagrama de classes de domnio do problema quais
objetos devem ser persistentes, ou seja, que devem ter seu contedo de
informao armazenado. Os objetos entidade so os candidatos naturais ao
armazenamento persistente.

3.6.1-Bancos de dados relacionais

3.6.1.1-Problemas
Quando armazena-se informao na forma de tabela do modelo relacional,
alguns problemas surgem, quais sejam:
-Somente armazenam-se dados, nunca comportamento
-Estruturas complexas tm que ser decompostas em tipos de dados primitivos
(problema da impedncia)
-Cria-se um forte acoplamento entre a aplicao e o banco de dados
-Como representar a herana
3.6.1.2- Representando objetos na forma de tabelas
Uma classe mapeada em tabelas da seguinte maneira:
-Alocar uma tabela classe
-Cada atributo primitivo tornar-se- uma coluna na tabela. Se o atributo for
complexo, adiciona-se uma tabela para o mesmo, ou pode-se parti-lo em
muitas colunas na tabela da classe.
-A chave primria ser o nico identificador da instncia, ou seja, ser o
identificador pelo qual a instncia ser unicamente reconhecida. O identificador
deve ser preferencialmente invisvel ao usurio, pois mudanas das chaves por
razes administrativas no devem afetar o mesmo; chaves geradas
automaticamente devem ser preferencialmente utilizadas.
-Cada instncia da classe ser agora representada por uma chave nesta tabela.
-Relaes 1 para muitos sero representadas por uma coluna de chave
estrangeira na classe de maior cardinalidade.
-Relaes muitos para muitos sero representadas por uma tabela contendo as
chaves primrias importadas das tabelas que a geraram, como chaves primrias
e/ou estrangeiras.
Com relao normalizao, tem-se o seguinte: um projeto de bancos de
dados baseado em um modelo de objetos est na terceira forma normal. Isto
ocorre porque na terceira forma normal, cada linha consiste de um identificador
com um nmero de atributos mutuamente independentes. Como o que
normalmente se tem em um modelo de objetos um objeto contendo um
identificador nico e um certo nmero de atributos no dependentes uns dos
outros, conclumos a afirmao anterior.A normalizao, entretanto, pode
41

ocasionar em muitas situaes, problemas de performance. Quando no for

possvel utilizarem-se tabelas de indexao especiais, deve-se desnormalizar a
base de dados para incrementar a performance. Isto vai, naturalmente , causar
os clssicos problemas de redundncia na base de dados, porm este problema
minimizado no modelo de objetos, j que esta redundncia vai estar
encapsulada no interior do objeto, portanto, livre do conhecimento do
programador.
3.6.1.1-Mapeamento de Herana
Para resolver o problema da herana, duas solues so possveis:
(1) Os atributos herdados so copiados para as tabelas que representam as
classes descendentes. No h tabela para a classe abstrata.
(2) A classe abstrata representada por uma tabela, para a qual as tabelas das
classes descendentes fazem referncia atravs de chave primria.

3.7-Atividade Produzir Prottipo da Interface

Quando da descrio dos casos de uso e da comunicao dos mesmos aos
usurios em potencial, importante descrever as interfaces em maior detalhe.
Se for uma interface homem-mquina pode-se mostrar o que o usurio
visualizar na tela quando executando o caso de uso ou prover simulaes mais
sofisticadas utilizando-se uma ferramenta especfica para isso. Desta forma
podemos simular os casos de uso da forma como ele aparecer aos usurios
antes mesmo de pensar em como realiz-los.Pode-se portanto, alocar s
descries dos casos de uso a interao real dos usurios com o sistema, o que
certamente eliminar vrios mal-entendidos. Deve-se frisar que quando da
definio de interfaces com usurios estes devem estar totalmente envolvidos.
Esta interface deve refletir a viso lgica do usurio com relao ao sistema.
Em nvel de prottipo executvel, podem ser documentos html ou jsp,
formulrios Delphi , Java ou VB, etc.
As interfaces produzidas nesta atividade sero utilizadas na descrio em nvel
real dos casos de uso, apresentada no prximo item.
No processo de codificao da interface proposto no Captulo 6, veremos que a
produo do prottipo em HTML ou JSP mais produtiva e, por conseguinte,
fortemente recomendada.
Deve-se ressaltar que nesta atividade que o papel do designer de interface
mais relevante: o prottipo deve refletir o aspecto final da aplicao.

3.8-Atividade Refinar Casos de Uso: produzir casos de uso reais

Os casos de uso reais possuem descries mais minuciosas de sua lgica,
incluindo nas descries expandidas, interaes com os atores por meio de
interfaces e solues comprometidas com tecnologias . Assim sendo, tais
42

descries envolvem interaes por meio de objetos de interface, como botes,

links, tabelas, displays, etc. Abaixo temos a descrio real do caso de uso
Registrar Revises de Documentos , com o qual o ator Revisor interage atravs
da interface mostrada na figura abaixo.
Aes do ator
Resposta do Sistema
1-O revisor seleciona de uma lista 2-Abre tela para registro de reviso do
(que contm somente os documentos documento.
alocados ao mesmo) o documento a
revisar.
3-O usurio pode:
Fazer
Download
3.1-Solicitar download do documento. 3.2-Iniciar

Documentos.
3.3-Preencher tabela, atribuindo nota
a quesitos de avaliao.
3.4-Registrar resultado da avaliao:

aceito, no aceito, aceito com nova

reviso, no aceito com nova reviso.
3.5-Preencher
campo
contendo
comentrios e correes.
3.6-Preencher data da reviso.
4-Finalizada a reviso, o usurio pode:
3.a.2-Se reviso tiver status de aceita,
3.a.1-Submeter a reviso ao sistema.
registra no documento sua data de
aprovao.
3.a.3-Grava reviso.
3.b.1-Criar uma nova reviso do 3.b.2-Se reviso tiver status de aceita,
registra no documento sua data de
documento.
aprovao.
3.b.3-Grava reviso.
3.b.4-Abre tela para registro da nova
reviso e inicia novamente este caso
de uso.

43

Figura Interface HTML do caso de uso Registrar Reviso de Documentos

3.9-Atividade Definir Classes de Interface

44

Toda funcionalidade especificada nas descries do caso de utilizao que seja

diretamente dependente do ambiente do sistema abstrada como classe de
interface. atravs destes objetos que os atores comunicam-se com o
sistema.
A tarefa de uma classe de interface traduzir as entradas dos atores ao
sistema em eventos no sistema e traduzir os eventos do sistema nos quais o
usurio esteja interessado em algo que apresentado ao ator.
As linguagens visuais (Delphi, C++ Builder por exemplo), retiram do
desenvolvedor a responsabilidade pela criao de classes de interface.
Entretanto, o desenvolvimento para internet, pressupe na parte das vezes, a
utilizao de formulrios HTML, de JSP ou de ASP, por exemplo, que se no
utilizados convenientemente, tornam a estrutura do projeto difcil de ser
mantida.
As classes de interface sero definidas segundo uma arquitetura que encapsule
mtodos para estruturao e apresentao de interfaces, segundo os seguintes
princpios:
-Detalhes de implementao so completamente omitidos do desenvolvedor,
que tem cincia apenas de mtodos e atributos para exibio e coleta de dados
da interface.
-As classes de interface devem ser hierarquicamente estruturadas por meio de
relaes de herana. Em aplicaes web especificamente, diversas pginas tm
partes em comum (cabealho e rodap, por exemplo), variando em outras (as
partes centrais e laterais). Estas partes em comum so alocadas a classes mes
e os detalhes especficos a classes derivadas.
As classes de interface, neste ponto, podem ser melhor definidas e
estruturadas, pois as descries reais j foram produzidas, detalhando a forma
de interao com as interfaces.

3.10-Atividade Definir Classes de Controle

As classes de controle encapsulam todas as regras de negcio da aplicao, ou
seja, implementam o fluxo de eventos da aplicao e, ainda, controlam as
requisies do usurio, alocando-as a aes especficas do sistema. Para cada
caso de uso identificamos uma classe de controle que encapsule estas
atribuies.

3.12-Atividade Produzir Diagramas de Classes de Anlise

O Diagrama de Classes de Anlise um refinamento realizado sobre o
diagrama de classes de domnio do problema de forma a incorporarem-se
nveis de abstrao ditados pelas classes de controle e interface j vistos
anteriormente. A viso proporcionada pelo diagrama de classes de anlise a
da arquitetura preliminar proposta para o sistema, livre ainda de aspectos de
45

implementao. Os subitens apresentam os passos sugeridos para gerao

deste diagrama.

3.12.1-Refinando a estrutura de classes entidade

As classes entidade tm em comum o fato de serem responsveis pelo
armazenamento e recuperao de informaes de banco de dados. Portanto
seria til em termos de reutilizao, a definio no diagrama de classes de
anlise de uma classe base que encapsule mtodos para armazenamento e
recuperao de informaes, quais sejam, incluir, alterar,excluir e pesquisar (no
mnimo, mas outros podem ser criados, desde que colaborem no intuito de
armazenar e recuperar informaes). No framework mostrado na Figura 3.27, a
classe BasePersistencia implementa os mtodos supra citados e as classes
entidade Persistente1, Persistente2 e PersistenteN herdam tais mtodos da
mesma.
BasePersistencia
Incluir()
Alterar()
Excluir()
Pesquisar()

Persistente1

Persistente2

PersistenteN

Figura 3.27 Framework para classes entidade (persistentes)

3.12.2-Adicionando classes de controle

No diagrama de classes de anlise, propomos a estruturao das classes de
controle j definidas segundo o framework exibido na Figura 3.28.

46

ControleCadastroBase

ControleInterface

ControleCadastroParticular

InterfacePagina

ControleFluxoEventos

Persistente

Figura 3.29 Framework proposto para classes de controle.

A classe ControleCadastroBase utilizada para encapsular aspectos comuns de
classes de controle que controlem fluxos de eventos de casos de uso de
cadastros de objetos do tipo Persistente j vistos. ControleCadastroParticular
particulariza a classe ControleCadastroBase para uma classe Persistente
especfica.
Por sua vez, ControleFluxoEventos possui mtodos que
implementam fluxos de eventos da aplicao e tambm se relaciona com
objetos do tipo Persistente. A classe ControleInterface serve apenas para
invocar classes de interface (InterfacePagina), que por sua vez invocam classes
do tipo ControleFluxoEventos.

3.12.3-Adicionando classes de interface

Propomos a alocao de classes de interface segundo o framework mostrado
na Figura 3.30, estruturado segundo os princpios citados no item 3.9. A classe
InterfaceBase encapsula todos os mtodos e atributos para exibio e coleta de
dados. A classe InterfaceEstruturaComum particulariza InterfaceBase contendo
a estrutura da pgina comum a todas as pginas da aplicao web. As classes
InterfacePagina1, InterfacePagina2 e InterfacePagina3 acrescentam detalhes a
InterfaceEstruturaComum. A classe InterfacePagina21 herda detalhes da classe
InterfacePagina2, particularizando alguma parte da mesma. No prximo
captulo descreveremos a implementao desta estrutura para Java-JSP.

47

Interface
Base

InterfaceEstruturaComum

InterfacePagina1

InterfacePagina2

InterfacePagina3
...

InterfacePagina21
...

Figura 3.30 Hierarquia genrica de classes de interface

3.12.4-Adicionando relaes de herana.

Nos item 3.12.1, 412.2 e 3.12.3 propusemos frameworks que incorporam
relaes de herana, de forma a agregar funcionalidades e caractersticas
comuns em classes mes, privilegiando o reutilizao das mesmas.
No diagrama de classes de anlise, devemos ainda identificar conceitos que
possuam pontos comuns, de forma que possamos criar uma relao de herana
dos mesmos, em relao a uma classe me que agregue tais pontos comuns
(conceitos mais gerais) . Este tipo de relao denominado generalizaoespecializao(gen-espec). A classe me, mais geral e abrangente, tambm
denominada supertipo ou classe base, e as classes filhas, particularizadas,
subtipos ou ainda classes derivadas.Vamos utilizar com mais freqncia os
termos classe base e classe derivada. Por exemplo as classes CompraaPrazo e
CompraaVista contm conceitos comuns, que podem ser generalizados na
classe base Compra. Assim, objetos das classes CompraaPrazo e CompraaVista
so tambm objetos do classe Compra.
Uma classe derivada sempre vai conter todos os atributos, associaes e
operaes da classe base. Se isto no ocorrer, a relao de herana no vai
existir. Entretanto, muitas vezes, a diviso de uma classe base em classes
derivadas apesar de semanticamente correta, pode no ser necessria.

48

Portanto, antes
seguinte[MO95]:

de

criarmos

um

subtipo,

devemos

considerar

-Se a classe derivada possui atributos, associaes e/ou operaes adicionais

em relao classe base. No exemplo citado, CompraaPrazo contm o atributo
NumeroParcelas que lhe particular;
-Se o conceito relacionado classe derivada tratado de maneira diferente ou
se comporta de maneira diferente da classe base ou de outras classes
derivadas. No exemplo citado, CompraaPrazo um tratamento particular para
uma Compra, diferente do tratamento dado a CompraaVista.
Compra

CompraaVista

CompraaPrazo

Figura 3.31-Relao de herana

Por outro lado, se temos vrias classes derivadas, a generalizao deve ser
motivada pelo seguinte:
-As classes derivadas tm atributos, associaes e/ou operaes comuns que
devem ser evidenciados em uma classe base;
-As classes derivadas so variaes de um conceito comum expresso na classe
base.
Os seguintes aspectos devem ser tambm considerados:
-Classes abstratas- Este conceito, definido no item 3.1.2.6, deve ser utilizado
quando a classe base no possui instncias tpicas (ou seja que no sejam
instncias das classes derivadas), existindo apenas para agregar os pontos
comuns das classes derivadas. No exemplo citado, Compra certamente ser
classificada como abstrata, pois no existem objetos que no sejam instncias
de uma das duas classes derivadas (CompraaVista e CompraaPrazo).
-Herana mltipla Classes derivadas podem herdar caractersticas de mais de
uma classe base. Quando isto ocorrer, teremos uma situao de herana
mltipla. Neste caso, instncias das classes derivadas vo ser instncias de
todas as classes bases e todos os atributos, associaes e operaes das
classes bases tambm pertencero s classes derivadas.

3.12.4-Determinar visibilidade dos atributos (encapsulamento)

49

Um aspecto relevante de aplicaes orientadas a objeto a possibilidade de se

ocultar ao desenvolvedor, informaes que no lhe sejam importantes,
disponibilizando apenas o relevante na consecuo das responsabilidades de
um determinado objeto. Neste passo, o analista determina o escopo de
visibilidade de atributos. Os critrios sugeridos para classificar quanto
visibilidade, no somente atributos, mas tambm mtodos (cuja obteno ser
descrita no prximo captulo), so os seguintes:
-Pblicos: atributos e operaes devem ser classificados como pblicos
quando sero utilizados em nvel de instncia de objetos, ou seja, a informao
ou funcionalidade deve ser til a quem quer que as utilize ou manipule.
-Protegidos : atributos e operaes so protegidos quando seu escopo
de visibilidade deve ser estendido a classes derivadas, mas no so relevantes
a instncias das classes bases e derivadas. o caso em que um atributo ou
operao so utilizados por outras operaes na classe base, e devem ser
igualmente utilizados nas classes derivadas.
-Privados: atributos e operaes privados no so importantes nem a
instncias da classe nem a suas classes derivadas. So de escopo local classe,
funcionando como auxlio realizao de funcionalidades de outros mtodos da
mesma.

3.12.5-Definir pacotes
Uma vez identificadas as classes de anlise, o sistema pode conter um grande
nmero de classes. Para um projeto de tamanho mdio, tipicamente de 30 a
100 classes sero especificadas. Para obter-se uma viso mais clara destes
objetos, pode-se agrup-los nos j apresentados pacotes (ver item 3.2). Este
agrupamento pode ser feito em diversos nveis, ou seja, pacotes podem conter
outros pacotes. Eles empacotam os objetos de forma a reduzir a complexidade.
O nvel mais baixo de um pacote denominado pacote de servio e
considerado uma unidade de modificaes atmica.
A diviso de um sistema em pacotes deve ser a priori baseada na
funcionalidade do mesmo. Todas as classes que tm um acoplamento
funcional mtuo forte devem ser colocados no mesmo pacotes. Deseja-se
tambm um mnimo de comunicao entre os pacotes, de forma a privilegiar o
baixo acoplamento.
Comeamos procurando por pacotes opcionais.Outros pacotes so definidos a
partir da funcionalidade do sistema: todas as classes envolvidas em uma parte
especfica da funcionalidade sero colocadas no mesmo pacote. Para identificar
partes de funcionalidade um bom procedimento remover uma determinada
classe do modelo e verificar se ela e classes relacionadas so ou no
suprfluos. Se forem, constituiro um mesmo pacote. Outros critrios que
podem auxiliar na identificao de pacotes:
-Modificaes em uma classe levam modificaes em outra classe?
-Elas se comunicam com o mesmo ator?
-So dependentes de uma terceira classe, de interface ou entidade?
50

-Uma classe executa muitas operaes de outra?

Aqui prevalece a idia da alta coeso no pacote e baixo acoplamento entre
pacotes. Um bom incio seria colocar a classe de controle em um pacote e
ento colocar classes entidade e de interface fortemente acopladas no mesmo
pacote.
Uma classe pode tambm no pertencer a nenhum pacote por no de encaixar
a nenhuma das funcionalidades ou por pertencer igualmente a duas ou mais.

51