Сложность определяется как количество информации: чем больше информации, тем сложнее, чем меньше информации, тем проще. Субъективно больший объем информации труднее понять.

Любая предметная область обладает сложностью, большей нуля, т.е. сложность любой предметной области составляет, как минимум, 1 бит. Любая часть предметной области может рассматриваться как самостоятельная предметная область. Разные предметные области обладают разной сложностью.

Решение представляет собой модель некоторой предметной области, записанной на некотором языке. Современные процессы разработки решений создают и поддерживают, в общем случае, несколько моделей (аналитическая модель, архитектурная модель и т.д.), каждая из которых представляет одну и ту же предметную область с разных точек зрения. Сам по себе такой подход уже является усложнением: несколько моделей одной и той же предметной области, и тем более в рамках одного процесса разработки – это всегда сложнее, чем одна модель.

Простейшая модель (решение), по определению, должна содержать минимум информации. Но быть проще предметной области (т.е. содержать меньше информации, чем предметная область) модель, в общем случае, не может. Следовательно,

модель (решение) будет простейшей в том случае, если она содержит информацию только из предметной области.

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

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

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

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

Исходя из вышесказанного, любая модель (решение) представима в виде:

модель = простейшая модель + оптимизация

Сложность модели будет определяться сложностью простейшего решения, плюс сложностью, вносимой оптимизацией. Как следствие, простейшая модель получиться в том случае, если в ней полностью отсутствует оптимизация.

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

Другой «проблемой» оптимизации является ее неотделимость от модели: очень часто, после оптимизирования модели, из нее уже невозможно выделить, ни простейшую модель, ни саму оптимизацию, в чистом виде. Оптимизация, что называется, «размазана» по модели, т.е. оптимизация становиться частью модели.

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

Остается определить, что является оптимизацией, а что – нет. Список элементов оптимизаций, видимо довольно большой, поэтому рассмотрим лишь некоторые.

1. Паттерны проектирования – это оптимизация модели по критерию гибкости внесения изменений в модель. Основным приемом паттернов проектирования является косвенность. Паттерны усложняют модель, увеличивая количество информации в ней.

2. Не все элементы языков программирования подойдут для записи простейшей модели. По-видимому, самый распространенный пример – это использование указателей для записи ассоциаций между объектами (имеется ввиду семантика обычных указателей С++; в других языках есть ссылки со схожей семантикой, например ссылки в Delphi). Указатель является оптимизацией по производительности. В предметной области объекты ссылаются друг на друга по ключу, а сами ключи заданы по значению (выражаясь языком С++). Значит и в простейшей модели объекты должны ссылаться друг на друга только по ключам. Состояние объектов в этом случае всегда стабильное, т.к. ключи заданы по значению. Если же в состоянии объекта есть указатель на другой объект, то такое состояние нестабильно: если объект, на который ссылаются, удален, то простое чтение состояния объекта, который ссылается на «труп», приведет к исключению. Это можно даже задать как критерий стабильного состояния: читать состояние объекта можно в любой момент времени. Именно такое поведение присутствует в предметной области.

3. Простейший поиск – это перебор. Применение любых других методов – это оптимизация по производительности.


По-видимому, проблему простейшей модели и оптимизации пытается решить языково-ориентированное программирование

Автор(ы): Сергей Дмитриев
Дата: 02.03.2006
Пришло время следующей технологической революции в разработке софта – и становится все очевиднее, какой она должна быть. Новая парадигма программирования – вот она, перед нами. Она еще не вполне сформировалась – разные части известны под разными именами вроде Intentional Programming, MDA, порождающее программирование и т.д. Я предлагаю объединение этих новаторских подходов под общим именем «языково-ориентированного программирования»; данная статья объясняет основные принципы новой парадигмы.

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