standardizing methodology metamodelling and notation: an iso exemplar

©B. Henderson-Sellers, 2008 1

Standardizing Methodology Metamodelling and Notation:

An ISO Exemplar

UNISCON Keynote

April 25 2008

Brian Henderson-SellersDirector, COTAR

University of Technology, Sydneywww-staff.it.uts.edu.au/~brian

email: [email protected][with thanks to Dr Cesar Gonzalez-Perez]


Preview

• I. The need for standardization

• II. Metamodelling basics

• III. Exemplar: ISO/IEC 24744

• IV. Adding a notation

• V. Using the standard (method construction)

• VI. In summary


I. The Need for Standardization

• Organization operates in an orderly and structure way (not everyone doing their own thing)

• Efficient utilization of time, money and people• Potential streamlining of processes• Systematization• Interoperability• Benefits of following the same approach

(standard) – interchange of staff


The Need for Standardization -2

• Consensus on terminology

• Standardized symbols

• Contract negotiation

• Able to compete in a broader market

• External image of company as trading according to international standards


A few relevant ISO standards

• ISO/IEC 12207 (software lifecycle processes)

• ISO/IEC 15288 (system lifecycle processes)

• ISO/IEC 15504 (process assessment)

• ISO/IEC TR 14143 (function points)

• ISO 9000 series

• ISO 24744 (methodology metamodel)


ISO Process

• SE standards in SC7 of JTC1 [ISO+IEC]• Several working groups (WG) in SC7 each

dealing with a group of standards• Development stages 6 months• National Bodies (NB) then comment• WG editors chair international group to

resolve all comments• WD CD DIS FDISIS


An Example ISO Standard (ISO/IEC 24744) – a methodology

metamodel• A methodology is used by software

developers (Method domain)

• It must be defined clearly – the role of the ISO standard

• It must be able to be executed on real projects (Endeavour domain)


II. Metamodelling Basics

A metamodel is at a higher level of abstraction than a model. It is often called “a model of models“. It provides the rules/grammar e.g. for a modelling language (ML) or a method engineering approach to method construction.


BankAccount

balance

withdraw (amount:Dollar)deposit (amount:Dollar)

Customer

address

Example model which uses the rules of UML metamodel


BankAccount

balance

deposit (amount:Dollar)

Customer

address

withdraw (amount:Dollar)

Example model which does not adhere to UML


AssociationClass

Classifier

Class Interface DataType

Association

AssociationEnd

aggregation

Attribute

StructuralFeature

Operation Method

BehaviouralFeature

Featurevisibility

1 *

GeneralizableElement

Node Component

Invariant

PostconditionPrecondition

Namespace

Artifact

stereotypeof constraint


Relationship

AssociationClass

AssociationClass

Classifier

Class Interface DataType

Association

AssociationEnd

aggregation

Attribute

StructuralFeature

Operation Method

BehaviouralFeature

Featurevisibility

1 *

GeneralizableElement

Node Component

Invariant

PostconditionPrecondition

Namespace

Artifact

stereotypeof constraintstereotypeof constraint


RelationshipRelationship

Example: part of a modelling language metamodel


WorkProduct

Architecture

WorkProductVersion

Application

SoftwareComponent

Document

Increment

Metric

Model

Requirement

0..*

{abstract}

{abstract}

Diagram{abstract}

StaticArchitecture

Diagram

DynamicBehaviorDiagram

ProcessMetric

QualityMetric

ComponentHardwareComponent

{abstract}

Convention

Plan

Procedure

Guideline

Standard

Template

Inspectionchecklist

0..1documents

U

U

documents

1..*

1..*+

{abstract}

0..*

1..*

1

{abstract}

Device

Computer

Network

Storage

Prototype

StaffingDescription

Schedule

+

ArchitectureDocument

RequirementsSpecification documents

documents

+ configurational,whole-part relationshipcontainment relationshipgeneralization relationship

U

KEY

WorkProduct

Architecture

WorkProductVersion

Application

SoftwareComponent

Document

Increment

Metric

Model

Requirement

0..*

{abstract}

{abstract}

