(PDF) Draft URML Abstract Syntax Specification (Excerpt from my in progress thesis)

URML: Towards Visual Negotiation of

Complex System Requirements

Florian Schneider

Tuesday 5th February, 2013

Disclaimer: This is an excerpt of my doctoral thesis, which in its appendix describes the URML abstract

syntax meta-model, dedicating a subsection to each of the language's elements. The meta-model version you

are looking at is in alpha state, namely in version 0.9.1. This state of the meta-model is implemented in the

Enterprise Architect Add-In for URML version 1.0.5. Later reﬁnements of meta-model and add-in will lead to a

re-publication of this document.

Patent applied for by Siemens and TUM, 2012

URML is a collaboration project of Siemens Corporate Research, Princeton, and Technische Universität

München, Institut für Informatik, Chair for Applied Software Engineering, Munich.

Contents
1 non-formal to formal transformation requires meta-model ......... 45
2 On abstraction ................................. 45
3 On modeling, human vs. compiler ....................... 46
4 Argument for reversing separation of constraints .............. 46
5 General blabla ................................. 46
Appendix 49
1 URML Abstract Syntax Speciﬁcation ..................... 49
1.1 AbstractFeature (Abstract Class) ................... 50
1.2 AbstractGoal (Abstract Class) .................... 50
1.3 Actor (Class) .............................. 51
1.4 Aggregation (Relationship) ...................... 51
1.5 AssessmentSketch (Class) ....................... 52
1.6 Asset (Class) .............................. 53
1.7 AssetOwnership (Relationship) .................... 54
1.8 AssetType (Enumeration) ....................... 55
1.9 BoundaryObject (Class) ........................ 55
1.10 BoundaryObjectContainment (Relationship) ............. 56
1.11 BusinessStakeholder (Class) ...................... 56
1.12 Customer (Class) ............................ 57
1.13 Danger (Abstract Class) ........................ 58
1.14 DangerTrigger (Relationship) ..................... 59
1.15 EntityObject (Class) .......................... 59
1.16 EnvironmentProcess (Class) ..................... 60
1.17 Feature (Class) ............................. 62
1.18 FeatureConstraint (Relationship) ................... 63
1.19 FeatureDescriptionRequirement (Relationship) ........... 63
1.20 FeatureDescriptionUseCase (Relationship) .............. 64
1.21 FeatureExclusion (Relationship) ................... 65
1.22 FeatureGroup (Class) ......................... 65
1.23 FeatureList (Relationship) ....................... 67
1.24 FeatureRequirement (Relationship) .................. 67
1.25 FeatureSelectionOption (Relationship) ................ 68
1.26 FeatureSelectionType (Enumeration) ................. 68
1.27 FeatureTree (Relationship) ...................... 69
1.28 FunctionalRequirement (Class) .................... 70
1.29 Goal (Class) ............................... 71
1.30 GoalContribution (Relationship) ................... 71
1.31 GoalContributionType (Enumeration) ................ 72
1.32 GoalDecomposition (Relationship) .................. 72
1.33 GoalRealization (Relationship) .................... 73
1.34 GoalStatement (Relationship) ..................... 73
1.35 Harm (Relationship) .......................... 74
1.36 HarmedElement (Abstract Class) ................... 75
5

Contents
1.37 Hazard (Class) ............................. 75
1.38 HazardType (Enumeration) ...................... 78
1.39 Idea (Class) ............................... 78
1.40 InformationFlow (Relationship) .................... 79
1.41 InformationFlowType (Enumeration) ................. 79
1.42 Inheritance (Relationship) ....................... 80
1.43 Mention (Relationship) ........................ 81
1.44 Mitigation (Abstract Relationship) .................. 81
1.45 Motivation (Relationship) ....................... 82
1.46 Procedure (Class) ............................ 82
1.47 ProceduralMitigation (Relationship) ................. 83
1.48 Process (Abstract Class) ........................ 84
1.49 ProcessConstraint (Relationship) ................... 85
1.50 ProcessEnabling (Relationship) .................... 85
1.51 ProcessExtension (Relationship) ................... 86
1.52 ProcessInclusion (Relationship) .................... 87
1.53 ProcessPrecedence (Relationship) ................... 87
1.54 ProcessRequirement (Relationship) .................. 88
1.55 Product (Class) ............................. 88
1.56 ProductLine (Class) .......................... 89
1.57 ProductLineAggregation (Relationship) ............... 90
1.58 ProductLineContainment (Relationship) ............... 90
1.59 ProductSuite (Class) .......................... 91
1.60 ProductSuiteContainment (Relationship) .............. 92
1.61 QualityRequirement (Class) ..................... 92
1.62 QualityRequirementType (Enumeration) ............... 96
1.63 Request (Class) ............................. 97
1.64 RequestStatement (Relationship) ................... 98
1.65 RequestCause (Relationship) ..................... 98
1.66 RequestRealization (Relationship) .................. 99
1.67 Requirement (Abstract Class) ..................... 99
1.68 RequirementMitigation (Relationship) ................100
1.69 RequirementReﬁnement (Relationship) ................101
1.70 ServiceContainment (Relationship) ..................101
1.71 ServiceProvider (Class) ........................102
1.72 ServiceProviderType (Enumeration) .................103
1.73 SoftGoal (Class) ............................104
1.74 Stakeholder (Class) ...........................104
1.75 StakeholderHierarchy (Relationship) .................105
1.76 System (Abstract Class) ........................106
1.77 SystemEmbedment (Relationship) ..................106
1.78 SystemFunction (Relationship) ....................107
1.79 SystemInteraction (Relationship) ...................107
1.80 SystemInteractionType (Enumeration) ................108
6

Contents
1.81 SystemInterest (Relationship) .....................108
1.82 SystemUnderDiscussion (Class) ....................109
1.83 TestDescription (Relationship) ....................110
1.84 Threat (Class) .............................110
1.85 URMLModel (Class) ..........................111
1.86 URMLModelElement (Abstract Class) ................111
1.87 URMLModelEntity (Abstract Class) .................111
1.88 URMLModelRelationship (Abstract Relationship) .........112
1.89 UseCase (Class) .............................112
1.90 Vulnerability (Relationship) ......................114
2 URML Meta-Model Diagrams .........................118
3 Pseudo-Algorithm for the simpliﬁcation of the meta-model .........118
Bibliography 118
List of Figures 125
7

7Appendix

7.1 URML Abstract Syntax Speciﬁcation

The URML comprises a total of 90 meta-model elements. This section gives a per-

element description of classes, relationships and enumerations of the meta-model. The

elements are presented in alphabetic, ascending order. Each element is described in its

own section. The format of each section is derived from the meta-model as described

in section 4.2. The name of the element, its metatype, and a speciﬁcation whether the

element is abstract form the section title. This is followed by the element summary,

which is one sentence summarizing the function of the element. Further content of the

section depends on the metatype of the element.

If the element is a classiﬁer, the summary is followed by a list of the element’s super

classiﬁers. This paragraph is named “Generalizations”. Then, a detailed description of

the element is given. A list of attributes is presented next. Classes also have a listing

of the attributes inherited from superclasses. This isn’t done for relationships as these

are not part of deep inheritance hierarchies.1For classes, a list of relationships they

can participate in comes next, while for relationships a list of role names combined with

cardinalities and a speciﬁcation how relationship instances on a diagram can be “read”

(i.e. transformed into prose text) comes next. For both types of classiﬁers a description

of their notation comes next.

If the element is an enumeration, the classiﬁer it is used with is presented. The list

of enumeration literals that entail the enumeration comes next, followed by the detailed

description. The notation used to reﬂect diﬀerent enumeration literals is presented with

the notation section of the according classiﬁer, therefore the notation section of an enu-

meration only references the according classiﬁer’s notation section. The speciﬁcation of

an enumeration is concluded by a list of text-based examples.

1In the current state of the URML, the only attribute that is inherited by every relationship is the

description attribute of URMLModelElement. The only occasion where the inheritance hierarchy is

one level deeper is the taxonomy of mitigation relationships.

49

7 Appendix

7.1.1 AbstractFeature (Abstract Class)

Abstract base class that enables the modeling of feature trees.

Generalizations

•URMLModelEntity

Description Abstract Feature enables the hierarchical structuring of features. It serves

as a superclass to Feature and Feature Group. The three form a composite pattern,

which allows for modeling the feature tree of a product line. Additionally, the selection

of one abstract feature can require the selection or exclusion of other abstract features.

Attributes

•No additional attributes.

Inherited Attributes

•description (from URMLModelElement)

•name (from URMLModelEntity)

7.1.2 AbstractGoal (Abstract Class)

Abstract base class for taking part in relationships that are common to goals and soft

goals.

Generalizations

•URMLModelEntity

Description An abstract goal is expressed by one to many stakeholders, expressing a

condition or state of aﬀairs in the world that [they] would like to achieve \cite{itu2008}.

An abstract goal is product independent. Abstract goals do not exist in isolation; there-

fore they can be connected via two relationships, namely GoalContribution and GoalDe-

composition. Abstract goals are either hard or soft. The distinction between ’hard’

(Goal) and ’soft’ (SoftGoal), depends on whether there is a description of how to mea-

sure success in reaching the goal (see AssessmentSketch). Abstract goals can be are the

source of stakeholder requests. Abstract goals are realized by features.

Attributes

•No additional attributes.

50

7.1 URML Abstract Syntax Speciﬁcation

Inherited Attributes

•description (from URMLModelElement)

•name (from URMLModelEntity)

7.1.3 Actor (Class)

A system of its own behavior interacting with the system under discussion. Therefore

also a stakeholder.

Generalizations

•Stakeholder

•System

Description An actor is a stakeholder that directly interacts with the system under

discussion. It can be a living person, or an external entity such as a computer or piece

of equipment (e.g. a thermostat). An actor uses boundary objects to initiate processes

of the system or to participate in them. An actor is external to the system.

Attributes

•No additional attributes.

Inherited Attributes

•description (from URMLModelElement)

•name (from URMLModelEntity)

•weight (from Stakeholder)

Notation The icon depicts an iconized person. This icon was basically inspired by the

stick ﬁgure known from the UML.

