Phân tích và thi t k

ng i t ng (Object Oriented System Analysis and Design)
Gi ng viên: Ph m Ng c Nam

h

© DHBK 2007

2/Chapter

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 tích và thi t k h th ng ng pháp có h th ng phân

© DHBK 2007

3/Chapter

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

© DHBK 2007

4/Chapter

Tài li u tham kh o
‡ Systems Analysis and Design with UML Version 2.0-An object oriented approach; Alan Dennis, Barbara Haley Wixom, David Tegarden. ‡ www.uml.org ‡ www.rational.com ‡ www.Google.com

© DHBK 2007

Ch

ng 1. Gi i thi u chung v phân tích và thi t k h th ng

5/Chapter

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

© DHBK 2007

6/Chapter

1.1 Gi i thi u

© DHBK 2007

7/Chapter

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 dùng khi nào, âu? c

‡ Thi t k (Design)
H th ng s làm vi c nh th nào?

‡ Tri n khai (Implementation)
Tri n khai h th ng

© DHBK 2007

1.2 Quy trình phát tri n h th ng L p k ho ch

8/Chapter

‡ ‡ ‡ ‡ ‡

Xác nh giá tr kinh doanh c a h th ng Phân tích tính kh thi Xây d ng k ho ch công vi c Xác nh ngu n nhân l c cho d án i u khi n và qu n lý d án

© DHBK 2007

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

9/Chapter

‡ ‡ ‡ ‡

Phân tích h th ng Thu th p các ngu n thông tin Mô hình hoá quá trình Mô hình hóa d li u

© DHBK 2007

1.2 Quy trình phát tri n h th ng Thi t k

10/Chapter

‡ ‡ ‡ ‡ ‡

Xác nh chi n l c thi t k Thi t k c u trúc Thi t k giao di n Thi t k c s d li u Thi t k ch ng trình

© DHBK 2007

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

11/Chapter

‡ Xây d ng h th ng ‡ Cài t h th ng

© DHBK 2007

1.2 Quy trình phát tri n h th ng Các pha và k t qu c a t ng pha
Process Planning Product Project Plan

12/Chapter

Analysis

System Proposal

Design

System Specification New System and Maintenance Plan

Implementation

© DHBK 2007

1.3 Các ph

ng pháp phát tri n h th ng

13/Chapter

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

ng pháp phát tri n nhanh ng d ng (RAD)
ng pháp phát tri n theo các pha 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)

© DHBK 2007

14/Chapter

1.3.1 Thi t k c u trúc
‡ D án s ti n tri n t b c này sang b c ti p theo m t cách có h th ng ‡ Thông th ng, m t b c ph i c hoàn thành tr c khi b t u b c ti p theo

© DHBK 2007

1.3.1 Thi t k c u trúc Ph ng pháp thác n c

15/Chapter

© DHBK 2007

1.3.1 Thi t k c u trúc Ph ng pháp thác n c

16/Chapter

‡

u i m:
Tr c khi l p trình thì các yêu c u v h th ng c xác nh r t chi ti t và y => gi m thi u cs thay i v yêu c u trong quá trình phát tri n h th ng

‡ Nh

c i m:

Th i gian t khi xu t d án n khi có s n ph m cu i cùng th ng r t dài (vài tháng -> vài n m)

© DHBK 2007

Ph

1.3.1 Thi t k c u trúc ng pháp phát tri n song song

17/Chapter

© DHBK 2007

18/Chapter

1.3.2 RAD
‡ Các nhân t quan tr ng:
Công c CASE JAD Ngôn ng l p trình th h th t / visual Công c t o mã

© DHBK 2007

Ph

1.3.2 RAD ng pháp phát tri n theo pha

19/Chapter

© DHBK 2007

Ph

1.3.2 RAD ng pháp xây d ng nguyên m u thông th ng

20/Chapter

© DHBK 2007

Ph

1.3.2 RAD ng pháp xây d ng nguyên m u lo i b

21/Chapter

© DHBK 2007

22/Chapter

1.3.3 L a ch n ph
‡ Tiêu chí:

ng pháp phù h p
i s d ng

rõ ràng, y c a các yêu c u c a ng Kh n ng, m c thành th o v công ngh ph c t p c a h th ng tin c y c a h th ng Qu th i gian

© DHBK 2007

23/Chapter

1.3.3 L a ch n ph

ng pháp phù h p

© DHBK 2007

Ch ng 2: Gi i thi u v phân tích và thi t k h ng i t ng v i UML

24/Chapter

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

© DHBK 2007

25/Chapter

2.1 Gi i thi u
‡ L ch s phát tri n c a ngôn ng l p trình:
First Generation (1954 ± 1958)
Fortran I

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

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

Object Oriented Languages
Smalltalk, C++, Java

© DHBK 2007

26/Chapter

2.1 Gi i thi u
‡ L ch s phát tri n c a UML

© DHBK 2007

27/Chapter

2.1 Gi i thi u
‡ L ch s phát tri n c a UML
2003

UML 2.0
UML 1.4.1

UML 1.4 (action semantics) UML 1.3 (extensibility)

2002 2001 1998 1997

UML 1.1 (OMG Standard)
1996 Rumbaugh Booch Jacobson

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

© DHBK 2007

28/Chapter

2.1 Gi i thi u
‡ Thi t k c u trúc và thi t k h ng it ng

© DHBK 2007

29/Chapter

2.1 Gi i thi u
‡ Thi t k c u trúc và thi t k h ng it ng

© DHBK 2007

2.2 Các

c i m c b n c a h th ng h ng i t ng

30/Chapter

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)

© DHBK 2007

31/Chapter

2.2.1 L p và

it

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

© DHBK 2007

32/Chapter

2.2.1 L p và

it

ng

© DHBK 2007

33/Chapter

2.2.1 L p và
1 2 3 4 5 6 7 8 9 10 11 }; class Time { public: Time(); void setTime( int, int, int ); void printMilitary(); void printStandard(); private: int hour; int minute; int second; // 0 - 23 // 0 - 59 // 0 - 59

it

ng

© DHBK 2007

34/Chapter

2.2.2 Ph
‡ Ph

ng th c và message

ng th c (Methods) implement an object¶s behavior
Analogous to a function or procedure

‡ Messages are sent to trigger methods
Procedure call from one object to the next

© DHBK 2007

35/Chapter

2.2.2 Ph

ng th c và message

© DHBK 2007

36/Chapter

2.2.3 Tóm l
‡ Encapsulation

c và n thông tin

combination of data and process into an entity

‡ Information Hiding
Only the information required to use a software module is published to the user

© DHBK 2007

37/Chapter

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

© DHBK 2007

38/Chapter

2.2.4 Th a k

© DHBK 2007

39/Chapter

2.2.4 Th a k

© DHBK 2007

40/Chapter

2.2.5 a hình thái và liên k t
‡ Polymorphism

ng

A message can be interpreted differently by different classes of objects

‡ Dynamic Binding
Sometimes called late binding Delays typing or choosing a method for an object until run-time

‡ Static Binding
Type of object determined at compile time

© DHBK 2007

41/Chapter

2.2.5 a hình thái và liên k t

ng

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

// Fig. 20.1: shape.h // Definition of abstract base class Shape #ifndef SHAPE_H #define SHAPE_H class Shape { public: virtual double area() const { return 0.0; } virtual double volume() const { return 0.0; } // pure virtual functions overridden in derived classes virtual void printShapeName() const = 0; virtual void print() const = 0; }; #endif // Fig. 20.1: point1.h // Definition of class Point #ifndef POINT1_H #define POINT1_H #include <iostream> using std::cout; #include "shape.h" class Point : public Shape { public: Point( int = 0, int = 0 ); // default constructor void setPoint( int, int ); int getX() const { return x; } int getY() const { return y; }

34 virtual void printShapeName() const { cout << "Point: "; } 35 virtual void print() const; 36 private: 37 int x, y; // 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 50 51 } 52 53 void Point::print() const 54 { cout << '[' << x << ", " << y << ']'; } x = a; y = b;

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 64 65 66 67 68 69 70 void setRadius( double ); double getRadius() const; virtual double area() const; virtual void printShapeName() const { cout << "Circle: "; } virtual void print() const; // default constructor Circle( double r = 0.0, int x = 0, int y = 0 );

71 private: 72 73 }; 74 75 #endif double radius; // radius of Circle

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 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 94 95 void Circle::print() const 96 { 97 98 99 } Point::print(); cout << "; Radius = " << radius; { return 3.14159 * radius * radius; } : Point( a, b ) // call base-class constructor 86 { setRadius( r ); }

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 109 110 111 112 113 114 115 116 117 119 120}; 121 122#endif void setHeight( double ); double getHeight(); virtual double area() const; virtual double volume() const; virtual void printShapeName() const { cout << "Cylinder: "; } virtual void print() const; double height; // height of Cylinder // default constructor Cylinder( double h = 0.0, double r = 0.0, int x = 0, int y = 0 );

118private:

123// Fig. 20.1: cylindr1.cpp 124// Member and friend function definitions for class Cylinder 125#include <iostream> 126 127using std::cout; 128 129#include "cylindr1.h" 130 131Cylinder::Cylinder( double h, double r, int x, int y ) 132 : Circle( r, x, y ) // call base-class constructor 133{ setHeight( h ); } 134 135void Cylinder::setHeight( double h ) 136 { height = h > 0 ? h : 0; } 137 138double Cylinder::getHeight() { return height; } 139 140double Cylinder::area() const 141{ 142 // surface area of Cylinder 143 return 2 * Circle::area() + 144 2 * 3.14159 * getRadius() * height; 145} 146 147double Cylinder::volume() const 148 { return Circle::area() * height; } 149 150void Cylinder::print() const 151{ 152 Circle::print(); 153 cout << "; Height = " << height; 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

186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219

point.print(); cout << '\n'; circle.printShapeName(); circle.print(); cout << '\n';

// static binding

// static binding // static binding

cylinder.printShapeName(); // static binding cylinder.print(); // static binding cout << "\n\n"; Shape *arrayOfShapes[ 3 ]; // array of base-class pointers

// aim arrayOfShapes[0] at derived-class Point object arrayOfShapes[ 0 ] = &point; // aim arrayOfShapes[1] at derived-class Circle object arrayOfShapes[ 1 ] = &circle; // aim arrayOfShapes[2] at derived-class Cylinder object arrayOfShapes[ 2 ] = &cylinder; // Loop through arrayOfShapes and call virtualViaPointer // to print the shape name, attributes, area, and volume // of each object using dynamic binding. cout << "Virtual function calls made off " << "base-class pointers\n";

2. Function calls

for ( int i = 0; i < 3; i++ ) virtualViaPointer( arrayOfShapes[ i ] ); // Loop through arrayOfShapes and call virtualViaReference // to print the shape name, attributes, area, and volume // of each object using dynamic binding.

220 221 222 223 224 225 226 227} 228

cout << "Virtual function calls made off " << "base-class references\n"; for ( int j = 0; j < 3; j++ ) virtualViaReference( *arrayOfShapes[ j ] ); return 0;

229// Make virtual function calls off a base-class pointer 230// using dynamic binding. 231void virtualViaPointer( const Shape *baseClassPtr ) 232{ 233 234 235 236 237} 238 239// Make virtual function calls off a base-class reference 240// using dynamic binding. 241void virtualViaReference( const Shape &baseClassRef ) 242{ 243 244 245 246 247} baseClassRef.printShapeName(); baseClassRef.print(); cout << "\nArea = " << baseClassRef.area() << "\nVolume = " << baseClassRef.volume() << "\n\n"; baseClassPtr->printShapeName(); baseClassPtr->print(); cout << "\nArea = " << baseClassPtr->area() << "\nVolume = " << baseClassPtr->volume() << "\n\n";

