Объектно-ориентированное моделирование: Максим Кидрук. Средства реализации объектно-ориентированной технологии программирования

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

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

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

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

Если принять объектно-ориентированный взгляд на мир, необходимо отве­тить на ряд вопросов. Какая структура должна быть у хорошей объ­ектно-ориентированной архитектуры? Какие артефакты должны быть созданы в процессе работы над проектом? Кто должен создавать их? И, наконец, как оценить результат?

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

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

Технология разработки программных систем, в основу которых положена парадигма представления окружающего мира в виде объектов, являющихся экземплярами соответствующих классов, получила название - объектно-ориентированный анализ и проектирование (ООАП) - OOA&D (Object-Oriented Analysis/Design). В рамках этой технологии язык UML является средством графического представления результатов моделирования не только программного обеспечения, но и более широких классов систем и бизнес-приложений, с использованием объектно-ориентированных понятий. При этом явным образом обеспечивается взаимосвязь между базовыми понятиями для моделей концептуального и физического уровня, достигается масштабируемость моделей, что особенно важно для сложных многоцелевых систем.

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

Учебное пособие содержит: краткое изложение языка 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 для построения наглядной имитационной модели, его средств явно недостаточно. Приведенные абстрактные объекты имитационной модели составляют концептуальную модель функционирования отдела продаж и маркетинга.

· Процедурные языки , которые представляют собой последовательность выполняемых операторов. Если рассматривать состояние ПК как состояние ячеек памяти, то процедурный язык – это последовательность операторов, изменяющих значение одной или нескольких ячеек. К процедурным языкам относятся 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 ) основан на использовании пары касатель­ных, проведенных к отрезку линии в ее окончаниях. Отрезки кривых Безье описы­ваются восемью параметрами, поэтому работать с ними удобнее. На форму линии влияет угол наклона касательной и длина ее отрезка. Таким образом, касательные играют роль виртуальных «рычагов», с помощью которых управляют кривой.

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

Транскрипт

1 Лабораторная работа 4 «Методология объектно-ориентированного моделирования» 1. Цель работы: Ознакомление с основными элементами определения, представления, проектирования и моделирования программных систем с помощью языка UML. 2. Методические указания Лабораторная работа направлена на ознакомление с основными элементами определения, представления, проектирования и моделирования программных систем с помощью языка UML, получение навыков по применению данных элементов для построения объектноориентированных моделей ИС на основании требований. Требования к результатам выполнения лабораторного практикума: модель системы должна содержать: диаграмму вариантов использования; диаграммы взаимодействия для каждого варианта использования; диаграмму классов, позволяющая реализовать весь описанный функционал ИС; объединенную диаграмму компонентов и размещения для классов указать стереотипы; в зависимости от варианта задания диаграмма размещения должна показывать расположение компонентов в распределенном приложении или связи между встроенным процессором и устройствами. 3. Общие сведения об объектном моделировании ИС Существует множество технологий и инструментальных средств, с помощью которых можно реализовать в некотором смысле оптимальный проект ИС, начиная с этапа анализа и заканчивая созданием программного кода системы. В большинстве случаев эти технологии предъявляют весьма жесткие требования к процессу разработки и используемым ресурсам, а попытки трансформировать их под конкретные проекты оказываются безуспешными. Эти технологии представлены CASE-средствами верхнего уровня или CASE-средствами полного жизненного цикла (upper CASE tools или full life-cycle CASE tools). Они не позволяют оптимизировать деятельность на уровне отдельных элементов проекта, и, как следствие, многие разработчики перешли на так называемые CASE-средства нижнего уровня (lower CASE tools). Однако они столкнулись с новой проблемой проблемой организации взаимодействия между различными командами, реализующими проект. Унифицированный язык объектно-ориентированного моделирования Unified Modeling Language (UML) явился средством достижения компромисса между этими подходами. Существует достаточное количество инструментальных средств, поддерживающих с помощью UML жизненный цикл информационных систем, и, одновременно, UML является достаточно гибким для настройки и поддержки специфики деятельности различных команд разработчиков.

2 Создание UML началось в октябре 1994 г., когда Джим Рамбо и Гради Буч из Rational Software Corporation стали работать над объединением своих методов OMT и Booch. В настоящее время консорциум пользователей UML Partners включает в себя представителей таких грандов информационных технологий, как Rational Software, Microsoft, IBM, Hewlett- Packard, Oracle, DEC, Unisys, IntelliCorp, Platinum Technology. UML представляет собой объектно-ориентированный язык моделирования, обладающий следующими основными характеристиками: является языком визуального моделирования, который обеспечивает разработку репрезентативных моделей для организации взаимодействия заказчика и разработчика ИС, различных групп разработчиков ИС; содержит механизмы расширения и специализации базовых концепций языка. UML это стандартная нотация визуального моделирования программных систем, принятая консорциумом Object Managing Group (OMG) осенью 1997 г., и на сегодняшний день она поддерживается многими объектно-ориентированными CASE-продуктами. UML включает внутренний набор средств моделирования, которые сейчас приняты во многих методах и средствах моделирования. Эти концепции необходимы в большинстве прикладных задач, хотя не каждая концепция необходима в каждой части каждого приложения. Пользователям языка предоставлены возможности: строить модели на основе средств ядра, без использования механизмов расширения для большинства типовых приложений; добавлять при необходимости новые элементы и условные обозначения, если они не входят в ядро, или специализировать компоненты, систему условных обозначений (нотацию) и ограничения для конкретных предметных областей. Язык UML Рис. 1. Интегрированная модель сложной системы в нотации языка UML Стандарт UML предлагает следующий набор диаграмм для моделирования: диаграммы вариантов использования (use case diagrams) для моделирования бизнес-процессов организации и требований к создаваемой системе); диаграммы классов (class diagrams) для моделирования статической структуры классов системы и связей между ними;