Figure 7.1: Actor Icon

7.1.4 Aggregation (Relationship)

Expresses a composite-component relationship for all entities of the URML.

51

7 Appendix

Generalizations

•URMLModelRelationship

Description Aggregation is a relationship of rather generic semantics that is available to

every entity of the URML. It oﬀers expression of composition/decomposition semantics

between elements of the same kind.

Attributes

•No additional attributes.

Role Names and Cardinalities

composite: URMLModelEntity[1]

component: URMLModelEntity[*]

Notation TODO

Template Sentence “URMLModelEntity consists of URMLModelEntit(-y/-ies)”

7.1.5 AssessmentSketch (Class)

A sketchy description of how the realization of a goal can be tested.

Generalizations

•URMLModelEntity

Description Description of how to measure success in reaching a goal. An assessment

sketch is a rather informal element that contains suggestions (in its description attribute)

for assessing or testing whether a goal is actually addressed by the system.

Attributes

•No additional attributes.

Inherited Attributes

•description (from URMLModelElement)

•name (from URMLModelEntity)

52

7.1 URML Abstract Syntax Speciﬁcation

Notation The icon depicts a goal being weighed on a scale.

0.0

Figure 7.2: AssessmentSketch icon

7.1.6 Asset (Class)

Something of value to a stakeholder.

Generalizations

•URMLModelEntity

•HarmedElement

Description An asset is something that is of value to a stakeholder and is owned by the

stakeholder. A further speciﬁcation of the nature of an asset can be given through the

asset type. An asset can be harmed by dangers. The nature of the asset, the probability

of the danger, and the weight of the stakeholder help in assessing the severity of the

danger.

Attributes

•type: AssetType (default value: Uncategorized)

Inherited Attributes

•description (from URMLModelElement)

•name (from URMLModelEntity)

Notation The basic icon (uncategorized asset) depicts a money bag. This base icon is

decorated when the value of the asset’s type changes. The bag ’contains’ a dollar sign for

ﬁnancial assets, two oﬃce buildings for property assets, and an identity card for identity

assets.

53

7 Appendix

Figure 7.3: Uncategorized

Asset icon

Figure 7.4: Financial

Asset icon

Figure 7.5: Property

Asset icon

Figure 7.6: Identity

Asset icon

7.1.7 AssetOwnership (Relationship)

Expresses which stakeholder owns which asset.

Generalizations

•URMLModelRelationship

Description This relationship shows which stakeholders own which assets. This is im-

portant for understanding goals and requests of the stakeholders, and for the analysis of

the impact of dangers.

Attributes

•No additional attributes.

Role Names and Cardinalities

owner: Stakeholder[1]

ownedAssets: Asset[1..*]

Notation TODO

Template Sentence “Stakeholder owns Asset(s)”

54

7.1 URML Abstract Syntax Speciﬁcation

7.1.8 AssetType (Enumeration)

Enables a distinction between ﬁnancial, identity, property, and uncategorized assets.

Categorized Class

•Asset

Enumeration Literals

•Financial

•Identity

•Property

•Uncategorized

Description AssetType enumerates the diﬀerent kinds of assets. A ﬁnancial asset fo-

cuses on assets of monetary value like cash, stock options, or funds. Property assets

focuses more on physical assets that might be damaged through a hazard. Identity as-

sets cover personal information about a stakeholder that should be protected. If the

distinction is of no importance in a speciﬁc context or is unambiguous by the name of

the asset, the modeler can leave the asset be uncategorized.

Notation See notation section of Asset (Class).

7.1.9 BoundaryObject (Class)

An interface of the system.

Generalizations

•URMLModelEntity

Description The interface between an actor and a system or process. It can for example

be a GUI, a panel or a switch. A boundary object is not strictly an input device. While

it accepts input by actors it can also possibly communicate or display the responses of

the system.

Attributes

•No additional attributes.

55

7 Appendix

Inherited Attributes

•description (from URMLModelElement)

•name (from URMLModelEntity)

Notation The icon depicts a hand, with the index ﬁnger pushing a big push-button.

Figure 7.7: BoundaryObject icon

7.1.10 BoundaryObjectContainment (Relationship)

Shows to which system a boundary object belongs.

Generalizations

•URMLModelRelationship

Description This relationship allows for modeling which boundary objects are exposed

by a system. By listing all boundary objects of a system, the modeler can get a summary

of the objects through which a system can be used, i.e. the interface of the system. A

boundary object may not be part of multiple systems.

Attributes

•No additional attributes

Role Names and Cardinalities

exposingSystem: System[1]

exposedBoundary: BoundaryObject[1]

Notation TODO

Template Sentence “System has boundary BoundaryObject”

7.1.11 BusinessStakeholder (Class)

Somebody who is primarily interested in the system because he orders it.

56

7.1 URML Abstract Syntax Speciﬁcation

Generalizations

•Stakeholder

Description A business stakeholder is a stakeholder other than the customer that is

involved with ﬁnancial aspects of a system or process set. For example, the CEO of a

company building rail cars would be a business stakeholder for railcar products. A person

in the role of a business stakeholder often is no user (i.e. actor) of the system.

Attributes

•No additional attributes.

Inherited Attributes

•description (from URMLModelElement)

•name (from URMLModelEntity)

•weight (from Stakeholder)

Notation The icon depicts two persons that are shaking hands. Both persons have a

suitcase standing beneath them.

Figure 7.8: BusinessStakeholder icon

7.1.12 Customer (Class)

Somebody who is primarily interested in the system because he pays for it.

Generalizations

•Stakeholder

Description A special kind of stakeholder that purchases or funds the development of a

system or process (e.g. hospital CFO). The term customer may also be used to describe

an entire entity, e.g. an Integrated Healthcare Network. In such a scenario, the customer

usually is no user of the system. In the private sector, a customer might also be the end

user (e.g. the buyer of a text editing software).

57

7 Appendix

Attributes

•No additional attributes.

Inherited Attributes

•description (from URMLModelElement)

•name (from URMLModelEntity)

•weight (from Stakeholder)

Notation The icon depicts a person pushing a shopping cart.

Figure 7.9: Customer icon

7.1.13 Danger (Abstract Class)

The potential occurrence of something to be avoided, because it harms assets, persons,

or systems.

Generalizations

•URMLModelEntity

Description Danger models the potential occurrence of something to be avoided as it

may cause physical (see Hazard) or ﬁnancial (see Threat) harm to the system, its stake-

holders, or the assets of these stakeholders. A danger has a probability with which it oc-

curs and a severity describing the magnitude of its impact. Dangers may threaten stake-

holders, service providers, or assets, which we summarize under the term HarmedEle-

ment. In addition to harmed elements, also processes can be vulnerable to a danger,

showing weak points of the system. While being vulnerable to danger, processes can also

be the source of danger. Dangers should be mitigated by either appropriate procedures

or requirements that the system under discussion should satisfy.

Attributes

•severity:

•probability:

58

7.1 URML Abstract Syntax Speciﬁcation

Inherited Attributes

•description (from URMLModelElement)

•name (from URMLModelEntity)

7.1.14 DangerTrigger (Relationship)

Relates a process with the dangers it might trigger.

Generalizations

•URMLModelRelationship

Description DangerTrigger models, from the viewpoint of a single process, which dan-

gers a single trigger might cause. This means that dangers that might happen in con-

junction are connected by one such relationship. Dangers that might happen at diﬀerent

points of the processes are connected via separate instances of this relationship.

Attributes

•No additional attributes

Role Names and Cardinalities

triggeredDangers: Danger[1..*]

triggeringProcess: Process[1]

Notation TODO

Template Sentence “Process triggers Danger(s)”

7.1.15 EntityObject (Class)

An object manipulated by the system.

Generalizations

•URMLModelEntity

59

7 Appendix

Description An entity object can be something an actor gives to the system (e.g. name),

something the system gives to the actor (e.g. an address) or something passed internally

from one part of the system to another. An entity object can be a tangible object (e.g.

a letter) or information. Entity objects are (as any other URML entity) decomposable.

For an entity object instance, it is of particular interest to the modeler whether it is

further decomposable or not. Entity objects are important for the system designers that

receive a URML model when it is ﬁnished, as the processing of these objects strongly

inﬂuences the architecture of the system. Thus, an entity object can be marked being

atomic, i.e. non-decomposable. This is reﬂected then by a diﬀerent notation.

Attributes

•atomic: Boolean

Inherited Attributes

•description (from URMLModelElement)

•name (from URMLModelEntity)

Notation The icon for the atomic entity object depicts an open envelope. The icon for

composite entity object depicts a ﬁling cabinet.

Figure 7.10: Composite

Entity-

Object

icon

Figure 7.11: Atomic

Entity-

Object

icon

7.1.16 EnvironmentProcess (Class)

A process being executed in the environment of the system under discussion.

Generalizations

•Process

60

7.1 URML Abstract Syntax Speciﬁcation

Description As the system under discussion will be embedded into its environment, the

activities of the environment need to be studied, in order to discover what the features

of the system should be, and what interfaces it needs to oﬀer. For danger modeling, it

should be considered which environment processes should not interfere with, or which

environment process could pose danger to the system. For business process modeling,

environment processes that describe the customer environment are of particular interest.

They are a description of activities as found in the customer’s organization (often termed

business processes). By the distinction between environment processes and use cases,

the model shows how the system under discussion is used within its environment. When

starting modeling, the environment process model can provide a black box view of the

system. The business process aspect can be emphasized through the boolean attribute

businessProcess inherited from the Process superclass.

Attributes

•No additional attributes

Inherited Attributes

•atomic (from Process)

•businessProcess (from Process)

•description (from URMLModelElement)

•name (from URMLModelEntity)

•preCondition (from Process)

•postCondition (from Process)

•underConstruction (from Process)

Notation The overall icon consists of a base icon that is decorated by overlays. The

base icon consists of an oval (inspired by UML use case notation), in which two persons

are depicted that shake hands. In between them stands a suitcase. Below them are two

stylized arrows pointing in opposite directions. If the process is atomic, a dot is placed

on the lower right of the icon. If the process is under construction, a yellow-and-black

striped road barrier is placed on the lower center.

61

