Система графических обозначений

Документирование процесса проектирования выполняется в соответствии с моделями объектно-ориентированного подхода. Документы должны фиксировать проектные решения, касающиеся логической структуры (структуры классов и структуры объектов) и физической структуры (архитектура модулей и архитектура процессов) разрабатываемой системы в статическом и динамическом аспектах. Наглядное представление проектных решений дают графические диаграммы: классов (рис. 1, 2, 3), объектов (рис. 4, 5, 6), взаимодействий (рис. 7), переходов состояний (рис. 8), модулей (рис. 9), процессов (рис. 10).

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

На диаграммах классов показывают отношения наследования (см. рис. 1), использования (см. рис. 2) и наполнения (см. рис. 3). Связи могут иметь имена (метки). Если при множественном наследовании возникает повторное наследование, то соответствующим значком помечается виртуальное наследование.

Различаются обозначения отношения использования интерфейсом класса (на рис. 2 интерфейс класса C9 использует класс C10) и реализацией класса (на рис. 2 реализация класса C9 использует класс C12). Иногда количество взаимодействующих объектов рассматриваемых классов предопределено условиями задачи (для классов C9 и C10 на рис.2). Соответствующие значения называются кардинальными числами и могут трактоваться как отношения "один к одному", "один ко многим" и другие.

Использование в реализации означает, что экземпляр класса содержит в себе экземпляр используемого класса (использование по значению) либо ссылку на экземпляр используемого класса (использование по ссылке). Эти отличия использования могут быть отражены на диаграмме. На рис. 2 класс C10 использует ссылки на экземпляры класса C11 и непосредственно экземпляры класса C13. Возможна ситуация, при которой экземпляры используемого класса (класса C13 на рис. 2) являются атрибутами некоторого класса (класса C12 на рис. 2), причем создаются и уничтожаются одновременно с экземпляром использующего класса. Этот способ использования отображается соответствующим значком как статическое свойство отношения между классами. Если некоторый класс или утилита используют другой класс так, что имеется доступ к защищенным полям и методам последнего, то такое отношение называется дружественным и помечается соответствующим значком (на рис. 2 между утилитой U2 и классом C13).

Отношение наполнения показывает, что конкретный класс (на рис. 3 класс C8) имеет такую же структуру, как обобщенный класс (класс C7 на рис.3) при замене формальных параметров (параметра P1) фактическими параметрами (параметром F1).

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

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

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

Для уточнения структуры классов может быть полезным детальное рассмотрение механизмов взаимодействия объектов с определением в явном виде их взаимной видимости. Возможны следующие реализации видимости, показанные на рис. 6: объект (X10) является глобальным и поэтому находится в области видимости другого объекта (X9); объект (X10) является локальным, то есть создается и удаляется в процессе выполнения операции другого объекта (X8); объект (X10) передается в качестве параметра какой-либо операции другого (X11); объект (X8) является полем другого объекта (X11). На диаграмме можно дополнительно показать, что видимый объект является разделяемым, то есть другие объекты используют его альтернативные имена (объект X9). Обозначение объекта при необходимости сопровождается указанием его устойчивости: динамический, статический или устойчивый.

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

Диаграмма переходов состояний (рис. 8) предназначена для отображения динамического поведения объекта определенного класса. На ней показываются состояния объекта, события, приводящие к переходу из одного состояния в другое и результаты переходов. На диаграмме стартовым узлом помечается начальное состояние и конечным узлом - конечное состояние. Часто начальное и конечное состояния не указываются, так как вновь созданный объект принимает состояние, зависящее от окружения, а при уничтожении объекта диаграмма переходов теряет смысл. Переход помечается именем события, инициирующим данный переход, условием перехода и именем результирующего действия. Указанный способ указания перехода состояний соответствует конечному автомату Мили. Необходимость введения понятия состояния возникает в том случае, если поведение объекта, точнее алгоритмы выполнения некоторых операций, различаются при разных значениях атрибутов объекта данного класса.

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

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

Программирование

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

Тестирование

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

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

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

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

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

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

ПРИМЕР РАЗРАБОТКИ ПРОГРАММНОЙ СИСТЕМЫ

Формулировка задачи

Предлагаемый пример является несколько измененным вариантом задачи из [3]. Требуется выполнить моделирование передвижения шаров при игре в бильярд. Бильярдный стол состоит из поля, ограниченного четырьмя стенками, в которых расположены четыре лузы. По полю двигаются шары. Один из шаров имеет белый цвет, остальные - черный. При столкновении шаров энергия в равных долях перераспределяется между ними. При столкновении шара со стенкой отражение происходит без потери энергии. Во время движения шары теряют энергию из-за трения о стол. При попадании в лузу черный шар остается в ней, теряя всю энергию, на белый шар луза не оказывает влияния. Первоначально шары имеют традиционную расстановку: белый шар в центре, черные - треугольником. Началом моделирования является придание белому шару начальной энергии и произвольного направления движения. Шары могут быть приведены в начальное состояние в любой момент времени.

Системный анализ

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

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

2. Перечислить все объекты (существительные) и приписать им те факты, в которых они упоминаются.

