Cách mô hình hóa các phụ thuộc giữa các trường trong các hình thức rất phức tạp

Chúng tôi phải tạo một ứng dụng web sẽ được sử dụng làm mẫu đơn đăng ký cho nhiều sản phẩm bảo hiểm (tổng cộng 15). Biểu mẫu ứng dụng này sẽ tương tự như trình hướng dẫn biểu mẫu, nó sẽ trải dài trên nhiều trang, tùy thuộc vào sản phẩm nào trong khoảng từ 4 đến 10.

Tổng cộng tất cả các yếu tố khác nhau (đầu vào, hộp chọn) mà biểu mẫu sẽ hiển thị là khoảng 250, nhưng ngay cả sản phẩm phức tạp nhất cũng sẽ không sử dụng hơn 170 trong số chúng. Ít phức tạp nhất vẫn cần khoảng 80 yếu tố.

Chúng tôi không muốn tạo 15 mẫu đơn khác nhau, mỗi mẫu cho một sản phẩm, chúng tôi muốn có một mẫu đơn sẽ được sử dụng bởi tất cả các sản phẩm.

Bây giờ như bạn có thể tưởng tượng, các yếu tố có rất nhiều phụ thuộc giữa chúng. Một giá trị được nhập vào một trường có thể làm cho một trường hoặc tập hợp trường khác xuất hiện hoặc biến mất (trên trang hiện tại hoặc (các) trang sau). Một số phụ thuộc khác dựa trên các giá trị được nhập:

• giá trị của một yếu tố là bắt buộc hay không
• giá trị có thể cho các hộp chọn sẽ được thay đổi
• các ràng buộc xác nhận sẽ được thay đổi

Như bạn có thể tưởng tượng, mô hình hóa này rất phức tạp. Câu hỏi là, công cụ nào bạn muốn giới thiệu để mô hình hóa (và ghi lại) tất cả các yếu tố này, sự phụ thuộc giữa chúng và các ràng buộc xác nhận? Làm thế nào bạn sẽ làm người mẫu? Không nói về mô hình dữ liệu trong trường hợp này. Mô hình này sẽ là một phần của thông số kỹ thuật về những gì cần được thực hiện và làm tài liệu tham khảo sau khi hoàn thành dự án. Bằng cách thay đổi mô hình, các mẫu đơn sẽ không được tự động thay đổi.

Một số điều chúng tôi muốn có thể thực hiện dễ dàng:

• xem những yếu tố nào một yếu tố nhất định phụ thuộc vào
• xem tất cả các yếu tố trong mẫu cho sản phẩm nhất định
• xem các yếu tố cần thiết cho một sản phẩm nhất định
• xác định quy tắc xác nhận cho từng yếu tố
• xác định các thuộc tính khác nhau cho từng yếu tố

Giới hạn: người quản lý sản phẩm và chủ sở hữu sản phẩm của chúng tôi là những người sẽ thực hiện mô hình.

Đối với một dự án phức tạp tương tự, chúng tôi đã triển khai một trình thông dịch trong lớp doanh nghiệp với các công thức cho "isValid" và "isVisible" cho mọi phần tử biểu mẫu

Đối với trình thông dịch, chúng tôi đã sử dụng Ngôn ngữ ràng buộc đối tượng của UML đã từng được thiết kế cho mục đích đó.

Thật không may, gần như không ai nói "uml-ocl" vì vậy việc tìm ai đó để duy trì các quy tắc là điều khó hiểu.

Nếu chúng ta phải làm điều đó một lần nữa, chúng ta sẽ chọn một ngôn ngữ phổ biến hơn như js / vb-script cho trình thông dịch

Một sự kết hợp của các công cụ có thể giúp quản lý sự phức tạp. Tôi thích bắt đầu với một cách tiếp cận được mô tả nhưng có tính mô tả (khác với cách tiếp cận được chính thức hóa cao) mà con người dễ dàng tương tác. PM nên thoải mái với bảng tính và nó có thể hữu ích cho các phụ thuộc bố cục ở định dạng bảng.

1. Ví dụ: bảng phụ thuộc vào sản phẩm x trường.
2. Bảng thứ hai có thể gói gọn các tương tác giữa các trường (trường x trường). Các ô giao nhau ban đầu có thể chứa văn bản mô tả.

