Комментарии 85
В англоязычном мире это устоявшиеся термины, и в моделировании активно используется подход с использованием множества точек зрения.
У нас же этого в бизнес-анализе и моделировании нет.
Разработчик может самостоятельно дойти до Multi-viewpoint идей, работая над traceabity system и параметризованной базой данных, но в аналитике этого до сих пор (до работ maxstroy) не было.
И — а нужно ли сообщать об этом Левенчуку?)
Довольно интересно прийти к мысли о множественности точек зрения через анализ задачи трейсабилити. Я вполне допускаю, что это возможно, но хотелось бы узнать этот путь поподробнее.
Левенчуку стоит знать.Он читает лекции на тему системной инженерии. И без осознания того, что мы строим модели через свое восприятие познать системную инженерию невозможно, ИМХО.
Довольно интересно прийти к мысли о множественности точек зрения через анализ задачи трейсабилити. Я вполне допускаю, что это возможно, но хотелось бы узнать этот путь поподробнее.
Необходимость в Traceability системе возникает, когда на предприятии нужно выстроить процесс, работающий на единую цель, на все предприятие.
Для этого необходимо нейтрализовать негативные последствие того факта, что каждое подразделение со своим руководством по факту работает на себя, и смотрит на процесс только со своей точки зрения.
И при этом оставить положительную сторону, когда подразделение выполняет свою часть общей работы.
Для этого необходимо, в дополнение к ERP-системе, разработать систему, условно, MES-уровня, которая будет точным образом фиксировать все атомарные события и операции в разрезе «что-где-когда-на каком основании».
И тогда, с одной стороны, мы будем иметь «рентгенографический» снимок всего, что происходило на предприятии, действительно первичную информацию, свободную от точек зрения и интересов каждого подразделения.
На основании собранной информации будут формироваться обобщенные данные для принятия управленческих решений как на уровне подразделений (в их интересах), так и на уровне руководства, координирующего совместную работу подразделений — в интересах предприятия в целом.
Для решения этих задач необходимо:
1. Разработать параметрически настраиваемую систему для сбора любых (атомарных) данных в каждой из точек производственного процесса.
В качестве реализации такой системы может выступать параметризованная реляционная БД (или графовая БД), позволяющая представить любой объект в виде универсальной конструкции и содержащая журнал (лог) всех атомарных операций.
Разнородные (зависящие от видов операций) данные для каждой строки журнала будет представляться в виде конструкции.
2. Для работы с такой базой данных необходим разработать соответствующее API.
С одной стороны, это API обеспечит работу с «конструкциями», журналом операций и другими универсальными структурами БД.
С другой — API должно предоставить возможность работать с объектами БД в терминах предметной области, и формировать обобщенные данные для каждого из подразделений и координирующего руководства (см. выше).
Итак, как только мы реализовали MES-систему в соответствии с этими принципами, на шаге 1 она превратилась в Traceability систему, а на шаге 2 мы обнаруживаем, что это полноценная Multiview-point система, разработанная эмпирическим путем.
Остается шаг 3 — проработать эту систему на уровне аналитики/моделирования/онтологии, и повторить путь программной реализации заново, получив на порядок или два более качественный результат, как с точки зрения архитектуры продукта, так и с точки зрения его бизнес-полезности.
Это называется SCADA и полно таких вещей.
2. Для работы с такой базой данных необходим разработать соответствующее API.
БД и т.д. вторична.
МЕС = Управляемая Модель предприятия в динамике (меса.орг и т.д. выкидываем за скобку).
Multiview-point тут не при чем — есть владельцы, их цели, процессы для достижения целей, ресурсы, управленческие политики.
В общем случае характер производства или процесса может было такой, что SCADA система не подойдет (вплоть до того, что процесс вообще может быть чисто организационным).
(Подробное описание системы, возможно, будет в отдельной публикации.)
Что до вторичности БД и АПИ, то я бы посоветовал вам вчитаться в комментарии, прежде чем отвечать.
Я об этом и пишу, что за неимением должной аналитики и онтологии, разработчик сам может дойти до Multiviewpoint-идей, если ему попадется подходящая задача (в первую очередь это Traceability).
И тогда появятся описанные БД и API.
А чтобы БД и API были реализованы с должным качеством, должна быть проработана первичная вещь — Multi-viewpoint аналитика.
Но здесь проблема — понятия аналитики и аналитиков у нас девальвированы (ну так, раз в 100 — все сводится в разработке макетов форм).
А за неимением аналитики только часть архитектурных вещей системы можно верно задать на уровне проработки архитектуры БД и API.
Ничего не девальвировано, просто не было такого слоя у нас — постановщики не доросли до аналитиков, а менеджмент и владельцы — до определителей целей, так как временной интервал для принятия решения никого не устраивает — нет законности и порядка.
В общем, я пас.
Про моделирование целей субъекта, его деятельности и т.д. могу поговорить, но тут вроде никак картинки не прицепишь, а это не интересно — приходится много писать наезженных слов, а их каждый понимает по своему да и пропадает рекламная составляющая.
Появление англоязычной работы maxstroy на тему Multi-viewpoint ontology привело меня в удивление:
Если вначале термин «точка зрения» казался хотя и кратким/емким, но все равно самобытным и местечковым определением длинного описания системы, приведенного в моем комментарии выше,
то затем внезапно оказалось, что там, где этим занимаются, это устойчивым образом называется Multi-viewpoint ontology (и термин construction там тоже есть, что характерно!).
И если разработчикам не знать этого простительно, то… как же так получается, что многочисленные современные консультанты, занимающейся системной инженерией, аналитикой, разработкой, оптимизацией и внедрением (бизнес-)процессов, этого даже не знают хотя бы на уровне терминологии — мол, есть такая Multi-viewpoint парадигма построения систем и процессов.
Ну а поскольку ничего подобного нет на уровне постановки задач и аналитики, но ничего подобного не наблюдается и на уровне разработки (программной реализации).
И если разработчикам не знать этого простительно
Вообще, разработчики про это знают и давно. В ненавистном ООП есть такая вещь как интерфейс (и interface segregation principle), благодаря которой один и тот же объект может восприниматься разными потребителями совершенно разным образом.
ООП вообще не про моделирование предметной области. Он про моделирование кода.
Во-первых, это утверждение, как неоднократно обсуждалось, неверно, причем в обеих своих частях. ООП не про моделирование кода, просто потому, что я могу не иметь модели кода вообще, но при этом иметь ООП. Во-вторых, ООП может использоваться для моделирования предметной области (конечно, с учетом его ограничений) — в том случае, если моделью выступают объекты программы.
Но речь не об этом. Интерфейс здесь исключительно при том, что понятие "точки зрения" разработчикам, как ни странно, знакомо, в том числе и применительно к объектам предметной области; просто под другим названием.
А при чем тут разработчики?
"конечно, с учетом его ограничений".
Ну и статью уже разобрали как несостоятельную.
ОПП задает объектную (структурно-поведенческую) часть, процессный дополняет до деятельности, а декомпозия целей до выходов процессов — включает волю.
Для меня — Деятельность — выработка целей и генерация, запуск и мониторинг обеспечивающих процессов для достижения этих целей.
Процесс — упорядоченный набор активностей процессоров во времени и в пространстве.
Процессор — ресурс с активной ролью, который не является потребностью (входом) или предложением (выходом) процесса
Вход процесса — то что процесс потребляет(трансформирует)
Выход — то что процесс генерирует
Ресурс — все что угодно (включая «объект», «процесс»)
Межпроцессная коммуникация — потоки на связях.
Связь соединяет процессы — задает отношение предшествования и темпоральную составляющую (относительные смещения во времени)
Связь может нести потоки — темпоральные, материальные, информационные, финансовые…
В принципе это концептуальная модель полностью описывает любое предприятие.
первое достижение целей субъекта со свободой выбора процессов достижения целей, а второе регламентированное участие в процессе.
И таки с второго первое не получишь, а первое всегда можно зарегламентировать и получить второе.
И вообще, мне кажется «моделирование активов» не очень звучит — или это Описание активов конкретного предприятия или просто Моделирование объектов независимо от предприятия и т.д.
Моделирование активов хорошо тогда, когда актив перемещается по предприятию, или меду предприятий и не требует смены БД для его учета. Хотя в одном случае это был молоток, а в другом — лом. В одном — инструмент, в другом — материальная ценность. Один и тот же предмет имеет разные трактовки в зависимости от того, кто на него смотрит. Поэтому мы вынуждены отделять трактовку объекта от констатации факта его наличия.
А вообще есть стандарт ISO 42010, который вводит понятия Viewpoint и View, определяя метамодель для 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, способ разложения) определяется не субъектом, смотрящим на объект, а интересом субъекта. У двух субъектов может быть один интерес и поэтому точка зрения у них будет одинаковая.
Так же в Архимейте в разделе 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 — это само описание (модель).
В таком разделении выносить объект «точка зрения» в информационную модель не корректно — это метамодель.
Не очень понимаю, что Вы называете «одной парадигмой» Левенчука. Однако даже в общем курсе системного мышления рассказывается минимум о трёх точках зрения.
Разделение объекта на функциональные подсистемы и функциональные модули — это что-то странное, модули (в нашей терминологии) всегда физические. А вот если Вы имели в виду разделение на функциональные подсистемы и функциональные компоненты — это общее место, вообще-то, реализованное во всех САПР.
Хотя это вроде и тривиально сейчас выглядит (Знание Эксперта = Сумма знаний спецов) на меня это сильное произвело впечатление.
Реляционная модель должна автоматически сгенерироваться из метаданных модели (если в ней есть нужда — на сегодня эта нужда диктуется наличием мощной инфраструктуры)
.
Моделировать можно все и очень адекватно простыми расширениями имеющихся языков (нотаций) моделирования. Но что бы заставить модель исполняться (симуляция) надо немного стараться.
Жаль тут нельзя кажись вешать файлы и картинки.
Все это спокойно описывается расширением ER (по части типизации отношений) + IDEF (введением количественной семантики).
Если у вас имеется методология сопоставления целей и процессов достижения этих целей (это самое сложное по части автоматизации), то считай все в кармане.
На счет доктора. Наши профессоры в этом деле сильно разочаровывают.
Обобщенный контекст — пространство, время, материя, процесс, воля.
Просто увидел «Точка зрения» — новое понятие и не удержался дать ссылку на 1980 г., можно было и поискать до царя Соломона.
А есть еще управление ситуацией.
Различие — капитан в море управляет судно в зависимости от погоды (ситуационное управление), но некоторые капитаны управляют погодой — обеспечивают благоприятные условия для своего судна (управление ситуацией).
Ладно. Моделируйте.
Все Use case, Интервью и т.д. нацелены на выяснение Точек зрения, что бы аналитик потом эти точки слил в единую модель предметной области.
Флотилия есть флотилия, друзья есть друзья, а враги — враги.
Все это определено заранее.
Часть же производственных задач не относятся к деятельности, как-то техпроцессы, например.Техпроцессы — это то что автоматизированно? Если да, то это вполне себе деятельность, которая в архимейте будет представлена бизнес-функцией или бизнес-процессом, а в связке со слоем Application и\или Technology будет реализовываться конкретным софтом\автоматом.
Эээ. Не уверен, что понял.
Процесс, Процессор, Вход, Выход
Процессор — это то что вам нужен
Процессором может быть любой Ресурс (актив ваш)
Процессоры бывают (как минимум):
Активные
Пассивные
Мобильные
— Активно мобильные
— Пассивно мобильные
Стационарные
Разделяемые
…
Все это и много чего реализовано в ВИП.Производство, которая опирается на платформу моделирования предметной области ВИПРОС.
Неужто вы думаете что «актор» отличается от «участник» пока не даны определения?
Что такое «факт» без интерпретации? Как он становится фактом, а не абракадаброй (раз нет интерпретации факта в каком то контексте)?
Операция, Вход и т.д. имеет свое определение. И каждая Железяка в Этой Операции имет свою Роль — Вход, выход, Процессор.
Другого не дано.
Если у вас Операция определено с одной Ролью — Участники, то и фиг с ним. Все у вас ВСЕГДА будут Участниками и никаким образом Входом и т.д., так как не существует в вашей концептуальной модели таких концептов.
Ну написали вы учет складской (если считать что они тоже участники, но стационарные) с перемещениями «Участников», а говорите про какие то страшные вещи :)
Есть Процесс хранения.
Есть на входе Объект.
На выходе Объект.
Есть Процесс Установки Объект на Полку.
Где имеется Активность Процессоров Устанавливающего Объект на Полку и Полка.
Процесс блокирует мощность процессоров. Какая та часть мощности Полки будет заблокировано Объектом пока его не уберут.
И ваще непонятна цель моделирования активов :)
И как сказано, сложность ИТОГО слишком велика, куча моделей с кучей связей. Честно, не осилил чем такая куча моделей поможет менеджеру по продажам. Ему же нужно «коридор» протоптать через «сложность бытия» с минимальным количеством ветвлений (что бы не запутался). Т.е. упростить мир, а не усложнить.
PS А по определению инстанса, вроде все просто (даже на вики есть). Например, есть мастер построения отчетов с кучей параметров и конкретные отчеты из него. Каждый отчет, который получили каким то набором значений в параметрах мастера, и есть инстанс. Класс делает объекты, печка — булочки =)
1) чем обусловлены ошибки в тексте?
2) заказчик заплатил за работу?
второй вопрос относится к коммерческим интересам и потому я не имею права на него отвечать.
«В этой статье я хочу рассказать о практике применении стандарта ИСО 15926» — «применения», хотя практикой я бы это не назвал.
«сложность обусловленная разрывом» — «обусловлена».
От такого названия и вступления ожидал большего, честно говоря.
Конечно заказчик заплатил. Вы же понимаете, что я не раскрыл деталей модели? Есть несколько ключевых моментов, без которых эта модель не взлетит. Раскрывать их я не имею права.
Однако, найти людей, которые работают в этом направлении, я бы хотел. Те, кто в теме, откликнутся, кто не в теме, могут задуматься о неочевидности простых решений. Это была цель моей статьи. Тема моделирования активов — невероятно сложная. Раскрыть все аспекты в одной статье нереально. Но познакомить читателя с задачей и сказать, что есть те, кто ее решают, — можно.
Стандарт ИСО 15926 выступил в роли идеологической основы, но не в качестве руководства к действию. Я не нашел в этом стандарте множественности точек зрения, но нашел время, как равноправную координату наравне с другими тремя. Именно это было взято для работы, а не предустановленные классы.
Моделирование активов предприятия: современные стандарты и практика