.RU

Что значит описать жизненный цикл и его практики - Понятие жизненного цикла и его практик


^ Что значит описать жизненный цикл и его практики
Для создания описания жизненного цикла и его практик недостаточно использовать процессный и проектный методы описаний в их классическом виде. Когда мы говорим о ЖЦ, то понимаем типовые активности (работы), внутри которых используются те или иные методы, описанные отдельно от их применений в жизненном цикле. Эти описанные отдельно методы, которые в терминологии ISO 15288 названы практиками (в оригинале – process, унаследованное из трансформационного описания), применяются в стадиях ЖЦ, сгруппированных в определенную последовательность и разделенных контрольными точками. Для того чтобы создать полноценное описание ЖЦ и его практик необходимо:

На основе этого списка видно, как должны поменяться процессная и проектная группы описаний.

В процессной группе происходит смена объекта рассмотрения. Очевиден переход к рассмотрению не только последовательности дел, но и их связанных групп – методов (практик, дисциплин), которые объединены общностью применяемой в их онтологией и зачастую общностью ролей, которые способны эти практики выполнять в силу знания этой онтологии. Методы (практики, дисциплины) также обеспечиваются руководствами по их использованию.

В проектной группе описания появляется другая специфика. Упор делается на последовательность и точки пересмотра ресурсов. Но, помимо процессной и проектной разверток деятельности во времени, при рассмотрении ЖЦ нас, прежде всего, интересует то, что обычно отражается на так называемой «горбатой» диаграмме (hump diagram). Она показывает применение практик во времени, то есть синхронизацию методов в рамках процесса ЖЦ. Классическим примером такой диаграммы является набор методов RUP (Rational Unified Process) для разработки программного обеспечения (см. рис 1). «Горбатую» диаграмму можно использовать рекурсивно, спускаясь на уровни более детальных и конкретных методов. Например, реализуя одну из практик RUP, а именно «Анализ и Проектирование» (Analysis and Design), можно воспользоваться набором методов, предложенных в MFESA (Method Framework for Engineering System Architecture) [31]. Пример описания этого набора методов с помощью горбатой диаграммы представлен на рис. 2. Подобные диаграммы наглядно показывают то, как и какие методы применяются на определенных стадиях проекта.



^ Рис. 1 Разумный унифицированный процесс (Rational Unified Process)



Рис. 2 Методический подход к инженерии системной архитектуры (Method Framework for Engineering System Architecture)

Очевидно, что ни процессная группа описаний, ни проектная группа описаний, ни их комбинация не могут обеспечить отражение всех аспектов, требуемых для описания ЖЦ и его практики. Требуется изменить точку зрения, сам метод описания, получить принципиально новое качество для описания того, как именно нужно выполнять работы в проекте/процессе. Такой метод описания может быть основан на подходе ситуационной инженерии методов.
  1. ^ Ситуационная Инженерия Методов (Situational Method Engineering)

В 80-х годах XX века начала формироваться специальная дисциплина, получившая название инженерия методов. Ее целью является обеспечение эффективных средств для создания и поддержки методов управления жизненным циклом разработки программных средств [5,6]. Результатом развития инженерии методов стало появление различных типовых наборов (frameworks) методов (methods, disciplines, practices, processes) для выполнения определенного вида работ. Набор методов выполняется определенными ролями в ходе установленных мероприятий в рамках конкретных стадий ЖЦ. К примерам наборов методов можно отнести CMMI, PMBoK, ITIL, ISO 12207, ISO 15288. Они описывались на основе вещного варианта трансформационного подхода, т.е. в терминах «процесса», подразумевающего последовательность трансформационных актов деятельности, склеенных через начальные и исходящие сущности. По сути, в прошлом инженерия методов представляла собой лишь такое процессное описание.

Каждый из наборов методов неявно включает в себя метамодель (онтологию, взятую в отрыве от нотации ее презентации, а также процесса описания) метода описания работ в ЖЦ. Позже фокус исследований был перенесен именно на эти метамодели: сначала они стали явно описываться, а затем и стандартизироваться.

Метамодель можно определить как описание модели. Она должна содержать средства выражения структуры и поведения необходимые для представления экземпляра целевой модели. Аналогично, любая модель системы содержит средства для выражения структуры и поведения экземпляра какой-либо целевой системы «в жизни». Таким образом, метамодель – это описание, в котором объектом изучения является сама модель, нежели какой-то другой тип систем. Метамодели могут описывать любой тип модели, но в данной работе мы концентрируемся на метамоделях, которые обеспечивают описание жизненного цикла системы и его практик.

В области разработки программных систем был создан ряд конкурирующих стандартизованных метамоделей, позволяющих описывать ЖЦ (например, SPEM 1.0 и OOSPICE). Со временем часть из них была перенесена в более широкий контекст системной инженерии и в настоящий момент они могут применяться для управления ЖЦ любых рукотворных систем, а не только ЖЦ программных средств.

Ограничения традиционной инженерии методов, неявно предполагавшей непосредственное применение метода независимо от ситуации, послужили предпосылками к появлению ситуационной инженерии методов (Situational Method Engineering). Она основана на идее о том, что набор методов, предназначенный для выполнения определенных работ, нельзя задать заранее: каждая система уникальна, имеет свой собственный уникальный жизненный цикл, к тому же исполнители задействуют разные инструменты для выполнения работы, поэтому каждая из систем в сочетании с используемыми инструментами требует для себя уникального метода работы. Утверждается, что какие-то куски/фрагменты методов все-таки можно выделить и хранить для повторного использования, но для конкретной системы и набора инструментов из таких кусков нужно в зависимости от ситуации собирать ее уникальный набор методов в уникальной последовательности. Такой набор будет продвигать эту систему по ее уникальному жизненному циклу, учитывая уникальную специфику и уникальные риски, соответствующие ситуации. Тем самым утверждается, что людям нельзя дать универсальный метод, но можно дать конструктор методов с достаточным количеством этих кусков/фрагментов, который позволит породить необходимый специализированный метод по потребности [29].

Особенностью ситуационной инженерии является явное отделение методов от (макро)процесса в рамках, которого они используются. Метод – это систематический, документированный, осознанный (intended) способ, которым должна быть выполнена работа. В методе вполне могут быть шаги, но заранее неизвестно, в какой момент этот метод будет выполняться в конкретном жизненном цикле. Метод – это единица повторной используемости. (Макро)процесс, в контексте инженерии методов, – это способ, которым выполняется работа "в жизни". Можно сказать, что процесс – это применения методов, происходящие в конкретные интервалы времени (и тем самым тесно переплетенные между собой в силу параллельности применения). Процесс – это всегда развертка во времени. Впрочем, описания процесса тоже могут использоваться повторно, быть типовыми: тогда говорят о "шаблонах процесса" (в SPEM это capability patterns). Объемлющий все другие процессы процесс – это и есть жизненный цикл, который тем самым описывается в терминах применения методов.