© DHBK 2007

51/Chapter

2.3 UML 2.0
2.3.1 Gi i thi u UML 2.3.2 Bi u c u trúc 2.3.3 Bi u ch c n ng 2.3.4 Các c ch m r ng 2.3.5 Tóm t t

© DHBK 2007

52/Chapter

2.3.1 Gi i thi u v UML
"The Unified Modeling Language (UML) is a graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system.´
Grady Booch, Ivar Jacobsen, Jim Rumbaugh Rational Software

‡ UML ch n thu n là ngôn ng ho hoá ch không ph i là ph ng pháp th ng

mô hình phát tri n h

© DHBK 2007

53/Chapter

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 Bi u mô hình c u trúc mô hình ch c n ng

© DHBK 2007

54/Chapter

2.3.2 Bi u
‡ 6 lo i bi u c u trúc:

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)

© DHBK 2007

55/Chapter

2.3.2 Bi u
‡ Bi u l p (class diagram)
Bi u di n m i quan h gi a các l p

c u trúc

© DHBK 2007

56/Chapter

2.3.2 Bi u
‡ Bi u it ng (object diagram)
it Bi u di n m i quan h gi a các

c u trúc
ng

© DHBK 2007

57/Chapter

2.3.2 Bi u
‡ Bi u gói (package diagram)

c u trúc

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

© DHBK 2007

58/Chapter

2.3.2 Bi u
‡ Bi u

c u trúc

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

© DHBK 2007

59/Chapter

2.3.2 Bi u
‡ Bi u

c u trúc

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

© DHBK 2007

60/Chapter

2.3.2 Bi u
‡ Bi u

c u trúc

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

© DHBK 2007

61/Chapter

2.3.3 Bi u
‡ 8 lo i bi u
Bi u Bi u
Bi Bi Bi Bi u u u u

ch c n ng

ch c n ng

ho t ng (activity diagram) t ng tác (interaction diagrams)
chu i tu n t (sequence diagram) c ng tác (communication/collaboration diagram) khát quát t ng tác (interaction overview diagram) 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)

© DHBK 2007

62/Chapter

2.3.3 Bi u
‡ Bi u ho t diagram) ng (activity

ch c n ng

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)

© DHBK 2007

63/Chapter

2.3.3 Bi u
‡ Bi u chu i tu n t

ch c n ng
d ng d a

(sequence diagram)

Mô t các ho t ng c a các i t ng trong m t ca s vào th t xu t hi n theo th i gian

© DHBK 2007

64/Chapter

2.3.3 Bi u
‡ Bi u

ch c n ng

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

© DHBK 2007

65/Chapter

2.3.3 Bi u
‡ Bi u khát quát t
c dùng mô t t d ng ph c t p Ít c s d ng

ch c n ng
it ng trong các ca s

ng tác (interaction overview diagram)
ng tác gi a các

‡ 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

© DHBK 2007

66/Chapter

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 c a m t l p có th có trong th i gian t n t i c a chúng. ng

© DHBK 2007

67/Chapter

2.3.3 Bi u
‡ Bi u ‡ Bi u

ch c n ng

máy tr ng thái giao th c (protocol state machines) ca s d ng (use case diagram)

c dùng mô t giao th c gi a các l p Ví d : open database -> Query or update 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

© DHBK 2007

68/Chapter

2.3.3 Bi u

ch c n ng

© DHBK 2007

69/Chapter

2.3.3 Bi u

ch c n ng

© DHBK 2007

70/Chapter

2.3.3 Bi u

ch c n ng

© DHBK 2007

71/Chapter

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

© DHBK 2007

72/Chapter

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) b sung thông tin cho m t ph n t nào ó (l p, i t «) Nhãn và giá tr c t trong ngo c { } c dùng ng, quan h

© DHBK 2007

73/Chapter

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

© DHBK 2007

74/Chapter

2.3.5 Tóm t t

© DHBK 2007

2.4 Phân tích và thi t k h ng t ng v i UML 2.0

75/Chapter

i

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

© DHBK 2007

76/Chapter

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

© DHBK 2007

77/Chapter

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

© DHBK 2007

78/Chapter

2.4.2

u i m c a OOAD

© DHBK 2007

79/Chapter

2.4.3 The Unified process
‡ Unified process là m t ph ng pháp phát tri n h th ng trong ó quy nh khi nào thì s d ng các k thu t UML và s d ng chúng nh th nào trong quá trình phân tích và thi t k h th ng.
Tác gi : Booch, Jacobsen, Rumbaugh Là ph ng pháp h ng i t ng Không ph i là m t quy trình phát tri n ph n m m hoàn thi n
Không xét n các v n v phân b nhân l c, ngân qu , qu n lý h p ng Không quy nh v các ho t ng b o trì hay h tr khách hàng Không xét n các v n t ng tác gi a các d án

© DHBK 2007

80/Chapter

2.4.3 The Unified process

© DHBK 2007

81/Chapter

2.4.3 The Unified process
‡ Pha kh i t o (Inception): gi ng nh pha l p k ho ch
Các b c liên quan:
Mô hình hoá giá tr kinh doanh c a h th ng (business modeling) * Xác nh yêu c u (requirements)* Phân tích (analysis)* Thi t k (design) Th c hi n (implementation) Ki m tra (test) Môi tr ng phát tri n (environment)*

K t qu :
Ph m vi c a d án Các yêu c u và ràng bu K ho ch d án b c Miêu t tính kh thi và r L a ch n môi tr ng c c quan tr ng u i ro c a d án n thi t phát tri n h th ng

© DHBK 2007

82/Chapter

2.4.3 The Unified process
‡ Pha phát tri n (elaboration): hoàn thi n mô hình kinh doanh, ánh giá l i r i ro và hoàn thi n k ho ch d án
Các b c liên quan:
Thu th p yêu c u (requirements) Phân tích (analysis)* Thi t k (design)* Th c hi n (implementation) Ki m tra (test) Tri n khai (deployment) Qu n lý c u hình và thay i (configuration and change management)

K t qu :
Bi u

c u trúc và ch c n ng UML Phiên b n ho t ng u tiên c a h th ng

© DHBK 2007

83/Chapter

2.4.3 The Unified process
‡ Pha xây d ng (construction): t p trung ch y u vào l p trình
Các b c liên quan:
Thu th p yêu c u (requirements) Phân tích (analysis) Thi t k (design) Th c hi n (implementation)* Ki m tra (test) Tri n khai (deployment) Qu n lý c u hình và thay i (configuration and change management)*

K t qu :
Phiên b n beta c a h th ng

© DHBK 2007

84/Chapter

2.4.3 The Unified process
‡ Pha chuy n ti p (transition): t p trung ch y u vào ki m tra và tri n khai
Các b c liên quan:
Thu th p yêu c u (requirements) Phân tích (analysis) Thi t k (design) Th c hi n (implementation) Ki m tra (test)* Tri n khai (deployment)* Qu n lý c u hình và thay i (configuration and change management)*

K t qu :
Phiên b n cu i cùng (release) c a h th ng H ng d n s d ng K ho ch h tr khách hàng, k ho ch nâng c p h th ng

© DHBK 2007

85/Chapter

2.4.3 The Unified process
‡ Các b c k thu t (Engineering workflows)
1. Mô hình hoá giá tr kinh doanh (business modeling)
Di n ra ch y u trong pha kh i t o Phát hi n v n và xác nh các d án ti m n ng Xác nh giá tr kinh doanh mà d án em l i Thu th p d li u và mô hình hoá ca s d ng có th d ng

cs

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

© DHBK 2007

86/Chapter

2.4.3 The Unified process
‡ Các b
4. Thi t k
Chuy n t mô hình phân tích sang mô hình thi t k Thi t k giao di n, c s d li u, c u trúc v t lý c a h th ng, thi t k chi ti t các l p

c k thu t (Engineering workflows)

5. Th c hi n (implementation)
L p trình: vi t các l p, ch vi n Tích h p các module ng trình và s d ng các l p trong th

6. Ki m tra (Test)
Ki m tra tích h p h th ng, ch c n ng, ki m tra kh n ng ch p nh n c a ng i s d ng « Vi c ki m tra u c ti n hành trong su t quá trình phát tri n c a h th ng

7. Tri n khai (deployment)
óng gói ph n m m, phân ph i, cài t và beta testing

© DHBK 2007

87/Chapter

2.4.3 The Unified process
‡ Các b c h tr (Supporting workflows)
1. Qu n lý d án (project management)
Di n ra trong su t quá trình phát tri n h th ng Xác nh và qu n lý r i ro Qu n lý ph m vi d án Qu n lý v th i gian, chi phí«

2. Qu n lý c u hình và thay change management )

i (configuration and

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)
ng phát tri n c n thi t cho d

Qu n lý các công c và môi tr

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

© DHBK 2007

88/Chapter

2.4.4 MOOSAD

© DHBK 2007

89/Chapter

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)

© DHBK 2007

90/Chapter

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

© DHBK 2007

91/Chapter

3.1.1 Gi i thi u

Nhu c u kinh doanh

Tài li u yêu c u h th ng Project sponsor

H i

ng duy t d án

Yes

No

Phân tích tính kh thi Project sponsor + analyst Yêu c u h th ng ã ch nh s a

H i

ng duy t d án

© DHBK 2007

92/Chapter

3.1.1 Gi i thi u
‡ H i ng duy t d án (approval committee)
H i ng chuyên trách h p th ng k (vd. 3 tháng 1 l n) 1 n v ch c n ng ho c cá nhân có th m quy n (vd. phòng qu n lý d án, giám c)

© DHBK 2007

93/Chapter

3.1.2 Yêu c u h th ng (system request)
‡ Tài li u yêu c u h th ng g m 5 thành ph n:
Ch nhi m d án (project sponsor) Nhu c u kinh doanh (business need) Yêu c u kinh doanh (business requirements) Các giá tr kinh doanh ( business values) Các v n c bi t (special issues)

© DHBK 2007

94/Chapter

3.1.2 Yêu c u h th ng (system request)
‡ Ch nhi m d án (project sponsor)
Ng i thu c phòng kinh doanh Ng i thu c phòng IT có th là ch nhi m ho c d án CIO, CEO ng ch nhi m

‡ Nhu c u kinh doanh (business need): why?
Xu t phát t :
Phòng kinh doanh Phòng IT Chuyên gia t v n bên ngoài

Phát sinh khi:
1 chi n d ch kinh doanh m i c n c h tr c n tìm ki m thêm khách hàng c n c i thi n vi c trao i v i nhà phân ph i vi c kinh doanh c a công ty có v n : c phi u gi m, h tr khách hàng kém, b c nh tranh công ngh m i nhi u ti m n ng xu t hi n

© DHBK 2007

95/Chapter

3.1.2 Yêu c u h th ng (system request)
‡ Yêu c u kinh doanh (business requirement)
H th ng s làm gì Các ch c n ng c a h th ng

‡ Giá tr kinh doanh (business values)
Giá tr h u hình: ví d : 20 % gi m v chi phí Giá tr vô hình: ví d : c i thi n ch t l ng d ch v khách hàng, c i thi n v trí c nh tranh

‡ Các v n

c bi t

ví d : th i h n hoàn thành

© DHBK 2007

96/Chapter

Case study: CD selections
‡ Gi i thi u chung v công ty CD selections:
50 c a hàng b ng a ca nh c California Doanh s bán hàng: 50 tri u USD T ng tr ng 3-5 % / n m Có website cung c p các thông tin c b n v công ty nh ch d n ng i n, gi m c a, a ch liên h

