Advanced Object-Oriented Analysis & Design
Dr. M.E. Fayad, Professor
Computer Engineering Department, Room #283I
College of Engineering
San José State University
One Washington Square
San José, CA 95192-0180
http://www.engr.sjsu.edu/~fayad
2003
SJSU -- CmpE
L7-S1
UC Diagrams
Lesson 7:
Use Case Diagrams
2
2003
SJSU – CmpE ---
M.E. Fayad
L7-S2
UC Diagrams
Lesson Objectives

Overview of Previous Lecture
 Use Case Models and Diagrams Notation
Objectives

Discuss the following:
– What is use case modeling?
– Use Case Modeling -- Core concepts
– Use Case Diagram tour
– When to model use cases
– Use Case Modeling tips
– Use Case Templates
– Examples: Library & University
Registration
2003
SJSU – CmpE ---
M.E. Fayad
L7-S3
UC Diagrams
3
Use Case Modeling: Core Elements
Construct Description
use case
actor
Syntax
A sequence of actions, including
variants, that a system (or other
entity) can perform, interacting with
actors of the system.
A coherent set of roles that users
of use cases play when interacting
with these use cases.
UseCaseName
ActorName
system
boundary
2003
Represents the boundary between
the physical system and the actors
who interact with the physical
system.
SJSU – CmpE ---
M.E. Fayad
L7-S4
4
UC Diagrams
Use Case Modeling: Core Relationships (1)
Construct
Description
Syntax
The participation of an actor in a use
case. i.e., instance of an actor and
instances of a use case communicate
with each other.
A relationship from an extension use
extend
case to a base use case, specifying
how the behavior for the extension
use case can be inserted into the
behavior defined for the base use
case.
generalization A taxonomic relationship between a
more general use case and a more
specific use case.
association
2003
SJSU – CmpE ---
M.E. Fayad
L7-S5
<<extend>>
5
UC Diagrams
Use Case Modeling: Core Relationships (2)
Construct
Description
include
An relationship from a base use case
to an inclusion use case, specifying
how the behavior for the inclusion use
case is inserted into the behavior
defined for the base use case.
Syntax
<<include>>
Multiplicities are missing!
6
2003
SJSU – CmpE ---
M.E. Fayad
L7-S6
UC Diagrams
Use Case Diagram Tour
 Shows
use cases, actor and their
relationships
 Use case internals can be specified by
text and/or interaction diagrams
 Kinds
–use case diagram
–use case description
7
2003
SJSU – CmpE ---
M.E. Fayad
L7-S7
UC Diagrams
When to model use cases




2003
Model user requirements with use cases.
Model test scenarios with use cases.
If you are using a use-case driven method
– start with use cases and derive your
structural and behavioral models from it.
If you are not using a use-case driven method
– make sure that your use cases are
consistent with your structural and
behavioral models
SJSU – CmpE ---
M.E. Fayad
L7-S8
UC Diagrams
8
Use Case Modeling Tips





2003
Make sure that each use case describes a significant chunk of
system usage that is understandable by both domain experts and
programmers
When defining use cases in text, use nouns and verbs accurately
and consistently to help derive objects and messages for
interaction diagrams
Factor out common usages that are required by multiple use cases
– If the usage is required use <<include>>
– If the base use case is complete and the usage may be
optional, consider use <<extend>>
A use case diagram should
– contain only use cases at the same level of abstraction
– include only actors who are required
Large numbers of use cases should be organized into packages
SJSU – CmpE ---
M.E. Fayad
L7-S9
UC Diagrams
9
Actors (1)

An actor is someone or some thing that must interact
with the system under development
Registrar
Professor
Student
Billing System
10
2003
SJSU – CmpE ---
M.E. Fayad
L7-S10
UC Diagrams
Actors (2)
 An
actor represents a coherent set of
roles that users of use cases play when
interacting with the use cases
 Typically,
an actor represents a role that
a human, a hardware device, or even
another system plays with a system
2003
SJSU – CmpE ---
M.E. Fayad
L7-S11
11
UC Diagrams
Use Cases (1)
 A use
case is a pattern of behavior the
system exhibits
– Each use case is a sequence of related
transactions performed by an actor and the
system in a dialogue
– It describes what a system does but NOT
how it does it
2003
SJSU – CmpE ---
12
M.E. Fayad
L7-S12
UC Diagrams
Use Cases (2)

