Как узнать о формальном нисходящем подходе к архитектуре программного обеспечения?

Question

Я разработчик программного обеспечения, заинтересованный в поиске информации. В настоящее время я работаю над своим третьим проектом поисковой системы и ОЧЕНЬ разочарован количеством стандартного кода, который пишется снова и снова, с теми же ошибками и т. Д.

Базовая поисковая система - это очень простой зверь, который можно описать формальным языком, состоящим из двух "слоев":

1. "Слой примитивов" (или аксиомы, язык ядра - не знаю, как их назвать). Они состоят из нескольких наборов (в виде набора ресурсов - файлов, веб-сайтов), отношений на наборах (как "ссылки сайта A на сайт B") и простых операций, таких как "открыть поток на ресурс A", "прочитать запись из потока", "объединить N потоков", "индексировать набор записей по полю F" и т. д. Кроме того, существует множество способов преобразования данных, таких как "сохранить поток в формате YAML", "загрузить поток из формата XML" и т. д.

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

Такое высокоуровневое представление может быть легко протестировано, может быть даже формально доказано и реализовано (или сгенерировано кодом) на выбранном языке программирования.

Итак, вопрос: кто-нибудь проектирует системы таким образом - формально, строго (возможно, даже на уровне алгебры / теории групп), в строгом подходе сверху вниз? Что я могу прочитать, чтобы узнать?

Answer 1

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

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

Поскольку вы упоминаете формальные подходы в тегах вашего вопроса, вы должны быть заинтересованы в этой теме, но на данный момент это ниша. Я особенно не понимаю, как эти методы могут быть экономно применены в проектах поисковых систем. В любом случае, если вы хотите узнать больше о том, как эти методы применяются в областях, где они работают, вот несколько ссылок:

Кто-то упоминал, что Z: Z - это язык спецификаций, структура, в которой вы уточняете и уточняете спецификации до тех пор, пока они не становятся исполняемыми, называется B. Вы также можете быть заинтересованы в Alloy. И, наконец, существуют формальные языки спецификации для существующих языков программирования. Эта тенденция началась с JML для Java и вдохновила многих других. Я работаю в группе людей, которые определили такой язык спецификации для C, ACSL.

Answer 2

Для большинства наших проектов у нас есть архитектура, основанная на стандартной трехслойной архитектуре:

• Пользовательский интерфейс: проверено вручную
• Бизнес: проверено с насмешкой
• Прокси / доступ к данным: протестировано с интеграционными тестами

Чтобы узнать больше об архитектурных шаблонах, смотрите http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science)

Answer 3

Краткий ответ: "Да, в разной степени".

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

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

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

Answer 4

Хм. Не знаю, помогает ли это, но вы смотрели на Z обозначения? Я слышал об этом в универе, но не использовал его (я не брал этот модуль).

Answer 5

Я рекомендую посмотреть на IEEE-1471.

Answer 6

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

Я видел рабочие места с системами, разработанными с целью повторного использования кода, которые в конечном итоге используют v. Немногие и имеют дополнительную сложность вокруг.

Я считаю, что придерживаться принципов в SOLID, выполнение TDD, имея в виду DRY, YAGNI и KISS, имеет большое значение для достижения разумного уровня повторного использования.

Упомянутые вами операции являются прекрасными примерами различных обязанностей, которые не должны заканчиваться в одном классе:

открытый поток в ресурс A', ' чтение записи из потока ',' объединение N потоков ',' индексный набор записей по полю F'и т. д. Кроме того, существует много преобразований данных, таких как "сохранить поток в формате YAML". загрузка потока из формата XML и т. д.

Я рекомендую вам эту книгу на твердом теле.

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