1

TRƢỜNG ĐẠI HỌC HÀNG HẢI VIỆT NAM KHOA CÔNG NGHỆ THÔNG TIN BỘ MÔN HỆ THỐNG THÔNG TIN

-----***-----

BÀI GIẢNG
PHÂN TÍCH & THIẾT KẾ HỆ THỐNG HƢỚNG ĐỐI TƢỢNG

TÊN HỌC PHẦN

: PHÂN TÍCH & THIẾT KẾ HỆ THỐNG HƢỚNG ĐỐI TƢỢNG MÃ HỌC PHẦN : 17407 TRÌNH ĐỘ ĐÀO TẠO : ĐẠI HỌC CHÍNH QUY DÙNG CHO SV NGÀNH : CÔNG NGHỆ THÔNG TIN

HẢI PHÒNG - 2011

2

MỤC LỤC
Nội dung Chƣơng 1. Mô hình đối tƣợng 1.1. Sự phát triển của mô hình đối tượng 1.2. Nền tảng của mô hình đối tượng 1.3. Phần tử cơ bản trong mô hình đối tượng Chƣơng 2. Lớp và đối tƣợng 2.1. Cơ bản về đối tượng 2.2. Mối quan hệ giữa các đối tượng 2.3. Cơ bản về lớp 2.4. Mối quan hệ giữa các lớp 2.5. Sự tương tác lẫn nhau của lớp và đối tượng Chƣơng 3. Sự phân loại (Classification). 3.1. Tầm quan trọng của sự phân loại 3.2. Xác định các lớp và đối tượng Chƣơng 4. Phân tích thiết kế hệ thống hƣớng đối tƣợng sử dụng UML (Unified Model Language) 4.1. Ngôn ngữ mô hình thống nhất (UML) 4.2. Các biểu đồ (Diagrams) Chƣơng 5. Quy trình phân tích và thiết kế 5.1. Nền tảng 5.2. Quy trình vĩ mô: Vòng đời của triển khai phần mềm 5.3. Quy trình vi mô: Quá trình phân tích và thiết kế Chƣơng 6. Một số bài toán cụ thể 6.1. Hệ thống điều khiển: Quản lý hệ thống giao thông 6.2. Ứng dụng mạng lưới: Hệ thống theo dõi kỳ nghỉ Trang 5 5 8 9 12 12 12 13 15 15 16 16 16 18 18 23 37 37 37 40 44 44 46

3

Tên học phần: Phân tích & Thiết kế hệ thống hướng đối tượng Loại học phần: 2 Bộ môn phụ trách giảng dạy: Hệ thống Thông tin Khoa phụ trách: CNTT. Mã học phần: 17407 Tổng số TC: 2 TS tiết Lý thuyết Thực hành/ Xemina Tự học Bài tập lớn Đồ án môn học 45 30 15 0 0 0 Học phần học trƣớc: Phân tích và Thiết kế hệ thống Học phần tiên quyết: Không yêu cầu. Học phần song song: Không yêu cầu. Mục tiêu của học phần: Cung cấp các kiến thức cơ bản về phân tích, thiết kế hệ thống thông tin tin học hoá theo mô hình hướng đối tượng sử dụng UML. Nội dung chủ yếu: Phương pháp luận phân tích thiết kế hệ thống hướng đối tượng; Nguyên tắc và công cụ mô hình hoá hệ thống; Thiết kế và cài đặt hệ thống hướng đối tượng; Các ví dụ minh hoạ. Nội dung chi tiết: PHÂN PHỐI SỐ TIẾT TÊN CHƢƠNG MỤC TS LT TH BT KT Chƣơng 1. Mô hình đối tƣợng 2 2 1.1. Sự phát triển của mô hình đối tượng 1.2. Nền tảng của mô hình đối tượng 1.3. Phần tử cơ bản trong mô hình đối tượng Chƣơng 2. Lớp và đối tƣợng 2 2 2.1. Cơ bản về đối tượng 2.2. Mối quan hệ giữa các đối tượng 2.3. Cơ bản về lớp 2.4. Mối quan hệ giữa các lớp 2.5. Sự tương tác lẫn nhau của lớp và đối tượng Chƣơng 3. Sự phân loại (Classification). 2 3.1. Tầm quan trọng của sự phân loại 3.2. Xác định các lớp và đối tượng Chƣơng 4. Phân tích thiết kế hệ thống hƣớng đối 18 16 2 tƣợng sử dụng UML (Unified Model Language) 4.1. Ngôn ngữ mô hình thống nhất (UML) 4.2. Các biểu đồ (Diagrams) Chƣơng 5. Quy trình phân tích và thiết kế 2 2 5.1. Nền tảng 5.2. Quy trình vĩ mô: Vòng đời của triển khai phần mềm 5.3. Quy trình vi mô: Quá trình phân tích và thiết kế Chƣơng 6. Một số bài toán cụ thể 4 3 1 6.1. Hệ thống điều khiển: Quản lý hệ thống giao thông 6.2. Ứng dụng mạng lưới: Hệ thống theo dõi kỳ nghỉ Nhiệm vụ của sinh viên: Tham dự các buổi học lý thuyết và thực hành, làm các bài tập được giao, làm các bài thi giữa học phần và bài thi kết thúc học phần theo đúng quy định. Tài liệu học tập: 1. Grady Booch, Robert A.Maksimchuk, Michael W.Engle, Bobbi J.Young, Ph.D, Jim Conallen, Kelli A.Houston, Object-Oriented Analysis And Design with Application, Third Edition. 2. Robert V. Stumpf, Lavette C. Teague, Object-Oriented Systems Analysis and Design with UML, Pearson Prentice Hall 3. Đoàn Văn Ban, Phân tích và thiết kế hệ thống hướng đối tượng, Nhà xuất bản ĐHQG Hà Nội, 2006.

4

4. Nguyễn Văn Vỵ, Phân tích và thiết kế các hệ thống thông tin hiện đại, Nhà xuất bản Thống Kê, Hà Nội, 2002. Hình thức và tiêu chuẩn đánh giá sinh viên: - Hình thức thi: thi viết. - Tiêu chuẩn đánh giá sinh viên: căn cứ vào sự tham gia học tập của sinh viên trong các buổi học lý thuyết và thực hành, kết quả làm các bài tập được giao, kết quả của các bài thi giữa học phần và bài thi kết thúc học phần. Thang điểm: Thang điểm chữ A, B, C, D, F. Điểm đánh giá học phần: Z = 0,3X + 0,7Y.

Bài giảng này là tài liệu chính thức và thống nhất của Bộ môn Hệ thống Thông tin, Khoa Công nghệ Thông tin và được dùng để giảng dạy cho sinh viên.

Ngày phê duyệt:

/

/

Trƣởng Bộ môn

5

CHƢƠNG I: MÔ HÌNH ĐỐI TƢỢNG
1.1. Sự phát triển của mô hình đối tượng
Trong mục này chúng ta khảo sát sự phát triển của các công cụ để giúp chúng ta hiểu sự thành lập và các nét nổi bật của kỹ thuật hướng đối tượng. Trong quá trình phát triển công nghệ phần mềm chúng ta có thể để ý và nghiên cứu theo 2 hướng sau: - Phát triển các chương trình nhỏ tới các chương trình lớn - Sự phát triển của các ngôn ngữ lập trình bậc cao hơn. Hầu hết tất cả các chương trình phần mềm ngày càng đòi hỏi cao vào phức tạp hơn. Chính điều này đã thúc đẩy việc nghiên cứu trong lĩnh vực công nghệ phần mềm, mà đặc biệt quan tâm tới sự phân tích, trừu tượng và tổ chức cho hệ thống. Đi đôi với điều này, việc phát triển các ngôn ngữ lập trình cũng đã đáp ứng được phần nào về giải quyết yêu cầu phức tạp của hệ thống. Wenger đã phân loại ra một số ngôn ngữ lập trình bậc cao phổ biến và sắp xếp theo thứ tự tùy thuộc và một số đặc tính của từng loại ngôn ngữ: - Thế hệ ngôn ngữ thứ nhất (1954 -195) FORTRAN I ALGOL 58 Flowmatic IPL V - Thế hệ ngôn ngữ thứ hai (1959 – 1961) FORTRAN II Các thủ tục con, tách riêng rẽ các mô hình phức tạp ALGOL 60 COBOL Lisp - Thế hệ ngôn ngữ thứ ba (1962 – 1970) PL/1 ALGOL 68 Pascal Simula FORTRAN + ALGOL + COBOL Kế thừa nghiêm ngặt từ ALGOL 60 Kế thừa đơn giản từ ALGOL 60 Lớp, trừu tượng dữ liệu Cấu trúc khối, kiểu dữ liệu Mô tả dữ liệu Con trỏ, Biểu thức toán học Biểu thức toán học Biểu thức toán học Biểu thức toán học

- Giai đoạn (1970 -1980): Trong giai đoạn này có rất nhiều ngôn ngữ khác nhau đuợc phát minh ra. Tuy nhiên có một số ngôn ngữ sau đã được sử dụng rộng rãi: C FORTRAN 77 Hiệu quả, có thể thực thi đuợc Theo chuẩn ANSI

. Do đó dẫn đến việc lập trình theo các Framework.NET Dựa trên các đối tượng Framework cơ bản của Microsoft Visual C# Visual Basic .Giai đoạn Framework (1990 – ngày nay): Nhiều ngôn ngữ mới đuợc phát triển và yêu cầu cần phải tuân theo một tiêu chuẩn nào đó. Về kiến trúc.NET Visual Basic cho Framework của Microsoft .Giai đoạn hướng đối tượng (1980 – 1990) Smalltalk C++ Ada83 Eiffel Kế thừa đơn giản từ ALGOL 60 Lớp. trừu tượng dữ liệu Ngôn ngữ hướng đối tượng Phát triển từ C và Simula Mạnh hơn Pascal Phát triển từ Ada và Simula .NET Bây giờ chúng ta xem xét cấu trúc của mỗi thế hệ ngôn ngữ lập trình. chúng ta có thể thấy kiến trúc của các ngôn ngữ lập trình ở thế hệ thứ nhất và đầu thời kì thứ 2. Trong hình này. Visual Basic Dễ dàng phát triển các giao diện đồ họa cho các ứng dụng Windows Java Python Kế thừa từ Oak Ngôn ngữ kịch bản hướng đối tượng J2EE Dựa trên các Framework cơ bản của Java . chúng ta có thể thấy rằng các khối cơ bản để xây dựng lên các ứng dụng là các chương trình con. Trong hình 1-1..6 Pascal Simula . chúng được xây dựng bởi các khối cơ bản và các phần được liên kết với nhau như thế nào.

các ngôn ngữ lập trình được hỗ trợ với nhiều các truyền tham số khác nhau. Trong suốt quá trình thiết kế dữ liệu của một chương trình con có thể tách biệt với dữ liệu của các chương trình con khác. Các mũi tên trên hình vẽ nói rằng các chương trình phụ thuộc vào các kiểu dữ liệu khác nhau. “ Chương trình đầu tiên.” các chương trình con được đề xuất trong giai đoạn 1950 nhưng nó vẫn chưa được coi như là một abstraction ở thời điểm đó. Kiến trúc của ngôn ngữ lập trình ở cuối giai đoạn 2 và đầu giai đoạn 3 Giữa năm 1960. Một lỗi trong một phần của chương trình có thể ảnh hưởng tới toàn bộ hệ thống bởi vì cấu trúc dữ liệu toàn cục được sử dụng cho tất các các chương trình con. cung cấp các định hướng để các nhà thiết kế cố gắng xây dựng một hệ thống phức tạp thông qua các chương trình nhỏ hơn được coi là các khối chương trình cơ bản. Subprograms được đánh giá như là một hướng tiếp cận để tách các chức năng của chương trình. Thứ nhất. nền tảng của lập trình cấu trúc là sắp xếp. Thứ hai. .7 Các ứng dụng được viết bởi những ngôn ngữ này thông thường được thiết kế với các chương trình con và dữ liệu toàn cục. Khi chúng ta cần chỉnh sửa một hệ thống lớn. cuối cùng thì các chương trình cũng được công nhận là trung gian giữa “vấn đề” và máy tính. giờ được gọi là thủ tục. Kiến trúc lập trình trong giai đoạn này chỉ ra một vài điều không phù hợp của các ngôn ngữ trước đó. phương pháp cấu trúc thể hiện được ưu điểm. Các subprogram có thể phục vụ như là một kĩ thuật tóm tắt có 3 hê quả quan trọng. khó có thể duy trì tính toàn vẹn của thiết kế gốc. Thứ ba. bố trí rõ ràng thông qua các chương trình con.

