Applying OCL for Model Validation in MagicDraw UML. Principal MagicDraw UML No Magic Europe

Transcription

1 Applying OCL for Model Validation in MagicDraw UML Dr. Darius Šilingas Principal MagicDraw UML No Magic Europe

2 About MagicDraw UML A visual UML modeling editor Domain-specific language (DSL) engine Roundtrip code engineering g for Java, C++, C#, Modeling teamwork control system Model documentation and report generation tool A modeling environment and model repository for Enterprise Architecture and Model-Driven Architecture paradigm Model validation engine using Dresden OCL Toolkit Developed since 1998 second oldest UML tool in the market! Sold in >70 countries, used in different business domains Widely regarded as the most standard-compliant UML tool 2

3 Disclaimer I use term model validation because it is used in MagicDraw user interface and documentation manuals In precise computer science terminology, I will discuss model verification since it is based on precisely defined rules Validate Verify 3

4 Model Validation: Correctness and Completeness Modeling like programming is an error-prone process A user model can be either incorrect (it breaks some rules) orincomplete (it lacks some required information) Rules defined in UML specification are automated in MagicDraw However, a specific modeling method typically implies additional rules Restriction to single generalization for classes Compulsory role names on navigable association ends Each use case must be documented with owned comment MagicDraw provides a way to define validation rules and validate models Validation rules can be specified on OCL 2.0 or Java 4

5 MagicDraw Validation Profile <<profile>> Validation Profile A special validation suite that is always active in the background Provides grouping for related validation rules so that they can be invoked together <<stereotype>> validationsuite [Package] <<stereotype>> validationrule [Constraint] abbreviation : String [0..1] errormessage : String [0..1] severity : SeverityKind [1] = error implementation : String [0..1] <<stereotype>> activevalidationsuite [Package] <<enumeration>> SeverityKind debug info warning error fatal Provides rule specification, against which model must to be checked Defines validation error significance levels 5

6 Validation Rule Properties <<metaclass>> Constraint constrainedelement : Element [0..*] specification : ValueSpecification [1] Defines meta-class, class or stereotype for which rule is applied Defines invariant specification in OCL 2 <<stereotype>> validationrule [Constraint] abbreviation : String [0..1] errormessage : String [0..1] severity : SeverityKind [1] = error implementation : String [0..1] Attributes for displaying and filtering validation errors A special attribute for indicating operation or class in case the rule is specified in Java 6

7 Validation Suite vs. Active Validation Suite Validation rules that are collected in a validation suite either by nesting or element import relationship are invoked by user This is a typical case for model completeness validation Validation suite is re-initialized on every invocation Validation rules that are collected in an active validation suite are invoked automatically when user changes the model This is a typical case for model correctness validation It is implemented in an intelligent way so that they fire only when relevant changes in model are performed For better performance, it is recommended to specify them in Java Active validation suite is initialized at project load time 7

8 Simple Model Validation Demo 8

9 A Case Study for Various Validation Rule Examples 1. An university needs a system MagicTest, which automates test assessments. 2. Teachers specify and maintain questions. 3. Each question must be applicable for 1 or more courses. 4. A question can be closed or open. 5. A closed question defines an ordered set of answer options, where at least one answer option is correct and at least one is incorrect. 6. An open question defines an expected correct answer. 7. Teachers define tests for particular classes that they are running. 8. A test collects a number of questions. 9. A test author also specifies test title, instructions, and allowed time. 10. Students participate in test assessments by providing answers to test questions. 11. MagicTest calculates test assessment evaluations. 12. Data about teachers, students, courses and classes are provided by University Data System (UDS). 9

10 Validation Rules with Constrained Meta-Classes COMPLETENESS Each use case must be documented with an owned comment context UseCase inv UseCaseDocumentation ownedcomment->size()>0 CORRECTNESS Each action cannot have more than one incoming control flow context Action inv SingleIncomingControlFlow incoming->size()<2 10