7 Appendix

Figure 7.12: EnvironmentProcess

icon

Figure 7.13: Atomic Environ-

mentProcess icon

Figure 7.14: Under construction EnvironmentProcess icon

7.1.17 Feature (Class)

Stakeholder-visible characteristic of the system under discussion.

Generalizations

•AbstractFeature

Description A feature is a desirable or existing, prominent or distinctive stakeholder-

visible aspect, quality, or characteristic of a system. A feature enables environment

processes, i.e. it is a necessary component for their execution. A feature contributes

to a goal if the user visible property helps the stakeholder reach that goal. A set of

features deﬁnes a product. A feature makes a set of functional requirements visible to

stakeholders. Quality requirements describe constraints that the feature must satisfy. A

feature that is in every product of a product line can be marked being a core feature.

Attributes

•core: Boolean

Inherited Attributes

•description (from URMLModelElement)

•name (from URMLModelEntity)

62

7.1 URML Abstract Syntax Speciﬁcation

Notation The overall icon consists of a base icon that is possibly decorated by one

overlay if the value of the core attribute is true. The base icon depicts a puzzle piece.

The core overlay depicts an apple’s core that is placed on the right of the puzzle piece.

Figure 7.15: Feature icon Figure 7.16: Core Feature icon

7.1.18 FeatureConstraint (Relationship)

Maps a quality requirement to a feature.

Generalizations

•URMLModelRelationship

Description A feature that itself is not a user-visible quality of the system might still be

constrained by a quality requirement. That is, the quality requirement is not advertised

as a feature itself, but as a constraint to a feature (e.g. Feature is “Long Battery Runtime”,

QualityRequirement is “~8hours”).

Attributes

•No additional attributes

Role Names and Cardinalities

constraint: QualityRequirement[1]

constrainedFeature: Feature[1]

Notation TODO

Template Sentence “QualityRequirement constrains Feature”

7.1.19 FeatureDescriptionRequirement (Relationship)

Maps a functional requirement to a feature.

Generalizations

•URMLModelRelationship

63

7 Appendix

Description A feature just describes what is a distinctive characteristic of the system

(e.g. what the user sees from the outside). This has to be backed by functional require-

ments. Which feature is described by which functional requirements is shown through

instances of this relationship.

Attributes

•No additional attributes

Role Names and Cardinalities

detailingRequirement: FunctionalRequirement[1]

detailedFeature: Feature[1]

Notation TODO

Template Sentence “FunctionalRequirement details Feature”

7.1.20 FeatureDescriptionUseCase (Relationship)

Maps a use case to a feature.

Generalizations

•URMLModelRelationship

Description While the FeatureDescriptionRequirement relationship allows to map func-

tional requirements to features, the modeler still does not now which functions of the

system might be invoked in which order. This relationship enables a mapping of features

to system behavior (i.e. use cases).

Attributes

•No additional attributes

Role Names and Cardinalities

detailingUseCase: UseCase[1]

detailedFeature: Feature[1]

Notation TODO

Template Sentence “UseCase details Feature”

64

7.1 URML Abstract Syntax Speciﬁcation

7.1.21 FeatureExclusion (Relationship)

Expresses that the selection of one feature leads to the exclusion of another feature.

Generalizations

•URMLModelRelationship

Description Some features or feature groups may not be part of the same product,

while they are still part of the same product line. This relationship expresses that the

selection of one feature or feature group excludes the selection of the other feature or

feature group.

Attributes

•No additional attributes

Role Names and Cardinalities

excludingFeature: AbstractFeature[1]

excludedFeature: AbstractFeature[1]

Notation TODO

Template Sentence “AbstractFeature excludes AbstractFeature”

7.1.22 FeatureGroup (Class)

A set of related features from which a product designer would select a subset according

to a deﬁned selection rule.

Generalizations

•AbstractFeature

Description A feature group is a set of related features, e.g. "power options". A feature

group is nothing ’physical’, it is mainly used for grouping purposes. For the product line

modeler it is nevertheless very important as it is the central concept for modeling a

feature tree. The topmost group of the feature tree is marked with the root == true.

The tree structure is enabled through the composite pattern with AbstractFeature and

Feature. A product line can have exactly one feature tree and thus points exactly to one

FeatureGroup with root == true.

65

7 Appendix

Attributes

•root: Boolean

•underConstruction: Boolean

•selectionType: FeatureSelectionType

Inherited Attributes

•description (from URMLModelElement)

•name (from URMLModelEntity)

Notation The overall icon consists of a base icon that is decorated by an overlay icon

if the feature group’s underConstruction attribute is set to true. If the feature group’s

root attribute is true, the base icon depicts a tree whose leaves are puzzle pieces. The

puzzle pieces stand for the features (see section 7.1.17). In the other case, the a base

icon depicts a set of six puzzle pieces, of which two and four are connected. The under

construction overlay is the same as with processes (see section ): a yellow-and-black

striped road barrier. In addition to the icon, an arc may be attached, depending on the

value of the selectionType attribute. If the value is ’All”, no arc is drawn. If the value is

’Any’ a hollow arc is drawn. If the value is ’Exclusive’, the arc is ﬁlled with black color.

The arc connects (and possibly hides part of) the lines constituting the notation of the

incoming feature selection option relationships.

Figure 7.17: FeatureGroup

icon

Figure 7.18: UnderConstruction

FeatureGroup

icon

Figure 7.19: Root Feature-

Group (a.k.a.

“feature tree”)

icon

Figure 7.20: UnderConstruction

Root Feature-

Group icon

66

7.1 URML Abstract Syntax Speciﬁcation

7.1.23 FeatureList (Relationship)

Shows to which product a feature belongs.

Generalizations

•URMLModelRelationship

Description This relationships enables modeling which of the potential features of a

product line are actually mapped to a product. Each feature that was selected for the

product is connected to it via this relationship.

Attributes

•No additional attributes

Role Names and Cardinalities

product: Product[1]

component: Feature[1]

Notation TODO

Template Sentence “Product has Feature”

7.1.24 FeatureRequirement (Relationship)

Shows that a feature requires another feature.

Generalizations

•URMLModelRelationship

Description Some features or feature groups may have other features as a prerequisite.

This can in turn be another feature or feature group. The requiring feature may only be

selected from a product line if the required feature is chosen as well.

Attributes

•No additional attributes

Role Names and Cardinalities

requiringFeature: AbstractFeature[1]

requiredFeature: AbstractFeature[1]

67

7 Appendix

Notation TODO

Template Sentence “AbstractFeature requires AbstractFeature”

7.1.25 FeatureSelectionOption (Relationship)

Shows to which feature group a feature or feature group belongs.

Generalizations

•URMLModelRelationship

Description A feature group prescribes a rule with which sub-features or sub-feature

groups of the group may be selected. These selectable features or feature groups are

connected to the parent feature group via this relationship. The relationship may further

conﬁne the selection rule by specifying that the connected feature or feature group is

mandatory and must be selected. This conﬁnement only makes sense for feature groups

of selection types “Any” or “Exclusive”. The “All” selection type already prescribes that

all sub-features must be selected. For the “Any” selection type the conﬁnement means

that the mandatory feature or feature group must be selected plus any combinations of

the sibling features or feature groups. For the “Exclusive” selection type, the conﬁnement

only makes sense if there is more than one sibling in addition to the mandatory feature

or feature group. The conﬁnement means then that the mandatory feature or feature

group must be selected plus exactly one of the other features or feature groups.

Attributes

•mandatory: Boolean

Role Names and Cardinalities

selectionGroup: FeatureGroup[1]

option: Feature[1]

Notation TODO

Template Sentence “FeatureGroup has option Feature”

7.1.26 FeatureSelectionType (Enumeration)

Categorized Class

•FeatureSelectionOptions

68

7.1 URML Abstract Syntax Speciﬁcation

Enumeration Literals

•All

•Any

•Exclusive

Description

All - All sub-features or feature groups must be selected.

Any - Any combination of features or feature groups can be selected.

Exclusive - Exactly one of the features or feature groups can be selected.

7.1.27 FeatureTree (Relationship)

Links a product line with its tree of features, rooted in a feature group.

Generalizations

•URMLModelRelationship

Description For a given tree of features, there should be one feature group at the top

of the tree that is marked being the root. This root feature group can then be linked to

the product line it shall represent. This is an exclusive relationship; a product line may

link to exactly one feature group and vice versa.

Attributes

•No additional attributes

Role Names and Cardinalities

representedProductLine: ProductLine[1]

featureTreeRoot: ProductGroup[1]

Notation TODO

Template Sentence “ProductGroup represents ProductLine”

Constraints A feature tree relationship may only relate to a feature group that is

marked being a root.

69

7 Appendix

7.1.28 FunctionalRequirement (Class)

A requirement that demands for a function of the system.

Generalizations

•Requirement

Description A functional requirement is a kind of requirement describing required func-

tionality of the system under discussion, as opposed to a quality requirement. Processes

require certain functions of the system, whose requirement is modeled through functional

requirements. Functional requirements detail features such that the manifest the set of

functional requirements that are made visible by that feature. Functional requirements

are not necessarily stakeholder-visible.

Attributes

•No additional attributes

Inherited Attributes

•costDriver (from Requirement)

•description (from URMLModelElement)

•name (from URMLModelElement)

•priority (from Requirement)

•rank (from Requirement)

•regulatory (from Requirement)

Notation The overall icon consists of a base icon that is decorated with an overlay icon

if the value of the regulatory attribute is set to true. The base icon depicts two gears

that mesh. The regulatory overlay depicts a police oﬃcer.

Figure 7.21: FunctionalRequirement

icon

Figure 7.22: Regulatory Func-

tionalRequire-

ment icon

70

7.1 URML Abstract Syntax Speciﬁcation

7.1.29 Goal (Class)

A specialization of abstract goal whose achievement by the system can be tested.

Generalizations

•AbstractGoal

Description An objective expressed by a stakeholder that should be achieved by the

system in operation. A goal’s realization is testable/measurable in some way (as opposed

to SoftGoal).

Attributes

•No additional attributes

Inherited Attributes

•description (from URMLModelElement)

•name (from URMLModelEntity)

