Phân tích và thiết kế

13/08/2020
Mục đích
Khoa HTTT Kinh tế và TMĐT • Cung cấp cho sinh viên những khái niệm cơ bản, nguyên lý chung
trong phân tích thiết kế hệ thống.
Bộ môn Công nghệ thông tin • Cung cấp kiến thức phân tích thiết kế hệ thống theo cách tiếp cận
hướng đối tượng và sử dụng ngôn ngữ UML
Sinh viên có thể áp dụng trong một số bài toán đời sống như quản lý
Bài giảng học phần kinh doanh, dịch vụ,…
Phân tích và Thiết kế Hệ thống thông tin
20/12/2013 Bộ môn CNTT - Khoa HTTT Kinh tế và TMDT 2
Mục tiêu học phần Cấu trúc và nội dung

 Explain the systems analyst’s role information systems development. • Cấu trúc: 3 tín chỉ (36,9)
 Describe the basic systems development life cycle and its phases. • Nội dung:
 Explain how organizations identify IS development projects. • Chương 1. Tổng quan về phân tích & thiết kế HT
 Explain the importance of linking the information system to business needs. • Chương 2: Ngôn ngữ mô hình hóa và công cụ PTTK
 Be able to create a system request. • Chương 3. Phân tích thiết kế hệ thống theo hướng đối tượng
 Describe technical, economic, and organizational feasibility assessment. • Chương 4: Thiết kế hệ thống theo hướng đối tượng
 Be able to perform a feasibility analysis. • Đánh giá: thi hết học phần + bài tập lớn
20/12/2013 Bộ môn CNTT - Khoa HTTT Kinh tế và TMDT 3 20/12/2013 Bộ môn CNTT - Khoa HTTT Kinh tế và TMDT 4
1
13/08/2020
Tài liệu tham khảo Chương 1. Tổng quan về PTTKHT

• Phân tích thiết kế các hệ thống thông tin hiện đại. Nguyễn Văn Vỵ, 1.1. Phương pháp luận về phân tích thiết kế hệ thống
Thống Kê, 2002. 1.1.1. Một số khái niệm cơ bản
1.1.2. Mô hình hóa hệ thống
• Phân tích và thiết kế hướng đối tượng, Đặng Văn Đức, NXB Giáo 1.1.3. Quy trình phân tích thiết kế hệ thống
Dục, 2002.
1.2. Các hướng tiếp cận trong phân tích thiết kế
• System Analysis and Design - Complete Introductory Tutorial for 1.2.1. Tiếp cận hướng chức năng
Software Engineering. http://www.freetutes.com/systemanalysis 1.2.2. Tiếp cận hướng đối tượng
• Phân tích và thiết kế Hệ thống thông tin với UML. Đặng Văn Đức, 1.2.3. Đánh giá các hướng tiếp cận
NXB Giáo dục
1.1 Phương pháp luận về PTTKHT 1.1.1 Một số khái niệm cơ bản
1.1.1. Một số khái niệm cơ bản • Khái niệm
1.1.2. Mô hình hóa hệ thống • Hệ thống: là tập hợp gồm nhiều thành phần/đối tượng có tổ chức và tương tác
1.1.3. Quy trình phân tích thiết kế hệ thống với nhau nhằm thực hiện các mục tiêu chung.
• Ví dụ: hệ thống điều khiển giao thông, hệ thống mạng máy tính
• HT mở: là HT trong đó tồn tại một số thành phần có tương tác với môi trường
bên ngoài
2
13/08/2020
1.1.1 Các khái niệm cơ bản 1.1.1 Các khái niệm cơ bản
• Khái niệm
• HT quản lý: là các phương tiện, biện pháp để theo dõi, kiểm tra và định hướng hoạt
động của tổ chức nhằm đạt được mục tiêu đã đề ra
• Thành phần
• Hệ thống quyết định: xác định mục tiêu mà tổ chức phải vươn tới, tác động lên HT tác vụ để
thực hiện mục tiêu đó
• Hệ thống tác vụ: thực hiện các hoạt động của tổ chức theo chiến lược mà HT quyết định đề ra
• Hệ thống thông tin: phân tích và cung cấp TT về tình hình của HT tác vụ và chuyển các chỉ thị
của HT quyết định cho HT tác vụ
• Chú ý: ranh giới phân chia các thành phần
Mối quan hệ các thành phần trong HT quản lý
Các sự kiện tiến hóa

1.1.1 Các khái niệm cơ bản (Cập nhập)
Dữ liệu
• Vai trò của HTTT: • Các thành phần của HTTT Về cấu trúc cơ quan
• Thu thập TT • Con người và thiết bị

TT ngoài
• Xử lý TT • Dữ liệu: Là các thông tin được lưu và duy Dữ Các tham Xử lý
• Truyền thông tin trì nhằm phản ánh thực trạng hiện thời liệu số
- Các quy tắc quản lý
- Các thủ tục
hay quá khứ của DN vào
• Các xử lý: Là những quá trình biến đổi TT
nội
thông tin, nhằm:
Dữ liệu bộ
• Sinh ra các thông tin theo thể thức quy định Về hoạt động KD/DV
• Trợ giúp ra các quyết định
(Thu thập)
Các sự kiện hoạt động

3
13/08/2020
1.1.1 Các khái niệm cơ bản

• Phân loại các HTTT:
• HT xử lý dữ liệu (DPS – Data Processing System)
• HTTT quản lý (MIS – Management Information System)
• HT hỗ trợ quyết định (DSS – Decision Support System)
• Hệ chuyên gia (ES – Expert System)
Người phân tích hệ thống

Nguyên tắc và kỹ năng
Nguyên tắc phân tích thiết kế Nguyên tắc phân tích thiết kế
Systems Analyst Role Systems Analyst Roles
 Key role in developing information systems  Interaction with an array of people
o Analyzing the business situation o Technical specialists (DBAs, network admins, programmers)
o Identifying opportunities for improvements o Business people (users, managers, steering committee)
o Designing an information system to implement the improvements o Others (vendors, consultants)
 Variety of specialized roles
o People-oriented: change management analyst, project management
o Business-oriented: requirements analyst, business analyst
o Technically-oriented: infrastructure analyst
o Generalist: systems analyst
4
13/08/2020
What Do System Analysts Like What Do System Analysts Dislike

About Their Work? About Their Work?
 Challenge (Thử thách)  Management’s lack of communication/recognition
 Technology (Công nghệ)  End-user mistakes and demands
 Variety (Đa dạng)  Stress/pressure/burnout
 Constant Change (Thường xuyên thay đổi)  Ever-changing business technology
 Problem Solving (Giải quyết vấn đề)  Unrealistic deadlines
Preparing for Your Career 1.1.2 Mô hình hóa hệ thống

 Working knowledge of information technology • Nguyên lý chế ngự sự phức tạp: Lờ đi những chi tiết không quan trọng
 Computer programming experience & expertise • Khái niệm mô hình: là một dạng trừu tượng hóa của một hệ thống thực.
 General business knowledge Hay mô hình là một biểu diễn của một hệ thống thực, được diễn tả:
• Ở một mức độ trừu tượng hóa nào đó
 Problem-solving skills
• Theo một quan điểm (góc nhìn) nào đó
 Interpersonal communication skills • Bởi một hình thức hiểu được nào đó (văn bản, bảng, đồ thị …)
 Flexibility and adaptability • Khái niệm mô hình hóa: là việc dùng mô hình để nhận thức và diễn tả
 Character and ethics một hệ thống
 Systems analysis & design skills
5
13/08/2020
1.1.2 Mô hình hóa hệ thống 1.1.2 Mô hình hóa hệ thống

• Mục đích của mô hình hóa: • Các phương diện mô tả hệ thống (bốn trục mô hình hóa)
• Để hiểu • Mô tả các chức năng HT phải thực hiện
• Để trao đổi • Mô tả các đặc điểm tĩnh của hệ thống: các thông tin, các quan hệ
• Mô tả cách ứng xử của HT
• Để hoàn chỉnh
• Mô tả kiến trúc của HT (các thành phần)
• Hiện nay: PTTKHT sử dụng các mô hình dạng biểu đồ (diagram) • Các phương pháp mô hình hóa
• Mức độ mô hình hóa HT • Các phương pháp hệ thống
• Mức logic • Các phương pháp hướng chức năng/ cấu trúc
• Mức vật lý • Phương pháp theo sự kiện
 Mọi quá trình phát triển hệ thống luôn có hai giai đoạn phân biệt: phân tích • Các phương pháp hướng dữ liệu
và thiết kế • Các phương pháp hướng đối tượng
1.1.3. Quy trình phân tích thiết kế hệ thống

• Giai đoạn 1: Khảo sát dự án Vòng đời phát triển hệ thống (SDLC)
•
•
Giai đoạn 2: Phân tích hệ thống
Giai đoạn 3: Thiết kế
The Systems Development Life Cycle
• Giai đoạn 4: Thực hiện
• Giai đoạn 5: Kiểm thử
• Giai đoạn 6: Triển khai và bảo trì The overall process of systems development
6
13/08/2020
Làm thế nào để xây dựng các hệ thống? Pha lập kế hoạch
How Do Systems Get Built? Planning Phase
Systems Development Life Cycle (SDLC)
 Project Initiation
 Planning
 Analysis
o Prepare system request
 Design o Perform preliminary feasibility analysis
 Implementation  Set Up the Project
Obsolete System
On-going Systems Planning
New Project Launched o Project Plan, including work plan & staffing plan
Planning
Implementation
Planned
System Project
System Design Analysis
Specifications Requirements
Pha phân tích Pha thiết kế

Analysis Phase Design Phase
 Determine Analysis Strategy  Determine Design Strategy
o Study existing system and its problems o Build / Buy / Outsource
 Collect and Analyze Requirements  Design system components
o Develop new system concept
o Describe new system with analysis models
o Architecture, interface, database, programs
 Prepare and Present System Proposal o Assemble design elements into System Specification
o Summarize results of the Analysis Phase  Present to steering committee
o Go/No Go decision made by sponsor and steering committee
o Go / No Go decision before entering final phase
7
13/08/2020
Pha cài đặt 1.2 Các hướng tiếp cận trong PTTKHT
Implementation Phase 1.2.1. Tiếp cận hướng cấu trúc
 System Construction 1.2.2. Tiếp cận hướng đối tượng
o Programming and testing 1.2.3. Đánh giá các hướng tiếp cận
 System Installation
o Training
o Conversion to new system
 On-going system support
