Метамодель для моделецентрического управления требованиями

[vvagr]

Набор UML-диаграмм, отражающих контекст и артефакты моделеориентированной инженерии требований и, частично, архитектурного дизайна.

Comments

[109]

диграмма 1.

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

cardinality. надо как-то определиться, хотим мы её показывать графически (жирным кружком или ромбом) или текстуально [1..n]. если текстуально, то хорошо бы не забыть, что её (cardinality) имеют оба конца.

диграмма 2.

уже иногда появляются [1..n] с обоих концов, что не может не радовать. но вот отношение между, скажем, требованиями и ограничениями симметричное, а стрелка почему-то нет.

дальше лень.

[vvagr]

Д1. Тут некоторая избыточность - не лишняя, разделение на системы и элементы - вещь субъективная. Это мета-модель для человека, что-то вроде формальной записи для машинной генерации кода - пока очень далека, на данном уровне общности такого не появится.

cardinality 1..1 моделер просто не рисует, если где-то не подписано - там 1. Это UML моделер в составе Papyrus плагина в Ecliplse, кстати. Жирный ромб - это вроде как composite aggregation, к cardinality отношения не имеет.

Д2. Отношение (в данной системе терминов!) совершенно не симметричное. Ограничение - один из видов компонент требования.

Ну лень так лень. И на том спасибо.

[109]

> Ограничение - один из видов компонент требования.

правильно, значит "requirement" contains one or more (zero or more?) "constraints". значит отношение 1 -> 1..n или 1 -> 0..n, а нарисовано что?

[vvagr]

Э нет. Разные стейкхолдеры могут совершенно независимо в свои требования вписать один и тот же constraint.

А вот насчёт 0 - спасибо, надо править.

[sergeyvi]

Для того, чтобы предлагать конструктивно, было бы осмысленно дать определения, т.к. явно не весь контекст поместился в картинки

[vvagr]

Разумеется не уместился. Тексты тоже выложим, если методику и метамодель удастся последовательно отделить от специфики клиента.

При реальном сборе требований должностные лица не встречаются :-) Организации, как ни странно, встречаются (кстати, они и представлены должностными лицами).

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

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

Но вообще-то дополнительны связи как раз картинку ещё путают. Необходимо помещать её в контекст процесса работы с этими артефактами, вот тогда становится понятнее.

[sergeyvi]

> При реальном сборе требований должностные лица не встречаются

[vvagr]

Ну тут надо начинать с того, что такое организация. В тесно связанных холдингах что департамент, что дочерняя компания - могут считаться организациями. Но, наверное, действительно я тут отразил некие "корпоративные традиции" кдиента, которыми и сам пропитался :-)

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

А "как у дяди Васи" - это всё же превращается либо в цель, либо в конкретное решение на самом раннем этапе работы собирателя требований.

Что такое система?

[nanotekhnolog]

В диагр. 1 Система определяется через элементы и подсистемы. Я бы предложил определять систему как отграниченную от остального мира часть мира. Отграничение осуществляется Наблюдателем, который собственно и имеет целеполагание относительно Системы, и именно ради этого целеполагания он и выделяет Систему в Мире. Прошу пообсуждать. (При этом не следует потерять такие важные характеристики Системы, как составность из Элементов; и эмержентность).

Re: Что такое система?

[vvagr]

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

Какая система?

[evan_r11]

А ваша система "предпринятие" или абстрактный методологический элемент?

Re: Какая система?

[vvagr]

Нет, эти диаграммы придуманы для моделирования узкого класса систем - рабочих продуктов "предпринятия", причём относящихся к типу "модель". Диаграмма 1, впрочем, применима к любому рабочему продукту типа "система", включая железные продукты. А вот начиная с Диаграммы 2 - идут модели только для моделей требований, моделей систем, моделей целей и т.п.

Для самого предпринятия нужны иные специфичные классы, как я пока думаю.

Re: Какая система?

[evan_r11]

Универсальная диаграмма 1 - слишком абстрактный предмет для обсуждения. Нужно таки идентифицировать объект типа "Система" либо как типа "железный продукт" (стоит "в поле" и из трубы дым идёт), либо как типа "модель" (допустим того же железного продукта). А лучше отразить оба со взаимо- и прочими связями.

Re: Какая система?

[vvagr]

На дальнейших диаграммах чётко показано, что Система с диаграммы 1 - это то, в отношении чего строятся модели. То, что модель тоже "система" - несомненно так, но не интересует нас в данном рассмотрении.

Кстати, опуболикованы новые версии.