Transcript Introduction to Object Orientation 28 January 2002

Software Design
and
Development
Kittipong Klomklaum
Senior System Analyst / Data Modeler
Bank of Thailand
[email protected]
O
O
A
D
Page
COURSE OUTLINE
: 2
O
O
A
D
Chapter 1
Software Development
Lifecycles
(SDLC)
Page
: 3
O
O
A
D
Chapter 1. Software Development Lifecycles (SDLC)
Software Development Lifecycles (SDLC)
SDLC is the methodology for developing software
SDLC is a tight combination of software development phases and
process model.
Software Development Phases = Requirement + Analysis + Design
+ Build
Process Model = The model that represents Directions and Activities
of System Development Phases
Page
: 4
O
O
A
D
Chapter 1. Software Development Lifecycles (SDLC)
1. Phases of Software Development
Requirements Acquisition :
To explore and ask what is the set of “needed to solved”
problems?
Requirement Analysis:
To try to answer the question “What should the software do to
solve the problems?”
Software Design:
To try to answer the question “How the software solve the
problems?”
Software Build:
To try to implement the answer to the question “How the software
solve the problems?”
Page
: 5
O
O
A
D
Chapter 1. Software Development Lifecycles (SDLC)
2. Software Development Process Models
Requirement
Acquisition
Waterfall Process Model
Analysis
Design
Build
Requirement
Acquisition
Incremental Process Model
Analysis
Design
Build
Requirement
Acquisition
Analysis
Design
Requirement
Acquisition
Analysis
Requirements
Spiral Process Model
Build
Design
Version 1
Page
: 6
Version 2
Version 3
Version 4
Build
Analysis
Design
Build
O
O
A
D
Chapter 1. Software Development Lifecycles (SDLC)
2. Software Development Process Models
Positive and Negative Factors to the Success of Process Model
•Stabilities of user requirements
•Association from steakholders
•Flexibilities on budgets management
•Efficiency of project manangement
•Etc.
•Inefficient change management
•Budget Problems
•Underestimation of work
•Lacking of user participation
•Etc.
Page
: 7
O
O
A
D
Chapter 1. Software Development Lifecycles (SDLC)
Waterfall Process Model
Requirement
Acquisition
Analysis
Design
Build
So called, sequential process model, waterfall process model prefers the
end-to-end (one-shot) plan. Therefore user requirements must be
(1) Clearly and completely understood.
(2) Stable over the development period.
In waterfall process model, after one phase finished, normally, revision
is not allowed . To cover the risk, signoff for each phase before working
on the next phase is recommended.
Page
: 8
O
O
A
D
Chapter 1. Software Development Lifecycles (SDLC)
Waterfall Process Model
Requirement
Acquisition
Analysis
Design
Build
Waterfall process model is the oldest and the most classic process model:
Simple / No complicated manangement needed.
Waterfall process model causes many problems:
The changes on development process could not easily asserted if the
development proceeded.
A working version will be produced only when the the development
success as a whole.
Uncertainty of requirement could not be handled in waterfall process
model.
Page
: 9
O
O
A
D
Chapter 1. Software Development Lifecycles (SDLC)
Waterfall Process Model
Time Passed : Risk Increase
Risk
Requirement
Acquisition
Analysis
Design
Build
Time
Page
: 10
O
O
A
D
Chapter 1. Software Development Lifecycles (SDLC)
Waterfall Process Model
With Positive Factors : Time Passed : Risk Increase more Slowly
Positive Factors
Requirement
Acquisition
Analysis
Risk
Design
Build
Time
Page
: 11
O
O
A
D
Chapter 1. Software Development Lifecycles (SDLC)
Incremental Process Model
Requirement
Acquisition
Analysis
Design
Build
Requirement
Acquisition
Analysis
Design
Requirement
Acquisition
Build
Analysis
Design
Incremental Process Model delivers a reduced set of functions of
software, which is enhanced in each iteration. In addition,
iterations can occur between steps.
The incremental approach to software development starts to delivers
limited function earlier than other approaches, with correnponding
faster return on investment. However it requires
•
Careful planning
•
Very tight management control.
Page
: 12
Build
O
O
A
D
Chapter 1. Software Development Lifecycles (SDLC)
Incremental Process Model
Requirement
Acquisition
Analysis
Design
Build
Requirement
Acquisition
Analysis
Design
Requirement
Acquisition
Delivery of 1st Increment
(20% of Requirement)
Delivery of 2nd Increment
Build
(45% of Requirement)
Analysis
Design
Build
Delivery of
Complete Version
(Nth increment)
Incremental process model deliver partial-bodies of software when time passed.
Early increment is often a core product. ( product that address normal/critical
requirements)
Incremental process model is useful for:
Relieve the staffing problem.
The changes can be handled in the next incremental.
Incremental process can cause problems because:
Increment needs an efficient version control mechanism.
Page
: 13
O
O
A
D
Chapter 1. Software Development Lifecycles (SDLC)
Incremental Process Model
Positive Factors
Requirement
Acquisition
Analysis
Design
Build
Requirement
Acquisition
Analysis
Design
Requirement
Acquisition
Build
Analysis
Design
Build
Risk
Time
Incremental Process Model :Tend to Success
Page
: 14
O
O
A
D
Chapter 1. Software Development Lifecycles (SDLC)
Incremental Process Model
Requirement
Acquisition
Risk
Analysis
Design
Build
Requirement
Acquisition
Analysis
Design
Requirement
Acquisition
Build
Analysis
Design
Build
Positive Factors
Time
Incremental Process Model :Tend to Fail !
Page
: 15
O
O
A
D
Chapter 1. Software Development Lifecycles (SDLC)
Spiral Process Model
Analysis
Requirements
Build
Design
Version 1
Version 2
Version 3
Version 4
Page
•Spiral process model is similar to incremental process model.
•Each cycle of spiral process model output the prototype and leter version of
software.
•Each development methodology could be recurred and improve in each cycle.
•Like incremental process model, user association is significant to the success of
development.
•At the end of each cycle: revision and evaluation is needed for the improvement
: 16
of development on the next phase
O
O
A
D
Chapter 1. Software Development Lifecycles (SDLC)
Spiral Process Model
Positive Factors
Requirement
Acquisition
Analysis
Design
Build
Requirement
Acquisition
Analysis
Design
Requirement
Acquisition
Build
Analysis
Design
Build
Risk
Time
Spiral Process Model :Tend to Success
Page
: 17
O
O
A
D
Chapter 1. Software Development Lifecycles (SDLC)
Spiral Process Model
Requirement
Acquisition
Risk
Analysis
Design
Build
Requirement
Acquisition
Analysis
Design
Requirement
Acquisition
Build
Analysis
Design
Build
Positive Factors
Time
Spiral Process Model :Tend to Fail !
Page
: 18
O
O
A
D
Chapter 2
Requirements
Acquisition
Page
: 19
O
O
A
D
Chapter 2. Requirements Acquisition
Requirements Acquisition
To analyze is to try to answer the question:
WHAT THE SOFTWARE DO?,
based on the requirement of users.
The analysis cannot be accomplished completely without the exact
requirements
Before analyze requirements it is very needed to
”ACQUIRE EXACT REQUIREMETNS from USERS”
and model the requirement on users’ perspective
Page
: 20
O
O
A
D
Chapter 2. Requirements Acquisition
Requirements Acquisition
To acquire requirements is to:
1.
2.
3.
4.
Page
: 21
Initialize requirements acquisition session.
Run requirements acquisition process.
Summarize the requirements.
If required, reprocess the acquisition.
O
O
A
D
Chapter 2. Requirements Acquisition
Requirements Acquisition
1. Initialize requirements acquisition
The easiest way for requirement acquisition is to conduct a
meeting or interview
At beginning, the the communication must be initialized by
•
•
•
Page
: 22
explaining explaining the importance of development
explaining the effects of system on users and stakeholders
explaining the expected association from users and
stakeholders.
O
O
A
D
Chapter 2. Requirements Acquisition
Requirements Acquisition
2. Run the acquisition process
To run a meeting or interview is to ask context-free questions and to
ask meta questions:
Context-free Questions: A set of questions that will be lead to
- basic understanding of the problem
- basic understanding of people who need solutions
- basic understanding of nature of desired solutions
Meta Questions: A set of questions that are asked to
- clarify the context-free questions
- confirm the understanding on questions and answers
Page
: 23
-
O
O
A
D
Chapter 2. Requirements Acquisition
Requirements Acquisition
2. Run the acquisition process (cont.)
The acquisition process should be partitioned into many subsessions,
each sub-session should be divided into 3 phases
1st phase: source of solutions/ benefit of successful solutions
2nd phase: problem understanding
3rd phase: clarify and confirmation
Page
: 24
O
O
A
D
Chapter 2. Requirements Acquisition
Requirements Acquisition
2. Run the acquisition process (cont.)
1st phase: the first set of context-free questions should be asked by
the analysts are:
•
•
•
•
Page
: 25
Who are behind the solution request?
Who will use the solution?
Who will get the benefit if the solution is successful?
Are there any other sources of solution that needed?
O
O
A
D
Chapter 2. Requirements Acquisition
Requirements Acquisition
2. Run the acquisition process (cont.)
2nd phase: the second set of context-free questions should be asked
by the analysts are:
•
•
•
•
Page
: 26
How would you characterize GOOD output that will be generated
by a successful solution?
What are the exact problems this solution address?
Can you describe the environment of the problem?
What will happen or what will you need if some conditions/
environments changed?
O
O
A
D
Chapter 2. Requirements Acquisition
Requirements Acquisition
2. Run the acquisition process (cont.)
3rd phase: the second set of meta questions should be asked by the
analysts are:
•
•
•
Page
: 27
Are my questions relevant to the problem you have?
Should I ask anything else?
Do you have any additional questions or suggestions?
O
O
A
D
Chapter 2. Requirements Acquisition
Requirements Acquisition
3. Summarize the requirements
QFD: Quality Function Deployment
QFD is a quality technique that translates needs of customer
into technical requirements for S/W. (QFD is first used by
Mitsubishi Heavy Industry Co.,Ltd., 1970s)
The Methodology to Classify the Users’ Requirements to:
•
•
•
Page
: 28
Normal Requirements
Expected Requirements
Exciting Requirements
O
O
A
D
Chapter 2. Requirements Acquisition
Requirements Acquisition
3. Summarize the requirements
QFD: Normal Requirements
•
•
Objectives and goals stated during the meeting with customers.
The customers quite satisfy with these requirements.
Example:
Page
: 29
- specific system functions
- favorite level of performance
O
O
A
D
Chapter 2. Requirements Acquisition
Requirements Acquisition
3. Summarize the requirements (cont.)
QFD: Expected Requirements
•
•
Fundamental requirements that are forgotten by customers
The absence of these requirements cause significantly
dissatisfaction to software
Example:
Page
: 30
- error handling and recovery
- user interface quality
- ease of installation
O
O
A
D
Chapter 2. Requirements Acquisition
Requirements Acquisition
3. Summarize the requirements (cont.)
QFD: Exciting Requirements
•
•
Requirements that go beyond customers’ expectation.
Proved to be very satisfying when presented.
Example:
Page
: 31
- help and tutorial.
- layout and template function.
- cross-application enabled components.
O
O
A
D
Chapter 3
Object Orientation
Page
: 32
O
O
A
D
Chapter 3. Object Orientation
Object คือ สงิ่ ทีม
่ ต
ี ัวตน และขอบเขตทีแ
่ น่นอน
และมีสงิ่ ต่อไปนี้
- Operation: สงิ่ ที่ Object สามารถกระทาได ้ (ต ้องมี)
- Unique Identity: สงิ่ ทีบ
่ ง่ บอกถึงความมีอยูจ
่ ริงของ Object /ความแตกต่าง
จาก Object อืน
่ ๆ (ต ้องมี)
- Attribute: คุณสมบัตท
ิ ี่ Object ตัวหนึง่ ๆจะมีได ้ (อาจจะมีหรือไม่มก
ี ็ได ้)
Object: เครือ
่ งบินรุน
่ BOEING 747 จุผู ้โดยสารได ้
140 คน ทีบ
่ น
ิ ออกจากดอนเมืองไปยัง Sydney ใน
วันที่ 15 เมษายน 2547 เวลา 12.30 น.
Page
: 33
O
O
A
D
Chapter 3. Object Orientation
Class
คือต้นฉบับของ Object ซึง่ มีคุณสมบัติ (attribute) พฤติกรรม (operation) ทีเ่ หมือนกัน
Class
Class เป็ น static description
Objectเป็ น instance ของ Class Objects
Page
OO Principle :
Abstraction
: 34
Car
O
O
A
D
Chapter 3. Object Orientation
Class: Attributes
Object
attribute value
attribute
Class
Car:Truck A
จำนวนล้อ = 10
ขนำดเครือ่ งยนต์ =10000
Car
จำนวนล้อ
ขนำดเครือ่ งยนต์
Car:Racer B
จำนวนล้อ = 4
ขนำดเครือ่ งยนต์ = 2500
Page
: 35
O
O
A
D
Chapter 3. Object Orientation
“ An Operation is the implementation of a service that can be
requested from any object of the class to affect behavior.”
Car
Operation
จานวนล ้อ
ขนาดเครือ
่ งยนต์
ติดเครือ
่ ง
เดินหน ้า
ถอยหลัง
Operation คือบริกำรที่ object มีให้เรียกใช้งำน
Page
: 36
O
O
A
D
Chapter 3. Object Orientation
หลักการพืน
้ ฐานของ Object Orientation ประกอบด ้วย 3 ข ้อ
1. Abstraction
2. Encapsulation
3. Modularity
Object Orientation
Modularity
: 37
Encapsulation
Abstraction
Page
O
O
A
D
Chapter 3. Object Orientation
นิยามของ Abstraction
“ Any model that includes the most important, essential, or
distinguishing aspects of something while suppressing or ignoring
less important, immaterial, or diversionary details. The result of
removing distinctions so as to emphasize commonalties”
จาก the Dictionary of Object Technology (Firesmith, Eykholt, 1995)
สรุปคือ
โครงร่างทีม
่ เี ฉพาะลักษณะพิเศษของตัวเอง ทีท
่ าให ้
แตกต่างจากสงิ่ อืน
่ ๆ
Page
: 38
O
O
A
D
Chapter 3. Object Orientation
นิยามของ Encapsulation
“ The physical localization of features (e.g., properties, behaviors)
into a single black box abstraction that hides their
implementation (and associated design decisions) behind a
public interface)”
สรุปคือ
่ นการทางานไว ้ภายในกล่อง โดยต ้องติดต่อผ่าน
การซอ
Interface ทีก
่ าหนดไว ้เท่านัน
้
Page
: 39
O
O
A
D
Chapter 3. Object Orientation
นิยามของ Modularity
“ The logical and physical decomposition of things (e.g., responsibilities
and software) into small, simple groupings (e.g., requirements and
classes, respectively), which increase the achievements of softwareengineering goals.”
สรุปคือ
Modularity เป็ นหลักการเดียวกับ Divide & conquer คือการแบ่งสงิ่ ทีม
่ ข
ี นาดใหญ่
ั ซอน
้ ให ้เป็ นชน
ิ้ ๆ ทีเ่ ล็กลง และจัดการได ้ง่ายขึน
และ/หรือ มีความซบ
้
Page
: 40
O
O
A
D
Chapter 3. Object Orientation
Abstractions
Abstractions คือกระบวนการในการหาและใส่
Concept เข้าไปย ัง Real-world Objects ทีส
่ นใจ
เพือ
่ ก่อให้เกิด Class
Abstractions สามารถจาแนกออกได้เป็น
4 กระบวนการ คือ
•Classification Abstraction
•Aggregation Abstraction
•Association Abstraction
•Generalization Abstraction
Page
: 41
O
O
A
D
Chapter 3. Object Orientation
Classification Abstractions
Classification Abstraction คือกระบวนการในการหาและใส่ Concept
เข ้าไปยัง Real-world Objects เพือ
่ ให ้เกิด Class
สรพงษ์
Mary
หวงเฟยหง
Page
: 42
Concepts:
มีรำ่ งกำย
สือ่ สำรด้วยภำษำมนุษย์
สำมำรถคิดได้
Class: คน
O
O
A
D
Chapter 3. Object Orientation
Classification Abstractions (cont.)
การเปลีย
่ น Concept จะมีผลให ้ Class มีคณ
ุ สมบัตเิ ปลีย
่ นไป และอาจจะทาให ้
ิ ของ Object ใน Class นัน
จานวนสมาชก
้ เปลีย
่ นไปได ้
สรพงษ์
Mary
หวงเฟยหง
Page
: 43
Concepts:
มีรำ่ งกำย
สือ่ สำรด้วยภำษำมนุษย์
สำมำรถคิดได้
เพศชาย
Class: ผูช้ ำย
O
O
A
D
Chapter 3. Object Orientation
Classification Abstractions (cont.)
สรพงษ์
Mary
Concepts:
Concepts:
มีรำ่ งกำย
สือ่ สำรด้วยภำษำมนุษย์
สำมำรถคิดได้
เพศชาย
เล่นเบสบอลได้
Class: นักกีฬำ
เบสบอลชำย
หวงเฟยหง
Page
: 44
O
O
A
D
Chapter 3. Object Orientation
Aggregation Abstraction
ั ันธ์ใน
Aggregation Abstraction คือกระบวนการในการหาความสมพ
เชงิ “องค์ประกอบ” ระหว่าง Class
Class ทีเ่ ป็นองค์ประกอบเรียกว่า Component Class
Class ทีเ่ กิดจากการรวมก ันของ Component Class เรียกว่า Aggregated
Class
หัว
ลำตัว
แขน
Page
: 45
ขำ
Aggregate
Class: คน
O
O
A
D
Chapter 3. Object Orientation
Aggregation Abstraction : Cardinality
ใน Aggregation Abstraction เราจาเป็ นต้องระบุ Cardinality หรือ จานวน
ของ Objects ของ Component Class ที่มีได้น้อยที่สดุ (Minimum Cardinality:
min-card) และมากที่สดุ (Maximum Cardinality: max-card)ใน Aggregated
Class
Aggregate
หัว 1..1
0..n ร่ำงกำย 1..1
ผม
0..2
แขน
Page
: 46
ขำ
0..2
Aggregate
Class: คน
O
O
A
D
Chapter 3. Object Orientation
Association Abstraction
Association Abstraction คือกระบวนการในการหาความสัมพันธ์
ระหว่าง Class ที่แตกต่างกัน โดยเป็ นความสัมพันธ์ที่ไม่ใช่ในเชิงที่
ขึน้ ต่อกันเหมือนกับใน Aggregation Abstraction
วิชำเรียน
สอน
อำจำรย์ผสู้ อน
แบ่งเป็ น
นักเรียน
มี
Section
ใช้
Page
: 47
ห้องเรียน
เส้นตรงใช้แสดงความสัมพันธ์ระหว่าง Class
ลูกศรใช้ในการบอกทิศทางของความสัมพันธ์
O
O
A
D
Chapter 3. Object Orientation
Association Abstraction: Cardinality
ความสัมพันธ์เชิง Association ระหว่าง Class จะมี Minimum
Cardinality และ Maximum Cardinality ของ Class ที่อยู่ทงั ้ สองข้าง
ของความสัมพันธ์ เสมอ
ประเภทของ Association จาแนกตาม Cardinality ได้เป็ น 3
ประเภท ดังนี้
One-to-One Association (1-1)
One-to-Many Association (1-M)
Many-to-Many Association (M-M)
Page
: 48
O
O
A
D
Chapter 3. Object Orientation
Association Abstraction: Cardinality
Example
One-to-One Association (1-1)
มี
1..1
คน
0..1 บัตรประจำตัวประชำชน
One-to-Many Association (1-M)
รถยนต์ 1..1 บรรทุก
0..n ผูโ้ ดยสำร
Many-to-Many Association (M-M)
นักเรียน
Page
: 49
0..n
เรียน
0..n วิชำเรียน
O
O
A
D
Chapter 3. Object Orientation
Generalization Abstraction
Generalization Abstraction คือกระบวนการในการหา
ความสัมพันธ์ระหว่าง Class ในลักษณะที่มีการเพิ่มเติม Attributes
หรือ Operations ให้กบั Class เดิม เพื่อให้เกิด Class ใหม่ทีมี
คุณลักษณะพิเศษแตกต่างไปจากเดิม โดย Class ใหม่ได้รบั
ถ่ายทอด (inherit) คุณลักษณะบางอย่างจาก Class เดิมด้วย
Generalization Abstraction สามารถจากัดความได้ใน
2 ความหมายคือ
-Generalize
-Specialize
Page
: 50
O
O
A
D
Chapter 3. Object Orientation
Generalization Abstraction: Generalize/ Inheritance
Generalization and Inheritance
Super Class
Generalize
Sub Class
Page
: 51
มีลอ้
มีเครือ่ งยนต์
Inherit
มีลอ้
มีเครือ่ งยนต์
ติดเทอร์โบ
O
O
A
D
Chapter 3. Object Orientation
Generalization Abstraction: Generalize/ Inheritance
Inheritance ก่อให้เกิ ดแนวคิ ด Abstract Class และ Hierarchy
Hierarchy 0
Hierarchy 1
Hierarchy 2
สิง่ มีชวี ติ
Parent / Child
พืช
สัตว์
สัตว์บก
สัตว์ปีก
สัตว์น้ ำ
Sibling
สิง่ มีชวี ติ จัดเป็ น Abstract Class: Class ทีไ่ ม่สำมำรถมี Object ของตัวเองได้
แต่จะมีได้ ต้องผ่ำนกำรทำ Inheritance ก่อน เสมอ
Page
: 52
O
O
A
D
Chapter 3. Object Orientation
Generalization Abstraction: Generalize/ Inheritance
ในแง่ Operations Inheritance ก่อให้เกิ ดแนวคิ ด Overriding
รถยนต์
Operation: เลีย้ ว (ใช้พวงมำลัย)
Inherit
รถตีนตะขำบ
Operation: เลีย้ ว (ใช้ระบบ
Mechanical Steering)
เลีย้ ว เป็ น Operation ที่ รถตีนตะขำบได้รบั ถ่ำยทอดมำจำกรถยนต์ แต่กำรเลีย้ วของรถ
ตีนตะขำบ ทำงำนต่ำงจำกกำรเลีย้ วของรถยนต์อย่ำงสิน้ เชิง ซึง่ เรำจะเรียกว่ำ กำรเลีย้ ว
ของรถตีนตะขำบได้ override กำรเลีย้ วของรถยนต์
Page
: 53
O
O
A
D
Chapter 3. Object Orientation
Encapsulation
Encapsulation หรือการซ่อนรายละเอียดของ Class (เปรียบได้กบั
การนาเอาสิ่งต่างๆ ที่ย่งุ เหยิง บรรจุไว้ใน Capsule) ก่อให้เกิด
แนวคิด
• Information Hiding
กำรซ่อนรำยละเอียดของ Class และเปิดเผยเฉพำะส่วนทีจ่ ำเป็ น
ให้ภำยนอกได้รบั รู้
• Polymorphism
กำรซ่อนวิธกี ำรทำงำนทีแ่ ตกต่ำงกันภำยใต้รปู แบบกำรเรียกใช้
งำนแบบเดียวกัน
Page
: 54
O
O
A
D
Chapter 3. Object Orientation
Encapsulation: Information Hiding
• Information Hiding
Class โดยทัวๆ
่ ไป แบ่งระดับของ Information Hiding
ออกเป็ น 3 ระดับด้วยกัน
1.Private: Attributes หรือ Operations ซึง่ เมือ่ เป็ นของ Class ใดแล้ว Class อื่นๆ
ไม่สำมำรถเข้ำถึงได้จำกภำยนอก
2.Protected: Attributes หรือ Operations ทีไ่ ม่สำมำรถเข้ำถึงได้จำกภำยนอก
ยกเว้นจำกตนเอง และ Class ทีถ่ ูก Inherit ไปจำกตนเองเท่ำนัน้
3.Public: Attributes หรือ Operations ทีส่ ำมำรถเห็นได้ทนั ทีจำกภำยนอก
Page
: 55
O
O
A
D
Chapter 3. Object Orientation
Encapsulation: Information Hiding
• Information Hiding
Class: นักวิง่
Attribute: ควำมคิด
Operation: คิด
Attributes: Group เลือด
Operation:
Attribute: สีผวิ
Operation: บอกอำยุ
Operation: วิง่
Page
: 56
O
O
A
D
Chapter 3. Object Orientation
Encapsulation: Polymorphism
Polymorphism (Poly + Morph (body))
คือกำรซ่อนวิธกี ำรทำงำนทีแ่ ตกต่ำงกันอยูภ่ ำยใต้รปู แบบกำรติดต่อ (interface) แบบเดียวกัน
Implementation ออกจำก declaration
เป็ นกำรแยก
กด Remote Control เพือ่ เพิม่
Volume เหมือนกัน แต่การเพิม่
Volume ของวิทยุทางานต่างจาก
การเพิม่ Volume ของทีวี
Page
: 57
ในทาง Programming
Polymorphism จะแทนด้วยคาว่า
Overloading
O
O
A
D
Chapter 3. Object Orientation
Modularity
คือการแบ่งหรือย่อยรายละเอียดต่างๆ ที่รวมกันอยู่ให้มีขนาดเล็กลง และ
จัดการได้ง่ายดายขึน้
Decomposition การแบ่งย่อย Application เพื่อให้เกิ ด Components
Composition กระบวนการในการทาให้เกิ ด Components จาก Application หลัก
Program
Page
: 58
Form
Buttons
Unit
Library Components
O
O
A
D
Chapter 3. Object Orientation
Object-Oriented Software Engineering (OOSE)
การสร้าง Software ด้วยหลักการ Object Orientation นัน้ คือ
 R: สร้ำงและตีกรอบ Problem Domain
 A: จำลอง Real-World Objects ด้วย Class (ด้วยกำรใช้ Abstraction Encapsulation Modluarity)
 A: จำลองภำพกิจกรรมต่ำงๆ ทีจ่ ะเกิดขึน้ จริงใน Problem Domain ทีส่ นใจ
 D: สร้ำงรำยละเอียดของ Class เพือ่ กำรทำงำนในคอมพิวเตอร์
 D: สร้ำงรำยละเอียดของกิจกรรมต่ำงๆ ทีจ่ ะเกิดขึน้ ในคอมพิวเตอร์
 B: สร้ำง Class และ กิจกรรมให้เกิดขึน้ จริงในคอมพิวเตอร์
