Файл: Применение объектно-ориентированного подхода при проектировании информационной системы (Базовые составляющие объектно-ориентированного подхода).pdf
Добавлен: 12.03.2024
Просмотров: 79
Скачиваний: 0
СОДЕРЖАНИЕ
1. Основы объектно-ориентированного подхода к анализу и проектированию информационных систем
1.1. Сущность объектно-ориентированного подхода
1.2. Базовые составляющими объектно-ориентированного подхода
1.3. Преимущества объектно-ориентированного подхода
2. Основы Унифицированного процесса
2.1. Структура Унифицированного процесса
2.4. Базовые концепции Унифицированного процесса
3. Основы Унифицированного языка моделирования
3.1. Структура Унифицированного языка моделирования
3.2. Семантика и синтаксис UML
3.4.1 Назначение и состав модели вариантов использования
3.4.2 Назначение и состав модели анализа
3.4.3 Общие сведения о диаграммах взаимодействия
3.4.5 Назначение и состав диаграммы последовательности
Таблица 2
Структурные типы сущностей в UML
- группирующая – элемент, используемый для некоторого смыслового объединения элементов диаграммы;
Таблица 3
Группирующие типы сущностей в UML
- поясняющая (аннотационная) – комментарий к элементу диаграммы.
Таблица 4
Поясняющие типы сущностей в UML
В некоторых источниках, в частности [3, 6], выделяют также поведенческие сущности взаимодействия и конечные автоматы, но с логической точки зрения их следует отнести к диаграммам.
В следующей таблице приведено описание всех видов отношений UML, используемых на диаграммах для указания связей между сущностями.
Таблица 5
Отношения между сущностями
Диаграмма представляет собой группировку элементов нотации для отображения некоторого аспекта разрабатываемой информационной системы. Диаграммы представляют собой, как правило, связный граф, в котором сущности являются вершинами, а отношения – дугами. В следующей таблице дана краткая характеристика диаграмм UML [1].
Для ассоциации, агрегации и композиции может указываться кратность (англ. multiplicity), характеризующая общее количество экземпляров сущностей, участвующих в отношении. Она, как правило, указывается с каждой стороны отношения около соответствующей сущности. Кратность может указываться следующими способами:
- * – любое количество экземпляров, в том числе и ни одного;
- целое неотрицательное число – кратность строго фиксирована и равна указанному числу (например: 1, 2 или 5);
- диапазон целых неотрицательных чисел "первое число .. второе число" (например: 1..5, 2..10 или 0..5);
- диапазон чисел от конкретного начального значения до произвольного конечного "первое число .. *" (например: 1..*, 5..* или 0..*);
- перечисление целых неотрицательных чисел и диапазонов через запятую (например: 1, 3..5, 10, 15..*).
Если кратность не указана, то принимается ее значение, равное 1. Кратность экземпляров сущностей, участвующих в зависимости, обобщении и реализации, всегда принимается равной 1.
В следующей таблице приведено описание механизмов расширения, применяемых для уточнения семантики сущностей и отношений. В общем случае, механизм расширения представляет собой строку текста, заключенную в скобки или кавычки.
Таблица 6
Механизмы расширения сущностей в UML
Помимо стереотипов, указываемых в виде строки текста в кавычках, на диаграммах могут использоваться графические стереотипы. На следующем рисунке приведены примеры стандартного и стереотипного отображения класса-сущности.
Рисунок 4. Обозначения класса-сущности.
3.4 Диаграммы
Диаграмма представляет собой группировку элементов нотации для отображения некоторого аспекта разрабатываемой информационной системы. Диаграммы представляют собой, как правило, связный граф, в котором сущности являются вершинами, а отношения – дугами. В следующей таблице дана краткая характеристика диаграмм UML [1].
Таблица 7
Краткая характеристика диаграмм UML
Стандарт UML 2.x определяет также дополнительные, узко специализированные диаграммы: - диаграмму объектов (object diagram) - аналогична диаграмме классов, но вместо классов отображаются объекты;
- диаграмму синхронизации (timing diagram) - описывает состояния объекта с течением времени;
- композитную структурную диаграмму (composite structure diagram) - описывает порты (включая интерфейсы) класса для взаимодействия с другими классами;
- профильную диаграмму (profile diagram) - аналогична диаграмме пакетов с описанием классов, входящих в него;
- обзорную диаграмму взаимодействия (interaction overview diagram) - аналогична диаграмме последовательности, но со скрытыми фрагментами взаимодействия (фрагментами с меткой ref). Представляет собой контекстную (концептуальную) диаграмму последовательности, элементы которой будут конкретизированы на отдельных диаграммах декомпозиции.
3.4.1 Назначение и состав модели вариантов использования
Визуальное моделирование в UML можно представить как некоторый процесс поуровнего спуска от наиболее общей и абстрактной концептуальной модели к логической, а затем и к физической модели соответствующей информационной системы. Для достижения этих целей вначале строится модель вариантов использования, которая описывает функциональное назначение системы. Основная цель построения этой модели – достигнуть взаимопонимания между разработчиками и заказчиками (пользователями) по назначению, возможностям и технологии использования будущей информационной системы, т. е. определить границы ее применения.
Построение этой модели необходимо для выявления:
- внешнего окружения, взаимодействующего с системой (актеров);
- основных функций системы (вариантов использования) с возможным уточнением технологии их выполнения;
- нефункциональных требований (платформы, производительности, надежности, защищенности и т. д.).
Достижение этой цели, в первую очередь, достигается за счет разработки диаграмм UML, которые являются основными артефактами технологического процесса «Формирование требований». К диаграммам, которые рекомендуется построить в рамках рассматриваемой модели, относятся:
- диаграмма вариантов использования;
- диаграмма автоматов;
- диаграмма классов анализа;
- диаграмма последовательности;
- диаграмма коммуникации.
В качестве дополнительных артефактов в данную модель также входят согласованные между заказчиком и разработчиком прототипы пользовательского интерфейса системы и глоссарий.
3.4.2 Назначение и состав модели анализа
Основное отличие модели вариантов использования от модели анализа состоит в том, что при построении первой основное внимание уделяется определению функциональных возможностей (требований) системы, а при построении второй – их уточнению с учетом внутренней организации (архитектуры) проектируемой системы. В связи с этим на второй стадии может использоваться более формальный и специфичный язык – язык разработчиков.
Построение этой модели необходимо:
- для выявления внутренней архитектуры (определения подсистем и основных классов);
- для поиска альтернативных вариантов реализации системы (подсистем) и выбора основного;
- для уточнения всех требований (функциональных и нефункциональных).
Диаграмма классов анализа по существу является прообразом классической диаграммы классов. Элементами, отображаемыми на диаграмме, являются классы и отношения между ними. При этом для отображения классов можно воспользоваться стандартным обозначением класса (прямоугольник) с указанием внутри него соответствующего стереотипа или значком-стереотипом.
Таблица 8
Варианты обозначения классов
Назначение классов анализа [6]:
- граничный класс – используется для моделирования взаимодействия между системой и актерами (пользователями, внешними системами или устройствами). Взаимодействие часто включает в себя получение или передачу информации, запросы на предоставление услуг и т. д. Граничные классы являются абстракциями диалоговых окон, форм, панелей, коммуникационных интерфейсов, интерфейсов периферийных устройств, интерфейсов API (англ. application program interface – интерфейс прикладных программ) и т. д. Каждый граничный класс должен быть связан как минимум с одним актером;
- управляющий класс – отвечает за координацию, взаимодействие и управление другими объектами, выполняет сложные вычисления, управляет безопасностью, транзакциями и т. п.
- класс сущности – используется для моделирования долгоживущей, нередко сохраняемой информации. Классы сущности являются абстракциями основных понятий предметной области – людей, объектов, документов и т. д., как правило, хранимых в табличном или ином виде.
3.4.3 Общие сведения о диаграммах взаимодействия
Реализация отдельного варианта использования требует участия и взаимодействия определенных экземпляров актеров и классов. Наиболее подходящий инструмент для описания такого взаимодействия – это диаграммы последовательности и коммуникации, которые, по сути, отображают одну и ту же информацию. В связи с этим большинство Case-средств позволяет после построения одной из диаграмм автоматически получить другую, а также выполнять синхронизацию этих диаграмм между собой.
Общими элементами диаграмм являются:
- экземпляры актеров и объекты, участвующие во взаимодействии;
- сообщения, передаваемые между экземплярами актеров и объектами.
Экземпляры сущностей отображаются стандартно (экземпляр актера – человечком, экземпляр класса (объект) – прямоугольником или графическим стереотипом класса анализа). В то же время следует помнить, что экземпляр – это конкретная реализация соответствующей сущности (актера, класса, узла и т. д.). Чтобы учесть этот нюанс на диаграммах, имя экземпляра подчеркивается и может отображаться в следующих вариантах:
- Имя объекта : Имя класса (например, Вася : Программист);
- : Имя класса (например, : Программист) – анонимный объект;
- Имя объекта (например, Вася) – предполагается, что имя класса известно;
- Имя объекта : (например, Вася :) – объект-сирота. Считается, что имя класса неизвестно.
Для объектов, кроме имени, могут указываться также некоторые важные для взаимодействия атрибуты и их значения.
Взаимодействие между экземплярами актеров и объектами моделируется посредством передачи сообщений. Сообщение (англ. message) – это спецификация факта передачи информации между сущностями с ожиданием выполнения определенных действий со стороны принимающей сущности. Сущность, отправляющую сообщение, называют клиентом, а принимающую – сервером. Таким образом, сообщения не только передают некоторую информацию, но и требуют или предполагают выполнения сервером определенных действий или передачу (возврат) клиенту необходимой информации. Если принимающей сообщение сущностью является объект, то оно представляет собой операцию (метод) объекта-сервера. Прием сообщения обычно трактуется, как возникновение события на сервере. Сообщения изображаются стрелкой с обязательным указанием направления (остриё стрелки указывает на принимающую сторону) и спецификации [1].
3.4.5 Назначение и состав диаграммы последовательности
Диаграмма последовательности наглядно отображает временной аспект взаимодействия. Она имеет два измерения. Одно измерение (слева-направо) указывает на порядок вовлечения экземпляров сущностей во взаимодействие. Крайним слева на диаграмме отображается экземпляр актера или объект, который является инициатором взаимодействия. Правее отображается другой экземпляр сущности, который непосредственно взаимодействует с первым и т.д. Второе измерение (сверху-вниз) указывает на порядок обмена сообщениями. Начальному моменту времени соответствует самая верхняя часть диаграммы. Масштаб на оси времени не указывается, поскольку диаграмма отображает лишь временную упорядоченность взаимодействия типа «раньше-позже» [1].
На диаграмме последовательности отображается ряд специфичных элементов, которые отсутствуют на диаграмме коммуникации.
Линия жизни (англ. lifeline) отображается штриховой вертикальной линией, соединенной с соответствующим экземпляром сущности. Линия жизни служит для обозначения периода времени, в течение которого экземпляр может потенциально участвовать во взаимодействии. Если он существует в течение всего взаимодействия, то и его линия жизни должна продолжаться от самой верхней части диаграммы до самой нижней.
Не обязательно создавать все объекты в начальный момент времени. Отдельные объекты в системе могут создаваться по мере необходимости, существенно экономя ресурсы системы и повышая ее производительность. В этом случае объект изображается не в верхней части диаграммы, а в том месте, где он создается. Для обозначения факта уничтожения объекта в UML используется специальный символ X. Как правило, уничтожаются объекты, созданные на основе граничных и управляющих классов. Экземпляры актеров и объекты классов сущностей остаются в системе после окончания взаимодействия.
Как было отмечено выше, взаимодействие между экземплярами моделируется через обмен сообщениями. Сообщения могут быть следующих видов:
– синхронное сообщение (англ. synchronous message). Клиент посылает сообщение серверу и ждет, пока тот примет и обработает сообщение. Как правило, один объект передает синхронное сообщение второму, второй – третьему и т.д., образуя вложенный поток сообщений. В любом случае клиент, инициирующий поток сообщений, должен дождаться его завершения, т.е. возврата управления. Это самый распространенный тип сообщений;