goal, role, and domain modelling as the front end for designing distributed systems dr kuldar...

40
Goal, role, and domain modelling as the front end for designing distributed systems Dr Kuldar Taveter, The University of Melbourne

Upload: lauren-griffin

Post on 27-Dec-2015

216 views

Category:

Documents


0 download

TRANSCRIPT

Goal, role, and domain modelling as the front end for designing distributed systems

Dr Kuldar Taveter,

The University of Melbourne

Brave, New World

Many computing nodes Peer-to-peer interactions Openness Change Uncertainty Unpredictability

Socio-technical system

A system that includes hardware and software and people

A system that contains both a social aspect, which may be a subsystem, and a technical aspect

The forthcoming book

‘The Art of Agent-Oriented Modelling’ by Leon Sterling and Kuldar Taveter

To be published in the second half of 2008 by MIT Press

The conceptual space

Motivation layer

System design layer

Deployment layer

DE

SIG

NIM

PLE

ME

NT

AT

ION

Motivation layer

What is a goal?

A particular state of affairs intended Dream with a deadline

Two kinds of goals

Functional goal: a goal that captures one or more desired scenarios. Example: listen to the seminar talk, forgive each other.

Quality goal: quality requirement of the achievement of the functional goal. Example: listen to the seminar talk attentively, forgive each other seventy times seven times.

What is a role?

Some capacity or position within the system to facilitate the achievement of its goal

What is a social policy?

A constraint on the achievement of a goal within an organization

Examples: tipping, bringing flowers to a wedding ceremony, handling business cards with two hands

System design layer

Deployment layer

Relationships between the concepts

Types of models at different layers

Motivation layer: goal models, role and organisation models, domain models

System design layer: agent and acquaintance models, interaction models, scenarios, behaviour models, service models

Deployment layer: agent interface and interaction specifications, data models, agent behaviour specifications, service specifications

Case studies

Conference management system Air traffic control Tamagotchis Smart home B2B e-commerce Manufacturing

The case study of a conference management system

Paper submission Reviewing Reminders Notifications Submission of camera-ready versions Printing

The goal model for a conference management system

The goal model for selecting reviews

The role model for AuthorRole name Author

Description The role of writing and submitting a paper.

Responsibilities Send his/ her paper for the conference to the PC chair. Receive the confirmation of paper submission. Receive the submission number. Receive the acceptance/ rejection decision and the reviews of the paper. Receive a request from the PC chair to submit the final version of the accepted paper. Send the final version of the accepted paper to the PC chair.

Constraints The paper must be submitted before the submission deadline. The final version of the accepted paper must be submitted before the submission deadline for camera-ready papers.

The role model for PC ChairRole name PC Chair

Description The PC Chair manages the process of determining the technical program for the conference.

Responsibilities Invite PC members.Receive confirmations of acceptance from PC members.Register PC members.Advertise the conference.Decide submission deadlines.Decide submission format.Receive the papers for the conference.- Store the papers.- Assign submission numbers to the papers.- Confirm paper submissions with the authors.Interact with PC members to receive their reviewing preferences.Assign the papers to PC members for reviewing.Re-distribute the papers rejected for review.Receive the reviews done by PC members.Negotiate with PC members about borderline or conflicting papers.Make acceptance/rejection decisions on the papers.Notify the authors of the acceptance/rejection decisions.Send the reviews to the authors.Request and receive final versions of the accepted papers.Request the publisher to print the final versions of the accepted papers as the proceedings of the

conference.Submit the final proceedings to the publisher according to an agreed deadline.

Constraints Each paper must be distributed to at least three PC members for reviewing.There is a limit in the number of papers that a PC chair can review.A PC member cannot review his/her own paper.A PC member cannot review a paper with which he/she has a conflict of interest.The authors must be notified in a timely manner whether their paper has been accepted or rejected.The submissions of final versions of the accepted papers to the publisher must be complete, with all

the accepted papers included.

The organisation model for a conference management system

The interaction frame diagram for roles

Domain model

Domain model represents the knowledge within the system that the system is supposed to handle.

A domain model may represent the environment(s) in which the system is to be situated and the resources provided by the environment(s).

The domain model for a conference management system

Quality

Standard of excellence (quality sign) Being fit for purpose. Examples: quality

standards and McDonald’s hamburgers. Quality as an attribute Speed, reliability, scalability,

maintainability, but also having fun, being secure, etc.

Measurable or not?

Some quality goals are quantifiable. For example: performance targets or system availability.

Qualitative descriptions are often more intuitive for stakeholders. For example: system being secure, game being fun, forgiving seventy times seven times.

Qualitative analysis

Achievement of quality goals depends on the context.

Analysis at the motivation layer Analysis of how quality goals affect

design decisions

The goal model for the allocation of airport resources

Allocate resources

Allocate ATC resources

Allocateairline / GH resources

Allocate airport

resources

Passenger

Local ATC Airport Airline / GH

Maximal airport efficiency

Minimalenvironmental

nuisance

Maximalsafety

The goal model for local ATC

Safeallocation

LocalATC

AllocateATC resources

Receiveflight plan

Insert the flight into arrival sequence

Timelyreceiving

Airline /Ground Handler

Introduce the flight into pre-departure

sequence

Determine taxi-in route

Optimal take-off sequence and

departure flow

Minimalenvironmental

nuisance

Maximal runway throughput

Minimal time on the ground

Optimal taxi-in route

Adherence tothe original slot

Refine pre-departure sequence

Calculatetaxi-out time

Calculate taxi-in time

Punctualityof flights

Maximalsafety

Maximal airport efficiency

Airline /Ground Handler

