Комментарии 85
Интересно. Левенчуку сообщали? Я как-то не помню, чтобы он использовал понятие «точки зрения», хотя сейчас удивляюсь, как он мог мимо этого пройти.
Да, Левенчуку сообщал, но не уверен, что дошло. На мой взгляд деление функционального объекта на части делается в стандарте единственным способом, что меня лично сильно огорчает.
Погуглите Multi-viewpoint ontology и Multi-viewpoint ontology construction and classification
В англоязычном мире это устоявшиеся термины, и в моделировании активно используется подход с использованием множества точек зрения.
У нас же этого в бизнес-анализе и моделировании нет.
Разработчик может самостоятельно дойти до Multi-viewpoint идей, работая над traceabity system и параметризованной базой данных, но в аналитике этого до сих пор (до работ maxstroy) не было.
И — а нужно ли сообщать об этом Левенчуку?)
В англоязычном мире это устоявшиеся термины, и в моделировании активно используется подход с использованием множества точек зрения.
У нас же этого в бизнес-анализе и моделировании нет.
Разработчик может самостоятельно дойти до Multi-viewpoint идей, работая над traceabity system и параметризованной базой данных, но в аналитике этого до сих пор (до работ maxstroy) не было.
И — а нужно ли сообщать об этом Левенчуку?)
Мы написали статью на эту тему: http://link.springer.com/chapter/10.1007%2F978-3-319-45880-9_1. Понятно, что иначе нельзя моделировать реальность.
Довольно интересно прийти к мысли о множественности точек зрения через анализ задачи трейсабилити. Я вполне допускаю, что это возможно, но хотелось бы узнать этот путь поподробнее.
Левенчуку стоит знать.Он читает лекции на тему системной инженерии. И без осознания того, что мы строим модели через свое восприятие познать системную инженерию невозможно, ИМХО.
Довольно интересно прийти к мысли о множественности точек зрения через анализ задачи трейсабилити. Я вполне допускаю, что это возможно, но хотелось бы узнать этот путь поподробнее.
Левенчуку стоит знать.Он читает лекции на тему системной инженерии. И без осознания того, что мы строим модели через свое восприятие познать системную инженерию невозможно, ИМХО.
Довольно интересно прийти к мысли о множественности точек зрения через анализ задачи трейсабилити. Я вполне допускаю, что это возможно, но хотелось бы узнать этот путь поподробнее.
Необходимость в Traceability системе возникает, когда на предприятии нужно выстроить процесс, работающий на единую цель, на все предприятие.
Для этого необходимо нейтрализовать негативные последствие того факта, что каждое подразделение со своим руководством по факту работает на себя, и смотрит на процесс только со своей точки зрения.
И при этом оставить положительную сторону, когда подразделение выполняет свою часть общей работы.
Для этого необходимо, в дополнение к ERP-системе, разработать систему, условно, MES-уровня, которая будет точным образом фиксировать все атомарные события и операции в разрезе «что-где-когда-на каком основании».
И тогда, с одной стороны, мы будем иметь «рентгенографический» снимок всего, что происходило на предприятии, действительно первичную информацию, свободную от точек зрения и интересов каждого подразделения.
На основании собранной информации будут формироваться обобщенные данные для принятия управленческих решений как на уровне подразделений (в их интересах), так и на уровне руководства, координирующего совместную работу подразделений — в интересах предприятия в целом.
Для решения этих задач необходимо:
1. Разработать параметрически настраиваемую систему для сбора любых (атомарных) данных в каждой из точек производственного процесса.
В качестве реализации такой системы может выступать параметризованная реляционная БД (или графовая БД), позволяющая представить любой объект в виде универсальной конструкции и содержащая журнал (лог) всех атомарных операций.
Разнородные (зависящие от видов операций) данные для каждой строки журнала будет представляться в виде конструкции.
2. Для работы с такой базой данных необходим разработать соответствующее API.
С одной стороны, это API обеспечит работу с «конструкциями», журналом операций и другими универсальными структурами БД.
С другой — API должно предоставить возможность работать с объектами БД в терминах предметной области, и формировать обобщенные данные для каждого из подразделений и координирующего руководства (см. выше).
Итак, как только мы реализовали MES-систему в соответствии с этими принципами, на шаге 1 она превратилась в Traceability систему, а на шаге 2 мы обнаруживаем, что это полноценная Multiview-point система, разработанная эмпирическим путем.
Остается шаг 3 — проработать эту систему на уровне аналитики/моделирования/онтологии, и повторить путь программной реализации заново, получив на порядок или два более качественный результат, как с точки зрения архитектуры продукта, так и с точки зрения его бизнес-полезности.
1. Разработать параметрически настраиваемую систему для сбора любых (атомарных) данных в каждой из точек производственного процесса.
Это называется SCADA и полно таких вещей.
2. Для работы с такой базой данных необходим разработать соответствующее API.
БД и т.д. вторична.
МЕС = Управляемая Модель предприятия в динамике (меса.орг и т.д. выкидываем за скобку).
Multiview-point тут не при чем — есть владельцы, их цели, процессы для достижения целей, ресурсы, управленческие политики.
Это называется SCADA и полно таких вещей.
2. Для работы с такой базой данных необходим разработать соответствующее API.
БД и т.д. вторична.
МЕС = Управляемая Модель предприятия в динамике (меса.орг и т.д. выкидываем за скобку).
Multiview-point тут не при чем — есть владельцы, их цели, процессы для достижения целей, ресурсы, управленческие политики.
Как только появляются цели, процессы для их достижения, ресурсы, мы говорим о деятельности. И тем самым сводим нашу модель к решению очень ограниченной задачи — описания деятельности. Но нам это не надо. Мы не хотим описывать деятельность, нас интересуют факты вне контекста деятельности. Это ровно то, что я сказал, что древние под умножением считали вычисление площади, так и нынешние аналитики считают, что описание активности — это описание деятельности.
SCADA в большей степени относится к уровню АСУ ТП, нежели MES.
В общем случае характер производства или процесса может было такой, что SCADA система не подойдет (вплоть до того, что процесс вообще может быть чисто организационным).
(Подробное описание системы, возможно, будет в отдельной публикации.)
Что до вторичности БД и АПИ, то я бы посоветовал вам вчитаться в комментарии, прежде чем отвечать.
Я об этом и пишу, что за неимением должной аналитики и онтологии, разработчик сам может дойти до Multiviewpoint-идей, если ему попадется подходящая задача (в первую очередь это Traceability).
И тогда появятся описанные БД и API.
А чтобы БД и API были реализованы с должным качеством, должна быть проработана первичная вещь — Multi-viewpoint аналитика.
Но здесь проблема — понятия аналитики и аналитиков у нас девальвированы (ну так, раз в 100 — все сводится в разработке макетов форм).
А за неимением аналитики только часть архитектурных вещей системы можно верно задать на уровне проработки архитектуры БД и API.
В общем случае характер производства или процесса может было такой, что SCADA система не подойдет (вплоть до того, что процесс вообще может быть чисто организационным).
(Подробное описание системы, возможно, будет в отдельной публикации.)
Что до вторичности БД и АПИ, то я бы посоветовал вам вчитаться в комментарии, прежде чем отвечать.
Я об этом и пишу, что за неимением должной аналитики и онтологии, разработчик сам может дойти до Multiviewpoint-идей, если ему попадется подходящая задача (в первую очередь это Traceability).
И тогда появятся описанные БД и API.
А чтобы БД и API были реализованы с должным качеством, должна быть проработана первичная вещь — Multi-viewpoint аналитика.
Но здесь проблема — понятия аналитики и аналитиков у нас девальвированы (ну так, раз в 100 — все сводится в разработке макетов форм).
А за неимением аналитики только часть архитектурных вещей системы можно верно задать на уровне проработки архитектуры БД и API.
Как не назови, просто подумал что вам эти термины не знакомы. Назовем системой обратной связи, которая событийно или еще как оповещает подписчиков (да хоть просто складирует инфу — один подписчик ОПС).
Ничего не девальвировано, просто не было такого слоя у нас — постановщики не доросли до аналитиков, а менеджмент и владельцы — до определителей целей, так как временной интервал для принятия решения никого не устраивает — нет законности и порядка.
В общем, я пас.
Про моделирование целей субъекта, его деятельности и т.д. могу поговорить, но тут вроде никак картинки не прицепишь, а это не интересно — приходится много писать наезженных слов, а их каждый понимает по своему да и пропадает рекламная составляющая.
Ничего не девальвировано, просто не было такого слоя у нас — постановщики не доросли до аналитиков, а менеджмент и владельцы — до определителей целей, так как временной интервал для принятия решения никого не устраивает — нет законности и порядка.
В общем, я пас.
Про моделирование целей субъекта, его деятельности и т.д. могу поговорить, но тут вроде никак картинки не прицепишь, а это не интересно — приходится много писать наезженных слов, а их каждый понимает по своему да и пропадает рекламная составляющая.
А насчет Л. это был сарказм в ответ на упоминание его как авторитета.
Появление англоязычной работы maxstroy на тему Multi-viewpoint ontology привело меня в удивление:
Если вначале термин «точка зрения» казался хотя и кратким/емким, но все равно самобытным и местечковым определением длинного описания системы, приведенного в моем комментарии выше,
то затем внезапно оказалось, что там, где этим занимаются, это устойчивым образом называется Multi-viewpoint ontology (и термин construction там тоже есть, что характерно!).
И если разработчикам не знать этого простительно, то… как же так получается, что многочисленные современные консультанты, занимающейся системной инженерией, аналитикой, разработкой, оптимизацией и внедрением (бизнес-)процессов, этого даже не знают хотя бы на уровне терминологии — мол, есть такая Multi-viewpoint парадигма построения систем и процессов.
Ну а поскольку ничего подобного нет на уровне постановки задач и аналитики, но ничего подобного не наблюдается и на уровне разработки (программной реализации).
Появление англоязычной работы maxstroy на тему Multi-viewpoint ontology привело меня в удивление:
Если вначале термин «точка зрения» казался хотя и кратким/емким, но все равно самобытным и местечковым определением длинного описания системы, приведенного в моем комментарии выше,
то затем внезапно оказалось, что там, где этим занимаются, это устойчивым образом называется Multi-viewpoint ontology (и термин construction там тоже есть, что характерно!).
И если разработчикам не знать этого простительно, то… как же так получается, что многочисленные современные консультанты, занимающейся системной инженерией, аналитикой, разработкой, оптимизацией и внедрением (бизнес-)процессов, этого даже не знают хотя бы на уровне терминологии — мол, есть такая Multi-viewpoint парадигма построения систем и процессов.
Ну а поскольку ничего подобного нет на уровне постановки задач и аналитики, но ничего подобного не наблюдается и на уровне разработки (программной реализации).
И если разработчикам не знать этого простительно
Вообще, разработчики про это знают и давно. В ненавистном ООП есть такая вещь как интерфейс (и interface segregation principle), благодаря которой один и тот же объект может восприниматься разными потребителями совершенно разным образом.
При чем тут интерфейс и ООП? ООП вообще не про моделирование предметной области. Он про моделирование кода.
ООП вообще не про моделирование предметной области. Он про моделирование кода.
Во-первых, это утверждение, как неоднократно обсуждалось, неверно, причем в обеих своих частях. ООП не про моделирование кода, просто потому, что я могу не иметь модели кода вообще, но при этом иметь ООП. Во-вторых, ООП может использоваться для моделирования предметной области (конечно, с учетом его ограничений) — в том случае, если моделью выступают объекты программы.
Но речь не об этом. Интерфейс здесь исключительно при том, что понятие "точки зрения" разработчикам, как ни странно, знакомо, в том числе и применительно к объектам предметной области; просто под другим названием.
при чем тут какой то код?
А при чем тут разработчики?
Разработчик сильное понятие — можно разработать пласт нефтеносный, математическую теорию, ракетную систему, развал США…
Очень яркая и понятная статья про ограничения ООП при моделировании предметных областей написана mnikolaev83
"конечно, с учетом его ограничений".
Ну и статью уже разобрали как несостоятельную.
ерунда эта статья
ОПП задает объектную (структурно-поведенческую) часть, процессный дополняет до деятельности, а декомпозия целей до выходов процессов — включает волю.
ОПП задает объектную (структурно-поведенческую) часть, процессный дополняет до деятельности, а декомпозия целей до выходов процессов — включает волю.
Термин «поведенческая» говорит о наследии теории деятельности в головах тех, кто говорит этот термин Мы не моделируем деятельность, мы не моделируем поведение, мы моделируем активность и потому нельзя в нашей области говорить о поведении.
Давайте просто определимся.
Для меня — Деятельность — выработка целей и генерация, запуск и мониторинг обеспечивающих процессов для достижения этих целей.
Процесс — упорядоченный набор активностей процессоров во времени и в пространстве.
Процессор — ресурс с активной ролью, который не является потребностью (входом) или предложением (выходом) процесса
Вход процесса — то что процесс потребляет(трансформирует)
Выход — то что процесс генерирует
Ресурс — все что угодно (включая «объект», «процесс»)
Межпроцессная коммуникация — потоки на связях.
Связь соединяет процессы — задает отношение предшествования и темпоральную составляющую (относительные смещения во времени)
Связь может нести потоки — темпоральные, материальные, информационные, финансовые…
В принципе это концептуальная модель полностью описывает любое предприятие.
Для меня — Деятельность — выработка целей и генерация, запуск и мониторинг обеспечивающих процессов для достижения этих целей.
Процесс — упорядоченный набор активностей процессоров во времени и в пространстве.
Процессор — ресурс с активной ролью, который не является потребностью (входом) или предложением (выходом) процесса
Вход процесса — то что процесс потребляет(трансформирует)
Выход — то что процесс генерирует
Ресурс — все что угодно (включая «объект», «процесс»)
Межпроцессная коммуникация — потоки на связях.
Связь соединяет процессы — задает отношение предшествования и темпоральную составляющую (относительные смещения во времени)
Связь может нести потоки — темпоральные, материальные, информационные, финансовые…
В принципе это концептуальная модель полностью описывает любое предприятие.
Ну вот об этом я и говорю — мы не моделируем деятельность, то есть, мы не моделируем входы, выходы, ресурсы и прочее, мы моделируем участников, а это совсем другая история. Это модель активности, а не деятельности. На основе модели активности как проекцию можно получить модель деятельности, но обратно — никак. Следовательно, нам не нужна модель деятельности как частный случай модели активности. Кроме того, я не смогу перейти в модели деятельности от точки зрения одного актора к точке зрения другого.
По мне «деятельность» намного шире чем «активность»
первое достижение целей субъекта со свободой выбора процессов достижения целей, а второе регламентированное участие в процессе.
И таки с второго первое не получишь, а первое всегда можно зарегламентировать и получить второе.
И вообще, мне кажется «моделирование активов» не очень звучит — или это Описание активов конкретного предприятия или просто Моделирование объектов независимо от предприятия и т.д.
первое достижение целей субъекта со свободой выбора процессов достижения целей, а второе регламентированное участие в процессе.
И таки с второго первое не получишь, а первое всегда можно зарегламентировать и получить второе.
И вообще, мне кажется «моделирование активов» не очень звучит — или это Описание активов конкретного предприятия или просто Моделирование объектов независимо от предприятия и т.д.
Я могу интерпретировать одну активность разными способами — с разных точек зрения. Сражение моно рассмотреть с одной точки зрения и с другой. Мы видим участников сражения, описываем акты, но не интерпретируем их никак. Это описание активности. Но встав на точку зрения одной из сторон, мы вносим субъективность в модель и появляются акторы, цели и прочее, что нам пока не интересно для моделирования активов той или иной из сторон.
Моделирование активов хорошо тогда, когда актив перемещается по предприятию, или меду предприятий и не требует смены БД для его учета. Хотя в одном случае это был молоток, а в другом — лом. В одном — инструмент, в другом — материальная ценность. Один и тот же предмет имеет разные трактовки в зависимости от того, кто на него смотрит. Поэтому мы вынуждены отделять трактовку объекта от констатации факта его наличия.
Моделирование активов хорошо тогда, когда актив перемещается по предприятию, или меду предприятий и не требует смены БД для его учета. Хотя в одном случае это был молоток, а в другом — лом. В одном — инструмент, в другом — материальная ценность. Один и тот же предмет имеет разные трактовки в зависимости от того, кто на него смотрит. Поэтому мы вынуждены отделять трактовку объекта от констатации факта его наличия.
А зачем ему об этом сообщать, если он сам явно говорит о точках зрения всегда повторяя фразу «система в глазах смотрящего» и выделяя как минимум три точки зрения: компоненты, модули и расположения.
А вообще есть стандарт ISO 42010, который вводит понятия Viewpoint и View, определяя метамодель для Viewpoint'а.
А вообще есть стандарт ISO 42010, который вводит понятия Viewpoint и View, определяя метамодель для Viewpoint'а.
потому что Левенчук еще ни разу не разобрал один и тот же функциональный объект на части (на функциональные объекты) двумя разными способами — в соответствии с тем, как это видят разные субъекты. Разбор на компоненты, модули и проч — это передустановленные разложения. Мы же говорим, что таких разложений может быть большое (не обязательно наперед заданное) количество.
Стандарт 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, способ разложения) определяется не субъектом, смотрящим на объект, а интересом субъекта. У двух субъектов может быть один интерес и поэтому точка зрения у них будет одинаковая.
> 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, способ разложения) определяется не субъектом, смотрящим на объект, а интересом субъекта. У двух субъектов может быть один интерес и поэтому точка зрения у них будет одинаковая.
Спасибо за столь интересный комментарий! Теперь осталось найти такой объект как «точка зрения», или «интерес» в информационных моделях, которые построены в определенных нотациях. Дело в том, что ни одна нотация не включила пока в себя эти термины и не дала фреймворка для создания моделей, которые описывались бы разными субъектами с разными интересами и к тому же имела маппинг между этими моделями.
а никто за это не хочет платить
Отвергнутый вам Архимейт предполагает разделение модели на Viewpoint'ы, приводя в пример определенный набор. Если вы будете использовать инструмент (а не стандарт), который позволяет представлять одну модель с разных точек зрения (например, Sparx Enterprise Architect или бесплатный Archi), то расположение одного объекта на разных диаграммах позволяет создавать эти связи между точками зрения.
Так же в Архимейте в разделе Motivation есть понятие "Driver":
Так же в Архимейте в разделе Motivation есть понятие "Driver":
Drivers may be internal, in which case they are usually associated with a stakeholder, and are often called “concerns”. Stakeholder concerns are defined in the TOGAF framework [4] as ”the key interests that are crucially important to the stakeholders in a system, and determine the acceptability of the system. Concerns may pertain to any aspect of the function, development, or operation of the system, including considerations such as performance, reliability, security, distribution, and evolvability.” /blockquote> А стандарт TOGAF напрямую определяет понятие «concern».
В архи нет правильного объяснения связи между бизнес-функцией и операциями, путаются разные уровни абстракции. Например, модель функции соединяется в нотации с моделью моделей процессов, что выглядит ужасно.
Опять же архи находится на поле описания деятельности, которое (поле) узко для создания расширяемых моделей. Нам нужен фреймворк для описания активности, но не деятельности
И совсем забыл акцентировать внимание на разделении понятий «viewpoint» и «view»:
* Viewpoint — это спецификация описания (модели).
* View — это само описание (модель).
В таком разделении выносить объект «точка зрения» в информационную модель не корректно — это метамодель.
* Viewpoint — это спецификация описания (модели).
* View — это само описание (модель).
В таком разделении выносить объект «точка зрения» в информационную модель не корректно — это метамодель.
В OWL нет деления на эти уровни, потому что такое деление приводит к ошибкам. Главное — правильно прописывать связи между объектами. метауровень описывает структуру хранения данных и тем самым связан с данными. Мы же описываем структуру в той же модели, что и саму модель. Если реляционная модель это запрещает, то это проблема реляционной модели, о которой отдельный разговор.
Трудно читать или слушать Левенчука, и не заметить использования им понятия viewpoint или рассуждений о стейкхолдерах, интересах, и соответствующих интересам группах описаний. Но вы сумели :-)
Я не говорю, что А. Левенчук не говорит про точку зрения. Я говорю о том, что нет физических и функциональных объектов — есть разные точки зрения. Вот тут скорее всего, мы расходимся с Левенчуком. Он говорит о разных точках зрения в рамках одной парадигмы, а я говорю, что и сами парадигмы — есть разные точки зрения. Например, разделение объекта на функциональные подсистемы и функциональные модули — это представление одного объекта в виде двух разных функциональных структур с разных точек зрения. Причем мы можем замаппиться с одной на другую, например, спросить, какие электрические сети находятся в модуле подъема труб? То есть есть маппинг между конструкциями с разных точек зрения. А далее никто не классифицировал возможные отношения между объектами в разных точках зрения — это тоже задача еще та! Я не видел ничего подобного ни в одной из лекций.
Не думаю, что Вы проходили какой-либо наш курс по информационному моделированию.
Не очень понимаю, что Вы называете «одной парадигмой» Левенчука. Однако даже в общем курсе системного мышления рассказывается минимум о трёх точках зрения.
Разделение объекта на функциональные подсистемы и функциональные модули — это что-то странное, модули (в нашей терминологии) всегда физические. А вот если Вы имели в виду разделение на функциональные подсистемы и функциональные компоненты — это общее место, вообще-то, реализованное во всех САПР.
Не очень понимаю, что Вы называете «одной парадигмой» Левенчука. Однако даже в общем курсе системного мышления рассказывается минимум о трёх точках зрения.
Разделение объекта на функциональные подсистемы и функциональные модули — это что-то странное, модули (в нашей терминологии) всегда физические. А вот если Вы имели в виду разделение на функциональные подсистемы и функциональные компоненты — это общее место, вообще-то, реализованное во всех САПР.
Три точки зрения — этого мало. Существуют разные области человеческой деятельности, каждая из которых порождает общепринятую точку зрения на сущее. Это значит, что специалист в этой области начинает видеть то, чему его научили в этой области. Область деятельности предполагает свой терминологический аппарат, свои типы объектов, которые (объекты) требуются для выделения. То, что мы называем «физические» объекты — это выделение объектов в одной области деятельности, то, что называется «функциональные» — это выделение объектов в другой области деятельности. Выделение объектов тем или иным способом диктуется используемой парадигмой. И таких парадигм огромное количество. Перед описанием объекта мы выделяем все парадигмы, все точки зрения в этих парадигмах, строим все модели и маппим их друг на друга. И тогда будут не физические объекты, а объекты, выделенные субъектом в рамках парадигмы, выдвинутой физиками. Ведь есть же объекты, в рамках парадигмы, выдвинутой православными, например. Святой дух, — ему тоже надо выделить место в модели, если мы рассматриваем мир в парадигме православия. Также надо понять, что все области деятельности являются равноправными. Поэтому нет выделенных точек зрения. В рамках каждой из парадигм существует множество своих точек зрения. Поэтому есть только три класса сущностей, которые описывают все разнообразие, которое нам надо описать, а не 200.
Читайте про Object Role Modeling — 100 лет в обед
Я не уверен, что есть модель данных, которая бы описывала то, что я рассказал. Наша работа была в создании именно такой модели. Что важно — создать ее в реляционной модели если и возможно, то очень громоздко и трудно. Мы используем OWL для моделирования.
«Точку зрения» впервые я увидел у Мартина Дж (Организация БД в вычислительных системах. Мир. 1980г.)
Хотя это вроде и тривиально сейчас выглядит (Знание Эксперта = Сумма знаний спецов) на меня это сильное произвело впечатление.
Реляционная модель должна автоматически сгенерироваться из метаданных модели (если в ней есть нужда — на сегодня эта нужда диктуется наличием мощной инфраструктуры)
.
Моделировать можно все и очень адекватно простыми расширениями имеющихся языков (нотаций) моделирования. Но что бы заставить модель исполняться (симуляция) надо немного стараться.
Жаль тут нельзя кажись вешать файлы и картинки.
Хотя это вроде и тривиально сейчас выглядит (Знание Эксперта = Сумма знаний спецов) на меня это сильное произвело впечатление.
Реляционная модель должна автоматически сгенерироваться из метаданных модели (если в ней есть нужда — на сегодня эта нужда диктуется наличием мощной инфраструктуры)
.
Моделировать можно все и очень адекватно простыми расширениями имеющихся языков (нотаций) моделирования. Но что бы заставить модель исполняться (симуляция) надо немного стараться.
Жаль тут нельзя кажись вешать файлы и картинки.
Расширением нотаций задачу не решить. Это я как доктор говорю. Подробности раскрывать я не могу — это и коммерческая тайна отчасти, а по большей части просто требует огромного времени на объяснение причин. Но для меня очевидно — расширение не работает.
Если мы говорим о модели предприятия, то она состоит из структурно — поведенческой и процессной модели с количественной семантикой.
Все это спокойно описывается расширением ER (по части типизации отношений) + IDEF (введением количественной семантики).
Если у вас имеется методология сопоставления целей и процессов достижения этих целей (это самое сложное по части автоматизации), то считай все в кармане.
На счет доктора. Наши профессоры в этом деле сильно разочаровывают.
Все это спокойно описывается расширением ER (по части типизации отношений) + IDEF (введением количественной семантики).
Если у вас имеется методология сопоставления целей и процессов достижения этих целей (это самое сложное по части автоматизации), то считай все в кармане.
На счет доктора. Наши профессоры в этом деле сильно разочаровывают.
впрочем, не наши — тоже :)
семейство нотаций IDEF также как BPMN, также как EPC не решают задачу в принципе. У них есть одна важная ошибка, про которую я не написал в статье, но которая сводит на нет все преимущества этих нотаций. И расширять эти нотации невозможно по причине этой ошибки. Про нее и то, как мы ее преодолели — отдельный разговор. Но в итоге мы получили нотации, совершенно непохожие на уже существующие. И то, что мы получили, не решается расширением существующих нотаций.
Версия о том, что модель предприятия состоит из структурно-поведенческой модели вызывает у меня сомнение, потому что я могу задать любой интересующий меня вопрос и должен получить на него ответ. Почему мои вопросы должны ограничиваться только этими аспектами, почему я не должен задавать вопросы, которые выходят за ее границы? Также как и в вопросе о процессной. Я скажу кощунственную вещь, но я не видел ни одной нотации, в которой описывались бы процессы. Хотя… Есть диаграмма Ганта. Она описывает процесс. Остальные нотации описывают модель моделей процессов, но не процесс.
Любой интересующий вопрос в Контексте.
Обобщенный контекст — пространство, время, материя, процесс, воля.
Просто увидел «Точка зрения» — новое понятие и не удержался дать ссылку на 1980 г., можно было и поискать до царя Соломона.
Обобщенный контекст — пространство, время, материя, процесс, воля.
Просто увидел «Точка зрения» — новое понятие и не удержался дать ссылку на 1980 г., можно было и поискать до царя Соломона.
волю мы не моделируем. Мы моделируем в том числе происшествия, происходящие помимо нашей воли. Это принципиальное отличие от того, что принято считать процессом. Это же касается любой технологии — например, вращения Земли вокруг Солнца, ее же никто не вращает))
Это называется ситуационное управление — для тех у кого мало воли :)
А есть еще управление ситуацией.
Различие — капитан в море управляет судно в зависимости от погоды (ситуационное управление), но некоторые капитаны управляют погодой — обеспечивают благоприятные условия для своего судна (управление ситуацией).
Ладно. Моделируйте.
А есть еще управление ситуацией.
Различие — капитан в море управляет судно в зависимости от погоды (ситуационное управление), но некоторые капитаны управляют погодой — обеспечивают благоприятные условия для своего судна (управление ситуацией).
Ладно. Моделируйте.
новое понятие «точка зрения» присутствует в нашей информационной модели. Я не видел еще ни одной информационной модели, где присутствовал бы ID точки зрения.
Я дал ссылку на Мартина Дж. Это учебник.
Все Use case, Интервью и т.д. нацелены на выяснение Точек зрения, что бы аналитик потом эти точки слил в единую модель предметной области.
Все Use case, Интервью и т.д. нацелены на выяснение Точек зрения, что бы аналитик потом эти точки слил в единую модель предметной области.
Невозможно слить в одну точку зрения то, что не сливается в одну. Например, с точки зрения двух флотилий ситуация выглядит противоположным образом. Друзья и враги меняются местами
В чём в итоге делали модель? Архимейт не подошёл, как я понял?
Архимейт сделал две ошибки — первая он рассматривает деятельность и только ее. Часть же производственных задач не относятся к деятельности, как-то техпроцессы, например. Вторая — он не решил задачу описания деятельности, так и не связав бизнес-функцию и операцию, не поняв, что такое процесс и в чем его отличие от типового процесса.
Часть же производственных задач не относятся к деятельности, как-то техпроцессы, например.Техпроцессы — это то что автоматизированно? Если да, то это вполне себе деятельность, которая в архимейте будет представлена бизнес-функцией или бизнес-процессом, а в связке со слоем Application и\или Technology будет реализовываться конкретным софтом\автоматом.
деятельность — это психическая функция субъекта. Нас часто не интересуют психические функции субъектов, часто нам интересны проявления законов природы, которые приводят нас к тем или иным решениям, например, камень падает на землю и мы используем это в нашей технологии. Разница в вопросах, которые мы задаем при этом. Деятельность везде ищет акторов, активность — участников. Разница гигантская, но не осознаваемая большинством аналитиков, в том числе не осознаваемая создателями Архи.
> Часть же производственных задач не относятся к деятельности, как-то техпроцессы, например
Эээ. Не уверен, что понял.
Эээ. Не уверен, что понял.
Деятельность — это психическая функция субъекта, я же не моделирую психические функции. Мне интересны факты, в которых нет места психическим функциям человека. Меня интересуют технологии, в которых субъект выполняет роль механизма, а не творца.
Описание такой схемы я уже приводил
Процесс, Процессор, Вход, Выход
Процессор — это то что вам нужен
Процессором может быть любой Ресурс (актив ваш)
Процессоры бывают (как минимум):
Активные
Пассивные
Мобильные
— Активно мобильные
— Пассивно мобильные
Стационарные
Разделяемые
…
Все это и много чего реализовано в ВИП.Производство, которая опирается на платформу моделирования предметной области ВИПРОС.
Процесс, Процессор, Вход, Выход
Процессор — это то что вам нужен
Процессором может быть любой Ресурс (актив ваш)
Процессоры бывают (как минимум):
Активные
Пассивные
Мобильные
— Активно мобильные
— Пассивно мобильные
Стационарные
Разделяемые
…
Все это и много чего реализовано в ВИП.Производство, которая опирается на платформу моделирования предметной области ВИПРОС.
Есть большая разница между описание активности и описанием деятельности. В деятельности есть актор, который что-то делает, есть входы и выходы. В описании активности нет ни входов, ни выходов, ни акторов. Но есть участники. Далее с моделью участников можно строить модели входов и выходов. Но это уже другая модель, которую мы не рассматриваем. Ровно как и процессы — нас не интересует их классификация. Нас интересуют только факты без их интерпретации. Интерпретация фактов производится при переходе от фактов к точке зрения на факты, но не ранее
Какая та каша. Я вообще то классифицировал Процессоры (акторы, участники и т.д. в вашем понимании), а не Процессы.
Неужто вы думаете что «актор» отличается от «участник» пока не даны определения?
Что такое «факт» без интерпретации? Как он становится фактом, а не абракадаброй (раз нет интерпретации факта в каком то контексте)?
Неужто вы думаете что «актор» отличается от «участник» пока не даны определения?
Что такое «факт» без интерпретации? Как он становится фактом, а не абракадаброй (раз нет интерпретации факта в каком то контексте)?
Вход — это интерпретация, участник — нет. Мы видим, что железяка участвовала в операции. Мы можем сказать, что с одной точки зрения железяка была входом в операцию, с другой — выходом из операции. Мы констатировали тот факт, что железяка была, но интерпретировать ее как вход или выход мы не стали, потому что это не наше дело.
Послушайте.
Операция, Вход и т.д. имеет свое определение. И каждая Железяка в Этой Операции имет свою Роль — Вход, выход, Процессор.
Другого не дано.
Если у вас Операция определено с одной Ролью — Участники, то и фиг с ним. Все у вас ВСЕГДА будут Участниками и никаким образом Входом и т.д., так как не существует в вашей концептуальной модели таких концептов.
Операция, Вход и т.д. имеет свое определение. И каждая Железяка в Этой Операции имет свою Роль — Вход, выход, Процессор.
Другого не дано.
Если у вас Операция определено с одной Ролью — Участники, то и фиг с ним. Все у вас ВСЕГДА будут Участниками и никаким образом Входом и т.д., так как не существует в вашей концептуальной модели таких концептов.
Да, для моделирования активов нам не нужны ни акторы, ни входы ни выходы. Тот или иной участник станет входом, или выходом в зависимости от смотрящего на это субъекта. Надо — мы смоделируем любую точку зрения на операцию, не надо — не будем, но всю необходимую для трассировки информацию, мы имеем без привлечения лишних сущностей типа актор, вход и выход. Это лишняя информация, загрязняющая модель. И именно такую нотацию мы и разработали.
В одной точке зрения входом может быть один объект, а выходом — другой, а с другой точки зрения — эти объекты меняются местами, вход становится выходом, а выход — входом. Простой пример такого переворота я приводил в одной из статей, когда все менялось в зависимости от того, что считалось входом и выходом — объект на полке, или пустое место на полке. Понятно, что пустое место «движется» навстречу" объекту. И в зависимости, что мы учитываем — пустые места на складе, или объекты, хранимые там, входы и выходы будут меняться местами. Поэтому бессмысленно говорить о входах и выходах, потому что это субъективная интерпретация существующих фактов
Каша в башке.
Есть Процесс хранения.
Есть на входе Объект.
На выходе Объект.
Есть Процесс Установки Объект на Полку.
Где имеется Активность Процессоров Устанавливающего Объект на Полку и Полка.
Процесс блокирует мощность процессоров. Какая та часть мощности Полки будет заблокировано Объектом пока его не уберут.
Есть Процесс хранения.
Есть на входе Объект.
На выходе Объект.
Есть Процесс Установки Объект на Полку.
Где имеется Активность Процессоров Устанавливающего Объект на Полку и Полка.
Процесс блокирует мощность процессоров. Какая та часть мощности Полки будет заблокировано Объектом пока его не уберут.
как я сказал, нас не интересуют входы и выходы, потому что это другая модель. Нас интересуют только участники операции. Интерпретировать, кто из участников был входом, а кто выходом, — мы оставляем на долю того, кому это интересно. Для моделирования активов предприятия — это ненужная задача.
Да вы даже не дали определение «актива» и «предприятия».
И ваще непонятна цель моделирования активов :)
И ваще непонятна цель моделирования активов :)
под активом понимается все, что требует учета: операции, функциональные объекты, физические лица, должности, события и прочее. Я называю это единицами учета, но для пущей важности мы сделали более распространенное название — актив предприятия. Просто потому что в частном случае этими же принципами описываются активы в общепринятом их смысле: как функциональные и физические объекты.
О, а я знаю место на КПДВ! Это Падун на Умбе :)
Само понятие модели и есть Ваши точки зрения. Модель — это когда от реального отбросили не важное для текущей цели и оставили важное. По сути у Вас разные модели одного итого же «насоса».
И как сказано, сложность ИТОГО слишком велика, куча моделей с кучей связей. Честно, не осилил чем такая куча моделей поможет менеджеру по продажам. Ему же нужно «коридор» протоптать через «сложность бытия» с минимальным количеством ветвлений (что бы не запутался). Т.е. упростить мир, а не усложнить.
PS А по определению инстанса, вроде все просто (даже на вики есть). Например, есть мастер построения отчетов с кучей параметров и конкретные отчеты из него. Каждый отчет, который получили каким то набором значений в параметрах мастера, и есть инстанс. Класс делает объекты, печка — булочки =)
И как сказано, сложность ИТОГО слишком велика, куча моделей с кучей связей. Честно, не осилил чем такая куча моделей поможет менеджеру по продажам. Ему же нужно «коридор» протоптать через «сложность бытия» с минимальным количеством ветвлений (что бы не запутался). Т.е. упростить мир, а не усложнить.
PS А по определению инстанса, вроде все просто (даже на вики есть). Например, есть мастер построения отчетов с кучей параметров и конкретные отчеты из него. Каждый отчет, который получили каким то набором значений в параметрах мастера, и есть инстанс. Класс делает объекты, печка — булочки =)
модель не есть точка зрения. Модель строится исходя из определенной точки зрения. Ранее об этом написал sand14 Тема называется: Multi-viewpoint ontology и Multi-viewpoint ontology construction and classification
Пара вопросов:
1) чем обусловлены ошибки в тексте?
2) заказчик заплатил за работу?
1) чем обусловлены ошибки в тексте?
2) заказчик заплатил за работу?
Если Вы нашли ошибки, помогите их исправить, пожалуйста. Две я поправил.
второй вопрос относится к коммерческим интересам и потому я не имею права на него отвечать.
второй вопрос относится к коммерческим интересам и потому я не имею права на него отвечать.
Я же Вас не спрашиваю сколько :) да или нет?
«В этой статье я хочу рассказать о практике применении стандарта ИСО 15926» — «применения», хотя практикой я бы это не назвал.
«сложность обусловленная разрывом» — «обусловлена».
От такого названия и вступления ожидал большего, честно говоря.
«В этой статье я хочу рассказать о практике применении стандарта ИСО 15926» — «применения», хотя практикой я бы это не назвал.
«сложность обусловленная разрывом» — «обусловлена».
От такого названия и вступления ожидал большего, честно говоря.
Спасибо за указание ошибок!
Конечно заказчик заплатил. Вы же понимаете, что я не раскрыл деталей модели? Есть несколько ключевых моментов, без которых эта модель не взлетит. Раскрывать их я не имею права.
Однако, найти людей, которые работают в этом направлении, я бы хотел. Те, кто в теме, откликнутся, кто не в теме, могут задуматься о неочевидности простых решений. Это была цель моей статьи. Тема моделирования активов — невероятно сложная. Раскрыть все аспекты в одной статье нереально. Но познакомить читателя с задачей и сказать, что есть те, кто ее решают, — можно.
Стандарт ИСО 15926 выступил в роли идеологической основы, но не в качестве руководства к действию. Я не нашел в этом стандарте множественности точек зрения, но нашел время, как равноправную координату наравне с другими тремя. Именно это было взято для работы, а не предустановленные классы.
Конечно заказчик заплатил. Вы же понимаете, что я не раскрыл деталей модели? Есть несколько ключевых моментов, без которых эта модель не взлетит. Раскрывать их я не имею права.
Однако, найти людей, которые работают в этом направлении, я бы хотел. Те, кто в теме, откликнутся, кто не в теме, могут задуматься о неочевидности простых решений. Это была цель моей статьи. Тема моделирования активов — невероятно сложная. Раскрыть все аспекты в одной статье нереально. Но познакомить читателя с задачей и сказать, что есть те, кто ее решают, — можно.
Стандарт ИСО 15926 выступил в роли идеологической основы, но не в качестве руководства к действию. Я не нашел в этом стандарте множественности точек зрения, но нашел время, как равноправную координату наравне с другими тремя. Именно это было взято для работы, а не предустановленные классы.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Моделирование активов предприятия: современные стандарты и практика