Shu
©
All Rights Reserved

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
2.2
Context Diagram .......................................................................... 20
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
8.3
8.4
Data Dictionary for the Processes in SRS Case ........................... 35
External Entity, Data Flow, Data Store and Attribute Definitions
37
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.6
2.7
2.8
2.9
2.2
2.3
2.4
2.5
Class ............................................................................................. 44
Attribute ....................................................................................... 44
Operation...................................................................................... 44
Class Operation and Class Attribute ............................................ 45
Instantiation.................................................................................. 45
Method Signature ......................................................................... 46
Messages ...................................................................................... 46
Dot................................................................................................ 46
2.10
2.11
Constructor ................................................................................... 47
Abstract Data Type ...................................................................... 47
2.12
Abstract Operations and Classes .................................................. 47
Chapter6 ....................................................................................................................... 49
1.
Relationship ................................................................................................. 49
1.1
Associations ................................................................................. 49
1.2
1.3
Whole / Part Associations ............................................................ 50
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
4.2
Packages ....................................................................................... 57
Interface ....................................................................................... 58
Chapter7 ....................................................................................................................... 59
1.
Messages ...................................................................................................... 59
1.1
1.2
What Is It? .................................................................................... 59
Example ....................................................................................... 59
2.
Collaboration Diagram................................................................................. 60
3.
Sequence Diagram ....................................................................................... 61
3.1
3.2
Checking Prerequisite Example ................................................... 61
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

T ABLE 1-1 A G ANTT C HART TO BE FILLED .................................................................... 7
T ABLE 1-2 I NFORMATION FOR A CPM ............................................................................ 7
T ABLE 4-1 R ULES OF C REATING DFD S ......................................................................... 29
T ABLE 7-1 O PERATIONS FROM THE SRS S EQUENCE D IAGRAM ..................................... 67

F IGURE 2-1 S YSTEMS D EVELOPMENT L IFE C YCLE ....................................................... 10
F IGURE 3-1 E NTITY R ELATIONSHIP D IAGRAM OF S TUDENT R EGISTRATION S YSTEM ,
V ERSION 2 ............................................................................................................ 17
F IGURE 4-1 G ANE & S ARSON DFD S YMBOLS ............................................................... 20
F IGURE 4-2 A C ONTEXT D IAGRAM ................................................................................ 20
F IGURE 4-3 C ONTEXT D IAGRAM OF A S HOPPING C ASE ................................................. 21
F IGURE 4-4 L EVEL -0 DFD FOR S HOPPING C ASE ........................................................... 21
F IGURE 4-5 L EVEL -1 DFD FOR S ELECT P RODUCT P ROCESS ......................................... 22
F IGURE 4-6 L EVEL -1 DFD FOR P URCHASE P RODUCT P ROCESS .................................... 23
F IGURE 4-7 A N U NBALANCED S ET OF DFD S ................................................................ 24
F IGURE 4-8 T HE C ONTEXT D IAGRAM OF S TUDENT R EGISTRATION S YSTEM ................. 25
F IGURE 4-9 L EVEL -0 DFD OF S TUDENT R EGISTRATION S YSTEM .................................. 26
F IGURE 4-10 L EVEL -1 DFD FOR
“C
HECK R OOM A VAILABILITY & A DD TO W AITING
L IST
”
S UBSYSTEM ................................................................................................. 27
F IGURE 6-1 A C LASS D IAGRAM .................................................................................... 50
F IGURE 6-2 W HOLE /P ART A SSOCIATION
–
A GGREGATION AND C OMPOSITION .............. 50
F IGURE 6-3 G ENERALIZATION ....................................................................................... 52
F IGURE 6-4 SRS C LASS D IAGRAM ................................................................................ 56
F IGURE 6-5 ................................................................................................................... 57
F IGURE 7-1 M ESSAGE OF T RANSFERRING F UNDS .......................................................... 60
F IGURE 7-2 T HE S EQUENCE D IAGRAM FOR T RANSFERRING F UNDS .............................. 61
F IGURE 7-3 A S EQUENCE D IAGRAM S HOWS R EGISTRATION AND C HECKING
P REREQUISITE ....................................................................................................... 62
F IGURE 7-4 ................................................................................................................... 65
F IGURE 7-5 ................................................................................................................... 65
F IGURE 7-6 SRS S EQUENCE D IAGRAM ......................................................................... 68
F IGURE 8-1 A U SE C ASE D IAGRAM ............................................................................... 71
F IGURE 8-2 SRS U SE C ASE D IAGRAM .......................................................................... 72
F IGURE 9-1 S TATE D IAGRAM FOR S ELLABLE I TEM .
CURR I NSPECTION S TATUS ................ 74
F IGURE 9-2 T HE S TATE D IAGRAM FOR M ACHINE .
OP S TAT ............................................. 75
F IGURE 9-3 T HE S TATE D IAGRAM FOR M ACHINE .S
ERVICE S TAT .................................... 76
F IGURE 9-4 A N ESTED S TATE D IAGRAM ........................................................................ 76
F IGURE 9-5 A S TATE D IAGRAM OF W ASHING M ACHINE WITH HISTORY .......................... 77
F IGURE 9-6 C ONCURRENT S TATES ................................................................................ 77
F IGURE 10-1 A CTIVITY D IAGRAMS ............................................................................... 78
F IGURE 10-2 A N A CTIVITY D IAGRAM SHOWS F LOWS OF C ONTROLS U SING S WIMLANES
AND F ORK /J OIN ..................................................................................................... 79

