đồ án tìm hiểu ứng dụng 1 công cụ giúp phân tích thiết kế tự động

Trong bối cảnh của ngày nay, nhanh chóng phân phối sản phẩm có thể được thử thách nhiệm vụ cho các nhà cung cấp phần mềm, CASE Tool như làcánh tay giúp việc để hỗ trợ tổ chức quản lý quá

Trường Đại học Công Nghiệp Hà Nội

Khoa Công nghệ thông tin

-o0o -Bài tập lớn môn Công nghệ phần mềm

Đề tài Tìm hiểu ứng dụng 1 công cụ trợ giúp

phân tích thiết kể tự động

Thành viên trong nhóm:

1 Nguyễn Ngọc Quý

2 Lê Đình Ngọc

3 Bùi Văn Toàn

Giáo viên hướng dẫn: Th.s Phùng Đức Hòa

Hà Nội ngày 22/12/2012

Lời nói đầu

Ngày nay, Công nghệ thông tin đã có những bước phát triển mạnh mẽ theo

cả chiều rộng và chiều sâu Máy tính điện tử không còn là một thứ phương tiện quỹhiếm mà đang ngày càng trở thành một công cụ làm việc và giải trí thông dụng củacon người, không chỉ ở công sở mà còn ngay cả trong gia đình

Đứng trước vai trò của thông tin hoạt động cạnh tranh gay gắt, các tổ chức

và các doanh nghiệp đều tìm mọi biện pháp để xây dựng hoàn thiện hệ thống thôngtin của mình nhằm tin học hóa các hoạt động tác nghiệp của đơn vị

Tự động hóa ngày càng có vai trò quan trọng trong nền kinh tế toàn cầu vàtrong kinh nghiệm hàng ngày Các kỹ sư đang cố gắng làm cho các thiết bị tự độnghoá kết hợp với các công cụ toán học và tổ chức để tạo ra các hệ thống phức tạpcho một phạm vi đang nhanh chóng phát triển rộng lớn của các ứng dụng và hoạtđộng của con người Hiện nay các công ty tin học hàng đầu thế giới không ngừngđầu tư và cải thiện các giải pháp cũng như các sản phẩm nhằm cho phép tiến hànhthương mại hóa trên Internet Thông qua các sản phẩm và công nghệ này, chúng

ta dễ dàng nhận ra tầm quan trọng và tính tất yếu của thương mại điện tử Vớinhững thao tác đơn giản trên máy có nối mạng Internet bạn sẽ có tận tay những gìmình cần mà không phải mất nhiều thời gian Bạn chỉ cần vào các trang dịch vụthương mại điện tử, làm theo hướng dẫn và click vào những gì bạn cần Các nhàdịch vụ sẽ mang đến tận nhà cho bạn

Ở Việt Nam cũng có rất nhiều doanh nghiệp đang tiến hành thương mại hóa trênInternet, tự động hóa các lĩnh vực nhưng do những khó khăn về cơ sở hạ tầng nênvẫn chưa được phổ biến rộng khắp

Để tiếp cận và góp phần trong quá trình tự động hóa các sản phẩm, chúng em

đã tìm hiểu và đưa ra được những đánh giá cho quá trình phân tích thiết kế tự độngkhi nghiên cứu tới phần mềm hỗ trợ phân tích thiết kế tự động Rational Rose

Với sự hướng dân tận tình của thầy Phùng Đức Hòa chúng em đã hoàn thành bàitập lớn này Tuy đã cố gắng hết sức để tìm hiểu, phân tích, cài đặt và sử dụngnhưng chắc rằng cũng không thể tránh khỏi những thiếu sót Chúng em rất mongnhận được sự thông cảm và góp ý của Thầy Chúng em xin chân thành cảm ơn

Nhóm sinh viên thực hiện:

Nguyễn Ngọc Quý Bùi Văn Toàn

Lê Đình Ngọc

Tóm tắt nội dung bài tập lớn.

Bài tập lớn tập chung vào việc phân tích quá trình trợ giúp tự động và đưa ra lựa chọn phân tịc là phần mềm Rational Rose

Bài tập lớn được chia thành 5 phần như sau:

Chương 1: Quy trình tự động hóa.

Chương này đưa ra các khái niệm cơ bản về quy trình, tự động hóa, và quy trình tự động hóa

Chương 2: CASE- Thiết kế phần mềm với sự trợ giúp của máy tính.

Giới thiệu về CASE (Computer Aided Software Engineering) Lịch sự pháttriển Tiếp đó đưa ra các Case Tool phổ biến hiện nay Trong đó có Rational Rose

Chương 3: Giới thiệu về UML- Ngôn ngữ mô hình hóa thống nhất.

Giới thiệu về UML (Unified Modeling Language) Lịch sử phát triển của UML Vai trò của UML trong phân tích thiết kế hệ thống

Các thành phần của ngôn ngữ UML, giới thiệu về các khung nhìn, các biểu đồ

có trong UML

Chương 4: Công cụ Rational Rose.

Giới thiệu về Rational Rose, các phiên bản của Rational Rose, cách cài đặt và

sử dụng Rational Rose cuối cùng là làm việc với Rational Rose như thế nào

Chương 5: Hỗ trợ phân tích thiết kế tự động từ Rational Rose.

Sau khi làm xong Chương 4, chúng ta sẽ biết cách sử dụng Rational Rose nhưthế nào thì trong Chương 5 chúng ta sẽ tìm hiểu về Rational Rose giúp gì trong quátrình phân tích thiết kế tự động Từ đó tìm được con người cần làm gì và hệ thốnggiúp đỡ gì trong quá trình phân tích

Mục lục

Chương 1: Quy trình tự động hóa 7

1 Quy trình là gì? 7

2 Tự động hóa là gì? 8

3 Quy trình tự động hóa là gì? 9

Chương 2: CASE- Thiết kế phần mềm với sự trợ giúp của máy tính 9

1 GIỚI THIỆU 9

1.1 SỰ RA ĐỜI VÀ PHÁT TRIỂN 10

1.1.1 Lịch sử 10

1.1.2 Sự cần thiết của CASE 10

1.1.3 Vị trí của CASE Tool trong những năm 90 11

1.1.4 Tại sao CASE Tool chưa phổ biến 12

1.2 MỤC TIÊU 13

1.3 Đôi nét về CASE Tool 14

1.3.1 Vai trò của các CASE Tool 14

1.3.2 Ưu điểm của CASE Tool 15

1.3.3 Các loại CASE Tool 16

1.3.4 Phân loại CASE Tool 17

1.3.5 Kỹ thuật đảo ngược và chuyển tiếp 18

1.4 CASE TOOL TRỰC QUAN VÀ RÕ NÉT 19

1.4.1 Phát triển hệ thống truyền thống và phát triển các hệ thống dựa trên Case 19

1.4.2 Môi trường CASE 20

1.4.3 CASE Tool nổi 22

1.4.4 CASE Tool hướng đối tượng 22

1.4.5 Tạo tài liệu và báo cáo bằng cách sử dụng các CASE Tool hướng đối

tượng 24

Chương 3: Giới thiệu về UML 26

I UML- Ngôn ngữ mô hình hóa thống nhất 26

1 LỊCH SỬ UML 26

2 UML LÀ GÌ? 26

3 UML TRONG PHÂN TÍCH THIẾT KẾ HỆ THỐNG 27

4 UML VÀ CÁC GIAI ĐOẠN PHÁT TRIỂN HỆ THỐNG 28

II Khái quát về UML 29

1 UML VÀ CÁC GIAI ĐOẠN CỦA CHU TRÌNH PHÁT TRIỂN PHẦN MỀM 29

1.1 Giai đoạn nghiên cứu sơ bộ: 29

1.2 Giai đoạn phân tích: 29

1.3 Giai đoạn thiết kế: 29

1.4 Giai đoạn xây dựng: 30

1.5 Thử nghiệm: 30

2 CÁC THÀNH PHẦN CỦA NGÔN NGỮ UML 30

3 KHUNG NHÌN (VIEW) 31

4.BIỂU ĐỒ (DIAGRAM) 34

4.1- Biểu đồ Use case (Use Case Diagram): 34

4.2- Biểu đồ đối tượng (Object Diagram) 34

4.3 Biểu đồ lớp (Class Diagram) 34

4.4 Biểu đồ trạng thái (State Diagram) 35

4.5 Biểu đồ trình tự (Sequence Diagram) 35

4.6 Biểu đồ cộng tác (Collaboration Diagram) 35

4.7 Biểu đồ hoạt động (Activity) 36

4.8 Biểu đồ thành phần (Component Diagram) 36

4.9 Biểu đồ triển khai (Deplopment Diagram) 37

Chương 4: Công cụ Rational Rose (Rose) 38

I Giới thiệu về Rational Rose 38

1 Rational Rose là gì? 38

2 Những phiên bản hiện hành của Rational Rose 39

II Cài đặt Rational Rose 40

III Làm việc với Rational Rose 54

1 Màn hình làm việc của ROSE 54

1.1 Browser 56

1.2 Toolbars 57

1.3 Cửa sổ tài liệu 58

1.4 Cửa sổ Log 59

2 Các hướng nhìn trong Rose 59

2.1 Hướng nhìn Use case (use case view): 60

2.2 Hướng nhìn logic (Logical View): 61

2.3 Hướng nhìn thành phần (Component View): 61

2.4 Hướng nhìn triển khai (Deployment View): 61

3 Làm việc với các mô hình trong Rose 61

3.1 Tạo mô hình 61

3.2 Lưu Mô hình 63

3.3 Nhập và xuất mô hình 64

3.4 Biểu đồ trong Rational Rose (Diagrams) 65

Chương 5 : Hỗ trợ Phân tích thiết kế tự động trong Rational Rose 100

I Rational Rose hỗ trợ Mô hình hóa hệ thống 100

1 Có năm mục đích chính của mô hình hoá 100

1.1 Mô hình giúp ta hiểu và thực hiện được sự trừu tượng, tổng quát hoá các khái niệm cơ sở để giảm thiểu độ phức tạp của hệ thống 100

1.2 Mô hình giúp chúng ta quan sát được hệ thống như nó vốn có trong

thực tế hoặc nó phải có như ta mong muốn 100

1.3 Mô hình cho phép ta đặc tả được cấu trúc và hành vi của hệ thống để hoàn chỉnh: 100

1 4 Mô hình hoá là nhằm tạo ra khuôn mẫu (template) và hướng dẫn cách xây dựng hệ thống; cho phép thử nghiệm, mô phỏng và thực hiện theo mô hình 101

1.5 Mô hình là cơ sở để trao đổi, ghi lại những quyết định đã thực hiện trong nhóm tham gia dự án phát triển phần mềm 101

2 Các yếu tố quan trọng mà người phân tích cần phải làm rõ 101

3 Hỗ trợ biến đổi các biểu đồ trong Rational Rose 101

II Rational Rose hỗ trợ xuất bản một mô hình lên web 103

III Tạo cơ sở dữ liệu trong Rational Rose 105

1 Các bước chính để tạo ra 1 mô hình cơ sở dữ liệu 105

a Tạo 1 database 105

b Thêm tablespace 107

c Thêm vào 1 Schema 110

2 Làm việc với View 112

a Tạo view và làm việc với view 112

III Rational Rose hỗ trợ tạo Code sau khi có các mô hình chuẩn 115

1 Kiểm tra các mô hình 115

2 Cài đặt các thuộc tính cho bảng mã 117

3 Xuất code 118

DANH MỤC CÁC HÌNH VẼ

Hình 2.1: Các thành phần của một CASE Tool điển hình

Hình 2.2: Kỹ thuật đảo ngược và chuyển tiếp

Hình 2.3: Môi trường CASE

Hình 2.4: Công cụ vẽ và thiết kế văn bản

Hình 2.5: Đầu ra chủ yếu của CASE Tool hướng đối tượng

Hình 2.6: Quy trình để tạo ra một tài liệu mô hình

Hình 3.1: Các khung nhìn trong UML

Hình 4.3.1: Giao diện của Rose

Hình 4.3.9 Xuất bản 1 mô hình Rose lên Web

Hình 4.3.10: Biểu đồ use case mức tổng quát trong bài toán quản lý hồ sơ bệnh ánHình 4.3.11: Phân rã use case quản lý bệnh án

Bảng 4.1: Biểu diễn scenario cho use case thêm bệnh án trong bài toán quản lý hồ

sơ bệnh án

Hình 4.3.12: Giao diện biểu đồ Use case trong Rational Rose

Hình 4.3.13: Cửa sổ đặc tả 1 Use case

Hình 4.3.14: Cửa sổ đặc tả một quan hệ dạng Dependency

Hình 4.3.15.a: Đặc tả quan hệ association– Tab General

Hình 4.3.15.b: Đặc tả quan hệ association– Tab Role A General

Hình 4.3.16: Phân rã use case

Hình 4.3.17: Một sơ đồ use case mức 2

Hình 4.3.18: Gắn file vào một use case

Hình 4.3.19: Biểu đồ đối tượng (Object Diagram)

Hình 4.3.20: Thêm thuộc tính và đối tượng vào Class

Hình 4.3.21: Biểu đồ Class trong quản lý hồ sơ bệnh án

Hình 4.3.22: Thêm yêu cầu ở biểu đồ trình tự trong quản lý hồ sơ bệnh án.Hình 4.3.23: Biểu đồ trình tự trong quản lý hồ sơ bệnh án

Hình 4.3.24: Biểu đồ trình tự trong quản lý hồ sơ bệnh án

Hình 4.3.25: Biểu đồ cộng tác trong Quản lý bệnh nhân

Hình 4.3.26: Biểu đồ hoạt động trong Quản lý hồ sơ bệnh án

Hình 4.3.27: Biểu đồ thành phần trong Quản lý hồ sơ bệnh án

Hình 4.3.28 : Biểu đồ triển khai trong Quản lý hồ sơ bệnh án

Hình 5.1: Xuất một mô hình Rational Rose lên web

Hình 5.2: Kết quả sau khi xuất một mô hình Rose lên web

Hình 5.3: Khởi tạo database

Hình 5.4: Rational Rose cùng các hỗ trợ Database

Hình 5.5: Thêm tablespace

Hình 5.6: Sử dụng hộp thoại Tablespace Specification

Hình 5.7: Làm việc với Schema

Hình 5.8: Thêm columns và cài đặt các thuộc tính kèm theo

Hình 5.9: Tạo liên kết giữa các bảng CSDL

Hình 5.10: Tạo View và sử dụng hộp thoại View Specification

Hình 5.11: Xuất code SQL

Chương 1: Quy trình tự động hóa.

1 Quy trình là gì?

Quy trình là một trình tự có tổ chức các hoạt động để hoàn thành cái gì đó.Chẳng hạn: Dự án phần mềm Trong trường hợp này, dự án là việc áp dụng tàinguyên vào quy trình đó Tài nguyên là con người, công cụ và kĩ thuật mà bạn ápdụng khi tuân theo quy trình Thuật ngữ “con người” cũng chỉ ra kĩ năng và kinhnghiệm của thành viên tổ Trình tự là trật tự theo đó mọi sự được hoàn thành.Thuật ngữ “trật tự” nghĩa là bạn phải tuân theo nó "từng bước một" tương ứng theoquy tắc Chẳng hạn, bạn phải hiểu yêu cầu trước khi bắt đầu thiết kế; chỉ khi thiết

kế được hoàn thành thì bạn mới có thể bắt đầu viết mã v.v

Quy trình được đại diện bởi ba yếu tố: Hiệu quả: Mối quan hệ giữa việc dùng tàinguyên và kết quả được hoàn thành Thời gian chu kì: "Tốc độ" của quy trình, tức

là, thời gian cần để hoàn thành một quy trình Và Chất lượng: Chất lượng của quytrình như được xác định bởi người dùng như đáp ứng yêu cầu, không có lỗi v.v Tổhợp của ba yếu tố này xác định ra năng lực của tổ hay tổ chức Cải tiến liên tục làviệc thay đổi hay nâng cấp từ năng lực mức thấp hơn lên năng lực mức cao hơn

Không có đào tạo đúng, người phát triển phần mềm sẽ làm bất kì cái gì họmuốn chỉ để làm cho công việc của họ được thực hiện Vì phát triển phần mềm làhoạt động "làm việc theo tổ", không phải là hoạt động cá nhân, điều quan trọng làmọi thành viên tổ đều tuân theo những qui tắc nào đó như tuân theo "Quy trìnhđược xác định" cho dự án đó Người quản lí dự án phải nhận diện "Quy trình đượcxác định" trong bản kế hoạch dự án và giám sát các hoạt động để đảm bảo rằng cácthành viên tổ tuân theo nó để có được kết quả mong muốn như hiệu quả, chấtlượng và tốc độ

Một trong những vấn đề chính trong đào tạo khoa học máy tính là sinh viên

có xu hướng làm việc cô lập Điển hình, từng người được trao cho một vấn đề đểgiải quyết, một chương trình để viết mã, và từng người được cho điểm tương ứngtheo thành tích cá nhân Khi sinh viên đi làm, từng người sẽ tiếp tục làm bất kì cái gì

có thể để làm cho việc làm của họ được thực hiện, giống như khi họ còn trongtrường Không có hiểu biết về làm việc tổ bằng việc tuân theo qui trình, nhiều dự án

sẽ không chuyển giao được phần mềm cho khách hàng trong lịch biểu và có chấtlượng Nhiều dự án thường chậm và có chất lượng kém Chúng thất bại vì thiếu sựphối hợp và làm việc tổ điều cho phép các thành viên tổ làm việc cùng nhau Chúngthất bại vì một số thành viên vội vàng viết mã mà không thực sự hiểu các yêu cầu.Chúng thất bại vì có quá nhiều thay đổi trong dự án điều thường tới trễ và không cóqui trình giải quyết thay đổi Chúng thất bại vì người quản lí dự án không biết cách

lập kế hoạch, tổ chức hay ước lượng thời gian, lịch biểu và nỗ lực được cần để hoànthành dự án.

Quy trình được xác định là bản lộ trình cho dự án Nó yêu cầu các thành viên tổtuân theo "con đường" từng bước một Từng bước phải có vai trò và trách nhiệmđược xác định rõ ràng cho từng thành viên tổ Khi thay đổi xảy ra, bản lộ trình nhậndiện rõ ràng ai làm cái gì để cho tổ có thể làm cho công việc của họ được thực hiện

có hiệu quả, chất lượng và đáp ứng lịch biểu dự án (tốc độ)

2 Tự động hóa là gì?

Tự động hóa là việc sử dụng các hệ thống kiểm soát như máy tính để kiểm soátmáy móc thiết bị công nghiệp và quy trình sản xuất, giảm bớt sự cần thiết phải canthiệp của con người Trong phạm vi điều chỉnh của công nghiệp hóa, tự động hóa làmột bước kế tiếp của cơ giới hoá Trong khi cơ giới hoá mang lại cho con người khảnăng vận hành máy móc thiết bị để giúp cho các cơ cấu vật lý hoạt động theo yêucầu công việc, thì tự động hóa lại làm giảm thiểu rất nhiều nhu cầu về sự giám sátcần thiết cũng như trí tuệ của con người Các quy trình và hệ thống đều có thể được

tự động hoá

Tự động hóa ngày càng có vai trò quan trọng trong nền kinh tế toàn cầu vàtrong kinh nghiệm hàng ngày Các kỹ sư đang cố gắng làm cho các thiết bị tự độnghoá kết hợp với các công cụ toán học và tổ chức để tạo ra các hệ thống phức tạpcho một phạm vi đang nhanh chóng phát triển rộng lớn của các ứng dụng và hoạtđộng của con người

Nhiều vai trò của con người trong các quá trình sản xuất công nghiệp hiện nayvẫn nằm ngoài phạm vi điều chỉnh của tự động hóa Khả năng nhận dạng, nhậngiọng và tạo ngôn ngữ vẫn nằm ngoài năng lực của cơ học hiện đại và các hệ thốngmáy tính Những công việc đòi hỏi phải có sự đánh giá chủ quan hoặc tổng hợp dữliệu bằng cảm tính phức tạp, chẳng hạn như hình ảnh và âm thanh, cũng như cácnhiệm vụ cao cấp như lập kế hoạch chiến lược hoặc trước mắt vẫn yêu cầu chuyênmôn của con người Trong nhiều trường hợp, việc sử dụng con người vẫn có hiệuquả hơn phương pháp tiếp cận cơ khí, cả những nơi thậm chí tự động hóa các tác vụcủa công nghiệp có thể đã thực hiện được

Các phần cứng máy tính đặc biệt, gọi tắt là các bộ điều khiển logic lập trình(PLC), thường được sử dụng để đồng bộ hóa tín hiệu đầu vào của các cảm biến vàđầu ra để tới các cơ cấu chấp hành Điều này dẫn đến sự kiểm soát chính xác nhữnghoạt động, vốn cho phép kiểm soát chặt chẽ hầu hết mọi quá trình sản xuất côngnghiệp

Các giao diện người - máy (HMI) hoặc giao diện máy tính - người (CHI), trướcđây được coi như là giao diện người - máy, thường được sử dụng để liên lạc với PLC

và các máy vi tính, chẳng hạn như nhập và giám sát nhiệt độ hoặc áp lực để cóthêm kiểm soát tự động hoặc phản ứng khẩn cấp Dịch vụ nhân sự gồm nhữngngười theo dõi và kiểm soát các giao diện thường được gọi tắt các kỹ sư tĩnh (có vẻchưa đúng thuật ngữ này).

3 Quy trình tự động hóa là gì?

Là thực hiện một quá trình, hoạt động, dự án với theo một quy trình với sự

hỗ trợ của thiết bị công nghệ và máy tính điện tử

Chương 2: CASE- Thiết kế phần mềm với sự trợ giúp của máy tính.

1 GIỚI THIỆU

