CSC 335: ObjectOriented Programming and Design

1
CSC 335 Object-Oriented Programming and Design
Presentation 8 Intro to OOA and a Software
Development Process
2
Outline

• Software Development Process
• Introduction to Object-Oriented Analysis
• Actors and use cases
• Sequence Diagrams
• Concepts
• Building the domain model
• Preview of Project 5

3
A Development Process

• A development process describes a possible order
  of activities during software development
• We will use an informal process that is
• separate from UML
• a convergence of several development processes
• only one of many development processes
• Spectrum of software development processes

Lightweight Agile Processes Code is
documentation, 1996...
Heavyweight, plan driven process Lots of
documentation and UML
- Rational Unified Process (RUP) - Capability
Maturity Model (CMM)
- Extreme Programming
- Scrum
4
Analysis and Design

• Analysis is about understanding
• investigate the problem (why and what)
• Design is about making decisions
• come up with a solution (how)
• OOAD does analysis and design from an
  object-oriented perspective

5
Analysis
Design
Construction
Investigation of
Logical solution
Tests and Code
the problem

• During Analysis
• find and describe the objects (concepts)
• During Design
• define logical software objects that will be
  implemented
• During Construction (implementation)
• test, implement, and integrate modules

6
Start a Business/Build OO Software Analogy

• Start a Business
• 1. What must be done to keep the business
  running
• sales, pay bills, build software, maintain
  delivery vans, ...
• 2. What are the roles in the organization?
• sales reps, customers, software engineer, ...
• 3. Who is responsible for what? How do they
  interact?
• Object-Oriented Analysis and Design
• 1. Requirements analysis -- what is needed
  Day 9
• 2. Domain Analysis -- understand the problem
  Day 9
• 3. Responsibility assignment, interaction design
  Day 10

7
Iterative Development

• The iterative aspect cycles through small sets of
  requirements
• analysis, design, construct (write tests and
  production code) for each iteration
• Each iteration can be confined to a limited time
• Could build a system with limited functionality
• Repeat with additional features
• Our next project will be designed this way
• two or more iterations (see page 206)
• each iteration will complete several features
• see progress continuously
• allows constant feedback

8
Analysis and Design

• Analysis and Design are on a continuum
• During analysis
• team tries to understand the problem
• During design
• team considers how the system will get built
• Avoid implementation until you have an
  understanding and some design

More design-oriented
More analysis-oriented
- what
- how
- requirements
- logical solution
- investigation
of domain
9
Process ! UML

• One possible process
• 1. Define use cases requirements analysis
• 2. Define conceptual model find the concepts
  (objects)
• 3. Define collaboration diagrams how objects
  interact with others
• 4. Define design class diagrams to be translated
  into Java

10
Object-Oriented Analysis

• OO Analysis using an object-oriented approach to
  understanding the problem
• The deliverables
• Understand the problem domain and its
  requirements
• Artifacts such as design class diagrams and
  sequence diagrams to describe interactions
  between objects

11
Use Cases

• Use cases
• Narrative descriptions of processes that need to
  be carried out by the system in relationship with
  "actors" outside the system
• Examples of actor A user, a computer, a data
  base
• Makes us think about and understand how users
  will use the system

12
Creating Use Cases

• Writing Effective Use Cases
• Identify actors
• Create a list of uses cases
• Define the sequence of events for each use case
• Model the use cases with sequence diagrams

13
College Course Registration System

• OOPin21 Uses an Online Web Store
• This was assigned reading for today
• This presentation will use a college course
  registration system
• The spec is on the next page

14
Course Registration

• 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 prerequisites, will need to be
  added to create a semester schedule so students
  can make informed decisions.

15
Course Registration

• 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. A student must be able to create a new
  schedule, update an existing schedule, 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.
• Note These rules may differ from your
  experiences. They are particular to MooseFalls

16
Identify Actors

• An actor is anything that interacts with the
  system
