Mô hình hóa chính thức quy trình phát triển bằng ngôn ngữ PROGRES (Phần 2)

Tài liệu nghiên cứu Ebook models and tools for managing development processes part 2, tổng hợp lý thuyết và thực hành, cung cấp kiến thức chuyên sâu về .

• Trường học: Springer-Verlag Berlin Heidelberg
• Chuyên ngành: Management Model
• Đề tài: Management Model: Formal Speci cation
• Loại tài liệu: book
• Năm xuất bản: 1999
• Địa điểm: Berlin Heidelberg

Tóm tắt

I. Hướng dẫn mô hình quản lý quy trình phát triển toàn diện

Việc quản lý quy trình phát triển phần mềm hiện đại đòi hỏi một cách tiếp cận có hệ thống và chính xác. Các mô hình quản lý không chỉ đơn thuần là các quy tắc, mà là những khung làm việc được định hình rõ ràng để đảm bảo tính nhất quán, hiệu quả và khả năng mở rộng. Trong bối cảnh này, việc sử dụng các ngôn ngữ đặc tả hình thức như PROGRES, được giới thiệu bởi Schürr và Westfechtel, mang lại một giải pháp mạnh mẽ. Các mô hình này không chỉ mô tả các khía cạnh khác nhau của vòng đời phát triển phần mềm (SDLC) mà còn cung cấp cơ sở để tự động hóa và tối ưu hóa. Một mô hình quản lý hiệu quả phải tích hợp ba thành phần cốt lõi: quản lý sản phẩm, quản lý hoạt động và quản lý tài nguyên. Tài liệu gốc của Westfechtel (1999) nhấn mạnh rằng: "Đặc tả PROGRES của mô hình quản lý đóng vai trò là điểm khởi đầu cho việc triển khai hệ thống quản lý". Điều này cho thấy tầm quan trọng của việc hình thức hóa các quy trình nội bộ, tách biệt rõ ràng giữa biểu diễn nội bộ (dành cho công cụ) và biểu diễn bên ngoài (dành cho người dùng). Việc sử dụng đồ thị thuộc tính (attributed graphs) làm mô hình dữ liệu nền tảng cho phép biểu diễn các cấu trúc phức tạp như lịch sử phiên bản, cấu hình phần mềm và mạng lưới nhiệm vụ một cách tự nhiên. Cách tiếp cận này giúp các công cụ quản lý dự án phần mềm vận hành trên các cấu trúc dữ liệu nội bộ phức tạp, thực hiện các thao tác tinh vi để đảm bảo tính toàn vẹn và nhất quán của dữ liệu. Bằng cách áp dụng các mô hình này, các tổ chức có thể đạt được sự tối ưu hóa quy trình phát triển một cách khoa học, thay vì dựa trên các phương pháp tùy biến và thiếu cấu trúc.

1.1. Tầm quan trọng của vòng đời phát triển phần mềm SDLC

Vòng đời phát triển phần mềm (SDLC) là nền tảng của mọi dự án công nghệ. Nó cung cấp một cấu trúc phương pháp luận cho việc thiết kế, phát triển và duy trì phần mềm chất lượng cao. Việc hiểu rõ và áp dụng một mô hình SDLC phù hợp, dù là Waterfall, V-Model, hay các phương pháp Agile, là yếu tố quyết định sự thành công. Các mô hình hình thức hóa như được đề cập trong tài liệu gốc giúp cụ thể hóa từng giai đoạn của SDLC, từ việc xác định yêu cầu đến triển khai và bảo trì. Chúng cho phép các quy tắc và ràng buộc được định nghĩa một cách chặt chẽ, giảm thiểu sự mơ hồ và sai sót. Ví dụ, việc quản lý các phiên bản sản phẩm và sự phụ thuộc giữa chúng là một phần quan trọng của SDLC, và một mô hình được đặc tả rõ ràng sẽ đảm bảo rằng các mối quan hệ này luôn nhất quán.

1.2. Giới thiệu ngôn ngữ đặc tả PROGRES và ứng dụng

PROGRES (PROgrammed Graph REwriting Systems) là một ngôn ngữ đặc tả tích hợp các khái niệm từ hệ quản trị cơ sở dữ liệu, hệ chuyên gia và hệ thống viết lại đồ thị. Theo Schürr (1991, 1996), PROGRES sử dụng đồ thị thuộc tính làm mô hình dữ liệu cơ bản, nơi các nút (node) mang thuộc tính và được kết nối bằng các cạnh (edge) có hướng. Điểm mạnh của PROGRES là khả năng mô tả các phép biến đổi đồ thị một cách khai báo thông qua các quy tắc viết lại (graph rewrite rules). Điều này cho phép các nhà phát triển định nghĩa các hoạt động phức tạp ở mức độ trừu tượng cao mà không cần quan tâm đến thuật toán tìm kiếm và thay thế mẫu. Ngôn ngữ này đặc biệt phù trợp để xây dựng các công cụ cho nhà phát triển và các hệ thống quản lý yêu cầu sự nhất quán dữ liệu nghiêm ngặt, chẳng hạn như trong quản lý cấu hình và quản lý vòng đời sản phẩm.