1.2.1 Cách tiếp cận hướng cấu trúc 1.2.1 Cách tiếp cận hướng cấu trúc
QL DN
• Tư tưởng: Lấy chức năng làm đơn vị phân rã HT
• Đặc điểm:
• Dựa vào chức năng là chính
QL Nhân sự QL Tài chính QL Vật tư QL KH
• Phân rã chức năng và làm mịn dần theo cách thực hiện từ trên xuống
• Các đơn thể chức năng trao đổi với nhau bằng cách truyền tham số hoặc
sử dụng dữ liệu chung
Giải
• Tính mở và thích nghi của HT bị hạn chế Theo Trả KT thu
KT QL
QL Vật quyết Tiếp
Tổng Thiết
• Khả năng tái sử dụng bị hạn chế và không hỗ trợ cơ chế kế thừa dõi NS công chi
hợp bị
liệu Đơn thị
hàng
8
13/08/2020
1.2.3. Đánh giá các hướng tiếp cận

1.2.2 Cách tiếp cận hướng đối tượng Tiếp cận hướng cấu trúc
• Tư tưởng: Lấy thực thể/ đối tượng là đơn vị phân rã HT • Ưu điểm: • Nhược điểm:
• Tư duy phân tích thiết kế rõ • Không hỗ trợ việc sử dụng lại. Các chương trình
• Đặc điểm: ràng. hướng cấu trúc phụ thuộc chặt chẽ vào cấu trúc
• Đặt trọng tâm vào dữ liệu • Chương trình sáng sủa dễ hiểu. dữ liệu và bài toán cụ thể, do đó không thể dùng
• Xem HT như là tập các thực thể, đối tượng • Phân tích được các chức năng lại modul nào đó trong phần mềm này cho phần
• Các lớp trao dổi với nhau bằng thông điệp của hệ thống mềm khác với các yêu cầu về dữ liệu khác.
• Tính mở và thích nghi của HT cao hơn • Dễ theo dõi luồng dữ liệu. • Không phù hợp cho phát triển các phần mềm lớn.
• Hỗ trợ sử dụng lại và cơ chế kế thừa. • Khó quản lý mối quan hệ giữa các modul và dễ
gây ra lỗi trong phân tích cũng như khó kiểm thử
và bảo trì.
1.2.3. Đánh giá các hướng tiếp cận

Tiếp cận hướng đối tượng Lĩnh vực áp dụng
• Ưu điểm: • Nhược điểm: • Phương pháp hướng cấu trúc • Phương pháp hướng đối tượng
• Gần gũi với thế giới thực. • Phương pháp này khá phức tạp, khó thường phù hợp với nhiều bài thường được áp dụng cho các bài
• Tái sử dụng dễ dàng. theo dõi được luồng dữ liệu do có
toán nhỏ, có luồng dữ liệu rõ toán lớn, phức tạp, hoặc có nhiều
• Đóng gói che giấu thông tin làm nhiều luồng dữ liệu ở đầu vào. Hơn luồng dữ liệu khác nhau mà
nữa giải thuật lại không phải là vấn ràng, cần phải tư duy giải
cho hệ thống tin cậy hơn. phương pháp cấu trúc không thể
• Thừa kế làm giảm chi phí, hệ
đề trọng tâm của phương pháp này. thuật rõ ràng và người lập quản lý được. Khi đó người ta
thống có tính mở cao hơn trình có khả năng tự quản lý dùng phương pháp hướng đối
• Xây dựng hệ thống phức tạp được mọi truy cập đến các dữ tượng để để tận dụng khả năng
liệu của chương trình. bảo vệ giữ liệu ngoài ra còn tiết
kiệm công sức và tài nguyên
9
13/08/2020
Các dự án IS đến từ đâu?

Where Do IS Projects Come From?
 Fulfill a business need
o Enable a business initiative or strategy
o Support a merger/acquisition
Khởi tạo dự án o Fix a “point of pain”
Project Initiation o Utilize a new technology

o Outgrowth of Business Process Management (BPM)
How projects get started
Quản trị quy trình kinh doanh là gì?

Quản trị quy trình kinh doanh là gì?
What is BPM? What is BPM? (continued)
 Business Process Management: A methodology used by  Four-step continuous cycle:
organizations to continuously improve end-to-end business o Define and map the steps in a business process,
processes o Create ways to improve on steps in the process that add value,
o Internal and cross-organizational processes o Find ways to eliminate or consolidate steps in the process that
o Benefits include: don’t add value,
▪ Enhanced process agility o Create or adjust electronic workflows to match the improved
▪ Process alignment with industry “best practices” process maps.
▪ Increased process efficiencies
10
13/08/2020
Xác định nhu cầu kinh doanh trong BPM Chúng ta đã có dự án chưa?
BPM Identifies Business Needs Do We Have a Project Yet?
 Business Process Automation  Strong business need leads to a person or group stepping up
o “Create or adjust electronic workflows to match the improved process maps” as the Project Sponsor
 Business Process Improvement o Driving force behind project
o Study the business processes o Specifies overall business requirements
o Create new, redesigned processes to improve the process workflows, and/or o Determines business value
o Utilize new technologies enabling new process structures
o Formally requests a project via the System Request
 Business Process Reengineering
o Total overhaul of work processes
Bài tập Yêu cầu

1. Phân tích và thiết kế HTTT Quản lý Nhân sự • Phân tích thiết kế các hệ thống trên theo hướng đối tượng
2. Phân tích và thiết kế HTTT Quản lý kinh doanh • Sử dụng hệ thống biểu đồ UML
3. Phân tích và thiết kế HTTT Quản lý Khách sạn. • Biên bản phân công công việc
4. Sinh viên tự chọn hệ thống (và phải được giáo viên duyệt) • Bản demo: Thiết kế các giao diện và kịch bản sử dụng (optional)
11
13/08/2020
Nội dung
2.1. Ngôn ngữ mô hình hóa thống nhất UML
Chương 2. Ngôn ngữ mô hình hóa 2.1.1. Giới thiệu
2.1.2. Các khái niệm cơ bản trong UML
và công cụ phân tích thiết kế 2.1.3. Các biểu đồ trong UML
2.2. Một số công cụ phân tích thiết kế
2.2.1. Giới thiệu
2.2.2. Công cụ phân tích
2.2.3. Công cụ thiết kế
2.1. Ngôn ngữ mô hình hóa thống nhất UML 2.1.1. Giới thiệu về UML
• Giới thiệu: UML là ngôn ngữ chuẩn để viết kế hoạch chi tiết phần mêm, được dùng để
mô hình hóa các hệ thống.
2.1.1. Giới thiệu
• Xuất xứ:
2.1.2. Các khái niệm cơ bản trong UML • T1/1994: Grady Booch & Jim Rumbaught (UML was developed by Grady Booch, Ivar
2.1.3. Các biểu đồ trong UML Jacobson and James Rumbaugh (The Three Amigos) )
• T10/1995: Ivar Jacobsson
• 14/11/1997: UML 1.1
• T6/2003: UML 2.0
• T2/2009: UML 2.2
• T5/2010: UML 2.3
• T3/2011: UML 2.4
• T6/2015: UML 2.5
12
13/08/2020
Tổng quan về UML 2.1.2. Các khái niệm cơ bản trong UML
 OMG Standard (Object Management Group Standard) • Hướng nhìn (view): cho phép biểu diễn nhiều hướng nhìn khác nhau
 The Unified Modeling Language (UML) của HT trong quá trình phát triển HT
 Data modeling, business modeling (work flows), object modeling, and component modeling
 UML aims to be a standard modeling language which can model concurrent and distributed Góc nhìn TK
(lớp, gói, đối tượng) Góc nhìn thực thi
systems
(thành phần)
 UML is a de-facto industry standard
 UML models may be automatically transformed to other representations (e.g. Java, PHP)
Góc nhìn ca sử dụng
 UML is extensible, through profiles, stereotypes and tagged values
(ca sử dụng)
Góc nhìn quá trình
 A lot of other languages are based on UML (SysML, SoaML) Góc nhìn bố trí
(trình tự, giao tiếp, máy
 Usually default language for a lot of architecture frameworks (MoDAF, DoDAF, NAF) (thành phần, bố trí)
trạng thái, hoạt động)
Bộ môn CNTT - Khoa HTTT Kinh tế và TMDT 49 20/12/2013 Bộ môn CNTT - Khoa HTTT Kinh tế và TMDT 50
20/12/2013
Các phần tử mô hình và các quan hệ Các phần tử mô hình và các quan hệ
• Các phần tử mô hình: là các biểu tượng, khái niệm sử dụng trong • Các quan hệ: gắn kết các phần tử lại với nhau
mô hình • Phụ thuộc (dependency): là quan hệ ngữ nghĩa giữa hai phần tử trong đó phần
• Phần tử cấu trúc: là các danh từ trong mô hình, biểu diễn các thành phần tử độc lập sẽ tác động đến ngữ nghĩa của phần tử phụ thuộc.
khái niệm hoặc vật lý. VD: lớp, giao diện, nút,... • Kết hợp/ (association): là quan hệ cấu trúc để mô tả tập liên kết giữa các đối
• Phần tử hành vi: là các động từ, biểu diễn hành vi theo tg, kg. VD: tương tượng. (giữa chúng có sự gửi/ nhận thông điệp)  quan hệ tụ hợp/kết tập
tác, trạng thái (aggregation)  quan hệ hợp thành (compositon)
• Phần tử nhóm: là bộ phận tổ chức của mô hình. Duy nhất: gói • Khái quát hóa (generalization): là quan hệ trong đó đối tượng cụ thể sẽ kế thừa
• Chú thích: là bộ phận chú giải của mô hình. VD: các thuộc tính và phương thức của đối tượng tổng quát
• Hiện thực hóa: là quan hệ ngữ nghĩa giữa giao diện và lớp/thành phần hiện
thực, giữa UC và hiện thực UC
13
13/08/2020
UML Diagram
2.1.3. Các biểu đồ trong UML
• Ý nghĩa: là ánh xạ của hệ thống, dùng để biểu diễn hệ thống đang
xây dựng dưới các góc độ quan sát khác nhau thông qua các phần tử
của mô hình.
• Biểu đồ Use case • Biểu đồ hoạt động
• Biều đồ lớp • Biểu đồ thành phần
• Biểu đồ trạng thái • Biểu đồ triển khai
• Biểu đồ tương tác
• Biểu đồ tuần tự
• Biểu đồ cộng tác
Kiến trúc hướng mô hình (MDA)

