Upload
libby-roberts
View
25
Download
0
Embed Size (px)
DESCRIPTION
Standardizing Methodology Metamodelling and Notation: An ISO Exemplar. UNISCON Keynote April 25 2008 Brian Henderson-Sellers Director, COTAR University of Technology, Sydney www-staff.it.uts.edu.au/~brian email: [email protected] [with thanks to Dr Cesar Gonzalez-Perez]. Preview. - PowerPoint PPT Presentation
Citation preview
©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]
©B. Henderson-Sellers, 2008 2
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
©B. Henderson-Sellers, 2008 3
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
©B. Henderson-Sellers, 2008 4
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
©B. Henderson-Sellers, 2008 5
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)
©B. Henderson-Sellers, 2008 6
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
©B. Henderson-Sellers, 2008 7
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)
©B. Henderson-Sellers, 2008 8
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.
©B. Henderson-Sellers, 2008 9
BankAccount
balance
withdraw (amount:Dollar)deposit (amount:Dollar)
Customer
address
Example model which uses the rules of UML metamodel
©B. Henderson-Sellers, 2008 10
BankAccount
balance
deposit (amount:Dollar)
Customer
address
withdraw (amount:Dollar)
Example model which does not adhere to UML
©B. Henderson-Sellers, 2008 11
AssociationClass
Classifier
Class Interface DataType
Association
AssociationEnd
aggregation
Attribute
StructuralFeature
Operation Method
BehaviouralFeature
Featurevisibility
1 *
GeneralizableElement
Node Component
Invariant
PostconditionPrecondition
Namespace
Artifact
stereotypeof constraint
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
stereotypeof constraint
RelationshipRelationship
Example: part of a modelling language metamodel
©B. Henderson-Sellers, 2008 12
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
©B. Henderson-Sellers, 2008 13
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.
©B. Henderson-Sellers, 2008 14
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
©B. Henderson-Sellers, 2008 15
+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
©B. Henderson-Sellers, 2008 16
The ISO architecturerealigns the “levels” to practice
endeavour
method
metamodelActivity
WorkUnit
Task Technique
* *
methodologies assessment quality tools
©B. Henderson-Sellers, 2008 17
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»
©B. Henderson-Sellers, 2008 18
ExampleTrees may be classified by species. Any
individual tree may be a gum, elm, plane etc. So we have
Tree
PlaneElmGum
TreeSpeciesis classified by
©B. Henderson-Sellers, 2008 19
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)
©B. Henderson-Sellers, 2008 20
Tree
PlaneElmGum
TreeSpeciesis classified by
«instanceOf»
TreeSpecies is thus aPowertype of Tree
©B. Henderson-Sellers, 2008 21
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
©B. Henderson-Sellers, 2008 22
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
©B. Henderson-Sellers, 2008 23
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
©B. Henderson-Sellers, 2008 24
• 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.
©B. Henderson-Sellers, 2008 25
• 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
©B. Henderson-Sellers, 2008 26
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
©B. Henderson-Sellers, 2008 27
Figure 2
StartTimeDuration
Task
NamePurpose
TaskKind
This powertype pairing occurs frequently in ISO/IEC 24744
©B. Henderson-Sellers, 2008 28
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
©B. Henderson-Sellers, 2008 31
+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
©B. Henderson-Sellers, 2008 32
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
©B. Henderson-Sellers, 2008 33
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»
©B. Henderson-Sellers, 2008 34
Adding an Attribute to SEMDM
methodology
metamodel
endeavour
NameStartTimeEndTimeDuration
Task
NamePurposeMinCapabilityLevel
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»
©B. Henderson-Sellers, 2008 35
Extending the SEMDM
methodology
metamodel
endeavour
NameStartTimeEndTimeDuration
Task
NamePurposeMinCapabilityLevel
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»
©B. Henderson-Sellers, 2008 36
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.
©B. Henderson-Sellers, 2008 37
• 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
©B. Henderson-Sellers, 2008 38
<Name>
<Name>
<Name>
<Name>
<Name>
<Name>
StagewithDurationKind
TimeCycleKind(bracket-like)
PhaseKind
BuildKind(iterative nature)
InstantaneousStageKind(abstract)MilestoneKind (not acontainer)
“Stage” family
©B. Henderson-Sellers, 2008 39
“WorkUnitKind” family
<Name>
n
<Name>n
<Name>
n
ProcessKind
TaskKind
TechniqueKind
Mincapabilitylevel
Various colour and shape combinations tried out
©B. Henderson-Sellers, 2008 40
“WorkProductKind” family
<Name>
<Name>
<Name>
<Name>
<Name>
<Name>
WorkProductKind
DocumentKind
ModelKind
SoftwareItemKind(old-fashioned? – yetstandard in file managers)
HardwareItemKind(old-fashioned?)
CompositeWork_ProductKind
©B. Henderson-Sellers, 2008 41
“Producer” family
<Name>
<Name>
<Name>
<Name>
ProducerKind
TeamKind
RoleKind
ToolKind
©B. Henderson-Sellers, 2008 42
Notation for Actions
taskend
workproductend
<Role>
d t
DeonticMarkeroptionality
Type ofUsage (CRUD)
©B. Henderson-Sellers, 2008 43
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
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
Lifecycle diagram
©B. Henderson-Sellers, 2008 44
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
High-Level Modelling1
Technological Design1
Deployment Planning1
Construction Planning1
User Documentation Authoring1
Low-Level Modelling1
Coding1 Generation1
Packaging1
Synchronisation1
System Retirement1
Change Management2
High-Level Modelling1
Low-Level Modelling1
Coding1 Generation1
Packaging1
Synchronisation1
©B. Henderson-Sellers, 2008 45
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
©B. Henderson-Sellers, 2008 47
DefinitionPhase
Phase
Definition Phase x1 : DefinitionPhase
«instanceOf»
Req. Eng. x1 : RequirementsEngineering
RequirementsEngineering
«instanceOf»
Process
Req. Qual. Assur. x1 : RequirementsQualityAssurance
RequirementsQualityAssurance
«instanceOf»
etc.DefinitionPhase
Phase
Definition Phase x1 : DefinitionPhase
«instanceOf»
Req. Eng. x1 : RequirementsEngineering
RequirementsEngineering
«instanceOf»
Process
Req. Qual. Assur. x1 : RequirementsQualityAssurance
RequirementsQualityAssurance
«instanceOf»
etc.
Enacting the methodology
©B. Henderson-Sellers, 2008 48
CP
HLM.
DefinitionDefinition
Requirements engineering-1
Deployment planning1
Construction planning1
High-level modelling1
Technological design1
2 Requirements quality assurance
RE
RQA
CP
HLM.
DefinitionDefinition
Requirements engineering-1
Deployment planning1
Construction planning1
High-level modelling1
Technological design1
2 Requirements quality assurance
RE
RQA
Proposed 24744 notation for the enactment diagram
©B. Henderson-Sellers, 2008 49
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
Low-Level Modelling1
Packaging1
Synchronisation1
User Documentation Authoring1
Coding1
Generation1
UDA
©B. Henderson-Sellers, 2008 50
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
©B. Henderson-Sellers, 2008 51
From the method fragments in the repository can be assembled an individually tailored process
methodfragments
Constructed methodology
©B. Henderson-Sellers, 2008 52
Process Model Level (Method Domain)Methodbase + Project Characteristics = Situational method
Project characteristics
Selection and Assemblyof Method Fragments
into Situational Method
Methodbase
©B. Henderson-Sellers, 2008 53
Method fragmentsRepository
Methodology Instance
Step 2: Project Manager
ConstructionGuidelines
uses
Metamodel
instance of
instances of
Methodology M
Step 1: Method engineer
Method fragmentsMethod fragmentsRepository
Methodology Instance
Step 2: Project Manager
Methodology Instance
Step 2: Project Manager
ConstructionGuidelines
uses
ConstructionGuidelines
uses
Metamodel
instance ofinstance of
instances ofinstances of
Methodology M
Step 1: Method engineer
Methodology MMethodology M
Step 1: Method engineer
In a little more detail
©B. Henderson-Sellers, 2008 54
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..*
©B. Henderson-Sellers, 2008 55
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
©B. Henderson-Sellers, 2008 56
Example Fragments
Example of PhaseKindAttributes
Name: Construction
Relationships
Is composed of (Process kinds): Low-Level Modelling Quality Engineering Implementation
©B. Henderson-Sellers, 2008 57
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
©B. Henderson-Sellers, 2008 58
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
©B. Henderson-Sellers, 2008 59
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
©B. Henderson-Sellers, 2008 60
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