Bài giảng Ứng dụng uml trong phân tích và thiết kế it44 Đại học mở hà nội

1. Công nghệ phần mềm ü Khái niệm: ¨ Công nghệ phần mềm là ngành khoa học nghiên cứu về việc xây dựng các phần mềm có chất lượng với chi phí hợp lý trong khoảng thời gian hợp lý. ü Đối tượng nghiên cứu ¨ Quy trình công nghệ ¨ Phương pháp xây dựng phần mềm ¨ Công cụ hỗ trợ phát triển phần mềm

Giảng viên chuyên môn: THS MAI THỊ THÚY HÀ

Tổng quan về phân tích thiết kế

Hướng đối tượng

Nội dung

◼ Phân tích thiết kế hướng đối tượng

1 Công nghệ phần mềm

◼ Khái niệm:

 Công nghệ phần mềm là ngành khoa học nghiên cứu về việc xây dựng các phần mềm có chất lượng với chi phí hợp

lý trong khoảng thời gian hợp lý.

◼ Đối tượng nghiên cứu

 Quy trình công nghệ

 Phương pháp xây dựng phần mềm

 Công cụ hỗ trợ phát triển phần mềm

Mục tiêu, kết quả nhận được từ giai đoạn trước đó

Kết quả chuyển giao cho giai đoạn tiếp theo.

 Phương pháp phát triển phần mềm

◼ là các hướng dẫn cho phép từng bước thực hiện một giai đoạn trong quy trình phát triển phần mềm

 Công cụ và môi trường phát triển phần mềm

◼ Các phần mềm được sử dụng trong quá trình phát triển phần mềm

 Quy trình xác định ai làm gì, khi nào và bằng

cách nào để đạt được một mục tiêu nào đó

 Quy trình phần mềm xác định một bộ khung và

tiêu chuẩn để triển khai công nghệ phần mềm.

 khi phát triển và xây dựng một phần mềm,

thường cần làm việc theo đội, nhóm.

◼ Một số câu hỏi thường đặt ra trong quy trình phát

triển phần mềm như

 Xây dựng phần mềm cần thực hiện theo trình tự

nào?

 Cần bao nhiêu người tham gia? Vai trò của từng

thành viên? Tổ chức quản lý các thành viên?

 Giao tiếp giữa các thành viên trong hệ thống?

3 Quy trình phát triển phần mềm

3 Quy trình phát triển phần mềm

◼ Làm thế nào để tiếp nhận chính xác các

yêu cầu của khách hàng?

◼ Làm thế nào để đặc tả đúng yêu cầu của

khách hàng?

◼ Làm thế nào để giao tiếp, tương tác với bộ

phần phát triển hệ thống?

◼ Làm thế nào để kiểm tra hệ thống phát

triển đúng theo yêu cầu trước khi thực

hiện triển khai đến khách hàng?

Bộ phận tiếp nhận yêu cầu của khách hàng

Business Analyst

3 Quy trình phát triển phần mềm

◼ Làm thế nào để thiết kế hệ thống

đúng với yêu cầu của người dùng?

◼ Làm thế nào để giao tiếp, tương tác

với các thành viên trong bộ phận phát

3 Quy trình phát triển phần mềm

3 Quy trình phát triển phần mềm

Mô hình thác nước – Waterfall Model

Mô hình thác nước – Waterfall Model

◼ Mô hình thác nước là phương pháp quản lý dự án dựa trên tiến trình, kế hoạch được tổ chức tuần tự và liên tiếp.

◼ Mô hình thác nước được tạo với mục đích quản lý vòng đời phát triển phần mềm.

◼ Các giai đoạn trong mô hình thác nước

 Xác định yêu cầu

 Phân tích, lên kế hoạch thực hiện hệ thống

 Thực hiện theo kế hoạch

 Kiểm thử sản phẩm

 Triển khai ứng dụng

 Bảo trì hệ thống

Mô hình Mẫu – Prototype Model

◼ Prototype là một mô hình phát triển phần mềm được phát triển dựa trên các yêu cầu hệ thống Dựa vào bản prototype mà khách hàng có cái nhìn tổng quan về hệ thống thực tế.

◼ Prototype là một ý tưởng hay cho các hệ thống phức tạp và lớn mà không

có quy trình thủ công để giúp xác định các yêu cầu.

