[q] uml?

[patch]

hi all,

I've done it again; on my quest for knowledge/direction I stumbled upon a
new exciting ancronym.. UML..
beginning to grasp the meaning/purpouse of this concept and am, again,
wondering.. Since i'm just starting/probing the "real"programmers fields
should I concern myself with UML? should I just keep it in mind but first
get my head round a C or a J language?
I understand the need of a good meta-model for designing
programs/applications, god knows the amount of time I lost having to start
all over in a php/javascript/mysql project (less and less though) but these
are relatively small scaled projects so not a real bummer.. But I can
imagine when I want to do something larger in C#.net i might need a
different approach...

and if I do manage to train myself in it/find some classes, is it something
which'll give me a significant advance over someone who hasn't in a
job-interview? i guess it does..

do you, as day-to-day programmers have anything to do with it? is it a
must-have?

suggestions? advice?

patch

[Michael Gautier]

>Since i'm just starting/probing the "real"programmers fields
>should I concern myself with UML?

UML basically allow you to document and represent your code in an industry
standard, pictorial format that is independent of technology. It is heavily
influenced towards objects. Where flowcharts serve a good purpose for procedural
programs, UML diagrams serve a good function for object oriented stuff. UML
is also used to illustrate the processes, program flow and interactions between
components.

should I just keep it in mind but first
>get my head round a C or a J language?

It depends on where you are at. Essentially, some programmers are very solution
oriented where they want to get right to the code, solve the problem. Others
steers towards a more organized approach where they analyze, design and get
as much of the requirements as they can before they code. For this latter
group, UML tends to be a very valuable tool. Sometimes it is easier to design
by coding especially if you are new to the technology or you have a harder
time working in the abstract.

The answer for you may be in whether you could learn to model and later writer
better code from the model or learn to code and then later/better understand
what the terms and parts of the modeling language as it ultimately applies
to the subsequent code.

For the beginner, a model can be like a step by step instruction book in
putting together your first programs or not know how to code can hinder/distract
you when modeling.

>I understand the need of a good meta-model for designing
>programs/applications, god knows the amount of time I lost having to start
>all over in a php/javascript/mysql project (less and less though) but these
>are relatively small scaled projects so not a real bummer.. But I can
>imagine when I want to do something larger in C#.net i might need a
>different approach...
>
>and if I do manage to train myself in it/find some classes, is it something
>which'll give me a significant advance over someone who hasn't in a
>job-interview? i guess it does..
>

Unless you are applying for either a senior developer or some type of analysis,
architecture or engineering position, then I don't see how your knowledge
of UML will give you an edge over another applicant. Either the interviewer
just wants a coder (with no ambition) or they want a coder that can progress/evolve
into a senior level position.

>do you, as day-to-day programmers have anything to do with it? is it a
>must-have?
>

Since I am primarily a new systems builder, I work with it all the time,
but it is usually a benefit for me and other programmers during/before implementation
and programmers that will pickup the system later. Managers, especially non
technical ones, could care less about a UML model and I have found some programmers
don't have the patience/stamina for models. To be fair, UML can be a foreign
language unless you read up on it. Flowcharts can be learned in a relatively
short time (10 or so symbol of which about 5 are typically used?).

Currently, I see UML as a personally acquired/used skill that isn't demanded
heavily by the industry. Perhaps that is symptomatic of the degree of emphasis
on quality, defects, documentation and long term maintainability.

>suggestions? advice?

I would suggest you learn it after you pick up the tangible technical skills
first since you can get a quicker return on your time. Later on you can move
to UML, Design Patterns, Refactoring and all the methodologies, techniques
and computer science/engineering approaches.

>
>patch
>
>

[Elena]

UML has been around for at least 8 years. I started reading about it quite
a while ago and then dropped it because I never came across it in the real
world. However I believe Michael's comments are right-on - - and if you happen
to find yourself in a large, structured organization, you might indeed use
UML.

My perception of UML is that it is intended to be a technical communication
tool much as Michael has stated. Business users would be oblivious to it.
Given the long list of technologies/methodologies/tools that we're all trying
to master, I would put UML at a low priority. I'm not saying it's not an
excellent tool, I'm just saying the practical payback on time invested is
probably not all that high.

[Mark]

"Business users would be oblivious to it"

No way! UML starts with defining Use Cases, these are business oriented
narratives where the user describes HOW they want to be able to work with
the automated system. The nouns in those descriptions become candidate "classes."
A class is another word for blueprint. Classes blueprint the objects your
application will create and use when executing.
UML STARTS with end-user involvement. They verify your early work to ensure
you understand what they are looking for. Sounds sort of important to me


