✖


Jump to content

Моделирование метапроцессов

Add links
Уровень абстракции процессов. [1]

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

Моделирование метапроцессов поддерживает усилия по созданию гибких моделей процессов . Целью моделей процессов является документирование и информирование о процессах, а также расширение возможности повторного использования процессов. Таким образом, процессы можно лучше обучать и выполнять. Результатом использования моделей метапроцессов является повышение производительности труда инженеров-технологов и улучшение качества создаваемых ими моделей. [2]

Обзор

[ редактировать ]

Моделирование метапроцессов фокусируется на процессе построения моделей процессов и поддерживает его . Его главная задача — улучшить модели процессов и заставить их развиваться, что, в свою очередь, будет способствовать развитию систем. [2] Это важно в связи с тем, что « процессы со временем меняются, как и модели процессов, лежащие в их основе. Таким образом, может возникнуть необходимость создания новых процессов и моделей и улучшения существующих». [2] «Основное внимание уделялось повышению уровня формальности моделей процессов, чтобы сделать возможным их применение в программных средах, ориентированных на процессы». [3] [4]

Метамодель процесса — это метамодель , «описание на уровне типа модели процесса. Модель процесса, таким образом, является экземпляром метамодели процесса. [..] Метамодель может быть создана несколько раз. раз для определения различных моделей процесса. Метамодель процесса находится на уровне метатипа по отношению к процессу». [2]

Существуют стандарты для нескольких областей:

Темы моделирования метаданных

[ редактировать ]

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

Для этой цели

[ редактировать ]

«Традиционные модели процессов являются выражением опыта их разработчиков. Поскольку этот опыт не формализован и, следовательно, не доступен как фонд знаний, можно сказать, что эти модели процессов являются результатом специальной методики построения. Это имеет два основных последствия: невозможно узнать, как были созданы эти модели процессов, и они становятся зависимыми от области опыта. Если модели процессов должны быть независимыми от предметной области и должны быть быстро генерируемыми и модифицируемыми, то мы должны это сделать. Необходимо отказаться от построения моделей процессов, основанных на опыте. Очевидно, что создание и модификация связаны с принятой политикой управления процессами (см. «Мир использования»). ." [2]

Сборка

[ редактировать ]

Техника сборки основана на идее хранилища процессов, из которого можно выбирать компоненты процесса. Роллан (1998) перечисляет две стратегии отбора: [2]

  1. Содействие глобальному анализу имеющегося проекта на основе критериев непредвиденных обстоятельств (Пример Ван Слоотен, 1996 г.). [5] )
  2. Использование понятия дескрипторов [6] как средство описания фрагментов процесса. Это облегчает поиск компонентов, отвечающих требованиям пользователя/соответствующих текущей ситуации. [7] (Пример Плигон 1995 г. [8] в ПРИРОДЕ [9] и хранилище подходов, основанных на сценариях, доступных в Интернете в проекте CREWS. [10] [11] )

Чтобы технология сборки была успешной, необходимо, чтобы модели процесса были модульными. Если техника сборки сочетается с техникой создания экземпляров, то метамодель сама должна быть модульной. [2]

Создание экземпляра

[ редактировать ]

Для повторного использования процессов модель метапроцесса определяет «общие, родовые особенности моделей процессов и представляет их в системе понятий. Такое представление потенциально может «сгенерировать» все модели процессов, которые разделяют эти характеристики. Этот потенциал реализуется, когда определяется метод генерации, применение которого приводит к желаемой модели процесса». [2]

Затем модели процессов получаются из метамоделей процессов посредством создания экземпляров . Роллан связывает ряд преимуществ с подходом создания экземпляров: [2]

  1. Использование метамодели помогает определить широкий спектр моделей процессов.
  2. Это делает работу по определению моделей процессов систематической и универсальной.
  3. Это заставляет искать и внедрять в метамодель процесса общие решения проблем, в результате чего производные модели процессов наследуют характеристики решения.

«Техника создания экземпляров использовалась, например, в NATURE, [9] Роллан 1993, [1] Роллан 1994, [12] и Роллан 1996. [13] Инженер-технолог должен определить примеры контекстов и отношений, которые составляют интересующую модель процесса». [2]

Язык

[ редактировать ]