A use case is a description of a set of
sequences of actions, including variants, that
a system performs to yield an observable
result of value to an actor

Each use case must have a name that
distinguishes it from other use cases
13
2003
SJSU – CmpE ---
M.E. Fayad
L7-S13
UC Diagrams
Use Cases (3)
 Actors
are examined to determine their needs
– Registrar -- maintain the curriculum
– Professor -- request roster
– Student -- maintain schedule
Maintain Curriculum
2003
Request Course Roster
SJSU – CmpE ---
M.E. Fayad
14
Maintain Schedule
L7-S14
UC Diagrams
Use Case Relationships (1)
 Can
organize use cases by specifying
relationships among them.
– Generalization
– Include
– Extend
15
2003
SJSU – CmpE ---
M.E. Fayad
L7-S15
UC Diagrams
Use Case Relationships (2)
 Generalization
– Child use case inherits the behavior and
meaning of the parent use case
– Child use case may add to or override the
behavior of its parent
– Child use case may be substituted any
place the parent use case appears
2003
SJSU – CmpE ---
M.E. Fayad
L7-S16
16
UC Diagrams
Use Case Relationships (3)

Include
– Base use case explicitly incorporates the behavior
of another use case at a location specified in the
base
– Use an include relationship to avoid describing the
same flow of events several times
• by putting the common behavior in a use case of its
own
2003
17
SJSU – CmpE ---
M.E. Fayad
L7-S17
UC Diagrams
Use Case Relationships (4)
<<include>>
Register for courses
<<include>>
Logon validation
18
Maintain curriculum
2003
SJSU – CmpE ---
M.E. Fayad
L7-S18
UC Diagrams
Use Case Relationships (5)

Extend
– An extend relationship between use cases means
that the base use case implicitly incorporates the
behavior of another use case at a location specified
indirectly by the extending use case
– Use an extend relationship to model the part of a use
case the user may see as optional system behavior
19
2003
SJSU – CmpE ---
M.E. Fayad
L7-S19
UC Diagrams
Use Case Relationships (6)
Super
Use Case
<<include>>
Included
Use Case
<<extend>>
generalization
Extending
Use Case
Sub
Use Case
2003
SJSU – CmpE ---
M.E. Fayad
L7-S20
UC Diagrams
20
Use Case Relationships (7)
Supply
Customer Data
«include»
Order
Product
«include»
Arrange
Payment
«include»
Place Order
1
*
«extend»
Extension points
additional requests :
the salesperson asks for
the catalog
after creation of the order
Request
Catalog
Fig. 3-45, UML Notation Guide
2003
SJSU – CmpE ---
M.E. Fayad
L7-S21
UC Diagrams
Use Case Relationships (8)
1
*
Place
Order
Salesperson
X
1
*
Establish
Credit
22
Supervisor
Fig. 3-46, UML Notation Guide
2003
SJSU – CmpE ---
M.E. Fayad
L7-S22
UC Diagrams
Use Case Model

UC model =
Use Cases +
System
Boundary +
Actors (outside
the system
boundary)
23
2003
SJSU – CmpE ---
M.E. Fayad
L7-S23
UC Diagrams
What is use case modeling?

use case model: a view of a system
that emphasizes the behavior as it
appears to outside users. A use case
model partitions system functionality
into transactions (‘use cases’) that are
meaningful to users (‘actors’).
24
2003
SJSU – CmpE ---
M.E. Fayad
L7-S24
UC Diagrams
Use Case Diagram (1)

Use case diagrams are created to visualize the relationships
between actors and use cases
Request Course Roster
Professor
Student
Maintain Schedule
25
Maintain Curriculum
Billing System
2003
Registrar
SJSU – CmpE ---
M.E. Fayad
L7-S25
UC Diagrams
Use Case Diagram (2)

A use case diagram is a diagram that shows a
set of use cases and actors and their
relationships.