Page
: 59
O
O
A
D
Chapter 3. Object Orientation
Object-Oriented Software Engineering (OOSE)
Abstract Level
OOSE
Conceptual
Visualization
Analysis
Design
Not In
Computer
In
Computer
Requirement
Acquisition
Programming
Real World Level
Page
: 60
O
O
A
D
Chapter 4
Introduction to UML
Page
: 61
O
O
A
D
Chapter 4. Introduction to UML
UML and Principles of Modeling
Unified Modeling Language (UML) is a language for modeling
purposes. UML has to be used based on the principles of modeling:
1.
2.
3.
4.
Page
: 62
The choice of what models to create has a profound influence on
how a problem is attacked and how a solution is shaped.
Every model may be expressed at different levels of precision.
The best models are connected to reality.
No single model is sufficient. Every nontrival system is best
approached through a small set of nearly independent models.
O
O
A
D
Chapter 4. Introduction to UML
UML Overview
This chapter gives intrduction on:
Things in UML
Relationships in UML
Diagrams in UML
Rules of UML
Page
: 63
O
O
A
D
Chapter 4. Introduction to UML
Things in UML
There are 4 kinds of things in the UML:
1.
2.
3.
4.
Structural Things
Behavioral Things
Grouping Things
Annotational Things
These things are the basic object-oriented building blocks of the UM
They are used to write “well-formed model”.
Page
: 64
O
O
A
D
Chapter 4. Introduction to UML
Things in UML
1. Structural Things
Structural things are the nouns of UML models. These are the
mostly static parts of a model
Structural things represent either conceptual or physical
elements.
7 kinds of structural things are
1.
2.
3.
4.
5.
Page
: 65
Classes
Interfaces
Use Cases
Components
Nodes
O
O
A
D
Chapter 4. Introduction to UML
Things in UML : Structural Things
1.1 Class
A class is a description of a set of objets that
share the same attributes, operations,
relationships and semantics. A class implements
one or more interfaces.
Private Element
Protected Element
Public Element
Page
: 66
O
O
A
D
Chapter 4. Introduction to UML
Things in UML : Structural Things
1.2 Interface
Interface is a collection of operations that specify a
service of a class or components. An interface
describes the externally visible behavors of that
element.
IWorking
An interface defines a set of operation specifications
(called signatures) but never a set of operation
implementation.
An interface rarely stands alon. Rather, it is typically
attached to the class or componnent that realizes the
interface.
Page
: 67
O
O
A
D
Chapter 4. Introduction to UML
Things in UML : Structural Things
1.3 Use Case
Place Order
Page
: 68
A use case is a description of set of sequence of
actions that a system performs that yields an
observable result of value to a particular actior.
O
O
A
D
Chapter 4. Introduction to UML
Things in UML : Structural Things
1.4 Component
orderform.java
A component is a physical and relaceable part of a
system that conforms to and provides the realization
of a set of interfaces.
In a system there are many kinds of components, like
COM+ or Java Beans, custom developed components,
such as source code files.
A component typically represents the physical
packaging of otherwise logical elements, such as
classes, interfaces.
Page
: 69
O
O
A
D
Chapter 4. Introduction to UML
Things in UML : Structural Things
1.5 Node
Server
Page
: 70
A node is a physical element that exists at run time
and represents a computational resource, generally
having at least some memory and, often, procession
capability. A set of components may reside on a node
and may also migrate from node to node.
O
O
A
D
Chapter 4. Introduction to UML
Things in UML
2. Behavioral Things
Behavioral things are the dynamic parts of UML models. These are
verbs of a model
Behavioral things represent behavior over time ans space.
There are 2 primary kinds of behavioral things.
1. Messages
2. States
Page
: 71
O
O
A
D
Chapter 4. Introduction to UML
Things in UML : Behavioral Things
2.1 Message
display
An interaction is behavior that comprises a set of
message exchanged among a set of objects within a
particular context to accomplish a specific purpose.
The behavior of a society of objects or of an individual
operation may be specified with an interaction.
Page
: 72
O
O
A
D
Chapter 4. Introduction to UML
Things in UML : Behavioral Things
2.2 State
waiting
Page
: 73
State is a behavior that specifies the sequences of
actions that an object goes through during its
lifetime in response to events together with its
response to those events.
O
O
A
D
Chapter 4. Introduction to UML
Things in UML
3. Grouping Things
Grouping things are the organizational parts of UML
models. These are the boxes into which a model
can be decomposed. In all, there is one primary
kinds of grouping, called “packages”
Page
: 74
O
O
A
D
Chapter 4. Introduction to UML
Things in UML : Groping Things
3.1 Package
Business Rules
A package is a general-purpose mechanisms for
organizing elements into groups. Structural
things, behavior things, and even other
grouping thing mays be placed in a package.
Unlike components, a package is purely
conceptual (existing only at development time,
not runtime as components) .
Page
: 75
O
O
A
D
Chapter 4. Introduction to UML
Things in UML : Annotational Things
4. Annotational Things
Annotational things are the explanatory parts of UML models.
These are the comments you may describe or remark
about any element in a model
This is on primary kind of annotational thing called a “note”
Page
: 76
O
O
A
D
Chapter 4. Introduction to UML
Things in UML : Annotational Things
4.1 Note
return copy of
self
Page
: 77
We can use notes to adorn diagrams with
constraints or comments that are best expressed
in informal or formal text.
O
O
A
D
Chapter 4. Introduction to UML
Relationships in UML
There are 4 kinds of relationships in the UML:
1.
2.
3.
4.
Dependency
Association
Generalization
Realization
These relationships are the basic relational building blocks of
the UML. They are used to write well-formed models.
Page
: 78
O
O
A
D
Chapter 4. Introduction to UML
Relationships in UML :
1. Dependency
Hardware
Dependency is a semantic relationship between two
things in which a change to one thing may affect the
semantics of the other thing.
Operating
System
Page
: 79
O
O
A
D
Chapter 4. Introduction to UML
Relationships in UML :
2. Association
An association is a structural relationship that describe
a set of links, a link being a connection among
objects.
Aggregation is a special kind of association,
representing a structural relationship between a whole
and its parts.
Application
Employer
1
employs
+hire
1..*
Employee
+work
Aggregation
Association
1..*
Form
Page
: 80
O
O
A
D
Chapter 4. Introduction to UML
Relationships in UML :
3. Generalization
Generalization is a specialization/generalization
relationship in which objects of the specialized
element (the child) are substitutable for objects of the
generalized element (the parent)
Notification
Message Box
In this way the child shares the structure and the
behavior of the parent.
Error Message Box
Page
: 81
O
O
A
D
Chapter 4. Introduction to UML
Relationships in UML :
3. Realization
Realization is a semantic relationship between
classifiers, wherein one classifier specifies a
contract that another classifier guarantees to
carry out.
Car Actions
You well see realization between interfaces and
classes that realize them.
Car
Page
: 82
O
O
A
D
Chapter 4. Introduction to UML
Diagrams in UML
A diagram is the graphical representation of a set of a set of elements, most
often rendered as a connected graph of thing and relationships. Diagrams are
created to visualize a system from different respective, so a diagram is a
projection into a system.
There are many diagrams in UML. The same element may appear in all
diagrams, or a few diagrams. The UML includes nine diagrams
1.
2.
3.
4.
5.
6.
7.
8.
9.
Page
: 83
Class Diagram ***
Object Diagram
Use Case Diagram ***
Sequence Diagram ***
Collaboration Diagram ***
Statechart Diagram ***
Activity Diagram
Component Diagram ***
Deployment Diagram ***
O
O
A
D
Chapter 4. Introduction to UML
UML Diagrams Categories
The UML Diagram can be categorized in 2 schemes
Scheme 1:
Characteristics of UML diagrams
Static Diagrams
Dynamic Diagrams
Scheme 2:
Usages of UML diagrams
Conceptual Diagrams
Architectural Diagrams
Scheme 2 is the scheme applied in this course
Page
: 84
O
O
A
D
Chapter 4. Introduction to UML
UML Conceptual Diagrams
UML Conceptual diagrams are used to represent the static and dynamic view of
requirements, of elements that play their roles to perform the functions of the
system and of the system’s interactions and activities.
The UML Structural Models are classified as
•
•
•
•
Models
Models
Models
Models
for
for
for
for
Requirement Modeling
Static Modeling
Dynamic Modeling
Activity Modeling
-
Use Case Diagram
Class Diagram
Sequence Diagram,Collaboration Diagram
Activity Diagram, Statchart Diagram
In OOSE, conceptual diagrams are created in OOA and are refined in OOD.
Page
: 85
O
O
A
D
Chapter 4. Introduction to UML
UML Architectural Diagrams
UML Architectural diagrams are used to represent the structure and architecture
of software, hardware,
The UML Conceptual Models are classified as
•
•
Models for Software Components
Models for Hardware Platform
- Component Diagram
- Deployment Diagram
In OOSE, architectural diagrams are created in OOD.
Page
: 86
O
O
A
D
Chapter 4. Introduction to UML
Rules of UML
The UML’s building blocks cannot simply be thrown together in a random
fashion. Like any language, the UML has a number of rules that specify
what a well-formed model should look like. A well-formed model is one that is
semantically self-consistent and in harmony with all its related models.
The well-formed UML models must contains
•
•
•
•
•
Page
: 87
Names
Scope
Visibility
Integrity
Execution
what can call things, relationships, and diagrams
the context that gives specific meaning to a name
how those names can be seen and used by others
how things properly and consistently relate to one another
what it means to run or simulate a dynamic model
O
O
A
D
Chapter 5
Object Oriented
Analysis
Page
: 88
O
O
A
D
Chapter 5. OOA
Object Oriented Analysis (OOA)
The goal of analysis is to build an analysis model based on
users’ experts and enterprise requirements.
Deliverables from OOA
OOA delivers Requirement Models, including
• Problem Statements and Problem Domain
• Use Cases and Use Case Diagram
• Static Analysis Model
• Dynamic Analysis Model
Page
: 89
O
O
A
D
Chapter 5. OOA
Object Oriented Analysis (OOA)
The Analysis models should include
The Use Case Models
• context of the system
• requirements of the system
the Static Models
•
•
•
•
classes needed to provide the required application behavior
relationships among the classes
the knowledge each class must have of other classes
the services each class must provide.
And Dynamic Models
•proper description of interacations
• how external events activate object’s action
Page
: 90
O
O
A
D
Chapter 5. OOA
Object Oriented Analysis (OOA)
OOA covers the following activities in most
methodologies, although the approaches, sequences and
techniques used to carry out these activities may differs:
•
•
•
•
•
•
•
Page
: 91
Understanding the Problem
Finding the Objects
Classify the Objects into Classes
Establishing Class Relationships
Defining Class Properties and Behaviors
Modeling Objects Interactions
Study Object State Changes
O
O
A
D
Chapter 5. OOA
Object Oriented Analysis (OOA)
How can Models be applied in OOA
USE CASE DIAGRAM
• Understanding the Problem
•
•
•
•
Finding the Objects
Classify the Objects into Classes
Establishing Class Relationships
Defining Class Properties and Behaviors
• Modeling Objects Interactions
• Study Object State Changes
Page
: 92
CLASS DIAGRAM
INTERACTION DIAGRAM
STATECHART DIAGRAM
O
O
A
D
Chapter 5. OOA
Object Oriented Analysis (OOA)
How can Models be applied in OOA
1.
2.
3.
Page
: 93
Model Requirements with Use Case Diagram
Medel Static Element with Class Diagram
Behavior Modeling
•
Sequence Diagram
•
State Chart Diatgram
O
O
A
D
Chapter 5. OOA
1. Use Case Modeling
1.
2.
3.
4.
5.
Page
: 94
Use Cases
Actors
Use Cases and Flow of Events
Use Cases and Scenarios
Use Case Diagram Organization Techniques
System Context Modeling
System Requirements Modeling
O
O
A
D
Chapter 5. OOA
1.1 Use Cases
Describes a set of sequences, in which each
sequence represents the interaction of the
things outside the system (its actors) with
the system itself.
A use case represents a functional
requirements of a system as a whole.
Process Loan
Actor
Loan Officer
Page
: 95
Use Case
O
O
A
D
Chapter 5. OOA
1.1 Use Cases
Not only, the functions of a system, use
cases can tell the boundary of a system.
Describing use cases helps us to identify
• the services the system must provide.
• who use or relate to use case.
Process Loan
Actor
Loan Officer
Page
: 96
Use Case
O
O
A
D
Chapter 5. OOA
1.1 Use Cases
Good use case must be
•
•
Able to collect the enough information and
requirements
Flexible: not too committing too early to a specific
solutions
Process Loan
Actor
Loan Officer
Page
: 97
Use Case
O
O
A
D
Chapter 5. OOA
1.1 Use Cases
Limitations of Use Cases
•
•
Use case not describes the internal interaction between
the internal obects
Conflicts among use cases cannot be easily detected
Process Loan
Actor
Loan Officer
Page
: 98
Use Case
O
O
A
D
Chapter 5. OOA
1.2 Actors
Represents set of roles that outside users of use
cases play when interacting with these use cases.
Typically, an actor represents a role that a human,
a hardware device, or even another system plays
with a system.
Process Loan
Actor
Loan Officer
Page
: 99
Use Case
O
O
A
D
Chapter 5. OOA
1.2 Actors
Criterias for Finding Actors
If you work for a bank, you might be a loan Officer. If you
do your personal banking there, as well, you will also play
the role of customer.
An instance of an actor, therefore, represents an individual
interacting with the system in a specific way. Although,
you will use actors in your model, actors are not
actually part of the system. They live outside the
system.
To find actors is to help determining what is inside or outside the system.
Page
: 100
O
O
A
D
Chapter 5. OOA
1.2 Actors
Generalization Specialization of Actors
We can inherit properties of one actor
A specialized actor may play different roles
compared to based actor.
Loan Officer
Page
: 101
Senior Loan Officer
O
O
A
D
Chapter 5. OOA
1.3 Use Case and Flow of Events
Use Case describes WHAT a system does (outside view)
But
Use Case does not specify HOW it does (Inside view)
Anyway, you can specify the behavior or “FLOW OF EVENTS”
of use case by describing a flow of events in text note. This text
note is for outsider to make clearly understand of system
functions.
In the note for flow of events the parts that must not be
forgotten are
• How it start and end,
• when the use case interact with actors,
• what objects are exchanged,
• basic flow and alternative flow of the behavior
Page
: 102
O
O
A
D
Chapter 5. OOA
1.3 Use Case and Flow of Events
EXAMPLE:
in the context of of ATM system, you might describe the
use case “Validate User” in the following way:
Main flow of events: The use case starts when the system prompts the
customer for a PIN number. The customer can now enter a PIN
number via a keypad. The customer commits the entry by pressing
the Enter button . The system then checks this PIN number to see
if it is valid. If the PIN number is valid, the system acknowledges
the entry, thus ending the use case.
Page
: 103
O
O
A
D
Chapter 5. OOA
1.3 Use Case and Flow of Events
EXAMPLE:
in the context of of ATM system, you might describe the
use case “Validate User” in the following way:
Exceptional flow of events: The customer can cancel a transaction at
any time by pressing the Cancel button, thus restarting the
use case. No changes are made to the customer’s account.
Exceptional flow of events: The customer can cancel clear a PIN
number before
number
Page
: 104
committing it and reenter a new PIN
O
O
A
D
Chapter 5. OOA
1.4 Use Case and Scenarios
One use case actually describes a set of sequences in which each
sequence in the set represents one possible flow of event through all
these varitions. Each sequence is called a “SCENARIO”
A scenario is a specific sequence of actions that illstrates behavior.
Scenarios are to use case as instaces are to class, basically,
SCENARIO is instance of a use case.
Use Case
Class
Scenario
Object
Page
: 105
Object
Object
Scenario
Scenario
O
O
A
D
Chapter 5. OOA
1.5 Use Case Diagram Organization Techniques
Use Cases can be organized by specifying generalization,
include and extend relationships among use cases.
Relationships: the things that are applied among use cases in
order to:
• Inherit behavior (generalization)
• factor common behavior (includes)
• factor variants (extends)
Notations
<<include>>
Include
<<extends>>
Extend
Generalization
Page
: 106
O
O
A
D
Chapter 5. OOA
1.5 Use Case Diagram Organization Techniques
Example of Generalization, Include and Extend in Use Cases
Track Order
<<include>>
Place Rush Order
<<extend>>
Validate User
<<include>>
Check Password
Place Order
Page
: 107
O
O
A
D
Chapter 5. OOA
1.5 Use Case Diagram Organization Techniques
Example of Use Case Diagram
<<extend>>
Cellular Network
Place Phone Call
Place Conf erence Call
<<extend>>
Receiv e Phone Call
User
Page
: 108
Use Scehduler
Receiv e Additional Call
O
O
A
D
Chapter 5. OOA
1.5 Use Case Diagram Organization Techniques
To construct Use Case Diagram is to:
Model the Context of a System
Model the Requirements of the System
Reverse engineer
System Context
Forward engineer
Page
: 109
refine
Requirement Model
O
O
A
D
Chapter 5. OOA
1.5 Use Case Diagram Organization Techniques
Modeling the Context of a System
The context of a system can be modeled with a use
case diagram.
To model the context of a system,
• Identify the actors that surround the system by considering
o which groups require help from the system to perform their task,
o Which groupss are needed to execute the system’s funcitons,
o Which groups interact with external hardware and other software system,
o Which groups perform functions for administration/management
• Organize actors that are similar to one another in a generalization/specialize
hierarchy
• Where it aids understandability, provide a stereotype for each such actor.
• Populate a use case diagram with these actor to the system’s use case
Page
: 110
Who should responsible for constructing system context model
Answer. “Users & Stakeholders”
O
O
A
D
Chapter 5. OOA
1.5 Use Case Diagram Organization Techniques
Modeling the Context of a System
Example: Credit Card Validation System : System Context
Actors
For credit card validaton,
• Customers which can be categorize into 2 kinds (Individual and Corporate)
• Customer perform card transaction to Reatil Institution who process customer bill
• Credit card account is managed by Sponsoring Financial Institution (for example, Clearing House)
Customer
Page
: 111
Indiv idual
Customer
Retail Institution
Corporate
Customer
Sponsoring FI
O
O
A
D
Chapter 5. OOA
1.5 Use Case Diagram Organization Techniques
Modeling the Context of a System
Example: Credit Card Validation System : System Context
Use Cases
For credit card validaton,
• Customers which can be categorize into 2 kinds (Individual and Corporate)
• Customer perform card transaction to Reatil Institution who process customer bill
• Credit card account is managed by Sponsoring Financial Institution (for example, Clearing House)
Manage Customer Account
Perf orm Card Transaction
Process Customer Bill
Page
: 112
O
O
A
D
Chapter 5. OOA
1.5 Use Case Diagram Organization Techniques
Modeling the Context of a System
Example: Credit Card Validation System : System Context
Preliminary Use Cases Diagram for System Context
Perform Card Transacti on
Retail Institution
Customer
Sponsoring FI
Process Customer Bill
Individual
Customer
Page
: 113
Corporate
Customer
Manage Customer Account
O
O
A
D
Chapter 5. OOA
1.5 Use Case Diagram Organization Techniques
Modeling the Requirements of a System
Requirements can be expressed in various forms, System’s function
requirements can also be expressed by use case diagram.
To model the requirements of a system,
•
•
•
•
•
•
•
Establish the context of the system started by identify the actors that surround it.
For each actor, consider the behavior that each requires the system to provide
Name these behavior as use cases.
Factor common behavior into new use cases that are used or included by others.
Factor variant behavior into new use cases tht extend more main line flows.
Model these use cases, actors and relationships in use case diagram
Fill the notes if required.
Who should responsible for constructing Requirements Model
Ans. “System Analysts + Users”
Page
: 114
O
O
A
D
Chapter 5. OOA
1.5 Use Case Diagram Organization Techniques
Modeling the Requirements of a System
Example: Credit Card Validation System : System Context
Step 1: Focus on actors’ requirements
Expand the system context model from its actors
we found that:
Detect Card Fraud is a behavior that is important for both retail institution and the
sponsoring FI.
Similarly, Report on Account Status is another behavior required of the system by
various institutions in its context.
Page
: 115
O
O
A
D
Chapter 5. OOA
1.5 Use Case Diagram Organization Techniques
Modeling the Requirements of a System
Example: Credit Card Validation System : Requirements Model
Requirements Use Case Model Step 1
Perf orm Card Transaction
Detect Card Fraud
Retail Institution
Report on Account
Customer
Sponsoring FI
Process Customer Bill
Page
Indiv idual
: 116
Customer
Corporate
Customer
Manage Customer Account
O
O
A
D
Chapter 5. OOA
1.5 Use Case Diagram Organization Techniques
Modeling the Requirements of a System
Example: Credit Card Validation System : System Context
Step 2: Try to Factor
Expand requirement use case model from step one
we found that:
Anytime the card transaction is processed, the card holder must be verified.
Beside the normal report, sometimes various institution may needs some ad hoc
report for some rush monitoring or analysis purpose.
For the age of internet the card transaction can be done online, so there is a
required capability of the system that institution to process an online card
transaction
Page
: 117
O
O
A
D
Chapter 5. OOA
1.5 Use Case Diagram Organization Techniques
Modeling the Requirements of a System
Example: Credit Card Validation System : Requirements Model
Requirements Use Case Model Step 2
<<include>>
Verif y Card Holder
Perf orm Card Transaction
Retail Institution
<<extend>>
Perf orm Online Transaction
Report on Account
Ad hoc Report
Detect Card Fraud
Customer
Process Customer Bill
Sponsoring FI
Page
idual
:Indiv
118
Customer
Corporate
Customer
Manage Customer Account
O
O
A
D
Chapter 5. OOA
2. Class Modeling
To build Class Diagram is to
•
•
•
•
•
Find out Classes
Specify Attributes and Methods of Classes
Build System Vocabulary
Build Class Diagram by Applying Abstractions
Improve the Class Diagram Created.
Recommendation:
These methodologies must be done based on
1
Page
: 119
2
3
spiral process model
4
5
O
O
A
D
Chapter 5. OOA
Class Modeling
2.1 Find Out Classes
Find Basic Classes from Use Cases:
1.
2.
Actor could be a class in class diagram
Behavior from each use case must be provided by class
How to:
1.
2.
3.
4.
5.
Page
: 120
List set of classes of each use case by describe the use case (may start
from scenarios or flows of events of each use case)
Some nouns in the description could become either class or attribute of
class.
Put the union product of nouns found in each use case into a class pool.
Note that, one class can reside in multiple use cases
Eliminate the class that is not in a scope (or be the scope itself)
O
O
A
D
Chapter 5. OOA
Class Modeling
Example : The Library
Borrow Books
Customer
Return Books
Librarian
Page
: 121
Borrow Books starts when customer
shows that he/she want to take the
books outside the library. The member
card of customer is verified. If verified
and if the number of borrowed items is
not excess the individual limit then the
books can be borrowed. The due date for
each books are set.
Customer shows the borrowed books to
the librarian. The librarian checks the
due date of each book. If there are
books that excess the due date.
Customer has to pay punishment charge.
Each books has its own punishment
charge. The charge is calculated in daily
basis.
O
O
A
D
Chapter 5. OOA
Exercise 1:
Refine Use Case Diagram
Directions:
Try to think of the feasible functions of library system that can serve these
requirements:
•
•
•
•
•
Page
:
Books borrowing
Books returning
Maintain Customer Information
Expiration/ Extension of Member Card
Books inventory
Start from existing basic use case diagram, refine it, to produce the class diagram
explaining the functions above.
122
O
O
A
D
Chapter 5. OOA
2.1 Find Out Classes
Example : The Library
Borrow Books
Customer
Return Books
Librarian
Page
: 123
Borrow Books starts when customer shows
that he/she want to take the books outside
the library. The member card of customer
is verified. If verified and if the number of
borrowed items is not excess the individual
limit then the books can be borrowed. The
due date for each books are set.
Customer shows the borrowed books to
the librarian. The librarian checks the due
date of each book. If there are books that
excess the due date. Customer has to pay
punishment charge. Each books has its
own punishment charge. The charge is
calculated in daily basis.
O
O
A
D
Chapter 5. OOA
2.1 Find Out Classes
Example : The Library
Find Class
Borrow Books
Borrow Books starts when customer
shows that he/she want to take the
books outside the library. The
member card of customer is verified. If
verified and if the number of borrowed
items is not excess the individual limit
then the books can be borrowed. The
due date for each books are set.
Customer
Librarian
Page
: 124
Possible to be classes:
Customer
Book
Librarian
Library
Member Card
Borrowed Items
Possible to be Attributes
Due Date
O
O
A
D
Chapter 5. OOA
2.1 Find Out Classes
Example : The Library
Find Class
Return Books
Customer
Customer shows the borrowed
books to the librarian. The librarian
checks the due date of each book.
If there are books that excess the
due date. Customer has to pay
punishment charge. Each books
has its own punishment charge. The
charge is calculated in daily basis.
Possible to be classes:
Librarian
Page
: 125
Customer
Book
Librarian
Borrowed Items
Possible to be Attributes
Due Date
Punishment Charge
O
O
A
D
Chapter 5. OOA
2.1 Find Out Classes
Example : The Library
Construct Class Pool
Customer
Book
Librarian
Library
Member Card
Borrowed Items
Customer
Book
Librarian
Borrowed Items
Page
: 126
Class Pool
Due Date
Customer
Book
Librarian
Library
Member Card
Borrowed Items
Due Date
Punishment Charge
Due Date
Punishment Charge
O
O
A
D
Chapter 5. OOA
2.1 Find Out Classes
Example : The Library
Eliminate out-of-scope classes from Class Pool
Customer
Book
Librarian
Library
Member Card
Borrowed Items
Due Date
Punishment Charge
Unrequired
The system itself
Page
: 127
Customer
Book
Member Card
Borrowed Items
Due Date
Punishment Charge
O
O
A
D
Chapter 5. OOA
2.2 Specify Attributes and Methods
Find Basic Methods
1.
2.
3.
4.
5.
Page
From the use case description. Method of classes are implicitly
shows in verbs
Normally, in the sense of language the sentence is
[ subject verb object ] . We can assume that verb is the method of
object (in the sense of language) , if such object noun is selected as
a class.
Some method found may be in or out of scope. Select just required
methods.
Note that, methods found in this phase is usually “Public” methods.
Think of class responsibilities and service that classes should provide
and fill it.
: 128
O
O
A
D
Chapter 5. OOA
2.2 Specify Attributes and Methods
Example : The Library
Find Methods
Borrow Books
Customer
Librarian
Page
: 129
Borrow Books starts when customer
shows that he/she want to take the
books outside the library. The member
card of customer is verified. If verified
and if the number of borrowed items is
not excess the individual limit then the
books can be borrowed. The due date
for each books are set.
Verbs Found:
Book has method
Take the Book
Synonym
borrow
Borrow the Book
Member Card has method verify
Verify Member Card
Set Due Date for Each Book
Book has method set due date
O
O
A
D
Chapter 5. OOA
2.2 Specify Attributes and Methods
Example : The Library
Find Methods
Return Books
Customer
Librarian
Customer shows the borrowed books
to the librarian. The librarian checks
the due date of each book. If there are
books that excess the due date.
Customer has to pay punishment
charge. Each books has its own
punishment charge. The charge is
calculated in daily basis.
Verbs Found:
Book has method show
Shows the Book
Check the Due Date of Book Book has method check due date
Pay Punishment Charge of A Book
Book has method pay
punishment charge
Not a required method
Page
: 130
O
O
A
D
Chapter 5. OOA
2.2 Specify Attributes and Methods
Example : The Library
Find Methods : Summary
Book has method set due date
Book has method check due date
Book has method pay punishment charge
Book has method borrow
Page
: 131
Member Card has method verify
O
O
A
D
Chapter 5. OOA
2.2 Specify Attributes and Methods
Find Basic Attributes
1.
2.
Page
: 132
Primarily, from the use case description the noun or adjective that
explains or belongs to the class could be an attributes of that class.
Refer to the methods, normally there should be some attributes of
class that is affected as result of a methods.
O
O
A
D
Chapter 5. OOA
2.2 Specify Attributes and Methods
Example : The Library
Find Attribtes
Borrow Books
Customer
Librarian
Borrow Books starts when customer shows
that he/she want to take the books outside
the library. The member card of customer is
verified. If verified and if the number of
borrowed items is not excess the individual
limit then the books can be borrowed. The
due date for each books are set.
Possible to be Attributes
Number of borrowed items is of Customer
Individial Limit explains Customer
Due Date explains Book
Page
: 133
O
O
A
D
Chapter 5. OOA
2.2 Specify Attributes and Methods
Example : The Library
Find Attributes
Customer
Return Books
Customer shows the borrowed books
to the librarian. The librarian checks
the due date of each book. If there are
books that excess the due date.
Customer has to pay punishment
charge. Each books has its own
punishment charge. The charge is
calculated in daily basis.
Possible to be Attributes
Librarian
Page
: 134
Due Date explains Book
Punishment Charge belongs to Book
Excess the Due Date Status explains Book
O
O
A
D
Chapter 5. OOA
2.2 Specify Attributes and Methods
Example : The Library
Find Attributes:
From finding Methods we learn that:
Book has method set due date
Book Already has Due Date
Book has method check due date
Book has method pay punishment charge
Book has method borrow
Book should has Borrowed Status
Member Card has method verify
Page
: 135
Book Already has Punishment Charge
Member Card should has Verified Status
O
O
A
D
Chapter 5. OOA
2.2 Specify Attributes and Methods
Example : The Library
Find Attributes: Summary
Customer contains attributes:
Number of Borrowed Items
Individual Limits
Book contains attributes:
Due Date
Punishment Charge
Excess Due Date Status
Borrowed Status
Member Card contains attributes
Verified Status
Page
: 136
O
O
A
D
Chapter 5. OOA
2.3 Build System Vocabulary
System Vocabulary
System vocabulary is
•
•
•
•
Page
: 137
visualization of class with its fundamental attributes and/or
methods,
With preliminary levels of information hiding (private, protected,
public), for primary modeling, all attributes should be private and
all methods should be public,
No relationships,
Notes can be added for explanatory purposes.
O
O
A
D
Chapter 5. OOA
2.3 Build System Vocabulary
Example : The Library : System Vocabulary
Page
: 138
O
O
A
D
Chapter 5. OOA
2.4 Build Class Diagram
How To:
Start from the System Vocabulary,
Apply the abstractions to define
new classes (if needed) and
identify the relationships among
classes.
The relationships
among classes could
be “aggregations” or
“associations” or
“genralization”.
Iterations are needed in this
process model.
Page
: 139
O
O
A
D
Chapter 5. OOA
2.4 Build Class Diagram
Example : The Library: Class Diagram (built from system vocab.)
Page
: 140
O
O
A
D
Chapter 5. OOA
Exercise 2:
Build the Class Diagram
Directions:
Based on the use case diagram (from Exercise 1) and the System Vocab.
Use abstractions to produce the class diagram of library system.
Page
: 141
O
O
A
D
Chapter 5. OOA
2.4 Build Class Diagram
Class Diagram of Library System
Page
: 142
O
O
A
D
Chapter 5. OOA
2.4 Build Class Diagram
Class Diagram of Library System
Page
: 143
O
O
A
D
Chapter 5. OOA
2.4 Build Class Diagram
Class Diagram of Library System – more refiend
Page
: 144
O
O
A
D
Chapter 5. OOA
Interaction Diagram
Interaction Diagram shows an interaction, consisting of
1.
2.
3.
A set of classes or objects
Their relarionships
Messages that may be dispatched among classes or objects
2 typess of interaction diagrams
1.
2.
Page
: 145
Sequence Diagram  emphsizes time ordering of messages.
Collaboration Diagram  emphasizes structural organization of
objects or classes that send and receive messages
O
O
A
D
Chapter 5. OOA
Interaction Diagram
Common Properties
Sequence diagram and Collaboration Diagram
are just a special kinds of diagram and shares the same common
properites as do all other diagrams
A name
Graphical contents
What distinguishes 2 kinds of an interaction diagram from each other
is its particular content and its explanation scheme.
Contents of Interacton Diagram:
Page
: 146
Objects
Links
Messages
O
O
A
D
Chapter 5. OOA
Interaction Diagram
Semantic Equivalence
Sequence diagram and collaboration diagram are semantically
equivalent.
As a result, you can take a diagram in one from and convert it to the
other without any loss information. (this feature is supported in
Rational ROSE)
Page
: 147
O
O
A
D
Chapter 5. OOA
Interaction Diagram
Common Uses
Interaction diagram is used to model the dynamic aspects of a
system.
Use Case and Interaction Diagram
From the system context, you can attach at least one interaction
diagram to a particular use case to explains use case’s dynamic
aspects (ether main flow of events or possible scenario, or both)
Page
: 148
O
O
A
D
Chapter 5. OOA
Interaction Diagram
How to Find Interactions
From each use case, the methods of elemental classes are provided
for being called by another class(es). The method of class will be
the message pointed to itself. The class that receive the
message is called receiver, while, the class that send the
message is called sender.
What are Yielded by Interactions
During interaction diagram construction, may be, the new messages
are created. This scenario yields the set of methods belonging to
the receiver.
Page
: 149
O
O
A
D
Chapter 5. OOA
Interaction Diagram
ATM KeyPad
Custom er : <Actor
Name>
The method “Enter Pin Code”
belongs to class
ATM KeyPad, not Customer.
Enter Pin Code
Sequence diagram
We can say that “Enter Pin Code” is
the service provided by ATM Keypad
1: Enter Pin Code
ATM
KeyPad
Customer : <Actor
Name>
Collaboration diagram
Page
If the method “Enter Pin Code” is now not of “ATM KeyPad”, this method must be
as public method of class ATM Keypad.
: added
150
O
O
A
D
Chapter 5. OOA
Interaction Diagram
ATM KeyPad
Screen
Customer : <Actor
Name>
Enter Pin Code
ShowMessage("Enter Amount")
Sequence diagram
Many times, there are the new class (and also its attributes and methods)
that are just discovered in this phase. Please note that the new discovered
class, usually, have to be added into the class diagram in the next iteration
(based on the spiral process model).
Page
: 151
O
O
A
D
Chapter 5. OOA
Interaction Diagram
Sequence Diagram
Sequence Diagram emphasizes the time ordering of
messages.
To form a sequence diagram is to
1.
2.
3.
Place the classes or objects that participate in interaction at a
top of diagram along the X axis
Move the initiate class to the left
Place the messages along the the Y axis (time axis).
How many Sequence Diagrams should have?
The number of sequence diagram should corresponds to the number
Of Use Case.
Page
: 152
O
O
A
D
Chapter 5. OOA
Interaction Diagram
Sequence Diagram
Sequence Diagram Syntax
Classes or Objects
: Client
: Transaction
: Account
create
Time passed
Page
: 153
check Balance
Focus of Control
update Balance
Messages
desrtroy
Timeline
O
O
A
D
Chapter 5. OOA
Interaction Diagram
Collaboration Diagram
Collaboration Diagram emphasizes the organization of the
objects that participate in an interaction.
How to Build the Collaboration Diagram
1.
2.
3.
Page
: 154
Place the classes or objects that participate in interaction as a
vertices in a graph.
Render the link of message that connect the objects as the arc of
the graph.
Give the name of the message led by the number to show the
sequence of interaction
O
O
A
D
Chapter 5. OOA
Interaction Diagram
Collaboration Diagram
Collaboration Diagram Syntax
Link
1: create
: Transaction
: Client
4: desrtroy
Sequence of Messages
: Account
Class or Objects
Page
: 155
2: check Balance
3: update Balance
O
O
A
D
Chapter 5. OOA
Exercise 3:
Build the
Interaction Diagram
Directions:
Based on the use case diagram (from Exercise 1), model the interaction of
each use case either by Sequence Diagram or Collaboration Diagram
Page
: 156
O
O
A
D
Chapter 5. OOA
CASE STUDY:
(30 points)
Foreign Currency
Exchange System
Analysis
Page
: 157
O
O
A
D
Chapter 5. OOA
CASE STUDY:
Foreign Currency Exchange System
Analysis
Problem Statement
The case sutdy features a bank with a number of worldwide distributed branches.
The bank provides its customers with various banking services, such as automatic
teller machine, credit card, and foreign currency exchange
The FCE application supports foreign currency cash and traveller’s check trading
services to customers based on current exchange rates. Customers who have
account in a bank branch are considered as bank customers. Customers who do
not have an account in any bank branches are considered general customers. Both
kinds of customers can use the exchange services
Page
: 158
O
O
A
D
Chapter 5. OOA
CASE STUDY:
Foreign Currency Exchange System
Analysis
Problem Statement (continued)
The CFE application manages information about customers, foreign currencies,
orders and payments, and stock availablibility. Branch cashiers are provided with
country information, including country, currency name, denominations of both
cash and traveller’s checks, and foreign counrty currency restrictions. Cashiers get
customer information, create an order, and receive an immediate response
regarding the request stock availability in their drawers and in the local branches.
Customer orders can be pending, in process, or completed. An order becomes
pending only if sufficient stock is not available in the cashier’s draser or in the local
branch. For bank customers, they have two choices fore receiving the foreign
currency money, receive a cash or account debit.
Page
: 159
O
O
A
D
Chapter 5. OOA
CASE STUDY:
Foreign Currency Exchange System Analysis
System Context
Manage Orders
(from Use Case)
Manage Stocks
(from Use Case)
Bank Customer
(from Actors)
Manage Customer Inf ormation
(from Use Case)
General Customer
(from Actors)
Page
: 160
Place the Order
(from Use Case)
Bank
(from Actors)
O
O
A
D
Chapter 5. OOA
CASE STUDY:
Foreign Currency Exchange System Analysis
<<include>>
Manage Exchange Rate
Requirements Model
(f rom Use Case)
Manage Orders
Convert Exchange Rate
(f rom Use Case)
(f rom Use Case)
Manage Traveller Check Order
<<extend>>
Bank
(f rom Use Case)
(f rom Actors)
<<extend>>
Manage Foreign Currency Order
Manage Stocks
(f rom Use Case)
(f rom Use Case)
Manage Customer Information
Place the Order
Customer
(f rom Use Case)
(f rom Use Case)
(f rom Actors)
Bank Customer
General Customer
(f rom Actors)
(f rom Actors)
Page
: 161
Place FCCY Order
Place Traveller Check Order
(f rom Use Case)
(f rom Use Case)
O
O
A
D
Chapter 5. OOA
CASE STUDY:
Foreign Currency Exchange System Analysis
Traveller Cheque Order
(from Classes)
System Vocabulary
place
Customer
(f rom Actors)
receive
Order
Foreign Currency Order
(f rom Classes)
(from Classes)
pays
pays
Bank Customer
manage
(f rom Actors)
General Customer
has
Payment
Foreign Curency Payment
(f rom Classes)
(from Classes)
(f rom Actors)
manage
Account
(f rom Classes)
Traveller Cheque Payment
(from Classes)
Bank Branch
(f rom Actors)
Money Stocks
(f rom Classes)
manage
Exchange Rate
(from Classes)
Page
: 162
Bank
(f rom Actors)
O
O
A
D
Chapter 5. OOA
CASE STUDY:
Foreign Currency Exchange System Analysis
<<include>>
Requirements Model
(Iterative 2)
Manage Customer Information
Manage Orders
Convert Exchange Rate
(f rom Use Case)
(f rom Use Case)
(f rom Use Case)
Manage Traveller Check Order
<<extend>>
(f rom Use Case)
Bank Branch
<<extend>>
(f rom Actors)
Manage Foreign Currency Order
Manage Stocks
(f rom Use Case)
(f rom Use Case)
Manage Exchange Rate
(f rom Use Case)
Place the Order
Customer
(f rom Use Case)
(f rom Actors)
Bank Customer
General Customer
(f rom Actors)
(f rom Actors)
Page
: 163
Place FCCY Order
(f rom Use Case)
Place Traveller Check Order
(f rom Use Case)
Bank
(f rom Actors)
O
O
A
D
Chapter 5. OOA
CASE STUDY:
Foreign Currency Exchange System Analysis
Preliminary Class Diagram
Page
: 164
O
O
A
D
Chapter 5. OOA
CASE STUDY:
Foreign Currency Exchange System Analysis
Class Diagram
Page
: 165
O
O
A
D
Chapter 5. OOA
CASE STUDY:
Foreign Currency Exchange System Analysis
Sequence Diagram:
Manage Customer Information – New Customer
: Bank Branch
: Custom er
: Bank Customer
[new customer] create()
: General
Customer
[want to open account] create()
create()
[do not want to open account] create()
Page
: 166
: Account
O
O
A
D
Chapter 5. OOA
CASE STUDY:
Foreign Currency Exchange System Analysis
Sequence Diagram:
Manage Customer Information – Not New Customer
: Bank Branch
: Custom er
: Bank Customer
[new customer] create()
: General
Customer
[want to open account] create()
create()
[do not want to open account] create()
Page
: 167
: Account
O
O
A
D
Chapter 5. OOA
CASE STUDY:
Foreign Currency Exchange System Analysis
Sequence Diagram:
Manage Stock – Decrease Stock
: Money Stocks
: Bank
checkStockAmount
[m ore than decreased am ount]decrease( )
Page
: 168
O
O
A
D
Chapter 5. OOA
CASE STUDY:
Foreign Currency Exchange System Analysis
Sequence Diagram:
Manage Stock – Increase Stock
: Money Stocks
: Bank
increase( )
Page
: 169
O
O
A
D
Chapter 5. OOA
CASE STUDY:
Foreign Currency Exchange System Analysis
Sequence Diagram:
Place Foreign Currency Order
: Foreign
Currency Order
: Custom er
create()
setStatus( "new order")
[is bank customer] setReceivingMethod()
[i s recei ve by Account] setRecei vi ngAccountNumber()
Page
: 170
O
O
A
D
Chapter 5. OOA
CASE STUDY:
Foreign Currency Exchange System Analysis
Sequence Diagram:
Place Traveller Cheque Order
: Traveller
Cheque Order
: Customer
create()
setStatus( "new")
Page
: 171
O
O
A
D
Chapter 5. OOA
CASE STUDY:
Foreign Currency Exchange System Analysis
YOUR JOBS
[Optional] Improve the Use Case Diagram
[Mandatory] Improve the Class Diagram
[Mandatory] Create Sequence Diagram of Other Use Cases
Don’t forget that the diagrams should be the revised
based on spiral process model.
Page
: 172
O
O
A
D
Chapter 6
Object Oriented
Design
Page
: 173
O
O
A
D
Chapter 6. OOD
Object Oriented Design
1.
OOA Models Refienement
•
Class Diagrams Refinement
•
Interaction Diagrams Refinement
•
Forward and Backward Engineering
2. Activity Design
3. Architecture Design
•
Component Design
•
Hardware Platform Design
4. Persistent Data Design
Page
: 174
O
O
A
D
Chapter 6. OOD
Object Oriented Design
1. OOA Models Refienement
1.Class Diagram Refinement
2.Interaction Diagram Refinement
3.Forward and Backward Engineering
Class Diagram
Refinement
Page
: 175
Behavior Diagram
Refinement
O
O
A
D
Chapter 6. OOD
Object Oriented Design: OOA Models Refinement
Class Diagram Refinement
Refinement Techniques
•
•
•
•
•
•
Page
: 176
Add non-business classes and relationships
Clarify attributes and methods of classes
Add non-business attributes
Add non-business methods
Refine information hiding levels
Add Interfaces
O
O
A
D
Chapter 6. OOD
Object Oriented Design: OOA Models Refinement
Class Diagram Refinement
Add non-business classes and relationships
What are non-business classes?
The classes that represents the system in technical terms, not
represents the data or business content: such as
• Application Forms
• I/O Classes
• Execution Classes
• Data Store Classes
• etc.
Page
: 177
O
O
A
D
Chapter 6. OOD
Object Oriented Design: OOA Models Refinement
Class Diagram Refinement
Clarify Attributes and Methods of Class
Clarification Techniques
The classed created during analysis phase, normally, has an incomplete
set of attributes and functions: How to refine them?
• Add missing business attributes and business methods to classes
• All Attributes should have simple or complex types
• Answer the question “Should the method return something?”
• Think of the paramether that the method should have
Page
: 178
O
O
A
D
Chapter 6. OOD
Object Oriented Design: OOA Models Refinement
Class Diagram Refinement
Add non-business attributes
What are the non-business attributes
The attributes of both business class and non-business class that
are not representing the business content of the class, for example:
• Create Date or Last Update Date
• Data Usage Status
• Version
• Confidential Level
Page
: 179
O
O
A
D
Chapter 6. OOD
Object Oriented Design: OOA Models Refinement
Class Diagram Refinement
Add non-business methods
What are non-business methods?
The methods that are not effecting the business properties of class,
such as:
• backup methods
• set Active/Inactive status of class
• Open and Close Data Store Class
• etc.
Page
: 180
O
O
A
D
Chapter 6. OOD
Object Oriented Design: OOA Models Refinement
Class Diagram Refinement
Refine Information Hiding Level
Think of the attributes and methods of classes
• the attributes / methods should be private, protected or public
• provide the public methods for setting or getting or
manipulating each private attribute
Page
: 181
O
O
A
D
Chapter 6. OOD
Object Oriented Design: OOA Models Refinement
Class Diagram Refinement
Add Interfaces
Interface is a collection of operations that specify a service
of a class. An interface describes the exernally visible
behavior of that element.
Interface is a collection of declaration of operations but never
have an implementation.
This constructs supports 2 OO concepts
1. Modularity
2. Polymorphism.
Page
: 182
O
O
A
D
Chapter 6. OOD
Object Oriented Design: OOA Models Refinement
Class Diagram Refinement
Add Interfaces (cont.d)
Interface never been a one-man-show component.
But:
It always be inheritted, so called, specialized by class
on the other hands :
class always possesses the operations provided by
interface
Page
: 183
O
O
A
D
Chapter 6. OOD
Object Oriented Design: OOA Models Refinement
Class Diagram Refinement
Add Interfaces (cont.d)
UML notations for interfaces:
in UML an interface is represented by a circle
Interface
Page
: 184
O
O
A
D
Chapter 6. OOD
Object Oriented Design: OOA Models Refinement
Class Diagram Refinement
Add Interfaces (cont.d)
When to Use Interfaces
The interface should be used if
1. There are many classes that use the same functions
2. The functions in 1 ,for the different classes, may needs
the different implementations
3. If the development is in a form of a “medium to big”
project, interface is one of very good tools for the
“development planning”
Page
: 185
O
O
A
D
Chapter 6. OOD
Exercise 4: Part I
Refine the
OOA Diagrams
Directions:
Based on the class diagram representing the activity of depositting/
withdrawing the money to/from Deposit Account (shown in next page).
Use the Class Diagram Refinement Concepts to Refine them and create the
OOD Diagram.
HINT: please don’t forget the spiral process model
Page
: 186
O
O
A
D
Chapter 6. OOD
Exercise 4: Part I
Refine the
OOA Diagrams
Page
: 187
O
O
A
D
Chapter 6. OOD
Object Oriented Design: OOA Models Refinement
Interaction Diagram Refinement
Refinement Techniques
•
•
Page
: 188
Refine the existing messges
Add the non-business classes and their corresponding message
to the sequence diagram
O
O
A
D
Chapter 6. OOD
Object Oriented Design: OOA Models Refinement
Interaction Diagram Refinement
Refine Existing Messages
How to refine the existing messages?
To refine the existing messages in sequence/collaboration diagram
is to:
• clarify the parameter(s) of message, if existed.
• Add new messages, if needed.
• Delete some messages, if it is not needed anymore.
Page
: 189
O
O
A
D
Chapter 6. OOD
Object Oriented Design: OOA Models Refinement
Interaction Diagram Refinement
Add the non-business classes and their corresponding
message to the sequence diagram
Q: How comes the non-business classes?
A: from the OOD Class Diagram
Techniques
For the sequence Diagram:
•
•
•
•
Page
: 190
The class for input frequently stay on the left side of diagram.
The class for output frequently stay on the right side of diagram.
Mostly, the message added are dealing with the input/output or flow of data.
Don’t worry of adding new classes or messages to the diagram, based on the
spiral process model, they will be revised.
O
O
A
D
Chapter 6. OOD
Exercise 4: Part II
Refine the
OOA Diagrams
Directions:
Look at the sequence diagram on the next pages:
Answer the question
1. From the sequence diagram, can we refine the class diagrams (the class
diagram done in part I )? If you can do it.
2. refine sequence diagrams to produce OOD sequence diagrams from the
given sequence diagrams
Page
: 191
O
O
A
D
Chapter 6. OOD
Exercise 4: Part II
Refine the
OOA Diagrams
: Deposit
Transaction
: Customer
: Deposit
Account
: Bill
fill()
deposit( )
print( )
Sequence Diagram for “Depositing the Money” to Account
Page
: 192
O
O
A
D
Chapter 6. OOD
Exercise 4: Part II
Refine the
OOA Diagrams
: Withdraw
Transaction
: Customer
: Deposit
Account
: Bill
fill()
withdraw( )
print( )
Sequence Diagram for “Withdraw the Money” from Account
Page
: 193
O
O
A
D
Chapter 6. OOD
Exercise 4: Part II
Refine the
OOA Diagrams
: Custom er
: Bank
: Overdraft Withdraw
Transaction
: Deposit
Account
: Bill
fill()
set Interest()
withdraw( )
print( )
Sequence Diagram for “Overdraft Withdraw”
Page
: 194
O
O
A
D
Chapter 6. OOD
Object Oriented Design: OOA Models Refinement
Forward and Backward Engineering
Definition
•
•
Forward Engineering: the refinement on class diagram effects
the behavior diagrams
Backward Engineering: the refinement on behavior diagrams
effects the class diagrams
Forward Engineering
Behavior Diagram
Refinement
Class Diagram
Refinement
Page
: 195
Backward Engineering
O
O
A
D
Chapter 6. OOD
Object Oriented Design: OOA Models Refinement
Forward and Backward Engineering
Forward Engineering
•
•
The changes on classes’ functions cause the change on
messages in behavior diagrams
The increases or/and decrease of class cause the change of
participant classes in behavior diagrams
Forward Engineering
: 196
Behavior Diagram
Refinement
Class Diagram
Refinement
Page
O
O
A
D
Chapter 6. OOD
Object Oriented Design: OOA Models Refinement
Forward and Backward Engineering
Backward Engineering
•
•
The increment/decrement of messages on behavior diagrams
impacts the methods of classes
The increment/decrement/modification on the semantics of
messages may impacts the methods of classes
Behavior Diagram
Refinement
Class Diagram
Refinement
Page
: 197
Backward Engineering
O
O
A
D
Chapter 6. OOD
Exercise 4: Part III
Refine the
OOA Diagrams
Directions:
Use the forward and backward engineering to revise the refinement of
class diagram and sequence diagram from part I and II.
Page
: 198
O
O
A
D
Chapter 6. OOD
Object Oriented Design
2. Activity Design
1. Statechart Diagram:Definition
2. Modeling Statechart Diagram
3. Refining Statechart Diagram
Page
: 199
O
O
A
D
Chapter 6. OOD
Object Oriented Design
2. Activity Design
Statechart Diagram : Definitions
Statechart Diagram shows a state machine, emphasizing the
flow of control from state to state.
State Machine is a behavior that specifies the sequence of
states and objects goes through during its life time in response
to events together with its response to events.
State is a condition or situation in the lifetime of object during
which it satisfies some conditions, perform some activity and
wait for some event.
Page
: 200
O
O
A
D
Chapter 6. OOD
Object Oriented Design
2. Activity Design
Statechart Diagram : Definitions
Event is a specification of occurrence or stimulus that can
trigger the state transition.
Transition is a relationship between two states
Activity is an excution within a state machine
Page
: 201
O
O
A
D
Chapter 6. OOD
Object Oriented Design
2. Activity Design
Statechart Diagram : Definitions
When to Model Statechart Diagram?
To explain the detail specification of states, transitions and
events that is possible to form the activity on the class’s object.
Statechart can lead to the programming specification.
Page
: 202
O
O
A
D
Chapter 6. OOD
Object Oriented Design
2. Activity Design
Modeling Statechart Diagram
What are needed for Preliminary Statecart Diagram
Prelim. Statechart Diagram needs
1. Important or Main States
2. Initial State
3. Final State (optional)
4. Transition and Prelim. Event
Page
: 203
O
O
A
D
Chapter 6. OOD
Object Oriented Design
2. Activity Design
Modeling Statechart Diagram : Prelim. Statechart Diagram
Initial State
on
State
intruding detected
Alarm
Idle
intruding cleared
intruding cleared
10 mi nutes
off
Final State
Police
Calling
intruding cleared
10 mi nutes
Transition
Page
: 204
Event
Locked
Intruder Detector
Statechart Diagram
O
O
A
D
Chapter 6. OOD
Object Oriented Design
2. Activity Design
Refining Statechart Diagram
Two schemes of refinement
1. Composite States: Try to decompose the state into many
detailed states and transitions
2. Explanation: Try to add the actions and events to states and/or
transitions
Both schemes always be used together
Page
: 205
O
O
A
D
Chapter 6. OOD
Object Oriented Design
2. Activity Design
Refining Statechart Diagram
Two schemes of refinement: Composite States
Composite States:
The State can be decomposed into a new sub-statechart diagram
that contains initial states, final states, internal states, events
Page
: 206
O
O
A
D
Chapter 6. OOD
Object Oriented Design
2. Activity Design
Refining Statechart Diagram
Two schemes of refinement: Explanation
Explain the states
You can explain the state by inserting actions into the state
The action can be in these type
• Entry example: on entry/show message (“Hello”)
• Exit example: on exit/disconnect
• On Event example: on every 1 minutes / monitor mailbox
Page
: 207
O
O
A
D
Chapter 6. OOD
Object Oriented Design
Composite states
2. Activity Design
Alarm
Refining Statechart Diagram : Example
on
intruding detected
High Frequency
Sound
interrupted
5 seconds
Idle
5 seconds
Low Frequency
Sound
intruding cleared
interrupted
off
intruding cleared
10 minutes
Make Warning
intruding cleared
entry/ Make Warning
on Every 1 Minute/ Send E-M ail to Police Station
10 minutes
Locked
Page
: 208
Explanation
O
O
A
D
Chapter 6. OOD
Object Oriented Design
2. Activity Design
Refining Statechart Diagram : Example
on
intruding detected
Alarm
High Frequency
Sound
interrupted
5 seconds
5 seconds
Idle
Low Frequency Sound
intruding cleared
interrupted
entry/ count = 0
on every 1 second/ count = count+1
on [count = 5]/ No Sound
off
intruding cleared
10 minutes
Make Warning
intruding cleared
on Undefined/ Make Warning
on Every 1 Minute/ Send E-Mail to Police Station
10 minutes
Locked
Page
: 209
O
O
A
D
Chapter 6. OOD
Exercise 5
Statechart Diagram
Directions:
From the statechart diagram on previous page,
1. Show the explanation of state “High Frequency Sound”
2. If the requirement is that: After 10 minutes of mailing the police, and
nothing done, every door in the building must be closed. Immediately,
after that, every window must be closed. And, 10 minutes after the
closing of windows the air-conditioner must be shut down. Please
refine the statechart diagram.
Page
: 210
O
O
A
D
Chapter 6. OOD
Object Oriented Design
3. Architecture Design
1. Component Design
2. Hardware Platform Design
Page
: 211
O
O
A
D
Chapter 6. OOD
Object Oriented Design
3. Architecture Design
Component Design
Component Diagram
Component Diagrams commonly contains
• Components
• Interfaces
• Relationships
• Dependency
• Generalization
• Association
• Realization
Page
: 212
O
O
A
D
Chapter 6. OOD
Object Oriented Design
3. Architecture Design
Component Design
Component Diagram
The common purpose for using component is to model the
components that can make the implementation.
For the most systems, the deployment components are
drawn from the decisions made about how to segment the
physical implementation of the system
Page
: 213
O
O
A
D
Chapter 6. OOD
Object Oriented Design
3. Architecture Design
Component Design
Component Design Methodologies
1. System Partitioning
2. Design Components & Relationships of Subsystems
Page
: 214
O
O
A
D
Chapter 6. OOD
Object Oriented Design
3. Architecture Design
Component Design
Design Methodologies: System Partitioning
The system should be partitioned into three subsystems:
• Presentation Logic Subsystem : Input/Output/UI of System
• Business Logic Subsystem : Working Parts of the system.
• Database Logic Subsystem : Persistent Parts of the System
Page
: 215
O
O
A
D
Chapter 6. OOD
Object Oriented Design
3. Architecture Design
Component Design
Design Methodologies: Model Presentation Logic Subsystem
The Components in Presentation Logic Subsystem belong to:
User Interface Components
Input Units
Display Components
Web Pages / Windows Form
Page
: 216
O
O
A
D
Chapter 6. OOD
Object Oriented Design
3. Architecture Design
Component Design
Design Methodologies: Model Presentation Logic Subsystem
Example
AppWeb
Page
show
Main
App
has
DataReco
ncileForm
call
Page
: 217
Open File
Dialog
call
call
Save File
Dialog
Print File
Form
has
Data Input
Form
O
O
A
D
Chapter 6. OOD
Object Oriented Design
3. Architecture Design
Component Design
Design Methodologies: Model Business Logic Subsystem
The Components in Business Logic Subsystem belong to:
Applications
Application Subprograms
Libraries
Executable Programs
Page
: 218
O
O
A
D
Chapter 6. OOD
Object Oriented Design
3. Architecture Design
Component Design
Design Methodologies: Model Business Logic Subsystem
Example
Form.htm
Transaction
Manage.exe
load
include
include
TXNKeyin.h
Receoncile.h
include
include
include
Screen.h
TableRender.h
Page
: 219
O
O
A
D
Chapter 6. OOD
Object Oriented Design
3. Architecture Design
Component Design
Design Methodologies: Database Logic Subsystem
The Components in Database Logic Subsystem belong to:
Data Items
Data Interfaces
Database Connections
Page
: 220
O
O
A
D
Chapter 6. OOD
Object Oriented Design
3. Architecture Design
Component Design
Design Methodologies: Database Logic Subsystem
DB
Login
Example
manage
Application
Database
contains
Page
: 221
Transaction
Data File
contains
Transaction
Data Table
has
DB
Connection
O
O
A
D
Chapter 6. OOD
Object Oriented Design
3. Architecture Design
Hardware Platform Design
The components developed or reused as part of software must
be deployed on some set of hardware and platform in order to
execute.
The hardware platform can be modeled on Deployment Diagram
Page
: 222
O
O
A
D
Chapter 6. OOD
Object Oriented Design
3. Architecture Design
Hardware Platform Design
Deployment Diagram
Deployment diagram consists of Nodes and Connection.
Node is used to represent the deployment and its
stereotype, description of component deployed can be
put in the note of the noce.
Connection describes the type of connection connecting
a pair of nodes.
Page
: 223
O
O
A
D
Chapter 6. OOD
Object Oriented Design
3. Architecture Design
Hardware Platform Design
Deployment Diagram: <<Web>>
Client
Example
Deploys
Presentation
Deploys
Database
Page
: 224
internet
<<Cluster>>
AppServer
Deploys
Business
<<ORACLE>>
DBServer
O
O
A
D
Chapter 6. OOD
Object Oriented Design
3. Architecture Design
Hardware Platform Design
Deployment Diagram
Not only the deployment, the deployment diagram can
model the device connecting to the software.
Normally, the deployment diagram with device attached is
extended from device-free version.
Page
: 225
O
O
A
D
Chapter 6. OOD
Object Oriented Design
3. Architecture Design
Hardware Platform Design
Deployment Diagram:
Example
<<Web>>
Client
internet
<<Cluster>>
AppServer
Printer
Smart
Card
Page
: 226
<<ORACLE>>
DBServer
O
O
A
D
Chapter 6. OOD
Object Oriented Design
4. Persistent Data Design
Persistent Data means
Data that has to be kept in the data storage for using in the future.
Persistent Data Design means
•
•
Page
: 227
Design of Structure of Data
Design of Relationships between Data
O
O
A
D
Chapter 6. OOD
Object Oriented Design
4. Persistent Data Design
How Comes the Structure of Persistent Data?
•
•
•
•
Page
: 228
The persistent data comes from the structure of class diagram
Not all classes go to the persistent data
Normally, structure of data is structure of classes of the
final analysis model
Only the attributes of classes are the details of persistent data
O
O
A
D
Chapter 6. OOD
Object Oriented Design
4. Persistent Data Design
How Comes the Relationships between Persistent Data?
•
•
•
Page
: 229
The relationships between data are from the abstractions
applied in the class diagram.
The referential rules is used to maintain the relationship
between data in data store.
All abstractions can be converted to data logical
relationships by abstraction-relationship conversion rules.
O
O
A
D
Chapter 6. OOD
Object Oriented Design
4. Persistent Data Design
Referential Rule
1. Primary Key and Foreign Key
Primary Key is the attribute or group of attributes that is selected for
identifying the uniqueness of data instance
Foreign Key is the attribute that is used by one data to link the relationship
to the primary key of other data
Page
: 230
O
O
A
D
Chapter 6. OOD
Object Oriented Design
4. Persistent Data Design
Referential Rule
1. Primary Key and Foreign Key
Example
Person Id
Primary Key
Person Id
Address Id
Person Name
Person Age
Address Name
Person Data
Attributes
Page
: 231
Address Data
Person Name
Person Age
Person Address
Lives in
0..n
1
Address Id
Address Name
Foreign Key refers to Address Data
The value in Person Address must not outside the
possible values of Address Id in Address
O
O
A
D
Chapter 6. OOD
Object Oriented Design
4. Persistent Data Design
Referential Rule
1 to 1 relationships
Choose primary key of one side of the relationship as a foreign key of the
other side.
Car
Engine
Car Id
Car
Engine
Car Id
Engine Id
Car Name
Car Model
Engine CC
Car Name
Car Model
Engine Id
Engine Id
1..1
has
0..1
or
Car
Engine
Car Id
Engine Id
Car Name
Car Model
has
0..1
Page
: 232
Engine CC
1..1 Engine CC
Car Id
O
O
A
D
Chapter 6. OOD
Object Oriented Design
4. Persistent Data Design
Referential Rule
1 to Many relationships
Put the primary key on the one side as the foreign key on the many side
Page
Country
City
Country Id
City Id
Country Name
Country Area
City Name
: 233
Country
Country Id
City
Country Name
Country Area
City Id
1..1
has
1..n City Name
Country Id
O
O
A
D
Chapter 6. OOD
Object Oriented Design
4. Persistent Data Design
Referential Rule
Many to Many relationships
Create the new data to keep the pairs of primay keys of the data on both
sides of relationship.
Subject
Student
Subject Id
Student Id
Subject Name
Subject Credit
study
0..n Student Name
0..n
Subject
Student
Subject-Student
Subject Id
Subject Name
Subject Credit
Page
: 234
1..1
0..n
Subject Id
Student Id
Student Id
1..1 Student Name
0..n
O
O
A
D
Chapter 6. OOD
Object Oriented Design
4. Persistent Data Design
Abstraction-Relationship Conversion Rules
•
Page
: 235
Association Abstraction Conversion
Apply the referential rule based on the cardinality of
association abstraction
O
O
A
D
Chapter 6. OOD
Object Oriented Design
4. Persistent Data Design
Abstraction-Relationship Conversion Rules
• Association Abstraction Conversion
Example
Customer
Order
Customer Id
Order Id
Customer Name
Customer Address 1..1
Customer Phone
Page
: 236
place
Order Type
Order Date
Order Status
0..n Order Currency
Order Amount
Customer Id
O
O
A
D
Chapter 6. OOD
Object Oriented Design
4. Persistent Data Design
Abstraction-Relationship Conversion Rules
•
Page
: 237
Aggregation Abstraction Conversion
Apply referential rule based on the cardinality of component
classes, normally the cardinality of aggregated class is one.
The relationship between aggregated and component classes
are one-to-one ot one-to-many relationship.
O
O
A
D
Chapter 6. OOD
Object Oriented Design
4. Persistent Data Design
Abstraction-Relationship Conversion Rules
•
Aggregation Abstraction Conversion
Head
Example
Head Id
1..1 Head Model
Robot Id
Arm
Arm Id
Robot
2..2
Arm Model
Robot Id
Robot Id
Leg
Robot Model
Leg Id
Leg Model
2..2 Robot Id
Body
Body Id
1..1
Page
: 238
Body Model
Robot Id
O
O
A
D
Chapter 6. OOD
Object Oriented Design
4. Persistent Data Design
Abstraction-Relationship Conversion Rules
•
Generalization Abstraction Conversion
The Generalization Abstraction can be replaced, in database by
the one-to-one relationship which allow the absence of the data
on the sub-class side.
The primary Key of subclass is the same as the primary key of
the super class, on the other words, the primary key of the
subclass is the foreign key refering to the primary key of the
super class.
Page
: 239
O
O
A
D
Chapter 6. OOD
Object Oriented Design
4. Persistent Data Design
Abstraction-Relationship Conversion Rules
•
Generalization Abstraction Conversion
Example
order
Order Id
order Type
Order Date
Order Status
Order Currency
Order Amount
1..1
1..1
Foreign Currency order
Foreign Currency Order
Denomination
Page
: 240
0..1
0..1 TravellerCheque Order Id
O
O
A
D
Chapter 6. OOD
CASE STUDY:
(30 points)
Foreign Currency
Exchange System
Design
Page
: 241
O
O
A
D
Chapter 6. OOD
CASE STUDY:
Foreign Currency Exchange System
Design
Assignment
1.
2.
3.
4.
Page
: 242
From the Foreign Currency Exchange Syatem analysis models,
refine class diagram, sequence diagram and statechart diagram.
Perform the persistent data design.
Partition the system and design the component diagram (based on
the requirements)
Discuss on the appropriate hardware platform (based on the
requirements) Design the deployment diagram.
O
O
A
D
Chapter 7
Software Testing
Page
: 243
O
O
A
D
Chapter 7. Software Testing
Software Testing
Testing Objectives
1. Testing is a process of executing a program with the
intention of finding a set of errors
2. A good test case is one that has a high probability of
finding an undiscovered error.
3. A Successful test is one that uncovers an undiscovered
errors.
Test Case = the body of inputs and their conditions that are created
and asserted to a software, in a specific software environment, to
make a software create the expected output.
Page
: 244
O
O
A
D
Chapter 7. Software Testing
Software Testing
Testing Principles
1. All tests should be traceable to users’ requirements.
2. Tests should be planned long enough before testing begin.
3. Testing should begin “in small scale” and progress toward
testing “in large scale”.
4. The most effective testing should be conducted by an
independent third party.
Page
: 245
O
O
A
D
Chapter 7. Software Testing
Software Testing
Testing Scales
Page
1. Unit Testing(UT): The testing conducted by the module
developers. The test cases of unit testing are prepared by the
developers.
2. User Acceptance Testing(UAT): The testing conducted by
users or developers. UAT occurs after the integration of the
software. The test cases should be prepared, or at least,
designed by users.
3. Integration-wide Testing (IWT): The testing conducted by the
whole project team (Users+Developers+Managers) or third party
or together. The test cases should be prepared by users and,
optionally, third party. The software quality control (QC) should be
processed in this phase.
: 246
O
O
A
D
Chapter 7. Software Testing
Software Testing
Testing Procedure
Software
release 1st
IWT
UT
UAT
IWT
develop
UAT
develop
develop
UT
Software
release 2nd
UT
Software
release 3rd
UAT
IWT
Time
Page
Project resources (manpower, budget, management)
Discovered Errors Found
Undiscovered Errors Found
: 247
O
O
A
D
Chapter 7. Software Testing
Software Testing
Test Case Design
For testing purpose, there are 2 kinds of test cases that must
be prepared
Page
: 248
•
Valid Test Case : The test case that is design with intention to
make sure that the system will return the satisfied output.
•
Invalid Test Case: The test case that is design with intention to
make sure that the system will be able to detect the abnormal
input and situation and can be recovered after error found.
O
O
A
D
Chapter 7. Software Testing
Software Testing
Testing Case Design
Test Case Design Principles
The test case, no matter valid or invalid test cases, must be
able to perform
• Validation Testing
• System Testing
Page
: 249
O
O
A
D
Chapter 7. Software Testing
Software Testing
Testing Case Design
Test Case Design Principles
Test Cases for Validation Testing
The test cases for validation testing must be able give the precise
answers tothe questions:
• Is the function or performance of software conform to the
requirements? (Correctness Testing)
• Have the elements and configurations of software been
developed or prepared properly? (Checklist Testing)
Page
: 250
O
O
A
D
Chapter 7. Software Testing
Software Testing
Testing Case Design
Test Case Design Principles
Test Cases for System Testing
The test cases for validation testing must be able give the precise
answers tothe questions:
• If the software is forced to fail, can the software perform or
try something to recover itself? (Recovery Testing)
• Can the software protect itself from variety of penetration?
(seccurity testing)
• Is the run time of software is acceptable? (performance
testing)
Page
: 251