INF5120 ”Modellbasert Systemutvikling” ”Modelbased System development”

1. INF5120”Modellbasert Systemutvikling””Modelbased System development” Lecture 6: 20.02.2012 Arne-Jørgen Berre arneb@ifi.uio.no or Arne.J.Berre@sintef.no

2. INF5120 - Lecture plan - 2012 • Part I: SSI – Service Innovation and Agile Service/Software Engineering • Part II: SSMDE – Model Driven Engineering • Part III – Model Driven Interoperability and ADM • 1: 16/1: Introduction to Model Based System Development (INF5120) • 2: 23/1: SIE I: Enterprise Architecture, Role modeling-Collaboration and Value Networks – Verna Allee (VNA) • 3: 30/1: SIE II:: Business Process Modeling with BPMN 2.0 and Business Model Innovation - Peter Lindgren (BMI) • 4: 6/2: SIE III: AT ONE –User-oriented design – with Use cases and user stories • 5: 13/2: SIE IV: Service modeling with SoaML – Service modeling - Design, patterns • 6: 20/2: SIE V: Precise Modeing in UML with OCL and Design with DCI - Design, patterns • 7: 27/2: MDE I: Software Process Model Frameworks – Essence/SEMAT, SPEM, EPF and ISO 24744 –Shihong Huang/Brian Elvesæter/Arne J. Berre • 8: 5/3: MDE II: Metamodels, Domain specific languages and UML profiles (Franck Fleurey, Brian Elvesæter) • 9: 12/3: MDE III: Metamodeling, MDLE and DSL Tools (EMF, GMF, ATL, Kermeta) (Franck Fleurey) • 10: 19/3: MDE IV: Model transformations - MOFScript, QVT DSLs with examples (Franck Fleurey) • 11: 26/3: MDE V: Internet Service Architectures - and Method Engineering (Arne J. Berre) • 2/4, 9/4: EASTER • 12: 16/4: MDE VI: User Interface Modeling – IFML etc. - ESITO • 13: 23/4: MDI I: Semantic technologies, Ontologies and Semantic annotations , Rules/SBVR • 14: 30/4: MDI II: Model Driven Service Interoperability • 15: 7/5: MDI III: ADM and Migration to Cloud computing • 16: 13/5: Conclusion and Summary for INF5120 - Preparation of Exam • Exam: Monday June 4th, 2011, 1430-1830 (4 hours)

3. INF5120 – Oblig/Exercise plan - 2012 • 1: 16/1: None • 2: 23/1: Guest lecture: Value Networks – Verna Allee (VNA) • 3: 30/1: Guest lecture: Business Model Innovation - Peter Lindgren (BMI) – Establish groups • 4: 6/2: AT ONE initial exercise – overall approach for Oblig 1 – “myServiceFellow” • 5: 13/2: Group presentation • 6: 20/2: Group presentation • 7: 27/2: Group presentation • 8: 5/3: MDE Tools – introduction – Oblig 2 intro • 9: 12/3: MDE Tools II - EMF • 10: 21/3: MDE Transformation tools - Delivery of Oblig 1 • 11: 26/3: Walk through of Oblig 1 • 2/4, 9/4: EASTER • 12: 16/4: MDE User Interface tools – ESITO o.a. • 13: 23/4: Oblig 2 questions • 14: 30/4: Oblig 2 delivery • 15: 7/5: Oblig 2 summary • 16: 13/5: Conclusion and Summary for INF5120 - Preparation of Exam • Exam: Monday June 4th, 2011, 1430-1830 (4 hours)

4. Outline • SoaML – part 2 – composite structures • Modelio – and support for UML 2, SoaML and BPMN • Precise Modeling and use of UML OCL • Roles and DCI • Scala – and support for roles and DCI through Traits • Software Process Engineering Metamodels (next lecture) • Oblig 1 – presentations and delivery

5. Individual exercise – until February 13th • Download myServiceFellow on a SmartPhone, iPhone or Android (from the respective AppStore). • Identifiy and evaluate touchpoints related to service interaction points you know about in the context of University of Oslo and Institute for Informatics • Think both about touchpoints that can be incrementally improved and radically improved (i.e. new apps/applications etc.) • Document your touchpoint evaluations using the app myServiceFellow

6. Service Design – ”My University” • Actors - Value Networks, Role models – VNA, Verna Allee • Service/Customer Journey – BPMN, Role play, • Touchpoints - UI sketches – Experiences – UI sketches • Opportunities and Needs • Identified services – SoaML – collaboration diagrams • Specificed services – SoaML - composite diagrams • 13/2: Touchpoint identification, customer journey (All) • 20/2: Actors and Role models, Value Networks, Role play • 27/2: BPMN diagrams, initial SoaML diagrams • 19/3-26/3: Final group delivery Oblig 1

