slide phan tich thiet ke he thong huong doi tuong dai hoc bach khoa ha noi

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

(Object (Object Oriented System Oriented System Analysis and Design)Analysis and Design)

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

2/Chapter© DHBK 2007

Giới thiệuGiớ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ênNộ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ọcTrang 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 dungNộ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ảoTà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

http://www.uml.org/

http://www.google.com/


Chương 1. Giới thiệu chung về phân Chương 1. Giới thiệu chung về phân tích và thiết kế hệ thốngtí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ệu1.1 Giới thiệu


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

• 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


1.2 Quy trình phát triển hệ thống1.2 Quy trình phát triển hệ thốngLập kế hoạchLậ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


1.2 Quy trình phát triển hệ thống1.2 Quy trình phát triển hệ thốngPhân tíchPhâ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


1.2 Quy trình phát triển hệ thống1.2 Quy trình phát triển hệ thốngThiế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 • Thiết kế cơ sở dữ liệu• Thiết kế chương trình


1.2 Quy trình phát triển hệ thống1.2 Quy trình phát triển hệ thốngTriển khaiTriển khai

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


1.2 Quy trình phát triển hệ thống1.2 Quy trình phát triển hệ thốngCác pha và kết quả của từng phaCác pha và kết quả của từng pha

Process Product

Planning

Analysis

Design

Implementation

Project Plan

System Proposal

System Specification

New System and Maintenance

Plan


1.3 Các phương pháp phát triển hệ 1.3 Các phương pháp phát triển hệ thốngthố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úc1.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


1.3.1 Thiết kế cấu trúc1.3.1 Thiết kế cấu trúcPhương pháp thác nướcPhương pháp thác nước


1.3.1 Thiết kế cấu trúc1.3.1 Thiết kế cấu trúcPhương pháp thác nướcPhươ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)


1.3.1 Thiết kế cấu trúc1.3.1 Thiết kế cấu trúcPhương pháp phát triển song songPhương pháp phát triển song song


1.3.2 RAD1.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 RAD1.3.2 RADPhương pháp phát triển theo phaPhương pháp phát triển theo pha

20/Chapter© DHBK 2007 1.3.2 RAD1.3.2 RADPhương pháp xây dựng nguyên mẫu thông Phương pháp xây dựng nguyên mẫu thông

thườngthường


1.3.2 RAD1.3.2 RADPhương pháp xây dựng nguyên mẫu loại bỏ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ợp1.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ợp1.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à Chương 2: Giới thiệu về phân tích và thiết kế hướng đối tượng với UMLthiế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



• 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 LanguagesSmalltalk, C++, Java



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



• Lịch sử phát triển của 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,…)Stroustrup, Harel, Wirfs-Brock, Reenskaug,…)

JacobsonJacobsonBoochBoochRumbaughRumbaugh

UML 1.1 (OMG Standard)UML 1.1 (OMG Standard)UML 1.1 (OMG Standard)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)

UML 1.4.1UML 1.4.1UML 1.4.1UML 1.4.1

1996

1997

1998

20012002

2003

UML 2.0UML 2.0UML 2.0UML 2.0



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



• 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 2.2 Các đặc điểm cơ bản của hệ thống hướng đối tượnghướ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)


2.2.1 Lớp và đối tượng2.2.1 Lớp và đố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 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 };


2.2.2 Phương thức và message2.2.2 Phương thức và message

• 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.2 Phương thức và message2.2.2 Phương thức và message


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

• Encapsulation combination of data and process into an entity

• Information HidingOnly the information required to use a software module

is published to the user


2.2.4 Thừa kế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.5 Đa hình thái và liên kết động2.2.5 Đa hình thái và liên kết động

• PolymorphismA message can be interpreted differently by different

classes of objects

• Dynamic BindingSometimes called late bindingDelays typing or choosing a method for an object until

run-time

• Static BindingType of object determined at compile time


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