II. Thách thức trong việc tối ưu hóa quy trình phát triển

Việc tối ưu hóa quy trình phát triển đối mặt với nhiều thách thức cố hữu, đặc biệt là khi quy mô dự án tăng lên. Một trong những vấn đề lớn nhất là duy trì tính nhất quán trên toàn bộ cơ sở dữ liệu quản lý. Tài liệu gốc chỉ ra rằng: "Cơ sở dữ liệu quản lý sản phẩm được sử dụng bởi nhiều người dùng, do đó cần ngăn chặn sự không nhất quán len lỏi vào cơ sở dữ liệu chung". Các ràng buộc (constraints) về cấu trúc, chẳng hạn như tên đối tượng phải là duy nhất, các mối quan hệ phụ thuộc không được tạo thành chu trình, và một phiên bản ổn định (stable) không thể bị sửa đổi, là cực kỳ quan trọng. Việc không tuân thủ các ràng buộc này có thể dẫn đến lỗi nghiêm trọng trong sản phẩm cuối cùng. Thêm vào đó, việc tự động hóa quy trình làm việc phức tạp là một thách thức khác. Các hoạt động không chỉ diễn ra tuần tự mà thường song song và phụ thuộc lẫn nhau. Ví dụ, một tác vụ chỉ có thể bắt đầu khi tất cả các đầu vào cần thiết đã sẵn sàng. Việc quản lý các trạng thái của tác vụ (ví dụ: Created, Active, Suspended, Done) và các điều kiện chuyển đổi giữa chúng đòi hỏi một cơ chế kiểm soát chặt chẽ. Các phương pháp truyền thống thường thiếu sự linh hoạt để xử lý các kịch bản phức tạp, dẫn đến sự chậm trễ và giảm năng suất của đội ngũ phát triển. Điều này nhấn mạnh sự cần thiết của các mô hình có khả năng đặc tả và thực thi các ràng buộc động một cách hiệu quả, điều mà các công cụ như bảng Kanban hay khung Scrum cố gắng giải quyết ở mức quy trình nhưng cần được hỗ trợ bởi các công cụ kỹ thuật mạnh mẽ hơn.

2.1. Vấn đề ràng buộc nhất quán trong quản lý phiên bản

Quản lý phiên bản là một bài toán phức tạp hơn việc chỉ lưu trữ các phiên bản khác nhau của tệp mã nguồn. Nó bao gồm việc quản lý các cấu hình (configurations), trong đó một cấu hình là một tập hợp các phiên bản cụ thể của nhiều thành phần khác nhau. Tài liệu của Westfechtel (1999) đưa ra nhiều ràng buộc nhất quán, ví dụ: "Mỗi thành phần phiên bản phải được ánh xạ đơn ánh tới thành phần đối tượng tương ứng" (Object-version correspondence) hay "Tất cả các thành phần của một phiên bản cấu hình ổn định cũng phải ổn định" (Configuration stability). Việc vi phạm các ràng buộc này có thể tạo ra các bản dựng không hợp lệ hoặc không thể tái tạo. Các hệ thống kiểm soát phiên bản như Git cung cấp nền tảng tốt, nhưng việc thực thi các quy tắc nghiệp vụ phức tạp này thường phải được xử lý thủ công hoặc bằng các kịch bản tùy chỉnh, làm tăng nguy cơ xảy ra lỗi.

2.2. Khó khăn trong việc tích hợp công cụ và tự động hóa

Một quy trình phát triển hiện đại không thể tách rời khỏi các công cụ tự động hóa. Tuy nhiên, việc tích hợp một chuỗi các công cụ DevOps vào một luồng làm việc liền mạch là không hề đơn giản. Thách thức nằm ở việc đảm bảo luồng dữ liệu chính xác và nhất quán giữa các công cụ, từ hệ thống theo dõi lỗi, hệ thống kiểm soát phiên bản, đến các công cụ trong đường ống CI/CD. Mô hình quản lý hình thức hóa cung cấp một lược đồ (schema) chung, giúp định nghĩa rõ ràng các đối tượng (ví dụ: TASK, VERSION, TOOL) và mối quan hệ giữa chúng. Điều này tạo cơ sở cho việc xây dựng các trình kết nối (connector) và API đáng tin cậy, cho phép tự động hóa quy trình làm việc một cách an toàn và hiệu quả, đảm bảo rằng các hành động được thực hiện bởi một công cụ không vi phạm các ràng buộc của toàn bộ hệ thống.