Ситуационная инженерия методов породила новое по отношению к «просто» инженерии методов поколение метамоделей, которые могут применяться для описания ЖЦ. Наличие нескольких таких метамоделей порождает проблему выбора. Существует ряд исследований, сравнивающих метамодели на базе различных признаков. Ниже приведено описание основных характеристик, служащих базой для классификации существующих метамоделей описания ЖЦ.
^ Используемые понятия
Одним из подходов к классификации и сравнению метамоделей ситуационной инженерии методов является рассмотрение используемого метода описания (viewpoint) процесса ЖЦ и его практик в терминах выделяемых в разных метамоделях понятий. Подобная классификация предложена в работе франко-австралийской команды исследователей [7]. Ниже приведено краткое описание выделенных классов. Далее, утверждая, что метамодель основана на чем-то, мы подразумеваем понятия, являющиеся для нее центральными.

Описание метамодели может создаваться с помощью разных методов. В настоящей работе для их моделирования применяется диаграмма классов UML. Язык UML широко распространен, он получил такую популярность за счет обеспечения различных групп описаний в рамках одной метамодели. UML имеет и недостатки, в настоящий момент разработана критика этого языка. Одно из основных ее положений в том, что никакого стандартного языка не может быть достаточно для удовлетворения потребностей различных заинтересованных лиц в силу наличия множества различных предметных областей, которые плохо описываются в терминах предписываемых UML видов диграмм. Однако, в настоящий момент стали достаточно развиты средства трансформации моделей из одних языков описания в другие. Для трансформации моделей UML в модели на других языках создано достаточное количество средств, поэтому можно не уделять большого внимания репрезентации метамодели в том или ином языке. Основной объект рассмотрения – это концептуальные схемы, предлагаемые метамоделями ситуативной инженерии методов, а не их «родные» репрезентации в UML, OWL или других языках онтологической работы.
^ Метамодели на основе деятельности (activity-oriented process metamodels)
Метамодели на основе деятельности позволяют создавать описания методов фокусирующиеся на актах деятельности (activities and tasks), выполняемых при производстве требуемых продуктов, а также порядке их выполнения. Обычно они включают в себя концепции «Единица Работы» / «Работа» (Work Unit / Work Definition), которые используют «Продукты» в качестве исходных и конечных сущностей (inputs and outputs), и которые выполняются «Ролями».

Такие метамодели как SPEM, The Open Process Framework, ISO 24744 преимущественно основаны на актах деятельности. Некоторые из них включают в себя и другие методы описания. Например, SPEM и ISO 24744 поддерживают, с разной степенью детализации, метод описания на основе продуктов.

Описания методов RUP, XP, SCRUM представляют собой экземпляры, порожденные на основе деятельность-ориентированных метамоделей, и, следовательно, о них можно говорить как о деятельность-ориентированых.

На рис. 3 приведена выдержка из метамодели SPEM 1.1 [8]. «Работа» (WorkDefinition) может представлять собой конкретный «АктДеятельности» (Activity), «Стадию» (Phase), «Итерацию» (Iteration) или сам «ЖизненныйЦикл» (Lifecycle) (в SPEM 2.0 [9] эти концепты несколько изменились). «Работа» описывает деятельность, выполняемую в рамках (макро)процесса. Концепт «Роль» (ProcessRole) определяет ответственность за конкретный «Продукт» (WorkProduct) и устанавливает роли, выполняющие и помогающие выполнять определенные дела. Метакласс «ПараметрАктаДеятельности» (ActivityParameter) позволяет специфицировать входы и выходы («Продукты») для «Работы».



Рис. 3 Выдержка из метамодели SPEM 1.1
^ Метамодели на основе продукта (product-oriented process metamodels)
Метамодели на основе продукта позволяют порождать описания методов, связывающие состояние продукта (product state) с делами (activities), генерирующими это состояние. Они опираются на концепт «Продукт», который имеет различные «Состояния» и переходы между ними. Состояние продукта отражает его положение в конкретный момент процесса жизненного цикла, выделенные переходы между состояниями отражают порядок, согласно которому состояние может изменяться. Переход – это связь между исходным состоянием и целевым состоянием. Он инициируется событием.

Примерами метамоделей на основе продукта, использующих описанные концепты, являются метамодель диаграммы состояний (Harel Statechart) и машины состояний (UML State Machine), а также менее распространенные метамодель Entity Process Model и State-Transition template.

На рис. 4 в качестве примера метамодели на основе продукта, показана упрощенная метамодель подхода State-Transition, описанного Финкельштейном [10]. «Продукт» (Product) состоит из одного или более «Состояний» (States). «Переход» (Transition) определяется между исходным (source) и целевым (target) состояниями.



Рис. 4 Выдержка из метамодели подхода State-Transition
^ Метамодели на основе решений (decision-oriented process metamodels)
Данный класс метамоделей позволяет создавать описания методов, отражающие последовательную трансформацию продукта в связи с принятыми решениями. Во внимание принимается концепт «Вопрос», который нуждается в решениях, определенных как «Альтернативы». «Альтернатива» может поддерживаться или оспариваться «Аргументами». «Вопрос» – это проблема, которая возникает во время протекания ЖЦ системы. «Альтернативы» – это различные варианты решения вопроса, которые базируется на доказательствах, т.е. аргументах.

Метод управления ЖЦ на основе решений впервые упомянут в 1970 в контексте проектирования информационных систем на основе вопросов (Issue-Based Information Systems, IBIS). Позже он совершенствовался в рамках исследовательских проектов (например, DAIDA), но не получил широкого распространения.

На рис. 5 в качестве примера приведена метамодель, описанная Поттсом (Potts) [11] в 1989 году. Выполнение «Шагов» (Steps) – синоним дел – в процессе ЖЦ приводит к возникновению «Задач» (Issues). «Альтернативы» (Alternatives) предлагают решения задач и подтверждаются или опровергаются «Аргументами» (Arguments), которые ссылаются на «Артефакты» (Artefacts). «Задача» может просматривать «Артефакт», а «Шаг» может его модифицировать.



Рис. 5 Выдержка из метамодели Поттса
^ Метамодели на основе контекста (context-oriented process metamodels)
Этот класс метамоделей способствует созданию моделей методов, которые отражают ситуацию и намерение Деятеля (Actor) в конкретный момент ЖЦ. Связка «Положение» - «Намерение» образует «Контекст». Эти концепты являются ключевыми для метамоделей на основе контекста. Положение – это часть проектируемого продукта, касательно которой должно приниматься решение. Намерение отражает цель, которую, в соответствии с положением, стремится достичь деятель.

Понятие контекста было дано в 1990 году, а позже получило окончательную форму в рамках европейского проекта NATURE и одноименной метамодели метода управления ЖЦ. В 2000 году метамодель NATURE была адаптирована к дисциплине Управления Знаниями (Enterprise Knowledge Management). Тогда концепт «Намерение» заменил «Решение», который также был определен в рамах NATURE. Стоит отметить, что «Положение» и «Намерение» являются основными концептами ситуационной инженерии методов, которая поддерживает конструирование метода «на лету» в соответствии с тем, как метод определяется в конкретный момент («Положение»), и что инженеру метода требуется в него добавить («Намерение»).

