Контекст системы

Любая
система содержит внутри себя какие-либо
сущности, в то время как другие сущности
остаются за ее пределами. Например, в
системе проверки кредитных карточек
имеются счета, транзакции и механизмы
проверки подлинности. В то же время
обладатели кредитных карточек и торговые
предприятия находятся вне системы.
Сущности внутри системы отвечают за
реализацию поведения, которого ожидают
сущности, находящиеся снаружи. Сущности,
находящиеся вне системы и взаимодействующие
с ней, составляют ее контекст. Таким
образом, контекстом называется окружение
системы.

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

Моделирование
контекста системы состоит из следующих
шагов:

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

2. Организуйте похожих актеров с помощью
   отношений обобщения/специализации;

3. Введите стереотипы для каждого актера,
   если это облегчает понимание;

4. Поместите актеров на диаграмму
   прецедентов и определите способы их
   связи с прецедентами системы.

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

Рисунок 2 – Моделирование контекста
системы

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

Требование
(Requirement) – это особенность проекта,
свойство или поведение системы. Приступая
к сбору требований, описываются условия
контракта, заключаемого между системой
и сущностями вне ее, в котором декларируется,
что система должна делать. При этом, как
правило, пользователя заботит не то,
как именно система будет выполнять
поставленные задачи, а только то, что
она будет делать. Хорошо спроектированная
система должна полностью выполнять все
требования, причем делать это предсказуемо
и надежно. Ее создание начинается с
соглашения о том, каково ее назначение,
хотя в ходе разработки понимание
требований будет постепенно изменяться.
Аналогично при работе с готовой системой
понимание того, как она себя ведет, имеет
принципиальное значение для ее правильного
использования.

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

Моделирование
требований к системе производится
следующим образом:

1. Установите контекст системы,
   идентифицировав окружающих ее актеров;

2. Для каждого актера рассмотрите поведение,
   которого он ожидает или требует от
   системы;

3. Поименуйте эти общие варианты поведения
   как прецеденты;

4. Выделите общее поведение в новые
   прецеденты, которые будут использоваться
   другими; выделите вариации поведения
   в новые прецеденты, расширяющие основные
   потоки событий;

5. Смоделируйте этих прецедентов, актеров
   и отношения между ними на диаграмме
   прецедентов;

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

Рис.
3 расширяет предыдущую диаграмму. Хотя
отношения между актерами и прецедентами
на ней опущены, но присутствуют
дополнительные прецеденты, которые
описывают важные, пусть и невидимые для
обычного пользователя, элементы поведения
системы. Эта диаграмма удобна, поскольку
дает возможность пользователям, экспертам
и разработчикам совместно визуализировать,
специфицировать, конструировать и
документировать свои решения относительно
функциональных требований к системе.
Например, прецедент Обнаружение фальшивых
карточек описывает поведение, важное
как для Торговых предприятий, так и для
Субсидирующих финансовых институтов.
Другой прецедент — Отчет о состоянии
счета — также описывает поведение,
требуемое от системы различными
организациями в своих контекстах.

Рисунок 3 – Моделирование требований
к системе

Создавая
диаграммы прецедентов в UML, помните, что
каждая из них является всего лишь
графическим представлением статического
вида системы с точки зрения прецедентов.
Это означает, что ни одна диаграмма
прецедентов, взятая в отдельности, не
может, да и не должна охватывать весь
этот вид целиком. В совокупности диаграммы
прецедентов дают полное представление
о виде системы с точки зрения прецедентов,
а каждая из них в отдельности — только
об одном из его аспектов.

Задача: Определение контекста системы

