Thiết ké hệ thống

Thiết ké hệ thống

Chương 5:

Thiết kế hệ thống

2 Thiết kế giao diện (Interface Design)

3 Thiết kế dữ liệu (Data design)

4 Thiết kế kiến trúc (Achitectural Design)

5 Thiết kế thành phần (Component Design)

Thiết kế là gì?

• Thiết kế tạo ra một biểu diễn hay mô hình của phần mềm,

nhưng không giống như mô hình phân tích (tập trung vào việc

mô tả dữ liệu, chức năng và hành vi)

• Mô hình thiết kế cung cấp chi tiết về kiến trúc (architecture), Giao diện (interfaces) và thành phần (component) cần thiết để cài đặt phần mềm

• Sản phẩm công tác (work product): biểu diễn kiến trúc (Cơ sơ

dữ liệu, giao tiếp với hệ thống khác…), giao diện người dùng (GUI), thành phần (giao tiếp các thành phần, cấu trúc dữ liệu, giải thuật dưới dạng mã giả…)

mean-time-to-• Thực thi (performance): tốc độ xử lý, thời gian đáp ứng, sử

dụng tài nguyên, hiệu quả…

• Khả năng hỗ trợ (suppotability): dễ mở rộng, khả năng ráp nối, khả năng test, khả năng cấu hình, khả năng tương thích…

Thiết kế hệ thống

Thiết kế phần mềm

• Thiết kế phần mềm là quá trình lặp thông qua đó các yêu cầu hệ thống sẽ được chuyển đổi thành “blueprint” (bản thiết kế chi tiết) của phần mềm

• Thiết kế bao gồm hai phần:

– Thiết kế ý niệm (conceptual design) nhằm nói cho khách

hàng biết chính xác hệ thống sẽ làm gì

– Thiết kế kỹ thuật (technical design) cho phép các nhà xây dựng hệ thống biết cách vận dụng phần cứng và phần mềm như thế nào để giải quyết bài toán của khách hàng

Hướng dẫn thiết kế

• Một thiết kế phải đưa ra một kiến trúc mà:

– (1) Dùng mẫu (pattern) hay kiểu (style) kiến trúc được thừa nhận

– (2) Gồm những 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 dữ liệu, kiến trúc, giao diện và thành phần (component)

• Thiết kế phải đưa ra cấu trúc dữ liệu phù hợp với lớp thực thi

và từ những mẫu dữ liệu được thừa nhận

• Thiết kế phải đưa ra những thành phần mà độc lập chức năng

• Thiết kế phải đưa ra những giao diện (interface) mà giảm sự

phức tạp của việc kết nối giữa các thành phần, cũng như môi trường ngoài

• Thiết kế được đưa ra từ việc dùng phương pháp lặp mà được định hướng bởi thông tin đạt được suốt quá trình phân tích yêu cầu phần mềm

• Thiết kế phải dùng những ký hiệu hiệu quả cao trong việc thông tin

Data Flow Diagram Control-Flow diagram

Flow-oriented Element Data Flow Diagram Control-Flow diagram

Behavioral Element

State diagram Sequence diagram

Behavioral Element State diagram Sequence diagram

Nguyên lý thiết kế

• Thiết kế phải tránh “tunnel vision”

• Thiết kế phải có thể lần vết ra mô hình phân tích

• Thiết kế phải không “reinvent the wheel”

• Thiết kế “minimize the intellectual distance” giữa phần mềm và những vấn

đề trong thế giới thực

• Thiết kế phải thể hiện tính đồng nhất và tích hợp

• Thiết kế phải hỗ trợ sự thay đổi

• Thiết kế phải làm nhẹ đi những lệch lạc về dữ liệu sự kiện hay điều kiện hoạt động

• Thiết kế không là code, code không là thiết kế

• Thiết kế phải được đánh giá chất lượng khi nó đang được tạo không phải khi nó có vấn đề

• Thiết kế phải được kiểm tra (review) để làm giảm thiểu những lỗi ngữ

nghĩa (semantic)

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 interface

• Độc lập chức năng (Functional independence) - single-minded function and low coupling

• Tinh chế (Refinement) - elaboration of detail for all abstractions

• Phân tách lại (Refactoring) - a reorganization technique that simplifies the design

2 Các mô hình thiết kế

• Thiết kế giao diện (Interface Design)

• Thiết kế kiến trúc (Achitectural Design)

• Thiết kế dữ liệu (Data design)

