ch ng 5 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Ch??ng 5: PowerPoint Presentation
Download Presentation
Ch??ng 5:

Loading in 2 Seconds...

play fullscreen
1 / 108

Ch??ng 5: - PowerPoint PPT Presentation


  • 160 Views
  • Uploaded on

Chương 5:. Thiết kế hệ thống. Một số khái niệm Các mô hình thiết kế Thiết kế mô hình hệ thống Thiết kế giao diện (Interface Design) Thiết kế dữ liệu (Data design) Thiết kế kiến trúc (Achitectural Design) Thiết kế thành phần (Component Design). Nội dung. Thiết kế là gì

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Ch??ng 5:' - shima


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
ch ng 5

Chương 5:

Thiết kế hệ thống

n i dung
Một số khái niệm

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

Thiết kế mô hình hệ thống

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

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

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

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

Nội dung
1 m t s kh i ni m
Thiết kế là gì

Thuộc tính chất lượng

Thiết kế hệ thống

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

Nguyên lý thiết kế

Khái niệm thiết kế

1. Một số khái niệm
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ả…)

Thiết kế là gì?
thi t k l g1
SRS cho biết hệ thống làm gì (what) và trở thành đầu vào cho quá trình thiết kế

Thiết kế dùng để chỉ ra hệ thống sẽ làm như thế nào (how), các yêu cầu sẽ được hiện thực hóa (realize) ra sao?

Kết quả của quá trình thiết kế là Software Design Document (SDD).

Thiết kế là gì?
thu c t nh ch t l ng
Chức năng (functionality): khả năng của phần mềm, kèm theo tính an ninh

Tiện dụng (usability): bao gồm cả tính mỹ thuật, toàn vẹn và tư liệu

Tin cậy (reliability): tính chính xác, dùng The mean-time-to-failure (MTTF), Khả năng 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ả 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…

Thuộc tính chất lượ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.

Thiết kế phần mềm
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

Hướng dẫn thiết kế
slide10
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

chuy n m h nh ph n t ch sang m h nh thi t k
Mỗi phần tử của mô hình phân tích (analysis model) cung cấp thông tin cần thiết để tạo 4 mô hình thiết kế.

Analysis Model

Scenario-based

Element

Use case diagram

Activity diagram

Flow-oriented

Element

Data Flow Diagram

Control-Flow diagram

Class-based

Element

Class diagram

CRC models

Behavioral

Element

State diagram

Sequence diagram

Chuyển mô hình phân tích sang mô hình thiết kế
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)

Nguyên lý thiết kế
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

Khái niệm thiết kế
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. Các mô hình thiết kế
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
2 2 thi t k giao di n1
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

ba quy t c v ng
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
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.

Người dùng muốn

“to control the computer, not have the computer control”,

“System reads their mind, it knows what the users want to do before the user need to do”

Nhưng

Người thiết kế muốn đưa vào giao diện các ràng buộc và giới hạn để làm đơn giản hóa việc thực thi giao diện.

quy t c 1 theo y u c u ng i d ng place the user in control1
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
Quy tắc 2: giảm thiểu việc ghi nhớ của người dùngReduce 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
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
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
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:

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

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

Người dùng cuối phát triển mô hình nhận biết hệ thống (system perception)

Người thực thi tạo mô hình thực thi (implementation model)

Các mô hình này có thể rất khác nhau. Vai trò của người thiết kế 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
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 & 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 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.

Bốn hoạt động chính:

1. User, task, and environment analysis and modeling

2. Interface design

3. Interface construction

4. Interface validation

ph n t ch giao di n
Phân tích giao diện

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

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

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

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

Để 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 n1
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

Để 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 ng1
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:

Are users trained professionals, technicians, clerical or workers?

What level of formal education does the average user have?

What is the age range of the user community?

Do users work normal office hours, or do they work until the job is done?

Are users expert typists or keyboard phobic?

Is the software to be an integral part of the work users do, or will it be used only occasionally?

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
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:

Where will the interface be located physically?

Will the user be sitting, standing, or performing other tasks unrelated to the interface?

Does the interface hardware accommodate space, light, or noise constraints?

Are there special human factors considerations driven by environmental factors?

ph n t ch nhi m v task analysis
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:

What work will the user perform in specific circumstances?

