Khi viết bài, tôi gặp rất nhiều khó khăn trong việc tìm kiếm thông tin. Đơn giản là không có thông tin. Sau một thời gian dài tìm hiểu trên các trang của Google, hóa ra thuật ngữ thiết kế trong tiếng Nga có phần khác. Trong tiếng Nga, thiết kế là một trong những giai đoạn phát triển phần mềm và là ngành học nghiên cứu các vấn đề về tạo và quản lý dự án, phương pháp thiết kế, v.v. được gọi là công nghệ phần mềm hoặc công nghệ lập trình công nghiệp (nếu hoàn toàn bằng tiếng Nga). Nếu vẫn còn những người chưa biết điều này, thì có lẽ nhận xét của tôi sẽ giúp bạn một chút.

Tất cả đã bắt đầu như thế nào

Lịch sử phát triển của quản lý dự án như vậy bắt nguồn từ Con tàu của Nô-ê và cuộc săn lùng tập thể của những người nguyên thủy để tìm một con voi ma mút. Hơn nữa, một số yếu tố quản lý dự án có thể được nhìn thấy trong hành vi của những kẻ săn mồi săn mồi theo bầy.

Vào thời cổ đại, thiết kế gắn liền với “khoa học của kiến ​​trúc sư” và khoa học này không chỉ gắn liền với việc xây dựng các tòa nhà mà còn với việc tạo ra các máy móc xây dựng và quân sự của kỹ sư và kiến ​​trúc sư La Mã Mark Vitruvius vào thế kỷ thứ nhất. BC trong chuyên luận "10 cuốn sách về kiến ​​trúc" đã đưa ra định nghĩa về thiết kế như sau:
Về lý thuyết - để thể hiện và biện minh cho màn trình diễn phù hợp với yêu cầu của nghệ thuật và tính hiệu quả.
Theo nghĩa thực tế - việc thực hiện công việc của bàn tay con người từ bất kỳ vật liệu nào theo một bản vẽ nhất định.

Tuy nhiên, lịch sử phát triển của quản lý dự án như một môn học còn khá trẻ: nó bắt đầu từ những năm 30 của thế kỷ 20 và gắn liền với sự phát triển của các phương pháp đặc biệt để điều phối kỹ thuật của các dự án lớn ở Hoa Kỳ - ngành hàng không tại US Air Corporation và dầu khí tại Exon. Ở Liên Xô, trong cùng thời kỳ, lý thuyết và thực tiễn về tổ chức dòng chảy công việc để thực hiện các dự án xây dựng lớn bắt đầu phát triển.

Sự xuất hiện của một môn học mới

Điều kiện tiên quyết để đưa các nguyên tắc quản lý dự án vào quy trình phát triển phần mềm bắt nguồn từ cuối những năm 60 và đầu những năm 70 của thế kỷ trước, khi một sự kiện xảy ra đã đi vào lịch sử là cuộc khủng hoảng lập trình đầu tiên. Sự kiện này nằm ở chỗ chi phí phần mềm bắt đầu tiệm cận với chi phí phần cứng ("phần cứng") và động lực tăng trưởng của những chi phí này khiến người ta có thể dự đoán rằng vào giữa những năm 90, toàn bộ nhân loại sẽ phát triển phần mềm cho máy tính. Sự phát triển của vi điện tử đã dẫn đến hiệu suất của máy tính tăng mạnh với chi phí giảm đáng kể. Các hạn chế đối với phần cứng bắt đầu biến mất, các hạn chế còn lại rơi vào phần mềm. Điều này dẫn đến khả năng xây dựng chương trình mới bị tụt hậu so với yêu cầu đối với chương trình mới.
Một xu hướng phát triển khác bắt nguồn từ chính ngành công nghiệp và dựa trên quan điểm ngày càng tăng về phát triển phần mềm không chỉ là "viết mã". Thay vào đó, phần mềm được coi là có một vòng đời hoàn chỉnh, từ ý tưởng thông qua thiết kế, phát triển, triển khai, bảo trì và phát triển. Sự thay đổi trọng tâm khỏi viết mã đã tạo ra sự phát triển của các phương pháp luận và công cụ tiên tiến có các nhóm kỹ sư được trang bị vũ khí tham gia vào tất cả các giai đoạn của vòng đời phần mềm.
Sau đó, họ bắt đầu nói về công nghệ phần mềm (công nghệ lập trình công nghiệp) như một ngành học nhất định, mục đích của nó là giảm chi phí cho các chương trình. Một vấn đề như vậy nên được giải quyết bởi một tổ chức có thẩm quyền hơn của quá trình phát triển. Điều này dẫn đến sự phát triển của các phương pháp luận thiết kế phần mềm và nâng nó lên thành các thành phần chi phối của sự phát triển.

Thuật ngữ công nghệ phần mềm lần đầu tiên được sử dụng vào năm 1968 như là chủ đề của một hội nghị dành riêng cho việc tối đa hóa tải trên các máy tính mạnh nhất (vào thời điểm đó).
Định nghĩa đặt nền móng cho một ngành khoa học và thực tiễn mới: cần phải tạo ra một hệ thống các nguyên tắc kỹ thuật áp dụng cho phát triển phần mềm, để đảm bảo tính kinh tế và độ tin cậy của quá trình phát triển, cũng như hiệu suất hiệu quả của sản phẩm cuối cùng trên nhiều môi trường thực tế khác nhau. máy móc.

Vì vậy, công nghệ phần mềm là một nguyên tắc kỹ thuật liên quan đến tất cả các khía cạnh của sản xuất phần mềm từ các giai đoạn ban đầu của việc tạo ra một đặc tả để duy trì hệ thống sau khi chạy thử.

Các phương pháp trong công nghệ phần mềm

Kể từ thời điểm này, lập trình "có được" nhiều hoạt động bổ sung khác nhau: phát triển yêu cầu, lập kế hoạch, thử nghiệm, quản lý cấu hình, quản lý dự án, tạo các tài liệu khác nhau (dự án, người dùng, v.v.). Việc phát triển mã chương trình được thực hiện trước khi phân tích và thiết kế (đầu tiên có nghĩa là tạo ra một mô hình chức năng của hệ thống tương lai mà không tính đến việc triển khai, để các lập trình viên hiểu được các yêu cầu và mong đợi của khách hàng; thứ hai có nghĩa là sơ bộ bố cục, phác họa, sơ đồ hệ thống trên giấy).
Tất cả những hoạt động này và các hoạt động bổ sung khác được thực hiện trong quá trình lập trình công nghiệp và cần thiết để thực hiện thành công các đơn đặt hàng sẽ được gọi là công nghệ phần mềm. Hóa ra đây là cách chúng ta chỉ định, thứ nhất, một số hoạt động thực tế và thứ hai, một lĩnh vực kiến ​​​​thức đặc biệt. Hay nói cách khác, một ngành khoa học. Thật vậy, để tạo điều kiện thuận lợi cho việc triển khai từng dự án riêng lẻ, để có thể sử dụng nhiều trải nghiệm tích cực mà các nhóm và nhà phát triển khác đạt được, chính trải nghiệm này phải được hiểu, khái quát hóa và thiết kế phù hợp. Đây là cách các phương pháp và thực tiễn khác nhau (thực tiễn tốt nhất) xuất hiện - thử nghiệm, thiết kế, làm việc theo yêu cầu, v.v., các mẫu kiến ​​​​trúc, v.v. Cũng như các tiêu chuẩn và phương pháp liên quan đến toàn bộ quy trình. Chính những khái quát hóa này được đưa vào công nghệ phần mềm như một lĩnh vực tri thức.
Do đó, các phương pháp luận trong công nghệ phần mềm là một trong những thành phần phát triển năng động nhất của lĩnh vực tri thức, bởi vì. có một thành phần thực tế.
Việc phân loại hiện đại các phương pháp quản lý dự án hoặc mô hình vòng đời dự án theo SWEBOK như sau.
Các phương pháp quản lý dự án:

• mô hình (thác, thác) truyền thống;
• mô hình xoắn ốc;
• mô hình lặp đi lặp lại và gia tăng (phương pháp tiến hóa).

Tìm hiểu thêm về các phương pháp

Như tên của nó, các phương pháp truyền thống được xây dựng dựa trên việc thực hiện tuần tự tất cả các giai đoạn của dự án và sản phẩm cuối cùng sẽ chỉ thu được sau khi tất cả các giai đoạn đã được hoàn thành. Việc quay lại giai đoạn trước không được cung cấp và khi các lỗi nghiêm trọng xuất hiện, toàn bộ dự án sẽ bắt đầu lại. Một ví dụ điển hình của các phương pháp phát triển như vậy là mô hình Thác nước hoặc Thác nước. Nguồn của mô hình này được coi là một bài báo của Winston Royce xuất bản năm 1970. Tuy nhiên, chính Royce đã mô tả mô hình này như một ví dụ về mô hình lặp lại, chỉ áp dụng cho các dự án rất đơn giản và bản thân ông đã sử dụng các phương pháp lặp đi lặp lại. Royce cũng viết rằng trong các lĩnh vực đặc biệt khó khăn của dự án và khi sử dụng các công nghệ mới chưa được sử dụng trước đây, các bước trung gian có thể được lặp lại hai lần và khách hàng nhận được phiên bản thứ hai của sản phẩm khi kết thúc dự án. Cách tiếp cận này không thể được gọi là lặp đi lặp lại, nhưng nó cũng nhất quán duy nhất. Nó đã đóng một vai trò hàng đầu trong những ngày đầu tiên như một phương pháp để phát triển thường xuyên phần mềm phức tạp. Vào những năm 70 - 80 của thế kỷ XX, mô hình này đã được Bộ Quốc phòng Hoa Kỳ lấy làm tiêu chuẩn.
Với sự phát triển của các phương pháp luận, mô hình xếp tầng đã phải chịu sự chỉ trích gay gắt từ tất cả các nhà nghiên cứu đề xuất các phương pháp luận của riêng họ. Việc thực hiện nhất quán các giai đoạn phát triển không cho phép thay đổi các yêu cầu đối với sản phẩm phần mềm cho đến khi chính bản phát hành. Dự án càng lớn thì càng có nhiều vấn đề tích lũy trong quá trình thiết kế. Và việc thực hiện các thay đổi trong phiên bản tiếp theo của sản phẩm đôi khi trở nên không phù hợp. Sản phẩm phải được viết bằng 0 . Do đó, chi phí của một phiên bản khả thi không hợp lý đang tăng mạnh. Và tỷ lệ dự án hoàn thành thành công là không đáng kể. Tuy nhiên, liệu các phương pháp phát triển truyền thống có thể bị coi là lỗi thời? Không thực sự. Đối với các dự án ảnh hưởng đến an toàn tính mạng, các yêu cầu được xác định chặt chẽ và mức độ chính thức hóa cao là yếu tố cơ bản và cần thiết.
Ngoài ra, bất chấp sự chỉ trích thời thượng đối với mô hình truyền thống, nó đóng một vai trò quan trọng, bởi vì nó đặt ra cho quá trình phát triển yêu cầu về một kỷ luật rất cần thiết đối với nó, với sự trợ giúp của nó, có thể bỏ qua một cách an toàn phi cấu trúc “ quá trình viết và chỉnh sửa”. Mô hình này đã đóng góp cơ bản cho sự hiểu biết về các quy trình phát triển phần mềm với các phát biểu sau:

• quá trình này phải tuân theo kỷ luật, lập kế hoạch và quản lý hợp lý;
• việc triển khai sản phẩm nên được trì hoãn cho đến khi các mục tiêu của việc triển khai này được hiểu đầy đủ.

Mô hình vòng đời xoắn ốc đã trở thành giai đoạn tiếp theo (sau thác nước) trong quá trình phát triển các phương pháp luận phát triển, vì nó giải quyết được vấn đề chính của mô hình thác nước. Mỗi giai đoạn của quy trình phát triển thác nước xoắn ốc kết thúc bằng giai đoạn tạo nguyên mẫu và quản lý rủi ro. Giai đoạn tạo mẫu sau mỗi giai đoạn của dự án cho phép bạn xác định trạng thái hiện tại của dự án tương ứng với kế hoạch ban đầu như thế nào. Dựa trên kết quả của việc tạo nguyên mẫu, quá trình chuyển đổi sang giai đoạn tiếp theo được thực hiện hoặc quay lại một trong các giai đoạn trước đó. Tuy nhiên, các pha và trình tự pha vẫn tuyến tính. Tác giả của mô hình này là Barry Boehm, người đã xuất bản bài báo "A Spiral Model of Software Development and Enhancement" vào năm 1988. Mặc dù thực tế là trong SWEBOK, mô hình này được phân biệt riêng với mô hình lặp, nhưng việc mô tả các mô hình dẫn đến kết luận rằng phương pháp xoắn ốc thuộc họ phương pháp lặp. Điều này cũng là do khả năng thay đổi yêu cầu giữa các giai đoạn và phát hành nguyên mẫu sản phẩm sau mỗi chu kỳ. Có lẽ sự phân chia này là do quyền tác giả của các phương pháp luận.

Mô hình lặp liên quan đến việc chia nhỏ vòng đời của một dự án thành một chuỗi các bước lặp, mỗi bước giống như một “dự án nhỏ”, bao gồm tất cả các giai đoạn của vòng đời như được áp dụng để tạo ra các phần nhỏ hơn của chức năng, so với dự án như một tổng thể. Các tài liệu tham khảo về phương pháp này đã bắt đầu xuất hiện từ lâu trước bài viết của W. Royce và sự xuất hiện của chính công nghệ phần mềm. Nguồn gốc của khái niệm phát triển lặp lại có thể bắt nguồn từ những năm 1930 bởi chuyên gia chất lượng sản phẩm Walter Shewart của Bell Labs. Một dấu mốc quan trọng trong lịch sử là dự án được thực hiện vào những năm 50 để phát triển máy bay phản lực siêu âm X-15. Theo những người tham gia các công trình này, việc áp dụng phương pháp này phần lớn quyết định sự thành công của dự án.
Các phương pháp phát triển Agile (phương pháp Agile) được thảo luận nhiều nhất hiện nay đề cập cụ thể đến các mô hình vòng đời lặp đi lặp lại. Khi mô tả bất kỳ phương pháp linh hoạt nào, nguyên tắc phân chia thành các lần lặp lại được đề cập. Tuy nhiên, điểm đặc biệt của các phương pháp này là nhấn mạnh vào yếu tố con người chứ không phải tài liệu dự án, điều này không được chỉ ra theo bất kỳ cách nào trong phần mô tả về phương pháp lặp đi lặp lại và gia tăng.

Các phương pháp phát triển linh hoạt bắt đầu xuất hiện trong bối cảnh công nghệ ngày càng tinh vi và thông tin hóa toàn cầu đang phát triển nhanh chóng. Bây giờ khách hàng trong hầu hết các trường hợp là một người ở xa công nghệ thông tin. Đối với một khách hàng như vậy, điều chính yếu là thành phẩm chứ không phải các tài liệu. Với tốc độ phát triển công nghệ thông tin ngày càng tăng theo cấp số nhân, các thuật ngữ về phát triển phần mềm đã được giảm bớt và trở nên khó khăn hơn. Bây giờ không có thời gian để lập kế hoạch dài, viết tài liệu và kiểm tra đầy đủ. Một sản phẩm phần mềm có thể lỗi thời trước khi phát hành. Trái ngược với các phương pháp phát triển truyền thống, các phương pháp lặp lại phân chia việc thực hiện dự án thành các lần lặp lại ngắn, có giới hạn thời gian. Sau mỗi lần lặp, kết quả được cung cấp cho khách hàng của sản phẩm. Quay lại các lần lặp lại trước đó được cung cấp. Sự xuất hiện của các phương pháp linh hoạt không bị ràng buộc vào một ngày cụ thể, vì bắt đầu từ giữa những năm 90, chúng bắt đầu xuất hiện và được giới thiệu gần như song song. Đó là các phương pháp phát triển như: Scrum (1995), Extreme Programming (1996), Crystal Clear, Lean, Kanban và những phương pháp khác. Được tạo ra vào tháng 2 năm 2001, Tuyên ngôn Agile tuyên bố triết lý của các phương pháp phát triển nhanh và thiết lập véc tơ cho sự phát triển của các phương pháp này.

Giai đoạn phát triển hiện tại của các phương pháp

Hơn bao giờ hết, việc lựa chọn phương pháp thiết kế chịu ảnh hưởng của tiếp thị. Ngày càng có nhiều chuyên gia tư vấn triển khai nhanh, huấn luyện viên tiến hành các khóa đào tạo, hội thảo, hội thảo trên web, các cuộc họp, hội nghị, bàn tròn bất tận. Tất cả những sự kiện này nhằm mục đích bán việc triển khai trong các công ty CNTT để kiếm được số tiền lớn bởi các chuyên gia được mời hoặc tăng xếp hạng của các công ty đã triển khai các phương pháp nhanh nhẹn.
Các phương pháp linh hoạt giờ đây giống như một khối kiến ​​​​thức về tổ chức công việc của mọi người theo quan điểm tâm lý học. Những phương pháp như vậy giúp nhóm thể hiện sự sáng tạo, tinh thần đồng đội, kỹ năng giao tiếp, v.v. Khía cạnh kỹ thuật của tổ chức công việc đang ngày càng lùi vào hậu cảnh. Chỉ XP (Lập trình cực đoan) mới có trong kho vũ khí của mình các thực hành kỹ thuật như phát triển dựa trên thử nghiệm, phép ẩn dụ và tái cấu trúc. Những thực hành này được áp dụng thành công kết hợp với các phương pháp khác. Với việc triển khai Agile kém chất lượng, chúng ta có được những gì đang xảy ra hiện nay trên thị trường sản phẩm CNTT. Thị trường quá bão hòa với các sản phẩm chất lượng thấp, không ổn định, không đáp ứng các yêu cầu về chức năng hoặc giao diện. Đồng thời, tốc độ phát hành của các sản phẩm như vậy, nhờ vào nguyên tắc tích hợp liên tục do Agile thúc đẩy, không ngừng tăng lên.

