Так что мой вопрос: кто-то уже проделал эту работу и нашел (или
даже половина найдена) структурированный способ экстраполировать соответствующий
метафора или эвристика для набора заданных задач программирования?
Возможно, у меня есть начало ответа на ваш запрос. Это состоит из нескольких уровней абстракции; описания нескольких доменов; и применение методов «моделирования» особым образом - действительно довольно отличным от того, что обычно делается в моделировании. Я полагаю, что общий подход - это то, что вы ищете - он дает метафоры, которые оперируются, а затем преобразуются в реальный результат. Он основан на ряде опубликованных подходов и в значительной степени опирается на некоторые из этих подходов и методов.
Что следует за этими оговорками:
- Это очень "работа в процессе".
- Я был на приеме унизительных комментариев о том, что я «астронавт архитектуры», с последующим выводом о том, что я не в курсе всех проблем, связанных с разработкой реальной системы. Это одна из причин, по которой эта работа еще не завершена - мой текущий проект предназначен для проверки этой концепции и демонстрации ее реальной полезности. Чтобы сделать это, мне нужно разработать систему достаточного масштаба и сложности, используя мой подход, который обычно был бы недоступен для отдельного разработчика. Я лишь часть такого доказательства концепции развития.
- Хотя описываемые мной концепции получены из рассмотрения сложных проблемных областей (система слежения за контактами гидролокатора и системы проектирования микросхем), мои примеры относятся к более простой области - в основном, к информационной системе, ограниченной системой правил. База правил включает в себя не только правила о домене, но и правила о применимости других правил.
- Я подозреваю, из вашего вопроса, что я иду к нему с противоположной стороны к вам. Вы просите способ экстраполировать соответствующую метафору или эвристику для набора заданных проблем программирования - что для меня подразумевает начало с проблем программирования. Мой импульс был со стороны анализа - я пытался найти и сформулировать способы описания предлагаемой системы, чтобы она могла быть реализована как реальная система.
- Когда я использую слова «модель» и «моделирование», я имею в виду моделирование, как описано ниже. Это описание несколько отличается от обычного использования этих терминов.
Три основные составляющие, необходимые для этого подхода:
Несколько доменов
Мое определение домена шире, чем обычно принятое:
Домен - это отдельный реальный, гипотетический или абстрактный мир, населенный
определенным набором объектов и явлений, которые ведут себя в соответствии с
правила и политики, характерные для домена. В проблеме
анализ. домен является полезной единицей рассмотрения при разработке
сложные системы.
В соответствии с этим определением в системе рассматривается несколько доменов. Часто, когда разработчики ссылаются на домен, они имеют в виду проблемный (или прикладной) домен (далее именуемый P ). Однако для этого подхода любой аспект системы или развития системы является потенциальным объектом для моделирования. Это включает архитектуру системы ( A ); артефакты создания системы (код, сценарии создания, схемы баз данных и т. д.) ( C ); Функции DBA; и т. д. Чтобы приблизиться к P через метафору, необходимо разработать несколько таких областей - связанных с метафорой и преобразованиями из метафоры в модель реального мира или в реализацию кода реальный мир в развитой системе. Когда разрабатывается несколько таких моделей, все они разрабатываются с одинаковой степенью охвата и точности.
Несколько уровней абстракции
Для описания проблемы и системы моделируются не только P , но и моделируются соответствующие более высокие уровни абстракции. Таким образом, метафора, выбранная для описания P, моделируется ( M ). Аналогичным образом моделируется формализм A ( F ), и, если это необходимо, процесс преобразования между P и C с использованием A ( R ). Таким образом, абстрагируешь проблемную область; реферат абстракции и пр.
Применение нескольких моделей аналогично цветоделению - они лежат друг на друге, и система должна соответствовать всем описаниям («полная картина») всех слоев. Опять же, это отличается от распространенных способов моделирования, которые, как правило, отвечают таким многочисленным требованиям путем разработки исходной модели с учетом различных ограничений. Это имеет особое значение, когда все домены архитектуры эффективно применяются ко всем элементам всех проблемных доменов.
Моделирование
То, что я имею в виду под моделированием, отличается от более обычных подходов к моделированию в следующих отношениях:
- Предмет модели, скорее всего, будет отличаться от домена к домену. Это контрастирует с моделированием, где начальные модели являются разработками других моделей. Действительно, один тест на достоверность модели состоит в том, что она представляет собой крайнюю версию принципов СУХОЙ - если что-то определено более чем в одном месте, это указывает на недостаток модели. Это распространяется на все рассматриваемые домены, поэтому способ построения системы определяется только в одном месте.
- Домен после моделирования, скорее всего, будет довольно статичным. Чем выше уровень абстракции, тем меньше вероятность его изменения.
- Область применения модели, вероятно, будет намного уже и намного глубже, чем те, которые обычно разрабатываются. Вероятно, в конкретной области будет меньше объектов, чем при обычном моделировании; но эти модели должны быть полными, и существуют тесты, которые дают некоторое представление о полноте модели (очевидно, никогда нельзя доказать, что описание системы является полным).
- P описывается в терминах, определенных как M . Модель может быть выражена в виде диаграмм, ОО представлений, математических формул или любого другого, подходящего для области M .
Следующий пример, полученный из моего проекта доказательства концепции, может дать некоторую конкретизацию моим описаниям выше. Я перечисляю некоторые из моих доменов вместе с содержимым кандидатов моделей доменов.
- P [Транспортные средства, единицы, движения, истощение, скорость ...]
- P1 [Правила, применимость, состояния, приоритеты ...] (вспомогательная проблемная область)
- M [Типы объектов, атрибуты, отношения, домены ...]
- A [События, таблицы, столбцы, домены базы данных, классы ...]
- F [Персистентный механизм, обработка, .....]
- C [Схемы базы данных, исходный код, сценарии SQL, сценарии сборки, ....]
- R [Формализмы, преобразования, отображения ...]
У этого подхода есть, по крайней мере, один существенный недостаток - работа, связанная с разработкой моделей, может рассматриваться руководством как непродуктивная, без реальных результатов.
Источники для этого ответа многочисленны и разнообразны, но сильно зависят от работ:
- Майкл Джексон по структурированному программированию; Системный анализ; и описания проблемных доменов.
- Метод Шлаера-Меллора развития системы путем преобразования, а не разработки.
- Консультирование по методике Кеннеди-Картера.