parte 1 - analise projeto oo - alan gavioli

Univ. Tecnológica Federal do Paraná

Campus de Medianeira

Curso de Pós-Graduação Lato Sensu

em Engenharia de Software

Prof. M.Sc. Alan Gavioli

alan@utfpr.edu.br

ANÁLISE E PROJETO DE SISTEMAS

ORIENTADOS A OBJETOS

Parte 01

INTRODUÇÃO

Ementa: Processo de análise de software orientada a objetos.

Processo de projeto de software orientado a objetos.Linguagem de modelagem UML. Ferramentas CASEaplicáveis.

Objetivos: O aluno deverá ser capaz de empregar apropriadamente

conceitos e frameworks da Engenharia de SoftwareOrientada a Objetos para realizar atividades de análise eprojeto de sistemas relacionados a domínios reais.

INTRODUÇÃO

Aulas:

Expositivo-dialogadas, para apresentação dosconceitos.

Práticas para aplicação dos conceitos (maiorparte da carga horária).

Avaliação:

Atividades práticas relacionadas aos conteúdosdas aulas (individuais e em grupos).

INTRODUÇÃO

Carga horária: 32 horas (4 sábados).

Requisitos para aprovação: Frequência às aulas: mínimo de 75%.

Média final >= 7,0.

ESCOPO DA DISCIPLINA

ImplementaçãoTestes

ImplantaçãoManutenção

AnáliseProjeto

Processo da Engenharia de Software

Objetivo desta disciplina

CUSTOS NO DESENV. DE SOFTWARE

MODELAGEM DE SOFTWARE

Modelagem de software consiste na utilização denotações gráficas e textuais com o objetivo deconstruir modelos que representem as partesessenciais de um sistema, considerando-sediversas perspectivas diferentes ecomplementares.

MODELO = DIAGRAMA + TEXTO

Diagramas fornecem representações concisas do sistema.Conforme o ditado: “Uma figura às vezes vale por 1.000palavras”.

Modelos da Eng. de SW também contêm informaçõestextuais.

Logo, dado um modelo de uma das perspectivas de umsistema, seu diagrama, juntamente com a informaçãotextual associada, formam a documentação deste modelo.

PROCESSO DE DESENVOLVIMENTO

As técnicas de modelagem perdem o sentido senão soubermos como elas se encaixam noprocesso de desenvolvimento (PD).

Por isso, antes de definir o que usar para modelar,é necessário definir o processo a ser utilizado nodesenvolvimento de um sistema.

PD: é a sequência de fases/atividades que podeser seguida para o desenvolvimento de sistemas.

PROCESSO E GERÊNCIA

A construção de um software é umempreendimento complexo, particularmente seenvolver muitas pessoas trabalhando durante umperíodo de tempo longo.

Essa é a razão pela qual projetos de softwareprecisam ser gerenciados.

ELEMENTOS EM UM PROCESSO DE DESENV. DE SOFTWARE

Pessoas:

Que trabalharão no desenvolvimento: precisam serorganizadas para realizar o trabalho com correção eeficiência.

Cliente(s): a comunicação com o(s) cliente(s) precisaocorrer de modo adequado, para que os requisitos doproduto sejam atendidos.

Produto: é o que será desenvolvido, neste caso osoftware e outros itens associados a este.

ELEMENTOS EM UM PROCESSO DE DESENV. DE SOFTWARE

Processo: precisa ser selecionado a fim de seadequar ao pessoal e ao produto.

Projeto: precisa ser planejado, com estimativas deesforço, tempo e custo financeiro para executar astarefas:

definição de produtos de trabalho;

estabelecimento de marcos de qualidade;

estabelecimento de mecanismos para monitorare controlar o trabalho definido no planejamento.

ESCOLHA DO PROCESSO

É uma questão fundamental:

Definição do processo mais adequado ao tipo de softwaree à equipe que executará o projeto.

O gerente deve decidir qual é o modelo deprocesso mais apropriado para:

o cliente, que solicitou o produto, e as pessoas queexecutarão o trabalho;

as características que o produto deverá ter;

o ambiente de projeto no qual a equipe de softwaretrabalhará.

FERRAMENTAS DE SUPORTE AO PROCESSO DE DESENVOLVIMENTO

