объект, состояние, событие, бизнес-операция и бизнес- функция / Хабр

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

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

1. ООП перепутало классы и типы. То, что называется типами у Аристотеля, в ООП назвали классами, а то, что математики называют классами, в ООП не имеет названия.
2. В ООП есть термин наследование. Это инструмент моделирования иерархии тип-подтип. Это значит, что ООП построено на логике Аристотеля. Ограничения этой логики в применении к моделированию предметных областей известны и описаны в книге Business Objects: Re-Engineering for Re-Use, которую я упомянул в прошлой статье. В качестве примера такого ограничения можно представить себе моделирование высоты у объектов класса слон и объектов класса вагон. Эти два атрибута в ООП никак не связаны между собой, поэтому понять, что слон поместится в вагон можно только, обратившись к программисту, создавшему эти атрибуты. Можно было бы ввести специализированные атрибуты, например, высота помещения как специализированный атрибут высота объектов, но и этого также сделать невозможно.
3. В ООП методы принадлежат объектам класса.
   Возникает вопрос — кто везет машину: колеса или двигатель? Корректным был бы другой вопрос: кто или что является участником операции? Метод необходимо отделить от класса, а трактовку степени участия нужно оставить читателю модели. Но даже, если в ИС смоделировать трактовку такого участия, она никак не повлияет на анализ данных, поскольку на практике нас совершенно не интересует кто и что делал, но интересует, кто, когда и где был занят и что произошло с ним, а это как раз и есть ответ на первый вопрос.

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

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

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

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

Про операцию можно сказать, во сколько она началась и во сколько она закончилась. Это – описание границ объекта во времени. Точно также можно обозначить временные границы не только операции, но и любого объекта. Например, болт существует с 1-го сентября 2016 года по 23 ноября 2017 года, когда он был переплавлен.
Для описания границ болта мы используем термины: в пространстве: где находится? Во времени: когда существует? Для описания границ операции мы используем термины: в пространстве: где произошло? Во времени: когда произошло? Нам непривычно было бы спросить про болт: произошел когда? А про операцию: существует где? Проблема в языке. Один и тот же вопрос для разных типов объектов учета формулируется по-разному. Это еще одна причина, по которой нам сложно представить себе операцию как 4-х мерный объект.

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

Для описания объекта строятся границы, которые ограничивают моделируемый объект. Если не загоняться на тему математических извратов, то границей 4-х мерного объекта будет 3-х мерный объект. Знать эту 3-х мерного границу хочется максимально точно. Например, если сказать, что молоток (4-х мерный объект) находится на складе с 1-го декабря 2016 года по 1-го марта 2017, — это будет плохая модель молотка. Хочется знать про молоток немного больше. Например, можно задать точные координаты куба, в котором он находится. Точные границы куба могли бы выглядеть так: по оси X: с 10 до 20 см, по оси Y: с 30 до 35 см, по оси Z: с 120 по 135 см, по оси времени с 1-го декабря 2016 года по 1-го марта 2017 года. Теперь возьмем 4-х мерный объект, трактуемый как операция. Описание этого 4-х мерного объекта выглядит также, как и описание 4-х мерного объекта, трактуемого как молоток. Для этого 3-граница описывается при помощи места, где происходит происшествие, времени начала и времени завершения операции.

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

Предположим, что мы изучаем молоток и движемся по его ручке. При таком движении фактура поверхности не меняется. Чтобы представить себе аналог такого движения по оси времени, надо понять, что поверхность 4-х мерного объекта при движении по оси времени описывается состояниями. Это значит, что, для проведения аналогии, необходимо, чтобы движение по оси времени не меняло состояние объекта учета.

Например, молоток лежит на столе и им никто не пользуется. Состояние молотка не меняется.

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

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

Коль скоро мы определили объект как модель 4-объема в 4-пространстве, мы можем определить, что такое тип объектов. Допустим, что есть множество моделей 4-объемов, или множество объектов. Эти модели хранятся у субъекта в сознании. Если эти модели похожи друг на друга, то субъект может создать модель этих моделей. Эта модель также хранится в сознании субъекта. Эта модель моделей и есть тип объектов. Модель моделей – это второй уровень абстракции. Первым уровнем абстракции были модели 4-пространств, которые мы называем объектами.

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

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

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

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

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

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