Integration of
the Four UML
Diagrams
20/12/2013 Bộ môn CNTT - Khoa HTTT Kinh tế và TMDT 55 56

20/12/2013 Bộ môn CNTT - Khoa HTTT Kinh tế và TMDT
14
13/08/2020
Phần tử mô Ý nghĩa Cách biểu diễn Ký hiệu trong biểu đồ

Biểu đồ Use case (Use case diagram) hình
Usecase Biểu diễn một chức năng Hình ellip chứa tên
• Ý nghĩa: xác định của hệ thống của các use case Usecase
Name
• Biểu diễn sơ đồ chức năng của hệ thống.

• Mỗi usecase mô tả một chức năng mà HT cần phải có xét từ góc độ người dùng. Tác nhân Là một đối tượng bên Biểu diễn bởi một
• Các biểu đồ usecase có thể phân rã theo nhiều mức khác nhau. ngoài hệ thống tương tác hình người tượng
trực tiếp với các Usecase trưng
• Các phần tử mô hình:
• Tác nhân:
• Các use case Mối quan Tùy từng dạng quan hệ Extend và Include
hệ giữa các có dạng mũi tên đứt
• Mối quan hệ giữa các use case:
use case nét, Generalization
• Include: sử dụng có dạng mũi tên tam
• Extend: mở rộng giác
• Generalization: kế thừa
Biên của hệ Tách biệt phần bên trong Được biểu diễn bởi
thống và bên ngoài hệ thống một hình chữ nhật
20/12/2013 Bộ môn CNTT - Khoa HTTT Kinh tế và TMDT 57 20/12/2013 rỗng
Bộ môn CNTT - Khoa HTTT Kinh tế và TMDT 58
Use cases
 Use cases are used to model the
Chi tiết trong các loại biểu đồ
requirements of a system (what a
system is supposed to do) Actors
 The key concepts associated with use
cases are actors, use cases, and the
subject.
 describes the relationships among a set Use cases
of use cases and the actors participating
in these use cases
 it does NOT describe behavior or flows
(WHO and WHAT, not HOW)
Subjects
15
13/08/2020
Use Case
Diagram with
Extends and
Use Case Includes
Diagram Associations
61 62
20/12/2013 Bộ môn CNTT - Khoa HTTT Kinh tế và TMDT 20/12/2013 Bộ môn CNTT - Khoa HTTT Kinh tế và TMDT
Biểu đồ lớp (Class diagram) Class diagram

Ý nghĩa:
- Biểu diễn cái nhìn tĩnh về hệ thống dựa trên các khái niệm lớp, thuộc tính và
phương thức.
Các phần tử mô hình:
- Lớp
- Thuộc tính:
Phạm_vi tên_thuộc_tính: kiểu_thuộc_tính
- Phương thức:
Phạm_vi Tên (danh sách tham số): kiểu trả về
16
13/08/2020
Biểu đồ lớp
Biểu đồ lớp
• Các kiểu lớp trong UML
Các mối quan hệ trong biểu đồ lớp:
• Khái quát hóa/tổng quát hóa (generalization):
• Quan hệ kết hợp (association):

• Quan hệ cộng hợp/ tụ hợp (Aggregation):
• Quan hệ hợp thành (composition)
• Quan hệ phụ thuộc (dependency):
Biểu đồ trạng thái

(State Machine diagram)
Ý nghĩa:
Multiplicity - Biểu diễn các trạng thái và sự
chuyển trạng thái của các lớp.
- Phạm vi của biểu đồ trạng
thái?
67 20/12/2013 Bộ môn CNTT - Khoa HTTT Kinh tế và TMDT 68

17
13/08/2020
Biểu đồ trạng thái Biểu đồ trạng thái

Phần tử mô Ý nghĩa Biểu diễn Ký hiệu
Các thành phần của biểu đồ trạng thái: hình
- Trạng thái (state) Trạng thái Biểu diễn một trạng Hình chữ nhật vòng ở
thái của đối tượng trong góc, gồm 3 phần: tên,
- Trạng thái con (substate)
vòng đời của đối tượng các biến và các hoạt
- Các kiểu trạng thái đó động
• Trạng thái bắt đầu
Trạng thái Khởi đầu vòng đời của Hình tròn đặc
• Trạng thái kết thúc khởi đầu đối tượng
• Các chuyển tiếp (transition)
• Sự kiện (event) Trạng thái Kết thúc vòng đời của Hai hình tròn lồng nhau
• Call event kết thúc đối tượng
• Signal event
• Time event Chuyển tiếp Chuyển từ trạng thái Mũi tên liền nét với tên
(transition) này sang trạng thái gọi là biểu diễn của
Tên chuyển
khác chuyển tiếp đó tiếp

Behavioral
State Machine
Diagram

18
13/08/2020

Timing diagram
Ví dụ: Trạng thái lớp thẻ mượn sách
Các thông điệp

Biểu đồ tuần tự STT Loại message Mô tả Biểu diễn
Ý nghĩa: 1 Gọi (call) Mô tả một lời gọi từ đối

- Biểu diễn mối quan hệ giữa các đối tượng và các tác nhân theo thứ tự thời gian. tượng này đến đối tượng
- Nhấn mạnh đến thứ tự thực hiện các tương tác. kia.
2 Trả về (return) Trả về giá trị tương ứng
Các phần tử mô hình: với lời gọi
- Đối tượng:
3 Gửi (send) Gửi một tín hiệu tới một
- Các thông điệp (message): đối tượng
4 Tạo (create) Tạo một đối tượng << Create>>
5 Hủy (destroy) Hủy một đối tượng << Destroy>>
19
13/08/2020
Chức năng thêm sách
Sequence
Diagram

Biểu đồ hoạt động

Activity diagram
Ý nghĩa:
- Biểu đồ hoạt động biểu diễn các hoạt động và sự đồng bộ, chuyển
tiếp các hoạt động của hệ thống trong một lớp hoặc kết hợp giữa
các lớp với nhau trong một chức năng cụ thể.
Các phần tử mô hình:
- Hoạt động:
- Thanh đồng bộ hóa:
- Điều kiện
- Các luồng (swimlane)
20
13/08/2020
Biểu đồ tương tác tổng

Biểu đồ hoạt động quát
Activity diagram Interaction Overview
Diagram
Biểu đồ thành phần

Component diagram
Ý nghĩa:
• Biểu đồ thành phần được sử dụng để biểu diễn các thành phần phần
mềm cấu thành nên hệ thống.
• Một hệ phần mềm có thể được xây dựng từ đầu bằng cách sử dụng
mô hình lớp như đã trình bày trong các phần trước của tài liệu, hoặc
cũng có thể được tạo nên từ các thành phần sẵn có (COM, DLL).
21
13/08/2020
Biểu đồ thành phần Biểu đồ thành phần

Component diagram Component diagram
Biểu đồ gói Biểu đồ gói

Package diagram Package diagram
• Ý nghĩa
• Được sử dụng để nhóm các phần tử và
cung cấp tên cho các phần tử được nhóm
• Tên đủ điều kiện: package name::element name
• Có 2 kiểu:
• «import» for a public package import =>
transitive: if A imports B and B imports C
then A indirectly imports C
• «access» for a private package import =>
intransitive
22
13/08/2020
Biểu đồ gói Biểu đồ triển khai

Package diagram Deployment diagram
Ý nghĩa:
- Biểu đồ triển khai biểu diễn kiến trúc cài đặt và triển khai hệ thống dưới dạng
các nodes và các mối quan hệ giữa các node đó. Thông thường, các nodes được
kết nối với nhau thông qua các liên kết truyền thông như các kết nối mạng, liên
kết TCPIP, microwave…
Phần tử mô Ý nghĩa Ký hiệu trong biểu đồ Biểu đồ triển khai

hình
Các nodes (hay Biểu diễn các thành phần không
Deployment diagram
các thiết bị) có bộ vi xử lý trong biểu đồ
triển khai hệ thống
Các bộ xử lý Biểu diễn các thành phần có bộ

xử lý trong biểu đồ
Các liên kết Nối các thành phần của biểu đồ

truyền thông triển khai hệ thống. Thường mô
tả một giao thức truyền thông
cụ thể.
23
13/08/2020
Biểu đồ triển khai

Deployment diagram Biểu đồ giao tiếp
Communication diagram
• Ý nghĩa
• Mô tả tương tác giữa các đối tượng trong hệ thống và thứ tự các
thông điệp được thực hiện trong các tương tác. Mỗi đối tượng sẽ có
một biểu đồ giao tiếp trong hệ thống khác nhau
Biểu đồ giao tiếp 2.2. Một số công cụ phân tích thiết kế

Communication
diagram 2.2.1. Giới thiệu
2.2.2. Công cụ phân tích
2.2.3. Công cụ thiết kế
24
13/08/2020
2.2.1. Giới thiệu 2.2.1. Giới thiệu (tt)

• Công cụ trợ giúp (CASE): là các phần mềm hỗ trợ cho quá trình phát
triển hệ thống. Bao gồm: • Rational Rose
• Công cụ hỗ trợ cho ngôn ngữ lập trình • Visio
• Công cụ hỗ trợ ngôn ngữ mô hình hóa • StarUML
• Công cụ hỗ trợ tiến trình phát triển HT • UML designer tool
• Draw.IO
• …
Rational Rose Visio
25
13/08/2020
StarUML UML designer tool
Draw.IO 2.2.3. Công cụ thiết kế
26
13/08/2020
Câu hỏi ôn tập Chương 2

• Trình bày các khái niệm cơ bản về UML? CHƯƠNG 3:
• Rational Rose có vai trò như thế nào trong phân tích, thiết kế HTTT
theo HĐT? PHÂN TÍCH HỆ THỐNG THEO HƯỚNG ĐỐI TƯỢNG
• Các công cụ phân tích ?
Tổng quan về pha phân tích

Nội dung
Overview of the Analysis Phase
3.1. Phân tích yêu cầu hệ thống
 Goal is to develop a clear understanding of the new system’s
3.2. Biểu đồ usecase
requirements
o Understand the “As-Is” system 3.3. Biểu đồ lớp
o Identify Improvements 3.4. Biểu đồ tương tác
o Develop the “To-Be” system concept 3.5. Biểu đồ trạng thái và biểu đồ hoạt động
 Use critical thinking skills to determine the true causes of
problems
 Apply knowledge of IS and business to outline ways to solve the
problems in the new system
27
13/08/2020
Yêu cầu hệ thống

System Request
 Describes business reasons for project
 Defines system’s expected value
