Bài giảng Phân tích và thiết kế hệ thống hướng đối tượng bằng UML - Object Oriented Systems Analysis and Design Using UML

M c đích môn h c ục đích môn học ọc– Các bước thu thập yêu cầu, phân tích và thiết kế hệ c thu th p yêu c u, phân tích và thi t k h ập yêu cầu, phân tích và thiết kế hệ ầu, phân tích và

Object Oriented

Systems Analysis and Design Using UML

1

M c đích môn h c ục đích môn học ọc

– Các bước thu thập yêu cầu, phân tích và thiết kế hệ c thu th p yêu c u, phân tích và thi t k h ập yêu cầu, phân tích và thiết kế hệ ầu, phân tích và thiết kế hệ ết kế hệ ết kế hệ ệ

th ng thông tin theo cách ti p c n hống thông tin theo cách tiếp cận hương đối tượng ết kế hệ ập yêu cầu, phân tích và thiết kế hệ ương đối tượng.ng đ i tống thông tin theo cách tiếp cận hương đối tượng ượng.ng

– Dùng ngôn ng UML đ mô hình và vi t s u li u cho h ữ UML để mô hình và viết sưu liệu cho hệ ể mô hình và viết sưu liệu cho hệ ết kế hệ ư ệ ệ

th ng.ống thông tin theo cách tiếp cận hương đối tượng

– Chuy n lể mô hình và viết sưu liệu cho hệ ượng.c đ phân tích thành lồ phân tích thành lược đồ thiết kế: ượng.c đ thi t k : ồ phân tích thành lược đồ thiết kế: ết kế hệ ết kế hệ

• Thi t k h th ng, Thi t k đ i t ết kế hệ ết kế hệ ệ ống thông tin theo cách tiếp cận hương đối tượng ết kế hệ ết kế hệ ống thông tin theo cách tiếp cận hương đối tượng ượng ng, Thi t k c s d ết kế hệ ết kế hệ ơng đối tượng ở dữ ữ UML để mô hình và viết sưu liệu cho hệ

li u, Thi t k giao di n ng ệ ết kế hệ ết kế hệ ệ ười dùng i dùng

– Nh p môn c s d li uập yêu cầu, phân tích và thiết kế hệ ơng đối tượng ở dữ ữ UML để mô hình và viết sưu liệu cho hệ ệ

– L p trình nâng cao ập yêu cầu, phân tích và thiết kế hệ

2

Topic Content

3

Course Text Books

the Standard Object Modeling Language, 3nd

Farmer, Object-Oriented Systems Analysis and

Design Using UML, 3nd Edition, McGraw Hill,

2006

Introduction to Object-Oriented Analysis and

Design and Iterative Development, 3nd Edition,

Addison Wesley, 2004

4

Đánh giá k t qu môn h c ết ả môn học ọc

1. Đ án môn h c: t i đa 10đ, tr ng s 50% ồ án môn học: tối đa 10đ, trọng số 50% ọc ối đa 10đ, trọng số 50% ọc ối đa 10đ, trọng số 50%

– Nhóm g m 2-3 sinh viênồ phân tích thành lược đồ thiết kế:

– Ch n m t đ tài và ti n hành thu th p yêu c u, phân ọn một đề tài và tiến hành thu thập yêu cầu, phân ột đề tài và tiến hành thu thập yêu cầu, phân ề tài và tiến hành thu thập yêu cầu, phân ết kế hệ ập yêu cầu, phân tích và thiết kế hệ ầu, phân tích và thiết kế hệ

tích, thi t k h th ng theo ti n trình n i dung c a ết kế hệ ết kế hệ ệ ống thông tin theo cách tiếp cận hương đối tượng ết kế hệ ột đề tài và tiến hành thu thập yêu cầu, phân ủa môn h c.ọn một đề tài và tiến hành thu thập yêu cầu, phân

