Home > Archive > Software Engineering > August 2004 > Questioning code generation from UML
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Questioning code generation from UML
|
|
|
| While automatic code-generation has been a long time ideal of OO
purists there have been several concerns/impediments to its use in the
software development process. Ideally we should be able to describe
all our objects/interfaces via the UML class diagrams and forward
engineer to get the source code to the level of "class skeletons" so
that to get to final deliverable code, we need to fill in only the
"method-stuffings".
However I have several doubts about the efficacy of employing forward
engineering to generate class level skeleton code.
1. In order to generate class level skeleton code, the class diagram
needs to be greatly detailed, which makes the class diagram very
cumbersome to read except for trivially small designs. Since one of
the aims of having class diagrams prior to code generation (automatic
or otherwise) is to get/generate a birds eye view of the system,
having to draw up a detailed design clearly defeats the purpose.
2. Along the same lines, drawing class diagrams to great level of
detail is IMHO, slower than writing code for the same (considering the
refactoring and automatic code generation facilities in most modern
IDEs). Moreoever code has another BIG advantage in that it can be
actually "run" after incremental development, while a class diagram is
at best a very pretty, pithy picture.
3. changing requirements scenario: Consider the case that forward
engineering has been done, followed by "method-stuffing" after which
requirements are changed which impacts the current interface/class
design. In this case is it is reasonable to make changes in code and
synchronize the changes in the class diagram using the facility of
leading CASE tools (the alternative - to make changes in your diagram
first, regenerate the code and cut-paste from the original source code
making changes consistent with the new design - is not very attractive
and clearly seems error-prone). What then is the advantage of having a
detailed class diagram in the first place if it eventually may have to
be changed via the code?
In the contexts of these questions, I would like to hear from those
who have successfully/unsuccessfully employed partial/full code
generation on how these issues were addressed, or the best
practices/suggestions in this area.
regards,
~ amol
Note: A related discussion is <a
href="http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=ba162549.0404201223.7cad80e4%40posting.google.com&rnum=3&prev=/ groups%3Fq%3DCASE%2Btools%2Bfor%2BOO%2B%
2522code%2Bgeneration%2522%2Bgroup:comp.software-eng%26hl%3Den%26lr%3D%26ie%3DUTF-8%26s
coring%3Dd%26selm%3Dba162549.0404201223.7cad80e4%2540posting.google.com%26rnum%3D3">
"Code generation with UML" </a>
| |
|
| Amol wrote:
> While automatic code-generation has been a long time ideal of OO
> purists there have been several concerns/impediments to its use in the
> software development process. Ideally we should be able to describe
> all our objects/interfaces via the UML class diagrams and forward
> engineer to get the source code to the level of "class skeletons" so
> that to get to final deliverable code, we need to fill in only the
> "method-stuffings".
>
>
> However I have several doubts about the efficacy of employing forward
> engineering to generate class level skeleton code.
The number one doubt is this process doesn't prevent bugs. The number two
doubt is it doesn't lead to rapid development, and number three is up-front
requirements analysis can lock down a design, making it very fragile for
changing requirements. They lead to "breaking" the design, and to bugs.
> 1. In order to generate class level skeleton code, the class diagram
> needs to be greatly detailed, which makes the class diagram very
> cumbersome to read except for trivially small designs. Since one of
> the aims of having class diagrams prior to code generation (automatic
> or otherwise) is to get/generate a birds eye view of the system,
> having to draw up a detailed design clearly defeats the purpose.
Right. A UML diagram should be a map, not the territory.
> 2. Along the same lines, drawing class diagrams to great level of
> detail is IMHO, slower than writing code for the same (considering the
> refactoring and automatic code generation facilities in most modern
> IDEs). Moreoever code has another BIG advantage in that it can be
> actually "run" after incremental development, while a class diagram is
> at best a very pretty, pithy picture.
There is an even greater benefit to feedback from live code: It can submit
to tests.
> 3. changing requirements scenario: Consider the case that forward
> engineering has been done, followed by "method-stuffing" after which
> requirements are changed which impacts the current interface/class
> design. In this case is it is reasonable to make changes in code and
> synchronize the changes in the class diagram using the facility of
> leading CASE tools (the alternative - to make changes in your diagram
> first, regenerate the code and cut-paste from the original source code
> making changes consistent with the new design - is not very attractive
> and clearly seems error-prone). What then is the advantage of having a
> detailed class diagram in the first place if it eventually may have to
> be changed via the code?
The benefit is simple: Your boss has experienced code-and-fix projects, with
high bug rates and high cost-of-change. The longer such a project goes, the
more likely it will be scrapped.
Your boss sees poor designs that are hard to change and extend, so it
declares "We will design everything before coding it".
The problem with this approach is simple to state: The purpose of
programming is to deliver features, based on code behaviors. The purpose is
NOT to deliver an elaborate design that users cannot see or rejoice over.
If behavior is more important than design, then write the behaviors first.
(Stuff your methods first!) Your system requires speculating how those
wonderful designs will behave together. To remove all speculation from the
loop, write tests that request behavior. Then write the behavior that passes
the tests. Then refactor, to design the relation between a program's
structures in memory and their behaviors in time. This process designs
/last/, by refactoring. Only perform very few edits between passing all
tests. This forces a design to remain testable, which in turn forces it to
remain flexible and bug-resistant.
When you develop, use a test runner, written in the same language as the
Production Code, that provides some kind of visual feedback at the end of
the test run. Either use a GUI-based test runner that displays a Green Bar
on success or a Red Bar on failure, or a console-based test runner that
displays "All tests passed" or a cascade of diagnostics, respectively.
Write failing tests, and briefly make them pass. Then refactor to improve
maintainability, testing every few edits, to ensure all tested behaviors
stay the same.
Engage each action in this algorithm:
* Locate the next missing CODE ABILITY you want to add
* WRITE A TEST that will only pass if the ability is there
* Run the test and ensure it FAILS FOR THE CORRECT REASON
* Perform the MINIMAL EDIT needed to make the test pass
* When the tests pass and you get a Green Bar, INSPECT THE DESIGN
* While the design (anywhere) is low quality, REFACTOR it
* Only after the design is squeaky clean, PROCEED TO THE NEXT ABILITY.
That algorithm needs more interpretation. Looking closely into each bold
item reveals a field of nuances. All are beholden to this algorithm and to
the intent of each action. Each action leverages different intents; they
often conflict directly with other actions' intents. Our behaviors during
each action differ in opposing ways. Repeated edits with opposing intents
anneal our code in a way that one must experience to fully appreciate and
begin to understand. Suspend disbelief, try the cycle, and report your
results to an Agile Alliance near you.
A CODE ABILITY, in this context, is the current coal face in the mine that
our picks swing at. It's the location in the program where we must add new
behavior, or change existing behavior. Typically, this location is near the
bottom of our most recent function. If we can envision one more line to add
there, or one more edit to make there, then we must perforce be able to
envision the complementing test that will fail without that line or edit.
WRITE A TEST can mean to WRITE A TEST function, and get as far as one
assertion. Alternately, take an existing test function, and add new
assertions to it. To re-use scenarios and bulk up on assertions, we'll
prefer the latter. Some TDD theorists propose minimizing test case size, and
not bulking up on assertions. Expensive setup is a code smell, but if our
GUI Toolkits make setup slow, and provide zillions of side-effects, we make
the most of each test case.
If the new test lines assume facts not in evidence - if, for example, they
reference a class or method name that does not exist yet - run the test
anyway and predict a compiler diagnostic. This test collects valid
information just like any other (and it minimizes all possible reasons not
to hit that test button). If the test inexplicably passes, you may now
understand you were about to write a new class name that conflicted with an
existing one.
Work on the assertion and the code's structure (but not behavior) until the
test FAILS FOR THE CORRECT REASON. If it passes, step thru and inspect the
code to ensure you understand it, and ensure the true reason was indeed
correct; then PROCEED TO THE NEXT FEATURE.
All this work prepares you to make that MINIMAL EDIT. Go ahead and write
that line which you have been anxious to get out of your system for the last
four paragraphs.
The edit is minimal because we live on borrowed time until the Bar turns
Green. Correct behavior and happy tests come (just slightly) before design
quality. We might pass the test by cloning a method and changing one line in
it. If that's the minimum number of edits, do it. Or, re-write a method from
scratch, even if it turns out very similar to an existing method. And often
the simplest edit naturally extends a pre-existing clean design that won't
need refactoring, yet.
The edit is minimal because it may do anything, including lying, to make the
test pass. More tests will force out the lie. Practice this technique, to
develop habits that work even when you don't know the production code lies.
If the MINIMAL EDIT fails, and if the fault is not obvious and simple, just
hit the Undo button and try again. Anything else is preferable to
bug-hunting, and an ounce of prevention is worth a pound of cure.
Now that we have a Green Bar, we INSPECT THE DESIGN. Per the MINIMAL EDIT
principle, the most likely design flaw is duplication. So, to help us learn
to improve things, we spread the definition of "duplication" as wide as
possible, beyond mere code cloning.
The book /Design Patterns/ advises to "abstract the thing that varies". This
is the reverse way to say "merge the duplication that does not vary". So
merging duplication together may tend to approach a Pattern.
To REFACTOR, we inspect our code, and try to envision a design with fewer
moving parts, less duplication, shorter methods, better identifiers,
separated concerns, and deeper abstractions. Start with the code we just
changed, and feel free to involve any other code in the project. But, during
this step, never change functionality - only design.
If we cannot envision a better design, we can proceed to the next step
anyway. S MINIMAL EDITs that will either improve the design or lead to a
series of similar edits leading to an improvement. Between each edit, run
all the tests. If any test fails, hit Undo and start again.
Don't REFACTOR in order from hard to easy. Refactor from easy to easy. Start
by picking the low-hanging fruit.
The level of cleanness is important here. You may have code quality that
formerly would have passed as "good enough". Or you may become enamored of
some new abstraction that new code might use, possibly months from now, or
minutes. Snap out of it. The path from cruft to new features is always
harder than the path from elegance to new features. Fix the problems,
including removing any speculative code, while the problems are still small.
If you see duplication, but can't imagine how to improve its design without
obfuscating what it does (or if you can't imagine any way at all), put the
duplicating lines right next to each other. This practice forms little
readable tables.
We may add assertions at nearly any time; while refactoring the design, and
before PROCEEDing TO THE NEXT ABILITY. Whenever we learn something new, or
realize there's something we don't know, we take the opportunity to write
new assertions that express this learning, or query the code's abilities. As
the TDD cycle operates, and individual abilities add up to small features,
we take time to collect information from the code about its current
operating parameters and boundary conditions.
Boundary conditions are the limits between defined behavior and regions
where bugs might live. Set boundaries for a routine well outside the range
you know production code will call it. Research "Design by Contract" to
learn good strategies; these roll defined ranges of behaviors up from the
lower routines to their caller routines. Within a routine, simplifying its
procedure will most often remove discontinuities in its response.
Parameters between these limits now typically cause the code to respond
smoothly with linear variations. The odds of bugs occurring between the
boundaries are typically lower than elsewhere. For example, today's method
that takes 2, 3 and 5 and returns 10, 15 and 25, respectively, is unlikely
tomorrow to take 4 and return 301. Like algebraic substitutions reducing an
expression, duplication removal forces out special cases.
After creating a function, other functions soon call it. Their tests engage
our function too. Our tests cover every statement in a program, and they
approach covering every path in a program. We add features in order of
business values, so the code of highest value - written earliest -
experiences the highest testing pressure and the most test events for the
remaining duration of the project. The cumulative pressure against bugs make
them extraordinarily unlikely.
If you are curious, or code does something unexpected, or you receive a bug
report, always write a new test. Then use what you learned to improve
design, and write more tests of this category. If you treat the situation
"this code does not yet have that ability" as a kind of bug, then the TDD
cycle is nothing but a specialization of the principle "capture bugs with
tests".
Teach your colleagues to write tests on your code, and learn to write tests
on theirs too. If they WRITE A TEST that fails due to missing abilities, not
faults in deployed abilities, treat the failing test as a feature request,
and prioritize it.
That cycle rapidly builds powerful code with a simple design. For example,
here's a recursive descent parser I wrote in a morning, using it:
http://www.xpsd.org/cgi-bin/wiki?RecursiveDescentParser
That cycle's effects scale. The bigger your program, the more tests
constrain it, and the /easier/ it becomes to change.
--
Phlip
http://industrialxp.org/community/b...tUserInterfaces
| |
| Robert Klemme 2004-08-16, 8:58 am |
|
"Amol" <deshmua@ececs.uc.edu> schrieb im Newsbeitrag
news:51d763aa.0408151619.6f5994c2@posting.google.com...
> However I have several doubts about the efficacy of employing forward
> engineering to generate class level skeleton code.
You're not alone.
robert
| |
| David Lightstone 2004-08-16, 8:58 am |
|
"Phlip" <phlip_cpp@yahoo.com> wrote in message
news:qlTTc.1087$9Q1.527@newssvr15.news.prodigy.com...
> Amol wrote:
>
>
> The number one doubt is this process doesn't prevent bugs.
Big deal, no process prevents bug. You still have to use your brain
> The number two
> doubt is it doesn't lead to rapid development,
When did rapid development become an evaluation criteria
> and number three is up-front
> requirements analysis can lock down a design,
Don't be silly, requirements are just that. Now if you want to state that
most people don't know the difference between requirements and design, who
am I to disagree
> making it very fragile for
> changing requirements.
Does that mean you believe that the diagrams can't be refactored?
Don't be silly of coase they can. Just look for the patterns
enough said I have better uses for my time
| |
| Richard Quinn 2004-08-16, 8:58 am |
| On 15 Aug 2004 17:19:21 -0700, deshmua@ececs.uc.edu (Amol) wrote:
>1. In order to generate class level skeleton code, the class diagram
>needs to be greatly detailed, which makes the class diagram very
>cumbersome to read except for trivially small designs.
No it doesn't. Skeletal code is never modeled. It is defined in
templates and applied using stereotypes. Changing the stereotype of a
class from "EJB Entity Bean" to "COM+ MTA Class" will require little
or no change in the classes attributes / operations.
>Since one of
>the aims of having class diagrams prior to code generation (automatic
>or otherwise) is to get/generate a birds eye view of the system,
>having to draw up a detailed design clearly defeats the purpose.
With correct packaging the class diagrams can easily be made self
containing. We created several medium sized business apps using UML.
The great advantage was being able to take these diagrams to the
customer and asking them to verify the object modeling based on their
domain expertise.
>2. Along the same lines, drawing class diagrams to great level of
>detail is IMHO, slower than writing code for the same (considering the
>refactoring and automatic code generation facilities in most modern
>IDEs). Moreoever code has another BIG advantage in that it can be
>actually "run" after incremental development, while a class diagram is
>at best a very pretty, pithy picture.
Class diagrams can be shown with different levels of detail. For
overviews removing all adornments and all operations / attributes is
great. For detailed work of course you'll want those. I generally
think that the major usefulness of class diagrams is in representing
associations between classes, this requires no more than drawing a
line between two classes and defining the association type. This is
exactly the kind of information which can be very difficult to extract
from a large OO code base during manual inspection.
In my experience (Rose, VB generation) generating application code
like this was a great help. Lots of method "scaffolding" (error
catching, COM instantiation, debugging code, security context
checking) could be piled into the template methods. This kind of code
would typically make up 10 lines of a 13 line procedure. The time
savings were enormous. Of course, VB is not an ideal language for most
kinds of work. I have also used Rose in J2EE environments. Building
the various supporting interface and stub classes by generating was
also a great time saver.
Class diagrams alone are not going to take you very far down the
round-trip engineering road. For greater rigour OCL really does help.
To show interactions it is absolutely necessary to have sequence
diagrams.
>3. changing requirements scenario: Consider the case that forward
>engineering has been done, followed by "method-stuffing" after which
>requirements are changed which impacts the current interface/class
>design. In this case is it is reasonable to make changes in code and
>synchronize the changes in the class diagram using the facility of
>leading CASE tools (the alternative - to make changes in your diagram
>first, regenerate the code and cut-paste from the original source code
>making changes consistent with the new design - is not very attractive
>and clearly seems error-prone). What then is the advantage of having a
>detailed class diagram in the first place if it eventually may have to
>be changed via the code?
Yes, the major difficulty with MDA is keeping the model and the code
synchronized. So we don't do that. We have used the following
approach:
* UML during requirements analysis / software design for Release 1.0
only.
* Major new components designed / documented with UML
* All changes thereafter are done exclusively in code, no
round-tripping.
This gave us these advantages:
* A detailed overview of component architecture / software design
(UML)
* A large majority of "scaffolding" code was auto-generated, much
lower defect rate than otherwise - also saving time.
* Pretty pictures which were really useful in translating the
customer's problem domain into an accurate description of the software
solution
* Assurance that the solution covered all aspects of the problem
without having had to code - no design changes later
* Removal of all synchronization issues between code / model
* No or little modeling of business rules (except of course the rules
engine)
and the following di vantages
* Model inevitably becomes increasingly outdated (But its usefulness
decreases at a much slower rate)
Of course our projects lend themselves to a traditional OOA / OOD
approach: they usually come with a detailed problem specification. If
the project is characterized by requirements instability then I doubt
that this approach would work. If the project is small, and if it
requires very little of the scaffolding code that many projects do,
then auto-generating method stubs would seem pointless.
If you consider that a major cost of development revolves around
changing the software design between iterations (versions) and its
associated problems then clearly a process which gives you confidence
that the proposed solution is viable before coding begins is
advantageous. Naturally, if you have a requirements horizon only as
long as your arm then this approach (or any other process mandating an
analysis / design step) will hardly help.
- Richard
---
richard.quinn@ieee.org
www.richard-quinn.com
| |
|
| "Robert Klemme" <bob.news@gmx.net> wrote in message news:<2obcdcF8hb8tU1@uni-berlin.de>...
> "Amol" <deshmua@ececs.uc.edu> schrieb im Newsbeitrag
> news:51d763aa.0408151619.6f5994c2@posting.google.com...
>
>
> You're not alone.
>
> robert
Thanks Robert for the reassurance :) and thanks also to Phlip for the
outlining the TDD process in such detail.
Anyway,
I was actually hoping to get some responses in defense of "code
generation by forward engineering". At this point I'm convinced that
code generation thru forward engineering (based on UML) is a flawed
goal. Like Phlip pointed out, CG-thru-FE impedes RAD, does not give
immediate feedback like "code that runs"
In that case, how do companies that use UML-CASE tools justify the
high (?) cost of UML-based CASE tools when all we need is a capability
to draw quick concise diagrams (paper or whiteboard works for me) to
get to the next stage -'coding' (or 'writing tests' if one is TDD
inclined)?
Would anybody currently using Rose/Together/<your-fav-UML-CASE-tool>
care to join in the dicussion explaining the value of the tools that
they are using in their overall software development process?
regards,
~ amol
| |
| Robert Klemme 2004-08-16, 3:58 pm |
|
"Amol" <deshmua@ececs.uc.edu> schrieb im Newsbeitrag
news:51d763aa.0408160853.35527dba@posting.google.com...
> "Robert Klemme" <bob.news@gmx.net> wrote in message
news:<2obcdcF8hb8tU1@uni-berlin.de>...
>
>
> Thanks Robert for the reassurance :) and thanks also to Phlip for the
> outlining the TDD process in such detail.
>
>
> Anyway,
> I was actually hoping to get some responses in defense of "code
> generation by forward engineering". At this point I'm convinced that
> code generation thru forward engineering (based on UML) is a flawed
> goal. Like Phlip pointed out, CG-thru-FE impedes RAD, does not give
> immediate feedback like "code that runs"
Well, go to http://www.omg.org/mda - OMG is still pretty much convinced that
this is the way to go. IMHO they (a) need a justification to keep the club
alive and (b) got somewhere lost in meta model space. They did CORBA and
UML quite well IMHO, but usage fell far short of what they envisioned. My
0.02 cent...
Everyone else is trying to get UML round trip engineering to work - but
didn't succeed yet. I'm not sure whether they will ever - and whether I
would want to model a complete complex system in UML.
see
http://www.borland.com/together/
http://www.fujaba.de/
> In that case, how do companies that use UML-CASE tools justify the
> high (?) cost of UML-based CASE tools when all we need is a capability
> to draw quick concise diagrams (paper or whiteboard works for me) to
> get to the next stage -'coding' (or 'writing tests' if one is TDD
> inclined)?
Dunno...
> Would anybody currently using Rose/Together/<your-fav-UML-CASE-tool>
> care to join in the dicussion explaining the value of the tools that
> they are using in their overall software development process?
I use a drawing tool with some UML support once in a while in order to
document crucial parts or core concepts of a system. In the earlier stages
I use paper and pencil.
Kind regards
robert
| |
|
| Amol wrote:
> In that case, how do companies that use UML-CASE tools justify the
> high (?) cost of UML-based CASE tools when all we need is a capability
> to draw quick concise diagrams (paper or whiteboard works for me) to
> get to the next stage -'coding' (or 'writing tests' if one is TDD
> inclined)?
In my ... zeal to describe software development's inner cycle, I forgot the
outer cycle:
Sort features by business priority, implement them in small batches, and
deploy them as often as possible.
This is a design technique. Subsequent features must bow to the primary
ones, of highest business value.
Now how can automating the drawing of UML diagrams help frequent
requirements analysis?
Amol needs to read /Domain Driven Development/ by Eric Evans, but I have not
read it enough to justify all the times I cite it...
--
Phlip
http://industrialxp.org/community/b...tUserInterfaces
| |
|
| "David Lightstone" <david._NoSpamlightstone@prodigy.net> wrote in message news:<gI0Uc.3645$FV3.2198@newssvr17.news.prodigy.com>...
> "Phlip" <phlip_cpp@yahoo.com> wrote in message
> news:qlTTc.1087$9Q1.527@newssvr15.news.prodigy.com...
>
> Big deal, no process prevents bug. You still have to use your brain
>
>
> When did rapid development become an evaluation criteria
>
>
> Don't be silly, requirements are just that. Now if you want to state that
> most people don't know the difference between requirements and design, who
> am I to disagree
>
>
> Does that mean you believe that the diagrams can't be refactored?
> Don't be silly of coase they can. Just look for the patterns
>
David, the concern I have regarding refactoring diagrams is that when
you use automated code generation after diagram-refactoring, you will
get a *skeleton* code. You have to then either copy paste the "method
stuffing" from the previously written code or recode the 'method
stuffing' all over again.
| |
|
| Amol wrote:
> David Lightstone wrote:
> David, the concern I have regarding refactoring diagrams is that when
> you use automated code generation after diagram-refactoring, you will
> get a *skeleton* code. You have to then either copy paste the "method
> stuffing" from the previously written code or recode the 'method
> stuffing' all over again.
Amol, use Google Groups to review David's posting history. His technique is
to simply gain-say trivial details in your post, leading you to think if you
had just posted a little more accurately he would have understood. Don't get
suckered.
--
Phlip
http://industrialxp.org/community/b...tUserInterfaces
| |
| David Lightstone 2004-08-16, 8:57 pm |
|
"Amol" <deshmua@ececs.uc.edu> wrote in message
news:51d763aa.0408161237.4753bd74@posting.google.com...
> "David Lightstone" <david._NoSpamlightstone@prodigy.net> wrote in message
news:<gI0Uc.3645$FV3.2198@newssvr17.news.prodigy.com>...
the[color=darkred]
forward[color=darkred]
that[color=darkred]
who[color=darkred]
>
> David, the concern I have regarding refactoring diagrams is that when
> you use automated code generation after diagram-refactoring, you will
> get a *skeleton* code. You have to then either copy paste the "method
> stuffing" from the previously written code or recode the 'method
> stuffing' all over again.
I am well aware of your concern. I am also well aware of the misdirection
provided by Phlip. I was attempting to place that misdirection in an
appropriate context. Nothing more.
The last time I used a "code generator" based on diagramming the tool was
called MatrixX. The authors of the particular model had a serious
rectal-cranial inversion problem. One which in my opinion (then articulated)
could not be resolved.
I spent quite a bit of time refactoring (modern terminology) and leveling it
(old notation). Barely scratched the surface. There is no real reason for
using such tools (my opinion)
You complaint doesn't surprise me. Using a modeling tool takes more planning
that people realize. The song and dance of productivity (pandering to greed)
doesn't always match the reality of the tools
| |
| Alan Gauld 2004-08-17, 3:56 am |
| > Amol wrote:[color=darkred]
Because not all companies work like you? :-)
Many companies work over distributed locations, often in
different countries. Whiteboards don't work so well when the team
in Bombay have to see the whiteboard in London and discuss it
with the team in Toronto. And as for shipping paper around!!
Of course Visio diagrams on a shared server might address much of
that, but the other feature that the Case tool gives is
consistency checking across large numbers of diagrams. If there
are 30 or more class diagrams in the project with maybe 200-500
classes its important to update every diagram where a class
appears. The tools do that, and publish the change to all sites
in real time, which is a huge time saver.
If your project consists of a small team in a single location
CASE tools don't offer massive benefits unless they do code
generation (and more than just headers!). But in a big team
distributed over the globe, often speaking different first
languages and the cmmunications advantages of a CASE tool are
significant.
Alan G.
Author of the Learn to Program website
http://www.freenetpages.co.uk/hp/alan.gauld
| |
| Cristiano Sadun 2004-08-17, 3:56 am |
| deshmua@ececs.uc.edu (Amol) wrote in
news:51d763aa.0408160853.35527dba@posting.google.com:
> I was actually hoping to get some responses in defense of "code
> generation by forward engineering". At this point I'm convinced that
> code generation thru forward engineering (based on UML) is a flawed
> goal.
Well, I think it's mostly a matter of context, tool capability and
team/programmer approach and discipline.
For example, back in about 1997/98 I used Rose with C++ and Java with a
mixed graphical/text engineering for a period, and it served me
reasonably well - even if the tool was quite limited. Here's some whys:
- sometimes it was quicker to draw a class and (re)generate than to write
the code;
- sometimes it was quite useful to have relevant UML diagrams ready
(switching off unnecessary details) to introduce new teammates to the
architectural bits or do higher management presentations;
- certain types of refactoring (for example, moving methods around) were
(or could have been ;) reasonably easier than to do in code;
- sometimes the hiding the implementation view enables easier observation
of certain properties; for example, to me many patterns have a geometric,
visual flawor which is lost, or less immediate, in a textual
representation.
- a commented and decorated UML diagram (which obviously can be created
only while doing the software, not afterwards) can go very far in
documenting the essentials of a model without cluttering the reader's
mind with details and is a good basis for documentation. For example I
extensively used notes, legnds, color-coded elements, made diagrams SMALL
(mostly fitting in a page), etc.
Nowadays, lots of the speedups that I gained by using that approach are
available in a textual context (at least if u work in Java) - with modern
IDE which for example enable quick refactoring, generation of accessors,
implemetation of interfaces etc. So I'm not sure I'd go that road again -
and surely I'd need way better roundtrip properties than were available
at the time.
And it's a matter of course that some things are specified way more
effectively in code than with (current) graphical notations.
A problem with roundtrip tools is that, to be valuable, the roundtrip
abilities must be really good. Anything less, and it's more a pain in the
a** than anything else.
Keep in mind that I do have a visual approach to modeling - so to me it's
still good to draw the occasional diagram every now and then and use it
for explanation or self clarification - and include - and use - them in
the documentation when the subsystem is reasonably stable.
Btw, I do think proper documentation (aside from self-documenting clear
code, which to me must be a given) is possible, even in the face of
evolutionary forces on the system; that's because other engineering
disciplines manage to do that, so I don't see why we shouldn't.
| |
| clifford shelley 2004-08-17, 8:56 am |
| deshmua@ececs.uc.edu (Amol) wrote in message news:<51d763aa.0408151619.6f5994c2@posting.google.com>...
> While automatic code-generation has been a long time ideal of OO
> purists there have been several concerns/impediments to its use in the
> software development process. Ideally we should be able to describe
> all our objects/interfaces via the UML class diagrams and forward
> engineer to get the source code to the level of "class skeletons" so
> that to get to final deliverable code, we need to fill in only the
> "method-stuffings".
<snip>
Automatic code generation was achieved some time ago - pre OO. The
method used was JSP - Jackson Structured Programming and the tool was
called PDF - Programme Development Facility written by the UKAEA. We
used PDF on itself to generate the next version.
Users generated Jackson diagrams and 'pushed a button' to generate
code - Ada, Fortram, C, Coral or whatever you wanted.
It worked because JSP was a very well defined, almost prescriptive,
method and the diagrams were formally constrained. If a well defined
and tightly contrained subset of UML were to be used I would see no
real problems with automatic code generation.
In passing - PDF made refactoring a natural process, although this was
well before the term was invented. Also the code was bug free and very
easy to maintain.
| |
| David Lightstone 2004-08-17, 8:56 am |
|
"Alan Gauld" <alan.gauld@btinternet.com> wrote in message
news:fec3i0p6rhnjmh76bb6r82v58vt94nkmg1@
4ax.com...
>
> Because not all companies work like you? :-)
>
> Many companies work over distributed locations, often in
> different countries. Whiteboards don't work so well when the team
> in Bombay have to see the whiteboard in London and discuss it
> with the team in Toronto. And as for shipping paper around!!
>
> Of course Visio diagrams on a shared server might address much of
> that, but the other feature that the Case tool gives is
> consistency checking across large numbers of diagrams. If there
> are 30 or more class diagrams in the project with maybe 200-500
> classes its important to update every diagram where a class
> appears. The tools do that, and publish the change to all sites
> in real time, which is a huge time saver.
Using Visio has significant problems even when used strictly as a drawing
tool
Try drawing several state diagrams, placing composite states on each (put
something on each of the child diagrams that correspond to the composite
states)
Now try moving one of those composite states to a new state diagram diagram.
Make certain
you still have the child diagram
As for why would you want to do something so silly. The initial task was to
model a subsystem.
The move is necessitated by integrating it with the work of others
>
> If your project consists of a small team in a single location
> CASE tools don't offer massive benefits unless they do code
> generation (and more than just headers!). But in a big team
> distributed over the globe, often speaking different first
> languages and the cmmunications advantages of a CASE tool are
> significant.
>
> Alan G.
>
> Author of the Learn to Program website
> http://www.freenetpages.co.uk/hp/alan.gauld
| |
|
| shelley@osel.netkonect.co.uk (clifford shelley) wrote in message news:<b96ee64c.0408170258.5f24e97a@posting.google.com>...
> deshmua@ececs.uc.edu (Amol) wrote in message news:<51d763aa.0408151619.6f5994c2@posting.google.com>...
>
> <snip>
>
> Automatic code generation was achieved some time ago - pre OO. The
> method used was JSP - Jackson Structured Programming and the tool was
> called PDF - Programme Development Facility written by the UKAEA. We
> used PDF on itself to generate the next version.
>
> Users generated Jackson diagrams and 'pushed a button' to generate
> code - Ada, Fortram, C, Coral or whatever you wanted.
>
> It worked because JSP was a very well defined, almost prescriptive,
> method and the diagrams were formally constrained. If a well defined
> and tightly contrained subset of UML were to be used I would see no
> real problems with automatic code generation.
>
> In passing - PDF made refactoring a natural process, although this was
> well before the term was invented. Also the code was bug free and very
> easy to maintain.
Thanksfor that interesting bit of information. I will admit my
ignorance of Jackson Structured Programming (among a host of other
things :) I'm going to definitely look it up.
In the context of non-UML/OO systems I might add:
....that one (non-UML/OO) area where i find forward generation of code
useful is in database design. I have yet to find a scenario so
complicated that i could not entirely design and forward generate the
code for database creation. I almost always use a tool to generate my
database schemas. However it may be observed that database creation is
in fact a 'static' model and hence the ease in forward engineering of
the database creation script should be no surprise. SQL or stored-proc
code generation is still not possible automatically (atleast i am not
aware of anyway).
| |
|
| Alan Gauld <alan.gauld@btinternet.com> wrote in message news:<fec3i0p6rhnjmh76bb6r82v58vt94nkmg1@4ax.com>...
>
> Because not all companies work like you? :-)
>
Accepted. That is why it is no wonder that
rose/together/<your-fav-uml-case-tool> are doing good business :). I'm
just trying to understand given the argument, why this is the case
(pun unintended)
> Many companies work over distributed locations, often in
> different countries. Whiteboards don't work so well when the team
> in Bombay have to see the whiteboard in London and discuss it
> with the team in Toronto. And as for shipping paper around!!
>
ok. point accepted... partly :) In all my experience working with
onsite-offshore software development, the design of the system was
entirely assigned to either the offshore team (most cases) or the
onsite team (sometimes). The major onsite-offshore communication was
in the form of use cases and/or requirement specs.
There was exchange of rose diagrams between the onsite-offshore teams,
but frankly, reflecting on the situation, i saw no advantage to
communicating the design between onsite and offshore teams. Use case
and requiements communication on the other hand was crucial.
And I can see no reason why design would need to be done
simultaneously by teams in distributed location except in certain
special scenarios (wouldn't that be counter productive?)
But probably you are talking of a more general scenario where software
development is done on the same application in multiple locations and
not just an onsite-offshore model. It seems likely then that you would
need to have the capabilities of a diagramming tool.
> Of course Visio diagrams on a shared server might address much of
> that, but the other feature that the Case tool gives is
> consistency checking across large numbers of diagrams. If there
> are 30 or more class diagrams in the project with maybe 200-500
> classes its important to update every diagram where a class
> appears. The tools do that, and publish the change to all sites
> in real time, which is a huge time saver.
>
so again the question arises: if your diagram is indeed very complex
how do you make sense of it. Yes, your diagram is updated and kept in
sync with the code by your fav CASE tool, but how does that matter? Do
you look at the diagram for defects or at your unit test reports? How
does looking at an evolving diagram (due to evolving code) help?
> If your project consists of a small team in a single location
> CASE tools don't offer massive benefits unless they do code
> generation (and more than just headers!). But in a big team
> distributed over the globe, often speaking different first
> languages and the cmmunications advantages of a CASE tool are
> significant.
>
point accepted...
Though I must say, having large teams distributed over the globe
doesnt imply that the _same_ design must be worked on simultaneously.
In almost all scenarios i can think of (and I may be limited in my
imagingation/experience), you would have high level boundaries
predefined between the different design teams which should *rarely*
change, which reduces (not eliminates) the need for exchanging design
diagrams. Again, a tool with basic capabilities to generate class
diagram seems necessary & sufficient.
> Alan G.
>
> Author of the Learn to Program website
> http://www.freenetpages.co.uk/hp/alan.gauld
| |
|
| "David Lightstone" <david._NoSpamlightstone@prodigy.net> wrote in message news:<CJlUc.1776$Dj2.495@newssvr32.news.prodigy.com>...
> "Alan Gauld" <alan.gauld@btinternet.com> wrote in message
> news:fec3i0p6rhnjmh76bb6r82v58vt94nkmg1@
4ax.com...
>
> Using Visio has significant problems even when used strictly as a drawing
> tool
>
> Try drawing several state diagrams, placing composite states on each (put
> something on each of the child diagrams that correspond to the composite
> states)
>
> Now try moving one of those composite states to a new state diagram diagram.
> Make certain
> you still have the child diagram
>
> As for why would you want to do something so silly. The initial task was to
> model a subsystem.
> The move is necessitated by integrating it with the work of others
>
I would draw a new diagram on a new sheet of paper refering to the
original sheet, then throw away the original sheet if it is no longer
required.
Reasonable assumptions:
1. Project is managed at a single location
2. State diagram is not too big/complex, else the duplication of
effort would be significant. Again, except for special cases having a
single monolithic overly complex diagram may defeat the purpose.
For scenarios not covered by the assumptions, I would consider it
necessary to have a CASE tool with advanced capabilities. One of the
point I'm trying to make is that advanced capabilities are usually
necessary only in special cases as against the general propaganda that
most OO software development should follow UML based methodology (and
not just for 'big', 'complex', 'multi-location' projects where the
'design stage is conducted in a distributed fashion').
[color=darkred]
>
>
| |
|
| Amol wrote:
> Alan Gauld wrote:
[color=darkred]
capability[color=darkred]
>
> Accepted. That is why it is no wonder that
> rose/together/<your-fav-uml-case-tool> are doing good business :). I'm
> just trying to understand given the argument, why this is the case
> (pun unintended)
>
>
>
> ok. point accepted... partly :) In all my experience working with
> onsite-offshore software development, the design of the system was
> entirely assigned to either the offshore team (most cases) or the
> onsite team (sometimes). The major onsite-offshore communication was
> in the form of use cases and/or requirement specs.
Some folks don't know what they have until they miss it. The most important
detail to unify a distributed is a daily build server at each site, with
automatically synchronized code. There are those who consider this so
obvious they don't realize they need to instruct those who don't do it.
The next step is a unified test server, with a remote interface, like
http://fitnesse.org . Folks implementing such a system often finds it
provides the primary benefits (high velocity and low bug rates) which are
the expected side-benefits of relentlessly drawing diagrams.
> There was exchange of rose diagrams between the onsite-offshore teams,
> but frankly, reflecting on the situation, i saw no advantage to
> communicating the design between onsite and offshore teams. Use case
> and requiements communication on the other hand was crucial.
Right. So automate requirements, in a literate format.
> Though I must say, having large teams distributed over the globe
> doesnt imply that the _same_ design must be worked on simultaneously.
> In almost all scenarios i can think of (and I may be limited in my
> imagingation/experience), you would have high level boundaries
> predefined between the different design teams which should *rarely*
> change, which reduces (not eliminates) the need for exchanging design
> diagrams. Again, a tool with basic capabilities to generate class
> diagram seems necessary & sufficient.
In some shops, one team draws the diagrams, and another team implements
them. Guess which team typically works long hours.
--
Phlip
http://industrialxp.org/community/b...tUserInterfaces
| |
| Alan Gauld 2004-08-18, 3:58 pm |
| On 18 Aug 2004 08:13:15 -0700, deshmua@ececs.uc.edu (Amol) wrote:
[color=darkred]
> Thanksfor that interesting bit of information. I will admit my
> ignorance of Jackson Structured Programming (among a host of other
> things :) I'm going to definitely look it up.
You might consider looking at SDL too.
SDL has been the main switch design tool in the telecomms
industry (and in many industrial automation contexts too - think
railway or factory control) and almost all the SDL CASE tools
generate code and many have a preliminary simulation mode that
allows you to test the model prior to generating the code.
SDL tools have been doing this since the late 80's at least.
Alan G.
Author of the Learn to Program website
http://www.freenetpages.co.uk/hp/alan.gauld
| |
| Alan Gauld 2004-08-18, 3:58 pm |
| On 18 Aug 2004 09:15:44 -0700, deshmua@ececs.uc.edu (Amol) wrote:
>
> ok. point accepted... partly :) In all my experience working with
> onsite-offshore software development,
Bombay was probably misleading, I'm not talking about offshoring
I'm talking about a large contract being sub-let out to different
companies each responsible for a part but the parts being
integrated to form the whole. THe parts may be discrete systems
with clean intrerfaces(not too hard) or they may be libraries
within a large system where the classes and objects within the
libraries are shared. THe latter cae is the one where CASE tools
help most.
> But probably you are talking of a more general scenario where software
> development is done on the same application in multiple locations and
> not just an onsite-offshore model. It seems likely then that you would
> need to have the capabilities of a diagramming tool.
Absolutely so.
> so again the question arises: if your diagram is indeed very complex
> how do you make sense of it. Yes, your diagram is updated and kept in
> sync with the code by your fav CASE tool, but how does that matter? Do
> you look at the diagram for defects or at your unit test reports? How
> does looking at an evolving diagram (due to evolving code) help?
I look at the diagram to locate the defects. Or at least to find
out which source file I need to open to find the defect. If my
design doesn't navigate me to the correct file without having to
open a debugger or editor then my design is inadequate.
Finding bugs at the design level is an order of magnitude faster
than reading source code - even ewith class browsers etc.
> Though I must say, having large teams distributed over the globe
> doesnt imply that the _same_ design must be worked on simultaneously.
No but where some of the teams are building libraries which are
shared by the other teams there needs to be some sharing of
design models. Class definitions and sequence diagrams will be
examples. Also which component houses which class can change
depending on coupling and cohesion debates and teams need to see
when a class moves from one component to another.
> In almost all scenarios i can think of (and I may be limited in my
> imagingation/experience), you would have high level boundaries
> predefined between the different design teams which should *rarely*
> change,
Agreed, unfortunately rarely doesnot mean never!
And rarely on a large project can still mean one major change
every two or three days...
> diagrams. Again, a tool with basic capabilities to generate class
> diagram seems necessary & sufficient.
Actually the ones that change most often in this context are the
sequence diagrams because they show the external view of the
classes - how the clients will use the class rather than how the
implementer builds it internally. Also deployment and component
diagrams are likely to change quite often at some stages of the
project as classes/libraries get refactored and as subsystems
realise they need to use a library that they didn't before...
IME at least.
Alan G.
Author of the Learn to Program website
http://www.freenetpages.co.uk/hp/alan.gauld
| |
|
| Alan Gauld <alan.gauld@btinternet.com> wrote in message news:<9847i0dfmee71tqmmfjj3o0vqhc4b599ii@4ax.com>...
> Actually the ones that change most often in this context are the
> sequence diagrams because they show the external view of the
> classes - how the clients will use the class rather than how the
> implementer builds it internally. Also deployment and component
> diagrams are likely to change quite often at some stages of the
> project as classes/libraries get refactored and as subsystems
> realise they need to use a library that they didn't before...
"...how the clients will use the class rather than how the implementer
builds it internally."
Alan, I have no first hand experience of developing in geographically
distributed teams, therefore I must ask you this: What are your
opinions on using sample client code as a part of (formal)
documentation rather than sequence diagrams.
Ofcourse this is not a new idea and several open source projects
almost always provide documentationn in the form of sample code and
javadocs for understanding the API/library very helpful (those that
become extremely popular have books written about them, but thats
another story :) ).
One reason I can think of why open source projects use this form of
documentation is because they would need to have a client code to test
out the library anyway, so having this form of documentation doesnt
involve any significant additional effort.
Personally, I'm so used to using this form of documentation that IMO,
these seem to be more directly useful than any diagram. Whats better
than a diagram is a client code that _works_. Clearly I can see a
matter of personal preference here, although I feel that a programmer
is more likely to favor "documenting code" rather than "sequence
diagrams".
Sequence diagrams themselves can be quite a pain when you have to
consider the different exceptional flows. Code on the other hand is a
succinct form of documentation and one which can be direcly used.
Interestingly, open source projects are a case of distributed software
development taken to the extreme. Apparently a very small percentage
of them actually use UML/CASE tools (atleast I dont find the UML
diagrams under "docs" for most projects in sourceforge). My own
experience in contributing to open source s/w is limited so it would
be great if we could have someone with a good deal of experience with
open source software development comment on this.
>
> IME at least.
>
> Alan G.
>
>
> Author of the Learn to Program website
> http://www.freenetpages.co.uk/hp/alan.gauld
| |
|
| Alan Gauld <alan.gauld@btinternet.com> wrote in message news:<9847i0dfmee71tqmmfjj3o0vqhc4b599ii@4ax.com>...
> Actually the ones that change most often in this context are the
> sequence diagrams because they show the external view of the
> classes - how the clients will use the class rather than how the
> implementer builds it internally. Also deployment and component
> diagrams are likely to change quite often at some stages of the
> project as classes/libraries get refactored and as subsystems
> realise they need to use a library that they didn't before...
"...how the clients will use the class rather than how the implementer
builds it internally."
Alan, I have no first hand experience of developing in geographically
distributed teams, therefore I must ask you this: What are your
opinions on using sample client code as a part of (formal)
documentation rather than sequence diagrams.
Ofcourse this is not a new idea and several open source projects
almost always provide documentationn in the form of sample code and
javadocs for understanding the API/library very helpful (those that
become extremely popular have books written about them, but thats
another story :) ).
One reason I can think of why open source projects use this form of
documentation is because they would need to have a client code to test
out the library anyway, so having this form of documentation doesnt
involve any significant additional effort.
Personally, I'm so used to using this form of documentation that IMO,
these seem to be more directly useful than any diagram. Whats better
than a diagram is a client code that _works_. Clearly I can see a
matter of personal preference here, although I feel that a programmer
is more likely to favor "documenting code" rather than "sequence
diagrams".
Sequence diagrams themselves can be quite a pain when you have to
consider the different exceptional flows. Code on the other hand is a
succinct form of documentation and one which can be direcly used.
Interestingly, open source projects are a case of distributed software
development taken to the extreme. Apparently a very small percentage
of them actually use UML/CASE tools (atleast I dont find the UML
diagrams under "docs" for most projects in sourceforge). My own
experience in contributing to open source s/w is limited so it would
be great if we could have someone with a good deal of experience with
open source software development comment on this.
>
> IME at least.
>
> Alan G.
>
>
> Author of the Learn to Program website
> http://www.freenetpages.co.uk/hp/alan.gauld
| |
| Alan Gauld 2004-08-19, 9:00 am |
| On 18 Aug 2004 19:50:24 -0700, deshmua@ececs.uc.edu (Amol) wrote:
> Alan Gauld <alan.gauld@btinternet.com> wrote in message news:<9847i0dfmee71tqmmfjj3o0vqhc4b599ii@4ax.com>...
>
> Alan, I have no first hand experience of developing in geographically
> distributed teams, therefore I must ask you this: What are your
> opinions on using sample client code as a part of (formal)
> documentation rather than sequence diagrams.
Too much work. Once an initial sequence diagram has been built
(in a model) it is very reasy to modify the sequence, just add
new lines or move them up or down by dragging the line.
Sample code has to be edited by hand, and even cut n paste is
harder than moving a single line.
Also the complexity of text over an arrow is significantly
higher. Consider a complex set of say, 30 interactions over 10 or
more objects, you have all the method arguments, the assignments,
even the names to read. With a sequence diagram it is much easier
on the brain to scan the big picture and focus in on the details
you need. This is particularly important where the team do not
all speak the same language, since code inevitably reflects the
authors language, lines on a diagram are much more universal.
Even though you need to read the detail eventually, scimming the
big picture is much easier without reading words.
> javadocs for understanding the API/library very helpful (those that
> become extremely popular have books written about them, but thats
> another story :) ).
Actually the best notation for documenting libraries is IMHO
Jackson diagrams. (Or Entity Life Histories in SSADM terms)
They can show very succinctly the different ways that an API can
be used, including the needed sequences etc.
> One reason I can think of why open source projects use this form of
> documentation is because they would need to have a client code to test
> out the library anyway, so having this form of documentation doesnt
> involve any significant additional effort.
Apart from on the part of the reader! :-)
> matter of personal preference here, although I feel that a programmer
> is more likely to favor "documenting code" rather than "sequence
> diagrams".
Programmers love text - even when its not efficient! :-)
But its not only programmers who must read the diagrams. There
are network designers, deployment designers, testers (who may not
be software engineers if its a mixed hardware/software project)
And what if the project is in multiple programming languages (as
is usually the case) and the VB using GUI team don't understand
the server teams Java style samples say...
> Sequence diagrams themselves can be quite a pain when you have to
> consider the different exceptional flows. Code on the other hand is a
> succinct form of documentation and one which can be direcly used.
Sequence diagrams are more space consuming that code, but if the
project has many objects, and the minimal sequences are long,
there is not much difference. And sample code can become very
hard to read if it covers all the possible scenarios too - a
welter of if/else statements.
> Interestingly, open source projects are a case of distributed software
> development taken to the extreme. Apparently a very small percentage
> of them actually use UML/CASE tools
Yes, but they tend to be on the small side, even something like
the Gimp (which is relatively tightly controlled) is tiny in
comparison to large scale DoD type projects. There are very few
open source projects that venture beyond the million lines of
code size. The projects I'm talking about start at that level and
go up to around the 100 million LoC size (certainly the biggest
I've worked on is around 60 million).
Alan G.
Author of the Learn to Program website
http://www.freenetpages.co.uk/hp/alan.gauld
| |
| clifford shelley 2004-08-19, 9:00 am |
| deshmua@ececs.uc.edu (Amol) wrote in message
>
<snip>
> Thanksfor that interesting bit of information. I will admit my
> ignorance of Jackson Structured Programming (among a host of other
> things :) I'm going to definitely look it up.
Probably only of historic interest now - seems to have been forgotten
(or is anyone still using it?) - most people assume JSP is Java Server
Pages
>
> In the context of non-UML/OO systems I might add:
> ...that one (non-UML/OO) area where i find forward generation of code
> useful is in database design. I have yet to find a scenario so
> complicated that i could not entirely design and forward generate the
> code for database creation. I almost always use a tool to generate my
> database schemas. However it may be observed that database creation is
> in fact a 'static' model and hence the ease in forward engineering of
> the database creation script should be no surprise. SQL or stored-proc
> code generation is still not possible automatically (atleast i am not
> aware of anyway).
Curious; JSP was driven by an analysis of the data structures that
programmes would work on - i/p & o/p. In IT (or DP as was) this was
comparatively straightforward. For RT and embedded systems the same
data oriented approached was required and also imposed, as a
necessity, a 'defensive programming' style to cope with whatever was
thrown at the system down the data streams.
| |
| Russell Wallace 2004-08-24, 11:05 pm |
| On Thu, 19 Aug 2004 07:51:52 GMT, Alan Gauld
<alan.gauld@btinternet.com> wrote:
>Yes, but they tend to be on the small side, even something like
>the Gimp (which is relatively tightly controlled) is tiny in
>comparison to large scale DoD type projects. There are very few
>open source projects that venture beyond the million lines of
>code size. The projects I'm talking about start at that level and
>go up to around the 100 million LoC size (certainly the biggest
>I've worked on is around 60 million).
To quote the late Douglas Adams: "That's a lot. A lot a lot."
If it's a DoD project you probably can't go into much detail, but can
you tell us what the 60 MLOC program was for, and give any idea of why
it needed to be 60 MLOC? I honestly can't imagine what you could
possibly use that much code for. (Which doesn't mean it wasn't needed
- you've worked on those projects and I haven't, so I'll take your
word for it if you say it was - I'd just love to know why.)
--
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
| |
| Phlip 2004-08-24, 11:05 pm |
| Russell Wallace wrote:
> If it's a DoD project you probably can't go into much detail, but can
> you tell us what the 60 MLOC program was for, and give any idea of why
> it needed to be 60 MLOC? I honestly can't imagine what you could
> possibly use that much code for. (Which doesn't mean it wasn't needed
> - you've worked on those projects and I haven't, so I'll take your
> word for it if you say it was - I'd just love to know why.)
Did it obey DOD-STD-2167A?
(That's the military's official version of Waterfall...)
--
Phlip
http://industrialxp.org/community/b...tUserInterfaces
| |
|
| Alan Gauld <alan.gauld@btinternet.com> wrote in message news:<6pl8i0dcn1hinvaoo1i5bat8sk8ngiqkap@4ax.com>...
>
> Yes, but they tend to be on the small side, even something like
> the Gimp (which is relatively tightly controlled) is tiny in
> comparison to large scale DoD type projects. There are very few
> open source projects that venture beyond the million lines of
> code size. The projects I'm talking about start at that level and
> go up to around the 100 million LoC size (certainly the biggest
> I've worked on is around 60 million).
>
Almost a w later, Amol writes:
Alan, you are probably right in the matter concerning really huge
software. Just one quick question that comes to my mind about the kind
of project that you are talking about : "Are you saying that these
projects eventually resulted in 100million LoC or did the
developers/managers have an idea that the project would be that large
at the outset" (I'm not trying to make a point here, just trying to
understand some things. AFAI can think, projects this large could be
either the result of integration of several projects that each began
small; or project which had high level boundaries decided upfront so
that each module could be individually completed as a separate project
with minimal dependencies across modules - again, I am limited by my
imagination here)
Also, what do you think about employing UML for small projects
(assuming that your point of applicability of UML for very large
projects is accepted)?
While I have your attention, may I also ask what are your
experiences/views on use of UML tools for forward engineering?
I personally dont feel that UML 'doesnt have a place' in software
developemtn - agile or not agile. I myself rely a lot initially on
drawing (and redrawing) UMLish diagrams on whiteboard. What I am
trying to understand is the justification for universal adoption of
complex UML tools as a standard software development practice - for
special scenarios of large scale projects the tools may be useful as
you suggest (although I think having diagrams to a very detailed level
would be just as futile even for large projects).
One area where I imagine the tools may be helpful is in their use for
reverse engineering in the case of wanting to maintain an existing
project which was developed by a different team and you want to have a
high level grasp of various modules involved in the project. Ofcourse
if the existing code is poorly developed/designed you wouldnt gain
much from the UML diagram (other than knowing that the code is poorly
developed/designed :)
|
|
|
|
|