Yêu cầu của hệ thống o Force the sponsor to formalize his/her ideas
The Systems Request o Provide a framework for collecting initial project information
o Standardize information to be used by steering (approval)
The business reasons for the new system committee
 Lists project’s key elements
Systems Request
Elements of the for Tune Source
Systems Music Download
Request System
111 112
28
13/08/2020
Estimating
Business Value
o Identify sources: increased sales;
decreased costs; reduced
headcount; lower turnover…
Phân tích tính khả thi
o Assign values as initial estimates
Feasibility Analysis
Is this project really worth doing…
Can we do this project…
Will the organization accept this if we go ahead…

Phân tích tính khả thi Khả thi về mặt công nghệ
Feasibility Analysis Technical Feasibility: Can We Build It?
 Detailed business case for the project  Sources of Technical Risk:
o Technical feasibility o Users’ and analysts’ lack of familiarity with the business application
area
o Economic feasibility
o Lack of familiarity with technology
o Organizational feasibility
▪ Have we used it before? How new is it?
 Compiled into a feasibility study o Project size
 Critically important to reassess feasibility throughout ▪ Number of people, time frame, distinct features
o Compatibility with existing systems
the project
▪ Degree of integration required
29
13/08/2020
Khả thi về mặt tài chính

Economic Feasibility: Should We Build It?
 Identify costs and benefits Costs and
 Assign values to costs and benefits Benefits
 Determine cash flow o Include development and
operational costs
 Assess financial viability o Consider tangible and intangible

benefits
o Return on investment
o Break even point
o Net present value
Khả thi về mặt tổ chức

Organizational Feasibility:
If We Build It, Will They Come?
Cost-Benefit  Strategic alignment
Analysis o Are project goals aligned with business strategy?
o Discounted cash flow method  Evaluate effect on various stakeholders
preferred
o NPV preferred o Strong and influential project champion?
o Strong and widespread organizational management support?
o Receptive / resistant system users?

30
13/08/2020
Organizational Feasibility Đánh giá tính khả thi

If We Build It, Will They Come? Feasibility Assessment: Summing It Up
 Strategic alignment  All projects have feasibility risks
o Close alignment with strategy increases the likelihood of o Our goal is to know the risks we face and the significance of those
success risks
o Project Sponsor, Project Manager, and other team members need
 Stakeholder groups can be influenced this awareness
o Presentations describing and promoting benefits o Once risks are known, steps can be taken to mitigate the risks
o Emphasizing personal benefits as well as organizational ▪ For example, if unfamiliar with a new technology
benefits • Provide enough budget for training
• Provide enough budget to hire consultants with expertise
o Prototypes help prove the system concept • Allow more schedule time to move up the learning curve
o Real user involvement throughout project • Use a methodology that incorporates experimentation
Đánh giá tính khả thi

Feasibility Assessment: Summing It Up
 Essential to continuously review and revise the
feasibility assessment Lựa chọn và quản lý dự án
o How well are we managing the risks we previously identified?
Are adjustments needed? Project Selection and Management
▪ Risk is being managed Systems analysis and design, 6th edition
▪ Risk is not well managed and needs further attention
Dennis, wixom, and roth
o Are there any new risks that have appeared?
▪ If so, what are the actions needed to address those risks?
▪ Budgetary and schedule effect?
31
13/08/2020
Các vấn đề khi lựa chọn dự án Quản lý danh mục dự án

Project Selection Issues Project Portfolio Management
 Ways to Characterize Projects  PPM software collects and manages information about all
o Size projects – on-going and awaiting approval.
o Cost
 Companies stay up to date on projects and adapt to
o Purpose
o Length changing conditions.
o Risk  Features: project prioritization, employee allocation, real-
o Scope time project monitoring, flagging cost and time variances,
o Economic Value
monitoring economic feasibility.
Khởi tạo kế hoạch cho dự án Lựa chọn phương thức cho dự án

Creating the Project Plan Selecting a Project Methodology
 Once a project is approved, the project manager  Methodology: A formalized approach to implementing the
must: SDLC
o A series of steps to perform and deliverables to produce
o Select the best project methodology
 Methodology Sources
o Develop a project work plan
o Internally developed by organizations
o Establish a staffing plan o Consulting firms
o Create ways to coordinate and control the project o Software vendors
o Government agencies
32
13/08/2020
Những vấn đề khi lựa chọn phương thức cho dự án Mô hình hóa phát triển các hệ thống
Selecting a Project Methodology - Issues Structured Systems Development
 These factors influence the best choice:  Based upon SDLC
o Clarity of User Requirements  Assumes a project phase is complete before moving to
o Familiarity with Technology the next phase
o System Complexity o Waterfall Development
o System Reliability o Parallel Development
o Time Frame o V-model
o Schedule Visibility  Goal – doing each phase thoroughly before moving
forward ensures correct and high-quality outcomes
Waterfall Methodology Assessment

Waterfall
Development STRENGTHS WEAKNESSES
Methodology
 System requirements  Must wait a long time before
o Move from phase to phase
o Emphasis on deliverables from one identified long before there is “visible” evidence of
phase flowing into the next phase construction begins the new system
 Requirements are “frozen” as  Takes a long time from start to
project proceeds – no moving finish
targets allowed

33
13/08/2020
Parallel Methodology Assessment

Parallel
Methodology
 Reduces overall project time  Creating subprojects requires
o Subdivide the project into (compared to Waterfall) careful design decisions
subprojects that can be worked on
at the same time.
o Reduce the overall project length  Reduces the need for rework;  Integrating subprojects at the
with shorter time frame, less end can be complex and
chance of requirements difficult
changing

V-Model Methodology Assessment

V-Model
Methodology
 Simple and straightforward  Rigid
o Emphasizes system quality through
text plan development
 Quality improves through the  Difficult to use in a dynamic
emphasis on testing business environment
 Including Quality Assurance
expertise early in the project
strengthens system quality

34
13/08/2020
Rapid Application Development Three RAD Approaches

 Incorporate special techniques and tools:  Iterative development
o CASE tools o A series of versions developed sequentially
o JAD sessions
 System Prototyping
o Create prototype (model) of system and “grow” it into the final
o Visual programming languages
system
o Code generators  Throw-away prototyping
 Goal – get some portion of system developed quickly and o Prototype alternative designs in an experimental way
in the users’ hands o Build system following prototype design but discard the actual
prototype
Iterative Development Methodology Assessment

Iterative
Methodology
 Users get a system to use  Users faced with using an
o RAD approach
o Develop system in series of quickly incomplete system for a time
versions
 Users identify additional  Users must be patient and wait
needs for later versions based for fully-functional system
on real experiences with
current version

35
13/08/2020
System System Prototyping Methodology Assessment

Prototyping
Methodology
 Users get to work with  Superficial analysis may cause
o RAD approach
o Create a rough version of system prototype very quickly problems
quickly and “grow” it into final
system with repetitive refinement  Feedback cycles let users  Initial design decisions may
identify changes and refine be poor
real requirements  Overlooked features may be
hard to add later

Throwaway Throwaway Prototyping Methodology Assessment

Prototyping
Methodology
 Uncertainty is minimized  May take longer (compared to
o RAD approach
o Adds emphasis on experimenting  Important issues are system prototyping)
with design options before design
is finalized understood before building the
o Design options are thrown-away, final system
but learning from them is factored
into final design

36
13/08/2020
Agile Methodologies Assessment

Agile
Methodologies
 Fast delivery of results  Requires discipline
o Extreme Programming (XP),
Scrum, and others
 Works well in projects with  Significant user involvement
o Focus on short cycles that produce undefined or changing is essential
a complete software product
o Highly adaptable in dynamic requirements  Initial high learning curve
environments
 Works best in smaller projects

Selection Summary
Waterfall Parallel V-Model Iterative System Throwaway Agile
Ability to develop Proto- Prototyping Develop-
systems typing ment
With unclear user

requirements
Poor Poor Poor Good Excellent Excellent Excellent
Các nhiệm vụ trong quản lý dự án
Project Management Tasks
With unfamiliar Poor Poor Poor Good Poor Excellent Poor
technology
That are complex Good Good Good Good Poor Excellent Poor
That are reliable Good Good Excellent Good Poor Excellent Good
Preparing to launch the project

With a short time Poor Good Poor Excellent Excellent Good Excellent
schedule
With schedule Poor Poor Poor Excellent Excellent Good Good

visibility
37
13/08/2020
Project Manager’s Balancing Act Project Estimation

 The process of assigning projected values for time and effort
• Project Management  Sources of estimates
involves making Project Size o Methodology in use
trade-offs… o Actual previous projects
o Experienced developers
 Estimates begin as a range and become more specific as the project
progresses
Modifying one element
Industry standards
requires adjusting the others o
o Function point estimation (Appendix 2A)
Project Estimates Using Industry Standard

Identifying Tasks
Percentages
INDUSTRY STANDARD PERCENTAGES EXAMPLE
 Use established guidelines – existing methodologies
 Use analogies – model previous projects’ task lists
• IF 4 months are required for Planning, then
 Top-down approach – break high level tasks into smaller, detailed
• 15% X = 4, where X = overall length of project
• X = 4 / 15% tasks
• X = 26.66 months for entire project  Organize into work breakdown structure
• Therefore:
• Planning (15%): 4 months
• Analysis (20%): 5.33 months
• Design (35%): 9.33 months
• Implementation (30%): 8 months
• Total Project Length: 26.66 months
38
13/08/2020
Project Work Plan
Typical
Workplan Entry

Project Work Plan

3.1. Phân tích yêu cầu hệ thống
3.1.1. Xác định yêu cầu hệ thống
3.1.2. Mô hình hoá nghiệp vụ
3.1.3. Các hướng nhìn trong phân tích
39
13/08/2020
3.1.1 Xác định các yêu cầu hệ thống Cơ sở xác định yêu cầu hệ thống
Cơ sở xác định yêu cầu hệ thống • Xuất phát: Xác định hiện trạng
Các phương pháp xác định yêu cầu truyền thống. • HT tổ chức đang hoạt động
Các phương pháp xác định yêu cầu hiện đại • HT tổ chức mới hình thành
• Mục tiêu:
• Tiếp cận chuyên môn nghiệp vụ, môi trường hoạt động của HT
• Tìm hiểu các chức năng, nhiệm vụ và cung cách hoạt động của HT
• Xác định những chỗ hợp lý của HT  kế thừa, chỗ bất hợp lý  cần khắc
phục.
Yêu cầu là gì? Các yêu cầu người dùng