CASE (Computer Aided Software Engineering) là những phương pháp trợ giúpcho nhà phát triển phần mềm Mục tiêu của việc giới thiệu CASE là giảm thời gian,chi phí phát triển phần mềm và cho việc nâng cao chất lượng của các việc phát triểncác hệ thống CASE liên quan đến việc sử dụng các gói phần mềm được gọi là CASETool để thực hiện và tự động hóa nhiều hoạt động của chu kỳ cuộc sống phát triển

hệ thống

CASE là một sự thay đổi cách mạng đang xảy ra trong quá trình phát triển hệthống phần mềm truyền thống Quá trình SDLC (Software Development Life Cycle –Vòng đời phần mềm) bình thường thường được xem là không linh hoạt, tốn thờigian và tốn kém Trước những hạn chế của quá trình SDLC, CASE đã nổi lên để giúpcác tổ chức phát triển hệ thống và phần mềm Các CASE Tool là hữu ích trong việclập kế hoạch kinh doanh, quản lý dự án, thiết kế giao diện người dùng, thiết kế cơ

sở dữ liệu và lập trình Sử dụng các CASE Tool làm cho máy tính hỗ trợ phát triểnphần mềm có thể Trong bối cảnh của ngày nay, nhanh chóng phân phối sản phẩm

có thể được thử thách nhiệm vụ cho các nhà cung cấp phần mềm, CASE Tool như làcánh tay giúp việc để hỗ trợ tổ chức quản lý quá trình phát triển phần mềm và tựđộng hoá các quy trình nhất định của các hoạt động này Đáng chú ý là một số khảnăng của CASE được tìm thấy trong hầu hết các công cụ phát triển phần mềm hiệnđại Một số tự động thiết kế giao diện người dùng, một vài có thể tự động sinh codechương trình; CASE Tools hỗ trợ đặc biệt trong phân tích & thiết kế, bảo trì và quyhoạch hệ thống, cung cấp các hỗ trợ trong toàn bộ vòng đời phát triển của phầnmềm v.v… Thật khó để tưởng tượng cuộc sống của một lập trình viên mà không cầncác CASE Tool

Ngày nay, hầu hết các tổ chức phần mềm không cần bận tâm về việc dùngCASE Tool trong quá trình phát triển phần mềm của họ Cuối cùng, rào cản trongviệc thúc đẩy các CASE Tool đã trở thành một tiêu chuẩn.

1.1 SỰ RA ĐỜI VÀ PHÁT TRIỂN

1.1.1 Lịch sử

Ngay từ những ngày đầu phát triển phần mềm, kỹ sư phần mềm đã tìm kiếmcác công cụ có ích cho họ trong mô hình của hệ thống, sự hiểu biết của hệ thống làcách dễ dàng trong nhiều cách khác với những người liên quan đến khoa học máytính Từ 1968 đến 1971 đã có rất nhiều cải tiến được thực hiện về vấn đề này nhưthiết kế cơ cấu từ trên xuống, lợi ích của mô đun, từng bước sàng lọc mã được thựchiện; đến năm 1975, chất lượng, độ tin cậy của phần mềm là những vấn đề lớn vàcác thủ tục kiểm tra được áp dụng cho sự phụ thuộc phần mềm

CASE Tool chính thức giới thiệu vào năm 1980, khi tài liệu hướng dẫn, sơ đồ

và các công cụ thiết kế được giới thiệu trong lĩnh vực này Trong cùng thập kỷ, tựđộng kiểm tra phân tích thiết kế, tạo mã tự động và các tiện ích thiết kế liên kếtđược giới thiệu Tầm quan trọng của CASE Tool được coi là hệ thống quy mô lớn vàCASE chính thức được coi như như là một ngành công nghiệp Ngày nay có rấtnhiều CASE Tool, thậm chí nhiều hơn số trường hợp cho cùng một vấn đề Giờ đây,công cụ này giúp các nhà phát triển phân tích, thiết kế và tạo các tài liệu hướng dẫncủa phần mềm Ngay cả các CASE Tool có sẵn cho việc triển khai và bảo trì củaphần mềm Các công cụ như Erwin, Rational Rose có tạo ra có tầm quan trọng trongthị trường do chất lượng và độ tin cậy của họ Trong vòng mười năm qua, các CASETool đã nổi lên như một công nghệ tương tác và đã đạt được vị trí cao trong các lĩnhvực phát triển phần mềm Chúng vẫn đang trong quá trình cải tiến như các lĩnh vựckhác của thế giới, bởi vì tất cả những gì con người tạo ra trong thế giới này luônluôn có chỗ cho cải tiến

1.1.2 Sự cần thiết của CASE

Các nhà phát triển phần mềm luôn luôn tìm kiếm các CASE Tool có thể giúp

họ trong nhiều cách khác nhau trong các giai đoạn phát triển khác nhau của phầnmềm, để họ có thể hiểu được phần mềm và chuẩn bị một sản phẩm cuối cùng cóhiệu quả thực hiện các yêu cầu của người dùng CASE Tool cung cấp những cách cóthể đáp ứng yêu cầu này của các nhà phát triển phần mềm Những công cụ nàycung cấp các thiết lập trên máy vi tính cho các nhà phát triển phần mềm để phântích một vấn đề và sau đó thiết kế mô hình hệ thống của nó

 Những ưu điểm của CASE Tool

 Chúng cung cấp sự nhận thức sâu sắc hơn về hệ thống

 Tạo điều kiện liên lạc giữa các thành viên trong nhóm.

 Các công cụ có hiệu quả hơn cho các hệ thống và các dự án quy môlớn

 CASE Tool cung cấp khả năng hiển thị của các quá trình và sự logic

 CASE Tool cải thiện chất lượng và năng suất của phần mềm

 CASE Tool giảm thời gian cho việc sửa lỗi và bảo trì

 CASE Tool cung cấp khả năng đọc rõ ràng và bảo trì của hệ thống

1.1.3 Vị trí của CASE Tool trong những năm 90.

Mục đích của CASE là để giảm chi phí và thời gian cần thiết cho sự phát triển

hệ thống và tập trung vào chất lượng của sản phẩm cuối cùng CASE đã không được

sử dụng như nó đã tưng được hy vọng Hầu hết các công ty không muốn áp dụngcác CASE Tool Quan sát cho thấy rằng CASE đang được sử dụng nhưng không phải

ở nhiều công ty “Những lý do để từ bỏ bao gồm chi phí, thiếu lợi nhuận đo lườngđược, và kỳ vọng không thực tế Các tổ chức sử dụng các CASE Tool và phát hiện rarằng một số lượng lớn của các hệ thống phát triển của họ không được sử dụng cácCASE Tool Ông báo cáo rằng 57% các tổ chức được khảo sát đã được sử dụng cácCASE Tool, ít hơn 25 % các nhà phát triển hệ thống sử dụng các công cụ” (DianeLending 1998) Và trong những công ty đã thông qua việc sử dụng CASE, cũng chỉ

có vài người đang sử dụng các CASE Tool Trong một cuộc khảo sát của 67 công ty,

nó đã được quan sát thấy rằng 69% các công ty chưa bao giờ được sử dụng cácCASE Tool Và những người đang sử dụng các CASE Tool thừa nhận rằng việc sửdụng các CASE Tool cải thiện các tiêu chuẩn tài liệu và kết quả hệ thống dễ dànghơn để kiểm tra và duy trì Tuy nhiên, những người sử dụng các CASE Tool cũngthừa nhận rằng việc sử dụng các CASE Tool đòi hỏi nhiều thời gian và nỗ lực vàcũng cho biết thêm trong thời gian phát triển tổng thể

Dưới 30% những người sử dụng tiềm năng và các nhà phát triển sử dụngCASE và những người sử dụng nó, sử dụng các chức năng đơn giản và cơ bản củacác CASE Tool Điều này cho thấy rằng ngay cả sau khi nhận được rất nhiều phổbiến các CASE Tool không được chấp nhận và sử dụng rất nhiều trong ngành côngnghiệp phát triển phần mềm như chúng mong đợi hoặc là chúng nên được sử dụng.Chỉ sau một năm giới thiệu 70 % các CASE Tool không bao giờ được sử dụng, 25%được sử dụng bởi một nhóm và 5% của CASE Tool được sử dụng hoàn toàn [ JuhaniIivar, 1996]

1.1.4 Tại sao CASE Tool chưa phổ biến

 Chi phí

Rất nhiều công cụ tốn kém và hầu hết các công ty không sẵn sàng để thựchiện các CASE Tool bởi thực tế là nó làm tăng chi phí tổng thể của dự án Và điềuthứ hai nếu một công ty không nhận được bất kỳ thêm lợi nhuận bằng cách sử dụngcác CASE Tool, tại sao họ phải sử dụng các CASE Tool, cuối cùng lại mất thêm chiphí.

 Thời gian giới hạn

Luôn luôn có một giới hạn thời gian cho tất cả các dự án phần mềm để pháttriển Hầu hết các công ty không chấp nhận CASE vì nó đòi hỏi rất nhiều thời gian

để đào tạo các nhà phát triển và thực hiện tất cả các hoạt động Case và luôn cónhững thời hạn để hoàn thành dự án Bạn đã quá đáp ứng thời hạn của công ty,nhưng nếu bạn sử dụng các CASE Tool bạn không thể hoàn thành dự án đúng thờihạn, đó cũng là một yếu tố được sử dụng ít hơn của CASE Tool

 Đào tạo

Đào tạo là một mối quan tâm lớn trong khi bất kỳ công ty sẽ sử dụng mộtcông cụ mới, đó là thủ tục khá tốn kém Họ có để đào tạo phát triển cho việc sửdụng hiệu quả của công cụ đó cụ thể Hầu hết các công ty tránh sử dụng các CASETool vì thực tế này rằng họ sẽ phải để đào tạo một số lượng lớn các nhân viên vàgây tốn kém chi phí cũng như tốn thời gian

 Thiếu quan tâm

Hầu hết các nhà phát triển sử dụng các CASE Tool không hoàn toàn hài lòng

từ các CASE Tool, đó là lý do tại sao họ là khá trung lập về tính hữu ích của CASETool Các nhà phát triển không được hưởng đầy đủ bằng cách sử dụng các CASETool và nếu một số người trong số họ làm như vậy, họ chỉ sử dụng chức năng hạnchế của CASE Tool Nhiều nhà phát triển sử dụng các CASE Tool như là một yêu cầucủa tổ chức duy nhất Các nhà phát triển dường như không có động cơ để sử dụngcác CASE Tool và thiếu sự quan tâm là yếu tố lớn trong việc sử dụng ít hơn củaCASE Tool

 Kỹ thuật hạn chế

Mọi CASE Tool theo một phương pháp cho các mô hình hệ thống Nhữngngười sử dụng bất kỳ công cụ trường hợp cụ thể trong một thời gian dài hơn thờigian quen với phương pháp của công cụ đó và họ cố gắng để áp dụng các phươngpháp tương tự đối với các dự án khác Hầu hết các công cụ phần cứng của họ vàyêu cầu phần mềm Những yêu cầu cần đáp ứng để sử dụng công cụ đó Đây là mộttrở ngại trong việc áp dụng CASE Tool cho những công ty không đáp ứng được yêucầu phần cứng hoặc phần mềm để sử dụng các CASE Tool Công cụ không nên làtấm hình thức phụ thuộc hoặc phần mềm hoặc phần cứng

 Chuyển giao công nghệ