3 диаграммы поведения системы (behavior diagrams): диаграммы взаимодействия (interaction diagrams): диаграммы последовательности (sequence diagrams) и кооперативные диаграммы (collaboration diagrams) для моделирования процесса обмена сообщениями между объектами; диаграммы состояний (statechart diagrams) для моделирования поведения объектов системы при переходе из одного состояния в другое; диаграммы деятельностей (activity diagrams) для моделирования поведения системы в рамках различных вариантов использования, или моделирования деятельностей; диаграммы реализации (implementation diagrams): диаграммы компонентов (component diagrams) для моделирования иерархии компонентов (подсистем) системы; диаграммы развертывания (deployment diagrams) для моделирования физической архитектуры системы. Диаграммы вариантов использования Понятие варианта использования (use case) впервые ввел Ивар Якобсон и придал ему такую значимость, что в настоящее время вариант использования превратился в основной элемент разработки и планирования проекта. Вариант использования представляет собой последовательность действий (транзакций), выполняемых системой в ответ на событие, инициируемое некоторым внешним объектом (действующим лицом). Вариант использования описывает типичное взаимодействие между пользователем и системой. В простейшем случае вариант использования определяется в процессе обсуждения с пользователем тех функций, которые он хотел бы реализовать. На языке UML вариант использования изображают следующим образом: Рис.2. Вариант использования Действующее лицо (actor) это роль, которую пользователь играет по отношению к системе. Действующие лица представляют собой роли, а не конкретных людей или наименования работ. Несмотря на то, что на диаграммах вариантов использования они изображаются в виде стилизованных человеческих фигурок, действующее лицо может также быть внешней системой, которой необходима некоторая информация от данной системы. Показывать на диаграмме действующих лиц следует только в том случае, когда им действительно необходимы некоторые варианты использования. На языке UML действующие лица представляют в виде фигур: Рис.3. Действующее лицо (актер) Действующие лица делятся на три основных типа:

4 пользователи; системы; другие системы, взаимодействующие с данной; время. Время становится действующим лицом, если от него зависит запуск каких-либо событий в системе. Связи между вариантами использования и действующими лицами В языке UML на диаграммах вариантов использования поддерживается несколько типов связей между элементами диаграммы. Это связи коммуникации (communication), включения (include), расширения (extend) и обобщения (generalization). Связь коммуникации это связь между вариантом использования и действующим лицом. На языке UML связи коммуникации показывают с помощью однонаправленной ассоциации (сплошной линии). Рис.4. Пример связи коммуникации Связь включения применяется в тех ситуациях, когда имеется какой-либо фрагмент поведения системы, который повторяется более чем в одном варианте использования. С помощью таких связей обычно моделируют многократно используемую функциональность. Связь расширения применяется при описании изменений в нормальном поведении системы. Она позволяет варианту использования только при необходимости использовать функциональные возможности другого. Рис.5. Пример связи включения и расширения С помощью связи обобщения показывают, что у нескольких действующих лиц имеются общие черты.

5 Рис.6. Пример связи обобщения Диаграммы взаимодействия (interaction diagrams) Диаграммы взаимодействия (interaction diagrams) описывают поведение взаимодействующих групп объектов. Как правило, диаграмма взаимодействия охватывает поведение объектов в рамках только одного варианта использования. На такой диаграмме отображается ряд объектов и те сообщения, которыми они обмениваются между собой. Сообщение (message) это средство, с помощью которого объект-отправитель запрашивает у объекта получателя выполнение одной из его операций. Информационное (informative) сообщение это сообщение, снабжающее объектполучатель некоторой информацией для обновления его состояния. Сообщение-запрос (interrogative) это сообщение, запрашивающее выдачу некоторой информации об объекте-получателе. Императивное (imperative) сообщение это сообщение, запрашивающее у объектаполучателя выполнение некоторых действий. Существует два вида диаграмм взаимодействия: диаграммы последовательности (sequence diagrams) и кооперативные диаграммы (collaboration diagrams). Диаграмма последовательности (sequence diagrams) Диаграмма последовательности отражает поток событий, происходящих в рамках варианта использования. Все действующие лица показаны в верхней части диаграммы. Стрелки соответствуют сообщениям, передаваемым между действующим лицом и объектом или между объектами для выполнения требуемых функций. На диаграмме последовательности объект изображается в виде прямоугольника, от которого вниз проведена пунктирная вертикальная линия. Эта линия называется линией жизни (lifeline) объекта. Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия. Каждое сообщение представляется в виде стрелки между линиями жизни двух объектов. Сообщения появляются в том порядке, как они показаны на странице сверху вниз. Каждое сообщение помечается как минимум именем сообщения. При желании можно добавить также аргументы и некоторую управляющую информацию. Можно показать самоделегирование (self-delegation) сообщение, которое объект посылает самому себе, при этом стрелка сообщения указывает на ту же самую линию жизни.

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

7 Рис. 8. Пример диаграммы кооперации Диаграммы классов Общие сведения Диаграмма классов определяет типы классов системы и различного рода статические связи, которые существуют между ними. На диаграммах классов изображаются также атрибуты классов, операции классов и ограничения, которые накладываются на связи между классами. Диаграмма классов UML - это граф, узлами которого являются элементы статической структуры проекта (классы, интерфейсы), а дугами - отношения между узлами (ассоциации, наследование, зависимости). На диаграмме классов изображаются следующие элементы: Класс Пакет (package) - набор элементов модели, логически связанных между собой; Класс (class) - описание общих свойств группы сходных объектов; Интерфейс (interface) - абстрактный класс, задающий набор операций, которые объект произвольного класса, связанного с данным интерфейсом, предоставляет другим объектам. Класс - это группа сущностей (объектов), обладающих сходными свойствами, а именно, данными и поведением. Отдельный представитель некоторого класса называется объектом класса или просто объектом. Под поведением объекта в UML понимаются любые правила взаимодействия объекта с внешним миром и с данными самого объекта. На диаграммах класс изображается в виде прямоугольника со сплошной границей, разделенного горизонтальными линиями на 3 секции: Верхняя секция (секция имени) содержит имя класса и другие общие свойства (в частности, стереотип). В средней секции содержится список атрибутов В нижней - список операций класса, отражающих его поведение (действия, выполняемые классом).

