Slide Phan Tich Thiet Ke He Thong Huong Doi Tuong Dai Hoc Bach Khoa Ha Noi
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View Slide Phan Tich Thiet Ke He Thong Huong Doi Tuong Dai Hoc Bach Khoa Ha Noi as PDF for free.
More details
- Words: 20,380
- Pages: 346
Phân tích và thiết kế hướng đối tượng (Object Oriented System Analysis and Design) Giảng viên: Phạm Ngọc Nam
2/Chapter
© DHBK 2007
Giới thiệu • 4 ĐVHT = 60 tiết • Học trên lớp + Bài tập lớn • Điểm = Điểm thi + Điểm bài tập lớn (70%) + (30%) • Điều kiện thi: Phải có bài tập lớn • Bài tập lớn: Làm theo nhóm tối đa 5 sinh viên Nội dung: phân tích và thiết kế hệ thống sử dụng Rational Rose Đề tài: sinh viên tự chọn đề tài
• Mục đích của môn học Trang bị cho sinh viên một phương pháp có hệ thống để phân tích và thiết kế hệ thống
3/Chapter
© DHBK 2007
Nội dung 1. Giới thiệu chung về phân tích và thiết kế hệ thống 2. Giới thiệu về phân tích và thiết kế hướng đối tượng với UML 3. Lập kế hoạch 4. Phân tích hệ thống 5. Thiết kế hệ thống 6. Triển khai hệ thống
4/Chapter
© DHBK 2007
Tài liệu tham khảo • Systems Analysis and Design with UML Version 2.0-An object oriented approach; Alan Dennis, Barbara Haley Wixom, David Tegarden. • www.uml.org • www.rational.com • www.Google.com
© DHBK 2007
5/Chapter
Chương 1. Giới thiệu chung về phân tích và thiết kế hệ thống
1.1 Giới thiệu 1.2 Quy trình phát triển hệ thống 1.3 Các phương pháp phát triển hệ thống
6/Chapter
© DHBK 2007
1.1 Giới thiệu
7/Chapter
© DHBK 2007
1.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
© DHBK 2007
• • • • •
8/Chapter
1.2 Quy trình phát triển hệ thống Lập kế hoạch
Xác định giá trị kinh doanh của hệ thống Phân tích tính khả thi Xây dựng kế hoạch công việc Xác định nguồn nhân lực cho dự án Điều khiển và quản lý dự án
© DHBK 2007
• • • •
9/Chapter
1.2 Quy trình phát triển hệ thống Phân tích
Phân tích hệ thống Thu thập các nguồn thông tin Mô hình hoá quá trình Mô hình hóa dữ liệu
© DHBK 2007
• • • • •
10/Chapter
1.2 Quy trình phát triển hệ thống 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
© DHBK 2007
11/Chapter
1.2 Quy trình phát triển hệ thống Triển khai
• Xây dựng hệ thống • Cài đặt hệ thống
© DHBK 2007
12/Chapter
1.2 Quy trình phát triển hệ thống Các pha và kết quả của từng pha Process
Product
Planning
Project Plan
Analysis
System Proposal
Design Implementation
System Specification New System and Maintenance Plan
© DHBK 2007
13/Chapter
1.3 Các phương pháp phát triển hệ thống
• Thiết kế cấu trúc (Structured design) Phương pháp thác nước (waterfall method) Phương pháp phát triển song song (Parallel development)
• Phương pháp phát triển nhanh ứng dụng (RAD) Phương pháp phát triển theo các pha Phương pháp xây dựng nguyên mẫu (prototyping) Thông thường (regular) Loại bỏ (throwaway)
• Phương pháp phát triển rất nhanh (Agile development) XP (extreme programming)
14/Chapter
© DHBK 2007
1.3.1 Thiết kế cấu trúc • Dự án sẽ tiến triển từ bước này sang bước tiếp theo một cách có hệ thống • Thông thường, một bước phải được hoàn thành trước khi bắt đầu bước tiếp theo
© DHBK 2007
1.3.1 Thiết kế cấu trúc Phương pháp thác nước
15/Chapter
© DHBK 2007
1.3.1 Thiết kế cấu trúc Phương pháp thác nước
16/Chapter
• Ư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)
© DHBK 2007
17/Chapter
1.3.1 Thiết kế cấu trúc Phương pháp phát triển song song
18/Chapter
© DHBK 2007
1.3.2 RAD • Các nhân tố quan trọng:
Công cụ CASE JAD Ngôn ngữ lập trình thế hệ thứ tư/ visual Công cụ tạo mã
© DHBK 2007
19/Chapter
1.3.2 RAD Phương pháp phát triển theo pha
© DHBK 2007
1.3.2 RAD Phương pháp xây dựng nguyên mẫu thông thường
20/Chapter
© DHBK 2007
21/Chapter
1.3.2 RAD Phương pháp xây dựng nguyên mẫu loại bỏ
22/Chapter
© DHBK 2007
1.3.3 Lựa chọn phương pháp phù hợp • Tiêu chí:
Độ rõ ràng, đầy đủ của các yêu cầu của người sử dụng Khả năng, mức độ thành thạo về công nghệ Độ phức tạp của hệ thống Độ tin cậy của hệ thống Quỹ thời gian
© DHBK 2007
23/Chapter
1.3.3 Lựa chọn phương pháp phù hợp
© DHBK 2007
24/Chapter
Chương 2: Giới thiệu về phân tích và thiết kế hướng đối tượng với UML
2.1 Giới thiệu 2.2 Các đặc điểm cơ bản của hệ thống hướng đối tượng 2.3 UML 2.0 2.4 Phân tích và thiết kế hướng đối tượng với UML 2.0
25/Chapter
© DHBK 2007
2.1 Giới thiệu • Lịch sử phát triển của ngôn ngữ lập trình: First Generation (1954 – 1958) Fortran I
Second Generation (1959 – 1961) Fortran II, Algol, Cobol
Third Generation (1962 – 1970) PL/I, Pascal
Object Oriented Languages Smalltalk, C++, Java
26/Chapter
© DHBK 2007
2.1 Giới thiệu • Lịch sử phát triển của UML
27/Chapter
© DHBK 2007
2.1 Giới thiệu • Lịch sử phát triển của UML 2003
UML 2.0 UML 1.4.1
UML 1.4 (action semantics) UML 1.3 (extensibility)
2002 2001 1998 1997
UML 1.1 (OMG Standard) 1996 Rumbaugh
Booch
Jacobson
Foundations of OO (Nygaard, Goldberg, Meyer, Stroustrup, Harel, Wirfs-Brock, Reenskaug,…)
1967
28/Chapter
© DHBK 2007
2.1 Giới thiệu • Thiết kế cấu trúc và thiết kế hướng đối tượng
29/Chapter
© DHBK 2007
2.1 Giới thiệu • Thiết kế cấu trúc và thiết kế hướng đối tượng
© DHBK 2007
30/Chapter
2.2 Các đặc điểm cơ bản của hệ thống hướng đối tượng
2.2.1 Lớp và đối tượng 2.2.2 Phương thức và message 2.2.3 Tóm lược và ẩn thông tin (Encapsulation and Information Hiding) 2.2.4 Thừa kế (inheritance) 2.2.5 Đa hình thái và liên kết động (Polymorphism and Dynamic Binding)
31/Chapter
© DHBK 2007
2.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
32/Chapter
© DHBK 2007
2.2.1 Lớp và đối tượng
33/Chapter
© DHBK 2007
2.2.1 Lớp và đối tượng 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 };
34/Chapter
© DHBK 2007
2.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
© DHBK 2007
35/Chapter
2.2.2 Phương thức và message
36/Chapter
© DHBK 2007
2.2.3 Tóm lược và ẩn thông tin • Encapsulation combination of data and process into an entity
• Information Hiding Only the information required to use a software module is published to the user
37/Chapter
© DHBK 2007
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
38/Chapter
© DHBK 2007
2.2.4 Thừa kế
39/Chapter
© DHBK 2007
2.2.4 Thừa kế
40/Chapter
© DHBK 2007
2.2.5 Đa hình thái và liên kết động • Polymorphism A message can be interpreted differently by different classes of objects
• Dynamic Binding Sometimes called late binding Delays typing or choosing a method for an object until run-time
• Static Binding Type of object determined at compile time
© DHBK 2007
41/Chapter
2.2.5 Đa hình thái và liên kết động
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33
// Fig. 20.1: shape.h // Definition of abstract base class Shape #ifndef SHAPE_H #define SHAPE_H class Shape { public: virtual double area() const { return 0.0; } virtual double volume() const { return 0.0; } // pure virtual functions overridden in derived classes virtual void printShapeName() const = 0; virtual void print() const = 0; }; #endif // Fig. 20.1: point1.h // Definition of class Point #ifndef POINT1_H #define POINT1_H #include using std::cout; #include "shape.h" class Point : public Shape { public: Point( int = 0, int = 0 ); // default constructor void setPoint( int, int ); int getX() const { return x; } int getY() const { return y; }
34 virtual void printShapeName() const { cout << "Point: "; } 35 virtual void print() const; 36 private: 37 int x, y; 38 }; 39 40 #endif
// x and y coordinates of Point
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: "; }
70
virtual void print() const;
71 private: 72
double radius;
73 }; 74 75 #endif
// radius of Circle
76 // Fig. 20.1: circle1.cpp 77 // Member function definitions for class Circle 78 #include 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 106 class Cylinder : public Circle { 107 public: 108
// default constructor
109
Cylinder( double h = 0.0, double r = 0.0,
110
int x = 0, int y = 0 );
111 112
void setHeight( double );
113
double getHeight();
114
virtual double area() const;
115
virtual double volume() const;
116
virtual void printShapeName() const { cout << "Cylinder: "; }
117
virtual void print() const;
118 private: 119
double height;
120 }; 121 122 #endif
// height of Cylinder
123 // Fig. 20.1: cylindr1.cpp 124 // Member and friend function definitions for class Cylinder 125 #include 126 127 using std::cout; 128 129 #include "cylindr1.h" 130 131 Cylinder::Cylinder( double h, double r, int x, int y ) 132 : Circle( r, x, y ) // call base-class constructor 133 { setHeight( h ); } 134 135 void Cylinder::setHeight( double h ) 136 { height = h > 0 ? h : 0; } 137 138 double Cylinder::getHeight() { return height; } 139 140 double Cylinder::area() const 141 { 142 // surface area of Cylinder 143 return 2 * Circle::area() + 144 2 * 3.14159 * getRadius() * height; 145 } 146 147 double Cylinder::volume() const 148 { return Circle::area() * height; } 149 150 void Cylinder::print() const 151 { 152 Circle::print(); 153 cout << "; Height = " << height; 154 }
155 // Fig. 20.1: fig20_01.cpp 156 // Driver for shape, point, circle, cylinder hierarchy 157 #include 158 159 using std::cout; 160 using std::endl; 161 162 #include 163 164 using std::ios; 165 using std::setiosflags; 166 using std::setprecision; 167 168 #include "shape.h" 169 #include "point1.h" 170 #include "circle1.h" 171 #include "cylindr1.h" 172 173 void virtualViaPointer( const Shape * ); 174 void virtualViaReference( const Shape & ); 175 176 int main() 177 { 178 cout << setiosflags( ios::fixed | ios::showpoint ) 179 << setprecision( 2 ); 180 181 Point point( 7, 11 ); // create a Point 182 Circle circle( 3.5, 22, 8 ); // create a Circle 183 Cylinder cylinder( 10, 3.3, 10, 10 ); // create a Cylinder 184 185 point.printShapeName(); // static binding
186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219
point.print(); cout << '\n';
// static binding
circle.printShapeName(); circle.print(); cout << '\n';
// static binding // static binding
cylinder.printShapeName(); // static binding cylinder.print(); // static binding cout << "\n\n"; Shape *arrayOfShapes[ 3 ];
// array of base-class pointers
// aim arrayOfShapes[0] at derived-class Point object arrayOfShapes[ 0 ] = &point; // aim arrayOfShapes[1] at derived-class Circle object arrayOfShapes[ 1 ] = &circle; // aim arrayOfShapes[2] at derived-class Cylinder object arrayOfShapes[ 2 ] = &cylinder; // Loop through arrayOfShapes and call virtualViaPointer // to print the shape name, attributes, area, and volume // of each object using dynamic binding. cout << "Virtual function calls made off " << "base-class pointers\n";
2. Function calls
for ( int i = 0; i < 3; i++ ) virtualViaPointer( arrayOfShapes[ i ] ); // Loop through arrayOfShapes and call virtualViaReference // to print the shape name, attributes, area, and volume // of each object using dynamic binding.
220 221
cout << "Virtual function calls made off " << "base-class references\n";
222 223 224
for ( int j = 0; j < 3; j++ ) virtualViaReference( *arrayOfShapes[ j ] );
225 226
return 0;
227 } 228 229 // Make virtual function calls off a base-class pointer 230 // using dynamic binding. 231 void virtualViaPointer( const Shape *baseClassPtr ) 232 { 233
baseClassPtr->printShapeName();
234
baseClassPtr->print();
235
cout << "\nArea = " << baseClassPtr->area()
236
<< "\nVolume = " << baseClassPtr->volume() << "\n\n";
237 } 238 239 // Make virtual function calls off a base-class reference 240 // using dynamic binding. 241 void virtualViaReference( const Shape &baseClassRef ) 242 { 243
baseClassRef.printShapeName();
244
baseClassRef.print();
245
cout << "\nArea = " << baseClassRef.area()
246 247 }
<< "\nVolume = " << baseClassRef.volume() << "\n\n";
51/Chapter
© DHBK 2007
2.3 UML 2.0 2.3.1 Giới thiệu UML 2.3.2 Biểu đồ cấu trúc 2.3.3 Biểu đồ chức năng 2.3.4 Các cơ chế mở rộng 2.3.5 Tóm tắt
52/Chapter
© DHBK 2007
2.3.1 Giới thiệu về UML "The Unified Modeling Language (UML) is a graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system.” Grady Booch, Ivar Jacobsen, Jim Rumbaugh Rational Software
• UML chỉ đơn thuần là ngôn ngữ đồ hoạ để mô hình hoá chứ không phải là phương pháp để phát triển hệ thống
53/Chapter
© DHBK 2007
2.3.1 Giới thiệu về UML • UML 2.0 cung cấp 14 biểu đồ để mô hình hoá cấu trúc và chức năng của hệ thống, chia làm 2 nhóm: Biểu đồ mô hình cấu trúc Biểu đồ mô hình chức năng
54/Chapter
© DHBK 2007
2.3.2 Biểu đồ cấu trúc • 6 loại biểu đồ cấu trúc: Biểu đồ lớp (Class) Biểu đồ đối tượng (Object) Biểu đồ gói (package) Biểu đồ triển khai (Deployment) Biểu đồ thành phần (Component) Biểu đồ cấu trúc phức hợp (Composite structure diagrams)
55/Chapter
© DHBK 2007
2.3.2 Biểu đồ cấu trúc • Biểu đồ lớp (class diagram) Biểu diễn mối quan hệ giữa các lớp
56/Chapter
© DHBK 2007
2.3.2 Biểu đồ cấu trúc • Biểu đồ đối tượng (object diagram) Biểu diễn mối quan hệ giữa các đối tượng
57/Chapter
© DHBK 2007
2.3.2 Biểu đồ cấu trúc • 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
58/Chapter
© DHBK 2007
2.3.2 Biểu đồ cấu trúc • 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
59/Chapter
© DHBK 2007
2.3.2 Biểu đồ cấu trúc • 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
60/Chapter
© DHBK 2007
2.3.2 Biểu đồ cấu trúc • 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
61/Chapter
© DHBK 2007
2.3.3 Biểu đồ chức năng • 8 loại biểu đồ chức năng Biểu đồ hoạt động (activity diagram) Biểu đồ tương tác (interaction diagrams) Biểu đồ chuỗi 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)
62/Chapter
© DHBK 2007
2.3.3 Biểu đồ chức năng • 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)
63/Chapter
© DHBK 2007
2.3.3 Biểu đồ chức năng • 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
64/Chapter
© DHBK 2007
2.3.3 Biểu đồ chức năng • 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
65/Chapter
© DHBK 2007
2.3.3 Biểu đồ chức nă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
66/Chapter
© DHBK 2007
2.3.3 Biểu đồ chức nă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.
67/Chapter
© DHBK 2007
2.3.3 Biểu đồ chức nă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
68/Chapter
© DHBK 2007
2.3.3 Biểu đồ chức năng
69/Chapter
© DHBK 2007
2.3.3 Biểu đồ chức năng
70/Chapter
© DHBK 2007
2.3.3 Biểu đồ chức năng
71/Chapter
© DHBK 2007
2.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 { }
72/Chapter
© DHBK 2007
2.3.4 Các cơ chế mở rộng • 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 { }
73/Chapter
© DHBK 2007
2.3.4 Các cơ chế mở rộng • 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 << >>
74/Chapter
© DHBK 2007
2.3.5 Tóm tắt
© DHBK 2007
75/Chapter
2.4 Phân tích và thiết kế hướng đối tượng với UML 2.0
2.4.1 Đặc điểm cơ bản của OOAD 2.4.2 Ưu điểm của OOAD 2.4.3 The Unified Process 2.4.4 The MOOSAD
76/Chapter
© DHBK 2007
2.4.1 Đặc điểm cơ bản của OOAD • Use-case driven • Architecture Centric • Cấu trúc phần mềm quyết định việc mô tả, xây dựng và viết tài liệu hệ thống • 3 dạng cấu trúc của một hệ thống: • Chức năng (functional view): chức năng bên ngoài của hệ thống từ góc nhìn của người sử dụng : biểu đồ ca sử dụng, biểu đồ hoạt động • Cấu trúc tĩnh (static view): lớp, thuộc tính, phương thức, quan hệ • Cấu trúc động (dynamic view): chức năng bên trong của hệ thống: biểu đồ máy trạng thái chức năng
• Iterative and Incremental
77/Chapter
© DHBK 2007
2.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ế
78/Chapter
© DHBK 2007
2.4.2 Ưu điểm của OOAD
79/Chapter
© DHBK 2007
2.4.3 The Unified process • Unified process là một phương pháp phát triển hệ thống trong đó quy định khi nào thì sử dụng các kỹ thuật UML và sử dụng chúng như thế nào trong quá trình phân tích và thiết kế hệ thống. Tác giả: Booch, Jacobsen, Rumbaugh Là phương pháp hướng đối tượng Không phải là một quy trình phát triển phần mềm hoàn thiện Không xét đến các vấn đề về phân bổ nhân lực, ngân quỹ, quản lý hợp đồng Không quy định về các hoạt động bảo trì hay hỗ trợ khách hàng Không xét đến các vấn đề tương tác giữa các dự án
80/Chapter
© DHBK 2007
2.4.3 The Unified process
81/Chapter
© DHBK 2007
2.4.3 The Unified process • Pha khởi tạo (Inception): giống như pha lập kế hoạch Các bước liên quan: Mô hình hoá giá trị kinh doanh của hệ thống (business modeling) * Xác định yêu cầu (requirements)* Phân tích (analysis)* Thiết kế (design) Thực hiện (implementation) Kiểm tra (test) Môi trường phát triển (environment)*
Kết quả: Phạm vi của dự án Các yêu cầu và ràng buộc quan trọng Kế hoạch dự án bước đầu Miêu tả tính khả thi và rủi ro của dự án Lựa chọn môi trường cần thiết để phát triển hệ thống
82/Chapter
© DHBK 2007
2.4.3 The Unified process • Pha phát triển (elaboration): hoàn thiện mô hình kinh doanh, đánh giá lại rủi ro và hoàn thiện kế hoạch dự án Cá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 UML Phiên bản hoạt động đầu tiên của hệ thống
83/Chapter
© DHBK 2007
2.4.3 The Unified process • Pha xây dựng (construction): tập trung chủ yếu vào lập trình Cá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
84/Chapter
© DHBK 2007
2.4.3 The Unified process • Pha chuyển tiếp (transition): tập trung chủ yếu vào kiểm tra và triển khai Cá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ống Hướng dẫn sử dụng Kế hoạch hỗ trợ khách hàng, kế hoạch nâng cấp hệ thống
85/Chapter
© DHBK 2007
2.4.3 The Unified process •
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
86/Chapter
© DHBK 2007
2.4.3 The Unified process •
Các bước kỹ thuật (Engineering workflows) 1. 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
2. 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
3. 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
4. Triển khai (deployment) Đóng gói phần mềm, phân phối, cài đặt và beta testing
87/Chapter
© DHBK 2007
2.4.3 The Unified process •
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++
88/Chapter
© DHBK 2007
2.4.4 MOOSAD
89/Chapter
© DHBK 2007
Chương 3. Lập kế hoạch 3.1 Khởi tạo dự án (Project initiation) 3.2 Quản lý dự án (Project Management)
90/Chapter
© DHBK 2007
3.1 Khởi tạo dự án 3.1.1 Giới thiệu 3.1.2 Yêu cầu hệ thống (system request) 3.1.3 Phân tích tính khả thi (feasibility analysis) 3.1.4 Lựa chọn dự án
91/Chapter
© DHBK 2007
3.1.1 Giới thiệu
Nhu cầu kinh doanh
Tài liệu yêu cầu hệ thống Project sponsor
Hội đồng duyệt dự án Yes
No
Phân tích tính khả thi Project sponsor + analyst Yêu cầu hệ thống đã chỉnh sửa
Hội đồng duyệt dự án
92/Chapter
© DHBK 2007
3.1.1 Giới thiệu • 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)
© DHBK 2007
93/Chapter
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)
© DHBK 2007
94/Chapter
3.1.2 Yêu cầu hệ thống (system request)
• Chủ nhiệm dự án (project sponsor) Người thuộc phòng kinh doanh Người thuộc phòng IT có thể là chủ nhiệm hoặc đồng chủ nhiệm dự án CIO, CEO
• Nhu cầu kinh doanh (business need): why? Xuất phát từ: Phòng kinh doanh Phòng IT Chuyên gia tư vấn bên ngoài
Phát sinh khi: 1 chiến dịch kinh doanh mới cần được hỗ trợ cần tìm kiếm thêm khách hàng cần cải thiện việc trao đổi với nhà phân phối việc kinh doanh của công ty có vấn đề: cổ phiếu giảm, hỗ trợ khách hàng kém, bị cạnh tranh công nghệ mới nhiều tiềm năng xuất hiện
© DHBK 2007
95/Chapter
3.1.2 Yêu cầu hệ thống (system request)
• Yêu cầu kinh doanh (business requirement) Hệ thống sẽ làm gì Các chức năng của hệ thống
• Giá trị kinh doanh (business values) Giá trị hữu hình: ví dụ: 20 % giảm về chi phí Giá trị vô hình: ví dụ: cải thiện chất lượng dịch vụ khách hàng, cải thiện vị trí cạnh tranh
• Các vấn đề đặc biệt ví dụ: thời hạn hoàn thành
96/Chapter
© DHBK 2007
Case study: CD selections • Giới thiệu chung về công ty CD selections: 50 cửa hàng băng đĩa ca nhạc ở California Doanh số bán hàng: 50 triệu USD Tăng trưởng 3-5 % / năm Có website cung cấp các thông tin cơ bản về công ty như chỉ dẫn đường đi đến, giờ mở cửa, địa chỉ liên hệ
• Margaret Mooney, phó chủ tịch phụ trách thị trường có ý tưởng bán CD trên mạng Internet
97/Chapter
© DHBK 2007
Case study: CD selections
98/Chapter
© DHBK 2007
3.1.3 Phân tích tính khả thi • Khả thi về kỹ thuật (technical feasibility) • Khả thi về kinh tế (economic feasibility) • Khả thi về mặt tổ chức (organizational feasibility)
99/Chapter
© DHBK 2007
3.1.3 Phân tích tính khả thi • Khả thi về kỹ thuật (technical feasibility) (can we build it ?) Mức độ quen thuộc với ứng dụng Mức độ quen thuộc với công nghệ Kích thước của dự án: Số lượng người tham dự thời gian độ phức tạp của hệ thống
Sự tương thích của hệ thống mới với hệ thống đang tồn tại quyết định dựa trên việc so sánh với các dự án trước đó hoặc tham khảo ý kiến của chuyên gia công nghệ
100/Chapter
© DHBK 2007
3.1.3 Phân tích tính khả thi • Khả thi về kinh tế (economic feasibility) (should we build it ?) Xác định các loại chi phí và lợi nhuận Chi phí phát triển hệ thống (1 lần) Chi phí vận hành (chi phí thường xuyên) Lợi nhuận hữu hình Lợi nhuận vô hình
101/Chapter
© DHBK 2007
3.1.3 Phân tích tính khả thi
102/Chapter
© DHBK 2007
3.1.3 Phân tích tính khả thi • 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
103/Chapter
© DHBK 2007
3.1.3 Phân tích tính khả thi • 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
104/Chapter
© DHBK 2007
3.1.3 Phân tích tính khả thi
105/Chapter
© DHBK 2007
3.1.3 Phân tích tính khả thi • 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
106/Chapter
© DHBK 2007
3.1.3 Phân tích tính khả thi • Khả thi về kinh tế (economic feasibility) (should we build it ?)
107/Chapter
© DHBK 2007
3.1.3 Phân tích tính khả thi • Khả thi về kinh tế (economic feasibility) (should we build it ?)
108/Chapter
© DHBK 2007
3.1.3 Phân tích tính khả thi • Khả thi về kinh tế (economic feasibility) (should we build it ?)
109/Chapter
© DHBK 2007
3.1.3 Phân tích tính khả thi • 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
110/Chapter
© DHBK 2007
3.1.4 Lựa chọn dự án • 3 phương án: Thông qua Loại bỏ Xem xét lại
• Phụ thuộc vào: ROI, giá trị NPV của lợi nhuận, thời gian hoà vốn Số lượng và chất lượng các dự án khác
111/Chapter
© DHBK 2007
3.2 Quản lý dự án 3.2.1 Giới thiệu 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
112/Chapter
© DHBK 2007
3.2.1 Giới thiệu • 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.
113/Chapter
© DHBK 2007
3.2.2 Xác định kích thước dự án • 3 nhân tố phụ thuộc lẫn nhau: Kích thước hệ thống Thời gian hoàn thành dự án Chi phí của dự án
• 2 phương pháp ước lượng kích thước dự án Phương pháp đơn giản dựa trên chuẩn công nghiệp Phương pháp điểm chức năng (function point approach)
114/Chapter
© DHBK 2007
3.2.2 Xác định kích thước dự án • Phương pháp đơn giản dựa trên chuẩn công nghiệp Planning Industry Standard For Web Applications
Time Required in Person Months
Analysis
15%
4
Design
20%
5.33
9.33
Implementation
35%
8
30%
115/Chapter
© DHBK 2007
3.2.2 Xác định kích thước dự án • Phương pháp điểm chức năng
116/Chapter
© DHBK 2007
3.2.2 Xác định kích thước dự án • Phương pháp điểm chức năng Xác định kích thước hệ thống theo điểm chức năng và số dòng lệnh 1 điểm chức năng là đơn vị đo kích thước chương trình dựa trên số lượng và độ phức tạp của đầu vào, đầu ra, truy vấn, files và giao diện chương trình Tính toán số điểm chức năng Liệt kê các thành phần cơ bản của chương trình Xác định số lượng mỗi thành phần Xác định đô phức tạp của mỗi thành phần (low, med., high) Tính tổng số điểm chức năng (TUFP)
117/Chapter
© DHBK 2007
3.2.2 Xác định kích thước dự án 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 Interfaces
__x 5
__x 7
__x 10
____
TOTAL UNADJUSTED FUNCTION POINTS ____
118/Chapter
© DHBK 2007
3.2.2 Xác định kích thước dự án Tính toán số điểm chức năng-Ví dụ:
119/Chapter
© DHBK 2007
3.2.2 Xác định kích thước dự án Tính độ phức tạp xử lý hiệu chỉnh (adjusted processing complexity)-Bước 2
120/Chapter
© DHBK 2007
3.2.2 Xác định kích thước dự án 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
121/Chapter
© DHBK 2007
3.2.2 Xác định kích thước dự án 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)
122/Chapter
© DHBK 2007
3.2.2 Xác định kích thước dự án Tính số dòng lệnh= LOC/Function Code Point x TAFP Language
LOC/Function Code Point
C COBOL JAVA C++ Turbo Pascal Visual Basic PowerBuilder HTML Packages (e.g., Access, Excel)
130 110 55 50 50 30 15 15 10-40
Ví dụ: lập trình dùng C: số dòng lệnh = 243x 130 = 31 590 dòng
123/Chapter
© DHBK 2007
3.2.2 Xác định kích thước dự án • Phương pháp điểm chức năng Xác định kích thước hệ thống theo điểm chức năng và số dòng lệnh Ước lượng nhân lực (person-months) Mô hình: COSOMO
Effort (in PersonMonths)
=
1.4 * thousands-oflines-of-code
Example: If LOC = 20000 Then... Effort = (1.4 * 20)
=
28 Person
124/Chapter
© DHBK 2007
3.2.2 Xác định kích thước dự án • Phương pháp điểm chức năng Xác định kích thước hệ thống theo điểm chức năng và 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
© DHBK 2007
• • • • •
125/Chapter
3.2.3 Xây dựng và quản lý kế hoạch công việc
Xác định các công việc của dự án Ước lượng thời gian thực hiện mỗi công việc Xác định sự phụ thuộc giữa các công việc Xác định ai sẽ làm công việc gì Liệt kê các kết quả đạt được của mỗi công việc ( deliverables): ví dụ: báo cáo, bản thiết kế, phương án thực hiện ...
© DHBK 2007
•
126/Chapter
3.2.3 Xây dựng và quản lý kế hoạch công việc
Ví dụ về một bản kế hoạch công việc: Work Plan Information
Example
Name of task Start date Completion date Person assigned Deliverable(s) Completion status Priority Resources needed Estimated time Actual time
Perform economic feasibility Jan 05, 2001 Jan 19, 2001 Mary Smith, sponsor Cost-benefit analysis Open High Spreadsheet 16 hours 14.5 hours
`
© DHBK 2007
•
127/Chapter
3.2.3 Xây dựng và quản lý kế hoạch công việc
Xác định các công việc của dự án: 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
© DHBK 2007
•
128/Chapter
3.2.3 Xây dựng và quản lý kế hoạch công việc
Xác định các công việc của dự án dùng phương pháp Top-down Phases
Work Plan * * * *
Deliverables
Phases with high level steps
Estimated duration
Assigned To
© DHBK 2007
•
129/Chapter
3.2.3 Xây dựng và quản lý kế hoạch công việc
Xác định các công việc của dự án 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
© DHBK 2007
130/Chapter
3.2.3 Xây dựng và quản lý kế hoạch công việc
© DHBK 2007
131/Chapter
3.2.3 Xây dựng và quản lý kế hoạch công việc
• Biểu đồ Gantt (Gantt Chart): là 1 cách biểu diễn kế hoạch công việc dựa trên WBS
© DHBK 2007
132/Chapter
3.2.3 Xây dựng và quản lý kế hoạch công việc
• Biểu đồ PERT (PERT= Project Evaluation and Review Technique ) Là cách biểu diễn khác của kế hoạch công việc Cách tốt nhất để biểu diễn sự phụ thuộc giữa các công việc và để xác định các pha then chốt PERT sử dụng 3 loại giá trị ước lượng thời gian thực hiện công việc: Lạc quan: O Khả năng cao: M (most likely) Bi quan: P
Thời gian ước lượng = (O + 4 * M + P)/6
© DHBK 2007
133/Chapter
3.2.3 Xây dựng và quản lý kế hoạch công việc
• Biểu đồ PERT
X: Hoàn thành \: đang thực hiện
© DHBK 2007
134/Chapter
3.2.4 Sắp xếp nhân lực cho dự án • Xác định số người cho dự án • Xây dựng kế hoạch nhân 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
135/Chapter
© DHBK 2007
3.2.4 Sắp xếp nhân lực cho dự án Ví dụ về cơ cấu tổ chức của dự án
136/Chapter
© DHBK 2007
3.2.4 Sắp xếp nhân lực cho 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?
137/Chapter
© DHBK 2007
3.2.4 Sắp xếp nhân lực cho dự án • Khích lệ động viên các thành viên trong nhóm: Sử dụng tiền thưởng một cách hết sức cẩn trọng Sử dụng các khích lệ tinh thần: Công việc hấp dẫn, thách thức Tinh thần trách nhiệm Nhu cầu tiến thủ Cơ hội để học kỹ năng mới Nhu cầu tự khẳng định mình Sự thành cônng
138/Chapter
© DHBK 2007
3.2.4 Sắp xếp nhân lực cho dự án • Chiến lược để giải quyết xung đột: Xác định rõ ràng công việc của từng thành viên trong nhóm Lập bảng quy định, nội quy của nhóm Dự đoán các ưu tiên khác và khả năng ảnh hưởng của chúng tới dự án
© DHBK 2007
139/Chapter
3.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 (computeraided 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
140/Chapter
© DHBK 2007
3.2.5 Điều phối hoạt động dự án • Tinh chỉnh các giá trị ước lượng Typical margins of Error for Phase time (%)
Deliverable
Planning
System Request Project Plan
Analysis 15 Design
Well-done Estimates Cost (%) 400 100
60 25
System Proposal
50
System Specification 25
10
141/Chapter
© DHBK 2007
3.2.5 Điều phối hoạt động dự án • Quản lý phạm vi dự án (scope management) Scope creep: hiện tượng dự án có nguy cơ kéo dài và tốn chi phí hơn dự kiến Nguyên nhân: thêm yêu cầu mới cho hệ thống sau khi phạm vi của hệ thống đã được giới hạn Biện pháp khắc phục: Cách 1: tăng cường gặp gỡ trao đổi với người sử dụng và xây dựng nguyên mẫu để tăng tốc việc định rõ các yêu cầu -> giảm được 5% nguy cơ Cách 2: sử dụng kỹ thuật hộp thời gian (timeboxing)
142/Chapter
© DHBK 2007
3.2.5 Điều phối hoạt động dự án • Timeboxing Steps 1. Set the date for system delivery. 2. Prioritize the functionality that needs to be included in the system. 3. Build the core of the system (the functionality ranked as most important). 4. Postpone functionality that cannot be provided within the time frame. 5. Deliver the system with core functionality. 6. Repeat steps 3 through 5, to add refinements and enhancements.
143/Chapter
© DHBK 2007
3.2.5 Điều phối hoạt động dự án • Điều phối hoạt động của dự án: CASE (computer-aided software engineering) tool – Software that automates all of part of the development process Initiation
Analysis
Upper CASE
Design
Implementation
Lower CASE
Integrated CASE (I-CASE)
144/Chapter
© DHBK 2007
3.2.5 Điều phối hoạt động dự án • Điều phối hoạt động của dự án: • Standardisation: Examples Formal rules for naming files Forms indicating goals reached Programming guidelines and Coding standard • Documentation Project binder: all deliverables and all the internal communications within a project Table of contents Continual updating
145/Chapter
© DHBK 2007
3.2.5 Điều phối hoạt động dự án • Quản lý rủi ro: Risk assessment: a document assesses a potential risk including: Risk No and its brief description Likelihood of risk Potential impact on the project Ways to address the risk
Actions to reduce risk Revised assessment
146/Chapter
© DHBK 2007
3.2.5 Điều phối hoạt động dự án • Quản lý rủi ro: Avoiding Classic Planning Mistakes Overly optimistic schedule Failing to monitor schedule Failing to update schedule Adding people to a late project
147/Chapter
© DHBK 2007
3.2.6 CD selections
148/Chapter
© DHBK 2007
Chương 4. Phân tích hệ thống 4.1 Xác định yêu cầu của hệ thống 4.2 Mô hình hoá chức năng 4.3 Mô hình hoá cấu trúc 4.4 Mô hình hoá hoạt động
149/Chapter
© DHBK 2007
Chương 4. Phân tích hệ thống
Định nghĩa yêu cầu của hệ thống
Mô hình chức năng
Yêu cầu hệ thống (system request)
Mô hình cấu trúc
Hội đồng duyệt dự án Yes Thiết kế hệ thống
Mô hình hoạt động Phân tích khả thi Kế hoạch công việc
+ system proposal
150/Chapter
© DHBK 2007
4.1 Xác định yêu cầu của hệ thống 4.1.1 Xác định yêu cầu 4.1.2 Các kỹ thuật phân tích yêu cầu 4.1.3 Các kỹ thuật thu thập yêu cầu 4.1.4 CD selections
151/Chapter
© DHBK 2007
4.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ăng Khả năng hoạt động An ninh yêu cầu về văn hoá, chính trị Yêu cầu không chức năng được dùng chủ yếu tại bước thiết kế hệ thống
152/Chapter
© DHBK 2007
4.1.1 Xác định yêu cầu • Tài liệu định nghĩa yêu cầu (requirement definition): Là văn bản liệt kê các yêu cầu chức năng và yêu cầu không chức năng Cung cấp đầu vào cho các bước tiếp theo trong quá trình phân tích hệ thống cũng như quá trình thiết kế Mục đích quan trọng nhất của tài liệu định nghĩa yêu cầu là định nghĩa phạm vi của hệ thống
153/Chapter
© DHBK 2007
4.1.1 Xác định yêu cầu • Xây dựng tài liệu định nghĩa yêu cầu Xác định các loại yêu cầu chức năng và không chức năng Sử dụng các kỹ thuật thu thập yêu cầu để thu thập thông tin Sử dụng các kỹ thuật phân tích yêu cầu để kiểm tra, thay đổi và hoàn thiện các yêu cầu thu thập được và xác định mức độ quan trọng của các yêu cầu
154/Chapter
© DHBK 2007
4.1.1 Xác định yêu cầu
155/Chapter
© DHBK 2007
4.1.1 Xác định yêu cầu
156/Chapter
© DHBK 2007
4.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: Business process automation (BPA): tự động hoá quá trình kinh doanh Business process improvement (BPI): cải tiến quá trình kinh doanh Business process reengineering (BPE)
•
3 bước trong quá trình phân tích yêu cầu: Phân tích tình trạng của hệ thống hiện tại Xác định chính xác những cải tiến có thể thực hiện Xây dựng yêu cầu của hệ thống cần xây dựng
© DHBK 2007
157/Chapter
4.1.2 Các kỹ thuật phân tích yêu cầu •
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 đề
© DHBK 2007
158/Chapter
4.1.2 Các kỹ thuật phân tích yêu cầu •
Business process improvement (BPI): cải tiến quá trình kinh doanh
Làm thay đổi hoạt động 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
159/Chapter
© DHBK 2007
4.1.2 Các kỹ thuật phân tích yêu cầu •
Business process reengineering (BPR): thay đổi quá trình kinh doanh Làm thay đổi 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ỏ đó
160/Chapter
© DHBK 2007
4.1.2 Các kỹ thuật phân tích yêu cầu •
Lựa chọn kỹ thuật thích hợp, phụ thuộc vào:
Giá trị kinh doanh tiềm 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
161/Chapter
© DHBK 2007
4.1.2 Các kỹ thuật phân tích yêu cầu •
Lựa chọn kỹ thuật thích hợp
© DHBK 2007
162/Chapter
4.1.3 Các kỹ thuật thu thập yêu cầu • • • • •
Phỏng vấn (Interviews) Kết hợp phát triển ứng dụng (Joint Application Development (JAD)) Điều tra (Questionnaires) Phân tích tài liệu (Document analysis) Quan sát (Observation)
163/Chapter
© DHBK 2007
4.1.3 Các kỹ thuật thu thập yêu cầu •
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
164/Chapter
© DHBK 2007
4.1.3 Các kỹ thuật thu thập yêu cầu •
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)
165/Chapter
© DHBK 2007
4.1.3 Các kỹ thuật thu thập yêu cầu •
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)
166/Chapter
© DHBK 2007
4.1.3 Các kỹ thuật thu thập yêu cầu •
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 How many telephone orders are received per day? * How do customers place orders? * What additional information would you like the new system to provide?
Closed-Ended Questions
*
Open-Ended Questions
* * *
Probing Questions
*
* *
What do you think about the current system? What are some of the problems you face on a daily basis? How do you decide what types of marketing campaign to run? Why? Can you give me an example? Can you explain that in a bit more detail?
167/Chapter
© DHBK 2007
4.1.3 Các kỹ thuật thu thập yêu cầu •
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
© DHBK 2007
168/Chapter
4.1.3 Các kỹ thuật thu thập yêu cầu •
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
169/Chapter
© DHBK 2007
4.1.3 Các kỹ thuật thu thập yêu cầu •
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
© DHBK 2007
170/Chapter
4.1.3 Các kỹ thuật thu thập yêu cầu •
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ờ
171/Chapter
© DHBK 2007
4.1.3 Các kỹ thuật thu thập yêu cầu •
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
© DHBK 2007
172/Chapter
4.1.3 Các kỹ thuật thu thập yêu cầu •
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
173/Chapter
© DHBK 2007
4.1.3 Các kỹ thuật thu thập yêu cầu •
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:
© DHBK 2007
174/Chapter
4.1.3 Các kỹ thuật thu thập yêu cầu •
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
175/Chapter
© DHBK 2007
4.1.3 Các kỹ thuật thu thập yêu cầu •
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
176/Chapter
© DHBK 2007
4.1.3 Các kỹ thuật thu thập yêu cầu •
JAD: Thiết lập cuộc họp
U-Shaped seating Away from distractions Whiteboard/flip chart Prototyping tools e-JAD
177/Chapter
© DHBK 2007
4.1.3 Các kỹ thuật thu thập yêu cầu •
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
178/Chapter
© DHBK 2007
4.1.3 Các kỹ thuật thu thập yêu cầu •
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
179/Chapter
© DHBK 2007
4.1.3 Các kỹ thuật thu thập yêu cầu •
JAD: Phòng họp
180/Chapter
© DHBK 2007
4.1.3 Các kỹ thuật thu thập yêu cầu •
Đ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
181/Chapter
© DHBK 2007
4.1.3 Các kỹ thuật thu thập yêu cầu •
Đ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.
182/Chapter
© DHBK 2007
4.1.3 Các kỹ thuật thu thập yêu cầu •
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
183/Chapter
© DHBK 2007
4.1.3 Các kỹ thuật thu thập yêu cầu •
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
184/Chapter
© DHBK 2007
4.1.3 Các kỹ thuật thu thập yêu cầu •
Lựa chọn kỹ thuật thích hợp:
185/Chapter
© DHBK 2007
4.1.4 CD selections Requirement Determination • Requirement Analysis Techniques Select BPI techniques to identify how to improve the current order process using a new web-based system Using several JAD session including store managers, marketing analysts and Wed developers (the working group) to work through BPI techniques and brainstorm Further apply informal benchmarking with Web-sites of several leading retailers and discuss with the working group The output is a list of suggested business requirements for the project team
186/Chapter
© DHBK 2007
4.1.4 CD selections Requirement Determination • Requirement-gathering Techniques The project team applies document analysis, interview and observation techniques Firstly apply document analysis to understand the current order processes (i.e., the as-is system). If anything is not clear, use interview to clarify Secondly interview senior analysts to get better ideas about as-is and to-be systems and IT contractor to understand the existing IT system Thirdly observe in stores to see the real working process of as-is system
• The above activities at the end produces the requirement definition (report) • Further JAD sessions are used to finalise and prioritise the requirement definition (report)
© DHBK 2007
4.2 Mô hình hoá chức năng (Functional Modeling)
187/Chapter
4.2.1 Giới thiệu 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
188/Chapter
© DHBK 2007
4.2.1 Giới thiệu • 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)
© DHBK 2007
189/Chapter
4.2.2 Mô hình quá trình kinh doanh bằng biểu đồ hoạt động (activity diagrams)
• Các phần tử của biểu đồ hoạt động • Xây dựng biểu đồ hoạt động
© DHBK 2007
190/Chapter
4.2.2 Mô hình quá trình kinh doanh bằng biểu đồ hoạt động (activity diagrams)
• Biểu đồ hoạt động được dùng để mô hình hoá các quá trình kinh doanh ở mức cao (high level business process) • Các phần tử của biểu đồ hoạt động Hành động (action) Là phần tử đơn giản biểu diễn một hoạt động không thể chia nhỏ hơn Tên: Động từ + danh từ, ví dụ: Make appointment
Hoạt động (activity) Dùng để biểu diễn tập hợp các hành động
Make appointment
Nốt đối tượng (object node) Biểu diễn một đối tượng được kết nối với các luồng đối tượng Tên của nốt đối tượng là tên lớp của đối tượng Class name
Luồng điều khiển (control flow) Biểu diễn chuỗi hoạt động
© DHBK 2007
191/Chapter
4.2.2 Mô hình quá trình kinh doanh bằng biểu đồ hoạt động (activity diagrams)
• Các phần tử của biểu đồ hoạt động (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
© DHBK 2007
192/Chapter
4.2.2 Mô hình quá trình kinh doanh bằng biểu đồ hoạt động (activity diagrams)
• Các phần tử của biểu đồ hoạt động (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
[điều kiện]
[điều kiện]
Nốt gộp (merge node) Dùng để gộp các nhánh đựơc tạo ra bởi nốt lựa chọn
© DHBK 2007
193/Chapter
4.2.2 Mô hình quá trình kinh doanh bằng biểu đồ hoạt động (activity diagrams)
• Các phần tử của biểu đồ hoạt động (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
© DHBK 2007
194/Chapter
4.2.2 Mô hình quá trình kinh doanh bằng biểu đồ hoạt động (activity diagrams)
© DHBK 2007
•
195/Chapter
4.2.2 Mô hình quá trình kinh doanh bằng biểu đồ hoạt động (activity diagrams)
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
© DHBK 2007
•
196/Chapter
4.2.2 Mô hình quá trình kinh doanh bằng biểu đồ hoạt động (activity diagrams) VD: CD selections
Internet Order System – Functional requirements: 2. Maintain CD Information 1.1…… 1.2….. 1.3…..
3. Maintain CD marketing information 2.1…. 2.2…. 2.3….
4. Place CD Orders 3.1 Search CDs from “CD Selection” web site; 3.2 Place orders; 3.3……
5. Maintain Orders 4.1….. 4.2… 4.3 Place Instore Hold: If ordered CDs are available in a near store, the CDs are on hold and to be picked up in the store 4.4. Place Special Order: If ordered CDs is not available in a near store, the ordered CDs will be sent to a near store and email to the customer when it is available in the near store
© DHBK 2007
•
197/Chapter
4.2.2 Mô hình quá trình kinh doanh bằng biểu đồ hoạt động (activity diagrams)
VD: CD selections Exercise: Create the activity diagram for Internet Order System Analysis: Main activities: Maintain CD Information, Maintain CD marketing information, Place CD Orders, Maintain ordered CDs Control flows: Three main parallel processes: Maintain CD Information Maintain CD marketing information Place CD Orders -> Maintain ordered CDs in which a decision needs to be made related to placing instore hold or placing special order
© DHBK 2007
•
198/Chapter
4.2.2 Mô hình quá trình kinh doanh bằng biểu đồ hoạt động (activity diagrams)
VD: CD selections
Maintain CD marketing information
Place CD Order [If available in near store] Place instore hold
[If not] Place special order
Maintain CD Information
199/Chapter
© DHBK 2007
4.2.3 Mô tả ca sử dụng • Một ca sử dụng miêu tả các hoạt động do người sử dụng hoặc các hệ thống khác tác động lên hệ thống. • Ca sử dụng là mô hình logic vì chúng miêu tả các hoạt động của hệ thống mà không miêu tả các hoạt động đó được thực hiện thế nào. • Ca sử dụng miêu tả chức năng của hệ thống: Người sử dụng có thể làm gì Hệ thống đáp ứng như thế nào Ca sử dụng miêu tả tương tác giữa người sử dụng và hệ thống
• Ca sử dụng có thể được dùng để mô tả hệ thống hiện tại và hệ thống cần xây dựng
200/Chapter
© DHBK 2007
4.2.3 Mô tả ca sử dụng • 2 bước để xây dựng biểu đồ ca sử dụng Viết bản mô tả ca sử dụng Chuyển từ bản mô tả ca sử dụng sang biểu đồ ca sử dụng
• Mỗi một ca sử dụng chỉ miêu tả duy nhất một chức năng của hệ thống • Để xác định nội dung của ca sử dụng, người phát triển hệ thống phải làm việc cùng với người sử dụng
201/Chapter
© DHBK 2007
4.2.3 Mô tả ca sử dụng • Các thành phần của bản mô tả ca sử dụng: Use Case Name: Level: Primary Actor:
ID:
Importance
Use Case Type:
Stakeholders and Interests: Brief Description: Trigger: Relationships: (Association, Include, Extend, Generalization) Normal Flow of Events: Subflows:
202/Chapter
© DHBK 2007
4.2.3 Mô tả ca sử dụng • Ví dụ:
203/Chapter
© DHBK 2007
4.2.3 Mô tả ca sử dụng • Ví dụ:
204/Chapter
© DHBK 2007
4.2.3 Mô tả ca sử dụng • Ví dụ:
205/Chapter
© DHBK 2007
4.2.3 Mô tả ca sử dụng •
Guidelines for Creating Use-Case Descriptions 1. Write each step in “SVDPI (subject-verb-direct object and optionally preposition-indirect object)” form Example. “The patient (subject) contacts (verb) the office (direct object) regarding (preposition) an appointment (indirect object). 2. Clarify initiator and receivers of action 3. Write from independent observer perspective 4. Write at same level of abstraction 5. Ensure a sensible set of steps 6. Apply KISS (keep it simple, stupid) principle liberally 7. Write repeating instructions after the set of steps to be repeated.
206/Chapter
© DHBK 2007
4.2.4 Biểu đồ ca sử dụng A Subject Boundary
An Actor An associate relationship A use case
207/Chapter
© DHBK 2007
4.2.4 Biểu đồ ca sử dụng
208/Chapter
© DHBK 2007
4.2.4 Biểu đồ ca sử dụng
209/Chapter
© DHBK 2007
4.2.4 Biểu đồ ca sử dụng
210/Chapter
© DHBK 2007
4.2.4 Biểu đồ ca sử dụng
© DHBK 2007
211/Chapter
4.2.5 Xây dựng mô tả ca sử dụng và Biểu đồ ca sử dụng
• 4 bước chính: Bước I. Xác định các ca sử dụng chính Bước II. Mở rộng ca sử dụng chính Bước III. Khẳng định lại các ca sử dụng chính Bước IV. Vẽ biểu đồ ca sử dụng
© DHBK 2007
•
212/Chapter
4.2.5 Xây dựng mô tả ca sử dụng và Biểu đồ ca sử dụng
Bước I (5 bước nhỏ): Xác định các ca sử dụng chính 1. Xem lại biểu đồ hoạt động 2. Xác định phạm vi của hệ thống 3. Liệt kê các tác nhân chính (primary actors) và mục đích của các tác nhân đó 4. Xác định và viết các ca sử dụng chính 5. Xem xét lại cẩn thận các ca sử dụng và sửa đổi nếu cần
© DHBK 2007
•
213/Chapter
4.2.5 Xây dựng mô tả ca sử dụng và Biểu đồ ca sử dụng
Bước I: Ví dụ Review activity diagram of Internet order System:
Place CD Order
Maintain CD Order
Maintain CD marketing information
Maintain CD Information
© DHBK 2007
•
214/Chapter
4.2.5 Xây dựng mô tả ca sử dụng và Biểu đồ ca sử dụng
Bước I: Ví dụ
Identify and write the major (overview) use-cases Use case name
Primary actor
Relationship Association
Maintain marketing information
Vendor
Vendor
Maintain CD information
Distribution system
Distribution system
Place order
Customer
Customer
Maintain order
Customer
Include
Maintain order
Exclude
© DHBK 2007
•
215/Chapter
4.2.5 Xây dựng mô tả ca sử dụng và Biểu đồ ca sử dụng
Bước II (5 bước nhỏ): Mở rộng ca sử dụng chính Chọn 1 ca sử dụng chính để mở rộng Điền các chi tiết vào form Điền các bước của luồng sự kiện bình thường (normal
flow of events) 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)
Miêu tả các bước thay thế hoặc ngoại lệ (alternate/exceptional) 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
© DHBK 2007
•
216/Chapter
4.2.5 Xây dựng mô tả ca sử dụng và Biểu đồ ca sử dụng
Bước II: Ví dụ: kết quả sau bước 7
© DHBK 2007
•
217/Chapter
4.2.5 Xây dựng mô tả ca sử dụng và Biểu đồ ca sử dụng
Bước II: Ví dụ: kết quả sau bước 8
© DHBK 2007
•
218/Chapter
4.2.5 Xây dựng mô tả ca sử dụng và Biểu đồ ca sử dụng
Bước II: Ví dụ: kết quả sau bước 11
© DHBK 2007
•
219/Chapter
4.2.5 Xây dựng mô tả ca sử dụng và Biểu đồ ca sử dụng
Bước II: Ví dụ: kết quả sau bước 11
© DHBK 2007
•
220/Chapter
4.2.5 Xây dựng mô tả ca sử dụng và Biểu đồ ca sử dụng
Bước III (2 bước nhỏ): Khẳng định lại các ca sử dụng chính 1. 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
2. Lặp lại 12 bước cho đến khi tất cả các ca sử dụng được xác định
© DHBK 2007
•
221/Chapter
4.2.5 Xây dựng mô tả ca sử dụng và Biểu đồ ca sử dụng
Bước IV (4 bước nhỏ): Vẽ biểu đồ ca sử dụng 1. 2. 3. 4.
Vẽ gianh giới của hệ thống Vẽ các ca sử dụng (vẽ theo thứ tự dễ nhìn) Vẽ các tác nhân Vẽ các quan hệ
© DHBK 2007
222/Chapter
Exercise: Draw use-case diagram Question. Suppose that 7 major use cases have been identified as below, draw the corresponding use-case diagram
Use case name
Primary actor
Relationship Association
Include
Maintain marketing information
Vendor
Vendor
Maintain CD information
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
Customer
Store
Place special order
Customer
Store
Extend
Place Instore hold Place special order
223/Chapter
© DHBK 2007
Maintain CD marketing information <>
<>
Credit Card Centre
Place CD order
Check out <> Place instore hold Maintain CD order << extend >> Place special order
<>
Distribution System
Maintain CD information
<>
Store
224/Chapter
© DHBK 2007
4.3 Mô hình hoá cấu trúc 4.3.1 Giới thiệu 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
225/Chapter
© DHBK 2007
4.3.1 Giới thiệu 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.
226/Chapter
© DHBK 2007
4.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ọng Các thuộc tính phải có kiểu cơ bản: nguyên, xâu, ngày, tháng, boolean …. Các thuộc tính phức tạp đựơc biểu diễn bằng quan hệ (relationship) giữa các lớp
227/Chapter
© DHBK 2007
4.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
© DHBK 2007
228/Chapter
4.3.3 Thẻ CRC (Class-ResponsibilityCollaboration)
• Trách nhiệm (responsibility) và hợp tác (collaboration) Trách nhiệm Đối tượng của một lớp phải có trách nhiệm: biết giá trị các thuộc tính và các quan hệ của nó thực hiện hoạt động của nó
Hợp tác Các đối tượng hợp tác với nhau để thực hiện một công việc Mô hình Client-server-contract
• Thẻ CRC được dùng để miêu tả các phần tử cơ bản của một lớp
© DHBK 2007
229/Chapter
4.3.3 Thẻ CRC (Class-ResponsibilityCollaboration)
© DHBK 2007
230/Chapter
4.3.3 Thẻ CRC (Class-ResponsibilityCollaboration)
231/Chapter
© DHBK 2007
4.3.4 Biểu đồ lớp
232/Chapter
© DHBK 2007
4.3.4 Biểu đồ lớp • Cú pháp: A CLASS
Class 1 -attribute +operation ()
AN ATTRIBUTE AN OPERATION AN ASSOCIATION
Attribute name/ derived attribute name operation name () 1..* 0..1 ______verb phrase____
233/Chapter
© DHBK 2007
4.3.4 Biểu đồ lớp • Thuộc tính: Derived attributes /age, for example can be calculated from birth date and current date
Visibility Public: Protected: Private:
+ # -
234/Chapter
© DHBK 2007
4.3.4 Biểu đồ lớp • Hoạt động (operations): Constructor Creates object
Query Makes information about state available
Update Changes values of some or all attributes
235/Chapter
© DHBK 2007
4.3.4 Biểu đồ lớp • Quan hệ: Multiplicity of relationship exactly one: zero or more: one or more: zero or one: specified range: multiple disjoint ranges:
1 0..* 1..* 0..1 2..4 1..5,7
236/Chapter
© DHBK 2007
4.3.4 Biểu đồ lớp • Biểu đồ đối tượng: cụ thể hóa biểu đồ lớp
237/Chapter
© DHBK 2007
4.3.5 Xây dựng thẻ CRC và biểu đồ lớp Three common approaches 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
3. Common object list Physical or tangible things Incidents Roles
4. Patterns Useful groupings of classes that occur in various situations
© DHBK 2007
238/Chapter
4.3.5 Xây dựng thẻ CRC và biểu đồ lớp • • • • • • •
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.
239/Chapter
© DHBK 2007
4.3.5 Xây dựng thẻ CRC và biểu đồ lớp
CD Selections
240/Chapter
© DHBK 2007
Step 1. Create CRC cards by performing textual analysis on the use-cases Textual Analysis: Nouns suggest classes
241/Chapter
© DHBK 2007
Step 1. Create CRC cards by performing textual analysis on the use-cases Textual Analysis: Nouns suggest classes • Textual Analysis Results: Identified potential classes Customer Search Request CD CD List Review (i.e., CD review information) If further analyse the Maintain Order and Checkout use cases, further potential classes will be identified such as Order Order Item Credit card centre etc
242/Chapter
© DHBK 2007
Step 1. Create CRC cards by performing textual analysis on the use-cases 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
243/Chapter
© DHBK 2007
Step 1. Create CRC cards by performing textual analysis on the use-cases Textual Analysis: Verbs suggest operations: •
Textual Analysis Result: For Customer Class, the identified operations (i.e., Responsibilities) and the relationship with other classes (i.e., Collaborators) are
Make Search request Place Order Get Credit Card
Search request Order Credit Card Centre
Info Exit Select CD for Info
CD List Not include as it can be included in Search request
This forms the front of “Customer class” CRC Card
244/Chapter
© DHBK 2007
Step 1. Create CRC cards by performing textual analysis on the use-cases •
Textual Analysis Result: Combine “nouns and verbs” analysis, the back of “Customer class” CRC Card can be
Order; Search request; Credit Card Centre
© DHBK 2007
245/Chapter
Step 2 and 3. Examine Common Object Lists and Role-play the CRC Cards
1. Brainstorm additional candidate classes, attributes, operations, and relationships by using the common object list approach. 2. 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
© DHBK 2007
246/Chapter
Step 4. Create the Class Diagram based on the CRC Cards
• Exercise. Suppose the CRC card of Customer class is given as before, create the class diagram based on it. • For customer class, assume that all attributes are private type whereas all operations are public type • For other associate classes, only the class names and the relationships with the customer class need to be given
© DHBK 2007
247/Chapter
Step 4. Create the Class Diagram based on the CRC Cards
• Solution: Credit Card Centre
Order Customer
0..* Check ->
0..*
-First name -Middle initial -Last name -…… +Make search req() +Place order() +Get credit info() +Exit() 0..*
1
0..*
place ->
Make ->
Search Reg 0..*
248/Chapter
© DHBK 2007
Step 5, 6 and 7: Review Classes Diagrams, Incorporate Patterns, and Review the Model 1. Review the class diagrams and structural model for any missing and/or redundancy 2. Incorporate useful patterns. • One possible pattern
3. Review the structural model.
249/Chapter
© DHBK 2007
4.4 Mô hình hoá hoạt động 4.4.1 Giới thiệu 4.4.2 Biểu đồ tương tác 4.4.3 Biểu đồ máy trạng thái
250/Chapter
© DHBK 2007
4.4.1 Giới thiệu • 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)
251/Chapter
© DHBK 2007
4.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
252/Chapter
© DHBK 2007
4.4.2 Biểu đồ tương tác • Biểu đồ tuần tự (sequence diagram) Miêu tả các đối tượng tham gia vào 1 ca sử dụng Biểu diễn các thông điệp được truyền giữa các đối tượng trong 1 ca sử dụng
253/Chapter
© DHBK 2007
4.4.2 Biểu đồ tương tác • Biểu đồ tuần tự (sequence diagram): ví dụ
254/Chapter
© DHBK 2007
4.4.2 Biểu đồ tương tác • Biểu đồ tuần tự (sequence diagram): Các phần tử
255/Chapter
© DHBK 2007
4.4.2 Biểu đồ tương tác • Biểu đồ tuần tự (sequence diagram): Các phần tử
256/Chapter
© DHBK 2007
4.4.2 Biểu đồ tương tác •
6 bước xây dựng biểu đồ tuần tự Xác định ngữ cảnh của biểu đồ tuần tự Xác định các đối tượng tham gia Xác định đường sống (lifeline) cho mỗi đối tượng Biểu diễn các thông điệp 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 Kiểm tra lại biểu đồ
Application Example:
© DHBK 2007
Normal Flow of Events: 1. Customer submits a search request to the system. 2. The system provides the customer a list of recommended CDs. 3. The customer chooses one of the CDs to find additional information. 4. The system provides the customer with basic (market) information & CD Reviews 5. The customer calls the maintain order use case. 6. The customer iterates over 3 through 5 until finished shopping. 7. The customer executes the checkout use case. 8. The customer leaves the website.
257/Chapter
Application Example:
© DHBK 2007
258/Chapter
259/Chapter
© DHBK 2007
4.4.2 Biểu đồ tương tác • 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
260/Chapter
© DHBK 2007
4.4.2 Biểu đồ tương tác • Biểu đồ giao tiếp : Ví dụ
261/Chapter
© DHBK 2007
4.4.2 Biểu đồ tương tác • Biểu đồ giao tiếp : Các phần tử Actor Object Association Message
262/Chapter
© DHBK 2007
4.4.2 Biểu đồ tương tác •
5 bước xây dựng biểu đồ giao tiếp 1. 2. 3. 4. 5.
Xác định ngữ cảnh Xác định các đối tượng và các liên kết giữa các đối tượng 2 Vẽ các đối tượng và liên kết Thêm các thông điệp Kiểm tra lại biểu đồ giao tiếp
© DHBK 2007
•
263/Chapter
Technique to Identify Collaborations between Objects - “CRUD” Analysis
What is “CRUD” analysis: identifying the processes to Create, Read or Reference, Update or Delete objects based on use cases The process of each user case is represented by “CRUD” matrix: a classby-class matrix in which each cell in the matrix represents the interaction between instances of the classes
264/Chapter
© DHBK 2007
“CRUD” Analysis Example
C C
Application Example:
© DHBK 2007
Normal Flow of Events: 1. Customer submits a search request to the system. 2. The system provides the customer a list of recommended CDs. 3. The customer chooses one of the CDs to find additional information. 4. The system provides the customer with basic (market) information & CD Reviews 5. The customer calls the maintain order use case. 6. The customer iterates over 3 through 5 until finished shopping. 7. The customer executes the checkout use case. 8. The customer leaves the website.
265/Chapter
Application Example:
© DHBK 2007
266/Chapter
267/Chapter
© DHBK 2007
4.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.
268/Chapter
© DHBK 2007
4.4.3 Biểu đồ máy trạng thái Ví dụ:
269/Chapter
© DHBK 2007
4.4.3 Biểu đồ máy trạng thái Các phần tử của biều đồ máy trạng thái:
270/Chapter
© DHBK 2007
4.4.3 Biểu đồ máy trạng thái Các phần tử của biều đồ máy trạng thái: •
Transitions: A transition indicates a movement from one state to the next one, denoted by lines with arrowheads. A transition has a label in the form of three parts: Event [guard]/activity. All three parts are optional. Event or Trigger: the signal event that triggers a potential change of state Guard: If presented, is a Boolean condition that must be true in order for the trigger to cause the transition Action or Activity: is some behaviour that has executed during the transition
state
Event [guard]/activity transition
271/Chapter
© DHBK 2007
4.4.3 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
Application Example:
© DHBK 2007
The Life of an Order Object:
272/Chapter
Application Example:
© DHBK 2007
273/Chapter
274/Chapter
© DHBK 2007
Chương 5. Thiết kế hệ thống 5.1 Chuyển sang thiết kế 5.2 Thiết kế lớp và phương thức 5.3 Thiết kế lớp quản lý dữ liệu 5.4 Thiết kế lớp tương tác người-máy 5.5 Thiết kế lớp kiến trúc vật lý
275/Chapter
© DHBK 2007
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ế
© DHBK 2007
276/Chapter
5.1.1 Chuyển từ mô hình phân tích sang mô hình thiết kế
• Factoring: Creating modules* that reflect similarities and differences between units of interest Here, module = new class | new method New classes can be represented by:Generalization Aggregation New classes identified by: Abstraction e.g. classes for nurse, admin and doctor share attributes and methods, so “factor our” common attributes and methods, create new class “employee”, relate employee to nurse, admin and doctor classes as generalisation (a-kind-of) relationship – a form of abstraction Refinement Identifying additional subclasses (of a higher level class) is a form of refinement
© DHBK 2007
277/Chapter
5.1.1 Chuyển từ mô hình phân tích sang mô hình thiết kế
• Partitions and Collaborations Creating subsystems*, i.e. collections (usually sets) of related components In object-oriented designs/implementations the “pattern of activity”, i.e. messages sent between objects, provides one basis for partitioning system into (smaller-scale) subsystems (where subsystem = partition) Grouping units that collaborate e.g. as modelled in UML communications diagram (for each use-case), CRUD analysis, clients(i.e. objects that are message senders)-servers(i.e. objects that receivemessages) & contracts (i.e. specifications of interactions between objects) May have collaboration among units (e.g. a class) or partitions (i.e. collections/sets of classes whose objects send/receive messages) The more messages or contracts between objects, the more likely they are in the same partition
© DHBK 2007
278/Chapter
5.1.1 Chuyển từ mô hình phân tích sang mô hình thiết kế
• 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)
© DHBK 2007
•
Layers
279/Chapter
5.1.1 Chuyển từ mô hình phân tích sang mô hình thiết kế
280/Chapter
© DHBK 2007
5.1.2 Gói và biểu đồ gói Package = UML representation (or abstraction over) collaboration OR partition OR layer •Logical grouping of any UML elements
Simplifies (large numbers of) UML diagrams Groups related elements into a single higher-level element Packages involving different kinds of construct (e.g. at particular layers) use different kinds of relationship between those constructs, i.e. in a class diagram, package = group (or set) of classes by aggregation or association relationship
281/Chapter
© DHBK 2007
5.1.2 Gói và biểu đồ gói • 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.
282/Chapter
© DHBK 2007
5.1.2 Gói và biểu đồ gói
A PACKAGE
A DEPENDENCY RELATIONSHIP
Package
© DHBK 2007
5.1.2 Gói và biểu đồ gói Ví dụ
283/Chapter
284/Chapter
© DHBK 2007
5.1.2 Gói và biểu đồ gói Collaborations, partitions and layers Collaborations usually are modelled as packages in UML
Collaborations usually factored into a set of partitions on a layer
Partitions can be composed of other partitions (hierarchically hence forming subsystems) Classes can be in partitions, those partitions then contained in other partitions, placed on a layer Simple example:- small part of appointments system
285/Chapter
© DHBK 2007
Package Diagram of Appointment System
Problem domain Classes: Patient, Appt. by intermediate Data Access and Manipulation (DM) Classes: DM-Patient, DM-Appt
Separated from object persistence Classes: Patient table, Appt. table
Patient UI dependent on Patient class DM-Patient class dependent on Patient class Patient table dependent on Patient class
ularity (information hiding and encapsulation again) simplifies maintenance (changes are psulated within “module boundary”) and increases reusability (module’s interface defines sages that can be responded to, module can be used/reused “as is” or adapted for other us
286/Chapter
© DHBK 2007
5.1.2 Gói và biểu đồ gói Steps for Identifying Packages and Building Package Diagrams
•
Set the context
•
Cluster classes together based on shared relationships
•
Model clustered classes as a package
•
Identify dependency relationships among packages
•
Place dependency relationships between packages
© DHBK 2007
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
287/Chapter
Step 2: Cluster classes together based on shared relationships, i.e. 288/Chapter form par using relationships (generalisation, aggregation, kinds of association and message passing between objects) shared by classes
© DHBK 2007
Examine analysis models
Class Diagram
Sequence Diagram(s)
Communication Diagram(s) Classes in a generalisation hierarchy put in a single partition
289/Chapter
© DHBK 2007
Step 3: Place clustered classes in partition and model clustered classes as a package, i.e. model partitions as packages
290/Chapter
© DHBK 2007
Step 4: Identify dependency relationships between packages, i.e. relationships that cross boundaries of packages = potential dependencies
a) association relationship between Person Pkg and Appt. Pkg via Association between Doctor class and Appt. class and Patient Pkg contained in Person Pkg
b) Appt. pkg via association between Patient and Appt classes and Treatment Pkg via association between Patient and Symptom classes
291/Chapter
© DHBK 2007
Step 5: Place dependency relationships between packages, i.e. between Person Package and Appt. Package, Person Package and Treatment Package Show dependency relations as “pure” package diagram showing ONLY dependency relations that CAN be created between packages
PD Layer Person Package
Appt. Package
Patient Package
Treatment Package
© DHBK 2007
292/Chapter
Worked Example: Applying Concepts at CD Selections: First, previous lectures...
•
Chapter 5: Functional and Non-functional Requirements
•
Chapter 6: Functional Model = activity diagram + use-case descriptions & diagrams
•
Chapter 7: Structural Model = CRC cards + class diagram
•
Chapter 8: Behavioural Models for “Places Order” use-case + “Order” class (sequence diagram, communication diagram, behavioural state machine)
•
Next: Create package diagram for CD Selections
© DHBK 2007
Example: Applying Concepts at CD Selections
•
Set the context = Problem Domain Layer
•
Cluster classes, i.e. review relationships amongst classes
293/Chapter
Sequence Diagram (Places Order Use Case
CD Selections Class Diagram (Places Order Use-Case View)
Communication Diagram (Place Order Use Case)
© 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
294/Chapter
© DHBK 2007 •
295/Chapter
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)
•
Order Class and Order Item Class = partition
•
Search Req Class and CD List Class = partition
Recall, cluster Mkt Info, Review, Artist Info, Sample Clip classes into partition
© DHBK 2007
•
Model each partition as a package n.b. Credit Card Centre not yet contained in a package
296/Chapter
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)
© DHBK 2007
297/Chapter
Place the dependency relations on the package diagram (and increase clarity by dependency relationships between packages = pure package diagram of PD layer of CD Selections containing highest level packages only (+ Credit Card Centre class) and their dependency relationships
298/Chapter
© DHBK 2007
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 problems e.g. for CD selections, can use ordering “web interface” as strategic enabler to better understand customer’s who order online, using technology to mine data obtained via custom applications • Has potential to change components e.g. for CD selections all components in custom application are available and can be reused in whole or part • Usually increases personnel skills e.g. for CD selections, developers build technical skills and business knowledge as they further evolve the system • Potentially requires significant resources • Potentially adds significant risk
299/Chapter
© DHBK 2007
5.1.3 Các chiến lược thiết kế •
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
300/Chapter
© DHBK 2007
5.1.3 Các chiến lược thiết kế •
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”
301/Chapter
© DHBK 2007
5.1.3 Các chiến lược thiết kế •
Outsourcing – (now increasingly popular) = pay external vendor, developer, service provider to create system For CD selections, use a Web Service Provider who provides commercial order taking system Potentially external suppliers have higher level of skill Their services MUST work to generate income, so web services are built by “experts” with significant experience Is not “cost free” – lose absolute control over software and data, inhouse expertise is not increased Only outsource what is properly understood in advance Needs rigorous planning and analysis of needs in advance of contract negotiations, must identify vendor, developer or service provider with proven track record of success in system and supporting technology for system’s needs Vendor choice and contract & payment method by strictly controlled criteria Time and arrangement deal Fixed price Value added contract
302/Chapter
© DHBK 2007
5.1.3 Các chiến lược thiết kế • Outsourcing Guidelines Keep lines of communication open with outsourcer Define and stabilize requirements before signing a contract View outsourcing relationship as partnership Select outsource vender carefully Assign person to manage relationship Don’t outsource what you don’t understand Emphasize flexible requirements, long-term relationships, and short-term contracts
303/Chapter
© DHBK 2007
5.1.3 Các chiến lược thiết kế • Select a strategy (1): Business need Common business needs best served by packaged systems, i.e. when custom built alternative does not require any special business needs, when system is not critical to company In-house experience Custom application only feasible if sufficient in-house skills for all functional and technical challenges, otherwise packaged system (possibly with in-house integration software added) Project skills Technical, e.g. Java programming and IDE skills, data design and SQL programming skills Functional, e.g. in electronic commerce If electronic commerce is to become basis for company’s future development, in-house skills in EC and technical skills in its exploitation must be further developed Some skills, e.g. network security, might be operational issue which can be outsourced
304/Chapter
© DHBK 2007
5.1.3 Các chiến lược thiết kế • Select a strategy (2): Project management Custom applications require significant project management via application of a proven system development methodology (or collection of integrated methods) Packaged and outsourced systems require different kinds of management, e.g. of contract and delivery Time frame If time to meet business requirement(s) is limited (or short), requirements are “standard” and well-defined, then packaged or outsourced most likely strategies, outsourced for standard, packaged for well-defined
305/Chapter
© DHBK 2007
5.1.4 Phát triển thiết kế thực tế •
Alternative Matrix Combines several feasibility analyses into one grid Revisits technical, economic, and organizational feasibility Created using same steps as feasibility analysis (chapter 3), but combines several analyses into a single matrix for comparison Matrix is represented by a grid Contains technical, budget, organisational feasibilities for each candidate, pro’s and cons, other useful information, e.g. criticality, future-proofing Sometimes “weights” are provided n.b. in AHP weights are derived (mathematically) from judgements over criteria
•
Request For Proposal Aids development of alternative matrix Description of the system you propose to be built Vendors, developers, service providers respond with proposals including how they will address needs as well as stating cost and time requirements. Similar (less effort-intensive) Request For Information (RFI)
306/Chapter
© DHBK 2007
5.1.4 Phát triển thiết kế thực tế
307/Chapter
© DHBK 2007
5.2 Thiết kế lớp và phương thức 5.2.1 Giới thiệu 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
308/Chapter
© DHBK 2007
5.2.1 Giới thiệu • Các mức trừu tượng của hệ thống hướng đối tượng
309/Chapter
© DHBK 2007
5.2.2 Các tiêu chí thiết kế • Coupling • Cohesion • Connascence
310/Chapter
© DHBK 2007
5.2.2 Các tiêu chí thiết kế • 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
311/Chapter
© DHBK 2007
5.2.2 Các tiêu chí thiết kế Types of interaction coupling
312/Chapter
© DHBK 2007
5.2.2 Các tiêu chí thiết kế • Interaction coupling: Law of Demeter = minimise number of objects that can receive messages from a given object Objects only send message to: A) Itself B) An object an object “contained” in an attribute of itself (or an object of one of its superclasses) C) An object passed as a parameter to the mehod D) An object created by the method E) An object stored in a variable whose declaration scope is the entire program (a “global” variable) Coupling increase if: calling method passes attributes to called method Calling method depends on value returned by called method
313/Chapter
© DHBK 2007
5.2.2 Các tiêu chí thiết kế • Cohesion: Refers to how single-minded a module is within a system 3 types of cohesion: Method Class Generalization/specialization
314/Chapter
© DHBK 2007
5.2.2 Các tiêu chí thiết kế •
Cohesion: Method cohesion: Address the cohesion within an individual method. Methods should do one and only one thing
315/Chapter
© DHBK 2007
5.2.2 Các tiêu chí thiết kế •
Cohesion: Class cohesion: Is the level of cohesion among the attributes and methods of a class A class should only represent one thing A cohesive class should: Contain multiple methods that are visible outside the class Have methods that refer to attributes or other methods defined with the class or its superclass Not have any control-flow coupling between its methods
316/Chapter
© DHBK 2007
5.2.2 Các tiêu chí thiết kế •
Cohesion: Class cohesion:
317/Chapter
© DHBK 2007
5.2.2 Các tiêu chí thiết kế •
Cohesion: Generalization/specialization cohesion: Addresses the sensibility of the inheritance hierarchy
318/Chapter
© DHBK 2007
5.2.2 Các tiêu chí thiết kế •
Connascence: Two modules (classes or methods) are so intertwined, that if you make a change in one, it is likely that a change in the other will be required Connascence and encapsulation Minimize overall connascence by eliminating any unnecessary connascence throughout the system, Minimize connascence across any encapsulation boundaries, such as method boundaries and class boundaries, Maximize connascence within any encapsulation boundary.
319/Chapter
© DHBK 2007
5.2.2 Các tiêu chí thiết kế •
Connascence:
© DHBK 2007
• • • • •
320/Chapter
5.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
© DHBK 2007
321/Chapter
5.2.3 Các hoạt động thiết kế đối tượng
• Additional specification: Ensure the classes are both necessary and sufficient for the problem Finalize the visibility of the attributes and methods of each class Determine the signature of every method of each class Define constraints to be preserved by objects
© DHBK 2007
322/Chapter
5.2.3 Các hoạt động thiết kế đối tượng
• Identifying opportunities for reuse: Analysis patterns Representations of the problem-domain
Design patterns Useful grouping of collaborating classes that provide a solution to a commonly occurring problem Many design patterns are available in C++ or Java source code
Frameworks A set of implemented classes that can be used as a basis for implementing an application Most frameworks allow us to create subclasses to inherit from classes in the framework
Libraries components
© DHBK 2007
323/Chapter
5.2.3 Các hoạt động thiết kế đối tượng
• Identifying opportunities for reuse: Libraries Class library similar to framework, i.e. has classes designed for reuse More domain specific, i.e. can be used to realise some layer, e.g. HIC layer Can be used to: Create instances of classes in library Create subclasses by inheritance, and then objects of subtype(s) Using inheritance again increases inheritance coupling and Connascence Directly instantiating class in library, object dependency created between created object and library object due to signatures of methods in library object, i.e. increases interaction coupling between class library object and created object
© DHBK 2007
324/Chapter
5.2.3 Các hoạt động thiết kế đối tượng
• Identifying opportunities for reuse: Components: Self-contained & encapsulated software that can be plugged into a system Provides specific funtionality Typically components implemented using ActiveX or JavaBean Component has well-defined Application Program Interface (API) API = set of method interfaces to objects contained in component Internal operation of component hidden by API Components can be implemented using class libraries and frameworks Unless API changes between between version of component, only need to relink component to application (no recompilation required)
© DHBK 2007
325/Chapter
5.2.3 Các hoạt động thiết kế đối tượng
• Identifying opportunities for reuse:
© DHBK 2007
326/Chapter
5.2.3 Các hoạt động thiết kế đối tượng
• Restructuring the design: Factoring Separate out shared aspects of a method or class into a new method or class New class related to existing classes via inheritance, aggregation or association Normalization Identifies classes missing from the design All association and aggregation relationships converted to attributes of the class Challenge inheritance relationships to ensure they only support a generalization/specialization semantics
© DHBK 2007
327/Chapter
5.2.3 Các hoạt động thiết kế đối tượng
• Optimizing the design Simple optimisations make an existing design more efficient, but must not make optimised design significantly more difficult to reason about, i.e. optimsation is a “trade-off” between efficiency and ease of understanding the design optimisations below need to be considered. [1] access paths between objects [2] attributes of each class [3] direct and indirect “fan-out” of each method [4] execution order of statements [5] unnecessary recomputation
© DHBK 2007
328/Chapter
5.2.3 Các hoạt động thiết kế đối tượng
• 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
© DHBK 2007
329/Chapter
5.2.3 Các hoạt động thiết kế đối tượng
• Optimizing the design [4] execution order of statements In frequently used methods, order of statements may be nonoptimal 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
© DHBK 2007
330/Chapter
5.2.3 Các hoạt động thiết kế đối tượng
• Map Problem Domain Classes to Implementation Languages: OO designs assume class-based OO programming language used to implement those designs e.g. UML class diagram is-a specification of a class in a classbased 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
© DHBK 2007
331/Chapter
5.2.3 Các hoạt động thiết kế đối tượng
• Map Problem Domain Classes to Implementation Languages: [1] design uses multiple inheritance, language has only single inheritance A) Convert multiple inheritance relationships to “superclass”-subclass association relationships If additional superclasses are concrete (objects of the class can be instantiated) then multiplicity from superclass to subclass is 0..1 Otherwise multiplicity is 1..1 Add an exclusive-OR constraint between associations Add appropriate methods to ensure all information remains available to existing class B) Copy ALL the attributes and methods of the additional superclasses to ALL the subclassess and remove additional superclass from the design
© DHBK 2007
332/Chapter
5.2.3 Các hoạt động thiết kế đối tượng
• Map Problem Domain Classes to Implementation Languages: [1] design uses multiple inheritance, language has only single inheritance
concrete SuperClass1 SuperClass2 -attribute1 1..1 -attribute3 -attribute2 -attribute4 0..*
Class1 -attribute5 -attribute6
{XOR}
SuperClass3 1..1 -attribute7 -attribute8
0..*
Class2 -attribute5 -attribute6
[1]All classes preserved [2]Increases amount of message passing [3]Adds to processing requirement due to XOR
© DHBK 2007
333/Chapter
5.2.3 Các hoạt động thiết kế đối tượng
• Map Problem Domain Classes to Implementation Languages: [1] design uses multiple inheritance, language has only single inheritance
abstract SuperClass1 -attribute1 -attribute2
SuperClass2 -attribute3 -attribute4
Class1 -attribute3 -attribute4 -attribute5 -attribute6
SuperClass3 -attribute7 -attribute8
Class2 -attribute3 -attribute4 -attribute5 -attribute6
Potential Inheritance Conflicts
© DHBK 2007
334/Chapter
5.2.3 Các hoạt động thiết kế đối tượng
• Map Problem Domain Classes to Implementation Languages: [2] implementation language is object-based and not classbased Need to factor out ALL uses of inheritance from problem-domain class design All superclasses concrete SuperClass1 SuperClass2 -attribute1 1..1 -attribute3 -attribute2 -attribute4 1..10..* 1..1
Class1 -attribute5 -attribute6
{XOR}
SuperClass3 1..1 -attribute7 -attribute8
0..*
Class2 -attribute5 -attribute6
1..1 1..1
© DHBK 2007
335/Chapter
5.2.3 Các hoạt động thiết kế đối tượng
• Map Problem Domain Classes to Implementation Languages: [2] implementation language is object-based and not classbased SuperClass1 -attribute1 -attribute2
If all superclasses are abstract SuperClass3 SuperClass2 -attribute7 -attribute3 -attribute8 -attribute4
Class1 -attribute1 -attribute2 -attribute3 -attribute4 -attribute5 -attribute6 -attribute7 -attribute8
Class2 -attribute1 -attribute2 -attribute3 -attribute4 - attribute5 -attribute6 -attribute7 -attribute8
Potential Inheritance Conflicts
© DHBK 2007
336/Chapter
5.2.3 Các hoạt động thiết kế đối tượng
• Map Problem Domain Classes to Implementation Languages: [3] language is of another (less expressive) language paradigm, e.g. C or Pascal are of the imperative-procedural paradigm Stay away from this! But if necessary, factor out all uses of Polymorphism Dynamic binding Encapsulation Information hiding
337/Chapter
© DHBK 2007
5.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
338/Chapter
© DHBK 2007
5.2.4 Ràng buộc và giao kèo • Pre- and post-conditions model constraints on individual methods • Invariants model constraints (that must always be true) for all instances of a class, e.g. Domains (in DB) or types (in design/programming language) of attributes Multiplicity of attributes Legal values of attributes including attributes that model association and aggregation and relationships e.g. if association relationship is required, invariant is created to enforce relationship to have valid value for instance to exist • Invariants usually attached to the class, e.g. CRC cards or class diagrams as a set of assertions
© DHBK 2007
•
Example:-
Attribute Constraint: Order Number IS unsigned long
339/Chapter Attribute Constraint: Customer IS INSTANCE OF Customer Class
Back: Attributes: Order Number (1:1) (unsigned long) Date (1..1) (Date) Sub Total (0..1) (double) Tax (0..1) (double) {Sub Total = sum(Product Order.GetExtension()) hipping (0..1) (double) Total (0..1) (double) Customer (1..1) (Customer) Cust ID (1..1) (unsigned long) (Cust ID = Customer.GetCustID()} State (1..1) (State) StateName (String) {State Name = State.GetState()}
Attribute Constraint Cust ID IS unsigned Long Constraint: Instance of Order EXISTS Relationships: AND IF (instance of Customer class AND Generalisation(a-kindInvariant instance of State class AND of): MUST HAVE one and >=1 instance of Product class) Aggregation (has-parts): ONLY one value ASSOCIATED WITH order object (1..1) = Other Associations: Product{1..*} Customer(1..1} State{1..1} Customer. GetCustID(
© DHBK 2007
Product Order
Invariants On a Class Diagram(Not recommended – Use CRC card for Invariants)
<> {Sub Total= Sum(Product Order.GetExtension())}}
Customer -Cust ID -Last Name -First Name
340/Chapter
Order Product Quantity Extension
Order Product -Order Number: unsigned long -Product Number -Date[1..]: Date -Product Desc 1..1 0..* -Sub Total[0..1]: double 0..* 1..* -Price -Tax[0..1]:double -Shipping[0..1]:double -Total[0..1]double -Tax[0..1]: double -Customer[1..1]: Customer <> -Cust ID[1..1]: unsigned long {Tax=State.GetTaxRate() -State[1..1] State *SubTotal} -State Name[1..1: String State
<> {Cust ID=Customer.GetCustID()} <> {State Name=State.GetState()}
0..* 1..1-State Tax RateProduct Desc
341/Chapter
© DHBK 2007
5.2.4 Ràng buộc và giao kèo •
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
342/Chapter
© DHBK 2007
Specific Method OF specific Class
Unique Contract ID
List of classes and methods that send a message to this List of use cases containingmethod this method where method is used to realise implementation of the use case (from server class’s CRC card and associated use cases) What the method does NOT how it does it
types of parameters passed type of value returned to its clients
= method signature
343/Chapter
© DHBK 2007
5.2.5 Xác định phương thức • • • •
General information Events Message passing Algorithm specification Structured English Pseudocode UML activity diagram
344/Chapter General Information (for managing programming effor
© DHBK 2007
Method Name Contract ID Programming Language:
Class Name Programmer:
ID: Date Due:
Visual Basic
SmallTalk
C++
Java
e.g. user initiated event(mouse event, keystroke event), Triggers/Events system event or event initiated by another method Arguments Received: Data Type:
Messages Sent & Arguments Passed ClassName.MethodName:
Argument Returned: Data Type: Algorithithm Specification:
Notes: Message passing to and from method (c.f. sequence and collaboration diagrams) Arguments = attributes and data structures in implemented method Data Type:
Notes:
Notes:
345/Chapter
© DHBK 2007
•
Structured English will suffice for algorithm specification…
Algorithm Specification: Action Statement
Examples:
Profits = Revenues – Expenses Generate Inventory-Report
IF Statement
Examples: IF Customer NOT in Customer Object Store THEN Add Customer record to Customer Object Store ELSE Add Current-Sale to Customer’s Total Sales Update Customer record in Customer Object Store
FOR Statement
Examples: FOR all Customers in Customer Object Store DO Generate a new line in Customer-Report Add Customer’s Total-Sales to Report-Total
CASE Statement Examples: CASE IF Income < 10,000: Marginal-tax-rate IF Income < 20,000: Marginal-tax-rate IF Income < 30,000: Marginal-tax-rate IF Income < 40,000: Marginal-tax-rate ELSE Marginal-tax-rate = 38 percent ENDCASE Notes:
= = = =
10 20 31 35
percent percent percent percent
© DHBK 2007
346/Chapter
• 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
2/Chapter
© DHBK 2007
Giới thiệu • 4 ĐVHT = 60 tiết • Học trên lớp + Bài tập lớn • Điểm = Điểm thi + Điểm bài tập lớn (70%) + (30%) • Điều kiện thi: Phải có bài tập lớn • Bài tập lớn: Làm theo nhóm tối đa 5 sinh viên Nội dung: phân tích và thiết kế hệ thống sử dụng Rational Rose Đề tài: sinh viên tự chọn đề tài
• Mục đích của môn học Trang bị cho sinh viên một phương pháp có hệ thống để phân tích và thiết kế hệ thống
3/Chapter
© DHBK 2007
Nội dung 1. Giới thiệu chung về phân tích và thiết kế hệ thống 2. Giới thiệu về phân tích và thiết kế hướng đối tượng với UML 3. Lập kế hoạch 4. Phân tích hệ thống 5. Thiết kế hệ thống 6. Triển khai hệ thống
4/Chapter
© DHBK 2007
Tài liệu tham khảo • Systems Analysis and Design with UML Version 2.0-An object oriented approach; Alan Dennis, Barbara Haley Wixom, David Tegarden. • www.uml.org • www.rational.com • www.Google.com
© DHBK 2007
5/Chapter
Chương 1. Giới thiệu chung về phân tích và thiết kế hệ thống
1.1 Giới thiệu 1.2 Quy trình phát triển hệ thống 1.3 Các phương pháp phát triển hệ thống
6/Chapter
© DHBK 2007
1.1 Giới thiệu
7/Chapter
© DHBK 2007
1.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
© DHBK 2007
• • • • •
8/Chapter
1.2 Quy trình phát triển hệ thống Lập kế hoạch
Xác định giá trị kinh doanh của hệ thống Phân tích tính khả thi Xây dựng kế hoạch công việc Xác định nguồn nhân lực cho dự án Điều khiển và quản lý dự án
© DHBK 2007
• • • •
9/Chapter
1.2 Quy trình phát triển hệ thống Phân tích
Phân tích hệ thống Thu thập các nguồn thông tin Mô hình hoá quá trình Mô hình hóa dữ liệu
© DHBK 2007
• • • • •
10/Chapter
1.2 Quy trình phát triển hệ thống 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
© DHBK 2007
11/Chapter
1.2 Quy trình phát triển hệ thống Triển khai
• Xây dựng hệ thống • Cài đặt hệ thống
© DHBK 2007
12/Chapter
1.2 Quy trình phát triển hệ thống Các pha và kết quả của từng pha Process
Product
Planning
Project Plan
Analysis
System Proposal
Design Implementation
System Specification New System and Maintenance Plan
© DHBK 2007
13/Chapter
1.3 Các phương pháp phát triển hệ thống
• Thiết kế cấu trúc (Structured design) Phương pháp thác nước (waterfall method) Phương pháp phát triển song song (Parallel development)
• Phương pháp phát triển nhanh ứng dụng (RAD) Phương pháp phát triển theo các pha Phương pháp xây dựng nguyên mẫu (prototyping) Thông thường (regular) Loại bỏ (throwaway)
• Phương pháp phát triển rất nhanh (Agile development) XP (extreme programming)
14/Chapter
© DHBK 2007
1.3.1 Thiết kế cấu trúc • Dự án sẽ tiến triển từ bước này sang bước tiếp theo một cách có hệ thống • Thông thường, một bước phải được hoàn thành trước khi bắt đầu bước tiếp theo
© DHBK 2007
1.3.1 Thiết kế cấu trúc Phương pháp thác nước
15/Chapter
© DHBK 2007
1.3.1 Thiết kế cấu trúc Phương pháp thác nước
16/Chapter
• Ư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)
© DHBK 2007
17/Chapter
1.3.1 Thiết kế cấu trúc Phương pháp phát triển song song
18/Chapter
© DHBK 2007
1.3.2 RAD • Các nhân tố quan trọng:
Công cụ CASE JAD Ngôn ngữ lập trình thế hệ thứ tư/ visual Công cụ tạo mã
© DHBK 2007
19/Chapter
1.3.2 RAD Phương pháp phát triển theo pha
© DHBK 2007
1.3.2 RAD Phương pháp xây dựng nguyên mẫu thông thường
20/Chapter
© DHBK 2007
21/Chapter
1.3.2 RAD Phương pháp xây dựng nguyên mẫu loại bỏ
22/Chapter
© DHBK 2007
1.3.3 Lựa chọn phương pháp phù hợp • Tiêu chí:
Độ rõ ràng, đầy đủ của các yêu cầu của người sử dụng Khả năng, mức độ thành thạo về công nghệ Độ phức tạp của hệ thống Độ tin cậy của hệ thống Quỹ thời gian
© DHBK 2007
23/Chapter
1.3.3 Lựa chọn phương pháp phù hợp
© DHBK 2007
24/Chapter
Chương 2: Giới thiệu về phân tích và thiết kế hướng đối tượng với UML
2.1 Giới thiệu 2.2 Các đặc điểm cơ bản của hệ thống hướng đối tượng 2.3 UML 2.0 2.4 Phân tích và thiết kế hướng đối tượng với UML 2.0
25/Chapter
© DHBK 2007
2.1 Giới thiệu • Lịch sử phát triển của ngôn ngữ lập trình: First Generation (1954 – 1958) Fortran I
Second Generation (1959 – 1961) Fortran II, Algol, Cobol
Third Generation (1962 – 1970) PL/I, Pascal
Object Oriented Languages Smalltalk, C++, Java
26/Chapter
© DHBK 2007
2.1 Giới thiệu • Lịch sử phát triển của UML
27/Chapter
© DHBK 2007
2.1 Giới thiệu • Lịch sử phát triển của UML 2003
UML 2.0 UML 1.4.1
UML 1.4 (action semantics) UML 1.3 (extensibility)
2002 2001 1998 1997
UML 1.1 (OMG Standard) 1996 Rumbaugh
Booch
Jacobson
Foundations of OO (Nygaard, Goldberg, Meyer, Stroustrup, Harel, Wirfs-Brock, Reenskaug,…)
1967
28/Chapter
© DHBK 2007
2.1 Giới thiệu • Thiết kế cấu trúc và thiết kế hướng đối tượng
29/Chapter
© DHBK 2007
2.1 Giới thiệu • Thiết kế cấu trúc và thiết kế hướng đối tượng
© DHBK 2007
30/Chapter
2.2 Các đặc điểm cơ bản của hệ thống hướng đối tượng
2.2.1 Lớp và đối tượng 2.2.2 Phương thức và message 2.2.3 Tóm lược và ẩn thông tin (Encapsulation and Information Hiding) 2.2.4 Thừa kế (inheritance) 2.2.5 Đa hình thái và liên kết động (Polymorphism and Dynamic Binding)
31/Chapter
© DHBK 2007
2.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
32/Chapter
© DHBK 2007
2.2.1 Lớp và đối tượng
33/Chapter
© DHBK 2007
2.2.1 Lớp và đối tượng 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 };
34/Chapter
© DHBK 2007
2.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
© DHBK 2007
35/Chapter
2.2.2 Phương thức và message
36/Chapter
© DHBK 2007
2.2.3 Tóm lược và ẩn thông tin • Encapsulation combination of data and process into an entity
• Information Hiding Only the information required to use a software module is published to the user
37/Chapter
© DHBK 2007
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
38/Chapter
© DHBK 2007
2.2.4 Thừa kế
39/Chapter
© DHBK 2007
2.2.4 Thừa kế
40/Chapter
© DHBK 2007
2.2.5 Đa hình thái và liên kết động • Polymorphism A message can be interpreted differently by different classes of objects
• Dynamic Binding Sometimes called late binding Delays typing or choosing a method for an object until run-time
• Static Binding Type of object determined at compile time
© DHBK 2007
41/Chapter
2.2.5 Đa hình thái và liên kết động
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33
// Fig. 20.1: shape.h // Definition of abstract base class Shape #ifndef SHAPE_H #define SHAPE_H class Shape { public: virtual double area() const { return 0.0; } virtual double volume() const { return 0.0; } // pure virtual functions overridden in derived classes virtual void printShapeName() const = 0; virtual void print() const = 0; }; #endif // Fig. 20.1: point1.h // Definition of class Point #ifndef POINT1_H #define POINT1_H #include
34 virtual void printShapeName() const { cout << "Point: "; } 35 virtual void print() const; 36 private: 37 int x, y; 38 }; 39 40 #endif
// x and y coordinates of Point
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: "; }
70
virtual void print() const;
71 private: 72
double radius;
73 }; 74 75 #endif
// radius of Circle
76 // Fig. 20.1: circle1.cpp 77 // Member function definitions for class Circle 78 #include
: 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 106 class Cylinder : public Circle { 107 public: 108
// default constructor
109
Cylinder( double h = 0.0, double r = 0.0,
110
int x = 0, int y = 0 );
111 112
void setHeight( double );
113
double getHeight();
114
virtual double area() const;
115
virtual double volume() const;
116
virtual void printShapeName() const { cout << "Cylinder: "; }
117
virtual void print() const;
118 private: 119
double height;
120 }; 121 122 #endif
// height of Cylinder
123 // Fig. 20.1: cylindr1.cpp 124 // Member and friend function definitions for class Cylinder 125 #include
155 // Fig. 20.1: fig20_01.cpp 156 // Driver for shape, point, circle, cylinder hierarchy 157 #include
186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219
point.print(); cout << '\n';
// static binding
circle.printShapeName(); circle.print(); cout << '\n';
// static binding // static binding
cylinder.printShapeName(); // static binding cylinder.print(); // static binding cout << "\n\n"; Shape *arrayOfShapes[ 3 ];
// array of base-class pointers
// aim arrayOfShapes[0] at derived-class Point object arrayOfShapes[ 0 ] = &point; // aim arrayOfShapes[1] at derived-class Circle object arrayOfShapes[ 1 ] = &circle; // aim arrayOfShapes[2] at derived-class Cylinder object arrayOfShapes[ 2 ] = &cylinder; // Loop through arrayOfShapes and call virtualViaPointer // to print the shape name, attributes, area, and volume // of each object using dynamic binding. cout << "Virtual function calls made off " << "base-class pointers\n";
2. Function calls
for ( int i = 0; i < 3; i++ ) virtualViaPointer( arrayOfShapes[ i ] ); // Loop through arrayOfShapes and call virtualViaReference // to print the shape name, attributes, area, and volume // of each object using dynamic binding.
220 221
cout << "Virtual function calls made off " << "base-class references\n";
222 223 224
for ( int j = 0; j < 3; j++ ) virtualViaReference( *arrayOfShapes[ j ] );
225 226
return 0;
227 } 228 229 // Make virtual function calls off a base-class pointer 230 // using dynamic binding. 231 void virtualViaPointer( const Shape *baseClassPtr ) 232 { 233
baseClassPtr->printShapeName();
234
baseClassPtr->print();
235
cout << "\nArea = " << baseClassPtr->area()
236
<< "\nVolume = " << baseClassPtr->volume() << "\n\n";
237 } 238 239 // Make virtual function calls off a base-class reference 240 // using dynamic binding. 241 void virtualViaReference( const Shape &baseClassRef ) 242 { 243
baseClassRef.printShapeName();
244
baseClassRef.print();
245
cout << "\nArea = " << baseClassRef.area()
246 247 }
<< "\nVolume = " << baseClassRef.volume() << "\n\n";
51/Chapter
© DHBK 2007
2.3 UML 2.0 2.3.1 Giới thiệu UML 2.3.2 Biểu đồ cấu trúc 2.3.3 Biểu đồ chức năng 2.3.4 Các cơ chế mở rộng 2.3.5 Tóm tắt
52/Chapter
© DHBK 2007
2.3.1 Giới thiệu về UML "The Unified Modeling Language (UML) is a graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system.” Grady Booch, Ivar Jacobsen, Jim Rumbaugh Rational Software
• UML chỉ đơn thuần là ngôn ngữ đồ hoạ để mô hình hoá chứ không phải là phương pháp để phát triển hệ thống
53/Chapter
© DHBK 2007
2.3.1 Giới thiệu về UML • UML 2.0 cung cấp 14 biểu đồ để mô hình hoá cấu trúc và chức năng của hệ thống, chia làm 2 nhóm: Biểu đồ mô hình cấu trúc Biểu đồ mô hình chức năng
54/Chapter
© DHBK 2007
2.3.2 Biểu đồ cấu trúc • 6 loại biểu đồ cấu trúc: Biểu đồ lớp (Class) Biểu đồ đối tượng (Object) Biểu đồ gói (package) Biểu đồ triển khai (Deployment) Biểu đồ thành phần (Component) Biểu đồ cấu trúc phức hợp (Composite structure diagrams)
55/Chapter
© DHBK 2007
2.3.2 Biểu đồ cấu trúc • Biểu đồ lớp (class diagram) Biểu diễn mối quan hệ giữa các lớp
56/Chapter
© DHBK 2007
2.3.2 Biểu đồ cấu trúc • Biểu đồ đối tượng (object diagram) Biểu diễn mối quan hệ giữa các đối tượng
57/Chapter
© DHBK 2007
2.3.2 Biểu đồ cấu trúc • 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
58/Chapter
© DHBK 2007
2.3.2 Biểu đồ cấu trúc • 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
59/Chapter
© DHBK 2007
2.3.2 Biểu đồ cấu trúc • 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
60/Chapter
© DHBK 2007
2.3.2 Biểu đồ cấu trúc • 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
61/Chapter
© DHBK 2007
2.3.3 Biểu đồ chức năng • 8 loại biểu đồ chức năng Biểu đồ hoạt động (activity diagram) Biểu đồ tương tác (interaction diagrams) Biểu đồ chuỗi 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)
62/Chapter
© DHBK 2007
2.3.3 Biểu đồ chức năng • 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)
63/Chapter
© DHBK 2007
2.3.3 Biểu đồ chức năng • 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
64/Chapter
© DHBK 2007
2.3.3 Biểu đồ chức năng • 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
65/Chapter
© DHBK 2007
2.3.3 Biểu đồ chức nă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
66/Chapter
© DHBK 2007
2.3.3 Biểu đồ chức nă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.
67/Chapter
© DHBK 2007
2.3.3 Biểu đồ chức nă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
68/Chapter
© DHBK 2007
2.3.3 Biểu đồ chức năng
69/Chapter
© DHBK 2007
2.3.3 Biểu đồ chức năng
70/Chapter
© DHBK 2007
2.3.3 Biểu đồ chức năng
71/Chapter
© DHBK 2007
2.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 { }
72/Chapter
© DHBK 2007
2.3.4 Các cơ chế mở rộng • 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 { }
73/Chapter
© DHBK 2007
2.3.4 Các cơ chế mở rộng • 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 << >>
74/Chapter
© DHBK 2007
2.3.5 Tóm tắt
© DHBK 2007
75/Chapter
2.4 Phân tích và thiết kế hướng đối tượng với UML 2.0
2.4.1 Đặc điểm cơ bản của OOAD 2.4.2 Ưu điểm của OOAD 2.4.3 The Unified Process 2.4.4 The MOOSAD
76/Chapter
© DHBK 2007
2.4.1 Đặc điểm cơ bản của OOAD • Use-case driven • Architecture Centric • Cấu trúc phần mềm quyết định việc mô tả, xây dựng và viết tài liệu hệ thống • 3 dạng cấu trúc của một hệ thống: • Chức năng (functional view): chức năng bên ngoài của hệ thống từ góc nhìn của người sử dụng : biểu đồ ca sử dụng, biểu đồ hoạt động • Cấu trúc tĩnh (static view): lớp, thuộc tính, phương thức, quan hệ • Cấu trúc động (dynamic view): chức năng bên trong của hệ thống: biểu đồ máy trạng thái chức năng
• Iterative and Incremental
77/Chapter
© DHBK 2007
2.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ế
78/Chapter
© DHBK 2007
2.4.2 Ưu điểm của OOAD
79/Chapter
© DHBK 2007
2.4.3 The Unified process • Unified process là một phương pháp phát triển hệ thống trong đó quy định khi nào thì sử dụng các kỹ thuật UML và sử dụng chúng như thế nào trong quá trình phân tích và thiết kế hệ thống. Tác giả: Booch, Jacobsen, Rumbaugh Là phương pháp hướng đối tượng Không phải là một quy trình phát triển phần mềm hoàn thiện Không xét đến các vấn đề về phân bổ nhân lực, ngân quỹ, quản lý hợp đồng Không quy định về các hoạt động bảo trì hay hỗ trợ khách hàng Không xét đến các vấn đề tương tác giữa các dự án
80/Chapter
© DHBK 2007
2.4.3 The Unified process
81/Chapter
© DHBK 2007
2.4.3 The Unified process • Pha khởi tạo (Inception): giống như pha lập kế hoạch Các bước liên quan: Mô hình hoá giá trị kinh doanh của hệ thống (business modeling) * Xác định yêu cầu (requirements)* Phân tích (analysis)* Thiết kế (design) Thực hiện (implementation) Kiểm tra (test) Môi trường phát triển (environment)*
Kết quả: Phạm vi của dự án Các yêu cầu và ràng buộc quan trọng Kế hoạch dự án bước đầu Miêu tả tính khả thi và rủi ro của dự án Lựa chọn môi trường cần thiết để phát triển hệ thống
82/Chapter
© DHBK 2007
2.4.3 The Unified process • Pha phát triển (elaboration): hoàn thiện mô hình kinh doanh, đánh giá lại rủi ro và hoàn thiện kế hoạch dự án Cá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 UML Phiên bản hoạt động đầu tiên của hệ thống
83/Chapter
© DHBK 2007
2.4.3 The Unified process • Pha xây dựng (construction): tập trung chủ yếu vào lập trình Cá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
84/Chapter
© DHBK 2007
2.4.3 The Unified process • Pha chuyển tiếp (transition): tập trung chủ yếu vào kiểm tra và triển khai Cá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ống Hướng dẫn sử dụng Kế hoạch hỗ trợ khách hàng, kế hoạch nâng cấp hệ thống
85/Chapter
© DHBK 2007
2.4.3 The Unified process •
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
86/Chapter
© DHBK 2007
2.4.3 The Unified process •
Các bước kỹ thuật (Engineering workflows) 1. 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
2. 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
3. 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
4. Triển khai (deployment) Đóng gói phần mềm, phân phối, cài đặt và beta testing
87/Chapter
© DHBK 2007
2.4.3 The Unified process •
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++
88/Chapter
© DHBK 2007
2.4.4 MOOSAD
89/Chapter
© DHBK 2007
Chương 3. Lập kế hoạch 3.1 Khởi tạo dự án (Project initiation) 3.2 Quản lý dự án (Project Management)
90/Chapter
© DHBK 2007
3.1 Khởi tạo dự án 3.1.1 Giới thiệu 3.1.2 Yêu cầu hệ thống (system request) 3.1.3 Phân tích tính khả thi (feasibility analysis) 3.1.4 Lựa chọn dự án
91/Chapter
© DHBK 2007
3.1.1 Giới thiệu
Nhu cầu kinh doanh
Tài liệu yêu cầu hệ thống Project sponsor
Hội đồng duyệt dự án Yes
No
Phân tích tính khả thi Project sponsor + analyst Yêu cầu hệ thống đã chỉnh sửa
Hội đồng duyệt dự án
92/Chapter
© DHBK 2007
3.1.1 Giới thiệu • 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)
© DHBK 2007
93/Chapter
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)
© DHBK 2007
94/Chapter
3.1.2 Yêu cầu hệ thống (system request)
• Chủ nhiệm dự án (project sponsor) Người thuộc phòng kinh doanh Người thuộc phòng IT có thể là chủ nhiệm hoặc đồng chủ nhiệm dự án CIO, CEO
• Nhu cầu kinh doanh (business need): why? Xuất phát từ: Phòng kinh doanh Phòng IT Chuyên gia tư vấn bên ngoài
Phát sinh khi: 1 chiến dịch kinh doanh mới cần được hỗ trợ cần tìm kiếm thêm khách hàng cần cải thiện việc trao đổi với nhà phân phối việc kinh doanh của công ty có vấn đề: cổ phiếu giảm, hỗ trợ khách hàng kém, bị cạnh tranh công nghệ mới nhiều tiềm năng xuất hiện
© DHBK 2007
95/Chapter
3.1.2 Yêu cầu hệ thống (system request)
• Yêu cầu kinh doanh (business requirement) Hệ thống sẽ làm gì Các chức năng của hệ thống
• Giá trị kinh doanh (business values) Giá trị hữu hình: ví dụ: 20 % giảm về chi phí Giá trị vô hình: ví dụ: cải thiện chất lượng dịch vụ khách hàng, cải thiện vị trí cạnh tranh
• Các vấn đề đặc biệt ví dụ: thời hạn hoàn thành
96/Chapter
© DHBK 2007
Case study: CD selections • Giới thiệu chung về công ty CD selections: 50 cửa hàng băng đĩa ca nhạc ở California Doanh số bán hàng: 50 triệu USD Tăng trưởng 3-5 % / năm Có website cung cấp các thông tin cơ bản về công ty như chỉ dẫn đường đi đến, giờ mở cửa, địa chỉ liên hệ
• Margaret Mooney, phó chủ tịch phụ trách thị trường có ý tưởng bán CD trên mạng Internet
97/Chapter
© DHBK 2007
Case study: CD selections
98/Chapter
© DHBK 2007
3.1.3 Phân tích tính khả thi • Khả thi về kỹ thuật (technical feasibility) • Khả thi về kinh tế (economic feasibility) • Khả thi về mặt tổ chức (organizational feasibility)
99/Chapter
© DHBK 2007
3.1.3 Phân tích tính khả thi • Khả thi về kỹ thuật (technical feasibility) (can we build it ?) Mức độ quen thuộc với ứng dụng Mức độ quen thuộc với công nghệ Kích thước của dự án: Số lượng người tham dự thời gian độ phức tạp của hệ thống
Sự tương thích của hệ thống mới với hệ thống đang tồn tại quyết định dựa trên việc so sánh với các dự án trước đó hoặc tham khảo ý kiến của chuyên gia công nghệ
100/Chapter
© DHBK 2007
3.1.3 Phân tích tính khả thi • Khả thi về kinh tế (economic feasibility) (should we build it ?) Xác định các loại chi phí và lợi nhuận Chi phí phát triển hệ thống (1 lần) Chi phí vận hành (chi phí thường xuyên) Lợi nhuận hữu hình Lợi nhuận vô hình
101/Chapter
© DHBK 2007
3.1.3 Phân tích tính khả thi
102/Chapter
© DHBK 2007
3.1.3 Phân tích tính khả thi • 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
103/Chapter
© DHBK 2007
3.1.3 Phân tích tính khả thi • 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
104/Chapter
© DHBK 2007
3.1.3 Phân tích tính khả thi
105/Chapter
© DHBK 2007
3.1.3 Phân tích tính khả thi • 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
106/Chapter
© DHBK 2007
3.1.3 Phân tích tính khả thi • Khả thi về kinh tế (economic feasibility) (should we build it ?)
107/Chapter
© DHBK 2007
3.1.3 Phân tích tính khả thi • Khả thi về kinh tế (economic feasibility) (should we build it ?)
108/Chapter
© DHBK 2007
3.1.3 Phân tích tính khả thi • Khả thi về kinh tế (economic feasibility) (should we build it ?)
109/Chapter
© DHBK 2007
3.1.3 Phân tích tính khả thi • 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
110/Chapter
© DHBK 2007
3.1.4 Lựa chọn dự án • 3 phương án: Thông qua Loại bỏ Xem xét lại
• Phụ thuộc vào: ROI, giá trị NPV của lợi nhuận, thời gian hoà vốn Số lượng và chất lượng các dự án khác
111/Chapter
© DHBK 2007
3.2 Quản lý dự án 3.2.1 Giới thiệu 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
112/Chapter
© DHBK 2007
3.2.1 Giới thiệu • 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.
113/Chapter
© DHBK 2007
3.2.2 Xác định kích thước dự án • 3 nhân tố phụ thuộc lẫn nhau: Kích thước hệ thống Thời gian hoàn thành dự án Chi phí của dự án
• 2 phương pháp ước lượng kích thước dự án Phương pháp đơn giản dựa trên chuẩn công nghiệp Phương pháp điểm chức năng (function point approach)
114/Chapter
© DHBK 2007
3.2.2 Xác định kích thước dự án • Phương pháp đơn giản dựa trên chuẩn công nghiệp Planning Industry Standard For Web Applications
Time Required in Person Months
Analysis
15%
4
Design
20%
5.33
9.33
Implementation
35%
8
30%
115/Chapter
© DHBK 2007
3.2.2 Xác định kích thước dự án • Phương pháp điểm chức năng
116/Chapter
© DHBK 2007
3.2.2 Xác định kích thước dự án • Phương pháp điểm chức năng Xác định kích thước hệ thống theo điểm chức năng và số dòng lệnh 1 điểm chức năng là đơn vị đo kích thước chương trình dựa trên số lượng và độ phức tạp của đầu vào, đầu ra, truy vấn, files và giao diện chương trình Tính toán số điểm chức năng Liệt kê các thành phần cơ bản của chương trình Xác định số lượng mỗi thành phần Xác định đô phức tạp của mỗi thành phần (low, med., high) Tính tổng số điểm chức năng (TUFP)
117/Chapter
© DHBK 2007
3.2.2 Xác định kích thước dự án 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 Interfaces
__x 5
__x 7
__x 10
____
TOTAL UNADJUSTED FUNCTION POINTS ____
118/Chapter
© DHBK 2007
3.2.2 Xác định kích thước dự án Tính toán số điểm chức năng-Ví dụ:
119/Chapter
© DHBK 2007
3.2.2 Xác định kích thước dự án Tính độ phức tạp xử lý hiệu chỉnh (adjusted processing complexity)-Bước 2
120/Chapter
© DHBK 2007
3.2.2 Xác định kích thước dự án 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
121/Chapter
© DHBK 2007
3.2.2 Xác định kích thước dự án 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)
122/Chapter
© DHBK 2007
3.2.2 Xác định kích thước dự án Tính số dòng lệnh= LOC/Function Code Point x TAFP Language
LOC/Function Code Point
C COBOL JAVA C++ Turbo Pascal Visual Basic PowerBuilder HTML Packages (e.g., Access, Excel)
130 110 55 50 50 30 15 15 10-40
Ví dụ: lập trình dùng C: số dòng lệnh = 243x 130 = 31 590 dòng
123/Chapter
© DHBK 2007
3.2.2 Xác định kích thước dự án • Phương pháp điểm chức năng Xác định kích thước hệ thống theo điểm chức năng và số dòng lệnh Ước lượng nhân lực (person-months) Mô hình: COSOMO
Effort (in PersonMonths)
=
1.4 * thousands-oflines-of-code
Example: If LOC = 20000 Then... Effort = (1.4 * 20)
=
28 Person
124/Chapter
© DHBK 2007
3.2.2 Xác định kích thước dự án • Phương pháp điểm chức năng Xác định kích thước hệ thống theo điểm chức năng và 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
© DHBK 2007
• • • • •
125/Chapter
3.2.3 Xây dựng và quản lý kế hoạch công việc
Xác định các công việc của dự án Ước lượng thời gian thực hiện mỗi công việc Xác định sự phụ thuộc giữa các công việc Xác định ai sẽ làm công việc gì Liệt kê các kết quả đạt được của mỗi công việc ( deliverables): ví dụ: báo cáo, bản thiết kế, phương án thực hiện ...
© DHBK 2007
•
126/Chapter
3.2.3 Xây dựng và quản lý kế hoạch công việc
Ví dụ về một bản kế hoạch công việc: Work Plan Information
Example
Name of task Start date Completion date Person assigned Deliverable(s) Completion status Priority Resources needed Estimated time Actual time
Perform economic feasibility Jan 05, 2001 Jan 19, 2001 Mary Smith, sponsor Cost-benefit analysis Open High Spreadsheet 16 hours 14.5 hours
`
© DHBK 2007
•
127/Chapter
3.2.3 Xây dựng và quản lý kế hoạch công việc
Xác định các công việc của dự án: 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
© DHBK 2007
•
128/Chapter
3.2.3 Xây dựng và quản lý kế hoạch công việc
Xác định các công việc của dự án dùng phương pháp Top-down Phases
Work Plan * * * *
Deliverables
Phases with high level steps
Estimated duration
Assigned To
© DHBK 2007
•
129/Chapter
3.2.3 Xây dựng và quản lý kế hoạch công việc
Xác định các công việc của dự án 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
© DHBK 2007
130/Chapter
3.2.3 Xây dựng và quản lý kế hoạch công việc
© DHBK 2007
131/Chapter
3.2.3 Xây dựng và quản lý kế hoạch công việc
• Biểu đồ Gantt (Gantt Chart): là 1 cách biểu diễn kế hoạch công việc dựa trên WBS
© DHBK 2007
132/Chapter
3.2.3 Xây dựng và quản lý kế hoạch công việc
• Biểu đồ PERT (PERT= Project Evaluation and Review Technique ) Là cách biểu diễn khác của kế hoạch công việc Cách tốt nhất để biểu diễn sự phụ thuộc giữa các công việc và để xác định các pha then chốt PERT sử dụng 3 loại giá trị ước lượng thời gian thực hiện công việc: Lạc quan: O Khả năng cao: M (most likely) Bi quan: P
Thời gian ước lượng = (O + 4 * M + P)/6
© DHBK 2007
133/Chapter
3.2.3 Xây dựng và quản lý kế hoạch công việc
• Biểu đồ PERT
X: Hoàn thành \: đang thực hiện
© DHBK 2007
134/Chapter
3.2.4 Sắp xếp nhân lực cho dự án • Xác định số người cho dự án • Xây dựng kế hoạch nhân 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
135/Chapter
© DHBK 2007
3.2.4 Sắp xếp nhân lực cho dự án Ví dụ về cơ cấu tổ chức của dự án
136/Chapter
© DHBK 2007
3.2.4 Sắp xếp nhân lực cho 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?
137/Chapter
© DHBK 2007
3.2.4 Sắp xếp nhân lực cho dự án • Khích lệ động viên các thành viên trong nhóm: Sử dụng tiền thưởng một cách hết sức cẩn trọng Sử dụng các khích lệ tinh thần: Công việc hấp dẫn, thách thức Tinh thần trách nhiệm Nhu cầu tiến thủ Cơ hội để học kỹ năng mới Nhu cầu tự khẳng định mình Sự thành cônng
138/Chapter
© DHBK 2007
3.2.4 Sắp xếp nhân lực cho dự án • Chiến lược để giải quyết xung đột: Xác định rõ ràng công việc của từng thành viên trong nhóm Lập bảng quy định, nội quy của nhóm Dự đoán các ưu tiên khác và khả năng ảnh hưởng của chúng tới dự án
© DHBK 2007
139/Chapter
3.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 (computeraided 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
140/Chapter
© DHBK 2007
3.2.5 Điều phối hoạt động dự án • Tinh chỉnh các giá trị ước lượng Typical margins of Error for Phase time (%)
Deliverable
Planning
System Request Project Plan
Analysis 15 Design
Well-done Estimates Cost (%) 400 100
60 25
System Proposal
50
System Specification 25
10
141/Chapter
© DHBK 2007
3.2.5 Điều phối hoạt động dự án • Quản lý phạm vi dự án (scope management) Scope creep: hiện tượng dự án có nguy cơ kéo dài và tốn chi phí hơn dự kiến Nguyên nhân: thêm yêu cầu mới cho hệ thống sau khi phạm vi của hệ thống đã được giới hạn Biện pháp khắc phục: Cách 1: tăng cường gặp gỡ trao đổi với người sử dụng và xây dựng nguyên mẫu để tăng tốc việc định rõ các yêu cầu -> giảm được 5% nguy cơ Cách 2: sử dụng kỹ thuật hộp thời gian (timeboxing)
142/Chapter
© DHBK 2007
3.2.5 Điều phối hoạt động dự án • Timeboxing Steps 1. Set the date for system delivery. 2. Prioritize the functionality that needs to be included in the system. 3. Build the core of the system (the functionality ranked as most important). 4. Postpone functionality that cannot be provided within the time frame. 5. Deliver the system with core functionality. 6. Repeat steps 3 through 5, to add refinements and enhancements.
143/Chapter
© DHBK 2007
3.2.5 Điều phối hoạt động dự án • Điều phối hoạt động của dự án: CASE (computer-aided software engineering) tool – Software that automates all of part of the development process Initiation
Analysis
Upper CASE
Design
Implementation
Lower CASE
Integrated CASE (I-CASE)
144/Chapter
© DHBK 2007
3.2.5 Điều phối hoạt động dự án • Điều phối hoạt động của dự án: • Standardisation: Examples Formal rules for naming files Forms indicating goals reached Programming guidelines and Coding standard • Documentation Project binder: all deliverables and all the internal communications within a project Table of contents Continual updating
145/Chapter
© DHBK 2007
3.2.5 Điều phối hoạt động dự án • Quản lý rủi ro: Risk assessment: a document assesses a potential risk including: Risk No and its brief description Likelihood of risk Potential impact on the project Ways to address the risk
Actions to reduce risk Revised assessment
146/Chapter
© DHBK 2007
3.2.5 Điều phối hoạt động dự án • Quản lý rủi ro: Avoiding Classic Planning Mistakes Overly optimistic schedule Failing to monitor schedule Failing to update schedule Adding people to a late project
147/Chapter
© DHBK 2007
3.2.6 CD selections
148/Chapter
© DHBK 2007
Chương 4. Phân tích hệ thống 4.1 Xác định yêu cầu của hệ thống 4.2 Mô hình hoá chức năng 4.3 Mô hình hoá cấu trúc 4.4 Mô hình hoá hoạt động
149/Chapter
© DHBK 2007
Chương 4. Phân tích hệ thống
Định nghĩa yêu cầu của hệ thống
Mô hình chức năng
Yêu cầu hệ thống (system request)
Mô hình cấu trúc
Hội đồng duyệt dự án Yes Thiết kế hệ thống
Mô hình hoạt động Phân tích khả thi Kế hoạch công việc
+ system proposal
150/Chapter
© DHBK 2007
4.1 Xác định yêu cầu của hệ thống 4.1.1 Xác định yêu cầu 4.1.2 Các kỹ thuật phân tích yêu cầu 4.1.3 Các kỹ thuật thu thập yêu cầu 4.1.4 CD selections
151/Chapter
© DHBK 2007
4.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ăng Khả năng hoạt động An ninh yêu cầu về văn hoá, chính trị Yêu cầu không chức năng được dùng chủ yếu tại bước thiết kế hệ thống
152/Chapter
© DHBK 2007
4.1.1 Xác định yêu cầu • Tài liệu định nghĩa yêu cầu (requirement definition): Là văn bản liệt kê các yêu cầu chức năng và yêu cầu không chức năng Cung cấp đầu vào cho các bước tiếp theo trong quá trình phân tích hệ thống cũng như quá trình thiết kế Mục đích quan trọng nhất của tài liệu định nghĩa yêu cầu là định nghĩa phạm vi của hệ thống
153/Chapter
© DHBK 2007
4.1.1 Xác định yêu cầu • Xây dựng tài liệu định nghĩa yêu cầu Xác định các loại yêu cầu chức năng và không chức năng Sử dụng các kỹ thuật thu thập yêu cầu để thu thập thông tin Sử dụng các kỹ thuật phân tích yêu cầu để kiểm tra, thay đổi và hoàn thiện các yêu cầu thu thập được và xác định mức độ quan trọng của các yêu cầu
154/Chapter
© DHBK 2007
4.1.1 Xác định yêu cầu
155/Chapter
© DHBK 2007
4.1.1 Xác định yêu cầu
156/Chapter
© DHBK 2007
4.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: Business process automation (BPA): tự động hoá quá trình kinh doanh Business process improvement (BPI): cải tiến quá trình kinh doanh Business process reengineering (BPE)
•
3 bước trong quá trình phân tích yêu cầu: Phân tích tình trạng của hệ thống hiện tại Xác định chính xác những cải tiến có thể thực hiện Xây dựng yêu cầu của hệ thống cần xây dựng
© DHBK 2007
157/Chapter
4.1.2 Các kỹ thuật phân tích yêu cầu •
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 đề
© DHBK 2007
158/Chapter
4.1.2 Các kỹ thuật phân tích yêu cầu •
Business process improvement (BPI): cải tiến quá trình kinh doanh
Làm thay đổi hoạt động 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
159/Chapter
© DHBK 2007
4.1.2 Các kỹ thuật phân tích yêu cầu •
Business process reengineering (BPR): thay đổi quá trình kinh doanh Làm thay đổi 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ỏ đó
160/Chapter
© DHBK 2007
4.1.2 Các kỹ thuật phân tích yêu cầu •
Lựa chọn kỹ thuật thích hợp, phụ thuộc vào:
Giá trị kinh doanh tiềm 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
161/Chapter
© DHBK 2007
4.1.2 Các kỹ thuật phân tích yêu cầu •
Lựa chọn kỹ thuật thích hợp
© DHBK 2007
162/Chapter
4.1.3 Các kỹ thuật thu thập yêu cầu • • • • •
Phỏng vấn (Interviews) Kết hợp phát triển ứng dụng (Joint Application Development (JAD)) Điều tra (Questionnaires) Phân tích tài liệu (Document analysis) Quan sát (Observation)
163/Chapter
© DHBK 2007
4.1.3 Các kỹ thuật thu thập yêu cầu •
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
164/Chapter
© DHBK 2007
4.1.3 Các kỹ thuật thu thập yêu cầu •
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)
165/Chapter
© DHBK 2007
4.1.3 Các kỹ thuật thu thập yêu cầu •
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)
166/Chapter
© DHBK 2007
4.1.3 Các kỹ thuật thu thập yêu cầu •
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 How many telephone orders are received per day? * How do customers place orders? * What additional information would you like the new system to provide?
Closed-Ended Questions
*
Open-Ended Questions
* * *
Probing Questions
*
* *
What do you think about the current system? What are some of the problems you face on a daily basis? How do you decide what types of marketing campaign to run? Why? Can you give me an example? Can you explain that in a bit more detail?
167/Chapter
© DHBK 2007
4.1.3 Các kỹ thuật thu thập yêu cầu •
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
© DHBK 2007
168/Chapter
4.1.3 Các kỹ thuật thu thập yêu cầu •
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
169/Chapter
© DHBK 2007
4.1.3 Các kỹ thuật thu thập yêu cầu •
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
© DHBK 2007
170/Chapter
4.1.3 Các kỹ thuật thu thập yêu cầu •
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ờ
171/Chapter
© DHBK 2007
4.1.3 Các kỹ thuật thu thập yêu cầu •
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
© DHBK 2007
172/Chapter
4.1.3 Các kỹ thuật thu thập yêu cầu •
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
173/Chapter
© DHBK 2007
4.1.3 Các kỹ thuật thu thập yêu cầu •
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:
© DHBK 2007
174/Chapter
4.1.3 Các kỹ thuật thu thập yêu cầu •
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
175/Chapter
© DHBK 2007
4.1.3 Các kỹ thuật thu thập yêu cầu •
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
176/Chapter
© DHBK 2007
4.1.3 Các kỹ thuật thu thập yêu cầu •
JAD: Thiết lập cuộc họp
U-Shaped seating Away from distractions Whiteboard/flip chart Prototyping tools e-JAD
177/Chapter
© DHBK 2007
4.1.3 Các kỹ thuật thu thập yêu cầu •
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
178/Chapter
© DHBK 2007
4.1.3 Các kỹ thuật thu thập yêu cầu •
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
179/Chapter
© DHBK 2007
4.1.3 Các kỹ thuật thu thập yêu cầu •
JAD: Phòng họp
180/Chapter
© DHBK 2007
4.1.3 Các kỹ thuật thu thập yêu cầu •
Đ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
181/Chapter
© DHBK 2007
4.1.3 Các kỹ thuật thu thập yêu cầu •
Đ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.
182/Chapter
© DHBK 2007
4.1.3 Các kỹ thuật thu thập yêu cầu •
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
183/Chapter
© DHBK 2007
4.1.3 Các kỹ thuật thu thập yêu cầu •
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
184/Chapter
© DHBK 2007
4.1.3 Các kỹ thuật thu thập yêu cầu •
Lựa chọn kỹ thuật thích hợp:
185/Chapter
© DHBK 2007
4.1.4 CD selections Requirement Determination • Requirement Analysis Techniques Select BPI techniques to identify how to improve the current order process using a new web-based system Using several JAD session including store managers, marketing analysts and Wed developers (the working group) to work through BPI techniques and brainstorm Further apply informal benchmarking with Web-sites of several leading retailers and discuss with the working group The output is a list of suggested business requirements for the project team
186/Chapter
© DHBK 2007
4.1.4 CD selections Requirement Determination • Requirement-gathering Techniques The project team applies document analysis, interview and observation techniques Firstly apply document analysis to understand the current order processes (i.e., the as-is system). If anything is not clear, use interview to clarify Secondly interview senior analysts to get better ideas about as-is and to-be systems and IT contractor to understand the existing IT system Thirdly observe in stores to see the real working process of as-is system
• The above activities at the end produces the requirement definition (report) • Further JAD sessions are used to finalise and prioritise the requirement definition (report)
© DHBK 2007
4.2 Mô hình hoá chức năng (Functional Modeling)
187/Chapter
4.2.1 Giới thiệu 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
188/Chapter
© DHBK 2007
4.2.1 Giới thiệu • 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)
© DHBK 2007
189/Chapter
4.2.2 Mô hình quá trình kinh doanh bằng biểu đồ hoạt động (activity diagrams)
• Các phần tử của biểu đồ hoạt động • Xây dựng biểu đồ hoạt động
© DHBK 2007
190/Chapter
4.2.2 Mô hình quá trình kinh doanh bằng biểu đồ hoạt động (activity diagrams)
• Biểu đồ hoạt động được dùng để mô hình hoá các quá trình kinh doanh ở mức cao (high level business process) • Các phần tử của biểu đồ hoạt động Hành động (action) Là phần tử đơn giản biểu diễn một hoạt động không thể chia nhỏ hơn Tên: Động từ + danh từ, ví dụ: Make appointment
Hoạt động (activity) Dùng để biểu diễn tập hợp các hành động
Make appointment
Nốt đối tượng (object node) Biểu diễn một đối tượng được kết nối với các luồng đối tượng Tên của nốt đối tượng là tên lớp của đối tượng Class name
Luồng điều khiển (control flow) Biểu diễn chuỗi hoạt động
© DHBK 2007
191/Chapter
4.2.2 Mô hình quá trình kinh doanh bằng biểu đồ hoạt động (activity diagrams)
• Các phần tử của biểu đồ hoạt động (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
© DHBK 2007
192/Chapter
4.2.2 Mô hình quá trình kinh doanh bằng biểu đồ hoạt động (activity diagrams)
• Các phần tử của biểu đồ hoạt động (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
[điều kiện]
[điều kiện]
Nốt gộp (merge node) Dùng để gộp các nhánh đựơc tạo ra bởi nốt lựa chọn
© DHBK 2007
193/Chapter
4.2.2 Mô hình quá trình kinh doanh bằng biểu đồ hoạt động (activity diagrams)
• Các phần tử của biểu đồ hoạt động (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
© DHBK 2007
194/Chapter
4.2.2 Mô hình quá trình kinh doanh bằng biểu đồ hoạt động (activity diagrams)
© DHBK 2007
•
195/Chapter
4.2.2 Mô hình quá trình kinh doanh bằng biểu đồ hoạt động (activity diagrams)
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
© DHBK 2007
•
196/Chapter
4.2.2 Mô hình quá trình kinh doanh bằng biểu đồ hoạt động (activity diagrams) VD: CD selections
Internet Order System – Functional requirements: 2. Maintain CD Information 1.1…… 1.2….. 1.3…..
3. Maintain CD marketing information 2.1…. 2.2…. 2.3….
4. Place CD Orders 3.1 Search CDs from “CD Selection” web site; 3.2 Place orders; 3.3……
5. Maintain Orders 4.1….. 4.2… 4.3 Place Instore Hold: If ordered CDs are available in a near store, the CDs are on hold and to be picked up in the store 4.4. Place Special Order: If ordered CDs is not available in a near store, the ordered CDs will be sent to a near store and email to the customer when it is available in the near store
© DHBK 2007
•
197/Chapter
4.2.2 Mô hình quá trình kinh doanh bằng biểu đồ hoạt động (activity diagrams)
VD: CD selections Exercise: Create the activity diagram for Internet Order System Analysis: Main activities: Maintain CD Information, Maintain CD marketing information, Place CD Orders, Maintain ordered CDs Control flows: Three main parallel processes: Maintain CD Information Maintain CD marketing information Place CD Orders -> Maintain ordered CDs in which a decision needs to be made related to placing instore hold or placing special order
© DHBK 2007
•
198/Chapter
4.2.2 Mô hình quá trình kinh doanh bằng biểu đồ hoạt động (activity diagrams)
VD: CD selections
Maintain CD marketing information
Place CD Order [If available in near store] Place instore hold
[If not] Place special order
Maintain CD Information
199/Chapter
© DHBK 2007
4.2.3 Mô tả ca sử dụng • Một ca sử dụng miêu tả các hoạt động do người sử dụng hoặc các hệ thống khác tác động lên hệ thống. • Ca sử dụng là mô hình logic vì chúng miêu tả các hoạt động của hệ thống mà không miêu tả các hoạt động đó được thực hiện thế nào. • Ca sử dụng miêu tả chức năng của hệ thống: Người sử dụng có thể làm gì Hệ thống đáp ứng như thế nào Ca sử dụng miêu tả tương tác giữa người sử dụng và hệ thống
• Ca sử dụng có thể được dùng để mô tả hệ thống hiện tại và hệ thống cần xây dựng
200/Chapter
© DHBK 2007
4.2.3 Mô tả ca sử dụng • 2 bước để xây dựng biểu đồ ca sử dụng Viết bản mô tả ca sử dụng Chuyển từ bản mô tả ca sử dụng sang biểu đồ ca sử dụng
• Mỗi một ca sử dụng chỉ miêu tả duy nhất một chức năng của hệ thống • Để xác định nội dung của ca sử dụng, người phát triển hệ thống phải làm việc cùng với người sử dụng
201/Chapter
© DHBK 2007
4.2.3 Mô tả ca sử dụng • Các thành phần của bản mô tả ca sử dụng: Use Case Name: Level: Primary Actor:
ID:
Importance
Use Case Type:
Stakeholders and Interests: Brief Description: Trigger: Relationships: (Association, Include, Extend, Generalization) Normal Flow of Events: Subflows:
202/Chapter
© DHBK 2007
4.2.3 Mô tả ca sử dụng • Ví dụ:
203/Chapter
© DHBK 2007
4.2.3 Mô tả ca sử dụng • Ví dụ:
204/Chapter
© DHBK 2007
4.2.3 Mô tả ca sử dụng • Ví dụ:
205/Chapter
© DHBK 2007
4.2.3 Mô tả ca sử dụng •
Guidelines for Creating Use-Case Descriptions 1. Write each step in “SVDPI (subject-verb-direct object and optionally preposition-indirect object)” form Example. “The patient (subject) contacts (verb) the office (direct object) regarding (preposition) an appointment (indirect object). 2. Clarify initiator and receivers of action 3. Write from independent observer perspective 4. Write at same level of abstraction 5. Ensure a sensible set of steps 6. Apply KISS (keep it simple, stupid) principle liberally 7. Write repeating instructions after the set of steps to be repeated.
206/Chapter
© DHBK 2007
4.2.4 Biểu đồ ca sử dụng A Subject Boundary
An Actor An associate relationship A use case
207/Chapter
© DHBK 2007
4.2.4 Biểu đồ ca sử dụng
208/Chapter
© DHBK 2007
4.2.4 Biểu đồ ca sử dụng
209/Chapter
© DHBK 2007
4.2.4 Biểu đồ ca sử dụng
210/Chapter
© DHBK 2007
4.2.4 Biểu đồ ca sử dụng
© DHBK 2007
211/Chapter
4.2.5 Xây dựng mô tả ca sử dụng và Biểu đồ ca sử dụng
• 4 bước chính: Bước I. Xác định các ca sử dụng chính Bước II. Mở rộng ca sử dụng chính Bước III. Khẳng định lại các ca sử dụng chính Bước IV. Vẽ biểu đồ ca sử dụng
© DHBK 2007
•
212/Chapter
4.2.5 Xây dựng mô tả ca sử dụng và Biểu đồ ca sử dụng
Bước I (5 bước nhỏ): Xác định các ca sử dụng chính 1. Xem lại biểu đồ hoạt động 2. Xác định phạm vi của hệ thống 3. Liệt kê các tác nhân chính (primary actors) và mục đích của các tác nhân đó 4. Xác định và viết các ca sử dụng chính 5. Xem xét lại cẩn thận các ca sử dụng và sửa đổi nếu cần
© DHBK 2007
•
213/Chapter
4.2.5 Xây dựng mô tả ca sử dụng và Biểu đồ ca sử dụng
Bước I: Ví dụ Review activity diagram of Internet order System:
Place CD Order
Maintain CD Order
Maintain CD marketing information
Maintain CD Information
© DHBK 2007
•
214/Chapter
4.2.5 Xây dựng mô tả ca sử dụng và Biểu đồ ca sử dụng
Bước I: Ví dụ
Identify and write the major (overview) use-cases Use case name
Primary actor
Relationship Association
Maintain marketing information
Vendor
Vendor
Maintain CD information
Distribution system
Distribution system
Place order
Customer
Customer
Maintain order
Customer
Include
Maintain order
Exclude
© DHBK 2007
•
215/Chapter
4.2.5 Xây dựng mô tả ca sử dụng và Biểu đồ ca sử dụng
Bước II (5 bước nhỏ): Mở rộng ca sử dụng chính Chọn 1 ca sử dụng chính để mở rộng Điền các chi tiết vào form Điền các bước của luồng sự kiện bình thường (normal
flow of events) 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)
Miêu tả các bước thay thế hoặc ngoại lệ (alternate/exceptional) 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
© DHBK 2007
•
216/Chapter
4.2.5 Xây dựng mô tả ca sử dụng và Biểu đồ ca sử dụng
Bước II: Ví dụ: kết quả sau bước 7
© DHBK 2007
•
217/Chapter
4.2.5 Xây dựng mô tả ca sử dụng và Biểu đồ ca sử dụng
Bước II: Ví dụ: kết quả sau bước 8
© DHBK 2007
•
218/Chapter
4.2.5 Xây dựng mô tả ca sử dụng và Biểu đồ ca sử dụng
Bước II: Ví dụ: kết quả sau bước 11
© DHBK 2007
•
219/Chapter
4.2.5 Xây dựng mô tả ca sử dụng và Biểu đồ ca sử dụng
Bước II: Ví dụ: kết quả sau bước 11
© DHBK 2007
•
220/Chapter
4.2.5 Xây dựng mô tả ca sử dụng và Biểu đồ ca sử dụng
Bước III (2 bước nhỏ): Khẳng định lại các ca sử dụng chính 1. 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
2. Lặp lại 12 bước cho đến khi tất cả các ca sử dụng được xác định
© DHBK 2007
•
221/Chapter
4.2.5 Xây dựng mô tả ca sử dụng và Biểu đồ ca sử dụng
Bước IV (4 bước nhỏ): Vẽ biểu đồ ca sử dụng 1. 2. 3. 4.
Vẽ gianh giới của hệ thống Vẽ các ca sử dụng (vẽ theo thứ tự dễ nhìn) Vẽ các tác nhân Vẽ các quan hệ
© DHBK 2007
222/Chapter
Exercise: Draw use-case diagram Question. Suppose that 7 major use cases have been identified as below, draw the corresponding use-case diagram
Use case name
Primary actor
Relationship Association
Include
Maintain marketing information
Vendor
Vendor
Maintain CD information
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
Customer
Store
Place special order
Customer
Store
Extend
Place Instore hold Place special order
223/Chapter
© DHBK 2007
Maintain CD marketing information <
<
Credit Card Centre
Place CD order
Check out <
<
Distribution System
Maintain CD information
<
Store
224/Chapter
© DHBK 2007
4.3 Mô hình hoá cấu trúc 4.3.1 Giới thiệu 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
225/Chapter
© DHBK 2007
4.3.1 Giới thiệu 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.
226/Chapter
© DHBK 2007
4.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ọng Các thuộc tính phải có kiểu cơ bản: nguyên, xâu, ngày, tháng, boolean …. Các thuộc tính phức tạp đựơc biểu diễn bằng quan hệ (relationship) giữa các lớp
227/Chapter
© DHBK 2007
4.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
© DHBK 2007
228/Chapter
4.3.3 Thẻ CRC (Class-ResponsibilityCollaboration)
• Trách nhiệm (responsibility) và hợp tác (collaboration) Trách nhiệm Đối tượng của một lớp phải có trách nhiệm: biết giá trị các thuộc tính và các quan hệ của nó thực hiện hoạt động của nó
Hợp tác Các đối tượng hợp tác với nhau để thực hiện một công việc Mô hình Client-server-contract
• Thẻ CRC được dùng để miêu tả các phần tử cơ bản của một lớp
© DHBK 2007
229/Chapter
4.3.3 Thẻ CRC (Class-ResponsibilityCollaboration)
© DHBK 2007
230/Chapter
4.3.3 Thẻ CRC (Class-ResponsibilityCollaboration)
231/Chapter
© DHBK 2007
4.3.4 Biểu đồ lớp
232/Chapter
© DHBK 2007
4.3.4 Biểu đồ lớp • Cú pháp: A CLASS
Class 1 -attribute +operation ()
AN ATTRIBUTE AN OPERATION AN ASSOCIATION
Attribute name/ derived attribute name operation name () 1..* 0..1 ______verb phrase____
233/Chapter
© DHBK 2007
4.3.4 Biểu đồ lớp • Thuộc tính: Derived attributes /age, for example can be calculated from birth date and current date
Visibility Public: Protected: Private:
+ # -
234/Chapter
© DHBK 2007
4.3.4 Biểu đồ lớp • Hoạt động (operations): Constructor Creates object
Query Makes information about state available
Update Changes values of some or all attributes
235/Chapter
© DHBK 2007
4.3.4 Biểu đồ lớp • Quan hệ: Multiplicity of relationship exactly one: zero or more: one or more: zero or one: specified range: multiple disjoint ranges:
1 0..* 1..* 0..1 2..4 1..5,7
236/Chapter
© DHBK 2007
4.3.4 Biểu đồ lớp • Biểu đồ đối tượng: cụ thể hóa biểu đồ lớp
237/Chapter
© DHBK 2007
4.3.5 Xây dựng thẻ CRC và biểu đồ lớp Three common approaches 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
3. Common object list Physical or tangible things Incidents Roles
4. Patterns Useful groupings of classes that occur in various situations
© DHBK 2007
238/Chapter
4.3.5 Xây dựng thẻ CRC và biểu đồ lớp • • • • • • •
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.
239/Chapter
© DHBK 2007
4.3.5 Xây dựng thẻ CRC và biểu đồ lớp
CD Selections
240/Chapter
© DHBK 2007
Step 1. Create CRC cards by performing textual analysis on the use-cases Textual Analysis: Nouns suggest classes
241/Chapter
© DHBK 2007
Step 1. Create CRC cards by performing textual analysis on the use-cases Textual Analysis: Nouns suggest classes • Textual Analysis Results: Identified potential classes Customer Search Request CD CD List Review (i.e., CD review information) If further analyse the Maintain Order and Checkout use cases, further potential classes will be identified such as Order Order Item Credit card centre etc
242/Chapter
© DHBK 2007
Step 1. Create CRC cards by performing textual analysis on the use-cases 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
243/Chapter
© DHBK 2007
Step 1. Create CRC cards by performing textual analysis on the use-cases Textual Analysis: Verbs suggest operations: •
Textual Analysis Result: For Customer Class, the identified operations (i.e., Responsibilities) and the relationship with other classes (i.e., Collaborators) are
Make Search request Place Order Get Credit Card
Search request Order Credit Card Centre
Info Exit Select CD for Info
CD List Not include as it can be included in Search request
This forms the front of “Customer class” CRC Card
244/Chapter
© DHBK 2007
Step 1. Create CRC cards by performing textual analysis on the use-cases •
Textual Analysis Result: Combine “nouns and verbs” analysis, the back of “Customer class” CRC Card can be
Order; Search request; Credit Card Centre
© DHBK 2007
245/Chapter
Step 2 and 3. Examine Common Object Lists and Role-play the CRC Cards
1. Brainstorm additional candidate classes, attributes, operations, and relationships by using the common object list approach. 2. 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
© DHBK 2007
246/Chapter
Step 4. Create the Class Diagram based on the CRC Cards
• Exercise. Suppose the CRC card of Customer class is given as before, create the class diagram based on it. • For customer class, assume that all attributes are private type whereas all operations are public type • For other associate classes, only the class names and the relationships with the customer class need to be given
© DHBK 2007
247/Chapter
Step 4. Create the Class Diagram based on the CRC Cards
• Solution: Credit Card Centre
Order Customer
0..* Check ->
0..*
-First name -Middle initial -Last name -…… +Make search req() +Place order() +Get credit info() +Exit() 0..*
1
0..*
place ->
Make ->
Search Reg 0..*
248/Chapter
© DHBK 2007
Step 5, 6 and 7: Review Classes Diagrams, Incorporate Patterns, and Review the Model 1. Review the class diagrams and structural model for any missing and/or redundancy 2. Incorporate useful patterns. • One possible pattern
3. Review the structural model.
249/Chapter
© DHBK 2007
4.4 Mô hình hoá hoạt động 4.4.1 Giới thiệu 4.4.2 Biểu đồ tương tác 4.4.3 Biểu đồ máy trạng thái
250/Chapter
© DHBK 2007
4.4.1 Giới thiệu • 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)
251/Chapter
© DHBK 2007
4.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
252/Chapter
© DHBK 2007
4.4.2 Biểu đồ tương tác • Biểu đồ tuần tự (sequence diagram) Miêu tả các đối tượng tham gia vào 1 ca sử dụng Biểu diễn các thông điệp được truyền giữa các đối tượng trong 1 ca sử dụng
253/Chapter
© DHBK 2007
4.4.2 Biểu đồ tương tác • Biểu đồ tuần tự (sequence diagram): ví dụ
254/Chapter
© DHBK 2007
4.4.2 Biểu đồ tương tác • Biểu đồ tuần tự (sequence diagram): Các phần tử
255/Chapter
© DHBK 2007
4.4.2 Biểu đồ tương tác • Biểu đồ tuần tự (sequence diagram): Các phần tử
256/Chapter
© DHBK 2007
4.4.2 Biểu đồ tương tác •
6 bước xây dựng biểu đồ tuần tự Xác định ngữ cảnh của biểu đồ tuần tự Xác định các đối tượng tham gia Xác định đường sống (lifeline) cho mỗi đối tượng Biểu diễn các thông điệp 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 Kiểm tra lại biểu đồ
Application Example:
© DHBK 2007
Normal Flow of Events: 1. Customer submits a search request to the system. 2. The system provides the customer a list of recommended CDs. 3. The customer chooses one of the CDs to find additional information. 4. The system provides the customer with basic (market) information & CD Reviews 5. The customer calls the maintain order use case. 6. The customer iterates over 3 through 5 until finished shopping. 7. The customer executes the checkout use case. 8. The customer leaves the website.
257/Chapter
Application Example:
© DHBK 2007
258/Chapter
259/Chapter
© DHBK 2007
4.4.2 Biểu đồ tương tác • 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
260/Chapter
© DHBK 2007
4.4.2 Biểu đồ tương tác • Biểu đồ giao tiếp : Ví dụ
261/Chapter
© DHBK 2007
4.4.2 Biểu đồ tương tác • Biểu đồ giao tiếp : Các phần tử Actor Object Association Message
262/Chapter
© DHBK 2007
4.4.2 Biểu đồ tương tác •
5 bước xây dựng biểu đồ giao tiếp 1. 2. 3. 4. 5.
Xác định ngữ cảnh Xác định các đối tượng và các liên kết giữa các đối tượng 2 Vẽ các đối tượng và liên kết Thêm các thông điệp Kiểm tra lại biểu đồ giao tiếp
© DHBK 2007
•
263/Chapter
Technique to Identify Collaborations between Objects - “CRUD” Analysis
What is “CRUD” analysis: identifying the processes to Create, Read or Reference, Update or Delete objects based on use cases The process of each user case is represented by “CRUD” matrix: a classby-class matrix in which each cell in the matrix represents the interaction between instances of the classes
264/Chapter
© DHBK 2007
“CRUD” Analysis Example
C C
Application Example:
© DHBK 2007
Normal Flow of Events: 1. Customer submits a search request to the system. 2. The system provides the customer a list of recommended CDs. 3. The customer chooses one of the CDs to find additional information. 4. The system provides the customer with basic (market) information & CD Reviews 5. The customer calls the maintain order use case. 6. The customer iterates over 3 through 5 until finished shopping. 7. The customer executes the checkout use case. 8. The customer leaves the website.
265/Chapter
Application Example:
© DHBK 2007
266/Chapter
267/Chapter
© DHBK 2007
4.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.
268/Chapter
© DHBK 2007
4.4.3 Biểu đồ máy trạng thái Ví dụ:
269/Chapter
© DHBK 2007
4.4.3 Biểu đồ máy trạng thái Các phần tử của biều đồ máy trạng thái:
270/Chapter
© DHBK 2007
4.4.3 Biểu đồ máy trạng thái Các phần tử của biều đồ máy trạng thái: •
Transitions: A transition indicates a movement from one state to the next one, denoted by lines with arrowheads. A transition has a label in the form of three parts: Event [guard]/activity. All three parts are optional. Event or Trigger: the signal event that triggers a potential change of state Guard: If presented, is a Boolean condition that must be true in order for the trigger to cause the transition Action or Activity: is some behaviour that has executed during the transition
state
Event [guard]/activity transition
271/Chapter
© DHBK 2007
4.4.3 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
Application Example:
© DHBK 2007
The Life of an Order Object:
272/Chapter
Application Example:
© DHBK 2007
273/Chapter
274/Chapter
© DHBK 2007
Chương 5. Thiết kế hệ thống 5.1 Chuyển sang thiết kế 5.2 Thiết kế lớp và phương thức 5.3 Thiết kế lớp quản lý dữ liệu 5.4 Thiết kế lớp tương tác người-máy 5.5 Thiết kế lớp kiến trúc vật lý
275/Chapter
© DHBK 2007
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ế
© DHBK 2007
276/Chapter
5.1.1 Chuyển từ mô hình phân tích sang mô hình thiết kế
• Factoring: Creating modules* that reflect similarities and differences between units of interest Here, module = new class | new method New classes can be represented by:Generalization Aggregation New classes identified by: Abstraction e.g. classes for nurse, admin and doctor share attributes and methods, so “factor our” common attributes and methods, create new class “employee”, relate employee to nurse, admin and doctor classes as generalisation (a-kind-of) relationship – a form of abstraction Refinement Identifying additional subclasses (of a higher level class) is a form of refinement
© DHBK 2007
277/Chapter
5.1.1 Chuyển từ mô hình phân tích sang mô hình thiết kế
• Partitions and Collaborations Creating subsystems*, i.e. collections (usually sets) of related components In object-oriented designs/implementations the “pattern of activity”, i.e. messages sent between objects, provides one basis for partitioning system into (smaller-scale) subsystems (where subsystem = partition) Grouping units that collaborate e.g. as modelled in UML communications diagram (for each use-case), CRUD analysis, clients(i.e. objects that are message senders)-servers(i.e. objects that receivemessages) & contracts (i.e. specifications of interactions between objects) May have collaboration among units (e.g. a class) or partitions (i.e. collections/sets of classes whose objects send/receive messages) The more messages or contracts between objects, the more likely they are in the same partition
© DHBK 2007
278/Chapter
5.1.1 Chuyển từ mô hình phân tích sang mô hình thiết kế
• 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)
© DHBK 2007
•
Layers
279/Chapter
5.1.1 Chuyển từ mô hình phân tích sang mô hình thiết kế
280/Chapter
© DHBK 2007
5.1.2 Gói và biểu đồ gói Package = UML representation (or abstraction over) collaboration OR partition OR layer •Logical grouping of any UML elements
Simplifies (large numbers of) UML diagrams Groups related elements into a single higher-level element Packages involving different kinds of construct (e.g. at particular layers) use different kinds of relationship between those constructs, i.e. in a class diagram, package = group (or set) of classes by aggregation or association relationship
281/Chapter
© DHBK 2007
5.1.2 Gói và biểu đồ gói • 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.
282/Chapter
© DHBK 2007
5.1.2 Gói và biểu đồ gói
A PACKAGE
A DEPENDENCY RELATIONSHIP
Package
© DHBK 2007
5.1.2 Gói và biểu đồ gói Ví dụ
283/Chapter
284/Chapter
© DHBK 2007
5.1.2 Gói và biểu đồ gói Collaborations, partitions and layers Collaborations usually are modelled as packages in UML
Collaborations usually factored into a set of partitions on a layer
Partitions can be composed of other partitions (hierarchically hence forming subsystems) Classes can be in partitions, those partitions then contained in other partitions, placed on a layer Simple example:- small part of appointments system
285/Chapter
© DHBK 2007
Package Diagram of Appointment System
Problem domain Classes: Patient, Appt. by intermediate Data Access and Manipulation (DM) Classes: DM-Patient, DM-Appt
Separated from object persistence Classes: Patient table, Appt. table
Patient UI dependent on Patient class DM-Patient class dependent on Patient class Patient table dependent on Patient class
ularity (information hiding and encapsulation again) simplifies maintenance (changes are psulated within “module boundary”) and increases reusability (module’s interface defines sages that can be responded to, module can be used/reused “as is” or adapted for other us
286/Chapter
© DHBK 2007
5.1.2 Gói và biểu đồ gói Steps for Identifying Packages and Building Package Diagrams
•
Set the context
•
Cluster classes together based on shared relationships
•
Model clustered classes as a package
•
Identify dependency relationships among packages
•
Place dependency relationships between packages
© DHBK 2007
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
287/Chapter
Step 2: Cluster classes together based on shared relationships, i.e. 288/Chapter form par using relationships (generalisation, aggregation, kinds of association and message passing between objects) shared by classes
© DHBK 2007
Examine analysis models
Class Diagram
Sequence Diagram(s)
Communication Diagram(s) Classes in a generalisation hierarchy put in a single partition
289/Chapter
© DHBK 2007
Step 3: Place clustered classes in partition and model clustered classes as a package, i.e. model partitions as packages
290/Chapter
© DHBK 2007
Step 4: Identify dependency relationships between packages, i.e. relationships that cross boundaries of packages = potential dependencies
a) association relationship between Person Pkg and Appt. Pkg via Association between Doctor class and Appt. class and Patient Pkg contained in Person Pkg
b) Appt. pkg via association between Patient and Appt classes and Treatment Pkg via association between Patient and Symptom classes
291/Chapter
© DHBK 2007
Step 5: Place dependency relationships between packages, i.e. between Person Package and Appt. Package, Person Package and Treatment Package Show dependency relations as “pure” package diagram showing ONLY dependency relations that CAN be created between packages
PD Layer Person Package
Appt. Package
Patient Package
Treatment Package
© DHBK 2007
292/Chapter
Worked Example: Applying Concepts at CD Selections: First, previous lectures...
•
Chapter 5: Functional and Non-functional Requirements
•
Chapter 6: Functional Model = activity diagram + use-case descriptions & diagrams
•
Chapter 7: Structural Model = CRC cards + class diagram
•
Chapter 8: Behavioural Models for “Places Order” use-case + “Order” class (sequence diagram, communication diagram, behavioural state machine)
•
Next: Create package diagram for CD Selections
© DHBK 2007
Example: Applying Concepts at CD Selections
•
Set the context = Problem Domain Layer
•
Cluster classes, i.e. review relationships amongst classes
293/Chapter
Sequence Diagram (Places Order Use Case
CD Selections Class Diagram (Places Order Use-Case View)
Communication Diagram (Place Order Use Case)
© 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
294/Chapter
© DHBK 2007 •
295/Chapter
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)
•
Order Class and Order Item Class = partition
•
Search Req Class and CD List Class = partition
Recall, cluster Mkt Info, Review, Artist Info, Sample Clip classes into partition
© DHBK 2007
•
Model each partition as a package n.b. Credit Card Centre not yet contained in a package
296/Chapter
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)
© DHBK 2007
297/Chapter
Place the dependency relations on the package diagram (and increase clarity by dependency relationships between packages = pure package diagram of PD layer of CD Selections containing highest level packages only (+ Credit Card Centre class) and their dependency relationships
298/Chapter
© DHBK 2007
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 problems e.g. for CD selections, can use ordering “web interface” as strategic enabler to better understand customer’s who order online, using technology to mine data obtained via custom applications • Has potential to change components e.g. for CD selections all components in custom application are available and can be reused in whole or part • Usually increases personnel skills e.g. for CD selections, developers build technical skills and business knowledge as they further evolve the system • Potentially requires significant resources • Potentially adds significant risk
299/Chapter
© DHBK 2007
5.1.3 Các chiến lược thiết kế •
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
300/Chapter
© DHBK 2007
5.1.3 Các chiến lược thiết kế •
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”
301/Chapter
© DHBK 2007
5.1.3 Các chiến lược thiết kế •
Outsourcing – (now increasingly popular) = pay external vendor, developer, service provider to create system For CD selections, use a Web Service Provider who provides commercial order taking system Potentially external suppliers have higher level of skill Their services MUST work to generate income, so web services are built by “experts” with significant experience Is not “cost free” – lose absolute control over software and data, inhouse expertise is not increased Only outsource what is properly understood in advance Needs rigorous planning and analysis of needs in advance of contract negotiations, must identify vendor, developer or service provider with proven track record of success in system and supporting technology for system’s needs Vendor choice and contract & payment method by strictly controlled criteria Time and arrangement deal Fixed price Value added contract
302/Chapter
© DHBK 2007
5.1.3 Các chiến lược thiết kế • Outsourcing Guidelines Keep lines of communication open with outsourcer Define and stabilize requirements before signing a contract View outsourcing relationship as partnership Select outsource vender carefully Assign person to manage relationship Don’t outsource what you don’t understand Emphasize flexible requirements, long-term relationships, and short-term contracts
303/Chapter
© DHBK 2007
5.1.3 Các chiến lược thiết kế • Select a strategy (1): Business need Common business needs best served by packaged systems, i.e. when custom built alternative does not require any special business needs, when system is not critical to company In-house experience Custom application only feasible if sufficient in-house skills for all functional and technical challenges, otherwise packaged system (possibly with in-house integration software added) Project skills Technical, e.g. Java programming and IDE skills, data design and SQL programming skills Functional, e.g. in electronic commerce If electronic commerce is to become basis for company’s future development, in-house skills in EC and technical skills in its exploitation must be further developed Some skills, e.g. network security, might be operational issue which can be outsourced
304/Chapter
© DHBK 2007
5.1.3 Các chiến lược thiết kế • Select a strategy (2): Project management Custom applications require significant project management via application of a proven system development methodology (or collection of integrated methods) Packaged and outsourced systems require different kinds of management, e.g. of contract and delivery Time frame If time to meet business requirement(s) is limited (or short), requirements are “standard” and well-defined, then packaged or outsourced most likely strategies, outsourced for standard, packaged for well-defined
305/Chapter
© DHBK 2007
5.1.4 Phát triển thiết kế thực tế •
Alternative Matrix Combines several feasibility analyses into one grid Revisits technical, economic, and organizational feasibility Created using same steps as feasibility analysis (chapter 3), but combines several analyses into a single matrix for comparison Matrix is represented by a grid Contains technical, budget, organisational feasibilities for each candidate, pro’s and cons, other useful information, e.g. criticality, future-proofing Sometimes “weights” are provided n.b. in AHP weights are derived (mathematically) from judgements over criteria
•
Request For Proposal Aids development of alternative matrix Description of the system you propose to be built Vendors, developers, service providers respond with proposals including how they will address needs as well as stating cost and time requirements. Similar (less effort-intensive) Request For Information (RFI)
306/Chapter
© DHBK 2007
5.1.4 Phát triển thiết kế thực tế
307/Chapter
© DHBK 2007
5.2 Thiết kế lớp và phương thức 5.2.1 Giới thiệu 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
308/Chapter
© DHBK 2007
5.2.1 Giới thiệu • Các mức trừu tượng của hệ thống hướng đối tượng
309/Chapter
© DHBK 2007
5.2.2 Các tiêu chí thiết kế • Coupling • Cohesion • Connascence
310/Chapter
© DHBK 2007
5.2.2 Các tiêu chí thiết kế • 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
311/Chapter
© DHBK 2007
5.2.2 Các tiêu chí thiết kế Types of interaction coupling
312/Chapter
© DHBK 2007
5.2.2 Các tiêu chí thiết kế • Interaction coupling: Law of Demeter = minimise number of objects that can receive messages from a given object Objects only send message to: A) Itself B) An object an object “contained” in an attribute of itself (or an object of one of its superclasses) C) An object passed as a parameter to the mehod D) An object created by the method E) An object stored in a variable whose declaration scope is the entire program (a “global” variable) Coupling increase if: calling method passes attributes to called method Calling method depends on value returned by called method
313/Chapter
© DHBK 2007
5.2.2 Các tiêu chí thiết kế • Cohesion: Refers to how single-minded a module is within a system 3 types of cohesion: Method Class Generalization/specialization
314/Chapter
© DHBK 2007
5.2.2 Các tiêu chí thiết kế •
Cohesion: Method cohesion: Address the cohesion within an individual method. Methods should do one and only one thing
315/Chapter
© DHBK 2007
5.2.2 Các tiêu chí thiết kế •
Cohesion: Class cohesion: Is the level of cohesion among the attributes and methods of a class A class should only represent one thing A cohesive class should: Contain multiple methods that are visible outside the class Have methods that refer to attributes or other methods defined with the class or its superclass Not have any control-flow coupling between its methods
316/Chapter
© DHBK 2007
5.2.2 Các tiêu chí thiết kế •
Cohesion: Class cohesion:
317/Chapter
© DHBK 2007
5.2.2 Các tiêu chí thiết kế •
Cohesion: Generalization/specialization cohesion: Addresses the sensibility of the inheritance hierarchy
318/Chapter
© DHBK 2007
5.2.2 Các tiêu chí thiết kế •
Connascence: Two modules (classes or methods) are so intertwined, that if you make a change in one, it is likely that a change in the other will be required Connascence and encapsulation Minimize overall connascence by eliminating any unnecessary connascence throughout the system, Minimize connascence across any encapsulation boundaries, such as method boundaries and class boundaries, Maximize connascence within any encapsulation boundary.
319/Chapter
© DHBK 2007
5.2.2 Các tiêu chí thiết kế •
Connascence:
© DHBK 2007
• • • • •
320/Chapter
5.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
© DHBK 2007
321/Chapter
5.2.3 Các hoạt động thiết kế đối tượng
• Additional specification: Ensure the classes are both necessary and sufficient for the problem Finalize the visibility of the attributes and methods of each class Determine the signature of every method of each class Define constraints to be preserved by objects
© DHBK 2007
322/Chapter
5.2.3 Các hoạt động thiết kế đối tượng
• Identifying opportunities for reuse: Analysis patterns Representations of the problem-domain
Design patterns Useful grouping of collaborating classes that provide a solution to a commonly occurring problem Many design patterns are available in C++ or Java source code
Frameworks A set of implemented classes that can be used as a basis for implementing an application Most frameworks allow us to create subclasses to inherit from classes in the framework
Libraries components
© DHBK 2007
323/Chapter
5.2.3 Các hoạt động thiết kế đối tượng
• Identifying opportunities for reuse: Libraries Class library similar to framework, i.e. has classes designed for reuse More domain specific, i.e. can be used to realise some layer, e.g. HIC layer Can be used to: Create instances of classes in library Create subclasses by inheritance, and then objects of subtype(s) Using inheritance again increases inheritance coupling and Connascence Directly instantiating class in library, object dependency created between created object and library object due to signatures of methods in library object, i.e. increases interaction coupling between class library object and created object
© DHBK 2007
324/Chapter
5.2.3 Các hoạt động thiết kế đối tượng
• Identifying opportunities for reuse: Components: Self-contained & encapsulated software that can be plugged into a system Provides specific funtionality Typically components implemented using ActiveX or JavaBean Component has well-defined Application Program Interface (API) API = set of method interfaces to objects contained in component Internal operation of component hidden by API Components can be implemented using class libraries and frameworks Unless API changes between between version of component, only need to relink component to application (no recompilation required)
© DHBK 2007
325/Chapter
5.2.3 Các hoạt động thiết kế đối tượng
• Identifying opportunities for reuse:
© DHBK 2007
326/Chapter
5.2.3 Các hoạt động thiết kế đối tượng
• Restructuring the design: Factoring Separate out shared aspects of a method or class into a new method or class New class related to existing classes via inheritance, aggregation or association Normalization Identifies classes missing from the design All association and aggregation relationships converted to attributes of the class Challenge inheritance relationships to ensure they only support a generalization/specialization semantics
© DHBK 2007
327/Chapter
5.2.3 Các hoạt động thiết kế đối tượng
• Optimizing the design Simple optimisations make an existing design more efficient, but must not make optimised design significantly more difficult to reason about, i.e. optimsation is a “trade-off” between efficiency and ease of understanding the design optimisations below need to be considered. [1] access paths between objects [2] attributes of each class [3] direct and indirect “fan-out” of each method [4] execution order of statements [5] unnecessary recomputation
© DHBK 2007
328/Chapter
5.2.3 Các hoạt động thiết kế đối tượng
• 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
© DHBK 2007
329/Chapter
5.2.3 Các hoạt động thiết kế đối tượng
• Optimizing the design [4] execution order of statements In frequently used methods, order of statements may be nonoptimal 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
© DHBK 2007
330/Chapter
5.2.3 Các hoạt động thiết kế đối tượng
• Map Problem Domain Classes to Implementation Languages: OO designs assume class-based OO programming language used to implement those designs e.g. UML class diagram is-a specification of a class in a classbased 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
© DHBK 2007
331/Chapter
5.2.3 Các hoạt động thiết kế đối tượng
• Map Problem Domain Classes to Implementation Languages: [1] design uses multiple inheritance, language has only single inheritance A) Convert multiple inheritance relationships to “superclass”-subclass association relationships If additional superclasses are concrete (objects of the class can be instantiated) then multiplicity from superclass to subclass is 0..1 Otherwise multiplicity is 1..1 Add an exclusive-OR constraint between associations Add appropriate methods to ensure all information remains available to existing class B) Copy ALL the attributes and methods of the additional superclasses to ALL the subclassess and remove additional superclass from the design
© DHBK 2007
332/Chapter
5.2.3 Các hoạt động thiết kế đối tượng
• Map Problem Domain Classes to Implementation Languages: [1] design uses multiple inheritance, language has only single inheritance
concrete SuperClass1 SuperClass2 -attribute1 1..1 -attribute3 -attribute2 -attribute4 0..*
Class1 -attribute5 -attribute6
{XOR}
SuperClass3 1..1 -attribute7 -attribute8
0..*
Class2 -attribute5 -attribute6
[1]All classes preserved [2]Increases amount of message passing [3]Adds to processing requirement due to XOR
© DHBK 2007
333/Chapter
5.2.3 Các hoạt động thiết kế đối tượng
• Map Problem Domain Classes to Implementation Languages: [1] design uses multiple inheritance, language has only single inheritance
abstract SuperClass1 -attribute1 -attribute2
SuperClass2 -attribute3 -attribute4
Class1 -attribute3 -attribute4 -attribute5 -attribute6
SuperClass3 -attribute7 -attribute8
Class2 -attribute3 -attribute4 -attribute5 -attribute6
Potential Inheritance Conflicts
© DHBK 2007
334/Chapter
5.2.3 Các hoạt động thiết kế đối tượng
• Map Problem Domain Classes to Implementation Languages: [2] implementation language is object-based and not classbased Need to factor out ALL uses of inheritance from problem-domain class design All superclasses concrete SuperClass1 SuperClass2 -attribute1 1..1 -attribute3 -attribute2 -attribute4 1..10..* 1..1
Class1 -attribute5 -attribute6
{XOR}
SuperClass3 1..1 -attribute7 -attribute8
0..*
Class2 -attribute5 -attribute6
1..1 1..1
© DHBK 2007
335/Chapter
5.2.3 Các hoạt động thiết kế đối tượng
• Map Problem Domain Classes to Implementation Languages: [2] implementation language is object-based and not classbased SuperClass1 -attribute1 -attribute2
If all superclasses are abstract SuperClass3 SuperClass2 -attribute7 -attribute3 -attribute8 -attribute4
Class1 -attribute1 -attribute2 -attribute3 -attribute4 -attribute5 -attribute6 -attribute7 -attribute8
Class2 -attribute1 -attribute2 -attribute3 -attribute4 - attribute5 -attribute6 -attribute7 -attribute8
Potential Inheritance Conflicts
© DHBK 2007
336/Chapter
5.2.3 Các hoạt động thiết kế đối tượng
• Map Problem Domain Classes to Implementation Languages: [3] language is of another (less expressive) language paradigm, e.g. C or Pascal are of the imperative-procedural paradigm Stay away from this! But if necessary, factor out all uses of Polymorphism Dynamic binding Encapsulation Information hiding
337/Chapter
© DHBK 2007
5.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
338/Chapter
© DHBK 2007
5.2.4 Ràng buộc và giao kèo • Pre- and post-conditions model constraints on individual methods • Invariants model constraints (that must always be true) for all instances of a class, e.g. Domains (in DB) or types (in design/programming language) of attributes Multiplicity of attributes Legal values of attributes including attributes that model association and aggregation and relationships e.g. if association relationship is required, invariant is created to enforce relationship to have valid value for instance to exist • Invariants usually attached to the class, e.g. CRC cards or class diagrams as a set of assertions
© DHBK 2007
•
Example:-
Attribute Constraint: Order Number IS unsigned long
339/Chapter Attribute Constraint: Customer IS INSTANCE OF Customer Class
Back: Attributes: Order Number (1:1) (unsigned long) Date (1..1) (Date) Sub Total (0..1) (double) Tax (0..1) (double) {Sub Total = sum(Product Order.GetExtension()) hipping (0..1) (double) Total (0..1) (double) Customer (1..1) (Customer) Cust ID (1..1) (unsigned long) (Cust ID = Customer.GetCustID()} State (1..1) (State) StateName (String) {State Name = State.GetState()}
Attribute Constraint Cust ID IS unsigned Long Constraint: Instance of Order EXISTS Relationships: AND IF (instance of Customer class AND Generalisation(a-kindInvariant instance of State class AND of): MUST HAVE one and >=1 instance of Product class) Aggregation (has-parts): ONLY one value ASSOCIATED WITH order object (1..1) = Other Associations: Product{1..*} Customer(1..1} State{1..1} Customer. GetCustID(
© DHBK 2007
Product Order
Invariants On a Class Diagram(Not recommended – Use CRC card for Invariants)
<
Customer -Cust ID -Last Name -First Name
340/Chapter
Order Product Quantity Extension
Order Product -Order Number: unsigned long -Product Number -Date[1..]: Date -Product Desc 1..1 0..* -Sub Total[0..1]: double 0..* 1..* -Price -Tax[0..1]:double -Shipping[0..1]:double -Total[0..1]double -Tax[0..1]: double -Customer[1..1]: Customer <
<
0..* 1..1-State Tax RateProduct Desc
341/Chapter
© DHBK 2007
5.2.4 Ràng buộc và giao kèo •
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
342/Chapter
© DHBK 2007
Specific Method OF specific Class
Unique Contract ID
List of classes and methods that send a message to this List of use cases containingmethod this method where method is used to realise implementation of the use case (from server class’s CRC card and associated use cases) What the method does NOT how it does it
types of parameters passed type of value returned to its clients
= method signature
343/Chapter
© DHBK 2007
5.2.5 Xác định phương thức • • • •
General information Events Message passing Algorithm specification Structured English Pseudocode UML activity diagram
344/Chapter General Information (for managing programming effor
© DHBK 2007
Method Name Contract ID Programming Language:
Class Name Programmer:
ID: Date Due:
Visual Basic
SmallTalk
C++
Java
e.g. user initiated event(mouse event, keystroke event), Triggers/Events system event or event initiated by another method Arguments Received: Data Type:
Messages Sent & Arguments Passed ClassName.MethodName:
Argument Returned: Data Type: Algorithithm Specification:
Notes: Message passing to and from method (c.f. sequence and collaboration diagrams) Arguments = attributes and data structures in implemented method Data Type:
Notes:
Notes:
345/Chapter
© DHBK 2007
•
Structured English will suffice for algorithm specification…
Algorithm Specification: Action Statement
Examples:
Profits = Revenues – Expenses Generate Inventory-Report
IF Statement
Examples: IF Customer NOT in Customer Object Store THEN Add Customer record to Customer Object Store ELSE Add Current-Sale to Customer’s Total Sales Update Customer record in Customer Object Store
FOR Statement
Examples: FOR all Customers in Customer Object Store DO Generate a new line in Customer-Report Add Customer’s Total-Sales to Report-Total
CASE Statement Examples: CASE IF Income < 10,000: Marginal-tax-rate IF Income < 20,000: Marginal-tax-rate IF Income < 30,000: Marginal-tax-rate IF Income < 40,000: Marginal-tax-rate ELSE Marginal-tax-rate = 38 percent ENDCASE Notes:
= = = =
10 20 31 35
percent percent percent percent
© DHBK 2007
346/Chapter
• 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
Related Documents
Phan Tich Thiet Ke Huong Doi Tuong
November 2019 12
Thiet Ke Huong Doi Tuong
May 2020 7
Phan Tich Ve Thiet Ke He Thong
July 2020 9
Phan Tich Thiet Ke
November 2019 23