Re: [UML Forum] programming language versus modeling language

[Remy Fannader]

A first distinction is about target: programming languages deal with software, modeling languages deal with systems (software+agents+devices).
A second one is about outcome: programming languages cover all the way to products, modeling languages don't.
http://caminao.wordpress.com/how-to-represent-objects-and-activities/quality/languages-models/
http://caminao.wordpress.com/system-engineering/products-projects-processes/model_transformations/

On 7 February 2013 18:01, Mary <rand.e...@gmail.com> wrote:

Hi, all

i really like to know the differences between programming language and modeling language?

i do know that a programing language used through implementation phase and modeling language used through analysis and design phase .


Best Regards

--
--
You received this message because you are subscribed to the Google
Groups "UML Forum" group.
Public website: www.umlforum.com
To post to this group, send email to umlf...@googlegroups.com
To unsubscribe from this group, send email to
umlforum+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/umlforum?hl=en?hl=en
 
---
You received this message because you are subscribed to the Google Groups "UML Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to umlforum+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[H. S. Lahman]

Responding to Mary...

i really like to know the differences between programming language and modeling language?

i do know that a programing language used through implementation phase and modeling language used through analysis and design phase .

Basically the only difference is the level of abstraction. A model is, by definition, an abstraction of something that is concrete and more complex in detail. To get to the concrete instance, one must add details to the model. Thus a 3GL program can be viewed as a model of the final executable in memory where the added value is detail provided by the compiler, linker, and loader. An OOA/D model in UML is just more abstract and requires more added value to realize as an executable.

-- 
Life is the only flaw in an otherwise perfect nonexistence
   -- Schopenhauer

Imagine how much more difficult physics would be if electrons had feelings
   -- Richard Feynman

Rene Descartes went into a bar. The bartender asked if he would like a drink. Descartes said, "I think not," and disappeared.

H. S. Lahman
H.la...@verizon.net
software blog: http://pathfinderpeople.blogs.com/hslahman/index.html
software book: Model Based development, Addison-Wesley, 2011
geology book: The Evolution and Utilization of Marine Resources, MIT Press, 1972

[H. S. Lahman]

Responding to Rand...

if the difference is only the level of abstraction.
Why theoretical computer science professors consider modeling language worthless or even ignore?

I will be charitable and just say that those CS professors don't understand modern software design. Even the most rabid OOP-based Agile advocate will admit that models have value.

and at the same time i don't have evidence to support  the belief that modeling language is very good ?

Modeling languages are often 4GL languages. UML combined with an Abstract Action Language (AAL) is a 4GL. 4GLs represent the next major paradigm shift in software development. In the late '50s the industry shifted from Assembly language to 3GLs and there was a huge (orders of magnitude) step up in productivity and reliability as a result. The same sort of productivity and reliability boost will occur with the conversion from 3GLs to 4GLs.

The technology has been around for full code generation from 4GL models since the early '80s. However, optimization for 4GLs is a much tougher problem than for 3GLs because one needs to optimize the entire computing space rather than just an instruction set. It was not until the late '90s that optimization for 4GLs was competitive. Now it is just a matter of time.

All you have to do is look at the models vs equivalent 3GL. The models for a 1m LOC application will fit in a couple of dozen diagrams and the total AAL will be << 50K lines. That compaction alone represents orders of magnitude in the sheer size needed. 50-80% of 3GL code is there just to deal with computing space details (e.g., opening files, building network message packets, coding HTML, etc.) that are handled automatically by the code generator, and there is simply no comparison. Finally, it is well established in the literature that the number of defects is directly proportional to the number of lines of code. Therefore, that compaction of representation also represents vast improvements in reliability.

If you want anecdotal evidence, I haven't written more than a few thousand lines of 3GL code since the mid-'80s. Once you use a model-level debugger, you view a 3GL debugger the same way a 3GL programmer views and Assembly debugger. Life is just too short to do that.

-- 
Life is the only flaw in an otherwise perfect nonexistence
   -- Schopenhauer

Imagine how much more difficult physics would be if electrons had feelings
   -- Richard Feynman

Rene Descartes went into a bar. The bartender asked if he would like a drink. Descartes said, "I think not," and disappeared.

H. S. Lahman
H.la...@verizon.net
software blog: http://pathfinderpeople.blogs.com/hslahman/index.html

software book: Model Based Development, Addison-Wesley, 2011
geology book: The Evolution and Utilization of Marine Resources, MIT Press, 1972

[H. S. Lahman]

