uml_phan_tich_va_thiet_ke_huong_doi_tuong__0506

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

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

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

2/Chapter© DHBK 2007

Gi i thi uớ ệGi i thi uớ ệ

• 4 ĐVHT = 60 ti tế• H cọ trên l pớ + Bài t p l nậ ớ• Đi m = Đi m thi + Đi m bài t p l nể ể ể ậ ớ

(70%) + (30%)• Đi u ki n thi: Ph i có bài t p l nề ệ ả ậ ớ• Bài t p l n:ậ ớ

Làm theo nhóm t i đa 5 sinh viênốN i dung: phân tích và thi t k h th ng s d ng Rational ộ ế ế ệ ố ử ụ

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

• M c đích c a môn h cụ ủ ọTrang b cho sinh viên ị m t ph ng pháp có h th ngộ ươ ệ ố đ phân ể

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

N i dungộN i dungộ

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

t ng v i UMLượ ớ3. L p k ho chậ ế ạ4. Phân tích h th ngệ ố5. Thi t k h th ngế ế ệ ố6. Tri n khai h th ngể ệ ố

Tài li u tham kh oệ ảTài li u tham kh oệ ả

• Systems Analysis and Design with UML Version 2.0-An object oriented approach; Alan Dennis, Barbara Haley Wixom, David Tegarden.

• www.uml.org

• www.rational.com• www.Google.com

Ch ng 1. Gi i thi u chung v phân ươ ớ ệ ềCh ng 1. Gi i thi u chung v phân ươ ớ ệ ềtích và thi t k h th ngế ế ệ ốtích và thi t k h th ngế ế ệ ố

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

1.1 Gi i thi uớ ệ1.1 Gi i thi uớ ệ

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

• L p k ho ch (ậ ế ạ Planning)Vì sao ph i xây d ng h th ng ?ả ự ệ ố

• Phân tích (Analysis)Ai s s d ng h th ng, h th ng s ẽ ử ụ ệ ố ệ ố ẽ làm gì, nó s ẽ

đ c dùng ượ khi nào, đâu?ở

• Thi t k (ế ế Design)H th ng s làm vi c ệ ố ẽ ệ nh th nào?ư ế

• Tri n khai (ể Implementation)Tri n khai h th ngể ệ ố

1.2 Quy trình phát tri n h th ngể ệ ố1.2 Quy trình phát tri n h th ngể ệ ốL p k ho chậ ế ạ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ề ể ả ự

1.2 Quy trình phát tri n h th ngể ệ ố1.2 Quy trình phát tri n h th ngể ệ ốPhân tíchPhân tích

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

• Mô hình hóa d li uữ ệ

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

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

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

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

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

Process Product

Planning

Analysis

Design

Implementation

Project Plan

System Proposal

System Specification

New System and Maintenance Plan

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

• Thi t k c u trúc (ế ế ấ Structured design) Ph ng pháp thác n c ươ ướ (waterfall method) Ph ng pháp phát tri n song song ươ ể (Parallel

development)

• Ph ng pháp phát tri n nhanh ng d ng (ươ ể ứ ụ RAD) Ph ng pháp phát tri n theo các ươ ể pha

Ph ng pháp xây d ng nguyên m u ươ ự ẫ (prototyping) Thông th ng ườ (regular)

Lo i b ạ ỏ (throwaway)

• Ph ng pháp phát tri n r t nhanh (ươ ể ấ Agile development)XP (extreme programming)

1.3.1 Thi t k c u trúcế ế ấ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ướ ắ ầ ướ ế

1.3.1 Thi t k c u trúcế ế ấ1.3.1 Thi t k c u trúcế ế ấPh ng pháp thác n cươ ướPh ng pháp thác n cươ ướ

• u đi m:Ư ểTr c khi l p trình thì các yêu c u v h th ng đ c xác ướ ậ ầ ề ệ ố ượ

đ nh r t chi ti t và đ y đ => gi m thi u đ c s thay đ i ị ấ ế ầ ủ ả ể ượ ự ổv yêu c u trong quá trình phát tri n h th ngề ầ ể ệ ố

• Nh c đi m:ượ ểTh i gian t khi đ xu t d án đ n khi có s n ph m cu i ờ ừ ề ấ ự ế ả ẩ ố

cùng th ng r t dài (vài tháng -> vài năm)ườ ấ

1.3.1 Thi t k c u trúcế ế ấ1.3.1 Thi t k c u trúcế ế ấPh ng pháp phát tri n song songươ ểPh ng pháp phát tri n song songươ ể

1.3.2 RAD1.3.2 RAD

• Các nhân t quan tr ng:ố ọ Công c CASEụ JAD Ngôn ng l p trình th h th t / visualữ ậ ế ệ ứ ư Công c t o mãụ ạ

1.3.2 RAD1.3.2 RADPh ng pháp phát tri n theo phaươ ểPh ng pháp phát tri n theo phaươ ể

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

th ngườth ngườ

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

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

• Tiêu chí: Đ rõ ràng, đ y đ c a các yêu c u c a ng i s ộ ầ ủ ủ ầ ủ ườ ử

d ngụ Kh năng, m c đ thành th o v công nghả ứ ộ ạ ề ệ Đ ph c t p c a h th ngộ ứ ạ ủ ệ ố Đ tin c y c a h th ngộ ậ ủ ệ ố Qu th i gianỹ ờ

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

Ch ng 2: Gi i thi u v phân tích và ươ ớ ệ ềCh ng 2: Gi i thi u v phân tích và ươ ớ ệ ềthi t k h ng đ i t ng v i UMLế ế ướ ố ượ ớ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

• L ch s phát tri n c a ngôn ng l p trình:ị ử ể ủ ữ ậFirst Generation (1954 – 1958)

Fortran I

Second Generation (1959 – 1961)Fortran II, Algol, Cobol

Third Generation (1962 – 1970)PL/I, Pascal

Object Oriented LanguagesSmalltalk, C++, Java

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

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

JacobsonJacobsonBoochBoochRumbaughRumbaugh

UML 1.1 (OMG Standard)UML 1.1 (OMG Standard)

UML 1.3 (extensibility)UML 1.3 (extensibility)

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

UML 1.4.1UML 1.4.1

20012002

UML 2.0UML 2.0

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

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

2.2.1 L p và đ i t ngớ ố ượ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 ứ

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

2.2.2 Ph ng th c và messageươ ứ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

2.2.2 Ph ng th c và messageươ ứ2.2.2 Ph ng th c và messageươ ứ

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

• Encapsulation combination of data and process into an entity

• Information HidingOnly the information required to use a software module

is published to the user

2.2.4 Th a kừ ế2.2.4 Th a kừ ế

• Superclasses or general classes are at the top of a hierarchy of classes

• Subclasses or specific classes are at the bottom• Subclasses inherit attributes and methods from

classes higher in the hierarchy

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

• PolymorphismA message can be interpreted differently by different

classes of objects

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

run-time

• Static BindingType of object determined at compile time

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

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

34 virtual void printShapeName() const { cout << "Point: "; }

35 virtual void print() const;

36 private:

37 int x, y; // x and y coordinates of Point

40 #endif

41 // Fig. 20.1: point1.cpp

42 // Member function definitions for class Point

43 #include "point1.h"

45 Point::Point( int a, int b ) { setPoint( a, b ); }

47 void Point::setPoint( int a, int b )

49 x = a;

50 y = b;

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"

61 class Circle : public Point {

62 public:

63 // default constructor

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

66 void setRadius( double );

67 double getRadius() const;

68 virtual double area() const;

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

71 private:

72 double radius; // radius of Circle

75 #endif

76 // Fig. 20.1: circle1.cpp

77 // Member function definitions for class Circle

78 #include <iostream>

80 using std::cout;

82 #include "circle1.h"

84 Circle::Circle( double r, int a, int b )

85 : Point( a, b ) // call base-class constructor

86 { setRadius( r ); }

88 void Circle::setRadius( double r ) { radius = r > 0 ? r : 0; }

90 double Circle::getRadius() const { return radius; }

92 double Circle::area() const

93 { return 3.14159 * radius * radius; }

95 void Circle::print() const

97 Point::print();

98 cout << "; Radius = " << radius;

100// Fig. 20.1: cylindr1.h

101// Definition of class Cylinder

102#ifndef CYLINDR1_H

103#define CYLINDR1_H

104#include "circle1.h"

106class Cylinder : public Circle {

107public:

108 // default constructor

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

110 int x = 0, int y = 0 );

112 void setHeight( double );

113 double getHeight();

114 virtual double area() const;

115 virtual double volume() const;

116 virtual void printShapeName() const { cout << "Cylinder: "; }

118private:

119 double height; // height of Cylinder

122#endif

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

155// Fig. 20.1: fig20_01.cpp

156// Driver for shape, point, circle, cylinder hierarchy

157#include <iostream>

159using std::cout;

160using std::endl;

162#include <iomanip>

164using std::ios;

165using std::setiosflags;

166using std::setprecision;

168#include "shape.h"

169#include "point1.h"

170#include "circle1.h"

171#include "cylindr1.h"

173void virtualViaPointer( const Shape * );

174void virtualViaReference( const Shape & );

176int main()

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

179 << setprecision( 2 );

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

185 point.printShapeName(); // static binding

2. Function calls

186 point.print(); // static binding187 cout << '\n';188189 circle.printShapeName(); // static binding190 circle.print(); // static binding191 cout << '\n';192193 cylinder.printShapeName(); // static binding194 cylinder.print(); // static binding195 cout << "\n\n";196197 Shape *arrayOfShapes[ 3 ]; // array of base-class pointers198199 // aim arrayOfShapes[0] at derived-class Point object200 arrayOfShapes[ 0 ] = &point;201202 // aim arrayOfShapes[1] at derived-class Circle object203 arrayOfShapes[ 1 ] = &circle;204205 // aim arrayOfShapes[2] at derived-class Cylinder object206 arrayOfShapes[ 2 ] = &cylinder;207208 // Loop through arrayOfShapes and call virtualViaPointer209 // to print the shape name, attributes, area, and volume 210 // of each object using dynamic binding.211 cout << "Virtual function calls made off "212 << "base-class pointers\n";213214 for ( int i = 0; i < 3; i++ ) 215 virtualViaPointer( arrayOfShapes[ i ] );216217 // Loop through arrayOfShapes and call virtualViaReference218 // to print the shape name, attributes, area, and volume 219 // of each object using dynamic binding.

220 cout << "Virtual function calls made off "

221 << "base-class references\n";

223 for ( int j = 0; j < 3; j++ )

224 virtualViaReference( *arrayOfShapes[ j ] );

226 return 0;

229// Make virtual function calls off a base-class pointer

230// using dynamic binding.

231void virtualViaPointer( const Shape *baseClassPtr )

233 baseClassPtr->printShapeName();

234 baseClassPtr->print();

235 cout << "\nArea = " << baseClassPtr->area()

236 << "\nVolume = " << baseClassPtr->volume() << "\n\n";

239// Make virtual function calls off a base-class reference

240// using dynamic binding.

241void virtualViaReference( const Shape &baseClassRef )

243 baseClassRef.printShapeName();

244 baseClassRef.print();

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

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

2.3 UML 2.02.3 UML 2.0

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

2.3.1 Gi i thi u v UMLớ ệ ề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.”

• UML ch đ n thu n là ngôn ng đ ho đ mô hình ỉ ơ ầ ữ ồ ạ ểhoá ch không ph i là ph ng pháp đ phát tri n h ứ ả ươ ể ể ệth ngố

Grady Booch, Ivar Jacobsen, Jim Rumbaugh Rational Software

2.3.1 Gi i thi u v UMLớ ệ ề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ể ồ ứ

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

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

diagrams)

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

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

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

