Для каждого класса выделяются и описываются его атрибуты (таблица 5).

Таблица 5 - Описание атрибутов класса And

Таблица 6 - Описание атрибутов класса Not

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

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

Рисунок 10 - Предварительная статическая модель

Следует иметь в виду, что при генерации кода в состав атрибутов класса And будет введен еще один: имя - taker; тип - Not. То есть, имя помеченного стрелкой конца связи добавляется в качестве атрибута к классу от которого исходит стрелка.

Событие - это нарушенное однообразие. Однообразие в схеме нарушается, если происходит изменение какого-либо сигнала. В цифровых схемах возможны два изменение сигнала: из 0 в 1 и обратно. То есть, с каждым входом и выходом элемента схемы связаны два события. Каждому событию необходимо присвоить имя и определить другие данные. Описание событий для объекта and класса And и объекта not класса Not приведены в таблицах 7,8.

Таблица 7 -Описание событий объекта and класса And

Таблица 8 - Описание событий объекта not класса Not

Простейший способ реагирования на события сопоставить каждому событию операцию класса, причем в качестве имен операций использовать имена событий. Для задания взаимодействия объектов по событиям можно использовать диаграмму последовательностей языка UML. На диаграмме последовательностей изображаются исключительно те объекты, которые непосредственно участвуют во взаимодействии и не показываются возможные статические ассоциации с другими объектами. Для диаграммы последовательностей ключевым моментом является динамика взаимодействия объектов во времени. При этом диаграмма последовательностей имеет как бы два измерения. Одно -- слева направо в виде вертикальных линий, каждая из которых изображает линию жизни отдельного объекта, участвующего во взаимодействии. Графически каждый объект изображается прямоугольником и располагается в верхней части своей линии жизни. Внутри прямоугольника записывается имя объекта. На рисунке 11 приведена диаграмма последовательностей для описанных событий и объектов. В качестве источника внешних событий на диаграмме приведен объект класса Imitator. Аргумент main_prog задает ссылку на объект главной программы, с помощью которого можно обращаться к операциям, определенным в главной программе.

Рисунок 11 - Диаграмма последовательностей

На диаграмме отражается также взаимосвязь событий - изменение выходного сигнала какого-либо объекта класса And приведет к возникновению события, связанного с изменением входного сигнала соответствующего объекта класса Not (связки событий vyx0_1(объект and) + vx0_1(объект not) и vyx1_0(объект and) + vx1_0(объект not)).

Помощь в выявлении событий предметной среды может оказать анализ состояний активных классов. Для представления активного класса используется модель конечного автомата Мура [7]. В языке UML для анализа и задания конечных автоматов используются диаграммы состояний (Statechart diagram) и диаграммы активности (Activity diagram). Например, модель активности класса Not может иметь вид, представленный на рисунке 12.

Рисунок 12 - Модель активности класса Not

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

Рисунок 13 - Уточненная статическая модель

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

// Изменение сигнала на входе 1 And из 0 в 1----------------------------

public void vx10_1(Form1 main_prog)

{

this.vx1 = 1;

if((this.vx2==1)&&( this.vyx==0))

{

main_prog.Porojdaet(this,"vyx0_1", this.tz, null);

}

}

// Изменение сигнала на выходе And из 0 в 1----------------------------

public void vyx0_1(Form1 main_prog)

{

this.vyx = 1;

main_prog.Porojdaet(taker,"vx0_1",0,null);

// здесь taker - адрес объекта Not, связанного с данным объектом And

// время задержки задано = 0

}

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

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

public override void do_it(string name_process,

ArrayList data,

Form1 main_prog)

{

switch(name_process)

{

case "vx11_0": vx11_0(main_prog);

break;

case "vx10_1": vx10_1(main_prog);

break;

case "vx21_0": vx21_0(main_prog);

break;

case "vx20_1": vx20_1(main_prog);

break;

case "vyx1_0": vyx1_0(main_prog);

break;

case "vyx0_1": vyx0_1(main_prog);

break;

}

}

Г. Буч [12] выделяет в процессе проектирования программного приложения микро и макропроцессы.

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

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

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

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

- выявление сущности требований к программному продукту (концептуализация);

- разработка модели требуемого поведения системы (анализ);

- создание архитектуры для реализации (проектирование);

Страницы: 1, 2, 3, 4