Re: In search of Knowledge

"Guy" <Guy@xxxxxxxxxx> wrote in message
news:45dcd1d2$0$5433$5a62ac22@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Hi All,

This is just a general inquiry about OO methodology.

I agree with everything H.S. Lahman had to say, but I have a different
viewpoint that may help to explain things.


I have been in the computing industry as an application developer for a
long time, probably before even structured systems methodologies were
properly formalised.

cool. We should compare notes sometime. I have some great jokes about
Assember op codes like "Jump on punch box full" that no one else understands
anymore. :-)


In the last 10+ years OO methodologies have become the defacto mechanism
for developing software

not sure I agree. It is certainly the mechanism that our frameworks are
built from. To say it is the framework that most programmers write code in
is stretching it. I would be surprised if the average programmers' use of OO
tools demonstrates more than a passing understanding of the basics of OO
design.

and whilst I can understand all the benefits of OO and do apply aspects of
OO development to my own work I believe I am still struggling to see the
bigger picture. Can you help?

A Scenario using Use Case Driven Object Modelling (ref: Doug Rosenberg and
Kendall Scott)

A high level problem statement has been developed for an example system
the "Portfolio Trading and Accounting" system.

From this problem statement use cases are developed, along with class and
sequence diagrams. Examples of the classes involved might be:

Investment (generalised to) Commodity, Contract, Debt and Equity Classes

Anyway the documentation has been developed which the users have signed
off on and given approval to proceed with development (sorry got to go to
work soon so will have to be quick)

So physical design has begun... the environment is a straight forward
client server application using bound forms (perhaps .NET or Microsoft
Access) and a relational database (maybe SQL Server or Oracle).

Now the problem or dilema I have and this is the real question: What use
are the class and sequence diagrams? (yes I accept that they are useful
for identifying requirements and there usage and so on).

A) Hopefully the class diagrams were used to generate the class definitions
automatically. (Lots of tools do this, including Visual Studio. Heck, if a
Microsoft tool does it, you know everyone ELSE has been doing it for years.
;-)

B) Hopefully the sequence diagrams are useful for allowing the developers to
understand what calls to make, from what methods, to what methods.

In other words, you should be able to get a huge jump start on your
development if the diagrams are done right. If not, don't do them.


Am I ever going to develop a class called Investment or Commodity with
methods and data members, unlikely. Probably what I am going to do is use
the class diagram to develop an entity relationship diagram and then the
supporting tables, views, stored procedures from the relational database
are going to be bound to the user interface.

You've made a common assumption about your system architecture. Perhaps it
is a valid assumption. Perhaps not. It is certainly a different assumption
than the person writing the book. I think this is the reason why you are
having trouble seeing the reasoning here.

The assumption you have made is this:
step 1. User -> sends data -> CRUD interface -> stores data -> database
step 2. database job -> sends data -> logic processing routine -> stores
results -> database
step 3. repeat step 2 as needed
step 4. User -> views data -> report -> queries data -> database

This is a common assumption because it is a common design. The partitioning
here is the execution of logic in back-end processing. Users simply store
data and view reports (constrained by rules). The back end system actually
enacts the processing. If this is the case, then the book won't make a lot
of sense, until you apply OO principles to that "logic processing routine"
(assuming it is not in SQL). That is where you will create Investment or
Commodity objects. That is where you will put your calculations, business
rules, and state machines. In the input of raw data, or the viewing of
reports, OO is not much of a player because most of this work is automated.


I am doing OO development wrong? Would you use the relational database to
populate the classes with data and then bind the classes to the user
interface? If so why and how, when the relational database can be used to
manipulate the data.

Last few words are telling: "when the relational database can be used to
manipulate the data".

I agree, in some sense. However, relational db models are easier to change
than procedural code (usually) but that scalability breaks down when the
logic complexity rises. Once the complexity is sufficiently large, SQL
maintainability drops off dramatically. That is the OO sweet spot: the
ability to cope with much larger amounts of complexity in that 'logic
processing' part than procedural or set-based development can handle.

Hope this helps,

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--


.

Relevant Pages

  • Re: Create C++ Object Hierarchy
    ... I simply want to create a diagram for a C++ object hierarchy. ... If you are one of the *best programmers* then you will find ... design in their head. ... Creating diagrams for object-oriented hierarchies is such common task, ...
    (microsoft.public.visio.general)
  • Re: Is symbolic thinking the silver bullit for programming?
    ... programming, such as database diagrams, object class diagrams, timing diagrams, flowcharts, etc. ... There is a definite strain of resistance to visualization among programmers. ... that you had to draw a flowchart before you wrote the program. ...
    (comp.lang.scheme)
  • Re: Is symbolic thinking the silver bullit for programming?
    ... >programming, such as database diagrams, object class diagrams, timing ... the visual representations are useful ... There is a definite strain of resistance to visualization among programmers. ... that you had to draw a flowchart before you wrote the program. ...
    (comp.lang.scheme)