Для чего нужно моделирование предметной области
Как запутать аналитика. Часть вторая: что такое моделирование предметной области?
В прошлой статье я говорил о заблуждениях, к которым склонны программисты и обещал рассказать про заблуждения, к которым склонны не только программисты, но и каждый из нас.
Объект учета и результат его классификации (существительные)
Проведем мысленный эксперимент. Представьте себе два хранилища моделей. В одном хранилище созданы классы для хранения моделей плавательных средств, в другом – классы для хранения моделей автомобилей. Допустим, что есть объект, который в одном хранилище описан как объект класса плавсредство, а во второй – как объект класса автомобиль. Допустим, что стоит задача объединения этих хранилищ в одно. Как вы это сделаете?
Возможно, вы создадите подкласс автомобилей, который одновременно является подклассом класса плавсредств, добавите модель в созданный вами подкласс и удалите, теперь ставшие лишними, модель из класса автомобилей и модель из класса плавсредств. Возможно, вы удалите объект из класса плавсредств, а объект из класса автомобилей одновременно сделаете объектом класса плавсредств.
Как бы вы не поступили, у меня вопрос: как теперь вы назовете моделируемый объект? Автомобиль-плавсредство? А, если потом появятся другие классы, к которым относится этот объект? Будете перечислять их названия через дефис, и говорить: автомобиль-плавсредство-альфа-омега? Если задать этот вопрос аналитику, то ответом будет: это один и тот же объект, одновременно являющийся и автомобилем и плавсредством. Буквально это значит, что есть объект учета, который может быть одновременно классифицирован и как автомобиль, и как плавсредство. Из этого следует, что мы моделируем не автомобили и плавсредства, а объекты учета!
ООП наследовал результат этой путаницы, и в нем невозможно разделить операцию по созданию модели объекта от классификации. Поэтому аналитики часто думают, что моделирование предметной области заключается в моделировании машин и плавсредств, а не объектов учета.
В этом смысле стандарт OWL более корректен, потому что в нем можно создать неклассифицированную модель объекта учета. Это позволяет отделить операцию по моделированию объекта учета от операции по его классификации.
Объект учета и результат его классификации (прилагательные)
Когда мы говорим, что машина красная, мы предполагаем, что машина может обладать свойством – быть черной, красной и тд. Но могут ли на самом деле машины иметь свойства?
Продолжим наш мысленный эксперимент. Пусть в двух хранилищах, которые мы рассматривали ранее, есть одноименные атрибуты: у автомобилей — атрибут цвет, и у плавсредств — атрибут цвет. Пусть есть объект, который мы описали как красный автомобиль в одном хранилище, и как красное плавсредство – в другом. Пусть снова стоит задача объединения этих хранилищ в одно. Как вы поступите?
Ранее для моделирования объекта вы создали подкласс автомобилей и плавсредств. Теперь стоит задача моделирования одного цвета вместо двух. Для решения этой задачи вы можете поступить разными способами.
Возможно вы создадите один надкласс для класса автомобилей и класса плавсредств, у которого создадите атрибут цвет. У классов автомобилей и плавсредств вы создадите наследуемые от надкласса атрибуты «цвет». Затем переделаете все объекты, чтобы они соответствовали новому видению.
Возможно, вы определите интерфейс «цвет» и выполните реализацию этого интерфейса в каждом классе.
Что бы вы ни сделали, важно понять, что полученный атрибут «цвет» не будет принадлежать ни автомобилям ни плавсредствам. Это нечто, что существует вне этих классов. И это правильно, поскольку атрибут не связан с типом. Атрибут – это способ деления множества объектов на подмножества другим способом, отличным от типа. Об этом я писал ранее в статье Понятия: множество, тип, атрибут.
.
Поэтому, если быть строгим, нельзя говорить о свойстве, принадлежащем объекту, надо говорить о свойстве независимо от типа, или объекта, например, так:
Объект учета отнесен к классу красных объектов, то есть классифицирован.
Хот я утверждения такого рода являются корректными, на деле говорить подобным образом слишком затратно. Причина в языке. Когда мы передаем информацию другому субъекту, мы стремимся сократить объем выполняемой работы. Сравните высказывания:
ООП унаследовал и это заблуждение. С помощью ООП невозможно создать атрибут отдельно от класса (правда для этого можно использовать интерфейсы). И снова OWL нам в помощь: в этом стандарте типы и атрибуты существуют отдельно друг от друга. Поэтому при слиянии двух моделей в OWL нам не придется делать столько работы, сколько пришлось бы делать в ООП. Для слияния надо только объявить два атрибута тождественно равными и более ничего.
Смысл процесса классификации
Пусть есть два хранилища моделей. В одном хранилище хранятся модели операций по продаже инструментов. В другом хранилище хранятся модели операций по покупке инструментов. Пусть есть одна операция, классифицированная в одном хранилище как операция по продаже, исполнителем которой был Мартынов, а в другом хранилище она же классифицирована как операция по покупке, исполнителем которой был Гаврилов. В процессе объединения двух хранилищ стоит задача объединения этих моделей в одну. Вопрос: как в объединенном хранилище представить модель этой операции?
На скорую руку приходит решение о создании новой модели, которая будет моделировать операцию под названием «купля-продажа», исполнителем которой будут Мартынов и Гаврилов. Но тут возникает вопрос: куда делась операция по продаже, исполнителем которой был Мартынов, и куда делась операция по покупке, исполнителем которой был Гаврилов? В новой модели эта информация оказалась потерянной, да еще и возникла коллизия, ведь операция – это такое действие, которое должно иметь цель. У продажи цель есть – продать подороже, и ради нее работал Мартынов. У покупки есть цель – купить подешевле, и ради нее работал Гаврилов. А у купли-продажи нет цели, потому что у нее нет стейкхолдера. Как же сохранить информацию, которая была в хранилищах до их объединения, избежать коллизии и, в то же время, объединить модели операций?
Для этого нам надо поступить так же, как мы поступили с автомобилями. Надо создать модель объекта учета и отнести его к двум разным классам одновременно: к классу операций по продаже и к классу операций по покупке. В разных классах будет один атрибут «исполнитель», значения которого будут зависеть от того, какой класс мы рассматриваем: класс покупок, или класс продаж. И это неожиданно – оказывается, что значения атрибутов одного объекта учета могут зависеть от того, как мы классифицировали объект учета.
Это кажется странным, но здесь нет ничего удивительного. Разные люди могут классифицировать один и тот же объект по-разному. Кто-то считает, что это – машина, а кто-то считает, что это – плавсредство. Для кого-то это — операция по продаже, а для кого-то – операция по покупке. Теперь проясняется смысл классификации. Классификация объекта учета – это выражение определенной точки зрения на объект учета. Нет автомобилей, но есть объект учета и субъект, трактующий этот объект учета как автомобиль. Нет операции по продаже, есть субъект, который трактует объект учета как операцию по продаже.
Тот же смысл имеют значения атрибутов. Есть объект учета и субъект, трактующий этот объект учета как принадлежащий определенному классу значений атрибута.
Поэтому тезисы про автомобиль и плавсредство надо уточнить:
О том, как при помощи OWL можно построить хранилище, в котором будут учтены разнообразные точки зрения, рассказано в статье: Multi-viewpoint Ontologies for Decision-Making Support.
Моделирование предметной области
Организация информации
Структурирование информации
Информационное пространство экономических объектов
Под информационным пространством некоторого объекта понимается совокупность всех информационных компонентов этого объекта или множества объектов независимо от способов и средств отображения этих компонентов.
Под структурированностью понимается такое свойство информационного пространства, при котором все содержание и особенности этого пространства представляются его компонентами и взаимосвязями между ними, выраженными в явном виде.
В зависимости от степени структурированности информационного пространства выделяется следующих пять его видов.
Неструктурированное пространство – это то, для которого характерно, что структурированность его компонентов информации встречается редко.
Примером неструктурированного информационного пространства является разговорная речь, хотя некоторые элементы структурированности в ней могут присутствовать.
Слабо структурированное информационное пространство то, в котором полностью структурированы только отдельные компоненты.
Примером может служить письменный язык, в котором выполняются правила синтаксиса.
Структурированное информационное пространство характеризуется существенным преобладанием структурированных компонентов, информация в нем документирована, широко используется кодирование для обеспечения однозначной трактовки тех или иных понятий. Примером может служить экономическая информационная система.
Формализованно структурированное информационное пространство – это пространство, где в явном виде существуют описания информационных образований, в которых определены не только информационные структуры и связи, но и алгоритмы получения значений любого элемента данных. Примером может служить автоматизированная информационная система.
Машинноструктурированное информационное пространство – это то, в котором описаны все информационные образования, в том числе формы входных и выходных документов. Типичным примером может служить база данных.
Моделирование предметной области
Любое предприятие или организация представляет собой совокупность различного рода ресурсов связанных между собой процессами. Ресурсами могут быть: рабочие и служащие, сырье и материалы, оборудование, электроэнергия и т.д. Процесс – это последовательность действий необходимая для преобразования одного вида ресурса в другой. На процесс накладывается технология выполнения этого процесса. Технология в данном случае – это совокупность методов и способов выполнения этого процесса. В зависимости от используемой технологии конечный ресурс может обладать разными свойствами, т.е. быть разного качества.
С целью получения единого представления о взаимодействии ресурсов и процессов, их можно описать в терминах предметной области.
Предметной областью может быть область объектов, универсум рассуждения, универсум рассмотрения, или просто универсум, класс (множество) объектов, рассматриваемых в пределах данного контекста. Под контекстом здесь может пониматься отдельное рассуждение или выражающая его фраза, или совокупность фраз, фрагмент научной теории или теория в целом. Если мы говорим о работе автоматизированной системы управления предприятием, то предметной областью будет все это предприятие. Если мы говорим об автоматизации отдельной задачи, решаемой на этом предприятии, то предметной областью будет вся необходимая для решения этой задачи совокупность объектов, описывающих их свойств, взаимосвязей между этими объектами и процессов, в которых они участвуют.
Предметной областью называется множество взаимосвязанных объектов, свойства которых и отношения между которыми рассматриваются в пределах данного контекста.
Объект – это сущность, которая четко проявляет свое поведение. Объектом может быть нечто материальное, например, предмет, который можно потрогать. Объектом может быть и не материальное, например, явление, понятие или совокупность сведений, если это явление или понятие проявляет свое поведение и это поведение можно описать достаточным количеством свойств.
Для каждой предметной области свойства объекта или его поведения могут рассматриваться разные. Например, человек в Университете Управления (т.е. в месте своей деловой активности) может быть студентом, преподавателем или сотрудником. Если он студент, то для его описания потребуются такие свойства, как: институт, курс, группа, ФИО, номер студенческого билета, количество задолженностей и т.д. Если этот же человек, едет в метро, то количество его задолженностей не имеет значения. Для этой предметной области существенно: сколько ему лет, хорошо ли он воспитан, не имеет ли он увечий и входит ли в круг присущих ему свойств – уступать место инвалидам, лицам с детьми и пожилым людям.
Объекты объединяются по присущим им общим свойствам во множества, называемые типами объектов, которые для каждой предметной области могут быть свои, но могут быть и общими типами. Например, для ГУУ типами объектов являются студенты, преподаватели, сотрудники, аудитории, читаемые дисциплины, проводимые контрольные мероприятия и т.д. Тип объекта охватывает множество экземпляров объектов. Экземпляр объекта – это каждый отдельный объект, который обладает своим уникальным (только ему присущим) свойством. Если рассматривать тип объекта «студент», то ФИО студента не может быть его уникальным свойством, т.к. потенциально в этой предметной области может присутствовать другой «студент», обладающий такими же и фамилией, и именем, и отчеством и даже может с первым учиться в одной группе.
Типы объектов могут объединяться для формирования новых типов по принципу «множество, элементами которого являются другие множества».
Свойства объекта или его поведения – это характеристика объекта, которая присуща ему в определенный момент времени. Два экземпляра одного типа объекта являются различными, если они отличаются по значению хотя бы одного свойства.
Деятельность, которая развернута во времени, охватывается понятием «взаимодействие объектов». Взаимодействие объектов называется факт участия нескольких объектов в каком-либо процессе, который протекает во времени и в пространстве.
Свойством взаимодействия называется такое свойство, которое характеризует совместное поведение объектов, но не относится ни к одному из них в отдельности. Количество изделий, произведенных за определенный день, является свойством взаимодействия, но никак не характеризует объекты «рабочий», «материал», «оборудование», взятые по отдельности
Предполагается, что представление объекта или процесса сводится к указанию его свойств, существенных специфических характеристик, информационным отображением которых служат атрибуты. Вопрос о выражении сущности объектов с помощью того или иного набора свойств решается путем расширения набора свойств, описывающих объект, чем достигается более полное представление об их сущности.
Существуют две основные единицы информации — атрибут и составная единица информации (СЕИ). Атрибут описывает определенное свойство объекта и соответствует понятию «переменная» в языках программирования.
Некоторые атрибуты обладают интересным свойством. Зная значение одного из них, можно определить значения, которые принимают другие атрибуты этого же объекта. Например, по номеру студенческого билета возможно установить его имя студента, институт, курс, группу и все его задолженности. Ключевыми атрибутами, называются специфические характеристики,которые однозначно определяют (идентифицируют) конкретные экземпляры объектов.
Составной единицей информации (СЕИ) в данном случаеназывается набор из атрибутов и, возможно, других СЕИ. Множество атрибутов объединяется в одну СЕИ по следующим принципам:
· соответствующие атрибуты описывают один и тот же факт или экономический процесс;
· значения атрибутов, входящих в СЕИ, возникают одновременно, связаны логическими или арифметическими соотношениями. Значения атрибутов и называют данными.
Компьютерная организация информации выглядит следующим образом: данные выстраиваются иерархически от битов к байтам, далее переходя к полям, записям, файлам, базам данных и информационным хранилищам.
Бит – это один двоичный разряд.
Байт – это восемь двоичных разрядов.
Поле – это определенное свойство (или атрибут) объекта, которое присуще множеству однотипных объектов.
Запись – это все необходимое множество свойств (атрибутов, полей), которые описывают один конкретный объект.
Файл – поименованная совокупность связанных однотипных записей, хранящихся во внешней памяти компьютера и рассматриваемых как единое целое. Обычно файл однозначно идентифицируется указанием имени файла, его расширения и пути доступа к файлу. Каждый файл состоит из атрибутов и значений атрибутов. Различают текстовые, графические и звуковые файлы.
Файлы могут храниться в виде отдельных единиц, могут быть объединены в папки (директории) или в базы данных.
Для решения каждой конкретной задачи при автоматизированной обработке информации простейший подход состоит в разработке одной или нескольких специальных прикладных программ (ПП) и использование одного или нескольких файлов. Но для каждого из них в программу необходимо включить такие операции, как добавление, удаление, замена, поиск записей. Кроме этого, некоторые элементы (имя, номер, адрес) неизбежно используются несколькими программами, а значит, и хранятся в нескольких файлах. Это делает проблематичным обеспечение “непротиворечивости” данных, так как обновление (актуализацию) необходимо проводить одновременно в нескольких файлах. Между атрибутами существует некоторая взаимосвязь, например, между ФИО студента и количеством сданных им экзаменов. Однако когда файлы реализованы в виде отдельных единиц, установить связь между элементами затруднительно или вообще невозможно. Существует также ограничение по доступности. Информация должна подаваться пользователю быстро, а если она разбросана по разным файлам, доступность ее ограничена. Из-за избыточности данных в файлах трудно реализовать изменения в предметной области, которые возникают достаточно часто.
Для решения всех этих проблем разработаны обобщенные «методы доступа». Обобщенные “методы доступа”, обеспечивающиеся универсальными программами, освобождают программиста от кодирования, тестирования и отладки стандартных блоков. Универсальные программы доступа, называемые системами управления базами данных (СУБД) гарантируют также определенную степень независимости данных от их физического хранения.
Только с появлением языков программирования, позволяющих создавать типизированные файлы, стало возможным существенно продвинуться в развитии технологий баз данных. Типизированные файлы позволили разработчикам создать комплексы взаимосвязанных данных, увеличить скорость обработки хранящихся данных, создавать разветвленные структуры данных, которые при некоторой обработке превращались в информацию. Таким образом, возникла необходимость в моделировании данных и дальнейшем представлении их с помощью изученных технологий организации данных в компьютере.
Для того чтобы пользователь мог работать с базой денных ему нужны два компонента:
Классификацию систем управления базами данных смотри на рис. 55.
Такое разделение СУБД на классы не случайно, поскольку в зависимости от пользователей, пользующихся СУБД, и предметной областью, для которой СУБД используется, выделяются разные средства.
Пользовательские СУБД отличаются от остальных СУБД такой особенность, что могут быть использованы непрофессиональными пользователями, которые хотят учитывать большие объемы информации в базах данных. В этих СУБД имеется достаточно хорошо развитый механизм обработки простейших баз данных со стандартным набором команд и пользователю практически нет необходимости серьезно изучать методы обработки данных в базах данных.
Рис. 55. Классификация СУБД
СУБД среднего уровня отличаются сложностью в работе, когда с ней могут работать, как правило, профессиональные пользователи и разработчики баз данных, но объемы информации достаточно невелики, что нет необходимости использовать сложные СУБД. Данный класс СУБД обладает большим набором возможностей по проектированию и моделированию баз данных по сравнению с пользовательскими СУБД. К разработчикам предъявляются достаточно серьезные требования по знанию программирования и теории проектирования и моделирования баз данных.
СУБД сложных систем, как правило, применяются при проектировании информационных систем на уровне больших предприятий, корпораций, муниципальном и государственном уровнях. Естественно, что, применяя их на таких уровнях, необходимо обрабатывать достаточно быстро очень большие объемы информации. В этих СУБД заложены передовые технологии по поиску и хранению информации в базах данных, имеются развитые технологии организации хранилищ данных и использования OLAP и OLTP технологий.
СУБД для языков программирования не используется, как самостоятельный программный продукт, а является модулем для современных языков программирования. В них заложен минимальный набор функциональных возможностей по обработке баз данных. Вся остальная обработка информации в базах данных осуществляется на основании приложения, которое использует конечный пользователь.
Особенности моделирования предметной области с помощью ООП
Введение
Хочу заметить, что тем, кто пользуется терминами ООП, будет очень трудно понять меня. Дело в том, что ООП подменил понятия. В ООП под классом понимается не множество, как обычно принято в математике, или лингвистике. В ООП классом называют тип объектов, как у Аристотеля. Было бы правильно в ООП вместо термина класс объектов использовать термин тип объекта. Однажды, съехав с правильной терминологии, вернуться в лоно правильных терминов оказывается очень трудно. В данной статье я попробую помочь тем, кто желает разобраться с терминологической кашей, заваренной ООП. В своих рассуждениях я буду использовать термины в их первоначальном смысле, а не в смысле ООП. Термин класс будет взят из логической парадигмы моделирования предметных областей, которая, в свою очередь, заимствовала этот термин из теории множеств. Термины тип и экземпляр будет взят из теории типов, построенной на парадигме Аристотеля о существовании типов.
Адепту ООП очень трудно понять, что термин экземпляр класса в русском языке указывает на класс объектов, а не на созвучный этому термину элемент класса – объект класса. Для многих, кто изучал ООП, термины экземпляр и элемент – неразличимы. Давайте разберемся с этими терминами внимательно.
Определения терминов
Термин экземпляр
Экземпляр – это объект из ряда себе подобных. То есть, экземпляр машины – это объект из ряда себе подобных машин. Аристотель считал, что у субъекта есть идея существования машин. Эта идея выражена в виде абстрактного типа объектов (машин), существующего в сознании у субъектов. Когда субъект смотрит на объект, он сравнивает то, что он видит, с тем образом, который есть у него в воображении (с типом машин), и, если находит схожие черты, то объект называет машиной, или экземпляром машины. Перечень схожих черт Аристотель назвал типом. А объект, обладающий этими чертами, — экземпляром данного типа.
Следуя логике, экземпляр класса – это объект из ряда себе подобных классов. Таким образом, в русском языке термин экземпляр класса указывает нам на класс.
Машина относится с классом машин так: машина есть объект класса машин.
Поэтому, если сказать, как это принято в ООП, что машина – есть экземпляр класса машин, то получится, что машина – есть класс машин. Коллизия!
В ООП под термином класс понимается термин тип. Поэтому термин экземпляр класса в ООП надо читать так: экземпляр типа объектов. Тогда наша картинка будет выглядеть так:
Поэтому, если Вы встречаете термин экземпляр класса, то знайте, что скорее всего, этот термин порожден ООП и значит он тип объекта. Вне ООП класс значит множество объектов.
Термин элемент
Элемент – это часть чего-то. Элемент платы – это резистор, элемент ноги – это колено, элемент множества – это объект. Таким образом, термин элемент может обозначать связь между двумя сущностями. Эта связь может быть связью композиция (элемент машины – колесо),
или связью классификация (элемент класса колес – колесо).
Другие пары некорректных терминов:
Кроме того, в бизнес-анализе сейчас распространены другие некорректные пары терминов: событие и экземпляр этого события, процесс и экземпляр этого процесса, договор и экземпляр этого договора. В русском языке нет такого понятия как объект и экземпляр этого объекта. Есть термины тип объекта и экземпляр этого типа объекта.
Возможно, ошибочное употребление терминов возникло из-за неверного перевода термина 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, а если счетное множество, а если континуум? Поэтому в ООП нет даже простейших операций над классами (сложение и вычитание множеств).