CSC 335: ObjectOriented Programming and Design

1
CSC 335 Object-Oriented Programming and Design
Presentation 9 A Process, Design, CRC Cards and
Role Play
2
Object-Oriented Design

• Our approach will be to
• partition the problem into objects
• determine the responsibilities of the objects
• determine the instance variables and methods for
  classes so we can make the objects
• determine how instances of these classes interact
  (send messages to each other) to carry out their
  responsibilities

3
Artifacts Documents, Code, Doodles

• Use cases (like previous handout)
• List of Concepts (as done in section)
• a representation of the concepts (objects) in the
  problem domain such as Course, Student,
  CourseCatalog
• just get a basic understanding
• find the obvious concepts
• defer deep investigation
• CRC Cards (coming up)
• Class Diagram (hinted at and coming up)

4
Concepts, Classes or Chunks

• Start by partitioning a system into chunks
• These chunks may be represented as models that
  describe the abstract essential aspects of the
  system
• Model Describes and abstracts essential parts of
  a system, provides an abstract view of the system
• We'll use the UML to describe the chunks

5
Artifacts

• Models are composed of artifacts
• diagrams and documents that describe things
• e.g. 1) use case diagrams 2) class design
  document
• Models and abstraction are used throughout the
  development process
• dynamic models represent functional aspects as in
  sequence diagrams
• static models such as class diagrams capture the
  structure of the solution

6
Analysis Document that are Done

