INF5120 Modellbasert Systemutvikling Modelbased System development

Size: px

Start display at page:

Download "INF5120 Modellbasert Systemutvikling Modelbased System development"

Preston Hancock
6 years ago
Views:

1 INF5120 Modellbasert Systemutvikling Modelbased System development Lecture: Arne-Jørgen Berre or 1

2 Content n Service Modeling n SoaML introduction n UML 2.0 Collaboration models n SoaML Service Architecture n UML 2.0 Composite models n SoaML Port/connector models n Patterns n Design Patterns 2

3 Course parts (16 lectures) n January February (1-7) (BAE/WebRatio): n 1-18/1: MDE-1: Introduction to INF5120 n 2-25/1: MDE-2: Modeling structure and behaviour (UML and UML 2.0 and metamodeling) ( B. Hjelle, Biocaching) n 3-1/2: BAE-1: Business Architecture Business Model Canvas - Strategyzer tool. n 4-8/2: SAE-1: WebRatio for Mobile App development (Get an App up and running!) n 5-15/2: BAE-2: Essence, Scrum, User stories and Use cases 2.0, Backlog, with Someone n 6-22/2: BAE-3: BPMN process, VDML and UML Activ.Diagrams, (MD/EA, Smaply and Balsamiq) n 7-29/2: BAE-4: Service Design, AT ONE,Touchpoints, UI, UX, Smaply and Balsamiq (Ragnhild Halvorsrund, SINTEF) n Oblig 1: BA Spec, WebRatio App1 (individual) (end of February, March 7 th ), Agile Scrum n March (8,9) (MDE/IFML/Client-Side): n 8-7/3: MDE-3: Model driven engineering Metamodels, DSL, UML Profiles, EMF, Sirius Editors n 9-14/3: SAE-2: IFML Interaction Flow Modeling Language, WebRatio advanced n April (10, 11,12,13) (BPMN, SAE/UML/Server-side): n 10-4/4: SAE-3: BPMN and WebRatio BPM platform/magicdraw BPMN n 11/4: SAE-4: UML Service Modeling, ServiceML,SoaML, REST, UML 2.0 Composition, MagicDraw n 12-18/4:MDE-4: Guest lecture: DSL and ThingML, Franck Fleurey) and Web Meet with project from Florida Atlantic University, FAU, Boca Raton, FL, USA (from ) n Oblig 2: Sirius DSL Editor for IFML +/- (individual), WebRatio/IFML App2 UI (inc. 2) (April 18 th ) n 13-25/4:SAE-5: MDE transformations, Non Functional requirements OCL and PLanguage n May (14,15,16): (Bringing it together) n 14-2/5: SAE-6: Final WebRatio App demo and discussion day (May 2 nd ) n Oblig 3: SA Spec (More models), WebRatio/IFML App 3 Server (Inc. 3) (May 2 nd ) n 15-9/5: MDE-5: Enterprise Architecture, TOGAF, UPDM, SysML DSLs etc. Big picture n 16-23/5: MDE-6: Conclusions/Summary of the course/preparation for the Exam n 6/6: Exam (4 hours), (June 6 th ) 3

4 MagicDraw Cameo Enterprise Architecture 4

5 5

6 Service Modeling and Service Design n UML 2.0 Components with Ports, SoaML (and SysML) n Service views in UPDM, (DODAF/MODAF/NAF) n SESAR ISRM connected to AIRM n GRA UML connected to NIEM n ISO connected to ISO 19103, and RM/ODP 6

7 SoaML Introduction See SoaML standard document on course web page / Dropbox

8 SoaML history n 2006, September n 2007, June n 2008 & 2009 n 2009, December n 2010, March n 2011, December OMG RFP 3 initial submissions Merge process SoaML 1.0 finished SoaML 1.0 adopted by OMG SoaML 1.0 formal standard by OMG n FTF chairs: Arne J. Berre, SINTEF and Jim Amsden, IBM n 8 8

9 UPMS SoaML Timeline Sx Submission version x Bx Beta version x IBM,... Fujitsu,... SHAPE,... Issued September 29, 2006 LOI Deadline November 28, 2006 Initial Submission Deadline June 4, 2007 Adaptive,... S1(3) S3(1) Revised Submission Deadline May 26, 2008 OMG Technical Meeting June 23-27, 2008 * Ontario Canada S2(2) Revised Submission November 19, 2007 Revised Submission Deadline Aug 25, 2008 S4 Voting List Deadline August 5, 2007 OMG Technical Meeting Sept 22-26, 2008 * Orlando EEUU B1 SoaML FTF Feb., 2009 OMG Technical Meeting Dec 08-12, 2008 * Santa Clara EEUU S5 Revised Submission Deadline Nov 10, 2008 AMP, Aug B2 SoaML FTF Nov., 2009 BPMN 2.0, Dec SoaML FTF Rec. Dec., 2009, Los Angeles B2 SoaML final standard March, 2010 (veto, by Oct. 2010)