Responding to George...

> Lahman pointed out the benefits of code side reduction. There is more
> to it, however. The translation from 4GL to 3GL requires the ability
> to think in terms of the 4GL. The language is not about software but
> about specifying rules. 4GL doesn't specify how something works but,
> rather, the constraints within which the system shall exist. The
> translation process realizes a computer program (or more) that abides
> by the rules. The skill is in identifying the salient objects and
> specifying the rules that matter.

True. But there are two benefits. One if that you only need to think
about functional requirements because the transformation engine designer
handles the nonfunctional requirements. The other benefit is the OO
paradigm is already explicitly supports the abstraction required.

>
> Lahman recently said "[n]o one said it would be easy." Don't take his
> comments about the orders of magnitude reduction in code size to mean
> orders of magnitude reduction in required skill. I think this is the
> reason model-driven development is not main stream. The stream is full
> of programmers that could never even develop the skills necessary to
> use MDD. Humbly, I know that I'm still a wannabe.

I have to disagree (somewhat) with this assessment. Yes, there is a
substantial learning curve and OOA models need to be developed much more
rigorously than they are in most shops today. Also, one could argue that
the learning curve is essentially the same learning curve needed to
learn to do OOA/D properly.

OTOH, the sad truth is that one could paraphrase G. B. Shaw's comment on
Christianity: The only problem with OO development it that it has never
been tried. There is a lot of really lousy OO software around because
people converting from procedural development started coding in OOPLs
right away and just mapped procedural practices onto it.

[Thomas Mercer-Hursh, Ph.D.]

On 2/9/2013 9:58 AM, H. S. Lahman wrote:
> I have to disagree (somewhat) with this assessment. Yes, there is a
> substantial learning curve and OOA models need to be developed much
> more rigorously than they are in most shops today. Also, one could
> argue that the learning curve is essentially the same learning curve
> needed to learn to do OOA/D properly.
>
> OTOH, the sad truth is that one could paraphrase G. B. Shaw's comment
> on Christianity: The only problem with OO development it that it has
> never been tried. There is a lot of really lousy OO software around
> because people converting from procedural development started coding
> in OOPLs right away and just mapped procedural practices onto it.

Amen! Not only that, but the perpetrators of some of this stuff will
then turn around and make what they do into a virtue, further confusing
the new programmer.

There is something confusing about the idea of good modeling being
hard. After all, all one is doing is describing how the system is
supposed to work without having to worry about the implementation
details. If one can't do that, then how is one supposed to manually
create a correct, working system? To be sure, one has to learn the
language by which to express oneself, but I find it difficult to believe
that it is harder to master the syntax and usage of UML than C++.

[H. S. Lahman]

Responding to Rand...

In addition to your "anecdotal evidence" , i wonder if there is a "practical evidence" supports this belief? because it is so difficult for a CS professor to convince by "anecdotal evidence"

Only my last paragraph was anecdotal. That defects are proportional to the number of representation elements has been well established since the '70s. That a UML OOA model has vastly fewer representation elements than corresponding 3GL program is obvious by inspection. That an OOA model that does not have to deal with nonfunctional requirements and computing space artifacts will be simpler and easier to get right is patently obvious.

IOW, if the guy got to be a professor believing models are useless, that is a religious issue and you aren't going to change his mind with any evidence.

[Rafael Chaves]

I am really interested in this discussion as I think in it may be the
crux of why modeling is not mainstream. This post is my reflection on
why programming may seem easier than modeling:

"How can modeling be harder than programming?"
http://abstratt.com/blog/2013/02/09/how-can-modeling-be-harder-than-programming/

This is Jean Bezivin's take on the issue:

"Why programming is much harder than modeling?"
http://modelseverywhere.wordpress.com/2013/02/10/why-programming-is-much-harder-than-modeling/

Cheers,

Rafael

[H. S. Lahman]

Responding to Chaves...

"How can modeling be harder than programming?"
http://abstratt.com/blog/2013/02/09/how-can-modeling-be-harder-than-programming/

I think there are three relevant points in response to this. First, I think it is important to note that historically OOA/D recognized the problem of mapping program code to the problem space back in the '80s. That's why OO design was separated into OOA and OOD. That allows one to deal solely with the customer's functional requirements in the OOA model without any computing space distractions. Moreover, OO abstraction was designed to allow the OOA model to be expressed purely in customer terms (i.e., problem domain terms). Thus I would argue that OO modeling is a crucial part of ensuring that there is a proper mapping between customer requirements and program code. That leads to my second point...