Задача: Определение контекста системы Данная задача определяет, как создать диаграмму системного контекста, показывающую кооперирование верхнего уровня между системой и ее субъектами. Назначение Создание кооперирования верхнего уровня основывается на модели вариантов использования  . Диаграмма показывает систему, смоделированную как подсистему верхнего уровня, ее интерфейсы и взаимосвязи с субъектами, включая внешние сущности ввода и вывода, которые проводят объекты между системой и субъектом. Взаимосвязи Роли Основной: Аналитик Дополнительно: Разработчик архитектуры Помощь: Входы Обязательный: Дополнительные спецификации Модель анализа Модель прецедентов Необязательный: Нет Внешний: Нет Выходы Модель анализа Модель прецедентов Операция Шаги Введение Поскольку модель вариантов использования показывает контекст поведения для системы, в этой задаче изображается логическая модель системы в ее среде с помощью рабочего продукта Модель вариантов использования   и  рабочего продукта Дополнительные спецификации в Диаграмме контекста. Интерфейсы, которые необходимо реализовать системе (в терминах операций, предоставляемых системой, и связанных поддерживаемых протоколов, переменные состояния и хранилищ, реализуемых системой, и атрибутов, описанных как Величина технической характеристики). Сущности ввода-вывода, которые проводят объекты между системой и ее субъектами. Необходимые интерфейсы системы (реализуемые субъектами, которые взаимодействуют с системой) для правильной работы. В случае, если субъекты системы представляют существующую систему, с которой данная система должна взаимодействовать, эти необходимые интерфейсы отражают ограничения, наложенные этой внешней системой. Диаграмма контекста показывает кооперирование верхнего уровня между системой и ее субъектами. Это структурный аналог модели вариантов использования для системы. Данное кооперирование создается в модели анализа. Сущности ввода-вывода (представляемые при моделировании как стереотипы классов ввода-вывода с атрибутами, но без операций) описывают потоки внутрь и вовне системы, и могут в общем случае включать данные, массу, энергию или физические элементы. Сущности ввода-вывода при моделировании связаны с парами субъект-система, что отражает работу сущностей ввода-вывода по проведению потока между субъектом и системой. Их можно показать на диаграммах в связи с субъектами, и направление потока по отношению к субъекту указывается на связи стереотипом «передача» или «прием». Системная операция — это служба, вызываемая из объекта для выполнения поведения. Операция указывает имя, тип, параметры и ограничения на вызов связанного поведения. Операции объединяются вокруг интерфейсов вдоль основных полномочий разрабатываемой (под)системы. Вызов системной операции представляет собой более мелкомодульное взаимодействие с системой, чем экземпляр варианта использования. Экземпляр варианта использования — это совокупность операций вызова и ответов. Хранилища и переменные состояния — это атрибуты, определяемые в интерфейсах, реализуемых системой. Они являются абстрактными и требуют, чтобы система поддерживала информацию, соответствующую типу и множественности атрибута и позволяла хранение, поиск и изменение этой информации. При этом не подразумевается, что атрибут в системе прямо соответствует атрибуту, определенному в интерфейсе. Разница между хранилищами и переменными состояния отражает то, как атрибуты используются для контроля операций конечного автомата системы. Состояние сохраняется какой-то период времени, в отличие от события, например, получения сигнала, которое случается в момент времени. Конечный автоматы определяются немногими переменными, например, текущее состояние может быть определено значением одного атрибута перечислимого типа. Однако, реакция системы на событие может зависеть не только от характера события (и информации, содержащейся, например, в операционных параметрах) и текущего состояния, но также от значений многих атрибутов. Величина технической характеристики — это ключевой атрибут, выбранный из Дополнительных спецификаций или модели вариантов использования, как основной показатель эффективности системы. Если он не выполняется, это означает, что возникает риск нарушения запланированных сроков, превышения стоимости и не соблюдения требований по быстродействию. Поэтому значения этого атрибуты отслеживаются на протяжение существования проекта. Например, может быть необходимо соблюдать ограничение по весу системы. Таким образом, необходимо отслеживать соблюдение этого параметра при проектировании и создании системы. Вес системы — это параметр экземпляра системы, и он не обязательно равен целевому весу при разработке. Например, для системы, запускаемой в космос — чем меньше вес, тем лучше. Для указания целевого значения Величины технической характеристики можно использовать значение UML в тегах, например: «Показатель технической характеристики» вес {максимальный_вес = 1000 кг} Показатель технической характеристики может также применятся к другим не структурным параметрам, таким как время ответа на операцию. Значения в тегах можно применять к системным операциям или к самой системе для записи. Создать начальную диаграмму контекста Следующие шаги показывают развитие уровней детализации системы в контексте. Следующий пример иллюстрирует систему безопасности, защищающую собственность от вторжения. В дополнение к подаче звуковой тревоги система обладает возможностью извещать соответствующие службы о проникновениях.   При развитии модели вариантов использования в нее добавляются субъекты или, если они уже определены, уточняется их взаимодействие. Таким образом создается первичное кооперирование и показывается с помощью диаграмма контекста. Диаграмма контекста может быть создана сначала без системных интерфейсов. Система изображается как подсистема верхнего уровня (стереотип «системы»), который затем реализует несколько интерфейсов. Субъекты и их связи сначала изображаются без детализации. Начальная диаграмма контекста Уточнение связей и интерфейсов Далее необходимо уточнить связи между субъектами и системой, а также системные интерфейсы. Требуется анализ системных операций и системных атрибутов при их появлении в  задаче Поиск субъектов и вариантов использования (Позднее Задача Детализация варианта использования). Обратите внимание, что теперь система общается с субъектами посредством интерфейсов. Можно выделить данную реализацию пунктирным кругом, но можно опустить выделение без какой-либо потери смысла. На данном этапе сущности ввода-вывода определяются только экспериментально на основании сведений о проблемной области, а также предварительной работы по созданию вариантов использования на уровне организации.  Обратите внимание, что на диаграмме не обязательно показывать сущности ввода-вывода, но это полезно для анализа взаимодействия субъект-система. Таким образом, можно начать описывать связи между субъектами и системой и поток сущностей между ними. Предварительная диаграмма контекста Детализация системных операций и других системных параметров. На этом шаге создаются сценарии вариантов использования (экземпляры вариантов использования), с помощью которых можно описывать системные операции (предоставляемые и необходимые). Сценарии можно иллюстрировать с помощью диаграмм взаимодействия или операций. Каждый черный ящик в варианте использования представляет мелкомодульное взаимодействие с системой и соответствует вызову операции, но не обязательно уникальной — другие черные ящики также могут использовать эту операцию. Вариант использования комментируется для трассируемости вызываемой операции, а системная операция определяется в диаграмме контекста (и следовательно в модели анализа). Операции наследуют технические и другие не функциональные требования, связанные с черным ящиком. Имена в черных ящиках соответствуют хранилищам и переменным состояния, которые система должна поддерживать  для выполнения сценария варианта использования. Также можно уточнить необходимые сущности ввода-вывода и связать их с вызовами операций для передачи сигналов между системой и субъектами.   Можно также разделить системный интерфейс на специфические интерфейсы в соответствии с требованиями, содержащимися в Дополнительных спецификациях. Рисунок ниже показывает развитие системного интерфейса в «предоставляемый системный интерфейс» для каждого типа субъекта (хотя это не является обязательным требованием). Субъекты могут совместно использовать интерфейс, а также может быть несколько интерфейсов для каждого субъекта. Данный анализ также может определить, какие интерфейсы необходимы системе, т.е. должны поддерживаться субъектами для обработки сообщений системы. Это можно добавить на диаграмму симметричным способом, например, как показано на диаграмме ниже — «необходимый системный интерфейс» службы IE/ESS, реализованный субъектом аварийной службой.  Напомним, что, хотя это не показано на диаграмме, субъект может поддерживать или реализовывать несколько интерфейсов. Операции, хранилища и т.д. необходимо добавлять к расширенной версии интерфейсов в отделения атрибутов и операций, как показано на диаграмме. По причине экономии места диаграмма выполнена частично. Интерфейс с физической средой, субъекты и т.д. не раскрыты. Обратите внимание, что реализацию предоставляемых системных интерфейсов можно опустить без потери передаваемого смысла. Завершающая диаграмма контекста Данное кооперирование верхнего уровня, показанное на диаграмме контекста, позволяет точно специфицировать интерфейсы, связи, входящие и исходящие системные потоки, а также операционные параметры, что позволяет разрабатывать систему независимо от других элементов системного контекста. Свойства Несколько вхождений Управляется событиями Выполняющийся Необязательный Запланированный Повторяющийся ©  Copyright IBM Corp.  1987, 2006.  Все права защищены..