III. Bí quyết quản lý sản phẩm với các chiến lược quản lý mã

Quản lý sản phẩm hiệu quả là nền tảng của một quy trình phát triển thành công. Cách tiếp cận dựa trên đồ thị thuộc tính cung cấp một phương pháp mạnh mẽ để mô hình hóa cấu trúc sản phẩm phức tạp. Trong mô hình này, mỗi thành phần của sản phẩm, từ một tài liệu đơn lẻ đến một cấu hình hệ thống hoàn chỉnh, được biểu diễn dưới dạng các nút trong một đồ thị. Các mối quan hệ như sự phụ thuộc, lịch sử phiên bản, và thành phần cấu thành được biểu diễn bằng các cạnh. Tài liệu gốc mô tả một lược đồ đồ thị chi tiết, bao gồm các lớp nút như OBJECT, VERSION, CONFIGURATION_OBJECT, và CONFIGURATION_VERSION. Lược đồ này không chỉ định nghĩa cấu trúc mà còn thực thi các ràng buộc toàn vẹn. Ví dụ, một VERSION là một thực thể của một OBJECT, và một CONFIGURATION_VERSION bao gồm các VERSION_COMPONENT. Phương pháp này vượt xa các hệ thống kiểm soát phiên bản truyền thống bằng cách cho phép định nghĩa các chiến lược quản lý mã nguồn tùy chỉnh và thực thi chúng một cách tự động. Các phép biến đổi đồ thị (graph transformations) được sử dụng để thực hiện các thao tác như tạo phiên bản mới (CreateVersion), tạo mối quan hệ kế thừa (CreateHistory), hay đóng băng một phiên bản (FreezeVersion). Mỗi thao tác này được định nghĩa bằng một quy tắc viết lại đồ thị, đảm bảo rằng mọi thay đổi đều tuân thủ các ràng buộc đã định trước, từ đó duy trì sự nhất quán của toàn bộ kho lưu trữ sản phẩm. Đây là một bước tiến quan trọng trong việc xây dựng các công cụ quản lý dự án phần mềm thông minh hơn.

3.1. Xây dựng lược đồ đồ thị cho hệ thống quản lý phiên bản

Lược đồ đồ thị (graph schema) đóng vai trò như một bản thiết kế chi tiết cho cơ sở dữ liệu quản lý sản phẩm. Nó định nghĩa các loại nút, loại cạnh, và các thuộc tính liên quan. Ví dụ, một nút DOCUMENT_VERSION có thể có các thuộc tính như Location (vị trí lưu trữ) và Locked (trạng thái khóa). Một cạnh Successor kết nối hai nút VERSION, biểu thị mối quan hệ kế thừa. Theo Westfechtel (1999), một thiết kế tốt sẽ phân biệt rõ ràng giữa "mặt phẳng đối tượng" (object plane) và "mặt phẳng phiên bản" (version plane), giúp quản lý các biến thể cấu trúc và lịch sử phát triển một cách độc lập. Việc sử dụng kế thừa đa cấp cho các lớp nút cho phép tái sử dụng và mở rộng lược đồ một cách linh hoạt, hỗ trợ các chiến lược quản lý mã nguồn phức tạp.

3.2. Áp dụng quy tắc viết lại đồ thị cho quản lý vòng đời

Quy tắc viết lại đồ thị (graph rewrite rules) là cơ chế cốt lõi để thực hiện các thay đổi trên đồ thị sản phẩm. Mỗi quy tắc bao gồm một vế trái (mẫu cần tìm) và một vế phải (đồ thị thay thế). Ví dụ, quy tắc CreateHistory sẽ tìm kiếm hai phiên bản không có mối quan hệ kế thừa và tạo ra một nút HISTORY cùng các cạnh Predecessor và Successor để nối chúng. Điều quan trọng là các quy tắc này có thể chứa các điều kiện tiên quyết và các điều kiện phủ định. Chẳng hạn, một phiên bản chỉ có thể có phiên bản kế thừa nếu nó ở trạng thái Stable. Việc sử dụng các quy tắc khai báo này giúp đơn giản hóa việc triển khai các thao tác phức tạp, đảm bảo tính nguyên tử (atomic) và nhất quán, đóng góp trực tiếp vào việc tối ưu hóa quy trình phát triển.

IV. Phương pháp quản lý hoạt động theo các phương pháp Agile