What is a Requirement? User Requirements
 A statement of what the system must do; or  What the user needs to do to complete a needed job or task
 A statement of characteristics the system must have  Focus on user tasks that are integral to business operations
 Types of requirements:  Understanding user tasks helps reveal ways that the new
o what the business needs (business requirements);
system can support those tasks
o what the users need to do (user requirements);
o what the software should do (functional requirements);
o characteristics the system should have (nonfunctional
requirements); and
o how the system should be built (system requirements).
40
13/08/2020
Các yêu cầu chức năng

Functional Requirements More on
 A process the system should perform as a part of Functional
supporting a user task, or Requirements
 Information the system should provide as the user performs o Process-oriented
o Information-oriented
a task
 Specify the support the system will provide to the user in
fulfilling his/her work tasks

Các yêu cầu phi chức năng

Nonfunctional Requirements More on
 Behavioral properties the system must have Nonfunctional
o Operational – physical and technical operating environment Requirements
o Performance – speed, capacity, and reliability needs o Behavioral properties the system
o Security – access restrictions, needed safeguards must have
o Cultural and political – issues that will affect the final system
 Nonfunctional requirements are discussed in Chapter 8
(Architecture Design)

41
13/08/2020
Các yêu cầu về tài liệu

Documenting Requirements
 Requirements definition report Comparing
o Text document listing requirements in outline form Techniques
o Organized in logical groupings
o Depth
o Priorities may be included o Breadth
 Key purpose is to define the project scope o Integration
o what is included o User involvement
o Cost
o what is not included.

Các yêu cầu cải tiến nhỏ

To Identify Small Improvements
 Problem Analysis
o Ask users to identify problems and solutions
Các chiến lược phân tích yêu cầu o Improvements tend to be small and incremental
o Rarely finds improvements with significant business value
Requirements Analysis Strategies  Root Cause Analysis
o Challenge assumptions about why problem exists
Ways to discover true underlying requirements o Trace symptoms to their causes to discover the “real” problem
42
13/08/2020
Các yêu cầu cải tiến trung bình Các yêu cầu cải tiến lớn
To Identify Moderate Improvements To Identify Major Improvements
 Goal is to improve efficiency and effectiveness  Goal is radical redesign of business processes
 Expect moderate changes to existing systems  Expect significant impact and value to organization
 Expect moderate impact and value to organization  Existing system is “obliterated:
 Types of activities:  Activities focus on envisioning the business in new ways:
o Duration Analysis o Outcome Analysis
o Activity-Based Costing o Technology Analysis
o Informal Benchmarking o Activity Elimination
Phân tích kết quả

Cơ sở xác định yêu cầu hệ thống
Outcome Analysis
 Consider desirable outcomes from customers’ perspective • Các nguồn điều tra • Các bước xác định yêu cầu
 Consider what the organization could enable the customer to • Những người dùng hệ thống • Khảo sát hiện trạng
Các sổ sách tài liệu Xác định yêu cầu chức năng
do • •
• Các chương trình máy tính • Về chức năng nghiệp vụ
 Brainstorm on desirable customer outcomes enabled by IS • Các tài liệu mô tả quy trình, chức • Về chức năng hệ thống
trách • Xác định yêu cầu phi chức năng
• Các thông báo
43
13/08/2020
Các phương pháp xác định yêu cầu 3.1.2. Mô hình hoá nghiệp vụ
• Nghiên cứu các tài liệu viết
• Tìm hiểu cấu trúc và khía cạnh động của tổ chức triển khai.
• Sử dụng phiếu thăm dò
• Xác định vấn đề thực tại, các cải tiến để nâng cao hiệu quả tổ chức.
• Phỏng vấn
• Người dùng cuối và người phát triển có cái nhìn chung về tổ chức.
• Quan sát
• Nắm bắt yêu cầu hệ thống cần hỗ trợ cho tổ chức
• ???
3.1.2. Mô hình hoá nghiệp vụ (tt) – Chế tác 3.1.2. Mô hình hoá nghiệp vụ (tt) – Luồng công việc
Chế tác RUP Nỗ lực

Business Vision Low
Business Use Case Model (in Rose) Medium
Business Use Case Model Survey Low
Business Object Model Medium
Business Object Model Survey Low
44
13/08/2020
3.1.2. Mô hình hoá nghiệp vụ (tt)

3.1.2. Mô hình hoá nghiệp vụ (tt) – Tiến trình Đánh giá trạng thái nghiệp vụ
3.1.2. Mô hình hoá nghiệp vụ (tt) – Mô tả

hiện trạng 3.1.2. Mô hình hoá nghiệp vụ (tt) – Mô tả hiện trạng
45
13/08/2020
3.1.2. Mô hình hoá nghiệp vụ (tt) 3.2. Biểu đồ Usecase

• Các bước xây dựng • Tìm tác nhân:
• Xác định tác nhân và các use case • Ai sẽ là người sử dụng các chức năng của HT
• Ai cần sự hỗ trợ của HT để thực hiện công việc
• Xác định các mối quan hệ và hằng ngày?
phân rã biểu đồ Usecase • Ai cần bảo trì, quản trị và đảm bảo HT hoạt
• Mô tả các use case thông qua các động?
kịch bản • HT sẽ tương tác với các HT nào khác?
• Kiểm tra và hiệu chỉnh biểu đồ • Ai hay cái gì quan tâm đến kết quả HT sinh ra
Lưu ý:
- Tốc độ quan trọng hơn chi tiết trong pha khởi đầu
- Làm sao nhận được bức tranh tổng thể đúng
3.2. Biểu đồ Usecase 3.2. Biểu đồ Usecase

• Tìm use case Thủ thư
• Tác nhân cần chức năng nào từ HT?
• Ví dụ:
• Tác nhân cần phải xem, cập nhập hay lưu trữ thông tin gì trên HT?
• Tác nhân cần thông báo cho HT những sự kiện gì, sự kiện đó đại diện cho Cập nhật TT Cập nhật TT Quản lý mượn
chức năng nào? Bạn đọc Về tài liệu trả sách
• HT có cần thông báo với tác nhân khi có sự thay đổi không?
• HT có chức năng gì để đơn giản hóa nhiệm vụ của tác nhân? Bạn đọc
• Các tác nhân và Usecase còn có thể sinh ra bởi sự kiện nào khác (sự kiện
thời gian, tác động của chức năng khác)?
• Hệ thống cần thông tin đầu vào đầu ra nào? Tìm kiếm Xem TT Đăng ký mượn
TT sách cá nhân trả sách
46
13/08/2020
3.2. Biểu đồ Use case 3.2. Biểu đồ Usecase

• Ở mức tổng quát: od Business Process Model
• Xác định mối quan hệ • Trình tự phân rã biểu đồ use case • Các chức năng chính
Các mối quan hệ được sử dụng? Xác định biểu đồ ở mức tổng quát
Dang nhap
Cap nhat
• • Có mức khái quát cao
• Quan hệ Include: • Phân rã use case ở mức cao • Dễ dàng nhìn thấy trên quan điểm
• Quan hệ extend: • Phân rã use case cho đến khi gặp use của tác nhân «include»
• Quan hệ generalization: case ở mức lá • Ví dụ: Tim kiem
• Quan hệ kết hợp: biểu diễn mỗi • Hoàn thiện biểu đồ + Đăng nhập Thu thu
liên hệ + Cập nhật Ban doc
+ Tìm kiếm
3.2. Biểu đồ Usecase Biểu đồ Use case theo kịch bản

• Ở mức cao:
• Sử dụng quan hệ extend
• Thêm vào các usecase cha
• Ví dụ:
• Cập nhật bao gồm
• Cập nhật bạn đọc
• Cập nhật tài liệu
• Ở mức lá:
• Các chức năng thực sự tương tác với tác
nhân
• Ví dụ:
• Cập nhật bạn đọc:
• Thêm bạn đọc
• Thay đổi thông tin bạn đọc.
• Xóa bạn đọc
47
13/08/2020
3.3. Biểu đồ lớp

Vấn đề xác định lớp:
• Diễn tả hướng nhìn tĩnh của HT.
• Lớp là nền tảng để diễn tả các hướng nhìn khác của hệ thống.
• Một số phương pháp: (mang tính định hướng)
• Trích danh từ.
• Dùng thẻ ghi CRC.
• Xác định lớp từ ca sử dụng và kịch bản
Các bước thực hiện ở mức phân tích:

• Xác định các lớp
• Xác định các thuộc tính và phương thức cơ bản
• Bước đầu chỉ ra mối quan hệ giữa các lớp.
3.4. Biểu đồ tương tác 3.5. Biểu đồ trạng thái và biểu đồ hoạt động
• Là biểu đồ mô tả chính xác các hoạt động của hệ thống, bao gồm: • Mô tả cấu trúc tổ chức của HT với nhiều bộ phận ở các mức khác
• Biểu đồ tuần tự (trình tự): nhau, tương tác với nhau qua các giao diện, các mối quan hệ và các
• Biểu đồ cộng tác: là biểu đồ chỉ ra một số các đối tượng và những sự liên kết ràng buộc
giữa chúng thông qua sự trao đổi thông điệp giữa các đối tượng
• Mô tả về các HT con, các thành phần và mối quan hệ giữa chúng
48
13/08/2020
Câu hỏi ôn tập Chương 3

1. Trình bày phương pháp xác định yêu cầu nghiệp vụ?
2. Trình bày các loại biểu đồ trong PTTK HĐT? Chương 4:
3. Vẽ các biểu đồ tương ứng cho bài toán xây dựng HTTT Quản lý
Nhân sự
Thiết kế hệ thống theo hướng đối tượng
Key Ideas
 In Systems Analysis we figure out…
o What the business needs
Chuyển đổi từ yêu cầu sang thiết kế 

o
In System Design we figure out…
How to build the system that fulfills those needs
Transition from Requirements to Design  All of the “logical” work from Systems Analysis is
converted to the “physical”
Brief preview
49
13/08/2020
Các bước trong pha thiết kế

Key Definitions
Design Phase Steps
 Design phase
o Decide how to build the system  Determine system acquisition strategy (make, buy, or outsource)
o Create system requirements that describe all technical details for  Determine the technical architecture for the system
building the system  Address security concerns and globalization issues
 System specification  Make hardware and software selections
o Final deliverable from design phase  Determine the way that users will interact with the system
o Conveys exactly what system the development team will implement (interface, inputs, and outputs)
during the implementation phase
 Design the programs for the underlying processes
 Design the way data will be stored
 Create final deliverable - the system specification
