OOeUML

3/17/2011

1

Monitoramento de ProjetosMarcelo Castilho – Todos os direitos reservados

IPLANRIOMetodologia e Processo de Desenvolvimento de Software

Análise de Projeto Orientado a Objetos através do uso da UML

PDSIplan – 2011Março de 2011

Treinamento Interno


Apresentação Pessoal

1984 - Formado em Programação Cobol

1989 - Estagiário da IBM Brasil

1992 - Formado em Informática pela PUC-RJ

1994 - Líder de projeto na IBM Brasil

1996 - Pessoa jurídica na IBM Brasil - Y2K

1998 - Admitido como Analista de Sistemas na IPLANRIO

1999 - Coordenador de Informática - João Goulart

2000 - Mestrado em Gestão de TI pela UFRJ

2002 - Admitido como Professor na UGF

2004 - Curso de extensão na PUC – OO com UML

2004 - Implantação RUP / UML / JAVA na CGM

2005 - Gerente de Projetos – Implantação do Sistema SIG

2007 - Gerente de TI – CGM

2010 – Integrante do PDSIPLAN para certificação MPS-BR

36 sistemas implantados

(maioria ainda

em produção)

3/17/2011

2


Cap.1 – Processos de Desenvolvimento de Software

Da Análise Estruturada ao MPS.BR

A metodologia do Processo Unificado

Cap.2 – A Orientação à Objetos e a UML

Principais Diagramas

Estudos de Caso

Assuntos Abordados

Não serão tratados neste curso :

Linguagem Java, Framework,

Design Pattern, Itil, Cobit ...


Bibliografia

Analise Baseada em Objetos – Peter Coad e Edward Yourdon

Projeto Baseado em Objetos – Peter Coad e Edward Yourdon

UML Essencial - Martin Fowler

Princípios de Análise e Projeto de Sistemas com UML – Eduardo Bezerra

UML: Guia do Usuário – Jacobson , Booch e Rumbaugh

UML Reference Manual, 2nd Ed - Jacobson , Booch e Rumbaugh

Guia de Consulta Rápida UML 2

www.sei.cmu.edu

www.softex.br/mpsbr

3/17/2011

3


Agenda Sugerida

14/03/2011 – Cap. 1 (Completo) , Cap. 2 (UML e principais diagramas /

Levantamento de Requisitos / Apresentação Estudo de Caso n.1)

15/03/2011 – Cap. 2 (Resolução Estudo de Caso n.1 / Diagrama de Caso de

Uso / Apresentação e Resolução Estudo de Caso n.2)


Cap. 1 - Processos de Desenvolvimento de SW

Antes da Análise Estruturada...

Um breve resumo da Análise Estruturada

Engenharia de SW

Por que mudar ? Qual a nova proposta ?

CMMI - Avaliando a empresa em SW

MPS.BR – Melhoria de Processo de SW Brasileiro

PDSIplan – Processo de Desenvolvimento de Sistemas

Processo Unificado

3/17/2011

4


Antes da Análise Estruturada...

1970 - Preocupação com a economia de espaço em disco e utilização do processador

Surgimento de linguagens comerciais como o COBOL e preocupação em estruturar o código (acabar com GO TO)

Modelos utilizados : fluxograma, pseudocódigo, gabarito de espacejamento...


“Euquipe” ao invés de equipe

Repetição do código e arquivos duplicados

Pouca padronização e documentação

Manutenção excessiva

Pouca Flexibilidade

Não atendimento aos requisitos de negócio

Desenvolvimento de software na época

“Muita programação e nenhuma

modelagem”

3/17/2011

5


Final dos anos 70 – Chris Gane e Tom De Marco lançam os fundamentos

da Análise Estruturada e Especificação de Sistemas

Definido a metodologia e as ferramentas para desenvolvimento de

sistemas

Metodologia :

Análise Estruturada - Metodologia

Especificação

Projeto

Codificação

Validação

Manutenção

MER/DER,DD,DFD,Mini-especificações

DE,Definição Pgm,Modelo BD

Programação

Modelo Cascata

Homol.


Análise Estruturada - Especificação

Reuniões

com usuários

Dicionário de Dados

Estoque = @cd_produto int código do produto

qt_produto int quant disponível

