”Modellbasert Systemutvikling” ”Modelbased System ......INF5120 Model based System Development...

INF5120 Model based System Development 24.01.2011

1

Telecom and Informatics 1

INF5120

”Modellbasert Systemutvikling”

”Modelbased System development”

Lecture 4: 06.02.2012 Arne-Jørgen Berre

[email protected] or [email protected]


INF5120 - Lecture plan - 2012

Part I: SSI – Service Innovation and Agile Service/Software Engineering

Part II: SSMDE – Model Driven Engineering

Part III – Model Driven Interoperability and ADM

1: 16/1: Introduction to Model Based System Development (INF5120)

2: 23/1: SIE I: Enterprise Architecture, Role modeling-Collaboration and Value Networks – Verna Allee (VNA)

3: 30/1: SIE II:: Business Process Modeling with BPMN 2.0 and Business Model Innovation - Peter Lindgren (BMI)

4: 6/2: SIE III: AT ONE –User-oriented design – with Use cases and user stories

5: 13/2: SIE IV: Service modeling with SoaML – Service modeling - Design, patterns

6: 20/2: SIE V: Information Modeling with UML and Design with DCI - Design, patterns

7: 27/2: MDE I: Software Process Model Frameworks – Essence/SEMAT, SPEM, EPF and ISO 24744 –Shihong Huang/Brian Elvesæter

8: 5/3: MDE II: Metamodels, Domain specific languages and UML profiles (Franck Fleurey)

9: 12/3: MDE III: Metamodeling, MDLE and DSL Tools (EMF, GMF, ATL, Kermeta)

10: 19/3: MDE IV: Model transformations - MOFScript, QVT DSLs with examples

11: 26/3: MDE V: Internet Service Architectures - with BPM/BPEL and SOA/Cloud transformations

2/4, 9/4: EASTER

12: 16/4: MDE VI: User Interface Modeling – IFML etc. - ESITO

13: 23/4: MDI I: Semantic technologies, Ontologies and Semantic annotations , Rules/SBVR

14: 30/4: MDI II: Model Driven Service Interoperability

15: 7/5: MDI III: ADM and Migration to Cloud computing

16: 13/5: Conclusion and Summary for INF5120 - Preparation of Exam

Exam: Monday June 4th, 2011, 1430-1830 (4 hours)

mailto:[email protected]

mailto:[email protected]


2


INF5120 – Oblig/Exercise plan - 2012

1: 16/1: None

2: 23/1: Guest lecture: Value Networks – Verna Allee (VNA)

3: 30/1: Guest lecture: Business Model Innovation - Peter Lindgren (BMI) – Establish groups

4: 6/2: AT ONE initial exercise – overall approach for Oblig 1 – “myServiceFellow”

5: 13/2: Group presentation



8: 5/3: MDE Tools – introduction – Oblig 2 intro

9: 12/3: MDE Tools II - EMF

10: 19/3: MDE Transformation tools

11: 26/3: MDE V: Internet Service Architectures - with BPM/BPEL and SOA/Cloud transformations

2/4, 9/4: EASTER

12: 16/4: MDE User Interface tools – ESITO o.a.

13: 23/4: Oblig 2 questions

14: 30/4: Oblig 2 delivery

15: 7/5: Oblig 2 summary

16: 13/5: Conclusion and Summary for INF5120 - Preparation of Exam

Exam: Monday June 4th, 2011, 1430-1830 (4 hours)

Telecom and Informatics

Outline

RM-ODP

Service Design, AT ONE

myServiceFellow

BPMN 2.0

Business Model Innovation


3


ISO RM/ODP - ISO/IEC 10746


Understanding Different Viewpoints

Enterprise

Viewpoint

Information

Viewpoint

Computational

Viewpoint

Engineering

Viewpoint

Implementation

Technology

Viewpoint


4


Signposting the way forward

Enterprise

Viewpoint

Implementation

Part 1

Reference

Model


Part 4: Services-Centric View

Enterprise

Viewpoint

Information

Viewpoint

Computational

Viewpoint

Engineering

Viewpoint

Technology

Viewpoint

Implementation

Business

Processes

UML

SoaML

USDL

XML/OWL

Web

.NET

Java

XML


5


Service Innovation



6


Service innovation practices support

neffics.modelbased.net


Service Innovation workflow


7


myServiceFellow

13

http://vimeo.com/34160910


Service-oriented Analysis and

Design

Multi-style

Service-oriented

Architecture