На рис. 6 показана выдержка из метамодели NATURE, описанной Ролландом (Rolland) в 1995 году [12]. Показано, что «Контекст» (Context) состоит из «Положения» (Situation), касающегося продукта, и «Намерения» (Intention), т.е. цели, связанной с продуктом. Предложено три типа контекста. «ПлановыйКонтекст» (Plan based) состоит из нескольких упорядоченных контекстов. «ВыборочныйКонтекст» (Choice based) соответствует «Положению», что требует рассмотрения альтернативных контекстов, базирующихся на «Аргументах». «КонтекстИсполнения» (Executive based) реализует «Намерение» путем выполнения «Действия» (Action), трансформирующего «ЧастьПродукта» (ProductPart).



Рис. 6 Выдержка из метамодели NATURE
^ Метамодели на основе стратегии (strategy-oriented process metamodels)
Метамодели на основе стратегии позволяют создавать описания, отражающие многоподходные процессы (Multi-Approach Processes, MAP), и планировать различные возможные пути разработки продукта, базирующиеся на представлении о намерении и стратегии. «Намерение» и «Стратегия» – базовые концепты данного класса метамоделей. Намерение – это цель для достижения. Стратегия – это способ достижения цели.

Метамодель MAP, также описанная Ролландом [13], возможно, является единственной метамоделью на основе стратегии, которая доступна в настоящий момент. Однако, подход к ситуационной инженерии методов, применяющий цели для конструирования методов, и подход пула продуктов (work product pool approach) тоже могут быть условно отнесены к этому классу метамоделей.

На рис. 7 представлена упрощенная метамодель подхода MAP. «Секция» (Section) состоит из «Стратегии» (Strategy). «Стратегия» представляет собой пару «Исходное Намерение» (Source Intention) – «Целевое Намерение» (Target Intention). Сам MAP-процесс состоит из одной или нескольких «Секций». Он всегда имеет намерения начала (start) и конца (stop).

На рис. 8 показан пример описания, созданного с помощью метода многоподходного процесса (MAP). Пример описывает процесс выбора концептов, взятый из метода создания метамоделей, который предложен в [7]. На рисунке можно увидеть намерения и возможные стратегии. Очевидно, что такая модель позволяет описывать деятельность, которая может быть выполнена различными путями, в зависимости от конкретной ситуации.



^ Рис. 7 Упрощенная метамодель подхода MAP



Рис. 8 Пример использования метода многоподходного процесса (Multi-Approach Process, MAP)
^ Проблемы разнообразия классов метамоделей
Для большого количества частных проектов может быть использована одна из существующих предопределенных метамоделей, отвечающая организационным требованиям. Именно с этой целью они были разработаны и стандартизованы. Однако, во многих других случаях, инженеры методов нуждаются в объединении концепций из двух и более классов метамоделей, т.е. они нуждаются в применении нескольких методов описаний и унифицированной метамодели, а также в метамоделях, подогнанных к специфике организации или проекта. Сегодня, для того, чтобы описать требуемый метод управления ЖЦ с помощью нескольких методов описания, приходится независимо использовать несколько метамоделей. Возможны два решения: объединение классов метамоделей на базе общей унифицированной метамодели или развитие существующих метамоделей с постепенным включением в них новых методов описания.

Очевидна связь между различными классами метамоделей, так как они описывают (формализуют, задают) один и тот же предмет, но с помощью разных методов описания. Ведутся разработки явно выраженного соответствия (mapping) между этими методами описания, с целью сформировать единую метамодель, которая бы включала все требуемые концепции, и, соответственно, обеспечивала многостороннее видение метода управление жизненным циклом системы. На основе такой унифицированной метамодели инженеры методов будут иметь возможность создавать собственные метамодели, обеспечивающие конкретные нужды организации.

Проблемой здесь является не только частичное соответствие онтологий (понятийных наборов), используемых в разных метамоделях, но и просто терминологические проблемы. Например, сравнение онтологически близких метамоделей на основе деятельности показывает, что один и тот же термин может использоваться для отражения различных концепций. Например, «Activity» из SPEM не соответствует «Activity» из OPF [7]. Подобные различия могут стать причиной трудностей в понимании метамоделей. В настоящий момент разработки унифицированных метамоделей ведутся отдельными исследователями, не стандартизованы и не имеют широкой инструментальной поддержки. Основной подход к унификации метамоделей включает методы онтологической интеграции данных с использованием библиотек справочных данных (например, использование ISO 15926).

С другой стороны, существующие метамодели описаний жизненного цикла можно расширять путем включения в них новых концепций, поддерживающих дополнительные методы описания. Как уже упоминалось, SPEM и ISO 24744 поддерживают также метод описания на основе продуктов. В планах Object Management Group (OMG) объединение SPEM с Business Motivation Metamodel (BMM), что позволит применять в рамках этой метамодели метод описания на основе стратегии. Подобный подход возможен, потому что ряд самых разных относящихся к деятельности метамоделей (целеполагания, организационной структуры, последовательности действий и т.д.) стандартизирован и поддерживается инструментарием.

Стоит заметить, что, несмотря на существование нескольких классов, именно метамодели на основе деятельности являются самыми распространенными. Это закономерно, так как метод описания деятельности, описывающий работу и порядок ее выполнения, используется инженерами методов в первую очередь. Софтверные инженеры, первыми создававшие метамодели описания ЖЦ, во всем видели технологическую цепочку, что соответствовало группе описания деятельности. Это послужило предпосылкой к стандартизации именно таких метамоделей и созданию программных средств для работы с ними. Поэтому при выборе метамодели необходимо учитывать, поддерживает ли она метод описания деятельности.
^ Представление фрагментов методов (method fragments)
Ситуационная инженерия разделила методы (практики) и (макро)процессы, в которых они используются. Методы превратились в единицы повторного использования, из которых можно собирать специфические процессы ЖЦ путем «применения» этих методов в определенные моменты времени. В каждой метамодели описания ЖЦ предложены свои подходы к выделению и описанию таких единиц. Далее для их обозначения мы будем использовать термин «фрагмент», т.к. исторически он был предложен в работе [5] одним их первых. Бринкемпер (Brinkkemper) определил фрагмент как «логически последовательную (когерентную) часть метода создания информационной системы». Сейчас мы видим, что фрагменты методов могут применяться для формирования процессов ЖЦ любых систем, не только информационных. Понятие фрагмента можно считать самым простым, а другие подходы рассматривать как его расширение.

Когда для описания ЖЦ, подходящего под специфическую ситуацию, необходимо использовать фрагменты разных типовых наборов методов, встает ряд вопросов. Как разбить типовой набор методов на фрагменты, которые могут быть повторно использованы в различных контекстах? Какие свойства должны характеризовать фрагмент? Как (или в какой степени) различные фрагменты могут быть объединены в уникальный набор методов? [14]. Выбор и модификация этих фрагментов в результате должны привести к законченному и последовательному процессу ЖЦ. Поэтому подход, который используется для описания фрагментов методов, является критичным для ситуационной инженерии методов.
^ Группы описания фрагментов методов
В процессе становления и развития ситуационной инженерии методов было предложено несколько подходов к представлению фрагментов. Такое представление должно включать набора специфических групп описания, которые соответствуют определенным интересам (concerns) заинтересованных сторон. В [15] предложена модель для оценки подходов к описанию фрагментов, основанная на четырех группах описания:

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

