Общие сведения о языке визуального моделирования UML
Существует множество технологий и инструментальных средств, с помощью которых можно реализовать в некотором смысле оптимальный проект ИС, начиная с этапа анализа и заканчивая созданием программного кода системы.
Эти технологии представлены CASE-средствами. CASE - Computer Aided System Engineering. Мощный толчок к разработке этого направления информационных технологий дало распространение объектно-ориентированных языков программирования в конце 1980-х — начале 1990-х годов. Необходим был единый язык, который объединял бы сильные стороны ОО методов и обеспечивал наилучшую поддержку моделирования.
Таким языком оказался Унифицированный язык объектно-ориентированного моделирования Unified Modeling Language (UML). Существует достаточное количество инструментальных средств, поддерживающих с помощью UML жизненный цикл информационных систем, и, одновременно, UML является достаточно гибким для настройки и поддержки специфики деятельности различных команд разработчиков.
UML был создан для ООАП, которые появились в конце 80-х и начале 90-х гг. Создание UML фактически началось в конце 1994 г. До этого времени американский инженер, руководитель исследований в IBM Research Гради Буч самостоятельно пытался реализовать собственный метод ООМоделирования - Booch.
Данный метод был изложен в книге «Объектно-ориентированный анализ и проектирование». Также Буч был автором одной из самых популярных в то время книг о программировании на языке Ada. С середины 1990-х Гради Буч занимал должность руководителя исследований компании Rational Software, где работал до 18 марта 2008 года. В настоящий момент Буч руководит исследованиями и проектами IBM Research.
|
|
|
В это же время Джеймс Рамбо разрабатывал собственный метод ОМТ (Object Modeling Technique). OMT был ориентирован на анализ, а метод Буча — на проектирование программных систем. Вскоре Буч и Рамбо начали работу по объединению методов Booch и ОМТ под эгидой компании Rational Software.
К концу 1995 г. они создали первую спецификацию объединенного метода, названного ими Unified Method, версия 0.8.
Осенью 1995 года к ним присоединился Ивар Якобсон (Айвар Джекобсон), автор метода Object-Oriented Software Engineering — OOSE, обеспечивавшего возможности для спецификации бизнес-процессов и анализа требований при помощи сценариев использования.
Таким образом, UML является прямым объединением и унификацией методов Буча, Рамбо и Якобсона, однако дополняет их новыми возможностям
В настоящее время принят в качестве стандартного языка моделирования и получил широкую поддержку в индустрии создания ПО. UML принят на вооружение почти всеми крупнейшими компаниями~ производителями ПО (Microsoft, IBM, Hewlett-Packard, Oracle, Sybase и др.). Кроме того, почти все мировые производители CASE-средств поддерживают UML в своих продуктах
|
|
|
Полное описание UML можно найти на сайтах http://www.omg.org и http://www.rational.com.
Существует консорциум пользователей UML Partners включает в себя представителей таких грандов информационных технологий, как Rational Software, Microsoft, IBM, Hewlett-Packard, Oracle, DEC, Unisys, IntelliCorp, Platinum Technology.
UML представляет собой объектно-ориентированный язык визуального моделирования, который обеспечивает разработку репрезентативных моделей для организации взаимодействия заказчика и разработчика ИС, различных групп разработчиков ИС.
Объектная модель является наиболее естественным способом представления реального мира.
Основные цели, которые преследовались при разработке UML следующие:
· Предоставить пользователям готовый к использованию выразительный язык визуального моделирования, позволяющий им разрабатывать понятные им модели и возможность обмениваться ими для разных групп разработчиков (проектировщиков).
· Обеспечить независимость от конкретных языков программирования и процессов разработки
· Предусмотреть механизмы для расширения базовых концепций (ядра UML);
· Обеспечить формальную основу для понимания языка. Язык должен быть одновременно точным и доступным для понимания, без лишнего формализма.
|
|
|
Словарь UML включает три вида основных конструкций (строительных блоков):
P Сущности (предметы) – реальный или воображаемый объект (абстракции), имеющий существенное значение для рассматриваемой предметной области;
P Отношения связывают сущности;
P Диаграммы группируют представляющие интерес множества сущностей и отношений. Диаграммы позволяют описать поведение системы (для анализа) или показать детали архитектуры (для проектирования).
Сущности в UML.
Сущности (предметы) – реальный или воображаемый объект (абстракции), имеющий существенное значение для рассматриваемой предметной области;
1. Объект – осязаемая сущность – предмет или явление (процесс), имеющие четко определяемое поведение. Объект представляет собой абстракцию некоторой сущности предметной области (объект реального мира) или программной системы (архитектурный объект). Любой объект обладает состоянием (State), поведением (behavior) и индивидуальностью (identity).
На языке UML существует следующее представление:
- только имя объекта
2. Класс (class) - это множество объектов, связанных общими свойствами (атрибутами), поведением (операциями), связями и семантикой (смысл). Структура и поведение схожих объектов определяют общий для них класс. Термин экземпляр класса и объект являются эквивалентными.
|
|
|
3. Актер (actor) – роль, которую играют пользователи системы во время взаимодействия с ней. Актерами могут быть как люди, так и другие автоматизированные системы.
4. Прецедент (вариант использования) (use case) - это описание последовательности выполняемых системой действий, которая производит наблюдаемый результат, значимый для какого-то определенного актера.
В модели элемент Use Case применяется для структурирования предметов поведения. Элемент Use Case реализуется кооперацией.
5. Компонент (component) - это относительно независимая физическая заменяемая часть программного обеспечения системы,.
6. Узел (node) – физический элемент реальной системы, который существует во время функционирования программного продукта и представляет собой некоторый вычислительный ресурс. обычно имеющий память и возможности обработки. В узле размещается набор компонентов, который может перемещаться от узла к узлу.
1. Взаимодействие (interaction) - это поведение, суть которого заключается в обмене сообщениями (messages) между объектами в рамках конкретного контекста для достижения определенной цели.
Взаимодействие может определять динамику как совокупности объектов, так и отдельной операции. Элементами взаимодействия являются сообщения, последовательность действий (поведение, вызываемое сообщением) и связи (соединения между объектами).
2. Автомат (state machine) - поведение, определяющее последовательность состояний объекта, через которые объект проходит на протяжении своего жизненного цикла в ответ на различные события, а также реакции на эти события.
С помощью конечного автомата может определяться поведение индивидуального класса или кооперации классов. Элементами конечного автомата являются состояния, переходы (от состояния к состоянию), события (предметы, вызывающие переходы) и действия (реакции на переход).
Пакеты (packages) представляют собой универсальный механизм распределения элементов в группы. В пакет могут помещаться структурные предметы, предметы поведения и даже другие группировки предметов. В отличие от компонента (который существует в период выполнения), пакет — чисто концептуальное понятие. Это означает, что пакет существует только в период разработки.
9. Диаграмма Вариантов использования в UML: назначение, принципы построения
Разработку спецификаций программного обеспечения начинают с анализа требований к функциональности, указанных в техническом задании. В процессе анализа выявляют внешних пользователей разрабатываемого программного обеспечения и перечень отдельных аспектов его поведения в процессе взаимодействия с конкретными пользователями.
Идея описать функциональные требования в виде вариантов использования была сформулирована в 1986 году Иваром Якобсоном. Эта идея была признана конструктивной и получила широкое одобрение. Впоследствии наиболее значительный вклад в решение проблемы определения сущности вариантов использования и способов их описания внес Алистер Коберн.
Диаграмма отражает динамические аспекты поведения системы. Диаграммы использования описывают функциональность ИС, которая будет видна пользователям системы. Каждая функциональность изображается в виде прецедентов (вариантов использования (use case).
Вариант использования (use case). представляет собой последовательность действий (транзакций), выполняемых системой в ответ на событие, инициируемое некоторым внешним объектом (действующим лицом). Вариант использования:
· описывает типичное взаимодействие между пользователем и системой
· отражает представление о поведении системы с точки зрения пользователя.
В простейшем случае вариант использования определяется в процессе обсуждения с пользователем тех функций, которые он хотел бы реализовать, или целей, которые он преследует по отношению к разрабатываемой системе.
Не следует путать вариант использования с конкретными операциями будущей системы. Каждый вариант использования связан с некоторой целью, имеющей самостоятельное значение, например для текстового редактора Формирование оглавления - это вариант использования, а Связывание заголовков со специальными стилями - операция, которую необходимо выполнить, чтобы стало возможно автоматическое построение оглавления.
Обозначается на диаграмме овалом, связанным с пользователями, которых принято называть действующими лицами (актеры, actors).
Таким образом, вариант использования — это типичное взаимодействие пользователя с системой, которое:
· описывает видимую пользователем функцию,
· может представлять различные уровни детализации,
· обеспечивает достижение конкретной цели, важной для пользователя.
Действующее лицо (actor) — это роль, которую пользователь играет по отношению к системе. Действующие лица представляют собой роли, а не конкретных людей или наименования работ. На диаграмме изображается только одно действующее лицо, однако реальных пользователей, выступающих в данной роли по отношению к ИС, может быть много.
Несмотря на то, что на диаграммах вариантов использования они изображаются в виде стилизованных человеческих фигурок, действующее лицо может также быть внешней системой, которой необходима некоторая информация отданной системы.
Действующие лица делятся на 4 основных типа — пользователи системы, другие системы, взаимодействующие с данной, какие-либо технические средства, взаимодействующие с разрабатываемым программным обеспечением, и время. Время становится действующим лицом, если от него зависит запуск каких-либо событий в системе.
Список всех прецедентов фактически определяет функциональные требования к ИС, которые лежат в основе разработки технического задания на создание системы.
Для наглядного представления вариантов использования применяются диаграммы вариантов использования (диаграммы прецедентов). Она отражает функциональные требования к системе с точки зрения пользователя, какие действующие лица инициируют ВИ.
Таким образом, варианты использования — это функции, выполняемые системой, а действующие лица — это заинтересованные лица (stakeholders) по отношению к создаваемой системе. Такие диаграммы показывают, какие действующие лица инициируют варианты использования. Направленная от варианта использования к действующему лицу стрелка показывает, что вариант использования предоставляет некоторую информацию, используемую действующим лицом.
Действующие лица могут играть различные роли по отношению к варианту использования. Они могут пользоваться его результатами, инициировать действие, сами непосредственно в нем участвовать. Значимость различных ролей действующего лица зависит от того, каким образом используются его связи.
Цель построения диаграмм ВИ – документирование функциональных требований к системе в самом общем виде, поэтому они должны быть предельно простыми.
Правила построения ДВИ
1. Не моделировать связи между актерами. По определению действующие лица находятся вне сферы действия системы. Это означает, что связи между ними также не относятся к ее компетенции.
2. Не соединяйте стрелкой два варианта использования непосредственно. Диаграммы данного типа описывают только сами варианты использования, а не порядок их выполнения. Для отображения порядка выполнения вариантов использования применяют диаграммы деятельности и сценарии вариантов использования.
3. Каждый ВИ должен быть инициирован актером. Т.е. всегда должна быть стрелка, начинающаяся на актере и заканчивающаяся на ВИ (исключение – те случаи, когда происходит передача управления другой системе или используется тип связи - расширение).
Как определить варианты использования:
Хорошим источником для идентификации вариантов использования служат внешние события. Следует начать с перечисления всех событий, происходящих во внешнем мире, на которые система должна каким-то образом реагировать. Какое-либо конкретное событие может повлечь за собой реакцию системы, не требующую вмешательства пользователей, или, наоборот, вызвать чисто пользовательскую реакцию. Идентификация событий, на которые необходимо реагировать, помогает идентифицировать варианты использования.
Различные разработчики подходят к описанию вариантов использования с разной степенью детализации. Например, Ивар Якобсон утверждал, что для проекта с трудоемкостью 10 человеко-лет количество вариантов использования может составлять около 20 (не считая связей «включения» и «расширения»). Следует предпочитать небольшие и детализированные варианты использования, поскольку они облегчают составление и реализацию согласованного плана проекта.
Достоинства модели вариантов использования:
1. определяет пользователей и границы системы
2. определяет системный интерфейс
3. удобна в общении пользователя и разработчика
4. используется для написания тестов
5. является основой для написания пользовательской документации
6. хорошо вписывается в любые методы проектирования.
10. Диаграмма Классов в UML: назначение, принципы построения.
Диаграммы классов - центральное звено объектно-ориентированных методов разработки программного обеспечения, поэтому все существующие методы используют диаграммы классов в одной из известных нотаций. Однако в основном диаграммы классов в этих методах применяют на этапе проектирования, для того чтобы показать особенности построения конкретных классов.
На диаграммах класс изображается в виде прямоугольника, внутри которого указано имя класса, атрибуты классов, операции классов и ограничения, которые накладываются на связи между классами. Линии между классами отображают отношения (или ассоциации) между ними. Сообщения обозначаются ярлыками возле стрелок, они могут иметь нумерацию и показывать возвращаемые значения.
Между классами возможны различные отношения.
Изначально, на этапе анализа программного обеспечения между классами устанавливаются ассоциации и обобщения.
Отношение ассоциации означает наличие связи между экземплярами классов или объектами, Когда класс участвует в ассоциации, он играет в этом отношении определенную роль. Роль определяет, каким представляется класс на одном конце ассоциации для класса на противоположном конце ассоциации.
Обобщение (Generalization), это отношение между общей сущностью (родителем — класс "клиент") и ее конкретным воплощением (потомком — классы "корпоративный клиент" или "частный клиент"). Объекты класса-потомка могут использоваться всюду, где встречаются объекты класса-родителя, но не наоборот. При этом он наследует свойства родителя (его атрибуты и операции). Операция потомка с той же сигнатурой, что и у родителя, замещает операцию родителя.
На этапе анализа достаточно указать ассоциации и обобщение классов. На этапе проектирования необходимо уточнить отношений между ними. Па этапе проектирования помимо ассоциации и обобщения различают еще два типа отношения между классами: агрегацию и композицию.
К сожалению, до настоящего времени не существует единой устоявшейся терминологии объектно-ориентированного проектирования. Агрегацией называют ассоциацию между целым и его частью или частями. Агрегацию вместо ассоциации указывают, если отношение «целое-часть» в конкретном случае существенно.
Например, если колесо нас интересует только как часть автомобиля, то между соответствующими классами целесообразно указать отношение агрегации, а если колесо - товар, также как и автомобиль, то связь целое-часть не существенна.
Композиция - более сильная разновидность агрегации, которая подразумевает, что объект-часть может принадлежать только единственному целому. Объект-часть при этом создается и уничтожается только вместе со своим целым.
Уточненные отношения между классами фиксируют на диаграмме классов. Для этого используют специальные уловные обозначения. Поскольку отношение ассоциации и его подвиды (агрегация и композиция) означают наличие обмена сообщениями между объектами классов целесообразно уточнить направление передачи сообщений. Навигацию (направление ассоциации) показывают стрелкой на конце линии ассоциации. Если стрелки указаны с обеих сторон, то это означает двунаправленную ассоциацию.
11. Диаграмма Последовательности в UML: назначение, принципы построения.
Диаграммы последовательностей отображают взаимодействие объектов, упорядоченное по времени. На ней показывают внутренние объекты, а также последовательность сообщений, которыми обмениваются объекты в процессе реализации фрагмента варианта использования, называемого сценарием.
Этот вид диаграмм используется для точного определения логики сценария выполнения ВИ. Диаграммы последовательностей отображают объекты, взаимодействующих при исполнении прецедентов. Они отображаются в верхней части диаграммы в виде прямоугольников на вершине пунктирной вертикальной линии. Эта вертикальная линия называется линией жизни (lifeline) объекта. Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия.
Объекты изображают в виде прямоугольников, внутри которого указана информация, идентифицирующая объект: имя, имя объекта и имя класса или только имя класса.
Каждое сообщение представляют в виде линии со стрелкой, соединяющей линии жизни двух объектов. Эти линии помещают на диаграмму в порядке генерации сообщений (сверху вниз и слева направо). Стрелки с надписями названий методов означают вызов метода у объекта. Сообщения появляются в том порядке, как они показаны на диаграмме сверху-вниз. Если предусматривается отправка сообщения объектом самому себе (самоделегирование), то стрелка начинается и заканчивается на одной "линии жизни".
Не все объекты, показанные на диаграмме, явно присутствуют в потоке событий. Там, например, может не быть форм для заполнения, но их необходимо показать на диаграмме, чтобы позволить действующему лицу ввести новую информацию в систему или просмотреть ее. В потоке событий, скорее всего, также не будет и управляющих объектов (control objects). Эти объекты управляют последовательностью событий в варианте использования.
На диаграммы может быть добавлена управляющая информация: описание условий, при которых посылается сообщение; признак многократной отправки сообщения (маркер итерации); признак возврата сообщения.
12. Диаграмма Состояний в UML: назначение, принципы построения.
Диаграммы состояний используются для описания поведения сложных систем. Они определяют все возможные состояния, в которых может находиться объект, а также процесс смены состояний объекта в результате некоторых событий. Эти диаграммы обычно используются для описания поведения одного объекта в нескольких прецедентах.
Диаграмма состояний показывает:
1) набор состояний объекта;
2) события, которые вызывают переход из одного состояния в другое;
3) действия, которые происходят в результате изменения состояния.
Существует много форм диаграмм состояний, незначительно отличающихся друг от друга семантикой.
Состояние изображается как закругленный прямоугольник, обычно включающий его имя и подсостояния (если они есть). Состояниям соответствуют определенные значения атрибутов объектов. Имеется также два вида псевдо-состояний: начальное состояние, в котором находится только что созданный объект, и конечное состояние, которое объект не покидает, как только туда перешел.
Между состояниями возможны различные типы переходов. Обычно переход инициируется событием. Допускаются переходы и без событий. Наконец, разрешены условные или охраняемые переходы.
В общем случае переходы имеют метки, которые синтаксически состоят из трех необязательных частей
<Событие> <[Условие]> < / Действие>.Стрелки представляют переходы от одного состояния к другому, которые вызываются выполнением некоторых функций объекта.
На рисунке обозначено:
Событие — происшествие, вызывающее изменение состояния,
Действие — набор операций, запускаемых событием.
Иначе говоря, события вызывают переходы, а действия являются реакциями на переходы.
Порядок выполнения условного перехода:
1) происходит событие;
2) вычисляется условие УсловиеПерехода;
3) при УсловиеПерехода=true запускается переход и активизируется действие, в противном случае переход не выполняется.
На диаграммах также отображаются функции, которые выполняются объектом в определенном состоянии (действия в состоянии). Синтаксис метки деятельности: выполнить/< деятельность >.
Для указания действий, выполняемых при входе в состояние и при выходе из состояния, используются метки entry и exit соответственно. Например, при входе в состояние Активна выполняется операция УстановитьТревогу() из класса Контроллер, а при выходе из состояния — операция СбросТревоги().
Действие, которое должно выполняться, когда система находится в данном состоянии, указывается после метки do. Считается, что такое действие начинается при входе в состояние и заканчивается при выходе из него. Например, в состоянии Активна это действие ПодтверждатьТревогу().
На слайде приведен пример диаграммы состояний для банковского счета. Из данной диаграмме видно, в каких состояниях может существовать счет. Можно также видеть процесс перехода счета из одного состояния в другое. Например, если клиент требует закрыть открытый счет, он переходит в состояние «закрыт».
Требование клиента называется событием (event), именно такие события и вызывают переход из одного состояния в другое. Если клиент снимает деньги с открытого счета, он может перейти в состояние «Превышение кредита». Это происходит, только если баланс по этому счету меньше нуля, что отражено условием [отрицательный баланс] на диаграмме. Заключенное в квадратных скобках ограничивающее условие (guard condition) определяет, когда может или не может произойти переход из одного состояния в другое.
На диаграмме имеются два специальных состояния — начальное (start) и конечное (stop). Начальное состояние выделено черной точкой, оно соответствует состоянию объекта, когда он только что был создан. Конечное состояние обозначается черной точкой в белом кружке, оно соответствует состоянию объекта непосредственно перед его уничтожением.
На диаграмме состояний может быть только одно начальное состояние, а конечных состояний может быть столько, сколько нужно, или их может не быть вообще. Когда объект находится в каком-то конкретном состоянии, могут выполняться различные процессы.
При превышении кредита клиенту посылается соответствующее сообщение. Процессы, происходящие, когда объект находится в определенном состоянии, называются действиями (actions). С состоянием можно связывать данные пяти типов: деятельность, входное действие, выходное действие, событие и история состояния.
Диаграммы состояний не надо создавать для каждого класса, они применяются только в сложных случаях. Если объект класса может существовать в нескольких состояниях и в каждом из них ведет себя по-разному, для него может потребоваться такая диаграмма.
Дата добавления: 2016-01-05; просмотров: 85; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!