3. Методические указания

3.1 Моделирование процессов и событий во времени

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

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

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

3.2 Проектирование пользовательского интерфейса

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

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

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

3.3 Объектный анализ и проектирование системы

Объектный анализ – начальная задача объектно-ориентированного проектирования, в ходе которой происходит выявление (идентификация) объектов и классов программной системы.

Объект – сущность, имеющая четко определенное функциональное назначение в рассматриваемой задаче, например: “небесное тело”, “орбита” (в модели Солнечной системы). Для выявления объектов полезно составить так называемый словарь проблемной области (задачи), в который входят все основные понятия (ключевые абстракции), как процедурные (глаголы), так и непроцедурные (существительные), например: “планета”, “вращаться” и т.п.

Объект характеризуется состоянием и поведением. Состояние объекта определяется перечнем (обычно статическим) всех атрибутов (свойств) данного объекта и текущими (динамическими) значениями каждого из этих свойств.

Поведение объекта характеризуется выполняемыми над ним операциями и его состоянием (некоторые операции имеют побочное действие – они изменяют состояние). Например, для объекта “небесное тело” атрибутами являются его координаты, размер, масса, а операциями – “изобразить”, “переместить” и др. Структура (атрибуты) и операции схожих объектов определяет общий для них класс (тип). Объекты – экземпляры соответствующих классов. Обычно операции объявляются как методы класса, к объектам которого они относятся. Поскольку в процессе работы одни объекты связаны с другими, эти связи моделируются как отношения между соответствующими классами. Сначала фиксируются общие семантические связи (зависимости) классов – ассоциации. В ходе дальнейшего проектирования эти связи конкретизируются. Будем различать следующие виды отношений между двумя классами:

-наследование: отношение обобщения, или общего и частного: например, “небесное тело” и “планета”; в общем случае подклассом наследуется структура и поведение более общего класса (суперкласса), в то же время подкласс обладает дополнительными/уточненными атрибутами и операциями.

-агрегация: отношение включения, или целого и части между экземплярами классов: например: “Солнечная система” и “планета”; обычно объект-часть включается в состояние объекта-целого.

-использование: связь между экземплярами классов, при которой один пользуется услугами другого (отношение клиент-сервер): например, использование операции.

Все перечисленные связи – направленные (в отличие от ассоциации).