Univ.

Tecnolgica Federal do Paran

Campus de Medianeira
Curso de Ps-Graduao Lato Sensu
em Engenharia de Software

ANLISE E PROJETO DE SISTEMAS

ORIENTADOS A OBJETOS
Parte 01

Prof. M.Sc. Alan Gavioli

alan@utfpr.edu.br

INTRODUO

Ementa:

Processo de anlise de software orientada a objetos.

Processo de projeto de software orientado a objetos.
Linguagem de modelagem UML. Ferramentas CASE
aplicveis.

Objetivos:

O aluno dever ser capaz de empregar apropriadamente

conceitos e frameworks da Engenharia de Software
Orientada a Objetos para realizar atividades de anlise e
projeto de sistemas relacionados a domnios reais.

INTRODUO

Aulas:

Expositivo-dialogadas, para apresentao dos

conceitos.
Prticas para aplicao dos conceitos (maior
parte da carga horria).

Avaliao:

Atividades prticas relacionadas aos contedos

das aulas (individuais e em grupos).

INTRODUO

Carga horria:

32 horas (4 sbados).

Requisitos para aprovao:

Frequncia s aulas: mnimo de 75%.

Mdia final >= 7,0.

ESCOPO DA DISCIPLINA
Processo da
Engenharia de
Software

Objetivo desta
disciplina

Anlise
Projeto
Implementao
Testes
Implantao
Manuteno

CUSTOS NO DESENV. DE SOFTWARE

MODELAGEM DE SOFTWARE

Modelagem de software consiste na utilizao de

notaes grficas e textuais com o objetivo de
construir modelos que representem as partes
essenciais de um sistema, considerando-se
diversas
perspectivas
diferentes
e
complementares.

MODELO = DIAGRAMA + TEXTO

Diagramas fornecem representaes concisas do sistema.

Conforme o ditado: Uma figura s vezes vale por 1.000
palavras.

Modelos da Eng. de SW tambm contm informaes

textuais.

Logo, dado um modelo de uma das perspectivas de um

sistema, seu diagrama, juntamente com a informao
textual associada, formam a documentao deste modelo.

PROCESSO DE DESENVOLVIMENTO

As tcnicas de modelagem perdem o sentido se

no soubermos como elas se encaixam no
processo de desenvolvimento (PD).

Por isso, antes de definir o que usar para modelar,

necessrio definir o processo a ser utilizado no
desenvolvimento de um sistema.

PD: a sequncia de fases/atividades que pode

ser seguida para o desenvolvimento de sistemas.

PROCESSO E GERNCIA

A
construo
de
um
software

um
empreendimento complexo, particularmente se
envolver muitas pessoas trabalhando durante um
perodo de tempo longo.

Essa a razo pela qual projetos de software

precisam ser gerenciados.

ELEMENTOS EM UM PROCESSO DE
DESENV. DE SOFTWARE

Pessoas:

Que trabalharo no desenvolvimento: precisam ser

organizadas para realizar o trabalho com correo e
eficincia.
Cliente(s): a comunicao com o(s) cliente(s) precisa
ocorrer de modo adequado, para que os requisitos do
produto sejam atendidos.

Produto: o que ser desenvolvido, neste caso o

software e outros itens associados a este.

ELEMENTOS EM UM PROCESSO DE
DESENV. DE SOFTWARE

Processo: precisa ser selecionado a fim de se

adequar ao pessoal e ao produto.

Projeto: precisa ser planejado, com estimativas de

esforo, tempo e custo financeiro para executar as
tarefas:
definio de produtos de trabalho;
estabelecimento de marcos de qualidade;
estabelecimento de mecanismos para monitorar
e controlar o trabalho definido no planejamento.

ESCOLHA DO PROCESSO

uma questo fundamental:

Definio do processo mais adequado ao tipo de software

e equipe que executar o projeto.

O gerente deve decidir qual o modelo de

processo mais apropriado para:

o cliente, que solicitou o produto, e as pessoas que

executaro o trabalho;
as caractersticas que o produto dever ter;
o ambiente de projeto no qual a equipe de software
trabalhar.

FERRAMENTAS DE SUPORTE AO
PROCESSO DE DESENVOLVIMENTO

So ferramentas que facilitam o desenv. de

software. Elas auxiliam, por exemplo:

na
na
no
no

construo dos modelos;

integrao do trabalho de cada membro da equipe;
gerenciamento do andamento do desenvolvimento;
aumento da produtividade e da qualidade do processo.

FERRAMENTAS DE SUPORTE AO
PROCESSO DE DESENVOLVIMENTO

Essas ferramentas so genericamente chamadas

de CASE (Computer-Aided Software Engineering).

As ferramentas CASE mais usadas para anlise e

projeto de software so as de modelagem,
classificadas como ferramentas de edio.

Algumas vantagens em usar:

Qualidade no processo e no produto final.

Produtividade.
Melhoria e reduo de cdigos de programao e de
custos na manuteno.
Reduo do retrabalho em todo o processo.

FERRAMENTAS DE SUPORTE AO
PROCESSO DE DESENVOLVIMENTO

Outras ferramentas importantes so, p. ex., as que

fornecem suporte ao gerenciamento:
Desenvolver cronogramas de tarefas.
Definir alocaes de verbas e pessoas.
Monitorar o progresso do processo e os gastos.
Gerar relatrios de gerenciamento.

ANLISE DE SOFTWARE

Anlise a etapa do processo de Eng. de

Software que inclui:

Estudo de Viabilidade: cronograma, custo e

tcnica (lembram das tcnicas de estimativa APF
e Use Case Points?);
Engenharia de Requisitos
disciplina anterior?);

(lembram

da

Modelagem em nvel de anlise (primeira

parte desta disciplina).

PROJETO DE SOFTWARE

Projeto a etapa seguinte anlise, e inclui:

Refinamento
Anlise.

expanso

dos

modelos

de

Construo de modelos de Projeto.

Validao da arquitetura candidata do software.

PROCESSOS DE DESENVOLVIMENTO

Os mais conhecidos e utilizados no mundo

so:

Processo de desenvolvimento baseado

Anlise
Essencial/Estruturada
e
Programao Estruturada.

na
na

Processo de desenvolvimento baseado em

Anlise e Projeto Orientados a Objetos e na
Programao Orientada a Objetos.

PROCESSOS DE DESENVOLVIMENTO

Os momentos de cada um:

Anlise e Programao Estruturada foram

dominantes
at
aproximadamente
o
incio/primeira metade da dcada de 1990.
A partir da segunda metade da dcada de 1990,
Anlise, Projeto e Programao Orientados
a Objetos passaram a predominar no mercado,
o que se mantm at o momento atual.

OUTROS PROCESSOS

Os Mtodos geis de desenvolvimento surgiram

como uma abordagem bastante diferente dos
processos tradicionais (Estruturado e Orientado a
Objetos).

Genericamente, focam as interaes contnuas

entre os stakeholders e pouca modelagem e
documentao, para agilizar ao mximo a criao
do produto final: o software.

OUTROS PROCESSOS

Modelos geis mais conhecidos:

XP (eXtreme Programming)
Scrum
Crystal
FDD
DAS
DSDM
Kanban

ANLISE
ESSENCIAL/ESTRUTURADA

Contm, como principais recursos:

Elementos bsicos para modelagem: entidade

externa, processo, fluxo de dados e depsito de
dados.
Diagrama de Contexto.
Diagramas de Fluxo de Dados (DFDs).
Dicionrio de Dados.
Diagrama Entidade-Relacionamento (DER).

ANLISE E PROJETO
ORIENTADOS A OBJETOS

Linguagem de modelagem
utilizada mundialmente:

Linguagem Unificada
Modeling Language).

de

padronizada

