Меню
ГлавнаяСоцсети

Объектно ориентированное моделирование информационных систем. Объектно- ориентированный подход к моделированию систем. Создание диаграммы классов

· Процедурные языки , которые представляют собой последовательность выполняемых операторов. Если рассматривать состояние ПК как состояние ячеек памяти, то процедурный язык – это последовательность операторов, изменяющих значение одной или нескольких ячеек. К процедурным языкам относятся FORTRAN, C, Ada, Pascal, Smalltalk и некоторые другие. Процедурные языки иногда также называются императивными языками. Код программы на процедурном языке может быть записан следующим образом:

оperator1; operator2; operator3;

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

· function1(function2(

· function3(beginning_date)));

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

Код программы на языке системы правил может быть записан следующим образом:

if condition1 then operator1;

if condition2 then operator2;

if condition3 then operator3;

· Объектно-ориентированные языки , основанные на построении объектов как набора данных и операций над ними. Объектно-ориентированные языки объединяют и расширяют возможности, присущие процедурным и аппликативным языкам. К объектно-ориентированным языкам относятся C++, Object Pascal, Java.

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

ППО - это комплекс прикладных программ, с помощью которых выполняются конкретные задания: производственные, творческие, развлекательные и т. д.

Классификация ПП средств

Текстовые редакторы - основные их функции - ввод и редактирование текстовых данных.

Графические редакторы - обширный класс программ, предназначенных для создания и обработки графических изображений.

Модель визуальная, если она позволяет визуализировать отношения и связи моделируемой системы, особенно в динамике.

Модель натурная, если она есть материальная копия оригинала.

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

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

Есть и другие типы моделей.

Примеры моделей

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

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

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

Основные свойства любой модели:

· целенаправленность;

· конечность;

· упрощенность;

· приблизительность;

· адекватность;

· информативность;

· полнота;

· замкнутость и др.

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

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

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

Компьютерное моделирование от начала и до завершения проходит следующие этапы.

1. Постановка задачи.

2. Предмодельный анализ.

3. Анализ задачи.

4. Исследование модели.

5. Программирование, проектирование программы.

6. Тестирование и отладка.

7. Оценка моделирования.

8. Документирование.

9. Сопровождение.

10. Использование (применение) модели.

При моделировании систем ПО выделяют два подхода: структурное моделирование и объектно-ориентированное моделирование. Каждый из этих подходов использует свои методы и средства. Язык моделирования должен включать: элементы модели , т. е. функциональные концепции моделирования и их семантику, нотацию , т. е. визуальное представление элементов моделирования и руководство по использованию . При моделировании широко используются инструментальные средства, называемые Case -средствами. Case -средство – это технология использования и эксплуатации систем ПО. Case -средство – это программное средство, которое поддерживает процессы жизненного цикла ПО . ЖЦ любого ПО – это период времени от принятия решения о необходимости создания ПО до изъятия ПО из эксплуатации. Все процессы ЖЦ ПО делятся на три группы: основные (5), вспомогательные (8), организационные (4). Для разработки моделей ЖЦ используется стандарт (ISO/IEC 12207). Стадия создания ПО – это часть процесса создания ПО, ограниченная временными рамками и заканчивающаяся выпуском конкретного продукта (модели, программы или документации). В состав ЖЦ ПО включают стадии :

1. Формирование требований к ПО

2. Проектирование

3. Реализация

4. Тестирование

5. Ввод в действие

6. Эксплуатация и сопровождение

7. Снятие с эксплуатации.

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

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

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

ERD – диаграммы сущность – связь . Это самое распространенное средство моделирования данных, которые в процессе проектирования и реализации будут отображены в базу данных. Базовыми понятиями данного средства моделирования являются: сущность, связь и атрибут .

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

Абстракция – это процесс выявления основных характеристик какой-либо сущности, которые отличают ее от других сущностей.

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

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

Иерархия – это ранжирование или упорядочивание системы абстракций. Виды иерархических структур – это структура классов и структура объектов.

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

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

