Mẫu thiết kế và ứng dụng phát triển hệ thống thông tin quản lý xuất nhập và tồn kho trong hoạt động Logistics

Từ nhu cầu thực tiễn xã hội và đặc biệt là của Công ty TNHH Sungnam Knitting Mills, cùng với cơ sở khoa học của việc nghiên cứu ứng dụng các mô hình sử dụng lại vào quá trình thiết kế ph

Trang 1

- 1 –

Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên http://www.lrc-tnu.edu.vn

ĐẠI HỌC THÁI NGUYÊN TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN & TRUYỀN THÔNG

- -

Trần Thị Xuân Hương

MẪU THIẾT KẾ VÀ ỨNG DỤNG PHÁT TRIỂN HỆ THỐNG THÔNG TIN QUẢN LÝ XUẤT NHẬP VÀ TỒN KHO TRONG HOẠT

ĐỘNG LOGISTICS

Chuyên ngành : Khoa học máy tính

Luận văn thạc sĩ Khoa học máy tính

Trang 2

- 2 –

Thái Nguyên, 2012

MỞ ĐẦU

1 Cơ sở khoa học và thực tiễn của đề tài

Thiết kế phần mềm là một công đoạn quan trọng trong quy trình xây dựng và phát triển phần mềm, giai đoạn này quyết định rất lớn đến sự thành công hay thất bại của phần mềm Cũng như việc thiết kế phần mềm nói

chung, việc thiết kế phần mềm hướng đối tượng cần hướng tới việc sử dụng

lại nhằm giảm bớt chi phí thực hiện và tăng tính hiệu quả

Cùng với sự phát triển nền kinh tế theo hướng toàn cầu hóa, Logistics

ra đời và phát triển rất nhanh chóng và mang lại kết quả rất tốt đẹp ở nhiều nước trên thế giới

Từ nhu cầu thực tiễn xã hội và đặc biệt là của Công ty TNHH Sungnam Knitting Mills, cùng với cơ sở khoa học của việc nghiên cứu ứng dụng các

mô hình sử dụng lại vào quá trình thiết kế phần mềm, luận văn đã chọn đề

tài “Mẫu thiết kế và ứng dụng phát triển hệ thống thông tin quản lý xuất

nhập và tồn kho trong hoạt động logistics”

2 Đối tƣợng và phạm vi nghiên cứu

- Đối tượng nghiên cứu: Đề tài tập trung nghiên cứu về các mẫu thiết kế

và hệ thống kho trong hoạt động logistics

- Phạm vi nghiên cứu: Đề tài chỉ tập trung tìm hiểu các mẫu thiết kế trong kỹ nghệ hướng đối tượng và ứng dụng để phát triển hệ thống thông tin quản lý xuất nhập và tồn kho trong dây chuyền hoạt động logistics

3 Mục tiêu nghiên cứu của đề tài

- Tổng quan về các mẫu thiết kế trong kỹ nghệ hướng đối tượng

- Đặc tả các hoạt động của hệ thống kho trong dây chuyền logistics

Trang 3

- 3 –

- Thiết kế hệ thống quản lý kho liên quan đến việc xuất nhập và tồn kho trong dây chuyền hoạt động logistics dựa vào việc sử dụng lại các mẫu

- Xây dựng chương trình thử nghiệm quản lý xuất nhập và tồn kho

4 Những nội dung nghiên cứu chính

MỞ ĐẦU: Giới thiệu cơ sở khoa học và thực tiễn của đề tài, đối tượng và

phạm vi nghiên cứu của đề tài

CHƯƠNG 1: Tổng quan về mẫu thiết kế trong kỹ nghệ hướng đối tượng và

hoạt động logistics

Trong chương này trình bày mẫu thiết kế, phân tích và thiết kế hướng mẫu trong công nghệ hướng đối tượng và vai trò của logistics đối với doanh nghiệp, xu hướng phát triển của logistics và vai trò của mẫu thiết kế trong việc phát triển các hệ thống quản lý hoạt động logistics

CHƯƠNG 2: Một số vấn đề về ứng dụng các mẫu thiết kế trong quá trình

phát triển HTTT quản lý

Trong chương này trình bày về một số mẫu điển hình về hành vi, trình diễn, ứng dụng của các mẫu thiết kế vào các bài toán cụ thể

CHƯƠNG 3: Cài đặt ứng dụng bài toán xuất nhập và tồn kho

Trong chương này trình bày về bài toán xuất nhập và tồn kho trong hoạt động logistics, phạm vi của bài toán và ứng dụng mẫu thiết kế vào bài toán quản lý hoạt động logistics và cài đặt ứng dụng

KẾT LUẬN: Đánh giá kết quả

Trang 4

- 4 –

CHƯƠNG I TỔNG QUAN VỀ MẪU THIẾT KẾ TRONG KỸ NGHỆ HƯỚNG ĐỐI

TƯỢNG VÀ HOẠT ĐỘNG LOGISTICS

1.1 Mẫu thiết kế

Năm 1995, Erich Gamma, Richard Helm, Join Vlissides và Ralph Johnson (Gang of Four - GOF) đã công bố cuốn sách “Elements of reusable Object – Oriented Software” đánh dấu sự ra đời của “Mẫu thiết kế” Đây là một bước tiến vô cùng quan trọng đối với việc thiết kế phần mềm hướng đối tượng

Ý tưởng của mẫu phần mềm được phát triển rất đa dạng Kiến trúc sư Christopher Alexander trường đại học California ở Berkeley là người phát triển nền tảng của mẫu Từ “mẫu” đã gần như gắn liền với sự nghiệp hoạt động của giáo sư Giáo sư và nhóm nghiên cứu của ông đã mất khoảng hơn

20 năm để phát triển một cách tiếp cận tới các kiến trúc thông thường có sử dụng các mẫu Alexander đã giới thiệu hơn 250 mẫu với nhiều mức độ trừu tượng từ kiến trúc của một thành phố đến các thiết kế phòng Kiến trúc sư đã thành lập khung mẫu miêu tả cơ bản của một mẫu như một giải pháp của vấn

đề ở mức ngữ cảnh Ông đã phát triển một nguyên mẫu từ các mẫu dùng trong công việc của ông về kiến trúc

Kent Beck và Ward Cunningham đã rất say mê áp dụng ý tưởng của Alexander để phát triển các mẫu phần mềm Họ đã tập hợp các mẫu đầu tiên nói về đặt tả giao diện người dùng Kent tập trung vào các thành ngữ cho Smalltalk và Ward diễn đạt kinh nghiệm của mình bằng các hệ thống nghiệp