Modelagem

(UML

Unified

Processo de desenvolvimento mais conhecido:

Processo Unificado (PU), especialmente o produto criado

pela empresa Rational o Rational Unified Process
(RUP).

PROCESSO UNIFICADO

um framework de processo de desenvolvimento

de software O.O. genrico, que pode ser usado
para diferentes reas de aplicao, diferentes tipos
de organizaes e diferentes tamanhos de projeto.

Utiliza amplamente a UML.

Caractersticas do desenvolvimento no PU:

Iterativo e incremental.
Centrado em uma arquitetura robusta.
Orientado por casos de uso.

PROCESSO UNIFICADO

Fases:

Concepo.
Elaborao.
Construo.
Transio.

Iteraes.

Disciplinas.

Artefatos.

UML

INTRODUO
(MATERIAL COMPLEMENTAR)

UML

Proporciona
uma
forma-padro
para a
preparao de planos de arquitetura de
projetos de sistemas, incluindo:

Aspectos conceituais, tais como processos de

negcios e funes do sistema;
Itens concretos, como as classes escritas em
determinada ling. de programao, esquemas de
BDs e componentes de software reutilizveis.

UML

Breve histrico:

Primeira linguagem O.O.: Simula-67, criada na Noruega.

Dcada de 1980: Smalltalk, Objective C, C++ e Eiffel.
Paralelamente, surgiram mtodos orientados a objetos:
Booch, de Grady Booch, 1991;
OOSE (Object-Oriented Software Engineering), de
Jacobson, 1992;
OMT (Object Modeling Technique), de Rumbaugh,
1991;
CRC (Classe-Responsabilidade-Colaborador), 1989;
Shlaer-Mellor, de 1989;
Coad-Yourdon, de 1991;
Fusion (Booch, OMT, CRC, Mtodos Formais), 1994.

UML

Breve histrico:

A partir de 1995: mtodos Booch, OOSE e OMT passaram

a ser integrados, unificando notaes usadas por eles.
Junho de 1996: verso 0.9 da UML.
Novembro de 1997: UML 1.1 foi adotada pelo OMG
(Object Management Group).
OMG produziu as verses 1.3, 1.4 e 1.5.
Incio de 2005: OMG adotou a UML 2.0, que inclui recursos
adicionais e algumas alteraes importantes, quando
comparada UML 1.
A UML foi desenvolvida com a colaborao das principais
empresas mundiais da rea de software.
Verso mais recente: 2.4.1 (consulta em jan/2013).
uma linguagem continuamente em desenvolvimento.
Veja mais em www.uml.org.

UML POR QUE MODELAR?

A modelagem uma parte fundamental de todas

as atividades que levam entrega de um bom
software ao cliente.

Os modelos so construdos para:

Comunicar a estrutura e o comportamento desejados do

sistema;
Visualizar e controlar a arquitetura do sistema;
Compreender melhor o sistema que est sendo elaborado,
expondo oportunidades de reutilizao e simplificao;
Gerenciar os riscos.

UML POR QUE MODELAR?

Ainda no se convenceu? Ento mais algumas razes:

Modelos de sistemas complexos so construdos porque

no possvel compreender esses sistemas em sua
totalidade.

Um modelo consegue simplificar a realidade.

Ajudam a visualizar o sistema como ele dever ser.

Permitem especificar a estrutura ou o comportamento de

um sistema.

So um guia para a implementao do sistema.

Documentam decises tomadas.

UML ONDE PODE SER USADA?

Principais domnios em que a UML tem sido

utilizada:

Sistemas de informao industriais.

Sistemas do setor de prestao de servios (bancrios,
financeiros em geral, telecomunicaes, transportes, rea
da sade, dentre tantos outros).

Sistemas de controle de vendas (atacado e varejo).

Softwares educacionais e cientficos.

Servios distribudos baseados na Web.

BLOCOS DE CONSTRUO DA UML

A UML abrange
construo:

tipos

de

blocos

de

Itens.
Relacionamentos.
Diagramas.

Os itens so as abstraes identificadas como elementos

bsicos (mas fundamentais) para um modelo da UML.
Os relacionamentos servem para reunir os itens.
Os diagramas agrupam colees interessantes de itens.

ITENS DA UML

Na UML, foram classificados em 4 categorias:

Itens estruturais: so os substantivos utilizados em

modelos; so as partes mais estticas do modelo e
denotam elementos conceituais ou fsicos.
Itens comportamentais: so as partes dinmicas dos
modelos; so identificados como verbos e representam
comportamentos no tempo e no espao.
Itens de agrupamento: so as partes organizacionais de
um modelo; so blocos em que os modelos podem ser
decompostos.
Itens anotacionais: so as partes explicativas dos
modelos; so comentrios includos para descrever ou
esclarecer qualquer elemento do modelo.

ITENS DA UML

Itens estruturais:

Classes (incluindo atores).

Interfaces.
Casos de Uso.
Componentes.
Artefatos
(incluindo
aplicaes,
documentos,
arquivos, bibliotecas, pginas e tabelas).
Ns.

Itens comportamentais.
Itens de agrupamento.
Itens anotacionais.

ITENS DA UML

Itens estruturais.
Itens comportamentais:

Interaes (mensagens).
Estados.
Atividades (aes).

Itens de agrupamento.
Itens anotacionais.

ITENS DA UML

Itens estruturais.
Itens comportamentais.
Itens de agrupamento:

Pacotes.

Itens anotacionais:

Notas.

RELACIONAMENTOS NA UML

Na UML, h 4 tipos de relacionamentos entre

itens:

Dependncia.
Associao (que inclui
agregao composta).
Generalizao.
Realizao.

agregao

simples

RELACIONAMENTOS NA UML

Dependncia:

Relacionamento entre 2 itens que indica

que alterao de um (o independente) pode
afetar
a
semntica
do
outro
(o
dependente).

Associao.
Generalizao.
Realizao.

RELACIONAMENTOS NA UML

Dependncia.
Associao:

Relacionamento entre classes que descreve

conexes entre objetos que so instncias
das classes. Se for agregao, representa
um relacionamento entre o todo e suas
partes.
A representao grfica pode incluir rtulo,
nomes de papis e multiplicidades.

Generalizao.
Realizao.

RELACIONAMENTOS NA UML

Dependncia.
Associao.
Generalizao:

Relacionamento de generalizao/especializao,
em que os objetos dos elementos especializados (os
filhos) compartilham a estrutura e o comportamento
dos objetos do elemento generalizado (os pais).
Muitas vezes, referido como relacionamento um
tipo de.

Realizao.

RELACIONAMENTOS NA UML

Dependncia.
Associao.
Generalizao.
Realizao:

Duas possibilidades: 1) Entre interfaces e