• Can be a user, a computer, a credit card company
• Consider
• humans who will use the system
• other systems that communicate
• database
• network
• other stimuli
• the clock strikes midnight

17
List Actors

• Actors
• Student
• Registrar
• Course Catalog
• Semester Schedule
• Instructor
• Billing System

18
List Preliminary Use Cases

• Some use cases
• Login (see use case 3 on handout)
• Register for courses (see use case 6 on handout)
• Create Semester Schedule
• View Report Card (see use case 9 on handout)
• View student list
• Close Registration

19
Draw a Use Case Model subjective
View report Card
Register for Courses
Student
Create Semester Schedule
Data base of Course Catalog, Semester schedule,
and students
Login
View Student List
Instructor
Close Registration
Registrar
Billing System
20
Refine Use Cases

• Instructors and students can Login
• We'll start with this one
• A use case has several elements
• Use case name
• Numbered sequence of events
• Alternatives
• Pre-conditions
• Post-conditions
• Formats do vary

21
Look at Use Cases

• Read some use cases from MooseFalls
• See attached used cases

22
Sequence Diagrams

• A sequence diagram
• models the interactions between the actors and
  the system over time
• Represents events between actors
• Time goes top to bottom

23
Example

• Sequence Diagram for student login

Registration System
Student
Ask for name and password
Enter name and password
Validate user
Inform user login successful
24
Domain Model

• Use cases help capture the concepts in the system
• These concepts may become objects
• Write concepts in rectangles and you have a
  preliminary domain model
• May add attributes and responsibilities
• Will do this later for the College Registration
  system
• Lets' consider the next project

25
Dice Game Example

• Next Project is a dice game
• Due next Friday _at_ 600 (11-October
• Goals
• Analyze and design a relatively small system
• Practice test-first design
• Build a model, then a GUI, then repsond to events
• Become more comfortable with event driven GUIs
• Good practice for the midterm
• Learn how to add a menu with menu items
• Specification on next slide

26
Dice Game Specification

• Design and implement a dice game where a user
  wins by rolling a 7 or an 11 and looses
  otherwise. The game must be an event-driven
  program with a GUI. The game must allow a user to
  play as many games as desired, to view their
  win/loss record, and to see a history of all
  games played (with both dice values (1..6) and
  the result).

27
Identify Actors

• Actors in Dice Game
• Player
• Use cases
• Player starts a new game
• Play a game
• Player views history list
• Player checks win/loss record

28
Usage Centered Design

• Here is a sketch of what the graphical user
  interface may look like
• You may choose your own design as long as
• New games begin with a new name
• The user can click a menu item to see win/loss
  record
• The user can click a menu item to see history

29
Menu selection
Rick

• See Index of Java book for
• JMeuItem
• JMenu
• JMenuBar
• setJMenuBar
• You need an ActionListener object
• to listen to JMenuItem clicks

30
Example of OOAD -- dice game

• Uses cases are textual narrative descriptions of
  the processes in the business or system
• They can be written in a variety of ways
• Use case
• Actors
• Description

Play a Game Player This use case begins when the
player picks up and rolls the dice. The players
wins when the two dice total seven and loses the
other 11 times.
UML diagram of a use case
Play a Game
31
Conceptual Model Classes and Object
interactions

• Conceptual model, a diagram that depicts
• Concepts Player Die DiceGame
• Attributes name faceValue
• Associations rolls includes
• Responsibilities roll start

Player
Die
2
1
Rolls
name
faceValue
getHistoryList
roll
getWinLossRecord
1
2
Plays

DiceGame
1
Includes
start
32
Project 5

• The final specification for project 5 will be
  posted later today. Here are some tasks
• Implement a Die object to return random numbers
  from 1through 6
• Implement a Dice Game that can be played by a
  player
• Implement a player that keeps track of all dice
  games
• The model will have several classes
• Use test first design
• There must be a unit test for each non-gui class
  you write
• See web writeup under happenings for unit testing
  with JBuilder Personal (will be posted today).
  Also see attached AllTests.java