Phát triển các hệ thống hướng đối tượng

Bài giảng kỹ thuật lập trình Thầy Cường Học viên bưu chính viễn thông TP HCM

Chương 11

Phát triển các hệ thống hướng đối tượng

• Giới thiệu

• Các mô hình hướng-thủ tục

• Các công cụ phát triển hướng-thủ tục

• Mô hình hướng đối tượng

• Các ký hiệu và đồ thị hướng đối tượng

• Các bước phân tích hướng đối tượng

• Các bước thiết kế hướng đối tượng

• Cài đặt

• Mô hình mẫu

• Tóm tắt

I/ Giới thiệu

Các kỹ sư phần mềm đã dùng nhiều công cụ (tools), phương pháp (methods) và thủ

tục (procedures) khác nhau để thực hiện tiến trình phát triển phần mềm nhằm xây dựng các sản phẩm phần mềm chất lượng cao với hiệu suất ngày càng cải tiến

Các phương pháp cung cấp khái niệm “làm như thế nào” để xây dựng phần mềm

trong khi các công cụ cung ứng các hổ trợ tự động và bán tự động cho các phương

pháp Họ sử dụng mọi giai đoạn phát triển của tiến trình phát triển phần mềm, đó là, lập kế hoạch, phân tích, thiết kế, phát triển và bảo trì

Các thủ tục phát triển phần mềm tích hợp các phương pháp và các công cụ lại với nhau và làm cho sự phát triển các hệ thống phần mềm trở nên hợp lý và hợp thời (hình 11.1) Chúng cung cấp các nguyên tắc chỉ đạo như làm thế nào áp dụng các phương pháp và công cụ, làm thế nào để tiến hành phân phối ở mỗi giai đoạn, các điều khiển nào sẽ áp dụng, và những cột mốc nào được dùng để đánh giá sự phát triển

Procedures

Methods

Tools

Hình 11.1 Các thành tố phát triển phần mềm

Có một số mô hình phát triển phần mềm, mỗi mô hình bao gồm một tập hợp các phương pháp và công cụ khác nhau Việc lựa chọn một mô hình phụ thuộc vào bản chất của một ứng dụng, ngôn ngữ lập trình được dùng, những điều khiền và phân phối được yêu cầu

Sự phát triển một hệ thống hoàn chỉnh không những phụ thuộc vào những phương pháp và kỹ thuật thích hợp mà còn phụ thuộc các ràng buộc của những nhà phát triển vào các đối tượng của hệ thống Một hệ thống hoàn chỉnh phải là :

1 thoả mãn những yêu cầu của người dùng

2 trở nên dể hiểu đối với người dùng và người vận hành

3 trở nên dể thao tác

4 có giao diện tốt

5 dễ dàng chỉnh lý

6 có thể phát triển được

7 có những điều khiển bảo mật thích hợp chống lại sự lạm dụng dữ liệu

8 bắt lỗi và xử lý ngoại lệ thật hài lòng

9 phân phối sản phẩm theo đúng ngày giờ đã ấn định

Trong chương này chúng ta sẽ xem xét một vài cách tiếp cận truyền thống được ứng dụng rộng rãi trong phát triển phần mềm và thảo luận một vài ý tưởng hiện nay có thể áp dụng được vào phát triển phần mềm hướng đối tượng

II/ Các mô hình hướng-thủ tục

Hình 11.2 Chu kỳ sống phát triển phần mềm cổ điển

(mô hình “thác nước” nhúng được)

Phát triển phần mềm thường được mô tả bởi một bộ các trạng thái mô tả các tác vụ khác nhau bao gồm trong tiến trình phát triển Hình 11.2 minh hoạ chu kỳ sống phần mềm cổ điển được ứng dụng rộng rãi trong phát triển hướng-thủ tục (procedure-oriented)

Chu kỳ sống cổ điển dựa trên một mô hình cơ bản, thông thường là mô hình “thác nước” Mô hình này cố gắng làm rõ những hoạt động có thể nhận biết được trong một chuỗi các hành động, mỗi một trong số chúng phải hoàn tất trước khi hành động khác lại bắt đầu Các hoạt động bao gồm, xác định vấn đề, phân tích các yêu cầu, thiết kế, lập trình, kiểm nghiệm, và bảo trì Sự tinh chế hơn nữa cho mô hình này bao gồm các bước lặp quay lui những giai đoạn trước đó nhằm kết hợp chặt chẽ bất kỳ sự biến đổi nào hoặc các liên kết còn thiếu

