Анализ требований и определение спецификаций программного обеспечения при объектном подходе

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

Таким образом, на этапе анализа ставятся две задачи:

• уточнить требуемое поведение разрабатываемого программного обеспечения,

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

 

6.1. UML - стандартный язык описания разработки программных продуктов с использованием объектного подхода.

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

 

 

Рис. 6. 1. Объектная декомпозиция программы построения таблиц и графиков.

 

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

Конец «войне методов» положило появление в 1995 г первой версии языка UML (Unified Modeling Language - унифицированный язык моделирования), который в настоящее время фактически признан стандартным средством описания проектов, создаваемых с использованием объектно-ориентированного подхода. Его создателями являются ведущие специалисты в этой области Гради Буч, Ивар Якобсон и Джеймс Рамбо, которые использовали в своем языке все лучшее, что появилось в подходах этих авторов во время «войны методов».

 

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

Рис. 6. 2. Полная спецификация разрабатываемого программного обеспечения при объектном подходе (UML).

 

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

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

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

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

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

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

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

• диаграммы вариантов использования;

• диаграммы классов;

• диаграммы пакетов;

• диаграммы последовательностей действий;

• диаграммы кооперации;

• диаграммы деятельности;

• диаграммы состояний объектов;

• диаграммы компонентов;

• диаграммы размещения.

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

Помимо указанных диаграмм, как и при структурном подходе, спецификация обязательно включает словарь терминов, а также различного рода описания и текстовые спецификации. Конкретный набор документации определяется разработчиком. UML и предлагаемая теми же авторами методика Rational Unified Process поддерживаются пакетом Rational Rose фирмы Rational Software Corporation. Ряд диаграмм UML можно построить также средствами программы Microsoft Visual Modeler и других CASE-средств. По данным «USA Today» в настоящее время 49 из 50-ти ведущих компьютерных компаний USA пользуют UML при разработке программного обеспечения с использованием объектного подхода, что и позволяет говорить о том, что сегодня UML фактически стал стандартом описания подобных разработок.

 

6.2. Определение «вариантов использования».

Разработку спецификаций программного обеспечения начинают с анализа требований к функциональности, указанных в техническом задании. В процессе анализа выявляют внешних пользователей разрабатываемого программного обеспечения и перечень отдельных аспектов его поведения в процессе взаимодействия с конкретными пользователями. Аспекты поведения программного обеспечения были названы «вариантами использования» или «прецедентами» (use cases).

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

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

В зависимости от цели выполнения конкретной процедуры различают следующие варианты использования:

• основные - обеспечивают требуемую функциональность разрабатываемого программного обеспечения:

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

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

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

 

Название варианта Цель Действующие лица Краткое описание   Тип варианта

Выполнение задания Получение результатов решения задачи Пользователь Решение задачи предполагает выбор задачи, выбор алгоритма, задание данных и получение результатов решения Основной

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

 

Диаграммы вариантов использования

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

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

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

Связь - взаимодействие действующих лиц и соответствующих вариантов использования.

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

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

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

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

а б в

Рис. 6.3.Основные условные обозначения диаграмм вариантов использования: а - действующее лицо, б - вариант использования; в – связь.

 

Пример:

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

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

 

Рис. 6. 4.Диаграмма вариантов использования системы учета успеваемости студентов.

 

Анализ вариантов использования показывает, что вариант получения сводки успеваемости по факультету «использует» вариант получения сводки по курсу, что и представлено на диаграмме.

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

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

 

6.3. Построение концептуальной модели предметной области.

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

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

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

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

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

Каждую из перечисленных моделей используют на конкретном этапе. Разработки программного обеспечения:

• концептуальную модель - на этапе анализа;

• диаграммы классов уровня спецификации - на этапе проектирования;

• диаграммы классов уровня реализации - на этапе реализации.

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

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

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

а б

Рис. 6.5.Обозначение класса на концептуальной диаграмме классов: а-без уточнения характеристик, б- с уточнением атрибутов.

 

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

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

Отношение ассоциацииозначает наличие связи между экземплярами классов или объектами, например, класс Студент ассоциирован с классом Институт. Ассоциация может иметь имя, например, Обучается. Рядом с именем ассоциации ставят стрелку, указывающую направление чтения имени («Студент обучается в институте», а не наоборот).

Связь между экземплярами классов подразумевает некоторые роли, которые соответствующие объекты играют по отношению друг к другу. Роль связана с направлением ассоциации. Так по отношению к студентам институт - организация, осуществляющая их обучение, т. е. роль института можно назвать Место учебы. Студент для института - объект обучающей деятельности института, т. е. Обучаемый. Если роль собственного имени не имеет, то можно считать, что ее имя совпадает с именем класса, по отношению к которому определяется эта роль. Для рассматриваемого примера это соответственно роли Студент и Институт (рис. 6.6, а),но роль можно указать и явно (рис. 6.6, б).

 

а б в

Рис. 6.6. Обозначение ассоциации: а - с указанием имени ассоциации и ее направления; б - с указанием имен ролей, в - с указанием множественности.

 

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

* - от 0 до бесконечности;

<целое>.. * - от заданного числа до бесконечности;

<целое> - точно определенное количество объектов;

<целое1>, <целое2> - несколько вариантов точного количества объектов;

<целое1>.. <целое2> - диапазон объектов.

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

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

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

 

 

Рис. 6.7.Обозначение обобщения.

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

• формируют множество понятий - кандидатов из существительных, характеризующих предметную область в описании вариантов использования;

• исключают понятия, не существенные для данного варианта использования, например, в предыдущем примере, «информация», «ввод» и т. д.

 

6.4. Описание поведения. Системные события и операции.

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

 

Диаграмма последовательностей системы.

Системные события и операции.

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

Для построения диаграммы последовательностей системы необходимо:

• представить систему как «черный ящик» и изобразить для нее линию жизни - вертикальную пунктирную линию, подходящую к блоку снизу;

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

• из описания варианта использования определить множество системных событий и их последовательность;

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

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

Множество всех системных операций определяют, идентифицируя системные события всех вариантов использования. Для наглядности системные операции изображают в виде операций абстрактного класса (типа) System. Если необходимо разделить множество операций на подмножества, инициируемые разными пользователями, то используют несколько абстрактных классов: Systeml, System2 и т. д.

Каждую системную операцию необходимо описать. Обычно описание системной операции содержит:

• имя операции и ее параметры;

• описание обязанности;

• указание типа;

• названия вариантов использования, в которых она используется;

• примечания для разработчиков алгоритмов и т. д.;

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

• описание вывода неинтерфейсных сообщений;

• предположение о состоянии системы до выполнения операции (предусловие);

• описание изменения состояния системы после выполнения операции (постусловие).