Modelação & Especificação de Sistemas de Software no contexto da Engenharia de Requisitos

1. Modelação & Especificação de Sistemas de Software no contexto da Engenharia de Requisitos João Pascoal Faria Engenharia de Requisitos de Sistemas de Software Versão 4.0 (partes I, II e III), 8/12/2003

2. Objectivo • Saber criar modelos de sistemas de software (representações em pequena escala a um nível elevado de abstracção) que permitam: • exprimir os requisitos dos sistemas de software como propriedades nesses modelos, de forma o mais compreensível, completa, consistente e não ambígua possível (modelo como especificação completa, consistente e não ambígua de sistema a desenvolver) • verificar formalmente (por demonstração) a consistência interna do modelo e a obediência a propriedades (modelo formal) • testar (animar) o modelo para verificar a sua consistência interna e validar os requisitos o mais cedo possível (modelo executável) • verificar mais tarde a conformidade da implementação com o modelo/especificação (i.e., a obediência aos requisitos expressos no modelo) • servir de base para a construção/implementação do sistema (modelo traduzível, construtivo)

3. Índice • Introdução • Modelação visual (semi-formal) em UML • Modelação formal com OCL (Enriquecimento de modelos visuais em UML com especificações formais de invariantes, pré-condições e pós-condições em OCL) • Elaboração de modelos executáveis e traduzíveis em UML executável XTUML (Enriquecimento de modelos visuais em UML com especificações de acções em linguagem de alto nível) • Modelação / especificação formal em VDM++ • Verificação e validação baseada em modelos