São ferramentas que facilitam o desenv. desoftware. Elas auxiliam, por exemplo:

na construção dos modelos;

na integração do trabalho de cada membro da equipe;

no gerenciamento do andamento do desenvolvimento;

no aumento da produtividade e da qualidade do processo.

X

FERRAMENTAS DE SUPORTE AO PROCESSO DE DESENVOLVIMENTO

Essas ferramentas são genericamente chamadasde CASE (Computer-Aided Software Engineering).

As ferramentas CASE mais usadas para análise eprojeto de software são as de modelagem,classificadas como ferramentas de edição.

Algumas vantagens em usar: Qualidade no processo e no produto final.

Produtividade.

Melhoria e redução de códigos de programação e decustos na manutenção.

Redução do retrabalho em todo o processo.

FERRAMENTAS DE SUPORTE AO PROCESSO DE DESENVOLVIMENTO

Outras ferramentas importantes são, p. ex., as quefornecem suporte ao gerenciamento:

Desenvolver cronogramas de tarefas.

Definir alocações de verbas e pessoas.

Monitorar o progresso do processo e os gastos.

Gerar relatórios de gerenciamento.

ANÁLISE DE SOFTWARE

Análise é a etapa do processo de Eng. deSoftware que inclui:

Estudo de Viabilidade: cronograma, custo etécnica (lembram das técnicas de estimativa APFe Use Case Points?);

Engenharia de Requisitos (lembram dadisciplina anterior?);

Modelagem em nível de análise (primeiraparte desta disciplina).

PROJETO DE SOFTWARE

Projeto é a etapa seguinte à análise, e inclui:

Refinamento e expansão dos modelos deAnálise.

Construção de modelos de Projeto.

Validação da arquitetura candidata do software.

PROCESSOS DE DESENVOLVIMENTO

Os mais conhecidos e utilizados no mundosão:

Processo de desenvolvimento baseado naAnálise Essencial/Estruturada e naProgramação Estruturada.

Processo de desenvolvimento baseado emAnálise e Projeto Orientados a Objetos e naProgramação Orientada a Objetos.

PROCESSOS DE DESENVOLVIMENTO

Os momentos de cada um:

Análise e Programação Estruturada foramdominantes até aproximadamente oinício/primeira metade da década de 1990.

A partir da segunda metade da década de 1990,Análise, Projeto e Programação Orientadosa Objetos passaram a predominar no mercado,o que se mantém até o momento atual.

OUTROS PROCESSOS

Os Métodos Ágeis de desenvolvimento surgiramcomo uma abordagem bastante diferente dosprocessos tradicionais (Estruturado e Orientado aObjetos).

Genericamente, focam as interações contínuasentre os stakeholders e pouca modelagem edocumentação, para agilizar ao máximo a criaçãodo produto final: o software.

OUTROS PROCESSOS

Modelos Ágeis mais conhecidos:

XP (eXtreme Programming)

Scrum

Crystal

FDD

DAS

DSDM

Kanban

ANÁLISE ESSENCIAL/ESTRUTURADA

Contém, como principais recursos:

Elementos básicos para modelagem: entidadeexterna, processo, fluxo de dados e depósito dedados.

Diagrama de Contexto.

Diagramas de Fluxo de Dados (DFDs).

Dicionário de Dados.

Diagrama Entidade-Relacionamento (DER).

ANÁLISE E PROJETOORIENTADOS A OBJETOS

Linguagem de modelagem padronizada eutilizada mundialmente:

Linguagem Unificada de Modelagem (UML - UnifiedModeling Language).

Processo de desenvolvimento mais conhecido:

Processo Unificado (PU), especialmente o produto criadopela empresa Rational – o Rational Unified Process(RUP).

PROCESSO UNIFICADO

É um framework de processo de desenvolvimentode software O.O. genérico, que pode ser usadopara diferentes áreas de aplicação, diferentes tiposde organizações e diferentes tamanhos de projeto.

Utiliza amplamente a UML.

Características do desenvolvimento no PU: Iterativo e incremental.

Centrado em uma arquitetura robusta.

Orientado por casos de uso.

PROCESSO UNIFICADO

Fases:

Concepção.

Elaboração.