Мы подошли к моему определению понятия бизнес-функция. Бизнес-функция – это 4-х мерный объект, который имеет описание в виде набора типов событий с указанием плотности этих событий во времени (в вырожденном случае может содержать всего один тип, например, тип событий по выпуску веников). Замечу, что это определение сильно отличается о общепринятого, в котором функция определена как преобразование входных потоков в выходные. Но здесь нет никакого противоречия. Просто обычное определение функции является частным случаем моего. Все дело в том, что каждому множеству однотипных событий (классу событий), которые моделируют функцию, можно приписать поток материальных объектов учета. И тогда каждому типу событий можно будет приписать поток объектов и направление этого потока. Однако, такое понимание функции страдает тем же, что и описание операции при помощи акторов, совершающих действие. Это – невозможность посмотреть на модель с другой точки зрения. Если в моем определении каждому типу событий аналитик может приписать свои только ему необходимые объекты учета, то в классической модели сделать это не удастся. А это, в свою очередь, не позволит построить модель с учетом требований Трейсабилити. Кроме того, моделируя типы событий, я вообще не привязан к моделированию потоков. Бывают случаи, когда описать поток объектов невозможно, потому что трудно найти объекты учета, которые приходят, или покидают функцию. Например, если моделируется функция удержания вращающегося мячика на пальце клоуна, то смоделировать поток объектов в такой функции невозможно – ничто не покидает систему «клоун-шар» и ничто туда не втекает, а функция – вот она! Правда в системе «клоун-шар» события, которые происходят, носят не дискретный характер, а непрерывный.

Для понимания, что такое непрерывный поток событий, обратимся к электромотору. С одной стороны, электромотор легко представить себе в виде объекта. Очень часто так и делается. Если не нужно моделировать движение вала электромотора, аналитик просто пишет: электромотор такой-то. Это моделирование 4-х мерного объекта в виде 3-х мерного объекта. С другой стороны, можно попытаться смоделировать вращение вала электромотора. Вал электромотора вращается равномерно. Каждое положение вала в любой момент времени – это состояние. Все подобные состояния являются однотипными. Количество таких состояний зависит от дискреты, с которой производится замер. Это может быть дискрета временная, а может – угловая. Для целей моделирования удобно взять угловую дискрету, то есть, считать однотипными такие состояния, которые совпадают с поворотом вала на определенный угол, например, один оборот. Тогда плотность таких состояний на оси времени – количество оборотов в минуту, будет говорить о скорости вращения вала. Таким образом, вращающийся шар на пальце у клоуна будет описываться угловой скоростью вращения этого шара. Плотность состояний, распределенных по оси времени, говорит нам о скорости, с которой происходят переходы из одного однотипного состояния в другое. Там, где человеческое сознание сталкивается с огромным множеством однотипных состояний, аналитик вынужден переходить от моделирования состояний к моделированию плотности состояний, а это и есть описание объекта в виде функции. В случае с вращением вала электродвигателя – это функция вращения вала.

Замечу, что 4-х мерный объект может быть одновременно смоделирован:

1. Как 3-объект – мотор.
2. Как функция вращения вала.

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

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

Морфология / Вавилон :: lingvo.info

• Фонетика, фонетические средства
  «Звуки, которые мы произносим»
• Морфология
  «Слова, как они образуются, и как они меняются»
• Синтаксис
  «Как сложить слова в предложение»
• Семантика, лексика
  «Значения, скрывающиеся за словами»

Морфология — это раздел лингвистики, анализирующий внутреннюю структуру слов и их связи со значением.

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

Каждое слово состоит как минимум из одной морфемы, а некоторые могут состоять из гораздо большего числа. Например, слово plimalboniĝintus на эсперанто (глагол, значащий ‘могло бы быть и хуже’) состоит из шести морфем.