In the '70s I was merrily churning out 100 KLOC/yr without models. Anyone can do that; there are 12-year-olds hacking DoD today who can do that. However, if any of that code surfaced today, I would be mortified because it was crap. The problem was my mental Big Picture (i.e., the overall model) was vague and I was writing code in a Joycian stream of consciousness. If you are writing a Quicksort routine you do not need a model full of Partition and Pivot objects because the scope is small. But for larger applications that doesn't work. You need to think about what you are doing -- things like separating functional and nonfunctional requirements. That is especially true when there are multiple developers whose various visions of the software need to be communicated into a consensus.

Models are very effective at expressing the Big Picture and providing unambiguous communication at large scales. Even the most rabid OOP-based Agile process will <grudgingly> admit that sometimes models are useful. My argument, vis a vis the first point, is that they are essential because they are compact and highly focused. That allows you to get things right up front, especially when you have step-stones to the customer domain, like OOA models.

My last point is that UML is really just another programming language. It has the same underlying set and graph theory. It requires the same rigor of expression. It is just primarily graphical. The proof of that is that full code generators for general purpose programming exist. So all one is really doing is learning a new language. During my career I learned dozens of languages; it is no big deal.

What is making it a big deal is that at the model level you are designing software, not coding software. In fact, if one is only coding software, one still needs to design it. One can keep that design in one's head, but that is error prone because people make mistakes and it is tough to peer review things in someone's head. So it is, IMO, almost impossible to produce high quality code for large applications without models. What you get is the hacker code I produced in the '70s.

<aside>
One of my favorite rules of thumb is that if one spends more that 5% of one's time at a keyboard writing 3GL code, one is doing something very wrong. As an anecdotal data point, I was one of ten developers who built a 1 MLOC application in ten months. (We had a leg up because it was an OO rewrite of a procedural system, so we pretty much knew what it had to do.) We spent four months writing and reviewing a functional spec because Marketing's requirements for a $2m system were a page and a half. We spent three months doing OO modeling. We then spent two weeks writing C++ code. The remaining month and a half was spent testing and debugging. When I retired from that shop, we were getting awards for MTTF of 2.7 years, and those were mostly hardware. If you do the math, you are not going to find many 3GL coding shops with that kind of reliability and productivity.
</aside>

This is Jean Bezivin's take on the issue:

"Why programming is much harder than modeling?"
http://modelseverywhere.wordpress.com/2013/02/10/why-programming-is-much-harder-than-modeling/

From that perspective, he's right. I could quibble about some of his tasks (e.g., one already has a platform and environment model in hand because everyone has done other applications there), but I don't think that is relevant. You have to design anyway. My point above is that you are much better off getting the design right up front than doing it in an ad hoc manner as you write 3GL code dealing with everything else.

Perhaps more important -- if you take the next step to translation, all you have to do is model. B-)

[Rafael Chaves]

That is my feeling exactly, Dan - it is not a matter of harder or
easier, but modeling requires a skill that you may get away without
having enough while passing off as a proficient programmer. For those
who have that skill, it is easier (assuming you get the implementation
for free); for those who don't, it will feel harder.

Cheers,

Rafael

On Thu, Feb 14, 2013 at 11:23 AM, Dan George <dgeorg...@gmail.com> wrote:
> I don't know about one thing being more difficult than another. However,
> whatever you do, you need to have skills to do it or it will be hard to do.
>
> I'm a little worried that my comment came off as "modeling is too hard, so
> don't do it." I tried to suggest that programmers typically need some
> significant skill development to create valid and valuable models.
>
> Cheers,
> Dan

[Ken Lloyd]

Jean Bezivin is a very sharp guy, and an excellent educator. Met him long
ago at an OMG Conference. But, the only thing "hard" about modeling or
programming is not knowing what to do (not the same as not knowing what
you're doing - that's a temporary, fixable problem, everyone discovers now
and then).

Programmer's program. They keep programming until the outcome is something
close to what they envisioned. After about three go-rounds, you have
something more like spaghetti. Modeling makes everything easier and more
efficient, only never model more detail than is absolutely necessary -
meaning what you might need to know 5 years later when you are responsible
for maintaining your own code (which you can't recognize or remember ever
having written).

Ken

[H. S. Lahman]

Responding to George...

> I don't know about one thing being more difficult than another.
> However, whatever you do, you need to have skills to do it or it will
> be hard to do.
>
> I'm a little worried that my comment came off as "modeling is too
> hard, so don't do it." I tried to suggest that programmers typically
> need some significant skill development to create valid and valuable
> models.

