Standardizing Methodology Metamodelling and Notation An ISO Exemplar

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: brian@it. uts. edu. au [with thanks to Dr Cesar Gonzalez-Perez] ©B. Henderson-Sellers, 2008 1

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 2

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 3

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 4

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 5

ISO Process • SE standards in SC 7 of JTC 1 [ISO+IEC] • Several working groups (WG) in SC 7 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 FDIS IS ©B. Henderson-Sellers, 2008 6

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 7

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 8

Example model which uses the rules of UML metamodel Bank. Account balance withdraw (amount: Dollar) deposit (amount: Dollar) ©B. Henderson-Sellers, 2008 Customer address 9

Example model which does not adhere to UML Bank. Account balance Customer address deposit (amount: Dollar) withdraw (amount: Dollar) ©B. Henderson-Sellers, 2008 10

Example: part of a modelling language metamodel ©B. Henderson-Sellers, 2008 11

Example: part of a methodology metamodel ©B. Henderson-Sellers, 2008 12

In the Endeavour domain, a process is derived as an instance of the methodology and then happens in real time. ©B. Henderson-Sellers, 2008 13

A “simpler” version is promoted by the OMG But enactment of processes is not possible ©B. Henderson-Sellers, 2008 14

This means that this is an invalid UML diagram Actually duration should be given a value here ©B. Henderson-Sellers, 2008 15

The ISO architecture realigns the “levels” to practice endeavour methodologies assessment quality tools metamodel ©B. Henderson-Sellers, 2008 16

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 17

Example Trees may be classified by species. Any individual tree may be a gum, elm, plane etc. So we have Tree Gum ©B. Henderson-Sellers, 2008 Elm is classified by Tree. Species Plane 18

But Gum, elm and plane are all instances of Tree. Species (which sort of puts Tree. Species at a higher metalevel, whilst remaining an M 1 Class). Thus we get (next slide) ©B. Henderson-Sellers, 2008 19

Tree. Species is thus a Powertype of Tree Gum ©B. Henderson-Sellers, 2008 Elm is classified by Plane Tree. Species «instance. Of» 20

This leads to the notion of “clabject” – an entity that has both class and object facets Elm Tree. Species Nam e Avg. H = “Elm” eigh t=1 8 Object facet ©B. Henderson-Sellers, 2008 t ht: in Heig Class facet 21

In terms of sets Tree class Tree. Species class Oak x x x Elm x x x x Sugar maple my. Friend ©B. Henderson-Sellers, 2008 x oak x elm x sugar maple Tree. Species is a Powertype i. e. a set of all subsets of another set as defined by a given discriminator 22

Now, in a software context Task class Task. Kind class Coding x x x Design. UI x Coding x x Develop. BOM Task. Kind Task Design. UI Coding ©B. Henderson-Sellers, 2008 23

• 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 24

• 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. “My. System” Req. Spec. Version 1. 5 Title Version Document “My. System” Requirements Specification Document endeavour Req. Spec. Document Must be approved: yes Document Kind method metamodel Name Must. Be. Approved ©B. Henderson-Sellers, 2008 25

III. Exemplar: ISO/IEC 24744 • 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 26

This powertype pairing occurs frequently in ISO/IEC 24744 Figure 2 ©B. Henderson-Sellers, 2008 27

clabject Figure 3 ©B. Henderson-Sellers, 2008 28

Figure 4 ©B. Henderson-Sellers, 2008 29

In 24744, each class is rigorously defined ©B. Henderson-Sellers, 2008 30

All the detailed information is defined by the standard ©B. Henderson-Sellers, 2008 31

A method fragment is conformant with this metamodel fragment Task Kind Name: 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 32

Using the SEMDM ©B. Henderson-Sellers, 2008 33

Adding an Attribute to SEMDM ©B. Henderson-Sellers, 2008 34

Extending the SEMDM ©B. Henderson-Sellers, 2008 35

IV. Adding a Notation Having standardized the metamodel, a followon project (NWI) was approved mid-2007 to create a semiotically-based notation for documenting constructed methods. ©B. Henderson-Sellers, 2008 36

• 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 37

“Stage” family Stagewith. Duration. Kind Time. Cycle. Kind (bracket-like) Phase. Kind Build. Kind (iterative nature) ©B. Henderson-Sellers, 2008 Instantaneous. Stage. Kind (abstract) Milestone. Kind (not a container) 38

Min capability level “Work. Unit. Kind” family Process. Kind Task. Kind Technique. Kind Various colour and shape combinations tried out ©B. Henderson-Sellers, 2008 39

“Work. Product. Kind” family Work. Product. Kind ©B. Henderson-Sellers, 2008 Software. Item. Kind (old-fashioned? – yet standard in file managers) Document. Kind Hardware. Item. Kind (old-fashioned? ) Model. Kind Composite. Work_ Product. Kind 40

“Producer” family Producer. Kind Team. Kind Role. Kind Tool. Kind ©B. Henderson-Sellers, 2008 41

Notation for Actions Deontic Marker optionality ©B. Henderson-Sellers, 2008 Type of Usage (CRUD) 42

Diagram Types Lifecycle diagram ©B. Henderson-Sellers, 2008 43

More extensive example Lifecycle Diagram ©B. Henderson-Sellers, 2008 44

Example Process Diagram ©B. Henderson-Sellers, 2008 45

Example Action Diagram ©B. Henderson-Sellers, 2008 46

Enacting the methodology ©B. Henderson-Sellers, 2008 47

Proposed 24744 notation for the enactment diagram ©B. Henderson-Sellers, 2008 48

Here is a more complex example ©B. Henderson-Sellers, 2008 49

V. Using the standard (method construction) • ISO/IEC 24744 strongly supports method engineering, though not exclusively so. • Methodology. Element 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 50

From the method fragments in the repository can be assembled an individually tailored process Constructed methodology method fragments ©B. Henderson-Sellers, 2008 51

Process Model Level (Method Domain) Methodbase + Project Characteristics = Situational method Methodbase Project characteristics ©B. Henderson-Sellers, 2008 Selection and Assembly of Method Fragments into Situational Method 52

In a little more detail ©B. Henderson-Sellers, 2008 53

Construction guidelines • MAP procedure • Deontic matrices • Process data diagrams (combining an activity diagram and a class-based work product diagram) ©B. Henderson-Sellers, 2008 54

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 55

Example Fragments Example of Phase. Kind Attributes Name: Construction Relationships Is composed of (Process kinds): Low-Level Modelling Quality Engineering Implementation ©B. Henderson-Sellers, 2008 56

Remember, each fragment is defined in form by the ISO standard Task Kind Name: 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 57

With relationships added Example of Task. Kind Attributes Name: Analyze requirements Purpose: Study, understand formalise requirements previously elicited. Description: //write description here. Minimum capability level: 1 Relationships Causes (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. ©B. Henderson-Sellers, 2008 58

Role. Kinds also defined by ISO standard Example of Role. Kind Attributes Name: Business Analyst Responsibilities: To develop models of the problem domain. Relationships Is involved in (Work performance kinds): Elicit requirements, mandatory. Analyze requirements, mandatory. Document requirements, recommended. Develop class models, recommended. Perform peer review, optional. ©B. Henderson-Sellers, 2008 59

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 ©B. Henderson-Sellers, 2008 60