Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #10069 > unrolled thread

Standard Design and Development Methodologies

Back to article view | Back to comp.lang.java.programmer

Contents

  Standard Design and Development Methodologies Novice <novice@example..com> - 2011-11-19 19:42 +0000
    Re: Standard Design and Development Methodologies Arne Vajhøj <arne@vajhoej.dk> - 2011-11-19 21:22 -0500
      Re: Standard Design and Development Methodologies Novice <novice@example..com> - 2011-11-20 16:55 +0000
        Re: Standard Design and Development Methodologies "Charles Hottel" <chottel@earthlink.net> - 2011-11-20 22:20 -0500
    Re: Standard Design and Development Methodologies Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-11-19 23:01 -0400
      Re: Standard Design and Development Methodologies Lew <lewbloch@gmail.com> - 2011-11-19 20:13 -0800
        Re: Standard Design and Development Methodologies Lew <lewbloch@gmail.com> - 2011-11-19 20:16 -0800
        Re: Standard Design and Development Methodologies "Derek K. Wodenhouse" <dkw@none.of.your.biz> - 2011-11-19 23:49 -0500
          Re: Standard Design and Development Methodologies Lew <lewbloch@gmail.com> - 2011-11-19 23:45 -0800
            Re: Standard Design and Development Methodologies "Derek K. Wodenhouse" <dkw@none.of.your.biz> - 2011-11-20 03:49 -0500
              Re: Standard Design and Development Methodologies Robert Klemme <shortcutter@googlemail.com> - 2011-11-20 13:58 +0100
              Re: Standard Design and Development Methodologies Lew <lewbloch@gmail.com> - 2011-11-20 08:32 -0800
                Re: Standard Design and Development Methodologies "Derek K. Wodenhouse" <dkw@none.of.your.biz> - 2011-11-20 18:24 -0500
          Re: Standard Design and Development Methodologies Patricia Shanahan <pats@acm.org> - 2011-11-20 03:27 -0800
            Re: Standard Design and Development Methodologies spk <jhic@speak.invalid> - 2011-11-20 09:54 -0400
              Re: Standard Design and Development Methodologies Lew <lewbloch@gmail.com> - 2011-11-20 08:33 -0800
              Re: Standard Design and Development Methodologies thoolen <th00len@th0lenbot.thorium> - 2011-11-20 18:30 -0500
        Re: Standard Design and Development Methodologies Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-11-20 09:35 -0400
        Re: Standard Design and Development Methodologies Novice <novice@example..com> - 2011-11-20 17:18 +0000
          Re: Standard Design and Development Methodologies Lew <lewbloch@gmail.com> - 2011-11-20 10:30 -0800
            Re: Standard Design and Development Methodologies Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-11-21 07:23 -0400
        Re: Standard Design and Development Methodologies Arne Vajhøj <arne@vajhoej.dk> - 2011-11-25 21:51 -0500
          Re: Standard Design and Development Methodologies Lew <lewbloch@gmail.com> - 2011-11-25 20:07 -0800
      Re: Standard Design and Development Methodologies Novice <novice@example..com> - 2011-11-20 17:08 +0000
        Re: Standard Design and Development Methodologies Arne Vajhøj <arne@vajhoej.dk> - 2011-11-20 12:18 -0500
        Re: Standard Design and Development Methodologies markspace <-@.> - 2011-11-20 10:29 -0800
        Re: Standard Design and Development Methodologies Lew <lewbloch@gmail.com> - 2011-11-20 10:55 -0800
          Re: Standard Design and Development Methodologies Arne Vajhøj <arne@vajhoej.dk> - 2011-11-20 14:07 -0500
            Re: Standard Design and Development Methodologies Lew <lewbloch@gmail.com> - 2011-11-20 11:50 -0800
        Re: Standard Design and Development Methodologies Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-11-21 07:19 -0400
    Re: Standard Design and Development Methodologies Roedy Green <see_website@mindprod.com.invalid> - 2011-11-20 22:27 -0800
      Re: Standard Design and Development Methodologies Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-11-21 07:02 -0400
        Re: Standard Design and Development Methodologies Robert Klemme <shortcutter@googlemail.com> - 2011-11-22 18:52 +0100
          Re: Standard Design and Development Methodologies markspace <-@.> - 2011-11-22 11:37 -0800
            Re: Standard Design and Development Methodologies Gene Wirchenko <genew@ocis.net> - 2011-11-22 14:27 -0800
              Re: Standard Design and Development Methodologies Arne Vajhøj <arne@vajhoej.dk> - 2011-11-25 22:06 -0500
                Re: Standard Design and Development Methodologies Gene Wirchenko <genew@ocis.net> - 2011-11-26 21:16 -0800
                  Re: Standard Design and Development Methodologies Arne Vajhøj <arne@vajhoej.dk> - 2011-12-02 21:53 -0500
                    Re: Standard Design and Development Methodologies Gene Wirchenko <genew@ocis.net> - 2011-12-04 21:25 -0800
                      Re: Standard Design and Development Methodologies Arne Vajhøj <arne@vajhoej.dk> - 2011-12-05 22:41 -0500
                        Re: Standard Design and Development Methodologies Gene Wirchenko <genew@ocis.net> - 2011-12-05 19:58 -0800
            Re: Standard Design and Development Methodologies Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-11-22 19:57 -0400
              Re: Standard Design and Development Methodologies Arne Vajhøj <arne@vajhoej.dk> - 2011-11-25 22:04 -0500
                Re: Standard Design and Development Methodologies Gene Wirchenko <genew@ocis.net> - 2011-11-26 21:18 -0800
                  Re: Standard Design and Development Methodologies Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-11-27 08:34 -0400
                    Re: Standard Design and Development Methodologies Patricia Shanahan <pats@acm.org> - 2011-11-27 08:39 -0800
                      Re: Standard Design and Development Methodologies Martin Gregorie <martin@address-in-sig.invalid> - 2011-11-27 20:07 +0000
                    Re: Standard Design and Development Methodologies Arne Vajhøj <arne@vajhoej.dk> - 2011-12-02 21:48 -0500
                      Re: Standard Design and Development Methodologies Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-12-03 14:52 -0400
                        Re: Standard Design and Development Methodologies Arne Vajhøj <arne@vajhoej.dk> - 2011-12-05 22:50 -0500
                          Re: Standard Design and Development Methodologies Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-12-06 07:21 -0400
        Re: Standard Design and Development Methodologies Arne Vajhøj <arne@vajhoej.dk> - 2011-11-25 21:54 -0500
      Re: Standard Design and Development Methodologies Arne Vajhøj <arne@vajhoej.dk> - 2011-11-25 21:47 -0500

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#10144