Construção.

Transição.

Iterações.

Disciplinas.

Artefatos.

UML

INTRODUÇÃO

(MATERIAL COMPLEMENTAR)

UML

Proporciona uma forma-padrão para apreparação de planos de arquitetura deprojetos de sistemas, incluindo:

Aspectos conceituais, tais como processos denegócios e funções do sistema;

Itens concretos, como as classes escritas emdeterminada ling. de programação, esquemas deBDs e componentes de software reutilizáveis.

UML

Breve histórico: Primeira linguagem O.O.: Simula-67, criada na Noruega.

Década de 1980: Smalltalk, Objective C, C++ e Eiffel.

Paralelamente, surgiram métodos orientados a objetos:

• Booch, de Grady Booch, 1991;

• OOSE (Object-Oriented Software Engineering), deJacobson, 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, Métodos Formais), 1994.

UML

Breve histórico: A partir de 1995: métodos Booch, OOSE e OMT passaram

a ser integrados, unificando notações usadas por eles.

Junho de 1996: versão 0.9 da UML.

Novembro de 1997: UML 1.1 foi adotada pelo OMG(Object Management Group).

OMG produziu as versões 1.3, 1.4 e 1.5.

Início de 2005: OMG adotou a UML 2.0, que inclui recursosadicionais e algumas alterações importantes, quandocomparada à UML 1.

A UML foi desenvolvida com a colaboração das principaisempresas mundiais da área de software.

Versão 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 todasas atividades que levam à entrega de um bomsoftware ao cliente.

Os modelos são construídos para:

Comunicar a estrutura e o comportamento desejados dosistema;

Visualizar e controlar a arquitetura do sistema;

Compreender melhor o sistema que está sendo elaborado,expondo oportunidades de reutilização e simplificação;

Gerenciar os riscos.

UML – POR QUE MODELAR?

Ainda não se convenceu? Então mais algumas razões:

Modelos de sistemas complexos são construídos porquenão é possível compreender esses sistemas em suatotalidade.

Um modelo consegue simplificar a realidade.

Ajudam a visualizar o sistema como ele deverá ser.

Permitem especificar a estrutura ou o comportamento deum sistema.

São um guia para a implementação do sistema.

Documentam decisões tomadas.

UML – ONDE PODE SER USADA?

Principais domínios em que a UML tem sidoutilizada:

Sistemas de informação industriais.

Sistemas do setor de prestação de serviços (bancários,financeiros em geral, telecomunicações, transportes, áreada saúde, dentre tantos outros).

Sistemas de controle de vendas (atacado e varejo).

Softwares educacionais e científicos.

Serviços distribuídos baseados na Web.

BLOCOS DE CONSTRUÇÃO DA UML

A UML abrange 3 tipos de blocos deconstrução:

Itens.

Relacionamentos.

Diagramas.

Os itens são as abstrações identificadas como elementosbásicos (mas fundamentais) para um modelo da UML.

Os relacionamentos servem para reunir os itens.

Os diagramas agrupam coleções interessantes de itens.

ITENS DA UML

Na UML, foram classificados em 4 categorias:

Itens estruturais: são os substantivos utilizados emmodelos; são as partes mais estáticas do modelo edenotam elementos conceituais ou físicos.

Itens comportamentais: são as partes dinâmicas dosmodelos; são identificados como verbos e representamcomportamentos no tempo e no espaço.

Itens de agrupamento: são as partes organizacionais deum modelo; são blocos em que os modelos podem serdecompostos.

Itens anotacionais: são as partes explicativas dosmodelos; são comentários incluídos para descrever ouesclarecer qualquer elemento do modelo.

ITENS DA UML

Itens estruturais: Classes (incluindo atores).

Interfaces.

Casos de Uso.

Componentes.

Artefatos (incluindo aplicações, documentos,arquivos, bibliotecas, páginas e tabelas).

Nós.

Itens comportamentais.

Itens de agrupamento.

Itens anotacionais.

ITENS DA UML

Itens estruturais.

Itens comportamentais:

Interações (mensagens).

Estados.

Atividades (ações).

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 entreitens:

Dependência.

Associação (que inclui agregação simples eagregação composta).

Generalização.

Realização.

