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

Решение задач и выполнение научно-исследовательских разработок: Отправьте запрос сейчас: irina@bodrenko.org    
математика, IT, информатика, программирование, статистика, биостатистика, экономика, психология
Пришлите по e-mail: irina@bodrenko.org описание вашего задания, срок выполнения, стоимость





 

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

 

Лекция 5.

 

Тема лекции: «Объектно-ориентированный подход к проектированию программного обеспечения».

 

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

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

3. Проектирование программного обеспечения при объектном подходе.

 

  1.  АНАЛИЗ ТРЕБОВАНИЙ И ОПРЕДЕЛЕНИЕ СПЕЦИФИКАЦИЙ ПРИ ОБЪЕКТНОМ ПОДХОДЕ.

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

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

Моделирование необходимо для решения следующих задач:

1) визуализации системы;

2) определения ее структуры и поведения;

3) получения шаблона, позволяющего затем сконструировать систему;

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

Для решения этих задач при описании поведения  проектируемого программного обеспечения в настоящее время  используется UML (Unified Modeling Language) — унифицированный язык моделирования.

1.1. Некоторые теоретические сведения о UML  - унифицированном языке моделирования.

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

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

Спецификация разрабатываемого программного обеспечения при использовании UML объединяет несколько моделей:  ЛОГИЧЕСКУЮ, ИСПОЛЬЗОВАНИЯ, РЕАЛИЗАЦИИ, ПРОЦЕССОВ, РАЗВЕРТЫВАНИЯ.

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

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

 

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

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

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

 

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

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

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

1)

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

2)

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

3)

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

4)

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

5)

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

6)

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

7)

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

8)

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

9)

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

1.2. Определение прецедентов (вариантов использования).

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

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

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

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

 ОСНОВНЫЕ, обеспечивают выполнение функций  проектируемой системы;

ВСПОМОГАТЕЛЬНЫЕ, обеспечивают выполнение настроек  системы и ее обслуживание;

 

ДОПОЛНИТЕЛЬНЫЕ, служат для удобства пользователя  (реализуются в том случае, если не требуют серьезных затрат  каких-либо ресурсов ни при разработке, ни при  эксплуатации).

 

ПРИМЕР. Анализ функциональных требований и  пользователей системы тестирования (модуль обучающей системы).

Система тестирования прежде всего требуется следующим заинтересованным лицам:

• обучаемому (студенту);

• составителю тестов (преподавателю);

• преподавателю, принимающему экзамен;

• сотруднику деканата, осуществляющему контроль за  успеваемостью;

• администратору сети и баз данных учебного учреждения.

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

• студент (тестируемый);

• администратор (он же преподаватель, он же составитель тестов).

Соответственно основные прецеденты (варианты  использования) для нашей системы следующие:

Прецедент для студента:

• П1 — пройти тестирование.

 

Прецеденты для администратора:

• П2 — создать/изменить тест;

• ПЗ — просмотреть результаты тестирования;

• П4 — добавить/изменить пользователей и др.

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

Краткое описание варианта использования для данного примера:

Подробное описание вариантов использования для данного примера:

 

Для большей наглядности используют диаграммы вариантов использования.

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

1.3.

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

 

 

Рисунок 1. Условные обозначения диаграмм прецедентов:

а — актор; б — вариант использования; в — связь

Приведем диаграмму прецедентов для вышеописанного  примера (рисунок 2).

 

Рисунок 2. Диаграмма вариантов использования тестовой системы.

 

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

2. ПОСТРОЕНИЕ КОНЦЕПТУАЛЬНОЙ МОДЕЛИ ПРЕДМЕТНОЙ ОБЛАСТИ.

2.1. Диаграммы классов.

Центральное место в объектно-ориентированном подходе к проектированию программного обеспечения занимает  разработка логической модели системы в виде диаграммы классов (class diagram).

UML предлагает использовать три уровня диаграмм классов в зависимости от степени их детализации:

• КОНЦЕПТУАЛЬНЫЙ УРОВЕНЬ, на котором диаграммы классов отображают связи между основными понятиями  предметной области;

• УРОВЕНЬ СПЕЦИФИКАЦИЙ, на котором диаграммы классов отображают связи объектов этих классов;

• УРОВЕНЬ РЕАЛИЗАЦИИ, на котором диаграммы классов  непосредственно показывают поля и операции конкретных классов.

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

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

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

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

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

 

