Объектно-ориентированный язык моделирования UML. Объектно-ориентированное моделирование. Методологии моделирования предметной области

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

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

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

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

Онтологический инжиниринг возник в середине 90-ых годов в крупных корпорациях, где проблемы обработки информация приобрели особую остроту и стали критическими. Стало очевидным, что основным узким местом в технологиях корпоративного управления является обработка знаний , накопленных специалистами компании, так как именно знания обеспечивают преимущество перед конкурентами. Так появился термин «Управление Знаниями» или «Менеджмент Знаний» (МЗ). МЗ трактуется как совокупность процессов, которые управляют созданием, распространением, обработкой и использованием информации внутри предприятия.

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

· объектно-ориентированный анализ (Object-Oriented Analysis, OOA),

• объектно-ориентированное проектирование (Object-Oriented Design, OOD),

· объектно-ориентированное программирование (Object-Oriented Programming, OOР).

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

Для реализации ОО-моделей разработан объектно-ориентированный унифицированный язык моделирования (Unified Modeling Language, UML). Он используется для спецификации, визуализации и документирования компонентов объектно-ориентированных информационных (программных) систем во время разработки.

Для моделирования таких систем UML предоставляет свыше десятка типов диаграмм, моделирующих структуру и функционирование («поведение») объектных систем с разных точек зрения. Моделирование начинается с анализа и моделирования предметной области программной системы и разработки требований её пользователей. Разработанный список требований представляется Use-Case-диаграмами UML. Затем моделируется структура системы в форме «структурных» диаграмм:

Диаграмм классов (Class Diagram),

Диаграмм программных компонентов (Component) и

Диаграмм развёртывания программных компонентов на программно-аппаратной платформе (Deployment Diagram).

Динамические свойства системы моделируются набором диаграмм «поведенческих» типов, определяющих

Алгоритмы взаимодействия программных объектов (Sequential- и Collaboration-диаграммы),

Поведение дискретных объектов (Statechart-диаграммы),

Процессы, протекающие в объектной системе (Activity-диаграммы.

В качестве примера на рис. 36 представлены требования пользователей к электронному книжному магазину (в форме Use-Case-диаграмм системы Rational Rose).

Рис 36. Use Case-диаграммы Rose-проекта eBookShop

Рис. 37. Диаграмма классов предметной области Rose-проекта eBookShop

Рис. 38. Полная статическая модель Rose-проекта eBookShop (в форме UML-диаграммы Классов)

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

Методики объектно-ориентированного моделирования совершили коренной переворот в архитектуре современных информационных систем. На смену традиционной архитектуры алгоритмической обработки данных пришла архитектура, базирующаяся на (объектных) моделях (Model-Driven Architecture, MDA).

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

Бурное развитие 1980-ые годы.

Главное не процедура или функция, а объект .

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

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

Появились методы объектно-ориентированного анализа и проектирования OOA/OOD. Они позволяют проектировать системы до написания кода, так чтоб проект был задокументирован. С помощью модели можно исправить недочёты без затрат.

2 вида диаграмм:

1) Структурные модели

2) модели поведения

В дальнейшем UML стал использоваться не столько для проектирования ИС, сколько для анализа и перепроектирования БП.

Моделирование бизнеса с помощью UML предполагает построение двух моделей:

1) прецедентная модель (вопрос 16)

2) объектная модель (анализ структурной модели, описывающийся внешней структурой бизнеса и т.д)(вопрос 17).

Прецедентная модель бизнеса

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

Между прецедентами и акторами устанавливается отношение коммуникации. Они моделируют информационные и материальные потоки, т.е. обмен прецедентов с субъектами окружения материальной и информационной природы (данными, документами, сырьем и т.д.).

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

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

Объектная модель бизнеса.

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