Определены разные цели, которые адресуются подходами к представлению фрагментов. Первым из интересов, которые рассматриваются в рамках группы описаний задачи, является функциональная совместимость (interoperability) фрагментов между собой. Она обсуждается с самого появления инженерии методов, но, тем не менее, большинство фрагментов совместимы только с фрагментами из своего репозитория методов (внутренняя совместимость). Внешняя совместимость более полно отвечает требованиям жизни, так как часты ситуации, в которых требуется совместимость фрагментов разных репозиториев методов или даже разных платформ разработки.

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

В одном из исследований метод рассматривается как «способ мыслить, способ описывать, способ работать и способ поддерживать». С точки зрения использования метода требуется оценка того, насколько полно его описание адресует все эти аспекты. Даже если множество фрагментов рассматривается как цельный метод, зачастую он не удовлетворяет всем требованиям. Поэтому одним из свойств, рассматриваемых группой описаний пользования, является так называемый масштаб способа (covered way), который характеризует мышление/описание/работу/поддержку, покрываемые способом описания фрагментов.

Использование фрагментов должно поддерживаться инструментарием, то есть должны быть обеспечена их реализация. ^ Реализация фрагментов с помощью инструментария (tool/implementation) второй важный интерес, оцениваемый в группе описаний пользования. Можно рассматривать различные уровни реализации фрагментов. С одной стороны, у фрагмента метода надо различать процессную часть и часть продукта, с другой стороны, мы выделяем операции, которые можно производить с фрагментами. Объединяя эти признаки можно выделить для рассмотрения следующие функции для поддержки инструментарием: хранение фрагментов и обращение к их записям, а также использование, извлечение и конструирование процессов.

^ Системная группа отвечает на вопрос «Что?», формализуя фрагмент и раскрывая его внутреннюю структуру элементов и их связей. Можно выделить три уровня рассмотрения (levels) фрагмента: контекстный, структурный и операционный. Контекстный уровень описывает окружение, в котором используется или повторно используется фрагмент. Структурный уровень определяет структуру фрагмента и типы структурных связей между элементами фрагмента: специализация, композиция, ссылка. Операционный уровень имеет дело с работающими частями фрагмента, позволяя реализовать его во время проекта.

Фрагмент не всегда рассматривается в одном и том же измерении (dimension), которое также является интересом, адресованным системной группой. Измерение фрагмента характеризуется элементами, доминирующими в подходе. Выделяют три измерения: процесса (process focused), продукта (product focused) и исполнителя (producer focused).

Важным аспектом структуры фрагмента является рекурсия (recursion). Концепция крупности разбиения (granularity) в различных подходах позволяет составлять фрагмент из других фрагментов. Например, фрагмент может представлять собой целый метод, который может быть декомпозирован на менее сложные фрагменты (которые также могут быть декомпозированы).

Еще одним интересом, связанным со системной группой, является уровень абстракции фрагмента (abstraction level). Фрагмент может быть определен на разных уровнях: мета-метамодель, метамодель, модель.

^ Формализм представления (representation formalism) фрагмента – это набор синтаксиса и семантики естественного языка, полуформального языка (диаграммы) или полностью формального языка. Формальное представление требует поддержки верификации свойств разработанного метода и валидации его описания с помощью приемов симуляции или исполнения. Применение неформальных нотаций осложнит последовательное исполнение разработанного метода. Формальное или полуформальное представление позволит следовать методу значительно эффективнее, так как такое представление требуется для автоматизированного применения метода. В контексте ситуационной инженерии методов представленные фрагменты должны извлекаться, собираться, адаптироваться и настраиваться, что требует формального или полуформального представления. Формализм может быть концептуальным (неформальным), когда фрагменты выражаются путем текстового описания и спецификации частей методов с использованием предзаданных понятий, или техническим (формальным или полуформальным), когда поддерживается инструментальная реализация частей методов.

В разработческой группе описаний (process view) рассматривается как применять фрагменты для создания методов. Интересы, адресуемые этой группой, описывают основные операции инженерии методов в части фрагментов. Можно выделить принципы декомпозиции метода, извлечения/выбора фрагментов, установления соответствия фрагмента ситуации проекта (matching with situation), конструирование нового метода. В работе [16] выделены следующие подходы к конструированию нового метода: порождение (instantiation), сборка (assembly), расширение (extension), сокращение (reduction). При порождении используется описывающая общие характеристики метода метамодель, представляющая систему понятий. Ее экземпляр представляет собой метод. Сборка концентрируется на группировании фрагментов, принадлежащих смежным в процессе методам. Расширение производится путем добавления новых фрагментов в существующий метод для расширения его функциональности. При сокращении фрагменты изымаются из метода, чтобы сделать его более компактным и удобным. Кроме того, в [15] отдельно выделен гибкий (agile) подход к конструированию новых методов.
^ Существующие подходы к представлению фрагментов методов
Несколько различных подходов к описанию фрагментов методов появилось в литературе. Ниже описаны некоторые предложенные подходы, которые сравнивались в рамках различных исследований [14, 15, 17].

Как упоминалось выше, одним из первых выделять фрагменты методов (method fragments) предложил Бринкемпер (Brinkkemper) в работе [5]. Он определял их как стандартизованные строительные блоки на базе логически последовательных (когерентных) частей метода. Он выделял продуктные фрагменты (product fragments) и процессные фрагменты (process fragments). Первые описывают продукты (диаграммы, модели, таблицы и т.д. – тогда речь шла только об информационных системах), используемые методом. Процессные фрагменты описывают работу, выполняемую в рамках процесса ЖЦ. Они могут представлять либо высокоуровневые макропроцессы, например, проектные стратегии, либо детализированные микропроцессы – процедуры, приемы. Соответственно, фрагменты могут составлять фрагменты более высокого уровня, а также быть связаны между собой. Для выбора фрагментов используются характеристики проектов (project characteristics), описывающие конкретную ситуацию и связанные с подходящими фрагментами. Фрагменты предлагается хранить в базе методов (method base), откуда они могут извлекаться для конструирования новых методов в соответствии с правилами сборки.

На рис. 9 приведена метамодель, описывающая этот подход к представлению фрагментов.



^ Рис. 9 Фрагмент Метода (Method Fragment)

Другим предложенным подходом является использование кусков методов (method chunks). Этот подход был предложен Роландом (Rolland) как способ описывать ситуационные аспекты инженерии методов и поддерживать возможность извлечения таких кусков из репозитория. Кусок метода определяется как автономная, связная и логически последовательная часть метода, которая обеспечивает руководства (guidelines) и связанные с ними концепты для выполнения конкретного вида деятельности системной инженерии.

Знание о методе описывается в теле (body) и интерфейсе (interface) куска метода. Интерфейс описывает предусловия и постусловия использования куска с помощью пары (). Положение описывает продуктные части (product parts) требуемые на входе, интерфейс определяет цель, которую помогает достичь кусок метода. Тело куска включает в себя два типа знаний: о продукте и о процессе. Первый определяет рабочие продукты (исходные и конечные), используемые куском метода, и обычно описывается в виде метамодели.

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

Дополнительно выделяется дескриптор (descriptor), который расширяет контекстное знание, заданное интерфейсом, набором критериев, позволяющий определять инженерную ситуацию, в которой кусок метода будет полезен. Дескриптор содержит мета-знание о методе. С помощью него куски метода извлекаются из базы методов, где они сгруппированы и описаны с помощью интерфейсов и дескрипторов. В зависимости от структуры базы методов к ней можно обращаться на языке запросов.