What tasks and subtasks will be performed as the user does the work?

What specific problem domain objects will the user manipulate as work is performed?

What is the sequence of work tasks – the workflow?

What is the hierarchy of tasks?

ph n t ch nhi m v task analysis1
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 analysis2
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

ph n t ch n i dung hi n th analysis of display content
Phân tích nội dung hiển thị(Analysis of display content)

Khi phân tích giao diện,các yếu tố thẩm mỹ và định dạng cũng cần được khảo sát thông qua 1 số câu hỏi:

Are different types of data assigned to consistent geographical locations on the screen?

Can user customize screen locations of content?

Is proper on-screen identification assigned to all content?

How should large report be partitioned for ease of understanding?

Will mechanisms be available for moving directly to data summary information for large data collections?

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

How will color be used to enhance understanding?

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

thi t k giao di n
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:

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

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

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

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
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
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
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

• displaysfloor plan and sensor locations

• displayszones on floor plan

• changes zones on floor plan

• displaysvideo camera locations on floor plan

• selectsvideo 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
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

m u thi t k design pattern
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ế.

v d c c m u thi t k giao di n
Ví dụ các mẫu thiết kế giao diện

Top-level navigation …

Card stack

Fill-in-the-blanks

Sortable table

Bread crumbs

Edit-in-place

Simple search

Shopping cart

Progress indicator

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

Response time

User help facilities

Error information handling

Command label

Nếu không được chú trọng ngay khi bắt đầu thiết kế sẽ gây ra hậu quả sau:

Unnecessary iteration

Project delays

Customer frustration.

v n 1 th i gian p ng response time
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.

v n 2 ti n ch h tr ng i d ng user help facilities
Vấn đề 2: Tiện ích hỗ trợ người dùng User help facilities

Các phần mềm hiện đại đều cung cấp hỗ trỡ trực tuyến (on-line help) cho phép người dùng hỏi và được trả lời hay giải quyết các rắc rối mà không cần phải đóng giao diện lại.

Hai loại hỗ trợ : tích hợp (integrated ) và bổ sung tùy chọn (add-on)

Integrated help: đựợc thiết kế ngay trong phần mềm, thường ở dạng cảm ngữ cảnh (context sensitive) cho phép người dùng chọn theo danh mục phù hợp với từng hành động đang được thực thi, tăng tính thân thiện với người dùng.

Add-on help: được bổ sung thêm vào phần mềm sau khi hệ thống đã được xây dựng. Nó thực sự là 1 số tay người dùng trực tuyến nhưng hạn chế khả năng truy vấn, người dùng phải dò tìm thông qua 1 danh mục hàng trăm chủ đề.

thi t k ph n h tr
Thiết kế phần hỗ trợ

Để thiết kế phần hỗ trợ, cần xem xét các vấn đề sau:

Will help be available for all system functions and at all times during system interaction? Options include help for only a subset of all functions and actions or help for all functions.

How will the user request help? Options include a help menu, a special function key, or a HELP command.

How will help be represented? Options include a separate window, a reference to a printed document (less than ideal), or a one- or two-line suggestion produced in a fixed screen location.

How will the user return to normal interaction? Options include a return button displayed on the screen, a function key, or control sequence.

How will help information be structured? Options include a "flat" structure in which all information is accessed through a keyword, a layered hierarchy of information that provides increasing detail as the user proceeds into the structure, or the use of hypertext.

v n 3 qu n l l i error handling
Vấn đề 3: Quản lý lỗiError handling

Thông báo (message) và cảnh báo (warnings) sai lệch hoặc không có tác dụng gì sẽ làm tăng sự thất vọng cho người dùng.

Thông báo lỗi nên theo các tính chất sau:

Nên mô tả theo thuật ngữ mà người dùng có thể hiểu được.

Nên cung cấp lời khuyên có tính xây dựng giúp người dùng khôi phục được khi lỗi xảy ra.

Nên chỉ ra các hậu quả (ví dụ file dữ liệu có thể bị lỗi) nhờ đó người dùng có thể kiểm tra lại

Nên đồng hành với các gợi ý âm thanh hay hình ảnh như tiếng beep, thông báo nhấp nháy hoặc có màu đặc biệt (đỏ)

Chỉ đơn thuần là thông báo, không mang tính phán quyết, đổ lỗi cho người dùng