(SOA) [Usländer, 2010]

Business IT-Strategy

Software Architecture

Business Services

View of Thematic Expert

Usage Area Enablers

Generic FI Enablers

View of IT Expert

requirements

capabilities /

service

registries

gap

http://vimeo.com/34160910


8


Mapping of Requirements to

Capabilities


Project Planning

Edit

ion o

f A

rchit

ectu

re D

ocu

men

t

Abstract Design

Concrete Design

Req‘s Analysis

Cap

abil

ity A

nal

ysi

s

Enterprise

Engineering Technology

Information Service

(1)Iterative Design

(2)Incremental

Edition of

Architecture

Viewpoints

SOA Design Process according to

RM-ODP Viewpoints

Milestone ?

Enterprise

Information

Service

Engineering

Technology


9


Coupling the

Viewpoints

SERVUS Design Process based

upon Resource Models

Enterprise

Engineering Technology

Information Service

Project Planning

Edit

ion o

f A

rchit

ectu

re D

ocu

men

t

Abstract Design

Concrete Design

Req‘s Analysis

Cap

abil

ity A

nal

ysi

s

Milestone ?

Enterprise

Information

Service

Engineering

Technology

resource

create get

delete update

representations

Requested/

Offered

Resource


SERVUS Design Methodology [Usländer, 2010]

Use Cases

[Jacobson and Ng, 2005]

Requested

Resources

SERVUS

Geospatial Data/

Services Models

[SOA Reference Model]

Offered

Resources

(1) SERVUS = Design Methodology for

Information Systems

(1) based upon Geospatial Service-

oriented Architectures and the

(2) Modelling of Use Cases and

Capabilities as Resources

(2) Unified Modelling as Resources

(1) Rephrasing of Use Cases

requested resources

(2) Publication of Capabilities

offered resources

Search &

Mapping


10


Steps for Requirements Analysis

1. Semi-formal description of use cases [Cockburn, 2007]

2. Usage of UML to model and document use cases

3. Discussion of the methodology with the users

4. Identification of the resources and their representations

5. Edit the Enterprise Viewpoint


Template of a Use Case Description

……….


11


Formal Modelling of a Use Case with

Resources

read access required

write access

required


Use Case Model Example

(Hydrology)

Requested

resources

(with read

access)

Requested resources

(with write access)


12




13


Backlog metamodel


Backlog metamodel (UC projects)

Scenario areas

Top level use cases

Architecture Analysis – use cases -> enablers

Second level Use cases


14


Backlog metamodel (FI-WARE)

Chapters Enablers Features of enablers

Iterations of enablers


User Story template

I <in the role of XX> needs functionaly <zzz> to achieve

the goal of <YYY>

28


15


COMET Business Modelling

with WesternGeco Survey Booking

Reference Example


Platform specific

model

UMT Config model

Component

implementation

model

Bu

sin

ess

Dom

ain

S

yst

em

Dom

ain

Model world Real world

Concepts& Artifacts

Processes

Actors

Business

model Goal Model

Architecture

model

Requirements model

Use case

Scenario Model

Other requirements

Prototype

Vision

for change

Context

statement

Risk

analysis

Business

Process & Role

Model

WARM

Business

Resource Model

PIM Data

Types

Context Business

model Goal Model

Vision

for change

Context

statement

Risk

analysis

Business

Process & Role

Model

Business

Resource Model

0,1

0,1

System Boundary

*

* *

*

Deployment

User Service

Tier

User Resource

Service Tier LS

Legacy

Business

Service

Tier

Resource

Service

Tier

Presentation Tier

User Dialog Tier

Com

pon

en

t Infra

structu

re

&

Work

flow

En

gin

e (

Micro

work

flow

)

Use

r S

erv

ice

Dom

ain

Bu

siness S

erv

ice

Dom

ain

User

Interface

Tier

RA RA

LA

Workflow Service Domain

Component structure

and internal design

Interface and

interaction

specification

Busines domain to system domain

mapping

•Subsystem grouping and BCE

(Combine Ref Arch)

•BM analysis

Work Element Analysis Model

BCE Model


16


Monitoring

Seismic

Acquis ition

• Sales &

• Planning

• Reporting &

• Monitoring

• Vessel Operation

• Exec. • Op. Mgr

• Vessel Schedule

• Work Order

• Prod. s tatis tics

• Downtime s tat.

• NCR

• Support

• Engineering

Context statement

Business Resource

model

O btain ClubIn fo and deliver to

re gisteringP rocesso r

