127
© Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML - Linguagem de Modelagem Unificada Autor: Rildo F. Santos ([email protected])

Unified Modeling Language - UML

  • Upload
    dracco

  • View
    268

  • Download
    5

Embed Size (px)

DESCRIPTION

Apostila sobre a Linguagem de Modelagem Unificada

Citation preview

Page 1: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UMLUML - Linguagem de

Modelagem Unificada

Autor: Rildo F. Santos ([email protected])

Page 2: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

2

Conteúdo

Parte 1:

- Introdução a Orientação a Objeto

Parte 2:

- Introdução a UML

Parte 3:

- Diagramas da UML

Parte 4:

- Estudo de Caso

- Exercício

Apêndices:

- Notação UML

- UML 2.0

Page 3: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

3

Palavra inicial

A UML é padrão de mercado (www.omg.org/uml) que representa as

melhores práticas da engenharia de software em modelagem de

software;

A UML permite que desenvolvedores visualizem o software através

modelos e de um conjunto de diagramas;

A modelagem visual facilita o entendimento e a comunicação do 'quê'

precisa ser feito e 'como' deve ser feito o software;

Os diagramas oferecem a padronização, que é necessária quando

trabalhamos com grandes equipes de desenvolvedores ou com

fornecedores;

Neste treinamento apresentaremos todos os diagramas, elementos e

a semântica da Linguagem de Modelagem Unificada;

O treinamento:

Começa sendo demonstrado uma introdução a orientação a objetos

com objetivo de fazer um alinhamento de conhecimento da Orientação

a Objetos.

Depois é apresentado a UML, semântica e todos os diagramas (da

versão 1.5)

Também será exibido em estudo de caso com propósito de mostrar

como é feito a modelagem visual de software com UML.

Será utilizada uma ferramenta de modelagem visual para ajudar o

aprendizado da UML.

Page 4: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

4

Introdução a Orientação

a Objetos

Objetivo desta parte:

É apresentar e discutir uma

introdução a Linguagem de

Modelagem Unificada versão 1.5.

Page 5: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

5

Orientado a Objetos

Introdução a Orientação a Objetos

Os sistemas projetados atualmente são maiores, mais complexos e sujeitos a constantes

alterações e adaptações aos diversos ambientes computacionais. Através do

encapsulamento de informações, a reutilização de esforços empregados em projetos

anteriores e a modificação do sistema se tornaram mais fáceis.

Orientação a Objetos:

Um problema sempre define ou está contido em um domínio (sujeito a leis da física, da

matemática, do direito, do mercado financeiro e por ai a fora).

Assim a primeira resposta a buscar no desenvolvimento de um sistema em computação é

a construção de um modelo que coloque em termos de algoritmos o domínio da

aplicação. Pensando num modelo de objetos, numa abordagem de alto nível de abstração

há três fases:

Projeto e Modelagem UML

Implementação Linguagem Java

MetodologiaAnálise

Orientação a Objetos

Análise: Discute

o porque, o que

(com quais informações

e para quais serviços) se

deve fazer

Projeto: O Como fazer, de

forma a ficar manutenível;

O mapeamento em

linguagem processável

pelo computador

Page 6: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

6

O Método Orientação a Objetos

A metodologia Orientação a Objetos é baseada em noções, consideradas intuitivas ao

ser humano, tais como: objetos e atributos, classes e membros, estruturas e

componentes, ação e reação.

Os métodos de desenvolvimento de software anteriores ao surgimento desse paradigma

organizam a especificação de um sistema de acordo com suas funções ou com os

dados manipulados. Geralmente, esses métodos apresentam dificuldades na transição

da representação do sistema em uma fase para outra do processo de desenvolvimento

(da Análise para o Projeto e, do Projeto para a Implementação).

Em um sistema orientado a objetos, os dados e todas as operações (funções), que

manipulam esses dados, são agrupados em uma única estrutura: os objetos. Desde o

início do desenvolvimento desses sistemas e, em todas as suas fases, o analista

trabalha com o mesmo elemento de abstração, os objetos.

Introdução a Orientação a Objetos

Orientado a Objetos

Page 7: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

7

As classes são as partes mais importantes de qualquer sistema orientada a objetos.

Usamos as classes para capturar o vocabulário do sistema que está em

desenvolvimento. Essas classes podem incluir abstrações que são parte do domínio do

problema, assim como as classes que fazem uma implementação. Podemos usar ainda

as classes para representar itens de software, de hardware e até itens que sejam

somente conceituais.

Exemplo:

A classe Pessoa deverá ter atributos e métodos comuns

Pessoa

Nome

Idade

GetNome

GetIdade

Nome da Classe

Atributos

Métodos

Os nome deverão ser identificadores únicos em conjunto de classes, este devem ser

substantivos. Exemplo: Produto.

Tipos de Classes:

• Classe Concreta

• Classe Abstrata

O que é uma Classes?

“Uma classe descreve um conjunto de objetos com propriedades e comportamentos

semelhantes e com relacionamentos comuns com outros objetos”

Classe

Orientado a Objetos

Page 8: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

8

Exemplo:

A classe Pessoa. Classe concreta.

public class Pessoa {

//Atributos

private String nome;

private int idade;

//métodos

public String getNome(){

return nome; }

public void setNome(String

nome){

this.nome = nome; }

public int getIdade(){

return idade; }

public void setIdade(int

idade){

this.idade = idade; }

}

Classe Concreta:

Uma classe que tem assinatura e a implementação de métodos.

Exemplo de diagrama de classe

usando Rational Rose (notação Unified)

Classe

Orientado a Objetos

Page 9: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

9

Exemplos de Objetos:

O que são Objetos ?

São qualquer coisa na natureza que possua propriedades (características) e

comportamentos (operações).

Exemplo: uma pessoa, uma cão e etc

Orientação a Objetos:

O termo orientação a objetos significa organizar o mundo real como uma coleção de

objetos que incorporam estrutura de dados e um conjunto de operações que

manipulam estes dados.

Estrutura de um objeto

Objetos combinam propriedades (atributos) e comportamentos (operações ou

métodos).

Propriedades Comportamentos

Bonita

Jovem

Inteligente

Andar

Correr

Falar

Chorar

Dançar

Objeto: Pessoa

Objetos

Orientado a Objetos

Page 10: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

10

public class CalculaData {

private int day, month, year;

public float calcDays(int age )

{

return 365.25F * age;

}

}

Métodos

método

Métodos são os comportamentos ou as funções do objeto. A declaração é feita da

seguinte forma:

< modificador > < tipo de retorno > < nome > ( < lista de argumentos > )

< bloco >

< modificador > -> segmento que possui os diferentes tipos de modificações

incluíndo public, protected, private e default (neste caso não precisamos declarar o

modificador).

< tipo de retorno > -> indica o tipo de retorno do método.

< nome > -> nome que identifica o método.

< lista de argumentos > -> todos os valores que serão passados como

argumentos.

Exemplos: public void somaDias (int dias) { }

private int somaMes(int mês) { }

protected String getNome() { }

int getAge(double id) { }

Orientado a Objetos

Page 11: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

11

public class Disciplina {

private int cargaHoraria;

private String nome;

public Disciplina(String nome, int

cargaHoraria){

this.nome = nome;

this.cargaHoraria =

calcCargaHoraria(cargaHoraria);

}

public String getNome(){

return nome;

}

public int getCargaHoraria(){

return cargaHoraria;

}

public int calcCargaHoraria(int

qdeHoras) {

int horasPlanejamento = (int)

( qdeHoras * 0.1);

return cargaHoraria =

horasPlanejamento + qdeHoras;

}

}

Atributos

Variáveis

temporárias

Atributos e variáveis (Linguagem Java)

Os atributos são pertencentes a classe, eles podem ser do tipo primitivo ou

referência (objetos), os seus modificadores podem ser: public, private, protected

ou default.

O ciclo de vida destes atributos estão vinculados ao ciclo de vida da classe.

Variáveis Locais:

São definidas dentro dos métodos. Elas têm o ciclo de vida vinculado ao ciclo do

método, também são chamadas de variáveis temporárias

Modificador

Orientado a Objetos

Page 12: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

12

O que é abstração?

Podemos dizer abstração é generalização.

Qual é a função da abstração ?

A função da abstração é capturar as propriedades e os comportamentos essenciais,

como se fosse uma fatoração, desta forma determina-se o que é importante e o que

não é.

Aeronave

Caça Helicóptero Passageiros

Mamífero

Vaca Urso Cavalo

Para discutirmos sobre classes abstratas é necessário falarmos sobre a abstração de

dados.

As classes Aeronave e Mamífero neste caso são abstratas e ambas representam um

domínio.

Abstração de Dados:

Orientado a Objetos

Page 13: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

13

Uma operação abstrata só determina a existência de um comportamento não definindo

uma implementação. Classes Abstratas - Exemplo:

Classes Abstratas

Uma classe abstrata é uma classe que:

• Provê organização

• Não possui “instances”

• Possui uma ou mais operações (métodos) abstratas

Pessoa

Pessoa

Física

Pessoa

Jurídica

getNome()

getNome() getNome()

Classe Abstrata

Funcionário

Analista Programador

Classe concreta

Classe concreta

Classe Abstrata

Abstração de Dados:

Orientado a Objetos

Page 14: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

14

Um relacionamento é a conexão entre itens. É representado graficamente como um

caminho, que tem tipos diferentes de linhas para distinguir os tipos de

relacionamentos.

Ao construir as abstrações, descobrimos que são poucas as classes que trabalham

sozinhas. Em vez disso, a maioria das classes colaboram com outras classes de várias

maneiras.

Portanto, quando estamos modelando, devemos identificar as classes, atributos, métodos e

relacionamentos.

Existem alguns tipos principais de relacionamentos entre classes e objetos:

• Herança

• Agregação

Veja a definição de relacionamento:

Exemplo: Hierarquia de Classes

Pessoa

Aluno Funcionário

ProfessorPessoal

Administrativo

Terceiro

Professor

Autônomo

Pessoal

Operacional

SubClasses

SuperClasse

Relacionamento:

1 - Pessoa é a SuperClasse de Terceiro, Aluno e de Funcionário,

estas são subclasse de Pessoa.

2 - Terceiro e Funcionário são SuperClasse de Professor e Pessoal Administrativo e de

Professor Autônomo e Pessoal Operacional respectivamente.

E estas são subclasse de Terceiro e Funcionário.

Relacionamento

Orientado a Objetos

Page 15: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

15

Herança é o mecanismo pelo qual elementos mais específicos incorporam a estrutura e

comportamento de elementos mais gerais,

Uma classe derivada herda a estrutura de dados e métodos de sua

classe “base”, mas pode seletivamente:

• adicionar novos métodos

• estender a estrutura de dados

• redefinir a implementação de métodos já existentes

Uma classe “pai” proporciona a funcionalidade que é comum a todas as suas classes

derivadas, filhas, enquanto que uma classe derivada proporciona a funcionalidade

adicional que especializa seu comportamento.

Exemplo:

Graduação Pós-Graduação

Curso

Universitário

Especialização Extensão

Hierarquia de Classes

Podemos dizer que Graduação é tipo de Curso Universitário, assim como Curso de

Especialização ou de Extensão.

extends

extends

Herança

Orientado a Objetos

Page 16: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

16

Exemplo: Implementação- Pessoa, Aluno, Terceiro, Funcionário

public abstract class Pessoa {

protected String idPessoa;

protected int idade;

protected String nome;

public Pessoa(String nome)

{

this.nome = nome;

}

public abstract String getNome();

public void setidPessoa()

{ }

public abstract int getIdade();

public void setIdade(int idade)

{ }

}

public class Terceiro extends Pessoa{

private int codigoTerceiro;

public Terceiro(String nome)

{

super(nome);

}

public int getIdade()

{

return 0;

}

public String getNome()

{

return "";

};

}

public class Funcionario extends Pessoa{

private int codigofuncionario;

public Funcionario(String nome)

{

super(nome);

}

public int getIdade()

{

return 0;

}

public String getNome()

{

return "";

};

}

Professor

Autônomo

Pessoal

Operacional

ProfessorPessoal

Administrativo

Herança

public class Aluno extends Pessoa{

public Aluno(String nome)

{

super(nome);

}

public int getIdade()

{

return 0;

}

public String getNome()

{

return "";

};

}

Orientado a Objetos

Page 17: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

17

Pessoa

AlunoTerceiro

public class ProfessorAutonomo

extends Terceiro{

public ProfessorAutonomo(

String nome)

{

super(nome);

}

}

public class PessoalOperacional

extends Terceiro{

public PessoalOperacional(

String nome)

{

super(nome);

}

}

public class Professor

extends Funcionario{

public Professor(

String nome)

{

super(nome);

}

}

public class PessoalAdministrativo

extends Funcionario{

public PessoalAdministrativo(

String nome)

{

super(nome);

}

}

Funcionário

Exemplo de Herança: Implementação: ProfessorAutonomo, PessoalOperacional,

Professor e Pessoal Administrativo

Herança

Orientado a Objetos

Page 18: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

18

A herança múltipla é quando uma classe tem mais que uma Superclasse associada e

que herde as características de todas elas. Veja a figura abaixo:

Pessoa

Pessoa JurídicaPessoa Física

<<interface>>

Mamífero

Relacionamento:

Pessoa Física é tipo de pessoa, mas também é mamífero.

Na linguagem Java:

A Herança múltipla é somente permitida por contrato, neste caso a Mamífero é uma

Interface, podemos dizer que é tipo especial de classe, que não pode

ter métodos implementados, apenas as assinaturas.

Herança Múltipla

<<interface>>

Mamífero

Interface:

O que é interface ?

Interface é um contrato entre o cliente, que pode ser classe concreta ou abstrata, e a

interface. Este contrato é garantia que o métodos assinados na interface serão

implementados na classe cliente.

Nota: Na interface também podemos declarar constantes (public static final).

interface Product

{

String getName ();

double getCost ();

}

SuperclasseSuperclasse

Exemplo de Interface

Orientado a Objetos

Page 19: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

19

Exemplo: Implementação da classe Pessoa, PessoaFisica e PessoaJuridica e a

interface Mamifero

public abstract class Pessoa {

protected String idPessoa;

protected int idade;

protected String nome;

public Pessoa(String nome)

{

this.nome = nome;

}

public abstract String getNome();

public abstract int getIdade();

public void setIdade(int idade){ }

}

public class PessoaJuridica1 extends Pessoa

{

public PessoaJuridica1(String nome)

{

super(nome);

}

public int getIdade()

{

return 0;

}

public String getNome()

{

return "";

};

}

public interface Mamifero {

final int qdeOlhos=2;

public int getQdePernas();

}

public class PessoaFisica1 extends Pessoa

implements Mamifero {

public PessoaFisica (String nome)

{

super(nome);

}

public int getQdePernas(){

return 2; }

public String getNome(){

return “”; }

public int getIdade(){

return 0; }

}

Exercício:

1 - Podemos implementar a herança múltipla na Classe Pessoa? Por que ?

2 - Por que somos obrigado a assinar ou implementar os métodos da Interface Mamifero

na classe PessoaFisica

Herança Múltipla

implements

extends

extends

Orientado a Objetos

Page 20: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

20

É uma proteção adicional dos dados do objeto de possíveis modificações impróprias,

forçando o acesso a um nível mais baixo para tratamento do dados.

Operações/métodos/interface

pública

Dados/Atributos/propriedades

privada

Encapsulamento (“data hiding”)Encapsulamento é definido como uma técnica para minimizar dependências entre

“módulos” através da definição de interfaces externas. Também conhecido como:

O fenômeno da “caixa preta”

Encapsulamento

public class Empregado {

private double salario;

public Empregado(){

salario=0.00;

}

public double getSalario(){

return this.salario;

}

}

O atributo salario somente poderá ter

um valor atribuído ou alterado,

através de método público.

Através do método getSalario, que

tem modificador public, podemos

manipular ou recuperar o valor do

atributo salario.

Classe Empregado e método

getSalario

O atributo salario

private double salario;

Orientado a Objetos

Page 21: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

21

A interface (pública) de um objeto declara todas as operações permitidas (métodos)

Todo o acesso aos dados do objeto é feito através da chamada a uma operação (método)

da sua interface.

Encapsulamento - Benefícios

- Segurança:

Protege os atributos dos objetos de terem seus valores corrompidos por outros

objetos.

- Independência:

“Escondendo” seus atributos, um objeto protege outros objetos de complicações de

dependência de sua estrutura interna

Encapsulamento

public class Gerente1 extends Empregado {

private double bonus = .15;

public double getSalario(){

//referência ao método getSalario

return super.getSalario() +

(super.getSalario()*this.bonus);

}

}

public class Empregado {

private double salario;

public Empregado(){

salario=0.00;

}

public double getSalario(){

return this.salario;

}

}

private double salario;

Orientado a Objetos

Page 22: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

22

Definição:

“Polimorfismo” é uma operação que pode assumir múltiplas formas, a propriedade

segundo o qual uma operação pode comportar-se diferentemente em classes diferentes”

(Rumbaugh)

O polimorfismo é o responsável pela extensibilidade em programação orientada a objetos.

Polimorfismo

overloading

overriding

Overloading:

Possibilidade de reúso do nome do método para diferentes implementações, em tempo de

execução, a aplicação, escolherá o método adequado para cada chamada, veja o

exemplo.

TesteSoma Soma

somar(int a, int b)

somar(float a, float b)

somar(char a, char b)

somar(long a, long b))

Para cada tipo de dados existe um método, o reúso do nome do método é permitido,

entretanto a lista de argumentos deve ser diferente, veja o exemplo acima: o método

somar é definido várias vezes, entretanto com a lista de argumentos diferente, desta

forma evitaremos problemas como ambigüidade.

Polimorfismo

Orientado a Objetos

Page 23: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

23

public class EmpregadoExemplo {

private double salario;

public void setSalario(int diastrabalhados,

double valorhora ){

this.salario = diastrabalhados *

valorhora * 8;

}

public double getSalario(){

return this.salario;

}

}

public class Engenheiro extends

EmpregadoExemplo {

public static void main(String args[])

{

Engenheiro eng = new Engenheiro();

eng.setSalario(22, 35.00);

System.out.println(eng.getSalario());

}

}

O método setSalario é herdado da Superclasse (Empregado), entretanto para cada cargo

(tipo de empregado) ele tem uma implementação diferente. Por exemplo:

- Para Engenheiro e Secretária salário = (Dias Trabalhados x Valor hora)

- Para Gerente salário = (Dias Trabalhados x Valor hora) + Bônus

- Para Diretor salário = (Dias Trabalhados x Valor hora) + Bônus + Participação nos

lucros.

Overrinding - Exemplo:

Empregado

setSalario()

getSalario()

Engenheiro

getSalario()

Gerente

getSalario()

Diretor

getSalario()

Secretária

getSalario()

Polimorfismo

Orientado a Objetos

Page 24: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

24

Overrinding

Uma subclasse pode mudar o comportamento herdado da Superclasse, ou seja, um método

herdado poderá ser alterado. Veja o exemplo abaixo:

O método getSaldo é herdado da Superclasse (Conta Bancária), entretanto para cada

tipo de Conta ele tem uma implementação diferente. Por exemplo:

- Para apurar o saldo da Conta Corrente saldo atual = (soma dos depósitos + saldo

anterior) - saques

Para a conta poupança seria saldo atual = (soma dos depósitos + saldo anterior + juros)

- saques

Para a conta de investimentos seria saldo atual = (soma dos aplicações + saldo anterior

+ juros) - resgates - ir

Conta Bancária

getSaldo()

Conta Corrente

getSaldo()

Conta Poupança

getSaldo()

Investimentos

getSaldo()

Exercício:

Faça a implementação das classes acima.

Polimorfismo

Orientado a Objetos

Page 25: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

25

Introdução a UML

Page 26: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

26

Visão de

Projeto

Funcionalidade

Vocabulário

Visão daImplementação

Codificação

Montagem

Visão do Processo

Desempenho

Escalabilidade

Throughput

Visão daImplantação

Topologia do Sistema

Distribuição

Instalação

Conceitual Físico

Visão de Caso de

Uso

Visão 4 + 1

Introdução a UML

Page 27: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

27

• A visão do caso de uso abrange os casos de usos que descrevem o

comportamento do sistema conforme é visto pelos seus usuários

finais, analista e pessoal de teste. Essa visão não especifica realmente

a organização do sistema de softwasre. Porém , ela existe para

especificar as forças que determinam a forma da arquitetura do

Sistema. Com a UML, os aspectos estáticos dessa visão são

representados em diagramas de caso de uso, enquanto os aspectos

dinâmicos são representados em diagrama de interação., diagrama de

gráfico de estados e diagrama de atividades

• A visão de projeto de um sistema abrange as classes e colaborações

que formam o vocabulário do problema e de sua solução. Essa

perpectiva proporciona principalmente um suporte para os requisitos

funcionais do sistema, ou seja, os serviços que o sistema deverá

fornecer a seus usuários finais.

Com a UML, os aspectos estáticos dessa visão são captados em

diagramas de classes e de objetos; os aspectos dinâmicos são

captados em diagramas de interações, de estados e de atividades.

Visão de Caso

de Uso

Visão de Processo

Introdução a UML

Visão 4 + 1

Page 28: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

28

• A visão do processo abrange os threads e os processos que formam

os mecanismos de concorrência e de sincronização do sistema. Essa

visão tem com objetivo principal tratar questões de desempenho, à

escalabilidade e ao throughput do sistema. Com a UML, os aspectos

estáticos e dinâmicos dessa visão são capturados nos mesmos tipos

de diagrama da visão do projeto, mas o foco voltado para as classes

ativas que repesentam esses threads e processos.

Threads = Linhas de execução em paralelos, estas linhs podem ser programas ou parte.

• A visão de implementação de um sistema abrange os componentes e

os arquivos utilizados para a montagem e fornecimento do sistema

físico. Essa visão envolve principalmente o gerenciamento da

configuração das versões do sistema, compostas por componentes e

arquivos de alguma maneira independentes, que podem ser reunidos

de diferentes formas para a produção de um sistema executável.

Visão de Implementação

Visão de Processo

Introdução a UML

Visão 4 + 1

Page 29: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

29

• A visão do implantação de um sistema abrange os nós que formam a

topologia de hardware em que o sistema é executado. Essa visão

direciona principalmente a distribuição, o fornecimento e a instalação

das partes que constituem o sistema físico. Com a UML, os aspectos

estáticos dessa visão são representados em diagrmas de implantação;

os aspectos dinâmicos são capturados em diagramas de interações,

de gráfico de estados e diagramas de atividades.

Visão de Implantação

Cada uma dessas visões pode ser considerada isoladamente, permitindo

que diferentes participantes orientem seu foco para os aspectos da

arquitetura do sistema que mais lhes interessem. Essas cincos visões

também interagem entre sí, por exemplo:

Os nós na visão de implantação contêm componentes da visão de

implementação que, por sua vez, representa a realização física de classes,

interfaces, colaborações e classes ativas provenientes das visões de projeto

e de processo.

Introdução a UML

Visão 4 + 1

Page 30: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

30

Desenvolvimento de Software

Estrutura:

Casos de Uso

Seqüência

(eventos)Colaboração

Classes

Distribuição

Implementação

Estrutura

Comportamento

interno

Comportamento

externo

Análise de

Requisitos

Introdução a UML

Page 31: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

31

Produtos dos Workflows de Requisitos e de Análise:

Documento de Visão

Especificação de Requisitos (Casos de Uso)

Vocabulário do Sistema

Modelo Conceitual ou Modelo de Domínio

Análise

Requisitos

Arquitetura Modelo de Arquitetura Inicial

Introdução a UML

Page 32: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

32

Produtos dos Workflows de Projeto

Projeto

Diagrama de Seqüência / Colaboração

Diagrama de Classes (Refinado)

Diagrama de Atividades*

Diagrama de Estados*

* se necessário

Introdução a UML

Page 33: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

33

Produtos dos Workflows de Arquitetura

Arquitetura

* se necessário

Diagrama de Componentes

Diagrama de Distribuição(Deployment)

Modelo de Arquitetura

Introdução a UML

Page 34: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

34

Por que fazer a modelagem?

“A Modelagem captura as partes essenciais do sistema.” (Rumbaugh)

Com a modelagem, alcançamos alguns objetivos:

1 - Os modelos ajudam a visualizar o sistema como ele é ou como desejamos que seja2 - Os modelos permitem especificar a estrutura ou o comportamento de um sistema3 - Os modelos proporcionam um guia para a construção do sistema4 - Os modelos documenta o sistema

O Que é Modelagem Visual?

Modelagem Visual significa modelar com a utilização de notações padrão. Precisamos adotar uma ferramenta, uma notação e linguagem para tal empreitada.UML (Linguagem de Modelagem Unificada) é a linguagem de modelagem é das mais populares do momento. Mas podemos optar por usar OMT, por exemplo.

Construímos modelos para compreender melhor que estamos desenvolvendo

Introdução a UML

Page 35: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

35

Modelagem visual significa modelar com a utilização de notações

padrão. Precisamos adotar uma ferramenta, uma notação e

linguagem para tal empreitada. UML (Linguagem de Modelagem

Unificada) é a linguagem de modelagem é das mais populares do

momento.

A UML (Linguagem de Modelagem

Unificado) é padrão mantido pelo

OMG (www.omg.org/uml).

O Que é Modelagem Visual?

Introdução a UML

Page 36: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

36

O Quê é a UML?

A UML (Linguagem de Modelagem Unificada) é uma linguagem-padrão

para elaboração da estrutura de projetos de software. A UML poderá ser

usada para:

• Visualização

• Especificação

• Construção de modelos e diagramas

• Documentação.

A UML é adequada para a modelagem de sistemas, cuja a abrangência

poderá incluir sistemas de informação corporativos a serem distribuídos a

Aplicação baseadas em Web e até sistemas complexos embutidos de

tempo real.

A UML é apenas uma linguagem e, portanto, é somente uma parte de um

método para desenvolvimento de software. Ela é independente do

processo, apesar de ser perfeitamente utilizada em processo orientado a

casos de usos, centrado na arquitetura, iterativo e incremental.

Introdução a UML

Page 37: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

37

ESTÁTICOS

. Diagrama de Classes

. Diagrama de Objetos

. Diagrama de Componentes

. Diagrama de Distribuição

DINÂMICOS

. Diagrama de Casos de Uso

. Diagramas de Interação

- Diagrama de Seqüência

- Diagrama de Colaboração

. Diagrama de Atividade

. Diagrama de Estados

Modela o comportamento

do sistema

Modela a estrutura

do sistema

Diagramas*

Introdução a UML

Nota: diagramas da versão 1.5

Page 38: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

38

O Quê é a UML?

A UML é linguagem para documentação

A construção de software produz todos os tipos de artefatos além do código executável.

Estes artefatos incluem o seguinte:

- Requisitos

- Arquitetura

- Projeto

- Código-Fonte

- Planos de Projeto

- Teste

- Protótipos

- Versões

A UML abrange a documentação da arquitetura do sistema e de todos os seus detalhes.

A UML também proporciona uma linguagem para expressão de requisitos e para

realização de testes. Por fim, a UML oferece uma linguagem para modelagem das

atividades de planejamento do projeto e de gerenciamento de versões.

Onde a UML pode ser utilizada ?

A UML se destina principalmente a construção de software complexos. Atualmente

sendo empregada largamente na construção de Sites de E-commerce e E-business

Introdução a UML

Page 39: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

39

O Quê é a UML?

Blocos de construção da UML

O Vocabulário da UML abrange três tipos de blocos de construção:

- Itens

- Relacionamentos

- Diagramas

- Itens,

Existem quatro tipos de itens na UML

Itens estruturais: São os substantivos utilizados em modelos da UML. São as partes

mais estáticas do modelo, representando elementos conceituais ou físicos.

Primeiro, as classes são descrições como conjuntos de objetos que compartilham os

mesmos atributos, operações, relacionamento e semântica.

Nome

Atributos

Métodos

Introdução a UML

Page 40: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

40

O Quê é a UML?

Blocos de construção da UML

- Itens (continuação),

Segundo, uma interface é uma coleção de operações que especificam serviços de uma

classe ou componente. Portanto, uma interface descreve o comportamento

externamente visível desse elemento. Uma interface poderá representar todo o

comportamento de uma classe ou componente, como também apenas parte do

comportamento. A interface define um conjunto de especificações de operações

(assinaturas), mas nunca um conjunto de implementações de operações.

Calculo

Terceiro, as colaborações definem interação e são sociedades de papéis e outros

elementos que funcionam em conjunto para proporcionar um comportamento

cooperativo superior à soma de todos os elementos. Portanto, as colaborações contêm

dimensões estruturais, assim como comportamentais. As colaborações representam a

implementação de padrões que formam um sistema .

Cadeia de

Responsabilidade

Introdução a UML

Page 41: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

41

O Quê é a UML?

Blocos de construção da UML

- Itens (continuação),

Quarto, um caso de uso é a descrição de conjunto de sequência de ações realizadas

pelo sistema que proporciona resultados observáveis de valor para um determinado

ator. Um caso de uso é utilizado para estruturar o comportamento de itens em um

modelo. Um caso de uso é realizado por uma colaboração.

Quinto, as classes ativas são classes cujos os objetos têm um mais processos ou

threads e, portanto, podem iniciar a atividade de controle. Uma classe ativa é

semelhante a um classe, exceto pelo fato de que seus objetos representam elementos

cujo o comportamento é concorrente com o outros elementos.

FazerPedido

start()

sleep()

ControlEvent

Introdução a UML

Page 42: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

42

O Quê é a UML?

Blocos de construção da UML

- Itens (continuação),

Sexto, os componentes são partes físicas e substituíveis de um sistema, que

proporcionam a realização de um conjunto de interfaces.Tipicamente os componentes

representam, o pacote físico de elementos lógicos diferentes, como classes,

interfaces e colaborações.

Sétimo, um nó é elemento físico existente em tempo de execução que representa um

recurso computacional, geralmente com pelo menos alguma memória e,

frequentemente, capacidade de processamento. Exemplo de nós:

- Computadores (estações clientes e servidores)

- Redes

- Roteadores

Component.java

Servidor

Introdução a UML

Page 43: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

43

O Quê é a UML?

Blocos de construção da UML

- Itens Comportamentais

São parte dinâmicas dos modelos de UML. São os verbos de um modelo, representado

comportamento no tempo e espaço. Ao todo, existem dois tipos de itens

comportamentais:

Primeiro, um interação é um comportamento que abrange um conjunto de mensagens

trocadas entre um conjunto de objetos em determinado contexto para realização de

propósitos específicos. As interações envolvem outros elementos, inclusive

mensagens, sequência de ações (os comportamentos chamados pelas mensagens) e

ligações (as conexões entre os objetos)

Mostrar

Segundo, uma máquina de estado é um comportamento que especifica as sequências

de estados pelas quais objetos ou interações passam durante sua existência em

resposta a eventos, bem como suas respostas a esses eventos. O comportamento de

classe ou de uma colaboração pode ser especificado por meio de uma máquina de

estados. Uma máquina de estados abrange mais elementos, tais como, transições (o

fluxo de um estado a outro evento), evento (itens que disparam uma transição) e

atividades (as respostas às transições).

Aguardando

Introdução a UML

Page 44: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

44

O Quê é a UML?

Blocos de construção da UML

- Itens de Agrupamentos

Os itens de agrupamento são partes organizacionais dos modelos de UML. São os

blocos em que os modelos podem ser decompostos. Ao todo, existe apenas um tipo

principal de itens de agrupamento chamado de pacotes.

Um pacote é mecanismo de propósito geral para a organização de elementos em

grupos. Os itens estruturais, os itens comportamentais e até outros itens de grupos

podem ser colocados em pacotes. Ao contrário dos componentes (que existem em

tempo de execução), um pacote é puramente conceitual (o que significa que existe

apenas em tempo de desenvolvimento.

Aplicação

Interface de

Usuário

ControleRegras de

Negócios

- Itens Anotacionais

Itens anotacionais são as partes explicativas dos modelos UML. São comentários,

incluídos para descrever, esclarecer e fazer alguma observação sobre qualquer

elemento do modelo. Existe apenas um item anotacional chamado nota

Imprimir

Recibo

Introdução a UML

Page 45: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

45

O Quê é a UML?

Blocos de construção da UML

- Relacionamentos

Existem quatro tipos de relacionamentos na UML:

1 - Dependência

2 - Associação

3 - Generalização

4 - Realização

Esses relacionamentos são blocos relacionais básicos de construção da UML.

O primeiro dependência é um relacionamento semântico entre dois itens, nos quais a

alteração de um (o item independente) pode afetar a semântica do outro (o

dependente). Sua representa é linha tracejada, possivelmente com setas e

ocasionalmente incluindo um rótulo.

O segundo associação é um relacionamento estrutural que descreve um conjunto de

ligações, em que as ligações são conexões entre objetos. A agregação é um tipo

especial de associação, representando um relacionamento estrutural entre o todo e

suas partes. É representada por uma linha sólida, possivelmente direcionadas,

ocasionalmente incluído rótulos e freqüentemente, contendo outros adornos, como

nomes de papéis e multiplicidade.

Pessoa Empregadorempregador

0..1

*

funcionário

Introdução a UML

Page 46: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

46

O Quê é a UML?

Blocos de construção da UML

O terceiro é a generalização é um relacionamento de especialização e generalização,

nos quais os objetos dos elementos especializados (os filhos) são substituíveis por

objetos do elemento generalizados (os pais). Dessa forma, os compartilham a estrutura

e comportamento dos pais.

Médico

Clinico Geral Pediatra

generalização

especialização

O quarto é a realização é um relacionamento semântico entre classificadores, em que

um classificador especifica um contrato que outro classificador garante executar.

Os relacionamentos de realização são encontrados em dois locais: entre interface

e as classes ou componentes que as realizam; entre casos de uso e as colaborações

que os realizam.

Place

order

Order

management

colaboração

Introdução a UML

Page 47: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

47

O Quê é a UML?

Revisão

Blocos de construção da UML

O Vocabulário da UML abrange três tipos de blocos de construção:

- Itens

- Relacionamentos

- Diagramas

- Itens,

Existem quatro tipos de itens na UML

Itens estruturais: São os substantivos utilizados em modelos da UML. São as partes

mais estáticas do modelo, representando elementos conceituais ou físicos.

Primeiro, as classes são descrições como conjuntos de objetos que compartilham os

mesmos atributos, operações, relacionamento e semântica.

Segundo, uma interface é uma coleção de operações que especificam serviços de

uma classe ou componente.

Terceiro, as colaborações definem interação e são sociedades de papéis e outros

elementos que funcionam em conjunto para proporcionar um comportamento

cooperativo superior à soma de todos os elementos.

Quarto, um caso de uso é a descrição de conjunto de sequência de ações realizadas

pelo sistema que proporciona resultados observáveis de valor para um determinado

ator.

Quinto, as classes ativas são classes cujos os objetos têm um mais processos ou

threads e, portanto, podem iniciar a atividade de controle

Introdução a UML

Page 48: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

48

O Quê é a UML?

Revisão

Sexto, os componentes são partes físicas e substituíveis de um sistema, que

proporcionam a realização de um conjunto de interfaces.

Sétimo, um nó é elemento físico existente em tempo de execução que representa um

recurso computacional

- Itens Comportamentais

São parte dinâmicas dos modelos de UML. São os verbos de um modelo, representado

comportamento no tempo e espaço. Ao todo, existem dois tipos de itens

comportamentais:

Primeiro, interação é um comportamento que abrange um conjunto de mensagens

trocadas entre um conjunto de objetos em determinado contexto para realização de

propósitos específicos.

Segundo, uma máquina de estado é um comportamento que especifica as sequências

de estados pelas quais objetos ou interações passam durante sua existência em

resposta a eventos, bem como suas respostas a esses eventos.

Introdução a UML

Page 49: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

49

Diagramas da UML

Page 50: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

50

Casos de Uso

O que são Caso de Uso?

São diagramas de que permitem visualizar, especificar e documentar o comportamento

de um elemento. Esses diagramas fazem com que sistema, subsistemas e classes

fiquem acessíveis e compreensíveis, por apresentarem uma visão externa sobre como

esses elementos podem ser utilizados no contexto.

Definição:

Caso de Uso é uma descrição de um conjunto de seqüências de ações, inclusive

variantes, que um sistema pode produzir um resultado de valor observável por um ator.

A representação gráfica é uma elipse.

Elementos dos Caso de Uso:

Ator:

Um ator representa um conjunto coerente de papéis que os usuários de casos de uso

desempenham quanto interagem com esses casos de uso. Geralmente um ator

representa um papel, que pode ser de pessoa, de um sistema ou de um dispositivo.

Cenários:

Podemos definir os cenários como uma instância de um Caso de uso. O caso de uso

deve ser descrito através de cenários. Devem ser construídos tantos cenários quantos

forem necessários para se entender completamente todo o sistema. Podem ser

considerados como teste informais para validação dos requisitos do sistema.

Introdução a UML

Page 51: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

51

Diagramas de Caso de Uso e Extensões

Professor

Selecionar curso

para ensinar

Pedir lista dos

matriculados

Gerente

Manter informação de

aluno

Manter informação de

professor

Gerar catalogo

Manter informações dos

cursos

Sistema de

cobrançaMatrícula nos

Cursos

Aluno

Casos de Uso

Generalização:

Entre casos de uso é parecida à generalização existente entre as classes.

No caso de uso a generalização significa que o caso de uso filho herda o

comportamento e o significado do caso de uso pai; o filho poderá acrescentar ou

sobrescrever o comportamento de seu pai; poderá ser substituído em qualquer

local qual o pai apareça.

Include:

Quando você estiver se repetindo em dois ou mais caso de uso separados

devemos evitar a repetição

Extends:

Quando estivermos descrevendo uma variação em comportamento normal,

entretanto, querendo fazer uma descrição mais controlada, explicando os pontos

de extensão no caso de uso.

Realizes:

Especifica a colaboração entre os casos de uso

Use (obsoleto): Especifica que a semântica do elemento de origem depende da

semântica da parte pública do destino

Introdução a UML

Page 52: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

52

Descrição dos Cenários:

Nome AutenticarSenha

Descrição Autenticar Senha

Objetivo Identificar o usuário, autenticar senhas e autorizar acesso.

Atores Usuário

Papéis: Funcionário Administrativos, Alunos e Professores

Pré Condição Usuário cadastro no sistema senhas, Usuário não estar “logado”

Dados Entrada

e Saída

Entrada: Código do usuário e senha de acesso

Saída: Autorização para uso (Pasta de Acesso) ou uma mensagem de alerta

Sequência de troca mensagens

Ator Sistemas

1. Usuário chama uma interface Registro

2. Usuário informa seu código e sua senha.

3. Usuário requisita autenticação dos dados

informados.

8 Usuário recebe a mensagem, ou seja, a autorização

Pasta de Acesso, formatada de acordo sua interface.

4. Aplicativo processa a autenticação da senha, faz a

identificação do usuário. Verificar se usuário tem o

status de Liberado.

5. Conferir se senha não está expirada.

6. Conferir se senha informada coincide com a senha

gravada.

7. Retornar uma mensagem e uma assinatura.

Curso Alternativo (Exceção):

Ator Sistemas

4. Usuário com status de bloqueado. Retornar

mensagem de alerta/erro

5. Senha expirada. Retornar mensagem de alerta/erro(O usuário deverá trocar a senha – ver case de uso

AlterarSenha)

6. Senha não confere. Retornar mensagem de

alerta/erro de senha inválida. Registrar a quantidade

de tentativas sem sucesso, caso seja igual a 5 (limite

de tentativas) o sistema bloqueará o usuário, mudando

o status de liberado para bloqueado automaticamente.

Pós Condição Autorização (Pasta de acesso)

Interfaces Registro

Casos de Uso

Introdução a UML

Page 53: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

53

Descrição dos Cenários: Regras de Negócios

Casos de Uso

Regras de Negócios:

Autenticação: A senha será validada, seguindo as regras de negócios de Autenticação de

Senha:

1 - O usuário deve estar cadastrado no Aplicativo;

2 - A senha não pode estar expirada;

3 - O usuário deve ter um “status” de Liberado;

4 - A senha informada (criptografada) deve coincidir com senha gravada na tabela de

senhas. Autorização

5 - Somente o usuário detentor da senha poderá altera-lá

Introdução a UML

Page 54: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

54

Ator

Casos de Uso - Identicação de Atores

Os atores não são parte do sistema - eles representam qualquer um e qualquer

coisa que faça interação com sistema. Podendo ser uma pessoa, software,

hardware e etc.

Uma ator pode:

- Apenas fornecer informações ao sistema

- Apenas receber informações ao sistema

- Fornecer e receber informações ao sistema

Tipicamente os atores são identificados nas declarações de problemas ou através de

entrevistas com os usuários e outros analistas envolvidos no processo, como, Analista de

Sistema e Analista de Negócio, por exemplo.

As seguintes questões podem ser usadas para identificar o atores:

- Onde o sistema será usado ?

- Quais áreas serão usuárias do sistema ?

- O sistema usará recurso externo ?

- Quem será o responsável pelo sistema ?

- Quem serão os usuários do sistema ?

Introdução a UML

Page 55: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

55

Casos de Uso

Generalização:

Entre casos de uso é parecida à generalização existente entre as classes.

No caso de uso a generalização significa que o caso de uso filho herda o

comportamento e o significado do caso de uso pai; o filho poderá acrescentar ou

sobrescrever o comportamento de seu pai; poderá ser substituído em qualquer

local qual o pai apareça.

Include:

Quando você estiver se repetindo em dois ou mais caso de uso separados,

devemos evitar a repetição

Extends:

Quando estivermos descrevendo uma variação em comportamento normal,

entretanto, querendo fazer uma descrição mais controlada, explicando os pontos

de extensão no caso de uso.

Realizes:

Especifica a colaboração entre os casos de uso

Use (obsoleto): Especifica que a semântica do elemento de origem depende da

semântica da parte pública do destino

Diagramas da UML

Page 56: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

56

Explicando o estereotipo <<extend>>

Extend: Podemos usa-los em dois momentos

1 Variação

Cada uma das extensões descreve as diferentes maneiras com que um

passo do caso de uso pode ser executado. Exemplo:

Casos de Uso

Dinheiro

ReceberConta

CartaoCredito Cheque

<<extend>><<extend>> <<extend>>

2 Casos excepcionais

Condições de falha que podem ocorrer e serem recuperada em único

passo e requerem um caso de uso para sua descrição.

AlterarDisponibilidadeCarro ConsultarCliente

<<include>>

DevolvendoCarro

CalcularMulta

<<extend>><<include>>

Diagramas da UML

Page 57: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

57

Casos de Uso

PlaceOrder

<<include>>

Um relacionamento de inclusão entre casos de uso significa que o caso de uso base

incorpora explicitamente o comportamento de outro caso de uso em uma localização

especificada na base. O caso de uso incluído nunca permanece isolado, mas é apenas

uma “instance” como parte de alguma base maior que o inclui. Você pode pensar na

inclusão como o caso de uso base que o obtém o comportamento a partir do fornecedor

do caso de uso.

Você utiliza um relacionamento de inclusão para evitar descrever o mesmo fluxo de

eventos várias vezes, incluindo o comportamento comum em um caso de uso próprio. O

relacionamento de inclusão é essencialmente um exemplo de delegação, você coleta um

conjunto de responsabilidades do sistema e o captura um único local (o caso de uso

incluído); depois, permite que outras partes do sistema (outros casos de uso) incluam a

nova agregação de responsabilidade sempre que precisamos utilizar essa

funcionalidade.

Explicando o estereotipo <<include>>

TrackOrder

ValidateUser<<include>>

Diagramas da UML

Page 58: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

58

Locadora de carros

Uma locadora aluga carros aos clientes previamente cadastrados. Caso o cliente

não esteja cadastrado, esta atividade custodial é realizada, separadamente em

outra atividade do sistema. Caso um carro, disponível, seja escolhido pelo cliente

este é alugado, sendo registrada a data inicial junto ao aluguel. Para que o

cliente possa alugar um carro, este não pode estar com dívida pendente.

Os carros são descritos pela placa, ano, modelo, descrição, km, preço por km,

situação(disponível, etc), taxa diária, observações(informações gerais) e sua

imagem. Os clientes são cadastrados pelo seu cpf, nome, endereço, telefone e

dívida(reservado para registrar pagamentos pendentes).

Quando o cliente devolve o carro, a situação do carro é mudada para

“disponível”, o km é atualizado com o km atual do carro e um recibo é emitido,

baseado nos kms rodados e nos dias em que ficou com o carro. Ainda na

atividade de devolução é removido o registro do aluguel e, caso o cliente não

possa pagar, a dívida do aluguel é registrada junto ao cliente.

Exemplo: Casos de Uso

Diagramas da UML

Page 59: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

59

Objetivo:

Fazer locação de carros

Restrição:

Cliente não pode ter dividas pendentes

Atores:

Atendente

Entidade Custodial

Candidatos a Casos de Usos:

Cadastrar Cliente

Cadastrar Carro

VerificarDadosCliente

VerificarDividadoCliente

VerificarDisponibilidadeVeiculo

(Locar) EntregarVeiculo

(Devolução) ReceberVeículo

EmitirRecibo

RegistrarDivida

Candidatos a Classe:

Veículos

Clientes

Divida do Cliente

Locação

Empregado

Exemplo: Casos de Uso

Diagramas da UML

Page 60: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

60

Continuação:

Atores:

Atendente: Faz o atendimento ao cliente da Locadora

Entidade Custodial: Faz o cadastro da custódia do cliente

Candidatos a Casos de Usos:

Cadastrar (Cliente e Carro)

VerificarDadosCliente (Se é cliente e se tem divida)

VerificarDisponibilidadeVeiculo

EntregarVeiculo

ReceberVeículo

EmitirRecibo

RegistrarDivida

Candidatos a Classe:

Veículo

DadosdoCliente

DividadoCliente

Locação

Empregado

Exemplo: Casos de Uso

Diagramas da UML

Page 61: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

61

Diagrama de Caso de Uso

EntregarVeiculo

Verif icarDisponibilidadeVeiculo

<<include>>

Verif icarDadosCliente

<<include>>

SocilicarCadastro

EntidadeCustodia

<<extend>>

AlterarDisponibidadeVeiculo

ReceberVeiculo

<<include>>

ImprimirReciboRegistrarDiv ida

ReceberPagtoCliente

<<include>>

<<extend>>

<<extend>>

Atendente

CadastrarCadastrarCliente

CadastrarCarro

Exemplo: Casos de Uso

Diagramas da UML

Page 62: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

62

Cenário do Caso de Uso: VerificarDadosCliente

Casos de Uso

Nome: VerificarDadosCliente

Objetivo: Verificar se Cliente está cadastro no Sistema e e divida pendente

Pré-condição: Cliente solicitar uma locação

Ator: Atendente

Fluxo Normal:

1-O atendente solicita o número do CPF

2-Digita o CPF no sistema

3-O sistema verifica se cliente está cadastrado e se tem

divida pendente

4-O sistema envia mensagem cliente cadastrado e não

há divida

Fluxo Alternativo 1 (Cliente não cadastrado):

4-O sistema envia mensagem cliente não cadastrado

5-Solicita o cadastro da custódia do cliente

Fluxo Alternativo 2 (Cliente com divida):

4-O sistema envia mensagem cliente cadastrado e com

divida pendente

Diagramas da UML

Page 63: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

63

Diagrama de Seqüência

O que é Diagramas de Seqüência?

É um diagrama que exibe a colaboração dinâmica entre os vários objetos de um sistema.

O principal aspecto deste diagrama é que a partir dele percebe-se a seqüência de

mensagens enviadas entre os objetos. Ele mostra a interação entre os objetos, alguma

evento que acontecerá em um ponto específico da execução do sistema.

formulários

de registro

formulário

de matrícula

cursos

disponíveis

Ator (José) entrar com chave de

acessovalidar acesso

entrar com o

semestre

criar nova matrículaapresentar em tela

obter cursos

Diagrama de Seqüência

Introdução a UML

Explicando o diagrama:

O diagrama de seqüência consiste em um número de objetos mostrado em

linhas verticais. O decorrer do tempo é visualizado observando-se o

diagrama no sentido vertical de cima para baixo. As mensagens enviadas

por cada objeto são simbolizadas por setas entre os objetos que se

relacionam.

Diagramas de seqüência possuem dois eixos: o eixo vertical, que mostra o

tempo e o eixo horizontal, que mostra os objetos envolvidos na seqüência de

uma certa atividade. Eles também mostram as interações para um cenário

específico de uma certa atividade do sistema.

Page 64: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

64

Diagrama de Seqüência

Diagramas da UML

Diagrama de Seqüência

Explicando o diagrama (continuação)

No eixo horizontal estão os objetos envolvidos na seqüência. Cada um é

representado por um retângulo de objeto (similar ao diagrama de objetos)

e uma linha vertical pontilhada chamada de linha de vida do objeto,

indicando a execução do objeto durante a seqüência, como exemplo

citamos: mensagens recebidas ou enviadas e ativação de objetos. A

comunicação entre os objetos é representada como linha com setas

horizontais simbolizando as mensagens entre as linhas de vida dos

objetos. A seta especifica se a mensagem é síncrona, assíncrona ou

simples. As mensagens podem possuir também números seqüenciais,

eles são utilizados para tornar mais explícito as seqüência no diagrama.

Em alguns sistemas, objetos executam de forma concorrente, cada um

com sua linha de execução (thread). Se o sistema usa linhas concorrentes

de controle, isto é mostrado como ativação, mensagens assíncronas, ou

objetos assíncronos.

Os diagramas de seqüência podem mostrar objetos que são criados ou

destruídos como parte do cenário documentado pelo diagrama. Um objeto

pode criar outros objetos através de mensagens. A mensagem que cria ou

destrói um objeto é geralmente síncrona, representada por uma seta sólida

Page 65: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

65

Diagrama de Seqüência

Exemplo: EntregarVeiculo

: Atendente : Cliente : Veiculo : Locacao

getDadosCliente( )

[* se cliente cadastrado

verificar divida ]

getDivida( )

getDisponibilidade( )

[* se veículo

disponível ]

setSaida( )

Este diagrama descreve em ordem cronológica as mensagens entre os

objetos.

Neste momento estamos dizendo o como o Caso de Uso deve ser

implementado

Diagramas da UML

Page 66: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

66

Diagrama de Seqüência

Explicando os detalhes:

: Atendente : Cliente : Veiculo : Locacao

getDadosCliente( )

[* se cliente cadastrado

verificar divida ]

getDivida( )

getDisponibilidade( )

[* se veículo

disponível ]

setSaida( )

ator

Instance das classes

Linha do tempo

As interações entre os

objetos

Restrição ou

condição

Autodelegação

Diagramas da UML

Page 67: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

67

Diagrama de Colaboração

O que é Diagramas de Colaboração?

É um diagramas que mostra a colaboração dinâmica entre os objetos,

semelhante ao diagrama de seqüência. No diagrama de colaboração, além

de mostrar a troca de mensagens entre os objetos, percebe-se também os

objetos com os seus relacionamentos. A interação de mensagens é mostrada

em ambos os diagramas. Se a ênfase do diagrama for o decorrer do tempo, é

melhor escolher o diagrama de seqüência, mas se a ênfase for o contexto do

sistema, é melhor dar prioridade ao diagrama de colaboração. Podemos

também escolher ambos. O diagrama

de colaboração é desenhado como um diagrama de objeto, onde os diversos

objetos são mostrados juntamente com seus relacionamentos. As setas de

mensagens são desenhadas entre os objetos para mostrar o fluxo de

mensagens entre eles. As mensagens são nomeadas, que entre outras

coisas mostram a ordem em que as mensagens são enviadas. Também

podem mostrar condições, interações, valores de resposta, e etc. O diagrama

de colaboração também pode conter objetos ativos, que executam

paralelamente com outros.

6:obter cursos

Ator (José)

formulários de registro

2: validar acesso

1:entrar com chave

de acesso3:entrar com o

semestre

4:criar nova matrícula

formulário de matrículacursos disponíveis

5:apresentar

em tela

Diagrama de Colaboração

Diagramas da UML

NOTA: O diagrama de colaboração em alguns caso pode ser considerado opcional. Pode-se escolher entre utilizar o diagrama de colaboração

ou o diagrama de seqüência.

Page 68: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

68

Diagrama de Colaboração

: Atendente

: Cliente

: Veiculo :

Locacao

1: getDadosCliente( )

2: getDivida( )

3: getDisponibilidade( )

4: setSaida( )

Diagramas da UML

Page 69: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

69

Diagrama de Estado

O que é Diagrama de Estado?

É um diagrama que tipicamente complementa a descrição das classes.

Pois este diagrama exibe todos os estados possíveis que objetos de uma

certa classe podem se encontrar e mostra também quais são os eventos do

sistemas que provocam tais mudanças.

Não necessário escrever o diagrama de estado para todas as classes de

um sistema, mas apenas para aquelas que possuem um número definido

de estados conhecidos e onde o comportamento das classes é afetado e

modificado pelos diferentes estados.

Diagramas de estado capturam o ciclo de vida dos objetos, subsistemas e

sistemas. Eles mostram os estados que um objeto pode possuir e como os

eventos (mensagens recebidas, tempo, erros, e condições sendo

satisfeitas) afetam estes estados ao passar do tempo.

Registro fechado[númeroDeAlunos<3]

cancelarCurso

cancelarCursocancelarCurso

Registro fechado[númeroDeAlunos>=3]

Registro fechado [númerode alunos =10]^Curso.Criar relatório

Matrícula aberta/inicializenúmeroDeAlunos = 0

Curso Completadofaça: Gerar lista dealunos

Criaçãofaça: Crie oobjeto curso

Atribuição Cursofaça: Atribuir umprofessor ao curso

Curso AbertoEntrada: Registreum aluno

Adicionar Aluno

Curso Encerradofaça: relate cursoesta cheio

Curso Canceladofaça: envie notificaçãode cancelamento

cancelarCurso

Projeto e Modelagem Visual com UML

Page 70: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

70

Diagrama de Estado

Projeto e Modelagem Visual com UML

Diagramas de estado possuem um ponto de início e vários pontos de

finalização. Um ponto de início (estado inicial) é mostrado como um círculo

todo preenchido, e um ponto de finalização (estado final) é mostrado como

um círculo em volta de um outro círculo menor preenchido. Um estado é

mostrado como um retângulo com cantos arredondados. Entre os estados

estão as transições, mostrados como uma linha com uma seta no final de

um dos estados. A transição pode ser nomeada com o seu evento

causador. Quando o evento acontece, a transição de um estado para outro

é executada ou disparada.

Uma transição de estado normalmente possui um evento ligado a ela. Se

um evento é anexado a uma transição, esta será executada quando o

evento ocorrer. Se uma transição não possuir um evento ligado a ela, a

mesma ocorrerá quando a ação interna do código do estado for executada

(se existir ações internas como entrar, sair, fazer ou outras ações definidas

pelo desenvolvedor). Então quando todas as ações forem executadas pelo

estado, a transição será disparada e serão iniciadas as atividades do

próximo estado no diagrama de estados.

Verificando

Estado Transição Fim Inicio

Elementos

Page 71: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

71

Diagrama de Estado

Projeto e Modelagem Visual com UML

Exemplo: Diagrama de Estado Telefone

ocioso

início

Ativo

fora do gancho

no gancho

transição

Estado

Os diagramas de estados são compostos de transições e estados. As

transições são associadas com ações e são consideradas como processo

de curta duração e não podem ser interrompidos. Os estados são

associados com as atividades e podem levar mais tempo. Uma atividade

pode ser interrompida por algum evento.

Final

Page 72: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

72

Diagrama de Estado

Projeto e Modelagem Visual com UML

Aplicação

Um diagrama de estado pode ser aplicado a diversos elementos da UML, tais como:

- Classes

- Tipos (conceitos)

- Casos de Uso

Exemplo:

início

Verificando Expedindo

Aguardando

Cancelamento

cancelamento

Entregue

cancelado

[Todos os itens

verificados e

alguns itens não

estão disponíveis]

[Todos os itens verificados e

os todos itens disponíveis]

Item recebido

[os todos itens

disponíveis]

final

[Nem todos os itens verificados]/pegar

próximo item

[itens ecebidos

[alguns itens não

estão disponíveis]

Page 73: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

73

Diagrama de Atividade

O que é Diagrama de Atividade?

É um diagramas que exibe o fluxo seqüencial das atividades, é geralmente utilizado para

demonstrar as atividades executadas por uma operação específica do sistema, como por

exemplo seleção de um item do menu principal. Consistem em estados de ação, que

contém a especificação de uma atividade a ser desempenhada por uma operação do

sistema. Decisões e condições, como execução paralela, também podem ser mostrados

na diagrama de atividade. O diagrama também pode conter especificações de

mensagens enviadas e recebidas como partes de ações executadas.

Diagramas de atividade capturam ações e seus resultados. Eles focam o trabalho

executado na implementação de uma operação (método), e suas atividades numa

instância de um objeto. O diagrama de atividade é uma variação do diagrama de estado e

possui um propósito um pouco diferente do diagrama de estado, que é o de capturar

ações (trabalho e atividades que serão executados) e seus resultados em termos das

mudanças de estados dos objetos.

Projeto e Modelagem Visual com UML

Fazer Pedido

Cliente

Processar Pedido

Separar Produtos

Enviar Pedido

Cobrar Cliente

Fechar Pedido

Receber Pedido

Pagar Fatura

Vendas Estoque

Page 74: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

74

Os estados no diagrama de atividade mudam para um próximo estágio quando uma

ação é executada (sem ser necessário especificar nenhum evento como no diagrama de

estado). Outra diferença entre o diagrama de atividade e o de estado é que podem ser

colocadas como swimlanes (raias). Uma swimlane agrupa atividades, com respeito a

quem é responsável e onde estas atividades residem na organização, e é representada

por retângulos que englobam todos os objetos que estão ligados a ela (swimlane).

Um diagrama de atividade é uma maneira alternativa de se mostrar interações, com a

possibilidade de expressar como as ações são executadas, o que elas fazem

(mudanças dos estados dos objetos), quando elas são executadas (seqüência das

ações), e onde elas acontecem (swimlanes).

Um diagrama de atividade pode ser usado com diferentes propósitos inclusive:

Para capturar os trabalhos que serão executados quando uma operação é

disparada (ações). Este é o uso mais comum para o diagrama de atividade.

Para capturar o trabalho interno em um objeto.

Para mostrar como um grupo de ações relacionadas podem ser executadas, e

como elas vão afetar os objetos em torno delas.

Para mostrar como uma “instance” pode ser executada em termos de ações e

objetos.

Para mostrar como um negócio funciona em termos de trabalhadores (atores),

fluxos de trabalho, organização, e objetos (fatores físicos e intelectuais usados no

negócio).

Enfim o diagrama de atividade mostra o fluxo seqüencial das atividades, é normalmente

utilizado para demonstrar as atividades executadas por uma operação específica do

sistema. Consistem em estados de ação, que contém a especificação de uma atividade

a ser desempenhada por uma operação do sistema. Decisões e condições, como

execução paralela, também podem ser mostrados na diagrama de atividade. O

diagrama também pode conter especificações de mensagens enviadas e recebidas

como partes de ações executadas.

Projeto e Modelagem Visual com UML

Diagrama de Atividade

Page 75: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

75

Exemplo:

Diagrama de Atividades

Projeto e Modelagem Visual com UML

Diagrama de Atividade

Page 76: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

76

Diagrama de Atividade

Componentes:

Projeto e Modelagem Visual com UML

Fazer Pedido

Cliente

Processar Pedido

Separar Produtos

Enviar Pedido

Cobrar Cliente

Fechar Pedido

Receber Pedido

Pagar Fatura

VendasEstoque

raias

junção

separação

atividade

Atividade

atividade transição decisãoBarras de

sincronização

Exemplo com comentários:

Page 77: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

77

Diagrama de Atividade

Projeto e Modelagem Visual com UML

Exemplo com comentários:

Receber Pedido

Preencher Pedido

Receber Pagamento

Enviar Fatura

Entrega durante

a noiteEntrega Regular

[pedido urgente] [senão]

Encerrar Pedido

Entrega

Page 78: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

78

Diagrama de Pacotes

Como podemos definir o diagrama de pacotes?

A definição de Pacote é uma generalização, ou seja, um agrupamento, com o propósito de

organizar as Classes de Objetos em grupos. Esta abordagem facilita a análise a medida

que o número de Classes de Objetos cresce num do cenário. O tipo de relacionamento é

linha pontilhada com uma seta que indica dependência.

A notação usada pela UML para representar pacotes é:

Nome do Pacote

Exemplo: As classes pertencentes ao Sistema de Matrícula podem ser agrupadas em três

pacotes:

• UI (Interface Usuário)

• Regras de Negócio

• Interfaces de Banco de Dados

Interfaces de

Banco de Dados

{abstrata}

Interfaces com

UsuárioRegras de

Negócios

Interface

MySQL

Introdução a UML

Page 79: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

79

Podemos usar a estrutura de pacotes para criar coesão entre as classes que tem objetivo

comum, por exemplo podemos colocar em único pacote todas as classes que se referem a

regras de negócios.

Exemplo:

Fisicamente os pacotes tem a estrutura de diretório e subdiretório, isto que dizer que

a Aplicação terá a seguinte formato:

Aplicação

Regras de Negócios

Interface de Usuário

Controle

Aplicação

Interface de Usuário

ControleRegras de Negócios

Diagrama de Pacotes

Projeto e Modelagem Visual com UML

Page 80: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

80

Diagrama de Classes

O que é um Diagrama de Classes?

É um diagrama que demonstra a estrutura estática das classes de um sistema e seus

relacionamentos. Classes podem se relacionar com outras através de diversas maneiras:

associação (conectadas entre si), dependência (uma classe depende ou usa outra classe),

especialização (uma classe é uma especialização de outra classe), ou em pacotes

(classes agrupadas por características similares). Todos estes relacionamentos são

mostrados no diagrama de classes juntamente com as suas estruturas internas, que são

os atributos e operações. O diagrama de classes é considerado estático já que a estrutura

descrita é sempre válida em qualquer ponto do ciclo de vida do sistema. Um sistema

normalmente possui alguns diagramas de classes, já que não são todas as classes que

estão inseridas em um único diagrama e uma certa classes pode participar de vários

diagramas de classes.

1..*

1

1

tem

Professores

Pessoa

AlunosFuncionários

Administrativo

Curso

Disciplinas

Matricula11

1

Uma classe num diagrama pode ser diretamente implementada utilizando-se uma

linguagem de programação orientada a objetos que tenha suporte direto para

construção de classes. Para criar um diagrama de classes, as classes têm que estar

identificadas, descritas e relacionadas entre si.

Introdução a UML

Page 81: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

81

Diagrama de Objetos

O que é um Diagrama de Objetos?

É um diagrama que exibe uma variação do diagrama de classes e utiliza quase a mesma

notação. A diferença é que o diagrama de objetos mostra os objetos que foram

“instanciados” das classes. O diagrama de objetos é como se fosse o perfil do sistema em

um determinado momento de sua execução. A mesma notação do diagrama de classes é

utilizada, entretanto há duas diferenças: os objetos são escritos com seus nomes

sublinhados e todas as instâncias num relacionamento são mostradas. Os diagramas de

objetos não tem a mesma importância do diagramas de classes, mas eles são muito úteis

para exemplificar diagramas complexos de classes ajudando muito em sua compreensão.

Diagramas de objetos também são usados como parte dos diagramas de colaboração,

onde a colaboração dinâmica entre os objetos do sistema são mostrados.

Nome: “Fulano de Tal”

Data: 23-02-2001

:Aluno

Matricula: 201-23-02-01

Curso: Adm Empresas

201-23-02-01:Matricula

Introdução a UML

Page 82: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

82

Diagrama de Classes

Diagramas da UML

Page 83: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

83

Mapeamento do Diagrama de Classes e Modelo de Entidades e

Relacionamento

MER

Entidades

Relacionamentos

Atributos

Roles

Constraints

Generalização e

Especialização

UML

Classes Persistentes

Associação

Atributos

Roles

Multiplicidade

Generalização e

Especialização

Veja a tabela abaixo que relaciona as característica da UML e MER:

Pessoa

-idpessoa

-nome

Pessoa

Idpessoa <pk>

nome

Classe persistente Entidade

Os atributo de uma classe persistente são mapeado para colunas de entidade

Diagramas da UML

Page 84: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

84

Mapeamento Diagrama de Classes e Modelo de Entidades e

Relacionamento

Um exemplo de mapeamento Diagrama de classe (UML) e entidade (MER)

Pessoa

-nome

-idade

Funcionário

funcao

{abstract}

ClienteIdcliente

telefone

Classes

Veja agora o mapeamento para entidade MER, para cada classe criaremos uma

entidade correspondente:

Pessoa

idpessoa <pk>

nome

idade

Funcionário Cliente

é um

idpessoa <fk>

funcao

idpessoa <fk>

idcliente <pk>

telefone

é um

Diagramas da UML

Page 85: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

85

Mapeamento Diagrama de Classes e Modelo de Entidades e

Relacionamento

Neste exemplo o mapeamento é feito para duas entidades:

Funcionário

idfunc <pk>

nome

idade

funcao

Cliente

idcliente <pk>

nome

idade

telefone

Diagramas da UML

Page 86: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

86

Diagrama de Componente

O que é um Diagrama de Componente?

É um diagrama que exibe o sistema por um lado funcional, expondo as

relações entre seus componentes e a organização de seus módulos durante

sua execução.

O diagrama de componente descreve os componentes de software e suas

dependências entre si, representando a estrutura do código gerado. Os

componentes são a implementação na arquitetura física dos conceitos e da

funcionalidade definidos na arquitetura lógica (classes, objetos e seus

relacionamentos). Eles são tipicamente os arquivos implementados no

ambiente de desenvolvimento.

Curso.jar Pessoa.jar

Aluno.class Professores.classDisciplina.classr

Introdução a UML

Um componente é mostrado em UML como um retângulo com uma elipse e

dois retângulos menores do seu lado esquerdo. O nome do componente é

escrito abaixo ou dentro de seu símbolo.

Componentes são tipos, mas apenas componentes executáveis podem ter

instâncias. Um diagrama de componente mostra apenas componentes como

tipos. Para mostrar instâncias de componentes, deve ser usado um diagrama

de execução, onde as instâncias executáveis são alocadas em nodes.

Page 87: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

87

Diagrama de Componente

Introdução a UML

A dependência entre componentes pode ser mostrada como uma linha

tracejada com uma seta, simbolizando que um componente precisa do outro

para possuir uma definição completa. Com o diagrama de componentes é

facilmente visível detectar que arquivos .jar são necessários para executar a

aplicação.

Componentes podem definir interfaces que são visíveis para outros

componentes. As interfaces podem ser tanto definidas ao nível de codificação

(como em Java) quanto em interfaces binárias usadas em run-time (COM).

Uma interface é mostrada como uma linha partindo do componente e com um

círculo na outra extremidade. O nome é colocado junto do círculo no final da

linha. Dependências entre componentes podem então apontar para a

interface do componente que está sendo usada.

Reserva.jar Pessoa.jar

PessoaFisica.PessoaJuridicaCheckIN

Exemplo:

Page 88: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

88

Diagrama de Distribuição

O que é Diagrama de Distribuição?

É um diagrama que exibe a arquitetura física do hardware e do software no sistema.

Pode apresentar os atuais computadores e periféricos, juntamente com as conexões que

eles estabelecem entre si e pode mostrar também os tipos de conexões entre esses

computadores.

Especifica-se também os componentes executáveis e objetos que são alocados para

mostrar quais unidades de software são executados e em que destes computadores são

executados.

O diagrama de distribuição demonstra a arquitetura runtime de processadores,

dispositivos físicos e de software que executam no ambiente onde o sistema

desenvolvido será utilizado. É o último diagrama da topologia do sistema, descrevendo

a estrutura de hardware e software que executam em cada unidade.

O diagrama de distribuição é composto por componentes, que possuem a mesma

simbologia dos componentes do diagrama de componentes, nodes, que significam

objetos físicos que fazem parte do sistema, podendo ser uma computador cliente em

uma Rede, um computador Servidor, uma impressora, um roteador, etc., e conexões

entre estes nodes e componentes que juntos compõem toda a arquitetura física do

sistema.

Cliente AServidor

de Aplicação

Servidor

de Banco de

Dados

<<TCP/IP>><<TCP/IP>>

0..* 1 1 1

Projeto e Modelagem Visual com UML

Page 89: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

89

Diagrama de Distribuição

Exemplo:

Projeto e Modelagem Visual com UML

Cliente

Servidor

Firewall

Banco de Dados

Web

Oracle Server

Apache sob Linux

HTPP

HTPP

*

1

Banco de Dados

Corporativo

MySQL

Page 90: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

90

Projeto de Desenvolvimento:

Um exemplo

Page 91: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

91

Exemplo de Projeto de Desenvolvimento com UML

Projeto de Desenvolvimento

Fases do Desenvolvimento

O desenvolvimento de um sistema de informação, de acordo com metodologia rápida, é

divido em duas etapas: enquanto a primeira fase, Definição de Requisitos, tem por objetivo

determinar os requisitos, a segunda Análise, tem a finalidade de definir os módulos

componentes do sistema.

Definição dos Requisitos

O objetivo desta fase é determinar a funcionalidade esperada pelo usuário do sistema.

Num projeto de construção civil, esta fase corresponderia ao projeto de arquitetura, onde

se descrevem as características da casa que são visíveis ao seu morador. O produto

desta fase é chamado de Modelo de Requisitos.

A estrutura do Modelo de Requisitos é exibida na figura abaixo. Cada uma das caixas

representa um ou mais documentos que devem ser apresentados no final da fase. O

diagrama indica que o modelo de Requisitos é composto de: Modelo de Casos de Uso,

uma protótipo e um Glossário.

Por sua vez, o Modelo de Casos de uso é composto de diagramas de caso de uso, cada

destes contém uma descrição para o caso de uso.

Modelos de Requisitos

Diagrama de Casos de

UsoProtótipo Glossário

Casos de Uso

Descrição do Caso

de Uso

1..*

1..*

Page 92: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

92

Segunda fase: Análise e Projeto

O objetivo desta fase é produzir um plano que permita a construção do sistema. Por

exemplo, comparando mais uma vez a engenharia civil, esta fase corresponderia às

plantas detalhadas da construção de uma casa.

Em termos de software, a planta do sistema é a especificação de suas classes

componentes, que chamamos de Modelo de Análise e Projeto.

O Modelo de Análise e Projeto é composto pelo Modelo Estático e pelo Modelo Dinâmico.

O modelo estático é composto por um conjunto de diagramas de classes.

O Modelo Dinâmico é composto por conjuntos de Diagramas de Seqüência e Diagrama

de Estados.

Modelos de Análise e

Projeto

Modelo Estático Modelo Dinâmico

Diagrama de Classes

Classes

Diagrama de Sequência Diagrama de Estado

1..*

1..*

1..* 1..*

Projeto de Desenvolvimento

Exemplo de Projeto de Desenvolvimento com UML

Page 93: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

93

Roteiro para o Desenvolvimento de Sistema usando a Metodologia Rápida

1 - Definir o escopo do Sistema;

2 - Produzir o Modelo de Requisitos

2.1 - Identificar os casos de usos

2.2 - Identificar os atores

2.3 - Identificar e definir as entidades do domínio do problema

2.4 - Definir os casos de uso que podem ser abstraídos

2.5 - Fazer agrupamento dos casos de uso com semântica semelhante

2.6 - Verificar o Modelo de Requisitos

3 - Produzir o Modelo de Análise e Projeto, executando as seguintes etapas:

3.1 - Criar um diagrama com modelo de classes do domínio do problema;

3.2 - Criar um diagrama com o modelo de classes de cada agrupamento de casos

de uso. Este modelo deve conter as classes de domínio, interface e controle

envolvidas no agrupamento de casos de uso.

3.3 - Fazer um diagrama de seqüência para cada agrupamento de caso de uso.

3.4 - Criar um diagrama de transição e estados para as classes de domínio,

interface e controle que tenham ciclos de vida não-triviais.

3.5 - Revisar o diagrama de classes (reveja os relacionamentos)

3.6 - Verificar o modelo de Análise e Projeto.

Projeto de Desenvolvimento

Exemplo de Projeto de Desenvolvimento com UML

Page 94: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

94

Estudo de Caso

e Exercício

Page 95: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

95

Estudo de Caso

Caso Prático

• A Universidade ESU quer informatizar seu sistema de matrícula

– A Secretaria produz o currículo para o semestre

– Os Alunos selecionam 4 matérias principais e 2 matérias

alternativas

– Após a matrícula, o sistema de cobranças será notificado para

que receba o pagamento do estudante por um semestre

– Os Alunos podem usar o sistema para adicionar ou remover

matérias por um determinado período após a matrícula

– Os Professores usam o sistema para receber a lista de ofertas

de cursos

– Os usuários do sistema de matrícula tem senhas que são

utilizadas para validação de logon

Page 96: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

96

Atores

• Um Ator é alguém ou alguma coisa que deve interagir com o sistema

a ser desenvolvido

Aluno

Secretaria

Professor

Sistema Cobrança

Estudo de Caso

Page 97: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

97

Casos de Uso:

• Um caso de uso é um padrão de comportamento que o sistema exibe

– Cada caso de uso é uma seqüência de transações relacionadas

executadas por um ator e o sistema num diálogo

• Atores são examinados para determinar suas necessidades

– Secretaria -- manter o curriculum

– Professor -- solicitar lista de cursos

– Aluno -- manter o horário de aulas

– Sistema Cobrança -- recebe informações sobre cobranças

Manter Horário

Manter Curriculum

Solicitar Lista de Cursos

Estudo de Caso

Page 98: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

98

Documentando Caso de Uso

• Um documento de fluxo de eventos é criado para cada caso de uso

– Escrito do ponto de vista do ator

• Detalha o que o sistema deve fornecer quando o caso de uso é

executado

• Conteúdos típicos

– Como o caso de uso inicia e termina

– Fluxo normal de eventos

– Fluxos alternativos de eventos

– Fluxos excepcionais de eventos (respostas a erros)

Fluxo de Eventos de Manter Curriculum

• Este caso de uso inicia quando a Secretaria entra no sistema e entra

sua senha. O sistema verifica se a senha é válida (E-1) e solicita a

escolha do semestre atual ou futuro (E-2). A Secretaria entra o

semestre desejado. O sistema pergunta qual a atividade desejada:

INCLUIR, APAGAR, MODIFICAR, ou SAIR.

• Caso a atividade selecionada seja INCLUIR, o S-1: O sub-fluxo

Inclui uma Matéria é executado.

• Caso a atividade selecionada seja APAGAR, o S-2: O sub-fluxo

Apaga uma Matéria é executado.

• Caso a atividade selecionada seja MODIFICAR, o S-3: O sub-fluxo

Modificar uma Matéria é executado.

• Caso a atividade selecionada seja SAIR, o caso de uso termina.

• ...

Estudo de Caso

Page 99: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

99

Diagrama de Caso de Uso

• Diagramas de caso de uso são criados para se visualizar a relação

entre atores e casos de uso

Aluno

Secretaria

Professor

Mantém Horário

Mantém Curriculum

Solicita Lista de Cursos

Sistema Cobrança

Estudo de Caso

Page 100: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

100

Usos e Extensões das Relações de Casos de Uso

• À medida em que casos de uso são documentados, outras relações

entre casos de uso poderão ser descobertas

– Uma relação de uso (usa) mostra comportamento que é comum a

um ou mais casos de uso

– Uma relação de extensão mostra comportamento opcional

Matricular para cursos

<<extends>>

Validar Senha<<extends>>

Manter Curriculum

Estudo de Caso

Page 101: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

101

Realizações de Casos de Uso:

• O Diagrama de Caso de Uso apresenta uma visão externa do sistema

• Diagramas de Interação descrevem como casos de uso são

realizados como interações entre associações de objetos

• Há dois tipos de Diagramas de Interação

– Diagramas de Seqüência

– Diagramas de Colaboração

Diagrama de Seqüência:

• Um Diagrama de Seqüência mostra interações de objetos ordenados

numa seqüência de tempo

: Aluno

1: preenche

2: envia

3: curso(Maria,matemática)

4: está aberto?

5: está aberto?6: incui(Maria l)

7: incui (Maria)

Formulário de

Matrúcula

Gerente de

Matrículas

Matemática

Básica

Matemática

Álgebra

Tempo

Estudo de Caso

Page 102: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

102

• Um Diagrama de Colaboração mostra interações organizadas à volta de

objetos e as ligações de um para o outro

Diagrama de Colaboração

: Secretaria

curso form : cursoForm

Diretor : Diretor_do_Curso

acurso : curso

1: pega informação curso 2: processa

3: incui curso

4: novo curso

Estudo de Caso

Page 103: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

103

Diagrama de Classes

• Um Diagrama de Classes mostra a existência de classes e suas

relações com a visão lógica do sistema

• Elementos de UML presentes nos Diagramas de Classes:

– Classes, suas estruturas internas e comportamento

– Associações, agregações, dependências, e relações de

herança

– Multiplicidade e indicadores de navegação

– Nomes de papéis (O que uma classe representa para outra)

Classes

• Uma classe é uma coleção de objetos com um estrutura,

comportamento, relações e semântica comuns

• Classes são descobertas pelo exame dos objetos nos diagramas

de Seqüência e Colaboração

• Uma classe é desenhada como um retângulo com três

compartimentos:

– Primeiro: Nome da classe

– Segundo: Atributos (opcional)

– Terceiro: Métodos (opcional)

• Classes devem ser nomeadas usando o vocabulário do domínio

– Padrões de nomenclatura devem ser estabelecidos

– Regra: Todos os nomes de classes são substantivos no

singular, iniciando com letra maiúscula

Exemplo: Cliente, Fornecedor, Pessoa, Aluno e etc.

Estudo de Caso

Page 104: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

104

Diretor Matrícula

Formulário Matrícula

Professor

Aluno

Oferta Curso

Curso

Algorítmo de Horário

Classes:

Estudo de Caso

Page 105: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

105

• O comportamento de uma classe é representado pelas suas operações

• Operações podem ser encontradas examinando-se os Diagramas de

Interação

Matrícula form

Matrícula Gerente

3: matricula curso(Maria, matemática)

Diretor Matrícula

Matricula (aluno,curso)

Classes:

Atributos:

Cada Curso oferecido

possui um número,

local e horário

Oferta Curso

número

local

horário

Estudo de Caso

Page 106: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

106

Classes

curso

nome

NúmeroCréditos

abrir()

incluirAluno(AlunoInfo)

Alunonome

nível

Professornome

StatusCadeira

Algorítmo de Horário

Formulário Matrícula

Diretor Matrícula

incluiAluno(curso, AlunoInfo)

Oferta Cursolocal

abrir()

incluirAluno(AlunoInfo)

Estudo de Caso

Page 107: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

107

Relacionamento:

• Relações fornecem um caminho para a comunicação entre os objetos

• Diagramas de seqüência e/ou colaboração são examinados para

determinar quais ligações entre objetos precisam existir para se chegar

ao comportamento desejado. -- Caso dois objetos precisem

“conversar” deverá haver uma ligação entre elas

• Há três tipos de relações:

– Associação e Agregação

– Dependência

– Herança

• Uma associação é uma conexão bidirecional entre classes

– Uma associação é mostrada como uma linha conectando as

classes relacionadas.

• Uma agregação é um tipo mais forte de conexão, aonde a relação é

entre o todo e suas partes.

– Uma agregação é mostrada como uma linha conectando as

classes relacionadas com um losango perto da classes que

representa o todo

• Uma relação de dependência é uma forma mais fraca de relação,

mostrando uma relação entre um cliente e um fornecedor, aonde o

cliente não tem conhecimento semântico do fornecedor

– Uma dependência é mostrada como uma linha pontilhada entre

o cliente e o fornecedor

Associação:

Estudo de Caso

Page 108: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

108

Descobrindo os Relacionamentos:

• Relações são descobertas examinando-se os Diagramas de Sequência

– Caso dois objetos devam “conversar”, deverá haver um caminho

para a comunicação

Diretor Matrícula

Álgebracurso

3: insere aluno(Maria)

Diretor Matrúcula

curso

Estudo de Caso

Page 109: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

109

Diretor Matrícula

incluiAluno(curso, AlunoInfo)

Alunonome

nível

Oferta Cursolocal

abrir()

incluirAluno(AlunoInfo)

Professornome

StatusCadeira

Algorítmo de Horário

Formulário Matrículacurso

nome

NúmeroCréditos

abrir()

incluirAluno(AlunoInfo)

Relacionamento:

Estudo de Caso

Page 110: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

110

Multiplicidade e Navegação:

• Multiplicidade define como muitos objetos participam numa relação

– Multiplicidade é o número de instâncias de uma classe que se

relacionam a UMA instância de uma outra classe

– Para cada associação e agregação, haverá duas decisões

relativas a multiplicidade a se tomar: Uma para cada lado da

relação

• Apesar de associações e agregações serem bidirecionais por

definição, freqüentemente é desejável restringir a navegação em uma

única direção

– Caso a navegação seja restringida, uma seta é adicionada para

se indicar a direção da navegação

Estudo de Caso

Page 111: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

111

Multiplicidade e Navegação:

Diretor Matrícula

incluiAluno(curso, AlunoInfo) curso

nomeNúmeroCréditos

abrir()incluirAluno(AlunoInfo)

Alunonomenível

Oferta Cursolocal

abrir()incluirAluno(AlunoInfo)

ProfessornomeStatusCadeira

Algorítmo de Horário

Formulário Matrícula0..*

1 10..*

1

1..*

3..10

1

4

0..4

Estudo de Caso

Page 112: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

112

Herança

• Herança é uma relação entre uma super-classe e suas subclasses

• Há duas formas de se descobrir heranças:

– Generalização

– Especialização

• Atributos comuns, operações, relações e/ou, são mostradas no nível

aplicável mais alto da hierarquia

nome

Usuário

Formulário Matrícula Algorítmo de Horário

Diretor Matrícula

incluiAluno(curso, AlunoInfo)

Oferta Cursolocal

abrir()incluirAluno(AlunoInfo)

Alunonomenível

curso

nomeNúmeroCréditos

abrir()incluirAluno(AlunoInfo)

ProfessornomeStatusCadeira

Estudo de Caso

Page 113: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

113

O Estado de um Objeto

• Um diagrama de transição de estados mostra

– O ciclo de vida de uma classe

– Os eventos que causam a transição de um estado para outro

– As ações que resultam de uma mudança de estado

• Diagramas de Transição de Estados são criados para objetos que

tenham um comportamento dinâmico significante

Iniciar AçãoAbrir

entrar: Registrar AlunoSair: incrementa contador

Fechado

Cancelado

fazer: Iiniciar curso

fazer: Finalize curso

fazer: Notificar Aluno Matriculado

Incluir Aluno /Contador = 0

Inclui aluno[ contador < 10 ]

[ contador = 10 ]

Cancelar

Cancelar

Cancelar

Diagrama de Transições de Estados

Estudo de Caso

Page 114: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

114

O Mundo Físico

• Diagramas de Componentes ilustram a organização e

dependências entre componentes de software

• Um componente pode ser:

– Um componente de código fonte

– Um componente de runtime, ou

– Um componente executável

Estudo de Caso

Page 115: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

115

Curso.class Oferta

curso.classAluno.class Professor.class

Diagrama de Componentes

curso.jar pessoa.jar

curso

Usuário

RegistroCobrança

Sistema

Cobrança

Estudo de Caso

Page 116: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

116

Distribuindo o Sistema

• O Diagrama de Distribuição mostra a configuração dos elementos de

processamento runtime e dos processos que rodam dentro deles

• O Diagrama de Distribuição visualiza a distribuição dos componentes

através de toda a empresa

Matrícula Database

Biblioteca

Salas

SedePrincipal

Diagrama de Distribuição

Estudo de Caso

Page 117: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

117

Exercício

O Hotel “Só quero Sossego” está precisando de sistema para

automatizar suas principais atividades e facilitar o gerenciamento de

suas operações.

O hotel contém um número de apartamentos disponíveis para

serem alugados aos hospedes. Cada apartamento tem as seguintes

características:

- Número, preços base, capacidade de pessoas

- Tipo (Single, double, triplo ou suíte)

O preço de cada apartamento está relacionado com seu tipo e

sazonalidades (períodos especiais, tais como: férias, natal,

carnaval...)

Um hospede pode fazer reserva de mais de um apartamentos

através do telefone, Internet ou pessoalmente no balcão de reserva

do Hotel . As reversas devem ser registras no livro de reservas, que

deve conter as seguintes informações:

- Tipo de apartamento, período, duração da estadia e data da

reserva. A reserva somente é confirmada após a verificação da

disponibilidade do apartamento na data informada. O cliente deve

receber as seguintes informações se confirmada a reserva:

- Preço e detalhes sobre hotel. Caso contrário deve receber a

informação que não foi possível fazer a reserva para data

informada.

Declaração do Problema:

Page 118: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

118

- As reservas também podem ser feitas diretamente na

Recepção do Hotel.

No Check-in o hospede é identificado juntamente com sua

reserva.

No Check-out verifica-se todos os serviços prestados ao

hospede e as despesas advindas desses serviços tais como:

lavandeira, restaurante, telefonia, assim como a consumação do

“frigobar”.

O cliente poderá pagar a conta com cartão de crédito, dinheiro,

cheque ou cheque de viagens.

A disponibilidade deseja para o sistema é de 24x7 para

Internet, as interfaces com usuários devem ser simples e

sistema deve seguir o padrão de Identidade Visual (Manual de

Identidade Visual).

O sistema deve implementar um nível de segurança que garanta

que somente o usuário que possuir uma senha (esta deve ser

criptografa) poderá fazer alterações nos dados da reserva ou

alterar seus cadastrais.

Exercício:

- Fazer o Diagrama de Caso de Reserva

- Fazer o Diagrama de Seqüência

- Fazer o Diagrama de Classes (Classes de Negócio)

- Fazer o Diagrama de Projeto (Refinamento de Casses)

- Fazer o Diagrama de Competentes

Declaração do Problema (continuação):

Exercício

Page 119: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

119

Apêndice

Page 120: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

120

SÍMBOLO GRÁFICO NOMEDIAGRAMAS EM QUEAPARECE USUALMENTE

MODELO A QUEPERTENCEM

ASSOCIAÇÂO DEAGREGAÇÃO

Diagrama de Classes,Diagrama de Componentes.

Classes de Objetos

Componentes

ASSOCIAÇÂO DECOMPOSIÇÃO

Diagrama de Classes,

Diagrama de Componentes.

Classes de Objetos

Componentes

ASSOCIAÇÂO DEDEPENDÊNCIA

Diagrama de Casos de Uso,Diagrama de Classes,Diagrama de Componentes,Diagrama de Implantação.

Caso de Uso

Classes de Objetos

Componentes

Componentes

ASSOCIAÇÂO DEGENERALIZAÇÃO

Diagrama de Casos de Uso,

Diagrama de Classes.

Caso de Uso

Classes de Objetos

ASSOCIAÇÂOREGULAR

Diagrama de Casos de Uso,Diagrama de Classes,Diagrama de Componentes,Diagrama de Implantação.

Caso de Uso

Classes de Objetos

Componentes

Componentes

ATORDiagrama de Casos de Uso,Diagrama de Seqüência.

Caso de Uso

Caso de Uso

CASO DE USO Diagrama de Casos de Uso. Caso de Uso

CLASSE Diagrama de Classes. Classes de Objetos

COMPONENTE Diagrama de Componentes Componentes

Nome do EstadoESTADO

Diagrama de Estados,

Diagrama de Atividades.

Classes de Objetos

Caso de Uso

ESTADO FINAL

Diagrama de Estados,

Diagrama de Atividades

Classes de Objetos

Caso de Uso

Nome da Classe

Atributos

Operações

Nome do Componente

Apêndice A

Notação UML

Page 121: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

121

ESTADO INICIALDiagrama de Estados,Diagrama de Atividades.

Classes de Objetos

Caso de Uso

Nome da “Interface” ou

“INTERFACE”Diagrama de Componentes Componentes

INTERVALO DEEXECUÇÃO DE

OPERAÇÂODiagrama de Seqüência Caso de Uso

MENSAGEM DERETORNO

Diagrama de Seqüência Caso de Uso

MENSAGEM ECHAMADA DEOPERAÇÂO“Síncrona”

Diagrama de Seqüência Caso de Uso

MENSAGEM ECHAMADA DEOPERAÇÃO“Assíncrona”

Diagrama de Seqüência Caso de Uso

NÓ Diagrama de Implantação Componentes

texto NOTA Em qualquer diagrama

identificador:Classe ou :Classe

OBJETODiagrama de Seqüência,

Diagrama de Atividades

Caso de Uso

Caso de Uso

Nome do Pacote PACOTE

Em qualquer diagrama em que énecessário representar umconjunto de coisas que devemestar agrupadas para efeito deuma organização apropriada

TRANSIÇÃO DEESTADO

Diagrama de Estados,

Diagrama de Atividades

Classes de Objetos

Caso de Uso

AUTODELEGAÇÃO Diagrama de Seqüência Caso de Uso

<<interface>> Nome da “Interface”

Operação1 ()Operação2 ()

Operação3 ()

Apêndice A

Notação UML

Page 122: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

122

Apêndice B

UML 2.0

Visão Descreve Diagramas

Visão de Requisitos

Funcionais

Requisitos funcionais do

sistema pelo ponto de vista

do usuário.

diagramas de casos de uso

Visão Estrutural

Estática

Estrutura estática do

sistema.

diagrama de classes

diagrama de estruturas

Visão de

Comportamento

Dinâmico

Comportamento dinâmico

do sistema, mostrando

suas interações.

diagramas de seqüências

diagramas de atividades

diagramas de estados

Visões UML 2.0:

Diagramas:

Page 123: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

123

Notas:

Marcas Registradas:

Todos os termos mencionados e reconhecidos como Marca Registrada e/ou

comercial são de responsabilidade de seus proprietários. O autor informa não estar

associada a nenhum produto e/ou fornecedor apresentado neste material. No decorrer

deste, imagens, nomes de produtos e fabricantes podem ter sido utilizados, e desde já

o autor informa que o uso é apenas ilustrativo e/ou educativo, não visando ao lucro,

favorecimento ou desmerecimento do produto/fabricante.

É proibido o uso deste material para fins comerciais.

Melhoria e Revisão:

Este material esta em processo constante de revisão e melhoria, se você encontrou

algum problema ou erro envie um e-mail nós.

Criticas e Sugestões:

Nós estamos abertos para receber criticas e sugestões que possam melhorar o

material, por favor envie um e-mail para nós.

Rildo F dos Santos ([email protected])

Imagens:

Google, Flickr e Banco de Imagem.

Page 124: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

124

Licença:

Page 125: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

125

Licença:

Page 126: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UML

126

Marcas Registradas:

Todos os termos mencionados e reconhecidos como Marca

Registrada e/ou comercial são de responsabilidade de seus

proprietários. O autor informa não estar associada a nenhum produto

e/ou fornecedor apresentado neste material. No decorrer deste,

imagens, nomes de produtos e fabricantes podem ter sido utilizados,

e desde já o autor informa que o uso é apenas ilustrativo e/ou

educativo, não visando ao lucro, favorecimento ou desmerecimento

do produto/fabricante.

Melhoria e Revisão:

Este material esta em processo constante de revisão e melhoria, se

você encontrou algum problema ou erro envie um e-mail nós.

Criticas e Sugestões:

Nós estamos abertos para receber criticas e sugestões que possam

melhorar o material, por favor envie um e-mail para nós.

Rildo F dos Santos ([email protected])

Imagens:

Google, Flickr e Banco de Imagem.

Notas do autor

Page 127: Unified Modeling Language - UML

Linguagem de Modelagem Unificada

© Copyright Rildo Ferreira, e-tecnologia.com, 2009

UMLUML - Linguagem de

Modelagem Unificada