Quản lý hoạt động là việc điều phối các nhiệm vụ, luồng công việc và sự tương tác giữa các thành viên trong nhóm phát triển. Các phương pháp Agile, như khung Scrum, cung cấp các nguyên tắc cấp cao cho việc quản lý này. Tuy nhiên, để thực thi chúng một cách hiệu quả trong các dự án lớn, cần có một mô hình hình thức hóa. Mô hình quản lý hoạt động được đề xuất trong tài liệu gốc mở rộng từ mô hình quản lý sản phẩm. Trong đó, một TASK (nhiệm vụ) được xem là một loại VERSION_COMPONENT, và một DATA_FLOW (luồng dữ liệu) là một loại VERSION_DEPENDENCY. Cách tiếp cận "lấy sản phẩm làm trung tâm" này liên kết chặt chẽ các hoạt động với các thành phần sản phẩm mà chúng tác động. Mỗi TASK có một vòng đời trạng thái riêng, được mô tả bằng một sơ đồ chuyển đổi trạng thái (state transition diagram) với các trạng thái như Created, Waiting, Active, Suspended, Done, và Failed. Các phép chuyển đổi trạng thái, ví dụ như Start hay Commit, không chỉ thay đổi trạng thái của nhiệm vụ mà còn được kiểm tra dựa trên các ràng buộc động. Ví dụ, một nhiệm vụ chỉ có thể Start khi các nhiệm vụ tiền nhiệm đã hoàn thành và cung cấp đủ dữ liệu đầu vào. Cách tiếp cận này cung cấp một cơ sở vững chắc để xây dựng các công cụ quản lý dự án phần mềm tiên tiến, có khả năng tự động hóa việc kích hoạt nhiệm vụ, kiểm tra điều kiện hoàn thành và quản lý các luồng công việc phức tạp, vượt xa khả năng của các bảng Kanban đơn thuần.

4.1. Mô hình hóa nhiệm vụ và luồng dữ liệu trong quy trình

Việc mô hình hóa nhiệm vụ và luồng dữ liệu là trung tâm của quản lý hoạt động. Một TASK không chỉ là một mục công việc; nó được gắn với các thuộc tính quan trọng như State (trạng thái) và ReleaseState (trạng thái phát hành). Một DATA_FLOW kết nối hai nhiệm vụ, mô tả sự phụ thuộc dữ liệu, và có các thuộc tính như Propagate (cho phép truyền dữ liệu) và NeededForActivation (cần thiết để kích hoạt). Mô hình này cho phép biểu diễn các kịch bản phức tạp, ví dụ như một nhiệm vụ chỉ có thể bắt đầu khi một số đầu vào cụ thể có sẵn. Điều này tương tự như các quy tắc được áp dụng trong một đường ống CI/CD, nơi một giai đoạn chỉ chạy khi giai đoạn trước đó thành công. Việc hình thức hóa các mối quan hệ này giúp phát hiện sớm các điểm nghẽn và xung đột trong quy trình.

4.2. Quản lý trạng thái và chuyển đổi trong vòng đời nhiệm vụ

Sơ đồ chuyển đổi trạng thái cung cấp một mô tả chính xác về vòng đời của một nhiệm vụ. Mỗi quá trình chuyển đổi tương ứng với một hoạt động cụ thể, ví dụ: Start, Suspend, Commit, Abort. Điều quan trọng là các hoạt động này được điều chỉnh bởi các ràng buộc. Ví dụ, tài liệu gốc chỉ ra rằng một siêu tác vụ (supertask) chỉ có thể ở trạng thái Done nếu tất cả các tác vụ con (subtasks) của nó cũng đã Done. Tương tự, một nhiệm vụ chỉ có thể Commit nếu tất cả các đầu vào của nó đều được cập nhật. Những ràng buộc này, khi được thực thi tự động, sẽ đảm bảo tính toàn vẹn của quy trình, giúp các nhóm thực hành phát triển tinh gọn (Lean development) bằng cách loại bỏ các bước chờ đợi và làm lại không cần thiết.

V. Cách tích hợp công cụ DevOps và quản lý tài nguyên hiệu quả

