ВСТУПИТЕЛЬНАЯ ЛЕКЦИЯ. ИСТОРИЯ РАЗВИТИЯ. 3 страница

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

Лекция 9. Модели систем

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

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

1. Внешнее представление, когда моделируется окружение или рабочая среда системы.

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

3. Описание структуры системы, когда моделируется системная архитектура или структуры данных, обрабатываемых системой.

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

Однако методы структурного анализа имеют ряд недостатков.

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

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

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

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

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

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

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

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

1. Модель обработки данных. Диаграммы потоков данных показывают последовательность обработки данных в системе.

2. Композиционная модель. Диаграммы «сущность-связь» показывают, как системные сущности составляются из других сущностей.

3. Архитектурная модель. Эти модели показывают основные подсистемы, из которых строится система.

4. Классификационная модель. Диаграммы наследования классов показывают, какие объекты имеют общие характеристики.

5. Модель «стимул-ответ». Диаграммы изменения состояний показывают, как система реагирует на внутренние и внешние события.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На рис. 9.5 показана модель конечного автомата (диаграмма состояний) простой микроволновой печи, оборудованной кнопками включения питания, таймера и запуска системы.

Реальная микроволновая печь на самом деле намного сложнее описанной здесь системы. Вместе с тем эта модель показывает все основные средства системы. Для упрощения модели предполагается такую последовательность действий при использовании печи.

1. Выбор уровня мощности (половинная или полная).

2. Ввод времени работы печи.

3. Нажатие кнопки запуска, после чего печь работает заданное время.

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

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

Рис. 9.5. Диаграмма состояний автомата микроволновой печи

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

Нотации UML позволяют определять действия, которые выполняются в том или ином состоянии. Но для создания системной спецификации необходима более детальная информация о состояниях и стимулах системы (табл. 9.1, 9.2). Эта информация может храниться в словаре данных.

Таблица 9.1. Описание состояний микроволновой печи

Таблица 9.2. Описание стимулов микроволновой печи

Основная проблема метода конечного автомата состоит в том, что число возможных состояний может быть очень велико. Поэтому для моделей больших систем необходима структуризация возможных состояний системы. Один из способов структуризации состоит в использовании суперсостояний, которые объединяют ряд отдельных состояний. Такое суперсостояние подобно одному состоянию модели высокого уровня, которое детализируется на отдельной диаграмме. Для иллюстрации этого понятия рассмотрим состояние «Работа» модели микроволновой печи (см. рис. 9.5). Это суперсостояние более детально показано на рис. 9.6.

Состояние «Работа» включает ряд подсостояний. Диаграмма на рис. 9.6 показывает, что в состоянии «Работа» сначала проверяется готовность печи к работе и, если обнаружены какие-либо проблемы, включается аварийная сигнализация и печь выключается. В состоянии «Нагрев» работает микроволновой генератор в течение указанного времени, по завершении его работы автоматически подается звуковой сигнал. Если во время работы печи будет открыта дверь, система переходит в состояние «Выключено», как показано на рис. 9.5.

Рис. 9.6. Работа микроволновой печи

Лекция 10. Модели систем (продолжение)

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

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

Наиболее широко используемой методологией моделирования данных является моделирование типа «сущность-связь-атрибут», которое показывает структуру данных, их атрибуты и отношения между ними[8]. Этот метод моделирования был предложен в середине 1970-х годов Ченом (Chen); с тех пор разработано несколько вариантов этого метода.

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

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

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

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

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

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

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

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

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

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

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

В примере словаря данных, приведенном в табл. 10.1, представлены имена, взятые из модели данных системы проектирования (см. рис. 10.1). Это упрощенный пример, где опущены некоторые имена и сокращена соответствующая информация.

Таблица 10.1. Пример словаря данных

10.2. Объектные модели

Объектно-ориентированный подход широко используется при разработке программного обеспечения, особенно для разработки интерактивных систем. В этом случае системные требования формируются на основе объектной модели, а программирование выполняется с помощью объектно-ориентированных языков, таких, как Java или C++.

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

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

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

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

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

Идентификация объектов и классов объектов считается наиболее сложной задачей в процессе объектно-ориентированной разработки систем. Определение объектов — это основа для анализа и проектирования системы. Здесь рассматриваются лишь некоторые объектные модели, полезные для анализа систем.

Различные методы объектно-ориентированного анализа были предложены в 1990-х годах Бучем (Booch), Кодом и Джордоном (Coad and Yourdon), а также Рамбо (Rumbaugh). Эти методы имели много общего, поэтому три главных разработчика— Буч, Рамбо и Якобсон (Jacobson) — решили интегрировать их для разработки унифицированного метода. В результате разработанный ими унифицированный язык моделирования (Unified Modeling Language — UML) стал фактическим стандартом для моделирования объектов. UML предлагает нотации для различных типов системных моделей.

В UML класс объектов представлен вертикально ориентированным прямоугольником с тремя секциями (рис. 10.2).

1. В верхней секции располагается имя класса.

2. Атрибуты класса находятся в средней секции.