Устойчивость – свойство объекта существовать во времени и/или пространстве.

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

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

Языки моделирования

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

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

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

Объектно-ориентированное программирование

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

Основные концепции ООП

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

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

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

ООП характеризуется следующими принципами (по Алану Кею):

· все является объектом;

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

· каждый объект имеет независимую память , которая состоит из других объектов;

· каждый объект является представителем класса, который выражает общие свойства объектов данного типа;

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

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

Абстрагирование (abstraction) - метод решения задачи, при котором объекты разного рода объединяются общим понятием (концепцией), а затем сгруппированные сущности рассматриваются как элементы единой категории.

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

Инкапсуляция (encapsulation) - техника, при которой несущественная с точки зрения интерфейса объекта информация прячется внутри него.

Наследование (inheritance) - свойство объектов, посредством которого экземпляры класса получают доступ к данным и методам классов-предков без их повторного определения.

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

Полиморфизм (polymorphism) - свойство, позволяющее использовать один и тот же интерфейс для различных действий; полиморфной переменной, например, может соответствовать несколько различных методов.

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

Класс (class) - множество объектов, связанных общностью структуры и поведения; абстрактное описание данных и поведения (методов) для совокупности похожих объектов, представители которой называются экземплярами класса.

Объект (object) - конкретная реализация класса, обладающая характеристиками состояния, поведения и индивидуальности, синоним экземпляра.

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

Основы представления графических данных

Виды компьютерной графики

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

В зависимости от способа формирования изображений компьютерную 2D-графику принято подразделять на растровую, векторную и фрактальную .

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

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

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

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

Растровая графика

Векторная графика

Трехмерная графика

Инженерная графика

Растровая графика

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

Разрешение оригинала;

Разрешение экранного изображения;

Разрешение печатного изображения.

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

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

Мониторы для обработки изображений с диагональю 20-21 дюйм (профессионального класса), как правило, обеспечивают стандартные экранные разрешения 640x480, 800x600, 1024x768, 1280x1024, 1600x1200, 1600x1280, 1920x1200, 1920x1600 точек. Расстояние между соседними точками люминофора у качественного монитора состав­ляет 0,22-0,25 мм.

Для экранной копии достаточно разрешения 72 dpi, для распечатки на цветном или лазерном принтере 150-200 dpi, для вывода на фотоэкспонирующем устройстве 200-300 dpi. Установлено эмпирическое правило, что при распечатке величина разрешения оригинала должна быть в 1,5 раза больше, чем линиатура растра устрой­ства вывода. В случае, если твердая копия будет увеличена по сравнению с ориги­налом, эти величины следует умножить на коэффициент масштабирования.

Разрешение печатного изображения и понятие линиатуры. Размер точки растро­вого изображения как на твердой копии (бумага, пленка и т. д.), так и на экране зависит от примененного метода и параметров растрирования оригинала. При растри­ровании на оригинал как бы накладывается сетка линий, ячейки которой образуют элемент растра . Частота сетки растра измеряется числом линий на дюйм (lines per inch - Ipi ) и называется линиатурой .

Размер точки растра рассчитывается для каждого элемента и зависит от интенсив­ности тона в данной ячейке. Чем больше интенсивность, тем плотнее заполняется элемент растра. То есть, если в ячейку попал абсолютно черный цвет, размер точки растра совпадет с размером элемента растра. В этом случае говорят о 100% заполняемости. Для абсолютно белого цвета значение заполняемости составит 0%. На практике заполняемость элемента на отпечатке обычно составляет от 3 до 98%. При этом все точки растра имеют одинаковую оптическую плотность, в идеале при­ближающуюся к абсолютно черному цвету. Иллюзия более темного тона создается за счет увеличения размеров точек и, как следствие, сокращения пробельного поля между ними при одинаковом расстоянии между центрами элементов растра (рис. 1). Такой метод называют растрированием с амплитудной модуляцией (AM).