Với sự suy giảm ngày càng tăng về chất lượng của các sản phẩm CNTT được sản xuất, các phương pháp bắt đầu xuất hiện để tìm cách cải thiện chất lượng này. DEvOps đã trở thành một phương pháp như vậy.
Thuật ngữ "devops" đã được phổ biến rộng rãi tại hội nghị "DevOps Days" vào năm 2009 tại Bỉ. Kể từ đó, phương pháp này ngày càng trở nên phổ biến, một phần là do các nguyên tắc của DevOP không ủng hộ việc từ bỏ phương pháp hiện tại trong tổ chức mà kết hợp với nó. Khái niệm chung về DevOps là tăng cường sự hợp tác giữa các nhóm phát triển (DEVelopments) và nhóm vận hành (OPerations) trong cùng một tổ chức chịu trách nhiệm phát triển phần mềm. Không cường điệu, phương pháp này là một vòng mới trong quá trình phát triển của các phương pháp phát triển, vì nó không chỉ tập trung vào việc đáp ứng các yêu cầu của khách hàng trong một khung thời gian được xác định nghiêm ngặt mà còn tập trung vào việc cải thiện chất lượng và độ ổn định của sản phẩm.

Cuối cùng, tôi muốn nói thêm rằng chủ đề được tiết lộ trong bài báo là một trong những thành phần của đồ án tốt nghiệp của tôi. Đó là lý do tại sao mục đích của bài viết này là ý kiến ​​​​của những người có kinh nghiệm và hiểu biết về vấn đề này, vì vậy các bình luận dưới bất kỳ hình thức nào (và đặc biệt là về chủ đề này) đều rất được hoan nghênh.

nguồn

Quản lý dự án phát triển phần mềm. Bộ môn "Các công nghệ phát triển phần mềm linh hoạt" tác giả: D.G. Shopyrin

Nếu nó có vẻ giống như một công việc để làm
dễ thì chắc chắn sẽ khó.
Nếu nó có vẻ khó khăn, sau đó
nó là hoàn toàn không thể để làm như vậy.
định lý Stackmyer

Công nghệ thiết kế ASOIU- một tập hợp các phương pháp luận, cũng như các phương pháp và phương tiện tổ chức quá trình thiết kế (quản lý quá trình phát triển và hiện đại hóa dự án).
Một phương pháp thiết kế là một khái niệm/nguyên tắc thiết kế được thực hiện bởi một tập hợp các thực hành thiết kế được hỗ trợ bởi các công cụ thiết kế.
Phương pháp (cách tiếp cận) thiết kế - một thuật toán / trình tự các bước để thực hiện một hoặc một giai đoạn khác của việc tạo ASOIU.
Nguyên tắc chính của việc xây dựng các hệ thống khác nhau - nguyên tắc phân tách theo thứ bậc bao gồm hai nhóm phương pháp:

1. Nhóm phương pháp cấu trúc-chức năng, dựa trên nguyên tắc phân rã chức năng: cấu trúc của hệ thống được mô tả dưới dạng phân cấp các chức năng của nó và chuyển thông tin giữa các phần tử chức năng riêng lẻ.
2. sử dụng phân rã đối tượng. Trong trường hợp này, cấu trúc của hệ thống được mô tả dưới dạng các đối tượng và mối quan hệ giữa chúng, và hành vi của hệ thống được mô tả dưới dạng trao đổi thông điệp giữa các đối tượng.

Phương pháp cấu trúc-chức năng

Phân tích và thiết kế kết cấu sử dụng các mô hình khác nhau để mô tả:

1. Cấu trúc chức năng của hệ thống;
2. Trình tự các hành động được thực hiện;
3. Chuyển giao thông tin giữa các quy trình chức năng;
4. Mối quan hệ giữa các dữ liệu.

Các triển khai phổ biến nhất của các mô hình này là:

1. Mô hình SADT chức năng(Kỹ thuật thiết kế và phân tích cấu trúc);
2. Mô hình IDEF3;
3. DFD (Sơ đồ luồng dữ liệu)- sơ đồ các luồng dữ liệu.
4. Sơ đồ mối quan hệ thực thể(ERD - Sơ đồ mối quan hệ thực thể).

Phương pháp SADTđược phát triển bởi Douglas Ross (SoftTech, Inc.) vào năm 1969 và đã được sử dụng thành công trong quân đội Hoa Kỳ, các tổ chức công nghiệp và thương mại để giải quyết nhiều vấn đề khác nhau. Phương pháp SADT được hỗ trợ bởi Bộ Quốc phòng Hoa Kỳ, cơ quan đã khởi xướng sự phát triển của nhóm tiêu chuẩn IDEF (Icam DEFinition), là phần chính của chương trình ICAM (Tin học hóa Sản xuất Tích hợp) do Lực lượng Không quân Hoa Kỳ khởi xướng. Phương pháp SADT được triển khai theo một trong các tiêu chuẩn của họ này - IDEF0, phiên bản mới nhất được phát hành vào tháng 12 năm 1993 bởi Viện Tiêu chuẩn và Công nghệ Quốc gia Hoa Kỳ (NIST). Năm 2000, theo nghị định của Tiêu chuẩn Nhà nước Nga, tài liệu hướng dẫn RD IDEF0 - 2000 đã có hiệu lực, chứa thông tin cơ bản về phương pháp mô hình hóa chức năng IDEF0, ngôn ngữ đồ họa của nó và phương pháp xây dựng và ứng dụng thực tế các mô hình chức năng của hệ thống tổ chức, kinh tế và sản xuất, kỹ thuật. Ngoài ra, RD IDEF0 - 2000 thiết lập các quy tắc để thiết kế một tập hợp các sơ đồ phân cấp.

Phương pháp IDEF0 dựa trên bốn khái niệm chính: khối chức năng, vòng cung giao diện, phân tách, bảng thuật ngữ.
Khối chức năng (Activity Box)đại diện cho một số chức năng cụ thể trong hệ thống được xem xét. Trong sơ đồ, một khối chức năng được thể hiện bằng một hình chữ nhật. Mỗi trong số bốn mặt của khối chức năng có ý nghĩa (vai trò) cụ thể của riêng nó, trong khi:

• mặt trên được đặt thành "Điều khiển";
• phía bên trái có giá trị "Đầu vào" (Input);
• phía bên phải được đặt thành "Đầu ra";
• phía dưới có giá trị "Cơ chế" (Mechanism).

Trong văn bản thuyết minh về sơ đồ ngữ cảnh cần chỉ rõ mục đích (Purpose) của việc xây dựng sơ đồ dưới dạng mô tả ngắn gọn và cố định quan điểm (Viewpoint).

Phương pháp lập mô hình IDEF3, là một phần của họ tiêu chuẩn IDEF, được phát triển vào cuối những năm 1980. Phương pháp này dành cho các mô hình quy trình trong đó điều quan trọng là phải hiểu chuỗi hành động và sự phụ thuộc lẫn nhau giữa chúng.
Đơn vị công việc - Unit of Work (UOW) (công việc), là các thành phần trung tâm của mô hình. Trong IDEF3, các công việc được thể hiện bằng các hình chữ nhật và có tên biểu thị quy trình của hành động và một số (số nhận dạng).
liên kết IDEF3 thể hiện mối quan hệ giữa các công việc. Tất cả các liên kết trong IDEF3 là một chiều và có các loại sau:

• ưu tiên tạm thời,
• luồng đối tượng,
• quan hệ mập mờ.

ngã tư đường- được sử dụng để hiển thị logic về cách các mũi tên tương tác khi hợp nhất và rẽ nhánh hoặc để hiển thị một tập hợp các sự kiện có thể hoặc phải được hoàn thành trước khi bắt đầu công việc tiếp theo.

Sơ đồ luồng dữ liệu (DFD)đại diện cho một hệ thống phân cấp của các quy trình chức năng được kết nối bởi các luồng dữ liệu. Mục đích của biểu diễn này là chỉ ra cách mỗi quá trình chuyển đổi đầu vào của nó thành đầu ra và tiết lộ mối quan hệ giữa các quá trình này.
Theo phương pháp này, mô hình hệ thống được định nghĩa là một hệ thống phân cấp các sơ đồ luồng dữ liệu mô tả quá trình chuyển đổi thông tin không đồng bộ từ đầu vào của nó vào hệ thống để phát hành cho người tiêu dùng. Các nguồn thông tin (các thực thể bên ngoài) tạo ra các luồng thông tin (luồng dữ liệu) chuyển thông tin đến các hệ thống con hoặc quy trình. Đổi lại, chúng biến đổi thông tin và tạo ra các luồng mới chuyển thông tin sang các quy trình hoặc hệ thống con khác, bộ lưu trữ dữ liệu hoặc các thực thể bên ngoài - người tiêu dùng thông tin.

Khi tạo sơ đồ luồng dữ liệu, bốn khái niệm cơ bản được sử dụng:

• luồng dữ liệu,
• quy trình (công việc) chuyển đổi luồng dữ liệu đầu vào thành luồng dữ liệu đầu ra,
• thực thể bên ngoài,
• thiết bị lưu trữ dữ liệu (storages).

SADT được tạo ra như một công cụ để mô hình hóa các hệ thống nói chung, và DFD là một công cụ thiết kế IS, vì vậy DFD càng hứa hẹn để sử dụng, DFD càng phù hợp với ERD, vì DFD chứa mô tả cấu trúc dữ liệu được sử dụng trực tiếp để xây dựng ERD.

Mô hình hóa dữ liệu là cần thiết để cung cấp cho nhà phát triển AIS một lược đồ cơ sở dữ liệu khái niệm ở dạng một mô hình đơn lẻ hoặc nhiều mô hình cục bộ có thể được ánh xạ tương đối dễ dàng tới bất kỳ hệ thống cơ sở dữ liệu nào.

Công cụ mô hình hóa dữ liệu phổ biến nhất là Sơ đồ mối quan hệ thực thể (ERD), lần đầu tiên được giới thiệu bởi Peter Chen vào năm 1976. Các khái niệm cơ bản của ERD là: (thực thể), thuộc tính của chúng (thuộc tính) và mối quan hệ với nhau (quan hệ). Ngoài ra, ERD được liên kết với các khái niệm như: số lượng và loại mối quan hệ, khóa chính và khóa ngoại, chỉ mục, chuẩn hóa biểu đồ, v.v.

Phương pháp hướng đối tượng

Cách tiếp cận hướng đối tượng để phát triển hệ thống đã đạt được thành công vào những năm 1990.
Cách tiếp cận đối tượng để phát triển hệ thống tuân theo một quá trình lặp đi lặp lại với việc xây dựng năng lực. Một mô hình duy nhất được cụ thể hóa trong các giai đoạn phân tích, thiết kế và triển khai - do lặp lại thành công, các chi tiết mới được thêm vào, các thay đổi và cải tiến được đưa ra khi cần thiết.

Phương pháp hướng đối tượng có những ưu điểm sau:

• Việc sử dụng cách tiếp cận đối tượng làm tăng đáng kể mức độ thống nhất phát triển và khả năng sử dụng lại, dẫn đến việc tạo ra môi trường phát triển và chuyển sang tạo mô hình lắp ráp.
• Sự phân tách đối tượng tránh được việc tạo ra các mô hình phức tạp, vì nó liên quan đến một lộ trình tiến hóa để phát triển một mô hình dựa trên các hệ thống con tương đối nhỏ.
• Mô hình đối tượng là tự nhiên vì nó tập trung vào nhận thức của con người về thế giới.

Nhược điểm của phương pháp hướng đối tượng bao gồm:

• chi phí ban đầu cao. Cách tiếp cận này không mang lại lợi nhuận ngay lập tức. Hiệu quả của ứng dụng của nó được cảm nhận sau khi phát triển hai hoặc ba dự án và tích lũy các thành phần có thể tái sử dụng.
• Khó quản lý dự án. Các nhà quản lý đo lường tiến độ phát triển thông qua các phân tích công việc được xác định rõ ràng, các hạng mục phạm vi và các mốc quan trọng. Trong quá trình phát triển đối tượng thông qua “chi tiết hóa”, không có ranh giới rõ ràng giữa các giai đoạn và tài liệu thiết kế không ngừng phát triển. Một giải pháp có thể chấp nhận được trong tình huống này là chia dự án thành các mô-đun nhỏ và quản lý tiến độ phát triển bằng cách thường xuyên phát hành các phiên bản thực thi được của các mô-đun này (một số bản phát hành này có thể dành cho sử dụng nội bộ và một số khác có thể được chuyển giao cho khách hàng).
• Tăng độ phức tạp của giải pháp, do đó, ảnh hưởng đến các đặc điểm phần mềm như khả năng bảo trì và khả năng mở rộng.

Cơ sở khái niệm của phương pháp hướng đối tượng là mô hình đối tượng, được xây dựng có tính đến các nguyên tắc sau:

• trừu tượng- đây là sự lựa chọn các đặc điểm cơ bản, quan trọng nhất của một đối tượng giúp phân biệt nó với tất cả các loại đối tượng khác và do đó, xác định rõ ranh giới khái niệm của nó từ quan điểm xem xét và phân tích thêm, và bỏ qua những điều ít quan trọng hơn hoặc không đáng kể chi tiết.
• đóng gói- bản địa hóa vật lý các thuộc tính và hành vi trong một trừu tượng hóa duy nhất (được coi là "hộp đen"), ẩn việc triển khai chúng đằng sau giao diện công cộng.
• tính mô đun- đây là một thuộc tính của hệ thống liên quan đến khả năng phân hủy của nó thành một số hệ thống con (mô-đun) được liên kết chặt chẽ bên trong nhưng được liên kết yếu với nhau.
• Hệ thống cấp bậc- đây là một hệ thống trừu tượng được xếp hạng hoặc sắp xếp theo cấp độ.

Các khái niệm cơ bản của phương pháp hướng đối tượng là đối tượng và lớp.
Một đối tượng- một đối tượng hoặc hiện tượng có hành vi được xác định rõ ràng và có trạng thái, hành vi và tính cách. Cấu trúc và hành vi của các đối tượng tương tự xác định một lớp chung cho chúng. Một lớp là một tập hợp các đối tượng có liên quan với nhau bởi một cấu trúc và hành vi chung. Nhóm các khái niệm quan trọng tiếp theo của cách tiếp cận đối tượng là tính kế thừa và tính đa hình. Khái niệm đa hình có thể được hiểu là khả năng một lớp thuộc về nhiều hơn một kiểu.
Di sản có nghĩa là xây dựng các lớp mới dựa trên các lớp hiện có với khả năng thêm hoặc ghi đè dữ liệu và phương thức. Các đối tượng của cùng một lớp có các thao tác và thuộc tính giống nhau nhưng giá trị thuộc tính của chúng có thể khác nhau.
trạng thái đối tượngđược xác định bởi các giá trị thuộc tính của nó; hành vi là hoạt động của nó. Khi gọi các thao tác có thể làm thay đổi giá trị các thuộc tính của đối tượng, đối tượng có thể chuyển từ trạng thái này sang trạng thái khác. Để thực hiện các chức năng của hệ thống, các liên kết được thiết lập giữa các đối tượng thông qua đó chúng trao đổi thông điệp.

Giới thiệu về Ngôn ngữ mô hình hóa thống nhất (UML)

Ngôn ngữ mô hình hóa thống nhất (UML) là một phương tiện để đạt được sự thỏa hiệp giữa các cách tiếp cận này. Có đủ số lượng công cụ hỗ trợ vòng đời của các hệ thống thông tin với sự trợ giúp của UML, đồng thời, UML đủ linh hoạt để tùy chỉnh và hỗ trợ các hoạt động cụ thể của các nhóm phát triển khác nhau.

Động lực mạnh mẽ cho sự phát triển của lĩnh vực công nghệ thông tin nàyđã tạo ra các ngôn ngữ lập trình hướng đối tượng vào cuối những năm 1980 và đầu những năm 1990. Người dùng muốn có một ngôn ngữ lập mô hình thống nhất có thể kết hợp tất cả sức mạnh của phương pháp hướng đối tượng và đưa ra một mô hình rõ ràng về hệ thống, phản ánh tất cả các khía cạnh quan trọng của nó. Vào giữa những năm 1990, các phương pháp Booch (Grady Booch), OMT-2 (Jim Rumbaugh), OOSE - Kỹ thuật phần mềm hướng đối tượng (Ivar Jacobson) đã trở thành những nhà lãnh đạo rõ ràng trong lĩnh vực này. Tuy nhiên, ba phương pháp này có điểm mạnh và điểm yếu: OOSE là tốt nhất ở giai đoạn phân tích miền vấn đề và phân tích yêu cầu hệ thống, OMT-2 được ưa thích nhất ở giai đoạn phân tích và phát triển hệ thống thông tin, Booch phù hợp nhất cho thiết kế và các giai đoạn phát triển.
Mọi thứ hướng tới việc tạo ra một ngôn ngữ duy nhất kết hợp các điểm mạnh của các phương pháp đã biết và cung cấp sự hỗ trợ tốt nhất cho việc lập mô hình. UML hóa ra là một ngôn ngữ như vậy.

Quá trình tạo UML đã bắt đầu vào tháng 10 năm 1994, khi Jim Rumbaugh và Grady Booch của Rational Software Corporation bắt đầu hợp nhất các phương pháp OMT và Booch của họ. Vào mùa thu năm 1995, phiên bản dự thảo đầu tiên của phương pháp thống nhất đã được phát hành, mà họ gọi là Phương pháp thống nhất 0.8. Sau khi Ivar Jacobson và công ty Objectory của ông gia nhập Rational Software Corporation vào cuối năm 1995, nỗ lực của ba người tạo ra các phương pháp luận hướng đối tượng phổ biến nhất đã được kết hợp và hướng đến việc tạo ra UML.

Hiện tại là một nhóm người dùng UML Partners bao gồm đại diện của những gã khổng lồ công nghệ thông tin như Microsoft, IBM, Hewlett-Packard, Oracle, DEC, Unisys, IntelliCorp, Platinum Technology.

UML là một ngôn ngữ lập mô hình hướng đối tượng với các đặc điểm chính sau:

• là ngôn ngữ mô hình hóa trực quan cung cấp sự phát triển của các mô hình đại diện để tổ chức tương tác giữa khách hàng và nhà phát triển IS, các nhóm nhà phát triển IS khác nhau;
• chứa các cơ chế để mở rộng và chuyên biệt hóa các khái niệm cơ bản của ngôn ngữ.

