Luận văn Xây dựng công cụ mô hình hoá tiến trình hỗ trợ mẫu tiến trình

11 Chương 2 MÔ HÌNH HOÁ TIẾN TRÌNH VÀ MẪU TIẾN TRÌNH 12 CHƯƠNG 2 MÔ HÌNH HOÁ TIẾN TRÌNH VÀ MẪU TIẾN TRÌNH Trong chương này, dựa trên nguồn tham khảo chính từ luận văn của TS Trần Hạnh Nhi [2], chúng tôi xin trình bày tổng quan về việc mô hình hoá tiến trình phần mềm và mẫu tiến trình. Ngoài ra, chúng tôi cũng đưa ra một ví dụ minh họa để thấy rõ nhu cầu tái sử dụng lại mẫu tiến trình. 2.1 Mô hình hoá tiến trình 2.1.1 Giới thiệu Tiến trình phần mềm được định nghĩa là một tập các hoạt động có thứ tự để phát triển hoặc bảo trì một sản phẩm phần mềm [2]. Ngày nay, tất cả các tổ chức phát triển phần mềm đều tuân thủ theo một tiến trình phát triển nào đó. Tiến trình phát triển phần mềm có ảnh hưởng to lớn đến chất lượng của các sản phẩm phần mềm. Từ đó chúng ta có thể thấy được tầm quan trọng của hướng nghiên cứu về công nghệ tiến trình. Hướng nghiên cứu này tập trung vào các phương pháp, công nghệ nhằm cho phép mô hình hoá, hỗ trợ vận hành các tiến trình đồng thời hỗ trợ cả việc phân tích và cải tiến tiến trình. Để có thể vận hành, phân tích, và cải tiến trước hết các tiến trình phần mềm cần phải được mô tả một cách tường minh thông qua việc mô hình hoá tiến trình phần mềm [2]. Mô hình hoá tiến trình phần mềm là việc mô tả tiến trình phần mềm thông qua một hoặc một vài mô hình tiến trình. Mô hình tiến trình là một bản mô tả tiến trình bằng một ngôn ngữ mô hình hoá nào đó (Process Modeling Language). Trong suốt hai thập niên qua, đã có rất nhiều nghiên cứu về mô hình hoá tiến trình và các khía cạnh liên quan đến nó. Trong phần này, chúng tôi sẽ trình bày một bức tranh tổng thể về việc mô hình hoá tiến trình như mục tiêu của việc mô hình hoá, các ngôn ngữ dùng để mô hình hoá tiến trình. 13 2.1.2 Mục tiêu và lợi ích của việc mô hình hoá Mục tiêu chính của việc mô hình hoá tiến trình là để xác định rõ quá trình phát triển phần mềm trong thực tế từ đó có thể tìm hiểu, cải tiến và sử dụng lại trong các trường hợp tương tự hoặc phục vụ cho việc vận hành tự động các tiến trình [1]. Việc mô hình hoá tiến trình mang lại các lợi ích như sau [2]: - Giúp tiến trình dễ hiểu: thông qua việc mô tả tiến trình một cách rõ ràng, các tri thức tiến trình trở nên dễ hiểu và dễ trao đổi giữa những người cùng tham gia tiến trình. Nếu không có một ngôn ngữ mô hình hoá chặt chẽ, thống nhất thì việc mô tả và hiểu tiến trình có thể khác nhau giữa các nhóm đối tượng, từ đó dẫn đến những bất cập trong quá trình phối hợp phát triển phần mềm [1]. - Giúp dễ dàng hơn trong việc quản lý và vận hành tiến trình: nếu một mô hình tiến trình được định nghĩa một cách chi tiết, với ngữ nghĩa rõ ràng, đầy đủ thì chúng ta có thể theo dõi diễn tiến của tiến trình sát sao hơn. Các thông tin về trạng thái của các hoạt động, các sản phẩm…được mô tả rõ, qua đó có thể kiểm chứng với tình hình của tiến trình trong thực tế để có thể điều chỉnh kịp thời [1]. Ngoài ra chúng ta còn có thể phát triển các công cụ hỗ trợ cho việc lập kế hoạch, điều khiển và giám sát việc thực thi tiến trình. Nếu mô hình tiến trình được định nghĩa đủ hình thức, hoàn toàn có thể thực hiện chúng một cách tự động thông qua các công cụ hỗ trợ tương ứng. - Để dễ dàng hơn cho việc phân tích và cải tiến tiến trình: mô hình tiến trình cung cấp các thông tin cho việc phân tích và giả lập tiến trình. Hơn nữa, sự tồn tại của mô hình tiến trình cho phép dễ dàng hơn trong việc sử dụng lại các tiến trình đã được kiểm nghiệm, đây là một nhân tố quan trọng để cải tiến tiến trình. 2.1.3 Mô hình tiến trình Mô hình tiến trình là một bản mô tả trừu tượng hoá của một tiến trình trong thực tế. Hiện có nhiều quan điểm chưa thống nhất về các thành tố cần có trong 14 một mô hình tiến trình. Ở đây chúng tôi chỉ nhấn mạnh những điểm chung về nội dung của các mô hình tiến trình trong một số nghiên cứu. 2.1.3.1 Nội dung của mô hình tiến trình Có nhiều loại thành tố khác nhau của tiến trình có thể được biểu diễn trong một mô hình tiến trình. Qua các hướng tiếp cận được đề nghị trong các nghiên cứu khác nhau, chúng tôi nhận thấy có các loại thành tố tiến trình như sau [2]: Các thành tố chính: · Các tác vụ · Các sản phẩm · Các vai trò Các thành tố phụ: · Các Agent: là một cá nhân tham gia vào quá trình phát triển. Một agent có thể đóng nhiều vai trò tại cùng một thời điểm. · Các tài nguyên: là một thành tố giúp dễ dàng hơn cho việc thực thi một hoạt động, ví dụ như các công cụ, hướng dẫn…Các thông tin này rất hữu ích trong suốt quá trình thực hiện tiến trình. · Các thông tin định lượng: cho phép đánh giá hiệu quả và chất lượng tiến trình, ví dụ như độ đo, các kết quả kiểm thử… · Các thông tin tổ chức: giúp dễ dàng hơn cho việc thi hành một tiến trình trong một dự án cụ thể nào đó. Nói chung, chúng liên quan đến ngữ cảnh công việc, cách sắp xếp, tổ chức các tài nguyên, cách thức phối hợp và giao tiếp… Một mô hình tiến trình không chỉ mô tả các thành tố tiến trình, mà còn mô tả mối quan hệ giữa các thành tố đó. Một số quan hệ chính là quan hệ giữa các hoạt động và các sản phẩm, quan hệ giữa các vai trò và các hoạt động và quan hệ giữa các vai trò với các sản phẩm. 15 2.1.3.2 Các khung nhìn về mô hình tiến trình Một mô hình tiến trình có thể được biểu diễn dưới nhiều góc nhìn khác nhau nhằm mô tả các khía cạnh khác nhau của một tiến trình. Curtis [9] đã đề xuất bốn góc nhìn khác nhau về mô hình tiến trình: · Functional View: mô tả các hoạt động trong tiến trình · Behavioral View: mô tả thứ tự thực thi của các hoạt động và các điều kiện tương ứng. · Organisatinal View: mô tả việc tham gia của các vai trò trong các hoạt động và sự phân phối tài nguyên cho việc thi hành tiến trình. · Informational View: biểu diễn các thông tin được xử lý trong tiến trình. Việc lựa chọn góc nhìn để mô hình hoá tiến trình phụ thuộc vào nhu cầu của nhà thiết kế tiến trình. 2.1.4 Ngôn ngữ mô hình hoá tiến trình Một mô hình tiến trình phải được diễn đạt bằng một ngôn ngữ nào đó. Ngôn ngữ mô tả tiến trình định nghĩa các khái niệm dành cho các tiến trình, đồng thời cung cấp cú pháp và hệ thống ký hiệu để biểu diễn mô hình tiến trình thông qua các khái niệm này. Có nhiều cách phân loại ngôn ngữ mô tả tiến trình khác nhau, ví dụ như dựa trên hệ ngôn ngữ, dựa trên mức độ hình thức của ngôn ngữ…Trong phần này, chúng tôi quan tâm đến khía cạnh mức độ hình thức của ngôn ngữ để để phân loại các ngôn ngữ. Mức độ hình thức của một ngôn ngữ được đo dựa trên mức độ chặt chẽ, chính xác trong định nghĩa của ngôn ngữ đó. Các ngôn ngữ mô hình hoá có thể được phân thành 3 loại như sau [2]: - Ngôn ngữ không hình thức: là một ngôn ngữ không được định nghĩa một cách rõ ràng. Chúng có thể đưa ra một vài ký hiệu nào đó để biểu diễn tiến trình nhưng chúng không định nghĩa hệ thống các khái niệm, cú pháp và ngữ nghĩa một cách đầy đủ và chính xác để thiết lập nên các quy luật tạo dựng các mô hình tiến trình. Các mô hình được mô tả bởi các ngôn ngữ này có thể không chính 16 xác và nhập nhằng. Vì vậy chúng khó phân tích và không thể vận hành được. Các ký hiệu được dùng có thể ở dạng văn bản (ngôn ngữ tự nhiên) hoặc ký hiệu đồ họa. Tuy nhiên các ngôn ngữ này có khả năng diễn đạt cao nên được dùng để mô tả các tiến trình phức tạp, ví dụ như các mô hình tiến trình được đề xuất trong CMMI và ISO 12207. - Ngôn ngữ bán hình thức: Các ngôn ngữ này đưa ra một định nghĩa rõ ràng các khái niệm của tiến trình, một cú pháp hình thức để tạo dựng các mô hình bằng cách sử dụng các khái niệm đã đề nghị. Ngữ nghĩa của các khái niệm cũng được định nghĩa, nhưng vẫn còn chưa chính xác, chưa hoàn chỉnh và không thực thi được. Các ngôn ngữ này có thể hỗ trợ cho việc phân tích nhưng không thể cho việc giả lập hoặc thực thi tự động các mô hình tiến trình. Các ngôn ngữ này thường được dùng để xác định và hiểu các tiến trình phần mềm. Ví dụ như IDEF0 [35], E3 [6], SPEM [38]… - Ngôn ngữ hình thức: Các ngôn ngữ này xác định một cách đầy đủ và chính xác hệ thống các khái niệm, cú pháp hình thức và ngữ nghĩa tương ứng để tạo dựng nên các mô hình tiến trình. Các mô hình được biểu diễn bằng loại ngôn ngữ này có thể giả lập và thực thi tự động được. Ví dụ như APPL/A [43], Spell [12], APEL [17], Promenade [36], UML4SPM [8]. 2.1.5 Nhu cầu sử dụng lại tiến trình Các tiến trình phần mềm thường phụ thuộc yếu tố con người, có khuynh hướng thay đổi, rất linh động và không ổn định [18]. Bản chất phức tạp này khiến cho tiến trình phần mềm khó để mô tả và xử lý. Do đó, việc mô hình hoá tiến trình là một công việc đòi hỏi rất nhiều công sức, sự đầu tư và thường tiêu tốn nhiều thời gian, tiền bạc [23][27]. Hướng tiếp cận xây dựng tiến trình mới bằng cách sử dụng lại những tiến trình có sẵn là một trong những cách thức nhằm nâng cao chất lượng tiến trình và giảm chi phí thiết kế tiến trình. Nó được định nghĩa là một hướng tiếp cận trong đó việc xây dựng một tiến trình được dựa trên tri thức của tiến trình có sẵn, đã được trải nghiệm và có thể sử dụng lại [30]. 17 Thường các nghiên cứu về hướng tiếp cận này tập trung vào hai vấn đề chính như sau [24][34]: Vấn đề thứ nhất bao gồm việc nhận diện, biểu diễn và tổ chức tri thức tiến trình, trong khi vấn đề thứ hai liên quan đến việc xây dựng một tiến trình mới có sử dụng lại các tri thức tiến trình đã có này. 2.2 Mẫu tiến trình 2.2.1 Giới thiệu Xuất phát từ các nghiên cứu của Alexander về mẫu kiến trúc [3], K. Beck và W. Cuningham [7] đã đưa khái niệm mẫu đến với công nghệ phần mềm. Mẫu phần mềm mô tả các vấn đề thường xuyên xảy ra trong một ngữ cảnh cụ thể của quá trình phát triển phần mềm và đề xuất một giải pháp đã được kiểm nghiệm để giải quyết vấn đề này [16]. Ngày nay, khái niệm mẫu được cộng đồng nghiên cứu về kỹ thuật phần mềm xem là một phương tiện hữu hiệu để sử dụng lại các tri thức thu được trong quá trình phát triển phần mềm. Mẫu phần mềm có thể được phân thành các loại như sau: - Mẫu sản phẩm: đưa ra các đặc tả về các sản phẩm trong quá trình phát triển. - Mẫu tiến trình: đưa ra các đặc tả về các bước cần tuân thủ để thực hiện quá trình phát triển. Mẫu sản phẩm đã được biết đến và sử dụng rất nhiều trong quá trình phát triển phần mềm hiện nay. Các nghiên cứu chính về mẫu sản phẩm gồm có: mẫu phân tích [11] [22], mẫu thiết kế [25], mẫu kiến trúc [10] và mẫu cài đặt [14]. Trong khi đó, mẫu tiến trình vẫn còn là một chủ đề mới, còn đang phát triển và có nhiều hạn chế. Khái niệm mẫu tiến trình được Coplien [15] giới thiệu lần đầu tiên tại hội nghị PloP’94 với ý nghĩa là mẫu về các tri thức tiến trình. Kể từ đó, đã có nhiều nghiên cứu về khái niệm này và xem nó như là một phương tiện phục vụ cho việc lưu trữ và sử dụng lại các tiến trình. Hiện nay có nhiều định nghĩa về mẫu tiến trình được đề xuất bởi các nhóm nghiên cứu khác nhau. Mẫu tiến trình được định nghĩa như là mẫu lưu giữ một tiến trình đã qua kiểm nghiệm [19][28], là toàn bộ các công nghệ và hoạt động áp dụng để giải quyết các vấn đề thường gặp trong 18 quá trình phát triển [4][9], là một mô hình cung cấp bản thiết kế tiến trình [31], là một mô hình lưu giữ cấu trúc chung của tiến trình [42]…Trong quan điểm của nhóm tác giả Tran H.N [2], mẫu tiến trình là mẫu cung cấp giải pháp cho các vấn đề mô hình hoá tiến trình thường gặp. Giống như các loại mẫu phần mềm khác, mẫu tiến trình cho phép lưu giữ các tri thức tiến trình đã qua kiểm nghiệm, cho phép mô tả các vấn đề và giải pháp tương ứng trong quá trình phát triển, giúp thuận tiện cho việc trao đổi cũng như sự hiểu biết về các tiến trình [19]. Ngoài ra, mẫu tiến trình còn có thể được sử dụng cho việc mô hình hoá tiến trình [9][42] bởi vì chúng: - Cho phép mô tả các tiến trình theo kiểu mô đun và có thể sử dụng lại: một mẫu tiến trình lưu giữ các phần tiến trình có thể sử dụng lại cho một vấn đề cụ thể nào đó. Một tiến trình mới có thể được thiết kế dựa trên cơ sở sử dụng lại một hoặc nhiều mẫu tiến trình có sẵn. - Cho phép mô tả các tiến trình theo kiểu linh động và dễ điều chỉnh: một mẫu có thể được áp dụng trong nhiều tình huống khác, vì vậy nó góp phần tạo ra các mô hình tiến trình linh động và dễ điều chỉnh hơn. Như vậy, có thấy thấy rằng mẫu tiến trình giúp cho việc sử dụng lại các tiến trình trở nên có triển vọng hơn. Tuy nhiên, các định nghĩa hiện tại vẫn còn chưa rõ ràng và chưa được chuẩn hoá [2]. 2.2.2 Các mẫu tiến trình hiện có Hiện có nhiều nghiên cứu cố gắng rút trích các tri thức tiến trình từ các tiến trình đã qua kiểm nghiệm. Tuy nhiên, chúng tôi nhận thấy chỉ có [4][5] là mô tả được rõ ràng một hệ thống các mẫu tiến trình. Kết quả đáng ngạc nhiên này một phần là do việc nhập nhằng về khái niệm giữa các nhà nghiên cứu với nhau [2]. Để có một cái nhìn toàn cảnh về các hướng tiếp cận liên quan đến mẫu tiến trình, chúng tôi mở rộng giới thiệu các nghiên cứu quan trọng khác trong lĩnh vực sử dụng lại các tri thức tiến trình, không chỉ gói gọn trong các tiến trình phần mềm mà còn cho cả các tiến trình nghiệp vụ. 19 2.2.2.1 Các mẫu tiến trình OOSP Ambler đã đưa ra một tiến trình phát triển phần mềm hướng đối tượng gọi tắt là OOSP (Object oriented software process) [4][5]. Mô hình tiến trình này được biểu diễn bằng một tập hợp các mẫu tiến trình, mỗi mẫu tập trung vào một vấn đề cụ thể của quá trình phát triển phần mềm hướng đối tượng. Tác giả đã phân thành 3 loại mẫu tiến trình: - Task Pattern: loại mẫu tiến trình này mô tả các bước con để thực hiện một tác vụ cụ thể nào đó. Ví dụ như mẫu “RequirementTesting”. - Stage Pattern: loại mẫu tiến trình này mô tả một tập các tác vụ, thường được thực hiện lặp lại nhiều lần, của một giai đoạn phát triển phần mềm. Một Stage Pattern có thể bao gồm nhiều Task Pattern. Ví dụ như Stage Pattern “Program” bao gồm các Task Pattern như mẫu “Write Source Codes”, mẫu “Reuse existing components”, mẫu “Technical review”. - Phase Pattern: loại mẫu này mô tả sự tương tác giữa các Stage Pattern trong suốt một pha của dự án. Phase Pattern bao gồm nhiều Stage Pattern. Ví dụ mẫu “Construct” bao gồm các Stage Pattern như mẫu “Model”, mẫu “Program”, mẫu “Test in the Small” và mẫu “Generalize”. 2.2.2.2 Các mẫu của Bergner Nhóm của Bergner [9] đã đề xuất một tập các mẫu tiến trình phục vụ cho việc xây dựng các tiến trình phần mềm hướng đối tượng. Các tác giả đề xuất bốn loại mẫu như sau: - Project Pattern: các mẫu này mô tả thứ tự thực hiện các pha của tiến trình phần mềm để tạo ra các sản phẩm. Ví dụ các mẫu như: Topdown, BottomUp, ArchitectureDriven, Roundtrip, Iterative. - Inter-Result Pattern: các mẫu thuộc loại này đề xuất một giải pháp nhằm tạo ra các sản phẩm thuộc ít nhất hai pha phát triển phần mềm khác nhau. Ví dụ mẫu Technical Foundation, Experimental Combined Prototyping, Component Assessment và Component Update. 20 - Hand Result Pattern: các mẫu này liên quan đến việc tạo ra các sản phẩm chính của quá trình phát triển. Ví dụ như Customer-Driven Analysis, Market- Driven Analysis, Experimental Prototyping, Design-Driven Evaluation. - Subresult Pattern: loại mẫu này cung cấp các giải pháp để tạo ra các sản phẩm tạm thời trong quá trình phát triển. Ví dụ như Adaptation by Wrapping, Wrapping and Adaptation by ReImplementation. 2.2.2.3 Workflow Patterns của Van der Aalst Mẫu luồng công việc được đề xuất bởi Van der Aalst [46] là khái niệm xuất hiện trong cộng đồng tiến trình nghiệp vụ. Mẫu luồng công việc đưa ra một giải pháp để biểu diễn luồng điều khiển giữa các hoạt động trong một ngữ cảnh nào đó. Mặc dù mẫu luồng công việc không mô tả các hoạt động có thể sử dụng lại như các mẫu tiến trình bên trên, nhưng chúng cung cấp các cấu trúc thường gặp của mô hình tiến trình. Mẫu luồng công việc hiện được chia thành 6 nhóm: - Basic Control Flow: Luồng điều khiển cơ bản như Sequence, Parallele Split, Exclusive Choice, Simple, Merge. - Advanced Branching and Synchronization: Rẽ nhánh và đồng bộ hoá nâng cao như MultipleChoice, SynchronizingMerge. - Structural: biểu diễn các tình huống liên quan đến các ràng buộc cấu trúc trong các tiến trình như Arbitrary Cycles, Implicit Termination. - Muiltiple Instances: mô tả các tình huống nhiều thể hiện của một hoạt động cùng được thực thiện tại một thời điểm: Multiple Instances Without Synchronization, Multiple Instances With a priori Design Time Knowledge. - State-based: biểu diễn việc thi hành một dãy các hoạt động phụ thuộc vào trạng thái của việc thực hiện các hoạt động khác ví dụ như Deferred Choice, Interleaved Parallel Routing. - Cancellation: biểu diễn việc kết thúc một hoạt động hoặc một tiến trình ví dụ như Cancel Activity. 21 2.2.2.4 Các nhóm mẫu tiến trình khác Ngoài các mẫu tiến trình đã giới thiệu ở trên, vẫn còn một số nghiên cứu khác liên quan đến việc tìm ra các mẫu tiến trình mới. Chúng tôi xin đề cấp một số nhóm mẫu tiến trình khác như: - Các mẫu MSF: tác giả đề xuất các mẫu tiến trình và mẫu tổ chức rút trích từ Microsoft Solutions Framework (MSF) [40]. Các mẫu được giới thiệu gồm Living Document, Clonable Lifecycle, Smart Lifecycle và Stakeholder-Oriented Organization. - Mẫu tiến trình nghiệp vụ: cộng đồng tiến trình nghiệp vụ cũng định nghĩa các mẫu tiến trình cho phép mô tả tiến trình nghiệp vụ, tiêu biểu gồm Penker&Eriksson [41] và MIT Handbook [33]. - Các mẫu tổ chức: Người ta cũng tìm ra các mẫu tiến trình trong hệ thống các mẫu tổ chức như [21][15][29][32][45]. Phần lớn các mẫu liên quan đến tiến trình giới thiệu ở đây đều được biểu diễn một cách không hình thức. Điều đó khiến cho người ta không thể sử dụng chúng trong việc tự động hoá nhằm phục vụ cho việc mô hình hoá tiến trình phần mềm. 2.2.3 Sử dụng mẫu tiến trình 2.2.3.1 Biểu diễn mẫu tiến trình Như chúng tôi đã đề cập, việc biểu diễn một cách trừu tượng, khó hiểu của mẫu tiến trình sẽ ngăn cản khả năng sử dụng lại chúng một cách hiệu quả. Vì vậy hình thức biểu diễn các mẫu tiến trình là yếu tố quan trọng để thúc đẩy việc ứng dụng chúng trong thực tế. Biểu diễn hình thức đưa ra một cấu trúc bao gồm một danh sách toàn bộ các đặc tính quan trọng của mẫu tiến trình. Hiện có khá nhiều biểu diễn hình thức được đề xuất như [4][13][42][44]. Mặc dù các hình thức được đề nghị khác nhau về số lượng và mức độ chi tiết về các đặc tính của mẫu tiến trình, nhưng chúng vẫn luôn bao gồm ba đặc tính quan trọng nhất: vấn đề thường xảy ra, giải pháp cho vấn đề đó và ngữ cảnh áp dụng của nó [2]. 22 Việc mô tả một cách không hình thức các mẫu tiến trình bằng ngôn ngữ tự nhiên được thực hiện khá dễ dàng và đơn giản. Nhưng ngôn ngữ tự nhiên có thể gây ra việc hiểu sai, nhập nhằng và biểu diễn không hình thức của tiến trình là không hiệu quả nếu muốn dùng nó như một cơ sở cho việc trao đổi hoặc nếu muốn được hỗ trợ một cách tự động bằng các công cụ mô hình hoá tiến trình. Đây là lý do tại sao xuất hiện nhu cầu cần một ngôn ngữ hình thức hơn để mô tả mẫu tiến trình. Ngôn ngữ hình thức này phải cung cấp ngữ nghĩa cho các khái niệm để hạn chế sự nhập nhằng và khó hiểu. Tuy nhiên, việc biểu diễn hình thức được đề cập rất ít trong các nghiên cứu về mẫu tiến trình. Trong hiểu biết của chúng tôi, hiện chỉ có một vài nhóm nghiên cứu về vấn đề này thông qua việc họ định nghĩa một ngôn ngữ mô tả tiến trình hỗ trợ khái niệm mẫu tiến trình. Tất cả các ngôn ngữ này đều xem mẫu tiến trình là một tập các hoạt động phát triển có thể sử dụng lại. Các ngôn ngữ này đều liên quan đến UML nhưng với những mức độ khác nhau: PROPEL [28], Promenade [36] và SPEM [38] là các mở rộng của UML meta model; Living Process Framework [26] đơn giản đề nghị dùng ký hiệu UML để biểu diễn khía cạnh động của tiến trình. Ưu điểm chính của PROPEL là mô tả cấu trúc bên trong của một mẫu và định nghĩa các quan hệ giữa các mẫu. Một trong những điểm mạnh của Promenade là