Tìm hiểu công cụ phân tích thiết kế hệ thống hướng đối tượng bằng UML và ứng dụng vào hệ thống save home

 OMT the Object Modeling Technique: công nghệ mô hình hoá đối tợng là một phơng pháp đợc phát triển khi ngời ta phát minh ra điện học, lúc đó James Rumbaugh đang làm việc, một tiến trìn

Lời nói đầu

Nếu nh trớc đây khi Công Nghệ Thông Tin cha phổ biến, thì yêu cầu của một ngời làm tin học hầu nh chỉ cần biết, nắm vững và làm chủ ngôn ngữ lập trình là đủ thì ngày nay những yêu cầu đó lại cao hơn, để tạo ra đợc những phần mềm đáp ứng đợc những yêu cầu của ngời sử dụng thì ngời làm trong nghành Công Nghệ Thông Tin

không những biết đợc những cái đó mà ngoài ra còn phải có khả năng hiểu, phân tích và nắm bắt đợc những yêu cầu công việc cụ thể của hệ thống, của ngời sử dụng để từ đó xây dựng, thiết kế nên những phần mềm hiệu quả nhất Để làm đợc nh vậy anh ta cần phải có tri thức về hệ thống, về phân tích và thiết kế hệ thống.

Hiện nay có hai xu hớng phân tích thiết kế hệ thống chính đó là: phân tích thiết

kế hệ thống theo hớngchức năng và phân tích và thiết kế hệ thống theo hớng đối ợng, mỗi hớng phân tích đều có những yêu điểm và nhợc điểm riêng, tuỳ theo từng hệ thống cụ thể mà ngời ta dùng hớng phân tích này hay hớng phân tích khác Phân tích và thiết kế hệ thống theo hớng chức năng thì dễ phân tích và thiết kế nhng lại không mô tả đợc những hệ thống thời gian thực, còn phân tích và thiết kế hệ thống theo hớng

t-đối tợng tuy hơi khó thực hiện song nó lại mô tả đợc các hệ thống thời gian thực, vì vậy ngày nay ngời ta hay dùng hớng phân tích và thiết kế hệ thống theo hớng này

Đề tài tốt nghiệp “Phân tích thiết kế hệ thống theo hớng đối tợng bằng công cụ

UML” này bàn về một số vấn đề cơ bản của phân tích thiết kế hệ thống theo h ớng

đối tợng, về công cụ dùng để phân tích và thiết kế là UML, cuối cùng là dùng UML

để phân tích thiết kế một hệ thống thời gian thực.

Cuối cùng em xin chân thành cảm ơn các thầy cô trong khoa Công Nghệ Thông Tin đặc biệt là thầy giáo Lê Văn Minh đã chỉ bảo, dìu dắt rất nhiệt tình cho em

để em hoàn thành đợc đề tài này Trong quá trình thực hiện bản thân đã có rất nhiều

cố gắng song do nhiều yếu tố nên đề tài còn có nhiều mặt hạn chế, vì thế em rất mong có sự chỉ bảo của các thầy các cô và những góp ý của các bạn để đề tài ngày một hoàn thiện hơn.

Sinh viên: Nguyễn Thị Thu Hơng

Lớp: 40B - CNTTmục lục

Phần I : Các vấn đề chung

I Yêu cầu, lý do chọn đề tài và phạm vi của đề tài …… ………… 5

1.1 Yêu cầu của đề tài ……… ……… 5

1.2 Lý do chọn đề tài………… ……… 5

1.3 Phạm vi của đề tài ……… ……… 5

II Đánh giá giữa phân tích thiết kế theo hớng chức năng và hớng đối tợng ……… 5

2.1. Ưu nhợc điểm của phân tích thiết kế hệ thống theo hớng chức năng ………6

2.2 Ưu nhợc điểm của phân tích và thiết kế hệ thống theo hớng đối t-ợng ……… 6

2.3 Nhận xét ……… ……… 7

phần II: công cụ UML chơng I: Khái niệm về UML 1.1 Mở đầu ……….8

1.2 Mô hình ngôn ngữ hợp nhất (UML) ………9

1.3 Mô hình hoá các phơng pháp và các ngôn ngữ ……… 13

1.4 Phát triển phần mềm hớng đối tợng ……….14

1.5 Sử dụng UML ……… 15

1.6 Các giai đoạn phát triển hệ thống ……….16

Chơng II: Các thành phần cơ bản của UML 2.1 Các view……… 18

2.2 Các sơ đồ ……….22

2.3 Các cơ chế chung…… ………29

2.4. UML mở rộng………31

2.5 Mô hình hoá với UML ……… 33

Giáo viên hớng dẫn ThS: Lê Văn Minh Thực hiện: Nguyễn Thị Thu Hơng

2.6 Các công cụ ……… 35

Chơng III: Mô hình hoá use-case 3.1 Các khái niệm ……….45

3.2 Sơ đồ use-case ……….47

3.3 Hệ thống …… ……… 47

3.4 Những tác nhân gây ra hành động ………48

3.5 Các trờng hợp sử dụng……….49

3.6 Các mô tả các trờng hợp sử dụng……….54

3.7 Kiểm tra các trờng hợp sử dụng……… 57

chơng IV: Các lớp, đối tợng và mối quan hệ của chúng 4.1 Các lớp và đối tợng ……….62

4.2 Các mối quan hệ ……… 70

chơng V: Mô hình động 5.1 Mở đầu ……… 93

5.2 Sự tơng tác giữa các đối tợng ……….94

5.3 Sơ đồ trạng thái ……… 95

5.4 Gửi các message giữa các sơ đồ trạng thái ……… 100

5.5 Sơ đồ tuần tự ……….102

5.6 Sơ đồ cộng tác ……… 105

5.7 Sơ đồ hoạt động ……… 110

5.8 Các khái niệm hệ thống thời gian thực ……… 114

5.8.1 Hớng đối tợng và các hệ thống thời gian thực……… 116

5.8.2 Các khái niệm thời gian thực ……… 118

5.8.3 Các lớp hoạt động và các đối tợng ………118

phần III: pttk hệ thống thời gian thực dùng UML

I Mô hình thời gian thực trong UML……….130

II PTTK hệ thống chuông báo động nhà dùng công cụ UML 130

1. Sơ đồ trạng thái ………132

2. Sơ đồ tuần tự ………135

4. Sơ đồ cộng tác ……… 138

5 Sơ đồ thành phần và triển khai ………… … ……… 140

Giáo viên hớng dẫn ThS: Lê Văn Minh Thực hiện: Nguyễn Thị Thu Hơng

Phần I : các vấn đề chung

1.1 Yêu cầu của đề tài:

1.1.1 Tìm hiểu về công cụ trợ giúp trong việc phân tích thiết kế hệ thống theo hớng

đối tợng là công cụ UML (Unified Modeling Language)

1.1.2 áp dụng UML để phân tích thiết kế hệ thống báo động nhà

1.2.Lý do chọn đề tài:

Hiện tại để có nhiều công cụ hỗ trợ cho kỹ s phần mềm trong việc xây dựng các

ứng dụng Các công cụ đó gọi là CASE (Computer of Aided Software Engineering)

có hiệu quả sử dụng cao nhng các lập trình viên vẫn đang đi theo hớng thiết kế cổ

điển

Mục đích của đề tài này một mặt giới thiệu với các lập trình viên một công cụ

hỗ trợ tốt trong việc phân tích thiết kế hệ thống theo hớng đối tợng, một hớng phântích thiết kế hệ thống hiện đại Một mặt ứng dụng công cụ đó để phân tích thiết hệ

thống báo động nhà (Save Home) Đó là công cụ UML.

1.3 Phạm vi của đề tài :

Do thời gian hạn hẹp nên đề tài này chỉ giới thiệu các thành phần cơ bản cầnthiết của công cụ UML, nhng nó cũng đủ để phân tích thiết kế một hệ thống

ở đây nêu rõ các thành phần của công cụ nh là các sơ đồ dùng để mô tả bài toán

và chi tiết của các sơ đồ Các sơ đồ đó mô tả bài toán dới dạng các lớp và các thuộctính của đối tợng

Cuối cùng đề tài sẽ phân tích thiết kế hệ thống báo động nhà Nhng do không đủthời gian và điều kiện nên hệ thống cha đợc cài đặt trên phần cứng và phần mềm cụthể Việc cài đặt sẽ đợc thực hiện khi đề tài này phát triển thêm

II đánh giá giữa phân tích thiết kế theo hớng chức năng và hớng đối tợng

Quá trình phân tích thiết kế hệ thống bao gồm hai quá trình: quá trình phân tích

và quá trình thiết kế Quá trình phân tích là quá trình trả lời cho câu hỏi What to

do?, hệ thống sẽ làm gì, quá trình này đợc làm ở mức logic của hệ thống Quá trình

thiết kế trả lời là quá trình trả lời cho câu hỏi How to do?, ngoài việc quan tâm đến

hệ thống sẽ làm gì thì quá trình này còn quan tâm đến hệ thống sẽ làm nh thế nào,quá trình thiết kế đợc làm ở mức vậy lý của hệ thống

Hiện nay có hai xu hớng phân tích và thiết kế hệ thống đó là: phân tích thiết kế

hệ thống theo hớng chức năng và theo hớng đối tợng, sau đây sẽ là một số u, nhợc

điểm của cả hai hớng phân tích thiết kế này

2.1 Ư u nhợc điểm của phân tích thiết kế hệ thống theo hớng chức năng.

Phân tích thiết kế theo hớng chức năng là tiếp cận hệ thống theo các chức năng.Các công cụ dùng để mô tả hệ thống nh là biểu đồ phân cấp chức năng, các biểu đồluồng dữ liệu, sơ đồ liên kết thực thể và các thuộc tính Ngôn ngữ cài đặt hệ thống là

các hệ quản trị cơ sở d liệu nh Foxpro, Fortran, v v

* Ưu điểm : - trực quan, dễ thu thập dữ liệu, dễ kiểm tra và đánh giá

- dễ phân tích và thiết kế

- thích hợp với các ứng dụng xử lý theo lô

* Nh ợc điểm : - không xử lý đợc các ứng dụng trực tuyến và thời gian thực

- không có tính sử dụng lại

- khó mở rộng

2.2 Ư u nhợc điểm của phân tích thiết kế hệ thống theo hớng đối tợng.

Phân tích thiết kế hệ thống theo hớng đối tợng là tiếp cận hệ thống theo các

đối tợng gồm các thuộc tính và các phơng thức thao tác trên các thuộc tính đócủa đối tợng Công cụ để mô tả bài toán là các lớp đợc phân cấp và kế thừa.Ngôn ngữ cài đặt là các ngôn ngữ lập trình hớng đối tợng nh C++ , Java, Visual

C ++ , v.v

* Ưu điểm : - Có khả năng mở rộng hệ thống dễ dàng

- Có tính sử dụng lại

- Mô tả đợc các ứng dụng trực tuyến và thời gian thực

* Nh ợc điểm : - Khó mô tả bài toán

Giáo viên hớng dẫn ThS: Lê Văn Minh Thực hiện: Nguyễn Thị Thu Hơng

Sau đây sẽ giới thiệu một công cụ dùng để phân tích thiết kế hệ thống theohớng đối tợng

Phần II : Công cụ UML

(Unified Modeling Language: mô hình ngôn ngữ hợp nhất)

vẽ nên cấu trúc công việc hiện tại Chi phí, thời gian ớc tính, sự phân bố công việc

và nguồn gốc cung cấp là cơ sở cho những thông tin chứa trong quá trình vẽ

Cái mà ta cần vẽ có sơ đồ và mô hình, một mô hình là một tập các quy tắc, màcác quy tắc đó có thể tồn tại trong một giai đoạn phát triển hoặc trong giai đoạn lập

kế hoạch Trong suốt quá trình hoạt động của một mô hình ngời thiết kế phải giámsát những kết quả đã hoàn thành xem có đúng với yêu cầu của mình không Nhữngyêu cầu đó thờng gồm: một chức năng tiện ích, một cách tiếp cận, hiệu suất, khảnăng phục vụ và độ tin cậy Ngời thiết kế phải tạo đợc một mô hình mà tất cả cácquy tắc có những khía cạnh kết quả khác nhau, mô hình đã đa đến một số quan

điểm cho rằng quy tắc lý tởng là kết quả hoặc sự cấu hình hệ thống, một mô hình cóthể qua nhiều giai đoạn, ở mỗi giai đoạn mô hình lại đợc chi tiết thêm

Quá trình tạo ra các mô hình là tạo ra các hoạt động ở mức cao, những ngờithiết kế mô hình làm việc lặp đi lặp lại nhiều lần để đảm bảo đó là những mô hình

đã đạt đến đích, hoặc là những yêu cầu của dự án đợc cấu trúc hoá Nhng một môhình không phải là cái cuối cùng, nó có thể thay đổi và có thể còn đợc cập nhật vàotrong dự án của chúng Những phơng án tốt thờng đã đạt đợc ở một trình độ caobằng những ý kiến và những cách giải quyết hay để tạo ra đợc những mô hình tốt vàchúng đã đợc kiểm tra Khi ngời thiết kế có nhiều khả năng khác nhau, họ đa ra sựhiểu biết sâu sắc về hệ thống và họ có thể tạo ra những mô hình của các hệ thống

đáp ứng đợc yêu cầu của ngời sử dụng

Các mô hình luôn đợc diễn tả bằng một ngôn ngữ trực quan với ý nghĩa rõràng Khi mô hình sử dụng những mô tả trực quan là cần thiết cho các liên kết đầy

đủ ở các mối quan hệ, nó cũng làm cho công việc mô hình hoá dễ dàng, mà không

Giáo viên hớng dẫn ThS: Lê Văn Minh Thực hiện: Nguyễn Thị Thu Hơng

điều gì có thể phù hợp hoàn toàn cho việc mô tả trực quan, tuy nhiên những thôngtin trong các mô hình đợc biểu diễn tốt ở các văn bản thông thờng Các mô hình cóthể sử dụng đợc là :

 Đúng đắn (Accurate): hệ thống với các quy luật đúng đắn đợc xây dựng

 Chắc chắn (Consistent): các quan điểm khác nhau không biểu hiện những vấn

đề mâu thuẫn lẫn nhau

 Dễ dàng liên lạc với những mô hình khác

 Dễ dàng thay đổi.

 Có thể hiểu đợc: là những vấn đề đơn giản nhng không sơ sài

Xu hớng của nhiều tổ chức công nghệ phần mềm là tạo ra những mô hình củanhững hệ thống mà chúng ta muốn đợc xây dựng Lập trình trực quan là một kỹthuật đợc làm bởi các chơng trình có cấu trúc, việc thu thập dữ liệu một cách trựcquan và các kiểu kết nối, các mô hình và các chơng trình đợc tích hợp ở mức cao.Các hệ thống đã trở nên lớn mạnh và phân tán trên rất nhiều máy tính ở kiến trúcclient/server, sự cần thiết của các hệ thống tích hợp đầy đủ trong môi trờng phântán, có những yêu cầu là hệ thống phải có những mô hình công việc kỹ thuật chung.Yêu cầu của những hệ thống máy tính đó là có những trợ giúp xử lý để thực hiệncác công việc của những mô hình Các mô hình của hệ thống phải đợc xây dựng tr-

ớc khi thực hiện, chúng sẽ trở thành bình thờng và đã đợc chấp nhận trong côngnghệ phần mềm nh trong các quy luật kỹ thuật khác

1.2 Mô hình ngôn ngữ hợp nhất UML (Unified Modeling Language):

Mô hình ngôn ngữ hợp nhất cố gắng giải quyết các vấn đề đã đợc mô tả chínhxác, UML có nhiều tiềm năng để xây dựng các mô hình nhờ vào phơng pháp hớng

 Booch: phơng pháp của Grady Booch có thể phát triển hớng đối tợng ở nhiều

cách khác nhau Booch đã định nghĩa và chú thích đó là một hệ thống đã đợc

phân tích trên một số khung nhìn, ở mỗi khung nhìn đợc mô tả bởi một số môhình sơ đồ Phơng pháp của Booch có nhiều ký hiệu rất rộng nhng chỉ vài ngời

sử dụng tìm thấy những ký hiệu đó, và rất nhiều trong chúng đợc vẽ bằng tay.Một phơng pháp cũng chứa đựng một tiến trình trên những hệ thống đã đợc phân

tích từ cả hai quan điểm phát triển là vĩ mô (macro) và vi mô (micro) đã là cơ sở

của sự phát triển và xử lý lặp ở mức cao

 OMT (the Object Modeling Technique): công nghệ mô hình hoá đối tợng là một phơng pháp đợc phát triển khi ngời ta phát minh ra điện học, lúc đó James

Rumbaugh đang làm việc, một tiến trình kiểm tra của nó thờng đợc xử lý một

cách trực tuyến, nó là cơ sở để thể hiện các yêu cầu, hệ thống đợc mô tả bởi một

số phơng pháp l: phơng pháp đối tợng, phơng pháp động lực học, phơng phápchức năng và phơng pháp sử dụng mô hình use-case Với nhiều phơng phápmới ta sẽ mô tả đợc hệ thống một cách đợc đầy đủ Phơng pháp OMT có nhiềumô tả đặc biệt trong việc định nghĩa hệ thống, đồng thời tạo tài khoản tơngtranh và ánh xạ liên kết tới các cơ sở dữ liệu

 OOSE / Objectory: công nghệ phần mềm hớng đối tợng và các phơng pháp

h-ớng đối tợng, cả hai đợc Ivan Jacobson xây dựng trên cơ sở khuôn dạng

ViewPoint, phơng pháp OOSE (I.Jacobson 1994) là một phiên bản của Jacobson

về phơng pháp hớng đối tợng, phơng pháp hớng đối tợng đã đợc sử dụng để xâydựng một số hệ thống nh là hệ thống thiết bị viễn thông và các hệ thống tài

chính cho công ty môi trờng, cả hai phơng pháp là cơ sở cho các use-case, với

việc định nghĩa về yêu cầu ban đầu của hệ thống sẽ đợc mở rộng bởi các tác

nhân (actors) Các use-case thực hiện trong nhiều giai đoạn của quá trình phát

triển, các giai đoạn kiểm tra hệ thống, khi đó họ đã sử dụng để chỉnh sửa hệthống, đối tợng cũng đợc đa vào các công việc kỹ thuật, khi những ý kiến đợc sửdụng trong mô hình để thúc đẩy việc xử lý

 Fusion (sự hợp nhất): Các phơng pháp hợp nhất đợc Hewleft - Packard

(D.coleman 1994) đa ra, nó đợc gọi là phơng pháp thế hệ thứ hai, bởi vì nó là cơ

sở mà các phơng pháp ban đầu đã đi qua Phơng pháp hợp nhất đã đợc nâng cấp

từ một số ý kiến quan trọng trớc, bao gồm các kỹ thuật thể hiện các phơng thức

và sự tơng tác giữa các đối tợng, phơng pháp này có một số lớn các biểu đồ môhình

Giáo viên hớng dẫn ThS: Lê Văn Minh Thực hiện: Nguyễn Thị Thu Hơng

 Coad/Yourdon: Phơng pháp Coad/Yourdon cũng đợc biết nh là phân tích thiết

kế hớng đối tợng OOA/OOD Đó là một trong những phơng pháp đầu tiên sửdụng cho phân tích và thiết kế hớng đối tợng Phơng pháp này đơn giản, dễ học,

và có giới hạn những ý kiến và thuật ngữ của kỹ thuật hớng đối tợng, tuy nhiênnhững chú thích và phơng pháp đó có thể không đợc tăng cờng, nhng các hệthống đó đã bị hạn chế rất nhiều, do đó các phơng pháp này ngày nay ít đợc sửdụng

Mỗi một phơng pháp có những ký hiệu (chú thích) riêng của chúng (các ký hiệu

đợc dùng để vẽ lên mô hình hớng đối tợng), cách xử lý (với sự kích hoạt thực hiệnnhững phần khác nhau của quá trình phát triển ), và các công cụ (công cụ CASE: kỹthuật phần mềm có sự trợ giúp của máy tính) khác nhau, để lựa chọn đợc một phơngpháp, một quyết định quan trọng thờng phải có các cuộc tranh luận, thảo luận sôi nổihơn để tìm ra phơng pháp tốt nhất, tiến bộ nhất và đúng nhất Các phơng pháp đợc

sử dụng để diễn tả một dự án, ở mỗi phơng pháp lại có những u điểm khác nhau, vìvậy để có một phơng pháp tốt thì cần phải hợp nhất nhiều phơng pháp ấy lại, nhng ai

sẽ tìm kiếm và hợp nhất các phơng pháp này lại?

1.2.2 UML

Grady booch và James Rumbaugh đã hợp lý hoá các liên đoàn phần mềm và

bắt đầu làm việc trên UML năm 1994, kết quả đó tạo ra một phơng pháp mới gọi là

“các phơng pháp hợp nhất”, nó sẽ hợp làm một Từ phơng pháp Booch và phơng

pháp OMT-2 của Rumbaugh đã hớng dẫn phát triển, năm 1995 Ivan Jacobson, một

ngời luôn theo dõi công nghệ phần mềm hớng đối tợng và kết nối các phơng pháp ớng đối tợng với nhau Các phần mềm hệ thống hớng đối tợng hợp lý cũng đã đợcbán cho một công ty ở Thụy Điển, công ty này đang phát triển và đã phân bố các đốitợng, đây là một điểm phát triển mới cho tơng lai của UML và đợc nhận thức rõ việc

