1. 1 N Degrees of Separation: Multi-Dimensional Separation of Concern (MDSOC) HyperJ: language and concepts of general concern combination

2. 2 Multi-dimensional separation of concerns (MDSOC) Multi dimensions separation of concerns refers to the ability to identify, encapsulate, and manipulate those parts of software that are relevant to a particular concern (concept, goal, purpose, etc.). It helps supporting construction, evolution and integration of software.

3. 3 Types of concerns: The prevalent concern in object-oriented programming is the class, which encapsulates data concerns. Feature concerns, like printing, persistence, and display capabilities, are also common. Aspects, roles, variants, and configurations. Concern means “ a particular area of interest ”

4. 4 Multi-dimensional separation of concerns (cont.) Its goals are to enable: Encapsulation of all types of concerns in a software system, simultaneously. Overlapping and interacting concerns. On-demand remodularization. It compliments existing formalisms, giving developers additional modularization flexibility while continuing to use the formalisms of their choice.

5. 5 Hyper/J Hyper/J supports multi-dimensional separation of concerns for JavaTM. It provides: Ability to specify modules according to concerns. Synthesize systems and components by integrating those modules.

6. 6

7. 7 Personnel Software - Requirements Personnel feature: name Print Business rules: 1-3 managers for each employee The payroll feature: Salary information Tax regulations minimum and maximum wage.

8. 8 Personnel Software – Class hierarchy name() print() check() position() pay() Employee name() print() check() position() pay() Sales name() print() check() position() pay() Research name() print() check() position() pay() Staff name() print() check() position() pay() ResearchMgr name() print() check() position() pay() Secretary name() print() check() position() pay() Maintenance name() print() check() position() pay() SalesMgr

9. 9 The tyranny of the dominant decomposition Existing formalisms provide only restricted sets decomposing and composing mechanisms, and these typically support only a single, “ dominant ” dimension of separation at a time. We would like the system to encapsulate all relevant kinds (dimensions) of concerns simultaneously.  MDSOC.

10. 10 Features are Scattered and Tangled Scattering – a single requirement affects multiple design and code modules. Tangling – material pertaining to multiple requirements is interleaved within a single module. In general: Features are coherent entities from a conceptual and requirement point of view, BUT  Features are not modules in design or code So, I is difficult to: Find and work with the code for a feature Add a new feature Remove a feature Mix-and-match features Non-Invasive In a Non-Invasive way!

11. 11 Hyper/J concepts HyperslicesHypermodulesHyperspaces

12. 12 S etting the context and introducing terminology for Separation of Concerns units It is convenient to think of the descriptive material in each artifact as being made up of units. Primitiveunits Primitive units – e.g. methods of a class, declarations. A unit might also be a state chart or requirement specification – depending upon the artifact. Compoundunitsmodules Compound units or modules – e.g. classes, interfaces. A single concept is typically modeled by a collection of many units (primitive or compound). A single unit often participates in modeling more than one concept.

13. 13 Multi-Dimensional Decomposition: Hyperslices hyperslice A hyperslice is a set of units. Hyperslices are intended to encapsulate concerns in dimensions other than the dominant one. The modules within it contain all, and only, those units that pertain to a given concern. Hyperslices can overlap – a given unit may occur in multiple hyperslices.

14. 14 Hyperslices in the personnel software: position() pay() Employee position() pay() Sales position() pay() Research position() pay() Stuff position() pay() ResearchMgr osition() pay() Secretary position() pay() Maintenance position() pay() SalesMgr Payrollhyperslice name() check() print() Employee name() check() print() Sales name() check() print() Research name() check() print() Stuff name() check() print() ResearchMgr name() check() print() Secretary name() check() print() Maintenance name() check() print() SalesMgr Personnelhyperslice

15. 15 Multi-Dimensional Decomposition: Hypermodules hypermodule Each hypermodule is composed of: hyperslices A set of hyperslices composition rule A composition rule that specifies how the hyperslices are to be integrated.

16. 16 Multi-Dimensional Decomposition: Hyperspaces hyperspace A hyperspace is a concerns space whose structure supports our approach to multi- dimensional separation of concerns. Concerns are grouped into dimensions, giving hyperspaces an explicitly multi-dimensional structure. A dimension of concern is a set of concerns that are disjoint (i.e., they have no units in common).

17. 17 Personnel Software - Hyperspaces Code Class Feature Employee Research Sales Secretary Artifact Payroll Personnel Requirements Design The Hyperspace is a multi dimensional space. The Hyperspace is a multi dimensional space. Axes are dimensions of concern Axes are dimensions of concern Points on axes are concerns Points on axes are concerns Software units fall at points in the space Software units fall at points in the space Encapsulation and composition via Hyperslices and Hypermodules Encapsulation and composition via Hyperslices and Hypermodules

18. 18 Hyperspaces (cont.) A hyperspace can contain many hypermodules realizing different modularizations of the same units. Systems can be composed in many ways from hypermodules. Hypermodules are not, in general, complete, executable programs.

