CSE323
การวิเคราะห์ และออกแบบระบบ
(Systems Analysis and Design)
Lecture 06:
Object-Oriented Systems Analysis and Design
Using UML
www.themegallery.com
Major Topics





Apr-15
CSE323
Systems
Object-oriented concepts and terminology
CRC Cards
Unified Modeling Language
Use case and other UML diagrams
Relationships
2
Object-Oriented Overview
 วิธกี ารเชงิ วัตถุ (Object-oriented techniques) ใช ้
ั ซอนได
้
ได ้ผลดีเมือ
่ ระบบทีม
่ ค
ี วามซบ
้รับการบารุงรักษา
ปรับปรุงเปลีย
่ นแปลง และออกแบบอย่างต่อเนือ
่ ง
 UML (The Unified Modeling Language) คือ
มาตรฐาน (industry standard) สาหรับการจาลอง
ระบบเชงิ วัตถุ
Apr-15
CSE323
Systems
3
Goals of O-O Analysis
เป้ าหมายของการวิเคราะห์เชงิ วัตถุ
้
 การนากลับมาใชใหม่
คอ
ื เป้ าหมายหลัก
 ระบบการบารุงรักษาเป็ นเป้ าหมายทีส่ าคัญ
 การเปลีย
่ นแปลงในออบเจ็กต์หนึง่ จะมีผลกระทบต่อ
ออบเจ็กต์อน
ื่ น ้อยทีส
่ ด
ุ
Apr-15
CSE323
Systems
4
Object-Oriented Concepts
นิยามและแนวคิด:
 ออบเจ็กต์แทนสรรพสงิ่ ในโลกแห่งความเป็ นจริง (realworld thing) หรือเหตุการณ์ (event)
ื้ ฯลฯ
 ออบเจ็กต์อาจเป็ น ลูกค ้า รายการ คาสงั่ ซอ
 ออบเจ็กต์อาจเป็ น GUI displays หรือ text areas on a
display
 ออบเจ็กต์ถก
ู แทนด ้วยคลาสและจัดป็ นกลุม
่ ของคลาส
ั
 คลาสหรือกลุม
่ ของคลาสมีคณ
ุ สมบัตแ
ิ ละบริการหรือฟั งก์ชน
การทางานร่วมกัน
้ อ
• Instantiate เป็ นคาทีใ่ ชเมื
่ มีการสร ้างออบเจ็กต์ขน
ึ้ จากคลาส
• Attributes หรือแอททริบวิ ท์ คือลักษณะประจาหรือคุณสมบัตข
ิ อง
คลาสทีท
่ ก
ุ ออบเจ็กต์ในคลาสนัน
้ มี
้ ้
• Method หรือเมทธอด คืองานอย่างใดอย่างหนึง่ ทีส
่ ามารถเรียกใชได
จากออบเจ็กต์ในคลาส
Apr-15
CSE323
Systems
5
Class Symbol
ั ลักษณ์ของคลาส
สญ
Apr-15
CSE323
Systems
6
Inheritance
ื ทอดคุณสมบัต ิ
การสบ
ื ทอดคุณสมบัต ิ (Inheritance) เกิดขึน
 การสบ
้ เมือ
่ มีการ
สร ้างคลาสขึน
้ ใหม่จากคลาสทีม
่ อ
ี ยูแ
่ ล ้ว
 คลาสเดิมจะเป็ นคลาสแม่ (parent or base class)
 คลาสใหม่จะเป็ นคลาสลูก (child or derived class)
 คลาสลูกได ้รับการถ่ายทอดคุณสมบัตแิ ละบริการหรือ
ั การทางานจากตลาสแม่
ฟั งก์ชน
Apr-15
CSE323
Systems
7
CRC Cards
การ์ด CRC (Class, responsibilities, and collaborators)
ั พันธ์
ใชส้ าหรับแสดงความรับผิดชอบของคลาสและปฏิสม
ระหว่างคลาส
การสร ้างการ์ด CRC
 หาคานามและคากริยาในประโยคปั ญหา
 สร ้างสถานการณ์จาลอง (Scenarios) โดยพิจารณาจากการทางานตาม
จริงของระบบ
ิ้ เล็กลงและเล็กลงเรือ
 ระบุและกาหนดความรับผิดชอบให ้กับงานชน
่ ยๆ
เท่าทีจ
่ ะทาได ้
 พิจาณาว่างานต่างๆทาได ้โดยออบเจ็กต์หรือการโต ้ตอบกับออบเจ็ กต์
อืน
่ ไอย่างไร
ั การทางาน
 ระบุความรับผิดชอบทีเ่ กีย
่ วข ้องเป็ นเมทธอดหรือฟั งก์ชน
Apr-15
CSE323
Systems
8
The Unified Modeling Language (UML)
UML has three categories:
 สงิ่ ต่างๆ หรือ ออบเจ็กต์ (Things, the objects)
ั พันธ์ (Relationships, the glue that holds things
 ความสม
together)
 แผนภาพ (Diagrams, categorized as either structure
or behavioral)
Apr-15
CSE323
Systems
9
Two General Groupings of Things
กลุม
่ ของสง่ ต่างๆใน UML:
 Structural things ซงึ่ ใชก้ าหนดโครงสร ้างตามแนวคิดและ
โครงสร ้างทางกายภาพของระบบเชงิ วัตถุ และอธิบายด ้วย
คานาม
 Behavioral things เป็ นคากริยาในแบบจาลอง UML ทีใ่ ช ้
แทนพฤติกรรมของระบบ และสถานะของระบบ ก่อน ระหว่าง
และหลัง เมือ
่ มีพฤติกรรมดังกล่าวเกิดขึน
้
Apr-15
CSE323
Systems
10
Structural and Behavioral Things
Structural things ได ้แก่:
 Classes.
 Use cases.
 Interfaces.
Behavioral things ได ้แก่:
 Interactions
 State machines
Apr-15
CSE323
Systems
11
Types of Relationships
ั พันธ์:
ประเภทของความสม
 Structural relationships ผูกสงิ่ ต่างๆเข ้าด ้วกันในแผนภาพ
โครงสร ้าง (Structural diagram)
้
 Behavioral relationship ใชในแผนภาพเหตุ
การณ์
(Behavioral diagrams)
Apr-15
CSE323
Systems
12
Structural and Behavioral Relationships
Structural relationships ได ้แก่:




Dependencies.
Aggregations.
Associations.
Generalizations.
 Behavioral relationships ได ้แก่:




Apr-15
CSE323
Systems
Communicates.
Includes.
Extends.
Generalizes.
13
Structural and Behavioral Diagrams
Structural things are the most common and include:




Class and object diagrams.
Use case diagrams.
Component diagrams.
Deployment diagrams.
Behavioral things include:





Apr-15
CSE323
Systems
Use case diagrams.
Sequence diagrams.
Collaboration diagrams.
Statechart diagrams.
Activity diagrams.
14
Commonly Used UML Diagrams
แผนภาพทีใ่ ชกั้ นโดยทั่วไปใน UML:
 แผนภาพยูสเคส (Use case diagram) อธิบายว่าระบบถูกใช ้
อย่างไร
• เป็ นจุดเริม
่ ต ้นสาหรับแบบจาลอง UML
 ยูสเคส (Use case - not a diagram)
 แผนภาพกิจกรรม (Activity diagram)
• แต่ละยูสเคสอาจสร ้างแผนภาพกิจกรรม
 แผนภาพลาดับเหตุการณ์ (Sequence diagram) แสดง
ั พันธ์ชอง
ลาดับเหตุการณ์ของกิจกรรมต่างๆและความสม
คลาส
• แต่ละยูสเคสอาจสร ้างหนึง่ หรือหลายแผนภาพลาดับเหตุการณ์
• A collaboration diagram is an alternative to a sequence
diagram.
Apr-15
CSE323
Systems
15
Commonly Used UML Diagrams
แผนภาพทีใ่ ชกั้ นโดยทั่วไปใน UML (ต่อ):
 แผนภาพคลาส (Class diagram) แสดงคลาสต่างๆและ
ั พันธ์ของคลาส
ความสม
• แผนภาพลาดับเหตุการณ์ (Sequence diagrams) และการ์ด CRC
้
ใชในการก
าหนดคลาส
 แผนภาพสถานะ (Statechart diagram)
• แต่ละคลาสสามารถสร ้างแผนภาพสถานะ ซงึ่ มีประโยชน์ในการ
กาหนดเมทธอดของคลาส
Apr-15
CSE323
Systems
16
Overview of UML Diagrams
Apr-15
CSE323
Systems
17
Use Case Diagram
 A use case describes what the system does, not how it
does the work.
 The use case model reflects the view of the system of
the user outside of the system.
 Symbols are:
 Actor, a stick figure.
 Use case, an oval.
 Connecting lines.
Apr-15
CSE323
Systems
18
Actors
 Represent role played by one or more users
 Exist outside of the system
 May be a person, another system, a device,
such as a keyboard or Web connection
 Can initiate an instance of a use case
 May interact with one or more use cases and a
use case may involve one or more actors
Apr-15
CSE323
Systems
19
Actors (Cont.)
Actors may be divided into two groups:
 Primary actors supply data or receive information
from the system
 Secondary actors help to keep the system running
or provide help
• Help desk, analysts, programmers, etc.
Apr-15
CSE323
Systems
20
Use Case
 Consists of three things:
 An actor (user) that initiates an event.
 An event that triggers a use case.
 The use case that performs the actions triggered by
the event.
Apr-15
CSE323
Systems
21
Use Case (Cont.)
 Better to create fewer use cases
 20 use cases for a large system
 50 use cases would be the maximum for a large
system
 Can nest use cases, if needed
Apr-15
CSE323
Systems
22
Use Case Relationships
 Communicates
 Connect an actor to a use case
 Includes
 Use case contains a behavior that is common to
more than one use case.
 The common use case is included in other use
cases.
 Dotted arrow points toward common use case.
Apr-15
CSE323
Systems
23
Use Case Relationships (Continued)
 Extends
 A different use case handles variations or exceptions
from the basic use case.
 Arrow goes from extended to basic use case.
 Generalizes
 One thing is more general than another thing.
 Arrow points to the general thing.
Apr-15
CSE323
Systems
24
Use Case Relationships
Apr-15
CSE323 Systems Analysis and
Design 2/2549
25
Steps for Creating a Use Case Model
The steps required to create a use case model
are:
 Review the business specifications and identify
the actors within the problem domain.
 Identify the high-level events and develop the
primary use cases that describe the events and how
actors initiate them.
 Review each primary use case to determine
possible variations of flow through the use case.
 Develop the use case documents for all primary
use cases and all important use case scenarios.
Apr-15
CSE323 Systems Analysis and
Design 2/2549
26
Use Case Scenario
 A use case scenario may be created for the
standard flow through the use case.
 Other scenarios may be created for variations
on the main flow.
 A use case includes:
 Use case identifiers and initiators.
 Steps performed.
 Conditions, assumptions, and questions.
Apr-15
CSE323
Systems
27
Activity Diagrams
 Activity diagrams show the sequence of
activities in a process, including sequential and
parallel activities.
 Symbols are used for activities, decisions and
so on.
 Arrows represent events that connect the
activities.
Apr-15
CSE323
Systems
28
Activity Diagram Symbols
Apr-15
CSE323
Systems
29
Creating Activity Diagrams
 Ask what happens first, second, and so on.
 Determine if the activities happen in sequence
or parallel.
 Examine all the scenarios for a use case.
Apr-15
CSE323
Systems
30
Swimlanes
 Included on activity diagrams to show
partitioning
 Show which activities:




Occur on a browser
Occur on a server
Happen on a mainframe
Are done by external partners
 Help to divide tasks among team members
Apr-15
CSE323
Systems
31
Swimlane Boundaries
When an event crosses swimlane boundaries,
data must be transmitted.
 A Web form is sent to a server.
 Data are placed into middleware to transmit it
between a server and a mainframe.
 Data are transmitted to and from an external partner.
Apr-15
CSE323
Systems
32
Sequence Diagrams
 Sequence diagrams show a succession of
interactions between classes or object instances
over time.
 It also shows the processing described in a
single scenario.
 The leftmost object is the starting object.
 Time sequence is from top to bottom.
Apr-15
CSE323
Systems
33
Sequence Diagrams (Cont.)
 Horizontal arrows represent messages or
signals sent between classes.
 Solid arrowheads represent synchronous calls, the
sending class waits for a response.
 Half or open arrowheads represent asynchronous
calls, those sent without waiting for a returning signal.
Apr-15
CSE323
Systems
34
Message Name Formats
Message names may be in the following formats:
messageName()
messageName(parameter1, parameter2, …)
messageName(parameterType:parameterName)(defaultValue)
Apr-15
CSE323
Systems
35
Sequence Diagram Example
Apr-15
CSE323
Systems
36
Collaboration Diagrams
 Collaboration Diagrams show the same
information as a sequence diagram.
 The emphasis is on the organization of the
objects.
 Sequence is shown by including a sequence
number on the message.
Apr-15
CSE323
Systems
37
Collaboration Diagram Example
Apr-15
CSE323
Systems
38
Class Diagrams and Class Attributes
 Class diagrams show classes, attributes, and
operations or methods.
 A class is shown as a rectangle.
 Attributes are either:




Private (the norm), indicated by a minus sign.
Public, indicated by a plus sign.
Protected, indicated by a pound sign (#).
Attributes may include the type of data and any initial
value.
 Methods are usually public.
Apr-15
CSE323
Systems
39
Method Overloading
 Method overloading is including the same
method several times in a class.
 The method signature, its name and
parameters, and type of parameters, must be
different.
Apr-15
CSE323
Systems
40
Types of Classes
 Classes fall into several categories:




Entity classes.
Boundary or interface classes.
Abstract classes.
Control classes.
 Each class may use a special symbol, called a
UML stereotype.
Apr-15
CSE323
Systems
41
Entity Classes
 Entity classes represent real-world items.
 Attributes are those stored for the entity.
 Methods work with the entity.
Apr-15
CSE323
Systems
42
Boundary or Interface Classes
 Provide a means for users to work with the
system.
 Display screens, windows, dialogue boxes,
touch-tone telephone, external systems.
 Methods required to send or reset the display
screen, or to produce a report.
Apr-15
CSE323
Systems
43
Abstract Classes
 Abstract classes are the parent or general class
in a generalization/specialization relationship.
 Abstract classes may not be directly
instantiated.
 Only the child classes can create objects.
Apr-15
CSE323
Systems
44
Control or Active Classes
 Control or active classes are used to control the
flow of activities.
 Many small control classes may be included to
achieve reuse.
 Attributes are those needed temporarily by the
control class.
 Methods are those used in control activities .
Apr-15
CSE323
Systems
45
Sequence Diagram for
using two Web pages:
one for student
information, one for
course information.
Apr-15
CSE323
Systems
46
Relationships on a Class Diagram
 Relationships are the connections between
classes and include:
 Associations, showing the one-to-many relationships
between classes.
• An asterisk (*) is used to represent many.
 Association classes are used to break up a many-tomany association between classes.
Apr-15
CSE323
Systems
47
Association Class Example
Apr-15
CSE323
Systems
48
Whole/Part Relationships
 One class represents the whole, other classes
represent the parts contained in the whole.
 Three types of whole/part relationships:
 Aggregation.
 Collection.
 Composition.
Apr-15
CSE323
Systems
49
Aggregation




Apr-15
CSE323
Systems
Aggregation is a “has a” relationship.
The whole is composed of the sum of the parts.
If the whole is removed, the part may still exist.
The diamond at the end of the line is not filled
in.
50
Collection
 Consists of a whole and its members
 Examples are a library with books or a voting
district with voters
 If the part is removed, the whole retains its
identity
 A weak association
Apr-15
CSE323
Systems
51
Composition
 The whole has a responsibility for the parts, and
is a stronger relationship.
 If the whole is removed, the parts are removed
 Shown with a filled-in diamond on the line
 Example: an insurance policy with riders
Apr-15
CSE323
Systems
52
Whole/Part Example
Apr-15
CSE323
Systems
53
Generalization/Specialization Diagrams
 Generalization/specialization or gen/spec diagrams





Apr-15
CSE323
Systems
show the relationship between a more general thing and
a specific kind of thing.
This relationship is described as an “is a” relationship.
For example: a car is a vehicle, a truck is a vehicle.
Generalization relationship is used to model inheritance.
General class is a parent, base, or superclass.
Specialized class is a child, derived, or subclass.
54
Polymorphism
 Polymorphism or method overriding is when a
method is defined in several classes in a
gen/spec relationship.
 The subclass overrides the parent class
attributes and/or methods.
 If a number of classes are involved, the most
specific class is used.
Apr-15
CSE323
Systems
55
Gen/Spec Example
Apr-15
CSE323
Systems
56
Finding Classes
Classes may be discovered:




During interviews or JAD sessions.
During brainstorming sessions.
By using CRC cards.
By examining use cases, looking for nouns.
• Each noun may lead to a candidate or potential class.
Apr-15
CSE323
Systems
57
Determining Class Methods
Class methods may be determined by:
 Using a CRUD matrix.
 Looking at messages sent between classes.
• The receiving class must have the message name as a
method.
 Using statechart diagrams.
Apr-15
CSE323
Systems
58
Statechart Diagrams
 Statechart diagrams show class states and the
events that cause them to transition between
states.
 It is also called a state transition diagram
 An event happens at a specific time and place.
 They cause a change of state, or the transition
“fires”
Apr-15
CSE323
Systems
59
Statechart Diagrams (Cont.)
 Each time an object changes state, some of its
attributes must change.
 There must be a method to change the
attributes.
 Often there is a display screen or Web form to
enter the attributes.
Apr-15
CSE323
Systems
60
Statechart Diagrams (Cont.)
 Statechart diagrams are not created for all classes.
 They are created when:
 A class has a complex life cycle.
 An instance of a class may update its attributes in a
number of ways through the life cycle.
 A class has an operational life cycle.
 Two classes depend on each other.
 The object’s current behavior depends on what
happened previously.
Apr-15
CSE323
Systems
61
Statechart Example
Apr-15
CSE323
Systems
62
Packages
 Containers for other UML things
 Show system partitioning
 Indicate which use cases or classes are
grouped into a subsystem
 Can show component packages
 Can be physical subsystems
 Use a folder symbol
Apr-15
CSE323
Systems
63
Package Example
Apr-15
CSE323
Systems
64
Steps Used in UML
The steps used in UML are:
 Define the use case model.
 Continue UML diagramming to model the system.
during the systems analysis phase.
 Develop the class diagrams.
 Draw statechart diagrams.
 Begin systems design by refining the UML diagrams.
 Document your system design in detail.
Apr-15
CSE323
Systems
65
Next Lecture
Object Interaction and
Specifying Operations
Apr-15
CSE323
Systems
66