software design and development
DESCRIPTION
Software Design and Development. Kittipong Klomklaum Senior System Analyst / Data Modeler Bank of Thailand [email protected]. COURSE OUTLINE. Chapter 1 Software Development Lifecycles (SDLC). Chapter 1. Software Development Lifecycles (SDLC). Software Development Lifecycles (SDLC). - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/1.jpg)
Software Design
and Development
Software Design
and Development
Kittipong KlomklaumSenior System Analyst / Data ModelerBank of [email protected]
![Page 2: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/2.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/3.jpg)
Page : 3
OOAD
OOAD
Chapter 1 Software Development Lifecycles(SDLC)
Chapter 1 Software Development Lifecycles(SDLC)
![Page 4: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/4.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/5.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/6.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/7.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/8.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/9.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/10.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/11.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/12.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/13.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/14.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/15.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/16.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/17.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/18.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/19.jpg)
Page : 19
OOAD
OOAD
Chapter 2Requirements Acquisition
Chapter 2Requirements Acquisition
![Page 20: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/20.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/21.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/22.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/23.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/24.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/25.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/26.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/27.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/28.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/29.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/30.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/31.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/32.jpg)
Page : 32
OOAD
OOAD
Chapter 3 Object Orientation
Chapter 3 Object Orientation
![Page 33: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/33.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/34.jpg)
Page : 34
OOAD
OOAD
Objects
CarClass
Class เป.น static descriptionObject เป.น instance ของ Class
Class
ค�อต้�นฉบ่$บ่ของ Object ซึ่��งม�ค"ณสิ่มบ่$ต้� (attribute) พฤต้�กรรม (operation) ที่��เหม�อนก$น
OO Principle : Abstraction
Chapter 3. Object Orientation
![Page 35: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/35.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/36.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/37.jpg)
Page : 37
OOAD
OOAD
หล$กการพ�5นฐานของ Object Orientation ประกอบ่ด้�วยู่ 3 ข�อ 1. Abstraction2. Encapsulation3. Modularity
Object OrientationObject OrientationA
bstraction
Encapsulation
Modularity
Chapter 3. Object Orientation
![Page 38: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/38.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/39.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/40.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/41.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/42.jpg)
Page : 42
OOAD
OOAD
Classification Abstractions
Classification Abstraction ค�อกระบ่วนการในการหาและใสิ่� Concept เข�าไปยู่$ง Real-world Objects เพ��อให�เก�ด้ Class
Concepts:ม�ร�างกายู่
สิ่��อสิ่ารด้�วยู่ภาษามน"ษยู่3
สิ่ามารถค�ด้ได้�
Class: คน
สิ่รพงษ3
Mary
หวงเฟยู่หง
Chapter 3. Object Orientation
![Page 43: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/43.jpg)
Page : 43
OOAD
OOAD
Classification Abstractions (cont.)
การเปล��ยู่น Concept จะม�ผู้ลให� Class ม�ค"ณสิ่มบ่$ต้�เปล��ยู่นไป และอาจจะที่�าให�จ�านวนสิ่มาช้�กของ Object ใน Class น$5นเปล��ยู่นไปได้�
Concepts:ม�ร�างกายู่
สิ่��อสิ่ารด้�วยู่ภาษามน"ษยู่3
สิ่ามารถค�ด้ได้�เพศช้ายู่ Class: ผู้��ช้ายู่
สิ่รพงษ3
Mary
หวงเฟยู่หง
Chapter 3. Object Orientation
![Page 44: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/44.jpg)
Page : 44
OOAD
OOAD
Classification Abstractions (cont.)
Class: น$กก�ฬาเบ่สิ่บ่อลช้ายู่
สิ่รพงษ3
Mary
หวงเฟยู่หง
Concepts:Concepts:
ม�ร�างกายู่สิ่��อสิ่ารด้�วยู่ภาษา
มน"ษยู่3สิ่ามารถค�ด้ได้�
เพศช้ายู่เล�นเบ่สิ่บ่อลได้�
Chapter 3. Object Orientation
![Page 45: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/45.jpg)
Page : 45
OOAD
OOAD
Aggregation Abstraction
Aggregation Abstraction คื�อกรุะบวนการุในการุหาคืวามีสิ่ มีพื่ นธ์)ในเชิ�ง “องคื)ปรุะกอบ” รุะหว�าง Class
Class ที่�เป'นองคื)ปรุะกอบเรุยกว�า Component ClassClass ที่�เก�ดจากการุรุวมีก นของ Component Class เรุยกว�า Aggregated Class
Class: คน
ห$ว
แขนขา
ล�าต้$ว Aggregate
Chapter 3. Object Orientation
![Page 46: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/46.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/47.jpg)
Page : 47
OOAD
OOAD
Association AbstractionAssociation Abstraction คื�อกรุะบวนการุในการุหาคืวามีสิ่ มีพื่ นธ์)รุะหว�าง Class ที่�แตักตั�างก น โดยเป'นคืวามีสิ่ มีพื่ นธ์)ที่�ไมี�ใชิ�ในเชิ�งที่�ข,�นตั�อก นเหมี�อนก บใน Aggregation Abstraction
ว�ช้าเร�ยู่นว�ช้าเร�ยู่น อาจารยู่3ผู้��สิ่อนอาจารยู่3ผู้��สิ่อน
น$กเร�ยู่นน$กเร�ยู่น
ห�องเร�ยู่นห�องเร�ยู่น
SectionSection
แบ่�งเป.น
สิ่อน
ม�
ใช้� เสิ่�นต้รงใช้�แสิ่ด้งความสิ่$มพ$นธ์3ระหว�าง Class ล�กศรใช้�ในการบ่อกที่�ศที่างของความสิ่$มพ$นธ์3
Chapter 3. Object Orientation
![Page 48: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/48.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/49.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/50.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/51.jpg)
Page : 51
OOAD
OOAD
Generalization Abstraction: Generalize/ InheritanceGeneralization and Inheritance
InheritGeneralize
ม�ล�อ ม�
เคร��องยู่นต้3
ม�ล�อ ม�
เคร��องยู่นต้3
ตั�ดเที่อรุ)โบ
Super Class
Sub Class
Chapter 3. Object Orientation
![Page 52: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/52.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/53.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/54.jpg)
Page : 54
OOAD
OOAD
EncapsulationEncapsulation หรุ�อการุซ่�อนรุายละเอยดของ Class (เปรุยบได!ก บการุน&าเอาสิ่��งตั�างๆ ที่�ย��งเหย�ง บรุรุจ�ไว!ใน Capsule) ก�อให!เก�ดแนวคื�ด
• Information Hiding การซึ่�อนรายู่ละเอ�ยู่ด้ของ Class และเป>ด้เผู้ยู่
เฉพาะสิ่�วนที่��จ�าเป.น ให�ภายู่นอกได้�ร$บ่ร� �• Polymorphism
การซึ่�อนว�ธ์�การที่�างานที่��แต้กต้�างก$นภายู่ใต้�ร�ปแบ่บ่การเร�ยู่กใช้�
งานแบ่บ่เด้�ยู่วก$น
Chapter 3. Object Orientation
![Page 55: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/55.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/56.jpg)
Page : 56
OOAD
OOAD
Encapsulation: Information Hiding• Information Hiding
Attribute: ความค�ด้Operation: ค�ด้Attributes: Group เล�อด้Operation:
Attribute: สิ่�ผู้�วOperation: บ่อกอายู่"Operation: ว��ง
Class: น$กว��ง
Chapter 3. Object Orientation
![Page 57: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/57.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/58.jpg)
Page : 58
OOAD
OOAD
คื�อการุแบ�งหรุ�อย�อยรุายละเอยดตั�างๆ ที่�รุวมีก นอย-�ให!มีขนาดเล4กลง และ จ ดการุได!ง�ายดายข,�น
Decomposition การุแบ�งย�อย Application เพื่��อให!เก�ด ComponentsComposition กรุะบวนการุในการุที่&าให!เก�ด Components จาก Application หล ก
Modularity
ProgramProgram
FormButtonsUnit
ComponentsLibrary
Chapter 3. Object Orientation
![Page 59: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/59.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/60.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/61.jpg)
Page : 61
OOAD
OOAD
Chapter 4 Introduction to UML
Chapter 4 Introduction to UML
![Page 62: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/62.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/63.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/64.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/65.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/66.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/67.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/68.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/69.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/70.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/71.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/72.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/73.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/74.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/75.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/76.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/77.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/78.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/79.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/80.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/81.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/82.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/83.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/84.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/85.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/86.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/87.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/88.jpg)
Page : 88
OOAD
OOAD
Chapter 5Object Oriented Analysis
Chapter 5Object Oriented Analysis
![Page 89: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/89.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/90.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/91.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/92.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/93.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/94.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/95.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/96.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/97.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/98.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/99.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/100.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/101.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/102.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/103.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/104.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/105.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/106.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/107.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/108.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/109.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/110.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/111.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/112.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/113.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/114.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/115.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/116.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/117.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/118.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/119.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/120.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/121.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/122.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/123.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/124.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/125.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/126.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/127.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/128.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/129.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/130.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/131.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/132.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/133.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/134.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/135.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/136.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/137.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/138.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/139.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/140.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/141.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/142.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/143.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/144.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/145.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/146.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/147.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/148.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/149.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/150.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/151.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/152.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/153.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/154.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/155.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/156.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/157.jpg)
Page : 157
OOAD
OOAD
Chapter 5. OOA
CASE STUDY: (30 points)
Foreign Currency Exchange SystemAnalysis
![Page 158: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/158.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/159.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/160.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/161.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/162.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/163.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/164.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/165.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/166.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/167.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/168.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/169.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/170.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/171.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/172.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/173.jpg)
Page : 173
OOAD
OOAD
Chapter 6Object Oriented Design
Chapter 6Object Oriented Design
![Page 174: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/174.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/175.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/176.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/177.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/178.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/179.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/180.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/181.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/182.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/183.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/184.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/185.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/186.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/187.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/188.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/189.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/190.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/191.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/192.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/193.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/194.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/195.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/196.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/197.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/198.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/199.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/200.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/201.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/202.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/203.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/204.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/205.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/206.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/207.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/208.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/209.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/210.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/211.jpg)
Page : 211
OOAD
OOAD
Chapter 6. OOD
Object Oriented Design
3. Architecture Design
1.Component Design2.Hardware Platform Design
![Page 212: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/212.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/213.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/214.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/215.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/216.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/217.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/218.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/219.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/220.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/221.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/222.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/223.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/224.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/225.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/226.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/227.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/228.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/229.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/230.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/231.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/232.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/233.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/234.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/235.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/236.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/237.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/238.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/239.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/240.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/241.jpg)
Page : 241
OOAD
OOAD
Chapter 6. OOD
CASE STUDY: (30 points)
Foreign Currency Exchange SystemDesign
![Page 242: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/242.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/243.jpg)
Page : 243
OOAD
OOAD
Chapter 7 Software Testing
Chapter 7 Software Testing
![Page 244: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/244.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/245.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/246.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/247.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/248.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/249.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/250.jpg)
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: Software Design and Development](https://reader035.vdocuments.site/reader035/viewer/2022062422/56812faf550346895d9535ab/html5/thumbnails/251.jpg)
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