Develop PERT/CPM chart and Gantt chart (Table 1-1)
1.
(a)
A CPM will be drawn on the blackboard
D
E
B
C
ID Duration Task
A 2
Start
Name Date
End
Date
Task 1 1/10/20 2/10/20
October 2020
30 1 2 3
3
4
1
1
Task 2 2/10/20
Task 3 3/10/20
Task 4 4/10/20
4
Task 5 5/10/20
Table 1-1 A Gantt Chart - to be filled
5 7 6 9 8
Task Duration Precedence
A 2
B 3 A
C 4 A
D 1 B, C
E 1 D
Table 1-2 Information for a CPM

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 instead of making changes throughout the entire system.
2.
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.
3.
Purpose
All components work all together to achieve some purpose.
4.
Environment
A system exists in an environment and exchanges data and information with its environment.
5.
Interfaces
The points that a system meets its environment
6.
Constraints
The limits to what a system can do and how a system can achieve its purpose
7.
Input
Whatever a system takes from its environment in order to fulfill its purpose
8.
Output
Whatever a system returns to its environment in order to fulfill its purpose

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
1 Data Modeling, aka Information Engineering Approach
 A technique for organizing and documenting a system’s data

Tool: Entity Relationship Diagram
2 Process Modeling, aka Structured Approach

A technique for organizing and documenting the structure and flow of data through a system’s 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
3 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
Figure 2-1 Systems Development Life Cycle

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 occurrence, entity instance
2.
Attribute
A named property of an entity that is of interest to the organization, ex. first_ name, last_name, middle_initial.
3.
Primary Key
An attribute, or combination of attributes (composite key), that uniquely identifies each instance of an entity
4.
Foreign Keys
An attribute (possibly composite) that appears as a non-key attribute in an entity and as a primary key attribute in the related entity.
5.
Relationship
An association between the instances of one or more entity types (participants), e.g.,

PROFESSOR <TEACHES> SECTION


STUDENT <ENROLL> SECTION
6.
Cardinality (Multiplicity)
The specific number (minimum, maximum) of instances associated with one 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.
7.
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.
8.
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!

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)
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 student’s 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.