Диаграммы классов обычно  содержат следующие сущности:

классы;

интерфейсы;

 

кооперации;

отношения зависимости, обобщения и ассоциации.

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

КЛАСС

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

 

Рисунок 3.Графическое изображение класса на диаграмме классов.

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

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

Рисунок 4. Примеры графического изображения классов.

 

ИМЯ КЛАССА

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

Примерами имен классов могут быть такие  существительные, как «Сотрудник», «Фирма», «Руководитель», «Покупатель», «Продавец» и многие другие, имеющие непосредственное  отношение к моделируемой предметной области и функциональному назначению проектируемой системы.

 

Если класс не имеет экземпляров (объектов), то он  называется абстрактным классом, его имя записывается курсивом, как любой текст, относящийся к абстрактному элементу.

Атрибуты класса

Во второй секции прямоугольника — графического  изображения класса — записываются его атрибуты (attributes) или свойства. Стандартная запись атрибута в языке UML выглядит следующим образом:

<квантор видимости><имя атрибута>[кратность]

<тип атрибута> <исходное значение>{строка-свойство}

Квантор видимости может быть опущен — это означает, что видимость атрибута не указывается либо же должна принимать одно из трех возможных значений:

общедоступный (public) — обозначается «+»;

защищенный (protected) — обозначается «#»;

закрытый (private) — обозначается «-».

ИМЯ АТРИБУТА — единственный обязательный элемент  обозначения атрибута, представляет собой строку текста, которая используется в качестве идентификатора соответствующего  атрибута и является уникальной в пределах данного класса.

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

[нижняя_граница1..верхняя_граница1, нижняя_граница2..верхняя_граница2, нижняя_границаk..верхняя_границаk],

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

 

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

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

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

Если же указывается единственный знак «*», то это означает, что кратность атрибута может быть произвольным  положительным целым числом или нулем.

Могут использоваться следующие варианты задания  кратности атрибутов:

• [0..1] означает, что кратность атрибута может принимать значение 0 или 1. При этом 0 означает отсутствие значения для данного атрибута;

• [0..*] или просто [*] означает, что кратность атрибута  может принимать любое неотрицательное целое значение, большее или равное 0;

• [1..*] означает, что кратность атрибута может принимать любое положительное целое значение, большее или  равное 1;

• [1..5] означает, что кратность атрибута может принимать любое значение из чисел 1, 2, 3, 4, 5;

• [1..3,7..10] означает, что кратность атрибута может принимать любое значение из чисел 1, 2, 3, 7, 8, 9, 10;

• [1..3,7..*] означает, что кратность атрибута может  принимать любое значение из чисел 1, 2, 3, а также любое  положительное целое значение, большее или равное 7.

 

Если кратность атрибута не указана, то по умолчанию  принимается ее значение, равное 1.

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

ПРИМЕР.

имя_студента [1..2]  String

 

здесь имя_студента является именем атрибута, тип атрибута String (строка).

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

ПРИМЕР.

имя_студента [1..2]  :  String = Иван.

 

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

 

Запись  данного атрибута в виде стипендия Integer = $50 означает, что при создании нового экземпляра Студент для него устанавливается по умолчанию стипендия в 50 долл.

 

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

ОПЕРАЦИЯ

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

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

<квантор видимости><имя операции> (список параметров)

<выражение типа возвращаемого значения>{строка-свойство}

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

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

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

<вид параметра><имя параметра>:<выражение типа>=<значение параметра по умолчанию>.

Вид параметра — это одно из ключевых слов in, out или inout со значением in по умолчанию.

 

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

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

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

Операция, которая не может изменять состояние системы, обозначается строкой-свойством {запрос} ({query}). Другие  операции могут изменять состояние системы, хотя и необязательно будут это делать.

ОПИСАНИЕ ОПЕРАЦИИ на самом верхнем уровне объявляет эту операцию на весь класс, при этом данная операция наследуется всеми потомками данного класса.

 

Если в некотором классе  операция не выполняется, то такая операция может быть помечена как абстрактная ({abstract}). Можно также записать сигнатуру операции курсивом, чтобы обозначить ее абстрактной.

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

 

ПРИМЕР.

 

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

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

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

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

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

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

1) идентифицировать каждое действующее лицо (объект) и изобразить для него линию жизни. Крайним слева на  диаграмме изображается объект, который является  инициатором взаимодействия (см. объект 1 на рисунке 5). Правее изображается другой объект, который непосредственно взаимодействует с первым, и т. д.;

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

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

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

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