as classes ou componentes que as realizam
(o tipo mais comum); 2) Entre casos de uso
e as colaboraes que os realizam.

A UML 2.x

Caractersticas introduzidas na UML 2.x:

O novo padro UML inclui 4 grandes caractersticas. A

primeira um mecanismo de extenso de primeira classe, que
permite aos modeladores a adio das suas prprias
metaclasses, facilitando assim a definio de novos Perfis UML e
o alargamento da modelagem a novas reas de aplicao. A
segunda caracterstica tem a ver com uma representao mais
exata e mais precisa das relaes, melhorando assim a
modelagem da herana, composio e agregao. A terceira
caracterstica refere-se a uma melhor modelagem do
comportamento, aumentando o suporte para encapsulamento e
escalabilidade, melhorando a estrutura dos diagramas de
sequncia e removendo as restries em nvel da representao
de esquemas de atividade para state machines. A quarta
caracterstica tem a ver com o fato das melhorias introduzidas na
linguagem simplificarem a sintaxe e a semntica, alm de
organizarem melhor a sua estrutura global (OMG).

DIAGRAMAS DA UML 2.x

Na UML 2.x so 13 diagramas (a UML 1.x tem 9). Mas

segundo os criadores da UML, h prioridades diferentes:
Diagrama

Descrio