Xác định vấn đề : Hành động này yêu cầu một định nghĩa chính xác về vấn đề trong những thuật ngữ đang dùng Một phát biểu rõ ràng của vấn đề là một quyết định cho sự thành công của sản phẩm Nó không chỉ giúp cho nhà phát triển mà còn giúp người sử dụng hiểu vần đề được tốt hơn

Phân tích các yêu cầu : Điều này bao trùm sự nghiên cứu chi tiết về những yêu cầu của cả người dùng lẫn sản phẩm Hành động này là một bước cơ bản có liên quan

đến “cái gì” (What) của hệ thống như là :

• Những đầu vào cho hệ thống là cái gì ?

• Các tiến trình yêu cầu cái gì ?

• Những đầu ra mong muốn sẽ là cái gì ?

• Những ràng buộc (constraints) là gì ?

Thiết kế : pha thiết kế giải quyết những quan niệm khác nhau của thiết kế hệ thống như cấu trúc dữ liệu, kiến trúc sản phẩm, và các thuật toán Pha này chuyển những

yêu cầu vào cách biểu diễn (representation) của sản phẩm Giai đoạn này trả lời câu hỏi “How”

Lập trình : Mã hoá có liên quan đến sự chuyển dịch bản thiết kế sang dạng có-thể-đọc-được Chi tiết hoá bản thiết kế, dễ dàng hơn đó là sự mã hoá và làm cho tính tin cậy của thiết kế được tốt hơn

mã-máy-Kiểm nghiệm : một bản mã lệnh được viết xong , cần phải kiểm nghiệm nghiêm ngặt giúp cho bản mã và kết quả được tốt nhất Sự kiểm nghiệm có thể là một vài modul

riêng lẽ hoặc có khi là toàn bộ hệ thống Nó yêu cầu một kế hoạch chi tiết như kiểm

tra cái gì, khi nào và làm như thế nào (what, when, how to test)

Bảo trì : sau khi sản phẩm đã được hoàn chỉnh, nó có thể phải chịu một vài thay đổi Điều này thường xảy ra theo yêu cầu của người dùng và của cả môi trường điều hành, hoặc một lỗi nào đó trong sản phẩm bị sót trong quá trình kiểm nghiệm Sự bảo trì bảo đảm rằng mọi thay đổi sẽ được kết hợp chặt chẽ bất cứ lúc nào thấy cần thiết

Mỗi pha của chu kỳ sống đều có mục đích và đầu ra Đầu ra của pha này sẽ là đầu vào của pha tiếp theo Bảng 11.1 sẽ chiû ra các kiểu của đầu ra

Pha Đầu ra (outputs)

Xác định vấn đề * Phiếu phát biểu của vấn đề

(why) * Tài liệu đề nghị của dự án

Phân tích * Tài liệu yêu cầu

(what) * Báo cáo khả thi

* Tài liệu đặc tả

* Tiêu chuẩn kiểm nghiệm được công nhận Thiết kế * Tài liệu thiết kế

(how) * Thiết kế các tình huống cho kiểm nghiệm

Mã hoá * Tài liệu mã hoá (chương trình)

(how) * Kế hoạch kiểm nghiệm

* Tài liệu cho người dùng Kiểm nghiệm * Các mã hoá đã được kiểm nghiệm

(what & how) * Các kết quả kiểm nghiệm

* Tài liệu cho hệ thống Bảo trì * Các phiếu nhật ký bảo trì

* Tài liệu các phiên bản

Bảng 11.1 Các đầu ra của chu kỳ sống phần mềm cổ điển

Chu kỳ sống phần mềm, được mô tả ở trên, thường được xem như kỹ thuật phân rã

chức năng (the functional decomposition), được biết rộïng rãi như cách tiếp cận từ trên xuống (top-down), hoặc theo modun (modular) Kỹ thuật phân rã chức năng dựa

