русс | укр

Языки программирования

ПаскальСиАссемблерJavaMatlabPhpHtmlJavaScriptCSSC#DelphiТурбо Пролог

Компьютерные сетиСистемное программное обеспечениеИнформационные технологииПрограммирование

Все о программировании


Linux Unix Алгоритмические языки Аналоговые и гибридные вычислительные устройства Архитектура микроконтроллеров Введение в разработку распределенных информационных систем Введение в численные методы Дискретная математика Информационное обслуживание пользователей Информация и моделирование в управлении производством Компьютерная графика Математическое и компьютерное моделирование Моделирование Нейрокомпьютеры Проектирование программ диагностики компьютерных систем и сетей Проектирование системных программ Системы счисления Теория статистики Теория оптимизации Уроки AutoCAD 3D Уроки базы данных Access Уроки Orcad Цифровые автоматы Шпаргалки по компьютеру Шпаргалки по программированию Экспертные системы Элементы теории информации

UML - унифицированный язык объектно-ориентированного моделирования


Дата добавления: 2015-07-09; просмотров: 2990; Нарушение авторских прав


 

Язык UML служит для определения, отображения и описания элементов объектно-ориентированных систем в процессе их создания. Он объединяет объектную модель, нотации Буча и ОМТ, а также лучшие идеи, предложенные авторами других методик. Таким образом, язык UML является стандартом де-факто в области объектно-ориентированного анализа и проектирования.

Универсальный язык UML - это попытка стандартизировать инструменты анализа и проектирования семантических моделей, синтаксических нотаций и диаграмм. Первая общедоступная версия (0.8) появилась в октябре 1995 года. Джекобсон и другие разработчики предложили несколько вариантов, которые были реализованы в последующих двух версиях (0.9 - в июле и 0.91 - в октябре 1996 года). Версия 1.0 была представлена для стандартизации в ассоциацию Object Management Group (OMG) в июле 1997 года. Дополнительные улучшения сделаны в версии 1.1, которая вышла в сентябре того же года, а в ноябре UML был утвержден ассоциацией OMG в качестве стандартного языка моделирования

 

Создатели UML представляют его как язык для определения, представления, проектирования и документирования программных систем, организационно-экономических систем, технических систем и других систем различной природы. UML содержит стандартный набор диаграмм и нотаций самых разнообразных видов. Стандарт UML версии 1.1, принятый OMG в 1997 г., предлагает следующий набор диаграмм для моделирования:

- диаграммы вариантов использования (use case diagrams) - для моделирования бизнес-процессов организации (требований к системе);

- диаграммы классов (class diagrams) - для моделирования статической структуры классов системы и связей между ними;

- диаграммы поведения системы (behavior diagrams):

- диаграммы взаимодействия (interaction diagrams):

- диаграммы последовательности (sequence diagrams) и кооперативные диаграммы (collaboration diagrams) –для моделирования процесса обмена сообщениями между объектами;



- диаграммы состояний (statechart diagrams) - для моделирования поведения объектов системы при переходе из одного состояния в другое;

- диаграммы деятельностей (activity diagrams) - для моделирования поведения системы в рамках различных вариантов использования, или моделирования деятельностей;

- диаграммы реализации (implementation diagrams):

- диаграммы компонентов (component diagrams) - для моделирования иерархии компонентов (подсистем) системы;

- диаграммы размещения (deployment diagrams) - для моделирования физической архитектуры системы.

 

Диаграммы вариантов использования (модели прецедентов)

 

Поведение разрабатываемой системы (то есть функциональность, обеспечиваемая системой) описывается с помощью функциональной модели, которая отображает системные прецеденты (use cases), системное окружение (действующих лиц или актеров - actors) и связи между прецедентами и актерами (диаграммы прецедентов - use cases diagrams). В нотации UML их чаще называют диаграммами вариантов использования. Основная задача модели прецедентов или диаграмм вариантов использования - представлять собой единое средство, дающее возможность заказчику, конечному пользователю и разработчику совместно обсуждать функциональность и поведение системы.

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

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

- только снабжать информацией систему;

- только получать информацию из системы;

- снабжать информацией и получать информацию из системы.

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

1. Кто заинтересован в определенном системном требовании?

