Post on 31-Dec-2015
description
Software Design
and Development
Software Design
and Development
Kittipong KlomklaumSenior System Analyst / Data ModelerBank of ThailandKittipok@bot.or.th
Page : 2
OOAD
OOAD COURSE OUTLINE
Page : 4
OOAD
OOAD
Chapter 1Software Development Lifecycles(SDLC)
Chapter 1Software Development Lifecycles(SDLC)
Page : 4
OOAD
OOAD
Chapter 1Software Development Lifecycles(SDLC)
Chapter 1Software Development Lifecycles(SDLC)
Page : 21
OOAD
OOAD
Chapter 2Requirements Acquisition
Chapter 2Requirements Acquisition
Page : 21
OOAD
OOAD
Chapter 2Requirements Acquisition
Chapter 2Requirements Acquisition
Page : 34
OOAD
OOAD
Chapter 3Object OrientationChapter 3Object Orientation
Page : 34
OOAD
OOAD
Chapter 3Object OrientationChapter 3Object Orientation
Page : 63
OOAD
OOAD
Chapter 4Introduction to UMLChapter 4Introduction to UML
Page : 63
OOAD
OOAD
Chapter 4Introduction to UMLChapter 4Introduction to UML
Page : 174
OOAD
OOAD
Chapter 6Object Oriented Design
Chapter 6Object Oriented Design
Page : 174
OOAD
OOAD
Chapter 6Object Oriented Design
Chapter 6Object Oriented Design
Page : 88
OOAD
OOAD
Chapter 5Object Oriented Analysis
Chapter 5Object Oriented Analysis
Page : 88
OOAD
OOAD
Chapter 5Object Oriented Analysis
Chapter 5Object Oriented Analysis
Page : 243
OOAD
OOAD
Chapter 7Software TestingChapter 7Software Testing
Page : 243
OOAD
OOAD
Chapter 7Software TestingChapter 7Software Testing
Page : 3
OOAD
OOAD
Chapter 1 Software Development Lifecycles(SDLC)
Chapter 1 Software Development Lifecycles(SDLC)
Page : 4
OOAD
OOAD
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 : 5
OOAD
OOAD
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?”
Chapter 1. Software Development Lifecycles (SDLC)
Page : 6
OOAD
OOAD
2. Software Development Process Models
Waterfall Process Model
Incremental Process Model
Spiral Process Model
Chapter 1. Software Development Lifecycles (SDLC)
DesignDesign
AnalysisAnalysis
BuildBuildRequirement
Acquisition
RequirementAcquisition
DesignDesign
AnalysisAnalysis
BuildBuildRequirement
Acquisition
RequirementAcquisition
DesignDesign
AnalysisAnalysis Build
BuildRequirementAcquisition
RequirementAcquisition
DesignDesign
AnalysisAnalysis
BuildBuild
RequirementAcquisition
RequirementAcquisition
RequirementsAnalysis
Design
Build
Version 1
Version 2Version 3
Version 4
Page : 7
OOAD
OOAD
2. Software Development Process Models
Positive and Negative Factors to the Success of Process Model
Chapter 1. Software Development Lifecycles (SDLC)
•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 : 8
OOAD
OOAD
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.
Chapter 1. Software Development Lifecycles (SDLC)
Waterfall Process Model
DesignDesign
AnalysisAnalysis
BuildBuild
RequirementAcquisition
RequirementAcquisition
Page : 9
OOAD
OOAD
DesignDesign
AnalysisAnalysis
BuildBuild
RequirementAcquisition
RequirementAcquisition
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.
Chapter 1. Software Development Lifecycles (SDLC)
Waterfall Process Model
Page : 10
OOAD
OOAD
Time
Risk
Design
Analysis
Build
RequirementAcquisition
Waterfall Process Model
Time Passed : Risk Increase
Chapter 1. Software Development Lifecycles (SDLC)
Page : 11
OOAD
OOAD
Time
Risk
Design
Analysis
Build
RequirementAcquisition
Waterfall Process Model
With Positive Factors : Time Passed : Risk Increase more Slowly
Positive Factors
Chapter 1. Software Development Lifecycles (SDLC)
Page : 12
OOAD
OOAD
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.
Chapter 1. Software Development Lifecycles (SDLC)
Incremental Process Model
DesignDesignAnalysisAnalysis BuildBuildRequirementAcquisition
RequirementAcquisition
DesignDesignAnalysisAnalysis BuildBuildRequirementAcquisition
RequirementAcquisition
DesignDesignAnalysisAnalysis BuildBuildRequirementAcquisition
RequirementAcquisition
Page : 13
OOAD
OOAD
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.
DesignDesignAnalysisAnalysis BuildBuildRequirementAcquisition
RequirementAcquisition
DesignDesignAnalysisAnalysis BuildBuildRequirementAcquisition
RequirementAcquisition
DesignDesignAnalysisAnalysis BuildBuildRequirementAcquisition
RequirementAcquisition
Delivery of 1st Increment (20% of Requirement)
Delivery of 2nd Increment (45% of Requirement)
Delivery of Complete Version (Nth increment)
Chapter 1. Software Development Lifecycles (SDLC)
Incremental Process Model
Page : 14
OOAD
OOAD
Incremental Process Model
DesignAnalysis BuildRequirementAcquisition
DesignAnalysis BuildRequirementAcquisition
DesignAnalysis BuildRequirementAcquisition
Time
Risk
Positive Factors
Incremental Process Model :Tend to Success
Chapter 1. Software Development Lifecycles (SDLC)
Page : 15
OOAD
OOAD
Incremental Process Model
DesignAnalysis BuildRequirementAcquisition
DesignAnalysis BuildRequirementAcquisition
DesignAnalysis BuildRequirementAcquisition
Time
Positive Factors
Risk
Incremental Process Model :Tend to Fail !
Chapter 1. Software Development Lifecycles (SDLC)
Page : 16
OOAD
OOAD
Spiral Process Model
•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 of development on the next phase
RequirementsAnalysis
Design
Build
Version 1
Version 2Version 3
Version 4
Chapter 1. Software Development Lifecycles (SDLC)
Page : 17
OOAD
OOAD
Spiral Process Model
DesignAnalysis BuildRequirementAcquisition
DesignAnalysis BuildRequirementAcquisition
DesignAnalysis BuildRequirementAcquisition
Time
Risk
Positive Factors
Spiral Process Model :Tend to Success
Chapter 1. Software Development Lifecycles (SDLC)
Page : 18
OOAD
OOAD
Spiral Process Model
DesignAnalysis BuildRequirementAcquisition
DesignAnalysis BuildRequirementAcquisition
DesignAnalysis BuildRequirementAcquisition
Time
Positive Factors
Risk
Spiral Process Model :Tend to Fail !
Chapter 1. Software Development Lifecycles (SDLC)
Page : 19
OOAD
OOAD
Chapter 2Requirements Acquisition
Chapter 2Requirements Acquisition
Page : 20
OOAD
OOAD
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
Chapter 2. Requirements Acquisition
Page : 21
OOAD
OOAD
Requirements Acquisition
To acquire requirements is to:
1. Initialize requirements acquisition session.2. Run requirements acquisition process.3. Summarize the requirements.4. If required, reprocess the acquisition.
Chapter 2. Requirements Acquisition
Page : 22
OOAD
OOAD
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
• explaining explaining the importance of development • explaining the effects of system on users and
stakeholders • explaining the expected association from users and
stakeholders.
Chapter 2. Requirements Acquisition
Page : 23
OOAD
OOAD
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
Chapter 2. Requirements Acquisition
Page : 24
OOAD
OOAD
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 solutions2nd phase: problem understanding3rd phase: clarify and confirmation
Chapter 2. Requirements Acquisition
Page : 25
OOAD
OOAD
Requirements Acquisition
2. Run the acquisition process (cont.)
1st phase: the first set of context-free questions should be asked by the analysts are:
• 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?
Chapter 2. Requirements Acquisition
Page : 26
OOAD
OOAD
Requirements Acquisition
2. Run the acquisition process (cont.)
2nd phase: the second set of context-free questions should be asked by the analysts are:
• 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?
Chapter 2. Requirements Acquisition
Page : 27
OOAD
OOAD
Requirements Acquisition
2. Run the acquisition process (cont.)
3rd phase: the second set of meta questions should be asked by the analysts are:
• Are my questions relevant to the problem you have?• Should I ask anything else?• Do you have any additional questions or suggestions?
Chapter 2. Requirements Acquisition
Page : 28
OOAD
OOAD
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:
• Normal Requirements• Expected Requirements• Exciting Requirements
Chapter 2. Requirements Acquisition
Page : 29
OOAD
OOAD
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: - specific system functions- favorite level of performance
Chapter 2. Requirements Acquisition
Page : 30
OOAD
OOAD
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: - error handling and recovery- user interface quality- ease of installation
Chapter 2. Requirements Acquisition
Page : 31
OOAD
OOAD
Requirements Acquisition
3. Summarize the requirements (cont.)
QFD: Exciting Requirements
• Requirements that go beyond customers’ expectation.• Proved to be very satisfying when presented.
Example: - help and tutorial.- layout and template function.- cross-application enabled components.
Chapter 2. Requirements Acquisition
Page : 32
OOAD
OOAD
Chapter 3 Object Orientation
Chapter 3 Object Orientation
Page : 33
OOAD
OOAD
Object คื�อ สิ่��งที่�มีตั วตัน และขอบเขตัที่�แน�นอน และมีสิ่��งตั�อไปน�
- Operation: สิ่��งที่�� Object สิ่ามารถกระที่�าได้� (ต้�องม�)- Unique Identity: สิ่��งที่��บ่�งบ่อกถ�งความม�อยู่��จร�งของ Object /ความแต้กต้�างจาก Object อ��นๆ (ต้�องม�)- Attribute: ค"ณสิ่มบ่$ต้�ที่�� Object ต้$วหน��งๆจะม�ได้� (อาจจะม�หร�อไม�ม�ก&ได้�)
Object: เคร��องบ่�นร" �น BOEING 747 จ"ผู้��โด้ยู่สิ่ารได้� 140 คน ที่��บ่�นออกจากด้อนเม�องไปยู่$ง Sydney ในว$นที่�� 15 เมษายู่น 2547 เวลา
1230 น.
Chapter 3. Object Orientation
Page : 34
OOAD
OOAD
Objects
CarClass
Class เป.น static descriptionObject เป.น instance ของ Class
Class
ค�อต้�นฉบ่$บ่ของ Object ซึ่��งม�ค"ณสิ่มบ่$ต้� (attribute) พฤต้�กรรม (operation) ที่��เหม�อนก$น
OO Principle : Abstraction
Chapter 3. Object Orientation
Page : 35
OOAD
OOAD
Carจ�านวนล�อขนาด้เคร��องยู่นต้3
Car:Truck Aจ�านวนล�อ 10=ขนาด้เคร��องยู่นต้3 10000
Car:Racer Bจ�านวนล�อ 4=ขนาด้เคร��องยู่นต้3 2500=
Class
Object
attribute
attribute value
Class: Attributes
Chapter 3. Object Orientation
Page : 36
OOAD
OOAD
Carจ�านวนล�อขนาด้เคร��องยู่นต้3
ต้�ด้เคร��องเด้�นหน�าถอยู่หล$ง
“ An Operation is the implementation of a service that can be requested from any object of the class to affect behavior.”
Operation
Operation ค�อบ่ร�การที่�� object ม�ให�เร�ยู่กใช้�งาน
Chapter 3. Object Orientation
Page : 37
OOAD
OOAD
หล$กการพ�5นฐานของ Object Orientation ประกอบ่ด้�วยู่ 3 ข�อ 1. Abstraction2. Encapsulation3. Modularity
Object OrientationObject OrientationA
bstraction
Encapsulation
Modularity
Chapter 3. Object Orientation
Page : 38
OOAD
OOAD
น�ยามีของ 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)
สิ่รุ�ปคื�อโครงร�างที่��ม�เฉพาะล$กษณะพ�เศษของต้$วเอง ที่��ที่�าให�แต้ก
ต้�างจากสิ่��งอ��นๆ
Chapter 3. Object Orientation
Page : 39
OOAD
OOAD
น�ยามีของ 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 ที่��ก�าหนด้ไว�เที่�าน$5น
Chapter 3. Object Orientation
Page : 40
OOAD
OOAD
สิ่รุ�ปคื�อModularity เป.นหล$กการเด้�ยู่วก$บ่ Divide & conquer ค�อการแบ่�งสิ่��งที่��ม�ขนาด้
ใหญ่� และ/หร�อ ม�ความซึ่$บ่ซึ่�อน ให�เป.นช้�5นๆ ที่��เล&กลง และจ$ด้การได้�ง�ายู่ข�5น
น�ยามีของ 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 software-engineering goals.”
Chapter 3. Object Orientation
Page : 41
OOAD
OOAD
Abstractions
Abstractions คื�อกรุะบวนการุในการุหาและใสิ่� Concept เข!าไปย ง Real-world Objects ที่�สิ่นใจเพื่��อก�อให!เก�ด Class
Abstractions สิ่ามีารุถจ&าแนกออกได!เป'น 4 กรุะบวนการุ คื�อ•Classification Abstraction•Aggregation Abstraction•Association Abstraction•Generalization Abstraction
Chapter 3. Object Orientation
Page : 42
OOAD
OOAD
Classification Abstractions
Classification Abstraction ค�อกระบ่วนการในการหาและใสิ่� Concept เข�าไปยู่$ง Real-world Objects เพ��อให�เก�ด้ Class
Concepts:ม�ร�างกายู่
สิ่��อสิ่ารด้�วยู่ภาษามน"ษยู่3
สิ่ามารถค�ด้ได้�
Class: คน
สิ่รพงษ3
Mary
หวงเฟยู่หง
Chapter 3. Object Orientation
Page : 43
OOAD
OOAD
Classification Abstractions (cont.)
การเปล��ยู่น Concept จะม�ผู้ลให� Class ม�ค"ณสิ่มบ่$ต้�เปล��ยู่นไป และอาจจะที่�าให�จ�านวนสิ่มาช้�กของ Object ใน Class น$5นเปล��ยู่นไปได้�
Concepts:ม�ร�างกายู่
สิ่��อสิ่ารด้�วยู่ภาษามน"ษยู่3
สิ่ามารถค�ด้ได้�เพศช้ายู่ Class: ผู้��ช้ายู่
สิ่รพงษ3
Mary
หวงเฟยู่หง
Chapter 3. Object Orientation
Page : 44
OOAD
OOAD
Classification Abstractions (cont.)
Class: น$กก�ฬาเบ่สิ่บ่อลช้ายู่
สิ่รพงษ3
Mary
หวงเฟยู่หง
Concepts:Concepts:
ม�ร�างกายู่สิ่��อสิ่ารด้�วยู่ภาษา
มน"ษยู่3สิ่ามารถค�ด้ได้�
เพศช้ายู่เล�นเบ่สิ่บ่อลได้�
Chapter 3. Object Orientation
Page : 45
OOAD
OOAD
Aggregation Abstraction
Aggregation Abstraction คื�อกรุะบวนการุในการุหาคืวามีสิ่ มีพื่ นธ์)ในเชิ�ง “องคื)ปรุะกอบ” รุะหว�าง Class
Class ที่�เป'นองคื)ปรุะกอบเรุยกว�า Component ClassClass ที่�เก�ดจากการุรุวมีก นของ Component Class เรุยกว�า Aggregated Class
Class: คน
ห$ว
แขนขา
ล�าต้$ว Aggregate
Chapter 3. Object Orientation
Page : 46
OOAD
OOAD
Aggregation Abstraction : Cardinalityใน Aggregation Abstraction เรุาจ&าเป'นตั!องรุะบ� Cardinality หรุ�อ จ&านวนของ Objects ของ Component Class ที่�มีได!น!อยที่�สิ่�ด (Minimum Cardinality: min-card) และมีากที่�สิ่�ด (Maximum Cardinality: max-card)ใน Aggregated Class
Class: คน
ห$ว
แขนขา
ร�างกายู่ Aggregate
1..1
1..1
0..2
0..2
Aggregate
0..nผู้ม
Chapter 3. Object Orientation
Page : 47
OOAD
OOAD
Association AbstractionAssociation Abstraction คื�อกรุะบวนการุในการุหาคืวามีสิ่ มีพื่ นธ์)รุะหว�าง Class ที่�แตักตั�างก น โดยเป'นคืวามีสิ่ มีพื่ นธ์)ที่�ไมี�ใชิ�ในเชิ�งที่�ข,�นตั�อก นเหมี�อนก บใน Aggregation Abstraction
ว�ช้าเร�ยู่นว�ช้าเร�ยู่น อาจารยู่3ผู้��สิ่อนอาจารยู่3ผู้��สิ่อน
น$กเร�ยู่นน$กเร�ยู่น
ห�องเร�ยู่นห�องเร�ยู่น
SectionSection
แบ่�งเป.น
สิ่อน
ม�
ใช้� เสิ่�นต้รงใช้�แสิ่ด้งความสิ่$มพ$นธ์3ระหว�าง Class ล�กศรใช้�ในการบ่อกที่�ศที่างของความสิ่$มพ$นธ์3
Chapter 3. Object Orientation
Page : 48
OOAD
OOAD
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)
Chapter 3. Object Orientation
Page : 49
OOAD
OOAD
Association Abstraction: CardinalityExample
One-to-One Association (1-1)
One-to-Many Association (1-M)
Many-to-Many Association (M-M)
คน บ่$ต้รประจ�าต้$วประช้าช้นม�1..1 0..1
รถยู่นต้3 ผู้��โด้ยู่สิ่ารบ่รรที่"ก1..1 0..n
น$กเร�ยู่น ว�ช้าเร�ยู่น0..n 0..nเร�ยู่น
Chapter 3. Object Orientation
Page : 50
OOAD
OOAD
Generalization AbstractionGeneralization Abstraction คื�อกรุะบวนการุในการุหาคืวามีสิ่ มีพื่ นธ์)รุะหว�าง Class ในล กษณะที่�มีการุเพื่��มีเตั�มี Attributes หรุ�อ Operations ให!ก บ Class เด�มี เพื่��อให!เก�ด Class ใหมี�ที่มีคื�ณล กษณะพื่�เศษแตักตั�างไปจากเด�มี โดย Class ใหมี�ได!รุ บถ�ายที่อด (inherit ) คื�ณล กษณะบางอย�างจาก Class เด�มีด!วยGeneralization Abstraction
สิ่ามีารุถจ&าก ดคืวามีได!ใน 2 คืวามีหมีายคื�อ-Generalize-Specialize
Chapter 3. Object Orientation
Page : 51
OOAD
OOAD
Generalization Abstraction: Generalize/ InheritanceGeneralization and Inheritance
InheritGeneralize
ม�ล�อ ม�
เคร��องยู่นต้3
ม�ล�อ ม�
เคร��องยู่นต้3
ตั�ดเที่อรุ)โบ
Super Class
Sub Class
Chapter 3. Object Orientation
Page : 52
OOAD
OOAD
Inheritance ก�อให!เก�ดแนวคื�ด Abstract Class และ Hierarchy
Generalization Abstraction: Generalize/ Inheritance
สิ่��งม�ช้�ว�ต้
พ�ช้ สิ่$ต้ว3
สิ่$ต้ว3บ่ก สิ่$ต้ว3ป=ก สิ่$ต้ว3น�5า
สิ่��งม�ช้�ว�ต้ จ$ด้เป.น Abstract Class: Class ที่��ไม�สิ่ามารถม� Object ของต้$วเองได้� แต้�จะม�ได้� ต้�องผู้�านการที่�า Inheritance ก�อน เสิ่มอ
Hierarchy 0
Hierarchy 1
Hierarchy 2
Parent / Child
Sibling
Chapter 3. Object Orientation
Page : 53
OOAD
OOAD
ในแง� Operations Inheritance ก�อให!เก�ดแนวคื�ด Overriding
Generalization Abstraction: Generalize/ Inheritance
เล�5ยู่ว เป.น Operation ที่�� รถต้�นต้ะขาบ่ได้�ร$บ่ถ�ายู่ที่อด้มาจากรถยู่นต้3 แต้�การเล�5ยู่วของรถต้�นต้ะขาบ่ ที่�างานต้�างจากการเล�5ยู่วของรถยู่นต้3อยู่�างสิ่�5นเช้�ง ซึ่��งเราจะเร�ยู่กว�า การเล�5ยู่วของรถต้�นต้ะขาบ่ได้� override การเล�5ยู่วของรถยู่นต้3
รถยู่นต้3
รถต้�นต้ะขาบ่
Operation: เล�5ยู่ว (ใช้�พวงมาล$ยู่)
Operation: เล�5ยู่ว (ใช้�ระบ่บ่ Mechanical Steering)
Inherit
Chapter 3. Object Orientation
Page : 54
OOAD
OOAD
EncapsulationEncapsulation หรุ�อการุซ่�อนรุายละเอยดของ Class (เปรุยบได!ก บการุน&าเอาสิ่��งตั�างๆ ที่�ย��งเหย�ง บรุรุจ�ไว!ใน Capsule) ก�อให!เก�ดแนวคื�ด
• Information Hiding การซึ่�อนรายู่ละเอ�ยู่ด้ของ Class และเป>ด้เผู้ยู่
เฉพาะสิ่�วนที่��จ�าเป.น ให�ภายู่นอกได้�ร$บ่ร� �• Polymorphism
การซึ่�อนว�ธ์�การที่�างานที่��แต้กต้�างก$นภายู่ใต้�ร�ปแบ่บ่การเร�ยู่กใช้�
งานแบ่บ่เด้�ยู่วก$น
Chapter 3. Object Orientation
Page : 55
OOAD
OOAD
Encapsulation: Information Hiding• Information Hiding
Class โด้ยู่ที่$�วๆ ไป แบ่�งระด้$บ่ของ Information Hiding
ออกเป.น 3 ระด้$บ่ด้�วยู่ก$น 1.Private: Attributes หร�อ Operations ซึ่��งเม��อเป.น
ของ Class ใด้แล�ว Class อ��นๆ ไม�สิ่ามารถเข�าถ�งได้�จากภายู่นอก
2.Protected: Attributes หร�อ Operations ที่��ไม�สิ่ามารถเข�าถ�งได้�จากภายู่นอก ยู่กเว�นจากต้นเอง และ Class ที่��ถ�ก Inherit ไปจากต้นเองเที่�าน$5น
3.Public: Attributes หร�อ Operations ที่��สิ่ามารถเห&นได้�ที่$นที่�จากภายู่นอก
Chapter 3. Object Orientation
Page : 56
OOAD
OOAD
Encapsulation: Information Hiding• Information Hiding
Attribute: ความค�ด้Operation: ค�ด้Attributes: Group เล�อด้Operation:
Attribute: สิ่�ผู้�วOperation: บ่อกอายู่"Operation: ว��ง
Class: น$กว��ง
Chapter 3. Object Orientation
Page : 57
OOAD
OOAD
Polymorphism (Poly + Morph (body))
ค�อการซึ่�อนว�ธ์�การที่�างานที่��แต้กต้�างก$นอยู่��ภายู่ใต้�ร�ปแบ่บ่การต้�ด้ต้�อ (interface) แบ่บ่เด้�ยู่วก$น เป.นการแยู่ก Implementation ออกจาก declaration
Encapsulation: Polymorphism
กด้ Remote Control เพ��อเพ��ม Volume เหม�อนก$น แต้�การเพ��ม Volume ของว�ที่ยู่"ที่�างานต้�างจากการเพ��ม Volume ของที่�ว�
ในที่าง ProgrammingPolymorphism จะแที่นด้�วยู่ค�าว�า Overloading
Chapter 3. Object Orientation
Page : 58
OOAD
OOAD
คื�อการุแบ�งหรุ�อย�อยรุายละเอยดตั�างๆ ที่�รุวมีก นอย-�ให!มีขนาดเล4กลง และ จ ดการุได!ง�ายดายข,�น
Decomposition การุแบ�งย�อย Application เพื่��อให!เก�ด ComponentsComposition กรุะบวนการุในการุที่&าให!เก�ด Components จาก Application หล ก
Modularity
ProgramProgram
FormButtonsUnit
ComponentsLibrary
Chapter 3. Object Orientation
Page : 59
OOAD
OOAD
การุสิ่รุ!าง Software ด!วยหล กการุ Object Orientation น �น คื�อ R: สิ่ร�างและต้�กรอบ่ Problem Domain A: จ�าลอง Real-World Objects ด้�วยู่ Class (ด้�วยู่การใช้� Abstraction Encapsulation
Modluarity) A: จ�าลองภาพก�จกรรมต้�างๆ ที่��จะเก�ด้ข�5นจร�งใน Problem Domain ที่��สิ่นใจ D: สิ่ร�างรายู่ละเอ�ยู่ด้ของ Class เพ��อการที่�างานในคอมพ�วเต้อร3 D: สิ่ร�างรายู่ละเอ�ยู่ด้ของก�จกรรมต้�างๆ ที่��จะเก�ด้ข�5นในคอมพ�วเต้อร3 B: สิ่ร�าง Class และ ก�จกรรมให�เก�ด้ข�5นจร�งในคอมพ�วเต้อร3
Object-Oriented Software Engineering (OOSE)
Chapter 3. Object Orientation
Page : 60
OOAD
OOAD
Object-Oriented Software Engineering (OOSE)
Not InComputer
InComputer
Abstract Level
Real W orld Level
RequirementAcquisition
Programming
Analysis Design
Chapter 3. Object Orientation
OOSE ConceptualVisualization
Page : 61
OOAD
OOAD
Chapter 4 Introduction to UML
Chapter 4 Introduction to UML
Page : 62
OOAD
OOAD
UML and Principles of Modeling
Chapter 4. Introduction to UML
1. The choice of what models to create has a profound influence on how a problem is attacked and how a solution is shaped.
2. Every model may be expressed at different levels of precision.
3. The best models are connected to reality.4. No single model is sufficient. Every nontrival system is
best approached through a small set of nearly independent models.
Unified Modeling Language (UML) is a language for modeling purposes. UML has to be used based on the principles of modeling:
Page : 63
OOAD
OOAD
UML Overview
Chapter 4. Introduction to UML
Things in UMLRelationships in UMLDiagrams in UMLRules of UML
This chapter gives intrduction on:
Page : 64
OOAD
OOAD
Chapter 4. Introduction to UML
Things in UML
There are 4 kinds of things in the UML:
1. Structural Things2. Behavioral Things3. Grouping Things4. Annotational Things
These things are the basic object-oriented building blocks of the UML.They are used to write “well-formed model”.
Page : 65
OOAD
OOAD
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. Classes2. Interfaces3. Use Cases4. Components5. Nodes
Page : 66
OOAD
OOAD
ApplianceOperation StatusVoltageNameModel
turn on()turn off()
ApplianceOperation StatusVoltageNameModel
turn on()turn off()
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 ElementProtected Element Public Element
Page : 67
OOAD
OOAD
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.
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.
IWorking
Page : 68
OOAD
OOAD
Chapter 4. Introduction to UML
Things in UML : Structural Things
1.3 Use Case
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.
Place Order
Page : 69
OOAD
OOAD
Chapter 4. Introduction to UML
Things in UML : Structural Things
1.4 Component
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.
orderform.java
Page : 70
OOAD
OOAD
Chapter 4. Introduction to UML
Things in UML : Structural Things
1.5 Node
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.
Server
Page : 71
OOAD
OOAD
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. Messages2. States
Page : 72
OOAD
OOAD
Chapter 4. Introduction to UML
Things in UML : Behavioral Things
2.1 Message
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.
display
Page : 73
OOAD
OOAD
Chapter 4. Introduction to UML
Things in UML : Behavioral Things
2.2 State
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.
waiting
Page : 74
OOAD
OOAD
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 : 75
OOAD
OOAD
Chapter 4. Introduction to UML
Things in UML : Groping Things
3.1 Package
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) .
Business Rules
Page : 76
OOAD
OOAD
Chapter 4. Introduction to UML
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”
Things in UML : Annotational Things
Page : 77
OOAD
OOAD
Chapter 4. Introduction to UML
Things in UML : Annotational Things
4.1 Note
We can use notes to adorn diagrams with constraints or comments that are best expressed in informal or formal text.
return copy of self
Page : 78
OOAD
OOAD
Chapter 4. Introduction to UML
Relationships in UML
There are 4 kinds of relationships in the UML:
1. Dependency2. Association3. Generalization4. Realization
These relationships are the basic relational building blocks of the UML. They are used to write well-formed models.
Page : 79
OOAD
OOAD
Chapter 4. Introduction to UML
Relationships in UML :
1. Dependency
Dependency is a semantic relationship between two things in which a change to one thing may affect the semantics of the other thing.Hardware
Operating System
Page : 80
OOAD
OOAD
Chapter 4. Introduction to UML
Relationships in UML :
2. AssociationAn 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.
Form
Application
1..*1..*
Employer Employee1..*1 employs
+work+hire
1..*1
AssociationAggregation
Page : 81
OOAD
OOAD
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)
In this way the child shares the structure and the behavior of the parent.
Notification
Message Box
Error Message Box
Page : 82
OOAD
OOAD
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.
You well see realization between interfaces and classes that realize them.
Car Actions
Car
Page : 83
OOAD
OOAD
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. Class Diagram ***2. Object Diagram 3. Use Case Diagram ***4. Sequence Diagram ***5. Collaboration Diagram ***6. Statechart Diagram ***7. Activity Diagram8. Component Diagram ***9. Deployment Diagram ***
Page : 84
OOAD
OOAD
Chapter 4. Introduction to UML
UML Diagrams Categories
The UML Diagram can be categorized in 2 schemes
Scheme 1: Characteristics of UML diagramsStatic DiagramsDynamic Diagrams
Scheme 2: Usages of UML diagramsConceptual DiagramsArchitectural Diagrams
Scheme 2 is the scheme applied in this course
Page : 85
OOAD
OOAD
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 for Requirement Modeling - Use Case Diagram• Models for Static Modeling - Class Diagram• Models for Dynamic Modeling - Sequence Diagram,Collaboration
Diagram• Models for Activity Modeling - Activity Diagram, Statchart Diagram
In OOSE, conceptual diagrams are created in OOA and are refined in OOD.
Page : 86
OOAD
OOAD
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 - Component Diagram• Models for Hardware Platform - Deployment Diagram
In OOSE, architectural diagrams are created in OOD.
Page : 87
OOAD
OOAD
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
• Names what can call things, relationships, and diagrams• Scope the context that gives specific meaning to a name• Visibility how those names can be seen and used by others• Integrity how things properly and consistently relate to
one another• Execution what it means to run or simulate a dynamic
model
Page : 88
OOAD
OOAD
Chapter 5Object Oriented Analysis
Chapter 5Object Oriented Analysis
Page : 89
OOAD
OOAD
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 : 90
OOAD
OOAD
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 : 91
OOAD
OOAD
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:
• 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
OOAD
OOAD
Chapter 5. OOA
Object Oriented Analysis (OOA)
How can Models be applied in OOA
• 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
USE CASE DIAGRAM
CLASS DIAGRAM
INTERACTION DIAGRAM
STATECHART DIAGRAM
Page : 93
OOAD
OOAD
Chapter 5. OOA
Object Oriented Analysis (OOA)
How can Models be applied in OOA
1. Model Requirements with Use Case Diagram2. Medel Static Element with Class Diagram3. Behavior Modeling
• Sequence Diagram• State Chart Diatgram
Page : 94
OOAD
OOAD
Chapter 5. OOA
1. Use Case Modeling
1. Use Cases 2. Actors3. Use Cases and Flow of Events4. Use Cases and Scenarios5. Use Case Diagram Organization Techniques
System Context ModelingSystem Requirements Modeling
Page : 95
OOAD
OOAD
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
Loan Officer
Actor
Use Case
Page : 96
OOAD
OOAD
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
Loan Officer
Actor
Use Case
Page : 97
OOAD
OOAD
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
Loan Officer
Actor
Use Case
Page : 98
OOAD
OOAD
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
Loan Officer
Actor
Use Case
Page : 99
OOAD
OOAD
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
Loan Officer
Actor
Use Case
Page : 100
OOAD
OOAD
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 : 101
OOAD
OOAD
Chapter 5. OOA
1.2 Actors
Loan Officer
Senior Loan Officer
Generalization Specialization of Actors
We can inherit properties of one actor
A specialized actor may play different roles compared to based actor.
Page : 102
OOAD
OOAD
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 : 103
OOAD
OOAD
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 : 104
OOAD
OOAD
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 committing it and reenter a new PIN
number
Page : 105
OOAD
OOAD
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.Class
ObjectObject ObjectObjectObjectObject
Use Case
ScenarioScenarioScenarioScenario
ScenarioScenario
Page : 106
OOAD
OOAD
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>>
<<extends>>
Include
Extend
Generalization
Page : 107
OOAD
OOAD
Chapter 5. OOA
Example of Generalization, Include and Extend in Use Cases
Track Order
Place Rush Order
Check Password
Place Order
<<extend>>
Validate User
<<include>>
<<include>>
1.5 Use Case Diagram Organization Techniques
Page : 108
OOAD
OOAD
Chapter 5. OOA
Example of Use Case Diagram
Place Conf erence Call
Receiv e Additional Call
Cellular Network
Receiv e Phone Call
<<extend>>
Place Phone Call
<<extend>>
UserUse Scehduler
1.5 Use Case Diagram Organization Techniques
Page : 109
OOAD
OOAD
Chapter 5. OOA
To construct Use Case Diagram is to:
1.5 Use Case Diagram Organization Techniques
Model the Context of a SystemModel the Requirements of the System
System Context
Requirement ModelForward engineer
refine
Reverse engineer
Page : 110
OOAD
OOAD
Chapter 5. OOA
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 caseWho should responsible for constructing system context modelAnswer. “Users & Stakeholders”
1.5 Use Case Diagram Organization Techniques
Modeling the Context of a System
Page : 111
OOAD
OOAD
Chapter 5. OOA
Example: Credit Card Validation System : System ContextActors
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 Retail Institution
Sponsoring FIIndiv idual Customer
Corporate Customer
1.5 Use Case Diagram Organization TechniquesModeling the Context of a System
Page : 112
OOAD
OOAD
Chapter 5. OOA
Example: Credit Card Validation System : System ContextUse 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)
Perf orm Card Transaction
Manage Customer Account
Process Customer Bill
1.5 Use Case Diagram Organization TechniquesModeling the Context of a System
Page : 113
OOAD
OOAD
Chapter 5. OOA
Example: Credit Card Validation System : System ContextPreliminary Use Cases Diagram for System Context
Individual Customer
Corporate Customer
Perform Card Transaction
Process Customer Bill
Customer
Retail Institution
Sponsoring FI
Manage Customer Account
1.5 Use Case Diagram Organization TechniquesModeling the Context of a System
Page : 114
OOAD
OOAD
Chapter 5. OOA
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 ModelAns. “System Analysts + Users”
1.5 Use Case Diagram Organization TechniquesModeling the Requirements of a System
Page : 115
OOAD
OOAD
Chapter 5. OOA
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.
1.5 Use Case Diagram Organization TechniquesModeling the Requirements of a System
Page : 116
OOAD
OOAD
Chapter 5. OOA
Example: Credit Card Validation System : Requirements ModelRequirements Use Case Model Step 1
Indiv idual Customer
Corporate Customer
Perf orm Card Transaction
Process Customer Bill
Customer
Detect Card Fraud
Retail Institution
Report on Account
Sponsoring FI
Manage Customer Account
1.5 Use Case Diagram Organization TechniquesModeling the Requirements of a System
Page : 117
OOAD
OOAD
Chapter 5. OOA
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
1.5 Use Case Diagram Organization TechniquesModeling the Requirements of a System
Page : 118
OOAD
OOAD
Chapter 5. OOA
Example: Credit Card Validation System : Requirements Model
Requirements Use Case Model Step 2
Indiv idual Customer Corporate
Customer
Process Customer Bill
Customer
Detect Card Fraud
Retail Institution
Sponsoring FI
Manage Customer Account
Verif y Card Holder
Ad hoc ReportReport on Account
<<extend>>
Perf orm Online Transaction
Perf orm Card Transaction
<<include>>
1.5 Use Case Diagram Organization TechniquesModeling the Requirements of a System
Page : 119
OOAD
OOAD
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 spiral process model
1 2
3
4 5
Page : 120
OOAD
OOAD
Chapter 5. OOA
2.1 Find Out Classes
Class Modeling
1. Actor could be a class in class diagram2. Behavior from each use case must be provided by class
Find Basic Classes from Use Cases:
1. 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)
2. Some nouns in the description could become either class or attribute of class.
3. Put the union product of nouns found in each use case into a class pool.
4. Note that, one class can reside in multiple use cases5. Eliminate the class that is not in a scope (or be the scope itself)
How to:
Page : 121
OOAD
OOAD
Chapter 5. OOA
Librarian
Customer
Example : The Library
Borrow Books
Return 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 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.
Class Modeling
Page : 122
OOAD
OOAD
Chapter 5. OOA
Directions:
Try to think of the feasible functions of library system that can serve these requirements:
• 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.
Exercise 1: Refine Use Case Diagram
Page : 123
OOAD
OOAD
Chapter 5. OOA
2.1 Find Out Classes
Example : The Library
Borrow Books
Return Books
Librarian
Customer
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.
Page : 124
OOAD
OOAD
Chapter 5. OOA
2.1 Find Out Classes
Possible to be classes:
CustomerBookLibrarianLibraryMember CardBorrowed Items
Possible to be Attributes
Due Date
Example : The Library
Borrow Books
Librarian
Customer
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.
Find Class
Page : 125
OOAD
OOAD
Chapter 5. OOA
2.1 Find Out Classes
Example : The Library
Possible to be classes:
CustomerBookLibrarianBorrowed Items
Possible to be Attributes
Due DatePunishment Charge
Librarian
CustomerReturn 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.
Find Class
Page : 126
OOAD
OOAD
Chapter 5. OOA
2.1 Find Out Classes
Example : The Library
CustomerBookLibrarianBorrowed Items
Due DatePunishment Charge
CustomerBookLibrarianLibraryMember CardBorrowed Items
Due Date
CustomerBookLibrarianLibraryMember CardBorrowed Items
Due DatePunishment Charge
Construct Class PoolClass Pool
Page : 127
OOAD
OOAD
Chapter 5. OOA
2.1 Find Out Classes
Example : The Library
CustomerBookLibrarianLibraryMember CardBorrowed Items
Due DatePunishment Charge
CustomerBookMember CardBorrowed Items
Due DatePunishment Charge
Eliminate out-of-scope classes from Class Pool
The system itself
Unrequired
Page : 128
OOAD
OOAD
Chapter 5. OOA
2.2 Specify Attributes and Methods
Find Basic Methods
1. From the use case description. Method of classes are implicitly shows in verbs
2. 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.
3. Some method found may be in or out of scope. Select just required methods.
4. Note that, methods found in this phase is usually “Public” methods.
5. Think of class responsibilities and service that classes should provide and fill it.
Page : 129
OOAD
OOAD
Chapter 5. OOA
Example : The Library
Borrow Books
Librarian
Customer
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.
Find Methods
2.2 Specify Attributes and Methods
Verbs Found:Take the BookBorrow the BookVerify Member CardSet Due Date for Each Book
SynonymBook has method borrow
Member Card has method verify
Book has method set due date
Page : 130
OOAD
OOAD
Chapter 5. OOA
Example : The Library
Librarian
CustomerReturn 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.
Find Methods
2.2 Specify Attributes and Methods
Verbs Found:Shows the BookCheck the Due Date of BookPay Punishment Charge of A Book
Book has method show
Book has method check due date Book has method pay
punishment charge
Not a required method
Page : 131
OOAD
OOAD
Chapter 5. OOA
Example : The Library
Find Methods : Summary
2.2 Specify Attributes and Methods
Book has method check due dateBook has method pay punishment charge
Book has method borrow
Member Card has method verify
Book has method set due date
Page : 132
OOAD
OOAD
Chapter 5. OOA
2.2 Specify Attributes and Methods
Find Basic Attributes
1. Primarily, from the use case description the noun or adjective that explains or belongs to the class could be an attributes of that class.
2. Refer to the methods, normally there should be some attributes of class that is affected as result of a methods.
Page : 133
OOAD
OOAD
Chapter 5. OOA
Example : The Library
Borrow Books
Librarian
Customer
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.
Number of borrowed items is of CustomerIndividial Limit explains CustomerDue Date explains Book
Possible to be Attributes
Find Attribtes
2.2 Specify Attributes and Methods
Page : 134
OOAD
OOAD
Chapter 5. OOA
Example : The Library
Possible to be Attributes
Due Date explains BookPunishment Charge belongs to BookExcess the Due Date Status explains Book
Librarian
CustomerReturn 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.
Find Attributes
2.2 Specify Attributes and Methods
Page : 135
OOAD
OOAD
Chapter 5. OOA
Example : The Library
Find Attributes:
Book has method check due dateBook has method pay punishment charge
Book has method borrow
Member Card has method verify
Book has method set due date
From finding Methods we learn that:
Book Already has Due Date
Book Already has Punishment ChargeBook should has Borrowed Status
Member Card should has Verified Status
2.2 Specify Attributes and Methods
Page : 136
OOAD
OOAD
Chapter 5. OOA
Example : The Library
Find Attributes: Summary
Customer contains attributes:Number of Borrowed ItemsIndividual Limits
Book contains attributes:Due DatePunishment ChargeExcess Due Date StatusBorrowed Status
Member Card contains attributesVerified Status
2.2 Specify Attributes and Methods
Page : 137
OOAD
OOAD
Chapter 5. OOA
System Vocabulary
System vocabulary is
• 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.
2.3 Build System Vocabulary
Page : 138
OOAD
OOAD
Chapter 5. OOA
Example : The Library : System Vocabulary
CustomerNumber of Borrowed ItemsIndividual Limits
Member CardVerified Status
Verify()BookDue DatePunishment ChargeBorrow StatusExcess Due Date Status
Set Due Date()Check Due Date()Pay Punishment Charge()Borrow()
Borrow Items
2.3 Build System Vocabulary
Page : 139
OOAD
OOAD
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.
CustomerNumber of Borrowed ItemsIndividual Limits
Member CardVerified Status
Verify()BookDue DatePunishment ChargeBorrow StatusExcess Due Date Status
Set Due Date()Check Due Date()Pay Punishment Charge()Borrow()
Borrow Items
Book
Book IdBook NameBook TypePunishment ChargeBorrowed Status
Set Punishment Charge()
(from Logical View)Member Card
Verified StatusMember Card IdExpire Date
Verify()Extend()
(f rom Logical View)
Customer
Number of Borrowed ItemsIndividual Limit
IdCustomer Name
Customer Address
(f rom Business Use-Case Model)
0..*
0..*
0..*
0..* 11 11
Book Borrowing
Due Date
Book TransactionBook IdCustomer IdTransaction TypeTransaction Date
Book ReturnSum Charge
Calculate Charge()
Page : 140
OOAD
OOAD
Chapter 5. OOA
2.4 Build Class Diagram
Book
Book IdBook NameBook TypePunishment ChargeBorrowed Status
Set Punishment Charge()
(from Logical View)Member Card
Verified StatusMember Card IdExpire Date
Verify()Extend()
(f rom Logical View)
Customer
Number of Borrowed ItemsIndividual Limit
IdCustomer Name
Customer Address
(f rom Business Use-Case Model)
0..*
0..*
0..*
0..* 11 11
Book Borrowing
Due Date
Book TransactionBook IdCustomer IdTransaction TypeTransaction Date
Book ReturnSum Charge
Calculate Charge()
Example : The Library: Class Diagram (built from system vocab.)
Page : 141
OOAD
OOAD
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 : 142
OOAD
OOAD
Chapter 5. OOA
2.4 Build Class DiagramClass Diagram of Library System
Book
Book IdBook NameBook TypePunishment ChargeBorrowed Status
Set Punishment Charge()
(from Logical View)Member Card
Verified StatusMember Card IdExpire Date
Verify()Extend()
(f rom Logical View)
Customer
Number of Borrowed ItemsIndividual Limit
IdCustomer Name
Customer Address
(f rom Business Use-Case Model)
0..*
0..*
0..*
0..* 11 11
Book Borrowing
Due Date
Book TransactionBook IdCustomer IdTransaction TypeTransaction Date
Book ReturnSum Charge
Calculate Charge()
Page : 143
OOAD
OOAD
Chapter 5. OOA
2.4 Build Class DiagramClass Diagram of Library System
Member Card
Verified StatusMember Card IdExpire Date
Verify()Extend()
(from Logical View)
Customer
Number of Borrowed ItemsIndividual Limit
IdCustomer Name
Customer Address
(from Business Use-Case Model)
11 11
Book Borrowing
Due Date
Book Transaction
Book IdCustomer IdTransaction TypeTransaction Date
Book ReturnSum Charge
Calculate Charge()
Book ShelfShelf IdShelf NameShelf Description
Book
Book IdBook NameBook TypePunishment ChargeBorrowed Status
Set Punishment Charge()
(from Logical View)
0..*
0..*
0..*
0..*
Shelf SlotSlot IdSlot Location
1..*
0..1
0..*is on
0..*
0..1
1..*
Page : 144
OOAD
OOAD
Chapter 5. OOA
2.4 Build Class DiagramClass Diagram of Library System – more refiend
Member Card
Verif ied StatusMember Card IdExpire Date
Verif y ()Extend()
(from Logical View)
Customer
Number of Borrowed ItemsIndiv idual Limit
IdCustomer Name
Customer Address
(from Business Use-Case Model)
11 11
Book Borrowing
Due Date
Book Transaction
Book IdCustomer IdTransaction Ty peTransaction Date
Book Return
Sum Charge
Calculate Charge()
Book Shelf
Shelf IdShelf NameShelf Description
Shelf Slot
Slot IdSlot Location
1..*1..*
Book Inventory
Book Category IdBook Category NameOutstanding
Book Income()Book OutGo()
Book
Book IdBook NameBook Ty pePunishment ChargeBorrowed Status
Set Punishment Charge()
(f rom Logical View)
0..*
0..*
0..*
0..*
0..1
0..*
0..1
0..*is on0..*
1
has
0..*
1
Page : 145
OOAD
OOAD
Chapter 5. OOA
Interaction Diagram
Interaction Diagram shows an interaction, consisting of 1. A set of classes or objects2. Their relarionships3. Messages that may be dispatched among classes or objects
2 typess of interaction diagrams
1. Sequence Diagram emphsizes time ordering of messages.
2. Collaboration Diagram emphasizes structural organization of objects or classes that send and receive messages
Page : 146
OOAD
OOAD
Chapter 5. OOA
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:- Objects- Links- Messages
Interaction Diagram
Page : 147
OOAD
OOAD
Chapter 5. OOA
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)
Interaction Diagram
Page : 148
OOAD
OOAD
Chapter 5. OOA
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)
Interaction Diagram
Page : 149
OOAD
OOAD
Chapter 5. OOA
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.
Interaction Diagram
Page : 150
OOAD
OOAD
Chapter 5. OOA
Customer : <Actor Name>
ATM KeyPad
Enter Pin Code The method “Enter Pin Code” belongs to classATM KeyPad, not Customer.
We can say that “Enter Pin Code” is the service provided by ATM Keypad
If the method “Enter Pin Code” is now not of “ATM KeyPad”, this method must be added as public method of class ATM Keypad.
Customer : <Actor Name>
ATM KeyPad
1: Enter Pin Code
Sequence diagram
Collaboration diagram
Interaction Diagram
Page : 151
OOAD
OOAD
Chapter 5. OOA
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).
Customer : <Actor Name>
ATM KeyPad Screen
Enter Pin CodeShowMessage("Enter Amount")
Sequence diagram
Interaction Diagram
Page : 152
OOAD
OOAD
Chapter 5. OOA
Sequence Diagram emphasizes the time ordering of messages.
To form a sequence diagram is to1. Place the classes or objects that participate in
interaction at a top of diagram along the X axis2. Move the initiate class to the left3. 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.
Interaction Diagram
Sequence Diagram
Page : 153
OOAD
OOAD
Chapter 5. OOA
Interaction DiagramSequence Diagram
Sequence Diagram Syntax
: Client : Transaction : Account
create
check Balance
update Balance
desrtroy
Tim
e p
asse
d
Classes or Objects
MessagesTimeline
Focus of Control
Page : 154
OOAD
OOAD
Chapter 5. OOA
Collaboration Diagram emphasizes the organization of the objects that participate in an interaction.
How to Build the Collaboration Diagram1. Place the classes or objects that participate in interaction
as a vertices in a graph.2. Render the link of message that connect the objects as the
arc of the graph.3. Give the name of the message led by the number to show
the sequence of interaction
Interaction Diagram
Collaboration Diagram
Page : 155
OOAD
OOAD
Chapter 5. OOA
Interaction DiagramCollaboration Diagram
: Client : Transaction
: Account
1: create
2: check Balance3: update Balance
4: desrtroy
Class or Objects
Sequence of Messages
LinkCollaboration Diagram Syntax
Page : 156
OOAD
OOAD
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 : 157
OOAD
OOAD
Chapter 5. OOA
CASE STUDY: (30 points)
Foreign Currency Exchange SystemAnalysis
Page : 158
OOAD
OOAD
Chapter 5. OOA
CASE STUDY:
Foreign Currency Exchange SystemAnalysis
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 : 159
OOAD
OOAD
Chapter 5. OOA
CASE STUDY:
Foreign Currency Exchange SystemAnalysis
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 : 160
OOAD
OOAD
Chapter 5. OOA
CASE STUDY: Foreign Currency Exchange System Analysis
Manage Orders
(from Use Case)
Bank Customer
(from Actors)
General Customer
(from Actors)
Place the Order
(from Use Case)
Manage Stocks
(from Use Case)
Bank
(from Actors)
Manage Customer Inf ormation
(from Use Case)
System Context
Page : 161
OOAD
OOAD
Chapter 5. OOA
CASE STUDY: Foreign Currency Exchange System Analysis
Requirements Model
Bank Customer
(f rom Actors)General Customer
(f rom Actors)
Manage Customer Information
(f rom Use Case)
Place FCCY Order
(f rom Use Case)
Place Travel ler Check Order
(f rom Use Case)
Manage Traveller Check Order
(f rom Use Case)
Manage Stocks
(f rom Use Case)
<<extend>>
Manage Foreign Currency Order
(f rom Use Case)
<<extend>>
Customer
(f rom Actors)
Place the Order
(f rom Use Case)
Manage Orders
(f rom Use Case)
Convert Exchange Rate
(f rom Use Case)
<<include>>
Bank
(f rom Actors)
Manage Exchange Rate
(f rom Use Case)
Page : 162
OOAD
OOAD
Chapter 5. OOA
CASE STUDY: Foreign Currency Exchange System Analysis
System Vocabulary
General Customer
(f rom Actors)
Foreign Curency Payment(from Classes)
Foreign Currency Order
(from Classes)
pays
Travel ler Cheque Payment
(from Classes)
Travel ler Cheque Order
(from Classes)
pays
Customer
(f rom Actors)
Exchange Rate(from Classes)
Bank
(f rom Actors)
Money Stocks
(f rom Classes)
manage
Bank Customer
(f rom Actors)
Account(f rom Classes)
has
Order(f rom Classes)
place
Bank Branch
(f rom Actors)
Payment(f rom Classes)
receive
manage
manage
Page : 163
OOAD
OOAD
Chapter 5. OOA
CASE STUDY: Foreign Currency Exchange System Analysis
Requirements Model(Iterative 2)
Convert Exchange Rate
(f rom Use Case)
Bank Customer
(f rom Actors)General Customer
(f rom Actors) Place FCCY Order
(f rom Use Case)
Place Travel ler Check Order
(f rom Use Case)
Manage Traveller Check Order
(f rom Use Case)
Manage Stocks
(f rom Use Case)
Manage Foreign Currency Order
(f rom Use Case)
Customer
(f rom Actors)
Place the Order
(f rom Use Case)
Bank
(f rom Actors)
Manage Exchange Rate
(f rom Use Case)
<<extend>>
<<extend>>
Manage Customer Information
(f rom Use Case)
Bank Branch
(f rom Actors)
Manage Orders
(f rom Use Case)
<<include>>
Page : 164
OOAD
OOAD
Chapter 5. OOA
CASE STUDY: Foreign Currency Exchange System Analysis
Preliminary Class Diagram
General Customer
(f rom Actors)
Foreign Currency Order
FCCYOrderId
(from Classes)
Foreign Curency Payment
FCCYPaymentId
(from Classes)
1
1pays
Traveller Cheque Order
TravChequeOrderId
(from Classes)
Travel ler Cheque Payment
TravChequePaymentId
(from Classes)
1
1
pays
Money Stocks
CurrencyStockAmount
increase()decrease()
(f rom Classes)
Account
Account NumberAccount NameAccount Balance
deposit()withdraw()
(from Classes)
Bank Customer
(f rom Actors)
1
1
has
Order
OrderIdOrderType
(f rom Classes)
Customer
(f rom Actors)0..*
1
place
Payment
PaymentIdPaymentType
(from Classes)
0..*
1
receive
Bank Branch
(f rom Actors)
0..*
1
manage
0..*
1
manage
0..*
1
0..*
1
0..*
10..*
1
1
1
Bank
(f rom Actors)
0..*
1
manage
Exchange Rate
FirstCurrencySecondCurrencyExchangeRateExchangeDate
(from Classes)0..*
1 acquire
0..*
1
0..*
1
1
1
1
1
Page : 165
OOAD
OOAD
Chapter 5. OOA
CASE STUDY: Foreign Currency Exchange System Analysis
Class Diagram
General Customer
(f rom Actors)
Foreign Currency Order
Denomination
(from Classes)
Foreign Curency Payment
FCCYPremium
(from Classes)
Traveller Cheque Order
TravChequeOrderId
(from Classes)
Traveller Cheque Payment
Travel lerChequeFeeTravel lerChequeExpireDateTravel lerChequeNumber
(from Classes)
Account
Account NumberAccount NameAccount Balance
deposit()withdraw()
(from Classes)
Bank Customer
(f rom Actors)
Customer
CustomerIdCustomerName
CustomerAddressCustomerPhone
(f rom Actors)
Order
OrderIdOrderTypeOrderDateOrderStatusOrderCurrencyOrderAmount
setStatus()
(from Classes)
Payment
PaymentIdPaymentTypePaymentDatePaymentStatus
setStatus()
(from Classes)
Bank Branch
BranchIdBranchName
BranchLocation
(f rom Actors)Money Stocks
CurrencyStockAmount
increase()decrease()
(f rom Classes)
Exchange Rate
FirstCurrencySecondCurrencyExchangeRateExchangeDate
(from Classes)
Bank
BankIdBankName
(f rom Actors)
1
1
1
1
pays
1
1
1
1
pays
1
1
1
1
has
0..*
1
0..*
1place
0..*
1
0..*
1
receive
0..*
1
0..*
1
manage
0..*
1
0..*
1
manage
0..*
1
0..*
1
manage
0..*1
0..*1
acquire
Page : 166
OOAD
OOAD
Chapter 5. OOA
CASE STUDY: Foreign Currency Exchange System Analysis
Sequence Diagram:Manage Customer Information – New Customer
: Customer : Bank Branch
[new customer] create()
: Bank Customer : General Customer
: Account
[want to open account] create()
[do not want to open account] create()
create()
Page : 167
OOAD
OOAD
Chapter 5. OOA
CASE STUDY: Foreign Currency Exchange System Analysis
Sequence Diagram:Manage Customer Information – Not New Customer
: Customer : Bank Branch
[new customer] create()
: Bank Customer : General Customer
: Account
[want to open account] create()
[do not want to open account] create()
create()
Page : 168
OOAD
OOAD
Chapter 5. OOA
CASE STUDY: Foreign Currency Exchange System Analysis
Sequence Diagram:Manage Stock – Decrease Stock
: Bank : Money Stocks
checkStockAmount
[more than decreased amount]decrease( )
Page : 169
OOAD
OOAD
Chapter 5. OOA
CASE STUDY: Foreign Currency Exchange System Analysis
Sequence Diagram:Manage Stock – Increase Stock
: Bank : Money Stocks
increase( )
Page : 170
OOAD
OOAD
Chapter 5. OOA
CASE STUDY: Foreign Currency Exchange System Analysis
Sequence Diagram:Place Foreign Currency Order
: Customer : Foreign
Currency Order
create()
setStatus( "new order")
[is bank customer] setReceivingMethod()
[is receive by Account] setReceivingAccountNumber()
Page : 171
OOAD
OOAD
Chapter 5. OOA
CASE STUDY: Foreign Currency Exchange System Analysis
Sequence Diagram:Place Traveller Cheque Order
: Customer : Traveller
Cheque Order
create()setStatus( "new")
Page : 172
OOAD
OOAD
Chapter 5. OOA
CASE STUDY: Foreign Currency Exchange System Analysis
YOUR JOBSYOUR 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 : 173
OOAD
OOAD
Chapter 6Object Oriented Design
Chapter 6Object Oriented Design
Page : 174
OOAD
OOAD
Chapter 6. OOD
Object Oriented Design
1. OOA Models Refienement• Class Diagrams Refinement• Interaction Diagrams Refinement• Forward and Backward Engineering
2. Activity Design3. Architecture Design
• Component Design• Hardware Platform Design
4. Persistent Data Design
Page : 175
OOAD
OOAD
Chapter 6. OOD
Object Oriented Design
1. OOA Models Refienement
1.Class Diagram Refinement2.Interaction Diagram Refinement3.Forward and Backward Engineering
Class Diagram Refinement
Behavior DiagramRefinement
Page : 176
OOAD
OOAD
Chapter 6. OOD
Object Oriented Design: OOA Models Refinement
Class Diagram Refinement
Refinement Techniques
• 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
Page : 177
OOAD
OOAD
Chapter 6. OOD
Object Oriented Design: OOA Models Refinement
Class Diagram RefinementAdd 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 : 178
OOAD
OOAD
Chapter 6. OOD
Object Oriented Design: OOA Models Refinement
Class Diagram RefinementClarify Attributes and Methods of Class
Clarification TechniquesThe 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 : 179
OOAD
OOAD
Chapter 6. OOD
Object Oriented Design: OOA Models Refinement
Class Diagram RefinementAdd non-business attributes
What are the non-business attributesThe 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 : 180
OOAD
OOAD
Chapter 6. OOD
Object Oriented Design: OOA Models Refinement
Class Diagram RefinementAdd 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 : 181
OOAD
OOAD
Chapter 6. OOD
Object Oriented Design: OOA Models Refinement
Class Diagram RefinementRefine 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 : 182
OOAD
OOAD
Chapter 6. OOD
Object Oriented Design: OOA Models Refinement
Class Diagram RefinementAdd 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 concepts1. Modularity 2. Polymorphism.
Page : 183
OOAD
OOAD
Chapter 6. OOD
Object Oriented Design: OOA Models Refinement
Class Diagram RefinementAdd Interfaces (cont.d)
Interface never been a one-man-show component.But:
It always be inheritted, so called, specialized by classon the other hands :
class always possesses the operations provided by interface
Page : 184
OOAD
OOAD
Chapter 6. OOD
Object Oriented Design: OOA Models Refinement
Class Diagram RefinementAdd Interfaces (cont.d)
UML notations for interfaces: in UML an interface is represented by a circle
Vehicle Interf ace
ref uel()stop()
Car
Engine CC
driv e()
Airplane
Engine Ty peVertical Wing Ty pe
Landing()Take Of f ()
Interface
Page : 185
OOAD
OOAD
Chapter 6. OOD
Object Oriented Design: OOA Models Refinement
Class Diagram RefinementAdd Interfaces (cont.d)
When to Use InterfacesThe 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 : 186
OOAD
OOAD
Chapter 6. OOD
Exercise 4: Part IRefine 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 : 187
OOAD
OOAD
Chapter 6. OOD
Exercise 4: Part IRefine the OOA Diagrams Bill
Bil l NumberBil l Type
print()
Deposit Transaction
Deposit TypeWithdraw Transaction
Id Card Number
TransactionTransaction NumberTransaction TypeTransaction DateTransaction Amount'Transaction Status
take Action()
confirm
Customer
(f rom Actors)
Bank
Deposit AccountAccount NumberAccount NameOutstanding Amount
deposit()withdraw()
providehold
effect
Overdraft Withdraw Transaction
OD Interest Rate
Page : 188
OOAD
OOAD
Chapter 6. OOD
Object Oriented Design: OOA Models Refinement
Interaction Diagram Refinement
Refinement Techniques
• Refine the existing messges• Add the non-business classes and
their corresponding message to the sequence diagram
Page : 189
OOAD
OOAD
Chapter 6. OOD
Object Oriented Design: OOA Models Refinement
Interaction Diagram RefinementRefine 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 : 190
OOAD
OOAD
Chapter 6. OOD
Object Oriented Design: OOA Models Refinement
Interaction Diagram RefinementAdd 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
TechniquesFor the sequence Diagram:
•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.
Page : 191
OOAD
OOAD
Chapter 6. OOD
Exercise 4: Part IIRefine 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 : 192
OOAD
OOAD
Chapter 6. OOD
Exercise 4: Part IIRefine the OOA Diagrams
: Customer
: Deposit Transaction
: Deposit Account
: Bill
fill()deposit( )
print( )
Sequence Diagram for “Depositing the Money” to Account
Page : 193
OOAD
OOAD
Chapter 6. OOD
Exercise 4: Part IIRefine the OOA Diagrams
Sequence Diagram for “Withdraw the Money” from Account
: Customer : Withdraw Transaction
: Deposit Account
: Bill
fill()withdraw( )
print( )
Page : 194
OOAD
OOAD
Chapter 6. OOD
Exercise 4: Part IIRefine the OOA Diagrams
Sequence Diagram for “Overdraft Withdraw”
: Customer : Bank : Overdraft Withdraw
Transaction : Deposit Account
: Bill
fill()
set Interest()withdraw( )
print( )
Page : 195
OOAD
OOAD
Chapter 6. OOD
Cla
ss Dia
gra
m
Refi
nem
ent
Behavio
r D
iag
ram
Refi
nem
ent
Object Oriented Design: OOA Models Refinement
Forward and Backward EngineeringDefinition• Forward Engineering: the
refinement on class diagram effects the behavior diagrams
• Backward Engineering: the refinement on behavior diagrams effects the class diagrams
Forward Engineering
Backward Engineering
Page : 196
OOAD
OOAD
Chapter 6. OOD
Cla
ss Dia
gra
m
Refi
nem
ent
Behavio
r D
iag
ram
Refi
nem
ent
Object Oriented Design: OOA Models Refinement
Forward and Backward EngineeringForward 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
Page : 197
OOAD
OOAD
Chapter 6. OOD
Cla
ss Dia
gra
m
Refi
nem
ent
Behavio
r D
iag
ram
Refi
nem
ent
Object Oriented Design: OOA Models Refinement
Forward and Backward EngineeringBackward 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
Backward Engineering
Page : 198
OOAD
OOAD
Chapter 6. OOD
Exercise 4: Part IIIRefine 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 : 199
OOAD
OOAD
Chapter 6. OOD
Object Oriented Design
2. Activity Design
1.Statechart Diagram:Definition2.Modeling Statechart Diagram3.Refining Statechart Diagram
Page : 200
OOAD
OOAD
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 : 201
OOAD
OOAD
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 statesActivity is an excution within a state machine
Page : 202
OOAD
OOAD
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 : 203
OOAD
OOAD
Chapter 6. OOD
Object Oriented Design
2. Activity Design
What are needed for Preliminary Statecart DiagramPrelim. Statechart Diagram needs 1. Important or Main States2. Initial State3. Final State (optional)4. Transition and Prelim. Event
Modeling Statechart Diagram
Page : 204
OOAD
OOAD
Chapter 6. OOD
Object Oriented Design
2. Activity Design
Modeling Statechart Diagram : Prelim. Statechart Diagram
IdleAlarm
Police Calling
Locked
10 minutes
intruding cleared
intruding cleared
onintruding detected
off
intruding cleared
10 minutes
Initial State
Final State
Transition
State
Event Intruder Detector Statechart Diagram
Page : 205
OOAD
OOAD
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 transitionsBoth schemes always be used together
Page : 206
OOAD
OOAD
Chapter 6. OOD
Object Oriented Design
2. Activity Design
Refining Statechart Diagram
Two schemes of refinement: Composite StatesComposite States:The State can be decomposed into a
new sub-statechart diagram that contains initial states, final states, internal states, events
Page : 207
OOAD
OOAD
Chapter 6. OOD
Object Oriented Design
2. Activity Design
Refining Statechart Diagram
Two schemes of refinement: ExplanationExplain the statesYou can explain the state by inserting
actions into the stateThe 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 : 208
OOAD
OOAD
Chapter 6. OOD
Object Oriented Design
2. Activity Design
Refining Statechart Diagram : Example
Idle
Alarm
High Frequency Sound
Low Frequency Sound
Make Warning
entry/ Make Warningon Every 1 Minute/ Send E-Mai l to Police Station
Locked
10 minutes
intruding cleared
intruding cleared
on intruding detected
off
High Frequency Sound
Low Frequency Sound
5 seconds5 seconds
interrupted
interrupted
10 minutes
intruding cleared
Composite states
Explanation
Page : 209
OOAD
OOAD
Chapter 6. OOD
Object Oriented Design
2. Activity Design
Refining Statechart Diagram : Example
Idle
on
Alarm
High Frequency Sound
Low Frequency Sound
entry/ count = 0on every 1 second/ count = count+1on [count = 5]/ No Sound
Make Warning
on Undefined/ Make Warningon Every 1 Minute/ Send E-Mai l to Police Station
Locked
intruding cleared
10 minutes
intruding cleared
intruding detected
off
High Frequency Sound
Low Frequency Sound
entry/ count = 0on every 1 second/ count = count+1on [count = 5]/ No Sound
5 seconds
interrupted
intruding cleared
10 minutes
5 secondsinterrupted
Page : 210
OOAD
OOAD
Chapter 6. OOD
Exercise 5Statechart 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 : 211
OOAD
OOAD
Chapter 6. OOD
Object Oriented Design
3. Architecture Design
1.Component Design2.Hardware Platform Design
Page : 212
OOAD
OOAD
Chapter 6. OOD
Object Oriented Design
3. Architecture Design
Component DesignComponent Diagram
Component Diagrams commonly contains• Components• Interfaces• Relationships
• Dependency• Generalization• Association• Realization
Page : 213
OOAD
OOAD
Chapter 6. OOD
Object Oriented Design
3. Architecture Design
Component DesignComponent 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 : 214
OOAD
OOAD
Chapter 6. OOD
Object Oriented Design
3. Architecture Design
Component DesignComponent Design Methodologies1. System Partitioning2. Design Components & Relationships of Subsystems
Page : 215
OOAD
OOAD
Chapter 6. OOD
Object Oriented Design
3. Architecture Design
Component DesignDesign 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 : 216
OOAD
OOAD
Chapter 6. OOD
Object Oriented Design
3. Architecture Design
Component DesignDesign Methodologies: Model Presentation Logic Subsystem
The Components in Presentation Logic Subsystem belong to:User Interface ComponentsInput UnitsDisplay ComponentsWeb Pages / Windows Form
Page : 217
OOAD
OOAD
Chapter 6. OOD
Object Oriented Design
3. Architecture Design
Component DesignDesign Methodologies: Model Presentation Logic Subsystem
Example
Main App
Open File Dialog
Save File Dialog
Print File Form
AppWebPage
DataReconcileForm
show
has
call call
call
Data Input Formhas
Page : 218
OOAD
OOAD
Chapter 6. OOD
Object Oriented Design
3. Architecture Design
Component DesignDesign Methodologies: Model Business Logic Subsystem
The Components in Business Logic Subsystem belong to:ApplicationsApplication SubprogramsLibrariesExecutable Programs
Page : 219
OOAD
OOAD
Chapter 6. OOD
Object Oriented Design
3. Architecture Design
Component DesignDesign Methodologies: Model Business Logic Subsystem
Example TransactionManage.exe
Receoncile.h
include
TXNKeyin.h
Screen.h
include
include
TableRender.h
include
include
Form.htmload
Page : 220
OOAD
OOAD
Chapter 6. OOD
Object Oriented Design
3. Architecture Design
Component DesignDesign Methodologies: Database Logic Subsystem
The Components in Database Logic Subsystem belong to:Data ItemsData InterfacesDatabase Connections
Page : 221
OOAD
OOAD
Chapter 6. OOD
Object Oriented Design
3. Architecture Design
Component DesignDesign Methodologies: Database Logic Subsystem
Example
Transaction Data File
Transaction Data Table
Application Database
contains
DB Connectionhas
contains
DB Login
manage
Page : 222
OOAD
OOAD
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 : 223
OOAD
OOAD
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 : 224
OOAD
OOAD
Chapter 6. OOD
Object Oriented Design
3. Architecture Design
Hardware Platform DesignDeployment Diagram: Example
AppServer<<Cluster>>
Client<<Web>>
internet
DBServer<<ORACLE>>
Deploys Presentation
Deploys Business
Deploys Database
Page : 225
OOAD
OOAD
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 : 226
OOAD
OOAD
Chapter 6. OOD
Object Oriented Design
3. Architecture Design
Hardware Platform DesignDeployment Diagram: Example
AppServer<<Cluster>>
Client<<Web>>
internet
DBServer<<ORACLE>>
Printer
Smart Card
Page : 227
OOAD
OOAD
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 • Design of Structure of Data• Design of Relationships between Data
Page : 228
OOAD
OOAD
Chapter 6. OOD
Object Oriented Design
4. Persistent Data Design
How Comes the Structure of Persistent Data?
• 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
Page : 229
OOAD
OOAD
Chapter 6. OOD
Object Oriented Design
4. Persistent Data Design
How Comes the Relationships between Persistent Data?
• 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.
Page : 230
OOAD
OOAD
Chapter 6. OOD
Object Oriented Design
4. Persistent Data Design
Referential Rule1. 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 : 231
OOAD
OOAD
Chapter 6. OOD
Object Oriented Design
4. Persistent Data Design
Referential Rule1. Primary Key and Foreign KeyExample
Person Id
Person NamePerson Age
Address Id
Address Name
Primary Key
Person Data
Address Data
Attributes
Person Id
Person NamePerson AgePerson Address
Address Id
Address Name
Foreign Key refers to Address DataThe value in Person Address must not outside the possible values of Address Id in Address
Lives in10..n
Page : 232
OOAD
OOAD
Chapter 6. OOD
Object Oriented Design
4. Persistent Data Design
Referential Rule1 to 1 relationshipsChoose primary key of one side of the
relationship as a foreign key of the other side.
Car Id
Car NameCar Model
Engine Id
Engine CC
EngineCar
Car Id
Car NameCar ModelEngine Id
Engine Id
Engine CC
EngineCar
has1..1
0..1
or
Car Id
Car NameCar Model
Engine Id
Engine CCCar Id
EngineCar
has1..1
0..1
Page : 233
OOAD
OOAD
Chapter 6. OOD
Object Oriented Design
4. Persistent Data Design
Referential Rule1 to Many relationshipsPut the primary key on the one side as
the foreign key on the many side
Country Id
Country NameCountry Area
City Id
City Name
CityCountry
Country Id
Country NameCountry Area
City Id
City NameCountry Id
City
Country
has 1..n1..1
Page : 234
OOAD
OOAD
Chapter 6. OOD
Object Oriented Design
4. Persistent Data Design
Referential RuleMany to Many relationshipsCreate the new data to keep the pairs of
primay keys of the data on both sides of relationship.
Subject Id
Subject NameSubject Credit
Student Id
Student Name
StudentSubject
study0..n
0..n
Subject Id
Subject NameSubject Credit
Student Id
Student Name
StudentSubject
Subject IdStudent Id
Subject-Student
0..n
1..1 1..1
0..n
Page : 235
OOAD
OOAD
Chapter 6. OOD
Object Oriented Design
4. Persistent Data Design
Abstraction-Relationship Conversion Rules
• Association Abstraction ConversionApply the referential rule based on the cardinality of association abstraction
Page : 236
OOAD
OOAD
Chapter 6. OOD
Object Oriented Design
4. Persistent Data Design
Abstraction-Relationship Conversion Rules
• Association Abstraction Conversion
Example
Customer
CustomerIdCustomerName
CustomerAddressCustomerPhone
(f rom Actors)
Order
OrderIdOrderTypeOrderDateOrderStatusOrderCurrencyOrderAmount
setStatus()
(from Classes)place
0..*
1
Customer NameCustomer AddressCustomer Phone
Customer Id
Order TypeOrder DateOrder StatusOrder CurrencyOrder AmountCustomer Id
Order Id
place
0..n
1..1
Custom er O rder
Page : 237
OOAD
OOAD
Chapter 6. OOD
Object Oriented Design
4. Persistent Data Design
Abstraction-Relationship Conversion Rules
• Aggregation Abstraction ConversionApply 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.
Page : 238
OOAD
OOAD
Chapter 6. OOD
Object Oriented Design
4. Persistent Data Design
Abstraction-Relationship Conversion Rules
• Aggregation Abstraction ConversionExample
BodyBody IdBody Model
TurnAround()
ArmArm IdArm Model
Hold()
LegLeg IdLeg Model
walk()
HeadHead IdHead Model
process()
RobotRobotIdRobot Model
Work()
1 2..2 2..2 1..11 2..2 2..2 1..1
Robot Model
Robot Id
Robot
Head ModelRobot Id
Head Id
Head
Arm ModelRobot Id
Arm Id
Arm
Leg ModelRobot Id
Leg Id
Leg
Body ModelRobot Id
Body Id
Body
1..1
1..1
2..2
2..2
Page : 239
OOAD
OOAD
Chapter 6. OOD
Object Oriented Design
4. Persistent Data Design
Abstraction-Relationship Conversion Rules
• Generalization Abstraction ConversionThe 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 : 240
OOAD
OOAD
Chapter 6. OOD
Object Oriented Design
4. Persistent Data Design
Abstraction-Relationship Conversion Rules
• Generalization Abstraction ConversionExample
Traveller Cheque Order
TravChequeOrderId
(from Classes)
Foreign Currency Order
Denomination
(from Classes)
Order
OrderIdOrderTypeOrderDateOrderStatusOrderCurrencyOrderAmount
setStatus()
(from Classes)
order TypeOrder DateOrder StatusOrder CurrencyOrder Amount
Order Id
order
TravellerCheque Order Id
Denomination
Foreign Currency Order
Foreign Currency order
0..10..1
1..11..1
Page : 241
OOAD
OOAD
Chapter 6. OOD
CASE STUDY: (30 points)
Foreign Currency Exchange SystemDesign
Page : 242
OOAD
OOAD
Chapter 6. OOD
CASE STUDY:
Foreign Currency Exchange SystemDesign
Assignment
1. From the Foreign Currency Exchange Syatem analysis models, refine class diagram, sequence diagram and statechart diagram.
2. Perform the persistent data design.3. Partition the system and design the component diagram
(based on the requirements)4. Discuss on the appropriate hardware platform (based on the
requirements) Design the deployment diagram.
Page : 243
OOAD
OOAD
Chapter 7 Software Testing
Chapter 7 Software Testing
Page : 244
OOAD
OOAD
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 : 245
OOAD
OOAD
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.
Chapter 7. Software Testing
Page : 246
OOAD
OOAD
Software Testing
Testing Scales
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.
Chapter 7. Software Testing
Page : 247
OOAD
OOAD
Software TestingTesting Procedure
Time
UT UAT IWT U
T UAT IWT
develo
p
develo
p
develo
p
Software release 1st
Software release 2nd
UT UAT IWT
Software release 3rd
Project resources (manpower, budget, management)Discovered Errors FoundUndiscovered Errors Found
Chapter 7. Software Testing
Page : 248
OOAD
OOAD
Software Testing
Test Case Design
For testing purpose, there are 2 kinds of test cases that must be prepared
• 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.
Chapter 7. Software Testing
Page : 249
OOAD
OOAD
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
Chapter 7. Software Testing
Page : 250
OOAD
OOAD
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)
Chapter 7. Software Testing
Page : 251
OOAD
OOAD
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)
Chapter 7. Software Testing