Роллан (1998) перечисляет множество языков для выражения моделей процессов, используемых сообществом разработчиков программного обеспечения: [2]

  • Е3 [4]
  • Различные диалекты Пролога для EPOS, [14] Ойкос, [15] и МИР [4]
  • PS-Алгол для PWI [4]

а также другие вычислительные парадигмы:

Языки обычно связаны с программами процессов, тогда как методы создания экземпляров используются для создания сценариев процессов. [2]

Поддержка инструментов

[ редактировать ]

Процесс метамоделирования часто поддерживается с помощью программных инструментов, называемых инструментами CAME (компьютерная разработка методов) или инструментами MetaCASE (инструменты компьютерной разработки программного обеспечения мета-уровня). Часто метод создания экземпляров «использовался для создания репозитория сред компьютерного проектирования». [2] [21] [22] [23] [24]

Примеры инструментов для моделирования метапроцессов: [25]

Пример: «Мультимодельный вид»

[ редактировать ]

Колетт Роллан (1999) [3] представляет собой пример модели метапроцесса, в которой используется техника создания экземпляров и сборки. В статье подход называется «Многомодельное представление» и применяется к методу CREWS-L'Ecritoire. Метод CREWS-L'Ecritoire представляет собой методический подход к проектированию требований , «части разработки ИС, которая включает в себя исследование проблем и требований сообщества пользователей и разработку спецификации будущей системы, так называемой концептуальной схемы». [1] [26] [27]

Помимо подхода CREWS-L'Ecritoire, многомодельное представление послужило основой для представления: [3]

(a) три других подхода к разработке требований, разработанных в рамках проекта CREWS: подход «Сцены реального мира», [28] Подход SAVRE для обнаружения исключений сценариев, [29] и подход к сценарной анимации [30]
(б) для интеграции подходов [31] одно с другим и с подходом OOSE [32]

Кроме того, CREWS-L'Ecritoire использует модели процессов и модели метапроцессов для достижения гибкости в конкретной ситуации. Этот подход основан на понятии размеченного графика намерений и стратегий, называемого картой, а также связанных с ним руководящих принципов . [3] Вместе карта (модель процесса) и рекомендации образуют метод. Основным источником этого объяснения являются разработки Роллана. [3]

Модель/карта процесса

[ редактировать ]

Карта представляет собой «навигационную структуру, которая поддерживает динамический выбор следующего намерения и соответствующей стратегии для его достижения»; это «модель процесса, в которую включен недетерминированный порядок намерений и стратегий. Это помеченный ориентированный граф с намерениями в качестве узлов и стратегиями в качестве ребер между намерениями. Направленный характер графа показывает, какие намерения могут следовать за каким из них. " [3]

Карта метода CREWS-L'Ecritoire выглядит следующим образом:

Модель процесса метода CREWS-L'Ecritoire [3]

Карта состоит из целей/ намерений (отмеченных овалами), которые связаны стратегиями (обозначенными стрелками). Намерение — это цель, задача, которую инженер приложения имеет в виду в данный момент времени. Стратегия – это подход, способ достижения цели. Соединение двух целей со стратегией еще называют разделом . [3]

Карта «позволяет разработчику приложения определить путь от намерения «Начать» до намерения «Остановить». Карта содержит конечное число путей, каждый из которых предписывает способ разработки продукта, т. е. каждый из них представляет собой модель процесса. является мультимоделью. Она воплощает в себе несколько моделей процессов, обеспечивая мультимодельное представление для моделирования класса процессов. Ни одна из конечных моделей, включенных в карту, не рекомендуется «априори». Вместо этого подход предполагает динамическую конструкцию. фактического пути путем навигации по карте. В этом смысле подход чувствителен к конкретным ситуациям, возникающим в процессе. Следующее намерение и стратегия его достижения выбираются инженером приложения динамически из нескольких возможных, предлагаемых. Кроме того, этот подход предназначен для динамического добавления пути на карте, т.е. добавления новой стратегии или нового раздела в фактический ход процесса. В таком случае руководящие принципы, которые делают доступными все варианты выбора. справиться с конкретной ситуацией очень удобно. Карта связана с такими рекомендациями». [3]

Рекомендации

[ редактировать ]