Một trong những thách thức chính trong việc áp dụng CASE là thay đổi côngnghệ CASE phụ thuộc vào quản lý, quy hoạch và kinh nghiệm đầu và nó không thểđược đảm bảo ngay cả những người có kinh nghiệm trường hợp đó có thể dễ dàngđược kết hợp

 Lựa chọn các CASE Tool

Đó cũng là một mối quan tâm lớn mà một tổ chức phải chọn trường hợp mộtcông cụ thích hợp mà bộ có tổ chức, nhưng không may thay hầu hết của các nhàphát triển thời gian không được tư vấn và quản lý sử dụng để chọn công cụ trườnghợp đó là một trở ngại lớn trong cách thâm nhập CASE Tool Trước khi lựa chọn bất

kỳ công nghệ mới, những người sử dụng chúng phải được tư vấn bởi vì họ tốt hơn

có thể lập luận rằng làm thế nào họ có thể sử dụng hiệu quả các CASE Tool Vì cónhiều công cụ cho cùng một vấn đề nên việc lựa chọn công cụ thị trường là một mốiquan tâm lớn

1.2 MỤC TIÊU

Phần này cung cấp kiến thức để:

• Biết các vai trò của các CASE Tool và sự sử dụng bởi các tổ chức ;

• Biết các thành phần của CASE Tools ;

• Giải thích các CASE Tool trực quan và biết về một số công cụ thương mại;

• Mô tả các CASE Tool tinh vi ;

• Mô tả các CASE Tools hướng đối tượng với tiện ích của chúng trong pháttriển phần mềm

1.3 Đôi nét về CASE Tool

CASE (Computer Aided Software Engineering) là việc sử dụng máy tính hỗ trợquá trình phát triển công nghệ phần mềm Sự hỗ trợ có thể là của bất kỳ loại nhưquản lý, kỹ thuật hoặc hành chính trên bất kỳ một phần của quá trình phát triểnphần mềm Tất cả các phần mềm tham gia giúp đỡ trong quá trình phát triển côngnghệ phần mềm có thể được gọi là CASE Tool

Khi hoạt động phát triển phần mềm trở nên phức tạp và không thể quản lýđược, đã có một nhận thức về sự cần thiết cho các công cụ tự động để giúp các nhàphát triển phần mềm để thực hiện nhiệm vụ này Ban đầu, đã được tập trung chủyếu vào chương trình công cụ hỗ trợ như thiết kế của phiên dịch, biên dịch, lắp ráp,các bộ vi xử lý vĩ mô, và các công cụ khác Khi máy tính trở nên mạnh mẽ hơn vàcác phần mềm chạy trên chúng đã phát triển lớn hơn và phức tạp hơn, các công cụ

hỗ trợ đã bắt đầu mở rộng hơn nữa Một số khả năng của CASE Tool cũng được tìmthấy trong các phần mềm ứng dụng phát triển chung

Quy mô lớn sử dụng máy tính đã đòi hỏi phải sử dụng tối đa và hiệu quả vàphát triển phần mềm cho các hoạt động khác nhau của bất kỳ tổ chức nào Một nỗlực phát triển phần mềm có thể được xem như là một nỗ lực đáng kể để thiết kế cácgiải pháp thích hợp, kiểm tra và thực hiện các giải pháp và cuối cùng là tài liệu cácgiải pháp Trong quan điểm này, một loạt các công cụ hỗ trợ bắt đầu xuất hiện đểgiúp các nhóm phát triển

1.3.1 Vai trò của các CASE Tool

CASE Tool đóng một vai trò quan trọng trong các hoạt động sau đây:

• Quản lý dự án

• Từ điển dữ liệu

• Sinh mã (sinh code)

• Thiết kế giao diện người dùng

• Sinh giản đồ

• Tạo ra các siêu dữ liệu cho kho dữ liệu

• Kỹ thuật đảo ngược

• Tái lập

• Sinh tài liệu

• Kiểm soát phiên bản

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

1.3.2 Ưu điểm của CASE Tool

Sau đây là một số lợi thế của CASE Tool:

• Môi trường phát triển tích hợp: CASE Tool cung cấp giao diện người dùngduy nhất cho các nhà phát triển và nhà phân tích, tự động hóa các hoạt động tốnthời gian và tẻ nhạt như sinh mã

• Hướng dẫn phát triển: Nó cung cấp nền tảng chung cho tất cả các nhà pháttriển và giúp phát triển hệ thống phương pháp

• Tính nhất quán giữa các mô hình và tài liệu: Tài liệu được tạo ra của môhình tự động dẫn đến sự nhất quán giữa các mô hình và tài liệu hướng dẫn

1.3.5 Nhược điểm của CASE Tool

Sau đây là một số trong những nhược điểm của các CASE Tool:

dễ dàng hơn

1.3.3 Các loại CASE Tool

Sau đây là các loại khác nhau của các CASE Tool:

• Kế hoạch và quản lý công cụ: Bắt đầu quá trình phát triển với thông tin quyhoạch và quản lý dự án

• Công cụ phân tích: Những công cụ này đảm bảo rằng các yêu cầu kinhdoanh một cách chính xác bắt trong giai đoạn phân tích sớm trong quá trình pháttriển Công cụ phân tích được sử dụng để kiểm tra các thông số kỹ thuật không đầy

đủ, không phù hợp hoặc không chính xác

• Thiết kế bộ công cụ: Nó cung cấp đặc điểm kỹ thuật chi tiết của hệ thống

• Thông tin tích hợp: Nó tích hợp kỹ thuật hệ thống và kiểm tra chúng chophù hợp và đầy đủ Nó cũng ghi lại trong kho CASE

• Sinh mã: Nó sẽ tự động tạo ra mã cụ thể cho một ngôn ngữ dựa trên cácđặc điểm kỹ thuật của hệ thống

• Cơ sở dữ liệu thiết kế bộ công cụ: Nó gợi ý thiết kế cơ sở dữ liệu và tạo ra

hệ thống thông tin điều khiển

• Giao diện người dùng máy phát điện: Nó tạo ra giao diện người sử dụngdựa trên đặc điểm kỹ thuật của hệ thống

• Kết xuất bảo cáo: Nó tạo ra các báo cáo dựa trên đặc điểm kỹ thuật

Hình 2.1: Các thành phần của một CASE Tool điển hình

Tất cả các công cụ CASE được dựa trên nguyên mẫu là đặc biệt hữu ích khiyêu cầu người sử dụng rất khó để xác định Các hệ thống lớn sử dụng phương pháptiếp cận SDLC truyền thống nhưng một phần của hệ thống có thể là nguyên mẫu.Các mẫu thử nghiệm sau đó liên tục tinh chế cho đến khi nó trở thành chấp nhậnđược

1.3.4 Phân loại CASE Tool

Hình 2.2: Các loại Case Tool.

Mặc dù các CASE Tool có thể được phân loại tùy thuộc vào các chức năng,chúng có thể được phân loại thành năm danh mục chung chung:

• Phát triển các công cụ: Những công cụ này tương tác trong tự nhiên Chúngđược sử dụng để hỗ trợ thiết kế và thế hệ mã

• Công cụ front-end: Chúng hỗ trợ hoạt động earlyin vòng đời của một quátrình phát triển phần mềm (lập kế hoạch, phân tích và thiết kế) Ví dụ như lưu lượng

dữ liệu sơ đồ, sơ đồ cấu trúc dữ liệu, sơ đồ ER, các công cụ tạo mẫu, vv

• Công cụ back-end: Chúng hỗ trợ các hoạt động sau này trong vòng đời củamột quá trình phát triển phần mềm ( Thực hiện và bảo trì) Ví dụ Sare chương trìnhbiểu đồ lưu lượng, chương trình soạn thảo, trình sửa lỗi, mã máy phát điện

• Các công cụ ngang: công cụ này là không cụ thể cho một bước chu kỳ cuộcsống cụ thể nhưng phổ biến trên một số ví dụ như bước chu kỳ cuộc sống, Tài liệucông cụ

• Công cụ dọc: Những công cụ này là cụ thể cho một chu kỳ sống

1.3.5 Kỹ thuật đảo ngược và chuyển tiếp

Chúng tôi sẽ thảo luận về hai khái niệm quan trọng liên quan đến các CASETool cụ thể là, kỹ thuật chuyển tiếp và đảo ngược Hình 2.3 mô tả cả hai kỹ thuật vềchuyển tiếp và đảo ngược

Kỹ thuật đảo ngược là quá trình vui chơi giải trí của mô hình dựa trên mã hiệntại Trước tiên, các mã hiện tại được quét để tạo ra các mô hình Sau đó, các môhình có thể được điều chỉnh phù hợp với yêu cầu Kỹ thuật đảo ngược cho phép cácnhà phát triển để tạo ra mô hình cho các hệ thống cũ, mà chưa bao giờ được môhình Nó phân tích phần mềm hiện có với mục đích của sự hiểu biết thiết kế và đặcđiểm kỹ thuật của nó đảo ngược công cụ kỹ thuật đọc mã nguồn của chương trình

và tạo ra đại diện đồ họa và văn bản của thiết kế

Kỹ thuật chuyển tiếp là quá trình thế hệ mã khung của các mô hình Bướcđầu tiên là để tạo ra các mô hình cho một hệ thống, sau đó tạo ra các mã có liênquan cho mô hình và sau đó cho phép sửa đổi của mã này trong điều chỉnh với cácyêu cầu Kỹ thuật lại có nghĩa là “tái cơ cấu và viết lại hệ thống di sản hoặc mộtphần của nó mà không cần thay đổi chức năng ban đầu của nó” Nỗ lực tái cơ làmcho phần mềm được cập nhật công nghệ hiện tại và do đó dễ duy trì Hệ thống mớinày sẽ trở thành cơ cấu lại và các tài liệu lại Kỹ thuật tái lập công cụ đọc mã nguồncủa chương trình và tương tác thay đổi và hệ thống hiện có để cải thiện hiệu suấtchất lượng hoặc bảo trì

Hình 2.2: Kỹ thuật đảo ngược và chuyển tiếp

1.4 CASE TOOL TRỰC QUAN VÀ RÕ NÉT

Visual CASE Tool cho phép người sử dụng để nhanh chóng tạo ra các giaodiện người dùng và mã khung có liên quan

1.4.1 Phát triển hệ thống truyền thống và phát triển các hệ thống dựa trên Case

Sau đây là các tính năng của phát triển hệ thống truyền thống:

• Nhấn mạnh vào chương trình, kiểm tra và mã hóa tài liệu

• Thông số kỹ thuật được viết bởi các nhà phân tích và trên giấy

• Mã chương trình là thủ công và tẻ nhạt

• Tài liệu được viết bởi các lập trình viên hoặc nhà phân tích và thường đượcthực hiện sau khi hoàn thành quá trình

