Biểu đồ ngữ cảnh hoạt động

Cách bổ sung biểu đồ ngữ cảnh hệ thống và giúp bạn thiết kế các khía cạnh kỹ thuật của một hệ thống

Trong nhiều năm, các kiến trúc sư và các nhà phân tích ứng dụng đã sử dụng biểu đồ ngữ cảnh hệ thống (System Context Diagram - SCD) như một công cụ mạnh để chia sẻ khung nhìn mức cao của một hệ thống. SCD cung cấp chỉ một khung nhìn chức năng của hệ thống, một khung nhìn mà sau này dẫn đến mô hình ca sử dụng. Để xác định toàn bộ hệ thống theo sự phát triển, các yêu cầu không chức năng phải được tính đến. Các NFR tạo một khung nhìn khác về ngữ cảnh của hệ thống: biểu đồ ngữ cảnh hoạt động, sau đó chuyển tiếp tới mô hình hoạt động. Trong bài viết này, hãy tìm hiểu về một kỹ thuật để bổ sung SCD với một biểu đồ ngữ cảnh hoạt động hướng không chức năng.

Vito Losacco, Kiến trúc sư quản trị CNTT, IBM

Vito Losacco photoVito Losacco là một kiến trúc sư quản trị CNTT với các hệ thống công nghệ toàn cầu của IBM ở Italia. Sau tám năm làm việc tại các phòng thí nghiệm phát triển của Rome, năm 1998 ông tham gia vào IGS với các vai trò kỹ thuật và lãnh đạo trong các dự án của khách hàng lớn, tập trung vào các hoạt động CNTT và các thiết kế của các giải pháp kiến trúc cơ sở hạ tầng. Ông hiện đang có vị trí kỹ thuật trước bán hàng như là ITSA của các cam kết lớn, cam kết giữa ngành công nghiệp và giữa các LOB. Vito đã là một người phát ngôn tại Hội nghị II về an ninh toàn cầu của IBM năm 2003 và người phát ngôn của TLE trong năm 2008



06 11 2009

Giới thiệu

Chúng ta đã luôn luôn muốn tính đơn giản của một biểu đồ ngữ cảnh hệ thống (SCD). Bạn có thể vẽ nó ở phía trước một khách hàng và chỉ trong vài phút đạt tới một sự hiểu biết chung về phạm vi của một dự án, các vai và thậm chí cả các ca sử dụng chính mà hệ thống đã thể hiện.

Nếu chúng ta là các nhà báo và phải mô tả các tin tức thay cho một hệ thống, SCD của chúng ta trả lời Ai và, như lát cắt đầu tiên, Cái gì. Nhưng, SCD sẽ không trả lời các câu hỏi Ở đâu, Khi nào, Như thế nào và Bao nhiêu. Nếu không có các thông tin này ngữ cảnh hệ thống của chúng ta chỉ định nghĩa được một phần.

Nhiệm vụ phân tích ban đầu phải tập trung vào chỉ nội dung chức năng. Ngay cả kiến trúc chức năng có thể bị ảnh hưởng bởi cách giải quyết các yêu cầu không chức năng (NFRs). Không có sự khác biệt nào về khái niệm giữa các yêu cầu chức năng và không chức năng, vì cả hai đều là các biểu hiện của động lực theo một trong các bên liên quan, hoặc những người có ảnh hưởng, trong hệ thống theo định nghĩa.

Xem Tài nguyên để biết thêm thông tin về các mô hình động lực kinh doanh.

Rozanski và Woods phân loại các bên liên quan khác nhau, những người quan tâm đến một hệ thống công nghệ thông tin (CNTT) như:

Những người thu nhận
Giám sát việc đấu thầu hệ thống hoặc sản phẩm.
Những người định giá
Giám sát sự thông nhất của hệ thống theo các tiêu chuẩn và quy định của pháp luật.
Những người truyền đạt
Giải thích về hệ thống cho các các bên liên quan khác về các tài liệu hướng dẫn và các tài liệu đào tạo.
Các nhà phát triển
Xây dựng và triển khai hệ thống từ đặc tả kỹ thuật (hoặc lãnh đạo các nhóm thực hiện như vậy).
Các nhà bảo trì
Quản lý sự tiến triển của hệ thống khi nó đang hoạt động.
Các nhà cung cấp
Xây dựng hoặc cung cấp phần cứng, phần mềm hoặc cơ sở hạ tầng mà hệ thống sẽ chạy trên đó.
Nhân viên hỗ trợ
Cung cấp sự hỗ trợ cho những người sử dụng sản phẩm hoặc hệ thống khi nó đang chạy.
Các nhà quản trị hệ thống
Vận hành hệ thống khi nó đã được triển khai.
Các nhà thử nghiệm
Thử nghiệm hệ thống để đảm bảo nó thích hợp để sử dụng.
Những người dùng
Xác định các chức năng hệ thống và cuối cùng bắt đầu sử dụng nó.

Tại nơi đặt một khung công tác Enterprise Architecture (EA - Kiến trúc doanh nghiệp), các yêu cầu của các bên liên quan đã được xác định trong chính EA. Chúng nên được tính đến như là đầu vào chính. Nếu không, việc phỏng vấn các bên liên quan có thể là một cách tốt để nắm bắt các nhu cầu của họ. Các nhu cầu cần được phân loại theo chức năng hoặc các NFR. Các NFR nên được phân loại theo các đặt tính (mục tiêu) và các ràng buộc (đã cho). Các đặt tính không chức năng có thể được các bên liên quan xếp loại theo tầm quan trọng cảm nhận được của chúng (từ VH = Rất cao đến VL = Rất thấp).


Phân loại các yêu cầu

Nhiều nguyên tắc phân loại đã được đề xuất để tổ chức các NFR: các đặt tính thời gian chạy và thời gian không chạy, các ràng buộc kinh doanh và kỹ thuật, phạm trù ISO9126, v.v. Bài viết này sử dụng một sự phân loại hơi khác một sự phân loại dựa trên khái niệm "nhu cầu chính".

Theo cách tiếp cận của chúng ta, các NFR là những gì mà các bên liên quan cần từ hệ thống theo thiết kế. Các yêu cầu đó sẽ tạo hình hệ thống từ điểm hoạt động của khung nhìn. Mỗi yêu cầu có thể được một số lớp của các bên liên quan thể hiện, nhưng nó thường đến từ một nguồn chính. Ví dụ, một đối tượng "các trang mỗi giây" là một yêu cầu cho:

  • Những người thu nhận, những người phải tính đến và xác minh nó trong quá trình mua sắm.
  • Các nhà phát triển và các nhà bảo trì, những người phải tiếp cận và duy trì đích được thiết lập.
  • Các nhà quản trị hệ thống, những người phải theo dõi và đo hiệu năng thời gian chạy.

Tuy nhiên, ngay cả khi hình như rất kỹ thuật, nhu cầu các trang mỗi giây cuối cùng được bắt nguồn từ Số lượng các giao dịch kinh doanh cho mỗi nhân viên lễ tân, một dòng về nghiệp vụ (LOB) hoặc người sử dụng cần.

Theo như một hướng dẫn, chúng ta sẽ sử dụng các phân loại sau cho các NFR:

Phụ thuộc vào vai
Các yêu cầu đại diện cho các nhu cầu của những người sử dụng hệ thống (con người hay không) và có thể được tiếp tục phân loại như:
  • Người sử dụng hay các hệ thống bên ngoài cần các đặc tính hệ thống tương tác với hệ thống, như được trình bày trong SCD.
  • Người quản lý dịch vụ CNTT đòi hỏi các đặc tính hệ thống, ví dụ như một tập của các vai chuyên ngành (con người và hệ thống) quản lý các hoạt động của hệ thống theo thiết kế.

Các vai có thể yêu cầu một NFR trở thành một sự ràng buộc của vai, mà hệ thống phải tuân theo. Hãy suy nghĩ về các sự ràng buộc như là các NFR không thể đàm phán (mặc dù đôi khi chúng có thể bị loại bỏ).

