Описание предметной области программы

Проблема для решения – «сложности при изучении работы с классами в C++».

· обучение с преподавателем;

· обучающие и тестирующие программы.

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

1.8 Неформальная постановка задачи

Необходимо сделать программу, которая предоставляет обучаемому информацию по классам С++. Программа должна предоставлять возможность тестирования обучаемых. Результаты тестирования должны храниться индивидуально для каждого пользователя. Программа должна предоставлять возможность администрирования списка обучаемых и их результатов.

1.9 Обзор существующих методов решения

В качестве аналогичного приложения рассмотрим “AUK BC”. Это обучающая программа по работе с интегрированной инструментальной средой C++ [6].

1.9.1 Плюсы и минусы программы “классы в С++” в сравнении “AUK BC”

Понятия | Предметная область

· приложение разработано под windows;

· можно просто адаптировать под учебный процесс кафедры (осветить необходимые вопросы, построить специфичный набор тестов).

· размер готовой программы достаточно большой;

· неполное освещение предмета обучения.

Дело в том, что C++ – достаточно сложный язык. Всякие “хитрости”, тонкости, особые моменты находятся буквально в каждой конструкции. Поэтому разработка обучающей программы становится столь громоздкой, что возможно целесообразнее рассматривать отдельные разделы.

2. Требования к окружению 2.1 Требования к программному обеспечению

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

2.1.1 Для локальной сети

· Файловый сервер для хранения *.MDB файла;

· ODBC-драйвер Ms Access, установленный на стороне клиента;

· Web-браузер с установленным компонентом – Authorware Web Player.

Доступ к *.MDB файлу осуществляется посредством протокола NetBIOS. База данных пользователей храниться под управлением ODBC-драйвера (Рис.1). Недостатком данной схемы является низкий уровень секретности. Фактически необходимо знать только путь к *.MDB файлу, чтобы появилась возможность редактировать его вручную.

Рис. 1. Диаграмма компонентов

2.1.2 Для сети TCP/IP

· SQL сервер с настроенной базой данных пользователей;

· ODBC-драйвер SQL сервера, установленный на стороне клиента;

· Web-браузер с установленным компонентом – Authorware Web Player.

База данных пользователей храниться под управлением SQL сервера (Рис.2). Недостатком данной схемы является необходимость и конфигурирование SQL сервера. По сравнению с предыдущей схемой обеспечивается более высокая секретность.

Декомпозиция предметной области (на примере магазина)

Рис. 2. Диаграмма компонентов

2.2 Требования к аппаратному обеспечению

· Минимальная аппаратная платформа: Pentium 200 MHz / 32 MB Ram / 30 Mb свободного пространства на жестком диске;

· Рекомендуемая аппаратная платформа: Pentium-II 350 MHz / 64 MB Ram / 100 Mb свободного пространства на жестком диске.

2.3 Требования к пользователям

Программа поддерживает два типа пользователей:

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

2. Обычный пользователь

Имеет возможность ознакомиться с курсом и пройти тестирование.

3. Спецификация данных

При создании нового пользователя данные автоматически заносятся в базу данных MS Access, доступ к этой базе данных осуществляется через ODBC-драйвер. База данных представляет собой таблицу, каждая строка которой несет информацию о конкретном пользователе. Строка имеет следующую структуру (см. Табл. 1).

Источник: kazedu.com

Описание предметной области

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

Система предназначена для работников пункта выдачи заказов интернет-магазина. Такая система должна обеспечивать хранение сведений о доставках, содержащих набор посылок. Для каждой партии имеется накладная. В свою очередь каждая накладная включает в себя:

• Информацию о дополнительных платных опциях

• ценная посылка (ЦГР)
• возврат документов отправителя (ВДО)
• погрузка/разгрузка посылок при доставке (ПРД)

• ФИО отправителя/получателя
• название компании
• контактное лицо (для отправителя)
• адрес отправителя
• номер телефона
• почтовый индекс (для получателя)

• объявленная ценность
• сумма наложенного платежа
• описание содержимого
• отправитель
• дата
• время

• общее количество мест
• масса отправления
• ФИО исполнителя

• сумма платежа
• способ оплаты

Непосредственно сама посылка содержит следующий перечень:

Для того, чтобы клиент смог получить посылку, ему необходимо продиктовать соответствующий трек-номер, который высылается интернет-магазином по смс или на электронный адрес.

