OOe UML

3/17/2011
Treinamento Interno
IPLANRIO
Metodologia e Processo de
Desenvolvimento de Software
Análise de Projeto Orientado a

Objetos através do uso da UML
PDSIplan – 2011
Março de 2011
Monitoramento de Projetos Marcelo Castilho – Todos os direitos reservados
Apresentação Pessoal
 1984 - Formado em Programação Cobol

36 sistemas implantados
 1989 - Estagiário da IBM Brasil
(maioria ainda
 1992 - Formado em Informática pela PUC-RJ em produção)
 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
1
3/17/2011
Assuntos Abordados
 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
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
2
3/17/2011
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
3/17/2011
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...
Desenvolvimento de software na época
 “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
“Muita programação e nenhuma

modelagem”
4
3/17/2011
Análise Estruturada - Metodologia
 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 :
Especificação MER/DER,DD,DFD,Mini-especificações
Projeto DE,Definição Pgm,Modelo BD
Codificação Programação
Validação Homol.
Manutenção
Modelo Cascata
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
5
3/17/2011
Análise Estruturada - Projeto
Análise de
transformação
Cliente Cliente_Produto
id_cliente: Integer id_cliente: Integer
id_produto: Integer
nr_CPF: Long Integer
Projeto nm_cliente: Text(20) qt_comprada: Long Integer
Físico nr_telefone: Long Integer vl_preco_compra: Currency
Produto
Modelo Físico id_produto: Integer
Banco de Dados ds_produto: Text(18)
tp_produto: Text(2)
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
Equipe Equipe
MER DFD
Levantamento
Ou Ou
Fase Fase
Análise Projeto
Quem eu
sigo ?
Equipe Programação
6
3/17/2011
 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
Ciclo Tradicional de Desenvolvimento

% tempo utilizado por fase
70 Especificação
80 Projeto
60 Codificação
40 Validação
15
3 5
20 3 Manutenção
0
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
Usado depois de Usado tal como

alterações 3% entregue
Estudo com
2%
projetos de Usado, mas
software do bastante
Governo alterado ou Entregue,
Americano em seguida mas nunca
abandonado usado
19% satisfatoriamente
47%
Pago mas
não entregue
29% Fonte: US Government Accounting Office
Marcelo Castilho - Todos os direitos reservados
7
3/17/2011
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
UML
Processo
Orientação
a Objetos CMMI Unificado
Pontos de
Função
8
3/17/2011
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
9
3/17/2011
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 ?
10
3/17/2011
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.
11
3/17/2011
MPS.BR – Comparação com CMMI
Por que usar MPS.BR ao invés do 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.

.
12
3/17/2011
MPS.BR – Empresas Certificadas
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)
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
13
3/17/2011
Modelos de Desenvolvimento
 Um processo de desenvolvimento de software é um conjunto de passos

ordenados que devem ser seguidos para atingir um determinado objetivo
 O modelo Cascata (ou clássico) está sendo substituído pelo modelo
Espiral, principalmente pela diminuição dos riscos (de requisitos,
tecnológicos, habilidades, políticos)
 O Processo Unificado (UP) de desenvolvimento de software é o

conjunto de atividades necessárias para transformar requisitos do usuário
em um sistema de software.
 O UP de desenvolvimento de sistemas combina os ciclos iterativo e

incremental para a construção de softwares. É fundamental na visão de
que o avanço de um projeto deve estar baseado na construção de
artefatos 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 Processo

Unificado que implementa modelo Espiral
 O RUP é desenhado e documentado através dos diagramas da

linguagem UML
14
3/17/2011
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
15
3/17/2011
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
16
3/17/2011
UML - Definições
 Linguagem gráfica para visualização, especificação, construção e

documentação de sistemas
 UML versão 1.0, formulado pelo consultores Booch, Rumbaugh e
Jacobson, foi adotado pela OMG (Object Management Group) em 1997,
como a linguagem de modelagem para desenvolvimento de softwares pela
indústria de TI
 Atualmente na versão 2.2, a UML é a Notação padrão para

desenvolvedores de software
 A UML é uma linguagem, não é um método. Representa um sistema

através de diagramas, onde cada um se refere a uma visão parcial do
problema:
 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 o

projeto atual)
 Não duplicar informações
 Utilizar na maneira correta a elaboração dos documentos - Criar o

mínimo necessário
E lembrem-se :
Que a modelagem tem uma seqüência para construção

dos artefatos e assim obter detalhes de maneira correta. Modelar
simplesmente para cumprir os “Entregáveis” deve ser evitado. Modelos
são difíceis de se manter, se o modelo esta muito “Profundo” a tendência
é que fique mais defasado com o código.
17
3/17/2011
Levantamento de Requisitos – A importância
 “Entender aquilo que o cliente deseja ou o que o cliente acredita que

precisa e as regras do negócio ou processos do negócio. Isso é o cerne
que move essa importante função que faz parte da engenharia de
requisitos”
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) e

postura 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”
18
3/17/2011
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 o