1 // Fig. 20.1: shape.h2 // Definition of abstract base class Shape3 #ifndef SHAPE_H4 #define SHAPE_H56 class Shape {7 public:8 virtual double area() const { return 0.0; }9 virtual double volume() const { return 0.0; }1011 // pure virtual functions overridden in derived classes12 virtual void printShapeName() const = 0;13 virtual void print() const = 0;14 };1516 #endif17 // Fig. 20.1: point1.h18 // Definition of class Point19 #ifndef POINT1_H20 #define POINT1_H2122 #include <iostream>2324 using std::cout;2526 #include "shape.h"2728 class Point : public Shape {29 public:30 Point( int = 0, int = 0 ); // default constructor31 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

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 = 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

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

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


118private:

119 double height; // height of Cylinder

120};

121

122#endif

123// Fig. 20.1: cylindr1.cpp124// Member and friend function definitions for class Cylinder125#include <iostream>126127using std::cout;128129#include "cylindr1.h"130131Cylinder::Cylinder( double h, double r, int x, int y )132 : Circle( r, x, y ) // call base-class constructor133{ setHeight( h ); }134135void Cylinder::setHeight( double h )136 { height = h > 0 ? h : 0; }137138double Cylinder::getHeight() { return height; }139140double Cylinder::area() const141{142 // surface area of Cylinder143 return 2 * Circle::area() +144 2 * 3.14159 * getRadius() * height;145}146147double Cylinder::volume() const 148 { return Circle::area() * height; }149150void Cylinder::print() const151{152 Circle::print();153 cout << "; Height = " << height;154}

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

2. Function calls

186 point.print(); // static binding187 cout << '\n';188189 circle.printShapeName(); // static binding190 circle.print(); // static binding191 cout << '\n';192193 cylinder.printShapeName(); // static binding194 cylinder.print(); // static binding195 cout << "\n\n";196197 Shape *arrayOfShapes[ 3 ]; // array of base-class pointers198199 // aim arrayOfShapes[0] at derived-class Point object200 arrayOfShapes[ 0 ] = &point;201202 // aim arrayOfShapes[1] at derived-class Circle object203 arrayOfShapes[ 1 ] = &circle;204205 // aim arrayOfShapes[2] at derived-class Cylinder object206 arrayOfShapes[ 2 ] = &cylinder;207208 // Loop through arrayOfShapes and call virtualViaPointer209 // 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";213214 for ( int i = 0; i < 3; i++ ) 215 virtualViaPointer( arrayOfShapes[ i ] );216217 // Loop through arrayOfShapes and call virtualViaReference218 // 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.

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

247}


2.3 UML 2.02.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ề UML2.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.”

• 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

Grady Booch, Ivar Jacobsen, Jim Rumbaugh Rational Software


2.3.1 Giới thiệu về UML2.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úcBiểu đồ mô hình chức năng


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

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


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

• 8 loại biểu đồ chức năngBiể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








2.3.4 Các cơ chế mở rộng2.3.4 Các cơ chế mở rộ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ắt2.3.5 Tóm tắt


2.4 Phân tích và thiết kế hướng đối 2.4 Phân tích và thiết kế hướng đối tượng với UML 2.0tượ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 OOAD2.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


2.4.2 Ưu điểm của OOAD2.4.2 Ưu điểm của OOAD

• 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.2 Ưu điểm của OOAD2.4.2 Ưu điểm của OOAD


2.4.3 The Unified process2.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, RumbaughLà phương pháp hướng đối tượngKhông phải là một quy trình phát triển phần mềm hoàn

thiệnKhông xét đến các vấn đề về phân bổ nhân lực, ngân quỹ, quản

lý hợp đồngKhông quy định về các hoạt động bảo trì hay hỗ trợ khách hàngKhô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ự ánCác yêu cầu và ràng buộc quan trọngKế hoạch dự án bước đầuMiêu tả tính khả thi và rủi ro của dự ánLự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ự ánCác bước liên quan:

Thu thập yêu cầu (requirements)Phân tích (analysis)*Thiết kế (design)*Thực hiện (implementation)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ả:Biểu đồ cấu trúc và chức năng UMLPhiê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ìnhCác bước liên quan:

Thu thập yêu cầu (requirements)Phân tích (analysis)Thiết kế (design)Thực hiện (implementation)*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 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 khaiCác bước liên quan:

Thu thập yêu cầu (requirements)Phân tích (analysis)Thiết kế (design)Thực hiện (implementation)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ốngHướng dẫn sử dụngKế 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 MOOSAD2.4.4 MOOSAD


Chương 3. Lập kế hoạchChươ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ự án3.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


3.1.1 Giới thiệu3.1.1 Giới thiệu

Nhu cầu kinh doanhTà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




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


3.1.2 Yêu cầu hệ thống (system request)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 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 doanhPhòng ITChuyê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 tranhcô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ệtví dụ: thời hạn hoàn thành


Case study: CD selectionsCase 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 ở CaliforniaDoanh số bán hàng: 50 triệu USDTăng trưởng 3-5 % / nămCó 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 selectionsCase study: CD selections


3.1.3 Phân tích tính khả thi3.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ụngMứ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ìnhLợi nhuận vô hình





• Khả thi về kinh tế (economic feasibility) (should we build 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



• Khả thi về kinh tế (economic feasibility) (should we build 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





• Khả thi về kinh tế (economic feasibility) (should we build 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



• Khả thi về kinh tế (economic feasibility) (should we build 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ự án3.1.4 Lựa chọn dự án

• 3 phương án:Thông quaLoạ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ốnSố lượng và chất lượng các dự án khác


3.2 Quản lý dự án3.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.2.2 Xác định kích thước dự án3.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ốngThời gian hoàn thành dự ánChi phí của dự án

• 2 phương pháp ước lượng kích thước dự ánPhương pháp đơn giản dựa trên chuẩn công nghiệpPhươ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

IndustryStandardFor Web 15% 20% 35% 30%Applications

TimeRequired 4 5.33 9.33 8in PersonMonths



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



• Phương pháp điểm chức năngXác định kích thước hệ thống theo điểm chức năng và

số dòng lệnh1 đ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



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

Adjusted Processing Complexity (APC)

= .65 + (0.01 * Processing Complexity)

Total Adjusted Function Points (TAFP)

= Adjusted Processing Complexity * TUFP



Tính độ phức tạp xử lý hiệu chỉnh (adjusted 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

CCOBOLJAVAC++Turbo PascalVisual BasicPowerBuilderHTMLPackages (e.g., Access, Excel)

130110 55 50 50 30 15 1510-40

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

Example:

If LOC = 20000 Then...Effort = (1.4 * 20) = 28 Person

Months




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 3.2.3 Xây dựng và quản lý kế hoạch công việccô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 ...



• Ví dụ về một bản kế hoạch công việc:

Work Plan Information Example

Name of task Perform economic feasibilityStart date ` Jan 05, 2001Completion date Jan 19, 2001Person assigned Mary Smith, sponsorDeliverable(s) Cost-benefit analysisCompletion status OpenPriority HighResources needed SpreadsheetEstimated time 16 hoursActual time 14.5 hours



• 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



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

PhasesPhases with

high level steps

Work Plan Deliverables Estimated Assignedduration To

****



• 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





• 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



• 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ệcCá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: OKhả năng cao: M (most likely)Bi quan: P

Thời gian ước lượng = (O + 4 * M + P)/6



• Biểu đồ PERT

X: Hoàn thành\: đang thực hiện


3.2.4 Sắp xếp nhân lực cho dự án3.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 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ọngSử dụng các khích lệ tinh thần:

Công việc hấp dẫn, thách thứcTinh thần trách nhiệmNhu cầu tiến thủCơ hội để học kỹ năng mớiNhu cầu tự khẳng định mìnhSự 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ómLập bảng quy định, nội quy của nhómDự đoán các ưu tiên khác và khả năng ảnh hưởng của

chúng tới dự án


3.2.5 Điều phối hoạt động dự án3.2.5 Điều phối hoạt động 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 EstimatesPhase Deliverable Cost (%)time (%)

Planning System Request 400 60Project Plan 100 25

Analysis System Proposal 5015

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ếnNguyê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ạnBiệ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 Steps1. 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:

Initiation Analysis Design Implementation

Upper CASE Lower CASE

Integrated CASE (I-CASE)

CASE (computer-aided software engineering) tool – CASE (computer-aided software engineering) tool – Software that automates all of part of the development Software that automates all of part of the development

processprocess



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

• Standardisation: ExamplesFormal rules for naming filesForms indicating goals reachedProgramming guidelines and Coding standard

• DocumentationProject binder: all deliverables and all the internal

communications within a projectTable of contents Continual updating



• Quản lý rủi ro:Risk assessment: a document assesses a potential risk

including: Risk No and its brief descriptionLikelihood of riskPotential impact on the project Ways to address the risk

Actions to reduce riskRevised assessment



• Quản lý rủi ro:Avoiding Classic Planning Mistakes

Overly optimistic scheduleFailing to monitor scheduleFailing to update scheduleAdding people to a late project


3.2.6 CD selections3.2.6 CD selections


Chương 4. Phân tích hệ thốngChươ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ốngChương 4. 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


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ả thiKế hoạch công việc

+

Yes

Thiết kế hệ thống


4.1 Xác định yêu cầu của hệ thống4.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


4.1.1 Xác định yêu cầu4.1.1 Xác định yêu cầu

• 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ăngKhả năng hoạt độngAn ninhyê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ăngCung 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ầuXác định các loại yêu cầu chức năng và không chức

năngSử dụng các kỹ thuật thu thập yêu cầu để thu thập

thông tinSử 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






4.1.2 Các kỹ thuật phân tích yêu cầu4.1.2 Các kỹ thuật phân tích 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 quá trình kinh doanh 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 quá trình kinh doanh 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


4.1.3 Các kỹ thuật thu thập yêu cầu4.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)• 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 (Interviews): Bước 2 : thiết kế câu hỏi 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?

Probing Questions

* Why?* Can you give me an example?* Can you explain that in a bit more detail?



• Phỏng vấn (Interviews): Bước 2 : thiết kế câu hỏi 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 (Interviews): Bước 2 : thiết kế câu hỏi 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:



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



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ăng4.2 Mô hình hoá chức năng(Functional Modeling)(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 4.2.2 Mô hình quá trình kinh doanh bằng biểu đồ hoạt động (activity diagrams)đồ 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ơnTê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

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ượngTên của nốt đối tượng là tên lớp của đối tượng

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

Make appointment

Class name



• 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



• Các phần tử của 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 chỉ đi theo 1 đường

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

[điều kiện] [điều kiện]



• Các phần tử của biểu đồ hoạt động (tiếp theo)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 selectionsInternet Order System – Functional requirements:1. Maintain CD Information

1.1…… 1.2….. 1.3…..

2. Maintain CD marketing information2.1…. 2.2…. 2.3….

3. Place CD Orders3.1 Search CDs from “CD Selection” web site; 3.2 Place orders; 3.3……

4. Maintain Orders4.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



• VD: CD selectionsExercise: 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



• VD: CD selections

Place CD Order

Maintain CD marketing

information

Maintain CD Information

Place instore hold

Place special order

[If available in near store] [If not]


4.2.3 Mô tả ca sử dụng4.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 có thể được dùng để mô tả hệ thống hiện tại và hệ thống cần xây dựng

Ca sử dụng miêu tả tương tác giữa người sử dụng và hệ thố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 Descriptions1. 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 action3. Write from independent observer perspective4. Write at same level of abstraction5. Ensure a sensible set of steps6. Apply KISS (keep it simple, stupid) principle liberally7. Write repeating instructions after the set of steps to

be repeated.


4.2.4 Biểu đồ ca sử dụng4.2.4 Biểu đồ ca sử dụng

An Actor

A use case

A Subject Boundary

An associate relationship










4.2.5 Xây dựng mô tả ca sử dụng và 4.2.5 Xây dựng mô tả ca sử dụng và Biểu đồ ca sử dụngBiểu đồ ca sử dụng

• 4 bước chính:Bước I. Xác định các ca sử dụng chínhBước II. Mở rộng ca sử dụng chínhBước III. Khẳng định lại các ca sử dụng chínhBướ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ính1. 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:

Place CD Order

Maintain CD marketing

information

Maintain CD Information

Maintain CD Order



• Bước I: Ví dụIdentify and write the major (overview) use-cases

Use case name Primary actor

Relationship

Association Include Exclude

Maintain marketing information

Vendor Vendor

Maintain CD information

Distribution system

Distribution 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ính6. 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ính12.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ụng1. 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ệ


Use case name Primary actor Relationship

Association Include Extend

Maintain marketing information

Vendor Vendor


Distribution system

Distribution system

Place order Customer Customer Check out Maintain order

Check out Customer Customer, Credit Centre

Maintain order

Maintain order Customer Place Instore hold

Place special order

Place Instore hold Customer Store

Place special order Customer Store

Exercise: Draw use-case diagram Question. Suppose that 7 major use cases have been identified as

below, draw the corresponding use-case diagram


Maintain CD marketing information


Maintain CD order

Place CD order

Place instore hold

Place special order

<<include>>

<< extend >><<actor>>

Store

<<actor>> Distribution

System

Check out

<<include>>

<<actor>> Credit Card

Centre


4.3 Mô hình hoá cấu trúc4.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.


4.3.2 Các phần tử của mô hình cấu trúc4.3.2 Các phần tử của mô hình cấu trúc

• 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ọngCá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


4.3.2 Các phần tử của mô hình cấu trúc4.3.2 Các phần tử của mô hình cấu trúc

• 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-4.3.3 Thẻ CRC (Class-Responsibility-Collaboration)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ệcMô 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






4.3.4 Biểu đồ lớp4.3.4 Biểu đồ lớp



• Cú pháp:

A CLASS

AN ATTRIBUTE

AN OPERATION

AN ASSOCIATION

Class 1

-attribute

+operation ()

Attribute name/derived attribute name

operation name ()

1..* 0..1______verb phrase____



• Thuộc tính:Derived attributes

/age, for example can be calculated from birth date and current date

VisibilityPublic: +Protected: #Private: -



• Hoạt động (operations):Constructor

Creates object

QueryMakes information about state available

UpdateChanges values of some or all attributes



• Quan hệ:Multiplicity of relationship

exactly one: 1zero or more: 0..*one or more: 1..*zero or one: 0..1specified range: 2..4multiple disjoint ranges: 1..5,7



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


4.3.5 Xây dựng thẻ CRC và biểu đồ lớp4.3.5 Xây dựng thẻ CRC và biểu đồ lớp

Three common approaches1. 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


Textual Analysis: Nouns suggest classes

Step 1. Create CRC cards by performing Step 1. Create CRC cards by performing textual analysis on the use-casestextual analysis on the use-cases


• 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: Nouns suggest classes


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

Select CD for Info

Place Order

CD List

Get Credit Card

Info Exit

Order Credit Card Centre

This forms the front of “Customer class” CRC Card

Not include as it can be included in Search request


Textual Analysis: Verbs suggest operations:


• 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 Step 2 and 3. Examine Common Object Lists and Role-play the CRC CardsRole-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. Step 4. Create the Class Diagram based on the CRC Create the Class Diagram based on the CRC CardsCards

• 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. Step 4. Create the Class Diagram based on the CRC Create the Class Diagram based on the CRC CardsCards

• Solution:

Customer

-First name-Middle initial-Last name-……+Make search req()+Place order()+Get credit info()+Exit()

Credit Card CentreOrder

Search Reg

Check ->

0..*

0..*

place ->

0..*1

Make ->0..*0..*


Step 5, 6 and 7: Review Classes Diagrams, Step 5, 6 and 7: Review Classes Diagrams, Incorporate Patterns, and Review the ModelIncorporate 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 động4.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)


4.4.2 Biểu đồ tương tác4.4.2 Biểu đồ tương tác

• 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ụngBiể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 đồ



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 Reviews5. 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 Application Example: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ếp1. 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 Technique to Identify Collaborations between Objects - “CRUD” AnalysisObjects - “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 ExampleCRUD” Analysis Example

C

C



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





4.4.3 Biểu đồ máy trạng thái4.4.3 Biểu đồ máy trạng thái

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



• 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

stateEvent [guard]/activity

transition

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



• 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



The Life of an Order Object:




Chương 5. Thiết kế hệ thốngChươ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 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ế


• Factoring: Creating modules* that reflect similarities and differences

between units of interestHere, module = new class | new method

New classes can be represented by:- GeneralizationAggregation

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

5.1.1 Chuyển từ mô hình phân tích sang 5.1.1 Chuyển từ mô hình phân tích sang mô hình thiết kếmô hình thiết kế


• Partitions and Collaborations Creating subsystems*, i.e. collections (usually sets) of related

componentsIn 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ói5.1.2 Gói và biểu đồ gói

Package = UML representation Package = UML representation (or abstraction over) (or abstraction over)

collaboration OR partition OR layer 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


5.1.2 Gói và biểu đồ gói5.1.2 Gói và biểu đồ góiVí dụVí dụ


Collaborations, partitions and layersCollaborations, 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 SystemPackage Diagram of Appointment System

Patient UI

dependent on Patient classDM-Patient class

dependent on Patient class

Patient table

dependent on Patient class

Problem domain Classes:Patient, Appt.

Separated from object persistence Classes: Patient table,Appt. table

by intermediate Data Access and Manipulation (DM) Classes:DM-Patient, DM-Appt

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 DiagramsSteps 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 2007Step 2: Cluster classes together based on shared relationships, i.e. form partitions using relationships (generalisation, aggregation, kinds of association and message passing between objects) shared by classes

Examine analysis modelsClass 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 Step 3: Place clustered classes in partition and model clustered classes as a package, i.e. model package, i.e. model partitionspartitions as as packagespackages


Step 4: Identify Step 4: Identify dependency relationshipsdependency relationships between packages, i.e. relationships that cross between packages, i.e. relationships that cross boundaries of packages = potential dependenciesboundaries of packages = potential dependencies

a) association relationship between

Person Pkg and Appt. Pkg via Association between Doctor

class and Appt. class and Patient Pkgcontained in Person Pkg

b) Appt. pkg via association between Patient and Appt classesand Treatment Pkg via association between Patient and Symptom

classes


Step 5: Place dependency relationships between packages, i.e. between Person Package and Step 5: Place dependency relationships between packages, i.e. between Person Package and Appt. Package, Person Package and Treatment PackageAppt. Package, Person Package and Treatment Package

Show dependency relations as “pure” package diagram showing ONLY dependency relations Show dependency relations as “pure” package diagram showing ONLY dependency relations that CAN be createdthat CAN be createdbetween packages between packages

PD Layer

Appt. Package

Treatment Package

Person Package

Patient Package

292/Chapter© DHBK 2007 Worked Example: Applying Concepts at CD Selections: First, previous Worked Example: Applying Concepts at CD Selections: First, previous lectures...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

293/Chapter© DHBK 2007 Example: Applying Concepts at CD SelectionsExample: Applying Concepts at CD Selections• Set the context = Problem Domain Layer

• Cluster classes, i.e. review relationships amongst classes

CD Selections Class Diagram (Places Order Use-Case View)

Sequence Diagram (Places Order Use Case)

Communication Diagram (Place Order Use Case)

294/Chapter© DHBK 2007• 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

295/Chapter© DHBK 2007• Association relationship (between CD class and Mkt Info class) and message sending pattern of activity = place in same partition

• Also, Vendor class only related to CD class = same partition (as CD and Market Info classes)

• 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

296/Chapter© DHBK 2007• 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)

297/Chapter© DHBK 2007Place the dependency relations on the package diagram (and increase clarity by dependency 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 relationships between packages = pure package diagram of PD layer of CD Selections containing highest level packages only (+ Credit Card Centre class) and their dependency relationshipshighest level packages only (+ Credit Card Centre class) and their dependency relationships


5.1.3 Các chiến lược thiết kế5.1.3 Các chiến lược thiết kế

• 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 problemse.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 componentse.g. for CD selections all components in custom application are available and can be reused in whole or part

• Usually increases personnel skillse.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 skillTheir 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 criteriaTime and arrangement dealFixed priceValue added contract



• Outsourcing Guidelines

Keep lines of communication open with outsourcerDefine and stabilize requirements before signing a

contractView outsourcing relationship as partnershipSelect outsource vender carefullyAssign person to manage relationshipDon’t outsource what you don’t understandEmphasize 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 experienceCustom 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 skillsTechnical, e.g. Java programming and IDE skills, data design

and SQL programming skillsFunctional, e.g. in electronic commerceIf 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 frameIf 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ế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 providedn.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.1.4 Phát triển thiết kế thực tế


5.2 Thiết kế lớp và phương thức5.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


5.2.2 Các tiêu chí thiết kế5.2.2 Các tiêu chí thiết kế

• 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) ItselfB) 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 mehodD) An object created by the methodE) 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 methodCalling method depends on value returned by called method



• Cohesion: Refers to how single-minded a module is within a system 3 types of cohesion:

MethodClass 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 thingA 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 encapsulationMinimize 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:


5.2.3 Các hoạt động thiết kế đối tượng5.2.3 Các hoạt động thiết kế đối tượng

• 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 problemFinalize the visibility of the attributes and methods of

each classDetermine the signature of every method of each classDefine constraints to be preserved by objects



• Identifying opportunities for reuse:Analysis patterns

Representations of the problem-domain

Design patternsUseful grouping of collaborating classes that provide a solution

to a commonly occurring problemMany design patterns are available in C++ or Java source code

FrameworksA set of implemented classes that can be used as a basis for

implementing an applicationMost frameworks allow us to create subclasses to inherit from

classes in the framework

Librariescomponents



• Identifying opportunities for reuse:Libraries

Class library similar to framework, i.e. has classes designed for reuseMore domain specific, i.e. can be used to realise some layer, e.g. HIC

layerCan 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



• Identifying opportunities for reuse:Components:

Self-contained & encapsulated software that can be plugged into a system

Provides specific funtionalityTypically components implemented using ActiveX or JavaBeanComponent has well-defined Application Program Interface

(API)API = set of method interfaces to objects contained in

componentInternal operation of component hidden by APIComponents can be implemented using class libraries and

frameworksUnless API changes between between version of component,

only need to relink component to application (no recompilation required)



• Identifying opportunities for reuse:



• 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

NormalizationIdentifies classes missing from the designAll association and aggregation relationships converted to

attributes of the class Challenge inheritance relationships to ensure they only support a

generalization/specialization semantics



• Optimizing the designSimple 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



• Optimizing the design[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



• Optimizing the design[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



• Map Problem Domain Classes to Implementation Languages: OO designs assume class-based OO programming language used

to implement those designse.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



• Map Problem Domain Classes to Implementation Languages:


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..1Add an exclusive-OR constraint between associationsAdd 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





SuperClass1-attribute1-attribute2



Class1-attribute5-attribute6


concrete

0..*

1..1

0..*

1..1

{XOR} [1]All classes preserved[2]Increases amountof message passing[3]Adds to processing requirement due to XOR








Class1

-attribute5-attribute6

Class2




PotentialInheritanceConflicts

abstract




[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

0..*

1..1

0..*

1..1

{XOR}1..11..1

1..11..1




[2] implementation language is object-based and not class-based




Class1


Class2




If all superclasses areabstract





PotentialInheritanceConflicts




[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

PolymorphismDynamic bindingEncapsulation Information hiding


5.2.4 Ràng buộc và giao kèo5.2.4 Ràng buộc và giao kèo

• 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 attributesMultiplicity of attributesLegal values of attributes including attributes that model

association and aggregation and relationshipse.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


• Example:-

Back:

Order Number (1:1) (unsigned long)Attributes:

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()}

Relationships:Generalisation(a-kind-of):

Aggregation (has-parts):

Other Associations: Product{1..*} Customer(1..1} State{1..1}

Attribute Constraint:Order Number IS unsigned long

Attribute Constraint:Customer IS INSTANCE OFCustomer Class

Attribute Constraint:Cust ID IS unsigned LongANDInvariant MUST HAVE one and ONLY one value(1..1) = GetCustID()Customer.

Constraint: Instance of Order EXISTSIF (instance of Customer class AND instance of State class AND >=1 instance of Product class) ASSOCIATED WITH order object


Invariants On a Invariants On a Class Diagram(Not recommended Class Diagram(Not recommended

– Use CRC card for Invariants)– Use CRC card for Invariants)

Order-Order Number: unsigned long-Date[1..]: Date-Sub Total[0..1]: double-Tax[0..1]:double-Shipping[0..1]:double-Total[0..1]double-Tax[0..1]: double-Customer[1..1]: Customer-Cust ID[1..1]: unsigned long-State[1..1] State-State Name[1..1: String

Customer

-Cust ID-Last Name-First Name

1..1 0..*

Product

-Product Number-Product Desc-Price0..* 1..*

State

-StateTax RateProduct Desc

0..* 1..1

Product Order

OrderProductQuantityExtension

<<invariant>>{Cust ID=Customer.GetCustID()}

<<invariant>>{State Name=State.GetState()}

<<invariant>>{Tax=State.GetTaxRate()

*SubTotal}

<<invariant>>{Sub Total=

Sum(Product Order.GetExtension())}}



• 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


Specific Method OF specific ClassUnique Contract ID

List of classes and methodsthat send a message to thismethodList of use cases containing

this method where method isused to realise implementation of the use case (from server class’s CRC card and associateduse 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ức5.2.5 Xác định phương thức

• General information• Events• Message passing• Algorithm specification

Structured EnglishPseudocodeUML activity diagram


Method Name Class Name ID:

Contract ID Programmer: Date Due:

Programming Language: Visual Basic SmallTalk C++ Java

Triggers/Events

Arguments Received: Data Type:

Notes:

Messages Sent & Arguments Passed ClassName.MethodName: Data Type: Notes:

Argument Returned: Data Type:

Notes:

Algorithithm Specification:

General Information (for managing programming effort)

e.g. user initiated event(mouse event, keystroke event), system event or event initiated by another method

Message passing to and from method(c.f. sequence and collaboration diagrams)Arguments = attributes and data structuresin implemented method


• Structured English will suffice for algorithm specification…

Algorithm Specification:

Action Statement Examples: Profits = Revenues – ExpensesGenerate 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 IF Income < 20,000: Marginal-tax-rate = 20 percent IF Income < 30,000: Marginal-tax-rate = 31 percent IF Income < 40,000: Marginal-tax-rate = 35 percent ELSE Marginal-tax-rate = 38 percentENDCASE

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

Documents

slide phan tich thiet ke he thong huong doi tuong dai hoc bach khoa ha noi