Woshiadai Dev Notebook

From UML Bible by Tom Pender 

“The UML authors of both 1.4 and 2.0 endeavored to uphold the four-layer meta-model (M0–M3) architecture, an approach that supports the distribution of concepts across many levels of abstraction. The layering supports the specification of concepts for different purposes such as object modeling (UML) and data modeling (CWM), customization for different domains, and ultimately for different implementations.

In the UML 1.4 architecture:

• The MOF provides the foundation for the UML
• The UML defines a Foundation package as well as the Behavioral and Model Management features. Together these packages define all of the essential features needed to create the modeling elements used to build UML diagrams.

In the UML 2.0 architecture:

• The new architecture defines an Infrastructure and a Superstructure
• The Infrustructure redefines the highest level of the architecture used to create the MOF and all other MDA components.
• The Superstructure is the UML portion of the architecture. The Superstructure derives all of its components from both the Infrastructure and the MOF.
• The Superstructure is organized according to the three types of diagrams defined by UML, that is structural (Class, Object, and so on), behavioral (Sequence, Timing, State Machine, and the like), and supplemental (information flows, profiles, and templates).

Diagram changes from 1.4 to 2.0:

• 2.0 replaced the Collaboration diagram with a more limited Communication diagram.
• 2.0 added two new interaction diagrams: the Interaction Overview diagram and the Timing diagram.
• 2.0 added the Protocol State Machine.
• 2.0 added the Composite Structure diagram
• 2.0 isolated the Activity diagram with its own semantics separate from the State Machine.”

I just read some recent articles and literatures about the idea of “building software at a higher level (than raw source code)” such as MDA, software workbench, software factories, etc. It seems like people are starting or have started (e.g. tools like OptimalJ from Compuware) using models as an efficient way of building software and leave the complexity issues to automation (as much as possible). Also, it appears to me that domain specific languages might appear as the major programming languages for specific domains. Actually, lots of XML documents have been serving as configuration files, preferences and options for quite some time, those in some sense are DSLs too.

Here are some interesting projects and articles from Eclipse and VS.NET 2005:

1) EMF+GEF+GMF: those are the modeling frameworks in Eclipse. EMF is quite similar in spirit to MDA proposed by OMG, GEF provides the framework to write graphical editors for editing EMF models. GMF (http://www.eclipse.org/gmf/) is a newly proposed project that aims to add automatic generation of GEF editors for EMF models, which bridges the gap between EMF and GEF.

2) Other MDA-related projects at Eclipse: GMT (http://www.eclipse.org/gmt/) is a set of research tools for generative model transformation. This one seems quite interesting because we are thinking about model transformation as well for our wizard-based design tools.MDDi (http://www.eclipse.org/proposals/eclipse-mddi/index.html) seems quite intersting as well, but it is also in its infancy.

3) MS has been pushing about software modeling in VS.NET 2005 and there are ideas and tools about “software factotires” (http://lab.msdn.microsoft.com/teamsystem/workshop/sf/default.aspx). They have a series of articles about software factories by Jack Greenfield. He also wrote a book (http://www.wiley.com/WileyCDA/WileyTitle/productCd-0471202843.html).

Problem: How to represent inner classes in the class diagram in UML?

I am doing TA for Software Methodology class this quarter and we use lots of UML diagrams. When grading students’ homework, I found this problem about representing inner classes in the class diagram.

After consulting the UML 1.5 spec and other resources, there are two ways.

Solution 1: (from Holub Associates: UML Reference Card)

 Nesting, Inner Class.. Identifies nesting (containment) relationships in all diagrams. In a class diagram: an “inner” class whose definition is nested within the another class definition. Typically puts the inner class in the name space of the outer class.

Solution 2: Use a package symbol (from UML 1.5 spec, chapter 3 UML Notations (PDF), 3.48.2)

“Note that nested notation is not the correct way to show a class declared within another class. Such a declared class is not a structural part of the enclosing class but merely has scope within the namespace of the enclosing class, which acts like a package toward the inner class. Such a namescope containment may be shown by placing a package symbol in the upper right corner of the class symbol. A tool can allow a user to click on the package symbol to open the set of elements declared within it. The “anchor notation” (a cross in a circle on the end of a line) may also be used on a line between two class boxes to show that the class with the anchor icon declares the class on the other end of the line.”