INF5120 Modellbasert Systemutvikling

Transcription

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

2 Content Service Modeling SoaML introduction o UML 2.0 Collaboration models SoaML Service Architecture UML 2.0 Composite models SoaML Port/connector models Download MagicDraw from NoMagic full EA version (Updated license file until September 1, 2013 is now provided) 2

3 Oblig 1 Group work Service Innovation and Design TravelAdvisor 1. Business Model Osterwalder/Strategyzer.com 2. Service Design with smaply.com Personas, Stakeholder maps, Customer/Service journey maps 3. BPMN diagrams (use of Cameo EA MagicDraw) 4. User stories (Agile) and selected Use cases (use of Cameo EA MagicDraw) 5. UI Mockup (Balsamiq) 6. Non functional requirements 3

4 Oblig 3 Group work Model-based Realisation of TravelAdvisor TravelAdvisor Model-based Realisation with UML/No Magic Enterprise Architecture models and WebRatio implementation The starting point is the TravelAdvisor specifications from Oblig 1 OBLIG 3: Part 1: Use of UML modeling with No Magic/MagicDraw Cameo Enterprise Architecture 1. Create an Information Model for TravelAdvisor (UML class model according to the ISO standard) 2. Create a Service Archtiecture for TravelAdvisor (UML/SoaML model according to the ISO standard and SoaML specify only the main functional services as components with ports/interfaces and the dynamics with a UML sequence diagram). Create also a corresponding Service Architecture using a SoaML collaboration diagram Part 2: Realise TravelAdvisor using WebRatio 3. Use WebRatio to create a WebRatio Information/class model 4. Use WebRatio to create an IFML model with the main user interfaces specified in Oblig 1 5. Use WebRatio to create a web-based running application for TravelAdvisor populate it for representative travel destination(s) 4

5 MagicDraw Cameo Enterprise Architecture 5

6 6

7 INF Lecture plan (13/1): Introduction overview of the course. Enterprise Architecture with UML and BPMN and DSLs 2 (20/1): Business Architecture Business Model Canvas and Business Model Innovation with Value Networks, Strategyzer tool. BPMN modeling, MagicDraw EA tool 3: (27/1): Service Innovation and Service Design, AT ONE, Smaply BPMN Examples 4 (3/2): User experience and Touchpoints/UI Design Balsamiq/WebRatio 5 (10/2): UML and Req.Modeling Agile User stories versus Use cases (17/2): ServiceML, Requirements Modeling, Goal Modeling, BMM, and Non Functional requirements Requirements Engineering 7 (24/2): UI Models, WebML and IFML, Process models (WebRatio) (for Oblig 3) 8 (3/3): Model driven engineering Metamodels, DSL, UML Profiles (for Oblig 2) 9(10/3): Model driven engineering, transformation technologies (for Oblig 2) 10(17/3): Method Engineering, SW Process frameworks, SPEM/EPF, ISO 24744, FACESEM/ESSENCE (Brian Elvesæter) 11(24/3): Enterprise Architecture (EA) UPDM, TOGAF, and SysML - Oblig 1 and 2 12(31/3): System Architecture and Information/Ontology modeling, UML, ISO (7/4): UML Service Modeling SoaML, UML 2.0 Collaboration/Service composition EASTER 14(28/4): Guest lecture Cloud modeling and/or Semantic modeling - and work on Oblig 2 and Oblig 3 15(5/5): Oblig 2 and 3, System realisation models (MagicDraw, JEE), MDA-ADM, Cloud, SBVR, MDI 16(12/5): Conclusion and Summary for INF5120 -Final Oblig review 17(19/5): Preparation for Exam Exam: Monday June 2nd, 2014, (4 hours) 7

8 Service Modeling and Service Design UML 2.0 Components with Ports, SoaML (and SysML) Service views in UPDM, (DODAF/MODAF/NAF) SESAR ISRM connected to AIRM GRA UML connected to NIEM ISO connected to ISO 19103, and RM/ODP WebRatio Information Models, UI models and service models Preparations for Oblig 3 8

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

10 SoaML history 2006, September 2007, June 2008 & , December 2010, March 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 FTF chairs: Arne J. Berre, SINTEF and Jim Amsden, IBM

11 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 e Aug 25, 2008 S4 Voting List Deadline August 5, 2007 OMG Technical Meeting Sept 22-26, 2008 * Ol Orlando EEUU B1 SoaML FTF Feb., 2009 AMP, Aug OMG Technical Meeting Dec 08-12, 2008 * Santa Clara EEUU S5 Revised Submission Deadline Nov 10, 2008 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)

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

13 UML/SoaML Metamodel approach P2 13

14 UML/SoaML Metamodel approach P3 14

15 SoaML/ShaML Metamodel approach P4 15

16 SoaML references OMG Web site SoaML Wiki: Specification: May 2009

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

18 SoaML Goals 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 18

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

20 Definition of service in SoaML 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. Service Oriented Architecture (SOA) is a way of describing and understanding organizations, communities and systems to maximize agility, scale and interoperability. SOA, then, is an architectural paradigm for defining how people, organizations and systems provide and use services to achieve results. SoaML provides a standard way to architect and model SOA solutions using the Unified Modeling Language (UML). 20

21 SOA in Model Driven Architecture (MDA) MDA Terms Business Concerns Compu tation Indepen ndent Model Platfo orm Indep pendent Mode l 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 Refineme nt & Auto omation L ine-of-sig ght Platform Specific Model Technology Specification JMS, JEE, Web Services WSDL, BPEL, XML Schema 21

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

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