vụ (hệ thống kế toán)

Trang 5

- 5 –

Erich Gamma đã xuất bản ấn phẩm đầu tiên về vấn đề sử dụng các mẫu trong phát triền phần mềm năm 1991 Cuốn sách được viết ở Đức, nhưng cuốn sách này không được chú ý nhiều Bruce Anderson là một trong những nhà lãnh đạo trong cộng đồng mẫu Ông thành lập ngân hàng mẫu ở OOPSLA vào đầu những năm 1990 Jim Coplien miêu tả thành ngữ trên C++ trong quyển lập trình C++ tiên tiến Theo một cách nào đó, những thành ngữ này có liên quan tới ý tưởng của những giải pháp cung cấp tài liệu cho những vấn đề thường xuyên Một nhóm có tên là Hillside Group được hình thành nhằm khai thác sâu hơn những ý tưởng này và thúc đẩy sử dụng mẫu trong quá trình phát triển phần mềm Họ xây dựng mẫu nhằm dẫn dắt và hỗ trợ những thành viên mới trong cộng đồng mẫu Nhóm này được hình thành đầu tiên với tên PLOP vào năm 1994

Những kiến trúc cơ bản của quá trình phát triển mẫu được Gang of Four (GOF) xuất bản trong cuốn “Những mẫu thiết kế” Những phần tử của phần mềm hướng đối tượng đã được giới thiệu và được miêu tả dễ hiểu với mẫu thiết kế hướng đối tượng Erich Gamma, Richard Helm, Ralph Johnson

và John Vlissides là đại diện cho lĩnh vực phân loại những giải pháp thiết kế

và việc sử dụng thông thường dùng bên trong mẫu hướng đối tượng Họ xây dựng một tập hợp gồm 23 mẫu chia làm 3 phạm trù: theo hành vi, theo cấu trúc và theo tạo sinh

Peter Coad gần đây cũng nghiên cứu về các mẫu hướng đối tượng Trong đó, ông đã mô tả 7 loại mẫu cơ bản trong phân tích và thiết kế hướng đối tượng Ông làm việc dựa trên các mẫu, tức là nhờ vào việc phân tích một ứng dụng của miền đã được đưa ra và sử dụng công nghệ hướng đối tượng để xây dựng các ứng dụng Douglas Schmidt cũng là một người dẫn dắt những

Trang 6

- 6 –

người mới tham gia vào lĩnh vực dùng mẫu Ông là tác giả của rất nhiều mẫu trong lĩnh vực các hệ thống truyền thông và các ứng dụng phân tán

Douglas Schmidt đã làm việc trên mẫu về các ứng dụng cho vấn đề phát triển khung làm việc Ông đã tạo ra các yếu tố cơ bản của cấu trúc vào trong các siêu mẫu được sử dụng để phát triển các khung làm việc và điền địa chỉ Hot-Sport và Hooks/templates tiếp cận trong việc phát triển khung làm việc

Kiến trúc phần mềm hướng mẫu: Một hệ thống mẫu còn được gọi

“Gang of Four” hướng vào việc sử dụng các mẫu ở kiến trúc trong quá trình phát triển phần mềm Nhiều tác giả phân loại các mẫu phần mềm thành mẫu kiến trúc, mẫu thiết kế và thành ngữ Hầu hết sự đóng góp của họ được hướng

về khía cạnh mẫu kiến trúc Những quyển sách của họ cùng với những quyển sách của GOF đánh dấu điểm bắt đầu của những người mới trong cộng đồng mẫu

1.1.1 Khái niệm mẫu thiết kế

Mẫu thiết kế (Design pattern) là một cặp giải pháp/vấn đề được đặt tên

có thể áp dụng trong những ngữ cảnh mới và những hướng dẫn để áp dụng nó trong những tình huống mới như thế nào [5]

Mẫu thiết kế không đơn thuần là một bước nào đó trong các giai đoạn phát triển phần mềm mà nó đóng vai trò là sáng kiến để giải quyết một bài toán thông dụng nào đó Các giai đoạn phần mềm vẫn hoàn chỉnh mà không

có mẫu thiết kế, nhưng sự góp mặt của mẫu thiết kế sẽ giúp cho việc xác định bài toán cần giải quyết nhanh gọn hơn, từ đó đưa ra cách giải quyết hợp lý.[7] Mẫu thiết kế không chỉ được sử dụng để xác định bài toán và cách giải quyết mà còn được sử dụng nhằm cô lập các thay đổi trong mã nguồn, từ đó

Trang 7

- 7 –

làm cho hệ thống có khả năng tái sử dụng cao do mẫu thiết kế tuân thủ rất nghiêm ngặt các nguyên lý thiết kế hướng đối tượng [7]

Việc xác định thế nào là một mẫu thiết kế phụ thuộc vào cách nhìn nhận vấn đề của mỗi người Theo GOF, cách nhìn nhận phổ biến về các mẫu thiết

kế là coi chúng giống như các mô tả về các đối tượng phục vụ mục đích trao đổi thông tin trong quá trình thiết kế đã được hiệu chỉnh để giải quyết những yêu cầu thiết kế trong những trường hợp nhất định

1.2.2 Các thành phần của mẫu thiết kế

Mỗi mẫu thiết kế trước tiên mô tả một bài toán mà ta gặp nhiều lần, rồi

mô tả những yếu tố căn bản nhất để giải quyết bài toán theo cách mà ta có thể

áp dụng lại nhiều lần Dựa trên mô tả như trên về các mẫu thiết kế, ta thấy chúng bao gồm những thành phần cơ bản như sau:

 Tên mẫu (Design pattern name): là tên gọi qua đó ta có thể mô tả bài toán cần giải quyết, giải pháp thực hiện kết quả Việc đặt tên mẫu thiết kế cho phép mô tả các bài toán và giải pháp một cách ngắn gọn Tạo thành một ngôn ngữ trong cộng đồng những người thiết kế Ví dụ, khi nói đến mẫu thiết kế “Facade”, ta hình dung ngay đến mô hình thiết kế một đối tượng với vai trò “interface” của một tập các thành phần nhỏ

 Bài toán: Cho phép xác định trong trường hợp nào thì áp dụng mẫu thiết