Registrator Secretariat application ClubRegister

Che ck if C lub ex ists

Club re gistration In form ation

Ask ClubRe giste rto che ck

if C lub alre ady e xists

E xisting ClubIn fo

Ask to e dit and confirm e xisting

ClubIn foE xisting ClubIn fo

E dit and acce pt e xistingclubInfoAsk to re giste r C lub

A dd Club

[C lu b Ex ists]

[C lu b d o no t Ex ists]

Business process model

Component structure model

Iterative &

Incremental

Vision for change

Risk analysis

Applications

Business components

General components

OS

HW

Component Implementation

Model

Business Model

(What and why) Requirements Model

(What)

Architecture Model

(How)

Platform Specific

model

(HowSolution)

Problem domain

Solution domain

BCE Model

Interface & Information

Model

Goal Model

Work Analysis

Refinement

System Boundary

Model

Use case scenario Model

: Secretariat Application

: ClubRegister : Registrator

registerClub

clubExists

registerClub

Other requirements

Prototypes

Arnor

er en kul type

Dette er et

forsøk på

å fylle denne

kommenten

med text

Component interaction model

: Secretariat Application

: ClubRegister : Registrator

registerClub

clubExists

registerClub

Arnor

er en kul type

Dette er et

forsøk på

å fylle denne

kommenten

med text

Platform profile model

O btain ClubIn fo and deliver to

re gisteringP rocesso r

Registrator Secretariat application ClubRegister

Che ck if C lub ex ists

Club re gistration In form ation

Ask ClubRe giste rto che ck

if C lub alre ady e xists

E xisting ClubIn fo

Ask to e dit and confirm e xisting

ClubIn foE xisting ClubIn fo

E dit and acce pt e xistingclubInfoAsk to re giste r C lub

A dd Club

[C lu b Ex ists]

[C lu b d o no t Ex ists]


Business Model

The Business Model is used to express the part played by the Product

(system or component) being developed in the context of the business

that will fund its development (or purchase it) and use it.

The Business Model includes goals, business processes, steps within

business processes, roles and resources. The scope (or domain) of

the model is any part of the world defined as interesting for a

company, organisation or others, and which has some impact on the

required behaviour or other characteristic of the Product.

The business model might be broadly or narrowly scoped, e.g.

describing the entire business of a company or describing the

immediate environment and context of a Product under consideration.


17


Business Metamodel

Structuring Concepts Basic Business modelling concepts

Work Analysis Refinement ConceptsProfiling model


Structuring concepts

Business Process & Roles Model

Community model

Work analysis Refinement

Context Business Model

1

refines

refined by

in context of

Business 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


18


Model structure for the Business model


Modelling concepts

Artifact Resource Actor Resource

1..* identified byresults in

Goal

Resource in Role

Business Rule

fulfilled by

constrained by

has1..* executes

1..*

1..*

*

objective of

subgoals

Community

Resource

*

has resources

constrained by1..*

*

resource in

1..*

0..1

*

*

*

fulfils

constrains

modelled as

represents Business Process

Step

Enabling behaviour

1..*behaviour of

generates

modelled as

Enabled by

met by

1..*

1..* 1..*

to meet

Role

constrains

1..*

*

*

*

actor for

constrains

1

1..*

1..*

1..*

*

*

performed by

identifier for

constrained by

Event

Behavioural Policy

0..1

affected by

model of

constrained by1..*

1..*

*

0..1*

*

*

affectsis generated by

constrains

Business Message

Resource as Artefact *

*

1..*

* *

1..*1..*

*

1

*

1..*

concerns

artifact in

result of

recipient

issued to

represented information flow

subject for

artifact

resource sender

received by


19


UML profile for business modelling


Survey Booking Reference Example

The survey-booking tool will help to administer the utilization of our vessels. It will mainly benefit three user groups; Sales, operations and marine management.

Sales will use it to book a survey or tender onto a vessel. The survey-booking tool will give an overview over the current workload and also which vessel qualifies for the job.

Sales will make booking suggestions to management, which then need to be confirmed by the global marine management.

For operations the booking tool should work as a planning aid. It will automatically warn about changes and it will have detailed job information available on-line.

Marine management will be able to use the booking tool to assess the current resource usage, confirm survey bookings and to reschedule jobs.


20


High-Level System Boundary

Sales

Marine Management

Support

Operations

Administrator

Introspection

<<description>>

The sales department is responsible for costing a

survey and to initially book it on a vessel or region in