v n 4 thi t k nh n menu and command labeling
Vấn đề 4: Thiết kế nhãnMenu and command labeling

Gõ lệnh vào là cách tương tác thông dụng nhất giữa người và máy và thường được dùng trong mọi ứng dụng

Hiện nay giao diện thông dụng là window-oriented, drag and drop, menu và các nút lệnh

Dù phải gõ lệnh hay dùng nút lệnh, cần lưu ý các vấn đề sau:

Mỗi tùy chọn của thực đơn có tương đương với 1 lệnh không?

Khi thi hành lệnh thì sẽ được form gì?

Học và nhớ lệnh khó khăn như thế nào? Phải làm gì nếu quên lệnh

Người dùng có thể tùy biến hay viết tắt lệnh được không?

slide51
Tham khảo 12 quy tắc thiết kế

http://www.smashingmagazine.com/2009/01/19/12-useful-techniques-for-good-user-interface-design-in-web-applications/

user interface design
User Interface Design

Examples of change: 1990 to 2006

2 3 thi t k d li u data design
Đôi khi còn gọi là data architecting

Để tạo mô hình dữ liệu ở mức trừu tượng (view của người dùng).

Trong nhiều ứng dụng dữ liệu có ảnh hưởng đáng kể đến kiến trúc phần mềm đang phát triển.

Cấu trúc dữ liệu luôn luôn là 1 phần quan trọng của thiết kế phần mềm

2.3 Thiết kế dữ liệu data design
thi t k d li u
Thiết kế dữ liệu ở mức thành phần chỉ tập trung vào việc biểu diễn các cấu trúc dữ liệu được truy xuất trực tiếp bởi một hay nhiều thành phần phần mềm (SW components)

Một số nguyên tắc:

Các nguyên tắc dùng để phân tích chức năng cũng nên áp dụng cho dữ liệu

Tất cả cấu trúc dữ liệu và thao tác được thực thi trên mỗi cấu trúc cũng cần xác định (Nguyên tắc này rất thích hợp cho loại cấu trúc class)

Thiết kế dữ liệu
2 4 thi t k ki n tr c
Kiến trúc(Architecture) là gì?

Tương tự như nói đến kiến trúc tòa nhà.

Kiến trúc chỉ hình dạng tổng thể của cấu trúc vật lý.

Kiến trúc là cách thức mà các thành phần(component)khác nhau được tích hợp lại để tạo nên một tồng thể thống nhất.

Kiến trúc còn chỉ ra cách mà tòa nhà còn phải phù hợp với môi trường và hòa hợp với các tòa nhà khác trong vùng.

Kiến trúc phần mềm (software architecture) của 1 chương trình hay hệ thống máy tính là cấu trúc của hệ thống bao gồm thành phần phần mềm (software component), các thuộc tính nhìn thấy được của thành phần và mối quan hệ giữa chúng.

2.4 Thiết kế kiến trúc
thi t k ki n tr c
Thành phần phần mềm (software component) có thể đơn giản là một module chương trình hay một class hướng đối tượng hay cũng có thể là cả một database hay “middleware”

Thuộc tính của thành phần (properties of components) là các đặc tính cần thiết để nhận biết sự tương tác giữa các thành phần như thế nào. Ở mức thiết kế kiến trúc, các thuộc tính nội bộ như chi tiết 1 giải thuật chưa cần phải xác định.

Mối quan hệ giữa các thành phần nếu đơn giản có thể giống như phép gọi thủ tục từ 1 module này đến module khác, nếu phức tạp thì giống như protocol truy xuất CSDL.

Thiết kế kiến trúc
thi t k ki n tr c1
Kiến trúc không phải là phần mềm vận hành (operational software).

Kiến trúc cho phép kỹ sư phần mềm:

Phân tích tính hiệu quả của thiết kế xem có đáp ứng các yêu cầu hay không?

Khảo sát các chọn lựa kiến trúc khác nhau

Giảm các rủi ro liên quan đến việc xây dựng phần mềm

Thiết kế kiến trúc
t m quan tr ng c a thi t k ki n tr c
Bản thiết kế của kiến trúc phần mềm là cách cho phép giao tiếp giữa các stakeholder trong quá trình phát triển hệ thống

