u m l - cesarbt.xpg.com.br · – amplo uso da internet; – programas extensos; – filosofia de...

U M L

Cesar Bezerra Teixeira

28/01/05

2

Bibliografia

• “Desenvolvendo Aplicações com UML”Ana Cristina MeloEditora Brasiport

• “Guia de Consulta Rápida”Douglas Marcos da SilvaNovatec Editora

• www.rational.com• www.cmm.com

http://www.rational.com/

3

SUMÁRIO

CAP 0 - INTRODUÇÃOCAP I - CONCEITOS DE OOCAP II - VISÃO GERAL DA UMLCAP III - DIAGRAMAS DE CASO DE USOCAP IV - DIAGRAMA DE CLASSESCAP V - DIAGRAMA DE OBJETOSCAP VI - DIAGRAMAS DE INTERAÇÃOCAP VII - DIAGRAMA DE GRÁFICO DE ESTADOSCAP VIII - DIAGRAMA DE ATIVIDADESCAP IX - DIAGRAMAS DE IMPLEMENTAÇÃO

4

SUMÁRIO


5

Objetivo

“Situar a UML no processo histórico da Computação, mostrando que o

incremento da complexidade dos sistemas levou à necessidade de

métodos de Análise & Projeto, que se adequassem às novas exigências.”

6

Histórico

• Década de 40

– Hardware de elevado custo e simples;– Aplicações sem interface;– Programação em linguagem de máquina;– Ausência de Metodologia;– Grande quantidade de erros de programação;– Ênfase em algoritmos;

7

Histórico

• Início da Computação Digital:– Tecnologia de Alto Custo;– Só Governo poderia financiar o desenvolvimento;– Utilização militar do computador:

• Cálculos Balísticos;• Criptografia e Decriptografia;

– Item inacessível;

• Pesquisa em Hardware barateou custos;

8

Histórico

• Décadas de 50/60

– Confirmação do Computador comercialmente;– Redução de custo de hardware;– Aumento da complexidade dos programas;– Ênfase no armazenamento e processamento de dados;– Uso de linguagens de programação;– Especificação Estruturada;

9

Histórico

• Válvulas, transistores, CI ;

• Diminuição do custo do hardware:– Utilização por grandes empresas e universidades;– Pesquisa por linguagens de programação:

• COBOL;• FORTRAN;

– Necessidade de aumento de produtividade;– Início da utilização comercial dos computadores;

• Produção de Sistemas Corporativos;

10

Histórico• Década de 70

– Programas mais complexos;– Operações mais complexas com dados;– Introdução do PC;– Análise Estruturada;

11

Histórico

• Década de 80

– Constatação da necessidade de documentação de SW;– Constatação do custo do retrabalho em programação;– Análise Essencial;– Pesquisa do modelo CMM;– Início real da era da Informação;– Disseminação de redes de computadores;

12

Histórico

• Década de 90

– Orientação a objetos para o trato com a complexidade;– Programas extremamente complexos;– Necessidade de aumento de produtividade;– Uso de COTS, c/necessidade de programação constante;

13

Histórico

• Século XXI

– Computador como eletrodoméstico;– Empresas totalmente dependentes de computação;– Aplicações distribuídas;– Amplo uso da Internet;– Programas extensos;– Filosofia de componentes – Qualidade de SW;

14

Histórico

PESQUISA TECNOLÓGICA

UTILIZAÇÃO COMERCIAL

POPULARIZAÇÃO DO COMPUTADOR

15

Histórico• Etapas do emprego do computador:

– Empresa de processamento de dados;– CPD;– Uso do computador “quase” em cada mesa de trabalho;

• Metodologias:

– Ausência;– Especificação Funcional;– Análise Estuturada / Análise Essencial;– Paradigma OO;

16

Programa

ALGORITMOS ESTRUTURA DE DADOS

PROGRAMA

17

Histórico

• Evolução Tecnológica:

– Interface gráfica c/o usuário (GUI);– Multimídia;– Acesso a Bancos de dados;– Conectividade;– Programas mais complexos;

• Evolução Tecnológica = Programas mais complexos;

18

Programa Atual

ALGORITMOS

ACESSO A BD

ESTRUTURA DE DADOS INTERFACE CONECTIVIDADE

PROGRAMA

19

Histórico• A complexidade dos programas atuais:

– Linguagens com mais recursos;– Ferramentas de software;– Capacidade de conectividade;– Alto poder computacional;– Acesso a BD;– Usuários mais exigentes;

• OO visa:– tratar a complexidade;– Adaptar-se aos novos paradigmas;

• Produtividade Reutilização de componentes;

20

Conceitos Básicos• Enfoque OO:

– Modelagem próxima da realidade do usuário;– Baseia-se na interação dos objetos do mundo real; – O mundo é uma coletânea de objetos que interagem;

• Características dos Objetos:– atributos (qualificadores); e – métodos (operações).

21

Princípios Básicos da OO

• Não há controle central;

• Não há dados globais;

• Processamento descentralizado:

• Comunicação entre os objetos é feita por mensagens.

22

Princípios Básicos da OO

“OO é uma nova maneira de pensar os problemas utilizando modelos organizados a partir de conceitos

do mundo real. O componente fundamental é o objeto que combina estrutura e comportamento em

um única entidade". [Rumbaugh]

23

Benefícios da abordagem OO:

• Modelagem próxima ao funcionamento do mundo;

• Suave TransiçãoAnáliseProjetoImplementação;

• Não requer reorganização do modelo entre as fases;

• Favorece a reutilização;

• Facilitar a extensão.

24

Vantagens da Orientação a Objetos:

• Facilidade de Particionamento do sistema;

• Modelagem isolada de restrições de implementação;

• Clara fronteira entre físico e lógico;

• Redução do tempo de análise;

• Modelagem de dados e processos sincronizada;

25

SUMÁRIO


26

Paradigma Estruturado

FUNÇÕESFUNÇÕES

FUNÇÕESFUNÇÕES

DADOSDADOS

27

Paradigma OO

FUNÇÕESFUNÇÕESFUNÇÕESFUNÇÕES

DADOSDADOSDADOSDADOS

28

Paradigma OO

Nome: ___Nome: ___Tel: ______Tel: ______

[Salvar][Salvar]

Sistema.exeSistema.exe

Objeto XObjeto X

Nome, tel

MétodoobjetoX.Gravar()

Objeto YObjeto Y

OKMétodo

Y.Validar()OK

29

Capítulo I

1.1 – Paradigmas de Desenvolvimento de Sistemas;

1.2 – Linguagens OO;

1.3 – Principais Conceitos OO;

30

1.1 – Paradigmas de Desenvolvimento de Sistemas

• Primeiros sistemas desenvolvidos décadas de 40/50;

• Até década de 70:

– Aplicações de pequena dimensão;– Máquinas limitadas;– A&P sem formalismos e métodos;– Modelagem texto descritivo (novela);– Única ferramenta Fluxograma;– Passagem da Análise p/o Projeto de forma empírica;

• 1968 Crise do software

31

• 1968 Crise do software:

– Dijkstra escreve sobre programação estruturada;– Importância à complexidade dos sistemas;

• Marcos importantes até a década de 70:

– Codd escreveu o modelo relacional;– Niklaus Wirth desenvolveu o Pascal;– Kernighan & Ritchie desenvolvem a linguagem C;– Fundação da Microsoft;– Tom de Marco populariza a Análise Estruturada;– Ferramentas: DFD, DER

32

• Aumento da complexidade dos Sistemas:

– Necessidade de maior esmero na A&P;– Desenvolvimento de produtos de maior qualidade;– Buscar evitar o retrabalho;

• AE introduziu avanços, possuindo imperfeições:

– Dificuldade de migração Análise Projeto;– Dificuldade de migração Projeto Implementação;– Dificuldade de correção dos modelos gerados;– Ferramentas não ajudam comunicação usuários X projetistas;– Processos e dados são vistos de forma independente;

33

• Aplicações antigas eram menores, minimizando os problemas;

• Aplicações atuais extensas e complexas:

– Urgência;– Adaptabilidade a novas situações e tecnologias;– Necessidade de evolução contínua;

• Paradigma atual de desenvolvimento de SW:

– Gastar menos tempo de desenvolvimento;– Economia de hardware;– Oferecer algo mais Diferencial competitivo;

34

• Década de 70 Início do paradigma OO;

• OO procura:

– Usar os mesmos modelos para Análise, Projeto e Implementação;– Usar os principais diagramas em todas as fases;– Unificação da perspectiva de dados e funções;– Melhoria da comunicação usuários X desenvolvedores;– Minimizar surpresas no produto;