Prioridade de
aprendizagem

Diagrama de Casos
de Uso

Exibe um conjunto de casos de uso

e atores, bem como seus
relacionamentos.

Elevada

Diagrama de
Classes

Exibe um conjunto de classes,

interfaces e colaboraes, bem
como seus relacionamentos.

Elevada

Diagrama de
Sequncia

Um dos diagramas de interao,

com nfase na ordenao temporal
das mensagens trocadas por
objetos.

Elevada

Diagrama de
Atividades

Exibe a estrutura de um
processo/computao, como o
fluxo de controle e os dados de
cada etapa da computao.

Elevada

DIAGRAMAS DA UML 2.x

Diagrama

Descrio

Prioridade de
aprendizagem

Diagrama de
Componentes

Apresenta os componentes que

compem um sistema ou at
uma empresa. So apresentados
os componentes, suas interrelaes e suas interfaces.

Mdia

Diagrama de
Mquina/Grfico de
Estados

Exibe uma mquina de estados,

formada por estados, transies,
eventos e atividades.

Mdia

Diagrama de
Implantao

Mostra a configurao dos ns

de processamento em tempo de
execuo e os componentes
deles.

Mdia

DIAGRAMAS DA UML 2.x

Diagrama

Descrio

Diagrama de
Comunicaes

outro diagrama de interao,

mas com nfase na organizao
estrutural dos objetos que
enviam e recebem mensagens.

Baixa

Diagrama de
Objetos

Mostra os objetos e suas

relaes em um dado momento;
normalmente um caso especial
de um diag. de classes ou de
comunicao.

Baixa

Praticamente idntico ao
diagrama de componentes,
sendo diferente apenas por ser
aplicvel a qualquer classe.

Baixa

Diagrama de
Estruturas
Compostas (NOVO)

Prioridade de
aprendizagem

DIAGRAMAS DA UML 2.x

Diagrama

Descrio

Diagrama de Pacote
(NOVO)

Mostra como os elementos do

modelo esto organizados em
pacotes e as dependncias entre
tais pacotes.

Baixa

Diagrama de
Temporizao
(NOVO)

Mostra a mudana de estado ou

condio de um objeto ao longo
do tempo, em resposta a
eventos externos. Seu uso
bastante especfico.

Baixa

Hbrido de um diagrama de
atividades e um diagrama de
sequncias. de uso muito
especfico.

Baixa

Diagrama de Viso
Geral da Interao
(NOVO)

Prioridade de
aprendizagem

DIAGRAMAS
DA UML 2.x

UML

MODELO DE CASOS DE USO

(MATERIAL COMPLEMENTAR)

DESCRIES NARRATIVAS

Cada caso de uso definido atravs da descrio

narrativa das interaes (cenrios) que ocorrem
entre o(s) elemento(s) externo(s) e o sistema.

Mas h vrias formas de descrever casos de uso.

FORMAS DE DESCREVER
CASOS DE USO

Formato:

Detalhamento:

Contnua.
Numerada.
Tabela/numerada.
Sucinto.
Expandido.

Grau de abstrao:

Essencial.
Real.

DESCRIO CONTNUA

Exemplo:
O Cliente chega ao caixa eletrnico e insere seu
carto. O Sistema requisita a senha do Cliente.
Aps o Cliente fornecer sua senha e esta ser
validada, o Sistema exibe as opes de
operaes possveis. O Cliente opta por realizar
um saque. Ento o Sistema requisita o total a
ser sacado. O Cliente informa o valor desejado.
O Sistema fornece a quantia e imprime um
comprovante de saque.

DESCRIO NUMERADA

