You are on page 1of 52

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

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. 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.6 Pascal 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. Về kiến trúc. Trong hình này.NET Dựa trên các đối tượng Framework cơ bản của Microsoft Visual C# Visual Basic .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 . 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.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 đó. Trong hình 1-1.NET Visual Basic cho Framework của Microsoft .. . Do đó dẫn đến việc lập trình theo các Framework.

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. phương pháp cấu trúc thể hiện được ưu điểm. Khi chúng ta cần chỉnh sửa một hệ thống lớn. 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. “ Chương trình đầu tiên. Thứ hai. 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. .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. 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. bố trí rõ ràng thông qua các chương trình con. nền tảng của lập trình cấu trúc là sắp xếp. Thứ nhất. 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 đó. 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. 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. Thứ ba.” 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 đó. 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.

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.2. Tương tự. 1.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. 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. Do đó. 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. 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. . sử dụng lớp và đối tượng như là các khối xây dựng cơ bản.

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. không chỉ là ngôn ngữ lập trình hướng đối tượng. Một trong những phương pháp đó là hướng thủ tục. cơ sở dữ liệu. không đổi. 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. Rapid Application Development (RAD). và quản lý cũng dễ dàng hơn. 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. như đã thảo luận ở phần trước. 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. 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.3. 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). 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. Nó không phá vỡ các cấu trúc của chương trình đã được thiết kế trước đó. nhận biết nó (Định danh của nó và toàn bộ các thuộc tính). 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. và ngay cả với kiến trúc của máy tính. đượ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. Họ lập trình theo mô hình mẫu của ngôn ngữ mà họ sử dụng. . 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. nền tảng mô hình 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. Một đối tượng là một người.9 Trên thực tế. 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. đị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. rõ ràng hơn. 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 SDLC được sử dụng phổ biến nhất đó là Structured System Analysis and Design. Object-Oriented Analysis and Design. Thực vậy. Tuy nhiên. 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ế. mô hình đối tượng đã bị chi phối bổi một số tác nhân. 1.

Các quy trình được xây dựng bởi các lược đồ luồng dữ liệu. Tiếp theo. 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. 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ương pháp OOAD có thể chia ra làm 2 lĩnh vực chính: . 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. Ở đây. Mô hình dữ liệu được định nghĩa bằng việc quan hệ giữa các thực thể (ERD). 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. Nhà phân tích sẽ gặp gỡ với người dùng và giải quyết vấn để. 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.10 - Quan hệ với cai gì (Quan hệ của nó với các đối tượng khác). Không có sự tách biệt giữa thực thể dữ liệu và tệp tin. phạm vi của hệ thống được định nghĩa là nơi hệ thống được triển khai. Một đối tượng là một vấn đề trong hệ thống máy tính. bỏ qua những phần nhỏ và chỉ tiết. trong giai đoạn này phải xác định được các yêu cầu. Không có sự tách biệt giữa quy trình và chương trì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. 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. làm việc cùng nhau để hoàn thành nhiệm vụ. 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. ERD mô tả dữ liệu (thực thể) và sự phối kết hợp giữa chúng. Nó làm những cái gì (Các phương thức của nó thực hiện với CSDL). xác nhật những vấn đề mà người dùng cần. 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. 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. Những phần này sẽ được phân tích sau. 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.

Đ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 đề. Mô hình đối tượng dựa trên các yêu tố cơ bản bao gồm: abstraction. 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? . 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. 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ụ.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. - 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. modularity. hierarchy…Mục tiêu tập trung ủa mô hình đối tượng là phân tích đối tượng. Một hệ thống hướng đối tượng sẽ có một số đối tượng.