Notation The icon depicts a simpliﬁed target with an array in the bull’s eye.

Figure 7.23: Goal icon

7.1.30 GoalContribution (Relationship)

The positive or negative impact the achievement of one goal has on the achievement of

another goal.

Generalizations

•URMLModelRelationship

Description The GoalContribution is a relationship between goals that is used to ex-

press how goals positively or negatively aﬀect each other. The goal contribution rela-

tionship has an attribute signifying the strength of the contribution.

71

7 Appendix

Attributes

•type: GoalContributionType

Role Names and Cardinalities

aﬀectedGoal: AbstractGoal[1]

contributingGoal: AbstractGoal[1]

Notation TODO

Template Sentence “AbstractGoal contributes to AbstractGoal”

Constraints The contribution might be known while its value is unknown. An un-

known contribution should however only be allowed in early phases of the requirement

engineering process as it leads to ambiguity as long as it is unknown.

7.1.31 GoalContributionType (Enumeration)

Categorized Class

•GoalContribution

Enumeration Literals

•++ (make)

•+ (help)

•? (unknown)

•-(hurt)

•– (break)

Description GoalContributionType enumerates the diﬀerent kinds of goal contribution.

A contribution can be positive (make, help), unknown, or negative (hurt, break).

7.1.32 GoalDecomposition (Relationship)

Enables a parent goal - subgoal relationship.

Generalizations

•URMLModelRelationship

72

7.1 URML Abstract Syntax Speciﬁcation

Description A GoalDecomposition allows to model a hierarchy of abstract goals. The

hierarchy can be mixed, i.e. consist of Goal as well as SoftGoal instances.

Attributes

•No additional attributes.

Role Names and Cardinalities

compositeGoal: AbstractGoal[1]

componentGoal: AbstractGoal[1]

Notation TODO

Template Sentence “AbstractGoal has component AbstractGoal”

7.1.33 GoalRealization (Relationship)

Maps a feature to the goal it realizes.

Generalizations

•URMLModelRelationship

Description In order to show stakeholders how the system will support their goals,

features of the system are mapped to goals. This relationships shows which goal is

realized by which feature.

Attributes

•No additional attributes.

Role Names and Cardinalities

addressedGoal: AbstractGoal[1]

realizingFeature: Feature[1]

Notation TODO

Template Sentence “Feature realizes AbstractGoal”

7.1.34 GoalStatement (Relationship)

Shows which stakeholder expressed a goal.

73

7 Appendix

Generalizations

•URMLModelRelationship

Description This relationship enables modeling which stakeholder expressed a goal.

Attributes

•No additional attributes.

Role Names and Cardinalities

issuingStakeholder: Stakeholder[1]

statedGoal: AbstractGoal[1]

Notation TODO

Template Sentence “Stakeholder expresses AbstractGoal”

7.1.35 Harm (Relationship)

Shows which danger would harm an harmed element upon occurrence.

Generalizations

•URMLModelRelationship

Description This relationship helps modeling the impact of dangers would they occur.

It connects dangers with harmed elements. As a rule of thumb, the more stakeholders

are involved, the more catastrophic the impact of the danger.

Attributes

•No additional attributes.

Role Names and Cardinalities

danger: Danger[1]

harmedElement: HarmedElement[1]

Notation TODO

Template Sentence “Danger endangers HarmedElement”

74

7.1 URML Abstract Syntax Speciﬁcation

7.1.36 HarmedElement (Abstract Class)

A superclass of stakeholder, asset, and service provider to show these can be aﬀected by

danger.

Generalizations

•URMLModelEntity

Description of all entities that may be aﬀected by danger (Stakeholder, Asset, Service

Provider). Harmed elements can be protected by procedures or requirements. The

relationships connecting Danger, HarmedElement, and the mitigating entity are called

either procedural mitigation (in the case of a procedure) or requirement mitigation (in

the case of a requirement).

Attributes

•No additional attributes.

Inherited Attributes

•description (from URMLModelElement)

•name (from URMLModelEntity)

7.1.37 Hazard (Class)

Generalizations

•Danger

Description A type of Danger; Potential cause of physical harm or injury to stake-

holders, service providers, or assets. Hazards are typed by their source (e.g. electrical,

mechanical).

Attributes

•type: HazardType

Inherited Attributes

•description (from URMLModelElement)

•name (from URMLModelEntity)

•probability (from Danger)

•severity (from Danger)

75

7 Appendix

Notation The overall icon consists of a base icon that is ﬁlled with diﬀerent content

depending on the value of the type attribute. The base icon is a triangle with rounded

corners. If the value is ’Uncategorized’, an exclamation mark is within the borders of the

triangle. If it is ’Biological’, ’Chemical’, ’Electrical’, ’Mechanical’, or ’Radiological’, the

content is adapted from the international standard on safety colors and safety signs, ISO

7010 [17], and the german standard for the same purpose, DIN 4844-2 [18]. If the value is

’Meteorological’, a simpliﬁed house and a cyclone are depicted. If the value is ’Seismical’,

a simpliﬁed house is depicted whith a crack inside. The house stands on ground that has

a chasm. If the value is ’Social’, three persons are depicted, where one person is lying on

the ground. One of the two standing persons is kicking the lying person.

76

7.1 URML Abstract Syntax Speciﬁcation

!

Figure 7.24: Uncategorized

Hazard icon

Figure 7.25: Biological Hazard

icon

Figure 7.26: Chemical Hazard

icon

Figure 7.27: Electrical Hazard

icon

Figure 7.28: Mechanical Haz-

ard icon

Figure 7.29: Meteorological

Hazard icon

Figure 7.30: Radiological Haz-

ard icon

Figure 7.31: Seismical Hazard

icon

Figure 7.32: Social Hazard

icon

77

7 Appendix

7.1.38 HazardType (Enumeration)

Categorized Class

•Hazard

Enumeration Literals

•Seismical

•Meteorological

•Biological

•Chemical

•Radiological

•Mechanical

•Electrical

•Social

•Uncategorized

Notation See notation section of Hazard (Class).

7.1.39 Idea (Class)

Generalizations

•URMLModelEntity

Description An inspiration or thought that may give rise to (i.e. motivates) a stake-

holder request. An idea is also mentioned by a stakeholder and thus has to be diﬀeren-

tiated from a request or a goal.

Attributes

•source: URI

Inherited Attributes

•description (from URMLModelElement)

•name (from URMLModelEntity)

78

7.1 URML Abstract Syntax Speciﬁcation

Notation The icon depicts a thought bubble with a shining light bulb inside.

Figure 7.33: Idea icon

7.1.40 InformationFlow (Relationship)

Enables modeling the ﬂow of entity objects between processes.

Generalizations

•URMLModelRelationship

Description This relationship connects an entity object with a process. Whether it is

going into the process (input) or coming out of it (output) should be understandable

from the context of the model elements and the value of the type attribute. A process

may create, delete, modify, or use an entity object. If a single process is the only user of

an entity object, the relationship may be left uncategorized.

Attributes

•type: InformationFlowType

Role Names and Cardinalities

informationUser: Process[1]

information: EntityObject[1]

Notation TODO

Template Sentence “Process works on EntityObject”

7.1.41 InformationFlowType (Enumeration)

Categorized Class

•InformationFlow

79

7 Appendix

Enumeration Literals

•Create

•Delete

•Modify

•Uncategorized

•Use

Description

Create - The process creates the object. Only one process may create an object.

Delete - The process deletes the object. Only one process may delete an object.

Modify - The process modiﬁes the object.

Uncategorized - The process is the single user of the object does all types of interaction

with it.

Use - The process uses the object but does not modify.

7.1.42 Inheritance (Relationship)

TODO:Summary

Generalizations

•URMLModelRelationship

Description TODO

Attributes

•No additional attributes.

Role Names and Cardinalities

superURMLModelEntity: URMLModelEntity[1]

subURMLModelEntity: URMLModelEntity[1]

Notation TODO

Template Sentence “URMLModelEntity inherits from URMLModelEntity”

80

7.1 URML Abstract Syntax Speciﬁcation

7.1.43 Mention (Relationship)

Shows which stakeholder mentioned an idea.

Generalizations

•URMLModelRelationship

Description For every idea recorded in the model, it should be known which stakeholder

mentioned the idea. This helps analyzing which requests are motivated by that idea.

Attributes

•No additional attributes.

Role Names and Cardinalities

mentioningStakeholder: Stakeholder[1]

mentionedIdea: Idea[1]

Notation TODO

Template Sentence “Stakeholder mentions Idea”

7.1.44 Mitigation (Abstract Relationship)

Generalizations

•URMLModelRelationship

Description mitigation is an abstract relationship that expresses that a danger is being

dealt with. This relationship can not be used on a diagram. Modelers have to use either

a requirement mitigation (i.e. the danger is mitigated by a requirement that describes

how the system should take precautions, circumvent the danger, or reduce the likeliness

of an incident) or a procedural mitigation (i.e. the precautions are not built into the

system but are realized by procedures that come along with the system, e.g. a handbook

or staﬀtraining).

Attributes

•No additional attributes.

81

7 Appendix

Role Names and Cardinalities

mitigatedDanger: Danger[1]

protectedHarmedElement: HarmedElement[1]

mitigation: Requirement OR Procedure

7.1.45 Motivation (Relationship)

Shows which idea motivated a request.

Generalizations

•URMLModelRelationship

Description Some knowledge the stakeholder had in mind, which was externalized in

the form of an idea to the model, can be the motivation of a request. This relationship

maps the idea to the request it motivated. Ideas that are not connected to a request

might be a hint to future requests.

Attributes

•No additional attributes.

Role Names and Cardinalities

motivatingIdea: Idea[1]

motivatedRequest: Request[1]

Notation TODO

Template Sentence “Idea motivates Request”

7.1.46 Procedure (Class)

Something outside the system under discussion that tells users how to safely use the

system.

Generalizations

•URMLModelEntity

82

7.1 URML Abstract Syntax Speciﬁcation

Description A procedure is not built into the system but into the environment of sys-

tem. It prescribes certain constraints or workﬂows how to use the system. For example it

can be a warning in the user manual containing safety instructions, guidelines in general,

