Контекстная диаграмма системы

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

Обзор

Контекстные диаграммы системы показывают систему в целом, а также ее входы и выходы от/к внешним факторам. По словам Косьякова и Свита (2011): ^[3]

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

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

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

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

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

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

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

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

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

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

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

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

См. также

Ссылки

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

Внешние ссылки

[1] Управление проектом NDE. Архивировано 7 ноября 2008 г. на веб-сайте использования данных Wayback Machine (NPOESS). 2008.

[2] Манодж Кумар Чубей (2012) ИТ-инфраструктура и управление (для GBTU и MMTU) . п. 53

[KoSw03-3] Александр Косяков, Уильям Н. Свит (2011). Системная инженерия: принципы и практика с. 266

[4] Ричард Винер (1998) Журнал объектно-ориентированного программирования . Том 11. с. 68

[5] Сюзанна Робертсон, Джеймс К. Робертсон (2006) Освоение процесса требований . Пирсон Эдьюкейшн, 17 мкр. 2006 г.

[6] Моделирование системных целей с использованием i *: подход в проекте спасательного центра HCI, 27 февраля 2003 г.

[USDT06-7] Перейти обратно: ^а ^б ^с Министерство транспорта США, Управление операций (2006 г.) Региональный руководящий документ по архитектуре ИТС . июль 2006 г.

[8] Грэм К. Симсион , Грэм К. Витт (2005). Основы моделирования данных . п. 512.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]