INF5120 ”Modellbasert Systemutvikling” ”Modelbased ...€¦ · Telecom and Informatics 3...

Telecom and Informatics 1

INF5120”Modellbasert Systemutvikling”

”Modelbased System development”

Lecture 6: 18.02.2013Arne-Jørgen Berre

[email protected] or [email protected]

Telecom and Informatics

Content

n Oblig 1 – detailsn Business-SoaML,, Goal Modeling, BMM, and Non

Functional requirementsn Requirements Modelingn BMM – Business Motivation Modeln Goal Modeling - KAOSn Gilb - PLanguagen Non functional requirements, ISO etc.n …

2


INF5120 - Lecture plan - 2013

n 1 (14/1): Introduction – overview Enterprise Architecture with UML and BPMN and DSLsn 2 (21/1): Service Innovation and Design, AT ONE method/workshop – myServiceFellow

(Marika Lüders)n 3: (28/1): Value Networks/VDML BPMN, vs. UML Activity diagrams - Oryxn 4 (4/2): User experience and Touchpoints/UI Design – Balsamiq – (Amela Karahasanovic)n 5 (11/2): UML and Req.Modeling –Agile User stories versus Use casesn 6 (18/2): Business-SoaML, Requirements Modeling, Goal Modeling, BMM, and Non

Functional requirements

n 7 (25/2): Model driven engineering – Metamodels, DSL, UML Profiles etc., more on NFRn 8 (4/3): Model driven engineering EMF, Eclipse, GMFn 9 (11/3): Model driven engineering , transformation technologies (Franck Fleurey)

n 10(18/3): UML Service Modeling – SoaML, UML 2.0 Service composition, USDL, ISO 19119n 11(8/4): BPMN and Business Process Management and CMMN and Case Managementn 12(15/4): UML and Entity and Information modeling, UML, ISO 19103n 13(22/4): UML and Semantic models, Facts, SBVR, Ontologies, Rulesn 14(29/4): UML and Platform models, realisation, migration, Java, Apps, CloudMLn 15(6/5): Software Process modeling frameworks – SPEM/EPF, ISO 24744,

FACESEM/ESSENCEn 16(13/5): Conclusion and Summary for INF5120 - Preparation for Exam

n Exam: Monday June 3rd, 2013, (4 hours)


INF5120 – Oblig plan - 2013

n 1 (14/1): Introductionn 2 (21/1): myServiceFellown 3: (28/1): Oryxn 4 (4/2): Balsamiqn 5 (11/2): Use cases 2.0n 6 (18/2): Oblig 1 – Group work

n 7 (25/2): EMF and Eclipse – Group presentation – Business Modeln 8 (4/3): EMF and GMF – Group presentation -n 9 (11/3): Delivery of Oblig 1 – “Concierge – BA and Requirements Model”

n 10(18/3): Walk through of Oblig 1n 11(8/4): Delivery of Oblig 2 – “Value Network editor in Eclipse”n 12(15/4): Walk through of Oblig 2n 13(22/4): Group work, Oblig 3 – Group presentationn 14(29/4): Group work, Oblig 3 – Group presentationn 15(6/5): Delivery of Oblig 3 – “Concierge – SA Model”n 16(13/5): Walk trough of Oblig 3 - Preparation for Exam

n Exam: Monday June 3rd, 2013, (4 hours)


Obligs

n Partially individual, partially group - in 3 parts

n Oblig 1 – Group “Personal Concierge” - Businessarchitecture and requirement models (March 11)

n Oblig 2 – Individual – Eclipse editor for “Value networks”(April 8)

n Oblig 3 – Group “Personal Concierge” – Systemarchitecture (May 6)

5


Student GroupsGroup 1n [email protected] [email protected] [email protected] [email protected]

Group 2n [email protected] [email protected] [email protected]

Group 3n [email protected] [email protected] [email protected] [email protected]

6

n Group 4n [email protected] [email protected] [email protected] [email protected]

n Group 5n [email protected] [email protected]


Strategyzer (Osterwalder)

7


ServiceML Editor

n Web-based modelling editorn http://tomcat.thingml.org/backend/poem/repository

n User guiden http://epf.thingml.org/wikis/neffics/practice.business.

service_modelling.base-sintef/guidances/toolmentors/neffics_service_modelling_editor_user_guide_D29F2B87.html