đ t o thành thành ph n l n h nể ạ ầ ớ ơ

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

h th ngệ ố

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

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

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

• 8 lo i bi u đ ch c năngạ ể ồ ứBi u đ ho t đ ng (activity diagram)ể ồ ạ ộBi u đ t ng tác (interaction diagrams)ể ồ ươ

Bi u đ chu i tu n t (sequence diagram)ể ồ ỗ ầ ựBi u đ c ng tác (communication/collaboration diagram)ể ồ ộBi u đ khát quát t ng tác (interaction overview diagram)ể ồ ươBi u đ th i gian (timing diagram)ể ồ ờ

Bi u đ máy tr ng thái (state machines)ể ồ ạMáy tr ng thái ch c năng (behavior state machines)ạ ứMáy tr ng thái giao th c (protocol state machines)ạ ứ

Bi u đ ca s d ng (use case diagram)ể ồ ử ụ

• Bi u đ ho t đ ng ể ồ ạ ộ(activity diagram) Đ c dùng đ mô t lu ng ượ ể ả ồ

công vi c c a h th ng ệ ủ ệ ốho c lu ng ho t đ ng trong ặ ồ ạ ộm t ca s d ng ho c mô t ộ ử ụ ặ ảthi t k chi ti t c a m t ế ế ế ủ ộph ng th c (method)ươ ứ

• Bi u đ chu i tu n t (sequence diagram)ể ồ ỗ ầ ự Mô t các ho t đ ng c a các đ i t ng trong m t ca s d ng d a ả ạ ộ ủ ố ượ ộ ử ụ ự

vào th t xu t hi n theo th i gianứ ự ấ ệ ờ

• Bi u đ c ng tác (collaboration diagram)ể ồ ộ Là cách bi u di n khác c a bi u đ chu i tu n t nh ng t p ể ễ ủ ể ồ ỗ ầ ự ư ậ

trung vào m i quan h và giao ti p gi a các đ i t ngố ệ ế ữ ố ượ

• Bi u đ khát quát t ng tác (interaction overview ể ồ ươdiagram) Đ c dùng đ mô t t ng tác gi a các đ i t ng trong các ca s ượ ể ả ươ ữ ố ượ ử

d ng ph c t pụ ứ ạ Ít đ c s d ngượ ử ụ

• Bi u đ th i gian (timing diagram)ể ồ ờ Đ c dùng đ mô t t ng tác gi a các đ i t ng theo th i gian. ượ ể ả ươ ữ ố ượ ờ

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

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

• Bi u đ máy tr ng thái ch c năng (behavior state ể ồ ạ ứmachines) Đ c dùng đ mô t các tr ng thái khác nhau mà các đ i t ng ượ ể ả ạ ố ượ

c a m t l p có th có trong th i gian t n t i c a chúng.ủ ộ ớ ể ờ ồ ạ ủ

• Bi u đ máy tr ng thái giao th c (protocol state ể ồ ạ ứmachines) Đ c dùng đ mô t giao th c gi a các l pượ ể ả ứ ữ ớ Ví d : open database -> Query or updateụ

• Bi u đ ca s d ng (use case diagram)ể ồ ử ụ Đ c dùng đ mô t t ng tác gi a m t h th ng v i ng i s ượ ể ả ươ ữ ộ ệ ố ớ ườ ử

d ng ho c v i các h th ng khác có t ng tác v i nó.ụ ặ ớ ệ ố ươ ớ Là công c đ mô t các yêu c u c a h th ngụ ể ả ầ ủ ệ ố Là m t trong nh ng công c quan tr ng nh t trong phân tích và ộ ữ ụ ọ ấ

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

2.3.4 Các c ch m r ngơ ế ở ộ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 { }ộ ượ ặ ặ

• Nhãn:giá tr (tagged values)ị Là m t c p chu i ký t : nhãn (tag) và giá tr (value) đ c dùng đ ộ ặ ỗ ự ị ượ ể

b sung thông tin cho m t ph n t nào đó (l p, đ i t ng, quan ổ ộ ầ ử ớ ố ượh …)ệ

Nhãn và giá tr đ c đ t trong ngo c { } ị ượ ặ ặ

• Khuôn m u (stereotype)ẫ Cho phép m r ng UML b ng cách s d ng các ph n t mô hình ở ộ ằ ử ụ ầ ử

hoá đã có s n trong UMLẵ Khuôn m u có th s d ng ràng bu c và tagged valuesẫ ể ử ụ ộ Khuôn m u đ c đ t trong d u << >>ẫ ượ ặ ấ

2.3.5 Tóm t tắ2.3.5 Tóm t tắ

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

2.4.1 Đ c đi m c b n c a OOADặ ể ơ ả ủ2.4.2 u đi m c a OOADƯ ể ủ2.4.3 The Unified Process

2.4.4 The MOOSAD

2.4.1 Đ c đi m c b n c a OOADặ ể ơ ả ủ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

2.4.2 u đi m c a OOADƯ ể ủ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 ư ề ố ượ ầ ớ ự ế

2.4.2 u đi m c a OOADƯ ể ủ2.4.2 u đi m c a OOADƯ ể ủ

2.4.3 The Unified process2.4.3 The Unified process

• Unified process là m t ph ng pháp phát tri n h ộ ươ ể ệth ng trong đó quy đ nh khi nào thì s d ng các ố ị ử ụk thu t UML và s d ng chúng nh th nào trong ỹ ậ ử ụ ư ếquá trình phân tích và thi t k h th ng.ế ế ệ ốTác gi : Booch, Jacobsen, 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àngKhông xét đ n các v n đ t ng tác gi a các d ánế ấ ề ươ ữ ự

• Pha kh i t o (Inception): gi ng nh pha l p k ở ạ ố ư ậ ếho ch ạCác b c liên quan:ướ

Mô hình hoá giá tr kinh doanh c a h th ng (business modeling) *ị ủ ệ ốXác đ nh yêu c u (requirements)*ị ầPhân tích (analysis)*Thi t k (design)ế ếTh c hi n (implementation)ự ệKi m tra (test)ểMôi tr ng phát tri n (environment)*ườ ể

K t qu :ế ảPh m vi c a d ánạ ủ ựCác yêu c u và ràng bu c quan tr ngầ ộ ọK ho ch d án b c đ uế ạ ự ướ ầMiêu t tính kh thi và r i ro c a d ánả ả ủ ủ ựL a ch n môi tr ng c n thi t đ phát tri n h th ngự ọ ườ ầ ế ể ể ệ ố

• Pha phát tri n (elaboration): hoàn thi n mô hình ể ệkinh doanh, đánh giá l i r i ro và hoàn thi n k ạ ủ ệ ếho ch d ánạ ự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ả ạ ộ ầ ủ ệ ố

• 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ả ủ ệ ố

• 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ế ạ ỗ ợ ế ạ ấ ệ ố

• Các b c k thu t (Engineering workflows)ướ ỹ ậ1. Mô hình hoá giá tr kinh doanh (business modeling)ị

Di n ra ch y u trong pha kh i t oễ ủ ế ở ạ Phát hi n v n đ và xác đ nh các d án ti m năngệ ấ ề ị ự ề Xác đ nh giá tr kinh doanh mà d án đem l iị ị ự ạ Thu th p d li u và mô hình hoá ca s d ng có th đ c s ậ ữ ệ ử ụ ể ượ ử

d ngụ

2. Xác đ nh yêu c u (requirements)ị ầ Xác đ nh yêu c u v ch c năng và c không ch c năngị ầ ề ứ ả ứ Yêu c u đ c thu th p t ng i s d ng, ng i qu n lý ầ ượ ậ ừ ườ ử ụ ườ ả

ng i s d ng, khách hàngườ ử ụ

3. Phân tích Xây d ng bi u đ c u trúc và ch c năng s d ng UMLự ể ồ ấ ứ ử ụ Xác đ nh các l p có th s d ng l iị ớ ể ử ụ ạ B c phân tích có th đ c s d ng l i b t kỳ lúc nào trong chu ướ ể ượ ử ụ ạ ấ

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

• Các b c k thu t (Engineering workflows)ướ ỹ ậ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ầ ề ố ặ

• Các b c h tr (Supporting workflows)ướ ỗ ợ1. Qu n lý d án (project management)ả ự

Di n ra trong su t quá trình phát tri n h th ngễ ố ể ệ ố Xác đ nh và qu n lý r i roị ả ủ Qu n lý ph m vi d ánả ạ ự Qu n lý v th i gian, chi phí…ả ề ờ

2. Qu n lý c u hình và thay đ i (configuration and ả ấ ổchange management ) Theo dõi và qu n lý tr ng thái và các phiên b n c a h th ngả ạ ả ủ ệ ố Qu n lý vi c thay đ i các phiên b n (ng i thay đ i, th i gian ả ệ ổ ả ườ ổ ờ

thay đ i…)ổ

3. Qu n lý môi tr ng phát tri n (environment)ả ườ ể Qu n lý các công c và môi tr ng phát tri n c n thi t cho d ả ụ ườ ể ầ ế ự

án Ví du: Rational Rose, Microsoft project, Microsoft Visual C++

2.4.4 MOOSAD2.4.4 MOOSAD

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

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

3.1 Kh i t o d ánở ạ ự3.1 Kh i t o d ánở ạ ự

3.1.1 Gi i thi uớ ệ3.1.2 Yêu c u h th ng (system request)ầ ệ ố3.1.3 Phân tích tính kh thi (feasibility analysis)ả3.1.4 L a ch n d ánự ọ ự

3.1.1 Gi i thi uớ ệ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ộ ồ ệ ự

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

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

Project sponsor + analyst