kế thông qua mô tả bài toán và ngữ cảnh của bài toán đó

 Giải pháp giải quyết bài toán: Mô tả những thành phần tạo nên mẫu thiết

kế (các lớp, các đối tượng) cùng mối quan hệ, vai trò và cách thức phối hợp giữa chúng (cấu trúc, thừa kế) Giải pháp không đề cập đến cách thức thiết kế hay thực hiện cụ thể nào vì nó được áp dụng trong rất nhiều tình huống khác nhau Thay vào đó, giải pháp của mẫu thiết kế được mô tả với tính khái quát cao với cách thức tổ chức chung nhất của các thành phần

Trang 8

- 8 –

trong việc giải quyết bài toán Ví dụ như mẫu thiết kế được gọi như một thành ngữ (mẫu GRASP), mẫu thiết kế có thể mô tả bằng lời hoặc mô hình thiết kế hay bằng mã nguồn

 Hệ quả: Là những gì thu nhận được cùng với những yếu tố cần cân nhắc khi áp dụng mẫu thiết kế để giải quyết bài toán Hệ quả thường không được đề cập khi nói đến một mẫu thiết kế nhưng đây là yếu tố quyết định khi cần chọn lựa hoặc phân tích chi phí và lợi ích khi áp dụng các mẫu thiết kế

1.2 Phân tích và thiết kế hướng mẫu trong công nghệ hướng đối tượng

Phân tích và thiết kế hướng mẫu (Pattern – Oriented Analysis and Design - POAD) là một cách tiếp cận kiến trúc cấu thành nhằm gắn kết các mẫu ở mức thiết kế Nó sử dụng các khái niệm của cấu trúc các mẫu thiết kế như là các thành phần thiết kế với các giao diện

Phân tích và thiết kế hướng mẫu dựa trên tiền đề là: tại một mức thiết

kế nào đó, người ta biết các mẫu có thể sử dụng được trong ứng dụng và nó thực sự không lấn át công việc của người thiết kế với những chi tiết của thiết

kế bên trong mỗi mẫu

1.2.1 Vai trò của mẫu trong phát triển phần mềm

Khi sự phức tạp của hệ thống phần mềm gia tăng, chúng ta tìm kiếm cách tiếp cận để làm đơn giản hóa sự phát triển của các ứng dụng phần mềm Các mẫu thiết kế hứa hẹn sớm đem lại lợi ích của việc tái sử dụng trong vòng đời phát triển Để có được lợi ích trong quá trình triển khai những giải pháp thiết kế đã được khẳng định này, chúng ta cần phải định nghĩa các kỹ thuật cấu thành thiết kế để xây dựng ứng dụng sử dụng các mẫu Những mô hình thiết kế linh hoạt cần phải được phát triển để hỗ trợ cho kỹ thuật này

Trang 9

- 9 –

Tái sử dụng phần mềm trong ứng dụng thực tế là một nhiệm vụ khó Nó thật sự quan trọng để giảm bớt công sức phát triển và đảm bảo chất lượng phần mềm cao hơn Các mẫu thiết kế có tác dụng thúc đẩy trong việc sử dụng lại các sản phẩm trong pha thiết kế, bởi vì chúng cung cấp một tập hợp các từ vựng thông thường cho thiết kế Chúng còn cung cấp một ngữ nghĩa giúp cho việc hiểu các thiết kế và chúng chỉ ra các khối xây dựng từ các ứng dụng phức tạp hơn đã được xây dựng Sự tập hợp từ nhiều danh mục mẫu sẵn có đã khuyến khích hình thành các ý tưởng xa hơn về việc làm sao để sử dụng những giải pháp có thể tin cậy được để phát triển các ứng dụng Các nhà nghiên cứu và thiết kế có kinh nghiệm đã mất nhiều công sức trong việc làm tài liệu có chất lượng cao trong thiết kế phần mềm như những mẫu thiết kế

1.2.2 Mục đích của việc phân tích thiết kế hướng mẫu

Khi yêu cầu về các hệ thống phần mềm tăng, các nhà nghiên cứu cũng như các nhà thực hành đã tìm kiếm các phương pháp luận và công nghệ để tự động hóa quá trình sản xuất phần mềm và làm thuận lợi quá trình bảo trì hệ thống Những công nghệ này xuất hiện gần đây bao gồm các mẫu thiết kế và các khung làm việc Trường hợp đặc biệt, trong cùng một khoảng thời gian chúng ta nhận thấy sự cần thiết của một phương pháp luận phát triển để phát triển các hệ thống phức tạp với qui mô lớn và học được kinh nghiệm của các nhà thiết kế hệ thống khác trong việc giải quyết các vấn đề lặp lại của thiết kế

Tài liệu của mẫu thiết kế miêu tả chi tiết về một mẫu như: cách dùng, cấu trúc, hành vi của những người tham gia, những phần tử và những nguyên tắc chỉ đạo cho việc triển khai Chúng ta hiểu lỗi là gì, làm sao để biên soạn những mẫu này để phát triển các ứng dụng Một hệ thống hoàn chỉnh không thể và cũng không bao giờ được xây dựng từ một mẫu đơn

Trang 10

- 10 –

Chúng ta có thể soạn các mẫu ở cùng một mức của lớp hoặc một mức của đối tượng Các mô hình lớp trình bày khía cạnh triển khai và bảo trì của một mẫu Trong khi các mô hình lớp trình bày khía cạnh triển khai và bảo trì của một mẫu Trong khi các mô hình đối tượng trình bày về sự thực hiện, hành vi và khía cạnh vai trò Các nhà nghiên cứu và các nhà thực thi quan tâm tới vấn đề kết hợp sử dụng vai trò các mẫu và mô hình nghiệp vụ Các vấn đề của soạn mẫu như các lớp thành phần ít được chú ý hơn

Mục đích của phân tích và thiết kế hướng mẫu là đẩy mạnh quá trình phát triển trên nền mẫu Chúng ta đang tìm kiếm những cách sao cho nhiều nhà thiết kế sử dụng nhiều các mẫu hơn Chúng ta muốn thu hút những nhà thiết kế mới để giúp họ sử dụng các mẫu một cách đơn giản theo từng tiến trình của họ Đẩy mạnh sự phát triển trên nền mẫu, chúng ta cần định nghĩa những cách tiếp cận cấu thành dễ sử dụng

