К обсуждению онтики сервисов и Use Cases

Посты студентов
, , ,
1

world-inclusion.png801×330 453 KB

13 - 16 апреля был в Бекасово на ежегодной встрече INCOSE по проблемам системной инженерии. Там состоялась очередная дискуссия по онтике сервисов (началась дискуссия еще 5 лет назад).

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

1. Сама онтика сервисов. Основной вопрос был про соотношение функций и сервисов. Уже на кофе-брейке договорились, что нужно различать для нашей системы следующее:

  • Функции, которые наша система выполняет в надсистеме. Это то же самое что функции нашей системы в надсистеме. Тут сбивает язык: мы говорим, что это функции нашей системы, но это не совсем так, потому что мы порой и не знаем, какие функции наша система будет выполнять в надсистеме. Хотя конечно мы догадываемся.
  • Сервисы нашей системы. Вот тут уже мы даже не знаем в какие надсистемы наша система будет включена, но можем описать поведение нашей системы как черного ящика.
  • Функции (внутри) нашей системы, которые реализуют сервисы нашей системы. И эти же функции выполняются сервисами подсистем.

2. Что из этого описывает юзкейс? Ответ - все, но не сразу. Практика юзкейсов удивительно всеядна. Она позволяет описать:

  • Функции в надсистеме. Причем здесь есть два варианта.
    • Первый вариант: Разработчики системы, которая для нашей является надсистемой, выполняют функциональную декомпозицию и привязку. Один из способов это сделать - как раз техники юзкейсов (но не базовые, а варианты Use Case Realization или FAS). Есть и другие варианты это сделать (более распространенная техника - Allocation Matrix).
    • Второй вариант: Если система очень сложная, например, самолет, то внутри разработчика надсистемы есть команда, которая разрабатывает концепцию эксплуатации для нашей системы (а для них это подсистема). Обычно вначале там функциональный объект (роль). И эту концепцию они могут делать с помощью юзкейсов. Тут как раз вполне традиционная техника: диаграмма юзкейсов (правда ее как правило не рисуют, а делают табличку-перечень) и для каждого юзкейса его дескрипшен.
  • Сервисы нашей системы. Разрабатывая нашу систему мы не можем идти по первому варианту из предыдущего пункта. Нам ведь никто не расскажет деталей архитектуры надсистемы: там есть много того, что нас не касается. К тому же, мы обычно рассчитываем встроиться во множество разных надсистем, в том числе, про которые даже не знаем пока. Поэтому мы делаем концепцию эксплуатации, описывающую сервисы нашей надсистемы, стараясь в контексте описывать функциональные объекты (роли). Здесь тоже традиционно: диаграмма юзкейсов (табличка) и для каждого юзкейса его дескрипшен.
  • Функции (внутри) нашей системы - здесь все аналогично функциям в надсистеме. Только теперь мы ее разработчики. А юзкейсы будем использовать точно так же: Use Case Realization или FAS. Это позволит понять, выполнение каких функций нужно реализовать сервисами подсистем.

3. Цепочка встраивания функциональных и конструктивных объектов. Здесь все тоже более-менее понятно. Но нужно это объяснать аккуратно. Потому что в текущих объяснениях это онтика как в старой гамбургер-диаграмме, а не как в ISO 81346. Хотя тут тоже нужно еще разбираться. Кажется с онтикой ISO 81346 тоже все не так хорошо.

1 лайк
2

Кирилл, отлично, что начали прорабатывать этот вопрос. Я хотел его вместе с другими подобными вопросами вынести на методсовет. Можно совместно подготовить статью, методрекомендацию и т.п. по этому вопросу.

Еще вопрос по вот этому:

  • Функции (внутри) нашей системы, которые реализуют сервисы нашей системы. И эти же функции выполняются сервисами подсистем.
Наверное, ты имел ввиду "Функции ПОДСИСТЕМ нашей системы, .....".
3

Да, затронули множество вопросов. Понял, что нужно выходить на коллективное мышление письмом чтобы продвинуться.
Статья - в журнал ШСМ?
Методрекомендации это что за формат?

Отвечая на твой вопрос: Конечно, в итоге это будет функциями подсистем нашей системы. Но когда мы думаем о системе в дизайн тайм, мы ничего про подсистемы можем и не знать. Мы понимаем какой сервис наша системы будет выдавать наружу (у нас есть гипотеза), и под этот сервис начинаем прорабатывать реализацию. Рисуем какой-то вариант функциональной схемы. Возможно, подсистемы мы еще не выделили, а функциональные цепочки уже нарисовали. Подсистемы появятся на следующем шаге. Более того, может оказаться, что какие-то функции будут реализовываться не внутри нашей системы, а придется использовать какой-то сервис снаружи. Так что даже “выполняются сервисами подсистем” это чересчур узкая формулировка.

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

4

«описать нашу поведение нашей системы» очепятка

И чуть выше видится тафтология: «Функции, которые наша система выполняет в надсистеме. Это то же самое что функции нашей системы в надсистеме.», не достаточно понятно зачем тут повтор. Выглядит как «Масло. Это то же самое что масло.»

5

Да, опечатка. Спасибо. Поправил.

Это конечно тафтология. Но я специально записал это два раза. Дело в том, что фраза “функции нашей системы” часто употребляется без уточнения. А без уточнения возникает путаница. А для дискуссии, в рамках которой этот пост вообще возник, это уточнение важно. Я бы даже сказал, критически важно.

6

А не скажете ли, с чем оно путалось?

7

Это даже я скажу, откуда такое возникает. Функции::поведение путают с ролями::“объектами, у которых поведение”. Массово. Поэтому слово “выполняют” вроде как добавляет тип “поведение как изменение состояния чего-то вовне системы”. Обычно или объект без поведения, или поведение без объекта. И ещё к этому сервис припутывается, тут вообще швах.

Это всё ранние тексты, в последней версии “Системного мышления” эти вопросы более подробно разъясняются, поэтому ошибок таких меньше должно быть. Можно тексты такие проще писать )))