4. Porquê modelos formais e executáveis? (1) • Consensual e prática cada vez mais corrente: • modelação visual com diagramas UML durante as fases de captura e especificação de requisitos, desenho de alto nível (arquitectura) e desenho detalhado • geração de algum código (Java, C#, SQL, XSD, etc.) a partir de UML e vice-versa • Passos seguintes: • modelos como especificações completas e rigorosas (sem ambiguidades nem inconsistências) de alto nível • especificar restrições formalmente (com invariantes) • especificar formalmente a semântica das operações (com pré e pós condições) e, possivelmente, casos de utilização • importante para aumentar o rigor (complementando especificações informais) • importante para suportar a verificação formal (do modelo e conformidade da implementação) • uma especificação pretende ser declarativa (diz os objectivos) e não necessariamente executável (não pretende dizer o caminho) • OCL e VDM++ são opções possíveis

5. Porquê modelos formais e executáveis? (2) • Passos seguintes (cont.): • modelos executáveis de alto nível • necessário especificar acções e algoritmos (resposta a eventos, corpo de operações, ...), em linguagem de muito alto nível • importante para validar os requisitos o mais cedo possível • Executable UML e VDM++ são opções possíveis • geração automática de código completo (e não só esqueletos de classes) a partir de modelos de alto nível • Executable UML e VDM++ são opções possíveis • VDM++ mais maduro e parcialmente integrado com UML, mas combinação de OCL e UML executável poderá ganhar

6. O que são métodos formais ? • Método Formal = Linguagem de Especificação Formal + Raciocínio Formal (verificação formal, ...) • As técnicas são suportadas por • Matemática precisa • Ferramentas de análise poderosas • Constituem um mecanismo rigoroso e efectivo para modelação, síntese e análise de sistemas modelação/especificação Especificação / modelo formal síntese Implementação análise

7. Classificação de métodos formais • Baseados em Modelos • Definem o comportamento do sistema através da construção de um modelo de dados (ou estado) usando estruturas matemáticas (conjuntos, sequências, funções finitas, etc.) - VDM, Z • Particularmente apropriados para desenvolvimento de sistemas de informação • Baseados em Propriedades • Modelam tipos de dados implicitamente definindo o comportamento do sistema através de um conjunto de propriedades • Algébricos – definem semântica de operações através de uma colecção de relações de equivalência (axiomas equacionais) - Obj, Larch, ... • Axiomáticos – definem semântica de operações através de predicados da lógica de primeira ordem - Larch, ... • Baseados no Comportamento • Definem sistemas em termos de sequências possíveis de estados em vez de tipos de dados e são normalmente usados para especificar sistemas concorrentes e distribuídos • Exemplos de formalismos: redes de Petri, Calculus of Communicating Systems (CCS), Communicating Sequencial Processes (CSP); lógica temporal; sistemas de transição; álgebras de processos

8. Exemplo em VDM++(baseada em modelos) É necessário escolher uma representação do estado de uma stack! Representação de dados (estado) baseada em construções matemáticas (conjuntos, sequências, funções finitas, etc.)! classStack instance variables elems : seq of int := []; operations Stack: () ==> () -- construtor Stack () == elems := [] post elems = []; Push : int ==> () Push(i) == elems := [i] ^ elems post elems = [i] ^ ~elems; Pop : () ==> () Pop() == elems := tl elems pre elems <> [] post elems = tl ~elems; Top : () ==> int Top() == return (hd elems) pre elems <> [] post RESULT = hd elems and elems = ~elems; end Stack Se fosse caso disso, podiam-se especificar invariantes, i.e., condições a que têm de obedecer os estados válidos. Corpo algorítmico Pré-condição é uma condição (nos argumentos de chamada e estado inicial do objecto) a que tem de obedecer qualquer chamada válida. Pós-condição é uma condição que relaciona o resultado da operação e o estado final do objecto com os argumentos de chamada e o estado inicial do objecto. Pré e pós-condição especificam semântica da operação!

9. Exemplo em OBJ (algébrica) Mais abstracta: especifica semântica de operações por axiomas, sem necessidade de escolher uma representação de dados interna (cf. noção de ADT)! Spec: Stack; Extend Nat by Sorts: Stack; Operations: newstack:  Stack push: Stack  Nat  Stack pop: Stack  Stack top: Stack  Nat Variables: s: Stack; n: Nat Axioms: pop(newstack) = newstack; top(newstack) = zero; pop(push(s,n)) = s; top(push(s,n)) = n; Uma stack é sempre representada por uma expressão de construção, e.g., push(push(push(newstack, 1), 2), 3) Axiomas permitem simplificar/avaliar expressões top(pop(push(push(newstack, 1), 2))) = = top(push(newstack, 1)) = 1

10. Índice • Introdução • Modelação visual (semi-formal) em UML • Modelação formal com OCL (Enriquecimento de modelos visuais em UML com especificações formais de invariantes, pré-condições e pós-condições em OCL) • Elaboração de modelos executáveis e traduzíveis em UML executável XTUML (Enriquecimento de modelos visuais em UML com especificações de acções em linguagem de alto nível) • Modelação / especificação formal em VDM++ • Verificação e validação baseada em modelos

11. Modelação visual em UML • Os modelos visuais são muito importantes para facilitar a visualização e compreensão • Peças principais para captura e especificação de requisitos • Modelo da arquitectura do sistema • Modelo de casos de utilização • Modelo de (objectos de) domínio

12. Modelo da arquitectura do sistema • Só se justifica em sistemas complexos • Decomposição em sub-sistemas, com indicação de dependências entre sub-sistemas, e dependências em relação a sistemas externos • Cada sub-sistema corresponde a uma área funcional (grupo de funcionalidades), cobrindo todas as camadas da implementação (UI, BL, BD) • Os sub-sistemas podem por sua vez ser decompostos da mesma forma • Em UML, representar por diagrama de estrutura estática, com pacotes (packages) e sub-pacotes • Possibilidade de indicar estereótipos «system» e «subsystem» • Em alternativa, representar por diagrama de blocos com ligações/fluxos entre blocos

13. Exemplo: Sistema de Gestão de Cuidados de Saúde sistema Gestão de Cuidados de Saúde Cuidados Primários Cuidados Diferenciados sub-sistema dependência Cuidados Comuns

14. Modelo de casos de utilização • Finalidade: mostrar a utilidade ou usos possíveis do sistema • Conteúdo: actores (tipos de utilizadores e sistemas externos que interagem com o sistema), casos de utilização (funcionalidades do sistema tal como são vistas externamente, ou tipos de interacções entre actores e o sistema) e relações entre ambos • Casos de utilização capturam os requisitos funcionais e alguns requisitos não funcionais • Dificuldade: qual a granularidade dos casos de utilização?

15. Forma do modelo de casos de utilização (1) • Visão geral • Diagrama de casos de utilização acompanhado de descrição textual que passa superficialmente pelos casos de utilização e actores mais importantes

16. Exemplo: Sistema de Gestão de Conferências nome do sistema fronteira do sistema actor caso de utilização diagrama de casos de utilização

17. Forma do modelo de casos de utilização (2) • Visão geral (cont.) • Se existirem muitos casos de utilização, apresentar um primeiro diagrama de pacotes de casos de utilização e depois um diagrama de casos de utilização para cada pacote • Pacotes correspondem normalmente a sub-sistemas no modelo da arquitectura

18. Exemplo: Sistema de Gestão de Hotéis (CRM4SH) (1) diagrama de pacotes de casos de utilização

19. Exemplo: Sistema de Gestão de Hotéis (CRM4SH) (2) diagramas de casos de utilização (com pacotes de 2º nível)

20. Exemplo: Sistema de Gestão de Hotéis (CRM4SH) (3) generalização

21. Forma do modelo de casos de utilização (3) • Visão geral (cont.) • Opcionalmente, modelar através de um ou mais diagramas de actividades o encadeamento de casos de utilização (i.e., modelar workflows ou processos de negócio) • casos de utilização aparecem como actividades no diagrama de actividades • se tiver sido construído anteriormente um modelo de processos de negócio, isto já foi feito

22. Exemplo: Sistema de Gestão de Conferências (1) actor objectos de classes do modelo de domínio (ver adiante) passos são execuções de casos de utilização! fluxo de controlo fluxo de objectos

23. Exemplo: Sistema de Gestão de Conferências (2) barra de sincronização (inicia ou termina execução em paralelo)

24. Exemplo: Sistema de Gestão de Cuidados de Saúde Consulta externa: do pedido até à efectivação Manual SIIMS EPR actor interno Marcar Consulta Observar Doente Registar DadosClínicos Prescrever Terapêutica Prescrição Médico Admitir Doente Carimbar Prescrição Funcionário Administrativo processo de negócio modelado por diagrama de actividades EPR SIIMS Marcar Consulta Registar Dados Clínicos Médico sistema ou sub-sistema Admitir Doente sistema ou sub-sistema Prescrever Terapêutica Func. Admin.

25. Forma do modelo de casos de utilização (4) • Actores • Breve descrição de cada actor • Casos de Utilização • Descrição mais ou menos detalhada de cada caso de utilização - ver a seguir

26. Descrição de cada caso de utilização • Identificação e utilidade • Nome e descrição sumária tornando evidente objectivo/utilidade • Features e restrições (Opcional) • Lista de requisitos internos ao caso de utilização • Pré-condições e pós-condições (Opcional) • Condições sobre inputs, outputs, estado inicial e estado final do sistema (com base em modelo de estado definido no modelo de domínio – ver adiante) • Opcionalmente, formalizar em OCL (a tratar mais tarde) • Interface e sequência de funcionamento • Mostrar sequências normais e excepcionais por diagramas de sequência • Mostrar todas as sequências possíveis por um diagrama de actividades • Opcionalmente, mostrar diagrama de navegação (diagrama de estados com estados da interface) e esboços de interface (um esboço por estado) • Fontes e referências, classes participantes (do modelo de domínio), actores participantes, atributos (prioridade, dificuldade, ...) • Implementação – claramente fora do âmbito desta fase

27. Exemplo: Sistema de Gestão de Hotéis diagrama de sequência, mostrando sequência normal de funcionamento do caso de utilização "Registar entrada de cliente sem reserva" objectos mensagens

28. Exemplo: Sistema de Gestão de Hotéis diagrama de actividades, mostrando todas as sequências possíveis de funcionamento do caso de utilização "Registar entrada de cliente sem reserva"

29. Exemplo: Sistema de Gestão de Conferências Diagrama de navegação do caso de utilização "Atribuir Revisores a Artigos" (diagrama de estados em UML, em que estados são estados de interface): estado da interface evento (acção do utilizador) Atribuir Revisores a Artigo artigo Atribuir Revisores a Artigos terminar título: autores: autor1, autor2, ... resumo: seleccionar artigo nº de revisores PDF artigo revisores atribuídos titulo1 0 nº art. nome excluir 1 titulo 2 excluir terminar seleccionar opção "Atribuir revisores a artigos" revisor 1 3 revisor 2 excluir 1 Terminar revisores disponíveis nº art. nome atribuir Dados de Revisor seleccionar revisor atribuir revisor 3 3 nome: instituição: e-mail: áreas de interesse: artigos que revê: artigo1, ... revisor 4 0 atribuir fechar Terminar Fechar atribuir excluir

30. Modelo de (objectos de) domínio (1) • Objectivos • organizar o vocabulário do domínio do problema (utilizado na descrição dos casos de utilização) • organizar e relacionar termos que estão definidos num glossário ou num dicionário de dados • capturar os requisitos de informação • que informação é mantida no sistema e trocada com o ambiente • especificar as transacções do negócio (por operações) • três tipos de classes • classes que modelam o estado interno persistente e partilhado do sistema, como atributos de entidades (e eventos) do negócio e respectivas ligações – são as classes mais importantes • classes que modelam a estrutura de documentos trocados entre o sistema e o seu ambiente • classes que modelam tipos de dados (usados nos atributos e operações das classes anteriores)

31. Modelo de (objectos de) domínio (2) • Forma • Visão geral • Diagrama de classes • Descrição textual que passa superficialmente pelas classes mais importantes

32. Exemplo: Sistema de Gestão de Hotéis agregação classe com atributos associação classe-associação (para indicar atributos) diagrama de classes nota (versão corrigida para ficar consistente com OCL) generalização

33. Modelo de (objectos de) domínio (3) • Forma (cont.) • Descrição de cada classe • Significado • Descrição de atributos • Definição de restrições • Informalmente • Formalmente, como invariantes em OCL (a ver mais tarde) • Descrição de operações (quando definidas) • Sintaxe • Semântica • Informalmente • Formalmente, com pré-condições e pós-condições em OCL (a ver mais tarde) • (Opcional) Ciclo de vida dos objectos da classe (diagrama de estados) • Estados devem corresponder a condições nos valores de atributos e ligações • Nesta fase, eventos devem corresponder a casos de utilização, podendo ter parâmetros

34. Exemplo: Sistema de Gestão de Hotéis ciclo de vida de uma reserva (diagrama de estados) estado transição evento (corresponde a execução de caso de utilização) estado composto subestado evento temporal

35. Índice • Introdução • Modelação visual (semi-formal) em UML • Modelação formal com OCL (Enriquecimento de modelos visuais em UML com especificações formais de invariantes, pré-condições e pós-condições em OCL) • Elaboração de modelos executáveis e traduzíveis em UML executável XTUML (Enriquecimento de modelos visuais em UML com especificações de acções em linguagem de alto nível) • Modelação / especificação formal em VDM++ • Verificação e validação baseada em modelos

36. O que é OCL? • OCL = Object Constraint Language • Faz parte de UML • Linguagem textual para formalizar invariantes, pré-condições e pós-condições por intermédio de expressões booleanas sem efeitos laterais • Expressões podem invocar métodos que consultam o estado de objectos (query methods), mas não métodos que alteram o estado de objectos ou criam ou eliminam objectos • Baseada em conceitos matemáticos (conjuntos, sequências, lógica matemática, etc.) • Versão corrente: 1.5 • Versão em preparação: 2.0

37. Especificação de invariantes em OCL • Invariantes são restrições a que devem obedecer os estados válidos • Definidos em OCL usando palava-chave inv • Em OCL, invariantes são sempre definidos no contexto de uma classe (ou objecto de classe) • Tipos de invariantes comuns: • restrição ao domínio (ou conjunto de valores possíveis) de um atributo • chaves de uma classe - atributo ou conjunto de atributos de uma classe que não pode tomar o mesmo valor (ou conjunto de valores) em dois objectos diferentes da classe • restrições relacionadas com ciclos nas associações • restrições relacionadas com datas e horas • restrições que definem a fórmula de derivação de elementos derivados (replicados ou calculados) • regras de existência – indicam que certos objectos devem existir quando outros objectos existem

38. Exemplo: Sistema de Gestão de HotéisRestrições a domínios de atributos (1) • R1) Em "Preço Serviço", o número de pessoas tem de ser maior que 0context Preço_Serviço inv: número_de_pessoas > 0 • R2) Em "Estadia", o número de pessoas tem de ser maior que 0context Estadia inv: número_de_pessoas > 0 • R3) Em "Reserva", o número de pessoas tem de ser maior que 0context Reserva inv: número_de_pessoas > 0 • R4) Em "Estadia_Quarto", o número de pessoas tem de ser maior que 0context Estadia_Quarto inv: número_de_pessoas > 0