h-tập trung trực tiếp để tạo ra một mô hình ngôn ngữ chuẩn có tên là “ Unified

Modeling Language (UML): mô hình ngôn ngữ hợp nhất ” Tiếp theo trong quá trình

thành lập một mô hình ngôn ngữ chuẩn giống nh một nhiệm vụ đơn giản là làm cáccông việc của một tiến trình từ một tiến trình khác Đó là tất cả các vấn đề tạo ra mộttiến trình chuẩn mà mọi ngời đều có thể dùng đợc

Booch Rumbaugh và Jacobson tách ra một số điều khoản khác nhau của UML

tới hớng đối tợng phổ biến, từ đó có rất nhiều ý kiến, gợi ý chặt chẽ để cải tiến ngônngữ Phiên bản 1.0 của UML đã phát hành trong năm 1997

Cho dù các phần chính của UML là cơ sở của Booch Các phơng pháp OMT vàOOSE đã đợc định nghĩa gồm các khái niệm từ nhiều phơng pháp khác nhau, cácphần của sự hợp nhất chú thích cho một số phơng thức đã có trong sơ đồ Mục đíchcủa UML là các trạng thái đợc định nghĩa nh sau:

 Mô hình hệ thống (không phải hoàn toàn là phần mềm) sử dụng các khái niệmhớng đối tựơng

 Thành lập một sự kết nối rõ ràng

 Chỉ ra đợc địa chỉ của kích thớc kế thừa đầy đủ về nhiệm vụ- chức năng của hệthống

 Tạo một mô hình ngôn ngữ sử dụng cả yếu tố con ngời và máy móc

UML đã đi đến sự bao quát, mô hình ngôn ngữ chung đã đợc sử dụng bởi một sốngành công nghiệp, nó có phạm vi sử dụng rộng, nó đợc xây dựng trong quá trìnhthành lập và đợc thử thách bởi kỹ thuật mô hình hệ thống và đợc ngành công nghiệptrợ giúp những thiết bị để thành lập một chuẩn trong thực tế, UML cũng có nhiều tàiliệu tốt với mô hình lớn của ngôn ngữ và với các dạng ngữ nghĩa đặc biệt của ngônngữ

1.2.3 Sự chấp nhận UML

Thành lập UML, phát triển và thực hiện hợp lý hoá ngôn ngữ để mọi ngời có thểdùng đợc, tuy nhiên ngôn ngữ không có quyền sở hữu và không thể tự do sử dụngcác phơng pháp của chúng mà phải có công cụ trợ giúp, các nhà cung cấp các công

cụ tự do tạo ra công cụ CASE cho nó, và họ còn khuyến khích viết ra những cuốnsách về nó

Trong suốt năm 1996 một số tổ chức đã kết hợp hợp lý từ một số phần củaUML, các tổ chức này đã giới hạn trạng thái công việc của UML đang sẵn sàng gópphần để định nghĩa nên UML, tất nhiên chúng có quan tâm phạm vi mà chúng đang

có để định nghĩa công việc một cách thành thạo Các công ty khác nhau trong tháng

1 năm 1997 đã đa ra những thiết bị kỹ thuật số HP, I-Logix, máy tính IBM, INCON,các hệ thống mã MCI, Microsoft, Oracle, công cụ Unisys, và các tiến trình hợp lý

Giáo viên hớng dẫn ThS: Lê Văn Minh Thực hiện: Nguyễn Thị Thu Hơng

(Rational), các công ty cũng đã có những đề nghị để đa vào UML nh là: quản lý đối

tợng theo nhóm (OMG) chuẩn cho mô hình ngôn ngữ

1.2.4 Tiêu chuẩn quản lý đối tợng theo nhóm (OMG standardization):

Khi bắt đầu làm việc với UML có những tiêu chuẩn thực tế, nó đang đợc sửdụng và phát triển, nó đã đợc công nhận và đang đứng đầu trong mô hình ngôn ngữ.Tuy nhiên khi OMG đa ra những yêu cầu cho một mô hình ngôn ngữ chuẩn thìUML đã công nhận sự phát triển đó, nên họ có thể đợc UML công nhận nh mộtdạng chuẩn, khi đó phải có những yêu cầu cao về sự chính xác và sự xác định cácdạng của UML và ngôn ngữ đang đợc cải tiến nhanh chóng Các dạng tiêu chuẩn rấtquan trọng cho nhiều ngành công nghiệp trớc khi họ tự nguyện sử dụng công nghệmới Đó là sự phát triển của những hệ thống nhỏ, hiện tại OMG đã đợc UML quyết

định dùng nh là một chuẩn của chúng

1.3 Các phơng pháp và mô hình ngôn ngữ :

Đây là những vấn đề quan trọng giữa một phơng pháp và một mô hình ngôn ngữ.Một phơng pháp là sự cấu trúc một cách rõ ràng về một ý kiến hay hành động nào

đó, ngời sử dụng một phơng pháp sẽ làm gì, làm nh thế nào và tại sao lại làm (mục

đích là thể hiện sự nhạy bén), các phơng pháp chứa các mô hình và mỗi mô hình sẽ

đợc sử dụng để mô tả một chút về kết quả liên kết khi sử dụng phơng pháp, cái khácnhau chính giữa các phơng pháp và mô hình ngôn ngữ đó là : mô hình ngôn ngữthiếu một tiến trình hoặc là kiến thức cung cấp để làm gì, làm nh thế nào, khi nàolàm và tại sao lại làm

Khi chúng ta xây dựng các mô hình thì tức là chúng ta đã cấu trúc nên những ýkiến của chính mình, một mô hình luôn là một mô hình của cái gì đó và nó có mộtmục tiêu, nếu mô hình không có nục tiêu rõ ràng thì nó sẽ sinh ra các vấn đề, bởi vìkhông ai biết đợc thế nào và tại sao lại sử dụng nó Một mô hình đợc diễn đạt trongmột mô hình ngôn ngữ, một mô hình ngôn ngữ gồm có các chú thích, các ký hiệu đ-

ợc sử dụng trong các mô hình là một tập các quy tắc, nhằm sử dụng nó nh thế nào.Các quy tắc có các cú pháp, ngữ nghĩa và có thực tế

Cú pháp cho ta biết các ký hiệu nào sẽ giống ký hiệu nào trong mô hình ngônngữ đã đợc tổ hợp, các ký hiệu đợc so sánh với các từ của ngôn ngữ tự nhiên, nó rấtquan trọng để chúng ta biết điều chỉnh cách phát âm và đặt từ khác nhau vào trongcâu nh thế nào Các quy tắc ngữ nghĩa sẽ nói cho chúng ta biết ý nghĩa của ký hiệu

là gì, nó sẽ tự giải thích nh thế nào và trong ngữ cảnh của các ký hiệu khác, chúng

đ-ợc so sánh với các nghĩa khác nhau trong các từ khác nhau của ngôn ngữ tự nhiên.Thực tế định nghĩa các quy tắc là có sự định nghĩa trớc các ký hiệu với mục đíchcủa mô hình đã đạt đợc và hiểu đợc, đây là các quy tắc tơng ứng trong ngôn ngữ tựnhiên cho việc cấu trúc câu, nó rõ ràng và có thể hiểu đợc

Sử dụng một mô hình ngôn ngữ tốt rất cần thiết để tìm hiểu tất cả các quy tắc,các Message tốt hơn Có phải là UML dễ dàng hiểu đợc hơn một ngôn ngữ tự nhiên.Nhiều mô hình ngôn ngữ chỉ bao phủ đợc cú pháp và ngữ nghĩa, thực tế nó khôngthể đợc chính thức hóa nên rất khó mô tả, nó chỉ có thể thao tác nh một dòng hớngdẫn Trong tự nhiên khi ngôn ngữ đa ra là cơ bản thì nó sẽ không đảm bảo rằng cácmô hình đa ra là tốt

1.4 Phát triển phần mềm hớng đối tợng (OO):

Nh một mô hình ngôn ngữ hớng đối tợng, tất cả các thành phần và sơ đồ trongUML là cơ sở cho các mô hình hớng đối tợng, thể hiện trong cuốn sách này là cáckhái niệm hớng đối tợng khác nhau, vài thiết bị đọc hoàn toàn lạ đối với OO và kỹthuật ấy sẽ đọc vài lời giới thiệu của văn bản, tơng tự nh với các quan điểm hớng đốitợng khác nh là:

 Hớng đối tợng là một kỹ thuật dùng để tạo ra các mô hình, nó phản

ánh một phạm vi nh là phạm vi công việc, phạm vi máy móc, ở đây chúng ta

đang dùng kỹ thuật phạm vi

 Các mô hình OO khi cấu trúc đợc sửa đổi, nó dễ dàng liên kết, thay

đổi và mở rộng đợc, có thể làm cho phù hợp và kiểm tra đợc

 Khi đang sửa đổi, xây dựng các hệ thống sử dụng kỹ thuật OO có thểthay đổi một cách linh hoạt, có kiến trúc đã đợc định nghĩa tốt và cung cấp mộttuỳ chọn để tạo ra và thực hiện các thành phần tái sử dụng, yêu cầu đối với một

hệ thống là có thể tạo mã của hệ thống

 Các mô hình OO có thể thực hiện một cách tiện dụng trong phầnmềm sử dụng ngôn ngữ lập trình OO Tuy nhiên trong thực tế nó rất quan trọngcho công nghệ phần mềm hớng đối tợng hơn là bộ máy tính và ngôn ngữ lậptrình

 Không đúng nh lý thuyết nhng nó là một kỹ thuật đã đợc chứng minh

là tốt và đợc sử dụng ở một số dự án trong qúa trình xây dựng nhiều kiểu hệ

Giáo viên hớng dẫn ThS: Lê Văn Minh Thực hiện: Nguyễn Thị Thu Hơng

thống khác nhau, các trờng sẽ thiếu đi các tiêu chuẩn để chứng minh kỹ thuật

đối tợng, đây cũng là một cách để công nghiệp hóa OMG đã cố gắng hoànthành các công việc đã đợc giao nh là một tiêu chuẩn

 Một phơng pháp yêu cầu tổ chức đối tợng đó là: hợp nhất một tiếntrình phát triển và một mô hình ngôn ngữ với công cụ, kỹ thuật có cấu trúc phùhợp

1.5 Sử dụng UML :

UML đợc sử dụng để mô hình các hệ thống với các giới hạn: Nhiều kiểu hệthống khác nhau có thể đã đợc mô tả, UML cũng đợc dùng trong các giai đoạn pháttriển khác nhau của một hệ thống, từ các yêu cầu thể hiện việc kiểm tra kết thúc một

