Как описать предметную область

Name already in use

PiRIS / articles / 5_1_1_4_analiz.md

• Go to file T
• Go to line L
• Copy path
• Copy permalink

1 contributor

Users who have contributed to this file

• Open with Desktop
• View raw
• Copy raw contents Copy raw contents

Copy raw contents

Copy raw contents

Анализ предметной области. Основные понятия системного и структурного анализа.

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

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

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

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

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

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

Анализ деятельности крупной организации, такой, как банк с сетью региональных отделений, нефтеперерабатывающий завод или компания, производящая автомобили, дает огромные объемы информации. Из этой информации надо уметь отбирать существенную, а также надо уметь находить в ней пробелы — области деятельности, информации по которым недостаточно для четкого представления о решаемых задачах. Значит, всю получаемую информацию надо каким-то образом систематизировать. Для систематизации сбора информации о больших организациях и дальнейшей разработки систем, поддерживающих их деятельность, применяется схема Захмана (автор — John Zachman) или архитектурная схема предприятия (enterprise architecture framework).

Таблица 1. Схема Захмана. Приведены примеры моделей для отдельных клеток.

В основе схемы Захмана лежит следующая идея: деятельность даже очень большой организации можно описать, используя ответы на простые вопросы — зачем, кто, что, как, где и когда, — и разные уровни рассмотрения. Обозначенные 6 вопросов определяют 6 аспектов рассмотрения.

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

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

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

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

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

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

Рисунок 1. Схема деятельности компании в нотации Йордана-ДеМарко.

Часто для описания поведения сложных систем и деятельности крупных организаций используются диаграммы потоков данных (data flow diagrams). Эти диаграммы содержат 4 вида графических элементов: процессы, представляющие собой любые трансформации данных в рамках описываемой системы, хранилища данных, внешние по отношению к системе сущности и потоки данных между элементами трех предыдущих видов.

Используются несколько систем обозначений для перечисленных элементов, наиболее известны нотация Йордана-ДеМарко (Yourdon-DeMarco) и нотация Гэйна-Сарсона (GaneSarson), обе предложенные в 1979 году. Рис. 1 показывает диаграмму потоков данных, которая описывает деятельность компании, управляющей небольшим магазином. Эта диаграмма изображена в нотации Йордана-ДеМарко: процессы изображаются кружками, внешние сущности — прямоугольниками, а хранилища данных — двумя горизонтальными параллельными линиями. На Рис. 2 изображена та же диаграмма в нотации Гейна-Сарсона: на ней процессы — прямоугольники со скругленными углами, внешние сущности — прямоугольники с тенью, а хранилища данных — вытянутые горизонтально прямоугольники без правого ребра.

Рисунок 2. Схема деятельности компании в нотации Гэйна-Сарсона.

Процессы на диаграммах потоков данных могут уточняться: если некоторый процесс устроен достаточно сложно, для него можно нарисовать отдельную диаграмму, описывающую потоки данных внутри этого процесса. На ней показываются те элементы, с которыми этот процесс связан потоками данных, и составляющие его более мелкие процессы и хранилища. Таким образом, возникает иерархическая структура процессов. Обычно на самом верхнем уровне находится один процесс, представляющий собой систему в целом, и набор внешних сущностей, с которыми она взаимодействует. На Рис. 3 показана возможная детализация процесса «Управление персоналом».

Рисунок 3. Детализация процесса «Управление персоналом».

Диаграммы потоков данных появились как один из первых инструментов представления деятельности сложных систем при использовании структурного анализа. Для представления структуры данных в этом подходе используются диаграммы сущностей и связей (entityrelationship diagrams, ER diagrams), изображающие набор сущностей предметной области и связей между ними. И сущности, и связи на таких диаграммах могут иметь атрибуты. Пример такой диаграммы представлен на Рис. 4.

Рисунок 4. Модель сущностей и связей.

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

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

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

Основные понятия системного анализа

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

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