Philosophically, I disagree with Mike and Elena. If you start off learning
the UML, you will be able to "see" how code is working and how pieces fit
together. You will be able to design far better applications regardless
of whether it's a small desktop app or a subsystem in a large enterprise
application. It will also give you insight into terms like "Event Listeners",
Inheritance, Abstraction. I believe knowledge of UML will make any developer
a far better developer.

I personally feel industry has the "let's do IT" paradigm totally "bass ackward".
Learn some UML concepts, then apply those principles in the code, then
learn some more, then take it a bit further with patterns.

UML is a VERY worthwhile pursuit. May I recommend a very simple, straight
forward instruction guide that isn't littered with gooble-d-gook you find
in the books published by OMG (owners of UML trademark). Sams Teach Yourself
UML in 24 Hours is an excellent self-study.

Mark

(still think the US should just annex Canada)

PS A useful way to learn. Get the book I mentioned. Get a J2E book, and
then as you read about UML look for the way the concepts are implemented
in Java. Really useful approach.


"Elena" <egermano@comcast.net> wrote:
>
>UML has been around for at least 8 years. I started reading about it quite
>a while ago and then dropped it because I never came across it in the real
>world. However I believe Michael's comments are right-on - - and if you
happen
>to find yourself in a large, structured organization, you might indeed use
>UML.
>
>My perception of UML is that it is intended to be a technical communication
>tool much as Michael has stated. Business users would be oblivious to it.
> Given the long list of technologies/methodologies/tools that we're all
trying
>to master, I would put UML at a low priority. I'm not saying it's not an
>excellent tool, I'm just saying the practical payback on time invested is
>probably not all that high.
>

[Michael Gautier]

Many would agree that use cases are more important, but there are several
questions:

How much of the time devoted to UML include training the customer, client
or management on what various symbols, terms and conventions? When you say
class, your boss says module? You speak of implementation, your boss thinks
deployment.

I am a UML proponent, but depending on where I work, no one may want it,
understand it and they may refer to things like, "Fluff work". Again, UML
is great on a personal level, but its impact and value is yet to be appreciated
by those that employ you.

People are different and operate differently. Not everyone has the discipline,
desire and foresight to utilize methodologies and processes outside of the
"do it now, do it in code" school. They can still be effective, learn and
produce. Although I will admit that many of them that I've witnessed may
progress more gradually or not make the transition from Procedural paradigms
to object/component oriented ones at all.

Also, technology is becoming increasingly complex with the shift from strict,
binary object systems to text based messaging systems built on xml technologies.
Because this new world is less static, you will need models. But, as we know,
managers do not have the strategic vision and only care about today.

In any event, the trends may be promising:

http://www.sdtimes.com/news/058/story3.htm

http://www.fawcette.com/xmlmag/2002_...default_pf.asp

[Elena]

"Mark" <mark@nospam.com> wrote:
>
>"Business users would be oblivious to it"
>
>No way! UML starts with defining Use Cases, these are business oriented
>narratives where the user describes HOW they want to be able to work with
>the automated system.

I can't get my users to read a two-page word document that explains the business
objectives of a new application - - there's no freaking way they're going
to work thru a lot of clever charts and graphs and special symbols. If you're
working in a very large company with strong support for methodology then
there's the possibility the users will look at this stuff. Otherwise, it's
all internal to IT.

Again, I'm not suggesting UML is not a useful technology, but the original
question was whether or not adding UML to one's resume would be a big asset
in the competition for jobs and I'm saying I've yet to work anywhere that
used it.

[MarkN]

I'm with Elena on this one. UML is a useful skill to have but finding companies
that actually use it or even know what it is, well, most want to know if
you are done coding yet - they told you what they want to do. I've worked
for large organizations with people who have been in the industry for years.
They had no clue what an ERD was.

UML is most useful with a tool that allows you to reverse engineer the code.
That way one can design and baseline, code and then bring it back into design
to see if it matches the design and is good. Few times does the design actually
pan out in reality. OO really is not that easy. Unfortunately these tools
(ie XDE) are usually expensive. So many are left with trying to keep the
design matching the code, doing nothing, or doing a little/lot of design
and the going for it.


"Elena" <egermano@comcast.net> wrote:
>
>"Mark" <mark@nospam.com> wrote:
>>
>>"Business users would be oblivious to it"
>>
>>No way! UML starts with defining Use Cases, these are business oriented
>>narratives where the user describes HOW they want to be able to work with
>>the automated system.
>
>I can't get my users to read a two-page word document that explains the
business
>objectives of a new application - - there's no freaking way they're going
>to work thru a lot of clever charts and graphs and special symbols. If
you're
>working in a very large company with strong support for methodology then
>there's the possibility the users will look at this stuff. Otherwise, it's
>all internal to IT.
>
>Again, I'm not suggesting UML is not a useful technology, but the original
>question was whether or not adding UML to one's resume would be a big asset
>in the competition for jobs and I'm saying I've yet to work anywhere that
>used it.
>
>