10 Metamodels and profiles model <-> meta-model relationship extension relationship MOF M3 UML process generic Meta-model M2 UML Real-time UML For J2EE Migration oriented process Meta-model Workflow Meta-model real-time model migration model Workflow model M1 10

11 UML/SoaML Metamodel approach P2 11

12 UML/SoaML Metamodel approach P3 12

13 SoaML/ShaML Metamodel approach P4 13

14 SoaML references n OMG Web site n n SoaML Wiki: Specification: May 2009

15 UML tools with SoaML n MagicDraw, NoMagic n Enterprise Architect, Sparq n Modelio, Softeam n RSA/RSM, IBM n 15

16 SoaML Goals n n n n n n n n n n n Intuitive and complete support for modelling services in UML Support for bi-directional asynchronous services between multiple parties Support for Services Architectures where parties provide and use multiple services. Support for services defined to contain other services Easily mapped to and made part of a business process specification Compatibility with UML, BPDM and BPMN for business processes Direct mapping to web services Top-down, bottom up or meet-in-the-middle modelling Design by contract or dynamic adaptation of services To specify and relate the service capability and its contract No changes to UML 16

17 SoaML Scope n Extensions to UML2.1 to support the following new modeling capabilities: n Identifying services n Specifying services n Defining service consumers and providers n Policies for using and providing services. n Defining classification schemes n Defining service and service usage requirements and linking them to related OMG metamodels, such as the BMM and BPMN 2.0. n SoaML focuses on the basic service modelling concepts n A foundation for further extensions both related to integration with other OMG metamodels like BPMN 2.0, SBVR, OSM, ODM and others. n SoaML is NOT a methodology 17

18 Definition of service in SoaML n A service is value delivered to another through a well-defined interface and available to a community (which may be the general public). A service results in work provided to one by another. n Service Oriented Architecture (SOA) is a way of describing and understanding organizations, communities and systems to maximize agility, scale and interoperability. n SOA, then, is an architectural paradigm for defining how people, organizations and systems provide and use services to achieve results. n SoaML provides a standard way to architect and model SOA solutions using the Unified Modeling Language (UML). 18

19 SOA in Model Driven Architecture (MDA) MDA Terms Business Concerns Computation Independent Model Platform Independent Model Business Model Enterprise Goals Services (e-soa) Roles, Collaborations & Interactions Process & Information Policy Customers Logical System Model Technology Costs Services (t-soa), Components Interfaces, Messages & Data Agility Refinement & Automation Line-Of-Sight Platform Specific Model Technology Specification JMS, JEE, Web Services WSDL, BPEL, XML Schema 19

20 SoaML Key concepts n Services architecture specification of community n Participants role n Service contracts collaboration (provide and consume) n Service contract specification of service n Role Provider and consumer n Interfaces n Choreography (protocol, behaviour) n Service interface bi-directional service n Simple interface one-directional service n Message Type data exchanged between services 20

21 Marketplace Services Example Consumer Order Conformation Shipped Provider Mechanics Are Us Dealer Consumer Physical Delivery 21 Status Provider Provider GetItThere Freight Shipper Ship Req Shipped Delivered Acme Industries Manufacturer Consumer

22 ServiceContracts and ServiceArchitectures Metamodel

23 ServiceContracts and ServiceArchitectures Profile

24 UML 2.0 Collaboration diagrams and SoaML

25 Collaboration Start - Explanation of standard UML 2.3

26 Collaboration

27 CollaborationUse

28 CollaborationUse

29 CollaborationUse End - Explanation of standard UML 2.3

Services architecture Purchasing service Ship Status service Shipping service n A ServicesArchitecture (or SOA): n n n is a network of participant roles providing and consuming

30 Services architecture Purchasing service Ship Status service Shipping service n A ServicesArchitecture (or SOA): n n n is a network of participant roles providing and consuming services to fulfil a purpose. defines the requirements for the types of participants and service realizations that fulfil those roles. It is defined using a UML Collaboration. 30

31 Inside the Manufacturer Order Conformation Shipped Order Processing Service Ship Req Accounting Shipped Delivered 31

32 Service contract n A ServiceContract: n n n Fully specifies the service (terms, conditions, interfaces, choreography, etc.) is binding on both the providers and consumers of that service. is defined using a UML collaboration that is focused on the interactions involved in providing a service. n A participant plays a role in the larger scope of a ServicesArchitecture and also plays a role as the provider or user of services specified by ServiceContracts. 32

