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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Транскрипт

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. Введение В настоящий момент во всем мире наиболее широко

Михаил Васильев, Игорь Хомков, Сергей Шаповаленко

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

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

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

Сложность решаемой задачи;

Сложность разработки ИС;

Сложность обеспечения таких параметров, как адекватность, масштабируемость, надежность, экономическая эффективность и безопасность;

Сложность описания отдельных подсистем ИС.

Объективные оценки может дать применение технологий моделирования. Построение модели, ее анализ и получение ответов на вопросы “что будет, если...?” позволяют спрогнозировать поведение ИС в различных ситуациях. Наиболее часто применяются стендовое макетирование и построение компьютерных моделей ИС.

В настоящее время на рынке инструментов моделирования информационных систем определились три лидера. Это американские компании MIL3 (система моделирования OPNET), Make Systems (система NetMaker XA) и CACI Products Company (система COMNET). На рис. 1 приведено главное окно системы OPNET. (В PC Week/RE, № 34/98, с. 36 на рис. 2 приведено окно графического представления результатов в системе OPNET.) Остановимся на одной из этих систем и на подходе, в ней реализованном, подробнее.

Технология моделирования ИС c использованием COMNET III

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

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

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

Рис. 1. Главное окно системы OPNET

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

Подход к построению моделей в COMNET III может быть представлен в виде стандартной последовательности шагов:

Описание топологии ИС и определение параметров оборудования;

Описание источников трафика и их поведения, описание загрузки сети;

Определение сценария моделирования.

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

Как уже говорилось, граничные условия для декомпозиции ИС зависят от требуемого уровня абстракции. Абстрагирование позволяет разработчику, создающему проект ИС, или системному администратору, осуществляющему ее сопровождение, отделить наиболее существенные особенности ее поведения от того, как именно они реализуются. “Хорошей является такая абстракция, при которой подчеркиваются существенные для рассмотрения и использования детали и опускаются те, которые на данный момент несущественны или отвлекают внимание”*1. Так, в одной ситуации при описании компьютера достаточно определить его как источник трафика, не вдаваясь в подробное описание архитектуры, в другой же может потребоваться детальное рассмотрение таких его характеристик, как, скажем, количество процессоров и параметров дисковой подсистемы.

*1. Shaw M. Abstraction Techniquest in Modern Programming Languages. - IEEE Software, Oct. 1984, v. 1(4), p.10.

В системе COMNET полностью применим объектно-ориентированный метод декомпозиции, что позволяет существенно сократить сроки моделирования и сделать его процесс интуитивно-понятным, четко коррелирующим с реальной системой. Модель создается из объектов, своего рода “строительных блоков”, знакомых пользователю из опыта реальной жизни. С системой COMNET поставляется большая библиотека таких объектов - моделей реального сетевого оборудования и методов доступа к среде. Рассмотрим подробнее объектную модель COMNET (рис. 2).

Рис. 2. Базовая библиотека классов COMNET III

Объекты в этой системе могут быть разделены на два класса: используемые, во-первых, для описания топологии и, во-вторых, для описания трафика и характеристик загрузки сети. Базовый экран COMNET III с набором библиотечных классов приведен на рис. 3.

Рис. 3. Основной экран системы COMNET

Описание топологии в COMNET III

Такие основные понятия топологии в системе COMNET III, как узлы, соединения, дуги, были описаны в PC Week/RE, № 34/98, с. 34.

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

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

Класс узлов наследуют четыре новых класса.

Класс “Компьютер и узел связи” (C&C Node, Computer and Communications Node)

Эти объекты могут служить источниками или приемниками трафика, а также применяются для моделирования сложных программных систем, учитывающих загрузку процессора и дисковых подсистем. Узлы ИС, описанные с помощью C&C Node, могут быть использованы и для моделирования программных маршрутизаторов.

Класс “Группа компьютеров” (Computer Group Node)

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

Класс “Маршрутизатор” (Router Node)

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

Класс “Коммутатор” (Switch Node)

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