• H i đ ng duy t d án (approval committee)ộ ồ ệ ựH i đ ng chuyên trách h p th ng kỳ (vd. 3 tháng 1 ộ ồ ọ ườ

l n)ầ1 đ n v ch c năng ho c cá nhân có th m quy n (vd. ơ ị ứ ặ ẩ ề

phòng qu n lý d án, giám đ c)ả ự ố

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

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

• Ch nhi m d án (project sponsor)ủ ệ ự Ng i thu c phòng kinh doanhườ ộ Ng i thu c phòng IT có th là ch nhi m ho c đ ng ch nhi m ườ ộ ể ủ ệ ặ ồ ủ ệ

d ánự CIO, CEO

• Nhu c u kinh doanh (business need): why?ầ Xu t phát t :ấ ừ

Phòng kinh doanhPhòng ITChuyên gia t v n bên ngoàiư ấ

Phát sinh khi:1 chi n d ch kinh doanh m i c n đ c h trế ị ớ ầ ượ ỗ ợ c n tìm ki m thêm khách hàngầ ế c n c i thi n vi c trao đ i v i nhà phân ph iầ ả ệ ệ ổ ớ ố vi c kinh doanh c a công ty có v n đ : c phi u gi m, h tr khách ệ ủ ấ ề ổ ế ả ỗ ợ

hàng kém, b c nh tranhị ạcông ngh m i nhi u ti m năng xu t hi nệ ớ ề ề ấ ệ

• Yêu c u kinh doanh (business requirement)ầH th ng s làm gìệ ố ẽCác ch c năng c a h th ngứ ủ ệ ố

• Giá tr kinh doanh (business values)ịGiá tr h u hình: ví d : 20 % gi m v chi phíị ữ ụ ả ềGiá tr vô hình: ví d : c i thi n ch t l ng d ch v ị ụ ả ệ ấ ượ ị ụ

khách hàng, c i thi n v trí c nh tranhả ệ ị ạ

• Các v n đ đ c bi tấ ề ặ ệví d : th i h n hoàn thànhụ ờ ạ

Case study: CD selectionsCase study: CD selections

• Gi i thi u chung v công ty CD selections:ớ ệ ề50 c a hàng băng đĩa ca nh c Californiaử ạ ởDoanh s bán hàng: 50 tri u USDố ệTăng tr ng 3-5 % / nămưởCó website cung c p các thông tin c b n v công ty ấ ơ ả ề

nh ch d n đ ng đi đ n, gi m c a, đ a ch liên h ư ỉ ẫ ườ ế ờ ở ử ị ỉ ệ

• Margaret Mooney, phó ch t ch ph trách th ủ ị ụ ịtr ng có ý t ng bán CD trên m ng Internetườ ưở ạ

Case study: CD selectionsCase study: CD selections

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

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

• Kh thi v k thu t (technical feasibility) (can we ả ề ỹ ậbuild it ?)M c đ quen thu c v i ng d ngứ ộ ộ ớ ứ ụM c đ quen thu c v i công nghứ ộ ộ ớ ệKích th c c a d án:ướ ủ ự

S l ng ng i tham dố ượ ườ ựth i gianờđ ph c t p c a h th ngộ ứ ạ ủ ệ ố

S t ng thích c a h th ng m i v i h th ng đang ự ươ ủ ệ ố ớ ớ ệ ốt n t iồ ạ

quy t đ nh d a trên vi c so sánh v i các d án tr c đó ho c ế ị ự ệ ớ ự ướ ặtham kh o ý ki n c a chuyên gia công nghả ế ủ ệ

• Kh thi v kinh t (economic feasibility) (should we build it ả ề ế?) Xác đ nh các lo i chi phí và l i nhu nị ạ ợ ậ

Chi phí phát tri n h th ng (1 l n)ể ệ ố ầChi phí v n hành (chi phí th ng xuyên)ậ ườL i nhu n h u hìnhợ ậ ữL i nhu n vô hìnhợ ậ

• Kh thi v kinh t (economic feasibility) (should we build it ả ề ế?) Đ nh l ng các lo i chi phí và l i nhu nị ượ ạ ợ ậ

C g ng đ nh l ng các giá tr vô hìnhố ắ ị ượ ị

• Kh thi v kinh t (economic feasibility) (should we build it ả ề ế?) Xác đ nh dòng ti n m t (cash flow): giá tr chi phí và l i nhu n ị ề ặ ị ợ ậ

trong kho ng th i gian t 3-5 nămả ờ ừ

• Kh thi v kinh t (economic feasibility) (should we build it ả ề ế?) Xác đ nh giá tr hi n t i Net present Value (NPV)ị ị ệ ạ Xác đ nh t l h i v n (Return on Investment)ị ỷ ệ ồ ố Xác đ nh đi m hoà v n (break even point)ị ể ố V đ th đi m hoà v nẽ ồ ị ể ố

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

• Kh thi v t ch cả ề ổ ứ Phân tích đánh giá m c đ h th ng m i đ c ch p nh n b i ứ ộ ệ ố ớ ượ ấ ậ ở

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

2 cách đánh giá:H th ng m i có cùng đ nh h ng v i chi n l c phát tri n c a công ệ ố ớ ị ướ ớ ế ượ ể ủ

ty?Phân tích nh h ng ho c b nh h ng c a d án đ i v i nh ng ả ưở ặ ị ả ưở ủ ự ố ớ ữ

ng i liên quanườ Ng i b o tr cho d ánườ ả ợ ự Ng i s d ng h th ngườ ử ụ ệ ố Ban lãnh đ o công tyạ

• Case study: CD selections

3.1.4 L a ch n d ánự ọ ự3.1.4 L a ch n d ánự ọ ự

• 3 ph ng án:ươThông quaLo i bạ ỏXem xét l iạ

• Ph thu c vào:ụ ộROI, giá tr NPV c a l i nhu n, th i gian hoà v nị ủ ợ ậ ờ ốS l ng và ch t l ng các d án khácố ượ ấ ượ ự

3.2 Qu n lý d ánả ự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

• Project management is the process of planning and controlling the development of a system within a specified timeframe at a minimum cost with the right functionality.

• A project manager has the primary responsibility for managing the hundreds of tasks and roles that need to be carefully coordinated.

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

• Ph ng pháp đ n gi n d a trên chu n công ươ ơ ả ự ẩnghi pệ

Planning Analysis Design Implementation

IndustryStandardFor Web 15% 20% 35% 30%Applications

TimeRequired 4 5.33 9.33 8in PersonMonths

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

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

s dòng l nhố ệ1 đi m ch c năng là đ n v đo kích th c ch ng trình d a ể ứ ơ ị ướ ươ ự

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

Tính toán s đi m ch c năngố ể ứLi t kê các thành ph n c b n c a ch ng trìnhệ ầ ơ ả ủ ươXác đ nh s l ng m i thành ph nị ố ượ ỗ ầXác đ nh đô ph c t p c a m i thành ph n (low, med., high)ị ứ ạ ủ ỗ ầTính t ng s đi m ch c năng (TUFP)ổ ố ể ứ

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

Complexity

Description Low Medium High Total

Inputs __x 3 __x 4 __x 6 ____

Outputs __x 4 __x 5 __x 7 ____

Queries __x 3 __x 4 __x 6 ____

Files __x 7 __x 10 __x 15 ____

Program __x 5 __x 7 __x 10 ____Interfaces

TOTAL UNADJUSTED FUNCTION POINTS ____

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

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

Adjusted Processing Complexity (APC)

= .65 + (0.01 * Processing Complexity)

Total Adjusted Function Points (TAFP)

= Adjusted Processing Complexity * TUFP

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

Processing Complexity (PC): __7______

Adjusted Processing Complexity (PCA) = 0.65 + (0.01 * __7_ )

Total Adjusted Function Points (TAFP):_0.72 * _338_ = 243 (TUFP From Step 1)

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

Language LOC/Function Code PointCCOBOLJAVAC++Turbo PascalVisual BasicPowerBuilderHTMLPackages (e.g., Access, Excel)

130110 55 50 50 30 15 151040

Ví d : l p trình dùng C: s dòng l nh = 243x 130 = 31 590 dòngụ ậ ố ệ

s dòng l nhố ệ c l ng nhân l c (person-months)Ướ ượ ự

Mô hình: COSOMO

Effort = 1.4 * thousandsof(in Person linesofcodeM onths)

Example:

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

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

Ví d : d án 28 person months c n 9 tháng đ hoàn thànhụ ự ầ ể

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

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

Work Plan Information Example

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

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

Xác đ nh các công vi c chính trong các pha c a d án ị ệ ủ ự L n l t chia các công vi c chính thành các công vi c nh ầ ượ ệ ệ ỏ

Ph ng pháp chu nươ ẩ S d ng danh sách công vi c chu nử ụ ệ ẩ S d ng danh sách công vi c t các d án t ng t đã làmử ụ ệ ừ ự ươ ự

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

Phases Phases with high level steps

Work Plan Deliverables Estimated Assignedduration To

• Xác đ nh các công vi c c a d án dùng ph ng ị ệ ủ ự ươpháp Top-down: c u trúc chia nh công vi c WBS ấ ỏ ệ(Work Breakdown Structure) Xác đ nh các công vi c chínhị ệ Chia m i công vi c chính thành các công vi c nh ỗ ệ ệ ỏ

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

phân t ngầ Có th th c hi n WBS theo 2 cách:ể ự ệ

Theo các b c c a SDLCướ ủ Theo s n ph mả ẩ

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

• Bi u đ PERT (ể ồ PERT= Project Evaluation and Review Technique )Là cách bi u di n khác c a k ho ch công vi 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ờ ướ ượ

• Bi u đ PERTể ồ

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

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

• Xác đ nh s ng i cho d ánị ố ườ ự• Xây d ng k ho ch nhân s (staffing plan) li t kê ự ế ạ ự ệ

các v trí c n thi t cho d ánị ầ ế ự• Xác đ nh c c u t ch c c a d ánị ơ ấ ổ ứ ủ ự• Ch n ng i thích h p vào các v tríọ ườ ợ ị• Khích l , đ ng viên và đ nh h ng cho c nhóm đi ệ ộ ị ướ ả

t i m c tiêu c a d ánớ ụ ủ ự• Gi i quy t các xung đ t có th x y ra gi a các ả ế ộ ể ả ữ

thành viên

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

• Ch n ng i thích h p cho t ng v trí: ọ ườ ợ ừ ị2 tiêu chí:

K năng k thu t (technical skills)ỹ ỹ ậK năng giao ti p, ng x (interpersonal skills)ỹ ế ứ ử

N u không có s n ng i phù h p?ế ẵ ườ ợ

• Khích l đ ng viên các thành viên trong nhóm:ệ ộS d ng ti n th ng m t cách h t s c c n tr ngử ụ ề ưở ộ ế ứ ẩ ọS d ng các khích l tinh th n:ử ụ ệ ầ