• pli-

  еще

• mal-

  противоположный

• bon-

  хорошо

• iĝ-

  становиться

• int-

  Причастие — прошедшее время, действительный залог

• -us

  условное причастие

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

Морфемы могут быть как свободными (несвязанными), в этом случае они выступают в виде самостоятельного словам, например, как в английском слове cat или польском kot, либо они могут быть связанными,это значит, что они должны появляться только как часть слова или вместе с другим элементом. В английском и польском языках окончания множественного числа -s и -y являются связанными.

• cat

  kot

• cat-s

  kot-y

В разных языках свободные и связанные морфемы различны. Испанское слово gato (кот) состоит из двух связанных морфем gat- и -o, последняя несет значение существительного мужского рода. Если заменить окончание на -a, то получится сущ. женского рода — кошка:

• gat-o

  (самец) cat

• gat-a

  (самка) cat

На эсперанто кот — это kato, которое состоит из двух морфем, корня kat- и -o которое является окончанием всех обычных существительных.

Часто у морфем бывает несколько форм. Разные фонетические версии морфемы называются алломорфами. По-венгерски кот это macska. Перед окончанием множественного числа -k может добавляться изменение последней гласной, таким образом macska и macská- являются алломорфами одной морфемы: macska + k = macskák.

Типы слов

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

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

Имена включают в себя:

• обычные существительные: название предметов и вещей, как класса: собака, дом, дружба
• имена собственные: имена конкретных людей, животных или мест Джон, Спот, Берлин
• личные местоимения: указывают на людей, не называя их по имени, как адресат сообщения я, получатель, ты, или тему они .
• указательные местоимения (демонстративы): указывают на то, как близко (этот) или далеко расположен объект (тот).

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

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

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

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

taberu = есть (в значении кушать, настоящее время)

tabeta = ел

akai = это красное

akakatta = было красным

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

Словоизменение

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

	единственное число	множественное число
иминительный падеж	nomo	nomoj
винительный падеж	nomon	nomojn

Носители языка не думают в категориях парадигмы (чем часто удивляют не носителей). Но парадигмы являются полезным инструментов в описании языка и его изучении. Удобным способом для обозначения всех парадигматических форм слова является лексема . Четыре слова в парадигме на эсперанто принадлежат к одной лексеме nomo.

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

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

aus- + sprechen = aussprechen

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

Удобно анализировать слово сквозь призму корней и основ. Корень является частью слова, несущей основное лексическое значение, как правило, он присутствует во всех словах. Основу составляют корень плюс деривационные аффиксы, к которым могут добавляться словоизменительные/флективные аффиксы. Например, английское слово alphabet (алфавит) одновременно является корнем и основой. Слово alphabetize (располагать в алфавитном порядке) является однокоренным, но основа в нем — alphabetize, с добавленным деривационным суффиксом -ize, который превращает существительное в глагол.

Такие словоизменительные аффиксы, как -d для прошедшего времени или -ing для причастия настоящего времени, добавлются к основе и получаются формы alphabetized и alphabetizing.

Также в польском слово przeczytam (прочитаю) можно разобрать по составу на корень czyta- (чита-), к которому добавляется деривационный префикс(приставка) prze- (про) и образуется основа przeczyta- (прочита-). Наконец добавляется словоизменительное окончание -m (для обозначения первого лица единственного числа).

Префиксы(приставки) и суффиксы представляют собой примеры линейного словообразования (где морфемы добавляются в линейном порядке). В нелинейном словообразовании новая морфема начинается до того, как закончится первая.

{B}Циркумфикс{/б} состоит из двух частей, которые ставятся в начале и конце другой морфемы. В немецком многие причастия прошедшего времени образуются при помощи циркумфикса ge- -t, как gesagt (сказал):

sag- + ge- -t = gesagt

Инфикс ставится внутри другой морфемы, или внутри корня слова. В тагальском языке (тагалог), являющимся языком лингвой-франка и государственным языком Филиппин, корень sulat значит писать. Инфикс -um- трансформирует его глагол, который фокусирует внимание на субъекте. Таким образом sumulat означает (кто-то) пишет.

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

