System Analysis &

Design

Wesley Shu
All Rights Reserved

Contents
Chapter1.........................................................................................................................7
1. PERT/CPM and Gantt Chart..........................................................................7
Chapter2.........................................................................................................................8
1. What is a System............................................................................................8
2. Important Systems Concept...........................................................................9
3. Approaches in Systems Analysis...................................................................9
4. Systems Development Life Cycle................................................................10
Chapter3.......................................................................................................................11
1. Basic Concept...............................................................................................11
2. Mini Cases....................................................................................................13
3. Case: Student Registration System..............................................................15
3.1
Identify Entities - Noun Phrase Analysis.....................................16
3.2
Identify Relationships - Verb Phrase Analysis.............................16
Chapter4.......................................................................................................................19
1. Data Flow Diagram Definitions...................................................................19
2. Developing DFD..........................................................................................20
2.1
Context Diagram..........................................................................20
2.2
Level-0 Diagram..........................................................................21
2.3
Level-n Diagram..........................................................................22
3. Balancing DFD.............................................................................................23
4. Case: Student Registration System..............................................................23
5. DFD Rules....................................................................................................25
6. Guidelines for Drawing DFDs.....................................................................29
7. Mini Case.....................................................................................................30
8. Documenting DFD Components..................................................................35
8.1
Process Descriptions....................................................................35
8.2
Data Dictionary for the Processes in SRS Case...........................35
8.3
External Entity, Data Flow, Data Store and Attribute Definitions
37
8.4
Example of Data Dictionary.........................................................39
9. Data Model and Process Model...................................................................41
Chapter5.......................................................................................................................43
1. Why Object Oriented Analysis?...................................................................43
2. Basic Concept...............................................................................................43

2.1
Object...........................................................................................43
2.2
Class.............................................................................................44
2.3
Attribute.......................................................................................44
2.4
Operation......................................................................................44
2.5
Class Operation and Class Attribute............................................45
2.6
Instantiation..................................................................................45
2.7
Method Signature.........................................................................46
2.8
Messages......................................................................................46
2.9
Dot................................................................................................46
2.10
Constructor...................................................................................47
2.11
Abstract Data Type.......................................................................47
2.12
Abstract Operations and Classes..................................................47
Chapter6.......................................................................................................................49
1. Relationship..................................................................................................49
1.1
Associations.................................................................................49
1.2
Whole / Part Associations............................................................50
1.3
Association Class.........................................................................51
1.4
Generalization..............................................................................51
2. Mini Cases....................................................................................................51
3. SRS Class Diagram......................................................................................55
3.1
Problem Description.....................................................................55
3.2
Some Points about the Attributes.................................................56
4. Even More Concept......................................................................................57
4.1
Packages.......................................................................................57
4.2
Interface........................................................................................58
Chapter7.......................................................................................................................59
1. Messages......................................................................................................59
1.1
What Is It?....................................................................................59
1.2
Example........................................................................................59
2. Collaboration Diagram.................................................................................60
3. Sequence Diagram.......................................................................................61
3.1
Checking Prerequisite Example...................................................61
3.2
Mini Case.....................................................................................62
3.3
SRS Sequence Diagram...............................................................66
Chapter8.......................................................................................................................69
1. Problem of Identifying Scope......................................................................69
2. Use Cases.....................................................................................................69
3. Use Cases Diagrams.....................................................................................70

4. Modeling Techniques...................................................................................70
5. Stereotype.....................................................................................................71
6. Draw a USE Case Diagram - SRS Example................................................71
Chapter9.......................................................................................................................73
1. Basic State Diagrams...................................................................................73
1.1
Elements.......................................................................................73
2. Nested States................................................................................................74
2.1
Composite State...........................................................................75
3. History..........................................................................................................75
4. Concurrent States.........................................................................................77
Chapter10.....................................................................................................................78
1. Components..................................................................................................78
2. More on Concurrent and Synchronization...................................................79
3. Swimlane......................................................................................................79
4. Object Flow..................................................................................................80

TABLE 1-1 A GANTT CHART - TO BE FILLED..................................................................7

TABLE 1-2 INFORMATION FOR A CPM...........................................................................7
TABLE 4-1 RULES OF CREATING DFDS........................................................................29
TABLE 7-1 OPERATIONS FROM THE SRS SEQUENCE DIAGRAM...................................67

FIGURE 2-1 SYSTEMS DEVELOPMENT LIFE CYCLE......................................................10

FIGURE 3-1 ENTITY RELATIONSHIP DIAGRAM OF STUDENT REGISTRATION SYSTEM,
VERSION 2............................................................................................................17
FIGURE 4-1 GANE & SARSON DFD SYMBOLS.............................................................20
FIGURE 4-2 A CONTEXT DIAGRAM...............................................................................20
FIGURE 4-3 CONTEXT DIAGRAM OF A SHOPPING CASE...............................................21
FIGURE 4-4 LEVEL-0 DFD FOR SHOPPING CASE.........................................................21
FIGURE 4-5 LEVEL-1 DFD FOR SELECT PRODUCT PROCESS.......................................22
FIGURE 4-6 LEVEL-1 DFD FOR PURCHASE PRODUCT PROCESS..................................23
FIGURE 4-7 AN UNBALANCED SET OF DFDS...............................................................24
FIGURE 4-8 THE CONTEXT DIAGRAM OF STUDENT REGISTRATION SYSTEM...............25
FIGURE 4-9 LEVEL-0 DFD OF STUDENT REGISTRATION SYSTEM................................26
FIGURE 4-10 LEVEL-1 DFD FOR CHECK ROOM AVAILABILITY & ADD TO WAITING
LIST SUBSYSTEM................................................................................................27
FIGURE 6-1 A CLASS DIAGRAM....................................................................................50
FIGURE 6-2 WHOLE/PART ASSOCIATION AGGREGATION AND COMPOSITION............50
FIGURE 6-3 GENERALIZATION......................................................................................52
FIGURE 6-4 SRS CLASS DIAGRAM...............................................................................56
FIGURE 6-5...................................................................................................................57
FIGURE 7-1 MESSAGE OF TRANSFERRING FUNDS........................................................60
FIGURE 7-2 THE SEQUENCE DIAGRAM FOR TRANSFERRING FUNDS............................61
FIGURE 7-3 A SEQUENCE DIAGRAM SHOWS REGISTRATION AND CHECKING
PREREQUISITE.......................................................................................................62
FIGURE 7-4...................................................................................................................65
FIGURE 7-5...................................................................................................................65
FIGURE 7-6 SRS SEQUENCE DIAGRAM........................................................................68
FIGURE 8-1 A USE CASE DIAGRAM..............................................................................71
FIGURE 8-2 SRS USE CASE DIAGRAM.........................................................................72
FIGURE 9-1 STATE DIAGRAM FOR SELLABLEITEM.CURRINSPECTIONSTATUS..............74
FIGURE 9-2 THE STATE DIAGRAM FOR MACHINE.OPSTAT...........................................75
FIGURE 9-3 THE STATE DIAGRAM FOR MACHINE.SERVICESTAT..................................76
FIGURE 9-4 A NESTED STATE DIAGRAM......................................................................76
FIGURE 9-5 A STATE DIAGRAM OF WASHINGMACHINE WITH HISTORY.......................77
FIGURE 9-6 CONCURRENT STATES................................................................................77
FIGURE 10-1 ACTIVITY DIAGRAMS..............................................................................78
FIGURE 10-2 AN ACTIVITY DIAGRAM SHOWS FLOWS OF CONTROLS USING
SWIMLANES AND FORK/JOIN................................................................................79