Commonly contain
– Use cases
– Actors
– Dependency, generalization, and association
relationships
2003
SJSU – CmpE ---
M.E. Fayad
L7-S26
26
UC Diagrams
Use Case Diagram (3)
27
2003
SJSU – CmpE ---
M.E. Fayad
L7-S27
UC Diagrams
Use Case Diagram (4)
28
2003
SJSU – CmpE ---
M.E. Fayad
L7-S28
UC Diagrams
Use Case Diagram (5)
29
2003
SJSU – CmpE ---
M.E. Fayad
L7-S29
UC Diagrams
Use Case Diagram (6)
30
2003
SJSU – CmpE ---
M.E. Fayad
L7-S30
UC Diagrams
Use Case Diagram (7)
31
2003
SJSU – CmpE ---
M.E. Fayad
L7-S31
UC Diagrams
Use Case Diagram (7)
32
2003
SJSU – CmpE ---
M.E. Fayad
L7-S32
UC Diagrams
Use Case Diagram (8)
33
2003
SJSU – CmpE ---
M.E. Fayad
L7-S33
UC Diagrams
The Use Case Model



We must now identify the users of the system
and the tasks they must undertake with the
system. The details of the use case should
be documented, using a Use Case Template.
There are many different use case templates
Show a few!!
34
2003
SJSU – CmpE ---
M.E. Fayad
L7-S34
UC Diagrams
Use Case Template & Example: Change Flight
Use Case #: 1.0
 Use Case Name: Change flight
 Actors: traveler, client account db, airline reservation system
 Preconditions:
 Traveler has logged on to the system and selected ‘change flight
itinerary’ option
 Basic course
 System retrieves traveler’s account and flight itinerary from client
account database
 System asks traveler to select itinerary segment she wants to change;
traveler selects itinerary segment.
 System asks traveler for new departure and destination information;
traveler provides information.
 If flights are available then
 …
 System displays transaction summary.
 Alternative courses
 If no flights are available then …

35
2003
SJSU – CmpE ---
M.E. Fayad
L7-S35
UC Diagrams
My Use Case Template
Use Case Template
PACKAGE: _________________ [Description (an over view of the package)].
USE CASES: [A package will have one or more Use Cases].
Use Case No.: [1.1]
Use Case Title: [A descriptive title]
[Ex. adding a new patient, or adding a new role].
Actors: _______, _______, _______, _______.
[Any users of the Use Case, ex. human, machine, other systems or subsystems].
Corresponding Roles: _______, _______, _______, _______.
[There is a different role per actor in every Use Case].
Classes: _______, _______, _______, _______.
[List all the classes within the Use Case Description].
Corresponding Attributes and Behaviors:
Enduring Business Themes (EBT): _______, _______, _______
Business Objects (BO): _______, _______, _______, _______.
Industrial Objects (IO): _______, _______, _______, _______.
[This represents a clear classification of all the classes within the use case description].
Description of the Use Case:
[Describes the data flow and the logic flow of the Use Case].
Alternatives:
2003
SJSU – CmpE ---
M.E. Fayad
L7-S36
UC Diagrams
36
Case Study 1: Library System

You have been contracted to develop a
computer system for a university library. The
library currently uses a 1960s program,
written in an obsolete language, for some
simple bookkeeping tasks, and a card index,
for user browsing. You are asked to build an
interactive system which handles both of
these aspects online.*
37
*Example from: “Using UML”, by: Pooley and Stevens
2003
SJSU – CmpE ---
M.E. Fayad
L7-S37
UC Diagrams
First Step!

2003
Time to start gathering the user requirements.
– Different users will have different, sometimes
conflicting priorities
– Users will not, necessarily know what they
want
– It is very possible to miss something vital
– The managers do not always know what the
users have to do
– Users can be, and frequently are, hostile.
Why? What can be done about it?
SJSU – CmpE ---
M.E. Fayad
L7-S38
UC Diagrams
38
Documenting Use Cases



A flow of events description is created for each use case
– Written from an actors point of view
Details what the system must provide to the actor when
the use case is executed
Typical contents
– How the use case starts and ends
– Normal flow of events
– Alternate flow of events
– Exceptional flow of events
39
2003
Copyright © 1997 by Rational Software Corporation
SJSU – CmpE --M.E. Fayad
L7-S39
UC Diagrams
Actors

An actor is someone or something that must interact with the
system under development
BookBorrower
Browser
Librarian
JournalBorrower
2003
SJSU – CmpE ---
M.E. Fayad
L7-S40
UC Diagrams
Use Cases
Actors are examined to determine their needs
– BookBorrower
• Checkout and return books
– Browser
• locate and peruse items of interest
– Librarian
• maintain order and accountablility
– JournalBorrower
• checkout and return journals
Checkout Book
2003
Return Book
SJSU – CmpE ---
Checkout Journal
M.E. Fayad
L7-S41
UC Diagrams
Use Case Description

