Science and Technology Norwegian University of NTNU Rolv Bræk, March 2006 1 Systems and Service...

Science and TechnologyNorwegian University ofNTNU

Rolv Bræk, March 2006 1

Systems and Service EngineeringDomain Modelling(textbook ch 3 ++)

Rolv Bræk

NTNU

Department of Telematics



The full systems engineering cycle/spiral

Domain

Systemdescriptions

DevelopInstall

SystemManufacture

Domaindescriptions

Model

has needs

quality =

satisfaction of needs



Why make domain models?

1. to understand the (problem) domain

2. to understand the needs and opportunities

3. to improve communication with users, owners and developers

4. to plan better products

5. to facilitate reuse

1. to understand the (problem) domain

2. to understand the needs and opportunities

3. to improve communication with users, owners and developers

4. to plan better products

5. to facilitate reuse

A common “language” for all departments:

• Product planning and marketing

• Development

• Engineering, production, sales

• Customer organizations

A common “language” for all departments:

• Product planning and marketing

• Development

• Engineering, production, sales

• Customer organizations



What are domain models?

Object

models

Property

models Dictionary

Statement

Domain descriptions

• They model a part of reality that systems may serve.

• They are not specific to a system, but rather to a market segment.

• They identify stable domain concepts and processes that need to be supported irrespective of particular system solutions.

• They model a part of reality that systems may serve.

• They are not specific to a system, but rather to a market segment.

• They identify stable domain concepts and processes that need to be supported irrespective of particular system solutions.



How to make domain models

Consider the enterprise - to find the real needs (why) and thereby identify the best system opportunities.

Consider the enterprise - to find the real needs (why) and thereby identify the best system opportunities.

Object

models

Property

models Dictionary

Statement

Domain descriptions

1. Make domain statement; identify: owners, users, subjects, helpers, services, workflows and procedures.

2. Make dictionary (Taxonomy of terms, Ontology).

3. Make object models: passive objects and active objects.

4. Make property models: define the services, workflows, procedures.

1. Make domain statement; identify: owners, users, subjects, helpers, services, workflows and procedures.

2. Make dictionary (Taxonomy of terms, Ontology).

3. Make object models: passive objects and active objects.

4. Make property models: define the services, workflows, procedures.



A-rule: Problem Statement

Make a statement that explains the problem domain. Focus on the purpose, the essential concepts, the procedures and the rules.

e.g.:• The main problem of the domain is to control the access of users to

access zones. Only a user with known identity and correct access right shall be allowed to enter into an access zone. Other users shall be denied access.

• The authentication of a user shall be established by means of a magnetic strip card holding a card code, and a secret Personal Identification Number, PIN, known by the user.

• The authorization is performed on the basis of the user identity, and access rights associated with the user.

• When a user is authenticated and authorized the access zone may be entered through a door.

• ...



A-rule: Dictionary

Make or obtain a dictionary for the problem domain. The dictionary should be kept updated throughout the development.

e.g.:• Access Point A point of access in one direction through a door.• Access Zone A physical zone where users are present, accessible through

doors.• Authentication To establish the identity of a user.• Authorization To establish the right of a user to enter an access zone• Card A personal identification means.• Cardcode A unique identification of a card stored in machine readable form on

the card.• Door A controlled passage from one access zone to another• ...



Make static object models (concept models) of the problem domain using UML diagrams, SOON or similar.

A-rule: Domain Object Models

zone door

Passive objects (subjects)

group

legal user

member of

has access to consist of

1..*1

1..* 1..* 1..*

Authenticator

Authorizer

User

Card

Operator

Door

Active objects



- and emphasizes passive objects (subjects)

The textbook uses SOON

owns

<n>: User

<n>: Card

<m>: Access Point

<k>: Access Zone

may use

may enterEntryControl

<l>: Door

controls

Access control domain

<m>,< n>, <l> = (+)

ExitControl

has



Use UML2.0 Class diagrams in stead

• SOON models part structures

• UML class diagrams model classes/types

owns

<n>: User

<n>: Card

<m>: Access Point

<k>: Access Zone

may use


<l>: Door

controls


<m>,< n>, <l> = (+)

ExitControl

has

AccessZone

AccessPoint

Door Card

User

*

* 0..2 may use 0..1

0..1 owns

*

11 controls

has 1..*

11EntryControl

1ExitControl

may enter



owns

<n>: User

<n>: Card

<m>: Access Point

<k>: Access Zone

may use


<l>: Door

controls


<m>,< n>, <l> = (+)

ExitControl

has

... and UML 2.0 composite classes• Composite Classes in

UML2.0 model part structures

• similar to SOON (and SDL)

az[k]:AccessZone

ap[m]:AccessPoint

u[n]:User

c[n]:Card

d[l]:Door

Access Control Domain



Make domain object model for a Hospital

• Passive objects



Domain Property Models• Non-functional and functional properties.• Functional properties: services; workflows;

procedures• UML 2.0 Collaborations are well suited:

• Role structures – for properties of active objects.

• Collaboration behaviour – for services, workflows and procedures.

Authenticator

Authorizer

User

Door

User Access



Using UML 2.0 collaborations• to model active objects as role structures • to specify behaviour properties using sequence

diagrams, activity diagrams and/or state machines• to define Use Cases in a useful way• to define interfaces behaviour and semantic

interfaces

a:Authenticator

b:Authorizer

u:User

d:Door

User Access

Classifier Role: specify properties of compatible classes



Collaboration diagrams

Session

roleX:TypeX roleY:TypeY

Service

roleA:TypeA

roleC:TypeC

roleB:TypeBsession1:Session

session2: Session

session3: Session

roleX roleY

roleX

roleY roleX

roleY

A collaboration with two roles

A collaboration with three roles and three collaboration uses

This illustrates collaboration (re-)use and composition

Note that TypeA must be compatible with TypeX

Compatibility means that the role behaviours must be contained in the total behaviour of the actor – how is a semantic variation point in UML2



Behaviour can be in three places:• The collaboration itself• The roles• The context (scope) of the collaboration:

Service

roleA:typeA

roleC:typeC

roleB:typeBsession1:Session

session2: Session

session3: Session

roleX roleY

roleX

roleYroleX

roleY

sd

1

3 2

sd

1

3 2



Service User Access

UserAccess example

User Access:– A user enters his

personal code, PIN

– The authenticator checks the card id and the PIN

– The authorizer checks the access right of the user

– If OK the door is opened

– If NOK no action

MSC UserAccess_Granted

User AuthorizerAuthenticator Door

Card id

Enter PIN

Givepin [PIN]Authorize[userid]

Open_LockEnter

Authenticator

Authorizer

User

Door

User Access

Science and Technology Norwegian University of NTNU Rolv Bræk, March 2006 1 Systems and Service...

Documents

Transcript of Science and Technology Norwegian University of NTNU Rolv Bræk, March 2006 1 Systems and Service...