or staﬀtraining.

Attributes

•No additional attributes.

Inherited Attributes

•description (from URMLModelElement)

•name (from URMLModelEntity)

Notation TODO

Figure 7.34: Procedure icon

Suggestions to implementors If the word procedure is a reserved word in your envi-

ronment, rename the class to “MitigatingProcedure”.

7.1.47 ProceduralMitigation (Relationship)

Protects a harmed element from danger through a procedure.

Generalizations

•Mitigation

Description A procedural mitigation is a mitigation relationship that expresses that a

danger is mitigated by a procedure. It signiﬁes that a danger is dealt with by precautions

external to the system under discussion.

Attributes

•No additional attributes.

83

7 Appendix

Role Names and Cardinalities

mitigatedDanger: Danger[1]

protectedHarmedElement: HarmedElement[1]

mitigatingProcedure: Procedure[1..*]

Notation TODO

Template Sentence “Procedure protects HarmedElement from Danger”

7.1.48 Process (Abstract Class)

Generalizations

•URMLModelEntity

Description A process is an abstract concept that describes the system with regards

to its usage. When specialized as EnvironmentProcess, it describes the environment in

which the system is used (i.e. the business processes of the customer). When specialized

as UseCase, it describes the functions that the system oﬀers to its users (i.e. actors). A

process in general describes the necessary steps to achieve something. It also describes

the objects used in these processes; such as objects the users interact with (i.e. boundary

objects), objects that represent internal state (i.e. entity objects), and internal agents

that control the processes (i.e. service providers). A process that is marked being atomic

cannot be subdivided further into processes. Business processes can be modeled by

setting the businessProcess attribute to true. A process has pre- and post-conditions.

It can be related to other processes via include and extend relationships (similar to

UML). A process can trigger a danger and can be vulnerable to danger. The attribute

underConstruction is used for model reviews, when the reviewer needs to know whether

the modeler is still working on the details of a particular process. This means that there

are still subprocesses to be modeled. The attributes atomic and underConstruction can

not be true at the same time, as an atomic process has no subprocesses and thus there

is no details to be worked on.

Attributes

•atomic: Boolean

•businessProcess: Boolean

•underConstruction: Boolean

•preCondition: String

•postCondition: String

84

7.1 URML Abstract Syntax Speciﬁcation

Inherited Attributes

•name (from URMLModelEntity)

•description (from URMLModelElement)

Constraints

•atomic and underConstruction cannot be true at the same time

7.1.49 ProcessConstraint (Relationship)

Connects a process with a quality requirement that constrains the process.

Generalizations

•URMLModelRelationship

Description A process may be required to execute within a certain time slot, or only

with a restricted set of resources. These are just two examples of how quality requirements

can constrain (and thus detail) how a process can be executed. Every type of quality

requirement can formulate a constraint to a process.

Attributes

•No additional attributes.

Role Names and Cardinalities

constrainedProcess: Process[1]

constrainingQualityRequirement: QualityRequirement[1]

Notation TODO

Template Sentence “QualityRequirement constrains Process”

7.1.50 ProcessEnabling (Relationship)

Shows which environment process is enabled by a feature of the system under construc-

tion.

Generalizations

•URMLModelRelationship

85

7 Appendix

Description A system enables certain processes of the environment with its features

(e.g. the photocopier enabled selling copies in copy shops). This is especially of interest

for a system under construction, as its usability and proﬁtability has to be defended.

This relationship allows to link environment processes with features and thus helps with

this task.

Attributes

•No additional attributes.

Role Names and Cardinalities

enabledProcess: EnvironmentProcess[1]

enablingFeature: Feature[1]

Notation TODO

Template Sentence “Feature enables EnvironmentProcess”

7.1.51 ProcessExtension (Relationship)

Lets a process extend another.

Generalizations

•URMLModelRelationship

Description Process extension is a well-known concept incorporated from the UML

(which incorporated Jacobson’s use case approach). Process extension expresses optional

or exceptional behavior of process. This behavior is speciﬁed by the extending process.

Attributes

•No additional attributes.

Role Names and Cardinalities

extendingProcess: Process[1]

extendedProcess: Process[1]

Notation TODO

Template Sentence “Process extends Process”

86

7.1 URML Abstract Syntax Speciﬁcation

7.1.52 ProcessInclusion (Relationship)

Lets a process include another.

Generalizations

•URMLModelRelationship

Description Process inclusion also is a well-known concept incorporated from the UML

(see ProcessExtension). Process inclusion allows the decomposition of processes. So a

complex process can be assembled from simpler subprocesses. How the subprocesses

interact with each other can be modeled through the precedence relationship (see Pro-

cessPrecedence). The URML does not support partial decomposition, so the behavior of

an including process is fully speciﬁed by its included and extending processes.

Attributes

•No additional attributes.

Role Names and Cardinalities

includingProcess: Process[1]

includedProcess: Process[1]

Notation TODO

Template Sentence “Process includes Process”

7.1.53 ProcessPrecedence (Relationship)

Shows the order of processes.

Generalizations

•URMLModelRelationship

Description This relationships enables a partial ordering of processes. While the URML

is not as powerful regarding control ﬂow modeling as the BPMN or UML Activity di-

agrams, it oﬀers modeling a sequence of processes through this relationship. Processes

can also occur in parallel. Decision gates are not supported. Detailed control ﬂow should

be left to the designer of the system under construction. The URML attempts to oﬀer

a basic set of control ﬂow modeling features because precedence might be important

for understanding certain requirements, whose formulation would imply that one pro-

cess executes before another. The precedence relationship is also useful in combination

with the information ﬂow relationship (see InformationFlow). The modeler can see how

information can be routed through the system.

87

7 Appendix

Attributes

•No additional attributes.

Role Names and Cardinalities

precedingProcess: Process[1]

precededProcess: Process[1]

Notation TODO

Template Sentence “Process precedes Process”

7.1.54 ProcessRequirement (Relationship)

Generalizations

•URMLModelRelationship

Description TODO

Attributes

•No additional attributes.

Role Names and Cardinalities

detailedProcess: Process[1]

detailingFunctionalRequirement: FunctionalRequirement[1]

Notation TODO

Template Sentence “Process requires FunctionalRequirement”

7.1.55 Product (Class)

Generalizations

•URMLModelEntity

Description Something that is marketed or sold. It may be a physical entity that is

manufactured or may be a set of services. Through the ’upcoming’ attribute, it can be

indicated whether the product already exists or if it is a future product

88

7.1 URML Abstract Syntax Speciﬁcation

Attributes

•upcoming: Boolean

Inherited Attributes

•description (from URMLModelElement)

•name (from URMLModelEntity)

Notation The overall icon consists of a base icon that is ﬁlled with diﬀerent content

depending on the value of the upcoming attribute. The base icon is a three-dimensional

box. If upcoming is set to true, the front side has square shape, if it is set to false, a

cloud is on the front side.

Figure 7.35: Existing

Product

icon

Figure 7.36: Upcoming

Product

icon

7.1.56 ProductLine (Class)

Generalizations

•URMLModelEntity

Description A product line deﬁnes a set of products sharing a common managed set of

features that satisfy the speciﬁc needs of a selected market. A product line points to the

root of a feature tree. The feature tree of the product line describes all possible current

and future product features that are used to deﬁne products from the product line.

Attributes

•No additional attributes.

Inherited Attributes

•description (from URMLModelElement)

•name (from URMLModelEntity)

89

7 Appendix

Notation The icon depicts a large box on which three smaller boxes are standing, one

of them being taller than the other two.

Figure 7.37: ProductLine icon

7.1.57 ProductLineAggregation (Relationship)

Shows the parent of a product line in a multi-leveled product line.

Generalizations

•URMLModelRelationship

Description Product lines may contain other product lines (e.g. in car manufacturing, a

company may have diﬀerent brands, each forming its own product line, but still member

of the company-wide car product line.). This relationship shows to which product line a

certain product line belongs to.

Attributes

•No additional attributes.

Role Names and Cardinalities

containingProductLine: ProductLine[1]

containedProductLine: ProductLine[1]

Notation TODO

Template Sentence “ProductLine contains ProductLine”

7.1.58 ProductLineContainment (Relationship)

Shows which product line the product belongs to.

Generalizations

•URMLModelRelationship

90

7.1 URML Abstract Syntax Speciﬁcation

Description This relationship allows to show which product line a product was created

from. A product can only be part of one product line (implicit participation through the

product line aggregation relationship not counting).

Attributes

•No additional attributes.

Role Names and Cardinalities

containingProductLine: ProductLine[1]

containedProduct: Product[1]

Notation TODO

Template Sentence “Product is part of ProductLine”

7.1.59 ProductSuite (Class)

Generalizations

•URMLModelEntity

Description A product suite is group of products that complement each other and can

be marketed as a complete set, e.g., the Microsoft Oﬃce Suite.

Attributes

•No additional attributes.

Inherited Attributes

•description (from URMLModelElement)

•name (from URMLModelEntity)

Notation The icon depicts three three-dimensional boxes, each with a tool inside. One

box is standing on the two others.

Figure 7.38: ProductSuite icon

91

7 Appendix

7.1.60 ProductSuiteContainment (Relationship)

Shows if a product is member of a product suite.

Generalizations

•URMLModelRelationship

Description This relationship allows indicating the membership of a product in product

suites. This means that the product is or will be sold in a bundle with the other products

of the product suite.

Attributes

•No additional attributes.

Role Names and Cardinalities

containingProductSuite: ProductSuite[1]

productSuiteMember: Product[1]

Notation TODO

Template Sentence “Product is member of ProductSuite”

7.1.61 QualityRequirement (Class)

Generalizations

•Requirement

Description A quality requirement is a class of requirement describing a constraint on

the operation of a product, process or service, e.g. performance, environmental, quality.

The type of the quality requirement is speciﬁed by an enumeration type, that is mostly

inspired by ISO 9126 categories. A quality requirement may constrain the system or its

environment: it can constrain a process (i.e. it constrains either business processes or

use cases), and, on a higher level of abstraction, features.

Attributes

•type: QualityRequirementType

92

7.1 URML Abstract Syntax Speciﬁcation