On 11-11-20 02:30 PM, Lew wrote:
> Novice wrote:
>> Lew wrote: 
>>> There's a comprehensive little pamphlet reviewing various software
>>> development methodologies called /Wicked Problems, Righteous
>>> Solutions/ by DeGrace and Stahl, 1990, that is as relevant today as
>>> when first published. 
>>> http://www.google.com/search?q=ISBN%20013590126X 
>>
>> I'm trying to figure out what kinds of things an interviewer from the 
>> technical side of the shop - as opposed to HR - is going to expect. I'm 
>> not sure how open-minded they will be to someone who wants a job but 
>> doesn't seem to have much prior contact with specific methodologies so I 
>> was hoping to get a list of the key methodologies. 
> 
> Add Agile to the list in /Wicked Problems.../ and you'll have that list.  Also, is there one on Wikipedia, perhaps, as Arved Sandstrom wrote: 
>> You could probably do worse than to read 
>> http://en.wikipedia.org/wiki/Software_development_methodology.
>>  This is of value primarily because it introduces a lot of common terminology. 
> ?
> 
I thought that was quite clear. :-) That Wikipedia article covers a lot
of ground and uses a lot of terms that are in widespread use. I think
it's a good starting point for doing a Rumsfeldian analysis of "what do
I not know".

AHS
-- 
You should know the problem before you try to solve it.
Example: When my son was three he cried about a problem with his hand. I
kissed it several times and asked him about the problem. He peed on his
hand.
-- Radia Perlman, inventor of spanning tree protocol

[toc] | [prev] | [next] | [standalone]

#10254

On 11/19/2011 11:13 PM, Lew wrote:
> There's a comprehensive little pamphlet reviewing various software
> development methodologies called /Wicked Problems, Righteous Solutions/
> by DeGrace and Stahl, 1990, that is as relevant today as when first
> published.
>
> Its main conclusion, after a very neutral overview of the extant pet
> theories, is that successful methodologies rest on two key features:
> an individual who maintains the project architecture and structures
> in his/her own mind,

