CMP231 – Sistemas Embarcados Ronaldo Ferreira

Apresentação em tema: "CMP231 – Sistemas Embarcados Ronaldo Ferreira"— Transcrição da apresentação:

1 CMP231 – Sistemas Embarcados Ronaldo Ferreira rrferreira@inf.ufrgs.br
Laboratório de UML CMP231 – Sistemas Embarcados Ronaldo Ferreira

2 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

3 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

4 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

5 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

6 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

7 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

8 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

9 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

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

11 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

12 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

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

14 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

15 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

16 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

17 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

18 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

19 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

20 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

21 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

22 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

23 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

24 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

25 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

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

27 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

28 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

29 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