На рис. 10 приведена метамодель, описывающая кусок метода и связанные концепты.



^ Рис. 10 Кусок Метода (Method Chunk)

Следующим подходом является использование компонентов методов (method components) [17, 18]. Основная идея подхода заключается в представлении метода, состоящего из компонентов, которые можно повторно использовать и которыми можно обмениваться. Каждый компонент состоит из описания выполнения работы (акт деятельности), нотаций и понятий. Описание работы определяет правила и рекомендация для пользователя компонента и информирует его о том, какие акты деятельности предпринять и в каком порядке. Нотации определяют семантические, синтаксические и символьные правила документирования. Понятия тут – это используемые актами деятельности и нотациями понятия. Каждый компонент метода решает отдельную задачу.

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

Компонент метода состоит из двух частей: содержание (content) и обоснование (rationale). Содержание состоит из элементов метода, определяющих целевое состояние компонента или поддерживающих переход из одного состояния в другое. Выделяют пять категорий элементов. Во-первых, три основные пересекающиеся категории: акт деятельности (action), нотация (notation) и концепт (concept). Их дополняют категории артефакт (artefact) и роль деятеля (actor role). Артефакты используются в качестве входящих и исходящих сущностей трансформации. Выбор ролей определяется предписанными действиями. Обоснование метода основано на целях (goals). Элементы содержания метода существуют по определенным причинам. Эти причины явно выражаются путем связи элементов с целями.

Компонент методов располагается в слое артефактов (artefact layer) и представляют неиерархический концепт, который не обладает рекурсией. Это отражает то, что компонент представляется как самая маленькая часть метода, которая может принести практическую пользу. Подобное проектировочное решение принято исходя из двух эмпирических наблюдений. Во-первых, разработчикам системы при обсуждении ситуационных методов свойственно фокусироваться на артефактах, которые представляют неиерархические шаблоны. Во-вторых, существуют сложности в балансировке выгод и затрат от применения иерархических концептов в ситуационной инженерии методов.

На рис. 11 представлено описание компонента методов.



^ Рис. 11 Method Component

OPEN Process Framework [19] также использует фрагменты (OPF Fragments), но особо подчеркивается то, что каждый фрагмент должен генерироваться на основе элемента предписанной метамодели. Эта метамодель тесно связана с метамоделью стандарта ISO 24744.

В подходе OPF используются концепты ориентированные и на акты деятельности, и на продукты, и на исполнителей. Стадии (stages) описывают макропроцессы и обеспечивают организацию исполнителей, продуктов и микропроцессов (актов деятельности). Классы стадий предоставляют достаточную выразительность для описания формы ЖЦ. Исполнители (producers) выполняют единицы работы и производят продукты. Единицы работы (work units) делятся на акты деятельности (activities), дела (tasks) и приемы (techniques). Акты деятельности можно разбить на дела, каждое из которых выполняется в соответствии с приемами. Единицы работы используют и производят рабочие продукты (work products). Продукты документируется с помощью языка (language). Отдельно выделяется концепт предприятия (endeavor), который отражает высокоуровневые начинания с целью создать или поддержать одну и более систему. Такими предприятиями могут являться классические проекты, их совокупности (программы), и совокупности программ – предприятия как юридические лица (enterprises). С каждым из фрагментов OPF связаны руководства (guidelines) по его применению.

Главное преимущество этого подхода в богатом выборе элементов метода, которые включают описание множества различных аспектов. Подход поддерживает различные уровни описания фрагмента (granularity levels). Имеющиеся описания большого числа фрагментов позволяют собирать и настраивать новые процессы ЖЦ. Однако, эти описания, возможно, слишком объемны, текстуальны (т.е. затруднены для автоматизированного применения) и сложны для изучения и использования [14].

На рис. 12 представлено описание фрагмента OPF.



^ Рис. 12 OPF Фрагмент (OPF Fragment)

В SPEM 2.0 повторно используемое содержание метода (method content) отделено от процесса ЖЦ (process), в котором оно используется. Содержание метода состоит из элементов (method content elements). Они включают в себя определения продуктов (work product definition), ролей (role definition), дел (task definition), используемых инструментов (tool definition). Также важной составляющей описания метода является руководства (guidance), которые могут представлять собой контрольные листы, примеры, инструкции, технические описания и т.д. Руководства определяются на пересечении процесса и метода, так как они могут поддерживать и то, и другое. Дела могут разбиваться на шаги (step). И шаги, и дела являются описаниями работы (work definition). В этом подходе предполагается описание квалификации (qualification), которая требуется от роли или для выполнения дела. На рис. 13 представлена выдержка из метамодели SPEM 2.0, описывающая элементы содержания метода.



^ Рис. 13 Элемент содержания метода (Method Content Element)

Отдельно можно выделить описание акта деятельности, предложенное Г.П.Щедровицким. Он предложил и развивал оригинальную логико-методологическую программу, которая в итоге приняла форму системомыследеятельностного подхода (СМД-подход) и общей методологии. Этот подход предлагает категориальный аппарат для исследований, организации и управления системами мышления и деятельности.

Изучая деятельность и анализируя механизмы ее воспроизводства, включая описание, Щедровицкий пришел к выводу о необходимости рассмотрения актов индивидуальной деятельности и разнообразных форм кооперации их в сложные системы. При этом структуры кооперации рассматриваются как механизм, обеспечивающий процесс воспроизводства деятельности, как самостоятельные структуры, и как процессы функционирования деятельности, которые должны быть воспроизведены. Описания актов деятельности, включающие разнородные элементы, выступают в роли конструктивных единиц, из которых могут быть собраны сложные системы кооперированной деятельности; при этом различным элементам приведенной схемы придаются разнообразные спецификации, благодаря чему она дает множество изображений актов деятельности разного вида и типа [30]. Здесь видна четкая параллель с ситуационной инженерией методов. Акты индивидуальной деятельности можно рассматривать как фрагменты метода, а структуры их кооперации либо как функциональные сборки в «логическом времени», либо как процессы ЖЦ, состоящие из множества применений методов, расположенных во времени.

У Щедровицкого повторно используемые единицы, т.е. методы, описываются с помощью схем актов деятельности. Цель этой схемы раскрыть «черный ящик» трансформации, показать ее в виде «разборного ящика». Это представление включает две части: объектная и субъектная. Объектная часть включает: продукт (Пр), получающийся в результате трансформации; исходный материал(ИсМ), из которого производится продукт; набор действий (д1…дn), прикладываемых к материалу; любые внешне выраженные средства, используемые в действиях, включая орудия и знания, которые фиксируется в специальных знаковых формах. Субъектная часть деятельности включает: самого индивида, который может быть представлен позицией (ролью); сознание индивида; внутренние средства и способности необходимые для оперирования всеми орудиями и выполнения действий. Особое место занимает цель деятельности, которая может рассматриваться и как объектный, и как субъектный элемент деятельности.

На рис. 14 представлено классическое описание схемы акта деятельности, предложенное Щедровицким. На рис. 15 предложено описание схемы акта деятельностью с помощью диаграммы классов UML.



