Файл: Применение объектно-ориентированного подхода при проектировании информационной системы (Методология объектно-ориентированного проектирования).pdf

3. Унифицированный язык моделирования (UML)

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

Язык UML является основным инструментом моделирования процессов и визуализации структуры базы данных. Этот язык содержит множество инструментов, которые могут быть использованы для построения логических и концептуальных систем, он составлен с использованием многолетнего опыта программной инженерии, который оттачивался при разработки больших систем.[^[7]]

Словарь UML включает три вида строительных блоков:

• Сущности;
• Диаграммы;
• Связи.

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

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

История унифицированного языка моделирования.

Во второй половине XX века с развитием объектно-ориентированных языков программирования (Simula 67, Smalltalk, Objective C, C++) возникла потребность в универсальном языке моделирования UML. Вследствие непрекращающегося усложнения создаваемых программных продуктов возникла нужда в учёте всё новых и новых возможностей языков и средств разработки при анализе, формулировании требований и в процессе проектирования программных приложений. Например, в короткий промежуток времени с 1989 года по 1994 год, количество объектно-ориентированных инструментов выросло с десятка до более, чем полусотни. Однако, многие разработчики затруднялись подобрать язык моделирования, который бы полностью отвечал всем их потребностям. В результате выделилось новое поколение методов разработки, среди, которого особую популярность приобрел метод Бутча, созданный Якобсоном Object-Oriented Software Engineering (OOSE) и разработанный Рамбо (Object Modeling Technique (OMT). Помимо них существовали и другие завершённые технологии, например Fusion, Shlaer-Mellor и Coad-Yourdon, однако всем из них были присущи не только преимущества, но и существенные недостатки. [^[8]]

---

До UML 1.x.

В 1994 году Гради Бутч и Джеймс Рамбо, работавшие в компании Rational Software, объединили свои усилия для создания нового языка объектно-ориентированного моделирования. За основу языка ими были взяты методы моделирования Object-Modeling Technique и Booch. OMT был ориентирован на анализ, а Booch — на проектирование программных систем. В октябре 1995 года была выпущена предварительная версия 0.8 унифицированного метода (англ. Unified Method). Осенью 1995 года к компании Rational присоединился Ивар Якобсон, автор метода Object-Oriented Software Engineering — OOSE. OOSE обеспечивал превосходные возможности для спецификации бизнес-процессов и анализа требований при помощи сценариев использования. OOSE был также интегрирован в унифицированный метод.

На этом этапе основная роль в организации процесса разработки UML перешла к консорциуму OMG (Object Management Group). Группа разработчиков в OMG, в которую также входили Буч, Рамбо и Якобсон («три амиго»), выпустила спецификации UML версий 0.9 и 0.91 в июне и октябре 1996 года. [^[9]]

UML 1.x

На волне растущей популярности языка моделирования UML к разработке новых версий присоединились такие гиганты в сфере IT, как HP, IBM и ICON Computing . В результате была разработана версия UML 1.0, вышедшая в январе 1997 года. В ноябре того же года за ней последовала версия 1.1, содержавшая улучшения нотации, а также некоторые расширения семантики.

Последующие релизы UML включали версии 1.3, 1.4 и 1.5, опубликованные, соответственно, в июне 1999, сентябре 2001 и марте 2003 года. [^[10]]

UML 2.x.

Версия UML 2.х является самым распространенным на данный момент способом моделирования информационных систем. UML2.0 - это первая основная версия стандарта UML, за которой последовала серия младших редакций [OMG04] [RJB05]. Зачем нужно было пересматривать UML?

Основной мотивацией для пересмотра языка было желание обеспечить лучшую поддержку MDD-средств и методов. За последнее десятилетие ряд производителей разработали основанные на UML инструментальные средства, которые поддерживали значительно более высокий уровень автоматизации, чем традиционные CASE-средства (computer-aided software engineering).

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

---

• Значительно увеличена степень точности в определении языка:
• Улучшена организация языка: Это характеризуется модульностью, которая не только делает язык более доступным для новых пользователей, но и содействует совместной работе инструментальных средств.
• Значительно улучшена способность моделирования широкомасштабных программных систем: Некоторые современные приложения представляют собой интеграцию существующих автономных приложений в более сбалансированные системы. Эта тенденция вероятно будет продолжаться, что приведет к появлению еще более сложных систем.
• Улучшена поддержка зависимой от домена (domain-specific) специализации:
• Общая консолидация, рационализация и прояснение различных концепций моделирования: Это привело к упрощению и более согласованному языку. Сюда входит консолидация и, в некоторых случаях, удаление избыточных концепций, уточнение многочисленных определений и добавление текстовых пояснений и примеров.[^[11]]

Диаграммы.

Основные виды диаграмм, использующиеся в UML:

Статические диаграммы:

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

Самыми распространенными видами связей между классами являются: ссылки, связи по композиции, связи по наследованию. Наследование классов изображается стрелкой с пустым наконечником, идущей от наследника к предку. Реализация интерфейсов изображается пунктирной стрелкой с пустым наконечником, ведущей от класса к реализуемому им интерфейсу. Диаграмма компонентов – полностью статическая диаграмма, изображает разбиение системы на структурные компоненты, а так же связи между ними. Компоненты изображаются с помощью прямоугольников с небольшими вставками с левой стороны. Связи между компонентами рисуются пунктирными стрелками, один компонент зависит от другого, если не может быть использован без него в системе.[^[13]]

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

---

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

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

Динамические диаграммы:

Диаграмма деятельности – динамическая диаграмма, иллюстрирующая процессы и действия, происходящие в системе. Действия изображаются в виде прямоугольников с закругленными краями, а последовательность данных ведется с помощью стрелок. Диаграмма делится на несколько дорожек, с помощью горизонтальных линий, каждая дорожка отвечает за группу объектов, которые выполняют действия, например дорожка под названием рабочие станции. Начальное действие помечается черным кружком, конечное - черным с белой окантовкой.[^[14]]

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

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

В UML представлены 8 видов диаграмм и диаграмма вариантов использования, о которой будет рассказано в отдельной главе. Такого количества диаграмм вполне достаточно для подробной визуализации предметной области, многие используют лишь несколько диаграмм из общего количества. Для полной визуализации, даже обширной предметной области, вполне достаточно диаграммы классов, диаграммы действий и диаграммы последовательности. В целом язык UML оказался чрезвычайно полезной разработкой, позволяющей детализировать объект проектирования и предусмотреть особенности будущей системы, избежать ошибки на стадии проектирования. Для подведения итогов данной главы перечислим основные преимущества, которые привнес UML в процесс проектирования.[^[15]]

---

Преимущества UML

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

4. Диаграмма вариантов использования (use case)

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

Длительное время с момента создания унифицированного языка моделирования, у разработчиков не было единого механизма планирования проекта. Все разработки шли хаотично, операции моделирования не имели четкой систематизации. Первым кто ввел понятие варианты использования (use case) был Ивар Якобсон, в 1994 году этот шведский ученый стал основоположником появления унифицированного процесса и разработал концепцию проектирования и наглядного представления вариантов использования системы.[^[16]]

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

---