Полиграфическое оборудование" href="/text/category/poligraficheskoe_oborudovanie/" rel="bookmark">полиграфического оборудования ; он применяется в основном для художествен­ных работ, при печати с числом красок, превышающим четыре.

Рис.2. Пример использования стохастического растра

Связь между параметрами изображения и размером файла. Средствами растровой графики принято иллюстрировать работы, требующие высокой точности в пере­даче цветов и полутонов. Однако размеры файлов растровых иллюстраций стре­мительно растут с увеличением разрешения. Фотоснимок, предназначенный для домашнего просмотра (стандартный размер 10x15 см, оцифрованный с разрешени­ем 200-300 dpi, цветовое разрешение 24 бита), занимает в формате TIFF с вклю­ченным режимом сжатия около 4 Мбайт. Оцифрованный с высоким разрешением слайд занимает 45-50 Мбайт. Цветоделенное цветное изображение формата А4 занимает 120-150 Мбайт.

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

Рис.3. Эффект пикселезации при масштабировании растрового изображения

Векторная графика

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

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

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

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

Рис. 4. Объекты векторной графики

Математические основы векторной графики

Рассмотрим подробнее способы представления различных объектов в векторной графике.

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

Прямая линия. Ей соответствует уравнение у = kx + b. Указав параметры k и b, всегда можно отобразить бесконечную прямую линию в известной системе коор­динат, то есть для задания прямой достаточно двух параметров.

Отрезок прямой. Он отличается тем, что требует для описания еще двух парамет­ров - например, координат x1 и х2 начала и конца отрезка.

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

x2+a1y2+a2xy+a3x+a4y+а5 = 0.

Таким образом, для описания бесконечной кривой второго порядка достаточно пятя; параметров. Если требуется построить отрезок кривой, понадобятся еще два параметра.

Кривая третьего порядка. Отличие этих кривых от кривых второго порядка состоит в возможном наличии точки перегиба. Например график функции у = x3 имеет точ­ку перегиба в начале координат (рис. 15.5). Именно эта особенность позволяет сде­лать кривые третьего порядка основой отображения природных объектов в век­торной графике. Например линии изгиба человеческого тела весьма близки к кривым третьего порядка. Все кривые второго порядка, как и прямые, являются частными случаями кривых третьего порядка.

В общем случае уравнение кривой третьего порядка можно записать так:

x3 + а1у3 + а2x2у + a3xy2 + a4x2 + а5y2 + а6xy + a7x + а8y + а9 = 0

Таким образом, кривая третьего порядка описывается девятью параметрами. Опи­сание ее отрезка потребует на два параметра больше.

Рис.5. Кривая третьего порядка (слева) и кривая Безье (справа)

Кривые Безье. Это особый, упрощенный вид кривых третьего порядка (с. рис. 5). Метод построения кривой Безье (Bezier ) основан на использовании пары касатель­ных, проведенных к отрезку линии в ее окончаниях. Отрезки кривых Безье описы­ваются восемью параметрами, поэтому работать с ними удобнее. На форму линии влияет угол наклона касательной и длина ее отрезка. Таким образом, касательные играют роль виртуальных «рычагов», с помощью которых управляют кривой.

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


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


Объект Объект – осязаемая реальность, имеющая четко определенное поведение. Объект обладает состоянием, поведением, индивидуальностью Структура и поведение схожих объектов определяют общий для них класс => Объект = экземпляр класса Объект = экземпляр класса"> Объект = экземпляр класса"> Объект = экземпляр класса" title="Объект Объект – осязаемая реальность, имеющая четко определенное поведение. Объект обладает состоянием, поведением, индивидуальностью Структура и поведение схожих объектов определяют общий для них класс => Объект = экземпляр класса"> title="Объект Объект – осязаемая реальность, имеющая четко определенное поведение. Объект обладает состоянием, поведением, индивидуальностью Структура и поведение схожих объектов определяют общий для них класс => Объект = экземпляр класса">


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