hệ thống

1.5.1.Các kiểu hệ thống khác nhau:

Đích của UML là mô tả đợc vài kiểu hệ thống Thuật ngữ sơ đồ hớng đối tợng

đ-ợc dùng chung để tạo ra các mô hình của hệ thống phần mềm UML cũng đđ-ợc dùng

để mô tả hệ thống máy tính không có phần mềm hoặc các tổ chức của một xínghiệp ở đây các kiểu hệ thống khác nhau có các đặc tính chung nh sau:

 Thông tin hệ thống: lu, khôi phục, dịch chuyển và đa thông tin tới ngời sửdụng, ở đây sử dụng một khối lợng lớn dữ liệu, có đầy đủ các mối liên kết đợc

lu vào bảng quan hệ hoặc đối tợng cơ sở dữ liệu

 Kỹ thuật hệ thống: dùng kỹ thuật để điều hành các thiết bị điều khiển nh viễnthông, hệ thống máy tính nhỏ hay một tiến trình xử lý, thờng là kỹ thuật xử lý

hệ thống thời gian thực

 Nhúng các hệ thống thời gian thực: thực hiện nhúng phần cứng vào một thiết

bị khác

 Hệ thống phân tán: sự phân tán ở một số máy khi dữ liệu dễ dàng dịch chuyển

từ máy này sang máy khác, yêu cầu các máy liên kết với nhau phải đồng bộ, nóthờng đợc xây dựng trên các loại máy nh CORBA, COM/DCOM, hay Javabeans/RMI

 Phần mềm hệ thống: Các cơ sở hạ tầng khác nhau đợc sử dụng những phầnmềm khác nhau, hệ thống tính toán cơ sở dữ liệu và thực hiện giao diện ngờidùng với những phơng thức ở mức thấp trên phần cứng, trong khi đa nhữnggiao diện chung cho các phần mềm khác sử dụng

 Hệ thống thơng mại: Mô tả các đích, các nguồn, các quy tắc và các công việchiện tại trong xí nghiệp.

1.5.2 Công nghệ tác nghiệp:

Công nghệ tác nghiệp là một lĩnh vực mới cho mô hình hoá hớng đối tợng mà

đang đợc quan tâm nhiều Các mô hình hớng đối tợng đã chứng tỏ là một phơngpháp u tú cho mô hình hoá các tiến trình tác nghiệp trong một công ty, hiện nay ng-

ời ta đang sử dụng ngôn ngữ mô hình hoá hớng đối tợng để xây dựng hệ thốngthông tin tác nghiệp trong công ty

1.6 Các giai đoạn phát triển hệ thống:

Có 5 giai đoạn phát triển hệ thống là: các yêu cầu phân tích, phân tích, thiết kế,cài đặt và kiểm thử

1.6.1 Yêu cầu phân tích

UML sử dụng các trờng hợp để thu thập những yêu cầu của khách hàng, môhình USE-CASE, các tác nhân bên ngoài trong mô hình hệ thống quan tâm tới cácchức năng mà họ yêu cầu từ hệ thống Các tác nhân và các trờng hợp sử dụng đợcmô hình hóa với những mối liên kết và có sự liên kết truyền thông với nhau, hoặc đãphá huỷ sự phân cấp bên trong Các tác nhân và các trờng hợp sử dụng đợc mô tảtrong sơ đồ USE-CASE của UML Mỗi trờng hợp sử dụng đợc mô tả và thể hiện cácyêu cầu của khách hàng là: cái gì họ mong đợi từ hệ thống (bỏ qua về mặt chứcnăng) Yêu cầu phân tích cũng có thể làm với các tiến trình tác nghiệp

1.6.2 Phân tích

Các giai đoạn phân tích có liên quan tới các khái niệm trừu tợng nguồn (các lớp

và các đối tợng) và các cơ chế đợc biểu diễn trong phạm vi vấn đề Mô hình các lớp

đó đã đợc xác định với các mối liên kết giữa chúng với các mô hình khác đợc mô tảtrong sơ đồ lớp của UML Sự liên kết giữa lớp và quá trình thực hiện các trờng hợpcũng đợc mô tả qua vài mô hình động trong UML Trong pha phân tích chỉ có phạm

vi vấn đề lớp là đợc mô hình hóa (các khái niệm thời gian thực), các giải pháp về kỹthuật lớp định nghĩa chi tiết trong hệ thống phần mềm nh: các lớp cho giao diện ng-

ời sử dụng, các cơ sở dữ liệu, sự truyền thông, sự tơng tranh v.v

thuật: giao diện ngời dùng, cơ sở dữ liệu thao tác để lu trữ các đối tợng vào cơ sở dữliệu, truyền thông với các hệ thống khác, tơng tác tới các thiết bị trong hệ thống v.v Phạm vi của lớp từ khi phân tích đợc “nhúng” vào trong cơ sở hạ tầng kỹ thuật đó,làm cho nó có thể thay đổi giữa phạm vi vấn đề và cơ sở hạ tầng kỹ thuật Các kếtquả thiết kế đợc chi tiết hoá cho pha lập trình.

đơn giản và chính xác Lập trình là một giai đoạn tách biệt với quá trình chuyểnthành mã của mô hình

1.6.5 Kiểm thử (test)

Một hệ thống thờng đợc tin cậy trong các đơn vị kiểm tra, các kiểm tra tíchhợp, kiểm tra hệ thống và kiểm tra sự chấp nhận Các đơn vị kiểm tra là các lớpriêng biệt hoặc một nhóm các lớp đợc thực hiện điển hình bởi lập trình viên Kiểmtra tích hợp là kiểm tra các thành phần tích hợp và các lớp nhằm mục đích kiểm trahoạt động đồng thời đợc chỉ định

Hệ thống kiểm tra xem hệ thống nh là một hộp đen làm cho chức năng hệthống phù hợp với ngời sử dụng cuối Kiểm tra sự chấp nhận đợc cấu thành bởikhách hàng để kiểm tra các yêu cầu hệ thống thoả mãn Các phép kiểm tra khácnhau sử dụng các sơ đồ UML khác nhau trên cơ sở công việc của chúng Kiểm tra

đơn vị dùng sơ đồ lớp và các đặc trng của lớp Kiểm tra tích hợp điển hình sử dụngcác sơ đồ thành phần, các sơ đồ cộng tác và kiểm tra hệ thống sử dụng các sơ đồ

use-case phù hợp với kiểu của hệ thống nh các sơ đồ đã định nghĩa ban đầu.

Chơng II:

các thành phần cơ bản của UML

Mô hình ngôn ngữ hợp nhất có phạm vi sử dụng rộng, nó có thể đợc sử dụng chomô hình xí nghiệp, cho mô hình phần mềm trong tất cả các giai đoạn phát triển, chotất cả các kiểu hệ thống và các mô hình đầy đủ gồm cả cấu trúc tĩnh và kiểu dáng

động Trong thứ tự thực hiện với khả năng giới hạn rộng, ngôn ngữ đã định nghĩa,

đ-ợc mở rộng và có đầy đủ các đặc điểm chung cho phơng thức của mô hình nh nhiềuloại hệ thống khác nhau, tránh đợc những thay đổi và các vấn đề phức tạp

Chơng này giới thiệu sơ qua về UML, giải thích ngắn gọn về phạm vi và cấutrúc các thành phần của ngôn ngữ

Mô tả sơ qua về sự khác nhau của các thành phần trong UML :

 Các View: là thể hiện những mô tả cơ bản khác nhau của hệ thống, nó không

phải là một đồ thị, nó thể hiện một số sơ đồ một cách trừu tợng ở đây chúng ta

mới chỉ định nghĩa một số cách nhìn (View), mỗi View đều thể hiện đợc đặc

điểm lý tởng của hệ thống Nó có thể là một bức tranh đầy đủ của hệ thống đã

đợc cấu trúc Các View cũng liên kết với mô hình ngôn ngữ để lựa chọn các tiếntrình, các phơng thức cho sự phát triển

 Sơ đồ: các sơ đồ là những đồ thị đợc mô tả trong cách nhìn, UML có 9 sơ đồ

khác nhau đợc sử dụng trong tất cả các cách nhìn để thể hiện sự kết hợp của hệthống

 Các phần tử mô hình: khái niệm đợc sử dụng trong sơ đồ là các thành phần mô

hình, nó chỉ ra các khái niệm hớng đối tợng (OO: Object Oriented) chung nh là: các lớp (Classes), các đối tợng (Objects), các mẫu tin (Messages) và các mối

quan hệ giữa chúng gồm: sự liên kết, sự phụ thuộc, sự tổng quát Một thànhphần mô hình đợc sử dụng trong vài sơ đồ khác, nhng nó luôn có ký hiệu và ýnghĩa

 Các cơ chế chung: các cơ chế tổng quát cung cấp những chú thích đặc biệt,

các thông tin hay ngữ nghĩa cho một số thành phần mô hình, thể hiện nh là mộttiến trình, một phơng thức, một tổ chức hay ngời sử dụng

Giáo viên hớng dẫn ThS: Lê Văn Minh Thực hiện: Nguyễn Thị Thu Hơng

2.1 Các View

Mô hình hoá một hệ thống đầy đủ là một nhiệm vụ lớn, nó chỉ ra rằng hệ thốngtoàn vẹn đã đợc mô tả trong một đồ thị đơn giản và nó đợc định nghĩa là một hệthống toàn vẹn, rõ ràng, dễ chuyển đổi và dễ hiểu, tuy nhiên vấn đề quan trọng làmột đồ thị đơn không thể thu thập tất cả các thông tin cần thiết cho việc mô tả một

hệ thống, hệ thống đợc mô tả bởi một số khía cạnh khác nhau là: hoạt động (là cấutrúc tĩnh và sự tơng tác động), không hoạt động (yêu cầu đồng bộ hoá, sự tin cậy, sự

phát triển,v.v ), các khía cạnh tổ chức (việc tổ chức, sự ánh xạ tới các modul mã).

Nh vậy một hệ thống đợc biểu diễn bởi một số View, mỗi View tiêu biểu chomột phép chiếu của sự biểu diễn đầy đủ về những khía cạnh đặc biệt của hệ thống.Mỗi View đợc mô tả trong một số sơ đồ, nó chứa các thông tin nhấn mạnh cáckhía cạnh đặc biệt của hệ thống Do vậy một sơ đồ có thể thể hiện đợc nhiều hơnmột View, nó giống nh một hệ thống từ những View khác nhau, nó có thể tập trungtrên một khía cạnh của hệ thống tại một thời điểm Một sơ đồ trong một View riêng

sẽ khá đơn giản để dễ dàng truyền thông, nhng cha mạch lạc so với nhiều sơ đồ vàcác View khác, vì thế bức tranh đầy đủ của hệ thống đã phải đợc mô tả bởi tất cảcác View cạnh nhau Một sơ đồ chứa các ký hiệu của đồ thị tiêu biểu cho một phần