1.
Find all nouns.
2.
Eliminate duplicates
3.
Eliminate references to the system itself.
4.
Eliminate references to the organization in question; i.e., the university
5.
Eliminate other miscellaneous terms which don’t seem to be entities.
6.
Group apparent synonyms, e.g., transcript implies a record of ‘courses com- pleted’ and ‘grades received’.
7.
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.
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-1 is the ERD for Student Registration System
COURSE SECTION
Or
PREREQ
ENROLL
MENT
STUDENT
Figure 3-1 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*(?)

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
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 destinations.
2.
Data store
Data at rest: physical location of data, e.g., file, folder, directory, etc.
3.
Process
Work or actions performed on data
4.
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-1 shows Gane and Sarson DFD symbols
1
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-2 is a context diagram.
Figure 4-3 is the context diagram of a typical shopping case.
Figure 4-1 Gane & Sarson DFD Symbols
Figure 4-2 A Context Diagram
1
To draw a DFD using Visio, you need to choose Gane & Sarson DFD from
Software Diagram in stead of Data Flow Diagram from Flowchart.

Figure 4-3 Context Diagram of a Shopping Case
A DFD that represents a system’s 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
Figure 4-4 Level-0 DFD for Shopping Case
.
SHELF returned product product picked up
Select
Product
CUSTOMER product selection receipt…
CASHIER Purchase
Product selected product
Cart selected products
Wallet payment bagged products
Car

payment…
Figure 4-4 Level-0 DFD for Shopping Case
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 DFD’s, Figure 4-5 and
Figure 4-6.
Figure 4-5 Level-1 DFD for Select Product Process

Cart
Wallet
Car selected products payment bagged product
Get
Products
Check Out products from cart
Place
Products for checkout Check-out products to purchase initiation receipt…
CASHIER payment
Figure 4-6 Level-1 DFD for Purchase Product Process
The conservation of inputs and outputs to a data flow diagram process when that
process is decomposed to a lower level. Figure 4-7 shows that the context DFD and
the level-1 DFD are unbalanced.
In Figure 4-7, the context DFD only has one source but in the level-0 DFD, two
sources appear.
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-7 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 student’s 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-8 is the context diagram of
Student Registration System.

Figure 4-8 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-9 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-10 shows Level-1 DFD segment for Process 3, Check Room ava-
ilability.
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-9 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-10 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 common location.
(d) A data flow cannot go directly back to the same process it leaves.
(e) A data flow to a data store means save, update, or delete.
(f) A data flow from a data store means retrieve or use.
(g) 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-1shows the DFD rules in DFD symbols:

Table 4-1 Rules of Creating 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 present, each of the components must be fully described in the data dictionary
2.
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: 7±2 (Miller’s 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 element on a single DFD.
3.
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.
4.
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 lowest-level menu options for the system, e.g., in MS Word, File - Save As -
Save. Save is a primitive.
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. ABC’s 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 university’s 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.

(SRS Example)
Each element, including process, data store, and data flow, should be formally defined.
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.
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
& Add to Waiting List’ process
2.
Check Room Availability and Add to Waiting List = 3.1 + 3.2 + 3.3 + 3.4 + 3.5
3.
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
Section data store)
END DO
Sent enrollment to Enrollment
4.
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
Section data store
Send enrollment information to that student
5.
Process 3.1 Receive registration request
Receive registration request for the sections whose prerequisites are verified
Send the request to Process 3.2
6.
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
7.
Process 3.3 Add to waiting list
Get ‘failed enrollment’ from ‘Check room availability’.
Add that student and section to ‘Waiting list’ data store.
8.
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
List all data elements in structured English. Example:
External Entity
Data Store
1.
Student =
N
0
{ student}
2.
Course =
N
0
{ course}

3.
Section =
N
0
{ section}
4.
Enrollment =
N
0
{ enrollment }
5.
Transcript =
N
0
{ transcript }
6.
Waiting List =
N
0
{ waiting__l ist}
Data Flow
1.
student = student id + first name + last name + address + ...
2.
section = schedule# + course id + instructor + room + enrollment + seat available
3.
waiting_list = section +
N
0
{ student + position} or waiting_list = schedule# + student_id
4.
seat_available = room_capacity (an attribute of ROOM) - # of enrollment for that section
5.
registered section for that student = registration request with prerequisite verified and room available
6.
student and section to be added = wait-listed student when section is available
7.
final registration request = registered section for that student + student and section to be added
8.
registration request = original registration request, containing all sections requested, from a student
9.
registration failure due to prerequisite = notification sent by ‘Verify
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 +
N
0
{ enrollment of that student}
12.
course = course_id + title + credit

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 =
N
0
{ enrollment }
2.
Student =
N
0
{ student}
3.
Course =
N
0
{ course}
4.
Course =
N
0
{ course}

5.
Section =
N
0
{ section}
Dataflow
1.
user request = user registration request or input grade request
2.
user registration request = student +
N
0
{ sections he wants to enroll}
3.
input grade request =
N
0
{ student + section + grade} , for updating student grades in Enrollment
4.
enrollment item = {student + section}, added to Enrollment
5.
enrollment = {student + section + grade}
6.
course = {cid + title + credit}
7.
section = {schedule_no, date, time, room_id, cid, section_no, seat_available}
8.
transcript = student +
N
0
{ section + course
 grade}
