Конспект лекций для студентов специальности i 53 01 07 Информационные технологии и управление в технических системах

• Название: Конспект лекций для студентов специальности i 53 01 07 Информационные технологии и управление в технических системах
• Дата: 11.05.2023
• Размер: 0.6 Mb.
• Имя файла: 12_100229_1_65759 (1).pdf
• Тип: Конспект лекций; #1122969
• страница: 3 из 6

Sample text 2.

Информационные Ресурсы Internet

ОСети Internet исполнилось 25 лет.

21

This is a blue text

This is a blue text

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

22
Язык UML
Унифицированный язык моделирования (UML) является стандартным инструментом для создания «чертежей» программного обеспечения. С помощью
UML можно визуализировать, специфицировать, конструировать и
документировать артефакты программных систем.
UML пригоден для моделирования любых систем: от информационных систем масштаба предприятия до распределенных Web-приложений и даже встроенных систем реального времени. UML – это язык для визуализации,
специфицирования, конструирования и документирования артефактов программных систем. Язык моделирования, подобный UML, является стандартным средством для составления «чертежей» программного обеспечения.
Для понимания любой нетривиальной системы приходится разрабатывать большое количество взаимосвязанных моделей. В применении к программным системам это означает, что необходим язык, с помощью которого можно с различных точек зрения описать представления архитектуры системы на протяжении цикла ее разработки.
UML – это графический язык специфицирования, что означает построение точных и полных графических моделей, касающиеся анализа, проектирования и реализации, которые должны приниматься в процессе разработки и развертывания системы программного обеспечения.
UML – это язык конструирования, и модели, созданные с его помощью,
могут быть непосредственно переведены на различные языки программирования. Иными словами, UML-модель можно отобразить на такие языки, как Java, C++, Visual Basic, и даже на таблицы реляционной базы данных.
Такое отображение модели на язык программирования позволяет осуществлять прямое проектирование: генерацию кода из модели UML в какой- то конкретный язык. Можно решить и обратную задачу: реконструировать модель по имеющейся реализации.
UML позволяет решить проблему документирования системной архитектуры и всех ее деталей, предлагает язык для формулирования требований к системе и определения тестов и, наконец, предоставляет средства для моделирования работ на этапе планирования проекта и управления версиями.
Использование UML эффективно в:
· информационных системах масштаба предприятия;
· банковских и финансовых услугах;
· телекоммуникациях;
· на транспорте;
· оборонной промышленности, авиации и космонавтике;
· розничной торговле;
· медицинской электронике;

23
· науке;
· распределенных Web-системах.
Сфера применения UML не ограничивается моделированием ПО. Он позволяет моделировать, скажем, документооборот в юридических системах,
структуру и функционирование системы обслуживания пациентов в больницах,
осуществлять проектирование аппаратных средств.
1 Структура и компоненты языка UML
1.1 Общие принципы
Конструктивное использование языка UML основывается на понимании общих принципов моделирования сложных систем и особенностей процесса
объектно-ориентированного анализа и проектирования (ООАП). Выбор выразительных средств для построения моделей сложных систем основывается на нескольких принципах.
Первым является принцип абстрагирования, который предписывает включать в модель только те аспекты проектируемой системы, которые имеют непосредственное отношение к выполнению системой своих функций или своего целевого предназначения. При этом все второстепенные детали опускаются,
чтобы чрезмерно не усложнять процесс анализа и исследования полученной модели.
Вторым принципом построения моделей сложных систем является принцип многомодельности. Это значит, что никакое единственное представление сложной системы не является достаточным для адекватного выражения всех ее особенностей.
Еще одним принципом прикладного системного анализа является принцип иерархического построения моделей сложных систем. Этот принцип предписывает рассматривать процесс построения модели на разных уровнях абстрагирования или детализации в рамках фиксированных представлений.
Таким образом, процесс ООАП можно представить как поуровневый спуск от наиболее общих моделей и представлений концептуального уровня к более частным и детальным представлениям логического и физического уровня. При этом на каждом из этапов ООАП данные модели последовательно дополняются все большим количеством деталей, что позволяет им более адекватно отражать различные аспекты конкретной реализации сложной системы.
Объектно-ориентированный анализ и проектирование системы предусматривает использование словаря языка UML, включающего три вида строительных блоков: сущности, отношения, диаграммы.
1.2 Сущности
Основными объектно-ориентированными блоками являются сущности. В
языке UML имеется четыре вида сущностей: структурные, поведенческие,