case of a lead. Sales account managers, sales

supervisors and sales managers are members of this

group.

<<description>>

* Marine management will be responsible to

confirm the booking of surveys onto a vessel.

* Regional marine management, business

managers and global marine management are part

of this group.

<<description>>

A support role is needed to promote the

input of competitor information. This role

needs to access the system to obtain status

on what is being added and by who.

<<description>>

* Operations will be responsible for the survey

preparation and execution.

* Operations managers, vessel supervisors and

party chiefs are the main members of this group.

* In addition there are several service groups

which will also be included in this group:

* Operational support (Technical services),

personnel management, accounting.

<<description>>

A person with administrator rights is needed to keep

the system updated with regards to user names and

rights and vessel names.

<<description>>

* Introspection has two tasks. For the booking

and booking validation process it shall inform

about vessel configurations, which it can get

from the vessel descriptions.

* In addition the actual progress is extracted

from Introspection to keep the schedule up to

date.

SurveyBooking


Subsystem Grouping BookingEditor

1. Book tender/lead

2. Update booking status

7a. View local schedule

15. Import from global schedule

5. Reschedule job

16. Export to global schedule

BookingViewer

7b. View global schedule

SubscriptionEditor

12. Subscribe to notification

1. Book tender/lead







Sales

Marine Management

Operations

GlobalScheduleService

17. Synchronize and save schedule

18. Assemble and deliver schedule

10. Add/remove users & rights

11. Add/remove vessels

SubscriptionService

19. Check for subscriptions & notify

20. Update list of available subscriptions

21. Save/remove subscriptions








<<include>>

5. Reschedule job

<<include>>

<<include>>

<<include>>

ActivityInfo

Administrator

Introspection

<<include>>

SubscriptionInfo


21


Component Structure – Bus Pattern

Component Infrastructure

BookingEditor BookingViewer

BookingService

ActivityInfo

SubscriptionService

SubscriptionEditor

SubscriptionInfo


Scoping statements

The context statement, which defines the scope and

positions this business model in its context.

Vision for change, which describes what to improve, the

motivation (i.e. what is wrong with the current situation), a

description or indication of what the improvements might

be and a gap analysis.

Risk analysis, which identifies the business and technical

risks related to a development project for the proposed

Product.

../CombineWeb0101/dev_proc_web/activities/bm/context_statement.htm

../CombineWeb0101/dev_proc_web/activities/bm/vision.htm

../CombineWeb0101/dev_proc_web/activities/bm/risk.htm


22


Context statement

Methods and Techniques The first step in developing any business model is to identify and

record the names of all people who will have an interest in having the Product developed or in its use, the business stakeholders, together with the nature of their interest.

The following are examples of business stakeholders who should be involved:

people who will authorise funding for development of the Product;

people who are responsible for design and maintenance of the business processes to be supported by the Product;

people who will use the Product;

people who will be responsible for the acceptance of the Product;

people who will be responsible for managing operation of the Product.


Roles – Organisation and Process roles

Sales Support Introspection Operations Maritime Manager

Administrator ClientTechnical Manager

System Operator Reviewer

QC-RepTechnical Support

Operation ManagementData Processing Legal

Marketing Corporate ManagerOil Company

Operation Manager

SecretarySales Manager


23


Scope and stakeholders <<summary>>

* Client contacts

* Marketing

* Global fleet plan

Operation Management

Technical Support

<<summary>>

* Liase with client

* Coordinate review review

* Compile tender

* Monitor vesel availability

* Monitor competitor activity

<<summary>>

* Review work specifications

* Propose technical solutions

<<summary>>

* Review operational risks

<<summary>>

* Liase with sales

* Issues tender

* Issue award/loss

Marine acquisition

<<summary>>

* Review contract

* Assess risk

* Insurance

Maritime Manager

Oil CompanyCorporate Manager

LegalData Processing

<<summary>>

* Monitor marine activity

* OBP proposals

AccountManager

Marketing

<<summary>>

* Optimize revenue

* Position vessels

* Upgrade vessels

* Report

<<summary>>

* Marketing

<<summary>>

Produce a

timeliy, quality

image service to

help clients

find, produce

and manage oil

assets.


Tender Bid

Context

Diagram


24


Vision for change

The vision for change document is short and describes

what the Product will be and why it is needed. It will

consist of some or all of the following elements:

General business/product vision and goals, including background

explaining why the Product is needed;

Business opportunities and business benefits;

Product description and technical business vision – how the