Phát triển các cách tiếp cận có hệ thống để gắn kết các mẫu: một nhu cầu ngày càng cấp thiết là phát triển những cách tiếp cận các thành phần một cách hệ thống nhằm làm đơn giản hóa quá trình kết hợp các mẫu Các mô hình làm đơn giản quá trình kết hợp giữa các mẫu trong pha thiết kế phải được phát triển để hỗ trợ cho cách tiếp cận này

Cải thiện chất lượng thiết kế: Các mẫu thiết kế là những thiết kế có chất lượng tốt Việc sử dụng lại những mẫu trong một thiết kế được định trước để cải thiện chất lượng thiết kế của các ứng dụng phần mềm được xây dựng nhờ

sử dụng những mẫu như những khối hợp nhất cơ bản của họ

1.2.3 Những vấn đề thiết kế hướng mẫu

Để thúc đẩy sự phát triển của các mẫu cơ sở và xây dựng các cách tiếp cận mới để biên soạn các mẫu thì chúng ta còn phải đương đầu với rất nhiều thách thức

Trang 11

- 11 –

Cái gì là cơ sở để phân loại mẫu như một thành phần thiết kế? Để sử dụng các mẫu như là một khối hợp nhất chúng ta cần phải tìm ra các đặc trưng mà mẫu được phân loại như một thành phần thiết kế Làm sao chúng ta

có thể định nghĩa những giao diện mẫu cho mục đích hợp nhất với các mẫu khác Chúng ta có thể biên soạn những ứng dụng đơn độc từ các mẫu thiết kế? Nhiều ứng dụng sử dụng một hoặc nhiều mẫu trong thiết kế Thách thức ở đây

là liệu các ứng dụng có thể xây dựng bằng cách kết hợp các mẫu thiết kế không? Giao diện của các mẫu này như thế nào? Giao diện của các mẫu là gì?

và giao diện nào không thích ứng với những vấn đề có thể xuất hiện? Các loại mẫu gì được sử dụng? Chúng ta phát triển các ứng dụng có sử dụng các mẫu thiết kế một cách hệ thống như thế nào? Có tiến trình thiết kế tốt để phát triển các ứng dụng sử dụng các mẫu đã thiết kế như những khối hợp nhất không?

1.3 Phân loại mẫu thiết kế

Erich Gamma và các đồng sự của ông đề xuất 23 mẫu thiết kế và đã đưa ra hai tiêu chí để phân loại các mẫu thiết kế này Đó là phân loại theo mục đích sử dụng và phạm vi áp dụng của mẫu

1.3.1 Phân loại theo mục đích sử dụng

Các mẫu thiết kế được phân thành 3 nhóm: mẫu kiến tạo, mẫu cấu trúc, mẫu hành vi

 Mẫu kiến tạo (Creational Patterns): mẫu kiến tạo trừu tượng hóa quá trình khởi tạo đối tượng Các mẫu này giúp hệ thống không phải phụ thuộc vào cách một đối tượng được tạo ra, xây dựng và thể hiện

Mẫu thiết kế kiến tạo bao gồm các mẫu sau: Abstract Factory, Builder, Factory Method, Prototype, Singleton

 Mẫu cấu trúc (Structural Patterns): mẫu thiết kế cấu trúc đề cập đến cách

mà các đối tượng và lớp đối tượng kết hợp để tạo nên một cấu trúc lớn hơn

Trang 12

- 12 –

và hữu dụng hơn Việc thiết kế các lớp đối tượng là nhằm đáp ứng các ràng buộc cụ thể của hệ thống Mẫu cấu trúc mô tả mối quan hệ giữa các lớp này và sắp xếp sao cho nếu có bất kì sự thay đổi nào với hệ thống đều không làm thay đổi những quan hệ đó

Mẫu thiết kế cấu trúc bao gồm các mẫu sau: Adapter, Bridge, Composite, Decorator, Façade, Flyweight, Proxy

 Mẫu hành vi (Behavioral Patterns): mẫu hành vi mô tả sự tương tác giữa các đối tượng và cách chúng phân phối, cộng tác, để giải quyết một hay một nhóm trách nhiệm nào đó

Mẫu hành vi bao gồm các mẫu sau: Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor

1.3.2 Phân loại theo phạm vi sử dụng

Các mẫu thiết kế được chia làm 2 nhóm: Phạm vi được nói đến khi ta quyết định nên áp dụng mẫu thiết kế vào các lớp hay các đối tượng

 Mẫu thiết kế áp dụng cho lớp (Class): Các mẫu này mô tả và giải quyết mối quan hệ giữa các lớp đối tượng và lớp con của chúng Các mối quan

hệ này được thiết lập qua cơ chế kế thừa và chỉ xảy ra ở thời điểm biên dịch chương trình

Các mẫu thuộc loại này bao gồm: Factory Method, Adapter (Class), Interpreter, Template Method

 Mẫu thiết kế áp dụng cho đối tượng (Object): Các mẫu này mô tả và giải quyết mối quan hệ giữa các đối tượng Các mối quan hệ này có thể thay đổi tại thời điểm chạy chương trình

Các mẫu thuộc loại này bao gồm: Abstract Factory, Builder, Prototype, Singleton, Adapter (Object), Bridge, Composite, Decorator, Façade,

Trang 13

- 13 –

Flyweight, Proxy, Chain of Responsibility, Command, Iterator, Mediator, Memento, Observer, State, Strategy, Visitor

Trang 14

- 14 –

1.4 Sơ đồ mối quan hệ giữa các mẫu thiết kế

1.5 Tổng quan về Logistics

Hình 1.1: Sơ đồ mối quan hệ giữa các mẫuthiết kế

Trang 15

vụ

Logistics được phát triển qua 3 giai đoạn:

* Giai đoạn 1: Phân phối vật chất

Vào những năm 60, 70 của thế kỷ 20, người ta đã bắt đầu quan tâm đến vấn đề quản lý một cách có hệ thống những hoạt động có liên quan với nhau như vận tải, phân phối, bảo quản hàng hóa, quản lý tồn kho, bao bì đóng gói, phân loại,… để đảm bảo phân phối sản phẩm, hàng hóa cho khách hàng một cách có hiệu quả Những hoạt động đó được gọi là phân phối sản phẩm vật chất hay còn có tên gọi là logistics đầu ra

* Giai đoạn 2: Hệ thống Logistic

Những năm 80, 90 của thế kỷ 20, các công ty tiến hành kết hợp quản lý

2 mặt: đầu vào(cung ứng vật tư) với đầu ra (phân phối sản phẩm) để tiết kiệm chi phí, tăng thêm hiệu quả của quá trình này, được gọi là hệ thống logistics