◼ Prototype thường không phải là hệ thống hoàn chỉnh và nhiều chi tiết không được xây dựng trong bản prototype Mục tiêu là cung cấp một hệ thống với chức năng tổng thể.

◼ Mô hình prototype nên được sử dụng khi hệ thống cần có nhiều tương tác với người dùng cuối

◼ Thông thường, các hệ thống trực tuyến, giao diện web có lượng tương tác rất cao với người dùng cuối, phù hợp nhất với mô hình Prototype.

◼ Bản prototype phải đảm bảo rằng người dùng cuối liên tục tương tác với hệ thống và cung cấp phản hồi cần cải tiến về bản prototype đó để tạo ra một

Mô hình Mẫu – Prototype Model

Quy trình phát triển RUP (IBM Rational Unified Process)

◼ Tiến trình này yêu cầu việc phát triển ứng dụng một cách chặt chẽ

và nghiêm ngặt với việc đưa ra các mẫu được thực hiện nhanh

chóng qua các cuộc làm việc vớI khách hàng và nhóm dự án, việc

lập kế hoạch và đưa ra các chức năng hệ thống một cách tích cực

◼ Kết quả sẽ đưa ra một ứng dụng đáp ứng các yêu cầu của người sử

dụng và giúp cho quá trình lên kế hoạch và thực thi nhanh chóng.

◼ Tiến trình hợp nhất là:

 Là một quá trình phát triển phần mềm hướng đối tượng.

 Một tập hợp các hoạt động để chuyển yêu cầu người sử dụng thành một hệ thống phần mềm

 Một khung làm việc chung với nhiều người tham gia.

 Dựa trên các thành phần và kết nối thông qua giao diện

 Sử dụng công cụ UML.

Quy trình phát triển RUP (IBM Rational Unified Process)

Quy trình xoắn ốc - Spiral Model

◼ Là mô hình kết hợp giữa các tính năng của mô hình prototyping và mô hình thác nước.

◼ Mô hình xoắn ốc được ưa chuộng cho các dự án lớn, đắt tiền và phức tạp.

◼ Mô hình này sử dụng nhiều những giai đoạn tương tự như mô hình thác nước,

về thứ tự, plan, đánh giá rủi ro, …

◼ Thường được sử dụng cho các ứng dụng lớn và các hệ thống được xây dựng theo các giai đoạn nhỏ hoặc theo các phân đoạn

◼ Ưu điểm:

 Estimates (i.e budget, schedule, etc.) trở nên thực tế hơn như là một quy trình làm việc, bởi vì những vấn đề quan trọng đã được phát hiện sớm hơn.

 Có sự tham gia sớm của deverlopers

 Quản lý rủi ro và phát triển hệ thống theo phase

◼ Nhược điểm:

 Chi phí cao và thời gian dài để có sản phẩm cuối cùng

Phải có kỹ năng tốt để đánh giá rủi ro và giả định.

Quy trình xoắn ốc - Spiral Model

Agile Model

◼ Agile là một phương pháp phát triển phần mềm linh hoạt, là một

hướng tiếp cận cụ thể cho việc quản lý dự án phần mềm.

◼ Nó gồm một quá trình làm việc tương tác và tích hợp để có thể đưa sản phẩm đến tay người dùng càng nhanh càng tốt.

◼ Tuyên ngôn Agile

 Individuals and interactions over processes and tools: Cá

nhân và sự tương tác hơn là quy trình và công cụ

 Working software over comprehensive documentation: Phần

mềm chạy tốt hơn là tài liệu đầy đủ

 Customer collaboration over contract negotiation: Cộng tác

với khách hàng hơn là đàm phán hợp đồng

 Responding to change over following a plan: Phản hồi với sự

thay đổi hơn là bám theo kế hoạch

Agile Model

