software design and development

Software Design

and Development

Software Design

and Development

Kittipong KlomklaumSenior System Analyst / Data ModelerBank of [email protected]

Page : 2

OOAD

OOAD COURSE OUTLINE

Page : 4

OOAD

OOAD

Chapter 1Software Development Lifecycles(SDLC)


Page : 4

OOAD

OOAD



Page : 21

OOAD

OOAD

Chapter 2Requirements Acquisition


Page : 21

OOAD

OOAD



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


Page : 174

OOAD

OOAD



Page : 88

OOAD

OOAD

Chapter 5Object Oriented Analysis


Page : 88

OOAD

OOAD



Page : 243

OOAD

OOAD

Chapter 7Software TestingChapter 7Software Testing

Page : 243

OOAD

OOAD

Chapter 7Software TestingChapter 7Software Testing

Page : 3

OOAD

OOAD

Chapter 1 Software Development Lifecycles(SDLC)

Chapter 1 Software Development Lifecycles(SDLC)

Page : 4

OOAD

OOAD

Chapter 1. Software Development Lifecycles (SDLC)

Software Development Lifecycles (SDLC)

SDLC is the methodology for developing software

SDLC is a tight combination of software development phases and process model.

Software Development Phases = Requirement + Analysis + Design + Build

Process Model = The model that represents Directions and Activities of System Development Phases

Page : 5

OOAD

OOAD

1. Phases of Software Development

Requirements Acquisition : To explore and ask what is the set of “needed to solved” problems?

Requirement Analysis: To try to answer the question “What should the software

do to solve the problems?”

Software Design:To try to answer the question “How the software solve the problems?”

Software Build:To try to implement the answer to the question “How the

software solve the problems?”


Page : 6

OOAD

OOAD

2. Software Development Process Models

Waterfall Process Model

Incremental Process Model

Spiral Process Model


DesignDesign

AnalysisAnalysis

BuildBuildRequirement

Acquisition

RequirementAcquisition

DesignDesign

AnalysisAnalysis

BuildBuildRequirement

Acquisition


DesignDesign

AnalysisAnalysis Build

BuildRequirementAcquisition


DesignDesign

AnalysisAnalysis

BuildBuild



RequirementsAnalysis

Design

Build

Version 1

Version 2Version 3

Version 4

Page : 7

OOAD

OOAD

2. Software Development Process Models

Positive and Negative Factors to the Success of Process Model


•Stabilities of user requirements•Association from steakholders•Flexibilities on budgets management•Efficiency of project manangement•Etc.

•Inefficient change management•Budget Problems•Underestimation of work•Lacking of user participation•Etc.

Page : 8

OOAD

OOAD

So called, sequential process model, waterfall process model prefers the end-to-end (one-shot) plan. Therefore user requirements must be(1) Clearly and completely understood.(2) Stable over the development period.

In waterfall process model, after one phase finished, normally, revision is not allowed . To cover the risk, signoff for each phase before working on the next phase is recommended.



DesignDesign

AnalysisAnalysis

BuildBuild



Page : 9

OOAD

OOAD

DesignDesign

AnalysisAnalysis

BuildBuild



Waterfall process model is the oldest and the most classic process model:

Simple / No complicated manangement needed.

Waterfall process model causes many problems:The changes on development process could not easily asserted if the development proceeded.A working version will be produced only when the the development success as a whole.Uncertainty of requirement could not be handled in waterfall process model.



Page : 10

OOAD

OOAD

Time

Risk

Design

Analysis

Build



Time Passed : Risk Increase


Page : 11

OOAD

OOAD

Time

Risk

Design

Analysis

Build



With Positive Factors : Time Passed : Risk Increase more Slowly

Positive Factors


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.



DesignDesignAnalysisAnalysis BuildBuildRequirementAcquisition






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.







Delivery of 1st Increment (20% of Requirement)

Delivery of 2nd Increment (45% of Requirement)

Delivery of Complete Version (Nth increment)



Page : 14

OOAD

OOAD


DesignAnalysis BuildRequirementAcquisition



Time

Risk

Positive Factors

Incremental Process Model :Tend to Success


Page : 15

OOAD

OOAD





Time

Positive Factors

Risk

Incremental Process Model :Tend to Fail !


Page : 16

OOAD

OOAD


•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


Page : 17

OOAD

OOAD





Time

Risk

Positive Factors

Spiral Process Model :Tend to Success


Page : 18

OOAD

OOAD





Time

Positive Factors

Risk

Spiral Process Model :Tend to Fail !


Page : 19

OOAD

OOAD



Page : 20

OOAD

OOAD

Requirements Acquisition

To analyze is to try to answer the question:

WHAT THE SOFTWARE DO?,

based on the requirement of users.

The analysis cannot be accomplished completely without the exact requirements

Before analyze requirements it is very needed to

”ACQUIRE EXACT REQUIREMETNS from USERS”

and model the requirement on users’ perspective

Chapter 2. Requirements Acquisition

Page : 21

OOAD

OOAD


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.


Page : 22

OOAD

OOAD


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.


Page : 23

OOAD

OOAD


2. Run the acquisition process

To run a meeting or interview is to ask context-free questions and to ask meta questions:

Context-free Questions: A set of questions that will be lead to - - basic understanding of the problem- basic understanding of people who need

solutions- basic understanding of nature of desired

solutions

Meta Questions: A set of questions that are asked to- clarify the context-free questions- confirm the understanding on questions and

answers


Page : 24

OOAD

OOAD


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


Page : 25

OOAD

OOAD



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?


Page : 26

OOAD

OOAD



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?


Page : 27

OOAD

OOAD



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?


Page : 28

OOAD

OOAD


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


Page : 29

OOAD

OOAD


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


Page : 30

OOAD

OOAD


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


Page : 31

OOAD

OOAD


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.


Page : 32

OOAD

OOAD

Chapter 3 Object Orientation

Chapter 3 Object Orientation

Page : 33

OOAD

OOAD

Object คื�อ สิ่��งที่�มีตั วตัน และขอบเขตัที่�แน�นอน และมีสิ่��งตั�อไปน�

- Operation: สิ่��งที่�� Object สิ่ามารถกระที่�าได้� (ต้�องม�)- Unique Identity: สิ่��งที่��บ่�งบ่อกถ�งความม�อยู่��จร�งของ Object /ความแต้กต้�างจาก Object อ��นๆ (ต้�องม�)- Attribute: ค"ณสิ่มบ่$ต้�ที่�� Object ต้$วหน��งๆจะม�ได้� (อาจจะม�หร�อไม�ม�ก&ได้�)

Object: เคร��องบ่�นร" �น BOEING 747 จ"ผู้��โด้ยู่สิ่ารได้� 140 คน ที่��บ่�นออกจากด้อนเม�องไปยู่$ง Sydney ในว$นที่�� 15 เมษายู่น 2547 เวลา

1230 น.

Chapter 3. Object Orientation

Page : 34

OOAD

OOAD

Objects

CarClass

Class เป.น static descriptionObject เป.น instance ของ Class

Class

ค�อต้�นฉบ่$บ่ของ Object ซึ่��งม�ค"ณสิ่มบ่$ต้� (attribute) พฤต้�กรรม (operation) ที่��เหม�อนก$น

OO Principle : Abstraction


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


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 ม�ให�เร�ยู่กใช้�งาน


Page : 37

OOAD

OOAD

หล$กการพ�5นฐานของ Object Orientation ประกอบ่ด้�วยู่ 3 ข�อ 1. Abstraction2. Encapsulation3. Modularity

Object OrientationObject OrientationA

bstraction

Encapsulation

Modularity


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)

สิ่รุ�ปคื�อโครงร�างที่��ม�เฉพาะล$กษณะพ�เศษของต้$วเอง ที่��ที่�าให�แต้ก

ต้�างจากสิ่��งอ��นๆ


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น


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


Page : 41

OOAD

OOAD

Abstractions

Abstractions คื�อกรุะบวนการุในการุหาและใสิ่� Concept เข!าไปย ง Real-world Objects ที่�สิ่นใจเพื่��อก�อให!เก�ด Class

Abstractions สิ่ามีารุถจ&าแนกออกได!เป'น 4 กรุะบวนการุ คื�อ•Classification Abstraction•Aggregation Abstraction•Association Abstraction•Generalization Abstraction


Page : 42

OOAD

OOAD

Classification Abstractions

Classification Abstraction ค�อกระบ่วนการในการหาและใสิ่� Concept เข�าไปยู่$ง Real-world Objects เพ��อให�เก�ด้ Class

Concepts:ม�ร�างกายู่

สิ่��อสิ่ารด้�วยู่ภาษามน"ษยู่3

สิ่ามารถค�ด้ได้�

Class: คน

สิ่รพงษ3

Mary

หวงเฟยู่หง


Page : 43

OOAD

OOAD

Classification Abstractions (cont.)

การเปล��ยู่น Concept จะม�ผู้ลให� Class ม�ค"ณสิ่มบ่$ต้�เปล��ยู่นไป และอาจจะที่�าให�จ�านวนสิ่มาช้�กของ Object ใน Class น$5นเปล��ยู่นไปได้�

Concepts:ม�ร�างกายู่

สิ่��อสิ่ารด้�วยู่ภาษามน"ษยู่3

สิ่ามารถค�ด้ได้�เพศช้ายู่ Class: ผู้��ช้ายู่


Mary



Page : 44

OOAD

OOAD

Classification Abstractions (cont.)

Class: น$กก�ฬาเบ่สิ่บ่อลช้ายู่


Mary


Concepts:Concepts:

ม�ร�างกายู่สิ่��อสิ่ารด้�วยู่ภาษา

มน"ษยู่3สิ่ามารถค�ด้ได้�

เพศช้ายู่เล�นเบ่สิ่บ่อลได้�


Page : 45

OOAD

OOAD

Aggregation Abstraction

Aggregation Abstraction คื�อกรุะบวนการุในการุหาคืวามีสิ่ มีพื่ นธ์)ในเชิ�ง “องคื)ปรุะกอบ” รุะหว�าง Class

Class ที่�เป'นองคื)ปรุะกอบเรุยกว�า Component ClassClass ที่�เก�ดจากการุรุวมีก นของ Component Class เรุยกว�า Aggregated Class

Class: คน

ห$ว

แขนขา

ล�าต้$ว Aggregate


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ผู้ม


Page : 47

OOAD

OOAD

Association AbstractionAssociation Abstraction คื�อกรุะบวนการุในการุหาคืวามีสิ่ มีพื่ นธ์)รุะหว�าง Class ที่�แตักตั�างก น โดยเป'นคืวามีสิ่ มีพื่ นธ์)ที่�ไมี�ใชิ�ในเชิ�งที่�ข,�นตั�อก นเหมี�อนก บใน Aggregation Abstraction

ว�ช้าเร�ยู่นว�ช้าเร�ยู่น อาจารยู่3ผู้��สิ่อนอาจารยู่3ผู้��สิ่อน

น$กเร�ยู่นน$กเร�ยู่น

ห�องเร�ยู่นห�องเร�ยู่น

SectionSection

แบ่�งเป.น

สิ่อน

ม�

ใช้� เสิ่�นต้รงใช้�แสิ่ด้งความสิ่$มพ$นธ์3ระหว�าง Class ล�กศรใช้�ในการบ่อกที่�ศที่างของความสิ่$มพ$นธ์3


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)


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เร�ยู่น


Page : 50

OOAD

OOAD

Generalization AbstractionGeneralization Abstraction คื�อกรุะบวนการุในการุหาคืวามีสิ่ มีพื่ นธ์)รุะหว�าง Class ในล กษณะที่�มีการุเพื่��มีเตั�มี Attributes หรุ�อ Operations ให!ก บ Class เด�มี เพื่��อให!เก�ด Class ใหมี�ที่มีคื�ณล กษณะพื่�เศษแตักตั�างไปจากเด�มี โดย Class ใหมี�ได!รุ บถ�ายที่อด (inherit ) คื�ณล กษณะบางอย�างจาก Class เด�มีด!วยGeneralization Abstraction

สิ่ามีารุถจ&าก ดคืวามีได!ใน 2 คืวามีหมีายคื�อ-Generalize-Specialize


Page : 51

OOAD

OOAD

Generalization Abstraction: Generalize/ InheritanceGeneralization and Inheritance

InheritGeneralize

ม�ล�อ ม�

เคร��องยู่นต้3

ม�ล�อ ม�

เคร��องยู่นต้3

ตั�ดเที่อรุ)โบ

Super Class

Sub Class


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


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


Page : 54

OOAD

OOAD

EncapsulationEncapsulation หรุ�อการุซ่�อนรุายละเอยดของ Class (เปรุยบได!ก บการุน&าเอาสิ่��งตั�างๆ ที่�ย��งเหย�ง บรุรุจ�ไว!ใน Capsule) ก�อให!เก�ดแนวคื�ด

• Information Hiding การซึ่�อนรายู่ละเอ�ยู่ด้ของ Class และเป>ด้เผู้ยู่

เฉพาะสิ่�วนที่��จ�าเป.น ให�ภายู่นอกได้�ร$บ่ร� �• Polymorphism

การซึ่�อนว�ธ์�การที่�างานที่��แต้กต้�างก$นภายู่ใต้�ร�ปแบ่บ่การเร�ยู่กใช้�

งานแบ่บ่เด้�ยู่วก$น


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 ที่��สิ่ามารถเห&นได้�ที่$นที่�จากภายู่นอก


Page : 56

OOAD

OOAD

Encapsulation: Information Hiding• Information Hiding

Attribute: ความค�ด้Operation: ค�ด้Attributes: Group เล�อด้Operation:

Attribute: สิ่�ผู้�วOperation: บ่อกอายู่"Operation: ว��ง

Class: น$กว��ง


Page : 57

OOAD

OOAD

Polymorphism (Poly + Morph (body))

ค�อการซึ่�อนว�ธ์�การที่�างานที่��แต้กต้�างก$นอยู่��ภายู่ใต้�ร�ปแบ่บ่การต้�ด้ต้�อ (interface) แบ่บ่เด้�ยู่วก$น เป.นการแยู่ก Implementation ออกจาก declaration

Encapsulation: Polymorphism

กด้ Remote Control เพ��อเพ��ม Volume เหม�อนก$น แต้�การเพ��ม Volume ของว�ที่ยู่"ที่�างานต้�างจากการเพ��ม Volume ของที่�ว�

ในที่าง ProgrammingPolymorphism จะแที่นด้�วยู่ค�าว�า Overloading


Page : 58

OOAD

OOAD

คื�อการุแบ�งหรุ�อย�อยรุายละเอยดตั�างๆ ที่�รุวมีก นอย-�ให!มีขนาดเล4กลง และ จ ดการุได!ง�ายดายข,�น

Decomposition การุแบ�งย�อย Application เพื่��อให!เก�ด ComponentsComposition กรุะบวนการุในการุที่&าให!เก�ด Components จาก Application หล ก

Modularity

ProgramProgram

FormButtonsUnit

ComponentsLibrary


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)


Page : 60

OOAD

OOAD

Object-Oriented Software Engineering (OOSE)

Not InComputer

InComputer

Abstract Level

Real W orld Level


Programming

Analysis Design


OOSE ConceptualVisualization

Page : 61

OOAD

OOAD

Chapter 4 Introduction to UML

Chapter 4 Introduction to UML

Page : 62

OOAD

OOAD

UML and Principles of Modeling

Chapter 4. Introduction to UML

1. The choice of what models to create has a profound influence on how a problem is attacked and how a solution is shaped.

2. Every model may be expressed at different levels of precision.

3. The best models are connected to reality.4. No single model is sufficient. Every nontrival system is

best approached through a small set of nearly independent models.

Unified Modeling Language (UML) is a language for modeling purposes. UML has to be used based on the principles of modeling:

Page : 63

OOAD

OOAD

UML Overview


Things in UMLRelationships in UMLDiagrams in UMLRules of UML

This chapter gives intrduction on:

Page : 64

OOAD

OOAD


Things in UML

There are 4 kinds of things in the UML:

1. Structural Things2. Behavioral Things3. Grouping Things4. Annotational Things

These things are the basic object-oriented building blocks of the UML.They are used to write “well-formed model”.

Page : 65

OOAD

OOAD


Things in UML

1. Structural Things

Structural things are the nouns of UML models. These are the mostly static parts of a model

Structural things represent either conceptual or physical elements.

7 kinds of structural things are

1. Classes2. Interfaces3. Use Cases4. Components5. Nodes

Page : 66

OOAD

OOAD

ApplianceOperation StatusVoltageNameModel

turn on()turn off()

ApplianceOperation StatusVoltageNameModel

turn on()turn off()


Things in UML : Structural Things

1.1 Class

A class is a description of a set of objets that share the same attributes, operations, relationships and semantics. A class implements one or more interfaces.

Private ElementProtected Element Public Element

Page : 67

OOAD

OOAD



1.2 Interface

Interface is a collection of operations that specify a service of a class or components. An interface describes the externally visible behavors of that element.

An interface defines a set of operation specifications (called signatures) but never a set of operation implementation.

An interface rarely stands alon. Rather, it is typically attached to the class or componnent that realizes the interface.

IWorking

Page : 68

OOAD

OOAD



1.3 Use Case

A use case is a description of set of sequence of actions that a system performs that yields an observable result of value to a particular actior.

Place Order

Page : 69

OOAD

OOAD



1.4 Component

A component is a physical and relaceable part of a system that conforms to and provides the realization of a set of interfaces.

In a system there are many kinds of components, like COM+ or Java Beans, custom developed components, such as source code files.

A component typically represents the physical packaging of otherwise logical elements, such as classes, interfaces.

orderform.java

Page : 70

OOAD

OOAD



1.5 Node

A node is a physical element that exists at run time and represents a computational resource, generally having at least some memory and, often, procession capability. A set of components may reside on a node and may also migrate from node to node.

Server

Page : 71

OOAD

OOAD


Things in UML

2. Behavioral Things

Behavioral things are the dynamic parts of UML models. These are verbs of a model

Behavioral things represent behavior over time ans space.

There are 2 primary kinds of behavioral things.

1. Messages2. States

Page : 72

OOAD

OOAD


Things in UML : Behavioral Things

2.1 Message

An interaction is behavior that comprises a set of message exchanged among a set of objects within a particular context to accomplish a specific purpose.

The behavior of a society of objects or of an individual operation may be specified with an interaction.

display

Page : 73

OOAD

OOAD


Things in UML : Behavioral Things

2.2 State

State is a behavior that specifies the sequences of actions that an object goes through during its lifetime in response to events together with its response to those events.

waiting

Page : 74

OOAD

OOAD


Things in UML

3. Grouping Things

Grouping things are the organizational parts of UML models. These are the boxes into which a model can be decomposed. In all, there is one primary kinds of grouping, called “packages”

Page : 75

OOAD

OOAD


Things in UML : Groping Things

3.1 Package

A package is a general-purpose mechanisms for organizing elements into groups. Structural things, behavior things, and even other grouping thing mays be placed in a package.

Unlike components, a package is purely conceptual (existing only at development time, not runtime as components) .

Business Rules

Page : 76

OOAD

OOAD


4. Annotational Things

Annotational things are the explanatory parts of UML models. These are the comments you may describe or remark about any element in a model

This is on primary kind of annotational thing called a “note”

Things in UML : Annotational Things

Page : 77

OOAD

OOAD


Things in UML : Annotational Things

4.1 Note

We can use notes to adorn diagrams with constraints or comments that are best expressed in informal or formal text.

return copy of self

Page : 78

OOAD

OOAD


Relationships in UML

There are 4 kinds of relationships in the UML:

1. Dependency2. Association3. Generalization4. Realization

These relationships are the basic relational building blocks of the UML. They are used to write well-formed models.

Page : 79

OOAD

OOAD


Relationships in UML :

1. Dependency

Dependency is a semantic relationship between two things in which a change to one thing may affect the semantics of the other thing.Hardware

Operating System

Page : 80

OOAD

OOAD



2. AssociationAn association is a structural relationship that describe a set of links, a link being a connection among objects.

Aggregation is a special kind of association, representing a structural relationship between a whole and its parts.

Form

Application

1..*1..*

Employer Employee1..*1 employs

+work+hire

1..*1

AssociationAggregation

Page : 81

OOAD

OOAD



3. Generalization

Generalization is a specialization/generalization relationship in which objects of the specialized element (the child) are substitutable for objects of the generalized element (the parent)

In this way the child shares the structure and the behavior of the parent.

Notification

Message Box

Error Message Box

Page : 82

OOAD

OOAD



3. Realization

Realization is a semantic relationship between classifiers, wherein one classifier specifies a contract that another classifier guarantees to carry out.

You well see realization between interfaces and classes that realize them.

Car Actions

Car

Page : 83

OOAD

OOAD


Diagrams in UML

A diagram is the graphical representation of a set of a set of elements, most often rendered as a connected graph of thing and relationships. Diagrams are created to visualize a system from different respective, so a diagram is a projection into a system.

There are many diagrams in UML. The same element may appear in all diagrams, or a few diagrams. The UML includes nine diagrams

1. Class Diagram ***2. Object Diagram 3. Use Case Diagram ***4. Sequence Diagram ***5. Collaboration Diagram ***6. Statechart Diagram ***7. Activity Diagram8. Component Diagram ***9. Deployment Diagram ***

Page : 84

OOAD

OOAD


UML Diagrams Categories

The UML Diagram can be categorized in 2 schemes

Scheme 1: Characteristics of UML diagramsStatic DiagramsDynamic Diagrams

Scheme 2: Usages of UML diagramsConceptual DiagramsArchitectural Diagrams

Scheme 2 is the scheme applied in this course

Page : 85

OOAD

OOAD


UML Conceptual Diagrams

UML Conceptual diagrams are used to represent the static and dynamic view of requirements, of elements that play their roles to perform the functions of the system and of the system’s interactions and activities.

The UML Structural Models are classified as

• Models for Requirement Modeling - Use Case Diagram• Models for Static Modeling - Class Diagram• Models for Dynamic Modeling - Sequence Diagram,Collaboration

Diagram• Models for Activity Modeling - Activity Diagram, Statchart Diagram

In OOSE, conceptual diagrams are created in OOA and are refined in OOD.

Page : 86

OOAD

OOAD


UML Architectural Diagrams

UML Architectural diagrams are used to represent the structure and architecture of software, hardware,

The UML Conceptual Models are classified as

• Models for Software Components - Component Diagram• Models for Hardware Platform - Deployment Diagram

In OOSE, architectural diagrams are created in OOD.

Page : 87

OOAD

OOAD


Rules of UML

The UML’s building blocks cannot simply be thrown together in a random fashion. Like any language, the UML has a number of rules that specify what a well-formed model should look like. A well-formed model is one that is semantically self-consistent and in harmony with all its related models.

The well-formed UML models must contains

• Names what can call things, relationships, and diagrams• Scope the context that gives specific meaning to a name• Visibility how those names can be seen and used by others• Integrity how things properly and consistently relate to

one another• Execution what it means to run or simulate a dynamic

model

Page : 88

OOAD

OOAD



Page : 89

OOAD

OOAD

Chapter 5. OOA

Object Oriented Analysis (OOA)The goal of analysis is to build an analysis model based on users’ experts and enterprise requirements.

Deliverables from OOA

OOA delivers Requirement Models, including

• Problem Statements and Problem Domain

• Use Cases and Use Case Diagram

• Static Analysis Model

• Dynamic Analysis Model

Page : 90

OOAD

OOAD

Chapter 5. OOA

Object Oriented Analysis (OOA)

The Analysis models should include

The Use Case Models• context of the system • requirements of the system

the Static Models• classes needed to provide the required application behavior • relationships among the classes• the knowledge each class must have of other classes• the services each class must provide.

And Dynamic Models•proper description of interacations • how external events activate object’s action

Page : 91

OOAD

OOAD

Chapter 5. OOA


OOA covers the following activities in most methodologies, although the approaches, sequences and techniques used to carry out these activities may differs:

• Understanding the Problem• Finding the Objects• Classify the Objects into Classes• Establishing Class Relationships• Defining Class Properties and Behaviors• Modeling Objects Interactions• Study Object State Changes

Page : 92

OOAD

OOAD

Chapter 5. OOA


How can Models be applied in OOA

• Understanding the Problem • Finding the Objects• Classify the Objects into Classes• Establishing Class Relationships• Defining Class Properties and Behaviors

• Modeling Objects Interactions

• Study Object State Changes

USE CASE DIAGRAM

CLASS DIAGRAM

INTERACTION DIAGRAM

STATECHART DIAGRAM

Page : 93

OOAD

OOAD

Chapter 5. OOA


How can Models be applied in OOA

1. Model Requirements with Use Case Diagram2. Medel Static Element with Class Diagram3. Behavior Modeling

• Sequence Diagram• State Chart Diatgram

Page : 94

OOAD

OOAD

Chapter 5. OOA

1. Use Case Modeling

1. Use Cases 2. Actors3. Use Cases and Flow of Events4. Use Cases and Scenarios5. Use Case Diagram Organization Techniques

System Context ModelingSystem Requirements Modeling

Page : 95

OOAD

OOAD

Chapter 5. OOA

1.1 Use Cases

Describes a set of sequences, in which each sequence represents the interaction of the things outside the system (its actors) with the system itself.

A use case represents a functional requirements of a system as a whole.

Process Loan

Loan Officer

Actor

Use Case

Page : 96

OOAD

OOAD

Chapter 5. OOA

1.1 Use Cases

Not only, the functions of a system, use cases can tell the boundary of a system.

Describing use cases helps us to identify • the services the system must provide.• who use or relate to use case.

Process Loan

Loan Officer

Actor

Use Case

Page : 97

OOAD

OOAD

Chapter 5. OOA

1.1 Use Cases

Good use case must be

• Able to collect the enough information and requirements

• Flexible: not too committing too early to a specific solutions

Process Loan

Loan Officer

Actor

Use Case

Page : 98

OOAD

OOAD

Chapter 5. OOA

1.1 Use Cases

Limitations of Use Cases

• Use case not describes the internal interaction between the internal obects

• Conflicts among use cases cannot be easily detected

Process Loan

Loan Officer

Actor

Use Case

Page : 99

OOAD

OOAD

Chapter 5. OOA

1.2 Actors

Represents set of roles that outside users of use cases play when interacting with these use cases.

Typically, an actor represents a role that a human, a hardware device, or even another system plays with a system.

Process Loan

Loan Officer

Actor

Use Case

Page : 100

OOAD

OOAD

Chapter 5. OOA

1.2 Actors

Criterias for Finding Actors

If you work for a bank, you might be a loan Officer. If you do your personal banking there, as well, you will also play the role of customer.

An instance of an actor, therefore, represents an individual interacting with the system in a specific way. Although, you will use actors in your model, actors are not actually part of the system. They live outside the system.

To find actors is to help determining what is inside or outside the system.

Page : 101

OOAD

OOAD

Chapter 5. OOA

1.2 Actors

Loan Officer

Senior Loan Officer

Generalization Specialization of Actors

We can inherit properties of one actor

A specialized actor may play different roles compared to based actor.

Page : 102

OOAD

OOAD

Chapter 5. OOA

1.3 Use Case and Flow of Events

Use Case describes WHAT a system does (outside view) But Use Case does not specify HOW it does (Inside view)

Anyway, you can specify the behavior or “FLOW OF EVENTS” of use case by describing a flow of events in text note. This text note is for outsider to make clearly understand of system functions.

In the note for flow of events the parts that must not be forgotten are • How it start and end,• when the use case interact with actors,• what objects are exchanged,• basic flow and alternative flow of the behavior

Page : 103

OOAD

OOAD

Chapter 5. OOA


EXAMPLE: in the context of of ATM system, you might describe the use case “Validate User” in the following way:Main flow of events: The use case starts when the system prompts the customer for a PIN number. The customer can now enter a PIN number via a keypad. The customer commits the entry by pressing the Enter button . The system then checks this PIN number to see if it is valid. If the PIN number is valid, the system acknowledges the entry, thus ending the use case.

Page : 104

OOAD

OOAD

Chapter 5. OOA


EXAMPLE: in the context of of ATM system, you might describe the use case “Validate User” in the following way:

Exceptional flow of events: The customer can cancel a transaction at any time by pressing the Cancel button, thus restarting the use case. No changes are made to the customer’s account.

Exceptional flow of events: The customer can cancel clear a PIN number before committing it and reenter a new PIN

number

Page : 105

OOAD

OOAD

Chapter 5. OOA

1.4 Use Case and Scenarios

One use case actually describes a set of sequences in which each sequence in the set represents one possible flow of event through all these varitions. Each sequence is called a “SCENARIO”

A scenario is a specific sequence of actions that illstrates behavior.

Scenarios are to use case as instaces are to class, basically,

SCENARIO is instance of a use case.Class

ObjectObject ObjectObjectObjectObject

Use Case

ScenarioScenarioScenarioScenario

ScenarioScenario

Page : 106

OOAD

OOAD

Chapter 5. OOA

1.5 Use Case Diagram Organization Techniques

Use Cases can be organized by specifying generalization, include and extend relationships among use cases.

Relationships: the things that are applied among use cases in order to:

• Inherit behavior (generalization)• factor common behavior (includes)• factor variants (extends)

Notations <<include>>

<<extends>>

Include

Extend

Generalization

Page : 107

OOAD

OOAD

Chapter 5. OOA

Example of Generalization, Include and Extend in Use Cases

Track Order

Place Rush Order

Check Password

Place Order

<<extend>>

Validate User

<<include>>

<<include>>


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


Page : 109

OOAD

OOAD

Chapter 5. OOA

To construct Use Case Diagram is to:


Model the Context of a SystemModel the Requirements of the System

System Context

Requirement ModelForward engineer

refine

Reverse engineer

Page : 110

OOAD

OOAD

Chapter 5. OOA

The context of a system can be modeled with a use case diagram.

To model the context of a system,• Identify the actors that surround the system by considering

o which groups require help from the system to perform their task,o Which groupss are needed to execute the system’s funcitons,o Which groups interact with external hardware and other software system, o Which groups perform functions for administration/management

• Organize actors that are similar to one another in a generalization/specialize hierarchy

• Where it aids understandability, provide a stereotype for each such actor.

• Populate a use case diagram with these actor to the system’s use caseWho should responsible for constructing system context modelAnswer. “Users & Stakeholders”


Modeling the Context of a System

Page : 111

OOAD

OOAD

Chapter 5. OOA

Example: Credit Card Validation System : System ContextActors

For credit card validaton, • Customers which can be categorize into 2 kinds (Individual and Corporate)• Customer perform card transaction to Reatil Institution who process customer bill• Credit card account is managed by Sponsoring Financial Institution (for example, Clearing House)

Customer Retail Institution

Sponsoring FIIndiv idual Customer

Corporate Customer

1.5 Use Case Diagram Organization TechniquesModeling the Context of a System

Page : 112

OOAD

OOAD

Chapter 5. OOA

Example: Credit Card Validation System : System ContextUse Cases

For credit card validaton, • Customers which can be categorize into 2 kinds (Individual and Corporate)• Customer perform card transaction to Reatil Institution who process customer bill• Credit card account is managed by Sponsoring Financial Institution (for example, Clearing House)

Perf orm Card Transaction

Manage Customer Account

Process Customer Bill


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


Customer

Retail Institution

Sponsoring FI



Page : 114

OOAD

OOAD

Chapter 5. OOA

Requirements can be expressed in various forms, System’s function requirements can also be expressed by use case diagram.

To model the requirements of a system,• Establish the context of the system started by identify the actors that

surround it.• For each actor, consider the behavior that each requires the system to

provide• Name these behavior as use cases.• Factor common behavior into new use cases that are used or included

by others.• Factor variant behavior into new use cases tht extend more main line

flows.• Model these use cases, actors and relationships in use case diagram• Fill the notes if required.

Who should responsible for constructing Requirements ModelAns. “System Analysts + Users”

1.5 Use Case Diagram Organization TechniquesModeling the Requirements of a System

Page : 115

OOAD

OOAD

Chapter 5. OOA

Example: Credit Card Validation System : System Context

Step 1: Focus on actors’ requirements

Expand the system context model from its actors

we found that:

Detect Card Fraud is a behavior that is important for both retail institution and the sponsoring FI.

Similarly, Report on Account Status is another behavior required of the system by various institutions in its context.


Page : 116

OOAD

OOAD

Chapter 5. OOA

Example: Credit Card Validation System : Requirements ModelRequirements Use Case Model Step 1

Indiv idual Customer

Corporate Customer



Customer

Detect Card Fraud

Retail Institution

Report on Account

Sponsoring FI



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


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


Customer

Detect Card Fraud

Retail Institution

Sponsoring FI


Verif y Card Holder

Ad hoc ReportReport on Account

<<extend>>

Perf orm Online Transaction


<<include>>


Page : 119

OOAD

OOAD

Chapter 5. OOA

2. Class Modeling

To build Class Diagram is to

• Find out Classes• Specify Attributes and Methods of Classes• Build System Vocabulary• Build Class Diagram by Applying Abstractions • Improve the Class Diagram Created.

Recommendation: These methodologies must be done based on spiral process model

1 2

3

4 5

Page : 120

OOAD

OOAD

Chapter 5. OOA

2.1 Find Out Classes

Class Modeling

1. Actor could be a class in class diagram2. Behavior from each use case must be provided by class

Find Basic Classes from Use Cases:

1. List set of classes of each use case by describe the use case (may start from scenarios or flows of events of each use case)

2. Some nouns in the description could become either class or attribute of class.

3. Put the union product of nouns found in each use case into a class pool.

4. Note that, one class can reside in multiple use cases5. Eliminate the class that is not in a scope (or be the scope itself)

How to:

Page : 121

OOAD

OOAD

Chapter 5. OOA

Librarian

Customer

Example : The Library

Borrow Books

Return Books

Borrow Books starts when customer shows that he/she want to take the books outside the library. The member card of customer is verified. If verified and if the number of borrowed items is not excess the individual limit then the books can be borrowed. The due date for each books are set.

Customer shows the borrowed books to the librarian. The librarian checks the due date of each book. If there are books that excess the due date. Customer has to pay punishment charge. Each books has its own punishment charge. The charge is calculated in daily basis.

Class Modeling

Page : 122

OOAD

OOAD

Chapter 5. OOA

Directions:

Try to think of the feasible functions of library system that can serve these requirements:

• Books borrowing • Books returning• Maintain Customer Information• Expiration/ Extension of Member Card• Books inventory

Start from existing basic use case diagram, refine it, to produce the class diagram explaining the functions above.

Exercise 1: Refine Use Case Diagram

Page : 123

OOAD

OOAD

Chapter 5. OOA



Borrow Books

Return Books

Librarian

Customer



Page : 124

OOAD

OOAD

Chapter 5. OOA


Possible to be classes:

CustomerBookLibrarianLibraryMember CardBorrowed Items

Possible to be Attributes

Due Date


Borrow Books

Librarian

Customer


Find Class

Page : 125

OOAD

OOAD

Chapter 5. OOA



Possible to be classes:

CustomerBookLibrarianBorrowed Items


Due DatePunishment Charge

Librarian

CustomerReturn Books


Find Class

Page : 126

OOAD

OOAD

Chapter 5. OOA



CustomerBookLibrarianBorrowed Items



Due Date



Construct Class PoolClass Pool

Page : 127

OOAD

OOAD

Chapter 5. OOA





CustomerBookMember CardBorrowed Items


Eliminate out-of-scope classes from Class Pool

The system itself

Unrequired

Page : 128

OOAD

OOAD

Chapter 5. OOA

2.2 Specify Attributes and Methods

Find Basic Methods

1. From the use case description. Method of classes are implicitly shows in verbs

2. Normally, in the sense of language the sentence is [ subject verb object ] . We can assume that verb is the method of object (in the sense of language) , if such object noun is selected as a class.

3. Some method found may be in or out of scope. Select just required methods.

4. Note that, methods found in this phase is usually “Public” methods.

5. Think of class responsibilities and service that classes should provide and fill it.

Page : 129

OOAD

OOAD

Chapter 5. OOA


Borrow Books

Librarian

Customer


Find Methods


Verbs Found:Take the BookBorrow the BookVerify Member CardSet Due Date for Each Book

SynonymBook has method borrow

Member Card has method verify

Book has method set due date

Page : 130

OOAD

OOAD

Chapter 5. OOA


Librarian



Find Methods


Verbs Found:Shows the BookCheck the Due Date of BookPay Punishment Charge of A Book

Book has method show

Book has method check due date Book has method pay

punishment charge

Not a required method

Page : 131

OOAD

OOAD

Chapter 5. OOA


Find Methods : Summary


Book has method check due dateBook has method pay punishment charge

Book has method borrow



Page : 132

OOAD

OOAD

Chapter 5. OOA


Find Basic Attributes

1. Primarily, from the use case description the noun or adjective that explains or belongs to the class could be an attributes of that class.

2. Refer to the methods, normally there should be some attributes of class that is affected as result of a methods.

Page : 133

OOAD

OOAD

Chapter 5. OOA


Borrow Books

Librarian

Customer


Number of borrowed items is of CustomerIndividial Limit explains CustomerDue Date explains Book


Find Attribtes


Page : 134

OOAD

OOAD

Chapter 5. OOA



Due Date explains BookPunishment Charge belongs to BookExcess the Due Date Status explains Book

Librarian



Find Attributes


Page : 135

OOAD

OOAD

Chapter 5. OOA


Find Attributes:

Book has method check due dateBook has method pay punishment charge

Book has method borrow



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


Page : 136

OOAD

OOAD

Chapter 5. OOA


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


Page : 137

OOAD

OOAD

Chapter 5. OOA

System Vocabulary

System vocabulary is

• visualization of class with its fundamental attributes and/or methods,

• With preliminary levels of information hiding (private, protected, public), for primary modeling, all attributes should be private and all methods should be public,

• No relationships,• Notes can be added for explanatory purposes.

2.3 Build System Vocabulary

Page : 138

OOAD

OOAD

Chapter 5. OOA

Example : The Library : System Vocabulary

CustomerNumber of Borrowed ItemsIndividual Limits

Member CardVerified Status

Verify()BookDue DatePunishment ChargeBorrow StatusExcess Due Date Status

Set Due Date()Check Due Date()Pay Punishment Charge()Borrow()

Borrow Items

2.3 Build System Vocabulary

Page : 139

OOAD

OOAD

Chapter 5. OOA

2.4 Build Class Diagram

How To:

Start from the System Vocabulary, Apply the abstractions to define new classes (if needed) and identify the relationships among classes.

The relationships among classes could be “aggregations” or “associations” or “genralization”.

Iterations are needed in this process model.

CustomerNumber of Borrowed ItemsIndividual Limits

Member CardVerified Status

Verify()BookDue DatePunishment ChargeBorrow StatusExcess Due Date Status

Set Due Date()Check Due Date()Pay Punishment Charge()Borrow()

Borrow Items

Book

Book IdBook NameBook TypePunishment ChargeBorrowed Status

Set Punishment Charge()

(from Logical View)Member Card

Verified StatusMember Card IdExpire Date

Verify()Extend()

(f rom Logical View)

Customer

Number of Borrowed ItemsIndividual Limit

IdCustomer Name

Customer Address

(f rom Business Use-Case Model)

0..*

0..*

0..*

0..* 11 11

Book Borrowing

Due Date

Book TransactionBook IdCustomer IdTransaction TypeTransaction Date

Book ReturnSum Charge

Calculate Charge()

Page : 140

OOAD

OOAD

Chapter 5. OOA

2.4 Build Class Diagram

Book





Verify()Extend()


Customer


IdCustomer Name

Customer Address


0..*

0..*

0..*

0..* 11 11

Book Borrowing

Due Date



Calculate Charge()

Example : The Library: Class Diagram (built from system vocab.)

Page : 141

OOAD

OOAD

Chapter 5. OOA

Exercise 2: Build the Class Diagram

Directions:

Based on the use case diagram (from Exercise 1) and the System Vocab. Use abstractions to produce the class diagram of library system.

Page : 142

OOAD

OOAD

Chapter 5. OOA

2.4 Build Class DiagramClass Diagram of Library System

Book





Verify()Extend()


Customer


IdCustomer Name

Customer Address


0..*

0..*

0..*

0..* 11 11

Book Borrowing

Due Date



Calculate Charge()

Page : 143

OOAD

OOAD

Chapter 5. OOA

2.4 Build Class DiagramClass Diagram of Library System

Member Card


Verify()Extend()

(from Logical View)

Customer


IdCustomer Name

Customer Address

(from Business Use-Case Model)

11 11

Book Borrowing

Due Date

Book Transaction

Book IdCustomer IdTransaction TypeTransaction Date


Calculate Charge()

Book ShelfShelf IdShelf NameShelf Description

Book



(from Logical View)

0..*

0..*

0..*

0..*

Shelf SlotSlot IdSlot Location

1..*

0..1

0..*is on

0..*

0..1

1..*

Page : 144

OOAD

OOAD

Chapter 5. OOA

2.4 Build Class DiagramClass Diagram of Library System – more refiend

Member Card

Verif ied StatusMember Card IdExpire Date

Verif y ()Extend()

(from Logical View)

Customer

Number of Borrowed ItemsIndiv idual Limit

IdCustomer Name

Customer Address

(from Business Use-Case Model)

11 11

Book Borrowing

Due Date

Book Transaction

Book IdCustomer IdTransaction Ty peTransaction Date

Book Return

Sum Charge

Calculate Charge()

Book Shelf

Shelf IdShelf NameShelf Description

Shelf Slot

Slot IdSlot Location

1..*1..*

Book Inventory

Book Category IdBook Category NameOutstanding

Book Income()Book OutGo()

Book

Book IdBook NameBook Ty pePunishment ChargeBorrowed Status



0..*

0..*

0..*

0..*

0..1

0..*

0..1

0..*is on0..*

1

has

0..*

1

Page : 145

OOAD

OOAD

Chapter 5. OOA

Interaction Diagram

Interaction Diagram shows an interaction, consisting of 1. A set of classes or objects2. Their relarionships3. Messages that may be dispatched among classes or objects

2 typess of interaction diagrams

1. Sequence Diagram emphsizes time ordering of messages.

2. Collaboration Diagram emphasizes structural organization of objects or classes that send and receive messages

Page : 146

OOAD

OOAD

Chapter 5. OOA

Common Properties Sequence diagram and Collaboration Diagram

are just a special kinds of diagram and shares the same common properites as do all other diagrams- A name- Graphical contents

What distinguishes 2 kinds of an interaction diagram from each other is its particular content and its explanation scheme.

Contents of Interacton Diagram:- Objects- Links- Messages

Interaction Diagram

Page : 147

OOAD

OOAD

Chapter 5. OOA

Semantic Equivalence Sequence diagram and collaboration diagram are

semantically equivalent.

As a result, you can take a diagram in one from and convert it to the other without any loss information. (this feature is supported in Rational ROSE)

Interaction Diagram

Page : 148

OOAD

OOAD

Chapter 5. OOA

Common Uses Interaction diagram is used to model the dynamic aspects of

a system.

Use Case and Interaction Diagram

From the system context, you can attach at least one interaction diagram to a particular use case to explains use case’s dynamic aspects (ether main flow of events or possible scenario, or both)

Interaction Diagram

Page : 149

OOAD

OOAD

Chapter 5. OOA

How to Find Interactions

From each use case, the methods of elemental classes are provided for being called by another class(es). The method of class will be the message pointed to itself. The class that receive the message is called receiver, while, the class that send the message is called sender.

What are Yielded by Interactions

During interaction diagram construction, may be, the new messages are created. This scenario yields the set of methods belonging to the receiver.

Interaction Diagram

Page : 150

OOAD

OOAD

Chapter 5. OOA

Customer : <Actor Name>

ATM KeyPad

Enter Pin Code The method “Enter Pin Code” belongs to classATM KeyPad, not Customer.

We can say that “Enter Pin Code” is the service provided by ATM Keypad

If the method “Enter Pin Code” is now not of “ATM KeyPad”, this method must be added as public method of class ATM Keypad.


ATM KeyPad

1: Enter Pin Code

Sequence diagram

Collaboration diagram

Interaction Diagram

Page : 151

OOAD

OOAD

Chapter 5. OOA

Many times, there are the new class (and also its attributes and methods) that are just discovered in this phase. Please note that the new discovered class, usually, have to be added into the class diagram in the next iteration (based on the spiral process model).


ATM KeyPad Screen

Enter Pin CodeShowMessage("Enter Amount")

Sequence diagram

Interaction Diagram

Page : 152

OOAD

OOAD

Chapter 5. OOA

Sequence Diagram emphasizes the time ordering of messages.

To form a sequence diagram is to1. Place the classes or objects that participate in

interaction at a top of diagram along the X axis2. Move the initiate class to the left3. Place the messages along the the Y axis (time axis).

How many Sequence Diagrams should have?The number of sequence diagram should corresponds to the

number Of Use Case.

Interaction Diagram

Sequence Diagram

Page : 153

OOAD

OOAD

Chapter 5. OOA

Interaction DiagramSequence Diagram

Sequence Diagram Syntax

: Client : Transaction : Account

create

check Balance

update Balance

desrtroy

Tim

e p

asse

d

Classes or Objects

MessagesTimeline

Focus of Control

Page : 154

OOAD

OOAD

Chapter 5. OOA

Collaboration Diagram emphasizes the organization of the objects that participate in an interaction.

How to Build the Collaboration Diagram1. Place the classes or objects that participate in interaction

as a vertices in a graph.2. Render the link of message that connect the objects as the

arc of the graph.3. Give the name of the message led by the number to show

the sequence of interaction

Interaction Diagram

Collaboration Diagram

Page : 155

OOAD

OOAD

Chapter 5. OOA

Interaction DiagramCollaboration Diagram

: Client : Transaction

: Account

1: create

2: check Balance3: update Balance

4: desrtroy

Class or Objects

Sequence of Messages

LinkCollaboration Diagram Syntax

Page : 156

OOAD

OOAD

Chapter 5. OOA

Exercise 3: Build the Interaction Diagram

Directions:

Based on the use case diagram (from Exercise 1), model the interaction of each use case either by Sequence Diagram or Collaboration Diagram

Page : 157

OOAD

OOAD

Chapter 5. OOA

CASE STUDY: (30 points)

Foreign Currency Exchange SystemAnalysis

Page : 158

OOAD

OOAD

Chapter 5. OOA

CASE STUDY:


Problem Statement

The case sutdy features a bank with a number of worldwide distributed branches. The bank provides its customers with various banking services, such as automatic teller machine, credit card, and foreign currency exchange

The FCE application supports foreign currency cash and traveller’s check trading services to customers based on current exchange rates. Customers who have account in a bank branch are considered as bank customers. Customers who do not have an account in any bank branches are considered general customers. Both kinds of customers can use the exchange services

Page : 159

OOAD

OOAD

Chapter 5. OOA

CASE STUDY:


Problem Statement (continued)

The CFE application manages information about customers, foreign currencies, orders and payments, and stock availablibility. Branch cashiers are provided with country information, including country, currency name, denominations of both cash and traveller’s checks, and foreign counrty currency restrictions. Cashiers get customer information, create an order, and receive an immediate response regarding the request stock availability in their drawers and in the local branches. Customer orders can be pending, in process, or completed. An order becomes pending only if sufficient stock is not available in the cashier’s draser or in the local branch. For bank customers, they have two choices fore receiving the foreign currency money, receive a cash or account debit.

Page : 160

OOAD

OOAD

Chapter 5. OOA

CASE STUDY: Foreign Currency Exchange System Analysis

Manage Orders

(from Use Case)

Bank Customer

(from Actors)

General Customer

(from Actors)

Place the Order

(from Use Case)

Manage Stocks

(from Use Case)

Bank

(from Actors)

Manage Customer Inf ormation

(from Use Case)

System Context

Page : 161

OOAD

OOAD

Chapter 5. OOA


Requirements Model

Bank Customer

(f rom Actors)General Customer

(f rom Actors)

Manage Customer Information

(f rom Use Case)

Place FCCY Order

(f rom Use Case)

Place Travel ler Check Order

(f rom Use Case)

Manage Traveller Check Order

(f rom Use Case)

Manage Stocks

(f rom Use Case)

<<extend>>

Manage Foreign Currency Order

(f rom Use Case)

<<extend>>

Customer

(f rom Actors)

Place the Order

(f rom Use Case)

Manage Orders

(f rom Use Case)

Convert Exchange Rate

(f rom Use Case)

<<include>>

Bank

(f rom Actors)

Manage Exchange Rate

(f rom Use Case)

Page : 162

OOAD

OOAD

Chapter 5. OOA


System Vocabulary

General Customer

(f rom Actors)

Foreign Curency Payment(from Classes)

Foreign Currency Order

(from Classes)

pays

Travel ler Cheque Payment

(from Classes)

Travel ler Cheque Order

(from Classes)

pays

Customer

(f rom Actors)

Exchange Rate(from Classes)

Bank

(f rom Actors)

Money Stocks

(f rom Classes)

manage

Bank Customer

(f rom Actors)

Account(f rom Classes)

has

Order(f rom Classes)

place

Bank Branch

(f rom Actors)

Payment(f rom Classes)

receive

manage

manage

Page : 163

OOAD

OOAD

Chapter 5. OOA


Requirements Model(Iterative 2)

Convert Exchange Rate

(f rom Use Case)

Bank Customer

(f rom Actors)General Customer

(f rom Actors) Place FCCY Order

(f rom Use Case)

Place Travel ler Check Order

(f rom Use Case)

Manage Traveller Check Order

(f rom Use Case)

Manage Stocks

(f rom Use Case)

Manage Foreign Currency Order

(f rom Use Case)

Customer

(f rom Actors)

Place the Order

(f rom Use Case)

Bank

(f rom Actors)

Manage Exchange Rate

(f rom Use Case)

<<extend>>

<<extend>>

Manage Customer Information

(f rom Use Case)

Bank Branch

(f rom Actors)

Manage Orders

(f rom Use Case)

<<include>>

Page : 164

OOAD

OOAD

Chapter 5. OOA


Preliminary Class Diagram

General Customer

(f rom Actors)


FCCYOrderId

(from Classes)

Foreign Curency Payment

FCCYPaymentId

(from Classes)

1

1pays

Traveller Cheque Order

TravChequeOrderId

(from Classes)

Travel ler Cheque Payment

TravChequePaymentId

(from Classes)

1

1

pays

Money Stocks

CurrencyStockAmount

increase()decrease()

(f rom Classes)

Account

Account NumberAccount NameAccount Balance

deposit()withdraw()

(from Classes)

Bank Customer

(f rom Actors)

1

1

has

Order

OrderIdOrderType

(f rom Classes)

Customer

(f rom Actors)0..*

1

place

Payment

PaymentIdPaymentType

(from Classes)

0..*

1

receive

Bank Branch

(f rom Actors)

0..*

1

manage

0..*

1

manage

0..*

1

0..*

1

0..*

10..*

1

1

1

Bank

(f rom Actors)

0..*

1

manage

Exchange Rate

FirstCurrencySecondCurrencyExchangeRateExchangeDate

(from Classes)0..*

1 acquire

0..*

1

0..*

1

1

1

1

1

Page : 165

OOAD

OOAD

Chapter 5. OOA


Class Diagram

General Customer

(f rom Actors)


Denomination

(from Classes)

Foreign Curency Payment

FCCYPremium

(from Classes)


TravChequeOrderId

(from Classes)

Traveller Cheque Payment

Travel lerChequeFeeTravel lerChequeExpireDateTravel lerChequeNumber

(from Classes)

Account

Account NumberAccount NameAccount Balance

deposit()withdraw()

(from Classes)

Bank Customer

(f rom Actors)

Customer

CustomerIdCustomerName

CustomerAddressCustomerPhone

(f rom Actors)

Order

OrderIdOrderTypeOrderDateOrderStatusOrderCurrencyOrderAmount

setStatus()

(from Classes)

Payment

PaymentIdPaymentTypePaymentDatePaymentStatus

setStatus()

(from Classes)

Bank Branch

BranchIdBranchName

BranchLocation

(f rom Actors)Money Stocks

CurrencyStockAmount

increase()decrease()

(f rom Classes)

Exchange Rate

FirstCurrencySecondCurrencyExchangeRateExchangeDate

(from Classes)

Bank

BankIdBankName

(f rom Actors)

1

1

1

1

pays

1

1

1

1

pays

1

1

1

1

has

0..*

1

0..*

1place

0..*

1

0..*

1

receive

0..*

1

0..*

1

manage

0..*

1

0..*

1

manage

0..*

1

0..*

1

manage

0..*1

0..*1

acquire

Page : 166

OOAD

OOAD

Chapter 5. OOA


Sequence Diagram:Manage Customer Information – New Customer

: Customer : Bank Branch

[new customer] create()

: Bank Customer : General Customer

: Account

[want to open account] create()

[do not want to open account] create()

create()

Page : 167

OOAD

OOAD

Chapter 5. OOA


Sequence Diagram:Manage Customer Information – Not New Customer

: Customer : Bank Branch

[new customer] create()

: Bank Customer : General Customer

: Account

[want to open account] create()

[do not want to open account] create()

create()

Page : 168

OOAD

OOAD

Chapter 5. OOA


Sequence Diagram:Manage Stock – Decrease Stock

: Bank : Money Stocks

checkStockAmount

[more than decreased amount]decrease( )

Page : 169

OOAD

OOAD

Chapter 5. OOA


Sequence Diagram:Manage Stock – Increase Stock

: Bank : Money Stocks

increase( )

Page : 170

OOAD

OOAD

Chapter 5. OOA


Sequence Diagram:Place Foreign Currency Order

: Customer : Foreign

Currency Order

create()

setStatus( "new order")

[is bank customer] setReceivingMethod()

[is receive by Account] setReceivingAccountNumber()

Page : 171

OOAD

OOAD

Chapter 5. OOA


Sequence Diagram:Place Traveller Cheque Order

: Customer : Traveller

Cheque Order

create()setStatus( "new")

Page : 172

OOAD

OOAD

Chapter 5. OOA


YOUR JOBSYOUR JOBS

[Optional] Improve the Use Case Diagram[Mandatory] Improve the Class Diagram[Mandatory] Create Sequence Diagram of Other Use Cases

Don’t forget that the diagrams should be the revised based on spiral process model.

Page : 173

OOAD

OOAD



Page : 174

OOAD

OOAD

Chapter 6. OOD

Object Oriented Design

1. OOA Models Refienement• Class Diagrams Refinement• Interaction Diagrams Refinement• Forward and Backward Engineering

2. Activity Design3. Architecture Design

• Component Design• Hardware Platform Design

4. Persistent Data Design

Page : 175

OOAD

OOAD

Chapter 6. OOD


1. OOA Models Refienement

1.Class Diagram Refinement2.Interaction Diagram Refinement3.Forward and Backward Engineering

Class Diagram Refinement

Behavior DiagramRefinement

Page : 176

OOAD

OOAD

Chapter 6. OOD

Object Oriented Design: OOA Models Refinement

Class Diagram Refinement

Refinement Techniques

• Add non-business classes and relationships• Clarify attributes and methods of classes• Add non-business attributes• Add non-business methods• Refine information hiding levels• Add Interfaces

Page : 177

OOAD

OOAD

Chapter 6. OOD


Class Diagram RefinementAdd non-business classes and relationships

What are non-business classes?

The classes that represents the system in technical terms, not represents the data or business content: such as

• Application Forms• I/O Classes• Execution Classes• Data Store Classes• etc.

Page : 178

OOAD

OOAD

Chapter 6. OOD


Class Diagram RefinementClarify Attributes and Methods of Class

Clarification TechniquesThe classed created during analysis phase, normally, has an incomplete set of attributes and functions: How to refine them?

• Add missing business attributes and business methods to classes• All Attributes should have simple or complex types• Answer the question “Should the method return something?”• Think of the paramether that the method should have

Page : 179

OOAD

OOAD

Chapter 6. OOD


Class Diagram RefinementAdd non-business attributes

What are the non-business attributesThe attributes of both business class and non-business class that are not representing the business content of the class, for example:

• Create Date or Last Update Date• Data Usage Status• Version• Confidential Level

Page : 180

OOAD

OOAD

Chapter 6. OOD


Class Diagram RefinementAdd non-business methods

What are non-business methods?The methods that are not effecting the business properties of class, such as:

• backup methods• set Active/Inactive status of class• Open and Close Data Store Class• etc.

Page : 181

OOAD

OOAD

Chapter 6. OOD


Class Diagram RefinementRefine Information Hiding Level

Think of the attributes and methods of classes

• the attributes / methods should be private, protected or public• provide the public methods for setting or getting or manipulating each private attribute

Page : 182

OOAD

OOAD

Chapter 6. OOD


Class Diagram RefinementAdd Interfaces

Interface is a collection of operations that specify a service of a class. An interface describes the exernally visible behavior of that element.

Interface is a collection of declaration of operations but never have an implementation.

This constructs supports 2 OO concepts1. Modularity 2. Polymorphism.

Page : 183

OOAD

OOAD

Chapter 6. OOD


Class Diagram RefinementAdd Interfaces (cont.d)

Interface never been a one-man-show component.But:

It always be inheritted, so called, specialized by classon the other hands :

class always possesses the operations provided by interface

Page : 184

OOAD

OOAD

Chapter 6. OOD



UML notations for interfaces: in UML an interface is represented by a circle

Vehicle Interf ace

ref uel()stop()

Car

Engine CC

driv e()

Airplane

Engine Ty peVertical Wing Ty pe

Landing()Take Of f ()

Interface

Page : 185

OOAD

OOAD

Chapter 6. OOD



When to Use InterfacesThe interface should be used if

1. There are many classes that use the same functions

2. The functions in 1 ,for the different classes, may needs the different implementations

3. If the development is in a form of a “medium to big” project, interface is one of very good tools for the “development planning”

Page : 186

OOAD

OOAD

Chapter 6. OOD

Exercise 4: Part IRefine the OOA Diagrams

Directions:

Based on the class diagram representing the activity of depositting/ withdrawing the money to/from Deposit Account (shown in next page). Use the Class Diagram Refinement Concepts to Refine them and create the OOD Diagram.HINT: please don’t forget the spiral process model

Page : 187

OOAD

OOAD

Chapter 6. OOD

Exercise 4: Part IRefine the OOA Diagrams Bill

Bil l NumberBil l Type

print()

Deposit Transaction

Deposit TypeWithdraw Transaction

Id Card Number

TransactionTransaction NumberTransaction TypeTransaction DateTransaction Amount'Transaction Status

take Action()

confirm

Customer

(f rom Actors)

Bank

Deposit AccountAccount NumberAccount NameOutstanding Amount

deposit()withdraw()

providehold

effect

Overdraft Withdraw Transaction

OD Interest Rate

Page : 188

OOAD

OOAD

Chapter 6. OOD


Interaction Diagram Refinement

Refinement Techniques

• Refine the existing messges• Add the non-business classes and

their corresponding message to the sequence diagram

Page : 189

OOAD

OOAD

Chapter 6. OOD


Interaction Diagram RefinementRefine Existing Messages

How to refine the existing messages?

To refine the existing messages in sequence/collaboration diagram is to:• clarify the parameter(s) of message, if existed.• Add new messages, if needed.• Delete some messages, if it is not needed anymore.

Page : 190

OOAD

OOAD

Chapter 6. OOD


Interaction Diagram RefinementAdd the non-business classes and their corresponding message to the sequence diagram

Q: How comes the non-business classes? A: from the OOD Class Diagram

TechniquesFor the sequence Diagram:

•The class for input frequently stay on the left side of diagram.

•The class for output frequently stay on the right side of diagram.

•Mostly, the message added are dealing with the input/output or flow of data.

•Don’t worry of adding new classes or messages to the diagram, based on the spiral process model, they will be revised.

Page : 191

OOAD

OOAD

Chapter 6. OOD

Exercise 4: Part IIRefine the OOA Diagrams

Directions:

Look at the sequence diagram on the next pages:Answer the question 1. From the sequence diagram, can we refine the class diagrams (the class diagram done in part I )? If you can do it.2. refine sequence diagrams to produce OOD sequence diagrams from the given sequence diagrams

Page : 192

OOAD

OOAD

Chapter 6. OOD


: Customer

: Deposit Transaction

: Deposit Account

: Bill

fill()deposit( )

print( )

Sequence Diagram for “Depositing the Money” to Account

Page : 193

OOAD

OOAD

Chapter 6. OOD


Sequence Diagram for “Withdraw the Money” from Account

: Customer : Withdraw Transaction

: Deposit Account

: Bill

fill()withdraw( )

print( )

Page : 194

OOAD

OOAD

Chapter 6. OOD


Sequence Diagram for “Overdraft Withdraw”

: Customer : Bank : Overdraft Withdraw

Transaction : Deposit Account

: Bill

fill()

set Interest()withdraw( )

print( )

Page : 195

OOAD

OOAD

Chapter 6. OOD

Cla

ss Dia

gra

m

Refi

nem

ent

Behavio

r D

iag

ram

Refi

nem

ent


Forward and Backward EngineeringDefinition• Forward Engineering: the

refinement on class diagram effects the behavior diagrams

• Backward Engineering: the refinement on behavior diagrams effects the class diagrams

Forward Engineering

Backward Engineering

Page : 196

OOAD

OOAD

Chapter 6. OOD

Cla

ss Dia

gra

m

Refi

nem

ent

Behavio

r D

iag

ram

Refi

nem

ent


Forward and Backward EngineeringForward Engineering• The changes on classes’ functions

cause the change on messages in behavior diagrams

• The increases or/and decrease of class cause the change of participant classes in behavior diagrams

Forward Engineering

Page : 197

OOAD

OOAD

Chapter 6. OOD

Cla

ss Dia

gra

m

Refi

nem

ent

Behavio

r D

iag

ram

Refi

nem

ent


Forward and Backward EngineeringBackward Engineering• The increment/decrement of

messages on behavior diagrams impacts the methods of classes

• The increment/decrement/modification on the semantics of messages may impacts the methods of classes

Backward Engineering

Page : 198

OOAD

OOAD

Chapter 6. OOD

Exercise 4: Part IIIRefine the OOA Diagrams

Directions:

Use the forward and backward engineering to revise the refinement of class diagram and sequence diagram from part I and II.

Page : 199

OOAD

OOAD

Chapter 6. OOD


2. Activity Design

1.Statechart Diagram:Definition2.Modeling Statechart Diagram3.Refining Statechart Diagram

Page : 200

OOAD

OOAD

Chapter 6. OOD


2. Activity Design

Statechart Diagram : Definitions

Statechart Diagram shows a state machine, emphasizing the flow of control from state to state.State Machine is a behavior that specifies the sequence of states and objects goes through during its life time in response to events together with its response to events.State is a condition or situation in the lifetime of object during which it satisfies some conditions, perform some activity and wait for some event.

Page : 201

OOAD

OOAD

Chapter 6. OOD


2. Activity Design


Event is a specification of occurrence or stimulus that can trigger the state transition.Transition is a relationship between two statesActivity is an excution within a state machine

Page : 202

OOAD

OOAD

Chapter 6. OOD


2. Activity Design


When to Model Statechart Diagram?To explain the detail specification of states, transitions and events that is possible to form the activity on the class’s object.

Statechart can lead to the programming specification.

Page : 203

OOAD

OOAD

Chapter 6. OOD


2. Activity Design

What are needed for Preliminary Statecart DiagramPrelim. Statechart Diagram needs 1. Important or Main States2. Initial State3. Final State (optional)4. Transition and Prelim. Event

Modeling Statechart Diagram

Page : 204

OOAD

OOAD

Chapter 6. OOD


2. Activity Design

Modeling Statechart Diagram : Prelim. Statechart Diagram

IdleAlarm

Police Calling

Locked

10 minutes

intruding cleared

intruding cleared

onintruding detected

off

intruding cleared

10 minutes

Initial State

Final State

Transition

State

Event Intruder Detector Statechart Diagram

Page : 205

OOAD

OOAD

Chapter 6. OOD


2. Activity Design

Refining Statechart Diagram

Two schemes of refinement

1. Composite States: Try to decompose the state into many detailed states and transitions

2. Explanation: Try to add the actions and events to states and/or transitionsBoth schemes always be used together

Page : 206

OOAD

OOAD

Chapter 6. OOD


2. Activity Design


Two schemes of refinement: Composite StatesComposite States:The State can be decomposed into a

new sub-statechart diagram that contains initial states, final states, internal states, events

Page : 207

OOAD

OOAD

Chapter 6. OOD


2. Activity Design


Two schemes of refinement: ExplanationExplain the statesYou can explain the state by inserting

actions into the stateThe action can be in these type

• Entry example: on entry/show message (“Hello”)

• Exit example: on exit/disconnect

• On Event example: on every 1 minutes / monitor mailbox

Page : 208

OOAD

OOAD

Chapter 6. OOD


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


Low Frequency Sound

5 seconds5 seconds

interrupted

interrupted

10 minutes

intruding cleared

Composite states

Explanation

Page : 209

OOAD

OOAD

Chapter 6. OOD


2. Activity Design

Refining Statechart Diagram : Example

Idle

on

Alarm


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


Low Frequency Sound

entry/ count = 0on every 1 second/ count = count+1on [count = 5]/ No Sound

5 seconds

interrupted

intruding cleared

10 minutes

5 secondsinterrupted

Page : 210

OOAD

OOAD

Chapter 6. OOD

Exercise 5Statechart Diagram

Directions:

From the statechart diagram on previous page,1. Show the explanation of state “High Frequency Sound”2. If the requirement is that: After 10 minutes of mailing the

police, and nothing done, every door in the building must be closed. Immediately, after that, every window must be closed. And, 10 minutes after the closing of windows the air-conditioner must be shut down. Please refine the statechart diagram.

Page : 211

OOAD

OOAD

Chapter 6. OOD


3. Architecture Design

1.Component Design2.Hardware Platform Design

Page : 212

OOAD

OOAD

Chapter 6. OOD



Component DesignComponent Diagram

Component Diagrams commonly contains• Components• Interfaces• Relationships

• Dependency• Generalization• Association• Realization

Page : 213

OOAD

OOAD

Chapter 6. OOD



Component DesignComponent Diagram

The common purpose for using component is to model the components that can make the implementation.

For the most systems, the deployment components are drawn from the decisions made about how to segment the physical implementation of the system

Page : 214

OOAD

OOAD

Chapter 6. OOD



Component DesignComponent Design Methodologies1. System Partitioning2. Design Components & Relationships of Subsystems

Page : 215

OOAD

OOAD

Chapter 6. OOD



Component DesignDesign Methodologies: System Partitioning

The system should be partitioned into three subsystems:• Presentation Logic Subsystem : Input/Output/UI of System• Business Logic Subsystem : Working Parts of the system.• Database Logic Subsystem : Persistent Parts of the System

Page : 216

OOAD

OOAD

Chapter 6. OOD



Component DesignDesign Methodologies: Model Presentation Logic Subsystem

The Components in Presentation Logic Subsystem belong to:User Interface ComponentsInput UnitsDisplay ComponentsWeb Pages / Windows Form

Page : 217

OOAD

OOAD

Chapter 6. OOD



Component DesignDesign Methodologies: Model Presentation Logic Subsystem

Example

Main App

Open File Dialog

Save File Dialog

Print File Form

AppWebPage

DataReconcileForm

show

has

call call

call

Data Input Formhas

Page : 218

OOAD

OOAD

Chapter 6. OOD



Component DesignDesign Methodologies: Model Business Logic Subsystem

The Components in Business Logic Subsystem belong to:ApplicationsApplication SubprogramsLibrariesExecutable Programs

Page : 219

OOAD

OOAD

Chapter 6. OOD



Component DesignDesign Methodologies: Model Business Logic Subsystem

Example TransactionManage.exe

Receoncile.h

include

TXNKeyin.h

Screen.h

include

include

TableRender.h

include

include

Form.htmload

Page : 220

OOAD

OOAD

Chapter 6. OOD



Component DesignDesign Methodologies: Database Logic Subsystem

The Components in Database Logic Subsystem belong to:Data ItemsData InterfacesDatabase Connections

Page : 221

OOAD

OOAD

Chapter 6. OOD



Component DesignDesign Methodologies: Database Logic Subsystem

Example

Transaction Data File

Transaction Data Table

Application Database

contains

DB Connectionhas

contains

DB Login

manage

Page : 222

OOAD

OOAD

Chapter 6. OOD



Hardware Platform Design

The components developed or reused as part of software must be deployed on some set of hardware and platform in order to execute.

The hardware platform can be modeled on Deployment Diagram

Page : 223

OOAD

OOAD

Chapter 6. OOD




Deployment Diagram

Deployment diagram consists of Nodes and Connection.

Node is used to represent the deployment and its stereotype, description of component deployed can be put in the note of the noce.

Connection describes the type of connection connecting a pair of nodes.

Page : 224

OOAD

OOAD

Chapter 6. OOD



Hardware Platform DesignDeployment Diagram: Example

AppServer<<Cluster>>

Client<<Web>>

internet

DBServer<<ORACLE>>

Deploys Presentation

Deploys Business

Deploys Database

Page : 225

OOAD

OOAD

Chapter 6. OOD




Deployment Diagram

Not only the deployment, the deployment diagram can model the device connecting to the software.

Normally, the deployment diagram with device attached is extended from device-free version.

Page : 226

OOAD

OOAD

Chapter 6. OOD



Hardware Platform DesignDeployment Diagram: Example

AppServer<<Cluster>>

Client<<Web>>

internet

DBServer<<ORACLE>>

Printer

Smart Card

Page : 227

OOAD

OOAD

Chapter 6. OOD



Persistent Data means Data that has to be kept in the data storage for using in the future.

Persistent Data Design means • Design of Structure of Data• Design of Relationships between Data

Page : 228

OOAD

OOAD

Chapter 6. OOD



How Comes the Structure of Persistent Data?

• The persistent data comes from the structure of class diagram• Not all classes go to the persistent data• Normally, structure of data is structure of classes of the

final analysis model• Only the attributes of classes are the details of persistent data

Page : 229

OOAD

OOAD

Chapter 6. OOD



How Comes the Relationships between Persistent Data?

• The relationships between data are from the abstractions applied in the class diagram.

• The referential rules is used to maintain the relationship between data in data store.

• All abstractions can be converted to data logical relationships by abstraction-relationship conversion rules.

Page : 230

OOAD

OOAD

Chapter 6. OOD



Referential Rule1. Primary Key and Foreign Key

Primary Key is the attribute or group of attributes that is selected for identifying the uniqueness of data instance

Foreign Key is the attribute that is used by one data to link the relationship to the primary key of other data

Page : 231

OOAD

OOAD

Chapter 6. OOD



Referential Rule1. Primary Key and Foreign KeyExample

Person Id

Person NamePerson Age

Address Id

Address Name

Primary Key

Person Data

Address Data

Attributes

Person Id

Person NamePerson AgePerson Address

Address Id

Address Name

Foreign Key refers to Address DataThe value in Person Address must not outside the possible values of Address Id in Address

Lives in10..n

Page : 232

OOAD

OOAD

Chapter 6. OOD



Referential Rule1 to 1 relationshipsChoose primary key of one side of the

relationship as a foreign key of the other side.

Car Id

Car NameCar Model

Engine Id

Engine CC

EngineCar

Car Id

Car NameCar ModelEngine Id

Engine Id

Engine CC

EngineCar

has1..1

0..1

or

Car Id

Car NameCar Model

Engine Id

Engine CCCar Id

EngineCar

has1..1

0..1

Page : 233

OOAD

OOAD

Chapter 6. OOD



Referential Rule1 to Many relationshipsPut the primary key on the one side as

the foreign key on the many side

Country Id

Country NameCountry Area

City Id

City Name

CityCountry

Country Id

Country NameCountry Area

City Id

City NameCountry Id

City

Country

has 1..n1..1

Page : 234

OOAD

OOAD

Chapter 6. OOD



Referential RuleMany to Many relationshipsCreate the new data to keep the pairs of

primay keys of the data on both sides of relationship.

Subject Id

Subject NameSubject Credit

Student Id

Student Name

StudentSubject

study0..n

0..n

Subject Id

Subject NameSubject Credit

Student Id

Student Name

StudentSubject

Subject IdStudent Id

Subject-Student

0..n

1..1 1..1

0..n

Page : 235

OOAD

OOAD

Chapter 6. OOD



Abstraction-Relationship Conversion Rules

• Association Abstraction ConversionApply the referential rule based on the cardinality of association abstraction

Page : 236

OOAD

OOAD

Chapter 6. OOD




• Association Abstraction Conversion

Example

Customer

CustomerIdCustomerName

CustomerAddressCustomerPhone

(f rom Actors)

Order


setStatus()

(from Classes)place

0..*

1

Customer NameCustomer AddressCustomer Phone

Customer Id

Order TypeOrder DateOrder StatusOrder CurrencyOrder AmountCustomer Id

Order Id

place

0..n

1..1

Custom er O rder

Page : 237

OOAD

OOAD

Chapter 6. OOD




• Aggregation Abstraction ConversionApply referential rule based on the cardinality of component classes, normally the cardinality of aggregated class is one. The relationship between aggregated and component classes are one-to-one ot one-to-many relationship.

Page : 238

OOAD

OOAD

Chapter 6. OOD




• Aggregation Abstraction ConversionExample

BodyBody IdBody Model

TurnAround()

ArmArm IdArm Model

Hold()

LegLeg IdLeg Model

walk()

HeadHead IdHead Model

process()

RobotRobotIdRobot Model

Work()

1 2..2 2..2 1..11 2..2 2..2 1..1

Robot Model

Robot Id

Robot

Head ModelRobot Id

Head Id

Head

Arm ModelRobot Id

Arm Id

Arm

Leg ModelRobot Id

Leg Id

Leg

Body ModelRobot Id

Body Id

Body

1..1

1..1

2..2

2..2

Page : 239

OOAD

OOAD

Chapter 6. OOD




• Generalization Abstraction ConversionThe Generalization Abstraction can be replaced, in database by the one-to-one relationship which allow the absence of the data on the sub-class side.

The primary Key of subclass is the same as the primary key of the super class, on the other words, the primary key of the subclass is the foreign key refering to the primary key of the super class.

Page : 240

OOAD

OOAD

Chapter 6. OOD




• Generalization Abstraction ConversionExample


TravChequeOrderId

(from Classes)


Denomination

(from Classes)

Order


setStatus()

(from Classes)

order TypeOrder DateOrder StatusOrder CurrencyOrder Amount

Order Id

order

TravellerCheque Order Id

Denomination


Foreign Currency order

0..10..1

1..11..1

Page : 241

OOAD

OOAD

Chapter 6. OOD

CASE STUDY: (30 points)

Foreign Currency Exchange SystemDesign

Page : 242

OOAD

OOAD

Chapter 6. OOD

CASE STUDY:

Foreign Currency Exchange SystemDesign

Assignment

1. From the Foreign Currency Exchange Syatem analysis models, refine class diagram, sequence diagram and statechart diagram.

2. Perform the persistent data design.3. Partition the system and design the component diagram

(based on the requirements)4. Discuss on the appropriate hardware platform (based on the

requirements) Design the deployment diagram.

Page : 243

OOAD

OOAD

Chapter 7 Software Testing

Chapter 7 Software Testing

Page : 244

OOAD

OOAD

Chapter 7. Software Testing

Software Testing

Testing Objectives

1. Testing is a process of executing a program with the intention of finding a set of errors

2. A good test case is one that has a high probability of finding an undiscovered error.

3. A Successful test is one that uncovers an undiscovered errors.

Test Case = the body of inputs and their conditions that are created and asserted to a software, in a specific software environment, to make a software create the expected output.

Page : 245

OOAD

OOAD

Software Testing

Testing Principles

1. All tests should be traceable to users’ requirements.

2. Tests should be planned long enough before testing begin.

3. Testing should begin “in small scale” and progress toward testing “in large scale”.

4. The most effective testing should be conducted by an independent third party.


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.


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


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.


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


Page : 250

OOAD

OOAD

Software Testing

Testing Case Design


Test Cases for Validation Testing The test cases for validation testing

must be able give the precise answers tothe questions:

• Is the function or performance of software conform to the requirements? (Correctness Testing)

• Have the elements and configurations of software been developed or prepared properly? (Checklist Testing)


Page : 251

OOAD

OOAD

Software Testing

Testing Case Design


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)


software design and development

Documents

software design

software testingooadchapter

software build

development success

sequential process model

classic process model

development period

requirement analysis