I think there are two things that need to be learned. One is the
notation, which is the easiest -- you've seen one computer language, you
have seen them all. The other is a design methodology so that one can
create rigorous, correct, and unambiguous designs in the notation.
That's the hard part.

My assertion is that non-modeling 3GL developers who actually know how
to design software are quite rare. And that's why a lot of 3GL software
is junk. Unfortunately one can also model without having a design
methodology and still end up with junk. IOW, the hard part is not ending
up with junk, whether one models or not.

[Scott Finnie]

Good point. But those things needn't be mutually exclusive. There's no inherent reason why there can't be 'instant gratification' from modelling tools. An example in point: mobl (mobl-Lang.org). Not uml, and textual, but a modelling language (actually two) that generates working applications instantly.

Of course one can still hack models: but any tool/method is liable to misuse.  As Lahman said elsewhere, learning to wield a method well is the hardest part.

 - S.

On Friday, 15 February 2013, RJB wrote:

Hacking code is addictive!  So many people get hooked on programming. You don't get the same high from developing a good model as you do with even an incomplete, buggy, rapidly prototyped program. Sadly.

[H. S. Lahman]

Responding to Finnie...

> Good point. But those things needn't be mutually exclusive. There's no
> inherent reason why there can't be 'instant gratification' from
> modelling tools. An example in point: mobl (mobl-Lang.org). Not uml,
> and textual, but a modelling language (actually two) that generates
> working applications instantly.

That instant gratification has been around for decades. It originally
appeared in niche languages like Mobl. The IEEE 716 standard for C/ATLAS
defines a requirements specification language for testing electronics.
It was sufficiently rigorous that within a couple of years there were
full compilers that could take the requirements and directly produce a
full test program. (They are nontrivial programs -- the kind used when
you pull a van up to a B2 bomber, plug in a cable the size of an
elephant's trunk, and test every piece of electronics in the plane.) For
smaller scale there are also design programs like HPVEE and LabView.

Full translation for general purpose programming from 4GLs took awhile
longer because the optimization problems are incredibly complex. But
that technology has been around since the early '80s. In the late '90s
the industry was finally poised for a paradigm shift from 3GLs to 4GLs,
but the OOP-based Agile movement came along and set software development
back a couple of decades.

[Ashley at Metamaxim]

Hi H.S.

> In the late '90s the industry was finally poised for a paradigm shift
from 3GLs to 4GLs, but the
> OOP-based Agile movement came along and set software development back
a couple of decades.

As far as I know Agile is not prescriptive on the source representation
(language) used for software. Is there any reason, in principle, why
should Agile should not be combined with the use of a compilable
modelling language/4GL, thereby getting the benefits of both?

Rgds
Ashley

[Thomas Mercer-Hursh, Ph.D.]

On 2/17/2013 1:43 PM, Ashley at Metamaxim wrote:

> As far as I know Agile is not prescriptive on the source
> representation (language) used for software. Is there any reason, in
> principle, why should Agile should not be combined with the use of a
> compilable modelling language/4GL, thereby getting the benefits of
> both?

I'll give H.S. a hand here :)
http://www.cintegrity.com/sites/cintegrity.com/files/Agile%20Model-based%20Development.pdf

[H. S. Lahman]

Responding to Ashley...

>
> As far as I know Agile is not prescriptive on the source
> representation (language) used for software. Is there any reason, in
> principle, why should Agile should not be combined with the use of a
> compilable modelling language/4GL, thereby getting the benefits of both?

Actually Scott Ambler has been pushing Agile Modeling for nearly two
decades, which is why I qualified 'OOP-based'. Unfortunately the
OOP-based Agile processes dominate.

If you talk to the advocates of XP and Scrum, it is very clear that BDUF
rules and they will bring out the crucifixes and silver bullets if you
do it for more than a few throwaways in an Architectural Spike or for
communication in a particular iteration.

There is no reason why you can't introduce Agile techniques into
modeling. In fact, I think I still have a paper I wrote many moons ago
about doing exactly that. If you are interested I can send it to you.

[H. S. Lahman]

Responding to Mercer-Hursh...

>
> I'll give H.S. a hand here :)
> http://www.cintegrity.com/sites/cintegrity.com/files/Agile%20Model-based%20Development.pdf
>

LOL I didn't realize you had posted that.

Ashley: $nevermind.

[Scott Finnie]

On 17/02/2013 15:41, H. S. Lahman wrote:

> Full translation for general purpose programming from 4GLs took awhile longer because the optimization problems are
> incredibly complex. But that technology has been around since the early '80s. In the late '90s the industry was
> finally poised for a paradigm shift from 3GLs to 4GLs, but the OOP-based Agile movement came along and set software
> development back a couple of decades.

Indeed. But the agile/OOP movement was a reaction to the mega-heavy prescriptions of the elaboration-based juggernaut
that dominated the modelling world. "Methodologies" that evolved to justify the cost of what were essentially very
expensive and (not so) fancy sketching tools. Not surprisingly, people smelled a rat - and questioned why it was all
necessary. Hence the 'back to basics' approach.

The sad irony (as I know you know!) is that Shlaer-Mellor and a few other lonely voices offered an alternative.
Unfortunately their voices were drowned out by the mainstream tidal wave.

If 'modelling' is to re-gain some traction it needs to beat OOP-based agile at its own game. It needs to deliver better
software quicker. That in turn needs an executable, translatable formalism. Combined with effective tools. Small
consolation to us SM disciples that Steve and Sally were right all along :-)

