[Csped] UML Diagrams and Use of Object Orientation on this Project

[John Howland]

Dear Class members,

During class yesterday, there was discussion (some what pointed)
about UML Diagrams and whether or not an Object Oriented implementation
of this project is appropriate.  Some of this discussion is coming a bit
late in a more proper timeline for this project and should have been
brought up earlier by you or me.  I assumed that the UML you learned as Sophomores
was the same as the UML Dr. Pitts and I had taught in past years.
However, that was not the case and some of you spent time struggling
with what an Analysis Diagram was as you worked on the second iteration
of design diagrams for the emulator problem.

UML is a rapidly evolving design methodology which, though
widely used, is certainly not universally accepted.  The question about
my requirement of Use Case, Analysis and Class diagrams left you
wondering what Analysis diagrams are.  When you Google UML Analysis
Diagram, you don't find a clean hit.  Links such as:

http://www.dotnetcoders.com/web/learning/uml/default.aspx

show 9 standard UML Diagrams in UML 1.4, none of which includes
analysis diagrams.

UML 2.0

http://www.omg.org/cgi-bin/doc?ptc/2003-08-02.pdf

has little mention of analysis diagrams in its 640 pages.

http://bdn.borland.com/article/images/31881/Together_White_paper__.pdf

gives a brief summary of what is in the newly approved UML 2.0 .

Dr. Pitts and I have used earlier versions of UML in which analysis
diagrams are closely related to Use Case diagrams.

See an example in:

http://www.cs.trinity.edu/~jhowland/class.files.cs4285.html/new-uml-slides/

particularly the teller examples

http://www.cs.trinity.edu/~jhowland/class.files.cs4285.html/new-uml-slides/uml08.jpg
http://www.cs.trinity.edu/~jhowland/class.files.cs4285.html/new-uml-slides/uml09.jpg

Other modeling strategies include:

http://www.agilemodeling.com/
http://www.extremeprogramming.org/
http://www.dsdm.org/
http://www.controlchaos.com/

As I said, above, there is not universal acceptance of a single analysis/design/implementation
methodology.

Now, about our design problem.  I have been following the majority (of instructors who have
taught these PED courses -- Drs. Pitts, Lewis, Massingill, Bateman, and Konstam) in suggesting
the use of UML.  UML pretty much forces one in the direction of an object oriented implementation
in some object oriented language which may be associated with a UML IDE.  This may not be
particularly apropos for the MC 68020/68881 emulator problem.  Let me clarify by saying that
it is not imperative to construct an object oriented implementation.  It could be done, for example,
by using objects/classes for each component part of the machine.

For example, a memory object (an array of bytes) which has read and write methods,
an instruction fetch object which has an instruction register and a fetch method,
a pc object which has the pc register and an increment method,
an instruction class which has subclasses for each instruction class each of which
has instances of each separate instruction in that class of instructions and has
an operation method, etc.

But it is also easy to design elegant non-object based emulators which have functional
models of each component part of the system, including function representations of
each instruction.

I do not care which approach you take, but you must be methodical in your approach.

Your initial UML diagrams only considered top-level user interaction with the emulator
and no detail of the emulator itself.  I asked for a second go-around on these which
was due yesterday and they still, for the most part, lack detail design information
of the emulator itself.  Remember I said user interaction facilities could -- rather
-- should be crude command line capabilities using stdio with file i/o using 
io redirection.  Spend your time on the emulator; thats where the hard work should be
done.

John

-- 
_______________________________________________________________
John E. Howland       url: http://www.cs.trinity.edu/~jhowland/
Computer Science    email: jhowland at ariel.cs.trinity.edu
Trinity University  voice: (210) 999-7364
One Trinity Place     fax: (210) 999-7477
San Antonio, Texas  78212-7200