vl_atual val valor atual

3/17/2011

6


Análise Estruturada - Projeto

Análise de

transformação

Projeto

Físico

Modelo Físico Banco de Dados

Clienteid_cliente: Integer

nr_CPF: Long Integer

nm_cliente: Text(20)

nr_telefone: Long Integer

Produtoid_produto: Integer

ds_produto: Text(18)

tp_produto: Text(2)

Cliente_Produtoid_cliente: Integer

id_produto: Integer

qt_comprada: Long Integer

vl_preco_compra: Currency


Análise Estruturada - Problemas

Como são analisados separadamente nas fases de

Especificação e de Projeto, ocorre um abismo entre o

mapeamento dos dados e o detalhamento das funções,

gerando projetos não integrados

Levantamento

Equipe

MER

Ou

Fase

Análise

Equipe

DFD

Ou

Fase

Projeto

Equipe Programação

Quem eu

sigo ?

3/17/2011

7



Vários consultores lançaram suas próprias notações*, dificultando a

transferência de tecnologia e aprendizado

Por pressão de cronograma, fases de análise são negligenciadas gerando

alta manutenção

3 515

3

7 0

0

2 0

4 0

6 0

8 0

Especificação

Projeto

Codificação

Validação

Manutenção

Ciclo Tradicional de Desenvolvimento

% tempo utilizado por fase



Na prática, os projetos ao iniciar a fase de programação, não revisam as fases

anteriores, ficando documentação desatualizada e não atendendo aos requisitos

do projeto

Marcelo Castilho - Todos os direitos reservados

Entregue,

mas nunca

usado

satisfatoriamente

47%

Usado, mas

bastante

alterado ou

em seguida

abandonado

19%

Pago mas

não entregue

29%

Usado depois de

alterações 3% Usado tal como

entregue

2%

Fonte: US Government Accounting Office

Estudo com

projetos de

software do

Governo

Americano

3/17/2011

8


Engenharia de Software

Estudo e aplicação de procedimentos sistemáticos, disciplinados e quantificáveis ao desenvolvimento, operação e manutenção de software

Desenvolver software não é somente modelar e escrever código. É criar aplicações que resolvam os problemas dos usuários. É fazer isto dentro do prazo, de forma precisa e com alta qualidade

Mas...pesquisas realizadas no ano de 1995 estimaram que, mesmo com a adoção da metodologia de desenvolvimento “Em Cascata” e o uso do método da “Análise Estruturada”, $81 bilhões foram gastos em projetos fracassados de TI e 53% custaram até 200% acima da estimativa inicial.

E agora ?


Estratégia para mudança deste cenário

A partir de 1995, as grandes empresas de TI se reúnem e buscam novas metodologias e linguagens de desenvolvimento de sistemas, visando

aumento na qualidade, amparado por métricas de avaliação de complexidade

CMMI

UML

Processo Unificado

Pontos de Função

Orientaçãoa Objetos

3/17/2011

9


Qualidade no desenvolvimento de Software

Conformidade aos requisitos funcionais e de desempenho explicitamente

estabelecidos, aos padrões de desenvolvimento explicitamente

documentados, e às características implícitas que são esperadas em todo

software desenvolvido profissionalmente

No desenvolvimento de software, a qualidade do produto está diretamente

relacionada à qualidade do processo de desenvolvimento, desta forma, é

comum que a busca por um software de maior qualidade passe

necessariamente por uma melhoria no processo de desenvolvimento.

O principal objetivo é garantir um produto final que satisfaça às

expectativas do cliente, dentro daquilo que foi acordado inicialmente.

Surge uma “chancela” perseguida pelas empresas, denominada GQS(

Garantia da Qualidade de Software), área-chave de processo do CMMI


CMMI - Definições

O CMMI (Capability Maturity Model Integration) é um modelo de

referência que contém práticas (Genéricas ou Específicas) necessárias à

maturidade em disciplinas específicas (Systems Engineering (SE), Software

Engineering (SW), Supplier Sourcing (SS))

Desenvolvido pelo SEI (Software Engineering Institute), o CMMI é uma

evolução do CMM e procura estabelecer um modelo único para o processo

de melhoria corporativo, integrando diferentes modelos e disciplinas, com