- Scott.

[H. S. Lahman]

Responding to Finnie...

Indeed.  But the agile/OOP movement was a reaction to the mega-heavy prescriptions of the elaboration-based juggernaut that dominated the modelling world.  "Methodologies" that evolved to justify the cost of what were essentially very expensive and (not so) fancy sketching tools.  Not surprisingly, people smelled a rat - and questioned why it was all necessary.  Hence the 'back to basics' approach.

Right. BDUF (Big design Up Front) assumes a single massive waterfall development model for everything, which is pretty much ancient history now because almost everyone tends to do IID, whether they are modeling or not. Unfortunately modeling in general got tarred with that brush.

<aside>
The OOP-based Agile crowd tends to rail about waterfall development. However, I find it quite ironic that if you look closely at their processes, they are very rigid waterfalls. There are just 1-3 weeks long. However, they argue that if you are modeling, you must be doing a waterfall, and that is evil.
</aside>

If 'modelling' is to re-gain some traction it needs to beat OOP-based agile at its own game.  It needs to deliver better software quicker.  That in turn needs an executable, translatable formalism.  Combined with effective tools.  Small consolation to us SM disciples that Steve and Sally were right all along :-)

That's quite true. Clearly application developers are going to be able to deliver software faster if all they have to resolve is functional requirements and they don't have to worry about nonfunctional requirements, computing space technologies, and physical coupling in the OOPLs.

But I think there is another reason that people don't talk about much. The OOP-based Agile processes incorporate testing into development, which is a very good thing. The problem is they they rely on it exclusively to obtain reliability -- if it passes the customer's acceptance tests, it is correct by definition. Hence the buzz phrase 'test-driven design'. The problem with that is that pure testing will, at best, get you 5-Sigma reliability because of the combinatorial problems of testing large applications. (Which manufacturers in the West discovered in the '80s when the PacRim blew them away because they didn't put defects in the product in the first place. 5-Sigma does not cut in manufacturing today and customers are beginning to wonder why software is the only thing that breaks anymore.)