Độc lập với vai
Các yêu cầu hệ thống đại diện cho các đặc tính hệ thống không thể bám chặt vào một vai nhưng vào một trong những bên liên quan khác. Một số các NFR có thể thuộc về cả hai các loại vai phụ thuộc lẫn vai độc lập cùng một lúc. Ví dụ, an ninh đồng thời có thể là một yêu cầu cho một lớp người sử dụng cụ thể và một chuẩn cho doanh nghiệp.

Các NFR độc lập với vai mà hệ thống phải tuân theo có thể trở thành các ràng buộc của độc lập với vai.

Nói chung, các NFR có thể được xếp loại bởi tầm quan trọng cảm nhận được của các bên liên quancủa chúng, cho cả hai loại, nhưng các ràng buộc sẽ được xác định thông qua một câu lệnh (như chuẩn hoặc quy định được đáp ứng).

Sự phân loại này có lợi thế của kiểu gõ trực tiếp vào SCD và do đó cho phép, như bạn sẽ thấy sau này, một sự biểu diễn tương tự.


Lĩnh vực của các NFR

Điểm khởi đầu trong danh sách các NFR là quy tắc phân loại ISO 9126. Do mục đích cuối cùng là xây dựng một biểu đồ ngữ cảnh hoạt động để điều khiển sự phát triển của mô hình hoạt động (OM) của hệ thống, các sửa đổi sau đây đã được thực hiện theo danh sách ISO 9126.

  • Để đơn giản, thường sử dụng Sự đáng tin cậy như là sự kết hợp của:
    • Tính chắc chắn.
    • Có khả năng khôi phục lại.
    • Khả năng chịu lỗi.

    Thường sử dụng Tính tiện lợi như là tập của:

    • Tính học được.
    • Tính hiểu được.
    • Tính hấp dẫn.
  • Đã bỏ tính thực dụng và tính tương tác (mà đơn giản xác định rằng một hệ thống bên ngoài là một vai của SCD của chúng ta), do cả hai đều có tác động rất ít đối với việc định nghĩa của OM.

    Đã bỏ tính ổn định, tính dễ thay đổi và tính thay thế, do cùng một lý do.

  • Sự tuân thủ an ninh được bổ sung như là một yếu tố quan trọng cho các thiết kế hệ thống hiện nay.
  • Bổ sung một tập các ràng buộc có liên quan đến kinh doanh để phân loại các đầu vào của LOB có thể ảnh hưởng đến OM:
    • Các chính sách kinh doanh (chính sách hành vi kinh doanh là các ràng buộc có liên quan đến quyết định kinh doanh của LOB, ví dụ sự hỗ trợ khách hàng theo nhiều kênh).
    • Lĩnh vực kinh doanh (các chính sách cấu trúc kinh doanh là các ràng buộc trực tiếp dẫn đến từ các chính sách của ngành công nghiệp hoặc các chính sách về lĩnh vực, chẳng hạn như giờ mở cửa cho các cửa hàng).
    • Lịch biểu/Ngân sách đề cập đến các ràng buộc về tài chính của dự án.
    • Các vị trí là các ràng buộc về các vị trí phải được hệ thống phục vụ.

    Danh sách này có thể được mở rộng, phụ thuộc vào dự án.

Thu thập các NFR

Do ngữ cảnh hoạt động, như là ngữ cảnh hệ thống, sẽ được xác định rất sớm trong quá trình phân tích, đừng trông đợi các mục tiêu định lượng chính xác cho hầu hết các NFR -- chỉ cần các định tính.

Khi thu thập thông tin từ các bên liên quan, bạn có thể cần cung cấp khung nhìn, định lượng nhiều hơn mặc dù là nhân tạo, của các yêu cầu để tránh tất cả các NFR bị đánh giá là Rất cao. Khi sử dụng hiệu năng như là một ví dụ, bạn có thể yêu cầu các bên liên quan xem thời gian đáp ứng chấp nhận được sẽ thấp hơn một giây, thấp hơn hai giây, v.v không. Với tính sẵn sàng, câu hỏi có thể là liệu hệ thống phải sẵn sàng 24x7, 24x6 hay 12x6 không.

