Чи існує стандарт документування архітектури високого рівня програми?


10

Я аматорський розробник, і всі мої програми до цих пір були досить простими, щоб бути задокументованими в коді. Під час читання коду було зрозуміло, що я роблю таку і таку дію (мій стандартний тест полягав у тому, щоб подивитися на 6 місяців пізніше і зрозуміти все на першому прочитанні - і у мене короткий проміжок пам’яті).

Зараз я зіткнувся з програмою, яка переростає у мій потенціал на запам'ятовування різних взаємодій між ними

  • сам код
  • індекси в базі даних
  • взаємодія між різними модулями (основний код «працівника» та «бібліотека»)

Моя поточна документація - це дошка, на якій я маю всілякі поля та стрілки, які вказують на код, на індекси бази даних, на дії, що виконуються, на зміну стану тощо. Просто для довідки, фрагмент безладу:

введіть тут опис зображення

Моє запитання - чи існує стандартний чи названий набір найкращих практик (названий у сенсі, що це набір практик, які були згруповані під конкретною назвою) для документації більш складних продуктів.

Які ключові слова я повинен шукати (загальні спроби "стандартів архітектури програмного забезпечення документа" та подібні варіації, як правило, призводять до програмного забезпечення для робочих процесів або архітектури систем CAD архітектури).

Я також очікую, що не може бути загальних найкращих практик для описів на високому рівні і що кожен будує свою власну філософію.


гм UML і звичайний звичайний старий текст зазвичай
jk.

Якщо ви можете прочитати німецьку мову, подивіться на arc42.de/template/index.html Вони показують деякі керівні лінії для документування архітектури програмного забезпечення.
Бернхард Гіллер

8
"Не турбуючись робити це взагалі", мабуть, найбільш близький до стандарту.
whatsisname

Відповіді:


13

Не існує жодного стандарту, якого всі дотримуються. Програми програмного забезпечення можуть сильно відрізнятися (подумайте: helloworld.py проти коду в космічному човні).

Один дуже поширений метод - використання моделі 4 + 1 . Замість того, щоб намагатися скомпонувати все в одному стилі документа, ця методологія розбиває дизайн на п'ять компонентів:

  • розвиток зору
  • логічний вигляд
  • фізичний вигляд
  • процес зору
  • Сценарії

Різні погляди описують продукт з чотирьох різних точок зору. Сценарії описують взаємодію інших поглядів.

Примітка. Це концептуальна модель і не пов'язана з будь-яким конкретним інструментом.

Більше ви можете прочитати тут:

  1. 4 + 1 модель архітектурного виду (вікіпедія)
  2. Архітектурні креслення - Перегляд моделі архітектури програмного забезпечення "4 + 1" (папір IEEE - pdf)

Це дуже хороший підхід, дякую. Відступивши назад, можна подумати, що це досить очевидно, але це дуже допомагає відключити різні 4 + 1 шматки, які я мав на одному графіку.
WoJ

4

IMHO UML не є інструментом, який добре працює для документування архітектури реального світу програмного забезпечення. Діаграми класів корисні, але використовують рівень абстракції, який часто є занадто низьким для цієї мети. Використовуйте діаграми регістрів, як правило, занадто "високого рівня" і пропускають певні аспекти. Інші типи діаграм UML мають подібні проблеми (якщо бути справедливими, діаграми пакетів, діаграми розгортання, компоненти діаграм можуть документувати певні архітектурні аспекти, але особисто я ніколи не вважав їх дуже корисними).

Якщо ви шукаєте прагматичний спосіб документування архітектур високого рівня, пропоную ознайомитись із діаграмами потоку даних . Вони легко зрозуміти і мають ту перевагу, яку вони можуть масштабувати до різних рівнів абстракцій. Я вважаю їх найбільш корисними для документування різних типів систем. Шкода, що вони не знайшли шлях до UML, але без того, що ви знайдете безліч інструментів - навіть безкоштовних, таких як Dia або DrawIO - для створення цих діаграм.

Як зауваження, чому вам потрібні "індекси в базі даних" в документації високого рівня? Я думаю, що вони є деталізацією реалізації вашої (реляційної?) Моделі даних, і якщо ви їх додасте чи ні, - на мій досвід - більше питання про ефективність та оптимізацію.


Пакетні діаграми? Діаграми розгортання? Діаграми компонентів?
Нік Кейлі

3
Чесно кажучи, купа коробок зі стрілками може творити чудеса для передачі низки дизайнерських особливостей. Я думаю, що діаграми компонентів потрапляють до цієї категорії, але мої клієнти розуміють потік даних у полях, що представляють основні біти. Я згоден з Док Браун. Формальність UML не вистачає позначки з цільовим призначенням.
Берін Лорич

@ NickKeighley: див. Мою редакцію.
Doc Brown

@BerinLoritsch: ІМХО "купа коробок зі стрілками" характеризує типи діаграм, згаданих Ніком Кейлі. Діаграми потоків даних, однак, чітко розрізняють дані або групи / кластери даних та процеси або компоненти, які передають або перетворюють ці дані. Це нічого, що я можу легко виразити з будь-якою з діаграм UML.
Doc Brown

1
Маю визнати, що інколи вдаюсь до діаграм потоків даних - особливо тих, які дозволяють магазини. Насправді діаграма верхнього рівня, яка описує нашу систему, по суті є DFD. Я все ще вважаю діаграми класів та пакет корисними для певної міри. Я не приділяю багато уваги "формальним" частинам UML.
Нік Кейлі

0

Уніфікована мова моделювання (UML) - це загальноприйнята, розвиваюча, моделююча мова в галузі інженерії програмного забезпечення, яка покликана забезпечити стандартний спосіб візуалізації дизайну системи.


Офіційну специфікацію можна знайти на omg.org/spec/UML/2.5, але в Інтернеті є чимало дружніх навчальних посібників.
Саймон Б

2
Ця відповідь є лише частиною запитання, UML є дефінітивно правильним інструментом для моделювання, але це не є повною документацією сама по собі
Walfrat

3
Хтось користується UML дуже часто?
Panzercrisis

малювання. зворотна інженерія.
Нік Кейлі

1
@Walfrat. є це? Дійсно? У мене є сумніви.
Doc Brown

-3

Я думаю, ми звикли робити краще. УМЛ ніби викидала дитину з ванною. Надаючи єдину мову моделювання, вона скасувала відмінність між архітектурою та реалізацією. Або якщо він не мав наміру, це, здавалося б, мало ефект.

Я бачив деякі монстрові моделі UML і, чесно кажучи, вони не роблять для мене нічого, що не міг зробити код, і роблять це краще.


3
не відповідає на питання, мабуть, краще, як коментар до відповіді SuperGirl.
Ньютопський

1
Це вирішує питання. Я стверджую, що відповідь на запитання - це більше «ні», ніж раніше.
Нік Кейлі
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.