Công vi c h p d n, thách th cệ ấ ẫ ứTinh th n trách nhi mầ ệNhu c u ti n thầ ế ủC h i đ h c k năng m iơ ộ ể ọ ỹ ớNhu c u t kh ng đ nh mìnhầ ự ẳ ịS thành cônngự

• Chi n l c đ gi i quy t xung đ t:ế ượ ể ả ế ộXác đ nh rõ ràng công vi c c a t ng thành viên trong ị ệ ủ ừ

nhómL 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ớ ự

3.2.5 Đi u ph i ho t đ ng d ánề ố ạ ộ ự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 (computer-ử ụ ụaided software engineering), chu n, tài li u đ c i thi n ẩ ệ ể ả ệvi c trao đ i thông tin và hi u qu c a d ánệ ổ ệ ả ủ ự

Qu n lý r i ro:ả ủ đánh giá r i ro và t đó có bi n pháp t i ủ ừ ệ ốthi u hoá r i roể ủ

• Tinh ch nh các giá tr c l ngỉ ị ướ ượ

Typical margins of Error for Welldone Estimates

Phase Deliverable Cost (%) time (%)

Planning System Request 400 60Project Plan 100 25

Analysis System Proposal 50 15

Design System Specification 25 10

• Qu n lý ph m vi d án (scope management)ả ạ ựScope creep: hi n t ng d án có nguy c kéo dài và ệ ượ ự ơ

t n chi phí h n d ki nố ơ ự ếNguyên nhân: thêm yêu c u m i cho h th ng sau khi ầ ớ ệ ố

ph m vi c a h th ng đã đ c gi i h nạ ủ ệ ố ượ ớ ạBi n pháp kh c ph c: ệ ắ ụ

Cách 1: tăng c ng g p g trao đ i v i ng i s d ng và xây ườ ặ ỡ ổ ớ ườ ử ụd ng nguyên m u đ tăng t c vi c đ nh rõ các yêu c u -> gi m ự ẫ ể ố ệ ị ầ ảđ c 5% nguy cượ ơ

Cách 2: s d ng k thu t h p th i gian (timeboxing)ử ụ ỹ ậ ộ ờ

• Timeboxing Steps1. Set the date for system delivery.

2. Prioritize the functionality that needs to be included in the system.

3. Build the core of the system (the functionality ranked as most important).

4. Postpone functionality that cannot be provided within the time frame.

5. Deliver the system with core functionality.

6. Repeat steps 3 through 5, to add refinements and enhancements.

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

Initiation Analysis Design Implementation

Upper CASE Lower CASE

Integrated CASE (ICASE)

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

process

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

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

• DocumentationProject binder: all deliverables and all the internal

communications within a projectTable of contents Continual updating

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

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

Actions to reduce riskRevised assessment

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

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

3.2.6 CD selections3.2.6 CD selections

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

4.1 Xác đ nh yêu c u c a h th ngị ầ ủ ệ ố4.2 Mô hình hoá ch c năngứ4.3 Mô hình hoá c u trúcấ4.4 Mô hình hoá ho t đ ngạ ộ

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

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

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

Mô hình c u trúcấ

Mô hình ch c năngứ

Mô hình ho t đ ngạ ộ

system proposal

Phân tích kh thiảK ho ch công vi cế ạ ệ

Thi t k h th ngế ế ệ ố

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

4.1.1 Xác đ nh yêu c uị ầ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 ninhyêu c u v văn hoá, chính trầ ề ịYêu c u không ch c năng đ c dùngầ ứ ượ

ch y u t i b c thi t k h th ngủ ế ạ ướ ế ế ệ ố

• Tài li u đ nh nghĩa yêu c u (requirement ệ ị ầdefinition):Là văn b n li t kê các yêu c u ch c năng và yêu c u ả ệ ầ ứ ầ

không ch c năngứCung c p đ u vào cho các b c ti p theo trong quá ấ ầ ướ ế

trình phân tích h th ng cũng nh quá trình thi t kệ ố ư ế ếM c đích quan tr ng nh t c a tài li u đ nh nghĩa yêu ụ ọ ấ ủ ệ ị

c u là đ nh nghĩa ph m vi c a h th ngầ ị ạ ủ ệ ố

• Xây d ng tài li u đ nh nghĩa yêu c uự ệ ị ầXác đ nh các lo i yêu c u ch c năng và không ch c ị ạ ầ ứ ứ

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

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

thay đ i và hoàn thi n các yêu c u thu th p đ c và ổ ệ ầ ậ ượxác đ nh m c đ quan tr ng c a các yêu c uị ứ ộ ọ ủ ầ

4.1.2 Các k thu t phân tích yêu c uỹ ậ ầ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:ỹ ậ ầ1. Business process automation (BPA): t đ ng hoá quá trình ự ộ

kinh doanh

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

3. Business process reengineering (BPE)

• 3 b c trong quá trình phân tích yêu c u:ướ ầ1. Phân tích tình tr ng c a h th ng hi n t i ạ ủ ệ ố ệ ạ2. Xác đ nh chính xác nh ng c i ti n có th th c hi nị ữ ả ế ể ự ệ3. Xây d ng yêu c u c a h th ng c n xây d ngự ầ ủ ệ ố ầ ự

• Business process automation (BPA): t đ ng hoá ự ộquá trình kinh doanh Không làm thay đ i ho t đ ng hi n t iổ ạ ộ ệ ạ T đ ng hoá m t s công vi c dùng công ngh máy ự ộ ộ ố ệ ệ

tính 2 k thu t BPA ỹ ậ

Phân tích v n đ (problem analysisấ ề ): xác đ nh các v n đ ị ấ ềtrong h th ng hi n t i và tìm cách gi i quy t chúng trong h ệ ố ệ ạ ả ế ệth ng m iố ớ

Phân tích nguyên nhân g c (root cause analysis)ố : phân tích nguyên nhân gôc c a v n đủ ấ ề

• Business process improvement (BPI): c i ti n quá ả ếtrình kinh doanh Làm thay đ i ho t đ ng hi n t iổ ạ ộ ệ ạ C n thi n đ c hi u su t và hi u qu c a h th ngả ệ ượ ệ ấ ệ ả ủ ệ ố T p trung vào h th ng m i đ c i ti nậ ệ ố ớ ể ả ế 3 ho t đ ng phân tích:ạ ộ

Phân tích kho ng th i gian (duration analysis):ả ờ phân tích chi ti t th i gian th c hi n m t khâu nào đó trong h th ng hi n ế ờ ự ệ ộ ệ ố ệt i và xác đ nh khâu có th đ c c i ti nạ ị ể ượ ả ế

Xác đ nh chi phí các ho t đ ng (activity based costing): ị ạ ộ xác đ nh chi phí c a t ng khâu trong h th ng hi n t i và xác ị ủ ừ ệ ố ệ ạđ nh các khâu có chi phí cao nh t và t đó c i ti n đ gi m ị ấ ừ ả ế ể ảchi phí

Nghiên c u kinh nghi m bên ngoài (informal benchmarking):ứ ệ nghiên c u cách t ch c kinh doanh c a các t ch c khác đ ứ ổ ứ ủ ổ ứ ểcó th rút ra đ c bài h c đ c i ti nể ượ ọ ể ả ế

• Business process reengineering (BPR): thay đ i ổquá trình kinh doanh Làm thay đ i c b n ho t đ ng hi n t iổ ơ ả ạ ộ ệ ạ 3 ho t đ ng phân tích:ạ ộ

Phân tích k t qu (outcome analysis):ế ả t p trung phân tích các ậk t qu c a h th ng có đem l i giá tr cho khách hàng. Nhà ế ả ủ ệ ố ạ ịphân tích khuy n khích các nhà qu n lý d án đ t mình vào v ế ả ự ặ ịtrí c a khách hàng và suy nghĩ c n th n v nh ng gì mà s n ủ ẩ ậ ề ữ ảph m và d ch v c a mình có th đem đ n cho khách hàng.ẩ ị ụ ủ ể ế

Phân tích công ngh (technology analysis): ệ Xác đ nh danh ịsách nh ng công ngh quan tr ng và h p d n t đó phân tích ữ ệ ọ ấ ẫ ừkh năng ng d ng công ngh vào ho t đ ng kinh doanh và ả ứ ụ ệ ạ ộl i ích c a vi c ng d ng công ngh đóợ ủ ệ ứ ụ ệ

Lo i b ho t đ ng (activity elimination)ạ ỏ ạ ộ : nhà phân tích và nhà qu n lý cùng tìm cách lo i b các ho t đ ng trong ho t đ ng ả ạ ỏ ạ ộ ạ ộkinh doanh, phân tích h u qu cũng nh nh h ng c a vi c ậ ả ư ả ưở ủ ệlo i b đóạ ỏ

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

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

4.1.3 Các k thu t thu th p yêu c uỹ ậ ậ ầ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)

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

• Ph ng v n (Interviews): ỏ ấ B c 1 Ch n ng i ướ ọ ườđ c ph ng v nựơ ỏ ấ D a vào các thông tin c n thu th pự ầ ậ Ch n ng i đ c ph ng v n các v trí khác nhau đ ọ ườ ựơ ỏ ấ ở ị ể

có thông tin t nhi u góc đ :ừ ề ộ Ng i qu n lýườ ả Ng i s d ngườ ử ụ Nh ng ng i có nh h ng ho c b nh h ng b i h th ng ữ ườ ả ưở ặ ị ả ưở ở ệ ố

m i (stakeholder)ớ

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

• Ph ng v n (Interviews): ỏ ấ B c 2 : thi t k câu h i ướ ế ế ỏph ng v n, 3 lo i:ỏ ấ ạ

Types of Questions ExamplesClosedEnded Questions * How many telephone orders

are received per day?* How do customers place orders?* What additional information would you like the new system to provide?

OpenEnded Questions * What do you think about the current system?* What are some of the problems you face on a daily basis? * How do you decide what types of marketing campaign to run?

Probing Questions * Why?

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

• Ph ng v n (Interviews): ỏ ấ B c 2 : thi t k câu h i ướ ế ế ỏph ng v n, 2 lo i ph ng v nỏ ấ ạ ỏ ấ Ph ng v n không c u trúc (Unstructured interview)ỏ ấ ấ

Các thông tin chung, khái quát Th c hi n t i các b c đ u tiên c a d ánự ệ ạ ướ ầ ủ ự

Ph ng v n có c u trúc (Structured interview)ỏ ấ ấ Các thông tin c th h nụ ể ơ Th c hi n t i các b c sau c a d ánự ệ ạ ướ ủ ự

• Ph ng v n (Interviews): ỏ ấ B c 2 : thi t k câu h i ướ ế ế ỏph ng v n, 2 chi n l c: top-down, bottom upỏ ấ ế ượ

• Ph ng v n (Interviews): ỏ ấ B c 3: chu n b cho ướ ẩ ịcu c ph ng v nộ ỏ ấ Chu n b k ho ch ph ng v n t ng thẩ ị ế ạ ỏ ấ ổ ế

Li t kê các câu h iệ ỏ D đoán tr c câu tr l i và câu h i ti p theoự ướ ả ờ ỏ ế

Kh ng đ nh l i lĩnh v c ki n th cẳ ị ạ ự ế ứ Xác đ nh các câu h i, lĩnh v c u tiên trong tr ng ị ỏ ự ư ườ

h p không đ th i gianợ ủ ờ Chu n b cho ng i đ c ph ng v nẩ ị ườ ượ ỏ ấ

X p l chế ị Thông báo lý do ph ng v nỏ ấ Thông báo các lĩnh v c th o lu nự ả ậ

• Ph ng v n (Interviews): ỏ ấ B c 4: th c hi n cu c ướ ự ệ ộph ng v nỏ ấ Ph i gây đ c thi n c m v i ng i đ c ph ng v n: ả ượ ệ ả ớ ườ ượ ỏ ấ

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

công vi c ti p theo sau cu c ph ng v nệ ế ộ ỏ ấ K t thúc đúng giế ờ

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

• Ph ng v n (Interviews): ỏ ấ B c 5: Công vi c sau ướ ệph ng v nỏ ấ Chu n b báo cáo v cu c ph ng v n trong vòng 48 ẩ ị ề ộ ỏ ấ

ti ngế G i báo cáo cho ng i đ c ph ng v n đ s a ch a, ử ườ ượ ỏ ấ ể ử ữ

b sung n u c nổ ế ầ

• Ph ng v n (Interviews): ỏ ấ B c 5: Công vi c sau ướ ệph ng v nỏ ấ

INTERVIEW REPORT

Interview notes approved by: ____________

Person interviewed ______________Interviewer _______________Date _______________Primary Purpose:

Summary of Interview:

Open Items:

Detailed Notes:

• JAD: Allows project managers, users, and developers to

work together to identify requirements May reduce scope creep by 50% Avoids requirements being too specific or too vague

• JAD: L a ch n ng i tham d và vai trò t ng ự ọ ườ ự ừng iườ Facilitator

sets the meeting agenda and guides the discussion

Scribe assist the facilitator by recording notes, making copies, etc.

Project team, users, and management

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

• JAD: phiên h p JADọ Tend to last 5 to 10 days over a three week period Prepare questions as with interviews Formal agenda and groundrules Facilitator activities

Keep session on track Help with technical terms and jargon Record group input Help resolve issues

Post-session follow-up

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

• JAD: Phòng h pọ

• Đi u tra (Questionnaire), các b c:ề ướ Selecting participants

Using samples of the population Designing the questionnaire

Careful question selection Administering the questionnaire

Working to get good response rate Questionnaire follow-up

Send results to participants

• Đi u tra (Questionnaire),ề thi t k :ế ế Begin with non-threatening and interesting questions. Group items into logically coherent sections. Do not put important items at the very end of the

questionnaire. Do not crowd a page with too many items. Avoid abbreviations. Avoid biased or suggestive items or terms. Number questions to avoid confusion. Pretest the questionnaire to identify confusing

questions. Provide anonymity to respondents.

• Phân tích tài li u:ệ Document analysis is used to provides clues about

existing “as-is” system Typical documents used

Forms Reports Policy manuals Organization chart

Look for user additions to forms Look for unused form elements

• Quan sát: Users/managers often don’t remember everything they

do Checks validity of information gathered other ways Behaviors change when people are watched Careful not to ignore periodic activities

Weekly … Monthly … Annual

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

Requirement Determination• Requirement Analysis Techniques

Select BPI techniques to identify how to improve the current order process using a new web-based system

Using several JAD session including store managers, marketing analysts and Wed developers (the working group) to work through BPI techniques and brainstorm

Further apply informal benchmarking with Web-sites of several leading retailers and discuss with the working group

The output is a list of suggested business requirements for the project team

Requirement Determination• Requirement-gathering Techniques

The project team applies document analysis, interview and observation techniques

Firstly apply document analysis to understand the current order processes (i.e., the as-is system). If anything is not clear, use interview to clarify

Secondly interview senior analysts to get better ideas about as-is and to-be systems and IT contractor to understand the existing IT system

Thirdly observe in stores to see the real working process of as-is system

• The above activities at the end produces the requirement definition (report)

• Further JAD sessions are used to finalise and prioritise the requirement definition (report)

4.2 Mô hình hoá ch c năngứ4.2 Mô hình hoá ch c năngứ(Functional Modeling)(Functional Modeling)

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

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

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

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

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

• B c 4: Chuy n t b n mô t ca s d ng sang ướ ể ử ả ả ử ụbi u đ ca s d ng đ bi u di n ch c năng và ể ồ ử ụ ể ể ễ ứho t đ ng bên ngoài c a quá trình kinh doanhạ ộ ủ

• -> chuy n sang mô hình hoá c u trúc (ph n 4.3)ể ấ ầ

4.2.2 Mô hình quá trình kinh doanh b ng bi u ằ ể4.2.2 Mô hình quá trình kinh doanh b ng bi u ằ ểđ ho t đ ng (activity diagrams)ồ ạ ộđ ho t đ ng (activity diagrams)ồ ạ ộ

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

• Bi u đ ho t đ ng đ c dùng đ mô hình hoá các quá ể ồ ạ ộ ượ ểtrình kinh doanh m c cao (high level business process)ở ứ

• Các ph n t c a bi u đ ho t đ ngầ ử ủ ể ồ ạ ộ Hành đ ng (action)ộ

Là ph n t đ n gi n bi u di n m t ho t đ ng không th chia nh ầ ử ơ ả ể ễ ộ ạ ộ ể ỏh 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ể ể ễ ậ ợ ộ

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ủ ố ố ượ ớ ủ ố ượ

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

Make appointment

Class name

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

Bi u di n lu ng c a 1 đ i t ng t ho t đ ng này sang ho t ể ễ ồ ủ ố ượ ừ ạ ộ ạđ ng khácộ

N t kh i đ u (initial node)ố ở ầBi u di n đi m b t đ u c a t p h p các ho t đ ngể ễ ể ắ ầ ủ ậ ợ ạ ộ

N t k t thúc ho t đ ng (final activity node)ố ế ạ ộK t thúc toàn b các lu ng đi u khi n và lu ng đ i t ngế ộ ồ ề ể ồ ố ượ

N t k t thúc lu ng (final flow node)ố ế ồK t thúc m t lu ng đi u khi n ho c lu ng đ i t ngế ộ ồ ề ể ặ ồ ố ượ

• Các ph n t c a bi u đ ho t đ ng (ti p theo)ầ ử ủ ể ồ ạ ộ ếN t l a ch n (decision node)ố ự ọ

Bi u di n vi c ki m tra đi u ki n đ đ m b o lu ng đi u ể ễ ệ ể ề ệ ể ả ả ồ ềkhi n ho c lu ng đ i t ng ch đi theo 1 đ ngể ặ ồ ố ượ ỉ ườ

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

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

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

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

N t k t h p (join node)ố ế ợDùng đ k t h p các lu ng ho t đ ng song songể ế ợ ồ ạ ộ

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

1. Xác đ nh ph m vi và ng c nh c a quá trình kinh ị ạ ữ ả ủdoanh r i đ t cho bi u đ ho t đ ng 1 tiêu đ phù ồ ặ ể ồ ạ ộ ềh pợ

2. Xác đ nh các ho t đ ng, lu ng đi u khi n, lu ng đ i ị ạ ộ ồ ề ể ồ ốt ng di n ra gi a các ho t đ ng. ượ ễ ữ ạ ộ

3. Xác đ nh các quy t đ nh l a ch n trong quá trình kinh ị ế ị ự ọdoanh

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

5. V bi u đ ho t đ ngẽ ể ồ ạ ộ

• VD: CD selectionsInternet Order System – Functional requirements:1. Maintain CD Information

1.1…… 1.2….. 1.3…..1. Maintain CD marketing information

2.1…. 2.2…. 2.3….1. Place CD Orders

3.1 Search CDs from “CD Selection” web site; 3.2 Place orders;

3.3……1. 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

• VD: CD selectionsExercise: Create the activity diagram for Internet

Order System

Analysis: Main activities: Maintain CD Information, Maintain CD

marketing information, Place CD Orders, Maintain ordered CDs

Control flows: Three main parallel processes: Maintain CD Information Maintain CD marketing information Place CD Orders -> Maintain ordered CDs in which a decision

needs to be made related to placing instore hold or placing special order

• VD: CD selections

Place CD Order

Maintain CD marketing

information

Maintain CD Information

Place instore hold

Place special order

[If available in near store] [If not]

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

Ca s d ng miêu t t ng tác gi a ng i s d ng và h ử ụ ả ươ ữ ườ ử ụ ệth ngố

• 2 b c đ xây d ng bi u đ ca s d ngướ ể ự ể ồ ử ụ Vi t b n mô t ca s d ng ế ả ả ử ụChuy n t b n mô t ca s d ng sang bi u đ ca s ể ừ ả ả ử ụ ể ồ ử

d ngụ

• M i m t ca s d ng ch miêu t duy nh t m t ỗ ộ ử ụ ỉ ả ấ ộch c năng c a h th ng ứ ủ ệ ố

• Đ xác đ nh n i dung c a ca s d ng, ng i phát ể ị ộ ủ ử ụ ườtri n h th ng ph i làm vi c cùng v i ng i s ể ệ ố ả ệ ớ ườ ửd ngụ

• Các thành ph n c a b n mô t ca s d ng:ầ ủ ả ả ử ụ

Use Case Name: ID: Importance Level:

Primary Actor: Use Case Type:

Stakeholders and Interests:

Brief Description:Trigger:Relationships: (Association, Include, Extend, Generalization)

Normal Flow of Events:

Subflows:

Alternate/Exceptional Flows:

• Ví d : ụ

• Guidelines for Creating Use-Case Descriptions1. Write each step in “SVDPI (subject-verb-direct

object and optionally preposition-indirect object)” form

Example. “The patient (subject) contacts (verb) the office (direct object) regarding (preposition) an appointment (indirect object).

1. Clarify initiator and receivers of action2. Write from independent observer perspective3. Write at same level of abstraction4. Ensure a sensible set of steps5. Apply KISS (keep it simple, stupid) principle liberally6. Write repeating instructions after the set of steps to

be repeated.

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

An Actor

A use case

A Subject Boundary

An associate relationship

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

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

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