7. Requirements for the Oblig 1 delivery Methodology: inf5120.modelbased.net • A group delivery – one document per group - containing your models for your selected area of interest. • Actors – Role models, CRC cards, – Interactive Role play, Value Network analysis • Customer/User/Service journey, BPMN, User stories/use cases • Touchpoints – Service descriptions/specifications, SoaML and UML for information exchange • Opportunities/Needs – match/mismatch ? • Experiences – Service experiences, User Interface sketches • Voluntary: Any comments on Business Model Innovation

8. Use of tools in Oblig 1 • Value Networks – VNA www.valuenetworks.com • Ideas – Sticky/coloured notes in Symphonical – AT ONE workshop results • Service journeys – BPMN in Modelio • Service Models – SoaML in Modelio • Service Information models – SoaML/UML in Modelio

9. Next Lecture – February 27th, 2012 • Software Process Engineering metamodels • SPEM • ISO 24744 • SEMAT • Oblig 1 – Group presentations, BPMN and SoaML

10. Service ports and service participants • A Service port: • is the offer of a service by one participant to others using well defined terms, conditions and interfaces • defines the connection point through which a Participant offers its capabilities and provides a service to clients. • It is defined using a UML Port on a Participant, and stereotyped as a <<Service>> • A Service port is a mechanism by which a provider Participant makes available services that meet the needs of consumer requests as defined by ServiceInterfaces, Interfaces and ServiceContracts.

11. ServiceInterfaces and Participants Metamodel 11

12. ServiceInterfaces and Participants Profile 12

13. UML Composite Diagrams • Composite DiagramsA composite structure diagram is a diagram that shows the internal structure of a classifier, including its interaction points to other parts of the system. It shows the configuration and relationship of parts, that together, perform the behavior of the containing classifier.classes can be displayed as composite elements exposing interfaces and containing ports and parts. Start - Explanation of standard UML 2.3

14. Part • A part is an element that represents a set of one or more instances which are owned by a containing classifier instance. So for example, if a diagram instance owned a set of graphical elements, then the graphical elements could be represented as parts; if it were useful to do so, to model some kind of relationship between them. Note that a part can be removed from its parent before the parent is deleted, so that the part isn't deleted at the same time.A part is shown as an unadorned rectangle contained within the body of a class or component element.

15. Ports A port is attached to an active class. The port has: A name. An interface specifying the signals that can be received. An interface specifying the signals that can be sent. Two types of ports: Connected to internal communication channels (by default). Connected to the state machine for the class instance (a behaviour port). In interface Out interface A behaviour port

16. Composite Structure • A composite structure diagram shows the relationship among internal components of a class, in terms of communication paths. • The class may have one or more communications ports through which signals can be sent or received. • The ports are connected either to: • Internal components • Channels connect the ports of the class to the ports of the internal components. • Channels can be unidirectional (one direction only) or bidirectional (both directions). • The state machine behaviour of the class (a behaviour port).

17. Object instance references instance name class name

18. Composite Structure

19. Composite class (incomplete) part • with parts, ports and connectors port connector

20. BankContext User-Reader ATM-bank :User :Bank :ATM User-Screen User-Keyboard User-Cash Context Model in UML2.0 - I • composite structure as part of a Collaboration

21. User-Reader :User [1..10000] :ATM [1..100] ATM-bank :Bank User-Screen User-Keyboard User-Cash Context Model in UML2.0 - II • Including multiplicities on parts multiplicity BankContext End - Explanation of standard UML 2.3

22. A ServiceInterface: can type a service port. can specify a bi-directional service (both the provider and consumer have responsibilities to send and receive messages and events). A ServiceInterface is defined from the perspective of the service provider using three primary sections: provided and required Interfaces ServiceInterface class protocol Behavior. Service interface

23. Participant with service and request ports • A Service Port is typed by a ServiceInterface • A Request port is typed by a conjugate ServiceInterface (defines the use of a service rather than its provision). This will allow us to connect service providers and consumers in a Participant. • Can be transformed to the appropriate interface/implementation code.

24. Interfaces for Participants Each role in the service that receives interactions has an interface, this is the interface for a logical technology component and is implemented by components providing or using this service. This service is bi-directional - messages flow in both directions. Interfaces will correspond with parts of WSDL in a web services mapping of SoaML

25. Components implement the service interfaces providing the link to systems. Participants and services may be used in multiple architectures. Logical System Components “Ports” on the participating components provide and require the service interfaces for each service provided or used

26. Composite Application Components Enterprise systems can be integrated with adapter components This component is defined as a composition of other components. Or, new implementation can be defined inside of components. Components can be assembled from other components by linking their services. This corresponds to the architecture for Acme.

27. ThiNgami nos knnn doZzzkf() karPhew(zAA) Editor text font changeFont(font) addElem(elem) spellCheck() NuclearReactorCore add(ControlRod, int) ControlRod remove(int) Model examples

28. Precise modeling – Details in models • Avoid misunderstanding • Completeness • Baseline for code generation • Model analysis • Consistence among models • Relationships and mappings between models • Analysis of models