– Ki m tra ti n đ th c hi n đ tài b ng cách ch đ nh ể mô hình và viết sưu liệu cho hệ ết kế hệ ột đề tài và tiến hành thu thập yêu cầu, phân ực hiện đề tài bằng cách chỉ định ệ ề tài và tiến hành thu thập yêu cầu, phân ằng cách chỉ định ỉ định ịnh

sinh viên thuy t trình trên l p.ết kế hệ ớc thu thập yêu cầu, phân tích và thiết kế hệ

– Cu i h c kỳ, báo cáo và demo chống thông tin theo cách tiếp cận hương đối tượng ọn một đề tài và tiến hành thu thập yêu cầu, phân ương đối tượng.ng trình cho phiên

b n cu i cùng c a đ án môn h c.ản cuối cùng của đồ án môn học ống thông tin theo cách tiếp cận hương đối tượng ủa ồ phân tích thành lược đồ thiết kế: ọn một đề tài và tiến hành thu thập yêu cầu, phân

2. Thi cu i h c kỳ b ng hình th c tr c nghi m: ối đa 10đ, trọng số 50% ọc ằng hình thức trắc nghiệm: ức trắc nghiệm: ắm bắt: ệm:

t i đa 10đ, tr ng s 40% ối đa 10đ, trọng số 50% ọc ối đa 10đ, trọng số 50%

3. Đi m chuyên c n, th o lu n trên l p: tr ng ểm chuyên cần, thảo luận trên lớp: trọng ần, thảo luận trên lớp: trọng ả môn học ận trên lớp: trọng ớp: trọng ọc

s 10% V ng 40% s bu i c m thi l n 1 ối đa 10đ, trọng số 50% ắm bắt: ối đa 10đ, trọng số 50% ổi cấm thi lần 1 ấm thi lần 1 ần, thảo luận trên lớp: trọng

5

TỔNG QUAN VỀ HỆ THỐNG THÔNG TIN

6

TỔNG QUAN VỀ HỆ THỐNG

THÔNG TIN

• Khái ni m c b n v h th ng (System) ệm: ơ bản về hệ thống (System) ả môn học ề hệ thống (System) ệm: ối đa 10đ, trọng số 50%

• T ch c (Organization) ổi cấm thi lần 1 ức trắc nghiệm:

(Management decision making)

Systems)

– Các IS phân lo i theo m c qu n lý t ch c.ại theo mức quản lý tổ chức ức quản lý tổ chức ản cuối cùng của đồ án môn học ổ chức ức quản lý tổ chức

7

Khái niệm cơ bản về hệ thống

"M t h th ng là m t t p h p các thành ph n ột hệ thống là một tập hợp các thành phần ệm: ối đa 10đ, trọng số 50% ột hệ thống là một tập hợp các thành phần ận trên lớp: trọng ợp các thành phần ần, thảo luận trên lớp: trọng

liên quan v i nhau và ph i h p ho t đ ng cùng ớp: trọng ối đa 10đ, trọng số 50% ợp các thành phần ạI IS ột hệ thống là một tập hợp các thành phần

v i nhau nh m đ t đ ớp: trọng ằng hình thức trắc nghiệm: ạI IS ượp các thành phần c m t m c tiêu c th " ột hệ thống là một tập hợp các thành phần ục đích môn học ục đích môn học ểm chuyên cần, thảo luận trên lớp: trọng (Lee)

Environment

of System A

Tổ chức (Organization)

• T ch c là m t h th ng ổi cấm thi lần 1 ức trắc nghiệm: ột hệ thống là một tập hợp các thành phần ệm: ối đa 10đ, trọng số 50%

– T ch c kinh t : xí nghi p, công ty, … ổ chức ức quản lý tổ chức ết kế hệ ệ

– T ch c xã h i: b nh vi n, câu l c b , … ổ chức ức quản lý tổ chức ột đề tài và tiến hành thu thập yêu cầu, phân ệ ệ ại theo mức quản lý tổ chức ột đề tài và tiến hành thu thập yêu cầu, phân

9

Sales

IT

HRIPurchasing