Do đó.8 Kiến trúc ngôn ngữ lập trình ở cuối giai đoạn 2 đầu giai đoạn 3 Kiến trúc của ngôn ngữ lập trình ở cuối giai đoạn thứ 3 Trong giai đoạn này. sử dụng lớp và đối tượng như là các khối xây dựng cơ bản. Tương tự. . việc phân tích thiết kế các chương trình mang tính quy mô lớn ngày càng nhiều và đòi hỏi nhiều đội. Nền tảng của mô hình hướng đối tượng Thiết kế hệ thống theo hướng cấu trúc giúp những nhà lập trình viên xây dựng các hệ thống phức tạp sử dụng thuật toán như là các khối cơ bản. do vậy rất cần thiết phải chia chương trình ra thành các phần khác nhau. hình thành việc chia các chương trình ra thành các module nhỏ như được hiển thị ở hình dưới đây: Kiến trúc ngôn ngữ lập trình của cuối giai đoạn 3 Kiến trúc của đối tƣợng cơ bản và ngôn ngữ lập trình hƣơng đối tƣợng Trừu tượng hóa dữ liệu là quan trọng để kiểm soát sự phức tạp của dữ liệu. nhiều nhóm phai tham gia cùng một lúc.2. thiết kế hệ thống theo hướng đối tượng giúp người lập trình viên khai thác được những điểm mạnh của đối tượng cơ bản và ngôn ngữ lập trình hướng đối tượng. 1.

Không có một kiểu lập trình nào mà tốt nhất đối với tất các các loại ứng dụng.9 Trên thực tế. Nó không phá vỡ các cấu trúc của chương trình đã được thiết kế trước đó. mô hình đối tượng đã chứng mình là một khái niệm thống nhất trong khoa học máy tính. . Phương pháp cấu trúc cho phép nhà phân tích chia nhỏ hệ thống phức tạp ra thành các hệ thống nhỏ hơn. địa điểm hay một sự vật được mô tả hay tồn tại trong hệ thống mà có 3 điều cần quan tâm: Cái gì để phân biệt. Nguyên nhân của việc được ưa chuộng phổ biến đó là hướng đối tượng giúp chúng ta đối phó với các kế thừa phức tạp trong nhiều loại hệ thống khác nhau. Một trong những phương pháp đó là hướng thủ tục.3. Các phần tử của mô hình đối tượng Hầu hết các lập trình viên làm việc trên một ngôn ngữ và sử dụng chỉ một phong cách lập trình. Họ lập trình theo mô hình mẫu của ngôn ngữ mà họ sử dụng. Tuy nhiên. nhận biết nó (Định danh của nó và toàn bộ các thuộc tính). Object-Oriented Analysis and Design. Theo thống kê thì có một số kiểu lập trình sau đây: + Hướng thủ tục + Hướng đối tượng + Hướng Logic + Hướng luật + Hướng ràng buộc Các thuật toán Các lớp và đối tượng Các mục đích Các luật If…then Các quan hệ bất biế. không chỉ là ngôn ngữ lập trình hướng đối tượng. và quản lý cũng dễ dàng hơn. rõ ràng hơn. Phương pháp OOAD chủ yếu là phân tích theo hướng đối tượng hơn là hướng thủ tục như là phương pháp SSAD. và ngay cả với kiến trúc của máy tính. hầu hết các lập trình viên không được huấn luyện khắt khe kỹ năng phân tích và thiết kế hướng đối tượng. Phân tích và thiết kế hướng đối tượng theo đó đưa ra sự phát triển tiên tiến hơn. nền tảng mô hình hướng đối tượng. Ví dụ: Lập trình theo hướng thủ tục thì tốt đối với việc thiết kế các chương trình liên quan tới việc tính toán… Từ trước tới nay đã và đang tồn tại nhiều phương pháp được áp dụng để phân tích thiết kế một hệ thống thông tin. mô hình đối tượng đã bị chi phối bổi một số tác nhân. Phương pháp SDLC được sử dụng phổ biến nhất đó là Structured System Analysis and Design. cơ sở dữ liệu. Một đối tượng là một người. như đã thảo luận ở phần trước. Phong cách lập trình được xem như là một cách tổ chức chương trình dựa trên một số các mô hình của lập trình và ngôn ngữ đã viết ra chương trình một cách rõ ràng. không đổi. được sử dụng trong việc giải quyết các vấn đề của hệ thống hiện tại hoặc cho việc xây dựng một hệ thống mới. Có nhiều phương pháp được sử dụng cho việc thiết kế và phát triển hệ thống thông tin bao gồm: Systems Development Life Cycle (SDLC). 1. không chỉ thích hợp với ngôn ngữ lập trình mà còn thích hợp với thiết kế giao diện người dùng. Thực vậy. Rapid Application Development (RAD).

Phân tích và thiết kế hệ thống theo hƣớng truyền thống System development life Cycle (SDLC) hoặc Structured Systems Analysis and Design (SSAD) là nền tảng cho mọi hoạt động và nhiệm vụ cần thiết để hoàn thành việc phát triển một hệ thống thông tin. hệ thống được coi một tổng thể ban đầu. Thiết kế hướng đối tượng là quá trình phát triển một mô hình hướng đối tượng. Nhà phân tích sẽ gặp gỡ với người dùng và giải quyết vấn để. Phương pháp OOAD có thể chia ra làm 2 lĩnh vực chính: . bỏ qua những phần nhỏ và chỉ tiết. Nó làm những cái gì (Các phương thức của nó thực hiện với CSDL). Các quy trình được xây dựng bởi các lược đồ luồng dữ liệu. Chủ yếu việc phân tích ở giai đoạn này để hiểu được những đặc tính của hệ thống. Mô hình dữ liệu được định nghĩa bằng việc quan hệ giữa các thực thể (ERD). Phân tích thiết kế hệ thống hƣớng đối tƣợng Phương pháp tiếp cận theo hướng đối tượng để phát triển một hệ thống xem hệ thống như là một tập các đối tượng tương tác với nhau. Hai vấn đề chính trong việc phát triển hệ thống thông tin đó là các quy trình và dữ liệu được xây dựng độc lập với phương pháp này. Nói tóm lại trong OOAD chúng ta đề cập tới thuật ngữ đối tượng nhiều hơn là chức năng. Phân tích hướng đối tượng là quá trình phát triển một mô hình hướng đối tượng mà trong mô hình này các đối tượng ban đầu biểu diễn các thực thể và các phương thức liên quan tới vấn đề cần giải quyết. xác nhật những vấn đề mà người dùng cần. Những phần này sẽ được phân tích sau. Nhà phân tích tập trung vào 2 mục đích chính: Hệ thống mới cần phải làm những gì và Hệ thống mới làm nó như thế nào? Phương pháp này yêu cầu người dùng theo sát từ đầu tới khi dự án hoàn thành. Phương pháp này như đã đề cập ở phần trước được gọi là mô hình thác nước. Một đối tượng là một vấn đề trong hệ thống máy tính.10 - Quan hệ với cai gì (Quan hệ của nó với các đối tượng khác). phạm vi của hệ thống được định nghĩa là nơi hệ thống được triển khai. ERD mô tả dữ liệu (thực thể) và sự phối kết hợp giữa chúng. Tiếp theo. Không có sự tách biệt giữa thực thể dữ liệu và tệp tin. Ở đây. Không có sự tách biệt giữa quy trình và chương trình. trong giai đoạn này phải xác định được các yêu cầu. lược đồ này mô phỏng luồng dữ liệu giữa quy trình và dữ liệu lưu trữ và nó được thay đổi như thế nào. Các vấn đề cơ bản trong SSAD có thể được tóm tắt như sau: Điều đầu tiên trong SSAD đó là sự phân tích theo hướng từ trên xuống dưới. làm việc cùng nhau để hoàn thành nhiệm vụ.

Bài tập 1) Trình bày sự phát triển của các mô hình lập trình? 2) Trình bày nền tảng của mô hình đối tượng? 3) Các thành phần của mô hình đối tượng? . modularity. Mô hình đối tượng dựa trên các yêu tố cơ bản bao gồm: abstraction. - Thiết kế hướng đối tượng: Điều này liên quan tới phát triển mô hình hướng đối tượng của hệ thống cần thiết để thực hiện các yêu cầu. Một hệ thống hướng đối tượng sẽ có một số đối tượng. Điều này xác định đối tượng biểu diễn các thực thể và quan hệ giữa các đối tượng và phương pháp cần thiết để giải quyết vấn đề.11 - Phân tích hướng đối tượng: Điều này liên quan tới phát triển mô hình hướng đối tượng của ứng dụng. mỗi đối tượng này sẽ kết hợp với các đối tượng khác để hoàn thành một nhiệm vụ. hierarchy…Mục tiêu tập trung ủa mô hình đối tượng là phân tích đối tượng. Các nhà phân tích và lập trình phải nghĩ thuật ngữ đối tượng nhiều hơn là chức năng. encapsulation.

Vậy ta tự hỏi. Cú pháp chuẩn là: tên đối tượng: tên lớp. Như vậy. một sinh viên trường Đại học Hàng hải. Chúng ta lấy một ví dụ về đối tượng là An. hay một quyển sách hoặc tồn tại ở dạng trìu tượng như là cảm xúc… Trong UML chúng ta xây dựng đối tượng bằng việc sử dụng một hình chữ nhật với 2 phần.kết tập (aggregation) Mối quan hệ liên kết (link) . 2. Cơ bản về đối tượng Trong khóa học này. Ví dụ. An là một trường hợp trong tất cả các sinh viên của trường Đại học Hàng hải. Các mối quan hệ cung cấp các đường dẫn để các đối tượng tương tác với nhau. tôi muốn quản lý các khóa học khác nhau tại trường Đại học Hàng hải. đối với sử dụng OOAD thì người phân tích và lập trình sử dụng thuật ngữ đối tượng rất rất nhiều.2. Phần dưới liệt kê các thuộc tính của đối tượng đó. Theo đó tôi phải tạo các đối tượng mà có thể lưu trữ thông tin về các khóa học này. một đối tượng có thể là tồn tại ở dạng vật chất. Có hai loại quan hệ giữa các đối tượng là : . Phần trên chứa tên của đối tượng và tên của lớp mà đối tượng thuộc vào lớp đó. Hoạt động của hệ thống thu được thông qua sự phối hợp của các đối tượng trong hệ thống. Mối quan hệ giữa các đối tượng Toàn bộ hệ thống được xây dựng từ rất nhiều lớp và đối tượng. nhưng chúng ta đã đề cập từ chương trước.12 CHƢƠNG II: LỚP VÀ ĐỐI TƢỢNG 2. để chúng ta có thể theo dõi hay lấy thông tin về các khóa học khác nhau. như là một sinh viên.liên kết(link) . Chúng ta cũng có thể nói đối tượng là cái gì đó mà chúng ta muốn lấy thông tin về chúng. đối tượng là gì? Đối tượng là một trường hợp của một sự việc có kiểu cụ thể.1. một khóa học.