39. Exemplo: Sistema de Gestão de HotéisRestrições a domínios de atributos (2) • R5) Em "Quarto", a capacidade tem de ser maior que 0context Quarto inv: capacidade > 0 • R6) Em "Preço_Serviço", o preço tem de ser maior que 0context Preço_Serviço inv: preço > 0

40. Elementos de OCL • Formas equivalentes:context Reserva inv: número_de_pessoas > 0context Reserva inv:self.número_de_pessoas > 0context r : Reserva inv:r.número_de_pessoas > 0 • Pode-se dar um nome ao invariante:context Reserva inv NumPesResPos: número_de_pessoas > 0

41. Exemplo: Sistema de Gestão de HotéisChaves simples (1) • R7) Não podem existir dois clientes com o mesmo número, isto é, o número de cliente é chavecontext Cliente inv R7:Cliente.allInstances->isUnique(número_de_cliente) • R7') (Equivalente a anterior, porque só há 1 hotel) Um hotel não pode ter dois clientes com o mesmo númerocontext Hotel inv R7b: clientes->isUnique(número_de_cliente)Nota: Sempre que possível é de evitar usar classe.allInstances, pois é fácil implementar numa base de dados mas é difícil implementar em objectos em memória (em memória prefere-se partir de um objecto raiz).