35

Dados

Métodos

OBJETO

Comparação de Linguagens Tradicionais e OO

Procedurex

Procedurey DADOS

Procedurez

Dados

Métodos

OBJETO

Dados

Métodos

OBJETO

36

1.2 – Principais linguagens OO

• Eifel;

• C++;

• Objective C;

• Object Pascal;

• Java;

37

1.3 – Conceitos OO

• Objeto;• Classe;• Encapsulamento;• Herança;• Polimorfismo

38

ObjetoÉ uma entidade tangível, que representa uma ocorrência específica (instância) de uma classe, e exibe um comportamento bem definido. Ele possui atributos, que são os seus dados e comportamentos, que são os seus processos. Estes comportamentos são ativados através de mensagens que são trocadas entre os objetos. Exemplo de objetos:

39

Objeto

“Um objeto é a abstração de elementos concretos ou abstratos, existentes no mundo real.”

Exemplos:Exemplos:

DisciplinaDisciplina

40

Objeto

• Um objeto é composto por:– Atributos (Características);– Operações (serviços);

Exemplos:Exemplos:

AutomóvelAutomóvel

ATRIBUTOS:

•Nº DE PORTAS = 2

•COR = VERMELHO

•ANO = 1990

•...

41

ClassesRepresentação de um conjunto de objetos que compartilham a mesma estrutura

Exemplo : Classe : Funcionário Objetos : Ciro, Marina, Paloma, Pedro

42

Classes

Objeto 2

representação

ClasseClasseAutomovelAutomovel

numeroPortasnumeroPortascorcorfabricantefabricanteanoanoplacaplaca

Objeto 1

43

Classes

• Ponto de partida p/a identificação de classes:

– Substantivos que aparecem numa definição de requisitos;– Podem ser objetos físicos (livros,...);– Verifica quais desses objetos tem relevância para o problema;

• Qualificação das Classes:

– Identificar requisitos mais importantes dos objetos relevantes;

• O processo é gradativo e incremental;

44

Encapsulamento• Usar o objeto sem conhecer seu conteúdo,apenas a interface;

• Encapsular significa ocultar:

– Estado do objeto;– Implementação de suas operações;– Um atributo só é modificado por operações;

• Vantagem de se utilizar o encapsulamento:

– Manutenções localizadas;

45

Encapsulamento

46

Herança• Herança de atributos e métodos pertencentes a uma classe existente;

• Permite a criação de classes complexas sem que seja necessário repetir o código, pois a nova classe herda seu nível base de características de um antepassado na hierarquia de classe.

• A estrutura de herança organiza as classes em relações de generalização e especialização, isto é, subclasses especializam uma classe e superclasses generalizam uma classe.

• Na superclasse ficam todos os atributos que são comuns as diversas subclasses, e qualquer alteração no atributo da superclasse reflete automaticamente nas subclasses.

47

Herança

FuncionárioFuncionário

herda deherda de

GerenteGerente

48

Polimorfismo• Permite a utilização da mesma operação entre classes genéricas e

específicas, porém com implementações (métodos) diferentes..

49

SUMÁRIO


50

Capítulo II

2.1 - Histórico da UML

2.2 - Conhecendo a UML

2.3 - Modelando com a UML

2.4 - Modelagem de Arquitetura

51

2.1 – Histórico da UML• Desde os primórdios da OO, apareceram vários métodos;

• A maior parte cometeu o erro de tentar estender o paradigma estruturado “Guerra dos Métodos”;

• A partir de 90 apareceram métodos realmente OO, ganhando cada um, uma fatia diferente do mercado;

• As tentativas de unificação foram infrutíferas;

• 1993 Métodos mais populares: Booch 93 / OMT-2 / OOSE;

52

• 1994 Início dos esforços para unificação na Rational:– James Rumbaugh (método OMT);– Grady Booch (método Booch);

• Out/95 Lançamento do Método Unificado, versão 0,8;– Jacobson junta-se à equipe (método OOSE);

• Jun/96 Lançamento da versão 0,9 da UML;

• Jan/97 Rational lança a versão 1.0 da UML;

• A evolução vem sendo contínua desde então;

53

2.2 – Conhecendo a UML• Os métodos normalmente compreendem:

– Linguagem de Modelagem (notação gráfica);e– Processo (passos p/elaboração de um projeto);

• A UML é só uma linguagem de modelagem, para:

– especificação, visualização, construção e documentação de artefatos (requisitos, arquitetura, projeto, código-fonte,...) de sistemas de software;

• A UML procura terminar c/as diferenças entre os métodos anteriores e unificar as perspectivas de modelagem de negócios e de software;

54

• Metas que a UML procura atingir:

– Prover à comunidade uma linguagem de modelagem visual;

– Possibilitar extensibilidade e mecanismos de especialização;

– Suportar especificações que são independentes de processos de desenvolvimento e linguagem de programação particulares;

– Prover uma base formal p/entendimento da linguagem de modelagem;

– Encorajar o crescimento do mercado de ferramentas de objetos;

– Suportar alto nível de conceitos de desenvolvimento como componentes, colaborações, estruturas e padrões;

– Integrar melhores práticas;

55

2.3 – Modelando com a UML

• Elementos do Modelo:

– Elementos Básicos do Modelo;

– Relacionamentos;

56

• Elementos Básicos do Modelo:– Estruturais:

• Classes;• Interfaces;• Colaborações;• Casos de uso;• Classes ativas (atividades de controle – thread);• Componentes;• Nós;

– Comportamentais:• Interação;• Estado;

– Agrupamento pacotes;– Anotacionais Notas;

57

• Relacionamentos:

– Dependência Indica que a mudança de um elemento afeta outro;

– Associação Envolve conexão entre instâncias;

– Generalização Elemento mais genérico e outro mais específico;

– Realização Relaciona uma especificação e sua implementação;

58

• Diagramas:

– Estáticos:

• Diagrama de Classes;• Diagrama de Objetos;• Diagrama de Componentes;• Diagrama de Implantação;

– Dinâmicos :

• Diagrama de Casos de Uso;• Diagrama de Seqüências;• Diagrama de Atividades;• Diagrama de Colaborações;• Diagrama de Gráficos de Estados;

59

2.4 – Modelagem de Arquitetura

VISÃO DE

PROJETO

VISÃO DE

IMPLEMENTAÇÃO

VISÃO DO

PROCESSO

VISÃO DA

IMPLANTAÇÃO

VISÃODE

CASOS DE USO

60

TOPOLOGIA DO SISTEMADISTRIBUIÇÃOFORNECIMENTOINSTALAÇÃO

IMPLANTAÇÃOINTERAÇÃOGRÁFICO DE ESTADOSATIVIDADES

NÓSVISÃO

DEIMPLANTAÇÃO

GERENCIAMENTO DA CONFIGURAÇÃO DAS VISÕESMONTAGEM DO SISTEMA

COMPONENTESINTERAÇÃOGRÁFICO DE ESTADOSATIVIDADES

COMPONENTESARQUIVOS

VISÃODE

IMPLEMENTAÇÃO

DESEMPENHOESCALABILIDADERENDIMENTO

CLASSESOBJETOSINTERAÇÃOGRÁFICO DE ESTADOSATIVIDADES

CLASSES ATIVASVISÃO

DOPROCESSO

VOCABULÁRIO DO SISTEMAFUNCIONALIDADE

CLASSESOBJETOSINTERAÇÃOGRÁFICO DE ESTADOSATIVIDADES

CLASSESINTERFACESCOLABORAÇÕES

VISÃODE

PROJETO

COMPORTAMENTODO

SISTEMA

CASOS DE USOINTERAÇÃOGRÁFICO DE ESTADOSATIVIDADES

CASOS DE USOVISÃO

DECASOS DE USO

ENFOQUEDIAGRAMASELEMENTOSVISÕES

61

Proposta de Processo

• Levantamento de Requisitos• Análise• Projeto• Implementação• Testes• Entrega• Manutenção

62

SUMÁRIO


63

Capítulo III

3.1 – Levantamento de Requisitos3.2 – O que é um caso de uso3.3 – Relacionamento entre Casos de Uso e Atores3.4 – Modelando requisitos com Casos de Uso3.5 – Criando o Diagrama de Casos de Uso3.6 – A Importância dos Protótipos3.7 – Estudo de caso

64

3.1 – Levantamento de Requisitos

• Não é uma tarefa fácil;

• A linguagem é cheia de ambigüidades;

• Importante o uso de uma boa técnica: brain-storming, JAD;

65

3.2 – O que é um caso de Uso