Kiến trúc sẽ giúp ra các quyết định thiết kế sớm có ảnh hưởng lớn đến sự thành công sau này của hệ thống

Chính kiến trúc tạo ra mô hình cho thấy hệ thống được cấu trúc như thế nào và các thành phần làm việc với nhau như thế nào (how)

Tầm quan trọng của thiết kế kiến trúc
c c m u ki n tr c architecture pattern and style
Phần mềm có thể được xây dựng theo một trong các mẫu kiến trúc)

Mỗi mẫu kiến trúc mô tả một loại hệ thống bao gồm:

Tập hợp các thành phần (database, computational modules) thực thi chức năng được yêu cầu bởi hệ thống.

Tập các kết nối (connector) thành phần

Các ràng buộc (constraint) xác định thành phần được tích hợp như thế nào

Các mô hình ngữ nghĩa (semantic model) cho phép nhà thiết kế hiểu được các thuộc tính tổng thể của hệ thống bằng cách phân tích các thuộc tính đã biết của các thành phần

Các mẫu kiến trúc(Architecture pattern and style)
ph n bi t gi a pattern v style
Phạm vi của pattern hẹp hơn, tập trung vào một ngữ cảnh nào đó hơn là kiến trúc tổng thể

Có thể dùng lẫn lộn cả hai thuật ngữ này

Phân biệt giữa pattern và style
m t s m u ki n tr c chung
Data-centered architecture

Data-flow architecture

Main program/subprogram architecture

Object-oriented architecture

Layered architecture

Một số mẫu kiến trúc chung
ki n tr c data centered
Kho dữ liệu (data store) nằm ở trung tâm kiến trúc này và được truy xuất thường xuyên bởi các thành phần khác để cập nhật, thêm, xóa hay sửa đổi dữ liệu trong kho. Kiến trúc Data-centered
ki n tr c data flow
Kiến trúc Data-flow được áp dụng khi dữ liệu đầu vào bị biến đổi thông qua 1 chuỗi các tính toán hay tạo ra các thành phần thành dữ liệu của đầu ra.

Ví dụ mẫu pipe and filter có 1 tập các component, được nối với nhau bởi các pipe để truyền dữ liệu từ thành phần này đến thành phần khác. Mỗi filter làm việc độc lập nhau, được thiết kế để dành cho 1 lọai dữ liệu đầu vào nào đó và tạo dữ liệu ra ở 1 dạng nào đó cho filter kế tiếp.

Kiến trúc Data Flow
slide65

Main program

Controller

subprogram

Controller

subprogram

Controller

subprogram

Application

subprogram

Application

subprogram

Application

subprogram

Application

subprogram

Application

subprogram

Application

subprogram

Application

subprogram

Cấu trúc Main program/ subprogram

ki n tr c h ng i t ng object oriented architectures
Các thành phần của hệ thống chứa vừa dữ liệu vừa thao tác (operation)

Việc giao tiếp giữa các thành phần được thực hiện thông qua các thông điệp (message) gửi cho nhau

Kiến trúc hướng đối tượng(Object-oriented architectures)
ki n tr c call and return
Cho phép người thiết kế phần mềm tạo cấu trúc chương trình dễ chỉnh sửa và mở rộng.

Hai kiểu chính :

Main program/subprogram architectures.

Remote procedure call architectures.

Kiến trúc call and return
p d ng c c ki u ki n tr c
Các kiểu kiến trúc này chỉ là 1 tập con trong số rất nhiều kiểu kiến trúc khác.

Sau khi thu thập yêu cầu phát hiện ra các đặc tính (characteristic) và ràng buộc (constraint) của hệ thống, nhà thiết kế có thể chọn một hay tập hợp các kiểu kiến trúc nào phù hợp nhất với các đặc tính của hệ thống đó.

Co thể có nhiều chọn lựa khác (alternative) cho cùng 1 hệ thống.

Áp dụng các kiểu kiến trúc
tr nh t thi t k ki n tr c
Ngay khi bắt đầu thiết kế kiến trúc, phần mềm cần xây dựng phải được đặt vào trong ngữ cảnh liên quan đến:

Thực thể bên ngoài

Bản chất của sự tương tác giữa phần mềm và thực thế

Sau khi đã mô hình hóa ngữ cảnh và giao diện bên ngoài, cần xác định và tinh chỉnh các thành phần phần mềm để thực thi kiến trúc.

