Q 2 1 1 TDT4250 - Modeling of Information Systems, Autumn 2006 - PDF document

TDT4250 - Modeling of Information Systems, Autumn 2006 Model-driven development (MDA), Software Oriented Architecture (SOA) and semantic web (exemplified by WSMO) Draft of presentation John Krogstie Professor, IDI, NTNU Senior Researcher, SINTEF ICT 1 TDT4250 - Modeling of Information Systems, Autumn 2006 Overview of lectures today and Wednesday Overview on SOA and MDA / MDD, based on material � produced in the Athena EU-project More details based on the articles today � Articles A14 White, S. A. Introduction to BPMN � A15. Pasley, J. How BPEL and SOA is changing web services � development, IEEE Internet computing May-June 2005 A16. de Bruijn, J, Fensel, D., Keller, U. and Lara, R. Using the � web-service modelling ontology to enable semantic e- business, Communication of ACM Dec 2005 A17. France, R.B., Gosh, S. Dinh-Trong, T, and Solberg, A. � Model-driven development using UML2.0: Promises and Pitfalls, IEEE Computer February 2006 A18. Jones, V., Rensik, A. and Briksma, E. Modelling mobile � health systems: an application of augmented MDA for the extended healthcare enterprise Q 2 1 1

TDT4250 - Modeling of Information Systems, Autumn 2006 BPMN – based on a presentation by Steven White Q 3 TDT4250 - Modeling of Information Systems, Autumn 2006 Business process management (BPM) services Q 4 2 2

TDT4250 - Modeling of Information Systems, Autumn 2006 Q 5 TDT4250 - Modeling of Information Systems, Autumn 2006 Q 6 3 3

TDT4250 - Modeling of Information Systems, Autumn 2006 Q 25 TDT4250 - Modeling of Information Systems, Autumn 2006 Model-driven development (MDD) Model-driven approach to system engineering CIM CIM where models are used in Business • understanding Context Models • design • construction • deployment • operation • maintenance Model trans- • modification formation Model transformation tools and services are used PIM to align the different models. PIM Software Specification Models Business-driven approach to system engineering where models are refined from business needs to software solutions • Computation independent model (CIM) capturing business context and business Model trans- requirements formation • Platform independent model (PIM) focusing on software services Q PSM PSM independent of IT technology Software • Platform specific model (PSM) focusing on Realisation Models the IT technology realisation of the software services 26 13 13

TDT4250 - Modeling of Information Systems, Autumn 2006 Current MDA Architecture OrgMM CIM Enterprise models modeling BSVR BPDM expert QVT OWL PIM System Ontology UML2.0 models ODM System QVT modeling PSM expert MOF2.0 System models MOF2Txt XMI2.0 System realisation ATL Q installation System QVT MOFScript expert EMF Java API (MOF2Txt) MTF (IBM) 27 TDT4250 - Modeling of Information Systems, Autumn 2006 A17. France, R.B., Gosh, S. Dinh-Trong, T, and Solberg, A. Model-driven development using UML2.0: Promises and Pitfalls, IEEE Computer February 2006 Navigating the metamuddle Arnor Solberg, Robert France, Raghu Reddy Colorado State University and SINTEF Norway 28 14 14

TDT4250 - Modeling of Information Systems, Autumn 2006 Claim � The complexity of the current UML 2 metamodel make the understanding, using, extending and evolving the metamodel difficult � 1000 + pages specification � large and fragmented � Available as a model in Rational Rose � Only for visualization, no manipulation features available (e.g. queries) � Poorly documented This is a risk factor for MDD in general and MDA in particular! Q 29 TDT4250 - Modeling of Information Systems, Autumn 2006 This is a problem since.. MDD require development teams to understand, use and extend � metamodels Configuring and tailoring MDD frameworks need to be done for each domain and � even System Family to be able to succeed with MDD. Defining domain specific modeling concepts (for example by means of profiles), � specification of metamodel mappings (transformations) and model composition will be main tasks Task for Domain and System Family architects. No out of the box tools to buy � from vendors. Tailoring is needed Q 30 15 15

TDT4250 - Modeling of Information Systems, Autumn 2006 Conceptual transformation model <<metamodel>> Transformation (e.g. MOF2.0 QVT) <<metamodel>> Source <<metamodel>> Target (e.g., UML domain/PF (e.g. CORBA UML profile) subset/profile) <<conforms_to>> <<source>> <<target>> <<conforms_to>> <<transformation>> <<conforms_to>> Source2Target Scheme <<Model instance>> <<Model instance>> Source <<conforms_to>> Target <<source>> <<target>> Q Transformation implementation 31 TDT4250 - Modeling of Information Systems, Autumn 2006 Good news and bad news � Good news is � In practice only part of the UML is used � Subset of diagrams � Subset of concepts � -> Should not need to have the full knowledge of the UML metamodel to use “your” part of UML � Bad news � Need to manually navigate the metamuddle to extract the concepts you want to use Q 32 16 16

TDT4250 - Modeling of Information Systems, Autumn 2006 A glimpse into the story Illustrative Example Mapping of Simple UML interactions models (e.g. to UML profile for CORBA) 33 TDT4250 - Modeling of Information Systems, Autumn 2006 Simple metamodel for UML interactions � Want to extract the Lifeline and Message concepts and their relationships. ☺ These are core concepts for modeling interactions so you would expect to find their properties and relationships quite easily in the standard � Examination of the Interactions section in the UML specification, reveals that the information required in this simple view is not available in one place in the metamodel. Q 34 17 17

TDT4250 - Modeling of Information Systems, Autumn 2006 Lifeline fragment (no obvious relation to Message) Q 35 TDT4250 - Modeling of Information Systems, Autumn 2006 Message fragment (no lifeline) Q 36 18 18

TDT4250 - Modeling of Information Systems, Autumn 2006 Problems of UML � Large and complex � Specification fragmented � Leads to accidental complexity As opposed to inherent problem complexity � � This is a risk factor for the MDA vision! � Furthermore how do you evolve the UML model in a consistent manner? How can one be sure that required changes are incorporated � consistently across the metamodel? How can one determine the impact that a change will have on � other metamodel elements? In particular, how can one ensure that the changes do not � result in a metamodel that defines inconsistent or nonsensical language constructs? Q � It will be extremely difficult to evolve the UML 2.0 metamodel to reflect changes in the UML standard using only manual techniques. 37 TDT4250 - Modeling of Information Systems, Autumn 2006 Suggestions � Need user oriented views into the metamuddle � At least a simple view of the metamodel for each diagram type that describes only the concepts and relationships that appears in the diagram � Use aspect oriented techniques e.g. to � Provide views of the set of diagram types that only contain concepts that are visible in the diagrams (abstract concepts such as NamedElement will not appear in such diagrams, but derived properties will) � Define aspects presenting views of abstract concepts reflecting language and UML-specific concerns such as name space management, element typing, connectivity of elements, and execution semantics. � Make it easier to evolve (e.g., change aspects, new aspects) Q 38 19 19