Phân Tích Thiết Kế

• 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[r]

(1)

Ph

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

đối tượng

(Object

(Object Oriented System Oriented System Analysis and Design)

(2)

2/Chapter © DHBK 2007

Giới thiệu

• 4 ĐVHT = 60 tiết

• Học lớp + Bài tập lớn

• Điểm = Điểm thi + Điểm tập lớn (70%) + (30%)

• Điều kiện thi: Phải có tập lớn • Bài tập lớn:

Làm theo nhóm tối đa sinh viên

Nội dung: phân tích thiết kế hệ thống sử dụng Rational

Rose

Đề tài: sinh viên tự chọn đề tài

• Mục đích mơn học

Trang bị cho sinh viên một phương pháp có hệ thống để phân

(3)

Nội dung

1 Giới thiệu chung phân tích thiết kế hệ thống 2 Giới thiệu phân tích thiết kế hướng đối

tượng với UML 3 Lập kế hoạch

(4)

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

(5)

tích thiết kế hệ thống

1.1 Giới thiệu

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

(6)

(7)

• Lập kế hoạch (Planning)

Vì sao phải xây dựng hệ thống ?

• Phân tích (Analysis)

Ai sử dụng hệ thống, hệ thống làm gì, dùng nào, đâu?

• Thiết kế (Design)

Hệ thống làm việc như nào?

• Triển khai (Implementation)

(8)

Lập kế hoạch

• Xác định giá trị kinh doanh hệ thống

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

• Xây dựng kế hoạch cơng việc

(9)

Phân tích

Phân tích • Phân tích hệ thống

• Thu thập nguồn thơng tin

(10)

Thiết kế

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

(11)

Triển khai

Triển khai • Xây dựng hệ thống

(12)

Các pha kết pha

(13)

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 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 nhanh (Agile

development)

(14)

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

• Dự án tiến triển từ bước sang bước tiếp theo cách có hệ thống

(15)

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

(16)

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

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

Phương pháp thác nước • Ưu điểm:

Trước lập trình yêu cầu hệ thống

xác định chi tiết đầy đủ => giảm thiểu thay đổi yêu cầu trình phát triển hệ thống • Nhược điểm:

Thời gian từ đề xuất dự án đến có sản phẩm cuối

(17)

Phương pháp phát triển song song

(18)

1.3.2 RAD

1.3.2 RAD • Các nhân tố quan trọng:

 Công cụ CASE  JAD

(19)

Phương pháp phát triển theo pha

(20)

20/Chapter

© DHBK 2007 1.3.2 RAD1.3.2 RAD

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

thường

(21)

Phương pháp xây dựng nguyên mẫu loại bỏ

(22)

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 • Tiêu chí:

 Độ rõ ràng, đầy đủ yêu cầu người sử dụng  Khả năng, mức độ thành thạo công nghệ

(23)

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

(24)

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

thiết kế hướng đối tượng với UML

2.2 Các đặc điểm hệ thống hướng đối tượng

2.3 UML 2.0

(25)

• Lịch sử phát triển 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

(26)

(27)

• Lịch sử phát triển UML

1967 Foundations of OO (Nygaard, Goldberg, Meyer,

Foundations of OO (Nygaard, Goldberg, Meyer, Stroustrup, Harel, Wirfs-Brock, Reenskaug,…) Stroustrup, Harel, Wirfs-Brock, Reenskaug,…) Foundations of OO (Nygaard, Goldberg, Meyer,

Foundations of OO (Nygaard, Goldberg, Meyer,

Stroustrup, Harel, Wirfs-Brock, Reenskaug,…)

Jacobson Jacobson Booch Booch Rumbaugh Rumbaugh

UML 1.1 (OMG Standard)

UML 1.3 (extensibility) UML 1.3 (extensibility) UML 1.3 (extensibility)

UML 1.3 (extensibility)

UML 1.4 (action semantics) UML 1.4 (action semantics) UML 1.4 (action semantics)

UML 1.4 (action semantics)

(28)

(29)

(30)

2.2 Các đặc điểm hệ thống

hướng đối tượng

2.2.1 Lớp đối tượng

2.2.2 Phương thức message

2.2.3 Tóm lược ẩn thông tin (Encapsulation and Information Hiding)

2.2.4 Thừa kế (inheritance)

(31)

2.2.1 Lớp đối tượng • 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 (Behaviors) – specify what object can

(32)

(33)

1 class Time {

2 public:

3 Time();

4 void setTime( int, int, int );

5 void printMilitary();

6 void printStandard();

7 private:

8 int hour; // - 23

9 int minute; // - 59

10 int second; // - 59

(34)

• Phương thức (Methods) implement an object’s behavior

 Analogous to a function or procedure

• Messages are sent to trigger methods

(35)

(36)

2.2.3 Tóm lược ẩn thơng tin

2.2.3 Tóm lược ẩn thơng tin • Encapsulation

combination of data and process into an entity

• Information Hiding

Only the information required to use a software module

(37)

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

(38)

2.2.4 Thừa kế

(39)

2.2.4 Thừa kế

(40)

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

2.2.5 Đa hình thái 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

(41)

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

(42)

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 = ); // default constructor 31 void setPoint( int, int );

32 int getX() const { return x; }

(43)

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

(44)

55 // Fig 20.1: circle1.h

56 // Definition of class Circle 57 #ifndef CIRCLE1_H

58 #define CIRCLE1_H

59 #include "point1.h"

60

61 class Circle : public Point {

62 public:

63 // default constructor

64 Circle( double r = 0.0, int x = 0, int y = );

65

66 void setRadius( double );

67 double getRadius() const;

68 virtual double area() const;

69 virtual void printShapeName() const { cout << "Circle: "; }

70 virtual void print() const;

71 private:

72 double radius; // radius of Circle 73 };

74

(45)

78 #include <iostream>

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 > ? 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;

(46)

100// Fig 20.1: cylindr1.h

101// Definition of class Cylinder 102#ifndef CYLINDR1_H

103#define CYLINDR1_H

104#include "circle1.h"

105

106class Cylinder : public Circle {

107public:

108 // default constructor

109 Cylinder( double h = 0.0, double r = 0.0,

110 int x = 0, int y = );

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: "; }

117 virtual void print() const;

118private:

119 double height; // height of Cylinder 120};

121

(47)

125#include <iostream>

126

127using std::cout;

128

129#include "cylindr1.h"

130

131Cylinder::Cylinder( double h, double r, int x, int y )

132 : Circle( r, x, y ) // call base-class constructor 133{ setHeight( h ); }

134

135void Cylinder::setHeight( double h )

136 { height = h > ? h : 0; }

137

138double Cylinder::getHeight() { return height; }

139

140double Cylinder::area() const

141{

142 // surface area of Cylinder 143 return * Circle::area() +

144 * 3.14159 * getRadius() * height;

145}

146

147double Cylinder::volume() const

148 { return Circle::area() * height; }

149

150void Cylinder::print() const

151{

152 Circle::print();

153 cout << "; Height = " << height;

(48)

155// Fig 20.1: fig20_01.cpp

156// Driver for shape, point, circle, cylinder hierarchy 157#include <iostream>

158

159using std::cout;

160using std::endl;

161

162#include <iomanip>

163

164using std::ios;

165using std::setiosflags;

166using std::setprecision;

167

168#include "shape.h"

169#include "point1.h"

170#include "circle1.h"

171#include "cylindr1.h"

172

173void virtualViaPointer( const Shape * );

174void virtualViaReference( const Shape & );

175

176int main()

177{

178 cout << setiosflags( ios::fixed | ios::showpoint )

179 << setprecision( );

180

181 Point point( 7, 11 ); // create a Point 182 Circle circle( 3.5, 22, ); // create a Circle 183 Cylinder cylinder( 10, 3.3, 10, 10 ); // create a Cylinder 184

(49)

2 Function calls

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[ ]; // array of base-class pointers 198

199 // aim arrayOfShapes[0] at derived-class Point object 200 arrayOfShapes[ ] = &point;

201

202 // aim arrayOfShapes[1] at derived-class Circle object 203 arrayOfShapes[ ] = &circle;

204

205 // aim arrayOfShapes[2] at derived-class Cylinder object 206 arrayOfShapes[ ] = &cylinder;

207

208 // Loop through arrayOfShapes and call virtualViaPointer 209 // to print the shape name, attributes, area, and volume 210 // of each object using dynamic binding.

211 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

(50)

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.

231void 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.

241void virtualViaReference( const Shape &baseClassRef )

242{

243 baseClassRef.printShapeName();

244 baseClassRef.print();

245 cout << "\nArea = " << baseClassRef.area()

246 << "\nVolume = " << baseClassRef.volume() << "\n\n";

(51)

2.3 UML 2.0

2.3 UML 2.0 2.3.1 Giới thiệu UML

(52)

2.3.1 Giới thiệu UML

"The Unified Modeling Language (UML) is a graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive

system.”

• UML đơn ngơn ngữ đồ hoạ để mơ hình hố khơng phải phương pháp để phát triển hệ thống

(53)

2.3.1 Giới thiệu UML

• UML 2.0 cung cấp 14 biểu đồ để mơ hình hố cấu trúc chức hệ thống, chia làm nhóm:

(54)

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

2.3.2 Biểu đồ cấu trúc • 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

(55)

• Biểu đồ lớp (class diagram)

(56)

• Biểu đồ đối tượng (object diagram)

(57)

• Biểu đồ gói (package diagram)

 Biểu đồ gói gộp thành phần khác UML (ví dụ: lớp) để

(58)

• Biểu đồ triển khai (deployment diagram)

 Biểu diễn cấu trúc phần cứng thành phần phần mềm hệ

(59)

• Biểu đồ thành phần (component diagram)

(60)

• Biểu đồ cấu trúc phức hợp (composite structure diagram)

(61)

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

2.3.3 Biểu đồ chức năng • 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 (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 (behavior state machines) Máy trạng thái giao thức (protocol state machines)

(62)

• Biểu đồ hoạt động (activity diagram)

 Được dùng để mô tả luồng

(63)

• Biểu đồ chuỗi (sequence diagram)

 Mô tả hoạt động đối tượng ca sử dụng dựa

(64)

• Biểu đồ cộng tác (collaboration diagram)

 Là cách biểu diễn khác biểu đồ chuỗi tập trung

(65)

• Biểu đồ khát quát tương tác (interaction overview diagram)

 Được dùng để mô tả tương tác đối tượng ca sử

dụng phức tạp

 Ít sử dụng

• Biểu đồ thời gian (timing diagram)

 Được dùng để mô tả tương tác đối tượng theo thời gian

Chủ yếu dùng để mô tả thay đối trạng thái đối tượng khi có tác động kiện theo thời gian.

 Được dùng để phát triển hệ thống thời gian thực hệ thống

(66)

• Biểu đồ máy trạng thái chức (behavior state machines)

 Được dùng để mô tả trạng thái khác mà đối tượng

(67)

• Biểu đồ máy trạng thái giao thức (protocol state machines)

 Được dùng để mô tả giao thứ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 hệ thống với người sử

dụng với hệ thống khác có tương tác với nó.

 Là cơng cụ để mơ tả yêu cầu hệ thống

 Là cơng cụ quan trọng phân tích

(68)

(69)

(70)

(71)

2.3.4 Các chế mở rộng

• Ràng buộc (constraints)

 Dùng để biểu diễn ràng buộc quan hệ mà biểu

diễn UML

(72)

• Nhãn:giá trị (tagged values)

 Là cặp chuỗi ký tự: nhãn (tag) giá trị (value) dùng để

bổ sung thơng tin cho phần tử (lớp, đối tượng, quan hệ …)

(73)

• Khn mẫu (stereotype)

 Cho phép mở rộng UML cách sử dụng phần tử mơ hình

hố có sẵn UML

(74)

2.3.5 Tóm tắt

(75)

tượng với UML 2.0

2.4.1 Đặc điểm OOAD 2.4.2 Ưu điểm OOAD

(76)

2.4.1 Đặc điểm OOAD

2.4.1 Đặc điểm OOAD • Use-case driven

• Architecture Centric

• Cấu trúc phần mềm định việc mô tả, xây dựng viết tài liệu hệ thống

• 3 dạng cấu trúc hệ thống:

• Chức (functional view): chức bên ngồi hệ thống từ góc nhìn 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 bên hệ thống: biểu đồ máy trạng thái chức năng

(77)

2.4.2 Ưu điểm OOAD

• Việc chia nhỏ hệ thống lớn thành module sẽ giúp cho việc giải vấn đề dễ dàng hơn, dễ chia sẻ thành viên dự án dễ dàng trao đổi với người dùng yêu cầu hệ

thống

• Dễ dàng sử dụng lại module dự án khác

(78)

2.4.2 Ưu điểm OOAD

(79)

2.4.3 The Unified process

• Unified process phương pháp phát triển hệ thống quy định sử dụng kỹ thuật UML sử dụng chúng q trình phân tích 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 quy trình phát triển phần mềm hồn

thiện

Không xét đến vấn đề phân bổ nhân lực, ngân quỹ, quản

lý hợp đồng

(80)

(81)

• Pha khởi tạo (Inception): giống pha lập kế hoạch

Các bước liên quan:

Mơ hình hoá giá trị kinh doanh hệ thống (business modeling) * Xác định yêu cầu (requirements)*

Phân tích (analysis)*

Thiết kế (design)

Thực (implementation) Kiểm tra (test)

Môi trường phát triển (environment)*

Kết quả:

Phạm vi dự án

Các yêu cầu ràng buộc quan trọng Kế hoạch dự án bước đầu

Miêu tả tính khả thi rủi ro dự án

(82)

• Pha phát triển (elaboration): hồn thiện mơ hình kinh doanh, đánh giá lại rủi ro 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)*

Thực (implementation) Kiểm tra (test)

Triển khai (deployment)

Quản lý cấu hình thay đổi (configuration and change management)

Kết quả:

Biểu đồ cấu trúc chức UML

(83)

• Pha xây dựng (construction): tập trung chủ yếu vào lập trình

Thu thập yêu cầu (requirements) Phân tích (analysis)

Thực (implementation)*

Kiểm tra (test)

Triển khai (deployment)

Quản lý cấu hình thay đổi (configuration and change management)* Kết quả:

(84)

• Pha chuyển tiếp (transition): tập trung chủ yếu vào kiểm tra triển khai

Thu thập yêu cầu (requirements) Phân tích (analysis)

Thực (implementation)

Kiểm tra (test)*

Triển khai (deployment)*

Quản lý cấu hình thay đổi (configuration and change management)* Kết quả:

Phiên cuối (release) hệ thống Hướng dẫn sử dụng

(85)

• Các bước kỹ thuật (Engineering workflows)

1 Mơ hình hố giá trị kinh doanh (business modeling)

 Diễn chủ yếu pha khởi tạo

 Phát vấn đề xác định dự án tiềm năng  Xác định giá trị kinh doanh mà dự án đem lại

 Thu thập liệu mơ hình hố ca sử dụng sử

dụng

2 Xác định yêu cầu (requirements)

 Xác định yêu cầu chức không chức năng

 Yêu cầu 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 chức sử dụng UML  Xác định lớp sử dụng lại

 Bước phân tích sử dụng lại lúc chu trình

(86)

2.4.3 The Unified process • 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, sở liệu, cấu trúc vật lý hệ thống, thiết kế

chi tiết lớp

5 Thực (implementation)

 Lập trình: viết lớp, chương trình sử dụng lớp thư

viện

 Tích hợp module

6 Kiểm tra (Test)

 Kiểm tra tích hợp hệ thống, chức năng, kiểm tra khả chấp nhận

của người sử dụng …

 Việc kiểm tra đuợc tiến hành suốt trình phát triển hệ

thống

7 Triển khai (deployment)

(87)

2.4.3 The Unified process • Các bước hỗ trợ (Supporting workflows)

1 Quản lý dự án (project management)

 Diễn suốt trình phát triển hệ thống  Xác định quản lý rủi ro

 Quản lý phạm vi dự án

 Quản lý thời gian, chi phí…

2 Quản lý cấu hình thay đổi (configuration and change management )

 Theo dõi quản lý trạng thái phiên hệ thống  Quản lý việc thay đổi phiê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ông cụ môi trường phát triển cần thiết cho dự

án

(88)

2.4.4 MOOSAD

(89)

Chương Lập kế hoạch

3.1 Khởi tạo dự án (Project initiation)

(90)

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)

(91)

Nhu cầu kinh doanh Tài liệu

yêu cầu hệ thống

Project sponsor

Hội đồng duyệt dự án

No

Yêu cầu hệ thống đã chỉnh sửa

Yes

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

Project sponsor + analyst

(92)

• Hội đồng duyệt dự án (approval committee)

Hội đồng chuyên trách họp thường kỳ (vd tháng

lần)

1 đơn vị chức cá nhân có thẩm quyền (vd

(93)

3.1.2 Yêu cầu hệ thống (system request) • Tài liệu yêu cầu hệ thống gồm 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)

(94)

• Chủ nhiệm dự án (project sponsor)

 Người thuộc phòng kinh doanh

 Người thuộc phịng IT chủ nhiệm đồ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 cần 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ơng ty có vấn đề: cổ phiếu giảm, hỗ trợ khách

hàng kém, bị cạnh tranh

(95)

3.1.2 Yêu cầu hệ thống (system request) • Yêu cầu kinh doanh (business requirement)

Hệ thống làm gì

Các chức hệ thống

• Giá trị kinh doanh (business values)

Giá trị hữu hình: ví dụ: 20 % giảm 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

(96)

Case study: CD selections

Case study: CD selections • Giới thiệu chung 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 thông tin công ty

như dẫn đường đến, mở cửa, địa liên hệ • Margaret Mooney, phó chủ tịch phụ trách thị

(97)

Case study: CD selections

(98)

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

3.1.3 Phân tích tính khả thi • Khả thi kỹ thuật (technical feasibility)

• Khả thi kinh tế (economic feasibility)

(99)

• Khả thi 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 dự án:

Số lượng người tham dự thời gian

độ phức tạp hệ thống

Sự tương thích hệ thống với hệ thống tồn

tại

(100)

• Khả thi kinh tế (economic feasibility) (should we build it ?)

 Xác định loại chi phí 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

(101)

(102)

(103)

 Xác định dòng tiền mặt (cash flow): giá trị chi phí lợi nhuận

(104)

(105)

 Xác định giá trị 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)

(106)

(107)

(108)

(109)

• Khả thi tổ chức

 Phân tích đánh giá mức độ hệ thống chấp nhận

người sử dụng khả tích hợp hệ thống vào hệ thống vận hành công ty

 2 cách đánh giá:

Hệ thống có định hướng với chiến lược phát triển cơng

ty?

Phân tích ảnh hưởng bị ảnh hưởng dự án

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

(110)

3.1.4 Lựa chọn dự án

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:

(111)

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 quản lý kế hoạch công việc 3.2.4 Sắp xếp nhân lực cho dự án

(112)

• 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

(113)

3.2.2 Xác định kích thước dự án • 3 nhân tố phụ thuộc lẫn nhau:

Kích thước hệ thống

Thời gian hồn thành dự án Chi phí 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 chuẩn công nghiệp Phương pháp điểm chức (function point

(114)

3.2.2 Xác định kích thước dự án • Phương pháp đơn giản dựa 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

(115)

(116)

3.2.2 Xác định kích thước dự án • 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

số dòng lệnh

1 điểm chức đơn vị đo kích thước chương trình dựa

trên số lượng độ phức tạp đầu vào, đầu ra, truy vấn, files và giao diện chương trình

Tính tốn số điểm chức năng

Liệt kê thành phần chương trình Xác định số lượng thành phần

(117)

Tính tốn số điểm chức năng-Bước 1:

Complexity

Description Low Medium High Total Inputs x x x Outputs x x x Queries x x x Files x x 10 x 15 Program x x x 10 Interfaces

(118)

(119)

(120)

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

Adjusted Processing Complexity (APC)

= 65 + (0.01 * Processing Complexity) Total Adjusted Function Points (TAFP)

(121)

Tính độ phức tạp xử lý hiệu chỉnh (adjusted processing complexity)-ví dụ:

Processing Complexity (PC): Adjusted Processing

Complexity (PCA) = 0.65 + (0.01 * 7_ ) Total Adjusted Function Points (TAFP):

(122)

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

Language LOC/Function Code Point

C COBOL JAVA C++ Turbo Pascal Visual Basic PowerBuilder HTML Packages

(e.g., Access, Excel)

130 110 55 50 50 30 15 15 10-40

(123)

Ướ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

(124)

Ước lượng nhân lực (person-months)

Ước lượng thời gian thực dự án (months)

Schedule Time (months) = 3.0 * person-months1/3

(125)

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

cơng việc

cơng việc • Xác định cơng việc dự án

• Ước lượng thời gian thực cơng việc

• Xác định phụ thuộc cơng việc • Xác định làm cơng việc gì

• Liệt kê kết đạt công việc ( deliverables): ví dụ: báo cáo, thiết kế,

(126)

công việc

cơng việc

• Ví dụ 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

(127)

công việc

• Xác định cơng việc dự án: phương pháp

 Phương pháp Top-down

 Xác định cơng việc pha dự án

 Lần lượt chia cơng việc thành 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

(128)

công việc

• Xác định cơng việc dự án dùng phương pháp Top-down

Phases high level stepsPhases with

Work Plan Deliverables Estimated Assigned duration To *

(129)

công việc

• Xác định cơng việc 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ơng việc chính

 Chia cơng việc thành cơng việc nhỏ hơn  Đánh số công việc xắp xếp chúng theo cấu trúc

phân tầng

 Có thể thực WBS theo cách:

(130)

công việc

(131)

công việc

cơng việc

(132)

cơng việc

• Biểu đồ PERT (PERT= Project Evaluation and Review Technique )

Là cách biểu diễn khác kế hoạch công việc

Cách tốt để biểu diễn phụ thuộc công

việc để xác định pha then chốt

PERT sử dụng loại giá trị ước lượng thời gian thực

hiện công việc:

Lạc quan: O

Khả cao: M (most likely) Bi quan: P

(133)

cơng việc

cơng việc • Biểu đồ PERT

(134)

3.2.4 Sắp xếp nhân lực cho dự án

3.2.4 Sắp xếp nhân lực cho dự án • Xác định số người cho dự án

• Xây dựng kế hoạch nhân (staffing plan) liệt kê các vị trí cần thiết cho dự án

• Xác định cấu tổ chức dự án

• Chọn người thích hợp vào vị trí

• Khích lệ, động viên định hướng cho nhóm

tới mục tiêu dự án

• Giải xung đột xảy

(135)

(136)

3.2.4 Sắp xếp nhân lực cho dự án • Chọn người thích hợp cho vị trí:

2 tiêu chí:

Kỹ kỹ thuật (technical skills)

Kỹ giao tiếp, ứng xử (interpersonal skills)

(137)

3.2.4 Sắp xếp nhân lực cho dự án • Khích lệ động viên thành viên nhóm:

Sử dụng tiền thưởng cách cẩn trọng Sử dụng 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ủ

(138)

3.2.4 Sắp xếp nhân lực cho dự án • Chiến lược để giải xung đột:

Xác định rõ ràng công việc thành viên

nhóm

Lập bảng quy định, nội quy nhóm

Dự đốn ưu tiên khác khả ảnh hưởng

(139)

3.2.5 Điều phối hoạt động dự án

• Kế hoạch dự án quản lý dự án phải cập nhật trong suốt thời gian dự án dự án tiến triển theo đúng kế hoạch dự kiến ban đầu:

Tinh chỉnh giá trị ước lượng: cập nhật ước lượng

về thời gian chi phí điều chỉnh dự án cho phù hợp với kết ước lượng

Quản lý phạm vi dự án: quản lý hậu gây 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 hiệu dự án

Quản lý rủi ro: đánh giá rủi ro từ có biện pháp tối

(140)

• Tinh chỉnh 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

(141)

• Quản lý phạm vi dự án (scope management)

Scope creep: tượng dự án có nguy kéo dài

tốn chi phí dự kiến

Nguyên nhân: thêm yêu cầu cho hệ thống sau

phạm vi hệ thống 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 xây

dựng nguyên mẫu để tăng tốc việc định rõ yêu cầu -> giảm được 5% nguy cơ

(142)

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

(143)

3.2.5 Điều phối hoạt động dự án • Điều phối hoạt động dự án:

Initiation Analysis Design Implementation

Upper CASE Lower CASE Integrated CASE (I-CASE)

CASE (computer-aided software engineering) tool –

Software that automates all of part of the development

process

(144)

3.2.5 Điều phối hoạt động dự án • Điều phối hoạt động 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

(145)

3.2.5 Điều phối hoạt động dự án • 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

(146)

3.2.5 Điều phối hoạt động dự án • Quản lý rủi ro:

Avoiding Classic Planning Mistakes

Overly optimistic schedule Failing to monitor schedule Failing to update schedule

(147)

3.2.6 CD selections

(148)

Chương Phân tích hệ thống

4.1 Xác định yêu cầu hệ thống 4.2 Mơ hình hố chức năng

(149)

Chương Phân tích hệ thống

Yêu cầu hệ thống (system request)

Định nghĩa yêu cầu của hệ thống

Hội đồng duyệt dự án

Mơ hình cấu trúc Mơ hình chức năng

Mơ hình hoạt động

system proposal Phân tích khả thi

Kế hoạch công việc

+

Yes

(150)

4.1 Xác định yêu cầu hệ thống

4.1.1 Xác định yêu cầu

(151)

4.1.1 Xác định yêu cầu • Yêu cầu gì?

1 yêu cầu (requirement) diễn tả chức hệ thống

phải làm đặc điểm hệ thống phải có

Yêu cầu chức (functional requirement): yêu cầu

có liên quan trực tiếp đến hoạt động mà hệ thống phải làm thông tin mà hệ thống lưu trữ

Yêu cầu không chức (nonfunctional requirement):

là yêu cầu tính chất thuộc tính mà hệ thống phải có khả hoạt động, khả sử dụng

Chức năng

Khả hoạt động An ninh

u cầu văn hố, trị

(152)

4.1.1 Xác định yêu cầu • Tài liệu định nghĩa yêu cầu (requirement

definition):

Là văn liệt kê yêu cầu chức yêu cầu

không chức năng

Cung cấp đầu vào cho bước q

trình phân tích hệ thống q trình thiết kế

Mục đích quan trọng tài liệu định nghĩa yêu

(153)

4.1.1 Xác định yêu cầu • Xây dựng tài liệu định nghĩa yêu cầu

Xác định loại yêu cầu chức không chức

năng

Sử dụng kỹ thuật thu thập yêu cầu để thu thập

thông tin

Sử dụng kỹ thuật phân tích yêu cầu để kiểm tra,

(154)

(155)

(156)

4.1.2 Các kỹ thuật phân tích yêu cầu

4.1.2 Các kỹ thuật phân tích u cầu • Phương pháp: người kinh doanh người phân

tích làm việc để phân tích yêu cầu

• 3 kỹ thuật phân tích u cầu:

1 Business process automation (BPA): tự động hố q trình kinh doanh

2 Business process improvement (BPI): cải tiến trình kinh doanh

3 Business process reengineering (BPE)

• 3 bước q trình phân tích u cầu:

1 Phân tích tình trạng hệ thống

(157)

4.1.2 Các kỹ thuật phân tích u cầu

• Business process automation (BPA): tự động hố q trình kinh doanh

 Không làm thay đổi hoạt động tại

 Tự động hố 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 vấn đề

hệ thống tìm cách giải chúng hệ thống mới

 Phân tích nguyên nhân gốc (root cause analysis): phân tích

(158)

4.1.2 Các kỹ thuật phân tích yêu cầu • Business process improvement (BPI): cải tiến

quá trình kinh doanh

 Làm thay đổi hoạt động tại

 Cản thiện hiệu suất hiệu hệ thống  Tập trung vào hệ thống để 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 khâu hệ thống tại xác định khâu cải tiến

 Xác định chi phí hoạt động (activity based costing): xác

định chi phí khâu hệ thống xác định các khâu có chi phí cao từ cải tiến để giảm chi phí

 Nghiên cứu kinh nghiệm bên (informal benchmarking):

(159)

4.1.2 Các kỹ thuật phân tích yêu cầu • Business process reengineering (BPR): thay đổi

quá trình kinh doanh

 Làm thay đổi hoạt động tại  3 hoạt động phân tích:

 Phân tích kết (outcome analysis): tập trung phân tích

kết hệ thống có đem lại giá trị cho khách hàng Nhà phân tích khuyến khích nhà quản lý dự án đặt vào vị trí khách hàng suy nghĩ cẩn thận mà sản phẩm dịch vụ đem đến cho khách hàng.

 Phân tích cơng nghệ (technology analysis): Xác định danh

sách công nghệ quan trọng hấp dẫn từ phân tích khả ứng dụng công nghệ vào hoạt động kinh doanh lợi ích việc ứng dụng cơng nghệ đó

 Loại bỏ hoạt động (activity elimination): nhà phân tích nhà

(160)

4.1.2 Các kỹ thuật phân tích u cầu • Lựa chọn kỹ thuật thích hợp, phụ thuộc vào:

 Giá trị kinh doanh tiềm (potential business value)  Chi phí dự án (project cost)

(161)

(162)

4.1.3 Các kỹ thuật thu thập yêu cầu

• 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)

(163)

• Phỏng vấn (Interviews): 5 bước

 Chọn người đựơc vấn

 Thiết kế câu hỏi vấn  Chuẩn bị cho vấn  Thực vấn

(164)

• Phỏng vấn (Interviews): Bước Chọn người

đựơc vấn

 Dựa vào thông tin cần thu thập

 Chọn người đựơc vấn vị trí khác để

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 bị ảnh hưởng hệ thống

(165)

• Phỏng vấn (Interviews): Bước : thiết kế câu hỏi

(166)

phỏng vấn, loại:

Types of Questions Examples

Closed-Ended Questions * How many telephone orders are received per day?

* How customers place orders?

* What additional information would you like the new system to provide?

Open-Ended Questions * What you think about the

current system?

* What are some of the problems

you face on a daily basis?

* How you decide what types of

marketing campaign to run? Probing Questions

* Why?

(167)

phỏng vấn, loại 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 bước dự án

 Phỏng vấn có cấu trúc (Structured interview)

 Các thông tin cụ thể hơn

(168)

(169)

• Phỏng vấn (Interviews): Bước 3: chuẩn bị cho

cuộc vấn

 Chuẩn bị kế hoạch vấn tổng thế

 Liệt kê câu hỏi

 Dự đoán trước câu trả lời câu hỏi tiếp theo

 Khẳng định lại lĩnh vực kiến thức

 Xác định câu hỏi, lĩnh vực ưu tiên trường

hợp không đủ thời gian

 Chuẩn bị cho người vấn

 Xếp lịch

 Thông báo lý vấn

(170)

• Phỏng vấn (Interviews): Bước 4: thực

phỏng vấn

 Phải gây thiện cảm với người vấn:

tỏ chuyên nghiệp không thiên vị

 ghi lại tất thơng tin

 Kiểm tra sách ghi âm vấn  Phải đảm bảo hiểu tất vấn đề thuật ngữ  Phân biệt rõ kiện với ý kiến bình luận

 Dành thời gian cho người đựơc vấn đặt câu hỏi  Nhớ cảm ơn người vấn thông báo

công việc sau vấn

(171)

• Phỏng vấn (Interviews): Bước 4: thực

phỏng vấn, practical tips  Don’t worry, be happy

 Pay attention

 Summarize key points  Be succinct

 Be honest

(172)

• 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ấn vòng 48

tiếng

 Gửi báo cáo cho người vấn để sửa chữa,

(173)

• 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:

(174)

• JAD:

 Allows project managers, users, and developers to

work together to identify requirements

 May reduce scope creep by 50%

(175)

• JAD: Lựa chọn người tham dự vai trị

người

 Facilitator

 sets the meeting agenda and guides the discussion

 Scribe

 assist the facilitator by recording notes, making copies, etc

(176)

• JAD: Thiết lập họp

 U-Shaped seating

 Away from distractions  Whiteboard/flip chart  Prototyping tools

(177)

• JAD: phiên họp JAD

 Tend to last 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

(178)

• JAD: Quản lý vấn đề phiên họp JAD

 Reducing domination

 Encouraging non-contributors  Side discussions

 Agenda merry-go-round  Violent agreement

 Unresolved conflict  True conflict

(179)

(180)

4.1.3 Các kỹ thuật thu thập yêu cầu • Điều tra (Questionnaire), 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

(181)

• Đ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.

(182)

• 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

(183)

• 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

(184)

(185)

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

(186)

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)

(187)

(Functional Modeling)

4.2.2 Mơ hình q trình kinh doanh 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 biểu đồ ca sử dụng

4.2.6 Hiệu chỉnh ước lượng kích thước dự án nhân lực sử dụng điểm ca sử dụng

(188)

• Bước chuẩn bị : Thu thập yêu cầu từ người sử dụng (phần 4.1).

• Bước 1: Sử dụng u cầu thu thập được, mơ hình trình kinh doanh sử dụng biểu đồ hoạt động (activity diagrams)

• Bước 2: Sử dụng hoạt động xác định để xác định ca sử dụng

• Bước 3: Xây dựng mô tả ca sử dụng cho ca sử dụng

• Bước 4: Chuyển tử mơ tả ca sử dụng sang

biểu đồ ca sử dụng để biểu diễn chức hoạt động bên ngồi q trình kinh doanh

(189)

đồ hoạt động (activity diagrams)

• Các phần tử biểu đồ hoạt động

(190)

4.2.2 Mơ hình q trình kinh doanh biểu

• Biểu đồ hoạt động dùng để mơ hình hố q trình kinh doanh mức cao (high level business process)

• Các phần tử biểu đồ hoạt động

 Hành động (action)

Là phần tử đơn giản biểu diễn hoạt động 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 hành động

 Nốt đối tượng (object node)

Biểu diễn đối tượng kết nối với luồng đối tượng Tên nốt đối tượng tên lớp đối tượng

 Luồng điều khiển (control flow) Biểu diễn chuỗi hoạt động

Make appointment

(191)

• Các phần tử biểu đồ hoạt động (tiếp theo) Luồng đối tượng (object flow)

Biểu diễn luồng đối tượng từ hoạt động sang hoạt

động khác

Nốt khởi đầu (initial node)

Biểu diễn điểm bắt đầu tập hợp hoạt động

Nốt kết thúc hoạt động (final activity node)

Kết thúc toàn luồng điều khiển luồng đối tượng

Nốt kết thúc luồng (final flow node)

(192)

• Các phần tử biểu đồ hoạt động (tiếp theo) 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 theo đường

Nốt gộp (merge node)

(193)

• Các phần tử biểu đồ hoạt động (tiếp theo) Nốt chia (fork node)

Chia hoạt động thành luồng hoạt động song song

Nốt kết hợp (join node)

(194)

4.2.2 Mơ hình trình kinh doanh biểu

(195)

• Xây dựng biểu đồ hoạt động:

1 Xác định phạm vi ngữ cảnh trình kinh

doanh đặt cho biểu đồ hoạt động tiêu đề phù hợp 2 Xác định hoạt động, luồng điều khiển, luồng đối

tượng diễn hoạt động

3 Xác định định lựa chọn trình kinh doanh

4 Xác định khả thực song song hoạt động (nếu có).

(196)

4.2.2 Mơ hình trình kinh doanh biểu

• 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

(197)

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

(198)

(199)

4.2.3 Mô tả ca sử dụng

4.2.3 Mơ tả ca sử dụng

• Một ca sử dụng miêu tả hoạt động người sử dụng hệ thống khác tác động lên hệ thống.

• Ca sử dụng mơ hình logic chúng miêu tả

hoạt động hệ thống mà không miêu tả hoạt động thực

• Ca sử dụng miêu tả chức hệ thống:

Người sử dụng làm gì Hệ thống đáp ứng nào

• Ca sử dụng dùng để mơ tả hệ thống

hiện hệ thống cần xây dựng

(200)

4.2.3 Mô tả ca sử dụng

4.2.3 Mô tả ca sử dụng • 2 bước để xây dựng biểu đồ ca sử dụng

 Viết mô tả ca sử dụng

Chuyển từ mô tả ca sử dụng sang biểu đồ ca sử

dụng

• Mỗi ca sử dụng miêu tả

chức hệ thống

• Để xác định nội dung ca sử dụng, người phát

Định dạng
Số trang	346
Dung lượng	18,63 MB