Với mỗi liên kết. Trong cách nói khác thì đối tượng là một trường hợp cụ thể của lớp. một cần lái. Nó luôn luôn bắt nguồn từ lớp. Các thông điệp được khởi tạo ở phía client. một đối tượng có thể có một trong ba vai trò:  Actor: Một đối tượng có thể hoạt động trên các đối tượng khác chứ không bị thao tác bởi các đối tượng khác. Một đối tượng phối hợp với các đối tượng khác thông qua các liên kết của nó với các đối tượng này. một động cơ . Trong UML một lớp được biểu diễn như là một hình chữ nhật với 3 phần riêng biệt được phân tách bởi dòng kẻ ngang. sau đó được đưa tới supplier. thông điệp được truyền giữa hai đối tượng là một chiều. Các lớp có thể định nghĩa thông qua các lớp khác bằng việc sử dụng tính chất kế thừa. Mục đích của nó là định nghĩa một tập các thuộc tính và thao tác mà mô tả đầy đủ cấu trúc và hành vi của các đối tượng. phần giữa định nghĩa tất cả các thuộc tính của lớp. Ví dụ: Một chiếc xe ô tô có 4 bánh. Nói một cách khác. trong đó một đối tượng(client) sử dụng những dịch vụ của đối tượng khác (supplier).. Thông thường. Nó phục vụ như là một mẫu khi mà tạo một đối tượng mới. nó chỉ có thể bị thao tác bởi các đối tượng khác. một hộp số. Phần trên cùng thể hiên tên lớp. phần cuối cùng chứa các định nghĩa thao tác. Mối quan hệ kết tập (aggregation) Mối quan hệ kết tập chỉ là một dạng đặc biệt của mối quan hệ liên hợp trong đó một đối tượng là sự tổng hợp của các đối tượng thành phần.3. 2. một liên kết biểu diễn một liên hợp (association) xác định.. .  Agent: Là đối tượng vừa có thể hoạt động trên các đối tượng khác. Cơ bản về lớp Lớp là một sự trìu tượng trong mô hình hướng đối tượng và trong ngôn ngữ hướng đối tương.13 Mối quan hệ liên kết là sự kết nối vật lý hoặc logic giữa các đối tượng. Một lớp là mô tả cho một tập đối tượng có thuộc tính và hoạt động giống nhau. Nó có cấu trúc và hành vi tùy theo sự mô tả trong lớp.  Server: Một đối tượng không bao giờ hoạt động trên các đối tượng khác. lại vừa có thể bị các đối tượng khác thao tác. còn dữ liệu có thể dịch chuyển theo cả hai chiều trên liên kết. Một lớp bao gồm cấu trúc và hành vi. đôi khi có thể là cả hai chiều.

Một ứng dụng có thể truy cập các dịch vụ của nó thông qua tên lớp. Các phƣơng pháp đƣợc sử dụng để xác định lớp Trong thực tế có rất nhiều phương pháp có thể xác định được lớp trong một hệ thống.14 Lớp là một loại đối tượng đặc biệt.2.1. 2. Xác định lớp dựa trên khái niệm về danh sách lớp. . Nó là một tập hợp các đối tượng đã được tạo. Nó được dùng để tạo và huỷ các đối tượng thuộc về nó. Tuy nhiên ở đây tôi đề cập tới 2 phương pháp hay được dùng nhất: Xác định các danh từ. Nó cũng có thể được dùng để lưu dữ liệu và cung cấp cho các dịnh vụ trong cùng nhóm.

4. Trong khi đó.15 2. Trong UML. Khái quát hoá là mối quan hệ giữa một yếu tố mang tính khái quát cao hơn và một yếu tố chuyên biệt hơn. tồn tại trong hệ thống.  Một lớp là một nguyên mẫu của một đối tượng. lớp là một khái niệm trừu tượng. mang tính khái niệm. chỉ tồn tại ở dạng khái niệmđể mô tả cácđặc tính chung của một số đối tượng. Trong khi đó. Sự phụ thuộc là một quan hệ giữa các yếu tố gồm một yếu tố mang tính độc lập và một yếu tố mang tính phụ thuộc một sự thay đổi trong yếu tố độc lập sẽ ảnh hưởng đến yếu tố phụ thuộc. Nó xác định các hành động khả thi và các thuộc tính cần thiết cho một nhóm các đối tượng cụ thể. cũng có nghĩa là sự nối kết giữa các đối tượng của các lớp này. Sự tương tác lẫn nhau của lớp và đối tượng Lớp vàđối tượng.  Tất cả các đối tượng thuộc về cùng một lớp có cùng các thuộc tính và các phương thức.5. Nói chung. mặc dù có mối liên hệ tươngứng lẫn nhau. đối tượng là một thể hiện của lớp. lớp là khái niệm tồn tại khi phát triển hệ thống. Bài tập 1) Đối tượng là gì? Mối quan hệ giữa các đối tượng? 2) Lớp là gì? Mối quan hệ giữa các lớp? 3) Trình bày mối quan hệ giữa Lớp và Đối tượng? . đối tượng là một thực thể cụ thể tồn tại khi hệ thống đang hoạt động. trừu tượng. Trong khi đó. nhưng ở những mức độ trừu tượng hoá khác nhau. Có thể chứa chỉ các thông tin bổ sung một thực thể (một đối tượng là một thực thể của một lớp) của yếu tố mang tính chuyên biệt hơn có thể được sử dụng ở bất cứ nơi nào mà đối tượng mang tính khái quát hoá hơn được phép. 1 liên hệ được định nghĩa là một mối quan hệ mô tả một tập hợp các nối kết trong khi nối kết được định nghĩa là một sự liên quan về ngữ nghĩa giữa một nhóm các đối tượng. có thực.  Đối tượng là một thực thể cụ thể. nhưng bản chất lại khác nhau:  Lớp là sự trừu tượng hoá của các đối tượng. Một sự nâng cấp là một quan hệ giữa hai lời mô tả của cùng một sự vật. Mối quan hệ giữa các lớp Quan hệ giữa các lớp có 4 loại:  Liên hệ ( Association)  Khái quát hoá (Generalization)  Phụ thuộc (Dependency)  Nâng cấp (Refinement) Một liên hệ là một số nối kết giữa các lớp. 2.

Việc phân loại cũng hướng dẫn chúng ta trong việc đưa ra những quyết định về module hóa. Thông qua sáng tạo. Trong thiết kế hướng đối tượng. khó khăn trong việc triển khai và lập trình. chức năng hoặc là độ tin cậy. Chúng ta có thể chọn và đặt toàn bộ các lớp và đối tượng trong cùng một module hoặc trong các module khác nhau. xây dựng các lớp chính xác sẽ dẫn tới hệ thống chúng ta thiết kế rõ ràng. hoạt động không hiệu quả. tùy thuộc vào việc đóng gói. 3. phổ biến. Chúng ta có thể tham khảo những kinh nghiệm của họ ở trong lĩnh vực phân loại này vào việc thiết kế hướng đối tượng nhờ sự phân loại. Không có một quy định chung nào để tìm ra được sự phân loại tốt nhất.1. các nhà khoa học và cả các nhà toán học đặc biệt quan tâm. việc phân loại các đối tượng cùng với các tương tác của nó trong hệ thống là vô cùng quan trọng.16 CHƢƠNG III: SỰ PHÂN LOẠI Sự phân loại được thực hiện dựa trên những gì hiểu biết của chúng ta. tất cả đều phải dựa trên kinh nghiệm và yêu cầu của hệ thống hiện tại. tránh được việc trùng lặp công việc. Xác định các lớp và đối tượng Vấn đề phân loại đã được vô số các nhà triết học. tùy thuộc vào sự giống nhau mà chúng ta tìm thấy giữa các lớp và đối tượng đó. 3. Phƣơng pháp tiếp cận cổ điển và hiện đại Có 3 hướng tiếp cận phổ biến thường được dùng để phân loại: . Kinh nghiệm cho thấy rằng xác định bao gồm cả phát hiện và sáng tạo. và triển khai cũng dễ hơn. và sự phân cấp giữa các lớp với nhau. Nếu như chúng ta phân loại không đúng thì hệ thống chúng ta sẽ cồng kềnh. ngôn ngữ học. Cuối cùng. chúng ta tìm đến những nhóm sự việc mà có chung một cấu trúc hoặc các hành vi chung. phát hiện và sáng tạo là các vấn đề trong phân loại và việc phân loại là đi tìm những vấn đề tương tự nhau. Thông qua phát hiện. Bằng việc nhận ra các tương tác chung giữa các đối tượng. nhanh hơn. Phân loại cũng đóng vai trò trong việc chỉ định các quy trình xử lý. Tuy nhiên nếu chúng ta có cái nhìn tốt và việc phân loại các đối tượng. Khi chúng ta phân loại. chúng ta đưa ra các kĩ thuật được coi là quyết định trong việc thực hiện. chúng ta có thể nhận ra được những lớp trìu tượng và kĩ thuật mà tạo nên vấn đề. Chúng ta có thể đặt toàn bộ các quy trình cùng với nhau trong một bộ xử lý hoặc ở các bộ xử lý khác nhau. Tầm quan trọng của việc phân loại hợp lý Việc xác định các lớp và các đối tượng là một trong những phần đầy thử thách của phân tích và thiết kế hướng đối tượng.2. chúng ta đưa ra những khái quát trìu tượng cũng như các kĩ thuật mới xác định các đối tượng cộng tác như thế nào. Phân loại giúp chúng ta cách xác định những lớp tổng quát.

Lý thuyết nguyên mẫu Loại cổ điển Trong hướng tiếp cận cổ điển để phân loại. Với hướng tiếp cận này thì các lớp được tạo ra do việc xây dựng các khái niệm mô tả đầu tiên của lớp này và sau đó phân loại các thực thể theo các mô tả. ”Tất cả các thực thể mà có một thuộc tính hoặc một tập các thuộc tính giống nhau tạo lên một loại. Bài tập 1) Sự phân loại là gì? Tầm quan trọng của sự phân loại? 2) Trình bày phương pháp xác định lớp và đối tượng? . Nhóm khái niệm. Lý thuyết mẫu Một lớp của các đối tượng được miêu tả bởi một đối tượng nguyên mẫu. Nhóm khái niệm.17 - Loại cổ điển. Như là các thuộc tính cần thiết và đủ để định nghĩa một loại”. và một đối tượng được coi như là một thành viên của lớp đó nếu và chỉ nếu nó nó tương tự với các mẫu này.

Vì vậy trong bài giảng này tôi sử dụng UML như là một công cụ chính trong việc thiết kế và giảng dạy. Ngôn ngữ mô hình thống nhất UML UML là ngôn ngữ chuẩn cho việc quy định các tiêu chuẩn.     Phần trên cùng biễu diễn tên lớp. Phần thứ 3 được dùng để mô tả các thao tác có thể được thực hiện.1. Các khối của UML có thể được định nghĩa là: Things. java… UML được sử dụng cho việc tạo các bản kế hoạch cho việc phát triển phần mềm.1. UML là viết tắt của Unified Modeling Language. xây dựng. Phần thứ 2 biểu diễn các thuộc tính của lớp.2. 4. và tài liệu của một hệ thống phần mềm. Mô hình khái niệm của UML có thể được tạo bởi 3 phần từ chính sau: Các khối UML Các luật.1. hình dung. Diagrams. Có một số Strutural things sau: Class: biểu diễn cho một tập các đối tuwngj có cùng trách nhiệm. Relationships. Behavioral.1 Các khối cơ bản trong UML UML đóng vai trò quan trọng trong việc tạo nên mô hình khái niệm. UML có mối liên quan mật thiết với phân tích và thiết kế hệ thống hướng đối tượng. Grouping và Annotational. Things Things là các khối quan trọng của UML. Chúng thể hiện các phần từ vật lý và khái niệm. nguyên tắc để kết nối giữa các khối Kỹ thuật chung của UML. UML không phải là ngôn ngữ lập trình. Phần thứ 4 là phần lựa chọn dùng để hiển thị thêm các thành phần phụ thêm . nhưng các công cụ có thể được dùng để sinh ra mã lệnh trong các ngôn ngữ khác nhau.18 CHƢƠNG IV: PHÂN TÍCH VÀ THIẾT KẾ HƢỚNG ĐỐI TƢỢNG SỬ DỤNG UML 4. Structural things: Structural things định nghĩa phần cố định của mô hình. UML hoàn toàn khác với các ngôn ngữ lập trình hướng đối tượng như C++. nhiệm vụ. Things có thể là: Structural. 4.

Collaboration được biểu diễn bằng hình eclips nét đứt.19 - Interface: định nghĩa một tập các thao tác mà đặc tả rõ trách nhiệm của hệ thống. - Collaboration: định nghĩa sự tương tác lẫn nhau giữa các phần tử. Use case được biểu diễn bằng hình eclip liền nét với tên được ghi bên trong hình. Trong giao diện chưa có viết mã lệnh để thực thi. Được dùng để mô tả các chức năng. Được biểu diễn bằng một hình tròn. Tên của nó được ghi ở bên trong hình. bên dưới ghi tên của giao diện. - Use case: biểu diễn một tập các hoạt động được thực hiện bởi một hệ thống cho một mục đích xác định. . mô tả cái chung nhất.