Chapter 1 Project
Management
1. PERT/CPM and Gantt Chart
Develop PERT/CPM chart and Gantt chart (Table 1 -1)
1.

(a)
A CPM will be drawn on the blackboard

ID

Duration

Task

Start

End

Name

Date

Date
2/10/20

Task 1

1/10/20

Task 2

2/10/20

Task 3

3/10/20

Task 4

4/10/20

Task 5

5/10/20

October 2020
30

Table 1-1 A Gantt Chart - to be filled

Task

Duration

Precedence

B, C

Table 1-2 Information for a CPM

Chapter 2 System Analysis

1. What is a System
A system is an interrelated set of components, with an identifiable boundary, working
together for some purpose.
1. Components
An irreducible part of an aggregate of parts (subsystem), that makes up a system.
So, we can repair or upgrade the system by changing individual components
2.

3.
4.

5.
6.
7.
8.

instead of making changes throughout the entire system.

Inter-related components
The function of one component is tied to the function of the others.

Boundary within which, all of its components are contained and

which establishes the limits of a system, separating from other systems.

Purpose
All components work all together to achieve some purpose.
Environment
A system exists in an environment and exchanges data and information with its
environment.
Interfaces
The points that a system meets its environment
Constraints
The limits to what a system can do and how a system can achieve its purpose
Input
Whatever a system takes from its environment in order to fulfill its purpose
Output
Whatever a system returns to its environment in order to fulfill its purpose

2. Important Systems Concept

1.

Decomposition
Breaking down a system into its components.

2.

Modularity
A direct result of decomposition.

3.

Coupling
The extent to which subsystems are dependent on each other.
Subsystems should be as independent as possible.

4.

Cohesion
The extent to which a system performs a single function

3. Approaches in Systems Analysis

1

Data Modeling, aka Information Engineering Approach

A technique for organizing and documenting a systems data

Tool: Entity Relationship Diagram

Process Modeling, aka Structured Approach

A technique for organizing and documenting the structure and flow of

data through a systems processes and /or the logic, policies, and procedures

to be implemented by a systems processes.

Tool: Data Flow Diagram, Functional Decomposition Diagram, Data-to-

Process-CRUD Matrix
Object-Oriented Approach

A technique for viewing an information system as a collection of

interacting objects which is composed of data and the operations.

Tool: UML, including class diagram, state diagram, use case, etc., for
Object-Oriented Analysis - both data and process

4. Systems Development Life Cycle

Figure 2-1 Systems Development Life Cycle

Chapter 3 Data Modeling

Entity Relationship Diagram
1. Basic Concept
1.

Entity
A collection of instances that share common properties, aka Entity, Entity Set, ex.
STUDENT

A group of distinguishable objects

can be a group of persons, places, physical objects, events, concepts, or a

relationship
An instance is single occurrence of an entity, aka occurrence, entity

2.

occurrence, entity instance

Attribute
A named property of an entity that is of interest to the organization, ex. first_

3.

name, last_name, middle_initial.

Primary Key
An attribute, or combination of attributes (composite key), that uniquely

4.

identifies each instance of an entity

Foreign Keys
An attribute (possibly composite) that appears as a non-key attribute in an entity

5.

and as a primary key attribute in the related entity.

Relationship
An association between the instances of one or more entity types (participants),
e.g.,

PROFESSOR <TEACHES> SECTION

STUDENT <ENROLL> SECTION

Cardinality (Multiplicity)
The specific number (minimum, maximum) of instances associated with one

6.

7.

8.

instance of the related entity.

E.g., PROFESSOR(1,1) <teach> (0,m)SECTION
At this moment, focus on the maximum. So, the above example is 1:M.
Composite Entity
It is a bridge between two (or more) entity types whose multiplicities are (x, m)
and (x, m) where x is either 0 or 1. A composite entity can have its own attributes.
Degree
(a) Binary
i. 1:M
E.g., PROFESSOR(1,1) <teach> (0,m)SECTION
ii. M:N
STUDENT(1,m) <enroll> (1,m) SECTION
Since this relationship is M:N, we create a composite entity named
ENROLL-MENT between STUDENT and SECTION
(b) Unary
i. 1:M
EMPLOYEE <manage> How to represent the cardinalities?
ii. M:N
COURSE <pre-require> How to represent the cardinalities?
Since this relationship is M:N, we create a composite entity named
PREREQ-UISITE. This principle is applied no matter what degree the
relationship is!

2. Mini Cases
1.

