+ All Categories
Home > Documents > Measurable Properties Name Blood pressure Weight Length Age Shoe size Temperature IQ EQ PERSON A...

Measurable Properties Name Blood pressure Weight Length Age Shoe size Temperature IQ EQ PERSON A...

Date post: 21-Dec-2015
Category:
View: 215 times
Download: 2 times
Share this document with a friend
24
Measurable Properties Name Blood pressure Weight Length Age Shoe size Temperature IQ EQ PERSON A person may have a large number of properties that are quantitative. Representing all these properties in a schema can make it exceedingly large.
Transcript

Measurable Properties

NameBlood pressureWeightLengthAgeShoe sizeTemperatureIQEQ

PERSONA person may have a largenumber of properties thatare quantitative.

Representing all theseproperties in a schema can make it exceedingly large.

Measurement Pattern

Phenomenon type

MeasurementObject Quantity

1

**

*1 1

The Measurement Pattern enables a compact representationof quantitative properties.

A measurement measures thequantity of a phenomenon type for a certain object.

Measurement Pattern

:Phenomenon typename = temperature

:Measurementdate = 000101

:Objectname = ‘Peter’

:Quantityunit = Celsiusvalue = 37.5

This instance diagram states that Peter has the temperature 37.5 degrees Celsius 000101.

Category Observation

Some properties are not quantitative, but rather classifyobjects into different groups, for example the gender or nationality of a person.

Phenomenon type

Category observation

Object Category

1

**

*1 1

Category Observation

:Phenomenon typename = gender

:Category observationdate = 000101

:Objectname = ‘Peter’

:Categoryvalue = male

This instance diagram states that Peter has the gender male 000101.

Observation Pattern

Phenomenon type

ObservationObject

1

**

*

1

1

Category observation

Measurement

CategoryQuantity

1*

Measurements and category obser-vations can be combined intoone pattern.

Employment

NameAgeAddressEmployerDate of employment

PERSON We can model the fact that a personis employed at some organisation byincluding a number of attributes ina type PERSON.

However, a person may be employedat several different organisations.In order to handle such a situation,the model has to be expanded.

Employment

NameAddress

ORGANISATION

NameAgeAddress

PERSON

Salary

EMPLOYMENT

FromTo

TIME PERIOD

employee employer11

1*

* *

Employment

NameAddress

ORGANISATION

NameAgeAddress

PERSON

Salary

EMPLOYMENTFromTo

TIME PERIOD

employee employer11

1*

* *This model expresses that there exists a responsibility between two parties, the employer and the employee. Similar responsibilities may exist in many other contexts.

Accountability Pattern

PERSON

ACCOUNTABILITY

ORGANISATION

FromTo

TIME PERIOD

Name

ACCOUNTABILITY TYPE

NameAddress

PARTY responsiblecommissioner

1

1 1

1**

* *

Accountability Pattern

ACCOUNTABILITY

ACCOUNTABILITY TYPE

PARTY

The Accountability Pattern can be used to model situations where there exists a relationship of responsibility between two parties:- Employment- Order- Contract- Membership- Offering

ACCOUNTABILITY TYPE specifies different kinds of accountability. In an employment context, it could contain: permanent employment, project employment, time limited employment, etc.

Accountability

:Accountability typename = permanent

:Accountability:Time period

from = 970101to = 001231

:Personname = ‘Peter’

:Organisationname = ‘IBM’

responsiblecommissioner

This instance diagram states that Peter is employed by IBM 970101 - 001231.

Action Pattern

PROPOSED ACTION IMPLEMENTED ACTION

TIME POINT ACTION

PARTY

LOCATION

An action is carried out by a party at a certain point in time at a certain location.

An action may be only proposed or it may be implemented, i.e. carried out.

Action Pattern

:Personname = ‘Peter’

:Proposed actionname = surgery

:Implemented actionname = ‘Peter’

:Locationroom = C604

:Time pointdate = 990101

time = 1.00 a.m.

:Locationroom = C608

:Time pointdate = 990101

time = 2.00 a.m.

Booking

FromTo

BOOKING

RESOURCE

1

*

for

Using this simple booking schema, we can express that different resources are booked for different time intervals.

In some situations, we do not want to book a specific resource, but rather a general resource type. For example, we only state that we want to book an anaesthesia nurse, it does not matter who. In other cases, we really want to book a specific nurse, say Ed Wallen.

Assets and other Resources

Some resources are consumed in an activity, e.g. in a surgery blood plasma is consumed.

Other resources are not consumed in an activity but can be reused. For example, a nurse is not consumed in a surgery.

Resource Allocation Pattern

RESOURCE TYPE

FromTo

TEMPORAL RESOURCE

SPECIFIC RAGENERAL RA

Quantity

RESOURCE ALLOCATION

ASSET TYPE ASSET

1

1

1

1

*

*

*

*

Resource Allocation

:General RAquantity 3

:Resource Typename = Blood plasma

:Asset Typename = Nurse

:Assetname = ‘Peter’

:Specific RA

:Temporal Resourcefrom = 0101, 04

to = 0101, 06

Three bags of blood plasma are allocated - we do not care which ones.

Peter is allocated for two hours.

Exercise

The Resource Allocation Pattern has

a number of limitations. Identify

these and construct an extension of

the pattern that overcomes these

limitations. Consider whether it

would be worthwhile to have

several variants of the pattern to

cover different situations.

Action and Resource Allocation

PROPOSED ACTION IMPLEMENTED ACTION

ACTION

RESOURCE ALLOCATION

books uses

A proposed action books resources, while an implemented action uses resources.

Plans

PLAN

PROPOSED ACTION

*

*

contains

The simplest way to model a plan is to say that it consists of a number of proposed actions.

Example: Plan for dinner party consists of buying food, cooking, and making the table.

One limitation of this model is that we cannot express dependencies between proposed actions, i.e. that certain actions have to be performed before others.

Plan Pattern

PLAN

ACTION REFERENCE

*

1

contains

PROPOSED ACTION

1

*precedes

By adding a type ACTION REFERENCE, we can express precedence relationships among proposed actions in a plan. We can also add descriptions of the role of an action within a plan, e.g. whether it is optional or not.

Subtypes

VEHICLE

BIKETRUCKBOATCAR

One way to show different categories is to introduce a number of subtypes. However, such a solution may result in a very large schema.

Powertypes

VEHICLE

VEHICLE TYPE

1

*

VEHICLE TYPE would have instances such as:Car, Truck, Boat, Bike, MC, Aeroplane, ...

VEHICLE would have instances such as:abc123 (which is a Car), vv22 (which is a Boat), ...


Recommended