Software Engineering - A question on identifying object for use case

Author

A question on identifying object for use case

Xia Yang

2006-05-26, 4:02 am

Hi,

I am a bit

by the software engineering book why they try to
make easy thing complicated.

In a very simple application, the user press a "create" button then the
application will show a form for user to enter data. Then the user can
press a "submit" button to save the data entered.

According to the software engineering book,
1. The create button is the first boundary object, after the user send
press() message to create button, it should create a control object
"createcontrol".
2. Then the createcontrol object will create an inputform object for
user, which is also a boundary object. The inputform object will also
create a control object called inputformcontrol object.
3. Then the user will send message to inputform to update data. After
user send submit() message to the submit button, the inputform object
will inform inputformcontrol object to send the collected data to the
entity object.
4. Lastly, the control objects are destoryed one by one.

I am just wondering why I shall do it in this way? Isn't it easier and
less complicated if I just create an object containing all the data
entered by user and then send it to the storage after the user press
submit button? Why shall I use those control objects? I know this may
be a stupid question, but please help if you got any idea. Thanks a lot.

H. S. Lahman

2006-05-28, 10:02 pm

Responding to Yang...

> In a very simple application, the user press a "create" button then the
> application will show a form for user to enter data. Then the user can
> press a "submit" button to save the data entered.
>
> According to the software engineering book,

I don't know what SE book you are reading and what the context of the
example is. It /sounds/ like the example is trying to define a GUI
interface much the same way that a Window Builder tool would do.

> 1. The create button is the first boundary object, after the user send
> press() message to create button, it should create a control object
> "createcontrol".

This is decoupling the GUI screen elements from the mechanics of
instantiation. The general message "createcontrol" can be used to
create buttons, text boxes, grids, or whatever. However, there is a
fixed suite of possible controls so there is a fixed suite of possible
control construction implementations (factories). That allows one to
"map" control into factory by instantiating a relationship over which
the same "createcontrol" message is sent.

The advantage of this is that one can later substitute a fancier button
in the GUI design that requires a different factory instantiation
mechanism by simply re-assigning the relationship and not touching to
code for the instantiation or whoever is sending the "createcontrol"
message.

> 2. Then the createcontrol object will create an inputform object for
> user, which is also a boundary object. The inputform object will also
> create a control object called inputformcontrol object.

I assume that the forms can be fairly complicated and will differ quite
a bit from one form to another. This sort of construction is then
accomplishing three things. First, it is separating the rules and
policies of instantiation from the rules and policies of collaboration.
Typically those sets of rules and policies will be quite different and
are concerned with different issues (Who participates in collaboration
vs. When collaboration takes place and What is does). This separation
is why one has "factory" objects -- to encapsulate the rules and
policies of instantiation.

The second, more important thing is separating the concerns of what
needs to be done into smaller, more cohesive, and more manageable
pieces. Hence the responsibilities of an inputform object are likely to
be different than the responsibilities of an inputformcontrol object.
This sort of divide-and-conquer approach to managing complexity is quite
common in software development; creating multiple object abstractions is
just a uniquely OO way of doing so. But this segues to an important
reason Why one wants to do this...

The third, and most important reason of all is that it allows one to
solve the problem with small generic behaviors. That is, one can
abstract the invariants of the GUI paradigm and write software around
them while leaving detailed differences to parametric data. This is
especially important when one is creating something as generic as a GUI.
One doesn't want to write a lot of custom code for every artifact in
the GUI design. Instead, one wants to encode operations for generic
elements like TextBoxControl.

Why? Because every text box behaves like every other text box. The
only unique problem semantics lies in the label text string and the
string in the Value attribute. So one only writes one TextBoxControl
implementation for all of the text boxes on the form. Then one just
needs to instantiate each one with the right values for things like
labels. But even that initialization is pretty cookbook, so we come
full circle back to using "factory" objects that know how to initialize
a particular GUI element given the right data.

> 3. Then the user will send message to inputform to update data. After
> user send submit() message to the submit button, the inputform object
> will inform inputformcontrol object to send the collected data to the
> entity object.

Up to here we were essentially in a sort of problem setup mode. Now we
are into collaboration to actually solve the problem in hand. Here the
developer connects to dots of the the overall solution sequence between
all those small, cohesive, generic operations that were defined and
instantiated previously.

> 4. Lastly, the control objects are destoryed one by one.

Right. Because the instances with the right data reflect what the user
sees on the screen. Once the screen is changed, they can be discarded.
(Whether they are literally destroyed or not depends upon other problem
considerations, such as the likelihood that exactly same screen will
need to be displayed again.)

>
> I am just wondering why I shall do it in this way? Isn't it easier and
> less complicated if I just create an object containing all the data
> entered by user and then send it to the storage after the user press
> submit button? Why shall I use those control objects? I know this may
> be a stupid question, but please help if you got any idea. Thanks a lot.

If all you want to do is write short, elegant programs in a hurry, you
should be doing functional programming. B-) However, the goals of OO
development are different. The primary goal of OO development is to
provide maintainable software in the face of volatile requirements. So
OO development places emphasis on things like static structure (which
requires verbose but passive declarations), emulating problem space
infrastructure through abstraction, separation and encapsulation of
concerns, decoupling, and peer-to-peer messaging to solve problems.

That approach is not as intuitive as other approaches so it takes longer
to master. It also leads to more total code and OO applications usually
take a little longer to build. But the payoff comes in maintainability
when the requirements change. [Depending on whose numbers one cites,
50-70% of all software written is actually maintenance of existing
software. Hence maintainability becomes of great practical importance.]

*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH

Sponsored Links