- Active class: có cấu tạo giống với class nhưng đường viền bên ngoài đậm hơn. - Kí hiệu bắt đầu: được dùng để khởi tạo. . bắt đầu một quy trình xử lý.20 - Actor có thể được định nghĩa như là các thực thể bên trong hoặc bên ngoài tương tác với hệ thống. - Kí hiệu kết thúc: Được dùng để báo hiệu kết thúc một quá trình xử lý. Tên của nó được ghi ở bên trong hình và có thể add thêm các phần tử khác nếu cần thiết. Được dùng để miêu tả hành động hiện hành của hệ thống. - Component: Mô tả phần vật lý của hệ thống.

Behavioral things: Behavioral thing gồm có các phần động của mô hình UML. Note là Annotational thing duy nhất. mô tả của cuác phần tử UML. Các sự kiện là những tác nhân bên ngoài chịu trách nhiệm thay đổi. . 4.1. Có 4 loại quan hệ được đề cập sau đây: Dependency: là loại quan hệ giữa 2 sự việc mà khi có một phần tử thay đổi thì cũng ảnh hưởng tới một phần tử khác. Theo đó có một số loại behavioral things sau: Interaction: được định nghĩa như là một hoạt động bao gồm một nhóm các thông điệp được chuyển giữa các phần tử để hoàn thành một nhiệm vụ rõ ràng. Chỉ có duy nhất một loại Grouping thing: Package. riêng biệt. Quan hệ Quan hệ giữa các phần tử cũng là một khối quan trọng của UML. Annotation things: có thể được định nghĩa như là một kĩ thuật để đánh dấu. Nó cho thấy các phần tử được liên kết với nhau như thế nào và sự kết hợp này mô tả chức năng của chương trình. Grouping things: có thể được định nghĩa như là một kĩ thuật để nhóm các phần tử của mô hình UML lại với nhau.21 - Node: mô tả phần tử vật lý mà tồn tại trong thời gian chạy chương trình. chú thích. Node được biểu diễn bởi hình vuông với tên được ghi ở trong hình.3. State machine: State machine định nghĩa một chuỗi các trạng thái mà một đối tượng phải trải qua trong việc đáp ứng sự kiện.

UML đóng vai trò quan trọng trong việc mô tả các cách nhìn nhận khác nhau của hệ thống. Kiểu quan hệ này tồn tại trong trường hợp interface. Component diagram. Deployment diagram. kiểm thử. Collaboration diagram. nhà phân tích…Vì vậy trước khi thiết kế một hệ thống được hình thành với các phối cảnh khác nhau trong suy nghĩ của từng người dùng. Có một số cách nhìn nhận sau đây: . Object diagram. UML Diagram Tất cả các phần tử. Nó mô tả quan hệ kế thừa của các đối tượng. UML bao gồm 9 lược đồ sau: Class diagram. quan hệ giữa chúng tạo nên một biểu đồ UML hoàn chỉnh và lược đồ này biểu diễn một hệ thống. Statechart diagram. - Realization: có thể được định nghĩa như là một quan hệ trong đó 2 phần tử được liên kết với nhau. - Generalization: có thể được định nghĩa như là một quan hệ mà kết nối một phần tử chuyên dụng với những phần tử chung. Một phần tử mô tả một số trách nhiệm mà chưa được thực thi và môt phần tử khác thì thực thi chúng. phát triển. Activity diagram. 4. nhà đầu tư. Use case diagram. Nó cũng mô tả các đối tượng liên kết với nhau như thế nào. Người dùng có thể là lập trình viên. Biểu đồ UML là 1 phần quan trong trong toàn bộ quy trình.22 - Association là liên kết cơ bản được dùng để kết nối giữa các phần tử trong mô hình UML.4. 4.1. Sequence diagram. Kiến trúc UML Bất kỳ hệ thống nào cũng được sử dụng bởi những người dùng khác nhau.5.1.

Lược đồ triển khai được sử dụng để hỗ trợ khía cạnh này. Biểu đồ lớp biểu diễn một tập các lớp.1. Mục đích của biểu đồ lớp có thể tóm tắt như sau: Phân tích và thiết kế cách nhìn tĩnh của ứng dụng. . Mỗi một phần tử và các quan hệ của nó phải rõ ràng. 4. Deployment biểu diễn các nút vật lý của hệ thống mà tạo nên phần cứng.23 - Design của một hệ thống bao gồm các lớp. kết hợp.2. giao diện. Biểu đồ lớp được xem như là biểu đồ cấu trúc. Mục đích Mục đích của biểu lớp là xây dựng lên cách nhìn tĩnh của ứng dụng. Biểu đồ thành phần UML được dùng để hỗ trợ thực thi theo cách này. chức năng của hệ thống. Mô tả các trách nhiệm. Sử dụng các phần tử giống như ở trong Design. lập tài liệu của các ảnh hưởng khác nhau của hệ thống mà còn xây dựng nên mã lệnh cho ứng dụng. Implementation định nghĩa các thành phần được sắp xếp lại với nhau để tạo nên một hệ thống vật lý hoàn chỉnh. Biểu đồ lớp không chỉ được dùng cho việc mô tả bên ngoài. Nó biểu diễn cái nhìn tĩnh của một ứng dụng. Class diagram Giới thiệu Biểu đồ lớp là một dạng biểu đồ tĩnh. giao diện và các cộng tác. Làm nền tảng cho biểu đồ thành phần và biểu đồ triển khai. Trong biểu đồ lớp miêu tả các thuộc tính và các thao tác của một lớp và cũng giàng buộc với hệ thống. Khả năng của lớp (thuộc tính và thao tác) phải rõ ràng và duy nhất. Vẽ biểu đồ lớp nhƣ thế nào? Biểu đồ lớp có nhiều thuộc tính cần phải chú ý trong khi vẽ nhưng ở đây. Biểu đồ lớp là biểu đồ mà có thể ánh xạ trực tiếp sang ngôn ngữ lập trình hướng đối tượng.2. UML cung cấp biểu đồ lớp. và giằng buộc. trong tài liệu này chỉ đề cập tới những thuộc tính cơ bản nhất và hay dùng nhất. cộng tác. biểu đồ đối tướng để hỗ trợ cách thiết kế này. Các biểu đồ 4. - Process định nghĩa luồng của hệ thống. Biểu đồ lớp được sử dụng rộng rãi trong việc thiết kế mô hình hướng đối tượng bởi vì chỉ có biểu đồ UML mới có thể ánh xạ trực tiếp sang ngôn ngữ hướng đối tuợng. Một số điểm cần chú ý khi vẽ biểu đồ lớp: Tên của biểu đồ lớp nên đặt sao cho có thể mô tả được diện mạo của hệ thống.

24 - Chỉ biểu diễn những thuộc tính đặc biệt của lớp. Sơ đồ Object Sơ đồ Object thu được từ sơ đồ lớp vì vậy sơ đồ đối tượng có được là dựa trên sơ đồ lớp. Về cơ bản sơ đồ lớp và sơ đồ đối tượng là tương tự nhau.2. Hệ thống này được mô tả như sau: Đầu tiêu tất cả các Order (đơn đặt hàng) và Customer (Khách hàng) được xác định như là 2 phần tử của hệ thống và chúng có quan hệ 1-n bởi vì khách hàng có thể có nhiều Order (Đơn đặt hàng). Bởi vì mục đích cuối cùng là làm cho người dùng và lập trình viên có thể hiểu được hệ thống được mô tả như thế nào. Thêm vào đó chúng có thêm các chức năng như là dispatch() và receive().2. Hai lớp kế thừa có tất cả các thuộc tính của lớp Order. Ví dụ: Vẽ biểu đồ lớp của một hệ thống đơn đặt hàng trong một ứng dụng bán hàng. bởi vì những nếu chúng ta biểu diễn cả những thuộc tính không quan trọng sẽ làm cho hệ thống phức tạp. Chúng ta hãy tưởng tượng lớp Order là một lớp trìu tượng và nó có 2 lớp thực tế tồn tại (Kế thừa từ lớp Order) đó là SpecialOrder và NormalOrder. Sơ đồ đối tượng cũng biểu diễn cách nhìn tĩnh của một hệ thống nhưng hướng nhìn tĩnh này là snapshot của hệ thống tại các thời điểm khác nhau. Sơ đồ đối tượng được dùng để đưa ra một tập các đối tượng và quan hệ giữa chúng. Các sơ đồ đối tượng biểu diễn một trường hợp của một sơ đồ lớp. . 4. rối và khó triển khai. - Sử dụng note khi được yêu cầu mô tả diện mạo của biểu đồ.

Vẽ sơ đồ đối tƣợng nhƣ thế nào? Như chúng ta đã đề cập ở phần trước.25 Mục đích Mục đích của việc sử dụng sơ đồ là làm cho chúng ta có thể hiểu được rõ ràng để triển khai hệ thống một cách hiệu quả. Tiếp theo. một sơ đồ lớp là một trường hợp của sơ đồ lớp. tại thời điểm đó sẽ có những đối tượng sau: Customer (Khách hàng). số sơ đồ lớp được giới hạn. Trong sơ đồ lớp các phần tử là ở dạng trìu tượng miêu tả bản kế hoạch hoặc sơ đồ và trong sơ đồ đối tượng các phần tử là tồn tại hiện hữu biểu diễn đối tượng trong thế giới thực. Ví dụ: Chúng ta sử dụng ví dụ ở phần Sơ đồ lớp “Order management System” (Hệ thống quản lý đơn đặt hàng). Vì thế giải pháp để giải quyết vấn đề này là: Đầu tiên. Chuyển tới và nhận lại từ các kĩ sư phần mềm Biểu diễn quan hệ giữa các đối tượng của một hệ thống. Nhưng nế chung ta theo dõi sơ đồ đối tượng thì chúng ta có thể không giới hạn các trường hợp của sơ đồ này. Hướng nhìn tĩnh một tương tác. Khi có khách hàng tới đặt mua hàng. Trước khi vẽ sơ đồ đối tượng chúng ta nên nhớ một số điều sau đây: . một sơ đồ đối tượng bao gồm các trường hợp của sự việc được sử dụng trong sơ đồ lớp. Có nghĩa là sơ đồ đối tượng miêu tả sát với hệ thống thực hơn. Liên kết trong sơ đồ đối tượng được dùng để kết nối các đối tượng. Hiểu các hoạt động của đối tượng và quan hệ giữa chúng. Sự khác nhau giữa 2 sơ đồ đó là sơ đồ lớp biểu diễn một mô hình trìu tượng bao gồm các lớp và quan hệ giữa chúng. Điều đó ngụ ý nói rằng. Để lấy được các hệ thống riêng biệt. Mục đích là lấy được hướng nhìn tĩnh của hệ thống tại một thời điểm riêng biệt. Mục đích của sơ đồ đối tượng cũng giống như mục đích của sơ đồ lớp. phân tích hệ thống và quyết định trường hợp nào có dữ liệu và mối liên kết quan trọng. Nhưng sơ đồ đối tượng biểu diễn một trường hợp tại một thời điểm cụ thể. Sơ đồ đối tượng chứa các đối tượng. Các đối tượng và các liên kết là 2 phần tử dùng để xây dựng lên một sơ đồ đối tượng. Cả hai sơ đồ đề được tạo từ các thành phần cơ bản nhưng cách thành lập khác nhau. theo dõi các trường hợp này cùng với tất cả các chức năng có thể. Lựa chọn một số trường hợp tốt nhất. Từ những gì đưa ra ở trên thì một sơ đồ đối tượng đơn không thể lấy được tất cả các trường hợp hay không thể mô tả được hết tất cả các đối tượng của hệ thống.

