Языки конструирования

1. Конфигурационные языки

2. Инструментальные языки

3. Языки программирования (Алгоритмические языки)

Конфигурационные языки

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

Как правило, последовательность задач с помощью подобной системы может реализовывать оператор вручную. Однако для повышения надежности и производительности работы системы, обычно используются специальные языки, которые называются конфигурационными. (AutoCAD, EMACS, LaTeX).

Инструментальные языки

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

Язык C изначально проектировался как инструментальный язык для поддержки компонентов операционных систем. Мощь языка состоит в использовании библиотеки LIBC.

ДИАГРАММЫ UML

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

• Диаграммы вариантов использования

• Диаграммы последовательности

• Кооперативные диаграммы

• Диаграмма классов

• Диаграмма состояний

• Диаграмма компонентов

• Диаграмма размещения

Диаграммы иллюстрируют различные аспекты системы. Например, Кооперативная диаграмма по­казывает, как должны взаимодействовать объекты, чтобы реализовать некоторую функциональность системы. У каждой диаграммы есть своя цель и своя аудитория.

Диаграммы вариантов использования

Диаграммы Вариантов Использования отображают взаимодействие между вариантами использова­ния, представляющими функции системы, и действующими лицами, представляющими людей или си­стемы, получающие или передающие информацию в данную систему. Пример диаграммы Вариантов Использования для банковского автомата (Automated Teller Machine, ATM) показан на рис. 1.8.

На диаграмме представлено взаимодействие между вариантами использования и действующими лицами. Она отражает требования к системе с точки зрения пользователя. Таким образом, варианты использования — это функции, выполняемые системой, а действующие лица — это заинтересованные лица (stakeholders) по отношению к создаваемой системе. Диаграммы "показывают, какие действую­щие лица инициируют варианты использования. Из них также видно, когда действующее лицо полу­чает информацию от варианта использования. В сущности, диаграмма Вариантов Использования может иллюстрировать требования к системе. В нашем примере клиент банка иллюстрирует различ­ные варианты использования: Снять деньги со счета, Перевести деньги, Положить деньги на счет, Показать баланс, Изменить идентификационный номер, Произвести оплату. Банковский служащий может инициировать вариант использования "Изменить идентификационный номер". От варианта использования "Произвести оплату" идет стрелка к Кредитной системе. Действующими лицами могут быть и внешние системы, в данном случае Кредитная система показана именно как действующее лицо — она является внешней для системы ATM. Стрелку, направленная от варианта использования к действующему лицу, показывает, что вариант использования предоставляет некоторую информацию действующему лицу. В данном случае вариант использования "Произвести оплату" предоставляет Кре­дитной системе информацию об оплате по кредитной карточке.

Из диаграмм Вариантов Использования можно получить довольно много информации о системе. Этот тип диаграмм описывает общую функциональность системы. Пользователи, менеджеры проек­тов, аналитики, разработчики, специалисты по контролю качества и все, кого интересует система в целом, могут, изучая диаграммы Вариантов Использования, понять, что система должна делать.

Диаграммы Последовательности

Диаграммы Последовательности отражают поток событий, происходящих в рамках варианта исполь­зования. Например, вариант использования "Снять'деньги" предусматривает несколько возможных последовательностей: снятие денег, попытка снять деньги при отсутствии их достаточного количест­ва на счету, попытка снять деньги по неправильному идентификационному номеру и некоторые дру­гие. Нормальный сценарий снятия $20 со счета (при отсутствии таких проблем, как неправильный идентификационный номер или недостаток денег на счету) показан на рис. 1.9.

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

Вариант использования начинается, когда клиент вставляет свою карточку в устройство для чте­ния — этот объект показан в прямоугольнике в верхней части диаграммы. Он считывает номер кар­точки, открывает объект "счет Джо" (account) и инициализирует экран ATM. Экран запрашивает у Джо его регистрационный номер. Клиент вводит число 1234. Экран проверяет номер у объекта "счет Джо" и обнаруживает, что он правильный. Затем экран предоставляет Джо меню для выбора, и тот выбирает пункт "Снять деньги". Экран запрашивает, сколько он хочет снять, и Джо указывает $20. Эк­ран снимает деньги со счета. При этом он инициирует серию процессов, выполняемых объектом "счет Джо". Во-первых, осуществляется проверка, что на этом счету лежат, по крайней мере, $20. Во-вторых, из счета вычитается требуемая сумма. Затем кассовый аппарат получает инструкцию вы­дать чек и $20 наличными. Наконец все тот же объект "счет Джо" дает устройству для чтения карто­чек инструкцию вернуть карточку.

