CMP231 – Sistemas Embarcados Ronaldo Ferreira rrferreira@inf.ufrgs.br Laboratório de UML CMP231 – Sistemas Embarcados Ronaldo 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 26/03/2017

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 26/03/2017

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 26/03/2017

UML Especificada em dois documentos Infrastructure Superstructure 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 26/03/2017

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 26/03/2017

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) 26/03/2017

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 26/03/2017

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 26/03/2017

Diagrama de classes Cada propriedade possui uma visibilidade de acesso (VisibilityKind) e um tipo Public (+) Private (-) Protected (#) Package (~) 26/03/2017

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 26/03/2017

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 26/03/2017

aggregationKind = none aggregationKind = shared aggregationKind = composite 26/03/2017

Errado Correto Indefinido B não pode ser dependente de duas classes distintas Correto B foi criado por alguém, não sabemos quem, mas está OK (em partes, depende da semântica de remoção da shared) Indefinido Depende da semântica assumida para a shared. 26/03/2017

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) 26/03/2017

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 26/03/2017

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( ) } 26/03/2017

Um pouco de código (c’est la vie) 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 ; A especificação da UML não define essas regras de tradução. É completamente dependente da ferramenta CASE utilizada. class Item { } class Livro extends Item {} class DVD extends Item {} class Biblioteca { Collection usuarios; Collection emprestadores; } class Usuario { Collection emprestimo; 26/03/2017

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 26/03/2017

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 26/03/2017

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; } 26/03/2017

Execução concorrente da Função C -> mais de uma instância do ator iniciam o caso de uso O comportamento definido na Função B é inserido na Função C através ponto 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 Include para reuso de casos de uso, sendo análogo a aninhamento de chamadas de subrotinas 26/03/2017

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 26/03/2017

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 26/03/2017

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> Inválidos Válidos Todos os traces possíveis 26/03/2017

Parâmetros formais Construtor Chamada aninhada Life line Destrutor Chamada assíncrona Construtor Chamada síncrona Chamada aninhada Life line Destrutor 26/03/2017

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 26/03/2017

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 26/03/2017

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 26/03/2017