• Descreve uma seqüência de ações que representam um cenário principal (perfeito) e cenários alternativos, com o objetivo de demonstrar o funcionamento de um sistema (ou parte dele), através de interações com atores;

• O caso de uso deve descrever uma rotina bem definida do sistema e deve ser totalmente compreensível p/a equipe de desenvolvimento, quanto p/os clientes que detêm o conhecimento do domínio do sistema.

• Não existe na UML um padrão único para descrição de casos de uso;

66

Exemplo de Caso de Uso

Caso de Uso : Reserva de um Restaurante• Ator: Setor de Atendimento ao Cliente• Cenário Principal:

1. O Cliente informa ao atendente a data da reserva, que é repassada ao sistema;

2. O sistema mostra o mapa do salão do restaurante, indicando as mesas já reservadas e as que estão livres. O sistema calcula e exibe o número de reservas ainda disponíveis;

3. Um ou vários lugares disponíveis são escolhidos p/reserva;4. Um sistema solicita o CPF do cliente p/sua identificação no sistema. O

sistema pesquisa o cliente e mostra nome e telefones de contato, para confirmação;

5. Após confirmação, a reserva é efetuada em nome do cliente.

67

• Cenários Alternativos:

Alternativa: Data não disponível para reserva1a) O sistema verifica se p/a data informada, é possível efetuar

reservas. Caso negativo, uma nova data deve ser solicitada;

Alternativa: Reservas Esgotadas1a) O sistema verifica se para o dia informado, as reservas estão

esgotadas. O sistema deve possibilitar que seja informada nova data ou que se encerre a solicitação de reserva.

68

3.3 – Relacionamento entre casos de uso e atores

• Casos de Uso são conjuntos bem definidos de funcionalidades do sistema, que não podem trabalhar sozinhas no contexto, precisando se relacionar um c/os outros;

• Tipos de Relacionamentos:– Entre casos de Uso:

• Generalização;• Extensão;• Inclusão;

– Entre Atores Generalização;– Entre Atores e casos de uso Associação;

69

3.4 – Modelando requisitos com casos de uso

• Não existe ordem predefinida, dizendo que diagramas devem ser modelados primeiro (Casos de Uso ou Classes);

• Todos os casos de uso possuem um nome que os identifica;

• Dados um ator, descobrimos os casos de uso, fazendo vários questionamentos sobre ele;

• Após identificados os casos de uso, nos concentraremos em descrever os cenários principais;

• A partir dos cenários principais identificamos os alternativos;

70

3.5 – Criando o Diagrama de Casos de Uso

Reserva deRestaurante

Mostrar mapado salão

Cadastrar ClienteReserva

Criado em .....

“include”

“extend”Balcão

71

CadastrarFuncionário

Cadastrar Professor

Vendedor

Gerente

Generalização

72

Emitir resultadode provas

Lançar resultadode provas

Aluno

Secretaria

Fronteira do Sistema

Professor

73

Uso de Pacotes

CadastrarAluno

MatricularAluno

Secretaria

Controle Acadêmico

Emitir HistóricoEscolar

74

3.6 – A Importância dos Protótipos

• O Produto final é sempre distante dos requisitos do usuário;

• O uso de protótipos (+ RAD):

– Facilita o desenvolvimento;– Reduz custos;– Aproxima o sistema final da especificação;– Facilita o levantamento de requisitos;

75

3.7 – Estudo de Caso“Uma empresa especializada em montagem de concursos públicos, necessita de um sistema que controle todo o processo seletivo. O sistema necessita receber os seguinte dados do processo seletivo:

– Razão social da empresa;– Nº do edital do concurso;– Localidade de trabalho;– .....

O sistema fornece os seguinte produtos:– Lista de candidatos X locais de prova X nº de vagas;– Cartão de confirmação do candidato;– Gabarito oficial;– Resultado parcial e final;– Resultado financeiro;

76

• Com base na situação foram detectados os seguintes casos de uso:

– Cadastrar concurso;– Cadastrar Inscrição de Candidato;– .....– Alocar candidatos nos locais de prova;– Cadastrar gabarito oficial;– .....– Emitir listagem de candidatos x locais de prova;– ....– Emitir cartão de confirmação do candidato;– .....– Listar resultado final;

77

Cadastrar Concurso

• Objetivo:Realizar o cadastramento prévio dos dados de um novo concurso, preparando o sistema para receber inscrições dos candidatos;