Итак, данная диаграмма Последовательности иллюстрирует последовательность действий, реали­зующих вариант использования "Снять деньги со счета" на конкретном примере снятия клиентом Джо $20. Глядя на эту диаграмму, пользователи знакомятся со спецификой своей работы. Аналитики видят последовательность (поток) действий, разработчики — объекты, которые надо создать, и их операции. Специалисты по контролю качества поймут детали процесса и смогут разработать тесты для их проверки. Таким образом, диаграммы Последовательности полезны всем участникам проекта.

Кооперативные диаграммы

Кооперативные диаграммы отражают ту же самую информацию, что и диаграммы Последовательно­сти. Однако делают они это по-другому и с другими целями. Показанная на рис. 1.9 диаграмма После­довательности представлена на рис. 1.10 в виде Кооперативной диаграммы.

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

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

Диаграммы Классов

Диаграммы Классов отражают взаимодействие между классами системы. Классы можно рассматри­вать как типы объектов. Например, счет Джо — это объект. Типом такого объекта можно считать счет вообще, т.е. "Счет" (Account) — это класс. Классы содержат данные и поведение (дейст­вия), влияющее на эти данные. Так, класс Account содержит идентификационный номер клиента и проверяющие его действия. На диаграмме Классов класс создается для каждого типа объектов из диа­грамм Последовательности или Кооперативных диаграмм. Диаграмма Классов для варианта исполь­зования "Снять деньги" показана на рис. 1.11.

На диаграмме показаны связи между классами, реализующими вариант использования "Снять де­ньги". В этом процессе задействованы четыре класса: Card Reader (устройство для чтения карточек), Account (счет), ATM.Screen (экран ATM) и Cash Dispenser (кассовый аппарат). Каждый класс на диа­грамме Классов изображается в виде прямоугольника, разделенного на три части. В первой части ука­зывается имя класса, во второй — его атрибуты. Атрибут — это некоторая информация, характеризующая класс. Например, класс Account (счет) имеет три атрибута: Account Number (номер счета), PIN (идентификационный номер) и Balance (баланс). В последней части содержатся опера­ции класса, отражающие его поведение (действия, выполняемые классом). Для класса Account определены четыре операции: Open (открыть), Withdraw Funds (снять деньги), Deduct Funds (вы­честь сумму денег из счета) и Verify Funds (проверить наличие денег).

Связывающие классы линии показывают взаимодействие между классами. Так, класс Account (счет) связан с классом ATM Screen (экран ATM), потому что они непосредственно взаимодействуют друг с другом. Класс Card Reader (устройство для чтения карточек) не связан с классом Cash Dispenser (кассовый аппарат), поскольку они не общаются друг с другом непосредственно. Обратите внимание, что слева от некоторых атрибутов и операций имеются маленькие значки в виде висячего замка. Они указывают, что атрибут или операция класса закрыта (private). Доступ к закрытым атрибутам или опе­рациям возможен только из содержащего их класса. Account Number, PIN и Balance — закрытые атри­буты класса Account. Кроме того, закрытыми являются операции Deduct Funds и Verify Funds.

Разработчики используют диаграммы Классов для реального создания классов. Такие инструмен­ты, как Rose, генерируют основу кода классов, которую программисты заполняют деталями на вы­бранном ими языке. С помощью этих диаграмм аналитики могут показать детали системы, а архитекторы — понять ее проект. Если, например, какой-либо класс несет слишком большую функци­ональную нагрузку, это будет видно на диаграмме классов, и архитектор сможет перераспределить ее между другими классами. С помощью диаграммы можно также выявить случаи, когда между сообщаю­щимися классами не определено никаких связей. Диаграммы Классов следует создавать, чтобы пока­зать взаимодействующие классы в каждом варианте использования. Можно строить также более общие диаграммы, охватывающие все системы или подсистемы.

Диаграммы Состояний

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

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

На данной диаграмме показаны возможные состояния счета, а также процесс перехода счета из одного состояния в другое. Например, если клиент требует закрыть открытый счет, последний пере­ходит в состояние "Закрыт". Требование клиента называется событием (event), именно события вызы­вают переход из одного состояния в другое.

Когда клиент снимает деньги с открытого счета, счет может перейти в состояние "Превышение кредита". Это происходит, только если баланс по счету меньше нуля, что отражено условием [отрица­тельный баланс] на нашей диаграмме. Заключенное в квадратные скобки условие (guard condition) определяет, когда может или не может произойти переход из одного состояния в другое.

