II. Đánh giá giữa phân tích thiết kế theo hớng chức năng và hớng đố
2.3. Các cơ chế chung
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ột kiể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ủa kiể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ặc giớ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 trong cá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 cho chú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 đến nó.
Hình 2.12: Chữ Class đợc in đậm chỉ lớp, chữ An object class chỉ đối tợng
2.3.2. Các chú thích:
Không có gì có thể đợc định nghĩa trong ngôn ngữ mô hình với chủ đề bao quát hết ngôn ngữ. UML cung cấp khả năng chú thích. Một chú thích có thể đợc đặt bất cứ nơi nào trong một sơ đồ nào đó và nó có thể chứa một số kiểu thông tin. Kiểu thông tin của nó là một chuỗi không đợc giải thích bởi UML. Điển hình là một chú thích đ- ợc gắn tới một vài thành phần trong sơ đồ với đờng nét đứt, chỉ rõ thành phần đợ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ững vấ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 trng 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 đợc mô 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, khả năng tơng thích của một lớp. Đặc tả kiểu này thông thờng không đợc chỉ ra trong bản
Stock Option TheorPrice() MarketPrice() ExpireData() Dùng công thức Black & Schole
<<Actor>> Customer
Customer
Customer
thân sơ đồ. Nhng nó sẵn dùng trong công cụ đợc truy nhập bằng cách Double_Click
trên phần tử có cửa sổ đặc tả với tất cả các thuộc tính.
2.4. Mở rộng UML:
UML có thể đợc mở rộng và phù hợp với một phơng pháp đặc biệt, một tổ chức hoặc ngời sử dụng, chúng ta sẽ xem xét cả 3 cơ chế đợc mở rộng là: các mẫu có sẵn, các giá trị đã đợc gán nhãn, và các ràng buộc.
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ời chú 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ố đơn giả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ết nố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ản vớ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ẫu hoặ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.
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ở
Instrument (abstract) (Author = “HEE”) (Status = Draft) value : int expdate: date 0..1
(Người với tuổi > 60) Nhóm người cao
tuổi
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ác phầ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ình hoá, 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ại thô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ày chỉ 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àng buộ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ống thực hiện không đúng. ở trờng hợp này thì ràng buộc đợc định nghĩa và đợc trực tiế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.
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.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ựng khô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ình lớ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 trong mô 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ặc cá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 dung củ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).
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ác nhau. Đó 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ểm soá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ến trì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ằng cá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ến tố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ác node 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ác thà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ột sơ đồ 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 tin thu đợ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ột phé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ợp vớ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).
Cuối cùng, mô hình đã đợc thực hiện trong một số loại nguyên mẫu, nó đánh giá 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ệc vắ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ặc nhữ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ực hiện khi các sơ đồ cùng đợc định kiểu. Mẫu đã đợc cấu trúc có thể bị bỏ đi hoàn toà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ác tiến trình phát triển thực.
Những ý kiến hay Bản phác thảo Thiết lập Vào: tri thức, các vấn đề về sự giải mã, các đích Tạo ra các mô hình:
Một tiến trình công việc thực tế
Sử dụng các công cự thông tin như: hộp trắng
và 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ế
Sự tổng hợp Sự kiểm tra Sự phê chuẫn
Sự định kiểu Và sự kiểm tra
Đánh giá
Thiết lập thông tin tóm tắt trong một công cụ để đưa ra
những dạng sơ đồ
Xác định nội dung của sơ đồ (như tổng hợp tiến trình và một
số mô hình thông minh) Kiểm tra sơ đồ, kiểm tra lại các sơ đồ khác, kiểm tra và đánh giá những yêu cầu đó
đã thích hợp chưa Tạo ra các mẫu và kiểm tra nó (một số sơ đồ được định mẫu ở
bước đầu tiên)
(Kết quả được thoả mãn)
(Dạng chưa thoả mãn) khi có bất kỳ một dạng chưĐánh giá kết quả: quay lại a thỏa mãn nào
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àm xong 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 duy trì, đồ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ểm tra độ 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, nh vậ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
đặ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 ít hơ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áo hoặ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ếu tên của lớp bị chuyển đổi trong sơ đồ thì sự chuyển đổi đó phải đợc phản ánh trong 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ững mô hình khác.
•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ực