Bài giảng phân tích và thiết kế hướng đối tượng bài giảng 1 TS đào nam anh

Giai đoạn của Chu trình phát triển phần mềm  Tập hợp yêu cầu Requirement capture  Phân tích yêu cầu Analysis  Thiết kế hệ thống System design  Thiết kế đối tượng Object design  Thự

PHÂN TÍCH VÀ THIẾT KẾ HƯỚNG ĐỐI TƯỢNG

OBJECT ORIENTED ANALYSIS AND DESIGN

DR DAO NAM ANH

Bài giảng 1:

Phương pháp hướng đối tượng và

quá trình phát triển hệ thống phần mềm

RESOURCE - REFERENCE

1 Ian Sommerville, Software Engineering, Ninth Edition, 2011

2 Bernd Bruegge & Allen H Dutoit Object-Oriented

Software Engineering: Using UML, Patterns, and Java,

Third Edition, Prentice Hall, 2010

3 Russell C Bjork, ATM Simulation Links, Gordon College

4 Hans-Erik Eriksson, Magnus Penker, Brian Lyons, David

Fado, UML 2 Toolkit, John Wiley & Sons Inc, 2003

5 Dương Kiều Hoa – Tôn Thất Hoà An, Phân tích và thiết kế

Hệ thống thông tin với UML, 2006

6 Đào Nam Anh, Giáo Trình Phân Tích Và Thiết Kế Hướng

Đối Tượng, Đại học Điện lực, 2013

2

CONTENT – NỘI DUNG

Phương pháp hướng đối tượng và quá trình phát triển hệ thống phần mềm

1 Giới thiệu về hệ thống phần mềm

2 Sự phát triển hệ thống

3 Các cách tiếp cận trong phát triển phần mềm

4 Quá trình phát triển phần mềm hợp nhất

Công nghệ phần mềm

1. Công việc lập mô hình (modeling)

Giải quyết sự phức tạp thông qua các mô hình, bằng cách tập trung vào các chi tiết có liên quan tại một thời điểm và

bỏ qua tất cả chi tiết khác

2. Việc giải quyết vấn đề (problem-solving)

Các mô hình được sử dụng để tìm ra một giải pháp có thể chấp nhận được

3. Việc thu thập kiến thức (knowledge acquisition)

Trong khi lập mô hình cho các ứng dụng và lĩnh vực liên

quan, kỹ sư phần mềm thu thập dữ liệu, tổ chức thành thông tin, và tổng hợp thành kiến thức

4 Hoạt động hướng hợp lý (rationale-driven)

Khi thu thập kiến ​​thức và đưa ra các quyết định về hệ thống,

kỹ sư phần mềm cũng cần phải hiểu bối cảnh thực hiện các quyết định, lý do đằng sau những quyết định này

4

Lập mô hình

 Mô hình là kết quả của sự trừu tượng, nhằm miêu tả

các thành phần cốt yếu của một vấn đề hay một cấu trúc phức tạp, qua việc lọc bớt các chi tiết không quan trọng

và làm cho vấn đề dễ hiểu hơn

 Lập mô hình rất có ích với các hệ thống quá lớn, phức

tạp, hoặc quá đắt để có thể trực tiếp trải nghiệm Lập mô hình cũng cho phép ta hình dung và hiểu hệ thống, cho

dù nó không còn tồn tại hoặc mới chỉ là ý tưởng

 Trong dự án có các khách hàng, chuyên gia của lĩnh vực liên quan, phân tích viên, người thiết kế Mô hình hoá

giúp mọi người trong dự án trao đổi, hiểu hệ thống Các

mô hình giúp hiểu các yêu cầu của hệ thống tốt hơn, tạo các thiết kế rõ ràng hơn và xây dựng các hệ thống có khả năng dễ bảo trì hơn

Mô hình lĩnh vực ứng dụng

 Mô tả những khía cạnh của hệ thống thực tế

có liên quan đến các vấn đề đang được xem xét

 Kỹ sư phần mềm cần phải hiểu môi trường trong đó hệ thống hoạt động

 Với hệ thống điều khiển giao thông đường

sắt, kỹ sư phần mềm cần biết các thủ tục báo hiệu tàu

 Với hệ thống giao dịch ngân hàng, kỹ sư

phần mềm cần phải biết các quy tắc giao

dịch ngân hàng

6

 Với những thách thức này, kỹ sư phần

mềm tìm hiểu và mô tả các khía cạnh

quan trọng của những hệ thống thay thế

Phương pháp hướng đối tượng kết hợp việc mô hình

 Lĩnh vực ứng dụng được mô hình hóa

bằng một tập các đối tượng và các liên

kết Sau đó sử dụng mô hình này để mô tả các hoạt động của hệ thống

 Lĩnh vực giải pháp cũng được mô hình

hóa bằng các đối tượng