Данная информационная система будет разработана на базе MySQL Database Service. В базе, полученной в результате работы с MySQL, должны быть созданы необходимые таблицы, заполненные данными. Для этих таблиц должны выполняться простые и перекрестные запросы, а также запросы на добавление, обновление и удаление.

Разрабатываемая информационная система должна выполнять следующие функции:

• Предоставление большой совокупности информации в виде таблиц базы данных
• Формирование различных запросов по:

• Поставщикам (Название компании, контактные данные)
• Накладным
• Посылкам (номер, ФИО, наименование, адрес, стоимость, вес)
• Возвратам (типы товаров, стоимость, причина возврата)

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

2. Анализ предметной области и построение информационной модели «как есть» на основе структурного подхода

2.1 Функциональная модель idef0

Для функционального описания предметной области используем модель IDEF0.

На рис. 1 изображена контекстная диаграмма уровня А-0, которая позволяет увидеть все элементы системы, которые обрабатываются в ходе работы приложения.

Рис.1. Контекстная диаграмма уровня А-0.

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

• Формирование заказа в интернет-магазине
• Поиск на складе
• Заказ товара у поставщика
• Комплектация товара и отправка
• Учёт товаров в ПВЗ (склад ПВЗ)
• Выдача товара
• Оформление возврата

Блоки расположены сверху-вниз, что качественно отображает порядок выполнения работ.

Рис. 2. Декомпозиция контекстной диаграммы уровня А-0.

Далее декомпозируем каждый из функциональных блоков для подробного представления работы приложения.

Рис. 3. Декомпозиция функционального блока «Учёт товаров в ПВЗ (склад ПВЗ)».

Рис. 4. Декомпозиция функционального блока «Выдача товара».

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

Рис. 5. Диаграмма дерева узлов.

Источник: studfile.net

Императив предметной области при разработке информационных систем

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

У нас есть многочисленные техники и методики, полученные на основе огромного опыта создания программных систем, которые объясняют, как именно лучше выделять и отделять предметную область и другие части из системы. Мы умеем так изолировать эти части, что можем менять фреймворки для различных уровней архитектуры, использовать разные универсальные языки программирования (УЯП) и всё это существует вместе, масштабируется, выдерживает большие нагрузки, позволяет выполнять доработку компонентов, не переписывая всю систему. По большей части. Можем, когда хотим.

Прекрасно! Но почему мы до сих пор этого не делаем? Почему так много времени уделяем той части программной составляющей, которая не имеет отношения к предметной области – интерфейсу пользователя, вспомогательным слоям, работе с базой данных и постоянному связыванию этих частей с кодом предметной области в различных фреймворках? Неужели это настолько важно?

Почему мы часто начинаем разработку с продумывания интерфейса между компонентами вместо того, чтобы просто писать логику предметной области? Из раза в раз. Уже много лет. Несмотря на технические возможности делать всё правильно.

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

Скорее всего, проблема кроется в том, что мы привыкли так делать. Существующая индустрия разработки, инструменты, УЯП сверхвысокого уровня, рынки обучения, найма и продвижения достались нам по наследству. А ещё есть страх машинерии, которая должна связывать все наши компоненты и поддерживать масштабирование, из-за которого мы порой забываем об императиве предметной области и превращаем себя в леммингов, занимающихся обслуживанием вспомогательных механизмов.

Всё это – тот монолит, который мы пытаемся масштабировать хотя бы на наше настоящее и надеемся, что будущее придёт и превратит ком грязи в карету. Но так не бывает! Мы сами должны это сделать. Мы и есть будущее!

Пожалуй, довольно пафоса. Давайте попробуем взглянуть на проблему с той стороны, с которой она должна быть рассмотрена, а не с той, с которой мы боимся на неё не смотреть.

Начинаем с описания предметной области

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

Как это не банально, но язык описания предметных областей должен обладать семантикой описания предметных областей. Только в этом случае можно будет действительно удобно формировать модель предметной области, не отвлекаясь на второстепенные конструкции. Фокусироваться на декомпозиции предметной области на взаимодействующие подобласти, а не продумывать механизмы связи между ними. Таких семантик может быть много, но для начала выберем одну из достаточно универсальных техник манипуляции предметными областями – Domain Driven Design (DDD) [1, 2].

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

После выбора семантики описания предметной области можно определить синтаксис, который наилучшим образом её отражает. В итоге получится язык, который можно условно назвать Domain Driven Language (DDL). Далее будет приведён пример кода на этом языке. Но сначала давайте посмотрим, как это может работать.

