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

Meta-process modeling
Уровень абстракции для процессов.[1]

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

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

Обзор

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

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

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

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

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

Для этого случая

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

Сборка

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

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

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

Создание

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

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

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

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

Язык

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

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

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

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

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

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

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

Пример: «Просмотр нескольких моделей»

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

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

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

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

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

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

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

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

Карта состоит из целей / намерения (отмечены овалами), которые соединены стратегии (обозначено стрелками). An намерение это цель, задача, которую прикладной инженер имеет в виду в данный момент времени. А стратегия это подход, способ достижения намерения. Связь двух целей со стратегией еще называют раздел.[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. IAG-8 Написать сценарий в свободной прозе
  9. IAG-9 Осмысление сценария со стратегией компьютерной поддержки
  10. IAG-10 Создайте концепцию сценария вручную
  11. IAG-11 Стоп со стратегией полноты

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

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

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

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

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

"The Начните мета-намерение запускает построение процесса, выбирая раздел в карте методов, в котором в качестве источника указано намерение карты Start. В Выберите раздел мета-намерение приводит к выбору раздела карты метода. В Принять раздел мета-намерение вызывает выполнение раздела карты методов в результате Выберите раздел. Наконец, Стоп мета-намерение останавливает построение процесса приложения. Это происходит, когда Принять раздел мета-намерение приводит к включению раздела карты методов с целью Stop. Как уже объяснялось в предыдущих разделах, есть два способа, которыми можно выбрать раздел схемы метода, а именно, путем выбора намерения или выбора стратегии. Следовательно, мета-намерение Выберите раздел с ним связаны две мета-стратегии, выбрать намерение и выбрать стратегию соответственно. После того, как раздел карты методов был выбран Выберите разделнеобходимо восстановить IAG для поддержки его принятия; это представлено в [графике] путем связывания метастратегии автоматическая поддержка с мета-намерением, Принять раздел."

Образец процесса

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

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

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

Смотрите также

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

  1. ^ а б c Колетт Роллан (Июнь 1993 г.). Моделирование процесса разработки требований. 3-й европейско-японский семинар по информационному моделированию и базам знаний. Будапешт, Венгрия. CiteSeerX 10.1.1.29.8738.
  2. ^ а б c d е ж г час я j k л м п Колетт Роллан (1998). «Комплексный взгляд на технологический процесс». Материалы 10-й Международной конференции по перспективной инженерии информационных систем содержание. Лондон: Springer-Verlag. С. 1–24. ISBN 978-3-540-64556-6.
  3. ^ а б c d е ж г час я j k л м п о п q Rolland, C .; Пракаш, Н .; Бенджамен, А. (1999). «Многомодельный взгляд на моделирование процессов» (PDF). Разработка требований. 4 (4): 169. Дои:10.1007 / s007660050018.
  4. ^ а б c d е А. Финкельштейн; Дж. Крамер; Б. Нусейбе, ред. (1994). Программное обеспечение для моделирования процессов и технологий. Нью-Йорк: Вили. ISBN 978-0-471-95206-0.
  5. ^ К. Ван Слоотен; Б. Ходс (1996). «Характеристика проекта развития ИС». IFIP WG 8.1 Conf. по методологии. Лондон: Чепмен и Холл. С. 29–44. ISBN 978-0-412-79750-7.
  6. ^ В. Де Антонеллис, Б. Перничи, П. Самарати. F-ORM METHOD: Методология повторного использования спецификаций. В объектно-ориентированном подходе в информационных системах. Ван Аше Ф., Мулен Б., К. Роллан (редакторы), Северная Голландия, 1991 г.
  7. ^ Роллан, Колетт и Пракаш, Навин (1996). «Предложение по разработке методов с учетом контекста». Труды рабочей конференции IFIP TC8, WG8.1 / 8.2 по методической инженерии по Методической инженерии: принципы построения методов и поддержка инструментов. Лондон: Чепмен и Холл. С. 191–208. ISBN 978-0-412-79750-7.
  8. ^ В. Плихон, К. Роллан (1995). Моделирование способов работы. Proc 7th Int. Конф. О продвинутой инженерии информационных систем (CAISE). Конспект лекций по информатике. 932. Springer Verlag. С. 126–139. Дои:10.1007/3-540-59498-1. ISBN 978-3-540-59498-7.
  9. ^ а б c Домашняя страница проекта NATURE (Новые подходы к теориям, лежащим в основе разработки требований)
  10. ^ Домашняя страница проекта CREWS (Совместная разработка требований со сценариями)
  11. ^ К. Роллан, К. Бен Ачур, К. Кове, Дж. Ралите, А. Сатклифф, N.A.M. Мейден, М. Джарк, П. Хаумер, К. Поль, Дюбуа, П. Хейманс (1998). «Предложение по структуре классификации сценариев». Журнал разработки требований. 3 (1): 23–47. CiteSeerX 10.1.1.30.5360. Дои:10.1007 / BF02802919.CS1 maint: несколько имен: список авторов (ссылка на сайт)
  12. ^ К. Роллан (Июнь 1994). «Контекстный подход к моделированию процесса разработки требований». 6-й международный Конф. О программной инженерии и инженерии знаний. Юрмала, Латвия. CiteSeerX 10.1.1.52.9389.
  13. ^ Rolland, C .; Плигон, В. (1996). Использование фрагментов универсального метода для создания фрагментов моделей процессов. Вторая международная конференция по разработке требований (ICRE'96). С. 173–180. Дои:10.1109 / ICRE.1996.491442. ISBN 978-0-8186-7252-1.
  14. ^ а б c Летиция Хаккери и Йенс-Отто Ларсен и Рейдар Конради (1992). «Моделирование и эволюция программных процессов в EPOS» (PDF). IEEE Transactions по разработке программного обеспечения. 19 (12): 1145–1156. CiteSeerX 10.1.1.53.493. Дои:10.1109/32.249660.
  15. ^ В. Амбриола, М. Л. Джакери, Определение и введение в действие программных объектов Oikos, Proc. Первого Европейского семинара по моделированию программных процессов, Милан, Италия, 1991 г.
  16. ^ С. Бандинелли; А. Фугетта; С. Григоли (1993). «Моделирование процессов в целом с помощью SLANG (1993)». Proc. 2-го Междунар. Конф. по программному процессу. Берлин. С. 75–93. CiteSeerX 10.1.1.31.9650.
  17. ^ W. Emmerich, G. Junkermann, W Schafer, MERLIN: моделирование процессов на основе знаний, Proc. Первого европейского семинара по моделированию программных процессов, Милан, Италия, 1991 г.
  18. ^ Derniame, J.C., Benali, K., Charoy, F., Boudjlida, N., Godart, C. (1989). «Презентация проекта ALF, Труды конференции, среды разработки программного обеспечения и фабрики». Берлин. HDL:10068/43710. Цитировать журнал требует | журнал = (помощь)CS1 maint: несколько имен: список авторов (ссылка на сайт)
  19. ^ Г. Э. Кайзер; и другие. (1988). «Поддержка баз данных для инженерных сред, основанных на знаниях». Эксперт IEEE. 3 (2): 18–32. Дои:10.1109/64.2102.
  20. ^ Н. Белхатир; В. Л. Мело (1994). «Поддержка процессов разработки программного обеспечения в Adele2». Компьютерный журнал. 37 (7): 621–628. Дои:10.1093 / comjnl / 37.7.621.
  21. ^ а б MetaEdit + Полностью настраиваемая многопользовательская и многофункциональная среда CASE и CAME. Конспект лекций по информатике. 1080. Гейдельберг: Springer. 1996. С. 1–21. Дои:10.1007/3-540-61292-0. ISBN 978-3-540-61292-6.
  22. ^ Harmsen, F .; Бринккемпер, С. (1995). «Разработка и внедрение системы управления базой методов для ситуационной среды CASE». Труды 1995 Азиатско-Тихоокеанская конференция по разработке программного обеспечения. С. 430–438. Дои:10.1109 / APSEC.1995.496992. ISBN 978-0-8186-7171-5.
  23. ^ а б Г. Мербет. Maestro II- das intergrierte CASE-system von Softlab, CASE systeme and Werkzeuge (Ed. H. Balzert) BI Wissenschaftsverlag, стр. 319-336, 1991
  24. ^ а б c Си-Саид, Самира; Роллан, Колетт (1997). «Руководство по процессам проектирования требований». Приложения баз данных и экспертных систем. Конспект лекций по информатике. 1308. Гейдельберг: Springer. С. 643–652. Дои:10.1007 / BFb0022072. ISBN 978-3-540-63478-2.
  25. ^ К. Роллан (10–13 июня 1997 г.). «Учебник по методологии». Материалы конференции ИНФОРСИД (INFormatique des organization et Systemes d'Information et de Decision), Тулуза, Франция. Чепмен и Холл. С. 1–7. ISBN 978-0-412-79750-7.
  26. ^ Хагельштейн, J (1988). «Декларативный подход к требованиям информационных систем». Системы, основанные на знаниях. 1 (4): 211–220. Дои:10.1016/0950-7051(88)90031-7.
  27. ^ Э. Дюбуа; Дж. Хагельштейн; А. Рифо (1989). «Формальная разработка требований с ERAE». Philips Journal Research. 43 (4).
  28. ^ Haumer, P .; Pohl, K .; Weidenhaupt, K. (1998). «Выявление и проверка требований на реальных сценах». IEEE Transactions по разработке программного обеспечения. 24 (12): 1036. Дои:10.1109/32.738338.
  29. ^ Sutcliffe, A.G .; Дева, N.A.M .; Minocha, S .; Мануэль, Д. (1998). «Поддержка разработки требований на основе сценариев». IEEE Transactions по разработке программного обеспечения. 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.
  31. ^ Ж. Ралите; К. Роллан; В. Плихон (июнь 1999 г.). «Улучшение метода методами на основе сценария». Материалы 11-й конференции по проектированию современных информационных систем, Гейдельберг, Германия. Лондон: Springer-Verlag. С. 103–118. ISBN 978-3-540-66157-3.
  32. ^ Якобсон, Ивар (1992). Объектно-ориентированная разработка программного обеспечения: подход на основе вариантов использования. ACM Press. ISBN 978-0-201-54435-0.
  33. ^ Французский словарь Le Petit Robert, Dictionnaires Le Robert, Франция, 1995
  34. ^ Роллан, С. (1995). «Подход к определению способов работы». Информационные системы. 20 (4): 337–359. Дои:10.1016 / 0306-4379 (95) 00018-У.
  35. ^ Г. Грош, К. Роллан, С. Швер; и другие. (1997). «Моделирование и инженерия процесса разработки требований: обзор подхода NATURE». Требования Eng J. 2 (3): 115–131. Дои:10.1007 / BF02802771.CS1 maint: несколько имен: список авторов (ссылка на сайт)