UML là một ký hiệu tiêu chuẩn cho mô hình hóa trực quan của các hệ thống phần mềm, được Nhóm quản lý đối tượng (OMG) thông qua vào mùa thu năm 1997 và hiện được hỗ trợ bởi nhiều sản phẩm CASE hướng đối tượng. UML bao gồm một tập hợp bên trong các công cụ mô hình hóa (mô-đun?) ("lõi") hiện được áp dụng trong nhiều phương pháp và công cụ mô hình hóa. Những khái niệm này là cần thiết trong hầu hết các ứng dụng, mặc dù không phải mọi khái niệm đều cần thiết trong mọi phần của mọi ứng dụng.

Người sử dụng ngôn ngữ có cơ hội để:

• xây dựng các mô hình dựa trên các công cụ nhân mà không sử dụng các cơ chế mở rộng cho hầu hết các ứng dụng điển hình;
• bổ sung, nếu cần, các yếu tố và quy ước mới, nếu chúng không có trong cốt lõi, hoặc chuyên biệt hóa các thành phần, quy ước (ký hiệu) và các hạn chế đối với các lĩnh vực chủ đề cụ thể.

Cú pháp và ngữ nghĩa của các đối tượng UML cơ bản

UML là một tập hợp các sơ đồ cho phép bạn tạo các mô hình của các hệ thống phần mềm phức tạp.
Sơ đồ UML được chia thành hai nhóm.
1. Sơ đồ kết cấu:

• Sơ đồ triển khai (implementation diagrams):
  • Sơ đồ triển khai (topology diagrams);
  • Biểu đồ thành phần (component diagrams).
• Sơ đồ lớp (class diagrams);

2. Sơ đồ hành vi:

• Use case diagram (sơ đồ các ca sử dụng);
• sơ đồ trạng thái (sơ đồ trạng thái);
  • Biểu đồ hoạt động (sơ đồ hoạt động);
• Sơ đồ tương tác (interaction diagrams);
  • Biểu đồ trình tự (sơ đồ tuần tự);
  • Sơ đồ hợp tác (sơ đồ cộng tác/sơ đồ hợp tác xã);

Sử dụng sơ đồ trường hợp

Trường hợp sử dụngđược xác định chủ yếu bởi tên của nó và loại người dùng của ứng dụng, được gọi là tác nhân.
Một ca sử dụng bao gồm một tương tác điển hình giữa một tác nhân và một ứng dụng. Ví dụ: lệnh "mở tệp" sẽ là trường hợp sử dụng điển hình cho trình soạn thảo văn bản với người dùng là tác nhân. Cùng một người hoặc hệ thống bên ngoài có thể sử dụng hệ thống theo một số cách khác nhau, đảm nhận vai trò của các tác nhân (actor) khác nhau. diễn viênđại diện chính xác vai trò của mọi người hoặc các thực thể bên ngoài chứ không phải những người hoặc thực thể cụ thể.
tiền lệ mô tả hành vi được thể hiện bởi hệ thống để tạo ra kết quả có ý nghĩa cho một hoặc nhiều tác nhân.
Để chi tiết tiền lệ, một đặc điểm kỹ thuật được thực hiện.

Bảng "Chế độ xem mẫu về đặc tả của trường hợp sử dụng"

Tên của tiền lệ là một danh từ bằng lời nói theo kiểu UpperCamelCase
Mã định danh (1.1 - Trường hợp luồng thay thế #)
Mô tả ngắn gọn - mục đích của ca sử dụng
diễn viên: các diễn viên chính khởi xướng tiền lệ; diễn viên phụ - tương tác với trường hợp sử dụng sau khi nó được kích hoạt
Điều kiện tiên quyết xác định các điều kiện phải đúng để trường hợp sử dụng được kích hoạt.
Xu hướng- các giai đoạn thực hiện tiền lệ. Các bước thường được viết như sau: <номер> <кто-либо><действие> 1. Người mua điền vào mẫu với tên và địa chỉ của mình Từ khóa "nếu" được sử dụng để đại diện cho một nhánh 2. Nếu người mua chọn "xóa hàng" 2.1. Hệ thống xóa sản phẩm khỏi giỏ hàng Các lần lặp lại được mô hình hóa bằng cách sử dụng từ khóa "For" hoặc "While" 3. Nếu hệ thống tìm thấy các sản phẩm cần thiết, thì 1.1 Đối với mỗi sản phẩm được tìm thấy 1.1.1 Hệ thống hiển thị giao diện sản phẩm 1.1.2 Hệ thống hiển thị giá của sản phẩm
Hậu điều kiện xác định điều kiện nào sẽ đúng sau khi ca sử dụng được thực thi
luồng thay thế– các đường dẫn thay thế trong trường hợp sử dụng bắt lỗi, các nhánh và sự gián đoạn của luồng chính (các luồng thay thế quan trọng nhất về chức năng được lập thành tài liệu riêng).

Sơ đồ trường hợp sử dụng cho phép bạn hiển thị các mối quan hệ cụ thể giữa các trường hợp sử dụng:

• sự khái quát,
• hòa nhập và
• sự mở rộng.

Khái quát hóa trường hợp sử dụng chuyển hành vi phổ biến đối với một hoặc nhiều trường hợp sử dụng sang trường hợp sử dụng gốc.

Hình "Tóm tắt án lệ"

Khi xây dựng sơ đồ ca sử dụng, bạn cần:

• Đầu tiên, tránh kết nối hai trường hợp sử dụng theo chuỗi, vì sơ đồ nhằm phản ánh các trường hợp sử dụng hiện có chứ không phải thứ tự thực hiện chúng (đây là mục đích sử dụng sơ đồ hoạt động).
• Thứ hai, mỗi trường hợp sử dụng phải được bắt đầu bởi một diễn viên.

Tuy nhiên, trong các sơ đồ có một kết nối nối tiếp của các tiền lệ, nhưng các loại kết nối đặc biệt được sử dụng:
quan hệ "bao gồm"được thiết lập giữa các trường hợp sử dụng cho phép hành vi của một trường hợp sử dụng được đưa vào luồng của một trường hợp sử dụng khác. Điều này có nghĩa là khi thực hiện ca sử dụng "Xem thẻ chỉ mục UMM", ca sử dụng "Tìm kiếm UMM" phải được thực hiện. UML sử dụng một mũi tên chấm để biểu thị mối quan hệ bao gồm, trỏ từ trường hợp sử dụng nguồn (bao gồm) đến trường hợp sử dụng đích (bao gồm).

Hình "Sử dụng quan hệ "bao gồm" và "mở rộng""

Bảng “Cấu trúc của một đặc tả ca sử dụng bao gồm quan hệ “bao gồm”

"kéo dài" quan hệ- một cách để giới thiệu hành vi mới vào một trường hợp sử dụng hiện có. Khi sử dụng “mở rộng”, trường hợp sử dụng cơ sở hoạt động như một khung mô hình mà các tiện ích mở rộng có thể được kết nối, chẳng hạn như để xử lý ngoại lệ. Mối quan hệ "mở rộng" trong UML được biểu thị bằng một mũi tên chấm chỉ từ trường hợp mở rộng đến trường hợp sử dụng cơ sở. Đồng thời, trường hợp sử dụng cơ sở phải độc lập, cho phép sử dụng mà không cần bất kỳ tiện ích mở rộng nào.

Các khả năng bổ sung của "bao gồm", "mở rộng" và khái quát hóa nên được sử dụng trong các trường hợp chính đáng, bởi vì Biểu đồ ca sử dụng phải đơn giản và dễ hiểu đối với khách hàng.
Khi thực hiện phân tích ca sử dụng, người thiết kế:

• xác định các lớp liên quan đến việc triển khai các luồng sự kiện trường hợp sử dụng;
• phân phối hành vi được thực hiện bởi trường hợp sử dụng giữa các lớp (xác định trách nhiệm của các lớp);
• thống nhất các lớp phân tích.

Sơ đồ ca sử dụng xác định lý do tại sao (hoặc cho mục đích gì) các tác nhân tương tác với hệ thống. Các trường hợp sử dụng và mô tả của chúng là thành phần quan trọng nhất của giai đoạn phân tích yêu cầu.
Để trả lời không chỉ câu hỏi “Tại sao có sự tương tác với hệ thống? Nhưng sự tương tác diễn ra như thế nào? cần phải chuyển sang sơ đồ tương tác (trình tự và cộng tác) và hoạt động (hoạt động).

Sơ đồ tương tác

Sự tương tác của các tác nhân với toàn bộ hệ thống hoặc sự tương tác của các mô-đun (lớp) riêng lẻ của hệ thống với nhau xảy ra thông qua việc trao đổi thông điệp (hoặc yêu cầu). Để mô hình hóa sự tương tác như vậy, UML bao gồm các sơ đồ tương tác: sơ đồ trình tự (Sơ đồ tuần tự) và sơ đồ cộng tác (Sơ đồ cộng tác), cho phép bạn xem xét sự tương tác của các đối tượng trong hệ thống được tạo ra từ các quan điểm khác nhau. Thông thường, sơ đồ tương tác bao gồm hành vi của các đối tượng trong một trường hợp sử dụng cụ thể.

Sequence Diagram (sơ đồ trình tự)

Để xây dựng sơ đồ trình tự, bạn cần:

• xác định từng nhân vật (đối tượng) và vẽ đường đời cho anh ta. Đối tượng ngoài cùng bên trái trong sơ đồ là đối tượng khởi xướng tương tác. Ở bên phải, một đối tượng khác được mô tả tương tác trực tiếp với đối tượng đầu tiên, v.v.;
• từ mô tả của trường hợp sử dụng, xác định tập hợp các thông báo hệ thống và trình tự của chúng;
• mô tả các thông báo hệ thống dưới dạng các đường có mũi tên ở cuối giữa các đường sinh mệnh của các tác nhân và hệ thống. Sau đó, tên thông báo và danh sách các giá trị sẽ được chuyển được chỉ định.

Trên sơ đồ trình tự chỉ những đối tượng liên quan trực tiếp đến tương tác mới được mô tả và các liên kết tĩnh có thể có với các đối tượng khác không được chỉ định.
Vòng đời đối tượng phục vụ để chỉ định khoảng thời gian mà một đối tượng tồn tại trong hệ thống và do đó, có khả năng tham gia vào tất cả các tương tác của nó. Trong sơ đồ, vòng đời được biểu thị bằng một đường thẳng đứng có chấm được liên kết với một đối tượng. Nếu một đối tượng tồn tại vĩnh viễn trong hệ thống, thì vòng đời của nó cũng phải tiếp tục dọc theo toàn bộ mặt phẳng của biểu đồ trình tự từ phần cao nhất đến phần thấp nhất của nó.

Nếu các đối tượng bị phá hủy tại một thời điểm nào đó để giải phóng tài nguyên hệ thống, thì vòng đời của chúng sẽ kết thúc tại thời điểm bị phá hủy. Để biểu thị thời điểm như vậy, một ký tự đặc biệt ở dạng chữ cái Latinh "X" được sử dụng.
Các đối tượng trên sơ đồ trình tự có thể ở hai trạng thái, hoạt động - trực tiếp thực hiện một số hành động và thụ động, chờ thông báo từ các đối tượng khác. Để làm nổi bật rõ ràng hoạt động của đối tượng như vậy, tiêu điểm kiểm soát được sử dụng. Tiêu điểm điều khiển được mô tả dưới dạng một hình chữ nhật hẹp kéo dài, mặt trên biểu thị điểm bắt đầu nhận tiêu điểm điều khiển của đối tượng (bắt đầu hoạt động) và mặt dưới của nó - điểm cuối của tiêu điểm điều khiển (kết thúc hoạt động). hoạt động).

Hình - Sơ đồ trình tự cho ca sử dụng "Thêm tệp UMM để xử lý"

Mỗi tương tác giữa các đối tượng được mô tả bởi một tập hợp các thông báo, mà các đối tượng trao đổi với nhau hoặc các thao tác mà các đối tượng gọi để thực hiện hành động nào đó. Thông điệp là một đoạn thông tin hoàn chỉnh được gửi từ đối tượng này sang đối tượng khác. Đối tượng nhận được tin nhắn phải phản hồi nó bằng một số chuỗi hành động nhằm giải quyết nhiệm vụ. Thứ tự của các tin nhắn được chỉ định theo hướng dọc. Loại thông báo được biểu thị bằng các mũi tên khác nhau:

• Đơn giản (1) - gửi tin nhắn đơn giản;
• Đồng bộ (2) - hoạt động chỉ xảy ra khi máy khách gửi tin nhắn và máy chủ có thể nhận tin nhắn của máy khách;
• Tự ủy quyền (3) là phổ biến trong OOP, chẳng hạn như khi một đối tượng gọi phương thức (thường được bảo vệ) của chính nó;
• Balking (4) - hoạt động chỉ xảy ra khi máy chủ sẵn sàng nhận tin nhắn ngay lập tức, nếu máy chủ chưa sẵn sàng nhận, máy khách sẽ không gửi tin nhắn;
• Hết thời gian (5) - máy khách từ chối đưa ra thông báo nếu máy chủ không thể chấp nhận nó trong một thời gian nhất định;
• Thủ tục gọi (6) - máy khách gọi thủ tục máy chủ và chuyển hoàn toàn quyền kiểm soát cho nó;
• Không đồng bộ (7) - máy khách đưa ra thông báo và không đợi phản hồi của máy chủ, tiếp tục thực thi mã chương trình của nó;
• Return (8) - chỉ định rằng thủ tục trả về;

Tần suất gửi tin nhắn có thể có hai tùy chọn:

• Định kỳ - tin nhắn được nhận từ máy khách với tần suất xác định;
• Định kỳ - tin nhắn được nhận từ khách hàng không thường xuyên.

Hình - Các loại thông báo trên sơ đồ trình tự

Cần tuân thủ các yêu cầu sau đối với tên tin nhắn: để tăng nội dung thông tin, tên phải bắt đầu bằng động từ thêm (thêm), nhập (nhập), kết thúc (hoàn thành), tải (tải), v.v. Ban đầu, ở giai đoạn phân tích hệ thống dưới dạng mô hình hộp đen, hệ thống được biểu diễn trong biểu đồ trình tự bởi một đối tượng. Các hoạt động được hiển thị trong sơ đồ trong trường hợp này được gọi là hoạt động của hệ thống. Chúng tạo thành giao diện chung của hệ thống và được thiết kế để xử lý tất cả các sự kiện hệ thống đầu vào mà hệ thống thực thi dưới dạng hộp đen. Sau đó, để tinh chỉnh các mô tả về hoạt động của hệ thống (tiền điều kiện và hậu điều kiện của chúng), sơ đồ hoạt động được sử dụng.

Giống như tất cả các sơ đồ UML khác, sơ đồ trình tự trải qua hai giai đoạn sàng lọc:

• (i) giai đoạn thu thập và phân tích yêu cầu, khi các phiên bản sơ đồ sơ đồ được tạo ra, chỉ phản ánh các đối tượng và thông điệp chính, được thiết kế chủ yếu để đồng ý với khách hàng về sự hiểu biết về các quy trình diễn ra trong hệ thống khi khách hàng triển khai một hoặc tiền lệ quy trình khác;
• (ii) giai đoạn thiết kế, trong đó tất cả các sơ đồ được cung cấp với số lượng chi tiết tối đa để đơn giản hóa công việc của người lập trình và/hoặc ghi lại kết quả cuối cùng của giai đoạn thực hiện. Đồng thời, trên sơ đồ trình tự, các thao tác được cung cấp chữ ký (tên và tham số) và trong phần mô tả sơ đồ, thông số kỹ thuật của chúng được đưa ra, bao gồm chỉ báo về các điều kiện trước và sau.

Hình - Sơ đồ trình tự cho ca sử dụng "Thêm tệp UMM để xử lý"

sơ đồ cộng tác khác với biểu đồ tương tác ở chỗ nó không tập trung vào trình tự truyền thông điệp. Nó có dạng biểu đồ mà các nút (đối tượng) có thể được đặt ở bất kỳ đâu trong biểu đồ.
Vì dòng thời gian không tham gia vào việc trình diễn thông điệp, sơ đồ này nhỏ gọn hơn và phù hợp hơn để phân tích sự tương tác của tất cả các đối tượng với nhau.
Do đó, sơ đồ trình tự mô tả chính xác thứ tự thời gian của các thông báo, nhưng chiếm nhiều dung lượng và sơ đồ cộng tác tiết kiệm không gian, nhưng làm suy yếu việc theo dõi trình tự truyền thông báo (các thao tác).

Hình - Sơ đồ cộng tác

Trong Sơ đồ cộng tác, thứ tự các thông báo được truyền đi được minh họa bằng các số thứ tự. Bạn có thể sử dụng các loại kết nối sau:

• Liên kết với bản thân chỉ ra rằng đối tượng có phản hồi cho chính nó.
• Tin nhắn liên kết / Tin nhắn liên kết ngược cho phép bạn phản ánh kết nối, ngụ ý việc truyền tin nhắn bắt buộc theo hướng thuận (nghịch).
• Luồng dữ liệu / Luồng dữ liệu ngược (dòng dữ liệu) cho phép bạn phản ánh kết nối cho thấy dữ liệu đang được truyền từ đối tượng này sang đối tượng khác theo hướng thuận/nghịch.

Đặc điểm nổi bật của sơ đồ hợp tác so với sơ đồ tương tác là khả năng sử dụng một tập hợp các cấu trúc cú pháp phong phú hơn. Trên hình. tình huống được mô phỏng, cung cấp sự hiện diện của phương thức “tạo” cho một thể hiện của lớp “ConcretStateA”. Phương thức "tạo" trong vòng lặp cho phép bạn tạo một (bộ sưu tập) nhiều đối tượng "ConcretStateB". Ngoài ra, vì phương thức "tạo" được gọi với một đối số, điều này có nghĩa là một hàm tạo có tham số được sử dụng khi tạo.

Hình - Các chu kỳ trong sơ đồ hợp tác

