<DRAFT>Coaches Manual

Fall 2008

Overview• Introduction to SDDTT• Team Composition

– Design Cell– Development Cell

• Rules for SDDTT Meets• Example Meet Schedule• UML Domain Model Tutorial (for Design Cells)

• Example Problems

• “The Broadening Participation in Computing (BPC) program aims to significantly increase the number of U.S. citizens and permanent residents receiving post secondary degrees in the computing disciplines, with an emphasis on students from communities with longstanding underrepresentation in computing: women, persons with disabilities, and minorities. Included minorities are African Americans, Hispanics, American Indians, Alaska Natives, Native Hawaiians, and Pacific Islanders. The BPC program seeks to engage the computing community in developing and implementing innovative methods to improve recruitment and retention of these students at the undergraduate and graduate levels. Because the lack of role models in the professoriate can be a barrier to participation, the BPC program also aims to develop effective strategies for encouraging individuals to pursue academic careers in computing and become these role models.”

-- NSF http://www.nsf.gov/funding/pgm_summ.jsp?pims_id=13510

• The BPC is composed of:– Alliances– Demonstration Projects

• Alliances are composed of a large number of universities all working together to achieve the mission of the BPC program.

• Demonstration Projects are smaller projects (efforts) that are aligned with Alliances

• The SDDTT is a Small Grant for Exploratory Research (SGER)

• It is hoped that the SDDTT will grow into a Demonstration Project and be adopted by one of the BPC Alliances

• The SDDTT– Underlying premise is that increased retention

(and recruiting) of women and African-American CS will comes has a result of developing stronger support/social networks between CS majors.

– The development of inter-university support/social networks between students and faculty will also result in increased recruitment/retention of women and African-American CS students.

• With this in mind, the SDDTT:– In not like the ACM Programming Contest– Is not a Programming Contest – Is primarily concerned with community building

between the students and faculty of the participating colleges and universities

– Is concerned with provide a venue that will allow all students to participate in and enjoy.

– Teams will compete against themselves rather than against one another

– Will have a number of winners rather than just one

• The SDDTT– Consist of:

• Three Meets• One Tournament

– The meets will all teams to design and develop solutions to a number of problems with a supportive, non-threatening environment.

– The Tournament will be similar to the other three meets with the exception that it will end in a SDDTT Banquet.

SDDTT Team Composition

• An SDDTT Team is composed of:– A Two Member Design Cell– A Two Member Development Cell

• The members of the design cell will develop the initial design of the software solution.

• The members of the development cell will then begin coding the solution based on the initial design.

• It is anticipated that all four members of the team continue to interact with each other during the design and development of the solution.

• SDDTT Team Composition– It is anticipated that the members of the Design Cell

will have less experience (in terms of their knowledge and understanding of Computer Science)

– It will be the responsibility of the Design Cell to develop the initial design of the solution in the form of a simple UML Domain Model

– It is hoped that the members of the Development Cell will be able to mentor/tutor/help the members of the Design Cell.

Rules for SDDTT Meets

SDDTT Meet Rules• Each team will be given a set of problems• Each problem will be assigned • A team’s score on a problem will be determined

by:– Whether the resulting software solution matches the

Domain Model developed by the Design Cell– The correctness of the software solution– The level of difficulty of the problem

• A teams total score will be the summation of the level of difficult of the problems successfully solved.

SDDTT Meet Rules (cont.)• The solution process for each problem must be started

by the Design Cell’s submission of an initial UML Domain Model complete with:– Concepts, and– Associations

• As the Development Cell begins coding the Design Cell will continue to work with the Development Cell to modify the Domain Model as needed.

• A team’s submitted solution must consist of:– The Software Solution– The Final Domain Model

SDDTT Meet Rules (cont.)• The Grading of a team’s solution will be as

follows: The number of points equal to the level of difficulty of

the problem (for a correct implementation)

* The number of points equal to the level of difficulty of

the problem * [1 - (the percentage difference between the objects in the implementation and the final Domain Model)]

Example Meet Schedule

Example SDDTT Meet

Host: North Carolina A&T State University

Building: McNair Hall