Одним из наиболее сложных способов словообразования является трансфикс (диффикс) который как бы накладывает как бы трафарет на корень (разрывает корень, состоящий из согласных, путем вставки гласных). В мальтийском, некоторые прилагательные радикально меняют форму в зависимости от рода. Для этих прилагательных трафаретом для мужского рода будет CCvC (, где v = гласная, C = согласная) при этом формой женского рода будет CvCCa.

	корень	мужской	женский
белый	b j d ,	abjad	bajda
черный	s w d	iswed	sewda

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

Некоторые языки предпочитают сложение для образования новых слов, при этом другие, избирают такой метод, как модифицированные существительные во фразе с предлогом. Кофемолка (в англ. 2 слова сoffee grinder) — это сложное слово в немецком Kaffemühle (как и в русском) и венгерском kavédaraló, между тем во французском moulin à café и польском {mlynek do kawy} это существительное плюс фраза с предлогом (мельница для кофе).

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

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

неопределенная форма (инфинитив)	ir	идти, ходить
будущее время	iré	пойду
прошедшее время	voy	Я иду, хожу

Типология морфологических структур

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

• ev-

  дом

• ler-

  множественное число

• -im-

  мои

• -in

  значение родительного падежа

• =
• evlerimin

  моих домов

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

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

• Tôi đã xem phim.

  (Я прошедшее время смотреть фильм )
  Я смотрел фильм.

• Tôi đang xem phim.

  (Я настроящее время смотреть фильм)
  Я смотрю фильм.

• Tôi sẽ xem phim.

  (Я будущее время смотреть фильм)
  Я буду смотреть фильм.

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

объект — Понимание документации JSON Schema 2020-12

• Свойства
• Свойства шаблона
• Дополнительные свойства
  • Расширение закрытых схем
• Неоцененные свойства
• Требуемые свойства
• Имена свойств
• Размер

Объекты — это тип сопоставления в JSON. Они сопоставляют «ключи» со «значениями». В JSON «ключи» всегда должны быть строками. Каждая из этих пар является условно именуется «имуществом».

• Информация для конкретного языка:
• Питон
• Рубин

В Python «объекты» аналогичны типу dict . Ан однако важным отличием является то, что словари Python в качестве ключа может использовать что угодно, а в JSON все ключи должны быть строками.

Постарайтесь не запутаться в двух значениях слова «объект» здесь: Python использует слово объект для обозначения универсального базового класса для всего, тогда как в JSON он используется только для обозначения отображения из строковые ключи к значениям.

В Ruby «объекты» аналогичны типу Hash . Важно разница, однако, в том, что все ключи в JSON должны быть строками, и поэтому любые нестроковые ключи преобразуются в их строковое представление.

Постарайтесь не запутаться в двух значениях слова «объект» здесь: Ruby использует слово Object для обозначения универсального базового класса для всего, тогда как в JSON он используется только для обозначения отображения из строковые ключи к значениям.

 { "тип": "объект" }
 

 {
   "ключ": "значение",
   "другой_ключ": "другое_значение"
}
 

 {
    «Солнце»: 1.9891e30,
    "Юпитер": 1.8986e27,
    «Сатурн»: 5.6846e26,
    «Нептун»: 10.243e25,
    «Уран»: 8. 6810e25,
    «Земля»: 5.9736e24,
    "Венера": 4.8685e24,
    «Марс»: 6.4185e23,
    «Меркурий»: 3.3022e23,
    «Луна»: 7.349e22,
    «Плутон»: 1.25e22
}
 

 {
    0,01: "см",
    1: «м»,
    1000: "км"
}
 

 "Не объект"
 

 ["An", "массив", "не", "an", "объект"]
 

Свойства (пары ключ-значение) объекта определяются с помощью свойства ключевое слово. Значением свойства является объект, где каждый ключ — это имя свойства, а каждое значение — это схема используется для проверки этого свойства. Любое свойство, которое не соответствует ни одному из имена свойств в ключевом слове properties игнорируются этим ключевое слово.

Примечание

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

Допустим, мы хотим определить простую схему для адрес, состоящий из номера, названия улицы и типа улицы:

 {
  "тип": "объект",
  "характеристики": {
    "число": { "тип": "число" },
    "название_улицы": { "тип": "строка" },
    "street_type": { "enum": ["Улица", "Авеню", "Бульвар"] }
  }
}
 

 { "номер": 1600, "street_name": "Пенсильвания", "street_type": "Авеню" }
 

 { "number": "1600", "street_name": "Пенсильвания", "street_type": "Avenue" }
 

 { "номер": 1600, "название_улицы": "Пенсильвания" }
 

 { "number": 1600, "street_name": "Пенсильвания", "street_type": "Avenue", "direction": "NW" }
 

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

Примечание

Регулярные выражения не привязаны. Это означает, что при определении регулярные выражения для patternProperties , это важно отметить, что выражение может совпадать где угодно в пределах свойства имя. Например, регулярное выражение "p" будет соответствовать любому имя свойства с p в нем, например, "яблоко" , а не просто свойство, имя которого просто "p" . Поэтому обычно меньше сбивает с толку окружение регулярного выражения в 9I_»: { «тип»: «целое число» } } }

 { "S_25": "Это строка" }
 

 { "И_0": 42}
 

 { "С_0": 42}
 

 { "I_42": "Это строка" }
 

 { "ключевое слово": "значение" }
 

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

Значение ключевого слова AdditionalProperties представляет собой схему, которая будет использоваться для проверки любых свойств в экземпляре, которые не соответствует свойствам или patternProperties . Настройка AdditionalProperties схема для false означает отсутствие дополнительных свойства будут разрешены.

Повторное использование примера из свойств, но на этот раз настройка дополнительные свойства с по false .

 {
  "тип": "объект",
  "характеристики": {
    "число": { "тип": "число" },
    "название_улицы": { "тип": "строка" },
    "street_type": { "enum": ["Улица", "Авеню", "Бульвар"] }
  },
  "дополнительные свойства": ложь
}
 

 { "number": 1600, "street_name": "Пенсильвания", "street_type": "Avenue" }
 

 { "number": 1600, "street_name": "Пенсильвания", "street_type": "Avenue", "direction": "NW" }
 

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

 {
  "тип": "объект",
  "характеристики": {
    "число": { "тип": "число" },
    "название_улицы": { "тип": "строка" },
    "street_type": { "enum": ["Улица", "Авеню", "Бульвар"] }
  },
  "дополнительные свойства": { "тип": "строка" }
}
 

 { "number": 1600, "street_name": "Пенсильвания", "street_type": "Avenue" }
 

 { "number": 1600, "street_name": "Пенсильвания", "street_type": "Avenue", "direction": "NW" }
 

 { "number": 1600, "street_name": "Пенсильвания", "street_type": "Avenue", "office_number": 201 }
 

Вы можете использовать дополнительных свойства с комбинацией свойства и свойства шаблона . В следующем примере основываясь на примере из Pattern Properties, мы добавляем 9I_»: { «тип»: «целое число» } }, «дополнительные свойства»: { «тип»: «строка» } }

 { "встроенный": 42 }
 

 { "ключевое слово": "значение" }
 

 { "ключевое слово": 42 }
 

Расширение закрытых схем

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

 {
  "все": [
    {
      "тип": "объект",
      "характеристики": {
        "street_address": { "тип": "строка" },
        "город": { "тип": "строка" },
        "состояние": { "тип": "строка" }
      },
      "обязательно": ["улица_адрес", "город", "штат"],
      "дополнительные свойства": ложь
    }
  ],
  "характеристики": {
    "тип": { "перечисление": [ "жилой", "деловой" ] }
  },
  "требуется": ["тип"]
}
 

 {
   "street_address": "1600 Пенсильвания-авеню, северо-запад",
   "город": "Вашингтон",
   "состояние": "DC",
   "тип": "бизнес"
}
 

 {
   "street_address": "1600 Пенсильвания-авеню, северо-запад",
   "город": "Вашингтон",
   "состояние": "DC"
}
 

