giddy@trl.oz.au (David Giddy) (01/17/91)
Hello fellow OOer's,
I would like to generate some discussion on the subject of developing
object oriented systems with more than a single programmer working on the same
system.
I would like to hear of others experiences in developing large systems
and how they divided work, defined interfaces and handled problems of ensuring
that a system was compilable while several people worked on various parts of
the system simultaneously.
We are in the process of starting development of a significant sized
system (around 10 staff years). We have chosen Eiffel as the development
environment for it's conceptual elegance, strict typing and good libraries. We
are in the process of system analysis and design and will be shortly in
a position
to start coding.
Being large, we have broken the system into many clusters of classes and
have tried to keep the interactions between clusters to a minimum. The
question we
now face is how to divide work amongst programmers and how much specification
of clusters is necessary before initial prototyping can begin. This is the area
where I am most interested to hear others experiences.
Out project team consists of around 7 programmers, two of whom are
located in another state! This last constraint makes clean division of work
essential and is an area in which I am looking for ideas.
I am looking forward to hearing the net's opinions on this area as I
don't believe it has been discussed much to date.
Regards,
David.
P.S: Our News system is being a bit slow at present (we are a dial up site), so
I may not see your replies for upto six or seven days, so please be
patient
for any response from me (Email is much quicker).
______________________________________________________________________________
David Giddy,
Telecom Research Laboratories, P.O. Box 249, Clayton, VICTORIA 3168, AUSTRALIA
Voice: +61 3 541 6388 Fax: +61 3 543 1944 Email: d.giddy@trl.oz.aupaj@mrcu (Paul Johnson) (01/18/91)
David Giddy (d.giddy@trl.os.au) asked for experiences in multi-person projects in OOP. The year before last I worked on a project in C++ with two other people. It was the first time we had used C++ on anything more than "Hello World" programs, although we were fluent in C and had used module based languages as well. I think the things we did right were: - We divided the work into three broad areas. Each person had one area and was responsible for the design and functionality of that area (mirroring the modular programming paradigm). - Everyone helped design the general architecture. This ensured that a) we got the benefit of three brains instead of one, and b) everyone understood how the system was supposed to work. - We had frequent meetings to hash out details of the interfaces. This seemed to work better than a top-down, waterfall style of cluster design. - We used SCCS. On any kind of multi-person project this (or its cousin RCS) is invaluable. It stops people editing the same file at the same time and it allows you to unwind from mistakes. Eiffel does not support SCCS or RCS, so you will have to fix up shell scripts or (ugh) Makefiles instead. Try and get this kind of substructure sorted out before you begin. Given that you are so split up, you are going to have to ensure high bandwidth communications between your 5 and your 2. I assume you have email between the sites. Try and get multi-way phone conference facilities and make it easy for anyone to set up or join a conference. Look into setting up a private newsgroup as well: that might be simpler than a mailing list. I think you are going to have to set up some ground rules to ensure consistency between your sites. Probably some kind of semi-automatic update propogation system will be needed. Again, think about this and sort it out first. I think that this is probably more important than detailed design documents (which we didn't have and didn't miss). Of course, we did not have the distribution problem. Good luck, and let us know how you get on. Paul. -- Paul Johnson UUCP: <world>!mcvax!ukc!gec-mrc!paj --------------------------------!-------------------------|------------------- GEC-Marconi Research is not | Telex: 995016 GECRES G | Tel: +44 245 73331 responsible for my opinions. | Inet: paj@uk.co.gec-mrc | Fax: +44 245 75244
tma@osc.COM (Tim Atkins) (01/25/91)
I'll briefly throw my two cents in here. The interesting and difficult part of multi-programmer OOP is precisely the part that is not logically divisible into independent projects. I recommend placement of the strongest design talents on the design of this common base of classes. Those portions of the system that are independent can proceed by whatever schedule and amount of up-front analysis/design is amenable. All using groups must have input as to what they need of the commonly used set of abstractions though. As in normal development, agreement as to inter- face is the paramount consideration. Once this has been agreed the actual developers of this critical layer are much freer using OO to change the actual architecture as long as the interface is preserved. I have some difficulty believing that too much analysis is called for, particularly in OOP. Just enough to identify common problems and abstract out the essential portions seems to be right. To do this well places a high premium on more than one individual having a good working knowledge of the entire design. One such individual is crucial to the coherency of the system. Two or more are likely to make it a much cleaner design as they will catch each other's oversights. Perhaps the most difficult part of OO is that it is much more essential than in more traditional approaches that ALL team members are aware of the classes and their methods as only such awareness can drive the tightness of the design and the achieving of maximum reuseability. Such awareness must be tightly separated from issues of responsibility if the project is not to bog down in endless committee reviews. As a long time designer and implementer I am also highly aware of the fact that a paper design is next to worthless as a specification compared to at least a skeleton of working code. The really subtle at design time is glaringly obvious once a bit of code is actually written. I would strongly recommend a technique of lots of early prototyping and an incremental development strategy. - Tim Atkins
jguy@lilith.EBay.Sun.COM (Jeff Bone) (01/26/91)
Just a (LONG) random $0.02 comment:
An interesting example of a shared OOP environment can be found in
the game "MOO". MOO is one of a family of games called "MUD", or
multi-user dimension --- "MOO" is an acronym for MUD object-oriented.
---------------------------------
MUD (and MOO) for the uninitiated
---------------------------------
MUDs resemble text adventure games with the exceptions that (a)
multiple users play and interact within the game world and (b) the
game world is usually extensible from within the game itself. The
more sophisticated MUDs (MOO is currently state of the art) allow
you to program complex behaviors on the objects within the database.
The various different flavors of MUD allow for various levels of
programmability in various languages --- among them C-like languages,
Forth-like languages, Lisp-like languages... MOO itself has a C-
like appearance on the surface, but is actually quite OO...
Additionally, MUDs have varying degrees of extensibility. Some MUDs
are actually "meta MUDs" --- the server itself simply provides the
database engine and programming environment and the rest of the game
(including in some cases the input parser --- not to be confused
with the language parser) is implemented in the server language
itself. MOO and Ubermud are examples of "meta MUDs".
-----------------------------------------
MOO as a multi-programmer OOP environment
-----------------------------------------
From the "Introduction to MOO" document by Stephen F. White, the
creator of MOO (the whole document is available via anonymous FTP
from belch.berkeley.edu as ~ftp/pub/moo/moo2.0.doc.ps...):
"One of the most powerful features of MOO (and that from
which it derives its rather silly name), is the object-
oriented programming metaphor known as inheritance.
Simply put, inheritance means that an object "inherits"
properties and functionality from another object. For
example, a brown paper bag might inherit the verbs 'put
in' and 'remove from' from a generic object "container".
The "parent" of an object is the object from which
it inherits functions (verbs)...
"In MOO, there is no distinction between objects and
classes. All classes are objects, and any object may
be instantiated to become a class.
"Objects inherit properties and verbs from their
parents. ... Verbs are the functions, or "methods"
(in o-o speak) which the object has. They determine
what behaviour an object is capable of performing. The
verbs in MOO are programmed in the MOO language ...
"Thus, a player may create an object, give it some
properties and verbs which may be used to manipulate it,
and then leave it in a public place for others to peruse
or instantiate (make copies of). The permissions on an
object determine who may instantiate what objects...
"Since MOO keeps track of what objects are instances of
what other objects, you may also dynamically add properties
and verbs to existing objects. For example, if you decide
to add the verb 'smash' to your 'precious ming vase' object,
all instances of that object will immediately inherit the
new functionality."
And so on... the MOO environment was designed expressely with the
multi-programmer concept in mind.
Note: MOO is a game and not a software development environment per
se.
--------------------------------------------------
Neat! Where do I find out more? How do I do MOO?
--------------------------------------------------
The definitive site for MOO code, examples, and documentation is
belch.berkeley.edu. There is also a variant version of MOO (the
"lambda" version) available at belch with various functional and
cosmetic differences from "original" MOO.
The MOO code is currently not in a stable release state --- it's a
tinkerer's toy right now. Also, there are not yet any published,
"live" MOO sites though I know of at least one which is nearing
completion... for information about the availability of live
MOO servers and other MUD topics, explore the archives on belch
and/or read the USENET group rec.games.mud... Be forewarned:
there's a significant social aspect to MUDding and a whole subculture
has evolved, so most of the postings in r.g.m are rather obscure to
the novice and deal with non-technical issues.
Anyway hope this proves at least interesting to you all... good luck
and let's hear any comments or observations any of you may have
about the technical aspects of MUDs/MOO and/or it's relevance to
OOP or other programming and systems issues in general.
Yrs,
--
--- jbone@Sun.COM ---------------------------------------------------
------------------------------------------------------ Jeff Bone ---
--
#include <std.disclaimer>
Note: My work at Sun does not involve MUDs or MOO... this is my own
thing, so to speak...