n Currently being extended to support ATONE Method (i.e., the ServiceInnovation practice)n http://epf.thingml.org/wikis/neffics/practice.innovatio

n.service_innovation.base-sintef/guidances/practices/service_innovation_F3FED330.html

8


Manifesto for Agile SoftwareDevelopment

n Individuals and interactions over processes and toolsn Working software over comprehensive documentationn Customer collaboration over contract negotiationn Responding to change over following a plan

9

http://agilemanifesto.org/


Specifying Services using the Serviceoriented architecture ModelingLanguage (SoaML): A baseline forSpecification of Cloud-based Services

Brian Elvesæter1, Arne-Jørgen Berre1 andAndrey Sadovykh2

1 SINTEF ICT, P. O. Box 124 Blindern, N-0314 Oslo, [email protected], [email protected]

2 SOFTEAM, 21 avenue Victor Hugo, 75016 Paris, [email protected]

10


Outline

n Short presentation of the main part of the papern What is SoaML?n Experiences and issuesn Illustrative examplen Two approaches

n Ongoing and future workn A baseline for Specification of Cloud-based Servicesn Towards a Cloud Modeling Language (CloudML)


n Key language constructs

n Consumer

n MessageType

n Participant

n Provider

n ServiceContract

n ServiceInterface

n ServicesArchitecture

What is SoaML?

n Service oriented architectureModeling Language (SoaML)

n Defines language constructsand extensions to UML2 tosupport service concepts(metamodel and UML profile)

n Focuses on basic servicemodelling concepts andstructure.

n A foundation for furtherextensions and integrationwith BPMN, BMM and othermetamodels.

12


SoaML experiences

n Our experiences with SoaMLn Toolingn Methods and practicesn Application in industry projects

n Identified issuesn Inconsistencies in the

specification.n Two (three) main approaches to

service modelling.n Examples illustrating the two

approaches are not consistent.n No clear separation, the two

approaches are somewhatintertwined.

n Tool support lacking or worsewrongly implemented.

n Purpose of our paper

n Clarify the differences andsimilarities between the differentapproaches.

n Describe how to align theapproaches.

n Position SoaML as a baseline forspecification of cloud-basedservices.

n SoaML can be extended withnew modelling constructs andintegrated with other modellinglanguages.


Dealer Network Architecture<<ServicesArchitecture>>

ship:Shipping Requeststatus:Ship Status

purchase:Secure Purchase

shipper

sender

shipper

receiver

sellerbuyer

broker

shipper:Shipper

manufacturer:Manufacturerdealer:Dealer

agent:Escrow Agent

Consolidated and extended example

Services architecture:n High level description of how participants work together

for a purpose by providing and using services expressedas service contracts.

Service contract:n Service specifications that define the roles each

participant plays in the service and the interfaces theyimplement to play that role.

Secure Purchase<<ServiceContract>>

:Escrow Purchase

:Place Order

consumer provider

broker

buyer seller

broker:Agent

seller:Sellerbuyer:Buyer

type

represents

ServicesArchitecture(Collaboration)

Participant type(role type)

CollaborationUse

RoleBinding Role

ServiceContract(Collaboration)

Manufacturer<<Participant>>

<<Service>> Service:OrderTaker

OrderPlacer

OrderTaker

type

Participant(Component)

Servic

(Port)

Service(Port)


Two approaches

15

Place Order<<ServiceContract>>

OrderTaker<<interface, Provider>>

OrderPlacer<<interface, Consumer>>

order()quoteRequest()

orderConfirmation()quote()

provider:OrderTakerconsumer:OrderPlacer

OrderTaker OrderTaker

OrderTaker<<interface, Provider>>

OrderPlacer<<interface, Consumer>>

PlaceOrderInterface<<ServiceInterface>>

~PlaceOrderInterface<<ServiceInterface>>

<<signal>> order(in message : Order)<<signal>> quoteRequest(in message : QuoteRequest)

<<signal>> orderConfirmation(in message : OrderConfirmation)<<signal>> quote(in message : Quote)

consumer:OrderPlacer

provider:OrderTaker

consumer:OrderPlacer

provider:OrderTaker

ConfirmationType<<enumeration>>

CurrencyType<<enumeration>>