Diagram{abstract}

StaticArchitecture

Diagram

DynamicBehaviorDiagram

ProcessMetric

QualityMetric

ComponentHardwareComponent

{abstract}

Convention

Plan

Procedure

Guideline

Standard

Template

Inspectionchecklist

Procedure

Guideline

Standard

Template

Inspectionchecklist

0..1documents

UU

UU

documents

1..*

1..*++

{abstract}

0..*

1..*

1

{abstract}

Device

Computer

Network

Storage

Prototype

StaffingDescription

Schedule

++

ArchitectureDocument

RequirementsSpecification documents

documents

+ configurational,whole-part relationshipcontainment relationshipgeneralization relationship

U

KEY

++ configurational,whole-part relationshipcontainment relationshipgeneralization relationship

UU

KEY

Example: part of a methodology metamodel


Method or Process Model

Metamodel

Process

Staticaspects

Dynamicaspects

As enacted byreal people on a specific project

As documented

As standardized

Method or Process Model

Metamodel

ProcessProcess

Staticaspects

Dynamicaspects

As enacted byreal people on a specific project

As documented

As standardized

In the

Endeavour

domain, a

process is

derived as an

instance of the

methodology

and then

happens in

real time.


M3

M2 Metamodel

M1Model

M0Data

instance_of

instance_of

instance_of

M3 (MOF) Metametamodel

M2 Metamodel

M1Model

M0Data

instance_of

instance_of

instance_of

M3

M2 Metamodel

M1Model

M0Data

instance_of

instance_of

instance_of

M3 (MOF) Metametamodel

M2 Metamodel

M1Model

M0Data

instance_of

instance_of

instance_of

A “simpler” version is promoted by the OMG

But enactment of processes is not possible


+name

Task

name = DefineOperations

ta1 : Task

«instanceOf»

do1 : DefineOperations

«instanceOf»

duration=50

duration:Time

duration:Time

+name

Task

name = DefineOperations

ta1 : Task

«instanceOf»

do1 : DefineOperations

«instanceOf»

duration=50

duration:Time

duration:Time

This means that this is an invalid UML diagram

Actually duration should begiven a value here


The ISO architecturerealigns the “levels” to practice

endeavour

method

metamodelActivity

WorkUnit

Task Technique

* *

methodologies assessment quality tools


Introduction to Powertypes

• “A user-defined metaelement whose instances are classes in the model” (OMG, page 3-61). In other words, a classifier whose instances are subtypes of another classifier.

• In UML, powertype is a stereotype of Classifier: «powertype»


ExampleTrees may be classified by species. Any

individual tree may be a gum, elm, plane etc. So we have

Tree

PlaneElmGum

TreeSpeciesis classified by


But

Gum, elm and plane are all instances of TreeSpecies (which sort of puts TreeSpecies at a higher metalevel, whilst remaining an M1 Class). Thus we get (next slide)


Tree

PlaneElmGum

TreeSpeciesis classified by

«instanceOf»

TreeSpecies is thus aPowertype of Tree


This leads to the notion of “clabject” – an entity that has both class and objectfacets

Name = “Elm”AvgHeight = 18Height: int

Elm TreeSpecies

Class facetObject facet


In terms of sets

xx

xx

xxx

x

xx

x

x

x

Sugar maple

ElmOak

Tree class

x

myFriend

TreeSpecies class

x

x

x sugar maple

elm

oak

TreeSpecies is a Powertype i.e. a set of all subsets of another set as defined by a given discriminator


xx

xx

xxx

x

xx

x

x

x

DevelopBOM

DesignUICoding

Task class TaskKind class

x

x

x DevelopBOM

Coding

DesignUI

TaskKind

DesignUIDesignUI Coding

Task

x

xx

xx

xxx

x

xx

x

x

x

DevelopBOM

DesignUICoding

Task class TaskKind class

x

x

x DevelopBOM

Coding

DesignUI

TaskKindTaskKind

DesignUIDesignUI Coding

Task

x

Now, in a software context


• Powertypes combine instantiation and generalization and can thus have attributes that are given values both one and two levels below.

