EmPowerTec UML and modeling blog

Hello!

Recently, someone posted this question concerning the UML metamodel (as Rational Rose model) from the OMG website to the precise UML (puml) mailing list:

"But when I browse the diagrams, I find some strange things such as many duplication of the same concept in the same diagram. …in any case, if you examine the classifiers hierarchy, you can find many instances of the same classes (Classifier, Class, Interface,…)"

And Earl Waldin – who is involved in the work on the UML specification within the OMG - responded:

 "…The specification heavily uses the concept of a merge increment. You can try reading the definition of PackageMerge in section 7.3.40 of the UML2 specification. However, it's not easy going. I don't know of any good description of this and a quick Google doesn't turn up any…"

So I thought I give it a try

(Btw.  the document Earl referred to is the UML 2.0 superstructure specification).

To start, let me cite the introductory paragraph of chapter 7.3.40 of this document:

"A package merge is a directed relationship between two packages that indicates that the contents of the two packages are to be combined. It is very similar to Generalization in the sense that the source element conceptually adds the characteristics of the target element to its own characteristics resulting in an element that combines the characteristics of both. This mechanism should be used when elements defined in different packages have the same name and are intended to represent the same concept. Most often it is used to provide different definitions of a given concept for different purposes, starting from a common base definition. A given base concept is extended in increments, with each increment defined in a separate merged package. By selecting which increments to merge, it is possible to obtain a custom definition of a concept for a specific end. Package merge is particularly useful in meta-modeling and is extensively used in the definition of the UML metamodel."

The basic nature of a package merge is to define a single concept not only in one place as a single entity but to split the concept definition over several packages. Reasons could be:

• The concept is complex and you don't want to handle all the complexity whenever you use the concept. In this case you could merge only those parts that are of concern to you into a target package and the use the concept from this target package. For example, in an editor with 'code completion' this could reduce the number of suggestions.
• You want to partition your system along some logical boundaries/responsibilities and create packages in your model to reflect this partitioning. Then you can divide a concept along these logical boundaries and define the specific parts of the concept in the related package. E.g. if you could decide to create packages for domain specific parts of your classes and for technical aspects like security or persistency. Then you could define the domain specific part of a given class in package A, the security in package B and the persistency in package C. In discussion with your stakeholders you could now use only package A to discuss the business requirements whereas you could create a merge package that combines packages A, B and C for a code generator.

 

The UML specifications lists in detail the (conceptual) transformations that take place during the merge and the constraints that must be satisfied to allow the merge. 

Now is the package merge a useful concept?

Personally, I doubt it. It probably has helped the people that have defined the UML metamodel but introduced a new concept that does not fit very well to the other concepts in UML and that has only limited support in most UML tools.

The main problem is, that it is a hybrid between a structural feature and a transformation that takes place at a given point in time and that transforms the model from one state to another. Conceptually, the merge takes place when the merge relation is established and whenever one of the merged packages is modified.

In addition, if you are a tool vendor the idea of properly supporting  the package merge feature might give you a headache.

Best regards,
Andreas

Technorati Tags: modeling, UML, package merge

 

Hello!

Recently, an announcement for a workshop on UML and AADL was made on the precise UML mailing list. The workshop seems to emphasize the usage of AADL.

AADL is a new modeling standard for embedded systems. If you want a quick introduction to AADL I recommend this presentation. The AADL seems to implement the "model based" approach to a high degree and it seems to have a better defined and integrated textual specification than UML (but it also supports graphical representations). A UML profile exists so that current users of UML can make their first steps with AADL in the tools they are used to.

Best regards,
Andreas

says Chris Rupp, a well known german requirements specialist.

The german information technology newspaper Computerzeitung cited Mrs. Rupp with interesting opinions (german) on trends in requirements engineering.

Chris thinks, that requirements specifications have become more accurate and complete in the past years. Reasons are

• Outsourcing becomes more and more popular. This requires better description of the requirements since with growing distance (geographically and more important mentally) the contractor usually knows much less about the problem domain than the principal. And communication is harder and more expensive.
• The principal usually demands formal qualification from the contractor, like CMMI and these qualifications imply formal requirements definitions.

Chris further says, it is hard to create good requirements specifications because there is a gap between domain experts and software development experts. Requirements engineering works best if a person that has relatively little domain knowledge speaks to a domain specialist and translates 'domain speak' into clear, efficient requirements. She has observed it is important that the domain specialist likes (on a personal level) to speak with the requirements engineer, otherwise the results will be poor.

Chris and her colleague Stefan Queins make these recommendations to improve your requirements engineering:

• Strive for a good requirements specification but expect that there will be gaps in your specification and that you will have to (repeatedly) spend additional effort for communicating your requirements.
• Make your contracts reflect this approach.
• Have at least one person available that is capable to make the translation between domain experts and the software developments team.

I'd like to add this suggestion:
If you want to improve your requirements specification process and your are using the UML to model a software system or software components you should consider using the Object Constraint Language to improve the precision and quality of your model and to capture requirements directly on the model level. These requirements will be automatically checked for consistency with the model, if you use the right software.

Best regards,
Andreas