Nội dung
Elements of
4.1. Thiết kế các hệ thống con
System
Specification 4.2. Thiết kế giao diện người dùng và thiết kế lớp
4.3. Thiết kế việc lưu trữ các dữ liệu
4.4. Mô hình hóa cài đặt hệ thống

50
13/08/2020
Giới thiệu
• Sau khi xác định và phân tích yêu cầu hệ thống, chúng ta chuyển
sang pha thiết kế và cài đặt hệ thống. Thiết kế kiến trúc hệ thống là
giai đoạn sớm nhất trong quy trình thiết kế hệ thống. Thiết kế kiến
Thiết kế kiến trúc
trúc cung cấp cho chúng ta bản đặc tả về kiến trúc hệ thống, bao gồm Architecture Design
những hệ thống con nào, tương tác với nhau ra sao, framework hỗ
trợ điều khiển tương tác giữa các hệ thống con như thế nào … Systems analysis and design, 6th edition
Key Definitions Objective of Architecture Design

 Architecture design  Assign the software components of the information system
o Plans for how the system will be distributed across computers and what to the hardware devices of the system in the most
hardware and software will be used for each computer.
advantageous way.
 Hardware and software specification
o Describes the hardware/software components in detail to aid those
 The major architectural components of any system are the
responsible for purchasing those products. software and the hardware.
51
13/08/2020
Architectural Components Architectural Components (cont’d)

 Software systems can be divided into four basic functions:  The three primary hardware components:
o Data storage. o Client computers: Input-output devices employed by users (e.g., PCs,
o Data access logic: the processing required to access stored data. laptops, handheld and mobile devices, smart phones)
o Application logic: the logic documented in the DFDs, use cases, and o Servers: Larger multi-user computers used to store software and data.
functional requirements. o Network: Connects the computers.
o Presentation logic: the display of information to the user and the
acceptance of the user’s commands.
Client-Server Architectures
Two-Tiered
 Client-server architectures balance the processing between client devices Client-Server
and one or more server devices. Architecture
 Generally, clients are responsible for the presentation logic, and
o Thick client – most of application
 the server(s) are responsible for the data access logic and data storage. logic on the client side (shown
here)
 Application logic location varies depending on the C-S configuration o Thin client – little application logic
on the client side; most shifted to
chosen. server side

52
13/08/2020
Three-Tiered n-Tiered Client-

Client-Server Server
Architecture Architecture
o Adds “specialized” servers – one o Adds “specialized” servers – one
for application logic; one for data for Web-related business logic; one
base tasks for application logic; one for data
base tasks
209 210
Mobile Application Architecture

Server-Based  Rich client – involves processing on the mobile device using its
Architecture resources. Presentation logic, business logic, and data access logic
Zero-client used today in virtual
on the client side.
desktop infrastructure (VDI)
 Thin Web-based client – business and data access logic on the
server side; always connected to server.
 Rich Internet application – browser-based; uses some technologies
on client device to provide a rich user interface (e.g., Flash).

53
13/08/2020
Mobile Application Options Selecting an Architecture Design

 Lower costs often used to justify choice of client-server
 Native app – written to run on specific device with specific  Recommended selection process:
operating system. o Expand nonfunctional requirement details
 Cross-platform frameworks – develop in web-based technologies o Base architecture selection on the detailed nonfunctional requirements
and use framework to deploy to multiple devices.  Operational,
 Performance,
 Mobile Web app – browser-based; platform independent. Most  Security, and
limited user experience.  Cultural/political
Operational Requirements Performance Requirements

Requirement Definition Example Requirement Definition Example
Technical Special hardware, software, All office locations have
Speed Time within which the system Network transaction
Environment and network requirements always-on network connection
must perform its function response time <= 4
imposed by business permitting real-time database
seconds
requirements updates
System The extent to which the system The system will read and write Capacity Total and peak number of users Maximum of 2000
Integration will operate with other systems to the main inventory database and the volume of data expected simultaneous users at peak
use times
Portability The extent to which the system The system must operate with
will need to operate in other mobile devices (Android and Availability and Extent to which the system will be 99% uptime performance
environments iOS) Reliability available to the users and the
Maintainability Expected business changes to The system must permissible failure rate due to
which the system should be accommodate new errors
able to adapt manufacturing plants
215 216
Bộ môn CNTT - Khoa HTTT Kinh tế và TMDT Bộ môn CNTT - Khoa HTTT Kinh tế và TMDT
54
13/08/2020
Security Requirements Cultural/Political Requirements

Requirement Definition Example Requirement Definition Example
System Value Estimated business value of A complete loss of all system Multilingual The language(s) the The system will operate in
Estimates the system and its data data would cost $20 million system users will need English, French, and Spanish
Access Control Limitations on who can access Inventory item changes can be Customization Specification of what Country managers will be able to
what data made only by managers for aspects of the system can define new fields in the product
items in their own department be changed by local users database to capture country-
specific information
Encryption and Defines what data will be Data will be encrypted from
Authentication encrypted where and whether the user’s computer to the Making Explicitly stating All weights will be stated in
authentication will be needed Web site to provide secure Unstated assumptions that differ pounds and in kilograms
for user access ordering Norms Explicit from country to country
Virus Control Controls to limit viruses All uploaded files will be Legal The laws and regulations Personal customer information
checked for viruses before that impose system cannot be transferred from
being saved in the system requirements European Union countries to US
217 218
Bộ môn CNTT - Khoa HTTT Kinh tế và TMDT Bộ môn CNTT - Khoa HTTT Kinh tế và TMDT
Nonfunctional
Requirements and
the Architecture
Design
Đặc tả phần cứng và phần mềm
Hardware Software Specification
Outlining needs in new system

55
13/08/2020
HW/SW Specification Purpose

Sample
 Used if new hardware or software must be purchased HW/SW
 Communicates project needs Specification
 Actual acquisition of hardware and software may be done
by a purchasing department -- especially in larger firms.

Key Definitions
System Interface: “connections” with other systems, where systems
Thiết kế giao diện người dùng
•
exchange information with each other. Designed as a part of
program design.
User Interface Design • User Interface: “connections” with users. Focus of this chapter.
• The navigation mechanism provides the way for users to tell the system what
Systems analysis and design, 6th edition to do
Dennis, wixom, and roth • The input mechanism defines the way the system captures information
• The output mechanism defines the way the system provides information to
users or other systems
56
13/08/2020
Usability Concept
• The system is easy to use and easy to learn
• Tasks are completed more efficiently and with more accuracy
• Mistakes with system are reduced Nguyên lý thiết kế giao diện
User satisfaction with new system is increased
Interface Design Principles
•
• Adoption of system is more likely

General guidelines for user interface design
Principles for User Interface Design Layout Concepts

• Layout • The screen is often divided into three boxes
• Content awareness • Navigation area (top)
• Status area (bottom)
• Aesthetics
• Work area (middle)
• Usage level
• Information can be presented in multiple areas
• Consistency
Minimize user effort
• Like areas should be grouped together
•
57
13/08/2020
More Layout Concepts

• Areas and information should minimize user movement from one to
another Model Layout
• Ideally, areas will remain consistent in for Web Page
• Size o Note use of multiple layout areas
for site navigation
• Shape
• Placement for entering data
• Reports presenting retrieved data

Usage Level
Content • Some people will be frequent, heavy users of the system
Awareness • Frequent users desire ease of use – quick and easy completion of job
o Note the use of highlighting to tasks
indicate menu selections
o Breadcrumbs provide additional • Other people may use the system infrequently
clues on navigational path
• Infrequent users desire ease of learning – quick and easy ways to
figure out what to do.

58
13/08/2020
Consistency
Example of
• Elements are the same throughout the application Inconsistent
• Enables users to predict what will happen Elements
• Reduces learning curve Note the different button styles, colors,
and font styles.
• Considers elements within an application and across
applications
• Pertains to many different levels
• Navigation controls
• Terminology
• Report and form design

Minimize Effort Special Issues of Touch Screen Design

• Three clicks rule • Ideal for information display but not data entry.
• Users should be able to go from the start or main menu of a system to the • Place content at top and navigation controls at bottom so finger does
information or action they want in no more than three mouse clicks or three
keystrokes
not obscure content area.
• Place labels on top of navigation controls.
• Size objects correctly for “fat fingers.”
• Include adequate spacing between objects.
59
13/08/2020
Android Device
Common Hand User Interface
Gestures Design Process
o Understand the Users
o Organize the Interface
o Define Standards
o Develop Prototypes
o Evaluation / Testing
237 238
Understand the Users

• Users likely will have very different goals and intentions when using
the system. Personas for
• Use personas to develop characterizations of various user groups. Tune Source
• Interests
• Typical behaviors
• Goals and objectives
• Expectations
• Plan a user interface that will be satisfying for that particular user
group.

60
13/08/2020
Organize the Interface

• Define the basic components of the interface and how they work
Use Scenarios together to provide functionality to users.
for Tune Source • Use Interface Structure Diagram (ISD)
• Shows how all screens, forms, and reports are related
• Shows how user moves from one to another
• Similar to DFD in using boxes and lines
• Boxes denote screens
• Lines show movement from one to another
• Different from DFD in having no standard rules or format

Interface
Structure
Diagram for Site Map for
Tune Source Tune Source
243 244
61
13/08/2020
Wireframe
Diagram for Storyboard
Tune Source Example
245 246
Language
Prototype
Example
Thiết kế chương trình
Program Design
Systems analysis and design, 6th edition
247
62
13/08/2020
The Physical Process Model Contrasting a Logical and Physical DFD

• Show the implementation details and explain how the system will
work, including LOGICAL DFD PHYSICAL DFD
• Actual, specific technology
• Format of information
• Human interaction with system
Key Definitions The Structure Chart

• Important program design technique
• Program design - creating instructions for the programmers
• Shows all components of code in a hierarchical format
• The top-down, modular approach - begin with the “big picture” and • Sequence
gradually add detail
• Selection
• Program design document – all structure charts and specifications • Iteration
needed by programmers to implement the system
• Illustrates the organization and interactions of the different program
modules
63
13/08/2020
Building the Structure Chart

Example • Processes in the DFD tend to represent one module on the
structure chart
Structure Chart • Afferent processes – provide inputs to system
• Central processes – perform critical system operations
• Efferent processes – handle system outputs
• The DFD leveling can correspond to the structure chart
hierarchy

Types of Cohesion Types of Coupling

Good Good
• Functional • Data
• Sequential • Stamp
• Communicational • Control
• Procedural • Common
• Temporal • Content Bad
• Logical
• Coincidental Bad
64
13/08/2020
Fan-in Quality Checklist