Dữ liệu và thông tin

• D li u (data): ữ liệu (Data) và thông tin (information) ệm:

"Data is the raw input from which information is provided” (Lucey)

– Là các d ki n, các s ki n, các giao d ch thô, r i r c, ữ UML để mô hình và viết sưu liệu cho hệ ệ ực hiện đề tài bằng cách chỉ định ệ ịnh ời dùng ại theo mức quản lý tổ chức.

• Thông tin (information):

“Information is data that have been processed in such a way as to be useful to the recipient.” (Lucey)

• Thông tin là tài nguyên c a t ch c, và có vai trò quan ủa tổ chức, và có vai trò quan ổi cấm thi lần 1 ức trắc nghiệm:

tr ng quy t đ nh s thành công c a t ch c ọc ết ịnh quản lý ự thành công của tổ chức ủa tổ chức, và có vai trò quan ổi cấm thi lần 1 ức trắc nghiệm:

– Thông tin đ ượng ại theo mức quản lý tổ chức c t o ra và truy xu t ngày càng tăng ất ngày càng tăng

– Yêu c u qu n lý thông tin hi u qu ầu, phân tích và thiết kế hệ ản cuối cùng của đồ án môn học ệ ản cuối cùng của đồ án môn học.

– X lý đ t o ra các thông tin m i có giá tr h n ử lý để tạo ra các thông tin mới có giá trị hơn ể mô hình và viết sưu liệu cho hệ ại theo mức quản lý tổ chức ớc thu thập yêu cầu, phân tích và thiết kế hệ ịnh ơng đối tượng.

10

Information Systems (IS)

• M t h th ng thông tin: ột hệ thống là một tập hợp các thành phần ệm: ối đa 10đ, trọng số 50%

– Là các phương đối tượng.ng ti n có th nh n d li u (input), l u tr ệ ể mô hình và viết sưu liệu cho hệ ập yêu cầu, phân tích và thiết kế hệ ữ UML để mô hình và viết sưu liệu cho hệ ệ ư ữ UML để mô hình và viết sưu liệu cho hệ

và x lý d li u, đ t o ra thông tin (output) cho m c ử lý để tạo ra các thông tin mới có giá trị hơn ữ UML để mô hình và viết sưu liệu cho hệ ệ ể mô hình và viết sưu liệu cho hệ ại theo mức quản lý tổ chức ục đích h tr ra quy t đ nh.ỗ trợ ra quyết định ợng ết kế hệ ịnh

– Có th x lý b ng tay ho c máy tính.ể mô hình và viết sưu liệu cho hệ ử lý để tạo ra các thông tin mới có giá trị hơn ằng cách chỉ định ặc máy tính

• H th ng thông tin c a t ch c g m: ệm: ối đa 10đ, trọng số 50% ủa tổ chức, và có vai trò quan ổi cấm thi lần 1 ức trắc nghiệm: ồ án môn học: tối đa 10đ, trọng số 50%

– M t c s thông tin (information base) mà bao g m ột đề tài và tiến hành thu thập yêu cầu, phân ơng đối tượng ở dữ ồ phân tích thành lược đồ thiết kế:

m t hay nhi u ngu n thông tin khác; ột đề tài và tiến hành thu thập yêu cầu, phân ề tài và tiến hành thu thập yêu cầu, phân ồ phân tích thành lược đồ thiết kế:

– M t t p các quy trình nghi p v mà đột đề tài và tiến hành thu thập yêu cầu, phân ập yêu cầu, phân tích và thiết kế hệ ệ ục ượng.c th c hi n b i ực hiện đề tài bằng cách chỉ định ệ ở dữ

người dùngi hay máy đ truy xu t, c p nh p và x lý thông ể mô hình và viết sưu liệu cho hệ ất ngày càng tăng ập yêu cầu, phân tích và thiết kế hệ ập yêu cầu, phân tích và thiết kế hệ ử lý để tạo ra các thông tin mới có giá trị hơntin

