Me2011 Granularity presentation by Henderson-Sellers


Published on

Towards the Gnularity Theory for Determining the Size of Atomic Method Fragments for Use in Situational Method Engineering

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Me2011 Granularity presentation by Henderson-Sellers

  1. 1. Towards the use of granularity theory for determining the size of atomic method fragments for use in situational method engineering Brian Henderson-Sellers Director, COTAR Centre for Human Centred Technology Design School of Software University of Technology, Sydney Cesar Gonzalez-Perez The Heritage Laboratory CSIC, Santiago de Compostela
  2. 2. Overview <ul><li>Application of granularity theory </li></ul><ul><li>Context of fragment for use in Situational Method Engineering (SME) </li></ul><ul><li>Focus on atomic fragments </li></ul><ul><li>Assessment of granularity of OPF’s work unit fragments </li></ul>
  3. 3. Context: SME <ul><li>Situational method engineering uses method fragments, stored in a repository, from which a full software development methodology is constructed </li></ul><ul><li>The granularity of these fragments has two elements: </li></ul><ul><ul><li>the granularity of the metamodel element </li></ul></ul><ul><ul><li>the size and granularity of the fragment description </li></ul></ul>
  4. 4. For example, metamodel granularity <ul><li>Two possible granularities for a metamodel </li></ul>Process Element Activity Task Process Element Activity Task Process Element Activity Task Process Element Activity Task Process Element
  5. 5. This leads to notion of abstraction, which is crucial for modelling <ul><li>Maps a representation of problem to a “more abstract” representation i.e. less detail </li></ul><ul><li>Loss of detail leads to a simpler problem to be solved </li></ul><ul><li>By preserving relevant properties, allows easier solution to problem by use of abstract model </li></ul>
  6. 6. Abstraction Mapping α : S  A Formally, an abstraction maps between two formal systems, Σ 1 , Σ 2 , where each system is a set of formulae, Θ , written in a language Λ . Then, equating Θ with Λ (Giunchiglia and Walsh, 1992), we have Σ =( Λ ) such that f: Σ 1  Σ 2 and f Λ : Λ 1  Λ 2
  7. 7. Abstraction = granularity abstraction, F, iff <ul><li>For x 1 , …. x n  L 0 , x  L j </li></ul><ul><li>F(x i ) = x for all i  [1,n] </li></ul><ul><li>where x is either a constant, a function or a predicate </li></ul><ul><li>A granularity abstraction is an atomic abstraction </li></ul>
  8. 8. Granularity abstraction called F-ABS by Keet (2007)  
  9. 9. Granularity abstractions <ul><li>May refer to </li></ul><ul><li>Classification structures (is instance of) </li></ul><ul><li>Generalization (is a kind of) </li></ul><ul><li>Whole-part (is a part of) </li></ul>
  10. 10. Example: Granularity in classification/instantiation structure Class Object detail added detail removed
  11. 11. Proposed size measure (ER2010) G s = 1 G s = 0.2
  12. 12. Discussion <ul><li>Smaller values of G s suggest finer granularity </li></ul><ul><li>Very high values (  1) and very low values (  0) are likely to be unacceptable – for different reasons </li></ul>
  13. 13. Methodology metamodel triangle Here, we focus on WorkUnit
  14. 14. Metamodel fragment for WorkUnitKind WorkUnitKind +StartTime +EndTime +Duration + Parent 0..1 + Child 0..* + Context 1 Process Kind Technique Kind TaskKind +Component 0..* SEMDM (ISO/IEC 24744)
  15. 15. Two possible granularities <ul><li>One specific TaskKind as example fragment </li></ul>Task Kind Name : Elicit and document requirements Purpose : To develop and refine a formal and stable requirements specification and provide a document . Minimum capability level : 1 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, distribution requirements and database requirements and providing a written statement of requirements . startTime endTime duration
  16. 16. Case Study: OPF fragments <ul><li>Problem </li></ul><ul><li>Many fragments increasing in size over the years – especially Construct the object model </li></ul><ul><li>Tasks should have a suite of optional techniques not a suite of mandatory ones – as was the case </li></ul>
  17. 17. Task amalgamation
  18. 18. Consequence of task amalgamation <ul><li>Creation of parallel Construct the agent model led to the identification of 17 atomic tasks embedded within the merged “Task” </li></ul>
  19. 19. Revision of fragments <ul><li>Solution </li></ul><ul><li>Suggest that Construct the agent model should be an OPF Activity (24744 SubProcess of Design Process) not a Task. Name = Construct the model using the selected technology/paradigm </li></ul><ul><li>With the 17 identified atomic tasks no longer embedded but as full Tasks </li></ul>
  20. 20. Summary - 1 <ul><li>Defining granularity theoretically is useful to understand how to optimize fragment granularity </li></ul><ul><li>BUT not the only factor – just one part of a “quality vector” </li></ul><ul><li>Re-evaluation of granularity of OPF fragments leads to major revision of the fragment structure and content </li></ul>
  21. 21. Summary - 2 <ul><li>Future work </li></ul><ul><li>Further re-evaluation of specific fragments in OPF and revision as necessary to ensure atomicity </li></ul><ul><li>Quantification of granularity value </li></ul><ul><li>How reusable are fragments of different granularities? </li></ul>