8 Любая из секций атрибутов и операций может не изображаться (а также обе сразу). Для отсутствующей секции не нужно рисовать разделительную линию и как-либо указывать на наличие или отсутствие элементов в ней. На усмотрение конкретной реализации могут быть введены дополнительные секции, например, исключения (Exceptions). Стереотипы классов Рис. 9. Пример диаграммы классов Стереотипы классов это механизм, позволяющий разделять классы на категории. В языке UML определены три основных стереотипа классов: Boundary (граница); Entity (сущность); Control (управление). Граничные классы Граничными классами (boundary classes) называются такие классы, которые расположены на границе системы и всей окружающей среды. Это экранные формы, отчеты, интерфейсы с аппаратурой (такой как принтеры или сканеры) и интерфейсы с другими системами. Чтобы найти граничные классы, надо исследовать диаграммы вариантов использования. Каждому взаимодействию между действующим лицом и вариантом использования должен соответствовать, по крайней мере, один граничный класс. Именно такой класс позволяет действующему лицу взаимодействовать с системой. Классы-сущности Классы-сущности (entity classes) содержат хранимую информацию. Они имеют наибольшее значение для пользователя, и потому в их названиях часто используют термины из предметной области. Обычно для каждого класса-сущности создают таблицу в базе данных. Управляющие классы

9 Управляющие классы (control classes) отвечают за координацию действий других классов. Обычно у каждого варианта использования имеется один управляющий класс, контролирующий последовательность событий этого варианта использования. Управляющий класс отвечает за координацию, но сам не несет в себе никакой функциональности, так как остальные классы не посылают ему большого количества сообщений. Вместо этого он сам посылает множество сообщений. Управляющий класс просто делегирует ответственность другим классам, по этой причине его часто называют классом-менеджером. В системе могут быть и другие управляющие классы, общие для нескольких вариантов использования. Например, может быть класс SecurityManager (менеджер безопасности), отвечающий за контроль событий, связанных с безопасностью. Класс TransactionManager (менеджер транзакций) занимается координацией сообщений, относящихся к транзакциям с базой данных. Могут быть и другие менеджеры для работы с другими элементами функционирования системы, такими как разделение ресурсов, распределенная обработка данных или обработка ошибок. Помимо упомянутых выше стереотипов можно создавать и свои собственные. Атрибуты Атрибут это элемент информации, связанный с классом. Атрибуты хранят инкапсулированные данные класса. Так как атрибуты содержатся внутри класса, они скрыты от других классов. В связи с этим может понадобиться указать, какие классы имеют право читать и изменять атрибуты. Это свойство называется видимостью атрибута (attribute visibility). У атрибута можно определить четыре возможных значения этого параметра: Public (общий, открытый). Это значение видимости предполагает, что атрибут будет виден всеми остальными классами. Любой класс может просмотреть или изменить значение атрибута. В соответствии с нотацией UML общему атрибуту предшествует знак «+». Private (закрытый, секретный). Соответствующий атрибут не виден никаким другим классом. Закрытый атрибут обозначается знаком в соответствии с нотацией UML. Protected (защищенный). Такой атрибут доступен только самому классу и его потомкам. Нотация UML для защищенного атрибута это знак «#». Package or Implementation (пакетный). Предполагает, что данный атрибут является общим, но только в пределах его пакета. Этот тип видимости не обозначается никаким специальным значком. В общем случае, атрибуты рекомендуется делать закрытыми или защищенными. Это позволяет лучше контролировать сам атрибут и код. С помощью закрытости или защищенности удается избежать ситуации, когда значение атрибута изменяется всеми классами системы. Вместо этого логика изменения атрибута будет заключена в том же классе, что и сам этот атрибут. Задаваемые параметры видимости повлияют на генерируемый код. Операции Операции реализуют связанное с классом поведение. Операция включает три части имя, параметры и тип возвращаемого значения. Параметры это аргументы, получаемые операцией «на входе». Тип возвращаемого значения относится к результату действия операции.

10 На диаграмме классов можно показывать как имена операций, так и имена операций вместе с их параметрами и типом возвращаемого значения. Чтобы уменьшить загруженность диаграммы, полезно бывает на некоторых из них показывать только имена операций, а на других их полную сигнатуру. В языке UML операции имеют следующую нотацию: Имя Операции (аргумент: тип данных аргумента, аргумент2:тип данных аргумента2,...): тип возвращаемого значения Следует рассмотреть четыре различных типа операций: Операции реализации; Операции управления; Операции доступа; Вспомогательные операции. Операции реализации Операции реализации (implementor operations) реализуют некоторые бизнес-функции. Такие операции можно найти, исследуя диаграммы взаимодействия. Диаграммы этого типа фокусируются на бизнес-функциях, и каждое сообщение диаграммы, скорее всего, можно соотнести с операцией реализации. Каждая операция реализации должна быть легко прослеживаема до соответствующего требования. Это достигается на различных этапах моделирования. Операция выводится из сообщения на диаграмме взаимодействия, сообщения исходят из подробного описания потока событий, который создается на основе варианта использования, а последний на основе требований. Возможность проследить всю эту цепочку позволяет гарантировать, что каждое требование будет реализовано в коде, а каждый фрагмент кода реализует какое-то требование. Операции управления Операции управления (manager operations) управляют созданием и уничтожением объектов. В эту категорию попадают конструкторы и деструкторы классов. Операции доступа Атрибуты обычно бывают закрытыми или защищенными. Тем не менее, другие классы иногда должны просматривать или изменять их значения. Для этого существуют операции доступа (access operations). Такой подход дает возможность безопасно инкапсулировать атрибуты внутри класса, защитив их от других классов, но все же позволяет осуществить к ним контролируемый доступ. Создание операций Get и Set (получения и изменения значения) для каждого атрибута класса является стандартом. Вспомогательные операции Вспомогательными (helper operations) называются такие операции класса, которые необходимы ему для выполнения его ответственностей, но о которых другие классы не должны ничего знать. Это закрытые и защищенные операции класса. Чтобы идентифицировать операции, выполните следующие действия: 1. Изучите диаграммы последовательности и кооперативные диаграммы. Большая часть сообщений на этих диаграммах является операциями реализации. Рефлексивные сообщения будут вспомогательными операциями.