8

Giải quyết vấn đề

Công nghệ chính là một hoạt động giải

quyết vấn đề (problem solving)

Thu thập Kiến thức

 Sai lầm phổ biến khi cho rằng việc thu

thập kiến thức (knowledge acquisition) là một tiến trình tuần tự Thực tế đó là một

tiến trình không tuần tự

 Việc bổ sung một đoạn mới của thông tin

có thể làm mất hiệu lực tất cả các

kiến ​​thức đã có từ trước

Thu thập Kiến thức

 Tránh sự tuần tự của mô hình thác nước

 Mô hình phát triển dựa trên rủi ro

(risk-based development)

 Mô hình phát triển dựa trên sự cố

Sự hợp lý

 Phát triển phần mềm hay gặp các hệ thống thay đổi liên tục Thay đổi hệ thống có thể

là việc khách hàng áp dụng thêm công

nghệ mới

 Việc bổ sung kiến ​​thức này được gọi là sự

hợp lý (rationale) của hệ thống

Sự phát triển hệ thống

 Trong quá trình phát triển hệ thống có sự

tham gia của nhiều người với các vai trò

khác nhau

 Quá trình phát triển được diễn ra trong

một chu kỳ

14

Vai trò

 Chu trình phát triển phần mềm (Software Development Life Cycle - SDLC) cần sự cộng tác của nhiều người với các nhiệm

vụ và lợi ích khác nhau: nhà phân tích

(Analyst), thiết kế viên (Designer), người phát triển (Developer) và người dùng

(User)

 Những người tham gia vào dự án như vậy

được xếp vào các vai trò (role) để thể hiện

các nhiệm vụ của mình trong dự án

Giai đoạn của Chu trình phát

triển phần mềm

 Tập hợp yêu cầu (Requirement capture)

 Phân tích yêu cầu (Analysis)

 Thiết kế hệ thống (System design)

 Thiết kế đối tượng (Object design)

 Thực hiện, triển khai (Implementation)

 Kiểm thử (Testing)

Giai đoạn của Chu trình phát

 Tác nhân đại diện cho các thực thể bên ngoài

tương tác với hệ thống Tác nhân bao gồm vai trò người dùng cuối, các máy tính khác mà hệ thống cần phải kết nối, và môi trường tương tác

 Use Case mô tả trình tự các các hành động có thể xảy ra giữa tác nhân và hệ thống cho một nhóm

các chức năng

18

Giai đoạn của Chu trình phát

bước tập hợp yêu cầu, thành một mô hình các đối

tượng (object model) mô tả toàn bộ hệ thống

ràng và thiếu nhất quán ở các Use Case, họ sẽ thảo

luận với khách hàng để làm rõ

(system model) với các diễn giải các thuộc tính, hoạt động, và các liên kết

Giai đoạn của Chu trình phát

phần cứng / phần mềm, chiến lược quản lý dữ

liệu, kiểm soát luồng thông tin, chính sách kiểm

soát truy cập, và xử lý các điều kiện biên

 Kết quả của việc thiết kế hệ thống là một mô tả rõ ràng của từng chiến lược này, hệ thống phân rã, và biểu đồ triển khai thể hiện quan hệ phần cứng /

phần mềm của hệ thống

20

Giai đoạn của Chu trình phát

triển phần mềm

Thiết kế đối tượng

 Thiết kế viên xác định các đối tượng trong lĩnh

vực giải pháp

 Bước này khai báo các đối tượng, giao diện giữa các hệ thống con, cơ cấu lại mô hình đối tượng để đạt các mục tiêu thiết kế như khả năng mở rộng hệ thống hoặc dễ hiểu, và tối ưu hóa mô hình đối

tượng để tăng tốc độ thực hiện

 Kết quả của các bước này là một mô hình đối

tượng chi tiết với mô tả chính xác cho từng phần

tử

21

Giai đoạn của Chu trình phát

triển phần mềm

Xây dựng

 Trong quá trình triển khai lập trình, lập

trình viên viết mã theo mô hình lĩnh vực

giải pháp

 Lập trình viên cũng có trách nhiệm viết tài liệu liên quan đến chương trình, chú giải các thủ tục (procedure) trong chương

trình

22

Giai đoạn của Chu trình phát

triển phần mềm

Kiểm thử

 Để đảm bảo chương trình được viết phải thoả mãn mọi yêu cầu đã nêu trong các tài liệu thiết kế

 Người kiểm thử tìm thấy sự khác biệt giữa hệ thống và mô

hình thiết kế của nó bằng cách chạy hệ thống với các bộ dữ liệu đầu vào

 Kiểm thử đơn vị (unit test), lập trình viên đối chiếu chương trình với từng đối tượng và hệ thống con trong mô hình thiết

kế đối tượng

 Kiểm thử kết nối (integration test), các hệ thống con được