OrderConfirmation<<MessageType>>

Quote<<MessageType>>

Order<<MessageType>>

QuoteRequest<<MessageType>>

OutOfStockCancelledShippedConfirmed

USDEUR

shipmentID : stringconfirmationDate : dateconfirmation : ConfirmationTypeproviderOrderID : stringcustomerOrderID : string

currency : CurrencyTypeprice : floatrequest : QuoteRequest

quantity : integerproductID : stringorderDate : datecustomerOrderID : stringcustomerID : string

quantity : integerproductID : stringquoteDate : datecustomerID : string

ServiceContract(Collaboration)

ServiceInterface(Class)

Refinementsor

Views

MessageType(Class)

Refinementsor

Views

Consumer(Interface)

Provider(Interface)

type type

Parameter

type

ICT

T. Chang1-3, A.-J. Berre4, C. Carrez4 and B. Elvesæter4

1 University of Bordeaux I, France 2 Harbin Institute of Technology, China3 University of Stavanger, Norway 4 SINTEF ICT, Norway

I-ESA’12 – March 22nd-23rd – Valencia, Spain

Business-SoaML: ServiceIdentification and Specification

from a Business Perspective

http://neffics.eu/


Presentation outline

n Business-SoaML Motivationn Vision, problem and solutionn Context: NEFFICS projectn VDML and SoaMLn Filling the gap between business and ITn Business-SoaML as a simplified SoaML for business

peoplen Conclusion & Future Work


Motivation: Lack of understandingbetween Business and IT

18

Partnernetwork

Keyactivities

OfferCustomerrelationships

Customersegments

Keyresources

Distrib.channels

Cost structure Revenue stream

n Business models:n Strategy planningn Identify sources of revenuen Identify new business opportunitiesn …

n Business people don’t understandimplementation models & coden How it should be done?

n Realisation by IT:n Detailed models, complex code

n Technical IT people don’t understandbusinessn What we did is what was planned?n What we did generate revenue?n …

Ost

erw

alde

r’s fr

amew

ork


Vision, Problem and Solutionn Business people should be able to communicate IT people:

n The identified services, their specification (business requirements/…)n By using model-driven techniques starting from the business perspective

down to the IT realisationn SoaML was designed to model business and IT as a "service-oriented"

system. However:n Business people use a different jargon and different modelsn Business people may talk about services, not about SOA which is perceived

as more technicaln SoaML is based on UML which is not typically used by business

n But:n SOA provides a good way to harmonise implementation with business reqs.

n We propose Business-SoaML:n Intermediate level that abstracts away technical termsn Linked to the up-coming VDML (Value Delivery Modelling Language; OMG

standard)

19


NEFFICS:Networked Enterprise transFormation andresource management in Future internet enabledInnovation CloudSn Overview:

n STREP FP7-ICT-2009-1.3n 36 months, started Sept. 2010n http://www.neffics.eun SINTEF, Vlastuin, HSJD, Cordys, Induct,

IC Focus, Aalborg University

n Short description:n Provide a cloud-based Software platform with associated

methods and models for Networked Business operations,linked to relevant Innovation processes, for enablingNetworked Enterprises to become Highly Innovative,Flexible and Agile.

n Demonstrated in the following areas:n Virtual extended factory (Vlastuin)n Virtual network of hospitals and companies (Hospital of

Sant Juan de Deu)

20

fines-cluster.eu


NEFFICS approach

21

Virtual Factory Network(Vlastuin)

Use

r vie

wTe

chno

logy

vie

w

Integrated methods, models and tools

Integrated platform

Methodology

Innovation Cloud

Networked businessvalue analysismodels

Networkedinnovation models

Networked processand service models

Business Values,Value Delivery Modeling,Tangibles, Intangibles

Business ModelInnovation,Service/Product/ProcessInnovation

Process ModelingService Modeling,Case Management

Networked BusinessOperations Platform

NetworkedInnovationCommunity Services(Cordys) (Induct)

Liquid Hospital(HSJD)

Our aim is toalign business

and IT

Our aim (inthe paper) is toalign business

and IT


What is VDMLn Value Delivery Modeling Language

n Answer to OMG RFP Value Delivery Metamodel (bmi/09-03-09)n Initial submission May 23 2011, Revised submission May 21 2012