• Thus, enactment is supported as well as method modelling.


• Software developers on a project need to know who is doing what, when and how. These are attribute values, some defined in the method domain, others in the metamodel domain.

endeavour

method

metamodel

“MySystem”RequirementsSpecification

“MySystem”RequirementsSpecification

DocumentDocument

RequirementsSpecificationDocument

RequirementsSpecificationDocument

DocumentKind

DocumentKind

TitleVersion

TitleVersion

NameMustBeApproved

NameMustBeApproved

TitleVersion

TitleVersion

Req. Spec. DocumentMust be approved: yesReq. Spec. DocumentMust be approved: yes

“MySystem” Req. Spec.Version 1.5

“MySystem” Req. Spec.Version 1.5


III. Exemplar: ISO/IEC24744

• Published in Feb 2007 after undergoing full ISO process of quality assessment and development

• Uses the 3 layer architecture discussed earlier

• Uses powertypes


Figure 2

StartTimeDuration

Task

NamePurpose

TaskKind

This powertype pairing occurs frequently in ISO/IEC 24744


Figure 3

StartTimeDuration

Task

NamePurpose

TaskKind

WriteCode

Name = "Write code"Purpose = "To wite code..."

: TaskKind

«instanceOf»

clabject

©B. Henderson-Sellers, 2008 29Figure 4

MethodologyElement

+Purpose+MinCapabilityLevel

WorkUnitKind

+Description

WorkProductKind

+Definition

ModelUnitKind

+Name

Template Resource

+Name

Language

+Name

Notation

+Expression

Constraint

+Description+MinCapabilityLevel

Outcome

EndeavourElement

+StartTime+EndTime+Duration

WorkUnit

+CreationTime+LastChangeTime+Status

WorkProduct

ModelUnit

+Description

GuidelineProducerKind

+Name

ProducerStage

StageKind


In 24744, each class is rigorously defined


+startTime+endTime+duration

Task

Elicit requirements

+name+purpose+minCapabilityLevel+description

TaskKind

tk4:TaskKind

name=Elicit requirements

classfacet

objectfacet

«instanceOf»

t4:Elicit requirements

«instanceOf»

startTime=1 SeptendTime=5 Septduration=4 days

slotvalues

All the detailed information is defined by the standard


A method fragment is conformant with this metamodel fragment

Task KindName: Elicit requirements

Purpose: To develop and refine a formal and stable requirements specification.

Description: Requirements are to be elicited from clients, domain experts,

marketing personnel and users. Usual sub-tasks include defining the problem,

evaluating existing systems, establishing user requirements, establishing

distribution requirements and establishing database requirements.

Minimum capability level: 1


Using the SEMDM

methodology

metamodelStartTimeEndTimeDuration

Task

NamePurposeMinCapabilityLevel

TaskKindName

ElicitRequirementsTask Name = Elicit requirementsPurpose = To determine...MinCapabilityLevel = 1

tk1 : TaskKind

«instanceOf»

endeavourStartTime = 5-Jun-05EndTime = 8-Jun-05Duration = 3 days

ert1 : ElicitRequirementsTask

«instanceOf»


Adding an Attribute to SEMDM

methodology

metamodel

endeavour

NameStartTimeEndTimeDuration

Task


TaskKind

NeedsSignOff

ValidateRequirementsTask Name = Validate requirementsPurpose = To ensure...MinCapabilityLevel = 2

tk2 : TaskKind

«instanceOf»

StartTime = 6-May-05EndTime = 18-May-05Duration = 12 daysNeedsSignOff = yes

vrt1 : ValidateRequirementsTask

«instanceOf»


Extending the SEMDM

methodology

metamodel

endeavour

NameStartTimeEndTimeDuration

Task


TaskKind

metamodelextensionPerformance

MeasuredTask

MeasurementGuidelines

MeasuredTaskKind

PackageCDsTask Name = Package CDsPurpose = To put CDs in cases...MinCapabilityLevel = 4MeasurementGuidelines = Count the...

mtk1 : MeasuredTaskKind

«instanceOf»