objetivo de melhorar a gerência, desenvolvimento e manutenção de software

Disponibiliza uma seqüência pré-determinada para melhoria baseada em

estágios que não deve ser desconsiderada, pois cada estágio serve de base

para o próximo. É caracterizado por Níveis de Maturidade (Maturity Levels):

Nível 1: Inicial (Ad-hoc)

Nível 2: Gerenciado

Nível 3: Definido

Nível 4: Gerenciado Quantitativamente

Nível 5: Otimizado

3/17/2011

10


CMMI – Níveis de Maturidade (resumo)


CMMI - Avaliação

A empresa ou setor é avaliado para verificar em qual nível de maturidade

se encontra, e só aumenta seu nível quando um conjunto de objetivos é

alcançado

Em resumo, os extremos :

Organização Imatura - o processo de software é improvisado. Mesmo

que o processo seja especificado, ele é ignorado. Não existe trabalho

em equipe e o sucesso depende do esforço e conhecimento individual

Organização Madura - possui capacidade organizada para gerenciar

a construção e a manutenção de software, em processo continuo de

evolução e otimização

Em qual nível a

minha TI se

encontra ?

3/17/2011

11


CMMI - Referências

No Brasil, as seguintes empresas conseguiram realizar a certificação até o final,

ou seja, alcançaram o nível 5 do CMMI (por ano da certificação):

2004 - TCS (TATA Consultancy Services) Brazil

2005 - IBM Brazil / EDS - Electronic Data Systems / Stefanini IT Solutions

2007 - Ci&T / CPM Braxis

2009 - Instituto Atlântico / BRQ IT Services

O custo desta certificação para uma empresa pode ser de até US$ 400 mil, o

que se torna inviável para empresas de micro, pequeno e médio porte. Então,

em uma parceria entre a Softex, Governo e Universidades, surgiu o projeto

MPS.Br (melhoria de processo de software brasileiro), que é a solução

brasileira compatível com o modelo CMMI, está em conformidade com as

normas ISO/IEC 12207 e 15504, além de ser adequado à realidade brasileira..


MPS.BR - Definição

O MPS.BR ou Melhoria de Processos do Software Brasileiro é

simultaneamente um movimento para a melhoria da qualidade (Programa

MPS.BR) e um modelo de qualidade de processo (Modelo MPS) voltada para a

realidade do mercado de pequenas e médias empresas de desenvolvimento de

software no Brasil.

A escala dos 7 níveis do MPS.BR pode ser expressa da seguinte forma:

G – Parcialmente Gerenciado

F – Gerenciado

E – Parcialmente Definido

D – Largamente Definido

C – Definido

B – Gerenciado Quantitativamente

A – Em Otimização

O MPS.BR é declaradamente inspirado no CMMI.

http://www.softex.br/mpsbr/_home/default.asp


3/17/2011

12


MPS.BR – Comparação com CMMI


• Existem empresas que não estão objetivando o mercado internacional.

• Compatibilidade plena com o CMMI e com a norma ISO/IEC 15504, ou

seja, uma certificação em MPS.BR, garante que a empresa está cumprido

plenamente o modelo proposto pelas outras duas entidades.

• Criado para a realidade brasileira, onde a maioria das empresas que

desenvolvem software são micro, pequenas ou médias.

• Propõe a divisão da certificação em mais níveis, com custos mais baixos

e a possibilidade de se criar grupos de empresas para se certificarem.

• A divisão em mais níveis permite uma implementação mais gradual.

.

Por que usar MPS.BR ao invés do CMMI



3/17/2011

13


No Brasil, as seguintes empresas conseguiram realizar a certificação

até o final, ou seja, alcançaram o nível A do MPS.BR :

CPM BRAXIS/UNITECH – BA (válido até: 08.abr.11)

POLITEC – DF (válido até: 27.mai.12)

STEFANINI – SP (válido até: 29.set.12)

MPS.BR – Empresas Certificadas


PDSIplan – Definição / Objetivos

PDSIplan – Processo de Desenvolvimento de Sistemas da Empresa

Municipal de Informática do RJ

Objetivos :

Padronizar o processo de desenvolvimento de software na PCRJ através

da utilização das melhores práticas do mercado