• Quá trình kiểm thử phần mềm theo phương pháp truyền thống

• Hướng dẫn sử dụng bảo trì của mã và tài liệu hướng dẫn

Sau đây là các tính năng của phát triển hệ thống dựa trên CASE:

• Nhấn mạnh vào phân tích và thiết kế

• Tạo mẫu nhanh và tương tác của các mô hình

• Tự động sinh mã

• Kết xuất tài liệu tự động

• Tự động thiết kế kiểm tra

• Duy trì kỹ thuật thiết kế

1.4.2 Môi trường CASE

Các thế hệ trước đó của các nhà phát triển công cụ CASE tập trung phần lớnvào việc tự động hóa các nhiệm vụ riêng biệt của quá trình phát triển hệ thống,chẳng hạn như sản xuất tài liệu, điều khiển phiên bản của mã nguồn, và hỗ trợphương pháp thiết kế Cần tích hợp những công cụ này để hỗ trợ một môi trườngphát triển chung đã được cảm nhận để hỗ trợ các hoạt động có hiệu quả Một CASEđiển hình môi trường bao gồm một số CASE Tool và các thành phần liên quan để hỗtrợ hầu hết hoặc tất cả các giai đoạn của chu kỳ cuộc sống phát triển hệ thống hoạt

động trên một phần cứng phổ biến và nền tảng phần mềm CASE môi trường làkhông chỉ là một sự pha trộn ngẫu nhiên của CASE Tool, nó cung cấp tương tác phùhợp giữa các CASE Tool Người ta phải tập trung ít hơn thành phần nên được lựachọn, và nhiều hơn về việc làm thế nào các thành phần được lựa chọn có thể đượcthực hiện để làm việc cùng nhau một cách hiệu quả Hình 2.4 mô tả môi trườngCASE điển hình.

Hình 2.3: Môi trường CASE

Mấu chốt của các CASE Tool là hội nhập Các công cụ có hiệu quả hơn nếuchúng được tích hợp để làm việc cùng nhau Tích hợp có thể tích hợp dữ liệu, giaodiện người dùng tích hợp hoặc tích hợp hoạt động

Ví dụ về các CASE Tool trực quan

• Oracle 2000 Designer

• Evergreen EasyCase

• Aonix: Software Through Pictures

• Popkin System Architect

Mô hình UML: mô hình ngôn ngữ thống nhất, hoặc UML là chủ yếu là mộtngôn ngữ mô hình đồ họa được sử dụng để thể hiện các thiết kế Nó là một ngônngữ chuẩn, trong đó hiện vật và các thành phần của một hệ thống phần mềm có thểđược xác định Điều quan trọng là phải hiểu rằng UML đơn giản mô tả một ký hiệu

và không phải là một quá trình Nó không đưa ra một phương pháp duy nhất hoặc

quá trình thiết kế, mà đúng hơn là một công cụ tiêu chuẩn hóa có thể được sử dụngtrong một quá trình thiết kế.

Sau đây là một số trong những nhiệm vụ có thể được thực hiện bằng cách sửdụng các CASE Tool:

• Mô hình hóa UML

• Hình thành, xây dựng code cho Visual C++, Visual Basic, C++, Ada, JAVA

• Thiết kế cơ sở dữ liệu

• Sinh mã hoàn chỉnh cho C, C++, v.v…

• Kiểm thử thành phần

Một CASE Tool khác là Enterprise Architect ( Parx System) Đây là một CASEđối tượng công cụ định hướng cho toàn chu kỳ phát triển phần mềm Tính năng của

nó là:

• Mô hình hóa quy trình kinh doanh

• Kỹ thuật đảo ngược và chuyển tiếp

• Tự động hóa giao diện

• Hỗ trợ C + +, Java, VB, VB.Net, Delphi

• Công cụ ước lượng đánh giá dự án

• Công cụ kiểm thử

• Thiết kế giao diện người dùng

• Yêu cầu thu thập

• Mô hình hóa thành phần

• Triển khai mô hình

1.4.3 CASE Tool nổi

Ban đầu các CASE Tool không mấy tinh vi về quá trình họ hỗ trợ Giờ đây,CASE Tool tích hợp đã xuất hiện để hỗ trợ các gam màu toàn bộ hệ thống kỹ thuật

và quá trình phát triển phần mềm

CASE tích hợp ( I- CASE )

• Nó cung cấp môi trường phát triển hệ thống tự động cung cấp rất nhiềucông cụ để tạo ra các sơ đồ, biểu mẫu và báo cáo

• Tất cả các công cụ chia sẻ một giao diện người dùng thông thường.

• Người dùng có cảm giác làm việc trên một trong những công cụ

• Cung cấp phân tích, báo cáo và các thiết bị thế hệ mã

• Liền mạch cổ phiếu và tích hợp dữ liệu khác giữa các công cụ

• Kho chứa là một địa điểm trung tâm để lưu trữ thông tin mà là để được chia

sẻ giữa các công cụ khác nhau

1.4.4 CASE Tool hướng đối tượng

CASE Tool hướng đối tượng tương tự như các CASE Tool khác Sự khác nhaucủa mỗi cái chỉ là về khả năng của chúng để tạo ra sơ đồ lớp và thông số kỹ thuậtvăn bản cho các báo cáo Các CASE Tool theo định hướng đối tượng hỗ trợ mộtphương pháp OO như Rumbaugh's Object Management Technique (OMT)

Ví dụ về các CASE Tool hướng đối tượng

Một số lượng lớn các CASE Tool hướng đối tượng có sẵn trên thị trường Baogồm: Paradigm Plusfrom Protosoft, Rational Rose từ Rational (nay thuộc IBM) vàWithClass từ MicroGold Software Thảo luận của chúng tôi ở đây sẽ mô tả các CASETool hướng đối tượng nói chung mà không làm cho tài liệu tham khảo cho một sảnphẩm cụ thể

Sau đây là một số các tính năng được tìm thấy ở hầu hết các CASE Toolhướng đối tượng:

1 Tạo đồ họa, chẳng hạn như sơ đồ lớp, sơ đồ tin, sơ đồ trạng thái v.v…

2 Tạo chi tiết kỹ thuật văn bản như đặc điểm kỹ thuật hệ thống, đặc điểm kỹthuật lớp và đặc điểm kỹ thuật mối quan hệ

3 Tạo ra mã nguồn

4 Kho lưu trữ của các mô hình

Sự khác biệt giữa các loại khác nhau của các CASE Tool hướng đối tượngTất cả những công cụ này đối tượng CASE định hướng tương tự về khả năngcủa mình để tạo ra sơ đồ lớp, sinh mã Tuy nhiên, họ có thể khác nhau về khả năng

mở rộng, số lượng hệ điều hành được hỗ trợ và các tính năng bổ sung và khả năng,chẳng hạn như hỗ trợ cho các phương pháp khác nhau và sinh mã máy( C + +, Ada,Java, v.v… ) Nhất cung cấp khả năng tự động tạo ra các mã của C + + và các ngônngữ khác từ một sơ đồ lớp và chi tiết kỹ thuật lớp Một số cung cấp khả năng để tạo

ra các sơ đồ lớp từ mã ( kỹ thuật đảo ngược ) Hình 1.5 mô tả công cụ vẽ và thiết kếvăn bản.

Một CASE tool hướng đối tượng có khả năng vẽ sơ đồ lớp và sơ đồ trạng thái.Đặc điểm kỹ thuật các công cụ tạo ra các báo cáo văn bản

Hình 2.5: Công cụ vẽ và thiết kế văn bản

Hình 2.6 mô tả các kết quả đầu ra chính của CASE Tool hướng đối tượng

Hình 2.6: Đầu ra chủ yếu của CASE Tool hướng đối tượng

Sơ đồ lớp là cốt lõi để thiết kế hướng đối tượng Nó mô tả các loại của các đốitượng trong hệ thống và các mối quan hệ tĩnh giữa chúng Các yếu tố cốt lõi của sơ

đồ lớp là lớp Trong một hệ thống hướng đối tượng, các lớp được sử dụng để đạidiện cho các thực thể trong hệ thống Các đối tượng thường liên quan đến các đốitượng thế giới thực

1.4.5 Tạo tài liệu và báo cáo bằng cách sử dụng các CASE Tool hướng đối tượng

Yêu cầu hệ thống mô tả một điều kiện hoặc khả năng mà một hệ thống phảiphù hợp với, hoặc trực tiếp từ nhu cầu người sử dụng hoặc có nguồn gốc từ hoặc đãđược ghi trong hợp đồng, tiêu chuẩn, đặc điểm kỹ thuật, tài liệu chính thức áp đặtkhác

Hầu hết các công cụ đối tượng CASE định hướng hỗ trợ trong tài liệu cũngnhư trong phân tích và thiết kế hướng đối tượng Đối tượng CASE Tool hướng cókhả năng nhập đồ họa từ các công cụ khác Yêu cầu hệ thống được hình dạng trongbản phác thảo bằng bút chì và giấy Sau đó, nó được sử dụng bởi các công cụ vẽ vàsoạn thảo văn bản có sẵn để tạo ra sơ đồ hệ thống, sơ đồ lớp và sơ đồ khác Tàiliệu xử lý sẽ làm tất cả để tạo ra một tài liệu mô hình từ các mô hình này Hình 1.9

mô tả quá trình để tạo ra một tài liệu mô hình

Hình 2.7: Quy trình để tạo ra một tài liệu mô hình

Hầu hết các CASE Tool hướng đối tượng hỗ trợ rất nhiều trong việc tạo ranguyên mẫu thực thi dựa trên thông số kỹ thuật thiết kế Biểu đồ dưới đây cho thấylàm thế nào các CASE Tool được sử dụng để tạo ra các mã thực thi Yêu cầu hệthống được chuẩn bị trong văn bản và biểu đồ bằng bút chì và giấy Kỹ thuật thiết

kế như thông số kỹ thuật lớp, sơ đồ hệ thống và thông số kỹ thuật văn bản khácnhau sau đó được tạo ra bằng cách sử dụng công cụ có sẵn trong CASE Từ đó,thiết kế mã số đặc điểm kỹ thuật được tạo ra bằng cách sử dụng các công cụ thế hệ

mã Hầu hết các CASE Tool hỗ trợ thế hệ của mã C++ trong khi một số có thể hỗtrợ các ngôn ngữ khác như là tốt Mã nguồn được tạo ra có thể yêu cầu cập nhật vớicác công thức, biểu thức, CASE Tool cũng tạo ra các biểu đồ cập nhật dựa trên mãnguồn cập nhật

Chương 3: Giới thiệu về UML

I UML- Ngôn ngữ mô hình hóa thống nhất.

1 LỊCH SỬ UML