tử mô hình của hệ thống, hình 2.1 mô tả tất cả View của UML đó là :

 View use-case: mô tả chức năng của hệ thống mà ngời ngoài có thể thấy đợc.

 View logical: mô tả chức năng làm nh thế nào?, nó đợc định nghĩa bên trong hệ

thống

 View cạnh tranh (Concurrency): thể hiện sự hài hòa trong hệ thống, các vấn đề

địa chỉ hoá với sự liên kết và sự đồng bộ, đây là sự hiện diện của một hệ thốnghài hoà

 View triển khai (Deplogment): thể hiện hệ thống triển khai trong kiến trúc vật

lý của các máy tính và các thiết bị đợc gọi là các nút (Nodes)

 View thành phần (Component): thể hiện việc tổ chức của các mã thành phần

Khi bạn lựa chọn công cụ để vẽ sơ đồ, làm cho nó dễ dàng chuyển qua từ Viewtới View khác, ta thấy chức năng đợc thiết kế cho công việc nào không có trong

một sơ đồ, công cụ sẽ làm nó dễ dàng chuyển từ View use-case này tới chức năng

nào đã đợc mô tả bởi ngời sử dụng ngoài, hoặc từ View tới chức năng nào phân

View component

View use-case

View logic

View concurrency

View deployment

tán trong cấu trúc vật lý, trong các công việc khác, chúng ta tìm thấy các máy tínhkhả dụng

Hình 2.1: Các view trong UML

Ngoài ra ngời ta còn sử dụng các View khác nh: view động, view tĩnh, viewlogic, view vật lý, view biểu thị luồng công việc v.v UML không yêu cầu sử dụngnhững view đó, nhng các view vẫn đợc ngời thiết kế UML sử dụng, do vậy nó là cáccông cụ, là cơ sở cho các View khác

2.1.1.View use-case

View use-case mô tả chức năng tiện ích mà hệ thống sẽ cung cấp Nó đợc tạo

ra bởi những tác nhân ngoài, sự tơng tác giữa một tác nhân ngoài với hệ thống có

thể là một ngời sử dụng hoặc một hệ thống khác View use-case cho các khách

hàng, cho ngời thiết kế, cho ngời phát triển và ngời kiểm tra, nó đợc mô tả trong các

sơ đồ use-case và thỉnh thoảng trong các sơ đồ hoạt động, sự mong muốn sử dụng của hệ thống đợc mô tả nh một số trờng hợp sử dụng view use-case, ở một tình

huống sử dụng đợc mô tả chung cho một ngời sử dụng hệ thống (một chức năng đợcyêu cầu)

View use-case là trung tâm chứa các thiết bị phát triển của các view khác Mục

đích cuối cùng của hệ thống là cung cấp các chức năng tiện ích đợc mô tả lâu dàitrong View View này cũng đợc sử dụng để phê chuẩn và kiểm tra lại cho hệ thống

bằng Testing, View use-case chống lại sự xâm nhập của khách hàng và sự kết thúc

của hệ thống

Giáo viên hớng dẫn ThS: Lê Văn Minh Thực hiện: Nguyễn Thị Thu Hơng

2.1.2 View logical

View logic mô tả chức năng của hệ thống làm gì Nó giữ vai trò chính cho ngời

phân tích và ngời phát triển hệ thống, sự tơng phản giữa View use-case và View

logic đợc thấy bên trong hệ thống, nó mô tả cấu trúc tĩnh (lớp, đối tợng và các mốiquan hệ) và sự hợp tác động xuất hiện khi đối tợng gửi Message tới một chức năngcung cấp khác, các thuộc tính nh là tính ổn định và tính hài hoà cũng đợc địnhnghĩa Nó tốt cho giao diện và cấu trúc bên trong của lớp Cấu trúc tĩnh đợc mô tảtrong sơ đồ đối tợng và sơ đồ lớp Mô hình động đợc mô tả trong các sơ đồ trạngthái, tuần tự, các sơ đồ cộng tác và sơ đồ hoạt động

2.1.3.View thành phần

View thành phần mô tả các modul thực hiện và sự phụ thuộc giữa chúng View

thành phần đóng vai trò chính cho ngời phát triển và phù hợp với sơ đồ thành phần.Các thành phần với các kiểu modul mã khác nhau thể hiện cấu trúc và sự phụ thuộccủa chúng Khi thêm một số thuộc tính về các thành phần nh là nguồn cấp phát haythông tin quản lý khác thì một báo cáo tiến độ công việc phát triển có thể cũng đợcthêm vào

2.1.4.View cạnh tranh

Các View cạnh tranh với việc chia hệ thống vào trong các tiến trình và các bộ xử

lý Khía cạnh này cùng với thuộc tính không phải là chức năng của hệ thống choviệc đánh giá hiệu suất sử dụng tài nguyên, sự thực hiện song song và thực hiệnkhông đồng bộ các tình huống từ môi trờng Hơn nữa nó chia hệ thống vào trongcác luồng điều khiển thực hiện một cách đồng thời View cũng phải phân phối sựtruyền thông và sự đồng bộ hoá của các luồng đó View cạnh tranh là các bộ pháttriển và bộ tích hợp của hệ thống, nó bao gồm các sơ đồ động (trạng thái, tuần tự,cộng tác và sơ đồ hoạt động) và sự thực hiện của các sơ đồ đó (các sơ đồ thành phần

và các sơ đồ triển khai)

2.1.5 View triển khai

Cuối cùng View triển khai thể hiện sự triển khai của hệ thống vào môi trờng vật

lý, nh là các máy tính, các thiết bị và cách chúng đợc kết nối với nhau View triểnkhai là các bộ phát triển, bộ tích hợp và bộ kiểm tra Nó đợc biểu diễn trong một sơ

đồ triển khai View cũng gồm một phép ánh xạ thể hiện các thành phần đã triển

Ký hiệu của nhà bán bảo hiểm

hệ thống tiêu biểu thì mỗi kiểu có một số sơ đồ Một sơ đồ là một phần của Viewchỉ định, khi đợc vẽ lên thì nó thờng cấp phát một View Các kiểu sơ đồ có thể lànhững phần của các View phụ thuộc vào nội dung của sơ đồ

Phần này mô tả các khái niệm cơ bản sau mỗi sơ đồ Tất cả chi tiết về các sơ đồ,

cú pháp của chúng và cách chúng tơng tác đợc mô tả trong chơng tiếp theo Sơ đồ làthể hiện các kiểu hệ thống khác nhau đó là tính đa dạng của UML

2.2.1 Sơ đồ use-case

Một sơ đồ use-case thể hiện một số tác nhân bên ngoài và kết nối của chúng tới

các trờng hợp sử dụng mà hệ thống đó cung cấp nh hình 2.2, một use-case mô tả

chức năng mà hệ thống đó cung cấp Sự mô tả hiện tại của các trờng hợp thờng sử

dụng trong văn bản gốc, nh thuộc tính tài liệu của ký hiệu use-case Nhng nó cũng

có thể đợc mô tả trong sơ đồ hoạt động Use-case chỉ mô tả bên ngoài bởi các tác nhân mà không mô tả chức năng bên trong của hệ thống Use-case định nghĩa các yêu cầu chức năng của hệ thống, các sơ đồ use-case đợc mô tả chi tiết hơn trong ch-

ơng 3

Hình 2.2 : Sơ đồ Use-case cho công việc bảo hiểm

2.2.2 Sơ đồ lớp

Một sơ đồ lớp chỉ ra cấu trúc tĩnh của các lớp trong hệ thống Các lớp biểu diễn

“mọi thứ” đợc thực hiện trong hệ thống Các lớp liên quan với nhau bằng một số

Giáo viên hớng dẫn ThS: Lê Văn Minh Thực hiện: Nguyễn Thị Thu Hơng

1 1 *

Actor

Name: String Age: Integer

Computer

Name: String Memory: Integer Sơ đồ lớp

Age: 32 Bob’s Home PC

Name: ‘Compaq Pentium MMX’

Memory: 32

cách: đợc liên kết, bị phụ thuộc, bị hạn chế hoặc đợc đóng gói, tất cả các mối liênkết đó đợc chỉ ra trong sơ đồ lớp với cấu trúc bên trong của lớp qua các thuật ngữ:thuộc tính và các phơng thức Cấu trúc đợc mô tả xem nh một sơ đồ tĩnh luôn hợp lýtrong bất kỳ thời điểm nào của chu kỳ sống hệ thống Một hệ thống điển hình là mộtsơ đồ lớp, không phải tất cả các lớp đợc dùng vào trong một sơ đồ lớp đơn mà lớp cóthể tham gia trong một sơ đồ lớp Sơ đồ lớp đợc mô tả trong chơng 4

2.2.3 Sơ đồ đối tợng

Sơ đồ đối tợng là một thể hiện của sơ đồ lớp Nó sử dụng hầu hết các chú thích

nh ở sơ đồ lớp Sự khác nhau giữa sơ đồ lớp và sơ đồ đối tợng đó là một số đối tợng

là thể hiện cụ thể của lớp thay cho lớp thực sự Sơ đồ đối tợng nh là một ví dụ của sơ

đồ lớp, nó minh họa sự thực hiện của hệ thống Các sơ đồ lớp đợc chú thích giống

nh vậy với hai ngoại lệ: tên đối tợng đợc gạch chân, tất cả đợc thể hiện trong mốiquan hệ đợc chỉ ra trong hình 2.3.

Hình 2.3 : Sơ đồ lớp thể hiện các lớp và sơ đồ đối tợng thể hiện cụ thể của các lớp.

Sơ đồ đối tợng không quan trọng nh sơ đồ lớp, nhng chúng thờng đợc dùng đểminh họa cho một sơ đồ lớp đầy đủ bằng cách chỉ ra các thể hiện thực sự và các mốiquan hệ giống sơ đồ lớp Các sơ đồ đối tợng cũng đợc sử dụng nh một phần của sơ

đồ cộng tác với sự cộng tác “động” giữa một tập các đối tợng đợc xác định

2.2.4 Sơ đồ trạng thái

Sơ đồ trạng thái bổ sung cho sự mô tả lớp Nó chỉ ra tất các trạng thái có thể của

đối tợng mà lớp có thể có và các tình huống gây ra sự thay đổi trạng thái (nh

hình2.4) một tình huống có thể là một đối tợng khác gửi một Message tới nó Sự

idle

Moving to first floor

arrived at first floor

arrive at floor

arrive

at floor

go up (floor)

Go up(floor)

Go down(floor) Time - out

Moving up

Moving down

: Queue

Print(file)

Print(file) [Printer free]

Print(file) [Printer basy]

Store(file)

: Printer : PrinterServer

: Computer

