Диаграмма контекста системы - System context diagram

Пример контекстной диаграммы системы.[1]

А диаграмма контекста системы (SCD) в инженерное дело это диаграмма который определяет границу между система, или часть системы и ее окружение, показывая сущности, которые с ней взаимодействуют.[2] Эта диаграмма представляет собой общий вид система. Это похоже на блок-схема.

Обзор

Диаграммы контекста системы показывают систему в целом и ее входы и выходы от / до внешних факторов. Согласно Kossiakoff и Sweet (2011):[3]

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

Диаграммы контекста системы используются на ранних этапах проекта, чтобы согласовать исследуемый объем.[4] Диаграммы контекста обычно включаются в документ требований. Эти диаграммы должны быть прочитаны всеми заинтересованными сторонами проекта и, следовательно, должны быть написаны простым языком, чтобы заинтересованные стороны могли понять элементы в документе.

Строительные блоки

Контекстные диаграммы можно разрабатывать с использованием двух типов строительных блоков:

  • Сущности (Актеры): маркированные коробки; один в центре, представляющий систему, и вокруг него несколько прямоугольников для каждого внешнего субъекта
  • Отношения: обозначенные линии между объектами и системой

Например, «клиент размещает заказ». Контекстные диаграммы также могут использовать множество различных типов чертежей для представления внешних сущностей. Они могут использовать овалы, фигурки, картинки, картинки или любое другое изображение для передачи смысла. Деревья решений и хранилище данных представлены в виде блок-схем системы.

Контекстная диаграмма также может перечислять классификации внешних объектов как одну из набора простых категорий.[5] (Примеры:[6]), которые добавляют ясности в уровень вовлеченности объекта в систему. Эти категории включают:

  • Активный: Динамический для достижения определенной цели (например, «читатели статьи» или «клиенты»).
  • Пассивный: Статические внешние объекты, которые нечасто взаимодействуют с системой (Примеры: «Редакторы статей» или «администратор базы данных»).
  • Кооператив: Предсказуемые внешние объекты, которые используются системой для достижения желаемого результата (Примеры: «Интернет-провайдеры» или «судоходные компании»).
  • Автономный (Независимый): Внешние объекты, которые отделены от системы, но влияют на систему косвенно, посредством наложенных ограничений или подобных влияний (Примеры: «регулирующие комитеты» или «группы стандартов»).

Альтернативы

Лучшие системные контекстные диаграммы используются для отображения того, как система взаимодействует на очень высоком уровне или как системы работают и логически взаимодействуют. Диаграмма контекста системы является необходимым инструментом в разработке базового взаимодействия между системами и участниками; акторы и система или системы и системы. Альтернативы контекстной диаграмме системы:

Пример схемы межсоединения архитектуры.[7]
  • Схема межсоединений архитектуры: На рисунке приведен пример архитектурной схемы межсоединений. На рисунке показано представление межсоединений региональной архитектуры ITS Альбукерке для управления полиции Альбукерке, созданное с помощью инструмента Turbo Architecture. Каждый блок представляет собой элемент инвентаризации ITS, включая имя заинтересованной стороны в верхней заштрихованной части. Линии соединения между элементами сплошные или пунктирные, что указывает на существующие или планируемые соединения.[7]
  • Холст бизнес-модели, шаблон стратегического управления для разработки новых или документирования существующих бизнес-моделей. Это наглядная диаграмма с элементами, описывающими ценностное предложение, инфраструктуру, клиентов и финансы фирмы [1]. Он помогает компаниям согласовывать свою деятельность, демонстрируя возможные компромиссы.
  • Модель данных предприятия: Этот тип модель данных согласно Simsion (2005) может содержать от 50 до 200 классов сущностей, что является результатом конкретного «высокого уровня обобщения в моделирование данных ".[8]
  • IDEF0 Контекстная диаграмма верхнего уровня: The IDEF0 процесс начинается с определения простой функции, которую нужно разложить. Эта функция обозначена на «диаграмме контекста верхнего уровня», которая определяет объем конкретного анализа IDEF0.
  • Диаграммы проблем (кадры проблем): В дополнение к тому, что показано на контекстной диаграмме, диаграмма проблем показывает требования и ссылки на требования.
  • Диаграмма вариантов использования: Один из Единый язык моделирования диаграммы. Они также представляют собой объем проекта на аналогичном уровне абстракции. - Сценарии использования, однако, больше фокусируются на целях «субъектов», которые взаимодействуют с системой, и не определяют какое-либо решение. Диаграммы вариантов использования представляют собой набор вариантов использования, которые представляют собой текстовые описания того, как субъект достигает цели варианта использования. например, заказчик размещает заказ.
  • ArchiMate: ArchiMate - это открытый и независимый язык моделирования архитектуры предприятия, который недвусмысленно поддерживает описание, анализ и визуализацию архитектуры внутри и между сферами бизнеса.

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

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

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

  1. ^ Управление проектами неразрушающего контроля В архиве 7 ноября 2008 г. Wayback Machine (NPOESS) Веб-сайт по эксплуатации данных. 2008 г.
  2. ^ Манодж Кумар Чубей (2012) ИТ-инфраструктура и управление (для ГБТУ и ММТУ). п. 53
  3. ^ Александр Косяков, Уильям Н. Свит (2011). Системная инженерия: принципы и практика п. 266
  4. ^ Ричард Винер (1998) Журнал объектно-ориентированного программирования. Том 11. с. 68
  5. ^ Сюзанна Робертсон, Джеймс С. Робертсон (2006) Освоение процесса требований. Pearson Education, 17 мрт. 2006 г.
  6. ^ Системное моделирование целей с использованием подхода i *: в RESCUE Центр дизайна HCI, 27 февраля 2003 г.
  7. ^ а б c Департамент транспорта США, Управление операций (2006 г.)Региональный руководящий документ по архитектуре ИТС. Июль 2006 г.
  8. ^ Грэм С. Симсион, Грэм К. Уитт (2005). Основы моделирования данных. п. 512.

внешняя ссылка