Download - Proposed Ideas

04/19/23 ABB Workshop 1

Proposed Ideas

Therapon Skotiniotis Karl Lieberherr

Northeastern University

Boston, MA 02115 USA


Traversal Related Concerns

• AIP performs lookups on hierarchical structures– NamePaths, Aspect Directory etc

• Demeter Theories could be deployed (XPath)– User friendly specification of Paths

from GUI via Valve to ValveTemperacture

from GraphicDisplay to *

• Adaptable specification

• Ability to add behavior on a group or substructure through the introduction of Demeter Style Visitors


Traversal Related Concerns(cont)

• Demeter Style Visitors– Perform operations before/after/around a specific node that is

being visited– Encapsulates behavior in a separate file – Easier extensibility

• Potential operations – Maintenance of Structures– Recording of dependencies

• Type Level ASK• Instance Level ASK

– Copying of structures – Ready made global operations on structures



A/C

getRTemp

Room

Valve

getTemp



A/C

getRTemp

Traversal + Visitor:from Room to getTemp(VmakeComponent)

Valve

getTemp

Valve_temp_compRoomRoom_climate_comp

Traversal + Visitor:from Room to getRTemp(VmakeComponent)


AOSD already in AIP

• “The house that ABB build”– Trackers and Hooks

• The ideas are really close to – JoinPoint model

• Hooks are a restricted pointcut for creation, modification and alteration

• Trackers are a bit more flexible– You can define the AIP aspects upon which you can capture

• Creation, Deletion, Setters, Notifications


AOSD already in AIP (cont)

• Adding – Method invocations will give a similar JoinPoint model as that of

AspectJ.

• Can be accomplished – Using a language specific approach ala AspectJ– Introduce a “Intermediary” component to delegate according to the

pointcuts provided by the programmer – Through a design constraint enforced by an API (yet another one)

• Issues – Language specific

• Harder to implement • Programmers need to learn a new sub-language


AOSD already in AIP (cont)

• Issues (cont)– Intermediary component

• A new tool rewrites the programmer’s source (preprocessor) making all necessary arrangements.

• Compile time + Runtime performance issues.• Automatically tangle code harder to provide runtime adaptability• Programmer can be oblivious to the whole mechanism

– Just uses the extra facility if he needs to.

– Design Constraints via an API • Extra components introduced at Framework level (might affect

stability and/or performance)• Maintain runtime adaptability.• May become too verbose for the programmer


Reuse Reuse Reuse

• Fine grained separation + subjective view make reuse between systems difficult– Duplicated information

– Dependencies between views • Underlying implementation

• Context sensitive dependencies

• HyperJ Solution– HyperSpaces and Multi Dimensional Separation of Concerns

– Binary manipulation. No need of source code

– Language specific (if at all possible)


Component Based Reuse

• The ability to reuse “building blocks” to provide– Similar solutions to similar problems– Create a new solution by adopting multiple collaborations together

and then applying them to the underlying system

• Capture parts of the systems structure that are paramount to the solution

• Define what abstract component types are expected/provided only

• This requires a coordination between – Structural Dependencies within Structures (Directories in AIP)– Behavioral Dependencies between entities (DLL’s ASO’s etc)


Component Based Reuse (cont)

• Structural Dependencies – XPath and a default visitor could capture structural dependencies

– Trackers and Hooks can be deployed by the programmer to capture behavioral dependencies



• XPath– Follows the same idea

– Allows also for documenting AIP structures

to * (MakeHMTLVisitor)

• “Write once runs on any Structure”