Một hệ thống quản lý phát triển hoàn chỉnh không chỉ bao gồm sản phẩm và hoạt động, mà còn phải quản lý cả tài nguyên – con người và công cụ. Mô hình quản lý tài nguyên được xây dựng dựa trên hai mô hình trước đó, tạo ra một hệ thống tích hợp toàn diện. Trong mô hình này, RESOURCE là một lớp cha chung, bao gồm EMPLOYEE (nhân viên) và TOOL (công cụ). Mỗi EMPLOYEE có một tập hợp các Roles (vai trò), xác định loại nhiệm vụ mà họ có khả năng thực hiện. Việc phân công nhiệm vụ được mô hình hóa bằng một cạnh ResponsibleFor nối giữa một EMPLOYEE và một TASK. Điều này cho phép hệ thống kiểm tra xem một nhân viên có đủ thẩm quyền để thực hiện một nhiệm vụ cụ thể hay không. Tương tự, mỗi TOOL được liên kết với các loại đối tượng mà nó có thể xử lý (ObjectTypes). Điều này cho phép hệ thống tự động đề xuất các công cụ tăng năng suất cho lập trình viên phù hợp cho một nhiệm vụ nhất định. Quan trọng hơn, mô hình này cho phép thực thi kiểm soát truy cập (access control) một cách tinh vi. Ví dụ, tài liệu gốc quy định rằng chỉ người quản lý (actor của supertask) mới có quyền Redefine một nhiệm vụ, trong khi người thực hiện (actor của task) có quyền Start nó. Việc tích hợp các quy tắc này vào hệ thống giúp tự động hóa việc tuân thủ quy trình, một yếu tố cốt lõi của văn hóa DevOps và các khung Agile mở rộng (SAFe).

5.1. Mô hình hóa vai trò và phân quyền trong nhóm phát triển

Mô hình hóa vai trò không chỉ đơn giản là gán nhãn. Trong PROGRES, vai trò (Roles) của một EMPLOYEE là một thuộc tính có giá trị là một tập hợp các kiểu nhiệm vụ (type in TASK). Điều này có nghĩa là hệ thống có thể kiểm tra một cách hình thức xem việc gán một nhiệm vụ có hợp lệ hay không. Ví dụ, một thao tác Assign (gán nhiệm vụ) sẽ thất bại nếu kiểu của nhiệm vụ không nằm trong tập hợp Roles của nhân viên. Cơ chế này mạnh mẽ hơn nhiều so với việc phân quyền dựa trên danh sách kiểm soát truy cập (ACL) tĩnh, vì nó cho phép các quy tắc phân quyền được liên kết trực tiếp với cấu trúc và loại hình công việc, tạo ra một hệ thống quản lý vòng đời linh hoạt và an toàn.

5.2. Tích hợp công cụ và kiểm soát truy cập trong CI CD

Việc tích hợp công cụ không chỉ là gọi một kịch bản. Mô hình này cho phép định nghĩa mối quan hệ giữa công cụ và nhiệm vụ thông qua đường dẫn Supports. Một TOOL hỗ trợ một TASK nếu nó có thể xử lý loại đầu ra hoặc đầu vào của nhiệm vụ đó. Điều này cho phép tự động hóa việc lựa chọn công cụ. Hơn nữa, việc kiểm soát truy cập có thể được mở rộng cho các hoạt động trong đường ống CI/CD. Mỗi thao tác (ví dụ: Commit, Start, Release) có thể được định nghĩa lại để yêu cầu một tham số Invoker (người gọi). Hệ thống sẽ kiểm tra xem Invoker có phải là người chịu trách nhiệm cho nhiệm vụ tương ứng hay không trước khi cho phép thực hiện. Điều này đảm bảo rằng chỉ những người có thẩm quyền mới có thể thực hiện các thay đổi quan trọng, tăng cường tính bảo mật và ổn định của quy trình quản lý phát hành (release management).

VI. Tương lai của quản lý phát triển Lean và Scaled Agile

Các mô hình quản lý hình thức hóa như được trình bày không chỉ là một bài tập lý thuyết. Chúng mở đường cho một thế hệ công cụ quản lý phát triển thông minh, tự động và có khả năng tự kiểm tra. Tương lai của ngành phát triển phần mềm đang hướng tới các nguyên tắc của phát triển tinh gọn (Lean development) và khả năng mở rộng quy trình Agile cho các tổ chức lớn thông qua các khung như Scaled Agile Framework (SAFe). Cả hai xu hướng này đều đòi hỏi mức độ chính xác, nhất quán và tự động hóa cao mà các phương pháp quản lý truyền thống không thể đáp ứng. Một ưu điểm nổi bật của cách tiếp cận này là khả năng thích ứng mô hình. Tài liệu gốc thảo luận về việc điều chỉnh một "mô hình chung" (generic model) thành một "mô hình cụ thể" (specific model) cho một lĩnh vực ứng dụng nhất định. Điều này được thực hiện bằng cách mở rộng lược đồ đồ thị với các loại nút và ràng buộc cụ thể của miền ứng dụng. Khả năng tùy biến này rất quan trọng, cho phép các tổ chức xây dựng một quy trình quản lý phù hợp chính xác với nhu cầu của họ, thay vì phải tuân theo một khuôn mẫu cứng nhắc. Bằng cách kết hợp sức mạnh của đặc tả hình thức với tính linh hoạt của các phương pháp Agile, các tổ chức có thể xây dựng các quy trình phát triển không chỉ nhanh và hiệu quả, mà còn mạnh mẽ, đáng tin cậy và có khả năng mở rộng.