To get to 6-Sigma and beyond, you need process-oriented development where defect prevention is the key. To achieve that, you have to constantly monitor and modify the process. However, the OOP-based Agile processes are actually very rigid; they literally tell you how to write 3GL code down to the code fragment level (witness: Fowler's Refactoring is a bible in those circles). The problem with rigid processes is that they are not adaptable. One of the things I rememebr well from my debates with XPers years ago was the mantra, "If you do Xxxx, you are not doing XP," that came up a lot. (In my less charitable moments I tend to refer to XP as PbM -- Programming by Mantra.) That rigidity will be a major bar to providing high quality software.

(Obviously you can have a rigid modeling process. However, no guru is standing on a mountain top in Switzerland holding tablets having 12 Principles and telling you that can't modify them as an article of faith.)

[Thomas Mercer-Hursh, Ph.D.]

On 2/19/2013 10:44 AM, H. S. Lahman wrote:

> That's quite true. Clearly application developers are going to be
> able to deliver software faster if all they have to resolve is
> functional requirements and they don't have to worry about
> nonfunctional requirements, computing space technologies, and
> physical coupling in the OOPLs.

While I think it is true that MBD can deliver the initial application
somewhat faster, my guess is that this is not its dramatic benefit.
More dramatic is the increased likelihood that the application is
correct coming out of the gate because of the attention which has been
put into resolving requirements completely during the modeling. If one
doesn't produce the correct application, it doesn't matter how quickly
it is produced because one will lose any advantage in cycling until the
correct version is produced.

And, even more dramatic is the savings over the lifecycle of the
application. Requirements constantly change and so one typically ends
up spending many more hours in maintenance than one does originally
creating the application. With MBD, however, finding the place to make
the change is extremely quick, easy, and reliable, and making the change
is simply modifying the model and turning on the translator to produce
new code.

This can be particularly dramatic when the revision isn't a simple
change in functional requirements, but a change in the architecture of
the application since the same model can be used to produce a new
architecture by changing the translator.

[H. S. Lahman]

Responding to Mercer-Hursh...

While I think it is true that MBD can deliver the initial application somewhat faster, my guess is that this is not its dramatic benefit.   More dramatic is the increased likelihood that the application is correct coming out of the gate because of the attention which has been put into resolving requirements completely during the modeling.  If one doesn't produce the correct application, it doesn't matter how quickly it is produced because one will lose any advantage in cycling until the correct version is produced.

I agree correctness is an issue, but I think it is more indirect. In fact, all software should be correct no matter how one constructs it. To do that you have to think about what you are doing and be rigorous with the design. You can do that at the 3GL level, but it is difficult. It is a lot easier at the OOA level because one is focused on just functional requirements and models are more compact descriptions. I would argue that one should put in the necessary effort at the 3GL level. But if it is more difficult, it will take longer and that becomes a productivity issue again.

FWIW, I would rank the benefits as:

(1) Maintainability -- this is orders of magnitude improvement, but it is hard to separate the effect of good OO practice from those of modeling and translation.

(2) Reliability -- This can be integer factors. (A process-oriented shop will do much better here than a traditional test-oriented shop, but that is independent of modeling and translation.)

(3) Initial development time -- This is double digit percentages. And it is probably small or nonexistent if one restricts the scope to simply producing an application because much of the trade-off is between spending more time doing OOA and a lot less time in test & debug, which reduces overall development time. (Which indirectly gets back to your point.)

And, even more dramatic is the savings over the lifecycle of the application.   Requirements constantly change and so one typically ends up spending many more hours in maintenance than one does originally creating the application.   With MBD, however, finding the place to make the change is extremely quick, easy, and reliable, and making the change is simply modifying the model and turning on the translator to produce new code.

This can be particularly dramatic when the revision isn't a simple change in functional requirements, but a change in the architecture of the application since the same model can be used to produce a new architecture by changing the translator.

You've become quite the convert, haven't you? B-)

[Thomas Mercer-Hursh, Ph.D.]

On 3/11/2013 3:02 AM, Remy Fannader wrote:
> First, one must consider their respective purposes: modeling
> languages are for communication between people, programing ones are
> for communication with machines. Then, that will determine contents:
> models are supposed to deal with concerns, possibly to be discussed
> and modified; programs are meant to be released and their contents
> final.

Except, of course, when using Model-Based Development where the model is
the code.

[H. S. Lahman]

Responding to Fannader...

> First, one must consider their respective purposes: modeling languages
> are for communication between people, programing ones are for
> communication with machines.

Actually, the best use of models is in translation, where a
transformation engine generates the executable directly from the model.

The second most important value in modeling is to ensure everyone on the
development team has the same vision of the overall design. IOW, the
models act as a benchmark reference.

> Then, that will determine contents: models are supposed to deal with
> concerns, possibly to be discussed and modified; programs are meant to
> be released and their contents final.

The problem with this view is that such models may be incomplete,
ambiguous, or incorrect. Since the models represent high level software
design, any such problems may not be detected until manual code
generation is well under way. Then fixing any design problems later can
trigger major rewrites. Whether one uses translation or not, the models
should be as carefully constructed and rigorous as if one intended to
use translation.

[Remy Fannader]

Obviously, when programs can be obtained from models there is not much to discuss ... Problems begin when there is a difference.

--
--
You received this message because you are subscribed to the Google
Groups "UML Forum" group.
Public website: www.umlforum.com
To post to this group, send email to umlf...@googlegroups.com
To unsubscribe from this group, send email to

umlforum+unsubscribe@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/umlforum?hl=en?hl=en

--- You received this message because you are subscribed to the Google Groups "UML Forum" group.

To unsubscribe from this group and stop receiving emails from it, send an email to umlforum+unsubscribe@googlegroups.com.