^ Рис. 14 Схема акта деятельности (классическое представление)



Рис. 15 Схема акта деятельности (в виде диаграммы классов)

В СМД-методологии в схеме акта деятельности разные исследователи выделяли до 20 составляющих.

В [15] предложен подход на основе выделения сервисов методов (method service). Этот подход объединяет концепции cервисно-ориентированной Архитектуры (SOA) и кусков методов (method chunks) и предлагает рассматривать реализацию фрагментов метода как автономных сервисов, обеспечивая тем самым их внешнюю функциональную совместимость. Метамодель в основе этого подхода базируется на трех основных принципах: ориентация на сервисы, применение онтологии актов деятельности для повторного использования знаний о проблемах процесса ЖЦ, динамическая композиция сервисов методов для генерации адаптированных методов.
^ Оценка подходов к представлению фрагментов методов
Рассматривая существующие подходы к представлению фрагментов методов в разрезе выделенных интересов заинтересованных сторон можно придти к нескольким выводам.

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

Создание, извлечение, композиция и приложение фрагментов реализуются вручную в большинстве подходов. ^ Уровень интерактивности может быть определен как низкий. Предпринят ряд усилий по созданию инструментов для поддержки пользователей фрагментов методов и в настоящий момент все подходы обеспечивают средства для хранения фрагментов в базе данных. Реализация фрагментов в основном распространяется на фрагменты продуктов. Для схем актов деятельности инструментария не предусмотрено.

Контекстный уровень рассмотрения представлен почти во всех подходах. В кусках методов контекстный уровень представлен интерфейсом (аспекты положения и намерения) и дескриптором (набор критериев для определения подходящей инженерной ситуации). Для компонентов метода контекст включает идентификацию целей. Фрагменты OPF также выбираются на основе их целей. Описание сервиса метода включает решаемую проблему и аргументы, связанные с сервисом. Все фрагменты имеют описание структурного уровня. Операционный уровень на уровне метамодели представлен только в подходе сервиса метода.

Фрагменты методов (method fragments) определены либо как продуктовые, либо как процессные фрагменты, в то время как во всех остальных подходах фрагменты включают в себя возможность обоих групп описаний. Группа описаний исполнителя явно выделяется в компонентах методов, фрагментах OPF, содержимом метода SPEM, схеме акта деятельности.

Несмотря на то, что почти все подходы настаивают на необходимости различных уровней гранулярности фрагментов (фрагмент может быть частью метода или целым методом), лишь куски методов могут быть описаны как полностью рекурсивные. Кусок основан на декомпозиции процесса на повторно используемые руководства, а это значит, что все куски могут быть также формально декомпозированы на другие куски. Другие типы фрагментов методов не позволяют формально определять декомпозицию процесса.

Все фрагменты определены на уровне абстракции метамоделей. Сервисы методов включают также уровень метаметамодели, так как предлагают использовать онтологию для описания продукта. Элементы фрагмента OPF включают в себя понятие предприятия (endeavor), которое является экземпляром модели.

Куски и компоненты методов формализуются понятийно-текстово, тогда как OPF фрагменты, сервисы метода и содержание метода SPEM поддерживают техническое представление. Фрагмент метода имеет и неформальное и формальное представление.

Все подходы применяют достаточно различающиеся принципы декомпозиции. Фрагменты методов используют иерархическую декомпозицию для связи всех частей метода. Куски и компоненты получаются путем разбиения методов на основе существующих намерений, целей. Фрагменты ISO 24744 являются «клабджектами» (clabjects), являющиеся результатом создания экземпляра родительских классов и наследования их свойств, а фрагменты OPF представляют собой простую иерархию классов (что, как отмечают авторы, теоретически неправильно, но зато существенно упрощает понимание).

Кроме того, различаются и приемы конструирования новых методов. Фрагменты методов собираются для создания нового метода. Подход на основе кусков методов использует сборку, разрешая наложение кусков друг на друга, и расширение. Подход на основе компонентов дополнительно допускает использование сокращения. Конструирование из сервисов методов основано на процессе композиции, поддерживающем последовательную и параллельную агрегацию сервисов. В OPF новый метод создается путем динамического создания экземпляров метамодели во время проекта. В системомыследеятельностном подходе предполагается большое разнообразие принципов сборки схем-единиц. Для организации этих сборок предлагаются формальные правила и содержательные принципы, группирующие шаги конструктивного развертывания.
^ Дополнительные рассмотрения касательно метамоделей описания ЖЦ Связь с ориентацией на аспекты
Усложнение систем привело к широкому использованию декомпозиции общей проблемы на частные задачи, для которых легко может быть найдено решение. Затем частные решения собираются и компонуются в целостное решение способное разрешить общую проблему. Этот метод может использоваться, когда частные задачи ортогональны друг другу. Но когда задачи зависят друг от друга, разбиение проблемы на раздельные блоки существенно осложняется или становится невозможным.

В области разработки ПО для решения этого вопроса был предложен метод аспектно-ориентированной разработки, который предлагает декомпозицию проблемы, учитывающую перекрестные интересы (аспекты) раздельно от традиционных единиц разбиения. В более широком контексте, на ранних фазах проекта мы можем использовать аспектно-ориентированное описание (aspect-oriented modeling) для определения, спецификации, вплетания и управления аспектами или перекрестными интересами, затрагивающими множество частей системы. В контексте ситуационной инженерии методов требуется поддержка вплетения методов, выполнение которых требуется в разные моменты ЖЦ, в процесс ЖЦ, а также вплетение перекрестных фрагментов в сами методы [32, 33]. Например, инженеру методов может понадобиться вплести метод выявления требований в несколько стадий ЖЦ или вплести продукт «список требований безопасности» в различные методы.

Один из подходов ситуационной инженерии методов, а именно ADOM-SME (см. его описание в разделе «Метамодели описания жизненного цикла»), предлагает особую структуру моделей для использования вплетания [26]. Аспектно-ориентированный ADOM выделяет три типа моделей: базисная, аспектная и модель вплетания.

^ Базисная модель описывает систему или их семейство, то есть предментую область. В нашем случае предметной областью является ситуационная инженерия методов, а методы представляют собой проектируемые системы. В ADOM предлагается использовать UML для описания систем, поэтому методы и их метамодель также описываются с помощью диаграммы классов.

^ Аспектная модель описывает конкретные перекрестные фрагменты и их возможное вплетение в методы. Она создается с помощью трех групп описания перекрестных фрагментов. Спецификация аспекта (concern specification) имеет дело с задачами, которые связаны с рассматриваемым аспектом, то есть определяет что именно будет вплетаться. Будучи отделенной от правил вплетания, спецификация аспекта представляет собой то же самое, что и базисная модель, но в отношении аспекта. Мы описываем аспект как систему связанных между собой понятий. Для этого можно также применить диаграмму классов UML. Описание паттерна совместимости (match pattern) ограничивает спектр базисных моделей, к которым может быть применен аспект. С помощью правил и ограничений, накладываемых на базисные модели, он определяет куда аспект может быть вплетен. Дополнительно паттерн совместимости устанавливает «якоря» в тех местах, где могут быть применены руководства слияния (merge guidance). Это третья группа описаний, составляющих аспектную модель, и она обеспечивает наставления для вплетения выбранных аспектов (фрагментов методов) в подходящие базисные модели (описания методов). Руководства слияния определяют как вплетать аспект, объединяя спецификацию аспекта и паттерн совместимости. Дополнительно стоит указать, что аспектная модель, в зависимости от уровня рассмотрения, может описывать экземпляр метамодели (уровень приложения) или метамодель (уровень домена).