The usual course through the system when actor is using the
system is called the basic course. Other courses would be
modeled as extending Use Cases.

An example of a basic course would be:
– Borrow copy of book A BookBorrower presents a book. The
system checks that the potential borrower is a member of the
library, and that s/he does not already have the maximum
permitted number of books on loan. This maximum is six unless
the member is a staff member, in which case it is 12. If both
checks succeed, the system records that this library member has
this copy of the book on loan.
42
**Example from: “Using UML”, by: Pooley and Stevens
2003
SJSU – CmpE ---
M.E. Fayad
L7-S42
UC Diagrams
Use Case Diagram for the first iteration
43
*Example from: “Using UML”, by: Pooley and Stevens
2003
SJSU – CmpE ---
M.E. Fayad
L7-S43
UC Diagrams
What Requirements would an ideal system satisfy?

Books and Journals: The library contains books and
journals. It may have several copies of a given book. Some
of the books are for short term loans only. All other books
may be borrowed by any library member for three weeks.
Only members of staff may borrow journals. Members of the
library can normally borrow up to six items at a time, but
members of staff may borrow up to 12 items at one time.
New books and journals arrive regularly, and are sometimes
disposed of. The current year’s journals are sent away to be
bound into volumes at the end of each year.*
44
*Example from: “Using UML”, by: Pooley and Stevens
2003
SJSU – CmpE ---
M.E. Fayad
L7-S44
UC Diagrams
What Requirements would an ideal system satisfy?


Borrowing: It is essential that the system keep track of
when books and journals are borrowed and returned, since
the current system already does that. The new system
should produce reminders when a book is overdue. There
may in future be a requirement for users to be able to extend
the loan of a book if it is not reserved.
Browsing: The system should allow users to search for a
book on a particular topic, by a particular author, etc., to
check whether a copy of the book is available for loan, and if
not, to reserve the book. Anyone can browse in the library.*
45
*Example from: “Using UML”, by: Pooley and Stevens
2003
SJSU – CmpE ---
M.E. Fayad
L7-S45
UC Diagrams
Use Cases for the library
46
*Example from: “Using UML”, by: Pooley and Stevens
2003
SJSU – CmpE ---
M.E. Fayad
L7-S46
UC Diagrams
Case Study 2: University Registration

The ESU University wants to computerize
their registration system
– The Registrar sets up the curriculum for a semester
• One course may have multiple course offerings
– Students select 4 primary courses and 2 alternate courses
– Once a student registers for a semester, the billing system is
notified so the student may be billed for the semester
– Students may use the system to add/drop courses for a period of
time after registration
– Professors use the system to receive their course offering rosters
– Users of the registration system are assigned passwords which
are used at logon validation
47
2003
SJSU – CmpE ---
M.E. Fayad
L7-S47
UC Diagrams
Actors
Registrar
Professor
Student
Billing System
48
2003
Copyright © 1997 by Rational Software Corporation
SJSU – CmpE --M.E. Fayad
L7-S48
UC Diagrams
Use Cases

Actors are examined to determine their needs
– Registrar
• maintain the curriculum
– Professor
• request roster
– Student
• maintain schedule
– Billing System
• receive billing information from registration
Maintain Curriculum
2003
Request Course Roster
Copyright © 1997 by Rational Software Corporation
SJSU – CmpE --M.E. Fayad
Maintain Schedule
L7-S49
UC Diagrams
Maintain Curriculum: Flow of Events (description)

This use case begins when the Registrar logs onto the
Registration System and enters his/her password. The system
verifies that the password is valid (E-1) and prompts the
Registrar to select the current semester or a future semester (E2). The Registrar enters the desired semester. The system
prompts the professor to select the desired activity: ADD,
DELETE, REVIEW, or QUIT.
 If the activity selected is ADD, the S-1: Add a Course subflow is
performed.
 If the activity selected is DELETE, the S-2: Delete a Course
subflow is performed.
 If the activity selected is REVIEW, the S-3: Review Curriculum
subflow is performed.
 If the activity selected is QUIT, the use case ends.
50
2003
Copyright © 1997 by Rational Software Corporation
SJSU – CmpE --M.E. Fayad
L7-S50
UC Diagrams
Use Case Model