24
группирующие, аннотационные.
Структурные сущности – это имена существительные в моделях на языке UML. Они представляют собой статические части модели,
соответствующие концептуальным или физическим элементам системы.
Существует пять разновидностей концептуальных и логических сущностей.
Класс (Class) – это описание совокупности объектов с общими атрибутами,
операциями, отношениями и семантикой (рис. 3). Класс реализует один или несколько интерфейсов.
Рис. 3 Классы
Интерфейс (Interface) – это совокупность операций, которые определяют набор услуг, предоставляемый классом или компонентом. Интерфейс описывает видимое извне поведение элемента (рис. 4). Интерфейс редко существует сам по себе – обычно он присоединяется к реализующему его классу или компоненту.
Рис. 4 Интерфейс
Кооперация (Collaboration) определяет взаимодействие, и представляет совокупность ролей, работающих совместно, производят некоторый кооперативный эффект. Кооперация имеет как структурный, так и поведенческий аспект, – один и тот же класс может принимать участие в нескольких кооперациях (рис. 5).
Рис. 5 Кооперация
Прецедент (Use case) – это описание последовательности выполняемых системой действий, которая производит наблюдаемый результат, значимый для какого-то определенного
актера
(Actor). Прецедент применяется для структурирования поведенческих сущностей модели, и реализуются посредством кооперации (рис. 6).
Рис. 6 Прецедент

25
Активным классом (Active class) называется класс, объекты которого вовлечены в один или несколько процессов (Threads), и могут инициировать управляющее воздействие. Активный класс отличается от обычного класса тем,
что деятельность его объектов осуществляется одновременно с деятельностью других элементов. Графически активный класс изображается так же, как простой класс, но ограничивающий прямоугольник рисуется жирной линией и обычно включает имя, атрибуты и операции (рис. 7)
Рис. 7 Активный класс
Компоненты и узлы соответствуют физическим сущностям системы.
Компонент (Component) – это физическая заменяемая часть системы,
соответствующая некоторому набору интерфейсов и обеспечивает его реализацию (рис. 8). Компонент
– это физическая упаковка логических элементов, (классов, интерфейсов и кооперации), например компоненты СОМ+
или Java Beans, а также файлы исходного кода.
Рис. 8 Компонент
Узел (Node) – это элемент, представляющий вычислительный ресурс,
обладающий памятью и способностью обработки. Совокупность компонентов может размещаться в узле, а также мигрировать с одного узла на другой (рис. 9).
Рис. 9 Узел
Существуют также разновидности этих семи сущностей: актеры, сигналы,
утилиты (виды классов), процессы и нити (виды активных классов), приложения,
документы, файлы, библиотеки, страницы и таблицы (виды компонентов).
Поведенческие сущности (Behavioral things) являются динамическими составляющими модели UML. Это глаголы языка: они описывают поведение модели. Существует всего два типа поведенческих сущностей.
Взаимодействие (Interaction) – это поведение, суть которого заключается в обмене сообщениями между объектами для достижения определенной цели. С
помощью взаимодействия описывается как отдельная операция, так и поведение совокупности объектов. Взаимодействие предполагает ряд других элементов,
таких как сообщение (рис. 10), последовательность действий (поведение,

26
инициированное сообщением) и связь (между объектами).
Рис. 10 Сообщение
Автомат (State machine) – это алгоритм поведения, определяющий последовательность состояний, через которые объект или взаимодействие проходят на протяжении своего жизненного цикла в ответ на различные события, а также реакции на эти события (рис. 11). С помощью автомата можно описать поведение отдельного класса или кооперации классов. С автоматом связан ряд других элементов: состояния, переходы (из одного состояния в другое), события (сущности, инициирующие переходы) и виды действий
(реакция на переход).
Рис. 11 Состояние
Взаимодействия и автоматы семантически связаны с различными структурными элементами, такими как классы, кооперации и объекты.
Группирующие сущности являются организующими частями модели, это блоки, на которые можно разложить модель. Основной группирующей сущностью является пакет.
Пакет (Package) – это универсальный механизм организации элементов в группы (рис. 12). В пакет можно поместить структурные, поведенческие и даже другие группирующие сущности. В отличие от компонентов, существующих во время работы программы, пакеты носят чисто концептуальный характер, то есть существуют только во время разработки.
Рис. 12 Пакеты
Существуют также вариации пакетов, например каркасы (Frameworks),
модели и подсистемы.
Аннотационные сущности – пояснительные части модели UML. Это комментарии для дополнительного описания, разъяснения или замечания к любому элементу модели. Имеется только один базовый тип аннотационных элементов – примечание.
Примечание (Note)
– это символ для изображения комментариев,
присоединенных к элементу или группе элементов (рис. 13).

