Standardizing Methodology Metamodelling and Notation: An ISO Exemplar

1. 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]

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

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

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

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)

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 FDISIS

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)

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.

9. Example model which uses the rules of UML metamodel BankAccount Customer balance address withdraw (amount:Dollar) deposit (amount:Dollar)

10. Example model which does not adhere to UML Customer BankAccount balance address deposit (amount:Dollar) withdraw (amount:Dollar)

11. Example: part of a modelling language metamodel

12. Example: part of a methodology metamodel

13. In the Endeavour domain, a process is derived as an instance of the methodology and then happens in real time.

14. A “simpler” version is promoted by the OMG But enactment of processes is not possible

15. This means that this is an invalid UML diagram Actually duration should be given a value here

16. endeavour method methodologies assessment quality tools metamodel The ISO architecturerealigns the “levels” to practice

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»

18. Example Trees may be classified by species. Any individual tree may be a gum, elm, plane etc. So we have Tree TreeSpecies is classified by Gum Elm Plane

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)

20. TreeSpecies is thus a Powertype of Tree Tree TreeSpecies is classified by Gum Elm Plane «instanceOf»

21. Elm TreeSpecies Name = “Elm” AvgHeight = 18 Height: int Object facet Class facet This leads to the notion of “clabject” – an entity that has both class and object facets

22. x In terms of sets Tree class TreeSpecies class Oak Elm x x x x x oak x x x x x x elm x x x x x sugar maple Sugar maple TreeSpecies is a Powertype i.e. a set of all subsets of another set as defined by a given discriminator myFriend

23. Task class Task class TaskKind TaskKind class class Coding Coding DesignUI DesignUI x x x x x x x x x x DesignUI DesignUI x x x x x x x x x x x x Coding Coding x x x x x x x x x x x x DevelopBOM DevelopBOM DevelopBOM DevelopBOM TaskKind TaskKind TaskKind Task Task DesignUI DesignUI DesignUI DesignUI Coding Coding Now, in a software context

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.

25. “MySystem” Requirements Specification endeavour “MySystem” Req. Spec. Version 1.5 Req. Spec. Document Must be approved: yes Title Version RequirementsSpecificationDocument Document Document Kind Title Version metamodel Name MustBeApproved method • 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.

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

27. This powertype pairing occurs frequently in ISO/IEC 24744 Figure 2

28. clabject Figure 3

29. Figure 4

30. In 24744, each class is rigorously defined

31. All the detailed information is defined by the standard

32. 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

33. Using the SEMDM

34. Adding an Attribute to SEMDM

35. Extending the SEMDM

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.

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

38. “Stage” family StagewithDurationKind TimeCycleKind (bracket-like) PhaseKind BuildKind (iterative nature) InstantaneousStageKind (abstract) MilestoneKind (not a container)

39. “WorkUnitKind” family Min capability level ProcessKind TaskKind TechniqueKind Various colour and shape combinations tried out

40. “WorkProductKind” family SoftwareItemKind (old-fashioned? – yet standard in file managers) HardwareItemKind (old-fashioned?) CompositeWork_ ProductKind WorkProductKind DocumentKind ModelKind

41. “Producer” family ProducerKind TeamKind RoleKind ToolKind

42. Notation for Actions Type of Usage (CRUD) Deontic Marker optionality

43. Diagram Types Lifecycle diagram

44. More extensive example Lifecycle Diagram

45. Example Process Diagram

46. Example Action Diagram

47. Enacting the methodology

48. Proposed 24744 notation for the enactment diagram

49. Here is a more complex example

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