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

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

Основными методами, которые можно отметить, являются (по именам создателей) ДеМарко (DeMarco, 1978), Иордон (Yourdon, 1990), Румбах (Rumbaugh, 1991), Шлер и Меллор (Shlaer, Mellor, 1998). Остальные методы, которые здесь также можно было бы перечислить, являются модификацией названных, в которых лишь изменен немного порядок действий и добавлены некоторые незначительные улучшения.

Стоит отметить, что сходств между этими методами гораздо больше, чем различий.

3.3.1 Методы перспектив.

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

• точки зрения заинтересованных сторон (stakeholders);.

• точки зрения экспертов, обладающих знаниями в предметной области и организации.

Роль и влияние точки зрения заинтересованных сторон для проекта вполне понятна и не вызывает вопросов у разработчиков требований. При этом точки зрения экспертов,.

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

В последующих разделах рассматриваются три различных метода, основанных на использования перспектив.

Контролируемое формулирование требований (Controlled Requirements Expression или CORE).

Метод контролируемого формулирования требований был изначально разработан в процессе работы по анализу требований для министерства обороны Великобритании.

Рис. 3.14 Представления и понятия метода контролируемого формулирования требований.

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

На рис. 3.14 изображены основные понятия и представления, использующиеся в методе.

Основным понятием метода является перспектива (точка зрения) и связанное с ней представление, известное как иерархия перспектив. В качестве перспективы может быть выбрана точка зрения на разрабатываемую систему отдельного человека, роли или организации [Такой подход был использован Дарке и Шанксом (Darke, Shanks, 1997) как основа для анализа точек зрения пользователей]. На уровне системных требований перспективы могут также отражать предназначение самой системы, а также ее частей или подсистем, входящих в окружение разрабатываемой системы и оказывающих влияние на ее функционал. Перспективы образуют иерархию, которая используется для определения границ системы и помогает процессу анализа.

В качестве иллюстрации вышесказанного, на рис. 3.15 представлен предварительный перечень возможных перспектив для системы контроля за торможением самолета (Aircraft brake and control system - ABCS), полученный в результате мозгового штурма.

Рис. 3.15 Предварительный перечень перспектив для системы контроля торможением самолета.

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

На рис. 3.16 представлена часть иерархии перспектив для системы контроля за торможением самолета.

Рис. 3.16 Пример иерархии.

Метод контролируемого формулирования требований предусматривает, что любая операция, выполняемая со стороны перспективы, должна быть четко определена. Каждая операция может использовать или производить информацию или другие элементы, характерные для рассматриваемой системы (например, товары). Вся информация, полученная в результате такого анализа, заносится в сводную табличную форму (TCF = Tabular Collection Form), возможный образец которой показан в таблице 3.1.

Таблица 3.1 Сводная табличная форма

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

Таблица 3.2 Пример сводной табличной формы (TCF)

Линии, связывающие между собой соседние столбцы, обозначают существование потоков.

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

Дальнейший анализ заключается в поочередной разработке более подробных моделей потоков данных для каждой перспективы. При этом отправной точкой для создания моделей перспектив служит информация, занесенная в сводную табличную форму (SVMs = Single Viewpoint Models). Модели перспектив описывают дополнительно потоки, находящиеся «внутри» перспективы, а также хранилища данных. Модель перспективы также описывает то, как операции перспективы контролируются и управляются в зависимости от потоков в других операциях (и реагируют на события в них).

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

Другое основное понятие метода CORE это системная транзакция.

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

Техника структурного анализа и проектирования (Structured Analysis and Design Technique или SADT).

Метод техники структурного анализа и проектирования (Structured Analysis and Design Technique или SADT) берет начало из работ Росса (Ross), посвященных структурному анализу, которые он проводил в 70-х годах.

Этот метод основан на применении диаграмм.

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

Основной элемент графической нотации метода является прямоугольник, который обозначает действие (на диаграммах действий), или данные (на диаграммах данных).

Рис. 3.17 Основные элементы техники структурного анализа и проектирования.

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

На рис. 3.17 показаны четыре основных типа стрелок. Тип стрелки зависит от того, с какой стороны она соединяется с прямоугольником (подходит к нему):.

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

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

• Управляющие стрелки соединяются с прямоугольником сверху и определяют способ преобразования входящей информации.

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