27
Рис. 13 Примечание
Примечания используются, чтобы снабдить диаграммы комментариями или ограничениями, которые можно выразить в виде неформального или формального текста. Существуют вариации этого элемента, например требования, где описывают некое желательное поведение с точки зрения внешней по отношению к модели.
1.2 Отношения
В языке UML определены четыре типа отношений: зависимость,
ассоциация, обобщение, реализация. Эти отношения являются основными связующими строительными блоками в UML.
Зависимость (Dependency) – это семантическое отношение между двумя сущностями, при котором изменение одной из них, независимой, может повлиять на семантику другой, зависимой (рис. 14).
Рис. 14 Отношения зависимости
Ассоциация (Association) – отношение, описывающее совокупность связей между объектами. Разновидностью ассоциации является
агрегирование
(Aggregation) – структурное отношение между целым и его частями (рис. 15).
Графическое изображение ассоциации может включать кратность и имена ролей
(рис. 16).
Рис. 15 Агрегирование
Рис. 16 Имена ассоциаций
Обобщение (Generalization) – это отношение “специализация/обобщение”

28
(рис. 17), при котором объект специализированного элемента (потомок) может быть подставлен вместо объекта обобщенного элемента (родителя или предка).
Таким образом, потомок (Child) наследует структуру и поведение своего родителя (Parent).
Рис. 17 Обобщение
Наконец,
реализация
(Realization)
– это отношение между классификаторами, при котором один классификатор определяет “контракт”, а другой гарантирует его выполнение (рис. 18).
Рис. 18 Реализация
Отношения реализации встречаются в двух случаях: во-первых, между интерфейсами и реализующими их классами или компонентами, а во-вторых,
между прецедентами и реализующими их кооперациями.
1.2 Диаграммы
Диаграмма в UML – это графическое представление набора элементов,
изображаемое в виде связанного графа с вершинами (сущностями) и ребрами
(отношениями), используемое для визуализации системы с разных точек зрения.
В UML выделяют 8 типов диаграмм (рис. 19).

29
Рис. 19 Интегрированная модель сложной системы в нотации UML
На диаграмме классов (Class diagram) изображаются классы, интерфейсы,
объекты и кооперации, а также их отношения. Используется при моделировании объектно-ориентированных систем.
На диаграмме вариантов использования (Use case diagram) представлены прецеденты и актеры (частный случай классов), а также отношения между ними.
Они используются при моделировании поведения системы.
Диаграммы последовательностей (Sequence diagram) и кооперации
(Collaboration diagram) являются частными случаями диаграмм взаимодействия.
На диаграммах взаимодействия представлены связи между объектами
(сообщения, которыми объекты могут обмениваться). Диаграммы взаимодействия относятся к динамическому виду системы. При этом диаграммы последовательности отражают временную упорядоченность сообщений, а диаграммы кооперации
– структурную организацию обменивающихся сообщениями объектов. Эти диаграммы могут быть преобразованы друг в друга.
На диаграммах состояний (Statechart diagrams) представлен автомат,
включающий состояния, переходы, события и виды действий. Диаграммы состояний используются при моделировании поведения интерфейса, класса или кооперации, зависящем от последовательности событий.
Диаграмма деятельности (Activity diagram) представляют переходы потока управления между объектами от одной деятельности к другой внутри системы.
Диаграмма компонентов (Component diagram) представляет зависимости между компонентами. Диаграммы компонентов отображаются на один или несколько классов, интерфейсов или коопераций.
На
диаграмме развертывания
(Deployment diagram) представлена конфигурация обрабатывающих узлов системы и размещенных в них компонентов.