n Goalsn Model value exchanges between business partners & customersn Analysis of value exchanges in an enterprise ecosystemn Analysis of value requirements and sources of value from activitiesn Characterise Capabilities and map them to responsible organizations

n Scope: provide a business design abstraction that supports:n Organization Structuren Value Network Analysisn Value Stream Analysisn Capability Analysis

22

n Business Model Analysisn Risk Analysisn REA (Resource Event Agent) Analysisn e3Value Analysis


VDML: views and examplen 7 views defined n Value Network view

23

Dealer

ShipperManufacturer

PurchaseRequest

Offerings

CompanyXP

Co brandOpportunities

Goods ShippingRequest

Ship Confirm

Goods

Feedback

Shipping MethodSuggestion

Ship Info

StatusEnquire

Feedback

captionTangible deliverablesIntangible deliverablesRoles


What is SoaMLn Service oriented architecture Modeling Language (SoaML)

- Specification for the UML Profile and Metamodel for Services (UPMS)n Adopted by OMG in March 2010

n Goalsn Support for modelling services in UML:

n bi-directional asynchronous services between multiple partiesn Services Architectures where parties provide & use multiple services

n Compatibility with UML, BPDM and BPMNn Top-down, bottom up or meet-in-the-middle modellingn Design by contract or dynamic adaptation of services

n Scopen Extensions to UML2.1 to support the following new modeling

capabilities:n Identifying & specifying servicesn Defining service consumers and providersn Policies for using and providing services.

24


TravelReservation<<ServicesArchitecture>>

tr:TravelReservation

co:CardOperations

cd:ClientDefinition

to:TravelOrder

ti:TravelInformation

visaCenter

partnerAgency

visaAccounter

travelAgencytravelAgency

travelAgency

travelAgency

traveller

traveller

client

r2:VisaPaymentCenterr3:Client

r1:PartnerAgency

r:TravelAgency

SoaML example: ServicesArchitecture& ServiceContract

25

TravelOrder<<ServiceContract>>

travelAgency:TravelOrdertraveller:

Role in the service

TravelOrder<<interface>>

cancelOrder(in order : Order)payOrder(in cardDetails : CardDetails)createOrder(in travel : Travel, in client : Client):Order

<<Participant>>PartnerAgency


VDML (Value Delivery Modelling Language)

buyer(C )

Seller(A)

Resel ler(B)

d1

d3

d4

d2

Comp.

Dept1 Dept2 Dept3

BU

buyer(C )

seller(A)

Reseller(B)

d1 d2Act 1 Act 2 Act 3

d1Act 1 Act 2

Participant

Participates in

Engineerin Team X

Member pof Project P

Employee A √ √

Team T √

Business-SoaML

IdentifyServices

(Services)BPMN

IdentifyProcesses

(Processes)CMMN

IdentifyCases

(Cases)

ITArchitect

BusinessStrategist

BusinessAnalyst

WebServicesWS1 WS2 WS3 WSx WSx WSx

Deploy newservices

Execute /Uses

Execute &uses

IdentifyServices

HasvalueHas

value

Hasvalue

Bridging the business-IT gap

26


VDML (Value Delivery Modelling Language)

buyer(C )

Seller(A)

Resel ler(B)

d1

d3

d4

d2

Comp.

Dept1 Dept2 Dept3

BU

buyer(C )

seller(A)

Reseller(B)

d1 d2Act 1 Act 2 Act 3

d1Act 1 Act 2

Participant

Participates in

Engineerin Team X

Member pof Project P

Employee A √ √

Team T √

Business-SoaML

IdentifyServices

(Services)BPMN

IdentifyProcesses

(Processes)CMMN

IdentifyCases

(Cases)ITArchitect

BusinessStrategist

BusinessAnalyst

WebServicesWS1 WS2 WS3 WSx WSx WSx

Deploy newservices

Execute/Uses

Execute &uses

IdentifyServices

HasvalueHas

value

Hasvalue

27

Bridging the business-IT gapThe paper concentrates onThe paper concentrates on

Business-SoaML, with alink to VDML


Our aims with Business-SoaMLn Reduced complexity

n Straightforward functionalities,n Simple and business friendlyn No unnecessary elements (e.g. service implementation details)

n High Level Abstraction:n Specify how Participants interact with each other through servicesn Minimum amount of information in the models