• Ator:Departamento de Seleção (identificado como usuário)

• Cenário Principal:– Usuário cadastra razão social da empresa;– Usuário cadastra dados do concurso;– ........

• Cenário Alternativo:– Prova sem cadastro de local de prova;

79

SUMÁRIO


80

Capítulo 4 – Diagrama de Classes

4.1 – Conceitos Gerais

4.2 – Criando Diagramas de Classe

4.3 – Conceitos Avançados

4.4 – Modelando um Diagrama de Classes

4.5 – Estudo de Caso

81

4.1 – Conceitos Gerais

• Visibilidade Quem enxerga uma propriedade:

– Público;– Protegido;– Privado;

• Multiplicidade Cardinalidade de um relacionamento;

• Notas Informação textual;

82

4.2 – Criando Diagramas de Classe

Nome da Classe

Atributos

•Nome• ......

Operações

•Incluir ();• ........

Responsabilidades

•Controlar o acesso ......• ........

83

SISTEMA DE VENDAS “ON-LINE”

84

4.3 – Conceitos Avançados

• Classe de Associação:

Representa uma associação que possui propriedades de classe, tais como: atributos, operações e outras associações

CURSO DISCIPLINA

PERÍODO

•CARGA HORÁRIA PRÁTICA;

•CARGA HORÁRIA TEÓRICA

85

4.4 – Modelando um Diagrama de Classes

• Na Análise de Requisitos devemos nos preocupar em:

– Identificar as classes;

– Identificar os atributos das classes;

– Analisar os atributos, identificando aqueles que podem ser relacionamentos;

– Identificação preliminar de operações ;

– Identificação de classes semelhantes, identificando relacionamentos de herança;

– Lançamento de detalhes dos atributos;

86

4.5 – Estudo de Casos• Exemplo de classe do caso de realização de concursos:

CANDIDATOS À CLASSE CANDIDATOS À ATRIBUTOS

•EMPRESA;

•NR DO EDITAL;

•PERÍODO DE INSCRIÇÃO;

•MÍNIMO DE ACERTOS;

•LISTA DE CARGOS;

•STATUS

CONCURSO PÚBLICO

87

SUMÁRIO


88

Criando Diagrama de Objetos

• Consiste numa instância do Diagrama de Classes;• São úteis para modelar estruturas complexas de dados;• O relacionamento entre os objetos é feito através de links;• Um link é uma instância de uma associação, não mostram multiplicidades;

Nome do objeto : Nome da Classse

Descrição = “Saia”

Cor = “Azul”

Tamanho = 40

Preço = R$ 50,00

89

SUMÁRIO


90

Capítulo 6

6.1 – Diagrama de Seqüências

6.2 – Diagrama de Colaboração

6.3 – Modelando Diagramas de Seqüências

91

6.1 – Diagrama de Seqüências • Sua representação gráfica é baseada em 2 dimensões:

– Eixo Y msg trocadas no decorrer de um tempo de vida;– Eixo X Objetos participantes das insterações;

• As msg correspondem a chamadas de serviços dos objetos (ou seja suas operações);

Tela de Relatóriode Comissão Vendas Vendedor

GerenteRelatório de

comissão do Mês X

Relatório de Comissões

Total vendas (mês)

Lista de vendas

Nome do vendedor

*(Para cada vendedor)

92

C

A

D

A

S

T

R

A

R

C

L

I

E

N

T

E

93

6.2 – Diagrama de Colaboração

Curso X : Curso

Coordenador

Turma 1 : Turma

Disc 1 : Disciplina

2:(Para cada disciplina) Obter info da disciplina

1: Obter Grade ()

3: (Disciplina com pre-req.) Obter pre_requisito ()

4: Obter Turmas Ativas(Curso X)

94

6.3 – Modelando Diagrama de Seqüências

• O Diagrama de Seqüências pode ser desenhado de forma gradativa;

• Para cada mensagem surgida, verifica-se a existência de um objeto instanciado ou não, procedendo-se à sua criação, se necessário;

• O uso mais freqüente do DS é a representação de cenários de casos de uso;

95

SUMÁRIO


96

Capítulo 7 – Diagrama de Gráfico de Estados

7.1 – Estado

7.2 – Transições

7.3 – Estado Composto

97

7.1 - Estado• O Diagrama de Gráfico de Estado descreve o comportamento de