Với các đơn đặt hàng có giá trị là 12. Những đối tượng đơn đặt hàng này được liên kết với đơn đặt hàng đặc biệt hoặc là bình thường (S1. NormalOrder. các tài liệu. 32 và 40 cho thấy rằng các đối tượng có giá trị tại thời điểm được quan sát. Bây giờ đối tượng khách hàng (C) được liên kết với 3 đối tượng đơn đặt hàng (O1. Sơ đồ thành phần Các sơ đồ thành phần được dùng để xây dựng lên diện mạo vật lý của hệ thống. Sự thi hành tĩnh biểu diễn cách tổ chức các thành phần tại các thời điểm riêng biêt. đối tượng đơn đặt hàng đặc biệt hoặc là bình thường được theo dõi thì chúng ta sẽ tìm thấy chúng có một vài giá trị.2. Mục đích của nó cũng khác với các sơ đồ khác. các sơ đồ thành phần được dùng để mô tả mường tượng về cách tổ chức và mối quan hệ giữa các thành phần trong hệ thống. Vì thế những mục đích của sơ đồ thành phần có thể được tóm tắt như sau: . Khách hàng có 3 đơn đặt hàng với các số lượng khác nhau (12. Vì vậy. O2. các thư viện. Khách hàng có thể tăng số lượng đơn đặt hàng lên trong thời gian tới và trong trường hợp đó số lượng sơ đồ đối tượng sẽ phản ánh rằng: nếu đơn đặt hàng. Những sơ đồ này cũng được dùng để tạo các hệ thống có thể thực thi. S2 và N1). SpecialOrder. 4. Một sơ đồ thành phần đơn không thể biểu diễn được toan bộ hệ thống nhưng một tập hợp các sơ đồ được dùng biểu diễn toàn bộ hệ thống. các tệp tin có thể thực thi tồn tại ở bên trong node. Sơ đồ thành phần có thể được miêu tả như là sự thi hành tĩnh của hệ thống.26 - Order (Đơn đặt hàng). và O3). Mục đích Sơ đồ thành phần là một loại sơ đồ đặc biệt trong UML. 32 và 40) cho từng thời điểm theo dõi. Vậy chúng ta tự hỏi diện mạo vật lý của hệ thống là gì? Diện mạo vật lý của hệ thống là các thành phần giống như các tệp tin.3. Nó không miêu tả các chức năng của hệ thống nhưng nó miêu tả các thành phần được dùng để tạo nên các chức năng đó.

Ban đầu. vật dụng. Sử dụng một tên đầy đủ nghĩa để xác định thành phần cho mỗi sơ đồ được vẽ Chuẩn bị các tài liệu trước khi sử dụng công cụ. thư viện…Vì thế mục đích của sơ đồ này có khác. Sơ đồ thành phần được sử dụng trong suốt giai đoạn thi hành của ứng dụng. Sơ đồ này rất quan trọng bởi vì nếu không có nó không một ứng dụng nào có thi hành một cách hiệu quả. Sau khi xác định các dụng cụ. Vẽ sơ đồ thành phần nhƣ thế nào? Sơ đồ thành phần được dùng để mô tả các phần vật lý của hệ thống. một số điểm sau cần được lưu ý: Dưới đây là sơ đồ thành phần cho hệ thống quản lý đơn đặt hàng của ví dụ ở phần trước. Vì thế sơ đồ biểu diễn các tệp tin trong ứng dung và mối quan hệ giữa chúng. Sơ đồ thành phần không giống như các sơ đồ UML khác bởi vì nó có mục đích khác các sơ đồ trước. Vì vậy trước khi vẽ sơ đồ thành phần các dụng cụ sau phải được xác định rõ ràng: Các tập tin được dùng trong hệ thống. ở đây dụng cụ là các tệp tin. hệ thống được thiết kế bằng việc sử dụng các sơ đồ UML khác và sau đó khi các dụng cụ là các sơ đồ thành phần được sử để lấy một ý tưởng của việc thi hành. file thực thi. Các phần này có thể là tệp tin.27 - Hình dung các thành phần của hệ thống. . Các thư viện và các dụng cụ khác liên quan tới ứng dụng. các thư viện. Xây dựng khả năng có thể thực thi bằng việc chuyển tới và nhận lại từ các kĩ sư phần mềm. Quan hệ giữa các vật dụng. Sử dụng node để ghi chú những điểm quan trọng. Mô tả cách tổ chức và quan hệ giữa các thành phần. các thư mục… Trong sơ đồ thành phần dưới đây 4 tệp tin được xác đinh và quan hệ giữa chúng được tạo ra. Trong thực tế sơ đồ thành phần chứa dlls.

Sơ đồ triển khai được dùng để mô tả các thành phần phần cứng nơi mà phần mềm được triển khai. các sơ đồ triển khai được sử dụng miêu tả hướng nhìn triển khai tĩnh của hệ thống. Vì vậy. Mô tả các thành phần phần cứng của hệ thống được dùng để triển khai các thành phần phần mềm. Miêu tả quá trình thực thi. Sơ đồ thành phần được dùng để miêu tả các thành phần và sơ đồ triển khai để miêu tả các thành phần được triển khai như thế nào trong phần cứng.2.28 4. Sơ đồ triển khai Sơ đồ triển khai được dùng để hình dung cấu trúc của các thành phần vật lý của hệ thống nơi mà các thành phần phần mềm được triển khai. Sơ đồ triển khai bao gồm các node và các mối quan hệ giữa chúng. Sơ đồ thành phần và sơ đồ triển khai có quan hệ chặt chẽ với nhau. Nhưng 2 sơ đồ đó là 2 sơ đồ đặc biệt được tạo ra đề tập trung vào cấu trúc phần cứng của hệ thống. Mục đích Từ triển khai bản thân nó cũng mô tả được mục đích của sơ đồ. Có thể tóm tắt các mục đích của sơ đồ triển khai như sau: Hình dung cấu trúc phần cứng của hệ thống. Vẽ sơ đồ triển khai nhƣ thế nào? . Sơ đồ triển khai được sử dụng bởi các kĩ sư hệ thống. UML được sử dụng để thiết kế tập trung và các “dụng cụ” phần mềm của hệ thống.4.

server 2.29 Sơ đồ triển khai biểu diễn hướng nhìn triển khai của hệ thống. Một sơ đồ triển khai bao gồm các nút. Khả năng mở rộng Khả năng bảo trì Portable Khi vẽ một sơ đồ triển khai chúng ta nên xác định Các nút Quan hệ giữa các nút Dưới đây là một ví dụ về sơ đồ triển khai của hệ thống quản lý đơn đặt hàng. Bởi vì các thành phần được triển khai sử dụng sơ đồ triển khai. Các nút là nothing nhưng là các phần cứng vật lý được dùng để triển khai ứng dụng. server 3. Người dùng sẽ kết nối tới ứng dụng qua đường truyền internet. Việc điều khiển sẽ được điều khiển từ caching server tới các cụm. Nó liên quan tới sơ đồ thành phần. Nó ảnh hướng tới các chức năng sau: Việc thực thi. Modem Caching Server Server Giả sử ứng dụng được triển khai dưới dạng WEB và chia ra các làm 3 cụm server: server 1. . Chúng ta xác định các nút sau: Màn hình. Các sơ đồ triển khai rất hữu ích cho các kĩ sư hệ thống. Một sơ đồ triển khai tốt là rất quan trọng nó ảnh hưởng tới chất lượng của ứng dụng.

Trong UML có 5 sơ đồ để xây dựng hành vi động của hệ thống và sơ đồ use case là một trong số đó. Các tác nhân. Vì vậy khi phân tích hệ thống để thu thập những chức năng có thể các use case được chuẩn bị và các tác nhân (actors) được xác định. Quan hệ giữa các use case và tác nhân. Chức năng được biểu diễn như một use case. Xác định các yếu tố bên trong và bên ngoài ảnh hưởng tới hệ thống. Vẽ sơ đồ Use case nhƣ thế nào? Sơ đồ use case được xem như là phân tích yêu cầu mức cao của hệ thống. các ứng dụng bên trong khác. Chọn tên sao cho có thể xác định được chức năng được thực hiện. Chỉ ra các mối quan hệ và độc lập trong sơ đồ. vì vậy. Khi vẽ sơ đồ use case chúng ta cần chú ý một số điểm sau: . Mục đích Mục đích của sơ đồ Use case là để nắm bắt các khía cạnh động của hệ thống. Vì vậy chỉ có hành vi tĩnh thì không đủ để xây dựng lên một hệ thống mà chúng ta cần phải có cả nhưng hành vi động. Đặt tên cho các tác nhân một cách dễ nhớ. Vì vậy khi vẽ sơ đồ use case ta cần xác định một số phần tử sau. Được sử dụng để có cái nhìn khách quan từ bên ngoài của hệ thống. Một sơ đồ use case biểu thị một chức năng riêng biệt của hệ thống. Sơ đồ này được sử dụng để xây dựng lên hệ thống hoặc các hệ thống con của ứng dụng. Chỉ ra tương tác giữa các yêu cầu và các tác nhân. Những yêu cầu này phần lớn là yêu cầu thiết kế. Tên của use case rất quan trọng.5. Trong sơ đồ tác nhân. Vì thế sơ đồ use case bao gồm các actors. các tác nhân có thể là người dùng.2. khi yêu cầu của hệ thống được phân tích các chức năng được thu thập lại trong use case. hoặc các ứng dụng bên ngoài. Nó được dùng để thu thập những yêu cầu của hệ thống bao gồm những tác nhân bên trong hoặc bên ngoài. Có những tác nhân bên trong và bên ngoài hệ thống được biết như là những actors. Sử dụng note khi yêu cầu làm rõ một vấn đề quan trọng nào đó. Hành vi động nghĩa là những hành vi của hệ thống khi chương trình chạy hoặc hoạt động. Sơ đồ Use Case Để xây dựng một hệ thống. Vì thế để xây dựng toàn bộ hệ thống thì chúng ta cần phải xây dựng nhiều hơn một sơ đồ use case.30 4. điều quan trọng là phải xử lý và theo dõi được những hành vi động. Có thể tóm tắt các mục đích của việc sử dụng sơ đồ use case như sau: Được dùng để thu thập các yêu cầu của hệ thống. use case và các mối quan hệ giữa chúng.

Hình dung các hành vi tương tác là công việc khó. Tác nhân customer nằm ngoài hệ thống được xem như là người dùng ngoài hệ thống. Sơ đồ tƣơng tác Ngay từ cái tên là sơ đồ tương tác chung ta cũng có thể hiểu được sơ đồ này được dùng để miêu rả các kiểu tương tác giữa các thành phần khác nhau trong mô hình. Một điểm quan trọng khác là để xác định ranh giới của hệ thống. Mô tả sự tương tác giữa các đối tượng. Vì vậy mục đích của việc dùng sơ đồ tương tác có thể được miêu tả ngắn gọn như sau: Để nắm bắt các hành vi động của hệ thống. Để mô tả cấu trúc tổ chức của các đối tượng. Để mô tả luồng thông báo trong hệ thống. Hành vi tương tác được biểu diễn trong UML bằng 2 sơ đồ được biết như là Sequence diagram và Collaboration diagram. SpecialOrder và NormalOrder use cases được suy ra từ Order use cases. Trong ví này ta xác định được 3 use cases (Order. Vì vậy giải pháp là sử dụng các mô hình khác nhau để nắm bắt được các diện mạo khác nhau của quá trình tương tác.2.31 Tiếp theo ví dụ trên. NormalOrder) và một tác nhân đó là Customer.6. SpecialOrder. Đó là vì tại sao sequence và collaboration diagram được sử dụng để nắm bắt bản chất động nhưng khác với di chuyển. 4. Vì vậy tương tác là một phần của hành vi động của hệ thống. . Mục đích Mục đích của biểu đồ tương tác là hình dung hành vi tương tác của hệ thống. Sequence diagram nhấn mạnh về các chuỗi thông báo và collaboration diagram nhấn mạnh về cấu trúc tổ chức của các đối tượng mà gửi và nhận thông báo. ta vẽ sơ đồ use case để thể hiện hệ thống quản lý đơn đặt hàng. Vi vậy chúng có quan hệ mở rộng với nhau.

