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

Milestone Three

Fall2002 M3 - Design the whole thing


Foreword:

Programming is separated into two sections: theory (abstract) and applied (concrete). Designing is considered theory, and coding is considered applied. One of the main purposes of this class (CS2340) is to teach that theory is important, that concrete ideas need an abstract base to work from.

Advantages of theory: Many ideas can be designed faster than they can be coded. This is because people can "mentally picture" the missing concrete details, while computers require absolute concretion and thus require every small detail (syntax/semantics) to be correct before working. The existance of time restraints raise the importance of theory. This is due to the coders wanting the highest chance possible that a each design they choose will work: since a design that cannot be coded can result in waisted coding time. In most cases, a design that can be backed with a sound theory has a higher chance of transfer to code (as opposed to a design that is not backed with a sound theory).

Disadvantages of theory: The act of being able to mentally picture an idea as working, in no way affects said idea's inherent ability to exist (work) in reality. A case example for this: many people that read fiction claim they can hear the character's voices, and see the character's environment (mentally picture sight and sound) – despite that these fiction books contain only words made of ink. The books remain fiction, even though people have mentally pictured the fiction as reality. Similarily, people can mentally picture a program design, even if it is logically flawed and therefore cannot exist as working code.

Summary of foreword: The ability to create a sound design is important. Having a design also increases team communication, since the team has a higher chance of mentially picturing the same coding structure if said coding structure exists in some form (in design or in code).


Introduction:


In M1, the specifications are to code, individually
In M2, the specifications are to design and to code, as a team
In M3, the specifications are to design and not code, as a team

In M1 and M2, being able to code the milestone without a finalized design can be considered both a crutch and a hinderance to accepting the importance of a sound design. Since M1 did not require a design, a successful completion of M1 can reinforce that designs are uneccessary. Since M2 did not require a design until the entire milstone's due date: teams can reverse engineer the design after they complete coding for M2.

M3 requires the team to think ahead of a coding structure for the rest of the semester. Since there is not enough time in M3 to code the rest of the semester and then write the design, this is the first milestone that emphasizes the importance of a good design. However, since no coding is involved, students are still likely to percieve a sound design as merely a grade requirement (as opposed to also being a useful tool).


Grading breakdown:


15% Good, believable scenarios that touch on every class in the system.
15% Good CRC Card Analysis: Reasonable names, understandable and clearly defined responsibilities, good exploration of other class names
10% Good test plan: equivalence classes clearly identified, test cases clearly defined.
20% Good UML class diagram and descriptions: Correct usage of notation (10%), detailed and understandable descriptions and names (10%).
20% Quality of the design
10% Clear definition of team member responsibilities: Can you tell who will do which pieces of system (as defined in UML and descriptions)? Will you be able to figure out whose part failed if there's a failure?
10% Believable and detailed group timeline: Could someone figure out from this what they're supposed to be doing each week? Can a team member figure out what they're supposed to have done each week from this?


Good, believable scenarios that touch on every class in the system:

The following two newsgroup posts should give you all the information you need to know about scenarios

Helpful post #1

Mon, 04 Nov 2002 08:13:02 git.cc.class.cs2340 Thread 173 of 202
Lines 26 Re: Scenarios RespNo 1 of 1
Lex Spoon at College of Computing, Georgia Tech

Newsgroups: git.cc.class.cs2340

You can limit the scenarios to those for the milestone, if you want.

Scenarios should not mention specific classes. If you follow the
standard 2340 design process, it would go like this:

1. scenarios
2. CRC cards
3. UML class diagram
4. implementation

Thus there should not be any classes defined when you do the scenarios.

Another way to look at the situation is that scenarios provide a
sketch of the program requirements. As part of the requirements, they
should avoid talking about portions of the solution.


Like many things, scenarios are incredibly simple once you see what
they are.... You are almost certainly already using them, in fact.
Whenever you are in a group meeting and say "suppose our user looks up
Santa Claus, who isn't in any database we support", you are defining a
scenario. Whenever you say "this design fails on Santa Claus
lookups", you are taking advantage of that scenario.


Lex>>

Helpful post #2

(please note that the original post contained two asterisks around the word "typical", that I change to quotation marks because the co-web considered the asterisks as a code tag)

Wed, 02 Oct 2002 15:29:59 git.cc.class.cs2340 Thread 113 of 202
Lines 39 Re: M3 - scenarios RespNo 1 of 1
Lex Spoon at Georgia Institute of Technology

Newsgroups: git.cc.class.cs2340

James Earl Kim writes:

> Although I've looked at scenarios in the Cases page, I'm still confused
> about what we're being asked for in M3. Are scenarios similar to use
> cases? I made a scenario for M5; feedback is welcome.

Incidentally, there is a lecture associated with the class. Some
people find it very helpful to hear an experienced professor describe
what is going on, though though most others claim that it is more
valuable to stay up late playing computer games.


Very briefly, a scenario is an example usage of the system in story
form.

Scenarios are easy to work with once you see what they are, because
you are surely doing it anyway. Any time you say "suppose there is a
person with twelve children, and one of them marries their second
cousin, and then blah blah blah", you are using a scenario. Make a
note to yourself about them and then have someone write it out in
longhand outside of the group meetings.

Here are a few things to watch for in your scenarios:

1. They should not have lots of if-then statements. Describe
one "typical" scenario at a time, and save the details for
the requirements.

2. They should cover all of the major requirements.



Lex


PS – I'm not sure what the currently popular terminology is, exactly.
Some people say that a scenario encompasses a number of use cases (or
is it vice versa?). The exact terminology isn't important for this
class.>>

scenarios summary: pick a specification of your milestone and write a narrative on how your team wants a user to fulfill said specification.


Good CRC Card Analysis:


CRC cards are explained in the textbook "Squeak: Object-Oriented Design with Multimedia Applications" by Mark Guzdial, on pages 91-94. CRC cards are also explained in the CH4-DESI powerpoint presentation design lecture slides link

For the CRC cards, each team member created their own idea of how the project should be implemented, so each team member wrote thier own CRC cards (on 3X5 index cards), then the CRC cards were used to explain each implementation idea to the rest of the team.

The CRC cards then needed to be photocopied. The CRC cards were written on pencil, and many of the photocopiers on campus cannot copy dark enough for the pencil to be legible. The best photocopier for copying pencil is in the Architecture library ("located in 75 College of Architecture-West Wing") design campus map link


Good test plan:

test cases example is an example of part of the test plan. The test plan did not appear to have any formal structure to it, so the structure used in the above link was considered good enough to use. The test cases were random, since the team was not far enough into the CS2335 class to learn how to use control flow graphs/white box testing/black box testing: to create good test cases. Consideration was used to attempt and find all the test case types regardless.



Link to this Page