11 2. Рассмотрите управляющие операции. Может потребоваться добавить конструкторы и деструкторы. 3. Рассмотрите операции доступа. Для каждого атрибута класса, с которым должны будут работать другие классы, надо создать операции Get и Set. Связи Связь представляет собой семантическую взаимосвязь между классами. Она дает классу возможность узнавать об атрибутах, операциях и связях другого класса. Иными словами, чтобы один класс мог послать сообщение другому на диаграмме последовательности или кооперативной диаграмме, между ними должна существовать связь. Существуют четыре типа связей, которые могут быть установлены между классами: ассоциации, зависимости, агрегации и обобщения. Ассоциации Ассоциация (association) это семантическая связь между классами. Их рисуют на диаграмме классов в виде обыкновенной линии. Рис. 10. Связь ассоциация Ассоциации могут быть двунаправленными, как в примере, или однонаправленными. На языке UML двунаправленные ассоциации рисуют в виде простой линии без стрелок или со стрелками с обеих ее сторон. На однонаправленной ассоциации изображают только одну стрелку, показывающую ее направление. Направление ассоциации можно определить, изучая диаграммы последовательности и кооперативные диаграммы. Если все сообщения на них отправляются только одним классом и принимаются только другим классом, но не наоборот, между этими классами имеет место однонаправленная связь. Если хотя бы одно сообщение отправляется в обратную сторону, ассоциация должна быть двунаправленной. Ассоциации могут быть рефлексивными. Рефлексивная ассоциация предполагает, что один экземпляр класса взаимодействует с другими экземплярами этого же класса. Зависимости Связи зависимости (dependency) также отражают связь между классами, но они всегда однонаправлены и показывают, что один класс зависит от определений, сделанных в другом. Например, класс A использует методы класса B. Тогда при изменении класса B необходимо произвести соответствующие изменения в классе A. Зависимость изображается пунктирной линией, проведенной между двумя элементами диаграммы, и считается, что элемент, привязанный к концу стрелки, зависит от элемента, привязанного к началу этой стрелки.

12 Рис. 11. Связь зависимость При генерации кода для этих классов к ним не будут добавляться новые атрибуты. Однако, будут созданы специфические для языка операторы, необходимые для поддержки связи. Агрегации Агрегации (aggregations) представляют собой более тесную форму ассоциации. Агрегация это связь между целым и его частью. Например, у вас может быть класс Автомобиль, а также классы Двигатель, Покрышки и классы для других частей автомобиля. В результате объект класса Автомобиль будет состоять из объекта класса Двигатель, четырех объектов Покрышек и т. д. Агрегации визуализируют в виде линии с ромбиком у класса, являющегося целым: Рис. 11. Связь агрегация В дополнение к простой агрегации UML вводит более сильную разновидность агрегации, называемую композицией. Согласно композиции, объект-часть может принадлежать только единственному целому, и, кроме того, как правило, жизненный цикл частей совпадает с циклом целого: они живут и умирают вместе с ним. Любое удаление целого распространяется на его части. Такое каскадное удаление нередко рассматривается как часть определения агрегации, однако оно всегда подразумевается в том случае, когда множественность роли составляет 1..1; например, если необходимо удалить Клиента, то это удаление должно распространиться и на Заказы (и, в свою очередь, на Строки заказа). Обобщения (Наследование) Обобщение (наследование) - это отношение типа общее-частное между элементами модели. С помощью обобщений (generalization) показывают связи наследования между двумя классами. Большинство объектно-ориентированных языков непосредственно поддерживают концепцию наследования. Она позволяет одному классу наследовать все атрибуты, операции и связи другого. Наследование пакетов означает, что в пакетенаследнике все сущности пакета-предка будут видны под своими собственными именами (т.е. пространства имен объединяются). Наследование показывается сплошной линией, идущей от класса-потомка к классу-предку (в терминологии ООП - от потомка к предку, от сына к отцу, или от подкласса к суперклассу). Со стороны более общего элемента рисуется большой полый треугольник.

13 Рис. 12. Пример связи наследование Помимо наследуемых, каждый подкласс имеет свои собственные уникальные атрибуты, операции и связи. Множественность Множественность (multiplicity) показывает, сколько экземпляров одного класса взаимодействуют с помощью этой связи с одним экземпляром другого класса в данный момент времени. Например, при разработке системы регистрации курсов в университете можно определить классы Course (курс) и Student (студент). Между ними установлена связь: у курсов могут быть студенты, а у студентов курсы. Вопросы, на который должен ответить параметр множественности: «Сколько курсов студент может посещать в данный момент? Сколько студентов может за раз посещать один курс?» Так как множественность дает ответ на оба эти вопроса, её индикаторы устанавливаются на обоих концах линии связи. В примере регистрации курсов мы решили, что один студент может посещать от нуля до четырех курсов, а один курс могут слушать от 0 до 20 студентов. В языке UML приняты определенные нотации для обозначения множественности. Таблица 1 - Обозначения множественности связей в UML Имена связей Связи можно уточнить с помощью имен связей или ролевых имен. Имя связи это обычно глагол или глагольная фраза, описывающая, зачем она нужна. Например, между классом Person (человек) и классом Company (компания) может существовать ассоциация. Можно задать в связи с этим вопрос, является ли объект класса Person клиентом компании, её

