INF5120 UML2 and SysML, Objecteering SOA support ”Modelbased System development”

1. INF5120 UML2 and SysML, Objecteering SOA support”Modelbased System development” Lecture 3: 02.02.2009 Arne-Jørgen Berre

2. Lecture plan - 2009 • 1: 19/1: Introduction to MBSU, MDA, OO and Service/SOA modeling, Overall EA (AJB) • 2: 26/1: MS I: Business Process Modeling (CIM) - with BPMN and BMM (AJB), Objecteering UML Modeler • 3: 2/2: MS II: UML2 and SysML, Objecteering SOA and Scope, – Collaboration /Component models • 4: 9/2: MS III: SoaML I (PIM) and Requirements modeling , CIM->PIM • 5: 16/2:MDE I: Metamodeling , DSL and UML profiles, MDA technologies (XMI, Eclipse, EMF/GMF) (ARS) • 6: 23/2: MS IV: Method Engineering and SPEM / EPF (BRE) • 7: 2/3: MS V: SoaML II and Service Design (AJB) • 8: 9/3: MDE II: Model transformations with MOScript, (ATL and QVT) – and JEE (GO) • 9 :16/3:: MDE II: Code generation with MOFScript and other technologies (GO) • 10: 23/3: MDE IV: PIM and Web Services teknologi (PSM) for SOA with WSDL/XML/BPEL (PSM) (BRE) • 11: 30/3: MDI I: Model Driven Interoperability I (AJB) • EASTER • 12: 20/4: MDE V: Open ArchitectureWare/Kermeta, Microsoft OSLO etc. (Neil, Franck, Anthe) • 13: 27/4: MDI II: Model Driven Interoperability - II - Ontologies, Semantic web and Semantic Modeling (AJB) • 14: 4/5: Course summary • Exam: May 29th, 2009 (Friday) • AJB – Arne J. Berre • BRE – Brian Elvesæter • GO – Gøran Olsen • ARS – Arnor Solberg

3. Next Lecture – February 9th, 2009 • MS III: (Modeling Services III) • SoaML I - Service oriented architecture Modeling Language – from a modeler’s perspective (PIM) • Requirements modeling • CIM->PIM mappings and transformations

4. OOram – Role modeling • Methodology from UIO/SINTEF from 1996 • Book: Working with Objects, • Prof. Trygve Reenskaug & al

5. Traveler Authorizer Book- keeper Pay- master Role model The role model is the basic abstraction in OOram. It is an object oriented model of an object structure and represents a bounded part of an interesting phenomen A role abstraction: - A general role played by many objects - Part of the responsibility for an object

6. State diagram view Describes the possible states of the role, the signals that are acceptable in each state, the action taken as a result of each signal, and the next state attained after the action is completed.

7. Interface view Defines a set of messages that may be sent from one role to another.

8. Objects play several roles ProjectManager ProjectParticipant Ruth

9. Synthesis of ExpenseReport and AirlineBooking ExpenseReport Traveler Authorizer Bookkeeper Paymaster AirlineBooking Traveler Secretary Bookkeeper Paymaster TravelAgent CompositModel Traveler Authorizer Secretary Bookkeeper Paymaster TravelAgent

10. Use of synthesis • 1. Sep. of concern and composition on one abstraction level • 2. Sep. of concern and composition between abstraction levels • 3. Specialization - generalization

11. UML 2.0 With contributions from Øystein Haugen, SINTEF & Birger Møller-Pedersen, UiO

12. UML 2.0

13. UML standardization within OMG – for Ericsson (Haugen, Møller-Pedersen) Requirementsfrom better tools developers world-wide improved Ericsson UML standardization team issuing requirements in cooperation with alllies contributing in cooperation with tool vendors

14. 2P U2 Partners • Submitters • Alcatel, CA, Ericsson, Fujitsu, HP, IBM, I-Logix, IONA, Kabira, Motorola, Oracle, Rational, SOFTEAM, Telelogic, Unisys • Supporters • Advanced Concepts Center LLC, Ceira Technologies, Commissariat à L'Energie Atomique, Compuware, DaimlerChrysler, Embarcadero Technologies, Enea Data, France Telecom, Fraunhofer FOKUS, Gentleware, Intellicorp, Jaczone, Kennedy Carter, Klasse Objecten, KLOCwork, Lockheed Martin, Mercury Computer, MSC.Software, Northeastern University, Popkin Software, Proforma, Sims Associates, Syntropy Ltd., Sun Microsystems, University of Kaiserslautern, University of Kent, VERIMAG, WebGain, and 88solutions