На рисунке 1 приведена условная схема формирования информационной системы (ИС) на базе описания предметной области с использованием DDL.

Ключевым моментом является формирование из описания предметной области на DDL «чистой» семантики [3], которая на самом деле может являться набором стандартизированных JSON-документов и фрагментов кода на каком-либо УЯП, на основе которых, плюс заготовки для конкретной архитектуры, собирается ИС.

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

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

А может – монолит настольного приложения в архитектуре махрового клиент-сервера. Да что угодно! И даже всё вместе! При одном и том же описании предметной области.

Некоторые новые возможности

Первое, что может спросить frontend-разработчик: «где же разработка пользовательского интерфейса»? Впрочем, это касается и остальных компонентов архитектуры: неужели пользователи будут довольствоваться автоматически генерируемыми неотёсанными версиями компонентов вроде интерфейса пользователя и других важных частей, которые вручную можно сделать гораздо более красивыми, удобными и оптимальными?

Конечно нет. В смысле действительно есть возможность на основе «чистой» семантики автоматически генерировать и интерфейс пользователя, и структуру базы данных, но никто не запрещает это делать вручную. Особенно в критических местах. Для этого случая можно дополнить схему разработки из рисунка 1 группой UI-дизайнеров, которые формируют важные элементы пользовательского интерфейса. Однако эти и другие группы желательно размещать под «чистой» семантикой.

Важно заметить, что на рисунке 1 изображена упрощённая схема, которая не отражает многих важных особенностей предлагаемого подхода в разработке ПО. Например, не показано, что может работать несколько DDD-команд, каждая из которых реализует свой ограниченный контекст предметной области. И не отображена возможность автоматизировать не только формирование ИС, но и взаимодействие этих команд, а также интеграцию этого взаимодействия в общем репозитории, баг-трекинге, вики и других инструментах организации разработки сложных программных систем.

Ещё одной особенностью подхода является возможное формирование расширений семантики DDL для учёта каких-то особенностей конкретной предметной области. Для этого можно использовать расширенную трактовку контрактного программирования [4].

Да много чего ещё может появиться интересного при таком подходе. В качестве ещё одного примера можно привести раннюю диагностику проблем в рамках семантики DDL, которая гораздо строже семантики любого УЯП. Это означает, что многие потенциальные проблемы, которые невозможно диагностировать при формировании кода на УЯП, будут подсвечиваться редактором при вводе описания модели предметной области на DDL, причём с учётом расширенных контрактов [4].

Рассмотрим простой пример

В качестве примера можно рассмотреть модель предметной области заказа в интернет-магазине – пример весьма канонический, знакомый и «любимый» многими. На рисунке 2 приведён скрин описания заказа на прототипе DDL в интегрированной среде разработки системы SIMODO [5, 6].

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

Было бы крайне любопытно посмотреть на описание ваших предметных областей на этом языке, возможно, с использованием некоторых расширений (в виде модулей или дополнений в синтаксис языка), которые покажутся необходимыми. Это помогло бы в разработке языка. Можно предложить и свой синтаксис DDL.

Другие семантики предметных областей и предметно-ориентированные языки

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

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

Приведённый пример показывает, что можно использовать несколько языков, каждый из которых описывает свой участок предметной области. На рисунке 4 приведён фрагмент схемы из рисунка 1, который показывает более эффективное формирование модели предметной области, т.к. часть модели формируется специалистом собственноручно (безусловно, при этом может использоваться собственный ПОЯ, не обязательно только язык дифференциальных уравнений).

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

Может показаться, что данный подход неоправданно сложный, т.к. необходимо поддерживать довольно большое количество ПОЯ. И не безосновательно. Однако почти любой новый подход бывает сложным. И на этот счёт разработан метод автоматизации разработки языков с использованием единой операционной семантики и расширений для интерпретаторов семантических дополнений [3].

Заключение

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

Одним из решений, предлагаемых для реализации данного подхода, является создание инструмента, автоматизирующего разработку языков для предметных областей, в том числе для DDD, как предметной области автоматизации предметных областей. Такой инструмент в настоящее время разрабатывается на кафедре ИУ6 МГТУ им. Н.Э. Баумана.

Библиографические ссылки

Часть материалов и статей ещё не обработана или являются платными.

• Domain Driven Design
• DDD
• семантика
• предметно-ориентированный язык
• микросервисы

Источник: habr.com