tích hợp với nhau và so sánh với các mô hình thiết kế hệ

thống

 Kiểm thử hệ thống (system testing), các trường hợp điển hình

và ngoại lệ được chạy qua hệ thống và so sánh với mô hình yêu cầu

Các cách tiếp cận trong phát triển phần mềm

Có nhiều chiến lược và kỹ thuật để phát

triển phần mềm:

 Phát triển hướng chức năng,

 Kỹ nghệ thông tin,

 Tạo mẫu và

 Phát triển hướng đối tượng

Những chiến lược này có thể được kết hợp,

bổ sung cho nhau trong thực tế

24

Các cách tiếp cận trong phát triển phần mềm

Phát triển phần mềm hướng chức năng

 Là một trong những phương pháp chính

được áp dụng rộng rãi cho các hệ thống

thông tin và các ứng dụng máy tính

 Đó là phương pháp lấy QUI TRÌNH làm trung tâm, được sử dụng để mô hình các

yêu cầu nghiệp vụ cho một hệ thống

Các cách tiếp cận trong phát triển phần mềm

Phát triển phần mềm hướng chức năng

 Đó là phương pháp lấy QUI TRÌNH làm trung tâm, được sử dụng để mô hình các

yêu cầu nghiệp vụ cho một hệ thống

26 http://blog.hammerandco.com/metrics-for-engineering-services/

Các cách tiếp cận trong phát triển phần mềm

Phát triển phần mềm hướng chức năng

 Phương pháp này luôn coi qui trình làm

trung tâm, xây dựng các khối QUI TRÌNH (process block) cho hệ thống thông tin

Phương pháp này cũng xây khối DỮ

LIỆU (data block) có tầm quan trọng thứ hai

Các cách tiếp cận trong phát triển phần mềm

Phát triển phần mềm hướng chức năng

 Phương pháp phân tích cấu trúc hiện đại có chiến lược đơn giản

 Các nhà phân tích vẽ các mô hình qui trình, được gọi là Mô hình dòng dữ liệu (data flow diagrams), mô tả các qui trình cần thiết của một hệ thống, kèm theo các yếu tố đầu vào, đầu ra, và các tập tin

 Bởi vì những hình vẽ thể hiện các yêu cầu

nghiệp vụ của hệ thống về mặt logic, độc lập với các giải pháp vật lý, nên các mô hình này được gọi là thiết kế logic của hệ thống

28

Các cách tiếp cận trong phát triển phần mềm

Phát triển phần mềm hướng đối tượng

 Biểu diễn các đối tượng ngoài đời thực

bằng các đối tượng trong các mô hình

 Chia ứng dụng thành các thành phần nhỏ tương đối độc lập với nhau, gọi là các đối tượng

 Sau đó ta có thể xây dựng ứng dụng bằng cách sắp xếp các đối tượng đó lại với

nhau

Các cách tiếp cận trong phát triển phần mềm

Phát triển phần mềm hướng đối tượng

 Ưu điểm: tính tái sử dụng hoặc khả năng

điều chỉnh phù hợp các đối tượng cho việc

độ thiết kế và phát triển phần mềm

30

Các cách tiếp cận trong phát triển phần mềm

Phát triển phần mềm hướng đối tượng

 Trong phương pháp phát triển phần mềm

hướng đối tượng có khả năng kết hợp các

đối tượng trong một nghiệp vụ tính toán

hữu ích Ví dụ các giao diện ứng dụng có thể được dựa trên các đối tượng đồ hoạ từ thư viện đồ họa có sẵn

Các cách tiếp cận trong phát triển phần mềm

Phân tích hướng đối tượng (Object-Oriented

Analysis – OOA)

 Dữ liệu và các qui trình thao tác trên dữ liệu đó

được kết hợp hoặc đóng gói vào đối tượng

 Với một vấn đề, nhà phân tích cần ánh xạ các đối tượng hay thực thể có thực như khách hàng, người bán hàng, mô hình thiết kế để tạo ra được bản

thiết kế gần cận với tình huống thực

 Mô hình thiết kế sẽ có các thực thể của một vấn

đề thực và giữ nguyên các mẫu hình về cấu trúc, quan hệ cũng như hành vi của chúng



32

Các cách tiếp cận trong phát triển phần mềm

Thiết kế hướng đối tượng (Object Oriented Design -

OOD) là tổ chức chương trình thành các tập hợp đối

tượng cộng tác, mỗi đối tượng trong đó là thực thể của một lớp

quan hệ thừa kế

những quy định phi chức năng, những yêu cầu về môi trường, những yêu cầu về khả năng thực thi

tối ưu hóa giải pháp đã được cung cấp trong khi vẫn đảm bảo thỏa mãn các yêu cầu đã được định trước đây

Các cách tiếp cận trong phát triển phần mềm

