chi_co_minh_em_13
New Member
LINK TẢI LUẬN VĂN MIỄN PHÍ CHO AE KET-NOI
Table of Contents
1. Giới thiệu : 3
2. Giới thiệu sơ lược về UML 4
3. USECASE View 8
3.1. USE CASE là gì ? 8
3.2. Sự cần thiết phải có Use Case 9
3.3. Hướng nhìn Use case (Use case View): 10
3.4. Mô hình hóa Use Case 12
4. Process view 28
4.1.Biểu đồ trạng thái(state diagram): 28
4.2. Biểu đồ tuần tự(squence diagram): 32
4.3. Biểu đồ cộng tác (Collaboration diagram): 35
4.4. Biểu đồ hoạt động (Activity diagram): 36
4.5. Lược đồ thành phần (Component diagram): 39
4.6. Lược đồ triển khai (deployment diagram): 40
5. Logical view 42
5.1. Class diagram 43
5.2. Object diagrams 44
5.3. Package diagrams 45
5.4. Composite Structure Diagrams 45
5.5. State machine diagrams 46
5.6. Mô hình hóa với góc nhìn Logic 47
6. Mối liên hệ giữa các View 49
7. Kết luận 50
1. Giới thiệu :
Ngày nay việc mô tả kiến trúc phần mềm là rất quan trọng. Qua Kinh nghiệm của nhiều nhà thiết kế và phát triển cho thấy phát triển phần mềm là một bài toán phức tạp
- Những người phát triển phần mềm rất khó hiểu cho đúng những gì người dùng cần
- Yêu cầu thường được miêu tả bằng văn bản, dài dòng, khó hiểu, nhiều khi thậm chí mâu thuẫn
- Chọn lựa phần cứng và phần mềm thích hợp cho giải pháp là một trong những thách thức lớn đối với Designer
Chu Trình Phát Triển Phần Mềm là một chuỗi các hoạt động của nhà phân tích (Analyst), nhà thiết kế (Designer), người phát triển (Developer) và người dùng (User) để phát triển và thực hiện một hệ thống thông tin. Những hoạt động này được thực hiện trong nhiều giai đọan khác nhau.
Chính vì sự trợ giúp của chuyên gia lĩnh vực có thể đóng vai trò rất quan trọng nên trong những giai đoạn đầu của quá trình phát triển phần mềm, kết quả phân tích nên được thể hiện sao cho dễ hiểu đối với các chuyên gia lĩnh vực. Đây cũng là môt trong rất nhiều lý do khiến cho phương pháp hướng đối tượng được nhiều người hưởng ứng
Mục tiêu của giai đoạn phân tích hệ thống là sản xuất ra một mô hình tổng thể của hệ thống cần xây dựng. Mô hình này cần được trình bày theo hướng nhìn (View) của khách hàng hay người sử dụng và làm sao để họ hiểu được. Mô hình này cũng có thể được sử dụng để xác định các yêu cầu của người dùng đối với hệ thống và qua đó giúp chúng ta đánh giá tính khả thi của dự án.
Nhà thiết kế cần tạo ra các mô hình mô tả tất cả các khía cạnh khác nhau của sản phẩm. Ngoài ra, một mô hình có thể được chia thành nhiều hướng nhìn, mỗi hướng nhìn trong số chúng sẽ mô tả một khía cạnh riêng biệt của sản phẩm hay hệ thống cần được xây dựng. Một mô hình cũng có thể được xây dựng trong nhiều giai đoạn và ở mỗi giai đoạn, mô hình sẽ được bổ sung thêm một số chi tiết nhất định.
Người ta nhận thấy cần thiết phải cung cấp một phương pháp tiệm cận được chuẩn hoá và thống nhất cho việc mô hình hoá hướng đối tượng. Yêu cầu cụ thể là đưa ra một tập hợp chuẩn hoá các ký hiệu (Notation) và các biểu đồ (Diagram) để nắm bắt các quyết định về mặt thiết kế một cách rõ ràng, rành mạch. Đã có ba công trình tiên phong nhắm tới mục tiêu đó, chúng được thực hiện dưới sự lãnh đạo của James Rumbaugh, Grady Booch và Ivar Jacobson. Chính những cố gắng này dẫn đến kết quả là xây dựng được một Ngôn Ngữ Mô Hình Hoá Thống Nhất (Unifield Modeling Language – UML).
2. Giới thiệu sơ lược về UML
UML = Unified Modeling Language : Ngôn ngữ mô hình hóa thống nhất đã được dùng kể từ năm 1997 và UML 2 được phát hành năm 2004, xây dựng dựa trên nền tiêu chuẩn của UML 1.
Philippe Kruchten là người đầu tiên đưa ra mô hình 4+1 View để diễn tả kiến trúc phần mềm – các hệ thống chuyên sâu. Và mô hình 4+1 đã được sử dụng rộng rãi trong các ngành công nghiệp phần mềm để miêu tả các bản thiết kể ứng dụng. Tuy nhiên ngành công nghiệp đã không nắm bắt được đầy đủ UML 2.
Bây giờ ta sẽ tìm hiểu sự tiến gần đến kiến trúc 4+1 View sử dụng các biểu đồ UML 2. Nó sẽ tăng cường các khái niệm ban đầu của việc sử dụng các tiểu chuẩn và công nghệ mô hình hiện tại. Bài này sẽ thảo luận về từng View và định rõ vị trí của các biểu đồ trong UML 2.
Các biểu đồ UML 2
Giới thiệu tóm tắt về các biểu đồ được sử dụng trong UML 2 Specification.
UML 2 Superstructure Specification chia 13 kiểu biểu đồ cơ bản thành 2 loại sau :
Loại 1 : Các biểu đồ cấu trúc : Chúng được sử dụng để xác định đác điểm kiến trúc tĩnh. Chúng gồm có các cấu trúc như là các lớp, các đối tượng và các thành phần và mối liên hệ giữa các yếu tố. Có 6 biểu đồ cấu trúc : Package, Class, Object, Composite Strucure, Component và Deployment Diagrams.
Loại 2 : Behavioral Diagrams : Các biểu đồ này được sử dụng để xác định đặc điểm kiến trúc động. Chúng bao gồm các cấu trúc hành vi như là các hoạt động, các trạng thái, các timeline và các thư thoại chạy giữa các đối tượng khác nhau. Chúng được sử dụng để mô tả mối tương tác giữa các yếu tố mô hình khác nhau và các trạng thái tức thời qua một thời kỳ. Có tất cả là 7 loại Behavioral Diagrams : Use Case, Activity, State Machine, Communication, Sequence, Timing và Interaction Overview Diagrams.
Table of Contents
1. Giới thiệu : 3
2. Giới thiệu sơ lược về UML 4
3. USECASE View 8
3.1. USE CASE là gì ? 8
3.2. Sự cần thiết phải có Use Case 9
3.3. Hướng nhìn Use case (Use case View): 10
3.4. Mô hình hóa Use Case 12
4. Process view 28
4.1.Biểu đồ trạng thái(state diagram): 28
4.2. Biểu đồ tuần tự(squence diagram): 32
4.3. Biểu đồ cộng tác (Collaboration diagram): 35
4.4. Biểu đồ hoạt động (Activity diagram): 36
4.5. Lược đồ thành phần (Component diagram): 39
4.6. Lược đồ triển khai (deployment diagram): 40
5. Logical view 42
5.1. Class diagram 43
5.2. Object diagrams 44
5.3. Package diagrams 45
5.4. Composite Structure Diagrams 45
5.5. State machine diagrams 46
5.6. Mô hình hóa với góc nhìn Logic 47
6. Mối liên hệ giữa các View 49
7. Kết luận 50
Do Drive thay đổi chính sách, nên một số link cũ yêu cầu duyệt download.
Password giải nén nếu cần: ket-noi.com | Bấm vào Link, đợi vài giây sau đó bấm Get Website để tải:
Table of Contents
1. Giới thiệu : 3
2. Giới thiệu sơ lược về UML 4
3. USECASE View 8
3.1. USE CASE là gì ? 8
3.2. Sự cần thiết phải có Use Case 9
3.3. Hướng nhìn Use case (Use case View): 10
3.4. Mô hình hóa Use Case 12
4. Process view 28
4.1.Biểu đồ trạng thái(state diagram): 28
4.2. Biểu đồ tuần tự(squence diagram): 32
4.3. Biểu đồ cộng tác (Collaboration diagram): 35
4.4. Biểu đồ hoạt động (Activity diagram): 36
4.5. Lược đồ thành phần (Component diagram): 39
4.6. Lược đồ triển khai (deployment diagram): 40
5. Logical view 42
5.1. Class diagram 43
5.2. Object diagrams 44
5.3. Package diagrams 45
5.4. Composite Structure Diagrams 45
5.5. State machine diagrams 46
5.6. Mô hình hóa với góc nhìn Logic 47
6. Mối liên hệ giữa các View 49
7. Kết luận 50
1. Giới thiệu :
Ngày nay việc mô tả kiến trúc phần mềm là rất quan trọng. Qua Kinh nghiệm của nhiều nhà thiết kế và phát triển cho thấy phát triển phần mềm là một bài toán phức tạp
- Những người phát triển phần mềm rất khó hiểu cho đúng những gì người dùng cần
- Yêu cầu thường được miêu tả bằng văn bản, dài dòng, khó hiểu, nhiều khi thậm chí mâu thuẫn
- Chọn lựa phần cứng và phần mềm thích hợp cho giải pháp là một trong những thách thức lớn đối với Designer
Chu Trình Phát Triển Phần Mềm là một chuỗi các hoạt động của nhà phân tích (Analyst), nhà thiết kế (Designer), người phát triển (Developer) và người dùng (User) để phát triển và thực hiện một hệ thống thông tin. Những hoạt động này được thực hiện trong nhiều giai đọan khác nhau.
Chính vì sự trợ giúp của chuyên gia lĩnh vực có thể đóng vai trò rất quan trọng nên trong những giai đoạn đầu của quá trình phát triển phần mềm, kết quả phân tích nên được thể hiện sao cho dễ hiểu đối với các chuyên gia lĩnh vực. Đây cũng là môt trong rất nhiều lý do khiến cho phương pháp hướng đối tượng được nhiều người hưởng ứng
Mục tiêu của giai đoạn phân tích hệ thống là sản xuất ra một mô hình tổng thể của hệ thống cần xây dựng. Mô hình này cần được trình bày theo hướng nhìn (View) của khách hàng hay người sử dụng và làm sao để họ hiểu được. Mô hình này cũng có thể được sử dụng để xác định các yêu cầu của người dùng đối với hệ thống và qua đó giúp chúng ta đánh giá tính khả thi của dự án.
Nhà thiết kế cần tạo ra các mô hình mô tả tất cả các khía cạnh khác nhau của sản phẩm. Ngoài ra, một mô hình có thể được chia thành nhiều hướng nhìn, mỗi hướng nhìn trong số chúng sẽ mô tả một khía cạnh riêng biệt của sản phẩm hay hệ thống cần được xây dựng. Một mô hình cũng có thể được xây dựng trong nhiều giai đoạn và ở mỗi giai đoạn, mô hình sẽ được bổ sung thêm một số chi tiết nhất định.
Người ta nhận thấy cần thiết phải cung cấp một phương pháp tiệm cận được chuẩn hoá và thống nhất cho việc mô hình hoá hướng đối tượng. Yêu cầu cụ thể là đưa ra một tập hợp chuẩn hoá các ký hiệu (Notation) và các biểu đồ (Diagram) để nắm bắt các quyết định về mặt thiết kế một cách rõ ràng, rành mạch. Đã có ba công trình tiên phong nhắm tới mục tiêu đó, chúng được thực hiện dưới sự lãnh đạo của James Rumbaugh, Grady Booch và Ivar Jacobson. Chính những cố gắng này dẫn đến kết quả là xây dựng được một Ngôn Ngữ Mô Hình Hoá Thống Nhất (Unifield Modeling Language – UML).
2. Giới thiệu sơ lược về UML
UML = Unified Modeling Language : Ngôn ngữ mô hình hóa thống nhất đã được dùng kể từ năm 1997 và UML 2 được phát hành năm 2004, xây dựng dựa trên nền tiêu chuẩn của UML 1.
Philippe Kruchten là người đầu tiên đưa ra mô hình 4+1 View để diễn tả kiến trúc phần mềm – các hệ thống chuyên sâu. Và mô hình 4+1 đã được sử dụng rộng rãi trong các ngành công nghiệp phần mềm để miêu tả các bản thiết kể ứng dụng. Tuy nhiên ngành công nghiệp đã không nắm bắt được đầy đủ UML 2.
Bây giờ ta sẽ tìm hiểu sự tiến gần đến kiến trúc 4+1 View sử dụng các biểu đồ UML 2. Nó sẽ tăng cường các khái niệm ban đầu của việc sử dụng các tiểu chuẩn và công nghệ mô hình hiện tại. Bài này sẽ thảo luận về từng View và định rõ vị trí của các biểu đồ trong UML 2.
Các biểu đồ UML 2
Giới thiệu tóm tắt về các biểu đồ được sử dụng trong UML 2 Specification.
UML 2 Superstructure Specification chia 13 kiểu biểu đồ cơ bản thành 2 loại sau :
Loại 1 : Các biểu đồ cấu trúc : Chúng được sử dụng để xác định đác điểm kiến trúc tĩnh. Chúng gồm có các cấu trúc như là các lớp, các đối tượng và các thành phần và mối liên hệ giữa các yếu tố. Có 6 biểu đồ cấu trúc : Package, Class, Object, Composite Strucure, Component và Deployment Diagrams.
Loại 2 : Behavioral Diagrams : Các biểu đồ này được sử dụng để xác định đặc điểm kiến trúc động. Chúng bao gồm các cấu trúc hành vi như là các hoạt động, các trạng thái, các timeline và các thư thoại chạy giữa các đối tượng khác nhau. Chúng được sử dụng để mô tả mối tương tác giữa các yếu tố mô hình khác nhau và các trạng thái tức thời qua một thời kỳ. Có tất cả là 7 loại Behavioral Diagrams : Use Case, Activity, State Machine, Communication, Sequence, Timing và Interaction Overview Diagrams.
Table of Contents
1. Giới thiệu : 3
2. Giới thiệu sơ lược về UML 4
3. USECASE View 8
3.1. USE CASE là gì ? 8
3.2. Sự cần thiết phải có Use Case 9
3.3. Hướng nhìn Use case (Use case View): 10
3.4. Mô hình hóa Use Case 12
4. Process view 28
4.1.Biểu đồ trạng thái(state diagram): 28
4.2. Biểu đồ tuần tự(squence diagram): 32
4.3. Biểu đồ cộng tác (Collaboration diagram): 35
4.4. Biểu đồ hoạt động (Activity diagram): 36
4.5. Lược đồ thành phần (Component diagram): 39
4.6. Lược đồ triển khai (deployment diagram): 40
5. Logical view 42
5.1. Class diagram 43
5.2. Object diagrams 44
5.3. Package diagrams 45
5.4. Composite Structure Diagrams 45
5.5. State machine diagrams 46
5.6. Mô hình hóa với góc nhìn Logic 47
6. Mối liên hệ giữa các View 49
7. Kết luận 50
Do Drive thay đổi chính sách, nên một số link cũ yêu cầu duyệt download.
Password giải nén nếu cần: ket-noi.com | Bấm vào Link, đợi vài giây sau đó bấm Get Website để tải:
You must be registered for see links
Last edited by a moderator: