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

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

Различные типы системных  моделей основаны на разных подходах к абстракции. Например, модель потоков данных концентрирует внимание на прохождении данных через систему и на функциональных преобразованиях этих данных. Модель оставляет без внимания структуру данных. И наоборот, модель "сущность-связь" предполагает документирование системных данных и их взаимосвязь, не касаясь системных функций.

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

1. Модель обработки данных. Диаграммы потоков данных показывают последовательность обработки данных в системе.
2. Композиционная модель. Диаграммы "сущность-связь" показывают, как системные сущности составляются из других сущностей.
3. Архитектурная модель. Эти модели показывают основные подсистемы, из которых строится система.
4. Классификационная модель. Диаграммы наследования классов показывают, какие объекты имеют общие характеристики.
5. Модель "стимул-ответ". Диаграммы изменения состояний показывают, как система реагирует на внутренние и внешние события.

Модели  системного окружения.

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

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

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

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

 

Рис.3. Рабочее окружение системы управления банкоматами.

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

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

Рис.4Модель процесса приобретения оборудования

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

Поведенческие модели

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

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

Модели  потоков данных

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

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

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

Рис.5 Диаграмма потоков данных при обработке бланка заказа

В диаграммах потоков данных используются следующие обозначения (см. рис. 5): закругленные прямоугольники соответствуют этапам обработки данных;

 стрелки, снабженные примечаниями с названием данных, представляют потоки данных;

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

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

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

Модели  конечных автоматов

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

Модели конечных автоматов  являются неотъемлемой частью методов  проектирования систем реального времени..

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

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

Модели  данных

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

Наиболее широко используемой методологией моделирования данных является моделирование типа "сущность-связь-атрибут", которое показывает структуру данных, их атрибуты и отношения между ними. Этот метод моделирования был предложен в середине 1970-х годов Ченом, с тех пор разработано несколько вариантов этого метода.

Язык моделирования UML не имеет определенных обозначений  для этого типа моделей данных, что желательно для объектно-ориентированного процесса разработки ПО, где для описания систем используются объекты и их отношения. Если сущностям поставить в соответствие простейшие классы объектов (без ассоциированных методов), тогда в качестве моделей данных можно использовать модели классов UML совместно с именованными ассоциациями между классами. Хотя такие модели данных не могут служить примером "хорошего" языка моделирования, удобство использования стандартных обозначений UML перевешивает возможные несовершенства таких конструкций.

Для описания структуры обрабатываемой информации модели данных часто используются совместно с моделями потоков данных. На рис. 5 представлена модель данных для системы проектирования ПО. Такую систему можно реализовать на основе комплекса инструментальных CASE-средств.

Рис.6. Модель данных для системы проектирования ПО

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

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

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

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

Перечислим преимущества использования словаря данных:

1. Существует механизм управления именами. При разработке большой системной модели, вероятно, придется изобретать имена для сущностей н связей. Эти имена должны быть уникальными. Программа словаря данных может проверять уникальность имен и сообщать об их дублировании.
2. Словарь может служить хранилищем организационной информации, которая может связать анализ, проектирование, реализацию и модернизацию системы. Вся информация о системных объектах и сущностях находится в одном месте.

 

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