Объекты классов C&C Node, Computer Group Node и Router node для моделирования сложных программных систем включают репозиторий команд, использующих такие уже упомянутые свойства объектов, как характеристики дисковой подсистемы. В постоянно обновляющуюся библиотеку объектов различных классов, входящих в состав COMNET, включен широкий спектр моделей реально существующих аппаратных устройств.

Объект link наследует два новых объекта.

Класс “Соединение точка - точка” (Point-to-Point Link)

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

Класс “Множественный доступ” (Multiaccess link)

Полем для применения этого класса являются ситуации, когда несколько узлов имеют доступ к одной среде передачи данных. В свою очередь, этот объект наследуется рядом новых объектов, описывающих конкретные факты реализации метода доступа к среде, такие, как Carrier Detection, Token Passing, SONET и т. п. (см. рис. 2).

До сих пор мы рассматривали случаи, когда родительский объект наследуется одним объектом-потомком. Однако объектно-ориентированный подход предусматривает и более сложные ситуации с множественным наследованием. Эта форма наследования также применима в системе COMNET. Здесь множественное наследование использовано при создании объектов таких важных классов, как Транзитная сеть (Transit Network) и “Облако” (WAN Cloud).

Оба класса являются наследниками двух родительских классов - Subnet и Link. Форма наследования изображена на рис. 2. Рассмотрим этот вариант подробнее.

Класс “Подсеть” (Subnet)

Исключительно важный класс. Используемый для создания иерархических топологий ИС, он позволяет корректно описывать подсети с различными алгоритмами маршрутизации, причем независимые от алгоритма, применяемого на магистрали. Кроме того, подсети используются, чтобы скрыть излишнюю детализацию при моделировании сложных ИС. В COMNET с их помощью описываются системы с произвольной глубиной вложения. Соединения между внутренней топологией подсети и топологией магистрали осуществляются с помощью точек доступа (access points), число которых может быть произвольным (см. рис. 3).

Класс “Транзитная сеть” (Transit Net)

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

Класс “Облако” (WAN Cloud)

Объекты этого класса, позволяющие создавать абстрактные представления для глобальных сетей, также наследуют свойства объектов-родителей - Subnet и Link. С точки зрения топологии объект WAN Cloud функционирует подобно объекту “соединение”, его пиктограмма подключается непосредственно к узлам. С точки зрения внутренней структуры облако состоит из набора виртуальных соединений (virtual circuit) и каналов доступа (access links), разновидности соединения точка - точка для моделирования глобальных сетей.

Описание трафика и загрузки сети в COMNET III

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

COMNET предоставляет широкий спектр средств для описания трафика.

Класс “Сообщение” (Message)

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

Класс “Отклик” (Response)

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

Класс “Вызов” (Call)

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

Класс “Сессия” (Session)

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

Отметим также, что в COMNET III применяются так называемые файлы описания внешнего трафика (external traffic files), получить которые можно с помощью различных анализаторов трафика.

Особый интерес представляют объекты класса “Приложение” (Application), являющегося результатом множественного наследования классов Message, Response, Call и Session (см. рис. 2). Его объекты позволяют наиболее гибко описывать в рамках модели рабочую загрузку сети и поведение источников трафика. Более того, при их использовании могут быть легко смоделированы практически любые виды программных систем, в том числе распределенных, таких, как СУБД, почтовые системы и пр.

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

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

Transport Message (передать сообщение). Эта команда представляет собой результат наследования объекта классом Application родительского объекта класса Message.

Setup (установить) - результат наследования класса Session.

Answer Message (ответить на сообщение) является наследником класса Response.

Filter Message (фильтровать сообщения). Эта команда позволяет приостановить все операции, описанные в объекте класса Application, до тех пор, пока не будет получено сообщение, удовлетворяющее условиям фильтрации.

Process (обработка). С помощью этой команды осуществляется моделирование обработки, вызывающей загрузку процессора.