Khi vượt qua lần đầu tiên, điều này có thể phơi bày các vấn đề với logic và / hoặc xác định các cơ hội để đơn giản hóa logic.

Và trong khi các PM có thể né tránh lập trình web trực tiếp, hãy sử dụng công nghệ phía khách hàng hiện đại, biểu cảm để xây dựng "ngôn ngữ" cho ứng dụng của bạn. Các công cụ như angular.js giúp khuyến khích tập trung vào những gì các thành phần làm và giảm thiểu mã tiếng ồn. Công nghệ web phù hợp cũng sẽ cung cấp hỗ trợ kiểm tra tốt.

Câu hỏi là, công cụ nào bạn muốn giới thiệu để mô hình hóa (và ghi lại) tất cả các yếu tố này, sự phụ thuộc giữa chúng và các ràng buộc xác nhận? Làm thế nào bạn sẽ làm người mẫu?

Chúng tôi đã có một dự án tương tự. Các hình thức rất phức tạp, và rất nhiều trong số họ.

• Các mẫu giấy gốc
  • Mục tiêu của chúng tôi là làm cho các trang web trông giống hệt như chúng
• Excel
  • Đặc tả dữ liệu màn hình-phần tử
  • Tên thành phần dữ liệu (rất quan trọng trong quá trình mã hóa) loại, độ dài, định dạng, quy tắc chung
• Kiến trúc sư doanh nghiệp
  • Thiết kế lớp cơ bản qua UML.

Kiến trúc sư doanh nghiệp (EA)

Đây là một liên kết.

Vòng loại: đã vài năm kể từ lần cuối tôi sử dụng nó. Một công cụ phức tạp. Đường cong học tập lớn. Kiến thức UML rất tốt cần có cho kết quả chính xác; có siêu dữ liệu đằng sau mọi thứ . Do đó, chức năng EA rộng, sâu, bí ẩn và đôi khi kỳ quặc.

EA tích hợp các đồ tạo tác của nó rất tốt. Nhưng kiến ​​thức về công cụ UML và EA tập thể của các nhóm chúng tôi không đủ để biến nó thành một công cụ đầu cuối thỏa đáng. Lưu ý rằng mục tiêu của chúng tôi là không sử dụng nó theo cách đó. Mặc dù vậy, tốt hơn là không sử dụng (một số khía cạnh) của công cụ hơn là sử dụng nó một cách tồi tệ.

Mỗi nhà phát triển đã sử dụng nó để thiết kế các lớp cho biểu mẫu được chỉ định của mình (hoặc phần của nó). Nhà phân tích kinh doanh đã sử dụng nó để tạo sơ đồ ca sử dụng. Không sử dụng nó để phân tích yêu cầu vì các biểu mẫu giấy, dữ liệu biểu mẫu và quy trình đã được thiết lập tốt - và được thực hiện trước khi chúng tôi áp dụng EA.

Chúng tôi không bao giờ phải tận dụng công cụ toàn diện này có lời hứa tích hợp từ phân tích yêu cầu đến mã thực tế. Các nhà phát triển chỉ học đủ để tạo ra các sơ đồ trình tự và lớp thô sơ cần thiết để quản lý phê duyệt mã đi. Và rõ ràng với tôi rằng ngay cả khi tôi tạo shell-code từ các sơ đồ lớp, nó quá khó (nghĩa là thiếu kiến ​​thức UML chi tiết), quá bất tiện, quá tẻ nhạt để giữ EA đồng bộ với phát triển mã. Vì vậy, ngay khi chúng tôi bắt đầu mã hóa các sơ đồ UML rất nhanh chóng trở nên lỗi thời và bị bỏ qua.

Các sơ đồ trình tự tốt là vô giá để hiểu sự tương tác của lớp và khởi tạo đối tượng. Một bản đồ cấp cao đẹp khi mã hóa.

Cảnh báo

Thiết kế miền kinh doanh đầy đủ và (thích hợp) là FAR quan trọng hơn bất kỳ công cụ nào. Tôi nhận được PTS chỉ nghĩ về cách phổ biến & * $ & # mã của chúng tôi ngoại trừ lần rất hiếm khi chúng tôi thực hiện một mô hình kinh doanh tốt. Tôi có thể viết các trang và các trang.