Поскольку AdditionalProperties распознает только объявленные свойства в той же подсхеме он рассматривает все, кроме «street_address», «city» и «state» в качестве дополнительных. Объединение схемы с allOf этого не меняют. Обходной путь, который вы можете использовать, это двигаться AdditionalProperties для схемы расширения и повторного объявления свойства из расширенной схемы.

 {
  "все": [
    {
      "тип": "объект",
      "характеристики": {
        "street_address": { "тип": "строка" },
        "город": { "тип": "строка" },
        "состояние": { "тип": "строка" }
      },
      "обязательно": ["адрес_улицы", "город", "штат"]
    }
  ],
  "характеристики": {
    "улица_адрес": правда,
    "город": правда,
    "состояние": правда,
    "тип": { "перечисление": [ "жилой", "деловой" ] }
  },
  "требуется": ["тип"],
  "дополнительные свойства": ложь
}
 

 {
   "street_address": "1600 Пенсильвания-авеню, северо-запад",
   "город": "Вашингтон",
   "состояние": "DC",
   "тип": "бизнес"
}
 

 {
   "street_address": "1600 Пенсильвания-авеню, северо-запад",
   "город": "Вашингтон",
   "состояние": "DC",
   "тип": "бизнес",
   "то, что не принадлежит": "привет!"
}
 

Теперь ключевое слово AdditionalProperties может распознавать все необходимые свойства, и схема работает должным образом. Продолжайте читать, чтобы посмотрите, как unevaluatedProperties 9Ключевое слово 0034 решает эту проблему без необходимости повторного объявления свойств.

Новое в проекте 2019-09

В предыдущем разделе мы рассмотрели проблемы с использованием AdditionalProperties при «расширении» схемы с помощью Состав схемы. Ключевое слово unevaluatedProperties похоже на AdditionalProperties за исключением того, что он может распознавать свойства объявлены в подсхемах. Итак, пример из предыдущего раздела можно быть переписаны без необходимости повторного объявления свойств.

 {
  "все": [
    {
      "тип": "объект",
      "характеристики": {
        "street_address": { "тип": "строка" },
        "город": { "тип": "строка" },
        "состояние": { "тип": "строка" }
      },
      "обязательно": ["адрес_улицы", "город", "штат"]
    }
  ],
  "характеристики": {
    "тип": { "перечисление": ["жилой", "деловой"] }
  },
  "требуется": ["тип"],
  «неоцененные свойства»: ложь
}
 

 {
   "street_address": "1600 Пенсильвания-авеню, северо-запад",
   "город": "Вашингтон",
   "состояние": "DC",
   "тип": "бизнес"
}
 

 {
   "street_address": "1600 Пенсильвания-авеню, северо-запад",
   "город": "Вашингтон",
   "состояние": "DC",
   "тип": "бизнес",
   "то, что не принадлежит": "привет!"
}
 

unevaluatedProperties работает, собирая любые свойства, которые успешно проверены при обработке схем и использовании их в качестве разрешенный список свойств. Это позволяет выполнять более сложные такие вещи, как условное добавление свойств. Следующий пример разрешает свойство «отдел» только в том случае, если «тип» адреса "бизнес".

 {
  "тип": "объект",
  "характеристики": {
    "street_address": { "тип": "строка" },
    "город": { "тип": "строка" },
    «состояние»: { «тип»: «строка» },
    "тип": { "перечисление": ["жилой", "деловой"] }
  },
  "обязательно": ["улица_адрес", "город", "штат", "тип"],
  "если": {
    "тип": "объект",
    "характеристики": {
      "тип": { "константа": "бизнес" }
    },
    "требуется": ["тип"]
  },
  "тогда": {
    "характеристики": {
      "отдел": { "тип": "строка" }
    }
  },
  «неоцененные свойства»: ложь
}
 

 {
  "street_address": "1600 Пенсильвания-авеню, северо-запад",
  "город": "Вашингтон",
  "состояние": "DC",
  "тип": "бизнес",
  "отдел": "HR"
}
 

 {
  "street_address": "1600 Пенсильвания-авеню, северо-запад",
  "город": "Вашингтон",
  "состояние": "DC",
  "тип": "жилой",
  "отдел": "HR"
}
 