Vậy ta tự hỏi. đố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ể.kết tập (aggregation) Mối quan hệ liên kết (link) . nhưng chúng ta đã đề cập từ chương trước. Cơ bản về đối tượng Trong khóa học này. Chúng ta lấy một ví dụ về đối tượng là An.2. 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. 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. Như vậy. đố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.1. như là một sinh viên. 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. 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ó hai loại quan hệ giữa các đối tượng là : . 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. Cú pháp chuẩn là: tên đối tượng: tên lớp. 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.12 CHƢƠNG II: LỚP VÀ ĐỐI TƢỢNG 2.liên kết(link) . Phần dưới liệt kê các thuộc tính của đối tượng đó. một sinh viên trường Đại học Hàng hải. 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. 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 đó. để chúng ta có thể theo dõi hay lấy thông tin về các khóa học khác nhau. một đối tượng có thể là tồn tại ở dạng vật chất. một khóa học. 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. 2.

Với mỗi liên kết. phần giữa định nghĩa tất cả các thuộc tính của lớp. . sau đó được đưa tới supplier... Nó phục vụ như là một mẫu khi mà tạo một đối tượng mới.  Server: Một đối tượng không bao giờ hoạt động trên các đối tượng khác. 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ột động cơ . đôi khi có thể là cả hai chiều. nó chỉ có thể bị thao tác bởi các đối tượng khác. 2.  Agent: Là đối tượng vừa có thể hoạt động trên các đối tượng khác. Một lớp bao gồm cấu trúc và hành vi. một hộp số. 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. Nói một cách khác. lại vừa có thể bị các đối tượng khác 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. 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. Thông thường. trong đó một đối tượng(client) sử dụng những dịch vụ của đối tượng khác (supplier). Trong cách nói khác thì đối tượng là một trường hợp cụ thể của lớp.3. Ví dụ: Một chiếc xe ô tô có 4 bánh. còn dữ liệu có thể dịch chuyển theo cả hai chiều trên liên kết. Nó luôn luôn bắt nguồn từ lớp. 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 liên kết biểu diễn một liên hợp (association) xác định. một cần lái. 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 cuối cùng chứa các định nghĩa thao tác. Phần trên cùng thể hiên tên lớp. thông điệp được truyền giữa hai đối tượng là một chiều.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. 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. Các thông điệp được khởi tạo ở phía client.

14 Lớp là một loại đối tượng đặc biệt. Xác định lớp dựa trên khái niệm về danh sách lớp.2. Nó là một tập hợp các đối tượng đã được tạo. 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. Nó được dùng để tạo và huỷ các đối tượng thuộc về nó. 2. . 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ừ.1. 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. 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.

Trong khi đó. Nói chung.  Một lớp là một nguyên mẫu của một đối tượng. 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. 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. 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. tồn tại trong hệ thống.5. mang tính khái niệm. Trong UML. 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ể.  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. có thực. nhưng ở những mức độ trừu tượng hoá khác nhau. 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. 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? . 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. Trong khi đó. Trong khi đó. 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. đối tượng là một thể hiện của lớp. 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. Sự tương tác lẫn nhau của lớp và đối tượng Lớp vàđối tượng. mặc dù có mối liên hệ tươngứng lẫn nhau. 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. đối tượng là một thực thể cụ thể tồn tại khi hệ thống đang hoạt động. 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. lớp là một khái niệm trừu tượng.4. trừu tượng. 2.15 2.  Đối tượng là một thực thể cụ thể. lớp là khái niệm tồn tại khi phát triển hệ thống.

Cuối cùng. và triển khai cũng dễ hơn. chức năng hoặc là độ tin cậy. 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 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. ngôn ngữ học. Khi chúng ta phân loại. 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. 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. 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. Phân loại giúp chúng ta cách xác định những lớp tổng quát. khó khăn trong việc triển khai và lập trình. 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. hoạt động không hiệu quả.2. 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. 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. Kinh nghiệm cho thấy rằng xác định bao gồm cả phát hiện và sáng tạo. tránh được việc trùng lặp công việc.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. 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. 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. Bằng việc nhận ra các tương tác chung giữa các đối tượng. Trong thiết kế hướng đối tượng. 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. 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 đó. Phân loại cũng đóng vai trò trong việc chỉ định các quy trình xử lý. 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 đề. Thông qua sáng tạo. Thông qua phát hiện. và sự phân cấp giữa các lớp với nhau. tùy thuộc vào việc đóng gói. phổ biến. 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. 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: . các nhà khoa học và cả các nhà toán học đặc biệt quan tâm. nhanh hơn.1. 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. 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. Không có một quy định chung nào để tìm ra được sự phân loại tốt nhất. 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. 3. 3.

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ư là các thuộc tính cần thiết và đủ để định nghĩa một loại”. Nhóm khái niệm. Nhóm khái niệm. 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.17 - Loại cổ điển. ”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? . 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ả. 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.

