READER COMMENT

This comment is about:

By Ivan Ryant, Prague, Czech Republic
http://sweb.cz/ryant/index_en.html

as we could expect, the article "Use Cases and Aspects - Working Seamlessly Together" by Ivar Jacobson raised not only my reaction, which I naturally follow with curiousness. The article "On Getting Use Cases and Aspects to Work Together" by R. Pawlak and H. Younessi emphasizes much of my objections to the original Jacobson's article (shortly said: Mr. Jacobson missed to mention an explicit requirement for a weaving mechanism in early phases of project lifecycle). So far so good.

Unfortunately, although Mr. Pawlak and Mr. Younessi explained AOP basics and the mechanism of weaving, much more essential thing in relation to the original Jacobson's article is not, what the authors succeded to explain (correctly, as I can asses), but what they have missed to say. I can see, combination of use cases and AOP promises to bring solutions to much broader range of problems than the Pawlak's and Younessi's paper involves. It is not a complaint, I realize, such is the world: the most important things in life are those, that are not spoken of.

(1)
The first thing, why we specify use cases, is pragmatics of the system. What Mr. Younessi and Mr. Pawlak say, is definitely correct (however ignored in most textbooks I know), that use cases specify communication protocols between actors and the system, but it is the secondary thing: protocols without context and purpose don't make sense. Nonetheless, mixing use cases and components seems to be rather inappropriate. Notion of use cases concerns early phases of project development, while components are pieces of implementation. Remark (4) returns to the importance of communication protocols in more detail.

(2)
As Ivar Jacobson explained in his tutorial in Frankfurt in 1994, particular use cases express purpose of the system in relation to particular actors (or user roles). Set of use cases of a system expresses plurality of purposes in accord with particular interests of particular actors. The question (and a burried dog) is, whether the use cases can make up together a single system - it is question of consistency. If the use cases are not logically consistent, the system can not be designed or implemented. The earlier is this fact discovered, the cheaper is cancellation of the project.

(3)
The authors state, that implementation of use cases is distributed among components. It is definitely possible (frontiers of components can be set quite deliberately, however), but this way the particular purpose of the use case gets implanted into the component and the component can not be reused to other purposes any more. I.e., distribution of use cases among components contradicts the principle of reusability. On the other hand, control objects, that typically implement use cases (or other implementations of use cases) can (and should) be kept separate from reusable components.

(4)
The authors mention only hierarchical structure of use cases, but they don't say, what hierarchy it is: hierarchy of purposes? conceptual hierarchy of subsystems in the system? architecture of system design? hierarchy of components? hierarchy of control? OK, any feasible verification of logical consistency requires a single supergoal and a hierarchy of subgoals, i.e. we need hierarchization of the systems specification, which is expressed by use cases. Similar hierarchical principle decomposes system into subsystems conceptually, according to hierarchy of purposes (esse est unum, verum, bonum - likes to say my favourite ontologist Halik). But the requirement of robustness (Jacobson!) or reusability may contradict strictly hierarchical structuring. Also systems architecture definitely doesn't require hierchical order, neither the communication protocols do. Communication protocols specify synchronization in the system generally: they may suggest more strict systems structure as well as more general structure than just the hierarchical one. And finally, specific requirements on deployment (esp. if system is required to be distributed) may contradict hierarchical structure of control (see remark 5). It seems, other structures can reflect some architectures (e.g. peer-to-peer systems) with significantly better fidelity (--> traceability), can reduce complexity of the system much more than any hierarchy and allow much more comprehension in analysis as well as more robust design.

(5)
Linearization of control flow is probably a good intuitive illustration, nonetheless not every system can have its control flow linearized. For example, take into account that use cases may synchronize each other not only using internal communication channels inside the system, but they even may synchronize each other through some unknown channels in the environment. Or what can do real-time requirements to the system's synchronization (real time is also a phenomenon external to the system)! Some reactive and esp. distributed systems cannot get linearized (nothing similar to "time" in such systems can be totally ordered!) but, on the other hand, just the distributed systems are perfect candidates for OO analysis in Jacobson's style based on use cases.

Take please this declaration of problems as a theme to be taken into account (not ignored), or as a contribution to a discussion, because I have to deal with those problems in my ordinary software-engineering practice. It is not meant to be a rigid dogma that I wish to teach You (I believe, You know it well enough Yourselves). It is just an effort to keep the topic as broad and promising utility, as Mr. Jacobson has delimited it in his article.

Sincerely Yours, Ivan Ryant

14 February 2004