Моделирование и проектирование информационных систем

Учебно-методическое пособие

 

Пермь 2007

УДК 004.41
ББК 32.97
Ш14

Шаврин С.М.

Ш14 Моделирование и проектирование информационных систем: учеб.-метод. пособие / С.М. Шаврин, Л.Н. Лядова, С.И. Чуприна; Перм. гос. ун‑т.– Пермь, 2007. – 152 с.: ил.

ISBN 5-7944-1035-3

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

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

Рецензент – доктор физико-математических наук, профессор, директор учебного центра «Информатика» С.В. Русаков

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

УДК 004.41
ББК 32.97

ISBN 5-7944-1035-3 © Шаврин С.М., Лядова Л.Н., Чуприна С.И., 2007
© Пермский государственный университет, 2007

СОДЕРЖАНИЕ

I. Организационно-методический раздел.. 5

Цели и задачи курса. 5

Требования к уровню освоения содержания курса. 5

Место курса в системе основной образовательной программы 6

II. Содержание курса.. 6

Связь между разделами. 6

Конспект лекций по курсу. 7

Раздел 1. Введение. 7

Тема 1.1. Понятие информационной системы.. 7

Тема 1.2. Проблемы сложных задач. 8

Раздел 2. Введение в теорию моделирования. 11

Тема 2.1. Понятие моделирования и модели. Принципы моделирования и классификация моделей 11

Тема 2.2. Метамоделирование. 19

Тема 2.3. Классификация информационных систем
по уровню и составу моделей. 25

Раздел 3. Жизненный цикл программного
обеспечения. 30

Тема 3.1. Понятие жизненного цикла.
Процессы жизненного цикла. 30

Тема 3.2. Модели жизненного цикла. 35

Раздел 4. Структурный подход. 38

Тема 4.1. Сущность и основные принципы
структурного подхода. 38

Тема 4.2. Метод функционального моделирования SADT. 41

Тема 4.3. Моделирование потоков данных. 44

Тема 4.4. Моделирование структур данных. 48

Раздел 5. Объектный подход. 53

Тема 5.1. Сущность и основные принципы объектного
подхода. 53

Тема 5.2. Пример объектно-ориентированного анализа и проектирования 56

Раздел 6. Унифицированный язык моделирования
UML. 61

Тема 6.1. Обзор языка UML. 61

Тема 6.2. Моделирование функциональных требований и диаграммы прецедентов 66

Тема 6.3. Моделирование бизнес-процессов и диаграммы активностей 80

Тема 6.4. Концептуальное моделирование и
диаграммы понятий. 86

Тема 6.5. Моделирование поведения системы и диаграмма последовательностей 103

Тема 6.6. Проектирование поведения системы и
диаграммы сотрудничества. 112

Тема 6.7. Проектирование статической структуры
системы и диаграмма классов. 123

Тема 6.8. Модель реализации и диаграмма компонентов. 128

Тема 6.9. Модель и диаграмма развертывания. 132

Раздел 7. Шаблоны проектирования. 135

Тема 7.1. Введение в шаблоны проектирования. 135

Тема 7.2. Шаблоны проектирования GRASP.. 137

Учебное задание. 144

Примерный перечень вопросов к зачету по всему
курсу. 144

Вопрос для государственного экзамена. 145

III. Примерное распределение часов курса
по формам и видам работ.. 146

IV. Форма итогового контроля.. 149

V. Учебно-методическое обеспечение
курса.. 149

Рекомендуемая литература (обязательная) 149

Рекомендуемая литература (дополнительная) 149

 

I. Организационно-методический раздел

Цели и задачи курса

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

Задачи курса:

– введение в теорию моделирования;

– обзор и сравнение основных подходов к разработке программного обеспечения;

– обзор языка UML, его средств и возможностей;

– изучение языка UML применительно к моделированию и проектированию информационных систем;

– приобретение опыта использования языка UML на различных этапах жизненного цикла информационных систем.

Требования к уровню освоения
содержания курса

При изучении курса студенты должны:

– получить базовые навыки использования языка UML на различных этапах жизненного цикла информационных систем;

– научиться «читать» чужие модели;

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

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

Кроме того, студенты должны усвоить основные концепции объектно-ориентированного проектирования.

Место курса в системе основной
образовательной программы

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

Полученные знания и навыки будут востребованы при выполнении курсовых и выпускных квалификационных работ.

II. Содержание курса

Связь между разделами

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

Конспект лекций

Раздел 1. Введение

Тема 1.1. Понятие информационной системы

Тематический контекст

Краткое содержание

1. Понятие информационной системы.

2. Основные задачи, стоящие перед разработчиком информационной системы.

3. Основной критерий качества информационной системы.

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

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

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

Здесь стоит обратить внимание на то, что информационная система работает с данными. Сразу возникает вопрос: а почему она информационная? Где информация? Ответ на этот вопрос прост. Информация извлекается из данных при их обработке. Собственно, основным назначением информационной системы является предоставление возможности извлечения информации из массива данных. Качество информационной системы в первую очередь определяется тем, насколько быстро и просто можно получить необходимую пользователю информацию. Все остальное вторично.

Вопросы для самоконтроля

1. Что такое информационная система?

2. Какие задачи стоят перед разработчиком информационной системы?

3. В чем разница между данными и информацией?

4. Каков основной критерий качества информационной системы?

Тема 1.2. Проблемы сложных задач

Тематический контекст

Краткое содержание

1. Проблема разбиения.

2. Проблема языка.

3. Проблема процесса.

4. Понятия методологии и технологии.

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

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

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

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

Прежде чем продолжить рассуждения, дадим определения методологии и технологии.

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

Определение. Технология – определённая последовательность действий, средства и инструменты для достижения желаемого результата; способ преобразования данного в необходимое. Технология применяет научные достижения на практике. Целью технологии является производство продукта: материальная технология создает материальный продукт, информационная технология – информационный продукт.

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

– анализ – исследование проблемы (а не поиск ее решения);

– проектирование – поиск логического решения задачи, обеспечивающего выполнение основных требований;

– реализация – конструирование системы в соответствии с логическим решением;

– тестирование – поиск и устранение ошибок.

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

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

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

Вопросы для самоконтроля

1. В чем заключается суть проблемы разбиения?

2. В чем заключается суть проблемы языка?

3. В чем заключается суть проблемы процесса?

4. Чем методология отличается от технологии?

Раздел 2. Введение в теорию моделирования

Тема 2.1. Понятие моделирования и модели.
Принципы моделирования и классификация
моделей

Тематический контекст

Краткое содержание

1. Понятие моделирования как метода научного познания.

2. Понятие модели, свойства модели, разделение моделей на материальные и идеальные.

3. Четыре принципа моделирования. Классификация моделей: по точке зрения на систему, по Бучу, по степени абстракции.

4. Классификация моделей.

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

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

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

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

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

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

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

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

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

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

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

2. Модель всегда «хуже» объекта-оригинала, она всегда является некоторым его упрощением.

Приведенное выше определение модели является слишком общим. Уточним понятие модели для задачи моделирования информационных систем.

Определение. Модель – это абстрактное описание на некотором формальном языке некоторых аспектов системы, важных с точки зрения цели моделирования.

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

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

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

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

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

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

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

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

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

– статические – описывают структурные свойства;

– динамические – описывают поведенческие свойства;

– функциональные – описывают функциональные свойства.

Эти три вида моделей представляют собой три ортогональных взгляда на систему, но в то же время они связаны между собой (рис. 1).

Рис. 1. Классификация моделей по точке зрения на систему

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

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

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

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

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

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

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

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

Рис. 2. Классификация Буча

Модель прецедентов – охватывает прецеденты, которые описывают поведение системы, наблюдаемое конечными пользователями, аналитиками и тестировщиками.

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

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

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

Модель развертывания – охватывает узлы, формирующие топологию аппаратных средств системы, на которых она выполняется.

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

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

– модели спецификации – определяют внешний вид и внешнее поведение системы;

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

Необходимо четко представлять разницу между этими моделями. Рассмотрим пример. На рис. 3 представлены три модели человека. Атрибут «Имя» на концептуальной модели (рис. 3, а) означает, что у человека есть имя. Причем имеется в виду человек из предметной области. На модели спецификации (рис. 3, б) тот же самый атрибут «Имя» означает, что класс «Человек» может сообщить имя и имеется механизм его обновления, т.е. в данном случае атрибут соответствует понятию свойства из языков программирования, однако нет никакой информации о том, как это свойство реализуется. И только на модели реализации (рис. 3, в) мы видим, что свойство «Имя» реализуется при помощи скрытого поля и двух методов доступа.

