Post on 20-May-2022
Telecom and Informatics 1
INF5120”Modellbasert Systemutvikling”
”Modelbased System development”
Lecture: 11.04.2016Arne-Jørgen Berre
arneb@ifi.uio.no or Arne.J.Berre@sintef.no
Telecom and Informatics
Contentn Service Modelingn SoaML introduction n UML 2.0 Collaboration modelsn SoaML – Service Architecturen UML 2.0 Composite modelsn SoaML – Port/connector models
n Patternsn Design Patterns
2
Telecom and Informatics
Course parts (16 lectures)
3
n January – February (1-7) (BAE/WebRatio): n 1-18/1: MDE-1: Introduction to INF5120n 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 7th), Agile Scrumn March (8,9) (MDE/IFML/Client-Side): n 8-7/3: MDE-3: Model driven engineering – Metamodels, DSL, UML Profiles, EMF, Sirius
Editorsn 9-14/3: SAE-2: IFML – Interaction Flow Modeling Language, WebRatio advancedn April (10, 11,12,13) (BPMN, SAE/UML/Server-side): n 10-4/4: SAE-3: BPMN and WebRatio BPM platform/Magicdraw BPMNn 11/4: SAE-4: UML Service Modeling, ServiceML,SoaML, REST, UML 2.0 Composition,
MagicDrawn 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 1700-1800)n Oblig 2: Sirius DSL Editor for IFML +/- (individual), WebRatio/IFML App2 UI (inc. 2) (April 18th )n 13-25/4:SAE-5: MDE transformations, Non Functional requirements – OCL and PLanguagen May (14,15,16): (Bringing it together)n 14-2/5: SAE-6: Final WebRatio App demo and discussion day (May 2nd) n Oblig 3: SA Spec (More models), WebRatio/IFML App 3 Server (Inc. 3) (May 2nd)n 15-9/5: MDE-5: Enterprise Architecture, TOGAF, UPDM, SysML – DSLs etc. – Big picturen 16-23/5: MDE-6: Conclusions/Summary of the course/Preparation for the Examn 6/6: Exam (4 hours), (June 6th)
Telecom and Informatics
MagicDrawCameo Enterprise Architecture
4
Telecom and Informatics 5
Telecom and Informatics
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 AIRMn GRA UML connected to NIEMn ISO 19119 connected to ISO 19103, and RM/ODP
6
Telecom and Informatics
SoaML Introduction
See SoaML standard document on course web page / Dropbox
Telecom and Informatics
8
SoaML history
n 2006, September OMG RFPn 2007, June 3 initial submissionsn 2008 & 2009 Merge processn 2009, December SoaML 1.0 finishedn 2010, March SoaML 1.0 adopted by OMGn 2011, December SoaML 1.0 formal standard by OMG
n FTF chairs: Arne J. Berre, SINTEF and Jim Amsden, IBM
n http://www.soaml.org
8
Telecom and Informatics
UPMS SoaML Timeline
IssuedSeptember 29, 2006
LOI DeadlineNovember 28, 2006
Initial Submission Deadline June 4, 2007
Voting List Deadline August 5, 2007
Revised SubmissionNovember 19, 2007
Revised Submission Deadline May 26, 2008
OMG Technical Meeting June 23-27, 2008 * Ontario Canada
IBM,... Fujitsu,... SHAPE,...
Adaptive,...
Revised Submission Deadline Aug 25, 2008
OMG Technical MeetingSept 22-26, 2008 * Orlando EEUU
OMG Technical MeetingDec 08-12, 2008 * Santa Clara EEUU
Revised Submission Deadline Nov 10, 2008
S1(3)
S2(2)S3(1)
S4
S5
Sx – Submission version xBx – Beta version x
SoaML FTF Feb., 2009B1
SoaML FTF Nov., 2009 SoaML FTF Rec. Dec., 2009, Los Angeles
SoaML final standardMarch, 2010 (veto, by Oct. 2010)
B2
BPMN 2.0, Dec. 2009
AMP, Aug. 2009
B2
Telecom and Informatics
10
Metamodels and profiles
MOF
UML process genericMeta-model
real-timemodel
WorkflowMeta-model
UMLFor J2EE
migrationmodel
Workflowmodel
Migration orientedprocess Meta-model
UMLReal-time
M3
M2
M1
extensionrelationship
model <-> meta-modelrelationship
Telecom and Informatics
11
UML/SoaML Metamodel approach – P2
Telecom and Informatics
12
UML/SoaML Metamodel approach – P3
Telecom and Informatics
13
SoaML/ShaML Metamodel approach –P4
Telecom and Informatics
May 2009
SoaML references
n OMG Web siten SoaML Wiki: http://www.SoaML.orgn Specification:
http://www.omgwiki.org/SoaML/doku.php?id=specification
Telecom and Informatics
UML tools with SoaML
n MagicDraw, NoMagic
n Enterprise Architect, Sparq
n Modelio, Softeam
n RSA/RSM, IBM
n …
15
Telecom and Informatics
16
SoaML – Goals
n Intuitive and complete support for modelling services in UMLn Support for bi-directional asynchronous services between multiple partiesn Support for Services Architectures where parties provide and use multiple
services.n Support for services defined to contain other servicesn Easily mapped to and made part of a business process specificationn Compatibility with UML, BPDM and BPMN for business processesn Direct mapping to web servicesn Top-down, bottom up or meet-in-the-middle modellingn Design by contract or dynamic adaptation of servicesn To specify and relate the service capability and its contractn No changes to UML
Telecom and Informatics
17
SoaML – Scope
n Extensions to UML2.1 to support the following new modeling capabilities:n Identifying servicesn Specifying servicesn Defining service consumers and providersn Policies for using and providing services.n Defining classification schemesn 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 conceptsn 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
Telecom and Informatics
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).
Telecom and Informatics
19
Business Concerns
Goals
Policy
Customers
Costs
Agility
Technology SpecificationJMS, JEE, Web ServicesWSDL, BPEL, XML Schema
Logical System ModelTechnology Services (t-SOA), ComponentsInterfaces, Messages & Data
SOA in Model Driven Architecture (MDA)
Business ModelEnterprise Services (e-SOA)Roles, Collaborations & InteractionsProcess & Information
Refinem
ent & A
utomation
Line-Of-Sight
Com
puta
tion
Inde
pend
ent
Mod
el
Plat
form
Inde
pend
ent
Mod
el
Plat
form
Spec
ific
Mod
elMDATerms
Telecom and Informatics
20
SoaML – Key concepts
n Services architecture – specification of communityn Participants – rolen Service contracts – collaboration (provide and
consume)n Service contract – specification of service
n Role – Provider and consumer n Interfacesn Choreography (protocol, behaviour)
n Service interface – bi-directional servicen Simple interface – one-directional servicen Message Type – data exchanged between services
Telecom and Informatics
21
Marketplace Services – Example
Order
Conformation
Ship Req
Shipped
Shipped
PhysicalDelivery
Delivered
Status
Provider
Consumer
ProviderC
onsu
mer
Consumer
Provider
GetItThere Freight Shipper
Mechanics Are UsDealer
Acme IndustriesManufacturer
Telecom and Informatics
ServiceContracts and ServiceArchitectures Metamodel
Telecom and Informatics
ServiceContracts and ServiceArchitectures Profile
Telecom and Informatics
UML 2.0 Collaboration diagramsand SoaML
Telecom and Informatics
Collaboration
Start - Explanation of standard UML 2.3
Telecom and Informatics
Collaboration
Telecom and Informatics
CollaborationUse
Telecom and Informatics
CollaborationUse
Telecom and Informatics
CollaborationUse
End - Explanation of standard UML 2.3
Telecom and Informatics
30
Services architecture
n A ServicesArchitecture (or SOA):n is a network of participant roles providing and consuming services to fulfil a
purpose. n defines the requirements for the types of participants and service realizations that
fulfil those roles.n It is defined using a UML Collaboration.
Shipping service
Ship Status service
Purchasing service
Telecom and Informatics
31
Inside the Manufacturer
Order
Conformation
Shipped
Ship Req
Shipped
Delivered
Order Processing
Accounting
Service
Telecom and Informatics
32
Service contract
n A ServiceContract:n Fully specifies the service (terms, conditions, interfaces, choreography, etc.)n is binding on both the providers and consumers of that service. n 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.
Telecom and Informatics
33
Service contract
n The service contract specifies the details of the service – what information, assets and responsibilities are exchanged and under what rules.
Role within service
Role within service
Service Contract
Service interface corresponding to role
Service interface corresponding to role
Information processed by order processor
Information received by orderer
type type
Role within service
Telecom and Informatics
34
Behaviour in SoaML can also be specified with Activity Diagrams or State Machines.
Simple protocol choreography for Ordering service contract
Telecom and Informatics
35
Participants
n Participants:n represent logical or real people or organizational units that participate in services
architectures and/or business processes. n provide and use services, defining their external contract
ParticipantParticipant
Telecom and Informatics
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 request a quoteThe optional interaction to
return the 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.
Telecom and Informatics
Service Data Metamodel
Telecom and Informatics
Service Data Profile
Telecom and Informatics
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.
Telecom and Informatics
Example Information ModelCRR Information Model
Telecom and Informatics
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
Telecom and Informatics
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.
Telecom and Informatics
UML 2.0 Composite diagramsand SoaML
Telecom and Informatics
44
Service ports and service participants
n A Service port:n is the offer of a service by one participant to others using well defined terms,
conditions and interfacesn defines the connection point through which a Participant offers its capabilities and
provides a service to clients.n 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.
Telecom and Informatics
45
ServiceInterfaces and Participants Metamodel
Telecom and Informatics
46
ServiceInterfaces and Participants Profile
Telecom and Informatics
UML Composite Diagramsn 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.
47
Start - Explanation of standard UML 2.3
Telecom and Informatics
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
Telecom and Informatics
Portsn 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).
A behaviour port
In interface
Out interface
Telecom and Informatics
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).
Telecom and Informatics
Object instance references
instance name
class name
Telecom and Informatics
Composite Structure
Telecom and Informatics 53
Composite class (incomplete)n with parts, ports and connectors
ATM
:CardReader
:CashDispenser:Keyboard
User-Reader
User-Keyboard
ATM-bank
User-Cash
:ScreenUser-Screen
part
port
connector
Telecom and Informatics 54
Context Model in UML2.0 - In composite structure as part of a Collaboration
BankContext
:User :ATM :Bank
User-Reader
User-Keyboard
ATM-bank
User-Cash
User-Screen
Telecom and Informatics 55
Context Model in UML2.0 - II
n Including multiplicities on parts
BankContext
:User[1..10000]
:ATM[1..100] :Bank
User-Reader
User-Keyboard
ATM-bank
User-Cash
User-Screen
multiplicity
End - Explanation of standard UML 2.3
Telecom and Informatics
56
Service interface
n A ServiceInterface:n can type a service port. n 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 provided and required Interfacesn ServiceInterface classn protocol Behavior.
Telecom and Informatics
57
Participant with service and request ports
n A Service Port is typed by a ServiceInterfacen 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.
n Can be transformed to the appropriate interface/implementation code.
Telecom and Informatics
Interfaces for ParticipantsEach 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
Telecom and Informatics
Logical System ComponentsComponents 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
Telecom and Informatics
Composite Application Components
Components can be assembled from other components by linking their services. This corresponds to the architecture for Acme.
Enterprise systems can be integrated with adapter components
Or, new implementation can be defined inside of components.
This component is defined as a composition of other components.
Telecom and Informatics
Service Architecting
61
Overall Architecting Process Overview
Service Architecting Process Overview
Examples from European SESARProject of Air Traffic Management
Telecom and Informatics
Service architecting process
62
Telecom and Informatics
Service Design
63
Service contract
Specify service messages and data types
Specify service behaviour
Specify Quality of Service and Service Policies
Specify service orchestration
Refined capabilities
model
Specify detailed service contract and service interfaces
Optional activity
Optional artefact
Service Interface
Specification
Service Policies
Specification
Quality of Service
specification
Specify service provision by participants
Spec
ify s
tatic
asp
ects
Spec
ify d
ynam
ic a
spec
ts
Spec
ify p
rovi
sion
asp
ects
ConsolidatedService Portolio
Service Architectures
Draft service contracts
Telecom and Informatics
Service Interface Specification characteristics
64
Design Abstraction Level
Interoperability Level
Service Provision/ Consumption architecture design
Service Data Message Schem
a
Comm
unication Technology
Service Design HIGH LEVEL LOGICAL HIGH LEVEL LOGICAL N/A
Physical Service InterfaceDesign
DETAILED / TECHNOLOGY-
ORIENTEDPHYSICAL DETAILED PHYSICAL IDENTIFIED
Telecom and Informatics
Service to requirements mapping
65
Telecom and Informatics
Capability to Requirements mapping
66
Telecom and Informatics
Service to Capability mappings
67
Telecom and Informatics
Service to BPMN operational process
68
BPMN Book a VPA
Natio
nal L
evel
Natio
nal L
evel
(Mili
tary
Air?
) Bas
e Al
pha
(Mili
tary
Air?
) Bas
e Al
pha
Tige
r 16
Tige
r 16
Squa
dron
Tig
erLe
ader
Squa
dron
Tig
erLe
ader
Name: Book a VPAAuthor: 08.03.05 Ashley Will iasVersion: 1.0Created: 20.11.2011 00:00:00Updated: 26.04.2012 00:00:00
Book a ARESL1093 or VPA[1] (User Task)
As soon as theairspace volume isidentified L1093
Day beforeoperation [2]
Update thebooking [2](User Task)
Confirm thebooking [2](User Task)
ConfirmBooking [3](User Task) Send
confirmedbooking
Appr
oved
Age
ncy
Beta
Appr
oved
Age
ncy
Beta
Receiveconfirmedbooking
Conflictbetween 2requestsidentified [4]
Conflictbetween 2requestsidentified [4]
Highlightconflict [4]
(Service Task)
Identifiyconflict [4]
(Service Task)
Identifiyconflict [4]
(Service Task)
Highlightconflict [4]
(Service Task)
Make a counterproposal [5](User Task)
Sendcounterproposal
Propose anothersolution [8.1](User Task)
Receivecounterproposal
Accept counterProposal [7](User Task)
Approve thebooking [9/12]
(User Task)
Bookings approvedReceiveacception [8]
Result?
Send acception
Figh
ter 2
5Fi
ghte
r 25
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).
Move other mission [9.1]
Receive counterproposal [10.1]
Accept counterProposal [11.1]
(User Task)
Acceptable?[11.1]
Counter proposal accepted [11.1]
Receice rejection [8.2]
Coordinate withSquadron Leader
[8.2]Send rejection [8.2]
Check proposal[9.2] (User
Task)
Is another solution suitable?
ARES not booked[11.2]
Don't approve thebooking [10.2]
(User Task)
Reject[8]
Counter proposal[8]
NO
YES
Accept [8]
Telecom and Informatics
Focus on service interactions
69
BPMN Request an ARES«P
ool»
AM
C«P
ool»
AM
C«P
ool»
Airs
pace
Use
r«P
ool»
Airs
pace
Use
r
Name: Request an ARESAuthor: 08.03.05 Ashley Will iasVersion: 1.0Created: 06.06.2013 18:23:42Updated: 06.06.2013 18:29:07
Confirm Booking [3](User Task)
Accept counterProposal [7] (User
Task)
Update the booking[2] (User Task)
Make a counterproposal [5] (User
Task)
Book a ARES L1093or VPA [1] (User
Task)
Check proposal [9.2](User Task)
Identifiy conflict [4](Service Task)
Highlight conflict [4](Service Task)
Approve the booking[9/12] (User Task)
Counter proposal Request approved ARES not bookedRejectionAcception
Counter proposalConfirmed request Counter proposal accepted
Telecom and Informatics
Service to Activity relationship
70
Telecom and Informatics
ServiceInterface interaction
71
Telecom and Informatics
Service Architecture
72
Telecom and Informatics
Quality of Service (QoS)
73
Telecom and Informatics
ServiceInterface to ServiceFunction
74
Telecom and Informatics
Service MessageType
75
Telecom and Informatics
Service Message Types
76
soaml MessageTypes
«messageType»DepartureClearanceAndStartupApprov alMessage
«datatype»SID
- sid: StandardInstrumentDeparture
«datatype»SSR
- ssrCode: SSRCode
«datatype»Frequency
- frequency: FrequencyType
«messageType»DepartureClearanceMessage
«messageType»StartupApprov alMessage
«messageType»AcknowledgeClearanceMessage
«messageType»ClearanceMessage
- clearanceID: CharacterString
«datatype»Runway
- designator: TextDesignatorType
«datatype»TSAT
- time: DateTime
«messageType»ClearanceRequestMessage
- fl ightID: FlightIdent
Runway::Runway{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
«trace»
Related AIRM entity
„Projection“ ofAn AIRM entity
Using AIRM datatypesfor typing of attributes
Defining messageattributes
Composition of message (adding payload)
Acknowledgement/error message and data type
soaml MessageAndDataTypes
«datatype»Message and DataTypes::Error
- code: CharacterString- description: CharacterString
«messageType»Message and DataTypes::
AcknowledgementMessage
- acknowledgement: Acknowledgement0..*
Telecom and Informatics
ISO 19119
n Services (from ISO/TC211 Geographic Information – but is mostly independent of the domain)
77
See ISO 19119 standard document on course web page / Dropbox
Telecom and Informatics
Interface with Message Type
78
Telecom and Informatics
Architectural reference model
79
Telecom and Informatics
Service Taxonomy – service types
80
Telecom and Informatics
Logical multi tiered architecture
81
Telecom and Informatics
Service life cycle
82
Telecom and Informatics 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 http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm) and defines the basis of RESTful-style
See http://www.restapitutorial.com/lessons/whatisrest.html
Telecom and Informatics 84
Telecom and Informatics 85
Telecom and Informatics 86
Telecom and Informatics 87
Telecom and Informatics 88
Telecom and Informatics 89
Telecom and Informatics 90