Relationships. Structural things: Structural things định nghĩa phần cố định của mô hình. nguyên tắc để kết nối giữa các khối Kỹ thuật chung của UML.2. UML là viết tắt của Unified Modeling Language. hình dung. Behavioral. 4.1. Things có thể là: Structural. 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. nhiệm vụ. 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++. Chúng thể hiện các phần từ vật lý và khái niệm. Grouping và Annotational. 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. UML không phải là ngôn ngữ lập trình.1. 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.1. 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.18 CHƢƠNG IV: PHÂN TÍCH VÀ THIẾT KẾ HƢỚNG ĐỐI TƢỢNG SỬ DỤNG UML 4. xây dựng. 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. Phần thứ 2 biểu diễn các thuộc tính của lớp. Diagrams. 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 . và tài liệu của một hệ thống phần mềm. Phần thứ 3 được dùng để mô tả các thao tác có thể được thực hiện.     Phần trên cùng biễu diễn tên lớp. 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. 4. Things Things là các khối quan trọng của UML.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. 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. Các khối của UML có thể được định nghĩa là: Things.

mô tả cái chung nhấ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. Được dùng để mô tả các chức năng.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. . Được biểu diễn bằng một hình tròn. Collaboration được biểu diễn bằng hình eclips nét đứt. Trong giao diện chưa có viết mã lệnh để thực thi. - Collaboration: định nghĩa sự tương tác lẫn nhau giữa các phần tử. 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.

- 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.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. Được dùng để miêu tả hành động hiện hành của hệ thống. bắt đầu một quy trình xử lý. - Kí hiệu bắt đầu: được dùng để khởi tạo. - Active class: có cấu tạo giống với class nhưng đường viền bên ngoài đậm hơn. . - Component: Mô tả phần vật lý của hệ thống.

Các sự kiện là những tác nhân bên ngoài chịu trách nhiệm thay đổi. Note là Annotational thing duy nhất. Chỉ có duy nhất một loại Grouping thing: Package. 4.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. Quan hệ Quan hệ giữa các phần tử cũng là một khối quan trọng của UML. chú thích.3. 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. Behavioral things: Behavioral thing gồm có các phần động của mô hình UML.1. 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. 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. riêng biệt. 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. . Node được biểu diễn bởi hình vuông với tên được ghi ở trong hình. Annotation things: có thể được định nghĩa như là một kĩ thuật để đánh dấu. 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. mô tả của cuác phần tử UML.

Deployment diagram. kiểm thử.4.5. Sequence diagram. UML bao gồm 9 lược đồ sau: Class diagram. Object diagram. Nó cũng mô tả các đối tượng liên kết với nhau như thế nào. Activity diagram. Nó mô tả quan hệ kế thừa của các đối tượng.1. UML Diagram Tất cả các phần tử. 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. Collaboration diagram. Kiểu quan hệ này tồn tại trong trường hợp interface. Biểu đồ UML là 1 phần quan trong trong toàn bộ quy trình. Có một số cách nhìn nhận sau đây: . nhà đầu tư. 4. phát triển.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. 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. Use case diagram. 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.1. Component diagram. Người dùng có thể là lập trình viên. Statechart diagram. 4. 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. 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. - 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.

. 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. Mỗi một phần tử và các quan hệ của nó phải rõ ràng.2. 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. Nó biểu diễn cái nhìn tĩnh của một ứng dụng. 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. Làm nền tảng cho biểu đồ thành phần và biểu đồ triển khai. cộng tác. UML cung cấp biểu đồ lớp. giao diện và các cộng tác. Class diagram Giới thiệu Biểu đồ lớp là một dạng biểu đồ tĩnh. - Process định nghĩa luồng của hệ thống. Lược đồ triển khai được sử dụng để hỗ trợ khía cạnh này. và giằng buộc. Các biểu đồ 4.1. chức năng của 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. 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. 4. Biểu đồ lớp biểu diễn một tập các lớp. 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. biểu đồ đối tướng để hỗ trợ cách thiết kế này. Sử dụng các phần tử giống như ở trong Design. 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. 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.2. Mô tả các trách nhiệm. 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. 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. 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.23 - Design của một hệ thống bao gồm các lớp. giao diện. Biểu đồ thành phần UML được dùng để hỗ trợ thực thi theo cách này. Biểu đồ lớp không chỉ được dùng cho việc mô tả bên ngoài. 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. kết hợp. Biểu đồ lớp được xem như là biểu đồ cấu trúc.

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. rối và khó triển khai. Thêm vào đó chúng có thêm các chức năng như là dispatch() và receive().2. Về cơ bản sơ đồ lớp và sơ đồ đối tượng là tương tự nhau. 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. 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. Các sơ đồ đối tượng biểu diễn một trường hợp của một sơ đồ lớp.2. - Sử dụng note khi được yêu cầu mô tả diện mạo của biểu đồ. 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.24 - Chỉ biểu diễn những thuộc tính đặc biệt của lớp. 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. 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. 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. 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). Hai lớp kế thừa có tất cả các thuộc tính của lớp Order. . 4.

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). Lựa chọn một số trường hợp tốt nhất.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ả. 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ể. Tiếp theo. Hiểu các hoạt động của đối tượng và quan hệ giữa chúng. Trước khi vẽ sơ đồ đối tượng chúng ta nên nhớ một số điều sau đây: . Điều đó ngụ ý nói rằ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. Để lấy được các hệ thống riêng biệt. 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. 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ể. Có nghĩa là sơ đồ đối tượng miêu tả sát với hệ thống thực hơn. Mục đích của sơ đồ đối tượng cũng giống như mục đích của sơ đồ lớp. Vì thế giải pháp để giải quyết vấn đề này là: Đầu tiê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. Sơ đồ đối tượng chứa các đối tượng. tại thời điểm đó sẽ có những đối tượng sau: Customer (Khách hàng). Khi có khách hàng tới đặt mua hàng. Liên kết trong sơ đồ đối tượng được dùng để kết nối các đối tượng. 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. 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. 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. Vẽ sơ đồ đối tƣợng nhƣ thế nào? Như chúng ta đã đề cập ở phần trước. 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. 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. 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. một sơ đồ lớp là một trường hợp của sơ đồ lớp. Hướng nhìn tĩnh một tương tác. số sơ đồ lớp được giới hạn. 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.

SpecialOrder. S2 và N1).26 - Order (Đơn đặt hàng). các tài liệu. 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. 4. 32 và 40) cho từng thời điểm theo dõi. 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. 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. NormalOrder. 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. 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 đó. Những sơ đồ này cũng được dùng để tạo các hệ thống có thể thực thi. Khách hàng có 3 đơn đặt hàng với các số lượng khác nhau (12.3. Mục đích của nó cũng khác với các sơ đồ khác. và O3). 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. Mục đích Sơ đồ thành phần là một loại sơ đồ đặc biệt trong UML. Vì vậy. 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.2. 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. Với các đơn đặt hàng có giá trị là 12. đố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ị. các tệp tin có thể thực thi tồn tại ở bên trong node. Vì thế những mục đích của sơ đồ thành phần có thể được tóm tắt như sau: . O2. 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. 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 thư viện. Sơ đồ thành phần có thể được miêu tả như là sự thi hành tĩnh của hệ thống.

