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

Тем средством, который позволил объединить данный подходы, стал Unified Modeling Language (Унифицированный язык объектно-ориентированного моделирования). United Modeling Language или просто UML – это преемник поколения методов ООАП, которые появились в конце 80-х и начале 90-х годов. Разработка UML началась в конце 1994 г, когда Джейм Рамбо и Гради Буч нчаласи работу по определению методов Booch и OMT под эгидой компании Rational Software. А уже к концу 1995 г они создали первую спецификацию объединенного метода, которого они назвали Unified Method, версии 0.8. В том же году к ним присоединился Ивар Якобсон, создать метода Object-oriented Software Engineering. В итоге UML стал прямым объединением и унификацией методов Буча, Рамбо и Якобсона^[20][20]. Основными целями при разработке UML были:

• дать пользователям уже готовый для применения выразительный язык визуального моделирования, который позволял не только проектировать осмысленные модели, но и обмениваться ими;
• обеспечить формальную среду для понимания данного языка моделирования;
• обеспечить независимость от определенных ЯП. и процессов разработки;
• заранее предусмотреть механизмы специализации и расширяемости для увеличения фундаментальных концепций^[21][21].

На сегодняшний день UML как нотация моделирования ИС поддерживается рядом объектно-ориентированных CASE-продуктов^[22][22].

Основными характеристиками объектно-ориентированного языка моделирования UML являются:

• организация взаимодействия разработчика ИС и заказчика путем построения репрезентативных визуальных моделей;
• специализация базовых обозначений для определенной предметной области.

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

• Моделирование с применение только средств «ядра» для типовых приложений;
• Моделирование с применением дополнительных условных обозначений, если они отсутствуют в «ядре», или специализация нотации и ограничений для данной предметной области^[23][23].

Для поддержки моделирования различных этапов жизненного цикла ИС язык UML предоставляет целую совокупность различных диаграмм.

При проектировании концептуальной модели используют диаграммы вариантов использования и диаграмм деятельности, модели бизнес-объектов, диаграммы последовательностей^[24][23].

На этапе работы над логической моделью ИС описать требования к системе позволяют диаграммы вариантов использования, а при предварительном проектировании применяют диаграммы классов, диаграммы последовательностей, диаграммы состояний.

Детальное проектирование при разработке физической модели выполняют с использованием диаграмм развертывания, диаграмм компонентов и диаграмм классов^[25]24.

2.2 Варианты использования

В течение довольно таки продолжительного периода времени в процессе как традиционного структурного, так и объектно-ориентированного проектирования разработчики применяли типичные сценарии, которые помогали точнее понять требования к системе. Трактовались данные сценарии весьма неформально, они часто использовались и очень редко документировались. Понятие use case (вариант использования) ввел впервые Ивар Якобсон и придал ему такую значимость, что оно трансформировалось в главный элемент проектирования и планирования проекта.

Вариант использования представляет собой такую последовательность действий, выполняемых системой в ответ на событие, инициируемое некоторым внешним объектом, т.е. действующим лицом^[26][25]. Вариант использования описывает примитивное взаимодействие между системой и пользователем. В качестве простого примера, два обычных варианта использования типичного текстового процессора – сделать данный текст полужирным и создать индекс. На этом простом примере легко можно выделить пару свойств варианта использования: он решать для пользователя некоторую дискретную задачу, охватывает очевидную для пользователя функцию, а так же может быть как большим, так и довольно маленьким. Вариант использования в простых случаях определяется в процессе обсуждения с пользователем тех функций, которые он хотел бы реализовать^[27][26].

В 1994 г. Ивар Якобсон предложил не только использовать варианты использования в качестве основных элементов процесса проектирования ПО, но и применять диаграммы вариантов для их наглядного представления^[28][27].

При создании модели прецедентов, основными элементами на диаграмме будут являться:

• актер (actor) – это элемент, обозначающий пользовательские роли и взаимодействующий с определенной сущностью;
• прецедент – это элемент, который отражает действия, выполняемые самой системой (с указанием всевозможных вариантов), приводящие в результата, наблюдаемые актерами.

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

• include (включение) – указывает на взаимосвязь некоторых вариантов использования, из которых основной использует всегда функциональное поведение связанных с ним прецедентов;
• extend (расширение) – указывает на взаимосвязь базового варианта использования и вариантов использования, которые в свою очередь являются специальными случаями;
• generalization (обобщение) – указывает на общность ролей^[29][28].