Certificar a empresa no MPS.BR

Disseminar conhecimentos técnicos para os analistas e programadores

da empresa

Melhorar a qualidade dos produtos desenvolvidos, no que se refere

ao atendimento as especificações funcionais e técnicas, em conformidade

com os padrões estabelecidos e dentro do prazo acordado

3/17/2011

14


Modelos de Desenvolvimento

Um processo de desenvolvimento de software é um conjunto de passosordenados que devem ser seguidos para atingir um determinado objetivo

O modelo Cascata (ou clássico) está sendo substituído pelo modeloEspiral, principalmente pela diminuição dos riscos (de requisitos,tecnológicos, habilidades, políticos)

O Processo Unificado (UP) de desenvolvimento de software é oconjunto de atividades necessárias para transformar requisitos do usuárioem um sistema de software.

O UP de desenvolvimento de sistemas combina os ciclos iterativo eincremental para a construção de softwares. É fundamental na visão deque o avanço de um projeto deve estar baseado na construção deartefatos de software, e não apenas em documentação.

O Processo Unificado utiliza a Linguagem de Modelagem Unificada

(Unified Modeling Language – UML) no preparo de todos os artefatos do

sistema


Processo Unificado

Rational Unified Process® ou RUP® - Um exemplo de ProcessoUnificado que implementa modelo Espiral

O RUP é desenhado e documentado através dos diagramas dalinguagem UML

3/17/2011

15


Modelo Espiral

Ciclos de desenvolvimento com Fases entrelaçadas

Especificação evolui junto com o sistema reduzindo riscos no projeto

Permite maior interação com o usuário

Suporta requisitos parcialmente definidos, adaptável a mudanças

Acúmulo de experiência e nivelamento da equipe

Um ciclo da espiral deve produzir uma versão

do software ou protótipo executável


Modelo Espiral x Modelo Cascata

Modelo Cascata Modelo Espiral

Início Elaboração Construção Transição

3/17/2011

16


Modelo Espiral – Exemplo de um Cronograma

Sistema CGM / SDP (Sistema Descentralizado de Pagamento)


Cap. 2 - A Orientação à Objetos e a UML

A UML e as visões de seus Diagramas

Levantamento de Requisitos *

Diagrama de Caso de Uso *

Diagrama de Pacotes *

Diagrama de Classes * (Princípios da Orientação à Objetos)

Diagrama de Objetos

Transposição para o MER (BD) *

Diagramas Opcionais :

Diagrama de Máquina de Estados (Atualizado na versão 2.0)

Diagrama de Seqüência *

* com estudo de caso

3/17/2011

17


UML - Definições

Linguagem gráfica para visualização, especificação, construção edocumentação de sistemas

UML versão 1.0, formulado pelo consultores Booch, Rumbaugh eJacobson, foi adotado pela OMG (Object Management Group) em 1997,como a linguagem de modelagem para desenvolvimento de softwares pelaindústria de TI

Atualmente na versão 2.2, a UML é a Notação padrão paradesenvolvedores de software

A UML é uma linguagem, não é um método. Representa um sistemaatravés de diagramas, onde cada um se refere a uma visão parcial doproblema:

Comportamento Externo Caso de Uso

Comportamento Interno Classe e Objetos / Pacotes

Estruturais Seqüência / Colaboração / Estados

Implementação (Arquitetura) Componentes / Distribuição


UML – Recomendações

A boa prática da UML recomenda que não existe um conjunto certo

de diagramas, logo deve-se :

Modelar apenas o necessário (apenas diagramas úteis para oprojeto atual)

Não duplicar informações

Utilizar na maneira correta a elaboração dos documentos - Criar omínimo necessário

E lembrem-se :

Que a modelagem tem uma seqüência para construçãodos artefatos e assim obter detalhes de maneira correta. Modelarsimplesmente para cumprir os “Entregáveis” deve ser evitado. Modelossão difíceis de se manter, se o modelo esta muito “Profundo” a tendênciaé que fique mais defasado com o código.

3/17/2011

18


Levantamento de Requisitos – A importância

“Entender aquilo que o cliente deseja ou o que o cliente acredita queprecisa e as regras do negócio ou processos do negócio. Isso é o cerneque move essa importante função que faz parte da engenharia derequisitos”