Vì thế sơ đồ biểu diễn các tệp tin trong ứng dung và mối quan hệ giữa chúng. Các phần này có thể là tệp tin. Sơ đồ thành phần được sử dụng trong suốt giai đoạn thi hành của ứng dụng. Quan hệ giữa các vật dụng. 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. 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. Trong thực tế sơ đồ thành phần chứa dlls. Sau khi xác định các dụng cụ. Sử dụng node để ghi chú những điểm quan trọng. 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. 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. 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. . 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ả. 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ụ. 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. Ban đầu. các thư viện. ở đây dụng cụ là các tệp tin. vật dụng. 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.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. thư viện…Vì thế mục đích của sơ đồ này có khác. Mô tả cách tổ chức và quan hệ giữa các thành phần. file thực thi.

2. Sơ đồ triển khai được sử dụng bởi các kĩ sư hệ thống. 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. 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ơ đồ 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. 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. 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. Mục đích Từ triển khai bản thân nó cũng mô tả được mục đích của sơ đồ. 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. Vì vậy.28 4. 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.4. Sơ đồ thành phần và sơ đồ triển khai có quan hệ chặt chẽ với nhau. Sơ đồ triển khai bao gồm các node và các mối quan hệ giữa chúng. Miêu tả quá trình thực thi. 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? .

Chúng ta xác định các nút sau: Màn hình. Nó liên quan tới sơ đồ thành phần. 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.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. 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. 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. 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 2. . 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. server 3.

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. 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 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. Chức năng được biểu diễn như một use case. 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ố đó. Những yêu cầu này phần lớn là yêu cầu thiết kế.5. Một sơ đồ use case biểu thị một chức năng riêng biệt của hệ thống. điều quan trọng là phải xử lý và theo dõi được những hành vi động. 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. use case và các mối quan hệ giữa chúng. Chọn tên sao cho có thể xác định được chức năng được thực hiện. Tên của use case rất quan trọng. Khi vẽ sơ đồ use case chúng ta cần chú ý một số điểm sau: . các tác nhân có thể là người dùng.2. các ứng dụng bên trong khác. Xác định các yếu tố bên trong và bên ngoài ảnh hưởng tới hệ thống. Chỉ ra các mối quan hệ và độc lập trong sơ đồ. 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. 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ơ đồ 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. Sử dụng note khi yêu cầu làm rõ một vấn đề quan trọng nào đó. Quan hệ giữa các use case và tác nhân. Vì thế sơ đồ use case bao gồm các actors. hoặc các ứng dụng bên ngoài. 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. Chỉ ra tương tác giữa các yêu cầu và các tác nhân.30 4. 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ớ. Được sử dụng để có cái nhìn khách quan từ bên ngoài của hệ thống. Sơ đồ Use Case Để xây dựng một hệ thống. 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. vì vậy. Vì vậy khi vẽ sơ đồ use case ta cần xác định một số phần tử sau. Các tác nhân. Trong sơ đồ tác nhân.

31 Tiếp theo ví dụ trên. 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. Trong ví này ta xác định được 3 use cases (Order. Hình dung các hành vi tương tác là công việc khó. 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. .6. SpecialOrder và NormalOrder use cases được suy ra từ Order use cases. Vì vậy tương tác là một phần của hành vi động của hệ thống. Một điểm quan trọng khác là để xác định ranh giới của hệ thống. NormalOrder) và một tác nhân đó là Customer. 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ụ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. Để mô tả luồng thông báo trong hệ thống. SpecialOrder. 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. 4. Mô tả sự tương tác giữa các đối tượng. Đó 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. Vi vậy chúng có quan hệ mở rộng với nhau. 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. Để mô tả cấu trúc tổ chức của các đối tượng.2. 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. ta vẽ sơ đồ use case để thể hiện hệ thống quản lý đơn đặt hàng.