• Some things done for Course Registration System
• Use cases (handouts from Thursday's class)
• List of concepts
• Some class diagrams with
• some associations
• a few attributes (instance variables)
• behaviors (methods)
• Still could be done
• A specification (need to simplify original spec)
• A modified use case (to simplify original spec)
• A picture of the interface when the student
  registers
• Sequence Diagram

7
Collaboration Diagrams

• Question How are objects going to do what we
  believe the system should be doing?
• Answer In a variety of ways such as 'Design by
  Coding'
• UML can capturing how objects accomplish their
  task

8
Interaction Digrams

• Interaction diagrams indicate how objects
  interact via messages
• At this point we need (and we have)
• a conceptual model from which to get objects
• to know what the system must do
• use cases to glean information from
• There are two kinds of interaction diagrams
• Collaboration Diagrams illustrate objects in a
  graph format
• Just look at an example
• Sequence diagrams show messages on a time line
• Should build at east one

9
Example

• Sequence Diagram

Credit
Accounts
System
Customer
Authorization
Receivable
Service
requestApproval(request)
handleCreditReply(reply)
addApproval(reply)
10
Example

• Collaboration Diagram

msg1()
1 create()
Sale
sl SalesLineItem
SalesLineItem
2 add(sl)
SalesLineItem
11
Design

• Artifacts that can be created during Design
• CRC Cards
• Assign responsibilities to objects
• Design Class Diagram
• Show class definitions (instance variables and
  methods)

12
We'll follow this process roughly

• Analysis identified candidate classes to model
  (shape) the system as a natural and sensible set
  of abstractions
• During design determine the the main
  responsibilities of each candidate class
• what an instance of the class must be able to do,
• and what each instance must know about itself
• Determine the collaborators (helpers)
• To help complete its responsibility, an object
  typically delegates responsibility to other
  objects.
• These are called collaborators

13
We'll use these object-oriented tools to help
develop the system

• Considered nouns as candidate objects
• Scenarios
• what happens when
• Role Playing
• team members become the object
• Component/Responsibility/Collaborator CRC cards
• documents class name, responsibilities, helpers
• Here is the specification the system again

14
Reduced System Specification

• As the head of the information systems for
  MooseFalls College, you are tasked with
  developing a new student registration system. The
  new system will allow students to register for
  courses and view report cards from personal
  computers attached to the local area network. Due
  to budget cuts, you cannot afford to implement
  the entire system.You will continue to use the
  existing course catalogue containing a list of
  course offerings for the college. Information
  about each course, such as instructor, department
  and course number, schedule day and times
  prerequisites, will need to be added to create a
  semester schedule so students can make informed
  decisions.

15

• This new system will allow students to select up
  to 19 credits as long as there is an open seat in
  the open course and the prerequisites have been
  satisfied and there is no scheduling conflict A
  student must be able to create a new schedule,
  update an existing schedule, which may be empty
  at first., or delete an existing schedule. For
  each semester, there is a period of time in which
  students can change the schedule. At the end of
  this time, when the registration closes, the
  registration system sends information to a
  billing system so the student can be billed for
  the semester. Instructors must be able to access
  the on-line system to indicate which courses they
  will be teaching. They will also need to see
  which students have signed up for their course
  offerings.

16
Prototype

• It can prove useful to draw a picture of the user
  interface
• Can be a sketch
• But it just so happens., Rick has a system almost
  working
• Next slide shows one possible interface
• And Rick could demo a system if you desire
• Missing
• Does not check for time/day conflicts
• Does not allow the user to logout or new students
  to login

17
One possible view Student Modifies schedule
18
Identify candidate objects

• Possible concepts (objects, candidate classes)
  that model a solution (after eliminating some
  possibilities)
• Course
• CourseCatalog
• CourseOffering
• ScheduledCourse
• SemesterSchedule
• Student
• Schedule

19
Role Playing and CRC card Development

• A team can act out scenarios
• helps determine what each candidate object is
  responsible for
• helps understand the system
• develop documentation to capture analysis helps
  and design decisions
• helps develop algorithms
• We'll skip this step for project 7 and just
  write a class diagram model

20
CRC Cards

• But here is a mention of CRC cards (in Day 10)
  Component/Responsibility/Collaborator cards
• could be a piece of paper or a 3x5" index card
• contains information about the classes identified
  as potential parts of a solution
• class name
• action responsibilities
• knowledge responsibilities
• helpers (classes that help the class do its
  thing)

21
A CRC Card

• The front of a CRC card looks like this

22
Scenarios

• Scenarios
• A scenario is the answer to the question "What
  happens when?"
• Students could now play the role of objects
• make up your own scenarios or try this
• User wants to add a course

23
Assigning Responsibilities

• Responsibilities
• What an object should be able to do
• do something itself
• delegate responsibility (send messages) to other
  objects
• control and coordinate activities in other
  objects
• What an object should know
• private state
• storing references to related objects

24
Assigning responsibilities

• CRC
• CRC card development is an important artifact
• Skillful assignment of responsibilities is
  important
• Should spend a lot of time assigning
  responsibilities
• Patterns and guidelines can be applied to improve
  the quality of your design
• So what is a pattern?

25
Patterns

• Pattern A named description of a problem and a
  solution that can be applied in many contexts
• Example
• Context You are trying to determine who should
  be responsible for deciding whether a student can
  add a course
• Solution Assign the responsibility to the class
  that has the information to fulfill it
• Pattern Name Expert

26
http//my.execpc.com/gopalan/design/behavioral/me
diator/mediator.html Gopalan Suresh Raj

• But does Student have the knoweldge
• There is another pattern that may be better
• Mediator is a behavioral pattern. This pattern
  helps to model a class whose object at run-time
  is responsible for controlling and coordinating
  the interactions of a group of other objects. It
  helps encapsulate collective behavior in a
  separate mediator object. Mediator promotes loose
  coupling by keeping objects from referring to
  each other explicitly, and allowing the designer
  to vary their interaction independently. Objects
  dont need to know about each other, they just
  need to know their Mediator. Mediators are
  generally used where complex protocols must be
  managed, and when centralized access points are
  desirable. Thus, as defined by Gamma et al, "A
  mediator serves as an intermediary that keeps
  objects in a group from referring to each other
  explicitly".

27
See simple view of design pattern

• From AG Communications, Phoenix
• http//www.agcs.com/supportv2/techpapers/patterns/
  papers/patexamples.htm

28
Find a pair programming partner

• Next project is due October 25th
• Can start immediately
• I recommend Course, CourseCatalog,
  ScheduledCourse, SenesterSchedule by Sunday
  (13-Oct)
• Your partner must be from you section