2. Какую роль система будет выполнять в организации?

3. Кто получит преимущества от использования системы?

4. Кто будет снабжать систему информацией, использовать информацию и получать информацию от системы?

5. Кто будет осуществлять поддержку и обслуживание системы?

6. Использует ли система внешние ресурсы?

7. Выступает ли какой-либо участник системы в нескольких ролях?

8. Выступают ли различные участники в одной роли?

9. Будет ли новая система взаимодействовать со старой?

В языке UML актер изображается в виде фигуры человечка —

 

Актеры делятся на три основных типа - пользователи системы, другие системы, взаимодействующие с данной, и время.

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

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

1. Каковы задачи каждого актера?

2. Будет ли актер создавать, хранить, изменять, удалять или получать информацию из системы?

3. Какой прецедент будет создавать, хранить, изменять, удалять или получать эту информацию?

4. Должен ли актер информировать систему о внезапныхизменениях внешней среды?

5. Должен ли актер быть проинформирован об изменениях состояния системы?

6. Какие прецеденты будут поддерживать и обслуживать систему?

7. Могут ли все функциональные требования быть реализованы прецедентами?

В языке UML прецедент изображается в виде овала.

 

Между актером и прецедентом может существовать ассоциативное отношение. Такой тип связи часто называют коммуникативной ассоциацией (communicate association), потому что она отражает связь между актером и прецедентом.

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

Существует два типа отношений между прецедентами: включает и дополняет. Различные прецеденты могут иметь одинаково функционирующие фрагменты. Их обычно помещают в отдельный прецедент, чтобы не повторять несколько раз. Отношение включает (include relationship) создается, когда один из преце­дентов использует другой. Отношение включаетизображается как отношение зависимости, которое направлено от базового прецедента к используемому.

Отношение дополняет (extend relationship) применяется для отражения:

- дополнительных режимов;

- режимов, которые запускаются только при определенных условиях, например сигнала тревоги;

- альтернативных потоков, которые запускаются по выбору актера.

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

В языке UML существует понятие стереотипа (stereotype), с помощью которого создаются новые элементы модели путем расширения функциональности базовых элементов. Таким образом, это понятие позволяет языку UML иметь минимальный набор символов, которые могут быть при необходимости дополнены для создания связующих элементов в разрабатываемой системе. Имя стереотипа заключается в двойные треугольные скобки и помещается рядом с линией связи. Стереотипы используются для создания нужных отношений между прецедентами. Стереотип «communicate» может добавляться к ассоциации, чтобы показать, что это коммуникативная ассоциация. Но в этом нет необходимости, поскольку ассоциация - это единственный допустимый тип связи между актером и прецедентом. Отношения включает и дополняет должны использовать стереотипы, потому что они отображаются как отношение зависимости.

Диаграмма вариантов использованияилидиаграмма прецедентов (use case diagram) – это графическое представление всех или части актеров, прецедентов и их взаимодействий в системе. В каждой системе обычно есть главная диаграмма прецедентов, которая отображает границы системы (актеров) и основное функциональное поведение системы (прецеденты). Другие диаграммы прецедентов могут создаваться при необходимости.

Пример такой диаграммы для банковского автомата (Automated Teller Machine, ATM)

Пример use- cases диаграммы

 

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

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

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



<== предыдущая лекция | следующая лекция ==>
Сущность объектно-ориентированного подхода к анализу и проектированию | Диаграммы классов


Карта сайта Карта сайта укр


Уроки php mysql Программирование

Онлайн система счисления Калькулятор онлайн обычный Инженерный калькулятор онлайн Замена русских букв на английские для вебмастеров Замена русских букв на английские

Аппаратное и программное обеспечение Графика и компьютерная сфера Интегрированная геоинформационная система Интернет Компьютер Комплектующие компьютера Лекции Методы и средства измерений неэлектрических величин Обслуживание компьютерных и периферийных устройств Операционные системы Параллельное программирование Проектирование электронных средств Периферийные устройства Полезные ресурсы для программистов Программы для программистов Статьи для программистов Cтруктура и организация данных


 


Не нашли то, что искали? Google вам в помощь!

 
 

© life-prog.ru При использовании материалов прямая ссылка на сайт обязательна.

Генерация страницы за: 0.009 сек.