Inherited Attributes

•costDriver (from Requirement)

•description (from URMLModelElement)

•name (from URMLModelElement)

•priority (from Requirement)

•rank (from Requirement)

•regulatory (from Requirement)

Notation The overall icon consists of a base icon which is modiﬁed depending on the

value of the type attribute and that is decorated with an overlay icon if the value of the

regulatory attribute is set to true. The base icon depicts a diamond. The modiﬁcation

depending on the type is an uppercase letter which is the ﬁrst letter of the type literal.

In the case of the project execution type, a deviation from this rule exists as the letter

’P’ was already taken by the portability type. In this case, two crossed tools (hammer

and wrench) are depicted “inside” the diamond. The regulatory overlay depicts a police

oﬃcer.

93

7 Appendix

Figure 7.39: Uncategorized

QualityRequire-

ment icon

Figure 7.40: Uncategorized,

Regulatory Qual-

ityRequirement

icon

E

Figure 7.41: Eﬃciency Qual-

ityRequirement

icon

E

Figure 7.42: Eﬃciency, Regu-

latory QualityRe-

quirement icon

F

Figure 7.43: Functionality

QualityRequire-

ment icon

F

Figure 7.44: Functionality,

Regulatory Qual-

ityRequirement

icon

M

Figure 7.45: Maintainability

QualityRequire-

ment icon

M

Figure 7.46: Maintainability,

Regulatory Qual-

ityRequirement

icon

94

7.1 URML Abstract Syntax Speciﬁcation

P

Figure 7.47: Portability Qual-

ityRequirement

icon

P

Figure 7.48: Portability, Regu-

latory QualityRe-

quirement icon

Figure 7.49: ProjectExecution

QualityRequire-

ment icon

Figure 7.50: ProjectExecution,

Regulatory Qual-

ityRequirement

icon

R

Figure 7.51: Reliability Qual-

ityRequirement

icon

R

Figure 7.52: Reliability, Regu-

latory QualityRe-

quirement icon

U

Figure 7.53: Usability Qual-

ityRequirement

icon

U

Figure 7.54: Usability, Regu-

latory QualityRe-

quirement icon

95

7 Appendix

7.1.62 QualityRequirementType (Enumeration)

Categorized Class

•QualityRequirement

Enumeration Literals

•Functionality

•Reliability

•Usability

•Eﬃciency

•Maintainability

•Portability

•Project Execution

•Uncategorized

Description Most of the enumeration literals where adapted from ISO 9126. Therefore,

the ISO’s deﬁnitions are usually directly cited from [19]. Where appropriate, additional

explanations were added.

Functionality: Incorporated from ISO 9126: “Functionality quality requirements target

the functional suitability of the system. They provide a metric to determine

whether the system is appropriate to its users.” Entails suitability, accuracy,

and interoperability. The ISO 9126 standard also includes security, which is

addressed by mitigating requirements in the URML.

Reliability: Incorporated from ISO 9126: “The capability of the [...] product to main-

tain a speciﬁed level of performance when used under speciﬁed conditions.”

Entails maturity, fault tolerance, and recoverability.

Usability: Incorporated from ISO 9126: “The capability of the [...] product to be un-

derstood, learned, used and attractive to the user, when used under speciﬁed

conditions.” Entails understandability, learnability, operability, and attrac-

tiveness.

Eﬃciency: Incorporated from ISO 9126: “The capability of the [...] product to provide

appropriate performance, relative to the amount of resources used, under

stated conditions.” Entails time behavior and resource utilization.

96

7.1 URML Abstract Syntax Speciﬁcation

Maintainability: Incorporated from ISO 9126: “The capability of the [...] product to be

modiﬁed. Modiﬁcations may include corrections, improvements or adaptation

of the software to changes in environment, and in requirements and functional

speciﬁcations.” Entails analysability, changeability, stability, and testability.

Portability: Incorporated from ISO 9126: “The capability of the [...] product to be

transferred from one environment to another.” Entails co-existence and re-

placeability.

ProjectExecution: Quality requirement that constrains the process of creating the system

under discussion. All others are constraints to the system under discussion

itself.

Uncategorized: The category of the quality requirement is yet to be determined.

Notation See notation section of QualityRequirement (Class).

7.1.63 Request (Class)

Generalizations

•URMLModelEntity

Description Asking for something to be part of or a constraint on a system. Requests,

which are wishes and suggestions expressed by stakeholders. Requests can also yield

requirements.

Attributes

•No additional attributes.

Inherited Attributes

•description (from URMLModelElement)

•name (from URMLModelEntity)

Notation The icon depicts a person raising a hand with a speech bubble that has a

question mark inside.

?

Figure 7.55: Request icon

97

7 Appendix

7.1.64 RequestStatement (Relationship)

Shows which stakeholder expressed a request.

Generalizations

•URMLModelRelationship

Description This relationships allows the mapping of stakeholders to requests. Thus

it can be analyzed who was the source of a request or if multiple stakeholders uttered a

similar request.

Attributes

•No additional attributes.

Role Names and Cardinalities

issuingStakeholder: Stakeholder[1]

statedRequest: Request[1]

Notation TODO

Template Sentence “Stakeholder expresses Request”

7.1.65 RequestCause (Relationship)

Allows analysis of the goal behind a request.

Generalizations

•URMLModelRelationship

Description Requests do not come out of the void. While they may be motivated by

general knowledge (i.e. ideas; see motivation relationship) they can also be there because

a stakeholder has a certain goal in mind. If this can be detected during elicitation, this

relationship can be used to indicate which goal is behind a stakeholder request.

Attributes

•No additional attributes.

98

7.1 URML Abstract Syntax Speciﬁcation

Role Names and Cardinalities

backdropGoal: Goal[1]

resultingRequest: Request[1]

Notation TODO

Template Sentence “Goal results in Request”

7.1.66 RequestRealization (Relationship)

Shows which requirement addresses a stakeholder request.

Generalizations

•URMLModelRelationship

Description In order to be able to show stakeholders how their requests are addressed,

this relationships enables the mapping of requirements to requests.

Attributes

•No additional attributes.

Role Names and Cardinalities

originatedRequest: Request[1]

resultingRequirement: Requirement[1]

Notation TODO

Template Sentence “Feature realizes Request”

7.1.67 Requirement (Abstract Class)

Abstract class representing the communalities of functional and quality requirements.

Generalizations

•URMLModelEntity

99

7 Appendix

Description Requirements are properties or qualities the system needs to fulﬁll. They

can be ranked and prioritized. Requirement itself is an abstract entity, either is special-

ized to describe desired functionality (i.e. functional requirement) or quality of the system

(i.e. quality requirement). Requirements can be involved in the mitigation of dangers

(See RequirementMitigation). Requirements can be decomposed into sub-requirements

through a reﬁnement relationship. Any requirement can be imposed by a regulatory

body. A requirement can be marked being a cost driver.

Attributes

•costDriver: Boolean

•priority:

•rank:

•regulatory: Boolean

Inherited Attributes

•description (from URMLModelElement)

•name (from URMLModelEntity)

7.1.68 RequirementMitigation (Relationship)

Protects a harmed element from danger through a requirement.

Generalizations

•Mitigation

Description When a danger leads to a formulation of a system requirement, this is

expressed by a requirement mitigation relationship. This means that the danger is mit-

igated technically, i.e. a requirement is formulated that makes the system prepared for

the danger.

Attributes

•No additional attributes.

Role Names and Cardinalities

mitigatedDanger: Danger[1]

protectedHarmedElement: HarmedElement[1]

mitigatingRequirement: Requirement[1..*]

100

7.1 URML Abstract Syntax Speciﬁcation

Notation TODO

Template Sentence “Requirement protects HarmedElement from Danger”

7.1.69 RequirementReﬁnement (Relationship)

Generalizations

•URMLModelRelationship

Description TODO

Attributes

•No additional attributes.

Role Names and Cardinalities

reﬁningRequirement: Requirement[1]

reﬁnedRequirement: Requirement[1]

Notation TODO

Template Sentence “Requirement reﬁnes Requirement”

7.1.70 ServiceContainment (Relationship)

Indicates which service provider is used by the system under discussion.

Generalizations

•URMLModelRelationship

Description The system under discussion can make use of other systems, for which

a black box view is provided through the service provider concept. This relationship

connects service providers with the system under discussion. It thus enables modeling the

use of components internal to the system. This is important for planning the embedment

of commercial-oﬀ-the-shelf (COTS) components into the system but also for staﬃng in

systems in which persons play an active role.

Attributes

•No additional attributes.

101

7 Appendix

Role Names and Cardinalities

systemUnderDiscussion: SystemUnderDiscussion[1]

internalService: ServiceProvider[1]

Notation TODO

Template Sentence “SystemUnderDiscussion uses ServiceProvider”

7.1.71 ServiceProvider (Class)

An internal component of the system that is either another system, software, or a human.

Generalizations

•HarmedElement

•System

Description A service provider is a part of the system under discussion and a system

by itself. It oﬀers services to the outside through use cases. Each use case should have

at least one controlling service provider instance (a.k.a. ’control object’). As it is part

of the system, it may be harmed by a Hazard that aﬀects the system. It is categorized

by its ServiceProviderType as either Human, System, or Software.

Attributes

•type: ServiceProviderType

Inherited Attributes

•description (from URMLModelElement)

•name (from URMLModelEntity)

Notation The icon, under all circumstances, depicts a platter with two tools on it. If

the category is not set, a black box is depicted to the left of the platter1. If the category

is ’Human’ then a person is carrying the platter. If it is ’System’, a robot is carrying the

platter. If it is ’Software’, the platter stands on top of a computer box, right to a display.

102

7.1 URML Abstract Syntax Speciﬁcation

Figure 7.56: Uncategorized

ServiceProvider

icon

Figure 7.57: Human Service-

Provider icon

Figure 7.58: Software Service-

Provider icon

Figure 7.59: System Service-

Provider icon

7.1.72 ServiceProviderType (Enumeration)

Categorized Class

•ServiceProvider

Enumeration Literals

•Human

•Software

•System

•Uncategorized

Description

Human - A person is providing the service.

Software - A software system is providing the service.