14 сотрудником или владельцем? Чтобы определить это, ассоциацию можно назвать «employs» (нанимает): Роли Рис. 13. Пример имен связей Ролевые имена применяют в связях ассоциации или агрегации вместо имен для описания того, зачем эти связи нужны. Возвращаясь к примеру с классами Person и Company, можно сказать, что класс Person играет роль сотрудника класса Company. Ролевые имена это обычно имена существительные или основанные на них фразы, их показывают на диаграмме рядом с классом, играющим соответствующую роль. Как правило, пользуются или ролевым именем, или именем связи, но не обоими сразу. Как и имена связей, ролевые имена не обязательны, их дают, только если цель связи не очевидна. Пример ролей приводится ниже: Пакет. Механизм пакетов Рис. 14. Пример ролей связей В контексте диаграмм классов, пакет - это вместилище для некоторого набора классов и других пакетов. Пакет является самостоятельным пространством имен. Рис. 15. Обозначение пакета в UML В UML нет каких-либо ограничений на правила, по которым разработчики могут или должны группировать классы в пакеты. Но есть некоторые стандартные случаи, когда такая группировка уместна, например, тесно взаимодействующие классы, или более общий случай - разбиение системы на подсистемы. Пакет физически содержит сущности, определенные в нем (говорят, что "сущности принадлежат пакету"). Это означает, что если будет уничтожен пакет, то будут уничтожено и все его содержимое. Существует несколько наиболее распространенных подходов к группировке. Во-первых, можно группировать их по стереотипу. В таком случае получается один пакет с классами-сущностями, один с граничными классами, один с управляющими классами и т.д. Этот подход может быть полезен с точки зрения размещения готовой системы, поскольку все находящиеся на клиентских машинах пограничные классы уже оказываются в одном пакете.

15 Другой подход заключается в объединении классов по их функциональности. Например, в пакете Security (безопасность) содержатся все классы, отвечающие за безопасность приложения. В таком случае другие пакеты могут называться Employee Maintenance (Работа с сотрудниками), Reporting (Подготовка отчетов) и Error Handling (Обработка ошибок). Преимущество этого подхода заключается в возможности повторного использования. Механизм пакетов применим к любым элементам модели, а не только к классам. Если для группировки классов не использовать некоторые эвристики, то она становится произвольной. Одна из них, которая в основном используется в UML, это зависимость. Зависимость между двумя пакетами существует в том случае, если между любыми двумя классами в пакетах существует любая зависимость. Таким образом, диаграмма пакетов представляет собой диаграмму, содержащую пакеты классов и зависимости между ними. Строго говоря, пакеты и зависимости являются элементами диаграммы классов, то есть диаграмма пакетов это форма диаграммы классов. Рис. 16. Пример диаграммы пакетов Зависимость между двумя элементами имеет место в том случае, если изменения в определении одного элемента могут повлечь за собой изменения в другом. Что касается классов, то причины для зависимостей могут быть самыми разными: один класс посылает сообщение другому; один класс включает часть данных другого класса; один класс использует другой в качестве параметра операции. Если класс меняет свой интерфейс, то любое сообщение, которое он посылает, может утратить свою силу. Пакеты не дают ответа на вопрос, каким образом можно уменьшить количество зависимостей в вашей системе, однако они помогают выделить эти зависимости, а после того, как они все окажутся на виду, остается только поработать над снижением их количества. Диаграммы пакетов можно считать основным средством управления общей структурой системы. Пакеты являются жизненно необходимым средством для больших проектов. Их следует использовать в тех случаях, когда диаграмма классов, охватывающая всю систему в целом и размещенная на единственном листе бумаги формата А4, становится нечитаемой. Диаграммы состояний Диаграммы состояний определяют все возможные состояния, в которых может находиться конкретный объект, а также процесс смены состояний объекта в результате наступления некоторых событий. Существует много форм диаграмм состояний, незначительно отличающихся друг от друга семантикой. На диаграмме имеются два специальных состояния начальное (start) и конечное (stop). Начальное состояние выделено черной точкой, оно соответствует состоянию объекта,

16 когда он только что был создан. Конечное состояние обозначается черной точкой в белом кружке, оно соответствует состоянию объекта непосредственно перед его уничтожением. На диаграмме состояний может быть одно и только одно начальное состояние. В то же время, может быть столько конечных состояний, сколько вам нужно, или их может не быть вообще. Когда объект находится в каком-то конкретном состоянии, могут выполняться различные процессы. Процессы, происходящие, когда объект находится в определенном состоянии, называются действиями (actions). С состоянием можно связывать данные пяти типов: деятельность, входное действие, выходное действие, событие и история состояния. Деятельность Деятельностью (activity) называется поведение, реализуемое объектом, пока он находится в данном состоянии. Деятельность это прерываемое поведение. Оно может выполняться до своего завершения, пока объект находится в данном состоянии, или может быть прервано переходом объекта в другое состояние. Деятельность изображают внутри самого состояния, ей должно предшествовать слово do (делать) и двоеточие. Входное действие Входным действием (entry action) называется поведение, которое выполняется, когда объект переходит в данное состояние. Данное действие осуществляется не после того, как объект перешел в это состояние, а, скорее, как часть этого перехода. В отличие от деятельности, входное действие рассматривается как непрерываемое. Входное действие также показывают внутри состояния, ему предшествует слово entry (вход) и двоеточие. Выходное действие Выходное действие (exit action) подобно входному. Однако, оно осуществляется как составная часть процесса выхода из данного состояния. Оно является частью процесса такого перехода. Как и входное, выходное действие является непрерываемым. Выходное действие изображают внутри состояния, ему предшествует слово exit (выход) и двоеточие. Поведение объекта во время деятельности, при входных и выходных действиях может включать отправку события другому объекту. В этом случае описанию деятельности, входного действия или выходного действия предшествует знак «^». Соответствующая строка на диаграмме выглядит как Do: ^Цель.Событие (Аргументы) Здесь Цель это объект, получающий событие, Событие это посылаемое сообщение, а Аргументы являются параметрами посылаемого сообщения. Деятельность может также выполняться в результате получения объектом некоторого события. При получении некоторого события выполняется определенная деятельность. Переходом (Transition) называется перемещение из одного состояния в другое. Совокупность переходов диаграммы показывает, как объект может перемещаться между своими состояниями. На диаграмме все переходы изображают в виде стрелки, начинающейся на первоначальном состоянии и заканчивающейся последующим.