– Ví d : M t h th ng th vi n có c s thông tin là sách, ục ột đề tài và tiến hành thu thập yêu cầu, phân ệ ống thông tin theo cách tiếp cận hương đối tượng ư ệ ơng đối tượng ở dữ

lo i sách, …; các nghi p v là tìm, mại theo mức quản lý tổ chức ệ ục ượng.n, tr sách, …ản cuối cùng của đồ án môn học

11

H th ng thông tin t đ ng hóa ệm: ối đa 10đ, trọng số 50% ự thành công của tổ chức ột hệ thống là một tập hợp các thành phần

• H th ng thông tin t đ ng hóa (Computerized ệm: ối đa 10đ, trọng số 50% ự thành công của tổ chức ột hệ thống là một tập hợp các thành phần Information Systems) bao g m: ồ án môn học: tối đa 10đ, trọng số 50%

– M t hay nhi u c s d li u (databases) hay t p tin ột đề tài và tiến hành thu thập yêu cầu, phân ề tài và tiến hành thu thập yêu cầu, phân ơng đối tượng ở dữ ữ UML để mô hình và viết sưu liệu cho hệ ệ ập yêu cầu, phân tích và thiết kế hệ

(files) l u tr c s thông tin.ư ữ UML để mô hình và viết sưu liệu cho hệ ở dữ ở dữ

– M t hay nhi u chột đề tài và tiến hành thu thập yêu cầu, phân ề tài và tiến hành thu thập yêu cầu, phân ương đối tượng.ng trình ng d ng (Application ức quản lý tổ chức ục

programs) đ truy xu t và c p nh t c s thông tin ể mô hình và viết sưu liệu cho hệ ất ngày càng tăng ập yêu cầu, phân tích và thiết kế hệ ập yêu cầu, phân tích và thiết kế hệ ơng đối tượng ở dữ

Thông tin và các c p qu n lý ấm thi lần 1 ả môn học

• Thông tin c n thi t cho doanh nghi p và giúp ra quy t ần, thảo luận trên lớp: trọng ết ệm: ết

đ nh nhi u m c qu n lý khác nhau trong t ch c ịnh quản lý ở nhiều mức quản lý khác nhau trong tổ chức ề hệ thống (System) ức trắc nghiệm: ả môn học ổi cấm thi lần 1 ức trắc nghiệm:

13

Anthony’s Pyramid: cấu trúc quản lý của tổ chức

Operational Tactical Strategic

Detail data

Unstructured problems

Structured problems

Transaction Processing Systems

Management Information Systems

16

Decision Support Systems

Best Practices of

Software Engineering

17

Objectives: Best Practices

• Identify symptoms of software development

problems.

• Explain the Best Practices.

• Present the Rational Unified Process (RUP)

within the context of the Best Practices.

18

M c đích c a công ngh ph n m m ục đích môn học ủa tổ chức, và có vai trò quan ệm: ần, thảo luận trên lớp: trọng ề hệ thống (System)

• Nh m t o ra s n ph m ph n m m có ch t l ằng hình thức trắc nghiệm: ạI IS ả môn học ẩm phần mềm có chất lượng ần, thảo luận trên lớp: trọng ề hệ thống (System) ấm thi lần 1 ượp các thành phần ng

– V i ít n l c (ti n trình phát tri n d dàng) ớc thu thập yêu cầu, phân tích và thiết kế hệ ỗ trợ ra quyết định ực hiện đề tài bằng cách chỉ định ết kế hệ ể mô hình và viết sưu liệu cho hệ ễ dàng)

– V i ít chi phí và th i gian ớc thu thập yêu cầu, phân tích và thiết kế hệ ời dùng

• Ch t l ấm thi lần 1 ượp các thành phần ng ph n m m (Quality Software) bao ần, thảo luận trên lớp: trọng ề hệ thống (System)

g m: ồ án môn học: tối đa 10đ, trọng số 50%

– Tính đáng tin c y (Reliable) ập yêu cầu, phân tích và thiết kế hệ