‡ Margaret Mooney, phó ch t ch ph trách th tr ng có ý t ng bán CD trên m ng Internet

© DHBK 2007

97/Chapter

Case study: CD selections

© DHBK 2007

98/Chapter

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)

© DHBK 2007

99/Chapter

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

ng thích c a h th ng m i v i h th ng ang t n

quy t nh d a trên vi c so sánh v i các d án tr tham kh o ý ki n c a chuyên gia công ngh

c ó ho c

© DHBK 2007

100/Chapter

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

© DHBK 2007

101/Chapter

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

© DHBK 2007

102/Chapter

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
nh l ng các giá tr vô hình C g ng

© DHBK 2007

103/Chapter

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

© DHBK 2007

104/Chapter

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

© DHBK 2007

105/Chapter

3.1.3 Phân tích tính kh thi
‡ Kh thi v kinh t (economic feasibility) (should we build it ?)
Xác Xác Xác V nh giá tr hi n t i Net present Value (NPV) nh t l h i v n (Return on Investment) nh i m hoà v n (break even point) th i m hoà v n

© DHBK 2007

106/Chapter

3.1.3 Phân tích tính kh thi
‡ Kh thi v kinh t (economic feasibility) (should we build it ?)

© DHBK 2007

107/Chapter

3.1.3 Phân tích tính kh thi
‡ Kh thi v kinh t (economic feasibility) (should we build it ?)

© DHBK 2007

108/Chapter

3.1.3 Phân tích tính kh thi
‡ Kh thi v kinh t (economic feasibility) (should we build it ?)

© DHBK 2007

109/Chapter

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

© DHBK 2007

110/Chapter

3.1.4 L a ch n d án
‡ 3 ph ng án:
Thông qua Lo i b Xem xét l i

‡ Ph thu c vào:
ROI, giá tr NPV c a l i nhu n, th i gian hoà v n S l ng và ch t l ng các d án khác

© DHBK 2007

111/Chapter

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

© DHBK 2007

112/Chapter

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.

© DHBK 2007

113/Chapter

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

ng pháp

cl

ng kích th

c d án

ng pháp n gi n d a trên chu n công nghi p ng pháp i m ch c n ng (function point approach)

© DHBK 2007

114/Chapter

3.2.2 Xác
‡ Ph ng pháp nghi p
Planning Industry Standard For Web Applications

nh kích th

c d án

n gi n d a trên chu n công

Analysis

Design

Implementation

15%

20%

35%

30%

Time Required in Person Months

4

5.33

9.33

8

© DHBK 2007

115/Chapter

3.2.2 Xác
‡ Ph

nh kích th

c d án

ng pháp i m ch c n ng

© DHBK 2007

116/Chapter

3.2.2 Xác
‡ Ph
Xác nh kích th s dòng l nh

nh kích th

c d án

ng pháp i m ch c n ng
c h th ng theo i m ch c n ng và
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)

© DHBK 2007

117/Chapter

3.2.2 Xác
Tính toán s

nh kích th
c 1:

c d án

i m ch c n ng-B
Complexity

Description Inputs Outputs Queries Files Program Interfaces

Low __x 3 __x 4 __x 3 __x 7 __x 5

Medium __x 4 __x 5 __x 4 __x 10 __x 7

High __x 6 __x 7 __x 6 __x 15 __x 10

Total ____ ____ ____ ____ ____

TOTAL UNADJUSTED FUNCTION POINTS

____

© DHBK 2007

118/Chapter

3.2.2 Xác
Tính toán s

nh kích th

c d án

i m ch c n ng-Ví d :

© DHBK 2007

119/Chapter

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

© DHBK 2007

120/Chapter

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

© DHBK 2007

121/Chapter

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)

© DHBK 2007

122/Chapter

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
C COBOL JAVA C++ Turbo Pascal Visual Basic PowerBuilder HTML Packages (e.g., Access, Excel)

LOC/Function Code Point
130 110 55 50 50 30 15 15 10-40

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

© DHBK 2007

123/Chapter

3.2.2 Xác
‡ Ph

nh kích th

c d án

ng pháp i m ch c n ng

Xác nh kích th c h th ng theo i m ch c n ng và s dòng l nh c l ng nhân l c (person-months)
Mô hình: COSOMO

Effort (in PersonMonths)
Example:

=

1.4 * thousands-oflines-of-code

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

=

28 Person Months

© DHBK 2007

124/Chapter

3.2.2 Xác
‡ Ph

nh kích th

c d án

ng pháp i m ch c n ng

Xác nh kích th c h th ng theo i m ch c n ng và s dòng l nh c l ng nhân l c (person-months) c l ng th i gian th c hi n d án (months)

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

Ví d : d án 28 person months c n 9 tháng

hoàn thành

© DHBK 2007

3.2.3 Xây d ng và qu n lý k ho ch công vi c

125/Chapter

‡ ‡ ‡ ‡ ‡

Xác nh các công vi c c a d án c l ng th i gian th c hi n m i công vi c Xác nh s ph thu c gi a các công vi c Xác nh ai s làm công vi c gì Li t kê các k t qu t c c a m i công vi c ( deliverables): ví d : báo cáo, b n thi t k , ph ng án th c hi n ...

© DHBK 2007

3.2.3 Xây d ng và qu n lý k ho ch công vi c
Example

126/Chapter

‡

Ví d v m t b n k ho ch công vi c:
Work Plan Information Name of task Start date Completion date Person assigned Deliverable(s) Completion status Priority Resources needed Estimated time Actual time