objetos, como reação a eventos discretos, por meio de seqüências de estados e ações que ocorrem durante a sua vida;

• Estado condição ou situação existente na vida de um objeto, durante a qual o estado satisfaz alguma condição, executa alguma atividade ou espera por algum evento;

BEBÊNascimento

98

7.2 - Transições

• Transição Relacionamento entre 2 estados, indicando que houve mudança de estado e determinadas ações serão executadas, quando um evento específico ocorrer, garantindo que condições foram satisfeitas;

• Evento Especificação de um tipo de ocorrência observável:– Condição ( V ou F);

– Recepção de um sinal;

– Outros;

99

7.3 – Estado Composto

• Estado Composto Estado que possui uma decomposição gráfica em 2 ou mais subestados concorrentes (sobrepostos) ou seqüênciais (disjuntos);

100

DE de Concurso Público

Aguardando Inscriçõesde Candidatos

Aguardando Definiçãodos Locais de prova

Aguardando realização da prova

Inscrições encerradas

Locais Lançados

Cadastrodo Concurso

101

Cadastrando conta

Aguardando Pagamento

Cancelando contaPagamento lançado

Conta cancelada

102

SUMÁRIO


103

Modelando o Diagrama de Atividades

• É um caso especial de diagrama de estados no qual todos os estados são ações ou subatividades;

Abrindo Arquivo

Carregando Texto Exibindo Texto

Liberando Ediçãodo texto

104

Identificarconta a pagar

Checar situação de pagamento

Lançar dados dopagamento

Alterar dados do pagamento

Atualizar Status da Conta

[já paga]

[não paga]

106

SUMÁRIO


107

Capítulo 9

9.1 – Diagrama de Componentes

9.2 – Diagrama de Implantação

“Diagramas de Implementação mostram aspectos de implementação física, incluindo a estrutura de

componentes e a estrutura em tempo de execução.”

108

9.1 – Diagrama de Componentes

• Mostra a estrutura dos componentes, incluindo os classificadores que eles especificam e os artefatos que eles implementam;

• Componente Representa um módulo físicco, implementável e substituível, que corresponde à parte de um sistema. O componente encapsula a implementação e exibe um conjunto de interfaces

PEDIDOS.EXE

109

9.2 – Diagrama de Implantação

• Mostram a estrutura de nós nos quais os componentes são implantados;

• Mostram a configuração de elementos de processamento em tempo de execução;

• Um DI é um gráfico de nós conectados por associações de comunicação;

• Nó Objeto físico que representa um recurso de processamento;

SERVIDOR NOTES

Mapeamento para umaLinguagem de Programação

111

MapeamentoContaAPagar

dataVencimentodescricaovalorTotalvalorParcial

lancar()registrarPagto()...

112

Mapeamento

type TContaAPagar = class private FValorTotal: real; FValorParcial: real; FDescricao: string; FDataVencimento: TDateTime; FTipoConta: TTipoConta; procedure SetDataVencimento(const Value: TDateTime); procedure SetDescricao(const Value: string); procedure SetValorParcial(const Value: real); procedure SetValorTotal(const Value: real); procedure SetTipoConta(const Value: TTipoConta); public procedure lancar; procedure registrarPagamento; property DataVencimento: TDateTime read FDataVencimento write

SetDataVencimento; property Descricao: string read FDescricao write SetDescricao; property ValorTotal: real read FValorTotal write SetValorTotal; property ValorParcial: real read FValorParcial write SetValorParcial; property TipoConta: TTipoConta read FTipoConta write SetTipoConta;

113

procedure TFormCadastro.btnCadastrarClick(Sender: TObject);begin oConta.Descricao := editDescricao.Text; oConta.ValorTotal := edtValor.Text; oConta.DataVencimento := edtDataVencimento.Text;

oConta.Lancar;end;

Mapeamento para umBD Relacional

115

Mapeamento

CLASSE TABELA

ATRIBUTO CAMPO DA TABELA

MÉTODO PODE SER IMPLEMENTADO COMO FUNÇÕES DO BANCO

RELACIONAMENTOS ATRIBUTOS DE CLASSE OU MÉTODOS

116

Processo OO

• Análise de Requisitos;• Análise;• Design (projeto);• Programação (implementação);• Testes;• Entrega;• Manutenção;

u m l - cesarbt.xpg.com.br · – amplo uso da internet; – programas extensos; – filosofia de...

Documents