High fan-in preferred 1. Library modules have been created where ever possible
Promotes reuse of subordinate modules 2. The diagram has a high fan-in structure
1.1
Calculate
1.2
Print
1.3
1.1
Calculate
1.2
Print
1.3 3. Control modules have no more than 7 subordinates
Calculate Calculate
Employee Employee Employee Employee
Salary Roster
Benefits
Salary Roster
Benefits 4. Each module performs only one function (high cohesion)
5. Modules sparingly share information (loose coupling)
1.1.2 1.1.1 1.2.1 1.3.1 6. Data couples that are passed are actually used by the accepting module
Read Read Read Read
Employee Employee Employee Employee 7. Control couples are passed from “low to high”
Record Record Record Record
8. Each module has a reasonable amount of code associated with it
Low fan-in not preferred
Program Specification Content

• No standard approach
• Include program information
Đặc tả chương trình •
•
Note events that trigger actions
List inputs and outputs
Program Specifications • Include pseudocode
Instructions to the programmer
• Provide additional notes and comments as needed
65
13/08/2020
Sample
Sample Program
Pseudocode Specification
261 262
Key Concepts
• Data storage function: how data is stored and handled by programs
Thiết kế lưu trữ dữ liệu •
that run the system.
Data storage design:
Data Storage Design •
•
select the data storage format;
convert the logical data model into a physical data model to reflect
implementation decisions;
Systems analysis and design, 6th edition • ensure that DFDs and ERDs balance; and
Dennis, wixom, and roth • design the selected data storage format to optimize its processing efficiency.

264
66
13/08/2020
DATA STORAGE FORMATS Files

• Data file: an electronic list of information that is formatted
• Types of data storage formats:
• Files: electronic lists of data, optimized to perform a particular transaction. for a particular transaction.
• Database: a collection of groupings of information that are related to each other in • Sequential organization is typical.
some way.
• Database Management System (DBMS): software that creates and • Record associations with other records created by pointers.
manipulates the databases. • Also called linked lists because of the way the records are
linked together using pointers.
Types of Files
• Master files – store core information that is important to the
application. Appointment
• Look-up files – contain static values. File Example
• Transaction files – store information that can be used to
update a master file.
• Audit files – record “before” and “after” images of data as
the data is altered.
• History files (or archive files) – store past transactions.

67
13/08/2020
Databases
• There are many types of databases:
• Legacy database Appointment
• Relational database
• Object database Database
• Multidimensional database
• NoSQL database

Object Databases Multidimensional Databases

• Based on object orientation: that all things should be treated as • A type of relational database used extensively in data warehousing.
objects that have both data (attributes) and processes (behaviors). • Data warehousing is the practice of taking and storing data in a data
• Object-oriented database management system (OODBMS) are warehouse (i.e., a large database) that supports business intelligence
mainly used to support multimedia applications or systems that (BI) systems.
involve complex data. • Data marts are smaller databases based on data warehouse data;
support BI for specific departments or functional areas of the
• Play a minor role in the DBMS market at this time.
organization.
68
13/08/2020
Selecting a Storage Format

• Each of the file and database data storage format has its
Multidimensional strengths and weaknesses.
Database
• Factors to consider in selecting a storage format:
• Data Types
• Type of Application System
• Existing Storage Formats
• Future Needs

4.1. Thiết kế các hệ thống con

• Quy trình thiết kế nhằm xác định các hệ thống con cấu tạo lên hệ
Comparing thống đề xuất và framework giúp điều khiển các hệ thống con và giao
Storage Formats tiếp giữa chúng được gọi là quy trình thiết kế kiến trúc. Kết quả của
quy trình thiết kế này là bản đặc tả về kiến trúc phần mềm.
• Thiết kế kiến trúc là pha sớm nhất trong quy trình thiết kế hệ thống.
Thiết kế kiến trúc thường được thực hiện song song với một số hành
động đặc tả. Nó bao gồm có việc phát hiện các thành phần chính của
hệ thống và giao tiếp giữa chúng.

69
13/08/2020
4.1. Thiết kế các hệ thống con 4.1. Thiết kế các hệ thống con
• Nếu chúng ta có được bản thiết kế kiến trúc rõ ràng thì ta sẽ thấy • Các đặc điểm của kiến trúc hệ thống:
được các ưu điểm của nó trong những hoạt động sau: • Hiệu năng: hạn chế các thao tác phức tạp và tối thiểu hoá giao tiếp.
• Giao tiếp giữa các stakeholder: • Bảo mật: sử dụng kiến trúc phân lớp với nhiều kiểm soát chặt chẽ ở các lớp
• Kiến trúc hệ thống thường được sử dụng làm tâm điểm của các buổi thảo luận giữa các sâu hơn.
stakeholder. • An toàn.
• Phân tích hệ thống: • Sẵn dùng.
• Tức là phân tích để xác định liệu hệ thống có thoả mãn các yêu cầu phi chức năng của nó • Có khả năng bảo trì.
hay không.
• Tái sử dụng với quy mô lớn:
• Kiến trúc có thể được tái sử dụng trong nhiều hệ thống.
4.1. Thiết kế các hệ thống con 4.2. Thiết kế giao diện và thiết kế lớp
• Nguyên tắc quan trọng khi xây dựng một hệ thống phần mềm, đó là:
• Các mô hình kiến trúc cơ bản:
• Người sử dụng không quan tâm đến cấu trúc bên trong của hệ thống, đơn giản hay phức
• Mô hình cấu trúc tĩnh: mô tả các thành phần hệ thống chính. tạp; cái mà họ có thể đánh giá được và cảm nhận được chính là giao diện tương tác giữa
• Mô hình quy trình động: biểu diễn quy trình cấu trúc của hệ thống. hệ thống và người sử dụng.
• Mô hình giao diện: định nghĩa tập hợp các giao diện của hệ thống con • Nếu người sử dụng cảm thấy giao diện không thích hợp, khó sử dụng thì rất có thể họ sẽ
• Mô hình quan hệ: biểu diễn quan hệ giữa các hệ thống con. không sử dụng cả hệ thống; cho dù hệ thống đó có đáp ứng tất cả các chức năng nghiệp vụ
• Mô hình phân tán: biểu diễn cách cài đặt các hệ thống con trên máy tính. mà họ muốn. Và như vậy, dự án của chúng ta sẽ thất bại.
• Vì tầm quan trọng của giao diện người dùng, nên chúng ta có cả một chương để
nói về chúng. Trong chương này, chúng ta sẽ nghiên cứu những vấn đề sau:
• Các yếu tố liên quan đến giao diện người dùng
• Quy trình xây dựng giao diện người dùng
70
13/08/2020
4.2.1. Thiết kế giao diện người dùng 4.2.1. Thiết kế giao diện người dùng
• Tổng quan: • Tác nhân con người trong thiết kế giao diện:
• Giao diện người dùng cần phải được thiết kế sao cho phù hợp với kỹ năng, kinh nghiệm và
sự trông đợi của người sử dụng nó.
• Một nhân tố quan trọng ảnh hưởng tới quá trình thiết kế giao diện đó chính là
• Người sử dụng hệ thống thường đánh giá hệ thống thông qua giao diện hơn là chức năng
người sử dụng hệ thống. Do đó, chúng ta phải tìm hiểu một số đặc điểm của
của nó. Giao diện của hệ thống nghèo nàn có thể khiến người sử dụng tạo ra các lỗi hết sức người sử dụng có liên quan đến giao diện hệ thống:
nghiêm trọng. Đó là lý do tại sao nhiều hệ thống phần mềm không bao giờ được sử dụng. • Khả năng nhớ tức thời của con người bị hạn chế: con người chỉ có thể nhớ ngay khoảng 7 loại thông
tin. Nếu ta biểu diễn nhiều hơn 7 loại, thì có thể khiến người sử dụng không nhớ hết và gây ra các lỗi.
• Mục tiêu: • Người sử dụng có thể gây ra lỗi: khi người sử dụng gây ra lỗi khiến hệ thống sẽ hoạt động sai, những
• Nắm được sự ảnh hưởng của người sử dụng tới giao diện thông báo không thích hợp có thể làm tăng áp lực lên người sử dụng và do đó, càng xảy ra nhiều lỗi
hơn.
• Một số nguyên tắc khi thiết kế giao diện người dùng
• Người sử dụng là khác nhau: con người có những khả năng khác nhau. Những người thiết kế không
• Phân loại các khả năng tương tác giữa người và máy để thiết kế giao diện cho phù hợp nên chỉ thiết kế giao diện phù hợp với những khả năng của chính họ.
• Biết cách biểu diễn thông tin cho phù hợp với người sử dụng • Người sử dụng thích các loại tương tác khác nhau: một số người thích hình ảnh, văn bản, âm thanh …
Giao diện người dùng (tt2) Giao diện người dùng (tt3)
• Các nguyên tắc thiết kế giao diện: • Các nguyên tắc thiết kế giao diện (tt1):
• Thiết kế giao diện phải phụ thuộc vào yêu cầu, kinh nghiệm và khả năng của • Sau đây là các nguyên tắc thiết kế giao diện:
người sử dụng hệ thống. • Sự quen thuộc của người sử dụng: giao diện phải được xây dựng dựa trên các thuật ngữ
• Người thiết kế cũng nên quan tâm đến những giới hạn vật lý và tinh thần của và các khái niệm mà người sử dụng có thể hiểu được hơn là những khái niệm liên quan
đến máy tính.
con người và nên nhận ra rằng con người luôn có thể gây ra lỗi.
• Ví dụ: hệ thống văn phòng nên sử dụng các khái niệm như thư, tài liệu, cặp giấy … mà không
• Không phải tất cả các nguyên tắc thiết kế giao diện đều có thể được áp dụng nên sử dụng những khái niệm như thư mục, danh mục …
cho tất cả các giao diện. • Thống nhất: hệ thống nên hiển thị ở mức thống nhất thích hợp.
• Ví dụ: các câu lệnh và menu nên có cùng định dạng …
• Tối thiểu hoá sự bất ngờ: nếu một yêu cầu được xử lý theo cách đã biết trước thì người sử
dụng có thể dự đoán các thao tác của những yêu cầu tương tư.
71
13/08/2020
Giao diện người dùng (tt4) 4.2.1. Thiết kế giao diện người dùng
• Các nguyên tắc thiết kế giao diện (tt2): • Các nguyên tắc thiết kế giao diện (tt3):
• Sau đây là các nguyên tắc thiết kế giao diện (tt1): • Sau đây là các nguyên tắc thiết kế giao diện (tt2):
• Khả năng phục hồi: hệ thống nên cung cấp một số khả năng phục hồi từ lỗi của người sử
dụng và cho phép người sử dụng khôi phục lại từ chỗ bị lỗi. Khả năng này bao gồm cho
• Tương tác giữa người sử dụng và hệ thống được chia thành 5 loại sau:
phép làm lại, hỏi lại những hành động như xoá, huỷ … • Vận hành trực tiếp
• Hướng dẫn người sử dụng: như hệ thống trợ giúp, hướng dẫn trực tuyến … • Lựa chọn menu
• Tính đa dạng: hỗ trợ nhiều loại tương tác cho nhiều loại người sử dung khác nhau. • Điền vào biểu mẫu (Form)
• Ví dụ: nên hiển thị phông chữ lớn với những người cận thị. • Ngôn ngữ ra lệnh
• Ngôn ngữ tự nhiên
4.2.1. Thiết kế giao diện người dùng 4.2.1. Thiết kế giao diện người dùng
• Biểu diễn thông tin • Biểu diễn thông tin (tt1)
• Biểu diễn thông tin có liên quan tới việc hiển thị các thông tin trong hệ thống • Các nhân tố ảnh hưởng tới việc hiển thị thông tin:
tới người sử dụng. Thông tin có thể được biểu diễn một cách trực tiếp hoặc có • Người sử dụng thích hiển thị một phần thông tin hay quan hệ dữ liệu?
thể được chuyển thành nhiều dạng hiển thị khác như: dạng đồ hoạ, âm thanh • Giá trị của thông tin thay đổi nhanh như thế nào? Sự thay đổi đó có cần phải thể hiện ngay
… lập tức hay không?
• Thông tin cần biểu diễn được chia thành hai loại: • Người sử dụng có phải thực hiện các hành động để đáp ứng với sự thay đổi không?
• Thông tin tĩnh: được khởi tạo ở đầu của mỗi phiên. Nó không thay đổi trong suốt phiên đó • Có phải là giao diện vận hành trực tiếp không?
và có thể là ở dạng số hoặc dạng văn bản. • Thông tin ở dạng văn bản hay dạng số? Các giá trị quan hệ có quan trọng không?
• Thông tin động: thay đổi trong cả phiên sử dụng và sự thay đổi này phải được người sử • Biểu diễn digital hay analogue?
dụng quan sát.
• Biểu diễn digital hay analogue?
72
13/08/2020
Quy trình thiết kế UI Quy trình thiết kế UI (tt1)