Airport

Update flight plan

data and status

From requirements analysis to designLocalATC

R3

Process arrival

Inform airline and airport

Airline /GH

R4

Refine flight servicing plans

inform(isFIR(FlightPlan))

R6

<<exogeneous>>AircraftIsInFIR

FlightPlan

Update ELDT, EIBT and TOBT

inform(isFinal(FlightPlan))

R7

Record ALDT, update EIBT, TOBT

and TTOT

<<exogeneous>>AircraftIsLanded

FlightPlan

inform(isLanded

(FlightPlan))

Airport

inform(isFIR(FlightPlan))

R5

Refine gate/stand allocation

R1

Update ELDT, EIBT and TOBT

Update ELDT, EIBT and TOBT

<<timeEvent>>inbound.LandingTime – t

FlightPlan

Inform airline

Inform airline

R8<<exogeneous>>AircraftIsInBlock

FlightPlan Record AIBT, update TOBT and

TTOT

Inform airline and airport

inform(isInBlock

(FlightPlan))

R10

Record AGHT, update TOBT and TTOT

<<exogeneous>>StartOfGroundHandling

FlightPlan

R9inform

(isInBlock(FlightPlan))

Inform ATCinform

(isAirborne(FlightPlan))

Insert the flight into arrival sequence

Determine taxi-in route

Calculate taxi-in time

Refine de-icing plan

Refinetowing plan

Refinefuelling plan

Refinecatering plan

<<exogeneous>>AircraftIsAirborne

FlightPlan

inform(isAirborne

(FlightPlan))R2

Allocategate/stand

Simulation

Conclusions

Clear diagrams The models facilitate communication

between software engineers and stakeholders & domain experts.

The models can be straightforwardly turned to various design models and prototype applications.

The models are ontologically founded.

The case study of Tamagotchis

The goal model for a system of humans and Tamagotchis

The motivational scenario of playing with a Tamagotchi

Scenario name Playing with the Tamagotchi Scenario description The owner has to take care of his/her digital pet – Tamagotchi. This

involves the following activities: a) feeding the Tamagotchi; b) curing the Tamagotchi if it becomes sick; c) cleaning the Tamagotchi’s environment if it produces

excrement; d) socializing the Tamagotchi by introducing it to other

Tamagotchis; e) entertaining the Tamagotchi by, for example, playing games

with it and visiting with it Tamagotchi Town; f) disciplining the Tamagotchi if it is naughty.

Quality description Playing with the Tamagotchi should be fun for the owner. The Tamagotchi should have an attractive and easy-to-operate user interface. If the Tamagotchi is not well taken care of, it would die.

The role model for MyTamagotchiRole name MyTamagotchi

Description The role of my digital pet.

Responsibilities

Grow from baby to child to teenager to adult.Express hunger.Become sick.Produce excrement.Express loneliness.Misbehave occasionally:

-express hunger when not hungry;-refuse food when hungry;-present a friend with an inappropriate gift.

Visit the friend.Give the friend a present.Play with the friend.

Constraints

The present needs to be appropriate.Only the initiator can give a present.The higher the level of training, the less the Tamagotchi misbehaves.The Tamagotchi needs to be of appropriate age to play with certain items.The Tamagotchi must be of the appropriate age to go to pre-school or school.The Tamagotchi must graduate from school to go to work.The Tamagotchi must have a sufficient amount of “gotchi” points to buy something from the shopping mall, food court, or travel agency.The Tamagotchi must have donated a certain number of “gotchi” points to visit the king’s castle.

The role model for OwnerRole name Owner

Description The role of the owner of my digital pet.

Responsibilities

Wake up the Tamagotchi.Feed the Tamagotchi.Cure the Tamagotchi.Flush the toilet.Discipline the Tamagotchi.Play a game with the Tamagotchi.Let the Tamagotchi play with an item.Initiate an interaction with another Tamagotchi:Visit Tamagotchi Town with the Tamagotchi:

- take the Tamagotchi to pre-school;- take the Tamagotchi to school;- take the Tamagotchi to workplace;- take the Tamagotchi to theatre;- take the Tamagotchi to shopping mall;- take the Tamagotchi to food court;- take the Tamagotchi to travel agency;- take the Tamagotchi to the game centre;- take the Tamagotchi to the town hall;- take the Tamagotchi to the king’s castle.

Constraints

For interacting with another Tamagotchi, the owner needs to establish infrared connection with correct parameters between the two Tamagotchis.

To visit Tamagotchi Town, the owner must have a computer with Internet connection.

The organisation model for Tamagotchis

The domain model for the case study of Tamagotchis

The types of resources consumed by a Tamagotchi

Resource(s) Role(s) Environment(s) Present (Snack or Item) MyTamagotchi, Owner,

FriendTamagotchi Tamagotchi Shell, Tamagotchi Town

Food (Meal or Snack) MyTamagotchi, Owner Tamagotchi Shell, Tamagotchi Town

Meal (Hamburger, Omlet, Fish, Pizza, …)

MyTamagotchi, Owner Tamagotchi Shell, Tamagotchi Town

Snack (Popcorn, Banana, Grapes, Watermelon, Ice-Cream, …)

MyTamagotchi, Owner, FriendTamagotchi

Tamagotchi Shell, Tamagotchi Town

Item (Racing-game, Chest, Flower, Shovel, …)

MyTamagotchi, Owner, FriendTamagotchi

Tamagotchi Shell, Tamagotchi Town

Souvenir MyTamagotchi, Owner Tamagotchi Town, Tamagotchi Shell

Letter MyTamagotchi, Owner Tamagotchi Shell