◼ Các phương pháp Agile Model

 Scrum: là một khung làm việc (framework) để phát triển bền vững các sản phẩm phứctạp Có thể nói Scrum là một trong những phương pháp Agile quan trọng nhất sửdụng cơ chế lặp (iterative) và tăng trưởng (Incremental) để tối ưu hóa hiệu quả cũngnhư kiểm soát rủi ro

 Kaban: là một phương pháp Agile dựa trên Phương thức Sản xuất Toyota với bốnnguyên lý: Trực quan hóa công việc, giới hạn công việc đang làm, tập trung vào luồnglàm việc, cải tiến liên tục Mô hình Kanban phù hợp cho việc hỗ trợ sản xuất trongquá trình làm việc

 Scrumban: kết hợp được những ưu điểm của Scrum và Kanban để cho phép nhóm liêntục cải tiến quy trình và khả năng xử lý công việc

 Lean Software Development (LSD):bao gồm: Loại bỏ lãng phí, Khuếch trương việchọc, Quyết định càng muộn càng tốt, Chuyển giao càng nhanh càng tốt, Trao quyềncho nhóm, Tạo ra tính toàn vẹn tự thân, Thấy toàn cảnh là linh hồn cho quá trình pháttriển phần mềm tinh gọn

 XP (Extreme Programming): chủ trương đưa ra các bản phát hành thường xuyênthông qua các chu trình phát triển ngắn như: Lập trình cặp (Pair programming), Táicấu trúc mã nguồn (Refactoring), Kiểm thử đơn vị (Unit Testing), Tích hợp liên tục

 Tính tăng trưởng (Incremental)

◼ Cuối mỗi phân đoạn (Sprint), nhóm phát triển thường cho ra các phần nhỏ củasản phẩm cuối cùng

◼ Các phần nhỏ này thường đáp ứng được các yêu cầu, có khả năng chạy tốt do đãđược kiểm thử cẩn thận và có thể sử dụng được ngay

◼ Theo thời gian, các phân đoạn sẽ tiếp nối nhau và tích lũy dần tới khi toàn bộyêu cầu của khách hàng được thỏa mãn

 Vòng phản hồi ngắn và thích ứng thường xuyên

◼ Do các phân đoạn chỉ kéo dài trong một khoảng thời gian ngắn, việc lập kếhoạch hay có những điều chỉnh, thay đổi trong quá trình phát triển đều có thểđáp ứng nhanh để phù hợp

Agile Model

◼ Đặc điểm của các phương pháp Agile Model

 Giao tiếp thường xuyên và hiệu quả

◼ Trong các nhóm Agile luôn đề cao việc giao tiếp thường xuyên và trực diện hơn

là việc trao đổi qua tài liệu, giấy tờ

◼ Các nhóm phát triển cũng thường chỉ ở quy mô nhỏ (đối với Scrum là từ 3-9 người), từ đó sẽ đơn giản hóa được quá trình giao tiếp và thúc đẩy hợp tác hiệu quả hơn

nguồn, v.v

 Phát triển dựa trên giá trị

◼ Theo cách tiếp cận của các phương pháp Agile, thời gian và chi phí sẽ là những phần cố định, khi đó các nhóm Agile luôn cộng tác trực tiếp và thường xuyên

4 Phân tích thiết kế chức năng

◼ Đến giữa năm 1990: Phần lớn các kỹ sư phần mềm sử dụng phương

pháp thiết kế chức năng Top-Down

4 Phân tích thiết kế chức năng

◼ Phương pháp này còn gọi là phương pháp cổ điển

◼ Được nhìn nhận dưới sự phức tạp của chức năng hệ thống máy tính

◼ Chức năng được phân rã theo một hệ thống cấu trúc nhất định

do người phân tích hệ thống đưa ra (cấu trúc phân nhánh, lặp )

◼ Bao gồm mô hình quá trình chức năng cũng như mô hình dữ liệu Sự liên kết giữa hai mô hình này con đơn giản qua các mối liên kết và luồng thông tin từ quá trình chức năng này sang chức năng khác.

4 Phân tích thiết kế chức năng

◼ Ưu điểm:

 Phân rã được chức năng, quá trình hoạt động phần mềm được thực hiện từng bước như thế nào, khá đơn giản và dễ hiểu.

◼ Nhược điểm:

 Việc dựa vào cấu trúc của quá trình chức năng dẫ đến khi chức năng hệ thống thay đổi, cấu trúc ấy có thể bị thay đổi rất nhiều, thậm chí phải thay đổi toàn bộ.

 Sự tách biệt giữa mô hình chức năng và mô hình dữ liệu dẫn đến những chức năng hoàn toàn giống nhau nhưng xử

lý những dữ liệu khác nhau phải được viết lại liên tục

 Thiếu linh động, phí phạm mã, khó mở rộng, khó thích nghi của phần mềm xây dựng dựa vào phương pháp này.

