Способы моделирования предметной области

Методологии моделирования предметной области

Структурная модель предметной области

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

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

К моделям предметных областей предъявляются следующие требования:

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

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

Структурный аспект предполагает построение:

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

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

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

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

Главный критерий адекватности структурной модели предметной области заключается в функциональной полноте разрабатываемой ИС.

Оценочные аспекты моделирования предметной области связаны с разрабатываемыми показателями эффективности автоматизируемых процессов, к которым относятся:

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

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

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

Объектная структура

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

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

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

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

Источник

Особенности моделирования предметной области с помощью ООП

Введение

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

Адепту ООП очень трудно понять, что термин экземпляр класса в русском языке указывает на класс объектов, а не на созвучный этому термину элемент класса – объект класса. Для многих, кто изучал ООП, термины экземпляр и элемент – неразличимы. Давайте разберемся с этими терминами внимательно.

Определения терминов

Термин экземпляр

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

Следуя логике, экземпляр класса – это объект из ряда себе подобных классов. Таким образом, в русском языке термин экземпляр класса указывает нам на класс.

Машина относится с классом машин так: машина есть объект класса машин.

Поэтому, если сказать, как это принято в ООП, что машина – есть экземпляр класса машин, то получится, что машина – есть класс машин. Коллизия!

В ООП под термином класс понимается термин тип. Поэтому термин экземпляр класса в ООП надо читать так: экземпляр типа объектов. Тогда наша картинка будет выглядеть так:

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

Термин элемент

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

или связью классификация (элемент класса колес – колесо).

Другие пары некорректных терминов:

Кроме того, в бизнес-анализе сейчас распространены другие некорректные пары терминов: событие и экземпляр этого события, процесс и экземпляр этого процесса, договор и экземпляр этого договора. В русском языке нет такого понятия как объект и экземпляр этого объекта. Есть термины тип объекта и экземпляр этого типа объекта.

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

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

• Экземпляр электрона — это электрон, экземпляр частицы типа электрон, или экземпляр данного типа электронов (но не экземпляр этого электрона).
• Экземпляр процесса – это процесс, экземпляр объекта типа процесс, или экземпляр данного типа процессов (но не экземпляр этого процесса).
• Экземпляр события — есть событие, экземпляр объекта типа событие, или экземпляр данного типа событий (но не экземпляр этого события).
• Экземпляр класса – это класс, экземпляр объекта типа класс, или экземпляр данного типа классов (Но не экземпляр этого класса)

Данные высказывания сделаны в парадигме Аристотеля, где есть типы объектов и экземпляры этих типов, но не объекты и экземпляры этих объектов. О парадигме Аристотеля я писал в статье: Знакомство с парадигмами построения моделей предметной области.

Аналогия с наукой

Надо заметить один очень интересный факт. Напрашивается аналогия между религией и наукой. Научный подход возник к противовес религиозному описанию мира. Если Вы описываете мир с точки зрения религии, то надо понимать, что наличие Бога проверить нельзя. В основу веры кладется вера. Научный подход, в противовес вере ставит главенство эксперимента. То есть, если эксперимент подтверждает существование Рая, то Рай существует. Если не подтверждает, то – неизвестно, существует он или нет. Термины, употребляемые в одном концепте не смешиваются с терминами, употребляемыми в другом. Например, можно слышать иногда тезис о том, что кто-то доказал существования Бога. Но как только кто-то это докажет, Бог перестанет быть Богом и станет очередным концептом. Поэтому доказать существование Бога невозможно и потому в религии невозможно ввести термин доказательство. Также как в религии неуместно говорить о доказательствах, в науке бессмысленно говорить о вере, кроме как в разрезе: мне эта вера помогает мыслить, но как только она станет мешать, я ее поменяю.
Точно также в онтологии существует два подхода: один придумал Аристотель. Это теория типов. Второй был придуман в противовес Аристотелевским типам. Этот подход называется логическая парадигма и использует термин класс. Эти две парадигмы несмешиваемы, как наука и религия. Поэтому в теории типов нельзя употреблять термин класс, а в теории классов нельзя употреблять термин тип. Однако, ООП нарушило этот запрет. За это ему надо сказать фу.

В своих изложениях я опираюсь на логическую парадигму, в которой есть объект и есть множество объектов, называемое классом объектов, но нет терминов экземпляр, тип и термина класс в смысле ООП. Для знакомства с логической парадигмой я могу посоветовать почитать книги Chris Partridgе Business Objects: Re-Engineering for Re-Use, Matthew West Developing High Quality Data Models.

Основа логической парадигмы: связи классификация и специализация

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

В ООП нет такой связи, и вы не сможете указать ее на диаграмме UML.

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

В ООП такая связь между классами называется наследование. Говорится, что Класс 2 наследуется от Класса 1.

Но в природе Класс 2 есть подмножество Класса 1. Видимо, имеется ввиду, что наследуются признаки, или параметры. Но параметры есть только в описании типа! И опять мы упираемся в смешение терминов. Классы не могут ничего наследовать. А вот типы – могут.

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

Деление на классы и объекты классов позволяет мне рассматривать любые объекты исследуемого класса, например, класса слонов (изучать продолжительность жизни любого из слонов, длину его бивней на различных этапах его жизни), а также — класс слонов (изучать среднюю длительность жизни слонов, средний рост и средний вес). Понятно, что любой слон класса не может «знать» информацию о средней длительности жизни всех слонов. Эту информацию «знает» только класс слонов. Попробуйте в парадигме Аристотеля придумать тот объект, который «знает» о среднем росте слонов, не используя при этом термин множество! Навряд ли у вас это получится. Поэтому, если вы аналитик, то вам придется работать с объектами и классами объектов (но классами не смысле ООП).

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

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

Пример: пусть у нас есть три яблони <1;2;3>. Это класс. ООП требует наличие у объектов этого класса общих признаков. Пусть это будет признак «наличие яблок». Создадим класс, состоящий из всех подклассов класса этих яблонь. Этот класс состоит из классов: <<пусто>;<1>;<2>;<3>;<1;2>;<1;3>;<2;3>;<1;2;3>>.

То есть в этом классе классов 8 элементов. Попробуйте, если вы следуете определению класса ООП, дать дифференцированное описание этих классов (другое бессмысленно). И это цветочки – всего три элемента в классе. А если их 1000, а если счетное множество, а если континуум? Поэтому в ООП нет даже простейших операций над классами (сложение и вычитание множеств).

Источник