thay đổi trạng thái đợc gọi là một sự chuyển tiếp Sự chuyển tiếp có thể là một hành

động đợc kết nối với nó Ta sẽ làm gì để kết nối đợc với sự chuyển đổi trạng thái đó

H

ình 2.4: Một sơ đồ trạng thái cho thang máy

Sơ đồ trạng thái không đợc vẽ cho tất cả các lớp, chỉ có một số lớp có một sốtrạng thái đợc định nghĩa rõ ràng và ở đó khung cảnh của lớp bị ảnh hởng và thay

đổi bởi các trạng thái khác nhau Sơ đồ trạng thái có thể đợc vẽ cho toàn bộ hệthống Các sơ đồ trạng thái đợc mô tả chi tiết hơn trong chơng sau

2.2.5 Sơ đồ tuần tự:

Hình 2.5 : Một sơ đồ tuần tự cho việc phục vụ máy in

Giáo viên hớng dẫn ThS: Lê Văn Minh Thực hiện: Nguyễn Thị Thu Hơng

1: Print(file) : Computer

: PrinterServer

: Queue

: Printer [Printer free] 1.1: Print(file)

[Printer busy]

1.2: Store(file)

Sơ đồ tuần tự chỉ ra sự hợp tác động giữa một số đối tợng nh trong hình 2.5.

Khía cạnh quan trọng ở sơ đồ này chỉ ra sự nối tiếp các Message đợc gửi giữa các

đối tợng Nó cũng chỉ ra sự tơng tác giữa các đối tợng, thỉnh thoảng điều đó sẽ xảy

ra tại một thời điểm trong quá trình thực hiện của hệ thống Sơ đồ gồm một số đối ợng chỉ ra với các đờng thẳng đứng Sơ đồ chỉ ra sự chuyển đổi các Message giữacác đối tợng nh thời gian tuần tự trôi qua Message thể hiện là các đờng thẳng vớimessage và các mũi tên giữa đờng đối tợng thẳng đứng Chi tiết về thời gian vànhững chú thích khác đợc thêm vào bên cạnh của sơ đồ Sơ đồ tuần tự đợc mô tảnhiều hơn ở chơng sau

t-2.2.6 Sơ đồ cộng tác:

Sơ đồ cộng tác thể hiện sự tác động Nó giống sơ đồ tuần tự Thể hiện của sựcộng tác thờng đợc xem nh là sơ đồ tuần tự hoặc sơ đồ cộng tác

Hình 2.6 : Một sơ đồ cộng tác cho việc phục vụ máy in

Hơn nữa thể hiện sự chuyển đổi của các Message (đợc gọi là sự tơng tác), sơ đồcộng tác thể hiện các đối tợng và các mối quan hệ giữa chúng Khi bạn sử dụng mộtsơ đồ tuần tự hay một sơ đồ cộng tác có thể thờng đợc quyết định bởi: nếu thời gianhoặc sự tuần tự là khía cạnh quan trọng để nhận định thì lựa chọn sơ đồ tuần tự, nếumối quan hệ của các đối tợng nhấn mạnh là quan trọng thì chọn sơ đồ cộng tác Sựtơng tác lẫn nhau giữa các đối tợng đợc thể hiện trong cả hai sơ đồ

Sơ đồ cộng đợc vẽ lên nh sơ đồ đối tợng, ở đó số các đối tợng đợc chỉ ra cùngvới mối quan hệ giữa chúng Các mũi tên chỉ Message đợc vẽ giữa các đối tợng đểthể hiện luồng Message giữa các đối tợng Các nhãn đợc đặt trên các Message ởgiữa các Message khác nhau thể hiện thứ tự trong các Message đợc gửi Nó cũng cóthể thể hiện các điều kiện, các tơng tác qua lại, giá trị trả về,… Khi quen với cúpháp nhãn Message, bộ phát triển có thể đọc sự cộng tác, các luồng thực hiện theo

Show Message Box

“disk full” on screen

[disk full ]

[Free disk space]

Create Postscript File

^Printer.print (file) Remove

Hình 2.7 : Sơ đồ hoạt động cho bộ trợ giúp máy in

Sơ đồ hoạt động thể hiện thứ tự các luồng hoạt động Nh chỉ ra trong hình 2.7,

sơ đồ hoạt động điển hình thờng mô tả các hoạt động trong một phơng thức, mặc dù

nó cũng có thể thờng mô tả các luồng hoạt động khác nh là một trờng hợp sử dụnghoặc một sự tơng tác Sơ đồ hoạt động bao gồm các trạng thái hoạt động, chứa chitiết về một hành động đợc thực hiện Một sơ đồ hoạt động gồm có các trạng tháihoạt động sẽ để lại trạng thái khi hành động đã đợc thực hiện (trạng thái trong sơ đồtrạng thái cần rõ ràng trớc khi nó để lại trạng thái trớc) Nh vậy các luồng điềukhiển giữa các trạng thái hoạt động chúng đợc kết nối lẫn nhau Sự quyết định vàcác điều kiện nh là sự thực hiện song song của các trạng thái hoạt động cũng có thể

đợc chỉ ra trong sơ đồ Sơ đồ cũng có thể chứa chi tiết các Message đợc gửi hoặc

đ-ợc nhận nh một phần các hành động đđ-ợc thực hiện Sơ đồ trạng thái đđ-ợc mô tả trongchơng 5

2.2.8 Sơ đồ thành phần:

Sơ đồ thành phần thể hiện cấu trúc vật lý của mã trong giới hạn các thành phần mã.Một thành phần có thể là một thành phần mã nguồn, một thành phần nhị phân, mộtthành phần có thể thực hiện Một thành phần chứa các thông tin của lớp logic hoặccác lớp nó thực hiện, nh việc tạo ra một ánh xạ từ View logic tới View thành phần

Sự phụ thuộc giữa các thành phần thể hiện việc phân tích dễ dàng thành phần khác

đã tác động đến sự thay đổi của một thành phần Các thành phần cũng có thể đợc

Giáo viên hớng dẫn ThS: Lê Văn Minh Thực hiện: Nguyễn Thị Thu Hơng

Windown Handler (whnd.cpp)

Comm Handler (comhnd.cpp)

Windown Handler (whnd.obj)

Graphic Lib (graphic.dll)

Comm Handler (comhnd.obj)

Client Program (client.exe) Main

Class (main.obj)

ra sự phụ thuộc giữa các thành phần

Nh trạng thái của sơ đồ triển khai đã có trớc, đợc thể hiện giống View triểnkhai, nó mô tả kiến trúc vật lý thực của hệ thống, đó là sự mô tả chức năng trong

View use-case Tuy nhiên với mô hình đợc định nghĩa là tốt khả năng quản lý tất cả

các cách từ một nút trong kiến trúc vật lý tới các thành phần, để lớp thực hiện sự

t-ơng tác các đối tợng đó của lớp tham dự trong một trờng hợp sử dụng cuối cùng.Các View khác của hệ thống đã cho sự mô tả chặt chẽ trong toàn bộ hệ thống

Silicon Graphic O2

Database Server:

đối tợng, trạng thái, nút, khối và các thành phần biểu diễn đồ họa của phần tử hay

ký hiệu đồ họa đợc sử dụng để biểu diễn phần tử nh trong hình 2.10.

Hình 2.11 thể hiện những ví dụ của các mối liên kết Cũng với các phần tử mô

hình và sử dụng để kết nối các phần tử mô hình này với các phần tử mô hình khác.Các mối liên kết khác nhau là:

 Sự liên kết: kết nối các phần tử và thể hiện cụ thể của lớp.

 Sự tổng quát hoá: cũng đợc gọi là sự thừa kế Nghĩa là một phần tử có là sự cá

biệt hoá của một phần tử khác

 Sự phụ thuộc: chỉ một phần tử phụ thuộc theo một cách nào đó vào phần tử

Giáo viên hớng dẫn ThS: Lê Văn Minh Thực hiện: Nguyễn Thị Thu Hơng

Sự phụ thuộc (Dependency)

Sự tổng quát hoá (Generalization)

Sự liên kết (Association)

Sự kết hợp (một dạng của sự liên kết)

State

Attributes Class

Operatings

Attributes Object

Operatings

Node

Use-case

Interface Package

ình 2.11: Các ví dụ của một vài mối liên kết

2.3 Các cơ chế chung (General Mechanisms)

UML dùng vài cơ chế chung trong tất cả các sơ đồ để thêm thông tin vào sơ đồ.Nhng nó không thể sử dụng để biểu diễn các khả năng cơ sở của các phần tử môhình

2.3.1 Sự tô vẽ:

Sự tô vẽ đồ thị có thể đợc gắn tới các phần tử mô hình trong các sơ đồ để tô vẽthêm ngữ nghĩa cho phần tử Khi một phần tử biểu diễn một kiểu thì tên của nó sẽ đ-

ợc hiển thị bằng kiểu chữ đậm Khi phần tử biểu diễn một thể hiện cụ thể của mộtkiểu thì tên của nó sẽ đợc gạch chân và tên của thể hiện cụ thể chỉ rõ nh tên củakiểu Một lớp biểu diễn bằng hình chữ nhật với tên đợc in đậm, tên của đối tợng thì

đợc gạch chân

Class An Object Class

Một sự tô điểm nữa là chỉ định các mối đa liên kết, đa liên kết đó là một số hoặcgiới hạn đợc chỉ ra nhiều thể hiện cụ thể của các kiểu nối có thể đợc bao hàm trongcác quan hệ Sự tô điểm đợc viết chính xác tới phần tử nào thêm thông tin chochúng, tất cả sự tô điểm đợc mô tả trong kết hợp với sự mô tả của phần tử tác động

đợc giải thích với thông tin trong đó nh hình 2.13

Chú thích thờng chứa dạng chú giải hoặc câu hỏi để nhắc nhở, giải quyết nhữngvấn đề khó ở nhiều thời điểm Các chú thích cũng có kiểu để mô tả

Hình 2.13: Chú thích bất kỳ thông tin thêm vào nh là một lời giải thích đơn giản

2.3.3 Các đặc tả:

Các phần tử mô hình có những thuộc tính giữ các giá trị của dữ liệu về phần tử.Thuộc tính đợc định nghĩa với một tên và một giá trị gọi là giá trị đuôi, kiểu đặc tr-

ng là số nguyên hoặc là xâu Có một số thuộc tính tiền định nh: Documentation,

Responsibility, Persistence và Concurrence.

Các thuộc tính thờng thêm các đặc tả về phần tử Điển hình nh là một lớp đợcmô tả với vài văn bản mà thông tin đã đợc lập thành mục Nó có khả năng đáp ứng,

Giáo viên hớng dẫn ThS: Lê Văn Minh Thực hiện: Nguyễn Thị Thu Hơng

Stock Option

TheorPrice() MarketPrice() ExpireData()

