Laboratório de UML

CMP231 – Sistemas EmbarcadosRonaldo Ferreira

rrferreira@inf.ufrgs.br

Agenda• Modelo e modelagem• UML• Diagrama de classes

– Structured e Behaviored classifiers• Classes e Interfaces

– Behavior e BehavioralFeature, OpaqueAction– Associações: composição e agregação, links

• Multiplicidades e subsetting• Diagrama de casos de uso• Interação e Diagrama de sequências

– Operadores de fluxo– Mensagens síncronas e assíncronas– Execution e Occurrence specifications

11/04/23 2

Modelo e modelagem

• O que é um modelo correto?– há um modelo correto?

• Um modelo é, na verdade, adequado ou não para o propósito e expectativas nele depositadas– Profundidade: o modelo implementa o nível de

detalhes adequado de suas funcionalidades– Largura: o modelo implementa todas as

funcionalidades necessárias• Quem garante? Processo interno ou agência

externa

11/04/23 3

Modelo e modelagem

• Qual o objetivo de se modelar?

• Refinamento da especificação• V&V• Simulação e geração de código• Time-to-market e abstração mais adequada• Redução de custos• Regra da disciplina CMP231

11/04/23 4

UML

• Especificada em dois documentos– Infrastructure• Não necessariamente UML, descreve o mínimo

necessário para descrever uma linguagem• Especifica o mecanismo de extensão de linguagens e

pontos de interação com o padrão MOF

– Superstructure• Descreve as construções e semântica da UML• Utiliza o Infrastructure

11/04/23 5

Agenda• Modelo e modelagem• UML• Diagrama de classes

– Structured e Behaviored classifiers• Classes e Interfaces

– Behavior e BehavioralFeature, OpaqueAction– Associações: composição e agregação, links

• Multiplicidades e subsetting• Diagrama de casos de uso• Interação e Diagrama de sequências

– Operadores de fluxo– Mensagens síncronas e assíncronas– Execution e Occurrence specifications

11/04/23 6

Diagrama de classes

• Descrição estrutural do modelo• Descreve o domínio e suas relações e

restrições

• Conceito central: Classifier– Define um conceito do domínio possuidor de um

nome (portanto, um NamedClassifier)

11/04/23 7

Diagrama de classes

• Classe– É um NamedClassifier, que possui propriedades

(atributos) (StructuralFeature), sendo, portanto, um StructuredClassifier

– É também um NamedClassifier possuidor de comportamento (BehavioralFeature), sendo, portanto, um BehavioredClassifier

– É um TypedElement e, portanto, a definição de

uma classe define um tipo no domínio

11/04/23 8

Diagrama de classes

• Interface– É um NamedClassifier, que possui propriedades

(atributos) (StructuralFeature), sendo, portanto, um StructuredClassifier

– É um TypedElement e, portanto, a definição de

uma classe define um tipo no domínio– É equivalente a uma classe abstrata sem

implementação de comportamento e propriedades

11/04/23 9

Diagrama de classes

• Cada propriedade possui uma visibilidade de

acesso (VisibilityKind) e um tipo

