Escolar Documentos
Profissional Documentos
Cultura Documentos
Apostila Uml 3
Apostila Uml 3
julho de 2007
Sumrio
AULA 1 PROCESSO DE SOFTWARE..........................................................................................5
1.1. Apresentao........................................................................................................................5
1.2. Introduo............................................................................................................................5
1.3. UML.....................................................................................................................................5
1.4. Crise do software.................................................................................................................6
1.5. Processo e Notao..............................................................................................................6
1.6. O poder da tecnologia de Objetos........................................................................................6
1.7. Anlise e projeto...................................................................................................................7
1.8. Desenvolvimento Iterativo e Incremental............................................................................7
1.9. Processo Unificado..............................................................................................................7
1.10. Atividade............................................................................................................................9
AULA 2 LEVANTAMENTO DE REQUISITOS..........................................................................10
2.1. Apresentao......................................................................................................................10
2.2. Levantamento de Requisitos..............................................................................................10
2.3. Atividade............................................................................................................................11
AULA 3 CASOS DE USO............................................................................................................13
3.1. Apresentao......................................................................................................................13
3.2. Comportamento do Sistema...............................................................................................13
3.3. Atores.................................................................................................................................13
3.4. Casos de Uso......................................................................................................................14
3.5. DIAGRAMAS DE CASO DE USO..................................................................................15
3.6. Atividade............................................................................................................................16
AULA 4 ESPECIFICAO DE CASOS DE USO......................................................................17
4.1. Apresentao......................................................................................................................17
4.2. A Especificao de um caso de Uso...................................................................................17
4.3. Atividade............................................................................................................................18
AULA 5 RELACIONAMENTOS ENTRE CASOS DE USO......................................................19
5.1. Apresentao......................................................................................................................19
5.2. Relacionamentos entre casos de uso..................................................................................19
5.3. Relacionamento <<include>>............................................................................................19
5.4. Relacionamento <<extend>>.............................................................................................19
5.5. Generalizaes...................................................................................................................20
5.6. Atividade............................................................................................................................21
AULA 6 IDENTIFICAO DE CLASSES USANDO O MVC..................................................22
6.1. Apresentao......................................................................................................................22
6.2. Descobrindo Classes..........................................................................................................22
6.3. Classes Entidade................................................................................................................22
6.4. Classes Limite....................................................................................................................22
6.5. Classes Controle.................................................................................................................23
6.6. Objetos e Classes no problema do Sistema de Matrcula (MATRI)..................................23
6.7. Atividade............................................................................................................................24
AULA 7 IDENTIFICAO DAS RESPONSABILIDADES DAS CLASSES ..........................25
7.1. Apresentao......................................................................................................................25
7.2. Cartes CRC......................................................................................................................25
7.3. Atividade............................................................................................................................26
AULA 8 IDENTIFICAO DE ATRIBUTOS E OPERAES DE UMA CLASSE................27
3
8.1. Apresentao......................................................................................................................27
8.2. O que uma operao?......................................................................................................27
8.3. O que um Atributo?.........................................................................................................29
8.4. Encapsulamento.................................................................................................................29
8.5. Atividade............................................................................................................................31
AULA 9 ASSOCIAES ENTRE CLASSES.............................................................................32
9.1. Apresentao......................................................................................................................32
9.2. Associaes........................................................................................................................32
9.3. Multiplicidade para Associaes........................................................................................33
9.4. Atividade............................................................................................................................34
AULA 10 AGREGAES E ASSOCIAES............................................................................36
10.1. Apresentao....................................................................................................................36
10.2. Agregao.........................................................................................................................36
10.3. Associaes Reflexivas....................................................................................................37
10.4. Classes de Ligao...........................................................................................................38
10.5. Encontrando Associaes e Agregaes..........................................................................39
10.6. Atividade..........................................................................................................................39
AULA 11 HERANA...................................................................................................................40
11.1. Apresentao....................................................................................................................40
11.2. Generalizao...................................................................................................................40
11.3. Herana Mltipla..............................................................................................................42
11.4. Atividade..........................................................................................................................43
AULA 12 INTERFACES E PACOTES.........................................................................................44
12.1. Apresentao....................................................................................................................44
12.2. Interfaces..........................................................................................................................44
12.3. Pacotes.............................................................................................................................45
12.4. Atividade..........................................................................................................................47
AULA 13 MODELO DE CLASSES, IMPLEMENTAO E MODELO RELACIONAL.........48
13.1. Apresentao....................................................................................................................48
13.2. Mapeando diagramas de Classe para cdigo em java......................................................48
13.3. Mapeando Classes para Modelo RElacional....................................................................50
13.4. Atividade..........................................................................................................................52
AULA 14 DIAGRAMAS DE INTERAO................................................................................53
14.1. Apresentao....................................................................................................................53
14.2. Diagramas de interao....................................................................................................53
14.3. Atividade..........................................................................................................................55
AULA 15 DIAGRAMAS DE SEQNCIA................................................................................56
15.1. Apresentao....................................................................................................................56
15.2. DESENVOLVIMENTO...................................................................................................56
15.3. Atividade..........................................................................................................................58
AULA 16 DIAGRAMAS DE ESTADOS.....................................................................................59
16.1. Apresentao....................................................................................................................59
16.2. Diagramas de Estados:.....................................................................................................59
16.3. Atividade..........................................................................................................................61
AULA 17 DIAGRAMAS DE COMPONENTES E DE IMPLANTAO..................................62
17.1. Apresentao....................................................................................................................62
17.2. Diagramas de Componentes.............................................................................................62
17.3. Diagramas de Implantao...............................................................................................63
17.4. Atividade..........................................................................................................................64
4
17.5. BIBLIOGRAFIA BSICA..............................................................................................64
1.2. INTRODUO
O desenvolvimento orientado a objetos comeou em 1967 com a linguagem Simula-67 e desde
ento surgiram linguagens orientadas a objetos como Smalltalk e C++ entre outras. Nos anos
80 comearam a surgir metodologias de desenvolvimento orientadas a objetos para tirar
vantagens deste paradigma. Entre 1989 e 1994 surgiram quase 50 mtodos de
desenvolvimento orientados a objetos, fenmeno que foi chamado a guerra dos mtodos.
Entre as mais importantes estavam: o mtodo de G. Booch, a Object Modeling Technique
(OMT) de J. Rumbaugh, o mtodo de Shlaer e Mellor e o mtodo Objectory de I. Jacobson. I.
Jacobson introduziu a modelagem de casos de uso em 1987 e criou o primeiro processo de
desenvolvimento de software que utiliza casos de uso, chamado Objectory.
Cada mtodo possua uma notao prpria, o que gerou uma infinidade de tipos de diagramas
e notaes. Isto causava problemas de comunicao, treinamento de pessoal e portabilidade.
Um esforo de unificao comeou em 1994 quando J. Rumbaugh e, logo aps, I. Jacobson,
juntaram-se a G. Booch, na empresa Rational Software Corporation. O primeiro grande
resultado desse esforo foi a criao da Unified Modeling Language (UML), apresentada, na
sua verso 1.0, em 1997.
1.3. UML
A UML uma linguagem criada para visualizar, especificar, construir e documentar os artefatos
de um sistema de software. A UML adotada, desde 1997, como padro internacional pelo
OMG (Object Management Group). A UML prov um conjunto de diagramas e seus
componentes, todos com notao e comportamento (semntica) bem definidos. A UML
descreve 13 diagramas que so apresentados na figura abaixo.
7
Reduo do nmero de linhas de cdigo dos projetos
1.10. ATIVIDADE
1)
2)
3)
4)
5)
6)
10
Durante o levantamento de requisitos a equipe tenta entender o domnio que deve ser
automatizado pelo sistema de software. O levantamento de requisitos um estudo exploratrio
das necessidades dos clientes, usurios e stakeholders (pessoas que so afetadas pelo
sistema).
O produto do levantamento de requisitos o documento de requisitos. Neste documento, os
requisitos so categorizados em: requisitos funcionais, requisitos no funcionais e requisitos
normativos.
Os requisitos funcionais representam as necessidades que o sistema deve prover. Por
exemplo:
O sistema deve permitir que o gerente de vendas visualize o relatrio de vendas por
regio.
11
2.3. ATIVIDADE
1)Faa uma especificao de requisitos para o sistema descrito abaixo:
Sistema de Matrcula em cursos de Universidade
O processo de designao de professores para cursos e a matrcula de estudantes
uma experincia frustrante e que consome muito tempo.
Depois que os professores da Universidade decidem em quais cursos eles vo lecionar
no semestre, a Secretaria alimenta essa informao no sistema em computador. Um
relatrio batch impresso para os professores indicando em quais cursos eles
lecionaro. Um catlogo de cursos impresso e distribudo para os estudantes.
Atualmente, os alunos preenchem formulrios de matrcula que indicam suas escolhas de
cursos e retornam os formulrios para a Secretaria. A carga tpica de um estudante de
quatro cursos. Os funcionrios da Secretaria alimentam os dados dos formulrios dos
estudantes no sistema de computador no mainframe. Uma vez que o currculo para o
semestre foi alimentado no sistema, um job batch executado durante a noite para
inscrever os estudantes nos cursos. Na maioria das vezes os estudantes obtm sua
primeira escolha; entretanto, naqueles casos em que h um conflito, a Secretaria
conversa com cada estudante para obter escolhas adicionais. Quando todos os
estudantes tiverem sido inscritos com sucesso nos cursos, um relatrio dos currculos
dos estudantes encaminhado para eles para verificao. A maioria dos registros dos
estudantes so processados durante uma semana, mas alguns casos excepcionais
demoram at duas semanas para serem solucionados. Quando o perodo inicial de
matrcula concludo, os professores recebem uma lista de estudantes para cada curso
que devem lecionar.
O novo sistema vai permitir, no incio de cada semestre, que os estudantes possam
solicitar um catlogo de cursos contendo uma lista dos cursos oferecidos no semestre.
Informaes sobre cada curso, tais como professor, departamento e pr-requisitos
estaro includas para ajudar os estudantes a tomarem suas decises.
O novo sistema vai permitir aos estudantes selecionarem quatro dos cursos oferecidos
para o semestre. Alm disso, cada estudante indicar duas escolhas alternativas para
12
caso um curso oferecido seja cancelado ou no tenha vagas suficientes. Nenhum curso
poder ter mais de dez ou menos do que trs alunos. Um curso com menos de trs
alunos ser cancelado. Uma vez concludo o processo de matrcula de um estudante, o
sistema de matrcula envia informao para o sistema de faturamento de forma que o
aluno possa receber as faturas para o semestre.
Professores devem poder acessar o sistema online para indicar quais cursos eles
lecionaro e para ver que estudantes se inscreveram em suas ofertas de curso. Para
cada semestre, h um perodo de tempo no qual os estudantes podem mudar sua grade
horria. Os estudantes devem poder acessar o sistema durante este perodo para
adicionar ou retirar cursos.
13
3.3. ATORES
Atores no so parte do sistema - eles representam algo ou algum que deve interagir com o
sistema. Um ator pode:
Quem suprir o sistema com esta informao, usar esta informao e remover esta
informao?
14
Na UML, um ator representado como um homem palito, como mostrado na figura abaixo.
Um caso de uso uma seqncia de transaes executadas por um sistema, que produz
um resultado mensurvel de valores para um ator em particular.
As seguintes perguntas devem ser usadas para auxiliar na identificao dos casos de
uso para um sistema:
15
16
Depois que o processo de seleo estiver completo, o sistema de Faturamento deve ser
suprido com informaes de fatura
O ator Professor precisa usar o sistema para selecionar os cursos para lecionar por um
semestre e deve estar habilitado a receber uma lista de cursos do sistema
A Secretaria responsvel pela gerao do catlogo de curso para um semestre e, pela
manuteno de todas as informaes a respeito do currculo, dos estudantes e dos
professores.
Baseado nestas necessidades, diversos casos de usos podem ser identificados, como o
"Matricula em um curso".
3.6. ATIVIDADE
Baseando-se na descrio dos sistema de matrculas (MATRI), descrito acima, desenvolva as
seguintes atividades:
1)Encontre os casos de uso, os atores, e os relacionamentos entre os casos de uso e
atores (coloque tudo no diagrama de casos de uso)
2)Faa uma breve descrio para os atores e os casos de uso que forem identificados
(mximo 2 frases)
17
18
Uma amostra do documento de Fluxo de Eventos para o Caso de Uso Selecionar Cursos para
Lecionar mostrada a seguir:
Especificao do Caso de Uso Cadastrar Usurio
1 Nome do Caso de Uso
Cadastrar Usurio
2 Breve descrio
Cadastra um usurio no sistema, com todos os dados, inclusive uma fotografia.
3 Fluxo de eventos
3.1Fluxo bsico
3.1.1 O caso de uso comea quando o ator seleciona a opo cadastrar
usurio. O sistema mostra a tela de cadastro de usurio com os seguintes
campos em branco: nome, "endereo", RG, CPF, telefone, email.
3.1.2 O ator preenche os campos e seleciona a opo cadastrar. O sistema
mostra uma tela para fazer o upload da fotografia.
3.1.3 O ator indica o nome e o caminho do arquivo com a sua fotografia e
seleciona importar. O sistema mostra uma tela com todos os dados e a
fotografia do cliente.
3.1.4 O ator seleciona a opo cadastrar e o sistema cadastra o novo
usurio, mostra uma mensagem de sucesso na operao e mostra a tela
inicial do sistema.
3.2 Fluxos alternativos
3.2.1< Primeiro fluxo alternativo>
Caso o ator no tenha preenchido um dos campos dos dados do usurio, o
sistema avisa o erro e retorna para a tela de cadastro dos dados do usurio com
os dados j preenchidos.
3.2.2< segundo fluxo alternativo>
Caso o usurio no importe um arquivo com a foto, o sistema mostra a tela de
confirmao sem a fotografia e uma mensagem de aviso.
3.2.3< Terceiro fluxo alternativo>
Caso o ator tenha cadastrado um usurio com o mesmo CPF, o sistema avisa o
erro e retorna para a tela de cadastro dos dados do usurio com os dados j
preenchidos.
4 Requisitos Especiais
No se aplica
5 Pr-condies
< pr-condio um >
O ator deve estar logado no sistema. Nenhum outro usurio com o mesmo CPF
dever ter sido cadastrado.
6 Ps-condies
< ps-condio um >
Um usurio novo cadastrado.
7 Pontos de Extenso
No se aplica.
4.3. ATIVIDADE
1)Baseando-se na descrio dos sistema de matrculas (MATRI), descrito nas unidades
anteriores, selecione 3 dos casos de uso identificados e faa a especificao de casos de uso
para cada um deles
19
20
um alarme, muitos diferentes caminhos que podem ser executados de acordo com uma
seleo feita por um ator. Por exemplo, um caso de uso que monitora o fluxo de pacotes em
uma esteira de transporte pode acionar um caso de uso de Disparo de Alarme se os pacotes
empilharem. At este momento, nenhum <<extend>> foi identificado para o Sistema de
Matrcula (MATRI).
5.5. GENERALIZAES
Uma generalizao entre um caso de uso C e um caso de uso D indica que C uma
especializao de D. Este relacionamento representado por uma seta de generalizao
partindo de D para C.
Pode ser representado, tambm, um tipo de relacionamento entre atores. Este relacionamento
o de generalizao. Uma generalizao de um ator A para um ator B indica que A pode se
comunicar com os mesmos casos de uso que B.
21
5.6. ATIVIDADE
Baseando-se na descrio dos sistema de matrculas (MATRI), descrito na unidade anterior,
desenvolva as seguintes atividades:
1)Encontre os casos de uso, os atores, e os relacionamentos entre os casos de uso e
atores (coloque tudo no diagrama de casos de uso)
22
23
Cada par ator/cenrio examinado para descobrir as classes limite. As classes limites
escolhidas na Fase de Elaborao do desenvolvimento so tipicamente de alto nvel. Por
exemplo, voc pode modelar uma janela mas no modela cada caixa de dilogo e botes.
Neste ponto, voc est documentando os requerimentos da interface com o usurio, no
implementando a interface.
Os requerimentos das interfaces com o usurio tendem a ser muito vagos - os termos
amigveis e flexveis so muito utilizados. Mas amigvel, tem significados diferentes para
pessoas diferentes. Neste caso as tcnicas de prototipagem podem ser muito teis. O cliente
pode dar uma olhada e sentir o sistema e realmente entender o que o termo amigvel significa.
O "o que" ento compreendido assim como a estrutura e o comportamento da Classe Limite.
Durante o projeto, essas classes so refinadas para levar em considerao os mecanismos da
interface escolhida.
Classes Limite so tambm adicionadas para facilitar a comunicao com outros sistemas.
Durante o projeto, estas classes so refinadas para levar em considerao o protocolo de
comunicao escolhido.
24
6.7. ATIVIDADE
Baseando-se no modelo de Caso de Uso abaixo, tente levantar as classes para o sistema de
Matrcula (MATRI).
25
26
A disposio espacial dos cartes importante. Quando duas classes so mtuas
colaboradoras, seus cartes devem ser colocados levemente sobrepostos. Quando uma classe
colaboradora de outras classes (a classe usada pelas outras), seu carto deve ficar abaixo
dos cartes das outras classes. Se h uma relao de herana, dever haver uma
sobreposio quase completa dos cartes. A disposio dos cartes importante, pois em
projetos ainda incompletos possvel notar a localizao de uma classe antes da mesma ter
sido projetada.
Para achar as classes, sua responsabilidades e seus colaboradores deve-se seguir as
seguintes etapas:
1. Definio das classes e das estruturas de dados de cada classe;
2. Definio das responsabilidades de cada classe;
3. Definio dos colaboradores de cada classe;
O que so classes e como defini-las
Num problema a ser resolvido, as diversas classes podem ser identificadas como as entidades
que existem no problema, por exemplo, aluno, turma, professor, etc... So classes, tambm, as
estruturas de dados utilizadas para resolver o problema, bem como os dispositivos(fsicos e
virtuais) a serem acessados. Por exemplo: interface, arquivo, controlador de tempo, etc...
O que so responsabilidades e como defini-las
As responsabilidades so definidas como sendo os problemas que as classes devem resolver.
So, a grosso modo, as funes das classes. Por exemplo: colocar um registro no arquivo, dar
presena ao aluno, cobrar mensalidade, etc... As responsabilidades so os problemas a serem
resolvidos. A maneira de resolve-los vo ser os mtodos das classes(implementao).
O que so colaboradores e como defini-los
Os colaboradores so as classes que ajudam uma classe a resolver as suas
responsabilidades. So as classes que vo prestar servios classe. A classe que est sendo
analisada solicita servios a outras classes e estas, por sua vez, prestam estes servios,
ajudando a resolver os problemas.
7.3. ATIVIDADE
1. modelar o problema de controle de uma pizzaria de entrega em domiclio. O cliente
pede uma ou mais pizzas, refrigerantes ou cervejas. O atendente anota o pedido no
sistema. Cada pizza pode ser (mdia, grande ou enorme). Cada pizza pode ter no
mximo 3 sabores. O atendente anota os dados do cilente e a forma de pagamento
(inclusive o troco necessrio). O atendente anota o cdigo do entregador e o tempo de
entrega. O gerente cadastra os sabores de pizzas existentes, os dados dos
entregadores e visualizaos relatrios de vendas(por sabor, regio) e tempo de entrega.
27
Perspectiva do Bancrio
Perspectiva do Mdico
receber emprstimo
anexar conta
receber linhaDeCrdito
examinar
tomarRemdio
irParaHospital
receberConta
Nomeando Operaes
Nome pobre
Indica que o saldo deve ser calculado - isto uma deciso de
implementao/otimizao
obterSaldo()
Bem nomeado
Indica apenas o resultado
Nomeando Operaes
As operaes devem ser nomeadas do ponto de vista do fornecedor e no do
cliente
Em um posto de gasolina, a gasolina vem da bomba
28
Assinatura da Operao
A assinatura da operao consiste de :
Lista de argumentos opcional
Classe de retorno
Durante a anlise NO OBRIGATRIO preencher a assinatura de operaes
Esta informao pode ser adiada para fase de projeto
Mostrando Operaes
Operaes so mostradas no terceiro compartimento da classe
GerenteDe
Matricula
um curso
get prerequisito
GerenteDe
Matricula
um curso
getPrerequisito():ListaDeCurso
29
Mostrando Atributos
8.4. ENCAPSULAMENTO
30
Exemplo: Encapsulamento
Valores de atributos podem ser alterados
apenas pelas operaes providas pelo
objeto
mudeNomeProprietrio
nmeroConta
nomeBanco
nomeProprietrio
saldo
depsito
saque
getSaldo
geraTransao
Benefcios do Encapsulamento
Aumentar performance
31
8.5. ATIVIDADE
32
9.2. ASSOCIAES
A Necessidade de Relacionamentos
Todos os sistemas abrangem muitas classes e objetos
Objetos atuam no comportamento de um sistema colaborando entre eles
A Colaborao realizada atravs de relacionamentos
Ocorrem dois tipos importantes de relacionamentos durante a anlise
Associao e
Generalizao
Associaes
Uma associao uma conexo semntica bi-direcional entre classes
Isto implica na existncia de uma ligao (link) entre os objetos das classes associadas
Associaes so representadas no diagrama de classes por uma linha ligando as classes
associadas. Em um link os dados podem fluir em ambas as direes
Navegao
Uma associao um relacionamento bi-direcional
Dada uma instncia de GerentelDeMatrcula h um objeto Curso associado
Dada uma instncia de Curso h um objeto OficialDeMatrcula associado
33
Definindo Papis
Um papel denota o propsito ou capacidade em que uma classe se associa com outra
Nomes de papis so tipicamente substantivos ou frases substantivas
Um nome de papel colocado ao longo da linha de associao, prximo da classe
referenciada
Um ou ambos os lados da associao podem ter nomes de papis
Associaes Mltiplas
Pode existir mais de uma associao entre duas classes
Se houver mais de uma associao entre duas classes, elas DEVEM ser nomeadas
Para cada instncia de Pessoa, muitos (i.e., zero ou mais) Cursos podem ser
ministrados
34
Muitos
Exatamente Um
Zero or mais
Um ou Mais
Zero or um
Intervalo Especfico
*
1
0..*
1..*
0..1
2..4
Indicadores de Multiplicidade
Cada lado de uma associao contem um indicador de multiplicidade
Indica o nmero de objetos que participam no relacionamento
Exemplo: Multiplicidade
Decises de Multiplicidade expem muitas suposies, antes ocultas, sobre o problema sendo
modelado
Um professor pode estar indisponvel?
Qualificadores
Um qualificador um atributo de uma classe que pode ser usado para reduzir a multiplicidade
da associao
Departamento
Professor
EmpregadoID
1
Restries
9.4. ATIVIDADE
1. Faa um Diagrama de Classes do subsistema de Operao de Trem, sem utilizar herana e
considerando o seguinte:
Um trem pode ser de carga, passageiros ou ambos e pode ser movido por um ou mais
vages com fora motriz.
Um vago com fora motriz possui um determinado tipo de motor, com potncia
especfica.
O trem de passageiros pode possuir vrias portas por vago, que devem abrir e fechar
automaticamente, ao chegar na estao e antes de partir, respectivamente.
A capacidade de passageiros de um trem deve estar registrada em quantidade, e a
35
36
10.2. AGREGAO
Agregao uma forma especializada de associao na qual o todo est relacionado a sua(s)
parte(s). Agregao conhecida como parte-de ou relacionamento de contedo. Uma
agregao representada como uma associao com um losango perto da classe que denota
a agregao (todo). A multiplicidade representada da mesma maneira que nas outras
associaes
<<limite>>
FormularioDeMatrcula
<<limite>>
FormularioDeHorrio
1
Testes de Agregao
Tipos de Agregao
Existem dois tipos de agregao:
Agregao propriamente dita, ou tambm chamada agregao por referncia
Conhecida como relacionamento tem-um(a)
Envolve partes componentes que existem independentemente de seus
agregados
Exemplo: A rea X da empresa tem os empregados A, B e C
Area
Empregado
1
0..*
37
componentes
Automovel
Porta
1
2..5
Associao ou Agregao ?
Se dois objetos so estreitamente ligados por um relacionamento parte-todo
O relacionamento uma agregao
Se dois objetos so usualmente considerados independentes, mesmo que eles estejam
freqentemente ligados
O relacionamento uma associao
Pr-requisito
0..*
ParteDeProduto
0..*
38
Um objeto ParteDeProduto composto de zero ou mais objetos ParteDeProduto
0..*
Curso
3-10
O atributo nota no pode ser colocado em Curso porque h (potencialmente) muitas ligaes
para muitos objetos Estudante
O atributo nota no pode ser colocado na classe Estudante porque h (potencialmente) muitas
ligaes para muitos objetos Curso
Portanto, o atributo realmente pertence a uma ligao particular Estudante-Curso
Uma classe de ligao usada para conter a informao da ligao
Desenhando Classes de Ligao
Crie uma classe de ligao usando um cone de classe
Conecte a classe na linha da associao usando uma linha tracejada
A classe de ligao pode incluir propriedades mltiplas da associao
Apenas uma classe de ligao permitida por associao
1..*
Estudante
Curso
3-10
Boletim
39
Estudante
nota
Curso
3-10
Estudante
Curso
3-10
nota
<<limite>>
<<limite>>
FormularioDeMatrcula
FormularioDeHorario
1
FormularioDeHorario e
GerenteDeMatrcula
so independentes
1
1
1
GerenteDeMatrcula
10.6. ATIVIDADE
Faa um Diagrama de Classes para um problema com as seguintes caractersticas:
40
AULA 11 HERANA
11.1. APRESENTAO
Nesta aula iremos abordar e exercitar o que so generalizaes entre classes e como us-las.
Iremos abordar aspectos como: generalizao, hierarquia, notao, subclasse, superclasse,
especializao, e herana mltipla.
11.2. GENERALIZAO
Relacionamento de Generalizao
InfoEstudante
Subclasse
O relacionamento no nomeado
Atributos
Operaes
Relacionamentos
Uma subclasse pode:
41
Herdando Atributos
Atributos so definidos no nvel mais alto da hierarquia de herana na qual eles so
aplicveis
Subclasses de uma classe herdam todos os atributos
Cada subclasse pode adicionar novos atributos
VeculoTerrestre
peso
nmeroLicena
Carro
Caminho
tonelagem
Herdando Operaes
Operaes so definidas no nvel mais alto da hierarquia de herana na qual elas so
aplicveis
Subclasses de uma classe herdam todas as operaes
Cada subclasse pode aumentar ou redefinir operaes herdadas
Herdando Relacionamentos
Relacionamentos tambm so herdados e devem ser definidos no nvel mais alto da
hierarquia de herana na qual eles so aplicveis
Subclasses de uma classe herdam todos os relacionamentos
Cada subclasse pode tambm possuir relacionamentos adicionais
Generalizao de Classes
Generalizao proporciona a capacidade de criar superclasses que reunem estrutura
e/ou comportamento comum a vrias subclasses
Procedimento de generalizao
42
Bens
ContaBancria
Poupana
ContaCorrente
Seguro
Imveis
Aes
Bnus
Especializao de Classes
A especializao proporciona a capacidade de criar subclasses que representam
refinamentos nos quais a estrutura e/ou comportamento da superclasse so
adicionados ou modificados
Procedimento de Especializao
Notar que algumas instncias apresentam estrutura ou comportamento especializado
Criar subclasses para agrupar instncias de acordo com sua especializao
Subclasses so menos abstratas que suas superclasses
Hierarquias de Herana
Tanto generalizao quanto especializao so usadas no desenvolvimento de uma
hierarquia de herana
Durante a anlise, so estabelecidas hierarquias de herana entre abstraes chaves
(i.e., classes) se necessrio
Durante o projeto, as hierarquias de herana so refinadas para:
Aumentar reutilizao
Incorporar classes de implementao
Incorporar bibliotecas de classes disponveis
Animal
herana
mltipla
Avio
Helicptero
Pssaro
Lobo
Cavalo
43
Cada ambiente/linguagem de programao escolhe maneiras de resolver estas dificuldades
Encontrando generalizao
importante avaliar todas as classes para encontrar possveis generalizaes
Redefina operaes
Agregao
Palavra chave um
Relaciona objetos da
mesma superclasse
Representado por uma seta
11.4. ATIVIDADE
Construa um Diagrama de Classes inicial para controlar emprstimos e reservas de
publicaes em uma biblioteca, considerando o seguinte:
44
12.2. INTERFACES
Uma Interface uma coleo de operaes utilizadas para especificar um servio de uma
classe ou componente.
As interfaces so empregadas para visualizar, especificar, construir e documentar a coeso
interna do sistema.
Escolhendo as interfaces corretas, voc pode selecionar componentes padro, bibliotecas e
frameworks para a implementao destas interfaces, sem precisar constru-las. medida que
descobrir implementaes melhores, voc pode substituir as antigas sem perturbar seus
usurios
Declarando a interface, voc pode estabelecer o comportamento desejado de uma abstrao
independente de qualquer implementao desta interface.
Notao:
Relacionamentos:
A relao entre Alvo e Observador uma relao de dependncia, enquanto que a relao
entre Observador e Rastreador uma relao de realizao. Uma relao de realizao indica
que a classe Rastreador implementa a interface Observador.
45
12.3. PACOTES
Se um sistema contm somente poucas classes, voc pode gerenci-las facilmente. Mas, a
maioria dos sistemas so compostos por muitas classes, neste caso ento necessrio um
mecanismo para agrupa-las, para obter uma melhor facilidade de uso, manuteno e
reutilizao. Neste caso onde o conceito de packages til. Um package na viso lgica de
um modelo uma coleo de packages e/ou classes relacionados. Agrupando classes em
packages, ns podemos ter uma viso de mais alto nvel do modelo (i.e., os packages), ou
podemos nos aprofundar no modelo, dando uma olhada no que est contido no package.
Cada package contm uma interface que implementada por um conjunto de classes pblicas
- aquelas classes com as quais os outros packages falam. O resto das classes em um package
so classes de implementao - classes, que no se comunicam com as classes de outros
packages.
Se um sistema complexo, packages podem ser criados logo no incio da Fase de Elaborao
para facilitar a comunicao. Para sistemas simples, as classes descobertas na anlise podem
ser agrupadas em um package - o prprio sistema. No decorrer do processo de anlise e
projeto, o conceito de package ser utilizado para agrupar as classes que so necessrias para
realizar as decises arquiteturais tomadas para o sistema.
Na UML, packages so representados como pastas.
Criando Packages
O prximo passo agrupar as classes em packages. Neste ponto, ns temos identificadas seis
classes: Curso, OfertaCurso, InformaoProfessor, OpesCursoProfessor,
AdicionaOfertaCurso e ControleCursoProfessor. Elas caem em trs grupos lgicos - coisas
nicas para a universidade, coisas que contm informaes sobre pessoas e coisas que so
parte das interfaces com os atores. Ns podemos identificar os packages: Interfaces,
ServicoUniversidade e InformacaoPessoa. As classes so realocadas para os packages
identificados. Os packages com suas classes so mostrados abaixo.
O principal diagrama de classes na viso lgica do modelo normalmente uma figura dos
packages do sistema. Cada package tambm tem o seu prprio diagrama principal, o qual
normalmente mostra as classes pblicas do package. Outros diagramas podem ser criados de
acordo com a necessidade. Alguns dos usos tpicos de outros diagramas so:
Viso de todas as classes de implementao do package;
Viso da estrutura e comportamento de uma ou mais classes;
Viso da hierarquia de herana.
Um exemplo do diagrama de classe principal do sistema de matrcula mostrado na figura
abaixo.
46
Quando mais packages e classes so adicionados ao modelo, diagramas adicionais podem ser
criados quando necessrios.
Um package na viso lgica do modelo uma coleo packages e/ou classes relacionadas.
Agrupando classes em packages, ns podemos olhar ao mais alto nvel de viso do modelo
(i.e., os packages), ou ns podemos ir fundo no modelo olhando o que est contido dentro dos
packages.
Relacionamentos entre Pacotes
Pacotes so relacionados entre si usando um relacionamento de dependncia
Se uma classe em um pacote conversa com uma classe em outro pacote ento um
relacionamento de dependncia adicionado ao nvel de pacote
Diagramas de Cenrio e diagramas de classe so avaliados para determinar relacionamentos
entre pacotes
47
Interfaces
Controle
Artefatos
Universitrios
12.4. ATIVIDADE
Construa um Diagrama de Classes inicial para controlar emprstimos e reservas de
publicaes em uma biblioteca, considerando o seguinte:
48
Implementando associaes:
Para implementar uma associao precisamos colocar um atributo de referncia. Em qual
classe ser colocado este atributo, depende da multiplicidade da associao. Estes atributos
ou classes que so criados para este fim no devem ser colocados no diagrama de classes.
No caso 1 para muitos podemos colocar todo o objeto com multiplicidade 1 como atributo do
objeto com multiplicidade muitos:
49
ou, se o objeto tiver um cdigo gerado automaticamente na base de dados, apenas o cdigo do
objeto com multiplicidade 1 como atributo do objeto com multiplicidade muitos:
public class ItemDePedido
{
private int quantidade;
private int codProduto;
}
Agregaes:
Uma agregao pode ser implementada usando um objeto para colees do Java como
java.util.Vector. Este objeto colocado como atributo da classe que agrega e contm objetos
da classe agregada;
public class Pedido
{
private Date data;
private String codPedido;
private boolean completo;
50
private Vector todosItens;
}
51
Uma tabela por classe
Mista
52
13.4. ATIVIDADE
1) Construa um Diagrama de Classes inicial para controlar emprstimos e reservas de
publicaes em uma biblioteca, considerando o seguinte:
2) Crie o cdigo Java para trs das classes identificadas acima, que possuas relacionamento.
3) Crie o script SQL de criao dessas 3 classes.
53
PASSOS:
1.
2.
3.
4.
:CtrlCadCliente
:Cliente
Usuario
Cliente:= mostraTelaCadCliente()
formulrio cliente
dados Cliente
setNome(nome)
setCNPJ(cnpj)
54
retorno de mensagem;
:ClasseB
:ClasseC
numero:= verificaNome(nome)
[numero = 0]: codigoNulo:= geracodigoNulo()
alt
[numero <= 3]
setNome(nome)
codigo:= calculaCodigo(nome)
nome:= getNome()
[numero >3]
c) Repeties (loops):
representados direto na mensagem ou atravs de fragmentos combinados (UML 2.0)
d) Chamadas a outros diagramas de seqncia (UML 2.0)
sd exemplo05
:CtrlPedido
criar ( )
:TicketBD
:Conta
:Pedido
loop
[proximo item]
reservar(contagem,date)
alt
[disponvel]
[no disponvel]
adicionar(assentos)
rejeitar()
debitar(custo)
55
omitidos na fase de anlise.
e)Podemos especificar objetos que so criados em tempo de execuo do sistema.
f) Podemos tambm expressar mensagens reflexivas.
g) Tambm podemos expressar noo de tempo de transmisso de mensagem.
DIAGRAMA DE COMUNICAO:
- Vieram a substituir os diagramas de colaborao na UML 2.0
- Mesmo comportamento do diagrama de rastreamento de eventos, porm com uma outra
viso.
- Algumas ferramentas CASE fazem a transformao automtica.
- a mesma coisa "escrita" de outra forma.
14.3. ATIVIDADE
construa o diagrama de seqncia para os seguintes enunciados:
2.2. Fluxo de Eventos
2.2.1. Fluxo bsico
1. O caso de uso comea quando o funcionrio seleciona a opo manter dados do ponto. O
sistema mostra uma lista com os ltimos registro de ponto e as opes "alterar " e "inserir".
2. Se o funcionrio seleciona a opo "incluir", o sub-fluxo incluir ponto executado; Se o
funcionrio seleciona a opo "alterar", o sub-fluxo alterar ponto executado;
2.2.2. Subfluxo inserir ponto
1. O sistema mostra uma tela com os campos do ponto, que so: "hora de incio", "hora de
trmino", "data", "nmero do projeto".
2. O funcionrio preenche os campos. O sistema mostra os dados preenchidos e pede
confirmao
3. O funcionrio confirma a incluso. O sistema mostra uma mensagem de sucesso.
2.2.3. Subfluxo alterar ponto
1. O sistema mostra uma lista com os ltimos registro de ponto.
2. O funcionrio seleciona o ponto a ser alterado. O sistema mostra uma tela com os dados do
ponto, que so: "hora de incio", "hora de trmino", "data", "nmero do projeto".
3. O funcionrio altera os dados necessrios. O sistema mostra os dados alterados e pede
confirmao
4. O funcionrio confirma a alterao. O sistema mostra uma mensagem de sucesso.
56
15.2. DESENVOLVIMENTO
Dicas para a identificao de classes que participam do caso de uso:
Para cada ator que participa do caso de uso, identifique pelo menos uma classe <<limite>>;
Para cada caso de uso identifique uma classes <<controle>>;
Para cada grupo de informaes manipulado no caso de uso, identifique uma classe <<entidade>>.
<<controle>>
CtlrCadastrarProduto
<<entidade>>
Produto
2. O Administrador preenche os dados do produto e seleciona a opo gravar produto. O sistema mostra
uma tela com os dados preenchidos do produto e pede confirmao;
:Administrador
limite
:IntAdministrador
controle
:CtrlCadastrarProduto
entidade
:Produto
limite
:Repositorio
:SGBD
57
1. O caso de uso comea quando o administrador seleciona a opo cadastrar produto. O sistema
mostra um formulrio com os campos para os dados do produto.
:Administrador
limite
:IntAdministrador
controle
:CtrlCadastrarProduto
entidade
:Produto
limite
:Repositorio
:SGBD
opcao:= mostraMenu()
menu
cadastrar produto
produto:= telaCadastroProduto()
tela cadastro produto
2. O Administrador preenche os dados do produto e seleciona a opo gravar produto. O sistema mostra
uma tela com os dados preenchidos do produto e pede confirmao;
:Administrador
limite
:IntAdministrador
controle
:CtrlCadastrarProduto
entidade
:Produto
limite
:Repositorio
:SGBD
opcao:= mostraMenu()
menu
cadastrar produto
produto:= telaCadastroProduto()
tela cadastro produto
dados do produto
setDados(valor,codigo,descricao,nome)
confirmacao:= pedeConfirmacao(produto)
dados do produto
dadosProduto:= getDados()
58
:Administrador
limite
:IntAdministrador
controle
:CtrlCadastrarProduto
entidade
:Produto
limite
:Repositorio
:SGBD
opcao:= mostraMenu()
menu
cadastrar produto
produto:= telaCadastroProduto()
tela cadastro produto
dados do produto
setDados(valor,codigo,descricao,nome)
confirmacao:= pedeConfirmacao(produto)
dados do produto
dadosProduto:= getDados()
confirmacao
gravou:= gravaProduto(produto)
dadosProduto:= getDados()
alt
[gravou]
mostraMensagem(mensagemSucesso)
insere dados
Produto gravado
15.3. ATIVIDADE
1. Construa o digrama de seqncia, e implemente o caso de uso alterar Produto para o
mesmo sistema.
59
60
Estado Destino
Evento
Condies de proteo
Aes
Exemplo:
Um diagrama que representa os estados de um pedido em uma empresa que fabrica itens sob
medida. O pedido aberto. Uma vez efetuada a venda, o pedido passa a para a produo.
Terminada a produo, o pedido passa para a entrega e, uma vez entregue ele concludo. O
pedido s pode ser cancelado enquanto est aberto ou em produo.
Subestados:
61
16.3. ATIVIDADE
1) Fazer um diagrama de estados para representar os diferentes estados de um funcionrio em
uma empresa.
2) Fazer um diagrama de estado para representar os diferentes estados de uma fita de vdeo
em uma vdeo-locadora.
62
Os componentes podem ser arquivos de propriedades, arquivos fonte, arquivos html, jsp e at
mesmo bibliotecas que precisam ser instaladas.
63
64
Exemplo:
17.4. ATIVIDADE
Faa um diagrama de implantao para o problema do sistema de Matrculas
65
BIBLIOGRAFIA BSICA
BECK, K; CUNNINGHAM, W.. A laboratory for teaching Object-Oriented thinking. Anais do
International Conference on Object-Oriented Programming, Systems, Languages and
Applications OOPLSA89. New Orleans, EUA: 1989.
BEZZERRA, E.. Princpios de anlise e projeto de sistemas com UML. Rio de Janeiro,
Brasil: Campus, 2002.
BOOCH, G.; RUMBAUGH, J.; JACOBSON, I.. The Unified Modeling Language user guide.
2a. ed.Westford, Massachusets, EUA: Addison-Wesley, 2005.
JACOBSON, I.; BOOCH, G.; RUMBAUGH, J.. The Unified Software Development Process.
Reading, Massachusetts, EUA: Addison-Wesley, 1999.
LARMAN, C.. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and
Design and Iterative Development. 3a. ed. New Jersey, EUA: Addison-Wesley Professional,
2004.
OMG. Unified Modeling Language - Superstructure specification Verso 2.0. OBJECT
MANAGEMENT GROUP: Nedham, Massachusets, EUA, 2005
PRESSMAN, R. S.. Software Engineering: a practitioner's approach. 6a. ed .New York,
EUA: McGraw-Hill, 2005.
RUMBAUGH, J.; JACOBSON, I.; BOOCH, G.. The unified modeling language reference
manual. 2a. ed. Reading, Massachusetts, EUA: Addison-Wesley, 2004.