Modelagem de Processos. Prof.: Fernando Ascani

Transcrição

1 Modelagem de Processos Prof.: Fernando Ascani

2 Regras e mecanismos da UML REGRAS Especificam o que deverá ser um modelo bem-formado. Um modelo bem formado é aquele que é semanticamente consistente e em harmonia com todos os outros modelos a ele relacionados.

3 Regras A UML tem regras semânticas para: Nomes Nomes de coisas, relacionamentos e diagramas Escopo O contexto que dá significado específico a um nome Visibilidade Como esses nomes podem ser vistos e usados por outros Integridade Como as coisas relacionam entre si de maneira própria e consistente Execução O que significa rodar ou simular um modelo.

4 Regras e mecanismos da UML Mecanismos Construções são mais harmônicas se são construídas de acordo com características comuns (pertencente a muitos) padrões. - Por exemplo, existem estilos: vitoriano, barroco, etc A UML utiliza 4 mecanismos comuns: Especificações Adorno Divisão comum Mecanismos de extensão

5 Mecanismos Especificações A UML não é só uma linguagem gráfica por trás de toda parte gráfica há uma especificação que define a sintaxe e semântica de um elemento. Por exemplo, uma classe pode ser mostrada na forma de ícone ou na forma convencional com um ou mais compartimentos mas a especificação a ela associada é sempre a mesma. A UML permite uma notação gráfica ou de especificação.

6 Mecanismos Especificações Na notação de especificação são definidos os detalhes de um elemento. A especificação pode ser construída incrementalmente e estará sempre por trás, valendo para qualquer tipo de exibição utilizado. As especificações UML provêm um pano de fundo que envolve todas as partes de um modelo. Um diagrama pode ser considerado uma projeção visual do sistema em um pano de fundo, cada diagrama revelando aspectos interessantes do sistema.

7 Mecanismos Adornos São itens gráficos ou visuais adicionados à notação básica de um elemento para permitir a especificação de detalhes. A UML oferece notações gráficas que provêm uma representação visual dos aspectos mais importantes de um elemento. Adornos podem ser adicionadas a essas representações para acrescentar detalhes.

8 Mecanismos Adornos Uma Nota é um adorno para um comentário preso a um elemento ou a uma coleção de elementos. Como a UML nunca será capaz de captar 100% das ideias reais do Projeto, usamos as Notas para expressar pequenos detalhes, pequenas observações, visando complementar a informação presente no elemento, no relacionamento entre elementos, etc.

9 Mecanismos Divisão Comum Dicotomia (divisão em dois) de conceitos utilizados na UML. Pode dividir classes e objetos e/ou especificação/implementação, por exemplo. Quase todos os elementos de modelagem apresentam essa dicotomia.

10 Mecanismos de Extensão Mecanismos que pretendem estender a linguagem de uma maneira controlada. Estereótipos Definição de etiquetas (Valores Rotulados / Tagged Values / Tag Definition) Restrições (Constrains)

11 Mecanismos de Extensão Estereótipos Permite estender o vocabulário da linguagem, criando novos elementos de modelagem. O estereótipo estende a semântica mas não a estrutura do elemento. Pode-se criar novos ícones para representar esses elementos em um forma gráfica individualizada

12 Mecanismos de Extensão Definição de Etiqueta A definição de etiqueta é uma propriedade declarada em um estereótipo. Essa propriedade é utilizada em tempo de modelagem. O valor etiquetado é associado ao elemento de modelagem, não a suas instâncias.

13 Mecanismos de Extensão Restrições (Constraints) Uma restrição estende a semântica de um elemento UML, permitindo a definição de novas regras ou modificar regras existentes.

14 Modelagem de regras de negócio Regras de Negócio - Definição Regras de negócios são declarações de políticas ou condições que devem ser cumpridas. As regras de negócios são tipos de requisitos de como os negócios, incluindo suas ferramentas de negócios, devem operar. Elas podem ser leis e regulamentos impostos ao negócio, mas também expressam a arquitetura e o estilo de negócio escolhido.

