I had hoped to get back to finishing the Action Language overview which I put on hold to mull over some choices I have to make. I sometimes find that putting off an arbitrary choice for a while can lead to a better choice later. I have found that making the wrong design choice can lead to lots of rework later. Here I am looking forward to providing Action Language code for all the mathematically dependent attributes in the metamodel. However, I want to be sure the Action Language addresses my requirements.
Instead, I implemented EnumeratedSubtypeType allowing users to determine the current subtype of a subtype-supertype relationship. This will allow users to switch (using the new switch statement) on a subtype without needing to perform multiple subtype-supertype relationship navigations. I also implemented EnumeratedStateType allowing users to determine the current state of a state model. OOA91 gave users access to the current state of a state model while OOA96 dropped this feature. OOA09 gives users access to current state since it is very useful for bridging and debug code. OOA09 recommends that both current subtype and current state should primarily be used with the new switch statement since all cases must be supplied and an error will be reported if a new case is required or an old case is redundant. Both types are always predefined and can be used as attribute types. They only appear as browsable types below subtype-supertype relationship and state model respectively when they are referenced by one or more attributes or data items.
I also rewrote the entity (object and terminator) key letters calculation logic so that key letters are always unique. Prior to Build 014 (the next build), non-unique key letters would simply be shown in red. The new logic which is discussed in detail in the previous blog now always generates unique key letters.
On an Action Language related issue, I managed to download the latest copy of Mentor Graphics BridgePoint UML Suite Object Action Language (OAL) manual. The main changes from OAL02 involve support for components, interfaces, ports and inter-component communications. Some form of array access which is not discussed in the body of the document also appears in the syntax grammar. However, I was surprised not to see a new variable declaration statement since I had previously spotted a BridgePoint pre-release note that suggested a variable declaration statement was going to be added. I won't be providing any support for components or interfaces in OOA Tool since it adds nothing (in my opinion) to OOA or xtUML. I will however be defining a variable declaration statement which is sorely missing from OAL.
Finally, I just want to mention that a new Executable UML group has been created by Lee Riemenschneider on LinkedIn. I added a few postings and I hope the group will provide a useful forum for Executable UML (and Shlaer-Mellor) specific discussions.
6 comments:
Isn't the point of object orientation to avoid type/case specific code through the use of polymorphic object hierarchies?
Polymorphic methods only avoid type/case specific code if you take the view that adding a new implementation method is better than adding a new case to a switch statement. In traditional object-oriented programming languages (e.g. Java) supported by an IDE then this view is almost certainly true. Especially since switch statements in languages such as Java and C++ have dangerously loose semantics. However, if you use Shlaer-Mellor OOA to decompose your problem into an information model and use a CASE tool such as OOA Tool then adding a new case to an OOA09 Action Language switch statement is probably better than adding a new implementation method since there is a data rather than method focus and any switch statements missing a case or with an extra case are flagged immediately.
It's good that there is much better integrity checking in the OOA language, but isn't the point one about centralised & automated versus distributed & hand created case selection code? With the latter requiring more maintenance effort to keep it correct?
OOD uses a number of design heuristics, and one of these is the open-closed principal (a class should be open to extension and closed to change), which so many design patterns exemplify. Are you suggesting that OOA should work to a different set of rules?
I'm not sure about your first point since polymorphic methods are distributed not centralized while switch statements keep type specific implementation logic in one place. Furthermore, polymorphic methods aren't any more automated than switch statements. An IDE can generate empty implementation methods but a CASE tool can also generate empty switch cases if requested.
The second point is valid for traditional object-oriented design and programming which is concerned with class level reuse. OOA isn't concerned with class level reuse at all. Shlaer-Mellor OOA/RD facilitates reuse at the service domain and architectural domain level. Even Executable UML (xtUML) which is closer to tradional OOD than Shlaer-Mellor is, isn't concerned with class level reuse, e.g. all generalizations are disjoint and complete. So yes, OOA does work to a different set of rules to tradional OOD. In fact, one doesn't have to use OOD at all with Shlaer-Mellor OOA/RD or Executable UML/MDA.
In general, I don't think that the distinction between OOD and OOA is well understood, and the distinction between (main stream) OOA and SM-OOA is definitely not understood. That is to say, for most a class is a class is class, even though they are thinking in terms of OOD and C++ classes. I hold OOA distinct from OOD until the one morphs into the other; I'm not a practitioner of SM-OOA (although I'd like to be as it would cut out the tedium in the OOD [:-;]).
There, therefore, seems to be a gap in the common understanding that SM-OOA practitioners need to fill by describing the differences in the modelling approaches and rules. There are clearly different areas of emphasis and these need to be brought to the fore. I suspect that the failure to comprehend such matters is what hinders the majority from understanding SM-OOA. I'm clearly sketchy on some of these issues too!
Having said that, one thing that is nagging me is the issue of coupling. The "open-closed principal" is essentially about achieving high cohesion and low coupling and this greatly facilitates maintenance. You seem to rewrite this as reuse, but this seems to miss the point of dealing with change. Even SM-OOA models have to deal with change, and yet it seems that there can be quite a bit of coupling between the data in a class and other modelling elements use of it. This, in part is what I meant by "centralised & automated versus distributed & hand created" in that OOD aspires to placing behaviours that relate to a class in the class (centralised) and not to have such things distributed out side of it. And from a polymorphic methods point of view, this means designing to the (abstract) interface and not to the implementation (classes). Some degree of reuse may directly arise (I don't deny that), but the point is that coupling is greatly reduced and change is greatly facilitated.
We could of course be talking at cross purposes, but if this is the case then I come back to my opening point.
Shlaer-Mellor OOA is really entity-relationship modelling with subtype-supertype relationships (generalizations in UML) thrown in. Shlaer-Mellor adds behaviour via object lifecycles and assigners. State actions are then decomposed into processes. Polymorphism was only added to Shlaer-Mellor later on in the form of polymorphic events (defined in OOA96). OOA09 (my evolution of Shlaer-Mellor) adds polymorphic attributes and may later add polymorphic processes (I'm not sure whether they are needed yet). OOA does not assume OOD will be used later.
For me, the most important distinction between structured analysis and OOA is the generalization concept. Polymorphism is an add-on feature here not a crucial feature.
Most UML users creating what they think are OOA models are really creating early OOD models since they assume OOD will be used and often start to add OOD information during analysis as a result.
Coupling within a domain often involves high cohesion except where a domain has been partitioned into subsystems and analysts should attempt to define subsystem boundaries where cohesion is lower. The important thing to note in Shlaer-Mellor is than an object instance only represents a slice of a component instance in the deployed system. An object instance may have a number of one-to-one counterparts in other domains. The coupling between domains is only defined in bridges. The implementation of the component instance is generated by translating all the domains and bridges in an application into deployment code.
The open-closed principle you talk about helps manage complexity and change that largely arises from the lack of adequate domain partitioning supported by translation. It is difficult for a developer to understand that a Shlaer-Mellor domain will not need to expand or change indefinitely unless they understand how Shlaer-Mellor bridges work. For example, if someone adds persistence or logging to a set of classes in UML then they will probably introduce polymorphic methods to minimize future changes that would result from different persistence or logging requirements in the future. In Shlaer-Mellor, persistence and logging would be defined in completely different domains with bridges linking them together. There should be no need to change the original domain to add the new behaviour since there would be no concept of persistence or logging in the original domain.
It is unfortunate that Project Technology and Kennedy Carter redirected their efforts from Shlaer-Mellor to Executable UML when they did since UML doesn't really support the notion of bridges. Package dependencies are second-class citizens in UML with minimal semantics. This has lead to bridges being marginalized in current xtUML and xUML documentation. Anyone who trys to implement Executable UML using a UML metamodel is at a major disadvantage. I have defined a Shlaer-Mellor metamodel for OOA09 and a two-way notational mapping between OOA and xtUML. This has allowed me to formalize domains and bridges properly. Although bridges haven't been fully implemented in OOA Tool yet!
Post a Comment