I'm currently writing a blog entry that is also about model-2-model transformations. I would like to explain shortly what a model-2-model transformation is in this post. Therefore I would like to come up with a simple example of two models, where the first is transformed to an instance of the second. Both models should be well known to developers, so that I don't need to explain them.
However I couldn't come up with some example models. ATL uses a family and person model in one of their tutorials, but they also require extra explanation as I think.
So do you know an example that I can make use of?
If you want to explain m2m to developers, you can use an M2M-trafo from petri nets to uml activity diagrams. Because activity diagrams are based on petri nets it should not be to complex. I think both models should be known by a developer. Sure, they are not easy, but a developer should know them.
http://en.wikipedia.org/wiki/Petri_net
http://en.wikipedia.org/wiki/Activity_diagram
Sure you should keep as simple as possible. This means you should only describe the transformation for a subset of modeling possibilities. For petri nets I only would use simple states and transitions as subset of the metamodel. For activity diagrams I only would use actions and transitions.
There should already be existing examples of this transformation, so you can also use existing knowledge.
Another thing I want to point out is, that someone how learns M2M-trafo understands what M2M-trafos are used for. Because this case described above can be used in practice.
I chose object relational mapping (ORM) as an example in my blog post. ORM can be viewed as a bidirectional transformation from a relational database model to an object oriented in memory model.
Most (every) developer should know about ORM. But the problem might be that this could cause devs to think about m2m in terms of Hibernate, JPA, etc, which is not the case.
As an example you may consider translation from one language to another. There is an example of translation from UML to OWL.
Related
I wish to document code for a fairly complex algorithm whose implementation is intertwined across several methods and classes. A sequence diagram cannot really describe the detail of each method well so I am looking at an activity diagram; however this doesn't typically seem to represent classes and methods, only the logic.
Is there a common or even proper way to show which methods the logic belongs to? I do not need to follow strict UML, the purpose is simply to make it clear what's happening visually.
Activity diagrams and partitions
The activity diagram are supposed to models activities without necessarily relating them to classes/objects. They are however very suitable for modeling complex algorithms, as they allows to show :
the control flow -- flowchart diagrams have proven effective for modeling alorthims; activity diagrams are much more precise in their semantic and can do this as well.
object flows that show what objects are passed through
there are object actions that are specifically meant for dealing with objects
Activity diagrams support partitions, i.e. visual grouping of activities according to a criteria. A popular use is to split actions by using subsystems as grouping criteria. Breaking down by classes seems overkill, but nothing forbids such groupings if it helps, and if you're able to use it consistently.
Interaction overview diagrams
Interaction Overview Diagrams are specialization of Activity Diagrams that represent Interactions.
Interaction overview diagrams are a kind of combination of activity and sequence diagrams. The general idea is to use some activity modeling features for showing the big picture of the flows, between interaction nodes, i.e. mini sequence diagrams embedded in the larger diagram, to show which objects are involved and what messages they exchange.
There is an inspiring example here. But be careful: the linked website is based on a former version of UML and the text is not fully up-to-date. The most accurate source on these diagrams is section 17.10 of the UML 2.5.1 specs.
Additional thoughts
Instead of trying to show everything in one diagram, you may prefer the beauty of simplicity: use an easy to understand, simpler overview diagram, and uncover the complexity in additional diagrams that focus on details. This works with activity diagram complements with more detailed activities or sequence diagrams. But it also works the other way round, showing exchanges between key objects in a sequence diagram, and provide more detailed activity diagrams to describe what happens inside of one of the invoked operation.
Disclaimer: While I provide some hints that you can use to model algorithms in relation with their classes, I have at the same time to warn you that visual programming, i.e. a very very very detailed modeling, may lead to very complex diagrams that are difficult to read, and even more difficult to maintain. They loose the benefit of communicating the big picture. I'm not alone in this criticism, see Grady Booch who knows what he is talking about, since he is one of the co-inventor of UML, Martin Fowler, and many others
I roughly know how to make a mvc uml class diagram en can find enough info/ examples on the internet. The only thing i cant find info about is if it makes a difference when you have a jacascript controller/model and a c# controller/model.
In general: no.
UML is technology independent. Most models don't assume the technology. MVC can also be applied to different programming languages.
You only need to be aware that there are some concepts that are not handled by particular languages. The only thing that comes to my mind here is multiinheritance. Just use interfaces instead of (eventual) multiinheritance and there'll be no problem.
I can also imagine that some details can be designed in different ways to achieve better performance, but you'd need to know both languages perfectly to be able to make such decisions.
So don't bother about specific language and your diagram will be fine.
I have an interface (android activity, but that should not matter) with text input, spinners and a toggle button (all on one page). Depending on the state of all these elements I produce text output (on the same page).
Since the relationship is not trivial, I would like to somehow visualize the logic relationship between these elements. I am reading about UML, activity diagrams, etc but got a bit lost there.
What term should I look for? What program do you recommend to use for drawing such diagrams on computer (linux)?
UML Activity Diagrams might not be what you are looking for. They are usually used to model activities in a process. They tend to be more high-level and conceptual and less about the implementation.
From your question it reads as if you are working on the implementation itself. In that case I would urge you to look at UML State Diagrams. They are really neat when you want to think about different states your application (or components of your application) can be in. It also lets you logically decompose behaviour into states.
Furthermore, it is also a straight-forward way to model your application in a way that you can apply a Design Pattern, notably the State Pattern, to implement your model.
Would an activity diagram be the best way to express validation rules for an HTML form, using a whole bunch of decision nodes? I am not convinced that it is, but I can't find a more appropriate one, nor can I find any examples of validation rules models online.
None - no one in their right mind would create a graphical representation of form validation rules. UML is not the same thing as engineering drawings, in spite of the best efforts of its proponents.
You're doing it wrong if the effort required to create the UML diagrams for a system approaches that of actually developing the code. Better to have running code that you can actually unit test. The unit tests are better documentation than UML will ever be.
Don't try to represent everything in UML.
An UML diagram is good idea. Activity diagram can be created with graphical rules (e.g. pink annotation).
It is a good start even before codding.
For any non-trivial rule you´ll need to use a language like OCL to be able to express the rule.
Validation is fired in case of a misuse case so it Can be represented using activity diagrams. Sequence and activity diagrams also help you debug production issues and nail them quickly
I was reading Code Complete (2nd Edition), and came across a quote in the margin on page 87 by Bertrand Meyer.
Ask not first what the system does; ask WHAT it does it to!
What exactly is the point Mr. Meyer is trying to get across here. I have some rough ideas, but I would like to make sure I really understand.
... So this is the second fallacy of teleology
- to attribute goal-directed
behavior to things that are not
goal-directed, perhaps without even
thinking of the things as alive and
spirit-inhabited, but only thinking, X
happens in order to Y. "In order to"
is mentalistic language, even though
it doesn't seem to name a blatantly
mental property like "fearful" or
"thinks it can fly". — Eliezer Yudkowsky, artificial intelligence theorist
concerned with self-improving AIs with stable goal systems
Bertrand Meyer's homily suggests that sound reasoning about systems is grounded in knowing what concrete entities are altered by the system; the purpose of the alterations is an emergent property.
I believe the point here is not on what the system does, but on the data it operates on and what those operations are.
This provides two major thinking shifts:
You think of the data and concepts first
You think of operations on that data
With those two "baselines" you will better prepared to organize a system to achieve your goals so that operations on data are well understood and make sense.
In effect, he is laying the ground work to be able to write the "contracts" on the code you write.
From Google search it picked up Art Gittleman's Computing With C# and the .Net Framework:
Bertrand Meyer gives an example of
payroll program, which produces
paychecks from timecards. Management
may later want to extend this program
to produce statistics or tax
information. The payroll function
itself may need to be changed to
produce weekly checks instead of
biweekly checks, for example. The
procedures used to implement the
original payroll program would need to
be changed to make any of these
modifications. Meyer notes that any of
these payroll programs will manipulate
the same sort of data, employee
records, company regulations, and so
forth.
Focusing on the more stable
aspect of such systems, Mayer states a
principle: "Ask not first what the
system does: Ask WHAT it does to!";
and a definition: "Object-oriented
design is the method which leads to
software architectures based on
objects every system or subsystem
manipulates (rather than "the"
function it meant to ensure)."
We today take UML's class diagram and other OOAD approach for granted, but it was something that was "discovered" along the way.
Also see Object-Oriented Design.
My opinion is that the quote is meant as a method to find good abstractions in your software. The text next to this quote deals with finding real-world objects to design your classes.
An simple example would be something like this:
You are making software for a bank. Because your software is working with bank accounts, it should have a class for an account. Then you start thinking what properties accounts have and the interactions you can have with accounts.
Of course, this quote makes more sense if the objects you are trying to model aren't as clear as this case.
Fred Brooks stated it this way:
"Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowcharts; they'll be obvious."
Domain-Driven design... Understand the problem the software is designed to solve. What "domain" entities, (data abstractions) does the system manipulate ? And what does it do to those domain entities?