17 Переходы могут быть рефлексивными. Объект может перейти в то же состояние, в котором он в настоящий момент находится. Рефлексивные переходы изображают в виде стрелки, начинающейся и завершающейся на одном и том же состоянии. У перехода существует несколько спецификаций. Они включают события, аргументы, ограждающие условия, действия и посылаемые события. События Событие (event) это то, что вызывает переход из одного состояния в другое. Событие размещают на диаграмме вдоль линии перехода. На диаграмме для отображения события можно использовать как имя операции, так и обычную фразу. Большинство переходов должны иметь события, так как именно они, прежде всего, заставляют переход осуществиться. Тем не менее, бывают и автоматические переходы, не имеющие событий. При этом объект сам перемещается из одного состояния в другое со скоростью, позволяющей осуществиться входным действиям, деятельности и выходным действиям. Ограждающие условия Ограждающие условия (guard conditions) определяют, когда переход может, а когда не может осуществиться. В противном случае переход не осуществится. Ограждающие условия изображают на диаграмме вдоль линии перехода после имени события, заключая их в квадратные скобки. Ограждающие условия задавать необязательно. Однако если существует несколько автоматических переходов из состояния, необходимо определить для них взаимно исключающие ограждающие условия. Это поможет читателю диаграммы понять, какой путь перехода будет автоматически выбран. Действие Действием (action), как уже говорилось, является непрерываемое поведение, осуществляющееся как часть перехода. Входные и выходные действия показывают внутри состояний, поскольку они определяют, что происходит, когда объект входит или выходит из него. Большую часть действий, однако, изображают вдоль линии перехода, так как они не должны осуществляться при входе или выходе из состояния. Действие рисуют вдоль линии перехода после имени события, ему предшествует косая черта. Событие или действие могут быть поведением внутри объекта, а могут представлять собой сообщение, посылаемое другому объекту. Если событие или действие посылается другому объекту, перед ним на диаграмме помещают знак «^».

18 Рис. 17. Пример диаграммы состояний Диаграммы состояний не надо создавать для каждого класса, они применяются только в сложных случаях. Если объект класса может существовать в нескольких состояниях и в каждом из них ведет себя по-разному, для него может потребоваться такая диаграмма. Диаграммы размещения Диаграмма размещения (deployment diagram) отражает физические взаимосвязи между программными и аппаратными компонентами системы. Она является хорошим средством для того, чтобы показать маршруты перемещения объектов и компонентов в распределенной системе. Каждый узел на диаграмме размещения представляет собой некоторый тип вычислительного устройства в большинстве случаев, часть аппаратуры. Эта аппаратура может быть простым устройством или датчиком, а может быть и мэйнфреймом. Диаграмма размещения показывает физическое расположение сети и местонахождение в ней различных компонентов. Рис. 19. Пример диаграммы размещения Диаграмма размещения используется менеджером проекта, пользователями, архитектором системы и эксплуатационным персоналом, чтобы понять физическое размещение системы и расположение её отдельных подсистем.

19 Диаграммы компонентов Диаграммы компонентов показывают, как выглядит модель на физическом уровне. На них изображены компоненты программного обеспечения и связи между ними. При этом на такой диаграмме выделяют два типа компонентов: исполняемые компоненты и библиотеки кода. Каждый класс модели (или подсистема) преобразуется в компонент исходного кода. После создания они сразу добавляются к диаграмме компонентов. Между отдельными компонентами изображают зависимости, соответствующие зависимостям на этапе компиляции или выполнения программы. Рис. 18. Пример диаграммы компонентов Диаграммы компонентов применяются теми участниками проекта, кто отвечает за компиляцию системы. Из нее видно, в каком порядке надо компилировать компоненты, а также какие исполняемые компоненты будут созданы системой. На такой диаграмме показано соответствие классов реализованным компонентам. Она нужна там, где начинается генерация кода. Объединение диаграмм компонентов и развертывания В некоторых случаях допускается размещать диаграмму компонентов на диаграмме развертывания. Это позволяет показать какие компоненты выполняются и на каких узлах. 4. Порядок выполнения работы 1. Изучить предлагаемый теоретический материал. 2. Постройте диаграмму вариантов использования для выбранной информационной системы. 3. Выполните реализацию вариантов использования в терминах взаимодействующих объектов и представляющую собой набор диаграмм: диаграмм классов, реализующих вариант использования; диаграмм взаимодействия (диаграмм последовательности или кооперативных диаграмм), отражающих взаимодействие объектов в процессе реализации варианта использования. 4. Разделить классы по пакетам использую один из механизм разбиения.

20 5. Постройте диаграмму состояний для конкретных объектов информационной системы. 6. Построить отчёт, включающий все полученные уровни модели, описание функциональных блоков, потоков данных, хранилищ и внешних объектов.

ФЕДЕРАЛЬНОЕ АГЕНСТВО ПО ОБРАЗОВАНИЮ КЕМЕРОВСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ Кафедра ЮНЕСКО по Новым информационным технологиям А.М. Гудов, С.Ю. Завозкин, С.Н. Трофимов ТЕХНОЛОГИЯ РАЗРАБОТКА ПРОГРАММНОГО

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

ОСНОВНЫЕ СВЕДЕНИЯ О ЯЗЫКЕ UML СРЕДСТВА UML Унифицированный язык моделирования UML (Unified Modeling Language) представляет собой язык для определения, представления, проектирования и документирования программных

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

Лекция 2.1 Язык UML. Диаграммы вариантов использования 1. Язык UML Содержание 2. Диаграммы вариантов использования Вариант использования Актеры Отношения 3. Пример диаграммы вариантов использования Графическая

Федеральное агентство железнодорожного транспорта филиал федерального государственного бюджетного образовательного учреждения высшего профессионального образования «Сибирский государственный университет

CASE технологии Лекция 5 1 Язык UML: виды диаграмм UML 1.5 определял двенадцать типов диаграмм, разделенных на три группы: четыре типа диаграмм представляют статическую структуру приложения; пять представляют