* Giai đoạn 3: Quản trị chuỗi cung ứng

Quản trị chuỗi cung ứng là một khái niệm mang tính chiến lược về quản trị chuỗi nối tiếp các hoạt động từ người cung cấp – đến người sản xuất – khách hàng tiêu dùng sản phẩm, Logistics phát triển quá nhanh chóng, trong nhiều ngành, nhiều lĩnh vực, ở nhiều nước Chính vì vậy, cho đến nay vẫn chưa có một khái niệm thống nhất về logistics

Trang 16

- 16 –

1.5.1 Khái niệm về logistics

Trong lĩnh vực sản xuất: logistics là cung ứng, là chuỗi hoạt động

nhằm đảm bảo nguyên nhiên vật liệu, máy móc, thiết bị, các dịch vụ cho hoạt động tổ chức doanh nghiệp được tiến hành liên tục, nhịp nhàng và có hiệu quả; bên cạnh đó còn tham gia vào quá trình phát triển sản phẩm mới

Dưới góc độ quản trị chuỗi cung ứng: logistics là quá trình tối ưu hóa

về vị trí lưu trữ và chu chuyển các tài nguyên/yếu tố đầu vào từ điểm xuất phát đầu tiên là nhà cung cấp, qua nhà sản xuất, người bán buôn, bán lẻ, đến tay người tiêu dùng cuối cùng, thông qua hàng loạt các hoạt động kinh doanh

Theo giáo sư Martin Christopher: “Logistics là quá trình quản trị chiến

lược thu mua, di chuyển và dự trữ nguyên liệu, bán thành phẩm, thành phẩm (và dòng thông tin tương ứng) trong một công ty và qua các kênh phân phối của công ty để tối đa hóa lợi nhuận hiện tại và tương lai thông qua việc hoàn tất các đơn hàng với chi phí thấp nhất”

Theo quan điểm “5 right” thì: “Logistics là quá trình cung cấp đúng

sản phẩm đến đúng vị trí, vào đúng thời điểm với điều kiện và chi phí phù hợp cho khách hàng tiêu dùng sản phẩm”

Theo nhóm tác giả của cuốn sách “Logistics– những vấn đề cơ bản” thì

logistics được định nghĩa như sau: “Logistics là quá trình tối ưu hóa về vị trí

và thời điểm, vận chuyển và dự trữ nguồn tài nguyên từ điểm đầu tiên của chuỗi cung ứng qua các khâu sản xuất phân phối cho đến tay người tiêu dùng cuối cùng, thông qua hàng loại các hoạt động kinh tế.”

1.5.2 Vai trò của logistics đối với các doanh nghiệp

Logistics giúp giải quyết cả đầu ra lẫn đầu vào của doanh nghiệp một cách hiệu quả

Trang 17

- 17 –

Logistics góp phần nâng cao hiệu quả quản lý, giảm thiểu chi phí nhằm nâng cao năng lực cạnh tranh của doanh nghiệp

Logistics còn góp phần giảm phí thông qua việc tiêu chuẩn hóa chứng

từ

Ngoài ra, logistics còn hỗ trợ đắc lực cho hoạt động marketing: Logistics đóng vai trò then chốt trong việc đưa sản phẩm đến đúng nơi cần đến, vào đúng thời điểm thích hợp

1.5.3 Xu hướng phát triển của logistics

Logistics đang phát triển theo 3 xu hướng chính sau:

- Xu hướng thứ nhất: ứng dụng công nghệ thông tin, thương mại điện tử ngày càng phổ biến và sâu rộng hơn trong các lĩnh vực của logistics như: hệ thống thông tin Quản trị chuỗi cung ứng toàn cầu, công nghệ nhận dạng bằng tần số Radio…

- Xu hướng thứ hai: phương pháp quản lý logistics kéo ngày càng phát triển mạnh mẽ và dần thay thế cho phương pháp logistics đẩy theo truyền thống

Phương pháp đẩy: là phương pháp tổ chức sản xuất theo dự báo nhu cầu thị trường Phương pháp này tạo ra hàng tồn kho và “đẩy” hàng ra thị trường để đáp ứng nhu cầu thực tế Ưu điểm của phương pháp này là đơn giản, dễ thực hiện, có nhiều thời gian để sản xuất, hạ giá thành sản phẩm nhờ phát huy tính kinh tế về quy mô và đường cong kinh nghiệm (là hiện tượng kỹ năng của người lao động tăng lên dẫn đến tăng năng suất lao động) Nhược điểm: tạo ra khối lượng hàng tồn lớn, chu kỳ sản xuất dài, chi phí dự trữ cao Phương pháp này đòi hỏi lượng vốn lưu động lớn, vòng quay chậm

Phương pháp kéo: hoạch định sản xuất dựa trên nhu cầu và đơn hàng thực tế của thị trường, có nghĩa là nhu cầu của khách hàng “kéo” hàng từ sản xuất về phía thị trường Ưu điểm: giảm thiểu khối lượng và chi phí hàng tồn

Trang 18

- 18 –

kho, rút ngắn chu trình sản xuất, nhờ đó giảm vốn lưu động, tăng vòng quay vốn, phản ứng nhanh và hiệu quả hơn với những thay đổi của thị trường Tuy nhiên, phương pháp này đòi hỏi phải có khả năng phản ứng nhanh trước những yêu cầu của thị trường, tổ chức linh hoạt, phải tổ chức và quản lý tốt hệ thống thông tin, chu trình sản xuất được quản lý chặt chẽ, khoa học, có khả năng đáp ứng được yêu cầu nghiêm ngặt về tiến độ, thời gian giao hàng,…

- Xu hương thứ ba: thuê dịch vụ logistics từ các công ty logistics chuyên nghiệp ngày càng phổ biến

Trên thế giới, logistics đã và đang phát triển mạnh mẽ Ở Việt Nam logistics đã bắt đầu được nhìn nhận như một công cụ “sắc bén” đem lại thành công cho các doanh nghiệp trong điều kiện hội nhập và chắc chắn logistics sẽ phát triển trong tương lai không xa

1.5.4 Vai trò của các mẫu thiết kế trong việc phát triển các hệ thống quản lý hoạt động logistics

Hệ thống quản lý có xu thế được phát triển với cường độ mạnh khi sử dụng các công nghệ kỹ thuật mới: ứng dụng công nghệ tiên tiến như sử dụng