Exemplo:
1. Cliente insere seu carto no caixa eletrnico.
2. Sistema apresenta solicitao de senha.
3. Cliente digita sua senha.
4.
Sistema
exibe
menu
de
operaes
disponveis.
5. Cliente indica que deseja realizar um saque.
6. Sistema requisita quantia a ser sacada.
7. Cliente informa o valor desejado.
8. Sistema fornece a quantia e um comprovante
de saque.

DESCRIO TABELA/NUMERADA
Cliente
1. Insere seu carto no caixa
eletrnico.
3. Digita sua senha.

5. Indica que deseja realizar

um saque.
7. Informa o valor desejado.

Sistema

2. Apresenta solicitao de
senha.
4. Exibe menu de operaes
disponveis.
6. Requisita quantia a ser
sacada.
8. Fornece a quantia e um
comprovante de saque.

DETALHAMENTO

O grau de detalhamento a ser utilizado na

descrio de um caso de uso pode variar
dependendo da fase em que se encontra o
desenvolvimento do sistema.

Fase de Anlise: um caso de uso sucinto

descreve as interaes sem muitos detalhes.

Fase de Projeto: um caso de uso expandido

descreve as interaes em detalhes.

GRAU DE ABSTRAO

O grau de abstrao de um caso de uso diz

respeito existncia ou no de meno
tecnologia a ser utilizada na descrio deste caso
de uso.

Um caso de uso essencial no faz meno

tecnologia a ser utilizada; normalmente utilizado
na etapa de anlise.

Um caso de uso real apresenta detalhes da

tecnologia a ser utilizada em sua implementao;
normalmente utilizado na etapa de projeto.

GRAU DE ABSTRAO

Essencial:

1 - O Cliente se identifica para o sistema atravs dos seus

dados.
2 - O sistema ao reconhec-lo deve apresentar as opes
de operaes:
2.1 - Realizar saque
2.2 - Realizar pagamento
2.3 - Emitir extrato
3 - Escolhida uma das operaes, o sistema a chamar.

GRAU DE ABSTRAO

Real:

1 - O cliente se identifica para o sistema atravs do seu

carto magntico com chip.
2 - O sistema l o carto e apresenta as opes de
operaes:
2.1 - Realizar saque
2.2 - Realizar pagamento
2.3 - Emitir extrato
3 - Escolhida uma das operaes, atravs do teclado, o
sistema a chamar.

DOCUMENTAO DOS
CASOS DE USO

A UML no define uma estruturao especfica a

ser utilizada na descrio do formato expandido de
um caso de uso.

A equipe de desenvolvimento deve utilizar o

formato de descrio que lhe for realmente til.

EXEMPLO DE DOCUMENTAO

EXEMPLO DE DOCUMENTAO

UML

MODELO DE CLASSES
(MATERIAL COMPLEMENTAR)

VISES INTERNA E EXTERNA DE UM

SISTEMA O. O.

Externamente, os atores visualizam resultados de

clculos, relatrios produzidos, confirmaes de
requisies realizadas, etc (diagrama de casos
de uso mostra isso).

Internamente, os objetos colaboram uns com os

outros para produzir os resultados (isto o
diagrama de casos de uso no mostra).

Essa colaborao pode ser vista sob o aspecto

dinmico e sob o aspecto estrutural esttico.

MODELO DE CLASSES

O diagrama da UML utilizado para representar os

aspectos estticos das colaboraes entre
objetos o diagrama de classes.

O modelo de classes evolui ( incrementado)

durante o desenvolvimento do sistema.

IDENTIFICAO DAS CLASSES

NECESSRIAS

Anlise dos casos de uso:

Cada caso de uso analisado para identificar classes

candidatas.

Premissa: a partir da descrio textual dos

casos de uso, podem-se derivar as classes:

A existncia de uma classe em um sistema s se justifica

se ela participa de alguma forma para o comportamento
externamente visvel do sistema.
Vantagem: esta abordagem bastante simples.
Desvantagem: depende de como os casos de uso foram
escritos (as formas de expressar uma mesma ideia so
bastante numerosas).