Объекты модели бизнеса представляют людей, участвующих в выполнении процессов, и различного рода, сущности, которые обрабатываются или создаются бизнесом. Участники процессов называются активными объектами, сущности – пассивными. Похожие объекты группируются в классы, каждый конкретный объект рассматривается как экземпляр некоторого класса. Например объекты, соответствующие конкретным служащим могут быть объединены в класс «служащие». Свойство объекта описывается с помощью характеристик, называемых атрибутами, при этом состав атрибутов одинаков для всего класса. Класс «служащий» может иметь атрибуты: фамилия, стаж, и т.д. Разные объекты будут иметь разные значения (которые могут меняться во времени). Поведение представляется с помощью набора операций, которые может выполнять объект. Пример операций класса «служащий»: Принять заказ, оформить договор, принять оплату и т.д.

Виды анализа БП.

Существуют различные классификации видов анализа. Классификация по объекту анализа позволяет выделить:

1. Анализ окружения

~ Анализ макроокружения (Политического, Экономического, технологического)

~ Анализ микроокружения (клиентов, поставщиков, конкурентов)

2. Анализ бизнеса (Продукции, Оборудования, Кадров).

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

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

Классификации в соответствии с анализируемыми состояниями системы (текущим, прошлым, будущим) – позволяет выделить сравнительный, ретроспективный и прогностический анализ.

Классификации по методам анализа – позволяет выделить две основные группы:

· количественный (основан на объективном измерении и дальнейшей обработке количественных параметров)

1) статистический (корреляционный, регрессионный, кластерный)

2) экономический (детерминированный факторный анализ, балансовый)

3) вычислительный (линейное программирование, анализ чувствительности и т.д.)

· качественный анализ (основан на мнениях, субъективных суждениях и оценках экспертов). При этом, как правило, используются неформальные или слабо-формализованные методы, такие как: Методы экспортных оценок, метод ДЭЛФИ, морфологический анализ, метод сценариев и метод построения дерева решений.

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

Концептуальной основой является объектная модель, которая строится с учетом следующих принципов:

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

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

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

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

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

Диаграмма (Diagram) - это графическое представление множества элементов. Чаще всего она изображается в виде связного графа с вершинами (сущностями) и ребрами (отношениями) и представляет собой некоторую проекцию системы.

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

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

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

Сравнение существующих методик

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

Несомненным достоинством функциональных моделей является реализация структурного подхода к проектированию ИС по принципу "сверху-вниз", когда каждый функциональный блок может быть декомпозирован на множество подфункций и т.д., выполняя, таким образом, модульное проектирование ИС . Для функциональных моделей характерны процедурная строгость декомпозиции ИС и наглядность представления.

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

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

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

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

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

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

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

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

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

Любое программирование осуществляется по одному из четырех принципов:

· принцип модульности

· принцип «от общего к частному»

· принцип пошаговости

· принцип структурирования

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

1. размер модуля должен быть ограничен;

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

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

4. входные параметры и результат модуля желательно передавать не через глобальные переменные, а через формальные параметры и результат функции.

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

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

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

· простой последовательности действий;

· конструкции выбора или оператора if;

· конструкции повторения или цикла.

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

· первоначально программа формулируется в виде некоторого неформального действия на естественном языке;

· первоначально определяются входные параметры и результат действия;

· очередной шаг детализации не меняет структуру программы, полученную на предыдущих шагах;

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

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

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

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

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

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

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

Объектно-ориентированный подход к программированию включает в себя 3 основные компоненты:

· объектно-ориентированный анализ (ООА),

· объектно-ориентированное проектирование (ООД),

· объектно-ориентированное программирование (ООП).

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

· удовлетворяет заданным (возможно, неформальным) функциональным спецификациям;

· согласована с ограничениями, накладываемыми оборудованием;

· удовлетворяет явным и неявным требованиям по эксплуатационным качествам и потреблению ресурсов;

· удовлетворяет явным и неявным критериям дизайна продукта;

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

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

Программа - это числовая модель проектируемой системы.(рис. 1.3.1.)

Рис. 1.3.1.

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

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

· условные обозначения - язык для описания каждой модели;

· процесс - правила проектирования модели;

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

Хороший метод проектирования базируется на прочной теоретической основе и при этом дает программисту известную степень свободы самовыражения.

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

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

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