n Intuitive:n e.g. Service Contract and Services Architecture shall be easy to

differentiate;n Relationship with value modelling:

n Aligned notationsn Relationships will be analysed in more details for future integration.

28


Business-SoaML: simplified metamodel

Property

Port

Interface

ConnectorEnd

Connector

Dependency

CollaborationUse

provided

required

0..*

0..*

capabilities

0..*

needs

0..*

ownedAttribute 0..*

0..* ownedConnector

role 1

end 0..*

end 2..*

type 1

collaborationUse

0..*

roleBinding 0..*

caption

SoaML concept

ServiceChannel

Service

Request

Participant

Provider Consumer

Collaboration

ServiceContract ServicesArchitecture

StructuredClassifier

ownedPort 0..*


SoaML

Business-SoaML: simplified notationServicesArchitecturen How Participants are connected and how they work together

30

dealer: Dealer mfg:Manufacturer

shipper:Shipper

ps:Purchasing

Service

status: ShipStatus ship: Ship

RoleA: buyer RoleB: seller

RoleE: agent

RoleF: fromRoleC: enquire

RoleD: ship info

<<ServicesArchitecture>>Dealer network architecture

Criticisms:n Cluttered diagramn Information overloadn Use of a container for

Services Architecture isuseful only if a higherlevel of architecture isneeded


SoaML Business-SoaMLBusiness-SoaML

Business-SoaML: simplified notationServicesArchitecturen How Participants are connected and how they work together

31

Dealer Manufacturer

Shipper

PurchasingService

Ship Status Ship

buyer seller

agent

fromenquire

Ship info

dealer: Dealer mfg:Manufacturer

shipper:Shipper

ps:Purchasing

Service

status: ShipStatus ship: Ship

RoleA: buyer RoleB: seller

RoleE: agent

RoleF: fromRoleC: enquire

RoleD: ship info

<<ServicesArchitecture>>Dealer network architecture


SoaML

Business-SoaML: simplified notationService Contractn Specify interaction patterns based on services

32

Criticisms:n Roles and Participants

should be differentiatedby shape

n Compound ServiceContracts look likeServicesArchitectureswhile they representdifferent concepts

n Use of the ellipse as acontainer if not optimal

payer:Payer

invoicer:Invoicer

<<ServiceContract>>Invoicing Service

: OrderingService

: InvoicingService

orderer Order processor

payer invoicer

buyer: Buyer seller: Seller

<<ServiceContract>>Purchasing Service

service contractSimple

service contract

service contractCompound

service contract


SoaML Business-SoaMLBusiness-SoaML

Business-SoaML: simplified notationService Contractn Specify interaction patterns based on services

33

payer:Payer

invoicer:Invoicer

<<ServiceContract>>Invoicing Service

invoicer(Invoicer)

payer(Payer

)

Invoicing Service

: OrderingService

: InvoicingService

orderer Order processor

payer invoicer

buyer: Buyer seller: Seller

<<ServiceContract>>Purchasing Service

service contractSimple

service contract

service contractCompound

service contract

-

: OrderingService

: InvoicingService

Buyer Seller

orderer order processor

payer invoicer

Purchasing Service

Buyer Seller

Opened / closedOpened / closedCompound

service contract

AggregatedAggregatedroles

Buyer Seller

+

Purchasing Service

Buyer Seller

AggregatedAggregatedroles


Business-SoaML editor in Oryx


Conclusionn Business-SoaML is a simplified SoaML

n Suitable for businessn Initial link to VDML

n Editorn Current (open-source) editor implemented on Cordys (proprietary)

n We are currently validating the approach with Vlastuinn AGR service

35

Farmer

AccountManager

FDAAgent

FinancialManager

TruckDriver

AccountManager

Farmer 2

LaboratoryEmployee

Laboratorymanager

Manure AccountingServer Cluster

Ministery ofAgriculture

Officer

Ministry ofAgrigulture

ServerCluster

FDAController

AGRServerCluster

Verification and control report

Verification and control report

Manure transport

Manure providerservice

MoneyManureprovidercontract

Manuretransportrequest

conf irmation

Manurerecoverycontract

Moneyinvoice

Verification andcontrol report

Manure transport

Data errorissue

Manureloading

dataData error

Manureloading

