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


Ectropic Design

Ectropic, the opposite of Entropic, is the creation of order from
chaos. The goal of the Ectropic Design project is to provide a tool
for Squeak programmers that will aid them in creating an orderly
design process from the chaos of the vast open-source (i.e. everyone
can contribute) environment. Mark Guzdial is leading the creation
of this design tool. I am currently working on a small portion of
this design tool (heretofore referred to as Ectropic).

There are several parts currently to Ectropic. The first is the
design of the project. You can read more about the design at The other parts are a backend that
holds all the information and two different user interfaces that
help to manipulate this information. For this semester I hope to
finish much of the back-end of this project. Hopefully I will be
working on the user interfaces for Fall Semester.

The UML is here UML and will be good to look at before reading on.

The back end of this project can get quite confusing (at least it
confused me ). The reason for this is that the back end design
combines three things that you should be familiar with. The first
are design techniques: CRC Cards and UML Diagrams. The last is the
actual Squeak code that will map to these designs. This means that
in creating the back end we have merged all the parts of these three
things into one cohesive unit. Listed here are the Objects in the
project, and where they originally came from.

1. Code
   a. Classes
   b. Methods
2. CRC Cards
   a. Responsibilities
   b. Goals
   c. Scenarios
   d. Episodes
3. UML Diagrams
   a. Relationships
     i.advanced feature probably not to be implemented until fall.

Most of these objects are much as you would expect them to be. As
you know however, CRC Cards are really just a design/primitive form
of Classes. So to understand this design you must understand how
Methods, Responsibilities, Goals, and Scenarios are related. I will
try to explain this to you.

We start with Goals. You should be familiar with goals from your
experience with CRC cards. These are the goals of your project.
These goals should, when put together, describe everything you hope
to accomplish with your project. At the start these goals should
just be a list, but once you are finished these goals should all
have sub-goals, and those goals should then in-turn have sub-goals
until each goal is a small manageable unit of your program. Goals
are here just to give your project a well defined direction.

From Goals we move to Responsibilities. Responsibilities are the
only objects that Goals are directly related to. Each
Responsibility should have a single goal. Goals do not have to have
responsibilities, but enough goals should have responsibilities as
it takes to make your project run. Please see the following

In these diagrams the boxes represent Goals and the r’s represent
Responsibilities tied to those goals.

A is a valid example, since there is a way of combining
responsibilities to accomplish the overall goal. While this is not
a good idea, since your Responsibility is probably to vague, it is
allowed by Ectropic. C however is invalid since you cannot fulfill
the overall goal due to your inability to fulfill the right-hand
goal. B is valid, and is an ideal case, since only leaf nodes are
tied to responsibilities.

I will skip the description of what CRC cards are and what Scenarios
are as these are described in most any book on UML/CRC design.
Please refer to “Squeak” by Mark Guzdial to see the definitions I am

Next we cover Episodes and Classes, and then finally Methods.

Episodes represent a single step in a Scenario. Each Episode should
be able to be accomplished by a single Class. Episodes can have
multiple Responsibilities, but each Responsibility with have only
one Episode.

Classes are a sub class of CRC Cards. It is encouraged that you
derive them from CRC cards (there will be a function to do so in the
back end and a button on the GUI), but it is not required by the
code. Each Class will have multiple Responsibilities and Methods.
As with Episodes, Responsibilities and Methods will have only one

Methods will have a Class and a Responsibility. Each Method should
meet its Responsibility for its Class. A Method CANNOT have a
Responsibility that is not contained within its Class.

Link to this Page