MODELAGEM COM A UML (UNIFIED MODELING LANGUAGE)

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))/

.

.

.