data

Dataupdate

Data errorreport

Manureaccount

data Dataupdate

Manuresamplebags

Labresults

Lab results

Manureloading

dataManure

loading dataverif ication

Manure loading data

Manureloading dataverif ication

Lab results Out of delta data report

Manure accounting form

Verificationand control

data

Farmer

AccountManager

FDAAgent

FinancialManager

TruckDriver

AccountManager

Farmer 2

LaboratoryEmployee

Laboratorymanager

Manure AccountingServer Cluster

Ministery ofAgriculture

Officer

Ministry ofAgrigulture

ServerCluster

FDAController

AGRServerCluster




Manureservice

Manuretransport

Manuretransport

Labresults

Labresults

Labresults

Manuresampling

AGRService

AGR API

AGRaccess


Manureaccounting

Dataverification

(Value Network view)VDML

(Value Network view) Business-SoaML

Dealer

ShipperManufacturer

PurchaseRequest

Offerings

CompanyXP

Co brandOpportunities

Goods ShippingRequest

Ship Confirm

Goods

Feedback

Shipping MethodSuggestion

Ship Info

StatusEnquire

Feedback

Dealer Manufacturer

Shipper

PurchasingService

Ship Status Ship

buyer seller

agent

fromenquire

Ship info


Future Work

n Comprehensive study with NEFFICS use cases(Manufacture / Healthcare)n Future improvementsn Feedback on friendliness

n Improve the metamodeln Notably with Operations defined in Interface.

n Provide a mapping from VDML, as well as links betweenVDML and Business-SoaML

n Further Tooling support:n Prototype in Oryx - considered for Cordys etc.

http://bpt.hpi.uni-potsdam.de/Oryx (open-source)

36


Requirements Engineering

37


RE Framework from K. Pohl’s book

38


Goal Modeling – approaches

With input from Prof. Dr. Shihong [email protected]

Florida Atlantic University


Goal Model

n A goal model is a conceptual model that documents goals,their decomposition into sub-goals, and existing goaldependencies

n Common goal modeling language include differentdialects:n AND/OR treesn The Goal-oriented Requirements Language (GRL) [GRL 2009]n i* [Yu 1993]n KAOS [Van Lamsweerde 2009]

FloridaAtlantic

Shihong Huang 40


RE-Tools (with StarUML)n The NFR Framework for non-functional requirements

(NFRs) modelingn The i* Framework for agent-oriented modelingn KAOS for formal goals modelingn Problem Frames for business and system requirements

and specifications modelingn UML for object-oriented modeling

http://www.utdallas.edu/~supakkul/tools/RE-Tools/

FloridaAtlantic

Shihong Huang 41

Telecom and Informatics FloridaAtlantic

Shihong Huang 42


i*(i-Star) Framework

n Comprehensive approach for documenting and analyzinggoals and goal dependencies

n i* is based on the idea that an actor depends on otheractors in order to achieve its goals

n In i*, the actors and their dependencies are documented inthe strategic dependency model

n In addition, the goals, tasks, etc. of each actor aredocumented using the strategic rational model

FloridaAtlantic

Shihong Huang 43


i*(i-Star)

n Based on the modeling language GRLn AND/OR trees for documenting goal decompositionsn GRL provides modeling constructs for quality aspectsn Basic concepts

n Objectsn Dependenciesn Relationships, which is further subdivided into

n Dependenciesn links

FloridaAtlantic

Shihong Huang 44


Notation of the modeling constructsin the i* framework

FloridaAtlantic

Shihong Huang 45


StarUML with RE module

FloridaAtlantic

Shihong Huang 46


RE Modules – Goal modeling

n iTroposn KAOSn System Problem Framen NFR Frameworkn Problem Interdependency Graph

FloridaAtlantic

Shihong Huang 47


KAOS

n KAOS modeling language is part of the KAOS frameworkfor eliciting, specifying, and analyzing goals, requirements,scenarios, and responsibilities assignments

n Framework with six complementary views or sub-modelsn Goal modeln Obstacle modeln Object modeln Agent modeln Operation modeln Behaviour model

n All sub-models are interrelated via traceability links

FloridaAtlantic

Shihong Huang 48


KAOS - Keep All ObjectivesSatisfiedn http://www.info.ucl.ac.be/~avl/ReqEng.html