kỹ nghệ hướng đối tượng, công cụ mô hình hóa UML và “mẫu” trong thiết kế cũng như ứng dụng công nghệ web để cập nhật và xử lý thông tin

Cũng nhờ vậy, việc thiết kế hệ thống dựa trên các nguyên tắc “hướng mẫu” nhằm bảo đảm trước hết có được một hệ thống quản lý chất lượng các hoạt động logistics, sau đó cho phép hệ thống dễ bảo trì, dễ mở rộng trong tương lai, đáp ứng được các yêu cầu phức tạp, có nhiều thay đổi và yêu cầu phát triển ngày càng cao của xã hội Hệ thống logistics được xây dựng trên cơ

sở như thế sẽ được áp dụng ngày càng rộng rãi trong các tổ chức và doanh nghiệp có kết nối mạng máy tính

Trang 19

- 19 –

Trang 20

- 20 –

CHƯƠNG II MỘT SỐ VẤN ĐỀ VỀ ỨNG DỤNG CÁC MẪU THIẾT KẾ TRONG

QUÁ TRÌNH PHÁT TRIỂN HTTT QUẢN LÝ

Không thể có một mẫu nào có thể vận dụng tốt cho mọi trường hợp Mỗi mẫu có những đặc thù riêng, có thể áp dụng trong quá trình phát triển một HTTT trong những ngữ cảnh cụ thể Việc làm rõ ý nghĩa, cấu trúc và phạm vi sử dụng của mỗi loại mẫu là rất quan trọng nhằm giúp các nhà thiết

kế hệ thống có được những quyết định đúng trong việc chọn lựa các mẫu thích hợp, hướng tới chất lượng quản lý các hoạt động sản xuất, kinh doanh, đặc biệt là các hoạt động logistics Dưới đây, chúng ta sẽ xét một số mẫu điển hình theo các phương diện nêu trên

2.1 Một số mẫu điển hình về hành vi, trình diễn và cấu trúc

2.1.1 Mẫu chế tạo trừu tượng (Abstract Factory Pattern)

Mẫu chế tạo trừu tượng cung cấp một giao diện có chức năng tạo ra một tập hợp các đối tượng liên quan hoặc phụ thuộc lẫn nhau mà không chỉ ra

đó là những lớp cụ thể nào tại thời điểm thiết kế

Về bản chất, mẫu chế tạo trừu tượng chỉ khác mẫu chế tạo ở chỗ bản thân đối tượng Factory không được chỉ ra cụ thể tại thời điểm thiết kế Nó là một giao diện hoặc lớp trừu tượng (Interface, abstract) Nếu như mẫu chế tạo phân loại đối tượng dựa trên tham số đầu vào thì đối với mẫu chế tạo trừu tượng, thủ tục createObject() còn phụ thuộc vào các yếu tố phụ khác như môi trường hệ điều hành Ứng với mỗi yếu tố phụ thứ hai ta có một lớp Factory cụ thể

Trang 21

- 21 –

* Cấu trúc của mẫu

Trong đó:

 AbstractFactory: là lớp trừu tượng, tạo ra các đối tượng thuộc 2 lớp trừu

tượng là: AbstractProductA và AbstractProductB

 ConcreteFactoryX: là lớp kế thừa từ AbstractFatory, lớp này sẽ tạo ra

một đối tượng cụ thể

 AbstractProduct: là các lớp trừu tượng, các đối tượng cụ thể sẽ là các

thể hiện của các lớp dẫn xuất từ lớp này

* Phạm vi ứng dụng mẫu

Hình 2.1 Cấu trúc của mẫuAbstract Factory

Trang 22

- 22 –

 Phía trình khách sẽ không phụ thuộc vào việc những sản phẩm được tạo

ra như thế nào

 Ứng dụng sẽ được cấu hình với một hoặc nhiều họ sản phẩm

 Các đối tượng cần phải được tạo ra như một tập hợp để có thể tương thích với nhau

 Chúng ta muốn cung cấp một tập các lớp và chúng ta muốn thể hiện các ràng buộc, các mối quan hệ giữa chúng mà không phải là các thực thi của chúng(interface)

* Nhận xét

Một trong những vấn đề gặp phải là khung giao diện Abstract Factory thường hay bị sửa đổi, ví dụ như bổ sung thủ tục chẳng hạn, khi đó các lớp cụ thể thực thi giao diện này phải được dịch và triển khai lại Để giảm nhẹ vấn đề này người ta thường thiết kế giao diện Abstract Factory một cách linh hoạt

2.1.2 Mẫu Builder Pattern

Phân tách những khởi tạo các thành phần của một đối tượng phức hợp,

để có thể cùng một khởi tạo mà có thể tạo nên nhiều định dạng khác khau Builder Pattern sử dụng để xây dựng sản phẩm phù hợp với các mô hình tổng hợp, mô hình cấu trúc

Hình 2.2 Cấu trúc của mẫu Builder

Trang 23

- 23 –

Trong đó:

 Director: là lớp điều khiển tạo ra một đối tượng Product

 Builder: là lớp trừu tượng cho phép tạo ra đối tượng Product từ các phương thức nhỏ khởi tạo từng thành phần của Product

 ConcreteBuilder: là lớp dẫn xuất của Builder, khởi tạo từng đối tượng cụ thể, lớp này sẽ khởi tạo đối tượng

 Áp dụng cho các lớp có cấu trúc bên trong phức tạp (đặc biệt là một biến

là một tập các đối tượng liên quan với nhau)

 Ứng dụng cho các lớp có các thuộc tính phụ thuộc vào các thuộc tính khác

 Sử dụng các đối tượng khác trong hệ thống mà có thể khó khởi tạo hoặc khởi tạo phức tạp

2.1.3 Mẫu chế tạo (Factory Method Pattern)

Mẫu chế tạo đóng vai trò như một “nhà xưởng” có nhiệm vụ trừu tượng hóa quá trình khởi tạo đối tượng cụ thể khi ứng dụng chạy Tại thời điểm thiết

kế, đối tượng được định nghĩa trừu tượng Các mẫu này giúp hệ thống không phải phụ thuộc vào cách một đối tượng được tạo ra, xây dựng và thể hiện

Hình 2.3 Cấu trúc của mẫu Factory