Read и Write (чтение и запись). Две эти команды также позволяют моделировать занятость процессора узла, но уже в контексте взаимодействия с дисковой подсистемой чтения и записи файлов.

Таким образом, с помощью классов Application, Message, Response, Session и Call возможно как гибкое моделирование текущей загрузки сети, так и детальное описание поведения программных систем, входящих в состав ИС. Исключительно важно, что эти классы позволяют моделировать сложные распределенные программные системы и их влияние на существующую сетевую инфраструктуру сети.

Объекты COMNET III: параметрическое абстрагирование

Говоря о базовом наборе классов COMNET III, крайне важно упомянуть о применимости к ним так называемого параметрического абстрагирования. Этот подход позволяет создавать новые объекты - экземпляры класса с различными свойствами. Такие важные технологические решения, как, скажем, Gigabit Ethernet, могут быть очень просто смоделированы путем изменения параметров рассматриваемой абстракции - свойств выбранного класса.

Рассмотрим пример. Допустим, мы моделируем локальную сеть, использующую на MAC-подуровне случайный метод доступа с контролем несущей и определением коллизий (CSMA/CD, класс соединений с множественным доступом), однако стандарт канального уровня, предложенный производителем сетевого оборудования, несколько отличается от “родного” IEEE 802.3. Подобная ситуация при использовании продукта, не реализующего объектно-ориентированный подход, могла бы вызвать некоторые неточности. Разработчик был бы вынужден использовать стандарт, предлагаемый производителем продукта, вероятнее всего - классический 802.3. На рис. 4 изображено интерфейсное окно COMNET III, с помощью которого пользователь может редактировать параметры этого стандарта - количество ретрансмиссий в случае обнаружения коллизий, длину заголовка кадра и т. д. Иными словами, пользователь сам осуществляет параметризацию объекта.

Рис. 4. Параметризация соединения 10BaseT стандарта IEEE 802.3

Итак, мы решаем вопрос о соответствии эталонного стандарта и стандарта производителя. Дальнейшие наши действия сводятся к тому, чтобы пополнить библиотеку объектов класса CSMA/CD новым стандартом, который определил пользователь. Для этого достаточно добавить новые параметры. Аналогично мы можем поступить с аппаратными узлами, источниками трафика, параметрами WAN Cloud и т. д.

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

Расширить базовый набор классов можно при дальнейшем использовании механизма наследования.

Режим “Копирование-вставка внешней модели” (Intermodel copy-paste)

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

В дальнейшем вся проблема состоит в том, чтобы объекты из одной модели перенести в другую. Для решения удобно пользоваться режимом COMNET III Intermodel copy-paste (копирование - вставка внешней модели), обеспечивающим перенос из модели в модель вновь создаваемых объектов со всеми свойствами за исключением тех, которые локальны для модели-источника.

Приведем пример. Допустим, мы переносим из одной модели в другую фрагмент сети, имеющий некоторую загрузку. Трафик описывается объектами класса Message. Свойством таких объектов, локальным для модели-источника, является его направленность (destination). Остальные свойства будут перенесены без изменений из объектов, наследующих классы Node (C&C node, Computer group, Router, Switch), Link и др., не привязанных к модели-источнику.

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

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

Модульное построение узлов

Рассмотрим процедуру создания объекта нового класса на основе множественного наследования.

Предположим, перед разработчиком ставится задача построения подробной модели аппаратного устройства (например, маршрутизатора, несколько интерфейсных модулей которого объединены интерфейсной шиной). Целью построения модели является определение задержки на интерфейсной шине. В стандартном описании COMNET III шина описывается двумя параметрами: пропускной способностью и частотой. Ясно, что такого описания нам недостаточно. Однако в нашем распоряжении есть объект, позволяющий описать шину как отдельное устройство, - соединение. В общем-то это не совсем стандартное решение, но, проведя необходимую параметризацию объекта класса Link, мы получим модель шины как полнофункционального устройства, реализующего, например, функцию арбитража. Изображенный на рис. 5 объект MPRouter смоделирован именно таким способом. Интерфейсная шина здесь работает по алгоритму Token Bus.