42. Elementos de OCLColecções • Cliente.allInstances dáo conjunto (Set) de todas as instâncias existentes da classe Cliente • O operador "->" toma o lado esquerdo como colecção e aplica-lhe a operação indicada no lado direito • Colecções em OCL podem ser dos seguintes tipos • Set – conjunto de elementos distintos • Bag – conjunto admitindo elementos repetidos • Sequence – sequência de elementos admitindo repetição • OrderedSet (só versão 2.0) – conjunto ordenado de elementos distintos • Uma colecção OCL contém objectos (instâncias de classes) ou valores de tipos primitivos (Integer, Real, Boolean ou String) • Classes são tipos-referência (reference types) • variáveis contêm referências para objectos; comparação e atribuição de referências • Tipos primitivos, colecções e tuplos (ver adiante) são tipos-valor (value types) • variáveis contêm os próprios valores; comparação e atribuição de valores • equivalem a tipos-referência em que não se podem criar duas instâncias (objectos) com o mesmo conteúdo e o conteúdo de uma instância é imutável

43. Elementos de OCLOperações com colecções (1) • collection->exists(expressãoBooleana) – dá true se a expressão for verdadeira para pelo menos um elemento da colecção •  x  collection : expressãoBooleana(x) • collection->forAll(expressãoBooleana) – dá true se a expressão for verdadeira para todos os elementos da colecção •  x  collection : expressãoBooleana(x) • collection->isUnique(expressão) – dá true não existirem dois elementos da colecção com o mesmo valor da expressão •  x, y  collection : x  y  expressão(x)  expressão(y) • collection->notEmpty() • collection->select(expressãoBooleana) – selecciona os elementos da colecção para os quais a expressão é verdadeira • { x  collection | expressãoBooleana(x) } - (tb. com sequências)

