Đang tải... (xem toàn văn)
Trang_danh_cho_Sinhvien - Nguyễn Thế Dũng Chapter5 tài liệu, giáo án, bài giảng , luận văn, luận án, đồ án, bài tập lớn...
TRƯỜNG ĐẠI HỌC CÔNG NGHIỆP TP.HCM MÔN HỌC CÔNG NGHỆ PHẦN MỀM Chương Kỹ thuật thiết kế Công Nghệ Phần Mềm Kỹ thuật thiết kế • 5.1 Thiết kế cơng nghệ phần mềm • 5.2 Khái niệm thiết kế • 5.3 Mơ hình thiết kế Cơng Nghệ Phần Mềm 5.1 Thiết kế công nghệ phần mềm sc e na r i o- ba se d e l e me nt s Com pone n t Le v e l D e sign f l ow- or i e nt e d e l e me nt s use-cases - text use-case diagrams activity diagrams swim lane diagrams data flow diagrams control-flow diagrams processing narratives Int e rf a c e D e sign Analysis Model c l a ss- ba se d e l e me nt s class diagrams analysis packages CRC models collaboration diagrams be v i or a l e l e me nt s state diagrams sequence diagrams A rc h it e c t ura l D e sig n D a t a / Cla ss D e sign Design Model Công Nghệ Phần Mềm Thiết kế chất lượng • Thiết kế phải thỏa yêu cầu tường minh ngầm định • Thiết kế phải dễ hiểu, dễ đọc hỗ trợ cho việc tạo code, test hỗ trợ phần mềm • Thiết kế phải cung cấp hình ảnh đầy đủ phần mềm, xác định liệu, chức hành vi Công Nghệ Phần Mềm Thuộc tính chất lượng • Chức (functionality): kèm theo tính an ninh • Tiện dụng (usability): bao gồm tính mỹ thuật, tồn vẹn tư liệu • Tin cậy (reliability): bảo đảm hoạt động, dùng The mean-time-to-failure (MTTF), Khả phục hồi từ lỗi • Thực thi (performance): tốc độ xử lý, thời gian đáp ứng, sử dụng tài nguyên, hiệu quả… • Khả hỗ trợ (suppotability): dễ mở rộng, khả ráp nối, khả phục vụ (3 thuộc tính khả bảo trì), khả test, khả cấu hình, khả tương thích… Cơng Nghệ Phần Mềm Hướng dẫn thiết kế • Một thiết kế phải đưa kiến trúc mà (1) Dùng mẫu (pattern) hay kiểu (style) kiến trúc thừa nhận (2) Gồm thành phần có đặc trưng thiết kế tốt (3) Có thể thi hành theo cách tiến hóa • Thiết kế phải module hóa • Thiết kế phải trình bày riêng liệu, kiến trúc, giao diện thành phần (component) • Thiết kế phải đưa cấu trúc liệu phù hợp với lớp thực thi từ mẫu liệu thừa nhận • Thiết kế phải đưa thành phần mà độc lập chức Công Nghệ Phần Mềm Hướng dẫn thiết kế • Thiết kế phải đưa giao diện mà giảm phức tạp việc kết nối thành phần, với mơi trường ngồi • Thiết kế đưa từ việc dùng phương pháp lặp mà định hướng thông tin đạt suốt trình phân tích u cầu phần mềm • Thiết kế phải dùng ký hiệu hiệu cao việc thông tin Công Nghệ Phần Mềm Nguyên lý thiết kế • • • • Thiết kế phải tránh ‘tunnel vision’ Thiết kế phải lần vết mơ hình phân tích Thiết kế phải khơng “reinvent the wheel” Thiết kế “minimize the intellectual distance” phần mềm vấn đề giới thực • Thiết kế phải thể tính đồng tích hợp Cơng Nghệ Phần Mềm Nguyên lý thiết kế • Thiết kế phải hỗ trợ thay đổi • Thiết kế phải làm nhẹ lệch lạc liệu kiện hay điều kiện hoạt động • Thiết kế khơng code, code khơng thiết kế • Thiết kế phải đánh giá chất lượng tạo khơng phải có vấn đề • Thiết kế phải kiểm tra để làm giảm thiểu lỗi khái niệm (semantic) Công Nghệ Phần Mềm 5.2 Khái niệm thiết kế • Trừu tượng (Abstraction) - data, procedure, control • Kiến trúc (Architecture) - the overall structure of the software • Mẫu (Patterns) - ”conveys the essence” of a proven design solution • Module hóa (Modularity) - compartmentalization of data and function • Che dấu thơng tin (Information hiding) - controlled interfaces • Độc lập chức (Functional independence) - singleminded function and low coupling • Tinh chế (Refinement) - elaboration of detail for all abstractions • Phân tách (Refactoring) - a reorganization technique that simplifies the design Công Nghệ Phần Mềm 10 Phân chia module hiệu • Có nhiều mức độ kết dính (từ thấp đến cao) Ngẫu nhiên: tác vụ không liên hệ với Luận lý: tác vụ liên quan logic với (không quan tâm tới loại) Thời gian: module chứa tác vụ mà phải thực thi khoảng thời gian Thủ tục: thành phần xử lý module phải thực theo trật tự định Thơng tin: tác vụ có sử dụng tập trung vào vùng liệu Cơng Nghệ Phần Mềm 34 Cohesion (từ cao đến thấp) • Chức năng: thành phần module cần thiết thiết yếu cho chức • Trình tự: thành phần module có liên quan việc thực phần khác trình tự hoạt động, output hoạt động input thành phần • Thơng tin: thành phần hoat động liệu • Thủ tục: thành phần module tất phần thủ tục • Thời gian: thành phần module quan hệ với theo thời gian, không cần phải xuất thứ tự chắn hay hoạt động liệu • Logic: Những thành phần module tất hướng phía thực tập hoạt động xác định • Ngẫu nhiên: Khơng có quan hệ thiết yếu Cơng Nghệ Phần Mềm 35 Phân chia module • Độ kết dính (cohesion) liên kết (coupling) • Độ kết dính dùng để đo lường quan hệ chức module • Sự liên kết đo lường liên kết module • Thiết kế kiến trúc phần mềm: cố gắng tăng độ kết dính, giảm liên kết Cơng Nghệ Phần Mềm 36 Sơ đồ phân cấp M Fan-out b a c Depth d f e h g i k l n o m p r j q Fan-in Width Cơng Nghệ Phần Mềm 37 Phân tách (Refactoring) • Fowler [FOW99] xác định: “Phân tách trình biến đổi hệ thống phần mềm cách thức mà khơng biến đổi hành vi bên ngồi code (thiết kế) nhằm cải thiện cấu trúc bên nó” • Khi phần mềm phân tách thiết kế kiểm tra Sự dư thừa (redundancy) Những thành phần thiết kế không sử dụng Những giải thuật không cần thiết hay không hiệu Cấu trúc liệu nghèo nàn hay không phù hợp Các lỗi thiết kế khác Công Nghệ Phần Mềm 38 Module hiệu • • • • Khả phân chia vấn đề thành vấn đề Những module ghép dễ dàng thành hệ thống Dễ hiểu module đứng Khi có thay đổi ảnh hưởng tới module riêng biệt • Khi có sai sót module ảnh hưởng nhỏ • Những thông tin thủ tục liệu cục module phải che dấu khỏi module khác • Các module giao tiếp với thông tin thật cần thiết Công Nghệ Phần Mềm 39 HEURISTIC • Đánh giá thiết kế ban đầu để tăng độ kết dính giảm liên kết • Khi chiều sâu tăng, hạn chế fan-out sử dụng fan-in • Giữ cho vùng ảnh hưởng module nằm bên vùng điều khiển • Đánh giá giao tiếp module nhằm giảm phức tạp, dư thừa tăng cường tính tồn vẹn • Ưu tiên module tất định (predictable-blackbox), hạn chế module nhiều ràng buộc • Tăng cường module giao tiếp ràng buộc, tránh kết nối module Công Nghệ Phần Mềm 40 Giao diện (Interface) M o b ile Ph o n e W ir e le ssPD A Co n t r o lPa n e l LCDdis play L ED i n d i c a t o r s k e y Pa d C h a r a c t e r i s t i c s s peak er w i r e l e s s In t e r f a c e K e y Pa d r e a d K e y St r o k e ( ) dec odeK ey ( ) d i s p l a y St a t u s ( ) l i g h t L ED s ( ) s e n d C o n t r o l M s g( ) < < in t e r f a c e > > K e y Pa d r e a d K e y s t r o k e( ) dec odeK ey ( ) F ig u r e U M L in t e r f a c e r e p r e se n t a t io n f o r C o n t r o l P a n e l Công Nghệ Phần Mềm 41 Thành phần (Component) SensorManagement Công Nghệ Phần Mềm Sensor 42 Thành phần Công Nghệ Phần Mềm 43 Thành phần triển khai Cont rol Panel CPI serv er Security homeownerAccess Personal comput er externalAccess Security Surveillance homeManagement Công Nghệ Phần Mềm communication Figure UML deploy m ent diagram for SafeHom e 44 Thiết kế Pattern • Người thiết kế tốt có khả nhận mẫu giải vấn đề mẫu tương ứng để giải vấn đề • Mơ tả mẫu thiết kế xem xét tập ảnh hưởng thiết kế (design force) Ảnh hưởng thiết kế (design force) mô tả yêu cầu phi chức (dễ bảo trì, dễ mang xách…) kết hợp với phần mềm mà mẫu áp dụng, ảnh hưởng đến mẫu • Những đặc trưng mẫu (lớp, nhiệm vụ, cộng tác) xác định thuộc tính thiết kế mà điều chỉnh phép mẫu giải vấn đề Cơng Nghệ Phần Mềm 45 Pattern • Tên mẫu (Pattern name) - describes the essence of the pattern in a short but expressive name • Mục đích (Intent) - describes the pattern and what it does • Tên khác (Also-known-as) - lists any synonyms for the pattern • Sự thúc đẩy (Motivation) - provides an example of the problem • Khả ứng dụng (Applicability) - notes specific design situations in which the pattern is applicable Công Nghệ Phần Mềm 46 Pattern • Cấu trúc (Structure) - describes the classes that are required to implement the pattern • Lớp tham gia (Participants) - describes the responsibilities of the classes that are required to implement the pattern • Cộng tác (Collaborations)- describes how the participants collaborate to carry out their responsibilities • Kết (Consequences) - describes the “design forces” that affect the pattern and the potential trade-offs that must be considered when the pattern is implemented • Mẫu liên quan (Related patterns) - cross-references related design patterns Công Nghệ Phần Mềm 47 Framework • framework khơng mẫu kiến trúc, khung với nhiều điểm nối (móc hay khe) cho phép ráp nối với miềm vấn đề đặc trưng • Gamma et al: Mẫu thiết kế nhiều trừu tượng Framework Mẫu thiết kế thành phần kiến trúc nhỏ Framework Mẫu thiết kế chun biệt framework Công Nghệ Phần Mềm 48 ... o- ba se d e l e me nt s Com pone n t Le v e l D e sign f l ow- or i e nt e d e l e me nt s use-cases - text use-case diagrams activity diagrams swim lane diagrams data flow diagrams control-flow... (Abstraction) - data, procedure, control • Kiến trúc (Architecture) - the overall structure of the software • Mẫu (Patterns) - ”conveys the essence” of a proven design solution • Module hóa (Modularity) -. .. diagr am s c ont r ol- f low diagr am s pr oc es s ing nar r at iv es des ign c las s r ealiz at ions s ubs y s t em s c ollabor at ion diagr am s us e- c as es - t ex t us e- c as e diagr am s