Если говорить о диаграммах классов языка UML, которые использовались в примере выше (рис. 3), то по их внешнему виду, как правило, удается определить, какая модель имеется в виду. На концептуальных моделях обычно отсутствуют операции, а также информация о видимости атрибутов и их типах. В модели спецификации добавляются операции и информация о типах, однако видимость по-прежнему не указывается, т.к. предполагается, что везде она «public». В модели реализации отображаются все члены класса – как скрытые (private, protected), так и открытые (public). Подробнее о диаграммах классов смотрите в соответствующих разделах пособия.

А б в

Рис. 3. Пример моделей человека
а – концептуальная модель, б – модель спецификации, в – модель реализации

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

Вопросы для самоконтроля

1. Что такое модель?

2. Каково основное свойство модели?

3. Когда нужно применять модель?

4. В чем особенность моделирования информационных систем?

5. Каковы основные принципы моделирования и в чем их суть?

6. Как модели можно классифицировать?

Тема 2.2. Метамоделирование

Тематический контекст

Краткое содержание

1. Понятие метамодели.

2. Разделение метамоделей на лингвистические и онтологические, связь между ними.

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

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

Рис. 4. Организация и ее модель

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

Рис. 5. Другие модели организации

Определение. Метамодель – это модель языка моделирования.

Исходя из данного определения все модели на рис. 4 и 5 являются простыми моделями. Все они моделируют исходную организацию, а также друг друга (более абстрактные модели можно считать моделями более подробных). Тогда возникает вопрос: а где же метамодель?

Заметим, что все модели на рис. 4 и 5 описаны при помощи одного и того же языка. Если их проанализировать, то можно выделить всего три элемента: объект, связь и слот. Объекты и связи были рассмотрены выше, а примером слота является количество сотрудников в модели на рис. 5 на правой модели. Если смоделировать этот язык, то получится метамодель. Пример метамодели представлен на рис. 6.

Рис. 6. Пример метамодели

На рис. 6 используется нотация диаграмм классов, которые подробно рассматриваются далее. Здесь ограничимся лишь кратким комментарием. Прямоугольник соответствует классу и состоит из трех разделов: имя, раздел атрибутов и раздел операций. Сплошные линии обозначают ассоциации, а цифры определяют множественность («*» означает «много»).

Рис. 7. Пример метамодели

Вернемся к моделям на рис. 4 и 5. Если продолжить их анализ, то можно выделить еще одну группу понятий: организация, подразделение и сотрудник. Это тоже язык, который можно смоделировать. На рис. 7 представлена метамодель, в терминах которой можно описать все три модели на рис. 4 и 5. Ромбы на концах ассоциаций обозначают отношения типа «часть–целое» (закрашенный ромб – это более сильная связь).

Подведем итог. Для некоторой организации были построены три модели и две метамодели. Все три модели похожи друг на друга в том смысле, что все они описывают исходную организацию, только с различной степенью детализации. Метамодели же принципиально различны. Первая метамодель (рис. 6) описывает предметно-независимый язык, а вторая метамодель (рис. 7) – предметно-зависимый язык. Такие метамодели называют лингвистическими и онтологическими соответственно.

Определение. Лингвистическая метамодель – это метамодель, которая описывает предметно-независимый язык моделирования.

Определение. Онтологическая метамодель – это метамодель, которая описывает предметно-зависимый язык моделирования.

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

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

Вернемся еще раз к рис. 6. Метамодель на этом рисунке моделирует язык, на котором можно описывать только «плоские модели». Действительно, предоставляется, по сути, единственная абстракция «объект», при помощи которой предлагается описывать задачу. Все объекты равноправны и, следовательно, находятся на одном уровне. На практике же удобно иметь возможность описывать сразу несколько онтологических уровней модели.

На рис. 8 приведен пример многоуровневого онтологического моделирования. Пунктирная стрелка означает отношение «Класс–Экземпляр» и указывает на класс. Полый треугольник на конце сплошной линии означает обобщение и указывает на более общее понятие.

Рис. 8. Пример многоуровневого онтологического
моделирования

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

Определение. Метакласс – это класс, экземплярами которого являются другие классы.

Определение. Класс – это совокупность объектов, обладающих схожей структурой, поведением и семантикой.