Урок 23.

Предмет: Технология разработки программных продуктов.

Тема :Определение спецификаций при объектном подходе.

 

Цели:

Образовательная

Ознакомление с процессами формирования спецификаций.

Развивающая:

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

Воспитательная:

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

Межпредметные связи:

-         Английский язык

-         Операционные системы

-         Информационные технологии

-         Основы алгоритмизации и программирования

Оборудование: доска, мел, письменные принадлежности, проектор, ПК

Тип урока: комбинированный

Метод обучения: Объяснительно иллюстративный

Ход урока:

1.Организационный момент

         - Проверка готовности кабинета

         - Объявление темы

2. Постановка цели урока

3.Повторение пройденного материала

    Спецификации процессов

   Диаграммы переходов состояний (SDT)

   Функциональные диаграммы

   Диаграммы потоков данных (DFD)

 

4.Сообщение новых знаний

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

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

Построение концептуальной модели предметной области(диаграммы классов)

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

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

 

5. Восприятие и осознание учащимися нового материала

6. Осмысление обобщение и систематизация знаний

7. Подведение итогов урока и  постановка домашнего задания

   Выучить содержимое темы

Гагарина Л.Г.  стр. С.132-157

        Ответить на вопросы:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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

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

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

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

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

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

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

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

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

язык моделирования.

 

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

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

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

     Спецификация разрабатываемого программного обеспечения при использовании UML объединяет несколько моделей: 

логическую, использования, реализации, процессов, развертывания [1].

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

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

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

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

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

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

программного обеспечения.

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

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

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

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

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

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

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

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

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

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

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

 

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

 

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

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

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

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

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

системы заказчиком с помощью приемочных тестов.

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

• основные, обеспечивают выполнение функций  проектируемой системы;

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

 

 

 

Подробное описание варианта использования Прохождение теста

 

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

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

 

 

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

 

 

 

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

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

 

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

 

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

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

diagram) [l, 48].

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

• концептуальный уровень, на котором диаграммы классов

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

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

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

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

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

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

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

реализации.

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

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

• классы;

• интерфейсы;

• кооперации;

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

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

Класс

Класс (class) в языке UML служит для обозначения  множества объектов, которые имеют одинаковую структуру, поведение и отношения с объектами из других классов. На диаграмме класс

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

 

 

Обязательным элементом обозначения класса является его имя.

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

дополняются атрибутами (рис. 3.40, б) и операциями (рис. 3.40, в).

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

 

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

зать(), скрыть()), секция атрибутов оставлена пустой. Для класса

«Счет» (рис. 3.41, в), кроме операции проверки кредитной 

карточки, дополнительно изображена четвертая секция, в которой

указано исключение — отказ от обслуживания просроченной

кредитной карточки.

Имя класса

Имя класса должно быть уникальным в пределах диаграммы

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

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

секции имени полужирным шрифтом и должно начинаться с 

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

использовать одно или несколько существительных без пробелов между

ними. Кроме того, в секции обозначения класса могут 

находиться ссылки на стандартные шаблоны или абстрактные классы, от

которых образован данный класс и, соответственно, от которых

он наследует свойства и методы.

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

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

 

Окно

проверить()

показать()

скрыть()

Исключения

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

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

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

следующим образом:

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

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

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

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

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

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

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

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

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

верхняя_граница2, нижняя_границак

верхняя_границак],

где нижняя_граница и верхняя_граница являются 

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

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

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

верхние границы интервалов включаются в значение кратности.

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

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

• [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) и не содержит формальных параметров. Эта операция не

возвращает никакого значения после своего выполнения.

 

Описание поведения системы.

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

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

 

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

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

[1, 48].

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

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

взаимодействует с первым, и т. д.;

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

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

значений.

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

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

отдельного объекта, участвующего во взаимодействии. 

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

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

 

Линия жизни объекта Линия жизни объекта (object lifeline) служит для обозначения

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

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

диаграммы последовательности от самой верхней ее части до  самой нижней (объекты 1 и 2 на рис. 3.42).

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

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

системе уже нет и этот объект должен быть исключен из всех  последующих взаимодействий.

 

Фокус управления

Объекты на диаграмме последовательности могут находиться в двух состояниях, активном — непосредственно выполняя  какие-либо действия, и пассивном, ожидая сообщения от других

объектов. Чтобы явно выделить подобную активность объектов, в языке UML применяется специальное понятие, получившее название фокуса управления (focus of control). Фокус управления

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

а ее нижняя сторона — окончание фокуса управления (окончание активности).

 

Сообщения

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

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

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

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

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

 

 

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

Объектами в этом примере являются: два абонента а и b, два телефонных аппарата, коммутатор и сам разговор как объект  моделирования.

 

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

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

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

Состояние действия

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

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

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

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

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

 

 

 

Переходы

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

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

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

переходов несколько и сработать может только один из них. 

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

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

(рис. 3.46). В этот ромб может входить только одна стрелка от того состояния действия, после выполнения которого поток

 

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

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

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

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

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

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

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

 

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

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

 

 

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

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

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

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

выполняемых при каждой такой смене.

 

Автомат

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

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

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

Простейший пример автомата с двумя состояниями  демонстрирует ситуация с исправностью компьютера. Здесь  рассматриваются два самых общих состояния: «исправен» и «неисправен»

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

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

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

 

 

 

 

Состояние

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

события.

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

 

 

 

 

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

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

Имя состояния

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

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

Список внутренних действий

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

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

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

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

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

черты У может не указываться.

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

 

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

 

Переход

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

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

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

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

него состоянии (целевом состоянии).

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

Событие

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

который происходит во времени и пространстве. В контексте 

автоматов событие — это стимул, способный вызвать 

срабатывание перехода.

Сторожевое условие

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

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