15. Why UML2.0? • for Ericsson, Motorola, Alcatel, Nokia (telecom, realtime) • SDL/MSC only one vendor • UML/ROOM (as by RoseRT) only one vendor • UML2.0 combining features from these • for others • Scalability, modeling of large, complex systems • Improvement of existing concepts: activities, components, • Completeness: action semantics, formal/precise definition • in general • Experiences with UML1.x required an improvement • Model Based Development requires a good modeling language

16. ! ?? ROOM UML SDL Snapshot from one of the meetings

17. Example - ATM • Domain statement • An Automatic Teller Machine (ATM) is a system with mechanical as well as electronic parts. Its purpose is to provide a bank user with cash provided that the user can authenticate herself and she has adequate funds in her bank account. • She authenticates herself by presenting a card to the ATM cardreader, and a personal identification number (PIN) through the ATM keyboard. • The ATM is connected electronically and possibly through some kind of network to the bank such that the account status may be checked online. • The ATM is refilled with cash notes regularly or when the number of specific notes is below some limit. • The ATM may also provide foreign currency to the customer

18. ATM: Domain Model I From Haugen, Ø., B. Møller-Pedersen, and T. Weigert, Modeling Embedded Systems in UML 2.0, in The Embedded Systems Handbook, Richard Zurawski, Editor. 2005, CRC Press.

19. Domain Model II

20. Use Case Model

21. ATM-Bank User-ATM ATM Bank User CardReader Keyboard Screen CashDispenser Context model with UML1.x class diagrams • with plain composition and no encapsulation • with only provided interfaces on classes

22. 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.

23. 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.

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

25. 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

26. 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

27. No User-Reader :User [1..10000] :ATM [1..100] ATM-bank :Bank User-Screen User-Keyboard User-Cash … as part of Packages? BankContext

28. Sequence Diagrams (Interactions) • Sequence Diagrams are • simple • powerful • readable • used to describe interaction sequences • History • Has been used for a number of years informally • Standardized 1992 in Z.120 (Message Sequence Charts - MSC) • Last major revision of MSC is from 1999 (called MSC-2000) • Formal semantics of MSC-96 is given in Z.120 Annex B • Included in UML from 1999, but in a rather simple variant

29. Purpose • Emphasizes the interaction between objects indicating that the interplay is the most important aspect • Often only a small portion of the total variety of behavior is described improve the individual understanding of an interaction problem • Sequence Diagrams are used to ... • document protocol situations, • illustrate behavior situations, • verify interaction properties relative to a specification, • describe test cases, • document simulation traces.

30. (Simple) Sequence Diagram • Messages have one send event, and one receive event. • The send event must occur before the receive event. • The send event is the result of an Action • Events are strictly ordered along a lifeline from top to bottom The frame (UML 2) The name of the interaction Receive Event Continuation Send Event Message name

31. Combined fragment example combined fragment frame operator operand separator

32. Combined fragments of Interaction • We want to express • choices: alternative, option, break • parallel merge • loops • We may also want to add other operators • negation • critical region • assertion • Other suggested operators that will not come in UML 2.0 • interrupt • disrupt

33. References (Interaction Use / Occurrence) reference Continuation

34. Nested combined fragments reference combined fragment Continuation nested fragment

35. Interaction Overview Diagram reference combined fragment Continuation nested fragment Inline diagram

36. EnterPIN state machine trigger guard effect definition of exit point

37. Statemachine for the ATM use of exit point submachine state

38. Statemachine is a Classifier (that is class-like): Attributes Operations (local actions) Behaviors (e.g. state machines) authN number of tries cid card id sa selected amount <<statemachine>> ATM authN: integer cid: integer sa: Amount sendMoney(a:Amount) Attributes of the ATM

39. State machine Withdrawal use of entry point

40. Simple GetAmount definition of entry point

41. A service similar to Withdrawal: Currency

42. Interactions are generalizable and redefinable actual gate formal gate

43. ATM revisited - generalised

44. Extended state machines

45. Decomposing a Lifeline wrt an Interaction this is the name of the diagram where we find the decomposition we want to look into this lifeline

46. Decomposition notice the correspondance! notice the correspondance!

47. Nested sequence diagrams

48. Composite (design) class

49. Structured Classes are like other Classes • Structured Classes may have • attributes & operations, interfaces, … • Internal structure is inherited, inherited parts may be redefined by extension

50. What about Components? • Components have all the properties of structured classes Note that these are just derived, that is they are also defined for classes