Пользователь
0,0
рейтинг
2 января 2015 в 16:58

Разработка → Физические и функциональные объекты (Продолжение)

Есть три способа описания процесса:







Чем они отличаются?

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


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



Природа пространства-времени


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

Определение границ экстента


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



А несвязанный так:



Первый шаг в исследовании экстента


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

Объектом – значит назовем его объектом,



Событием – значит назовем его событием,



Операцией, — значит назовем его операцией.



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

Второй шаг в исследовании экстента


Субъективная трактовка экстента – это описание его с какой-то точки зрения. Например, экстент с какой-то точки зрения может быть молотком, а с другой – гвоздодером. Молоток и гвоздодер – это субъективные описания одного и того же экстента — железяки. Понятно, что точек зрения на экстент — множество. Поэтому у одного физического объекта может быть множество трактовок.

Трактовки можно объединять, вычитать, находить пересечения. Например, если у события есть две трактовки: одна — победа и другая — поражение, то существует объединение этих трактовок: победа и поражение.



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

Синтез и анализ


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

События


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

Функциональные события


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



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



Из этой диаграммы видно, что состояние и операция — объекты одной природы, потому что и то и другое описывается двумя событиями: началом состояния (операции) и завершением состояния (операции).
Цикличность процессов
Здесь я немного забежал вперед и показал вам диаграммы процессов, которые можно назвать циклическими (состояние системы циклически проходит через состояния одних и тех же классов («потух», «горит»). Но если вы внимательно посмотрите на реальные процессы, то увидите там те же свойства. Например, операцию «Прием заявки» предваряет операция «Ожидание клиента с заявкой». Начинается она с события «Клиент обратился» и заканчивается операцией – «Ожидание приема заявки», которое, в свою очередь, заканчивается событием «Клиент обратился». Сансара, мать ее)).

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



Ночь, улица, фонарь, аптека,
Бессмысленный и тусклый свет.
Живи еще хоть четверть века — Все будет так. Исхода нет.

Умрешь — начнешь опять сначала
И повторится все, как встарь:
Ночь, ледяная рябь канала,
Аптека, улица, фонарь.


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



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



Физическое событие


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

Операции


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

Функциональные операции


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

Первый аналитик нарисовал такую схему взаимодействия:



Второй – такую:



А третий такую:



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

Физическая операция


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

Один экстент — разные объекты?


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

Пересечение экстентов


Есть мнение, что состояние или операция описывается начальным и конечным событиями. Я с этим соглашусь, но с одной оговоркой. Если под событием понимать момент времени (как принято в ИСО), то противоречие возникает при попытке определения точного момента, когда оно произошло. Например, когда точно произошло событие «Куликовская битва»? Нет такого момента. Если же мы предполагаем, что событие – это 4-Д экстент, то получается другое противоречие. Получается, что экстент операции имеет общие части с экстентом событие. И это значит, что описание в виде операции, которая имеет начало и конец, — это лишь приблизительное описание реальности. Вот тут я и соглашусь. Все наши описания – это лишь некие приблизительные модели, описывающие реальные объекты довольно упрощенно. Это упрощение позволяет нам сократить описание до приемлемого уровня детализации, требуемой с точки зрения целей моделирования. В итоге реальность и ее модель соотносятся приблизительно следующим образом:



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

Способы описания событий


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

Первый способ описания событий


Полная классификация описаний экстентов пока не дана, и потому на данном этапе можно просто поиграться. Например, события могут быть описаны при помощи граничных состояний. Есть одно состояние системы, есть второе, и оба они описаны. Событие декларируется как переход из одного состояния в другое, что изображают стрелкой на диаграмме состояний. Например, есть состояние помидор зеленый и состояние помидор красный. Переход между этими состояниями и есть событие. Мы прекрасно понимаем, что переход имеет ненулевой временной интервал. Однако, с точки зрения рассказчика ширина этого интервала несущественна. Описание события включает в себя описание двух состояний: помидор зеленый и помидор красный, а также временного интервала, в течении которого произошла смена состояний. Например, в ночь с 5-го августа на 6-е помидор поспел.
Ошибка Партриджа
Именно так и надо было Крису Партриджу в книге Business Objects: Re-Engineering for Re-Use поступить при описании события «Помидор поспел». Он же придумал некое «Сложное событие», которое отличает от простого тем, что оно якобы состоит из простых, но автор не смог это описать ясно. Вот пример из его книги, в которой он приводит диаграмму пространства- времени.



Второй способ описания событий


Другой способ описания события – это описание его как состояния. Например, событие «Розжиг начат» можно описать так: «Смотритель отдыхает».

Что мне не нравится в ИСО 15926