– Tính tái s d ng (Reusable) ử lý để tạo ra các thông tin mới có giá trị hơn ục

– Tinh t (Robust): có các ch c năng hi u qu ết kế hệ ức quản lý tổ chức ệ ản cuối cùng của đồ án môn học.

– D b o trì (Maintainable) ễ dàng) ản cuối cùng của đồ án môn học.

– Tính Hi u qu (Efficient) ệ ản cuối cùng của đồ án môn học.

– Thân thi n ng ệ ười dùng i dùng (Userfriendly)

– …

19

B n ch t vi c phát tri n ph n ả môn học ấm thi lần 1 ệm: ểm chuyên cần, thảo luận trên lớp: trọng ần, thảo luận trên lớp: trọng

m m ề hệ thống (System)

• Ph n m m là s n ph m c a ho t đ ng phát tri n ần, thảo luận trên lớp: trọng ề hệ thống (System) ả môn học ẩm phần mềm có chất lượng ủa tổ chức, và có vai trò quan ạI IS ột hệ thống là một tập hợp các thành phần ểm chuyên cần, thảo luận trên lớp: trọng

m t cách sáng t o c a các “ngh sĩ lành ngh ” ột hệ thống là một tập hợp các thành phần ạI IS ủa tổ chức, và có vai trò quan ệm: ề hệ thống (System)

– Ph n m m đ ầu, phân tích và thiết kế hệ ề tài và tiến hành thu thập yêu cầu, phân ượng c phát tri n, ch không ph i s n xu t ể mô hình và viết sưu liệu cho hệ ức quản lý tổ chức ản cuối cùng của đồ án môn học ản cuối cùng của đồ án môn học ất ngày càng tăng

– Ngay c v i công ngh thành ph n (Component ản cuối cùng của đồ án môn học ớc thu thập yêu cầu, phân tích và thiết kế hệ ệ ầu, phân tích và thiết kế hệ

technology), ph n m m đ ầu, phân tích và thiết kế hệ ề tài và tiến hành thu thập yêu cầu, phân ượng c xây d ng b ng cách l p ghép ực hiện đề tài bằng cách chỉ định ằng cách chỉ định ắp ghép các thành ph n thì x lý l p ghép này cũng là ngh thu t ầu, phân tích và thiết kế hệ ử lý để tạo ra các thông tin mới có giá trị hơn ắp ghép ệ ập yêu cầu, phân tích và thiết kế hệ

• Cho b t kỳ h th ng nào, luôn c n ph i t o ra m t ấm thi lần 1 ệm: ối đa 10đ, trọng số 50% ần, thảo luận trên lớp: trọng ả môn học ạI IS ột hệ thống là một tập hợp các thành phần

mô hình quan ni m c a gi i pháp cu i cùng th a ệm: ủa tổ chức, và có vai trò quan ả môn học ối đa 10đ, trọng số 50% ỏa mãn các yêu c u c a khách hàng ần, thảo luận trên lớp: trọng ủa tổ chức, và có vai trò quan

– Đó là k t qu c a nhi m v phân tích yêu c u và thi t k ết kế hệ ản cuối cùng của đồ án môn học ủa ệ ục ầu, phân tích và thiết kế hệ ết kế hệ ết kế hệ

h th ng ệ ống thông tin theo cách tiếp cận hương đối tượng.

– Đ c l p v i cài đ t ột đề tài và tiến hành thu thập yêu cầu, phân ập yêu cầu, phân tích và thiết kế hệ ớc thu thập yêu cầu, phân tích và thiết kế hệ ặc máy tính.

20

Symptoms of Software Development Problems

• User or business needs not met

• Requirements not addressed

• Modules not integrating

• Difficulties with maintenance

• Late discovery of flaws

• Poor quality of end-user experience

• Poor performance under load

• No coordinated team effort

• Build-and-release issues

22

Trace Symptoms to Root Causes

Overwhelming complexity Undetected inconsistencies Poor testing

