Active Class
Jim Logan
If I state the following in a model, what would it mean?
- A is an active class (isActive is true)
- B and C are specializations of A, but are not specified as active classes (isActive is false)
-Jim
Remy Fannader
Remy.
--
You received this message because you are subscribed to the Google
Groups "UML Forum" group.
Public website: www.umlforum.com
To post to this group, send email to umlf...@googlegroups.com
To unsubscribe from this group, send email to
umlforum+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/umlforum?hl=en?hl=en
Ashley at Metamaxim
What an excellent question!
Personally, I find the notion of an "active object" troubling. It seems to me that, if anything, it is a property of how you choose to implement an object and not of the object itself.
For instance, it is sometimes possible to implement the same behaviour as either a process in its own right on a thread (in which case it is active) or as a co-routine invoked from somewhere else within the same thread to execute the next part of its behaviour (in which case it is not active).
Rgds
Ashley
Remy Fannader
Active classes represent external objects with the capacity to interact with the system. Hence they must be identified at requirement level disregarding the way they will be implemented.
http://caminao.wordpress.com/what-is-to-be-represented/objects/physical-objects/
http://caminao.wordpress.com/how-to-implement-symbolic-representations/patterns/representation-patterns/entry-points/
Remy
Dan George
separate state machine for each instance) to a passive class? I'm not
coming up with real-world situations where a passive thing is really a
specialization of an active thing. It would seem to be a really
special case for a passive object to be appropriately substitutable
for an active one. For example, given an active class Pet (perhaps
from Lahman's pet care facility) and its specialization, Dead Pet,
will they both react appropriately to a Food Dish Has Food event? Of
course, that example doesn't work. Is there one that does?
Dan
On Oct 29, 12:43 pm, Ashley at Metamaxim
> Hi Jim
>
> What an excellent question!
>
> Personally, I find the notion of an "active object" troubling. It seems
> to me that, if anything, it is a property of how you choose to implement
> an object and not of the object itself.
>
> For instance, it is sometimes possible to implement the same behaviour
> as either a process in its own right on a thread (in which case it is
> active) or as a co-routine invoked from somewhere else within the same
> thread to execute the next part of its behaviour (in which case it is
> not active).
>
> Rgds
> Ashley
>
> On 28/10/2011 21:12, Jim Logan wrote:
>
>
>
>
>
>
>
> > Hi all,
>
> > If I state the following in a model, what would it mean?
>
> > * B and C are specializations of A, but are not specified as active
H. S. Lahman
>
> Personally, I find the notion of an "active object" troubling. It
> seems to me that, if anything, it is a property of how you choose to
> implement an object and not of the object itself.
I suspect you are bothered that the casual definition is that any object
with a state machine is active and state machines specify private object
implementation. But that's just a convenient description because the
translation methodologies, starting with Shlaer-Mellor in the early
'80s, require that all objects with behavior responsibilities must have
a state machine.
So I agree it is somewhat sloppy to link it to object state machines.
However, I think the real intent was simply to identify objects that
have behavior responsibilities (i.e., execute problem space rules and
policies). It is often useful to distinguish between objects that are
just dumb data holders (i.e., have only knowledge responsibilities) and
those that have behaviors. That distinction has nothing to do with
object implementation; it is about the intrinsic nature of the object.
--
Life is the only flaw in an otherwise perfect nonexistence
-- Schopenhauer
Rene Descartes went into a bar. The bartender asked if he would like a drink. Descartes said, "I think not," and disappeared.
H. S. Lahman
H.la...@verizon.net
software blog: http://pathfinderpeople.blogs.com/hslahman/index.html
H. S. Lahman
What situation would call for specializing an active class (one with a separate state machine for each instance) to a passive class?
Note that in an OO generalization tree, as soon as you define a property, it applies to all descendants. So as soon as you define a single behavior responsibility for a superclass, that superclass and all descendant subclasses become active.
H. S. Lahman
Note that if A is a subclass of X, which has only knowledge responsibilities, X is not active but A is. IOW, the active property itself is not inherited; it simply describes the the way properties are defined in a given class and happens to follow the way properties are inherited by subclasses in OO generalizations.
Ashley at Metamaxim
I think your definition does not correspond to UML's. For instance, it says in the UML superstructure specification: "In case of active objects, where each object has its own thread of execution, ..."
If we this together with your definition we conclude that "every external object has to be on a separate thread". This would be silly in some situations -- for instance where the population of external objects is very large but they don't do anything very frequently. It would then be daft to give each its own thread.
I suppose my point is that is the notion of "active object" is slippery!
Rgds
Ashley
Rafael Chaves
http://www.ts.mah.se/RUP/RationalUnifiedProcess/process/glossary.htm#activeclasshttp://www.ts.mah.se/RUP/RationalUnifiedProcess/process/glossary.htm#activeobject
Active objects "can initiate control activity", instead of being
onlyreactive.
> I suppose my point is that is the notion of "active object" is slippery!
language features for very different purposes. The higher the level of
abstraction, the more room for different interpretations.
Cheers,
Rafaelhttp://abstratt.com/blog
On Oct 31, 12:04 pm, Ashley at Metamaxim
> Hi Remy
>
> I think your definition does not correspond to UML's. For instance, it
> says in the UML superstructure specification: "In case of active
> objects, where each object has its own thread of execution, ..."
>
> If we this together with your definition we conclude that "every
> external object has to be on a separate thread". This would be silly in
> some situations -- for instance where the population of external objects
> is very large but they don't do anything very frequently. It would then
> be daft to give each its own thread.
>
> I suppose my point is that is the notion of "active object" is slippery!
>
> Rgds
> Ashley
>
> On 30/10/2011 05:39, Remy Fannader wrote:
>
>
>
>
>
>
>
> > Hi Ashley,
> > Active classes represent external objects with the capacity to
> > interact with the system. Hence they must be identified at requirement
> > level disregarding the way they will be implemented.
> >http://caminao.wordpress.com/how-to-implement-symbolic-representation...
>
> > On 29 October 2011 21:43, Ashley at Metamaxim
>
> > Hi Jim
>
> > What an excellent question!
>
> > Personally, I find the notion of an "active object" troubling. It
> > seems to me that, if anything, it is a property of how you choose
> > to implement an object and not of the object itself.
>
> > For instance, it is sometimes possible to implement the same
> > behaviour as either a process in its own right on a thread (in
> > which case it is active) or as a co-routine invoked from somewhere
> > else within the same thread to execute the next part of its
> > behaviour (in which case it is not active).
>
> > Rgds
> > Ashley
>
> > On 28/10/2011 21:12, Jim Logan wrote:
> >> Hi all,
>
> >> If I state the following in a model, what would it mean?
>
> >> * B and C are specializations of A, but are not specified as
>
> >> Are instances of B and C active objects? I don't see anything in
> >> the UML spec about this.
>
> >> -Jim
> >> --
> >> You received this message because you are subscribed to the Google
> >> Groups "UML Forum" group.
> >> <mailto:umlforum+u...@googlegroups.com>
> >> http://groups.google.com/group/umlforum?hl=en?hl=en
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "UML Forum" group.
> > <mailto:umlforum%2Bunsu...@googlegroups.com>
Remy Fannader
When slipping try to find some solid catch. In that case it's that the "active" concept has nothing to do with implementation. So the "thread" argument is irrelevant.
Remy.
ashley....@metamaxim.com
> When slipping try to find some solid catch. In that case it's that the
> "active" concept has nothing to do with implementation.
For me, the "active" concept is slippery too. Is "Customer" an active
object in a banking system? What about "Account"?
> So the "thread" argument is irrelevant.
OK. You should tell the authors of UML! (Although, to give them their due,
they have attempted to expunge the word "thread" from their definition of
"active". They just haven't quite succeeded yet!)
I once, as a perverse experiment, implemented a real-time simulation of
bank of elevators (including the elevators themselves, the request
buttons, and the algorithms that determined which elevator should respond
to a request at a floor, and a simple graphical display) as a single
monolithic COBOL program. Conceptually, the sofware consisted of around 70
parallel processes, but they were all implemented using a form of
co-routining.
I don't think I could tell you which "objects" in this software were
"active".
Rgds
Ashley
>>> - A is an active class (isActive is true)
>>> - B and C are specializations of A, but are not specified as active
Remy Fannader
First of all, active objects are system ones, i.e symbolic representation of business ones.
Second, only physical objects can interact with the system, so class for Accounts is not active.
Third, interactions are to be real (events), not symbolic (language based), so individual customers (corporate ones are not even physical) are not, but ATM are.
There is no problem or ambiguity with active classes. If you need more convincing have a look at real-time modelling (eg H. Gomaa).
Remy.
ashley....@metamaxim.com
An "ATM" is an "automatic teller machine". Suppose I use a human teller
and the human teller types my request to withdraw money into a keyboard,
is there any "active object"?
Perhaps the active object is now the keyboard? I think the answer must be
yes, as the human teller could just be use keyboard on another ATM under
her desk, and this we think is an active object.
However, I cannot see that "the keyboard" qualifies as an object that (per
the UML specification):
". . . as a direct consequence of its creation, commences to execute its
classifier behavior, and does not cease until either the complete behavior
is executed or the object is terminated by some external object."
However, I can understand that "non-persistent events" are special, in
that such events require immediate dedicated attention or are lost. This
could be true of the key pressses on a keyboard or the events at an ATM.
(And perhaps such events are what you call "not symbolic", as symbols
provide a medium for persisting and therefore for buffering and processing
later.)
But if this really is the nub of the matter I think the epithet "active"
properly belongs to event and not to object, and the definition of
"active" should be quite different from that currently given in UML.
Rgds
Ashley
lwriemen
> Note that in an OO generalization tree, as soon as you define a
> property, it applies to all descendants. So as soon as you define a
> single behavior responsibility for a superclass, that superclass and all
> descendant subclasses become active.
>
states, "each instance of the specific classifier is also an instance
of the general classifier".
H. S. Lahman
> I suspect the isActive property was influenced by RUP:
Actually, I believe it predates RUP. In the early '80s the Shlaer-Mellor
methodology for translation recognized that knowledge and behavior
access were quite different (i.e., synchronous vs. asynchronous) and
that would be important for the transformation engine. So 'active' was
used to identify classes that had behavior responsibilities and,
therefore, would require asynchronous messaging infrastructure in the
implementation.
State machines came in because all translation methodologies require an
object with behavior responsibilities to have a state machine. So it
became an idiom to equate 'active' with the object having a state machine.
H. S. Lahman
> First of all, active objects are system ones, i.e symbolic
> representation of business ones.
> Second, only physical objects can interact with the system, so class
> for Accounts is not active.
> Third, interactions are to be real (events), not symbolic (language
> based), so individual customers (corporate ones are not even physical)
> are not, but ATM are.
> There is no problem or ambiguity with active classes. If you need more
> convincing have a look at real-time modelling (eg H. Gomaa).
I don't know where you are getting this, but I have to agree with Ashley
that it is not from UML.
I would add that I don't think it is from OOA/D either because the
notion of 'active' dates back to the early '80s (see my response to
Chaves) and I don't know of any OOA/D methodology that uses it in any
way other than as a class characteristic that may be applied to any
class of objects that have behavior.
I don't know anything about Gomaa, but I do know that other R-T/E
authors I have read -- Mellor, Selig, Douglass, Raistrick -- do not
share your view.
Remy Fannader
Jim Logan
The state machine is something of a red herring. When resolving the requirements and you must abstract objects that have behavior responsibilities (i.e., must execute problem space rules and policies), then you have active objects. If the objects you need to abstract only have knowledge responsibilities, then those objects are passive because they does not do anything; they just know things.
Note that in an OO generalization tree, as soon as you define a property, it applies to all descendants. So as soon as you define a single behavior responsibility for a superclass, that superclass and all descendant subclasses become active.
-Jim
Jim Logan
-Jim
Remy
introducing a warranted concept with a half baked definition like "a
have behavior".
anywhere, and best practices are not substitutes for sound analysis.
Hassan Gomaa is not alone suggesting answers that make sense, and
there is a broad consensus (Douglass included) about external objects
with the capacity to generate non symbolic events.
Hassan Gomaa, "Software Modeling and Design: UML, Use Cases, Patterns,
and Software Architectures", Cambridge University Press (2011)
http://caminao.wordpress.com/how-to-implement-symbolic-representations/patterns/functional-patterns/entry-points/
Remy Fannader.
> software blog:http://pathfinderpeople.blogs.com/hslahman/index.html
Dan George
impossibility of making a passive specialization of an active object
in OO. I'm still curious if there is a case to even want such a
construct.
@Lahman, I must confess my reference to "separate state machines for
each instance" was not an original thought. Shaler and Mellor said it
in the Object Lifecycles book. I suppose you are implying that
behavior responsibility does not have to be represented by a state
machine, right? Your knack for abstraction cannot be overstated :).
On Oct 31, 8:09 am, "H. S. Lahman" <h.lah...@verizon.net> wrote:
> Responding to George...
>
> > What situation would call for specializing an active class (one with a
> > separate state machine for each instance) to a passive class?
>
> The state machine is something of a red herring. When resolving the
> requirements and you must abstract objects that have behavior
> responsibilities (i.e., must execute problem space rules and policies),
> then you have active objects. If the objects you need to abstract only
> have knowledge responsibilities, then those objects are passive because
> Note that in an OO generalization tree, as soon as you define a
> property, it applies to all descendants. So as soon as you define a
> single behavior responsibility for a superclass, that superclass and all
> descendant subclasses become active.
>
> --
> Life is the only flaw in an otherwise perfect nonexistence
> -- Schopenhauer
>
> Rene Descartes went into a bar. The bartender asked if he would like a drink. Descartes said, "I think not," and disappeared.
>
> H. S. Lahman
Remy
You're right about ATM, which may combine external devices (e.g
keyboards or touch-screens) with symbolic processing capabilities. As
it happens H.Gomaa uses that example.
http://caminao.wordpress.com/about/sample-problems/atm/
Gomaa, Hassan. “Software Modeling and Design: UML, Use Cases,
(2011)
>
> >>http://caminao.wordpress.com/how-to-implement-symbolic-representation...
>
> >> >> On 29 October 2011 21:43, Ashley at Metamaxim <
Jim Logan
If there were an OCL constraint stating that class behavior implies an active class, then, because behavior is inherited, all subclasses would also be active. But, there is no such constraint in UML that I've seen.
This might be what HS meant by the following:
On 10/31/2011 11:09 AM, H. S. Lahman wrote:
The state machine is something of a red herring. When resolving the requirements and you must abstract objects that have behavior responsibilities (i.e., must execute problem space rules and policies), then you have active objects. If the objects you need to abstract only have knowledge responsibilities, then those objects are passive because they does not do anything; they just know things.
Note that in an OO generalization tree, as soon as you define a property, it applies to all descendants. So as soon as you define a single behavior responsibility for a superclass, that superclass and all descendant subclasses become active.
I believe "a class with behavior responsibilities" can mean multiple things, such as "a class that has methods" or "a class that has classifier behavior". I originally interpreted what he wrote as, "a class that has methods must be an active class", which is obviously false. Given the Executable UML context of his book, where problem domain classes run state machines that invoke behaviors in response to signals, I can see an interpretation that makes his statements true. I interpret what he wrote as follows (with my clarifications in italics):
When resolving requirements, you must abstract objects that have behavior responsibilities that execute in response to received signals (i.e., must execute problem space rules and policies in response to received signals), then you have active objects. If the objects you need to abstract only have knowledge responsibilities (e.g., accessors and mutators), then those objects are passive because they do not do anything related to problem space rules and policies; they just know things.This rephrasing agrees with the OCL constraint, above and makes sense to me. Would you agree with this rephrasing, HS?
-Jim
RJB
dates back to Michael Jackson
in 1975...
I went back to the UML2.0 specification...
---------------
An active object is an object that, as a direct consequence of its
and does not cease until either the complete behavior is executed or
the object is terminated by some external object.
control”.) The points at which an active object
responds to communications from other objects is determined solely by
the behavior of the active object and not by the
invoking object. If the classifier behavior of an active object
completes, the object is terminated.
generalization
A taxonomic relationship between a more general classifier and a more
specific classifier. Each instance of the
specific classifier is also an indirect instance of the general
classifier. Thus, the specific classifier indirectly has
features of the more general classifier. See: inheritance.
inheritance
The mechanism by which more specific elements incorporate structure
and behavior of more general elements.
----------------
SO I think that any specialized class will also, automatically,
active... but it can change the inherited behaviors.
Hope this helps
RJB
H. S. Lahman
@Lahman, I must confess my reference to "separate state machines for each instance" was not an original thought. Shaler and Mellor said it in the Object Lifecycles book. I suppose you are implying that behavior responsibility does not have to be represented by a state machine, right? Your knack for abstraction cannot be overstated :).
First, a quibble for lurkers. I have a problem with the way 'instance' is overloaded in the literature by often making it synonymous with 'object'. An object is, itself, an abstraction of an identifiable problem space entity; it just happens abstract it in the same fashion as all other objects that are members of its class. So an object exists as a conceptual entity as soon as the designer thinks about it. OTOH, in a run time software context objects are instantiated and removed during the execution and it is very useful to know when an object is available for collaboration in the solution flow of control. So I think the notion of 'instance' should be reserved for objects that exist in a run time context. I believe S-M and you were using 'instance' in this more restricted sense.
Next, at the risk of being an Apostle of the Obvious, the notion that each object has its own state machine really just means that each instance can be in a different state of the machine. All the objects within a class will have the same state machine; their instances just transition through it independently.
Finally, I am, indeed, arguing that a behavior responsibility does not have to be represented by a state machine. In fact, I would argue a behavior responsibility never has a state machine, but I am concerned that isn't what you meant. My view is colored by the translation approaches that date back to the early '80s. To provide the necessary rigor of specification that literal-minded code generators require, those approaches insisted on some constraints that UML does not require.
Thus any object with a behavior responsibility must have a state machine. The object's individual behavior responsibilities then all become actions within that object state machine and the transitions define problem space constraints on the relative sequencing of the behaviors within the solution's flow of control. Behavior responsibilities are also supposed to be logically indivisible at the subsystem level of abstraction, so that precludes an individual behavior having a state machine with multiple actions. But those are only methodological constraints and they need to be spelled out in an MDA profile for using UML.
<aside>
There is a lot of wiggle room around synchronous services that just access knowledge and can be quite complex, such as a 'transpose' operation on a Matrix class. Thus the definition of 'behavior responsibility' itself is methodological. The one I subscribe to is that a behavior responsibility implements business rules and policies unique to the particular subsystem subject matter's problem domain. Under that rather narrow definition, any operation that just modifies an object's knowledge attributes without executing unique problem domain rules and policies becomes just a knowledge setter (aka synchronous service), regardless of how complex the operation is. Thus Matrix.transpose is just a knowledge setter because the operation is wholly specified by a much broader problem domain (mathematics) than that of the containing subsystem.
</aside>
-- Life is the only flaw in an otherwise perfect nonexistence -- Schopenhauer Rene Descartes went into a bar. The bartender asked if he would like a drink. Descartes said, "I think not," and disappeared. H. S. Lahman
H. S. Lahman
The state machine is something of a red herring. When resolving the requirements and you must abstract objects that have behavior responsibilities (i.e., must execute problem space rules and policies), then you have active objects. If the objects you need to abstract only have knowledge responsibilities, then those objects are passive because they does not do anything; they just know things.
Note that in an OO generalization tree, as soon as you define a property, it applies to all descendants. So as soon as you define a single behavior responsibility for a superclass, that superclass and all descendant subclasses become active.
I don't see any OCL constraint in UML that states that having behavior in a class implies isActive is true, nor one that states that isActive in a superclass implies isActive in a child class.
If a superclass defines a property for members of that class, then all members of descendant subclasses must have that property. That is a definition of OO generalization. If a superclass has one or more properties that are behavior responsibilities, then it is 'active'. Therefore all descendant subclasses that must have those same properties are also 'active'.
Note that 'active' is about what properties the class defines for its members so whether the superclass is virtual or not doesn't matter. That's why McNeile is correct that it is sloppy to equate 'active' with having a state machine since the state machine will usually only be implemented in the leaf subclass members where all the relevant behaviors are known.
H. S. Lahman
> Active classes offer a good example of UML benefits and limits, namely
> introducing a warranted concept with a half baked definition like "a
> class characteristic that may be applied to any class of objects that
> have behavior".
> The point is, how to decide ?
The notion of 'active' was introduced because it has implications for
the implementation of the model. If an object has no behavior
responsibilities, then the implementation can always provide synchronous
collaborations safely. However, if it has any behavior responsibilities,
then the implementer may have safety issues with a synchronous
implementation. IOW, there is nothing to decide; one can think of
'active' as simply a flag to the model implementer that there may be
safety issues for the implementation of collaborations with the object.
Note that in the translation approaches 'active' is not even in the MDA
profile. That is because it is redundant. In those approaches all
objects with behavior responsibilities must have a state machine. That
means that all behavior collaborations in the model are event-based so
the model already employs asynchronous behavior collaborations. Since
asynchronous communications are the most general, one is guaranteed the
model can always be implemented safely and there is no need to warn the
implementer.
--
Life is the only flaw in an otherwise perfect nonexistence
-- Schopenhauer
Rene Descartes went into a bar. The bartender asked if he would like a drink. Descartes said, "I think not," and disappeared.
H. S. Lahman
H. S. Lahman
The state machine is something of a red herring. When resolving the requirements and you must abstract objects that have behavior responsibilities (i.e., must execute problem space rules and policies), then you have active objects. If the objects you need to abstract only have knowledge responsibilities, then those objects are passive because they does not do anything; they just know things.
Note that in an OO generalization tree, as soon as you define a property, it applies to all descendants. So as soon as you define a single behavior responsibility for a superclass, that superclass and all descendant subclasses become active.
I believe "a class with behavior responsibilities" can mean multiple things, such as "a class that has methods" or "a class that has classifier behavior". I originally interpreted what he wrote as, "a class that has methods must be an active class", which is obviously false. Given the Executable UML context of his book, where problem domain classes run state machines that invoke behaviors in response to signals, I can see an interpretation that makes his statements true. I interpret what he wrote as follows (with my clarifications in italics):
When resolving requirements, you must abstract objects that have behavior responsibilities that execute in response to received signals (i.e., must execute problem space rules and policies in response to received signals), then you have active objects. If the objects you need to abstract only have knowledge responsibilities (e.g., accessors and mutators), then those objects are passive because they do not do anything related to problem space rules and policies; they just know things.This rephrasing agrees with the OCL constraint, above and makes sense to me. Would you agree with this rephrasing, HS?
FWIW, I see this as an example of the problems one gets into when trying to make UML the Mother of Modeling Languages. To capture disparate modeling contexts OMG ends up defining things in contrived ways like "responding to signals" that don't make sense in the original OOA/D context unless one has an MDA profile to say, "just kidding, we really only mean these signals."
H. S. Lahman
Alas, the quotes hit a Hot Button for me that is mostly OT...
> First... the idea of objects that have life histories or life cycles
> dates back to Michael Jackson
> in 1975...
Right. Jackson was far ahead of his time. JSD was may favorite design
methodology in the '70s but I didn't really understand why until the
early '80s. I recall a comparison of models produced by different
structured methodologies. All of them looked pretty much the same except
the JSD design, which was quite different. With 20/20 hindsight I would
describe it as being very OOA-like. However, Jackson himself saw it as a
Structured methodology (i.e., the S in JSD), but it sure had an OO-like
approach.
OTOH, it has been many moons, but I don't recall Jackson using 'active'
in the sense we use it in OOA/D.
>
> I went back to the UML2.0 specification...
> ---------------
> An active object is an object that, as a direct consequence of its
> creation, commences to execute its classifier behavior,
> and does not cease until either the complete behavior is executed or
> the object is terminated by some external object.
> (This is sometimes referred to as �the object having its own thread of
> control�.) The points at which an active object
> responds to communications from other objects is determined solely by
> the behavior of the active object and not by the
> invoking object. If the classifier behavior of an active object
> completes, the object is terminated.
This I find very disturbing. OMG has completely changed the sense of
what 'active' means from the original UML. Here OMG seems to defining an
ongoing action like a polling loop. It also ties the execution of the
behavior to the life of the owning object. BUT...
You will note that in Superstructure 6.2.1 they indirectly describe
'active objects' in the original sense of entities having behavior
responsibilities. So how does OMG reconcile these two views? With the
idea that all behaviors are objects! So the paragraph you quote is
talking about a "behavior object", not an OO object with behaviors. This
is the sort of nonsense that happens when you try to reconcile
incompatible subject matters in a single notation.
FWIW, this is the furthest I have seen OMG go down the garden path. To
me the notion that behaviors are objects is beyond the pale of ludicrous
in an OOA/D context. It is clear OMG is also trying to support
functional programming in UML where functions are first class objects.
But that ignores the fact that the OO and FP paradigms are fundamentally
incompatible and antithetical. IOW, there is no way to reconcile them
under the same notation semantics.
> generalization
> A taxonomic relationship between a more general classifier and a more
> specific classifier. Each instance of the
> specific classifier is also an indirect instance of the general
> classifier. Thus, the specific classifier indirectly has
> features of the more general classifier. See: inheritance.
This is an example of OMG being forced to dumb down the semantics of
notation elements to support disparate subject matters. To provide the
necessary generality to accommodate all subject matters, they must
generalize the semantics to the point that there is almost no
information content. So to interpret the model correctly you have to go
get an OOA/D book that explains that what this is really about is sets,
subsets, and Venn Diagrams. Grrrr.
>
> inheritance
> The mechanism by which more specific elements incorporate structure
> and behavior of more general elements.
And this is just plain wrong in an OOA/D context because one can inherit
knowledge as well as behavior.
All of these things are typical of what I have seen many times since
v2.0.0. People seem to be going into the UML specification and "fixing"
it so it supports some new modeling context OMG would like to support.
But as they do that they either directly break the original OOA/D
semantics or they dumb down the semantics into obscurity so that we have
threads like this one on forums.
>
> ----------------
> SO I think that any specialized class will also, automatically,
> active... but it can change the inherited behaviors.
While I agree that's true, I don't think OMG is going to get any awards
for clarity. B-)
Dan George
in a run-time context. They also match state model to object and state
machine to instance. With that context set they can say each instance
has a state machine and that means each instance is independently in
one of the states defined in the state model.
Right, I didn't intend to imply that the behavior has a state machine.
I have, until your comment, assumed that a state model is essential to
any active object.
I think you really nailed this stuff in your book. Thinking about ADTs
vs objects with only knowledge responsibilities vs objects with
knowledge and behavior responsibilities is more useful than the active
and passive distinction.
Dan