Điều quan trọng là phải hiểu rằng bạn có thể sử dụng chỉ các giá trị đại diện, tùy thuộc vào kiểu hệ thống theo thiết kế. Để cho kiến trúc sư CNTT đưa ra như là một tập đại diện của các giá trị. Việc định lượng các NFR thực sẽ diễn ra sau trong chu trình thiết kế (trừ khi các yêu cầu này là các ràng buộc thực sự cho hệ thống).

Danh sách kết quả của các NFR, thể hiện trong Hình 1, có thể được dùng để tập các nhu cầu của các bên liên quan.

Hình 1. Phân loại các NFR
Phân loại/phác thảo các yêu cầu không theo chức năng

Các bên liên quan được tổ chức thành ba nhóm chính:

  • Các vai SCD.
  • Các bên liên quan, người tương tác với các vật phẩm của hệ thống (thời gian chạy hay thời gian phát triển), như là các nhà phát triển.
  • Các bên liên quan, người tương tác chỉ với quá trình giới thiệu hệ thống trong ngữ cảnh kinh doanh, như là những nhà định giá.

Những yếu tố đầu vào đó sẽ được hợp nhất trong bảng trong Hình 2, bảng này trình bày ma trận các NFR của hệ thống và bố trí biểu diễn biểu đồ ngữ cảnh hoạt động.

Hình 2. Ma trận các NFR của hệ thống
Ma trận các NFR của hệ thống

Hãy xem cách kiến trúc sư trưởng của chúng ta có thể khai thác biểu đồ ngữ cảnh hoạt động và ma trận các NFR hệ thống để cung cấp một khung nhìn chưa xác định công nghệ đầu tiên của kiến trúc hoạt động. Nếu công việc mô hình hóa thành phần không có sẵn, các kỹ thuật khác như Ma trận các yêu cầu xung đột không thể sử dụng được.


Biểu đồ ngữ cảnh hoạt động

Biểu đồ ngữ cảnh hoạt động là điểm khởi đầu để thiết kế các khía cạnh kỹ thuật của hệ thống. Để giúp giải thích các khái niệm, kịch bản sau đây bao gồm một công ty giả định bắt nguồn từ một việc kinh doanh bất động sản, như trong Hình 3.

Hình 3. Biểu đồ ngữ cảnh hệ thống mua nhà
Biểu đồ ngữ cảnh hệ thống mua nhà

Khách hàng muốn bắt đầu một khả năng mua nhà, với khả năng cung cấp mọi dịch vụ đơn lẻ theo một số cách: tổng đài điện thoại, Internet hoặc trong quầy hàng.

Môi trường công ty bao gồm một văn phòng chính và một nhà kho tại một địa điểm riêng biệt. Tổng đài điện thoại thuê ngoài.

Kiến trúc sư trưởng thu thập các NFR từ các bên liên quan, dẫn đến các bảng trong Hình 4. Chỉ có nguồn chính với một yêu cầu nhất định được hiển thị.

Hình 4. Ví dụ về các đáp ứng của các bên liên quan
Ví dụ về các đáp ứng của các bên liên quan

Các đáp ứng sau đó đã được hợp nhất vào trong ma trận các NFR hệ thống trong Hình 5.

Hình 5. Ví dụ về ma trận các NFR hệ thống
Ví dụ về ma trận các NFR hệ thống

Bảng trên cho thấy rằng các bên liên quan đã gán tầm quan trọng tương đối cho các yêu cầu. Một số trong chúng cũng đã được phân loại như là các ràng buộc hệ thống.

Biểu đồ ngữ cảnh hoạt động trong Hình 6 biểu thị các thông tin giống nhau trong một bản vẽ đồ họa. Chỉ các yêu cầu có tầm quan trọng Cao và Rất cao được hiển thị. Các đặc tính (màu đỏ) và các ràng buộc (màu xanh dương) được kết nối với các vai có nguồn gốc hoặc đến ranh giới của hệ thống, trong trường hợp chúng là chung cho tất cả các vai. Các đặc tính và các ràng buộc không bắt nguồn từ một vai cụ thể được xếp thẳng hàng ở bên trái của hình như là các đặc điểm của hệ thống.