StartTime = 20-Sep-05EndTime = 28-Sep-05Duration = 8 daysPerformance = 82%

pct1 : PackageCDsTask

«instanceOf»


IV. Adding a Notation

Having standardized the metamodel, a follow-on project (NWI) was approved mid-2007 to create a semiotically-based notation for documenting constructed methods.


• Mainly graphical• Mostly for construction rather than

enactment (so far)• Easy to draw by hand as well as with

drawing package• Culturally-independent shapes• Semiotic principles• Families of shapes and colours• Use of colour but also B/W• Introduction of abstract symbols


<Name>

<Name>

<Name>

<Name>

<Name>

<Name>

StagewithDurationKind

TimeCycleKind(bracket-like)

PhaseKind

BuildKind(iterative nature)

InstantaneousStageKind(abstract)MilestoneKind (not acontainer)

“Stage” family


“WorkUnitKind” family

<Name>

n

<Name>n

<Name>

n

ProcessKind

TaskKind

TechniqueKind

Mincapabilitylevel

Various colour and shape combinations tried out


“WorkProductKind” family

<Name>

<Name>

<Name>

<Name>

<Name>

<Name>

WorkProductKind

DocumentKind

ModelKind

SoftwareItemKind(old-fashioned? – yetstandard in file managers)

HardwareItemKind(old-fashioned?)

CompositeWork_ProductKind


“Producer” family

<Name>

<Name>

<Name>

<Name>

ProducerKind

TeamKind

RoleKind

ToolKind


Notation for Actions

taskend

workproductend

<Role>

d t

DeonticMarkeroptionality

Type ofUsage (CRUD)


Diagram Types

Construction

Construction Build

Mc

Definition

Requirements Engineering1

High-Level Modelling1

Technological Design1

Deployment Planning1

Construction Planning1

Low-Level Modelling1

Packaging1

Synchronisation1

Coding1 Generation1

User Documentation Authoring1

Hypothetical methodology

2 Requirements quality assurance

Construction

Construction Build

Mc

Definition

Requirements Engineering1






Packaging1

Synchronisation1

Coding1 Generation1


Hypothetical methodology


Lifecycle diagram


More extensive example Lifecycle Diagram

OPEN/Metis Project

M0

Construction

Construction Build

Mc

Mf

Determination of Needs

Definition

Change

Change Build

Mu

Retirement

Needs Formalisation1

Needs Documentation1

Requirements Specification1







Coding1 Generation1

Packaging1

Synchronisation1

System Retirement1

Change Management2



Coding1 Generation1

Packaging1

Synchronisation1


Example Process Diagram

Require-ments

+

Quality

RequirementsEngineering

1

RequirementsQuality Assurance

2

Metrics Tool

Elicitrequirements

1

Analyserequirements

1

Documentrequirements

1

Validaterequirements

2

Verifyrequirements

2

Measurerequirements

quality4


Example Action Diagram


DefinitionPhase

Phase

Definition Phase x1 : DefinitionPhase

«instanceOf»

Req. Eng. x1 : RequirementsEngineering


«instanceOf»

Process

Req. Qual. Assur. x1 : RequirementsQualityAssurance

RequirementsQualityAssurance

«instanceOf»

etc.DefinitionPhase

Phase

Definition Phase x1 : DefinitionPhase

«instanceOf»

Req. Eng. x1 : RequirementsEngineering


«instanceOf»

Process

Req. Qual. Assur. x1 : RequirementsQualityAssurance

RequirementsQualityAssurance

«instanceOf»

etc.

Enacting the methodology


CP

HLM.

DefinitionDefinition

Requirements engineering-1

Deployment planning1

Construction planning1

High-level modelling1

Technological design1


RE

RQA

CP

HLM.

DefinitionDefinition

Requirements engineering-1

Deployment planning1

Construction planning1

High-level modelling1

Technological design1


RE

RQA

Proposed 24744 notation for the enactment diagram


Here is a more complex example

Syn.2

Cod.2

LLM.2

Syn.1

Cod.1

LLM.1

Construction

Construction Build 1

Construction