9.
roster = section +
0
N
{ 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
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.

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.
Technical and Social Complexity
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.

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
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 defined.
2.
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
An object’s behavior. E.g., setStudent() , removeStudent () , and getStudent() .
Visibility: the visibility for attribute also applied.

Operations and attributes only classes can have, e.g.,
1.
operation: New
2.
attribute: noOfStudent: Integer
3.
Class attributes and operations are underlined.
4.
e.g., nextOrderNum: Integer or bumpNextOrderNum( ) .
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.
3.
aStudent is a handle referring to this newly created object.
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 Assume there is a cl ass called Student already.

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 argument: Section section return type: boolean
This example will add a section for a student. It will return a message to notify the system the action successful or not.
3.
boolean successfullyCompleted(Course course); // in class Transcript
This example will check if a course has been completed by a student.
An object (sender) requests another object (target) to carry out an activity via a message. A message is a method/operation call.
1.
Student x = new Student(); x.addSection(s);
We can do that because of a vector of Sections under Student.
2.
Student x = new Student(); x.name = “Britney Spears ”;
The dot (.) allow us to get access to an object’s operation or attribute.

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
3.
the method name is the same as the class name.
Ex.,
Student();
1.
What is a data type? Ex., integer, number, char, varchar2, string...
2.
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.
An ADT does not include the methods (operations).
1.
Abstract Operations: operations not implemented
2.
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
Polygon’s subclasses, e.g., triangle, rectangle, etc.
Here is an abstract class with an abstract operation:

It is a relationship link between instances of classes. Figure 6-1 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
Person’s
Role is Employee (in the association
Employment .)
(b) Each object in class
Company’s
Role is Employer .
3.
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 or 1 company.
4.
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-1 A Class Diagram
One class represents a larger thing (whole) which consists of smaller things (part).
Figure 6-2 shows the two kinds of whole/part association.
Figure 6-2 Whole/Part Association – Aggregation and Composition

1.
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.
2.
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.
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-1.
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.
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. ABC’s 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-3 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 university’s 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.
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 student’s 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.
1.
attends:Vector
Vector is a special data type in java. It stores an array of data
3
. 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.
2.
addSection()
Since we have a enrolls vector under Student class, the operation for adding a section, addSection() , can be put under Student .
Figure 6-4 SRS Class Diagram
3 but it is conceptually slight different from an array. An array is fixed length but a vector is variable length.

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() .
(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.
4.
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
5.
Aggregation
An aggregation implies a vector. In TS, you do not need to create a vector for the aggregate.
Figure 6-5
Simply it is a group of logically related items. It is useful when we do enterprise modeling.

It is a class without attributes so that other classes can utilize the methods defined in that class.
In Figure 6-5,
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.

Object-Interaction Diagrams show dynamic structure of an object-oriented system.
They can be either sequence diagrams or collaboration diagrams.
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.
Figure 7-1 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 fromAccount as the object
4.
The message withdrawFunds may carry an operation and the target is the

owner of the operation . fromAccount.withdrawFunds(in amountOfMoney, out withdrawOK);
Figure 7-1 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.
toAccount is the target of message depositFunds .
3.
toAccount is pointed to by a variable toAccount .
BankAccount toAccount; - to declare the variable toAccount = new BankAccount (); - to create an object and assign variable fromAccount as the object
4.
The message depositFunds may carry an operation and the target is the owner of the operation .
toAccount.depositFunds(in amountOfMoney, out depositOK);
5.
The sender of message depositFunds is fromAccount instead of c shows the arguments are delegated from c .
6.
The numbers of messages show the sequence.
A collaboration diagram is an interaction diagram that shows the sequence of

messages that implement an operation or a transaction. Figure 7-1 is a Collaboration
Diagram.
One type of object-interaction diagram is sequence diagrams. Figure 7-2 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-2 The Sequence Diagram for Transferring Funds
Figure 7-3 is an example for registration and checking prerequisite.

Figure 7-3 A Sequence Diagram Shows Registration and Checking Prerequisite
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. ABC’s 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-4
Figure 7-5
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 university’s 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.
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 student’s 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-1 Operations from the SRS Sequence Diagram
Figure 7-6
shows the sequence diagram for SRS case. Table 7-1 lists the operations we
generate from Figure 7-6 .

Figure 7-6 SRS Sequence Diagram

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.)
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.

Figure 8-1 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.
1.
Identify the actors who use this system.
2.
Organize actors in generalization relationships.
3.
Identify the primary behavior that each actor expects the system to provide.
4.
Each behavior is a use case.
5.
Factor common behavior into new use cases that are used by others - include.

6.
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-1 A Use Case Diagram
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.
1.
Identify the actors
Student, Registrar, ...
2.
Determine High-Level Use Cases for each actor. Actors may have over- lapping 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-2 is a use case diagram for SRS.
Figure 8-2 SRS Use Case 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.
Figure 9-1 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.
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-1 State Diagram for SellableItem.currInspectionStatus
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-2 shows the
operating states and Figure 9-3 shows the service states.
In Figure 9-2,
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-2
inside inService
state in Figure 9-3. This creates a new diagram in Figure 9-4. The
fact that opStat is within inService shows that opStat has meaning only when serviceStat = inService .

A state which has substates.
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-5 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-2 The State Diagram for Machine.opStat

Figure 9-3 The State Diagram for Machine.ServiceStat
Figure 9-4 A Nested State Diagram

Figure 9-5 A State Diagram of WashingMachine with history
Figure 9-6 shows an example of concurrent states. The order is approved only if both
credit manager and customer manager approve.
Figure 9-6 Concurrent States

A diagram shows the flow from activity to activity.
1.
Activity
An activity is an ongoing execution in a state. It ultimately results in some action.
2.
Transition
A flow from one activity to another activity.
3.
Branch
4.
Other components
An activity diagram shares many components of a state diagram.
Figure 10-1 shows two activity diagram. One has branch and the other has not.
Figure 10-1 Activity Diagrams

UML uses forks and joins to represent concurrent flows and synchronization in activity diagrams.
In Figure 10-2,
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 b i ll customer . These two are concurrent too.
An activity diagram can be partition into groups. Each group represents the business
organization responsible for those activities. Ex, in Figure 10-2, we have
Customer ,
Sales , and Warehouse . Groups are separated by swimlanes.
Figure 10-2 An Activity Diagram shows Flows of Controls Using Swimlanes and
Fork/Join

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.