Hình 6 cho thấy một cách ngắn gọn các kỳ vọng khác nhau mà các vai phải có về hệ thống. Biểu đồ ngữ cảnh hoạt động là một sự trợ giúp rất tốt để giải thích và xác nhận sự phức tạp của hệ thống đối với khách hàng. Ví dụ, với cả Internet và các quán hàng, tính tiện lợi là một mối quan tâm chính và sẽ có thể yêu cầu một giao diện kênh cụ thể, trong khi các hoạt động 24x7 là một sự ràng buộc chỉ với tùy chọn Internet.

Hình 6. Biểu đồ ngữ cảnh hoạt động mua nhà
Biểu đồ ngữ cảnh hoạt động mua nhà

Kiến trúc sư trưởng bây giờ có thể khai thác biểu đồ ngữ cảnh hoạt động và ma trận các NFR hệ thống để cung cấp một khung nhìn công nghệ trung lập đầu tiên của kiến trúc hoạt động.

Đặc tính của vai cụ thể có liên quan đến các NFR chuyển thành các yêu cầu trên các nút khái niệm hỗ trợ cho vai đó. Thông thường, điều này bao gồm nhiều nút và một số nút phải hỗ trợ nhiều hơn một kiểu vai. Tất nhiên, việc đòi hỏi nhiều hơn các yêu cầu áp dụng cho các nút chung.

Việc sử dụng thông tin được cung cấp với các điều kiện cần thiết của các Vị trí và một số các ràng buộc về kết nối, bạn có thể dự thảo một sự phân vùng ban đầu cho các thành phần hạ tầng chính của hệ thống. Bạn biết nơi đặt các nút khái niệm, mà cuối cùng sẽ lưu trữ các thành phần hỗ trợ các chức năng mức ứng dụng:

  • Vị trí thời gian chạy trung tâm của hệ thống sẽ lưu trữ các dịch vụ ứng dụng chính (CN_App Svcs) cần một dịch vụ tích hợp AAA để tái sử dụng hệ thống AAA hiện có (một sự ràng buộc đã nêu) và một giao diện dịch vụ tích hợp (CN_Old WH Interface Svc) để cho phép sự tương tác với giao diện hiện có của kho hàng.
  • Đại diện cửa hàng, người sử dụng Internet và Tổng đài điện thoại yêu cầu các giao diện kênh cụ thể, tiện lợi rất cao, đề xuất sự phân tách hệ thống.

    Có lẽ chấp nhận một công nghệ khác nhau cho biểu diễn các giao diện theo thứ tự.

  • Hãy xem xét một nút khái niệm, cho phép dịch vụ quản lý, để đáp ứng yêu cầu hoạt động cao cho vai của nhà quản lý dịch vụ CNTT
  • Tổng đài điện thoại, tại một địa điểm ở xa có kết nối tin cậy thấp, đòi hỏi các hiệu năng Rất cao. Nó có thể được hỗ trợ bằng cách lưu trữ nhanh các bản sao cục bộ của dữ liệu 'khó thay đổi' (tương tự như các mô tả và hình ảnh của một danh mục) thông qua một hệ thống riêng.
  • Để đảm bảo khả năng tương tác với hệ thống thẻ tín dụng, bạn cần thêm các nút theo khái niệm cổng chuyên dụng.

Hình 7 cho thấy kiến trúc hoạt động khái niệm kết quả của hệ thống của chúng ta.

Hình 7. Một lát cắt đầu tiên của kiến trúc hoạt động
Một lát cắt đầu tiên của kiến trúc hoạt động