Segundo Miranda (2002 apud SANTOS, 2007, p.12) :

50% dos principais problemas/defeitos de software são oriundos da

fase de especificação de requisitos;

12% das principais causas de fracassos em projetos são oriundos

de requisitos incompletos;

12% das principais causas de sucessos em projetos são oriundos de

requisitos consistentes.


Levantamento de Requisitos - Definições

A entrevista como pedra fundamental : Preparação (questionário) epostura profissional

Análise de Requisitos do Sistema (visão do usuário)

Definição dos atores

“Quem interage com sistema”

Definição da lista de eventos

“O que cada ator precisa fazer”

“O que o sistema deve contemplar”

3/17/2011

19


Levantamento de Requisitos - Tipos

Em todos os tipos de especificação há 2 tipos de requisitos a considerar:

Requisitos funcionais: descrevem as funcionalidades que se espera que osistema disponibilize, de uma forma completa e consistente. É aquilo que ousuário espera que o sistema ofereça, atendendo aos propósitos para qual osistema será desenvolvido.

Requisitos não-funcionais:referem-se a aspectos não-funcionais do sistema,como restrições nas quais o sistema deve operar ou propriedades emergentesdo sistema. Costumam ser divididos em Requisitos não-funcionais de:Utilidade, Confiança, Desempenho, Suporte e Escalabilidade.

Importante : As especificações devem refletir O QUE e não COMO o

requisito deve ser satisfeito. O requisito não deve refletir o projeto,

implementação ou descrever uma operação. Requisitos de Interface são

exceções.


Levantamento de Requisitos - Exemplo

Requisitos funcionais

RF 1 – Cadastrar Assinante

Descrição: O sistema deve permitir o cadastro de um novo assinante,

está interface deve estar disponível aos visitantes.

Entrada: O usuário deverá entrar com os seguintes campos: nome, data

de nascimento, apelido, sexo, email, senha, foto e cep.

Processamento: O sistema deve verificar se já existe algum registro com

o email informado, caso não exista grava no banco de dados e envia um

email de confirmação para o endereço informado, o cliente irá confirmar

seu cadastro clicando em um link que estará no email de confirmação

enviado pelo sistema, após isso o cadastro será liberado, caso já exista

um registro com o email informado, o SDE exibe mensagem de erro.

Saída: Mensagem de confirmação de cadastrado com envio de email ou

Mensagem de erro

3/17/2011

20


1º Estudo de Caso - Levantamento de Requisitos

-

Locadora ClockBuster

1. Faça a leitura dos requisitos iniciais

2. Liste os eventos e os atores envolvidos


Caso de Uso – Definições

Após definidos o plano de projeto, os atores e a lista de eventos,

atribuímos os eventos à casos de uso

Diagrama de casos de uso é o mais informal da UML (visão do usuário) e é

amplamente utilizado nas fases de levantamento e análise de requisitos

Trata-se de um conjunto de cenários - seqüência de ações que um ator

executa com um propósito específico, que na prática se traduz na interação

entre o usuário e o sistema

Para cada caso de uso deve-se descrever o fluxo(cenário) típico (nada

ocorre de errado) e os alternativos

3/17/2011

21


Caso de Uso – Objetivos Principais

Delimitação do contexto de um sistema

Documentação e o entendimento dos requisitos

Descreve os requisitos funcionais

Principal saída da etapa de especificação de requisitos

Facilita a comunicação entre os “stakeholders”

É base para a definição do cronograma

Auxilia a elaboração dos casos de teste

Auxilia nas estimativas


Caso de Uso – Diagramação

CASO DE USO_1

ATOR_1

CASO DE USO_1

ATOR_2

CASO DE USO_3

CASO DE USO_2ATOR_3

Fronteira da Aplicação

3/17/2011

22


Caso de Uso – Descrição

Caso de Uso : Cadastrar Servidor

Descrição : Cadastrar dados dos Servidores, da PCRJ, que farão parte do SDP, e serão nomeados como Secretário, Ordenador e Gestores, além dos Técnicos que serão designados para operar o Sistema.

Ator(es) : GSCA/CRE

Fluxo Típico