• Thiết kế thành phần (Component Design)

2.2 Thiết kế giao diện

• Để hệ thống làm việc tốt, ta phải điều khiển được các hệ thống con, làm cho các dịch vụ của chúng phải được thực hiện đúng chỗ và đúng thời điểm

• Có 2 loại điều khiển (control styles):

– Điều khiển tập trung: một hệ thống con chịu trách nhiệm

kiểm soát, khởi tạo hoặc dừng các hệ thống con khác

– Điều khiển hướng sự kiện: mỗi hệ thống đáp ứng với các sự kiện xảy ra từ các hệ thống con khác hoặc từ môi trường của

hệ thống

2.2 Thiết kế giao diện

• Ba quy tắc vàng

• Các mô hình phân tích & thiết kế giao diện

• Quy trình phân tích & thiết kế giao diện

• Phân tích giao diện

• Thiết kế giao diện

(architecture design)

Các mô tả Doors, windows,

utility connections for

water, for electricity,…

Thiết kế giao diện (user interface design)

Ba quy tắc vàng

1 Place the user in control

2 Reduce the user’s memory load

3 Make the interface consistent

Quy tắc 1: Theo yêu cầu người dùng

Place the user in control

• Người dùng luôn mong muốn hệ thống tương tác và giúp họ thực hiện mọi việc dễ dàng

Quy tắc 1: Theo yêu cầu người dùng

Place the user in control

• Nên xác định kiểu tương tác sao cho không ép người dùng thực hiện các thao tác không cần thiết hay không mong muốn

• Cho phép tương tác linh hoạt ( bàn phím, chuột, bút, )

• Cho phép người dùng được ngắt khi thực 1 chuỗi thao tác hay được phép “undo” thao tác nào

• Cho phép người dùng thông thạo được phép tùy biến các tương tác (dùng macro)

• Không nên để người dùng phải nhìn thấy các yếu tố kỹ thuật của hệ thống (hệ điều hành, chức năng quản lý file,…)

• Cho phép người dùng tương tác trực tiếp với các đối tượng trên màn hình (kéo dãn 1 đối tượng vẽ )

Quy tắc 2: giảm thiểu việc ghi nhớ của người dùng

Reduce the user’s memory load

• Càng bắt người dùng phải nhớ càng nhiều, thì việc tương tác với hệ thống càng dễ bị lỗi

– Để giảm việc phải nhớ các hành động cần làm, nên đưa ra các gợi ý hình ảnh (visual cues)

– Nên tạo các mặc định thích hợp

– Nên tạo các phím gõ tắt (shortcut) trực giác, dễ nhớ

– Nên sắp xếp giao diện gần giống với thế giới thực

– Nên tổ chức thông tin theo dạng phân cấp (hierarchical),

thông tin ở mức trừu tượng trước, rồi tới mức chi tiết ( chọn chức năng gạch dưới xong, thì các kiểu gạch dưới cụ thể sẽ được liệt kê tiếp theo )

Quy tắc 3: Giao diện phải luôn nhất quán

Make the interface consistent.

• Nhất quán trong việc thiết kế các màn hình giao diện theo cùng một tiêu chuẩn

– Cùng cơ chế nhập liệu

– Cùng cơ chế chuyển đổi từ nhiệm vụ này sang nhiệm vụ

khác

Mục tiêu của thiết kế giao diện

• Là để xác định tập hợp các đối tượng giao diện và các hành động cho phép người dùng thực hiện được tất cả những nhiệm

vụ của hệ thống

Các mô hình phân tích và thiết kế giao diện

Bốn mô hình có liên quan đến thiết kế giao diện:

1 Kỹ sư phần mềm tạo mô hình thiết kế (design model)

2 Người phụ trách về nhân sự tạo ra mô hình người dùng

giao diện là phải làm sao cho các mô hình này tương thích và tạo ra giao diện ôn định

Phân loại người dùng

• Novices (người mới) – không có kiến thức về hệ thống, hiểu biết rất ít về ứng dụng cũng như cách sử dụng máy tính

• Knowledgeable intermittent users (người dùng gián đoạn tuy có kiến thức)

• Knowledgeable frequent users (người dùng thường xuyên có hiểu biết)

Phân tích giao diện thường xét đến hồ sơ (profile) của người dùng

hệ thống và phân tích cả môi trường làm việc của người dùng

Quy trình phân tích & thiết kế giao diện

Quy trình phân tích và thiết kế giao diện thường lặp lại và có thể được biểu diễn bằng mô hình xoắn ốc