Quy trình này sẽ lặp lại cho đến khi hoàn tất kiến trúc thiết kế

Trình tự thiết kế kiến trúc
bi u di n h th ng theo ng c nh
Khi phân tích hệ thống thì lược đồ ngữ cảnh (System Context Diagram – DFD mức 0) được dùng để biểu diễn dòng thông tin vào và ra của hệ thống

Khi thiết kế kiến trúc thì lược đồ ngữ cảnh kiến trúc ( Architectural Context DiagramACD) được dùng để mô hình hóa cách thức phần mềm tương tác với các thực thể bên ngoài.

Biểu diễn hệ thống theo ngữ cảnh
slide73

Superordinate systems

Cấu trúc chung của architectural Context Diagram

Used by

Target system

Peers

uses

uses

Actors

Depends on

Subordinate systems

c u tr c c a acd
Superordinate system: hệ thống sử dụng hệ thống đích để thực hiện các xử lý mức cao hơn

Subordinate system: hệ thống được dùng bởi hệ thống đích, cung cấp dữ liệu hay các xử lý cần thiết để giúp hệ thống đích hoàn thành chức năng

Peer-level system: hệ thống tương tác 1-1

Actor: thực thể (con người, thiết bị) tương tác với hệ thống đích .

Mỗi thực thể bên ngoài tương tác với hệ thống đích thông qua giao diện (interface)

Cấu trúc của ACD
slide75

Superordinate systems

Ví dụ : ACD của SafeHome

Safehome

product

Internet-based

system

Used by

Target system:

Security function

Peers

Control panel

Surveillance

system

uses

Homeowner

uses

Actors

Depends on

Sensors

Sensors

Subordinate systems

nh x d ng d li u th nh ki n tr c
Thiết kế kiểu cấu trúc (Structured design) thường được mô tả như một phương pháp thiết kế hướng dòng dữ liệu (data flow-oriented).

Nó cung cấp 1 cách chuyển đổi thuận tiện từ DFD thành kiến trúc phần mềm theo quy trình 7 bước.

Ánh xạ dòng dữ liệu thành kiến trúc
quy tr nh b y b c chuy n t dfd sang thi t k ph n m m
Xem lại mô hình hệ thống cơ bản

Xem và tinh chỉnh lại DFD ở các mức 2 và 3

Xác định xem DFD có đặc tính transform flow hay transaction flow không?

Cô lập điểm transform center

Thực hiện "first-level factoring” (phân chia mức đầu tiên)

Thực hiện “second-level factoring” (phân chia mức thứ cấp)

Tinh chỉnh lại kiến trúc dựa vào heuristics

Quy trình bảy bước chuyển từ DFD sang thiết kế phần mềm
d ng th ng tin
Loại dòng thông tin (information flow) sẽ quy định cách ánh xạ trong bước 3. Có 2 loại dòng:

Transform flow

Transaction flow

Một DFD có thể được đặc trưng bằng cả hai loại dòng transform flow và transaction flow.

Dòng thông tin
transform flow
Thông tin được đưa vào hoặc xuất ra bên ngoài phần mềm trong dạng "external world" . Ví dụ: dữ liệu đưa vào từ bàn phím, giọng nói qua điện thoại, hình ảnh … là thông tin bên ngoài.

Dữ liệu bên ngoài này cần phải đuợc biến đổi thành dạng “internal” để được xử lý.

Thông tin được đưa vào hệ thống dọc theo các đường dẫn (path) được gọi là dòng vào (incoming flow).

Bên trong phần mềm, dữ liệu vào sẽ được đưa vào trung tâm biến đổi (transform center) và bắt đầu chuyển dọc theo các đường dẫn để xuất ra ngoài được gọi là dòng ra (outgoing flow).

Trong lược đồ DFD, nếu dòng dữ liệu xảy ra 1 cách tuần tự (sequential) theo dạng đường thẳng (straight line) thì phần lược đồ đó có đặc tính transform flow

Transform Flow
transaction flow
Mô hình hệ thống cơ bản thường thuộc dạng transform flow, mọi dòng dữ liệu đều có thể được đặc trưng theo dạng này.