Руководство «помогает в реализации выбранного намерения»; [3] это «набор указаний о том, как действовать для достижения цели или выполнения действия». [33] Описание руководящих принципов основано на контекстуальном подходе проекта NATURE. [9] [34] [35] и соответствующий механизм его принятия. [24] Можно выделить три типа руководящих указаний:

  • Рекомендации по выбору намерения (ISG) определяют набор намерений, которые могут быть достигнуты на следующем этапе, и выбирают соответствующий набор либо IAG (только один вариант для намерения), либо SSG (несколько возможных намерений).
  • Рекомендации по выбору стратегии (SSG) определяют выбор стратегии, тем самым приводя к выбору соответствующей IAG.
  • Рекомендации по достижению намерения (IAG) направлены на поддержку инженера-приложения в достижении намерения в соответствии со стратегией, касаются тактики реализации этих стратегий, могут предлагать несколько тактик и, таким образом, могут содержать альтернативные рабочие способы выполнения намерения.
Пример Руководства по выбору намерения 1 (ISG-1) [3]
Пример Руководства по выбору стратегии 1 (SSG-1) [3]
Пример Руководства по достижению намерений 8 (IAG-8) [3]

В нашем случае необходимо определить следующие рекомендации, соответствующие карте, показанной выше:

Рекомендации по выбору намерений (ISG)
  1. ISG-1 Прогресс от достижения цели
  2. Прогресс ISG-2 от концептуализации сценария
  3. ISG-3 Прогресс от написания сценария
  4. Прогресс ISG-4 с самого начала
Руководство по выбору стратегии (SSG)
  1. SSG-1 Прогресс для достижения цели
  2. Прогресс SSG-2 в концептуализации сценария
  3. SSG-3 Ход написания сценария
  4. SSG-4 Прогресс для достижения цели
  5. Прогресс SSG-5 должен остановиться
Руководство по достижению намерений (IAG)
  1. IAG-1 Постановка цели с помощью стратегии, основанной на конкретных случаях
  2. IAG-2 Выявление цели с помощью стратегии композиции
  3. IAG-3 Выявление цели с помощью альтернативной стратегии
  4. IAG-4 Выявление цели с помощью стратегии уточнения
  5. IAG-5 Выявите цель с помощью лингвистической стратегии
  6. IAG-6 Выявление цели с помощью стратегии, основанной на шаблонах
  7. IAG-7 Написание сценария со стратегией на основе шаблонов
  8. ИАГ-8 Написать сценарий в свободной прозе
  9. IAG-9 Концептуализация сценария со стратегией компьютерной поддержки
  10. IAG-10 Концептуализация сценария вручную
  11. IAG-11 Остановить со стратегией полноты

На следующем графике показаны подробности Руководства по достижению намерений 8 (IAG-8).

Карта метапроцессов

[ редактировать ]

С точки зрения мультимодели, представленной в статье К. Роллана, метапроцесс (экземпляр модели метапроцесса) — это «процесс генерации пути из карты и его мгновенного применения для приложения». под рукой». [3] Хотя модель метапроцесса может быть представлена ​​по-разному, в качестве средства для этого снова была выбрана карта. Ее не следует путать с картой для модели процесса, представленной выше.

Модель метапроцесса метода CREWS-L'Ecritoire [3]

Колетт Роллан описывает метамодель следующим образом: [3] (Метанамерения выделены жирным шрифтом, метастратегии – курсивом – зеленым на карте.)

« Метанамерение « Начать» запускает построение процесса путем выбора раздела на карте метода, который имеет намерение «Начать карту» в качестве источника. Метанамерение « Выбрать раздел » приводит к выбору раздела карты метода. Метанамерение Принять раздел « » вызывает выполнение раздела карты метода, полученного в результате выбора раздела . Наконец, метанамерение Stop останавливает построение процесса приложения. Это происходит, когда метанамерение Enact Раздел приводит к выполнению раздела карты метода, имеющего Stop в качестве параметра. цель. Как уже объяснялось в предыдущих разделах, существует два способа выбора раздела карты метода, а именно путем выбора намерения или путем выбора стратегии. метанамерения Таким образом, с разделом выбора связаны две метастратегии: выбрать намерение и выбрать стратегию соответственно. После того, как раздел карты метода выбран с помощью Choose Раздел , необходимо получить IAG для поддержки его применения; это представлено на [графике] путем сопоставления метастратегии автоматизированная поддержка с мета-намерением, раздел Enact ».

Пример процесса

[ редактировать ]

