Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
PiRIS_mobile.docx
Скачиваний:
0
Добавлен:
01.07.2025
Размер:
2 Мб
Скачать
☆

19. Объяснить назначение классов и применение отношений: ассоциация, зависимость, композиция и конкретизация между классами модельного примера "Гирлянда из цветных лампочек". (113)

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

На основе рассмотренных отношений между классами, приведем пример (рис. 4.19) полной иерархии классов проекта «Гирлянда из цветных лампочек» (Garland Application) [18].

На рис. 4.19 представлен вариант определения класса ColorableObject на основе интерфейса IColorable. Проиллюстрируем на этом примере основную идею, лежащую в основе концепции интерфейса. Цветом могут характеризоваться не только лампочки, но и самые разнообразные объекты.

В рамках программной модели было бы неплохо иметь какой-нибудь вполне унифицированный механизм работы с такими объектами. Интерфейс IColorable, «в кооперации» с типом – перечислением ColorEnum, предоставляет простейшую модель такого механизма. Тип ColorEnum содержит элементы перечисления, которые мы будем использовать для идентификации цвета. Интерфейс IColorable использует этот тип для определения сигнатур двух методов SetColor() и GetColor(), которые должен поддерживать любой объект, характеризуемый цветом.

В такой интерпретации класс ColoredLight может трактоваться как разновидность ColorableObject.

Можно реализовать и другие разновидности ColorableObject.

Графически отношение реализации изображается пунктирной линией с полой стрелкой, направленной от сущности (класса), обеспечивающей реализацию, к сущности, определяющей контракт, то есть, к интерфейсу.

Рис.4.19. Диаграмма классов GarlandApplication

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

void SetWhite (IColorable * arg)

{ arg -> SetColor (WHITE); }

В данный метод, в качестве параметра, можно передать указатель на любой объект, который поддерживает интерфейс IColorable.

В заключение отметим, что большинство современных языков программирования поддерживают интерфейсы в виде встроенных средств языка (включая Java, C#, Visual C++.Net with Managed Extentions). Язык С++ напрямую не поддерживает интерфейсы, однако эквивалентная

20. Что является источниками классов предметной области, каковы типичные приемы и методы выявления и моделирования классов. Привести пример классов интернет-системы бронирования авиабилетов. (116, 162)

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

До сих пор мы использовали классы для определения бизнес – объектов. Все приведенные нами примеры классов относились к долгоживущим (постоянным или перманентным) сущностям бизнес – процессов, таким как: Личность, Компания, Курс, Студент, Заказ, Товар и т.д. Это классы, которые определяют модель базы данных для прикладной области. По этой причине подобные классы часто называют классами – сущностями (entity classes) или модельными классами. Они представляют постоянно хранимые объекты базы данных.

Классы – сущности определяют существо любой информационной системы, поэтому понадобится определить классы – сущности для отдельных таблиц и различных смешанных запросов, включающих обращение сразу к нескольким таблицам. Начиная с этого момента, эти сущности просто моделируются как классы. Можно использовать стереотип <<table>>, если сущности представляют какие-либо таблицы, или вообще не указывать стереотип, если необходимо обозначить какой-то собственный (пользовательский) класс.

Анализ функциональных требований направлен преимущественно на выявление классов – сущностей. Однако для функционирования системы требуются также и другие типы классов. Пользователям системы, например, необходимы классы, которые определяют GUI – объекты (такие как экранные формы интерактивного диалога), называемые пограничными классами (boundary classes) (классами представления –view classes). Основной задачей интерфейсных классов является абстрагирование системы от прямого взаимодействия с внешними системами.

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

Лучшими источниками классов являются: высокоуровневое описание задачи, низкоуровневые требования и экспертная оценка задачи и предметной области.

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

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

Диаграмма классов интернет-системы бронирования авиабилетов

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]