Nếu cần thiết, các cấu trúc cú pháp tương tự cũng có thể được sử dụng trên sơ đồ trình tự, điều này một mình có thể vi phạm hệ tư tưởng: sơ đồ trình tựđược thiết kế để tập trung vào thứ tự truyền tin nhắn (hoạt động cuộc gọi) và biểu đồ hợp tácđể hiển thị các tính năng nhắn tin nâng cao.

Sơ đồ hoạt động

Sơ đồ hoạt động cho phép bạn mô tả luồng hoạt động trong một hệ thống, quy trình sản xuất hoặc công nghệ. Một biểu đồ hoạt động được sử dụng để mô hình hóa một trường hợp sử dụng dưới dạng một chuỗi các hành động (hoạt động) mô tả sự tương tác của một tác nhân với một hệ thống. Sơ đồ này tập trung vào những hoạt động nào được thực hiện và ai chịu trách nhiệm thực hiện chúng. Hoạt động được mô tả trên sơ đồ dưới dạng

Các hoạt động có thể có hai loại:

• hành động - hành động.
• gửi sự kiện - gửi một sự kiện.

Đến lượt mình, hành động có thể có tên (name) và được thực hiện khi vào (on Entry), khi thoát (on Exit), trong khi (Do) và khi một sự kiện xảy ra (on Event). Ngữ nghĩa của hoạt động "Chuẩn bị đĩa", bao gồm hành động "Định dạng", được thực hiện khi nhập, có nội dung sau. lượt xem:

Hình - Hình ảnh của một hành động trên sơ đồ hoạt động

Khi khởi tạo một hành động trên một sự kiện (on Event) bạn có thể chỉ định tên của sự kiện, các đối số được thông qua và điều kiện phải đáp ứng để khởi tạo hành động đối với sự kiện này. Ngữ nghĩa của hoạt động "Quy trình công nghệ", bao gồm hành động "Gọi", được thực hiện khi sự kiện "Đã hoàn tất quy trình" xảy ra với đối số "thời gian" và điều kiện "thời gian=0", như sau. lượt xem:

Hình - Hình ảnh của một hành động với một sự kiện

Nếu hoạt động thuộc loại "gửi sự kiện"- gửi một sự kiện, sau đó, ngoài việc chỉ định thời điểm khởi tạo hoạt động này (vào Mục nhập, khi Thoát, Thực hiện, trên Sự kiện), bạn có thể chỉ định các đối số sẽ được gửi (Gửi đối số) và hoạt động đích (Gửi mục tiêu ). Hành động "Gọi" của hoạt động "Quy trình công nghệ" được thực hiện khi sự kiện "Quá trình kết thúc" xảy ra với đối số "thời gian" và điều kiện "thời gian=0" và bao gồm việc gửi một thông báo đến hoạt động "Kết thúc quy trình" với đối số (trạng thái và tổng thời gian). Trong trường hợp này, ngữ nghĩa của hoạt động "Quy trình công nghệ" có dạng sau:
Hình - Hình ảnh của một hành động với một sự kiện và một điều kiện để thực hiện

Sơ đồ hoạt động, ngoài các hoạt động (hoạt động), có thể bao gồm:

• bang (bang),
• đồng bộ hóa (Đồng bộ hóa),
• nút quyết định (hợp nhất) – quyết định và
• các phần (swimlanes-làn bơi).

Tiểu bang- đây là một tình huống trong vòng đời của một đối tượng trong đó nó thỏa mãn một điều kiện nhất định, trong khi đối tượng thực hiện một số hành động nhất định hoặc chờ đợi một sự kiện nào đó. Cũng như Hoạt động, trạng thái có thể có hai loại: hành động - trạng thái thực hiện hành động đã chỉ định và gửi sự kiện - trạng thái gửi một sự kiện với các cài đặt tương tự cho thời điểm chuyển sang trạng thái hoặc gửi tin nhắn .

Chuyển động của một đối tượng từ hoạt động (trạng thái) này sang hoạt động khác (trạng thái) được phản ánh bằng một mũi tên (chuyển tiếp).
Đặc tả chuyển tiếp bao gồm:

• Một sự kiện là một cái gì đó gây ra sự chuyển đổi từ hoạt động này sang hoạt động khác. Tên của sự kiện được đặt phía trên mối quan hệ giữa các trạng thái. Một sự kiện có thể có đối số.
• điều kiện bảo vệ - các điều kiện áp đặt cho việc thực hiện quá trình chuyển đổi. Các điều kiện bảo vệ được chỉ định dọc theo đường chuyển tiếp sau tên sự kiện và được đặt trong dấu ngoặc vuông.
• hành động được thực hiện trong quá trình chuyển đổi (được biểu thị dọc theo đường chuyển tiếp sau dấu "/").
• một sự kiện có thể được gửi (gửi sự kiện) mục tiêu hoạt động (gửi mục tiêu) với các đối số (gửi đối số)

Hình - Ngữ nghĩa của bước nhảy có điều kiện

Biểu đồ hoạt động hỗ trợ khả năng tạo các hoạt động (trạng thái) lồng nhau. Một hoạt động có thể bắt đầu khi một số sự kiện xảy ra hoặc tại thời điểm khởi tạo hoạt động đầu tiên, được biểu thị bằng dấu - . Biểu tượng kết thúc thực thi - .

nút đồng bộ hóađược thiết kế để chia một luồng thành nhiều luồng song song hoặc ngược lại, kết hợp nhiều luồng vào thành một luồng đi.
nút quyết định phải kèm theo chỉ dẫn về điều kiện chuyển tiếp dưới dạng nhận xét. Trong trường hợp này, mỗi nhánh của luồng phải được cung cấp một điều kiện bảo vệ (guard condition). Nó trở thành một nút hợp nhất nếu nó hợp nhất nhiều luồng.
Phần (đường bơi-đường bơi)được thiết kế để phân tách các hoạt động bằng cách nhóm chúng theo tiền lệ, lớp, thành phần, vai trò, v.v.
Trạng thái lịch sử (ký hiệu là "H") là trạng thái giả khôi phục trạng thái hoạt động trước đó ở trạng thái tổng hợp. Nó cho phép trạng thái tổng hợp của OpenState ghi nhớ trạng thái lồng nhau nào (StopState hoặc StartState) hiện tại tại thời điểm thoát khỏi OpenState, để bất kỳ quá trình chuyển đổi nào trong OpenState trở về trạng thái lồng nhau này chứ không phải trạng thái ban đầu.

Hình - Ảnh về "Trạng thái lịch sử"

Biểu đồ trạng thái là một trường hợp đặc biệt của sơ đồ hoạt động và nhằm mô tả các trạng thái của một đối tượng và các điều kiện chuyển tiếp giữa chúng, cùng nhau đặc trưng cho hành vi của một đối tượng trong vòng đời của nó. Biểu đồ trạng thái về cơ bản là một biểu đồ thuộc loại đặc biệt đại diện cho một số máy tự động. Các đỉnh của đồ thị này là các trạng thái. Các cung đồ thị dùng để biểu thị sự chuyển tiếp từ trạng thái này sang trạng thái khác.

Hình - Ví dụ về xây dựng sơ đồ hoạt động

Sơ đồ tương tác (trình tự và cộng tác), cũng như sơ đồ hoạt động (hoạt động)được sử dụng rộng rãi cả ở giai đoạn phân tích và ở giai đoạn thiết kế để ghi lại kết quả. Tuy nhiên, mục đích chính của các sơ đồ này là để phân tích lĩnh vực chủ đề (quy trình công nghệ) mà hệ thống đang được phát triển. Cơ sở của hệ thống tương lai là mô hình miền. Do đó, nhiệm vụ chính của giai đoạn phân tích là xác định các khái niệm về lĩnh vực chủ đề và trình bày kết quả dưới dạng một mô hình của lĩnh vực chủ đề. Khi kết thúc thiết kế, mô hình này được chuyển thành mã. Về vấn đề này, các vấn đề xây dựng mô hình miền cần được quan tâm đặc biệt.

sơ đồ lớp

Mô hình miền hiển thị các lớp khái niệm chính (theo quan điểm của nhà thiết kế) (các lớp khái niệm) về lĩnh vực chủ đề. Trong UML, một mô hình miền được biểu diễn dưới dạng sơ đồ lớp, sơ đồ này mô tả các lớp khái niệm trong thế giới thực hơn là các thành phần phần mềm. Ngoài các lớp khái niệm, một mô hình miền có thể biểu diễn các liên kết giữa các lớp và các thuộc tính của các lớp khái niệm. Tuy nhiên, các thao tác trên sơ đồ lớp của mô hình miền không được hiển thị.

Mô hình miền được xây dựng lặp đi lặp lại qua nhiều lần lặp lại của giai đoạn phát triển. Ở mỗi lần lặp lại tiếp theo, các lớp khái niệm mới được thêm vào mô hình hoặc các lớp hiện có của trường hợp sử dụng được phân tích tiếp theo được tinh chỉnh.
Kỹ thuật đơn giản nhất để xác định các lớp khái niệm là trích xuất các danh từ từ mô tả văn bản của lĩnh vực chủ đề và coi chúng như các ứng cử viên cho các lớp hoặc thuộc tính khái niệm.

Ví dụ, trong hình. sơ đồ lớp của kịch bản chính của ca sử dụng P.1 “Thêm tệp UMM để xử lý” được trình bày, trong đó đặc tả tải xuống UMM mô hình hóa bảng cơ sở dữ liệu trong đó dữ liệu (đăng nhập người dùng, ngày tháng, tên tệp) về các tệp UMM được tải lên máy chủ sẽ được lưu. Trong Đặc tả UMM cho mỗi UMM, thông tin thuộc tính được lưu trữ (tên của UMM, năm xuất bản, số trang, v.v.), thành phần của chúng được liệt kê trong ToR.

Hình - Sơ đồ lớp của ca sử dụng "Thêm tệp UMM để xử lý"

Trong sơ đồ, một lớp được hiển thị dưới dạng hình chữ nhật với ba vùng bên trong: tên lớp, thuộc tính và hoạt động. Một hoạt động thiết lập hình thức của một chức năng hoặc thủ tục (chữ ký của nó). Một triển khai cụ thể của một hoạt động là một phương pháp. Tên lớp nên là một danh từ số ít. con số.

Hình - Hình ảnh của một lớp trên sơ đồ lớp

Các đối tượng trao đổi thông điệp thông qua các kết nối - liên kết. Nhưng để có sự liên kết giữa các đối tượng thì phải có sự liên kết giữa các lớp của các đối tượng này, vì sự liên kết giữa các đối tượng là một thể hiện của sự liên kết giữa các lớp.
Sự kết hợp- đây là mối quan hệ giữa các lớp, phản ánh một số mối quan hệ quan trọng giữa chúng.
Trong quá trình phân tích các liên kết, cần tuân thủ các nguyên tắc của chủ nghĩa tối giản, vì nếu MPO bao gồm N lớp, thì về mặt lý thuyết, N (N-1) có thể được thiết lập giữa chúng. Về vấn đề này, chỉ những hiệp hội đó mới được đưa vào mô hình, kiến ​​​​thức về chúng phải được lưu giữ trong một thời gian nhất định.
Không chỉ toàn bộ liên kết có thể có tên, mà các lớp ở cả hai đầu của liên kết có thể được gán tên vai trò được thực hiện bởi các đối tượng lớp khi bị ràng buộc bởi một thể hiện của liên kết. Mũi tên chỉ hướng truyền thông tin (ví dụ: gửi tin nhắn) từ đối tượng này sang đối tượng khác.
Ví dụ: giả sử một công ty thuê n nhân viên. Các ràng buộc bội số "1" và "n" có nghĩa là các đối tượng Người chỉ có thể được thuê bởi một đối tượng Công ty tại một thời điểm nhất định và Người không thể thất nghiệp. Đối tượng Công ty có thể gửi tin nhắn đến đối tượng Người, nhưng không phải ngược lại.

Hình - Sử dụng các ký hiệu bội số trong sơ đồ lớp

Tính đa bội bị đánh giá thấp làm hạn chế tính linh hoạt của ứng dụng, ví dụ, một số người quản lý cá nhân không cho phép bạn bảo vệ nhiều điện thoại cho một người.
Trường hợp đặc biệt của một quan hệ kết hợp là một Lớp kết hợp, nó có cả thuộc tính của lớp và thuộc tính của quan hệ kết hợp. Lớp liên kết là nơi lưu trữ các thuộc tính và hoạt động liên quan đến một liên kết.
Tên cực liên kết được yêu cầu khi một lớp có liên kết với chính nó (liên kết phản thân), nghĩa là các đối tượng của lớp này có quan hệ với các đối tượng khác của cùng một lớp.
Mỗi đối tượng Thư mục có thể có mối quan hệ với các đối tượng Thư mục hoạt động như các thư mục con, số lượng thư mục con có thể thay đổi từ 0 đến n. Mặt khác, một thư mục con có thể chỉ có 1 thư mục mẹ hoặc không có thư mục nào cả. Ngoài ra, một Thư mục có thể được liên kết với bất kỳ số lượng đối tượng Tệp nào.

Hình - Một ví dụ về việc sử dụng liên kết phản xạ trên sơ đồ lớp

Do việc sử dụng rộng rãi các liên kết nhiều-nhiều, UML cung cấp các lớp liên kết đặc biệt. Giống như các lớp thông thường, các lớp liên kết có thể có các thuộc tính và hoạt động thuộc về liên kết, nghĩa là những thuộc tính và hoạt động không thể được gán cho bất kỳ đối tượng thành viên nào của liên kết. Trên hình. thuộc tính accessPermission (quyền truy cập) của lớp AccessibleBy (Có sẵn) áp dụng cho cả tệp và người dùng cùng một lúc và không thể chỉ gắn vào một trong số chúng mà không làm mất thông tin.

Hình - Lớp liên kết

Các hình thức liên kết (hiệp hội) cụ thể:

• phụ thuộc là một mối quan hệ đơn hướng cho thấy rằng một lớp phụ thuộc vào các định nghĩa được tạo ra trong một lớp khác. Ví dụ, một mối quan hệ như vậy xảy ra nếu một lớp sử dụng lớp khác làm tham số hoạt động. Khi tạo mã, các thuộc tính của lớp đích sẽ không được thêm vào lớp nguồn, nhưng một toán tử như "#include" sẽ được thêm vào mã.
• tổng hợp- một trường hợp đặc biệt của một hiệp hội thể hiện mối quan hệ toàn bộ (ví dụ: động cơ ô tô). Tập hợp có tính bắc cầu: nếu A là một phần của B và B là một phần của C, thì A là một phần của C. Tập hợp được biểu thị bằng một viên kim cương, được đặt gần cực, là một tập hợp. Vòng đời của một bộ phận đối tượng trùng với vòng đời của một tổng thể đối tượng. Một loại tập hợp mạnh hơn là mối quan hệ kiểu "sáng tác" (sáng tác), áp đặt thêm hai hạn chế đối với liên kết:
  • (i) một bộ phận cấu thành có thể thuộc về không quá một tập hợp;
  • (ii) thành phần nhận thời gian tồn tại của đơn vị. Thành phần được chỉ định bởi một viên kim cương đầy. Do đó, tập hợp là một cách nhúng nhiều đối tượng vào một đối tượng vùng chứa duy nhất và sử dụng các đối tượng có thể nhúng để triển khai các phương thức vùng chứa.

Mật mã:

Sự khái quát– hiển thị các liên kết thừa kế giữa hai lớp (lớp cha-lớp con). Đồng thời, các lớp con kế thừa tất cả các tính năng của lớp cha của chúng (thuộc tính, hoạt động, mối quan hệ, hạn chế) - tính kế thừa. Generics thường được sử dụng cùng với các lớp trừu tượng, có thể có các thuộc tính và hoạt động trừu tượng. Các lớp trừu tượng không tạo các thể hiện. Một lớp con của một lớp trừu tượng thực hiện các hoạt động trừu tượng bằng cách thêm các tính năng mới hoặc xác định lại chúng.

Hình - Kế thừa trên sơ đồ lớp

Vì một khái quát hóa là bắc cầu, một thể hiện của một lớp con đồng thời là một thể hiện của tất cả các tổ tiên của nó, tức là có các giá trị của tất cả các thuộc tính của tất cả các lớp tổ tiên và có thể gọi bất kỳ thao tác nào được chỉ định trên bất kỳ lớp tổ tiên nào của nó. Bạn không nên tạo một hệ thống phân cấp lớp quá sâu, vì điều này sẽ gây khó khăn cho việc hiểu mô hình - hệ thống phân cấp có không quá 3 cấp độ thường luôn được chấp nhận; 5-6 cấp độ phân cấp có thể được chấp nhận hoặc không, tùy thuộc vào các tính năng của hệ thống được thiết kế.
Ngoài ra, cái chung chỉ nên được sử dụng khi ít nhất một trong các lớp con có các thuộc tính, hoạt động hoặc liên kết không áp dụng cho lớp cha. Ví dụ: bạn không nên sử dụng khái quát hóa khi có các lớp con giống hệt nhau về chữ ký và hành vi của chúng với lớp cha (bộ bài).
việc thêm một lớp con mới sẽ tự động kế thừa hành vi của lớp cha và hơn nữa, lớp con mới không phá vỡ hoạt động của lớp hiện có.
Cần lưu ý rằng một số ngôn ngữ lập trình hỗ trợ đa kế thừa, cho phép một lớp kế thừa các thành phần từ nhiều lớp cùng một lúc.

Hình vẽ cho thấy cây lớp, trong đó SubClass là một lớp con (lớp con) trong mối quan hệ với hai lớp cha (lớp cơ sở) - SuperClass1 và SuperClass22. Object1 và Object2 là các thể hiện của lớp SubClass kế thừa các thuộc tính của lớp SubClass (x và y). Đổi lại, SubClass kế thừa các thuộc tính z và w của SuperClass1 và SuperClass2, xác định lại3 thuộc tính x và thêm thuộc tính y.
Do đó, một cuộc gọi đến, ví dụ, Object1.x hoặc Object2.x sẽ sử dụng thuộc tính SubClass.x, thuộc tính này cao hơn một cấp trong hệ thống phân cấp thừa kế; khi gọi Object1.z hoặc Object2.z, thuộc tính SuperClass1.z sẽ được sử dụng, vì SuperClass1 ở bên trái của SuperClass2 trong cây, SubClass sẽ kế thừa các thuộc tính của SuperClass1 trước. Vì vậy, khi sử dụng đa kế thừa, hãy nhớ rằng thứ tự của các lớp được liệt kê trong dòng tiêu đề của câu lệnh lớp của lớp kế thừa sẽ xác định thứ tự các thuộc tính được kế thừa.