30
2 Диаграммы вариантов использования (use case diagram)
На диаграммах вариантов использования отображается взаимодействие между вариантами использования, представляющими функции системы, и действующими лицами, представляющими людей или системы, получающие или передающие информацию в данную систему. Из диаграмм вариантов использования можно получить довольно много информации о системе. Этот тип диаграмм описывает общую функциональность системы. Пользователи,
менеджеры проектов, аналитики, разработчики, специалисты по контролю качества и все, кого интересует система в целом, могут, изучая диаграммы вариантов использования, понять, что система должна делать.
2.1 Базовые элементы диаграммы вариантов использования
К базовым элементам рассматриваемой диаграммы относятся вариант
использования, актер и интерфейс.
Вариант использования (рис. 20) применяется для спецификации общих особенностей поведения системы или другой сущности без рассмотрения ее внутренней структуры (например, оформление заказа на покупку товара,
получение информации о кредитоспособности клиента, отображение графической формы на экране монитора).
Рис. 20 Графическое обозначение варианта использования
Актер – это внешняя по отношению к моделируемой системе сущность,
которая взаимодействует с системой и использует ее функциональные возможности для решения определенных задач (рис. 21). При этом актеры служат для обозначения согласованного множества ролей, которые могут играть пользователи в процессе взаимодействия с проектируемой системой.
Рис. 21 Графическое обозначение актера
Имя актера должно быть достаточно информативным с точки зрения семантики, например клиент банка, продавец магазина, пассажир авиарейса,
водитель автомобиля, сотовый телефон.
Так как в общем случае актер всегда находится вне системы, его внутренняя структура никак не определяется. Для актера имеет значение только его внешнее представление, т.е. то, как он воспринимается со стороны системы.
Актеры взаимодействуют с системой посредством передачи и приема сообщений от вариантов использования. Сообщение представляет собой запрос актером

31
сервиса от системы и получение этого сервиса. Это взаимодействие может быть выражено посредством ассоциаций между отдельными актерами и вариантами использования или классами. Кроме этого, с актерами могут быть связаны интерфейсы, которые определяют, каким образом другие элементы модели взаимодействуют с этими актерами.
Интерфейс служит для спецификации параметров модели, которые видимы извне без указания их внутренней структуры (рис. 22). В диаграммах вариантов использования интерфейсы определяют совокупность операций,
обеспечивающих необходимый набор сервисов или функциональности для актеров. Интерфейсы не могут содержать ни атрибутов, ни состояний, ни направленных ассоциаций. Они содержат только операции без указания особенностей их реализации. Формально интерфейс эквивалентен абстрактному классу без атрибутов и методов с наличием только абстрактных операций.
Рис. 22 Графическое изображение интерфейсов на диаграммах вариантов использования
Интерфейс соединяется с вариантом использования сплошной линией,
если он реализует все операции, необходимые для данного интерфейса
(рис. 23, а). Если же вариант использования определяет только тот сервис,
который необходим для реализации данного интерфейса, используется пунктирная стрелка (рис. 23, б).
Рис. 23 Графическое изображение взаимосвязей интерфейсов с вариантами использования а) реализация всех операций, б) реализация только необходимого сервиса
Важность интерфейсов заключается в том, что они определяют стыковочные узлы в проектируемой системе, что совершенно необходимо для организации коллективной работы над проектом. Более того, спецификация интерфейсов способствует “безболезненной” модификации уже существующей системы при переходе на новые технологические решения. В этом случае изменению подвергается только реализация операций, но никак не функциональность самой системы. А это обеспечивает совместимость последующих версий программ с первоначальными при спиральной технологии разработки программных систем.