It is obviously correct.

But it is not very useful.

Creating good software when one person can understand the
entire app is the easy problem.

Creating good software when one person cannot understand the
entire app is the hard problem.

Arne

[toc] | [prev] | [next] | [standalone]

#10261

Arne Vajhøj wrote:
> Lew wrote:
>> There's a comprehensive little pamphlet reviewing various software
>> development methodologies called /Wicked Problems, Righteous Solutions/
>> by DeGrace and Stahl, 1990, that is as relevant today as when first
>> published.
>>
>> Its main conclusion, after a very neutral overview of the extant pet
>> theories, is that successful methodologies rest on two key features:
>> an individual who maintains the project architecture and structures
>> in his/her own mind,
> 
> It is obviously correct.
> 
> But it is not very useful.
> 
> Creating good software when one person can understand the
> entire app is the easy problem.
> 
> Creating good software when one person cannot understand the
> entire app is the hard problem.

You are correct, but bear in mind that I provided only a very few words of summary for a rather detailed, patient analysis and set of conclusions in the original work.  Before judging their conclusions you might want to be sure that you understand their point more directly than by hearsay from a very cursory precis.

As best I understand the book it is their conclusion that even the second case requires a person to understand the entire app.  This apparent paradox is resolved by understanding that the overview knowledge, while detailed, isn't necessarily atomic.  It's a matter of someone exercising a form of leadership to assure consistency and a certain focus in a project.  By analogy, the chief executive of a nation need not understand necessarily every single detail of every action occurring in every corner of their realm, but the should have a keen grasp of the nation as a whole and a vision for its direction.  This is the sort of "understand the project" that I infer and remember from the book.

I conclude that a project that grows beyond such a vision needs to have fractal subprojects that fit within such scope and operate with some autonomy.

This is a direction that might address the valid point you raised.  I recommend the book not so much to endorse its conclusions as to commend its even-handed and comprehensive analysis and the segregation thereof from the authors' agenda or theories.  While it draws conclusions in the latter part of the book, it does not go so far as to recommend anything.  They have no pet buzzword or system to promote, only observations as to what works and fails under different methodological structures.  It's a foundational work.

As to how "useful" their conclusions are, I'll let you judge for yourself after you've bypassed the filter of my reporting.  I'd be surprised if you maintained your dyspeptic view after that.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#10103

Arved Sandstrom <asandstrom3minus1@eastlink.ca> wrote in
news:p4_xq.30508$Pm3.8310@newsfe12.iad: 

> You could probably do worse than to read
> http://en.wikipedia.org/wiki/Software_development_methodology. This is
> of value primarily because it introduces a lot of common terminology.
> 
> Ultimately _every_ software development methodology (SDM) boils down
> to: 
> 
> 1. requirements analysis - understanding what the client needs you to
> do; 2. analysis & design - how you intend to meet those needs. See
> http://en.wikipedia.org/wiki/Object-oriented_analysis_and_design,
> since we are talking Java, for general concepts;
> 3. implementation - actually write code;
> 4. testing - ensuring that your code, as written, satisfies the
> requirements;
> 5. maintenance - nurturing the application over its lifespan.
> 
> How all the various approaches differ is how they break up and
> sequence these activities. What really matters is that all these
> activities are important.
> 
> It's probably best not to fixate on any given methodology. Just learn
> up on the highlights of each, and keep in mind that all of them
> ultimately boil down to requiring competence in the same skills. You'd
> be interested initially in object-oriented analysis (OOA),
> object-oriented design (OOD), and how to test your code (starting with
> unit testing and perhaps functional testing).
> 
> Like Arne suggested, "Effective Java" by Bloch is a great book. So is
> "Code Complete". IMO I wouldn't bother buying a copy of the GOF design
> patterns book; borrow from a university library or locate a decent
> website instead. Read some Martin Fowler
> (http://martinfowler.com/intro.html). Don't get hung up on specific
> methodologies (did I say that already?) - no project ever succeeded or
> failed just because of what methodology a team used. Get some
> familiarity with UML but don't go overboard with it.
> 
> My own specific suggestion - read
> http://www.agilemodeling.com/artifacts/crcModel.htm (Scott Ambler is
> also a good author). CRC is not just useful in agile.
> 
> If your understanding of persistence (databases) is not solid - in
> your estimation, bone up on that.
> 
> If you don't have one already, select another OO programming language
> to learn. You can make a lot more headway in learning all of the above
> if you're not tied to one specific language. Just my opinion.
> 
Thanks, Arved. Lots of great suggestions, tempered with common sense like 
not getting fixated on any specific methodology. 