Bắt đầu từ khung nhìn này và với đầu vào từ mô hình thành phần mức ứng dụng, kiến trúc sư CNTT cơ sở hạ tầng trực tiếp đưa vào chi tiết mô hình hoạt động cuối cùng của hệ thống, như sau.

  • Các nút có độ tin cậy được đặt tới Cao hoặc Rất cao sẽ hàm ý hạ tầng được co cụm hoặc cân bằng.
  • Nhu cầu hiệu năng sẽ yêu cầu các kết nối và các máy chủ thích hợp từ đầu đến cuối.
  • Các yêu cầu cho một hệ thống an ninh cao, vì thế bạn phải "bịt kín", với một nhà cung cấp an ninh, tất cả các giao diện bên ngoài (các mạng Internet và mạng bên ngoài như các cơ quan tín dụng hoặc công ty tổng đài điện thoại) và các giao diện với các khu vực không an toàn của mạng nội bộ, chẳng hạn như nhà kho và các cửa hàng.
  • Đích sử dụng nguồn tài nguyên sẽ đòi hỏi một hoạt động lập kế hoạch phù hợp trong các giai đoạn sau.

Bằng cách sử dụng các đặc tả kỹ thuật của các NFR tại mức vai hệ thống, cách tiếp cận này chỉ ra những nét chính trong bài viết này cho phép tạo hình cơ sở hạ tầng chính xác hơn. Bạn có thể tránh, ví dụ, cung cấp các tài nguyên mà không chứng minh bằng các nhu cầu thực tế của một vai.


Kết luận

Trong bài viết này bạn đã học về kỹ thuật để bổ sung một biểu đồ ngữ cảnh hệ thống nổi tiếng với một biểu đồ ngữ cảnh hệ thống có định hướng không theo chức năng.

Biểu đồ ngữ cảnh hoạt động là điểm khởi đầu để thiết kế các khía cạnh kỹ thuật của hệ thống, bao gồm cả cơ sở hạ tầng hỗ trợ.


Lời cảm ơn

Các tác giả cảm ơn Philippe Binet, kỹ sư xuất sắc của IBM GTS tại Ý, Piero Sguazzero, kỹ sư xuất sắc của IBM SWG tại Ý và Raffaele pullo, Kiến trúc sư CNTT chấp hành của IBM GTS tại Ý, về sự động viên và các ý kiến có giá trị của họ cho bài viết này.

Tài nguyên

Học tập

Lấy sản phẩm và công nghệ

  • Tải về phiên bản đánh giá sản phẩm IBM và nhận được các bài thực hành của bạn trên các công cụ phát triển ứng dụng và các sản phẩm phần mềm trung gian từ DB2®, Lotus®, Rational®, Tivoli® và WebSphere®.

Thảo luận

Bình luận

developerWorks: Đăng nhập

Các trường được đánh dấu hoa thị là bắt buộc (*).


Bạn cần một ID của IBM?
Bạn quên định danh?


Bạn quên mật khẩu?
Đổi mật khẩu

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Ở lần bạn đăng nhập đầu tiên vào trang developerWorks, một hồ sơ cá nhân của bạn được tạo ra. Thông tin trong bản hồ sơ này (tên bạn, nước/vùng lãnh thổ, và tên cơ quan) sẽ được trưng ra cho mọi người và sẽ đi cùng các nội dung mà bạn đăng, trừ khi bạn chọn việc ẩn tên cơ quan của bạn. Bạn có thể cập nhật tài khoản trên trang IBM bất cứ khi nào.

Thông tin gửi đi được đảm bảo an toàn.

Chọn tên hiển thị của bạn



Lần đầu tiên bạn đăng nhập vào trang developerWorks, một bản trích ngang được tạo ra cho bạn, bạn cần phải chọn một tên để hiển thị. Tên hiển thị của bạn sẽ đi kèm theo các nội dung mà bạn đăng tải trên developerWorks.

Tên hiển thị cần có từ 3 đến 30 ký tự. Tên xuất hiện của bạn phải là duy nhất trên trang Cộng đồng developerWorks và vì lí do an ninh nó không phải là địa chỉ email của bạn.

Các trường được đánh dấu hoa thị là bắt buộc (*).

(Tên hiển thị cần có từ 3 đến 30 ký tự)

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Thông tin gửi đi được đảm bảo an toàn.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=70
Zone=Rational
ArticleID=444910
ArticleTitle=Biểu đồ ngữ cảnh hoạt động
publish-date=11062009