44. Elementos de OCLOperações com colecções (2) • collection->collect(expressão) – produz uma nova colecção formada pelos valores da expressão indicada sobre os elementos da primeira colecção • collection->sum() – soma valores de uma colecção de inteiros ou reais • collection->including(elem) – dá nova colecção incluindo o elemento indicado • collection->excluding(elem) – dá nova colecção excluindo o elemento indicado • collection->iterate(iterador; DeclaraçãoEInicializaçãoAcumulador | proximoValorAcumulador) – dá o valor final do acumulador depois de iterar sobre todos os elementos da colecção • collection->any(expressãoBooleana) – dá um elemento qualquer da colecção que verifica a expressão booleana indicada

45. versão 4.0 Elementos de OCLNavegação através de associações e classes-associações • No contexto de uma instância de Estadia: • quartos – conjunto de instâncias correspondentes da classe Quarto (usa-se o rolename), do tipo Set(Quarto) • estadia_Quarto – conjunto de instâncias correspondentes da classe-associação Estadia_Quarto (usa-se o nome da classe-associação com 1ª letra em minúscula), do tipo Set(Estadia_Quarto) • No contexto de uma instância de Quarto: • estadia – conjunto de instâncias correspondentes da classe Estadia (como não existe rolename, usa-se o nome da classe com 1ª letra em minúscula), do tipo Set(Estadia) • estadia_Quarto – conjunto de instâncias correspondentes da classe-associação Estadia_Quarto (usa-se o nome da classe-associação com 1ª letra em minúscula), do tipo Set(Estadia_Quarto) • No contexto de uma instância de Estadia_Quarto: • quartos – instância correspondente da classe Quarto (usa-se o rolename), do tipo Quarto • estadia – instância correspondente da classe Estadia (como não existe rolename, usa-se o nome da classe com 1ª letra em minúscula), do tipo Estadia quartos Estadia Quarto * * quartos: Set(Quarto)estadia_Quarto: Set(Estadia_Quarto) estadia: Set(Estadia)estadia_Quarto: Set(Estadia_Quarto) Estadia_Quarto quartos: Quartoestadia: Estadia

