На каком уровне иерархии спецификаций начинается СПО (Илья Захаров, OSEDUCONF-2017)

Ссылки сюда (2) →

Короткая ссылка: 20170129C

Аннотация

Докладчик

Илья Захаров™

Базовым понятием идеологии свободного программного обеспечения (СПО) является исходный код, полный доступ к которому — обязательное условие, без выполнения которого не возможно свободно использовать, модифицировать и распространять ПО.

Таким образом, исходный код ПО — это тот уровень иерархии спецификаций, отношение к которому явно и однозначно определено идеологией СПО. Подразумевается, что СПО соответствует также и открытым спецификациям (стандартам). Однако их иерархия и, соответственно, полный перечень не определен. Каждый проект СПО использует необходимый для него набор спецификаций.

Между тем, на разных уровнях различных иерархий спецификаций происходят интенсивные процессы: спецификации разрабатываются, развиваются и предлагаются к использованию, в том числе на проприетарных условиях. Некоторые спецификации значительно влияют на развитие информационных технологий в целом и СПО в частности. Например, концепция обобщенного программирования и MDA. Для формирования обоснованных выводов о соотношении идеологии СПО и процессов разработки спецификаций необходимо определить иерархию, в рамках которой это соотношение возможно оценить. В докладе предлагается рассмотреть подходы к решению проблемы оценки различных спецификаций с точки зрения идеологии СПО.

Видео

on youtube

Слайды

Тезисы

1. Возможное определение иерархии спецификаций для оценки их соотношения с идеологией СПО

Построение такой иерархии должно учитывать основные направления развития информационных технологий (ИТ) и включать уже сложившиеся фрагменты структуры перспективных спецификаций. Обосновать легче наиболее общий уровень, начало иерархии, т. к. его можно определить из опыта, на основании исследования направлений развития ИТ. Он же, как родительский класс определит нижележащие слои иерархии спецификаций.

Например, вот что сказал Бьерн Страуструп в интервью Cnews в 2010 году: «Когда я начинал, никто не слышал об объектно-ориентированном программировании, а почти все, кто «знал», о чем шла речь, считали тему невозможной (слишком сложно, слишком трудно изучить, слишком медленно, слишком специализировано и так далее), и все же сегодня мы все пользуемся результатами той идеи. Аналогичная ситуация наблюдается сейчас с парадигмой обобщенного программирования: только представьте, что будет через десять лет...».

Здесь, как и во многих других авторитетных источниках речь идет об объектно-ориентированном программировании как стратегическом выборе. На сегодняшний день этот выбор привел к тому, что сформировалась иерархия спецификаций, которые в сбалансированном виде входят в язык моделирования UML. Причем, эту иерархию спецификаций есть все основания выстраивать начиная с онтологического понятия «объект», в смысле объект познавательной деятельности, то есть рассматривая объектно-ориентированный анализ как средство научной познавательной деятельности. Эти вопросы кратко изложены в докладе. В такой трактовке верхние уровни иерархии спецификаций ИТ-проектов могут выглядеть так, как изображено на рисунке 1.

2. Примеры кратких спецификаций диаграмм (моделей)

Дальнейшее специфицирование под свободными лицензиями типов моделей, называемых в языке UML диаграммами, создает методологические и юридические основания для развития открытой коллективной разработки ПО.

2.1 Краткая спецификация (теоретическая схема) диаграммы последовательности (вида диаграммы взаимодействия), которая в настоящее время подразумевается в языке UML.

2.1.1 Диаграмма взаимодействия — модель поведения кооперации, реализующая интегративное свойство системы. Другие варианты контекста: взаимодействие между объектами в реализации операций и ВСКД семантики класса.

2.1.2 Способы моделирования взаимодействий: в контексте времени (диаграмма последовательности); в контексте структурных связей (диаграмма коммуникации).

2.1.3 Взаимодействие (interaction) — поведение, в которое вовлечено множество сообщений, передаваемых между объектами, которые играют определенные роли в некотором контексте для достижения заданной цели.

2.1.4 Сообщение — это спецификация взаимодействия объектов, которая передает информацию и ожидает последующих действий. Сообщение чаще всего вызывает операции или передачу сигнала, а также может сопровождаться созданием или уничтожением объектов.

2.1.5 Типы сообщений: call (вызвать) — вызов операции объекта (наиболее частое событие); return (возвращает) — вызывает сообщение вызывающему объекту; send (послать) — посылает сигнал объекту; create (создать) — создать объект; destroy (уничтожить) — уничтожает объект, в т.ч. сам себя; не специфицируемые в UML сообщения (в части синтаксиса и семантики).

2.1.6 Синхронное сообщение — сообщение, ожидающее ответа (стрелка с закрашенным треугольником), ответ на синхронное сообщение (возврат из вызова) — пунктирная стрелка уголком (может не отображаться).

2.1.7 Асинхронное сообщение — сообщение, не ожидающее ответа (стрелка с уголком).

2.1.8 Роль — прототип объекта.

2.1.9 Коннектор — прототип связи между ролями.

2.1.10 Ссылка (link) — экземпляр ассоциации, смысловое (семантическое) соединение объектов друг с другом.

2.2 Краткая спецификация (теоретическая схема) диаграммы состояния (или конечного автомата), которая в настоящее время подразумевается в языке UML.

2.2.1 Диаграмма состояний (state diagram) — модель конечного автомата, показывающая поток управления от одного состояния к другому (граф с вершинами и ребрами). Может использоваться для моделирования практически любого элемента системы, однако чаще всего применяется для моделирования всей системы, подсистемы, класса, сценариев варианта использования, поведения интерфейсов.