На диаграмме имеются два специальных состояния — начальное (start) и конечное (stop). Начальное состояние выделяется черной точкой, оно соответствует состоянию объекта в момент его создания. Конечное состояние обозначается черной точкой в белом кружке, оно соответствует состоянию объ­екта непосредственно перед его уничтожением. На диаграмме Состояний может быть одно и только одно начальное состояние. В то же время может быть столько конечных состояний, сколько вам нуж­но, или их может не быть вообще.

Когда объект находится в каком-то конкретном состоянии, могут выполняться те или иные про­цессы. В нашем примере при превышении кредита клиенту посылается соответствующее сообщение. Процессы, происходящие, когда объект находится в определенном состоянии, называются действия­ми (actions).

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

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

Диаграммы Компонентов

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

В среде Rose каждый класс модели преобразуется в компонент исходного кода. Созданные компо­ненты сразу добавляются к диаграмме Компонентов. Затем указываются зависимости между отдель­ными компонентами, соответствующие зависимостям на этапе компиляции или выполнения программы.

На рис. 1.13 изображена одна из диаграмм Компонентов для системы ATM.

На этой диаграмме показаны компоненты клиента системы ATM. В данном случае команда разра­ботчиков решила строить систему с помощью языка C++. У каждого класса имеется свой собственный заголовочный файл и файл с расширением . СРР, так что каждый класс преобразуется в свои собствен­ные компоненты на диаграмме. Например, класс ATM Screen преобразуется в два компонента ATM Screen диаграммы. Вместе эти компоненты представляют тело и заголовок класса ATM Screen. Выде­ленный темным компонент называется спецификацией пакета (package specification) и соответствует файлу тела класса ATM Screen на языке C++ (файл с расширением .СРР). Невыделенный компонент также называется спецификацией пакета, но соответствует заголовочному файлу класса языка C++ (файл с расширением . H). Компонент АТМ.ехе является спецификацией задачи и представляет поток обработки информации (thread of processing). В данном случае поток обработки программы. Компоненты соединены штриховой линией, отображающей зависимости между ними. Например, класс Card Reader зависит от класса ATM Screen. Следовательно, для того чтобы класс Card Reader мог быть скомпилирован, класс ATM Screen должен уже существовать. После компиляции всех клас­сов может быть создан исполняемый файл ATMClient.exe. Пример ATM содержит два потока обработки, и таким образом получаются два исполняемых фай­ла. Один из них — это клиент ATM, он содержит компоненты Cash Dispenser, Card Reader и ATM Screen. Второй файл — сервер ATM, включающий в себя компонент Account. Диаграмма Компонен­тов для сервера ATM

Как видно из примера, у системы может быть несколько диаграмм Компонентов в зависимости от числа подсистем или исполняемых файлов. Каждая подсистема является пакетом компонентов. В об­щем случае, пакеты — это совокупности компонентов (см. раздел "Основы Rose" главы 3). В примере ATM используются два пакета: клиент ATM и сервер ATM.

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

Диаграммы Размещения

Диаграммы Размещения показывают физическое расположение различных компонентов системы в сети. В нашем примере система ATM состоит из большого количества подсистем, выполняемых на от­дельных физических устройствах, или узлах (node). Диаграмма Размещения для системы ATM пред­ставлена на рис. 1.15.

Из данной диаграммы можно узнать о физическом размещении системы. Клиентские программы ATM будут работать в нескольких местах на различных сайтах. Через закрытые сети будет осуществ­ляться сообщение клиентов с региональным сервером ATM. На нем будет работать программное обеспечение сервера ATM. В свою очередь, посредством локальной сети региональный сервер будет взаимодействовать с сервером банковской базы данных, работающим под управлением Oracle. Нако­нец с региональным сервером ATM соединен принтер.

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

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

Rational Rose

Rational Rose — мощный инструмент анализа и проектирования объектно-ориентированных програм­мных систем. Он позволяет моделировать системы до написания кода, так что вы можете с самого на­чала быть уверены в адекватности их архитектуры. С помощью готовой модели недостатки проекта легко обнаружить на стадии, когда их исправление не требует еще значительных затрат.

Среда Rational Rose позволяет проектировать варианты использования и их диаграммы для визуа­лизации функциональных возможностей системы. Диаграммы Взаимодействия показывают, как объ­екты работают совместно, обеспечивая требуемые функциональные возможности. Для отображения объектов системы и их отношений используются диаграммы Классов. Диаграммы Компонентов ил­люстрируют, как классы соотносятся с готовыми физическими компонентами системы. Наконец диа­граммы Размещения применяют для визуализации проекта распределенных систем.

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