System - A system is providing the service. The system service provider is used

for mixed-type systems, possibly including mechanical components, software

components, and humans.

Uncategorized - The type of system is not yet determined.

103

7 Appendix

Notation See notation section of ServiceProvider (Class).

7.1.73 SoftGoal (Class)

Generalizations

•AbstractGoal

Description An objective expressed by a stakeholder that should be achieved by the

system in operation. In contrast to a goal, a soft goal’s realization is not testable.

Attributes

•No additional attributes.

Inherited Attributes

•description (from URMLModelElement)

•name (from URMLModelEntity)

Notation The icon depicts a cloud which is a target for an arrow.

Figure 7.60: SoftGoal icon

7.1.74 Stakeholder (Class)

Generalizations

•URMLModelEntity

•HarmedElement

Description Someone or something (e.g. a regulatory agency) interested in the deﬁned

or to be deﬁned system, its product(s) or process(es). A stakeholder can either be an

actor, a user of the system, a Customer, who is a person that pays for the system, or

a BusinessStakeholder, which is any person with a commercial interest in the projects

success. Stakeholders can form hierarchies, which can be expressed by means of the

reports to relationship. They also have diﬀerent importance, expressed by the weight

attribute. Stakeholder utterances can be formalized in diﬀerent ways. They can be

goals, requests, or ideas. Stakeholders have assets that may be harmed by dangers,

which is of importance when evaluating the severity of a danger.

104

7.1 URML Abstract Syntax Speciﬁcation

Attributes

•weight:

Inherited Attributes

•description (from URMLModelElement)

•name (from URMLModelEntity)

Notation The icon depicts a person with a speech bubble that has an exclamation mark

inside.

!

Figure 7.61: Stakeholder icon

7.1.75 StakeholderHierarchy (Relationship)

A hierarchical relationship that indicates who reports to whom.

Generalizations

•URMLModelRelationship

Description The stakeholders of a system might themselves have certain relationships

to each other. This relationship links two stakeholders, where one stakeholder is reporting

to the other. This helps with a trade-oﬀanalysis of the diﬀerent stakeholder’s statements.

Attributes

•No additional attributes.

Role Names and Cardinalities

reportingStakeholder: Stakeholder[1]

superiorStakeholder: Stakeholder[1]

Notation TODO

Template Sentence “Stakeholder reports to Stakeholder”

105

7 Appendix

7.1.76 System (Abstract Class)

Generalizations

•URMLModelEntity

Description A system is an abstract concept that is characterized by its boundary

objects (indicating how it can be used). A system can interact with other systems

through their boundary objects which enables initiation of or participation in processes

of the other system.

Attributes

•No additional attributes.

Inherited Attributes

•description (from URMLModelElement)

•name (from URMLModelEntity)

7.1.77 SystemEmbedment (Relationship)

Shows in which environment process the system under discussion is embedded.

Generalizations

•URMLModelRelationship

Description The system under discussion oﬀers features that enable environment pro-

cesses. Not all environment processes that are modeled are using the system under

discussion. Some of them might be part of the model because they trigger dangers.

Thus, there is a need to highlight which of the environment processes actually uses the

system.

Attributes

•No additional attributes.

Role Names and Cardinalities

embeddedSystem: SystemUnderDiscussion[1]

environmentProcess: EnvironmentProcess[1]

Notation TODO

106

7.1 URML Abstract Syntax Speciﬁcation

Template Sentence “SystemUnderDiscussion is used in EnvironmentProcess”

7.1.78 SystemFunction (Relationship)

Shows the functions of a system in terms of behavior.

Generalizations

•URMLModelRelationship

Description Apart from the functional requirements, use cases constitute the functional

behavior of the system under discussion. This relationship links a use case with the

system under discussion it is a function of.

Attributes

•No additional attributes.

Role Names and Cardinalities

systemOfFunction: SystemUnderDiscussion[1]

functionOfSystem: UseCase[1]

Notation TODO

Template Sentence “SystemUnderDiscussion has UseCase”

7.1.79 SystemInteraction (Relationship)

Shows how an external system interacts with the system under discussion’s processes via

boundary objects.

Generalizations

•URMLModelRelationship

Description The SystemInteraction relationship describes how systems interact, from

the viewpoint of a system under discussion. An instance of such a relationship shows

through which boundary object a system initiates a process of another system or takes

part in a process of another system. As the internal workings of another system are

out of scope for the system under discussion2, the acting system usually is an instance

of a service provider or an actor. The interaction with a service provider shows how

the system under discussion uses components of which the modeler only has a black-box

view. The interaction with the actor shows how the system under discussion is embedded

in its environment.

2If absolutely needed, these can be modeled in a separate URML model.

107

7 Appendix

Attributes

•type: SystemInteractionType

Role Names and Cardinalities

actingSystem: System[1]

usedBoundaryObject: BoundaryObject[1]

executedProcess: Process[1]

Notation TODO

Template Sentence “System interacts with Process via BoundaryObject”

7.1.80 SystemInteractionType (Enumeration)

Categorized Class

•SystemInteraction

Enumeration Literals

•Initiate

•Participate

Description In order to diﬀerentiate between process initiation and process participa-

tion, the SystemInteraction has an attribute ’type’ typed by this enumeration.

7.1.81 SystemInterest (Relationship)

Connects a stakeholder with a system he/she is interested in.

Generalizations

•URMLModelRelationship

Description In stakeholder analysis, a set of stakeholders of the system under discussion

is determined. As the URML potentially allows modeling multiple systems at once, there

is a need to map stakeholders to systems. This relationship connects a stakeholder with

the system under discussion he/she is interested in.

Attributes

•No additional attributes.

108

7.1 URML Abstract Syntax Speciﬁcation

Role Names and Cardinalities

interestedStakeholder: Stakeholder[1]

systemOfInterest: SystemUnderDiscussion[1]

Notation TODO

Template Sentence “Stakeholder has interest in SystemUnderDiscussion”

7.1.82 SystemUnderDiscussion (Class)

Generalizations

•System

Description The system under discussion is the central entity of the model. This is

the system for which requirements shall be elicited. A system under discussion has

stakeholders which have an interest in it. It is embedded in the customer’s (which is

one of the stakeholders) environment (which is model via EnvironmentProcess). The

function it oﬀers to its actors are modeled via use cases. For requirements elicitation,

no detailed subsystem decomposition is done yet. It shall however be visible if persons,

other systems, or software are relied upon by the system (which is modeled through

containment of service providers).

Attributes

•No additional attributes.

Inherited Attributes

•description (from URMLModelElement)

•name (from URMLModelEntity)

Notation The icon depicts three gears, the ones on the lower left and the upper right

only shown partially, both being black. The one in the center is white. The icon has a

rectangular bounding box.

Figure 7.62: SystemUnderDiscussion icon

109

7 Appendix

7.1.83 TestDescription (Relationship)

Connects a goal with a description how it might be tested.

Generalizations

•URMLModelRelationship

Description This relationship connects an assessment sketch with a goal. A goal that

has no connected assessment sketch is either incomplete or should be a soft goal.

Attributes

•No additional attributes.

Role Names and Cardinalities

testableGoal: Goal[1]

possibleTest: AssessmentSketch[1]

Notation TODO

Template Sentence “AssessmentSketch outlines test case of Goal”

7.1.84 Threat (Class)

Generalizations

•Danger

Description Potential cause of loss of assets (e.g. ﬁnancial as opposed to physical

harm). Dangers posing such risk are modeled as threats.

Attributes

•No additional attributes.

Inherited Attributes

•description (from URMLModelElement)

•name (from URMLModelEntity)

110

7.1 URML Abstract Syntax Speciﬁcation

Notation The icon depicts a person’s head with a mask and a bag with coins in it.

Figure 7.63: Threat icon

7.1.85 URMLModel (Class)

Generalizations

•None

Description URMLModel is the unique starting symbol used for checking grammatical

correctness of an URML model. It also is the top level container of such a model, directly

or indirectly containing all its elements.

Attributes

•name: String

•description: String

7.1.86 URMLModelElement (Abstract Class)

Generalizations

•None

Description URMLModelElement is the abstract superclass of all elements of a URML

model. Model elements are classiﬁed into entities and relationships.

Attributes

•description: String

Inherited Attributes

•None

7.1.87 URMLModelEntity (Abstract Class)

Generalizations

•URMLModelElement

111

7 Appendix

Description URMLModelEntity is the abstract superclass of all classes in the URML

meta-model that are not inheriting from another class (e.g. FunctionalRequirement is

a subclass of Requirement which in turn is a subclass of URMLModelElement). This

allows delineating the URML model entities from other models (e.g. SysML models) in

CASE tools that allow the mixing of multiple visual notations.

Attributes

•name: String

Inherited Attributes

•description (from URMLModelElement)

7.1.88 URMLModelRelationship (Abstract Relationship)

Abstract superclass of all relationships deﬁned by the URML.

Generalizations

•None

Description URMLModelRelationship is the abstract superclass of all relationships de-

ﬁned by the URML. This allows delineating the URML model relationships from other

models (e.g. SysML models) in CASE tools that allow the mixing of multiple visual

notations.

Attributes

•No additional attributes.

Role Names and Cardinalities

TODO

7.1.89 UseCase (Class)

Generalizations

•URMLModelElement

112

7.1 URML Abstract Syntax Speciﬁcation

Description A use case describes the use of a system from the perspective of the user(s)

(i.e. actors). The actor’s interaction with the system (i.e. a use case) always goes

through a boundary object. The sequence of steps that a use case entails is modeled

through included (always taking place) and extended use cases (optional or exceptional

behavior). This is inherited from the abstract superclass Process. Use cases may be part

of a business process and thus describe the interactions with other systems. From the

business process perspective, a use case provides a white box view into the system. Use

cases detail features, which means they describe the functions of the system on a more

detailed level.

Attributes

•No additional attributes.

Inherited Attributes

•atomic (from Process)

•businessProcess (from Process)

•description (from URMLModelElement)

•name (from URMLModelEntity)

•preCondition (from Process)

•postCondition (from Process)

•underConstruction (from Process)

Notation The overall icon consists of a base icon that is decorated by overlays. The