– Public (+)– Private (-)– Protected (#)– Package (~)

11/04/23 10

Diagrama de classes

• Associação define comunicação entre objetos (instâncias de classes) em tempo de execução

• A associação é também uma classe, sua instância chama-se link

• Possui três tipos (AggregationKind)– None– Shared– Composite

11/04/23 11

Shared vs. composite• Ambas definem relação todo parte

(leia-se B é parte de A ou A é o todo de B)

• Composite: As instâncias de B são criadas “dentro” de A, e são removidas quando A deixa de existir

• Shared: B é parte de A, mas pode ser parte de outra classe também. Como lidar com isso é um semantic variation point

11/04/23 12

aggregationKind = none

aggregationKind = shared

aggregationKind = composite

11/04/23 13

Errado

Correto

Indefinido

B não pode ser dependente de duas classes distintas

B foi criado por alguém, nãosabemos quem, mas está OK(em partes, depende da semânticade remoção da shared)

Depende da semântica assumidapara a shared.

11/04/23 14

Propriedades da associação• Uma associação define uma coleção de elementos. Há

propriedades para especificar essa coleção.– Subsets: os elementos de uma relação A estão na relação

B, e |A| <= |B|– Redefines: os elementos da relação A especializam os

elementos da relação B– Union: uma relação A é definida como a união dos

elementos de outras relações– Ordered: os elementos da relação são ordenados– Nonunique: pode haver elementos repetidos na relação– Sequence: coleção de elementos não ordenados com

possibilidade de repetição de elementos (estrutura bag)

11/04/23 15

Multiplicidades incoerentes. UML assume a mais restrita como correta

Conceito padrão de herança. Chama-se Generalização em UML.Introduz hierarquia de tipos

11/04/23 16

Propriedade vs. associação

class A { b : Classe B main() { b.foo( ) ; }}

class B{ foo( )}

class A {}

class B{ foo( )}

link :: a_b { a : Classe A b : Classe B

main() { b.foo( ) }}

11/04/23 17

Um pouco de código (c’est la vie)

class Item { }class Livro extends Item {}class DVD extends Item {}class Biblioteca { Collection usuarios; Collection emprestadores;}class Usuario { Collection emprestimo;}

class Usuario { Collection emprestimo; boolean remove ( Item : it ) { emprestimo.contains ( it ) ? ( if emprestimo.size – 1 < 1 return false ; else emprestimo.remove ( it ) return true ; ) : return false ; } }class Biblioteca { Collection usuarios; Collection emprestadores; boolean addEmprestadores ( Usuario : usr ) { usuarios.contains ( usr ) ? ( emprestadores.add ( usr ) return true ; ) : return false ; } }

A especificação da UML não define essas regras de tradução.

É completamente dependenteda ferramenta CASE utilizada.

11/04/23 18

Agenda• Modelo e modelagem• UML• Diagrama de classes

– Structured e Behaviored classifiers• Classes e Interfaces

– Behavior e BehavioralFeature, OpaqueAction– Associações: composição e agregação, links

• Multiplicidades e subsetting• Diagrama de casos de uso• Interação e Diagrama de sequências

– Operadores de fluxo– Mensagens síncronas e assíncronas– Execution e Occurrence specifications

11/04/23 19

Diagrama de casos de uso

• Diagrama comportamental, descreve a interação entre atores externos e o sistema sendo modelado

• O caso de uso é uma descrição em alto-nível de um comportamento emergente

11/04/23 20

Diagrama de casos de uso

• Um caso de uso é um EmergentBehavior– Composição de diversos comportamentos

baseado na troca de mensagens entre instâncias– Cada comportamento que compõe o emergente

pode tanto ser um EmergentBehavior (troca de mensagens) quanto um AtomicBehavior (depende somente da instância em questão)

void comprarProduto ( ) { checarDisponibilidade ( ) calcularPreco ( ) baixarEstoque ( ) entregarProduto ( )}

int getPosicaoAtual ( ) { return this.x – this.y;}

11/04/23 21

Execução concorrente da Função C -> mais de uma instância do ator iniciamo caso de uso

O comportamento definido na Função B é inserido na Função C atravésponto de extensão Execução degradada. Como realiza-se essa inserção éum semantic variation point

A Função A possui o comportamento das Funções B e D. Utiliza-se o Includepara reuso de casos de uso, sendo análogo a aninhamento de chamadas de subrotinas

11/04/23 22

Agenda• Modelo e modelagem• UML• Diagrama de classes

– Structured e Behaviored classifiers• Classes e Interfaces

– Behavior e BehavioralFeature, OpaqueAction– Associações: composição e agregação, links

• Multiplicidades e subsetting• Diagrama de casos de uso• Interações e Diagrama de sequências

– Operadores de fluxo– Mensagens síncronas e assíncronas– Execution e Occurrence specifications

11/04/23 23

Interação

• Uma interação é a descrição de um traço de execução entre instâncias

• Não especifica o comportamento completamente• Unidade de comportamento descrevendo a troca

de mensagens entre objetos

• Conceito central: Mensagem– O foco é o sequenciamento das mensagens, não o

fluxo de dados

11/04/23 24

Interação

• Definida através de dois conjuntos de traces: traces válidos e traces inválidos

• Trace é um ordenamento de OccurrenceSpecification <e1, e2, e3, ..., eN>

11/04/23 25

InválidosVálidos

Todos os traces possíveis

11/04/23 26

Parâmetros formais

Life lineChamada aninhada

Construtor

Destrutor

Chamada assíncrona

Chamada síncrona

Como começar o meu modelo UML?

• Descrever casos de uso– Entrada: requisitos e funcionalidades do sistema– Saída: Diagrama de casos de uso, requisitos

refinados– Durante o projeto dos casos de uso, refinam-se os

requisitos e funcionalidades até termos profundidade e largura adequadas

11/04/23 27

Como começar o meu modelo UML?

• Fase de análise – modelo conceitual– A partir dos requisitos e casos de uso, extraem-se

os conceitos do domínio– Cria-se um diagrama de classes estruturando e

hierarquizando esses conceitos– Sem métodos, somente estrutura– O projeto do modelo conceitual pode ajudar a

refinar os casos de uso

11/04/23 28

Como começar o meu modelo UML?

• Fase de projeto – diagrama de classes– Definem-se atributos e métodos– Colocam-se detalhes de implementação do

sistema, independente de linguagem– Novamente, aqui é possível ganhar mais

conhecimento e refinar o modelo conceitual e os casos de uso

– Criam-se os diagramas de sequências

11/04/23 29