Объектно-ориентированное проектирование. 
Информационная система выбора оптимальных туристских маршрутов

Рассмотрю принципы объектно-ориентированного проектирования, которое основано на объектно-ориентированной модели. Обычно процессы программирования и проектирования, отделенный от процесса управления (или микропроцесс в определении Гради Буча [16]), состоит из следующих видов деятельности:

• · выявление классов и объектов на данном уровне абстракции;
• · выявление семантики этих классов и объектов;
• · выявление связей между этими классами и объектами;
• · спецификация интерфейса и реализация этих классов и объектов.

При этом в микропроцессе перемешаны фазы анализа и проектирования. Рассмотрю эти процессы более подробно.

Цель выявления классов и объектов состоит в том, чтобы найти границы предметной области. Кроме того, эта деятельность является первым шагом в продумывании объектно-ориентированной декомпозиции разрабатываемой системы. Этот шаг в анализе применяется, когда обнаруживается задача абстракции, составляющие словарь предметной области. Такие действия необходимы при проектировании, когда изобретаются новые абстракции, которые являются составными частями решения. Переходя к программной реализации, применяется процедура выявления, чтобы изобрести простые абстракции, из которых строятся более сложные, и обнаружить общие черты существующих абстракций с целью упростить архитектуру системы. Результатом выявления классов и объектов является обновляющийся по мере развития проекта словарь данных. Словарь данных — центральное хранилище относящихся к системе абстракций.

После выполнения этого шага можно переходить к выявлению семантики классов и объектов, то есть определению поведения и атрибутов каждой абстракции. На стадии анализа этот шаг применяется для распределения обязанностей между различными видами поведения системы. На стадии проектирования эта процедура позволяет распределить обязанности между частями реализации. При реализации следует продвигаться от описаний ролей и обязанностей в свободной форме к спецификациям конкретных протоколов для каждой абстракции и, в конечном счёте, — к точным сигнатурам (совокупностям признаков) каждой операции. Результатом становится уточнение словаря данных. В ходе проектирования можно выработать спецификации к каждой абстракции, перечисляя имена операций в протоколе каждого класса. Следующим шагом станет создание интерфейсов этих классов на языке реализации. Примером могут служить заголовочные файлы. h в С++. Также составляются диаграммы объектов и диаграммы взаимодействий, передающие семантику сценариев, создаваемых в ходе микропроцесса.

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

Реализация классов и объектов доводит существующие абстракции до уровня, достаточного для обнаружения новых классов и объектов, необходимых на следующем уровне абстракции. При проектировании с целью реализации становится создание осязаемого представления абстракций путём выпуска последовательных исполнимых версий системы (макропроцесс). Этот шаг намеренно выполняется позже всех, так как макропроцесс концентрирует внимание на поведении и откладывает решения о представлении. На этом шаге принимается решение о представлении каждой абстракции и об отображении каждой абстракций в физическую модель. В начале процесса разработки формулируются тактические решения о представлении в форме уточненных спецификаций классов. Решения, имеющие общий интерес, или подходящие для повторного использования, документируются на диаграммах классов (показывающих их статическую семантику), состояний или взаимодействия (показывающих их динамическую семантику). Когда становится ясно, на каком языке реализовывать проект, начинается программирование в псевдокоде или исполнимом коде. Для раскрытия связей между логическим и физическим уровнем, вводятся диаграммы модулей, которые затем можно использовать, чтобы показать отображение архитектуры в программную реализацию. С реализацией связано одно главное действие — выбор структур и алгоритмов, которые представляют семантику определённых ранее микропроцессом абстракций. В отличие от первых трех стадий микропроцесса, сосредоточенных на внешних представлениях абстракций, этот этап акцентирует внимание на их внутреннем представлении. На стадии анализа результаты этого действия относительно абстрактны, поскольку разработчик не столько обеспокоен реализацией сколько заинтересован в отыскании новых абстракций, которым можно делегировать обязанности. На стадии проектирования, особенно на поздних стадиях проектирования классов, нужно переходить к практическим решениям.