RELACIONAMENTOS NA UML

Dependência:

Relacionamento entre 2 itens que indicaque alteração de um (o independente) podeafetar a semântica do outro (odependente).

Associação.

Generalização.

Realização.

RELACIONAMENTOS NA UML

Dependência.

Associação: Relacionamento entre classes que descreve

conexões entre objetos que são instânciasdas classes. Se for agregação, representaum relacionamento entre o “todo” e suas“partes”.

A representação gráfica pode incluir rótulo,nomes de papéis e multiplicidades.

Generalização.

Realização.

RELACIONAMENTOS NA UML

Dependência.

Associação.

Generalização: Relacionamento de generalização/especialização,

em que os objetos dos elementos especializados (osfilhos) compartilham a estrutura e o comportamentodos objetos do elemento generalizado (os pais).Muitas vezes, referido como relacionamento “é umtipo de”.

Realização.

RELACIONAMENTOS NA UML

Dependência.

Associação.

Generalização.

Realização:

Duas possibilidades: 1) Entre interfaces eas classes ou componentes que as realizam(o tipo mais comum); 2) Entre casos de usoe as colaborações que os realizam.

A UML 2.x

Características introduzidas na UML 2.x: “O novo padrão UML inclui 4 grandes características. A

primeira é um mecanismo de extensão de primeira classe, quepermite aos modeladores a adição das suas própriasmetaclasses, facilitando assim a definição de novos Perfis UML eo alargamento da modelagem a novas áreas de aplicação. Asegunda característica tem a ver com uma representação maisexata e mais precisa das relações, melhorando assim amodelagem da herança, composição e agregação. A terceiracaracterística refere-se a uma melhor modelagem docomportamento, aumentando o suporte para encapsulamento eescalabilidade, melhorando a estrutura dos diagramas desequência e removendo as restrições em nível da representaçãode esquemas de atividade para state machines. A quartacaracterística tem a ver com o fato das melhorias introduzidas nalinguagem simplificarem a sintaxe e a semântica, além deorganizarem melhor a sua estrutura global” (OMG).

DIAGRAMAS DA UML 2.x

Na UML 2.x são 13 diagramas (a UML 1.x tem 9). Massegundo os criadores da UML, há prioridades diferentes:

Diagrama Descrição 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 colaborações, bem como seus relacionamentos.

Elevada

Diagrama de Sequência

Um dos diagramas de interação, com ênfase na ordenação temporal das mensagens trocadas por objetos.

Elevada

Diagrama de Atividades

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

Elevada

DIAGRAMAS DA UML 2.x

Diagrama Descrição Prioridade de aprendizagem

Diagrama de Componentes

Apresenta os componentes que compõem um sistema ou até uma empresa. São apresentados os componentes, suas inter-relações e suas interfaces.

Média

Diagrama de Máquina/Gráfico de

Estados

Exibe uma máquina de estados, formada por estados, transições, eventos e atividades.

Média

Diagrama de Implantação

Mostra a configuração dos nós de processamento em tempo de execução e os componentes deles.

Média

DIAGRAMAS DA UML 2.x

Diagrama Descrição Prioridade de aprendizagem

Diagrama de Comunicações

É outro diagrama de interação, mas com ênfase na organização estrutural dos objetos que enviam e recebem mensagens.

Baixa

Diagrama de Objetos

Mostra os objetos e suas relações em um dado momento; normalmente um caso especial de um diag. de classes ou de comunicação.

Baixa

Diagrama de Estruturas

Compostas (NOVO)

Praticamente idêntico ao diagrama de componentes, sendo diferente apenas por ser aplicável a qualquer classe.

Baixa

DIAGRAMAS DA UML 2.x

Diagrama Descrição Prioridade de aprendizagem

Diagrama de Pacote (NOVO)

Mostra como os elementos do modelo estão organizados em pacotes e as dependências entre tais pacotes.

Baixa

Diagrama de Temporização

(NOVO)

Mostra a mudança de estado ou condição de um objeto ao longo do tempo, em resposta a eventos externos. Seu uso é bastante específico.

Baixa

Diagrama de Visão Geral da Interação

(NOVO)

Híbrido de um diagrama de atividades e um diagrama de sequências. É de uso muito específico.