15 Categorias de Regras de Negócios As regras de negócios podem ser classificadas pelas categorias: Regras de restrição Especificam políticas e condições que restringem o comportamento e estrutura dos objetos Regras de derivação - Especificam políticas ou condições para deduzir ou calcular fatos de outros fatos Regras de dedução - especificam que se determinados fatos são verdadeiros, uma conclusão pode ser deduzida. Regras de Cálculo - Derivam seus resultados pela forma de processar algoritmos, uma variante mais sofisticada de regras de dedução.

16 Regras de Restrição Regras de estímulo e resposta - restringem o comportamento especificando quando e se as condições devem ser verdadeiras para que o comportamento seja disparado. Regras de restrição de operação especificam as condições que devem ser verdadeiras antes e após uma operação para garantir que a operação seja executada corretamente. Regras de restrição de estrutura especificam políticas ou condições sobre classes, objetos e seus relacionamentos que não podem ser violados.

17 OCL As regras de negócios devem ser expressas rigorosa e formalmente para que sejam uma base para automação. Uma alternativa pode ser o uso da Linguagem de Restrição de Objetos (OCL Object Constraint Language) conforme especificado na Linguagem Unificada de Modelagem. OCL é uma linguagem declarativa para descrever as regras que se aplicam ao padrão UML. É uma linguagem proposta para ser utilizada em conjunto com outras ferramentas, tais como os diagramas de classes da UML.

18 OCL Algumas vezes a UML não é suficiente para expressar todas as informações necessárias somente pelas suas notações diagramáticas. A OCL é uma linguagem de expressões para especificar restrições sobre modelos orientados a objetos ou outros artefatos da linguagem UML. É uma linguagem de texto precisa que fornece afirmações em um modelo orientado a objeto que não possam ser expressados pela notação por diagramas. Uma das suas principais características é que seu uso não exige um forte conhecimento matemático para ser utilizada corretamente.

19 OCL A OCL pode ser utilizada para: Para especificar invariantes em classes e tipos do modelos de classes Especificar tipos invariantes para estereótipos Descrever pré e pós condições em operações Como uma linguagem de navegação entre associações Como uma linguagem de consulta Para descrever protetores. Para especificar o alvo das mensagens e ações. Para especificar regras de derivações para atributos. Especificar restrições sobre operações.

20 + p a rtn e rs 1..n 1..n P ro g ra m P a rtn e r n u m b e ro fc u sto m e rs : In te g e r S e rvice co n d itio n : B o o le a n p o in tse a rn e d : In te g e r p o in tsb u rn e d : In te g e r d e scrip tio n : S trin g Lo y a ltyp r o g ra m e n ro ll() 0..n + d e live re d S e rvic e s 0..n 1..n + p ro g ra m 0..n 0..n S e rvice L e ve l n a m e : S trin g + a va ila b le S e rvice s + tra n sa ctio n s Lo ya lt ya ccou n t po in t s : In te g er ea rn () bu rn () isem pty( ) + tra n sa ctio n s 0.. n 0..n 0..n + a ctu a ll e vel M e m b e rsh ip T ra n sa ctio n po in t s : In te g er da te : D a te pro g ra m() c a rd +tra nsa ction s 0..n C u sto m e r n a m e : S trin g title : S trin g ism a le : B o o le a n d a te O fb irth : D a te a g e () + o w n e r +c a rd s 0..n C u sto m e rc a rd va lid : B o o le a n va lid F ro m : D a te g o o d T h ru : D a te co lo r : e n u m {silve r, g o ld } p rin te d N a m e : S trin g + ca rd B u rn in g E a rn in g

21 Invariantes Customer name : String title : String ismale : Boolean dateofbirth : date CustomerCard valid : Boolean validfrom : Date goodthru : Date printedname : string age() <<invariant>> Context Customer inv: self.age() >= 18 <<invariant>> Context Customercard inv: printedname = customer.title.concat( customer.name)