24 ServiceContracts and ServiceArchitectures Metamodel

25 ServiceContracts and ServiceArchitectures Profile

26 UML 2.0 Collaboration diagrams and SoaML

27 Collaboration Start - Explanation of standard UML 2.3

28 Collaboration

29 CollaborationUse

30 CollaborationUse

31 CollaborationUse End - Explanation of standard UML 2.3

32 Services architecture Purchasing service Ship Status service Shipping service A ServicesArchitecture (or SOA): 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. 32

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

34 Service contract AS ServiceContract: t 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. 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. 34

35 rvice contract Service Contract Role within service Role l 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 The service contract specifies the details of the service what information, assets and responsibilities are exchanged and under what rules. 35

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

37 Participants Participant Participant Participants: 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 37

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

39 Service Data Metamodel

40 Service Data Profile

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

42 Example Information Model CRR Information Model

43 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

44 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 h 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.

45 UML 2.0 Composite diagrams and SoaML

46 The image cannot be displayed. Your computer may not have enough memory to open the image, or the image may have been corrupted. Restart your computer, and then open the file again. If the red x still appears, you may have to delete the image and then insert it again. 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. 46

47 ServiceInterfaces and Participants Metamodel 47

48 ServiceInterfaces and Participants Profile 48

49 UML Composite Diagrams 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

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

51 Ports A port is attached to an active class. The port has: A name. An interface specifying i the signals that t 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

52 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).

53 Object instance references instance name class name

54 Composite Structure

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

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

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

58 Service interface 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. 58

59 The image cannot be displayed. Your computer may not have enough memory to open the image, or the image may have been corrupted. Restart your computer, and then open the file again. If the red x still appears, you may have to delete the image and then insert it again. 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. 59

60 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

61 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

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

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

64 Service architecting process 64

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

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

67 Service to requirements mapping 67

68 Capability to Requirements mapping 68

69 Service to Capability mappings 69

70 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 se Alpha (Military Air?) Bas Tiger 16 Tiger Squadron T Leader Day before operation [2] As soon as the airspace volume is identified L1093 Book a ARES L1093 or VPA [1] (User Task) Update the booking [2] (User Task) The ARES; The date; The slot for the 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). Confirm the booking [2] (User Task) Confirm Booking [3] (User Task) Identifiy conflict [4] (Service Task) Send confirmed booking Conflict between 2 requests identified [4] Highlight conflict [4] (Service Task) Accept counter Proposal [7] (User Task) Receive counter proposal Counter proposal [8] Result? Propose another solution [8.1] (User Task) Accept [8] Reject [8] Send acception Move other mission [9.1] Coordinate with Squadron Leader [8.2] Send rejection [8.2] ghter 25 Fig Receive counter proposal [10.1] Accept counter Proposal [11.1] (User Task) Acceptable? [11.1] Counter proposal accepted [11.1] National Level Approved Agency Beta Receive confirmed booking Identifiy conflict [4] (Service Task) Conflict between 2 requests identified [4] Highlight conflict [4] (Service Task) YES Make a counter proposal [5] (User Task) Send counter proposal Approve the booking [9/12] (User Task) Receive acception [8] Receice rejection [8.2] Bookings approved Is another solution suitable? Check proposal [9.2] (User T ask) NO Don't approve the booking [10.2] (User Task) ARES not booked [11.2] 70

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

72 Service to Activity relationship 72

73 ServiceInterface interaction 73

74 Service Architecture 74

75 Quality of Service (QoS) 75

76 ServiceInterface to ServiceFunction 76

77 Service MessageType 77

78 Service Message Types «messagetype» ClearanceRequestMessage - flightid: FlightIdent «messagetype» ClearanceMessage Composition of message (adding payload) - clearanceid: CharacterString Defining message attributes «messagetype» AcknowledgeClearanceMessage «messagetype» DepartureClearanceMessage «messagetype» StartupApprov almessage Projection of An AIRM entity «datatype» Runw ay «datatype» TSAT «datatype» SID «datatype» SSR «datatype» Frequency - designator: TextDesignatorType - time: DateTime - sid: 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:: AcknowledgementMessage - acknowledgement: Acknowledgement 0..* «datatype» Message and DataTypes::Error - code: CharacterString - description: CharacterString Acknowledgement/error message and data type 78

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

80 Interface with Message Type 80

81 Architectural reference model GIS applications GIS applications API API API Geographic API API Geographic API Information Services Information Services Service access Information Technology Services Information Technology Services HTI ISI CSI CSI ISI HTI NNI NNI Legend API - Aplication Programming Interface HTI - Human Technology Interface ISI - Information Services Interface CSI - Communications Services Interface NNI - Network to Network Interface Data sharing and transfer based on common conceptual models 81

82 Service Taxonomy service types HTI API IT HS GHS GIS applications API Geographic Information Services GMS GWS GSS GPS GCS Information Technology Services IT MS IT WS ISI IT SS IT PS IT CS CSI API NNI Legend G - Geographic IT - Information Technology HS - Human Interaction Services MS - Model Management Services WS - Workflow/Task Services SS - System Management Services PS - Processing Services CS - Communication Services The approach is to define Geographic Information Services in each of the six groups, where general Information Technology services do not meet the requirements. 82

83 Logical multi tiered architecture Human interaction services Communication services User processing services Shared processing services Workflow/Task services System management services Model/Information management services 83

84 Service life cycle 84