Home › Forums › Open Discussion

HyperJ and Feature Heuristics

Mon, 03/17/2003 - 07:33 — Mark Ng

G'day,

FDD and HyperJ looks like a good combination, since both deals with
features that essentially cuts across class boundaries. So, similar that I
think heuristics used for managing the interaction of features might be
applicable to the management of HyperSlices.

Is there any freely available guidelines on managing the interaction of features ?

Thanks,
mark

‹ The Psychology of Programming Agile Development Conference June25-28, 2003 Salt Lake City, USA ›

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Sun, 03/23/2003 - 02:15 — szego
szego's picture

Link Please

Can you please post some links to HyperJ? As I've never heard of it, it's hard to answer your question.

PaulS :(

Wed, 03/26/2003 - 04:15 — Mark Ng

Sorry for the omission. Hy

Sorry for the omission.

Hyper/J is a tool from IBM that supports multi-dimensional separation of concerns (MDSOC).
This concerns are similar to features, in order to implement a concern it requires modification to a bunch of related classes.

HyperJ allows developers to define separate concerns in a custom language and weave them together to produce Java classes. So, you can implement features without actually having to change classes directly.

A related tool is Aspect/J, but it handles non-functional requirements, whereas HyperJ is for functional requirements.

Sun, 03/30/2003 - 04:30 — szego
szego's picture

Problem Domain vs. Implementation

I think there's a fundamental difference here between features and concerns - but I could be wrong.

After reading several pages on MSDOC, I still couldn't find a concrete definition of a concern that put it in context. There are nice abstract descriptions like a "goal, concept or purpose". However an example they used was something like "printing, persistence and display capabilities".

Features in FDD on the other hand are all about the problem domain - they come from a decomposition of a description of the domain we are concerned with modelling in process 1 - Develop an Overall Model. They are expressed in client terms - there is no technology involved here.

So my initial guess is that they're focused on different things. The only similarity that I see is precisely what you've observed: that the implementation of each requires modification to a bunch of classes.

So before I make any more observations - have I missed the point about MSDOC?

PaulS.

Wed, 04/09/2003 - 06:51 — Mark Ng

Hi Paul, Yes,. Concerns an

Hi Paul,

Yes,. Concerns and Features are rather different. Concerns are more design-oriented whereas Features are business-oriented. But they both do cross-cut classes, features do end up being expressed (implemented) as technology, which could effectively be a concern (or a set of concerns). Or is my understanding of Features way off ?

So, I was thinking maybe heuristics to manage interactions, conflicts of features might be able to be (creatively) applied to managing of concerns.

Thanks,
Mark