Различие между классом и объектом Множество объектов со схожими свойствами (состояние, поведение, индивидуальность) = КЛАСС => Каждый объект = экземпляр класса Каждый объект = экземпляр класса"> Каждый объект = экземпляр класса"> Каждый объект = экземпляр класса" title="Различие между классом и объектом Множество объектов со схожими свойствами (состояние, поведение, индивидуальность) = КЛАСС => Каждый объект = экземпляр класса"> title="Различие между классом и объектом Множество объектов со схожими свойствами (состояние, поведение, индивидуальность) = КЛАСС => Каждый объект = экземпляр класса">


Иерархия классов: Родительский класс обладает фи" title="Принципы ООП. Наследование Наследование – принцип, в соответствии с которым знание о более общей категории разрешается применять для более частной категории Наследованиеиерархия классов Наследование -> иерархия классов: Родительский класс обладает фи" class="link_thumb"> 7 Принципы ООП. Наследование Наследование – принцип, в соответствии с которым знание о более общей категории разрешается применять для более частной категории Наследованиеиерархия классов Наследование -> иерархия классов: Родительский класс обладает фиксированным набором свойств => производный от него класс содержит тот же набор свойств + дополнительные свойства, характеризующие его уникальность иерархия классов: Родительский класс обладает фи"> иерархия классов: Родительский класс обладает фиксированным набором свойств => производный от него класс содержит тот же набор свойств + дополнительные свойства, характеризующие его уникальность"> иерархия классов: Родительский класс обладает фи" title="Принципы ООП. Наследование Наследование – принцип, в соответствии с которым знание о более общей категории разрешается применять для более частной категории Наследованиеиерархия классов Наследование -> иерархия классов: Родительский класс обладает фи"> title="Принципы ООП. Наследование Наследование – принцип, в соответствии с которым знание о более общей категории разрешается применять для более частной категории Наследованиеиерархия классов Наследование -> иерархия классов: Родительский класс обладает фи">




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




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


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


Универсальный язык моделирования UML. Предыстория В начале 90-х гг. 20 века – создание новых объектно-ориентированных языков программирования (Smalltalk, C++, Java) Разработано огромное количество методов проектирования объектно-ориентированного ПО Результат – разработка UML, с целью объединения достоинств различных подходов в один независимый от производителей язык моделирования.


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


Универсальный язык моделирования UML Авторы – Гради Буч (G. Booch), Джим Румбах (или Рамбо, D. Rumbaugh), Айвар Джекобсон (I. Jacobson). Первая версия языка появилась в 1996 г. В настоящее время все вопросы дальнейшей разработки UML сконцентрированы в рамках консорциума OMG. В 2004 г. – UML 2.0.


Диаграммы UML UML включает в себя 8 типов диаграмм: 1) диаграммы вариантов использования; 2) диаграммы классов; 3) диаграммы состояний; 4) диаграммы деятельности; 5) диаграммы кооперации; 6) диаграммы последовательности; 7) диаграммы компонентов; 8) диаграммы развертывания. Диаграммы взаимодействия Диаграммы реализации


Некоторые программные продукты (UML tools) IBM Rational Software Architect (IBM) IBM Rational Rose (IBM) ARIS UML Designer (IDS Sheer) Enterprise Architect (SPARX Software) Altova Umodel KUml, Dia, PowerDesigner И т.д. Подробнее:




Задание Самостоятельно изучить статью «UML basics: An introduction to the Unified Modeling Language»: /library/769.html?S_TACT=105AGX15&S_ CMP=EDU

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru/

Контрольная работа

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

Студент: Филатов Р.Д.

Липецк 2015

Введение

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

Rational Rose 2000 имеет достаточно простой и интуитивно понятный интерфейс пользователя, позволяющий создавать модели сложных программных продуктов с помощью унифицированного языка программирования UML

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

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

Создание диаграммы прецедентов

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

Создание диаграммы последовательности

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

Создание диаграммы сотрудничества

