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

Различные разработчики подходят к описанию  вариантов  использования  с разной степенью детализации. Например,  Ивар  Якобсон  утверждает,  что  для проекта   с   трудоемкостью   в   10   человеко-лет   количество   вариантов использования может составлять около 20 (не считая связей "использование"  и "расширение"). Следует предпочитать небольшие  и  детализированные  варианты использования,   поскольку   они   облегчают   составление   и    реализацию согласованного плана проекта.

2.2 Диаграммы

 

UML обеспечивает поддержку  всех этапов жизненного цикла  ИС и предоставляет для этих целей ряд графических средств - диаграмм.

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

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

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

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

Диаграммы прецедентов (диаграммы  вариантов использования, use case diagrams) - это обобщенная модель функционирования системы в окружающей среде.

Диаграммы видов деятельности (диаграммы деятельностей, activity diagrams) - модель бизнес-процесса или поведения  системы в рамках прецедента.

Диаграммы взаимодействия (interaction diagrams) - модель процесса обмена сообщениями между объектами, представляется в виде диаграмм последовательностей (sequence diagrams) или кооперативных диаграмм (collaboration diagrams).

Диаграммы состояний (statechart diagrams) - модель динамического поведения системы и ее компонентов при переходе из одного состояния в другое.

Диаграммы классов (class diagrams) - логическая модель базовой структуры системы, отражает статическую структуру системы и связи между ее элементами.

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

Диаграммы компонентов (component diagrams) - модель иерархии подсистем, отражает физическое размещение баз данных, приложений и интерфейсов ИС.

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

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

Рис. 2 Взаимосвязи между диаграммами UML

 

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

 

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

• ассоциации (например, клиент может сделать заказ);

• подтипы (частный клиент является разновидностью клиента).

 

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

 

 

 

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

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

Построение диаграмм классов можно рассматривать  в различных аспектах:

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

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

аспект реализации - модель действительно определяет реализацию классов ПО. Этот аспект наиболее важен для программистов.

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

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

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

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

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

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

Каждая ассоциация обладает двумя ролями; каждая роль представляет собой направление ассоциации. Таким  образом, ассоциация между Клиентом и Заказом содержит две роли: одна от Клиента к Заказу, другая - от Заказа к Клиенту.

Роль может быть явно поименованная с помощью метки. Например, роль ассоциации в направлении  от Заказа к Строкам заказа называется "позиция заказа". Если такая  метка отсутствует, роли присваивается имя класс - цели - таким образом, роль ассоциации от Заказа к Клиенту может быть названа Клиент (термины "начало" (source) и "цель" (target) употребляются для обозначения классов, являющихся соответственно начальным и конечным для ассоциации).

2.2.2 Диаграмма взаимодействия

 

Диаграммы взаимодействия (interaction diagrams) являются моделями, описывающими поведение взаимодействующих групп объектов.

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

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

Окно Ввода Заказа посылает Заказу сообщение "приготовиться".

Заказ посылает данное сообщение каждой Строке заказа в данном Заказе.

Каждая Строка заказа проверяет состояние определенного  Запаса товара:

Если данная проверка удовлетворяется (результат - true), то Строка заказа удаляет соответствующее  количество товара из Запаса.

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

Существуют два вида диаграмм взаимодействия: диаграммы  последовательности (sequence diagrams) и кооперативные диаграммы (collaboration diagrams).

На диаграмме последовательности объект изображается в виде прямоугольника на вершине пунктирной вертикальной линии (рис.2.2).

Эта вертикальная линия  называется линией жизни (lifeline) объекта. Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия. Такую форму представления впервые ввел Ивар Якобсон.

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

 

Каждое сообщение представляется в виде стрелки между линиями жизни двух объектов. Сообщения появляются в том порядке, как они показаны на странице - сверху вниз. Каждое сообщение помечается, как минимум, именем сообщения; при желании можно добавить также аргументы и некоторую управляющую информацию и, кроме того, можно показать само делегирование (self-delegation) - сообщение, которое объект посылает самому себе, при этом стрелка сообщения указывает на ту же самую линию жизни.

Из всей возможной  управляющей информации два ее вида имеют существенное значение. Во-первых, это условие, показывающее, когда посылается сообщение (например, [нуженПовторныйЗаказ = "true"]). Сообщение посылается только при выполнении данного условия. Другой полезный управляющий маркер - это маркер итерации, показывающий, что сообщение посылается много раз для множества объектов-адресатов (например,* приготовиться).

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

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

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

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

 

Рис. 2.3 Параллельные процессы и активизации

 

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

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

• создавать новую  ветвь процесса (в этом случае оно  связано с самой верхней частью активизации);

• создавать новый  объект;

• устанавливать связь  с уже выполняющейся ветвью процесса.

Удаление объекта показано с помощью большого знака "X". Объекты могут выполнить самоуничтожение или могут быть уничтожены посредством еще одного сообщения.

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

  
3. Разработка модели программного обеспечения,

управляющего  работой холодильника

3.1 Описание предметной области

 

Требуется разработать  средствами Rational Rose модель программного обеспечения встроенного процессора холодильника.