IDENTIFICAO DAS CLASSES

NECESSRIAS

CATEGORIAS DE
RESPONSABILIDADES

Costuma-se categorizar os objetos de um

sistema
de
acordo
com
o
tipo
de
responsabilidade atribuda:

Objetos de entidade.

Objetos de controle.

Objetos de fronteira.

OBJETOS DE ENTIDADE

Um objeto de entidade um repositrio para

alguma informao manipulada pelo sistema.

Esses objetos representam conceitos do domnio do

negcio.

Normalmente
esses
objetos
informaes persistentes.

H vrias instncias de uma mesma classe de

entidade coexistindo no sistema.

armazenam

OBJETOS DE FRONTEIRA

Classes de fronteira realizam a comunicao do

sistema com atores, sejam eles outros sistemas,
equipamentos ou seres humanos.

H trs tipos principais de classes de fronteira:

As que se comunicam com usurios (atores humanos);

As que se comunicam com outros sistemas;
As que se comunicam com dispositivos atrelados ao
sistema.

OBJETOS DE CONTROLE

So a ponte de comunicao entre objetos de

fronteira e objetos de entidade.

Responsveis por controlar a lgica de execuo

correspondente a um caso de uso.

Decidem o que o sistema deve fazer quando um

evento externo relevante ocorre.

Realizam o controle do processamento.

Agem como coordenadores/controladores dos outros
objetos para a realizao de um ou mais casos de uso.

EXERCCIO 1

Utilizando a listagem de requisitos levantados, as

especificaes dos casos de uso (nvel ANLISE) e o
diagrama de classes (nvel ANLISE) do sistema que
seu grupo est modelando:

Atualize as descries dos casos de uso para o nvel de

PROJETO.

Construa o diagrama de classes em nvel de PROJETO.

Envie a soluo deste exerccio pelo Moodle, em um

nico arquivo .pdf.

UML

DIAGRAMA DE OBJETOS

DIAGRAMA DE OBJETOS

Alm do diagrama de classes, a UML define um

segundo tipo de diagrama estrutural: o
diagrama de objetos.

Pode ser visto com uma instncia de diagramas

de classes.

Representa uma fotografia do sistema em um

certo instante.

Exibe as ligaes formadas entre objetos conforme estes

interagem e os valores dos seus atributos.

DIAGRAMA DE OBJETOS

Exemplo 1:

DIAGRAMA DE OBJETOS

Exemplo 2:

EXERCCIO 2

A partir do diagrama de classes (nvel ANLISE) do

sistema que seu grupo est modelando:

Elabore um diagrama de objetos que exiba as ligaes

formadas entre objetos conforme estes interajam para a
realizao de um dos casos de uso do sistema.

Junte este diagrama ao resultado do exerccio 1.

UML

MAPEAMENTO OBJETO-RELACIONAL

INTRODUO

Quando se opta pela anlise, pelo projeto e pela

implementao de acordo com o paradigma OO,
em tese o ideal seria optar tambm por um SGBD
orientado a objetos.

Problema: os SGBDs OO ainda esto longe de conquistar

o mercado, que em sua grande maioria continua utilizando
SGBDs relacionais.

Mesmo tendo um banco de dados (BD) relacional,

podemos unir dados e comportamento em classes,
isto atravs do mapeamento objeto-relacional.

A IMPORTNCIA DO OID

OID: Object Identification, ou seja, identificador

nico de um objeto.

Para minimizar o impacto do desencontro objetorelacional, temos que manter um paralelo em

alguns aspectos aos BDs relacionais, a exemplo
disso temos os OIDs.

Como nossos objetos sero salvos em um BD

relacional, devemos disponibilizar uma forma de
encontr-los.

MAPEAMENTO OBJETO-RELACIONAL

Pacotes, classes e atributos podem ser mapeados