Baixa

DIAGRAMAS DA UML 2.x

UML

MODELO DE CASOS DE USO

(MATERIAL COMPLEMENTAR)

DESCRIÇÕES NARRATIVAS

Cada caso de uso é definido através da descriçãonarrativa das interações (cenários) que ocorrementre o(s) elemento(s) externo(s) e o sistema.

Mas há várias formas de descrever casos de uso.

FORMAS DE DESCREVERCASOS DE USO

Formato:

Contínua.

Numerada.

Tabela/numerada.

Detalhamento:

Sucinto.

Expandido.

Grau de abstração:

Essencial.

Real.

DESCRIÇÃO CONTÍNUA

Exemplo:

“O Cliente chega ao caixa eletrônico e insere seucartão. O Sistema requisita a senha do Cliente.Após o Cliente fornecer sua senha e esta servalidada, o Sistema exibe as opções deoperações possíveis. O Cliente opta por realizarum saque. Então o Sistema requisita o total aser sacado. O Cliente informa o valor desejado.O Sistema fornece a quantia e imprime umcomprovante de saque”.

DESCRIÇÃO NUMERADA

Exemplo:

1. Cliente insere seu cartão no caixa eletrônico.

2. Sistema apresenta solicitação de senha.

3. Cliente digita sua senha.

4. Sistema exibe menu de operaçõesdisponíveis.

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 comprovantede saque.

DESCRIÇÃO TABELA/NUMERADA

Cliente Sistema

1. Insere seu cartão no caixa eletrônico.

3. Digita sua senha.

5. Indica que deseja realizar um saque.

7. Informa o valor desejado.

2. Apresenta solicitação de senha.

4. Exibe menu de operações disponíveis.

6. Requisita quantia a ser sacada.

8. Fornece a quantia e um comprovante de saque.

DETALHAMENTO

O grau de detalhamento a ser utilizado nadescrição de um caso de uso pode variardependendo da fase em que se encontra odesenvolvimento do sistema.

Fase de Análise: um caso de uso sucintodescreve as interações sem muitos detalhes.

Fase de Projeto: um caso de uso expandidodescreve as interações em detalhes.

GRAU DE ABSTRAÇÃO

O grau de abstração de um caso de uso dizrespeito à existência ou não de menção àtecnologia a ser utilizada na descrição deste casode uso.

Um caso de uso essencial não faz menção àtecnologia a ser utilizada; normalmente utilizadona etapa de análise.

Um caso de uso real apresenta detalhes datecnologia a ser utilizada em sua implementação;normalmente utilizado na etapa de projeto.

GRAU DE ABSTRAÇÃO

Essencial:

1 - O Cliente se identifica para o sistema através dos seusdados.

2 - O sistema ao reconhecê-lo deve apresentar as opçõesde operações:

• 2.1 - Realizar saque

• 2.2 - Realizar pagamento

• 2.3 - Emitir extrato

3 - Escolhida uma das operações, o sistema a chamará.

GRAU DE ABSTRAÇÃO

Real:

1 - O cliente se identifica para o sistema através do seucartão magnético com chip.

2 - O sistema lê o cartão e apresenta as opções deoperações:

• 2.1 - Realizar saque

• 2.2 - Realizar pagamento

• 2.3 - Emitir extrato

3 - Escolhida uma das operações, através do teclado, osistema a chamará.

DOCUMENTAÇÃO DOSCASOS DE USO

A UML não define uma estruturação específica aser utilizada na descrição do formato expandido deum caso de uso.

A equipe de desenvolvimento deve utilizar oformato de descrição que lhe for realmente útil.

EXEMPLO DE DOCUMENTAÇÃO

EXEMPLO DE DOCUMENTAÇÃO

UML

MODELO DE CLASSES

(MATERIAL COMPLEMENTAR)

VISÕES INTERNA E EXTERNA DE UM SISTEMA O. O.

Externamente, os atores visualizam resultados decálculos, relatórios produzidos, confirmações derequisições realizadas, etc (diagrama de casosde uso mostra isso).

Internamente, os objetos colaboram uns com osoutros para produzir os resultados (isto odiagrama de casos de uso não mostra).

Essa colaboração pode ser vista sob o aspectodinâmico e sob o aspecto estrutural estático.