Глава 1. Основные сведения о языке UML Самое лучшее средство это большая диаграмма, приколотая к стене. Даг Скотт 1.1. Цели и история создания языка UML Унифицированный язык моделирования UML (Unified

12_Этапы проектирования ИС с применением UML Основные типы UML-диаграмм, используемые в проектировании информационных систем. Взаимосвязи между диаграммами. Поддержка UML итеративного процесса проектирования

Конспект по языку UML Составитель Лейченок Е.А. гр.521701 Унифицированный язык моделирования (Unified Modeling Language, UML) является графическим языком для визуализации, специфицирования, конструирования

Лабораторная работа 1 «Диаграмма вариантов использования» Оглавление Понятие языка UML... 3 Диаграмма вариантов использования (usecase diagram)... 6 Вариант использования... 7 Актеры... 7 Интерфейсы...

Лекция 3 часть 6: Элементы графической нотации диаграммы компонентов Аннотация: Назначение диаграммы компонентов, ее основные элементы. Особенности физического представления программных систем. Компоненты

Лабораторная работа Диаграмма вариантов использования Цель работы:. Знакомство с основными понятиями UML 2. Знакомство со средой моделирования Rational Rose 3. Изучение компонентов модели 4. Построение

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ СТАВРОПОЛЬСКИЙ ГОСУДАРСТВЕННЫЙ АГРАРНЫЙ УНИВЕРСИТЕТ Экономический факультет Кафедра информационных систем УТВЕРЖДАЮ

UML диаграммы Диаграмма классов (2) Диаграмма прецедентов (22) Диаграмма активности (35) Диаграмма взаимодействия (51) Диаграмма классов Класс (class) - категория вещей, которые имеют общие атрибуты и

Диаграммы взаимодействия объектов в UML В данной статье рассматриваются во всех подробностях диаграммы сотрудничества (collaboration diagram) и диаграммы последовательности взаимодействия (sequence diagram)

CASE технологии Лекция 4 1 Язык UML: предыстория середина 1970-х конец 1980-х годов Появление и расцвет объектно-ориентированного проектирования (ООП) «Война методов» проектирования середина 1990-х годов

Лекция 3 часть2: Отношения и их графическое изображение на диаграмме классов Ключевые слова: UML, ассоциация, association relationship, обобщение, generalization relationship, агрегация, композиция, представление,

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

ОбАн и ПРС Лекция 1 стр 1 из 7 Графические примитивы UML стандарта Парадигмы UML стандарта А Словарь языка Б Правила над словарем В Механизмы Словарь языка Сущности Поведенческие сущности Группирующие

Лабораторная работа 2 «Диаграмма классов» Оглавление Общее понятие... 3 Класс... 3 Атрибуты... 4 Операция... 6 Отношения между классами... 7 Отношение зависимости... 7 Отношение ассоциации... 8 Отношение

Лабораторная работа 3 «Диаграмма состояний и диаграмма деятельности» Оглавление ДИАГРАММА СОСТОЯНИЙ... 3 Общее понятие... 3 Состояние... 4 Переход... 6 Составное состояние и подсостояние... 8 Примеры диаграмм

Объектно-ориентированный анализ и дизайн Copyright Мухортов В. В., Няньчук-Татарский Н. А., 2001-2004 Copyright ООО «Интекс», 2003-2004 Классы Class набор объектов с общей структурой и поведением Interface

ЛАБОРАТОРНАЯ РАБОТА 4 РАЗРАБОТКА ФИЗИЧЕСКОГО ПРЕДСТАВЛЕНИЯ ПРОЦЕССА ФУНКЦИОНИРОВАНИЯ ПРОГРАММНОГО СРЕДСТВА С ИСПОЛЬЗОВАНИЕМ UML 1 Цель занятия Научиться формировать диаграммы компонентов и диаграммы развертывания

Федеральное агентство связи Федеральное государственное образовательное бюджетное учреждение высшего профессионального образования ПОВОЛЖСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ТЕЛЕКОММУНИКАЦИЙ И ИНФОРМАТИКИ

Цель: Лабораторная работа 7: Основы UML Целью данной работы является знакомство с базовыми приёмами проектирования систем и процессов с использованием универсального языка моделирования (UML) Задание:

Золотов Сергей Юрьевич к.т.н., доцент кафедры АСУ Проектирование информационных систем Вебинар 3 «Суть объектно-ориентированного подхода к проектированию информационных систем» План вебинара Смысл объектно-ориентированного

ПРОГРАММНАЯ ИНЖЕНЕРИЯ РЕАЛИЗАЦИЯ ПРЕЦЕДЕНТОВ РАДЧЕНКО Г.И., КАФЕДРА СП ЮУРГУ АНАЛИЗ ПРЕЦЕДЕНТА Аналитическая модель классов это статическая структура системы, а реализация прецедентов показывает, как взаимодействуют

Предисловие Введение в UML и UP Что такое UML? Что такое UML? Рождение UML MDA - будущее UML Почему «унифицированный»? Объекты и UML Структура UML Строительные блоки UML Общие механизмы UML Архитектура

Лабораторная работа 4 «Введение в Rational Unified Process. Паттерны» Цель работы научиться разрабатывать модели потока работ; понять место данной модели при определении функций разрабатываемой системы

CASE-СРЕДСТВА РАЗРАБОТКИ ИНФОРМАЦИОННОГО ОБЕСПЕЧЕНИЯ САПР Лекция 5 «Разработка требований к информационному обеспечению» Объектно-ориентированный подход ООП основан на представлении предметнойобласти задачи

UML - Universal Modelling Language общие сведения UML - Universal Modelling Language универсальный язык моделирования предназначен для создания унифицированных описаний моделей системных объектов. Его

Санкт-Петербургский государственный университет информационных технологий, механики и оптики Описание самостоятельной работы студентов (СРС) «Анализ и проектирование на UML» Новиков Ф.А., Канд. физ.-мат.

1 1.Введение... 3 2. Основы... 4 3. Типы диаграмм... 5 3.1 Диаграмма вариантов использования (Use-case diagram). 5 3.2 Диаграмма последовательностей (Sequence diagram)... 13 3.3 Диаграмма классов... 19

Лекция 2.5 Диаграмма развертывания. Диаграмма синхронизации 1 Диаграмма развертывания (deployment diagram) 2 1.1 Артефакт 3 1.2 Узел 3 1.3 Соединения 5 1.3.1 Отношения зависимости 6 1.4 Рекомендации по

ЛАБОРАТОРНЫЕ РАБОТЫ ПО КУРСУ ТЕОРИЯ ИНФОРМАЦИОННЫХ ПРОЦЕССОВ И СИСТЕМ 1. Цель работы ЛАБОРАТОРНАЯ РАБОТА 4 Создание диаграмм взаимодействия Получить навыки построения диаграмм последовательности и кооперации

ПРОГРАММНАЯ ИНЖЕНЕРИЯ ОБЪЕКТНО-ОРИЕНТИРОВАННЫЙ АНАЛИЗ РАДЧЕНКО Г.И., КАФЕДРА СП ЮУРГУ АНАЛИЗ ПРЕЦЕДЕНТА Деятельность UP «Анализ прецедента» включает: создание классов анализа реализации прецедентов Классы

Глава 5 Моделирование бизнес-процессов Основные положения Для анализа проблем в среде IS/IT наиболее подходящим является метод моделирования бизнес-процессов. Модель бизнес-процесса помогает нам при определении

Содержание Предисловие 19 Введение 21 Образовательные и Web-ресурсы 22 Для кого предназначена эта книга 22 Что необходимо знать 22 Примеры на языке Java 22 Структура книги 23 Об авторе 23 Контакты 24 Дополнения

Графические диаграммы агентов SObjectizer Борис Сивко Intervale 2007.11.20 Содержание 1 Введение 1 2 Типы диаграмм 2 3 Диаграмма операций 2 3.1 Используемые элементы.................... 2 3.1.1 Агенты..........................

ПРОГРАММНАЯ ИНЖЕНЕРИЯ Классы анализа РАДЧЕНКО Г.И., КАФЕДРА СП ЮУРГУ ОБЪЕКТНО-ОРИЕНТИРОВАННОЕ ПРОЕКТИРОВАНИЕ ПОСРЕДСТВОМ UML РАДЧЕНКО Г.И., КАФЕДРА СП ЮУРГУ 2 НОТАЦИЯ ОБЪЕКТОВ UML Прямоугольник с двумя

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

Моделирование потоков 1 Моделирование потоков В основе данной методологии (методологии Gane/Sarson) лежит построение модели анализируемой ИС проектируемой или реально существующей. В соответствии с методологией

РАЗРАБОТКА ИС Жизненный цикл ИС Определение 1: Жизненный цикл ИС это процесс ее построения и развития. Определение 2: Жизненный цикл ИС период времени, который начинается с момента принятия решения о необходимости

Моделирование данных Модель «сущность-связь» Рассматриваемые вопросы: Элементы модели «сущность-связь» Диаграммы «сущность-связь» Слабые сущности Подтипы сущностей Рассматриваемые вопросы: Пример ER-диаграммы

Министерство образования Республики Беларусь Учреждение образования «Белорусский государственный университет информатики и радиоэлектроники» Кафедра электронных вычислительных машин А. В. Отвагин, Н. А.

ГОУ ВПО Владимирский государственный университет имени Александра Григорьевича и Николая Григорьевича Столетовых ЯЗЫК ВИЗУАЛЬНОГО МОДЕЛИРОВАНИЯ UML Методические указания к курсовой работе по дисциплине

Лабораторная работа 3 УПРАВЛЕНИЕ ТРЕБОВАНИЯМИ К АВТОМАТИЗИРОВАННЫМ СИСТЕМАМ С ПОМОЩЬЮ IBM RATIONAL REQUISITE PRO. СОЗДАНИЕ СЦЕНАРИЕВ ИСПОЛЬЗОВАНИЯ Цель работы: разработка сценариев использования программного

Министерство образования и науки Российской Федерации Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования «Владимирский государственный университет имени

Лекция 2 Средства моделирования бизнес-процессов 2.1 Введение BPMN (Business Process Modeling Notation) графическая нотация для моделирования бизнес-процессов. BPMN была разработана Business Process Management

КАЗАНСКИЙ (ПРИВОЛЖСКИЙ) ФЕДЕРАЛЬНЫЙ УНИВЕРСИТЕТ ИНСТИТУТ ВЫЧИСЛИТЕЛЬНОЙ МАТЕМАТИКИ И ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ Визуальное моделирование систем в StarUML Казань 2013 УДК 004.4"22 519.682.6 Печатается по

Вичугова Анна Александровна, ассистент кафедры автоматики и компьютерных систем Института кибернетики ТПУ. E-mail: [email protected] Область научных интересов: бизнес-моделирование, структурный анализ, базы

ФЕДЕРАЛЬНОЕ АГЕНТСТВО СВЯЗИ Федеральное государственное бюджетное образовательное учреждение высшего образования «ПОВОЛЖСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ТЕЛЕКОММУНИКАЦИЙ И ИНФОРМАТИКИ» Кафедра информационных

Метаязык построения визуальных языков моделирования Л.Н. Лядова, А.О. Сухов Пермский государственный университет [email protected], [email protected] Введение С увеличением числа требований к адаптируемым

ПРОГРАММНАЯ ИНЖЕНЕРИЯ АНАЛИЗ И ПРОЕКТИРОВАНИЕ РАДЧЕНКО Г.И., КАФЕДРА СП ЮУРГУ ПРОЕКТИРОВАНИЕ ПО РАДЧЕНКО Г.И., КАФЕДРА СП ЮУРГУ 2 ЧТО ТАКОЕ ПРОЕКТИРОВАНИЕ ПО? Проектирование ПО это осознанный выбор решений

Лабораторная работа 7. ДИАГРАММЫ ПОСЛЕДОВАТЕЛЬНОСТИ. Диаграмма последовательностей показывает последовательность, в которой объекты в процессе взаимодействия обмениваются сообщениями. Схемы последовательностей

Тема: ПОДХОДЫ К ПРОЕКТИРОВАНИЮ СЛОЖНЫХ СИСТЕМ. Методика Джексона. Содержание: введение структурное программирование. методика Джексона "10 правил" 1. Введение В настоящий момент во всем мире наиболее широко