• Giới thiệu:
• Thiết kế giao diện người dùng là một quy trình lặp lại bao gồm sự
cộng tác giữa người sử dụng và người thiết kế.
• Trong quy trình này gồm 3 hoạt động cơ bản:
• Phân tích người sử dụng: tìm hiểu những gì người sử dụng sẽ làm với hệ
thống.
• Lập mẫu thử hệ thống: xây dựng một tập các mẫu thử để thử nghiệm
• Đánh giá giao diện: thử nghiệm các mẫu thử cùng với người sử dụng.
Quy trình thiết kế UI (tt2) Quy trình thiết kế UI (tt3)

• Mục tiêu:
• Phân tích người sử dụng
• Hiểu được quy trình thiết kế giao diện người dùng
• Nếu ta không hiểu rõ những gì người sử dụng muốn làm với hệ thống, thì ta
• Nắm được chi tiết từng hoạt động trong quy trình thiết kế giao diện người sẽ không thể thiết kế được một giao diện hiệu quả.
dùng • Phân tích người sử dụng phải được mô tả theo những thuật ngữ để người sử
• Với mỗi hoạt động, chúng ta có rất nhiều cách để thực hiện. Do đó, phải có dụng và những người thiết kế khác có thể hiểu được.
khả năng lựa chọn phương pháp nào là thích hợp nhất cho từng hoàn cảnh cụ • Các ngữ cảnh mà ta mô tả thao tác ở trong đó là một trong những cách mô tả
thể. phân tích người dùng. Ta có thể lấy được rất nhiều yêu cầu của người sử
dụng từ đó.
73
13/08/2020
4.3. Thiết kế việc lưu trữ các dữ liệu 4.3. Thiết kế việc lưu trữ các dữ liệu
• Có 2 dạng lưu trữ chính: • Các bước thực hiện:
– Lưu trữ dưới dạng Tập tin • Bước 1: Chọn 1 YC và xác định sơ đồ logic cho YC
– Lưu trữ dưới dạng CSDL đó.
• Bước 2: Bổ sung thêm 1 YC và xem lại sơ đồ logic
• Lưu trữ dưới dạng tập tin • Nếu sơ đồ logic vẫn đáp ứng được thì tiếp tục bước 3 (không thêm gì cả).
– Thường chỉ thích hợp với một số PM • Nếu sơ đồ logic không đáp ứng được thì bổ sung vào
• Chú trọng rất nhiều vào các xử lý và hình thức giao – Ưu tiên 1: thuộc tính mới
– Ưu tiên 2: thành phần mới cùng với các thuộc tính và liên kết tương ứng.
diện.
• Thường các thông tin được tiếp nhận và xử lý ngay. • Bước 3: Quay lại bước 2 cho đến khi đã xem xét đầy
đủ YC.
• Vị dụ: các game nhỏ, …
• Bước 4: Tìm và liệt kê các RBTN, RBNC
• Lưu trữ dưới dạng CSDL rất thông dụng.
4.4. Mô hình hóa cài đặt hệ thống

Hệ thống thông tin lý mới
Bài tập
Phần cứng Công nghệ Các biểu mẫu Quy trình Con người
phần mềm quản lý nghiệp vụ • Câu 1:
• Nêu một số trường hợp không thể cung cấp giao diện người dùng một cách
nhất quán
CSDL
• Câu 2:
• Hãy đề xuất một vài giao diện người dùng thích hợp cho hệ thống bán sách
trực tuyến, dành cho những khách hàng là người khuyết tật.
Hệ thống thông tin cũ
• Câu 3:
Phần cứng Công nghệ Các biểu mẫu Quy trình Con người • Cho biết những ưu điểm của việc hiển thị thông tin một cách trực quan. Lấy ví
phần mềm quản lý nghiệp vụ dụ để minh hoạ cho tính vượt trội của việc hiển thị thông tin trực quan so với
các thông tin thống kế như văn bản, số liệu.
Dữ liệu Dữ liệu Dữ liệu
74
13/08/2020
Bài tập (tt1)

• Câu 4:
• Nêu những chú ý khi sử dụng màu để thiết kế giao diện
• Câu 5:
• Viết kịch bản tương tác của hệ thống dịch vụ đặt mua vé trước và thực hiện
thanh toán bằng thẻ tín dụng.
75

Phân tích và thiết kế

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Phân tích và thiết kế

Uploaded by

Copyright:

Available Formats

13/08/2020

20/12/2013 Bộ môn CNTT - Khoa HTTT Kinh tế và TMDT 2

Mục tiêu học phần Cấu trúc và nội dung

Tài liệu tham khảo Chương 1. Tổng quan về PTTKHT

Các sự kiện tiến hóa

• Thu thập TT • Con người và thiết bị

Các sự kiện hoạt động

1.1.1 Các khái niệm cơ bản

Người phân tích hệ thống

What Do System Analysts Like What Do System Analysts Dislike

Preparing for Your Career 1.1.2 Mô hình hóa hệ thống

1.1.2 Mô hình hóa hệ thống 1.1.2 Mô hình hóa hệ thống

1.1.3. Quy trình phân tích thiết kế hệ thống

Pha phân tích Pha thiết kế

1.2.3. Đánh giá các hướng tiếp cận

1.2.3. Đánh giá các hướng tiếp cận

Các dự án IS đến từ đâu?

Project Initiation o Utilize a new technology

Quản trị quy trình kinh doanh là gì?

Bài tập Yêu cầu

20/12/2013 Bộ môn CNTT - Khoa HTTT Kinh tế và TMDT 46

Kiến trúc hướng mô hình (MDA)

20/12/2013 Bộ môn CNTT - Khoa HTTT Kinh tế và TMDT 55 56

Phần tử mô Ý nghĩa Cách biểu diễn Ký hiệu trong biểu đồ

• Biểu diễn sơ đồ chức năng của hệ thống.

Biểu đồ lớp (Class diagram) Class diagram

• Quan hệ kết hợp (association):

• Quan hệ phụ thuộc (dependency):

Biểu đồ trạng thái

67 20/12/2013 Bộ môn CNTT - Khoa HTTT Kinh tế và TMDT 68

Biểu đồ trạng thái Biểu đồ trạng thái

Biểu đồ trạng thái

20/12/2013 Bộ môn CNTT - Khoa HTTT Kinh tế và TMDT 71 72

Biểu đồ trạng thái

Các thông điệp

Ý nghĩa: 1 Gọi (call) Mô tả một lời gọi từ đối

5 Hủy (destroy) Hủy một đối tượng << Destroy>>

Chức năng thêm sách

77 20/12/2013 Bộ môn CNTT - Khoa HTTT Kinh tế và TMDT 78

Biểu đồ hoạt động

Biểu đồ tương tác tổng

Biểu đồ thành phần

Biểu đồ thành phần Biểu đồ thành phần

Biểu đồ gói Biểu đồ gói

Biểu đồ gói Biểu đồ triển khai

Phần tử mô Ý nghĩa Ký hiệu trong biểu đồ Biểu đồ triển khai

Các bộ xử lý Biểu diễn các thành phần có bộ

Các liên kết Nối các thành phần của biểu đồ

Biểu đồ triển khai

Biểu đồ giao tiếp 2.2. Một số công cụ phân tích thiết kế

2.2.1. Giới thiệu 2.2.1. Giới thiệu (tt)

Rational Rose Visio

StarUML UML designer tool

Draw.IO 2.2.3. Công cụ thiết kế

Câu hỏi ôn tập Chương 2

20/12/2013 Bộ môn CNTT - Khoa HTTT Kinh tế và TMDT 105

Tổng quan về pha phân tích

Yêu cầu hệ thống

113 20/12/2013 Bộ môn CNTT - Khoa HTTT Kinh tế và TMDT 114

Khả thi về mặt tài chính

 Assess financial viability o Consider tangible and intangible

Khả thi về mặt tổ chức

119 20/12/2013 Bộ môn CNTT - Khoa HTTT Kinh tế và TMDT 120

Organizational Feasibility Đánh giá tính khả thi