◼ Chiến lược phát triển phần mềm hướng đối tượng là quan sát thế giới như tập các đối tượng

◼ Các tính chất của đối tượng

 Đối tượng có thể là

◼ các thực thể nhìn thấy được trong thế giới thực (trong giai đoạn phân tích yêu cầu)

◼ biểu diễn các thực thể hệ thống (trong giai đoạn thiết kế)

 Các đối tượng được gom nhóm thành các lớp đối tượng – class

◼ Những đối tượng thuộc cùng một lớp đều có đặc tính (thuộc tính và hành vi) chung

5 Phân tích thiết kế hướng đối tượng

◼ Tiếp cận hướng đối tượng tập trung vào cả thông tin và hành

vi của đối tượng

◼ Cho khả năng xây dựng hệ thống mềm dẻo, linh hoạt

◼ Phương pháp này được xây dựng dựa trên các nguyên tắc sau

◼ Thành phần cơ bản của đối tượng gồm hai thành phần cơ bản: trạng thái (state) và hành vi (behavior)

◼ Trạng thái (State):

 Giúp phân biệt giữa đối tượng này với đối tượng khác

 Mô tả đặc điểm cơ bản của đối tượng

 Bao gồm những thuộc tính (attribute) và những giá trị của các thuộc tính đó

◼ Hành vi (behavior)

 Cho biết đối tượng có thể làm được những việc gì

 Bao gồm những phương thức (method) để chúng ta có thể điều khiển đối tượng đó.

5 Phân tích thiết kế hướng đối tượng

◼ Sự trừu tượng hoá

 Xem xét các vấn đề cụ thể thông qua quá trình tư duy trừu tượng để rút ra các khái niệm, nguyên tắc quy luật

 Là công cụ chủ yếu để con người nhận thức và mô hình hoá thế giới

 Trừu tượng hoá bao gồm hai quá trình chính: Khái quát hoá

và cụ thể hoá

5 Phân tích thiết kế hướng đối tượng

◼ Khái quát hoá (Generalization)

 Khái quát hoá là quá trình tập trung vào những đặc điểm cơ bản của các đối tượng, sự kiện công việc cụ thể, loại bỏ những đặc điểm riêng có tính vụn vặt không quan trọng để tạo một khái niệm mới mang đặc tính chung liên quan đến tất cả những cái cụ thể ấy

 Khái quát hoá là quá trình đồng hoá những đặc điểm chung

của các sự việc cụ thể mà con người quan sát được.

 Khái quát hoá có thể được phân thành nhiều cấp độ khác

nhau tuỳ vào mức độ khi thực hiện phép khái quát cũng như những đặc điểm chung cơ bản được rút ra từ các đối tượng cụ thể.

5 Phân tích thiết kế hướng đối tượng

◼ Cụ thể hoá (Refinement)

 Ngược lại với khái quát hoá là tính cụ thể hoá

 Quá trình cụ thể hoá là quá trình đi từ những khái niệm sự việc trừu trượng khái quát để mô tả chi tiết, cụ thể các đối tượng sự việc cụ thể hay các khái niệm sự việc trừu tượng

ở mức thấp hơn.

 Do cụ thể hoá là quá trình ngược của khái quát hoá, nó bao gồm nhiều mức độ khác nhau tuỳ theo mức độ mô tả cụ thể vấn đề khái quát cũng như hướng mô tả.

5 Phân tích thiết kế hướng đối tượng

 Những bước phân rã đó được gọi là phân rã kiến trúc Mỗi phần của phần mềm được phân rã và tích hợp khác nhau tuỳ theo phương pháp luận khác nhau.

5 Phân tích thiết kế hướng đối tượng

◼ Che dấu thông tin

 Từ hai phương pháp cơ bản là trừu tượng hoá và phân rã độ phức tạp dẫn đến câu hỏi: "Làm thế nào để xây dựng được phần mềm với mức độ phức tạp và trừu tượng khác nhau?"

 Nguyên tắc che dấu thông tin – thong tin của hai phần được che

dấu nếu thực sự không cần thiết – được đưa ra nhằm đảm bảo các phần khác nhau của bài toán có thể tồn tại độc lập và bỏ qua những chi tiết không cần thiết trong mối quan hệ giữa chúng với nhau.

 Che dấu thông tin vì vậy đảm bảo được sự độc lập của từng phần của bài toán, chia bài toán thành từng phần trừu tượng khác nhau và giải quyết bài toán trên từng mức trừu tượng đó.

