A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Laboratório de UML CMP231 – Sistemas Embarcados Ronaldo Ferreira

Apresentações semelhantes


Apresentação em tema: "Laboratório de UML CMP231 – Sistemas Embarcados Ronaldo Ferreira"— Transcrição da apresentação:

1 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 27/3/20142

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 27/3/20143

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 27/3/20144

5 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 27/3/20145

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 27/3/20146

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) 27/3/20147

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 27/3/20148

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 27/3/20149

10 Diagrama de classes Cada propriedade possui uma visibilidade de acesso (Visibility Kind ) e um tipo – Public (+) – Private (-) – Protected (#) – Package (~) 27/3/201410

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 27/3/201411

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 27/3/201412

13 aggregationKind = none aggregationKind = shared aggregationKind = composite 27/3/201413

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

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) 27/3/201415

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 27/3/201416

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( ) } } 27/3/201417

18 Um pouco de código (cest 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 dependente da ferramenta CASE utilizada. 27/3/201418

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 27/3/201419

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 27/3/201420

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; } 27/3/201421

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 27/3/201422

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 27/3/201423

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 27/3/201424

25 Interação Definida através de dois conjuntos de traces: traces válidos e traces inválidos Trace é um ordenamento de OccurrenceSpecification 27/3/ InválidosVálidos Todos os traces possíveis

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

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 27/3/201427

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 27/3/201428

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 27/3/201429


Carregar ppt "Laboratório de UML CMP231 – Sistemas Embarcados Ronaldo Ferreira"

Apresentações semelhantes


Anúncios Google