Escolar Documentos
Profissional Documentos
Cultura Documentos
Apostilauml PDF
Apostilauml PDF
Setembro de 2015
2
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
8.1. Apresentao......................................................................................................................27
3
1.1. APRESENTAO
Nesta aula sero apresentados e discutidos os conceitos de processo de desenvolvimento de
software, processo e notao, crise de software, anlise e projeto, desenvolvimento iterativo e
incremental e do Processo Unificado.
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.
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.
5
Fluxos de atividades
Atividades
passos
entradas e sadas
guias (de ferramentas ou no), templates
Responsveis (papel e perfil, no pessoa)
Artefatos
8
1.10. ATIVIDADE
1) Qual a diferena entre processo e notao?
2) Qual a diferena entre anlise e projeto de sistemas de software?
3) Cite algumas caractersticas da orientao a objetos.
4) Quais so as caractersticas do processo unificado?
5) Quais so e o que feito em cada uma das fases do processo unificado?
6) O que arquitetura do sistema?
9
2.1. APRESENTAO
Nesta aula sero apresentados e discutidos os conceitos de concepo e
especificao de um projeto de um sistema de software.
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).
2.3. ATIVIDADE
1)Faa uma especificao de requisitos para o sistema descrito abaixo:
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
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
11
3.1. APRESENTAO
Nesta aula sero discutidos de comportamento do sistema, como definir casos de uso e
atores e como utilizar o diagrama de casos de uso para mostrar os atores, os casos de uso
e suas interaes.
3.3. ATORES
Atores no so parte do sistema - eles representam algo ou algum que deve interagir com o
sistema. Um ator pode:
Somente fornecer informaes para o sistema
Somente receber informaes do sistema
Fornecer e receber informaes para e do sistema
Tipicamente, estes atores so encontrados na definio do problema e em conversas com
clientes e especialistas no domnio do problema. As seguintes perguntas podem ser usadas
para auxiliar na identificao dos atores de um sistema:
Na UML, um caso de uso representado como uma figura oval, como mostrado na figura
abaixo.
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)
16
4.1. APRESENTAO
Nesta aula ser apresenta e discutida a especificao dos caso de uso
Uma amostra do documento de Fluxo de Eventos para o Caso de Uso Selecionar Cursos para
17
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
18
5.1. APRESENTAO
Nesta aula ser apresentado e discutido como utilizar o diagrama de casos de uso
para mostrar os atores, os casos de uso e suas interaes.
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).
Um relacionamento extend de um caso de uso A para um caso de uso B indica que o caso de
uso B pode ser aumentado (de acordo com condies especificadas na extenso) por um
comportamanto especificado pelo caso de uso A. O comportamento inserido no local definido
pelo ponto de extenso em B o qual referenciado pelo relacionamento extend. No caso de
uso A, o comportamento a ser inserido deve ser marcado com um rtulo.
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.
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)
21
6.1. APRESENTAO
Nesta aula ser visto como identificar Classes de um sistema usando o Padro Modelo-Viso-
Controlador.
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.
Este caso de uso interage somente com o ator Professor. A ao especificada neste cenrio
somente uma das definidas no caso de uso (o caso de uso tambm afirma que o Professor
pode modificar, excluir, rever e imprimir a seleo). Isto significa que alguma coisa no sistema
deve prover ao Professor a capacidade de selecionar a sua opo. Uma classe contm todas
as opes disponveis ao Professor como est registrado no caso de uso, para satisfazer a
especificao feita. Esta classe chamada OpesCursoProfessor. Adicionalmente podemos
identificar uma classe que faa a adio de um novo Curso Ofertado para o Professor. Esta
classe chamada AdicionaOfertaCurso.
Este cenrio est relacionado com Cursos, com as Ofertas de Curso e com o Relacionamento
do Curso com o Professor. Ns podemos identificar trs classes entidade: Curso, OfertaCurso
e InformaoProfessor.
Iremos adicionar uma classe de controle para manusear o fluxo de eventos para o caso de uso.
Esta classe chamada ControleCursoProfessor. As classes identificadas foram adicionadas ao
modelo.
6.7. ATIVIDADE
Baseando-se no modelo de Caso de Uso abaixo, tente levantar as classes para o sistema de
Matrcula (MATRI).
24
7.1. APRESENTAO
Nesta aula ser visto como identificar as classes de um sistema usando os cartes CRC
baseada nos trs atributos principais de um objeto na fase de projeto: nome da classe, suas
responsabilidades e seus colaboradores.
O nome da classe deve descrever o objeto no contexto geral do ambiente. Deve-se
tomar um certo cuidado e gastar um pouco de tempo para escolher o conjunto certo de
palavras para descrever o objeto.
As responsabilidades devem identificar os problemas a serem resolvidos e no as
solues. Identificando-se os problemas fica fcil escolher entre as solues possveis.
Novamente deve-se tomar cuidado com o conjunto de palavras usadas. As frases
devem ser curtas e concisas.
Os colaboradores de um objeto so os objetos para os quais este ir enviar mensagens
a fim de satisfazer as suas responsabilidades.
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.
26
8.1. APRESENTAO
Nesta aula ser visto como identificar os atributos e as operaes das classes do sistema
Objeto
Um objeto uma construo de software que encapsula estado e comportamento,
atravs de propriedades (atributos) e operaes (mtodos);
Estado de um objeto: composto por suas propriedade e seus respectivos valores;
Comportamento: a maneira como o objeto reage quando o seu estado alterado ou
quando uma mensagem recebida.
CLASSES
Conjunto de objetos similares.
Estrutura de dados similares (propriedades);
27
Troca de Mensagens
Mecanismo atravs do qual os objetos se comunicam, invocando as operaes
desejadas;
Um objeto (Emissor) envia uma mensagem a outro (Receptor) que executar uma
tarefa;
Operaes (mtodos) so invocados atravs de mensagens.
Encapsulamento
No mostre as cartas de seu baralho
Objetivo: Ocultar do mundo externo ao objeto, os detalhes de implementao e
restringir o acesso aos propriedades e mtodos.
Vantagens:
Segurana no acesso ao objeto;
Melhor consistncia no estado interno, pois evita alteraes incorretas de
valores das propriedades.
28
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
Uma operao para que a bomba tenha esta responsabilidade -- como
29
Uma operao primitiva uma operao que pode ser implementada apenas
usando o que intrnseco, interno a classe
Todas as operaes de uma classe so tipicamente primitivas
Exemplos:
Adicione um item a um conjunto -- operao primitiva
Adicione quatro itens a um conjunto -- no primitiva
Pode ser implementada com mltiplas chamadas a operao adicione um item a um conjunto
Assinatura da Operao
Mostrando Atributos
8.5. ENCAPSULAMENTO
Exemplo: Encapsulamento
31
Benefcios do Encapsulamento
8.6. ATIVIDADE
9.1. APRESENTAO
Nesta aula iremos abordar e exercitar o que so associaes entre classes e como us-las.
Iremos abordar aspectos como: associaes, nomes, papeis, multiplicidade, qualificadores,
navegabilidade e associaes reflexivas.
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
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
Muitos
*
Exatamente Um
1
Zero or mais
0..*
Um ou Mais
1..*
Zero or um
0..1
Intervalo Especfico
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?
Um curso pode ter dois professores?
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
capacidade de cada vago de carga em metros cbicos.
36
Cada trem possui uma rota que deve ser seguida durante a viagem.
A data de incio de trabalho de cada vago deve ser registrada.
A velocidade do trem deve ser controlada automaticamente. Ao arrancar ele dever
estar ganhando velocidade, e ao logo da viagem dever manter outra velocidade e
estando a uma determinada distncia da estao dever reduzir a velocidade para
parar.
Os segmentos de trilho iniciam e terminam em um determinado quilmetro.
A localizao do trem numa ferrovia deve ser possvel.
37
10.1. APRESENTAO
Nesta aula iremos abordar e exercitar o que so agregaes entre classes e como us-las.
Iremos abordar aspectos como: agregaes, composies, associaes reflexivas, classes de
ligao e as diferenas entre associaes e agregaes.
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>> <<limite>>
FormularioDeMatrcula FormularioDeHorrio
1 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..*
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
Curso
0..*
Pr-requisito 0..*
ParteDeProduto
0..*
Ns desejamos rastrear todas as notas que um estudante teve em todos os cursos que fez
O relacionamento entre Estudante e Curso um relacionamento muitos-para-muitos
Onde colocamos o atributo nota?
Estudante Curso
0..*
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
3-10
Boletim
Estudante 1 Curso
nota 3-10
Estudante 1 Curso
3-10
nota
<<limite>> <<limite>>
FormularioDeMatrcula FormularioDeHorario
1 1
1
FormularioDeHorario e
GerenteDeMatrcula
so independentes
1
GerenteDeMatrcula
10.6. ATIVIDADE
Faa um Diagrama de Classes para um problema com as seguintes caractersticas:
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
InfoRegistroUsurio
Superclasse
Relacionamento de Generalizao
InfoEstudante
Subclasse
O que Herdado?
Uma subclasse herda de seus pais:
Atributos
Operaes
Relacionamentos
Uma subclasse pode:
Incluir atributos, operaes e relacionamentos adicionais
Redefinir as operaes herdadas (use com cautela!)
42
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
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
Identificar similaridades de estrutura/comportamento entre vrias classes
Criar uma superclasse para reunir a estrutura/comportamento comum
As classes originais passam a ser subclasses da nova superclasse
Superclasses so mais abstratas que suas subclasses
Exemplo de Generalizao
43
Bens
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
CoisaQueVoa Animal
herana
mltipla
Encontrando generalizao
importante avaliar todas as classes para encontrar possveis generalizaes
Procure por comportamento comum (operaes) e estado comum (atributos) nas
classes
Tcnica de adio
Adicione novas operaes/atributos na(s) subclasse(s)
Tcnica de modificao
Redefina operaes
Deve ser feito com cuidado para no alterar a semntica
Generalizao Agregao
11.4. ATIVIDADE
Construa um Diagrama de Classes inicial para controlar emprstimos e reservas de
publicaes em uma biblioteca, considerando o seguinte:
12.1. APRESENTAO
Nesta aula iremos abordar e exercitar o que so Intefaces e pacotes.
12.2. INTERFACES
Uma Interface uma coleo de operaes utilizadas para especificar um servio de uma
classe ou componente.
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.
46
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:
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.
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:
13.1. APRESENTAO
Nesta aula iremos abordar e exercitar que o modelo de classes tem com a codificao em java
e com o modelo relacional.
classProduto{
privateStringnome;
privateStringdescricao;
protecteddoublepreco;
publicvoidsetNome(StringumNome){}
publicStringgetNome(){returnnull;}
staticpublicVectorgetAll(){returnnull;}
}
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:
50
publicclassItemdePedido
{
privateintquantidade;
privateEspecificacaoProdutoproduto;
}
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:
publicclassItemDePedido
{
privateintquantidade;
privateintcodProduto;
}
publicclassMatricula
{
privateAlunoaluno;
privateTurmaturma;
}
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;
publicclassPedido
{
privateDatedata;
privateStringcodPedido;
privatebooleancompleto;
51
privateVectortodosItens;
}
Associao 1:N
Define-se uma tabela por classe acrescentando-se os atributos identificadores de cada classe
respectiva tabela. A figura abaixo ilustra a situao tratada:
Associao M:N
Define-se uma tabela por classe acrescentando-se os atributos identificadores de cada classe
respectiva tabela. Neste caso, necessria a criao de uma tabela auxiliar para indicar as
associaes entre os objetos. A figura abaixo ilustra a situao tratada:
Herana
Identificam-se quatro formas para o mapeamento das heranas. So elas:
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.
14.1. APRESENTAO
PASSOS:
s d e x e m p lo 0 1
:I n t U s u a r i o :C t r lC a d C lie n t e :C lie n t e
U s u a r io
C lie n t e : = m o s t r a T e la C a d C lie n t e ( )
f o r m u l r io c lie n t e
d a d o s C lie n t e
s e tN o m e ( n o m e )
s e tC N P J ( c n p j)
s d e x e m p lo 0 4
:C la s s e A :C la s s e B :C la s s e C
n u m e r o : = v e r if ic a N o m e ( n o m e )
[ n u m e r o = 0 ] : c o d ig o N u lo : = g e r a c o d ig o N u lo ( )
a lt s e tN o m e (n o m e )
[n u m e ro < = 3 ] c o d ig o : = c a lc u la C o d ig o ( n o m e )
[n u m e ro > 3 ] n o m e := g e tN o m e ( )
c) Repeties (loops):
representados direto na mensagem ou atravs de fragmentos combinados (UML 2.0)
s d e x e m p lo 0 5
:C t r lP e d id o :T ic k e t B D :C o n t a
:P e d i d o
c r ia r ( )
r e c u p e r a r s t a t u s d e c lie n t e e x is t e n t e
lo o p
[ p r o x im o it e m ] re s e rv a r(c o n ta g e m ,d a te )
a lt
a d ic io n a r ( a s s e n t o s )
[ d is p o n v e l]
[ n o d is p o n v e l]
r e je it a r ( )
d e b it a r ( c u s t o )
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:
15.1. APRESENTAO
Construindo e implementando diagramas de sequncia em java com jsp e servlet de controle
15.2. DESENVOLVIMENTO
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>>.
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;
Primeiro vamos colocar as instncias (objetos) das classes identificadas acima no diagrama:
lim it e c o n t r o le e n t id a d e lim it e
:I n t A d m in i s t r a d o r :C t r l C a d a s t r a r P r o d u t o :P r o d u t o :R e p o s it o r io
: A d m in is t r a d o r :S G B D
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.
lim it e c o n t r o le e n t id a d e lim it e
:In t A d m in is t r a d o r :C t r lC a d a s t r a r P r o d u t o :P r o d u t o :R e p o s it o r io
: A d m in is t r a d o r :S G B D
o p c a o := m o s tra M e n u ()
m enu
c a d a s tra r p ro d u to
p r o d u to := te la C a d a s tr o P r o d u to ( )
t e la c a d a s t r o p r o d u t o
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;
lim it e c o n t r o le e n t id a d e lim it e
:I n t A d m in i s t r a d o r :C t r l C a d a s t r a r P r o d u t o :P r o d u t o :R e p o s it o r io
: A d m in is t r a d o r :S G B D
o p c a o := m o s tra M e n u ( )
m enu
c a d a s tra r p ro d u to
p r o d u t o : = t e la C a d a s t r o P r o d u t o ( )
t e la c a d a s t r o p r o d u t o
d a d o s d o p ro d u to
s e t D a d o s ( v a lo r , c o d ig o , d e s c r ic a o , n o m e )
c o n f ir m a c a o : = p e d e C o n f ir m a c a o ( p r o d u t o )
d a d o s d o p r o d u to d a d o s P ro d u to := g e tD a d o s ()
lim it e c o n t r o le e n t id a d e lim it e
:In t A d m in is t r a d o r :C t r lC a d a s t r a r P r o d u t o :P r o d u t o :R e p o s it o r io
: A d m in is t r a d o r :S G B D
o p c a o := m o s tra M e n u ()
m enu
c a d a s tra r p ro d u to
p r o d u t o : = t e la C a d a s t r o P r o d u t o ( )
t e la c a d a s t r o p r o d u t o
d a d o s d o p ro d u to
s e t D a d o s ( v a lo r , c o d ig o , d e s c r ic a o , n o m e )
c o n f ir m a c a o : = p e d e C o n f ir m a c a o ( p r o d u t o )
d a d o s d o p ro d u to d a d o s P ro d u to := g e tD a d o s ()
c o n f ir m a c a o
g ra v o u := g ra v a P ro d u to (p ro d u to )
d a d o s P ro d u to := g e tD a d o s ()
a lt in s e r e d a d o s
m o s tra M e n s a g e m (m e n s a g e m S u c e s s o )
[g ra v o u ]
P ro d u to g r a v a d o
15.3. ATIVIDADE
16.1. APRESENTAO
Estados:
Transies
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:
62
16.3. ATIVIDADE
17.1. APRESENTAO
Notao:
Os componentes podem ser arquivos de propriedades, arquivos fonte, arquivos html, jsp e at
mesmo bibliotecas que precisam ser instaladas.
64
Exemplo:
17.4. ATIVIDADE
Faa um diagrama de implantao para o problema do sistema de Matrculas
66
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.
RUMBAUGH, J.; JACOBSON, I.; BOOCH, G.. The unified modeling language reference
manual. 2a. ed. Reading, Massachusetts, EUA: Addison-Wesley, 2004.