Bài giảng Phân tích và thiết kế hệ thống thông tin - Phần 3: Phân tích hệ thống - Nguyễn Anh Hào

Phân tích & thiết kế H.T.T.T Phần 3: Phân tích hệ thống Nguyễn Anh Hào Khoa CNTT2 – HV CNBCVT Cơ sở Tp.HCM 0913609730 – nahao@ptithcm.edu.vn 2 Nội dung bài giảng 1. Hành động phân tích hệ thống 2. Yêu cầu đ/v hệ thống từ môi trường 3. Đặc tả hệ thống • Coi hệ thống là một đối tượng lớn: ranh giới của nó tách hệ thống thành 2 phần: bên trong và bên ngoài • Nhìn từ ngoài: đặc tả những gì hệ thống sẽ làm cho môi trường (usecase) • Nhìn vào bên trong: đặc tả kết cấu các thành phần (đối tượng) cần thiết của hệ thống (classes) và các quan hệ giữa các đối tượng này. 3 SE: phân tích hệ thống • Trong SE, phân tích hệ thống: – Là quá trình chuyễn đổi yêu cầu đ/v hệ thống thành đặc tả về hệ thống. Các đặc tả này sẽ phải hiện thực trong hệ thống sau khi nó được “cải tạo”. – Đặc tả hệ thống = cấu trúc logic của hệ thống, nhìn từ phía người phát triễn hệ thống, trong đó: • Có các thành phần hợp thành hệ thống (các đối tượng) • Có các quan hệ nội tại giữa các thành phần, mà người phát triễn phải tìm ra và sử dụng chúng. • Yêu cầu đối với hệ thống: – Từ đâu ra ? Có phải là từ người sử dụng ? Tất cả các câu hỏi này phải được giải đáp từ cách lý giải về sự tồn tại của hệ thống bằng lý thuyết hệ thống 4 Sự tương tác của hệ thống Đề thực hiện được vai trò, hệ thống phải có các tương tác với môi trường để tạo ra / lấy những thứ cần thiết cho / từ môi trường. Sự tương tác này hình thành các yêu cầu chức năng của hệ thống. Hệ thống là cổ máy biến inputs thành outputs cho môi trường 5 Quan hệ giữa hệ thống - môi trường • Hệ thống lớn (môi trường) phải giải quyết nhiều vấn đề để giúp nó tồn tại, được gọi là miền vấn đề (problem domain). – Vd: Công ty phải làm gì để tồn tại được ?... • Miền vấn đề chứa các vấn đề có tính quy luật (khách quan, và kết dính với nhau theo cách nào đó) – Vd: chuổi nghiệp vụ của tổ chức được xem là “bất biến” (khách quan) vì người ta có lý do để làm như vậy. – Domain Model: mô hình cho miền vấn đề • Hệ thống đang xem xét là một bộ phận của hệ thống lớn, do đó nó có vai trò hổ trợ giải quyết tốt các vấn đề của hệ thống lớn, thông qua các tương tác của nó. 6 Yêu cầu từ môi trường • Sự tương tác giữa hệ thống với môi trường bên ngoài hình thành yêu cầu đối với hệ thống (cái gì nó phải làm ra, và phải chuyễn giao như thế nào,) • Yêu cầu (từ tương tác) được xác định đúng (giải quyết đúng bản chất của vấn đề trong miền vấn đề) thì hệ thống sẽ hoạt động ổn định (ít bị thay đổi). • Như vậy, khía cạnh đầu tiên của việc phân tích yêu cầu là hiểu đúng bản chất của các tương tác trong môi trường mà hệ thống sẽ vận hành. – Phân tích các quan hệ cộng tác với nhau ở bên ngoài (trong hệ thống lớn hơn) và có liên quan đến hệ thống. 7 Cách đặc tả hệ thống (1) A. Nhìn hệ thống từ bên ngoài (outside view – ‘what’): 1. Xác định phạm vi trách nhiệm (vai trò) của hệ thống. 2. Mô hình hóa các quy luật cộng tác trong môi trường có hệ thống tham gia. – Tìm ra các quy luật cộng tác mang tính bản chất – Vẽ Workflow,Dataflow,Collaboration,Activity, 3. Xác định các tương tác cơ bản nhất, quyết định vai trò của hệ thống trong môi trường (Usecases) 4. Đặc tả ứng xử của hệ thống đ/v từng usecase – “Phương thức” của hệ thống, scenario 8 Vai trò của use-case Nhìn vào bên trong: Những đối tượng trong hệ thống hợp tác thực hiện use-case như thế nào ? Nhìn từ bên ngoài: Hệ thống sẽ làm được gì cho hệ thống lớn hơn (qua sự cộng tác với các actors) Use case Ranh giới của phần mềm 9 Lược đồ use case: nhìn từ ngoài 1. Với các đối tượng có trong hệ thống lớn (môi trường): – Đối tượng nào cần hệ thống phần mềm này, hoặc phần mềm này cần đối tượng nào ? 2. Định nghĩa use-case – Sự hợp tác trên có ý nghĩa gì đối với hệ thống lớn ? 3. Định nghĩa actor – Vai trò của các đối tượng trong hệ thống lớn (hoặc đối với usecase) là gì ? 4. Vẽ lược đồ use case – nhìn từ bên ngoài cho hệ thống phần mềm 10 ví dụ 1: coffee drink Người ta cần gì ở tách cà phê ? 11 Coffee cup: interfaces 12 Coffee cup: use cases - external Sitting Filling Holding Drinking Pouring Holding 13 Ví dụ 2: Quản lý kho trong nhà hàng Kho (lưu trữ) Quầy phục vụ (bán) Nhà bếp (chế biến) Văn phòng (điều khiển) Nguyên liệu Thức ăn Nhà cung câp (cung ứng) Khách hàng (tiêu thụ) Hàng hóa, Dịch vụ Tiền trả Tiền thu Tiền trả Nguyên liệu Đối thủ (cạnh tranh) Chính phủ (ra luật) Thông tin, mệnh lệnh Quy định 14 Các tương tác liên quan đến kho Kho (lưu trữ) Nhà bếp (chế biến) Văn phòng (điều khiển) Nhà cung câp (cung ứng) Thủ kho Giám đốcNgười bán Đầu bếp “Tôi cần ” “Xuất cho ” “Tôi đặt mua ” “Tôi giao ” “Đề nghị trả tiền ” “Trả tiền mua .” UML dùng thông điệp để diễn tả cho tương tác 15 Thông điệp (message) • Thông điệp là một thông báo mang yêu cầu hoặc phản hồi, gửi từ một đối tượng đến một đối tượng. • Trong UML, thông điệp được diễn tả là: [điều kiện] (thông sô) – [điều kiện]: điều kiện để thông điệp xuất hiện (biểu thức logic) – : tên của thông điệp – (thông số): các thuộc tính của nhóm thông điệp • Ví dụ, sau khi login, khách có thể đặt hàng trên website: [acc=valid] Đặt hàng (mã kh,mã hàng,số lượng, ngày) 16 Kho của nhà hàng: Lược đồ cộng tác Thủ kho Đầu bếp Giám đốcNgười bán y/c xuất(hàng,slg, pyc#) Xuất (hàng,slg, pyc#) Đặt mua(hàng,slg) Giao(hàng,slg,hđ#) y/c trả tiền (tiền, hđ#) Trả tiền (tiền, hđ#) Trong UML v2: lược đồ này gọi là communication diagram 17 Quản lý kho: use-cases (a) Thủ kho Đặt hàng Nhập kho Xuất kho y/c trả tiền PM quản lý kho Người bán Giám đốc Đầu bếp Phạm vi sử dụng của phần mềm (a): chỉ giới hạn ở các tương tác với thủ kho 18 Quản lý kho:use-cases (b) Thủ kho Đặt hàng Nhập kho Xuất kho y/c trả tiền PM quản lý kho Người bán Giám đốc Đầu bếp Phạm vi sử dụng của phần mềm (b): có các tương tác với thủ kho, người bán, giám đốc, và đầu bếp 19 Ví dụ 3: hệ thống khóa cửa • Hệ thống khóa cửa yêu cầu chìa khóa là số pin để mở cửa. Có 2 tình huống: số pin đúng và số pin sai Book_SE_2012.pdf Page 82 20 Lược đồ tuần tự: chìa khóa đúng 21 Lược đồ tuần tự: chìa khóa sai 22 Lược đồ usecase: hệ thống khóa cửa Book_SE_2012.pdf Page 92 23 Usecase - Glossary – glossary: là chuỗi quá trình tương tác giữa hệ thống phần mềm với actor USECASE: Actors Actor’s goal Tình huống tương tác trên usecase 1. Actor : 2. SYSTEM: 3 24 Test usecase • Để biết xem usecase có ích như thế nào ? • BOSS TEST: – “What have you been doing all day?” – “Log in !” is a very, very bad answer (no value) • The Elementary Business Process (EBP) test – Một công việc sẽ phải góp phần tạo ra giá trị cho tổ chức (xử lý các sự kiện / tình huống / vấn đề cho tổ chức) – Good: Nhận đơn đặt hàng, xác nhận đơn hàng – Bad: xem, xóa, sửa,in, đơn đặt hàng (là các tác vụ ở mức chức năng) 25 Test Use-case example Is this a useful use case diagram for ATM ? NO ! A use case should satisfy a goal for the actor. 26 Test Use-case example Book_SE_2012.pdf Page 93 27 Vai trò của use-case Nhìn vào bên trong: Những đối tượng trong hệ thống hợp tác thực hiện use-case như thế nào ? Nhìn từ bên ngoài: Hệ thống sẽ làm được gì cho hệ thống lớn hơn (qua sự cộng tác với các actors) Use case Ranh giới của phần mềm 28 Nhìn vào bên trong hệ thống Ví dụ: hệ thống khóa cửa Book_SE_2012.pdf 29 Cách đặc tả hệ thống (2) B. Nhìn vào bên trong hệ thống (inside view – ‘how’): 1. Tìm đối tượng cần thiết trong hệ thống (object model) – CRC card (Class-Responsibility-Collaboration) – Lược đồ lớp với các quan hệ: tổng quát hóa, kết tập (aggregation), liên hệ (association). 2. Mô hình hóa dịch vụ của các đối tượng bên trong hệ thống gắn với từng usecase (functional model) – Lược đồ cộng tác, tuần tự, hoạt động 3. Mô hình hóa cách ứng xử của hệ thống (dynamic model) – Lược đồ trạng thái 30 CRC card • CRC (class – responsibilities – collaborators) là một cấu trúc bảng để mô tả khái quát vai trò (có thể là cần thiết) của một đối tượng trong hệ thống. CRC được lập ra từ tình huống sử dụng đối tượng trong usecase • Ví dụ: CRC card cho Card Reader của máy ATM 31 Lập CRC: Bước 1 • Là bước tìm các đối tượng bằng brain-storming • Viết ra các đối tượng biết được trong miền vấn đề – Chú ý đến các danh từ trong mô tả (objects are nouns) – Object có thuộc tính và dịch vụ • Sau đó, lọc và tinh chỉnh lại các đối tượng này – Có giao tiếp phù hợp nhau (trong phạm vi ứng dụng) – Loại bỏ sự trùng lặp: • Nó có là thuộc tính của các đối tượng khác ? • Nó có là thể hiện của lớp đối tượng nào đó ? • Nó có là lớp con của lớp đối tượng nào đó ? 32 Lập CRC: Bước 2 • Với mỗi đối tượng tìm được, định nghĩa lớp đối tượng của nó (chỉ bằng tên gọi) • Với mỗi lớp đối tượng, tạo ra một CRC card cho nó. • Vai trò ( trách nhiệm) của đối tượng có thể là: – Chứa thông tin dùng được cho các đối tượng khác – Làm cầu nối (liên kết các đối tượng bằng quan hệ) – Cung cấp dịch vụ cho các đối tượng khác – Điều khiển đối tượng khác (controller) – Chuyễn đổi giao tiếp cho các đối tượng 33 Lập CRC: Bước 3 • Tinh chỉnh cards: – Xem xét các tình huống sử dụng – Cập nhật thêm nhiệm vụ của đối tượng – Viết thêm các cộng tác viên để thực hiện nhiệm vụ của đối tượng 34 Ví dụ 1: Coffee cup Brainstorming: Cái tách cà phê nào tốt ? 35 Coffee cup: component objects For sitting For filling = pouring & holding coffee,.. For holding For drinking BOWL HANDLE 36 Coffee cup: CRC cards Class BOWL Responsibilities Collaborators Pour(coffee/tea/water/) Hold(coffee/tea/water/) Drink(coffee/tea/water/) HANDLE Sit_on(table/desk/ground/) Class HANDLE Responsibilities Collaborators Hold_by (hand/robot hand/) 37 Ví dụ 2: Thiết kế đồng hồ • Chúng ta cần tạo ra cái đồng hồ. Yêu cầu là: 1. Có cách để đặt thời gian cho đồng hồ • ie, nhớ được thời gian 2. Hiển thị thời gian giờ, phút, giây theo khuông mẫu • 12h+AM/PM; 24h; hoặc đồng hồ kim, 3. Cập nhật thời gian đúng với giờ hiện hành. • Đếm thời gian chính xác từng giây 38 Làm lần đầu • Brainstorming – Attributes: hours, mins, secs, timezone,state(low bat,..) – Services: update(), setTime(), alarm(), setAlarm(), displayTime(), displayDate(), setAmPm(), getAmPm(),... • Filter/requirements: ticker, hours, minutes, seconds • Class CLOCK: – Attributes: seconds, minutes, hours, displayFormat – Services: get/set, nextSecond, display, setFormat 39 Sai !! • Chúng ta giả định rằng chỉ có 1 lớp đồng hồ: Clock. – Làm sao để dùng lại ? • Chúng ta bắt đầu từ dữ liệu và không bắt đầu từ vai trò / trách nhiệm – Không có sự chia sẽ trách nhiệm giữa các đối tượng, không tìm ra được sự cộng tác. • Ngay từ đầu, chúng ta quá chú tâm vào việc lập trình theo chức năng. 40 Làm lại lần 2 • Brainstorm objects for Clock – Clock, Display, Formatter, Time, SecondTicker – – Clock (function: display, format), Time. SecondTicker • CRC Cards: – Có hai tình huống: 1. Update time: Khi bộ xung nhịp (SecondTicker) tạo ra 1 xung (sau 1 giây) cho đồng hồ, thời gian của đồng hồ (Time) phải tăng lên 1 giây. 2. Display time: Khi đồng hồ (clock) cần hiển thị thời gian, thời gian phải được đọc từ bộ lưu thời gian (Time) và định dạng hiển thị theo khuông mẫu đã ấn định. 41 CRC cho tình huống 1: Update time 1. Bộ xung 1 giây (seconds-Ticker) kích hoạt đồng hồ (clock) 2. Đồng hồ thông báo 1 giây đã trôi qua cho bộ đếm thời gian (time) 3. Bộ đếm thời gian tự cập nhật lại thời gian của nó (giờ:phút:giây) 42 CRC cho tình huống 2: Display time 1. Đồng hồ cần hiển thị thời gian lấy từ bộ đếm thời gian (time) 2. Bộ đếm thời gian trả về giờ, phút, giây hiện tại 43 CRC cho tình huống 2: Display time 3. Đồng hồ chuyễn thời gian (giờ, phút, giây) thành dạng hiển thị 44 Finished CRC 45 Clock object model Clock Set Clock Time Second ticker 46 CRC Clock: Lược đồ cộng tác Clock TimeSecond ticker 1: Pulse() 2: Inform(Pulse) 3:UpdateTime() Update time: 47 CRC Clock: Lược đồ cộng tác Clock Time 1: Inform(Pulse) 2:Time(hr, m, s) Display time: 3:DisplayTime(hr, m, s) 48 Ví dụ “Quản lý tài khoản ngân hàng” Bank Employee Bank Teller Bank Manager Manage Account Open Account Close Account Monitor Account Account Management Software 49 “Open Account” Scenario Bank Manager Open Account 1.BM: Request Open Account 2.SYSTEM: Ask Customer Data 3.BM: Give Customer Data 4.SYSTEM: Ask Account Type 5.BM: Give Account Type 6.SYSTEM: Ask Initial Balance 7.BM: Give Initial Balance 8.SYSTEM: Confirm to BM USE CASE: Open Account Actor: Bank Manager (BM) Actor’s goal: Create a new Customer’s Account on the System Basic flows: 50 Lược đồ tuần tự cho “Open account” Bank Manager OpenAccount(id) AskCustInfo(id) CustomerInfo(data) AskAccountType(id) AccountType(AccType) AskInitialBalance(id) Balance(InitBalance) Confirm(ResultCode) SYSTEM Lớp SYSTEM có nhiệm vụ gì ? 3. Lưu trữ để sử dụng CRC Lớp Customer Manager Lớp Account Manager Lớp Database 1. Nhận biết khách hàng 2. Cấp tài khoản (loại, số dư) 51 Lược đồ tuần tự cho “Open account” Bank Manager Cust manager OpenAccount(id) AskCustInfo(id) CustomerInfo(data) AskAccountType(id) AccountType(AccType) AskInitialBalance(id) Balance(InitBalance) Confirm(ResultCode) Acc manager Acc DB Activate(CustData) CreateAcc (Cust, Acc) 52 Lược đồ cộng tác cho “Open account” Bank Manager CustManager 1: OpenAccount(id) 2: AskCustInfo(id) 3: CustomerInfo(data) 5: AskAccountType(id) 6: AccountType(Acctype) 7: AskIntialBalance(id) 8: Balance(InitBalance) 10: Confirm(id,ResultCode) AccManager 4: Activate (CustData) AccDatabase 9: CreateAcc (CustData,Acc) 53 Lược đồ hoạt động cho “Open account” New customer Get Cutomer Data Create Account Cust Manager Get Account Type Old customer Acc Manager AccDatabase Get Initial Balance 54 Lược đồ trạng thái cho “Open account” New customer CustData: ready Cust Manager Acc Manager AccDatabase CustData: none AccType: ready AccType: none AccInit: none AccInit: ready Get Account Type Get Acc balance CustAcc: ready CustAcc: none Create Account Get customer data 55 Đặc tả chi tiết lớp • Ngoài tên gọi, đối tượng còn có thuộc tính và phương thức xử lý. – Thuộc tính: là đặc tính của đối tượng (có thể public, private hay protected) – Phương thức: là hành động của đối tượng (có thể public- gọi là dịch vụ, hay private- hành vi bên trong) • Sự đặc tả chi tiết cho đối tượng bắt nguồn từ cách nhìn từ bên ngoài đối với đối tượng (nhìn ra các thuộc tính và hành động xử lý cần thiết cho hệ thống) – ký hiệu trước thuộc tính/phương thức: + : Public, - : Private, # : Protected 56 Đặc tả thuộc tính của lớp Tùy trường hợp sử dụng. (1) (2) (3) (4) • Cách nào đúng ? 57 Từ lược đồ class: quan hệ kế thừa Nhân viên -tên,tuổi -Vai trò - Nhiệm vụ Bác sỹ -tên,tuổi -Vai trò - Nhiệm vụ Người -tên, tuổi Bác sỹ -tên,tuổi Bác sỹ -tên,tuổi -Vai trò - Nhiệm vụ +Khám() +Điều trị() Chữa bệnh +Khám() +Điều trị() Dược sỹ -tên,tuổi -Vai trò - Nhiệm vụ +Cấp thuốc() Làm thuốc +Cấp thuốc() 58 Từ lược đồ class: Association ProjectEmployee * * Work_on Hours Start_date Work_on -E: Employee -P: Project -Hours -Start_date Bệnh nhânBác sỹ Điều trị 1 * BN -My doctor : BS BS -My Patients[ ]: BN +ĐieuTri (x:BN) 59 Từ lược đồ class: Aggregation Car Bike Engine Wheel Car -List of (Engine) -List of (Wheel) Bike -List of (Wheel) A "uses" B = Aggregation : B exists independently (conceptually) from A 60 Từ lược đồ class: Composition Person Leg Arm Person -MyArm : Arm -MyLeg : Leg A "owns" B = Composition : B has no meaning or purpose in the system without A 61 Đặc tả phương thức xử lý của lớp • Dynamic view • Các phương thức này là những dịch vụ của đối tượng trong hệ thống, được trích ra từ các lược đồ mô tả các tương tác trong hệ thống: – Lược đồ cộng tác, tuần tự – Lược đồ hoạt động 62 Từ lược đồ tuần tự Person Free Kick(c) Inspector Event(m,c) Report( p,c) Cat Rear Report( m) Police Crime(p,c) Arrest( p) 63 Đặc tả cho đối tượng – thành phần • Đặc tả đối tượng = đặc tả các thuộc tính & phương thức cần thiết cho hệ thống (loại public, protect) • Các thuộc tính & phương thức riêng (private) được đặc tả chỉ để hướng dẫn cách cài đặt cho đối tượng. 64 Đặc tả phương thức: “Open account” Bank Manager Cust manager OpenAccount(id) AskCustInfo(id) CustomerInfo(data) AskAccountType(id) AccountType(AccType) AskInitialBalance(id) Balance(InitBalance) Confirm(ResultCode) Acc manager Acc DB Activate(CustData) CreateAcc (Cust, Acc) SYSTEM = SOFTWARE INTERFACE : USER - SOFTWARE Kích hoạt từ menu “open account” 65 Đặc tả phương thức: “Open account” Bank Manager Cust Manager OpenAccount(id) AskCustInfo(id) CustomerInfo(data) Activate (CustData) Acc Manager Cust Manager + Open Account () -AskCustInfo():FORM -Activate(AM,CustData) Open Account Cust.Name: Cust.Addr: OK> Ký hiệu UML: > Ký hiệu UML: 66 Đặc tả phương thức: “Open account” Bank Manager AskAccountType(id) AccountType(AccType) AskInitialBalance(id) Balance(InitBalance) Acc Manager CreateAcc (Cust, Acc) Activate(CustData) Cust Manager Acc DB Acc Manager + Activate (CustData) -AskAccType(): FORM -AskInitBalance(): FORM -Create(ACDB,Cust,Acc) 67 Đặc tả phương thức: “Open account” Confirm(ResultCode) Acc manager Acc DB CreateAcc (Cust, Acc) Acc DB +CreateAcc (Cust, Acc) -DBAdd(DB,Cust,Acc) -Confirm() : FORM Bank Manager DBMS > Ký hiệu UML: 68 Stereo types • Lớp biên (boundary): để tương tác giữa actor với hệ thống, vd: form giao diện cho user, tương tác với thiết bị. • Lớp điều khiển (control): phân phối các thông điệp để thực hiện usecase • Lớp thực thể (entity): lớp có chứa dữ liệu cho các tương tác trong usecase > > >