Диаграммы сотрудничества - второй тип диаграмм взаимодействия -Collaboration Diagram - Г. Буч называет диаграммой объектов. Эта диаграмма не акцентирует внимание на последовательности передачи сообщений, она отражает наличие взаимосвязей вообще, то есть на этой диаграмме отражается наличие сообщений от клиентов к серверам. Диаграмма показывает взаимодействие между объектами, а не классами, то есть является мгновенным снимком объектов системы в некотором состоянии. Ведь объекты, в отличие от созданных на этапе проектирования классов, создаются и уничтожаются на всем протяжении работы программы. И в каждый момент имеется конкретная группа объектов, с которыми осуществляется работа. В связи с этим появляются такие понятия, как время жизни и область видимости объектов, которые будут рассмотрены далее.

Создание диаграммы классов

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

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

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

Наконец, применяют комбинацию двух указанных подходов. Для дальнейшей организации классов разрешается вкладывать пакеты друг в друга. На высоком уровне абстракции можно сгруппировать классы по функциональности, создав пакет Security. Внутри него можно создать другие пакеты, сгруппировав отвечающие за безопасность классы по функциональности или по стереотипу. Ознакомившись с классами модели, объединим эти классы в пакеты по стереотипу. Были созданы следующие пакеты: Entities (Сущности), Boundaries (Границы) и Control (Управление). В эти пакеты были помещены советующие им классы (рисунок А.4).

Классы-сущности (entity classes) отражают основные понятия (абстракции) предметной области и, как правило, содержат хранимую информацию. В данный пакет были добавлены класса Вклад и ВкладВалюты.

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

Граничные классы (boundary classes) - позволяют действующему лицу взаимодействовать с системой. Каждому взаимодействию между действующим лицом и вариантом использования должен соответствовать по крайней мере один граничный класс.

Граничные классы (boundary classes) - это классы, которые расположены на границе системы и окружающей среды. Они включают все формы, отчеты, интерфейсы с аппаратурой (такой, как принтеры или сканеры) и интерфейсы с другими системами.

В данной модели была создана диаграмма классов (рисунок А.4) для сценария "Открыть новый вклад".

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

Создание диаграммы состояний для классов и диаграммы компонентов

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

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

Литература

1. Боггс У., Боггс М.. UML и Rational Rose: Пер. с англ. - М.: Издательство "Лори", 2009.- 581 с, ил.

2. Буч Г., Рамбо Д., Джекобсон А. Язык UML для пользователя: Пер. с англ. - М.: ДМК, 2009.- 432 е., ил. (Серия "для программистов").

3. Ларман К. применение UML и шаблонов проектирования: Пер. с англ. - М.: Издательский дом "Вильяме", 2012. - 496 с, ил.

4. Кураев Е.А. Банковские системы: Издательский дом "Глория", 2013.-225 с.,ил (Валютные операции с вкладами)

5. Родионова В.М. Банковские операции: Под ред. Родионовой В.М.,2011 .- 112с, ил (Валютные операции с вкладами)

Размещено на Allbest.ru

...

Подобные документы

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

    курсовая работа , добавлен 23.06.2011

    Этапы разработки объектно-ориентированной модели информационной подсистемы приемной комиссии для учета абитуриентов. Создание диаграмм для моделирования процесса обмена сообщениями между объектами. Порядок генерации программного кода на языке С++.

    курсовая работа , добавлен 29.06.2011

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

    курсовая работа , добавлен 25.06.2011

    Разработка объектно-ориентированной подсистемы складского учета для фирмы "КавказЮгАвто". Краткая характеристика предметной области. Построение диаграмм размещения, прецедентов, последовательности, компонентов и классов. Генерация программного кода C++.

    курсовая работа , добавлен 26.06.2011

    Унифицированный язык моделирования. Методы объектно-ориентированного анализа и проектирования. Создание диаграммы последовательности и диаграммы сотрудничества. Главная диаграмма классов. Добавление связей между классами. Зависимость между пакетами.

    курсовая работа , добавлен 23.06.2011

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

    курсовая работа , добавлен 23.06.2011

    Разработка модели информационной подсистемы для учета заказов клиентов автосервиса с применением языка UML. Создание диаграммы прецедентов, последовательности, сотрудничества и классов, используя методы Rational Rose 2000. Генерация программного кода C++.

    курсовая работа , добавлен 22.06.2011

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

    курсовая работа , добавлен 13.05.2014

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

    курсовая работа , добавлен 21.06.2011

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

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

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

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

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

Оглавление
Оглавление
Предисловие
Глава 1. Объектно-ориентированный подход к моделированию
Необходимость в унифицированном языке описания моделей
Классы, экземпляры и многокомпонентные системы
Использование UML на начальной стадии проектирования
Диаграммы классов
Атрибуты
Поведение
Операции и методы
Абстрактные и конкретные классы. Интерфейсы
Классы и отношения
Ассоциация
Обобщение
Агрегация
Наследование
Полиморфизм
Поведение. Диаграммы состояний
Структурированные классификаторы
Компоненты
События и сигналы
Пакеты
Модель
Глава 2. Объектно-ориентированное моделирование сложных динамических систем на основе формализма гибридного автомата
Активный класс и активный динамический объект
Пакеты и модель
Использование пассивных объектов
Переменные
Типы данных
Скалярные типы
Вещественный тип
Целые типы
Булев тип
Перечислимые типы
Символьные типы
Регулярные типы
Векторы
Матрицы
Массивы
Списки
Комбинированный тип (запись)
Явно определяемые типы
Сигналы
Автоматическое приведение типов
Система уравнений
Карта поведения
Состояния
Переходы
Структурная схема
Объекты
Связи
Регулярные структуры
Наследование классов
Добавление новых элементов описания
Переопределение унаследованных элементов
Полиморфизм
Параметризованные классы
Глава 3. Моделирование гибридных систем и объектно-ориентированный подход в различных пакетах
Моделирование гибридных систем в инструментальных средствах для "больших" ЭВМ
Язык SLAM II
Язык НЕДИС
Гибридные модели в современных инструментах моделирования
Моделирование гибридных систем в пакете Simulink ("блочное моделирование")
Моделирование гибридных систем на языке Modelica ("физическое моделирование")
Гибридное направление
Языки объектно-ориентированного моделирования
Simula-67 и НЕДИС
ObjectMath
Omola
Modelica
Инструменты "блочного моделирования"
Анализ существующих языков ООМ применительно к моделированию сложных динамических систем
Глава 4. Многообъектные модели
Глава 5. Объектно-ориентированное моделирование и объектно-ориентированный анализ
Сложная техническая система
Объектно-ориентированный анализ при разработке сложных технических систем
Объектно-ориентированное моделирование на последующих этапах разработки и сопровождения сложной технической системы
Системно-аналитическая модель как основа "сквозной" технологии проектирования
Литература
Дополнительная литература к главе 1
Дополнительная литература к главе 2
Дополнительная литература к главе 3
Дополнительная литература к главе 4
Дополнительная литература к главе 5
Предметный указатель.

Бесплатно скачать электронную книгу в удобном формате, смотреть и читать:
Скачать книгу Моделирование систем, Объектно-ориентированный подход, Колесов Ю., Сениченков Ю., 2012 - fileskachat.com, быстрое и бесплатное скачивание.

Скачать pdf
Ниже можно купить эту книгу по лучшей цене со скидкой с доставкой по всей России.

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

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

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

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

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

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

Формальное описание предметной области с использованием UML основывается на иерархической структуре модельных представлений (см. рис. 4.5), состоящей из четырех уровней: 1) мета-метамодели; 2) мегамо- дели; 3) модели; 4) объектов.

Рис. 4.5.

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

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

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

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

В рамках языка UML все представления о модели сложной системы фиксируются в виде специальных графических конструкций - диаграмм. В терминах UML определены следующие виды диаграмм (рис. 4.6):

  • диаграмма вариантов использования (Use Case Diagram );
  • диаграмма классов (Class Diagram );
  • диаграммы поведения (Behavior Diagrams );
  • диаграммы реализации (Implementation Diagrams).