Product might be deployed and used;

Presentation material summarising the above.


Vision for change (1/2)

Beginning 2000 it was decided to phase out and replace the suite of business support tools used in the Tender bidding process in the Marine Acquisition Business segment. These tools were based on Excel technology and did not support the needs in a distributed 7by24 organization. Also after 10 years of evolution, pushing spreadsheet functionality beyond its limits, these tools were hard to maintain.

The decision was to reengineer this tool-suite based on the Introspection business tool platform, which was based on Web and Java technology.

The first priority was to look at “The Survey Booking Tool” and “The Survey Costing Tool”. The Survey Booking tool will help to administer the utilization of the seismic vessels and will be used to book a survey or tender onto a vessel. It will give an overview over the current workload and also which vessel qualifies for the job. The Survey Costing tool is used to calculate the cost and revenue of a potential survey.


25


Vision for change (2/2)

The survey-booking tool is a web-based and highly

automated tool to support the process around booking of

vessel time for potential surveys.

Its main task will be:

Schedule leads and surveys

Send automatic warnings on changes and conflicts

Inform about current resource usage and potential backlog


Goal Model

The goal model describes a loose hierarchy of goals of the business within the particular area of concern, starting with the goals of a Business Stakeholder in developing or buying the Product, and leading to the detailed business goals met by the Product or its users when using it.

The Goal Model is discovered by a process of workshops and interviews involving all stakeholders (as identified in development of the Context Statement).

Goals must be achievable, preferably measurable, and not self-evident, and should have clear and detailed implications. It should be reasonable (but not necessarily appropriate, and almost certainly not correct) to assert an alternative. The implications should be expressible in terms of a set of sub-goals or enabling processes.

../CombineWeb0101/dev_proc_web/activities/bm/context_statement.htm


26


Goal Model

Make a profitable bid

Optimize fleet utilizationSound cost estimates Proper technical assesmentProper legal assesment

Easy access to historical information Updated cost-models Updated own schedule Updated competitor schedule


Business Resource Model

The Business Resource Model is an information model that identifies

and defines the main things (and concepts) of the domain that are

relevant to the Product.

The Business Resource Model is generally prepared at the same time

as the associated Business Process & Roles model, and methods and

techniques used are similar, i.e. activities that include brain-storming

sessions, structured workshops, interviews and feed-back sessions,

and detailed modelling using a UML tool.

Object flows in the activity diagrams are candidates for business

resources.

../CombineWeb0101/dev_proc_web/activities/bm/bus_process.htm


27


Business Resources

Crew

Tender/Lead

LocalSchedule GlobalSchedule

Company

Vessel

Survey Phase

<<owns>>

Schedule

Booking

summary : undefined

start : undefined

end : undefined

summary : undefined

start : undefined

end : undefined

<<located in>>

Configuration

SWO

1

1

1

11

*

<<shall use>>

Client

corp_code : undefined

1

*

1

1

corp_code : undefined

*

CountryJob

1

1

*

<<located in>>

*

1

*

Area/region

WesternGeco

1

1

*

*

*

1

*

*

Competitor

Capacity

1*


Business Process &

Role Model

Purpose

The objective of the Business Process Model is to identify and

detail all the business processes supported by the Product to the

extent necessary to detail the roles of the Product (and its

components, i.e. Application Components, Business Service

Components and Tool Components).

Methods and Techniques

The Business Process Model is derived through a set of activities

that encompass brain-storming sessions, structured workshops,

interviews and feed-back sessions, and detailed modelling using a

UML tool.


28


Work Element Analysis

(WARM)

In WARM refinement of the Business Process model, the kinds of step performed by resources in the model are further categorised as follows:

A Human Step is a step performed by a human with no involvement of the Product being modelled.

A Tool Step is a step performed by a human user interacting with a tool that is part of the Product. The human user will use some form of interactive device (e.g. a GUI) to interact with the Product. A Tool Step is a candidate for realisation by a Tool Component.

An Immediate Step is a step that is required to complete as soon as possible, and whose intermediate states are of no concern to the business. It is performed autonomously, with no intervention from a human. An Immediate Step may be mapped to an Operation on a Business Service Component (Process) in the Architecture Model.


Tender Bid Process Overview

Receive ITT & Prepare for bidding

Make Tender

Submit Tender

[continue]

[continue]

[stop]

[stop]


29


Receive ITT & Prepare for bidding


Make

Tender


30


Submit Tender


Process and goal structure

Tender Bid

Survey costing Tender compilation