Lập trình hướng đối tượng (Object Oriented

Programming - OOP)

 Thực hiện thiết kế hướng đối tượng qua việc

sử dụng một ngôn ngữ lập trình có hỗ trợ các tính năng hướng đối tượng

 Ngôn ngữ hướng đối tượng thường được

nhắc tới là C++ và Java

 Kết quả của giai đoạn này là bộ code chạy

được, chỉ được đưa vào sử dụng sau khi đã

trải qua nhiều vòng kiểm thử khác nhau



34

Quá trình phát triển phần mềm

hợp nhất

Việc quản lý một dự án công nghệ phần mềm

Hoạt động quản lý tập trung vào việc lập kế hoạch dự

án, theo dõi tình trạng dự án, theo dõi thay đổi, và điều phối các nguồn lực để bàn giao sản phẩm chất lượng cao đứng thời hạn và trong phạm vi ngân sách

Hoạt động quản lý bao gồm

Quá trình phát triển phần mềm

hợp nhất

Trao đổi thông tin (Communication ) là hoạt động

quan trọng và tốn thời gian nhất trong công nghệ

phần mềm

 Hiểu lầm và thiếu thông tin thường dẫn đến lỗi và

sự chậm trễ, tạo nên sửa chữa tốn kém về sau

 Trao đổi thông tin bao gồm việc trao đổi các mô hình và các tài liệu về hệ thống và lĩnh vực dụng của hệ thống, báo cáo tình trạng của các sản phẩm

dự án, cung cấp thông tin phản hồi về chất lượng của các sản phẩm, thiết lập các vấn đề và đàm

phán các vấn đề, và thông báo các quyết định

36

Quá trình phát triển phần mềm

hợp nhất

Quản lý cấu hình phần mềm (Software

configuration management) là quá trình theo

dõi và kiểm soát những thay đổi trong các sản phẩm

 Các thay đổi tràn ngập trong quá trình phát

triển phần mềm Yêu cầu thay đổi khi khách hàng cần có các tính năng mới và khi các nhà phát triển giúp họ hiểu rõ hơn về lĩnh vực

ứng dụng Môi trường phần cứng / phần

mềm có thay đổi khi tổ chức áp dụng một

công nghệ mới

Quá trình phát triển phần mềm

hợp nhất

Quản lý cấu hình phần mềm

 Theo dõi các thay đổi Hệ thống được mô tả như

là một cấu hình các phần tử độc lập Sự tiến hóa của cấu hình được theo dõi như một tập hợp các phiên bản cấu hình Khi có thay đổi không tốt,

nhà phát triển có thể đặt lại hệ thống vào một cấu hình cũ có tình trạng ổn định trước đây

 Kiểm soát sự thay đổi Mọi thay đổi cần được

đánh giá và chấp thuận trước khi được thực hiện Điều này đảm bảo cho hệ thống phát triển theo

đúng mục tiêu dự án và hạn chế được số lượng

các lỗi hệ thống

38

Quá trình phát triển phần mềm

hợp nhất

Quản lý sự hợp lý

Với một quyết định, sự hợp lý của nó bao gồm các

vấn đề mà nó đề cập đến, các lựa chọn thay thế mà

các nhà phát triển xem xét

phát triển cần khi có thay đổi hệ thống Nếu một tiêu chuẩn thay đổi, các nhà phát triển có thể đánh giá lại tất cả các quyết định có sự phụ thuộc vào tiêu chuẩn này

đánh giá lại các lựa chọn dựa vào các tiêu chí đã có Nếu một quyết định cần xem xét lại, ta có thể xem lại các sự hợp lý để biện minh cho nó

Quá trình phát triển phần mềm

hợp nhất

Quản lý dự án (Project Management) không tạo ra

sản phẩm nào trong quá trình phát triển phần mềm

 Quản lý dự án bao gồm các hoạt động giám sát để đảm bảo tạo ra một hệ thống chất lượng cao, đúng thời gian và trong phạm vi ngân sách

 Điều này bao gồm việc quản lý kế hoạch và quản

lý ngân sách dự án trong quá trình đàm phán với khách hàng, thuê các nhà phát triển và tổ chức

thành các đội phát triển, theo dõi tình trạng của dự

án, và can thiệp khi có sai lệch

40

 Bảo trì phần mềm khác biệt với các hoạt

động phát triển khác vì nó hay có thay đổi và được thực hiện bởi một đội ngũ, khác với

nhóm phát triển ban đầu Khi các dự án công nghệ phần mềm có định hướng về sự thay

đổi (change driven), sự khác biệt giữa các

hoạt động xây dựng và các hoạt động bảo trì

sẽ lu mờ

42

DISCUSSION – CÂU HỎI

https://sites.google.com/site/daonamanhedu/teac

hing/objectorientedanalysisanddesign