[Mark]

Let's step back and think about this. The original question was whether UML
looks good on a resume. Perhaps it's not a big attention getter. BUT, if
you are a new developer and have studied UML in conjunction with a coding
language such as Java, you WILL have better insights into what is going on
from the OO perspective. A picture is worth 1,000 words? So, when our dear,
young, hopeful candidate lands an interview, he/she will be much more conversant
all the way round, including coding questions. Still think it's a very useful
skill.

Getting users to look at funky diagrams? I agree, absolutely not! Getting
users to help write a Use Case? Educate them briefly on the technique and
purpose and it will be impossible to get them to shut up! I speak from experience.
A very useful requirements gather technique. Plus, if you document real-world
business scenarios with your use cases, you are well on the way to having
a user acceptance test plan based on their own requirements. I use this
technique and it works!




"MarkN" <m@n.com> wrote:
>
>I'm with Elena on this one. UML is a useful skill to have but finding companies
>that actually use it or even know what it is, well, most want to know if
>you are done coding yet - they told you what they want to do. I've worked
>for large organizations with people who have been in the industry for years.
> They had no clue what an ERD was.
>
>UML is most useful with a tool that allows you to reverse engineer the code.
> That way one can design and baseline, code and then bring it back into
design
>to see if it matches the design and is good. Few times does the design
actually
>pan out in reality. OO really is not that easy. Unfortunately these
tools
>(ie XDE) are usually expensive. So many are left with trying to keep the
>design matching the code, doing nothing, or doing a little/lot of design
>and the going for it.
>
>
>"Elena" <egermano@comcast.net> wrote:
>>
>>"Mark" <mark@nospam.com> wrote:
>>>
>>>"Business users would be oblivious to it"
>>>
>>>No way! UML starts with defining Use Cases, these are business oriented
>>>narratives where the user describes HOW they want to be able to work with
>>>the automated system.
>>
>>I can't get my users to read a two-page word document that explains the
>business
>>objectives of a new application - - there's no freaking way they're going
>>to work thru a lot of clever charts and graphs and special symbols. If
>you're
>>working in a very large company with strong support for methodology then
>>there's the possibility the users will look at this stuff. Otherwise,
it's
>>all internal to IT.
>>
>>Again, I'm not suggesting UML is not a useful technology, but the original
>>question was whether or not adding UML to one's resume would be a big asset
>>in the competition for jobs and I'm saying I've yet to work anywhere that
>>used it.
>>
>>
>

[patch]

so, what it adds up to is;

trying to learn UML as a "standalone" goal will not get me anywhere soon.
But as something to pick up on while I'm learning either Java or a
C-language might be a good idea and if it "fits" me and I get my head round
it, it will benefit my programming(design) as well as my abstract
thinking-level towards programming.

Having UML on my resume on itself is like with what I stated before: next to
useless, but again it might help in indirect ways like in conversation end
maybe a better understanding of what clients want from me (clients in the
widest sense here)..

Having read the uml-article from Michael (btw: why are YOU allways the one
with links? whats the deal with that?) I also think its smart that IF i
choose to do (some) uml and put it on my resume i'd better also put which
diagrams I know/ am comfortable with..

I think for me it's indeed a good idea to Marks approach to pick up on it
while learning another OO-language.. This because my background is far from
being a programmer but I AM quite capable at abstract thinking.. (thats
exactly where the designer and nerd in me overlap I think).. Thanx again for
helping me out G&G's..

Patch

ps: Mark, you suggest J2E, this could also be another OO-language? (I'm
seriously considering one of the C's), the Sams book is a good tip: it'll be
my fourth and I'm quite comfortable with them... (and I think Holland should
annex you both, at least we should have never traded you New-York w/
Surinam.. what on earth were they thinking)

Mark wrote in message <3d46b8af$1@10.1.10.29>...
>
[...snip..]

[MarkN]

>I AM quite capable at abstract thinking

Good. Because those without that skill will be only be coders in the OO world.
They can code with an OO langauge but [usually] not in an OO way. Not very
many can do this. That is why VB6 and COBOL and RPG and ... will be around
for quite a while and Java and C# and ... won't be used to their full potential
most of the time. The thing I have come to find out about the OO world is
that one must additionally think abstactly about abstract things. Customers
and addresses and invoices are easy. But [somewhat]intangible and conceptual
things are difficult. Especially when they really aren't what they were
described to you by the users.

[patch]

MarkN wrote in message <3d47ceef@10.1.10.29>...
>
>>I AM quite capable at abstract thinking
>
>Good. Because those without that skill will be only be coders in the OO
world.
[...]
>that one must additionally think abstactly about abstract things.
[...]
>But [somewhat]intangible and conceptual things are difficult.