Dùng công thức Black

& Schole

2.4.1 Các mẫu có sẵn:

Một mẫu có sẵn với cơ chế mở rộng đợc định nghĩa là một loại mới của phần tửmô hình Mỗi mẫu có sẵn gần giống phần tử đã tồn tại Một mẫu của một phần tử cóthể đợc sử dụng trong các trạng thái của phần tử có hớng đã đợc dùng Một mẫu cósẵn là cơ sở cho các kiểu phần tử nh: các lớp, các node, các thành phần và các lờichú thích, nó có các mối quan hệ tốt nh: sự liên kết, sự tổng hợp hoá, sự phụ thuộc.Một số mẫu là tiền định trong UML đợc dùng để điều chỉnh việc mở rộng một phần

tử mô hình thay cho việc định nghĩa một phần tử mô hình mới theo những cơ số đơngiản của ngôn ngữ UML

Một mẫu đợc mô tả rằng tên của nó đợc đặt vào tên của phần tử nh hình 2.14.Một mẫu có sẵn cũng có thể có sự biểu diễn bằng đồ họa nh là biểu tợng và đợc kếtnối với nó Một phần tử của một mẫu đặc biệt có thể thể hiện sự biểu diễn đơn giảnvới tên của mẫu ở mặt trớc của tên Bất cứ khi nào thì một phần tử đều có tên mẫuhoặc biểu tợng đợc kết nối với nó, mẫu đó nói lên kiểu của phần tử

Ví dụ: một lớp có các mẫu cửa sổ tức là các mẫu cửa sổ đó thể hiện các kiểu cửa

sổ của lớp

Hình 2.14 : Các khách hàng là một lớp với mẫu << Actor >> Trong trờng hợp này lớp biểu diễn ngời sử dụng ngoài hệ thống.

Instrument (abstract) (Author = “HEE”) (Status = Draft) value : int expdate: date

Nh ở đoạn trớc một mẫu đã có cơ chế mở rộng hơn hẳn, UML đang mở rộng

tr-ớc để trở nên đầy đủ hơn Nhiều phần tử mô hình mới yêu cầu có một bản mẫu cơ

sở trong UML Một mẫu có sẵn có thể đợc dùng để thêm những ngữ nghĩa cần thiết

đợc yêu cầu theo thứ tự để định nghĩa các phần tử mô hình khuyết :

H

ình 2.15 : Các thuộc tinh trên công cụ lớp, Instrument là một thuộc tính tiền định,

Author và Status là các giá trị đã dán nhãn đợc ngời dùng định nghĩa

2.4.2 Các giá trị đợc dán nhãn (Tagged Values):

Các phần tử có thể có các thuộc tính chứa cặp giá trị trên với một số thông tin

của chúng (nh hình 2.15), các thuộc tính đó cũng đợc gọi là giá trị đã dán nhãn, và

một số thuộc tính đó cũng có thể đợc ngời sử dụng định nghĩa để nén thông tin vàthêm vào một số phần tử Bất kỳ một kiểu thông tin nào cũng có thể đ ợc gắn tới cácphần tử: thông tin về đặc điểm-phơng thức, quản lý thông tin để tiến hành mô hìnhhoá, các công cụ sử dụng thông tin khác nh các công cụ sinh mã hoặc bất cứ loạithông tin nào mà ngời sử dụng muốn gắn vào các phần tử

2.4.3 Các ràng buộc:

Một ràng buộc là một sự ràng buộc trong phần giới hạn sử dụng của phần tửhoặc ý nghĩa của phần tử Một ràng buộc đợc công khai trong các công cụ và đợc sửdụng lặp đi lặp lại trong các sơ đồ riêng biệt, hay đợc định nghĩa và đợc thêm vào

nh yêu cầu của sơ đồ Hình 2.18 thể hiện sự liên kết giữa lớp nhóm ngời cao tuổi và

lớp ngời Nó chỉ ra một nhóm có thể có nhiều ngời liên kết với nó mối quan hệ nàychỉ những ngời thuộc có thuộc tính tuổi lớn hơn 60, Để định nghĩa cho các ràngbuộc đó ngời ta sử dụng sự liên kết Một ràng buộc cũng có thể làm cho hệ thốngthực hiện không đúng ở trờng hợp này thì ràng buộc đợc định nghĩa và đợc trựctiếp thêm vào sơ đồ khi sử dụng, nhng nó cũng có thể đợc định nghĩa là ràng buộc

có tên và đặc điểm nh : “ngời cao tuổi” và “ngời tuổi >60” đợc sử dụng trong các sơ

đồ riêng

Giáo viên hớng dẫn ThS: Lê Văn Minh Thực hiện: Nguyễn Thị Thu Hơng

0 1 0 *

(Ng ời với tuổi > 60)

Nhóm ng ời cao tuổi

Ng ời

Hình 2.16 : Một ràng buộc hạn chế các đối tợng ngời đợc đa vào trong liên kết.

2.5 Mô hình hoá với UML

Khi các hệ thống đang đợc xây dựng bằng UML thì hệ thống đợc xây dựngkhông phải bao giờ cũng chính xác, đây là những mô hình riêng biệt trong các giai

đoạn phát triển khác nhau thì mục tiêu của các mô hình là tách biệt nhau Trong giai

đoạn phân tích mục tiêu của mô hình là nắm đợc các yêu cầu của hệ thống, mô hìnhlớp cơ sở và sự cộng tác giữa chúng Trong giai đoạn thiết kế mục tiêu của mô hình

là mở rộng những mô hình đã phân tích trong một kỹ thuật giải quyết công việc vàquan tâm đến môi trờng thực hiện Trong giai đoạn thực hiện thì mô hình là mãnguồn thực, nó đã đợc lập trình và đợc dịch trong các chơng trình, cuối cùng trongmô hình phát triển, sẽ mô tả, giải thích hệ thống triển khai nh thế nào ở kiến trúc vật

lý Sự đánh dấu giữa các giai đoạn và các mô hình đợc duy trì ở các thuộc tính hoặccác mối quan hệ đợc lọc

Mặc dù các mô hình là khác nhau, nhng nó vẫn xây dựng và mở rộng nội dungcủa mô hình một cách dễ dàng Vì tất cả các mô hình sẽ đợc lu lại để sử dụng sau vàchạy lại hoặc mở rộng các mô hình đợc phân tích từ đầu, dần dần sự thay đổi đó sẽ

đợc đa vào việc thiết kế và thực hiện các mô hình (nh hình 2.17).

System model

Mô hình phân tích Mô hình thiết kế Thực hiênMô hình

Mô hình Triển khai

Hình 2.17 : một hệ thống là sự mô tả các mô hình riêng biệt.

Các giai đoạn của UML là độc lập, nghĩa là nó giống nh ngôn ngữ chung, vàgiống các sơ đồ đợc sử dụng trong các mô hình khác nhau của các giai đoạn khácnhau Đó là sự mô hình hoá giải quyết mục tiêu và phạm vi của mô hình sẽ kiểmsoát Mô hình ngôn ngữ chỉ tạo ra các mô hình có phơng pháp và ý nghĩa phù hợp Khi mô hình hoá với UML, công việc sẽ bị ảnh hởng bởi các phơng pháp và tiếntrình ngoại tuyến để tạo ra các bớc khác nhau và việc thực hiện những bớc đó Nh

vậy một kiểu tiến trình sẽ đợc chia ra thành phép lặp có thứ tự các pha: phân tích /

thiết kế / thực hiện và pháp triển, đó cũng là tiến trình nhỏ có liên quan tới việc mô

hình hoá thực tế Thông thờng khi một mô hình hay một sơ đồ đợc hình thành bằngcách một nhóm ngời thích hợp thu thập, bàn bạc, thống nhất và đa ra những ý kiếntốt nhất để xây dựng và chuyển đổi các mô hình, công cụ sử dụng chủ yếu là cácnode và một bảng mạch Cuộc họp của nhóm ngời này tiếp tục cho đến khi cácthành phần tham gia đều cảm thấy họ đã có những ý kiến thực tế cho một mô hình.Cơ sở kết quả đợc đa vào một công cụ, mô hình giả thiết đã đợc định hớng và mộtsơ đồ thực phù hợp đợc hình thành, đó là kết quả của việc mô hình hoá ngôn ngữ,tiếp đến mô hình sẽ càng đợc chi tiết hơn và công việc đó sẽ đợc lặp lại cho đến hết,

từ đó một số giải pháp chi tiết đã đợc pháp hiện và đợc tài liệu hoá Những thông tinthu đợc về một số vấn đề là giải pháp, giả thiết và chúng đang dần trở thành mộtphép chuẩn sai cho một mô hình khả thi Khi một mô hình gần kết thúc thì ta thu đ-

ợc một sự tích hợp và các bớc kiểm tra Với các mô hình hay sơ đồ đầu đợc tích hợpvới các mô hình hay sơ đồ khác trong dự án bảo đảm không tồn tại sự mâu thuẫn,

mô hình cũng đợc phê chuẩn để kiểm tra lại các vấn đề giải quyết bên phải (hình

2.18).

Giáo viên hớng dẫn ThS: Lê Văn Minh Thực hiện: Nguyễn Thị Thu Hơng

các node

Sự định kiểu

Mô tả các cảm giác nh một cách tiếp cận thực tế