trên sự thể hiện không gian vấn đề và nó chuyển sang không gian lời giải như là sự thông dịch một tập các hàm Các hàm được phân rã theo trình tự tăng dần, những

hàm đơn giản nhất sẽ được thực thi cuối cùng Hệ thống cuối cùng được xem như

một tập các hàm được tổ chức theo cấu trúc phân cấp top-down

Cũng có một vài thiếu sót trong cách tiếp cận top-down, tiếp cận phân rã chức năng

Chúng bao gồm :

1 Không cho phép những thay đổi tiến hoá trong phần mềm

2 Hệ thống được đặc trưng bởi một hàm đơn (a single function) ở đỉnh của cây

phân cấp nhưng không phải lúc nào cũng hoàn toàn đúng Trong nhiều

trường hợp thực tế các hệ thống không có hàm đơn ở đỉnh

3 Dữ liệu không được xem là đáng quan trọng

4 Nó không khuyến khích việc tái sử dụng mã lệnh đã có

III/ Các công cụ phát triển hướng-thủ tục

Các công cụ phát triển hiện nay có thể phân loại theo 3 thế hệ

Các công cụ thế hệ 1 được phát triển vào thập niên 60 và 70 được gọi là các công cụ truyền thống

Các công cụ thế hệ 2 được giới thiệu vào cuối thập niên 70 và đầu thập niên 80 dành

cho phân tích và thiết kế các hệ thống có cấu trúc và do đó chúng được biết như là các công cụ có cấu trúc

Các công cụ thế hệ 3 được giới thiệu vào cuối thập niên 80 cho đến nay dành cho

phân tích và thiết kế các hệ thống hướng đối tượng

Bảng 11.2 chỉ cho thấy một số công cụ thông dụng dành cho các tiến trình phát triển theo 3 chủng loại Phần này sẽ giới thiệu tổng quát một vài công cụ thường dùng ở thế hệ 1 và 2

representation Grid charts Object dictionary

Logic

processes

Playscript English narrative

Decision tables trees

Data flow diagrams

Inheritance graphs Data flow diagrams

State change diagrams Ptech diagrams

Coad/Yourdon charts

Bảng 11.2 Các công cụ phát triển hệ thống

!"Lưu đồ hệ thống (System flowcharts)

!"Lưu đồ chương trình (Program flowcharts)

!"Kịch bản từng giai đoạn (Playscripts)

!"Các khuôn dạng sơ bộ (Layout forms) cho việc nhập và xuất kết quả

!"Biểu đồ (Grid charts) biểu diễn mối quan hệ giữa các modun của hệ thống

!"Lược đồ ngữ cảnh (Context diagrams) biểu diễn đầu vào với tài nguyên của chúng và đầu ra với các đích của chúng

!"Lược đồ dòng dữ liệu (Data flow diagrams) biểu diễn dòng dữ liệu giữa các thành phần khác nhau của hệ thống

!"Từ điển dữ liệu (Data dictionary)

!"Biểu đồ cấu trúc (Structures chart) biểu diễn đồ thị các điều khiển logic giữa các modun của hệ thống

!"Bảng quyết định (Decision table) một bảng các tình huống bất ngờ dành cho việc xác định vấn đề và các hành động để thực hiện

!"Cây quyết định (Decision tree)

!"Lược đồ Warnier/Orr : một biểu đồ phân cấp hàng ngang sử dụng một tập các dấu móc, mã giả (pseudo-code) và các ký hiệu logic để chỉ các cấu trúc chương trình

IV/ Mô hình hướng-đối tượng

Mô hình hướng-đối tượng đặt nặng trên lý thuyết hệ thống tổng quát như là nền tảng

thuộc về khái niệm Một hệ thống có thể được xem như một sự tập hợp các thực thể

(entities), chúng tương tác với nhau nhằm đạt đến mục tiêu nào đó (hình 11.3)

Các thực thể có thể biểu diễn các đối tượng vật lý như các thiết bị hay con người, và các khái niệm trừu tượng như các file dữ liệu hoặc các hàm Trong phân tích hướng-

đối tượng các thực thể được gọi là các đối tượng (objects)