1.Sistema requisita a matrícula, nome, endereço, tel. comercial, tel. celular, e-mail de contato do Servidor para a GSCA/CRE. 2.Gerência informa os dados do Servidor para o Sistema 3.Sistema armazena os dados e informa que a operação foi efetuada com sucesso.

Fluxos Alternativos - Caso o Servidor já se encontre cadastrado.

1.Sistema retorna que o Servidor já está cadastrado


Caso de Uso – Descrição (Exemplo)

Caso de Uso : Realizar Saque no Caixa Automático

Ator(es): Cliente

Fluxo Típico :

1. Sistema realiza leitura do cartão magnético.

2. Cliente informa sua senha.

3. Sistema valida senha, verificando se está associada ao cliente.

4. Cliente informa o valor desejado para saque.

5. Sistema verifica se o cliente tem saldo suficiente.

6. Sistema inicia a contagem de cédulas.

7. Sistema debita o valor do saque da conta corrente.

8. Sistema libera o dinheiro para o cliente.

Fluxo Alternativo : 5a – saldo insuficiente

1. Sistema informa “Saldo insuficiente para o saque desejado”

2. Encerra caso de uso

3/17/2011

23


Caso de Uso – Descrição (Padrão Proposto)

Caso de Uso: Descrição Geral:

Atores:

Início:

Fluxo Típico N

o Ação

1

2

3

4

5

6

Fluxos Alternativos Alternativa 1:

No Ação


Caso de Uso – Associação <<Include>>

Associação entre Casos de Uso

Inclusão – Quando há uma parte do comportamento que é semelhante em

mais de um caso de uso. Esta alternativa reduz redundância no projeto.

Ex:

Cadastrar

novo

funcionário

Tranferir

funcionário

Gerar

novo

crachá

<<inclui>>

<<inclui>>

uses ou

include

3/17/2011

24


Caso de Uso – Associação <<Extend>>

Extensão – Estende as funcionalidades de um caso de uso através da

associação com outro caso de uso. Pode ser usado para representar novos

casos ou como suplemento de um caso.

Ex:

Cliente

Efetuar

Pedidos

Cadastrar

Cliente

<<estende>>

extend


Caso de Uso – Generalização

Generalização de Ator – Quando um ator herda o papel de outro ator

para determinados casos de uso

Generalização de Caso de Uso – Quando existe uma especialização do

caso de uso

Cliente

Alugar

DVDAlugar

ProdutoAtendente

Alugar

VHS"Comentário"

Genérico

3/17/2011

25


Caso de Uso – Sugestão de Metodologia

Prioridade no atendimento, dentre os tipos de casos de uso :

1º – Tratar os casos de uso fundamentais, relacionados aos

requisitos de negócio

2º – Tratar os casos de uso custodiais, ou triviais, relacionados a

memória dos dados, como atualizar cliente, excluir veículo

3º – Tratar os casos de uso tecnológicos, como imprimir fatura,

enviar email


2º Estudo de Caso – Diagrama de Casos de Uso


1. Desenvolva o Diagrama de Casos de Uso

2. Faça a descrição dos casos de uso :

cadastrar produto e alugar produto

3/17/2011

26


Definição dos Módulos – Diagrama de Pacotes

Diagrama de Pacotes – Divisão dos casos de uso em pacotes, definindo

os ciclos de construção da aplicação

Incremento 1

Incremento 2 Incremento 3

Casos de Uso

Casos de Uso

Casos de Uso


3º Estudo de Caso - Diagrama de Pacotes


1. Desenvolva o Diagrama de Pacotes do Sistema,

identificando os módulos e os casos de uso que

serão entregues em cada versão

3/17/2011

27


Diagrama de Classes - Definições

Descreve os tipos de objetos no sistema e os vários tipos derelacionamento estático que existem entre eles

Representação das abstrações importantes do sistema (classes)

e de suas relações:

Associações – Relação de utilização

Agregação – Relação de constituição

Generalização – Relação de especialização

Classe, Objeto, Abstração,

Associação,.. preciso dos

princípios de Orientação à

Objetos.....


Orientação a Objetos – Conceitos Essenciais (1)

Classe - representa um conjunto de objetos com características

afins. Uma classe define o comportamento dos objetos através de seus

métodos, e quais estados ele é capaz de manter através de seus