Задачи структурного системного анализа

В менеджменте перед ССА ставятся следующие задачи:

• описать существующее положение вещей (объект управления), т.е. построить так называемую модель «как есть» («AS-IS»);
• предложить новые решения по структуре управления или технологии выполнения бизнес-процессов, т.е. построить модель «как должно быть» («ТО-ВЕ»). При этом предприятие рассматривается в качестве сложной бизнес-системы, функционирующей на основе определенного множества бизнес-процессов. Задачей реорганизации является перевод предприятия в некоторое целевое состояние, характеризующееся, как правило, качественно более высоким уровнем организации работы за счет:
  • повышения эффективности бизнес-процессов;
  • создания организационной структуры, направленной на поддержку выполнения бизнес-процессов;
  • создания информационной системы поддержки выполнения бизнес-процессов.

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

  В процессе ССА рассматриваются функциональные, информационные и динамические модели, а также модели функционально-стоимостного анализа (АВС-модели).

  Истоки структурного моделирования

  В основе ССА лежит графическое представление исследуемого или проектируемого объекта. Основы современных методов структурно-функционального анализа и моделирования сложных систем были разработаны в трудах профессора Массачусетского технологического института Дугласа Росса, который впервые использовал понятие «структурный анализ» в конце 60-х годов. О дальнейшем развитии идеи описания сложных объектов с помощью относительно небольшого набора типовых элементов свидетельствовало появление методологии структурно-функционального моделирования и анализа сложных систем (SADT), которая постоянно совершенствовалась и широко использовалась для эффективного решения целого ряда проблем (управление финансами и материально-техническим снабжением крупных фирм; разработка программного обеспечения АСУ телефонными сетями; долгосрочное и стратегическое планирование деятельности фирм; проектирование вычислительных систем и сетей и др.).

  Идеи и принципы ССА

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

  • Аналитику сложно получить исчерпывающую информацию для оценки требований к системе с точки зрения заказчика.
  • Заказчик, в свою очередь, не имеет достаточной информации о проблеме (реорганизации предприятия и бизнес-процессов или построении ИС) и поэтому не может судить о том, что является выполнимым, а что нет.

  Аналитик сталкивается с чрезмерным количеством подробных сведений как о предметной области, так и о новой системе.

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

  Методы ССА основаны на следующих принципах, помогающих преодолеть сложности, возникающие при описании систем:

  • расчленение систем на части «черные ящики»;
  • иерархическая организация этих «черных ящиков»;
  • использование графических средств.

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

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

  Второй важной идеей, лежащей в основе структурных методов, является идея иерархии.

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

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

  Другие принципы ССА

  Методология ССА строится на общих (базовых) принципах. Но существуют также и другие принципы, без учета которых не возможно проведение ССА:

  • формализации (необходимость строго методического подхода к решению проблемы);
  • абстрагирования (выделение существенных с некоторых позиций аспектов системы и отвлечение от несущественных с целью представления проблемы в упрощенном общем виде);
  • «упрятывания» (скрытие несущественной на конкретном этапе информации каждая часть «знает» только необходимую ей информацию);
  • концептуальной общности (следование единой философии на всех этапах ЖЦ: структурный анализ структурное проектирование структурное тестирование);
  • непротиворечивости (обоснованность и согласованность элементов); логической независимости (концентрация внимания на логическом проектировании для обеспечения независимости от физического проектирования).

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

  Классы моделей ССА:

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

  В качестве компьютерного инструмента ССА используются CASE-средства.

  CASE-cpедcmвa — комплекс средств автоматизации для анализа, проектирования, разработки и сопровождения сложных систем.

  В основе CASE лежат такие понятия, как методология, метод, нотация и средство.

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

  Метод — процедура или техника описания компонентов объекта исследования, программного обеспечения или ИС.

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

  Средства — инструментарий для поддержки и усиления методов.

  Принципы построения ИС.

  Проектирование имеет целью обеспечить эффективное функционирование АИС и взаимодействие АИТ со специалистами, использующими в сфере деятельности конкретного экономического объекта ЭВМ и развитые средства коммуникации для выполнения своих профессиональных задач и принятия управленческих решений.

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

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

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

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

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

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

  Принцип единого информационного пространства:

  • пространственная распределенность пользователей;
  • функционирование ИС в режиме реального времени;
  • расширенные глобальные телекоммуникационные возможности;
  • внутрисистемная информационная связанность;
  • множественность интерфейсов; виртуальность и однородность их технической реализации;

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

  Принцип надежности, защищенности и безопасности:

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

  Принцип эффективности заключается в достижении рационального соотношения между затратами на создание АИС и целевым эффектом, получаемым при ее функционировании.

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

  Для реализации перечисленных требований и обеспечения структурной и функциональной полноты интегрированной АИС необходима реализация проекта с соблюдением ряда принципов проектирования:

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

  Принцип первого руководителя предусматривает:

  • наличие у руководителя проекта реальных полномочий при рассмотрении и утверждении концепции и стратегии развития;
  • контроль за сроками, технологичностью и полнотой проекта;
  • возможность делегирования и перераспределения полномочий;
  • подготовку и переподготовку персонала, участвующего в проекте;
  • координацию усилий подразделений на всех стадиях жизненного цикла проекта системы;

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

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

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

  Рассмотренные базовые принципы дополняются не менее важными организационно-технологическими, без которых невозможна разработка новых информационных технологий. Наиболее применяемые организационно-технологические принципы создания АИТ:

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

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

  Пример описания предметной области «Фитнесс-центр»

  Программа для фитнес-центра по распределению фитнес – расписания и контроля его соблюдения

  Предполагается, что в системе фитнес центра будет 3 роли пользователей: клиенты, тренеры, администраторы. Авторизация в системе производится по телефону и паролю. Клиенты могут зарегистрироваться в системе, указав ФИО, телефон, пароль, дату рождения, фото профиля, пол.

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

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

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

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

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

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

  

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

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

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

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

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

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

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

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

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

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

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

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

  

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

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

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

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

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

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

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

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

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

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

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

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

  

  Рисунок 2. Пример описания агрегата «Заказ» на прототипе DDL в интегрированной среде разработки системы SIMODO

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

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

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

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

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

  

  Рисунок3. Пример описания модели динамического объекта и запуска моделирования в интегрированной среде разработки системы SIMODO

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

  

  Рисунок 4. Применение ПОЯ при формировании модели предметной области

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

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

  Заключение

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

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

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

  Эванс Э. Предметно-ориентированное проектирование (DDD): структуризация сложных программных систем.: Пер. с англ. – М.: ООО «И.Д. Вильямс», 2011. – 448 с.

  Вернон В. Реализация методов предметно-ориентированного проектирования. : Пер. с англ. – СПб. Ж ООО «Диалектика». 2019. – 688 с.

  Иванова Г.С., Фетисов М.В., Малкина Т.А., Ралдугина А.В. Унификация работы с предметно-ориентированными языками и открытая программная архитектура в адаптивной системе имитационного моделирования // Динамика сложных систем. 2021. T. 15. № 3. С. 36−47. DOI: 10.18127/j19997493-202103-03

  Ivanova G.S., Fetisov M.V. The concept of contract management in the base language of the adaptive modeling system. [Электронный ресурс]. URL: https://summa.stu.lipetsk.ru/assets/Final_programm.pdf (дата обращения: 05.12.2021).

  Иванова Г.С., Жильцов А.И., Фетисов М.В., Чулин Н.А., Юдин А.Е. Адаптивная система моделирования. – Автоматизация. Современные технологии, номер 11 за 2020 год, стр. 500.

  Олег и предметная область проекта

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

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

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

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

  Первым делом Олег отправляется изучать техническое задание.
  И не понимает ни слова.
  Более того, Олегу говорят, что через неделю он летит в командировку в лабораторию к клиенту, собирать данные о пользователях. Но Олег не понимает, что собирать, потому что не понимает совсем ничего.

  Олега начинают одолевать неприятные мысли о том, что он не очень-то и хорош как дизайнер.
  Что все его работы — мусор, и сам он тоже мусор и все тлен.

  Пока Олег прокрастинирует и самобичуется, попробуем разобраться, почему так вышло.

  Дело в том, что сложно понять дизайн-задачу, если не понимаешь, о чем проект.

  Привычные и понятные проекты, вроде тех, с которыми имел дело Олег, не требуют много времени на погружение. В таких проектах разрабатывается то, с чем мы сталкиваемся достаточно часто: интернет-магазины, посадочные страницы, календари и пр.

  Но бывают исключения — проекты со сложной предметной областью.

  Что такое предметная область

  Предметная область — это специфическая группа знаний.

  Помните, в школе у нас были разные предметы: химия, физика, биология?

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

  Для UX-дизайнера предметная область — это контекст, в котором существует (или будет существовать) система и пользовательский интерфейс.

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

  Для удобства можно разделить предметную область на три компонента:

  • специфичные термины и язык людей, которые живут/работают в предметной области,
  • важные объекты, существенные единицы предметной области,
  • то, как эти единицы вязаны и взаимодействуют.

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

  Чем глубже вы понимаете контекст проекта, тем эффективнее вы работаете на начальных этапах.

  Как разобраться в предметной области

  В знании предметной области я условно выделяю 4 этапа (или, если угодно, состояния поектировщика):

  Сейчас Олег находится в состоянии “Я ничего не знаю”.
  На то, чтобы максимально преисполниться и достичь состояния “Я эксперт” у Олега могут уйти годы. Как и у любого из нас.
  Поэтому последний этап мы опустим и поговорим о том, как достичь состояний “Я знаю, чего я не знаю” и “Я кое-что знаю”.

  И первый шаг на пути к просветлению — домашнее чтение.

  Шаг 1: домашнее чтение

  Итак, Олег берет себя в руки и решает перебраться из состояния «Я ничего не знаю» в «Я знаю, чего я не знаю». Он начинает читать.

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

  Олег остается один на один с тонной новой информации и разрозненных терминов.
  Яснее не стало.

  Олег предполагал, что путь будет прост.

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

  Как же из этой тонны информации выбрать то, что важно знать для проекта?

  Вам нужно знать ровно столько, сколько вам нужно знать.

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

  Поэтому, на этапе домашнего чтения, нам нужно сформулировать гипотезы и вопросы.

  Какие вопросы о предметной области нужно сформулировать

  Как мы уже обсудили, предметная область состоит из 3 компонентов: словарь, сущности и связи между ними.

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

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

  Артефакт — описание продукта с определённой точки зрения по заданному формату. Он помогает договориться всем участникам процесса, но его не увидит конечный пользователь.

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

  В случае изучения предметной области помогают 2 артефакта:

  • словарь — буквально список слов/терминов с их значениями и контекстом применения;
  • модель связей сущностей — диаграмма, отображающая то, как связаны главные объекты и роли предметной области.

  Именно этими артефактами решает заняться Олег.
  Он создает таблицу — словарь, куда вносит непонятные слова и предполагает их смысл.

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

  На основе своих артефактов Олег может составить вопросы.

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

  С домашним чтением покончено, у Олега куча вопросов.
  Он знает, чего он не знает.

  Что же с этими вопросами делать дальше? Самое время обратиться к экспертам.

  Шаг 2: Общение с экспертами

  Немного разобравшись с базовыми понятиями и сформулировав вопросы, Олег отправляется выяснять тонкие детали к экспертам.

  Почему нельзя сразу начать с экспертов, не тратя время на домашнее чтение?
  Эксперты — занятые люди. У них полно своих дел и работы.
  Лучше заранее разобраться в базовых вещах и сформулировать конкретные вопросы. Это позволит предметно и по существу общаться с экспертами, не тратя их время на объяснение основ.

  Кто такие эксперты и где их взять?

  Эксперты — люди, которые разбираются в предметной области и/или в ней работают. Они уже прошли минимум 2 этапа познания и находятся в состоянии “Я кое-что знаю” или “Я эксперт”.

  Ближайшими в зоне досягаемости экспертами могут выступать коллеги на проекте.
  Например, менеджер/руководитель проекта или бизнес-аналитик, которые уже давно варятся в этой кухне.
  Если до вас на проекте работали дизайнеры, они могли немного разобраться и оставить полезные документы.
  Часть сформулированных вопросов и гипотез можно обсудить с коллегами.

  Безусловно, экспертами являются лица, заинтересованные в реализации проекта:

  1. Заказчик. Он — точка входа для вас и связующее звено с теми, кто может вам помочь. Бывает, что заказчик и сам является экспертом.
  2. Пользователи. Часто в сложных проектах пользователи являются экспертами в предметной области. В случае Олега лаборанты будут стопроцентными экспертами в области клинических исследований.

  Для эффективного общения с заказчиком/пользователями можно использовать интервью и наблюдение.

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

  Артефакты обновлены.
  Словарь содержит верное объяснение терминов, в нем много деталей о разных понятиях, присущих компании N.

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

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

  Безусловно, со временем Олег еще лучше разберется в предметной области своего проекта и его артефакты дополнятся деталями.

  Вывод

  Попадая на проект со сложной (даже немножко) предметной областью, будьте как Олег.
  Исследуйте предметную область в два простых шага:

  1. Домашнее чтение. Это позволит сформировать общее представление о терминах, ролях и процессах; сформулировать гипотезы и вопросы к экспертам
  2. Общение с экспертами. Это позволит прояснить детали, проверить гипотезы, и дополнить артефакты: словарь терминов и модель связей сущностей.

  Немного полезных советов:

  • Будьте проактивны
  • Помните: вы не эксперт
  • Сфокусируйтесь на компонентах предметной области (словарь, сущности, связи)
  • Не бойтесь задавать вопросы
  • Сначала пообщайтесь с коллегами, затем с экспертами
  • Пишите заметки и проверяйте их
  • Документируйте

  Если статья показалась интересной — дайте знать аплодисментами ��

  Больше о проектировании интерфейсов и мемы по средам можно найти в телеграм-канале Поясни за UX

  Описание предметной области и определение цели проектирования

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

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

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

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

  Желательно описать алгоритмы выполнения тех или иных операций исполнителей конкретных видов работ или действий.

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

  Анализ предметной области и инфологическое проектирование

  В разделе «Функциональная модель предметной области» должны быть приведены результаты функционального моделирования предметной области учебной базы данных, выполненного в среде BPwin. Словесные описания особенностей функционирования предметной области должны сопровождаться изображениями контекстной диаграммы предметной области, диаграмм декомпозиции, иерархической схемы функций (Node Tree-диаграммы BPwin) (рис. 4-6), а также сводными таблицами (табл. 1 и 2) описаний работ (функций) и стрелок (данных).

  Р ис. 4. Пример контекстной диаграммы предметной области «Библиотека»

  Рис. 5. Пример диаграммы декомпозиции предметной области «Библиотека»

  

  

  Рис. 6. Пример иерархической диаграммы функций предметной области «Библиотека»

  

  Номер работы

  Описание работы

  Под работой библиотеки имеются в виду технологические аспекты ее функционирования

  Комплектование библиотеки и хранение новых книг

  Комплектование библиотеки предполагает приобретение новых книг, их хранение и списание

  Справочно-библиографическое обслуживание предполагает занесение сведений о книгах в каталог и поиск книг в каталоге

  Абонементное обслуживание

  Абонементное обслуживание, в том числе:

  1) запись на абонемент

  2) поиск книг в каталоге

  3) оформление заявки в хранилище

  5) прием возвращенных книг

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

  Экземпляры книг хранятся в хранилище и выдаются по заявкам абонентов во временное пользование

  Занесение в каталог

  Вновь приобретенные книги регистрируются в каталоге

  По запросу абонента осуществляется поиск информации о книге в каталоге

  Запись на абонемент

  Посетители библиотеки могут быть записаны в качестве ее абонентов

  Поиск сведений о книге выполняется по заявке абонента

  Затребованные книги при наличии их в хранилище могут быть выданы

  При наличии свободного экземпляра книги в хранилище оформляется заявка на затребованную книгу

  Выданные книги подлежат возврату и размещению их в хранилище

  

  Имя стрелки

  Описание стрелки

  Абоненты — это зарегистрированные клиенты библиотеки. После регистрации они приобретают права законных пользователей

  Бюджет регламентирует все виды работ в библиотеке

  Возвращенные на абонемент книги размещаются в хранилище

  Выданные книги — это один из вариантов книг на выходе и один из вариантов поступления книг

  Перед оформлением заявки выполняется запрос на поиск информации о книге в каталоге

  Статус зарегистрированной приобретает книга после ее занесения в каталог. После регистрации в каталоге зарегистрированная книга поступает на хранение

  При наличии свободного экземпляра по заявке затребованная книга поступает на абонемент

  При наличии свободного экземпляра книги оформляется заявка на ее получение во временное пользование

  Книги на входе

  Источники книг на входе библиотеки:

  1) новые поступления

  2) возвращенные книги

  Книги на выходе

  Книги на выходе‑это:

  1) зарегистрированные, но не востребованные книги

  2) выданные книги

  3) списанные книги

  Новые книги — это один из вариантов поступления книг в библиотеку

  Библиотеку могут посещать клиенты, не являющиеся ее абонентами

  Правила пользования распространяются только на справочно-библиографическое и абонементное обслуживание

  Книги, пришедшие в негодность, подлежат списанию. Это один из вариантов книг на выходе

  Справка — это результат справочно-библиографического поиска по запросу абонента

  После поступления новой книге присваивается инвентарный номер и она приобретает статус учтенной книги. Учтенная книга поступает на хранение

  Книги, поступившие на хранение либо после присваивания им инвентарного номера, либо после их регистрации в каталоге

  

  В разделе «Информационная модель предметной области» должны быть приведены результаты разработки информационной модели предметной области в терминах модели «сущность-связь», выполненной в среде ERwin (т.н. Logical Model) [10] (рис. 7).

  В разделе «Спецификации сущностей» следует для каждой сущности указать:

  Результаты удобно свести в таблицу типа приведенной ниже (табл. 3). При построении таблицы следует воспользоваться возможностями ERwin для формирования отчетов (по команде Tasks/Generate Reports).

  Имя сущности

  Описание сущности

  История выдач и возврата книг. Содержит сведения о том, кому, кем, что и когда было выдано или возвращено

  Содержит информацию об абонентах библиотеки

  Содержит информацию о книге, зарегистрированной в каталоге

  Содержит информацию о сотрудниках библиотеки

  Сотрудник, являющийся абонентом библиотеки

  Студент, являющийся абонентом библиотеки

  Содержит информацию о наличии экземпляров свободных книг

  В разделе «Спецификации атрибутов» для каждого атрибута указать:

  Результаты удобно свести в таблицу типа приведенной ниже (табл. 4). При построении таблицы следует воспользоваться возможностями ERwin для формирования отчетов (по команде Tasks/Generate Reports).

  Рис. 7. Пример информационной модели предметной области «Библиотека»

  

  Спецификации атрибутов сущностей

  Имя сущности

  Имя атрибута

  Описание атрибута

  Первичный ключ

  Внешний ключ

  Инвентарный номер книги на абонементе — компонент первичного ключа и ключ связи с сущностью «Хранимая книга»

  Читать:

  Как перейти к полярным координатам