В этой схеме свойства, объявленные только в схеме , затем считаются «оцененными» свойствами, если «тип» адреса "бизнес".

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

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

• Информация о проекте:
• Проект 4

В черновике 4 обязательный должен содержать хотя бы одну строку.

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

 {
  "тип": "объект",
  "характеристики": {
    "имя": { "тип": "строка" },
    "электронная почта": { "тип": "строка" },
    "адрес": { "тип": "строка" },
    "телефон": { "тип": "строка" }
  },
  "обязательно": ["имя", "электронная почта"]
}
 

 {
  "name": "Уильям Шекспир",
  "email": "[электронная почта защищена]"
}
 

 {
  "name": "Уильям Шекспир",
  "email": "[электронная почта защищена]",
  "address": "Хенли-стрит, Стратфорд-на-Эйвоне, Уорикшир, Англия",
  "авторство": "под вопросом"
}
 

 {
  "name": "Уильям Шекспир",
  "address": "Хенли-стрит, Стратфорд-на-Эйвоне, Уорикшир, Англия",
}
 

 {
  "name": "Уильям Шекспир",
  "address": "Хенли-стрит, Стратфорд-на-Эйвоне, Уорикшир, Англия",
  "электронная почта": ноль
}
 

Новое в проекте 6

Имена свойств могут быть проверены по схеме, независимо от их ценности. Это может быть полезно, если вы не хотите применять определенные свойства, но вы хотите убедиться, что имена этих свойств соответствуют определенному соглашение. Например, вы можете захотеть, чтобы все имена были действительными. Токены ASCII, чтобы их можно было использовать в качестве атрибутов в конкретном программировании. язык. 9[A-Za-z_][A-Za-z0-9_]*$" } }

 {
  "_a_proper_token_001": "значение"
}
 

 {
  "001 неверный": "значение"
}
 

Поскольку ключи объекта всегда должны быть строками, подразумевается, что схема, заданная для propertyNames , всегда не менее:

 { "type": "string" }
 

Количество свойств объекта можно ограничить с помощью minProperties и maxProperties ключевых слова. Каждый из них должно быть неотрицательным целым числом.

 {
  "тип": "объект",
  "minProperties": 2,
  "максСвойства": 3
}
 

 { "а": 0}
 

 { "а": 0, "б": 1}
 

 { "а": 0, "б": 1, "в": 2}
 

 { "а": 0, "б": 1, "в": 2, "г": 3}
 

factory — создание сложных объектов из анализа файла

Эта проблема напоминает старые файлы конфигурации XML, которые использовались для связывания компонентов вместе в начале и середине 2000-х годов. Базовый подход был довольно прост:

• XML-элементы сопоставлялись с объектами (обычно с помощью какой-либо таблицы поиска или специальных атрибутов, имеющих имя класса)
• Атрибуты XML были сопоставлены со свойствами (геттеры/сеттеры) объекта

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

Главное, на что я хотел бы обратить внимание, это сохранить хорошее разделение проблем:

• Парсер: Просто используйте парсер, с которым вы знаете, как работать
• Object Mapper: Принимает результаты синтаксического анализатора и вызывает фабрику
• Фабрика: Создает экземпляры необходимых вам объектов
• Преобразователь: Если объекты необходимо соединить вместе, преобразователь находит нужный экземпляр
• Реестр: Реестр обрабатываемых объектов

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

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

Вам действительно нужен простой набор правил, чтобы это работало:

• Вам нужна только одна фабрика, если объекты могут быть созданы с помощью пустого конструктора
• Свойства (геттеры/сеттеры) должны быть общедоступными

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