Что такое системный контекст?

Что такое системный контекст, почему он важен и как вы отслеживаете свою систему?

Запланированный системный элемент находится в центре схемы. Он представляет разрабатываемую систему, описывает объем и функции системы.

Актеры — это пользователи, устройства или соседние системы, взаимодействующие с системой.

На диаграммах элемент системного контекста представляет собой элемент, находящийся внутри или вне системного контекста.

Элементы системного контекста, находящиеся внутри системного контекста, связаны с системой через информационный поток.

Законы, нормы и другие документы могут оказывать влияние на систему. Они связаны с системой через отношения правил.

Это пример элемента системного контекста, который не является частью системного контекста. Он не подключен к системе.

Что такое системный контекст?

Термин системный контекст относится к среде вашей системы. Разрабатываемая система никогда не стоит сама по себе, она связана со своим окружением.

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

Помимо системы и ее контекста существует нерелевантная среда, содержащая все, что не оказывает никакого влияния на систему и ее развитие.

Разграничение системного контекста отвечает на три жизненно важных вопроса

Почему важен системный контекст?

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

Как вы отслеживаете?

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

Обзор
нашей базы знаний

Применение знаний с помощью правильного инструмента:
objectiF RPM

Найдите еще
интересных загрузок здесь

© Copyright — microTOOL

системный контекст — Глоссарий | CSRC

• Проекты

• Публикации

  Развернуть или свернуть

• Темы

  Развернуть или свернуть

• Новости и обновления
• События
• Глоссарий

• О CSRC

  Развернуть или свернуть

Поиск

Сортировать по

Релевантность (наилучшее совпадение)Срок (A-Z)Срок (Z-A)

Пункты на странице
100200500Все

Глоссарий

А
|
Б
|
С
|
Д
|
Е
|
Ф
|
грамм
|
ЧАС
|
я
|
Дж
|
К
|
л
|
М
|
Н
|
О
|
п
|
Вопрос
|
р
|
С
|
Т
|
U
|
В
|
Вт
|
Икс
|
Д
|
Z

системный контекст

Определения:

  Конкретные системные элементы, границы, взаимосвязи, взаимодействия и операционная среда, которые определяют систему.

This entry was posted in Популярное