Trang 24

 Product: cũng là lớp trừu tượng

 ConcreteCteatorA và ConcreteCteatorB: là 2 lớp kế thừa từ lớp Creator để tạo ra các đối tượng riêng biệt

 ConcreteProductA và ConcreteProductB: là các lớp kế thừa từ lớp Product, các đối tượng của 2 lớp này sẽ do 2 lớp ConcreteCteatorA và ConcreteCteatorB tạo ra

Sử dụng tính chất kế thừa của mẫu để phân loại các đối tượng được tạo

ra

Sử dụng mối quan hệ kết hợp để tham chiếu tới đối tượng sẽ được tạo

ra Đối tượng được tạo ra sẽ trở thành một phần hay thuộc tính của lớp Factory Chúng ta thường gặp loại này trong mẫu chế tạo trừu tượng (Abstract Factory Pattern)

2.1.4 Mẫu nguyên mẫu (Prototype Pattern)

Giúp khởi tạo đối tượng bằng cách sao chép một đối tượng khác đã tồn tại

Trang 25

2.1.5 Mẫu đơn chiếc (Singleton Pattern)

Mẫu đơn chiếc đảm bảo một lớp chỉ có một thể hiện duy nhất được tạo

ra và đồng thời cung cấp một truy cập toàn cục đến đối tượng được tạo ra

Việc sử dụng mẫu đơn chiếc mang lại nhiều tiện ích: Quản lý việc truy cập tốt hơn; cho phép cải tiến các tác vụ và các thể hiện do mẫu có thể được

kế thừa và tùy biến lại thông qua một thể hiện của lớp con; quản lý số lượng thể hiện của một lớp, không nhất thiết chỉ có một thể hiện mà có số thể hiện xác định; khả chuyển hơn so với việc dùng một lớp có thuộc tính tĩnh, vì việc dùng lớp tĩnh chỉ có thể sử dụng một thể hiện duy nhất, còn mẫu đơn chiếc cho phép quản lý các thể hiện tốt hơn và tùy biến theo điều kiện cụ thể

Trang 26

Ứng dụng rõ nhất của mẫu đơn chiếc có thể thấy trong dịch vụ Web khi triệu gọi các đối tượng từ xa Ở đó đối tượng nằm trên server hoặc sẽ phục vụ chung cho

tất cả các ứng dụng khách (singleton) hoặc sẽ chỉ đáp ứng một ứng dụng khách riêng lẻ nào đó rồi tự bị phá hủy sau đó

* Nhận xét

Chúng ta xét trường hợp có nhiều đối tượng có cùng chung một số tính chất nào đó được tạo ra ứng với mỗi một yêu cầu từ các đối tượng khách (client) Lúc này độ phức tạp sẽ tăng lên và ứng dụng sẽ chiếm dụng nhiều vùng nhớ hơn Mẫu đơn chiếc là một giải pháp đặc biệt của mẫu chế tạo ở chỗ, đối tượng sinh ra là điểm truy cập toàn cục duy nhất đối với mọi chương trình gọi đến, hay nói một cách khác, tất cả các đối tượng khách gọi đến đều chia sẻ đối tượng được tạo ra

Trang 27

- 27 –

Hình 2.6 Cấu trúc của mẫu Adapter Pattern

2.1.6 Mẫu thích nghi (Adapter Pattern)

Mẫu thích nghi biến đổi giao diện của một lớp thành một giao diện khác mà các đối tượng client có thể hiểu được Lớp với giao diện được tạo ra gọi là Adapter Nguyên tắc cơ bản của mẫu thích nghi nằm ở chỗ, làm thế nào

để các lớp với giao diện không tương thích có thể làm việc được với nhau

Mẫu thích nghi không quản lý tập trung các đối tượng gần giống như mẫu chế tạo, mà kết nối với nhiều lớp không liên quan gì với nhau Ví dụ, lớp

A sau khi thực thi giao diện của nó và vẫn muốn bổ sung phương thức từ một lớp B nào đó, chúng ta có thể kết nối A với B thông qua hình thức kế thừa hoặc liên kết đối tượng như một thành phần Mẫu Adapter có một chút giống mẫu proxy ở chỗ đã tận dụng tối đa tính chất “ủy quyền”

Trang 28

- 28 –

 Adapter: thực thi từ Target và sử dụng đối tượng lớp Adaptee, Adapter có nhiệm vụ gắn kết Adaptee vào Target để có được chức năng mà Client mong muốn

Mẫu Adapter được ứng dụng trong các trường hợp sau:

- Cần tích hợp một vài module vào chương trình

- Không thể sát nhập trực tiếp module vào chương trình

- Module đang tồn tại không có giao diện như mong muốn

- Cần nhiều hơn các phương thức cho module đó

- Một số phương thức có thể nạp chồng

2.1.7 Mẫu Brigde Pattern

Một thành phần hướng đối tượng (OOP) thường có 2 phần: phần ảo – định nghĩa các chức năng và phần thực thi – thực thi các chức năng được định nghĩa trong phần ảo Hai phần này liên hệ với nhau qua quan hệ kế thừa Những thay đổi trong phần ảo dẫn đến các thay đổi trong phần thực thi

Mẫu Bridge được sử dụng để tách thành phần ảo và thành phần thực thi riêng biệt, do đó các thành phần này có thể thay đổi độc lập và linh động thay

vì liên hệ với nhau bằng quan hệ kế thừa hai thành phần này mà liên hệ với nhau thông qua quan hệ chứa trong

Hình 2.7 Cấu trúc của mẫu Bridge

Trang 29

 Implementation: là giao tiếp thực thi của lớp các chức năng nào đó của Abstraction

 RefineAbstraction: là định nghĩa các chức năng mới hoặc chức năng đã có trong Abstraction

 ConcreteImplement: là các lớp định nghĩa tường minh các thực thi trong lớp giao tiếp Implementation

 Sử dụng mẫu khi chúng ta muốn tạo ra sự mềm dẻo giữa 2 thành phần: phần ảo và thực thi của một thành phần và tránh đi mối quan hệ tĩnh giữa chúng

 Sử dụng mẫu khi muốn những thay đổi của phần thực thi sẽ không ảnh hưởng đến Client

 Định nghĩa nhiều thành phần ảo và thực thi

 Phân lớp con một cách thích hợp, nhưng lại muốn quản lý 2 thành phần của hệ thống một cách riêng biệt

Trang 30

- 30 –

2.1.8 Mẫu phức hợp (Composite Pattern)

Mẫu phức hợp được dùng để thiết kế các đối tượng thành cấu trúc cây