В ИСО 159126 под событием понимается момент времени. И трактовка момента времени следующая: это срез 4-Д пространства-времени перпендикулярно оси времени. То есть, — это вся вселенная в момент времени t. Чем это отличается от определения, данного нами? Во-первых, зачем нам вся вселенная? Мы работаем на ограниченном участке пространства. И одновременность на этом участке определяется нами визуально (на одной полянке), хронометрами (на Земном шаре) и какой-то там теорией относительностью в пределах ближнего космоса. Но, как только мы начинаем разбираться в том, что такое одновременность вообще, мы получаем коллизию и невозможность этого определения. Во-вторых, срез вселенной – это геометрическая абстракция, от которой мы всеми силами пытались избавиться. Ведь то определение, которое дал я, понятно с точки зрения здравого смысла. А то, что дает ИСО, идет не от здравого смысла, а от математической абстракции (ровно то, что и говорил Колмогоров в своем учебнике по геометрии для 6-го класса!) Если принять определение ИСО 15926, то встает вопрос: какой из моментов считать событием? Например, аналитик может поставить вопрос: «Что есть событие «клиент пришел?» Ответ может быть таким: «Это тот момент, когда его макушка пересекла плоскость дверного проема офиса» Вам нравится такое определение события? Мне – нет, потому что я сразу поинтересуюсь, «а что такое макушка?» и «что такое дверной проем?» и так далее. Поэтому ИСОшное определение события перевернутое с ног на голову. Оно включает в себя то, что нам не нужно – всю вселенную, да еще и абстракцию, с которой работать немыслимо! Мое же вполне оправдано, потому что всегда локально (ограничено рамками моделируемого пространства), и понятно.
Марк Мельник @maxstroy
карма
15,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (79)

  • 0
    И ещё раз — по 15926 при совпадении экстентов совпрадают индивиды. Функциональный объект и физичекий невозможно различить на основе только анализа их экстентов.

    Если вы вводите «функциональное событие» по аналогии с функциональным объектом — покажите, как именно оно состоит из обычных событий. Если же аналогии такой нет, то, пожалуйста, откажитесь от использования слова «функциональный», чтобы не сбивать понимание тех, кто работает в рамках ISO 15926.
    • 0
      Экстенты равны друг другу, если совпадают. Это абсолютно понятно. Далее: один экстент может трактоваться как функциональный объект, как информационный объект, как операция. Это тоже не должно вызывать нареканий, потому что в ИСО нет ограничений на экстенты, которые могут трактоваться так и не могут трактоваться иначе. То есть, любой экстент ассоциируется с любым количеством функциональных объектов, информационных объектов и операций. В моем мире события — тоже 4-Д объекты. Причину я изложил подробно в статье. Поэтому любой экстент может трактоваться как событие. Я не знаю, какие термины ввести, чтобы сказать простую вещь: что есть трактовка экстента как объекта, события, операции и есть трактовка уже объекта, событие и операции. Я принял допущение, что функциональность объекта, события и операции отражает субъективный взгляд на событие, объект и операцию. (Список объектов можно продолжать). Я не нашел других терминов в ИСО для отражения субъективной точки зрения. Именно функциональность объектов отличает разные точки зрения на один физический объект. Это и было взято за основу. Если есть другие термины, то они должны быть названы, и приведены в соответствие с терминами физический и функциональный объект.
  • +7
    До прочтения этой статьи, я думал, что неплохо было бы из программиста вырасти до аналитика. Но Вы (автор) меня поставили в затруднение.

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

    Я все это говорю не для того, что бы обидеть или как то себя обозначить. Я просто хочу сказать, что у «технарей» (инженеров, программистов и пр.) шарики в голове немного не так вертятся. У них даже не возникает мысли о том
    «Что есть событие «клиент пришел?»
    Либо на двери есть датчик, либо нет, и как следствие — нет события. Да и, к тому же, что требуется от разрабатываемой системы при возникновении этого события? Я не сталкивался с разработкой систем, логика которых основана на таких событиях, как «клиент пришел», «кассир подумал», «Солнце село». Это очень, повторяю, очень абстрактно. Инженеру нужно нечто, что можно измерить.

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

    Прошу прощения, если получилось грубовато. Но хочется больше конкретики или не бывать мне аналитиком :)
    • 0
      Спасибо огромное за комментарий! Я хочу подчеркнуть, насколько важно то, что Вы сейчас сказали. Технарям действительно не нужны философские рассуждения. Им нужны практические рецепты применения этих рассуждений. Но вот тут собака-то и порылась. Вы как собираетесь моделировать предметную область? ER-диаграммами? Диаграммами классов? И тот и другой метод проектирования дают точность в полкилометра мимо. Если Вас устраивает такая точность, то Вы вполне можете использовать существующие методы проектирования данных. Но, если вы хотите полновесного попадания в цель, то Вам придется учиться очень много и очень долго.

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

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

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

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

      Абстрактная модель даже без изменений — весьма любопытная штука.

      Ну и примеры неудачные. «Солнце село», «водитель уснул», «кассир встал» — вполне достаточные условия для того, чтобы включить освещение, принудительно активировать торможение транспортного средства или заблокировать кассовый аппарат.
      • 0
        Как программисту мои рассуждения могут показаться слишком надуманными и лишними. Вопрос, который я обсуждаю, больше нужен аналитику. Эти вопросы возникают при проведении митингов с заказчиком и попытке так сформулировать ТЗ. чтобы и вашим и нашим было понятно, о чем идет речь. Программисту дают вообще не модель предметной области, а модель реализации. Поэтому программист не видит моделей предметных областей, или точнее не должен их видеть. Но проблема в том, что аналитики вырастают из программистов. И эти аналитики начинают видеть, например, наследование в предметной области. То есть то, чего там в принципе быть не может. И вот эти аналитики, к сожалению, не делают разницы между моделированием предметной области и моделированием реализации. И тогда возникает вопрос: о чем я тут пишу? Для таких аналитиков моя статья кажется чисто философской и лишенной практического смысла
        • 0
          >> Программисту дают вообще не модель предметной области, а модель реализации. Поэтому программист не видит моделей предметных областей

          Правда? А кто же составляет «модель реализации» и на каком основании? Аналитик? А откуда он знает, как правильнее реализовывать ту или иную функциональность?

          (еще, конечно, то, что вы говорите, противоречит идеям domain-driven design чуть менее, чем полностью)
          • 0
            Модель предметной области создает бизнес-аналитик. Модель системных объектов и системных функций — системный аналитик. Иногда, и очень часто, эти роли совмещены.

            Что касается domain-driven design. Какую бы методику проектирования мы не взяли, к ней можно применить слова Крега Лармана:


            На странице 36-37 его книги написано:

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

            Есть методика, которая позволила бы сделать непосредственное моделирование предметной области в коде. ИСО 15926 для этого и создавалось. Но посмотрите на ресурсы, которые требуются для реализации этой методики (как интеллектуальные так и машинные), и поймете, что пока эта желанная цель не достигнута.
            • 0
              Вы там выше говорили про модель реализации, а теперь, внезапно, переключились на системную модель. Это одно и то же, или разные вещи?

              Приведенная вами цитата Лармана применима не к любой методике проектирования: далеко не всегда то, чем оперирует программа, имеет отношение к реальному миру. И уж тем более эта цитата не противоречит тому факту, что ваше утверждение, что программист не видит модель предметной области, противоречит DDD.

              И нет, ISO 15926 не имеет отношения к моделированию предметной области в коде, потому что ISO 15296 обсуждает именно модель данных (то, что Асафьев назвал бы формой-кристаллом), но он никак не связан с алгоритмикой и структурой кода, а, следовательно, не может предлагать решений по выражению намерений и/или семантики в языках программирования.
              • 0
                Модель реализации — это и есть модель системы. Потому что система — есть реализация. Система моделирует предметную область. Модель предметной области создает бизнес-аналитик. Модель системы — системный аналитик. Эти аналитики делают так, чтобы модель предметной области нашла свое отражение в реализации. А реализация была описана простым и понятным для программиста образом.

                Я сказал, что я согласен с Ларманом. ИМХО.

                Про ИСО я знаю мало — это лучше Левенчука почитать. Его команда делает адаптеры для информационных систем и, насколько я знаю, успешно.
                • 0
                  То есть в вашей картине мира аналитик настолько хорошо разбирается в технологиях, чтобы принимать решения по реализации? (Простейший пример такого решения — это методология и структура хранения данных)

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

                    А вот тут я не понимаю, о чем Вы. Есть предметная область. Есть информационная модель предметной области. И это разные вещи. Они могут стать одной только в том случае, когда байты станут признаваться в качестве аргумента в суде. Но до этого пока далеко.
                    • 0
                      Удачи вам в поиске таких системных аналитиков. Я таких не видел никогда (и не думаю, что когда-либо увижу). Собственно, в чем тогда отличие между функциями системного аналитика и архитектора? (и да, архитектор — это уже часть разработки, поэтому «разработчик» модель предметной области видит)

                      Я о том, что бывают системы, которые не содержат модели предметной области, поскольку для выполнения возложенных на систему задач это не нужно.
                      • 0
                        Я не знаю, в чем отличие, потому что мой интерес — модели предметной области, а не модели системы или реализации. Хотя, я знаком с ними и с принципами их разработки, но это не мое.

                        Опять не понятно. Система не содержит модель. Она есть модель.
                        • 0
                          Тогда зачем вы что-то утверждаете об области, в которой вы не разбираетесь? (Самый яркий пример такого утверждения — это то, что разработчики не имеют дела с моделью предметной области)

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

                          И да, вы противоречите себе: если программист не видит — как вы пишете — модели предметной области, то как он может разработать систему, которая — как вы пишете — является моделью предметной области?
                          • +1
                            Я говорю с чужих слов, — тех людей, которые считают себя профессионалами. Одни из них — системные аналитики, другие — архитекторы, третьи — программисты, четвертые — бизнес-аналитики. Каждый имеет что сказать про свою работу.

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

                            Программист не разрабатывает систему. Он программирует. разработкой системы занимается системный аналитик и архитектор. Если программист выполняет роль системного аналитика или архитектора, то это совмещение ролей. Но не одна роль!
                            • +2
                              Вам не кажется, что это странный подход — говорить о чужой работе с чужих слов, но едва вам зададут вопрос или укажут на не точность — сразу говорить, что вы этим не занимаетесь? А чем вы тогда занимаетесь?

                              Я тоже говорю об информационных системах, и именно к ним применимо мое определение. И именно информационные системы не являются моделью предметной области.

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

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

                                В процессе разработки появляются три артефакта: описание предметной области, описание информационной системы и код.Вы согласны с этим?
                                • 0
                                  Нет, не согласен.

                                  Что вы понимаете под «разработкой»: один из этапов проекта (например, водопадного: анализ — проектирование — разработка — внедрение — сопровождение), или же весь проект целиком (как в «контракт на разработку системы управления складской деятельностью»)?
                                  • 0
                                    Под разработкой понимается весь процесс от идеи до остановки сопровождения. Весь жизненный цикл. Понятно, что в процессе разработки появляются множество артефактов, но три перечисленные — возникают как правило. Хотя никто не говорит о том, что можно обойтись без одного из них. Даже работу кода можно симулировать. Так что ни один из артефактов не являясь обязательным, тем не менее присутствует как правило.
                                    • 0
                                      Даже в этом определении и с этими оговорками — не согласен. «Как правило» присутствуют только два артефакта: постановка задачи и результат работы. При этом первое не обязано содержать описание предметной области, а второе — код.
                                      • 0
                                        Я думаю, что мы не понимаем друг друга, потому что я априори считаю, что перед разработчиками стоит задача описания предметной области. Если не стоит такая задача, то «нет тела, нет преступления». То есть, нет смысла говорить о том, чего нет.
                                        • 0
                                          Мы с вами действительно не понимаем друг друга, потому что у вас какое-то свое (и меняющееся) понятие терминов «разработка» и «разработчик», отличающееся от принятого в индустрии.

                                          Именно поэтому я как считал, так и продолжаю считать, что то, о чем вы говорите в своих постах, к реальным задачам и проблемам имеет на редкость малое и опосредованное отношение. Вы, например, легко и непринужденно отметаете ER-диаграммы, а я считаю их (в логическом варианте) незаменимым средством описания сущностей в предметной области.
                                          • 0
                                            ER диаграммы я не отметаю, я лишь рассказываю про их ограничения. И я привожу даже не свои исследования на этот счет. Эти исследования сделал не я. Я просто их иллюстрирую своими примерами.
                                            • 0
                                              У _любой_ модели есть ограничения. Важно лишь то, чтобы эти ограничения не противоречили целям моделирования.
                                              • 0
                                                Да. Я с самого начала говорю о том, что, если Вам достаточно тех методов, которыми Вы пользуетесь, — пользуйтесь ими. Мне не достаточно ER диаграмм. Я искал другие методы проектирования и нашел их. Теперь делюсь ими с теми, у кого есть такая же потребность. Я не настаиваю на том, что всем надо переходить на эти методы. Просто рассказываю про свой опыт и свое видение.
                                                • 0
                                                  Для каких именно аналитических задач, возникающих при разработке ПО, вам недостаточно ER-диаграмм (для описания, повторюсь, сущностей), и у вас возникла потребность в использовании той системы, которую вы предлагаете? Что именно вы *проектируете* таким образом и в какой роли?
                                                  • 0
                                                    Вы хотите, чтобы я представил Вам доказательства необходимости моего подхода? Зачем Вам это? Я не пытаюсь никого ни в чем убедить. Я пытаюсь дать видение, которое у меня есть, но не стремлюсь заставить верить в него. Если Вам оно не нужно, — не пользуйтесь им.
                                                    • 0
                                                      Я хочу понять цели вашей модели.

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

                                                      Вы делаете утверждения о том, как должно и не должно быть в процессе разработки, но когда я оспариваю эти утверждения — вы никак их не обосновываете, и это тоже не добавляет мне понимания.
                                                      • 0
                                                        Цели я обозначил сразу — неудовлетворенность существующими методами моделирования предметной области и тотальное невежество. Но это мое мнение. Я не пытаюсь убедить других в том, что я прав. Я могу ошибаться. Просто исследую эту область методами мне доступными. А вот зачем Вам обязательно меня убедить в том, что я не прав — не понимаю. У Вас свое мнение, у меня — свое. Это хорошо. Я не вижу смысла Вас переубеждать. Я не вижу смысла в том, чтобы Вы меня убедили в чем-то. Давайте закроем эту тему и продолжим работать. Это ведь гораздо интереснее, чем холиварить?
                                                        • 0
                                                          Неудовлетворенность существующими методами не модет быть целью модели, потому что у вам получается модель ради модели.

                                                          Что касается невежества — то вы бы хоть указывали, в чем?

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

                                                          >> Оказалось, что существующий state of art бизнес-анализа не способен ответить на мои вопросы
                                                          Какие именно вопросы? При решении каких задач они возникли?
                                                          • 0
                                                            Чтобы проверить выкладки, не нужно знать целей проведения выкладок. Для целей обсуждения не нужно знать мои цели.

                                                            Про невежество напишу отдельную статью, когда придет время.

                                                            Если Вас не задел тот факт, что ER модель позволяет моделировать связи «Классификация» и «Специализация» предметной области двумя разными способами, да еще и не делая различия между ними, то у Вас нет вопросов, а значит и не может быть желания получить ответы. Поэтому для Вас есть два пути. Первый — это разобраться с тем, что я только что сказал и только после этого продолжить диспут. Или, если Вы хотите и дальше дискутировать, то похоже это будет на разговор глухого с немым.
                                                            • 0
                                                              >> Чтобы проверить выкладки, не нужно знать целей проведения выкладок. Для целей обсуждения не нужно знать мои цели.

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

                                                              >> Если Вас не задел тот факт, что ER модель позволяет моделировать связи «Классификация» и «Специализация» предметной области двумя разными способами, да еще и не делая различия между ними

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

                                                              (и да, переход на личности засчитан)

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

                                                                Насчет специализации и классификации. Эти доводы найдены не мной. Ограничения моделей в виде таблиц известны онтологам, и способы их разрешения тоже известны. Если Вы понимаете эти ограничения и умеете их обходить, — не значит, что этих ограничений не существует, и не значит, что о них знать не надо.
                                                                • 0
                                                                  А какое отношение «модели в виде таблиц» имеют к ER-диаграммам? Это принципиально разные представления.
                                                                  • 0
                                                                    Любую ER модель можно представить в виде набора таблиц. Причем однозначно, насколько я помню. Но тут я не силен, потому что моделирование при помощи таблиц лично мне не нравится. Все силы я направляю на моделирование в логической парадигме и только в самый последний момент, если это необходимо, реализую модель в виде таблиц.
                                                                    • 0
                                                                      >> Любую ER модель можно представить в виде набора таблиц.
                                                                      Это будет модель модели (т.е., иное представление той же информации), и ее ограничения не имеют ничего общего с ограничениями самой ER-модели.

                                                                      >> Но тут я не силен, потому что моделирование при помощи таблиц лично мне не нравится.
                                                                      Я правильно понимаю, что на самом деле у вас нет *конкретного* примера ограничений ER-диаграмм как средства построения логической модели данных, а все, на что вы опирались перед этим утверждением — это «онтологам известны ограничения моделей в виде таблиц» и «моделирование при помощи таблиц мне не нравится»?

                                                                      Если неправильно — то приведите, пожалуйста, все-таки такой пример.
                                                                      • 0
                                                                        Мои статьи посвящены почти целиком ограничениям моделирования в виде диаграмм классом, или ER моделей. Если Вас не устраивают мои примеры, то я привел книгу Криса Партриджа, в которой эти ограничения разобраны подробно.
                                                                      • 0
                                                                        Я уже отвечал на этот вопрос: меня не устраивает моделирование в виде ER диаграмм потому что они не различают связи классификация и специализация в предметной области и, кроме того, позволяют моделировать эти связи двумя разными способами. Из этого получается полный бардак в моделях. Меня это не устраивает
                                                                        • 0
                                                                          >> они не различают связи классификация и специализация в предметной области
                                                                          Я же говорю: в предметной области между *сущностями* нет связей «классификация» и «специализация». Если есть — покажите конкретный пример.

                                                                          >> ограничениям моделирования в виде диаграмм классом, или ER моделей
                                                                          Диаграмма классов и ER-модель — это две фундаментально разных модели. В ваших статьях мне пока не удалось найти ни одного явного ограничения ER-моделей.

                                                                          >> я привел книгу Криса Партриджа, в которой эти ограничения разобраны подробно.
                                                                          Вы говорите о «Business Objects: Re-Engineering for Re-Use»? Не могли бы вы назвать конкретную главу, где описаны ограничения ER-моделей?
                                                                          • 0
                                                                            «Business Objects: Re-Engineering for Re-Use»
                                                                            страница 67 CHAPTER 3 What Is the Entity Paradigm? там же про неразличение отношений, и о том, как это обходится.
                                                                            • 0
                                                                              Вы ошибаетесь. В этом разделе нет ни слова о ER-моделях. Там обсуждается некая entity paradigm, которая к современным ER-моделям имеет исключительно отдаленное отношение.

                                                                              Вот наглядный пример: одним из фундаментальных ограничений сущностной парадигмы Партридж считает то, что «In the entity paradigm, there is no hierarchy and entity types are restricted to a single level». Так вот, ER-модель *позволяет* выразить иерархию типов сущностей (лично я для этого использую термин «архетип», чтобы избежать термина «наследование», но это вопрос внутренней терминологии).

                                                                              Что же касается отношений — Партридж сам пишет, что модель, содержащая явные отношения (а не «отношения в виде атрибутов» или «отношения в виде псевдо-сущностей») не имеет проблем с выражением связей. ER-модель потому и называется entity-*relationship* (в отличие от партриджевской entity paradigm), что связи в ней выражены явно.

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

                                                                              Таким образом, вы так и не привели никаких ограничений ER-моделей, равно как и ваша ссылка на Партриджа не выдерживает критики, потому что он о них вообще не пишет (что не удивительно для книги, чья первая редакция была в 1996-ом году).
                                                                              • 0
                                                                                Мы не говорим о том, что ER модель не позволяет нам моделировать предметную область. И Крис с этим тоже не спорит. И иерархия типов решается легко. Вопрос не в этом. Вопрос в том, что эта иерархия легко может измениться, — это раз. По прихоти заказчика уже после начала эксплуатации системы. Во-вторых, эта иерархия типов может быть построена разными способами. То ли путем создания сущностей, то ли путем создания связей между сущностями, В предметной области нет разных способов существования вещей. там все однозначно. Неоднозначность реализации — болезнь самой реализации, а не предметной области. Ну и повторяю, что неразличение классификации и специализации — это тоже не сахар. Книгу стоит прочитать целиком.
                                                                              • 0
                                                                                Очень часто я слышу: мы не знали этого в самом начале и потому затраты на переделку будут вот такими! Поэтому часто проектировщики делают структуры на вырост и с запасом. Все потому что изменения неизбежны, а вектор их не всегда предсказуем. В логической парадигме появление новых знаний о проектируемом объекте, не ведет к никаким последствиям, кроме как добавлению новых классов и связей. В парадигме типов — постоянно жди неприятностей. У Криса есть график трудоемкости разработки на основе сущностей и на основе логической парадигмы в зависимости от объема кода. Посмотрите, он интересный.
                                                                                • 0
                                                                                  >> Мы не говорим о том, что ER модель не позволяет нам моделировать предметную область.
                                                                                  Ну да, вы говорите, что у нее есть непреодолимые ограничения… только пока вам так и не удалось их назвать.

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

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

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

                                                                                  >> неразличение классификации и специализации
                                                                                  Приведите, пожалуйста, пример (и ER-диаграмму) из реальной предметной области, где это видно.

                                                                                  >> мы не знали этого в самом начале и потому затраты на переделку будут вот такими!
                                                                                  И будете слышать дальше. Переделка всегда стоит трудозатрат.

                                                                                  >> Поэтому часто проектировщики делают структуры на вырост и с запасом.
                                                                                  И ошибаются. Именно потому, что изменения непредсказуемы.

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

                                                                                  >> У Криса есть график трудоемкости разработки на основе сущностей
                                                                                  >> и на основе логической парадигмы в зависимости от объема кода
                                                                                  Вы о рисунке P.5, он же повторен как 18.5? Так это, простите, график удельной сложности (т.е. сложности с поправкой на объем) в зависимости от объема проекта. Ни (а) трудоемкости, ни (б) разработки, ни (ц) кода там не упоминается. Ну и да, там говорится о «традиционном сущностном моделировании», которое описано в главе 3, и о котором мы уже выяснили, что его связь с современными ER-моделями весьма опосредованная.

                                                                                  Таким образом, вернемся к исходному вопросу: какие существенные ограничения ER-моделей вы можете назвать (и привести примеры конкретных прикладных областей, где это мешает работе)?
                                                                                  • 0
                                                                                    Давайте так: Вам не мешает моделирование в ER нотации? Ок! Я не пытаюсь создать Вам лично проблемы. Мне мешают? Да. Я делюсь теми причинами и теми способами, которыми я преодолел эти ограничения. У Вас нет этих проблем и, значит, нет желание чего-то преодолевать. Вы говорите, что мои проблемы от моего невежества. Ок. Я согласен с Вами. Я дремуч и невежествен. Если Вам надо доказывать свою правоту человеку, которого Вы даже не знаете, то да, Вы правы.
                                                                                    • 0
                                                                                      >> Я делюсь теми причинами и теми способами, которыми я преодолел эти ограничения.
                                                                                      Нет, не делитесь. Вы говорите «у ER-моделей есть ограничения, которые мы будем преодолевать», но любую просьбу привести конкретный пример этих ограничений вы игнорируете.

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

                                                                                      Я не скрываю, что стараюсь идти по пути наименьшего необходимого усилия — потому что покидать хоть как-то понятные всем участникам команды принципы моделирования ради каких-то мифических ограничений с точки зрения проекта (-ов) просто неэффективно.
                                                          • 0
                                                            Так именно что Марку интересна модель per se, ради модели. Любой намек на практическую применимость он отвергает под предлогом утраты моделью должной общности. Собственно из чего и понятно, что «общность» и является действительной «целью» рассуждений Марка.

                                                            Но, в силу того что «общность» по определению размыта и не предполагает способа и критерия определить, достигнута ли она (в отличие от её антипода «детальности») — рассуждения Марка подобны САУ с положительной ОС. Посему они и обречены растекашеся все большим стадом мысей по все большему лесу древ.

                                                            Тогда как обычный режим поисковых размышлений аналитика — это режим САУ с отрицательной ОС, когда во времени процесс мышления/моделирования сходится к требуемому уровню детальности, причем для определения этого уровня есть и способ, и критерий.
    • +1
      Во-первых, нельзя из программиста вырасти до аналитика, это профессии, у которых очень мало общего, и они не находятся на одной линейке развития.

      А во-вторых, то, о чем говорит автор, к реальному анализу, применяемому при разработке ПО, имеет чрезвычайно малое отношение.
  • +1
    Спасибо за разъяснения. Теперь мне хоть немного стал ясен изначальный замысел этого цикла статей. Да, видимо,
    нельзя из программиста вырасти до аналитика

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

    Заказчик, скорее всего, так и формулирует условия. Но до программиста это не должно доходить в таком виде. Кто то должен переварить это и выдать на-гора нечто вроде:
    — Когда уровень освещенности становится меньше 1 лк освещение должно быть включено.
    — Когда время смыкания век водителя становится больше 0.5 с торможение должно быть активировано на уровне достаточном для обеспечения замедления величиной в 5,5 м/с2
    — Когда показания датчика веса установленного под рабочем местом кассира становятся ниже 5 кг на протяжении 2 с кассовый аппарат должен быть заблокирован.

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

    Кто должен заниматься созданием такого рода требований и моделированием систем на их основе?
    • 0
      Созданием требований занимаются аналитики (если мы говорим о функциональных требованиях). А вот построением модели — когда как. Для требований нужна одна модель (и, на самом деле, в разных требованиях — разная), для проектирования системы — уже другая (и тоже не одна).
    • 0
      Попробуйте прочитать статью, в которой на примере термина договор я рассказываю про то, как видят мир программисты. Возможно, будет интересно и полезно
    • +1
      Все зависит от программиста, электроника, желаемого результата и результатов проработки.

      Кто-то в любом случае должен определиться с требованиями — быть может солнце заходит по расписанию, водитель считается заснувшим, когда собирается выехать на встречку, а «кассир встал» — имеется ввиду прекращение авторизованного доступа технического персонала к материальным ценностям и должно учитывать вариант, когда кассира вытаскивают из-за стула, а на его место ставят гирю…

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

      — Можно ли доверять датчику освещенности настолько, чтобы замерять ровно 1лк? или лучше учесть погрешность в его работе и включать свет уже при 1.2лк?
      — Что делать со временем смыкания век водителя, если он, негодяй такой, взял и отвернулся от камеры, а камера считает, что он закрыл глаза?
      — Стоит ли учитывать вес стула, который стоит на рабочем месте кассира, как нулевую точку отсчета или забить до того момента, как кто-нибудь не решит ставить кассирам шестикилограммовые стулья?

      Часто это можно решить сразу и угадать. А часто можно и не угадать — порой достаточно сложно понять, почему аналитик взял те или иные цифры и какого эффекта он ожидает на самом деле.
      • 0
        Как я вижу профдеформацию программистов? Программируя, они часто забывают о том, что они на самом деле делают. Если программист создает информационную систему, то через некоторое время он забывает, что создаваемые им сущности — информационные объекты, несущие информацию о предметной области. Сами информационные объекты в воображении программиста становятся объектами предметной области. Это верно, если он занимается моделированием информационных объектов системы, а не объектов предметной области. Но, моделирую информационные объекты, он связывает их жесткой связью с объектами предметной области. И с этого момента он становится непригодным как аналитик предметной области, да и как системный аналитик — тоже. Если же он, глядя на таблицу под названием договора, будет видеть записи таблицы, хранящие информацию о классе объектов, каждый из которых (объектов) — есть экземпляр договора, то шанс быть аналитиком у него есть. Кроме того, он должен знать ограничения тех инструментов моделирования, которые он использует в работе. Но этого часто не знают и сами аналитики(.
        • 0
          Не без этого. Хотя точка зрения на это отличается. Быть может только терминологически,

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

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

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

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

              (под «выяснением настоящих желаний» я понимаю переход от «добавьте мне вот тут одно поле» к «для выполнения такого-то закона необходимо учитывать еще и вот такие характеристики объектов учета таким-то образом»)
      • 0
        Я заметил одну важную деталь в Ваших рассуждениях, на которую хочу обратить внимание. Вы просите определить требования. когда водитель считается уснувшим. Это абсолютно законное желание. Однако, Вы забываете указать интервал значений, при которых переход из одного состояния в другой будет считаться выполненным. Допуск — вот что Вы забыли. А он как раз решает философский вопрос о том, что есть событие? Если ввести допуск, то момент времени превратится в интервал времени. То есть водитель считается уснувшим не в момент времени, а в интервале времени. И так со всеми событиями. Кроме того, надо добавить погрешности измерений. И тогда на сцену появляется новый игрок — вероятность получения достоверных данных на основе проведенных испытаний. И это делает наш интервал не просто интервалом, но еще и вероятностным интервалом.
        • 0
          >>Цели я обозначил сразу — неудовлетворенность существующими методами моделирования предметной области и тотальное невежество
          Может быть уточните само понятие — цель. То что мы видим — это же не цель! После этого хотелось бы саму Вашу цель осознать
          • 0
            Я потратил около 10 лет на попытку понять некоторые вещи. Оказалось, что существующий state of art бизнес-анализа не способен ответить на мои вопросы. Мне понадобилось еще 2 года, чтобы самостоятельно ответить на них. Теперь у меня есть запрос от коллег по цеху, которые просят описать эту позицию в виде текста, а не в виде устного творчества. Я выполняю этот запрос.
            • 0
              С целью — то что? Ответа не будет?
              • 0
                Цели имеют иерархическую структуру. Есть цель пописать. Она разбивается на цели: найти туалет и цель — успеть до него добежать. Но цель пописать возникает из желания выжить. И так далее. Вы скажите, какого уровня цель вы имеете ввиду?
                • 0
                  >>Цели я обозначил сразу — неудовлетворенность существующими методами моделирования предметной области и тотальное невежество
                  >>Вы скажите, какого уровня цель вы имеете ввиду?
                  Я имею ввиду те цели и того уровня, который Вы обозначили сразу.
                  Мой вопрос не структуре цели, а о том что это такое для Вас- целью называется…
                  • +1
                    Возможно, Вы не прочли мой ответ, что был ранее. Меня попросили поделиться наработками, чтобы они не остались только на словах. Моя цель — зафиксировать в текстовом виде эти наработки. Это поможет другим. ИМХО
  • 0
    Попробую зафиксировать некоторые комментарии по ходу чтения:
    Далее мы называем экстент тем, чем мы хотим его представить

    Вроде изначально подразумевалось, что речь идет об одном и том же экстенте, но далее по тексту этот вопрос как-то замалчивается. Вопрос: событие (ширина во времени равна нулю, конечно, в изложении субъекта) и операция (с временными границами) — это про один и тот же экстент? Если про один, то возникает законный вопрос, как мы будем формализовать фразу "ширина экстента во времени равна с точки зрения рассказчика нулю"?
    Мы часто сталкиваемся с описание субъективной оценки вместо описания… Субъективная трактовка экстента – это...

    Здесь одним термином «субъективное» обозначены два понятия: «личное оценочное» (мнение, суждение) и «распознаваемое с позиции субъекта» (событие, предикат, функция и пр.). Трактовка экстента с той или иной точки зрения — это не оценка факта, а сам факт: факт фиксации функции объекта в том или ином действии, что может быть сделано даже без участия субъекта. Если и упоминать субъекта, то использовать вместо слова «субъективная» термин «субъектная» — два понятия, два термина. Хотя первое понятие, на мой взгляд, тут совсем лишнее.
    Все наши описания – это лишь некие приблизительные модели, описывающие реальные объекты довольно упрощенно.

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

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

    И даст простой ответ: а как условимся фиксировать, так и будет (хоть датчик на двери, хоть открытие формы ввода данных секретарем или по нажатию клавиши Enter) ведь практически всегда нам нужно не абсолютное значение времени события, а наличие события и его положение во времени относительно других событий — плюс минус несколько секунд/минут тут не играет роли (будет играть — пересмотрим условия фиксации).
  • 0
    как мы будем формализовать фразу «ширина экстента во времени равна с точки зрения рассказчика нулю»?


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

      Вопрос был о том, как мы в системе должны зафиксировать ситуацию «ширина экстента во времени равна с точки зрения рассказчика нулю»? Где в системе рассказчик? И как указать его взгляд на ширину экстента? Как зафиксировать, что у других рассказчиков будет другая длина экстента? Тем более, что никакого упоминания, что у нас время хоть как-то отличается от физического не было.
      • 0
        Я абсолютно серьезно комментирую. Все эти вопросы были у меня, когда я разбирал задачу. И это не спонтанные решения. Они выстраданы не одним годом рассуждений. Задайте себе вопрос о том, как мы определяем вершину пирамиды Хеопса. Где она? есть ли у нее размер? Если нет, то как определить ее абсолютно точно?
        • 0
          Я абсолютно серьезно комментирую.
          Я понимаю, что вы не шутите ))).

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

          И что получается? Я задаю вопрос: «как мы будем формализовать фразу «ширина экстента во времени равна с точки зрения рассказчика нулю»?». А в ответ получаю: «Я нашел таки статью Колмогорова о геометрических точках» и еще подумайте над тем " как мы определяем вершину пирамиды Хеопса".

          Это даже не про бузину и дядьку, а гораздо круче. Я понимаю, что проблема во мне, что я не вижу связи между абстрактными понятиями, пирамидой и решением конкретной технической проблемы (фиксации в онтологии мнения рассказчика). Но ведь поэтому и задаю вопрос. А в ответ получаю: читайте Колмогорова. ))
          • 0
            как мы будем формализовать фразу «ширина экстента во времени равна с точки зрения рассказчика нулю»?


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

              Итак, есть некая система, есть экстент, есть два субъекта («рассказчика»), для одного ширина экстента во времени равна нулю (с его точки зрения), для другого — не равна. Как мы это запишем? как зафиксируем? как с этим будем оперировать?
              • 0
                Как мы это запишем? как зафиксируем? как с этим будем оперировать?


                Также как в черчении пишем границу здания — линией обозначаем то, чего нет в природе: плоскость фасада. Формализм тот же.
                • 0
                  Так у нас на чертеже будет две линии? Одна тонкая для одного субъекта и вторая широкая для другого? Повторю вопрос:
                  есть два субъекта («рассказчика»), для одного ширина экстента во времени равна нулю (с его точки зрения), для другого — не равна. Как мы это запишем?
                  • 0
                    Есть фасад здания. Для одного — это плоскость. Для другого — поверхность очень сложной формы, а для третьего — электромагнитное поле без четких границ. Как мы запишем это? Мы возьмем точку зрения субъекта и запишем, все, что он нам сообщит о фасаде. Точно также мы запишем все. что сообщит нам субъект об экстенте.
                    • 0
                      Следует ли считать, что ваш ответ означает, что мы должны иметь столько моделей системы, сколько имеется разных точек зрения? Существование разных точек зрения (для одного субъекта договор это бумажка, для другого — файл) в одной модели исключается.
                      • 0
                        Любая модель начинается с определения точки зрения. Как только появляется другая точка зрения, — это приводит нас к необходимости создания нового представления новой модели. В ИС это часто можно видеть в примерах планирования проектов. Есть точка зрения верхнеуровневого планирования, есть подробного. Для обеих точек зрения разрабатывается две модели, расчет идет для каждой отдельно.
                        • 0
                          Да, спасибо. Мне показалось, что вы указывая на точку зрения отдельного субъекта подразумевали возможность ее учета в модели. А так вопросов нет — всем ясно, что модель отражает некоторую точку зрения.

                          Спасибо

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