Năm 1997, Object Management Group (OMG – Nhóm quản lý đối tượng) đãphát hành bản Unified Modeling Language (UML) Một trong những mục đích củaUML là cung cấp cho cộng đổng phát triển một ngôn ngữ thiết kế phổ biến và ổnđịnh, ngôn ngữ này có thể được dùng để phát triển và xây dựng các ứng dụng máytính UML đưa ra một ký hiệu mô hình hóa chuẩn thống nhất mà các chuyên giacông nghệ thong tin muốn có trong nhiều năm Khi sử dụng UML, các chuyên giacông nghệ thong tin bây giờ đã có thể đọc và phổ biến cấu trúc hệ thống và các kếhoạch thiết kế - giống như các công nhân xây dựng đang làm trong nhiều năm quavới các kế hoạch chi tiết về các tòa nhà

2 UML LÀ GÌ?

UML (Unified Modeling Language) là một ngôn ngữ chuẩn cho việc cụ thểhóa, trực quan hóa, xây dựng và tạo tài liệu cho một hệ thống phần mềm, cũng nhưcho mô hình doanh nghiệp và những hệ thống khác UML miêu tả một loạt các kỹthuật công nghệ tốt nhất đã được kiểm chứng và thành công trong nhiều hệ thốnglớn và phức tạp UML là một phần quan trọng trong việc phát triển các phần mềmhướng đối tượng và trong quy trình phát triển phần mềm UML sử dụng hầu hết các

ký hiệu đồ họa để mô tả bản thiết kế của các dự án phần mềm Sử dụng UML sẽ

giúp cho các nhóm dự án có thể dễ dàng giao tiếp, khai thác những tiềm năng thiết

kế, và phê chuẩn thiết kế kiến trúc của phần mềm

Ngôn ngữ mô hình hóa thống nhất (Unifield Modeling Language – UML) làmột ngôn ngữ để biểu diễn mô hình theo hướng đối tượng được xây dựng bởi ba tácgiả trên với chủ đích là:

 Mô hình hoá các hệ thống sử dụng các khái niệm hướng đối tượng

 Thiết lập một kết nối từ nhận thức của con người đến các sự kiện cần môhình hoá

 Giải quyết vấn đề về mức độ thừa kế trong các hệ thống phức tạp, có nhiềuràng buộc khác nhau

 Tạo một ngôn ngữ mô hình hoá có thể sử dụng được bởi người và máy

UML là hệ thống các ký hiệu và hình vẽ có ý nghĩa, quan trọng UML khôngphải là một ngôn ngữ lập trình, nó phải được sử dụng kết hợp với một tiến trìnhphương pháp luận UML là một ngôn ngữ dùng để đặc tả, trực quan hoá, và tư liệuhoá phần mềm hướng đối tượng

3 UML TRONG PHÂN TÍCH THIẾT KẾ HỆ THỐNG

UML có thể được sử dụng trong nhiều giai đoạn, từ phát triển, thiết kế cho tớithực hiện và bảo trì Vì mục đích chính của ngôn ngữ này là dùng các biểu đồ hướngđối tượng để mô tả hệ thống nên miền ứng dụng của UML bao gồm nhiều loại hệthống khác nhau như:

 Hệ thống thống tin (Information System): Cất giữ, lấy, biến đổi biểu diễnthông tin cho người sử dụng Xử lý những khoảng dữ liệu lớn có các quan hệphức tạp, mà chúng được lưu trữ trong các cơ sở dữ liệu quan hệ hay hướngđối tượng

 Hệ thống kỹ thuật (Technical System): Xử lý và điều khiển các thiết bị kỹthuật như viễn thông, hệ thống quân sự, hay các quá trình công nghiệp Đây

là loại thiết bị phải xử lý các giao tiếp đặc biệt, không có phần mềm chuẩn vàthường là các hệ thống thời gian thực (real time)

 Hệ thống nhúng (Embeded System): Thực hiện trên phần cứng gắn vào cácthiết bị như điện thoại di động, điều khiển xe hơi, … Điều này được thực hiệnbằng việc lập trình mức thấp với hỗ trợ thời gian thực Những hệ thống nàythường không có các thiết bị như màn hình đĩa cứng, …

 Hệ thống phân bố ( Distributed System): Được phân bố trên một số máy chophép truyền dữ liệu từ nơi này đến nơi khác một cách dễ dàng Chúng đòi hỏi

các cơ chế liên lạc đồng bộ để đảm bảo toàn vẹn dữ liệu và thường được xâydựng trên một số các kỹ thuật đối tượng như CORBA, COM/DCOM, hay JavaBeans/RMI.

 Hệ thống Giao dịch (Business System): Mô tả mục đích, tài nguyên (conngười, máy tính, …), các quy tắc (luật pháp, chiến thuật kinh doanh, cơ chế,

…), và công việc hoạt động kinh doanh

 Phần mềm hệ thống (System Software): Định nghĩa cơ sở hạ tầng kỹ thuậtcho phần mềm khác sử dụng, chẳng hạn như hệ điều hành, cơ sở dữ liệu,giao diện người sử dụng

4 UML VÀ CÁC GIAI ĐOẠN PHÁT TRIỂN HỆ THỐNG

Preliminary Investigation: Use Cases thể hiện các yêu cầu của người dùng.Phần miêu tả use case xác định các yêu cầu, phần diagram thể hiện mối quan hệ vàgiao tiếp với hệ thống

Analysis: Mục đích chính của giai đọan này là trừu tượng hóa và tìm hiểu các

cơ cấu có trong phạm vi bài toán Class diagrams trên bình diện trừu tượng hóa cácthực thể ngoài đời thực được sử dụng để làm rõ sự tồn tại cũng như mối quan hệcủa chúng Chỉ những lớp (class) nằm trong phạm vi bài toán mới đáng quan tâm

Design: Kết quả phần analysis được phát triển thành giải pháp kỹ thuật Cáclớp được mô hình hóa chi tiết để cung cấp hạ tầng kỹ thuật như giao diện, nền tảngcho database, … Kết quả phần Design là các đặc tả chi tiết cho giai đoạn xây dựngphần mềm

Development: Mô hình Design được chuyển thành code Programmer sử dụngcác UML diagrams trong giai đoạn Design để hiểu vấn đề và tạo code

Testing: Sử dụng các UML diagrams trong các giai đoạn trước Có 4 hình thứckiểm tra hệ thống:

 Unit testing (class diagrams & class specifications): kiểm tra từng đơn thể,được dùng để kiểm tra các lớp hay các nhóm đơn thể

 Integration testing (integration diagrams & collaboration diagrams): kiểm tratích hợp là kiểm tra kết hợp các component với các lớp để xem chúng hoạtđộng với nhau có đúng không

 System testing (use-case diagrams): kiềm tra xem hệ thống có đáp ứng đượcchức năng mà người sử dụng yêu cầu hay không

 Acceptance testing: Kiểm tra tính chấp nhận được của hệ thống, thường đượcthực hiện bởi khách hàng, việc kiểm tra này thực hiện tương tự như kiểm tra

hệ thống

II Khái quát về UML.

1 UML VÀ CÁC GIAI ĐOẠN CỦA CHU TRÌNH PHÁT TRIỂN PHẦN MỀM

1.1 Giai đoạn nghiên cứu sơ bộ:

UML đưa ra khái niệm Use Case để nắm bắt các yêu cầu của khách hàng (người sử dụng) UML sử dụng biểu đồ Use case (Use Case Diagram) để nêu bật mối quan hệ cũng như sự giao tiếp với hệ thống

Qua phương pháp mô hình hóa Use case, các tác nhân (Actor) bên ngoài quan tâmđến hệ thống sẽ được mô hình hóa song song với chức năng mà họ đòi hỏi từ phía

hệ thống (tức là Use case) Các tác nhân và các Use case được mô hình hóa cùngcác mối quan hệ và được miêu tả trong biểu đồ Use case của UML Mỗi một Usecase được mô tả trong tài liệu, và nó sẽ đặc tả các yêu cầu của khách hàng: Ai chờđợi điều gì ở phía hệ thống mà không hề để ý đến việc chức năng này sẽ được thựcthi ra sao

1.2 Giai đoạn phân tích:

Giai đoạn phân tích quan tâm đến quá trình trừu tượng hóa đầu tiên (các lớp

và các đối tượng) cũng như cơ chế hiện hữu trong phạm vi vấn đề Sau khi nhàphân tích đã nhận biết được các lớp thành phần của mô hình cũng như mối quan hệgiữa chúng với nhau, các lớp cùng các mối quan hệ đó sẽ được miêu tả bằng công

cụ biểu đồ lớp (class diagram) của UML Sự cộng tác giữa các lớp nhằm thực hiệncác Use case cũng sẽ được miêu tả nhờ vào các mô hình động (dynamic models)của UML Trong giai đoạn phân tích, chỉ duy nhất các lớp có tồn tại trong phạm vivấn đề (các khái niệm đời thực) là được mô hình hóa Các lớp kỹ thuật định nghĩachi tiết cũng như giải pháp trong hệ thống phần mềm, ví dụ như các lớp cho giaodiện người dùng, cho ngân hàng dữ liệu, cho sự giao tiếp, trùng hợp, v.v , chưaphải là mối quan tâm của giai đoạn này

1.3 Giai đoạn thiết kế:

Trong giai đoạn này, kết quả của giai đoạn phân tích sẽ được mở rộng thànhmột giải pháp kỹ thuật Các lớp mới sẽ được bổ sung để tạo thành một hạ tầng cơ

sở kỹ thuật: Giao diện người dùng, các chức năng để lưu trữ các đối tượng trongngân hàng dữ liệu, giao tiếp với các hệ thống khác, giao diện với các thiết bị ngoại vi

và các máy móc khác trong hệ thống, Các lớp thuộc phạm vi vấn đề có từ giaiđoạn phân tích sẽ được "nhúng" vào hạ tầng cơ sở kỹ thuật này, tạo ra khả năngthay đổi trong cả hai phương diện: Phạm vi vấn đề và hạ tầng cơ sở Giai đoạn thiết

kế sẽ đưa ra kết quả là bản đặc tả chi tiết cho giai đoạn xây dựng hệ thống

1.4 Giai đoạn xây dựng:

Trong giai đoạn xây dựng (giai đoạn lập trình), các lớp của giai đoạn thiết kế

sẽ được biến thành những dòng code cụ thể trong một ngôn ngữ lập trình hướngđối tượng cụ thể (không nên dùng một ngôn ngữ lập trình hướng chức năng!) Phụthuộc vào khả năng của ngôn ngữ được sử dụng, đây có thể là một công việc khókhăn hay dễ dàng Khi tạo ra các mô hình phân tích và thiết kế trong UML, tốt nhấtnên cố gắng né tránh việc ngay lập tức biến đổi các mô hình này thành các dòngcode Trong những giai đoạn trước, mô hình được sử dụng để dễ hiểu, dễ giao tiếp

và tạo nên cấu trúc của hệ thống; vì vậy, vội vàng đưa ra những kết luận về việcviết code có thể sẽ thành một trở ngại cho việc tạo ra các mô hình chính xác và đơngiản Giai đoạn xây dựng là một giai đoạn riêng biệt, nơi các mô hình được chuyểnthành code

1.5 Thử nghiệm:

Như đã trình bày trong phần Chu Trình Phát Triển Phần Mềm, một hệ thốngphần mềm thường được thử nghiệm qua nhiều giai đoạn và với nhiều nhóm thửnghiệm khác nhau Các nhóm sử dụng nhiều loại biểu đồ UML khác nhau làm nềntảng cho công việc của mình: Thử nghiệm đơn vị sử dụng biểu đồ lớp (classdiagram) và đặc tả lớp, thử nghiệm tích hợp thường sử dụng biểu đồ thành phần(component diagram) và biểu đồ cộng tác (collaboration diagram), và giai đoạn thửnghiệm hệ thống sử dụng biểu đồ Use case (use case diagram) để đảm bảo hệthống có phương thức hoạt động đúng như đã được định nghĩa từ ban đầu trongcác biểu đồ này

2 CÁC THÀNH PHẦN CỦA NGÔN NGỮ UML

Ngôn ngữ UML bao gồm một loạt các phần tử đồ họa (graphic element) cóthể được kếp hợp với nhau để tạo ra các biểu đồ Bởi đây là một ngôn ngữ, nênUML cũng có các nguyên tắc để kết hợp các phần tử đó

Một số những thành phần chủ yếu của ngôn ngữ UML:

 Hướng nhìn (view): Hướng nhìn chỉ ra những khía cạnh khác nhau của hệthống cần phải được mô hình hóa Một hướng nhìn không phải là một bản vẽ,

mà là một sự trừu tượng hóa bao gồm một loạt các biểu đồ khác nhau Chỉqua việc định nghĩa của một loạt các hướng nhìn khác nhau, mỗi hướng nhìnchỉ ra một khía cạnh riêng biệt của hệ thống, người ta mới có thể tạo dựngnên một bức tranh hoàn thiện về hệ thống Cũng chính các hướng nhìn này

nối kết ngôn ngữ mô hình hóa với quy trình được chọn cho giai đoạn pháttriển.

 Biểu đồ (diagram): Biểu đồ là các hình vẽ miêu tả nội dung trong một hướngnhìn UML có tất cả 9 loại biểu đồ khác nhau được sử dụng trong những sựkết hợp khác nhau để cung cấp tất cả các hướng nhìn của một hệ thống

 Phần tử mô hình hóa (model element): Các khái niệm được sử dụng trong cácbiểu đồ được gọi là các phần tử mô hình, thể hiện các khái niệm hướng đốitượng quen thuộc Ví dụ như lớp, đối tượng, thông điệp cũng như các quan

hệ giữa các khái niệm này, bao gồm cả liên kết, phụ thuộc, khái quát hóa.Một phần tử mô hình thường được sử dụng trong nhiều biểu đồ khác nhau,nhưng nó luôn luôn có chỉ một ý nghĩa và một kí hiệu

 Cơ chế chung: Cơ chế chung cung cấp thêm những lời nhận xét bổ sung, cácthông tin cũng như các quy tắc ngữ pháp chung về một phần tử mô hình;chúng còn cung cấp thêm các cơ chế để có thể mở rộng ngôn ngữ UML chophù hợp với một phương pháp xác định (một quy trình, một tổ chức hoặc mộtngười dùng)

3 KHUNG NHÌN (VIEW)

Mô hình hóa một hệ thống phức tạp là một việc làm khó khăn Lý tưởng nhất

là toàn bộ hệ thống được miêu tả chỉ trong một bản vẽ, một bản vẽ định nghĩa mộtcách rõ ràng và mạch lạc toàn bộ hệ thống, một bản vẽ ngoài ra lại còn dễ giao tiếp

và dễ hiểu Mặc dù vậy, thường thì đây là chuyện bất khả thi Một bản vẽ không thểnắm bắt tất cả các thông tin cần thiết để miêu tả một hệ thống Một hệ thống cầnphải được miêu tả với một loạt các khía cạnh khác nhau: Về mặt chức năng (cấutrúc tĩnh của nó cũng như các tương tác động), về mặt phi chức năng (yêu cầu vềthời gian, về độ đáng tin cậy, về quá trình thực thi, v.v và v.v.) cũng như về khíacạnh tổ chức (tổ chức làm việc, ánh xạ nó vào các code module, ) Vì vậy một hệthống thường được miêu tả trong một loạt các hướng nhìn khác nhau, mỗi hướngnhìn sẽ thể hiện một bức ảnh ánh xạ của toàn bộ hệ thống và chỉ ra một khía cạnhriêng của hệ thống

Hình 3.1: Các khung nhìn trong UML

Mỗi một khung nhìn được miêu tả trong một loạt các biểu đồ, chứa đựng cácthông tin nêu bật khía cạnh đặc biệt đó của hệ thống Trong thực tế khi phân tích vàthiết kế rất dễ xảy ra sự trùng lặp thông tin, cho nên một biểu đồ trên thật tế có thể

là thành phần của nhiều hướng nhìn khác nhau Khi nhìn hệ thống từ nhiều hướngnhìn khác nhau, tại một thời điểm có thể người ta chỉ tập trung vào một khía cạnhcủa hệ thống Một biểu đồ trong một hướng nhìn cụ thể nào đó cần phải đủ độ đơngiản để tạo điều kiện giao tiếp dễ dàng, để dính liền với các biểu đồ khác cũng nhưcác hướng nhìn khác, làm sao cho bức tranh toàn cảnh của hệ thống được miêu tảbằng sự kết hợp tất cả các thông tin từ tất cả các hướng nhìn Một biểu đồ chứa các

kí hiệu hình học mô tả các phần tử mô hình của hệ thống UML có tất cả các hướngnhìn sau:

 Khung nhìn Use case (use case view): đây là hướng nhìn chỉ ra khíacạnh chức năng của một hệ thống, nhìn từ hướng tác nhân bên ngoài.Đóng một vai trò đặc biệt đối với kiến trúc Nó chứa một vài kịch bảnhay use case chủ yếu, dùng để khám phá và thiết kế kiến trúc và xácnhận các khung nhìn khác nhau Khung nhìn này có thể sử dụng sơ đồuse case để minh hoạ

 Khung nhìn logic (logical view): chỉ ra chức năng sẽ được thiết kế bêntrong hệ thống như thế nào, Mô tả các yêu cầu chức năng của hệthống, Sự trừu tượng của mô hình thiết kế và xác định các gói thiết kếchính, các subsystem và lớp chính Trong UML khung nhìn này có thểđược trình bày dùng sơ đồ lớp, sơ đồ đối tượng, sơ đồ mô tả các gói,

hệ thống con

 Khung nhìn thực hiện (implementation view): chỉ ra khía cạnh tổ chứccủa các thành phần code Mô tả tổ chức của các đơn thể (module)phần mềm tĩnh (như mã nguồn, tập tin dữ liệu, thành phần, tập tinthực thi, và các thành phần kèm theo khác) trong môi trường pháttriển Dùng sơ đồ thành phần để trình bày

 Khung nhìn xử lý (process view): Mô tả các khía cạnh xảy ra đồng thờicủa hệ thống thời gian thực (run-time) (tasks, threads, processes ).Tập trung vào sự đồng hành, song song, khởi động và đóng hệ thống,khả năng chịu đựng hư hỏng, và sự phân tán các đối tượng chỉ ra sựtồn tại song song/ trùng hợp trong hệ thống, hướng đến vấn đề giaotiếp và đồng bộ hóa trong hệ thống

 Khung nhìn triển khai (deployment view): chỉ ra khía cạnh triển khai hệthống vào các kiến trúc vật lý (các máy tính hay trang thiết bị được coi

là trạm cộng tác) Cho thấy các tập tin thực thi và các thành phần khácnhau được triển khai trên các hệ thống như thế nào Nó giải quyết cácvấn đề như triển khai, cài đặt, và tốc độ Trong UML, khung nhìn này

có thể sử dụng sơ đồ triển khai để mô tả

Khi bạn chọn công cụ để vẽ biểu đồ, hãy chọn công cụ nào tạo điều kiện dễdàng chuyển từ hướng nhìn này sang hướng nhìn khác Ngoài ra, cho mục đích quansát một chức năng sẽ được thiết kế như thế nào, công cụ này cũng phải tạo điềukiện dễ dàng cho bạn chuyển sang hướng nhìn Use case (để xem chức năng nàyđược miêu tả như thế nào từ phía tác nhân), hoặc chuyển sang hướng nhìn triểnkhai (để xem chức năng này sẽ được phân bố ra sao trong cấu trúc vật lý - Nói mộtcách khác là nó có thể nằm trong máy tính nào)

Ngoài các hướng nhìn kể trên, ngành công nghiệp phần mềm còn sử dụng cả cáchướng nhìn khác, ví dụ hướng nhìn tĩnh-động, hướng nhìn logic-vật lý, quy trìnhnghiệp vụ (workflow) và các hướng nhìn khác UML không yêu cầu chúng ta phải sửdụng các hướng nhìn này, nhưng đây cũng chính là những hướng nhìn mà các nhàthiết kế của UML đã nghĩ tới, nên có khả năng nhiều công cụ sẽ dựa trên các hướngnhìn đó

4.BIỂU ĐỒ (DIAGRAM)

Biểu đồ là các hình vẽ bao gồm các ký hiệu phần tử mô hình hóa được sắpxếp để minh họa một thành phần cụ thể hay một khía cạnh cụ thể của hệ thống.Một mô hình hệ thống thường có nhiều loại biểu đồ, mỗi loại có nhiều biểu đồ khácnhau Một biểu đồ là một thành phần của một hướng nhìn cụ thể; và khi được vẽ ra,

nó thường thường cũng được xếp vào một hướng nhìn Mặt khác, một số loại biểu

đồ có thể là thành phần của nhiều hướng nhìn khác nhau, tùy thuộc vào nội dungcủa biểu đồ

Phần sau miêu tả các khái niệm căn bản nằm đằng sau mỗi loại biểu đồ Tất

cả các chi tiết về biểu đồ, ngữ cảnh của chúng, ý nghĩa chính xác của chúng và sựtương tác giữa chúng với nhau được miêu tả chi tiết trong các chương sau (mô hìnhđối tượng – mô hình động) Các biểu đồ lấy làm ví dụ ở đây được lấy ra từ nhiều loại

hệ thống khác nhau để chỉ ra nét phong phú và khả năng áp dụng rộng khắp củaULM

4.1- Biểu đồ Use case (Use Case Diagram):

Một biểu đồ Use case chỉ ra một số lượng các tác nhân ngoại cảnh và mối liênkết của chúng đối với Use case mà hệ thống cung cấp Một Use case là một lời miêu

tả của một chức năng mà hệ thống cung cấp Lời miêu tả Use case thường là mộtvăn bản tài liệu, nhưng kèm theo đó cũng có thể là một biểu đồ hoạt động Các Usecase được miêu tả duy nhất theo hướng nhìn từ ngoài vào của các tác nhân (hành vicủa hệ thống theo như sự mong đợi của người sử dụng), không miêu tả chức năngđược cung cấp sẽ hoạt động nội bộ bên trong hệ thống ra sao Các Use case địnhnghĩa các yêu cầu về mặt chức năng đối với hệ thống