2.2.2 Конечный автомат (state machine) — описание последовательности состояний, через которые проходит объект на протяжении жизненного цикла, реагируя на события, а также описание реакции на эти события. Подходит для спецификации поведения объекта, который должен отвечать на асинхронные сообщения либо его поведение зависит от прошлого. Явно специфицируются: события, на которые объект может реагировать, реакция на эти события, влияние более раннего поведения на текущее.

2.2.3 Состояние (state) — ситуация в жизненном цикле объекта, на протяжении которой он удовлетворяет некоторому условию, выполняет некоторую деятельность или ожидает некоторого события.

2.2.4 Событие (event) — спецификация существенного факта, которое происходит во времени и пространстве. В контексте автомата событие — это воздействие, которое вызывает переход между состояниями.

2.2.5 Переход (transition) — связь между двумя состояниями, показывающая, что объект, находящийся в первом состоянии, должен выполнить некоторые действия и перейти во второе, как только произойдет определенное событие и будут выполнены определенные условия.

2.2.6 Деятельность (activity) — процесс, работа, происходящая внутри автомата.

2.2.7 Действие (action) — примитивное выполняемое вычисление, приводящее к смене состояния модели или возврату значения.

2.2.8 Характеристики состояния объекта (автомата объекта):

• имя — текстовая строка, отличающая данное состояние от других (состояние может быть анонимным, т.е. без имени);
• входной/выходной эффекты (entry/exit) — действия, выполняемые при входе/выходе из состояния;
• внутренние переходы (internal transition) — переходы, которые обрабатываются без смены состояния;
• подсостояния (substate) — вложенные состояния, в том числе неортогональные (последовательно активные) или ортогональные (параллельно активные);
• отложенные события (deffered event) — список событий, которые не обрабатываются в данном состоянии, но откладываются и помещаются в очередь для обработки объектом в другом состоянии.

3. Спецификации метамоделей, начиная с наиболее общего (абстрактного) уровня

3.1 На рисунке 2 представлена предельно общая структурная модель современной научной картины мира. Её особое значение, несмотря на кажущуюся тривиальность, заключается в том, что данное представление является фактическим консенсусом.

Рисунок 2. Структурная модель объекта «Современная научная картина мира»

Степень общности и полноты, таким образом, определяет её прикладное значения для разработки различных систем. Если для каких-то задач целесообразно изобразить эту схему как на рисунке 2 в виде компонентов (концептуально более мягкая форма — пакеты), то в смысле объектно-ориентированного проектирования надо согласиться, что эта схема изображает структуру родительского класса для любых других систем, которые так или иначе должны наследовать свойства и операции этого класса. Вне терминологии объектно-ориентированного анализа и программирования то же самое можно сказать так: эта структура в явном или неявном виде должна учитываться при разработке любых теорий (схем, моделей и т.п.).

3.2 Вероятно, наиболее перспективная метамодель, позволяющая составить формализованное представление о сложной системе изображена на рисунке 3.

Рис 3. Условное название метамодели «внутренняя сложность»

Эта метамодель отражает подход к моделированию сложной системы, когда в качестве первой спецификации удалось выявить отдельные компоненты системы и определить их взаимосвязи. Стохастические процессы и другие неформализуемые характеристики остаются внутри компонентов, которые как «черные ящики» могут в дальнейшем быть более подробно специфицированы через состояние портов.

3.3 Распространенной метамоделью является первичное представление о сложной системе, как о логически разделяемом представлении о ядре и его окружении (или периферии). На рисунке 4 эта метамодель изображена в виде совокупности «пакетов» между которыми существуют связи типа «зависимость». «Пакеты» являются логическим представлением проектировщика о системе. На физическом уровне в системе такое разделение может отсутствовать.

Рисунок 4. Метамодель «ядро — периферия»

3.4 На рисунке 5 приведена поведенческая метамодель (в авторской нотации), которая отражает сценарий поведения систем уровня системной сложности с самоорганизацией (саморазвитием), предложенная В.С. Стёпиным.

Рисунок 5. Общая поведенческая модель самоорганизующихся систем, предложенная В.С. Степиным

• 1. Исходная саморегуляция.
• 2. Новый тип саморегуляции, основанный на трансформации предшествующих уровней иерархии системы.
• 3. Потенциально возможный уровень организации при продолжении развития системы как возможность нового типа саморегуляции.

Выводы

1. В терминах иерархии спецификаций, изображенной на рисунке 1, исторически сложившаясяся, «естественная», конкуренция свободного и проприетарного ПО находится в области спецификаций конкретных Классов, Объектов (в смысле экземпляров классов) и Артефактов. Расширение этой области конкуренции может привести к негативным для развития ИТ последствиям.
2. Целесообразно вовлечение в сферу свободных лицензий максимального объема спецификаций, начиная с максимально обобщенных уровней. Предположительно, наиболее важным на начальном этапе является публикация метамоделей различного рода и уровня иерархии, включая профили, шаблоны и т.д.
3. Требуется дальнейшая проработка вопросов построения иерархии(-ий) спецификаций, в рамках которых возможно определение отношения различных документов (спецификаций, стандартов) с идеологией СПО.
4. Если строить иерархию спецификаций от уровня Объекта научной познавательной деятельности, то это может создать юридические основания для защиты открытости нижележащих спецификаций, так как они наследуют его свойства и операции.

Примечания и отзывы

• Discuss on Facebook
• Discuss on VK

Plays:25   Comments:0