Sơ đồ cộng tác: Biểu đồ này biểu diễn cách tổ chức các đối tượng . Một là sơ đồ trình tự và cái khác là sơ đồ cộng tác. Các luồng thông báo giữa các đối tượng. Chúng ta có 2 loại sơ đồ tương tác trong UML. Trình tự trong đó các thông báo được truyền đi. Sơ đồ trình tự: Đối với sơ đồ trình tự sẽ có 4 đối tượng cần quan tâm (Customer. SpecialOrder và NormalOrder). Đối tượng sẽ gửi một lệnh xác nhận confirm() tới SpecialOrder. Đối tượng SpecialOrder sẽ gửi một lệnh Dispatch() tới chính nó. Đầu tiên.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. 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. Tổ chức đối tượng. 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. 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. Order. 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. Sơ đồ vẽ đầu tiên là sơ đồ trình tự và thứ 2 là sơ đồ cộng tá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 . 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. 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. 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. 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. Và những trạng thái này được thay đổi bởi các sự kiệ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. đố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. 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. cụ thể đối với một thành phần. đố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. 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. 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. 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. 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ó. Tóm lại.2.7. Vì vậy. Để xây dựng vòng đời của một hệ thống tương tác.33 4. 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ó. Đị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.

Vì vậy điều khiển luồng được vẽ từ môt thao tác tới thao tác khác.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. 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. 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. chính xác. Sơ đồ trạng thái của đối tượng Order được mô tả như hình dưới đây: 4. 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. confirm request. Ví dụ dưới đây mô tả sơ đồ trạng thái của đối tượng Order. 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. Nhận biết các sự kiện.8.2. 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. 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. 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. 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. 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. 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.

Sơ đồ dưới đây được vẽ với 4 hoạt động chính. Một hoạt động là một chức năng được thực hiện bởi 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. Liên kết. Phần tử chính của một sơ đồ hoạt động là hoạt động của bản thân nó. 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. 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.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. Mô tả chuỗi từ một hoạt động với một hoạt động khác. Xác nhận đơn Gửi đơn đặt hàng đi. Mô tả luồng song song. đ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. nhánh và đồng thời của hệ thống. Gửi đơn đặt hàng tới khách hà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. 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. Sau khi nhận được đơn đặt hàng. 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ận đơn đặt hàng. kết hợp Các điều kiện Các giàng buộc. Nhưng sơ đồ hoạt động không chính xác là một flow chart.

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)? .

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). Thiết lập giới hạn của 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. tùy theo cách thiết kế. cách viết mã nguồn và ngôn ngữ lập trình được dùng. . Phân tích và thiết kế: Biến đổi những yêu cầu trong thiết kế hệ thống. Thường khi một phần mềm được tạo thành. Tùy theo mức độ phức tạp của phần mềm làm ra. 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.2. 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.37 CHƢƠNG V: QUY TRÌNH PHÂN TÍCH VÀ THIẾT KẾ 5. đưa ra. 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). 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.2. 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. 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. Một cách cơ bản là để hướng dẫn tạo ra hệ thống. kết quả một hệ thống có thể thực thi. 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. các thuật toán và các mã giả). 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.1.1. 5. requirements capture). các lưu đồ. chẳng hạn người sử dụng. Đô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. 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. 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 đó. để 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. hoặc đặc tả yêu cầu (requirements specification). 5. kiểm tra và tích hợp hệ thống. Thi hành (Implementation): thi hành.

Hoạt động: Trong suốt giai đoạn Khởi đầu. đ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 đó. phục vụ và giám sát dự án cũng như quản lý rủi ro. 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. Quy trình vĩ mô theo thời gian – Mốc và giai đoạn a. đả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ụ). 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. 5. 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ế.2. 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. bao gồm: lên kế hoạch.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. 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ó.2. 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. . đạt được thỏa thuận với khách hàng trên những gì được xây dựng. Quản lý cấu hình và sự thay đổi: Xác định cấu hình các mục.

ả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. 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. xác định kiểu kiến trúc kĩ thuật và môi trường phát triển. 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. 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). Sản phẩm (Work Product): Trong suốt giai đoạn Elaboration. 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. xem xét. 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. chấp thuận. một danh sách rủi ro. 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. Sau đó nhóm triển khai thu thập những phản hồi của người dùng. Chuyển giao. Xây dựng (Construction) Mục đích: Xây dựng một kiến trúc ổn định. 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. 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. thiết lập phần nền tảng của kiến trúc.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ụ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. d. Sản phẩm: Trong suốt giai đoạn này. Hoạt động: Trong suốt giai đoạn chuyển tiếp. Hoạt động: Trong suốt giai đoạn xây dựng. các thuộc tính hành vi. Mốc (Milestone): Phạm vi được hiểu. Hoạt động: Giai đoạn Elaboration bao gồm việc quyết định đưa ra kiến trúc. 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ó. b. 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 ý. yêu cầu của người dùng cuối. 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. hiểu rõ sự ưu tiên của các yêu cầu liên quan. 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. sản phẩm được cung cấp tới người dùng cho việc đánh giá và kiểm đị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. triển khai phần cốt lõi. . đặc trưng.

Quy trình vĩ mô theo thời gian – Lặp đi lặp lại Trong quy trình vĩ mô. 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. phần lớn thời gian sẽ được sử dụng trên việc phân tích và thiết kế. Nếu quá trình lặp lại được thực hiện trong giai đoạn khởi đầu. Mốc: Hệ thống sẵn sàng cho việc triển khai. 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. 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. kiểm thử và triển khai trong quá trình vĩ mô. 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. Tất nhiên. 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. được thực hiện thông qua vòng đời của chương trình. . như là cấu hình và thay đổi quan lý. 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 đó. đối với một số disciplines. 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ô. tài liệu hỗ trợ. môi trường. 5.40 thiết lập cấu hình. Nếu quá trình lặp lại được thực hiện trong giai đoạn chi tiết. phần lớn thời gian sẽ được sử dụng trên việc xử lý các yêu cầu. cài đặt và hướng dẫn sử dụng. Quy trình vi mô: Quá trình phân tích và thiết kế Như hình mô tả dưới đây. quản lý dự án. 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. tài liệu hướng dẫn. 5.2. Tuy nhiên.3. 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.3. Đặ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.

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. 5. Mức độ trìu tƣợng. 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. 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. là phù hợp và có thể phục vụ tốt cho việc thiết kế. 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. . 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. Phân tích tập trung vào hành vi chứ không phải cấu tạo.1. 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. ở đâ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. Trong thiết kế. Trong phân tích. nó phụ thuộc vào phạm vi của hệ thống. Số mức không thể xác định. chính xác các yêu cầu của hệ thống. Việc phân tích được xem như là hoàn thành khi nó biểu diễn đúng đắn.3.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. khái niệm Trong quá trình vi mô. các giai đoạn phổ biến. 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. 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. trách nhiệm và sự cộng tác.

Đị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ử. 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. khám phá hoặc đề xuất các phần tử sẽ sử dụng. bao gồm cả việc miêu tả kĩ thuật chung.42 Các hành động Quá trình vi mô bao gồm một tập các hành động. 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ử. 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ế. Định nghĩa các mối quan hệ giữa các phần tử. hỗ trợ cho sự kết hợp các phần tử. chuẩn bị các phần tử cho mức độ trìu tượng tiếp theo. . 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.

Việc sử dụng lại cũng đóng vai trò quan trọng. hành vi và quan hệ của chúng. Từ góc nhìn của kiến trúc sư. 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. 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.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. 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. Trong thành phần thiết kế. Trong quá trình thiết kế kiến trúc. 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. 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. Trong thành phần phân tích. 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. 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ử đó. sự khác biệt đó là mức độ trìu tượng được đề cập. Trong suốt quá trình thiết kế chi tiết. Khi thực hiện phân tích kiến trúc. 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. các phần tử thiết kế và trách nhiệm 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. 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 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. 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ử. 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 đó. 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? . 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. 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ế. 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. Từ quan điểm của kĩ sư.

