Дж. Рамбо, М. Блаха - UML 2.0 - Объектно-ориентированное моделирование и разработка, страница 8

Современные вычислительные возможности позволяют моделировать многие физические структуры в компьютере, не создавая реальных моделей. Такое моделирование не только оказывается дешевле, но и дает дополнительные данные, которые сложно или невозможно измерить в физической модели. Физические и компьютерные модели стоят дешевле реальной системы и при этом позволяют выявить и устранить недостатки на ранних этапах проектирования. 2.

Взаимодействие с заказчиками. Архитекторы и дизайнеры создают модели, которые затем показывают своим заказчикам. Это демонстрационные модели, имитирующие (частично или полностью) внешнее поведение системы. 3. Визуализация. Раскадровка фильмов, телешоу и рекламных роликов позволяет сценаристам увидеть воплощение их идей. Они могут исправить неудачные переходы, устранить незавершенные линии и избыточные сегменты перед тем, как начать проработку более детального сценария. Эскизы дают художникам возможность набросать свои замыслы вчерне и внести необходимые изменения перед тем, как воплощать их в масле или камне. 4.

Уменьшение сложности. Основное назначение моделирования, включающее все предыдущие пункты, состоит в там, что оно позволяет работать с системами, которые являются слишком сложными для непосредственного изучения. Человеческий мозг может обрабатывать лишь ограниченный объем информации в единицу времени. Модели уменьшают сложность реальных систем, выделяя ограниченный набор важнейших свойств. 2.2. Абстрагирование Абстрагирование — это выборочное изучение некоторых аспектов проблемы. Цель абстрагирования состоит в том, чтобы изолировать аспекты, важные для некоторой цели, и избавиться от всех остальных. Абстрагирование всегда должно иметь цель, поскольку именно она определяет, что является важным, а что нет.

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

Хорошая модель описывает важнейшие аспекты проблемы и опускает все прочие. Большинство компьютерных языков плохо подходят для моделирования алгоритмов, потому что онн требуют указания деталей реализации, несущественных 36 Глава 2 ° Моделирование как методика проектирования для алгоритмов. Модель, содержащая избыточные детали, ограничивает ваш выбор при проектировании и отвлекает ваше внимание от важнейших аспектов. 2.3. Три модели Нам кажется полезным моделировать систему с трех различных точек зрения, связанных между собой.

Каждая модель описывает важные аспекты системы, но для более полного описания требуются все три модели. Модель классов представляет статические, структурные аспекты системы, связанные с данными. Модель состояний представляет временные, поведенческие, управленческие аспекты системы. Модель взаимодействия представляет кооперацию отлельных объектов, другими словами, все аспекты системы, связанные с взаимодействиями. Типичная процедура в программе обладает всеми тремя аспектами: она использует структуры данных (модель классов), упорядочивает операции во времени (модель состояний) и передает данные и управление между объектами (молель взаимодействия).

Каждая модель содержит ссылки на сущности из других моделей. Например, модель классов связывает операции с классами, тогда как модели состояний и взаимодействия конкретизируют операции. Модели трех типов дают различные представления системы. Модели не являются абсолютно независимыми, потому что система представляет собой нечто большее, нежели объединение независимых частей, однако каждая модель в значительной степени может быть проанализирована и понята сама по себе. Связи между моделями ограничены и выражены явным образом. Разумеется, всегда можно создать такой плохой проект, в котором три модели окажутся настолько переплетены друг с другом, что их невозможно будет разделить. Хороший проект разделяет разные аспекты системы и ограничивает связь между ними.

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

2.3.1. Модель классов Модель классов (с!авз шоде!) описывает структуру объектов системы; их индивидуальность, отношения с другими объектами, атрибуты и операции. Модель классов создает контекст для моделей состояний и взаимодействия. Изменения и взаимодействия не имеют смысла, если отсутствует изменяющийся объект или взаимодействующие объекты. Объекты (оЪ)ессз) — это блоки, на которые мы разбиваем наш мир, молекулы нашей модели. Цель конструирования модели классов состоит в том, чтобы охватить те реальные концепции, которые важны для нашего приложения.

При моделировании инженерной задачи модель классов должна содержать термины, знакомые инженерам. 2.3. Три модели 37 При моделировании бизнес-задачи должны использоваться термины нз бизнеса. Молель пользовательского интерфейса должна быть выражена в терминах приложения. Аналитическая модель не должна содержать компьютерных конструкций, если только моделируемое приложение не является чисто компьютерным, как, например, компилятор или операционная система. Проектная модель описывает возможности решения задачи, а потому может содержать компьютерные конструкции.

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

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

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

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

Операции в модели классов связаны 38 Глава 2 ° Моделирование как методика проектирования 2.4. Резюме Модели являются абстракциями и создаются для того, чтобы лучше понять задачу, перед тем как приступать к ее решению. Любая абстракция является подмножеством реальности, выбранным с некоторой целью. Мы рекомендуем использовать модели трех типов. Модель классов описывает статическую структуру в терминах классов и отношений межлу ними. Модель состояний описывает управляющую структуру системы в терминах событий и состояний.

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