Use case diagrams are created to visualize the relationships
between actors and use cases
Request Course Roster
Professor
Student
Maintain Schedule
Maintain Curriculum
Billing System
Registrar
2003
Copyright © 1997 by Rational Software Corporation
SJSU – CmpE --M.E. Fayad
L7-S51
UC Diagrams
Uses and Extends Use Case Relationships

As the use cases are documented, other use case
relationships may be discovered
– A uses relationship shows behavior that is common to
one or more use cases
– An extends relationship shows optional behavior
<<uses>>
Register for courses
<<uses>>
Logon validation
Maintain curriculum
2003
Copyright © 1997 by Rational Software Corporation
SJSU – CmpE --M.E. Fayad
L7-S52
UC Diagrams
Possible Problems with Use Cases
1. Use Cases emphasize ordering. This can be
considered to be incompatible with object
technology.
2. Over modeling – Leads to requirement inflation.
53
2003
SJSU – CmpE ---
M.E. Fayad
L7-S53
UC Diagrams
Cautions
Do not invent requirements!
– Use cases are about the user’s requirements,
not about what you, as the designer might
think that the system could usefully do!
54
2003
SJSU – CmpE ---
M.E. Fayad
L7-S54
UC Diagrams
Sample Use Case from Philips Project (1)
2003

Use Case No.: 1.1.1

Use Case Title: Find Candidate

Actors: Registrar

Roles: Data Entry Clerk (Registrar),

Classes: IDSession, PersonProfile, PersonIdentifier, PersonTraits
, CandidateListGenerator, DataManager

Enduring Business Themes: (EBT): identity, security,

Business Objects: IDSession, IDManager, DataManager,
PersonIdentifier

Industrial Objects: CandidateList, PersonTraits, PersonProfiles,
SecurityManager, TraitGatekeeper
SJSU – CmpE ---
M.E. Fayad
L7-S55
UC Diagrams
55
Sample Use Case from Philips Project (2)

Description of the Use Case:

1.
The Registrar enters the information about a person into the
System.

2.
IDSession clears the request with Security.

3.
The System tells the Person-Identifier to search for candidates.

4.
The Person-Identifier gives the request to its DataManager

5.
The DataManager determines a list of candidates, using its
CandidateListGenerator and its set of PersonProfiles and returns it
to the System.

6.
The Registrar chooses the candidate from the list that
represents the person.
56
2003
SJSU – CmpE ---
M.E. Fayad
L7-S56
UC Diagrams
Sample Use Case from Philips Project (3)

Use Case No.: 1.2.1

Use Case Title: Register New ID

Actors: Registrar

Roles: Data Entry Clerk (Registrar),

Classes: IDSession, IDManager, PersonProfile, PersonTraits,
CandidateList, PersonIdentifier

Enduring Business Themes (EBT): identity, security

Business Objects (BO): IDSession, IDManager, PersonIdentifier

Industrial Objects (IO): PersonProfile, PersonTraits, CandidateList
57
2003
SJSU – CmpE ---
M.E. Fayad
L7-S57
UC Diagrams
Sample Use Case from Philips Project (4)

Description of the Use Case:

1.
The Registrar enters the information about a person into the IDSession.

2.
The IDSession has security clear the request.

3.
The IDSession has the PersonIdentifier search for candidates.

4.
The Person-Identifier determines that no candidates fit the criteria.

5.
The Person-Identifier gives this information to the system.

6.
The informs the Registrar that no candidates exist.

7.
System asks the Registrar if the person should be added as new.

8.
Registrar tells System to add new person.

9.
System sends traits to ID-Manager.

10. ID-Manager creates a new profile.
2003
SJSU – CmpE ---
58
M.E. Fayad
L7-S58
UC Diagrams
Sample Use Case from Philips Project (5)

Exceptional Flow of Events 01: If any of the identifying information
entered by the Registrar is incomplete or invalid the system displays
corresponding error message(s). The system will not validate the
New Person until all identifying information is made available.


Exceptional Flow of Events 02: In case the system determines that
one or more of the identifying information for a person matches one or
more person(s) already in the system the Registrar is displayed with a
screen listing all the person(s) meeting the search criteria. The
Registrar is then given the opportunity to either create the person in
the system with a new ID or pick one from the selection list.
59
2003
SJSU – CmpE ---
M.E. Fayad
L7-S59
UC Diagrams
Sample Use Case from Philips Project (6)

Use Case No.: 1.3.1

Use Case Title: Get Patient Profile using Patient ID