5 Phân tích thiết kế hướng đối tượng

◼ Chia sẻ và tái sử dụng

 Tính độc lập của từng bài toán có thể giúp cho bài toán được

sử dụng lại trong nhiều hệ thống khác nhau mà không cần thiết phải giải lại.

 Tính kế thừa (inheritance)

◼ Kế thừa cho phép định nghĩa một lớp mới tương tự những lớp đã có, ngoài ra bổ sung thêm những thuộc tính và các phương pháp mô tả chi tiết hơn về một nhóm các đối tượng cụ thể

◼ Những lớp kế thừa gọi là lớp con (subclass) hoặc lớp dẫn xuất (derived)

◼ Những lớp được kế thừa còn gọi là lớp cha (supperclass)

5 Phân tích thiết kế hướng đối tượng

anhtt@ehou.edu.vn

Chúc Anh/chị học tập tốt

Yêu cầu của mô hình hoá

◼ Không một mô hình đơn nào là đầy đủ, cần thiết phải có các khung nhìn khác nhau

 Cách tốt nhất để tiếp cận mỗi hệ thống phức tạp là đi từ tập

◼ 1994- các phương thức đã gần như hoàn chỉnh và tương tự nhau

 Cùng khái niệm (concepts): objects, classes, relationships, attributes, etc.

 Cùng khái niệm nhưng lại dùng kí hiệu (notation) khác nhau Mỗi phương thức đều có các mặt mạnh và yếu

◼ 1994 – James Rumbaugh liên kết với Grady Booch thành lập Rational Software Corporation

◼ Vào thời gian đầu, là sự hợp nhất của 2 phương pháp

 Booch và OMT (Object Modelling Technique)

◼ Phương pháp này được gọi là Unified Method

◼ 1995 – Rational thông báo kết hợp với Jacobson tích hợp phương pháp này với OOSE.

◼ Những tài liệu đầu tiên về UML được ra đời vào năm 1996

◼ Phiên bản 1.0 của UML được công bố vào năm 1997

◼ Phiên bản 1.5 được tạo ra vào tháng 3 năm 2003

◼ Phiên bản 2.0 được tạo ra vào năm 2004

Lịch sử phát triển

UML và các khái niệm

◼ UML là một ngôn ngữ mô hình sử dụng các kí hiệu cho việc viết tài liệu, phân tích, thiết kế và thực hiện tiến trình phát triển

hệ thống hướng đối tương

Đặc điểm của UML

◼ UML – Ngôn ngữ mô hình hướng đối tượng

 UML được tạo ra phục vụ cho việc mô hình hoá hướng đối tượng

 Hướng đối tượng sản sinh ra các mô hình thể hiện một lĩnh vực

◼ Một lĩnh vực kinh doanh, ví dụ: banking

◼ Các thuật ngữ và đối tượng của lĩnh vực (ví dụ: tiền, séc)

 UML có thể được sử dụng để mô hình nhiều kiểu hệ thống khác nhau

◼ UML – Ngôn ngữ mô hình hoá trực quan

 Ngôn ngữ mô hình hoá trực quan là một phát minh lớn của những năm 1990s trong việc thiết kế phần mềm

 Thể hiện trực quan là cách tốt nhất để giao tiếp và quản lý độ phức tạp

 Làm cho mô hình hoá ngày càng gần hơn so với việc cài đặt

Mục tiêu của UML

◼ Cung cấp một ngôn ngữ mô hình hoá trực quan có sẵn và gợi

tả, từ đó có thể phát triển và thay đổi các mô hình một cách hiệu quả

◼ Cung cấp các kĩ thuật chuyên môn để mở rộng các khái niệm cốt lõi

◼ Độc lập với các ngôn ngữ lập trình riêng biệt và các tiến trình phát triển

◼ Cung cấp kiến thức cơ bản để hiểu ngôn ngữ mô hình hoá

◼ Ủng hộ/ khuyến khích sự phát triển của môi trường sử dụng công cụ hướng đối tượng

◼ Hỗ trợ các khái niệm cho sự phát triển ở mức độ cao như là sự cộng tác (collaborations), khung (frameworks), mẫu (patterns), thành phần (components)