Upload
thuy-lee
View
187
Download
4
Embed Size (px)
Citation preview
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ế ế ệ ố
3/Chapter© DHBK 2007
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ể ệ ố
4/Chapter© DHBK 2007
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
5/Chapter© DHBK 2007
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ươ ể ệ ố
6/Chapter© DHBK 2007
1.1 Gi i thi uớ ệ1.1 Gi i thi uớ ệ
7/Chapter© DHBK 2007
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ể ệ ố
8/Chapter© DHBK 2007
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ề ể ả ự
9/Chapter© DHBK 2007
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ữ ệ
10/Chapter© DHBK 2007
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ế ế ươ
11/Chapter© DHBK 2007
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ặ ệ ố
12/Chapter© DHBK 2007
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
13/Chapter© DHBK 2007
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)
14/Chapter© DHBK 2007
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ướ ắ ầ ướ ế
15/Chapter© DHBK 2007
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ươ ướ
16/Chapter© DHBK 2007
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)ườ ấ
17/Chapter© DHBK 2007
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ươ ể
18/Chapter© DHBK 2007
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ãụ ạ
19/Chapter© DHBK 2007
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ườ
21/Chapter© DHBK 2007
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ươ ự ẫ ạ ỏ
22/Chapter© DHBK 2007
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ỹ ờ
23/Chapter© DHBK 2007
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ự ọ ươ ợ
24/Chapter© DHBK 2007
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
25/Chapter© DHBK 2007
2.1 Gi i thi uớ ệ2.1 Gi i thi uớ ệ
• L ch s phát tri n c a ngôn ng l p trình:ị ử ể ủ ữ ậFirst Generation (1954 – 1958)
Fortran I
Second Generation (1959 – 1961)Fortran II, Algol, Cobol
Third Generation (1962 – 1970)PL/I, Pascal
Object Oriented LanguagesSmalltalk, C++, Java
26/Chapter© DHBK 2007
2.1 Gi i thi uớ ệ2.1 Gi i thi uớ ệ
• L ch s phát tri n c a ị ử ể ủUML
27/Chapter© DHBK 2007
2.1 Gi i thi uớ ệ2.1 Gi i thi uớ ệ
• L ch s phát tri n c a ị ử ể ủUML
1967
Foundations of OO (Nygaard, Goldberg, Meyer,Foundations of OO (Nygaard, Goldberg, Meyer,Stroustrup, Harel, Wirfs-Brock, Reenskaug,…)Stroustrup, Harel, Wirfs-Brock, Reenskaug,…)
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
1996
1997
1998
20012002
2003
UML 2.0UML 2.0
28/Chapter© DHBK 2007
2.1 Gi i thi uớ ệ2.1 Gi i thi uớ ệ
• Thi t k c u trúc và thi t k h ng đ i t ngế ế ấ ế ế ướ ố ượ
29/Chapter© DHBK 2007
2.1 Gi i thi uớ ệ2.1 Gi i thi uớ ệ
• Thi t k c u trúc và thi t k h ng đ i t ngế ế ấ ế ế ướ ố ượ
30/Chapter© DHBK 2007
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)
31/Chapter© DHBK 2007
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 ứ
do
32/Chapter© DHBK 2007
2.2.1 L p và đ i t ngớ ố ượ2.2.1 L p và đ i t ngớ ố ượ
33/Chapter© DHBK 2007
2.2.1 L p và đ i t ngớ ố ượ2.2.1 L p và đ i t ngớ ố ượ
1 class Time {
2 public:
3 Time();
4 void setTime( int, int, int );
5 void printMilitary();
6 void printStandard();
7 private:
8 int hour; // 0 - 23
9 int minute; // 0 - 59
10 int second; // 0 - 59
11 };
34/Chapter© DHBK 2007
2.2.2 Ph ng th c và messageươ ứ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
35/Chapter© DHBK 2007
2.2.2 Ph ng th c và messageươ ứ2.2.2 Ph ng th c và messageươ ứ
36/Chapter© DHBK 2007
2.2.3 Tóm l c và n thông tinượ ẩ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
37/Chapter© DHBK 2007
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
38/Chapter© DHBK 2007
2.2.4 Th a kừ ế2.2.4 Th a kừ ế
39/Chapter© DHBK 2007
2.2.4 Th a kừ ế2.2.4 Th a kừ ế
40/Chapter© DHBK 2007
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
41/Chapter© DHBK 2007
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
38 };
39
40 #endif
41 // Fig. 20.1: point1.cpp
42 // Member function definitions for class Point
43 #include "point1.h"
44
45 Point::Point( int a, int b ) { setPoint( a, b ); }
46
47 void Point::setPoint( int a, int b )
48 {
49 x = a;
50 y = b;
51 }
52
53 void Point::print() const
54 { cout << '[' << x << ", " << y << ']'; }
55 // Fig. 20.1: circle1.h
56 // Definition of class Circle
57 #ifndef CIRCLE1_H
58 #define CIRCLE1_H
59 #include "point1.h"
60
61 class Circle : public Point {
62 public:
63 // default constructor
64 Circle( double r = 0.0, int x = 0, int y = 0 );
65
66 void setRadius( double );
67 double getRadius() const;
68 virtual double area() const;
69 virtual void printShapeName() const { cout << "Circle: "; }
70 virtual void print() const;
71 private:
72 double radius; // radius of Circle
73 };
74
75 #endif
76 // Fig. 20.1: circle1.cpp
77 // Member function definitions for class Circle
78 #include <iostream>
79
80 using std::cout;
81
82 #include "circle1.h"
83
84 Circle::Circle( double r, int a, int b )
85 : Point( a, b ) // call base-class constructor
86 { setRadius( r ); }
87
88 void Circle::setRadius( double r ) { radius = r > 0 ? r : 0; }
89
90 double Circle::getRadius() const { return radius; }
91
92 double Circle::area() const
93 { return 3.14159 * radius * radius; }
94
95 void Circle::print() const
96 {
97 Point::print();
98 cout << "; Radius = " << radius;
99 }
100// Fig. 20.1: cylindr1.h
101// Definition of class Cylinder
102#ifndef CYLINDR1_H
103#define CYLINDR1_H
104#include "circle1.h"
105
106class Cylinder : public Circle {
107public:
108 // default constructor
109 Cylinder( double h = 0.0, double r = 0.0,
110 int x = 0, int y = 0 );
111
112 void setHeight( double );
113 double getHeight();
114 virtual double area() const;
115 virtual double volume() const;
116 virtual void printShapeName() const { cout << "Cylinder: "; }
117 virtual void print() const;
118private:
119 double height; // height of Cylinder
120};
121
122#endif
123// Fig. 20.1: cylindr1.cpp124// Member and friend function definitions for class Cylinder125#include <iostream>126127using std::cout;128129#include "cylindr1.h"130131Cylinder::Cylinder( double h, double r, int x, int y )132 : Circle( r, x, y ) // call base-class constructor133{ setHeight( h ); }134135void Cylinder::setHeight( double h )136 { height = h > 0 ? h : 0; }137138double Cylinder::getHeight() { return height; }139140double Cylinder::area() const141{142 // surface area of Cylinder143 return 2 * Circle::area() +144 2 * 3.14159 * getRadius() * height;145}146147double Cylinder::volume() const 148 { return Circle::area() * height; }149150void Cylinder::print() const151{152 Circle::print();153 cout << "; Height = " << height;154}
155// Fig. 20.1: fig20_01.cpp
156// Driver for shape, point, circle, cylinder hierarchy
157#include <iostream>
158
159using std::cout;
160using std::endl;
161
162#include <iomanip>
163
164using std::ios;
165using std::setiosflags;
166using std::setprecision;
167
168#include "shape.h"
169#include "point1.h"
170#include "circle1.h"
171#include "cylindr1.h"
172
173void virtualViaPointer( const Shape * );
174void virtualViaReference( const Shape & );
175
176int main()
177{
178 cout << setiosflags( ios::fixed | ios::showpoint )
179 << setprecision( 2 );
180
181 Point point( 7, 11 ); // create a Point
182 Circle circle( 3.5, 22, 8 ); // create a Circle
183 Cylinder cylinder( 10, 3.3, 10, 10 ); // create a Cylinder
184
185 point.printShapeName(); // static binding
2. Function calls
186 point.print(); // static binding187 cout << '\n';188189 circle.printShapeName(); // static binding190 circle.print(); // static binding191 cout << '\n';192193 cylinder.printShapeName(); // static binding194 cylinder.print(); // static binding195 cout << "\n\n";196197 Shape *arrayOfShapes[ 3 ]; // array of base-class pointers198199 // aim arrayOfShapes[0] at derived-class Point object200 arrayOfShapes[ 0 ] = &point;201202 // aim arrayOfShapes[1] at derived-class Circle object203 arrayOfShapes[ 1 ] = &circle;204205 // aim arrayOfShapes[2] at derived-class Cylinder object206 arrayOfShapes[ 2 ] = &cylinder;207208 // Loop through arrayOfShapes and call virtualViaPointer209 // to print the shape name, attributes, area, and volume 210 // of each object using dynamic binding.211 cout << "Virtual function calls made off "212 << "base-class pointers\n";213214 for ( int i = 0; i < 3; i++ ) 215 virtualViaPointer( arrayOfShapes[ i ] );216217 // Loop through arrayOfShapes and call virtualViaReference218 // to print the shape name, attributes, area, and volume 219 // of each object using dynamic binding.
220 cout << "Virtual function calls made off "
221 << "base-class references\n";
222
223 for ( int j = 0; j < 3; j++ )
224 virtualViaReference( *arrayOfShapes[ j ] );
225
226 return 0;
227}
228
229// Make virtual function calls off a base-class pointer
230// using dynamic binding.
231void virtualViaPointer( const Shape *baseClassPtr )
232{
233 baseClassPtr->printShapeName();
234 baseClassPtr->print();
235 cout << "\nArea = " << baseClassPtr->area()
236 << "\nVolume = " << baseClassPtr->volume() << "\n\n";
237}
238
239// Make virtual function calls off a base-class reference
240// using dynamic binding.
241void virtualViaReference( const Shape &baseClassRef )
242{
243 baseClassRef.printShapeName();
244 baseClassRef.print();
245 cout << "\nArea = " << baseClassRef.area()
246 << "\nVolume = " << baseClassRef.volume() << "\n\n";
247}
51/Chapter© DHBK 2007
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ắ
52/Chapter© DHBK 2007
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
53/Chapter© DHBK 2007
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ể ồ ứ
54/Chapter© DHBK 2007
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)
55/Chapter© DHBK 2007
2.3.2 Bi u đ c u trúcể ồ ấ2.3.2 Bi u đ c u trúcể ồ ấ
• Bi u đ l p (class diagram)ể ồ ớ Bi u di n m i quan h gi a các l pể ễ ố ệ ữ ớ
56/Chapter© DHBK 2007
2.3.2 Bi u đ c u trúcể ồ ấ2.3.2 Bi u đ c u trúcể ồ ấ
• Bi u đ đ i t ng (object diagram)ể ồ ố ượ Bi u di n m i quan h gi a các đ i t ngể ễ ố ệ ữ ố ượ
57/Chapter© DHBK 2007
2.3.2 Bi u đ c u trúcể ồ ấ2.3.2 Bi u đ c u trúcể ồ ấ
• Bi u đ gói (package diagram)ể ồ Bi u đ gói g p các thành ph n khác nhau c a UML (ví d : l p) ể ồ ộ ầ ủ ụ ớ
đ t o thành thành ph n l n h nể ạ ầ ớ ơ
58/Chapter© DHBK 2007
2.3.2 Bi u đ c u trúcể ồ ấ2.3.2 Bi u đ c u trúcể ồ ấ
• Bi u đ tri n khai (deployment diagram)ể ồ ể Bi u di n c u trúc ph n c ng và các thành ph n ph n m m c a ể ễ ấ ầ ứ ầ ầ ề ủ
h th ngệ ố
59/Chapter© DHBK 2007
2.3.2 Bi u đ c u trúcể ồ ấ2.3.2 Bi u đ c u trúcể ồ ấ
• Bi u đ thành ph n (component diagram)ể ồ ầ Bi u di n quan h gi a các thành ph n c a h th ngể ễ ệ ữ ầ ủ ệ ố
60/Chapter© DHBK 2007
2.3.2 Bi u đ c u trúcể ồ ấ2.3.2 Bi u đ c u trúcể ồ ấ
• Bi u đ c u trúc ph c h p (composite structure diagram)ể ồ ấ ứ ợ Minh ho chi ti t c u trúc bên trong c a m t l pạ ế ấ ủ ộ ớ
61/Chapter© DHBK 2007
2.3.3 Bi u đ ch c năngể ồ ứ2.3.3 Bi u đ ch c năngể ồ ứ
• 8 lo i bi u đ ch c năngạ ể ồ ứBi u đ ho t đ ng (activity diagram)ể ồ ạ ộBi u đ t ng tác (interaction diagrams)ể ồ ươ
Bi u đ chu i tu n t (sequence diagram)ể ồ ỗ ầ ựBi u đ c ng tác (communication/collaboration diagram)ể ồ ộBi u đ khát quát t ng tác (interaction overview diagram)ể ồ ươBi u đ th i gian (timing diagram)ể ồ ờ
Bi u đ máy tr ng thái (state machines)ể ồ ạMáy tr ng thái ch c năng (behavior state machines)ạ ứMáy tr ng thái giao th c (protocol state machines)ạ ứ
Bi u đ ca s d ng (use case diagram)ể ồ ử ụ
62/Chapter© DHBK 2007
2.3.3 Bi u đ ch c năngể ồ ứ2.3.3 Bi u đ ch c năngể ồ ứ
• Bi u đ ho t đ ng ể ồ ạ ộ(activity diagram) Đ c dùng đ mô t lu ng ượ ể ả ồ
công vi c c a h th ng ệ ủ ệ ốho c lu ng ho t đ ng trong ặ ồ ạ ộm t ca s d ng ho c mô t ộ ử ụ ặ ảthi t k chi ti t c a m t ế ế ế ủ ộph ng th c (method)ươ ứ
63/Chapter© DHBK 2007
2.3.3 Bi u đ ch c năngể ồ ứ2.3.3 Bi u đ ch c năngể ồ ứ
• Bi u đ chu i tu n t (sequence diagram)ể ồ ỗ ầ ự Mô t các ho t đ ng c a các đ i t ng trong m t ca s d ng d a ả ạ ộ ủ ố ượ ộ ử ụ ự
vào th t xu t hi n theo th i gianứ ự ấ ệ ờ
64/Chapter© DHBK 2007
2.3.3 Bi u đ ch c năngể ồ ứ2.3.3 Bi u đ ch c năngể ồ ứ
• Bi u đ c ng tác (collaboration diagram)ể ồ ộ Là cách bi u di n khác c a bi u đ chu i tu n t nh ng t p ể ễ ủ ể ồ ỗ ầ ự ư ậ
trung vào m i quan h và giao ti p gi a các đ i t ngố ệ ế ữ ố ượ
65/Chapter© DHBK 2007
2.3.3 Bi u đ ch c năngể ồ ứ2.3.3 Bi u đ ch c năngể ồ ứ
• Bi u đ khát quát t ng tác (interaction overview ể ồ ươdiagram) Đ c dùng đ mô t t ng tác gi a các đ i t ng trong các ca s ượ ể ả ươ ữ ố ượ ử
d ng ph c t pụ ứ ạ Ít đ c s d ngượ ử ụ
• Bi u đ th i gian (timing diagram)ể ồ ờ Đ c dùng đ mô t t ng tác gi a các đ i t ng theo th i gian. ượ ể ả ươ ữ ố ượ ờ
Ch y u đ c dùng đ mô t s thay đ i tr ng thái c a đ i t ng ủ ế ượ ể ả ự ố ạ ủ ố ượkhi có tác đ ng c a m t s ki n theo th i gian.ộ ủ ộ ự ệ ờ
Đ c dùng đ phát tri n các h th ng th i gian th c và h th ng ượ ể ể ệ ố ờ ự ệ ốnhúng
66/Chapter© DHBK 2007
2.3.3 Bi u đ ch c năngể ồ ứ2.3.3 Bi u đ ch c năngể ồ ứ
• Bi u đ máy tr ng thái ch c năng (behavior state ể ồ ạ ứmachines) Đ c dùng đ mô t các tr ng thái khác nhau mà các đ i t ng ượ ể ả ạ ố ượ
c a m t l p có th có trong th i gian t n t i c a chúng.ủ ộ ớ ể ờ ồ ạ ủ
67/Chapter© DHBK 2007
2.3.3 Bi u đ ch c năngể ồ ứ2.3.3 Bi u đ ch c năngể ồ ứ
• Bi u đ máy tr ng thái giao th c (protocol state ể ồ ạ ứmachines) Đ c dùng đ mô t giao th c gi a các l pượ ể ả ứ ữ ớ Ví d : open database -> Query or updateụ
• Bi u đ ca s d ng (use case diagram)ể ồ ử ụ Đ c dùng đ mô t t ng tác gi a m t h th ng v i ng i s ượ ể ả ươ ữ ộ ệ ố ớ ườ ử
d ng ho c v i các h th ng khác có t ng tác v i nó.ụ ặ ớ ệ ố ươ ớ Là công c đ mô t các yêu c u c a h th ngụ ể ả ầ ủ ệ ố Là m t trong nh ng công c quan tr ng nh t trong phân tích và ộ ữ ụ ọ ấ
thi t k h ng đ i t ngế ế ướ ố ượ
68/Chapter© DHBK 2007
2.3.3 Bi u đ ch c năngể ồ ứ2.3.3 Bi u đ ch c năngể ồ ứ
69/Chapter© DHBK 2007
2.3.3 Bi u đ ch c năngể ồ ứ2.3.3 Bi u đ ch c năngể ồ ứ
70/Chapter© DHBK 2007
2.3.3 Bi u đ ch c năngể ồ ứ2.3.3 Bi u đ ch c năngể ồ ứ
71/Chapter© DHBK 2007
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 { }ộ ượ ặ ặ
72/Chapter© DHBK 2007
2.3.4 Các c ch m r ngơ ế ở ộ2.3.4 Các c ch m r ngơ ế ở ộ
• Nhãn:giá tr (tagged values)ị Là m t c p chu i ký t : nhãn (tag) và giá tr (value) đ c dùng đ ộ ặ ỗ ự ị ượ ể
b sung thông tin cho m t ph n t nào đó (l p, đ i t ng, quan ổ ộ ầ ử ớ ố ượh …)ệ
Nhãn và giá tr đ c đ t trong ngo c { } ị ượ ặ ặ
73/Chapter© DHBK 2007
2.3.4 Các c ch m r ngơ ế ở ộ2.3.4 Các c ch m r ngơ ế ở ộ
• Khuôn m u (stereotype)ẫ Cho phép m r ng UML b ng cách s d ng các ph n t mô hình ở ộ ằ ử ụ ầ ử
hoá đã có s n trong UMLẵ Khuôn m u có th s d ng ràng bu c và tagged valuesẫ ể ử ụ ộ Khuôn m u đ c đ t trong d u << >>ẫ ượ ặ ấ
74/Chapter© DHBK 2007
2.3.5 Tóm t tắ2.3.5 Tóm t tắ
75/Chapter© DHBK 2007
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
76/Chapter© DHBK 2007
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
77/Chapter© DHBK 2007
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 ư ề ố ượ ầ ớ ự ế
78/Chapter© DHBK 2007
2.4.2 u đi m c a OOADƯ ể ủ2.4.2 u đi m c a OOADƯ ể ủ
79/Chapter© DHBK 2007
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ế ấ ề ươ ữ ự
80/Chapter© DHBK 2007
2.4.3 The Unified process2.4.3 The Unified process
81/Chapter© DHBK 2007
2.4.3 The Unified process2.4.3 The Unified process
• Pha kh i t o (Inception): gi ng nh pha l p k ở ạ ố ư ậ ếho ch ạCác b c liên quan:ướ
Mô hình hoá giá tr kinh doanh c a h th ng (business modeling) *ị ủ ệ ốXác đ nh yêu c u (requirements)*ị ầPhân tích (analysis)*Thi t k (design)ế ếTh c hi n (implementation)ự ệKi m tra (test)ểMôi tr ng phát tri n (environment)*ườ ể
K t qu :ế ảPh m vi c a d ánạ ủ ựCác yêu c u và ràng bu c quan tr ngầ ộ ọK ho ch d án b c đ uế ạ ự ướ ầMiêu t tính kh thi và r i ro c a d ánả ả ủ ủ ựL a ch n môi tr ng c n thi t đ phát tri n h th ngự ọ ườ ầ ế ể ể ệ ố
82/Chapter© DHBK 2007
2.4.3 The Unified process2.4.3 The Unified process
• Pha phát tri n (elaboration): hoàn thi n mô hình ể ệkinh doanh, đánh giá l i r i ro và hoàn thi n k ạ ủ ệ ếho ch d ánạ ựCác b c liên quan:ướ
Thu th p yêu c u (requirements)ậ ầPhân tích (analysis)*Thi t k (design)*ế ếTh c hi n (implementation)ự ệKi m tra (test)ểTri n khai (deployment)ểQu n lý c u hình và thay đ i (configuration and change management)ả ấ ổ
K t qu :ế ảBi u đ c u trúc và ch c năng UMLể ồ ấ ứPhiên b n ho t đ ng đ u tiên c a h th ngả ạ ộ ầ ủ ệ ố
83/Chapter© DHBK 2007
2.4.3 The Unified process2.4.3 The Unified process
• Pha xây d ng (construction): t p trung ch y u ự ậ ủ ếvào l p trìnhậCác b c liên quan:ướ
Thu th p yêu c u (requirements)ậ ầPhân tích (analysis)Thi t k (design)ế ếTh c hi n (implementation)*ự ệKi m tra (test)ểTri n khai (deployment)ểQu n lý c u hình và thay đ i (configuration and change management)*ả ấ ổ
K t qu :ế ảPhiên b n beta c a h th ngả ủ ệ ố
84/Chapter© DHBK 2007
2.4.3 The Unified process2.4.3 The Unified process
• Pha chuy n ti p (transition): t p trung ch y u vào ể ế ậ ủ ếki m tra và tri n khaiể ểCác b c liên quan:ướ
Thu th p yêu c u (requirements)ậ ầPhân tích (analysis)Thi t k (design)ế ếTh c hi n (implementation)ự ệKi m tra (test)*ểTri n khai (deployment)*ểQu n lý c u hình và thay đ i (configuration and change management)*ả ấ ổ
K t qu :ế ảPhiên b n cu i cùng (release) c a h th ngả ố ủ ệ ốH ng d n s d ngướ ẫ ử ụK ho ch h tr khách hàng, k ho ch nâng c p h th ngế ạ ỗ ợ ế ạ ấ ệ ố
85/Chapter© DHBK 2007
2.4.3 The Unified process2.4.3 The Unified process
• Các b c k thu t (Engineering workflows)ướ ỹ ậ1. Mô hình hoá giá tr kinh doanh (business modeling)ị
Di n ra ch y u trong pha kh i t oễ ủ ế ở ạ Phát hi n v n đ và xác đ nh các d án ti m năngệ ấ ề ị ự ề Xác đ nh giá tr kinh doanh mà d án đem l iị ị ự ạ Thu th p d li u và mô hình hoá ca s d ng có th đ c s ậ ữ ệ ử ụ ể ượ ử
d ngụ
2. Xác đ nh yêu c u (requirements)ị ầ Xác đ nh yêu c u v ch c năng và c không ch c năngị ầ ề ứ ả ứ Yêu c u đ c thu th p t ng i s d ng, ng i qu n lý ầ ượ ậ ừ ườ ử ụ ườ ả
ng i s d ng, khách hàngườ ử ụ
3. Phân tích Xây d ng bi u đ c u trúc và ch c năng s d ng UMLự ể ồ ấ ứ ử ụ Xác đ nh các l p có th s d ng l iị ớ ể ử ụ ạ B c phân tích có th đ c s d ng l i b t kỳ lúc nào trong chu ướ ể ượ ử ụ ạ ấ
trình phát tri n h th ngể ệ ố
86/Chapter© DHBK 2007
2.4.3 The Unified process2.4.3 The Unified process
• Các b c k thu t (Engineering workflows)ướ ỹ ậ1. Thi t kế ế
Chuy n t mô hình phân tích sang mô hình thi t kể ừ ế ế Thi t k giao di n, c s d li u, c u trúc v t lý c a h th ng, thi t ế ế ệ ơ ở ữ ệ ấ ậ ủ ệ ố ế
k chi ti t các l pế ế ớ
2. Th c hi n (implementation)ự ệ L p trình: vi t các l p, ch ng trình và s d ng các l p trong th ậ ế ớ ươ ử ụ ớ ư
vi n ệ Tích h p các moduleợ
3. Ki m tra (Test)ể Ki m tra tích h p h th ng, ch c năng, ki m tra kh năng ch p ể ợ ệ ố ứ ể ả ấ
nh n c a ng i s d ng …ậ ủ ườ ử ụ Vi c ki m tra đu c ti n hành trong su t quá trình phát tri n c a h ệ ể ợ ế ố ể ủ ệ
th ngố
4. Tri n khai (deployment)ể Đóng gói ph n m m, phân ph i, cài đ t và beta testingầ ề ố ặ
87/Chapter© DHBK 2007
2.4.3 The Unified process2.4.3 The Unified process
• Các b c h tr (Supporting workflows)ướ ỗ ợ1. Qu n lý d án (project management)ả ự
Di n ra trong su t quá trình phát tri n h th ngễ ố ể ệ ố Xác đ nh và qu n lý r i roị ả ủ Qu n lý ph m vi d ánả ạ ự Qu n lý v th i gian, chi phí…ả ề ờ
2. Qu n lý c u hình và thay đ i (configuration and ả ấ ổchange management ) Theo dõi và qu n lý tr ng thái và các phiên b n c a h th ngả ạ ả ủ ệ ố Qu n lý vi c thay đ i các phiên b n (ng i thay đ i, th i gian ả ệ ổ ả ườ ổ ờ
thay đ i…)ổ
3. Qu n lý môi tr ng phát tri n (environment)ả ườ ể Qu n lý các công c và môi tr ng phát tri n c n thi t cho d ả ụ ườ ể ầ ế ự
án Ví du: Rational Rose, Microsoft project, Microsoft Visual C++
88/Chapter© DHBK 2007
2.4.4 MOOSAD2.4.4 MOOSAD
89/Chapter© DHBK 2007
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)ả ự
90/Chapter© DHBK 2007
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ự ọ ự
91/Chapter© DHBK 2007
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ộ ồ ệ ự
No
Yêu c u h th ngầ ệ ốđã ch nh s aỉ ử
Yes
Phân tích tính kh thiả
Project sponsor + analyst
H i đ ng duy t d ánộ ồ ệ ự
92/Chapter© DHBK 2007
3.1.1 Gi i thi uớ ệ3.1.1 Gi i thi uớ ệ
• H i đ ng duy t d án (approval committee)ộ ồ ệ ựH i đ ng chuyên trách h p th ng kỳ (vd. 3 tháng 1 ộ ồ ọ ườ
l n)ầ1 đ n v ch c năng ho c cá nhân có th m quy n (vd. ơ ị ứ ặ ẩ ề
phòng qu n lý d án, giám đ c)ả ự ố
93/Chapter© DHBK 2007
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)ấ ề ặ ệ
94/Chapter© DHBK 2007
3.1.2 Yêu c u h th ng (system ầ ệ ố3.1.2 Yêu c u h th ng (system ầ ệ ốrequest)request)
• Ch nhi m d án (project sponsor)ủ ệ ự Ng i thu c phòng kinh doanhườ ộ Ng i thu c phòng IT có th là ch nhi m ho c đ ng ch nhi m ườ ộ ể ủ ệ ặ ồ ủ ệ
d ánự CIO, CEO
• Nhu c u kinh doanh (business need): why?ầ Xu t phát t :ấ ừ
Phòng kinh 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ệ ớ ề ề ấ ệ
95/Chapter© DHBK 2007
3.1.2 Yêu c u h th ng (system ầ ệ ố3.1.2 Yêu c u h th ng (system ầ ệ ốrequest)request)
• Yêu c u kinh doanh (business requirement)ầH th ng s làm gìệ ố ẽCác ch c năng c a h th ngứ ủ ệ ố
• Giá tr kinh doanh (business values)ịGiá tr h u hình: ví d : 20 % gi m v chi phíị ữ ụ ả ềGiá tr vô hình: ví d : c i thi n ch t l ng d ch v ị ụ ả ệ ấ ượ ị ụ
khách hàng, c i thi n v trí c nh tranhả ệ ị ạ
• Các v n đ đ c bi tấ ề ặ ệví d : th i h n hoàn thànhụ ờ ạ
96/Chapter© DHBK 2007
Case study: CD 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ườ ưở ạ
97/Chapter© DHBK 2007
Case study: CD selectionsCase study: CD selections
98/Chapter© DHBK 2007
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)ả ề ặ ổ ứ
99/Chapter© DHBK 2007
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) (can we ả ề ỹ ậbuild it ?)M c đ quen thu c v i ng d ngứ ộ ộ ớ ứ ụM c đ quen thu c v i công nghứ ộ ộ ớ ệKích th c c a d án:ướ ủ ự
S l ng ng i tham dố ượ ườ ựth i gianờđ ph c t p c a h th ngộ ứ ạ ủ ệ ố
S t ng thích c a h th ng m i v i h th ng đang ự ươ ủ ệ ố ớ ớ ệ ốt n t iồ ạ
quy t đ nh d a trên vi c so sánh v i các d án tr c đó ho c ế ị ự ệ ớ ự ướ ặtham kh o ý ki n c a chuyên gia công nghả ế ủ ệ
100/Chapter© DHBK 2007
3.1.3 Phân tích tính kh thiả3.1.3 Phân tích tính kh thiả
• Kh thi v kinh t (economic feasibility) (should we build it ả ề ế?) Xác đ nh các lo i chi phí và l i nhu nị ạ ợ ậ
Chi phí phát tri n h th ng (1 l n)ể ệ ố ầChi phí v n hành (chi phí th ng xuyên)ậ ườL i nhu n h u hìnhợ ậ ữL i nhu n vô hìnhợ ậ
101/Chapter© DHBK 2007
3.1.3 Phân tích tính kh thiả3.1.3 Phân tích tính kh thiả
102/Chapter© DHBK 2007
3.1.3 Phân tích tính kh thiả3.1.3 Phân tích tính kh thiả
• Kh thi v kinh t (economic feasibility) (should we build it ả ề ế?) Đ nh l ng các lo i chi phí và l i nhu nị ượ ạ ợ ậ
C g ng đ nh l ng các giá tr vô hìnhố ắ ị ượ ị
103/Chapter© DHBK 2007
3.1.3 Phân tích tính kh thiả3.1.3 Phân tích tính kh thiả
• Kh thi v kinh t (economic feasibility) (should we build it ả ề ế?) Xác đ nh dòng ti n m t (cash flow): giá tr chi phí và l i nhu n ị ề ặ ị ợ ậ
trong kho ng th i gian t 3-5 nămả ờ ừ
104/Chapter© DHBK 2007
3.1.3 Phân tích tính kh thiả3.1.3 Phân tích tính kh thiả
105/Chapter© DHBK 2007
3.1.3 Phân tích tính kh thiả3.1.3 Phân tích tính kh thiả
• Kh thi v kinh t (economic feasibility) (should we build it ả ề ế?) Xác đ nh giá tr hi n t i Net present Value (NPV)ị ị ệ ạ Xác đ nh t l h i v n (Return on Investment)ị ỷ ệ ồ ố Xác đ nh đi m hoà v n (break even point)ị ể ố V đ th đi m hoà v nẽ ồ ị ể ố
106/Chapter© DHBK 2007
3.1.3 Phân tích tính kh thiả3.1.3 Phân tích tính kh thiả
• Kh thi v kinh t (economic feasibility) (should we build it ả ề ế?)
107/Chapter© DHBK 2007
3.1.3 Phân tích tính kh thiả3.1.3 Phân tích tính kh thiả
• Kh thi v kinh t (economic feasibility) (should we build it ả ề ế?)
108/Chapter© DHBK 2007
3.1.3 Phân tích tính kh thiả3.1.3 Phân tích tính kh thiả
• Kh thi v kinh t (economic feasibility) (should we build it ả ề ế?)
109/Chapter© DHBK 2007
3.1.3 Phân tích tính kh thiả3.1.3 Phân tích tính kh thiả
• Kh thi v t ch cả ề ổ ứ Phân tích đánh giá m c đ h th ng m i đ c ch p nh n b i ứ ộ ệ ố ớ ượ ấ ậ ở
ng i s d ng và kh năng tích h p c a h th ng vào trong h ườ ử ụ ả ợ ủ ệ ố ệth ng đang v n hành trong công tyố ậ
2 cách đánh giá:H th ng m i có cùng đ nh h ng v i chi n l c phát tri n c a công ệ ố ớ ị ướ ớ ế ượ ể ủ
ty?Phân tích nh h ng ho c b nh h ng c a d án đ i v i nh ng ả ưở ặ ị ả ưở ủ ự ố ớ ữ
ng i liên quanườ Ng i b o tr cho d ánườ ả ợ ự Ng i s d ng h th ngườ ử ụ ệ ố Ban lãnh đ o công tyạ
• Case study: CD selections
110/Chapter© DHBK 2007
3.1.4 L a ch n d ánự ọ ự3.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ố ượ ấ ượ ự
111/Chapter© DHBK 2007
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
112/Chapter© DHBK 2007
3.2.1 Gi i thi uớ ệ3.2.1 Gi i thi uớ ệ
• Project management is the process of planning and controlling the development of a system within a specified timeframe at a minimum cost with the right functionality.
• A project manager has the primary responsibility for managing the hundreds of tasks and roles that need to be carefully coordinated.
113/Chapter© DHBK 2007
3.2.2 Xác đ nh kích th c d ánị ướ ự3.2.2 Xác đ nh kích th c d ánị ướ ự
• 3 nhân t ph thu c l n nhau:ố ụ ộ ẫKích th c h th ngướ ệ ốTh i gian hoàn thành d ánờ ựChi phí c a d ánủ ự
• 2 ph ng pháp c l ng kích th c d ánươ ướ ượ ướ ựPh ng pháp đ n gi n d a trên chu n công nghi pươ ơ ả ự ẩ ệPh ng pháp đi m ch c năng (function point ươ ể ứ
approach)
114/Chapter© DHBK 2007
3.2.2 Xác đ nh kích th c d ánị ướ ự3.2.2 Xác đ nh kích th c d ánị ướ ự
• Ph ng pháp đ n gi n d a trên chu n công ươ ơ ả ự ẩnghi pệ
Planning Analysis Design Implementation
IndustryStandardFor Web 15% 20% 35% 30%Applications
TimeRequired 4 5.33 9.33 8in PersonMonths
115/Chapter© DHBK 2007
3.2.2 Xác đ nh kích th c d ánị ướ ự3.2.2 Xác đ nh kích th c d ánị ướ ự
• Ph ng pháp đi m ch c năngươ ể ứ
116/Chapter© DHBK 2007
3.2.2 Xác đ nh kích th c d ánị ướ ự3.2.2 Xác đ nh kích th c d ánị ướ ự
• Ph ng pháp đi m ch c năngươ ể ứXác đ nh kích th c h th ng theo đi m ch c năng và ị ướ ệ ố ể ứ
s dòng l nhố ệ1 đi m ch c năng là đ n v đo kích th c ch ng trình d a ể ứ ơ ị ướ ươ ự
trên s l ng và đ ph c t p c a đ u vào, đ u ra, truy v n, ố ượ ộ ứ ạ ủ ầ ầ ấfiles và giao di n ch ng trìnhệ ươ
Tính toán s đi m ch c năngố ể ứLi t kê các thành ph n c b n c a ch ng trìnhệ ầ ơ ả ủ ươXác đ nh s l ng m i thành ph nị ố ượ ỗ ầXác đ nh đô ph c t p c a m i thành ph n (low, med., high)ị ứ ạ ủ ỗ ầTính t ng s đi m ch c năng (TUFP)ổ ố ể ứ
117/Chapter© DHBK 2007
3.2.2 Xác đ nh kích th c d ánị ướ ự3.2.2 Xác đ nh kích th c d ánị ướ ự
Tính toán s đi m ch c năng-B c 1:ố ể ứ ướ
Complexity
Description Low Medium High Total
Inputs __x 3 __x 4 __x 6 ____
Outputs __x 4 __x 5 __x 7 ____
Queries __x 3 __x 4 __x 6 ____
Files __x 7 __x 10 __x 15 ____
Program __x 5 __x 7 __x 10 ____Interfaces
TOTAL UNADJUSTED FUNCTION POINTS ____
118/Chapter© DHBK 2007
3.2.2 Xác đ nh kích th c d ánị ướ ự3.2.2 Xác đ nh kích th c d ánị ướ ự
Tính toán s đi m ch c năng-Ví d :ố ể ứ ụ
119/Chapter© DHBK 2007
3.2.2 Xác đ nh kích th c d ánị ướ ự3.2.2 Xác đ nh kích th c d ánị ướ ự
Tính đ ph c t p x lý hi u ch nh (adjusted ộ ứ ạ ử ệ ỉprocessing complexity)-B c 2 ướ
120/Chapter© DHBK 2007
3.2.2 Xác đ nh kích th c d ánị ướ ự3.2.2 Xác đ nh kích th c d ánị ướ ự
Tính đ ph c t p x lý hi u ch nh (adjusted ộ ứ ạ ử ệ ỉprocessing complexity)-B c 2 ướ
Adjusted Processing Complexity (APC)
= .65 + (0.01 * Processing Complexity)
Total Adjusted Function Points (TAFP)
= Adjusted Processing Complexity * TUFP
121/Chapter© DHBK 2007
3.2.2 Xác đ nh kích th c d ánị ướ ự3.2.2 Xác đ nh kích th c d ánị ướ ự
Tính đ ph c t p x lý hi u ch nh (adjusted ộ ứ ạ ử ệ ỉprocessing complexity)-ví d :ụ
Processing Complexity (PC): __7______
Adjusted Processing Complexity (PCA) = 0.65 + (0.01 * __7_ )
Total Adjusted Function Points (TAFP):_0.72 * _338_ = 243 (TUFP From Step 1)
122/Chapter© DHBK 2007
3.2.2 Xác đ nh kích th c d ánị ướ ự3.2.2 Xác đ nh kích th c d ánị ướ ự
Tính s dòng l nh= ố ệ LOC/Function Code Point x TAFP
Language LOC/Function Code 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ụ ậ ố ệ
123/Chapter© DHBK 2007
3.2.2 Xác đ nh kích th c d ánị ướ ự3.2.2 Xác đ nh kích th c d ánị ướ ự
• Ph ng pháp đi m ch c năngươ ể ứXác đ nh kích th c h th ng theo đi m ch c năng và ị ướ ệ ố ể ứ
s dòng l nhố ệ c l ng nhân l c (person-months)Ướ ượ ự
Mô hình: COSOMO
Effort = 1.4 * thousandsof(in Person linesofcodeM onths)
Example:
If LOC = 20000 Then...Effort =(1.4 * 20) = 28 Person M onths
124/Chapter© DHBK 2007
3.2.2 Xác đ nh kích th c d ánị ướ ự3.2.2 Xác đ nh kích th c d ánị ướ ự
• Ph ng pháp đi m ch c năngươ ể ứXác đ nh kích th c h th ng theo đi m ch c năng và ị ướ ệ ố ể ứ
s dòng l nhố ệ c l ng nhân l c (person-months)Ướ ượ ự c l ng th i gian th c hi n d án (months)Ướ ượ ờ ự ệ ự
Schedule Time (months) = 3.0 * personmonths
1/3
Ví d : d án 28 person months c n 9 tháng đ hoàn thànhụ ự ầ ể
125/Chapter© DHBK 2007
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 ...ươ ự ệ
126/Chapter© DHBK 2007
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ệ
• 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
127/Chapter© DHBK 2007
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: 2 ph ng ị ệ ủ ự ươpháp Ph ng pháp Top-downươ
Xác đ nh các công vi c chính trong các pha c a d án ị ệ ủ ự L n l t chia các công vi c chính thành các công vi c nh ầ ượ ệ ệ ỏ
h nơ
Ph ng pháp chu nươ ẩ S d ng danh sách công vi c chu nử ụ ệ ẩ S d ng danh sách công vi c t các d án t ng t đã làmử ụ ệ ừ ự ươ ự
128/Chapter© DHBK 2007
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 dùng ph ng ị ệ ủ ự ươpháp Top-down
Phases Phases with high level steps
Work Plan Deliverables Estimated Assignedduration To
****
129/Chapter© DHBK 2007
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 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ả ẩ
130/Chapter© DHBK 2007
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ệ
131/Chapter© DHBK 2007
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ệ
• 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ạ ệ ự
132/Chapter© DHBK 2007
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ệ
• 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ờ ướ ượ
133/Chapter© DHBK 2007
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ệ
• Bi u đ PERTể ồ
X: Hoàn thành\: đang th c hi nự ệ
134/Chapter© DHBK 2007
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
135/Chapter© DHBK 2007
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ắ ế ự ự
Ví d v c c u t ch c c a d ánụ ề ơ ấ ổ ứ ủ ự
136/Chapter© DHBK 2007
3.2.4 S p x p nhân l c cho d ánắ ế ự ự3.2.4 S p x p nhân l c cho d ánắ ế ự ự
• Ch n ng i thích h p cho t ng v trí: ọ ườ ợ ừ ị2 tiêu chí:
K năng k thu t (technical skills)ỹ ỹ ậK năng giao ti p, ng x (interpersonal skills)ỹ ế ứ ử
N u không có s n ng i phù h p?ế ẵ ườ ợ
137/Chapter© DHBK 2007
3.2.4 S p x p nhân l c cho d ánắ ế ự ự3.2.4 S p x p nhân l c cho d ánắ ế ự ự
• Khích l đ ng viên các thành viên trong nhóm:ệ ộS d ng ti n th ng m t cách h t s c c n tr ngử ụ ề ưở ộ ế ứ ẩ ọS d ng các khích l tinh th n:ử ụ ệ ầ
Công vi c h p d n, thách th cệ ấ ẫ ứTinh th n trách nhi mầ ệNhu c u ti n thầ ế ủC h i đ h c k năng m iơ ộ ể ọ ỹ ớNhu c u t kh ng đ nh mìnhầ ự ẳ ịS thành cônngự
138/Chapter© DHBK 2007
3.2.4 S p x p nhân l c cho d ánắ ế ự ự3.2.4 S p x p nhân l c cho d ánắ ế ự ự
• Chi n l c đ gi i quy t xung đ t:ế ượ ể ả ế ộXác đ nh rõ ràng công vi c c a t ng thành viên trong ị ệ ủ ừ
nhó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ớ ự
139/Chapter© DHBK 2007
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ể ủ
140/Chapter© DHBK 2007
3.2.5 Đi u ph i ho t đ ng d ánề ố ạ ộ ự3.2.5 Đi u ph i ho t đ ng d ánề ố ạ ộ ự
• Tinh ch nh các giá tr c l ngỉ ị ướ ượ
Typical margins of Error for Welldone Estimates
Phase Deliverable Cost (%) time (%)
Planning System Request 400 60Project Plan 100 25
Analysis System Proposal 50 15
Design System Specification 25 10
141/Chapter© DHBK 2007
3.2.5 Đi u ph i ho t đ ng d ánề ố ạ ộ ự3.2.5 Đi u ph i ho t đ ng d ánề ố ạ ộ ự
• Qu n lý ph m vi d án (scope management)ả ạ ựScope creep: hi n t ng d án có nguy c kéo dài và ệ ượ ự ơ
t n chi phí h n d ki nố ơ ự ếNguyên nhân: thêm yêu c u m i cho h th ng sau khi ầ ớ ệ ố
ph m vi c a h th ng đã đ c gi i h nạ ủ ệ ố ượ ớ ạBi n pháp kh c ph c: ệ ắ ụ
Cách 1: tăng c ng g p g trao đ i v i ng i s d ng và xây ườ ặ ỡ ổ ớ ườ ử ụd ng nguyên m u đ tăng t c vi c đ nh rõ các yêu c u -> gi m ự ẫ ể ố ệ ị ầ ảđ c 5% nguy cượ ơ
Cách 2: s d ng k thu t h p th i gian (timeboxing)ử ụ ỹ ậ ộ ờ
142/Chapter© DHBK 2007
3.2.5 Đi u ph i ho t đ ng d ánề ố ạ ộ ự3.2.5 Đi u ph i ho t đ ng d ánề ố ạ ộ ự
• 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.
143/Chapter© DHBK 2007
3.2.5 Đi u ph i ho t đ ng d ánề ố ạ ộ ự3.2.5 Đi u ph i ho t đ ng d ánề ố ạ ộ ự
• Đ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
144/Chapter© DHBK 2007
3.2.5 Đi u ph i ho t đ ng d ánề ố ạ ộ ự3.2.5 Đi u ph i ho t đ ng d ánề ố ạ ộ ự
• Đ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
145/Chapter© DHBK 2007
3.2.5 Đi u ph i ho t đ ng d ánề ố ạ ộ ự3.2.5 Đi u ph i ho t đ ng d ánề ố ạ ộ ự
• Qu n lý r i ro:ả ủRisk assessment: a document assesses a potential risk
including: Risk No and its brief descriptionLikelihood of riskPotential impact on the project Ways to address the risk
Actions to reduce riskRevised assessment
146/Chapter© DHBK 2007
3.2.5 Đi u ph i ho t đ ng d ánề ố ạ ộ ự3.2.5 Đi u ph i ho t đ ng d ánề ố ạ ộ ự
• Qu n lý r i ro:ả ủAvoiding Classic Planning Mistakes
Overly optimistic scheduleFailing to monitor scheduleFailing to update scheduleAdding people to a late project
147/Chapter© DHBK 2007
3.2.6 CD selections3.2.6 CD selections
148/Chapter© DHBK 2007
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ạ ộ
149/Chapter© DHBK 2007
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ủ ệ ố
H i đ ng duy t d ánộ ồ ệ ự
Mô hình c u trúcấ
Mô hình ch c năngứ
Mô hình ho t đ ngạ ộ
system proposal
Phân tích kh thiảK ho ch công vi cế ạ ệ
+
Yes
Thi t k h th ngế ế ệ ố
150/Chapter© DHBK 2007
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
151/Chapter© DHBK 2007
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ủ ế ạ ướ ế ế ệ ố
152/Chapter© DHBK 2007
4.1.1 Xác đ nh yêu c uị ầ4.1.1 Xác đ nh yêu c uị ầ
• Tài li u đ nh nghĩa yêu c u (requirement ệ ị ầdefinition):Là văn b n li t kê các yêu c u ch c năng và yêu c u ả ệ ầ ứ ầ
không ch c năngứCung c p đ u vào cho các b c ti p theo trong quá ấ ầ ướ ế
trình phân tích h th ng cũng nh quá trình thi t kệ ố ư ế ếM c đích quan tr ng nh t c a tài li u đ nh nghĩa yêu ụ ọ ấ ủ ệ ị
c u là đ nh nghĩa ph m vi c a h th ngầ ị ạ ủ ệ ố
153/Chapter© DHBK 2007
4.1.1 Xác đ nh yêu c uị ầ4.1.1 Xác đ nh yêu c uị ầ
• Xây d ng tài li u đ nh nghĩa yêu c uự ệ ị ầXác đ nh các lo i yêu c u ch c năng và không ch c ị ạ ầ ứ ứ
nă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ị ứ ộ ọ ủ ầ
154/Chapter© DHBK 2007
4.1.1 Xác đ nh yêu c uị ầ4.1.1 Xác đ nh yêu c uị ầ
155/Chapter© DHBK 2007
4.1.1 Xác đ nh yêu c uị ầ4.1.1 Xác đ nh yêu c uị ầ
156/Chapter© DHBK 2007
4.1.2 Các k thu t phân tích yêu c uỹ ậ ầ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ự ầ ủ ệ ố ầ ự
157/Chapter© DHBK 2007
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ỹ ậ ầ
• 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 đủ ấ ề
158/Chapter© DHBK 2007
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ỹ ậ ầ
• Business process improvement (BPI): c i ti n quá ả ếtrình kinh doanh Làm thay đ i ho t đ ng hi n t iổ ạ ộ ệ ạ C n thi n đ c hi u su t và hi u qu c a h th ngả ệ ượ ệ ấ ệ ả ủ ệ ố T p trung vào h th ng m i đ c i ti nậ ệ ố ớ ể ả ế 3 ho t đ ng phân tích:ạ ộ
Phân tích kho ng th i gian (duration analysis):ả ờ phân tích chi ti t th i gian th c hi n m t khâu nào đó trong h th ng hi n ế ờ ự ệ ộ ệ ố ệt i và xác đ nh khâu có th đ c c i ti nạ ị ể ượ ả ế
Xác đ nh chi phí các ho t đ ng (activity based costing): ị ạ ộ xác đ nh chi phí c a t ng khâu trong h th ng hi n t i và xác ị ủ ừ ệ ố ệ ạđ nh các khâu có chi phí cao nh t và t đó c i ti n đ gi m ị ấ ừ ả ế ể ảchi phí
Nghiên c u kinh nghi m bên ngoài (informal benchmarking):ứ ệ nghiên c u cách t ch c kinh doanh c a các t ch c khác đ ứ ổ ứ ủ ổ ứ ểcó th rút ra đ c bài h c đ c i ti nể ượ ọ ể ả ế
159/Chapter© DHBK 2007
4.1.2 Các k thu t phân tích yêu c uỹ ậ ầ4.1.2 Các k thu t phân tích yêu c uỹ ậ ầ
• Business process reengineering (BPR): thay đ i ổquá trình kinh doanh Làm thay đ i c b n ho t đ ng hi n t iổ ơ ả ạ ộ ệ ạ 3 ho t đ ng phân tích:ạ ộ
Phân tích k t qu (outcome analysis):ế ả t p trung phân tích các ậk t qu c a h th ng có đem l i giá tr cho khách hàng. Nhà ế ả ủ ệ ố ạ ịphân tích khuy n khích các nhà qu n lý d án đ t mình vào v ế ả ự ặ ịtrí c a khách hàng và suy nghĩ c n th n v nh ng gì mà s n ủ ẩ ậ ề ữ ảph m và d ch v c a mình có th đem đ n cho khách hàng.ẩ ị ụ ủ ể ế
Phân tích công ngh (technology analysis): ệ Xác đ nh danh ịsách nh ng công ngh quan tr ng và h p d n t đó phân tích ữ ệ ọ ấ ẫ ừkh năng ng d ng công ngh vào ho t đ ng kinh doanh và ả ứ ụ ệ ạ ộl i ích c a vi c ng d ng công ngh đóợ ủ ệ ứ ụ ệ
Lo i b ho t đ ng (activity elimination)ạ ỏ ạ ộ : nhà phân tích và nhà qu n lý cùng tìm cách lo i b các ho t đ ng trong ho t đ ng ả ạ ỏ ạ ộ ạ ộkinh doanh, phân tích h u qu cũng nh nh h ng c a vi c ậ ả ư ả ưở ủ ệlo i b đóạ ỏ
160/Chapter© DHBK 2007
4.1.2 Các k thu t phân tích yêu c uỹ ậ ầ4.1.2 Các k thu t phân tích yêu c uỹ ậ ầ
• L a ch n k thu t thích h p, ph thu c vào:ự ọ ỹ ậ ợ ụ ộ Giá tr kinh doanh ti m năng (potential business value)ị ề Chi phí d án (project cost)ự Ph m vi phân tích (breadth of analysis)ạ R i ro th t b iủ ấ ạ
161/Chapter© DHBK 2007
4.1.2 Các k thu t phân tích yêu c uỹ ậ ầ4.1.2 Các k thu t phân tích yêu c uỹ ậ ầ
• L a ch n k thu t thích h pự ọ ỹ ậ ợ
162/Chapter© DHBK 2007
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)
163/Chapter© DHBK 2007
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): ỏ ấ 5 b cướ Ch n ng i đ c ph ng v nọ ườ ựơ ỏ ấ Thi t k câu h i ph ng v n ế ế ỏ ỏ ấ Chu n b cho cu c ph ng v nẩ ị ộ ỏ ấ Th c hi n ph ng v nự ệ ỏ ấ Th c hi n công vi c sau ph ng v nự ệ ệ ỏ ấ
164/Chapter© DHBK 2007
4.1.3 Các k thu t thu th p yêu c uỹ ậ ậ ầ4.1.3 Các k thu t thu th p yêu c uỹ ậ ậ ầ
• Ph ng v n (Interviews): ỏ ấ B c 1 Ch n ng i ướ ọ ườđ c ph ng v nựơ ỏ ấ D a vào các thông tin c n thu th pự ầ ậ Ch n ng i đ c ph ng v n các v trí khác nhau đ ọ ườ ựơ ỏ ấ ở ị ể
có thông tin t nhi u góc đ :ừ ề ộ Ng i qu n lýườ ả Ng i s d ngườ ử ụ Nh ng ng i có nh h ng ho c b nh h ng b i h th ng ữ ườ ả ưở ặ ị ả ưở ở ệ ố
m i (stakeholder)ớ
165/Chapter© DHBK 2007
4.1.3 Các k thu t thu th p yêu c uỹ ậ ậ ầ4.1.3 Các k thu t thu th p yêu c uỹ ậ ậ ầ
• Ph ng v n (Interviews): ỏ ấ B c 2 : thi t k câu h i ướ ế ế ỏph ng v n, 3 lo i câu h i:ỏ ấ ạ ỏ Câu h i đóng (close ended)ỏ Câu h i m (open-ended)ỏ ở Câu h i dò (probing)ỏ
166/Chapter© DHBK 2007
4.1.3 Các k thu t thu th p yêu c uỹ ậ ậ ầ4.1.3 Các k thu t thu th p yêu c uỹ ậ ậ ầ
• Ph ng v n (Interviews): ỏ ấ B c 2 : thi t k câu h i ướ ế ế ỏph ng v n, 3 lo i:ỏ ấ ạ
Types of Questions 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?
167/Chapter© DHBK 2007
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): ỏ ấ 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ự ệ ạ ướ ủ ự
168/Chapter© DHBK 2007
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): ỏ ấ B c 2 : thi t k câu h i ướ ế ế ỏph ng v n, 2 chi n l c: top-down, bottom upỏ ấ ế ượ
169/Chapter© DHBK 2007
4.1.3 Các k thu t thu th p yêu c uỹ ậ ậ ầ4.1.3 Các k thu t thu th p yêu c uỹ ậ ậ ầ
• Ph ng v n (Interviews): ỏ ấ B c 3: chu n b cho ướ ẩ ịcu c ph ng v nộ ỏ ấ Chu n b k ho ch ph ng v n t ng thẩ ị ế ạ ỏ ấ ổ ế
Li t kê các câu h iệ ỏ D đoán tr c câu tr l i và câu h i ti p theoự ướ ả ờ ỏ ế
Kh ng đ nh l i lĩnh v c ki n th cẳ ị ạ ự ế ứ Xác đ nh các câu h i, lĩnh v c u tiên trong tr ng ị ỏ ự ư ườ
h p không đ th i gianợ ủ ờ Chu n b cho ng i đ c ph ng v nẩ ị ườ ượ ỏ ấ
X p l chế ị Thông báo lý do ph ng v nỏ ấ Thông báo các lĩnh v c th o lu nự ả ậ
170/Chapter© DHBK 2007
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): ỏ ấ B c 4: th c hi n cu c ướ ự ệ ộph ng v nỏ ấ Ph i gây đ c thi n c m v i ng i đ c ph ng v n: ả ượ ệ ả ớ ườ ượ ỏ ấ
t ra chuyên nghi p và không thiên vỏ ệ ị ghi l i t t c thông tinạ ấ ả Ki m tra v chính sách ghi âm cu c ph ng v n ể ề ộ ỏ ấ Ph i đ m b o hi u t t c các v n đ và thu t ng ả ả ả ể ấ ả ấ ề ậ ữ Phân bi t rõ s ki n v i ý ki n bình lu n ệ ự ệ ớ ế ậ Dành th i gian cho ng i đ c ph ng v n đ t câu h iờ ườ ựơ ỏ ấ ặ ỏ Nh c m n ng i đ c ph ng v n và thông báo ớ ả ơ ườ ượ ỏ ấ
công vi c ti p theo sau cu c ph ng v nệ ế ộ ỏ ấ K t thúc đúng giế ờ
171/Chapter© DHBK 2007
4.1.3 Các k thu t thu th p yêu c uỹ ậ ậ ầ4.1.3 Các k thu t thu th p yêu c uỹ ậ ậ ầ
• Ph ng v n (Interviews): ỏ ấ B c 4: th c hi n cu c ướ ự ệ ộph ng v n, practical tipsỏ ấ Don’t worry, be happy Pay attention Summarize key points Be succinct Be honest Watch body language
172/Chapter© DHBK 2007
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): ỏ ấ B c 5: Công vi c sau ướ ệph ng v nỏ ấ Chu n b báo cáo v cu c ph ng v n trong vòng 48 ẩ ị ề ộ ỏ ấ
ti ngế G i báo cáo cho ng i đ c ph ng v n đ s a ch a, ử ườ ượ ỏ ấ ể ử ữ
b sung n u c nổ ế ầ
173/Chapter© DHBK 2007
4.1.3 Các k thu t thu th p yêu c uỹ ậ ậ ầ4.1.3 Các k thu t thu th p yêu c uỹ ậ ậ ầ
• Ph ng v n (Interviews): ỏ ấ B c 5: Công vi c sau ướ ệph ng v nỏ ấ
INTERVIEW REPORT
Interview notes approved by: ____________
Person interviewed ______________Interviewer _______________Date _______________Primary Purpose:
Summary of Interview:
Open Items:
Detailed Notes:
174/Chapter© DHBK 2007
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ỹ ậ ậ ầ
• JAD: Allows project managers, users, and developers to
work together to identify requirements May reduce scope creep by 50% Avoids requirements being too specific or too vague
175/Chapter© DHBK 2007
4.1.3 Các k thu t thu th p yêu c uỹ ậ ậ ầ4.1.3 Các k thu t thu th p yêu c uỹ ậ ậ ầ
• JAD: L a ch n ng i tham d và vai trò t ng ự ọ ườ ự ừng iườ Facilitator
sets the meeting agenda and guides the discussion
Scribe assist the facilitator by recording notes, making copies, etc.
Project team, users, and management
176/Chapter© DHBK 2007
4.1.3 Các k thu t thu th p yêu c uỹ ậ ậ ầ4.1.3 Các k thu t thu th p yêu c uỹ ậ ậ ầ
• JAD: Thi t l p cu c h pế ậ ộ ọ U-Shaped seating Away from distractions Whiteboard/flip chart Prototyping tools e-JAD
177/Chapter© DHBK 2007
4.1.3 Các k thu t thu th p yêu c uỹ ậ ậ ầ4.1.3 Các k thu t thu th p yêu c uỹ ậ ậ ầ
• JAD: phiên h p JADọ Tend to last 5 to 10 days over a three week period Prepare questions as with interviews Formal agenda and groundrules Facilitator activities
Keep session on track Help with technical terms and jargon Record group input Help resolve issues
Post-session follow-up
178/Chapter© DHBK 2007
4.1.3 Các k thu t thu th p yêu c uỹ ậ ậ ầ4.1.3 Các k thu t thu th p yêu c uỹ ậ ậ ầ
• JAD: Qu n lý v n đ trong phiên h p JADả ấ ề ọ Reducing domination Encouraging non-contributors Side discussions Agenda merry-go-round Violent agreement Unresolved conflict True conflict Use humor
179/Chapter© DHBK 2007
4.1.3 Các k thu t thu th p yêu c uỹ ậ ậ ầ4.1.3 Các k thu t thu th p yêu c uỹ ậ ậ ầ
• JAD: Phòng h pọ
180/Chapter© DHBK 2007
4.1.3 Các k thu t thu th p yêu c uỹ ậ ậ ầ4.1.3 Các k thu t thu th p yêu c uỹ ậ ậ ầ
• Đi u tra (Questionnaire), các b c:ề ướ Selecting participants
Using samples of the population Designing the questionnaire
Careful question selection Administering the questionnaire
Working to get good response rate Questionnaire follow-up
Send results to participants
181/Chapter© DHBK 2007
4.1.3 Các k thu t thu th p yêu c uỹ ậ ậ ầ4.1.3 Các k thu t thu th p yêu c uỹ ậ ậ ầ
• Đi u tra (Questionnaire),ề thi t k :ế ế Begin with non-threatening and interesting questions. Group items into logically coherent sections. Do not put important items at the very end of the
questionnaire. Do not crowd a page with too many items. Avoid abbreviations. Avoid biased or suggestive items or terms. Number questions to avoid confusion. Pretest the questionnaire to identify confusing
questions. Provide anonymity to respondents.
182/Chapter© DHBK 2007
4.1.3 Các k thu t thu th p yêu c uỹ ậ ậ ầ4.1.3 Các k thu t thu th p yêu c uỹ ậ ậ ầ
• Phân tích tài li u:ệ Document analysis is used to provides clues about
existing “as-is” system Typical documents used
Forms Reports Policy manuals Organization chart
Look for user additions to forms Look for unused form elements
183/Chapter© DHBK 2007
4.1.3 Các k thu t thu th p yêu c uỹ ậ ậ ầ4.1.3 Các k thu t thu th p yêu c uỹ ậ ậ ầ
• Quan sát: Users/managers often don’t remember everything they
do Checks validity of information gathered other ways Behaviors change when people are watched Careful not to ignore periodic activities
Weekly … Monthly … Annual
184/Chapter© DHBK 2007
4.1.3 Các k thu t thu th p yêu c uỹ ậ ậ ầ4.1.3 Các k thu t thu th p yêu c uỹ ậ ậ ầ
• L a ch n k thu t thích h p:ự ọ ỹ ậ ợ
185/Chapter© DHBK 2007
4.1.4 CD selections4.1.4 CD selections
Requirement Determination• Requirement Analysis Techniques
Select BPI techniques to identify how to improve the current order process using a new web-based system
Using several JAD session including store managers, marketing analysts and Wed developers (the working group) to work through BPI techniques and brainstorm
Further apply informal benchmarking with Web-sites of several leading retailers and discuss with the working group
The output is a list of suggested business requirements for the project team
186/Chapter© DHBK 2007
4.1.4 CD selections4.1.4 CD selections
Requirement Determination• Requirement-gathering Techniques
The project team applies document analysis, interview and observation techniques
Firstly apply document analysis to understand the current order processes (i.e., the as-is system). If anything is not clear, use interview to clarify
Secondly interview senior analysts to get better ideas about as-is and to-be systems and IT contractor to understand the existing IT system
Thirdly observe in stores to see the real working process of as-is system
• The above activities at the end produces the requirement definition (report)
• Further JAD sessions are used to finalise and prioritise the requirement definition (report)
187/Chapter© DHBK 2007
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
188/Chapter© DHBK 2007
4.2.1 Gi i thi uớ ệ4.2.1 Gi i thi uớ ệ
• B c chu n bướ ẩ ị : Thu th p các yêu c u t ng i ậ ầ ừ ườs d ng ử ụ (ph n ầ 4.1).
• B c 1: S d ng các yêu c u thu th p đ c, mô ướ ử ụ ầ ậ ượhình quá trình kinh doanh s d ng bi u đ ho t ử ụ ể ồ ạđ ng (ộ activity diagrams)
• B c 2: S d ng các ho t đ ng đã xác đ nh đ ướ ử ụ ạ ộ ị ểxác đ nh các ca s d ngị ử ụ .
• B c 3: Xây d ng b n mô t ca s d ng cho m i ướ ự ả ả ử ụ ỗca s d ngử ụ
• B c 4: Chuy n t b n mô t ca s d ng sang ướ ể ử ả ả ử ụbi u đ ca s d ng đ bi u di n ch c năng và ể ồ ử ụ ể ể ễ ứho t đ ng bên ngoài c a quá trình kinh doanhạ ộ ủ
• -> chuy n sang mô hình hoá c u trúc (ph n 4.3)ể ấ ầ
189/Chapter© DHBK 2007
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ự ể ồ ạ ộ
190/Chapter© DHBK 2007
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)ồ ạ ộ
• 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
191/Chapter© DHBK 2007
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 (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ế ộ ồ ề ể ặ ồ ố ượ
192/Chapter© DHBK 2007
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 (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]ề ệ
193/Chapter© DHBK 2007
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 (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ể ế ợ ồ ạ ộ
194/Chapter© DHBK 2007
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)ồ ạ ộ
195/Chapter© DHBK 2007
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)ồ ạ ộ
• 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ẽ ể ồ ạ ộ
196/Chapter© DHBK 2007
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)ồ ạ ộ
• 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
197/Chapter© DHBK 2007
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)ồ ạ ộ
• 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
198/Chapter© DHBK 2007
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)ồ ạ ộ
• 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]
199/Chapter© DHBK 2007
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ố
200/Chapter© DHBK 2007
4.2.3 Mô t ca s d ngả ử ụ4.2.3 Mô t ca s d ngả ử ụ
• 2 b c đ xây d ng bi u đ ca s d ngướ ể ự ể ồ ử ụ Vi t b n mô t ca s d ng ế ả ả ử ụChuy n t b n mô t ca s d ng sang bi u đ ca s ể ừ ả ả ử ụ ể ồ ử
d ngụ
• M i m t ca s d ng ch miêu t duy nh t m t ỗ ộ ử ụ ỉ ả ấ ộch c năng c a h th ng ứ ủ ệ ố
• Đ xác đ nh n i dung c a ca s d ng, ng i phát ể ị ộ ủ ử ụ ườtri n h th ng ph i làm vi c cùng v i ng i s ể ệ ố ả ệ ớ ườ ửd ngụ
201/Chapter© DHBK 2007
4.2.3 Mô t ca s d ngả ử ụ4.2.3 Mô t ca s d ngả ử ụ
• Các thành ph n c a b n mô t ca s d ng:ầ ủ ả ả ử ụ
Use Case Name: 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:
202/Chapter© DHBK 2007
4.2.3 Mô t ca s d ngả ử ụ4.2.3 Mô t ca s d ngả ử ụ
• Ví d : ụ
203/Chapter© DHBK 2007
4.2.3 Mô t ca s d ngả ử ụ4.2.3 Mô t ca s d ngả ử ụ
• Ví d : ụ
204/Chapter© DHBK 2007
4.2.3 Mô t ca s d ngả ử ụ4.2.3 Mô t ca s d ngả ử ụ
• Ví d : ụ
205/Chapter© DHBK 2007
4.2.3 Mô t ca s d ngả ử ụ4.2.3 Mô t ca s d ngả ử ụ
• 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.
206/Chapter© DHBK 2007
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
207/Chapter© DHBK 2007
4.2.4 Bi u đ ca s d ngể ồ ử ụ4.2.4 Bi u đ ca s d ngể ồ ử ụ
208/Chapter© DHBK 2007
4.2.4 Bi u đ ca s d ngể ồ ử ụ4.2.4 Bi u đ ca s d ngể ồ ử ụ
209/Chapter© DHBK 2007
4.2.4 Bi u đ ca s d ngể ồ ử ụ4.2.4 Bi u đ ca s d ngể ồ ử ụ
210/Chapter© DHBK 2007
4.2.4 Bi u đ ca s d ngể ồ ử ụ4.2.4 Bi u đ ca s d ngể ồ ử ụ
211/Chapter© DHBK 2007
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ướ ẽ ể ồ ử ụ
212/Chapter© DHBK 2007
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ể ồ ử ụ
• 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ầ
213/Chapter© DHBK 2007
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ể ồ ử ụ
• 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
214/Chapter© DHBK 2007
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ể ồ ử ụ
• 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
Distribution system
Place order Customer Customer Maintain order
Maintain order Customer
215/Chapter© DHBK 2007
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ể ồ ử ụ
• 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ứ ệ ố ứ
216/Chapter© DHBK 2007
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ể ồ ử ụ
• B c II: Ví d : k t qu sau b c 7ướ ụ ế ả ướ
217/Chapter© DHBK 2007
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ể ồ ử ụ
• B c II:ướ Ví d : k t qu sau b c 8ụ ế ả ướ
218/Chapter© DHBK 2007
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ể ồ ử ụ
• B c II:ướ Ví d : k t qu sau b c 11ụ ế ả ướ
219/Chapter© DHBK 2007
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ể ồ ử ụ
• B c II:ướ Ví d : k t qu sau b c 11ụ ế ả ướ
220/Chapter© DHBK 2007
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ể ồ ử ụ
• 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ượ ị
221/Chapter© DHBK 2007
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ể ồ ử ụ
• 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ẽ ệ
222/Chapter© DHBK 2007
Use case name Primary actor Relationship
Association Include Extend
Maintain marketing information
Vendor Vendor
Maintain CD information
Distribution system
Distribution system
Place order Customer Customer Check out Maintain order
Check out Customer Customer, Credit Centre
Maintain order
Maintain order Customer Place Instore hold
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
223/Chapter© DHBK 2007
Maintain CD marketing information
Maintain CD 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
224/Chapter© DHBK 2007
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ự ẻ ể ồ ớ
225/Chapter© DHBK 2007
4.3.1 Gi i thi uớ ệ4.3.1 Gi i thi uớ ệ
M c đích c a mô hình c u trúc: ụ ủ ấ• Mô t c u trúc c a d li u đ c s d ng trong h ả ấ ủ ữ ệ ượ ử ụ ệ
th ng.ố• Rút ng n kho ng cách gi a th gi i th c và th ắ ả ữ ế ớ ự ế
gi i ph n m mớ ầ ề• Xây d ng thu t ng chung cho ng i s d ng và ự ậ ữ ườ ử ụ
ng i phân tích h th ng ườ ệ ố• Bi u di n s v t, ý t ng và khái ni m quan tr ng ể ễ ự ậ ưở ệ ọ
trong h th ngệ ốCác mô hình c u trúc: ấ• CRC cards, class diagrams, object diagrams.
226/Chapter© DHBK 2007
4.3.2 Các ph n t c a mô hình c u trúcầ ử ủ ấ4.3.2 Các ph n t c a mô hình c u trúcầ ử ủ ấ
• L p (Classes)ớ Ki u d li u đ đ nh nghĩa đ i t ng (Templates for ể ữ ệ ể ị ố ượ
creating instances or objects) C th (Concrete)ụ ể Tr u t ng (Abstract)ừ ượ
• Thu c tính (Attributes)ộ Đ n v thông tin liên quan đ n vi c miêu t l pơ ị ế ệ ả ớ Ch nên đ a vào các thu c tính quan tr ngỉ ư ộ ọCác thu c tính ph i có ki u c b n: nguyên, xâu, ngày, ộ ả ể ơ ả
tháng, boolean ….Các thu c tính ph c t p đ c bi u di n b ng quan h ộ ứ ạ ựơ ể ễ ằ ệ
(relationship) gi a các l pữ ớ
227/Chapter© DHBK 2007
4.3.2 Các ph n t c a mô hình c u trúcầ ử ủ ấ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ệ ữ ớ
228/Chapter© DHBK 2007
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ả ủ ộ ớ
229/Chapter© DHBK 2007
4.3.3 Th CRC (Class-Responsibility-ẻ4.3.3 Th CRC (Class-Responsibility-ẻCollaboration)Collaboration)
230/Chapter© DHBK 2007
4.3.3 Th CRC (Class-Responsibility-ẻ4.3.3 Th CRC (Class-Responsibility-ẻCollaboration)Collaboration)
231/Chapter© DHBK 2007
4.3.4 Bi u đ l pể ồ ớ4.3.4 Bi u đ l pể ồ ớ
232/Chapter© DHBK 2007
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____
233/Chapter© DHBK 2007
4.3.4 Bi u đ l pể ồ ớ4.3.4 Bi u đ l pể ồ ớ
• Thu c tính:ộDerived attributes
/age, for example can be calculated from birth date and current date
VisibilityPublic: +Protected: #Private: -
234/Chapter© DHBK 2007
4.3.4 Bi u đ l pể ồ ớ4.3.4 Bi u đ l pể ồ ớ
• Ho t đ ng (operations):ạ ộConstructor
Creates object
QueryMakes information about state available
UpdateChanges values of some or all attributes
235/Chapter© DHBK 2007
4.3.4 Bi u đ l pể ồ ớ4.3.4 Bi u đ l pể ồ ớ
• 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
236/Chapter© DHBK 2007
4.3.4 Bi u đ l pể ồ ớ4.3.4 Bi u đ l pể ồ ớ
• Bi u đ đ i t ng: c th hóa bi u đ l pể ồ ố ượ ụ ể ể ồ ớ
237/Chapter© DHBK 2007
4.3.5 Xây d ng th CRC và bi u đ l pự ẻ ể ồ ớ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
238/Chapter© DHBK 2007
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ự ẻ ể ồ ớ
• 1.Create CRC cards by performing textual analysis on the use-cases.
• 2. Brainstorm additional candidate classes, attributes, operations, and relationships by using the common object list approach.
• 3. Role-play each use-case using the CRC cards.• 4. Create the class diagram based on the CRC cards.• 5. Review the class diagrams and structural model for
missing and/or unnecessary classes, attributes, operations, and relationships.
• 6. Incorporate useful patterns.• 7. Review the structural model.
239/Chapter© DHBK 2007
4.3.5 Xây d ng th CRC và bi u đ l pự ẻ ể ồ ớ4.3.5 Xây d ng th CRC và bi u đ l pự ẻ ể ồ ớ
CD Selections
240/Chapter© DHBK 2007
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
241/Chapter© DHBK 2007
• 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
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: Nouns suggest classes
242/Chapter© DHBK 2007
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
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
243/Chapter© DHBK 2007
• 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
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: Verbs suggest operations:
244/Chapter© DHBK 2007
• Textual Analysis Result: Combine “nouns and verbs” analysis, the back of “Customer class” CRC Card can be
Order; Search request; Credit Card Centre
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
245/Chapter© DHBK 2007
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
246/Chapter© DHBK 2007
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
247/Chapter© DHBK 2007
Step 4. Step 4. Create the Class Diagram based on the CRC Create the Class Diagram based on the CRC CardsCards
• Solution:
Customer-First name-Middle initial-Last name-……+Make search req()+Place order()+Get credit info()+Exit()
Credit Card CentreOrder
Search Reg
Check >0..*
0..*
place >
0..*1
Make >0..*0..*
248/Chapter© DHBK 2007
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.
249/Chapter© DHBK 2007
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ể ồ ạ
250/Chapter© DHBK 2007
4.4.1 Gi i thi uớ ệ4.4.1 Gi i thi uớ ệ
• M c đích c a mô hình ho t đ ng:ụ ủ ạ ộMiêu t cách th c các đ i t ng trong mô hình c u trúc ả ứ ố ượ ấ
t ng tác v i nhau trong m i ca s d ng ươ ớ ỗ ử ụMiêu t ho t đ ng bên trong c a h th ng ả ạ ộ ủ ệ ốMiêu t nh h ng c a các ho t đ ng t i h th ng ả ả ưở ủ ạ ộ ớ ệ ốĐ c s d ng đ ki m tra và thay đ i các mô hình ượ ử ụ ể ể ổ
ch c năng và mô hình c u trúc ứ ấ
• Các lo i mô hình ho t đ ng:ạ ạ ộBi u đ t ng tác (Interaction Diagrams)ể ồ ươ
Bi u đ tu n t (sequence diagram)ể ồ ầ ựBi u đ giao ti p (c ng tác) (communication diagram)ể ồ ế ộ
Bi u đ máy tr ng thái (Behavioral state machine ể ồ ạdiagram)
251/Chapter© DHBK 2007
4.4.2 Bi u đ t ng tácể ồ ươ4.4.2 Bi u đ t ng tácể ồ ươ
• Các ph n t c b n:ầ ử ơ ảĐ i t ng (Objects)ố ượ
1 b n sao c a l pả ủ ớ Có các thu c tính miêu t đ i t ngộ ả ố ượ
Ho t đ ng (Operations)ạ ộTruy n ho c nh n thông đi pề ặ ậ ệ
Thông đi p (Messages)ệ Ch th cho đ i t ng th c hi n m t ho t đ ng ỉ ị ố ượ ự ệ ộ ạ ộ
252/Chapter© DHBK 2007
4.4.2 Bi u đ t ng tácể ồ ươ4.4.2 Bi u đ t ng tácể ồ ươ
• Bi u đ tu n t (sequence diagram)ể ồ ầ ựMiêu t các đ i t ng tham gia vào 1 ca s d ngả ố ượ ử ụBi u di n các thông đi p đ c truy n gi a các đ i ể ễ ệ ượ ề ữ ố
t ng trong 1 ca s d ngượ ử ụ
253/Chapter© DHBK 2007
4.4.2 Bi u đ t ng tácể ồ ươ4.4.2 Bi u đ t ng tácể ồ ươ
• Bi u đ tu n t (sequence diagram): ví dể ồ ầ ự ụ
254/Chapter© DHBK 2007
4.4.2 Bi u đ t ng tácể ồ ươ4.4.2 Bi u đ t ng tácể ồ ươ
• Bi u đ tu n t (sequence diagram): Các ph n tể ồ ầ ự ầ ử
255/Chapter© DHBK 2007
4.4.2 Bi u đ t ng tácể ồ ươ4.4.2 Bi u đ t ng tácể ồ ươ
• Bi u đ tu n t (sequence diagram): Các ph n tể ồ ầ ự ầ ử
256/Chapter© DHBK 2007
4.4.2 Bi u đ t ng tácể ồ ươ4.4.2 Bi u đ t ng tácể ồ ươ
• 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 để ạ ể ồ
257/Chapter© DHBK 2007
Normal Flow of Events:
1. Customer submits a search request to the system.2. The system provides the customer a list of recommended CDs.3. The customer chooses one of the CDs to find additional information.4. The system provides the customer with basic (market) information & CD 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:
258/Chapter© DHBK 2007Application Example:
259/Chapter© DHBK 2007
4.4.2 Bi u đ t ng tácể ồ ươ4.4.2 Bi u đ t ng tácể ồ ươ
• Bi u đ giao ti p (communication diagram)ể ồ ếT p trung miêu t t ng tác gi a các đ i t ng mà ậ ả ươ ữ ố ượ
không t p trung vào miêu t th i gian và trình t c a ậ ả ờ ự ủcác t ng tácươ
260/Chapter© DHBK 2007
4.4.2 Bi u đ t ng tácể ồ ươ4.4.2 Bi u đ t ng tácể ồ ươ
• Bi u đ giao ti p : Ví dể ồ ế ụ
261/Chapter© DHBK 2007
4.4.2 Bi u đ t ng tácể ồ ươ4.4.2 Bi u đ t ng tácể ồ ươ
• Bi u đ giao ti p : Các ph n tể ồ ế ầ ử
Actor
Object
Association
Message
262/Chapter© DHBK 2007
4.4.2 Bi u đ t ng tácể ồ ươ4.4.2 Bi u đ t ng tácể ồ ươ
• 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ể ạ ể ồ ế
263/Chapter© DHBK 2007
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
264/Chapter© DHBK 2007
““CRUD” Analysis ExampleCRUD” Analysis Example
CC
265/Chapter© DHBK 2007
Normal Flow of Events:
1. Customer submits a search request to the system.2. The system provides the customer a list of recommended CDs.3. The customer chooses one of the CDs to find additional information.4. The system provides the customer with basic (market) information & CD 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:
266/Chapter© DHBK 2007Application Example:
267/Chapter© DHBK 2007
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.ộ ủ ố ượ ể ạ
268/Chapter© DHBK 2007
4.4.3 Bi u đ máy tr ng tháiể ồ ạ4.4.3 Bi u đ máy tr ng tháiể ồ ạ
Ví d :ụ
269/Chapter© DHBK 2007
4.4.3 Bi u đ máy tr ng tháiể ồ ạ4.4.3 Bi u đ máy tr ng tháiể ồ ạ
Các ph n t c a bi u đ máy tr ng thái:ầ ử ủ ề ồ ạ
270/Chapter© DHBK 2007
4.4.3 Bi u đ máy tr ng tháiể ồ ạ4.4.3 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:ầ ử ủ ề ồ ạ
271/Chapter© DHBK 2007
4.4.3 Bi u đ máy tr ng tháiể ồ ạ4.4.3 Bi u đ máy tr ng tháiể ồ ạ
• 5 b c xây d ng bi u đ máy tr ng thái:ướ ự ể ồ ạ1. Xác đ nh ng c nhị ữ ả2. Xác đ nh tr ng thái b t đ u, k t thúc và các tr ng thái ị ạ ắ ầ ế ạ
n đ nh c a đ i t ng ổ ị ủ ố ượ3. Xác đ nh th t c a các tr ng thái mà đ i t ng s ị ứ ự ủ ạ ố ượ ẽ
tr i qua ả4. Xác đ nh các s ki n, hành đ ng và đi u ki n c a m i ị ự ệ ộ ề ệ ủ ỗ
chuy n tr ng thái ể ạ5. Ki m traể
272/Chapter© DHBK 2007Application Example:
The Life of an Order Object:
273/Chapter© DHBK 2007Application Example:
274/Chapter© DHBK 2007
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ýế ế ớ ế ậ
275/Chapter© DHBK 2007
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ự ế ế ự ế
276/Chapter© DHBK 2007
• 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ế ế
277/Chapter© DHBK 2007
• 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
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ế ế
278/Chapter© DHBK 2007
• 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)
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ế ế
279/Chapter© DHBK 2007
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ế ế
• Layers
280/Chapter© DHBK 2007
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
281/Chapter© DHBK 2007
• 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.
5.1.2 Gói và bi u đ góiể ồ5.1.2 Gói và bi u đ góiể ồ
282/Chapter© DHBK 2007
5.1.2 Gói và bi u đ góiể ồ5.1.2 Gói và bi u đ góiể ồ
A PACKAGE Package
A DEPENDENCY RELATIONSHIP
283/Chapter© DHBK 2007
5.1.2 Gói và bi u đ góiể ồ5.1.2 Gói và bi u đ góiể ồVí dụVí dụ
284/Chapter© DHBK 2007
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ể ồ
285/Chapter© DHBK 2007
Package Diagram of Appointment SystemPackage Diagram of Appointment System
Patient UI
dependent on Patient class
DMPatient class
dependent on Patient class
Patient table
dependent on Patient class
Problem domain Classes:Patient, Appt.
Separated from object persistence Classes: Patient table,Appt. table
by intermediate Data Access and Manipulation (DM) Classes: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
286/Chapter© DHBK 2007
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ể ồ
287/Chapter© DHBK 2007
Step 1: Set the context, i.e. model a partition or a layer, e.g. for appointments system we might choose
context = problem domain (PD) layer
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
289/Chapter© DHBK 2007
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
290/Chapter© DHBK 2007
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
291/Chapter© DHBK 2007
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)
294/Chapter© DHBK 2007• Keep classes in a generalisation hierarchy together =
cluster Customer, Individual and Organisation(al) classes into partition
• Aggregation relationships = cluster Mkt Info, Review, Artist Info, Sample Clip classes into partition
295/Chapter© DHBK 2007• Association relationship (between CD class and Mkt Info class) and message sending pattern of activity = place in same partition
• Also, Vendor class only related to CD class = same partition (as CD and Market Info classes)
• Recall, cluster Mkt Info, Review, Artist Info, Sample Clip classes into partition
• Order Class and Order Item Class = partition
• Search Req Class and CD List Class = partition
296/Chapter© DHBK 2007• Model each partition as a package
n.b. Credit Card Centre not yet contained in a package
Identify dependency relationships between packages = Customer Package + Order Package, Customer Package + Search Package, Order Package + CD Package, Search Package + CD Package (also between Credit Card Centre + Customer package)
297/Chapter© DHBK 2007Place the dependency relations on the package diagram (and increase clarity by dependency Place the dependency relations on the package diagram (and increase clarity by dependency
relationships between packages = pure package diagram of PD layer of CD Selections containing relationships between packages = pure package diagram of PD layer of CD Selections containing highest level packages only (+ Credit Card Centre class) and their dependency relationshipshighest level packages only (+ Credit Card Centre class) and their dependency relationships
298/Chapter© DHBK 2007
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
299/Chapter© DHBK 2007
5.1.3 Các chi n l c thi t kế ượ ế ế5.1.3 Các chi n l c thi t kế ượ ế ế
• Packaged Software
Software already written – so available, “as is”For CD selections, could use “shopping cart” software installed
into existing web page Potentially more efficient, better tested (even proven!) - because
developers/implementors more skilled in techniques used to specify/design + implement, test (or even prove!)For CD selections, “shopping cart” is freely available “software
tool”, other simple components also available, e.g. ActiveX controls, Java “beans”, whole approach scales-up to Enterprise Resource Planning applications (ERP’s), e.g. SAP, Oracle
Functionality provided “as is” For CD selections, packed software may require change to
existing business practice, but could customise an order processing application, or “work around” via custom-built application that “wraps around” packaged software giving additional functionality
300/Chapter© DHBK 2007
5.1.3 Các chi n l c thi t kế ượ ế ế5.1.3 Các chi n l c thi t kế ượ ế ế
• Packaged Software (cont.)
Systems Integration: building new systems from combinations of packaged software, existing legacy systems and new custom developed software to integrate these together.
Problem is usually integrating data, different formats must be resolved
For CD selections, integrating data in new online order system with data in legacy distribution application may be problematic
Could develop “object wrapper” around legacy system (and its data) so that new object oriented web based ordering system can send messages to the “wrapper”
301/Chapter© DHBK 2007
5.1.3 Các chi n l c thi t kế ượ ế ế5.1.3 Các chi n l c thi t kế ượ ế ế
• Outsourcing – (now increasingly popular) = pay external vendor, developer, service provider to create system
For CD selections, use a Web Service Provider who provides commercial order taking system
Potentially external suppliers have higher level of 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
302/Chapter© DHBK 2007
5.1.3 Các chi n l c thi t kế ượ ế ế5.1.3 Các chi n l c thi t kế ượ ế ế
• 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
303/Chapter© DHBK 2007
5.1.3 Các chi n l c thi t kế ượ ế ế5.1.3 Các chi n l c thi t kế ượ ế ế
• Select a strategy (1): Business need
Common business needs best served by packaged systems, i.e. when custom built alternative does not require any special business needs, when system is not critical to company
In-house 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
304/Chapter© DHBK 2007
5.1.3 Các chi n l c thi t kế ượ ế ế5.1.3 Các chi n l c thi t kế ượ ế ế
• Select a strategy (2): Project management
Custom applications require significant project management via application of a proven system development methodology (or collection of integrated methods)
Packaged and outsourced systems require different kinds of management, e.g. of contract and delivery
Time 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
305/Chapter© DHBK 2007
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)
306/Chapter© DHBK 2007
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ể ế ế ự ế
307/Chapter© DHBK 2007
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ị ươ ứ
308/Chapter© DHBK 2007
5.2.1 Gi i thi uớ ệ5.2.1 Gi i thi uớ ệ
• Các m c tr u t ng c a h th ng h ng đ i t ngứ ừ ượ ủ ệ ố ướ ố ượ
309/Chapter© DHBK 2007
5.2.2 Các tiêu chí thi t kế ế5.2.2 Các tiêu chí thi t kế ế
• Coupling• Cohesion• Connascence
310/Chapter© DHBK 2007
5.2.2 Các tiêu chí thi t kế ế5.2.2 Các tiêu chí thi t kế ế
• Coupling: Indicates the interdependence or interrelationships of the modules
Interaction coupling Relationships with methods and objects through message passage
Inheritance coupling Deals with how tightly coupled the classes are in an inheritance hierarchy
311/Chapter© DHBK 2007
5.2.2 Các tiêu chí thi t kế ế5.2.2 Các tiêu chí thi t kế ế
Types of interaction coupling
312/Chapter© DHBK 2007
5.2.2 Các tiêu chí thi t kế ế5.2.2 Các tiêu chí thi t kế ế
• Interaction coupling: Law of Demeter = minimise number of objects that can receive
messages from a given object Objects only send message to:
A) 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
313/Chapter© DHBK 2007
5.2.2 Các tiêu chí thi t kế ế5.2.2 Các tiêu chí thi t kế ế
• Cohesion: Refers to how single-minded a module is within a system 3 types of cohesion:
MethodClass Generalization/specialization
314/Chapter© DHBK 2007
5.2.2 Các tiêu chí thi t kế ế5.2.2 Các tiêu chí thi t kế ế
• Cohesion: Method cohesion:
Address the cohesion within an individual method. Methods should do one and only one thing
315/Chapter© DHBK 2007
5.2.2 Các tiêu chí thi t kế ế5.2.2 Các tiêu chí thi t kế ế
• Cohesion: Class cohesion:
Is the level of cohesion among the attributes and methods of a class A class should only represent one 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
316/Chapter© DHBK 2007
5.2.2 Các tiêu chí thi t kế ế5.2.2 Các tiêu chí thi t kế ế
• Cohesion: Class cohesion:
317/Chapter© DHBK 2007
5.2.2 Các tiêu chí thi t kế ế5.2.2 Các tiêu chí thi t kế ế
• Cohesion: Generalization/specialization cohesion:
Addresses the sensibility of the inheritance hierarchy
318/Chapter© DHBK 2007
5.2.2 Các tiêu chí thi t kế ế5.2.2 Các tiêu chí thi t kế ế
• Connascence: Two modules (classes or methods) are so intertwined, that if you
make a change in one, it is likely that a change in the other will be required
Connascence and 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.
319/Chapter© DHBK 2007
5.2.2 Các tiêu chí thi t kế ế5.2.2 Các tiêu chí thi t kế ế
• Connascence:
320/Chapter© DHBK 2007
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
321/Chapter© DHBK 2007
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: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
322/Chapter© DHBK 2007
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ạ ộ ế ế ố ượ
• 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
323/Chapter© DHBK 2007
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ạ ộ ế ế ố ượ
• 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
324/Chapter© DHBK 2007
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ạ ộ ế ế ố ượ
• 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)
325/Chapter© DHBK 2007
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ạ ộ ế ế ố ượ
• Identifying opportunities for reuse:
326/Chapter© DHBK 2007
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ạ ộ ế ế ố ượ
• 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
327/Chapter© DHBK 2007
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ạ ộ ế ế ố ượ
• 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
328/Chapter© DHBK 2007
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ạ ộ ế ế ố ượ
• 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
329/Chapter© DHBK 2007
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ạ ộ ế ế ố ượ
• 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
330/Chapter© DHBK 2007
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ạ ộ ế ế ố ượ
• 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
331/Chapter© DHBK 2007
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ạ ộ ế ế ố ượ
• 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
332/Chapter© DHBK 2007
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ạ ộ ế ế ố ượ
• Map Problem Domain Classes to Implementation Languages:
[1] design uses multiple inheritance, language has only single inheritance
SuperClass1-attribute1-attribute2
SuperClass2-attribute3-attribute4
SuperClass3-attribute7-attribute8
Class1-attribute5-attribute6
Class2-attribute5-attribute6
concrete
0..*
1..1
0..*
1..1
{XOR} [1]All classes preserved[2]Increases amountof message passing[3]Adds to processing requirement due to XOR
333/Chapter© DHBK 2007
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ạ ộ ế ế ố ượ
• Map Problem Domain Classes to Implementation Languages:
[1] design uses multiple inheritance, language has only single inheritance
SuperClass1-attribute1-attribute2
SuperClass2-attribute3-attribute4
SuperClass3-attribute7-attribute8
Class1
-attribute5-attribute6
Class2
-attribute5-attribute6
-attribute3-attribute4
-attribute3-attribute4
PotentialInheritanceConflicts
abstract
334/Chapter© DHBK 2007
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ạ ộ ế ế ố ượ
• Map Problem Domain Classes to Implementation Languages:
[2] implementation language is object-based and not class-basedNeed to factor out ALL uses of inheritance from problem-domain
class design
SuperClass1-attribute1-attribute2
SuperClass2-attribute3-attribute4
SuperClass3-attribute7-attribute8
Class1-attribute5-attribute6
Class2-attribute5-attribute6
All superclasses concrete
0..*
1..1
0..*
1..1
{XOR}1..11..1
1..11..1
335/Chapter© DHBK 2007
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ạ ộ ế ế ố ượ
• Map Problem Domain Classes to Implementation Languages:
[2] implementation language is object-based and not class-based
SuperClass1-attribute1-attribute2
SuperClass2-attribute3-attribute4
SuperClass3-attribute7-attribute8
Class1
-attribute5-attribute6
Class2
-attribute5-attribute6
-attribute3-attribute4
-attribute3-attribute4
If all superclasses areabstract
-attribute7-attribute8
-attribute7-attribute8
-attribute1-attribute2
-attribute1-attribute2
PotentialInheritanceConflicts
336/Chapter© DHBK 2007
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ạ ộ ế ế ố ượ
• Map Problem Domain Classes to Implementation Languages:
[3] language is of another (less expressive) language paradigm, e.g. C or Pascal are of the imperative-procedural paradigmStay away from this!But if necessary, factor out all uses of
PolymorphismDynamic bindingEncapsulation Information hiding
337/Chapter© DHBK 2007
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
338/Chapter© DHBK 2007
5.2.4 Ràng bu c và giao kèoộ5.2.4 Ràng bu c và giao kèoộ
• Pre- and post-conditions model constraints on individual methods
• Invariants model constraints (that must always be true) for all instances of a class, e.g.Domains (in DB) or types (in design/programming
language) of 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
339/Chapter© DHBK 2007
• Example:-
Back:
Order Number (1:1) (unsigned long)Attributes:
Date (1..1) (Date)Sub Total (0..1) (double)Tax (0..1) (double) {Sub Total = sum(Product Order.GetExtension())}Shipping(0..1) (double)Total (0..1) (double)Customer (1..1) (Customer)Cust ID (1..1) (unsigned long) (Cust ID = Customer.GetCustID()}State (1..1) (State)StateName (String) {State Name = State.GetState()}
Relationships:Generalisation(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
340/Chapter© DHBK 2007
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..*
State
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())}}
341/Chapter© DHBK 2007
5.2.4 Ràng bu c và giao kèoộ5.2.4 Ràng bu c và giao kèoộ
• Contract: Contracts document message passing between objects, i.e.
messages sent to server objects by implementor’s client object, and values returned by server
Ideally a contract for each message sent and received by each object, i.e. one contract per interaction
In practice, one contract for each method that can receive messages from other objects, i.e. each visible method
Contracts are declarative = documents for client object’s implementor what the method 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
342/Chapter© DHBK 2007
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
343/Chapter© DHBK 2007
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
344/Chapter© DHBK 2007
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
345/Chapter© DHBK 2007
• 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:
346/Chapter© DHBK 2007
• 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