Actors / Roles: Nurse, Patient, and Profile Access

Classes:

Enduring Business Themes (EBT): Diagnosis, Customer Service
and Complete Medical History

Business Objects (BO): Profile Access, Identify Person and
Identity

Industrial Objects (IO): Identity Access
60
2003
SJSU – CmpE ---
M.E. Fayad
L7-S60
UC Diagrams
Sample Use Case from Philips Project (7)

Description of the Use Case:

1.

2.
The Person Identification system determines the validity of the
Person ID.

3.

Exceptional Flow of Events 01: If the Person ID is invalid an error
message is displayed. The nurse then can decide either to search the
system with person identification information or redirect the person to a
Registrar.
The Nurse enters the Person ID for the person.
The Get Profile System returns the profile the specified Person ID.
61
2003
SJSU – CmpE ---
M.E. Fayad
L7-S61
UC Diagrams
Summary & Simplifications
62
2003
SJSU – CmpE ---
M.E. Fayad
L7-S62
UC Diagrams
Simplification: Notation
Construct
Description
association
The participation of an actor in a use case. i.e.,
instance of an actor and instances of a use
case communicate with each other.
inheritance
It is a AKO or is-a relationshipThis relationship
includes extend and generalization. A
taxonomic relationship between a more general
use case and a more specific use case and
relationship from an extension use case to a
base use case, specifying how the behavior for
the extension use case can be inserted into the
behavior defined for the base use case.
It is a part-of relationship.
aggregation
2003
SJSU – CmpE ---
Syntax
M.E. Fayad
L7-S63
UC Diagrams
Multiplicities (1)
1
*
One to Many
*
1
Association
Directed association is a one-way association, in which one
side knows the other, but not vice versa.


2003
Multiplicity Specification:
–1
exactly one
– 0, 1
zero or one
– 0..4
between zero and four
– 3, 7
either three or seven
SJSU – CmpE ---
64
M.E. Fayad
L7-S64
UC Diagrams
Multiplicities (2)

More multiplicity specifications:
– 0..*
greater than or equal to zero (default)
– *
many
– 1..*
greater than or equal to one
– 0..3, 7, 9..* between zero and three, or exactly seven, or
greater than or equal to nine.
65
2003
SJSU – CmpE ---
M.E. Fayad
L7-S65
UC Diagrams
Samples of Use Case Diagrams (1)
supply
Retailer
Wholesaler
*
sale
66
A supply activity consists of many sales.
2003
SJSU – CmpE ---
M.E. Fayad
L7-S66
UC Diagrams
Samples of Use Case Diagrams (2)
deliver, pay
1
sale
*
1
Retailer
Wholesaler
order
67
A sale activity consists of order and deliver.
2003
SJSU – CmpE ---
M.E. Fayad
L7-S67
UC Diagrams
Samples of Use Case Diagrams (3)
Different kinds of sales &
their constituent actions
sale
saleByPrice
saleByQty
saleBySupply
salePrice
order
2003
68
pay
accept
reqPay
deliver
SJSU – CmpE ---
M.E. Fayad
L7-S68
UC Diagrams
Discussion Questions
1. Define: use case model, a use case, use case diagrams,
and, actors
2. T/F
a. A use case is a pattern of behavior the system exhibits.
b. A use case describes how the system does it but NOT what
a system does.
c. Use case diagrams are created to visualize the behavior
between actors and use cases
d. Use cases are about user’s requirements not about what
you might think as a designer that the system could usefully
do.
2003
SJSU – CmpE ---
M.E. Fayad
L7-S69
UC Diagrams
69
Questions for the Next Lecture

CRC Cards

Existing CRC Cards

My CRC Cards

How to create with CRC
Cards
70
2003
SJSU – CmpE ---
M.E. Fayad
L7-S70
UC Diagrams
Tasks for Next Lecture
Task 1: Problem Statement for team projects are
needed (see sample problems on OOPSLA –
DesignFest). This is due on the third week of
the semester.
Task 2: Identify the team members of your team.
Select a team name and e-mail me, the team
name, team’s members’ names, their e-mails,
phone numbers -- Immediately.
Task 3: Think about extra assignments and writing
essays. E-mail me if you like to start right
away.
Please note that problem statements must be
submitted electronically as MS Word format.
2003
SJSU – CmpE ---
M.E. Fayad
L7-S71
UC Diagrams
71