46. versão 4.0 Elementos de OCLNavegação através de associações qualificadas Hotel • No contexto de uma instância de Hotel: • cliente – conjunto de instâncias correspondentes da classe Cliente, do tipo Set(Pessoa) • cliente[i] – instância da classe Pessoa correspondente a númeroCliente = i • No contexto de uma instância de Pessoa: • hotel – conjunto de instâncias correspondentes da classe Hotel, do tipo Set(Hotel) • Dado um hotel, como obter o seu conjunto de números de clientes (instâncias do qualificador)?? • Dada uma pessoa, como obter o seu conjunto de pares hotel +número de cliente?? cliente númeroCliente Pessoa 1..* 0..1 hotel: Set(Hotel) cliente : Set(Pessoa)cliente[i]: Pessoa

47. versão 4.0 Elementos de OCLNavegação para classe-associação em associação recursiva Empregado • No contexto de uma instância de Empregado: • chefes – conjunto de chefes correspondentes (instâncias de Empregado) • subordinados – conjunto de subordinados correspondentes (instâncias de Empregado) • avaliação[chefes] – conjunto de instâncias correspondentes da classe-associação Avaliação quando se navega do empregado para os seus chefes (permite aceder às avaliações que foram atribuídas ao empregado pelos seus chefes) • avaliação[subordinados] - conjunto de instâncias correspondentes da classe-associação Avaliação quando se navega do empregado para os seus subordinados (permite aceder às avaliações que o empregado atribuiu aos seus subordinados) chefes * Avaliação * subordinados avaliação guarda avaliação atribuída pelo chefe ao subordinado

48. Exemplo: Sistema de Gestão de HotéisChaves simples (2) • R8) (Chave alternativa) Não podem existir dois clientes com o mesmo número de bilhete de identidade ou passaporte (este atributo pode ser visto como uma combinação de tipo de documento + número de documento)context Cliente inv: Cliente.allInstances->isUnique( número_do_bilhete_de_identidade_ou_passaporte) • R9) Não podem existir duas reservas com o mesmo númerocontext Reserva inv: Reserva.allInstances->isUnique(número_da_reserva) • R10) Não podem existir duas estadias com o mesmo número context Estadia inv: Estadia.allInstances->isUnique(número_da_estadia)

49. Exemplo: Sistema de Gestão de HotéisChaves simples (3) • R11) Não podem existir dois quartos com o mesmo númerocontext Quarto inv: Quarto.allInstances->isUnique(número) • R12) Não podem existir dois empregados com o mesmo logincontext Empregado inv: Empregado.allInstances->isUnique(login) • R13) Não podem existir duas facturas com o mesmo número context Factura inv: Factura.allInstances->isUnique(número) • R14) Não podem existir dois serviços com o mesmo nome context Serviço inv: Serviço.allInstances->isUnique(nome)

50. Exemplo: Sistema de Gestão de HotéisChaves compostas • R15) Em "Preço Serviço", não podem existir duas ocorrências para a mesma combinação de serviço, data de início e número de pessoasEm OCL 2.0 (em preparação), existe o conceito de tuplo (conjunto de componentes com nome e valor), pelo que se poderá escrever:context Preço_Serviço inv: Preço_Serviço.allInstances->isUnique(p : Preço_Serviço |Tuple{serviço : Serviço = p.serviço, data_de_início: Date = p.data_de_início, número_de_pessoas : Integer = p.número_de_pessoas} )Ou omitindo os tipos do iterador e dos componentes dos tuplos:context Preço_Serviço inv: Preço_Serviço.allInstances->isUnique(p |Tuple{serviço = p.serviço, data_de_início = p.data_de_início, número_de_pessoas = p.número_de_pessoas} ) variável/iterador (para desambiguar) separador entre iterador e expressão