Dòng thông tin cũng có thể được đặc trưng bởi 1 mục dữ liệu (data item) nào đó mà mục dữ liệu này có thể kích khởi (trigger) các dòng dữ liệu khác dọc theo 1 hay nhiều đường dẫn. Mục dữ liệu này được gọi là transaction.

Transaction flow được đặc trưng bởi dữ liệu di chuyển dọc theo 1 incoming path để biến thông tin của thế giới bên ngoài thành 1 transaction  transaction đuợc đánh giá và dựa vào giá trị của nó mà dòng sẽ đi theo 1 trong nhiều action path.

Nơi mà các dòng thông tin tỏa ra được gọi là transaction center.

Transaction Flow
transform mapping
Transform mapping là một tập hợp các bước thiết kế cho phép DFD có đặc tính transform flow được ánh xạ thành 1 kiểu kiến trúc xác định nào đó. Transform mapping
v d 7 b c thi t k
Bước 1: xem lại mô hình hệ thống cơ bản và thông tin hỗ trợ. Cần xem lại SRS và đặc tả hệ thống (system specification), cả hai mô tả DFD mức 0 và 1.

Bước 2: xem và tinh chỉnh lại DFD ở các mức 2 và 3. Ví dụ khảo sát DFD mức 2 dành cho việc giám sát các cảm biến (sensor) và DFD mức 3 được suy dẫn từ mức 2. Ở mức 3, mỗi process tương ứng với 1 phép transform đều thực hiện 1 chức năng riêng biệt nào đó mà có thể triển khai như một module trong phần mềm. Vì vậy, DFD mức 3 này chứa chi tiết vừa đủ cho thiết kế kiến trúc của hệ thống con (cảm biến) và không cần tinh chỉnh thêm nữa.

Ví dụ: 7 bước thiết kế
slide86

Level 2 DFD

that refines the

monitor sensors

process

v d 7 b c thi t k1
Bước 3: xác định xem DFD có đặc tính transform flow hay transaction flow không?

Nói chung thì dòng thông tin trong 1 hệ thống thường đều có thể biểu diễn như dạng transfom. Nhưng nếu DFD có đặc tính transaction rõ ràng thì nên theo cách ánh xạ của transaction flow. Các miền cục bộ (local region) của transform flow hay transaction flow đều bị cách ly nhau. Các dòng con này có thể được dùng để tinh chỉnh kiến trúc chương trình đã được suy dẫn từ đặc tính tổng thể chung trước đó.

Ở DFD mức 3, dữ liệu đưa vào phần mềm dọc theo 1 incoming path và đi ra dọc theo 3 outgoing path và không có transaction center rõ ràng. Vì vậy dòng thông tin của lược đồ này là transform.

Ví dụ: 7 bước thiết kế
v d 7 b c thi t k2
Bước 4: cô lập transform center bằng cách xác định đường biên (boundary) của các dòng vào và ra. Đường biên của dòng vào và ra không cần phải quá khắt khe và tùy theo nhà thiết kế, có thể vị trí của biên là những điểm khác nhau trên các dòng.

Có thể có nhiều kết quả thiết kế khác nhau bằng cách thay đổi vị trí của các đường biên dòng. Việc thay đổi vị trí biên này nói chung không ảnh hưởng nhiều tới cấu trúc cuối cùng của chương trình.

Các transform tạo nên transform center sẽ nằm bên trong hai đường biên.

Ví dụ: 7 bước thiết kế
slide90

DFD mức 3 với các

Đường biên dòng

(flow boundary)

v d 7 b c thi t k3
Bước 5: thực hiện "first-level factoring” (phân chia mức đầu tiên)

Cấu trúc chương trình biểu diễn sự phân phối các control từ trên xuống dưới.

Việc phân chia (factoring) sẽ tạo ra trong cấu trúc chương trình module mức cao thực thi việc ra quyết định, và các module mức thấp thực thi hầu hết các ngõ vào, biến đổi và ngõ ra. Các module mức giữa thực thi 1 số control và làm một số công việc mức trung bình.

Khi phép biến đổi (transform) được đưa vào, DFD được ánh xạ thành 1 cấu trúc xác định nào đó (vd: call and return architecture) chứa control dành cho việc xử lý ngõ vào, biến đổi và xử lý thông tin ngõ ra.

Ví dụ: 7 bước thiết kế
v d 7 b c thi t k4
Bước 5 (tt):

