Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 79
И ещё раз — по 15926 при совпадении экстентов совпрадают индивиды. Функциональный объект и физичекий невозможно различить на основе только анализа их экстентов.
Если вы вводите «функциональное событие» по аналогии с функциональным объектом — покажите, как именно оно состоит из обычных событий. Если же аналогии такой нет, то, пожалуйста, откажитесь от использования слова «функциональный», чтобы не сбивать понимание тех, кто работает в рамках ISO 15926.
Если вы вводите «функциональное событие» по аналогии с функциональным объектом — покажите, как именно оно состоит из обычных событий. Если же аналогии такой нет, то, пожалуйста, откажитесь от использования слова «функциональный», чтобы не сбивать понимание тех, кто работает в рамках ISO 15926.
Экстенты равны друг другу, если совпадают. Это абсолютно понятно. Далее: один экстент может трактоваться как функциональный объект, как информационный объект, как операция. Это тоже не должно вызывать нареканий, потому что в ИСО нет ограничений на экстенты, которые могут трактоваться так и не могут трактоваться иначе. То есть, любой экстент ассоциируется с любым количеством функциональных объектов, информационных объектов и операций. В моем мире события — тоже 4-Д объекты. Причину я изложил подробно в статье. Поэтому любой экстент может трактоваться как событие. Я не знаю, какие термины ввести, чтобы сказать простую вещь: что есть трактовка экстента как объекта, события, операции и есть трактовка уже объекта, событие и операции. Я принял допущение, что функциональность объекта, события и операции отражает субъективный взгляд на событие, объект и операцию. (Список объектов можно продолжать). Я не нашел других терминов в ИСО для отражения субъективной точки зрения. Именно функциональность объектов отличает разные точки зрения на один физический объект. Это и было взято за основу. Если есть другие термины, то они должны быть названы, и приведены в соответствие с терминами физический и функциональный объект.
До прочтения этой статьи, я думал, что неплохо было бы из программиста вырасти до аналитика. Но Вы (автор) меня поставили в затруднение.
Неужели все эти рассуждения необходимы? Нет, конечно, это очень увлекательно, но в рамках некой гуманитарной дисциплины (по моему мнению). Читая Вашу статью, я вновь почувствовал себя на лекциях по Философии, на которых я все время пытался вслушаться в то, что именно до меня хотят донести, и чем мне это поможет на практике. Но вынес очень мало, а применил и того меньше.
Я все это говорю не для того, что бы обидеть или как то себя обозначить. Я просто хочу сказать, что у «технарей» (инженеров, программистов и пр.) шарики в голове немного не так вертятся. У них даже не возникает мысли о том
Еще один момент. Научные работы «технарей» (статьи, диссертации) всегда очень конкретны. И если встречается фраза
Иначе это не закон.
Прошу прощения, если получилось грубовато. Но хочется больше конкретики или не бывать мне аналитиком :)
Неужели все эти рассуждения необходимы? Нет, конечно, это очень увлекательно, но в рамках некой гуманитарной дисциплины (по моему мнению). Читая Вашу статью, я вновь почувствовал себя на лекциях по Философии, на которых я все время пытался вслушаться в то, что именно до меня хотят донести, и чем мне это поможет на практике. Но вынес очень мало, а применил и того меньше.
Я все это говорю не для того, что бы обидеть или как то себя обозначить. Я просто хочу сказать, что у «технарей» (инженеров, программистов и пр.) шарики в голове немного не так вертятся. У них даже не возникает мысли о том
«Что есть событие «клиент пришел?»Либо на двери есть датчик, либо нет, и как следствие — нет события. Да и, к тому же, что требуется от разрабатываемой системы при возникновении этого события? Я не сталкивался с разработкой систем, логика которых основана на таких событиях, как «клиент пришел», «кассир подумал», «Солнце село». Это очень, повторяю, очень абстрактно. Инженеру нужно нечто, что можно измерить.
Еще один момент. Научные работы «технарей» (статьи, диссертации) всегда очень конкретны. И если встречается фраза
Теперь рассмотрим операции. Для них действуют те же законы, что и для событий: деление на физические и функциональныето перед этим обязательно есть формулировка этих законов. Дайте определение, например, закон деления событий на физические и функциональные состоит в том, что…
Иначе это не закон.
Прошу прощения, если получилось грубовато. Но хочется больше конкретики или не бывать мне аналитиком :)
Спасибо огромное за комментарий! Я хочу подчеркнуть, насколько важно то, что Вы сейчас сказали. Технарям действительно не нужны философские рассуждения. Им нужны практические рецепты применения этих рассуждений. Но вот тут собака-то и порылась. Вы как собираетесь моделировать предметную область? ER-диаграммами? Диаграммами классов? И тот и другой метод проектирования дают точность в полкилометра мимо. Если Вас устраивает такая точность, то Вы вполне можете использовать существующие методы проектирования данных. Но, если вы хотите полновесного попадания в цель, то Вам придется учиться очень много и очень долго.
Далее Вы будете «автоматизировать процессы». Если Вы действительно хотите помочь организации. то Вам придется глубоко проникнуть в суть того, что такое «процесс». Иначе Вы просто не сможете учесть то множество корреляций, которое (множество) в итоге развалит всю стройность планируемой системы. Как правило, эти корреляции исключаются на уровне интуиции. Однако, поскольку нет языка, чтобы это описать, нет возможности этому научить. И следовательно, мы как алхимики учимся на собственных ошибках за счет клиента.
Повторюсь, большинство аналитиков не знают того, о чем я пишу. И большинству аналитиков это не нужно. И большинству аналитиков это не интересно. Я прекрасно отдаю себе отчет в этом. Однако, существуют немного людей, которым также как и мне важно знать, что они делают и почему именно так надо делать, а не иначе. Вот для них я пытаюсь описать свое видение, потому что другие точки зрения меня пока не устраивают.
Далее Вы будете «автоматизировать процессы». Если Вы действительно хотите помочь организации. то Вам придется глубоко проникнуть в суть того, что такое «процесс». Иначе Вы просто не сможете учесть то множество корреляций, которое (множество) в итоге развалит всю стройность планируемой системы. Как правило, эти корреляции исключаются на уровне интуиции. Однако, поскольку нет языка, чтобы это описать, нет возможности этому научить. И следовательно, мы как алхимики учимся на собственных ошибках за счет клиента.
Повторюсь, большинство аналитиков не знают того, о чем я пишу. И большинству аналитиков это не нужно. И большинству аналитиков это не интересно. Я прекрасно отдаю себе отчет в этом. Однако, существуют немного людей, которым также как и мне важно знать, что они делают и почему именно так надо делать, а не иначе. Вот для них я пытаюсь описать свое видение, потому что другие точки зрения меня пока не устраивают.
Мне, как программисту, рассуждения такого рода кажутся достаточно интересными. Поскольку позволяют получить какую-никакую обратную связь между поведением пользователя и поведением системы. Конечно же, это философия чистой воды, но порой эта философия коренным образом меняет представление о системе.
Самый явный пример мне в голову приходит на тему разницы блокировки и удаления. как будет вести себя система, если пользователь захочет удалить свою учетную запись. С одной стороны для разработчика системы оба этих действия могут выглядеть абсолютно одинаково. А с другой стороны — пользователь, получая возможность заблокировать учетную запись, может ожидать что у него будет возможность ее разблокировать. Или же наоборот, не захотев блокировать — он захочет ее удалить. Почему так происходит? Потому что с точки зрения пользователя и с точки зрения системы может использоваться разная терминология.
То же самое и с событиями — если клиент хочет на какое-то абстрактное событие повесть какое-то абстрактное действие, бог ему судья. Но реализация системы, по хорошему, должна удовлетворить этого клиента. Даже в простейшем «клиент пришел» могут таиться огромные разночтения. Может быть подразумевается, что это именно клиент — а не просто посетитель. И именно пришел — а не приехал на кресле или велосипеде. А может быть вообще это вода в спецификации и всем все равно — клиент, или не клиент, пришел или материализовался. Мало ли какие особенности у конкретной бизнес-модели могут быть. Но на построение системы это может оказать огромное влияние. Если в одном случае это затрагивает не только клиента и кофеварку но еще и системы визуальной аутентификации и мониторинга, то в другом случае это личное событие клиента.
Абстрактная модель даже без изменений — весьма любопытная штука.
Ну и примеры неудачные. «Солнце село», «водитель уснул», «кассир встал» — вполне достаточные условия для того, чтобы включить освещение, принудительно активировать торможение транспортного средства или заблокировать кассовый аппарат.
Самый явный пример мне в голову приходит на тему разницы блокировки и удаления. как будет вести себя система, если пользователь захочет удалить свою учетную запись. С одной стороны для разработчика системы оба этих действия могут выглядеть абсолютно одинаково. А с другой стороны — пользователь, получая возможность заблокировать учетную запись, может ожидать что у него будет возможность ее разблокировать. Или же наоборот, не захотев блокировать — он захочет ее удалить. Почему так происходит? Потому что с точки зрения пользователя и с точки зрения системы может использоваться разная терминология.
То же самое и с событиями — если клиент хочет на какое-то абстрактное событие повесть какое-то абстрактное действие, бог ему судья. Но реализация системы, по хорошему, должна удовлетворить этого клиента. Даже в простейшем «клиент пришел» могут таиться огромные разночтения. Может быть подразумевается, что это именно клиент — а не просто посетитель. И именно пришел — а не приехал на кресле или велосипеде. А может быть вообще это вода в спецификации и всем все равно — клиент, или не клиент, пришел или материализовался. Мало ли какие особенности у конкретной бизнес-модели могут быть. Но на построение системы это может оказать огромное влияние. Если в одном случае это затрагивает не только клиента и кофеварку но еще и системы визуальной аутентификации и мониторинга, то в другом случае это личное событие клиента.
Абстрактная модель даже без изменений — весьма любопытная штука.
Ну и примеры неудачные. «Солнце село», «водитель уснул», «кассир встал» — вполне достаточные условия для того, чтобы включить освещение, принудительно активировать торможение транспортного средства или заблокировать кассовый аппарат.
Как программисту мои рассуждения могут показаться слишком надуманными и лишними. Вопрос, который я обсуждаю, больше нужен аналитику. Эти вопросы возникают при проведении митингов с заказчиком и попытке так сформулировать ТЗ. чтобы и вашим и нашим было понятно, о чем идет речь. Программисту дают вообще не модель предметной области, а модель реализации. Поэтому программист не видит моделей предметных областей, или точнее не должен их видеть. Но проблема в том, что аналитики вырастают из программистов. И эти аналитики начинают видеть, например, наследование в предметной области. То есть то, чего там в принципе быть не может. И вот эти аналитики, к сожалению, не делают разницы между моделированием предметной области и моделированием реализации. И тогда возникает вопрос: о чем я тут пишу? Для таких аналитиков моя статья кажется чисто философской и лишенной практического смысла
>> Программисту дают вообще не модель предметной области, а модель реализации. Поэтому программист не видит моделей предметных областей
Правда? А кто же составляет «модель реализации» и на каком основании? Аналитик? А откуда он знает, как правильнее реализовывать ту или иную функциональность?
(еще, конечно, то, что вы говорите, противоречит идеям domain-driven design чуть менее, чем полностью)
Правда? А кто же составляет «модель реализации» и на каком основании? Аналитик? А откуда он знает, как правильнее реализовывать ту или иную функциональность?
(еще, конечно, то, что вы говорите, противоречит идеям domain-driven design чуть менее, чем полностью)
Модель предметной области создает бизнес-аналитик. Модель системных объектов и системных функций — системный аналитик. Иногда, и очень часто, эти роли совмещены.
Что касается domain-driven design. Какую бы методику проектирования мы не взяли, к ней можно применить слова Крега Лармана:
На странице 36-37 его книги написано:
Программные объекты в некотором смысле соответствуют объектам реального мира, но не являются их точными моделями или копиями. Хотя полученная диаграмма классов проектирования не до конца соответствует модели предметной области, некоторые имена классов и их характеристики совпадают. Объектно-ориентированные проектные решения и языки позволяют уменьшить разрыв между представлением информации в виде программных компонентов и ментальными моделями предметной области. Это улучшает образность представления.
Есть методика, которая позволила бы сделать непосредственное моделирование предметной области в коде. ИСО 15926 для этого и создавалось. Но посмотрите на ресурсы, которые требуются для реализации этой методики (как интеллектуальные так и машинные), и поймете, что пока эта желанная цель не достигнута.
Что касается domain-driven design. Какую бы методику проектирования мы не взяли, к ней можно применить слова Крега Лармана:
На странице 36-37 его книги написано:
Программные объекты в некотором смысле соответствуют объектам реального мира, но не являются их точными моделями или копиями. Хотя полученная диаграмма классов проектирования не до конца соответствует модели предметной области, некоторые имена классов и их характеристики совпадают. Объектно-ориентированные проектные решения и языки позволяют уменьшить разрыв между представлением информации в виде программных компонентов и ментальными моделями предметной области. Это улучшает образность представления.
Есть методика, которая позволила бы сделать непосредственное моделирование предметной области в коде. ИСО 15926 для этого и создавалось. Но посмотрите на ресурсы, которые требуются для реализации этой методики (как интеллектуальные так и машинные), и поймете, что пока эта желанная цель не достигнута.
Вы там выше говорили про модель реализации, а теперь, внезапно, переключились на системную модель. Это одно и то же, или разные вещи?
Приведенная вами цитата Лармана применима не к любой методике проектирования: далеко не всегда то, чем оперирует программа, имеет отношение к реальному миру. И уж тем более эта цитата не противоречит тому факту, что ваше утверждение, что программист не видит модель предметной области, противоречит DDD.
И нет, ISO 15926 не имеет отношения к моделированию предметной области в коде, потому что ISO 15296 обсуждает именно модель данных (то, что Асафьев назвал бы формой-кристаллом), но он никак не связан с алгоритмикой и структурой кода, а, следовательно, не может предлагать решений по выражению намерений и/или семантики в языках программирования.
Приведенная вами цитата Лармана применима не к любой методике проектирования: далеко не всегда то, чем оперирует программа, имеет отношение к реальному миру. И уж тем более эта цитата не противоречит тому факту, что ваше утверждение, что программист не видит модель предметной области, противоречит DDD.
И нет, ISO 15926 не имеет отношения к моделированию предметной области в коде, потому что ISO 15296 обсуждает именно модель данных (то, что Асафьев назвал бы формой-кристаллом), но он никак не связан с алгоритмикой и структурой кода, а, следовательно, не может предлагать решений по выражению намерений и/или семантики в языках программирования.
Модель реализации — это и есть модель системы. Потому что система — есть реализация. Система моделирует предметную область. Модель предметной области создает бизнес-аналитик. Модель системы — системный аналитик. Эти аналитики делают так, чтобы модель предметной области нашла свое отражение в реализации. А реализация была описана простым и понятным для программиста образом.
Я сказал, что я согласен с Ларманом. ИМХО.
Про ИСО я знаю мало — это лучше Левенчука почитать. Его команда делает адаптеры для информационных систем и, насколько я знаю, успешно.
Я сказал, что я согласен с Ларманом. ИМХО.
Про ИСО я знаю мало — это лучше Левенчука почитать. Его команда делает адаптеры для информационных систем и, насколько я знаю, успешно.
То есть в вашей картине мира аналитик настолько хорошо разбирается в технологиях, чтобы принимать решения по реализации? (Простейший пример такого решения — это методология и структура хранения данных)
И нет, система не моделирует предметную область. Система выполняет поставленные задачи, для чего она может (а может и не) содержать можель предметной области, причем в зависимости от ситуации эта модель может быть более или менее явной.
И нет, система не моделирует предметную область. Система выполняет поставленные задачи, для чего она может (а может и не) содержать можель предметной области, причем в зависимости от ситуации эта модель может быть более или менее явной.
Системный аналитик настолько хорошо разбирается в технологиях, что на него и на архитектора возлагаются задачи проектирования системы.
А вот тут я не понимаю, о чем Вы. Есть предметная область. Есть информационная модель предметной области. И это разные вещи. Они могут стать одной только в том случае, когда байты станут признаваться в качестве аргумента в суде. Но до этого пока далеко.
А вот тут я не понимаю, о чем Вы. Есть предметная область. Есть информационная модель предметной области. И это разные вещи. Они могут стать одной только в том случае, когда байты станут признаваться в качестве аргумента в суде. Но до этого пока далеко.
Удачи вам в поиске таких системных аналитиков. Я таких не видел никогда (и не думаю, что когда-либо увижу). Собственно, в чем тогда отличие между функциями системного аналитика и архитектора? (и да, архитектор — это уже часть разработки, поэтому «разработчик» модель предметной области видит)
Я о том, что бывают системы, которые не содержат модели предметной области, поскольку для выполнения возложенных на систему задач это не нужно.
Я о том, что бывают системы, которые не содержат модели предметной области, поскольку для выполнения возложенных на систему задач это не нужно.
Я не знаю, в чем отличие, потому что мой интерес — модели предметной области, а не модели системы или реализации. Хотя, я знаком с ними и с принципами их разработки, но это не мое.
Опять не понятно. Система не содержит модель. Она есть модель.
Опять не понятно. Система не содержит модель. Она есть модель.
Тогда зачем вы что-то утверждаете об области, в которой вы не разбираетесь? (Самый яркий пример такого утверждения — это то, что разработчики не имеют дела с моделью предметной области)
Нет. Система — не модель. Система — это (в контексте хабра) аппаратно-програмный комплекс, работающий с или без привлечения человека. Этот комплекс — это вполне реальный объект, а не модель чего бы то ни было.
И да, вы противоречите себе: если программист не видит — как вы пишете — модели предметной области, то как он может разработать систему, которая — как вы пишете — является моделью предметной области?
Нет. Система — не модель. Система — это (в контексте хабра) аппаратно-програмный комплекс, работающий с или без привлечения человека. Этот комплекс — это вполне реальный объект, а не модель чего бы то ни было.
И да, вы противоречите себе: если программист не видит — как вы пишете — модели предметной области, то как он может разработать систему, которая — как вы пишете — является моделью предметной области?
Я говорю с чужих слов, — тех людей, которые считают себя профессионалами. Одни из них — системные аналитики, другие — архитекторы, третьи — программисты, четвертые — бизнес-аналитики. Каждый имеет что сказать про свою работу.
До сего момента я рассказывал про информационные системы. Информационная система — объект, но информационный. Его также можно моделировать, как и любой другой объект, но об этом я писал ранее. Если мы говорим про другие системы — то Вы скажите, какие Вы имеете ввиду и мы рассмотрим их подробно.
Программист не разрабатывает систему. Он программирует. разработкой системы занимается системный аналитик и архитектор. Если программист выполняет роль системного аналитика или архитектора, то это совмещение ролей. Но не одна роль!
До сего момента я рассказывал про информационные системы. Информационная система — объект, но информационный. Его также можно моделировать, как и любой другой объект, но об этом я писал ранее. Если мы говорим про другие системы — то Вы скажите, какие Вы имеете ввиду и мы рассмотрим их подробно.
Программист не разрабатывает систему. Он программирует. разработкой системы занимается системный аналитик и архитектор. Если программист выполняет роль системного аналитика или архитектора, то это совмещение ролей. Но не одна роль!
Вам не кажется, что это странный подход — говорить о чужой работе с чужих слов, но едва вам зададут вопрос или укажут на не точность — сразу говорить, что вы этим не занимаетесь? А чем вы тогда занимаетесь?
Я тоже говорю об информационных системах, и именно к ним применимо мое определение. И именно информационные системы не являются моделью предметной области.
Вот с момента «программист не разрабатывает систему» вы снова явно пишете о том, в чем не разбираетесь. Программист именно разрабатывает систему (собственно, именно поэтому уже давно говорят «разработчик», а не «программист»), а архитектор занимается проектированием системы (причем на самом деле это не исключает того, что каждый разработчик тоже проектирует систему, просто на своем уровне). Но самое главное состоит в том, что даже не принимая во внимание эту терминологическую ошибку, вы все равно себе противоречите: нельзя «программировать» систему, не осознавая ее целиком.
Проще говоря: как только вы лишаете разработчика доступа к информации о предметной области (в первую очередь — к требованиям и содержащейся в ней модели), вы лишаете его возможности принимать мотивированные решения уровня реализации, а себя — его экспертизы в области проектирования. Вы превращаете его в бездумную машину, конвертирующую неизвестно что в код, не осознавая значения этого неизвестно чего на входе.
Я тоже говорю об информационных системах, и именно к ним применимо мое определение. И именно информационные системы не являются моделью предметной области.
Вот с момента «программист не разрабатывает систему» вы снова явно пишете о том, в чем не разбираетесь. Программист именно разрабатывает систему (собственно, именно поэтому уже давно говорят «разработчик», а не «программист»), а архитектор занимается проектированием системы (причем на самом деле это не исключает того, что каждый разработчик тоже проектирует систему, просто на своем уровне). Но самое главное состоит в том, что даже не принимая во внимание эту терминологическую ошибку, вы все равно себе противоречите: нельзя «программировать» систему, не осознавая ее целиком.
Проще говоря: как только вы лишаете разработчика доступа к информации о предметной области (в первую очередь — к требованиям и содержащейся в ней модели), вы лишаете его возможности принимать мотивированные решения уровня реализации, а себя — его экспертизы в области проектирования. Вы превращаете его в бездумную машину, конвертирующую неизвестно что в код, не осознавая значения этого неизвестно чего на входе.
Мне кажется, или Вы действительно говорите про теплое, а я про мягкое?
В процессе разработки появляются три артефакта: описание предметной области, описание информационной системы и код.Вы согласны с этим?
В процессе разработки появляются три артефакта: описание предметной области, описание информационной системы и код.Вы согласны с этим?
Нет, не согласен.
Что вы понимаете под «разработкой»: один из этапов проекта (например, водопадного: анализ — проектирование — разработка — внедрение — сопровождение), или же весь проект целиком (как в «контракт на разработку системы управления складской деятельностью»)?
Что вы понимаете под «разработкой»: один из этапов проекта (например, водопадного: анализ — проектирование — разработка — внедрение — сопровождение), или же весь проект целиком (как в «контракт на разработку системы управления складской деятельностью»)?
Под разработкой понимается весь процесс от идеи до остановки сопровождения. Весь жизненный цикл. Понятно, что в процессе разработки появляются множество артефактов, но три перечисленные — возникают как правило. Хотя никто не говорит о том, что можно обойтись без одного из них. Даже работу кода можно симулировать. Так что ни один из артефактов не являясь обязательным, тем не менее присутствует как правило.
Даже в этом определении и с этими оговорками — не согласен. «Как правило» присутствуют только два артефакта: постановка задачи и результат работы. При этом первое не обязано содержать описание предметной области, а второе — код.
Я думаю, что мы не понимаем друг друга, потому что я априори считаю, что перед разработчиками стоит задача описания предметной области. Если не стоит такая задача, то «нет тела, нет преступления». То есть, нет смысла говорить о том, чего нет.
Мы с вами действительно не понимаем друг друга, потому что у вас какое-то свое (и меняющееся) понятие терминов «разработка» и «разработчик», отличающееся от принятого в индустрии.
Именно поэтому я как считал, так и продолжаю считать, что то, о чем вы говорите в своих постах, к реальным задачам и проблемам имеет на редкость малое и опосредованное отношение. Вы, например, легко и непринужденно отметаете ER-диаграммы, а я считаю их (в логическом варианте) незаменимым средством описания сущностей в предметной области.
Именно поэтому я как считал, так и продолжаю считать, что то, о чем вы говорите в своих постах, к реальным задачам и проблемам имеет на редкость малое и опосредованное отношение. Вы, например, легко и непринужденно отметаете ER-диаграммы, а я считаю их (в логическом варианте) незаменимым средством описания сущностей в предметной области.
ER диаграммы я не отметаю, я лишь рассказываю про их ограничения. И я привожу даже не свои исследования на этот счет. Эти исследования сделал не я. Я просто их иллюстрирую своими примерами.
У _любой_ модели есть ограничения. Важно лишь то, чтобы эти ограничения не противоречили целям моделирования.
Да. Я с самого начала говорю о том, что, если Вам достаточно тех методов, которыми Вы пользуетесь, — пользуйтесь ими. Мне не достаточно ER диаграмм. Я искал другие методы проектирования и нашел их. Теперь делюсь ими с теми, у кого есть такая же потребность. Я не настаиваю на том, что всем надо переходить на эти методы. Просто рассказываю про свой опыт и свое видение.
Для каких именно аналитических задач, возникающих при разработке ПО, вам недостаточно ER-диаграмм (для описания, повторюсь, сущностей), и у вас возникла потребность в использовании той системы, которую вы предлагаете? Что именно вы *проектируете* таким образом и в какой роли?
Вы хотите, чтобы я представил Вам доказательства необходимости моего подхода? Зачем Вам это? Я не пытаюсь никого ни в чем убедить. Я пытаюсь дать видение, которое у меня есть, но не стремлюсь заставить верить в него. Если Вам оно не нужно, — не пользуйтесь им.
Я хочу понять цели вашей модели.
Ну и да, вы регулярно говорите, что те или иные инструменты (которыми я, в том числе, пользуюсь) — недостаточны. Я хочу понимать, для чего они недостаточны, и в какой момент мне нужно переходить на ваш инструментарий.
Вы делаете утверждения о том, как должно и не должно быть в процессе разработки, но когда я оспариваю эти утверждения — вы никак их не обосновываете, и это тоже не добавляет мне понимания.
Ну и да, вы регулярно говорите, что те или иные инструменты (которыми я, в том числе, пользуюсь) — недостаточны. Я хочу понимать, для чего они недостаточны, и в какой момент мне нужно переходить на ваш инструментарий.
Вы делаете утверждения о том, как должно и не должно быть в процессе разработки, но когда я оспариваю эти утверждения — вы никак их не обосновываете, и это тоже не добавляет мне понимания.
Цели я обозначил сразу — неудовлетворенность существующими методами моделирования предметной области и тотальное невежество. Но это мое мнение. Я не пытаюсь убедить других в том, что я прав. Я могу ошибаться. Просто исследую эту область методами мне доступными. А вот зачем Вам обязательно меня убедить в том, что я не прав — не понимаю. У Вас свое мнение, у меня — свое. Это хорошо. Я не вижу смысла Вас переубеждать. Я не вижу смысла в том, чтобы Вы меня убедили в чем-то. Давайте закроем эту тему и продолжим работать. Это ведь гораздо интереснее, чем холиварить?
Неудовлетворенность существующими методами не модет быть целью модели, потому что у вам получается модель ради модели.
Что касается невежества — то вы бы хоть указывали, в чем?
Я не пытаюсь убедить вас, что вы не праы. Я просто вижу противоречие между вашим и моим подходом, и мне нужно разобраться. Если правы вы, то мой подход нужно менять. Если прав я, то нужно указать на ошибки вашего подхода — даже не обязательно и не столько вам, сколько тем, кто придет читать ваши статьи и делать из них выводы.
>> Оказалось, что существующий state of art бизнес-анализа не способен ответить на мои вопросы
Какие именно вопросы? При решении каких задач они возникли?
Что касается невежества — то вы бы хоть указывали, в чем?
Я не пытаюсь убедить вас, что вы не праы. Я просто вижу противоречие между вашим и моим подходом, и мне нужно разобраться. Если правы вы, то мой подход нужно менять. Если прав я, то нужно указать на ошибки вашего подхода — даже не обязательно и не столько вам, сколько тем, кто придет читать ваши статьи и делать из них выводы.
>> Оказалось, что существующий state of art бизнес-анализа не способен ответить на мои вопросы
Какие именно вопросы? При решении каких задач они возникли?
Чтобы проверить выкладки, не нужно знать целей проведения выкладок. Для целей обсуждения не нужно знать мои цели.
Про невежество напишу отдельную статью, когда придет время.
Если Вас не задел тот факт, что ER модель позволяет моделировать связи «Классификация» и «Специализация» предметной области двумя разными способами, да еще и не делая различия между ними, то у Вас нет вопросов, а значит и не может быть желания получить ответы. Поэтому для Вас есть два пути. Первый — это разобраться с тем, что я только что сказал и только после этого продолжить диспут. Или, если Вы хотите и дальше дискутировать, то похоже это будет на разговор глухого с немым.
Про невежество напишу отдельную статью, когда придет время.
Если Вас не задел тот факт, что ER модель позволяет моделировать связи «Классификация» и «Специализация» предметной области двумя разными способами, да еще и не делая различия между ними, то у Вас нет вопросов, а значит и не может быть желания получить ответы. Поэтому для Вас есть два пути. Первый — это разобраться с тем, что я только что сказал и только после этого продолжить диспут. Или, если Вы хотите и дальше дискутировать, то похоже это будет на разговор глухого с немым.
>> Чтобы проверить выкладки, не нужно знать целей проведения выкладок. Для целей обсуждения не нужно знать мои цели.
Я уже говорил, что обсуждать любую модель можно только в рамках ее целей, поскольку моделирование не бывает универсальным.
>> Если Вас не задел тот факт, что ER модель позволяет моделировать связи «Классификация» и «Специализация» предметной области двумя разными способами, да еще и не делая различия между ними
Нет, не задел. По одной простой причине: в *предметной области* не может быть связи «специализация» между сущностями (а связь «классификация» понимается совсем не в том значении, в котором вы ее используете). Если использовать ER-диаграммы по тому назначению, которое я описал выше (а именно: для описания логической — в противовес физической — модели данных в требованиях), то они прекрасно справляются. Не надо усложнять.
(и да, переход на личности засчитан)
Я уже говорил, что обсуждать любую модель можно только в рамках ее целей, поскольку моделирование не бывает универсальным.
>> Если Вас не задел тот факт, что ER модель позволяет моделировать связи «Классификация» и «Специализация» предметной области двумя разными способами, да еще и не делая различия между ними
Нет, не задел. По одной простой причине: в *предметной области* не может быть связи «специализация» между сущностями (а связь «классификация» понимается совсем не в том значении, в котором вы ее используете). Если использовать ER-диаграммы по тому назначению, которое я описал выше (а именно: для описания логической — в противовес физической — модели данных в требованиях), то они прекрасно справляются. Не надо усложнять.
(и да, переход на личности засчитан)
Я рассуждаю логически без привязки к цели, к которой я должен прийти. Я не знаю, куда приведут эти рассуждения. Пока я вижу определенный горизонт, на котором маячит нотация, которая была бы более удобна, чем те, которыми мне приходится пользоваться сейчас. Но это далекая перспектива.
Насчет специализации и классификации. Эти доводы найдены не мной. Ограничения моделей в виде таблиц известны онтологам, и способы их разрешения тоже известны. Если Вы понимаете эти ограничения и умеете их обходить, — не значит, что этих ограничений не существует, и не значит, что о них знать не надо.
Насчет специализации и классификации. Эти доводы найдены не мной. Ограничения моделей в виде таблиц известны онтологам, и способы их разрешения тоже известны. Если Вы понимаете эти ограничения и умеете их обходить, — не значит, что этих ограничений не существует, и не значит, что о них знать не надо.
А какое отношение «модели в виде таблиц» имеют к ER-диаграммам? Это принципиально разные представления.
Любую ER модель можно представить в виде набора таблиц. Причем однозначно, насколько я помню. Но тут я не силен, потому что моделирование при помощи таблиц лично мне не нравится. Все силы я направляю на моделирование в логической парадигме и только в самый последний момент, если это необходимо, реализую модель в виде таблиц.
>> Любую ER модель можно представить в виде набора таблиц.
Это будет модель модели (т.е., иное представление той же информации), и ее ограничения не имеют ничего общего с ограничениями самой ER-модели.
>> Но тут я не силен, потому что моделирование при помощи таблиц лично мне не нравится.
Я правильно понимаю, что на самом деле у вас нет *конкретного* примера ограничений ER-диаграмм как средства построения логической модели данных, а все, на что вы опирались перед этим утверждением — это «онтологам известны ограничения моделей в виде таблиц» и «моделирование при помощи таблиц мне не нравится»?
Если неправильно — то приведите, пожалуйста, все-таки такой пример.
Это будет модель модели (т.е., иное представление той же информации), и ее ограничения не имеют ничего общего с ограничениями самой ER-модели.
>> Но тут я не силен, потому что моделирование при помощи таблиц лично мне не нравится.
Я правильно понимаю, что на самом деле у вас нет *конкретного* примера ограничений ER-диаграмм как средства построения логической модели данных, а все, на что вы опирались перед этим утверждением — это «онтологам известны ограничения моделей в виде таблиц» и «моделирование при помощи таблиц мне не нравится»?
Если неправильно — то приведите, пожалуйста, все-таки такой пример.
Мои статьи посвящены почти целиком ограничениям моделирования в виде диаграмм классом, или ER моделей. Если Вас не устраивают мои примеры, то я привел книгу Криса Партриджа, в которой эти ограничения разобраны подробно.
Я уже отвечал на этот вопрос: меня не устраивает моделирование в виде ER диаграмм потому что они не различают связи классификация и специализация в предметной области и, кроме того, позволяют моделировать эти связи двумя разными способами. Из этого получается полный бардак в моделях. Меня это не устраивает
>> они не различают связи классификация и специализация в предметной области
Я же говорю: в предметной области между *сущностями* нет связей «классификация» и «специализация». Если есть — покажите конкретный пример.
>> ограничениям моделирования в виде диаграмм классом, или ER моделей
Диаграмма классов и ER-модель — это две фундаментально разных модели. В ваших статьях мне пока не удалось найти ни одного явного ограничения ER-моделей.
>> я привел книгу Криса Партриджа, в которой эти ограничения разобраны подробно.
Вы говорите о «Business Objects: Re-Engineering for Re-Use»? Не могли бы вы назвать конкретную главу, где описаны ограничения ER-моделей?
Я же говорю: в предметной области между *сущностями* нет связей «классификация» и «специализация». Если есть — покажите конкретный пример.
>> ограничениям моделирования в виде диаграмм классом, или ER моделей
Диаграмма классов и ER-модель — это две фундаментально разных модели. В ваших статьях мне пока не удалось найти ни одного явного ограничения ER-моделей.
>> я привел книгу Криса Партриджа, в которой эти ограничения разобраны подробно.
Вы говорите о «Business Objects: Re-Engineering for Re-Use»? Не могли бы вы назвать конкретную главу, где описаны ограничения ER-моделей?
«Business Objects: Re-Engineering for Re-Use»
страница 67 CHAPTER 3 What Is the Entity Paradigm? там же про неразличение отношений, и о том, как это обходится.
страница 67 CHAPTER 3 What Is the Entity Paradigm? там же про неразличение отношений, и о том, как это обходится.
Вы ошибаетесь. В этом разделе нет ни слова о 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-ом году).
Вот наглядный пример: одним из фундаментальных ограничений сущностной парадигмы Партридж считает то, что «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-ом году).
Мы не говорим о том, что ER модель не позволяет нам моделировать предметную область. И Крис с этим тоже не спорит. И иерархия типов решается легко. Вопрос не в этом. Вопрос в том, что эта иерархия легко может измениться, — это раз. По прихоти заказчика уже после начала эксплуатации системы. Во-вторых, эта иерархия типов может быть построена разными способами. То ли путем создания сущностей, то ли путем создания связей между сущностями, В предметной области нет разных способов существования вещей. там все однозначно. Неоднозначность реализации — болезнь самой реализации, а не предметной области. Ну и повторяю, что неразличение классификации и специализации — это тоже не сахар. Книгу стоит прочитать целиком.
Очень часто я слышу: мы не знали этого в самом начале и потому затраты на переделку будут вот такими! Поэтому часто проектировщики делают структуры на вырост и с запасом. Все потому что изменения неизбежны, а вектор их не всегда предсказуем. В логической парадигме появление новых знаний о проектируемом объекте, не ведет к никаким последствиям, кроме как добавлению новых классов и связей. В парадигме типов — постоянно жди неприятностей. У Криса есть график трудоемкости разработки на основе сущностей и на основе логической парадигмы в зависимости от объема кода. Посмотрите, он интересный.
>> Мы не говорим о том, что ER модель не позволяет нам моделировать предметную область.
Ну да, вы говорите, что у нее есть непреодолимые ограничения… только пока вам так и не удалось их назвать.
>> иерархия типов может быть построена разными способами. То ли путем создания сущностей, то ли путем создания связей между сущностями
Ну нет. Иерархия типов в ER-модели может быть построена ровно одним способом — как иерархия типов. То, о чем вы говорите — это уже не иерархия типов.
>> В предметной области нет разных способов существования вещей. там все однозначно.
Вообще-то, далеко не в каждой.
>> Неоднозначность реализации — болезнь самой реализации, а не предметной области.
Реализация должна быть однозначной. То, что для одной задачи есть больше одной возможной реализации — это не болезнь, а удобство, позволяющее выбирать ту реализацию, которая лучше подходит по совокупности параметров.
>> неразличение классификации и специализации
Приведите, пожалуйста, пример (и ER-диаграмму) из реальной предметной области, где это видно.
>> мы не знали этого в самом начале и потому затраты на переделку будут вот такими!
И будете слышать дальше. Переделка всегда стоит трудозатрат.
>> Поэтому часто проектировщики делают структуры на вырост и с запасом.
И ошибаются. Именно потому, что изменения непредсказуемы.
>> В логической парадигме появление новых знаний о проектируемом объекте, не ведет к никаким последствиям, кроме как добавлению новых классов и связей.
Это вы сейчас, вероятно, говорите об аналитических «последствиях». В реализации же картина будет совершенно иной.
>> У Криса есть график трудоемкости разработки на основе сущностей
>> и на основе логической парадигмы в зависимости от объема кода
Вы о рисунке P.5, он же повторен как 18.5? Так это, простите, график удельной сложности (т.е. сложности с поправкой на объем) в зависимости от объема проекта. Ни (а) трудоемкости, ни (б) разработки, ни (ц) кода там не упоминается. Ну и да, там говорится о «традиционном сущностном моделировании», которое описано в главе 3, и о котором мы уже выяснили, что его связь с современными ER-моделями весьма опосредованная.
Таким образом, вернемся к исходному вопросу: какие существенные ограничения ER-моделей вы можете назвать (и привести примеры конкретных прикладных областей, где это мешает работе)?
Ну да, вы говорите, что у нее есть непреодолимые ограничения… только пока вам так и не удалось их назвать.
>> иерархия типов может быть построена разными способами. То ли путем создания сущностей, то ли путем создания связей между сущностями
Ну нет. Иерархия типов в ER-модели может быть построена ровно одним способом — как иерархия типов. То, о чем вы говорите — это уже не иерархия типов.
>> В предметной области нет разных способов существования вещей. там все однозначно.
Вообще-то, далеко не в каждой.
>> Неоднозначность реализации — болезнь самой реализации, а не предметной области.
Реализация должна быть однозначной. То, что для одной задачи есть больше одной возможной реализации — это не болезнь, а удобство, позволяющее выбирать ту реализацию, которая лучше подходит по совокупности параметров.
>> неразличение классификации и специализации
Приведите, пожалуйста, пример (и ER-диаграмму) из реальной предметной области, где это видно.
>> мы не знали этого в самом начале и потому затраты на переделку будут вот такими!
И будете слышать дальше. Переделка всегда стоит трудозатрат.
>> Поэтому часто проектировщики делают структуры на вырост и с запасом.
И ошибаются. Именно потому, что изменения непредсказуемы.
>> В логической парадигме появление новых знаний о проектируемом объекте, не ведет к никаким последствиям, кроме как добавлению новых классов и связей.
Это вы сейчас, вероятно, говорите об аналитических «последствиях». В реализации же картина будет совершенно иной.
>> У Криса есть график трудоемкости разработки на основе сущностей
>> и на основе логической парадигмы в зависимости от объема кода
Вы о рисунке P.5, он же повторен как 18.5? Так это, простите, график удельной сложности (т.е. сложности с поправкой на объем) в зависимости от объема проекта. Ни (а) трудоемкости, ни (б) разработки, ни (ц) кода там не упоминается. Ну и да, там говорится о «традиционном сущностном моделировании», которое описано в главе 3, и о котором мы уже выяснили, что его связь с современными ER-моделями весьма опосредованная.
Таким образом, вернемся к исходному вопросу: какие существенные ограничения ER-моделей вы можете назвать (и привести примеры конкретных прикладных областей, где это мешает работе)?
Давайте так: Вам не мешает моделирование в ER нотации? Ок! Я не пытаюсь создать Вам лично проблемы. Мне мешают? Да. Я делюсь теми причинами и теми способами, которыми я преодолел эти ограничения. У Вас нет этих проблем и, значит, нет желание чего-то преодолевать. Вы говорите, что мои проблемы от моего невежества. Ок. Я согласен с Вами. Я дремуч и невежествен. Если Вам надо доказывать свою правоту человеку, которого Вы даже не знаете, то да, Вы правы.
>> Я делюсь теми причинами и теми способами, которыми я преодолел эти ограничения.
Нет, не делитесь. Вы говорите «у ER-моделей есть ограничения, которые мы будем преодолевать», но любую просьбу привести конкретный пример этих ограничений вы игнорируете.
А так, глядишь, если бы вы показали свои проблемы сообществу, может быть, уже бы и получили советы по их решению, не покидая существующей парадигмы.
Я не скрываю, что стараюсь идти по пути наименьшего необходимого усилия — потому что покидать хоть как-то понятные всем участникам команды принципы моделирования ради каких-то мифических ограничений с точки зрения проекта (-ов) просто неэффективно.
Нет, не делитесь. Вы говорите «у ER-моделей есть ограничения, которые мы будем преодолевать», но любую просьбу привести конкретный пример этих ограничений вы игнорируете.
А так, глядишь, если бы вы показали свои проблемы сообществу, может быть, уже бы и получили советы по их решению, не покидая существующей парадигмы.
Я не скрываю, что стараюсь идти по пути наименьшего необходимого усилия — потому что покидать хоть как-то понятные всем участникам команды принципы моделирования ради каких-то мифических ограничений с точки зрения проекта (-ов) просто неэффективно.
Так именно что Марку интересна модель per se, ради модели. Любой намек на практическую применимость он отвергает под предлогом утраты моделью должной общности. Собственно из чего и понятно, что «общность» и является действительной «целью» рассуждений Марка.
Но, в силу того что «общность» по определению размыта и не предполагает способа и критерия определить, достигнута ли она (в отличие от её антипода «детальности») — рассуждения Марка подобны САУ с положительной ОС. Посему они и обречены растекашеся все большим стадом мысей по все большему лесу древ.
Тогда как обычный режим поисковых размышлений аналитика — это режим САУ с отрицательной ОС, когда во времени процесс мышления/моделирования сходится к требуемому уровню детальности, причем для определения этого уровня есть и способ, и критерий.
Но, в силу того что «общность» по определению размыта и не предполагает способа и критерия определить, достигнута ли она (в отличие от её антипода «детальности») — рассуждения Марка подобны САУ с положительной ОС. Посему они и обречены растекашеся все большим стадом мысей по все большему лесу древ.
Тогда как обычный режим поисковых размышлений аналитика — это режим САУ с отрицательной ОС, когда во времени процесс мышления/моделирования сходится к требуемому уровню детальности, причем для определения этого уровня есть и способ, и критерий.
Во-первых, нельзя из программиста вырасти до аналитика, это профессии, у которых очень мало общего, и они не находятся на одной линейке развития.
А во-вторых, то, о чем говорит автор, к реальному анализу, применяемому при разработке ПО, имеет чрезвычайно малое отношение.
А во-вторых, то, о чем говорит автор, к реальному анализу, применяемому при разработке ПО, имеет чрезвычайно малое отношение.
Спасибо за разъяснения. Теперь мне хоть немного стал ясен изначальный замысел этого цикла статей. Да, видимо,
По поводу
Заказчик, скорее всего, так и формулирует условия. Но до программиста это не должно доходить в таком виде. Кто то должен переварить это и выдать на-гора нечто вроде:
— Когда уровень освещенности становится меньше 1 лк освещение должно быть включено.
— Когда время смыкания век водителя становится больше 0.5 с торможение должно быть активировано на уровне достаточном для обеспечения замедления величиной в 5,5 м/с2
— Когда показания датчика веса установленного под рабочем местом кассира становятся ниже 5 кг на протяжении 2 с кассовый аппарат должен быть заблокирован.
На точность этих требований не претендую. Но они реализуемы. Кроме того, продукт с такими требованиями может пройти испытания по результатам которых он будет принят или не принят заказчиком. И никто не будет гадать, а село ли Солнце или еще не совсем, уснул ли водитель или слегка задремал, ну и, наконец, встал ли кассир с кровати или еще откуда.
Кто должен заниматься созданием такого рода требований и моделированием систем на их основе?
нельзя из программиста вырасти до аналитика
По поводу
«Солнце село», «водитель уснул», «кассир встал» — вполне достаточные условия для того, чтобы включить освещение, принудительно активировать торможение транспортного средства или заблокировать кассовый аппарат.
Заказчик, скорее всего, так и формулирует условия. Но до программиста это не должно доходить в таком виде. Кто то должен переварить это и выдать на-гора нечто вроде:
— Когда уровень освещенности становится меньше 1 лк освещение должно быть включено.
— Когда время смыкания век водителя становится больше 0.5 с торможение должно быть активировано на уровне достаточном для обеспечения замедления величиной в 5,5 м/с2
— Когда показания датчика веса установленного под рабочем местом кассира становятся ниже 5 кг на протяжении 2 с кассовый аппарат должен быть заблокирован.
На точность этих требований не претендую. Но они реализуемы. Кроме того, продукт с такими требованиями может пройти испытания по результатам которых он будет принят или не принят заказчиком. И никто не будет гадать, а село ли Солнце или еще не совсем, уснул ли водитель или слегка задремал, ну и, наконец, встал ли кассир с кровати или еще откуда.
Кто должен заниматься созданием такого рода требований и моделированием систем на их основе?
Созданием требований занимаются аналитики (если мы говорим о функциональных требованиях). А вот построением модели — когда как. Для требований нужна одна модель (и, на самом деле, в разных требованиях — разная), для проектирования системы — уже другая (и тоже не одна).
Попробуйте прочитать статью, в которой на примере термина договор я рассказываю про то, как видят мир программисты. Возможно, будет интересно и полезно
Все зависит от программиста, электроника, желаемого результата и результатов проработки.
Кто-то в любом случае должен определиться с требованиями — быть может солнце заходит по расписанию, водитель считается заснувшим, когда собирается выехать на встречку, а «кассир встал» — имеется ввиду прекращение авторизованного доступа технического персонала к материальным ценностям и должно учитывать вариант, когда кассира вытаскивают из-за стула, а на его место ставят гирю…
Точность и неизбыточность требований — вот вотчина аналитиков, как мне видится этот вопрос. И в любом случае кто-то будет разбираться с подсистемой, которая отвечает на вопросы вида «когда солнце считается севшим, человек вставшим а водитель заснувшим». По большому счету можно это считать чуть ли не отдельным проектом со своим заказчиком, своим аналитиком и своим исполнителем. В случае выхода за пределы изначальной детализации, все эти роли оказываются сосредоточенными в руках конечного исполнителя:
— Можно ли доверять датчику освещенности настолько, чтобы замерять ровно 1лк? или лучше учесть погрешность в его работе и включать свет уже при 1.2лк?
— Что делать со временем смыкания век водителя, если он, негодяй такой, взял и отвернулся от камеры, а камера считает, что он закрыл глаза?
— Стоит ли учитывать вес стула, который стоит на рабочем месте кассира, как нулевую точку отсчета или забить до того момента, как кто-нибудь не решит ставить кассирам шестикилограммовые стулья?
Часто это можно решить сразу и угадать. А часто можно и не угадать — порой достаточно сложно понять, почему аналитик взял те или иные цифры и какого эффекта он ожидает на самом деле.
Кто-то в любом случае должен определиться с требованиями — быть может солнце заходит по расписанию, водитель считается заснувшим, когда собирается выехать на встречку, а «кассир встал» — имеется ввиду прекращение авторизованного доступа технического персонала к материальным ценностям и должно учитывать вариант, когда кассира вытаскивают из-за стула, а на его место ставят гирю…
Точность и неизбыточность требований — вот вотчина аналитиков, как мне видится этот вопрос. И в любом случае кто-то будет разбираться с подсистемой, которая отвечает на вопросы вида «когда солнце считается севшим, человек вставшим а водитель заснувшим». По большому счету можно это считать чуть ли не отдельным проектом со своим заказчиком, своим аналитиком и своим исполнителем. В случае выхода за пределы изначальной детализации, все эти роли оказываются сосредоточенными в руках конечного исполнителя:
— Можно ли доверять датчику освещенности настолько, чтобы замерять ровно 1лк? или лучше учесть погрешность в его работе и включать свет уже при 1.2лк?
— Что делать со временем смыкания век водителя, если он, негодяй такой, взял и отвернулся от камеры, а камера считает, что он закрыл глаза?
— Стоит ли учитывать вес стула, который стоит на рабочем месте кассира, как нулевую точку отсчета или забить до того момента, как кто-нибудь не решит ставить кассирам шестикилограммовые стулья?
Часто это можно решить сразу и угадать. А часто можно и не угадать — порой достаточно сложно понять, почему аналитик взял те или иные цифры и какого эффекта он ожидает на самом деле.
Как я вижу профдеформацию программистов? Программируя, они часто забывают о том, что они на самом деле делают. Если программист создает информационную систему, то через некоторое время он забывает, что создаваемые им сущности — информационные объекты, несущие информацию о предметной области. Сами информационные объекты в воображении программиста становятся объектами предметной области. Это верно, если он занимается моделированием информационных объектов системы, а не объектов предметной области. Но, моделирую информационные объекты, он связывает их жесткой связью с объектами предметной области. И с этого момента он становится непригодным как аналитик предметной области, да и как системный аналитик — тоже. Если же он, глядя на таблицу под названием договора, будет видеть записи таблицы, хранящие информацию о классе объектов, каждый из которых (объектов) — есть экземпляр договора, то шанс быть аналитиком у него есть. Кроме того, он должен знать ограничения тех инструментов моделирования, которые он использует в работе. Но этого часто не знают и сами аналитики(.
Не без этого. Хотя точка зрения на это отличается. Быть может только терминологически,
Сущности не создаются а описываются, поскольку они то как раз и приходят из модели предметной области. К примеру в данной статье, что я к ней так прицепился, описывается модель с состояниями и процессами — каждая сущность в ней описывается не только состоянием, но и временем ( ошибочно называть ее 4д, поскольку на практике в ней только два измерения ). Добавление временного измерения накладывает огромные накладные расходы в стандартную модель проектирования, где все изменения и события сугубо атомарны, однако, потенциально оно рождает новые возможности — если удастся представить процессы в удобоваримой форме. Это как минимум позволит перейти от учета к планированию и прогнозированию, не меняя модели, а только лишь делая выводы из уже существующей.
И во вторых — воображения программиста. Для профдефармированного программиста, это сугубо что ни на есть субъективная реальность, которую программист пытается свести к внутренне непротиворечивому состоянию. Лично мне любая модель, которая может стать противоречивой, доставляет физический дискомфорт. То есть любая заплатка или костыль, которая встраивается в систему, должна или иметь границы применимости, по достижении которых эта заплатка должна быть заменена новой, или предоставлять обратную связь о своей эффективности, чтобы при снижении оной быть замененным.
При общении с аналитиками, кто бы ни выступал в их роли, наибольшую боль доставляет именно нелогичность требований. Причем нелогичность не в плане булевой логики, не в плане абстрактной логики со «шмакодявками»( известный тест на логику ), а именно отход от реализованной логики модели. Поэтому я стараюсь заложить заранее в свою голову некую потенциальную идеальную модель, которая позволяет реализовывать произвольные хотелки, чтобы знать, что делать с требованиями вида «когда рак на горе свистнет».
К сожалению на данный момент в моей модели ахиллесова пята — это процессы, некие неатомарные события. Их можно представить в виде череды событий, но это требует слишком много системных ресурсов.
Сущности не создаются а описываются, поскольку они то как раз и приходят из модели предметной области. К примеру в данной статье, что я к ней так прицепился, описывается модель с состояниями и процессами — каждая сущность в ней описывается не только состоянием, но и временем ( ошибочно называть ее 4д, поскольку на практике в ней только два измерения ). Добавление временного измерения накладывает огромные накладные расходы в стандартную модель проектирования, где все изменения и события сугубо атомарны, однако, потенциально оно рождает новые возможности — если удастся представить процессы в удобоваримой форме. Это как минимум позволит перейти от учета к планированию и прогнозированию, не меняя модели, а только лишь делая выводы из уже существующей.
И во вторых — воображения программиста. Для профдефармированного программиста, это сугубо что ни на есть субъективная реальность, которую программист пытается свести к внутренне непротиворечивому состоянию. Лично мне любая модель, которая может стать противоречивой, доставляет физический дискомфорт. То есть любая заплатка или костыль, которая встраивается в систему, должна или иметь границы применимости, по достижении которых эта заплатка должна быть заменена новой, или предоставлять обратную связь о своей эффективности, чтобы при снижении оной быть замененным.
При общении с аналитиками, кто бы ни выступал в их роли, наибольшую боль доставляет именно нелогичность требований. Причем нелогичность не в плане булевой логики, не в плане абстрактной логики со «шмакодявками»( известный тест на логику ), а именно отход от реализованной логики модели. Поэтому я стараюсь заложить заранее в свою голову некую потенциальную идеальную модель, которая позволяет реализовывать произвольные хотелки, чтобы знать, что делать с требованиями вида «когда рак на горе свистнет».
К сожалению на данный момент в моей модели ахиллесова пята — это процессы, некие неатомарные события. Их можно представить в виде череды событий, но это требует слишком много системных ресурсов.
Насчет непротиворечивости моделей. Непротиворечивость рождается на основе непротиворечивого базиса. Пока программисты пользовались быстрыми методами проектирования и реализации, которые (методы) имеют внутренние противоречия. В своих статьях я пытаюсь вслед за Крисом Партриджем описать эти противоречия. И пытаюсь познакомить читателя с подходом, лишенным этих противоречий. Однако, как Вы правильно заметили, ресурсы на создание моделей и кода на основе этой методологии — огромны. У Криса ест ьрисунок в его книге, которую я рекомендую всем прочитать, тех затрат, которые требуются на создание непротиворечивой модели и тех кейсов, при которых эта модель себя окупает.
Вот именно поэтому программист и аналитик — это две роли, и совмещать их в одном человеке настоятельно не рекомендуется.
И менеджера отдельно, чтобы он выяснял настоящие желания заказчика. И рассказывал о том, как система будет решать его потребности — еще одна немаловажная роль.
Настоящие желания заказчика выясняет именно аналитик. Менеджер занимается согласованием их приоритетов и управлением работой.
(под «выяснением настоящих желаний» я понимаю переход от «добавьте мне вот тут одно поле» к «для выполнения такого-то закона необходимо учитывать еще и вот такие характеристики объектов учета таким-то образом»)
(под «выяснением настоящих желаний» я понимаю переход от «добавьте мне вот тут одно поле» к «для выполнения такого-то закона необходимо учитывать еще и вот такие характеристики объектов учета таким-то образом»)
Я заметил одну важную деталь в Ваших рассуждениях, на которую хочу обратить внимание. Вы просите определить требования. когда водитель считается уснувшим. Это абсолютно законное желание. Однако, Вы забываете указать интервал значений, при которых переход из одного состояния в другой будет считаться выполненным. Допуск — вот что Вы забыли. А он как раз решает философский вопрос о том, что есть событие? Если ввести допуск, то момент времени превратится в интервал времени. То есть водитель считается уснувшим не в момент времени, а в интервале времени. И так со всеми событиями. Кроме того, надо добавить погрешности измерений. И тогда на сцену появляется новый игрок — вероятность получения достоверных данных на основе проведенных испытаний. И это делает наш интервал не просто интервалом, но еще и вероятностным интервалом.
>>Цели я обозначил сразу — неудовлетворенность существующими методами моделирования предметной области и тотальное невежество
Может быть уточните само понятие — цель. То что мы видим — это же не цель! После этого хотелось бы саму Вашу цель осознать
Может быть уточните само понятие — цель. То что мы видим — это же не цель! После этого хотелось бы саму Вашу цель осознать
Я потратил около 10 лет на попытку понять некоторые вещи. Оказалось, что существующий state of art бизнес-анализа не способен ответить на мои вопросы. Мне понадобилось еще 2 года, чтобы самостоятельно ответить на них. Теперь у меня есть запрос от коллег по цеху, которые просят описать эту позицию в виде текста, а не в виде устного творчества. Я выполняю этот запрос.
С целью — то что? Ответа не будет?
Цели имеют иерархическую структуру. Есть цель пописать. Она разбивается на цели: найти туалет и цель — успеть до него добежать. Но цель пописать возникает из желания выжить. И так далее. Вы скажите, какого уровня цель вы имеете ввиду?
>>Цели я обозначил сразу — неудовлетворенность существующими методами моделирования предметной области и тотальное невежество
>>Вы скажите, какого уровня цель вы имеете ввиду?
Я имею ввиду те цели и того уровня, который Вы обозначили сразу.
Мой вопрос не структуре цели, а о том что это такое для Вас- целью называется…
>>Вы скажите, какого уровня цель вы имеете ввиду?
Я имею ввиду те цели и того уровня, который Вы обозначили сразу.
Мой вопрос не структуре цели, а о том что это такое для Вас- целью называется…
Попробую зафиксировать некоторые комментарии по ходу чтения:
Вроде изначально подразумевалось, что речь идет об одном и том же экстенте, но далее по тексту этот вопрос как-то замалчивается. Вопрос: событие (ширина во времени равна нулю, конечно, в изложении субъекта) и операция (с временными границами) — это про один и тот же экстент? Если про один, то возникает законный вопрос, как мы будем формализовать фразу "ширина экстента во времени равна с точки зрения рассказчика нулю"?
Здесь одним термином «субъективное» обозначены два понятия: «личное оценочное» (мнение, суждение) и «распознаваемое с позиции субъекта» (событие, предикат, функция и пр.). Трактовка экстента с той или иной точки зрения — это не оценка факта, а сам факт: факт фиксации функции объекта в том или ином действии, что может быть сделано даже без участия субъекта. Если и упоминать субъекта, то использовать вместо слова «субъективная» термин «субъектная» — два понятия, два термина. Хотя первое понятие, на мой взгляд, тут совсем лишнее.
Не думаю, что объяснение через приблизительность модели, тут может оправдать неопределенность выделения момента события. Ведь в реальности все события (сработал автомат, увидел свет маяка) именно мгновенны. Да, есть переходные процессы, но всегда есть момент фиксации события, момент переключения. И если стоит задача выделения события в реальности, то момент фиксируется точно по остановке секундомера. Поэтому я считаю, что ваша картинка «реальность» неверна, ведь и в реальности мы имеем дело не с неким переходным процессом приведшим к событию, а именно с самим событием. Поэтому как в реальности, так и в модели событие должно определяться только через понятие «фиксация»: кто и что зафиксировал.
Вот и выползают проблемы вашего описания события. Посадим человека (или прибор) перед помидором и попросим его зафиксировать событие перехода из состояния «зеленый» в «красный». Наблюдатель ведь когда-то примет решение — вот теперь красный — и это будет событие. И для моделирования нам нужен/важен именно момент (пора рвать), а не констатация наличия перехода. И еще раз убеждаемся, что событие — это не нечто происходящее с объектом, а нечто между объектами, а чаще между субъектом и объектом (хотя можно сказать и «всегда», если в любом событии один объект принять за субъект, а второй за объект).
И даст простой ответ: а как условимся фиксировать, так и будет (хоть датчик на двери, хоть открытие формы ввода данных секретарем или по нажатию клавиши Enter) ведь практически всегда нам нужно не абсолютное значение времени события, а наличие события и его положение во времени относительно других событий — плюс минус несколько секунд/минут тут не играет роли (будет играть — пересмотрим условия фиксации).
Далее мы называем экстент тем, чем мы хотим его представить
Вроде изначально подразумевалось, что речь идет об одном и том же экстенте, но далее по тексту этот вопрос как-то замалчивается. Вопрос: событие (ширина во времени равна нулю, конечно, в изложении субъекта) и операция (с временными границами) — это про один и тот же экстент? Если про один, то возникает законный вопрос, как мы будем формализовать фразу "ширина экстента во времени равна с точки зрения рассказчика нулю"?
Мы часто сталкиваемся с описание субъективной оценки вместо описания… Субъективная трактовка экстента – это...
Здесь одним термином «субъективное» обозначены два понятия: «личное оценочное» (мнение, суждение) и «распознаваемое с позиции субъекта» (событие, предикат, функция и пр.). Трактовка экстента с той или иной точки зрения — это не оценка факта, а сам факт: факт фиксации функции объекта в том или ином действии, что может быть сделано даже без участия субъекта. Если и упоминать субъекта, то использовать вместо слова «субъективная» термин «субъектная» — два понятия, два термина. Хотя первое понятие, на мой взгляд, тут совсем лишнее.
Все наши описания – это лишь некие приблизительные модели, описывающие реальные объекты довольно упрощенно.
Не думаю, что объяснение через приблизительность модели, тут может оправдать неопределенность выделения момента события. Ведь в реальности все события (сработал автомат, увидел свет маяка) именно мгновенны. Да, есть переходные процессы, но всегда есть момент фиксации события, момент переключения. И если стоит задача выделения события в реальности, то момент фиксируется точно по остановке секундомера. Поэтому я считаю, что ваша картинка «реальность» неверна, ведь и в реальности мы имеем дело не с неким переходным процессом приведшим к событию, а именно с самим событием. Поэтому как в реальности, так и в модели событие должно определяться только через понятие «фиксация»: кто и что зафиксировал.
Например, есть состояние помидор зеленый и состояние помидор красный. Переход между этими состояниями и есть событие.
Вот и выползают проблемы вашего описания события. Посадим человека (или прибор) перед помидором и попросим его зафиксировать событие перехода из состояния «зеленый» в «красный». Наблюдатель ведь когда-то примет решение — вот теперь красный — и это будет событие. И для моделирования нам нужен/важен именно момент (пора рвать), а не констатация наличия перехода. И еще раз убеждаемся, что событие — это не нечто происходящее с объектом, а нечто между объектами, а чаще между субъектом и объектом (хотя можно сказать и «всегда», если в любом событии один объект принять за субъект, а второй за объект).
Например, аналитик может поставить вопрос: «Что есть событие «клиент пришел?»
И даст простой ответ: а как условимся фиксировать, так и будет (хоть датчик на двери, хоть открытие формы ввода данных секретарем или по нажатию клавиши Enter) ведь практически всегда нам нужно не абсолютное значение времени события, а наличие события и его положение во времени относительно других событий — плюс минус несколько секунд/минут тут не играет роли (будет играть — пересмотрим условия фиксации).
как мы будем формализовать фразу «ширина экстента во времени равна с точки зрения рассказчика нулю»?
Я нашел таки статью Колмогорова о геометрических точках. О той же проблеме, но в геометрии:
Поймите, я задаю исключительно прагматические вопросы, а вы все пытаетесь перевести разговор на уровень мировоззрения и общих понятий.
Вопрос был о том, как мы в системе должны зафиксировать ситуацию «ширина экстента во времени равна с точки зрения рассказчика нулю»? Где в системе рассказчик? И как указать его взгляд на ширину экстента? Как зафиксировать, что у других рассказчиков будет другая длина экстента? Тем более, что никакого упоминания, что у нас время хоть как-то отличается от физического не было.
Вопрос был о том, как мы в системе должны зафиксировать ситуацию «ширина экстента во времени равна с точки зрения рассказчика нулю»? Где в системе рассказчик? И как указать его взгляд на ширину экстента? Как зафиксировать, что у других рассказчиков будет другая длина экстента? Тем более, что никакого упоминания, что у нас время хоть как-то отличается от физического не было.
Я абсолютно серьезно комментирую. Все эти вопросы были у меня, когда я разбирал задачу. И это не спонтанные решения. Они выстраданы не одним годом рассуждений. Задайте себе вопрос о том, как мы определяем вершину пирамиды Хеопса. Где она? есть ли у нее размер? Если нет, то как определить ее абсолютно точно?
Я абсолютно серьезно комментирую.Я понимаю, что вы не шутите ))).
Наверное, именно потому, что вы все продумали, вы и пропускаете звенья объяснения. Для вас все ясно и вы выдаете готовый конечный результата или отсылаете к исходной точке размышлений. Но я-то не вижу этих ваших страданий и многолетнего восхождения.
И что получается? Я задаю вопрос: «как мы будем формализовать фразу «ширина экстента во времени равна с точки зрения рассказчика нулю»?». А в ответ получаю: «Я нашел таки статью Колмогорова о геометрических точках» и еще подумайте над тем " как мы определяем вершину пирамиды Хеопса".
Это даже не про бузину и дядьку, а гораздо круче. Я понимаю, что проблема во мне, что я не вижу связи между абстрактными понятиями, пирамидой и решением конкретной технической проблемы (фиксации в онтологии мнения рассказчика). Но ведь поэтому и задаю вопрос. А в ответ получаю: читайте Колмогорова. ))
как мы будем формализовать фразу «ширина экстента во времени равна с точки зрения рассказчика нулю»?
Мне показалось, что Колмогоров говорит о том же. Как мы будем формализовать вершину треугольника, если вершина — это физический объект. Он не может быть точкой. Поэтому все рассуждения Колмогорова о физической точке перекладываются на рассуждение о событии. Как формализовать объект с нулевой шириной по времени, если в природе мы такого не встречаем. В природе мы не способны воспринимать нулевую ширину по времени. Всегда только объем. Также не можем воспринимать точку — всегда только объем. Точка и событие — это идеализация нашего опыта, пренебрежение чем-то чем можно пренебречь с точки зрения решаемой задачи
Наверное, тут моя вина, я не смог донести до вас суть проблемы. Вы скорее всего, в своих размышлениях не опускаетесь на уровень формальной реализации. А меня интересуют сугубо прикладные моменты — мне надо работающую систему проектировать.
Итак, есть некая система, есть экстент, есть два субъекта («рассказчика»), для одного ширина экстента во времени равна нулю (с его точки зрения), для другого — не равна. Как мы это запишем? как зафиксируем? как с этим будем оперировать?
Итак, есть некая система, есть экстент, есть два субъекта («рассказчика»), для одного ширина экстента во времени равна нулю (с его точки зрения), для другого — не равна. Как мы это запишем? как зафиксируем? как с этим будем оперировать?
Как мы это запишем? как зафиксируем? как с этим будем оперировать?
Также как в черчении пишем границу здания — линией обозначаем то, чего нет в природе: плоскость фасада. Формализм тот же.
Так у нас на чертеже будет две линии? Одна тонкая для одного субъекта и вторая широкая для другого? Повторю вопрос:
есть два субъекта («рассказчика»), для одного ширина экстента во времени равна нулю (с его точки зрения), для другого — не равна. Как мы это запишем?
Есть фасад здания. Для одного — это плоскость. Для другого — поверхность очень сложной формы, а для третьего — электромагнитное поле без четких границ. Как мы запишем это? Мы возьмем точку зрения субъекта и запишем, все, что он нам сообщит о фасаде. Точно также мы запишем все. что сообщит нам субъект об экстенте.
Следует ли считать, что ваш ответ означает, что мы должны иметь столько моделей системы, сколько имеется разных точек зрения? Существование разных точек зрения (для одного субъекта договор это бумажка, для другого — файл) в одной модели исключается.
Любая модель начинается с определения точки зрения. Как только появляется другая точка зрения, — это приводит нас к необходимости создания нового представления новой модели. В ИС это часто можно видеть в примерах планирования проектов. Есть точка зрения верхнеуровневого планирования, есть подробного. Для обеих точек зрения разрабатывается две модели, расчет идет для каждой отдельно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Физические и функциональные объекты (Продолжение)