Xác định nội dung của sơ đồ (nh tổng hợp tiến trình và một

(Dạng ch a thoả mãn) khi có bất kỳ một dạng ch a Đánh giá kết quả: quay lại

thỏa mãn nào

Cuối cùng, mô hình đã đợc thực hiện trong một số loại nguyên mẫu, nó đánhgiá cho một số thiếu sót trong giải pháp thực tế, sự thiếu sót đó bao gồm nh là việcvắng mặt các chức năng, thực hiện không tốt hay chi phí để phát triển quá cao.Những thiếu sót đó đòi hỏi các nhà phát triển phải lùi lại từng bớc Nếu các vấn đề

là lớn thì ngời phát triển có thể có nhiều cách lùi lại để đi tới những ý kiến hay hoặcnhững bản phác thảo Nếu các vấn dề là nhỏ thì các nhà phát triển hoàn toàn có thểthay đổi các phần của việc tổ chức hay chỉ định của mô hình Chú ý rằng các bớc

định kiểu không thể trực tiếp thực hiện đợc khi sơ đồ đã kết thúc Nó sẽ đợc thựchiện khi các sơ đồ cùng đợc định kiểu Mẫu đã đợc cấu trúc có thể bị bỏ đi hoàntoàn khi đánh giá hoặc kết quả của các bớc định kiểu trở thành phép lặp trong cáctiến trình phát triển thực

Hình 2.20 : Mô hình hoá một tiến trình công việc thực.

2.6 Các công cụ

Dùng một mô hình ngôn ngữ đầy đủ và mở rộng là UML thì yêu cầu là phải có

sự trợ giúp của các công cụ Dù bản phác thảo đầu tiên của một mô hình đã đ ợc làmxong và đang sử dụng một hộp trắng (nh việc vẽ các mô hình bằng tay) Việc duytrì, đồng bộ và cung cấp một số mô hình rất quan trọng đối với một công cụ

Mô hình hoá công cụ hay công cụ CASE từ các phiên bản đầu tiên đợc sử dụng

để sản xuất các chơng trình Đa số ở đây là công cụ dùng để vẽ, với các phép kiểmtra độ tin cậy, hoặc việc hiểu biết phơng pháp hay mô hình ngôn ngữ hiện thời, nhvậy là vẫn có sự cải tiến và ngày nay ngời ta đang lựa chọn các công cụ từ phiên bản

đầu tiên nh hình 2.19, nhiều công cụ còn lại đã đợc hiệu chỉnh Với những lỗi kỹ

thuật hay những đặc trng mà những phần mềm ứng dụng gốc không có, nh là cắt vàdán Các công cụ đợc giới hạn bởi tất cả mô hình ngôn ngữ mà chúng ta có hoặc íthơn những cái mà chúng ta định nghĩa về ngôn ngữ Với phiên bản của UML, công

cụ mà ngời cung cấp có thể đa ra ngay là rất quan trọng cho việc định nghĩa các

ph-ơng thức và ngôn ngữ mới

Một công cụ CASE hiện đại sẽ có các chức năng sau:

 Vẽ sơ đồ: công cụ phải đáp ứng đợc yêu cầu đơn giản của các sơ đồ trong mô

hình ngôn ngữ Công cụ sẽ đủ thông minh để hiểu đợc mục đích của các sơ đồ,biết đợc ngữ nghĩa đơn giản cũng nh các quy luật, do vậy nó có thể cảnh báohoặc ngăn cản việc sử dụng không đúng, không thích hợp của các mô hình

 Hành động nh là một kho: các công cụ phải đáp ứng đợc một kho chung, do

vậy nó đã thu đợc một số thông tin về mô hình và lu vào một vị trí nào đó Nếutên của lớp bị chuyển đổi trong sơ đồ thì sự chuyển đổi đó phải đợc phản ánhtrong tất cả các sơ đồ khác với các lớp đã đợc sử dụng

 Trợ giúp việc điều hành: công cụ đợc sinh ra phải dễ dàng điều khiển đợc mô

hình, từ vết của thành phần trong sơ đồ này tới sơ đồ khác, hoặc rộng ra là sựgiải mã của một thành phần

 Tạo ra sự trợ giúp đa dụng: công cụ phải trợ giúp ngời sử dụng và họ có thể

làm việc trên một mô hình không có giao diện hoặc đang bị sáo trộn với nhữngmô hình khác

Giáo viên hớng dẫn ThS: Lê Văn Minh Thực hiện: Nguyễn Thị Thu Hơng

 Sinh mã: một công cụ đợc cải tiến có thể sinh mã, tất cả thông tin trong mô hình

đã đợc chuyển vào trong mã chính, nó đợc sử dụng nh là cơ sở của các pha thựchiện

 Xây dựng sự ngịch đảo: một công cụ cao cấp có khả năng đọc đợc sự tồn tại

của mã tạo ra các mô hình từ đó Nh vậy có thể mô hình đợc tạo ra và sự tồn tạicủa mã hay sự phát triển đó có thể bị lặp lại giữa công việc mô hình hoá công cụhay lập trình

 Tích hợp với các công cụ khác: một công cụ sẽ có thể tích hợp với các công cụ

khác và với môi trờng phát triển nh là chức năng soạn thảo, dịch, sửa lổi với cáccông cụ khác nh sự điều hành xác nhận và phiên bản của các hệ điều hành

 Sự phủ của mô hình ở tất cả các mức trừu tợng: công cụ sẽ dễ dàng mô tả hệ

thống từ mức cao nhất đến mức thấp nhất là mức mã Nh việc truy nhập mã chomột phơng thức đặc trng của lớp, khi đó bạn sẽ nhắp chuột vào phơng thức trongsơ đồ

 Sự chuyển đổi các mô hình: một mô hình hay một sơ đồ riêng từ một mô hình

có thể đợc xuất ra từ một công cụ và đa vào một công cụ khác Nó nh là sựchuyển đổi các mô hình trong việc định nghĩa một ngôn ngữ

2.6.1 Trợ giúp vẽ:

Một công cụ phải nhanh và dễ dàng vẽ đợc sơ đồ Trong một thời gian dài khimột công cụ cấp cao nh công cụ CASE có thể tự gọi nó Nó không những cung cấpcác công cụ tiên tiến cho máy tính thực hiện việc chọn, đặt, kết nối và định nghĩacác thành phần trong một sơ đồ, Mà nhiều công cụ còn trợ giúp cho việc mô hìnhhoá các thành phần trong khi hiệu chỉnh một sơ đồ

Công cụ có thể hiểu đợc ngữ nghĩa của các thành phần do vậy nó có thể đa racảnh báo nếu một thành phần đợc sử dụng không đúng hoặc việc thể hiện một ph-

ơng thức không tơng thích với phơng thức khác

Công cụ cũng hổ trợ cho việc bố trí thiết kế các sơ đồ, những công cụ này chophép ngời mô hình hoá sắp xếp lại các thành phần và tự đông sắp xếp lại cácmessage, do vậy chúng không thể giao với mỗi công cụ khác Nhiều hệ thống thiết

kế có sự trợ giúp của máy tính (CAD), và máy tính có những giải thuật thông minh

để làm những công việc đó, ngoài ra nhiều công cụ cũng cung cấp công cụ có thểhọc đợc giống nh những hệ thống trên

Sơ đồ

Sơ đồ Tuần tự

Sơ đồ Cộng tác

Sơ đồ kích

Sơ đồ phát triển

Kho chung

2.6.2 Mô hình kho:

Công cụ CASE phải duy trì một mô hình kho, nó đa ra đợc một cơ sở dữ liệuvới tất cả thông tin của một số thành phần đợc sử dụng trong mô hình Kho này sẽchứa những thông tin cơ sở về toàn bộ mô hình, với mô hình xuyên suốt một số mô

hình nh hình 2.21.

Những nhiệm vụ mà công cụ có thể thực hiện đợc từ sự trợ giúp của một kholà:

 Kiểm tra sự tơng thích: nếu một thành phần đã đợc sử dụng không tơng thích

với các sơ đồ khác, khi đó công cụ phải đa ra cảnh báo hoặc ngăn cản nó Sơ

đồ phát triển phải đa ra đợc những cảnh báo khi một mô hình có thể xoá cácthành phần trong một sơ đồ mà thành phần đó còn đợc sử dụng trong sơ đồkhác Còn nếu nhất định xoá đi các thành phần đó thì nó phải đợc xoá trong tấtcả các sơ đồ khác có nó, khi đó ngời phát triển phải đi ngợc lại và cập nhật vàotất cả các sơ đồ khác

 Sự phê chuẩn: sử dụng thông tin trong một kho, một công cụ có thể phê chuẩn

một mô hình, các phần điểm vào không thể thể hiện hay ứng dụng mô hìnhHeuristics, nó thể hiện lỗi ở vấn đề hay giải pháp không hợp lý

 Sự tổng kết: Công cụ có thể tự động sinh ra toàn bộ và mở rộng tài liệu của tất

cả các thành phần là các lớp hay các sơ đồ trong mô hình nh hàng loạt thuậtngữ của dữ liệu

 Sử dụng lại các thành phần hoặc các sơ đồ: một kho có thể cung cấp để sử

dụng lại, các giải pháp mô hình hoá đó hoặc các phần của một giải pháp trongmột dự án có thể dễ dàng đợc sử dụng lại ở dự án khác Các thành phần trongmô hình UML là sự tích hợp của mã nguồn, do vậy cả mô hình và mã có thể đ-

ợc sử dụng lại trong những dự án khác

Giáo viên hớng dẫn ThS: Lê Văn Minh Thực hiện: Nguyễn Thị Thu Hơng

Hình 2.21 : Kho chung chứa tất cả các thông tin từ những sơ đồ có khả năng tạo

ra một mô hình thích hợp và có khả năng sinh ra các công cụ.

2.6.3 Sự điều hành:

Khi một số View và sơ đồ đợc sử dụng cùng với mô tả một hệ thống thì điềuquan trọng ở đây là có thể dễ dàng quản lý chúng, khi đó công cụ phải hỗ trợ đểthực hiện quản lý một cách dễ dàng hơn, nó phải dễ dàng tìm duyệt trên các sơ đồkhác nhau và thực hiện tìm kiếm với các phần tử mô hình

Phần tử sẽ có các siêu liên kết, những liên kết đó ta không thể nhìn thấy khi sơ

đồ đợc in ra, nhng chúng có thể truy nhập thông qua công cụ Nó có thể click bằng

chuột phải lên phần tử và sẽ hiện lên một menu pop-up hiển thị các phơng thức cho

khả năng điều hành Nh tìm kiếm một sơ đồ khác ở một phần tử hiện thời hay nhữngtruy nhập thông tin chi tiết về một phần tử Các phần của một sơ đồ có thể đ ợc mởrộng ra hoặc chia nhỏ, nó sẽ dễ dàng mở rộng và một khung nhìn bao quanh cácgói

Cách khác để điều hành sơ đồ một cách đầy đủ là định nghĩa các bộ lọc, nó cóthể phân tách hay ấn định một vài khía cạnh quan tâm đến sơ đồ, ví dụ nó chỉ ra mộtkiểu quan hệ hoặc lớp Bộ mô hình hoá sẽ điều khiển những cái đó, vì vậy chúng ta

có thể chỉ nghiên cứu phần quan trọng tại thời điểm đã cho

2.6.4 Hỗ trợ đa ngời dùng:

Công cụ sẽ cho phép nhiều ngời dùng làm việc hợp tác trên một mô hình nhnhau Đó là bỏ qua sự nhiễu loạn hay giao thoa với nhau, điển hình: ngời dùng làmviệc trên một sơ đồ sẽ xem nh không có gì có thể thay đổi nó tại một thời điểm Hơnnữa bất cứ sự thay đổi nào tạo ra các phần tử đợc chia sẻ trong kho sẽ đợc định danhbởi công cụ Nhng các quyết định về thay đổi hợp lệ phải đợc giải quyết bởi ngờidùng

ơng thức, phần thân của các phơng thức chứa mã thực thờng có dấu trống bên trái,

đợc điền bởi lập trình viên Mặc dù về mặt lý thuyết các phần của mô hình động có

Giáo viên hớng dẫn ThS: Lê Văn Minh Thực hiện: Nguyễn Thị Thu Hơng