Результатом вплетания спецификации аспекта с помощью руководства слияния в базисную модель, отвечающую требованиям паттерна совместимости, является модель вплетания (woven model).

Основным недостатком ориентации на аспекты является отсутствие средств отладки полученного результата, то есть метода. Возможности предопределения результата вплетания аспектов в метод ограничены в настоящий момент. Ориентация на аспекты не получила широкого распространения именно из-за того, что встают большие сложности по отслеживанию логических, аспектных связей, по расплетанию метода. Вплетание аспектов позволяет описывать и выражать комплексные методы, но это существенно затрудняет понимание их внутренней структуры, осложняет исследование этих методов и их отладку. Для этого с аспектно-ориентированным проектированием потребуется использование дополнительных инструментов, исследование которых только начинает проводиться.
^ Применение Clabjects и Powertype
Разработчики систем не работают непосредственно с метамоделями. В своей деятельности они используют методы, которые обеспечивают руководства по выполнению конкретных задач. Эти методы описываются с помощью моделей. Когда разработчики применяют подобную модель, они порождают ее экземпляр, соответствующий нуждам конкретного проекта. Подобный экземпляр должен соответствовать модели набора методов. Качество набора методов определяется его способностью порождать полезные экземпляры.

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

Эти рассмотрения помогают выделить три уровня абстракции, предложенные в ISO 24744: метамодель, метод и проект (экземпляр ЖЦ). Разные заинтересованные стороны работают на разных уровнях. Инженеры методов используют метамодели, чтобы создавать и модифицировать методы. Разработчики систем применяют метод для генерации конкретного проекта. Таким образом, методы служат в качестве моста между метамоделями и проектами и обеспечивают косвенное взаимодействие разработчиков, работающих над проектом, и метамоделью, которая была использована для создания применяемого метода.

Для описания трех уровней моделирования процесса жизненного цикла применяется следующая схема. Элементы уровней метамодели и методов описывается с помощью классов. Классы метода являются подтипами классов метамодели. При генерации проекта создаются объекты-экземпляры классов метода, которые будут являться также экземплярами классов метамодели. Этот подход приводит к тому, что элементы метамодели не могут передавать информацию элементам слоя методов. У элемента метода нет возможности получить значения любых атрибутов или связей, так как он тоже является классом, а не объектом [23].

Наполнение элементов методов информацией зачастую является практичным и даже необходимым. Иногда требуется описать свойство, которым обладают не все экземпляры элемента метода, а только какая-то их часть. Например, инженер методов может захотеть описать цель каждого типа работ, которые могут выполняться в проекте. Работы по написанию программного кода будут иметь цель «написать код, реализующий требования, описанные в начальной спецификации», в то время как работы по модификации списка требований будут иметь цель «изменить список требований так, чтобы он отражал утвержденные запросы на изменения». Эти атрибуты не принадлежат каждой работе по написанию кода и модификации списка требований, но принадлежат типам этих работ. Инженер методов нуждается в инструменте присвоения конкретных значений набору объектов уровня проекта, таких как набор работ.

Обычно набор объектов описывается как класс, а свойство, которым должен обладать каждый объект этого набора, будет иметь значение, описанное атрибутом класса. Таким образом, в продолжение примера, требуется, чтобы метамодель обеспечивала класс, описывающий разные типы работ проекта и имеющий атрибут Цель. Такой класс можно назвать ТипРаботы. Экземпляр этого класса будет находиться на уровне метода. В нашем примере могут быть созданы экземпляры «НаписаниеКода» и «МодификацияТребований», имеющие соответствующие значение атрибута Цель.

Мы упоминали, что инженер методов использует классы метамодели для создания подклассов и сборки их в метод. Но теперь получается, что инженеру требуется создавать экземпляры некоторых классов метамодели и размещать их на уровне метода. В нашем примере, инженер на уровне метода создаст подкласс НаписаниеКода класса Работа и объект «НаписаниеКода», который будет экземпляром класса ТипРаботы уровня метамодели. Очевидно, что эти подкласс и объект отражают одно и то же, то есть работы, целью которых является написание кода, реализующего требования ТЗ. Подкласс унаследует свойства и отношения класса Работа и позволит своим экземплярам на уровне проекта получать их значения и связи. С другой стороны, объект принимает значения и связи из атрибутов и отношений класса ТипРаботы уровня метамодели. Для обращения к этому набору класса и объекта применяется специальный термин “clabject”. В нашем случае мы имеем clabject #НаписаниеКода (см. рис. 12).

Важно понимать, что два элемента метамодели, которые являются базой для clabject’a, это два разных класса со своими наборами свойств и отношений. Но, в то же время, они тесно связаны. Фактически, один класс (ТипРаботы) отражает группу экземпляров другого класса (Работа); экземпляры класса Работа представляют собой реальные работы, выполняемые в проекте, а экземпляры класса ТипРаботы представляют наборы работ, которые разделяют общие свойства, то есть имеют один тип. В этом смысле, экземпляры класса ТипРаботы дробят экземпляры класса Работа. Такое отношение получило название powertype. В нашем примере, ТипРаботы – это powertype класса Работа, так как его экземпляры составляют аспект объектов clabject’а, аспекты классов которого представлены подтипами класса Работа. Сложная композиция уровня метамодели, сформированная разделяемым классом и его powertype, может использоваться в качестве шаблона (powertype pattern).

Дополнительно clabject’ы позволяют переносить свойства классов метамодели уровень метода в объекты уровня проекта (deep instantiation) и задавать им значения. В нашем примере, свойство Продолжительность, заданное на уровне метамодели, будет перенесено в объекты проекта и получит значение при создании экземпляра «Работа 2.1» (см. рис. 16)



^ Рис. 16 Пример использования Powertype и Clabject

С точки зрения инструментария, Clabject’ы являются мощными средствами, которые могут быть легко реализованы. Аспект объектов может храниться в БД, в то время как аспект классов будет использоваться инструментом как шаблон для создания экземпляров. Их реализация облегчается тем, что clabject’ы состоят из общепринятых концепций (классов и объектов).

В настоящий момент широко распространено строгое метамоделирование (strict metamodeling), которое предполагает, что элементы любого уровня должны быть экземплярами элементов второго уровня, который располагается сразу над первым. В таких ситуациях невозможно применять clabject и powertype Очевидно, что строгое метамоделирование не позволяет описать все ситуации, которые возникают в реальном мире. Поэтому выразительность метамодели стоит оценивать, в том числе, и по наличию поддержки clabject’ов.