Plan

Win profitable bidsSound cost estimates

ITT

Tender

Sales

Oil Company

<<achieves>><<achieves>>


31


COMET Requirements Modelling

with WesternGeco Survey Booking

Reference Example


Platform specific

model

UMT Config model

Component

implementation

model

Bu

sin

ess

Dom

ain

S

yst

em

Dom

ain

Model world Real world

Concepts& Artifacts

Processes

Actors

Business

model Goal Model

Architecture

model

Requirements model

Use case

Scenario Model

Other requirements

Prototype

Vision

for change

Context

statement

Risk

analysis

Business

Process & Role

Model

WARM

Business

Resource Model

PIM Data

Types

Context Business

model Goal Model

Vision

for change

Context

statement

Risk

analysis

Business

Process & Role

Model

Business

Resource Model

0,1

0,1

System Boundary

*

* *

*

Deployment

User Service

Tier

User Resource

Service Tier LS

Legacy

Business

Service

Tier

Resource

Service

Tier

Presentation Tier

User Dialog Tier

Com

pon

en

t Infra

structu

re

&

Work

flow

En

gin

e (

Micro

work

flow

)

Use

r S

erv

ice

Dom

ain

Bu

siness S

erv

ice

Dom

ain

User

Interface

Tier

RA RA

LA

Workflow Service Domain

Component structure

and internal design

Interface and

interaction

specification

Busines domain to system domain

mapping

•Subsystem grouping and BCE

(Combine Ref Arch)

•BM analysis

Work Element Analysis Model

BCE Model


32


Use Case Model

The Use Case Model describes the system in terms of

Actors

use cases

scenario descriptions

It is defined a use case template to be used as a vehicle for

developing the use case model.

Non functional requirements are part of the use case model as these

kinds of requirements are associated with use cases according to the

use case template.

General non functional requirements that applies for the whole system

are associated with the system boundary which is also included in the

use case model.


Purpose of Use Case Model

Capture system requirements

Specify system behavior as “Use Cases”

Set the system boundary

Specify system environment as “Actors”

Describe interactions between System and Actors

Drive system development process

A Use Case specifies a sequence of actions, including

variants, that the system can perform and that yields an

observable result of value to a particular actor.


33


A Use Case is

User visible

User-meaningful

Easy for a user to confirm (or change)

Precise enough as specification


System Boundary

Goals Identify and describe system boundaries, main services and

actors.

Assure a common understanding of the system and its purpose.

Identify interactions between the system and its environment.

Deliverables A high-level UML Use case diagram showing the system, the

actors and the actors responsibilities.

A detailed UML Use case diagram showing the system boundary, the actors and their main use cases.

Each use case should be numbered for later reference.

General extra requirements that applies for the complete system are associated with the System Boundary


34


Survey Booking Example (1/2)

Sales

Marine Management

Support

Operations

Administrator

Introspection

<<description>>





group.

<<description>>





of this group.

<<description>>





<<description>>









<<description>>




<<description>>







date.

SurveyBooking


Survey Booking Example (2/2) SurveyBooking

1. Book tender/lead

2. Update booking status12. Subscribe to notification

9. Notify

3. Ask for confirmation

5. Reschedule job

4. Confirm job



13. View market-share and forecast reports

14. View competitor input report(s)

8. Automated schedule updates

<<include>>

<<include>>

<<include>>

<<include>>

<<include>>

6. Update work-order (SWO)

7. View schedule

<<include>>

Support

9. Notify


11. Add/remove vessels14. View competitor input report(s)

1. Book tender/lead


Sales3. Ask for confirmation

5. Reschedule job


7. View schedule

<<include>>

<<include>>

<<include>>

<<include>>

Operations

Marine Management

Introspection


Administrator

4. Confirm job



<<include>>

<<include>>


35


System Boundary:

Methods and techniques (1/2)

Information gathering

Sources

Domain model

Users and domain experts

Users playing the roles denoted by identified actors

Existing system/competing system


System Boundary:

Methods and techniques (2/2)

Identify the system boundary

What is Inside the system: Use case(s) (this is what to create)

What is outside the system: Actors (this is what to interface with)


36


Identify actors

Answer the following questions:

Who uses the system?

Who maintains the system?

What other systems use this system?

Who gets information from the system?

Who provides information to the system?

Does anything happen automatically at preset times?

Who starts and shut down the system?

Examples: persons/roles, software systems, things/objects

(hardware) networks, etc.

Describe the actors responsibilities (short)