19. 19 Hyperspaces - Advantages comprehensibility The explicit identification of concerns and dimensions, and the alignment of units according to concerns, are significant aids to comprehensibility. traceability Hyperspaces are intended to include artifacts from all phases of the software lifecycle (e.g., requirements, design, code), and the alignment of units promotes traceability. Changes that add functionality Changes that add functionality can always be accomplished by adding new units, and either including them within existing hypermodules or adding new hypermodules. limits the impact of all changes The structure of hypermodules and their composition rules significantly limits the impact of all changes.

20. 20 Using Hyper/J – for personnel software

21. 21 Class Feature Employee Research Sales Secretary Employee Research Sales Secretary Personnel name() check() print() position() pay() EmployeeResearchSalesSecretary Basic Personnel hyperspace name() check() print() position() pay() name() check() print() position() pay() name() check() print() position() pay() hyperspace payrollPlusPersonnel composable class Personnel.*;

22. 22 Different organization – Different requirements No need for payroll information Different business rules Each employee must have exactly one manager.  Mix-and-match the payroll feature.  Modify an existing well-formed constraint

23. 23 On-demand remodularization Hyper/J permits developers to identify and noninvasively encapsulate new concerns at any time Including concerns that are scatterd across, and tangled within existing software.

24. 24 On-demand remodularization The developer needs to identify those pieces of the existing software that are part of the new concern(s) concern mapping And express this information in Hyper/J using a concern mapping: package Personnel: Feature.Personnel operation position: Feature.Payroll operation pay: Feature.Payroll By default, all members of the classes and interfaces in the Java package Personnel belong to the personnel concern in the feature dimension The subsequent statements override this to say: positionpay Any method named position or pay belongs to the payroll concern in the feature dimension (irrespective of its class)

25. 25 Hyper/J creates a hyperslice for each feature (each row) name() check() print() name() Position() pay() Identification of Concerns name() Position() pay() name() Position() pay() name() Position() pay() Class Feature Employee Research Sales Secretary Employee Research Sales Secretary Payroll Personnel name() check() print() name() check() print() name() check() print() EmployeeResearchSalesSecretary Employee ResearchSalesSecretary public float pay() { System.out.println ( “Paying” + name() ); return _salary; }

26. 26 Declarative Completeness name() Position() pay() name() Position() pay() name() Position() pay() Class Feature Employee Research Sales Secretary Employee Research Sales Secretary Payroll Personnel name() check() print() name() check() print() name() check() print() name() check() print() Employee ResearchSalesSecretary name() Position() pay() Employee ResearchSalesSecretary Hyper/J inserts abstract declarations for any members referred to, but not implemented within the hyperslice

27. 27 Composing hyperslices The developer needs to write a hypermodule declaration: hypermodule PayrollPlusPersonnel hyperslice: hyperslice: Payroll, Personnel; relationship relationship: mergeByName; end hypermodule Name the hypermodule List of hyperslices to be composed The relationship section lists all the ways in which the hyperslices are related

28. 28 Class Feature Employee Research Sales Secretary Employee Research Sales Secretary PayrollPlusPersonnel name() check() print() position() pay() EmployeeResearchSalesSecretary name() check() print() position() pay() name() check() print() position() pay() name() check() print() position() pay() Composing hyperslices (cont.) What happened with the method name () ? PayrollPlusPersonnel.Employee

29. 29 Composing – general strategies mergeByName Units in different hyperslices, that have the same name correspond and should be merged. nonCorrespondingMerge Units in different hyperslices accidently have the same name, but are not actually related to one another. This strategy does not work correctly and is disabled! overrideByName The last unit (according to the specification order) should override the others.

30. 30 What about the changes to the business rules? method Personnel.Employee.check : BusinessRule.ThreeManagers dimension Creates a new dimension: BusinessRule ThreeManagersconcern And creates the ThreeManagers concern on that dimension. method SingleManagerPkg.Employee.check: BusinessRule.OneManager OneManagers concern Creates the OneManagers concern on that dimension.

31. 31 Changes for Business Rules Feature None Class Payroll Personnel Business Rule ThreeManagersOneManager Position() pay() Employee name() check() print() Employee check() Employee check() Employee Compose for new one-manager check Compose for original 3 managers check

32. 32 HyperJ - summary With HyperJ, a program can be decomposed according to different concerns. New separate modules can be created, in standard Java, that encapsulate concerns from scratch, without modifying the rest of the program or interfering with the work of other developers. Modules can also be extracted from existing Java programs. Selections of these modules can then be integrated to yield programs that are executable on standard JVMs. Multiple system decompositions can be created simultaneously and new decompositions added at any stage of the software development lifecycle. HyperJ helps in managing the interactions across different decompositions. HyperJ also provides a powerful composition capability, which can be used to combine separated concerns selectively into an integrated program or component.

33. 33 Hyper/J vs. Aspect/J tool  Hyper/J is a tool language  Aspect/J is a language  Hyper/J supports integration of multiple models  Aspect/J supports augmentation of single model  Hyper/J – composing and decomposing can be done at any time.  Aspect/J – incremental changes only