Hình - Đa kế thừa

Hình - Danh sách mã chứng minh nhiều kế thừa

Nhiều kế thừa được cố gắng tránh bằng cách tái cấu trúc mô hình ở giai đoạn thiết kế hoặc bằng cách sử dụng cơ chế thực hiện "ủy quyền".

Khả năng hiển thị của một thuộc tính cho biết liệu nó có thể được sử dụng bởi các lớp khác hay không. Một lớp có thể "nhìn thấy" một lớp khác nếu nó nằm trong phạm vi của lớp đầu tiên và có mối quan hệ rõ ràng hoặc tiềm ẩn giữa chúng. UML định nghĩa ba mức độ hiển thị:

• đại chúng (chung)- bất kỳ lớp bên ngoài nào "thấy" lớp này đều có thể sử dụng các thuộc tính chung của nó. Được biểu thị bằng dấu “+” trước tên thuộc tính hoặc thao tác;
• được bảo vệ (được bảo vệ)- chỉ một lớp hoặc hậu duệ của lớp này mới có thể sử dụng các thuộc tính được bảo vệ của nó. Chúng được biểu thị bằng dấu "#";
• riêng tư (đã đóng) Chỉ lớp này mới có thể sử dụng các thuộc tính riêng tư. Được biểu thị bằng ký hiệu "-";
• gói hoặc thực hiện– thuộc tính được chia sẻ trong gói chứa lớp. Chúng được biểu thị bằng ký hiệu "~".

Khi xác định khả năng hiển thị cho một thành phần cụ thể, cần tính đến các cân nhắc sau:

1. khả năng của lớp được xác định chủ yếu bởi các thành phần công khai của nó, riêng tư, được bảo vệ và đóng gói được giới thiệu để dễ thực hiện;
2. Các phương thức công khai, theo định nghĩa, được sử dụng bởi nhiều lớp, vì vậy việc thay đổi chữ ký của chúng (số lượng và loại đối số, loại giá trị trả về) có thể phá hủy tính nhất quán của toàn bộ mô hình. Vì các phương thức gói, riêng tư và được bảo vệ được biết là được sử dụng bởi ít lớp hơn nên việc thay đổi chúng sẽ rẻ hơn.

Một đặc điểm quan trọng khác của các thuộc tính và hoạt động của lớp là phạm vi, xác định xem một thành phần nhất định có tham chiếu đến một đối tượng hay một lớp hay không. Các đối tượng có các bản sao của các thuộc tính đảm nhận các giá trị và hoạt động khác nhau. Phạm vi của các thuộc tính này và các hoạt động thể hiện (instance) - mỗi thể hiện của lớp có giá trị riêng cho thuộc tính này. Tuy nhiên, đôi khi bạn cần định nghĩa các thuộc tính có một giá trị chung cho tất cả các đối tượng của lớp. Tương tự, chúng ta cần các thao tác không liên quan đến bất kỳ thể hiện cụ thể nào của lớp (ví dụ: thao tác tạo đối tượng - hàm tạo). Các thuộc tính và hoạt động như vậy có bộ phân loại phạm vi (bộ phân loại) - tất cả các trường hợp đều chia sẻ giá trị chung của thuộc tính này (được đánh dấu trong sơ đồ bằng cách gạch chân).
Trong trường hợp này, nó được gọi là tĩnh.
Để nhóm các lớp có điểm chung, các gói được sử dụng, là phương tiện tổ chức một mô hình trong quá trình phát triển, tăng khả năng quản lý và khả năng đọc của nó. Một sơ đồ gói là một sơ đồ chứa các gói của các lớp và sự phụ thuộc giữa chúng. Ngoài ra, các gói được sử dụng để đại diện cho các hệ thống con (mô-đun) của một hệ thống trong quá trình thiết kế. Một hệ thống con bao gồm một tập hợp các lớp thực hiện một tập hợp các thao tác được định nghĩa trong giao diện của nó.

Hình - Sơ đồ gói

Một phần tử có thể thuộc về gói mà nó được định nghĩa hoặc nó có thể được tham chiếu từ các gói khác. Nếu một phần tử của gói phụ thuộc vào một phần tử của gói khác, thì sự phụ thuộc này có thể được hiển thị bằng mối quan hệ.

Hình - Ánh xạ các gói tới các lớp dự án

Mỗi gói đại diện cho một không gian tên, vì vậy mỗi lớp trong gói riêng của nó phải có một tên duy nhất. Để phân biệt lớp này với lớp khác, bạn có thể sử dụng tên đầy đủ, nghĩa là tên trỏ đến cấu trúc sở hữu gói. UML sử dụng hai dấu hai chấm trong tên gói, vì vậy các lớp ngày tháng có thể được đặt tên là System::Date.
Bạn chỉ có thể hiển thị tên gói hoặc tên cùng với nội dung của nó.
Theo khái niệm của UML, các lớp trong gói có thể là công khai (public) hoặc đóng (private). Các lớp công khai đại diện cho một phần giao diện của gói và có thể được sử dụng bởi các lớp từ các gói khác; các lớp riêng tư không thể truy cập từ bên ngoài. Bạn có thể làm điều này bằng cách cung cấp cho tất cả các lớp công cụ sửa đổi khả năng hiển thị ở chế độ riêng tư (đã đóng), để chúng chỉ khả dụng đối với các lớp trong gói này và cũng bằng cách tạo các lớp công khai bổ sung để sử dụng bên ngoài. Các lớp bổ sung này, được gọi là Mặt tiền, ủy thác các hoạt động chung cho các lớp khác trong gói.

Sơ đồ thành phần

Component Diagram (sơ đồ các thành phần) cho phép bạn tạo một phản ánh vật lý của mô hình hiện tại. Sơ đồ thành phần hiển thị tổ chức và mối quan hệ của các thành phần phần mềm được biểu thị bằng mã nguồn, tệp nhị phân hoặc tệp thực thi.
Do hệ thống có thể bao gồm các mô-đun thuộc các loại khác nhau, người dùng có thể sử dụng các khuôn mẫu sau để xác định những khác biệt này và việc thay đổi khuôn mẫu thường dẫn đến thay đổi biểu diễn đồ họa của thành phần trên sơ đồ:

• Gói (gói) - kết hợp một nhóm các thành phần trong mô hình;
• Chương trình chính (chương trình chính);
• Thân chương trình con (subprogram body);
• Đặc tả gói/phần thân (định nghĩa gói/phần thân).

Hình - Sơ đồ thành phần

Sơ đồ triển khai

Phản ánh các mối quan hệ vật lý giữa các thành phần phần mềm và phần cứng của một hệ thống. Nó là một công cụ tốt để hiển thị vị trí của các đối tượng và thành phần trong một hệ thống phân tán.
Mỗi nút trong sơ đồ bố trí đại diện cho một số loại thiết bị điện toán—trong hầu hết các trường hợp, là một phần cứng. Phần cứng này có thể là một thiết bị hoặc cảm biến đơn giản hoặc có thể là một máy tính lớn. Sơ đồ vị trí hiển thị vị trí vật lý của mạng và vị trí của các thành phần khác nhau trong đó.

Hình - Sơ đồ vị trí

Phương pháp thiết kế dự án đầu tư xây dựng cơ bản- 1. Tập hợp các nguyên tắc, phương pháp thiết kế, quy tắc và thủ tục được sử dụng trong việc lập dự án xây dựng cơ bản. Đề cập đến một phương pháp đặc biệt (xem "Phương pháp") và liên quan trực tiếp đến phương pháp và kỹ thuật ... ...

- (từ phương pháp của trò chơi. Lời nói, khái niệm, học thuyết), một hệ thống các nguyên tắc và phương pháp tổ chức và xây dựng lý thuyết. và thiết thực hoạt động, cũng như học thuyết của hệ thống này. Ban đầu, M. được đại diện ngầm trong thực tế. các hình thức quan hệ... bách khoa toàn thư triết học

phương pháp luận- 3.14 phương pháp: Một tập hợp các hướng dẫn (dưới dạng văn bản, chương trình máy tính, công cụ, v.v.) cung cấp hỗ trợ từng bước cho người dùng. Lưu ý Khi thực hiện các khía cạnh cần thiết của vòng đời của một dự án tích hợp... ... Sách tham khảo từ điển thuật ngữ tài liệu quy chuẩn và kỹ thuật

- (viết tắt từ tiếng Anh Architecture of Integrated Information Systems) phương pháp mô hình hóa các quy trình kinh doanh của công ty là một tập hợp các phương pháp luận khác nhau được tích hợp trong phương pháp tiếp cận hệ thống. Điều này cho phép bạn nói về ... ... Khoa học chính trị. Từ điển.

phương pháp SADT- Được phát triển vào những năm 70 bởi Douglas Ross (D. Ross) và được phát triển bởi những người theo ông, phương pháp phân tích cấu trúc và thiết kế của các hệ thống thông tin và phần mềm phức tạp. Kết quả của ứng dụng của nó là một mô hình chức năng ... ... Cẩm nang phiên dịch viên kỹ thuật

Lịch sử triết học: Bách khoa toàn thư

Học thuyết về phương pháp tổ chức và xây dựng hoạt động lý luận và thực tiễn của con người. Triết học cho thấy sự phụ thuộc lịch sử xã hội của các tiết mục và phương tiện hoạt động của con người vào trình độ phát triển của chúng và vào bản chất của các nghị quyết mà chúng cho phép ... ... Từ điển triết học mới nhất

phương pháp luận- PHƯƠNG PHÁP một loại ý thức phản ánh hợp lý nhằm nghiên cứu, cải tiến và xây dựng các phương pháp (xem Phương pháp) trong các lĩnh vực hoạt động tinh thần và thực tiễn khác nhau. Có những ý tưởng về phương pháp luận và ... ... Bách khoa toàn thư về nhận thức luận và triết học khoa học

phương pháp luận- (Phương pháp luận) Cấu trúc phương pháp luận, phương pháp luận nghiên cứu, các loại phương pháp luận Phương pháp luận khoa học, phương pháp luận lịch sử, phương pháp luận phân tích, phương pháp luận quản lý, phương pháp luận xã hội, những vấn đề của phương pháp luận Nội dung Nội dung Mục 1.…… … Bách khoa toàn thư của nhà đầu tư

PHƯƠNG PHÁP NGHIÊN CỨU KHOA HỌC- học thuyết về các phương pháp, phương tiện và quy trình của hoạt động khoa học, một phần của phương pháp chung về tri thức, cũng như một phần của lý thuyết về tri thức khoa học. Mọi phương pháp luận của khoa học trước hết đều xuất phát từ sự phân loại nhất định các phương pháp của tri thức khoa học. Như… … Triết học Khoa học: Từ điển thuật ngữ cơ bản

PHƯƠNG PHÁP TÂM LÝ HỌC KỸ THUẬT- (từ phương pháp Hy Lạp là con đường nghiên cứu, kiến ​​​​thức, logos giảng dạy) đây là những vị trí xác định mục đích, phương hướng và nội dung của tất cả các nghiên cứu của nó. sự phát triển của M. và. p. cho phép bạn xác định đối tượng và chủ đề nghiên cứu, mục đích và phương pháp của họ ... ... Từ điển bách khoa về tâm lý học và sư phạm

Sách

• , Limarenko G.N. Chuyên khảo nêu bật các vấn đề thiết kế, nghiên cứu lý thuyết, thực nghiệm và sản xuất thử nghiệm các bộ biến đổi chuyển động thanh răng, bánh răng và truyền động tịnh tiến ...
• Phương pháp thiết kế thanh răng và bánh răng dẫn động cho máy truyền động tự động. Chuyên khảo, Limarenko G.N. Chuyên khảo bao gồm các vấn đề về thiết kế, lý thuyết, thực nghiệm và 160; nghiên cứu sản xuất thử nghiệm bộ chuyển đổi chuyển động thanh răng và bánh răng và 160; chuyển động tịnh tiến ...

Theo nghĩa rộng, thiết kế là sự tổng hợp của một mô tả chính cho phép bạn tạo một đối tượng chưa tồn tại trong một số điều kiện nhất định. Từ ngôn ngữ Latinh, từ "projectus" được dịch là "ném về phía trước". Đối với một mô tả có thể được thể hiện trong tương lai dưới dạng một đối tượng thực, các bản ghi văn bản, tính toán, bản vẽ bảng được sử dụng và các thuật toán được sử dụng để thể hiện một chuỗi hành động có điều kiện. Nói chung, sau khi chi tiết, tính toán, bổ sung và tối ưu hóa, mô tả của đối tượng trở thành cơ sở để đưa ý tưởng vào cuộc sống.

Làm việc với một đối tượng chưa có biểu hiện vật chất (không tồn tại) trước khi tạo ra nó về cơ bản phân biệt thiết kế với mô hình hóa. Từ quan điểm của các giai đoạn, thiết kế có thể vừa là giai đoạn cuối của giai đoạn nghiên cứu vừa là giai đoạn đầu của giai đoạn sản xuất (xây dựng). Nhưng thiết kế hiện đại là một quá trình đa dạng và nhiều mặt, có những đặc điểm và quy tắc riêng trong từng ngành riêng lẻ: từ thiết kế hệ thống điều khiển đến thiết kế trong xây dựng. Và, do sự phát triển của các ngành công nghiệp làm thay đổi các điều kiện của quy trình làm việc, nên các quy tắc hoạt động của dự án cũng thay đổi theo thời gian.

Thiết kế làm cơ sở cho sự hình thành của bất kỳ hoạt động nào

Bất kỳ thiết kế kỹ thuật nào cũng bắt nguồn từ nhu cầu xã hội rõ rệt, nhằm hướng đến nhu cầu xuất hiện của một số đối tượng kỹ thuật. Các đối tượng như vậy bao gồm kết quả của các hoạt động xây dựng, sản phẩm công nghiệp, phần mềm, quy trình, v.v. Và giai đoạn đầu tiên của bất kỳ thiết kế nào là thể hiện nhu cầu này dưới dạng một nhiệm vụ kỹ thuật hoặc phát triển một đề xuất kỹ thuật.

Thông thường, các điều khoản tham chiếu xuất hiện dưới dạng tài liệu (hoặc các tài liệu), thể hiện mô tả chính ban đầu của đối tượng. Do đó, các tác giả nhận được bộ tài liệu cuối cùng chứa thông tin đủ để sản xuất đối tượng trong các điều kiện nhất định. Theo nghĩa hẹp của từ này, tài liệu như vậy, là phần mô tả cuối cùng, được gọi là một dự án. Do đó, thiết kế hiện đại thường được mô tả là một quá trình chuyển đổi từ mô tả ban đầu của một đối tượng sang mô tả cuối cùng bằng cách thực hiện một loạt các công việc nghiên cứu, tính toán và thiết kế.

Quá trình biến đổi như vậy gây ra sự xuất hiện của một số mô tả trung gian, mỗi mô tả tổng hợp một số kết quả của việc giải quyết các vấn đề giai đoạn. Trong một số mô hình thiết kế (ví dụ, trong các phương pháp lặp lại), các kết quả trung gian như vậy thường trở thành cơ sở cho các cuộc thảo luận về nhu cầu tiếp tục thiết kế và về các hướng phát triển quy trình nếu các kết quả trung gian được chấp thuận. Trong các mô hình khác (ví dụ: trong mô hình thiết kế theo giai đoạn cổ điển trong xây dựng), các mô tả trung gian (thiết kế phác thảo, khảo sát kỹ thuật, v.v.) trở thành một cột mốc bắt buộc trong việc tạo ra một gói tài liệu hoàn chỉnh.

Là một phần của hoạt động kỹ thuật, thiết kế hiện đại có một số đặc điểm phản ánh nội dung của quá trình này.

Theo việc sử dụng hoặc không sử dụng phần mềm chuyên dụng và lao động thủ công trong quá trình hoạt động của dự án, có:

• thiết kế có sự hỗ trợ của máy tính dựa trên sự tương tác giữa máy tính và con người,
• thiết kế tự động, được thực hiện ở giai đoạn trung gian mà không cần sự can thiệp của con người,
• thủ công.

Phần lớn các dự án vẫn được thực hiện theo kiểu tự động hóa và thiết kế tự động được áp dụng cho các đối tượng tương đối đơn giản. Nhưng ngay cả trong tỷ lệ này, thị phần của máy tính không ngừng tăng lên.

Phương pháp thiết kế

Các nguyên tắc và ý tưởng cơ bản của thiết kế được thể hiện theo cách tiếp cận có hệ thống, được đặc trưng bởi việc xem xét các bộ phận của một hệ thống hoặc hiện tượng phức tạp về mặt tương tác của chúng. Để làm điều này, cấu trúc của hệ thống đối tượng được tiết lộ, các mối quan hệ được loại bỏ, các thuộc tính được xác định và ảnh hưởng của môi trường bên ngoài được phân tích. Giải pháp cho những vấn đề này trong khuôn khổ thực hiện phương pháp tiếp cận có hệ thống dẫn đến việc tạo ra các nguyên tắc có mức độ khái quát hóa khác nhau. Do đó, "Lý thuyết về Hệ thống" chẳng hạn, khám phá thiết kế của các hệ thống kinh tế và xã hội phức tạp và thường là bán cấu trúc.

Trong kỹ thuật, các hệ thống kỹ thuật phức tạp được nghiên cứu trong khuôn khổ của chuyên ngành "Kỹ thuật hệ thống", tương tự như lý thuyết hệ thống. Ngoài quá trình tạo và vận hành một hệ thống kỹ thuật, bộ môn nghiên cứu các nguyên tắc và phương pháp thiết kế của nó. Để làm điều này, điều quan trọng là phải hình thành rõ ràng các mục tiêu hệ thống và tổ chức xem xét hệ thống từ quan điểm này. Điều này cho phép bạn từ bỏ việc thiết kế các yếu tố và bộ phận không quan trọng, tập trung vào các vấn đề tối ưu hóa.