Identify use cases

Go through the list of actors and identify what services

they need to fulfil their obligations

Answer the following Questions

What services will the actor want to get from the system?

Which events will the actor initiate and which events will the actor

be interested in?

Which events/notifications occur? (the notifications reaching the

actor independent of his interest (e.g error notifications))


37


Use case Scenario Model

Description

The Use Case Scenario Model digs into the identified use cases

and describes these in detail.

A use case template is used as a vehicle for this detailing.

Goal

Capture and understand the requirements.

Deliverables

Detailed UML use case diagram and descriptions in accordance to

Use case template

Activities

Fill in Use Case template


Use case template Use case

<number>

Use case <name>

Each use case is identified for later reference.

Priority Priority with respect to implementation, marked 1 – 10.

Goal Description of the goal(s) for the use case, derived from the Goal Model in the Business Model.

Actors Description of the roles involved in the use case and their responsibilities.

Pre-conditions Description of the pre-conditions for the use case.

Façade Description of methods/operations that the system should provide to realize the use case.

Quality

requirements

Description of extra requirements for this use case. Issues such as uptime, availability, security,

performance, etc. can be recorded here.

Scenario Description of the use case scenarios. This includes the primary scenario and related secondary

scenarios.

Description Step Action

1 Step 1 description.

2 Step 2 description.

n Step n description.

Post-

conditions

Description of the post-conditions for the use case.


38


Quality / Non-functional requirements

Non functional requirements

Description of non functional requirements for this use case

Consider:

Performance

Uptime

Availability

Security

Scalability

Distribution

Reliability

and more ...


RA Analysis

Description

The Reference architecture analysis is the first step in modeling the architecture, representing an intermediate step between Business Domain Models and the architecture design.

The Reference Architecture Analysis is developed using a use case driven approach and provides the basis for the initial development of the Architecture Model.

Goal

The Reference Architecture Analysis should provide the link between analysis and design, in particular the link between the Use Case Model and the Architecture Model.

Deliverables

Detailed use case diagram with subsystem grouping.

Updated use case descriptions following the use case template.

First version of the Component Structure using the bus architecture pattern (Object Management Architecture pattern).


39


Survey Booking Example BookingEditor

1. Book tender/lead




5. Reschedule job


BookingViewer


SubscriptionEditor


1. Book tender/lead







Sales

Marine Management

Operations






SubscriptionService











<<include>>

5. Reschedule job

<<include>>

<<include>>

<<include>>

ActivityInfo

Administrator

Introspection

<<include>>

SubscriptionInfo


RA Analysis: Methods and

techniques (1/2)

Recall the Reference Architecture with associated tiers and component types.

Analyse the System Boundary part of the Use Case Model with regards to the Reference Architecture. The System Boundary correspond to the boundaries of the component of concern for the actual project, typically an Application Component.

After the identification of this "main" component the next step is to analyze the System Boundary Model with respect to its set of use cases and actors.

Divide the System Boundary Model into a set of subsystems. Each subsystem will cover a collection of the System Boundary use cases.

the subsystems are non-exclusive, implying that a use case might be part of more than one subsystem. The result of this task is a functional decomposition of the main component, with reiterated versions of the use cases.

_web/archs_web/reference_architecture.htm

_web/dev_proc_web/activities/rm/requirements.htm

_web/dev_proc_web/activities/rm/requirements.htm


40


RA Analysis: Methods and

techniques (2/2)

The actors are important when it comes to obtaining the most

appropriate decomposition as they group related use cases.

The subsystem grouping are related to the actors and the subsystem

design should strive to have as few relationships between actors and

subsystems as possible.

Related use cases and especially use cases that typically are

executed in sequence should be provided by one subsystem.

The subsystems identified typically reflects

Tool Components;

Business Service Components; and

Resource Service Components


Prototype

Goals

Reduce technical risk

Reduce the possibility of user dissatisfaction

Deliverables

Prototype

Activities

Identify technical uncertainties

Develop UI, get feedback from users

Test the risky technical solutions

Start prototyping early

Useful for the common understanding

Best way of communicating with end user?

Useful for identifying more user requirements


41


WesternGeco Survey Booking

Reference Example


Survey Booking Reference Example

The survey-booking tool will help to administer the utilization of our vessels. It will mainly benefit three user groups; Sales, operations and marine management.

Sales will use it to book a survey or tender onto a vessel. The survey-booking tool will give an overview over the current workload and also which vessel qualifies for the job.