Пример процесса «Выявление требований к машине по переработке» представляет собой метод проектирования требований к предприятиям по переработке отходов. Пункты переработки предназначены для клиентов супермаркета. Адекватный метод достигается путем реализации модели метапроцесса в модели процесса.

В следующей таблице показана пошаговая трассировка процесса выявления требований к машине по переработке отходов (от [3] ):

Шаг Руководство Метапроцесс Процесс Продукт (цель = Gxx)
1.1 ССГ-4 Выберите раздел с выбранной стратегией SSG4 предлагает две стратегии. Стратегия, основанная на шаблонах, выбрана потому, что это наиболее подходящий способ ознакомиться с формализацией цели, предлагаемой методом CREWS-L'Ecritoire.  
1.2 ИАГ-6 Раздел Enact с автоматизированной поддержкой IAG6 отображает шаблон постановки цели и объясняет значение каждого параметра. Инженер по требованиям (RE) выбирает свободное утверждение, в котором есть только глагол и цель. G1: Цель Provideverb (предприятия по переработке отходов*) *RF
2.1 ИСГ-1 Выберите раздел с выбранным намерением ISG1 предоставляет RE аргументы, которые помогают ему выбрать одно из двух возможных намерений из «Выявить цель» , а именно « Выявить цель» или «Написать сценарий» . Первое выбрано таким образом, чтобы генерировать альтернативные проектные решения.  
2.2 ИАГ-1 Раздел Enact с автоматизированной поддержкой IAG1 использует структуру формулировки целей и предоставленные значения параметров для создания альтернативных целей. Это приводит к 21 альтернативной цели G1, которые соединяются ИЛИ с G1. После обсуждения с заинтересованными сторонами выбирается G4. G2: Предоставить нашим клиентам бутылку RF с помощью карточного автомата; G3: Предоставлять нашим клиентам бумажные РФ с помощью карточного автомата; G4: Предоставлять нашим клиентам бутылки и коробки RR с помощью карточного автомата; . . . G22: Обеспечьте бутылку RF всем клиентам с помощью машины для возврата денег.
3.1 ССГ-3 Выберите раздел с выбранной стратегией SSG3 предлагает две стратегии, из которых выбирается стратегия, основанная на шаблонах. Это происходит потому, что существует неопределенность относительно того, каким должен быть сценарий. Шаблоны приводят к некоторой уверенности  
3.2 ИАГ-7 Раздел Enact с автоматизированной поддержкой IAG7 предлагает заполнить шаблон. Шаблон соответствует сценарию обслуживания и содержит действия, выражающие услуги, ожидаемые от системы. SC4: Если клиент получает карту, он сдает предметы на переработку.
4.1 ССГ-2 Выберите раздел с выбранной стратегией SSG2 предлагает две стратегии концептуализации сценария. Среди двух стратегий, ручной и компьютерной, выбран первый, поскольку сценарий обслуживания (SC4) очень прост и может обрабатываться вручную.  
4.2 ИАГ-10 Раздел Enact с автоматизированной поддержкой IAG10 предлагает две вещи: (1) избегать анафорических ссылок, таких как он, она и т. д. (2) выражать атомарные действия в явном порядке (3) во избежание двусмысленностей. Сценарий переписан соответствующим образом. SC4: 1. Покупатель получает карту; 2. Клиент сдает коробки и бутылки на переработку.
5.1 ССГ-1 Выберите раздел с выбранной стратегией RE знает, что он хочет проанализировать сценарий SC4, чтобы обнаружить новую цель. Таким образом, он знает целевое намерение «Выявить цель», и отображается SSG1. SSG1 предлагает три стратегии для обнаружения новых целей на основе анализа сценариев. Стратегия уточнения выбрана потому, что необходимо выяснить функциональные требования к машине по переработке отходов.  
5.2 ИАГ-4 Раздел Enact с автоматизированной поддержкой IAG4 помогает преобразовать действия сценария обслуживания SC4 в цели, выражающие функциональные требования. Создаются две цели, которые связываются с G4 отношением «И». G24 выбирается для дальнейшей обработки G23: Получить карту в супермаркете; G24: Переработка бутылок и коробок от RM
6.1 ССГ-3 Выберите раздел с выбранной стратегией RE знает свое целевое намерение, а именно: «Написать сценарий». Таким образом, отображается SSG3, чтобы помочь RE выбрать правильную стратегию. Стратегия свободной прозы выбрана потому, что текст, вероятно, будет длинным, и свободная проза облегчает это.  
6.2 ИАГ-8 Раздел Enact с автоматизированной поддержкой IAG8 предоставляет рекомендации по стилю и содержанию, адаптированные к типу рассматриваемого сценария, а именно к сценарию взаимодействия системы. SC24-1: Клиент вставляет свою карту в RM. RM проверяет, действительна ли карта, а затем выдает подсказку. Клиент вводит бутылки и/или коробки в RM. Если предметы не заблокированы, РМ извлекает карту и распечатывает чек.
7.1 ССГ-2 Выберите раздел с выбранной стратегией Отображается SSG2. Стратегия автоматизированной поддержки выбрана таким образом, чтобы воспользоваться преимуществами мощных лингвистических средств и получить формулировку сценария, которая станет основой для автоматического рассуждения.  
7.2 ИАГ-9 Раздел Enact с автоматизированной поддержкой IAG9 полуавтоматически преобразует исходную прозу в структурированный текст, семантика которого соответствует сценарной модели. Преобразование включает в себя устранение неоднозначности, завершение и отображение лингвистических структур, связанных с концепциями модели сценария. SC24-2 является результатом трансформации SC24-1. (Подчеркнутые утверждения являются результатом преобразования) SC24-2: 1. Клиент вставляет карту клиента в RM, 2. RM проверяет, действительна ли карта, 3. Действительна ли карта, 4. Клиенту выдается подсказка, 5. Клиент вводит данные бутылки и коробки в РМ, 6. РМ проверяет, не заблокированы ли бутылки и коробки, 7. Не заблокированы ли бутылки и коробки, 8. РМ выдает карту клиенту, 9. RM распечатывает чек клиенту
8.1 ССГ-1 Выберите раздел с выбранной стратегией Из трех стратегий, предложенных SSG1, выбирается альтернативная стратегия обнаружения. Эта стратегия соответствует необходимости исследовать варианты и исключения из нормального курса действий, описанного в SC242.  
8.2 ИАГ-3 Раздел Enact с автоматизированной поддержкой IAG3 предлагает несколько тактик для поиска альтернативных целей G24. Выбирается тот, который основан на анализе условий сценария. Это приводит к обнаружению G25 и G26. G25: Утилизировать коробку и бутылки из RM с недействительной картой; G26: Переработка коробок и бутылок с этапом разблокировки

