Файл: ТРПО-лекции.pdf

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения 51

Пусть система реализуется на основе технологии клиент/сервер. Эта технология предполагает, что объекты клиента и объекты сервера будут разделены физически, то есть будут находиться в разных исполняемых модулях. Объекты, реализующие интерфейс пользователя, выносятся в отдельный программный модуль Client. Объекты оставшихся трѐх пакетов (PD, SI, DM) помещаются в программный модуль Server, через который пользователи и получают доступ к данным. Шаблон организации архитектуры приобретает вид, который показан на рис. 3-3.

Рис. 3-3. Шаблон организации

архитектуры

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

Для проектирования и реализации ПС в рамках одной предметной области достаточно воспользоваться упрощѐнным шаблоном (рис. 3-4).

Рис. 3-4. Упрощѐнный шаблон

4. МЕТОДОЛОГИИ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПОДХОДА

Объектно-ориентированный подход к разработке ПС базируется на трѐх основополагающих методологиях:

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения

1.Объектно-ориентированный анализ (Object Oriented Analysis). Предполагает52

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

2.Объектно-ориентированное проектирование (Object Oriented Design). Акценти-

рует внимание на программных классах и ищет логические пути решения поставленных анализом задач.

3.Объектно-ориентированное программирование (Object Oriented Programming).

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

Объектно-ориентированный анализ и проектирование логически приводят к объ- ектно-ориентированной декомпозиции на различных уровнях абстракции. При изменении уровня абстракции изменяется декомпозиция. Происходит итеративный процесс совершенствования модели ПС.

4.1. Объектно-ориентированный анализ

Объектно-ориентированный анализ (ООА) направлен на моделирование поведения системы. Модель анализа служит основой для последующего проектирования ПС.

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

ООА решает три основные задачи:

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

2.Выявление объектов/классов, которые составляют словарь (глоссарий) предметной области.

3.Создание структур, которые обеспечивают взаимодействие объектов/классов для удовлетворения поставленных требований.

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

4.1.1. Определение назначения системы

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

Подлежащим всегда должна быть система. Например,

1 Конкретная сфера деятельности человека, к которой относится решаемая задача. Например, люди управляют движением поездов, предметная область – железнодорожный транспорт; люди планируют транспортировку грузов по железным дорогам, предметная область – грузоперевозки на железнодорожном транспорте.

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

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

"Эта система помогает…" "Система ATM обслуживает…"

"Система РЕГИСТРАТОР поддерживает…" "Система АРЕНДАТОР облегчает…"

Другие глаголы: управляет, повышает и т.п.

Дополнение показывает объект, для которого работает система. Например,

"Эта система помогает диспетчеру товарной конторы работать более эффективно при расчѐте с заказчиком"

"Система ATM обслуживает клиентов банка, пользующихся банковскими автоматами"

"Система РЕГИСТРАТОР поддерживает ведение правильных записей о каждом факультативном курсе на факультете"

"Система АРЕНДАТОР облегчает управление арендой недвижимости"

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

4.1.2. Определение основных функций

Необходимо сначала ограничиться только самыми важными функциями. Следует помнить, что выявленные функции не должны перекрываться, то есть две разные функции не должны решать одну и ту же задачу (например, регистрация документа и сохранение документа).

При определении функций удобно придерживаться следующей классификации:

1.Регистрация важной информации. Например, регистрация документов, результатов бизнеса.

2.Ведение дела. Например, контроль и оценка состояния чего-либо на основе значений его атрибутов, различные вычисления, сортировка и поиск.

3.Анализ результатов бизнеса. Например, подсчѐт экономических показателей деятельности, оценка производительности труда.

4.Взаимодействие с другой системой. Например, приѐм сообщений от системы более низкого уровня и отправка сообщений системе более высокого уровня.

Например, для системы АРЕНДАТОР можно определить такие функции:

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

При использовании UML на уровне представления (Use Case View) полезно строить диаграммы прецедентов (Use case diagram) для идентификации актѐров, системных сервисов и представления входных и выходных документов.

4.1.3. Пример

В примере рассматривается вариант вузовской системы РЕГИСТРАТОР.

Назначение системы: Система РЕГИСТРАТОР поддерживает ведение правильных записей о каждом факультативном курсе на факультете.

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

Определение действующих лиц и функций системы:

Актѐр – секретарь факультета, который будет работать с системой.

Варианты использования (рис. 4-1):

Рис. 4-1. Диаграмма

прецедентов системы РЕГИСТРАТОР

1.Секретарь должен регистрировать читаемые преподавателями факультативы.

2.Секретарь должен регистрировать студентов факультета для посещения факультативных курсов.

Выделение ключевых абстракций:

Для определения классов можно воспользоваться следующими рекомендациями:

1.Перечислить всех кандидатов в классы, которые есть в описании задачи. Как правило, это имена существительные. Например, для системы РЕГИСТРАТОР к таким кандидатам можно отнести следующие классы: Факультет (Department),

Студент (Student); Курс (Course); Факультативный курс (ElectiveSubject); Факультатив (Facultative); Преподаватель (Teacher); Регистрация (Registration).

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения

2.Добавить кандидатов в классы из анализа предметной области: Университет55

(University); Декан (Dean).

3.Отказаться от всех ненужных классов согласно следующим критериям:

3.1.Избыточные классы: если два класса выражают одну и ту же информацию, сохранить класс с более подробным описанием (Факультатив – название читаемого предмета, Факультативный курс – название читаемого предмета, количество лекционных часов, количество часов лабораторных занятий, количество часов практических занятий).

3.2.Несоответствующие объекты: если объект имеет немного или ничего, чтобы решить проблему, этот объект должен быть устранѐн (Декан).

3.3.Неопределѐнные объекты: объекты с неточно определяемыми свойствами должны быть устранены.

3.4.Атрибуты: названия, которые описывают конкретные объекты с нечѐтко выраженным поведением, должны быть заявлены как атрибуты, а не как объек-

ты (Курс).

3.5.Операции: если название описывает операцию, которая применяется к объекту и не может быть выполнена отдельно от него, то это не объект, и эту операцию следует инкапсулировать в классе объекта (Регистрация).

3.6.Роли: название объекта должно отражать его характер, а не роль, которую он может играть в ассоциации (Декан).

3.7.Элементы реализации: все объекты, отдалѐнные от реальной проблемы, должны быть устранены из модели анализа.

4.1.4. Подготовка словаря системы

Словарь системы (Глоссарий) – это центральное хранилище относящихся к системе абстракций.

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

На начальном этапе Словарь состоит из трѐх основных граф, в которые заносятся: термин, его обозначение в системе и точное описание.

Термин Обозначение Описание

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

Значение Имя класса Имя атрибута Тип атрибута Описание атрибута

по умолчанию

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011