29. flights 1 0..* 0..* 0..* 1 1 Simplify with OCL Flight Airplane PassengerFlight CargoFlight PasssengerPlane CargoPlane

30. Flight 0..* 1 Airplane flights type = enum{cargo, passenger} type = enum{cargo, passenger} Diagram with invariants context Flight inv: type = #cargo implies airplane.type = #cargo inv: type = #passenger implies airplane.type = #passenger

31. Definition of constraint • “A constraint is a restriction on one or more values of (part of) an object-oriented model or system.”

32. Object Constraint Language - OCL • OCL er del av UML • Tekstlig språk for å beskrive beskrankninger • Predikatlogikk gjort folkelig (ingen ) • Constraints • begrensninger på modellene • multiplisitet, etc er begrensinger! • ønsker ytterligere begrensninger • Brukes i definisjonen av UMLs metamodell • må jo være presis! • Formelt • entydig • ingen side-effekter

33. Example model Flight departing Flights origin Airport departTime: Time /arrivalTime: Time duration : Interval maxNrPassengers: Integer * flights name: String * airline * arriving Flights desti- nation Airline passengers * {ordered} name: String Passenger $minAge: Integer age: Integer needsAssistance: Boolean airline 0..1 0..1 CEO book(f : Flight)

34. Constraint context and self • Every OCL expression is bound to a specific context. • The context may be denoted within the expression using the keyword ‘self’. Who? Me?

35. Notation • Constraints may be denoted within the UML model or in a separate document. • the expression: context Flight inv: self.duration < 4 • is identical to: context Flight inv: duration < 4 • is identical to: Flight <<invariant>> duration < 4 duration: Integer

36. Elements of an OCL expression • In an OCL expression these elements may be used: • basic types: String, Boolean, Integer, Real. • classifiers from the UML model and their features • attributes, and class attributes • query operations, and class query operations • associations from the UML model

37. OCL types OclAny OclType OclState Real String Boolean OclExpression Integer Collection Set Bag Sequence

38. Example: OCL basic types context Airline inv: name.toLower = ‘klm’ context Passenger inv: age >= ((9.6 - 3.5)* 3.1).abs implies mature = true

39. Model classes and attributes • “Normal” attributes context Flight inv: self.maxNrPassengers <= 1000 • Class attributes context Passenger inv: age >= Passenger.minAge

40. Example: query operations context Flight inv: self.departTime.difference(self.arrivalTime) .equals(self.duration) Interval Time $midnight: Time month : String day : Integer year : Integer hour : Integer minute : Integer nrOfDays : Integer nrOfHours : Integer nrOfMinutes : Integer equals(i:Interval):Boolean $Interval(d, h, m : Integer) : Interval difference(t:Time):Interval before(t: Time): Boolean plus(d : Interval) : Time

41. Example: navigations • Navigations context Flight inv: origin <> destination inv: origin.name = ‘Amsterdam’ context Flight inv: airline.name = ‘KLM’

42. i: Instructor, c: Course, s: Session The name of the course: c.name The date of the session: s.date The instructor assigned to the session: s.instructor The course of the session: s.course The name of the course of the session: s.course.name The instructors qualified for the session: s.course.qualifiedInstructors Basic “Navigation” expressions Coursename Instructorname * * qualifiedInstructors qualifiedFor 0..1 Sessiondate * * assignedTo Let’s navigate on a model

43. What does a1.r1.r2.r3 yield? Assuming the B’s have a boolean attribute “black”; black=false for b6, b8 - what expression refers from a2 to the set { b1 } c2 c4 c3 c1 C A B a2 a1 Navigation Example 1 0..1 r2 * * a r1 * 1 r3 b1 b2 b3 b4 b5 b6 b7 b8

44. Association classes context Person inv: if employer.name = ‘Klasse Objecten’ then job.type = #trainer else job.type = #programmer endif Job type : {trainer, programmer} 1 Company * Person employee employer name : String

45. Three subtypes to Collection • Set: • arrivingFlights(from the context Airport) • Bag: • arrivingFlights.duration (from the context Airport) • Sequence: • passengers (from the context Flight)

46. Collection operations • OCL has a great number of predefined operations on the collections types. • Syntax: collection->operation

47. The collect operation • Syntax: collection->collect(elem : T | expr) collection->collect(elem | expr) collection->collect(expr) • Shorthand: collection.expr • The collect operation results in the collection of the values resulting evaluating expr for all elements in the collection

48. The select operation • Syntax: collection->select(elem : T | expression) collection->select(elem | expression) collection->select(expression) • The select operation results in the subset of all elements for which expression is true

49. The forAll operation • Syntax: collection->forAll(elem : T | expr) collection->forAll(elem | expr) collection->forAll(expr) • The forAll operation results in true if expr is true for all elements of the collection

50. The exists operation • Syntax: collection->exists(elem : T | expr) collection->exists(elem | expr) collection->exists(expr) • The exists operation results in true if there is at least one element in the collection for which the expression expr is true.