The relationship between programs, models and systems is really quite simple if you are allowed to define terms.
001 – A System is a set of interacting concepts in the Real World or in some imagined world.
002 – A System is assimilated by an analyst or programmer.
003 – A Model is created by an analyst from some understanding of the System.
004 – A Model is described in terms of concepts bounded by the System.
005 – A Model is a representation of a System using a notation.
006 – A notation can either be textual (text) or part graphical and part textual (diagrams).
007 – A Model described in text is a textual Model.
008 – A Model described in diagrams is a graphical Model.
009 – A textual Model is equivalent to a graphical Model under transformation and vice versa.
010 – A Program can be written by a programmer from some understanding of the System.
011 – A Program is textual (text).
012 – A Program is written in terms of concepts bounded by the System plus queues, stacks, processes, remote procedure calls, message passing protocols, file access, databases, handling user input and output, windows management and other things.
013 – A Program can be automatically generated from a Model via a software architecture which defines mapping to queues, stacks, processes, remote procedure calls, message passing protocols, file access, databases, handling user input and output, windows management and other things.
014 -Therefore, a Program is not a Model.
015 – A Program is compiled to an executable.
016 – An executable running on computer hardware is known as a computer System.
I’m a Postdoctoral Researcher at SOM Research Team, in Barcelona. Currently, I’m involved in the development of scalable tools for MDE, especially in the persistence of Very Large Models.
Good initiative. However, I don’t see VALUE IN attaching the definition OF models TO notations, but instead TO languages. A LANGUAGE can admit multiple notations, but NO matter what notation you use, the model IS still the same.
IOW, instead OF:
005 – A Model IS a representation OF a System USING a notation.
I would have:
005 – A Model IS a representation OF a System (FROM a particular perspective) according TO a specific modeling LANGUAGE.
Changing that affects many OF the following definitions (textual model, graphical model etc).
I fully agree HAVING a SET OF definitions helps a lot, the problem IS TO find definitions that ARE commonly agreed.
> 003 – A Model IS created by an analyst FROM
> SOME understanding OF the System.
I guess you ARE talking about analysis models ONLY. Analysis models focus ON understanding the problem, AND WITH that focus, given that a program IS a statement OF a solution, it IS indeed very easy TO clearly differentiate BETWEEN (analysis) models AND programs.
However, that separation IS NOT so clear WHEN one talks about (executable) design models. A design model, just LIKE a program, IS a statement OF a solution, NOT the problem. Executable models ARE design (NOT analysis) models WITH enough detail that allow FOR executability. AND there IS WHERE the line BETWEEN programs AND (executable design) models blur.
So long story short:
1) analysis model != program
2) non-executable design model != program
3) executable design model ~ program
Cheers,
Rafael
http://abstratt.com/blog
There is some confusion out there over the terms “model” and “language”.
In a post on Jordi’s blog:
https://modeling-languages.com/blog/content/list-dsl-tools (which motivated the topic), Steve Kelly says “I know the text/model/graphics distinction has been muddied up later by Microsoft calling their graphical DSM languages “DSLs”, and some pushing to call code a model too”.
You’re right about a model being a representation of a System from a particular perspective.
What I had in mind when I wrote that was something like an Air Traffic Control (ATC) System. So:
analysis model + model compiler = program
I’m NOT clear about your use OF the term “design model”. IN my world, ALL models ARE analysis models.
If we ARE talking about Executable UML (xUML), I disagree that “Executable models are design (not analysis) models”. A xUML model, such AS an ATC System model IS clearly an analysis model AND given an appropriate Model Compiler a suitable program can be generated.
If ANY piece OF knowledge (e.g. a program) IS a model, depends ON whom you will ask this. A program can be a model FOR an assembly developer. AT the same TIME, a program IS NOT a model IN the eyes OF e.g. an analyst.
In practice, people attach labels TO certain abstraction levels: object code, program, PSM, PIM, CIM. It IS NOT unreasonable TO predict that PSM will take the role OF programs AND will NOT be considered model anymore (despite word ‘model’ IN the NAME). IMO it IS MORE useful TO understand what those levels ARE, instead OF focusing ON the NAME.
“Executability” IS most often FOUND among programs, but IS NOT limited TO the programs ONLY. Executability IS rather a semantical property OF the paradigm/LANGUAGE IN which model IS described. Examples OF executable analysis models include Mendix, simulation packages, etc..
Just LIKE Rafael I don’t see value in attaching the definition of models to notations. In my opinion, language (and more specifically its concepts, paradigm) are essential for this purpose. Notation is a question of usability that is important for specific stakeholders. A point in case are so called “projections”, a recent development in language workbenches that allows “on-the-fly” toggling notations (also between textual/visual) for the same model.
I agree with the above posters that this is an important subject. Relationships among models and systems is the subject of the field of Modeling and Simulation (M&S). Anyone interested in the foundations of relationships among models and systems, I recommend the essential book on the subject: “Theory of Modeling and Simulation, Second Edition” by Bernard P. Zeigler, Herbert Praehofer, Tag Gon Kim.
> In my world, all models are analysis models
That would suggest you are a business analyst, not a developer. Is that the case?
Analysis – what – problem statement – by business analysts
Design – how – solution – by designers/developers
> A xUML model is clearly an analysis model and
> given an appropriate Model Compiler a suitable
> program can be generated.
If you replaced “analysis” with “design” I would agree 100% with you. But the way you said it, it doesn’t make sense. An analysis model does NOT define a solution, but the problem – the way you put it sounds LIKE a model compiler IS a magic tool that can automatically produce a solution based ON a statement OF the problem.
Executable UML allows you TO define a solution while ignoring implementation choices such AS distribution, allocation OF threads, memory management etc (Executable UML book SECTION 1.4). Yet, Executable UML IS ONLY concerned WITH the solution, i.e., design, NOT analysis.
IMHO, if users must specify models with such a level of detail that the generation to the code becomes a simple 1:1 transformation, then models are not that useful (from a code-generation perspective).
It´s true that tools cannot produce code from analysis models per se, but they could adopt an implicit design strategy. Therefore, analysis models + tool + embedded design strategy = automatic code generation .
> if users must specify models WITH such a LEVEL
> OF detail that the generation TO the code becomes
> a simple 1:1 transformation, THEN models ARE NOT
> that useful
I did NOT imply that, Jordi. BETWEEN design AND implementation there IS a whole lot going ON (1:10 would be MORE accurate). AND that IS a lot OF VALUE that code generation can provide.
> It´s TRUE that tools cannot produce code FROM
> analysis models per se, but they could adopt an
> implicit design strategy. Therefore, analysis
> models + tool + embedded design strategy =
> automatic code generation .
You seem TO be suggesting that it IS possible TO define a transformation that can produce running code FROM an analysis model. I sustain that there isn’t such a thing.
The input for code generation must be a design model. Just because a design model can be made free from explicit implementation-oriented concerns (by implying them by convention, for instance) does not make it an analysis model.
Analysis deals with the problem. Design deals with solution. There is no tool from automatically map from one space to the other. That mapping must be performed by a designer/developer.
> This is strategy we follow for the portal services
Correct me if I am wrong, Jordi, but I believe your tooling deals with code generation based on structural aspects only. That limits what kind of code can be generated, and also limits how much you include in your model (models and generated code omit important parts). I can see how, if you limit yourself to modeling structural aspects only, the distinction between analysis and design models can be harder to identify.
In the general case, I agree that human intervention is needed. My point is that you can “encode” this human intervention as a default design strategy in the tool itself to bridge the gap automatically.
For instance, I proposed an approach to automatically derive action specifications from operation pre and postconditions . Of course, with limitations, this method was able create kind of “executable UML models” (design models) from conceptual schemas where operations where just defined using analysis contracts.
My point there was that even if a contract just defines the “what” but not the “how”, it is possible to guess a good enough “how” from the “what” in many situations.
Rafael, it is definitely possible to define a transformation (or an interpreter) that can produce running system from an analysis model. Good interpretive example is Mendix (www.mendix.com). Another interpretive example is here: http://tinyurl.com/6cd8hfh. Some years ago I myself developed a software factory for a specific problem domain that generated web applications for Zope platform. It seems that Jordi and UltraDark may have more examples..
These solutions do come at a price: they usually reduce the space of available choices (as many of the choices have already been predefined: design strategy, supported platforms, etc..). It is up to customers to choose which solution direction suits them most.
And to make it clear, the above examples deal with both structural and behavioral aspects 🙂
I think I should clarify what I mean by notation.
A notation is a system of symbols used to specify a Model.
For example, Z is a formal mathematical textual notation, while UML and the Executable UML profile are graphical notations.
Im asserting that this definition only includes computer languages that are purposely constructed to only specify concepts bounded by the System and furthermore are completely incapable of describing, invoking or manipulating architectural and implementation mechanisms such queues, stacks, processes, remote procedure calls, message passing protocols, file access, databases, handling user input and output, windows management and other things unless explicitly modelled by virtue of the fact they are the subject of the domain under analysis that forms the System.
Andriy,
Yes, if you reduce the solution space enough (domain and/or technical dimensions), that can definitely blur the distinction between analysis/problem and design/solution, allowing domain experts to create the solution (a la DSM). Is that what you are referring to?
I was thinking of the more general case where the analysis and design are clearly separate activities, and make use of general-purpose languages, like UML, for instance. In the typical scenario the gap between problem and solution is just not trivial enough to allow for automating that mapping process.
Jordi, please see my response to Andriy above.
> My point there was that even if a contract just
> defines the “what” but not the “how”, it is
> possible to guess a good enough “how” from
> the “what” in many situations.
In fact, I’d say one should never specify the “how” if the “what” IS enough (declarative better than imperative). ANY application will have SOME instances OF that. But FOR ALL but most trivial applications you cannot fully define the solution IN terms OF CONSTRAINTS (even if you ARE dealing WITH the DOMAIN dimension ONLY). So even if the gap can be somewhat narrowed, it IS still there.
I think we think along the same lines.. However I would NOT use word “reduction” w.r.t. solution SPACE. IN stead I would use “charting” OF solution SPACE.. IN those examples, developers had TO travel the solution SPACE AND they FOUND that certain paths (IN other words design AND implementation choices) ARE working FOR a family OF problems. THEN they built interpreters OR generators that help navigate/travel development FROM problem description TO working systems very fast. So it IS MORE LIKE highways over the same distance instead OF reduced distance..
I have done BA work in the past but I get drawn back to Real-Time Systems.
The problem I’m HAVING AT the moment IS WITH your notion OF “(executable) design models”.
If we take the stakeholders system AND analyse it we END up WITH an xUML analysis model AT the M1 LEVEL OF analysis abstraction.
Now, this same model IS also AT the analysis LEVEL OF design abstraction. Sorry, I know this sounds confusing, but it just means that there exist higher design abstraction LEVEL models (FOR example, formal specification IN the Z Notation) AND LOWER design abstraction models (FOR example, design AT the architectural LEVEL) that can represent the same system.
This model will NOT EXECUTE ON its own. FOR that we need a Model Compiler (leaving aside simulation). A Model Compiler IS defined AS domains AT M2 AND works ON the stakeholders analysis model TO generate code. These domains AT M2 determine the architectural constructs AND program structure (Shlaer-Mellor Software Architecture) OF the generated code AND actually form the Model Compiler itself.
The Model Compiler domains ARE analysis models AND can be considered design artefacts (OR models). However, they have been created by analysis IN exactly the same way AS ANY stakeholder application DOMAIN. Design IS a perfectly valid subject matter FOR analysis.
I think we ARE just disagreeing ON terminology. I am USING the terms analysis model AND design model AS the products OF (respectively) the analysis AND design phases OF the software development lifecycle (SLDC).
The terms analysis AND design ARE clearly defined AS being completely separate phases (one IS concerned WITH understanding requirements, the other WITH satisfying them), so things LIKE “analysis level of design abstraction” sound really confusing.
AFAIK, xUML IS focused ON the solution side OF things, AND has NO implications ON the way requirements ARE gathered. I suspect what you see (IN the context OF xUML) AS an analysis model may be the same thing I see AS a design model. Even MORE, I won’t be surprised if xUML practitioners might downplay the idea of analysis as a distinct phase/model, given how easy it is to model (design) a solution that allows execution/code generation (wouldn’t blame them FOR that). FOR instance, the Executable UML book [Mellor/Balcer] has a small chapter ON requirements AT the beginning OF the book (USING ONLY use cases, but NO classes), AND THEN starts talking about solution (design) FOR the rest OF the book (starting FROM class AND attribute modeling).