Любая диаграмма в этом методе состоит из ряда прямоугольников, связанных стрелками.

Таким образом, любая проблема детализируется и уточняется путем последовательной.

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

рис. 3.18.

Рис. 3.18 Проведение декомпозиции с использованием техники структурного анализа и.

проектирования.

На рис. 3.19 представлен пример диаграммы действий для системы контроля торможением самолета. Декомпозиция продолжается до тех пор, пока не будет получено достаточно подробное описание для начала разработки архитектуры решения.

Рис. 3.19 Пример использования техники структурного анализа и проектирования (SADT).

Определение требований, основанное на перспективах (Viewpoint-oriented Requirement Definition или VORD).

Определение требований, основанное на перспективах [Котонья (Kotonya) и Саммервилль (Sommerville), 1996] это метод, базирующийся на парадигме рассмотрения различных перспектив (точек зрения).

Метод использует «сервис-ориентированную» модель, в которой перспектива может рассматриваться в качестве «клиента», если эту модель сравнивать с системой типа «клиент-сервер». Модель ориентирована на предоставление сервисов клиентам, точки зрения (перспективы) которых принимаются во внимание при разработке системы.

Концепция метода заключается в том, что «клиент» (= перспектива) получает от системы сервис, а в свою очередь, обеспечивает для системы поток управления.

Такой подход делает этот метод особенно полезным для проектирования интерактивных систем.

В методе VORD рассматривается два типа перспектив - прямые и косвенные:.

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

• Перспективы (точки зрения), которые являются косвенными, не взаимодействуют с системой напрямую, но, тем не менее, «имеют свой интерес» как минимум в одном из сервисов, предоставляемых системой.

Косвенных перспектив может быть великое множество.

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

Метод предусматривает три основных неоднократно применяемых шага:.

• определение перспектив и их структуры;.

• документирование перспектив;.

• разработка требований и их детализация на основе перспектив.

На рис. 3.20 показана графическая нотация, используемая этим методом.

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

Рис. 3.20 Графическая нотация для моделирования перспектив.

Использование метода предполагает последовательное рассмотрение и выделение (идентификацию) необходимых перспектив. Вначале предлагается рассматривать общий набор абстрактных перспектив (см. рис. 3.21), который можно считать стартовой точкой в процессе идентификации (по соглашению принятому в VORD, прямые перспективы обозначаются белыми прямоугольниками, косвенные - серыми). Затем этот набор сокращается удалением ненужных перспектив, которые не являются существенными с точки зрения рассматриваемой проблемы. А уж далее определяются все заинтересованные лица и перспективы, относящиеся к другим системам, взаимодействующим с проектируемой, а также все непосредственные пользователи системы. И, в конце концов, для каждой из идентифицированных косвенных перспектив определяется, с чем они могут быть связаны (ассоциированы).

Рис. 3.21 Классы перспектив.

На рис. 3.22 представлены перспективы для системы автоматической оплаты парковки.

Рис. 3.22 Перспективы для системы автоматической оплаты парковки.

Как видно из рисунка, «Пользователь, расплачивающийся наличными», и «Пользователь, расплачивающийся кредитной картой», являются детализациями перспективы «Клиент парковки»; а «Кассир» и «Управляющий парковки» являются детализациями перспективы «Служащий парковки». Перспектива «Система печати квитанций» представляет собой базу данных организации, отвечающей за прием оплаты и представление квитанций. «База данных кредитных карт» является внешней перспективой и представляет систему, хранящую информацию о кредитных картах клиентов.

Следующим шагом метода VORD является документирование требований для каждой из перспектив. В качестве примера того, как это делается, в таблице 3.3 приведены начальные требования для перспективы «Клиент парковки».

Таблица 3.3 Требования для точки зрения клиента автомобильной парковки.

В таблице в графе тип требований аббревиатура sv обозначает сервис (service), а nf обозначает нефункциональное требование (non-functional requirement). Как упоминалось ранее, каждая из перспектив может иметь свойства, которые определяют характеристики перспективы с точки зрения проблемной области. Эти свойства являются важными, поскольку обеспечивают дополнительную информацию о среде, в которой должна функционировать разрабатываемая система (см. рис. 3.23).

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

Заключительной стадией метода VORD является разработка документа требований в соответствии с промышленными стандартами на основе полученных результатов анализа.

Рис. 3.23 Атрибуты перспектив.