Action vs Activity (and relationships)

[Modesto Vega]

Unless you consider the decision to base a UML design tool on the UML specification (back before UML 2 existed) to fit into that category.

But Sparx EA is not just a UML design tool, it does much more than UML and this is the reason we buy it.

Furthermore, Sparx EA is not fully compliant with the latest UML specification. Many legacy UML features no longer supported by the current specification, starting with Object, are still present in Sparx EA (and I do understand the difficulties involved in migrating them to new features). Many new UML features are implemented inconsistently.

Yes. "Abstract" means it "can only be instantiated by instantiating one of its specializations".¹ EA implementing that behavior is not some arbitrary design decision on our part. Unless you consider the decision to base a UML design tool on the UML specification (back before UML 2 existed) to fit into that category.

Furthermore, you also seem to be implying that if something is a Class in the specification a concrete type is required.

Regardless of the implementation, you need to be able to create the concrete types. You don't need to be able to create the abstract types.

Yet the way abstract classes are implemented is inconsistent. Action is according to the specification an Abstract Class (pleae see section 16.14.3, p. 490) but has been implemented as a concrete type. Not that I would like to see all its specialisations  as concrete types

I'm not  sure what you mean by promoted or demoted. Concrete classes can have specializations. In fact Class itself fits into that category.

Hypotethically, let's assume that a future version of the UML specification makes ActivityNode a class, instead of an abstract class. What would be the impact on future versions of Sparx EA?

Behavior is an abstract specialization of class.

This is a known weakness of UML. Something that ArchiMate3 addresses.

The intention of UML is that you can create Class, Activity and StateMachine, but you can only create a Behavior by creating one of its concrete children.

Aren't you oversimplifying? Is this really the way Sparx EA is designed?

¹ Unified Modeling Language, v2.5.1 9.9.4.5

Section 9 is about classification. Classification does not describe the structure of UML, it only classifies the structure of UML.

[Paolo F Cantoni]

Hi Modesto,
I know you're not channelling me (principally because I'm still alive  ) from years back.  But others might not be convinced.
An interesting discussion and tussle between you and Eve.

Anyway, welcome to the real world...  Standards are inconsistent (and often overlapping)^[1], Sparx EA is inconsistent.

A few years ago, I took the view that I should treat EA as a framework within which to define an organisation-specific modelling environment.   Since then we haven't looked back!  We define metatypes as required, we define interrelationships as required, we define viewpoints and views as required etc. etc.  We have concentrated on trying to understand/develop a "Theory of Modelling" to allow us to make as accurate representations of the real world as to allow us to implement J.R. Abrial's dictum (paraphrased) "The sole purpose of an information system is to allow the user to ask the same question of reality and the system - and get the same answer!"

We take cognisance of the various modelling standards and methodologies but aren't constrained by them.  We believe we have developed an integrated, consistent, modelling environment.  You may have noticed that most of my reported errors, defects and questions relate to EA as a framework.

I think you're currently "on a hiding to nothing".

Paolo

^[1] Sometimes they are just plain wrong n places.

[Eve]

Yes. The only specification I've referred to for this discussion is UML. That's because the topic of the conversation was UML and there was a claim that EA should have an ActivityNode element as a concrete element with subtypes would be more UML compliant. Now I'm seeing the assertion that EA is not compliant because Action (a specialization of ActivityNode) is implemented in the way you think EA should implement the parent.

The description of Classifier in section 9 of the UML specification does describe the intended behavior of all classes in the rest of the specification. The whole specification is described using UML itself. ActivityNode and Action are both described as an Abstract Class, which absolutely does mean that the specification only intends them to be instantiated by creating a specialization.

I won't dispute that in some places the way EA stores information does not directly match the UML specification. (or any other specification you want to use to model) The actual implementation details don't constitute conformance though. What's relevant to conformance is that you can create appropriate models, and if there is a defined exchange format, correct import and export to that format.

[Modesto Vega]

I know you're not channelling me (principally because I'm still alive  ) from years back.

Thankfully, we can think alike without the need for channelling  .

I took the view that I should treat EA as a framework within which to define an organisation-specific modelling environment.

This is pretty much the approach that I have also been using for a number of years.

Now I'm seeing the assertion that EA is not compliant because Action (a specialization of ActivityNode) is implemented in the way you think EA should implement the parent.

Just for the record, I am not suggesting that this indicates non-compliance. I am merely saying that the UML specification is not consistently implemented, this is one example.

The description of Classifier in section 9 of the UML specification does describe the intended behavior of all classes in the rest of the specification.

Whereabout in section 9 are classifiers being described as "describing" the behaviour of all classes. Besides describing the structure and the behaviour are 2 very different things. Sections 10 to 20 of the specification describe the structure of UML, to understand the structure I do not need to understand the behaviour, I do not need to know is something is a RedefinableElement or not.

Sparx EA can be seen as a UML modelling tool or as a tool that can used to create frameworks (and languages) to describe architectures. Sparx Systems actively promotes this by shipping multiple frameworks and languages with the software, starting with Sparx very own interpretation of UML. IMO, this is why people buy Sparx EA.