Construction Build

Mc Mc.1

Construction Build 2

Mc.2


Packaging1

Synchronisation1


Coding1

Generation1

UDA


V. Using the standard(method construction)

• ISO/IEC 24744 strongly supports method engineering, though not exclusively so.

• MethodologyElement hierarchy defines elements that can be defined and used in the method construction i.e. fragments

• Generated method fragments are stored in a repository or methodbase


From the method fragments in the repository can be assembled an individually tailored process

methodfragments

Constructed methodology


Process Model Level (Method Domain)Methodbase + Project Characteristics = Situational method

Project characteristics

Selection and Assemblyof Method Fragments

into Situational Method

Methodbase


Method fragmentsRepository

Methodology Instance

Step 2: Project Manager

ConstructionGuidelines

uses

Metamodel

instance of

instances of

Methodology M

Step 1: Method engineer

Method fragmentsMethod fragmentsRepository






uses


uses

Metamodel

instance ofinstance of

instances ofinstances of

Methodology M


Methodology MMethodology M


In a little more detail


Construction guidelines

• MAP procedure

• Deontic matrices

• Process data diagrams (combining an activity diagram and a class-based work product diagram)

Specify MethodRequirements

Start

Process -driven

Intention -driven

Stop

AssembleMethod Chunks

Requirements -driven

IntegrationCompleteness

Aggregation

Decomposition

Aassociation

Refinement

EvaluationSelect

Method chunks

Specify MethodRequirements

Start

Process -driven

Intention -driven

Stop

AssembleMethod Chunks

Requirements -driven Requirements -driven

IntegrationCompleteness

Aggregation

Decomposition

Aassociation

Refinement

EvaluationSelect

Method chunks

Use casemodeling

Find actors and use cases

Prioritize use cases

Detail use cases

USE CASE MODEL

USE CASE

PRIORITY

1

1

1

Structure use cases

ACTOR1..*1..*

prioritizes

detailsDESCRIPTION

11..*


ME also supports SPI

• Method can be incrementally enhanced by new fragments

• Support of different capability levels (e.g. 15504)

• SPI seen as emergent, needing an agile (and flexible) approach (Allison and Merali, 2006)

• Practical evaluation with action research


Example Fragments

Example of PhaseKindAttributes

Name: Construction

Relationships

Is composed of (Process kinds): Low-Level Modelling Quality Engineering Implementation


Task KindName: Elicit requirements

Purpose: To develop and refine a formal and stable requirements specification.

Description: Requirements are to be elicited from clients, domain experts,

marketing personnel and users. Usual sub-tasks include defining the problem,

evaluating existing systems, establishing user requirements, establishing

distribution requirements and establishing database requirements.

Minimum capability level: 1

WorkUnitKind+purpose+mincapabilitylevel

TaskKind

+description

Template

+name

Remember, each fragment is defined in form by the ISO standard


Example of TaskKindAttributesName: Analyze requirementsPurpose: Study, understand and formalise requirements previously

elicited.Description: //write description here.Minimum capability level: 1RelationshipsCauses (Action kinds):• Modifies Requirements Specification Document, mandatory.Results in (Outcomes):• Requirements have been analysed and understood.Includes (Task kinds): • (none)Is involved in (Task-technique mapping kinds):• //map to techniques here.Is involved in (Work performance kinds):• Business Analyst, mandatory.• Customer, recommended.

With relationships added


Example of RoleKindAttributesName: Business AnalystResponsibilities: To develop models of the problem domain.RelationshipsIs involved in (Work performance kinds): Elicit requirements, mandatory. Analyze requirements, mandatory. Document requirements, recommended. Develop class models, recommended. Perform peer review, optional.

RoleKinds also defined by ISO standard


VI. In Summary

• Standards are useful• Presentation of one exemplar: ISO/IEC 24744• Method fragments and diagram notation (draft)• Application through SME

• Forthcoming book: Metamodelling for Software Engineering, Gonzalez-Perez, C. and Henderson-Sellers, B., Wiley, August 2008

standardizing methodology metamodelling and notation: an iso exemplar

Documents