6.1. Hướng tới phát triển tinh gọn Lean development với mô hình hóa

Phát triển tinh gọn (Lean development) tập trung vào việc tối đa hóa giá trị cho khách hàng và giảm thiểu lãng phí. Các mô hình hình thức hóa đóng góp trực tiếp vào mục tiêu này. Bằng cách tự động hóa việc kiểm tra các ràng buộc và điều kiện tiên quyết, chúng giúp loại bỏ thời gian chờ đợi và các lỗi do con người gây ra. Việc mô hình hóa rõ ràng các luồng dữ liệu và sự phụ thuộc giúp xác định và loại bỏ các điểm nghẽn trong quy trình. Hơn nữa, khả năng theo dõi chính xác trạng thái của từng thành phần sản phẩm và nhiệm vụ cho phép các nhà quản lý đưa ra quyết định dựa trên dữ liệu thực tế, tối ưu hóa việc phân bổ tài nguyên và rút ngắn chu kỳ phát hành sản phẩm.

6.2. Triển vọng của mô hình hình thức trong Scaled Agile SAFe

Scaled Agile Framework (SAFe) được thiết kế để áp dụng các nguyên tắc Agile cho các doanh nghiệp lớn. Một trong những thách thức lớn nhất của SAFe là duy trì sự đồng bộ và nhất quán giữa nhiều nhóm, nhiều dự án. Các mô hình quản lý hình thức hóa cung cấp một "nguồn chân lý duy nhất" (single source of truth) cho toàn bộ tổ chức. Bằng cách định nghĩa một lược đồ đồ thị chung cho tất cả các sản phẩm, hoạt động và tài nguyên, SAFe có thể đảm bảo rằng các mối quan hệ phụ thuộc giữa các nhóm được quản lý một cách chặt chẽ. Việc tự động thực thi các ràng buộc ở cấp độ chương trình và danh mục đầu tư (portfolio) giúp ngăn chặn sự sai lệch và đảm bảo rằng toàn bộ tổ chức đang hoạt động hướng tới cùng một mục tiêu chiến lược.

Trích đoạn nội dung tài liệu