Такой чертеж помогает решить старую проблему. Допустим, команда разработчиков обсудила с пользователями и документировала требования к приложению. Программисты готовы писать код. Один из них (назовем его Боб) берет часть требований, принимает определенные решения и пишет некоторый фрагмент кода. Другой (Джейн) тоже берет часть требований, принимает свои, совер­шенно отличающиеся от первого, решения по проекту и пишет другой код.

Естественно ожидать различие в стилях программирования; получив одинаковый набор требова­ний, 20 разработчиков создадут 20 различных систем. Таким образом, без подробного обсуждения ра­боты с каждым участником проекта будет трудно понять, какие решения по проекту приняты, из каких элементов состоит система и что представляет собой ее общая структура. Не имея документи­рованного проекта, трудно даже быть уверенным, что созданное приложение — это именно то, чего хотели пользователи.

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

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

Модель Rose предлагает совершенно другой подход:

В этом случае проект уже документирован. Разработчики могут собраться вместе и обсудить при­нимаемые по проекту решения до фактического написания кода. Вам не нужно больше беспокоиться, что каждый из них пойдет своим путем в проектировании частей одного и того же приложения

Однако модели используют не только разработчики:

• С помощью диаграмм Вариантов Использования потребители и менеджеры проекта получат общее представление о системе и смогут принять решение о сфере ее применения.

• С помощью диаграмм Вариантов Использования и документации менеджеры проекта смогут разделить проект на отдельные управляемые задачи*

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

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

• Из диаграмм Последовательности и Кооперативных диаграмм аналитики и разработчики уяс­нят, насколько логично работает система, поймут ее объекты и сообщения между ними.

• С помощью документации по вариантам использования, а также диаграмм Последовательно­сти и Кооперативных диаграмм специалисты по контролю качества смогут получить информа­цию, требуемую им для написания тестовых сценариев.

• С помощью диаграмм Классов и Состояний разработчики получат представление о фрагмен­тах системы и их взаимодействии друг с другом.

• Из диаграмм Компонентов и Размещения эксплуатационный персонал сможет узнать, какие .EXE и .DLL файлы и другие компоненты будут созданы, а также где в сети они должны быть размещены.

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

Итак, Rose — это средство, которое может быть использовано всеми участниками проекта. Это, фактически, хранилище информации о контексте и проекте системы, из которого каждый участник проекта извлекает то, что ему нужно.

Помимо всего вышесказанного, Rational Rose позволяет генерировать "скелетный код" на боль­шом количестве различных языков, включая C++, Java, Visual Basic и PowerBuilder. Более того, можно выполнять обратное проектирование кода и создавать таким образом модели уже существующих сис­тем. Весьма выгодно иметь модели Rose для уже существующих приложений. Если сделано изменение в модели, Rose позволяет модифицировать код для его реализации. Если же был изменен код, можно автоматически обновить соответствующим образом и модель. Благодаря этому удается поддерживать соответствие между моделью и кодом, уменьшая риск "устаревания" первой.

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

ДИАГРАММА ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ

Диаграмма Вариантов Использования содержит некоторые варианты использования системы, некото­рых действующих лиц и связи между ними. Вариант использования (use case) — это описание функцио­нальности системы на "высоком уровне". Действующее лицо (actor) — это все, что взаимодействует с системой. На рис. 3.1 приведен пример диаграммы Вариантов Использования.

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

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

Часто для одной системы создается несколько диаграмм Вариантов Использования. На диаграмме высокого уровня, называемой в среде Rational Rose Главной (Main), указываются только пакеты (группы) вариантов использования. Другие диаграммы описывают совокупности вариантов исполь­зования и действующих лиц. Может потребоваться также нанести на одну диаграмму все варианты ис­пользования и всех действующих лиц системы. Количество и состав создаваемых диаграмм Вариантов Использования полностью зависит от вас. Важно только, чтобы они содержали достаточ­но информации, чтобы быть полезными, но не слишком много, чтобы не привести в замешательство.

Конкретная цель диаграмм Вариантов Использования — документирование вариантов использова­ния (все входящее в сферу применения системы), действующих лиц (все вне этой сферы) и связей между ними. Разрабатывая диаграммы Вариантов Использования, старайтесь придерживаться следу­ющих правил:

Не моделируйте связи между действующими лицами. По определению действующие лица нахо­дятся вне сферы действия системы. Это означает, что связи между ними также не относятся к ее компетенции. Для изучения коммуникации между действующими лицами применяется диа­грамма потоков работ (workflow diagram).

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

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

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