Рис. 1.3.2

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

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

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

PagesCount: integer;

function CompareWithBook(OtherBook: TBook): integer;

procedure ShowTitle;

constructor Create(NewTitle, New

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

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

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

ArCon. Дизайн интерьеров и архитектурное моделирование для всех Кидрук Максим Иванович

Объектно-ориентированное моделирование

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

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

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

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

Применение объектного подхода дает множество преимуществ.

На порядок возрастает скорость создания планов и чертежей.

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

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

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

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

Рис. 1.1. Пример иерархического представления строительного плана, созданного на основе объектного подхода

Примечание

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

Одним из главных, но вовсе не очевидных преимуществ объектно-ориентированного подхода при создании графических изображений является возможность быстрого и полностью автоматического перехода к трехмерному изображению (другими словами, возможность автоматической генерации трехмерной модели спроектированного объекта). С учетом того, что набор объектов, которыми может оперировать пользователь, в любом случае ограничен, а также учитывая то, что в свойствах каждого объекта можно заложить достаточно информации, чтобы получить полное представление о его форме, становится возможным реализация «поднятия» графического изображения в 3D без каких-либо усилий со стороны пользователя (именно такой подход и реализован в системе ArCon). В итоге пользователь почти мгновенно получает трехмерное представление своего проекта, при этом не затратив практически никаких усилий. Полученную трехмерную модель далее можно будет визуализировать и получить реалистичную картинку или передать в другую систему для дальнейшего редактирования или проведения инженерных расчетов. Более того, в таком случае пользователю вообще не нужно никаких специальных навыков трехмерного моделирования.

Примечание

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

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

В первую очередь (и это очевидно) это ограниченность набора готовых объектов, а также невозможность произвольного их изменения. Это отбирает гибкость у программы, из чего следует, что принцип объектного проектирования может быть применен только в специализированных системах (таких, к примеру, как ArCon, Professional Home Design Platinum и пр.). Разработчикам таких систем необходимо основательно учитывать специфику отрасли, для автоматизации и решения задач которой предназначается программный продукт, а также максимально расширять возможность настройки свойств предлагаемых объектов.

Здесь на первый план выходит вопрос стоимости и функционала системы. Если вы на 100 % уверены в том, что та или иная специализированная программа подходит для ваших целей, сомнений при ее покупке не должно возникать. В противном случае вам необходимо более подробно изучить функционал, чтобы убедиться, можно ли будет решать поставленные задачи или же, в худшем случае, придется потратить деньги на «обычный» и дорогой CAD-редактор.

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

Примечание

Забегая наперед, скажу, что проекты ArCon+ 2005 можно экспортировать в различные как двухмерные, так и трехмерные форматы, используя группу команд Файл? Экспортировать в формате (рис. 1.2). Важно отметить, что в программе поддерживаются такие известные форматы обмена данных, как VRML, DXF, формат системы 3ds Max, а также возможность сохранения проекта в выполнимый EXE-файл (подробнее об этом написано далее).

Рис. 1.2. Поддерживаемые форматы для экспорта проектов из ArCon

Еще хуже дело обстоит с импортом данных из других систем. Если они не приведены к определенному формату, «взять» их внутрь объектной специализированной системы невозможно. Скажем, при импорте чертежа из AutoCAD в ArCon может быть загружено лишь изображение. При этом ArCon никак самостоятельно не сможет распознать, где в открытом изображении окна, двери, стены и т. п., и тем более присвоить отдельным объектам вполне разумные свойства. Это значит, что дальнейшее редактирование чертежа в ArCon, как и «поднятие» его в 3D, невозможно. Импортирование, по существу, становится бессмысленным, поэтому преимущественное большинство объектно-ориентированных проектных систем не имеют функций для чтения графических данных извне.

Однако, несмотря на такие существенные недостатки, легкость в работе, а главное – скорость и наглядность выполнения проектов берут верх. Как следствие, в последнее время системы, подобные рассматриваемой в этой книге программе ArCon, нашли широкое применение при решении различных задач проектирования.

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