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

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

Рис. 10.2. Часть иерархии классов для библиотечной системы

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

10.2.1. Модели наследования

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

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

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

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

Рис. 10.3. Иерархия классов пользователей

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

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

Рис. 10.4. Множественное наследование

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

10.2.2. Агрегирование объектов

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

Рис. 10.5. Модель агрегирования объектов

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

10.2.3. Моделирование поведения объектов

Модели поведения объектов показывают операции, выполняемые объектами. В UML поведение объектов моделируется посредством сценариев. Кроме диаграмм последовательностей в UMLпредусмотрены также кооперативные диаграммы (collaboration diagrams4), показывающие последовательность сообщений, которыми обмениваются объекты. Они подобны диаграммам последовательностей.

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

На рис. 10.6 показана диаграмма последовательностей, в верхней части которой расположены объекты.

Рис. 10.6. Выдача электронных библиотечных элементов

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

10.3. Инструментальные CASE-средства

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

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

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

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

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

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

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

3. Центральный репозиторий позволяет проектировщику найти нужный проект и соответствующую проектную информацию.

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

5. Средства генерирования отчетов на основе информации из центрального репозитория автоматически генерируют системную документацию.

6. Средства создания форм определяют форматы документов и экранных форм.

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

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

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

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

Лекция 11. Прототипирование программных средств

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

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

Прототип ПО помогает на двух этапах процесса разработки системных требований.

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

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

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

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

Наряду с тем, что прототипы помогают формировать требования, они имеют и другие достоинства.

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

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

3. Работая, хотя и ограниченно, в виде прототипа, система может продемонстрировать свои слабые и сильные стороны.

4. Прототип может служить основой для написания спецификации высококачественной системы. Разработка прототипа обычно ведет к улучшению спецификации системы.

Действующий прототип может также использоваться для других целей.

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

2. Тестирование системы. Прототипы позволяют «прокручивать» тесты. Один и тот же тест запускается на прототипе и на системе. Если получаются одинаковые результаты, это означает, что тест не обнаружил дефектов в системе. Если результаты отличаются, то необходимо исследовать причины различия, что позволяет выявить возможные ошибки в системе.

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

1. Улучшаются эксплуатационные качества системы.

2. Система больше соответствует потребностям пользователей.

3. Системная архитектура становится более совершенной.

4. Сопровождение системы упрощается и становится более удобным.

5. Сокращаются расходы на разработку системы.

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

Модель процесса разработки прототипа показана на рис. 11.1.

Рис. 11.1. Процесс разработки прототипа

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

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

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

11.1. Прототипирование в процессе разработки ПО

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

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

Рис. 11.2. Эволюционное и экспериментальное прототипирование

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

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

Существует различие между целями эволюционного и экспериментального прототипирования.

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

• Целью экспериментального прототипирования является проверка и формирование системных требований. Здесь сначала создается прототип, реализующий те требования, которые сформулированы нечетко и с которыми необходимо «разобраться». Требования, которые сформулированы четко и понятно, не нуждаются в прототипировании.

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

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

11.1.1. Эволюционное прототипирование

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

Этот метод прототипирования имеет два основных преимущества.

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

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

Рис. 11.3. Эволюционное прототипирование

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

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

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

3. Применение методов быстрой разработки систем. Они могут использовать инструментальные CASE-средства и языки четвертого поколения.

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

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

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

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

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

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

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

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

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

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

Рис. 11.4. Пошаговый процесс разработки

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

11.1.2. Экспериментальное прототипирование

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

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

Рис. 11.5. Разработка ПО с использованием экспериментальных прототипов

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