đích c a các tác nhân đóủ4. Xác đ nh và vi t các ca s d ng chính ị ế ử ụ5. Xem xét l i c n th n các ca s d ng và s a đ i n u ạ ẩ ậ ử ụ ử ổ ế

c nầ

• B c I: Ví dướ ụ

Review activity diagram of Internet order System:

Place CD Order

Maintain CD marketing

information

Maintain CD Information

Maintain CD Order

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

Use case name Primary actor Relationship

Association Include Exclude

Maintain marketing information

Vendor Vendor

Maintain CD information

Distribution system

Place order Customer Customer Maintain order

Maintain order Customer

• B c II (5 b c nh ): M r ng ca s d ng chínhướ ướ ỏ ở ộ ử ụ1. Ch n 1 ca s d ng chính đ m r ng ọ ử ụ ể ở ộ

2. Đi n các chi ti t vào form ề ế

3. Đi n các b c c a lu ng s ki n bình th ng ề ướ ủ ồ ự ệ ườ(normal flow of events)

4. 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)ặ ư ử ụ

5. Miêu t các b c thay th ho c ngo i l ả ướ ế ặ ạ ệ(alternate/exceptional)

6. V i m i b c thay th ho c ngo i l , miêu t cách ớ ỗ ướ ế ặ ạ ệ ảth c mà tác nhân (actor) và h th ng đáp ngứ ệ ố ứ

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

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

• 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ượ ị

• B c IV (4 b c nh ): V bi u đ ca s d ngướ ướ ỏ ẽ ể ồ ử ụ1. V gianh gi i c a h th ngẽ ớ ủ ệ ố2. V các ca s d ng (v theo th t d nhìn)ẽ ử ụ ẽ ứ ự ễ3. V các tác nhânẽ4. V các quan hẽ ệ

Use case name Primary actor Relationship

Association Include Extend

Maintain marketing information

Vendor Vendor

Distribution system

Place order Customer Customer Check out Maintain order

Check out Customer Customer, Credit Centre

Maintain order

Maintain order Customer Place Instore hold

Place special order

Place Instore hold Customer Store

Place special order Customer Store

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

below, draw the corresponding use-case diagram

Maintain CD marketing information

Maintain CD order

Place CD order

Place instore hold

Place special order

<<include>>

<< extend >> <<actor>>Store

<<actor>> Distribution

System

Check out

<<include>>

<<actor>> Credit Card Centre

4.3 Mô hình hoá c u trúcấ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ự ẻ ể ồ ớ

M c đích c a mô hình c u trúc: ụ ủ ấ• Mô t c u trúc c a d li u đ c s d ng trong h ả ấ ủ ữ ệ ượ ử ụ ệ

th ng.ố• Rút ng n kho ng cách gi a th gi i th c và th ắ ả ữ ế ớ ự ế

gi i ph n m mớ ầ ề• Xây d ng thu t ng chung cho ng i s d ng và ự ậ ữ ườ ử ụ

ng i phân tích h th ng ườ ệ ố• Bi u di n s v t, ý t ng và khái ni m quan tr ng ể ễ ự ậ ưở ệ ọ

trong h th ngệ ốCác mô hình c u trúc: ấ• CRC cards, class diagrams, object diagrams.

4.3.2 Các ph n t c a mô hình c u trúcầ ử ủ ấ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ữ ớ

4.3.2 Các ph n t c a mô hình c u trúcầ ử ủ ấ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ệ ữ ớ

4.3.3 Th CRC (Class-Responsibility-ẻ4.3.3 Th CRC (Class-Responsibility-ẻCollaboration)Collaboration)

• Trách nhi m (responsibility) và h p tác ệ ợ(collaboration)Trách nhi mệ

Đ i t ng c a m t l p ph i có trách nhi m: ố ượ ủ ộ ớ ả ệbi tế giá tr các thu c tính và các quan h c a nóị ộ ệ ủ th c hi nự ệ ho t đ ng c a nóạ ộ ủ

H p tác ợCác đ i t ng h p tác v i nhau đ th c hi n m t công vi 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ả ủ ộ ớ

4.3.4 Bi u đ l pể ồ ớ4.3.4 Bi u đ l pể ồ ớ

• Cú pháp:

A CLASS

AN ATTRIBUTE

AN OPERATION

AN ASSOCIATION

Class 1

attribute

+operation ()

Attribute name/derived attribute name

operation name ()

1..* 0..1______verb phrase____

• Thu c tính:ộDerived attributes

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

VisibilityPublic: +Protected: #Private: -

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

Creates object

QueryMakes information about state available

UpdateChanges values of some or all attributes

• Quan h :ệMultiplicity of relationship

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

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

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

Three common approaches1. Textual analysis of use-case information to create

an initial rough structure model Nouns suggest classes Verbs suggest operations Creates a rough(tr ng thái thô ban đ u) first cutạ ầ

2. Common object list Physical or tangible things Incidents Roles

3. Patterns Useful groupings of classes that occur in various

situations

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

• 2. Brainstorm additional candidate classes, attributes, operations, and relationships by using the common object list approach.

• 3. Role-play each use-case using the CRC cards.• 4. Create the class diagram based on the CRC cards.• 5. Review the class diagrams and structural model for

missing and/or unnecessary classes, attributes, operations, and relationships.

• 6. Incorporate useful patterns.• 7. Review the structural model.

CD Selections

Textual Analysis: Nouns suggest classes

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

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

Textual Analysis: Nouns suggest classes

Textual Analysis: Verbs suggest operations: • For each identified class, check the related verbs to identify the operations as

well as the relationships with other classes

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

Make Search request Search request

Select CD for Info

Place Order

CD List

Get Credit Card Info Exit

Order Credit Card Centre

This forms the front of “Customer class” CRC Card

Not include as it can be included in Search request

Textual Analysis: Verbs suggest operations:

• Textual Analysis Result: Combine “nouns and verbs” analysis, the back of “Customer class” CRC Card can be

Order; Search request; Credit Card Centre

Step 2 and 3. Examine Common Object Lists and Step 2 and 3. Examine Common Object Lists and Role-play the CRC CardsRole-play the CRC Cards

1. Brainstorm additional candidate classes, attributes, operations, and relationships by using the common object list approach.

2. Roleplay each usecase using the CRC cards.

Possible outcomes: Search request class need having 3 subclasses: Title Search, Artist Search and Category Search

Step 4. Step 4. Create the Class Diagram based on the CRC Create the Class Diagram based on the CRC CardsCards

• Exercise. Suppose the CRC card of Customer class is given as before, create the class diagram based on it. • For customer class, assume that all attributes are

private type whereas all operations are public type• For other associate classes, only the class names

and the relationships with the customer class need to be given

Step 4. Step 4. Create the Class Diagram based on the CRC Create the Class Diagram based on the CRC CardsCards

• Solution:

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

Credit Card CentreOrder

Search Reg

Check >0..*

place >

Make >0..*0..*

Step 5, 6 and 7: Review Classes Diagrams, Step 5, 6 and 7: Review Classes Diagrams, Incorporate Patterns, and Review the ModelIncorporate Patterns, and Review the Model

1. Review the class diagrams and structural model for any missing and/or redundancy

2. Incorporate useful patterns.• One possible pattern

1. Review the structural model.

4.4 Mô hình hoá ho t đ ngạ ộ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ể ồ ạ

• M c đích c a mô hình ho t đ ng:ụ ủ ạ ộMiêu t cách th c các đ i t ng trong mô hình c u trúc ả ứ ố ượ ấ

t ng tác v i nhau trong m i ca s d ng ươ ớ ỗ ử ụMiêu t ho t đ ng bên trong c a h th ng ả ạ ộ ủ ệ ốMiêu t nh h ng c a các ho t đ ng t i h th ng ả ả ưở ủ ạ ộ ớ ệ ốĐ c s d ng đ ki m tra và thay đ i các mô hình ượ ử ụ ể ể ổ

ch c năng và mô hình c u trúc ứ ấ

• Các lo i mô hình ho t đ ng:ạ ạ ộBi u đ t ng tác (Interaction Diagrams)ể ồ ươ

Bi u đ tu n t (sequence diagram)ể ồ ầ ựBi u đ giao ti p (c ng tác) (communication diagram)ể ồ ế ộ

Bi u đ máy tr ng thái (Behavioral state machine ể ồ ạdiagram)

4.4.2 Bi u đ t ng tácể ồ ươ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 ỉ ị ố ượ ự ệ ộ ạ ộ

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

t ng trong 1 ca s d ngượ ử ụ

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

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

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

trên m i đ ng s ng c a đ i t ngỗ ườ ố ủ ố ượ6. Ki m tra l i bi u để ạ ể ồ

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

Application Example:

• Bi u đ giao ti p (communication diagram)ể ồ ếT p trung miêu t t ng tác gi a các đ i t ng mà ậ ả ươ ữ ố ượ

không t p trung vào miêu t th i gian và trình t c a ậ ả ờ ự ủcác t ng tácươ

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

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

Object

Association

Message

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

Technique to Identify Collaborations between Technique to Identify Collaborations between Objects - “CRUD” AnalysisObjects - “CRUD” Analysis

• What is “CRUD” analysis: identifying the processes to Create, Read or Reference, Update or Delete

objects based on use cases The process of each user case is represented by “CRUD” matrix: a class-

by-class matrix in which each cell in the matrix represents the interaction between instances of the classes

““CRUD” Analysis ExampleCRUD” Analysis Example

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

Application Example:

4.4.3 Bi u đ máy tr ng tháiể ồ ạ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.ộ ủ ố ượ ể ạ

Ví d :ụ

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

• Transitions: A transition indicates a movement from one state to the next one, denoted by lines with arrowheads. A transition has a label in the form of three parts: Event [guard]/activity. All three parts are optional. Event or Trigger: the signal event that triggers a potential change of state Guard: If presented, is a Boolean condition that must be true in order for the trigger

to cause the transition

Action or Activity: is some behaviour that has executed during the transition

stateEvent [guard]/activity

transition

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

• 5 b c xây d ng bi u đ máy tr ng thái:ướ ự ể ồ ạ1. Xác đ nh ng c nhị ữ ả2. Xác đ nh tr ng thái b t đ u, k t thúc và các tr ng thái ị ạ ắ ầ ế ạ

n đ nh c a đ i t ng ổ ị ủ ố ượ3. Xác đ nh th t c a các tr ng thái mà đ i t ng s ị ứ ự ủ ạ ố ượ ẽ

tr i qua ả4. Xác đ nh các s ki n, hành đ ng và đi u ki n c a m i ị ự ệ ộ ề ệ ủ ỗ

chuy n tr ng thái ể ạ5. Ki m traể

The Life of an Order Object:

Ch ng 5. Thi t k h th ngươ ế ế ệ ốCh ng 5. Thi t k h th ngươ ế ế ệ ố

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

5.1 Chuy n sang thi t kể ế ế5.1 Chuy n sang thi t kể ế ế

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

5.1.2 Gói và Bi u đ góiể ồ5.1.3 Các chi n l c thi t kế ượ ế ế5.1.4 Xây d ng thi t k th c tự ế ế ự ế

• Factoring: Creating modules* that reflect similarities and differences

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

New classes can be represented by:- GeneralizationAggregation

New classes identified by:

Abstraction

e.g. classes for nurse, admin and doctor share attributes and methods, so “factor our” common attributes and methods, create new class “employee”, relate employee to nurse, admin and doctor classes as generalisation (a-kind-of) relationship – a form of abstraction

Refinement

Identifying additional subclasses (of a higher level class) is a form of refinement

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

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

componentsIn object-oriented designs/implementations the “pattern of

activity”, i.e. messages sent between objects, provides one basis for partitioning system into (smaller-scale) subsystems (where subsystem = partition)

Grouping units that collaborate e.g. as modelled in UML communications diagram (for each use-case), CRUD analysis, clients(i.e. objects that are message senders)-servers(i.e. objects that receivemessages) & contracts (i.e. specifications of interactions between objects)

May have collaboration among units (e.g. a class) or partitions (i.e. collections/sets of classes whose objects send/receive messages)

The more messages or contracts between objects, the more likely they are in the same partition

• Layers A system’s environment includes software architecture, user

interface and stored data Layer enables useful separation of (related) concerns, e.g.

application logic from user-interface considerations Model-view-controller (MVC) architecture

• Models implement application logic• Views and controllers manage interfaces• Views = output logic• Controllers = input logic• Models = application logic• Suggested layers now include foundation, physical, HCI, data access and

management, problem domain. n.b. layer constrains kind(s) of classes that exist “on that layer”

• Foundation = programming language and IDE constructs• Physical architecture = classes used for communication• HCI = classes enabling user interaction• Data access and management = classes for persistence• Problem domain = classes to be refined into implementable (effective and

efficient)

• Layers

5.1.2 Gói và bi u đ góiể ồ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 higherlevel element Packages involving different kinds of construct (e.g. at particular layers) use different kinds of relationship between those constructs, i.e. in a class diagram, package = group (or set) of classes by aggregation or association relationship

• Also need “dependency” relationships between packages • A UML package diagram can be a class diagram that contains

only package symbols and dependency relationships (dotted arrows)

• Package symbol is similar to tabbed folder symbol

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

A PACKAGE Package

A DEPENDENCY RELATIONSHIP

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

Collaborations, partitions and layersCollaborations, partitions and layers Collaborations usually are modelled as packages in UML

Collaborations usually factored into a set of partitions on a layer

Partitions can be composed of other partitions (hierarchically hence forming subsystems)

Classes can be in partitions, those partitions then contained in other partitions, placed on a layer

Simple example:- small part of appointments system

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

Package Diagram of Appointment SystemPackage Diagram of Appointment System

Patient UI

dependent on Patient class

DMPatient class

Patient table

Problem domain Classes:Patient, Appt.

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

by intermediate Data Access and Manipulation (DM) Classes:DMPatient, DMAppt

Modularity (information hiding and encapsulation again) simplifies maintenance (changes are encapsulated within “module boundary”) and increases reusability (module’s interface defines messages that can be responded to, module can be used/reused “as is” or adapted for other uses

Steps for Identifying Packages and Building Package DiagramsSteps for Identifying Packages and Building Package Diagrams

• Set the context

• Cluster classes together based on shared relationships

• Model clustered classes as a package

• Identify dependency relationships among packages

• Place dependency relationships between packages

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

Step 1: Set the context, i.e. model a partition or a layer, e.g. for appointments system we might choose

context = problem domain (PD) layer

288/Chapter© DHBK 2007Step 2: Cluster classes together based on shared relationships, i.e. form partitions using relationships (generalisation, aggregation, kinds of association and message passing between objects) shared by classes

Examine analysis modelsClass Diagram Sequence Diagram(s)

Communication Diagram(s)

Classes in a generalisation hierarchy put in a single partition

Step 3: Place clustered classes in partition and model clustered classes as a Step 3: Place clustered classes in partition and model clustered classes as a package, i.e. model package, i.e. model partitionspartitions as as packagespackages

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

a) association relationship between Person Pkg and Appt. Pkg via Association between Doctor class and Appt. class and Patient Pkgcontained in Person Pkg

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

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

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

PD LayerAppt. Package

Treatment Package

Person Package

Patient Package

292/Chapter© DHBK 2007 Worked Example: Applying Concepts at CD Selections: First, previous Worked Example: Applying Concepts at CD Selections: First, previous lectures...lectures...

• Chapter 5: Functional and Non-functional Requirements

• Chapter 6: Functional Model = activity diagram + use-case descriptions & diagrams

• Chapter 7: Structural Model = CRC cards + class diagram

• Chapter 8: Behavioural Models for “Places Order” use-case + “Order” class (sequence diagram, communication diagram, behavioural state machine)

• Next: Create package diagram for CD Selections

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

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

CD Selections Class Diagram (Places Order UseCase View)

Sequence Diagram (Places Order Use Case)

Communication Diagram (Place Order Use Case)

cluster Customer, Individual and Organisation(al) classes into partition

• Aggregation relationships = cluster Mkt Info, Review, Artist Info, Sample Clip classes into partition

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

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

• Recall, cluster Mkt Info, Review, Artist Info, Sample Clip classes into partition

• Order Class and Order Item Class = partition

• Search Req Class and CD List Class = partition

n.b. Credit Card Centre not yet contained in a package

Identify dependency relationships between packages = Customer Package + Order Package, Customer Package + Search Package, Order Package + CD Package, Search Package + CD Package (also between Credit Card Centre + Customer package)

297/Chapter© DHBK 2007Place the dependency relations on the package diagram (and increase clarity by dependency Place the dependency relations on the package diagram (and increase clarity by dependency

relationships between packages = pure package diagram of PD layer of CD Selections containing relationships between packages = pure package diagram of PD layer of CD Selections containing highest level packages only (+ Credit Card Centre class) and their dependency relationshipshighest level packages only (+ Credit Card Centre class) and their dependency relationships

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

• Custom Development • Has potential for meeting highly specialized requirements

e.g. for CD selections, order taking process could be web-based, linking tightly with the existing distribution system,or, the technical environment may enforce constraint that all information systems are built using standard technology and interface designs (for consistency, ease of reuse)

• Has potential for greater flexibility and creativity in solving problemse.g. for CD selections, can use ordering “web interface” as strategic

enabler to better understand customer’s who order online, using technology to mine data obtained via custom applications

• Has potential to change componentse.g. for CD selections all components in custom application are available and can be reused in whole or part

• Usually increases personnel skillse.g. for CD selections, developers build technical skills and business

knowledge as they further evolve the system• Potentially requires significant resources• Potentially adds significant risk

• Packaged Software

Software already written – so available, “as is”For CD selections, could use “shopping cart” software installed

into existing web page Potentially more efficient, better tested (even proven!) - because

developers/implementors more skilled in techniques used to specify/design + implement, test (or even prove!)For CD selections, “shopping cart” is freely available “software

tool”, other simple components also available, e.g. ActiveX controls, Java “beans”, whole approach scales-up to Enterprise Resource Planning applications (ERP’s), e.g. SAP, Oracle

Functionality provided “as is” For CD selections, packed software may require change to

existing business practice, but could customise an order processing application, or “work around” via custom-built application that “wraps around” packaged software giving additional functionality

• Packaged Software (cont.)

Systems Integration: building new systems from combinations of packaged software, existing legacy systems and new custom developed software to integrate these together.

Problem is usually integrating data, different formats must be resolved

For CD selections, integrating data in new online order system with data in legacy distribution application may be problematic

Could develop “object wrapper” around legacy system (and its data) so that new object oriented web based ordering system can send messages to the “wrapper”

• Outsourcing – (now increasingly popular) = pay external vendor, developer, service provider to create system

For CD selections, use a Web Service Provider who provides commercial order taking system

Potentially external suppliers have higher level of skillTheir services MUST work to generate income, so web services

are built by “experts” with significant experience Is not “cost free” – lose absolute control over software and data,

inhouse expertise is not increased Only outsource what is properly understood in advance

Needs rigorous planning and analysis of needs in advance of contract negotiations, must identify vendor, developer or service provider with proven track record of success in system and supporting technology for system’s needs

Vendor choice and contract & payment method by strictly controlled criteriaTime and arrangement dealFixed priceValue added contract

• Outsourcing Guidelines

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

contractView outsourcing relationship as partnershipSelect outsource vender carefullyAssign person to manage relationshipDon’t outsource what you don’t understandEmphasize flexible requirements, long-term

relationships, and short-term contracts

• Select a strategy (1): Business need

Common business needs best served by packaged systems, i.e. when custom built alternative does not require any special business needs, when system is not critical to company

In-house experienceCustom application only feasible if sufficient in-house skills for

all functional and technical challenges, otherwise packaged system (possibly with in-house integration software added)

Project skillsTechnical, e.g. Java programming and IDE skills, data design

and SQL programming skillsFunctional, e.g. in electronic commerceIf electronic commerce is to become basis for company’s future

development, in-house skills in EC and technical skills in its exploitation must be further developed

Some skills, e.g. network security, might be operational issue which can be outsourced

• Select a strategy (2): Project management

Custom applications require significant project management via application of a proven system development methodology (or collection of integrated methods)

Packaged and outsourced systems require different kinds of management, e.g. of contract and delivery

Time frameIf time to meet business requirement(s) is limited (or short),

requirements are “standard” and well-defined, then packaged or outsourced most likely strategies, outsourced for standard, packaged for well-defined

5.1.4 Phát tri n thi t k th c tể ế ế ự ế5.1.4 Phát tri n thi t k th c tể ế ế ự ế

• Alternative Matrix

Combines several feasibility analyses into one grid Revisits technical, economic, and organizational feasibility Created using same steps as feasibility analysis (chapter 3), but combines several

analyses into a single matrix for comparison Matrix is represented by a grid

Contains technical, budget, organisational feasibilities for each candidate, pro’s and cons, other useful information, e.g. criticality, future-proofing

Sometimes “weights” are providedn.b. in AHP weights are derived (mathematically) from judgements over criteria

• Request For Proposal

Aids development of alternative matrix Description of the system you propose to be built Vendors, developers, service providers respond with proposals including how they

will address needs as well as stating cost and time requirements. Similar (less effort-intensive) Request For Information (RFI)

5.1.4 Phát tri n thi t k th c tể ế ế ự ế5.1.4 Phát tri n thi t k th c tể ế ế ự ế

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

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

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

• Coupling• Cohesion• Connascence

• Coupling: Indicates the interdependence or interrelationships of the modules

Interaction coupling Relationships with methods and objects through message passage

Inheritance coupling Deals with how tightly coupled the classes are in an inheritance hierarchy

Types of interaction coupling

• Interaction coupling: Law of Demeter = minimise number of objects that can receive

messages from a given object Objects only send message to:

A) ItselfB) An object an object “contained” in an attribute of itself (or an

object of one of its superclasses)C) An object passed as a parameter to the mehodD) An object created by the methodE) An object stored in a variable whose declaration scope is the