.. my terrain totally.. thinking abstract about abstract things.. whish I
could turn that off once in awhile but it seems to be part of who I am.. (in
another life I might have been a philosopher or taoistic monk..[grin])

patch

[mark]

LOL! You Dutch and your silly tulip currency - that really took you a long
way didn't it? (Ha ha)

Still, Rembrandt and "The Night Watch" are the pinnacle of artist and artistic
painting so the Dutch are more than redeemed in my eyes.

Golden Earring weren't too bad either. Hey, what ever happened to Golden
Earring?

Patch, you and I have much in common in our thinking. I am in that two-percent-of-the-population-abstract-thinking-idea-type-person.
We are in good company, Bill Cosby, Robin Williams, and Albert Einstein.
Seriously!

You can go with Java (J2E is a sort of expanded Java that includes structures
like servlets, java server pages, and other stuff) or C++, C# or even VB
.Net and all will stack up well with UML concepts.

Learning UML while learning Java was very... synergistic (to use a word I
loathe)

Best to Ya!

Mark


"patch" <pretpet@hotmail.com> wrote:
>so, what it adds up to is;
>
>trying to learn UML as a "standalone" goal will not get me anywhere soon.
>But as something to pick up on while I'm learning either Java or a
>C-language might be a good idea and if it "fits" me and I get my head round
>it, it will benefit my programming(design) as well as my abstract
>thinking-level towards programming.
>
>Having UML on my resume on itself is like with what I stated before: next
to
>useless, but again it might help in indirect ways like in conversation end
>maybe a better understanding of what clients want from me (clients in the
>widest sense here)..
>
>Having read the uml-article from Michael (btw: why are YOU allways the one
>with links? whats the deal with that?) I also think its smart that IF i
>choose to do (some) uml and put it on my resume i'd better also put which
>diagrams I know/ am comfortable with..
>
>I think for me it's indeed a good idea to Marks approach to pick up on
it
>while learning another OO-language.. This because my background is far from
>being a programmer but I AM quite capable at abstract thinking.. (thats
>exactly where the designer and nerd in me overlap I think).. Thanx again
for
>helping me out G&G's..
>
>Patch
>
>ps: Mark, you suggest J2E, this could also be another OO-language? (I'm
>seriously considering one of the C's), the Sams book is a good tip: it'll
be
>my fourth and I'm quite comfortable with them... (and I think Holland should
>annex you both, at least we should have never traded you New-York w/
>Surinam.. what on earth were they thinking)
>
>Mark wrote in message <3d46b8af$1@10.1.10.29>...
>>
>[...snip..]
>
>

[Mark]

Or perhaps a Dutch painter who studied and intimately knew the quality of
light and could translate that into incredible works of art? :-)


"patch" <pretpet@hotmail.com> wrote:
>
>MarkN wrote in message <3d47ceef@10.1.10.29>...
>>
>>>I AM quite capable at abstract thinking
>>
>>Good. Because those without that skill will be only be coders in the OO
>world.
>[...]
>>that one must additionally think abstactly about abstract things.
>[...]
>>But [somewhat]intangible and conceptual things are difficult.
>
>.. my terrain totally.. thinking abstract about abstract things.. whish
I
>could turn that off once in awhile but it seems to be part of who I am..
(in
>another life I might have been a philosopher or taoistic monk..[grin])
>
>patch
>
>

[Mark]

"MarkN" <m@n.com> wrote:

>I'm with Elena on this one. UML is a useful skill to have but finding companies
>that actually use it or even know what it is, well, most want to know if
>you are done coding yet - they told you what they want to do. I've worked
>for large organizations with people who have been in the industry for years.
> They had no clue what an ERD was.
>

That's exactly why I said that business has the whole paradigm (with respect
to skills ascendency) upside down.

Just think of what our systems would be like if we had developers learning
the UML first, and THEN learning to code.

[MarkN]

Makes for interesting conversations. I "love" the looks I get from people.
I have multiple conversations and rabbit trails going in my head before
I even say anything. Then after I say a few words, everything shifts again.
Ends up usually being stutering. Typing isn't much better - in some cases
worse because I am a slow typer.


"patch" <pretpet@hotmail.com> wrote:
>
>MarkN wrote in message <3d47ceef@10.1.10.29>...
>>
>>>I AM quite capable at abstract thinking
>>
>>Good. Because those without that skill will be only be coders in the OO
>world.
>[...]
>>that one must additionally think abstactly about abstract things.
>[...]
>>But [somewhat]intangible and conceptual things are difficult.
>
>.. my terrain totally.. thinking abstract about abstract things.. whish
I
>could turn that off once in awhile but it seems to be part of who I am..
(in
>another life I might have been a philosopher or taoistic monk..[grin])
>
>patch
>
>