sistema disponibilize, de uma forma completa e consistente. É aquilo que o
usuário espera que o sistema ofereça, atendendo aos propósitos para qual o
sistema 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 emergentes
do 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
19
3/17/2011
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
20
3/17/2011
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
Fronteira da Aplicação
CASO DE USO_1
ATOR_1
CASO DE USO_2
ATOR_3
ATOR_2
CASO DE USO_3
21
3/17/2011
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
22
3/17/2011
Caso de Uso – Descrição (Padrão Proposto)
Caso de Uso:
Descrição Geral:
Atores:
Início:
Fluxo Típico
o
N Ação
1
2
3
4
5
6
Fluxos Alternativos
Alternativa 1:
o
N 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:
uses ou
Cadastrar include
novo <<inclui>>
funcionário
Gerar
novo
crachá
Tranferir
funcionário <<inclui>>
23
3/17/2011
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:
extend
<<estende>>
Efetuar Cadastrar
Pedidos Cliente
Cliente
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
Genérico
Alugar
DVD
Alugar
Atendente Produto
Alugar
"Come ntário"
VHS
Cliente
24
3/17/2011
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
25
3/17/2011
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
Casos de
Uso
Incremento 2 Incremento 3
Casos de Casos de
Uso 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
26
3/17/2011
Diagrama de Classes - Definições
Descreve os tipos de objetos no sistema e os vários tipos de

relacionamento 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
27
3/17/2011
 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)
28
3/17/2011
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
Funcionário
nome da classe nr_matricula
Valores em nm_nome
comum que dt_nascimento
caracterizam cd_estado_civil
os objetos da atributos exemplo cd_sexo
nr_cpf
classe
nr_identidade
nm_filiacaomae
Descrevem o nm_filiacaopai
comportamento operações
nm_nacionalidade
da classe; os nm_naturalidade
serviços
disponíveis CadastrarFuncionário()
ExcluirFuncionário()
29
3/17/2011
Relações entre Classes - Associação
 Representa o relacionamento entre classes

• ex: cliente possui contratos
1
Cliente Associação Contrato engloba
nmCliente 1 nrContrato
cpfCliente 0..*
realiza dtContrato
endereço 0..*
vlContrato Associação
dtNascim reflexiva
/idade
Derivado Multiplicidade
Numero de objetos de uma
Papel (opcional)
classe relacionados com um
recomendável principalmente
único objeto de outra
numa associação reflexiva
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
1..* 11..22
é composto de
Notação para agregação
30
3/17/2011
Relações entre Classes - Composição
 Representa uma associação “todo-parte”, mas qualquer das

“partes” tem um e somente um “todo”
Mesa NotaFiscal ItemNF

1 *
1 4
contem
Tampo Perna
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
Enfermeiro
Cirurgião
Pessoa Doutor
Clinico geral
Anestesista
Subclasses herdam atributos, operações e relações da superclasse
31
3/17/2011
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º Caso : Associação promovida à Classe Plena


Pessoa Emprego Empresa
cpf 1 1..* periodoAlocado 1..* 1 cnpj
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
Neste caso só pode haver uma instância entre as classes associadas
Pessoa * Projeto
trabalha para 1..*
cpf identificador
Contrato
Classe de remuneração
Só pode haver uma
Associação instância entre as classes
associadas
32
3/17/2011
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 :
33
3/17/2011
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
34
3/17/2011
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)
35

OOe UML

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

OOe UML

Título original:

Enviado por

Direitos autorais:

Formatos disponíveis

3/17/2011

Análise de Projeto Orientado a

Monitoramento de Projetos Marcelo Castilho – Todos os direitos reservados

 1984 - Formado em Programação Cobol

Monitoramento de Projetos Marcelo Castilho – Todos os direitos reservados

 Cap.1 – Processos de Desenvolvimento de Software

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

Monitoramento de Projetos Marcelo Castilho – Todos os direitos reservados

 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

Monitoramento de Projetos Marcelo Castilho – Todos os direitos reservados

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

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

Monitoramento de Projetos Marcelo Castilho – Todos os direitos reservados

Cap. 1 - Processos de Desenvolvimento de SW

 Antes da Análise Estruturada...

 Um breve resumo da Análise Estruturada

 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

Monitoramento de Projetos Marcelo Castilho – Todos os direitos reservados

Antes da Análise Estruturada...

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

 Surgimento de linguagens comerciais como o COBOL e preocupação em

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

Monitoramento de Projetos Marcelo Castilho – Todos os direitos reservados

Desenvolvimento de software na época

 “Euquipe” ao invés de equipe

 Repetição do código e arquivos duplicados

 Pouca padronização e documentação

 Não atendimento aos requisitos de negócio

“Muita programação e nenhuma

Monitoramento de Projetos Marcelo Castilho – Todos os direitos reservados

Análise Estruturada - Metodologia

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

 Definido a metodologia e as ferramentas para desenvolvimento de

Monitoramento de Projetos Marcelo Castilho – Todos os direitos reservados

Análise Estruturada - Especificação

Estoque = @cd_produto int código do produto

Monitoramento de Projetos Marcelo Castilho – Todos os direitos reservados

Análise Estruturada - Projeto

Monitoramento de Projetos Marcelo Castilho – Todos os direitos reservados

Análise Estruturada - Problemas

Como são analisados separadamente nas fases de

Monitoramento de Projetos Marcelo Castilho – Todos os direitos reservados

Análise Estruturada - Problemas

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

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

Ciclo Tradicional de Desenvolvimento

Monitoramento de Projetos Marcelo Castilho – Todos os direitos reservados

Análise Estruturada - Problemas

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

Usado depois de Usado tal como

Monitoramento de Projetos Marcelo Castilho – Todos os direitos reservados

 Estudo e aplicação de procedimentos sistemáticos, disciplinados e

 Desenvolver software não é somente modelar e escrever código. É criar