I am asking if it is necessary or useful to have semantic variances in UML. Would it not be more useful when it was more formal and therefore verifiable or even used for rapid prototyping. What is the benefit of the variance? Can you give some examples?
I would prefer to get rid of the semantic variation points of the UML. A typical example that causes confusion when I model diagrams is the multiple classification semantic variation point. When modeling generalizations in a class diagram, you can choose to assume that the diagram admits multiple classification (an object can be instance of two or more classes not related by a subtype relationship) or not.
Usually designers with a background programming implicitly assume that this is not possible while at the conceptual level many of us tend to implicitly assume that this is possible. You can imagine the result.
Related
Suppose I draw an UML class diagram representing the class and interface structure of my project. Are there any methods to assess the UML design before actually creating those classes and interfaces?
Example: It is known that the diagram below will lead to diamond problem. And must be changed or handled.
UML is a powerful design language. It is programming language independent (although it has a bias towards class based languages) and thus allows to design things that are not implementable in some languages but trivial in some other languages.
The real question is what you expect from assessment:
syntactic and semantic validity of the model with regard to its compliance with the UML specifications? In your diagram, you use void type, which does not belong to the primitive types of UML. It's a language dependent type.
completeness and accuracy of the model, with an eye on potential ambiguities and missing informations? In your diagram, Animal.eats() may for example be {abstract}. But is the absence of this information an indication that it's not abstract ?
evaluation of the class design, such as for example its complexity, the deepness of the inheritance, the intensity of relations, mutual dependencies, etc... ? But how can this help to spot a bad design, when some domains are just inheriently complex ?
feasibility? UML allows for multiple inheritance, but does not precisely define the semantics behind it. For instance, in C++ you can very well cope with this design with the virtual inheritance of Animal. In Java, multiple inheritance is forbidden and this would not be implementable as such (you would need to alter this model to introduce an interface and use interface realization). Now here, we will not reopen the debate about MI.
A systematic review of of diagrams is done here everyday. The goal of such assessment is to see if the notation is consistent with the UML specification, and eventually with the constraints of the chosen UML profile. There are some research papers that explore the automation of such consistency assessments.
Design is currently not highly automated; There is therefore no systematic method to assess the design as far as I know.
There are some general metrics (e.g. CK metrics) and some of these can be calculated for UML class diagrams (e.g. only 3 out of 6 CK metrics for example). Metrics are not assessments, but they can help an analyst in this task.
What practice is considered the best one when i have to translate an aggregation/composition of an UML Diagram drawn in Design Phase in implementation phase?
In many cases, when aggregation or composition has been used in a UML class diagram, it just means an association and doesn't have any additional meaning. So, the simple advice is: just translate an aggregation/composition of a UML design model to an association and implement it with suitable reference properties in the implementation (model).
You may want to read my article Really Understanding Association, Aggregation, and Composition.
As Thomas noted, I dont think there are any clear generally aplicable best practices. There's just so many different situations and different contexts which strongly affect selected approach.
Aggregations and compositions are analytical constructs and should not appear in design or implementation models very often, if at all.
What can be said is, that many people struggle to understand the meaning/semantics of aggregation/composition. Usually they tend to over-identify aggregations and compositions. These are in fact rather rare relationships within SW system models. Not every 1:N relationship is an aggregation.
I need insight on how much UML to teach. I'm an adjunct for a "2-credit 100-level introductory course" on systems analysis and design (a contradiction in terms to me). The text is written for the typical 300-level 3-credit class. This chapter covers ~7 UML diagrams, it's already extremely simplistic, and I have to strip it down further. I have one week, or two class hours, to cover it.
I've concluded I can either trash the book and cover class diagrams well, which would introduce them to a lot of basic OO concepts, or I can simply aim for basic recognition of these 7 diagrams (not even expecting them to create any). But I feel like basic recognition would so totally skim the surface as to be useless for these brand-new programmers and the diagrams would run together meaninglessly. Advice greatly appreciated.
The 7, by the way, are: object relationship, use case, class, sequence, state transition, activity, and business process modeling.
There are several UML elements that map easily to code and are therefore straightforward to use as design elements.
Package diagram (translates to namespaces).
Class diagram (translates to classes in OO languages).
State machine (translates to any number of state-based implementations).
Sequence diagram (shows chronology of method invocations).
I would say that this is the minimum useful set of UML elements to teach. If you have time, I would also encourage people to learn use case diagrams, although many people find text documents just as effective for that type of analysis.
I would recommend to focus on class diagrams. They are the most useful type of UML diagram for analysing, designing and documenting (the information, or state, structure of) a software system. You could show how class diagrams define
the properties of an object type, both data-valued attributes and object-valued reference properties (representing unidirectional associations).
if a property is single-valued or multi-valued (by its multiplicity)
other property constraints
inheritance relationships in class hierarchies
You could show how classes can be used for conceptual information modeling (also called domain modeling) in the analysis phase, where they define the real-world object types, and for design modeling in the design phase, where they define platform-independent computational constructs to be implemented in some target programming language.
I'm currently working on a project for my university and one teacher told me I was wrong to think that there could be classes in a UML class diagram (thinking of it as a design diagram) to which there would be no equivalent in a data model. He then pressured me to provide a counter-example to prove my point but I just couldn't think of one.
I checked a few books I had about UML like "Learning UML 2.0," "Applying UML and Patterns" and UML 2 for dummies, but I couldn't find any information regarding which classes appear on a class diagram. I asked him about implementation classes but he told me that they shouldn't be included in a class diagram. So I'm at a loss here.
I also checked this questions before posting:
Differences between a conceptual UML class diagram and an ERD?
Generate UML from a conceptual data model
how to relate data with function in uml class diagram
But they don't really solve the question I have.
Thanks for any insight you might have.
Both your teacher and you are unnecessarily distracted by the differences between UML and conceptual data modeling (which I take to be tantamount to ER modeling). The real issue you and your teacher are discussing is the difference between analysis and design, regardless of the model used.
A UML model can be created that diagrams the problem as stated or that diagrams the solution as designed. In the first case, implementation classes should be omitted, because they do not pertain to the problem domain. In the second case, they should be included. The first case is analysis. The second case is design.
The same ambiguity exists with regard to ER diagrams. Some people, including myself, use ER models and ER diagrams only to represent the data requirements inherent in the problem itself. This is what is most often meant by "conceptual data modeling". In this framework, the only entities that should appear are entities that have a perceived reality in the subject matter itself, and are not merely constructs inside the database or the application(s). This is analysis.
But there are plenty of other people, perhaps a majority, who use ER diagrams to pictorialize the design of a schema of tables. In this framework, foreign keys are included, and junction tables are elevated to the status of entities, even though they are not subject matter entities. There's nothing inherently wrong in this, so long as the distiction between analysis and design is kept clear.
Unfortunately, the distinction between analysis and design is very often obscured beyond recognition. There are dozens of instances of this right here in SO.
So, if a confusion between analysis and design is allowed to creep into the discussion between you and your teacher, the discussion could end up going in almost any direction.
"one teacher told me I was wrong to think that there could be classes in a UML class diagram (thinking of it as a design diagram) to which there would be no equivalent in a data model. He then pressured me to provide a counter-example to prove my point but I just couldn't think of one."
He is right. In the stage of conceptual analysis/conceptual design, those rectangular boxes in a UML class diagram depict "concepts". And whatever the "concept" happens to be, you can always also draw an E/R diagram around it to illustrate (the nature of) that concept, other concepts that relate to it, and what the nature of those relationships is.
From my understanding of UML, it does NOT define what should be in a diagram. I found this example in the IBM site: (image did'nt lode, so here is the link: http://www.ibm.com/developerworks/webservices/library/ws-RESTservices/)
Surely, a servlet is not part of a domain model.
A UML class diagram us used to model classes, which are entities that have attributes and methods. IMHO, it doesn't matter if they are part of the domain model or are functional classes that support the application. If you need to show them to the customer, they must be there.
Is an activity diagram is considered algorithmic?
Strange question indeed. Taking a look at dictionary definitions:
Algorithmic: of or relating to or having the characteristics of an algorithm
Algorithm(1): a precise rule (or set of rules) specifying how to solve some problem
Algorithm(2): an effective method for solving a problem expressed as a finite sequence of steps.
So: can Activity Diagrams be used to describe "a method for solving problems expressed as a finite sequence of steps"? Yes - that's their purpose. They support all the usual control structures required to describe algorithms: sequence (A followed by B), alternation (either A or B), iteration. They also provide explicit support for parallel activity.
Areas where they may be considered weak:
The execution semantics are not precisely and unambiguously defined. Whilst the UML spec does provide some semantics, it leaves some points open.
There's no pre-defined set of primitive types defined for Activity Diagrams. Thus, the lowest level primitive activities (adding integers, concatenating strings, etc.) aren't pre-defined. In that sense Activity Diagrams on their own aren't computationally complete.
However: those are nitpicking theoretics. In practice, Activity Diagrams are a popular means to represent algorithms: from the design of software procedures to specifying business processes.
Of course, it all comes down to your definition of algorithmic. If you go with the general definitions above then ADs are algorithmic. If you go with something more specific they might not be.
hth.
OMG Meta-Models (i.e. UML, SysML, etc.), starting from the Meta-Meta-Modeling language by means of which they are described (MOF), consists of two different classes of models respectively aimed at definining:
The static structure of a system, or architecture (i.e. Class Diagram, Component Diagram, Block Diagram, etc.);
The dynamic of the system, or behaviours (i.e. sequence diagram, activity diagrams, state machine diagrams, object interaction diagrams, etc.)
Activity diagrams belong to the second class so they are aimed at describing behaviours.
an algorithmic is only of type of behaviour that can be described by means of an activity diagram
Activity diagrams complemented with the new UML executable standards can be used to represent any algorithm. Activity diagrams alone can be used to represent the overall control flow but not really the details of data management