1
MODELAGEM COM A UML (UNIFIED MODELING LANGUAGE)
BREVE HISTÓRICO
CARACTERÍSTICAS
CONCEITOS DE PROGRAMAÇÃO ORIENTADA A OBJETOS
MODELAGEM DE ANÁLISE E DE PROJETO
2
I . BREVE HISTÓRICO
Em fi ns dos anos 80 e início dos anos 90 vários métodos orientados a objetos surgiram, entre eles os métodos de Grady Booch, J im Rumbaugh (OMT) e I var J acobson. A UML foi uma tentativa de unificar as notações destes três métodos. Foi concebida por esses profissionais. A idéia era produzir um padrão, com as melhores práticas adotadas pela indústria, levando mais desenvolvedores a modelar seus sistemas de sof tware antes de construí-los.
14
I I . CARACTERÍSTICAS A UML não é um método e pode ser utilizada por
dif erentes processos de desenvolvimento de sof tware A UML foi reconhecida pelo OMG (Object Management
Group) como uma linguagem de modelagem padrão. (OMG – uma associação aberta que desenvolve e mantém especificações utilizadas pela indústria da computação) Obtenha a especificação da UML em http://www.omg.org A UML utiliza conceitos de orientação a objetos.
15
17
Finalidades do UML
-Visualizar
-Especificar
-Construir
-Documentar
18
Elementos do UML
-Itens
-Relacionamentos
-Diagramas
19
Itens do UML
-Estruturais-Comportamentais-Agrupamento-Anotacionais
20
Itens Estruturais do UML (parte estática)
-Classes (conjunto de objetos com caract. Comuns)-Interface (serviços de uma classe ou componente)-Colaborações (comportamento colaborativo)-Caso de Uso (sequência de ações)-Classes Ativas (objetos com threads)-Componentes (pacotes físicos de elementos lógicos)-Nó (recurso computacional)
21
Itens Comportamentais do UML (parte dinâmica)
-Interação (intercâmbio de dados)-Máquina de Estados
-Estados-Transições-Eventos-Atividades
22
Itens de Agrupamento do UML (organizacional)
-Pacotes
23
Itens Anotacionais do UML (explicativo)
-Nota
24
Relacionamentos do UML
-Dependência (relacionamento semântico de dois itens)
-Associação (relacionamento estrutural)
-Generalização (hierarquia)
-Realização (contrato de uma das partes)
25
Diagramas do UML
-Classes-Objetos-Casos de Uso-Sequência-Colaborações-Gráfico de Estados-Atividades-Componentes-Implantação
26
Na programação orientada a objetos os dados a serem processados e os mecanismos de processamento destes dados devem ser analisados em conjunto.
Assim, programadores que utilizam o paradigma de
programação orientada a objetos criam e usam objetos.
Na abordagem orientada a objetos os dados são
subdivididos em objetos
III. CONCEITOS DE PROGRAMAÇÃO ORIENTADA A OBJETOS
27
Cada objeto tem sua própria identidade. Assim, dois
livros, no sistema de venda de livros, por mais semelhanças que contenham constituem cada um, um único objeto
Objetos com a mesma estrutura de dados (atributos),
com o mesmo comportamento (operações) e relacionamentos são agrupados numa classe
Assim, uma classe Livro descreve o que é comum em
todos os livros no contexto de um determinado sistema.
28
Devemos pensar em um objeto como algo que tem
responsabilidades. Objetos devem ser responsáveis por si mesmos e ter essas responsabilidades claramente defi nidas.
No nível conceitual um objeto deveria ser pensado
desta f orma: um objeto é um conjunto de responsabilidades.
29
Como os objetos têm responsabilidades e são
responsáveis por si próprios, deve haver um modo de informá-los sobre o que devem fazer.
Objetos dispõem de dados para informá-los sobre si
mesmos e métodos para implementar f uncionalidades.
Alguns desses métodos podem ser invocados por
outros objetos. A coleção desses métodos é denominada interf ace pública do objeto.
30
Comparando com a Progr. Orientada a Procedimentos: Na Progr. Orientada a Procedimentos é identificada a
taref a a ser realizada e através de refi namentos sucessivos, quebra-se essa taref a em subtarefas menores, e estas em subtarefas ainda mais simples até que estas subtarefas estejam simples o suficiente para que possam ser implementadas.
Após a implementação destas tarefas elas costumam
ser combinadas para f ormar procedimentos mais complexos.
31
Na Programação Orientada a Objetos há três conceitos f undamentais:
Encapsulamento ou Ocultação de inf ormação
Herança
Polimorfismo
32
Encapsulamento ou Ocultação de I nformação
Encapsulamento consiste na separação dos aspectos externos de um objeto, acessíveis por outros objetos, dos detalhes internos da implementação daquele objeto, que ficam ocultos dos demais objetos.
Pode-se desejar modificar a implementação de um
objeto para melhorar o desempenho ou retirar um erro, dentre outros motivos. O encapsulamento f acilita a realização dessas alterações, já que a implementação de um objeto pode ser modificada sem que isso af ete as aplicações que o utilizam.
33
Na orientação a objetos um objeto encapsula dados,
operações, outros objetos, constantes e outras informações.
A idéia é que os usuários desse objeto possam
acessá-lo através de um conjunto de interfaces cuidadosamente documentadas, controladas e padronizadas.
Através do envio de mensagens pode-se solicitar a
esses objetos que façam algo. Por exemplo pode-se enviar a um objeto livro uma mensagem de atualização de preço. Objetos são responsáveis por f ornecer informações sobre si mesmos.
34
C++, por exemplo, permite a restrição ao acesso a campos e
métodos em classes por intermédio de quatro modificadores de acesso: public, private, protected e sem modificador.
o Public: o campo ou método declarado com este modificador pode ser acessado ou executado a partir de qualquer outra classe.
o Private: o campo ou método declarado com este modificador
só pode ser acessado, modifi cado ou executado por métodos da mesma classe.
o Protected: funciona como o modificador private, exceto que
classes herdeiras ou derivadas também terão acesso ao campo ou método com este modifi cador.
35
Herança
O mecanismo de herança é apropriado para relações “é um tipo de” entre classes.
A herança permite que uma classe herde atributos e
comportamento de outra.
36
Considere que em um sistema de controle de consultas
médicas dois tipos de pagamento podem ser realizados em uma consulta: através de convênio ou particular
Todos os pagamentos estão relacionados a uma consulta mas
só o pagamento de convênio está relacionado ao convênio correspondente. J á no caso de pagamento particular, deverá ser anotado como foi realizado o pagamento (dinheiro, cheque).
Usando o mecanismo de herança, podemos declarar as
classes PagamentoConvenio e PagamentoParticular como sendo um tipo de Pagamento. Assim: - PagamentoConvenio e PagamentoParticular herdam todos
os campos e métodos da classe Pagamento. - A classe herdeira poderá acrescentar campos e métodos à
classe original.
37
Herança Múltipla
I maginar a seguinte situação: o Personagem
Sof rem transformação espacial Recebem mensagens
38
Problemas da Herança Múltipla
Ambigüidade (confl itos de métodos e atributos) Topologia (diamond shape / herança virtual)
o Ex. Mover veículos Problemas de Arquitetura
39
Polimorfismo Através do polimorfi smo é possível se referir a
dif erentes derivações de uma classe do mesmo modo, obtendo no entanto o comportamento da classe derivada a que se está referindo.
Podemos, por exemplo, escreve um método que receba
uma instância da classe ObjetoGeometrico e ele é capaz de processar instâncias de qualquer classe que seja sua herdeira, como Retângulo ou Círculo.
40
Ex: Suponha que temos um método imprimir que recebe um
uma instância da classe ObjetoGeometrico e calcula a área do objeto e imprime o valor obtido.
Em tempo de execução poderá ser processada uma
instância de um retângulo ou de círculo. Mas no código é f eita uma ref erência a uma instância de ObjetoGeometrico.
41
Como já estudamos na 1ª parte do curso, podemos construir os modelos de análise e projeto. Vamos estudar a UML aprendendo como elaborar esses dois modelos.
IV. MODELAGEM DE ANÁLISE E DE PROJETO
42
MODELO DE ANÁLISE De acordo com a abordagem de Pressman o modelo de análise é construído na Elaboração, atividade da Engenharia de Requisitos, a partir das inf ormações obtidas nas atividades de Concepção e Levantamento de requisitos. Nessas duas atividades é elaborado o diagrama de casos de uso.
43
Para elaborar o modelo de análise de acordo com a abordagem orientada a objetos, utilizando a UML, vamos estudar os seguintes diagramas:
diagrama de casos de uso diagrama de classes diagrama de packages diagrama de estados diagrama de atividades diagrama de seqüência.
44
MODELO DE PROJ ETO
O modelo de projeto inclui representações de dados, arquitetura, interf ace, componentes e implantação Este modelo é o principal produto produzido
durante o projeto de sof tware.
Rational Rose
Ambiente Rational Rose
Visões de Modelo
Use Case View – Modelos de Análise
Logical View – Modelos de Projeto
Component View – Modelos de Implementação
Modelo de Análise
Diagrama de packagesDiagrama de casos de usoDiagrama de classesDiagrama de estadosDiagrama de atividadesDiagrama de sequência
Diagrama de Packages
Sistema Livraria – Packages
Diagrama de Casos de Uso
Diagrama de Casos de Uso
Especificação e Documentação Caso de uso: Faz Pedido
Faz pedido para presentear
Valida pedido
Faz Pedido
Solicita cancelamento de Pedido
Diminui quantidade de um item do pedido
<<include>>
Paga f atura
Solicita cancelamento de f atura
Cliente
Comunica atraso no pagamento
Av alia cancelamento de f atura
Gerente
Fatura pedido
Funcionário
Comunica atraso
(v erif icação de itens pendentes)
<<extend>>
<<include>>
Controle de Pedidos - Diagrama de Casos de Uso
Diagrama de Classes
Diagrama de Classes
itemFaturado
/ quantFaturada
(from Logical View)
Se uma f atura atende a um pedido, necessariamente os itens pedidos ligados à f atura dev em ser do pedido ao qual a f atura está relacionada.
Cliente
nomecpfCódigoendereçotelefoneEmailname
(from Logical View)Pedido
numPedidodataEmissãonomePresenteadoendereçoEntregadataCancelamentostatus
(from Logical View)
1..n1 1..n1
Faz
Fatura
numFaturadataEmissãodataVencimentovalorPagodataPagamentodataPedidoCancelamentodataCancelamentostatus
(from Logical View)
1
0..n
1
0..n
Livro
isbntítulodescriçãoquantEstoquepreçoprazoMédioEntrega
(from Logical View)
ItemPedido
quantidadePedidapreçoCobrado
(from Logical View)
1..n
0..n
1..n
0..n
1
0..n
1
0..n
Controle de Pedidos - Diagrama de Classes
Diagrama de Estados
Diagrama de Estados
Diagrama de Estados Classe Pedido
Cliente paga fatura[ todas as faturas foram pagas ]
Pedido cancelado
Pedido criado
Pedido fechado
Pedido totalmente atendido
Pedido parcialmente atendido
Pedido com solicitação de cancelamento
Cliente solicita cancelamento de pedido
Funcionário fatura pedido[ Funcionário fatura pedido ]
Funcionário fatura pedido[ não foram enviados todos os l ivros ]
Funcionário fatura pedido[ não foram enviados todos os l ivros ]
Cliente solicita cancelamento de faturaCliente solicita cancelamento de fatura
Gerente avalia cancelamento de fatura[ foram enviados todos os l ivros e há fatura não paga ]
Gerente avalia cancelamento de fatura[ há faturas a serem avaliadas ]
Gerente avalia cancelamento de fatura[ há l ivros a enviar ]
Gerente avalia cancelamento de fatura[ o cancelamento é aprovado, foram enviados todos os livros e já tinham sido pagas as demais faturas ]
Gerente avalia cancelamento de fatura[ canceladas todas as faturas ]
Diagrama de Atividades
Diagrama de atividades Caso de uso: Solicita cancelamento de fatura
Informa se deseja confirmar
Informa o número da fatura Valida número
da fatura
fatura existe?
Comunica ao cliente que fatura não foi encontrada
[ não ]
Apresenta dados da fatura: número, data, emissão, status e valor pago
[ sim ]
verifica se solicitação já foi realizada
Solicitação já realizada?
Solicita confirmação
[ não ]
Comunica que a solicitação já foi realizada e informa a data...
[ sim ]
Comunica que não foi realizada a operação
Armazena a solicitação de cancelamento e a data da solicitação
Cliente confirmou?
[ sim ][ não ]
Informa que o pedido só será analisado após a devolução dos livros
SistemaCliente
Diagrama de Sequência
Diagrama de Sequência
Diagrama de Sequência - Cenário:
Cliente solicita cancelamento de fatura válida Cliente : Cliente Sistema
1: Mostra janela inicial
2: Informa fatura
3: Verifica fatura
4: Apresenta dados da fatura
5: Solicita confirmação
6: Confirma
8: Informa que o pedido só será analisado após a devolução dos livros
7: Armazena a solicitação e dados
Modelo de Projeto
Casos de Uso real
Diagrama de Sequência
Projeto Lógico de Banco de Dados
Caso de Uso Real
Caso de Uso RealSolicita cancelamento de fatura real
Diagrama de Classes para Caso de Uso Real
Diagrama de Classes: solicita cancelamento de fatura
Fatura_Proj
numFatura : intdataEmissao : java.util.DatedataVencimento : java.uti l.DatevalorPago : doubledataPagamento : java.util.DatedataPedidoCancelamento : java.uti l.Datestatus : StringnumPedido : int
recuperarPelaPK(numFatura : int) : Fatura_Projsol icitarCancelamento() : Void
(from Logical View)
ControladorDePedidos
obterFatura(numero : int) : Fatura_ProjcadastrarSolCancFatura(umaFatura : Fatura_Proj) : String
(from Logical View)JanelaSolicCancFatura
exibir() : void
(from Logical View)
JanelaPrincipal
main(args : String[]) : Void
(from Logical View)
FaturaNaoEncontradaExcepition(from Logical View)
SolicitacaoDeCancelamentoJaEfetuadoExcepition(from Logical View)
Conexao
conn : Connection = null(from Logical View)
Diagrama de Sequênciasolicita cancelamento de fatura
Cliente : Cliente
Janelaprincipal : JanelaPrincipal
JanelasolicCancFatura : JanelaSolicCancFatura
ControladorDePedidos : ControladorDePedidos
Fatura_Proj : Fatura_Proj
Conexao : Conexao
1: Apresenta menu
2: Seleciona opçao solicita cancelamento
3: exibir( )
4: Solicita numFatura
5: Informa numFatura6: numFatura = ControladorDePedidos.obterFatura(numFatura)
7: umaFatura = Fatura_Proj.recuperarPelaPK(numFatura)8: Conexao.getConexao()
9: umaFatura.getDataEmissao()
10: umaFatira.getStatus()
11: umaFatura.getValorPago()
12: apresenta dados da Fatura e pede confirmação de cancelamento
13: Confirma cancelamento
14: ControladorDePedidos.cadastrarSolCancFatura(umaFatura)
15: umaFatura.solicitaCancelamento()
16: Conexao.getConexao()17: confirma o cadastramento da solicitação e pede a devolução dos livros
Projeto Lógico de Banco de Dados
Criação de tabelas relacionais através do add-in Oracle8
Criação de tabelas relacionais através do add-in Data Modeler
Tabela Relacional no Oracle
Tabela Relacional no Oracle
Tabela Relacional no Oracle
Criando Chave primária eChave estrangeira
Primary Key Foreign Key
Diagrama do Projeto Lógico de Banco de Dados
Diagrama do Projeto Lógico de Banco de Dados
<<FK>>
LIVROS
ISBN : VARCHAR2TITULO : VARCHAR2DESCRICAO : VARCHAR2QUANT_ESTOQUE : NUMBERPRECO : NUMBERPRAZO_MEDIO_ENTREGA : NUMBERLIVRO_PK = ISBN
<<RelationalTable>>
CLIENTE
ID : VARCHAR2CPF : VARCHAR2NOME : VARCHAR2ENDERECO : VARCHAR2TELEFONE : NUMBEREMAIL : VARCHAR2CLIENTE_PK = ID
<<RelationalTable>>
ITEM_PEDIDO
NUM_ITEM : NUMBERQUANT_PEDIDA : NUMBERPRECO_COBRADO : NUMBERITEM_PEDIDO_PK = ID_PEDIDO,NUM_ITEM
<<RelationalTable>>
ID_LIVRO = ISBNID_LIVRO = ISBN
ITEMPED_LIVRO_FK
<<FK>>
PEDIDO
ID : VARCHAR2DT_EMISSAO : DATENOME_PRESENTEADO : VARCHAR2ENDERECO_ENTREGA : VARCHAR2DT_CANCELAMENTO : DATESTATUS : VARCHAR2PEDIDO_PK = ID
<<RelationalTable>>
IDCLIENTE = IDIDCLIENTE = ID
PEDIDO_CLIENTE_FK
ID_PEDIDO = IDID_PEDIDO = ID
ITEMPED_PEDIDO_FK
<<FK>>
ITEM_FATURADO
QUANT_FATURADA : NUMBERITEM_FATURADO_PK = ID_FATURA,ID_ITEM,ID_PEDIDO
<<RelationalTable>>
ID_ITEM = NUM_ITEMID_PEDIDO = ID
ID_ITEM = NUM_ITEMID_PEDIDO = ID
ITEMFAT_ITEMPED_FK
<<FK>>
FATURA
ID : VARCHAR2DT_EMISSAO : DATEDT_VENCIMENTO : DATEVALOR_PAGO : NUMBERDT_PAGAMENTO : DATEDT_PEDIDO_CANCELADO : DATEDT_CANCELAMENTO : DATESTATUS : VARCHAR2FATURA_PK = ID
<<RelationalTable>>
ID_PEDIDO = IDID_PEDIDO = ID
FATURA_PEDIDO_FK
<<FK>>
ID_FATURA = IDID_FATURA = ID
ITEMFAT_FATURA_FK
<<FK>>
Tabela Relacional no Data Modeler
Criando Database
Tabela Relacional no Data Modeler
Criando Schema
Criando Tabela no Data Modeler
Tabelas no Data Modeler
Tabelas no Data Modeler
Atributos Chaves Primárias e Estrangeiras
Criando Relacionamentos (Chaves Estrangeiras) entre tabelas
Neste exemplo, este relacionamento identifica Foreign Key
Diagrama com Data Modeler
ITEM_PEDIDO
NUM_ITEM : NUMBER(7, 0)QUANT_PEDIDA : NUMBER(9, 0)PRECO_COBRADO : NUMBER(9, 2)PEDIDO_ID : NUMBER(7, 0)LIVRO_ID : NUMBER(7, 0)
<<PK>> PK_ITEM_PEDIDO()<<FK>> ITEMPED_PEDIDO_FK()<<FK>> ITEMPED_LIVRO_FK()
CLIENTE
ID : NUMBER(7, 0)CPF : VARCHAR2(20)NOME : VARCHAR2(50)ENDERECO : VARCHAR2(50)TELEFONE : VARCHAR2(20)EMAIL : VARCHAR2(50)
<<PK>> PK_CLIENTE()
LIVRO
ISBN : NUMBER(7, 0)TITULO : VARCHAR2(50)DESCRICAO : VARCHAR2(1000)QUANT_ESTOQUE : NUMBER(9, 0)PRECO : NUMBER(9, 2)PRAZO_MEDIO_ENTREGA : NUMBER(9, 0)
<<PK>> PK_LIVRO()
PEDIDO
ID : NUMBER(7, 0)DT_EMISSAO : DATENOME_PRESENTEADO : VARCHAR2(50)ENDERECO_ENTREGA : VARCHAR2(50)DT_CANCELAMENTO : DATESTATUS : CHAR(1)CLIENTE_ID : NUMBER(7, 0)
<<PK>> PK_PEDIDO()<<FK>> PEDIDO_CLIENTE_FK()
0..*1 0..*1
PEDIDO_CLIENTE_FK
FATURA
ID : NUMBER(7, 0)DT_EMISSAO : DATEDT_VENCIMENTO : DATEVALOR_PAGO : NUMBER(9, 2)DT_PAGAMENTO : DATEDT_PEDIDO_CANCELAMENTO : DATEDT_CANCELAMENTO : DATESTATUS : CHAR(1)PEDIDO_ID : NUMBER(7, 0)
<<PK>> PK_FATURA()<<FK>> FATURA_PEDIDO_FK()
0..*
1
0..*
1
FATURA_PEDIDO_FK
ITEM_FATURADO
QUANT_FATURADA : NUMBER(9, 0)FATURA_ID : NUMBER(7, 0)ITEM_ID : NUMBER(7, 0)PEDIDO_ID : NUMBER(7, 0)
<<FK>> ITEMFAT_FATURA_FK()<<FK>> ITEMFAT_ITEMPED_FK()<<PK>> PK_ITEM_FATURADO()
0..*
1
0..*
1
ITEMFAT_FATURA_FK
0..*
1
0..*
1
ITEMPED_LIVRO_FK
0..*
1
0..*
1
ITEMPED_PEDIDO_FK
0..*
1
0..*
1ITEMFAT_ITEMPED_FK
Geração de código no Rational Rose
Aplicado às classes do Modelo de Projeto
Linguagem: Java (nos exemplos)
Configurando Pastas
Configurando Pastas
Escolher pasta a ser associada aos arquivos de código.
Configurações para Java
Tools > OptionsNeste tipo “Class” pode-se alterar alguns métodos de criação automática do Rose como construtores, finalizadores, etc.
Configurações para Java
Nesta tipo “Attribute” pode-se permitir ao Rose gerar automaticamente os métodos públicos get/set.
Checando Sintaxe
Gerando código para uma Classe
Gerando código para Várias Classes
Associando a pasta
O arquivo .java será associado a uma pasta.
Editando o código gerado
Geração de Script SQL
Aplicado as tabelas relacionais criadas com o add-in Oracle8
Aplicado as tabelas relacionais criadas com o add-in Data Modeler
Geração de Script SQL com Oracle8
Escolhendo tabelas e checando sintaxe (Oracle8)
Visualização do Script (Oracle8)
Gerando Script SQL com Data Modeler
Visualização do Script (Data Modeler)
CREATE TABLE CLIENTE (ID NUMBER ( 7 ) NOT NULL,CPF VARCHAR2 ( 20 ) NOT NULL,NOME VARCHAR2 ( 50 ) NOT NULL,ENDERECO VARCHAR2 ( 50 ) NOT NULL,TELEFONE VARCHAR2 ( 20 ),EMAIL VARCHAR2 ( 50 ),CONSTRAINT PK_CLIENTE PRIMARY KEY (ID))
/CREATE TABLE PEDIDO (
ID NUMBER ( 7 ) NOT NULL,DT_EMISSAO DATE NOT NULL,NOME_PRESENTEADO VARCHAR2 ( 50 ),ENDERECO_ENTREGA VARCHAR2 ( 50 ) NOT NULL,DT_CANCELAMENTO DATE,STATUS CHAR ( 1 ) NOT NULL,CLIENTE_ID NUMBER ( 7 ) NOT NULL,CONSTRAINT PK_PEDIDO PRIMARY KEY (ID))
/ALTER TABLE PEDIDO ADD ( CONSTRAINT PEDIDO_CLIENTE_FK FOREIGN KEY (CLIENTE_ID)
REFERENCES CLIENTE (ID))/
CREATE TABLE FATURA (ID NUMBER ( 7 ) NOT NULL,DT_EMISSAO DATE NOT NULL,DT_VENCIMENTO DATE NOT NULL,VALOR_PAGO NUMBER ( 9, 2 ),DT_PAGAMENTO DATE,DT_PEDIDO_CANCELAMENTO DATE,DT_CANCELAMENTO DATE,STATUS CHAR ( 1 ) NOT NULL,PEDIDO_ID NUMBER ( 7 ) NOT NULL,CONSTRAINT PK_FATURA PRIMARY KEY (ID))
/ALTER TABLE FATURA ADD ( CONSTRAINT FATURA_PEDIDO_FK FOREIGN KEY
(PEDIDO_ID) REFERENCES PEDIDO (ID))/
.
.
.