Все варианты использования, так или иначе, связаны с требованиями к функциональности системы извне. Варианты использования всегда нужно анализировать вместе с актерами системы, при этом определяя реальные цели пользователей и рассматривая альтернативные варианты решения этих задач^[30][29].

Актеры могут играть разные роли по отношению к варианту использования. Они могут сами принимать в нем участие или всего лишь пользоваться его результатами. Важность разных ролей актеров зависит от того, как используются его связи^[31][30].

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

В дополнение к связям между актерами и вариантами использования существуют так же еще два других типа связей, такие как: extends (расширение) и uses (использование) между вариантами использования. Связь типа extends (расширение) используется, когда один вариант использования похож на другой, но при этом не несет большую загрузку.

Выбор необходимого типа связи определяется следующими правилами:

• связь типа extends (расширение) нужно использовать при описании в нормальном поведении системы;
• связь типа uses (использование) требуется применять во избежание повторов в двух или более вариантах использования.

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

ДИАГРАММЫ

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

Диаграмма UML – это специальный язык графического описания и предусмотренный для объектного моделирования в области разработки различного ПО^[32][31]. Данный язык представляет собой открытый стандарт, в котором применяются разные графические обозначения, для того чтобы создать абстрактную модель системы. UML разрабатывался для обеспечения визуализации, определения, документирования, а так же для проектирования различных систем^[33][32]. Следует сказать, что сама по себе UML-диаграмма не является ЯП, но при этом предусматривается возможность генерации отдельного кода на ее основе.

Использования UML не прекращается на моделировании различного ПО. На сегодняшний момент данный язык все так же используется для моделирования различных бизнес-процессов и ведения системного проектирования^[34][33].

С его помощью разработчики ПО способны добиться соглашения в используемых графических обозначениях. Благодаря этому достигается большая степень концентрации на проектировании и архитектуре.

Далее мы рассмотрим, какие бывают виды диаграмм, и скажем об их назначении.

Итак, диаграммы бывают следующих видов:

• диаграмма вариантов использования;
• диаграмма классов;
• диаграмма состояний;
• диаграмма взаимодействий;
• диаграмма деятельности;
• диаграмма пакетов;
• диаграмма компонентов;
• диаграмма размещения.

Диаграмма вариантов использования показывает на себе все отношения, возникающие между актерами и разными вариантами использования^[35][34]. Основная ее цель – это осуществлять собой полное средство, при помощи которого конечный пользователь, заказчик или разработчик могут совместно обсуждать функциональность и поведение конкретной системы^[36][35].

Диаграмма классов представляет собой статическую структурную диаграмму, которая предназначена для описания структуры системы, а также для демонстрации методов, атрибутов и зависимостей между несколькими различными классами^[37][36].

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

• концептуальная. В этом случае диаграмма классов UML осуществляет описание модели конкурентной сферы, и в ней предусматриваются только классы прикладных объектов;
• реализационная. В данном случае диаграмма классов включает в себя всевозможные классы, которые применяются в программном коде;
• специфическая. Здесь, диаграмма применятся в процессе проектирования различных ИС^[38][37].

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

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

Диаграмма деятельности показывает разложение деятельности на некоторое количество частей. Под понятие деятельности понимается спецификация определенного исполняемого поведения как в виде параллельного, так и в виде координированного последовательного выполнения разных подконтрольных элементов – вложенных типов деятельности и различных действий, которые объединены потоками, идущими от выходов конкретного узла к выходам другого^[40][39].

Диаграмма пакетов носит структурный характер, и главных ее содержанием являются различные пакеты, а также отношения между ним. В этом случае, нет никакого жесткого разделения между несколькими структурами диаграммами, в итоге их использование все чаще встречается только для удобства, и не несет в себе никакого семантического значения. Различные элементы способны предоставлять другие UML диаграммы (пакеты и сами диаграммы пакетов)^[41][40]. Их использование осуществляется для обеспечения организации нескольких элементов в группы, по какому либо признаку, для упрощения структуры и организации работы с моделью данной системы.

Диаграмма компонентов представляет собой статическую структурную диаграмму, предназначенную для демонстрации разбиения определенной программной системы на различные структурные компоненты и для связи между ними. В качестве таковых диаграмма компонентов способна использовать различные исполняемые файлы, пакеты, библиотеки, модели^[42][41].