rvice contract Service Contract Role within service Role within service Service interface correspondin g to role Information received by orderer type type Information processed by order

33 rvice contract Service Contract Role within service Role within service Service interface correspondin g to role Information received by orderer type type Information processed by order processor Service interface correspondin g to role n The service contract specifies the details of the service what information, assets and responsibilities are exchanged and under what rules. 33

34 Simple protocol choreography for Ordering service contract Behaviour in SoaML can also be specified with Activity Diagrams or State Machines. 34

35 Participants Participant Participant n Participants: n n represent logical or real people or organizational units that participate in services architectures and/or business processes. provide and use services, defining their external contract 35

36 Service Choreography for Place Order The role of the consumer (a participant that places orders) and the consumers interface The role of the provider (an order taker) and their interface The optional interaction to return the quote The optional interaction to request a quote The required interaction to place an order The required interaction to accept or reject the order A more detailed look at the same service. Note that this models a fully asynchronous SOA like most business interactions, the document message types are detailed on the next page.

37 Service Data Metamodel

38 Service Data Profile

39 Message Detail for Place Order This is the detail for the message types that correspond to the interactions for the place order service. Note that at the technology level this can produce XML schema for the messages.

40 Example Information Model CRR Information Model

41 Linking messages to business information SOA Messages can reference and include parts of the logical information model forming a connection between SOA and enterprise data

Linking the Business Process A business process represents

Each participant is given a swimlane which contains the

actions carried out by each of the participants.

42 Linking the Business Process A business process represents the desired behavior among the various participants in a services architecture. This is modeled here as a UML activity. Each participant is given a swimlane which contains the actions carried out by that participant within the business process. The overall behavior emerges as an orchestration of the actions carried out by each of the participants. Interactions with participants must be consistent with the service contracts by which they interact. This is the business process for the RIB Claims Processing enterprise SOA we saw earlier.

43 UML 2.0 Composite diagrams and SoaML

44 Service ports and service participants n A Service port: n n n 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>> n 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. 44

45 ServiceInterfaces and Participants Metamodel 45

46 ServiceInterfaces and Participants Profile 46

UML Composite Diagrams n Composite Diagrams A composite structure diagram is a diagram that shows the internal structure of a classifier, including its interaction points to other parts of the system.

47 UML Composite Diagrams n Composite Diagrams A 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

48 Part n 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. 48

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

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

51 Object instance references instance name class name

52 Composite Structure

53 Composite class (incomplete) n with parts, ports and connectors part ATM port User-Reader :CardReader User-Screen :Screen ATM-bank User-Keyboard :Keyboard :CashDispenser connector User-Cash 53

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

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

56 Service interface n A ServiceInterface: n n 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). n A ServiceInterface is defined from the perspective of the service provider using three primary sections: n n n provided and required Interfaces ServiceInterface class protocol Behavior. 56

