Планирование управления требованиями
Планирование является первым этапом процесса управления требованиями. Управление требованиями очень дорого, и для каждого проекта на стадии планирования устанавливается необходимый уровень детализации управления требованиями. В процессе управления нужно отслеживать ряд вопросов, касающихся разработки требований.
1. Идентификация требований. Каждое требование должно быть однозначно определено, поскольку оно может пересекаться с другими требованиями. Пересечение требований можно обнаружить с помощью оперативного контроля.
2. Управление процессом внесения изменений. Это ряд операций, которые оценивают воздействие на систему вносимых изменений, а также стоимость изменений. Более подробно этот вопрос рассматривается в следующем разделе.
3. Стратегия оперативного контроля. Определяет отношения между требованиями, а также между требованиями и проектированием системы.
4. Поддержка CASEсредств. Управление требованиями предполагает обработку большого объема информации о требованиях. В этом процессе могут использоваться разнообразные инструментальные средства, например электронные таблицы или простые системы баз данных.
Существует много взаимозависимостей между требованиями, а также между требованиями и структурой системы. Кроме того, существует связь между требованиями и причинами, по которым эти требования были предложены. Если необходимо внести в требования изменения, в процессе управления нужно проследить влияние этих изменений на другие требования и саму систему. Оперативный контроль позволяет обнаружить связанные требования и отследить влияние одних требований на другие.
Существует три типа информации, используемой в оперативном контроле.
1. Информация, об источнике требования связывает требование с лицами, которые предложили эти требования, и с логическим обоснованием этих требований. Если предложено изменение в требованиях, эта информация используется для определения лиц, которые могут обосновать эти изменения.
2. Информация о требованиях связывает требования внутри спецификации. Эта информация используется для оценки количества требований, которые затрагивают предложенные изменения.
3. Информация о структуре системы связывает требования с системными модулями, которые реализуют требования. Эта информация используется для оценки влияния предложенных изменений на систему и ее реализацию.
Управление изменениями требований
Управление изменениями требований (см. рис. 6.15) должно применяться ко всем предложенным изменениям требований. Преимущество использования формального процесса управления изменениями состоит в том, что все предложенные изменения обрабатываются последовательно, при этом можно управлять и отслеживать внесение изменений в системную спецификацию.
Рис. 6.15. Управление изменениями требований Процесс управления изменениями состоит из трех основных этапов.
1. Анализ проблем изменения спецификации. Процесс начинается с определения проблем в требованиях или с прямого предложения внесения изменений. На этой стадии проблема или предложенные изменения анализируются для проверки их обоснованности. Затем могут быть сделаны более определенные предложения относительно изменений в требованиях.
2. Анализ изменений и расчет их стоимости. Эффект от внесения предложенного изменения оценивается с использованием оперативного контроля. Стоимость изменений оценивается двумя показателями: стоимостью внесения изменения в спецификацию и стоимостью внесения изменений в структуру системы и непосредственно в программный код. По окончании этого этапа принимается решение, продолжать или нет внесение изменений в систему.
3. Реализация изменений. Реализация изменений в системной спецификации, структуре системы и программном коде.
Если требуется срочно внести изменения в требования, всегда существует соблазн сделать сначала изменения в системе, а затем задним числом изменить спецификацию. Это почти неизбежно приводит к тому, что готовая система не будет согласована с требованиями.
Литература:
Ларман, Крэг. Применение UML и шаблонов проектирования.: Пер. с англ..: Уч. Пос. – М.: Издательский дом «Вильямс», 2001. – 496 с.: ил. – Парал. Тит. Англ..
Соммервилл, Иан. Инженерия програмного обеспечения, 6-е издание.: Пер. с англ.. – М.: Издательский дом «Вильямс» 2002. – 624 с.: ил. – Парал. Тит. Анг.
Ф.Брукс. Мифический человеко-месяц или как создаются программные системы. – пер. с англ. – СПб.: Символ-Плюс, 2001.-304 с.: ил.
Лекция 5.
Моделирование программных систем. Прототипирование. Спецификации программных систем и архитектурное проектирование
План
Модели систем
Типы системных моделей при анализе систем.
Модели системного окружения
Поведенческие модели
Модели потоков данных
Модели конечных автоматов
Модели данных
Объектные модели
Модели наследования
Агрегирование объектов
Моделирование поведения объектов
Цели и задачи прототипирования
Модель процесса разработки прототипа
Прототипирование в процессе разработки ПО
Эволюционное прототипирование
Экспериментальное прототипирование
Технологии быстрого прототипирования
Применение динамических языков высокого уровня
Сборка приложений с повторным использованием компонентов
Прототипирование пользовательских интерфейсов
Формальные спецификации ПО
Формальные спецификации в процессе разработки ПО
Специфицирование интерфейсов
Спецификация поведения систем
Структурирование системы
Модель репозитория
Модель клиент/сервер
Модель абстрактной машины
Модели управления
Централизованное управление
Системы, управляемые событиями
Модульная декомпозиция
Объектные модели
Модели потоков данных
Проблемно-зависимые архитектуры
Модели классов систем
Базовые архитектуры
Модели систем
Пользовательские требования обычно пишутся на естественном языке, поскольку они должны быть понятны даже не специалистам в области разработки ПО. Однако более детализированные системные требования должны описываться более "техническим" способом. Одной из широко используемых методик документирования системных требований является построение ряда моделей системы. Эти модели используют графические представления, показывающие решение как исходной задачи, для которой создается система, так и разрабатываемой системы. Как правило, графические представления более понятны, чем детальное описание системных требований на естественном языке. Модели являются связующим звеном между процессом анализа исходной задачи и процессом проектирования системы.
Модели можно использовать в процессе анализа существующей системы, которую нужно или заменить, или модифицировать, а также для формирования системных требований. Модели могут представить систему в различных аспектах.
Внешнее представление, когда моделируется окружение или рабочая среда системы.
Описание поведения системы, когда моделируется ее поведение.
Описание структуры системы, когда моделируется системная архитектура или структуры данных, обрабатываемых системой.
Эти три типа представления систем раскрыты в данной главе; кроме того, здесь рассматривается объектное моделирование, которое до некоторой степени объединяет поведенческое и структурное моделирование.
Такие структурные методы, как структурный анализ систем и объектно-ориентированный анализ, обеспечивают основу для детального моделирования системы как части процесса постановки и анализа требований. Большинство структурных методов работают с определенными типами системных моделей. Эти методы обычно определяют процесс, который используются для построения моделей, и набор правил, которые применяются к этим моделям. Для поддержки структурных методов существуют различные CASE-средства, включающие редакторы моделей, автоматизированную систему документирования и инструменты проверки моделей.
Однако методы структурного анализа имеют ряд недостатков.
Они не обеспечивают эффективной поддержки формирования нефункциональных системных требований.
Обычно руководства по этим методам не содержат советов, которые помогали бы пользователям решить, подходит ли данный метод для решения конкретной задачи.
В результате применения этих методов часто получается объемная документация, при этом суть системных требований скрывается за массой несущественных деталей.
Построенные модели очень детализированы и трудны для понимания. Обычные пользователи не могут реально проверить действенность этих моделей.
Практическая разработка требований не должна ограничиваться только моделями, построенными с помощью тех или иных методов. Например, объектно-ориентированные методы обычно не предполагают применения для разработки моделей потоков данных. Однако, исходя из моего опыта, такие модели полезны для объектно-ориентированного анализа, поскольку отражают понимание системы конечным пользователем и могут помочь идентифицировать объекты и действия с ними.
Наиболее важным аспектом системного моделирования является то, что оно опускает детали. Модель является абстракцией системы и легче поддается анализу, чем любое другое представление этой системы. В идеале представление системы должно сохранять всю информацию относительно представляемого объекта. Абстракция является упрощением и определяется выбором наиболее важных характеристик системы.
Различные типы системных моделей основаны на разных подходах к абстракции. Например, модель потоков данных концентрирует внимание на прохождении данных через систему и на функциональных преобразованиях этих данных. Модель оставляет без внимания структуру данных. И наоборот, модель "сущность-связь" предполагает документирование системных данных и их взаимосвязь, не касаясь системных функций.
Типы системных моделей при анализе систем.
Приведем типы системных моделей, которые могут создаваться в процессе анализа систем.
Модель обработки данных. Диаграммы потоков данных показывают последовательность обработки данных в системе.
Композиционная модель. Диаграммы "сущность-связь" показывают, как системные сущности составляются из других сущностей.
Архитектурная модель. Эти модели показывают основные подсистемы, из которых строится система.
Классификационная модель. Диаграммы наследования классов показывают, какие объекты имеют общие характеристики.
Модель "стимулответ". Диаграммы изменения состояний показывают, как система реагирует на внутренние и внешние события.
Эти типы моделей описаны далее в главе. Везде, где возможно, я использую обозначения унифицированного языка моделирования UML, который является стандартом языка моделирования, особенно для объектно-ориентированного моделирования. В тех случаях, когда UML не предусматривает подходящих нотаций, для описания моделей я использую простые интуитивные обозначения.
Модели системного окружения
На ранних этапах формирования требований необходимо определить границы системы. Этот этап предполагает работу с лицами, участвующими в формировании требований, для того чтобы разграничить систему и ее рабочее окружение. В некоторых случаях границы между системой и ее окружением относительно ясны. Например, когда новая система заменяет существующую, ее рабочее окружение обычно совпадает с окружением существующей системы.
В других случаях необходим дополнительный анализ. Например, рабочее окружение разрабатываемого набора CASE-средств может включать существующую базу данных, сервисы которой используются системой, но набор средств может также иметь внутреннюю базу данных. Если база данных уже существует, определение границ между ними может оказаться сложной технической и управленческой проблемой. Только после проведения дополнительного анализа можно будет принять решение о том, что является, а что не является частью разрабатываемой системы.
На определение системного окружения могут также влиять социальные и организационные ограничения, т.е. граница системы может определяться не только техническими факторами. Например, система может быть очерчена так, что при ее разработке не будет необходимости консультироваться с менеджерами; при другом определении границ может возрасти ее стоимость или возникнет необходимость расширить отдел разработки и т.п.
После определения границ между системой и ее окружением далее специфицируется само рабочее окружение и связи между ним и системой. Обычно на этом этапе строится простая структурная модель, подобная представленной на рис. 7.1 модели структуры окружения информационной системы, управляющей сетью банкоматов. Структурные модели высокого уровня обычно являются простыми блок-схемами, где каждая подсистема представлена именованным прямоугольником, а линии показывают, что существуют некоторые связи между подсистемами.
Структурные модели описывают непосредственное рабочее окружение системы. Но они не показывают связи между другими системами в окружающей среде, которые не соединены непосредственно с разрабатываемой системой, но могут на нее влиять. Например, внешние системы могут производить данные для системы или использовать данные, произведенные системой. При этом они могут быть соединены между собой и системой через сеть или не соединены вообще. Они могут физически соприкасаться или располагаться в разных зданиях. Все эти взаимоотношения могут влиять на требования к разрабатываемой системе и должны быть приняты во внимание.
Таким образом, простые структурные модели обычно дополняются моделями других типов, например моделями процессов, которые показывают взаимодействия в системе, или моделями потоков данных (описаны в следующем разделе), которые показывают последовательность обработки и перемещения данных внутри системы и между другими системами в окружающей среде.
Поведенческие модели
Эти модели используются для описания общего поведения системы. Здесь рассматривается два типа поведенческих моделей — модель потоков данных, которая представляет обработку данных в системе, и модель конечного автомата, которая показывает реакцию системы на события. Эти модели можно использовать отдельно или совместно, в зависимости от типа разрабатываемой системы.
Большинство бизнес-систем прежде всего управляют данными. Они также управляют вводом данных в систему и сравнительно мало занимаются обработкой внешних событий. Для таких систем модель потоков данных может содержать все, что необходимо для описания поведения системы. В противоположность им системы реального времени управляют событиями с минимальной обработкой данных. Модель конечного автомата (обсуждаемая в разделе 7.2.2) является наиболее эффективным способом описания их поведение. Другие классы систем управляют как данными, так и событиями, поэтому для их представления необходимы оба типа моделей.
Модели потоков данных
Модели потока данных — это интуитивно понятный способ показа последовательности обработки данных внутри системы. Нотации, используемые в этих моделях, описывают обработку данных с помощью системных функций, а также хранение и перемещения данных между системными функциями. Модели потоков данных стали широко использоваться после публикации книги о структурном системном анализе [91]. На базе этого фундаментального исследования было разработано множество методов анализа систем.
Модели потоков данных используются для показа последовательности шагов обработки данных. Эти шаги обработки или преобразования данных выполняются программными функциями. В сущности, диаграммы потоков данных используются для документирования программных функций перед проектированием системы. Анализ модели обработки данных может быть выполнен специалистами вручную или с помощью компьютера.
В диаграммах потоков данных используются следующие обозначения: закругленные прямоугольники соответствуют этапам обработки данных; стрелки, снабженные примечаниями с названием данных, представляют потоки данных; прямоугольники соответствуют хранилищам или источникам данных.
Модели потоков данных ценны тем, что они прослеживают и документируют перемещение данных по системе, помогая тем самым аналитикам понять этот процесс. Преимущество диаграмм потоков данных в том, что они, в отличие от других моделей, просты и интуитивно понятны. Поэтому их можно объяснить потенциальным пользователям системы, которые затем могут участвовать в ее анализе.
Модели конечных автоматов
Модели конечных автоматов используются для моделирования поведения системы, реагирующей на внутренние или внешние события. Такая модель показывает состояние системы и события, которые служат причиной перехода системы из одного состояния в другое. Модель не показывает поток данных внутри системы. Этот тип модели особенно полезен для моделирования систем реального времени, поскольку этими системами обычно управляют входные сигналы, приходящие из окружения системы.
Модели конечных автоматов являются неотъемлемой частью методов проектирования систем реального времени. В работе определены диаграммы состояний, которые стали основой системы нотаций в языке моделирования UML.
Модель конечного автомата системы предполагает, что в любое время система находится в одном из возможных состояний. При получении входного сигнала или стимула система может изменить свое состояние. Например, система, управляющая клапаном, при получении команды оператора (стимул) может перейти из состояния "Клапан открыт" к состоянию "Клапан закрыт".
Нотации UML позволяют определять действия, которые выполняются в том или ином состоянии. Но для создания системной спецификации необходима более детальная информация о стимулах и состояниях системы . Эта информация может храниться в словаре данных, как будет показано далее
Модели данных
Многие большие программные системы используют информационные базы данных. В одних случаях эта база данных существует независимо от программной системы, в других — специально создается для разрабатываемой системы. Важной частью моделирования систем является определение логической формы данных, обрабатываемых системой.
Наиболее широко используемой методологией моделирования данных является моделирование типа "сущность-связь-атрибут", которое показывает структуру данных, их атрибуты и отношения между ними. Этот метод моделирования был предложен в середине 1970х годов Ченом; с тех пор разработано несколько вариантов этого метода.
Язык моделирования UML не имеет определенных обозначений для этого типа моделей данных, что желательно для объектно-ориентированного процесса разработки ПО, где для описания систем используются объекты и их отношения. Если сущностям поставить в соответствие простейшие классы объектов (без ассоциированных методов), тогда в качестве моделей данных можно использовать модели классов UML совместно с именованными ассоциациями между классами. Хотя такие модели данных не могут служить примером "хорошего" языка моделирования, удобство использования стандартных обозначений UML перевешивает возможные несовершенства таких конструкций.
Для описания структуры обрабатываемой информации модели данных часто используются совместно с моделями потоков данных.
Проекты структуры ПО представляются ориентированными графами. Они состоят из набора узлов различных типов, соединенных дугами, отображающими связи между структурными узлами. В системе проектирования присутствуют средства вывода на дисплей этого графа (т.е. структурной диаграммы) и его преобразования к виду, удобному для хранения в базе данных проектов. Система редактирования выполняет преобразования структурной диаграммы из формата базы данных в формат, позволяющий отобразить ее на экране монитора в виде блок-схемы. Информация, предоставляемая редактором другим средствам анализа проекта, должна включить логическое представление графа проекта. Конечно, эти средства "не интересуются" деталями физического представления растрового изображения графа. Они работают с объектами, их логическими атрибутами и связями между ними.
Объектные модели
Объектно-ориентированный подход широко используется при разработке программного обеспечения, особенно для разработки интерактивных систем. В этом случае системные требования формируются на основе объектной модели, а программирование выполняется с помощью объектно-ориентированных языков, таких, как Java или C++.
Объектные модели, разработанные для формирования требований, могут использоваться как для представления данных, так и для процессов их обработки. В этом отношении они объединяют модели потоков данных и семантические модели данных. Они также полезны для классификации системных сущностей и могут представлять сущности, состоящие из других сущностей.
Для некоторых классов систем объектные модели — естественный способ отображения реально существующих объектов, которые находятся под управлением системы. Например, для систем, обрабатывающих информацию относительно конкретных объектов (таких, как автомобили, самолеты, книги и т.д.), которые имеют четко определенные атрибуты. Более абстрактные высокоуровневые сущности, например библиотеки, медицинские регистрирующие системы или текстовые редакторы, труднее моделировать в виде классов объектов, поскольку они имеют достаточно сложный интерфейс, состоящий из независимых атрибутов и методов.
Объектные модели, разработанные во время анализа требований, несомненно, упрощают переход к объектно-ориентированному проектированию и программированию. Однако конечные пользователи часто считают объектные модели неестественными и трудными для понимания. Часто они предпочитают функциональные представления процессов обработки данных. Поэтому полезно дополнить их моделями потоков данных, чтобы показать сквозную обработку данных в системе.
Класс объектов — это абстракция множества объектов, которые определяются общими атрибутами (как в семантической модели данных) и сервисами или операциями, которые обеспечиваются каждым объектом. Объекты — это исполняемые сущности с атрибутами и сервисами класса объектов. Объекты представляют собой реализацию класса, на основе одного класса можно создать много различных объектов. Обычно при разработке объектных моделей основное внимание сосредоточено на классах объектов и их отношениях.
Модели систем, разрабатываемые при формировании требований, должны отображать реальные сущности, принадлежащие классам объектов. Классы не должны содержать информацию об отдельных системных объектах. Можно разработать различные типы объектных моделей, показывающие, как классы связаны друг с другом, как объекты агрегируются из других объектов, как объекты взаимодействуют с другими объектами и т.д. Эти модели расширяют понимание разрабатываемой системы.
Модели наследования
Важным этапом объектно-ориентированного моделирования является определение классов объектов, которые затем систематизируются. Это подразумевает создание схемы классификации, которая показывает, как классы объектов связаны друг с другом посредством общих атрибутов и сервисов.
Схема классификации организована в виде иерархии наследования, на вершине которой представлены наиболее общие классы объектов. Более специализированные объекты наследуют их атрибуты и сервисы. Эти объекты могут иметь собственные атрибуты и сервисы.
Основной проблемой множественного наследования является разработка такой схемы, где объекты не наследуют ненужные атрибуты. Другая проблема — сложность реорганизации схемы наследования при разрешении конфликта, когда несколько родительских классов имеют атрибуты с одним и тем же именем, но разными значениями. На уровне системного моделирования такие проблемы решаются относительно просто — путем изменения объектной модели вручную. Эти проблемы служат причиной многих ошибок в объектно-ориентированном программировании.
Агрегирование объектов
Подобно тому как одни объекты получают атрибуты и сервисы посредством связей от других объектов, другие объекты могут создаваться из нескольких объектов. Иными словами, объект агрегируется из совокупности других объектов. Классы, представляющие такие объекты, можно смоделировать, используя модель агрегирования объектов, подобную показанной на рис. 7.11 В этом примере смоделирован библиотечный элемент, который является пакетом учебных материалов университетского курса. Этот пакет содержит записи лекций, упражнения, примеры решений, копии диапозитивов, используемых на лекциях, видеозаписи.
Рис. 7.11. Модель агрегирования объектов
В UML для показа агрегирования объектов используется связь с окончанием ромбовидной формы. Вот как можно прочитать рис. 7.11: "Учебный пакет, составленный из нескольких заданий, пакета слайдов, записей лекций и видеозаписей".
Моделирование поведения объектов
Модели поведения объектов показывают операции, выполняемые объектами. В UML поведение объектов моделируется посредством сценариев, которые основаны на вариантах использования, рассмотренных в главе 6, где приведен пример моделирования поведения, показывающий последовательность управления библиотечным каталогом (см. рис. 6.11). Кроме диаграмм последовательностей в UML предусмотрены также кооперативные диаграммы (collaboration diagrams), показывающие последовательность сообщений, которыми обмениваются объекты. Они подобны диаграммам последовательностей, и здесь я на них не останавливаюсь.
Я покажу диаграммы последовательностей в качестве модели поведения пользователя при получении библиотечного элемента в электронном виде. Например, пакет учебных материалов (см. рис. 7.11) может храниться в электронном виде и загружаться на компьютер студента.
На рис. 7.12 показана диаграмма последовательностей, в верхней части которой расположены объекты. Операции обозначаются помеченными стрелками, а последовательность операций читается сверху вниз. В этом сценарии библиотечный пользователь сначала обращается к электронному каталогу, чтобы увидеть, доступен ли нужный элемент, и, если доступен, запрашивает его. Для соблюдения авторских прав пользователь должен подтвердить свое согласие с лицензией на запрашиваемый материал, если, конечно, это предусмотрено правилами пользования данным материалом. Затем выбранный элемент пересылается на сетевой сервер для сжатия, после чего отсылается библиотечному пользователю.
Рис. 7.12. Выдача электронных библиотечных элементов
.
Цели и задачи прототипирования
Заказчикам программного обеспечения и конечным пользователям обычно сложно четко сформулировать требования к разрабатываемой программной системе. Трудно предвидеть, как система будет влиять на трудовой процесс, как она будет взаимодействовать с другими системами и какие операции, выполняемые пользователями, необходимо автоматизировать. Тщательный анализ требований помогает уменьшить неопределенность относительно того, что система должна делать. Однако реально проверить требования, прежде чем их утвердить, практически невозможно. В этой ситуации может помочь прототип системы.
Прототип является начальной версией программной системы, которая используется для демонстрации концепций, заложенных в системе, проверки вариантов требований, а также поиска проблем, которые могут возникнуть как в ходе разработки, так и при эксплуатации системы, и возможных вариантов их решения. Очень важна быстрая разработка прототипа системы, чтобы пользователи могли начать экспериментировать с ним как можно раньше.
Прототип ПО помогает на двух этапах процесса разработки системных требований.
Постановка требований. Пользователи могут экспериментировать с системными прототипами, что позволяет им проверять, как будет работать система. Пользователи получают новые идеи для постановки требований, могут определить сильные и слабые стороны ПО. В результате могут сформироваться новые требования.
Проверка требований. Прототип позволяет обнаружить ошибки и упущения в ранее принятых требованиях. Например, системные функции, определенные в требованиях, могут быть полезными и нужными (с точки зрения пользователя). Однако в процессе применения этих функций совместно с другими функциями пользователи могут изменить первоначальное мнение о них. В результате требования к системе изменятся, отражая измененное понимание пользователями системных функций.
Модель процесса разработки прототипа
Модель процесса разработки прототипа показана на рис. 8.1. На первом этапе данного процесса определяются назначение прототипа и цель прототипирования. Целью может быть разработка макета пользовательского интерфейса, проверка функциональных системных требований или демонстрация реализуемости системы для руководства. Один и тот же прототип не может служить одновременно всем целям. Если цели определены неточно, функции прототипа могут быть восприняты неверно.
Рис. 8.1. Процесс разработки прототипа
На следующем этапе процесса разработки прототипа определяются его функциональные возможности, т.е. принимается решение о том, какие свойства системы должен отражать прототип, а какие (что, возможно, более важно) — нет. Для уменьшения затрат на создание прототипа можно исключить некоторые системные функции. Например, можно ослабить временные характеристики и требования к использованию памяти. Средства управления и обработки ошибок могут игнорироваться либо быть элементарными, если, конечно, целью прототипирования не является модель интерфейса пользователя. Также могут быть снижены требования к надежности и качеству программ.
Заключительный этап процесса прототипирования — оценивание созданного прототипа. В работе [178] утверждается, что это наиболее важный этап процесса прототипирования. Здесь проверяется, насколько созданный прототип соответствует своему назначению и целям, а также на его основе создается план мероприятий по совершенствованию разрабатываемой системы.
Прототипирование в процессе разработки ПО
Как уже отмечалось, конечным пользователям трудно представить, как они будут использовать новую систему ПО в повседневной работе. Если система большая и сложная, то это невозможно сделать, прежде чем система будет создана и введена в эксплуатацию.
Один из способов преодоления этой трудности состоит в использовании эволюционного метода разработки систем. Это означает, что пользователю предоставляется незавершенная система, которая затем изменяется и дополняется до тех пор, пока не станут ясны все требования пользователя. В качестве альтернативы можно построить "экспериментальный" прототип, который поможет проанализировать и проверить требования. После этого создается система. На рис. 8.2 показаны оба подхода к использованию прототипов.
Рис. 8.2. Эволюционное и экспериментальное Прототипирование
Эволюционное прототипирование начинается с построения относительно простой системы, которая реализует наиболее важные требования пользователя. По мере выявления новых требований прототип изменяется и дополняется. В конечном счете он становится той системой, которая требуется. В этом процессе не используется детальная системная спецификация, во многих случаях нет даже формального документа с системными требованиями. В настоящее время эволюционное Прототипирование является обычной технологией разработки программных систем, которая широко используется при разработке Web-узлов и приложений электронной коммерции.
В противоположность эволюционному подходу метод экспериментального прототипирования предназначен для разработки и уточнения системной спецификации. Прототип создается, оценивается и модифицируется. Данные оценивания прототипа используются для дальнейшей детализации спецификации. Когда системные требования сформированы, прототип больше не нужен.
Эволюционное прототипирование
В основе эволюционного прототипирования лежит идея разработки первоначальной версии системы, демонстрации ее пользователям и последующей модификации вплоть до получения системы, отвечающей всем требованиям (рис. 8.3). Такой подход сначала использовался для разработки систем, которые трудно или невозможно специфицировать (например, систем искусственного интеллекта). В настоящее время он становится основной методикой при разработке программных систем. Эволюционное прототипирование имеет много общего с методами быстрой разработки приложений и часто входит в эти методы как их составная часть.
Рис. 8.3. Эволюционное прототипирование Этот метод прототипирования имеет два основных преимущества.
1. Ускорение разработки системы. Как указывалось во введении, современные темпы изменений в деловой сфере требуют быстрых изменений программного обеспечения. В некоторых случаях быстрая поставка ПО, удобство и простота его использования более важны, чем полный спектр функциональных возможностей системы или долгосрочные возможности ее сопровождения.
2. Взаимодействие пользователя с системой. Участие пользователей в процессе разработки означает, что в системе более полно будут учтены пользовательские требования.
Между отдельными методами быстрой разработки ПО существуют различия, но все они имеют некоторые общие свойства.
Этапы разработки технических требований, проектирования и реализации перемежаются. Не существует детальной системной спецификации, проектная документация обычно зависит от инструментальных средств, используемых для реализации системы. Пользовательские требования определяют только наиболее важные характеристики системы.
Система разрабатывается пошагово. Применение методов быстрой разработки систем. Они могут использовать инструментальные CASE-средства и языки четвертого поколения.
Пользовательский интерфейс системы обычно создается с использованием интерактивных систем разработки (см. раздел 8.3), которые позволяют быстро спроектировать и создать интерфейс.
Эволюционное прототипирование и методы, основанные на использовании детальной системной спецификации, отличаются подходами к верификации и аттестации систем. Верификация — процесс проверки системы на соответствие спецификации. Поскольку для прототипа не создается подробной спецификации, его верификация невозможна.
Аттестация системы должна показать, что программа соответствует тем целям, для которых она создавалась. Аттестацию также трудно провести без детальной спецификации, поскольку нет четких формулировок целей. Конечные пользователи, участвующие в процессе разработки, могут быть удовлетворены системой, в то время как другие пользователи — неудовлетворенны, поскольку система не полностью соответствует тем целям, которые они неявно перед ней поставили.
Верификацию и аттестацию системы, разработанной с использованием эволюционного прототипирования, можно осуществить, если она в достаточной степени соответствует поставленной цели и своему назначению. Это соответствие, конечно, нельзя измерить, можно сделать лишь субъективные оценки. Такой подход, как будет показано ниже, может породить проблемы, если программная система создается сторонними организациями-разработчиками.
Экспериментальное прототипирование
Модель процесса разработки ПО, основанная на экспериментальном прототипирова-нии, показана на рис. 8.5. В этой модели расширен этап анализа требований в целях уменьшения общих затрат на разработку. Основное назначение прототипа— сделать понятными требования и предоставить дополнительную информацию для оценки рисков. После этого прототип больше не используется и не участвует в дальнейшем процессе разработки системы.
Рис. 8.5. Разработка ПО с использованием экспериментальных прототипов
Этот метод прототипирования обычно используется для разработки аппаратных систем. Прежде чем будет начата дорогостоящая разработка системы, создается макет (прототип), который используется для проверки структуры системы. Электронный макет системы создается с использованием готовых компонентов, что позволяет разработать версию системы до того, как будут вложены денежные средства в разработку специализированных интегральных схем.
Экспериментальный прототип программных систем обычно не используется для проверки архитектуры системы, он помогает разработать системные требования. Прототип часто совершенно не похож на конечную систему. Система разрабатывается по возможности быстро, поэтому для ускорения формирования требований используется упрощенный прототип системы. В экспериментальный прототип закладываются только обязательные системные функции, стандарты качества для прототипа могут быть снижены, критерии эффективности игнорируются. Язык программирования прототипа часто отличается от языка программирования, на котором будет создаваться окончательный вариант системы.
Технологии быстрого прототипирования
Эти технологии рассчитаны главным образом на обеспечение быстрой разработки прототипов, а не на такие их системные характеристики, как производительность, удобство эксплуатации или безотказность. Существует три основных метода быстрой разработки прототипов.
Разработка с применением динамических языков высокого уровня.
Использование языков программирования баз данных.
Сборка приложений с повторным использованием компонентов.
Для удобства эти методы описаны в отдельных разделах. Но на практике они часто совместно используются при разработке прототипов систем. Например, язык программирования баз данных может применяться для извлечения данных с их последующей обработкой с помощью повторно используемых компонентов. Интерфейс пользователя системы можно разработать, используя визуальное программирование. В статье описано смешанное применение этих методов при создании прототипа управляющей системы.
В настоящее время разработка прототипов обычно опирается на набор инструментов, поддерживающих по крайней мере два из этих методов. Например, система Smalltalk VisualWorks поддерживает язык очень высокого уровня и обеспечивает повторное использование компонентов. Пакет Lotus Notes включает поддержку программирования баз данных с помощью языка высокого уровня и повторное использование компонентов, которые могут обеспечить операции над базой данных.
Применение динамических языков высокого уровня
Динамические языки высокого уровня — это языки программирования, которые имеют мощные средства контроля данных во время выполнения программы. Они упрощают разработку программ, так как уменьшают число проблем, связанных с распределением памяти и управлением ею. Такие языки имеют средства, которые обычно должны быть построены из более примитивных конструкций в языках, подобных Ada или С. Примеры языков очень высокого уровня— Lisp (основанный на структурах списков), Prolog (основанный на алгебре логики) и Smalltalk (основанный на объектах).
До недавнего времени динамические языки высокого уровня широко не использовались для разработки больших систем, поскольку они нуждаются в основательных средствах динамической поддержки. Эти средства увеличивали объем необходимой памяти и уменьшали скорость выполнения программ, написанных на этих языках. Однако возрастание мощности и снижение стоимости компьютерного оборудования сделало эти факторы не столь существенными.
Таким образом, для многих деловых приложений эти языки могут заменить такие традиционные языки программирования, как С, COBOL и Ada. Язык Java, несомненно, является основным языком разработки, имеющим корни в языке C++, но с включением многих средств языка Smalltalk наподобие платформенной независимости и автоматического управления памятью. Язык Java объединяет в себе многие преимущества языков высокого уровня, совмещая это с точностью и возможностью оптимизации выполнения, обычно предлагаемой языками третьего поколения. В языке Java много компонентов, доступных для повторного использования, все это делает его подходящим для эволюционного прототипирования.
Сборка приложений с повторным использованием компонентов
Время, необходимое для разработки системы, можно уменьшить, если многие части такой системы будут использованы неоднократно. Для быстрого построения прототипа необходимо иметь набор компонентов, пригодных для повторного использования, и механизм сборки системы из этих компонентов. Этот подход показан на рис. 8.7.
Рис. 8.7. Сборка повторно используемых компонентов
Прототипирование с повторно используемыми компонентами применяется при разработке требований, конечно, если есть подходящие компоненты. Если подходящих компонентов нет, то для реализации некоторых требований будет необходим компромиссный подход. Функциональные возможности доступных компонентов могут не точно соответствовать пользовательским требованиям. Но, с другой стороны, эти требования обычно достаточно гибкие, поэтому во многих случаях возможно создание прототипа.
Прототипирование пользовательских интерфейсов
Графические интерфейсы пользователя в настоящее время являются стандартом для интерактивных систем. Усилия, вкладываемые в определение, проектирование и реализацию такого интерфейса, составляют значительную часть стоимости разработки приложения. Разработчики не должны навязывать пользователям свою точку зрения на проектируемый интерфейс. Пользователи должны принимать активное участие в процессе проектирования интерфейса. Такой взгляд на разработку интерфейса привел к подходу, названному проектированием, ориентированным на пользователя (user-centred design), который основан на прототипировании интерфейса и участии пользователя в процессе его проектирования.
В этом аспекте Прототипирование — необходимая часть процесса проектирования пользовательского интерфейса. Из-за динамической природы пользовательских интерфейсов текстовых описаний и диаграмм недостаточно для формирования требований к интерфейсу. Поэтому эволюционное Прототипирование с участием конечного пользователя — единственный приемлемый способ разработки графического интерфейса для программных систем.
Генераторы интерфейсов— это графические системы проектирования экранных форм, где интерфейсы компонуются из элементов типа меню, полей, пиктограмм и кнопок, которые, в свою очередь, можно просто выбрать из меню и поместить в экранную форму. Как уже упоминалось, системы этого типа — необходимая часть систем программирования баз данных. Миллионы людей сегодня имеют доступ к Web-броузерам. Они поддерживают язык разметки гипертекста HTML, который позволяет создавать пользовательские интерфейсы. Кнопки, поля, формы и таблицы могут быть включены в Web-страницы так же, как и средства мультимедиа. Сценарии обработки событий и данных, связанные с объектами интерфейса, могут выполняться или на машине Web-клиента, или на Web-сервере.
Из-за широких возможностей Web-броузеров и мощности языка HTML в настоящее время все больше пользовательских интерфейсов строятся как Web-ориентированные. Как показано в главе 26, посвященной наследуемым системам, такие интерфейсы — принадлежность не только новых систем; они заменяют интерфейсы, построенные на текстовых формах, в широком круге наследуемых систем.