Nghiên cứu triển khai dịch vụ VPN,MPLS

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ VĂN THỊ HỒNG PHÚC NGHIÊN CỨU KỸ THUẬT KIỂM THỬ PHẦN MỀM TRÊN CƠ SỞ MƠ HÌNH UML LUẬN VĂN THẠC SĨ Hà Nội - 2009 MỤC LỤC Chương 1: Giới thiệu 1.1 Giới thiệu nhiệm vụ đề tài 1.2 Tình hình nghiên cứu nước .2 1.3 Mục tiêu luận văn .3 Chương 2: Một số khái niệm 2.1 Phần mềm sử dụng cấu phần 2.1.1 Chuẩn tương tác [3] 2.1.2 Chuẩn kết hợp [3] 2.2 Vòng đời phát triển phần mềm sở cấu phần .9 2.3 Các mơ hình cấu phần dịch vụ cấu phần 12 2.3.1 Mơ hình cấu phần 12 2.3.2 Sự cài đặt mô hình cấu phần dịch vụ 16 2.4 UML phát triển phần mềm 19 2.4.1 Mục tiêu UML 19 2.4.2 Vai trị, vị trí lược đồ UML vòng đời phần mềm .21 2.4.3 Các công cụ xây dựng UML 22 2.5 Lý thuyết kiểm thử 24 2.5.1 Tại kiểm thử cần thiết? [2] 24 2.5.2 Nguyên nhân gây lỗi phần mềm 25 2.5.3 Vai trò kiểm thử phát triển phần mềm 28 Chương 3: Kiểm thử sở mô hình UML 34 3.1 Các thành phần cấu phần 34 3.2 UML kiểm thử 35 3.3 Kiểm thử phần mềm sở cấu phần 42 3.4 Các khía cạnh kiểm thử 46 3.3.1 Khía cạnh cấu trúc kiểm thử 47 3.3.2 Khía cạnh hành vi kiểm thử 48 3.5 Mơ hình kiểm thử phần mềm cấu phần [5] 50 3.4.1 Mơ hình tương tác 50 3.4.2 Mơ hình hành vi .51 3.4.3 Cấu trúc điều khiển 52 3.4.4 Các quan hệ tương tác liệu 52 3.6 UML pha kiểm thử tích hợp 53 3.5.1 Mơ hình áp dụng cho kiểm thử tích hợp phần mềm cấu phần 55 3.5.2 Các tiếp cận kiểm thử tích hợp sở UML .58 Chương 4: Thực nghiệm kiểm thử phần mềm 64 4.1 Sử dụng cấu phần Text Java 64 4.2 Bài toán ( Phát biểu) 66 4.3 Quy trình xây dựng tài liệu kiểm thử dựa mơ hình UML 67 4.4 Mơ hình xây dựng use-case với toán thực tế 67 4.4.1 Xây dựng luồng nghiệp vụ sở cách tiếp cận mơ hình cộng tác/tuần tự .68 4.4.2 Quản lý kho 70 4.4.3 Xây dựng chương trình 94 4.4.4 Các bước thực chương trình 96 4.4.5 Xây dựng tình kiểm thử 97 Kết luận 103 Tóm tắt kết đạt 103 Tồn hướng phát triển 104 Tài liệu tham khảo 106 DANH MỤC HÌNH # Tên danh mục hình Hình 1: Các phần tử mơ hình cấu phần Hình 2: Chuẩn đặc tả miền Hình 3: Các tình phát sinh lỗi q trình ph phần mềm Hình 4: Chi phí sửa lỗi qua giai đoạn phát triển Hình 5: Cấu trúc cầu phần Hình 6: Quy trình kiểm thử cấu phần hệ thống Hình 7: Lược đồ biểu diễn cấu trúc ca kiểm thử Hình 8: Lược đồ biểu diễn use case quản lý giao dị Hình 9: Mơ hình biểu diễn cấu trúc hồ sơ kiểm thử Hình 10: Các khái niệm liên quan đến tình kiểm 10 Hình 11: Các khái niệm liên quan đến hành vi kiểm thử 11 Hình 12: Các khái niệm liệu hồ sơ kiểm thử 12 Hình 13: Tập điều kiện kiểm tra phụ thuộc 13 Hình 14: Mơ hình cộng tác mơ tả hoạt động giao dịch c 14 ATM Hình 15: Mơ hình mơ tả giao dịch ATM 15 Hình 16: Mơ hình trạng thái phục vụ máy ATM 16 Hình 17: Mơ hình cấu phần phục vụ giao dịch gửi/rút t 17 Hình 18: Cây cấu phần JtextComponent 18 Hình 19: Ví dụ xây dựng javabean 19 Hình 20: Mơ hình use case mơ tả tốn phát biểu 20 Hình 21: Mơ hình cộng tác - tốn thực tế 21 Hình 22: Mơ hình - tốn thực tế DANH MỤC BẢNG # Bảng Tên So sánh vòng đời ph Bảng phần với vòng đời p Các yếu tố tr Bảng UML hỗ trợ loại THUẬT NGỮ SỬ DỤNG TRONG TÀI LIỆU Thuật ngữ QTDA CNPM CBSE ADT UML Pro So Co en Re Di Ap Int Ab Un OMG COM CSLC RTE Ob Co Co Re IDL HTTP XML IDE SUT DF Int Hy eX Int en Qu Op Co Co Ob arc Sy De DW De RM-ODP APIs QoS HĐH CIG COTs OMA LỜI CẢM ƠN Trước hết xin gửi lời cảm ơn đặc biệt tới PGS.TS Đặng Văn Đức viện Công nghệ thông tin người định hướng đề tài tận tình hướng dẫn bảo tơi suốt q trình thực luận văn cao học Tôi xin gửi lời cảm ơn sâu sắc tới Trung tâm Đào tạo Sau đại học thầy cô giáo Khoa Công nghệ thông tin, Trường Đại học Quốc Gia Hà Nội tận tình giảng dạy truyền đạt kiến thức, kinh nghiệm quý báu suốt năm học Cao học Tơi xin bày tỏ lịng cảm ơn chân thành tới tất bạn bè, thầy cô giáo, đồng nghiệp Khoa Công nghệ thông tin, Trường Đại học Quốc Gia Hà Nội động viên, tạo điều kiện cho suốt thời gian thực luận văn Cuối tơi xin dành tình cảm biết ơn tới Bố, Mẹ, người luôn bên cạnh tôi, động viên, chia sẻ suốt thời gian học cao học trình thực luận văn cao học Hà Nội, ngày 30 tháng năm 2009 Văn Thị Hồng Phúc LỜI CAM ĐOAN Tôi xin cam đoan: Luận văn “Nghiên cứu kỹ thuật kiểm thử phần mềm sở mô hình UML” cơng trình nghiên cứu riêng tơi Các kết nghiên cứu luận văn trung thực Nếu sai tơi xin hồn tồn chịu trách nhiệm Hà Nội, ngày 30 tháng năm 2009 Học viên Văn Thị Hồng Phúc Chương 1: Giới thiệu 1.1 Giới thiệu nhiệm vụ đề tài Kiểm thử khâu khơng thể thiếu q trình phát triển phần mềm Nhiều hệ thống phần mềm thất bại khơng tìm lỗi Nguồn lực sử dụng cho khâu kiểm thử yêu cầu lớn trình phát triển phần mềm Quá trình kiểm thử yêu cầu số pha kết hợp gồm: kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử hệ thống, kiểm thử chấp nhận Quy trình kiểm thử xây dựng nhằm đạt mục tiêu sau: Xem xét yêu cầu đưa khách hàng, đối chiếu với sản phẩm phần mềm lập trình lập trình viên  Phát sai sót lỗi phần mềm mà hành vi phần mềm không đúng, không tuân theo đặc tả Phương pháp hướng đối tượng (Object-Oriented) thể rõ tính ưu việt phát triển phần mềm Trong đó, tính đóng gói, trừu tượng hóa tính sử dụng lại làm tăng chất lượng phần mềm Theo Paul Allen có đến 70% hệ thống phần mềm phát triển dựa sở cấu phần Các cấu phần thường phát triển theo hướng đối tượng viết ngôn ngữ khác nhau, chạy môi trường khác nhau, phân tán khắp nơi người phát triển phần mềm không cung cấp mã nguồn Các đặc tính nguyên nhân gây nhiều khó khăn việc kiểm thử hệ thống phần mềm Để tăng tính mềm dẻo nhìn nhận chức năng, đặc điểm phần mềm xây dựng, sử dụng ngơn ngữ mơ hình hóa chuẩn UML Ngơn ngữ mơ hình hóa thống (UML – Unified Modeling Language) công nhận chuẩn công nghiệp cho việc phân tích thiết kế hệ thống hướng đối tượng UML cung cấp ký pháp biểu đồ thể thơng tin thiết kế góc độ nhìn hệ thống Trong năm gần đây, có nhiều nghiên cứu sử dụng mơ hình UML nguồn thông tin đầu vào cho kiểm thử phần mềm Thí dụ, biểu đồ trạng thái UML sử dụng biểu diễn hành vi bên đối tượng thành phần, biểu đồ tương tác được ứng dụng kiểm thử tương tác lớp cấu phần Biểu đồ hoạt động biểu diễn quan hệ thành phần cấu phần Thực tế cho thấy phương pháp Phát triển phần mềm theo cấu phần làm giảm chi phí dự án phát triển phần mềm So với công nghệ truyền thống chuẩn, công nghệ phần mềm sở cấu phần quan tâm đến cách xây dựng phần mềm nhiều Thông qua việc sử dụng lại cấu phần, vòng đời phát triển phần mềm rút ngắn lại, đồng thời tăng tính mềm dẻo sử dụng  bảo trì phần mềm Hơn nữa, phát triển phần mềm có khả làm tăng chất lượng phần mềm Với tầm quan trọng trên, có nhiều kết nghiên cứu lý thuyết sản phẩm công cụ hỗ trợ phát triển phần mềm sở cấu phần Nội dung luận văn nhằm mục tiêu khảo sát vấn đề kỹ thuật phát triển phần mềm theo cấu phần Đặc biệt luận văn tập trung vào kỹ thuật kiểm thử phần mềm phát triển dựa theo cấu phần với mục đích hướng tới ứng dụng thực tế Việt Nam 1.2 Tình hình nghiên cứu nước Năm 1975 Freed Brooks, nhà quản lý dự án IBM, viết The Mythical Man-month Bài luận ngắn trong sách mô tả khó khăn phát triển phần mềm phức tạp, Brooks viết chương với tiêu đề “No Silver Bullet” giải thích hệ thống phần mềm phức tạp Ơng dự đốn khơng có kỹ thuật – no silver bullet – mà cải thiện suất theo danh sách yêu cầu cho hệ thống Trong chương này, Brooker trích dẫn lý gây nên “khủng hoảng phần mềm”, khủng hoảng tiếp tục kỹ thuật công nghệ phần mềm sở cấu phần (CBSE – Component based software engineering) trở nên có tính khoa học thực dựa tính khoa học Và thế, CBSE đưa “Những học hay nhất” sản phẩm công nghệ phần mềm suốt 30 năm Brooks trình bày phương pháp khả thi giúp giảm mức độ phức tạp phần mềm “Buy before Build” “Reuse before Buy” Các khái niệm mấu chốt đưa nhằm giúp giảm chi phí cơng nghệ phát triển phần mềm Trong hội nghị thảo luận năm 1968, NATO tham gia tranh luận thuật ngữ khủng hoảng phần mềm Thêm nhiều thuật ngữ khó hiểu kẽ hở phần mềm, … thuật ngữ làm rõ q trình phát triển cơng nghệ phần mềm Theo David Fraser phát biểu năm 1968, “ Kẽ hở phát thời điểm mà hậu việc hỏng hóc phần mềm tăng theo mức độ nghiêm trọng” Để phát triển phần mềm sở cấu phần phải học cách xây dựng cấu phần dựa vào yêu cầu, dựa việc thiết kế module thành phần hay thiết kế trực tiếp cấu phần Các khách hàng đặt hàng (các cấu phần) việc tích hợp cấu phần cung cấp nhà sản xuất đảm bảo đáp ứng yêu cầu khách hàng với mong muốn họ đưa Khái niệm mơ hình cấu phần phần mềm phát triển rộng rãi BradCox đặt móng cho việc tạo hạ tầng phát triển cấu phần Bước 94 Nhấn [Thêm] để thêm mặt hàng giao dịch Nhập thông tin mặt hàng giao dịch Mã hàng Đơn giá Số lượng Nhấn [Cập nhật] Kiểm tra mặt hàng có quản lý theo serial hay khơng Nếu có thực bước Nếu khơng thực bước 5 Tìm kiếm serial mặt hàng quản lý kho Chọn serial cần thực giao dịch Nhấn [Cập nhật] (Người dùng chọn mặt hàng khác cho đơn hàng) Hệ thống tạo giao dịch thành công Hệ thống thực trừ số lượng hàng kho giao dịch viên Hệ thống thực cập nhật trạng thái serial = xuất, kết thúc giao dịch Dòng kiện phụ Bao gồm kiện phụ UC005 - Xuất Yêu cầu đặc biệt  Bao gồm yêu cầu đặc biệt UC005 - Xuất Tình trạng trước  Bao gồm tình trạng trước UC005 - Xuất Tình trạng sau   Bao gồm tình trạng sau UC005 - Xuất 4.4.3 Xây dựng chương trình Ta xây dựng chương trình phần mềm sở cấu phần có sẵn với ngơn ngữ lập trình Java Các cấu phần JavaBean đóng gói dịch thành file JAR, file bao gồm file class, tài nguyên đáp ứng cho lời gọi file thống kê Các lời gọi cung cấp thông tin chúng 95 Sau bước tích hợp cấu phần vào chương trình xây dựng, phát triển đơn vị chương trình ta tiến hành kiểm thử sở cấu phần tích hợp xây dựng form chức hồn chỉnh Các cấu phần hiển thị frame ToolBox: Khi thực thi chương trình, form hiển thị: 96 4.4.4 Các bước thực chương trình Bước Servlet cung cấp tảng cấu phần, phương thức phát triển độc lập đáp ứng cho xây dựng ứng dụng Web, mà không thực giới hạn chương trình CGI Khơng giống chế mở rộng thực server riêng rẽ( chẳng hạn Netscape Server API module Apache), servlet server với tảng độc lập Run Java servlet Vòng đời servlet bao gồm bước: Class servlet load trình bao gói suốt thời gian khởi động Trình bao gói gọi phương thức init() Phương thức khởi tạo servlet phải gọi trước servlet phục vụ yêu cầu Trong tồn vịng đời servlet, phương thức init() gọi lần Sau khởi tạo, servlet phục vụ 97 Bước 4.4.5 Xây dựng tình kiểm thử Ta xây dựng tình kiểm thử ứng với use case “Xuất hàng tiêu thụ” toán thực tiễn phát biểu 98 Các use case scenario phát triển từ use case bao gồm:  Lập giao dịch bán hàng cho khách  Kiểm tra giá trị giao dịch  Lập hóa đơn giao dịch Dưới bảng xây dựng tình kiểm thử use case nhập giao dịch bán lẻ hàng Tình Lập giao dịch bán hàng cho khách Thực giao dịch bán hàng thành cơng – hàng có serial 99 Thực giao dịch thành khơng có serial Kiểm tra lượng hàng giao dịch 100 Kiểm tra thông tin giao dịch Bỏ trống thông tin bắt buộc nhập Số lượng hàng dịch bị bỏ trống Mặt hàng giao chưa khai giá Số lượng hàng nhập giao dịch < Kiểm tra giá trị giao dịch 101 Kiểm tra giá trị “tổng tiền” Kiểm tra giá trị thuế Kiểm tra giá trị chưa thuế Kiểm tra giá trị phải trả Hóa đơn cho giao dịch bán hàng Lập hóa đơn bán hàng từ giao dịch bán lẻ thành cơng Lập hóa đơn bán hàng cho nhiều giao dịch thành công Cửa hàng khơng cịn hóa đơn trắng 102 Khơng chọn giao dịch lập hóa đơn Thơng tin hóa đơn bỏ trống Kiểm tra thơng tin giao dịch hóa đơn 103 Kết luận Hiện nay, phát triển phần mềm hướng cấu phần (CBSE) thu hút nghiên cứu từ nhiều góc độ khác kỹ thuật xây dựng, đánh giá, kiểm định phần mềm, quy trình khảo sát, phân tích thiết kế, quản lý Phát triển phần mềm hướng cấu phần (CBSE) công nghệ quan trọng cho phép xây dựng hệ thống phần mềm chất lượng cao, mở hệ thống phần mềm lớn cách tích hợp cấu phần phần mềm tồn trước CBSE giảm bớt giá thành phát triển phần mềm, xây dựng hệ thống cách nhanh chóng, giảm bớt việc bảo trì theo kiểu xoắn ốc liên quan đến việc hỗ trợ nâng cấp cho hệ thống lớn CBSE thu hút nghiên cứu nhiều từ góc độ kỹ thuật xây dựng, đánh giá phần mềm quy trình khảo sát, phân tích thiết kế, quản lý, đánh giá Một hướng nghiên cứu thay đổi cách phát triển hệ thống phần mềm: chuyển từ việc lập trình tạo sản phẩm sang việc biên soạn hệ thống phần mềm, tức tập trung vào việc lựa chọn tích hợp cấu phần có sẵn để xây dựng nên hệ thống Trong phương pháp phát triển việc tìm kiếm cấu phần lựa chọn tích hợp dịch vụ cấu phần hai vấn đề tập trung nghiên cứu UML hỗ trợ phát triển phần mềm hướng cấu phần đem đến cho đối tượng phát triển hệ thống nhìn rõ ràng hệ thống xây dựng, giúp cho người phân tích thiết kế thấy yếu tố ảnh hưởng trực tiếp tới hệ thống Trên sở đó, cán phân tích hệ thống xác định cấu phần cần tích hợp với hệ thống Tham gia vào quy trình phát triển phần mềm ln có góp mặt phận kiểm định phần mềm Với phương pháp phát triển phần mềm cấu phần trên, kết hợp với bước kiểm định làm giảm thiểu cách tối đa lỗi phần mềm Tuy thế, Mặt khác, ta khẳng định phát triển phần mềm sở cấu phần, với tham gia UML thiết kế phần mềm làm khơng cịn lỗi Tóm tắt kết đạt Qua thời gian nghiên cứu tìm hiểu phần mềm xây dựng sở cấu phần, áp dụng UML CBSE, kiểm thử phần mềm, áp dụng nghiên cứu kiểm thử phần mềm vào phần mềm hướng cấu phần đạt kết định Một công việc quan trọng kỹ thuật kiểm thử 104 là: phát lỗi hỗ trợ sửa lỗi nhằm đảm bảo chất lượng phần mềm Với phát triển không ngừng kỹ thuật lập trình nay, lập trình hướng cấu phần (COP) lên kỹ thuật lập trình cung cấp khả phát triển hệ thống Xét tính khả thi, hiệu kinh tế CBSE mang lại mà luận văn tập trung nghiên cứu đến khía cạnh kiểm thử phần mềm sở cấu phần Như vậy, sau trình tìm hiểu, nghiên cứu vấn đề kiểm thử nói trên, luận văn tơi đạt số kết sau:  Tìm hiểu tổng quan khái niệm chuẩn phần mềm hướng cấu phần, đánh giá, phân tích ưu nhược điểm phần mềm xây dựng sở hướng cấu phần  Kết hợp kỹ thuật kiểm thử vào quy trình phát triển phần mềm hướng cấu phần Từ thấy ưu điểm việc kiểm thử tốn thực tế  Xây dựng ví dụ thực nghiệm áp dụng nghiên cứu với toán “quản lý bán hàng” Tồn hướng phát triển Với phát triển vũ bão nghành Công nghệ thông tin, hệ thống phần mềm ngày phức tạp, nhu cầu sử dụng lại thành có sẵn nhằm giảm chi phí giá thành cạnh tranh sản xuất mục tiêu hướng tới doanh nghiệp Chính hướng phát triển phần mềm sở hướng cấu phần giai đoạn hợp lý thu hút quan tâm nhiều đối tượng Các kỹ thuật kiểm thử phần mềm chưa đáp ứng cách triệt để, chưa kiểm soát hết khía cạnh giao tiếp cấu phần cấu phần với Việc sử dụng lại cấu phần phát triển theo khía cạnh sử dụng lại hộp trắng, sử dụng lại hộp đen Vì thế, vấn đề đặt thời gian tới ta xây dựng kỹ thuật kiểm thử hiệu đáp ứng nhu cầu kiểm soát hoạt động cấu phần toàn hệ thống kiểm soát thay đổi, nâng cấp tính nhăng tích hợp cấu phần tồn hệ thống Vậy làm để bao quát vấn đề quản lý cấu phần hệ thống phần mềm, từ kiểm thử ảnh hưởng cấu phần hệ thống Và tương lai liệu có cơng cụ hỗ trợ cho hướng kiểm thử này? Với mục tiêu hướng tới phần mềm có chất lượng cao, đạt hiệu kinh tế, hướng nghiên cứu tương lai cần tập trung vào: 105 Nghiên cứu kỹ thuật kiểm thử hiệu đơn vị cấu phần cho sử dụng lại - Đi sâu vào kỹ thuật kiểm thử tích hợp cấu phần có sẵn vào phần mềm xây dựng - Tìm hiểu công cụ hỗ trợ kiểm thử đáp ứng phần mềm xây dựng sở hướng cấu phần - 106 Tài liệu tham khảo 1) Dinesh Maidasani, 2007, Software Testing, Firewall 2) Dorothy Graham, Erik van Veenendaal, Isabel Evans, Rex Black, 2008, Foundation of software testing, Cengage Learning (Thompson) 3) Bill Councill, George T Heineman, May.2001, Component-Based software engineering, Addison-Wesley 4) Hans Gerhard, 2005, Component-Based Software Testing with UML, Springer 5) Jerry Zeyu Gao, H.-S.Jacob Tsao Ye Wu, August.2003, Testing And Quality Assurance For Component Based Software, Artech House 6) Bruce Powel Douglass, 2002, Real-Time Design Patterns, Addison- Wesley 7) Andy Ju An Wang, Kai Qian, 2005, Component-Oriented Programming, 8) H Muccini and A Bucchiarone, 2004, Testing Product Line Architectures 9) Jean Hartmann; Claudio Imoberdorf; Michael Meisinger, 2000, UML-Based Integration Testing 10) Antonia Bertolino; Eda Marchetti; Andrea Polini, 2003, Intergration of “Components” to Test Software Components, Vol.82 11) Clay E Williams, Software Testing and the UML, Center for Software Engineering, IBM T J Watson Research Center 12) Shaukat Ali1, Lionel C Briand, Muhammad Jaffar-ur Rehman, Hajra Asghar, Muhammad Zohaib Z Iqbal, Aamer Nadeem, October 2006, A State-based Approach to Integration Testing based on UML Models, Carleton Technical Report SCE-05-02, Version 13) Ye Wu and Mei-Hwa Chen and Jeff Offutt, UML-based Integration Testing for Component-based Software, Information and Software Engineering Department George Mason University, Computer Science Department State University of New York at Albany 14) British Computer Society Specialist Interest Group in Software Testing,2001, Standard for Software Component Testing 107 15) Trung Thanh Dinh Trong, 2007, A Systematic Procedure for Testing UML Designs, Computer Science Department, Colorado State University 16) Dominykas Barisas, Eduardas Bareisa, 2009, A Software testing approach based on behavioral UML models, ISSN 1392-124X, Vol.38, No.2 17) Adriana Carniello, Mario Jino, Marcos Lordello Chaim, August 2005, Structural Testing with Use Case, JCS & T, Vol.5 No 18) Zhen Ru Dai, Model- Driven Testing with UML 2.0, Fraunhofer FOKUS, Kaiserin-Augusta-Allee 31, 10589 Berlin, Germany 19) Adrita Bhor, June 2001, Software Component Testing Strategies, Dept of Information and Computer Science University of California, Irvine, Report UCI-ICS-02-06 20) Jerry Gao, Ph.D, Testing Component-Based Software, San Jose State University One Washington Square San Jose, CA 95192-0180 ... kèm Một mô tả triển khai cung cấp thơng tin bên gói (hoặc gói liên quan) thơng tin khác cần thiết cho quy trình triển khai Chuẩn triển khai đặc tả cấu trúc ngữ nghĩa cho mô tả triển khai quy định... cung cấp dịch vụ có sẵn chẳng hạn giao dịch bảo mật 2.3.1.3 Đóng gói triển khai Các chuẩn mơ hình cấu phần chứng nhận, kết nối Internet băng thông rộng, làm thay đổi công việc triển khai phần... cung cấp:  Môi trường chạy  Các dịch vụ  Các dịch vụ ngang có tác dụng miền đa nhiệm  Dịch vụ dọc cung cấp chức cho miền cấu phần phần mềm 19 2.4 UML phát triển phần mềm Ngôn ngữ Mơ hình thống