Сайт Информационных Технологий

4. Проектирование программной системы

4.1. Построение объектной модели

4.1.1. Определение классов
4.1.2. Подготовка словаря
4.1.3. Определение зависимостей
4.1.4. Уточнение атрибутов
4.1.5. Дальнейшее усовершенствование модели


4. Проектирование программной системы

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

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

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

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

4.1. Построение объектной модели

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

4.1.1. Определение классов

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

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

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

Proxy

Кэш

Другой proxy

Запрос

Документ

Клиент

Ответ

Удалённый Web сервер

Конфигурация

Файл

Информация о документе

Информация об удалённом Web сервере

Заголовок запроса

Заголовок ответа

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

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

Proxy

Кэш

Другой proxy

Запрос

Документ

Клиент

Ответ

Удалённый Web сервер

Конфигурация proxy сервера

Файл

Заголовок ответа

4.1.2. Подготовка словаря

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

4.1.3. Определение зависимостей

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

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

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

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

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

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

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

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

4.1.4. Уточнение атрибутов

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

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

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

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

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

Следуя этим рекомендациям получаем следующую версию объектной диаграммы для proxy сервера (Рис. 4.2).

 

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

4.1.5. Дальнейшее усовершенствование модели

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

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

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

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


Site of Information Technologies
Designed by  inftech@webservis.ru.