Hoạt động implementation

thường là prototyping

Quy trình thiết kế giao diện người dùng

• Quy trình thiết kế giao diện thường hay lặp lại và theo mô hình xoắn ốc

Phân tích giao diện

Mục tiêu của phân tích giao diện:

1 Để hiểu người sẽ sử dụng hệ thống thông qua giao diện

2 Để hiểu nhiệm vụ người dùng cuối phải thực hiện

3 Để hiểu nội dung trong mỗi giao diện

4 Để hiểu bản chất môi trường mà nhiệm vụ sẽ thực hiện

Phân tích giao diện

• Phân tích người dùng (user analysis)

• Phân tích và mô hình hóa nhiệm vụ (task analysis and modeling)

• Phân tích môi trường làm việc

• Phân tích nội dung hiển thị

Phân tích người dùng

Để phân tích người dùng có thể dựa vào các nguồn sau:

• Phỏng vấn người dùng (User interviews)

• Từ việc bán hàng (Sales input) – nhân viên bán hàng sẽ giúp nhà thiết kế phân loại người dùng và nắm được nhu cầu của họ

• Từ tiếp thị (Marketing input)

• Từ hỗ trợ (Support input)

Phân tích người dùng

Những câu hỏi giúp nhà thiết kế giao diện hiểu rõ hơn người dùng:

1 Are users trained professionals, technicians, clerical or

workers?

2 What level of formal education does the average user have?

3 What is the age range of the user community?

4 Do users work normal office hours, or do they work until the

job is done?

5 Are users expert typists or keyboard phobic?

6 Is the software to be an integral part of the work users do, or

will it be used only occasionally?

7 Do users want to know about the technology that sists behind

the interface?

Phân tích môi trường làm việc

của người dùng

Thông qua 1 số câu hỏi sau:

1 Where will the interface be located physically?

2 Will the user be sitting, standing, or performing other tasks

unrelated to the interface?

3 Does the interface hardware accommodate space, light, or

noise constraints?

4 Are there special human factors considerations driven by

environmental factors?

Phân tích nhiệm vụ (Task analysis)

Mục tiêu của phân tích nhiệm vụ để trả lời các câu hỏi sau:

1 What work will the user perform in specific circumstances?

2 What tasks and subtasks will be performed as the user does the

work?

3 What specific problem domain objects will the user manipulate

as work is performed?

4 What is the sequence of work tasks – the workflow?

5 What is the hierarchy of tasks?

Phân tích nhiệm vụ (Task analysis)

• Có thể theo 1 trong 2 cách để phân tích nhiệm vu:

– Cần phải hiểu được nhiệm vụ mà người dùng cần phải làm (trước khi có phần mềm), rồi ánh xạ chúng thành tập các nhiệm vụ cần thực thi trong giao diện của người dùng

– Có thể nghiên cứu đặc tả có sẵn của phần mềm và từ tập nhiệm vụ của người dùng để suy diễn ra mô hình người

dùng

• Mỗi nhiệm vụ chính (major task) có thể được chia thành nhiều nhiệm vụ con (subtask)

Phân tích nhiệm vụ (Task analysis)

• Nếu hệ thống có nhiều người dùng khác nhau, mỗi người dùng

có vai trò khác nhau, nên sử dụng các giao diện khác nhau , thì

kỹ sư thiết kế cần áp dụng kỹ thuật workflow analysis

• Workflow analysis: kỹ thuật cho phép kỹ sư phần mềm hiểu một quy trình công việc được hoàn thành như thế nào

• Thể hiện workflow analysis là lược đồ activity của UML

• Ví dụ: quy trình kê đơn và phát thuốc Có 3 loại người dùng: bệnh nhân, bác sĩ và người bán thuốc

2 Can user customize screen locations of content?

3 Is proper on-screen identification assigned to all content?

4 How should large report be partitioned for ease of understanding?

5 Will mechanisms be available for moving directly to data summary

information for large data collections?

6 Will graphical output be scaled to fit bounds of display device used?

7 How will color be used to enhance understanding?

8 How will error messages and warnings be displayed to the user?

Thiết kế giao diện

• Ngay sau khi phân tích xong giao diện, thiết kế giao diện sẽ

bắt đầu

• Là quá trình lặp, được chia thành 4 bước:

1 Xác định các đối tượng và thao tác của giao diện

2 Xác định các sự kiện làm cho trạng thái của các giao diện thay