FloridaAtlantic

Shihong Huang 49


Shihong Huang 50


Shihong Huang 51


Constructs for goal modeling inKAOSn Objects

n Behavioural goaln Softgoaln Agent

n Relationshipsn AND-decompositionn Alternative decompositionn Potential Conflictn Responsibility assignment

FloridaAtlantic

Shihong Huang 52


Basic constructs of the KAOS framework formodeling goals and assigning responsibilitiesfor goals to agents

FloridaAtlantic

Shihong Huang 53


KAOS - Goal

n In KAOS, a goal is either a behavioral goal or a softgoal,and

n Is defined as a prescriptive statement of intent that thesystem should satisfy through the cooperation of itsagents

n Characterize:n Behavioral goalsn Softgoals, andn agents

FloridaAtlantic

Shihong Huang 54


KAOS Object: Behavioral goals

n Behavioral goal: Set of admissible system behaviorsn Can be defined in a clean-cut manner, i.e., one can

verify whether the system satisfies a behavior goal or notn Example: “The train doors shall remain closed while the

train is moving”n Two types of behavior goals

n Achieve goal: the defined property must eventually holdn Maintain goal: the defined property must always hold (possibly

under some condition)

FloridaAtlantic

Shihong Huang 55


KAOS Object: Softgoals

n Document preferences among alternative systembehaviors

n Like in i*, softgoal has no clear cut criterion for satisfactionn Hence, softgoals are expected to be satisfied within

acceptable limits rather than absolutelyn Example: “the system shall minimize the traveling time”

FloridaAtlantic

Shihong Huang 56


KAOS Object: Agent

n While i* focuses primarily on agents within organizationstructures

n Agent in KAOS related to users and components ofsoftware-intensive systems

n An agent is defined as an active system component with aspecific role for satisfying a goal (e.g. user)

n An agent can be a human agent, a device (e.g., a sensoror actuator), or a software component

FloridaAtlantic

Shihong Huang 57


KAOS - Relationships

n AND-decomposition:n Relates a super-goal to a set of sub- goalsn The super-goal is satisfied if all sub-goals are satisfied

n Alternative decomposition (OR-decomposition)n Assignment of multiple AND-decompositions to the super-goaln Each alternative is a set of AND-decompositions (may be only

one)n The super-goal is satisfied if one of the alternatives (one AND-

decomposition assigned to the super-goal) is satisfied


KAOS - Relationships

n Potential Conflictn One goal may prevent satisfying another goaln This link does not correspond to the conflict dependency,

which documents that when one goal is satisfied, the othergoal cannot be satisfied

n Responsibility assignment (relation of goals to agents)n Means that the agent is responsible for satisfying the goaln Only terminal goals (goals that cannot be refined) can be

assigned to an agentn Alternative responsibility assignments can be defined, i.e., a goal

can be related to multiple agents using a responsibilityassignment relationship

FloridaAtlantic

Shihong Huang 59


Modeling goals in KAOS

n The goal (sub-) model documents goals softgoals, andtheir dependencies, i.e.,

n AND-decompositionsn Alternative decompositions, andn Potential conflicts

FloridaAtlantic

Shihong Huang 60


Example of a goal model inKAOS

FloridaAtlantic

Shihong Huang 61

Decomposition of the goal“avoid traffic jams”

Contribute toContribute totwo softgoals

Conflict link

AND-Decomposedinto two goals

OR-Decomposedinto two goals


Modeling goals in KAOS

n Goal sub-modeln Documents goals, softgoals and their dependencies

n Agent sub-modeln Defines agents

n Responsibilitiesn Link goal sub-model with agent sub-model

FloridaAtlantic

Shihong Huang 62


Modeling ResponsibilityAssignments in KAOSn Are used to interrelate goals defined in the goal sub-model

and agents defined in the agent sub-model

FloridaAtlantic

Shihong Huang 63


Example of responsibilityassignment in KAOS

Florida Atlantic University Shihong Huang 64

Agent

Goal

ResponsibilityAssignment

link


Deciding Which Goal Modeling Languageto Use

n Extended AND/OR graphsn Document goals and dependencies, but no agentsn Cannot be used to model actors and relationships between

actorsn i* framework

n Primarily targeted at actors and their goals within organizationand organization structures

