INF5120 Modelbased System development

Size: px

Start display at page:

Download "INF5120 Modelbased System development"

Dwayne Barnett
5 years ago
Views:

1 INF5120 Modelbased System development Lecture 9: Arne-Jørgen Berre and 1

2 Course parts (16 lectures) 2018 Part I-a -(Introduction to Modeling): 15/1 - Start 1-15/1: Introduction to INF5120 Part I-b -(Introduction to Business Architecture and Business Modeling 2-22/1: Modeling structure and behaviour (UML and UML 2.0 and metamodeling) 3-29/1: Business Modeling BMC, LSC, VDML/VDMBee, (w/meta model) - (Business Model Canvas, Value Proposition, Lean Canvas Part II - (Modeling Server side Node-RED + THingML + Sensors/IoT/Cloud - and the Smart X project): ) 4-5/2: BPMN process - UML Activ.Diagram + Flow modelling Node-RED - establish Oblig groups (3-4 persons) 5-12/2: Node-RED/IBM Bluemix/Cloud getting started + Individual Oblig + VDMBee/VDML 6-19/2: Cognitive Services/AI Watson services example (for Oblig 1 and 2) (IBM Cloud presentation from IBM Norway) 7-26/2: ArchiMate 3.0 Modeling, TOGAF Design Thinking 8-5/3: Smart Office - Design Thinking workshop IBM new office, Lakkegata 33, Oslo 5/3 - Oblig 1: Individual - Node-RED 9-12/3: Service Modeling with UML 2.X Collaboration Models and Composite Models and SoaML Extra: 13/2: TJBot workshop at IBM, Lakkegata 53, /3: UML 2.x Sequence Diagrams, UML 2.x State Machines. ArchiMate ArchIsurance, ArhiMetal examples, 19/3 - Oblig 2: Specification Models Smart Office Business Architecture Business Canvases, + +, ArchiMate + IBM ChatBot Conversation (Individual) Introduction Oblig 3 for 23/4 ArchiMate + UML + BPMN EASTER 26/3 and 2/4 Part IIi - (Modeling Apps + EA/ArchiMate) 11-9/4 UI Server, UI Start lecture incl. CJML EA with ArchiMate - discussion/presentation, ThingML Part IV - (MDE Creating Your own Domain Specific Language Eclipse, Xtext/SIRIUS): 12-16/4: MDE with Xtext and SIRIUS 13-23/4: MDE transformations, Non Functional requirements 23/4 - Oblig 3: Smart Building Realisation with Node-RED, IBM Watson/IoT services + ArchiMate/UML++ Application, Technology, Physical models 10% 14-30/5 Guest lecture - Archi, Reenskaug, Gilb, Landmark, ThingML/Tellu, IBM, /5 Guest lecture 2 14/5 - Oblig 4 - Your own Domain Specific Language (DSL-x) - 10% 16-14/5: Summary of the course

3 Content ArchiMate Application view Service Modeling SoaML introduction UML 2.0 Collaboration models SoaML Service Architecture UML 2.0 Composite models SoaML Port/connector models 3

4 ArchiMate Authors : eschoolink Group - ITNLU

6 Layers Motivation layer Strategy layer

7 Layers, domains

8 Layers

9 Overview of the ArchiMate concepts and main relationships.

10 10

11 11

12 12

13 13

14 14

15 ArchiMate vs UML ArchiMate ArchiMate was created to model the architecture of an enterprise (all of the systems in an organization). ArchiMate models the business, information system (application and data), and technology architectures of the environment, including how these architectures are inter-related. 3.0 adds motivation and strategy. UML UML is a comprehensive way to document the architecture of a single system UML provides 13 diagram types, providing flexibility to describe many different types of systems.

16 Service Modeling and Service Design UML 2.0 Components with Ports, SoaML (and SysML) Service views in UPDM, (DODAF/MODAF/NAF) ISO connected to ISO 19103, and RM/ODP 16

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

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

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

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

21 UML/SoaML Metamodel approach P2 21

22 UML/SoaML Metamodel approach P3 22

23 SoaML/ShaML Metamodel approach P4 23

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

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

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

27 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 27

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

Business Concerns BusinessModel Model Business EnterpriseServices Services(e-SOA) (e-soa) Enterprise Goals Roles,Collaborations Collaborations&&Interactions Interactions Roles, Process&&Information

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

30 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 30

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

32 ServiceContracts and ServiceArchitectures Metamodel

33 ServiceContracts and ServiceArchitectures Profile

34 UML 2.0 Collaboration diagrams and SoaML

35 Collaboration Start - Explanation of standard UML 2.3

36 Collaboration

37 CollaborationUse

38 CollaborationUse

39 CollaborationUse End - Explanation of standard UML 2.3

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

40 Services architecture Purchasing service Shipping service Ship Status 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. 40

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

42 Service contract A ServiceContract: 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. 42

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

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

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

45 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 45

46 Service Choreography for Place Order The The role role of of the the consumer consumer (a (a participant participant that that places places orders) orders) and and the the consumers consumers interface interface The The optional optional interaction interaction to to return the quote return the quote The The role role of of the the provider provider (an (an order order taker) taker) and and their their interface interface The The optional optional interaction interaction to to request request aa quote quote The The required required interaction interaction to to place an order place an order The The required required interaction interaction to to accept or reject the order 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.

47 Service Data Metamodel

48 Service Data Profile

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

50 Example Information Model CRR Information Model

51 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

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

53 UML 2.0 Composite diagrams and SoaML

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

55 ServiceInterfaces and Participants Metamodel 55

56 ServiceInterfaces and Participants Profile 56

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.

57 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

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

59 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

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

61 Object instance references instance name class name

62 Composite Structure

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

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

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

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

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

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

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

68 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

Components implement the service interfaces providing the link to systems. Participants and services may be used in multiple architectures.

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

Composite Application Components Enterprise Enterprise systems systems can can be be integrated with adapter integrated with adapter components components This This component component is is defined

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

71 Service architecting process 71

72 Service Design 72

73 Service Interface Specification characteristics Service Design Physical Service Interface Design Design Abstraction Level Interoper ability Level Service Provision/ Consumption architecture design Service Data Message Schema Communication Technology HIGH LEVEL LOGICAL HIGH LEVEL LOGICAL N/A DETAILED / TECHNOLOGYORIENTED PHYSICAL DETAILED PHYSICAL IDENTIFIED 73

74 Service to requirements mapping 74

75 Service to BPMN operational process 75

INF5120 Modellbasert Systemutvikling Modelbased System development

INF5120 Modellbasert Systemutvikling Modelbased System development Lecture: 11.04.2016 Arne-Jørgen Berre arneb@ifi.uio.no or Arne.J.Berre@sintef.no 1 Content n Service Modeling n SoaML introduction n UML