MODELO DE CLASSES

O diagrama da UML utilizado para representar osaspectos estáticos das colaborações entreobjetos é o diagrama de classes.

O modelo de classes evolui (é incrementado)durante o desenvolvimento do sistema.

IDENTIFICAÇÃO DAS CLASSES NECESSÁRIAS

Análise dos casos de uso:

Cada caso de uso é analisado para identificar classescandidatas.

Premissa: a partir da descrição textual doscasos de uso, podem-se derivar as classes:

A existência de uma classe em um sistema só se justificase ela participa de alguma forma para o comportamentoexternamente visível do sistema.

Vantagem: esta abordagem é bastante simples.

Desvantagem: depende de como os casos de uso foramescritos (as formas de expressar uma mesma ideia sãobastante numerosas).

IDENTIFICAÇÃO DAS CLASSES NECESSÁRIAS

CATEGORIAS DE RESPONSABILIDADES

Costuma-se categorizar os objetos de umsistema de acordo com o tipo deresponsabilidade atribuída:

Objetos de entidade.

Objetos de controle.

Objetos de fronteira.

OBJETOS DE ENTIDADE

Um objeto de entidade é um repositório paraalguma informação manipulada pelo sistema.

Esses objetos representam conceitos do domínio donegócio.

Normalmente esses objetos armazenaminformações persistentes.

Há várias instâncias de uma mesma classe deentidade coexistindo no sistema.

OBJETOS DE FRONTEIRA

Classes de fronteira realizam a comunicação dosistema com atores, sejam eles outros sistemas,equipamentos ou seres humanos.

Há três tipos principais de classes de fronteira:

As que se comunicam com usuários (atores humanos);

As que se comunicam com outros sistemas;

As que se comunicam com dispositivos atrelados aosistema.

OBJETOS DE CONTROLE

São a “ponte de comunicação” entre objetos defronteira e objetos de entidade.

Responsáveis por controlar a lógica de execuçãocorrespondente a um caso de uso.

Decidem o que o sistema deve fazer quando umevento externo relevante ocorre.

Realizam o controle do processamento.

Agem como coordenadores/controladores dos outrosobjetos para a realização de um ou mais casos de uso.

EXERCÍCIO 1

Utilizando a listagem de requisitos levantados, asespecificações dos casos de uso (nível ANÁLISE) e odiagrama de classes (nível ANÁLISE) do sistema queseu grupo está modelando:

Atualize as descrições dos casos de uso para o nível dePROJETO.

Construa o diagrama de classes em nível de PROJETO.

Envie a solução deste exercício pelo Moodle, em umúnico arquivo .pdf.

UML

DIAGRAMA DE OBJETOS

DIAGRAMA DE OBJETOS

Além do diagrama de classes, a UML define umsegundo tipo de diagrama estrutural: odiagrama de objetos.

Pode ser visto com uma instância de diagramasde classes.

Representa uma “fotografia” do sistema em umcerto instante.

Exibe as ligações formadas entre objetos conforme estesinteragem e os valores dos seus atributos.

DIAGRAMA DE OBJETOS

Exemplo 1:

DIAGRAMA DE OBJETOS

Exemplo 2:

EXERCÍCIO 2

A partir do diagrama de classes (nível ANÁLISE) dosistema que seu grupo está modelando:

Elabore um diagrama de objetos que exiba as ligaçõesformadas entre objetos conforme estes interajam para arealização de um dos casos de uso do sistema.

Junte este diagrama ao resultado do exercício 1.

UML

MAPEAMENTO OBJETO-RELACIONAL

INTRODUÇÃO

Quando se opta pela análise, pelo projeto e pelaimplementação de acordo com o paradigma OO,em tese o ideal seria optar também por um SGBDorientado a objetos.

Problema: os SGBDs OO ainda estão longe de conquistaro mercado, que em sua grande maioria continua utilizandoSGBDs relacionais.

Mesmo tendo um banco de dados (BD) relacional,podemos unir dados e comportamento em classes,isto através do mapeamento objeto-relacional.

A IMPORTÂNCIA DO OID

OID: Object Identification, ou seja, identificadorúnico de um objeto.