`

Perform economic feasibility Jan 05, 2001 Jan 19, 2001 Mary Smith, sponsor Cost-benefit analysis Open High Spreadsheet 16 hours 14.5 hours

© DHBK 2007

3.2.3 Xây d ng và qu n lý k ho ch công vi c
ng
ng pháp Top-down

127/Chapter

‡

Xác nh các công vi c c a d án: 2 ph pháp
Ph

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
ng t ã làm

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

© DHBK 2007

3.2.3 Xây d ng và qu n lý k ho ch công vi c

128/Chapter

‡

Xác nh các công vi c c a d án dùng ph pháp Top-down
Phases with high level steps

ng

Phases

Work Plan

Deliverables

Estimated duration

Assigned To

* * * *

© DHBK 2007

3.2.3 Xây d ng và qu n lý k ho ch công vi c

129/Chapter

‡

Xác nh các công vi c c a d án dùng ph ng pháp Top-down: c u trúc chia nh công vi c WBS (Work Breakdown Structure)
Xác nh các công vi c chính Chia m i công vi c chính thành các công vi c nh h n ánh s công vi c và x p x p chúng theo c u trúc phân t ng Có th th c hi n WBS theo 2 cách:
Theo các b c c a SDLC Theo s n ph m

© DHBK 2007

3.2.3 Xây d ng và qu n lý k ho ch công vi c

130/Chapter

© DHBK 2007

3.2.3 Xây d ng và qu n lý k ho ch công vi c

131/Chapter

‡ Bi u Gantt (Gantt Chart): là 1 cách bi u di n k ho ch công vi c d a trên WBS

© DHBK 2007

3.2.3 Xây d ng và qu n lý k ho ch công vi c

132/Chapter

‡ 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

cl

ng = (O + 4 * M + P)/6

© DHBK 2007

3.2.3 Xây d ng và qu n lý k ho ch công vi c
PERT

133/Chapter

‡ Bi u

X: Hoàn thành \: ang th c hi n

© DHBK 2007

134/Chapter

3.2.4 S p x p nhân l c cho d

án

‡ Xác nh s ng i cho d án ‡ Xây d ng k ho ch nhân s (staffing plan) li t kê các v trí c n thi t cho d án ‡ Xác nh c c u t ch c c a d án ‡ Ch n ng i thích h p vào các v trí ‡ Khích l , ng viên và nh h ng cho c nhóm i t i m c tiêu c a d án ‡ Gi i quy t các xung t có th x y ra gi a các thành viên

© DHBK 2007

135/Chapter

3.2.4 S p x p nhân l c cho d
Ví d v c c u t ch c c a d án

án

© DHBK 2007

136/Chapter

3.2.4 S p x p nhân l c cho d
‡ Ch n ng
2 tiêu chí:
K n ng k thu t (technical skills) K n ng giao ti p, ng x (interpersonal skills)

án

i thích h p cho t ng v trí:

N u không có s n ng

i phù h p?

© DHBK 2007

137/Chapter

3.2.4 S p x p nhân l c cho d
‡ Khích l

án

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

© DHBK 2007

138/Chapter

3.2.4 S p x p nhân l c cho d
‡ Chi n l c gi i quy t xung t:

án

Xác nh rõ ràng công vi c c a t ng thành viên trong nhóm L p b ng quy nh, n i quy c a nhóm D oán các u tiên khác và kh n ng nh h ng c a chúng t i d án

© DHBK 2007

139/Chapter

3.2.5 i u ph i ho t

ng d án

‡ K ho ch d án và qu n lý d án ph i luôn c c p nh t trong su t th i gian d án vì r t ít khi d án ti n tri n theo úng nh k ho ch d ki n ban u: Tinh ch nh các giá tr c l ng: c p nh t c l ng v th i gian và chi phí và i u ch nh d án cho phù h p v i các k t qu c l ng m i Qu n lý ph m vi d án: qu n lý h u qu gây ra do vi c thay i yêu c u h th ng i u ph i d án: s d ng công c CASE (computeraided software engineering), chu n, tài li u c i thi n vi c trao i thông tin và hi u qu c a d án Qu n lý r i ro: ánh giá r i ro và t ó có bi n pháp t i thi u hoá r i ro

© DHBK 2007

140/Chapter

3.2.5 i u ph i ho t ‡ Tinh ch nh các giá tr
cl ng

ng d án

Phase Planning

Deliverable System Request Project Plan

Typical margins of Error for Well-done Estimates Cost (%) time (%) 400 100 60 25

Analysis Design

System Proposal System Specification

50 25

15 10

© DHBK 2007

141/Chapter

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)

© DHBK 2007

142/Chapter

3.2.5 i u ph i ho t ‡ Timeboxing Steps

ng d án

1. Set the date for system delivery. 2. Prioritize the functionality that needs to be included in the system. 3. Build the core of the system (the functionality ranked as most important). 4. Postpone functionality that cannot be provided within the time frame. 5. Deliver the system with core functionality. 6. Repeat steps 3 through 5, to add refinements and enhancements.

© DHBK 2007

143/Chapter

3.2.5 i u ph i ho t
‡ i u ph i ho t ng c a d án:

ng d án

CASE (computer-aided software engineering) tool ± (computerSoftware that automates all of part of the development process
Initiation Analysis Design Implementation

Upper CASE

Lower CASE

Integrated CASE (I-CASE)

© DHBK 2007

144/Chapter

3.2.5 i u ph i ho t
‡ i u ph i ho t ng c a d án:

ng d án

‡ Standardisation: Examples Formal rules for naming files Forms indicating goals reached Programming guidelines and Coding standard ‡ Documentation Project binder: all deliverables and all the internal communications within a project Table of contents Continual updating

© DHBK 2007

145/Chapter

3.2.5 i u ph i ho t
‡ Qu n lý r i ro:

ng d án

Risk assessment: a document assesses a potential risk including:
Risk No and its brief description Likelihood of risk Potential impact on the project Ways to address the risk

Actions to reduce risk Revised assessment

© DHBK 2007

146/Chapter

3.2.5 i u ph i ho t
‡ Qu n lý r i ro:
Avoiding Classic Planning Mistakes
Overly optimistic schedule Failing to monitor schedule Failing to update schedule Adding people to a late project

ng d án

© DHBK 2007

147/Chapter

3.2.6 CD selections

© DHBK 2007

148/Chapter

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

© DHBK 2007

149/Chapter

Ch

ng 4. Phân tích h th ng

nh ngh a yêu c u c a h th ng

Yêu c u h th ng (system request)

Mô hình ch c n ng

H i

ng duy t d án Yes

Mô hình c u trúc

Thi t k h th ng Mô hình ho t Phân tích kh thi K ho ch công vi c ng

+
system proposal

© DHBK 2007

150/Chapter

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

© DHBK 2007

151/Chapter

4.1.1 Xác
‡ Yêu c u là gì?

nh yêu c u

1 yêu c u (requirement) di n t ch c n ng h th ng ph i làm ho c c i m h th ng ph i có Yêu c u ch c n ng (functional requirement): là yêu c u có liên quan tr c ti p n ho t ng mà h th ng ph i làm ho c thông tin mà h th ng l u tr Yêu c u không ch c n ng (nonfunctional requirement): là các yêu c u v tính ch t ho c thu c tính mà h th ng ph i có nh kh n ng ho t ng, kh n ng s d ng ...
Ch c n ng Kh n ng ho t ng An ninh yêu c u v v n hoá, chính tr
Yêu c u không ch c n ng c dùng ch y u t i b c thi t k h th ng

© DHBK 2007

152/Chapter

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

© DHBK 2007

153/Chapter

4.1.1 Xác
‡ Xây d ng tài li u

nh yêu c u

nh ngh a yêu c u

Xác nh các lo i yêu c u ch c n ng và không ch c n ng S d ng các k thu t thu th p yêu c u thu th p thông tin S d ng các k thu t phân tích yêu c u ki m tra, thay i và hoàn thi n các yêu c u thu th p c và xác nh m c quan tr ng c a các yêu c u

© DHBK 2007

154/Chapter

4.1.1 Xác

nh yêu c u

© DHBK 2007

155/Chapter

4.1.1 Xác

nh yêu c u

© DHBK 2007

156/Chapter

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)

‡

3b

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

© DHBK 2007

157/Chapter

4.1.2 Các k thu t phân tích yêu c u
‡ Business process automation (BPA): t hoá quá trình kinh doanh ng

Không làm thay i ho t ng hi n t i T ng hoá m t s công vi c dùng công ngh máy tính 2 k thu t BPA
Phân tích v n (problem analysis): xác nh các v n trong h th ng hi n t i và tìm cách gi i quy t chúng trong h th ng m i Phân tích nguyên nhân g c (root cause analysis): phân tích nguyên nhân gôc c a v n

© DHBK 2007

158/Chapter

4.1.2 Các k thu t phân tích yêu c u
‡ Business process improvement (BPI): c i ti n quá trình kinh doanh
Làm thay i ho t ng hi n t i C n thi n c hi u su t và hi u qu c a h th ng T p trung vào h th ng m i c i ti n 3 ho t ng phân tích:
Phân tích kho ng th i gian (duration analysis): phân tích chi ti t th i gian th c hi n m t khâu nào ó trong h th ng hi n t i và xác nh khâu có th c c i ti n Xác nh chi phí các ho t ng (activity based costing): xác nh chi phí c a t ng khâu trong h th ng hi n t i và xác nh các khâu có chi phí cao nh t và t ó c i ti n gi m chi phí Nghiên c u kinh nghi m bên ngoài (informal benchmarking): nghiên c u cách t ch c kinh doanh c a các t ch c khác có th rút ra c bài h c c i ti n

© DHBK 2007

159/Chapter

4.1.2 Các k thu t phân tích yêu c u
‡ Business process reengineering (BPR): thay quá trình kinh doanh
Làm thay i c b n ho t 3 ho t ng phân tích: ng hi n t i

i

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 ó

© DHBK 2007

160/Chapter

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

© DHBK 2007

161/Chapter

4.1.2 Các k thu t phân tích yêu c u
‡ L a ch n k thu t thích h p

© DHBK 2007

162/Chapter

4.1.3 Các k thu t thu th p yêu c u
‡ ‡ ‡ ‡ ‡ Ph ng v n (Interviews) K t h p phát tri n ng d ng (Joint Application Development (JAD)) i u tra (Questionnaires) Phân tích tài li u (Document analysis) Quan sát (Observation)

© DHBK 2007

163/Chapter

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

© DHBK 2007

164/Chapter

4.1.3 Các k thu t thu th p yêu c u
‡ Ph ng v n (Interviews): B c ph ng v n c 1 Ch n ng i

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 m i (stakeholder)

ng ho c b

nh h

ng b i h th ng

© DHBK 2007

165/Chapter

4.1.3 Các k thu t thu th p yêu c u
‡ Ph ng v n (Interviews): B 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)

c 2 : thi t k câu h i

© DHBK 2007

166/Chapter

4.1.3 Các k thu t thu th p yêu c u
‡ Ph ng v n (Interviews): B ph ng v n, 3 lo i:
Types of Questions Closed-Ended Questions
*

c 2 : thi t k câu h i
Examples

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

Open-Ended Questions

What do you think about the current system? What are some of the problems you face on a daily basis? How do you decide what types of marketing campaign to run? Why? Can you give me an example? Can you explain that in a bit more detail?

Probing Questions

* *

© DHBK 2007

167/Chapter

4.1.3 Các k thu t thu th p yêu c u
‡ Ph ng v n (Interviews): B c 2 : thi t k câu h i ph ng v n, 2 lo i ph ng v n
Ph ng v n không c u trúc (Unstructured interview)
Các thông tin chung, khái quát Th c hi n t i các b c u tiên c a d án

Ph ng v n có c u trúc (Structured interview)
Các thông tin c th h n Th c hi n t i các b c sau c a d án

© DHBK 2007

168/Chapter

4.1.3 Các k thu t thu th p yêu c u
‡ Ph ng v n (Interviews): B c 2 : thi t k câu h i ph ng v n, 2 chi n l c: top-down, bottom up

© DHBK 2007

169/Chapter

4.1.3 Các k thu t thu th p yêu c u
‡ Ph ng v n (Interviews): B cu c ph ng v n c 3: chu n b cho

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

ng

© DHBK 2007

170/Chapter

4.1.3 Các k thu t thu th p yêu c u
‡ Ph ng v n (Interviews): B ph ng v n c 4: th c hi n cu c

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

© DHBK 2007

171/Chapter

4.1.3 Các k thu t thu th p yêu c u
‡ Ph ng v n (Interviews): B ph ng v n, practical tips
Don¶t worry, be happy Pay attention Summarize key points Be succinct Be honest Watch body language

c 4: th c hi n cu c

© DHBK 2007

172/Chapter

4.1.3 Các k thu t thu th p yêu c u
‡ Ph ng v n (Interviews): B ph ng v n c 5: Công vi c sau

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

© DHBK 2007

173/Chapter

4.1.3 Các k thu t thu th p yêu c u
‡ Ph ng v n (Interviews): B ph ng v n
INTERVIEW REPORT

c 5: Công vi c sau

Interview notes approved by: ____________ Person interviewed Interviewer Date Primary Purpose: Summary of Interview: Open Items: Detailed Notes: ______________ _______________ _______________

© DHBK 2007

174/Chapter

4.1.3 Các k thu t thu th p yêu c u
‡ JAD:
Allows project managers, users, and developers to work together to identify requirements May reduce scope creep by 50% Avoids requirements being too specific or too vague

© DHBK 2007

175/Chapter

4.1.3 Các k thu t thu th p yêu c u
‡ JAD: L a ch n ng ng i
Facilitator
sets the meeting agenda and guides the discussion

i tham d và vai trò t ng

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

Project team, users, and management

© DHBK 2007

176/Chapter

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

© DHBK 2007

177/Chapter

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

© DHBK 2007

178/Chapter

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

© DHBK 2007

179/Chapter

4.1.3 Các k thu t thu th p yêu c u
‡ JAD: Phòng h p

© DHBK 2007

180/Chapter

4.1.3 Các k thu t thu th p yêu c u
‡ i u tra (Questionnaire), các b
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

c:

© DHBK 2007

181/Chapter

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.

© DHBK 2007

182/Chapter

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

© DHBK 2007

183/Chapter

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

© DHBK 2007

184/Chapter

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:

© DHBK 2007

185/Chapter

4.1.4 CD selections
Requirement Determination ‡ Requirement Analysis Techniques
Select BPI techniques to identify how to improve the current order process using a new web-based system Using several JAD session including store managers, marketing analysts and Wed developers (the working group) to work through BPI techniques and brainstorm Further apply informal benchmarking with Web-sites of several leading retailers and discuss with the working group The output is a list of suggested business requirements for the project team

© DHBK 2007

186/Chapter

4.1.4 CD selections
Requirement Determination ‡ Requirement-gathering Techniques
The project team applies document analysis, interview and observation techniques Firstly apply document analysis to understand the current order processes (i.e., the as-is system). If anything is not clear, use interview to clarify Secondly interview senior analysts to get better ideas about as-is and to-be systems and IT contractor to understand the existing IT system Thirdly observe in stores to see the real working process of as-is system

‡ The above activities at the end produces the requirement definition (report) ‡ Further JAD sessions are used to finalise and prioritise the requirement definition (report)

© DHBK 2007

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

187/Chapter

4.2.1 Gi i thi u 4.2.2 Mô hình quá trình kinh doanh b ng bi u ho t ng (activity diagrams) 4.2.3 Mô t ca s d ng (use case descriptor) 4.2.4 Bi u ca s d ng 4.2.5 Xây d ng mô t ca s d ng và bi u ca s d ng 4.2.6 Hi u ch nh c l ng kích th c d án và nhân l c s d ng i m ca s d ng 4.2.7 CD Selections

© DHBK 2007

188/Chapter

4.2.1 Gi i thi u
‡ B c chu n b : Thu th p các yêu c u t ng i s d ng (ph n 4.1). ‡ B c 1: S d ng các yêu c u thu th p c, mô hình quá trình kinh doanh s d ng bi u ho t ng (activity diagrams) ‡ B c 2: S d ng các ho t ng ã xác nh xác nh các ca s d ng. ‡ B c 3: Xây d ng b n mô t ca s d ng cho m i ca s d ng ‡ B c 4: Chuy n t b n mô t ca s d ng sang bi u ca s d ng bi u di n ch c n ng và ho t ng bên ngoài c a quá trình kinh doanh ‡ -> chuy n sang mô hình hoá c u trúc (ph n 4.3)

© DHBK 2007

4.2.2 Mô hình quá trình kinh doanh b ng bi u ho t ng (activity diagrams) ho t ng ng

189/Chapter

‡ Các ph n t c a bi u ‡ Xây d ng bi u ho t

© DHBK 2007

4.2.2 Mô hình quá trình kinh doanh b ng bi u ho t ng (activity diagrams)

190/Chapter

‡ 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)
bi u di n t p h p các hành ng Make appointment

Dùng

N t

it

ng (object node)
it ng Class name

Bi u di n m t i t ng c k t n i v i các lu 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

© DHBK 2007

4.2.2 Mô hình quá trình kinh doanh b ng bi u ho t ng (activity diagrams) c a bi u
it

191/Chapter

‡ Các ph n t
Lu ng it

ho t

ng (ti p theo)
ng này sang ho t

ng (object flow)
ng t ho t

Bi u di n lu ng c a 1 ng khác

N t kh i

u (initial node)
u c a t p h p các ho t ng it ng ng

Bi u di n i m b t

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

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 it

© DHBK 2007

4.2.2 Mô hình quá trình kinh doanh b ng bi u ho t ng (activity diagrams) c a bi u ho t ng (ti p theo)
m b o lu ng i u khi n ng

192/Chapter

‡ Các ph n t

N t l a ch n (decision node)
Bi u di n vi c ki m tra i u ki n ho c lu ng i t ng ch i theo 1

[ i u ki n]

[ i u ki n]

N t g p (merge node)
Dùng g p các nhánh c t o ra b i n t l a ch n

© DHBK 2007

4.2.2 Mô hình quá trình kinh doanh b ng bi u ho t ng (activity diagrams) c a bi u ho t ng (ti p theo)
ng song song

193/Chapter

‡ Các ph n t
Chia ho t

N t chia (fork node)
ng thành các lu ng ho t

N t k t h p (join node)
Dùng k t h p các lu ng ho t ng song song

© DHBK 2007

4.2.2 Mô hình quá trình kinh doanh b ng bi u ho t ng (activity diagrams)

194/Chapter

© DHBK 2007

4.2.2 Mô hình quá trình kinh doanh b ng bi u ho t ng (activity diagrams)
ho t ng:

195/Chapter

‡

Xây d ng bi u

1. Xác nh ph m vi và ng c nh c a quá trình kinh doanh r i t cho bi u ho t ng 1 tiêu phù h p 2. Xác nh các ho t ng, lu ng i u khi n, lu ng i t ng di n ra gi a các ho t ng. 3. Xác nh các quy t nh l a ch n trong quá trình kinh doanh 4. Xác nh kh n ng th c hi n song song c a các ho t ng (n u có). 5. V bi u ho t ng

© DHBK 2007

‡

4.2.2 Mô hình quá trình kinh doanh b ng bi u ho t ng (activity diagrams) VD: CD selections
1.1«« 1.2«.. 1.3«..

196/Chapter

Internet Order System ± Functional requirements: 1. Maintain CD Information 2. Maintain CD marketing information
2.1«. 2.2«. 2.3«.

3. Place CD Orders
3.1 Search CDs from ³CD Selection´ web site; 3.2 Place orders; 3.3««

4. Maintain Orders
4.1«.. 4.2« 4.3 Place Instore Hold: If ordered CDs are available in a near store, the CDs are on hold and to be picked up in the store 4.4. Place Special Order: If ordered CDs is not available in a near store, the ordered CDs will be sent to a near store and email to the customer when it is available in the near store

© DHBK 2007

4.2.2 Mô hình quá trình kinh doanh b ng bi u ho t ng (activity diagrams)

197/Chapter

‡

VD: CD selections
Exercise: Create the activity diagram for Internet Order System Analysis: Main activities: Maintain CD Information, Maintain CD marketing information, Place CD Orders, Maintain ordered CDs Control flows: Three main parallel processes:
Maintain CD Information Maintain CD marketing information Place CD Orders -> Maintain ordered CDs in which a decision needs to be made related to placing instore hold or placing special order

© DHBK 2007

4.2.2 Mô hình quá trình kinh doanh b ng bi u ho t ng (activity diagrams)

198/Chapter

‡

VD: CD selections

Place CD Order [If available in near store] Place instore hold [If not]

Maintain CD marketing information

Maintain CD Information

Place special order

© DHBK 2007

199/Chapter

4.2.3 Mô t ca s

d ng

‡ M t ca s d ng miêu t các ho t ng do ng i s d ng ho c các h th ng khác tác ng lên h th ng. ‡ Ca s d ng là mô hình logic vì chúng miêu t các ho t ng c a h th ng mà không miêu t các ho t ng ó c th c hi n th nào. ‡ Ca s d ng miêu t ch c n ng c a h th ng:
Ng i s d ng có th làm gì H th ng áp ng nh th nào Ca s d ng miêu t t ng tác gi a ng i s d ng và h th ng

‡ Ca s d ng có th c dùng mô t h th ng hi n t i và h th ng c n xây d ng

© DHBK 2007

200/Chapter

4.2.3 Mô t ca s
‡ 2b c xây d ng bi u

d ng

ca s d ng
ca s

Vi t b n mô t ca s d ng Chuy n t b n mô t ca s d ng sang bi u 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

© DHBK 2007

201/Chapter

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: Primary Actor: ID: Use Case Type: Importance Level:

Stakeholders and Interests: Brief Description: Trigger: Relationships: (Association, Include, Extend, Generalization) Normal Flow of Events: Subflows: Alternate/Exceptional Flows:

© DHBK 2007

202/Chapter

4.2.3 Mô t ca s
‡ Ví d :

d ng

© DHBK 2007

203/Chapter

4.2.3 Mô t ca s
‡ Ví d :

d ng

© DHBK 2007

204/Chapter

4.2.3 Mô t ca s
‡ Ví d :

d ng

© DHBK 2007

205/Chapter

4.2.3 Mô t ca s
‡

d ng

Guidelines for Creating Use-Case Descriptions
1. Write each step in ³SVDPI (subject-verb-direct object and optionally preposition-indirect object)´ form Example. ³The patient (subject) contacts (verb) the office (direct object) regarding (preposition) an appointment (indirect object). 2. Clarify initiator and receivers of action 3. Write from independent observer perspective 4. Write at same level of abstraction 5. Ensure a sensible set of steps 6. Apply KISS (keep it simple, stupid) principle liberally 7. Write repeating instructions after the set of steps to be repeated.

© DHBK 2007

206/Chapter

4.2.4 Bi u

ca s

d ng
A Subject Boundary

An Actor An associate relationship

A use case

© DHBK 2007

207/Chapter

4.2.4 Bi u

ca s

d ng

© DHBK 2007

208/Chapter

4.2.4 Bi u

ca s

d ng

© DHBK 2007

209/Chapter

4.2.4 Bi u

ca s

d ng

© DHBK 2007

210/Chapter

4.2.4 Bi u

ca s

d ng

© DHBK 2007

4.2.5 Xây d ng mô t ca s d ng và Bi u ca s d ng
c chính:
c I. Xác nh các ca s d ng chính c II. M r ng ca s d ng chính c III. Kh ng nh l i các ca s d ng chính c IV. V bi u ca s d ng

211/Chapter

‡ 4b
B B B B

© DHBK 2007

4.2.5 Xây d ng mô t ca s d ng và Bi u ca s d ng
c nh ): Xác nh các ca s d ng

212/Chapter

‡

B c I (5 b chính

1. Xem l i bi u ho t ng 2. Xác nh ph m vi c a h th ng 3. Li t kê các tác nhân chính (primary actors) và m c ích c a các tác nhân ó 4. Xác nh và vi t các ca s d ng chính 5. Xem xét l i c n th n các ca s d ng và s a in u c n

© DHBK 2007

4.2.5 Xây d ng mô t ca s d ng và Bi u ca s d ng
c I: Ví d

213/Chapter

‡

B

Review activity diagram of Internet order System:

Place CD Order

Maintain CD marketing information

Maintain CD Information

Maintain CD Order

© DHBK 2007

4.2.5 Xây d ng mô t ca s d ng và Bi u ca s d ng
c I: Ví d
Primary actor Vendor Distribution system Customer Customer Relationship Association Vendor Distribution system Customer Maintain order Include Exclude

214/Chapter

‡

B

Identify and write the major (overview) use-cases
Use case name Maintain marketing information Maintain CD information Place order Maintain order

© DHBK 2007

4.2.5 Xây d ng mô t ca s d ng và Bi u ca s d ng
c II (5 b
m r ng ki n bình th

215/Chapter

‡

B
7. 8.

c nh ): M r ng ca s d ng chính

6. Ch n 1 ca s d ng chính
i n các chi ti t vào form i n các b c c a lu ng s

ng (normal

flow of events) 9. Chu n hoá kích th

c c a m i b c (n u b c nào quá ph c t p ho c quá dài, chia nh thành các subflows ho c a thêm ca s d ng)

10. Miêu t các b

c thay th ho c ngo i l (alternate/exceptional) 11. V i m i b c thay th ho c ngo i l , miêu t cách th c mà tác nhân (actor) và h th ng áp ng

© DHBK 2007

4.2.5 Xây d ng mô t ca s d ng và Bi u ca s d ng
c II: Ví d : k t qu sau b c7

216/Chapter

‡

B

© DHBK 2007

4.2.5 Xây d ng mô t ca s d ng và Bi u ca s d ng
c II: Ví d : k t qu sau b
c8

217/Chapter

‡

B

© DHBK 2007

4.2.5 Xây d ng mô t ca s d ng và Bi u ca s d ng
c II: Ví d : k t qu sau b
c 11

218/Chapter

‡

B

© DHBK 2007

4.2.5 Xây d ng mô t ca s d ng và Bi u ca s d ng
c II: Ví d : k t qu sau b
c 11

219/Chapter

‡

B

© DHBK 2007

4.2.5 Xây d ng mô t ca s d ng và Bi u ca s d ng
c nh ): Kh ng nh l i các ca s

220/Chapter

‡

B c III (2 b d ng chính

12. Xem xét l i các ca s

d ng, s a l i n u c n

Xem xét l i cú pháp và ng ngh a Làm vi c cùng v i ng i s d ng

13. L p l i 12 b c cho c xác nh

n khi t t c các ca s d ng

© DHBK 2007

4.2.5 Xây d ng mô t ca s d ng và Bi u ca s d ng
c IV (4 b c nh ): V bi u ca s d ng
d nhìn) gianh gi i c a h th ng các ca s d ng (v theo th t các tác nhân các quan h

221/Chapter

‡

B
1. 2. 3. 4. V V V V

© DHBK 2007

Exercise: Draw use-case diagram Question. Suppose that 7 major use cases have been identified as below, draw the corresponding use-case diagram
Primary actor Relationship Association Include Extend

222/Chapter

Use case name

Maintain marketing information Maintain CD information Place order

Vendor

Vendor

Distribution system Customer

Distribution system Customer Check out Maintain order Maintain order Place Instore hold Place special order Store
Store

Check out Maintain order Place Instore hold
Place special order

Customer Customer Customer
Customer

Customer, Credit Centre

© DHBK 2007

223/Chapter

Maintain CD marketing information
<<actor>>

<<include>> Check out <<include>> Maintain CD order

Credit Card Centre

Place CD order

Place instore hold << extend >> Place special order
<<actor>>

Store

<<actor>>

Distribution System

Maintain CD information

© DHBK 2007

224/Chapter

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

© DHBK 2007

225/Chapter

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.

© DHBK 2007

226/Chapter

4.3.2 Các ph n t
‡ L p (Classes)

c a mô hình c u trúc
ng (Templates for

Ki u d li u nh ngh a it 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

© DHBK 2007

227/Chapter

4.3.2 Các ph n t
‡ Ho t ng (Operations)

c a mô hình c u trúc

Hành ng mà i t ng có th th c hi n T i b c phân tích này, ch t p trung vào các ho t ng liên quan tr c ti p n v n c n mô hình hoá Sau này, ho t ng s c chuy n i sang ph ng th c (methods)

‡ Quan h (Relationships)
T ng quát hóa (Generalization)
Cho phép k th a thu c tính và ho t ng a-kind-of (e.g. secretary is a kind of employee)

T ng th (Aggregation)
K t n i gi a b ph n v i t ng th a-part-of ( e.g. a door is a part of a car) ho c has part

K t h p (Association)
Các quan h khác gi a các l p

© DHBK 2007

4.3.3 Th CRC (Class-Responsibility(Class-ResponsibilityCollaboration)

228/Chapter

‡ Trách nhi m (responsibility) và h p tác (collaboration)
Trách nhi m
it 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 Mô hình Client-server-contract th c hi n m t công vi c

‡ Th CRC

c dùng b nc am tl p

miêu t các ph n t

c

© DHBK 2007

4.3.3 Th CRC (Class-Responsibility(Class-ResponsibilityCollaboration)

229/Chapter

© DHBK 2007

4.3.3 Th CRC (Class-Responsibility(Class-ResponsibilityCollaboration)

230/Chapter

© DHBK 2007

231/Chapter

4.3.4 Bi u

l p

© DHBK 2007

232/Chapter

4.3.4 Bi u
‡ Cú pháp:
A CLASS Class 1 -attribute +operation () AN ATTRIBUTE

l p

Attribute name/ derived attribute name

AN OPERATION

operation name ()

AN ASSOCIATION

1..* 0..1 ______verb phrase____

© DHBK 2007

233/Chapter

4.3.4 Bi u
‡ Thu c tính:
Derived attributes

l p

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

Visibility
Public: Protected: Private: + # -

© DHBK 2007

234/Chapter

4.3.4 Bi u
‡ Ho t ng (operations):
Creates object

l p

Constructor Query
Makes information about state available

Update
Changes values of some or all attributes

© DHBK 2007

235/Chapter

4.3.4 Bi u
‡ Quan h :
Multiplicity of relationship
exactly one: zero or more: one or more: zero or one: specified range: multiple disjoint ranges:

l p

1 0..* 1..* 0..1 2..4 1..5,7

© DHBK 2007

236/Chapter

4.3.4 Bi u
‡ Bi u it ng: c th hóa bi u

l p
l p

© DHBK 2007

237/Chapter

4.3.5 Xây d ng th CRC và bi u

l p

Three common approaches 1. 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

© DHBK 2007

238/Chapter

4.3.5 Xây d ng th CRC và bi u
‡ ‡

l p

‡ ‡ ‡

‡ ‡

1.Create CRC cards by performing textual analysis on the use-cases. 2. Brainstorm additional candidate classes, attributes, operations, and relationships by using the common object list approach. 3. Role-play each use-case using the CRC cards. 4. Create the class diagram based on the CRC cards. 5. Review the class diagrams and structural model for missing and/or unnecessary classes, attributes, operations, and relationships. 6. Incorporate useful patterns. 7. Review the structural model.

© DHBK 2007

239/Chapter

4.3.5 Xây d ng th CRC và bi u

l p

CD Selections

© DHBK 2007

240/Chapter

Step 1. Create CRC cards by performing textual analysis on the use-cases useTextual Analysis: Nouns suggest classes

© DHBK 2007

241/Chapter

Step 1. Create CRC cards by performing textual analysis on the use-cases useTextual Analysis: Nouns suggest classes ‡ Textual Analysis Results: Identified potential classes 
Customer  Search Request  CD  CD List  Review (i.e., CD review information) If further analyse the Maintain Order and Checkout use cases, further potential classes will be identified such as  Order  Order Item  Credit card centre  etc

© DHBK 2007

242/Chapter

Step 1. Create CRC cards by performing textual analysis on the use-cases useTextual Analysis: Verbs suggest operations:
‡ For each identified class, check the related verbs to identify the operations as well as the relationships with other classes

© DHBK 2007

243/Chapter

Step 1. Create CRC cards by performing textual analysis on the use-cases useTextual Analysis: Verbs suggest operations:
‡ Textual Analysis Result: For Customer Class, the identified operations (i.e., Responsibilities) and the relationship with other classes (i.e., Collaborators) are

Make Search request Place Order Get Credit Card Info Exit Select CD for Info

Search request Order Credit Card Centre CD List Not include as it can be included in Search request

This forms the front of Customer class CRC Card

© DHBK 2007

244/Chapter

Step 1. Create CRC cards by performing textual analysis on the use-cases use‡ Textual Analysis Result: Combine ³nouns and verbs´ analysis, the back of ³Customer class´ CRC Card can be

Order; Search request; Credit Card Centre

© DHBK 2007

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

245/Chapter

2. Brainstorm additional candidate classes, attributes, operations, and relationships by using the common object list approach. 3. Role-play each use-case using the CRC cards. Possible outcomes: Search request class need having 3 sub-classes: Title Search, Artist Search and Category Search

© DHBK 2007

Step 4. Create the Class Diagram based on the CRC Cards Exercise. Suppose the CRC card of Customer class is given as before, create the class diagram based on it. For customer class, assume that all attributes are private type whereas all operations are public type For other associate classes, only the class names and the relationships with the customer class need to be given

246/Chapter

© DHBK 2007

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

247/Chapter

Solution:
Credit Card Centre Order Customer 0..* Check -> 0..* 1 0..* place ->

-First name -Middle initial -Last name -«« +Make search req() +Place order() +Get credit info() +Exit()
0..*

Search Reg 0..*

Make ->

© DHBK 2007

248/Chapter

Step 5, 6 and 7: Review Classes Diagrams, Incorporate Patterns, and Review the Model 5. Review the class diagrams and structural model for any missing and/or redundancy 6. Incorporate useful patterns. One possible pattern

7. Review the structural model.

© DHBK 2007

249/Chapter

4.4 Mô hình hoá ho t
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

ng

© DHBK 2007

250/Chapter

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

ng:

t

ng tác (Interaction Diagrams)
tu n t (sequence diagram) giao ti p (c ng tác) (communication diagram)

Bi u máy tr ng thái (Behavioral state machine diagram)

© DHBK 2007

251/Chapter

4.4.2 Bi u
‡ Các ph n t
it

t

ng tác

c b n:
it ng

ng (Objects)

1 b n sao c a l p Có các thu c tính miêu t

Ho t

ng (Operations)

Truy n ho c nh n thông i p

Thông i p (Messages)
Ch th cho it ng th c hi n m t ho t ng

© DHBK 2007

252/Chapter

4.4.2 Bi u
‡ Bi u

t

ng tác

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

© DHBK 2007

253/Chapter

4.4.2 Bi u
‡ Bi u tu n t

t

ng tác

(sequence diagram): ví d

© DHBK 2007

254/Chapter

4.4.2 Bi u
‡ Bi u tu n t

t

ng tác

(sequence diagram): Các ph n t

© DHBK 2007

255/Chapter

4.4.2 Bi u
‡ Bi u tu n t

t

ng tác

(sequence diagram): Các ph n t

© DHBK 2007

256/Chapter

4.4.2 Bi u
‡ 6b
1. 2. 3. 4. 5.

t

ng tác

c xây d ng bi u

tu n t

Xác nh ng c nh c a bi u tu n t Xác nh các i t ng tham gia Xác nh ng s ng (lifeline) cho m i i t ng Bi u di n các thông i p Bi u di n các i m xu t hi n ho t ng (execution occurrence) trên m i ng s ng c a i t ng 6. Ki m tra l i bi u

© DHBK 2007

Application Example:

257/Chapter

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

© DHBK 2007

Application Example:

258/Chapter

© DHBK 2007

259/Chapter

4.4.2 Bi u
‡ Bi u

t

ng tác

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

© DHBK 2007

260/Chapter

4.4.2 Bi u
‡ Bi u giao ti p : Ví d

t

ng tác

© DHBK 2007

261/Chapter

4.4.2 Bi u
‡ Bi u Actor Object Association Message giao ti p : Các ph n t

t

ng tác

© DHBK 2007

262/Chapter

4.4.2 Bi u
‡ 5b
1. 2. 3. 4. 5.

t

ng tác

c xây d ng bi u

giao ti p
it ng 2

Xác nh ng c nh Xác nh các i t ng và các liên k t gi a các V các i t ng và liên k t Thêm các thông i p Ki m tra l i bi u giao ti p

© DHBK 2007

Technique to Identify Collaborations between Objects - ³CRUD´ Analysis

263/Chapter

‡ 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

© DHBK 2007

264/Chapter

³CRUD´ Analysis Example

C C

© DHBK 2007

Application Example:

265/Chapter

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

© DHBK 2007

Application Example:

266/Chapter

© DHBK 2007

267/Chapter

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.

© DHBK 2007

268/Chapter

4.4.3 Bi u
Ví d :

máy tr ng thái

© DHBK 2007

269/Chapter

4.4.3 Bi u
Các ph n t c a bi u

máy tr ng thái

máy tr ng thái:

© DHBK 2007

270/Chapter

4.4.3 Bi u
Các ph n t
‡

máy tr ng thái

c a bi u

máy tr ng thái:

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

Event [guard]/activity state transition

© DHBK 2007

271/Chapter

4.4.3 Bi u
‡ 5b c xây d ng bi u

máy tr ng thái
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

© DHBK 2007

Application Example:

272/Chapter

The Life of an Order Object:

© DHBK 2007

Application Example:

273/Chapter

© DHBK 2007

274/Chapter

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ý

© DHBK 2007

275/Chapter

5.1 Chuy n sang thi t k
5.1.1 Chuy n t mô hình phân tích sang mô hình thi t k 5.1.2 Gói và Bi u gói 5.1.3 Các chi n l c thi t k 5.1.4 Xây d ng thi t k th c t

© DHBK 2007

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

276/Chapter

‡ Factoring:
Creating modules* that reflect similarities and differences between units of interest Here, module = new class | new method New classes can be represented by:Generalization Aggregation New classes identified by: Abstraction e.g. classes for nurse, admin and doctor share attributes and methods, so ³factor our´ common attributes and methods, create new class ³employee´, relate employee to nurse, admin and doctor classes as generalisation (a-kind-of) relationship ± a form of abstraction Refinement Identifying additional subclasses (of a higher level class) is a form of refinement

© DHBK 2007

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

277/Chapter

‡ Partitions and Collaborations
Creating subsystems*, i.e. collections (usually sets) of related components In object-oriented designs/implementations the ³pattern of activity´, i.e. messages sent between objects, provides one basis for partitioning system into (smaller-scale) subsystems (where subsystem = partition) Grouping units that collaborate e.g. as modelled in UML communications diagram (for each use-case), CRUD analysis, clients(i.e. objects that are message senders)-servers(i.e. objects that receivemessages) & contracts (i.e. specifications of interactions between objects) May have collaboration among units (e.g. a class) or partitions (i.e. collections/sets of classes whose objects send/receive messages) The more messages or contracts between objects, the more likely they are in the same partition

© DHBK 2007

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

278/Chapter

‡ Layers
A system¶s environment includes software architecture, user interface and stored data Layer enables useful separation of (related) concerns, e.g. application logic from user-interface considerations Model-view-controller (MVC) architecture
‡ ‡ ‡ ‡ ‡ ‡ Models implement application logic Views and controllers manage interfaces Views = output logic Controllers = input logic Models = application logic Suggested layers now include foundation, physical, HCI, data access and management, problem domain. n.b. layer constrains kind(s) of classes that exist ³on that layer´ Foundation = programming language and IDE constructs Physical architecture = classes used for communication HCI = classes enabling user interaction Data access and management = classes for persistence Problem domain = classes to be refined into implementable (effective and efficient)

‡ ‡ ‡ ‡ ‡

© DHBK 2007

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

279/Chapter

‡ Layers

© DHBK 2007

280/Chapter

5.1.2 Gói và bi u
Package = UML representation (or abstraction over) collaboration OR partition OR layer
‡Logical grouping of any UML elements

gói

Simplifies (large numbers of) UML diagrams Groups related elements into a single higher-level element Packages involving different kinds of construct (e.g. at particular layers) use different kinds of relationship between those constructs, i.e. in a class diagram, package = group (or set) of classes by aggregation or association relationship

© DHBK 2007

281/Chapter

5.1.2 Gói và bi u

gói

‡ Also need ³dependency´ relationships between packages ‡ A UML package diagram can be a class diagram that contains only package symbols and dependency relationships (dotted arrows) ‡ Package symbol is similar to tabbed folder symbol ‡ Dependency relationship implies change in one package may require change in dependent package e.g. change in (the signature) of one method will cause interface for all objects of this class to change, therefore, all classes that have objects that send messages to instances of modified class may need to be modified.

© DHBK 2007

282/Chapter

5.1.2 Gói và bi u

gói

A PACKAGE

Package

A DEPENDENCY RELATIONSHIP

© DHBK 2007

5.1.2 Gói và bi u Ví d

gói

283/Chapter

© DHBK 2007

284/Chapter

5.1.2 Gói và bi u
Collaborations, partitions and layers
Collaborations usually are modelled as packages in UML

gói

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

© DHBK 2007

285/Chapter

Package Diagram of Appointment System
Patient UI dependent on Patient class DM-Patient class dependent on Patient class Patient table dependent on Patient class

Problem domain Classes: Patient, Appt. by intermediate Data Access and Manipulation (DM) Classes: DM-Patient, DM-Appt Separated from object persistence Classes: Patient table, Appt. table

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

© DHBK 2007

286/Chapter

5.1.2 Gói và bi u

gói

Steps for Identifying Packages and Building Package Diagrams

‡

Set the context

‡

Cluster classes together based on shared relationships

‡

Model clustered classes as a package

‡

Identify dependency relationships among packages

‡

Place dependency relationships between packages

© DHBK 2007

287/Chapter

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

© DHBK 2007

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

Examine analysis models
Class Diagram Sequence Diagram(s)

Communication Diagram(s) Classes in a generalisation hierarchy put in a single partition

© DHBK 2007

289/Chapter

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

© DHBK 2007

290/Chapter

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

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

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

© DHBK 2007

291/Chapter

Step 5: Place dependency relationships between packages, i.e. between Person Package and Appt. Package, Person Package and Treatment Package Show dependency relations as ³pure´ package diagram showing ONLY dependency relations that CAN be created between packages

PD Layer Person Package Patient Package

Appt. Package

Treatment Package

© DHBK 2007

Worked Example: Applying Concepts at CD Selections: First, previous lectures...

292/Chapter

‡ ‡

Chapter 5: Functional and Non-functional Requirements Chapter 6: Functional Model = activity diagram + use-case descriptions & diagrams Chapter 7: Structural Model = CRC cards + class diagram Chapter 8: Behavioural Models for ³Places Order´ use-case + ³Order´ class (sequence diagram, communication diagram, behavioural state machine) Next: Create package diagram for CD Selections

‡ ‡

‡

© DHBK 2007

Example: Applying Concepts at CD Selections
Set the context = Problem Domain Layer Cluster classes, i.e. review relationships amongst classes

293/Chapter

‡ ‡

Sequence Diagram (Places Order Use Case)

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

© DHBK 2007

‡

Keep classes in a generalisation hierarchy together = cluster Customer, Individual and Organisation(al) classes into partition

294/Chapter

‡

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

© DHBK 2007

‡

Association relationship (between CD class and Mkt Info class) and message sending pattern of activity = place in same partition
‡

295/Chapter

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

‡

‡

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

© DHBK 2007

‡

Model each partition as a package n.b. Credit Card Centre not yet contained in a package

296/Chapter

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

© DHBK 2007

297/Chapter

Place the dependency relations on the package diagram (and increase clarity by dependency relationships between packages = pure package diagram of PD layer of CD Selections containing highest level packages only (+ Credit Card Centre class) and their dependency relationships

© DHBK 2007

298/Chapter

5.1.3 Các chi n l
‡ Custom Development

c thi t k

‡ Has potential for meeting highly specialized requirements e.g. for CD selections, order taking process could be web-based, linking tightly with the existing distribution system, or, the technical environment may enforce constraint that all information systems are built using standard technology and interface designs (for consistency, ease of reuse) ‡ Has potential for greater flexibility and creativity in solving problems e.g. for CD selections, can use ordering ³web interface´ as strategic enabler to better understand customer¶s who order online, using technology to mine data obtained via custom applications ‡ Has potential to change components e.g. for CD selections all components in custom application are available and can be reused in whole or part ‡ Usually increases personnel skills e.g. for CD selections, developers build technical skills and business knowledge as they further evolve the system ‡ Potentially requires significant resources ‡ Potentially adds significant risk

© DHBK 2007

299/Chapter

5.1.3 Các chi n l
‡ Packaged Software

c thi t k

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

© DHBK 2007

300/Chapter

5.1.3 Các chi n l
‡ Packaged Software (cont.)

c thi t k

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´

© DHBK 2007

301/Chapter

5.1.3 Các chi n l

c thi t k

‡ Outsourcing ± (now increasingly popular) = pay external vendor, developer, service provider to create system For CD selections, use a Web Service Provider who provides commercial order taking system Potentially external suppliers have higher level of skill Their services MUST work to generate income, so web services are built by ³experts´ with significant experience Is not ³cost free´ ± lose absolute control over software and data, inhouse expertise is not increased Only outsource what is properly understood in advance Needs rigorous planning and analysis of needs in advance of contract negotiations, must identify vendor, developer or service provider with proven track record of success in system and supporting technology for system¶s needs Vendor choice and contract & payment method by strictly controlled criteria Time and arrangement deal Fixed price Value added contract

© DHBK 2007

302/Chapter

5.1.3 Các chi n l
‡ Outsourcing Guidelines

c thi t k

Keep lines of communication open with outsourcer Define and stabilize requirements before signing a contract View outsourcing relationship as partnership Select outsource vender carefully Assign person to manage relationship Don¶t outsource what you don¶t understand Emphasize flexible requirements, long-term relationships, and short-term contracts

© DHBK 2007

303/Chapter

5.1.3 Các chi n l
‡ Select a strategy (1):

c thi t k

Business need Common business needs best served by packaged systems, i.e. when custom built alternative does not require any special business needs, when system is not critical to company In-house experience Custom application only feasible if sufficient in-house skills for all functional and technical challenges, otherwise packaged system (possibly with in-house integration software added) Project skills Technical, e.g. Java programming and IDE skills, data design and SQL programming skills Functional, e.g. in electronic commerce If electronic commerce is to become basis for company¶s future development, in-house skills in EC and technical skills in its exploitation must be further developed Some skills, e.g. network security, might be operational issue which can be outsourced

© DHBK 2007

304/Chapter

5.1.3 Các chi n l
‡ Select a strategy (2):

c thi t k

Project management Custom applications require significant project management via application of a proven system development methodology (or collection of integrated methods) Packaged and outsourced systems require different kinds of management, e.g. of contract and delivery Time frame If time to meet business requirement(s) is limited (or short), requirements are ³standard´ and well-defined, then packaged or outsourced most likely strategies, outsourced for standard, packaged for well-defined

© DHBK 2007

305/Chapter

5.1.4 Phát tri n thi t k th c t
‡ Alternative Matrix
Combines several feasibility analyses into one grid Revisits technical, economic, and organizational feasibility Created using same steps as feasibility analysis (chapter 3), but combines several analyses into a single matrix for comparison Matrix is represented by a grid Contains technical, budget, organisational feasibilities for each candidate, pro¶s and cons, other useful information, e.g. criticality, future-proofing Sometimes ³weights´ are provided n.b. in AHP weights are derived (mathematically) from judgements over criteria

‡

Request For Proposal
Aids development of alternative matrix Description of the system you propose to be built Vendors, developers, service providers respond with proposals including how they will address needs as well as stating cost and time requirements. Similar (less effort-intensive) Request For Information (RFI)

© DHBK 2007

306/Chapter

5.1.4 Phát tri n thi t k th c t

© DHBK 2007

307/Chapter

5.2 Thi t k l p và ph
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 5.2.4 Ràng bu c và giao kèo 5.2.5 Xác nh ph ng th c

ng th c

it

ng

© DHBK 2007

308/Chapter

5.2.1 Gi i thi u
‡ Các m c tr u t ng c a h th ng h ng it ng

© DHBK 2007

309/Chapter

5.2.2 Các tiêu chí thi t k
‡ Coupling ‡ Cohesion ‡ Connascence

© DHBK 2007

310/Chapter

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

© DHBK 2007

311/Chapter

5.2.2 Các tiêu chí thi t k
Types of interaction coupling

© DHBK 2007

312/Chapter

5.2.2 Các tiêu chí thi t k
‡ Interaction coupling:
Law of Demeter = minimise number of objects that can receive messages from a given object Objects only send message to: A) Itself B) An object an object ³contained´ in an attribute of itself (or an object of one of its superclasses) C) An object passed as a parameter to the mehod D) An object created by the method E) An object stored in a variable whose declaration scope is the entire program (a ³global´ variable) Coupling increase if:  calling method passes attributes to called method  Calling method depends on value returned by called method

© DHBK 2007

313/Chapter

5.2.2 Các tiêu chí thi t k
‡ Cohesion:
Refers to how single-minded a module is within a system 3 types of cohesion:
Method Class Generalization/specialization

© DHBK 2007

314/Chapter

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

© DHBK 2007

315/Chapter

5.2.2 Các tiêu chí thi t k
‡ Cohesion:
Class cohesion:
Is the level of cohesion among the attributes and methods of a class A class should only represent one thing A cohesive class should:  Contain multiple methods that are visible outside the class  Have methods that refer to attributes or other methods defined with the class or its superclass  Not have any control-flow coupling between its methods

© DHBK 2007

316/Chapter

5.2.2 Các tiêu chí thi t k
‡ Cohesion:
Class cohesion:

© DHBK 2007

317/Chapter

5.2.2 Các tiêu chí thi t k
‡ Cohesion:
Generalization/specialization cohesion:
Addresses the sensibility of the inheritance hierarchy

© DHBK 2007

318/Chapter

5.2.2 Các tiêu chí thi t k
‡ Connascence: Two modules (classes or methods) are so intertwined, that if you make a change in one, it is likely that a change in the other will be required Connascence and encapsulation
Minimize overall connascence by eliminating any unnecessary connascence throughout the system, Minimize connascence across any encapsulation boundaries, such as method boundaries and class boundaries, Maximize connascence within any encapsulation boundary.

© DHBK 2007

319/Chapter

5.2.2 Các tiêu chí thi t k
‡ Connascence:

© DHBK 2007

5.2.3 Các ho t

ng thi t k

it

320/Chapter

ng

‡ ‡ ‡ ‡ ‡

Additional specification Identifying opportunities for reuse Restructuring the design Optimizing the design Map Problem Domain Classes to Implementation Languages

© DHBK 2007

5.2.3 Các ho t

ng thi t k

it

321/Chapter

ng

‡ Additional specification:
Ensure the classes are both necessary and sufficient for the problem Finalize the visibility of the attributes and methods of each class Determine the signature of every method of each class Define constraints to be preserved by objects

© DHBK 2007

5.2.3 Các ho t

ng thi t k

it

322/Chapter

ng

‡ Identifying opportunities for reuse:
Analysis patterns
Representations of the problem-domain

Design patterns
Useful grouping of collaborating classes that provide a solution to a commonly occurring problem Many design patterns are available in C++ or Java source code

Frameworks
A set of implemented classes that can be used as a basis for implementing an application Most frameworks allow us to create subclasses to inherit from classes in the framework

Libraries components

© DHBK 2007

5.2.3 Các ho t

ng thi t k

it

323/Chapter

ng

‡ Identifying opportunities for reuse:
Libraries
Class library similar to framework, i.e. has classes designed for reuse More domain specific, i.e. can be used to realise some layer, e.g. HIC layer Can be used to: Create instances of classes in library  Create subclasses by inheritance, and then objects of subtype(s)  Using inheritance again increases inheritance coupling and Connascence  Directly instantiating class in library, object dependency created between created object and library object due to signatures of methods in library object, i.e. increases interaction coupling between class library object and created object

© DHBK 2007

5.2.3 Các ho t

ng thi t k

it

324/Chapter

ng

‡ Identifying opportunities for reuse:
Components:
Self-contained & encapsulated software that can be plugged into a system Provides specific funtionality Typically components implemented using ActiveX or JavaBean Component has well-defined Application Program Interface (API) API = set of method interfaces to objects contained in component Internal operation of component hidden by API Components can be implemented using class libraries and frameworks Unless API changes between between version of component, only need to relink component to application (no recompilation required)

© DHBK 2007

5.2.3 Các ho t

ng thi t k

it

325/Chapter

ng

‡ Identifying opportunities for reuse:

© DHBK 2007

5.2.3 Các ho t

ng thi t k

it

326/Chapter

ng

‡ Restructuring the design:
Factoring Separate out shared aspects of a method or class into a new method or class New class related to existing classes via inheritance, aggregation or association Normalization Identifies classes missing from the design All association and aggregation relationships converted to attributes of the class Challenge inheritance relationships to ensure they only support a generalization/specialization semantics

© DHBK 2007

5.2.3 Các ho t

ng thi t k

it

327/Chapter

ng

‡ Optimizing the design
Simple optimisations make an existing design more efficient, but must not make optimised design significantly more difficult to reason about, i.e. optimsation is a ³trade-off´ between efficiency and ease of understanding the design optimisations below need to be considered. [1] access paths between objects [2] attributes of each class [3] direct and indirect ³fan-out´ of each method [4] execution order of statements [5] unnecessary recomputation

© DHBK 2007

5.2.3 Các ho t

ng thi t k

it

328/Chapter

ng

‡ Optimizing the design
[1] access paths between objects 
A message from one object to another may go though many intervening objects  If a) the path though the intervening objects is long and b) the message is sent frequently consider a ³redundant path´, i.e. an additional attribute in the calling object that stores a direct connection to object at end of path

[2] attributes of each class 
If methods that use an attribute only read and update attribute and only instances of a single class send those messages then attribute may belong to calling class.

[3] direct and indirect ³fan-out´ of each method 
Fan-out = number of messages sent by a method  Direct Fan-out = number of messages sent by given method  Indirect Fan-out includes number of messages sent by methods called by other methods in a message tree  If fan-out of a method significantly higher than other methods in a system then should be optimised, e.g. add an index to attributes used to send messages to objects in message tree

© DHBK 2007

5.2.3 Các ho t

ng thi t k

it

329/Chapter

ng

‡ Optimizing the design
[4] execution order of statements 
In frequently used methods, order of statements may be nonoptimal  Changing order should not affect result of computation  Changing order can be more efficient, e.g. when searching, if one attribute known to narrow search then search on that attribute first

[5] unnecessary recomputation 
Derived attributes (or active values) need not be recomputed until attributes that are involved in its computation change, e.g.  A) Add ³trigger´ to attributes in computation of derived attribute and when any of those attributes change recompute derived attribute  B) Mark derived attribute and recompute only when it is next accessed

© DHBK 2007

5.2.3 Các ho t

ng thi t k

it

330/Chapter

ng

‡ Map Problem Domain Classes to Implementation Languages:
OO designs assume class-based OO programming language used to implement those designs e.g. UML class diagram is-a specification of a class in a classbased OO programming language Need to resolve any conflicts between constructs assumed in the design to be available in programming language but are not present in that language e.g.
[1] design uses multiple inheritance, language has only single inheritance [2] implementation language is object-based and not class-based, i.e. implementation language supports object creation but not implementation inheritance [3] language is of another (less expressive) language paradigm, e.g. C or Pascal are of the imperative-procedural paradigm

© DHBK 2007

5.2.3 Các ho t

ng thi t k

it

331/Chapter

ng

‡ Map Problem Domain Classes to Implementation Languages:
[1] design uses multiple inheritance, language has only single inheritance 
A) Convert multiple inheritance relationships to ³superclass´subclass association relationships If additional superclasses are concrete (objects of the class can be instantiated) then multiplicity from superclass to subclass is 0..1 Otherwise multiplicity is 1..1 Add an exclusive-OR constraint between associations Add appropriate methods to ensure all information remains available to existing class  B) Copy ALL the attributes and methods of the additional superclasses to ALL the subclassess and remove additional superclass from the design

© DHBK 2007

5.2.3 Các ho t

ng thi t k

it

332/Chapter

ng

‡ Map Problem Domain Classes to Implementation Languages:
[1] design uses multiple inheritance, language has only single inheritance

concrete SuperClass1 -attribute1 -attribute2 SuperClass2 -attribute3 -attribute4
{XOR}

1..1

SuperClass3 1..1 -attribute7 -attribute8
[1]All classes preserved [2]Increases amount of message passing [3]Adds to processing requirement due to XOR

0..*

0..*

Class1 -attribute5 -attribute6

Class2 -attribute5 -attribute6

© DHBK 2007

5.2.3 Các ho t

ng thi t k

it

333/Chapter

ng

‡ Map Problem Domain Classes to Implementation Languages:
[1] design uses multiple inheritance, language has only single inheritance

abstract SuperClass1 -attribute1 -attribute2 SuperClass2 -attribute3 -attribute4 SuperClass3 -attribute7 -attribute8 Potential Inheritance Conflicts

Class1 -attribute3 -attribute4 -attribute5 -attribute6

Class2 -attribute3 -attribute4 -attribute5 -attribute6

© DHBK 2007

5.2.3 Các ho t

ng thi t k

it

334/Chapter

ng

‡ Map Problem Domain Classes to Implementation Languages:
[2] implementation language is object-based and not classbased 
Need to factor out ALL uses of inheritance from problem-domain class design All superclasses concrete SuperClass1 -attribute1 -attribute2 SuperClass2 -attribute3 -attribute4
{XOR}

1..1

SuperClass3 1..1 -attribute7 -attribute8
1..1 1..1

1..1 0..* 1..1

0..*

Class1 -attribute5 -attribute6

Class2 -attribute5 -attribute6

© DHBK 2007

5.2.3 Các ho t

ng thi t k

it

335/Chapter

ng

‡ Map Problem Domain Classes to Implementation Languages:
[2] implementation language is object-based and not classbased
SuperClass1 -attribute1 -attribute2 If all superclasses are abstract SuperClass3 SuperClass2 -attribute7 -attribute3 -attribute8 -attribute4 Class2 -attribute1 -attribute2 -attribute3 -attribute4 - attribute5 -attribute6 -attribute7 -attribute8

Class1 -attribute1 -attribute2 -attribute3 -attribute4 -attribute5 -attribute6 -attribute7 -attribute8

Potential Inheritance Conflicts

© DHBK 2007

5.2.3 Các ho t

ng thi t k

it

336/Chapter

ng

‡ Map Problem Domain Classes to Implementation Languages:
[3] language is of another (less expressive) language paradigm, e.g. C or Pascal are of the imperative-procedural paradigm 
Stay away from this!  But if necessary, factor out all uses of
Polymorphism Dynamic binding Encapsulation Information hiding

© DHBK 2007

337/Chapter

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

© DHBK 2007

338/Chapter

5.2.4 Ràng bu c và giao kèo
‡ Pre- and post-conditions model constraints on individual methods ‡ Invariants model constraints (that must always be true) for all instances of a class, e.g. Domains (in DB) or types (in design/programming language) of attributes Multiplicity of attributes Legal values of attributes including attributes that model association and aggregation and relationships e.g. if association relationship is required, invariant is created to enforce relationship to have valid value for instance to exist ‡ Invariants usually attached to the class, e.g. CRC cards or class diagrams as a set of assertions

© DHBK 2007

‡

Example:-

Attribute Constraint: Order Number IS unsigned long

339/Chapter Attribute Constraint: Customer IS INSTANCE OF Customer Class

Back: Attributes: Order Number Date (1..1) Sub Total Tax (0..1) Shipping (0..1) Total (0..1) Customer Cust ID (1..1) State (1..1) StateName

(1:1) (unsigned long) (Date) (0..1) (double) (double) {Sub Total = sum(Product Order.GetExtension())} (double) (double) (1..1) (Customer) (unsigned long) (Cust ID = Customer.GetCustID()} (State) (String) {State Name = State.GetState()}
Attribute Constraint: Cust ID IS unsigned Long AND Invariant MUST HAVE one and ONLY one value (1..1) = Customer.GetCustID()

Relationships: Generalisation(a-kind-of): Aggregation (has-parts):

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

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

© DHBK 2007

Invariants On a Class Diagram(Not recommended ± Use CRC card for Invariants)

Product Order Order Product Quantity Extension

340/Chapter

<<invariant>> {Sub Total= Sum(Product Order.GetExtension())}}

Customer -Cust ID -Last Name -First Name

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

Product -Product Number -Product Desc 0..* 1..* -Price

<<invariant>> {Tax=State.GetTaxRate() *SubTotal} State

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

0..* 1..1 -State Tax RateProduct Desc

© DHBK 2007

341/Chapter

5.2.4 Ràng bu c và giao kèo
‡ Contract: Contracts document message passing between objects, i.e. messages sent to server objects by implementor¶s client object, and values returned by server Ideally a contract for each message sent and received by each object, i.e. one contract per interaction In practice, one contract for each method that can receive messages from other objects, i.e. each visible method Contracts are declarative = documents for client object¶s implementor what the method does
Method name, class name, ID number, client objects, associated use cases, description, arguments received, type of reurn value, pre- and post-conditions

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

© DHBK 2007

342/Chapter

Unique Contract ID Specific Method OF specific Class

List of use cases containing this method where method is used to realise implementation of the use case (from server class s CRC card and associated use cases)

List of classes and methods that send a message to this method

What the method does NOT how it does it

types of parameters passed type of value returned to its clients

= method signature

© DHBK 2007

343/Chapter

5.2.5 Xác
‡ ‡ ‡ ‡ General information Events Message passing Algorithm specification
Structured English Pseudocode UML activity diagram

nh ph

ng th c

© DHBK 2007

344/Chapter General Information (for managing programming effort)

Method Name Contract ID Programming Language: Triggers/Events

Class Name Programmer: Visual Basic SmallTalk

ID: Date Due: C++ Java

e.g. user initiated event(mouse event, keystroke event), system event or event initiated by another method Notes: Message passing to and from method (c.f. sequence and collaboration diagrams) Arguments = attributes and data structures in implemented method Data Type: Notes:

Arguments Received: Data Type:

Messages Sent & Arguments Passed ClassName.MethodName:

Argument Returned: Data Type: Algorithithm Specification:

Notes:

© DHBK 2007

345/Chapter

‡

Structured English will suffice for algorithm specification«

Algorithm Specification: Action Statement IF Statement Examples: Profits = Revenues Expenses Generate Inventory-Report

Examples: IF Customer NOT in Customer Object Store THEN Add Customer record to Customer Object Store ELSE Add Current-Sale to Customer s Total Sales Update Customer record in Customer Object Store Examples: FOR all Customers in Customer Object Store DO Generate a new line in Customer-Report Add Customer s Total-Sales to Report-Total Examples: CASE IF Income < 10,000: Marginal-tax-rate IF Income < 20,000: Marginal-tax-rate IF Income < 30,000: Marginal-tax-rate IF Income < 40,000: Marginal-tax-rate ELSE Marginal-tax-rate = 38 percent ENDCASE = = = = 10 20 31 35 percent percent percent percent

FOR Statement

CASE Statement

Notes:

© DHBK 2007

346/Chapter

‡ Pseudocode = ³programming specific´ language with initialisation and linking instructions ‡ (Get_CD_Info Module) Accept(CD.Title) {Required} Accept(CD.Artist) {Required} Accept(CD.Category) {Required} Accept(CD.Length) ‡ Return