ABC is an e-Commerce retail company. It sells products through the Internet. The
company needs to record customers, orders, and products. A customer puts orders
and each order belongs to only one customer. An order may have several
transaction items and each transaction item matches a product, although one
transaction may contain more than one item of that product. The company also
needs to record product information including description, price, and inventory
level. Please draw an ERD for this mini case
CUSTOMER(customer#, name, address, ...)
ORDER(order#, date, customer#)
PRODUCT(product#, description, price, onhand)
TRANSACTION(transaction#, unit, product#, order#)

2.

At NCU, students take classes (sections). Each section is a course and there can
be many sections for a course. You can find courses without sections offered. An
enrollment is a file where the university records the grade for a student in a
particular section. Each section is taught by a professor but a professor can teach
many sections. She/he may not teach any section. Please draw an ERD for this
mini case.
PROFESSOR(staff#, name, address)
COURSE(course#, description, unit)
SECTION(section#, room, max enrollment, course#, staff#)
STUDENT(student#, name, address)

ENROLLMENT(section#, student#, grade, date complete)

3.

Following the above case, NCU understands the importance to be able to verify
prerequisites and to allow waiting list for each section. A course may be a
prerequisite for many other courses. A course can also have many prerequisites. A
waiting list contains the information of sections and the students waiting for
them. One section can allow many students to wait for and a student can wait for
many sections. Please draw an ERD for this mini-case.
COURSE(course#, description, unit)
PREREQUISITE(course#, prerequisite#)
SECTION(schedule#, room, max enrollment, course#, section#, staff#)
STUDENT(student#, name, address)
WAITINGLIST(section#, student#, priority)

4.

Parking is a big problem for NCU. The university issues different types of
parking permits including handicap (H), SP1, SP2, F, S, and Commercial (C).
The parking structures are buildings and each building has information on the

location, number of spaces for each type of parking permit. The university has to
keep track of the sales of parking permits. The number of each type of parking
permit cannot be more than 120% of the total number of parking spaces for that
type. Please draw an ERD for this case.
PERMIT(permit#, type_id )
BUILDING(building#, location)
PERMIT TYPE(type_id, description)
BP(building#, type_id, quantity)

3. Case: Student Registration System

We have been asked to develop an automated Student Registration Systems (SRS) for
the university. This system will enable students to register on-line for sections each
semester. During the registration period preceding each semester, the SRS will verify
whether or not the student has satisfied the necessary prerequisites for each requested
section by referring the students on-line transcript of classes completed and grades
received. Assuming that (a) the prerequisites for the requested sections are satisfied,
and (b) there is room available in each of the sections, the student is enrolled in the
sections. Once a section is successfully registered, the system will notify the student.
When a section is not registered, either because of prerequisite not verified or room
not available, the system will also notify the student.

3.1 Identify Entities - Noun Phrase Analysis

1.

Find all nouns.

2.
3.
4.
5.
6.

Eliminate duplicates
Eliminate references to the system itself.
Eliminate references to the organization in question; i.e., the university
Eliminate other miscellaneous terms which dont seem to be entities.
Group apparent synonyms, e.g., transcript implies a record of courses com-

7.

pleted and grades received.

Put aside roles of an entity, e.g., a section can have roles of section taken

or section is being registered.

The result is the following entities: Section, Course, Student, and Transcript.

3.2 Identify Relationships - Verb Phrase Analysis

1.

Find the verbs resulting in relationships.

2.

Do not include transient actions which do not result in relationships or verbs

which are immaterial, e.g., Students track their progress toward completion of
their degree, or Student first enrolls at the university.
The result is the following matrix:

Text means a relationship.

A check means there is a relationship but naming is not important or

possible.

A cross means no relationship exists.

3. Draw the Entity Relationship Diagram
Draw the Entity Relationship Diagram
Figure 3 -2 is the ERD for Student Registration System
COURSE

SECTION
ENROL
L
MENT

PRER
EQ

STUDENT

Or

Figure 3-2 Entity Relationship Diagram of Student Registration System

The attributes of each entity are (in the above diagram):
COURSE(cid, title, )
PREREQ(cid, pid, )
SECTION(section_id, course_id, instructor, room, seating_capacity)
STUDENT(sid, sname, saddress)
ENROLLMENT(sid, sec_id, grade, date_of_complete)
The attributes of each entity are (in the below diagram):
COURSE(cid, title, prerequisite*)
SECTION(section_id, course_id, instructor, room, seating_capacity, room
_availability)
STUDENT(sid, sname, saddress)
ENROLLMENT(sid, sec_id, grade, date_of_complete)
TRANSCRIPT*(?)

Chapter 4
Process Modeling - Data Flow
Diagram
A complete Systems Analysis phrase has these deliverables:
1. Context Data Flow Diagram (DFD)
2. DFDs of current logical system
3. DFDs of new logical system
4. Thorough descriptions of each DFD component

1. Data Flow Diagram Definitions

1.

Data flow
Data in motion, moving from one place in a system to another A data flow is data
that move together. Thus, a data flow can be composed of many individual pieces
of data that are generated at the same time and flow together to common

2.
3.
4.

destinations.
Data store
Data at rest: physical location of data, e.g., file, folder, directory, etc.
Process
Work or actions performed on data
External Entity
A physical object interacting with the system. It is always outside the system.

5.

Source/sink
Source or destination of the data.
Figure 4 -3 shows Gane and Sarson DFD symbols1

2. Developing DFD
2.1 Context Diagram
An overview of an organizational system that shows the system boundaries, external
entities that interact with the system, and the major information flows between the
external entities and the system. Figure 4 -4 is a context diagram.
Figure 4 -5 is the context diagram of a typical shopping case.

Figure 4-3 Gane & Sarson DFD Symbols

Figure 4-4 A Context Diagram

To draw a DFD using Visio, you need to choose Gane & Sarson DFD from Software
Diagram in stead of Data Flow Diagram from Flowchart.
1

Figure 4-5 Context Diagram of a Shopping Case

2.2 Level-0 Diagram

A DFD that represents a systems major processes, data flows, and data stores at a
high level of detail. For the above shopping case, the Level-0 DFD can be in .

SHELF

returned product

product picked up

Select
Product

CUSTOMER

selected product

product selection
receipt
CASHIER
payment
Wallet

Cart
Purchase
Product

payment

Figure 4-6 Level-0 DFD for Shopping Case

selected products
bagged
products

Car

2.3 Level-n Diagram

A DFD that is the result of n nested decompositions of a series of sub-processes from
a process on a level-0 diagram. For example, we can expand Select Product and
Purchase Product by showing their details in the two Level-1 DFDs, Figure 4 -7
and Figure 4 -8.

Figure 4-7 Level-1 DFD for Select Product Process

selected products
Cart

Get
Products

payment
Check Out

Wallet

products from cart

checkout
initiation

products to purchase
receipt
CASHIER

bagged product
Car

Place
Products for
Check-out

payment

Figure 4-8 Level-1 DFD for Purchase Product Process

3. Balancing DFD
The conservation of inputs and outputs to a data flow diagram process when that
process is decomposed to a lower level. Figure 4 -9 shows that the context DFD and
the level-1 DFD are unbalanced.
In Figure 4 -9, the context DFD only has one source but in the level-0 DFD, two
sources appear.

4. Case: Student Registration System

We have been asked to develop an automated Student Registration Systems (SRS) for
the university. This system will enable students to register on-line for sections each
semester.

Figure 4-9 An Unbalanced Set of DFDs

During the registration period preceding each semester, the SRS will verify whether
or not the student has satisfied the necessary prerequisites for each requested section
by referring the students on-line transcript of classes completed and grades received.
Assuming that (a) the prerequisites for the requested sections are satisfied, and (b)
there is room available in each of the sections, the student is enrolled in the sections.
Once a section is successfully registered, the system will notify the student. When a
section is not registered, either because of prerequisite not verified or room not
available, the system will also notify the student. Figure 4 -10 is the context diagram
of Student Registration System.

Figure 4-10 The Context Diagram of Student Registration System

The Student Registration System contains 5 major processes: Verify
Prerequisite, Check Room Availability & Add to Waiting List, Notify Enrollment, and
Enroll. The system also contains the data flows between the processes and data stores.
Figure 4 -11 shows the Level-0 diagram.
Consider the following example:
A Subsystem of check Room Availability
Following the above SRS case, the university maintains a waiting list for each section.
If prerequisite requirement is satisfied, but room is not available, the student is placed
on the first-come, first-served waiting list. If a class/section that she/he was previously
wait-listed for becomes available, the first-come student will be automatically added
into that section.
Figure 4 -12 shows Level-1 DFD segment for Process 3, Check Room availability.

5. DFD Rules
1. Process
(a) No process can have only outputs (a miracle.) If an object has only
outputs, then it must be a source.
(b) No process can have only inputs (a black hole). If an object has only
inputs, then it must be a sink.
(c) A process has a verb phrase label.

Figure 4-11 Level-0 DFD of Student Registration System

2. Data Store
(a) Data cannot move directly from one data store to another data store.
Data must be moved by a process.
(b) Data cannot move directly from an outside source to a data store. Data
must be moved by a process which receives data from the source and
places the data into the data store.
(c) Data cannot move directly to an outside sink from a data store. Data
must be moved by a process.
(d) A data store has a noun phrase label.
3. Source/ Sink
(a) Data cannot move directly from a source to a sink. It must be moved by
a process if the data are of any concern to our system. Otherwise, the
data flow is not shown on the DFD.
(b) A source/sink has a noun phrase label

Figure 4-12 Level-1 DFD for Check Room Availability & Add to Waiting List
Subsystem
4. Data Flow
(a) A data flow has only one direction of flow between symbols.
(b) A fork in a data flow means that exactly the same data goes from a
common location to two or more different processes, data stores, or
sources/sinks. This usually indicates different copies of the same data
going to different locations.
(c) A join in a data flow means that exactly the same data comes from any
of two or more different processes, data stores or sources/sinks to a
(d)
(e)
(f)
(g)

common location.
A data flow cannot go directly back to the same process it leaves.
A data flow to a data store means save, update, or delete.
A data flow from a data store means retrieve or use.
A data flow has a noun phrase label. More than one data flow noun

phrase can appear on a single arrow.

5. Other Rules
(h) A composite data flow, say A on one level can be split into component

data flows, say A1 and A2, at the next level but no new data can be
added.
(i) At the lowest level of DFDs, new data flows may be added to represent
data that are transmitted under exceptional condition; these data flows
typically represent error messages or confirmation notices.
Table 4 -3shows the DFD rules in DFD symbols:

Table 4-3 Rules of Creating DFDs

6. Guidelines for Drawing DFDs

1.

Completeness
whether you have included in your DFDs all of the components necessary for the
system you are modeling. Not only must all necessary elements of a DFD be

2.

present, each of the components must be fully described in the data dictionary
Minimizing complexity - to avoid information overload
to divide information into small and relatively independent subsets. Each subset
should contain a comprehensible amount of information, e.g., fragmented DFDs.
Rules to avoid information overload: 72 (Millers Number)
(a) A single DFD should have no more than 9 processes.

(b) If a single DFD should have more than 5 processes, do not draw less than
5processes.
(c) No more than 9 data flows should enter or leave a process, data store, or data
3.

4.

element on a single DFD.

Consistency
whether the depiction of the system shown at one level of a nested set of DFDs is
compatible with the depictions of the system shown at other levels.
Rules for Primitives - the lowest level of decomposition for a data flow diagram
concerned about when to stop decomposing processes - when you have reached
the lowest logical level. What is that?
(a) when you have reduced each process to a single decision or calculation or to
a single database operation, such as update, create, delete, or read,
(b) when each data store represents data about a single entity, such as student,
course, enrollment, and faculty,
(c) when the system user does not care to see any more detail,
(d) when every data flow does not need to be split further to show that different
data are handled in different ways. All data flows in SRS are primitives
(e) when you believe that you have shown each business form or transaction,
computer on-line display, and report as a single data flow, e.g., the class
schedule as one single data flow,
(f) when you believe there is a separate process for each choice on all lowestlevel menu options for the system, e.g., in MS Word, File - Save As - Save.
Save is a primitive.

7. Mini Case
You always need to name data flows! Practice in class.
1. ABC is an e-Commerce retail company. It sells products through the internet. The
company needs to record customers, orders, and products. A customer put orders
and each order belongs to only one customer. An order may have several
transaction items and each transaction item matches a product, though one
transaction may contain more than one item of that product. Product information
includes description, price, and inventory level. ABCs web site allows customers

to put products into their shopping bag. When a customer finishes shopping, he
will proceed to check out. A customer can update the shopping bag before
checking out - changing the quantity or deleting an item. If the customer changes
the quantity, the product is still in the shopping bag but if the customer deletes a
product, it will be gone from the bag. Please draw DFD for this case. (hint:
assume the shopping bag is open and there is no need to retrieve for customer.)

2. At NCU, students take classes (sections). Each section is a course and there can be
many sections for a course. You can find courses without sections offered. An
enrollment is a file where the university records the grade for a student in a
particular section. Each section is taught by a professor but a professor can teach
many sections. She/he may not teach any section. When a semester starts, the
university will record all students and the sections they take in the enrollment data

file. After the semester is over, the university has to record the grade each student
gets. Then, the university will prepare the transcript. The university decides not to
keep a database for transcript because all content of a transcript can be got from
the existing files (referring to the ERD.) The university then will send transcripts
to students and their advisors who are faculty members. Please draw DFD for this
case.

3. Parking is a big problem for NCU. The university issues different types of parking
permits including handicap (H), SP1, SP2, F, S, and Commercial (C). The parking
structures are buildings and each building has information on the location, number
of spaces for each type of parking permit. The university has to keep track of the
sales of parking permits. The number of each type of parking permit cannot be
more than 120% of the total number of parking spaces for that type. Once this
number is reached, no new permit will be issued. Since many buildings are under
construction, the university needs to update the building information too.

4. The Purpose of the TEXTBOOK INVENTORY SYSTEM at a campus bookstore

is to supply textbooks to students for classes at a local university. The universitys
academic departments submit initial data about courses, sections, instructors,
textbooks, and projected enrollments to the bookstore on a TEXTBOOK
MASTER LIST. The bookstore generates a PURCHASE ORDER, which is sent
to publishing companies supplying textbooks. Book orders arrive at the bookstore
accompanied by a PACKING slip, which is checked and verified by the receiving
department. Students fill out a BOOK REQUEST that includes course
information. When they pay for their books, the students are given a SALES
RECEIPT.

8. Documenting DFD Components

(SRS Example)
Each element, including process, data store, and data flow, should be formally
defined.

8.1 Process Descriptions

1. Each process can be defined by a process decomposition until primitive processes.
2. A primitive can be defined by Structured English
Like programming statements without references to computer concepts.
(a) Rules for structured programming are followed, ex. IF...END IF, DO WHILE
(NOT),
(b) Indentation should be used.

8.2 Data Dictionary for the Processes in SRS Case

1.

Verify Prerequisite
Get registration request
Get Course
Get Transcript
WHILE NOT end of sections requested in the registration request, DO
Check prerequisites in each requested section from Course data store.
WHILE NOT end of prerequisite list, DO
Find the prerequisite in transcript
END DO
IF all prerequisites are in transcript
prerequisite verified for that course/section
Else
Send registration failure due to prerequisite to the student for failed
sections
End if
END DO
Send registration request with prerequisite verified to Check Room Availability

2.
3.

& Add to Waiting List process

Check Room Availability and Add to Waiting List = 3.1 + 3.2 + 3.3 + 3.4 + 3.5
Enroll
Get final registration request from Check Room Availability & Add to Waiting
List
WHILE NOT end of final registration request
add each enrollment request in the final registration request to Enrollment
data
store
send availability change to Section data store (Update seat available in

4.

Section data store)

END DO
Sent enrollment to Enrollment
Notify enrollment
Get enrollment from Enrollment
While NOT end of Enrollment, DO
find enrollments of the specified student

END DO
Search the section date, time, course id of each enrollment for the student from

5.

6.

7.

8.

Section data store

Send enrollment information to that student
Process 3.1 Receive registration request
Receive registration request for the sections whose prerequisites are verified
Send the request to Process 3.2
Process 3.2 Check room availability
Get registration request from Process 3.1
Get section information from Section data store
WHILE NOT end of sections in the registration request
IF seat available > 0
THEN add that section into registered section for that student
(part of final registration request)
ELSE send failed enrollment to Add to waiting list.
END IF
END DO
Send registered section for that student to Enroll
Process 3.3 Add to waiting list
Get failed enrollment from Check room availability.
Add that student and section to Waiting list data store.
Process 3.4 Add wait-listed student
Get sections to see if there is any section becomes available.
WHILE NOT end of all sections
IF seat available > 0
THEN get the FCFS (or other rules) student of that section from
Waiting list data store.
add that student with the section to student and section to be added.
Send student and section to be added to Enroll.
ELSE return
END IF
END DO

8.3 External Entity, Data Flow, Data Store and Attribute

Definitions
List all data elements in structured English. Example:
External Entity
Data Store
1. Student = 0N {student}
2. Course = 0N {course}
3. Section = 0N {section}
4. Enrollment = 0N {enrollment}
5. Transcript = 0N {transcript}
6. Waiting List = 0N {waiting__list}
Data Flow
1. student = student id + first name + last name + address + ...
2. section = schedule# + course id + instructor + room + enrollment + seat

4.

available
waiting_list = section + 0N {student + position} or
waiting_list = schedule# + student_id
seat_available = room_capacity (an attribute of ROOM) - # of enrollment

5.

for that section

registered section for that student = registration request with prerequisite

6.

verified and room available

student and section to be added = wait-listed student when section is

7.

available
final registration request = registered section for that student + student and

8.

section to be added
registration request = original registration request, containing all sections

9.

requested, from a student

registration failure due to prerequisite = notification sent by Verify

3.

Prerequisite that the course section a student chooses does not meet
prerequisite requirement
10. enrollment = student_id + schedule# + date_of_complete + grade
11. transcript = student + 0N {enrollment of that student}
12. course = course_id + title + credit

8.4 Example of Data Dictionary

At NCU, students take classes (sections). Each section is a course and there can be
many sections for a course. You can find courses without sections offered. An
enrollment is a file where the university records the grade for a student in a particular
section. Each section is taught by a professor but a professor can teach many sections.
She/he may not teach any section. When a semester starts, the university will record
all students and the sections they take in the enrollment data file. After the semester is
over, the university has to record the grade each student gets. Then, the university will
prepare the transcript. The university decides not to keep a database for transcript
because all content of a transcript can be got from the existing files (referring to the
ERD.) The university then will send transcripts to students and their advisors who are
faculty members.

Datastore
1. Enrollment = 0N {enrollment}
2. Student = 0N {student}
3. Course = 0N {course}
4. Course = 0N {course}
5. Section = 0N {section}
Dataflow
1. user request = user registration request or input grade request
2. user registration request = student + 0N {sections he wants to enroll}
3. input grade request = 0N {student + section + grade} , for updating student

4.
5.
6.
7.

grades in Enrollment
enrollment item = {student + section}, added to Enrollment
enrollment = {student + section + grade}
course = {cid + title + credit}
section = {schedule_no, date, time, room_id, cid, section_no,

seat_available}
8. transcript = student + 0N {section + course grade}
9. roster = section + 0N {student grade}
Processes
1. Add data
Get student registration request from USER
WHILE NOT end of the request DO
add enrollment to Enrollment
END DO
Return
Get input grade request from USER
update grade to Enrollment
RETURN
2. Report transcript
Get enrollments from Enrollment, sections from Section, courses from
Course, and
students from Student
Group data by students
WHILE NOT end of students DO
WHILE NOT end of sections taken by that student DO
add enrollments, sections, courses into transcript
END DO
format the transcript
send student transcript to STUDENT
END DO
RETURN
Group data by faculty id (an attribute of section)
WHILE NOT end of faculty DO
Group data by section
WHILE NOT end of sections DO
WHILE NOT end of students enrolled in that section DO
add enrollments, courses, students into roster

END DO
format the roster
END DO
send rosters to FACULTY
END DO
RETURN

9. Data Model and Process Model

1.

A dataflow contains data from entities. E.g., dataflow prerequisite contains

data from entity COURSE.

2.

CRUD (create, read, update, delete) matrix highlights data requirement for
each process. This table is for SRS example.

Chapter 5
Concepts of Object-Oriented Analysis
1.

Why Object Oriented Analysis?

1.

It reflects the way we think about the world.

2.

It provides a direct mapping between an Object-Oriented model of the

business and software components built using OO languages such as Java.
Much of the code can be constructed from pre-fabricated components.

3.

2.

Technical and Social Complexity

Basic Concept

2.1 Object
1.

A thing

2.

An object can be almost everything.

3.

Similar to an instance of an entity in ER model (but still different).

4.

A data structure and associated functions - this differs from traditional

approach where data model and process model are separate. cf., ERD and
DFD.

5.

Ex. A student called Britney Spears in SRS.

2.2 Class
1.

Definition
A class is the stencil from which objects are created (instantiated). Each
object has the same structure and behavior as the class from which it is
instantiated. Similar to an entity in ER model (but still different.)

2.

Ex. student in SRS

2.3 Attribute
A named property of a class that describes a range of values that instances of the
property may hold.
1. Export Control (Visibility)
(a) public: Any outside classifier with visibility of the given classifier can
use the feature, +.
(b) protected: Any descendant (i.e., subclasses) of the classifier can use the
feature, #.
(c) private: Only the classifier itself can use the feature, -. Not inherited by
subclasses.
(d) implementation: The element is visible only in the package in which it is
2.

defined.
Attributes can be read only. Usually read only attributes are derived.

Derived attribute is signaled by /.

Objects in the same class differ in different handles

2.4 Operation
An objects behavior. E.g., setStudent() , removeStudent (), and getStudent() .
Visibility: the visibility for attribute also applied.

2.5 Class Operation and Class Attribute

Operations and attributes only classes can have, e.g.,
1. operation: New
2. attribute: noOfStudent: Integer

3.
4.

Class attributes and operations are underlined.

e.g., nextOrderNum: Integer or bumpNextOrderNum( ) .

2.6 Instantiation
The fact that an object is created based on a class definition.
Student aStudent = new Student()2;
1. We define a class Student and declare a variable aStudent and create a new
object belonging to the class Student.
2. aStudent is a handle referring to this newly created object.
3. You can assign a different handle to the same object, ex.
Student sameStudent ;
sameStudent = aStudent;
Both sameStudent and aStudent refer to the same object.
Java Implementation of a Class
public class Student {
private String name;
private String major;
private String degree;
private Transcript transcript ;
private Vector attends ; // of Sections
setMajor(major);
setDegree(degree);
}

2.7 Method Signature

A specification on how a method is performed. It consists of name of the method,
arguments, and return type. E.g.,
1. void setName(String name);
method name: setName
argument: String name
return type void
This example enters a name.
2. boolean addSection(Section section); // in class Student
method name: addSection

Assume there is a cl ass called Student already.

argument: Section section

return type: boolean
This example will add a section for a student. It will return a message to
3.

notify the system the action successful or not.

boolean successfullyCompleted(Course course); // in class Transcript
This example will check if a course has been completed by a student.

2.8 Messages
An object (sender) requests another object (target) to carry out an activity via a
message. A message is a method/operation call.

2.9 Dot
1.

2.

2.10

Student x = new Student();

x.addSection(s);
We can do that because of a vector of Sections under Student.
Student x = new Student();
x.name = Britney Spears ;
The dot (.) allow us to get access to an objects operation or attribute.

Constructor

A constructor is a special method which

1. construct a new object,
2. does not have an explicit return type because the default return type is an
object, and
the method name is the same as the class name.

3.
Ex.,
Student();

2.11
1.
2.

Abstract Data Type

What is a data type? Ex., integer, number, char, varchar2, string...
In C,
int x;
means to declare x as a variable whose data type is an integer. How about Student

y?
This means to declare y as a variable whose data type is Student !!!

3.

In Student class we created in Section 5.2.6, Transcript is an ADT since Transcript

is a class.

4.

2.12

An ADT does not include the methods (operations).

Abstract Operations and Classes

1.
2.

Abstract Operations: operations not implemented

Abstract Classes: Classes do not instantiate objects.
So, this is an illegal message:
someAbstractClass.New;
e.g., Polygon and its operation getArea. If we make getArea an abstract operation
and Polygon an abstract class, then:
1. We are obliged to provide a concrete operation getArea for each shape.
2. There is no instantiation for class Polygon. We instantiate objects at
Polygons subclasses, e.g., triangle, rectangle, etc.
Here is an abstract class with an abstract operation:

Chapter 6
OOA Class Diagram
1.

Relationship

1.1 Associations
It is a relationship link between instances of classes. Figure 6 -13 shows a class
diagram. There is an association between Person and Company.
An association has these elements:
1. Name
Association name is Employment.
2. Role
(a) Each object in class Persons Role is Employee (in the association

3.

Employment.)
(b) Each object in class Companys Role is Employer.
Multiplicity (cardinality)
(a) Person multiplicity is 1..n, i.e., for each company, there can be 1 to
n persons.
(b) Company multiplicity is 0..1, i.e., for each person, he belongs to 0

4.

or 1 company.
Navigation
Traversal direction from one object to the other.
(a) Bidirectional
If we know the person, we know which company he belongs to. If
we know the company, we know who are its employees.

(b) Unidirectional
Given a user, we are able to know his password but not the other
way around. Figure shows a unidirectional association.

Figure 6-13 A Class Diagram

1.2 Whole / Part Associations

One class represents a larger thing (whole) which consists of smaller things (part).
Figure 6 -14 shows the two kinds of whole/part association.

Figure 6-14 Whole/Part Association Aggregation and Composition

1.

2.

Composition
(a) The composition object does not exist without its components.
(b) At any time, each given component object may be part of only one
composite.
(c) Composition is typically heteromeric.
(d) E.g., a glider is composed of fuselage, tail, and wings.
Aggregation
(a) The aggregate object may potentially exist without its constituent
objects.
(b) At any time, each object may be a constituent of more than one
aggregate.
(c) Aggregation tends to be homeomeric.
(d) E.g., a company is made of several departments, or an order is an
aggregation of several order lines.
(e) Hint: Aggregation is similar to Weak Entity in Relational model.

1.3 Association Class

The class to represent the properties of the relationship that apply to exactly one
pairing of the objects of the participating classes. Job is an association class in Figure
6 -13.

1.4 Generalization
A relationship between a general thing (superclass) and a more specific kind of that
thing (subclass).
1. The subclass inherits all the structure and behavior of the superclass.
2. The subclass may add new structure and behavior.
3. The subclass may modify the behavior of the superclass. E.g., getArea.

2.

Mini Cases
1.

ABC is an e-Commerce retail company. It sells products through the

internet. The company needs to record customers, orders, and products. A
customer put orders and each order belongs to only one customer. An order
may have several transaction items and each transaction item matches a
product, though one transaction may contain more than one item of that
product. The company also needs to record product information including
description, price, and inventory level. ABCs web site allows customers to
put products into their shopping bag. When a customer finishes shopping,
he will proceed to check out. A customer can update the shopping bag
before checking out - changing the quantity or deleting an item. If the
customer changes the quantity, the product is still in the shopping bag but if
the customer deletes a product, it will be gone from the bag. Please draw a
class diagram for this case.

Figure 6-15 Generalization

2.

At NCU, students take classes (sections). Each section is a course and there
can be many sections for a course. You can find courses without sections
offered. An enrollment is a file where the university records the grade for a
student in a particular section. Each section is taught by a professor but a
professor can teach many sections. She/he may not teach any section. When
a semester starts, the university will record all students and the sections they
take in the enrollment data file. After the semester is over, the university has
to record the grade each student gets. Then, the university will prepare the
transcript. The university decides not to keep a database for transcript
because all content of a transcript can be got from the existing files

(referring to the ERD.) The university then will send transcripts to students
and their advisors who are faculty members. Please draw a class diagram
for this case.

3.

Following the above case, NCU understands the importance to be able to

verify prerequisites. A course may be a prerequisite for many other courses.
A course can also have many prerequisite. The system get prerequisite for
the courses of the sections a student wants to be enrolled. It will check if the
student has finished all the prerequisites. If yes, the system will enroll that
student into the section he requested. Please draw a class diagram.

4.

Parking is a big problem for NCU. The university issues different types of
parking permits including handicap (H), SP1, SP2, F, S, and Commercial
(C). The parking structures are buildings and each building has information
on the location, number of spaces for each type of parking permit. The
university has to keep track of the sales of parking permits. The number of
each type of parking permit cannot be more than 120% of the total number
of parking spaces for that type. Once this number is reached, no new permit
will be issued. Since many buildings are under construction, the university
needs to update the building information too. Please draw a class diagram.

5.

The Purpose of the TEXTBOOK INVENTORY SYSTEM at a campus

bookstore is to supply textbooks to students for classes at a local university.
The universitys academic departments submit initial data about courses,
sections, instructors, textbooks, and projected enrollments to the bookstore
on a TEXTBOOK MASTER LIST. The bookstore generates a PURCHASE

ORDER, which is sent to publishing companies supplying textbooks. Book

orders arrive at the bookstore accompanied by a PACKING slip, which is
checked and verified by the receiving department. Students fill out a BOOK
REQUEST that includes course information. When they pay for their books,
the students are given a SALES RECEIPT. Please draw a class diagram.

3.

SRS Class Diagram

3.1 Problem Description

We have been asked to develop an automated Student Registration Systems (SRS) for
the university. This system will enable students to register on-line for classes each
semester. During the registration period preceding each semester, the SRS will verify
whether or not the student has satisfied the necessary prerequisites for each requested
class by referring the students on-line transcript of classes completed and grades
received. Assuming that (a) the prerequisites for the requested classes are satisfied,
and (b) there is room available in each of the classes, the student is enrolled in the
classes. Once a section is successfully registered, the system will notify the student.
When a section is not registered, either because of prerequisite not verified or room
not available, the system will also notify the student. The university maintains a
waiting list for each section. If (a ) is satisfied, but (b) is not, the student is placed on

the first-come, first-served waiting list. If a class/section that she/he was previously
wait-listed for becomes available, the first-come student will be automatically added
into that section.
F6-4 is the class diagram of SRS.

3.2 Some Points about the Attributes

1.

2.

attends:Vector
Vector is a special data type in java. It stores an array of data3. When the
relationship is M:M, you may consider a vector data type in one or Both of
the two related classes. E.g., in Student class, we have a vector enrolls
which stores all the sections this student is registered.
If you select only one vector (e.g., a vector under Student holding Sections,)
the relationship is unidirectional; otherwise (e.g., a vector under Student
holding Sections, and the other under Section holding Students), it is
bidirectional.
addSection()
Since we have a enrolls vector under Student class, the operation for adding
a section, addSection(), can be put under Student.

Figure 6-16 SRS Class Diagram

3.

addSection() or addStudent() ?
Either way.
(a) If there is a vector of Sections under Student, you can addSection().
If there is a vector of Students under Section, you can addStudent().

but it is conceptually slight different from an array. An array is fixed length but a
vector is variable length.
3

4.

5.

(b) Which one? Depends. If the registrar pulls out a student account
and wants to add a section to that student, addSection. If the
registrar pulls out a section account and wants to add a student to
that section, addStudent.
Vector and Composite Entity
If you have a vector for an M:M relationship, you do not need to have an
association class unless you want to put some attributes to that association
class to describe that relationship.
(a) Case 1: you want to put an attribute, e.g., grade of Enrollment.
(b) Case 2: you do not want to put an attribute, e.g., there is no
composite entity for the unary relationship of Course.
(c) Case 3: if you do not want to put an attribute for WaitingList, it is
only a vector
Aggregation
An aggregation implies a vector. In TS, you do not need to create a vector
for the aggregate.

Figure 6-17

4.

Even More Concept

4.1 Packages
Simply it is a group of logically related items. It is useful when we do enterprise
modeling.

4.2 Interface
It is a class without attributes so that other classes can utilize the methods defined in
that class.
In Figure 6 -17, EmployeeInterface is an Interface:
1. Class Person Uses (Imports) Interface EmployeeInterface - a dependency
relationship.
2. Interface EmployeeInterface are Exported (Realized) from Class Employee a realization relationship.

Chapter 7
OOA Object-Interaction Diagrams
Object-Interaction Diagrams show dynamic structure of an object-oriented system.
They can be either sequence diagrams or collaboration diagrams.

1.

Messages

1.1 What Is It?

A message is the vehicle by which a sender object obj1 conveys to a target object
obj2 a demand for object obj2 to apply one of its methods.

1.2 Example
Figure 7 -18 shows an example of transferring funds. This figure is a collaboration
diagram.
Message withdrawFunds
1. c is the sender of message withdrawFunds. c is an object of class Customer.
2. fromAccount is the target of message withdrawFunds.
3. fromAccount is pointed to by a variable fromAccount.
BankAccount fromAccount; - to declare the variable
fromAccount = new BankAccount(); - to create an object and assign variable
4.

fromAccount as the object

The message withdrawFunds may carry an operation and the target is the
owner of the operation.

fromAccount.withdrawFunds(in amountOfMoney, out withdrawOK);

Figure 7-18 Message of Transferring Funds

Message depositFunds
1. fromAccount is the sender of message depositFunds
The sender is not c: Customer because fromAccount is the delegation to
achieve fund transfer. Delegation is hidden from the Customer.
2.
3.

2.

toAccount is the target of message depositFunds.

toAccount is pointed to by a variable toAccount.
BankAccount toAccount; - to declare the variable
toAccount = new BankAccount(); - to create an object and assign variable

4.

fromAccount as the object

The message depositFunds may carry an operation and the target is the

5.

owner of the operation.

toAccount.depositFunds(in amountOfMoney, out depositOK);
The sender of message depositFunds is fromAccount instead of c shows the

6.

arguments are delegated from c.

The numbers of messages show the sequence.

Collaboration Diagram

A collaboration diagram is an interaction diagram that shows the sequence of

messages that implement an operation or a transaction. Figure 7 -18 is a
Collaboration Diagram.

3.

Sequence Diagram

One type of object-interaction diagram is sequence diagrams. Figure 7 -19 is the

sequence diagram counterpart for the transferring fund. Can you draw the class
diagram based on the sequence or collaboration diagram?
1. An object on top should belong to a class.
2. An object square has this format: object:Class.
3.

It is the target owns the operation.

Figure 7-19 The Sequence Diagram for Transferring Funds

3.1 Checking Prerequisite Example

Figure 7 -20 is an example for registration and checking prerequisite.

Figure 7-20 A Sequence Diagram Shows Registration and Checking Prerequisite

3.2 Mini Case

1.

At NCU, students take classes (sections). Each section is a course and there
can be many sections for a course. You can find courses without sections
offered. An enrollment is a file where the university records the grade for a
student in a particular section. Each section is taught by a professor but a
professor can teach many sections. She/he may not teach any section. When
a semester starts, the university will record all students and the sections they
take in the enrollment data file. After the semester is over, the university has
to record the grade each student gets. Then, the university will prepare the
transcript. The university decides not to keep a database for transcript
because all content of a transcript can be got from the existing files
(referring to the ERD.) The university then will send transcripts to students
and their advisors who are faculty members. Please draw a sequence
diagram for this case.

2.

ABC is an e-Commerce retail company. It sells products through the

internet. The company needs to record customers, orders, and products. A
customer put orders and each order belongs to only one customer. An order
may have several transaction items and each transaction item matches a
product, though one transaction may contain more than one item of that
product. The company also needs to record product information including
description, price, and inventory level. ABCs web site allows customers to
put products into their shopping bag. When a customer finishes shopping,
he will proceed to check out. A customer can update the shopping bag
before checking out - changing the quantity or deleting an item. If the
customer changes the quantity, the product is still in the shopping bag but if
the customer deletes a product, it will be gone from the bag. Please draw a
sequence diagram for this case.

3.

Following the NCU case, NCU understands the important to be able to

verify prerequisites and to allow waiting list for each section. A course may
be a prerequisite for many other courses. A course can also have many
prerequisite. When a student requests for enrollment, the registration system
will check the prerequisites of that section. Then, the system will check if
the student has finished all the prerequisites by referring to his transcript.
When it is done, the system will send a message to the student if the section
can be enrolled or not.

4.

Following the NCU case, NCU understands the important to be able to

verify prerequisites and to allow waiting list for each section. A course may
be a prerequisite for many other courses. A course can also have many
prerequisite. A waiting list contains the information of sections and the
students waiting for them. One section can allow many students to wait for
and a student can wait for many sections. The waiting students will be
placed into the waiting list on a first-come first serve rule and an email,
listing all the sections a student is waiting for, will be sent to her/him. NCU
has an automatic system to monitor the class/section availability. If the
class/section that she/he was previously waiting for becomes available
(either because some other student has dropped the class or because the

seating capacity for the class has been increased), the student is
automatically enrolled in the wait-listed class. Please draw a sequence
diagram.

Figure 7-21

Figure 7-22
5.

Parking is a big problem for NCU. The university issues different types of
parking permits including handicap (H), SP1, SP2, F, S, and Commercial
(C). The parking structures are buildings and each building has information
on the location, number of spaces for each type of parking permit. The
university has to keep track of the sales of parking permits. The number of

each type of parking permit cannot be more than 120% of the total number
of parking spaces for that type. Once this number is reached, no new permit
will be issued. Since many buildings are under construction, the university
needs to update the building information too. Please draw a sequence
diagram.

6.

The Purpose of the TEXTBOOK INVENTORY SYSTEM at a campus

bookstore is to supply textbooks to students for classes at a local university.
The universitys academic departments submit initial data about courses,
sections, instructors, textbooks, and projected enrollments to the bookstore
on a TEXTBOOK MASTER LIST. The bookstore generates a PURCHASE
ORDER, which is sent to publishing companies supplying textbooks. Book
orders arrive at the bookstore accompanied by a PACKING slip, which is
checked and verified by the receiving department. Students fill out a BOOK
REQUEST that includes course information. When they pay for their books,
the students are given a SALES RECEIPT. Please draw a sequence
diagram.

3.3 SRS Sequence Diagram

Problem Description
We have been asked to develop an automated Student Registration Systems (SRS) for

the university. This system will enable students to register on-line for classes each
semester. During the registration period preceding each semester, the SRS will verify
whether or not the student has satisfied the necessary prerequisites for each requested
class by referring the students on-line transcript of classes completed and grades
received. Assuming that (a) the prerequisites for the requested classes are satisfied,
and (b) there is room available in each of the classes, the student is enrolled in the
classes. Once a section is successfully registered, the system will notify the student.
When a section is not registered, either because of prerequisite not verified or room
not available, the system will also notify the student. The university maintains a
waiting list for each section. If (a ) is satisfied, but (b) is not, the student is placed on
the first-come, first-served waiting list. If a class/section that she/he was previously
wait-listed for becomes available, the first-come student will be automatically added
into that section.

Table 7-4 Operations from the SRS Sequence Diagram

Figure 7 -23 shows the sequence diagram for SRS case. Table 7 -4 lists the operations

we generate from Figure 7 -23.

Figure 7-23 SRS Sequence Diagram

Chapter 8
OOA Use Cases - Identify Scope
1.

Problem of Identifying Scope

1. Traditional requirements specifications often assume that the scope of the system
is already understood by all participants.
2. The diversity of requirements from different people can lead to direct
contradictions in expectations, and can also give rise to ambiguities where the
requirements can be interpreted in different ways.
3. Traditional approach cannot guarantee either that only the pertinent features are
captured (over specification) or that the system is fully specified (missing
specification.)

2.

Use Cases

1. A use case is a description of a set of sequence of actions, including variants, that

a system performs to yield an observable result of value to an actor.
2. It is a way of decomposing system functionality into smaller chunks, each focused
on a single usage of the system without presuming any specific design or
implementation.
3. They are used to capture user requirement.
4. They should have strong correlations with material in the user manual for the
system. E.g., you can explore the GUI design.

3.

Use Cases Diagrams

Figure 8 -24 shows a use case diagram.

1. Use cases
An individual function in a system. E.g., Place phone call, Place conference
call, etc.
2. Actors
An actor represents a coherent set of roles that users of use cases play when
interacting with these use cases. It can represent roles of a human, a hardware
device, or anther system.
3. Dependency
(a) Include
The base use case explicitly incorporates the behavior of another use case
at a location specified in the base. E.g., Use scheduler includes the
behavior of Look up calendar.
(b) Extend
The base use case implicitly incorporates the behavior of another use case
at a location specified indirectly by the extending use case. E.g., Place
conference call extends the behavior of Place phone call. I.e.,
functionality of Place phone call is extended by incorporating the
function of Place conference call.
4. Generalization - a kind of, see classes. E.g., Administrative user is a kind of
User.

4.

Modeling Techniques
1.
2.
3.
4.
5.
6.

Identify the actors who use this system.

Organize actors in generalization relationships.
Identify the primary behavior that each actor expects the system to provide.
Each behavior is a use case.
Factor common behavior into new use cases that are used by others - include.
Factor variant behavior into new use cases that extend more main line flows extend.

7. Organize these use cases and actors into a use case diagram.

Figure 8-24 A Use Case Diagram

5.

Stereotype

Stereotype allows additional classification of an element. Include and extend are

stereotypes of dependency. Actor has stereotypes of role, organization, device, and
system. Stereotypes are subtypes of an element.

6.

Draw a USE Case Diagram - SRS Example

1. Identify the actors
Student, Registrar, ...
2. Determine High-Level Use Cases for each actor. Actors may have overlapping user cases.
Student: Register for a section
Registrar: Register students
...
3. Determine sub use cases. Ex., Register student can be factored into
Verify that a student has met the prerequisites.
Check room availability for that class.
Place student in the waiting list.
Figure 8 -25 is a use case diagram for SRS.

Figure 8-25 SRS Use Case Diagram

Chapter 9
OOA Statechart Diagram
1. It shows the states that objects of that class may assume and the transitions the
objects may make from state to state.
2. One state diagram is for an attribute.
9.0.1 State Attribute
It has only a few possible values and there are significant restrictions on its transitions
from one value to another. E.g., status.

1.

Basic State Diagrams

Figure 9 -26 is a state diagram. This diagram shows some event cause the change of
values in attribute currInspectionStatus for class SellableItem. The changes trigger
different actions.

1.1 Elements
1. Start: the black spot shows the beginning of the transition of states.
2. State: it represents the states of an object during its lifetime, e.g., receive,
inInspection, accepted, and rejected.
3. Transition: the arrow represents the change from one state to another.
4. Event: it triggers a transition from one state to another. It is usually caused by an
inbound message to the object, e.g., inspectorSelectsItem, inspectorAcceptsItem,
and inspectorRejectsItem.
5. Action: it is triggered by an event. It is usually an outbound message from the

object, e.g., currShipment.logReject.

Figure 9-26 State Diagram for SellableItem.currInspectionStatus

2.

Nested States

Suppose we have a machine. The machine has four operating states (attribute opStat ):
standingBy, accelerating, running, and decelerating. But, the machine will not enter
these states unless the service state is inService. The service states (attribute
serviceStat) are inService, inRepair, and waitingForRepair. Figure 9 -27 shows the
operating states and Figure 9 -28 shows the service states.
In Figure 9 -27, self.ServiceStat = inService is a guard. It means that the
transition takes place only if the Boolean expression in brackets evaluates to true
when the triggering event occurs.
Since opStat occurs only when serviceStat is inService, we will put Figure 9 -27
inside inService state in Figure 9 -28. This creates a new diagram in Figure 9 -29.
The fact that opStat is within inService shows that opStat has meaning only when
serviceStat = inService.

2.1 Composite State

A state which has substates.

3.

History

We need history symbol in the situation that once the operation is interrupted, it has to
go back to the state right before the interruption instead of the start.
Figure 9 -30 shows a state diagram of a Washing Machine with history. When
door is closed, we enter the runnable state and when the door is opened, we exit to the
paused state. When the door is closed again, we return to the previous state instead of
stopped.

Figure 9-27 The State Diagram for Machine.opStat

Figure 9-28 The State Diagram for Machine.ServiceStat

Figure 9-29 A Nested State Diagram

Figure 9-30 A State Diagram of WashingMachine with history

4.

Concurrent States

Figure 9 -31 shows an example of concurrent states. The order is approved only if
both credit manager and customer manager approve.

Figure 9-31 Concurrent States

Chapter 10
OOA Activity Diagram
A diagram shows the flow from activity to activity.

1.
1.

2.
3.
4.

Components
Activity
An activity is an ongoing execution in a state. It ultimately results in some
action.
Transition
A flow from one activity to another activity.
Branch
Other components
An activity diagram shares many components of a state diagram.

Figure 10 -32 shows two activity diagram. One has branch and the other has not.

Figure 10-32 Activity Diagrams

2.

More on Concurrent and Synchronization

UML uses forks and joins to represent concurrent flows and synchronization in
activity diagrams.
In Figure 10 -33, continue work and the flow of process order, pull materials
and ship order are done concurrently. After they are synchronized, the process goes on
to receive order and bill customer. These two are concurrent too.

3.

Swimlane

An activity diagram can be partition into groups. Each group represents the business
organization responsible for those activities. Ex, in Figure 10 -33, we have Customer,
Sales, and Warehouse. Groups are separated by swimlanes.

Figure 10-33 An Activity Diagram shows Flows of Controls Using Swimlanes and
Fork/Join

4.

Object Flow

Objects can be put into an activity diagram. They are connected by dependencies or
object flows - a dashed line. The brackets beneath the object name represent the state.