Рис. 5. Параметризация источника трафика при переносе

фрагмента модели в другую модель (Session Source)

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

Возможность задания состояний объектов

Любой объект в COMNET может находиться в нескольких состояниях. К примеру, для объектов классов Link и Node возможны состояния up, down, failure (включен, выключен, ошибка). Можно также моделировать переходы между этими состояниями и анализировать влияние перехода на моделируемую ИС (рис. 6).

Рис. 6. Определение параметров текущего состояния объекта (Node Properties)

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

Итак, мы рассмотрели основные инструменты и наиболее общие методики построения моделей в COMNET III. Дальнейшие статьи авторы планируют посвятить моделированию различных решений, широко используемых в современных ИС.

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

7. Геометрическое моделирование. Виды систем моделирования. Внутреннее представление моделей.

Геометрическое моделирование.

Можно выделить 2 задачи:

1.Построение геометрической модели уже существующего тела.

2.Синтез геометрической модели нового объекта.

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

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

Поверхностная модель: вначале создается трёхмерный каркас, на который затем “натягиваются” различные виды математических поверхностей. Системы поверхностного моделирования поддерживают различные виды поверхностей: линейчатые поверхности, кинематические поверхности и скульптурные поверхности. Над поверхностями можно проводить следующие операции: обрезание пов-сти другой пов-стью или пространственной кривой на поверхности, построение гладких переходов или скруглений между пов-стями.

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

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

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

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

построение скруглений, построение отверстий на гранях, построение рёбер жёсткости, построение фасок.

Твёрдотельная модель хранится в САПР в виде дерева построения.

Преимущество твёрдотельного моделирования:

1.Простота параметризации.

2.Возможность расчёта масс-инерционных хар-к и разбивка на сетку конечных элементов.

3.Относительная простота моделирования.

Недостаток: ограниченность конструктивных форм создаваемых моделей.

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

1 стр-ра представляет собой дерево , опис-щее историю прим-я булевских операций к примитивам. Журнал операций называется конструктивным пред­ставлением объемной геометрии (Constructive Solid Geometry – CSG representation ). Дерево называется деревом CSG (GSG tree ).

2 стр-ра содержит сведения о границах объема (вершинах, ребрах, гранях и их соединении друг с другом). Это представление называется граничным представлением (boundary representation – В- rep ), а структура данных – структурой B - rep (B - rep data structure ).

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

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

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

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

Геометрическое моделирование раздел математического

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

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

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

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

Этапы геометрического моделирования:

Постановка геометрической задачи, соответствующая исходной прикладной задаче или ее части:

Разработка геометрического алгоритма решения поставленной задачи;

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

Анализ и интерпретация полученных результатов. Методы геометрического моделирования:

Аналитический:

Графический;

Графический, с использованием средств машинной графики:

Графоаналитические методы.

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

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

8. Графические языки высокого уровня.

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

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

автоматизация программирования для оборудования с ЧПУ;

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

системы геометрического моделирования.

Одним из первых проблемно-ориентированных языков, имеющих средства для описания геометрической информации, явился язык АРТ (AUTOMATED PROGRAMMING TOOLS). Этот язык послужил основой для разработки разнообразных систем автоматизации программирования для станков с ЧПУ.

В качестве примеров систем с автономным языком высокого уровня могут также служить системы геометрического моделирования трехмерных тел – COMPAC и СИМАК-Д.

Система COMPAC (COMPUTER ORIENTED PART CODING) предназначена для формирования описания объемных тел из объемных элементов формы – (метод конструктивной геометрии). Кроме трех базовых объемных элементов (кубы, цилиндры, конусы), могут использоваться профилированные детали, получаемые перемещением замкнутого контура вдоль прямой или дуги, а также тела вращения, получаемые вращением замкнутого контура вокруг оси. Элементы задаются, позиционируются и оразмериваются языковыми конструкциями, напоминающими АРТ. Составление детали из объемных элементов производится с помощью операций объединения, вычитания и отсечения.

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

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

довольно значительные затраты на создание языка и транслятора с него;

затраты на внедрение, на включение языка в работающую систему программирования и на обучение пользователей, которые не всегда охотно берутся за изучение еще одного языка, а предпочитают пользоваться процедурными расширениями известных им алгоритмических языков: ALGOL, FORTRAN, PL-1, PASCAL и т.д.;

трудности с последующим расширением языка;

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

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

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

Объектно-ориентированное моделирование (feature - based modeling ) позволяет конструктору создавать объемные тела, используя привычные элементы форм (features ). Созданное тело несет в себе информацию об этих элементах в допол­нение к информации об обычных геометрических элементах (вершинах, ребрах, гранях и др.). Например, конструктор может давать команды типа «сделать от­верстие такого-то размера в таком-то месте» или «сделать фаску такого-то раз­мера в таком-то месте», и получившаяся фигура будет содержать сведения о на­личии в конкретном месте отверстия (или фаски) конкретного размера. Набор доступных в конкретной программе элементов формы зависит от спектра приме­нения этой программы.

Большинством систем объектно-ориентированного моделирования поддержива­ются такие элементы, которые используются при изготовлении деталей: фаски, отверстия, скругления, пазы, выемки и т. д. Такие элементы называются произ­водственными , поскольку каждый из них может быть получен в результате кон­кретного процесса производства. Например, отверстие создается сверлением, а выемка – фрезерованием. Следовательно, на основании сведений о наличии, размере и расположении производственных элементов можно попытаться авто­матически сформировать план технологического процесса. Автоматическое пла­нирование технологического процесса, если оно будет разработано на практиче­ском уровне, перебросит мост между CAD и САМ, которые в настоящий момент существуют отдельно друг от друга. Таким образом, в настоящий момент лучше моделировать объекты, подобные изображенному на рис. 5.20, с использованием команд объектно-ориентированного моделирования «Выемка» и «Отверстие», а не просто булевских операций. Модель, созданная при помощи таких команд, облегчит планирование технологического процесса, если не сделает его полно­стью автоматическим. Использование производственных элементов в моделиро­вании иллюстрирует рис. 5.21.

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

Дисциплина «Лингвистическое и программное обеспечение САПР» (Беспалов В.А.)

Понятие автоматизации проектирования и его лингвистического обеспечения

Базовое и управляющее лингвистическое обеспечение.

Организация диалога в САПР, средства обеспечения диалогового режима.

Принципы организации трансляторов.

Обобщенная структура компилятора.

Синтаксический анализатор.

Языки проектирования и программирования.

Основы теории языков и формальных грамматик.

Способы записи синтаксиса языка. Организация лексического анализа.

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

Понятие автоматизации проектирования и его лингвистического обеспечения.

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

ЛО САПР – совокупность языков, терминов, определений, необходимых для выполнения автоматизированного проект-я. ЛО имеет место наряду с: техническим, математическим, информационным, программным, методическим и организационным обеспечением САПР. Основу ЛО САПР составляют спец. языковые средства (языки проектирования), предназначенных для описания процедур автоматизир. пр-я и проектных решений. Обычно они наз-ся проблемно-ориентированными языками (ПОЯ). 2 вида построения ПОЯ:

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

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

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

набор терминальных символов ПОЯ

интерпретатор ПОЯ

средства синтаксического анализа

средства пакетирования директив

библиотеки базовых функций ПОЯ

интерфейс для связи с СУБД

Интерпритатор- программа или устройство, осуществляющее пооператорную трансляцию и выполнение исходной программы.

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

Базовое и управляющее лингвистическое обеспечение.

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

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

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

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

... » Рассматриваются вопросы построения подсистемы САПР метеорологической поддержки (МП... практических занятий по дисциплине «концепции современного... интеллектуального анализа данных. Интеллектуальный анализ, параллельные алгоритмы, интеллектуальный ...