Controller chính (monitor sensors executive) nằm ở đỉnh của cấu trúc chương trình và phối hợp với các control phía dưới

Sensor input controller: nhận tất cả dữ liệu ngõ vào

Alarm conditions controller: giám sát tất cả các thao tác liên quan đến dữ liệu

Alarm output controller: phối hợp để tạo ra thông tin ngõ ra.

Những hệ thống lớn thì có thể có nhiều hơn 2 control module cho mỗi chức năng điều khiển.

Số module ở phân chia mức đầu tiên này nên hạn chế it nhất sao cho vẫn hoàn thành đuợc chức năng điều khiển và vẫn giữ được đặc tính coupling và cohesion

Ví dụ: 7 bước thiết kế
slide94

Phân chia

mức 1

v d 7 b c thi t k5
Bước 6: Thực thi "second-level factoring." (phân chia mức hai)

Việc phân chia mức hai được hoàn thành bằng cách ánh xạ các transform đơn lẻ của DFD thành các module thích hợp bên trong cấu trúc. Bắt đầu từ đường biên của transform center và chuyển dần ra ngoài dọc theo đường dẫn vào rồi sau đó theo đuờng dẫn ra. Các transform được biến đổi thành các control mức dưới.

Thực tế hai hay nhiều hơn các transform kết hợp lại để biểu diễn 1 module hay một transform có thể được mở rộng thành 2 hay nhiều module hơn.

Ví dụ: 7 bước thiết kế
v d 7 b c thi t k6
Bước 7: tinh chỉnh lại kiến trúc ở lần lặp đầu (first-iteration) bằng thiết kế heuristic

Kiến trúc nên được tinh chỉnh lại. Các thành phần có thể triển khai hay rút gọn lại sao cho việc phân rã hợp lý hơn, cohesion tốt hơn, giảm coupling.

Những chỉnh sửa ở bước này sẽ tốn thời gian và công sức nhưng có thể có ảnh hưởng lớn đến chất lượng phần mềm

Ví dụ: 7 bước thiết kế
transaction mapping
Ví dụ: Khảo sát hệ thống con user interaction của hệ thống SafeHome

Các bước 1, 2 và 3 tương tự như transform mapping

Bước 1: xem lại mô hình hệ thống cơ bản

Bước 2: xem và tinh chỉnh lại DFD ở các mức 2 và 3

Bước 3: xác định xem DFD có đặc tính transform hay transaction flow

Transaction mapping
transaction mapping1
Bước 3: xác định xem DFD có đặc tính transform hay transaction flow

Mục dữ liệu command type làm cho dòng dữ liệu tỏa ra  DFD có đặc tính transaction flow.

Tuy nhiên hai action path tỏa ra từ Invoke command processing thì dường như có đặc tính transform flow. Vì vậy cần xác định đường biên cho cả loại dòng này.

Transaction mapping
transaction mapping2
Bước 4: xác định transaction center và đặc tính dòng dọc theo mỗi action path

Transaction center là nút Invoke command processing. Tất cả path vào và ra khỏi tâm này cần phải được cô lập lại.

Kế đến mỗi action path cần được đánh giá xem nó có đặc tính dòng nào?

Xét nhánh Password: nó có đặc tính transform nên nó có các đường biên riêng

Transaction mapping
transaction mapping3
Bước 5: ánh xạ DFD thành cấu trúc chương trình

Transaction flow được ánh xạ thành 1 cấu trúc chứa 1 nhánh vào (incoming branch) và 1 nhánh gửi đi (dispatch branch).

Cấu trúc của nhánh vào được phát triển tương tự như transform mapping. Xuất phát từ transaction center, các nút dọc theo đường dẫn vào (incoming path) được ánh xạ thành các module.

Cấu trúc của nhánh gửi đi chứa 1 dispatcher module (module điều vận) sẽ điều khiển tất cả các action module phía dưới nó.

Mỗi action path được ánh xạ thành 1 cấu trúc tương ứng với đặc tính dòng của nó.

Transaction mapping
slide108
Bước 6: phân chia và tinh chỉnh lại cấu trúc transaction và cấu trúc của mỗi action path

Bước 7: Tinh chỉnh lại kiến trúc lặp lần đầu (first-iteration) bằng thiết kế heuristic