Из моей лекции студентам. Мы не собираемся подробно забурятся в вопросы UML и прочего, нам нужна просто возможность какие-то архитектурные вещи визуализовать, в процессе разработки учебных проектов. И для этого был выбран ERIL.
Из лекции Ермакова писал(а):
Графическое моделирование программных систем
Что такое модель? Это какое-то отражение существенных черт оригинала. Оригиналы в данном случае - это решаемая программой задача и устройство самой программы.
Графическое моделирование может использоваться и на этапе анализа задачи, и на этапе проектирования, и для описания разрабатываемой системы.
Графические модели становятся частью проектной документации.
По поводу и графического моделирования, и подхода с добротной документацией в отрасли есть разные мнения. Одни не представляют без этого работы (и таких всё больше, особенно по мере улучшения уровня обучения в ВУЗах), другие говорят (и тоже из реального опыта): "нет толку от этого документирования, отнимает кучу времени поддержание актуальности, код уходит вперёд" и т.п. В отрасли есть примеры и того, как загибаются проекты, не имеющие нормальной документации (так будет рано или поздно с любым проектом, если только он не ведётся всё время одной и той же малой командой или вообще человеком, которые держат всё знание в головах). Если и примеры, как при обилии документации проект оказывается провальным. Это означает, что документировали не то, что нужно, или просто не смогли реализовать напроектированное.
Наиболее прагматичные сегодня подходы (допустим, см. Эрик Эванс "Предметно-ориентированное проектирование. Структуризация сложных программных систем.") пропогандируют принцип, что основная проектная документация - это всё же сам код. Он наиболее достоверен. И нужно находить способы по-максимуму смыслов выразить и закрепить в коде (даже не используя без необходимости комментарии). Но огромная роль также отводится правильной документации. Правильная документация включает в себя основные концепции, которые нужны для понимания системы. Т.е. она - модель системы, а модель - это не копия, не полное описание всех деталей, а отражение существенных черт.
Далее начинаются разногласия относительно графических методов в программировании и в проектировании. Есть языки графического программирования (LabView, реализации ДРАКОНа, Microsoft Robotics Studio, Scratch - хотя он не визуальный, а типа визуализованного текта...), есть их сторонники и противники, и есть языки графического проектирования-моделирования (от простейших - ER-диаграммы, до претендующего на универсальность UML - Universal Modelling Language. В дообъектную эпоху были распространены IDEF и SADT-диаграммы). Противники графического моделирования предлагаются ограничиваться неформальными описаниями на естественном языке, таблицами, неформальными иллюстрациями.
Какие факты имеют место быть:
1) Доказано, что хорошую, специально подготовленную графику мозг воспринимает лучше, чем текст - быстрее и т.п. Хотя есть процентов 15-20 людей, у которых может быть и наоборот. Однако если графика очень продуманная и строгая, то и у них она воспринимается, по крайней мере, не хуже, чем текст.
2) В большом числе случаев графику используют неправильно, недостаточно лаконично, выразительно, строго, не накладывают на неё строгие правила. Это и для мозга не так удачно, и ещё и вызывает неприятие у многих "умных людей".
3) Подготавливать графику труднее, чем текст, если нет специальных программных средств. Требования к инструментальному оснащению возрастают.
4) Свобода рисования оказывается часто недостатком. Сколько рисовальщиков схем - столько и вариантов. Сидишь и "чешешь репу", что поместить справа, а что слева, и под каких углом провести линию.
Это и затрудняет распространение графики. Для программирования переход на графику будет ещё долгим и только частичным. Скорее там восторжествуют вместо плоского текста "семантические редакторы" - когда редактируем дерево программы, видим всякие активные таблички, формируем программу блоками.
Но для моделирования хорошие графические языки - то, что надо.
Главное - правильно их использовать. Документация - это сама по себе всего лишь модель системы, она не должна быть чрезмерно детальной. А графическая модель - это уже самый "экстракт", самое главное из документации.
- изображайте самое главное, стрежневое;
- поддерживайте рисунки простыми;
- используйте строгие визуальные языки, если берёте большой раздутый язык типа UML, то берите небольшое подмножество.
И "будет щаЗтье".
В ПО есть две стороны, как известно: алгоритмы (поведение, процессы) и данные. ООП немного изменило ситуацию в том плане, что алгоритмы "растеклись" по данным, стали привязанными к данным. Это ещё больше повысило значение языков моделирования данных.
Т.е., имея язык моделирования алгоритмов (процессов) и язык моделирования структуры данных (соответствующий реалиям ООП), мы имеем полноценный арсенал визуального моделирования ПО.
Древний и простой визуальный язык моделирования алгоритмов - блок-схемы. Однако они имели много недостатков, почему от них все здравые люди отказались (хотя ГОСТ на них есть - и иногда по ГОСТу требуется формализовать алгоритмы блок-схемами, в частности, в курсовых и дипломных УНИИТ ГУ-УНПК). Сейчас большую популярность набирает пришедший из космической отрасли ДРАКОН - это язык изображения алгоритмов, ориентированный на 1) максимальное удобство для восприятия и 2) максимальное "ограничение свободы рисования". Т.е. это не рисунок, а некая жёсткая конструкция, построенная по строгим правилам.
Древнее и простое средство моделирования данных - это ER-диаграммы, "сущность-связь". Эти диаграммы можно применять и для моделирования реляционных баз данных, и просто для моделирования структур данных в памяти.
Чего не хватает им для соответствия ООП-эпохе?
Очевидно, что класс, тип данных - это и есть сущность.
Полиморфизм - это уже особенность уровня программирования...
Остаются инкапсуляция и наследование.
Инкапсуляция - это когда сущность содержит не просто пассивные данные, а ещё связанные с ними операции.
Ну, никто не мешает в прямоугольничках перечислять не только свойства (они же поля, атрибуты), но и операции с их списками параметров.
А наследование - это взаимоотношения между сущностями по принципу "род-вид", обобщение.
Можно их, условно, какими-то специальными стрелочками от подтипов к надтипам изображать.
В 90-х годах устоялся внешний вид таких стрелочек, он потом вошёл в UML, выглядит это так:
Вот и получается, что если взять ER-диаграммы, сущности описывать объектно-ориентированно - и изображать отношения обобщения (наследования), то мы получаем минимальный джентльменский набор для моделирования данных.
Учитывая, что в объектной системе и поведение рассредоточено по данным, то мы имеем основной инструмент описания структуры системы.
UML пошёл путём введения своих правил изображения классов, их отношений и особенностей, дополнил их другими видами диаграмм: как поведенческих (диаграммы взаимодействия, диаграммы деятельности), так и всяких вспомогательных (типа диаграммы пакетов, диаграммы способа использования) - и в нём получилось как некое базовое хорошее ядро (диаграммы классов, диаграммы взаимодействия классов) - которое используется повсеместно, в том числе в массе литературы, так и всякий необязательный мусор, который на практике удобнее описать текстовой документацией.
Ничего сложного в UML нет, пока он используется как язык документирования и проектирования.
Уже 20 лет безуспешным попыткам превратить UML в язык программирования - и генерировать код по диаграммам. Они провальны, потому что это менее удобно, чем писать код. А модель на то и модель, чтобы не было нужды детально прописывать каждую мелочь.
Ввиду того, что на практике нужно всё время только подмножество UML, трудно найти удобную программу, которая не содержала бы излишеств и т.п.
Мы будем использовать программу DRAKON Editor Степана Митькина, в которой с определённого момента в дополнение к ДРАКОНу появился свой визуальный язычок моделирования данных, названный ERIL (Entity-Relation & Inheritance Language - "язык для отношений сущность-связь и отношений наследования"). Собственно, он как раз и сделан по вышеописанной мысли дополнения ER-диаграмм, плюс содержит строгие правила, как их рисовать, плюс поддержан удобной и простой программой.