để biểu diễn quan hệ bộ phận – tổng thể Mẫu phức hợp cho phép mã khách hàng (client) xem các đối tượng đơn lẻ và đối tượng hợp từ các đối tượng đơn

lẻ này đều như nhau

Việc không phân biệt đối tượng đơn lẻ và đối tượng phức hợp làm chương trình xử lý trở nên đơn giản hơn Mục tiêu này đạt được bằng cách lợi dụng tích đa hình trong lập trình hướng đối tượng đơn lẻ lẫn đối tượng phức hợp

Hình 2.8 Cấu trúc của mẫu Composite

Trang 31

 Composite: là lớp được định nghĩa bởi các thành phần mà nó chứa Composite chứa một nhóm động các Component, vì vậy nó có các phương thức để thêm vào hoặc loại bỏ các thể hiện của Component trong tập các Component của nó Những phương thức được định nghĩa trong Component được thực thi để thực hiện các hành vi đặc tả cho lớp Composite và để gọi lại phương thức đó trong các nốt của nó Lớp Composite được gọi là lớp nhánh hay lớp chứa

 Leaf: là lớp thực thi từ giao tiếp Component Sự khác nhau giữa lớp Leaf

và Composite là lớp Leaf không chứa các tham chiếu đến các Component khác, lớp Leaf đại diện cho mức thấp nhất của cấu trúc cây

Trang 32

- 32 –

2.1.9 Mẫu lưu giữ (Memento Pattern)

Mẫu này được sử dụng nhằm mục đích không làm phá vỡ tính bao gói (encapsulation) nhưng vẫn lưu giữ và thể hiện được trạng thái bên trong đối tượng để sau này đối tượng có thể phục hồi lại trạng thái trước đó

Các thành phần tham gia vào cấu trúc Memento:

 Memento: Lưu giữ trạng thái riêng của đối tượng nguồn Originator, bảo

vệ chống truy xuất bởi các đối tượng khác ngoài đối tượng Originator của

Trang 33

Sử dụng mẫu này làm đơn giản hóa đối tượng Originator, người dùng chỉ quản lý các tình trạng do Originator yêu cầu và tránh được việc người dùng phải thông báo cho Originator khi họ thực hiện xong

Memento có thể bị quá tải nếu đối tượng nguồn Originator phải sao chép khối lượng lớn những thông tin lưu trữ hay nếu người dùng tạo và trả lại Memento cho Originator khi đối tượng này đã đầy

2.1.10 Mẫu quan sát (Observer Pattern)

Mẫu quan sát định nghĩa mối quan hệ phụ thuộc một – nhiều giữa các đối tượng sao cho khi một đối tượng thay đổi trạng thái thì tất cả các đối tượng liên quan cũng sẽ thông báo và tự động cập nhật theo

Việc phân chia hệ thống thành nhiều lớp con có quan hệ với nhau là nhu cầu tất yếu có thể duy trì sự bền vững của hệ thống Chúng ta không bao giờ muốn cài đặt hệ thống mà tất cả các lớp dính chặt lại với nhau, bởi vì điều này sẽ làm giảm tính tái sử dụng lại của chúng

Ví dụ, nhiều công cụ giao diện đồ họa phân tách giao diện (GUI) ra khỏi dữ liệu bên dưới Các lớp định nghĩa cho giao diện và dữ liệu trên có thể kết hợp với nhau để làm việc cũng như có thể được sử dụng 1 cách độc lập

Mẫu quan sát mô tả cách thiết lập mối quan hệ này Có hai đối tượng then chốt trong mẫu này, đó là Subject và Observer Một đối tượng Subject có thể có một hoặc nhiều đối tượng Observer phụ thuộc vào nó Tất cả các đối tượng Observer sẽ được cảnh báo (notify) khi đối tượng Subject có sự thay

Trang 34

- 34 –

đổi về trạng thái Khi đó, các đối tượng Observer sẽ lấy thông tin về trạng thái của đối tượng Subject để tự cập nhật lại trạng thái của chính nó

* Cấu trúc của mẫu Observer

Ở cấu trúc trên, khi khởi tạo một đối tượng thuộc lớp ConcreteObserver thì sự khởi tạo này phải dựa trên đối tượng thuộc lớp ConcreteSubject để lấy thông tin trạng thái hiện tại của đối tượng Subject Đặc biệt của mẫu này là sự ánh

xạ qua lại giữa đối tượng thuộc lớp Subject và các đối tượng thuộc lớp Observer Đối tượng ConcreteObserver sẽ giữ con trỏ của đối tượng ConcreteSubject Ngược lại lớp cha của lớp ConcreteSubject (lớp Subject) sẽ giữ một mảng các con trỏ đến lớp Observer (lớp cha của lớp ConcreteObserver)

Hình 2.10 Cấu trúc của mẫu Observer

Trang 35

- 35 –

Khi áp dụng có mối quan hệ phụ thuộc, đối tượng này phụ thuộc vào đối tượng kia

Khi một sự thay đổi ở đối tượng này dẫn đến sự thay đổi ở đối tượng khác và chúng ta không biết chính xác có bao nhiêu đối tượng phải thay đổi theo

2.1.11 Mẫu ủy nhiệm (Proxy Pattern)

* Ý nghĩa

Mẫu ủy nhiệm (Proxy Pattern) là mẫu thiết kế mà ở đó tất cả các truy cập trực tiếp một đối tượng nào đó sẽ được chuyển hướng vào một đối tượng trung gian của lớp ủy nhiệm

Mẫu ủy nhiệm không những giúp quản lý đối tượng tốt hơn mà còn có nhiệm vụ bảo vệ việc truy cập một đối tượng bằng cách thông qua Proxy, hay còn gọi là truy cập gián tiếp Mẫu Proxy được ủy quyền về phía ứng dụng khách cho phép tương tác với đối tượng đích theo những cách khác nhau, như gửi yêu cầu một dịch vụ nào đó, theo dõi trạng thái và vòng đời đối tượng, xây dựng lớp vỏ bảo vệ đối tượng… Thí dụ, chúng ta phát hiện ra một đối tượng như thư viện DLL có thể bị khai thác truy cập vào trong một số trường quan trọng, khi đó chúng ta không thể mở mã nguồn thư viện đã được dịch để

vá lỗ hổng Giải pháp lúc này là xây dựng một proxy ngăn chặn truy cập các trường đó và cuối cùng biên dịch lại thành một DLL mới

Định dạng
Số trang	71
Dung lượng	2,83 MB