Participant with service and request ports n n n A Service Port is typed by a ServiceInterface A Request port is typed by a conjugate ServiceInterface (defines the use of a

57 Participant with service and request ports n n n 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. 57

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

58 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

Logical System Components Components implement

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

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

61 Service Architecting Examples from European SESAR Project of Air Traffic Management Overall Architecting Process Overview Service Architecting Process Overview 61

62 Service architecting process 62

63 Service Design Refined capabilities model Consolidated Service Portolio Specify static aspects Specify detailed service contract and service interfaces Specify service messages and data types Service Architectures Draft service contracts Optional activity Optional artefact Specify dynamic aspects Specify service behaviour Specify service orchestration Specify provision aspects Specify Quality of Service and Service Policies Specify service provision by participants Service contract Service Interface Specification Quality of Service specification Service Policies Specification 63

64 Service Interface Specification characteristics Communication Technology Service Data Message Schema Service Provision/ Consumption architecture design Interoperability Level Design Abstraction Level Service Design HIGH LEVEL LOGICAL HIGH LEVEL LOGICAL N/A Physical Service Design Interface DETAILED / TECHNOLOGY- ORIENTED PHYSICAL DETAILED PHYSICAL IDENTIFIED 64

65 Service to requirements mapping 65

66 Capability to Requirements mapping 66

67 Service to Capability mappings 67

68 Service to BPMN operational process BPMN Book a VPA Name: Book a VPA Author: Ashley Willias Version: 1.0 Created: :00:00 Updated: :00:00 National Level (Military Air?) Base Alpha Tiger 16 Squadron Tiger Leader Fighter 25 Approved Agency Beta Day before operation [2] As soon as the airspace volume is identified L1093 Receive confirmed booking Book a ARES L1093 or VPA [1] (User Task) Update the booking [2] (User Task) The ARES; The date; The slot for the Identifiy conflict [4] (Service Task) mission (start and end time); The priority. VPAs (VPAX1, X2, X4 and X6) he needs to book; Upper and Lower levels; Penetration status segregation or restriction. Call sign; Number and type of aircraft; Aerodrome of departure (ADEP); Aerodrome of destination (ADES); Mission type; Link with another mission (if existing). Conflict between 2 requests identified [4] Confirm the booking [2] (User Task) Confirm Booking [3] (User Task) Identifiy conflict [4] (Service Task) Send confirmed booking Highlight conflict [4] (Service Task) YES Conflict between 2 requests identified [4] Receive counter proposal [10.1] Make a counter proposal [5] (User Task) Highlight conflict [4] (Service Task) Send counter proposal Accept counter Proposal [11.1] (User Task) Acceptable? [11.1] Accept counter Proposal [7] (User Task) Receive counter proposal Approve the booking [9/12] (User Task) Receive acception [8] Result? Bookings approved Counter proposal [8] Counter proposal accepted [11.1] Receice rejection [8.2] Accept [8] Propose another solution [8.1] (User Task) Check proposal [9.2] (User Task) Reject [8] Send acception Is another solution suitable? Move other mission [9.1] Coordinate with Squadron Leader [8.2] NO Don't approve the booking [10.2] (User Task) Send rejection [8.2] ARES not booked [11.2] 68

69 Focus on service interactions BPMN Request an ARES Name: Request an ARES Author: Ashley Willias Version: 1.0 Created: :23:42 Updated: :29:07 «Pool» AMC «Pool» Airspace User Confirmed request Book a ARES L1093 or VPA [1] (User Task) Counter proposal Identifiy conflict [4] (Service Task) Confirm Booking [3] (User Task) Counter proposal accepted Make a counter proposal [5] (User Task) Highlight conflict [4] (Service Task) Counter proposal Accept counter Proposal [7] (User Task) Acception Approve the booking [9/12] (User Task) Update the booking [2] (User Task) Request approved Check proposal [9.2] (User Task) Rejection ARES not booked 69

70 Service to Activity relationship 70

71 ServiceInterface interaction 71

72 Service Architecture 72

73 Quality of Service (QoS) 73

74 ServiceInterface to ServiceFunction 74

75 Service MessageType 75

76 Service Message Types «messagetype» ClearanceRequestMessage - flightid: FlightIdent «messagetype» ClearanceMessage Composition of message (adding payload) - clearanceid: CharacterString Defining message attributes «messagetype» Acknow ledgeclearancemessage «messagetype» DepartureClearanceMessage «messagetype» StartupApprovalMessage Projection of An AIRM entity «datatype» Runw ay «datatype» TSAT «datatype» SID «datatype» SSR «datatype» Frequency - designator: TextDesignatorType - time: DateTime - si d: StandardInstrumentDeparture - ssrcode: SSRCode - frequency: FrequencyType «trace» Using AIRM datatypes for typing of attributes «messagetype» DepartureClearanceAndStartupApprov almessage Runw ay::runw ay {root} + designator: TextDesignatorType + type: CodeRunwayType + nominallength: Distance + lengthaccuracy: Distance + nominalwidth: Distance + widthaccuracy: Distance + widthshoulder: Distance + lengthstrip: Distance + widthstrip: Distance + lengthoffset: ValDistanceSignedType + widthoffset: ValDistanceSignedType + abandoned: Logical Related AIRM entity «messagetype» Message and DataTypes:: Acknow ledgementmessage - acknowledgement: Acknowledgement 0..* «datatype» Message and DataTypes::Error - code: CharacterString - description: CharacterString Acknowledgement/error message and data type 76

77 ISO n Services (from ISO/TC211 Geographic Information but is mostly independent of the domain) See ISO standard document on course web page / Dropbox 77

78 Interface with Message Type 78

79 Architectural reference model 79

80 Service Taxonomy service types 80

81 Logical multi tiered architecture 81

82 Service life cycle 82

83 The REST architectural style describes six constraints. These constraints, applied to the architecture, were originally communicated by Roy Fielding in his doctoral dissertation (see and defines the basis of RESTful-style See 83

84 84

85 85

86 86

87 87

88 88

89 89

90 90

INF5120 Modelbased System development

INF5120 Modelbased System development Lecture 9: 12.03.2018 Arne-Jørgen Berre arneb@ifi.uio.no and Arne.J.Berre@sintef.no 1 Course parts (16 lectures) 2018 Part I-a -(Introduction to Modeling): 15/1 -