para BDs relacionais (esquemas, tabelas, colunas),
embora sejam de natureza diferente.

Mapeamento:
Modelo OO

Banco Relacional

Classes

Relaes (tabelas)

Objetos

Tuplas (registros, linhas)

Mtodos

Stored procedures

Atributos

Campos (colunas)

MAPEAMENTO OBJETO-RELACIONAL

Geralmente, somente as classes concretas e

categorizadas como classes de entidade so
mapeadas para tabelas. Mapeamento:

MAPEAMENTO OBJETO-RELACIONAL

Os relacionamentos entre classes (associao,

agregao simples, composio, generalizao) so
mapeados para uma ou mais tabelas.

MAPEAMENTO DA HERANA

Existem 3 formas bsicas para se implementar a

herana, que um conceito de orientao a
objetos, em um BD relacional.
Forma 1: uma tabela para toda hierarquia de classe nessa
situao, temos uma tabela que armazena os dados de
professor e de aluno.

MAPEAMENTO DA HERANA

Forma 2: uma tabela por classe concreta da hierarquia.

Nessa implementao, h dificuldade para a insero de
novos atributos comuns s classes da hierarquia. Ex: se
formos inserir um novo atributo classe-base Pessoa, p.
ex. o atributo e-mail, deveremos lembrar que a coluna EMAIL
dever ser criada em ambas as tabelas (subclasses).

MAPEAMENTO DA HERANA

Forma 3: uma tabela por classe. Muitos afirmam que esta

a melhor forma de implementar herana, pois o BD fica
normalizado e se aproxima mais da realidade do modelo de
classes. Porm, com essa implementao vrias tabelas so
criadas para representar a herana, e isso pode implicar em
uma perda relativa de desempenho do BD.

MAPEAMENTO DE ATRIBUTOS

Ao transpor-se um objeto para uma tabela de BD

relacional, os atributos do mesmo so mapeados
em colunas da tabela. Este processo de
mapeamento deve levar em considerao fatores
como a tipagem dos dados e o comprimento
mximo dos campos.

Em diversos casos, atributos de um objeto no

devem ter obrigatoriamente uma coluna em uma
tabela que os referencie.

MAPEAMENTO DE ASSOCIAES

Os relacionamentos de associao entre objetos

so uma das caractersticas mais facilmente
mapeadas. Conceitualmente, existem apenas trs
tipos de relacionamentos possveis:

um-para-um;

um-para-muitos; e

muitos-para-muitos.

EXERCCIO 3

A partir do diagrama de classes (nvel ANLISE) do

sistema que seu grupo est modelando:

Faa o mapeamento objeto-relacional das classes de

entidade para relaes (tabelas) de um BD relacional.
A construo de um DER neste exerccio opcional,
sendo obrigatrio apenas apresentar as tabelas e seus
atributos (campos).

Junte a soluo deste exerccio aos resultados dos

exerccios anteriores.

Envie o arquivo completo dos exerccios pelo Moodle, em

um nico arquivo .pdf.

BIBLIOGRAFIA UTILIZADA

BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: Guia do Usurio. 2 ed. Rio
de Janeiro: Campus, 2005.

LARMAN, C. Utilizando UML e Padres: uma introduo Anlise e ao Projeto

Orientados a Objetos e ao Desenvolvimento Iterativo. 3 ed. Porto Alegre:
Bookman, 2007.

MEDEIROS, E. S. Desenvolvendo Software com UML 2.0: Definitivo. So

Paulo: Pearson Makron Books, 2005.

PRESSMAN, R. S. Engenharia de Software: uma abordagem profissional. 7

ed. So Paulo: Artmed, 2011.

SOMMERVILLE, I. Engenharia de Software. 9 ed. So Paulo: Pearson, 2011.

WAZLAWICK, R. S. Anlise e Projeto de Sistemas de Informao Orientados

a Objetos. Rio de Janeiro: Elsevier, 2004.