Management Model: Formal Speci cation To formalize the management model introduced in the previous chapter, we use the speci cation language PROGRES [Schurr 1989; Schurr 1990; Schurr 1994; Schurr et al. 1995; Schurr et al. The PROGRES speci cation of the management model serves in turn as a starting point for the implementation of the management system to be described in the next chapter. Note that the speci cation concerns the internal representation used by man- agement tools.

In contrast, in the previous chapter many gures showed external representations of graphs visible at the user interface. These levels have to be separated clearly. Internal representations include all details which have to be taken care of by sophisticated management tools. On the other hand, a simple and readable representation is required at the user interface.

This chapter is structured as follows: Firstly, we give a brief introduction to PROGRES and motivate its application to the management of development processes (Section 9. The subsequent sections are devoted to the speci cation of the submodels for product, activity, and resource management (Sections 9.5, we explain how general base models can be adapted to a speci c application domain. Afterwards, we discuss our experiences gathered in using the PROGRES language (Section 9.7 compares related work, and Section 9.8 gives a short summary.1 PROGRES at a First Glance Building tools for engineering design applications is a challenging task. Such tools operate on complicated internal data structures representing e.

CAD de- signs, manufacturing plans, SA diagrams, software architectures, or programs. In order to realize commands to be executed on such documents, sophisticated operations on the corresponding internal data structures have to be performed. Before implementing these operations in a programming language such as C, Ada, or Modula-2, a high-level speci cation is required from which the imple- mentation may be derived. To satisfy this need, the speci cation language PROGRES [Schurr and Zundorf 1996] has been developed within our group.

The PROGRES language integrates concepts from various disciplines (database systems, knowledge-based systems, graph rewriting systems, programming languages) into one coherent language whose semantics is de ned by means of logic calculus the discussion of B. Westfechtel: Managing Development Processes, LNCS 1646, pp.
c Springer-Verlag Berlin Heidelberg 1999 194 9. Management Model: Formal Speci cation which goes beyond the scope of this book (see [Schurr 1991; Schurr 1996]).

Let us brie y summarize the most important language features: { PROGRES is based on attributed graphs as the underlying data model. Nodes, which may carry attributes, are connected by binary, directed relationships (edges), which may not carry attributes. { A graph schema de nes types of nodes, edges, and attributes, thereby serving as a database schema. Node types are organized into a multiple inheritance hierarchy.

All graph operations have to conform to the graph schema. { Derived data may be de ned in graph schema as well. This includes derived attributes, paths (i., derived binary relationships), restrictions (unary rela- tionships, i., conditions on nodes), and constraints. { Graph transformations are described declaratively by means of graph rewrite rules (rule-based programming style).

A graph rewrite rule essentially consists of a left-hand side | the graph pattern to be matched | and a right-hand side | the replacing subgraph. \Declarative" means that the user of PROGRES is not concerned with the algorithms for pattern matching and replacement. In particular, the left-hand sides can be very general graph patterns containing paths, restrictions, optional nodes, set nodes, negative application conditions, etc. { In addition, PROGRES o ers graph tests which can be considered graph rewrite rules performing identical replacements (i., a graph test searches for a pattern and leaves the host graph una ected).

{ In case the rule-based programming style does not suÆce, PROGRES provides control structures for calling graph rewrite rules and graph tests (sequence, branch, various forms of loops, etc. These control structures take non-determinism into account | which is inher- ent to graph rewrite rules because there are often di erent pattern matches among which one can be selected for replacement. In particular, if the appli- cation of a rule fails, backtracking is triggered so that the solution space is explored through depth- rst search. The PROGRES development environment [Schurr et al.

1995; Schurr et al. 1996; Schurr et al. 1999] o ers tightly integrated, syntax-aided tools for con- structing speci cations. The PROGRES language is hybrid in that it contains both textual and graphical parts.

The editor guarantees correctness with re- spect to the context-free syntax and checks the rules of the context-sensitive syntax incrementally. The browser supports navigation along both context-free and context-sensitive relationships (in the underlying syntax tree and along bind- ings of identi ers to their declarations, respectively). The interpreter executes an intermediate graph code which is incrementally generated from the speci cation. The tools are integrated seamlessly in that commands provided by di erent tools can be invoked in almost any order (e., the speci cation can be edited during interpretation).

In this chapter, we use PROGRES to specify the structure of the management database and the operations performed on it. Attributed graphs are well suited 9.2 Product Management Model 195 to represent version histories, con gurations, task nets, etc. in a natural way. The overall product management graph is a quite sophisticated graph structure which has to ful ll many consistency constraints.

Operations on the product management graph perform complicated changes which can be speci ed with the help of graph rewrite rules such that these consistency constraints are not violated. In the following, we present cut-outs of the speci cation of the management model developed in the SUKITS project. The speci cation fragments to be pre- sented were created with the help of the PROGRES environment, which also provides a tool for transforming the speci cation into a text-processing format. In our presentation, we do not assume that the reader is familiar with the PRO- GRES language.

Rather, the language constructs are explained as required. For further information on PROGRES, the reader is referred to [Schurr 1996; Schurr 1998].2 Product Management Model After having introduced the product management model in an informal way in Section 8.1, we now turn to its formal speci cation [Westfechtel 1994; Westfechtel 1996a]. First, we describe the schema for product management graphs , including constraints. Next, we specify consistency-preserving operations.1 Graph Schema Node classes, edge types, and attributes PROGRES is based on attributed graphs.

An attributed graph consists of nodes decorated with attributes and edges which do not carry attributes. An edge represents a binary, directed rela- tionship. When a node is deleted, all adjacent edges are deleted as well (referen- tial integrity). Furthermore, an edge may be traversed in both directions (from source to target and vice versa).

As in database management systems, the elements of graphs of a certain class | e., product management graphs to be discussed below | are declared in a graph schema. Nodes and edges are classi ed into node classes and edge types, respectively. A node class de nes the attributes which its instances will carry. An edge type de nes the classes of source and target nodes and the cardinality of its instances.

Node classes are organized into a multiple inheritance hierarchy. A subclass inherits from its superclasses all attributes and adjacent edge types. Inheritance on edge types is not supported. A graph schema may be represented both textually and graphically.1 displays a graphical schema diagram for product management graphs; later on, we will also use the textual notation as required.

In the diagram, each node class is represented by a box which contains the name of the class and its attributes. Dashed and solid arrows stand for inheritance relationships and edge types, respectively. configuration object graph DOCUMENT_OBJECT CONFIGURATION_OBJECT ––––––––––––––––––––––– is_a Variants : string [0:n] is_a 1 1 OC_Contains OD_Contains n O_Master, n object O_ActsAs OBJECT_COMPONENT O_Dependent OBJECT_DEPENDENCY OBJECT plane –––––––––––––––––––––––––– –––––––––––––––––––––––––– ––––––––––––– 1 n n OC_Variants : string [0:n] 1 OD_Variants : string [0:n] Name : string 1 1 1 1 HasHistory O_HasInstance OC_HasInstance OD_HasInstance n n n version n VERSION V_ActsAs 1 n plane n 1 ––––––––––––––––––– VERSION_COMPONENT VERSION_DEPENDENCY HISTORY VersionNo : integer 1 n n V_Master, n Predecessor, Stable : boolean V_Dependent Successor VC_Contains VD_Contains 1 1 CONFIGURATION_VERSION version graph is_a –––––––––––––––––––––– Graph schema for product management Variant : string [0:1] 9. Management Model: Formal Speci cation is_a configuration version graph DOCUMENT_VERSION –––––––––––––––––– Location : string Locked : boolean DOCUMENT_VERSION node class –––––––––––––––––– edge type inheritance Location : string Locked : boolean attributes 9.2 Product Management Model 197 The graph schema was designed according to the following rules: { Relationships, which were represented as arrows in the gures presented in Section 8.1, are modeled as nodes and adjacent edges (e., a successor rela- tionship is modeled as a HISTORY node and Predecessor/Successor edges).

This solution allows for attaching attributes to relationships, and for estab- lishing relationships between relationships. { Each subgraph of the product management graph is represented by a root node which is connected to all nodes belonging to this subgraph (e., a con- guration version graph is represented by a CONFIGURATION VERSION node which is connected to VERSION COMPONENT and VERSION DEPENDENCY nodes by VC Contains and VD Contains edges, respectively. The graph model is constructed such that subgraphs are mutually disjoint. In particular, we distin- guish between applied occurrences (e., OBJECT COMPONENT) and declarations (e.

{ Apart from HISTORY nodes, each node of the version plane is connected to the corresponding node of the object plane by an (incoming) HasInstance edge. Such a node of the version plane may be regarded as an instance of exactly one node of the object plane. In this way, the re nement relationship between object plane and version plane is represented. Note that this kind of instantiation is user-de ned (on top of PROGRES) and has to be distinguished from PROGRES instantiations (e., a node is an instance of a node class).

More speci cally, the graph schema is structured as follows: { Each OBJECT carries a unique Name attribute. The corresponding version graph contains VERSION and HISTORY nodes. VersionNo identi es a version uniquely among the versions of one object. Stable indicates whether the version may still be modi ed.

Furthermore, a DOCUMENT VERSION carries additional at- tributes Location, which identi es the place where the version contents are stored, and Locked, which indicates whether the version has been reserved for modi cation. { A CONFIGURATION OBJECT may exist in multiple structural variants each of which is a member of the Variants set1. The corresponding con guration ob- ject graph contains OBJECT COMPONENT and OBJECT DEPENDENCY nodes whose attributes indicate the variants to which they belong. Each OBJECT COMPONENT is connected to its corresponding OBJECT by an incoming O ActsAs edge.

{ A CONFIGURATION VERSION is an instance of a speci c structural Variant2. A con guration version graph contains nodes of class VERSION COMPONENT, which are connected to the corresponding VERSION and OBJECT COMPONENT by incoming V ActsAs and OC HasInstance edges, respectively, and nodes of class VERSION DEPENDENCY, each of which has an incoming OD HasInstance edge from the corresponding OBJECT DEPENDENCY. 1 For the sake of simplicity, only a single attribute for characterizing variants is intro- duced in the graph schema. 2 If structural variants are not used, the Variant attribute is absent, and the Variants set of the CONFIGURATION OBJECT is empty.

198 O_HasInstance configuration object graph Fig. 1 : CONFIGURATION Shaft OBJECT OC_Contains OD_Contains OC_Contains OD_Contains OC_Contains 2 : OBJECT O_Master 3 : OBJECT O_Dependent 4 : OBJECT O_Master 5 : OBJECT O_Dependent 6 : OBJECT COMPONENT DEPENDENCY COMPONENT DEPENDENCY COMPONENT Design RawDesign Plan OC_HasInstance OD_HasInstance OC_HasInstance OD_HasInstance OC_HasInstance Design.3 7 : VERSION V_Master 8 : VERSION V_Dependent 9 : VERSION V_Master 10 : VERSION V_Dependent 11 : VERSION COMPONENT DEPENDENCY COMPONENT DEPENDENCY COMPONENT VC_Contains VD_Contains VC_Contains VD_Contains VC_Contains 12 : CONFIGURATION configuration VERSION version graph Shaft.3 Example of a product management graph 9.