atributos.

Exemplo de classe: Os seres humanos

Subclasse é uma nova classe que herda características de

sua(s) classe(s) pai

Exemplo de subclasse: humanos do sexo masculino

Abstração - habilidade de concentrar nos aspectos essenciais de

um contexto qualquer, ignorando características menos importantes ou

acidentais. Em modelagem orientada a objetos, uma classe é uma

abstração de entidades existentes no domínio do sistema de software

Objeto/instância de uma classe - um objeto é capaz de armazenar

estados através de seus atributos e reagir a mensagens enviadas a

ele, assim como se relacionar e enviar mensagens a outros objetos.

Exemplo de objetos da classe Humanos: João, José, Maria

H:/BIBLIOTECAS/Documents/ARQUIVOS MARCELO/00_Curso Iplan_OO.pptx

3/17/2011

28



Atributo - características de um objeto. Basicamente a estrutura de

dados que vai representar a classe.

Exemplos:

Funcionário: nome, endereço, telefone, CPF,...;

Carro: nome, marca, ano, cor, …;

Livro: autor, editora, ano.

Método - define uma comportamento(habilidade) do objeto.

Exemplo: Métodos deLatir, deDeitar do objeto “Rexx” que é uma

instância da classe Cachorro

Herança (ou generalização) - é o mecanismo pelo qual uma classe

(sub-classe) pode estender outra classe (super-classe), aproveitando

seus comportamentos (métodos) e variáveis possíveis (atributos).

Exemplo: Mamífero é super-classe de Humano. Ou seja, um

Humano é um mamífero.

Herança múltipla quando uma sub-classe possui mais de uma

super-classe.



Associação – para agrupar certas coisas que acontecem em algum

ponto no tempo ou sob circunstâncias similares. Pode ser uma

associação simples "usa um" ou de um acoplamento "parte de".

Exemplo: Um veiculo e um proprietário

Encapsulamento - consiste na separação de aspectos internos e

externos de um objeto. Este mecanismo é utilizado amplamente para

impedir o acesso direto ao estado de um objeto (seus atributos),

disponibilizando externamente apenas os métodos que alteram estes

estados. Exemplo: você não precisa conhecer os detalhes dos circuitos

de um telefone para utilizá-lo. A carcaça do telefone encapsula esses

detalhes, provendo a você uma interface mais amigável (os botões, o

monofone e os sinais de tom)

3/17/2011

29


Diagrama de Classes – Objetivos Principais

Complementar as descrições dos casos de uso

Encontrar classes de análise

Distribuir comportamento entre as classes de análise

Descrever responsabilidades

Descrever atributos

Estabelecer associações entre classes de análise


Diagrama de Classes – - Representação

Para cada classe devemos descrever seus atributos e operações

nome da classe

atributos

operaçõesDescrevem o

comportamento

da classe; os

serviços

disponíveis

Valores em

comum que

caracterizam

os objetos da

classe

Funcionário

nr_matricula

nm_nome

dt_nascimento

cd_estado_civil

cd_sexo

nr_cpf

nr_identidade

nm_filiacaomae

nm_filiacaopai

nm_nacionalidade

nm_naturalidade

CadastrarFuncionário()

ExcluirFuncionário()

exemplo

3/17/2011

30


Relações entre Classes - Associação

Representa o relacionamento entre classes

• ex: cliente possui contratos

Multiplicidade

Numero de objetos de uma

classe relacionados com um

único objeto de outra

nrContrato

dtContrato

vlContrato

Cliente

nmCliente

cpfCliente

endereço

dtNascim

/idade

Contrato

0..*

1

Associação

realiza

Papel (opcional)

recomendável principalmente

numa associação reflexiva

engloba

0..*

1

Associação

reflexiva

Derivado


Relações entre Classes - Agregação

Representa uma associação “todo-parte” e qualquer uma das

“partes” pode estar contido em outros “todos”

Time Jogador

11..221..*

é composto de

Notação para agregação

3/17/2011

31


Relações entre Classes - Composição

Representa uma associação “todo-parte”, mas qualquer das

“partes” tem um e somente um “todo”

Mesa

Tampo Perna

1 4

NotaFiscal ItemNF

*1

contem

Notação para composição