Monitor Traffic: Giám sát tất cả các tuyến xe lửa trong một vù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. Monitor Train Systems: Giám sát hệ thống xe lửa cho nhưng chức năng thích hợp. 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. 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. 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. tránh va chạm. 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. 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. 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. 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ộ. Track Train Location: Giám sát vị trí của các xe lửa. xung đột tuyến đường và ghi lại nhật ký. Hơn nữa. 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. 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ó. theo dõi vết tuyến đường. 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. Avoid Collision: Đưa ra biện pháp. 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. dự báo lỗi. Các chức năng liên quan bao gồm lập kế hoạch. đối với một hệ thống xe lửa cần phải được giám sát chặt chẽ. kế hoạch này vạch rõ các tuyến đường mà xe lửa sẽ đi qua. Từ những chức năng trên.1.44 CHƢƠNG VI: ÁP DỤNG PHÂN TÍCH BÀI TOÁN CỤ THỂ 6. giám sát giao thông. chúng ta có thể đưa ra 8 use cases sau: Route Train: Thiết lập một kế hoạch. 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. Thêm vào đó chúng ta . Vì vậy.

Đá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: Giám sát tình trạng hoạt động của xe lửa. Cung cấp một hệ thống hoạt động chính xác ở mức 99. Hỗ trợ tốc độ xe lửa lên tới 250 dặm/giờ. TrainEngineer. Navstar GPS: Cung cấp dịch vụ định vị dùng để theo dõi tàu hỏa. Maintainer: Giám sát tình trạng duy tri hệ thông 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. và Maintainer.99% Cung cấp các đầy đủ các chức năng. 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. 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. tương tác với thiết bị ngoài. Quay lại bài toán quản lý hệ thống đường xe lửa của chúng ta. Đáp ứng đầu vào trong vòng 10s. Cung cấp chính xác vận tốc của xe lửa. Navstar GPS. Những ràng buộc. Cung cấp vị trí chính xác của tàu trong vòng 10 yards. trách dư thừa. Bây giờ chúng ta đã có những yêu cầu của bài toán. . Các tác nhân đóng vai trò sau trong hệ thống. Ngoài ra hệ thống còn giao tiếp.

Vì vậy. 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. 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.46 6. Ứng dụng Web: Hệ thống theo dõi kì nghỉ Ngày nay. Yêu cầu: . 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ý. các nhà quản lý có ít thời gian gặp được công nhân. các đặc tính chủ yếu. 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. sự tự chủ và độc lập của công nhân ngày càng tăng. các đặc tả use case chính và các kiến trúc cần thiết. 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ý. đối với nhiều doanh nghiệp. các mô hình use case.2.

Employee: là người sử dụng hệ thống chủ yếu. . Cho phép quản lý phê duyệt. và thời gian nghỉ thương niên. chúng ta thấy có 4 tác nhân sau. 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.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ọ. Một nhân viên sử dụng hệ thống để quản lý thời gian nghỉ của họ. 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. nghỉ việc vì đau ốm. Sử dụng phần cứng hiện tại. 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. 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. 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. 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. Lưu giữ lại những bản ghi cho tất cả các giao dịch. 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. Được thực hiện.

Miêu tả Admin sao lưu dữ liệu. 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. - 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ơ. 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. trơn. Có thể quản lý thời gian gian nghỉ của một nhóm nhân viên. 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. 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. Manage Leave Categories: Override Leave Records: Back Up System Logs.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. Manage Locations: Miêu tả một Clerk quản lý các bản ghi như thế nào. . 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.

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

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 ý: . nộp lại đề sau khi thi Đề thi số: Ký duyệt đề: x x .Không sửa. xóa đề thi.

xóa đề thi. 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.

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. nộp lại đề sau khi thi Đề thi số: Ký duyệt đề: x x . 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.