đổi Tạo mô hình cho các hành vi này

3 Mô tả mỗi trạng thái giao diện

4 Chỉ ra làm thế nào người dùng hiểu các trạng thái này từ thông

tin được cung cấp trên giao diện

Phân tích các bước thiết kế

• Từ đặc tả use case, lọc ra các noun (object) và verb (action) để tạo ra danh sách các object và action

• Phân loại đối tượng (type): source, target và application

– Source là loại đối tượng có thể drag and drop vào target.– Application là đối tượng chứa dữ liệu của ứng dụng nhưng không được tạo ra 1 cách trực tiếp bằng các thao tác trên màn hình

• Screen layout: là 1 quá trình lặp để sắp xếp vị trí các biểu

tượng, xác định các phần mô tả (text), xác định và đặt tên cho cửa sổ, định nghĩa menu,

Ví dụ: khảo sát scenario

Scenario: The homeowner wishes to gain access to the SafeHome system

installed in his house Using software operating on a remote PC, the

homeowner determines the status of the alarm system, arms or disarms the system, reconfigures security zones, and views different rooms within the house via preinstalled video cameras.

To access SafeHome from a remote location, the homeowner provides an

identifier and a password These define levels of access and provide

security Once validated, the user checks the status of the system and

changes status by arming or disarming SafeHome The user reconfigures the system by displaying a floor plan of the house, viewing each of the

security sensors, displaying each currently configured zone, and modifying zones as required The user views the interior of the house via strategically placed video cameras The user can pan and zoom each camera to provide different views of the interior.

Ví dụ: xác định đối tượng và hành động

Nhiệm vụ của homeowner:

• accesses the SafeHome system

• enters an ID and password to allow remote access

• checks system status

• arms or disarms SafeHome system

• displays floor plan and sensor locations

• displays zones on floor plan

• changes zones on floor plan

• displays video camera locations on floor plan

• selects video camera for viewing

• views video images (4 frames per second)

• pans or zooms the video camera

Các đối tượng ?? Các hành động???

Ví dụ: bố trí màn hình của Safehome

• Có 3 loại đối tượng:

– Source: video camera location

– Target: video camera Khi source được kéo vào target thì sẽ tạo ra hình ảnh mà camera đó thu được

– Application: cửa sổ video image

Ví dụ: bố trí sơ bộ màn hình

Mẫu thiết kế Design pattern

Mẫu thiết kế là một giải pháp tổng thể cho các vấn đề chung

trong thiết kế phần mềm Một mẫu thiết kế không phải là một thiết kế hoàn thiện để mà có thể được chuyển đổi trực tiếp

thành mã; nó chỉ là một mô tả hay là sườn (template) mô tả

cách giải quyết một vấn đề mà có thể được dùng trong nhiều tình huống khác nhau Các mẫu thiết kế hướng đối tượng

thường cho thấy mối quan hệ và sự tương tác giữa các lớp hay các đối tượng, mà không cần chỉ rõ các lớp hay đối tượng của từng ứng dụng cụ thể Các giải thuật không được xem là các mẫu thiết kế, vì chúng giải quyết các vấn đề về tính toán hơn là các vấn đề về thiết kế

Bốn vấn đề thiết kế giao diện

1 Response time

2 User help facilities

3 Error information handling

Vấn đề 1: Thời gian đáp ứng

(Response time)

• Được tính từ lúc người dùng thực hiện 1 hành động kiểm soát (control) nào

đó cho đến lúc phần mềm đáp ứng được bằng kết quả hay hành động

• Hai đặc tính: length and variability.

• Length: nếu thời gian đáp ứng quá lâu, sẽ gây bực bội và căng thẳng cho người dùng Thời gian đáp ứng quá nhanh cũng gây bất lợi, người dùng sẽ vội vàng và dễ gây nhầm lẫn

• Variability: độ dao động của thời gian đáp ứng Độ dao động thấp cho

phép người dùng xác lập được sự thao tác nhịp nhàng, ngay cả khi thời

gian đáp ứng tương đối lâu Ví dụ: thời gian đáp ứng 1 giây cho mỗi lệnh vẫn được ưa thích hơn là thời gian đáp ứng thay đổi từ 0.1 đến 2.5 giây Người dùng luôn cảm thấy mất thăng bằng nếu lúc nhanh lúc chậm, họ

luôn tự hỏi liệu có cái gì khác đang xảy ra mỗi lần đáp ứng chậm.