3. Разделить факты для каждого объекта на три группы: первая - "атрибуты", вторая - "поведение", третья - “сообщения другим объектам”. Группа “атрибуты” - это перечень абстракций сущности данного объекта. В группу “поведение” добавляются действия, которые можно сформулировать как "сделать что-то" с данным объектом, при этом указывается, какие атрибуты изменяются. При формировании группы "поведение" может возникнуть необходимость пополнения группы "атрибуты". В группу “сообщения другим объектам” включаются те действия, которые описывают взаимодействие данного объекта с другими объектами.

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

· Бильярдный стол (TTable)

¨ Атрибуты:
Четыре стенки
Четыре лузы
Черные шары
Белый шар

¨ Действия:
Начать игру (Start)
Выполнить начальную расстановку (Initiate)

· Стенка (TWall)

¨ Атрибуты:
Длина (theLength)
Угол (theAngle)

· Луза (THole)

¨ Атрибуты:
Радиус (theRadius)

· Шар (TBall)

¨ Атрибуты:
Направление движения шара (theDirection)
Энергия шара (theEnergy)
Радиус (theRadius)

¨ Действия:
Двигать шар (Move)
Установить значение энергии (SetEnergy)
Установить направление (SetDirection)

¨ Сообщения другим объектам:
Ударить шар в другой шар (HitOnBall)
Ударить шар в стенку (HitOnWall)
Попасть в лузу (HitOnHole)

· Черный шар (TBlackBall)

· Белый шар (TWhiteBall)

· Моделируемая действительность (TReality)

¨ Атрибуты:
Бильярдный стол

¨ Действия:
Выполнить моделирование (Run)

К полученному словарю предметной области следует сделать следующие замечания. Все шары имеют одноименные характеристики поведения, поэтому классы TWhiteBall и TBlackBall являются подклассами одного класса TBall. Строго говоря, моделируемый бильярдный стол не является замкнутой системой, он входит в состав более широкого понятия - моделируемая действительность. Это проявляется в том, что по условиям задачи на моделируемый стол оказывается воздействие в форме сообщений Initiate и Start от внешнего источника. Поэтому вводится понятие "моделируемая действительность" как объект theReality класса TReality. Об этом объекте известно лишь то, что он генерирует внешние события и воздействует на моделируемый бильярдный стол в процессе моделирования (Run).

Понятие "начальная энергия шара" является некоторой физической величиной, которую следовало бы предварительной определить из натурного эксперимента, но, упрощая задачу, примем ее как константу cMaxEnergy = 200.0 условных единиц. При изучении движения шара следовало бы рассмотреть физику трения качения и привести соответствующие формулы. Учитывая учебный характер примера, примем грубое допущение, что за единичный интервал времени энергия шара уменьшается на cDeltaEnergy=0.05 условных единиц не зависимо от скорости. Если в некоторый момент времени энергия оказывается меньше порогового значения cThresholdEnergy = 0.5, то шар далее двигаться не может. В реальном мире скорость движения шара зависит от его кинетической энергии, но в рассматриваемом примере будем считать, что шар движется с постоянной скоростью cVelocity = 2.0 условных единиц в единицу времени, если его энергия превышает cThresholdEnergy.

Будем определять направление движения как угол между некоторым базовым направлением и прямой, по которой движется шар. При столкновении шара, имеющего направление Alpha, со стенкой, имеющей угол theAngle, угол отражения Beta определяется формулой Beta=2*TheAngle-Alpha. Это означает, что необходимым атрибутом класса TWall является угол стенки theAngle к базовому направлению.

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

Абстракция поведения "выполнить начальную расстановку" предполагает размещение шаров на поле по следующему алгоритму. Белый шар располагается недалеко от центра поля, а остальные шары располагаются рядами, образуя треугольник. Абстракция поведения "начать моделирование" означает, что белому шару сообщаются начальная энергия и случайное направление. Из этого взаимодействия следует, что для класса TBall определены операции: "установить значение энергии" (SetEnergy) и "установить направление" (SetDirection).

Для решаемой задачи важным является отображение формы моделируемых объектов, при этом соотношение размеров следовало бы получить экспериментальным путем. Примем следующие константы в условных единицах измерения: радиус шаров cBallRadius = 5, диаметр лузы cHoleRadius = 6, длина длинных стенок cLongWallLength = 290, длина коротких стенок cShortWallLength = 190, стенки расположены под прямым углом друг к другу.

Необходимость графического отображения влечет расширение словаря предметной области. В класс TBall вводим атрибут "радиус" (theRadius), в класс THole - атрибут "радиус" (theRadius), в класс TWall - “длина” (theLength).

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

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

- управление моделированием осуществляется при помощи команд, подаваемых с клавиатуры: начать моделирование (клавиша “S”), выполнить начальную расстановку (клавиша “I”), завершить работу программы (клавиша “Q”);

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

Эксплуатационные требования:

- технические средства - ПЭВМ IBM PC;

- операционная система - MSDOS;

- процесс моделирования управляется одним оператором.

Ограничения на процесс разработки:

- сроки выполнения проекта определены в разделе “порядок выполнения работы” данных методических указаний;

- порядок сдачи системы определен в разделе “порядок выполнения работы” данных методических указаний.

Проектирование