Основные этапы объектно-ориентированного проектирования (стр. 4 из 5)

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

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

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

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

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

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

5.4 Исходные тексты операций обработки событий

Для рассматриваемого примера семантика операций обработки событий определяется тем, что сигнал об изменении значения сигнала должен привести к изменению значения соответствующего атрибута объекта. При этом должны выявляться сочетания входных сигналов, требующих изменения значения выходного сигнала. В этом случае необходимо обеспечить задержку события изменения выходного сигнала на время задержки логического элемента. Для этого предназначена операция главной программы 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

}

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

5.5 Диспетчер вызовов операций класса

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

publicoverridevoiddo_it(stringname_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;

}

}

6. Организация процесса проектирования

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

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

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

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

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

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

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

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

- итеративное выполнение реализации (эволюция);

- управление эволюцией продукта в ходе эксплуатации (сопровождение).

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

Описание основных этапов разработки приложения дано в таблице 9.

Таблица 9 - Основные этапы разработки приложения

Наименование этапа	Основные действия	Результаты
Выявление сущности требований к программному продукту (концептуализация)	1) определить цели апробации концепции и критерии того, что считать благополучным исходом;2) собрать подходящую команду для разработки прототипа;3) оценить готовый прототип и принять ясное решение о проектировании конечного продукта или о дальнейшем исследовании. Решение о начале разработки конечного продукта нужно принимать с разумным учетом потенциального риска, выявленного при апробации концепции.	Первичными продуктами концептуализации являются прототипы системы.
Разработка модели требуемого поведения системы (анализ)	1) идентифицировать основные функциональные точки системы и, если возможно, сгруппировать функционально связанные виды поведения. Рассмотреть возможность создания иерархии функций, в которой высшие функции вытекают из низших.2) для каждого представляющего интерес набора функциональных точек сделать раскадровку сценария, используя технику анализа поведения. Когда прояснится семантика сценариев, следует документировать их, используя диаграммы объектов, которые иллюстрируют объекты. Приложить описание событий, происходящих при выполнении сценария, и порядок выполняемых в результате действий. Кроме того, необходимо перечислить все предположения, ограничения и показатели эффективности для каждого сценария;3) если необходимо, сделать описания поведения системы в исключительных ситуациях;4) для объектов с особо важным жизненным циклом описать диаграммы состояний (построить конечный автомат);5) найти в сценариях повторяющиеся шаблоны и выразить их в терминах более абстрактных обобщенных сценариев или в терминах диаграмм классов, показывающих связи между ключевыми абстракциями.6) внести изменения в словарь данных; включить в него новые классы и объекты, выявленные для каждого сценария, вместе с описанием их ролей и обязанностей.	Результатом анализа должно быть описание назначения системы, сопровождаемое характеристиками производительности и перечислением требуемых ресурсовПобочным результатом анализа будет оценка риска: выявление опасных мест, которые могут повлиять на процесс проектирования.
Создание архитектуры для реализации (проектирование).Архитектурное планирование - охватывает логическую декомпозицию, состоящую в группировании классов, и физическую декомпозицию, состоящую в разбиении на модули и назначении заданий процессорам	1) рассмотреть группирование функциональных точек (найденных в анализе) и распределить их по слоям и разделам архитектуры. Функции, базирующиеся одна на другой должны попасть в разные слои; функции, сотрудничающие между собой для обеспечения требуемого поведения системы на данном уровне абстракции должны попасть в разделы системы, представляющие услуги на этом уровне;2) проверить архитектуру созданием действующих релизов, которые частично удовлетворяют семантике нескольких важнейших сценариев, предоставленных анализом;3) оценить достоинства и недостатки архитектуры. Определить риск изменения каждого ключевого архитектурного интерфейса, чтобы можно было заранее распределить ресурсы при эволюции системы.	Диаграммы классов и объектов.
Создание архитектуры для реализации (проектирование).Тактическое проектированиесостоит в принятии решений о множестве общих приемов	1) перечислить все случаи, когда нужно следовать единым общим приемам. Некоторые из них окажутся фундаментальными, независимыми от предметной области, например, управление памятью, обработка ошибок и т.д. Другие будут специфичны для данной области и будут содержать свойственные этой области идиомы и механизмы, такие, как принципы управления системами реального времени или транзакциями и базами данных в информационных системах;2) для каждого приема составить сценарий, описывающий его семантику. Затем выразить ее в виде исполнимого прототипа, который может быть уточнен и представлен инструментально;3) документировать каждый принцип и распространить полученные документы, чтобы обеспечить единое архитектурное видение.	Диаграммы классов и объектовОписания семантики. Сценарии
Создание архитектуры для реализации (проектирование).Программные релизы закладывают основы архитектурной эволюции системы.	1) полученные в результате анализа сценарии упорядочить от основных к второстепенным. Приоритетность сценариев лучше выяснить вместе с экспертом в предметной области, аналитиком, архитектором и контролером качества;2) распределить функциональные точки по релизам так, чтобы последний релиз в серии представлял результирующую систему;3) определить цели и расписание релизов так, чтобы дать время на разработку и синхронизировать релизы с другими действиями, например, с разработкой документации и полевыми испытаниями;4) начать планирование задач, учитывая критические места проекта и ресурсы, отведенные на выпуск каждого релиза.	Программные релизы.План, в котором определены расписание работ, задачи коллектива и оценка риска.
Итеративное выполнение реализации (эволюция);	1) определить функциональные точки, которые попадут в новый релиз, и области наивысшего риска, особенно те, которые были выявлены еще при эволюции предыдущего релиза;2) распределить задачи по релизам среди членов команды и начать новый микропроцесс. Контролировать микропроцесс, просматривая проект, и проверять состояние дел в важных промежуточных этапах с интервалами от нескольких дней до двух недель;3) когда потребуется понять семантику требуемого поведения системы, поручить разработчикам сделать прототип поведения. Четко установить назначение каждого прототипа и определить критерии готовности. После завершения решить, как включить результаты прототипирования в этот или последующие релизы;4) завершить микропроцесс интеграцией и очередным действующим релизом.	Серия исполняемых релизов, представляющих итеративные усовершенствования изначальной архитектурной модели.Описание поведения, которое используется для исследования альтернативных подходов и дальнейшего анализа системы
Управление эволюцией продукта в ходе эксплуатации (сопровождение).	1) упорядочить по приоритетам предложения о крупных изменениях и сообщения об ошибках, связанных с системными проблемами, и оценить стоимость переработки;2) составить список этих изменений и принять их за функциональные точки в дальнейшей эволюции;3) если позволяют ресурсы, запланировать в следующем релизе менее интенсивные, более локализованные улучшения;4) приступить к разработке следующего эволюционного релиза программы.	Список новых заданий: обнаруженные дефекты и новые требования.

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