“Quando a composição é destruída, seus componentes também são”


Relações entre Classes - Generalização

Quando há necessidade de especializar, onde a subclasse contém mais

informações que o genérico (superclasse ou supertipo), mas são totalmente

relacionados

Pessoa

Enfermeiro

Doutor

Anestesista

Cirurgião

Clinico geral

Subclasses herdam atributos, operações e relações da superclasse

3/17/2011

32


Diagrama de Classes - Associação entre Classes

Classe que surge em virtude de uma associação entre outras classes,

para se especificar objetos que são dependentes do relacionamento

entre essas classes

Permite que se especifique atributos e operações específicas desta

relação

Ex: Pessoa é empregada numa empresa

1

Pessoa Emprego Empresa

1..*1..* 1periodoAlocado cpf cnpj

1º Caso : Associação promovida à Classe Plena

Neste caso pode haver várias instâncias entre as classes associadas


Diagrama de Classes - Classe de Associação

2º Caso : Classe de Associação

Classe de

Associação

1..*trabalha para ProjetoPessoa *

cpf identificador

Contrato

remuneração Só pode haver uma

instância entre as classes

associadas

Neste caso só pode haver uma instância entre as classes associadas

3/17/2011

33


Diagrama de Classes – a partir dos Casos de Uso

Faça uma análise gramatical das descrições dos casos de uso,

procurando identificar :

Substantivos – identifica classes

Verbos – indica operações ou associações

Indicação de posse – indica atributos de uma classe ou a

presença de agregação

Ex : Cliente, previamente cadastrado, aluga um veiculo disponível no

sistema, que através do GPS instalado registra as cidades

percorridas, para eventual cobrança de multa

o Classes : Cliente, Veiculo, Cidade, Multa

o Associação : Aluguel (será promovida a classe plena ?)

o Agregação : Multas pertencem ao Veículo, ao Cliente ou

a associação entre Cliente e Veiculo através do Aluguel ?


Diagrama de Objetos

Complementar ao Diagrama de Classes, sendo bastante dependente

deste, o Diagrama de Objetos fornece uma visão dos valores armazenados

pelos objetos de um Diagrama de Classes em um determinado momento da

execução de um processo. Exemplo :

3/17/2011

34


4º Estudo de Caso - Diagrama de Classes


1. Através da leitura dos Casos de Uso e Análise de

Requisitos identifique as classes candidatas e

seus atributos

2. Desenvolva o Diagrama de Classes


Obtendo o MER a partir do Diagrama de Classes

10 Regras para a Transposição do Diagrama de Classes para o

Modelo de Entidades e Relacionamentos :

1º RC – procurar utilizar uma ferramenta case (erwin, powerdesign, visio,...)

2º RC – em geral toda classe, classe de associação e ligação torna-se uma

tabela

3º RC – todos os atributos são aproveitados e deve-se criar chaves

primárias – Identificadores (extra-negócio)

4º RC – associação 1_1 transpõe a chave primária da classe “mais forte”

para “mais fraca” que não precisa criar nova chave

5º RC – classe de associação deriva em tabela sem Id próprio e as chaves

estrangeiras compõem a chave desta tabela

3/17/2011

35


Obtendo o MER a partir do Diagrama de Classes

10 Regras para a Transposição do Diagrama de Classes para o

Modelo de Entidades e Relacionamentos (Continuação) :

6º RC – associação 1__* transpõe a chave primária da classe(1) para a

classe(*) sem compor a chave da tabela

7º RC – tanto a superclasse como a subclasse derivam em tabelas, sendo

que a sub, herda a chave da super sem compor a chave

8º RC – nos casos de agregação ou composição, a chave da classe “Todo”

é transposta para a classe “Parte” e compõe a chave da tabela criada

9º RC – normalize o modelo

10º RC – Adicione as tabelas extra-negócio, necessárias para manter o

histórico das operações (trilha de auditoria) e o controle de acesso ao sistema


5º Estudo de Caso – Modelo Relacional


A partir do Diagrama de Classes crie o Esquema ou

Modelo relacional a ser implementado .

Ex: Para a classe produto o esquema será:

produto(idproduto,codigo,descricao,idcategoria)

OOeUML

Documents

Transcript of OOeUML