Time Event 9:00 AM - 12:00 PM Regular Team Competition12:00 PM - 12:15 PM Announcement of Team Results12:15 PM - 1:00 PM Lunch (Corporate Sponsored Event) and Socialization 1:00 PM - 4:00 PM Mixed Team Competition2:00 PM - 3:30 PM Coaches Symposium (Concurrent)4:00 PM - 4:15 PM Announcement of Overall Results of the Friendly (Corporate Prizes Awarded)4:15 PM - 5:00 PM Socialization with Corporate Representatives and

Directors (Feedback from Participants, Coaches, and Sponsors)

UML Domain Model Tutorial (for Design Cells)

• A Concept can be seen as a ‘baby’ object.• Below is an example of an ATM machine

concept.• Notice that the top part of a concept is the

identifier (name) of the concept.

ATM_Machine

• Concepts may also have Attributes associated with them.

• Below ATM_ID_Number and Amount_of_Cash are examples of attributes of the Concept ATM_Machine

Rule of Thumb: if we don’t think of something as a number or text then it is probably a concept.

ATM_Machine

ATM_ID_NumberAmount_of_Cash

• An Association can be consider as any relationship between any two concepts.

• For our domain concepts, we are only concerned with those relationships that are meaningful or contribute to a better understanding of the Domain Model in general.

• The task of discovering concepts is more important than the task of discovering associations. Therefore, more time should be spent on searching for concepts for Domain Models.

• Some Association Guidelines are:– An Attribute is a pure data value that a concept

needs to remember.– Concentrate on the associations that are important

and last for some amount of time (“need-to-know” associations).

– Concept discovery is more important that association discovery

– Too many associations could be bad.

• Some Association Guidelines are:– Avoid excess associations (redundant, derivable). – When naming an association use a typename-

verbphrase-typename format.– Association names should start with a capital letter

while the words of the association name should be hyphenated.

– Remember if something cannot be thought of as a number or text then it is probably a concept and not an attribute.

– However, if in doubt make the ‘thing’ a concept.

SaleRegister Records-current 0..11

association name multiplicity

-"reading direction arrow"-it has no meaning except to indicate direction of reading the association label-often excluded

Figure 9.12: An Example Association: Craig Larman’s, Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, 3rd Edition.

zero or more; "many"

one or more

one to 40

exactly 5

T

T

T

T

*

1..*

1..40

5

T3, 5, 8

exactly 3, 5, or 8

It is possible to indicate the multiplicity with respect to both sides of an association

Figure 9.14: Craig Larman’s, Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, 3rd Edition.

Domain Models

Consist of:

Concepts

Attributes

Associations

Register

Item

Store

addressname

Sale

date time

Payment

amount

SalesLineItem

quantity

Stocked-in

*

Houses

1..*

Contained-in

1..*

Records-sale-of

0..1

Paid-by

1

1

1

1

1

1

0..1

1

Captured-on

conceptor domain object

association

attributes

Figure 9.2: Craig Larman’s, Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, 3rd Edition.

• A common mistake when identifying concepts is to misrepresent a concept as an attribute. For example:

Team

Player1 Player2 : : PlayerN

Team Player Plays-for

1 1..65

Note: As a general rule, if we don’t think of something as a number or text then it is probably a concept.

• Domain Model Guidelines– List concepts via noun phrase identification.– Put the concepts together into a conceptual model. – Add associations.– Add attributes.

• When naming concepts – Use the more common name for a particular concept.– Only include meaningful and relevant features.– Don’t added stuff that isn’t there.

Example Problems

Example Problem #1Write a program to implement the game called Life, created by the British mathematician J. H. Conway in 1970. Life is really a simulation, not a game with players. It takes place on a rectangular grid in which each cell can either be occupied by an organism or not. Occupied cells are called alive; unoccupied cells are called dead. Which cells are alive changes from generation to generation according to the number of neighboring cells that are alive, as follows:

• The neighbors of a given cell are the eight cells that touch it vertically, horizontally, or diagonally.

• If a cell is alive but either has no neighboring cells alive or only one alive, then in the next generation the cell dies of loneliness.

• If a cell is alive and has four or more neighboring cells also alive, then in the next generation the cell dies of overcrowding.

• A living cell with either two or three living neighbors remains alive in the next generation.

• If a cell is dead, then in the next generation it will become alive if it has exactly three neighboring cells no more or fewer that are already alive. All other dead cells remain dead in the next generation.

• All births and deaths take place at exactly the same time, so that dying cells can help to give birth to another, but cannot prevent the death of others by reducing overcrowding, nor can cells being born either preserve or kill cells living in the previous generation.