Ví dụ: Chúng ta thực hiện vẽ sơ đồ tương tác cho bài toán hệ thống quản lý đơn đặt hàng. Các luồng thông báo giữa các đối tượng. Đầu tiên. Đối tượng SpecialOrder sẽ gửi một lệnh Dispatch() tới chính nó. Đối tượng sẽ gửi một lệnh xác nhận confirm() tới SpecialOrder. Order. Sơ đồ vẽ đầu tiên là sơ đồ trình tự và thứ 2 là sơ đồ cộng tác. Sơ đồ cộng tác: Biểu đồ này biểu diễn cách tổ chức các đối tượng . SpecialOrder và NormalOrder). Chúng ta có 2 loại sơ đồ tương tác trong UML. Sơ đồ trình tự: Đối với sơ đồ trình tự sẽ có 4 đối tượng cần quan tâm (Customer.32 Vẽ sơ đồ tƣơng tác nhƣ thế nào? Như chúng ta đã thảo luận từ trước mục đích của sơ đồ tương tác là để nắm bắt những diện mạo thay đổi của hệ thống. Một là sơ đồ trình tự và cái khác là sơ đồ cộng tác. khách hành sẽ gửi một đơn đặt hàng tới đối tượng Order. Diện mạo động có thể được định nghĩa như là chụp nhanh lại diện mạo của hệ thống đang chạy tại các thời điểm riêng biệt. Trình tự trong đó các thông báo được truyền đi. Chúng ta cần phải xác định các things trước khi vẽ sơ đồ: Các đối tương trong quá trình tương tác. Vì vậy để nắm bắt những diện mạo thay đổi chúng ta cần hiểu cái gì là diện mạo động và nó được hình dung như thế nào. Tổ chức đối tượng.

Vì vậy. đối tượng của một hệ thống Việc sử dụng sơ đồ statechart cũng thể hiện được các trạng thái của từng thành phần.2. Vẽ sơ đồ trạng thái nhƣ thế nào? Sơ đồ trạng thái được sử dụng để mô tả các trạng thái của các đối tượng khác nhau trong toàn bộ vòng đời của nó. Vì vậy mục đích quan trọng nhất của sơ đồ trạng thái là xây dựng vòng đời của một đối tượng từ khi khởi tạo tới khi kêt thúc. Mô tả các trạng thái khác nhau của đối tượng trong suốt thời gian sống của nó. Sơ đồ trạng thái mô tả luồng điều khiển từ trạng thái đầu tiên tới trạng thái khác. điểm nổi bật được đưa ra là trạng thái thay đổi dựa trên các sự kiện . đối tượng trong hệ thống được điều khiển bởi các sự kiện trong và ngoài hệ thống như thế nào. Các trạng thái là là riêng biệt. Hệ thống tác động trở lại có thể được định nghĩa như là một hệ thống mà đáp trả lại các sự kiện bên ngoài và bên trong. Định nghĩa trạng thái của bộ máy để xây dựng lên trạng thái của một đối tượng. cụ thể đối với một thành phần. Các trạng thái được định nghĩa nuhư là một điều kiên trong đó một đối tượng tồn tại và đối tượng đó thay đổi khi một vài sự kiện được gây ra. Để xây dựng vòng đời của một hệ thống tương tác. Vì vậy. Và những trạng thái này được thay đổi bởi các sự kiện. sơ đồ trạng thái rất hữu ích trong việc xây dựng lên hệ thống tác động trở lại. Tóm lại.7.33 4. mục đích của sơ đồ trạng thái của thế mô tả tóm tắt như sau: Để xây dựng diện mạo thay đổi của hệ thống. Mục đích: Sơ đồ trạng thái là một trong 5 sơ đồ UML được dùng để xây dựng lên tính năng động của một hệ thống. Sơ đồ statechart Mục đích của việc sử dụng sơ đồ Statechart là miêu tả các trạng thái khác nhau của một thành phần trong hệ thống. Sơ đồ trạng thái định nghĩa các trạng thái khác nhau của một đối tượng trong suốt vòng đời của nó.

Ví dụ dưới đây mô tả sơ đồ trạng thái của đối tượng Order. Việc thoát không đúng quy trình có thể xảy ra trong một vài trường hợp của hệ thống.2.8. join… Mục đích: . Khi toàn bộ vòng đời được hoàn thành nó được xem như là hoàn thành một giao dịch. Vì vậy điều khiển luồng được vẽ từ môt thao tác tới thao tác khác. Sơ đồ trạng thái của đối tượng Order được mô tả như hình dưới đây: 4. Sơ đồ hoạt động Sơ đồ hoạt động là một sơ đồ quan trọng khác trong UML để mô tả hiện mạo thay đổi của hệ thống. chính xác. Trước khi vẽ một sơ đồ trạng thái chúng ta phải rõ ràng một số điểm sau: Nhận biết các đối tượng quan trọng được phân tích. Nhận biết các trạng thái. và dispatch order. Những sự kiện này chịu trách nhiệm cho việc thay đổi trạng thái của đối tượng Order. Nhận biết các sự kiện. Trạng thái đầu tiên là trạng thái khởi đầu mà từ đó tiến trình bắt đầu. Hoạt động này có thể được mô tả như là hoạt động của hệ thống.34 trong và ngoài hệ thống. Các trạng thái tiếp theo được đến từ các sự kiện như là send request. Trong suốt toàn bộ vòng đời của hệ thống nó đi qua một chuỗi các trạng thái và có thể bị thoát không đúng quy trình. Sơ đồ hoạt động giải quyết tất cả các luồng điều khiển bằng việc sử dụng các thành phần như là fork. Sơ đồ hoạt động cơ bản là một luồng biểu đồ biểu diễn luồng bắt đầu từ hoạt động đầu tiên tới hoạt động khác. confirm request. Trạng thái của các đối tượng đóng vai trò quan trọng trong việc phân tích và triển khai chúng một cách đúng đắn.

Nhận đơn đặt hàng. Trước khi vẽ một sơ đồ hoạt động chúng ta phải hiểu rõ về các phần tử được sử dụng trong sơ đồ hoạt động. Gửi đơn đặt hàng tới khách hàng. Sau khi loại đơn đặt hàng được xác định hành động gửi đi được thực hiện và được xem như là kết thúc một tiến trình hoạt động. Xác nhận đơn Gửi đơn đặt hàng đi. nhánh và đồng thời của hệ thống. kết hợp Các điều kiện Các giàng buộc. Một hoạt động là một chức năng được thực hiện bởi hệ thống.35 Sơ đồ hoạt động không chỉ sử dụng cho việc cung cấp cái nhìn trực quan về hệ thống mà còn được sử dụng để xây dựng lên hệ thống có thể thực thi bằng việc chuyển tiếp và đảo ngược. Sơ đồ dưới đây được vẽ với 4 hoạt động chính. Mô tả chuỗi từ một hoạt động với một hoạt động khác. Liên kết. Vẽ sơ đồ hoạt động nhƣ thế nào? Sơ đồ hoạt động được sử dụng như là một flow chart bao gồm các hoạt động được thực hiện bởi hệ thống. Sau khi xác định các hoạt động chúng ta cần hiểu chúng kết hợp với các rằng buộc và điều kiện như thế nào. điều tra điều kiện được thực hiện để kiểm tra xem đơn đặt hàng là 1 trong 2 loại normal hay special order. Phần tử chính của một sơ đồ hoạt động là hoạt động của bản thân nó. Sau khi nhận được đơn đặt hàng. . Nhưng sơ đồ hoạt động không chính xác là một flow chart. Mục đích của sơ đồ hoạt động có thể được tóm tắt như sau: Vẽ luồng hoạt động của hệ thống. Như vậy khi vẽ sơ đồ hoạt động chúng ta phải xác định được các phần từ sau: Các hoạt động. Mô tả luồng song song.

36 Bài tập 1) Biểu đồ lớp là gì? Mục đích và cách vẽ biểu đồ lớp (Class diagram)? 2) Biểu đồ đối tượng là gì? Mục đích và cách vẽ biểu đồ đối tượng (Object diagram)? 3) Biểu đồ Use case là gì? Mục đích và cách vẽ biểu đồ Use case? 4) Biều đồ tuần tự là gì? Mục đích và cách vẽ biểu đồ tuần tự (Sequence diagram)? .