Интересно, что сама концепция clabject и PowerType развивается сейчас главным образом исходя из требований деятельностного подхода – ситуационной инженерии методов.

  1. chast-3-ogon-gorit-yarko-rej-bredberi-451-gradus-po-farengejtu.html
    chast-3-perechen-izlozhenie-i-izvlecheniya-iz-normativnih-pravovih-aktov-soderzhashih-dopolnitelnie-normi-regulirovaniya-zemlepolzovaniya-i-zastrojki.html
    chast-3-perspektivi-politicheskoj-transformacii-doklad-sostoit-iz-treh-chastej-vpervoj-chasti-mi-analiziruem-tekushie.html
    chast-3-polnaya-profneprigodnost-andrej-parshev-pochemu-rossiya-ne-amerika.html
    chast-3-pozvolte-moskva-sankt-peterburg-nizhnij-novgorod-voronezh-rostov-na-donu-ekaterinburg-samara.html
    chast-3-predlozheniya-po-sovershenstvovaniyuzakonodatelstva-o-sostoyanii-zakonodatelstva-samarskoj-oblasti-v-2010-godu.html
  2. bukva.bystrickaya.ru/programma-organizacii-obedinennih-nacij-po-okruzhayushej-srede-dvadcat-vtoroe-soveshanie-storon-monrealskogo-stranica-6.html
  3. otsenki.bystrickaya.ru/socialnaya-cennost-rossijskogo-ugolovnogo-sudoproizvodstva.html
  4. bukva.bystrickaya.ru/pravo-zanimatsya-predprinimatelskoj-deyatelnostyu.html
  5. predmet.bystrickaya.ru/slovoobrazovanie-sovremennij-russkij-yazik.html
  6. esse.bystrickaya.ru/referat-diplomnij-proekt-soderzhit-116-stranic-7-risunkov-28-tablic-21-istochnik.html
  7. paragraph.bystrickaya.ru/magistraturaa-tsushler-shn-mamandi-bojinsha-emtihan-sratari-6m0806-agrarli-tehnika-zhne-tehnologiya-mal-sharuashalain-mehanikalandiru.html
  8. urok.bystrickaya.ru/pro-i-antioksidantnij-status-v-dinamike-eksperimentalnogo-raka-shejki-matki-pri-dejstvii-lazernogo-izlucheniya-03-03-01-fiziologiya.html
  9. pisat.bystrickaya.ru/temi-referatov-po-discipline-fizicheskaya-kultura-dlya-studentov-ochnoj-formi-obucheniya-osvobozhdennih-ot-prakticheskih-zanyatij.html
  10. upbringing.bystrickaya.ru/literatura-nastoyashee-uchebnoe-posobie-koncentriruet-vnimanie-na-odnom-iz-vazhnejshih-aspektov-missii-biologii-v-sovremennom.html
  11. grade.bystrickaya.ru/nalog-na-dobavlennuyu-stoimost.html
  12. education.bystrickaya.ru/1minimalnie-trebovaniya-k-soderzhaniyu-kursa-vipiska-iz-gosa-po-specialnosti-utverzhdennogo-ekspertom-opisaniya-speckursa-stranica-4.html
  13. znaniya.bystrickaya.ru/rabochaya-programma-uchebnoj-disciplini-razrabotana-na-osnove-federalnogo-gosudarstvennogo-standarta-dalee-fgos-po-specialnosti-srednego-professionalnogo-obrazovaniya.html
  14. assessments.bystrickaya.ru/energeticheskaya-revolyuciya-vo-blago.html
  15. write.bystrickaya.ru/fiziko-geograficheskij-ocherk-zailijskogo-i-kungej-alatau-po-severnomu-tyan-shanyu-gornie-turistskie-marshruti-po-zailijskomu.html
  16. spur.bystrickaya.ru/l-m-belozerova-permskaya-gosudarstvennaya-medicinskaya-akademiya.html
  17. kanikulyi.bystrickaya.ru/zakon-respubliki-gruziya-ob-uprazdnenii-yugo-osetinskoj-avtonomnoj-oblasti-28.html
  18. essay.bystrickaya.ru/chast-iii-skazhite-svyazno-poryadok-slov-nemeckaya-grammatika-s-chelovecheskim-licom.html
  19. writing.bystrickaya.ru/biblioteki-stranica-2.html
  20. essay.bystrickaya.ru/doklad-rabochej-gruppi-po-zheleznodorozhnomu-transportu-o-rabote-ee-pyatdesyat-vosmoj-sessii.html
  21. essay.bystrickaya.ru/dnevnik-k-i-chukovskogo-stranica-84.html
  22. control.bystrickaya.ru/byulleten-novih-postuplenij-za-yanvar-2011g.html
  23. education.bystrickaya.ru/20-formi-koordinacii-prokuraturi-i-inih-gosudarstvennih-organov-1-sushnost-i-zadachi-prokurorskoyu-nadzora-v-rf.html
  24. pisat.bystrickaya.ru/uchebnij-plan-municipalnogo-kazyonnogo-obsheobrazovatelnogo-uchrezhdeniya-srednej-obsheobrazovatelnoj-shkoli-5-na-2013-2014-uchebnij-god-nachalnoe-obshee-obrazovanie.html
  25. kolledzh.bystrickaya.ru/analiz-patologicheskih-form-eritrocitov-krovi-sudaka.html
  26. tests.bystrickaya.ru/lingvopravovoe-prostranstvo-yazikovih-sredstv-kak-osobij-sposob-kodirovaniya-smislov-v-sudebno-ekspertnoj-praktike.html
  27. knowledge.bystrickaya.ru/mezhdunarodnij-konkurs-studentov-aspirantov-i-molodih-uchenih-strani-s-perehodnoj-ekonomikoj-v-usloviyah-globalizacii2.html
  28. zanyatie.bystrickaya.ru/o-razvitii-navikov-raboti-nad-polifoniej.html
  29. assessments.bystrickaya.ru/doklad-mbou-sosh4.html
  30. ekzamen.bystrickaya.ru/regionalnij-svodnij-plan-meropriyatij-po-obespecheniyu-effektivnoj-disseminacii-innovacionnogo-opita-uchitelej-pobeditelej-nacionalnogo-proekta-obrazovanie-v-moskovskoj-oblasti-s-yanvarya-2012-po-maj-2012-goda.html
  31. abstract.bystrickaya.ru/-tradiciej-amerikanskogo-v-s-katkalo-perevodchiki-kand-ekon.html
  32. tests.bystrickaya.ru/konspekt-lekcij-po-ugolovnomu-pravu-chast-2.html
  33. turn.bystrickaya.ru/opit-antikrizisnogo-regulirovaniya-v-bankovskih-sektorah-stran-sng-centralnoj-i-vostochnoj-evropi-sbornik-analiticheskih-materialov-associaciya-bankov-azerbajdzhana.html
  34. college.bystrickaya.ru/1-uchenie-arheologi-delyat-kamennij-vek-na-tri-osnovnih-perioda-k-paleolitu-otnositsya-period-25-mln-12-tis-let-do-n-e-stranica-11.html
  35. reading.bystrickaya.ru/lekciya-21-pravootnosheniya-lekciya-predmet-i-metodologiya-teorii-gosudarstva-i-prava.html
  36. lektsiya.bystrickaya.ru/prava-detej-na-zhilishe-problemi-analiz-polozheniya-v-rostovskoj-oblasti-doklad-o-deyatelnosti.html
© bystrickaya.ru
Мобильный рефератник - для мобильных людей.