Рисунок 5. Различные графические примитивы диаграммы последовательности.

 

ЛИНИЯ ЖИЗНИ ОБЪЕКТА.

Линия жизни объекта (object lifeline) служит для обозначения периода времени, в течение которого объект существует в  системе и, следовательно, может потенциально участвовать во всех ее взаимодействиях. На диаграмме линия жизни изображается пунктирной вертикальной линией, ассоциированной с  единственным объектом. Если объект существует в системе постоянно, то и его линия жизни должна продолжаться по всей плоскости диаграммы последовательности от самой верхней ее части до  самой нижней (объекты 1 и 2 на рисунке 5).

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

ФОКУС УПРАВЛЕНИЯ.

Объекты на диаграмме последовательности могут находиться в двух состояниях, активном — непосредственно выполняя  какие-либо действия, и пассивном, ожидая сообщения от других объектов. Чтобы явно выделить подобную активность объектов, в языке UML применяется специальное понятие, получившее название фокуса управления (focus of control). Фокус управления изображается в форме вытянутого узкого прямоугольника (см. объект 1 на рис. 3.42), верхняя сторона которого обозначает  начало получения фокуса управления объекта (начало активности) а ее нижняя сторона — окончание фокуса управления (окончание активности).

СООБЩЕНИЯ.

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

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

 

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

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

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

 

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

 

Рисунок 6. Пример диаграммы последовательностей состояний.

 

Диаграммы деятельностей (activity diagram)

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

СОСТОЯНИЕ ДЕЙСТВИЯ.

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

 

Рисунок 7. Графическое изображение состояния действия:

а — простое действие; б — выражение.

Действие может быть записано на естественном языке,  некотором псевдокоде или языке программирования. Рекомендуется в качестве имени простого действия использовать глагол с  пояснительными словами (рисунок 7, а). Если это возможно, то  допускается запись действия на том языке программирования, на котором предполагается реализовывать конкретный проект (рисунок 7, б).

Каждая диаграмма деятельности должна иметь единственное начальное и единственное конечное состояния (рисунок 8). Саму диаграмму деятельности принято располагать таким образом, чтобы действия следовали сверху вниз. В этом случае начальное состояние будет изображаться в верхней части диаграммы, а  конечное — в ее нижней части.

 

 

Рисунок 8. Графическое изображение: а — начальное состояние; б — конечное состояние.

ПЕРЕХОДЫ.

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

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

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

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

 

На рисунке 9 представлен фрагмент известного алгоритма  нахождения корней квадратного уравнения. В общем случае после приведения уравнения второй степени к каноническому виду (а х х+ b x+ c = 0)  в случае отрицательного дискриминанта уравнение не имеет решения на множестве действительных  чисел, и дальнейшие вычисления должны быть прекращены. При неотрицательном дискриминанте уравнение имеет решение, корни которого могут быть получены на основе конкретной  расчетной формулы.

 

 

Рисунок 9. Фрагмент диаграммы деятельности для алгоритма нахождения корней квадратного уравнения.

 

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

 

При этом разделение (concurrent fork) имеет один входящий переход и несколько  выходящих (рисунок 10, а). Слияние (concurrent join), наоборот, имеет несколько входящих переходов и один выходящий (рисунок 10, б).

 

Рисунок 10. Графическое изображение:

а – слияния; в – разделения параллельных потоков управления.

 

На рисунке 11 показан пример диаграммы деятельности  процесса приготовления напитка.

 

Рисунок 11. Пример диаграммы деятельности.

 

Диаграммы состояний (statechart diagram).

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

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

АВТОМАТ.

Диаграмма состояний по существу является графом  специального вида, который представляет некоторый автомат.

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

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

Простейший пример автомата с двумя состояниями  демонстрирует ситуация с исправностью компьютера. Здесь  рассматриваются два самых общих состояния: «исправен» и «неисправен» и два перехода: «выход из строя» и «ремонт». Графически эта информация может быть представлена в виде изображенной Диаграммы состояний компьютера (рисунок 12).

Рисунок 12. Пример диаграммы состояний.

Основными понятиями, описывающими АВТОМАТ, являются состояние и переход. Предполагается, что система находится в каком-либо состоянии в течение некоторого времени, тогда как переход объекта из состояния в состояние происходит мгновенно.

СОСТОЯНИЕ.

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

