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

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

Для операций – название, назначение, тип и параметры (с указанием их типов).

Для отношений – полюсы, направление и описание отношения.

Словарь системы постепенно уточняется путѐм:

−Введения новых абстракций.

−Исключения лишних абстракций.

−Объединения схожих абстракций.

Создание Глоссария даѐт три существенных выигрыша:

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

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

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

4.1.5. Пример (продолжение)

Глоссарий (на текущий момент) системы РЕГИСТРАТОР:

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

4.1.6. Создание структуры

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

Любое взаимодействие объектов указывает на наличие отношения между классами. Отношения могут обозначать:

1.Физическое расположение. Один объект является частью другого (Университет

– Факультет).

2.Направленные действия. Один объект воздействует на другой. В системе АРЕНДАТОР оплаченный клиентом счѐт № 123 инициирует генерацию и отправку клиенту счѐта-фактуры № 123Ф, подтверждающую оплату.

3.Связь. Один объект связан с другим (Преподаватель – Факультативный курс).

4.Права владения. Один объект является хозяином другого. Например, НОД 1 Октябрьской железной дороги владеет вагоном № 64084356.

5.Удовлетворение некоторого условия. Один объект запрашивает состояние дру-

гого объекта. Например, если вагон № 64084356 неисправный, то отправить в ремонт.

Идентификация ассоциаций производится следующим образом:

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

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

3.Для каждой из определѐнных ассоциаций задать мощность и имена ролей (особенно если это помогает понять модель).

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

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

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

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

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

абстракции или имеют различную значимость. Обобщение и зависимость – односторонние ассоциации.

4.1.7. Пример (продолжение)

Идентификация отношений для системы РЕГИСТРАТОР:

Университет – Факультет. Один университет состоит из одного или более факультетов. Факультеты не могут существовать без своего университета.

Факультет – Студент. На одном факультете обучается много студентов. Факультет не может существовать без своих студентов. Факультеты в какой-то степени определяются своими студентами. В то же время студенты связаны со своим факультетом, и в какой-то мере он формирует их облик.

Факультет – Преподаватель. На каждом факультете должен быть хотя бы один преподаватель.

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

Студент – Факультативный курс. Каждый студент может посещать любое число дополнительных курсов или не посещать их совсем. На каждый такой курс может приходить не более десяти студентов.

Преподаватель – Факультативный курс. Каждый преподаватель может вести не более трѐх дополнительных курсов, в том числе и ни одного. Для каждого курса должен быть хотя бы один преподаватель.

Структурные отношения для системы РЕГИСТРАТОР показаны на концептуальной диаграмме классов (рис.4-2).

Рис. 4-2.

Концептуальная диаграмма классов системы РЕГИСТРАТОР

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

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

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

Для создания хорошей модели анализа необходимо помнить:

1.Модель анализа должна быть ПРОСТОЙ.

2.Модель анализа всегда использует язык предметной области. Абстракции должны формировать часть словаря бизнеса в соответствии с принятой в предметной области терминологией.

3.Каждая диаграмма должна раскрывать отдельную важную часть поведения системы.

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

5.Необходимо стремиться к минимизации связанности, так как каждая ассоциация между классами увеличивает связанность объектов.

6.Если присутствует естественная и очевидная иерархия абстракций, то использовать обобщение. Наследование (как механизм реализации обобщения) – самая сильная форма связанности классов.

7.Модель анализа должна быть понятной всем заинтересованным лицам: пользователям, заказчикам, аналитикам-проектировщикам и тестерам.

Рабочий поток анализа в RUP показан на рис.4-3.

Рис.4-3. Рабочий

4.2. Объектно-ориентированное проектирование

Объектно-ориентированное проектирование (OOD) направлено на создание моделей программных абстракций. Основой для создания модели проектирования служит модель анализа (рис. 4-4).

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

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

Рис. 4-4. Связь анализа и

рования

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

Цель проектирования – определить то, как будет реализовываться функциональность, выявленная на этапе анализа.

OOD так же, как и ООА использует принципы объектной абстракции и декомпозиции, и решает следующие основные задачи:

1.Определение логических программных классов.

2.Определение атрибутов и операций логических программных объектов.

3.Создание статической логической модели системы.

4.Создание динамической логической модели системы.

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

4.2.1. Определение программных классов

Большинство классов, которые должны участвовать в программном решении, определены в диаграммах классов этапа анализа и занесены в Глоссарий.

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

На этапе проектирования детально прорабатываются следующие абстракции:

1.Классы для управления последовательностью событий. Как правило, для каждого прецедента существует (как минимум) один управляющий класс.

2.Классы, моделирующие сущности предметной области.

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