PROCESS

Hình 11.3 Một hệ thống với các quan hệ-bên trong của các thực thể

Theo như tên gọi, mô hình hướng-đối tượng đặt để tầm quan trọng nhất vào các đối tượng đó là tính đóng gói dữ liệu và hàm Chúng đóng vai trò trung tâm trong mọi giai đoạn của phát triển phần mềm và do đó sẽ tồn tại ở mức cao sự gối lên nhau

(overlap) và sự lặp đi lặp lại (iteration) giữa các giai đoạn Tiến trình phát triển toàn

thể trở thành sự tiến hoá như trong tự nhiên Bất kỳ một biểu diễn đồ hoạ nào của các phiên bản hướng-đối tượng của chu kỳ phát triển phần mềm đều phải lưu tâm đến hai khía cạnh gối lên nhau và và sự lặp đi lặp lại Kết quả là mô hình “vòi phun

nước” (fountain model) đã thay thế mô hình “thác nước cổ điển” (hình 11.4)

Entity Entity

Entity

Entity Entity

Maintenance Further development

Application

Object-oriented OOP Objects

programming in program

Object-oriented OOD Objects

design in solution space

Object-oriented OOA Objects

analysis in problem space

Hình 11.4 Mô hình “vòi phun nước” trong phát triển

phần mềm hướng-đối tượng

Phân tích hướng-đối tượng (OOA) có liên quan đến các phương pháp của các yêu cầu đặc tả của phần mềm theo thuật ngữ các đối tượng của thế giới thực, các hành vi ứng xử và các tương tác của chúng

Thiết kế hướng-đối tượng (OOD) chuyển những yêu cầu của phần mềm sang những đặc tả cho đối tượng và các lớp dẫn xuất phân cấp từ đó các đối tượng sẽ được tạo ra

Lập trình hướng-đối tượng (OOP) có liên quan đến cài đặt chương trình trong một ngôn ngữ lập trình hướng đối tượng như C++

Tương phản với cách tiếp cận phân rã chức năng top-down, tiếp cận hướng đối tượng sử dụng các thiết kế top-down lẫn bottom-up Kỹ thuật phân rã chức năng từ trên xuống có thể áp dụng để thiết kế các lớp riêng lẽ trong khi hệ thống cuối có thể được xây dựng với sự trợ giúp các modun lớp sử dụng tiếp cận từ dưới lên

Problem space Objects defined

in problem space during analysis

Hình 11.5 Các tầng của các đặc tả đối tượng

V/ Các ký hiệu và đồ thị hướng đối tượng

Các ký hiệu đồ hoạ (graphical notations) là phần không thể thiếu của bất kỳ quá

trình thiết kế và phát triển nào, thiết kế hướng đối tượng cũng vậy Chúng ta cần các ký hiệu để biểu diễn các lớp, các đối tượng, các lớp con, và mối quan hệ qua lại của chúng Thật không may, không có các ký hiệu chuẩn để biểu diễn các đối tượng và các tương tác ủua chúng Mỗi tác giả và các nhà nghiên cứu đều có cách ký hiệu riêng của mình Dưới đây là một số ký hiệu thông dụng , từ hình 11.6 đến 11.14

1 lớp và đối tượng

2 các thể hiện của đối tượng

3 message truyền thông giữa các đối tượng

4 quan hệ kế thừa

5 quan hệ phân loại

6 quan hệ hợp thành

7 biểu đồ phân cấp thứ bậc

8 quan hệ client-server

9 các tiến trình

Classname

Function 1

Functions Data Data

Functions

Hình 11.6 Các dạng khác nhau dùng biểu diễn lớp/đối tượng

data

(một tiến trình có thể có từ 5 đến 7 đối tượng tiêu biểu)

VI/ Các bước trong phân tích hướng đối tượng

Phân tích hướng đối tượng (OOA) cung cấp cho chúng ta một cơ chế đơn giản nhưhg

đầy sức mạnh để nhận biết các đối tượng, các khối xây dựng (the buiding blocks) của

phần mềm đã được phát triển

Việc phân tích có liên quan về cơ bản đến sự phân rã của vấn đề thành các bộ phận