Состояние на диаграмме изображается прямоугольником со скругленными вершинами (рисунок 13), который может быть  разделен горизонтальной линией на две секции.

 

Рисунок 13. Графическое изображение состояний на диаграмме состояний.

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

ИМЯ СОСТОЯНИЯ.

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

 

Имя является необязательным элементом.

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

СПИСОК ВНУТРЕННИХ ДЕЙСТВИЙ.  

 

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

<метка-действия   выражение-действия>

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

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

 

Рисунок 14. Пример состояния с непустой секцией внутренних действий.

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

ПЕРЕХОД

Простой переход (simple transition) представляет собой  отношение между двумя последовательными состояниями, которое указывает на факт смены одного состояния другим.

 

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

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

 

 

В примере на рисунке 12 переход сработает при возникновении события — «выход из строя».

СОБЫТИЕ.

Событие (Event) — это спецификация существенного факта, который происходит во времени и пространстве.

 

В контексте  автоматов событие — это стимул, способный вызвать  срабатывание перехода.

СТОРОЖЕВОЕ УСЛОВИЕ.

Сторожевое условие (guard condition), если оно есть, всегда записывается в прямых скобках после события-триггера и  представляет собой некоторое булевское выражение (выражение,  результатом которого является «истина» или «ложь»).

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

 

Рисунок 15. Диаграмма состояний для моделирования почтовой программы-клиента.

 

3. ПРОЕКТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ПРИ ОБЪЕКТНОМ ПОДХОДЕ.

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

 

3.1. Разработка структуры программного обеспечения при объектном подходе.

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

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

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

класс-сущность (entity class) — пассивный класс,  информация о котором должна храниться постоянно. Как правило, этот класс соответствует отдельной таблице базы данных.

В этом случае его атрибуты являются полями таблицы, а операции — присоединенными или хранимыми  процедурами (рисунок 16, б);

граничный класс (boundary class) располагается на границе системы с внешней средой. К этому типу относят как  классы, реализующие пользовательские интерфейсы, так и классы, обеспечивающие интерфейс с аппаратными  средствами или программными системами (рисунок 16, в).

 

Рисунок 16. Графическое изображение классов для моделирования программного обеспечения:  а — управляющий класс; б — класс-сущность; в — граничный класс

ОТНОШЕНИЯ МЕЖДУ КЛАССАМИ.

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

отношение зависимости (dependency relationship);

отношение ассоциации (association relationship);

 

отношение обобщения (generalization relationship);

отношение реализации (realization relationship).

 

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

ОТНОШЕНИЕ ЗАВИСИМОСТИ.

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

Отношение зависимости графически изображается  пунктирной линией между соответствующими элементами со стрелкой на одном из ее концов («->» или «<-»). На диаграмме классов данное отношение связывает отдельные классы между собой, при этом стрелка направлена от класса-клиента зависимости к независимому классу или классу-источнику (рисунок 17). На  данном рисунке изображены два класса: Класс_А и Класс_Б, при этом Класс_Б является источником некоторой зависимости, а Класс А — клиентом этой зависимости.

 

Рисунок 17. Графическое изображение отношения зависимости на диаграмме классов.

ОТНОШЕНИЕ АССОЦИАЦИИ.

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

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

На рисунке 18 показано отношение бинарной ассоциации  между классом «Группа» и классом «Студент». Они связаны между собой бинарной ассоциацией «Учеба», имя которой указано на рисунке над линией ассоциации. Порядок следования классов в данном отношении таков: первым является класс «Студент», а вторым — класс «Группа».

 

Рисунок 18. Графическое изображение отношения бинарной ассоциации между классами.

Можно, хотя это редко бывает необходимо, создавать  ассоциации, связывающие сразу несколько классов; они называются N-арными.

 

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

 

Пример тернарной ассоциации показан на рисунке 19. Здесь изображено отношение между тремя классами: «Футбольная  команда», «Год» и «Игра», которое может представлять  информацию об играх футбольных команд в национальном чемпионате в течение нескольких последних лет.

 

 

Рисунок 19. Графическое изображение тернарной ассоциации между тремя классами.

 

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

К таким свойствам относятся:

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

• кратность отдельных классов, являющихся концами  ассоциации. Интервал кратности записывается рядом с концом ассоциации и для TV-арной ассоциации означает потенциальное число отдельных экземпляров или значений  кортежей этой ассоциации, которые могут иметь место, когда остальные N - 1 экземпляров или значений классов  фиксированы.