Việc cụ thể hóa và giải thích các ý tưởng ban đầu của cách tiếp cận hệ thống được phản ánh trong các cách tiếp cận phái sinh khác để thiết kế:

• cách tiếp cận cấu trúc. Nó liên quan đến việc tổng hợp các tùy chọn hệ thống từ các thành phần khối. Với việc liệt kê một phần các thành phần, có thể dự đoán trước các đặc điểm của chúng.
• Phương pháp phân cấp khối. Bản chất của cách tiếp cận thiết kế này là ở giai đoạn đầu tiên, đối tượng được coi là một "hộp đen" khép kín, cấu trúc bên trong của nó chưa được biết. Sau đó, dần dần, từng cấp độ, bắt đầu từ đối tượng đầu tiên, đối tượng được chi tiết hóa, kết nối giữa các khối được thiết lập. Đầu tiên, tương ứng, là các khối của cấp độ 1, sau đó các khối của cấp độ 2 xuất hiện và được trình bày chi tiết, v.v. - cho đến khi có được các khối ở cấp độ thấp hơn với cấu trúc khá đơn giản và minh bạch. Với cách tiếp cận này, các chuyên gia khác nhau có thể làm việc trên các khối riêng lẻ, nhưng khó khăn là việc kết nối các giải pháp tiếp theo có thể gây khó khăn (bao gồm cả do tính chất ảo của các đối tượng được thiết kế). Nói chung, cách tiếp cận liên quan đến việc phân tách các mô tả phức tạp.
• Cách tiếp cận hướng đối tượng. Cách tiếp cận này giới thiệu một cấu trúc chắc chắn hơn liên quan đến việc phân phối dữ liệu giữa các lớp đối tượng. Ngoài ra, nhờ các mối quan hệ phân cấp và thừa kế, khối lượng thông số kỹ thuật được giảm và khả năng hỏng dữ liệu cũng giảm.

Trong thiết kế xã hội, tất cả các cách tiếp cận quy trình thường được chia theo tiêu chí định hướng của chúng thành 3 loại:

• với hướng đối tượng (hướng đối tượng),
• tập trung vào chủ đề (hướng chủ đề, hoặc thesarius),
• định hướng vấn đề (problem-oriented).

Nhu cầu tăng tốc độ thực hiện giai đoạn thiết kế của công việc gây ra sự xuất hiện của các phương pháp thiết kế mới.

phương pháp thiết kế

Đối với nhiều lĩnh vực hoạt động, rất khó để trình bày đầy đủ vấn đề thiết kế như một vấn đề chính thức lựa chọn phương án tốt nhất và hiệu quả nhất như một biểu thức toán học rõ ràng về tính tối ưu. Do đó, các phương pháp thiết kế khác nhau được lựa chọn tùy thuộc vào các điều kiện cụ thể và bổ sung cho nhau, có được các tính năng cụ thể trong các lĩnh vực hoạt động khác nhau.

• phương pháp đồ họa.

Các định luật của hình học mô tả áp dụng cho nó, theo đó một vật thể được mô tả trên một mặt phẳng. Tất cả những suy nghĩ, ý tưởng, hình ảnh và so sánh, phân tích và nghiên cứu nhiệm vụ thiết kế, phát triển kỹ thuật chi tiết đều được kèm theo một bản trình bày đồ họa dưới dạng sơ đồ, bảng, phác thảo, bản vẽ, đồ thị, văn bản. Mỗi bước của quy trình bị chi phối bởi các kỹ thuật cụ thể của riêng nó.

Ưu điểm của phương pháp là nó đáp ứng các điều kiện của quy trình thiết kế tất cả các yếu tố của các đối tượng khác nhau, không yêu cầu các công cụ và thiết bị phức tạp, dễ dàng đối phó với các quy mô và chi tiết khác nhau, và kết quả thiết kế bằng phương pháp đồ họa rõ ràng như nhau cho bất kỳ chuyên gia có năng lực được đào tạo kỹ thuật nào. Điều này làm cho phương pháp này trở thành ngôn ngữ quốc tế của hoạt động dự án. Các phương pháp khác cũng không thể thực hiện được nếu không có hình ảnh đồ họa, vì vậy phương pháp này được coi là phương pháp tham khảo hoặc phương pháp chính.

Phương pháp này dựa trên quy trình sắp xếp các mô hình ba chiều và các phần tử của chúng trực tiếp trong không gian. Với một tập hợp các yếu tố mô hình có điều kiện thống nhất, cũng như các mô hình thiết bị và kết cấu, bạn có thể xem xét nhiều phương án bố trí để chọn ra phương án tốt nhất. Việc áp dụng phương pháp này bị hạn chế bởi sự đa dạng của các thành phần bố cục mà nhà thiết kế tùy ý sử dụng, nhưng trong các tổ chức thiết kế nghiêm túc, sự đa dạng của các yếu tố không ngừng tăng lên và với sự có mặt của 3 máy in, việc đưa phương pháp này trở nên phổ biến. thực hành thiết kế là một vấn đề của tương lai gần. Giá trị thực tế và tầm quan trọng của phương pháp này cũng nằm ở chỗ ý tưởng mô hình hóa làm cơ sở của một thí nghiệm khoa học trở thành một phần của thiết kế khi tạo ra một mô hình.

• Phương pháp bố cục-đồ họa.

Là một cách kết hợp tư duy sáng tác, năng lực đồ họa và mô hình hóa khối lượng quy mô lớn, phương pháp phức tạp này phù hợp nhất với bản chất của quy trình thiết kế, đặc biệt là khi nói đến thiết kế kiến ​​trúc của các nhà máy công nghiệp. Với sự giúp đỡ của nó, thiết kế được thực hiện ở tất cả các giai đoạn, bắt đầu với ý tưởng xây dựng và kết thúc bằng việc tạo ra các bố cục làm việc của các kế hoạch tổng thể.

Bản thân phương pháp bố cục-đồ họa đang tích cực phát triển như một phương pháp phổ quát và làm cơ sở cho các nhánh riêng lẻ trong thiết kế - ví dụ: thiết kế ảnh và phim. Với sự trợ giúp của công nghệ hiện đại, chuyển động tự nhiên của con người trong không gian của vật thể tương lai được mô phỏng từ nhiều góc nhìn thực tế. Khi được sử dụng đúng cách, điều này cho phép bạn tạo ra các bố cục hoàn hảo nhất, do đó, làm giảm khả năng mắc lỗi bố cục trong quá trình chuyển đổi dự án sang tự nhiên.

• Phương pháp tự động (sử dụng công nghệ điện tử).

Phương pháp này cho phép bạn xử lý toàn bộ lượng thông tin cần được xử lý chính xác và nhanh chóng trong quá trình thiết kế. Các phương pháp trước đây, chủ yếu dựa vào sức lao động của con người, có những hạn chế khách quan giúp khắc phục việc sử dụng công nghệ tự động và điện tử.

Các dự án được tạo ra bằng phương pháp này có đặc điểm là tối ưu hóa trong nhiệm vụ tổng hợp các khía cạnh xây dựng, kỹ thuật, xã hội, thẩm mỹ, khoa học của dự án. Cho đến nay, giai đoạn khó khăn nhất trong việc áp dụng phương pháp này là giai đoạn tìm kiếm một ý tưởng như một tuyên bố nghệ thuật-kỹ thuật và cảm xúc-triết học.

Đối với tất cả sự phức tạp về kỹ thuật trong việc cung cấp một phương pháp tự động, nó và phương pháp bố trí đồ họa là một trong hai phương pháp thiết kế phát triển nhanh nhất.

Cấu trúc thiết kế

Thiết kế được chia thành các thủ tục, các giai đoạn và các giai đoạn. Việc thiết kế các đối tượng phức tạp bao gồm các giai đoạn sau:

• công trình nghiên cứu,
• công tác phát triển,
• dự án kỹ thuật,
• dự án làm việc,
• giai đoạn thử nghiệm một nguyên mẫu.

Giai đoạn đầu tiên thường được chia thành các giai đoạn nghiên cứu tiền dự án, đề xuất kỹ thuật và chuyển giao kỹ thuật. Nội dung của các hoạt động ở các giai đoạn này được rút gọn thành:

• nghiên cứu nhất quán về nhu cầu của xã hội đối với các sản phẩm mới với một mục đích nhất định,
• nghiên cứu các nguyên tắc vật lý, xây dựng, công nghệ và thông tin để tạo ra sản phẩm,
• dự đoán các đặc điểm có thể có của các đối tượng và các tham số của chúng.

Kết quả của công việc nghiên cứu là các điều khoản tham chiếu cho sự phát triển của cơ sở trong tương lai. Ở giai đoạn phát triển, một thiết kế dự thảo của sản phẩm được tạo ra và các nguyên tắc được thiết lập ở giai đoạn trước được chỉ định, xác minh và sửa chữa. Các giai đoạn của dự án kỹ thuật là "chịu trách nhiệm" cho các giải pháp kỹ thuật chi tiết. Và giai đoạn của dự án làm việc - cho một bộ tài liệu thiết kế và công nghệ hoàn chỉnh (đủ để sản xuất). Ở giai đoạn cuối cùng của quá trình thử nghiệm nguyên mẫu, các lỗi thiết kế được xác định dựa trên kết quả thử nghiệm và các biện pháp được thực hiện để loại bỏ những thiếu sót.

Theo quy định, các tổ chức thiết kế chuyên ngành chịu trách nhiệm thiết kế. Vì vậy, trong xây dựng, một mô hình được coi là cổ điển, trong đó khách hàng chuyển sang công ty thiết kế và sau khi thống nhất với khách hàng về khái niệm chung và nhận được các điều khoản tham chiếu với dữ liệu ban đầu, nó sẽ tham gia vào quy trình thiết kế nhiều giai đoạn .

Đối với một số loại hợp đồng công việc, tổng thầu đảm nhận chức năng tương tác với các tổ chức thiết kế. Các tiêu chuẩn kỹ thuật quốc tế cung cấp một số tùy chọn, trong đó các thỏa thuận phổ biến nhất là các hợp đồng theo tiêu chuẩn EPC (Xây dựng Mua sắm Kỹ thuật) và tiêu chuẩn EPCM (+ Quản lý). Trong trường hợp đầu tiên, nhà thầu cung cấp cho khách hàng dịch vụ thiết kế chìa khóa trao tay (cũng như mua sắm thiết bị và xây dựng). Trong trường hợp thứ hai, nhà thầu quản lý các quy trình này (bao gồm cả quản lý thiết kế).

Có thiết kế từ trên xuống (từ trên xuống), trong đó các nhiệm vụ của các cấp độ phân cấp cao hơn được giải quyết trước và thiết kế hướng lên (từ dưới lên), trong đó trình tự ngược lại được quan sát - từ các nhiệm vụ của các cấu trúc thấp hơn trong hệ thống cấp bậc. Trong các hệ thống phức tạp, thiết kế chức năng thường là từ trên xuống, trong khi thiết kế cấu trúc là từ trên xuống.

RUP dựa trên các nguyên tắc sau:

• 
  Xác định sớm và liên tục (cho đến khi kết thúc dự án) loại bỏ các rủi ro chính.
• 
  Tập trung đáp ứng các yêu cầu của khách hàng đối với chương trình thực thi (phân tích và xây dựng mô hình các tiền lệ (use case)).
• 
  Mong đợi những thay đổi trong yêu cầu, quyết định thiết kế và triển khai trong quá trình phát triển.
• 
  Một kiến ​​trúc thành phần được triển khai và thử nghiệm trong giai đoạn đầu của dự án.
• 
  Đảm bảo chất lượng liên tục ở tất cả các giai đoạn phát triển dự án (sản phẩm).
• 
  Làm việc trong dự án trong một nhóm gắn bó chặt chẽ, trong đó các kiến ​​trúc sư đóng vai trò chủ chốt.

Vòng đời phát triển

RUP sử dụng mô hình phát triển lặp đi lặp lại. Vào cuối mỗi lần lặp lại (lý tưởng là kéo dài từ 2 đến 6 tuần), nhóm dự án phải đạt được các mục tiêu đã lên kế hoạch cho lần lặp lại đó, tạo hoặc tinh chỉnh các sản phẩm thiết kế và có được phiên bản trung gian nhưng đầy đủ chức năng của sản phẩm cuối cùng. Phát triển lặp lại cho phép bạn nhanh chóng đáp ứng các yêu cầu thay đổi, phát hiện và loại bỏ rủi ro trong giai đoạn đầu của dự án và kiểm soát hiệu quả chất lượng của sản phẩm được tạo ra.

Vòng đời phát triển sản phẩm hoàn chỉnh bao gồm bốn giai đoạn, mỗi giai đoạn bao gồm một hoặc nhiều lần lặp lại:

Biểu diễn đồ họa của quá trình phát triển RUP

1. 
   Phân tích đối tượng tự động hóa. Các phương pháp phân tích. ARIS.

ARIS(viết tắt từ tiếng Anh. ngành kiến ​​​​trúc của tích hợp Thông tin hệ thống) - phương pháp và sản phẩm phần mềm nhân rộng để mô hình hóa quy trình kinh doanh của các tổ chức. Sản phẩm và phương pháp này thuộc sở hữu của công ty Đức Software AG do tác giả của phương pháp này, August-Wilhelm Scheer (tiếng Đức. Tháng Tám Wilhelm Scheer).

phương pháp luận

Trong số lượng lớn các phương pháp mô tả có thể, có thể phân biệt như sau:

1. 
   eEPC (tiếng Anh) chuỗi quy trình hướng sự kiện mở rộng) - phương pháp mô tả quá trình;
2. 
   ERM (tiếng Anh) thực thể- mối quan hệ kiểu mẫu) - mô hình "mối quan hệ thực thể" để mô tả cấu trúc dữ liệu;
3. 
   UML (tiếng Anh) thống nhât người mẫu ngôn ngữ) là một ngôn ngữ lập mô hình hướng đối tượng.

Công nghệ ARIS Script cho phép bạn tự động sản xuất:

1. 
   Hình thành các văn bản quy định dựa trên các mô hình ARIS (ví dụ: hộ chiếu quy trình, quy định quy trình).
2. 
   Hình thành các báo cáo phân tích dựa trên mô hình ARIS.
3. 
   Tích hợp Bộ công cụ ARIS với các ứng dụng và cơ sở dữ liệu khác.
4. 
   Hình thành cơ sở dữ liệu của các mô hình ARIS dựa trên các thông số kỹ thuật làm sẵn.

Khái niệm kiến ​​trúc ARIS.

Kiến trúc ARIS tạo cơ sở cho việc phát triển và tối ưu hóa các hệ thống thông tin tích hợp, cũng như để mô tả việc triển khai chúng. Việc lựa chọn các cấp độ và loại mô tả tạo thành kiến ​​trúc của ARIS, được sử dụng làm mô hình để xây dựng các quy trình liên quan đến quản lý kinh doanh, phân tích và đánh giá chúng.

các loại mô hình.

Hơn 100 loại mô hình được trình bày trong ARIS. Làm thế nào để chọn cách phù hợp nhất về cách tiếp cận mô tả của doanh nghiệp?

Thông thường, mô tả quy trình kinh doanh dựa trên chuỗi quy trình. Chuỗi có thể được mô tả dưới dạng sơ đồ VAD, sơ đồ này xem quy trình từ quan điểm chiến lược và sơ đồ eEPC (Chuỗi quy trình mở rộng) chi tiết. Sơ đồ eEPC là cốt lõi mô tả quá trình của từng quy trình trong doanh nghiệp (tất nhiên, khi khía cạnh quy trình của hoạt động được xem xét).

Các nhu cầu về mô hình hóa cơ cấu tổ chức được bao trùm bởi nhiều sơ đồ khác nhau, trong đó có sơ đồ Sơ đồ tổ chức - mô hình tổ chức. cơ cấu doanh nghiệp.

Các nhu cầu về mô hình hóa dữ liệu và lưu trữ thông tin có thể được đáp ứng bằng cách sử dụng tất cả các loại sơ đồ ERM và UML. Các sơ đồ này đưa ra một bức tranh hoàn chỉnh về cấu trúc dữ liệu và thành phần của tài sản thông tin của doanh nghiệp.

Các mô hình chức năng được thiết kế để mô hình hóa cấu trúc chức năng khi cách tiếp cận theo quy trình không được áp dụng hoặc chưa đủ củng cố vị trí trong tổ chức.

Có những mô hình đầu ra/điều khiển không được xem xét trong phần mềm ARIS nhưng không kém phần quan trọng trong quá trình lập mô hình. Các sơ đồ này được chứa trong các phần khác và mỗi phần của tòa nhà ARIS có sơ đồ điều khiển và đầu ra riêng.

Một số sơ đồ không thể được gán cho một hoặc một tính năng khác, bởi vì đặc điểm của chúng thuộc nhiều tham số. Trong trường hợp này, phương pháp lập mô hình "miễn phí" được tích cực thực hiện trong ARIS, khi các sơ đồ đó được sử dụng có thể hiểu được bằng trực giác, cho cả các chuyên gia trong lĩnh vực tư vấn cũng như quản lý và lập trình viên triển khai các mô-đun chương trình riêng lẻ.

Do đó, chúng tôi đã cố định một tập hợp các loại mô hình trong kiến ​​trúc ARIS, mỗi loại được “ký” theo cấp độ. Cùng với việc mô tả các vấn đề kinh doanh, đóng vai trò là điểm khởi đầu để phân tích, chúng tạo thành 13 thành phần của kiến ​​trúc ARIS. Bây giờ cần lựa chọn và trình bày các phương pháp mô tả từng thành phần của kiến ​​trúc.

Các tiêu chí để lựa chọn các phương pháp này như sau:

• 
  sự đơn giản và biểu cảm của các phương tiện của hình ảnh,
• 
  hỗ trợ cho nội dung ngữ nghĩa, để hiển thị các chi tiết cụ thể của chủ đề,
• 
  khả năng sử dụng một bộ đầy đủ các phương pháp cho các loại ứng dụng khác nhau,
• 
  mức độ quen thuộc với các phương pháp và sự sẵn có của các tài liệu cần thiết,
• 
  một mức độ độc lập nhất định của các phương pháp với việc triển khai kỹ thuật trong các hệ thống thông tin và truyền thông.