A couple of followup questions if I may. 
1. I'm pretty solid on relational databases, although not OO databases. 
I'm not clear on the actual purpose of "persistence layers" though. I 
started to look at Hibernate a few years back but got sidetracked and 
didn't get very far. Can you possibly summarize in a few sentences:
a. what a persistence layer does 
b. how an OO database differs from a relational database?

I'm also intrigued to hear you suggest looking at another OO language as 
a way to learn more about OO in general. Interesting idea. Like learning 
French to help improve your Spanish, to use a non-computer metaphor.I did 
dabble in C++ briefly after I had the basics of C but then discovered 
that C++ was not easily portable across platforms. That's when I was sold 
(brainwashed?) into looking at Java ;-)

What other OO language would be best to consider? C++? Smalltalk? .NET? 
(Hmm, I'm not sure if .NET is even considered OO....)


-- 
Novice

[toc] | [prev] | [next] | [standalone]

#10105

On 11/20/2011 12:08 PM, Novice wrote:
> I'm also intrigued to hear you suggest looking at another OO language as
> a way to learn more about OO in general. Interesting idea. Like learning
> French to help improve your Spanish, to use a non-computer metaphor.I did
> dabble in C++ briefly after I had the basics of C but then discovered
> that C++ was not easily portable across platforms. That's when I was sold
> (brainwashed?) into looking at Java ;-)
>
> What other OO language would be best to consider? C++? Smalltalk? .NET?
> (Hmm, I'm not sure if .NET is even considered OO....)

.NET is OO.

But I think C# is too close to Java to provide maximum alternative
perspective.

C++, Ruby may provide more value for this purpose.

Arne

[toc] | [prev] | [next] | [standalone]

#10107

On 11/20/2011 9:08 AM, Novice wrote:

> 1. I'm pretty solid on relational databases, although not OO databases.
> I'm not clear on the actual purpose of "persistence layers" though. I
> started to look at Hibernate a few years back but got sidetracked and
> didn't get very far. Can you possibly summarize in a few sentences:
> a. what a persistence layer does


Persistence just saves stuff to long term storage.  How it does that is 
another matter.  When talking databases, a persistence layer interfaces 
objects to a database (usually a database connection of some sort).  It 
takes care of a lot of the busy work of reading a database entity into 
objects, and writing objects out as database entities.

You can do this manually, but it's really busy work.  Do it once to see 
how it works, then forget it and go for JPA.


> b. how an OO database differs from a relational database?


I don't know, other than I don't think OO databases are popular or 
practical.  Everyone I know uses the relational variety, or flat files.

[toc] | [prev] | [next] | [standalone]

#10109

Novice wrote:
> A couple of followup questions if I may. 
> 1. I'm pretty solid on relational databases, although not OO databases. 
> I'm not clear on the actual purpose of "persistence layers" though. I 
> started to look at Hibernate a few years back but got sidetracked and 
> didn't get very far. Can you possibly summarize in a few sentences:
> a. what a persistence layer does 
> b. how an OO database differs from a relational database?

This is a major topic.  I'll hit some headlines /infra/.

> ... 
> What other OO language would be best to consider? C++? Smalltalk? .NET? 
> (Hmm, I'm not sure if .NET is even considered OO....)

.Net isn't a language, it's a platform.

You might read Grady Booch or others on what object-oriented blahblah is generally.

Don't get too bogged down there - skimming the TOC and a few paragraphs in each chapter in the bookstore will get you started.

Object-oriented is just a way of looking at things.  Relational algebra (RDBMSes) is another, orthogonal way.

Object-oriented, as well explained by Booch and others, entails adherence to certain principles, the number and name of which vary a bit between authors.  Basically it's encapsulation and inheritance, component and layered architecture, and a clean, well laid-out structure.

Encapsulation involves abstraction of the interaction between tightly focused types that hide their mechanics.  You program to the interface <generically at times>.

Inheritance is a spice to use lightly.

O-O is at its best a synonym for really good modeling.  Each type should be fairly simple - easier to do if you concentrate on its interface and not the messy innards.

Unit tests are invaluable.

Good languages are C#, C++, Smalltalk (the progenitor).

Other languages to know are Lisp, Forth, Javascript, Python, Go, Prolog, C, bash.

Object-oriented databases are a dead end.

IMHO.

But SQL is really only for those who understand relations.

Relations are not objects.

And vice versa.

But they map to each other, with a lot of transformational infrastructure.  The key is that the object and data ontologies are not the same.

I've done a lot of that - mapping objects to relations, or "object-to-relational mapping" (ORM).

The best way to do ORM in Java is JPA, the Java Persistence API.  There are three standard, free products that give you that specification: EclipseLink, Apache OpenJPA, and Hibernate.  Hibernate comes with a weight of documentation and culture from its pre-JPA days.  Don't get sucked into that.  Stick firmly with JPA.

OK, "best" is relative.  You might be fine with just the Collections API, which you should master anyway.  But to talk to databases like Derby or PostgreSQL, JPA is wonderful.  As long as you don't think of it as "talking to databases".

JPA gives you an object-oriented view of persistent information, hiding the relational sensibility from the program.  It is about control of sessions, that is, 'EntityManager' lifetimes, and how durable to make object properties, not about data.  The framework handles a subset of data manipulations opaquely to support that mapping.

Well, translucently, but learn the basics first.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#10110

On 11/20/2011 1:55 PM, Lew wrote:
>> ...
>> What other OO language would be best to consider? C++? Smalltalk? .NET?
>> (Hmm, I'm not sure if .NET is even considered OO....)
>
> .Net isn't a language, it's a platform.

But with the OO support in the platform.

Arne

[toc] | [prev] | [next] | [standalone]

#10112

Novice wrote:
>  Arne Vajhøj wrote:
>> Lew wrote:
>>> ...
>>> What other OO language would be best to consider? C++? Smalltalk? .NET?
>>> (Hmm, I'm not sure if .NET is even considered OO....)
>>
>> .Net isn't a language, it's a platform.
> 
> But with the OO support in the platform.

True, but the OP did ask about languages and listed .Net as one such.

Just like the JVM is object-oriented but not a language.

The advantage to the OP is that every .Net language is object oriented.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#10143

On 11-11-20 01:08 PM, Novice wrote:
> Arved Sandstrom <asandstrom3minus1@eastlink.ca> wrote in
> news:p4_xq.30508$Pm3.8310@newsfe12.iad: 
> 
>> You could probably do worse than to read
>> http://en.wikipedia.org/wiki/Software_development_methodology. This is
>> of value primarily because it introduces a lot of common terminology.
>>
>> Ultimately _every_ software development methodology (SDM) boils down
>> to: 
>>
>> 1. requirements analysis - understanding what the client needs you to
>> do; 2. analysis & design - how you intend to meet those needs. See
>> http://en.wikipedia.org/wiki/Object-oriented_analysis_and_design,
>> since we are talking Java, for general concepts;
>> 3. implementation - actually write code;
>> 4. testing - ensuring that your code, as written, satisfies the
>> requirements;
>> 5. maintenance - nurturing the application over its lifespan.
>>
>> How all the various approaches differ is how they break up and
>> sequence these activities. What really matters is that all these
>> activities are important.
>>
>> It's probably best not to fixate on any given methodology. Just learn
>> up on the highlights of each, and keep in mind that all of them
>> ultimately boil down to requiring competence in the same skills. You'd
>> be interested initially in object-oriented analysis (OOA),
>> object-oriented design (OOD), and how to test your code (starting with
>> unit testing and perhaps functional testing).
>>
>> Like Arne suggested, "Effective Java" by Bloch is a great book. So is
>> "Code Complete". IMO I wouldn't bother buying a copy of the GOF design
>> patterns book; borrow from a university library or locate a decent
>> website instead. Read some Martin Fowler
>> (http://martinfowler.com/intro.html). Don't get hung up on specific
>> methodologies (did I say that already?) - no project ever succeeded or
>> failed just because of what methodology a team used. Get some
>> familiarity with UML but don't go overboard with it.
>>
>> My own specific suggestion - read
>> http://www.agilemodeling.com/artifacts/crcModel.htm (Scott Ambler is
>> also a good author). CRC is not just useful in agile.
>>
>> If your understanding of persistence (databases) is not solid - in
>> your estimation, bone up on that.
>>
>> If you don't have one already, select another OO programming language
>> to learn. You can make a lot more headway in learning all of the above
>> if you're not tied to one specific language. Just my opinion.
>>
> Thanks, Arved. Lots of great suggestions, tempered with common sense like 
> not getting fixated on any specific methodology. 
> 
> A couple of followup questions if I may. 
> 1. I'm pretty solid on relational databases, although not OO databases. 
> I'm not clear on the actual purpose of "persistence layers" though. I 
> started to look at Hibernate a few years back but got sidetracked and 
> didn't get very far. Can you possibly summarize in a few sentences:
> a. what a persistence layer does 
> b. how an OO database differs from a relational database?

What the others said. :-) Not a cop-out - they explained it well.

> I'm also intrigued to hear you suggest looking at another OO language as 
> a way to learn more about OO in general. Interesting idea. Like learning 
> French to help improve your Spanish, to use a non-computer metaphor.I did 
> dabble in C++ briefly after I had the basics of C but then discovered 
> that C++ was not easily portable across platforms. That's when I was sold 
> (brainwashed?) into looking at Java ;-)
> 
> What other OO language would be best to consider? C++? Smalltalk? .NET? 
> (Hmm, I'm not sure if .NET is even considered OO....)
> 
C# is a good language to learn, but I'm with Arne that it's too close to
Java to serve the purpose I suggested. I wouldn't recommend C++, even
C++11, for this purpose either, for different reasons - steep learning
curve, multi-paradigm so you might lose sight of the forest for the
trees etc etc.

OO in Ruby would be worth looking at, IMO. If you really wanted to open
your eyes you could look at prototype-based OO like Self or Javascript
[1], but I think Ruby would do just fine.

AHS

1. Look up the terms "prototype based OO" or "prototype based
programming". Languages like C# or Java are class-based OO, in contrast.
-- 
You should know the problem before you try to solve it.
Example: When my son was three he cried about a problem with his hand. I
kissed it several times and asked him about the problem. He peed on his
hand.
-- Radia Perlman, inventor of spanning tree protocol

[toc] | [prev] | [next] | [standalone]

#10139

On Sat, 19 Nov 2011 19:42:07 +0000 (UTC), Novice <novice@example..com>
wrote, quoted or indirectly quoted someone who said :

>What are the standard design and development methodologies being used in 
>systems departments these days and, ideally, where can I find tutorials for 
>them, preferably free and online? 

see http://mindprod.com/jgloss/designpatterns.html

Design patterns are the most important.  I have yet to be convinced of
the utility of tools like UML.  

see http://mindprod.com/jgloss/uml.html
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
I can't come to bed just yet. Somebody is wrong on the Internet. 

[toc] | [prev] | [next] | [standalone]

#10142

On 11-11-21 02:27 AM, Roedy Green wrote:
> On Sat, 19 Nov 2011 19:42:07 +0000 (UTC), Novice <novice@example..com>
> wrote, quoted or indirectly quoted someone who said :
> 
>> What are the standard design and development methodologies being used in 
>> systems departments these days and, ideally, where can I find tutorials for 
>> them, preferably free and online? 
> 
> see http://mindprod.com/jgloss/designpatterns.html
> 
> Design patterns are the most important.  I have yet to be convinced of
> the utility of tools like UML.  
> 
> see http://mindprod.com/jgloss/uml.html

I'm convinced of the utility of a specific number of UML diagrams, when
used with pencil and paper or on whiteboards. There are only 2 or 3 of
the diagrams I would ever use in technical documentation, and then very
sparingly. For the latter I make a point of not using any "UML editors";
rather, I use my favourite drawing program with UML stencils.

Diagrams have considerable merit to display information, and you may as
well use a standardized notation. UML is OK for that. But if you find
yourself struggling with the details of the notation, or the UML editor
is getting in your way, you're wasting your time.

Design patterns _are_ useful in OOP; I'll second that recommendation.
You'll get a leg up over most of your peers if you understand the useful
patterns thoroughly, because most programmers in the industry don't know
patterns.

AHS
-- 
You should know the problem before you try to solve it.
Example: When my son was three he cried about a problem with his hand. I
kissed it several times and asked him about the problem. He peed on his
hand.
-- Radia Perlman, inventor of spanning tree protocol

[toc] | [prev] | [next] | [standalone]

#10174

On 21.11.2011 12:02, Arved Sandstrom wrote:
> On 11-11-21 02:27 AM, Roedy Green wrote:
>> On Sat, 19 Nov 2011 19:42:07 +0000 (UTC), Novice<novice@example..com>
>> wrote, quoted or indirectly quoted someone who said :
>>
>>> What are the standard design and development methodologies being used in
>>> systems departments these days and, ideally, where can I find tutorials for
>>> them, preferably free and online?
>>
>> see http://mindprod.com/jgloss/designpatterns.html
>>
>> Design patterns are the most important.  I have yet to be convinced of
>> the utility of tools like UML.
>>
>> see http://mindprod.com/jgloss/uml.html
>
> I'm convinced of the utility of a specific number of UML diagrams, when
> used with pencil and paper or on whiteboards. There are only 2 or 3 of
> the diagrams I would ever use in technical documentation, and then very
> sparingly. For the latter I make a point of not using any "UML editors";
> rather, I use my favourite drawing program with UML stencils.
>
> Diagrams have considerable merit to display information, and you may as
> well use a standardized notation. UML is OK for that. But if you find
> yourself struggling with the details of the notation, or the UML editor
> is getting in your way, you're wasting your time.

I strongly agree!  Additional point: it may make sense to use non UML 
elements in an UML diagram from time to time to improve understanding. 
You can't do that with a string UML programming tool.

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#10176

On 11/22/2011 9:52 AM, Robert Klemme wrote:

> On 21.11.2011 12:02, Arved Sandstrom wrote:
>> I'm convinced of the utility of a specific number of UML diagrams, when
>> used with pencil and paper or on whiteboards. There are only 2 or 3 of
>> the diagrams I would ever use in technical documentation, and then very
>> sparingly. For the latter I make a point of not using any "UML editors";
>> rather, I use my favourite drawing program with UML stencils.


I'd think that if a diagram, UML or otherwise, is useful on a 
whiteboard, then the same diagram would be useful in the requirements 
document, as it explains to still yet more folks what is intened.


>>
>> Diagrams have considerable merit to display information, and you may as
>> well use a standardized notation. UML is OK for that. But if you find
>> yourself struggling with the details of the notation, or the UML editor
>> is getting in your way, you're wasting your time.
>
> I strongly agree! Additional point: it may make sense to use non UML
> elements in an UML diagram from time to time to improve understanding.
> You can't do that with a string UML programming tool.


Agree that UML shouldn't be considered a straight-jacket.

[toc] | [prev] | [next] | [standalone]

#10178

On Tue, 22 Nov 2011 11:37:04 -0800, markspace <-@.> wrote:

>On 11/22/2011 9:52 AM, Robert Klemme wrote:
>
>> On 21.11.2011 12:02, Arved Sandstrom wrote:

[snip]

>>> Diagrams have considerable merit to display information, and you may as
>>> well use a standardized notation. UML is OK for that. But if you find
>>> yourself struggling with the details of the notation, or the UML editor
>>> is getting in your way, you're wasting your time.

     Too true.

>> I strongly agree! Additional point: it may make sense to use non UML
>> elements in an UML diagram from time to time to improve understanding.

     Yes.

>> You can't do that with a string UML programming tool.

>Agree that UML shouldn't be considered a straight-jacket.

     Unfortunately, UML often is a straitjacket.  I used it while
taking my degree.  A few of the diagrams were useful, but they were
just more formal versions of what I might do anyway.  I dreaded
diagramming, because it took so much time and did not help me much at
all.  I certainly would not use UML diagramming to help design a
system.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#10257

On 11/22/2011 5:27 PM, Gene Wirchenko wrote:
> On Tue, 22 Nov 2011 11:37:04 -0800, markspace<-@.>  wrote:
>> Agree that UML shouldn't be considered a straight-jacket.
>
>       Unfortunately, UML often is a straitjacket.  I used it while
> taking my degree.  A few of the diagrams were useful, but they were
> just more formal versions of what I might do anyway.

Sure.

But by formalizing by using standard notation they become
much more readable by the maintenance programmers that will
have to work with the code later.

>                                                         I dreaded
> diagramming, because it took so much time and did not help me much at
> all.  I certainly would not use UML diagramming to help design a
> system.

Some people don't believe in standards.

Arne

[toc] | [prev] | [next] | [standalone]

#10273

On Fri, 25 Nov 2011 22:06:43 -0500, Arne Vajhøj <arne@vajhoej.dk>
wrote:

>On 11/22/2011 5:27 PM, Gene Wirchenko wrote:
>> On Tue, 22 Nov 2011 11:37:04 -0800, markspace<-@.>  wrote:
>>> Agree that UML shouldn't be considered a straight-jacket.
>>
>>       Unfortunately, UML often is a straitjacket.  I used it while
>> taking my degree.  A few of the diagrams were useful, but they were
>> just more formal versions of what I might do anyway.
>
>Sure.
>
>But by formalizing by using standard notation they become
>much more readable by the maintenance programmers that will
>have to work with the code later.
>
>>                                                         I dreaded
>> diagramming, because it took so much time and did not help me much at
>> all.  I certainly would not use UML diagramming to help design a
>> system.
>
>Some people don't believe in standards.

     I believe in standards, but UML is awkward to enter.  Sketches
are much faster, and I can think with them.  I understand about
documenting, but UML is just too fiddly for my taste.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#10455

On 11/27/2011 12:16 AM, Gene Wirchenko wrote:
> On Fri, 25 Nov 2011 22:06:43 -0500, Arne Vajhøj<arne@vajhoej.dk>
> wrote:
>
>> On 11/22/2011 5:27 PM, Gene Wirchenko wrote:
>>> On Tue, 22 Nov 2011 11:37:04 -0800, markspace<-@.>   wrote:
>>>> Agree that UML shouldn't be considered a straight-jacket.
>>>
>>>        Unfortunately, UML often is a straitjacket.  I used it while
>>> taking my degree.  A few of the diagrams were useful, but they were
>>> just more formal versions of what I might do anyway.
>>
>> Sure.
>>
>> But by formalizing by using standard notation they become
>> much more readable by the maintenance programmers that will
>> have to work with the code later.
>>
>>>                                                          I dreaded
>>> diagramming, because it took so much time and did not help me much at
>>> all.  I certainly would not use UML diagramming to help design a
>>> system.
>>
>> Some people don't believe in standards.
>
>       I believe in standards, but UML is awkward to enter.  Sketches
> are much faster, and I can think with them.  I understand about
> documenting, but UML is just too fiddly for my taste.

You may think your sketch is very readable, but other people
reading it will get the same info as you from it, because the
semantics of things shown are not standardized.

Arne

[toc] | [prev] | [next] | [standalone]

#10516

On Fri, 02 Dec 2011 21:53:05 -0500, Arne Vajhøj <arne@vajhoej.dk>
wrote:

>On 11/27/2011 12:16 AM, Gene Wirchenko wrote:

[snip]

>>       I believe in standards, but UML is awkward to enter.  Sketches
>> are much faster, and I can think with them.  I understand about
>> documenting, but UML is just too fiddly for my taste.
>
>You may think your sketch is very readable, but other people
>reading it will get the same info as you from it, because the
                ^
>semantics of things shown are not standardized.

     I think you are missing a "not" at the indicated position.  I am
assuming that in my response.

     Not necessarily.  XML is not the only standard.  It just has a
loud drummer.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#10543

On 12/5/2011 12:25 AM, Gene Wirchenko wrote:
> On Fri, 02 Dec 2011 21:53:05 -0500, Arne Vajhøj<arne@vajhoej.dk>
> wrote:
>> On 11/27/2011 12:16 AM, Gene Wirchenko wrote:
>
> [snip]
>
>>>        I believe in standards, but UML is awkward to enter.  Sketches
>>> are much faster, and I can think with them.  I understand about
>>> documenting, but UML is just too fiddly for my taste.
>>
>> You may think your sketch is very readable, but other people
>> reading it will get the same info as you from it, because the
>                  ^
>> semantics of things shown are not standardized.
>
>       I think you are missing a "not" at the indicated position.  I am
> assuming that in my response.

Yes.

>       Not necessarily.

So what notation with standardized semantics are you using

 >                         XML is not the only standard.  It just has a
 > loud drummer.

????

What does XML have to do with the topic?

Arne

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web