В рассмотренном ранее примере (см.: рисунок18) кратность «1» для класса «Группа» означает, что каждый студент может  учиться только в одной группе. Кратность «1..*» для класса «Студент» означает, что в каждой группе могут учиться несколько  студентов, общее число которых заранее неизвестно и ничем не  ограничено, но всегда больше нуля.

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

(Xor-association).

 

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

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

 

Рисунок 20. Графическое изображение исключающей ассоциации между тремя классами.

 

ОТНОШЕНИЕ АГРЕГАЦИИ.

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

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

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

Агрегация является частным случаем ассоциации и  изображается в виде пустой ассоциации с незакрашенным ромбом со стороны «целого» (рисунок 21).

 

Рисунок 21. Графическое изображение отношения агрегации в языке UML.

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

 

Рисунок 22. Диаграмма классов для иллюстрации отношения агрегации на примере структуры персонального компьютера.

 

ОТНОШЕНИЕ КОМПОЗИЦИИ.

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

Графически отношение композиции изображается  сплошной линией, один из концов которой представляет собой  закрашенный внутри ромб. Этот ромб указывает на тот из классов, который представляет собой класс-композицию или «целое» (рисунок 23).

 

Рисунок 23. Графическое изображение отношения композиции  в языке UML.

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

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

 

А именно, указание кратности класса ассоциации и имени данной  ассоциации, которые не являются обязательными. Диаграмма  классов для класса «Окно_программы», описанного выше, может иметь следующий вид (рисунок 24).

 

Рисунок 24. Диаграмма классов для иллюстрации отношения композиции на примере

класса окна программы.

 

ОТНОШЕНИЕ ОБОБЩЕНИЯ.

Отношение обобщения является отношением между более  общим элементом (родителем или предком) и более частным или специальным элементом (дочерним или потомком).

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

 

Рисунок 25. Графическое изображение отношения обобщения в языке UML.

Кроме классов на диаграмме могут изображаться  интерфейсы.

 

ИНТЕРФЕЙСЫ.

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

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

Для обозначения интерфейса на диаграмме классов используется специальный графический символ — окружность, рядом с  которой указывается имя интерфейса, или стандартный способ — прямоугольник класса с обозначением «Interface» (рисунок 26).

 

Рисунок 26. Обозначения интерфейсов.

ОБЪЕКТЫ.

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

Объект (object) — это отдельный экземпляр класса, который создается на этапе выполнения программы.

 

Он имеет свое  собственное имя и конкретные значения атрибутов.

 

ИМЯ ОБЪЕКТА  ПРЕДСТАВЛЯЕТ СОБОЙ СТРОКУ ТЕКСТА «ИМЯ ОБЪЕКТА» «ИМЯ КЛАССА»,  РАЗДЕЛЕННУЮ ДВОЕТОЧИЕМ.

 

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

 

Рисунок 27. Пример диаграммы объектов.

 

Диаграммы кооперации.

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

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

 

 

ДИАГРАММЫ КОМПОНЕНТОВ И РАЗВЕРТЫВАНИЯ выполняются на этапе физического проектирования программных систем для того, чтобы привязать их к некоторому аппаратному обеспечению.

 

 

СПИСОК РЕКОМЕНДУЕМОЙ ЛИТЕРАТУРЫ.

 

[1] Благодатских В.А., Волнин В.А., Поскакалов К.Ф. Стандартизация разработки программных средств. Учебное пособие /Под ред. О.С. Разумова. М.: Финансы и статистика, 2005. – 288 с., ил.

 

[2] Брауде Э. Технология разработки программного обеспечения. СПб.: Питер, 2004. – 655 с.: ил.

[3] Вигерс К. Разработка требований к программному обеспечению /Пер. с англ. – М.: ИТД «Русская Редакция», 2004. – 576.: ил.  

 

[4] Гагарина Л.Г., Кокорева Е.В., Виснадул Б.Д. Технология разработки программного обеспечения. Учебное пособие /Под ред. Л.Г. Гагариной. – М.: ИД «Форум»: ИНФРА-М, 2008. – 400 с.: ил. – (Высшее образование).

 

[5] Котов С.Л., Палюх Б.В., Федченко С.Л. Разработка, стандартизация и сертификация программных средств и информационных технологий и систем. Учебное пособие. Тверь.: ТГТУ, 2006. – 104 с.