Tất cả những đặc điểm này đều được đáp ứng bởi phần mềm ARIS của ID Sheer.

ARIS vừa là một ký hiệu, một phương pháp, một sản phẩm phần mềm và một kiến ​​trúc. Khi họ nói ARIS, một người đã đọc bài viết này và các cuốn sách khác, chẳng hạn như do Vest-Meta Technology và Business Logic xuất bản, sẽ luôn làm rõ những gì đang được nói.

20 . Quy trình thiết kế. Thiết kế kiến ​​trúc hệ thống.

Thiết kế- quá trình phát triển dự định, nghĩa là, một bộ tài liệu được thiết kế để tạo một đối tượng cụ thể, hoạt động, sửa chữa và thanh lý của nó, cũng như để xác minh hoặc tái tạo các giải pháp trung gian và cuối cùng trên cơ sở mà đối tượng này được phát triển. Thiết kế là một quá trình lâu dài và bao gồm các giai đoạn từ chuẩn bị các thông số kỹ thuật đến thử nghiệm nguyên mẫu.

Thiết kế, bất kể nội dung của nó là gì, là một phần không thể thiếu của quy hoạch.

đối tượng thiết kế có thể là một đối tượng vật chất, hiệu suất công việc, cung cấp dịch vụ.

Thiết kế có cái riêng của nó phương pháp luận, mà bao gồm cấu trúc các hoạt động, Nguyên tắc và định mức các hoạt động, đối tượng, một đối tượng và của anh ấy người mẫu , phương pháp và vân vân.

kỹ thuật hệ thống giải quyết toàn diện các nhiệm vụ đặt ra, có tính đến sự tương tác và liên kết của các hệ thống đối tượng riêng lẻ và các bộ phận của chúng với nhau và với môi trường bên ngoài, có tính đến hậu quả kinh tế xã hội và môi trường do hoạt động của chúng. Thiết kế hệ thống dựa trên sự xem xét chung cẩn thận giữa đối tượng thiết kế (mô hình, cơ sở phần tử) và quy trình thiết kế (cấu trúc, nguyên tắc, định luật, phương pháp), do đó bao gồm một số phần quan trọng,

21. PP. Các phương pháp mô tả kiến ​​trúc hệ thống.

Thiết kế hệ thống nên dựa trên cách tiếp cận hệ thống. Cho đến nay, không thể tranh luận rằng thành phần và nội dung đầy đủ của nó được biết đến liên quan đến các hoạt động của dự án, tuy nhiên, điều quan trọng nhất trong số chúng có thể được hình thành:

• 
  Tiện ích thực tế:
  • 
    hoạt động nên được có mục đích nhằm đáp ứng nhu cầu thực tế của một người tiêu dùng thực sự hoặc một tầng lớp xã hội, lứa tuổi hoặc nhóm người khác nhất định;
  • 
    hoạt động nên được láu cá. Điều quan trọng là phải phát hiện ra những lý do ngăn cản việc sử dụng các phương tiện hiện có để đáp ứng nhu cầu mới, xác định những mâu thuẫn chính gây ra chúng và tập trung nỗ lực giải quyết các vấn đề chính;
  • 
    hoạt động nên được hợp lý và hiệu quả. Sẽ là hợp lý nếu không sử dụng bất kỳ giải pháp nào cho vấn đề, mà là tìm kiếm sự lựa chọn tốt nhất ;
• 
  Sự thống nhất của các bộ phận cấu thành:
  • 
    nên xem xét bất kỳ đối tượng nào, dù phức tạp hay đơn giản, như hệ thống, trong đó bạn có thể chọn các phần đơn giản hơn có liên quan về mặt logic - hệ thống con, sự thống nhất của các thuộc tính cụ thể tạo thành các thuộc tính mới về chất của hệ thống đối tượng;
  • 
    các đối tượng được phát triển là dành cho con người, chúng được tạo ra và vận hành. Do đó, một người cũng phải được coi là một trong những hệ thống tương tác. Đồng thời, không chỉ tính đến sự tương tác về thể chất, mà còn phải tính đến tác động về tinh thần và thẩm mỹ;
  • 
    bên ngoài, hoặc như nó còn được gọi là - môi trường sống, cũng nên được coi là một hệ thống liên kết với đối tượng được thiết kế;
• 
  Thay đổi theo thời gian:
  • 
    kế toán các giai đoạn của vòng đời của một đối tượng;
  • 
    có tính đến lịch sử và triển vọng phát triển và ứng dụng của đối tượng đang được phát triển, cũng như các lĩnh vực khoa học và công nghệ, dựa trên những thành tựu mà sự phát triển tương ứng dựa trên.

22. PP. Phong cách kiến ​​trúc và các mẫu thiết kế.

Vật mẫu(tiếng Đức Schablone) - trong xây dựng, một vật cố định hoặc dụng cụ để kéo phào chỉ.

mẫu thiết kế(mẫu, mẫu thiết kế tiếng Anh) là một thiết kế kiến ​​trúc có thể tái sử dụng, cung cấp giải pháp cho một vấn đề thiết kế chung trong một ngữ cảnh cụ thể và mô tả tầm quan trọng của giải pháp này. Một mẫu không phải là một kế hoạch chi tiết hoàn chỉnh có thể được chuyển đổi trực tiếp thành mã, mà là một mô tả hoặc mẫu về cách giải quyết vấn đề theo cách có thể được sử dụng trong nhiều tình huống. Các mẫu hướng đối tượng thường thể hiện các mối quan hệ và tương tác giữa các lớp hoặc các đối tượng mà không chỉ định các lớp hoặc đối tượng ứng dụng cuối cùng nào sẽ được sử dụng. Các thuật toán không được coi là khuôn mẫu vì chúng giải quyết các vấn đề tính toán chứ không phải các vấn đề thiết kế.

Vào những năm 1970, kiến ​​trúc sư Christopher Alexander đã biên soạn một bộ mẫu thiết kế. Trong lĩnh vực kiến ​​trúc, ý tưởng này không được phát triển nhiều như sau này trong lĩnh vực phát triển phần mềm.
Một phong cách kiến ​​trúc, đôi khi được gọi là một mẫu kiến ​​trúc, là một tập hợp các nguyên tắc, một lược đồ cấp cao cung cấp một khung trừu tượng cho một họ các hệ thống. Phong cách kiến ​​trúc cải thiện khả năng phân vùng và thúc đẩy tái sử dụng thiết kế bằng cách cung cấp giải pháp cho các vấn đề phổ biến. Các kiểu và mẫu kiến ​​trúc có thể được coi là một tập hợp các nguyên tắc hình thành nên một ứng dụng.
Chúng bao gồm các mẫu như máy khách/máy chủ, kiến ​​trúc phân lớp, kiến ​​trúc thành phần, kiến ​​trúc bus thông báo và kiến ​​trúc hướng dịch vụ.
Bảng sau đây liệt kê các khu vực trọng tâm chính và các phong cách kiến ​​trúc tương ứng.
ngành kiến ​​​​trúc

23. PP. Thiết kế kiến ​​trúc thông tin.

Kiến trúc thông tin là hệ thống hóa nội dung thông tin của trang web và điều hướng thông qua nó.

Mục đích của kiến ​​​​trúc thông tin là đơn giản hóa việc tìm kiếm thông tin cần thiết với sự trợ giúp của các siêu liên kết được đặt đúng chỗ và tổ chức thời gian lưu trú thoải mái của khách truy cập trên trang web.

Thiết kế kiến ​​​​trúc thông tin bao gồm phân tích nội dung của tài nguyên và quá trình phát triển cấu trúc của nó, điều này sẽ giúp người dùng tìm thấy thông tin cần thiết (ví dụ: tìm kiếm sản phẩm phù hợp, nhận câu trả lời cho câu hỏi, v.v.).

Một trang web có kiến ​​trúc thông tin được thiết kế tốt có những ưu điểm sau:

• 
  vị trí cao trong chỉ mục của các công cụ tìm kiếm: kiến ​​trúc thông tin làm nổi bật các yếu tố chính được các công cụ tìm kiếm sử dụng để tính toán mức độ liên quan của các trang (ví dụ: tiêu đề trang, từ khóa và cụm từ, tên thư mục, tệp, v.v.);
• 
  Cải thiện khả năng sử dụng: kiến ​​trúc thông tin đơn giản hóa công việc với tài nguyên (vị trí tối ưu của các yếu tố điều hướng chính);
• 
  các tệp được đặt và phân loại thuận tiện, do đó, sẽ tốn ít thời gian hơn để tìm kiếm chúng;
• 
  không cần cập nhật hoàn toàn trang web khi thêm tài liệu mới.

24. PP. Xây dựngcấp cứungười mẫu. Các loại ký hiệu.

mô hình mối quan hệ thực thể (cấp cứu-kiểu mẫu)(Tiếng Anh) thực thể- mối quan hệ kiểu mẫu, ERM) là một mô hình dữ liệu cho phép bạn mô tả các lược đồ khái niệm của lĩnh vực chủ đề.

Mô hình ER được sử dụng trong thiết kế cơ sở dữ liệu cấp cao (khái niệm). Với sự trợ giúp của nó, bạn có thể đánh dấu các thực thể chính và chỉ định các mối quan hệ có thể được thiết lập giữa các thực thể này.

Mô hình ER là một cấu trúc chính thức, bản thân nó không quy định bất kỳ phương tiện đồ họa nào để trực quan hóa nó. Là một ký hiệu đồ họa tiêu chuẩn mà bạn có thể hình dung mô hình ER, đã được đề xuất sơ đồ mối quan hệ thực thể (cấp cứu-biểu đồ)

Ký hiệu Peter Chen

Tập thực thể được hiển thị dưới dạng hình chữ nhật, tập mối quan hệ được hiển thị dưới dạng hình thoi. Nếu một thực thể tham gia vào một mối quan hệ, chúng được kết nối bằng một đường. Nếu mối quan hệ là tùy chọn, thì đường nét đứt. Các thuộc tính được hiển thị dưới dạng hình bầu dục và được kết nối bằng một đường thẳng với một mối quan hệ hoặc một thực thể.

Quá trình hình thành mô hình logic bao gồm các hoạt động sau:

• 
  định nghĩa thuộc tính (Attributes);
• 
  làm rõ thành phần của các thực thể của khu vực lưu trữ dữ liệu chi tiết (Hệ thống hồ sơ);
• 
  ánh xạ dữ liệu của hệ thống nguồn tới thuộc tính của các thực thể của mô hình dữ liệu logic;
• 
  định nghĩa về thứ bậc (Hierarchy);
• 
  xác định thành phần và loại phép đo thay đổi chậm (SCD);
• 
  định nghĩa các truy vấn nghiệp vụ cơ bản (Business Queries) - nhóm các yêu cầu của người dùng đối với một tập dữ liệu cụ thể;
• 
  tiến hành phân tích GAP:
  • 
    phân tích mô hình logic (có tính đến dữ liệu có sẵn trong hệ thống nguồn) để xác định các yêu cầu không thể đáp ứng;
  • 
    ra quyết định đối với những yêu cầu không thể đáp ứng;
• 
  xác định thành phần và cấu trúc của tập hợp (Summary Area), dữ liệu mart (Data Marts);
• 
  xác định thành phần của các giá trị (Miền) cho thứ nguyên và thứ bậc;
• 
  hình thành một tài liệu làm việc mô tả mô hình logic;
• 
  tiến hành kiểm toán bên ngoài mô hình - so sánh mô hình logic và các yêu cầu ở cấp độ các chỉ số;
• 
  phối hợp mô hình logic với các chuyên gia chức năng của Khách hàng.

26. PP. Xây dựng mô hình dữ liệu vật lý.

Thiết kế vật lí - sự sáng tạo lược đồ cơ sở dữ liệu cho một cụ thể Hệ quản trị cơ sở dữ liệu . Các chi tiết cụ thể của một DBMS cụ thể có thể bao gồm các hạn chế về cách đặt tên cho các đối tượng cơ sở dữ liệu, hạn chế về các loại dữ liệu được hỗ trợ, v.v. Ngoài ra, các chi tiết cụ thể của một DBMS cụ thể trong thiết kế vật lý bao gồm lựa chọn giải pháp liên quan đến môi trường lưu trữ dữ liệu vật lý (lựa chọn phương pháp quản lý lưu trữ đĩa, phân chia cơ sở dữ liệu thành tệp và thiết bị, phương pháp truy cập dữ liệu), tạo chỉ mục, vân vân.

Quá trình hình thành một mô hình vật lý bao gồm:

• 
  xác định quy tắc đặt tên cho các đối tượng cơ sở dữ liệu;
• 
  phát triển các đối tượng lưu trữ (bảng, dạng xem cụ thể hóa, hình khối, v.v.);
• 
  xác định thành phần của các trường (Cột) và kiểu dữ liệu của chúng (Kiểu dữ liệu);
• 
  hình thành khóa chính (Primary Keys) và khóa ngoại (Foreign Keys);
• 
  làm rõ thành phần giá trị (Miền) cho các chiều và thứ bậc;
• 
  thiết kế thành phần và cấu trúc của các phần (Partitions), chỉ mục (Indexes), trình tự (Sequences), v.v.
• 
  hình thành một tài liệu làm việc với một mô tả về mô hình vật lý;
• 
  phối hợp mô hình vật lý với các chuyên gia kỹ thuật của Khách hàng.

27. PP. Các mẫu kiến ​​trúc thông tin.
Chúng tôi đã lưu ý ở trên về mức độ phù hợp của việc tích hợp các ứng dụng và sử dụng các thành phần chung của hệ thống thông tin (dịch vụ). Sự phản ánh của thực tế này là xu hướng hiện tại tách các khía cạnh này thành các khu vực riêng biệt của kiến ​​trúc doanh nghiệp. Các yếu tố tiêu chuẩn hóa đóng một vai trò quan trọng trong việc thực hiện các lĩnh vực này.

Giống như thiết kế tòa nhà có thể bao gồm các yếu tố của cấu trúc đã tạo trước đó, do đó, việc triển khai hỗ trợ quy trình nghiệp vụ trong hệ thống thông tin có thể sử dụng các đoạn mã chương trình đã biết và / hoặc cấu hình thiết bị điển hình. Điều này một mặt cho phép giảm đáng kể thời gian cần thiết để hoàn thành giải pháp, mặt khác, giảm rủi ro thông qua việc sử dụng các mảnh đã được thử nghiệm trong thực tế. Thực ra đó là việc lựa chọn và sử dụng các mẫu (pattern) phù hợp. Thuật ngữ tiếng Anh "mẫu" có nhiều cách dịch khác nhau, bao gồm "mẫu", "mẫu", v.v. Trong trường hợp này, chúng tôi sẽ sử dụng thuật ngữ "mẫu" trong tiếng Nga, để lại "mẫu" trên giấy truy tìm để chỉ các đối tượng tương tự trong lĩnh vực kiến ​​trúc phần mềm. Có thể nói, các mẫu là những cách đã được chứng minh để xây dựng một số phần của hệ thống.

Một định nghĩa hay về các mẫu là: "Một mẫu là một giải pháp chung cho một số vấn đề lặp đi lặp lại trong một ngữ cảnh cụ thể."

Cơm. 7.7. Mẫu - giải quyết vấn đề trong ngữ cảnh

Nghĩa là, một khía cạnh quan trọng liên quan đến các khuôn mẫu là chúng đi kèm với những lời giải thích nhất định về lý do tại sao một giải pháp nhất định lại tốt trong một bối cảnh nhất định. Mẫu là bước tiếp theo để hiểu và áp dụng các mô hình. Mẫu cho biết điều gì làm cho một mô hình trở thành một giải pháp tốt và cách tạo ra một giải pháp cho một vấn đề cụ thể.

Ví dụ, việc nhận ra tầm quan trọng của các mẫu đã dẫn đến Phương pháp Mô tả Kiến trúc Gartner để chọn ra các mẫu như một "lớp" riêng biệt của kiến ​​trúc.

Việc sử dụng các mẫu có nguồn gốc rõ ràng trong kiến ​​trúc xây dựng. Đóng góp xác định cho việc hình thành khái niệm "mẫu" ban đầu thuộc về kiến ​​​​trúc sư nổi tiếng Christopher Alexander. Trong tác phẩm nổi tiếng năm 1987 của mình, ông đã xác định hơn 250 giải pháp kiến ​​trúc điển hình, chẳng hạn như cầu thang, hốc tường, kết nối giữa các văn phòng, v.v. Theo Alexander, mỗi nguyên mẫu như vậy thực sự xác định một giải pháp được đề xuất cho một vấn đề cụ thể trong một bối cảnh cố định. Trong bản gốc, Alexander làm nổi bật bối cảnh, các lực tác động và ứng dụng của khuôn mẫu. Theo bình luận ngụ ngôn của Cope, mô tả khuôn mẫu là một vở kịch. Bối cảnh thiết lập bối cảnh và xác định các diễn viên, các thế lực âm mưu, giải pháp được tìm thấy cung cấp cho Catharsis.

Mục tiêu ban đầu của các tác phẩm này của Alexander không phải là phát triển một số ý tưởng mới, mà ngược lại, phân tích kinh nghiệm xây dựng tích lũy - cả các tòa nhà riêng lẻ và toàn bộ thành phố - để xác định các giải pháp kiến ​​​​trúc thành công và các yếu tố góp phần để điều này. Tất nhiên, các tiêu chí để xác định thành công trong lĩnh vực này phần lớn là chủ quan, vì chúng phụ thuộc vào xã hội sử dụng các tòa nhà này. Trong lĩnh vực công nghệ thông tin, các tiêu chí đó có thể là mức độ đáp ứng đầy đủ các yêu cầu, độ bền, hiệu quả thực hiện và cũng phù hợp với trọng tâm, trước hết là mở rộng chứ không giới hạn khả năng của tổ chức. Một khái niệm quan trọng khác từ kiến ​​trúc công trình, được phản ánh trong lĩnh vực công nghệ thông tin, đó là ngôn ngữ mẫu (Pattern Language). Theo định nghĩa của Cope, nó là tập hợp các mẫu tương tác với nhau tạo thành một hệ thống.

