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

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

Модели помогают:

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

В настоящее время существует несколько технологий объектно-ориентированной разработки прикладных программных систем, в основе которых лежит построение и интерпретация на компьютере моделей этих систем. В данном проекте применена одна из них - OMT (Object Modeling Techniques). Кроме того построена диаграмма объектной модели на языке UML .

Анализ внешних требований к проектируемой системе позволяет определить объекты и классы объектов, связанные с прикладной проблемой, которую должна решать эта система. Все классы должны быть осмыслены в рассматриваемой прикладной области; классов, связанных с компьютерной реализацией, как например список, стэк и т.п. на этом этапе вводить не следует.

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

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

Далее анализируем список возможных классов с целью исключения из него ненужных классов. Такими классами являются[1,3]:

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

Приведём словарь, содержащий определения классов, используемых в проекте:

• Proxy – программа, обрабатывающая запросы клиентов;
• Запрос – запрос клиента (Http запрос);
• Ответ – ответ на запрос (Http ответ на Http запрос);
• Кэш – хранилище информации, в котором содержится часть документов, когда-либо вызываемых пользователем. Существует алгоритм отбора этой части документов. Параметр “верхний уровень воды” определяет максимальный размер кэша. Параметр “нижний уровень воды” определяет размер кэша после очередной очистки.
• Документ – документ, запрашиваемый пользователем;
• Заголовок ответа – заголовок http ответа;
• Удалённый сервер – Web сервер, с которого пользователь хочет загрузить документ;
• Другой proxy – каскадируемый proxy сервер. Если в конфигурации моего proxy сервера указан адрес другого proxy сервера, то все запросы поступающие моему серверу буду переадресованы ему (каскадирование);
• Клиент – клиентская программа (Browser Internet);
• Конфигурация proxy сервера – информация об основных настройках моего proxy сервера;
• Файл – локальный текстовый файл для хранения информации.

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

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

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

Аналогично тому, как имена возможных классов получались из существительных, встречающихся в предварительной постановке прикладной задачи, имена возможных зависимостей могут быть получены из глаголов или глагольных оборотов, встречающихся в указанном документе. Таким образом, можно получить следующие глагольные обороты:

• Клиент посылает Запрос Proxy;
• Proxy посылает Запрос Другому proxy;
• Другой proxy возвращает Ответ Proxy;
• Удалённый сервер возвращает Ответ Proxy;
• Proxy посылает Ответ Клиенту;
• Proxy посылает Запрос Удалённому Web серверу;
• Web сервер возвращает Ответ Proxy;
• Документ содержится в Ответе;
• Заголовок ответа является частью ответа;
• Proxy анализирует Заголовок ответа;
• Документы содержатся в Кэше;
• Документ хранится в Файле;
• Конфигурация взаимодействует с Файлом;
• Proxy взаимодействует с Кэшем;
• Proxy взаимодействует с Конфигурацией;

Затем убираем ненужные или неправильные зависимости, используя следующие критерии:

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

Обработав список зависимостей, получаем следующие:

• Ответ состоит из Ответа и Заголовка ответа
• Документ содержится в Кэше;
• Кэш хранится в Файле;
• Proxy взаимодействует с Кэшем;
• Proxy анализирует Заголовок ответа;
• Proxy взаимодействует с Конфигурацией proxy;
• Кэш взаимодействует с Конфигурацией proxy;
• Proxy взаимодействует с Запросом;
• Proxy взаимодействует с Ответом;
• Клиент посылает Запрос;
• Запрос посылается Удалённому серверу;
• Запрос посылается Другому proxy;
• Клиент получает Ответ;
• Другой proxy возвращает Ответ;
• Удалённый сервер возвращает Ответ;

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

Рис. 4.1. Первая версия объектной диаграммы для Proxy сервера.

На этом этапе уточняется система атрибутов: корректируются атрибуты классов, вводятся, в случае необходимости, новые атрибуты. Атрибуты выражают свойства объектов рассматриваемого класса, либо определяют их текущее состояние.

Атрибуты обычно соответствуют существительным; например цвет_автомобиля (свойство объекта), позиция_курсора (состояние объекта). Атрибуты, как правило, слабо влияют на структуру объектной модели.

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

Наряду с атрибутами объектов необходимо ввести и атрибуты зависимостей между классами (связей между объектами).

При уточнении атрибутов руководствуются следующими критериями[1,3]:

• Замена атрибутов на объекты. Если наличие некоторой сущности важнее, чем ее значение, то это объект, если важнее значение, то это атрибут: например, начальник - это объект (неважно, кто именно начальник, главное, чтобы кто-то им был), зарплата - это атрибут (ее значение весьма существенно).
• Квалификаторы. Если значение атрибута зависит от конкретного контекста, его следует сделать квалификатором.
• Имена. Именам обычно лучше соответствуют квалификаторы, чем атрибуты объектов; во всех случаях, когда имя позволяет сделать выбор из объектов некоторого множества, его следует сделать квалификатором.
• Идентификаторы. Идентификаторы объектов связаны с их реализацией. На ранних стадиях проектирования их не следует рассматривать в качестве атрибутов.
• Атрибуты связей. Если некоторое свойство характеризует не объект сам по себе, а его связь с другим объектом (объектами), то это атрибут связи, а не атрибут объекта.
• Внутренние значения. Атрибуты, определяющие лишь внутреннее состояние объекта, незаметное вне объекта, следует исключить из рассмотрения.
• Несущественные детали. Атрибуты, не влияющие на выполнение большей части операций, рекомендуется опустить.

Рис. 4.2. Объектная диаграмма для Proxy сервера с учётом основных атрибутов.

Так как документы в “чистом виде” не хранятся на диске, то имеет смысл преобразовать класс Документ в класс ДокументИнфо, содержащий только информацию о документе, но не сам документ.

Так как мы не реализуем Другой Proxy, то вполне допустимо вместо класса Другой Proxy можно добавить два атрибута классу Конфигурация, а именно: Использовать_альтернативный_proxy (AlternativeProxyOn), Имя_альтернативного_proxy (AlternativeProxyName), Порт_альтернативного _proxy (AlternativeProxyPort).

Класс удалённый сервер мы не реализуем, а вся статистическая информация хранится в классе СерверИнфо (ServerInfo).

В результате мы получим модель, изображённую на рисунке 4.3. с помощью языка моделирования UML.