kết quả một hệ thống có thể thực thi. các lưu đồ. chẳng hạn người sử dụng. hoặc đặc tả yêu cầu (requirements specification). Một cách cơ bản là để hướng dẫn tạo ra hệ thống. Thường khi một phần mềm được tạo thành. dựa trên cơ sở là các yêu cầu (có thể mâu thuẫn) mà những người có vai trò quan trọng đối với hệ thống. Tùy theo mức độ phức tạp của phần mềm làm ra.37 CHƢƠNG V: QUY TRÌNH PHÂN TÍCH VÀ THIẾT KẾ 5.1.1. Quy trình vĩ mô: Vòng đời của triển khai phần mềm Mục đích của quy trình vĩ mô là để hướng dẫn toàn bộ triển khai hệ thống. Nền tảng Phân tích yêu cầu là công việc bao gồm các tác vụ xác định các yêu cầu cho một hệ thống mới hoặc được thay đổi. cách viết mã nguồn và ngôn ngữ lập trình được dùng. Phạm vi của quy trình vĩ mô là từ một ý tưởng ban đầu của hệ thống phần mềm mà thực hiện triển khai ý tưởng đó. .2. tùy theo cách thiết kế. các thuật toán và các mã giả). sau đó mẫu này được mã hoá bằng các ngôn ngữ lập trình và đưọc các trình dịch chuyển thành các khối lệnh (module) hay/và các tệp khả thi. để cho hoàn hảo thì phần mềm đó phải đưọc điều chỉnh hay sửa chữa từ khâu thiết kế cho đến khâu tạo thành phiên bản phần mềm một số lần. Thi hành (Implementation): thi hành. Thiết lập giới hạn của hệ thống. Việc phân tích yêu cầu một cách có hệ thống còn được gọi là kỹ nghệ yêu cầu (requirements engineering).2. đưa ra. cái mà phục vụ như là một đặc tả của sự thi hành trong môi trường thi hành đã chọn. Một phần mềm thông thường sẽ tương thích với một hay vài hệ điều hành. Tập hợp các tệp khả thi và các khối lệnh đó làm thành một phần mềm. Đôi khi nó còn được gọi một cách không thật chính xác bằng những cái tên như thu thập yêu cầu (requirements gathering. người thiết kế phần mềm sẽ ít nhiều dùng đến các phương tiện để tạo ra mẫu thiết kế theo ý muốn (chẳng hạn như là các sơ đồ khối. kiểm tra và tích hợp hệ thống. 5. Quy trình vĩ mô theo nội dung Quy trình vĩ mô theo nội dung bao gồm một số các giai đoạn sau: Yêu cầu (Requirements): Thiết lập và duy trì sự thỏa thuận với các khách hàng và các nhà đầu tư khác trên những gì hệ thống nên làm. requirements capture). 5. Thuật ngữ "phân tích yêu cầu" còn được áp dụng cụ thể cho công việc thuần túy phân tích (thay vì các việc khác chẳng hạn như làm rõ yêu cầu hay viết tài liệu yêu cầu). Phân tích và thiết kế: Biến đổi những yêu cầu trong thiết kế hệ thống. Việc phân tích yêu cầu có ý nghĩa quan trọng đối với thành công của một dự án.

Triển khai: Đảm bảo rằng sản phẩm phần mềm là sẵn sàng cho người dùng cuối của nó. bạn thiết lập và ưu tiên những yêu cầu cốt yếu của hệ thống. đạt được thỏa thuận với khách hàng trên những gì được xây dựng.2. phục vụ và giám sát dự án cũng như quản lý rủi ro.38 - Kiểm định: Kiểm định thực thi để đảm bảo rằng đã hoàn thành các yêu cầu. 5. Quy trình vĩ mô theo thời gian – Mốc và giai đoạn a. điều khiển sự thay đổi của các mục đó và quản lý cấu hình của các mục đó.2. Các quy tắc sau sẽ được thực hiện qua vòng đời của phần mềm Quản lý dự án: Quản lý dự án phát triển phần mềm. Giai đoạn bắt đầu (Inception): Mục đích: Mục đích của giai đoạn khởi đầu là đảm bảo rằng dự án có tính ứng dụng và khả thi. Xác nhận thông qua các bản demo mà phần mềm thực hiện các chức năng như đã thiết kế. Quản lý cấu hình và sự thay đổi: Xác định cấu hình các mục. đảm bảo rằng bạn hiểu và nắm được những rủi ro kèm theo việc xây dựng một hệ thống và quyết định môi trường triển khai nào được sử dụng (gồm cả quy trình và công cụ). Hoạt động: Trong suốt giai đoạn Khởi đầu. Môi trường: Cung cấp môi trường phát triển phần mềm bao gồm cả các quy trình và công tụ mà hỗ trợ cho đội triển khai. bao gồm: lên kế hoạch. .

chấp thuận. tập trung vào việc chuyển từ hiểu vấn đề và xác định những giải pháp chính tới việc triển khai một sản phẩm có thể triển khai. Hoạt động: Trong suốt giai đoạn chuyển tiếp. Tầm nhìn cung cấp một cách mô tả rõ ràng về những gì được xây dựng bao gồm phạm vi của nó. triển khai phần cốt lõi. Mốc (Milestone): Phạm vi được hiểu. xem xét. Mục đích: Giai đoạn chuyển giao được thực hiện khi bạn chắc chắn sản phẩm có thể được chấp nhận bởi người dùng cuối. Sản phẩm: Trong suốt giai đoạn này.39 Sản phẩm (Work Products): Sản phẩm chính của giai đoạn khởi đầu là tầm nhìn về những gì được xây dựng. một danh sách rủi ro. Sau đó nhóm triển khai thu thập những phản hồi của người dùng. yêu cầu của người dùng cuối. Sản phẩm (Work Product): Trong suốt giai đoạn Elaboration. hiểu rõ sự ưu tiên của các yêu cầu liên quan. Xây dựng (Construction) Mục đích: Xây dựng một kiến trúc ổn định. Kết quả của giai đoạn Elaboration không chỉ cung cấp một tài liệu về kiến trúc mà còn bao gồm những ấn phẩm thực tế của hệ thống. . Trong giai đoạn này chủ yếu tập chung vào làm cho chương trình khớp với yêu cầu. Chuyển giao. b. sản phẩm được cung cấp tới người dùng cho việc đánh giá và kiểm định. các thuộc tính hành vi. kiểm định và tinh chỉnh nền tảng xây dựng hệ thống dựa trên kết quả của việc kiểm định. ảnh hưởng qua lại và quan hệ với các hệ thống đã tồn tại cũng như là bất kì các rằng buộc phải được theo dõi. Hoạt động: Trong suốt giai đoạn xây dựng. c. thiết lập phần nền tảng của kiến trúc. và khi tất cả các rủi ro đã được giảm bớt để xác định giá và lịch biểu cho quá trình triển khai hệ thống. xác định kiểu kiến trúc kĩ thuật và môi trường phát triển. d. Mốc: Hệ thống sẵn sàng cho người dùng cuối kiểm tra: Giai đoạn xây dựng hoàn thành khi các chức năng và chất lượng của các ấn bản là cần thiết để triển khai tới người dùng cuối cho một số người dùng cuối khác kiểm tra. Mốc: Giai đoạn Elaboration được hoàn thành khi kiến trúc được xác lập tính hợp lệ với tất cả các yêu cầu của hệ thống và về chức năng và không chức năng. Giai đoạn Khởi tạo được hoàn thành khi có sự hiểu rõ ràng về những gì được xây dựng (toàn bộ phạm vi và các yêu cầu chính của hệ thống). kiến trúc được phê duyệt bằng việc tao ra một chuỗi kiến trúc có thể thực thi. một chuỗi các ấn bản có thể thực thi được đưa ra đáp ứng những kịch bản. việc phát triển hệ thống được hoàn thành dựa trên kiến trúc cơ sở được xây dựng từ giai đoạn trước. Chi tiết bổ sung (Elaboration): Mục đích: Điều đầu tiên đó là những gì cần xây dựng phải được hiểu và đạt được sự đồng ý. đặc trưng. Hoạt động: Giai đoạn Elaboration bao gồm việc quyết định đưa ra kiến trúc.

2. 5. phần lớn thời gian sẽ được sử dụng trên việc phân tích và thiết kế. Sản phẩm: Sản phẩm được đưa ra trong suốt giai đoạn chuyển giao bao gồm sản phẩm đóng gói. Hình trên miêu tả một dự án di chuyển thông qua một chuỗi quá trình được lặp đi lặp lại. thời gian lặp lại sử dụng trong các quy tắc khác nhau phụ thuộc vào xuất hiện trong giai đoạn lặp nào. Nếu quá trình lặp lại được thực hiện trong giai đoạn xây dựng thì phần lớn thời gian được sử dụng trên việc triển khai và kiểm định. như là cấu hình và thay đổi quan lý. Mốc: Hệ thống sẵn sàng cho việc triển khai. môi trường. đối với một số disciplines. 5. Quy trình vi mô: Quá trình phân tích và thiết kế Như hình mô tả dưới đây. cài đặt và hướng dẫn sử dụng. . Quá trình vĩ mô cung cấp đầu vào cho quá trình vi mô và sử dụng đầu ra của quá trình vi mô. phần lớn thời gian sẽ được sử dụng trên việc xử lý các yêu cầu. quản lý dự án.3. các mốc đạt được bằng việc thực hiện 1 hoặc nhiều lần lặp lại và những lần lặp lại này có thể bao gồm các hoạt động trong bất kì vào trong toàn bộ quy tắc. Nếu quá trình lặp lại được thực hiện trong giai đoạn khởi đầu. được thực hiện thông qua vòng đời của chương trình. tài liệu hỗ trợ. Các tài liệu hỗ trợ dùng chương trình được hoàn thiện và gửi cho người dùng cuối. Kích thước của các hộp trong mỗi giai đoạn biểu thị lượng thời gian được sử dụng trên giai đoạn đó.40 thiết lập cấu hình. quá trình phân tích và thiết kế hệ thống được thực hiện trong toàn bộ quá trình phát triển phần mềm. Nếu quá trình lặp lại được thực hiện trong giai đoạn chi tiết. Tuy nhiên. Tất nhiên. Quy trình vĩ mô theo thời gian – Lặp đi lặp lại Trong quy trình vĩ mô.3. tài liệu hướng dẫn. Đặc biệt quá trình vi mô lấy yêu cầu được cung cấp bởi quá trình vĩ mô và sản xuất ra đặc tả thiết kế mà đã được thực hiên. kiểm thử và triển khai trong quá trình vĩ mô.

nó phụ thuộc vào phạm vi của hệ thống. bạn sáng tạo ra các phần tử mà cung cấp các hành vi mà các phần tử trong giai đoạn phân tích yêu cầu. Trong thiết kế. Trong phân tích. truyền thống của phân tích và thiế kế là tập trung vào việc làm mờ và thay thế được thực hiện tại các mức độ khác nhau của trìu tượng. Bạn bắt đầu quá trình thiết kế ngay khi bạn hoàn thành việc xây dựng mô hình các hành vi của hệ thống. là phù hợp và có thể phục vụ tốt cho việc thiết kế. khái niệm Trong quá trình vi mô. Việc thiết kế được xem như là hoàn thành khi nó mô tả chi tiết đủ để thực hiện và kiểm định. các giai đoạn phổ biến. Việc phân tích được xem như là hoàn thành khi nó biểu diễn đúng đắn. bạn tìm đến xây dựng một thế giới bằng việc xác định các phần tử mà tạo nên các vấn đề trong hệ thống và mô tả chức năng của chúng. ở đây chúng ta cũng sẽ mô tả quá trình vi mô trong 2 lĩnh vực đó là khái niệm và nội dung. 5. và thiết kế lấy kết quả của quá rình phân tích và đưa ra một đặc tả mà có hiệu quả trong việc thực hiện. Số mức không thể xác định. Phân tích lấy các yêu cầu của hệ thống và đưa ra một giải pháp ban đầu.3.1. chính xác các yêu cầu của hệ thống. Phân tích và thiết kế được thực hiện tại các mức của trìu tượng qua vòng đời phát triển. Phân tích tập trung vào hành vi chứ không phải cấu tạo. . trách nhiệm và sự cộng tác. Mức độ trìu tƣợng.41 Chúng ta đã mô tả quá trình vĩ mô trong 2 lĩnh vực đó là thời gian và nội dung.

mà được thực hiện cho phạm vi xác định và tại mức độ trìu tượng xác định. chuẩn bị các phần tử cho mức độ trìu tượng tiếp theo.42 Các hành động Quá trình vi mô bao gồm một tập các hành động. hỗ trợ cho sự kết hợp các phần tử. Xác định các phần tử? Tìm hiểu. Định nghĩa semantic của các phần tử: Thiết lập các hành vi và các thuộc tính của các phần tử. . Định nghĩa các mối quan hệ giữa các phần tử. Định nghĩa sự kết hợp giữa các phần tử: Mô tả các phần tử kết hợp với nhau như thế nào để cung cấp các hành vi mà hệ thống yêu cầu. Định nghĩa các mối quan hệ giữa các phần tử. bao gồm cả việc miêu tả kĩ thuật chung. Việc mô tả bao gồm cấu trúc cần thiết cho diện mạo của mô hình phân tích và thiết kế. Các hoạt động của quá trình vi mô được mô tả bởi hình sau: Sản phẩm Có 2 sản phẩm chính sẽ được sinh ra trong quá trình vi mô: Mô tả kiến trúc: Mô tả kiến trúc của hệ thống. khám phá hoặc đề xuất các phần tử sẽ sử dụng.

quá trình vi mô cung cấp một khuôn mẫu cho phát triển và khám phá kiến trúc thay thế. sự khác biệt đó là mức độ trìu tượng được đề cập. Quá trình vi mô tập trung vào việc chọn lọc các phần tử đã được phân tích rõ ràng. Từ góc nhìn của kiến trúc sư. Việc phân tích các phần tử này miêu tả gần đúng các thành phần của hệ thống mà được sử dụng trong quá trình thiết kế thành phần dể xác định việc thiết kế các phần tử. quá trình vi mô tập trung vào việc tạo một phiên bản ban đầu của kiến trúc. Quá trình chọn lựa nên dừng lại khi có đủ chi tiết cho việc thiết kế các lớp được thực thi. Khi thực hiện phân tích kiến trúc.43 - Mô hình phân tích thiết kế bao gồm các phần tử phân tích thiết kế của giải pháp phần mềm và việc tổ chức chúng. Trong thành phần thiết kế. những kiến trúc này thúc đẩy các kiến trúc đã tồn tại hoặc các kiến trúc nền tảng ban đầu. Quá trình vi mô và mức độ trừu tƣợng Quá trình vi mô áp dụng như nhau đối với kiến trúc sư dự án và kĩ sư ứng dụng. Từ quan điểm của kĩ sư. các phần tử thiết kế và trách nhiệm của chúng. hành vi và quan hệ của chúng. kiến trúc ban đầu được phát triển từ kiến trúc phân tích mà đã được lọc. bạn tiếp tục chọn lựa các lớp thông qua làm việc với các nội dung. Trong quá trình thiết kế kiến trúc. Trong suốt quá trình thiết kế chi tiết. quá trình vi mô tập trung vào việc phân tích các phần tử xác định và trách nhiệm cũng như là tương tác giữa chúng. Trong thành phần phân tích. Các kĩ thuật phân tích cũng được chọn lựa vào trong kĩ thuật thiết kế mà thúc đẩy các công nghệ trước đó. lựa chọn dựa trên những kinh nghiệm trong suốt quá trình phân tích kiến trúc. cũng như các mối quan hệ mà miêu tả hành vi yêu cầu của hệ thống được thực hiện như thế nào trong các phần tử đó. Bài tập 1) Trình bày quy trình xây dựng phần mềm? 2) Trình bày quy trình phân tích và thiết kế trong xây dựng phần mềm? . quá trình vi mô cung cấp các hướng dẫn trong việc ra quyết định thích ứng với từng kiểu cấu trúc. quá trình vi mô tập trung vào việc chọn lọc việc thiết kết các thành phần bằng việc định nghĩa nó trong các lớp mà có thể thực thi trực tiếp bằng các kĩ thuật thực hiện đã chọn. Việc sử dụng lại cũng đóng vai trò quan trọng. Các phần tử thiết kế được định nghĩa tại mức độ này biểu diễn các khối chính của toàn bộ kiến trúc nền tảng và các mối quan hệ của chúng xác định toàn bộ cấu trúc của hệ thống.

theo dõi vết tuyến đường. Hơn nữa. Predict Failure: Thực hiên phân tích những điều kiện của hệ thống và đưa ra những cảnh báo lỗi liên quan tới kế hoạch vận hành của từng tuyến xe lửa. Vì vậy. Chúng ta có thể thấy rằng hệ thống xe lửa ở các nước phát triển rất mạnh bởi vì nó mang lại hiệu quả kinh tế cao hơn so với các phương tiện khác. có thể là tự động hoặc làm thủ công để tránh những vụ va chạm trên tuyến xe lửa. giám sát giao thông. Những use cases này thiết lập các yêu cầu chức năng cơ bản cho hệ thống quản lý giao thông xe lửa. xung đột tuyến đường và ghi lại nhật ký. bởi vì mỗi chuyến sức vận chuyển có nó có thể lên tới hàng trăm thậm chí hàng ngàn người. Monitor Train Systems: Giám sát hệ thống xe lửa cho nhưng chức năng thích hợp. đối với một hệ thống xe lửa cần phải được giám sát chặt chẽ. Monitor Traffic: Giám sát tất cả các tuyến xe lửa trong một vùng. Chúng cho ta biết hệ thống phải làm những gì đối với người sử dụng nó. Từ những chức năng trên. Người dân vẫn thích sử dụng hệ thống xe lửa để đi lại những cung đường dài.1. dự báo lỗi. kế hoạch này vạch rõ các tuyến đường mà xe lửa sẽ đi qua. việc sử dụng xe lửa đi lại cũng được coi như là phương tiện an toàn nhất trong các phương tiện đường bộ. chúng ta có thể đưa ra 8 use cases sau: Route Train: Thiết lập một kế hoạch. Avoid Collision: Đưa ra biện pháp. Plan Traffice: Thiết lập một kế hoạch giao thông mà cung cấp hướng dẫn trong việc triển khai kế hoạch tuyến xe lửa tại một thời gian nhất định và một vùng nhất định. Yêu cầu cho hệ thống quản lý tuyến đƣờng xe lửa: Hệ thống quản lý tuyến đường xe lửa có 2 chức năng chính: Dẫn đường và giám sát tuyến đường. Hệ thống điều khiển: Quản lý hệ thống giao thông Khởi đầu Ở một số nước tiên tiến thì việc sử dụng hệ thống xe lửa được coi như là phổ biến. Thêm vào đó chúng ta .44 CHƢƠNG VI: ÁP DỤNG PHÂN TÍCH BÀI TOÁN CỤ THỂ 6. Trong bài này chúng ta tập phân tích một hệ thống quản lý đường xe lửa bằng việc xác định các yêu cầu và hệ thống tác nhân. Track Train Location: Giám sát vị trí của các xe lửa. tránh va chạm. Log Maintenance: Đưa ra biện pháp để ghi lại những nhật kí đã thực hiện trên tuyến xe lửa. Các chức năng liên quan bao gồm lập kế hoạch.

Cung cấp vị trí chính xác của tàu trong vòng 10 yards. tương tác với thiết bị ngoài. TrainEngineer: Giám sát tình trạng hoạt động của xe lửa. Những ràng buộc. Qua tìm hiểu và phân tích thì chúng ta có thể đưa ra 3 kiểu người dùng khác nhau tác động tới hệ thống: Dispatcher. Cung cấp một hệ thống hoạt động chính xác ở mức 99. Đáp ứng đầu vào trong vòng 10s. Navstar GPS: Cung cấp dịch vụ định vị dùng để theo dõi tàu hỏa. trách dư thừa. . Dispatcher: Thiết lập tuyến đường xe lửa và theo dõi việc tiến hành của từng xe lửa riêng biệt. Ngoài ra hệ thống còn giao tiếp. Navstar GPS. Bây giờ chúng ta đã có những yêu cầu của bài toán. Cung cấp chính xác vận tốc của xe lửa.45 có những yêu cầu không có chức năng và giằng buộc mà tác động lên các yêu cầu được định rõ bởi các use case của chúng ta: Những yêu cầu không có chức năng: Vận chuyển hành khách và hàng hóa an toàn. Maintainer: Giám sát tình trạng duy tri hệ thông xe lửa.99% Cung cấp các đầy đủ các chức năng. Các tác nhân đóng vai trò sau trong hệ thống. Đáp ứng các tiêu chuẩn quốc gia Phù hợp về giá thành cả về phần cứng và phần mềm. TrainEngineer. và Maintainer. Quay lại bài toán quản lý hệ thống đường xe lửa của chúng ta. Hỗ trợ tốc độ xe lửa lên tới 250 dặm/giờ.

các mô hình use case. Yêu cầu: . các đặc tả use case chính và các kiến trúc cần thiết. đối với nhiều doanh nghiệp. các đặc tính chủ yếu. Giải pháp được đưa ra là chúng ta xây dựng một hệ thống cho phép theo dõi thời gian làm việc cũng như kì nghỉ của mỗi công nhân. Ứng dụng Web: Hệ thống theo dõi kì nghỉ Ngày nay. do đó việc quản lý thời gian làm việc cũng như thời gian nghỉ gặp nhiều khó khăn. Tương ứng với số thời gian làm việc thì đòi hỏi thời gian nghỉ ngơi cũng phải hợp lý. các nhà quản lý có ít thời gian gặp được công nhân. sự tự chủ và độc lập của công nhân ngày càng tăng.46 6. Khởi đầu Yêu cầu của hệ thống là được miêu tả một cách tóm tắt các tài liệu.2. Mỗi công nhân có thể tham gia vào nhiều dự án vì thế phải phân chia thời gian sao cho hợp lý. Vì vậy.

Cho phép người dùng có thể truy cập lại thời gian trước đó và cho phép yêu cầu được thực hiên đến một năm rưỡi trong tương lai. . Mô hình use case mức cao nhất chưa 4 tác nhân và 8 use case được miêu tả ở hình dưới đây: Nhìn vào sơ đồ trên. Cung cấp một dịch vụ giao diện Web cho các hệ thống nội bộ khác truy vấn và đưa ra bất kỳ thời gian nghỉ của nhân viên nào. và thời gian nghỉ thương niên.47 Hệ thống theo dõi kì nghỉ sẽ cung cấp từng nhân viên riêng biệt cùng với khả năng để quản lý thời gian nghỉ của họ. Hệ thống sẽ cung cấp các đặc tính chính sau: Thực thi một cách linh hoạt cho việc kiểm chứng và xác minh lại thời gian yêu cầu. nghỉ việc vì đau ốm. Một nhân viên sử dụng hệ thống để quản lý thời gian nghỉ của họ. triển khai mở rộng của mạng nội bộ hiện tại và sử dụng tính năng đăng nhập một lần cho tất cả các cơ chế xác thực. Cho phép người quản lý trực tiếp tặng thời gian nghỉ thêm cho nhân viên. Cho phép quản lý phê duyệt. chúng ta thấy có 4 tác nhân sau. Lưu giữ lại những bản ghi cho tất cả các giao dịch. Employee: là người sử dụng hệ thống chủ yếu. Được thực hiện. Sử dụng e-mail thông báo để yêu cầu quản lý phê duyệt và thông báo cho nhân viên biết trạng thái thay đổi. Sử dụng phần cứng hiện tại.

- Clerk: Một thành viên của hệ thống quản lý người có đầy đủ các quyền để xem hồ sơ. trơn. không bị lỗi Sơ đồ trên còn mô tả các use case chính sau: Bài tập 1) Áp dụng phân tích và thiết kế hệ thống vào bài toán quản lý Hồ sơ sinh viên? 2) Áp dụng phân tích và thiết kế hệ thống vào bài toán quản lý Kết quả học tập của sinh viên? Manage Time: Miêu tả các nhân viên yêu cầu và xem thời gian nghỉ như thế nào. dữ liệu cá nhân của một nhân viên và chịu trách nhiệm cho tất cả các thông tin về nhân viên. Một thư ký có thể thêm hoặc loại bỏ bất kỳ một bản ghi nào trong hệ thống. Manage Locations: Miêu tả một Clerk quản lý các bản ghi như thế nào. Edit Employee Record: Miêu tả một Clerk của hệ thống chỉnh sửa thông tin của một nhân viên như thế nào. Manage Leave Categories: Override Leave Records: Back Up System Logs. Miêu tả Admin sao lưu dữ liệu. Có thể quản lý thời gian gian nghỉ của một nhóm nhân viên. Approve Request: Miêu tả một quản lý đáp ứng yêu cầu của một nhóm như thế nào. . - System Admin: Có vai trò chịu trách nhiệm cho hệ thống chạy ổn định.48 - Manager: là một nhân viên cũng sử dụng hệ thống như các nhân viên khác với mục đích tương tự nhưng có thêm một số quyền cao hơn nhân viên bình thường.

49 MỘT SỐ ĐỀ THI MẪU .

nộp lại đề sau khi thi Đề thi số: Ký duyệt đề: x x .50 Trƣờng Đại Học Hàng Hải Việt Nam Khoa Công nghệ Thông tin BỘ MÔN HỆ THỐNG THÔNG TIN -----***----- THI KẾT THÚC HỌC PHẦN Tên học phần: PHÂN TÍCH& THIẾT KẾ HT HƢỚNG ĐỐI TƢỢNG Năm học: x Thời gian: 60 phút Câu 1: (2 điểm) So sánh Phân tích thiết kế hệ thống hướng cấu trúc với Phân tích thiết kế hệ thống hướng đối tượng? Câu 2: (2 điểm) Đối tượng là gì? Mối quan hệ giữa các đối tượng? Câu 3: (3 điểm) Trình bày các phương pháp phân loại? Lấy ví dụ? Câu 4: (3 điểm) Trình bày các khối cơ bản trong UML? ----------------------------***HẾT***---------------------------Lưu ý: . xóa đề thi.Không sửa.

nộp lại đề sau khi thi Đề thi số: Ký duyệt đề: x x .51 Trƣờng Đại Học Hàng Hải Việt Nam Khoa Công nghệ Thông tin BỘ MÔN HỆ THỐNG THÔNG TIN -----***----- THI KẾT THÚC HỌC PHẦN Tên học phần: PHÂN TÍCH& THIẾT KẾ HT HƢỚNG ĐỐI TƢỢNG Năm học: x Thời gian: 60 phút Câu 1: (2 điểm) Trình bày những ưu và nhược điểm của Phân tích và thiết kế hệ thống hướng đối tượng? Câu 2: (2 điểm) Lớp là gì? Mối quan hệ giữa các lớp? Câu 3: (3 điểm) Liệt kê các loại biểu đồ (Diagrams) trong UML? Mục đích của từng loại biểu đồ? Câu 4: (3 điểm) Biểu đồ lớp là gì? Trình bày mục đích và cách vẽ biểu đồ lớp trong UML? ----------------------------***HẾT***---------------------------Lưu ý: .Không sửa. xóa đề thi.

xóa đề thi.52 Trƣờng Đại Học Hàng Hải Việt Nam Khoa Công nghệ Thông tin BỘ MÔN HỆ THỐNG THÔNG TIN -----***----- THI KẾT THÚC HỌC PHẦN Tên học phần: PHÂN TÍCH& THIẾT KẾ HT HƢỚNG ĐỐI TƢỢNG Năm học: x Thời gian: 60 phút Câu 1: (2 điểm) Đối tượng là gì? Lớp là gì? Trình bày mối quan hệ giữa Lớp và Đối tượng? Cho ví dụ? Câu 2: (2 điểm) Trình bày các khái niệm: Use case. nộp lại đề sau khi thi Đề thi số: Ký duyệt đề: x x . Actor trong UML? Cho ví dụ? Câu 3: (3 điểm) Vòng đời của xây dựng phần mềm? Câu 4: (3 điểm) Biểu đồ tuần tự (Sequence) là gì? Trình bày mục đích và cách vẽ biểu đồ tuần tự trong UML? ----------------------------***HẾT***---------------------------Lưu ý: .Không sửa.

Sign up to vote on this title
UsefulNot useful