Subjective assessment Waterfall development Uncontrolled change Insufficient automation

Ambiguous communications

Undetected inconsistencies

Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML)

Continuously Verify Quality Manage Change

Model Visually (UML) Continuously Verify Quality Modules do not fit

Best Practices Reinforce Each Other

24

Best Practices

Develop Iteratively Manage Requirements

Use Component Architectures

Model Visually (UML)

Continuously Verify Quality

Manage Change

Develop Iteratively Manage Requirements

Use Component Architectures

Model Visually (UML)

Continuously Verify Quality

Manage Change

Validates architectural decisions early on

Addresses complexity of design/implementation incrementally

Measures quality early and often

Evolves baselines incrementally Ensures users are involved

as requirements evolve

Practice 1: Develop Iteratively

25

Best Practices

Process Made Practical Best Practices

Process Made Practical

Develop Iteratively Manage Requirements

Use Component Architectures Model Visually (UML) Continuously Verify Quality

Manage Change

Develop Iteratively

Manage Requirements

Use Component Architectures Model Visually (UML) Continuously Verify Quality

Manage Change

Waterfall Development Characteristics

• Delays and aggregates

integration and testing.

System Test

Waterfall Process

Requirements

Analysis Planning

Iterative Development Characteristics

• Resolves major risks before making large investments

• Enables early user feedback

• Makes testing and integration continuous

• Focuses project short-term objective milestones

• Makes possible deployment of partial

Each iteration results in an executable release

Practice 2: Manage Requirements

30

Best Practices

Process Made Practical Best Practices

Process Made Practical

Manage Requirements

Use Component Architectures Model Visually (UML) Continuously Verify Quality

Manage Change

Develop Iteratively

Manage Requirements

Use Component Architectures Model Visually (UML) Continuously Verify Quality

Manage Change

Managing Requirements

• Ensures that you

– solve the right problem

– build the right system

• by taking a systematic approach to

– Understanding the problem

– Eliciting, organizing, and documenting the

requirements

– Managing the changing requirements of a

software application

31

Practice 3: Use Component

Architectures

32

Best Practices

Process Made Practical Best Practices

Process Made Practical

Manage Requirements Use Component Architectures

Model Visually (UML) Continuously Verify Quality

Manage Change

Develop Iteratively Manage Requirements

Use Component Architectures

Model Visually (UML) Continuously Verify Quality

Manage Change

Use Component Architectures

• Software architecture needs to be:

Purpose of a Component-Based Architecture

• Basis for reuse

System- specific

Business- specific

Application-Component-based architecture with

layers

Practice 4: Model Visually (UML)

35

Best Practices

Process Made Practical Best Practices

Process Made Practical

Manage Requirements

Use Component Architectures Model Visually (UML) Continuously Verify Quality

Manage Change

Develop Iteratively Manage Requirements

Use Component Architectures

Model Visually (UML)

Continuously Verify Quality

Manage Change

Model Visually (UML)

• Captures structure and behavior

• Shows how system elements fit together

• Keeps design and implementation consistent

• Hides or exposes details as appropriate

• Promotes unambiguous communication

– The UML provides one language for all practitioners

36

Visual Modeling with the Unified Modeling Language

Static Diagrams

Sequence Diagrams

Communication Diagrams

State Machine Diagrams

Deployment Diagrams

Component Diagrams

Object Diagrams

Class Diagrams Use-Case

Diagrams

Activity Diagram – L ượp các thành phần c đ ho t đ ng ồ án môn học: tối đa 10đ, trọng số 50% ạI IS ột hệ thống là một tập hợp các thành phần

• Activity diagrams đ ượp các thành phần c dùng đ miêu t dòng công ểm chuyên cần, thảo luận trên lớp: trọng ả môn học

Process Payment

38

Use Case Diagram

Class Diagram

40

Personal Customer creditCard#

Customer name address creditRating()

creditRating creditLimit

remind() billForMonth()

0 1

0 n 0 1

0 n sales rep