Sales will make booking suggestions to management, which then need to be confirmed by the global marine management.

For operations the booking tool should work as a planning aid. It will automatically warn about changes and it will have detailed job information available on-line.

Marine management will be able to use the booking tool to assess the current resource usage, confirm survey bookings and to reschedule jobs.


42


High-Level System Boundary

Sales

Marine Management

Support

Operations

Administrator

Introspection

<<description>>





group.

<<description>>





of this group.

<<description>>





<<description>>









<<description>>




<<description>>







date.

SurveyBooking


Definition of actors

Sales

The sales department is responsible for costing a survey and to initially book it on a vessel or region in case of a lead. Sales account managers, sales supervisors and sales managers are members of this group.

Operations

Operations will be responsible for the survey preparation and execution. Operations managers, vessel supervisors and party chiefs are the main members of this group.

Marine management

Marine management will be responsible to confirm the booking of surveys onto a vessel. Regional marine management, business managers and global marine management are part of this group.

Introspection

Introspection has two tasks. For the booking and booking validation process it shall inform about vessel configurations, which it can get from the vessel descriptions.


43


Detailed System Boundary SurveyBooking

1. Book tender/lead

2. Update booking status12. Subscribe to notification

9. Notify

3. Ask for confirmation

5. Reschedule job

4. Confirm job




14. View competitor input report(s)


<<include>>

<<include>>

<<include>>

<<include>>

<<include>>


7. View schedule

<<include>>

Support

9. Notify


11. Add/remove vessels14. View competitor input report(s)

1. Book tender/lead


Sales3. Ask for confirmation

5. Reschedule job


7. View schedule

<<include>>

<<include>>

<<include>>

<<include>>

Operations

Marine Management

Introspection


Administrator

4. Confirm job



<<include>>

<<include>>


Subsystem Grouping BookingEditor

1. Book tender/lead




5. Reschedule job


BookingViewer


SubscriptionEditor


1. Book tender/lead







Sales

Marine Management

Operations






SubscriptionService











<<include>>

5. Reschedule job

<<include>>

<<include>>

<<include>>

ActivityInfo

Administrator

Introspection

<<include>>

SubscriptionInfo


44


Definition of subsystems

Booking Editor

The Booking-Editor is a tool-Component and is used by the sales community. This component contains most of the use-cases for sales and supports the need to run offline.

Booking Viewer

The Booking-Viewer is a tool-component used by all actors.

Subscription Editor

The Subscription-Editor is a tool-component used by all actors. This component is a web-based client that gives the possibility to monitor (via email) different business-events (state-changes) in the booking schedule.

Global Schedule Service

The Global-schedule-service is a business-service-component that serves the Booking-Editor- and the Booking-Viewer tool-components.

Subscription Service

The Subscription-service is a business-service component that implements the server-side functionality of the Subscription-editor.


Booking Editor Component

BookingEditor

1. Book tender/lead




5. Reschedule job

Sales

Introspection

GlobalScheduleService16. Export to global schedule


45


UC

1:

Bo

ok t

en

der/

lead

Pri

mary

scen

ari

o


UC

1:

Bo

ok t

en

der/

lead

Alt

ern

ati

ve s

cen

ari

o


46


Global Schedule Service Component




BookingEditor

ActivityInfoBookingViewer



Administrator

SubscriptionService


UC

17

: S

yn

ch

ron

ize

an

d s

ave

sc

hed

ule

Pri

ma

ry s

ce

nari

o


47


Component Structure – Bus Pattern

Component Infrastructure

BookingEditor BookingViewer

BookingService

ActivityInfo

SubscriptionService

SubscriptionEditor

SubscriptionInfo


Individual exercise – until February 13th

Download myServiceFellow on a SmartPhone, iPhone or

Android (from the respective AppStore).

Identifiy and evaluate touchpoints related to service

interaction points you know about in the context of

University of Oslo and Institute for Informatics

Think both about touchpoints that can be incrementally

improved and radically improved (i.e. new

apps/applications etc.)

Document your touchpoint evaluations using the app

myServiceFellow

94


48


Next Lecture – February 13th, 2012

AT ONE continued …

Service Design, Service Innovation and User Experiences

Service Modeling

Oblig 1 – Touchpoints through myServiceFellow

”Modellbasert Systemutvikling” ”Modelbased System ......INF5120 Model based System Development...

Documents

Transcript of ”Modellbasert Systemutvikling” ”Modelbased System ......INF5120 Model based System Development...