Para minimizar o impacto do desencontro objeto-relacional, temos que manter um paralelo emalguns aspectos aos BDs relacionais, a exemplodisso temos os OIDs.

Como nossos objetos serão salvos em um BDrelacional, devemos disponibilizar uma forma deencontrá-los.

MAPEAMENTO OBJETO-RELACIONAL

Pacotes, classes e atributos podem ser mapeadospara BDs relacionais (esquemas, tabelas, colunas),embora sejam de natureza diferente.

Mapeamento:

Modelo OO Banco Relacional

Classes Relações (tabelas)

Objetos Tuplas (registros, linhas)

Métodos Stored procedures

Atributos Campos (colunas)

MAPEAMENTO OBJETO-RELACIONAL

Geralmente, somente as classes concretas ecategorizadas como “classes de entidade” sãomapeadas para tabelas. Mapeamento:

MAPEAMENTO OBJETO-RELACIONAL

Os relacionamentos entre classes (associação,agregação simples, composição, generalização) sãomapeados para uma ou mais tabelas.

MAPEAMENTO DA HERANÇA

Existem 3 formas básicas para se implementar aherança, que é um conceito de orientação aobjetos, em um BD relacional.

Forma 1: uma tabela para toda hierarquia de classe – nessasituação, temos uma tabela que armazena os dados deprofessor e de aluno.

MAPEAMENTO DA HERANÇA

Forma 2: uma tabela por classe concreta da hierarquia.Nessa implementação, há dificuldade para a inserção denovos atributos comuns às classes da hierarquia. Ex: seformos inserir um novo atributo à classe-base Pessoa, p.ex. o atributo e-mail, deveremos lembrar que a coluna EMAILdeverá ser criada em ambas as tabelas (subclasses).

MAPEAMENTO DA HERANÇA

Forma 3: uma tabela por classe. Muitos afirmam que esta éa melhor forma de implementar herança, pois o BD ficanormalizado e se aproxima mais da realidade do modelo declasses. Porém, com essa implementação várias tabelas sãocriadas para representar a herança, e isso pode implicar emuma perda relativa de desempenho do BD.

MAPEAMENTO DE ATRIBUTOS

Ao transpor-se um objeto para uma tabela de BDrelacional, os atributos do mesmo são mapeadosem colunas da tabela. Este processo demapeamento deve levar em consideração fatorescomo a tipagem dos dados e o comprimentomáximo dos campos.

Em diversos casos, atributos de um objeto nãodevem ter obrigatoriamente uma coluna em umatabela que os referencie.

MAPEAMENTO DE ASSOCIAÇÕES

Os relacionamentos de associação entre objetossão uma das características mais facilmentemapeadas. Conceitualmente, existem apenas trêstipos de relacionamentos possíveis:

um-para-um;

um-para-muitos; e

muitos-para-muitos.

EXERCÍCIO 3

A partir do diagrama de classes (nível ANÁLISE) dosistema que seu grupo está modelando:

Faça o mapeamento objeto-relacional das classes deentidade para relações (tabelas) de um BD relacional.A construção de um DER neste exercício é opcional,sendo obrigatório apenas apresentar as tabelas e seusatributos (campos).

Junte a solução deste exercício aos resultados dosexercícios anteriores.

Envie o arquivo completo dos exercícios pelo Moodle, emum único arquivo .pdf.

BIBLIOGRAFIA UTILIZADA

BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: Guia do Usuário. 2 ed. Riode Janeiro: Campus, 2005.

LARMAN, C. Utilizando UML e Padrões: uma introdução à Análise e ao ProjetoOrientados a Objetos e ao Desenvolvimento Iterativo. 3 ed. Porto Alegre:Bookman, 2007.

MEDEIROS, E. S. Desenvolvendo Software com UML 2.0: Definitivo. SãoPaulo: Pearson Makron Books, 2005.

PRESSMAN, R. S. Engenharia de Software: uma abordagem profissional. 7ed. São Paulo: Artmed, 2011.

SOMMERVILLE, I. Engenharia de Software. 9 ed. São Paulo: Pearson, 2011.

WAZLAWICK, R. S. Análise e Projeto de Sistemas de Informação Orientadosa Objetos. Rio de Janeiro: Elsevier, 2004.