View this PageEdit this PageAttachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide
Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007

Group Morph - Final design review (and some more)

Our critiques is on the final design of our project.

Throughout this course our designs have been tested by the changes we
have had to implement. Some of our design decisions were solid and
didn't have to be changed at all. Others required some serious
plumbing when changes had to be made. Here we discuss some of these
solid and not so solid decisions.

Our task was to build a program that would act as a filter for some
web content. There are clearly several functional units to this
program. Someone has to go out on the web and retrieve
information. Someone has to filter the information. Someone has to
format it for display. Someone has to manage UI.

The best way to come up with a good design is to look for real world
analogies to the problem, and so our first design ideas did just
that. We thought of having reporters that went out and fetched reports
of news from sites and editors that filtered content and formatted the
paper. We sort of stuck to that plan throughout the semester, but some
parts of the program got broken down into more detailed components as
we got deeper into the project.

Right at the beginning, we divided our group of 4 into two subgroups
that (more or less) worked on the same parts of the code throughout
the semester. One group worked on the Reporters and the web side of
things, and the other group worked on Display, formatting and the
UI. We still did all our work together though. As time went on and the
code became more and more complex, certain members in our group became
associated with certain objects in the program. People also took
charge of contiguous objects in the design. So you could draw a circle
around a group member's objects in the design picture. What this meant
was a minimum of communication was needed within the group to figure
out inter-object communication. This also meant the amount of
confusion was less than it might have been. The problem with this was
the interaction between objects that were controlled by the same
person tended to get sloppy and hackish (this is true at least of some
of my work), if you weren't careful.

Our first serious flaws in design had to do with the MVC way of doing
things. We misunderstood how MVC was to be implemented. The most
important thing to remember is that the model should have no clue
about the view. All communication from Model to View should be done
through dependent lists and changed messages. Each Model be hooked up
to the View by somebody else, possibly the person in charge of that
Model. Two of the models in our design were the NewsPaper and
NewsOption classes. One of the things I had trouble deciding on was
who should link the NewsOption class to its view? I could have
NewsPaper do it, but then it would have to know about which view was
being used for the options. This was solved by passing the NewsPaper a
handle ot the OptionView on initialization. This doesn't sound like a
good solution to me, and seems to suggest that we should in fact have
just one view per program. What I mean is only one View connection,
there can be multiple Views, but they should all connect to the same
model. The first change to the plan (the introduction of web
interfaces to the design) required some plumbing. Stuff had to be
moved from one class to another to ensure that the lines between Model
and View were clearly defined.

Another design decision we had to make had to do with the way
Reporters work. Our final solution was to have a NewsReporter class
that knew how to talk to the web, and subclasses that knew how to do
the details required of each site. The design of this part has
remained the same since it was first conceived.

We did have an interesting discussion on how things should work with
Reporters. A group member writes:

I think that how a Reporter builds an article from the website should be
able to be added in at runtime. That is, the user should be able to add
and delete NewsReporters WITHOUT having to write any SmallTalk code, and
without modifying the system. To accomplish this, how about a class
called "PluggableNewsReporter", which can be instaniated (a runtime
action) and initialized (again, a runtime action) such that the object
behaves like instances of our existing NewsReporters. The significant
difference (and source of the design benefits) arise from this dynamic
nature. Websites change. Websites are born and die. Being able to
accomodate for such changes is a definate plus.

How I originally proposed to implement such a concept was to give a
NewsReporter some blocks upon instantiation that tell it how things are
done. In order to fit the above design, these dynamic element need not
be blocks; it just seemed the most straightforward and easily
implemented approach at the time. Another was to would be to develop a
language which a naive user could learn and use (which would be easier
to use than SmallTalk), but that would require writing a new parser,
etc. to facilitate.

This was a very interesting idea. Smalltalk allows you to write code
on the fly (almost) with blocks. We stayed away from implementing
this, but by the end, our NewsReporter was sufficiently developed to
make passing it a block that gave it the intelligence to deal with a
site feasible. But the question is, where do you stop with programs
that modify themselves? You could extend the same idea to come up with
a program that could be instructed in not just how to deal with a
particular web site, but could be instructed on how to do
everything. You could have a program that started up as completely
generic, not having anything to do with NewsPapers. You run the
program and make it watch you go to a few websites and pick out
articles that you want to see. And then it does it for you the next
time. It's the same concept as the generic NewsReporter idea, taken to
the extreme. I think the line should depend on how usable the final
thing can be made, and what the price of this true generic nature is.

Other flaws in our initial design became apparent when we had to do
the stock ticker for one of the labs. We realized that the Stock
ticker had much in common with our NewsPaper (it talked to the web),
but our NewsPaper knew NewsPaper specific stuff, so we came up with
the Publication class that only knew how to deal with the web and talk
to reporters, and subclassed it to get the NewsPaper and
StockTicker. I've realized that it is very very hard to clearly
separate objects into the proper inheritance chain just by thinking
about how things should be. The best way to test a design (even before
you begin coding) is to come up with extreme situations in which some
part of your code can be reused. If you find that you can cleanly use
the parts that you need to from your existing program without any
overhead, you're golden.

Commenting helps. It really does. On a project of this scale, you even
forget what you had written at the beginning of the semester.



Another look at lab 9...




Reuse of Code:

Our lab 9 is a very good example of reuse of code. As, it required
for us to create a Stock Ticker. This required to parse html code,
so therefore Our class NewsReporter is used again as it is a generic
tool which uses the Html parser. Our design than changed so that we
added the Publication class which is able to handle different type of
applications that could be added to our basic program. In Our Stock
program, we just reused code of our NewsReporter so the hard part of
the program was already done for us.

Uploaded Image: stockreporter.gif


Link to this Page