Можно ли войти в одну реку дважды?
Данная статья написана по результатам доклада на конференции Нефтегазстандарт – 2016, сделанная мной от имени компании ТриниДата.
Работая инженером — онтологом, я занимаюсь созданием информационных моделей для информационных систем.
В этой статье я хочу рассказать о практике применения стандарта ИСО 15926 к моделированию активов предприятия, и о том, к каким результатам это привело нас в итоге. Те, кто незнаком со стандартом, могут не расстраиваться — чтение статьи будет полезно независимо от знания стандарта.
Проблемы моделирования активов
- Построение модели активов предприятия до сих пор является сложной и нетривиальной задачей. На мой взгляд, эта сложность обусловлена разрывом между методиками моделирования и обычным человеческим мышлением. Например, ни в логике Аристотеля ни в матлогике вы не найдете ничего похожего на термин «инстанс». Однако программисты и аналитики очень часто употребляют это слово, не удосуживаясь объяснить его смысл. Лично я нигде не нашел определение этого термина.
- Одной из наиболее удачных методик моделирования активов можно назвать стандарт ИСО 15926. В нем сделано революционное предположение, что для моделирования предприятия можно пользоваться временем как четвертой координатой наравне с обычными пространственными координатами. Этот подход позволил моделировать полный жизненный цикл активов. Однако с помощью данного стандарта пока не удалось создать универсальную метамодель для описания деятельности предприятия. Собственно создатели этого стандарта не ставили перед собой этой задачи.
- Для моделирования деятельности предприятия предложено множество стандартов, например, стандарт ArchiMate. По заявлениям его разработчиков этот стандарт дружественен стандарту ISO 15926 и методологии моделирования архитектуры предприятий TOGAF. Несмотря на заявленные возможности, этот стандарт не вполне справился с поставленными задачами. Одна из причин этого – отсутствие разграничения между понятиями «деятельность» и «активность» (деятельность подразумевает целенаправленные усилия по достижению результата. Активность же трактуется как происходящее, которое независимо от воли субъекта). Чтобы лучше понять возникающую трудность, вспомните, как древние греки трактовали «а» в квадрате? Они не мыслили это иначе как площадь квадрата со сторонами длиной а. То же можно сказать про куб – объем куба со сторонами длиной «а» записывался как «а» в кубе. Но, поскольку нельзя придумать физический аналог «а» в четвертой степени, уравнения выше кубических в Древней Греции не рассматривались. И так было до тех пор, пока в средние века алгебраисты не оторвали уравнения от физического смысла. Начавшаяся эра чистой математики не искала физических аналогов уравнениям. Ровно то же происходит в бизнес-анализе. Рассмотрение происходящего только под одним углом зрения (как деятельность), сильно ограничивает наши аналитические возможности.
- В стандарте ISO 15926 также присутствует ценная возможность моделировать объекты разных типов (например, функциональные и физические), а также пересечения этих объектов во времени. Однако набор возможных типов объектов жестко определен стандартом, и в некоторых практических случаях его оказывается недостаточно для создания модели, адекватно отражающей представления об объекте, событии или процессе. Например, в стандарте нет объектов типа «производственный ресурс».
Постановка задачи
Последняя моя работа была связана с Самарским заводом нефтяного резервуарного оборудования.
Заказчик пожелал создать информационную систему, которая помогала бы менеджеру по продажам взаимодействовать с клиентом наиболее эффективным способом. Для этого менеджер должен быть обеспечен всей необходимой информацией, которая включает в себя:
- Модель функциональных требований (что нужно клиенту?)
- Модели возможных решений (как могут быть удовлетворены функциональные требования?)
- Модель себестоимости выполнения заказа
- Модель рисков
- Модель отношений с клиентом
Для решения поставленной задачи фактически понадобилось создать модель всего предприятия, начиная от модели активов, заканчивая моделью деятельности.
В качестве идеологической основы для создания модели был взят стандарт ИСО 15926.
Стандарт великолепно справляется с задачей описания жизненного цикла активов, моделирования функциональных и физических объектов, а также их пересечения. Однако для создания полноценной модели предприятия возможностей этого стандарта оказалось недостаточно.
Для описания деятельности предприятия можно было взять нотацию ArchiMate.
Но она не подошла по причинам, сказанным ранее – в ней нет дифференциации между моделью деятельности и моделью активности. Кроме того в ней нет точного описания того, что такое бизнес-функция, как она связана с операциями и процессами. Для решения этой задачи в стандарте необходимо было бы разделить два значения одного и того же вопроса: «Это один и тот же объект?» в смысле тот же самый объект? или это похожие объекты? К сожалению, в стандарте не делается различие межу этими двумя разными значениями этого вопроса, поэтому нет возможности построить модель деятельности корректно: две бизнес-операции признаются одним объектом в смысле похожи друг на друга, но две бизнес-функции признаются одним объектом, если они реально совпадают. Нельзя в одной модели путать эти вопросы.
Далее мы продолжили уже самостоятельно работать над созданием модели деятельности. В процессе этой работы мы с удивлением обнаружили единый шаблон, который позволяет нам моделировать не только деятельность, но и стоимости, функциональные и физические объекты. Причем способ моделирования этих сущностей оказался универсальным. Этот способ можно было использовать где угодно!
Далее я расскажу об этом способе более подробно.
Решение
Новое понятие, которое нам понадобилось, — это точка зрения. Рассмотрим насос в качестве примера актива.
С точки зрения инженера – это функциональный объект, с точки зрения бухгалтера или экономиста – производственный актив. Способ восприятия объекта зависит от бизнес-функции, в которой участвует субъект, строящий модель. Поэтому мы вводим понятие «точка зрения» и говорим об интерпретации объекта в рамках определенной точки зрения. Например то, что данный предмет интерпретируется инженером, участвующим в эксплуатации нефтепровода, как насос, финансистом, участвующим в согласовании бюджета интерпретируется как производственный актив, а сотрудником охраны предприятия – как материальный объект, который необходимо охранять от хищения, зависит от точки зрения на объект.
Второе понятие, которое нам понадобилось, — это конструкция. Рассмотрим конструкцию человеческого организма.
Нам известны как минимум две разные точки зрения. С одной точки зрения организм состоит из рук, ног, туловища и головы. С другой точки зрения – из костно-мышечного аппарата, нервной, кровеносной, дыхательной и пищеварительной систем. Можно придумать и представить себе множество других способов представления организма человека в виде конструкции. То, что верно для человеческого тела, верно и для активов. Рассмотрим, например, буровую установку.
В зависимости от функции, в которой участвует субъект, он увидит разную ее конструкцию.
Один увидит множество агрегатов, а другой – множество подсистем. При этом таких разбиений можно сделать сколь угодно много.
Для моделирования такого разнообразия понятие «конструкция» нам необходимо наравне с понятием «объект».
Глядя на полученные результаты, мы пришли к выводу, что не существует физических и функциональных объектов. Есть множество областей человеческой деятельности, каждая из которых порождает свою точку зрения и свои модели. Можно сделать модели исходя из каждой такой точки зрения, и описать матрицы переходов от одной модели к другой. То, как это сделано в стандарте ИСО 15926:
После этого можно двигаться от одного представления к другому, меняя точки зрения. Это позволяет в одном информационном хранилище хранить информацию о моделях, которые созданы разными людьми с разными целями.
В стандарте ИСО 15926 описан способ построения хранилища данных, в котором учтены только две точки зрения: точка зрения на физический мир и точка зрения на функциональные объекты. В нем также описан способ перехода от одного представления к другому через темпоральные части. То есть можно получить ответ на вопрос: какие физические объекты исполняли роль данного функционального и когда? Можно получить ответ и на обратный вопрос: какие функциональные объекты исполнял тот или иной физический объект? Ответ на эти вопросы и есть способ перехода от одного представления к другому. Однако, введя понятие «точка зрения» мы теперь не ограничены только двумя точками зрения. Теперь мы можем создавать столько точек зрения, сколько нам надо для наших целей моделирования.
Максимальную выгоду от такого подхода к моделированию можно получить, рассмотрев и саму деятельность предприятия как объект, имеющий конструкцию.
С одной точки зрения конструкцию операции можно представить пространственно в виде набора ролей, а с другой стороны темпорально в виде набора подопераций — сценария.
Таким образом, фреймворк для описания архитектуры предприятия основывается на понятиях: точка зрения, объект и конструкция. Это позволяет создавать информационные модели, которые не требуют структурной переделки в процессе эксплуатации. Например, можно создать информационную модель, в которой можно переходить с одной точки зрения к другой – например, от поставщика к заказчику, не заставляя при этом их принимать единую, общую точку зрения на каждый объект.
Так, одна и та же операция с точки зрения поставщика называется «продажа», а с точки зрения клиента – «покупка». Кстати, способность передвигаться по модели, меняя точки зрения, позволяет решить задачу сквозного учета (traceability).
За кадром нашего разговора оставим рассмотрение более сложных единиц учета: множеств, типов, атрибутов. Для завершения фреймворка описания активов необходимо внимательно рассмотреть и эти объекты.
Итоги:
Полученная метамодель обладает следующими преимуществами:
- Метамодель приближена к нашему естественному мышлению, что позволяет в случае необходимости легко ее расширить, например, введя в нее вероятности.
- Метамодель обладает универсальностью. Все, что нам нужно было смоделировать, мы смогли описать, используя данную методику.
- Дополнительным бонусом возникла возможность описания деятельностей разного типа в одном фреймворке. Например, обычная производственная деятельность и деятельность по саботажу производственной деятельности описывается единым способом в одной модели.
- Мы смогли разорвать связь между моделью и методологией ее применения. Разработчик модели теперь не обязан знать цели, с которыми будет применяться та или иная модель. Он фиксирует факты, а их интерпретацией занимаются другие субъекты. Это позволяет создавать модели с необходимым уровнем секретности.
- Метамодель предполагает такую точку зрения на предметную область, которая не требует введения предустановленным типов объектов: например, функциональных или физических. Подобные типы вводятся по мере необходимости и количество подобных типов может быть любым.
- Метамодель позволяет переходить от одного представления объекта к другому его представлению, используя при этом одну информационную модель.
- Метамодель позволяет создавать информационную модель, которая способна расширяться неограниченно. Ее расширение ограничено только объемом хранимой информации, но не логическими противоречиями, которые могли бы возникнуть по причине несогласованности данных.
Трудности в реализации модели:
- Трудность в реализации данной модели в том, что полученная в итоге модель имеет большую степень сложности и потому предъявляет высокие требования к программной реализации.
- Для создания моделей такого уровня сложности требуется дополнительное обучение специалистов.
Комментарии (85)
sakhavat
31.10.2016 13:59+1Читайте про Object Role Modeling — 100 лет в обед
maxstroy
31.10.2016 14:05Я не уверен, что есть модель данных, которая бы описывала то, что я рассказал. Наша работа была в создании именно такой модели. Что важно — создать ее в реляционной модели если и возможно, то очень громоздко и трудно. Мы используем OWL для моделирования.
sakhavat
31.10.2016 14:59+1«Точку зрения» впервые я увидел у Мартина Дж (Организация БД в вычислительных системах. Мир. 1980г.)
Хотя это вроде и тривиально сейчас выглядит (Знание Эксперта = Сумма знаний спецов) на меня это сильное произвело впечатление.
Реляционная модель должна автоматически сгенерироваться из метаданных модели (если в ней есть нужда — на сегодня эта нужда диктуется наличием мощной инфраструктуры)
.
Моделировать можно все и очень адекватно простыми расширениями имеющихся языков (нотаций) моделирования. Но что бы заставить модель исполняться (симуляция) надо немного стараться.
Жаль тут нельзя кажись вешать файлы и картинки.maxstroy
31.10.2016 20:19Расширением нотаций задачу не решить. Это я как доктор говорю. Подробности раскрывать я не могу — это и коммерческая тайна отчасти, а по большей части просто требует огромного времени на объяснение причин. Но для меня очевидно — расширение не работает.
sakhavat
31.10.2016 22:43Если мы говорим о модели предприятия, то она состоит из структурно — поведенческой и процессной модели с количественной семантикой.
Все это спокойно описывается расширением ER (по части типизации отношений) + IDEF (введением количественной семантики).
Если у вас имеется методология сопоставления целей и процессов достижения этих целей (это самое сложное по части автоматизации), то считай все в кармане.
На счет доктора. Наши профессоры в этом деле сильно разочаровывают.maxstroy
01.11.2016 06:18семейство нотаций IDEF также как BPMN, также как EPC не решают задачу в принципе. У них есть одна важная ошибка, про которую я не написал в статье, но которая сводит на нет все преимущества этих нотаций. И расширять эти нотации невозможно по причине этой ошибки. Про нее и то, как мы ее преодолели — отдельный разговор. Но в итоге мы получили нотации, совершенно непохожие на уже существующие. И то, что мы получили, не решается расширением существующих нотаций.
maxstroy
01.11.2016 06:28Версия о том, что модель предприятия состоит из структурно-поведенческой модели вызывает у меня сомнение, потому что я могу задать любой интересующий меня вопрос и должен получить на него ответ. Почему мои вопросы должны ограничиваться только этими аспектами, почему я не должен задавать вопросы, которые выходят за ее границы? Также как и в вопросе о процессной. Я скажу кощунственную вещь, но я не видел ни одной нотации, в которой описывались бы процессы. Хотя… Есть диаграмма Ганта. Она описывает процесс. Остальные нотации описывают модель моделей процессов, но не процесс.
sakhavat
01.11.2016 11:04Любой интересующий вопрос в Контексте.
Обобщенный контекст — пространство, время, материя, процесс, воля.
Просто увидел «Точка зрения» — новое понятие и не удержался дать ссылку на 1980 г., можно было и поискать до царя Соломона.maxstroy
01.11.2016 13:02волю мы не моделируем. Мы моделируем в том числе происшествия, происходящие помимо нашей воли. Это принципиальное отличие от того, что принято считать процессом. Это же касается любой технологии — например, вращения Земли вокруг Солнца, ее же никто не вращает))
sakhavat
01.11.2016 13:14Это называется ситуационное управление — для тех у кого мало воли :)
А есть еще управление ситуацией.
Различие — капитан в море управляет судно в зависимости от погоды (ситуационное управление), но некоторые капитаны управляют погодой — обеспечивают благоприятные условия для своего судна (управление ситуацией).
Ладно. Моделируйте.maxstroy
01.11.2016 14:13Мы не занимаемся вопросами управления. Такая задача не стояла — мы занимаемся инвентаризацией объектов.
maxstroy
01.11.2016 13:04новое понятие «точка зрения» присутствует в нашей информационной модели. Я не видел еще ни одной информационной модели, где присутствовал бы ID точки зрения.
sakhavat
01.11.2016 13:21Я дал ссылку на Мартина Дж. Это учебник.
Все Use case, Интервью и т.д. нацелены на выяснение Точек зрения, что бы аналитик потом эти точки слил в единую модель предметной области.maxstroy
01.11.2016 14:14Невозможно слить в одну точку зрения то, что не сливается в одну. Например, с точки зрения двух флотилий ситуация выглядит противоположным образом. Друзья и враги меняются местами
sakhavat
02.11.2016 11:50Какая еще «ситуация»?
Флотилия есть флотилия, друзья есть друзья, а враги — враги.
Все это определено заранее.
maxstroy
02.11.2016 12:07Мнение одного адмирала не совпадает с мнением другого — у них разные друзья и враги, которые меняются местами
sakhavat
02.11.2016 12:16При чем тут оценка ситуации разными ЛПР и моделирование объектов?
maxstroy
02.11.2016 12:26Потому что разные субъекты в одном и том же видят разные объекты. В процессе покупки покупатель видит покупку, а продавец — проданный товар. И эти объекты сильно отличаются друг от друга, в то время, как пространство, которое занимают эти объекты, совпадает.
Eldhenn
31.10.2016 14:09+1В чём в итоге делали модель? Архимейт не подошёл, как я понял?
maxstroy
31.10.2016 20:21Архимейт сделал две ошибки — первая он рассматривает деятельность и только ее. Часть же производственных задач не относятся к деятельности, как-то техпроцессы, например. Вторая — он не решил задачу описания деятельности, так и не связав бизнес-функцию и операцию, не поняв, что такое процесс и в чем его отличие от типового процесса.
CrazyViper
31.10.2016 21:52Часть же производственных задач не относятся к деятельности, как-то техпроцессы, например.
Техпроцессы — это то что автоматизированно? Если да, то это вполне себе деятельность, которая в архимейте будет представлена бизнес-функцией или бизнес-процессом, а в связке со слоем Application и\или Technology будет реализовываться конкретным софтом\автоматом.maxstroy
01.11.2016 06:12деятельность — это психическая функция субъекта. Нас часто не интересуют психические функции субъектов, часто нам интересны проявления законов природы, которые приводят нас к тем или иным решениям, например, камень падает на землю и мы используем это в нашей технологии. Разница в вопросах, которые мы задаем при этом. Деятельность везде ищет акторов, активность — участников. Разница гигантская, но не осознаваемая большинством аналитиков, в том числе не осознаваемая создателями Архи.
Eldhenn
31.10.2016 22:22> Часть же производственных задач не относятся к деятельности, как-то техпроцессы, например
Эээ. Не уверен, что понял.maxstroy
01.11.2016 06:13Деятельность — это психическая функция субъекта, я же не моделирую психические функции. Мне интересны факты, в которых нет места психическим функциям человека. Меня интересуют технологии, в которых субъект выполняет роль механизма, а не творца.
sakhavat
02.11.2016 11:17Описание такой схемы я уже приводил
Процесс, Процессор, Вход, Выход
Процессор — это то что вам нужен
Процессором может быть любой Ресурс (актив ваш)
Процессоры бывают (как минимум):
Активные
Пассивные
Мобильные
— Активно мобильные
— Пассивно мобильные
Стационарные
Разделяемые
…
Все это и много чего реализовано в ВИП.Производство, которая опирается на платформу моделирования предметной области ВИПРОС.maxstroy
02.11.2016 12:05Есть большая разница между описание активности и описанием деятельности. В деятельности есть актор, который что-то делает, есть входы и выходы. В описании активности нет ни входов, ни выходов, ни акторов. Но есть участники. Далее с моделью участников можно строить модели входов и выходов. Но это уже другая модель, которую мы не рассматриваем. Ровно как и процессы — нас не интересует их классификация. Нас интересуют только факты без их интерпретации. Интерпретация фактов производится при переходе от фактов к точке зрения на факты, но не ранее
sakhavat
02.11.2016 12:21Какая та каша. Я вообще то классифицировал Процессоры (акторы, участники и т.д. в вашем понимании), а не Процессы.
Неужто вы думаете что «актор» отличается от «участник» пока не даны определения?
Что такое «факт» без интерпретации? Как он становится фактом, а не абракадаброй (раз нет интерпретации факта в каком то контексте)?maxstroy
02.11.2016 12:29Вход — это интерпретация, участник — нет. Мы видим, что железяка участвовала в операции. Мы можем сказать, что с одной точки зрения железяка была входом в операцию, с другой — выходом из операции. Мы констатировали тот факт, что железяка была, но интерпретировать ее как вход или выход мы не стали, потому что это не наше дело.
sakhavat
02.11.2016 12:35Послушайте.
Операция, Вход и т.д. имеет свое определение. И каждая Железяка в Этой Операции имет свою Роль — Вход, выход, Процессор.
Другого не дано.
Если у вас Операция определено с одной Ролью — Участники, то и фиг с ним. Все у вас ВСЕГДА будут Участниками и никаким образом Входом и т.д., так как не существует в вашей концептуальной модели таких концептов.maxstroy
02.11.2016 12:42Да, для моделирования активов нам не нужны ни акторы, ни входы ни выходы. Тот или иной участник станет входом, или выходом в зависимости от смотрящего на это субъекта. Надо — мы смоделируем любую точку зрения на операцию, не надо — не будем, но всю необходимую для трассировки информацию, мы имеем без привлечения лишних сущностей типа актор, вход и выход. Это лишняя информация, загрязняющая модель. И именно такую нотацию мы и разработали.
sakhavat
02.11.2016 12:47Ну, ну.
Ну написали вы учет складской (если считать что они тоже участники, но стационарные) с перемещениями «Участников», а говорите про какие то страшные вещи :)
maxstroy
02.11.2016 12:53нет, опять не то. У нас есть время, как часть модели. И оно моделирует изменения. Просто мы не интерпретируем эти изменения ради поклонения богу деятельности.
maxstroy
02.11.2016 12:15В одной точке зрения входом может быть один объект, а выходом — другой, а с другой точки зрения — эти объекты меняются местами, вход становится выходом, а выход — входом. Простой пример такого переворота я приводил в одной из статей, когда все менялось в зависимости от того, что считалось входом и выходом — объект на полке, или пустое место на полке. Понятно, что пустое место «движется» навстречу" объекту. И в зависимости, что мы учитываем — пустые места на складе, или объекты, хранимые там, входы и выходы будут меняться местами. Поэтому бессмысленно говорить о входах и выходах, потому что это субъективная интерпретация существующих фактов
sakhavat
02.11.2016 12:28Каша в башке.
Есть Процесс хранения.
Есть на входе Объект.
На выходе Объект.
Есть Процесс Установки Объект на Полку.
Где имеется Активность Процессоров Устанавливающего Объект на Полку и Полка.
Процесс блокирует мощность процессоров. Какая та часть мощности Полки будет заблокировано Объектом пока его не уберут.maxstroy
02.11.2016 12:33как я сказал, нас не интересуют входы и выходы, потому что это другая модель. Нас интересуют только участники операции. Интерпретировать, кто из участников был входом, а кто выходом, — мы оставляем на долю того, кому это интересно. Для моделирования активов предприятия — это ненужная задача.
sakhavat
02.11.2016 12:42Да вы даже не дали определение «актива» и «предприятия».
И ваще непонятна цель моделирования активов :)maxstroy
02.11.2016 12:51под активом понимается все, что требует учета: операции, функциональные объекты, физические лица, должности, события и прочее. Я называю это единицами учета, но для пущей важности мы сделали более распространенное название — актив предприятия. Просто потому что в частном случае этими же принципами описываются активы в общепринятом их смысле: как функциональные и физические объекты.
uniqm
31.10.2016 17:37Само понятие модели и есть Ваши точки зрения. Модель — это когда от реального отбросили не важное для текущей цели и оставили важное. По сути у Вас разные модели одного итого же «насоса».
И как сказано, сложность ИТОГО слишком велика, куча моделей с кучей связей. Честно, не осилил чем такая куча моделей поможет менеджеру по продажам. Ему же нужно «коридор» протоптать через «сложность бытия» с минимальным количеством ветвлений (что бы не запутался). Т.е. упростить мир, а не усложнить.
PS А по определению инстанса, вроде все просто (даже на вики есть). Например, есть мастер построения отчетов с кучей параметров и конкретные отчеты из него. Каждый отчет, который получили каким то набором значений в параметрах мастера, и есть инстанс. Класс делает объекты, печка — булочки =)
igormartynov
01.11.2016 21:55Пара вопросов:
1) чем обусловлены ошибки в тексте?
2) заказчик заплатил за работу?maxstroy
02.11.2016 08:40Если Вы нашли ошибки, помогите их исправить, пожалуйста. Две я поправил.
второй вопрос относится к коммерческим интересам и потому я не имею права на него отвечать.igormartynov
02.11.2016 09:54Я же Вас не спрашиваю сколько :) да или нет?
«В этой статье я хочу рассказать о практике применении стандарта ИСО 15926» — «применения», хотя практикой я бы это не назвал.
«сложность обусловленная разрывом» — «обусловлена».
От такого названия и вступления ожидал большего, честно говоря.maxstroy
02.11.2016 10:14Спасибо за указание ошибок!
Конечно заказчик заплатил. Вы же понимаете, что я не раскрыл деталей модели? Есть несколько ключевых моментов, без которых эта модель не взлетит. Раскрывать их я не имею права.
Однако, найти людей, которые работают в этом направлении, я бы хотел. Те, кто в теме, откликнутся, кто не в теме, могут задуматься о неочевидности простых решений. Это была цель моей статьи. Тема моделирования активов — невероятно сложная. Раскрыть все аспекты в одной статье нереально. Но познакомить читателя с задачей и сказать, что есть те, кто ее решают, — можно.
Стандарт ИСО 15926 выступил в роли идеологической основы, но не в качестве руководства к действию. Я не нашел в этом стандарте множественности точек зрения, но нашел время, как равноправную координату наравне с другими тремя. Именно это было взято для работы, а не предустановленные классы.
Eldhenn
Интересно. Левенчуку сообщали? Я как-то не помню, чтобы он использовал понятие «точки зрения», хотя сейчас удивляюсь, как он мог мимо этого пройти.
maxstroy
Да, Левенчуку сообщал, но не уверен, что дошло. На мой взгляд деление функционального объекта на части делается в стандарте единственным способом, что меня лично сильно огорчает.
sand14
Погуглите Multi-viewpoint ontology и Multi-viewpoint ontology construction and classification
В англоязычном мире это устоявшиеся термины, и в моделировании активно используется подход с использованием множества точек зрения.
У нас же этого в бизнес-анализе и моделировании нет.
Разработчик может самостоятельно дойти до Multi-viewpoint идей, работая над traceabity system и параметризованной базой данных, но в аналитике этого до сих пор (до работ maxstroy) не было.
И — а нужно ли сообщать об этом Левенчуку?)
maxstroy
Мы написали статью на эту тему: http://link.springer.com/chapter/10.1007%2F978-3-319-45880-9_1. Понятно, что иначе нельзя моделировать реальность.
Довольно интересно прийти к мысли о множественности точек зрения через анализ задачи трейсабилити. Я вполне допускаю, что это возможно, но хотелось бы узнать этот путь поподробнее.
Левенчуку стоит знать.Он читает лекции на тему системной инженерии. И без осознания того, что мы строим модели через свое восприятие познать системную инженерию невозможно, ИМХО.
sand14
Необходимость в Traceability системе возникает, когда на предприятии нужно выстроить процесс, работающий на единую цель, на все предприятие.
Для этого необходимо нейтрализовать негативные последствие того факта, что каждое подразделение со своим руководством по факту работает на себя, и смотрит на процесс только со своей точки зрения.
И при этом оставить положительную сторону, когда подразделение выполняет свою часть общей работы.
Для этого необходимо, в дополнение к ERP-системе, разработать систему, условно, MES-уровня, которая будет точным образом фиксировать все атомарные события и операции в разрезе «что-где-когда-на каком основании».
И тогда, с одной стороны, мы будем иметь «рентгенографический» снимок всего, что происходило на предприятии, действительно первичную информацию, свободную от точек зрения и интересов каждого подразделения.
На основании собранной информации будут формироваться обобщенные данные для принятия управленческих решений как на уровне подразделений (в их интересах), так и на уровне руководства, координирующего совместную работу подразделений — в интересах предприятия в целом.
Для решения этих задач необходимо:
1. Разработать параметрически настраиваемую систему для сбора любых (атомарных) данных в каждой из точек производственного процесса.
В качестве реализации такой системы может выступать параметризованная реляционная БД (или графовая БД), позволяющая представить любой объект в виде универсальной конструкции и содержащая журнал (лог) всех атомарных операций.
Разнородные (зависящие от видов операций) данные для каждой строки журнала будет представляться в виде конструкции.
2. Для работы с такой базой данных необходим разработать соответствующее API.
С одной стороны, это API обеспечит работу с «конструкциями», журналом операций и другими универсальными структурами БД.
С другой — API должно предоставить возможность работать с объектами БД в терминах предметной области, и формировать обобщенные данные для каждого из подразделений и координирующего руководства (см. выше).
Итак, как только мы реализовали MES-систему в соответствии с этими принципами, на шаге 1 она превратилась в Traceability систему, а на шаге 2 мы обнаруживаем, что это полноценная Multiview-point система, разработанная эмпирическим путем.
Остается шаг 3 — проработать эту систему на уровне аналитики/моделирования/онтологии, и повторить путь программной реализации заново, получив на порядок или два более качественный результат, как с точки зрения архитектуры продукта, так и с точки зрения его бизнес-полезности.
sakhavat
1. Разработать параметрически настраиваемую систему для сбора любых (атомарных) данных в каждой из точек производственного процесса.
Это называется SCADA и полно таких вещей.
2. Для работы с такой базой данных необходим разработать соответствующее API.
БД и т.д. вторична.
МЕС = Управляемая Модель предприятия в динамике (меса.орг и т.д. выкидываем за скобку).
Multiview-point тут не при чем — есть владельцы, их цели, процессы для достижения целей, ресурсы, управленческие политики.
maxstroy
Как только появляются цели, процессы для их достижения, ресурсы, мы говорим о деятельности. И тем самым сводим нашу модель к решению очень ограниченной задачи — описания деятельности. Но нам это не надо. Мы не хотим описывать деятельность, нас интересуют факты вне контекста деятельности. Это ровно то, что я сказал, что древние под умножением считали вычисление площади, так и нынешние аналитики считают, что описание активности — это описание деятельности.
sand14
SCADA в большей степени относится к уровню АСУ ТП, нежели MES.
В общем случае характер производства или процесса может было такой, что SCADA система не подойдет (вплоть до того, что процесс вообще может быть чисто организационным).
(Подробное описание системы, возможно, будет в отдельной публикации.)
Что до вторичности БД и АПИ, то я бы посоветовал вам вчитаться в комментарии, прежде чем отвечать.
Я об этом и пишу, что за неимением должной аналитики и онтологии, разработчик сам может дойти до Multiviewpoint-идей, если ему попадется подходящая задача (в первую очередь это Traceability).
И тогда появятся описанные БД и API.
А чтобы БД и API были реализованы с должным качеством, должна быть проработана первичная вещь — Multi-viewpoint аналитика.
Но здесь проблема — понятия аналитики и аналитиков у нас девальвированы (ну так, раз в 100 — все сводится в разработке макетов форм).
А за неимением аналитики только часть архитектурных вещей системы можно верно задать на уровне проработки архитектуры БД и API.
sakhavat
Как не назови, просто подумал что вам эти термины не знакомы. Назовем системой обратной связи, которая событийно или еще как оповещает подписчиков (да хоть просто складирует инфу — один подписчик ОПС).
Ничего не девальвировано, просто не было такого слоя у нас — постановщики не доросли до аналитиков, а менеджмент и владельцы — до определителей целей, так как временной интервал для принятия решения никого не устраивает — нет законности и порядка.
В общем, я пас.
Про моделирование целей субъекта, его деятельности и т.д. могу поговорить, но тут вроде никак картинки не прицепишь, а это не интересно — приходится много писать наезженных слов, а их каждый понимает по своему да и пропадает рекламная составляющая.
sand14
А насчет Л. это был сарказм в ответ на упоминание его как авторитета.
Появление англоязычной работы maxstroy на тему Multi-viewpoint ontology привело меня в удивление:
Если вначале термин «точка зрения» казался хотя и кратким/емким, но все равно самобытным и местечковым определением длинного описания системы, приведенного в моем комментарии выше,
то затем внезапно оказалось, что там, где этим занимаются, это устойчивым образом называется Multi-viewpoint ontology (и термин construction там тоже есть, что характерно!).
И если разработчикам не знать этого простительно, то… как же так получается, что многочисленные современные консультанты, занимающейся системной инженерией, аналитикой, разработкой, оптимизацией и внедрением (бизнес-)процессов, этого даже не знают хотя бы на уровне терминологии — мол, есть такая Multi-viewpoint парадигма построения систем и процессов.
Ну а поскольку ничего подобного нет на уровне постановки задач и аналитики, но ничего подобного не наблюдается и на уровне разработки (программной реализации).
lair
Вообще, разработчики про это знают и давно. В ненавистном ООП есть такая вещь как интерфейс (и interface segregation principle), благодаря которой один и тот же объект может восприниматься разными потребителями совершенно разным образом.
maxstroy
При чем тут интерфейс и ООП? ООП вообще не про моделирование предметной области. Он про моделирование кода.
lair
Во-первых, это утверждение, как неоднократно обсуждалось, неверно, причем в обеих своих частях. ООП не про моделирование кода, просто потому, что я могу не иметь модели кода вообще, но при этом иметь ООП. Во-вторых, ООП может использоваться для моделирования предметной области (конечно, с учетом его ограничений) — в том случае, если моделью выступают объекты программы.
Но речь не об этом. Интерфейс здесь исключительно при том, что понятие "точки зрения" разработчикам, как ни странно, знакомо, в том числе и применительно к объектам предметной области; просто под другим названием.
sakhavat
при чем тут какой то код?
lair
А при чем тут разработчики?
sakhavat
Разработчик сильное понятие — можно разработать пласт нефтеносный, математическую теорию, ракетную систему, развал США…
lair
… вот и "код" — тоже понятие сильное.
maxstroy
Очень яркая и понятная статья про ограничения ООП при моделировании предметных областей написана mnikolaev83
lair
"конечно, с учетом его ограничений".
Ну и статью уже разобрали как несостоятельную.
sakhavat
ерунда эта статья
ОПП задает объектную (структурно-поведенческую) часть, процессный дополняет до деятельности, а декомпозия целей до выходов процессов — включает волю.
maxstroy
Термин «поведенческая» говорит о наследии теории деятельности в головах тех, кто говорит этот термин Мы не моделируем деятельность, мы не моделируем поведение, мы моделируем активность и потому нельзя в нашей области говорить о поведении.
sakhavat
Давайте просто определимся.
Для меня — Деятельность — выработка целей и генерация, запуск и мониторинг обеспечивающих процессов для достижения этих целей.
Процесс — упорядоченный набор активностей процессоров во времени и в пространстве.
Процессор — ресурс с активной ролью, который не является потребностью (входом) или предложением (выходом) процесса
Вход процесса — то что процесс потребляет(трансформирует)
Выход — то что процесс генерирует
Ресурс — все что угодно (включая «объект», «процесс»)
Межпроцессная коммуникация — потоки на связях.
Связь соединяет процессы — задает отношение предшествования и темпоральную составляющую (относительные смещения во времени)
Связь может нести потоки — темпоральные, материальные, информационные, финансовые…
В принципе это концептуальная модель полностью описывает любое предприятие.
maxstroy
Ну вот об этом я и говорю — мы не моделируем деятельность, то есть, мы не моделируем входы, выходы, ресурсы и прочее, мы моделируем участников, а это совсем другая история. Это модель активности, а не деятельности. На основе модели активности как проекцию можно получить модель деятельности, но обратно — никак. Следовательно, нам не нужна модель деятельности как частный случай модели активности. Кроме того, я не смогу перейти в модели деятельности от точки зрения одного актора к точке зрения другого.
sakhavat
По мне «деятельность» намного шире чем «активность»
первое достижение целей субъекта со свободой выбора процессов достижения целей, а второе регламентированное участие в процессе.
И таки с второго первое не получишь, а первое всегда можно зарегламентировать и получить второе.
И вообще, мне кажется «моделирование активов» не очень звучит — или это Описание активов конкретного предприятия или просто Моделирование объектов независимо от предприятия и т.д.
maxstroy
Я могу интерпретировать одну активность разными способами — с разных точек зрения. Сражение моно рассмотреть с одной точки зрения и с другой. Мы видим участников сражения, описываем акты, но не интерпретируем их никак. Это описание активности. Но встав на точку зрения одной из сторон, мы вносим субъективность в модель и появляются акторы, цели и прочее, что нам пока не интересно для моделирования активов той или иной из сторон.
Моделирование активов хорошо тогда, когда актив перемещается по предприятию, или меду предприятий и не требует смены БД для его учета. Хотя в одном случае это был молоток, а в другом — лом. В одном — инструмент, в другом — материальная ценность. Один и тот же предмет имеет разные трактовки в зависимости от того, кто на него смотрит. Поэтому мы вынуждены отделять трактовку объекта от констатации факта его наличия.
sakhavat
Удачи.
CrazyViper
А зачем ему об этом сообщать, если он сам явно говорит о точках зрения всегда повторяя фразу «система в глазах смотрящего» и выделяя как минимум три точки зрения: компоненты, модули и расположения.
А вообще есть стандарт ISO 42010, который вводит понятия Viewpoint и View, определяя метамодель для Viewpoint'а.
maxstroy
потому что Левенчук еще ни разу не разобрал один и тот же функциональный объект на части (на функциональные объекты) двумя разными способами — в соответствии с тем, как это видят разные субъекты. Разбор на компоненты, модули и проч — это передустановленные разложения. Мы же говорим, что таких разложений может быть большое (не обязательно наперед заданное) количество.
CrazyViper
Стандарт ISO 42010 прямо говорит то же самое:
> An architecture viewpoint could be defined as a part of an architecture description (Clause 5), as a part of an
architecture framework (Clause 6) or individually using the requirements of this Clause. A library viewpoint is an architecture viewpoint produced outside of the context of a single architecture description such that it can be used in many architecture descriptions.
И даже больше. В стандарте выделяются интересы (concern) тех субъектов, которые смотрят на объект (стейкхолдеры) с разных точек зрения. И собственно точка зрения (viewpoint, способ разложения) определяется не субъектом, смотрящим на объект, а интересом субъекта. У двух субъектов может быть один интерес и поэтому точка зрения у них будет одинаковая.
maxstroy
Спасибо за столь интересный комментарий! Теперь осталось найти такой объект как «точка зрения», или «интерес» в информационных моделях, которые построены в определенных нотациях. Дело в том, что ни одна нотация не включила пока в себя эти термины и не дала фреймворка для создания моделей, которые описывались бы разными субъектами с разными интересами и к тому же имела маппинг между этими моделями.
sakhavat
а никто за это не хочет платить
CrazyViper
Отвергнутый вам Архимейт предполагает разделение модели на Viewpoint'ы, приводя в пример определенный набор. Если вы будете использовать инструмент (а не стандарт), который позволяет представлять одну модель с разных точек зрения (например, Sparx Enterprise Architect или бесплатный Archi), то расположение одного объекта на разных диаграммах позволяет создавать эти связи между точками зрения.
Так же в Архимейте в разделе Motivation есть понятие "Driver":
maxstroy
В архи нет правильного объяснения связи между бизнес-функцией и операциями, путаются разные уровни абстракции. Например, модель функции соединяется в нотации с моделью моделей процессов, что выглядит ужасно.
maxstroy
Опять же архи находится на поле описания деятельности, которое (поле) узко для создания расширяемых моделей. Нам нужен фреймворк для описания активности, но не деятельности
CrazyViper
И совсем забыл акцентировать внимание на разделении понятий «viewpoint» и «view»:
* Viewpoint — это спецификация описания (модели).
* View — это само описание (модель).
В таком разделении выносить объект «точка зрения» в информационную модель не корректно — это метамодель.
maxstroy
В OWL нет деления на эти уровни, потому что такое деление приводит к ошибкам. Главное — правильно прописывать связи между объектами. метауровень описывает структуру хранения данных и тем самым связан с данными. Мы же описываем структуру в той же модели, что и саму модель. Если реляционная модель это запрещает, то это проблема реляционной модели, о которой отдельный разговор.
vvagr
Трудно читать или слушать Левенчука, и не заметить использования им понятия viewpoint или рассуждений о стейкхолдерах, интересах, и соответствующих интересам группах описаний. Но вы сумели :-)
maxstroy
Я не говорю, что А. Левенчук не говорит про точку зрения. Я говорю о том, что нет физических и функциональных объектов — есть разные точки зрения. Вот тут скорее всего, мы расходимся с Левенчуком. Он говорит о разных точках зрения в рамках одной парадигмы, а я говорю, что и сами парадигмы — есть разные точки зрения. Например, разделение объекта на функциональные подсистемы и функциональные модули — это представление одного объекта в виде двух разных функциональных структур с разных точек зрения. Причем мы можем замаппиться с одной на другую, например, спросить, какие электрические сети находятся в модуле подъема труб? То есть есть маппинг между конструкциями с разных точек зрения. А далее никто не классифицировал возможные отношения между объектами в разных точках зрения — это тоже задача еще та! Я не видел ничего подобного ни в одной из лекций.
vvagr
Не думаю, что Вы проходили какой-либо наш курс по информационному моделированию.
Не очень понимаю, что Вы называете «одной парадигмой» Левенчука. Однако даже в общем курсе системного мышления рассказывается минимум о трёх точках зрения.
Разделение объекта на функциональные подсистемы и функциональные модули — это что-то странное, модули (в нашей терминологии) всегда физические. А вот если Вы имели в виду разделение на функциональные подсистемы и функциональные компоненты — это общее место, вообще-то, реализованное во всех САПР.
maxstroy
Три точки зрения — этого мало. Существуют разные области человеческой деятельности, каждая из которых порождает общепринятую точку зрения на сущее. Это значит, что специалист в этой области начинает видеть то, чему его научили в этой области. Область деятельности предполагает свой терминологический аппарат, свои типы объектов, которые (объекты) требуются для выделения. То, что мы называем «физические» объекты — это выделение объектов в одной области деятельности, то, что называется «функциональные» — это выделение объектов в другой области деятельности. Выделение объектов тем или иным способом диктуется используемой парадигмой. И таких парадигм огромное количество. Перед описанием объекта мы выделяем все парадигмы, все точки зрения в этих парадигмах, строим все модели и маппим их друг на друга. И тогда будут не физические объекты, а объекты, выделенные субъектом в рамках парадигмы, выдвинутой физиками. Ведь есть же объекты, в рамках парадигмы, выдвинутой православными, например. Святой дух, — ему тоже надо выделить место в модели, если мы рассматриваем мир в парадигме православия. Также надо понять, что все области деятельности являются равноправными. Поэтому нет выделенных точек зрения. В рамках каждой из парадигм существует множество своих точек зрения. Поэтому есть только три класса сущностей, которые описывают все разнообразие, которое нам надо описать, а не 200.