Community
Participate
Working Groups
Improve UML2 documentation by updating the FAQ, enhancing the Javadoc, and publishing new articles.
In particular, the Javadoc for Element#getValue(Stereotype, String) and Element#setValue(Stereotype, String, Object) needs to be enhanced to describe the use of "property expressions" to (recursively) get/set the values of attributes on (nested) complex types.
The FAQ and Javadoc (now available online for each UML2 release) were updated in UML2 1.1. Documentation will be further improved (e.g. existing articles will be updated and new articles will be added) during the 2.0 release cycle.
The fix has been committed to CVS.
Created attachment 42660 [details] migration doc Migration document
Created attachment 43099 [details] Migration doc update Updated .html to work with Firefox
Created attachment 43100 [details] Zipped up images zipped up version of migration doc so that binary images work.
Created attachment 44308 [details] migration doc update format
Created attachment 44312 [details] zipped up version of patch
Continued improvements to documentation will be made in a future release.
Created attachment 46371 [details] added programatic migration
Planned items. -Article on extending UML. (90% complete) -Article on creating heavy-weight extensions. (60% complete) -Update to migration document ( document profile application in migration ).
Created attachment 55336 [details] Extending UML doc ( almost complete ;) )
Created attachment 55337 [details] Heavyweight extension documentation started.
Created attachment 57812 [details] describes the UML2.profile.uml profile.
Created attachment 57911 [details] mapping ecore generics to uml ( draft )
The UML2.1 superstructure spec (ptc/06-04-02) in 18.3.6 (Profile) shows an example of XMI for exchanging profiles (pages 694 to 696) that includes an XMI definition of the profile in XML schema. For the lightweight profile customization strategy, what are the pros/cons of producing such XMI schema definitions? Specifically, can we use the XMI schema definition of a UML profile to simplify matters of UML interoperability along the lines of https://bugs.eclipse.org/bugs/show_bug.cgi?id=80306 ?
The Javadoc for the package org.eclipse.uml2.common is in dire need for more documentation, especially when it comes to the purposes of the different EList implementations provided there. This is critical, as they -- AFAIK -- still have to be used manually to implement derived associations in one's model.
Created attachment 60230 [details] Tutorial to create Domain metamodel using the heavyextension This is a tutorial of the domain metamodel creation. It uses a simplified BPMN model as example. In fact, it is a Proof of Concept to implement BPDM metamodel.
Created attachment 61171 [details] How to use composite structures
James, the composite structure document is a good start; I would suggest clarifying your assumptions w.r.t. the notion of 'connector' you use. Many ADLs distinguish make a distinction between modeling architecture element types and modeling instances of such types. For example, CMU's AcmeStudio calls the former an architecture "family" and the later an architecture "system". With the UML, we have a reasonable type/instance distinction for components and ports but things become muddled very quickly for connectors. In the UML superstructure spec, a connector links instances of components in a specific context such as a collaboration. However, the decision to enforce a typing on what constitutes legal connections is left up to the user in the UML whereas in other ADLs, the user can express this typing constraint in the form of, e.g., a connector type in AcmeStudio. In your document, there is some glimpse of this in several parts: - in the detailed class diagram, you indicate with a note that the customer use/provided ports have no association between them to avoid unnecessary coupling. What if I want to say that the customer use port must be a structural feature of a component instance fulfilling the role of an administrator type and that the customer provided port must be a structural feature of a component instance fulfilling the role of a customer type? There are many ways to model this in the UML; one example is enough. The point here is that the instance-level topology of use/provided port connections should be type checkable. - in the communication diagram (detail), you show a link between instances of customer use/provided ports. I would suggest defining the interaction as a collaboration type so that it can be instantiated and so that instance-level port connections can be type checked. You seem to be headed in that direction. Do you think it would be reasonable for the purposes of this example to postulate that a well-formed connection must be an instance of a properly defined collaboration type? If you agree, then it would be nice if we eventually could specify in OCL what it means for an instance-level component/port wiring diagram to be well-typed w.r.t. a set of types (components, ports, collaborations, etc..). - in the structure diagram, a note seems to indicate that the IUknown interface is used to obtain the interface with the other end (of a connection). This is a Microsoft COM-biased view for what amounts to querying the component/port level topology of an architecture at runtime. I believe it would be preferable to stick to the the UML-biased view of component architecture reified as collaboration patterns. In this view, the components, ports and links between them participating in a collaboration would be introspectable -- i.e., port instances, component instances, and perhaps link instances should have an "identity" to lookup the context of each instance in the collaboration and resolve queries like "what is the port on the other side of link I'm attached to?". Cheers, -- Nicolas.
Nicholas, Thanks for the feedback. I'll definitely take your comments into account before finishing this article (it's quite rough now). The idea behind this article comes from questions in the newsgroup about composite structures and the vague notion of "connector" and what exactly it means for two ports to be connected. Frankly, I have not seen any examples explaining this in great detail. I also wanted to clarify that assembly connectors should not be shown on component diagrams. Context is required amongst other things. I find it very intersting that the spec speaks of parts in terms of instances and does not mention parts in terms of the static nature of a system. Parts are afterall properties and properties can be considered to be part of the static nature of encapsulated classifiers in a similar way that attributes are part of the static definition of a class. The "instance" notion seems to be an implied runtime concept. Presumably your component will be part of a running system so the spec seems to skip to the instance terminology. I could say that at runtime, any general instance of this class will have these parts and these parts will be connected in this manner. I could speak about attributes of a class in a similar fashion but the spec doesn't. I can see the need to describe parts as instances when connectors come into play. Connectors really say that "somehow" these two parts are connected at runtime... but that connection is vague. The connection itself might only exist at runtime. It could be implented as a lookup table etc. There also seems to be some overlapping terminology. For example, "Link" is an InstanceSpecification of type Attribute whereas we talk about Connectors as "links". Connectors seem to be a bit more vague than true Links. (Connectors may or may not be typed by Associations). Composite structures really talk about any general instance whereas object diagrams talk about specific instances. The reason for choosing the MFC type example is to explain all the gory details of hooking up process using ports. I will consider other examples. Also, I intend to finish the article by including every type of diagram in UML, including Object diagram. Thanks again ... any other input is appreciated. - James.
Javadoc has been added for parameters of custom and valdation operations.
Created attachment 72730 [details] Migration from UML2 2.0 to UML2 2.1
Created attachment 73587 [details] Migration from 2.0 to 2.1
Created attachment 74838 [details] generics in UML (draft)
Created attachment 78642 [details] Generics with UML Templates