Рис. 4.6.

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

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

  • диаграмма состояния (Statechart Diagram );
  • диаграмма деятельности {Activity Diagram);
  • диаграммы взаимодействия {Interaction Diagrams) :
  • - диаграмма последовательности {Sequence Diagram);
  • - диаграмма кооперации {Collaboration Diagram).

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

  • диаграмма компонентов {Component Diagram);
  • диаграмма развертывания {Deployment Diagram).

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

С точки зрения моделирования бизнес-процессов визуальное моделирование в IJML можно представить как некоторый процесс поуровневого спуска от наиболее общей и абстрактной концептуальной модели исходной системы к логической, а затем и к физической модели соответствующей программной системы. Для достижения этих целей сначала строится модель в форме так называемой диаграммы вариантов использования {Use Case Diagram ), которая описывает функциональное назначение системы или, другими словами, то, что система будет делать в процессе своего функционирования. Диаграмма вариантов использования является исходным концептуальным представлением или концептуальной моделью системы в процессе ее проектирования и разработки.

Разработка диаграммы вариантов использования преследует следующие цели:

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

Суть данной диаграммы состоит в следующем: проектируемая система представляется в виде множества сущностей или акторов, взаимодействующих с системой с помощью так называемых вариантов использования. При этом актором {actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая способна служить источником воздействия на моделируемую систему так, как определит сам разработчик. В свою очередь, вариант использования {use case) служит для описания сервисов, которые система предоставляет актору. Другими словами, каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актором. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие акторов с системой.

Основные объекты диаграммы вариантов использования сведены в табл. 4.1.

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

Таблица 4.1

Обозначение

Назначение

Вариант использования

f Проверить состояние (текущего счета ) клиента банка

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

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

Интерфейс

Датчик Устройство считывания шрихкода

Интерфейс служит для спецификации параметров модели, которые видимы извне без указания их внутренней структуры

Примечание

Реализовать в виде отдельной библиотеки стандартных функций

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

Окончание табл. 4.1

Обозначение

Назначение

Отношения на диаграмме вариантов использования

Отношение ассоциации (association relationship)

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

Отношение расширения (extend relationship)

Отношение расширения определяет взаимосвязь экземпляров отдельного варианта использования с более общим вариантом, свойства которого определяются на основе способа совместного объединения данных экземпляров

Отношение обобщения (generalization relationship)


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

Отношение включения (include relationship)


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

Пример диаграммы вариантов использования показан на рис. 4.7.


Рис. 4.7.

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

Не вдаваясь в описание семантики языка UML (она хорошо освещена в соответствующей литературе), приведем лишь результаты объектно-ориентированного анализа, показанные на рис. 4.8-4.12.

Нетрудно заметить, что время как важнейший атрибут любой поведенческой модели присутствует на приведенных диаграммах лишь опосредованно. Это означает, что при анализе поведения (или изменения состояний) возможны лишь качественные оценки типа «не раньше, чем...», «только после того, как...» и т.н. Однако при анализе, например, диаграммы состояний (см. рис. 4.9) естественным образом возникают следующие вопросы: «Как часто поступают заказы?», «Как долго они оформляются?», «Каково соотношение количества автоматизированных рабочих мест (АРМ) и числа менеджеров?», «Какой должна быть производительность сервера?» и т.д. Очевидно, что без привлечения аппарата имитационного моделирования получить ответы на эти вопросы по приведенным диаграммам просто невозможно.


Рис. 4.8.


Рис. 4.9.


Рис. 4.10.


Рис. 4.11.


Рис. 4.12.

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

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

Таблица 4.2

Взаимосвязь объектов диаграмм UML и объектов имитационной модели

Объект диаграммы состояний

Объект имитационной модели

Объект диаграммы вариантов использования

Объект диаграммы состояний

Объект имитационной модели

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