n Main focus: the system environmentn Sophisticated modeling language in terms of actors,

dependencies between actors, and rationale structures of theindividual actors

n Requires some training before use

FloridaAtlantic

Shihong Huang 65


Deciding Which Goal Modeling Languageto UseKAOSn Targets on agents that are system users or components of

software systemsn The basic concepts for defining goals in KAOS framework are

very similar to extended AND/OR goal graphsn Support conflicts and softgoalsn Five other supplementary models, also for hardware

components – thus support interrelating goal models with data,functional, and behavior modeles

n Very suitable for embedded systemsn Requires some training before use

FloridaAtlantic

Shihong Huang 66


Hint: Choosing a goalmodeling languagen Use extended AND/OR graphs if your main focus is the

documentation of goals, their decompositions, and theirdependencies

n Use i* models if you aim to document and analyze therelationships between different actors in an organizationusing an agent-oriented modeling paradigm

n Use KAOS models if you aim to document the intendedproperties of the hardware and software components ofa software-intensive paradigm and if you aim to relatethe defined goals with solution-oriented requirementsmodels

FloridaAtlantic

Shihong Huang 67


References

n Klaus Pohl, “Requirements Engineering – Fundamentals,Principles, and Techniques”, Springer 2010

n Axel van Lamsweerde “Requirements Engineering fromSystem Goals to UML Models to Software Specifications”,Wiley 2011

FloridaAtlantic

Shihong Huang 68


KAOS support

n Tool:n http://www.utdallas.edu/~supakkul/tools/RE-Tools/

n Reading:n http://www.info.ucl.ac.be/~avl/ReqEng.html

FloridaAtlantic

Shihong Huang 69


ISO standards, 250xx

70


ISO 25010

71


Targets of Quality Models

72


Quality in Use

73


Product Quality

74


Quality Measures

75


Measurements

76


Tom and Kai Gilb

77


‘Quantifying All QualityRequirements’

www.Gilb.comSee ‘Downloads’

https://www.dropbox.com/sh/w05apx9s1qbfpsz/IkQ78CZLfV


Multiple Required Performance and Cost Attributesare the basis for architecture selection and evaluation

Function

Stakeholder B’sFinancial Budget

Effort

Elapse Time

Stakeholder A’sFinancial Budget

Usability

Reliability

Innovation

Environment

Security

Cost Reduction

Resource Performance

Client Accounts

>>>>

> >>

>>

>>

!

0%

100%

0%

100%

>[Operator][Management]

©[email protected]


Scale and Meter, Past and Goal

81


Structuring concepts

Business Process & Roles Model

Community model

Work analysis Refinement

Context Business Model

1

refines

refined by

in context ofBusiness Model

Context statement

Vision for change

Risk analysis Goal model

Scoping Statement

1

1 1

1

1

1 1 1..*

1

1..*

1

1

1

Business Resource Model

1

1..*

1

*

0..1

1

refines

context for

1

1refined by

BMM

BPMN


BMM – Business Motivation Model(OMG)

2007 standard from OMG, based on input from theBusiness Rules Community

http://www.omg.org/technology/documents/br_pm_spec_catalog.htm

Example of a relevant metamodel, with a domain specific language, andeditor support with EMF/GMF.


What BMM Offers

n Standardizes common Business terms and Businessrelationships

n Provide a open medium for communicating BusinessPlans

n Provides a “bridge” for relating the WHAT and the WHY tothe HOW:n Business Processesn Business Rulesn Organizational Structure


BMM (Metamodel)


BMMoverview

ServicesArchitecture/Community

executed by


BMM modeling


Concrete Syntax

n No mandated syntax.n Which is best?

Textual Syntax

Graphical SyntaxStructured Syntax

EU-Fly is vulnerable todirect competition from low-costairlines on many of its single-sectorroutes.Revenue from businesstravel is critical


Graphical Syntax Option

n Implemented in Eclipse, using GMF (Graphical Modeling Framework)

Concepts, e.g.Influencer

Relationships,e.g. judges


Example

INF5120 ”Modellbasert Systemutvikling” ”Modelbased ...€¦ · Telecom and Informatics 3...

Documents

Transcript of INF5120 ”Modellbasert Systemutvikling” ”Modelbased ...€¦ · Telecom and Informatics 3...