Phân tích và thiết kế Hệ thống thông tin hướng đối tượng với UML
MỤC LỤC
ƯU ĐIỂM CỦA MÔ HÌNH HƯỚNG ĐỐI TƯỢNG
Trong ví dụ bán xe ô tô, mọi giai đoạn phân tích thiết kế và thực hiện đều xoay quanh các khái niệm như khách hàng, nhân viên bán hàng, xe ô tô, … Vì quá trình phát triển phần mềm đồng thời là quá trình cộng tác của khách hàng/người dùng, nhà phân tích, nhà thiết kế, nhà phát triển, chuyên gia lĩnh vực, chuyên gia kỹ thuật,. Giống như việc bạn có thể tái sử dụng các khối xây dựng (hay bản sao của nó ) trong một toà lâu đài, một ngôi nhà ở, một con tàu vũ trụ, bạn cũng có thể tái sử dụng các thành phần (đối tượng) căn bản trong các thiết kế hướng đối tượng cũng như code của một hệ thống kế toán, hệ thống kiểm kê, hoặc một hệ thống đặt hàng.
PHẦN CÂU HỎI
NGÔN NGỮ MÔ HÌNH HOÁ THỐNG NHẤT LÀ GÌ
Mô hình thường được mô tả trong ngôn ngữ trực quan, điều đó có nghĩa là đa phần các thông tin được thể hiện bằng các ký hiệu đồ họa và các kết nối giữa chúng, chỉ khi cần thiết một số thông tin mới được biểu diễn ở dạng văn bản; Theo đúng như câu ngạn ngữ. Đáp: Điểm khác nhau cơ bản giữa một phương pháp và một ngôn ngữ mô hình hoá là ngôn ngữ mô hình hoá không có một tiến trình (process) hay các câu lệnh (instruction) mô tả những công việc người sử dụng cần làm mà nó bao gồm các ký hiệu – những biểu tượng được dùng trong mô hình – và một tập các quy tắc chỉ cách sử dụng chúng.
KHÁI QUÁT VỀ UML
Các nhóm sử dụng nhiều loại biểu đồ UML khác nhau làm nền tảng cho công việc của mình: Thử nghiệm đơn vị sử dụng biểu đồ lớp (class diagram) và đặc tả lớp, thử nghiệm tích hợp thường sử dụng biểu đồ thành phần (component diagram) và biểu đồ cộng tác (collaboration diagram), và giai đoạn thử nghiệm hệ thống sử dụng biểu đồ Use case (use case diagram) để đảm bảo hệ thống có phương thức hoạt động đúng như đã được định nghĩa từ ban đầu trong các biểu đồ này. Ngoài ra, cho mục đích quan sát một chức năng sẽ được thiết kế như thế nào, công cụ này cũng phải tạo điều kiện dễ dàng cho bạn chuyển sang hướng nhìn Use case (để xem chức năng này được miêu tả như thế nào từ phía tác nhân), hoặc chuyển sang hướng nhìn triển khai (để xem chức năng này sẽ được phân bố ra sao trong cấu trúc vật lý - Nói một cách khác là nó có thể nằm trong máy tính nào).
Mô hình hóa USE CASE
- Để tạo nờn một lời mụ tả rừ ràng và nhất quỏn về việc hệ thống cần phải làm gỡ, làm sao để mô hình có thể được sử dụng nhất quán suốt toàn bộ quá trình phát triển, được sử dụng làm công cụ giao tiếp cho tất cả những người phát triển nên các yêu cầu này, và để tạo nên một nền tảng cho việc tạo nên các mô hình thiết kế cung cấp các chức năng được yêu cầu. Các nguyên tắc của UML cho việc thực hiện các Use Case là: Một Use Case sẽ được thực hiện trong một sự cộng tác (collaboration): Một sự cộng tác chỉ ra một giải pháp (phụ thuộc vào sự thực thi nội bộ) của một Use Case sử dụng các khái niệm lớp/đối tượng và mối quan hệ giữa chúng đối với nhau (gọi là ngữ cảnh – context của sự cộng tác) cũng như sự tương tác giữa chúng để đạt tới chức năng mong muốn (gọi là chuỗi tương tác của sự cộng tác).
MÔ HÌNH ĐỐI TƯỢNG
Khi các mô hình được xây dựng dựa trên các khái niệm lấy ra từ cuộc đời thực và dựa trên các khái niệm thuộc phạm vi vấn đề, hướng đối tượng sẽ là một phương pháp rất thích hợp bởi nền tảng của phương pháp hướng đối tượng là các lớp, đối tượng và mối quan hệ giữa chúng. Các vật dụng (artifact) trong một doanh nghiệp, những thông tin cần được lưu trữ, phân tích hoặc các vai trò mà một tác nhân đảm nhận trong một doanh nghiệp thường sẽ trở thành các lớp trong các hệ thống doanh nghiệp và hệ thống thông tin. Khi trình bày với người sử dụng, chúng có một ánh xạ 1-1 giữa với những thực thể liên quan tới người sử dụng như hóa đơn, sec, giấy đề nghị rút tiền, sổ tiết kiệm, thẻ rút tiền tự động, nhân viên thu ngân, nhân viên nhà băng, các phòng ban,….
REFINEMENT)
NÂNG CẤP Mễ HèNH QUA CÁC VềNG LẶP KẾ TIẾP
Cho tới thời điểm này, chúng ta đi qua các bước công việc phân tích căn bản và tạo nên phiên bản đầu tiên của mô hình đối tượng. Mô hình này cần phải được lấy làm mục tiêu cho các vòng lặp nâng cấp tiếp theo. Công việc nâng cấp có thể được thực hiện bằng cách đưa mô hình qua tất cả các giai đoạn phát triển mô hình đối tượng một lần nữa. Lần này, những kiến thức thu được trong vòng phát triển đầu sẽ tỏ ra rất hữu dụng. Khi nâng cấp mô hình cần chú ý đến các bước sau:. a) Nghiên cứu các lớp để tìm các thuộc tính và thủ tục không đồng dạng (dissimilar). Nếu có, xẻ lớp thành các thành phần để tạo tính đồng nhất (harmony) trong lớp. Ví dụ với một lớp đảm nhận hai vai trò khác nhau, hãy xẻ lớp thành các lớp kết quả với những thủ tục được xỏc định rừ ràng. b) Nếu phát hiện thấy một chức năng không hướng tới một lớp đích nào thì đó là triệu chứng thiếu lớp. Hãy bổ sung lớp thiếu và đưa thủ tục kể trên vào lớp đó. c) Khái quát hóa là còn chưa đủ độ nếu có các liên hệ trùng lặp (nhiều liên hệ cùng định nghĩa một quan hệ). Trong trường hợp này, cần tạo lớp cha để kết hợp các mối liên hệ đó. d) Nếu một vai trò mang một ý nghĩa đặc biệt quan trọng đối với hệ thống thì thường nó cần một lớp riêng. Một lựa chọn khác là biến liên hệ định nghĩa vai trò này thành một lớp liên hệ. e) Nếu một lớp thiếu cả thuộc tính lẫn thủ tục và / hoặc liên hệ thì rất có thể đây là một lớp không cần thiết. Hãy loại bỏ những lớp đó nếu có thể. f) Hãy rà sát toàn bộ hệ thống để tìm những vai trò giữa các lớp còn chưa được thể hiện. Nếu có, đây là triệu chứng thiếu liên hệ. g) Nếu có một liên hệ giữa các đối tượng nhưng lại chẳng được thủ tục nào sử dụng tới thì rất có thể đây là một liên hệ không cần thiết.
CHẤT LƯỢNG MÔ HÌNH
Trong vòng đầu của quy trình mô hình hóa đối tượng, hãy xác định các mối liên hệ căn bản và gạt ra ngoài các chi tiết, việc xem xét tới các số lượng thành phần tham gia (Cardinality) trong quan hệ được để dành cho giai đoạn sau; rất có thể là ở vòng thứ hai. Tích hợp có nghĩa là một nhóm các mô hình cùng chung mục đích và thể hiện cùng một thứ (mặc dù chúng có thể có nhiều hướng nhìn khác nhau, ví dụ như mô hình động, mô hình chức năng, mô hình tĩnh), thì chúng phải có khả năng được ráp lại với nhau mà không làm nảy sinh mâu thuẫn.
TểM TẮT VỀ Mễ HèNH ĐỐI TƯỢNG
Ngay cả khi cỏc mụ hỡnh của chỳng ta dễ dàng giao tiếp, cú một mục đớch rừ ràng, nắm bắt được những điểm trọng yếu trong phạm vi vấn đề và có thể được phối hợp với nhau, ta vẫn có thể gặp khó khăn nếu mô hình quá phức tạp. Nếu bản chất phạm vi vấn đề của chúng ta là phức tạp, hãy xẻ mô hình thành nhiều mô hình khác nhau (sử dụng các tiểu mô hình – tức là các gói) và cố gắng để qui trình này có thể kiểm soát được tình huống.
MÔ HÌNH ĐỘNG
- Biểu đồ trạng thái: miêu tả một đối tượng có thể có những trạng thái nào trong vòng đời của nó, ứng xử trong các trạng thái đó cũng như các sự kiện nào gây ra sự chuyển đổi trạng thái, ví dụ, một tờ hóa đơn có thể được trả tiền (trạng thái đã trả tiền) hoặc là chưa được trả tiền (trạng thái chưa trả tiền). Mặt khác, vẫn có một sự móc nối ngoài ý muốn của lớp cha đến với lớp con thông qua các thuộc tính mà chúng sử dụng chung, ví dụ chỉ nên xem xét biểu đồ trạng thái cho các tài khoản có kỳ hạn theo phương diện sự thay đổi của chính các thuộc tính của chúng, chứ không phải là thuộc tính của lớp cha.