См. также

[ редактировать ]

Ссылки

[ редактировать ]
  1. ^ Перейти обратно: а б с Колетт Роллан (июнь 1993 г.). Моделирование процесса разработки требований . 3-й Европейско-Японский семинар по информационному моделированию и базам знаний. Будапешт, Венгрия. CiteSeerX   10.1.1.29.8738 .
  2. ^ Перейти обратно: а б с д и ж г час я дж к л м н Колетт Роллан (1998). «Комплексный взгляд на технологические процессы». Содержание Материалы 10-й Международной конференции по проектированию передовых информационных систем . . Лондон: Springer-Verlag. стр. 1–24. ISBN  978-3-540-64556-6 .
  3. ^ Перейти обратно: а б с д и ж г час я дж к л м н тот п д Роллан, К.; Пракаш, Н.; Бенджамен, А. (1999). «Мультимодельный взгляд на моделирование процессов» (PDF) . Инженерия требований . 4 (4): 169. дои : 10.1007/s007660050018 . S2CID   6988662 .
  4. ^ Перейти обратно: а б с д и А. Финкельштейн; Дж. Крамер; Б. Нусейбе, ред. (1994). Программное моделирование процессов и технологии . Нью-Йорк: Уайли. ISBN  978-0-471-95206-0 .
  5. ^ К. Ван Слоотен; Б. Ходс (1996). «Характеристика проекта разработки ИБ». ИФИП РГ 8.1 Конф. по методической инженерии . Лондон: Чепмен и Холл. стр. 29–44. ISBN  978-0-412-79750-7 .
  6. ^ В. Де Антонеллис, Б. Перничи, П. Самарати. МЕТОД F-ORM: методология повторного использования спецификаций. В объектно-ориентированном подходе в информационных системах. Ван Аш Ф., Мулен Б., К. Роллан (редакторы), Северная Голландия, 1991 г.
  7. ^ Роллан, Колетт и Пракаш, Навин (1996). «Предложение по разработке контекстно-зависимых методов». Материалы рабочей конференции IFIP TC8, WG8.1/8.2 по разработке методов на тему «Разработка методов: принципы построения методов и инструментальная поддержка» . Лондон: Чепмен и Холл. стр. 191–208. ISBN  978-0-412-79750-7 .
  8. ^ В. Плихон, К. Роллан (1995). «Передовая информационная системная инженерия». Процесс 7-го Межд. Конф. О проектировании передовых информационных систем (CAISE) . Конспекты лекций по информатике. Том. 932. Спрингер Верлаг. стр. 126–139. дои : 10.1007/3-540-59498-1 . ISBN  978-3-540-59498-7 . S2CID   35242104 .
  9. ^ Перейти обратно: а б с Домашняя страница проекта NATURE (Новые подходы к теориям, лежащим в основе разработки требований)
  10. ^ Домашняя страница проекта CREWS (Совместная разработка требований со сценариями)
  11. ^ К. Роллан , К. Бен Ашур, К. Кове, Ж. Ралите, А. Сатклифф, Н. А. Мейден, М. Ярк, П. Хаумер, К. Поль , Дюбуа, П. Хейманс (1998). «Предложение по системе классификации сценариев». Журнал инженерных требований . 3 (1): 23–47. CiteSeerX   10.1.1.30.5360 . дои : 10.1007/BF02802919 . S2CID   1889956 . {{cite journal}}: CS1 maint: несколько имен: список авторов ( ссылка )
  12. ^ К. Роллан (июнь 1994 г.). «Контекстный подход к моделированию процесса разработки требований». 6-й международный Конф. О программной инженерии и инженерии знаний . Юрмала, Латвия. CiteSeerX   10.1.1.52.9389 .
  13. ^ Роллан, К.; Плихон, В. (1996). «Использование фрагментов универсальных методов для создания фрагментов моделей процессов». Материалы второй международной конференции по разработке требований . стр. 173–180. дои : 10.1109/ICRE.1996.491442 . ISBN  978-0-8186-7252-1 . S2CID   2500090 .
  14. ^ Перейти обратно: а б с Летиция Джаккери, Йенс-отто Ларсен и Рейдар Конради (1992). «Моделирование и эволюция программных процессов в EPOS» (PDF) . Транзакции IEEE по разработке программного обеспечения . 19 (12): 1145–1156. CiteSeerX   10.1.1.53.493 . дои : 10.1109/32.249660 .
  15. ^ В. Амбриола, М. Л. Джаккери, Определение и введение в действие программных объектов Oikos, Proc. Первого европейского семинара по моделированию программных процессов, Милан, Италия, 1991 г.
  16. ^ С. Бандинелли; А. Фугетта; С. Григоли (1993). «Моделирование процессов в целом с помощью СЛАНГА (1993)». Учеб. 2-го Межд. Конф. по процессу программного обеспечения . Берлин. стр. 75–93. CiteSeerX   10.1.1.31.9650 . {{cite book}}: CS1 maint: отсутствует местоположение издателя ( ссылка )
  17. ^ В. Эммерих, Г. Юнкерманн, В. Шафер, МЕРЛИН: моделирование процессов, основанное на знаниях, Proc. Первого европейского семинара по моделированию программных процессов, Милан, Италия, 1991 г.
  18. ^ Дерниам Дж. К., Бенали К., Чарой Ф., Буджлида Н., Годарт К. (1989). «Презентация проекта ALF, материалы конференции по средам и фабрикам разработки программного обеспечения» . Берлин. hdl : 10068/43710 . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь ) CS1 maint: несколько имен: список авторов ( ссылка )
  19. ^ Дж. Э. Кайзер; и др. (1988). «Поддержка баз данных для инженерных сред, основанных на знаниях». Эксперт IEEE . 3 (2): 18–32. дои : 10.1109/64.2102 . S2CID   12499409 .
  20. ^ Н. Белхатир; В. Л. Мело (1994). «Поддержка процессов разработки программного обеспечения в Adele2» . Компьютерный журнал . 37 (7): 621–628. дои : 10.1093/comjnl/37.7.621 .
  21. ^ Перейти обратно: а б Инженерия передовых информационных систем . Конспекты лекций по информатике. Том. 1080. Гейдельберг: Шпрингер. 1996. стр. 1–21. дои : 10.1007/3-540-61292-0 . ISBN  978-3-540-61292-6 . S2CID   27968437 .
  22. ^ Хармсен, Ф.; Бринккемпер, С. (1995). «Проектирование и внедрение системы управления методической базой для ситуационной CASE-среды» . Материалы Азиатско-Тихоокеанской конференции по разработке программного обеспечения , 1995 г. стр. 430–438. дои : 10.1109/APSEC.1995.496992 . ISBN  978-0-8186-7171-5 . S2CID   16914451 .
  23. ^ Перейти обратно: а б Г. Мербет. Maestro II - интегрированная система CASE от Softlab, системы и инструменты CASE (под ред. Х. Бальцерта) BI Wissenschaftsverlag, стр. 319-336, 1991 г.
  24. ^ Перейти обратно: а б с Си-Саид, Самира; Роллан, Колетт (1997). «Руководство по процессам проектирования требований». Приложения баз данных и экспертных систем (PDF) . Конспекты лекций по информатике. Том. 1308. Гейдельберг: Шпрингер. стр. 643–652. дои : 10.1007/BFb0022072 . ISBN  978-3-540-63478-2 .
  25. ^ К. Роллан (10–13 июня 1997 г.). «Букварь для разработки методов» . Материалы конференции INFORSID (INFormatique des Organizations et Systemes d'Information et de Decision), Тулуза, Франция . Чепмен и Холл. стр. 1–7. ISBN  978-0-412-79750-7 .
  26. ^ Хагельштейн, Дж (1988). «Декларативный подход к требованиям к информационным системам». Системы, основанные на знаниях . 1 (4): 211–220. дои : 10.1016/0950-7051(88)90031-7 .
  27. ^ Э. Дюбуа; Дж. Хагельштейн; А. Рифо (1989). «Разработка формальных требований с помощью ERAE» Исследование журнала Philips . 43 (4).
  28. ^ Хаумер, П.; Пол, К.; Вайденхаупт, К. (1998). «Выявление и проверка требований на примере реальных сцен». Транзакции IEEE по разработке программного обеспечения . 24 (12): 1036. дои : 10.1109/32.738338 .
  29. ^ Сатклифф, AG; Мейден, НАМ; Миноча, С.; Мануэль, Д. (1998). «Поддержка разработки требований на основе сценариев». Транзакции IEEE по разработке программного обеспечения . 24 (12): 1072. дои : 10.1109/32.738340 .
  30. ^ Э. Дюбуа; П. Хейманс (1998). «Методы, основанные на сценариях, для поддержки разработки и проверки формальных требований». Требование Eng J . 3 (3–4): 202–218. CiteSeerX   10.1.1.45.4151 . дои : 10.1007/s007660050005 . S2CID   2471719 .
  31. ^ Ж. Ралите; К. Роллан; В. Плигон (июнь 1999 г.). «Усовершенствование метода с помощью методов, основанных на сценариях» . Материалы 11-й конференции по разработке передовых информационных систем, Гейдельберг, Германия . Лондон: Springer-Verlag. стр. 103–118. ISBN  978-3-540-66157-3 .
  32. ^ Джейкобсон, Ивар (1992). Объектно-ориентированная разработка программного обеспечения: подход, основанный на сценариях использования . АКМ Пресс. ISBN  978-0-201-54435-0 .
  33. ^ Французский словарь Le Petit Robert, словари Le Robert, Франция, 1995
  34. ^ Роллан, К. (1995). «Подход к определению способов работы». Информационные системы . 20 (4): 337–359. дои : 10.1016/0306-4379(95)00018-Y .
  35. ^ Г. Гросс, К. Роллан , С. Швер; и др. (1997). «Моделирование и проектирование процесса разработки требований: обзор подхода NATURE». Требования Eng J . 2 (3): 115–131. дои : 10.1007/BF02802771 . S2CID   7672233 . {{cite journal}}: CS1 maint: несколько имен: список авторов ( ссылка )
Retrieved from "https://en.wikipedia.org/w/index.php?title=Meta-process_modeling&oldid=1230341815"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 467a3686670256bf582052ff18adc9f9__1719022200
URL1:https://arc.ask3.ru/arc/aa/46/f9/467a3686670256bf582052ff18adc9f9.html
Заголовок, (Title) документа по адресу, URL1:
Meta-process modeling - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)