11 Missing Use Case Documentation Student Take Test Assessment <<include>> <<documentation>> Takes student through a test, prepared by teacher, collects student's answers and calculates test assessment grade. Review Test Assessment Evaluation In MagicDraw UML the first owned comment is treated as official model element documentation. 11

12 Select Assigned Test Assessment Multiple Incoming Control Flows Display Test Instructions Start Test Assessment Register Test Assessment Start Display Question Provide Answer at (timeout) I will demonstrate later how to implement an auto-resolution for this validation rule violations. However, this must be done in Java as OCL is effect-free free language and we need to fix the model Register Answer [more questions available] End Test Assessment [no more questions available] Review Test Assessment Evaluation

13 Validation Rules with Constrained Stereotypes We will be using robustness analysis method, which requires a profile with stereotypes «boundary», «control», «entity» CORRECTNESS Boundary components can use only boundary and control components Control components can use only control and entity components Entity components can use only entity components context entity inv UseOnlyEntities clientdependency->forall(cd cd.supplier->forall(s s.ocliskindof(entity))) 13

14 Incorrect Dependency from Entity to Control <<boundary>> TestAssessmentDialog <<control>> TestService <<entity>> TestAssessment <<boundary>> TestSetupDialog <<boundary>> QuestionBrowser <<control>> DataService <<entity>> Test <<entity>> Question MagicDraw provides DSL engine, which enables modelers to enforce such stereotype-specific rules without OCL 14

15 Validation Rules with Constraints on Classes COMPLETENESS CORRECTNESS A closed question defines an ordered set of answer options, where at least one answer option is correct and at least one is incorrect 15

16 Data Structure Design <<enumeration>> TestStatus status Test author : Teacher [1] test DRAFT 1 1 assignedto : Class [1] 1 PREPARED title : String ACTIVE instructions : String... EXPIRED 0..* TestAssessment author : Student [1] grade : Integer... 1 status 1 <<enumeration>> TestAssessmentStatus ASSIGNED IN_PROGRESS PAUSED COMPLETED 0..* 1 questions 1..* {ordered} answers 0..* {ordered} Question Answer question subjects : Course [1..*] registered : date author : Teacher [1] 1 0..* description : String OpenQuestion expectedanswer : String ClosedQuestion {options->collect(correct)->includes(true) o ect) c ue) and options->collect(correct)->includes(false)} SelectionAnswer input : String InputAnswer 1 options 2..* AnswerOption statement : String correct : Boolean selectedoptions 1..* 1 16

17 Data Sample: Instance Specifications supervisor = Darius Darius : Teacher Applying UML 2 with MagicDraw : Course MagicDraw UML@D Dresden : Class course = Applying UML 2 with MagicDraw instructor = Darius location = "Technical University Dresden" participants = Matthias UML Basics : Test author = Darius questions = Metaclasses, Diagrams status = ACTIVE Metaclasses : OpenQuestion Diagrams : ClosedQuestion description = "UML2 defines... metaclasses" description = "UML2 defines... diagrams" expectedanswer = "249" options = 7, 11 7 : AnswerOption 11 : AnswerOption correct = false correct = false Matthias : Student 249 : InputAnswer question = Metaclasses 11 : SelectionAnswer question = Diagrams answers = 249, 11 grade = 1 status = COMPLETED test = UML Basics UML Basics by Matthias : TestAssessment 17

18 Ideas for Future OCL-Driven Features in MagicDraw Update to the most recent version of Dresden OCL toolkit Needs a bridge from MOF-based to EMF-based model Integrate intelligent OCL editor into constraint specification Easier specification and debugging of OCL 2.0 expressions Support implicit model element relationship analysis Specify criteria in OCL for dependency matrix and related elements finder Generate code for operation bodies from OCL expressions Applicable for query operations, test cases 18

19 Thank You for Attention! Questions??? Let s Keep in Touch: Dr. Darius Šilingas darius.silingas@nomagic.com Skype: darius.silingas Phone: