Tailieuxanh Uml Phan Tich Va Thiet Ke Huong Doi Tuong 0506

Phân tích và thiết kế hướng
đối tượng
(Object Oriented System
Analysis and Design)
Giảng viên: Phạm Ngọc Nam

© DHBK 2007 2/Chapter
Giới thiệu
• 4 ĐVHT = 60 tiết
• Học trên lớp + Bài tập lớn
• Điểm = Điểm thi + Điểm bài tập lớn
(70%) + (30%)
• Điều kiện thi: Phải có bài tập lớn
• Bài tập lớn:
 Làm theo nhóm tối đa 5 sinh viên
 Nội dung: phân tích và thiết kế hệ thống sử dụng Rational
Rose
 Đề tài: sinh viên tự chọn đề tài
• Mục đích của môn học
 Trang bị cho sinh viên một phương pháp có hệ thống để phân
tích và thiết kế hệ thống
Nội dung
1. Giới thiệu chung về phân tích và thiết kế hệ thống
2. Giới thiệu về phân tích và thiết kế hướng đối
tượng với UML
3. Lập kế hoạch
4. Phân tích hệ thống
5. Thiết kế hệ thống
6. Triển khai hệ thống
Tài liệu tham khảo

• Systems Analysis and Design with UML Version
2.0-An object oriented approach; Alan Dennis,
Barbara Haley Wixom, David Tegarden.
• www.uml.org
• www.rational.com
• www.Google.com
Chương 1. Giới thiệu chung về phân

tích và thiết kế hệ thống
1.1 Giới thiệu
1.2 Quy trình phát triển hệ thống
1.3 Các phương pháp phát triển hệ thống
1.1 Giới thiệu


• Lập kế hoạch (Planning)
 Vì sao phải xây dựng hệ thống ?
• Phân tích (Analysis)
 Ai sẽ sử dụng hệ thống, hệ thống sẽ làm gì, nó sẽ được
dùng khi nào, ở đâu?
• Thiết kế (Design)
 Hệ thống sẽ làm việc như thế nào?
• Triển khai (Implementation)
Triển khai hệ thống

Lập kế hoạch
• Xác định giá trị kinh doanh của hệ thống
• Phân tích tính khả thi
• Xây dựng kế hoạch công việc
• Xác định nguồn nhân lực cho dự án
• Điều khiển và quản lý dự án

Phân tích
• Phân tích hệ thống
• Thu thập các nguồn thông tin
• Mô hình hoá quá trình
• Mô hình hóa dữ liệu

Thiết kế
• Xác định chiến lược thiết kế
• Thiết kế cấu trúc
• Thiết kế giao diện
• Thiết kế cơ sở dữ liệu
• Thiết kế chương trình

Triển khai
• Xây dựng hệ thống
• Cài đặt hệ thống

Các pha và kết quả của từng pha
Process Product
Planning Project Plan
Analysis System Proposal
Design System
Specification
Implementation New System and

Maintenance Plan
1.3 Các phương pháp phát triển hệ

thống
• Thiết kế cấu trúc (Structured design)
 Phương pháp thác nước (waterfall method)
 Phương pháp phát triển song song (Parallel
development)
• Phương pháp phát triển nhanh ứng dụng (RAD)
 Phương pháp phát triển theo các pha
 Phương pháp xây dựng nguyên mẫu (prototyping)
Thông thường (regular)
 Loại bỏ (throwaway)
• Phương pháp phát triển rất nhanh (Agile

development)
XP (extreme programming)
1.3.1 Thiết kế cấu trúc

• Dự án sẽ tiến triển từ bước này sang bước tiếp
theo một cách có hệ thống
• Thông thường, một bước phải được hoàn thành
trước khi bắt đầu bước tiếp theo

Phương pháp thác nước

Phương pháp thác nước
• Ưu điểm:
 Trước khi lập trình thì các yêu cầu về hệ thống được
xác định rất chi tiết và đầy đủ => giảm thiểu được sự
thay đổi về yêu cầu trong quá trình phát triển hệ thống
• Nhược điểm:
 Thời gian từ khi đề xuất dự án đến khi có sản phẩm cuối
cùng thường rất dài (vài tháng -> vài năm)

Phương pháp phát triển song song
1.3.2 RAD
• Các nhân tố quan trọng:
 Công cụ CASE
 JAD
 Ngôn ngữ lập trình thế hệ thứ tư/ visual
 Công cụ tạo mã
1.3.2 RAD
Phương pháp phát triển theo pha
© DHBK 2007 1.3.2 RAD 20/Chapter
Phương pháp xây dựng nguyên mẫu thông

thường
1.3.2 RAD
Phương pháp xây dựng nguyên mẫu loại bỏ
1.3.3 Lựa chọn phương pháp phù hợp

• Tiêu chí:
 Độ rõ ràng, đầy đủ của các yêu cầu của người sử dụng
 Khả năng, mức độ thành thạo về công nghệ
 Độ phức tạp của hệ thống
 Độ tin cậy của hệ thống
 Quỹ thời gian
1.3.3 Lựa chọn phương pháp phù hợp

Chương 2: Giới thiệu về phân tích và

thiết kế hướng đối tượng với UML
2.1 Giới thiệu
2.2 Các đặc điểm cơ bản của hệ thống hướng đối
tượng
2.3 UML 2.0
2.4 Phân tích và thiết kế hướng đối tượng với UML
2.0
2.1 Giới thiệu

• Lịch sử phát triển của ngôn ngữ lập trình:
 First Generation (1954 – 1958)
Fortran I
 Second Generation (1959 – 1961)
Fortran II, Algol, Cobol
 Third Generation (1962 – 1970)
PL/I, Pascal
 Object Oriented Languages
Smalltalk, C++, Java
2.1 Giới thiệu

• Lịch sử phát triển của UML
2.1 Giới thiệu

• Lịch sử phát triển của UML
2003
UML 2.0
UML
UML 1.4.1
1.4.1
2002
2001
UML
UML 1.4
1.4 (action
(action semantics)
semantics)
1998
UML
UML 1.3
1.3 (extensibility)
(extensibility)
1997
UML 1.1 (OMG Standard)

1996
Rumbaugh Booch Jacobson
Foundations
Foundations ofof OO
OO (Nygaard,
(Nygaard, Goldberg,
Goldberg, Meyer,
Meyer,
Stroustrup,
Stroustrup, Harel,
Harel, Wirfs-Brock,
Wirfs-Brock, Reenskaug,…)
Reenskaug,…)
1967
2.1 Giới thiệu

• Thiết kế cấu trúc và thiết kế hướng đối tượng
2.1 Giới thiệu

• Thiết kế cấu trúc và thiết kế hướng đối tượng
2.2 Các đặc điểm cơ bản của hệ thống

hướng đối tượng
2.2.1 Lớp và đối tượng
2.2.2 Phương thức và message
2.2.3 Tóm lược và ẩn thông tin (Encapsulation and
Information Hiding)
2.2.4 Thừa kế (inheritance)
2.2.5 Đa hình thái và liên kết động (Polymorphism
and Dynamic Binding)

• Lớp (Class) – Template to define specific
instances or objects
• Đối tượng (Object) – Instantiation of a class
• Thuộc tính (Attributes) – Describes the object
• Chức năng (Behaviors) – specify what object can
do

1 class Time {
2 public:
3 Time();
4 void setTime( int, int, int );
5 void printMilitary();
6 void printStandard();
7 private:
8 int hour; // 0 - 23
9 int minute; // 0 - 59
10 int second; // 0 - 59
11 };

• Phương thức (Methods) implement an object’s behavior
 Analogous to a function or procedure
• Messages are sent to trigger methods
 Procedure call from one object to the next

2.2.3 Tóm lược và ẩn thông tin

• Encapsulation
 combination of data and process into an entity
• Information Hiding
 Only the information required to use a software module
is published to the user
2.2.4 Thừa kế
• Superclasses or general classes are at the top of a
hierarchy of classes
• Subclasses or specific classes are at the bottom
• Subclasses inherit attributes and methods from
classes higher in the hierarchy
2.2.4 Thừa kế
2.2.4 Thừa kế
2.2.5 Đa hình thái và liên kết động

• Polymorphism
 A message can be interpreted differently by different
classes of objects
• Dynamic Binding
 Sometimes called late binding
 Delays typing or choosing a method for an object until
run-time
• Static Binding
 Type of object determined at compile time
2.2.5 Đa hình thái và liên kết động

1 // Fig. 20.1: shape.h
2 // Definition of abstract base class Shape
3 #ifndef SHAPE_H
4 #define SHAPE_H
5
6 class Shape {
7 public:
8 virtual double area() const { return 0.0; }
9 virtual double volume() const { return 0.0; }
10
11 // pure virtual functions overridden in derived classes
12 virtual void printShapeName() const = 0;
13 virtual void print() const = 0;
14 };
15
16 #endif
17 // Fig. 20.1: point1.h
18 // Definition of class Point
19 #ifndef POINT1_H
20 #define POINT1_H
21
22 #include <iostream>
23
24 using std::cout;
25
26 #include "shape.h"
27
28 class Point : public Shape {
29 public:
30 Point( int = 0, int = 0 ); // default constructor
31 void setPoint( int, int );
32 int getX() const { return x; }
33 int getY() const { return y; }
34 virtual void printShapeName() const { cout << "Point: "; }
35 virtual void print() const;
36 private:
37 int x, y; // x and y coordinates of Point
38 };
39
40 #endif
41 // Fig. 20.1: point1.cpp
42 // Member function definitions for class Point
43 #include "point1.h"
44
45 Point::Point( int a, int b ) { setPoint( a, b ); }
46
47 void Point::setPoint( int a, int b )
48 {
49 x = a;
50 y = b;
51 }
52
53 void Point::print() const
54 { cout << '[' << x << ", " << y << ']'; }
55 // Fig. 20.1: circle1.h
56 // Definition of class Circle
57 #ifndef CIRCLE1_H
58 #define CIRCLE1_H
60
61 class Circle : public Point {
62 public:
63 // default constructor
64 Circle( double r = 0.0, int x = 0, int y = 0 );
65
66 void setRadius( double );
67 double getRadius() const;
68 virtual double area() const;
69 virtual void printShapeName() const { cout << "Circle: "; }
71 private:
72 double radius; // radius of Circle
73 };
74
75 #endif
76 // Fig. 20.1: circle1.cpp
77 // Member function definitions for class Circle
79
80 using std::cout;
81
82 #include "circle1.h"
83
84 Circle::Circle( double r, int a, int b )
85 : Point( a, b ) // call base-class constructor
86 { setRadius( r ); }
87
88 void Circle::setRadius( double r ) { radius = r > 0 ? r : 0; }
89
90 double Circle::getRadius() const { return radius; }
91
92 double Circle::area() const
93 { return 3.14159 * radius * radius; }
94
95 void Circle::print() const
96 {
97 Point::print();
98 cout << "; Radius = " << radius;
99 }
100 // Fig. 20.1: cylindr1.h
101 // Definition of class Cylinder
102 #ifndef CYLINDR1_H
103 #define CYLINDR1_H
105
106 class Cylinder : public Circle {
107 public:
108 // default constructor
109 Cylinder( double h = 0.0, double r = 0.0,
110 int x = 0, int y = 0 );
111
112 void setHeight( double );
113 double getHeight();
114 virtual double area() const;
115 virtual double volume() const;
116 virtual void printShapeName() const { cout << "Cylinder: "; }
118 private:
119 double height; // height of Cylinder
120 };
121
122 #endif
123 // Fig. 20.1: cylindr1.cpp
124 // Member and friend function definitions for class Cylinder
126
127 using std::cout;
128
129 #include "cylindr1.h"
130
131 Cylinder::Cylinder( double h, double r, int x, int y )
132 : Circle( r, x, y ) // call base-class constructor
133 { setHeight( h ); }
134
135 void Cylinder::setHeight( double h )
136 { height = h > 0 ? h : 0; }
137
138 double Cylinder::getHeight() { return height; }
139
140 double Cylinder::area() const
141 {
142 // surface area of Cylinder
143 return 2 * Circle::area() +
144 2 * 3.14159 * getRadius() * height;
145 }
146
147 double Cylinder::volume() const
148 { return Circle::area() * height; }
149
150 void Cylinder::print() const
151 {
152 Circle::print();
153 cout << "; Height = " << height;
154 }
155 // Fig. 20.1: fig20_01.cpp
156 // Driver for shape, point, circle, cylinder hierarchy
158
159 using std::cout;
160 using std::endl;
161
162 #include <iomanip>
163
164 using std::ios;
165 using std::setiosflags;
166 using std::setprecision;
167
168 #include "shape.h"
171 #include "cylindr1.h"
172
173 void virtualViaPointer( const Shape * );
174 void virtualViaReference( const Shape & );
175
176 int main()
177 {
178 cout << setiosflags( ios::fixed | ios::showpoint )
179 << setprecision( 2 );
180
181 Point point( 7, 11 ); // create a Point
182 Circle circle( 3.5, 22, 8 ); // create a Circle
183 Cylinder cylinder( 10, 3.3, 10, 10 ); // create a Cylinder
184
185 point.printShapeName(); // static binding
186 point.print(); // static binding
187 cout << '\n';
188
189 circle.printShapeName(); // static binding
190 circle.print(); // static binding
191 cout << '\n';
192
193 cylinder.printShapeName(); // static binding
194 cylinder.print(); // static binding
195 cout << "\n\n";
196
197 Shape *arrayOfShapes[ 3 ]; // array of base-class pointers
198
199 // aim arrayOfShapes[0] at derived-class Point object
200 arrayOfShapes[ 0 ] = &point;
201
202 // aim arrayOfShapes[1] at derived-class Circle object
203 arrayOfShapes[ 1 ] = &circle;
204
205 // aim arrayOfShapes[2] at derived-class Cylinder object
206 arrayOfShapes[ 2 ] = &cylinder;
207
208 // Loop through arrayOfShapes and call virtualViaPointer
209 // to print the shape name, attributes, area, and volume
210
211
2. Function calls
// of each object using dynamic binding.
cout << "Virtual function calls made off "
212 << "base-class pointers\n";
213
214 for ( int i = 0; i < 3; i++ )
215 virtualViaPointer( arrayOfShapes[ i ] );
216
217 // Loop through arrayOfShapes and call virtualViaReference
218 // to print the shape name, attributes, area, and volume
219 // of each object using dynamic binding.
220 cout << "Virtual function calls made off "
221 << "base-class references\n";
222
223 for ( int j = 0; j < 3; j++ )
224 virtualViaReference( *arrayOfShapes[ j ] );
225
226 return 0;
227 }
228
229 // Make virtual function calls off a base-class pointer
230 // using dynamic binding.
231 void virtualViaPointer( const Shape *baseClassPtr )
232 {
233 baseClassPtr->printShapeName();
234 baseClassPtr->print();
235 cout << "\nArea = " << baseClassPtr->area()
236 << "\nVolume = " << baseClassPtr->volume() << "\n\n";
237 }
238
239 // Make virtual function calls off a base-class reference
240 // using dynamic binding.
241 void virtualViaReference( const Shape &baseClassRef )
242 {
243 baseClassRef.printShapeName();
244 baseClassRef.print();
245 cout << "\nArea = " << baseClassRef.area()
246 << "\nVolume = " << baseClassRef.volume() << "\n\n";
247 }
2.3 UML 2.0

2.3.1 Giới thiệu UML
2.3.2 Biểu đồ cấu trúc
2.3.3 Biểu đồ chức năng
2.3.4 Các cơ chế mở rộng
2.3.5 Tóm tắt
2.3.1 Giới thiệu về UML

"The Unified Modeling Language (UML) is a graphical
language for visualizing, specifying, constructing, and
documenting the artifacts of a software-intensive
system.”
Grady Booch, Ivar Jacobsen, Jim Rumbaugh
Rational Software
• UML chỉ đơn thuần là ngôn ngữ đồ hoạ để mô hình

hoá chứ không phải là phương pháp để phát triển hệ
thống
2.3.1 Giới thiệu về UML

• UML 2.0 cung cấp 14 biểu đồ để mô hình hoá cấu
trúc và chức năng của hệ thống, chia làm 2 nhóm:
 Biểu đồ mô hình cấu trúc
 Biểu đồ mô hình chức năng

• 6 loại biểu đồ cấu trúc:
 Biểu đồ lớp (Class)
 Biểu đồ đối tượng (Object)
 Biểu đồ gói (package)
 Biểu đồ triển khai (Deployment)
 Biểu đồ thành phần (Component)
 Biểu đồ cấu trúc phức hợp (Composite structure
diagrams)

• Biểu đồ lớp (class diagram)
 Biểu diễn mối quan hệ giữa các lớp

• Biểu đồ đối tượng (object diagram)
 Biểu diễn mối quan hệ giữa các đối tượng

• Biểu đồ gói (package diagram)
 Biểu đồ gói gộp các thành phần khác nhau của UML (ví dụ: lớp) để
tạo thành thành phần lớn hơn

• Biểu đồ triển khai (deployment diagram)
 Biểu diễn cấu trúc phần cứng và các thành phần phần mềm của hệ
thống

• Biểu đồ thành phần (component diagram)
 Biểu diễn quan hệ giữa các thành phần của hệ thống

• Biểu đồ cấu trúc phức hợp (composite structure diagram)
 Minh hoạ chi tiết cấu trúc bên trong của một lớp

• 8 loại biểu đồ chức năng
 Biểu đồ hoạt động (activity diagram)
 Biểu đồ tương tác (interaction diagrams)
Biểu đồ chuỗi tuần tự (sequence diagram)
Biểu đồ cộng tác (communication/collaboration diagram)
Biểu đồ khát quát tương tác (interaction overview diagram)
Biểu đồ thời gian (timing diagram)
 Biểu đồ máy trạng thái (state machines)
Máy trạng thái chức năng (behavior state machines)
Máy trạng thái giao thức (protocol state machines)
 Biểu đồ ca sử dụng (use case diagram)

• Biểu đồ hoạt động (activity
diagram)
 Được dùng để mô tả luồng
công việc của hệ thống hoặc
luồng hoạt động trong một
ca sử dụng hoặc mô tả thiết
kế chi tiết của một phương
thức (method)

• Biểu đồ chuỗi tuần tự (sequence diagram)
 Mô tả các hoạt động của các đối tượng trong một ca sử dụng dựa
vào thứ tự xuất hiện theo thời gian

• Biểu đồ cộng tác (collaboration diagram)
 Là cách biểu diễn khác của biểu đồ chuỗi tuần tự nhưng tập trung
vào mối quan hệ và giao tiếp giữa các đối tượng

• Biểu đồ khát quát tương tác (interaction overview diagram)
 Được dùng để mô tả tương tác giữa các đối tượng trong các ca sử
dụng phức tạp
 Ít được sử dụng
• Biểu đồ thời gian (timing diagram)
 Được dùng để mô tả tương tác giữa các đối tượng theo thời gian.
Chủ yếu được dùng để mô tả sự thay đối trạng thái của đối tượng
khi có tác động của một sự kiện theo thời gian.
 Được dùng để phát triển các hệ thống thời gian thực và hệ thống
nhúng

• Biểu đồ máy trạng thái chức năng (behavior state
machines)
 Được dùng để mô tả các trạng thái khác nhau mà các đối tượng
của một lớp có thể có trong thời gian tồn tại của chúng.

• Biểu đồ máy trạng thái giao thức (protocol state machines)
 Được dùng để mô tả giao thức giữa các lớp
 Ví dụ: open database -> Query or update
• Biểu đồ ca sử dụng (use case diagram)
 Được dùng để mô tả tương tác giữa một hệ thống với người sử
dụng hoặc với các hệ thống khác có tương tác với nó.
 Là công cụ để mô tả các yêu cầu của hệ thống
 Là một trong những công cụ quan trọng nhất trong phân tích và
thiết kế hướng đối tượng




• Ràng buộc (constraints)
 Dùng để biểu diễn ràng buộc và các quan hệ mà không thể biểu
diễn được bằng UML
 Ràng buộc được đặt trong ngoặc { }

• Nhãn:giá trị (tagged values)
 Là một cặp chuỗi ký tự: nhãn (tag) và giá trị (value) được dùng để
bổ sung thông tin cho một phần tử nào đó (lớp, đối tượng, quan hệ
…)
 Nhãn và giá trị được đặt trong ngoặc { }

• Khuôn mẫu (stereotype)
 Cho phép mở rộng UML bằng cách sử dụng các phần tử mô hình
hoá đã có sẵn trong UML
 Khuôn mẫu có thể sử dụng ràng buộc và tagged values
 Khuôn mẫu được đặt trong dấu << >>
2.3.5 Tóm tắt

2.4 Phân tích và thiết kế hướng đối

tượng với UML 2.0
2.4.1 Đặc điểm cơ bản của OOAD
2.4.2 Ưu điểm của OOAD
2.4.3 The Unified Process
2.4.4 The MOOSAD
2.4.1 Đặc điểm cơ bản của OOAD

• Use-case driven
• Architecture Centric
• Cấu trúc phần mềm quyết định việc mô tả, xây dựng và
viết tài liệu hệ thống
• 3 dạng cấu trúc của một hệ thống:
• Chức năng (functional view): chức năng bên ngoài của hệ thống
từ góc nhìn của người sử dụng : biểu đồ ca sử dụng, biểu đồ
hoạt động
• Cấu trúc tĩnh (static view): lớp, thuộc tính, phương thức, quan
hệ
• Cấu trúc động (dynamic view): chức năng bên trong của hệ
thống: biểu đồ máy trạng thái chức năng
• Iterative and Incremental


• Việc chia nhỏ một hệ thống lớn thành các module
sẽ giúp cho việc giải quyết vấn đề dễ dàng hơn, dễ
chia sẻ giữa các thành viên của dự án và dễ dàng
trao đổi với người dùng về các yêu cầu của hệ
thống
• Dễ dàng sử dụng lại các module trong các dự án
khác
• Tư duy suy nghĩ về đối tượng gần gũi với thực tế

2.4.3 The Unified process

• Unified process là một phương pháp phát triển hệ
thống trong đó quy định khi nào thì sử dụng các
kỹ thuật UML và sử dụng chúng như thế nào trong
quá trình phân tích và thiết kế hệ thống.
 Tác giả: Booch, Jacobsen, Rumbaugh
 Là phương pháp hướng đối tượng
 Không phải là một quy trình phát triển phần mềm hoàn
thiện
Không xét đến các vấn đề về phân bổ nhân lực, ngân quỹ, quản
lý hợp đồng
Không quy định về các hoạt động bảo trì hay hỗ trợ khách hàng
Không xét đến các vấn đề tương tác giữa các dự án


• Pha khởi tạo (Inception): giống như pha lập kế
hoạch
 Các bước liên quan:
 Mô hình hoá giá trị kinh doanh của hệ thống (business modeling) *
 Xác định yêu cầu (requirements)*
 Phân tích (analysis)*
 Thiết kế (design)
 Thực hiện (implementation)
 Kiểm tra (test)
 Môi trường phát triển (environment)*
 Kết quả:
 Phạm vi của dự án
 Các yêu cầu và ràng buộc quan trọng
 Kế hoạch dự án bước đầu
 Miêu tả tính khả thi và rủi ro của dự án
 Lựa chọn môi trường cần thiết để phát triển hệ thống

• Pha phát triển (elaboration): hoàn thiện mô hình
kinh doanh, đánh giá lại rủi ro và hoàn thiện kế
hoạch dự án
 Thu thập yêu cầu (requirements)
 Phân tích (analysis)*
 Thiết kế (design)*
 Triển khai (deployment)
 Quản lý cấu hình và thay đổi (configuration and change management)
 Kết quả:
 Biểu đồ cấu trúc và chức năng UML
 Phiên bản hoạt động đầu tiên của hệ thống

• Pha xây dựng (construction): tập trung chủ yếu
vào lập trình
 Phân tích (analysis)
 Thực hiện (implementation)*
 Triển khai (deployment)
 Quản lý cấu hình và thay đổi (configuration and change management)*
 Kết quả:
Phiên bản beta của hệ thống

• Pha chuyển tiếp (transition): tập trung chủ yếu vào
kiểm tra và triển khai
 Phân tích (analysis)
 Kiểm tra (test)*
 Triển khai (deployment)*
 Quản lý cấu hình và thay đổi (configuration and change management)*
 Kết quả:
Phiên bản cuối cùng (release) của hệ thống
Hướng dẫn sử dụng
Kế hoạch hỗ trợ khách hàng, kế hoạch nâng cấp hệ thống

• Các bước kỹ thuật (Engineering workflows)
1. Mô hình hoá giá trị kinh doanh (business modeling)
 Diễn ra chủ yếu trong pha khởi tạo
 Phát hiện vấn đề và xác định các dự án tiềm năng
 Xác định giá trị kinh doanh mà dự án đem lại
 Thu thập dữ liệu và mô hình hoá ca sử dụng có thể được sử
dụng
2. Xác định yêu cầu (requirements)
 Xác định yêu cầu về chức năng và cả không chức năng
 Yêu cầu được thu thập từ người sử dụng, người quản lý người
sử dụng, khách hàng
3. Phân tích
 Xây dựng biểu đồ cấu trúc và chức năng sử dụng UML
 Xác định các lớp có thể sử dụng lại
 Bước phân tích có thể được sử dụng lại bất kỳ lúc nào trong chu trình
phát triển hệ thống

• Các bước kỹ thuật (Engineering workflows)
4. Thiết kế
 Chuyển từ mô hình phân tích sang mô hình thiết kế
 Thiết kế giao diện, cơ sở dữ liệu, cấu trúc vật lý của hệ thống, thiết kế
chi tiết các lớp
5. Thực hiện (implementation)
 Lập trình: viết các lớp, chương trình và sử dụng các lớp trong thư
viện
 Tích hợp các module
6. Kiểm tra (Test)
 Kiểm tra tích hợp hệ thống, chức năng, kiểm tra khả năng chấp nhận
của người sử dụng …
 Việc kiểm tra đuợc tiến hành trong suốt quá trình phát triển của hệ
thống
7. Triển khai (deployment)
 Đóng gói phần mềm, phân phối, cài đặt và beta testing

• Các bước hỗ trợ (Supporting workflows)
1. Quản lý dự án (project management)
 Diễn ra trong suốt quá trình phát triển hệ thống
 Xác định và quản lý rủi ro
 Quản lý phạm vi dự án
 Quản lý về thời gian, chi phí…
2. Quản lý cấu hình và thay đổi (configuration and
change management )
 Theo dõi và quản lý trạng thái và các phiên bản của hệ thống
 Quản lý việc thay đổi các phiên bản (người thay đổi, thời gian
thay đổi…)
3. Quản lý môi trường phát triển (environment)
 Quản lý các công cụ và môi trường phát triển cần thiết cho dự
án
 Ví du: Rational Rose, Microsoft project, Microsoft Visual C++
2.4.4 MOOSAD
Chương 3. Lập kế hoạch

3.1 Khởi tạo dự án (Project initiation)
3.2 Quản lý dự án (Project Management)
3.1 Khởi tạo dự án

3.1.1 Giới thiệu
3.1.2 Yêu cầu hệ thống (system request)
3.1.3 Phân tích tính khả thi (feasibility analysis)
3.1.4 Lựa chọn dự án
Tài liệu
Nhu cầu kinh doanh Hội đồng duyệt dự án
yêu cầu hệ thống
Project sponsor
Yes No
Phân tích tính khả thi
Project sponsor + analyst
Yêu cầu hệ thống

đã chỉnh sửa
Hội đồng duyệt dự án


• Hội đồng duyệt dự án (approval committee)
 Hội đồng chuyên trách họp thường kỳ (vd. 3 tháng 1
lần)
 1 đơn vị chức năng hoặc cá nhân có thẩm quyền (vd.
phòng quản lý dự án, giám đốc)

• Tài liệu yêu cầu hệ thống gồm 5 thành phần:
 Chủ nhiệm dự án (project sponsor)
 Nhu cầu kinh doanh (business need)
 Yêu cầu kinh doanh (business requirements)
 Các giá trị kinh doanh ( business values)
 Các vấn đề đặc biệt (special issues)

• Chủ nhiệm dự án (project sponsor)
 Người thuộc phòng kinh doanh
 Người thuộc phòng IT có thể là chủ nhiệm hoặc đồng chủ nhiệm
dự án
 CIO, CEO
• Nhu cầu kinh doanh (business need): why?
 Xuất phát từ:
 Phòng kinh doanh
 Phòng IT
 Chuyên gia tư vấn bên ngoài
 Phát sinh khi:
 1 chiến dịch kinh doanh mới cần được hỗ trợ
 cần tìm kiếm thêm khách hàng
 cần cải thiện việc trao đổi với nhà phân phối
 việc kinh doanh của công ty có vấn đề: cổ phiếu giảm, hỗ trợ khách
hàng kém, bị cạnh tranh
 công nghệ mới nhiều tiềm năng xuất hiện

• Yêu cầu kinh doanh (business requirement)
 Hệ thống sẽ làm gì
 Các chức năng của hệ thống
• Giá trị kinh doanh (business values)
 Giá trị hữu hình: ví dụ: 20 % giảm về chi phí
 Giá trị vô hình: ví dụ: cải thiện chất lượng dịch vụ khách
hàng, cải thiện vị trí cạnh tranh
• Các vấn đề đặc biệt
 ví dụ: thời hạn hoàn thành
Case study: CD selections

• Giới thiệu chung về công ty CD selections:
 50 cửa hàng băng đĩa ca nhạc ở California
 Doanh số bán hàng: 50 triệu USD
 Tăng trưởng 3-5 % / năm
 Có website cung cấp các thông tin cơ bản về công ty
như chỉ dẫn đường đi đến, giờ mở cửa, địa chỉ liên hệ
• Margaret Mooney, phó chủ tịch phụ trách thị
trường có ý tưởng bán CD trên mạng Internet
Case study: CD selections

3.1.3 Phân tích tính khả thi

• Khả thi về kỹ thuật (technical feasibility)
• Khả thi về kinh tế (economic feasibility)
• Khả thi về mặt tổ chức (organizational feasibility)

• Khả thi về kỹ thuật (technical feasibility) (can we
build it ?)
 Mức độ quen thuộc với ứng dụng
 Mức độ quen thuộc với công nghệ
 Kích thước của dự án:
Số lượng người tham dự
thời gian
độ phức tạp của hệ thống
 Sự tương thích của hệ thống mới với hệ thống đang tồn
tại
quyết định dựa trên việc so sánh với các dự án trước đó hoặc
tham khảo ý kiến của chuyên gia công nghệ

• Khả thi về kinh tế (economic feasibility) (should we build
it ?)
 Xác định các loại chi phí và lợi nhuận
 Chi phí phát triển hệ thống (1 lần)
 Chi phí vận hành (chi phí thường xuyên)
 Lợi nhuận hữu hình
 Lợi nhuận vô hình


it ?)
 Định lượng các loại chi phí và lợi nhuận
 Cố gắng định lượng các giá trị vô hình

it ?)
 Xác định dòng tiền mặt (cash flow): giá trị chi phí và lợi nhuận
trong khoảng thời gian từ 3-5 năm


it ?)
 Xác định giá trị hiện tại Net present Value (NPV)
 Xác định tỷ lệ hồi vốn (Return on Investment)
 Xác định điểm hoà vốn (break even point)
 Vẽ đồ thị điểm hoà vốn

it ?)

it ?)

it ?)

• Khả thi về tổ chức
 Phân tích đánh giá mức độ hệ thống mới được chấp nhận bởi
người sử dụng và khả năng tích hợp của hệ thống vào trong hệ
thống đang vận hành trong công ty
 2 cách đánh giá:
 Hệ thống mới có cùng định hướng với chiến lược phát triển của công
ty?
 Phân tích ảnh hưởng hoặc bị ảnh hưởng của dự án đối với những
người liên quan
 Người bảo trợ cho dự án
 Người sử dụng hệ thống
 Ban lãnh đạo công ty
• Case study: CD selections

3.1.4 Lựa chọn dự án

• 3 phương án:
 Thông qua
 Loại bỏ
 Xem xét lại
• Phụ thuộc vào:
 ROI, giá trị NPV của lợi nhuận, thời gian hoà vốn
 Số lượng và chất lượng các dự án khác
3.2 Quản lý dự án
3.2.2 Xác định kích thước dự án
3.2.3 Xây dựng và quản lý kế hoạch công việc
3.2.4 Sắp xếp nhân lực cho dự án
3.2.5 Điều phối hoạt động dự án
3.2.6 CD selections

• Project management is the process of planning
and controlling the development of a system
within a specified timeframe at a minimum cost
with the right functionality.
• A project manager has the primary responsibility
for managing the hundreds of tasks and roles that
need to be carefully coordinated.

• 3 nhân tố phụ thuộc lẫn nhau:
 Kích thước hệ thống
 Thời gian hoàn thành dự án
 Chi phí của dự án
• 2 phương pháp ước lượng kích thước dự án
 Phương pháp đơn giản dựa trên chuẩn công nghiệp
 Phương pháp điểm chức năng (function point
approach)

• Phương pháp đơn giản dựa trên chuẩn công
nghiệp
Planning Analysis Design Implementation
Industry
Standard
For Web 15% 20% 35% 30%
Applications
Time
Required 4 5.33 9.33 8
in Person
Months

• Phương pháp điểm chức năng

 Xác định kích thước hệ thống theo điểm chức năng và
số dòng lệnh
1 điểm chức năng là đơn vị đo kích thước chương trình dựa
trên số lượng và độ phức tạp của đầu vào, đầu ra, truy vấn, files
và giao diện chương trình
Tính toán số điểm chức năng
 Liệt kê các thành phần cơ bản của chương trình
 Xác định số lượng mỗi thành phần
 Xác định đô phức tạp của mỗi thành phần (low, med., high)
 Tính tổng số điểm chức năng (TUFP)

Tính toán số điểm chức năng-Bước 1:
Complexity
Description Low Medium High Total
Inputs __x 3 __x 4 __x 6 ____
Outputs __x 4 __x 5 __x 7 ____
Queries __x 3 __x 4 __x 6 ____
Files __x 7 __x 10 __x 15 ____
Program __x 5 __x 7 __x 10 ____

Interfaces
TOTAL UNADJUSTED FUNCTION POINTS ____


Tính toán số điểm chức năng-Ví dụ:

Tính độ phức tạp xử lý hiệu chỉnh (adjusted
processing complexity)-Bước 2

processing complexity)-Bước 2
Adjusted Processing Complexity (APC)
= .65 + (0.01 * Processing Complexity)
Total Adjusted Function Points (TAFP)
= Adjusted Processing Complexity * TUFP


processing complexity)-ví dụ:
Processing Complexity (PC): __7______
Adjusted Processing
Complexity (PCA) = 0.65 + (0.01 * __7_ )
Total Adjusted Function Points (TAFP):

_0.72 * _338_ = 243
(TUFP -- From Step 1)

Tính số dòng lệnh= LOC/Function Code Point x TAFP
Language LOC/Function Code Point

C 130
COBOL 110
JAVA 55
C++ 50
Turbo Pascal 50
Visual Basic 30
PowerBuilder 15
HTML 15
Packages 10-40
(e.g., Access, Excel)
Ví dụ: lập trình dùng C: số dòng lệnh = 243x 130 = 31 590 dòng

số dòng lệnh
 Ước lượng nhân lực (person-months)
Mô hình: COSOMO
Effort = 1.4 * thousands-of-

(in Person- lines-of-code
Months)
Example:
If LOC = 20000 Then...

Effort = (1.4 * 20) = 28 Person

số dòng lệnh
 Ước lượng nhân lực (person-months)
 Ước lượng thời gian thực hiện dự án (months)
Schedule Time (months) = 3.0 * person-months1/3
Ví dụ: dự án 28 person months cần 9 tháng để hoàn thành

3.2.3 Xây dựng và quản lý kế hoạch

công việc
• Xác định các công việc của dự án
• Ước lượng thời gian thực hiện mỗi công việc
• Xác định sự phụ thuộc giữa các công việc
• Xác định ai sẽ làm công việc gì
• Liệt kê các kết quả đạt được của mỗi công việc
( deliverables): ví dụ: báo cáo, bản thiết kế,
phương án thực hiện ...

công việc
• Ví dụ về một bản kế hoạch công việc:
Work Plan Information Example
Name of task Perform economic feasibility

Start date ` Jan 05, 2001
Completion date Jan 19, 2001
Person assigned Mary Smith, sponsor
Deliverable(s) Cost-benefit analysis
Completion status Open
Priority High
Resources needed Spreadsheet
Estimated time 16 hours
Actual time 14.5 hours

công việc
• Xác định các công việc của dự án: 2 phương
pháp
 Phương pháp Top-down
 Xác định các công việc chính trong các pha của dự án
 Lần lượt chia các công việc chính thành các công việc nhỏ
hơn
 Phương pháp chuẩn
 Sử dụng danh sách công việc chuẩn
 Sử dụng danh sách công việc từ các dự án tương tự đã làm

công việc
• Xác định các công việc của dự án dùng phương
pháp Top-down
Phases with
Phases high level steps
Work Plan Deliverables Estimated Assigned

duration To
*
*
*
*

công việc
• Xác định các công việc của dự án dùng phương
pháp Top-down: cấu trúc chia nhỏ công việc
WBS (Work Breakdown Structure)
 Xác định các công việc chính
 Chia mỗi công việc chính thành các công việc nhỏ hơn
 Đánh số công việc và xắp xếp chúng theo cấu trúc
phân tầng
 Có thể thực hiện WBS theo 2 cách:
 Theo các bước của SDLC
 Theo sản phẩm

công việc

công việc
• Biểu đồ Gantt (Gantt Chart): là 1 cách biểu diễn kế
hoạch công việc dựa trên WBS

công việc
• Biểu đồ PERT (PERT= Project Evaluation and
Review Technique )
 Là cách biểu diễn khác của kế hoạch công việc
 Cách tốt nhất để biểu diễn sự phụ thuộc giữa các công
việc và để xác định các pha then chốt
 PERT sử dụng 3 loại giá trị ước lượng thời gian thực
hiện công việc:
Lạc quan: O
Khả năng cao: M (most likely)
Bi quan: P
 Thời gian ước lượng = (O + 4 * M + P)/6

công việc
• Biểu đồ PERT
X: Hoàn thành
\: đang thực hiện

• Xác định số người cho dự án
• Xây dựng kế hoạch nhân sự (staffing plan) liệt kê
các vị trí cần thiết cho dự án
• Xác định cơ cấu tổ chức của dự án
• Chọn người thích hợp vào các vị trí
• Khích lệ, động viên và định hướng cho cả nhóm đi
tới mục tiêu của dự án
• Giải quyết các xung đột có thể xảy ra giữa các
thành viên

Ví dụ về cơ cấu tổ chức của dự án

• Chọn người thích hợp cho từng vị trí:
 2 tiêu chí:
Kỹ năng kỹ thuật (technical skills)
Kỹ năng giao tiếp, ứng xử (interpersonal skills)
Nếu không có sẵn người phù hợp?


• Khích lệ động viên các thành viên trong nhóm:
 Sử dụng tiền thưởng một cách hết sức cẩn trọng
 Sử dụng các khích lệ tinh thần:
Công việc hấp dẫn, thách thức
Tinh thần trách nhiệm
Nhu cầu tiến thủ
Cơ hội để học kỹ năng mới
Nhu cầu tự khẳng định mình
Sự thành cônng

• Chiến lược để giải quyết xung đột:
 Xác định rõ ràng công việc của từng thành viên trong
nhóm
 Lập bảng quy định, nội quy của nhóm
 Dự đoán các ưu tiên khác và khả năng ảnh hưởng của
chúng tới dự án

• Kế hoạch dự án và quản lý dự án phải luôn được cập nhật
trong suốt thời gian dự án vì rất ít khi dự án tiến triển theo
đúng như kế hoạch dự kiến ban đầu:
 Tinh chỉnh các giá trị ước lượng: cập nhật ước lượng
về thời gian và chi phí và điều chỉnh dự án cho phù hợp
với các kết quả ước lượng mới
 Quản lý phạm vi dự án: quản lý hậu quả gây ra do việc
thay đổi yêu cầu hệ thống
 Điều phối dự án: sử dụng công cụ CASE (computer-
aided software engineering), chuẩn, tài liệu để cải thiện
việc trao đổi thông tin và hiệu quả của dự án
 Quản lý rủi ro: đánh giá rủi ro và từ đó có biện pháp tối
thiểu hoá rủi ro

• Tinh chỉnh các giá trị ước lượng
Typical margins of Error for

Well-done Estimates
Phase Deliverable Cost (%) time (%)
Planning System Request 400 60

Project Plan 100 25
Analysis System Proposal 50 15
Design System Specification 25 10


• Quản lý phạm vi dự án (scope management)
 Scope creep: hiện tượng dự án có nguy cơ kéo dài và
tốn chi phí hơn dự kiến
 Nguyên nhân: thêm yêu cầu mới cho hệ thống sau khi
phạm vi của hệ thống đã được giới hạn
 Biện pháp khắc phục:
Cách 1: tăng cường gặp gỡ trao đổi với người sử dụng và xây
dựng nguyên mẫu để tăng tốc việc định rõ các yêu cầu -> giảm
được 5% nguy cơ
Cách 2: sử dụng kỹ thuật hộp thời gian (timeboxing)

• Timeboxing Steps
1. Set the date for system delivery.
2. Prioritize the functionality that needs to be
included in the system.
3. Build the core of the system (the functionality
ranked as most important).
4. Postpone functionality that cannot be provided
within the time frame.
5. Deliver the system with core functionality.
6. Repeat steps 3 through 5, to add refinements
and enhancements.

• Điều phối hoạt động của dự án:
CASE (computer-aided software engineering) tool –
Software that automates all of part of the development
process
Initiation Analysis Design Implementation
Upper CASE Lower CASE
Integrated CASE (I-CASE)


• Điều phối hoạt động của dự án:
• Standardisation: Examples
 Formal rules for naming files
 Forms indicating goals reached
 Programming guidelines and Coding standard
• Documentation
 Project binder: all deliverables and all the internal
communications within a project
 Table of contents
 Continual updating

• Quản lý rủi ro:
 Risk assessment: a document assesses a potential risk
including:
Risk No and its brief description
Likelihood of risk
Potential impact on the project
 Ways to address the risk
 Actions to reduce risk
 Revised assessment

• Quản lý rủi ro:
 Avoiding Classic Planning Mistakes
Overly optimistic schedule
Failing to monitor schedule
Failing to update schedule
Adding people to a late project
3.2.6 CD selections
Chương 4. Phân tích hệ thống

4.1 Xác định yêu cầu của hệ thống
4.2 Mô hình hoá chức năng
4.3 Mô hình hoá cấu trúc
4.4 Mô hình hoá hoạt động
Chương 4. Phân tích hệ thống
Định nghĩa yêu cầu

của hệ thống
Yêu cầu hệ thống Mô hình chức năng

(system request) Hội đồng duyệt dự án
Mô hình cấu trúc Yes
Thiết kế hệ thống
Mô hình hoạt động
Phân tích khả thi +

Kế hoạch công việc
system proposal
4.1 Xác định yêu cầu của hệ thống

4.1.1 Xác định yêu cầu
4.1.2 Các kỹ thuật phân tích yêu cầu
4.1.3 Các kỹ thuật thu thập yêu cầu
4.1.4 CD selections

• Yêu cầu là gì?
 1 yêu cầu (requirement) diễn tả chức năng hệ thống
phải làm hoặc đặc điểm hệ thống phải có
 Yêu cầu chức năng (functional requirement): là yêu cầu
có liên quan trực tiếp đến hoạt động mà hệ thống phải
làm hoặc thông tin mà hệ thống lưu trữ
 Yêu cầu không chức năng (nonfunctional requirement):
là các yêu cầu về tính chất hoặc thuộc tính mà hệ thống
phải có như khả năng hoạt động, khả năng sử dụng ...
Chức năng
Khả năng hoạt động
An ninh
yêu cầu về văn hoá, chính trị
Yêu cầu không chức năng được dùng
chủ yếu tại bước thiết kế hệ thống

• Tài liệu định nghĩa yêu cầu (requirement
definition):
 Là văn bản liệt kê các yêu cầu chức năng và yêu cầu
không chức năng
 Cung cấp đầu vào cho các bước tiếp theo trong quá
trình phân tích hệ thống cũng như quá trình thiết kế
 Mục đích quan trọng nhất của tài liệu định nghĩa yêu
cầu là định nghĩa phạm vi của hệ thống

• Xây dựng tài liệu định nghĩa yêu cầu
 Xác định các loại yêu cầu chức năng và không chức
năng
 Sử dụng các kỹ thuật thu thập yêu cầu để thu thập
thông tin
 Sử dụng các kỹ thuật phân tích yêu cầu để kiểm tra,
thay đổi và hoàn thiện các yêu cầu thu thập được và xác
định mức độ quan trọng của các yêu cầu



• Phương pháp: người kinh doanh và người phân
tích làm việc cùng nhau để phân tích yêu cầu
• 3 kỹ thuật phân tích yêu cầu:
1. Business process automation (BPA): tự động hoá quá trình
kinh doanh
2. Business process improvement (BPI): cải tiến quá trình kinh
doanh
3. Business process reengineering (BPE)
• 3 bước trong quá trình phân tích yêu cầu:
1. Phân tích tình trạng của hệ thống hiện tại
2. Xác định chính xác những cải tiến có thể thực hiện
3. Xây dựng yêu cầu của hệ thống cần xây dựng

• Business process automation (BPA): tự động hoá
quá trình kinh doanh
 Không làm thay đổi hoạt động hiện tại
 Tự động hoá một số công việc dùng công nghệ máy
tính
 2 kỹ thuật BPA
 Phân tích vấn đề (problem analysis): xác định các vấn đề trong
hệ thống hiện tại và tìm cách giải quyết chúng trong hệ thống
mới
 Phân tích nguyên nhân gốc (root cause analysis): phân tích
nguyên nhân gôc của vấn đề

• Business process improvement (BPI): cải tiến
 Làm thay đổi hoạt động hiện tại
 Cản thiện được hiệu suất và hiệu quả của hệ thống
 Tập trung vào hệ thống mới để cải tiến
 3 hoạt động phân tích:
 Phân tích khoảng thời gian (duration analysis): phân tích chi
tiết thời gian thực hiện một khâu nào đó trong hệ thống hiện
tại và xác định khâu có thể được cải tiến
 Xác định chi phí các hoạt động (activity based costing): xác
định chi phí của từng khâu trong hệ thống hiện tại và xác định
các khâu có chi phí cao nhất và từ đó cải tiến để giảm chi phí
 Nghiên cứu kinh nghiệm bên ngoài (informal benchmarking):
nghiên cứu cách tổ chức kinh doanh của các tổ chức khác để
có thể rút ra được bài học để cải tiến

• Business process reengineering (BPR): thay đổi
 Làm thay đổi cơ bản hoạt động hiện tại
 3 hoạt động phân tích:
 Phân tích kết quả (outcome analysis): tập trung phân tích các
kết quả của hệ thống có đem lại giá trị cho khách hàng. Nhà
phân tích khuyến khích các nhà quản lý dự án đặt mình vào vị
trí của khách hàng và suy nghĩ cẩn thận về những gì mà sản
phẩm và dịch vụ của mình có thể đem đến cho khách hàng.
 Phân tích công nghệ (technology analysis): Xác định danh
sách những công nghệ quan trọng và hấp dẫn từ đó phân tích
khả năng ứng dụng công nghệ vào hoạt động kinh doanh và
lợi ích của việc ứng dụng công nghệ đó
 Loại bỏ hoạt động (activity elimination): nhà phân tích và nhà
quản lý cùng tìm cách loại bỏ các hoạt động trong hoạt động
kinh doanh, phân tích hậu quả cũng như ảnh hưởng của việc
loại bỏ đó

• Lựa chọn kỹ thuật thích hợp, phụ thuộc vào:
 Giá trị kinh doanh tiềm năng (potential business value)
 Chi phí dự án (project cost)
 Phạm vi phân tích (breadth of analysis)
 Rủi ro thất bại

• Lựa chọn kỹ thuật thích hợp

• Phỏng vấn (Interviews)
• Kết hợp phát triển ứng dụng (Joint Application
Development (JAD))
• Điều tra (Questionnaires)
• Phân tích tài liệu (Document analysis)
• Quan sát (Observation)

• Phỏng vấn (Interviews): 5 bước
 Chọn người đựơc phỏng vấn
 Thiết kế câu hỏi phỏng vấn
 Chuẩn bị cho cuộc phỏng vấn
 Thực hiện phỏng vấn
 Thực hiện công việc sau phỏng vấn

• Phỏng vấn (Interviews): Bước 1 Chọn người
đựơc phỏng vấn
 Dựa vào các thông tin cần thu thập
 Chọn người đựơc phỏng vấn ở các vị trí khác nhau để
có thông tin từ nhiều góc độ:
 Người quản lý
 Người sử dụng
 Những người có ảnh hưởng hoặc bị ảnh hưởng bởi hệ thống
mới (stakeholder)

• Phỏng vấn (Interviews): Bước 2 : thiết kế câu hỏi
phỏng vấn, 3 loại câu hỏi:
 Câu hỏi đóng (close ended)
 Câu hỏi mở (open-ended)
 Câu hỏi dò (probing)

phỏng vấn, 3 loại:
Types of Questions Examples
Closed-Ended Questions * How many telephone orders
are received per day?
* How do customers place orders?
* What additional information
would you like the new system
to provide?
Open-Ended Questions * What do you think about the
current system?
* What are some of the problems
you face on a daily basis?
* How do you decide what types of
marketing campaign to run?
* Why?
Probing Questions
* Can you give me an example?
* Can you explain that in a bit
more detail?

phỏng vấn, 2 loại phỏng vấn
 Phỏng vấn không cấu trúc (Unstructured interview)
 Các thông tin chung, khái quát
 Thực hiện tại các bước đầu tiên của dự án
 Phỏng vấn có cấu trúc (Structured interview)
 Các thông tin cụ thể hơn
 Thực hiện tại các bước sau của dự án

phỏng vấn, 2 chiến lược: top-down, bottom up

• Phỏng vấn (Interviews): Bước 3: chuẩn bị cho
cuộc phỏng vấn
 Chuẩn bị kế hoạch phỏng vấn tổng thế
 Liệt kê các câu hỏi
 Dự đoán trước câu trả lời và câu hỏi tiếp theo
 Khẳng định lại lĩnh vực kiến thức
 Xác định các câu hỏi, lĩnh vực ưu tiên trong trường
hợp không đủ thời gian
 Chuẩn bị cho người được phỏng vấn
 Xếp lịch
 Thông báo lý do phỏng vấn
 Thông báo các lĩnh vực thảo luận

• Phỏng vấn (Interviews): Bước 4: thực hiện cuộc
phỏng vấn
 Phải gây được thiện cảm với người được phỏng vấn:
tỏ ra chuyên nghiệp và không thiên vị
 ghi lại tất cả thông tin
 Kiểm tra về chính sách ghi âm cuộc phỏng vấn
 Phải đảm bảo hiểu tất cả các vấn đề và thuật ngữ
 Phân biệt rõ sự kiện với ý kiến bình luận
 Dành thời gian cho người đựơc phỏng vấn đặt câu hỏi
 Nhớ cảm ơn người được phỏng vấn và thông báo
công việc tiếp theo sau cuộc phỏng vấn
 Kết thúc đúng giờ

• Phỏng vấn (Interviews): Bước 4: thực hiện cuộc
phỏng vấn, practical tips
 Don’t worry, be happy
 Pay attention
 Summarize key points
 Be succinct
 Be honest
 Watch body language

• Phỏng vấn (Interviews): Bước 5: Công việc sau
phỏng vấn
 Chuẩn bị báo cáo về cuộc phỏng vấn trong vòng 48
tiếng
 Gửi báo cáo cho người được phỏng vấn để sửa chữa,
bổ sung nếu cần

• Phỏng vấn (Interviews): Bước 5: Công việc sau
phỏng vấn
INTERVIEW REPORT
Interview notes approved by: ____________
Person interviewed ______________

Interviewer _______________
Date _______________
Primary Purpose:
Summary of Interview:
Open Items:
Detailed Notes:

• JAD:
 Allows project managers, users, and developers to
work together to identify requirements
 May reduce scope creep by 50%
 Avoids requirements being too specific or too vague

• JAD: Lựa chọn người tham dự và vai trò từng
người
 Facilitator
 sets the meeting agenda and guides the discussion
 Scribe
 assist the facilitator by recording notes, making copies, etc.
 Project team, users, and management

• JAD: Thiết lập cuộc họp
 U-Shaped seating
 Away from distractions
 Whiteboard/flip chart
 Prototyping tools
 e-JAD

• JAD: phiên họp JAD
 Tend to last 5 to 10 days over a three week period
 Prepare questions as with interviews
 Formal agenda and groundrules
 Facilitator activities
 Keep session on track
 Help with technical terms and jargon
 Record group input
 Help resolve issues
 Post-session follow-up

• JAD: Quản lý vấn đề trong phiên họp JAD
 Reducing domination
 Encouraging non-contributors
 Side discussions
 Agenda merry-go-round
 Violent agreement
 Unresolved conflict
 True conflict
 Use humor

• JAD: Phòng họp

• Điều tra (Questionnaire), các bước:
 Selecting participants
 Using samples of the population
 Designing the questionnaire
 Careful question selection
 Administering the questionnaire
 Working to get good response rate
 Questionnaire follow-up
 Send results to participants

• Điều tra (Questionnaire), thiết kế:
 Begin with non-threatening and interesting questions.
 Group items into logically coherent sections.
 Do not put important items at the very end of the
questionnaire.
 Do not crowd a page with too many items.
 Avoid abbreviations.
 Avoid biased or suggestive items or terms.
 Number questions to avoid confusion.
 Pretest the questionnaire to identify confusing
questions.
 Provide anonymity to respondents.

• Phân tích tài liệu:
 Document analysis is used to provides clues about
existing “as-is” system
 Typical documents used
 Forms
 Reports
 Policy manuals
 Organization chart
 Look for user additions to forms
 Look for unused form elements

• Quan sát:
 Users/managers often don’t remember everything they
do
 Checks validity of information gathered other ways
 Behaviors change when people are watched
 Careful not to ignore periodic activities
 Weekly … Monthly … Annual

• Lựa chọn kỹ thuật thích hợp:
4.1.4 CD selections
Requirement Determination
• Requirement Analysis Techniques
 Select BPI techniques to identify how to improve the
current order process using a new web-based system
 Using several JAD session including store managers,
marketing analysts and Wed developers (the working
group) to work through BPI techniques and brainstorm
 Further apply informal benchmarking with Web-sites of
several leading retailers and discuss with the working
group
 The output is a list of suggested business requirements
for the project team
4.1.4 CD selections
Requirement Determination
• Requirement-gathering Techniques
 The project team applies document analysis, interview and
observation techniques
 Firstly apply document analysis to understand the current order
processes (i.e., the as-is system). If anything is not clear, use
interview to clarify
 Secondly interview senior analysts to get better ideas about as-is
and to-be systems and IT contractor to understand the existing IT
system
 Thirdly observe in stores to see the real working process of as-is
system
• The above activities at the end produces the requirement
definition (report)
• Further JAD sessions are used to finalise and prioritise the
requirement definition (report)
4.2 Mô hình hoá chức năng

(Functional Modeling)
4.2.2 Mô hình quá trình kinh doanh bằng biểu đồ
hoạt động (activity diagrams)
4.2.3 Mô tả ca sử dụng (use case descriptor)
4.2.4 Biểu đồ ca sử dụng
4.2.5 Xây dựng mô tả ca sử dụng và biểu đồ ca sử
dụng
4.2.6 Hiệu chỉnh ước lượng kích thước dự án và
nhân lực sử dụng điểm ca sử dụng
4.2.7 CD Selections

• Bước chuẩn bị : Thu thập các yêu cầu từ người
sử dụng (phần 4.1).
• Bước 1: Sử dụng các yêu cầu thu thập được, mô
hình quá trình kinh doanh sử dụng biểu đồ hoạt
động (activity diagrams)
• Bước 2: Sử dụng các hoạt động đã xác định để
xác định các ca sử dụng.
• Bước 3: Xây dựng bản mô tả ca sử dụng cho mỗi
ca sử dụng
• Bước 4: Chuyển tử bản mô tả ca sử dụng sang
biểu đồ ca sử dụng để biểu diễn chức năng và
hoạt động bên ngoài của quá trình kinh doanh
• -> chuyển sang mô hình hoá cấu trúc (phần 4.3)
4.2.2 Mô hình quá trình kinh doanh bằng biểu

đồ hoạt động (activity diagrams)
• Các phần tử của biểu đồ hoạt động
• Xây dựng biểu đồ hoạt động

• Biểu đồ hoạt động được dùng để mô hình hoá các quá
trình kinh doanh ở mức cao (high level business process)
• Các phần tử của biểu đồ hoạt động
 Hành động (action)
 Là phần tử đơn giản biểu diễn một hoạt động không thể chia nhỏ hơn
 Tên: Động từ + danh từ, ví dụ: Make appointment
 Hoạt động (activity)
 Dùng để biểu diễn tập hợp các hành động Make appointment
 Nốt đối tượng (object node)

 Biểu diễn một đối tượng được kết nối với các luồng đối tượng
 Tên của nốt đối tượng là tên lớp của đối tượng
Class name
 Luồng điều khiển (control flow)
 Biểu diễn chuỗi hoạt động

• Các phần tử của biểu đồ hoạt động (tiếp theo)
 Luồng đối tượng (object flow)
Biểu diễn luồng của 1 đối tượng từ hoạt động này sang hoạt
động khác
 Nốt khởi đầu (initial node)
Biểu diễn điểm bắt đầu của tập hợp các hoạt động
 Nốt kết thúc hoạt động (final activity node)
Kết thúc toàn bộ các luồng điều khiển và luồng đối tượng
 Nốt kết thúc luồng (final flow node)
Kết thúc một luồng điều khiển hoặc luồng đối tượng

 Nốt lựa chọn (decision node)
Biểu diễn việc kiểm tra điều kiện để đảm bảo luồng điều khiển
hoặc luồng đối tượng chỉ đi theo 1 đường
[điều kiện] [điều kiện]
 Nốt gộp (merge node)

Dùng để gộp các nhánh đựơc tạo ra bởi nốt lựa chọn

 Nốt chia (fork node)
Chia hoạt động thành các luồng hoạt động song song
 Nốt kết hợp (join node)

Dùng để kết hợp các luồng hoạt động song song


• Xây dựng biểu đồ hoạt động:
1. Xác định phạm vi và ngữ cảnh của quá trình kinh

doanh rồi đặt cho biểu đồ hoạt động 1 tiêu đề phù hợp
2. Xác định các hoạt động, luồng điều khiển, luồng đối
tượng diễn ra giữa các hoạt động.
3. Xác định các quyết định lựa chọn trong quá trình kinh
doanh
4. Xác định khả năng thực hiện song song của các hoạt
động (nếu có).
5. Vẽ biểu đồ hoạt động

• VD: CD selections
Internet Order System – Functional requirements:
1. Maintain CD Information
1.1…… 1.2….. 1.3…..
2. Maintain CD marketing information
2.1…. 2.2…. 2.3….
3. Place CD Orders
3.1 Search CDs from “CD Selection” web site; 3.2 Place orders;
3.3……
4. Maintain Orders
4.1….. 4.2…
4.3 Place Instore Hold: If ordered CDs are available in a near store,
the CDs are on hold and to be picked up in the store
4.4. Place Special Order: If ordered CDs is not available in a near
store, the ordered CDs will be sent to a near store and email to
the customer when it is available in the near store

Exercise: Create the activity diagram for Internet Order
System
Analysis:
 Main activities: Maintain CD Information, Maintain CD
marketing information, Place CD Orders, Maintain
ordered CDs
 Control flows: Three main parallel processes:
 Maintain CD Information
 Maintain CD marketing information
 Place CD Orders -> Maintain ordered CDs in which a decision
needs to be made related to placing instore hold or placing
special order

Maintain CD
Place CD Maintain CD
marketing
Order Information
information
[If available in near store] [If not]
Place Place
instore hold special order
4.2.3 Mô tả ca sử dụng
• Một ca sử dụng miêu tả các hoạt động do người
sử dụng hoặc các hệ thống khác tác động lên hệ
thống.
• Ca sử dụng là mô hình logic vì chúng miêu tả các
hoạt động của hệ thống mà không miêu tả các
hoạt động đó được thực hiện thế nào.
• Ca sử dụng miêu tả chức năng của hệ thống:
Người sử dụng có thể làm gì
Hệ thống đáp ứng như thế nào
Ca sử dụng miêu tả tương tác giữa người sử dụng và hệ thống

• Ca sử dụng có thể được dùng để mô tả hệ thống
hiện tại và hệ thống cần xây dựng
• 2 bước để xây dựng biểu đồ ca sử dụng
 Viết bản mô tả ca sử dụng
 Chuyển từ bản mô tả ca sử dụng sang biểu đồ ca sử
dụng
• Mỗi một ca sử dụng chỉ miêu tả duy nhất một
chức năng của hệ thống
• Để xác định nội dung của ca sử dụng, người phát
triển hệ thống phải làm việc cùng với người sử
dụng
• Các thành phần của bản mô tả ca sử dụng:
Use Case Name: ID: Importance Level:
Primary Actor: Use Case Type:
Stakeholders and Interests:
Brief Description:
Trigger:
Relationships: (Association, Include, Extend, Generalization)
Normal Flow of Events:
Subflows:
Alternate/Exceptional Flows:
• Ví dụ:
• Ví dụ:
• Ví dụ:
• Guidelines for Creating Use-Case Descriptions
1. Write each step in “SVDPI (subject-verb-direct
object and optionally preposition-indirect object)”
form
Example. “The patient (subject) contacts (verb)
the office (direct object) regarding (preposition)
an appointment (indirect object).
2. Clarify initiator and receivers of action
3. Write from independent observer perspective
4. Write at same level of abstraction
5. Ensure a sensible set of steps
6. Apply KISS (keep it simple, stupid) principle liberally
7. Write repeating instructions after the set of steps to
be repeated.
A Subject
Boundary
An Actor
An associate
relationship
A use case




4.2.5 Xây dựng mô tả ca sử dụng và

Biểu đồ ca sử dụng
• 4 bước chính:
 Bước I. Xác định các ca sử dụng chính
 Bước II. Mở rộng ca sử dụng chính
 Bước III. Khẳng định lại các ca sử dụng chính
 Bước IV. Vẽ biểu đồ ca sử dụng

• Bước I (5 bước nhỏ): Xác định các ca sử dụng
chính
1. Xem lại biểu đồ hoạt động
2. Xác định phạm vi của hệ thống
3. Liệt kê các tác nhân chính (primary actors) và mục đích
của các tác nhân đó
4. Xác định và viết các ca sử dụng chính
5. Xem xét lại cẩn thận các ca sử dụng và sửa đổi nếu
cần

• Bước I: Ví dụ
Review activity diagram of

Internet order System:
Maintain CD
Place CD Maintain CD
marketing
Order Information
information
Maintain
CD Order

• Bước I: Ví dụ
Identify and write the major (overview) use-cases
Use case name Primary Relationship
actor
Association Include Exclude
Maintain marketing Vendor Vendor

information
Maintain CD Distribution Distribution

information system system
Place order Customer Customer Maintain order
Maintain order Customer


• Bước II (5 bước nhỏ): Mở rộng ca sử dụng chính
6. Chọn 1 ca sử dụng chính để mở rộng
7. Điền các chi tiết vào form
8. Điền các bước của luồng sự kiện bình thường (normal
flow of events)
9. Chuẩn hoá kích thước của mỗi bước (nếu bước nào
quá phức tạp hoặc quá dài, chia nhỏ thành các
subflows hoặc đưa thêm ca sử dụng)
10. Miêu tả các bước thay thế hoặc ngoại lệ
(alternate/exceptional)
11. Với mỗi bước thay thế hoặc ngoại lệ, miêu tả cách
thức mà tác nhân (actor) và hệ thống đáp ứng

• Bước II: Ví dụ: kết quả sau bước 7




• Bước III (2 bước nhỏ): Khẳng định lại các ca sử
dụng chính
12. Xem xét lại các ca sử dụng, sửa lại nếu cần
 Xem xét lại cú pháp và ngữ nghĩa
 Làm việc cùng với người sử dụng
13. Lặp lại 12 bước cho đến khi tất cả các ca sử dụng
được xác định

• Bước IV (4 bước nhỏ): Vẽ biểu đồ ca sử dụng
1. Vẽ gianh giới của hệ thống
2. Vẽ các ca sử dụng (vẽ theo thứ tự dễ nhìn)
3. Vẽ các tác nhân
4. Vẽ các quan hệ
 Exercise: Draw use-case diagram
 Question. Suppose that 7 major use cases have been identified as
below, draw the corresponding use-case diagram
Use case name Primary actor Relationship
Association Include Extend

Maintain marketing Vendor Vendor
information
Maintain CD Distribution Distribution system

information system
Place order Customer Customer Check out
Maintain
order
Check out Customer Customer, Credit Maintain

Centre order
Maintain order Customer Place Instore hold
Place special order
Place Instore hold Customer Store
Place special order Customer Store

Maintain CD
marketing information
Place CD
<<include>>
<<actor>> order
Credit
Card Check out
Centre
<<include>>
Maintain CD Place instore hold

order <<actor>>
<< extend >>
Store
Place special order
<<actor>>
Distribution Maintain CD
System information
4.3 Mô hình hoá cấu trúc

4.3.2 Các phần tử của mô hình cấu trúc
4.3.3 Thẻ CRC (Class-Responsibility-Collaboration)
4.3.4 Biểu đồ lớp
4.3.5 Xây dựng thẻ CRC và biểu đồ lớp

Mục đích của mô hình cấu trúc:
• Mô tả cấu trúc của dữ liệu được sử dụng trong hệ
thống.
• Rút ngắn khoảng cách giữa thế giới thực và thế
giới phần mềm
• Xây dựng thuật ngữ chung cho người sử dụng và
người phân tích hệ thống
• Biểu diễn sự vật, ý tưởng và khái niệm quan trọng
trong hệ thống
Các mô hình cấu trúc:
• CRC cards, class diagrams, object diagrams.

• Lớp (Classes)
 Kiểu dữ liệu để định nghĩa đối tượng (Templates for
creating instances or objects)
 Cụ thể (Concrete)
 Trừu tượng (Abstract)
• Thuộc tính (Attributes)
 Đơn vị thông tin liên quan đến việc miêu tả lớp
 Chỉ nên đưa vào các thuộc tính quan trọng
 Các thuộc tính phải có kiểu cơ bản: nguyên, xâu, ngày,
tháng, boolean ….
 Các thuộc tính phức tạp đựơc biểu diễn bằng quan hệ
(relationship) giữa các lớp

• Hoạt động (Operations)
 Hành động mà đối tượng có thể thực hiện
 Tại bước phân tích này, chỉ tập trung vào các hoạt động
liên quan trực tiếp đến vấn đề cần mô hình hoá
 Sau này, hoạt động sẽ được chuyển đổi sang phương
thức (methods)
• Quan hệ (Relationships)
 Tổng quát hóa (Generalization)
Cho phép kế thừa thuộc tính và hoạt động
a-kind-of (e.g. secretary is a kind of employee)
 Tổng thể (Aggregation)
Kết nối giữa bộ phận với tổng thể
a-part-of ( e.g. a door is a part of a car) hoặc has part
 Kết hợp (Association)
Các quan hệ khác giữa các lớp
4.3.3 Thẻ CRC (Class-Responsibility-

Collaboration)
• Trách nhiệm (responsibility) và hợp tác
(collaboration)
 Trách nhiệm
Đối tượng của một lớp phải có trách nhiệm:
 biết giá trị các thuộc tính và các quan hệ của nó
 thực hiện hoạt động của nó
 Hợp tác
Các đối tượng hợp tác với nhau để thực hiện một công việc
Mô hình Client-server-contract
• Thẻ CRC được dùng để miêu tả các phần tử cơ

bản của một lớp

Collaboration)

Collaboration)


• Cú pháp:
A CLASS Class 1
-attribute
+operation ()
AN ATTRIBUTE Attribute name/

derived attribute name
AN OPERATION
operation name ()
AN ASSOCIATION
1..* 0..1
______verb phrase____

• Thuộc tính:
 Derived attributes
/age, for example can be calculated from birth date and current
date
 Visibility
Public: +
Protected: #
Private: -

• Hoạt động (operations):
 Constructor
Creates object
 Query
Makes information about state available
 Update
Changes values of some or all attributes

• Quan hệ:
 Multiplicity of relationship
exactly one: 1
zero or more: 0..*
one or more: 1..*
zero or one: 0..1
specified range: 2..4
multiple disjoint ranges: 1..5,7

• Biểu đồ đối tượng: cụ thể hóa biểu đồ lớp

Three common approaches
1. Textual analysis of use-case information to create
an initial rough structure model
 Nouns suggest classes
 Verbs suggest operations
 Creates a rough(trạng thái thô ban đầu) first cut
2. Common object list
 Physical or tangible things
 Incidents
 Roles
3. Patterns
 Useful groupings of classes that occur in various
situations

• 1.Create CRC cards by performing textual analysis
on the use-cases.
• 2. Brainstorm additional candidate classes,
attributes, operations, and relationships by using the
common object list approach.
• 3. Role-play each use-case using the CRC cards.
• 4. Create the class diagram based on the CRC
cards.
• 5. Review the class diagrams and structural model
for missing and/or unnecessary classes, attributes,
operations, and relationships.
• 6. Incorporate useful patterns.
• 7. Review the structural model.
CD Selections
Step 1. Create CRC cards by performing

textual analysis on the use-cases
Textual Analysis: Nouns suggest classes

Textual Analysis: Nouns suggest classes
• Textual Analysis Results: Identified potential classes
 Customer
 Search Request
 CD
 CD List
 Review (i.e., CD review information)
If further analyse the Maintain Order and Checkout use
cases, further potential classes will be identified such as
 Order
 Order Item
 Credit card centre
 etc

Textual Analysis: Verbs suggest operations:
• For each identified class, check the related verbs to identify the operations as
well as the relationships with other classes

Textual Analysis: Verbs suggest operations:
• Textual Analysis Result: For Customer Class, the identified operations (i.e.,
Responsibilities) and the relationship with other classes (i.e.,
Collaborators) are
Make Search request Search request

Place Order Order
Get Credit Card Info Credit Card Centre
Exit
Select CD for Info CD List
Not include as it can be included in Search request
This forms the front of “Customer class” CRC Card


• Textual Analysis Result: Combine “nouns and verbs” analysis, the
back of “Customer class” CRC Card can be
Order; Search request; Credit Card Centre

Step 2 and 3. Examine Common Object Lists and

Role-play the CRC Cards
2. Brainstorm additional candidate classes, attributes,

operations, and relationships by using the common
object list approach.
3. Role-play each use-case using the CRC cards.
Possible outcomes: Search request class need having 3

sub-classes: Title Search, Artist Search and Category
Search
Step 4. Create the Class Diagram based on the CRC

Cards
• Exercise. Suppose the CRC card of Customer class is

given as before, create the class diagram based on it.
• For customer class, assume that all attributes are
private type whereas all operations are public type
• For other associate classes, only the class names
and the relationships with the customer class need
to be given
Step 4. Create the Class Diagram based on the CRC

Cards
• Solution:
Credit Card Centre
Order
Customer 0..*
1
-First name
0..* place ->
-Middle initial
Check -> 0..* -Last name
-……
+Make search req()
+Place order()
+Get credit info() Search Reg
+Exit()
0..* 0..*
Make ->
Step 5, 6 and 7: Review Classes Diagrams,

Incorporate Patterns, and Review the Model
5. Review the class diagrams and structural model for any

missing and/or redundancy
6. Incorporate useful patterns.
• One possible pattern
7. Review the structural model.

4.4 Mô hình hoá hoạt động

4.4.2 Biểu đồ tương tác
4.4.3 Biểu đồ máy trạng thái

• Mục đích của mô hình hoạt động:
 Miêu tả cách thức các đối tượng trong mô hình cấu trúc
tương tác với nhau trong mỗi ca sử dụng
 Miêu tả hoạt động bên trong của hệ thống
 Miêu tả ảnh hưởng của các hoạt động tới hệ thống
 Được sử dụng để kiểm tra và thay đổi các mô hình chức
năng và mô hình cấu trúc
• Các loại mô hình hoạt động:
 Biểu đồ tương tác (Interaction Diagrams)
Biểu đồ tuần tự (sequence diagram)
Biểu đồ giao tiếp (cộng tác) (communication diagram)
 Biểu đồ máy trạng thái (Behavioral state machine
diagram)

• Các phần tử cơ bản:
 Đối tượng (Objects)
 1 bản sao của lớp
 Có các thuộc tính miêu tả đối tượng
 Hoạt động (Operations)
Truyền hoặc nhận thông điệp
 Thông điệp (Messages)
 Chỉ thị cho đối tượng thực hiện một hoạt động

• Biểu đồ tuần tự (sequence diagram)
 Miêu tả các đối tượng tham gia vào 1 ca sử dụng
 Biểu diễn các thông điệp được truyền giữa các đối
tượng trong 1 ca sử dụng

• Biểu đồ tuần tự (sequence diagram): ví dụ

• Biểu đồ tuần tự (sequence diagram): Các phần tử

• Biểu đồ tuần tự (sequence diagram): Các phần tử

• 6 bước xây dựng biểu đồ tuần tự
1. Xác định ngữ cảnh của biểu đồ tuần tự
2. Xác định các đối tượng tham gia
3. Xác định đường sống (lifeline) cho mỗi đối tượng
4. Biểu diễn các thông điệp
5. Biểu diễn các điểm xuất hiện hoạt động (execution occurrence)
trên mỗi đường sống của đối tượng
6. Kiểm tra lại biểu đồ
Application
Example:
1. Customer submits a search request to the system.

2. The system provides the customer a list of recommended
CDs.
3. The customer chooses one of the CDs to find additional
information.
4. The system provides the customer with basic (market)
information & CD Reviews
5. The customer calls the maintain order use case.
6. The customer iterates over 3 through 5 until finished
shopping.
7. The customer executes the checkout use case.
8. The customer leaves the website.
Application
Example:

• Biểu đồ giao tiếp (communication diagram)
 Tập trung miêu tả tương tác giữa các đối tượng mà
không tập trung vào miêu tả thời gian và trình tự của
các tương tác

• Biểu đồ giao tiếp : Ví dụ

• Biểu đồ giao tiếp : Các phần tử
Actor
Object
Association
Message

• 5 bước xây dựng biểu đồ giao tiếp
1. Xác định ngữ cảnh
2. Xác định các đối tượng và các liên kết giữa các đối tượng 2
3. Vẽ các đối tượng và liên kết
4. Thêm các thông điệp
5. Kiểm tra lại biểu đồ giao tiếp
Technique to Identify Collaborations between

Objects - “CRUD” Analysis
• What is “CRUD” analysis:

 identifying the processes to Create, Read or Reference, Update or
Delete objects based on use cases
 The process of each user case is represented by “CRUD” matrix: a
class-by-class matrix in which each cell in the matrix represents the
interaction between instances of the classes
“CRUD” Analysis Example
C
C
Application
Example:
1. Customer submits a search request to the system.

2. The system provides the customer a list of recommended
CDs.
3. The customer chooses one of the CDs to find additional
information.
4. The system provides the customer with basic (market)
information & CD Reviews
5. The customer calls the maintain order use case.
6. The customer iterates over 3 through 5 until finished
shopping.
7. The customer executes the checkout use case.
8. The customer leaves the website.
Application
Example:

• Là mô hình động biểu diễn các trạng thái khác
nhau của một đối tượng và các sự kiện làm thay
đổi trạng thái của đối tượng cũng như đáp ứng và
hành động của đối tượng khi chuyển trạng thái.

Ví dụ:

Các phần tử của biều đồ máy trạng thái:

Các phần tử của biều đồ máy trạng thái:
• Transitions: A transition indicates a movement from one state to the next
one, denoted by lines with arrowheads. A transition has a label in the
form of three parts: Event [guard]/activity. All three parts are optional.
 Event or Trigger: the signal event that triggers a potential change of state
 Guard: If presented, is a Boolean condition that must be true in order for the
trigger to cause the transition
 Action or Activity: is some behaviour that has executed during the transition
Event [guard]/activity
state
transition

• 5 bước xây dựng biểu đồ máy trạng thái:
1. Xác định ngữ cảnh
2. Xác định trạng thái bắt đầu, kết thúc và các trạng thái
ổn định của đối tượng
3. Xác định thứ tự của các trạng thái mà đối tượng sẽ trải
qua
4. Xác định các sự kiện, hành động và điều kiện của mỗi
chuyển trạng thái
5. Kiểm tra
Application
Example:
The Life of an Order Object:
Application
Example:
Chương 5. Thiết kế hệ thống

5.1 Chuyển sang thiết kế
5.2 Thiết kế lớp và phương thức
5.3 Thiết kế lớp quản lý dữ liệu
5.4 Thiết kế lớp tương tác người-máy
5.5 Thiết kế lớp kiến trúc vật lý
5.1 Chuyển sang thiết kế

5.1.1 Chuyển từ mô hình phân tích sang mô hình
thiết kế
5.1.2 Gói và Biểu đồ gói
5.1.3 Các chiến lược thiết kế
5.1.4 Xây dựng thiết kế thực tế
5.1.1 Chuyển từ mô hình phân tích sang

mô hình thiết kế
• Factoring:
 Creating modules* that reflect similarities and differences
between units of interest
 Here, module = new class | new method
 New classes can be represented by:-
 Generalization
 Aggregation
 New classes identified by:
Abstraction
e.g. classes for nurse, admin and doctor share attributes and
methods, so “factor our” common attributes and methods,
create new class “employee”, relate employee to nurse,
admin and doctor classes as generalisation (a-kind-of)
relationship – a form of abstraction
Refinement
Identifying additional subclasses (of a higher level class) is a
form of refinement

• Partitions and Collaborations
 Creating subsystems*, i.e. collections (usually sets) of related
components
 In object-oriented designs/implementations the “pattern of
activity”, i.e. messages sent between objects, provides one
basis for partitioning system into (smaller-scale) subsystems
(where subsystem = partition)
 Grouping units that collaborate e.g. as modelled in UML
communications diagram (for each use-case), CRUD analysis,
clients(i.e. objects that are message senders)-servers(i.e. objects
that receivemessages) & contracts (i.e. specifications of
interactions between objects)
 May have collaboration among units (e.g. a class) or partitions
(i.e. collections/sets of classes whose objects send/receive
messages)
 The more messages or contracts between objects, the more
likely they are in the same partition

• Layers
 A system’s environment includes software architecture, user
interface and stored data
 Layer enables useful separation of (related) concerns, e.g.
application logic from user-interface considerations
 Model-view-controller (MVC) architecture
• Models implement application logic
• Views and controllers manage interfaces
• Views = output logic
• Controllers = input logic
• Models = application logic
• Suggested layers now include foundation, physical, HCI, data access and
management, problem domain. n.b. layer constrains kind(s) of classes that
exist “on that layer”
• Foundation = programming language and IDE constructs
• Physical architecture = classes used for communication
• HCI = classes enabling user interaction
• Data access and management = classes for persistence
• Problem domain = classes to be refined into implementable (effective and
efficient)

• Layers
5.1.2 Gói và biểu đồ gói

Package = UML representation
(or abstraction over)
collaboration OR partition OR layer
•Logical grouping of any UML elements
Simplifies (large numbers of) UML diagrams
Groups related elements into a single higher-level element
Packages involving different kinds of construct (e.g. at

particular layers) use different kinds of relationship between
those constructs, i.e. in a class diagram, package = group
(or set) of classes by aggregation or association relationship
• Also need “dependency” relationships between packages
• A UML package diagram can be a class diagram that contains

only package symbols and dependency relationships (dotted
arrows)
• Package symbol is similar to tabbed folder symbol
• Dependency relationship implies change in one package may

require change in dependent package e.g. change in (the
signature) of one method will cause interface for all objects
of this class to change, therefore, all classes that have
objects that send messages to instances of modified class
may need to be modified.
A PACKAGE Package
A DEPENDENCY RELATIONSHIP

Ví dụ

Collaborations, partitions and layers
 Collaborations usually are modelled as packages in UML
 Collaborations usually factored into a set of partitions on a layer
 Partitions can be composed of other partitions (hierarchically hence

forming subsystems)
 Classes can be in partitions, those partitions then contained in other

partitions, placed on a layer
Simple example:- small part of appointments system

Package Diagram of Appointment System
Patient UI
Problem domain
Classes:
dependent on
Patient, Appt.
Patient class
by intermediate DM-Patient class

Data Access and
Manipulation (DM) dependent on
Classes: Patient class
DM-Patient,
DM-Appt Patient table
Separated from
object persistence dependent on
Classes: Patient class
Patient table,
Appt. table
Modularity (information hiding and encapsulation again) simplifies maintenance (changes are
encapsulated within “module boundary”) and increases reusability (module’s interface defines
messages that can be responded to, module can be used/reused “as is” or adapted for other uses

Steps for Identifying Packages and Building Package Diagrams
• Set the context
• Cluster classes together based on shared relationships
• Model clustered classes as a package
• Identify dependency relationships among packages
• Place dependency relationships between packages

Step 1: Set the context, i.e. model a partition or a layer, e.g. for
appointments system we might choose
context = problem domain (PD) layer
288/Chapter
© DHBK 2007
Step 2: Cluster classes together based on shared relationships, i.e. form partition
using relationships (generalisation, aggregation, kinds of association
and message passing between objects) shared by classes
Examine analysis models

Class Diagram Sequence Diagram(s)
Communication Diagram(s)
Classes in a generalisation
hierarchy put in a single
partition
Step 3: Place clustered classes in partition and model clustered classes as a

package, i.e. model partitions as packages
Step 4: Identify dependency relationships between packages, i.e. relationships that cross
boundaries of packages = potential dependencies
a) association relationship between b) Appt. pkg via association between

Person Pkg and Appt. Pkg via Patient and Appt classes
Association between Doctor class and Treatment Pkg via association
and Appt. class and Patient Pkg between Patient and Symptom classes
contained in Person Pkg
Step 5: Place dependency relationships between packages, i.e. between Person Package and
Appt. Package, Person Package and Treatment Package
Show dependency relations as “pure” package diagram showing ONLY dependency relations
that CAN be created
between packages
PD Layer
Person Package Appt. Package
Patient Package
Treatment Package
Worked Example: Applying Concepts at CD Selections: First, previous
lectures...
• Chapter 5: Functional and Non-functional Requirements
• Chapter 6: Functional Model = activity diagram + use-case descriptions &

diagrams
• Chapter 7: Structural Model = CRC cards + class diagram
• Chapter 8: Behavioural Models for “Places Order” use-case + “Order” class

(sequence diagram, communication diagram, behavioural state machine)
• Next: Create package diagram for CD Selections

Example: Applying Concepts at CD Selections
• Set the context = Problem Domain Layer
• Cluster classes, i.e. review relationships amongst classes
Sequence Diagram (Places Order Use Case)
CD Selections Class Diagram

(Places Order Use-Case View)
Communication Diagram
(Place Order Use Case)
• Keep classes in a generalisation hierarchy together =
cluster Customer, Individual and Organisation(al) classes into partition
• Aggregation relationships = cluster Mkt Info, Review, Artist Info, Sample Clip
classes into partition
• Association relationship (between CD class and Mkt Info class) and message
sending pattern of activity = place in same partition
• Recall,
cluster Mkt
Info, Review,
Artist Info,
Sample Clip
classes into
partition
• Order Class and Order Item

Class = partition
• Search Req Class and CD

List Class = partition
• Also, Vendor class only

related to CD class = same
partition (as CD and Market
Info classes)
• Model each partition as a package
n.b. Credit Card Centre not yet contained in a package
Identify dependency relationships between packages =

Customer Package + Order Package, Customer Package + Search Package,
Order Package + CD Package, Search Package + CD Package
(also between Credit Card Centre + Customer package)
Place the dependency relations on the package diagram (and increase clarity by dependency
relationships between packages = pure package diagram of PD layer of CD Selections containing
highest level packages only (+ Credit Card Centre class) and their dependency relationships

• Custom Development
• Has potential for meeting highly specialized requirements
e.g. for CD selections, order taking process could be web-based, linking
tightly with the existing distribution system,
or, the technical environment may enforce constraint that all information
systems are built using standard technology and interface designs (for
consistency, ease of reuse)
• Has potential for greater flexibility and creativity in solving problems
e.g. for CD selections, can use ordering “web interface” as strategic
enabler to better understand customer’s who order online, using
technology to mine data obtained via custom applications
• Has potential to change components
e.g. for CD selections all components in custom application are available
and can be reused in whole or part
• Usually increases personnel skills
e.g. for CD selections, developers build technical skills and business
knowledge as they further evolve the system
• Potentially requires significant resources
• Potentially adds significant risk

• Packaged Software
 Software already written – so available, “as is”

For CD selections, could use “shopping cart” software installed
into existing web page
 Potentially more efficient, better tested (even proven!) - because
developers/implementors more skilled in techniques used to
specify/design + implement, test (or even prove!)
For CD selections, “shopping cart” is freely available “software
tool”, other simple components also available, e.g. ActiveX
controls, Java “beans”, whole approach scales-up to Enterprise
Resource Planning applications (ERP’s), e.g. SAP, Oracle
 Functionality provided “as is”
For CD selections, packed software may require change to
existing business practice, but could customise an order
processing application, or “work around” via custom-built
application that “wraps around” packaged software giving
additional functionality

• Packaged Software (cont.)
 Systems Integration: building new systems from combinations of

packaged software, existing legacy systems and new custom
developed software to integrate these together.
Problem is usually integrating data, different formats must be

resolved
For CD selections, integrating data in new online order system

with data in legacy distribution application may be problematic
Could develop “object wrapper” around legacy system (and its

data) so that new object oriented web based ordering system
can send messages to the “wrapper”

• Outsourcing – (now increasingly popular)
 = pay external vendor, developer, service provider to create system
For CD selections, use a Web Service Provider who provides
commercial order taking system
 Potentially external suppliers have higher level of skill
Their services MUST work to generate income, so web services
are built by “experts” with significant experience
 Is not “cost free” – lose absolute control over software and data,
inhouse expertise is not increased
 Only outsource what is properly understood in advance
Needs rigorous planning and analysis of needs in advance of
contract negotiations, must identify vendor, developer or
service provider with proven track record of success in system
and supporting technology for system’s needs
 Vendor choice and contract & payment method by strictly
controlled criteria
Time and arrangement deal
Fixed price
Value added contract

• Outsourcing Guidelines
 Keep lines of communication open with outsourcer

 Define and stabilize requirements before signing a
contract
 View outsourcing relationship as partnership
 Select outsource vender carefully
 Assign person to manage relationship
 Don’t outsource what you don’t understand
 Emphasize flexible requirements, long-term
relationships, and short-term contracts

• Select a strategy (1):
 Business need
Common business needs best served by packaged systems, i.e.
when custom built alternative does not require any special
business needs, when system is not critical to company
 In-house experience
Custom application only feasible if sufficient in-house skills for
all functional and technical challenges, otherwise packaged
system (possibly with in-house integration software added)
 Project skills
Technical, e.g. Java programming and IDE skills, data design
and SQL programming skills
Functional, e.g. in electronic commerce
If electronic commerce is to become basis for company’s future
development, in-house skills in EC and technical skills in its
exploitation must be further developed
Some skills, e.g. network security, might be operational issue
which can be outsourced

• Select a strategy (2):
 Project management
Custom applications require significant project management via
application of a proven system development methodology (or
collection of integrated methods)
Packaged and outsourced systems require different kinds of
management, e.g. of contract and delivery
 Time frame
If time to meet business requirement(s) is limited (or short),
requirements are “standard” and well-defined, then packaged or
outsourced most likely strategies, outsourced for standard,
packaged for well-defined
5.1.4 Phát triển thiết kế thực tế

• Alternative Matrix
 Combines several feasibility analyses into one grid

 Revisits technical, economic, and organizational feasibility
 Created using same steps as feasibility analysis (chapter 3), but combines several
analyses into a single matrix for comparison
 Matrix is represented by a grid
 Contains technical, budget, organisational feasibilities for each candidate, pro’s
and cons, other useful information, e.g. criticality, future-proofing
 Sometimes “weights” are provided
 n.b. in AHP weights are derived (mathematically) from judgements over criteria
• Request For Proposal
 Aids development of alternative matrix

 Description of the system you propose to be built
 Vendors, developers, service providers respond with proposals including how they
will address needs as well as stating cost and time requirements.
 Similar (less effort-intensive) Request For Information (RFI)
5.1.4 Phát triển thiết kế thực tế

5.2 Thiết kế lớp và phương thức

5.2.2 Các tiêu chí thiết kế
5.2.3 Các hoạt động thiết kế đối tượng
5.2.4 Ràng buộc và giao kèo
5.2.5 Xác định phương thức

• Các mức trừu tượng của hệ thống hướng đối tượng

• Coupling
• Cohesion
• Connascence

• Coupling:
 Indicates the interdependence or interrelationships of the modules
 Interaction coupling
 Relationships with methods and objects through message passage
 Inheritance coupling
 Deals with how tightly coupled the classes are in an inheritance hierarchy

Types of interaction coupling

• Interaction coupling:
 Law of Demeter = minimise number of objects that can receive
messages from a given object
 Objects only send message to:
A) Itself
B) An object an object “contained” in an attribute of itself (or an
object of one of its superclasses)
C) An object passed as a parameter to the mehod
D) An object created by the method
E) An object stored in a variable whose declaration scope is the
entire program (a “global” variable)
Coupling increase if:

 calling method passes attributes to called method
 Calling method depends on value returned by called method

• Cohesion:
 Refers to how single-minded a module is within a system
 3 types of cohesion:
 Method
 Class
 Generalization/specialization

• Cohesion:
 Method cohesion:
 Address the cohesion within an individual method.
 Methods should do one and only one thing

• Cohesion:
 Class cohesion:
 Is the level of cohesion among the attributes and methods of a class
 A class should only represent one thing
 A cohesive class should:
 Contain multiple methods that are visible outside the class
 Have methods that refer to attributes or other methods defined with the class or
its superclass
 Not have any control-flow coupling between its methods

• Cohesion:
 Class cohesion:

• Cohesion:
 Generalization/specialization cohesion:
 Addresses the sensibility of the inheritance hierarchy

• Connascence:
 Two modules (classes or methods) are so intertwined, that if you
make a change in one, it is likely that a change in the other will be
required
 Connascence and encapsulation
 Minimize overall connascence by eliminating any unnecessary
connascence throughout the system,
 Minimize connascence across any encapsulation boundaries, such as
method boundaries and class boundaries,
 Maximize connascence within any encapsulation boundary.

• Connascence:
• Additional specification
• Identifying opportunities for reuse
• Restructuring the design
• Optimizing the design
• Map Problem Domain Classes to Implementation
Languages
• Additional specification:
 Ensure the classes are both necessary and sufficient for
the problem
 Finalize the visibility of the attributes and methods of
each class
 Determine the signature of every method of each class
 Define constraints to be preserved by objects
• Identifying opportunities for reuse:

 Analysis patterns
Representations of the problem-domain
 Design patterns
Useful grouping of collaborating classes that provide a solution
to a commonly occurring problem
Many design patterns are available in C++ or Java source code
 Frameworks
A set of implemented classes that can be used as a basis for
implementing an application
Most frameworks allow us to create subclasses to inherit from
classes in the framework
 Libraries
 components

 Libraries
 Class library similar to framework, i.e. has classes designed for reuse
 More domain specific, i.e. can be used to realise some layer, e.g. HIC
layer
 Can be used to:-
 Create instances of classes in library
 Create subclasses by inheritance, and then objects of subtype(s)
 Using inheritance again increases inheritance coupling and
Connascence
 Directly instantiating class in library, object dependency created
between created object and library object due to signatures of
methods in library object, i.e. increases interaction coupling
between class library object and created object

 Components:
Self-contained & encapsulated software that can be plugged
into a system
Provides specific funtionality
Typically components implemented using ActiveX or JavaBean
Component has well-defined Application Program Interface
(API)
API = set of method interfaces to objects contained in
component
Internal operation of component hidden by API
Components can be implemented using class libraries and
frameworks
Unless API changes between between version of component,
only need to relink component to application (no recompilation
required)

• Restructuring the design:

 Factoring
Separate out shared aspects of a method or class into a new
method or class
New class related to existing classes via inheritance,
aggregation or association
 Normalization
Identifies classes missing from the design
All association and aggregation relationships converted to
attributes of the class
 Challenge inheritance relationships to ensure they only support a
generalization/specialization semantics

 Simple optimisations make an existing design more
efficient, but must not make optimised design
significantly more difficult to reason about, i.e.
optimsation is a “trade-off” between efficiency and ease
of understanding
 the design optimisations below need to be considered.
[1] access paths between objects
[2] attributes of each class
[3] direct and indirect “fan-out” of each method
[4] execution order of statements
[5] unnecessary recomputation

[1] access paths between objects
 A message from one object to another may go though many intervening
objects
 If a) the path though the intervening objects is long and b) the message is
sent frequently consider a “redundant path”, i.e. an additional attribute in
the calling object that stores a direct connection to object at end of path
 [2] attributes of each class
 If methods that use an attribute only read and update attribute and only
instances of a single class send those messages then attribute may belong
to calling class.
 [3] direct and indirect “fan-out” of each method
 Fan-out = number of messages sent by a method
 Direct Fan-out = number of messages sent by given method
 Indirect Fan-out includes number of messages sent by methods called by
other methods in a message tree
 If fan-out of a method significantly higher than other methods in a system
then should be optimised, e.g. add an index to attributes used to send
messages to objects in message tree

[4] execution order of statements
 In frequently used methods, order of statements may be non-
optimal
 Changing order should not affect result of computation
 Changing order can be more efficient, e.g. when searching, if one
attribute known to narrow search then search on that attribute first
[5] unnecessary recomputation
 Derived attributes (or active values) need not be recomputed until
attributes that are involved in its computation change, e.g.
 A) Add “trigger” to attributes in computation of derived attribute
and when any of those attributes change recompute derived
attribute
 B) Mark derived attribute and recompute only when it is next
accessed

Languages:
 OO designs assume class-based OO programming language used
to implement those designs
e.g. UML class diagram is-a specification of a class in a class-
based OO programming language
 Need to resolve any conflicts between constructs assumed in the

design to be available in programming language but are not present
in that language e.g.
 [1] design uses multiple inheritance, language has only single

inheritance
 [2] implementation language is object-based and not class-based, i.e.

implementation language supports object creation but not
implementation inheritance
 [3] language is of another (less expressive) language paradigm, e.g. C

or Pascal are of the imperative-procedural paradigm

Languages:
[1] design uses multiple inheritance, language has only single
inheritance
 A) Convert multiple inheritance relationships to “superclass”-
subclass association relationships
If additional superclasses are concrete (objects of the class can
be instantiated) then multiplicity from superclass to subclass is
0..1
Otherwise multiplicity is 1..1
Add an exclusive-OR constraint between associations
Add appropriate methods to ensure all information remains
available to existing class
 B) Copy ALL the attributes and methods of the additional
superclasses to ALL the subclassess and remove additional
superclass from the design

Languages:
inheritance
concrete
SuperClass1 SuperClass2 SuperClass3

-attribute1 1..1 -attribute3 1..1 -attribute7
-attribute2 -attribute4 -attribute8
0..* {XOR}
0..* [1]All classes preserved
[2]Increases amount
Class1 Class2 of message passing
-attribute5 -attribute5 [3]Adds to processing
-attribute6 -attribute6 requirement due to XOR

Languages:
inheritance
abstract

Potential
Class1 Class2 Inheritance
-attribute3 -attribute3 Conflicts
-attribute4 -attribute4

Languages:
[2] implementation language is object-based and not class-
based
 Need to factor out ALL uses of inheritance from problem-domain
class design
All superclasses concrete

-attribute1 1..1 -attribute3 1..1 -attribute7
1..1 0..* {XOR} 1..1
0..*
1..1 1..1
Class1 Class2

Languages:
[2] implementation language is object-based and not class-
based
If all superclasses are
abstract
Class1 Class2
-attribute1 -attribute1 Potential
-attribute2 -attribute2 Inheritance
-attribute3 -attribute3 Conflicts
-attribute5 - attribute5

Languages:
[3] language is of another (less expressive) language paradigm,
e.g. C or Pascal are of the imperative-procedural paradigm
 Stay away from this!
 But if necessary, factor out all uses of
 Polymorphism
 Dynamic binding
 Encapsulation
 Information hiding

• Contract formalises interactions between client and server objects
• Contract is a set of constraints and guarantees
• If constraints are met, server object will guarantee certain behaviour
• Constraints can be stated in natural language or formal language, e.g.
OCL (Object Constraint Language)
• Constraints may be pre-conditions, post-conditions or invariants
• Contracts establish pre- and post-conditions for a method to execute
correctly
• Pre-condition is constraint which must be met for a method to execute
 e.g. actual parameters passed must be valid, if not exception must be
raised
• Post-condition is constraint that must be met after method executes
Otherwise effect of method execution must be undone
 e.g. method cannot make any attributes take invalid value
 Exception must be raised, and effect of method’s execution must be
undone

• Pre- and post-conditions model constraints on individual
methods
• Invariants model constraints (that must always be true) for
all instances of a class, e.g.
 Domains (in DB) or types (in design/programming
language) of attributes
 Multiplicity of attributes
 Legal values of attributes including attributes that model
association and aggregation and relationships
 e.g. if association relationship is required, invariant is
created to enforce relationship to have valid value for
instance to exist
• Invariants usually attached to the class, e.g. CRC cards or
class diagrams as a set of assertions
339/Chapter
© DHBK 2007 Attribute Constraint:
Customer IS INSTANCE OF
Attribute Constraint:
• Example:- Customer Class
Order Number IS unsigned long
Back:
Attributes:
Order Number (1:1) (unsigned long)
Date (1..1) (Date)
Sub Total (0..1) (double)
Tax (0..1) (double) {Sub Total = sum(Product Order.GetExtension())}
Shipping (0..1) (double)
Total (0..1) (double)
Customer (1..1) (Customer)
Cust ID (1..1) (unsigned long) (Cust ID = Customer.GetCustID()}
State (1..1) (State)
StateName (String) {State Name = State.GetState()}
Attribute Constraint:
Cust ID IS unsigned
Long
Relationships: Constraint: Instance of Order EXISTS AND
Generalisation(a-kind-of): IF (instance of Customer class AND
Invariant
instance of State class AND
MUST HAVE one and
Aggregation (has-parts): >=1 instance of Product class)
ONLY one value
ASSOCIATED WITH order object
(1..1) =
Other Associations: Product{1..*} Customer(1..1} State{1..1} Customer. GetCustID()
Product Order
Invariants On a Order
Class Diagram(Not recommended Product
– Use CRC card for Invariants) Quantity
<<invariant>> Extension
{Sub Total=
Sum(Product Order.GetExtension())}}
Customer Order Product

-Cust ID -Order Number: unsigned long -Product Number
-Last Name 1..1 0..* -Date[1..]: Date -Product Desc
-First Name -Sub Total[0..1]: double 0..* 1..* -Price
-Tax[0..1]:double
-Shipping[0..1]:double
-Total[0..1]double
-Tax[0..1]: double
-Customer[1..1]: Customer <<invariant>>
-Cust ID[1..1]: unsigned long {Tax=State.GetTaxRate()
-State[1..1] State *SubTotal}
-State Name[1..1: String
State
<<invariant>> 0..* 1..1 -State

{Cust ID=Customer.GetCustID()} Tax RateProduct Desc
<<invariant>>
{State Name=State.GetState()}

• Contract:
 Contracts document message passing between objects, i.e.
messages sent to server objects by implementor’s client object,
and values returned by server
 Ideally a contract for each message sent and received by each

object, i.e. one contract per interaction
 In practice, one contract for each method that can receive

messages from other objects, i.e. each visible method
 Contracts are declarative = documents for client object’s

implementor what the method does
 Method name, class name, ID number, client objects, associated use
cases, description, arguments received, type of reurn value, pre- and
post-conditions
 Does NOT contain details of how method works i.e. not procedural
Unique Contract ID
Specific Method OF specific Class
List of classes and methods

that send a message to this
List of use cases containing method
this method where method is
used to realise implementation
of the use case (from server
class’s CRC card and associated
use cases)
What the method does NOT how it does it
types of parameters passed
type of value returned to its clients
= method signature
5.2.5 Xác định phương thức

• General information
• Events
• Message passing
• Algorithm specification
 Structured English
 Pseudocode
 UML activity diagram
344/Chapter
© DHBK 2007 General Information (for managing programming effort)
Method Name Class Name ID:
Contract ID Programmer: Date Due:
Programming Language: Visual Basic SmallTalk C++ Java
Triggers/Events e.g. user initiated event(mouse event, keystroke event),

system event or event initiated by another method
Arguments Received: Notes:

Data Type: Message passing to and from method
(c.f. sequence and collaboration diagrams)
Arguments = attributes and data structures
in implemented method
Messages Sent & Arguments Passed
ClassName.MethodName: Data Type: Notes:
Argument Returned: Notes:

Data Type:
Algorithithm Specification:
• Structured English will suffice for algorithm specification…
Algorithm Specification:
Action Statement Examples: Profits = Revenues – Expenses
Generate Inventory-Report
IF Statement Examples: IF Customer NOT in Customer Object Store
THEN
Add Customer record to Customer Object Store
ELSE
Add Current-Sale to Customer’s Total Sales
Update Customer record in Customer Object Store
FOR Statement Examples: FOR all Customers in Customer Object Store DO

Generate a new line in Customer-Report
Add Customer’s Total-Sales to Report-Total
CASE Statement Examples: CASE
IF Income < 10,000: Marginal-tax-rate = 10 percent
ELSE Marginal-tax-rate = 38 percent
ENDCASE
Notes:
• Pseudocode = “programming specific” language

with initialisation and linking instructions
• (Get_CD_Info Module)
Accept(CD.Title) {Required}
Accept(CD.Artist) {Required}
Accept(CD.Category) {Required}
Accept(CD.Length)
• Return

Tailieuxanh Uml Phan Tich Va Thiet Ke Huong Doi Tuong 0506

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tailieuxanh Uml Phan Tich Va Thiet Ke Huong Doi Tuong 0506

Uploaded by

Copyright:

Available Formats

Phân tích và thiết kế hướng

Giảng viên: Phạm Ngọc Nam

Tài liệu tham khảo

Chương 1. Giới thiệu chung về phân

1.1 Giới thiệu

1.2 Quy trình phát triển hệ thống

1.2 Quy trình phát triển hệ thống

1.2 Quy trình phát triển hệ thống

1.2 Quy trình phát triển hệ thống

1.2 Quy trình phát triển hệ thống

1.2 Quy trình phát triển hệ thống

Planning Project Plan

Analysis System Proposal

Implementation New System and

1.3 Các phương pháp phát triển hệ

• Phương pháp phát triển rất nhanh (Agile

1.3.1 Thiết kế cấu trúc

1.3.1 Thiết kế cấu trúc

1.3.1 Thiết kế cấu trúc

1.3.1 Thiết kế cấu trúc

Phương pháp xây dựng nguyên mẫu thông

1.3.3 Lựa chọn phương pháp phù hợp

1.3.3 Lựa chọn phương pháp phù hợp

Chương 2: Giới thiệu về phân tích và

2.1 Giới thiệu

2.1 Giới thiệu

2.1 Giới thiệu

UML 1.1 (OMG Standard)

2.1 Giới thiệu

2.1 Giới thiệu

2.2 Các đặc điểm cơ bản của hệ thống

2.2.1 Lớp và đối tượng

2.2.1 Lớp và đối tượng

2.2.1 Lớp và đối tượng

4 void setTime( int, int, int );

2.2.2 Phương thức và message

2.2.2 Phương thức và message

2.2.3 Tóm lược và ẩn thông tin

2.2.5 Đa hình thái và liên kết động

2.2.5 Đa hình thái và liên kết động

2.3 UML 2.0

2.3.1 Giới thiệu về UML

• UML chỉ đơn thuần là ngôn ngữ đồ hoạ để mô hình

2.3.1 Giới thiệu về UML

2.3.2 Biểu đồ cấu trúc

2.3.2 Biểu đồ cấu trúc

2.3.2 Biểu đồ cấu trúc

2.3.2 Biểu đồ cấu trúc

2.3.2 Biểu đồ cấu trúc

2.3.2 Biểu đồ cấu trúc

2.3.2 Biểu đồ cấu trúc

2.3.3 Biểu đồ chức năng

2.3.3 Biểu đồ chức năng

2.3.3 Biểu đồ chức năng

2.3.3 Biểu đồ chức năng

2.3.3 Biểu đồ chức năng

2.3.3 Biểu đồ chức năng

2.3.3 Biểu đồ chức năng

2.3.3 Biểu đồ chức năng

2.3.3 Biểu đồ chức năng

2.3.3 Biểu đồ chức năng

2.3.4 Các cơ chế mở rộng

2.3.4 Các cơ chế mở rộng

Inputs x 3 x 4 x 6 __

Outputs x 4 x 5 x 7 __

Queries x 3 x 4 x 6 __

Files x 7 x 10 x 15 __

Program x 5 x 7 x 10 __