cấu thành (component parts) của nó và thiết lập một mô hình logic nhằm mô tả các

chức năng của hệ thống

Tiếp cận phân tích hướng đối tượng gồm có các bước sau đây :

1 Hiểu và nắm vững vấn đề

2 Phác thảo những đặc tả yêu cầu của người dùng và của phần mềm

3 Nhận biết các đối tượng và các thuộc tính của chúng

4 Nhận biết các dịch vụ trong đó mỗi đối tượng được mong đợi cung cấp (giao

diện)

5 Thiết lập các quan hệ nối liền với nhau (cộng tác - collaborations) giữa các đối

tượng dưới dạng các dịch vụ được yêu cầu và các dịch vụ đáp lại (services

rendered)

Mặc dù, chúng ta đã chỉ ra các tác vụ như một tập các bước riêng lẻ, ba bước cuối được thực hiện phụ thuộc lẫn nhau như hình 11.15

Hình 11.15 Các hoạt động của phân tích hướng đối tượng

1/ Hiểu và nắm vững vấn đề (problem understanding)

Phát biểu vấn đề phải rõ ràng và xác định lại dưới dạng công nghệ hệ thống máy tính sao cho gợi ý ra những lời giải dựa trên máy tính Phát biểu vấn đề cung cấp cơ sở cho việc phác thảo đặc tả các yêu cầu của cả người dùng lẫn phần mềm

2/ Đặc tả các yêu cầu (requirements specification)

Một khi vấn đề được xác định rõ ràng, bước tiếp theo sẽ biết được điều gì hệ thống được yêu cầu thực hiện Điều quan trọng ở giai đoạn này là tạo cho được một danh sách các yêu cầu của người dùng Một sự hiểu biết thông suốt phải có giữa người

dùng và nhà phát triển (developer) với cái gì được yêu cầu Dựa trên những yêu cầu

của người dùng, các đặc tả cho phần mềm sẽ được phác thảo Nhà phát triển phải diễn đạt hết sức rõ ràng (what) :

• Các đầu ra (outputs) được yêu cầu là gì

• Các tiến trình nào được gọi để cho ra các đầu ra đó

• Những đầu vào (inputs) cần thiết đó là gì

• Những tài nguyên nào được yêu cầu

Những đặc tả này thường dùng như một tham khảo để kiểm nghiệm sản phẩm cuối nhằm thực thi các tác vụ mong đợi

3/ Nhận biết các đối tượng (Identication of objects)

Các đối tượng thường được nhận biết duới dạng các đối tượng thế giới thực hơn là các đối tượng trừu tượng Do đó, nơi tốt nhất để xem xét các đối tượng là ngay chính ứng dụng Ứng dụng có thể được phân tích bằng cách sử dụng một trong hai tiếp cận sau đây :

• Các lược đồ dòng dữ liệu (DFD – Data flow diagrams)

• Phân tích theo nguyên bản (TA – Textual analysis)

a/ Lược đồ dòng dữ liệu

Một ứng dụng có thể biểu diễn dưới dạng DFD chỉ cho thấy dữ liệu sẽ được lưu chuyển từ nơi này đến nơi khác trong hệ thống Các ký hiệu hộp (boxe) và khung lưu trữ dữ liệu (data store) trong DFD là những ứng viên tốt cho biểu diễn các đối tượng

Tiến trình nổi bọt “bubbles” sẽ tương ứng với các thủ tục Hình 11.16 minh hoạ một

lược đồ dòng dữ liệu điển hình Nó cũng được biết đến như một đồ thị dòng dữ liệu

(data flow graph) hoặc một biểu đồ nổi bọt (bubble chart)

Bookseller : nguời bán sách

Order : đơn đặt hàng

Process order : xử lý đơn đặt hàng

Shipping instructions : chỉ thị/lời chỉ dẫn về vận chuyển hàng bằøng đuờng thủy

Stores/ Warehouse : cửa hàng/ kho hàng

Check credit status : kiểm tra tình trạng của thẻ tín dụng

Shipment information : thông tin về việc gởi hàng lên tàu thủy

Shipping notice : lời báo trước/thời hạn về vận chuyển hàng bằøng đuờng thủy