inf5120 ”modellbasert systemutvikling” ”modelbased system

Telecom and Informatics 1

INF5120”Modellbasert Systemutvikling”

”Modelbased System development”

Lecture: 11.04.2016Arne-Jørgen Berre

[email protected] or [email protected]

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


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)


MagicDrawCameo Enterprise Architecture

4


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


SoaML Introduction

See SoaML standard document on course web page / Dropbox


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


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


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


11

UML/SoaML Metamodel approach – P2


12

UML/SoaML Metamodel approach – P3


13

SoaML/ShaML Metamodel approach –P4


May 2009

SoaML references

n OMG Web siten SoaML Wiki: http://www.SoaML.orgn Specification:

http://www.omgwiki.org/SoaML/doku.php?id=specification


UML tools with SoaML

n MagicDraw, NoMagic

n Enterprise Architect, Sparq

n Modelio, Softeam

n RSA/RSM, IBM

n …

15


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


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


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


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


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


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


ServiceContracts and ServiceArchitectures Metamodel


ServiceContracts and ServiceArchitectures Profile


UML 2.0 Collaboration diagramsand SoaML


Collaboration

Start - Explanation of standard UML 2.3


Collaboration


CollaborationUse


CollaborationUse

End - Explanation of standard UML 2.3


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


31

Inside the Manufacturer

Order

Conformation

Shipped

Ship Req

Shipped

Delivered

Order Processing

Accounting

Service


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.


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


34

Behaviour in SoaML can also be specified with Activity Diagrams or State Machines.

Simple protocol choreography for Ordering service contract


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


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.


Service Data Metamodel


Service Data Profile


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.


Example Information ModelCRR Information Model


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


UML 2.0 Composite diagramsand SoaML


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.


45

ServiceInterfaces and Participants Metamodel


46

ServiceInterfaces and Participants Profile


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


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


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


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


Object instance references

instance name

class name


Composite Structure


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


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


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


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.


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.


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


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


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.


Service Architecting

61

Overall Architecting Process Overview

Service Architecting Process Overview

Examples from European SESARProject of Air Traffic Management


Service architecting process

62


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


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


Service to requirements mapping

65


Capability to Requirements mapping

66


Service to Capability mappings

67


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]


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


Service to Activity relationship

70


ServiceInterface interaction

71


Service Architecture

72


Quality of Service (QoS)

73


ServiceInterface to ServiceFunction

74


Service MessageType

75


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


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


Interface with Message Type

78


Architectural reference model

79


Service Taxonomy – service types

80


Logical multi tiered architecture

81


Service life cycle

82


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

inf5120 ”modellbasert systemutvikling” ”modelbased system

Documents