base icon consists of an oval, inside which a person and a computer are depicted. Below

them are two stylized arrows pointing in opposite directions. If the use case is atomic,

a dot is placed on the lower right of the icon. If the use case is under construction, a

yellow-and-black striped road barrier is placed on the lower center.

113

7 Appendix

Figure 7.64: UseCase icon Figure 7.65: Atomic UseCase

icon

Figure 7.66: Under construction UseCase icon

7.1.90 Vulnerability (Relationship)

A weak point of a process that might be misused by malicious attacks.

Generalizations

•URMLModelRelationship

Description A vulnerability indicates that a process might be misused and thus could

be the source of danger.

Attributes

•No additional attributes.

Role Names and Cardinalities

possibleDanger: Danger[1]

vulnerableProcess: Process[1]

Notation TODO

Template Sentence “Process is vulnerable to Danger”

114

7.2 URML Meta-Model Diagrams

atomic : Boolean

preCondition : String

postCondition : String

underConstruction : Boolean

businessProcess : Boolean

«class»

Process

*

probability: Enum

severity: Enum

«class»

Danger

1

*

1

*

1

*

«class»

Environment

Process

«class»

UseCase

atomic : boolean

«class»

EntityObject

«class»

Boundary

Object

«class»

Quality

Requirement

«class»

Functional

Requirement

«class»

Feature

*

1

«class»

System

*

1*

1

Use

Modify

Create

Delete

Uncategorized

«enumeration»

InformationFlow

Typ e

type: InformationFlowType

«association»

InformationFlow

«class»

SystemUnder

Discussion

*

1

*

1

Initiation

Participation

«enumeration»

SystemInteraction

Typ e

"interacts via ▶"

type : SystemInteractionType

«association»

SystemInteraction

1

*

«association»

System

Function

"has"

▼

«association»

SystemEmbedment "used in"

▼

*

11

*

1

1*

1

*

1

"details"

▼

«association»

Feature

Description

UseCase ▲

"enables"

«association»

Process

Enabling

1

*

1

*

◀ "triggers"

«association»

DangerTrigger

*

▲

"constrains"

«association»

Process

Constraint

"requires"

▼

«association»

Process

Requirement

*

1

*

1

*

1

"extends"▶

«association»

Process

Extension

◀ "includes"

«association»

Process

Inclusion

◀ "precedes"

«association»

Process

Precedence

*

1

*

1

*

1

+description: String

«association»

Vulnerabilty

◀ "is vulnerable to"

Figure 7.67: Excerpt of the URML meta-model dealing with use cases and environment

processes

115

7 Appendix

«class»

Goal

weight: int

«class»

Stakeholder

1

*

«class»

Actor

«class»

Business

Stakeholder

«class»

Customer

«class»

AbstractGoal

«class»

Softgoal

«class»

Request

1

*

1

*

1

source: URI

«class»

Idea

1

*

1

*

«association»

Motivation

«association»

Mention

1

*

1

*

◀"reports to"

«association»

Stakeholder

Hierarchy

"expresses"

▼

«association»

GoalStatement

▲

"results in"

«association»

RequestCause

◀"expresses"

«association»

Request

Statement

*

1

*

1 1

*

1

«interface»

HarmedElement

type : AssetType

«class»

Asset

1

▼"has"

«association»

AssetOwnership

1

*

Financial

Identity

Property

Uncategorized

«enumeration»

AssetType

◀"mentions"

"results in"

▼

Figure 7.68: Excerpt of the URML meta-model dealing with stakeholders

116

7.2 URML Meta-Model Diagrams

«class»

Goal

weight: int

«class»

Stakeholder

+ + (Make)

+ (Help)

? (Unknown)

- (Hurt)

- - (Break)

«enumeration»

GoalContribution

Typ e

*

«class»

Actor

«class»

Business

Stakeholder

«class»

Customer

«class»

AbstractGoal

«class»

Feature

1

*

1

1*

«association»

GoalDecomposition

«class»

Softgoal

«class»

Assessment

Sketch

1 *

«class»

Request

1

*

1

*

1

type: GoalContributionType

«association»

GoalContribution

◀"realizes"

«association»

GoalRealization

"expresses"

▼

«association»

GoalStatement

▲

"results in"

«association»

RequestCause

◀"outlines test case of"

«association»

TestDescription

1

*

1

* 1

*

1

Figure 7.69: Excerpt of the URML meta-model dealing with goals

117

7 Appendix

atomic : Boolean

preCondition : String

postCondition : String

underConstruction : Boolean

businessProcess : Boolean

«class»

Process

type : ServiceProviderType

«class»

ServiceProvider «class»

Environment

Process

«class»

UseCase

«class»

Boundary

Object

«class»

Actor

«class»

System

«class»

SystemUnder

Discussion

*

1

«association»

ServiceContainment

"uses ▶"1

*

«association»

BoundaryObject

Containment

"has ▶"

1

*

1

*

1

Initiation

Participation

«enumeration»

SystemInteraction

Typ e

"interacts via ▶"

type : SystemInteractionType

«association»

SystemInteraction

1

*

«association»

System

Function

"has"

▼

«association»

SystemEmbedment "used in"

▼

*

1

*

1

Figure 7.70: Excerpt of the URML meta-model dealing with aspects of system modeling

7.2 URML Meta-Model Diagrams

7.3 Pseudo-Algorithm for the simpliﬁcation of the

meta-model

The meta-model of the URML is very complex, thus it is hard to see an underlying

structure at ﬁrst sight. To help with understanding that structure, a pseudo-algorithm

for the simpliﬁcation of the model was designed.

Algorithm 7.1 Pseudo-code describing how the URML meta-model can be simpliﬁed.

1. Decide upon the members of the simpliﬁed meta-model and put them into the simpli-

ﬁed model. Let’s name them ’essential classes’.

2. For every essential class

* if the name starts with "Abstract", remove the preﬁx "Abstract" from the name

* From the complete meta-model, ﬁnd the direct connections of the according meta-class

or one of its subclasses to another member of the simpliﬁed meta-model or one of its

subclasses

* if there is no connection between such two members (in the simpliﬁed model), and a

direct connection was found, connect the two in the simpliﬁed model

* ﬁnd a label that generalizes the relationship between the two essential classes. If this

is semantically not possible, use two diﬀerent labels

118

7.3 Pseudo-Algorithm for the simpliﬁcation of the meta-model

weight: int

«class»

Stakeholder

«class»

Process

«interface»

HarmedElement

regulatory: Boolean

«class»

Requirement

Human

System

Software

Uncharacterized

«enumeration»

ServiceProvider

Typ e

probability: Enum

severity: Enum

«class»

Danger

*

1

1..* *

1

1..*

seismical

meteorological

biological

chemical

radiological

mechanical

electrical

social

uncategorized

«enumeration»

HazardType

+description: String

«association»

Vulnerabilty

◀ triggers

type : ServiceProviderType

«class»

ServiceProvider

type : HazardType

«class»

Hazard

«class»

Threat

«association»

Mitigation

«association»

Procedural

Mitigation

«association»

Requirement

Mitigation

«class»

EnvironmentProcess

«class»

UseCase

type : AssetType

«class»

Asset

«class»

Quality

Requirement

«class»

Functional

Requirement

*

1

*

1

Financial

Identity

Property

Uncategorized

«enumeration»

AssetType

*

1

«class»

Procedure

1

1..*

«association»

Harm

"harms▶"

*

1..*

«association»

DangerTrigger

◀has

«association»

AssetOwnership *

1

*

Figure 7.71: Excerpt from the URML meta-model dealing with dangers

119

7 Appendix

*

1

*

1

«class»

Environment

Process

«class»

UseCase

root : Boolean

selectionType: FeatureSelectionType

underConstruction : Boolean

«class»

FeatureGroup

«class»

AbstractFeature

«class»

ProductLine

upcoming: Boolean

«class»

Product

All

Exclusive

Any

«enumeration»

FeatureSelection

Typ e

parent

*

«class»

ProductSuite

1

*

1

*

1

«comment»

Only one root

allowed for the

whole system!

«association»

ProductLine

Containment

«association»

ProductSuite

Containment

"requires"▶

«association»

FeatureRequirement

"excludes"▶

«association»

FeatureExclusion

mandatory : Boolean

«association»

FeatureSelection

Options

«association»

ProductLine

Aggregation

«association»

FeatureTree

▲

"details"

«association»

FeatureDescription

UseCase "enables"

▼

«association»

ProcessEnabling

*

1

core: Boolean

«class»

Feature 1 1

1

*

«association»

FeatureList

"has" ▶

*

1

*

1

*

1

*

1

0..1

1

*

1

*

1

*

1

Figure 7.72: Excerpt from the URML meta-model dealing with features and product lines

120

7.3 Pseudo-Algorithm for the simpliﬁcation of the meta-model

priority: Integer

rank: Integer

regulatory: Boolean

costDriver: Boolean

«class»

Requirement

«class»

Request

1

*

"results in"

▼

«association»

RequestRealization

1

*

1

1..*

«association»

Requirement

Mitigation

«class»

Quality

Requirement

«class»

Functional

Requirement

probability: Enum

severity: Enum

«class»

Danger

*

«association»

Mitigation

1

*

1

"constrains"

▼

«association»

FeatureConstraint

core: Boolean

«class»

Feature

*

1

*

1

«association»

FeatureDescription

Requirement

▲

"details"

«class»

AbstractGoal

1

*

1

▲

"realizes"

«association»

GoalRealization

▲

"results in"

«association»

RequestCause

1

*

1

atomic : Boolean

preCondition : String

postCondition : String

«class»

Process

*

1

▲

"constrains"

«association»

ProcessConstraint

"requires"

▼

«association»

ProcessRequirement *

1

*

1

*

1

Figure 7.73: Excerpt from the URML meta-model including the core requirements ratio-

nale modeling features

121

Draft URML Abstract Syntax Specification (Excerpt from my in progress thesis)

Abstract and Figures

Recommended publications

Unknown

Abstract Syntax and Normalisation of AKL Programs

Knowledge-Based Systems : Formalisation and Application to Insurance

Non-Functional Requirements in Architectural Decision-Making