4.2- Biểu đồ đối tượng (Object Diagram)

Biểu diễn một cách trực quan các lớp (mức quan niệm, chỉ có thuộc tính,không có phương thức) hoặc các đối tượng (thế giới thực, hay còn gọi là các thựcthể) trong phạm vi bài toán (problem domain) Mô tả hướng nhìn tĩnh của một hệthống bằng các khái niệm lớp và mối liên hệ giữa chúng với nhau Mục đích là tạonền tảng cho các biểu diễn khác, thể hiện các khía cạnh khác của hệ thống (ví dụnhư trạng thái của đối tượng hay cộng tác động giữa các đối tượng, được chỉ ratrong các biểu đồ động)

4.3 Biểu đồ lớp (Class Diagram)

Là sơ đồ mô tả các lớp, các giao diện (interface) và các mối lien hệ giữachúng cho ta một khung nhìn tĩnh của các lớp trong mô hình Liên hệ “toàn thể bộphận” (Whole - part):

Aggregation: cho biết thể hiện của 1 lớp sẽ bao gồm hoặc chứa các thể hiệncủa lớp khác.

Composition: giống như aggregation, có thêm “cùng gắn kết” (coincidentlifetime, khi whole được tạo thì part cũng được tạo, khi whole bị xóa thì part cũng bịxóa)

4.4 Biểu đồ trạng thái (State Diagram)

Một biểu đồ trạng thái thường là một sự bổ sung cho lời miêu tả một lớp Nóchỉ ra tất cả các trạng thái mà đối tượng của lớp này có thể có, và những sự kiện(event) nào sẽ gây ra sự thay đổi trạng thái Một sự kiện có thể xảy ra khi một đốitượng tự gửi thông điệp đến cho nó - ví dụ như để thông báo rằng một khoảng thờigian được xác định đã qua đi – hay là một số điều kiện nào đó đã được thỏa mãn.Một sự thay đổi trạng thái được gọi là một sự chuyển đổi trạng thái (StateTransition) Một chuyển đổi trạng thái cũng có thể có một hành động liên quan, xácđịnh điều gì phải được thực hiện khi sự chuyển đổi trạng thái này diễn ra

Biểu đồ trạng thái không được vẽ cho tất cả các lớp, mà chỉ riêng cho nhữnglớp có một số lượng các trạng thái được định nghĩa rõ ràng và hành vi của lớp bịảnh hưởng và thay đổi qua các trạng thái khác nhau Biểu đồ trạng thái cũng có thểđược vẽ cho hệ thống tổng thể

4.5 Biểu đồ trình tự (Sequence Diagram)

Một biểu đồ trình tự chỉ ra một cộng tác động giữa một loạt các đối tượng.Khía cạnh quan trọng của biểu đồ này là chỉ ra trình tự các thông điệp (message)được gửi giữa các đối tượng Nó cũng chỉ ra trình tự tương tác giữa các đối tượng,điều sẽ xảy ra tại một thời điểm cụ thể nào đó trong trình tự thực thi của hệ thống.Các biểu đồ trình tự chứa một loạt các đối tượng được biểu diễn bằng các đườngthẳng đứng Trục thời gian có hướng từ trên xuống dưới trong biểu đồ, và biểu đồchỉ ra sự trao đổi thông điệp giữa các đối tượng khi thời gian trôi qua Các thôngđiệp được biểu diễn bằng các đường gạch ngang gắn liền với mũi tên (biểu thị thôngđiệp) nối liền giữa những đường thẳng đứng thể hiện đối tượng Trục thời gian cùngnhững lời nhận xét khác thường sẽ được đưa vào phần lề của biểu đồ

4.6 Biểu đồ cộng tác (Collaboration Diagram)

Một biểu đồ cộng tác chỉ ra một sự cộng tác động, cũng giống như một biểu

đồ trình tự Thường người ta sẽ chọn hoặc dùng biểu đồ trình tự hoặc dùng biểu đồcộng tác Bên cạnh việc thể hiện sự trao đổi thông điệp (được gọi là tương tác), biểu

đồ cộng tác chỉ ra các đối tượng và quan hệ của chúng (nhiều khi được gọi là ngữcảnh) Việc nên sử dụng biểu đồ trình tự hay biểu đồ cộng tác thường sẽ được quyếtđịnh theo nguyên tắc chung sau: Nếu thời gian hay trình tự là yếu tố quan trọngnhất cần phải nhấn mạnh thì hãy chọn biểu đồ trình tự; nếu ngữ cảnh là yếu tố

quan trọng hơn, hãy chọn biểu đồ cộng tác Trình tự tương tác giữa các đối tượngđược thể hiện trong cả hai loại biểu đồ này.

Biểu đồ cộng tác được vẽ theo dạng một biểu đồ đối tượng, nơi một loạt cácđối tượng được chỉ ra cùng với mối quan hệ giữa chúng với nhau (sử dụng những kýhiệu như trong biểu đồ lớp/ biểu đồ đối tượng) Các mũi tên được vẽ giữa các đốitượng để chỉ ra dòng chảy thông điệp giữa các đối tượng Các thông điệp thườngđược đính kèm theo các nhãn (label), một trong những chức năng của nhãn là chỉ rathứ tự mà các thông điệp được gửi đi Nó cũng có thể chỉ ra các điều kiện, chỉ ranhững giá trị được trả về, v.v Khi đã làm quen với cách viết nhãn, một nhà pháttriển có thể đọc biểu đồ cộng tác và tuân thủ theo dòng thực thi cũng như sự traođổi thông điệp Một biểu đồ cộng tác cũng có thể chứa cả các đối tượng tích cực(active objects), hoạt động song song với các đối tượng tích cực khác

4.7 Biểu đồ hoạt động (Activity)

Một biểu đồ hoạt động chỉ ra một trình tự lần lượt của các hoạt động(activity) Biểu đồ hoạt động thường được sử dụng để miêu tả các hoạt động đượcthực hiện trong một thủ tục, mặc dù nó cũng có thể được sử dụng để miêu tả cácdòng chảy hoạt động khác, ví dụ như trong một Use case hay trong một trình tựtương tác Biểu đồ hoạt động bao gồm các trạng thái hành động, chứa đặc tả củamột hoạt động cần phải được thực hiện (một hành động - action) Một trạng tháihành động sẽ qua đi khi hành động được thực hiện xong (khác với biểu đồ trạngthái: một trạng thái chỉ chuyển sang trạng thái khác sau khi đã xảy ra một sự kiện

rõ ràng !) Dòng điều khiển ở đây chạy giữa các trạng thái hành động liên kết vớinhau Biểu đồ còn có thể chỉ ra các quyết định, các điều kiện, cũng như phần thựcthi song song của các trạng thái hành động Biểu đồ ngoài ra còn có thể chứa cácloại đặc tả cho các thông điệp được gửi đi hoặc được nhận về, trong tư cách làthành phần của hành động được thực hiện

4.8 Biểu đồ thành phần (Component Diagram)

Một biểu đồ thành phần chỉ ra cấu trúc vật lý của các dòng lệnh (code) theokhái niệm thành phần code Một thành phần code có thể là một tập tin source code,một thành phần nhị phân (binary) hay một thành phần thực thi được (executable).Một thành phần chứa các thông tin về các lớp logic hoặc các lớp mà nó thi hành,như thế có nghĩa là nó tạo ra một ánh xạ từ hướng nhìn logic vào hướng nhìn thànhphần Biểu đồ thành phần cũng chỉ ra những sự phụ thuộc giữa các thành phần vớinhau, trợ giúp cho công việc phân tích hiệu ứng mà một thành phần được thay đổi

sẽ gây ra đối với các thành phần khác Thành phần cũng có thể được miêu tả với

bất kỳ loại giao diện nào mà chúng bộc lộ, ví dụ như giao diện OLE/COM; và chúng

có thể được nhóm góp lại với nhau thành từng gói (package) Biểu đồ thành phầnđược sử dụng trong công việc lập trình cụ thể

4.9 Biểu đồ triển khai (Deplopment Diagram)

Là sơ đồ mô tả kiến trúc hệ thống phần cứng và giao thức và các nodes (máy tính,máy in,…) trao đổi thông điệp với nhau

Chương 4: Công cụ Rational Rose (Rose)

I Giới thiệu về Rational Rose.

1 Rational Rose là gì?

Rational Rose là phần mềm công cụ mạnh hỗ trợ cho quá trình phân tích,thiết kế hệ thống hướng đối tượng Nó giúp cho việc mô hình hoá hệ thống trước khiviết chương trình, đồng thời có khả năng kiểm tra đảm bảo tính đúng đắn, hợp lýcủa kiến trúc hệ thống từ khi khởi đầu dự án Sử dụng mô hình này, bạn có thể bắtlỗi trong quá trình thiết kế, trong lúc này chúng không tốn kém để ta sửa chữa

Rational Rose hỗ trợ mô hình thương mại, giúp bạn hiểu được các công việcdiễn ra trên hệ thống Nó giúp hệ thống phân tích bằng cách cho phép bạn thiết kếcác trường hợp sử dụng và sử dụng lược đồ Use Case để hiển thị các chức năng của

hệ thống Nó cho phép bạn thiết kế sơ đồ tương tác với hệ thống và từ đó hiển thịcác đối tượng làm việc cùng nhau để cung cấp các chức năng cần thiết Sơ đồ lớp cóthể được tạo ra để hiển thị các lớp trong một hệ thống và các mối quan hệ ràngbuộc có liên quan Biểu đồ thành phần (Component Diagram) là biểu đồ mô tả cácthành phần và sự phụ thuộc của chúng trong hệ thống Và cuối cùng biểu đồ triểnkhai (Deployment Diagram) chỉ ra cấu hình các phần tử xử lý lúc chương trình chạy,các nút trên mạng và các tiến trình phần mềm thực hiện trên những phần tử đó

Mô hình Rose là 1 bức tranh toàn cảnh về hệ thống với những mô phỏng khác nhau,

nó bao gồm tất cả các biểu đồ UML như biểu đồ ca sử dụng biểu đồ lớp, trình tự,trạng thái, hoạt động, cộng tác và giải quyết các mâu thuẫn trong hệ thống Nó mô

tả rất chi tiết những gì mà hệ thống đang thực hiện và sẽ thực hiện như thế nào, do

đó thì các các nhà phát triển sử dụng mô hình này như là xây dựng một kế hoạchchi tiết cho hệ thống

Tuy nhiên, các nhà phát triển không phải là những người duy nhất sử dụng

mô hình:

 Toàn bộ đội ngũ trong nhóm kinh doanh sẽ sử dụng sơ đồ trường hợp

để có được một sự hiểu biết của các doanh nghiệp xung quanh hệthống

 Khách hàng và nhà quản lý dự án sẽ sử dụng sơ đồ trường hợp để cóđược một cái nhìn tổng quát của hệ thống và bao quát về phạm vi dựán

 Bộ phận kỹ thuật sẽ xem xét trường hợp sử dụng các tài liệu hướngdẫn để bắt đầu viết bản hướng dẫn sử dụng, lên kế hoạch tập huấn