Có ba cụm từ chính trong định nghĩa mẫu ở trên:

• 
  Quyết định chung. Điều này có nghĩa là mẫu không cung cấp giải pháp hoàn chỉnh. Thay vào đó, nó xác định loại vấn đề và cách giải quyết vấn đề đó bằng cách sử dụng một phương pháp cụ thể, đưa ra các lập luận ủng hộ phương pháp đó. Điểm mạnh của một mẫu là nó được xây dựng ở mức độ trừu tượng đủ cao để sử dụng trong nhiều tình huống khác nhau;
• 
  Vấn đề định kỳ. Điều này có nghĩa là các mẫu được sử dụng khi vấn đề không phải là duy nhất và chúng hữu ích nhất để giải quyết các vấn đề phổ biến;
• 
  Bối cảnh nhất định. Điều này có nghĩa là khuôn mẫu cung cấp giải pháp cho một vấn đề có ranh giới được xác định rộng rãi. Bằng cách hiểu các điều kiện theo đó một giải pháp được đề xuất ở dạng mẫu là tốt, sau đó bạn xây dựng giải pháp của riêng mình dựa trên mẫu đó.

Trong lĩnh vực công nghệ thông tin, các mẫu ban đầu được công nhận trong lĩnh vực kiến ​​trúc phần mềm. Một tác phẩm nổi tiếng của một nhóm tác giả (thường được gọi trong văn học Anh là "nhóm bốn người" theo số lượng tác giả trong cuốn sách) mô tả các cấu trúc chung cho các ngôn ngữ lập trình hướng đối tượng như C++. Một số lượng lớn các liên kết và ví dụ liên quan có sẵn tại http://www.patterns.com. Nhưng hóa ra khái niệm mẫu lại rất hiệu quả trong lĩnh vực kiến ​​trúc doanh nghiệp nói chung!

Liên quan đến công nghệ thông tin, chúng ta có thể nói rằng các mẫu là các mô hình logic của công nghệ: chúng là những ý tưởng thiết kế có thể được sử dụng lại trong toàn bộ doanh nghiệp. Theo quy định, các giải pháp này, theo một nghĩa nào đó, phục vụ như các tiêu chuẩn ngành và thường tồn tại trong một thời gian dài. Chúng có thể được coi là một số sơ đồ xác định các thành phần của giải pháp, tức là mức thiết kế logic (ví dụ: máy chủ dữ liệu hoặc máy chủ ứng dụng) và hiển thị vai trò, tương tác và mối quan hệ của các thành phần ở mức trừu tượng đó.

Khi chúng ta nói về các mẫu, chúng ta không nói về các mẫu phần cứng hoặc phần mềm cụ thể. Như được minh họa trong Hình 7.8, điều đáng quan tâm là một vấn đề khác: làm thế nào để các máy chủ giao tiếp với nhau và làm thế nào để chúng hoạt động cùng với hệ thống của một khách hàng sử dụng máy tính cá nhân? Mỗi thành phần đóng vai trò gì? Những loại thông tin liên lạc là cần thiết giữa họ?

Cơm. 7,8. Mẫu hiển thị sự tương tác của các thành phần hệ thống với nhau

Tầm quan trọng của các mẫu đối với toàn bộ kiến ​​trúc doanh nghiệp là do các lý do sau:

• 
  nếu các mẫu chính xác được sử dụng, thì xác suất có được một triển khai vật lý hoạt động đầy đủ của kiến ​​trúc sẽ tăng lên;
• 
  việc phát triển và sử dụng các mẫu trong toàn bộ doanh nghiệp mang lại những lợi ích liên quan đến việc tái sử dụng chúng để giải quyết các vấn đề khác nhau. Điều này mang đến cho các kiến ​​trúc sư cơ hội sử dụng kinh nghiệm và tiêu chuẩn hóa các giải pháp khi tạo ra các hệ thống mới;
• 
  việc sử dụng các mẫu phân tách lớp logic khỏi lớp vật lý của kiến ​​trúc. Điều này cho phép tạo ra các giải pháp dài hạn và mang lại sự linh hoạt vì các thiết kế khá lâu dài này có thể được liên kết với các giải pháp quy trình cụ thể ở giai đoạn sau.

Có thể nói, các khái niệm kiến ​​trúc (phương pháp) và các mẫu là hai công cụ để xây dựng mô hình và triển khai hệ thống thành công, nhanh chóng, tiết kiệm chi phí với rủi ro tối thiểu. Việc xác định các mẫu đề cập đến các miền kiến ​​trúc khác nhau (mẫu nghiệp vụ, mẫu cơ sở hạ tầng, v.v.) và các mức độ trừu tượng kiến ​​trúc khác nhau là rất phổ biến.

Cơm. 7.9. Kiến trúc, Hoa văn và Mô hình

Trong một doanh nghiệp, việc tạo một kho lưu trữ mẫu là điều hợp lý. Số lượng mẫu khác nhau dành riêng cho doanh nghiệp theo thứ tự là 30. Điều này bao gồm các mẫu sử dụng cho các hệ thống máy khách/máy chủ kế thừa và kế thừa, các mô hình cho kiến ​​trúc tương lai (ví dụ: hướng dịch vụ), v.v.

Mô tả các mẫu có thể được thực hiện với mức độ chi tiết khác nhau và phù hợp với điều kiện thực tế. Tùy thuộc vào cấp độ này, các yếu tố của ngôn ngữ mẫu có mức độ trừu tượng khác nhau có thể được xem xét - thành ngữ, mẫu thiết kế (mẫu thiết kế) và mô hình khung (khung). Trong trường hợp này, thành ngữ là mẫu ở "mức thấp nhất", phụ thuộc vào một công nghệ cụ thể. Các mẫu thiết kế có tính độc lập nhất định, nhưng đồng thời chúng không thể được coi là một hệ thống nói chung. Các mẫu lớp tiêu chuẩn là một ví dụ điển hình. Ví dụ, khái niệm "Object Factory" trong các ứng dụng hướng đối tượng, nói chung, không phụ thuộc vào việc lựa chọn một ngôn ngữ lập trình cụ thể và có thể được triển khai theo cách tương tự trong C ++ và Java. Cuối cùng, các mô hình khung là các hệ thống "hoàn thành một phần" thể hiện các yếu tố cơ bản nhất của việc triển khai hoặc là các hệ thống hoạt động đầy đủ cho một số điều kiện bên ngoài được đơn giản hóa, hạn chế hoặc lý tưởng hóa. Các mô hình này có thể được sử dụng làm cơ sở cho các cải tiến chuyên biệt, cũng như để nhanh chóng tạo ra toàn bộ mô hình hệ thống dựa trên các thành phần riêng lẻ đó.

Hơn nữa, khái niệm mẫu đã được mở rộng sang lĩnh vực cơ sở hạ tầng, vì vậy bây giờ chúng ta có thể nói về các giải pháp phần cứng và phần mềm phức tạp tương ứng. Đối với sự cân nhắc của chúng tôi, các mẫu có mức độ đủ cao được quan tâm nhiều nhất. Việc sử dụng các giải pháp như vậy hỗ trợ rất nhiều cho nhiệm vụ triển khai các yếu tố mới của hệ thống thông tin. Mỗi mẫu như vậy có thể kết hợp một phần mềm ứng dụng cụ thể, hệ điều hành, máy chủ DBMS, nền tảng phần cứng hoặc một số nền tảng phân tán, giao diện, siêu dữ liệu, v.v. Ví dụ điển hình là mẫu B2B (Doanh nghiệp với Doanh nghiệp) để tương tác với Khách hàng/Nhà cung cấp hoặc B2E (Doanh nghiệp với Nhân viên), mô tả sự tương tác giữa hệ thống thông tin và nhân viên.

Các mẫu cơ sở hạ tầng có thể được định nghĩa là một tập hợp các yêu cầu, thành phần và dịch vụ được tiêu chuẩn hóa cùng nhau tạo thành cơ sở hạ tầng phù hợp cần thiết cho một hệ thống ứng dụng nhất định và triển khai logic quy trình kinh doanh. Hình 7.10 minh họa định nghĩa chung của một mẫu cơ sở hạ tầng dưới dạng phân loại theo lớp các chức năng và danh sách biểu thị các thành phần công nghệ ở mỗi cấp độ.

Cơm. 7.10. Ví dụ về mẫu cơ sở hạ tầng

Tổ chức cơ sở hạ tầng bằng cách sử dụng một bộ mẫu cho phép bạn xác định các thành phần và chức năng theo cách nhất quán để phần này của cơ sở hạ tầng CNTT có thể được tái sử dụng cho các loại hệ thống ứng dụng khác nhau có các yêu cầu chung về cơ sở hạ tầng. Điều này phù hợp với nguyên tắc mà chúng ta đã trình bày trong Bài giảng 6 khi nói về thực tế là các kiểu và loại hệ thống ứng dụng và quy trình kinh doanh khác nhau có các yêu cầu cơ sở hạ tầng khác nhau. Do đó, thay vì xây dựng cơ sở hạ tầng cho từng ứng dụng, nó được phát triển dưới dạng một tập hợp nhiều mẫu, mỗi mẫu được thiết kế tối ưu cho một nhóm hệ thống ứng dụng cụ thể, như trong Hình. 7.11.

Cơm. 7.11. Từ kiến ​​trúc truyền thống đến kiến ​​trúc sử dụng mô hình cơ sở hạ tầng

Mối quan tâm lớn trong việc tạo ra kiến ​​trúc kinh doanh của một doanh nghiệp là các mẫu kinh doanh. Theo mô tả của doanh nghiệp mẫu bao gồm:

• 
  mô tả về chức năng kinh doanh được hỗ trợ;
• 
  dữ liệu được yêu cầu để thực hiện chức năng kinh doanh được mô tả;
• 
  các thành phần kinh doanh, là sự thể hiện dữ liệu và các chức năng kinh doanh bằng ngôn ngữ của công nghệ thông tin;
• 
  có lẽ là một mô tả về cơ sở hạ tầng cần thiết để hỗ trợ các chức năng, dữ liệu và thành phần.

Đối với những độc giả quan tâm đến vấn đề này, chúng tôi giới thiệu bài viết đã được đăng trên tạp chí Microsoft dành cho kiến ​​trúc; có thể tìm thấy ấn phẩm điện tử tại http://msdn.microsoft.com/architecture/journ/.

Một ví dụ khác, hãy xem xét khả năng của các mẫu Thương mại điện tử của IBM.

Vì hầu hết tất cả các ứng dụng kinh doanh điện tử đều phải đối mặt với nhu cầu giải quyết các vấn đề như khả năng mở rộng, độ tin cậy, tính khả dụng, bảo mật, nên có vẻ như việc sử dụng một số lượng tương đối nhỏ các giải pháp tiêu chuẩn hóa có thể hữu ích. Đến lượt mình, các giải pháp này có thể được chia nhỏ tùy thuộc vào mức độ trừu tượng - tương ứng thành các mẫu nghiệp vụ, mẫu kiến ​​trúc, mẫu mức ứng dụng, v.v. Trong đó:

• 
  các mẫu nghiệp vụ (Business pattern) được thiết kế để mô tả sự tương tác giữa những người tham gia quy trình;
• 
  các mẫu thiết kế phản ánh cấu trúc thành phần bên trong của hệ thống;
• 
  các mẫu lớp ứng dụng (Mẫu ứng dụng) xác định các tùy chọn khác nhau để tương tác giữa người dùng, ứng dụng và dữ liệu trong hệ thống, cũng như nguyên mẫu cấp độ chạy tương ứng;
• 
  các mẫu thời gian chạy mô tả sự ràng buộc của các thành phần hệ thống với các nút vật lý và xác định các sản phẩm cụ thể có thể có và sự kết hợp của chúng.

Theo sơ đồ đề xuất, 4 mô hình kinh doanh chính được phân biệt (xem Bảng 7.1).

Ngoài ra, còn có hai mẫu dịch vụ tương ứng là tích hợp truy cập và tích hợp ứng dụng.

Các mẫu này nhằm mô tả các khu vực điển hình như:

• 
  tương tác - tương tác giữa người dùng và doanh nghiệp (ví dụ: bán hàng hóa, dịch vụ không theo catalog) - U2B;
• 
  tương tác phần mềm giữa các ứng dụng của các doanh nghiệp khác nhau (B2B);
• 
  cộng tác của người dùng, bao gồm email, tin nhắn nhanh, diễn đàn chung, v.v. – U2U;
• 
  tìm kiếm thông tin trong danh mục và cơ sở dữ liệu, phân tích dữ liệu, đăng ký - U2D;
• 
  tương tác giữa các ứng dụng "trong doanh nghiệp", bao gồm cả việc không nhất thiết phải sử dụng giao diện web;
• 
  truy cập tập trung vào hệ thống ở cấp giao diện đã chọn (cổng thông tin) hoặc ở cấp tổng quát hơn (Web, điện thoại thoại, thiết bị di động, v.v.);
• 
  Bảo vệ.

Các mẫu có thể được sử dụng riêng lẻ hoặc kết hợp để thực hiện các giải pháp phức tạp phức tạp hơn. Để xác định các loại giải pháp này, các từ viết tắt đã trở nên phổ biến sử dụng cách phát âm tương tự trong tiếng Anh của số 2 và mối quan hệ giữa hai bên - các hệ thống như B2B, B2C, v.v. Ví dụ: một cửa hàng điện tử truyền thống (B2C) có thể bao gồm các yếu tố của nguyên mẫu U2D (Người dùng đến dữ liệu - công việc của người dùng với danh mục sản phẩm), U2B (Người dùng đến doanh nghiệp - đặt hàng), U2U (Người dùng đến người dùng - tư vấn với người bán hoặc liên hệ với bộ phận hỗ trợ).

Đối với việc triển khai kiến ​​trúc doanh nghiệp thống nhất trong thực tế, các mẫu tích hợp ứng dụng có tầm quan trọng đặc biệt. Trước hết, cần làm nổi bật hai loại liên quan đến mức độ thực hiện tương tác - tích hợp ở cấp độ quy trình và tích hợp ở cấp độ dữ liệu. Loại đầu tiên được sử dụng nếu dữ liệu từ một quy trình được sử dụng trực tiếp trong quy trình khác được liên kết với quy trình đầu tiên. Một ví dụ là việc sử dụng tin nhắn để đảm bảo phân phối dữ liệu từ chi nhánh ngân hàng đến văn phòng trung tâm. Một danh mục khác liên quan đến việc đồng bộ hóa dữ liệu giữa các quy trình không liên quan trực tiếp với nhau (ví dụ: tải dữ liệu tổng hợp từ hệ thống thanh toán của khách hàng vào hệ thống quản lý tiếp thị).

Bản thân các mẫu được xây dựng trên cơ sở một tập hợp các dịch vụ phổ biến được xác định trước có thể được đưa vào mẫu trong sự kết hợp cần thiết. Ví dụ về các dịch vụ được chia sẻ như vậy có thể bao gồm:

• 
  chuyển đổi dữ liệu (đặc biệt là nối/tách, thay thế, làm tròn, dịch từ ngôn ngữ này sang ngôn ngữ khác, sử dụng XSL để chuyển đổi XML->XML, v.v.);
• 
  định tuyến tin nhắn (bao gồm tối ưu hóa tuyến đường, nhân/tách nhân để gửi một đến nhiều, định tuyến động dựa trên nội dung, v.v.);
• 
  giao hàng đảm bảo;
• 
  kho lưu trữ thông điệp và siêu dữ liệu;
• 
  quản lý giao dịch, bao gồm cả giao dịch phân tán;
• 
  lập kế hoạch nhiệm vụ và hoạt động;
• 
  ghi nhật ký và kiểm toán;
• 
  quản lý tải (bao gồm hỗ trợ cụm, cân bằng động, trao đổi nóng, v.v.);
• 
  quản lý hệ thống, bao gồm phát hiện lỗi, giám sát tham số;
• 
  dịch vụ thư mục;
• 
  bảo mật, bao gồm mã hóa dữ liệu.

Các mẫu kiến ​​trúc tương tự theo thuật ngữ của Microsoft là Giải pháp Cấp độ Doanh nghiệp. Chúng được nhóm thành một mô hình đặc biệt theo mức độ trừu tượng và miền kiến ​​trúc (xem Hình 7.12).

Cơm. 7.12. Phân loại các mẫu kiến ​​trúc của Microsoft

Đồng thời, khu vực của các mẫu có thể nói là "giới hạn từ bên trên" bằng cách chỉ bao gồm cơ sở dữ liệu quan hệ, kiến ​​trúc phân lớp của các ứng dụng hướng đối tượng và hệ thống N-link. Do hạn chế này (cụ thể là các hệ thống OLAP và ứng dụng nguyên khối hoặc chạy trên cùng một nền tảng bị loại trừ khỏi việc xem xét), có thể đạt được chiều sâu phát triển đáng kể. Bộ này bao gồm các mẫu trình bày thông tin qua Web, hỗ trợ hệ thống phân tán, cung cấp dịch vụ, đảm bảo hiệu năng và độ tin cậy của hệ thống.
28. PP. Thiết kế kiến ​​trúc phần mềm.

Kiến trúc phần mềm (các bên liên quan (Tiếng Anh các bên liên quan), cho phép bạn nắm bắt các quyết định được đưa ra ở giai đoạn đầu thiết kế thiết kế cấp cao của hệ thống và cho phép bạn sử dụngCác thành phần cái này thiết kế và mẫu một lần nữa trong các dự án khác.

Ngôn ngữ mô tả kiến ​​trúc

Architecture Description Languages ​​(ADLS) được sử dụng để mô tả kiến ​​trúc của phần mềm. Một số ADLS khác nhau đã được phát triển bởi các tổ chức khác nhau, bao gồm AADL (tiêu chuẩn SAE), Wright (được phát triển tại Đại học Carnegie Mellon), Acme (được phát triển tại Đại học Carnegie Mellon), xADL (được phát triển tại UCI), Darwin (được phát triển tại Đại học Hoàng gia Luân Đôn) , DAOP-ADL (được phát triển tại Đại học Malaga) và ByADL (Đại học L'Aquila, Ý). Các yếu tố chung cho tất cả các ngôn ngữ này là các khái niệm về thành phần, trình kết nối và cấu hình.