About simplifying the uML
Aurelia
I have herad that there is an initiative to try to simplify the UML
and/or its metamodel, but I am not able to find any reference.
Could you help me to get informationa bout it?
Thanks to everybody
Timothy Marc
There is a RFP for a simplification of the UML specification document at the
OMG
http://www.omg.org/techprocess/meetings/schedule/UML_Specification_Simplific
ation_RFP.html (member restricted access).
This is only about making the document easier to read and understand and
also to consolidate pending ambiguities in the spec. The metamodel is not
affected, at first. Most probably, there will be a FTF afterwards to address
issues in the metamodel.
Timothy
> -----Ursprüngliche Nachricht-----
> Von: umlf...@googlegroups.com [mailto:umlf...@googlegroups.com]
> Im Auftrag von Aurelia
> Gesendet: Donnerstag, 12. Januar 2012 15:33
> An: UML Forum
> Betreff: [UML Forum] About simplifying the uML
> --
> 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
Adriano Comai
http://drdobbs.com/architecture-and-design/224701702?pgno=1
I haven't more recent news, however.
Adriano Comai
www.analisi-disegno.com
Michael Jesse Chonoles
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
H. S. Lahman
This is more to OMG than to you; I'm not trying to kill the messenger. B-)
UML 2.5, in progress, is an attempt to simplify the metamodel of UML without any change to the users of UML. The problem has been that because of over-usage of OO features (e.g., in some cases 10 levels of inheritance. package merge, etc), the metamodel has become brittle. A small change to fix one problem has often revealed or caused another problem.
LOL. Oh, how I love to say: I told you [OMG] so!
That's what you get when you try to make UML service modeling subject matters with very different and often conflicting representational semantics -- huge taxonomies that try to resolve conflicts by putting them in different limbs. It is also what you get when people who do not understand OOA/D well apply it to the meta model. Any experienced OOA/D reviewer could have told OMG that 10 levels of inheritance is a Really Bad Idea for exactly that reason and that one should always look first for a reasonable delegation solution before using generalization.
[Actually, such taxonomies could work IF UML serviced a single modeling subject matter. That's because the subject matter is not changing so a complex generalization taxonomy could last indefinitely as-is as a subject matter invariant. However, OMG is adding new modeling contexts to the Mother of Modeling Languages as we speak. That's where the static generalization structure becomes brittle -- you can't change it when the semantic analog of the Duck Billed Platypus comes along in a new subject matter.]
Those reviewers could also tell OMG that the inheritance <<subsystem>> <- Component <- Class <- Classifier makes no semantic sense in an OO modeling context unless you change the semantics of Class by dumbing it down to be a container of arbitrary things. And if you change the semantics of Class in the meta model, all you do is confuse anyone attempting to apply the meta model rigorously to OOA/D. That is, the MDA profile for OOA/D has to say, "OMG was just kidding; ignore the meta model. Subsystems are containers of multiple, semantically different classes while classes are containers of semantically identical objects -- by methodological definition. In addition, the scale (aka level of abstraction that defines logical indivisibility) in the problem space is a critical factor in distinguishing subsystems from objects. Thus a subsystem contains things that are not logically indivisible (e.g., classes or other subsystems) while a class contains things that are logically indivisible (objects) so they are apples & oranges." And that is not even getting into semantics of 'subsystem' vs. 'component'; they not the same things at all unless you employ definitions that are so devoid of information content that the distinction becomes useless for rigorous modeling.
UML v2.0 is full of this sort of stuff. OMG's rationale is that they are just defining the notation semantics, not the model semantics. But you cannot separate the notation from the model semantics. Models are constructed using rigorous methodologies. Notations exist to support those methodologies for constructing the models so they must have the same semantic rigor as the methodology or you cannot interpret the model correctly. Dumbing down the notation semantics in an LCD manner so it will support multiple methodologies just reduces the information content of the notation and makes it ambiguous for modeling. Making some cosmetic changes to the meta model is not going to fix that fundamental problem.
<Hot Button>
-- 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
Michael Jesse Chonoles
Michael
From: H. S. Lahman <h.la...@verizon.net>
To: umlf...@googlegroups.com
Sent: Monday, January 16, 2012 1:45 PM
Subject: Re: [UML Forum] About simplifying the uML
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
Timothy Marc
Hi all,
To be honest, I really appreciate the way UML is constructed, though I think there should be more information taken into account directly like requirements etc. instead of being proposed by additional profiles.
Anyway, the metamodel is quite complex, agreed, and some fundamental things are redundantly realized, but that redundancy allows you to use concepts almost isolated from each other, e.g. Interactions and Activities. In contrast, the UML kernel package is a very good set of concepts fundamental for OOA/D.
My perception is, when people argue UML is too complex and is not applicable out of the box, those people just never tried to tailor UML to their needs. As Michael said, there are almost infinite methodologies that can be realized with UML – you just have to do it.
Simplifying the specification document, however, was necessary. In particular the removal of those miserable PackageMerge concepts which just caused confusion sometimes. Additionally, aligning MOF directly with UML Superstructure and getting rid of UML Infrastructure facilitate understandability and readability, in my opinion.
Regards,
Timothy
Ken Lloyd
I think UML grew up to be a generalized object-oriented modeling language, and not specifically for Object-Oriented Analysis and Design of software (in its strictest sense). OOAD as a paradigm has strengths and weaknesses, changing in various contexts. A practitioner of OOAD focuses upon leveraging those strengths. But there are other viewpoints.
The advantage of the UML (and to a lesser extent, SysML) is that the language is extensible to adapt to the modeling challenge at hand. In other words, out of the box, it may be inadequate. I've found most modelers "skittish" about extending the language as necessary , for reasons I can't fathom. For example, I have extended BehavioredClassifiers and Actors into an Agent (i.e. artificial intelligence that works within system boundaries)
I think inheritance depth is an arbitrary measure. Additional specification of structure is normally clustered in groups, but could just as easily be broken down into individual increments.
Ken
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.1901 / Virus Database: 2109/4747 - Release Date: 01/16/12
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.1901 / Virus Database: 2109/4747 - Release Date: 01/16/12
H. S. Lahman
It's difficult to disagree. However at the same time, even within OOAD, even when trying to be rigorous, there are vast differences in terminology and methodology and programming languages. UML would never have been approved, never received the penetration it had, if only had support one approach - the flavor of the moment.
BTW, subsystem is not a UML 2 construct. Certainly, a methodology can define a stereotype <<subsystem>> and attach it anywhere, putting it in the wrong spot has consequences. In UML 1.x, subsystem was a type of package, which makes more sense.
I also have to disagree with your last sentence. In v1 packages served double duty in identifying logical semantic entities of the problem space, like subsystems, and simply organizing model elements for orthogonal reasons like version control. Separating Packages and Components was one clarification I agree with. Thus the Package takes the abstract road of organizing the model elements while Component takes the more concrete road of abstracting problem space semantics. Then a subsystem is logically a Component because it abstracts a real problem space entity. (My objection to the meta model inheritance was making Component a Class because that became broken when one looked at the real semantics of the <<subsystem>> specialization of Component.)
BTW, there is another inconsistency. In section 8.1 the discussion clearly identifies a Component as being a kind of Package. However, that mega generalization of the meta model has it being a Class, which is a sibling of Package under Classifier. In addition, there is something wrong with the picture of having a separate Component Diagram view when there are already Class and Package Diagram views, no matter which one Component inherits from. For my money Component should be a peer of both Package and Class.
Remy Fannader
Domain specific languages and profiles will split up the UML, and it's difficult to see how to simplify it without hampering its qualities.
Actually, the objective should be to get a better match between UML constructs and modeling contexts, and
that may be achieved with a clear separation between syntactic and semantics layers.
Remy Fannader
http://caminao.wordpress.com/about/caminao-charter/
http://caminao.wordpress.com/about/umlcharp-manifesto/
H. S. Lahman
I think UML grew up to be a generalized object-oriented modeling language, and not specifically for Object-Oriented Analysis and Design of software (in its strictest sense). OOAD as a paradigm has strengths and weaknesses, changing in various contexts. A practitioner of OOAD focuses upon leveraging those strengths. But there are other viewpoints.
In addition, to say that OOA/D is somehow separate from an OO modeling language just does not float for me. What is an OO model? It is an abstraction (model) of a design of an OO software solution. What is UML? It is just a notation. What was it a notation for originally? OO designs. And dating back to the early '80s OO design has always been subdivided into OOA, the customer's perspective (functional requirements), and OOD, the computing space's perspective (nonfunctional requirements). That subdivision of the notion of 'software design' was done intentionally to provide a separation of concerns when bridging the vast gulf between customer domains and computing domains that Structured Design failed to provide. (That subdivision has been graven in stone by OMG with the MDA initiative where an OOA model is an MDA Platform Independent Model and an OOD model is an MDA Platform Specific Model.)
As it happens, there is a great deal of object-based software around -- many IT infrastructures and applications created from number of procedural languages that have been objectified, like perl, LISP, and COBOL. That software quite often violates good OOA/D practice. But that's the reason it is called object-based rather than object-oriented. To me, the notions of OO design and OOA/D are inseparable and synonymous.