entire program (a “global” variable)

Coupling increase if:calling method passes attributes to called methodCalling method depends on value returned by called method

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

MethodClass Generalization/specialization

• Cohesion: Method cohesion:

Address the cohesion within an individual method. Methods should do one and only one thing

• Cohesion: Class cohesion:

Is the level of cohesion among the attributes and methods of a class A class should only represent one thingA cohesive class should:

Contain multiple methods that are visible outside the class Have methods that refer to attributes or other methods defined with the class or

its superclass Not have any control-flow coupling between its methods

• Cohesion: Class cohesion:

• Cohesion: Generalization/specialization cohesion:

Addresses the sensibility of the inheritance hierarchy

• Connascence: Two modules (classes or methods) are so intertwined, that if you

make a change in one, it is likely that a change in the other will be required

Connascence and encapsulationMinimize overall connascence by eliminating any unnecessary

connascence throughout the system,Minimize connascence across any encapsulation boundaries, such as

method boundaries and class boundaries, Maximize connascence within any encapsulation boundary.

• Connascence:

5.2.3 Các ho t đ ng thi t k đ i t ngạ ộ ế ế ố ượ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

• Additional specification:Ensure the classes are both necessary and sufficient for

the problemFinalize the visibility of the attributes and methods of

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

• Identifying opportunities for reuse:Analysis patterns

Representations of the problem-domain

Design patternsUseful grouping of collaborating classes that provide a solution

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

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

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

classes in the framework

Librariescomponents

• Identifying opportunities for reuse:Libraries

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

layerCan be used to:-

Create instances of classes in libraryCreate subclasses by inheritance, and then objects of subtype(s)Using inheritance again increases inheritance coupling and

ConnascenceDirectly instantiating class in library, object dependency created

between created object and library object due to signatures of methods in library object, i.e. increases interaction coupling between class library object and created object

• Identifying opportunities for reuse:Components:

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

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

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

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

frameworksUnless API changes between between version of component,

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

• Identifying opportunities for reuse:

• Restructuring the design: Factoring

Separate out shared aspects of a method or class into a new method or class

New class related to existing classes via inheritance, aggregation or association

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

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

generalization/specialization semantics

• Optimizing the designSimple optimisations make an existing design more

efficient, but must not make optimised design significantly more difficult to reason about, i.e. optimsation is a “trade-off” between efficiency and ease of understanding

the design optimisations below need to be considered. [1] access paths between objects[2] attributes of each class[3] direct and indirect “fan-out” of each method[4] execution order of statements[5] unnecessary recomputation

• Optimizing the design[1] access paths between objects

A message from one object to another may go though many intervening objects

If a) the path though the intervening objects is long and b) the message is sent frequently consider a “redundant path”, i.e. an additional attribute in the calling object that stores a direct connection to object at end of path

[2] attributes of each class If methods that use an attribute only read and update attribute and only

instances of a single class send those messages then attribute may belong to calling class.

[3] direct and indirect “fan-out” of each method Fan-out = number of messages sent by a method Direct Fan-out = number of messages sent by given method Indirect Fan-out includes number of messages sent by methods called by

other methods in a message tree If fan-out of a method significantly higher than other methods in a system

then should be optimised, e.g. add an index to attributes used to send messages to objects in message tree

• Optimizing the design[4] execution order of statements

In frequently used methods, order of statements may be non-optimal

Changing order should not affect result of computation Changing order can be more efficient, e.g. when searching, if one

attribute known to narrow search then search on that attribute first

[5] unnecessary recomputationDerived attributes (or active values) need not be recomputed until

attributes that are involved in its computation change, e.g. A) Add “trigger” to attributes in computation of derived attribute

and when any of those attributes change recompute derived attribute

B) Mark derived attribute and recompute only when it is next accessed

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

to implement those designse.g. UML class diagram is-a specification of a class in a class-

based OO programming language

Need to resolve any conflicts between constructs assumed in the design to be available in programming language but are not present in that language e.g.

[1] design uses multiple inheritance, language has only single inheritance

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

[3] language is of another (less expressive) language paradigm, e.g. C or Pascal are of the imperative-procedural paradigm

• Map Problem Domain Classes to Implementation Languages:

[1] design uses multiple inheritance, language has only single inheritanceA) Convert multiple inheritance relationships to “superclass”-

subclass association relationshipsIf additional superclasses are concrete (objects of the class can

be instantiated) then multiplicity from superclass to subclass is 0..1

Otherwise multiplicity is 1..1Add an exclusive-OR constraint between associationsAdd appropriate methods to ensure all information remains

available to existing class B) Copy ALL the attributes and methods of the additional

superclasses to ALL the subclassess and remove additional superclass from the design

SuperClass1-attribute1-attribute2

Class1-attribute5-attribute6

concrete

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

Class1

-attribute5-attribute6

Class2

PotentialInheritanceConflicts

abstract

[2] implementation language is object-based and not class-basedNeed to factor out ALL uses of inheritance from problem-domain

class design

All superclasses concrete

{XOR}1..11..1

1..11..1

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

Class1

Class2

If all superclasses areabstract

PotentialInheritanceConflicts

[3] language is of another (less expressive) language paradigm, e.g. C or Pascal are of the imperative-procedural paradigmStay away from this!But if necessary, factor out all uses of

PolymorphismDynamic bindingEncapsulation Information hiding

5.2.4 Ràng bu c và giao kèoộ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

• Pre- and post-conditions model constraints on individual methods

• Invariants model constraints (that must always be true) for all instances of a class, e.g.Domains (in DB) or types (in design/programming

language) of attributesMultiplicity of attributesLegal values of attributes including attributes that model

association and aggregation and relationshipse.g. if association relationship is required, invariant is

created to enforce relationship to have valid value for instance to exist

• Invariants usually attached to the class, e.g. CRC cards or class diagrams as a set of assertions

• Example:-

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

Date (1..1) (Date)Sub Total (0..1) (double)Tax (0..1) (double) {Sub Total = sum(Product Order.GetExtension())}Shipping(0..1) (double)Total (0..1) (double)Customer (1..1) (Customer)Cust ID (1..1) (unsigned long) (Cust ID = Customer.GetCustID()}State (1..1) (State)StateName (String) {State Name = State.GetState()}

Relationships:Generalisation(akindof):

Aggregation (hasparts):

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

Attribute Constraint:Order Number IS unsigned long

Attribute Constraint:Customer IS INSTANCE OFCustomer Class

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

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

Invariants On a Class Diagram(Not recommended

– Use CRC card for Invariants)

OrderOrder Number: unsigned longDate[1..]: DateSub Total[0..1]: doubleTax[0..1]:doubleShipping[0..1]:doubleTotal[0..1]doubleTax[0..1]: doubleCustomer[1..1]: CustomerCust ID[1..1]: unsigned longState[1..1] StateState Name[1..1: String

CustomerCust IDLast NameFirst Name

1..1 0..*

ProductProduct NumberProduct DescPrice0..* 1..*

StateTax RateProduct Desc

0..* 1..1

Product OrderOrderProductQuantityExtension

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

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

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

*SubTotal}

<<invariant>>{Sub Total=

Sum(Product Order.GetExtension())}}

• Contract: Contracts document message passing between objects, i.e.

messages sent to server objects by implementor’s client object, and values returned by server

Ideally a contract for each message sent and received by each object, i.e. one contract per interaction

In practice, one contract for each method that can receive messages from other objects, i.e. each visible method

Contracts are declarative = documents for client object’s implementor what the method doesMethod name, class name, ID number, client objects, associated use

cases, description, arguments received, type of reurn value, pre- and post-conditions

Does NOT contain details of how method works i.e. not procedural

Specific Method OF specific ClassUnique Contract ID

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

this method where method isused to realise implementation of the use case (from server class’s CRC card and associateduse cases)

What the method does NOT how it does it

types of parameters passed

type of value returned to its clients

= method signature

5.2.5 Xác đ nh ph ng th cị ươ ứ5.2.5 Xác đ nh ph ng th cị ươ ứ

• General information• Events• Message passing

• Algorithm specificationStructured EnglishPseudocodeUML activity diagram

Method Name Class Name ID:

Contract ID Programmer: Date Due:

Programming Language: Visual Basic SmallTalk C++ Java

Triggers/Events

Arguments Received: Data Type:

Notes:

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

Argument Returned: Data Type:

Notes:

Algorithithm Specification:

General Information (for managing programming effort)

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

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

• Structured English will suffice for algorithm specification…

Algorithm Specification:Action Statement Examples: Profits = Revenues – Expenses

Generate InventoryReport

IF Statement Examples: IF Customer NOT in Customer Object Store THEN Add Customer record to Customer Object Store ELSE Add CurrentSale 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 CustomerReport

Add Customer’s TotalSales to ReportTotalCASE Statement Examples: CASE

IF Income < 10,000: Marginaltaxrate = 10 percent IF Income < 20,000: Marginaltaxrate = 20 percent IF Income < 30,000: Marginaltaxrate = 31 percent IF Income < 40,000: Marginaltaxrate = 35 percent ELSE Marginaltaxrate = 38 percentENDCASE

Notes:

• Pseudocode = “programming specific” language with initialisation and linking instructions

• (Get_CD_Info Module)Accept(CD.Title) {Required}Accept(CD.Artist) {Required}Accept(CD.Category) {Required}Accept(CD.Length)

• Return

uml_phan_tich_va_thiet_ke_huong_doi_tuong__0506

Documents

Русско-латинский словарь

Municipios de España

Antoni Gaudi arhitectura

Informacia ot BD i RIOSV 12 12 2005

מוטיבציה בעבודה

העצמת בני משפחה של חולי אלצהיימר

הצגת מלחמת העצמאות באתר של מט"ח

phone

Puntuación PAEF,s

1 시스템분석입문

Махновщина

gidoi teknikoa

БОРБЕНИ АВИОНИ КОМПАНИЈЕ СУХОЈ

Άσκηση1 4

דילמות בערכי יהדות

לאומיות וחברת המידע

168名詞解釋

cisco사례분석

Клиентизм

טבלת תרופות למערכת העצבים האוטונומית