Мезенцев В.Л. Разработка модели бизнес-процессов при помощи программного средства Silverrun. Методическое пособие - файл n2.doc

Мезенцев В.Л. Разработка модели бизнес-процессов при помощи программного средства Silverrun. Методическое пособие
Скачать все файлы (415.2 kb.)

Доступные файлы (6):
n2.doc370kb.30.10.2004 04:35скачать
n3.doc207kb.07.04.2005 00:49скачать
n4.bpm
n5.txt2kb.24.09.2005 13:00скачать
n6.txt9kb.27.01.2005 01:01скачать
n7.doc243kb.27.01.2005 01:01скачать

n2.doc



Методическое пособие по Silverrun-BPM. Выполнили студенты гр. АОИ-00/I Леонтьева Ж.Г. и Межова О.В.

1. Основные требования при составлении модели бизнес – процессов.



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

П
остроение модели системы мы будем выполнять с использованием CASE – средства Silverrun. Это средство хорошо тем, что позволяет моделировать предметную область, анализировать модель на всех этапах разработки и информационного сопровождения, а так же разрабатывать приложения в соответствии с информационными потребностями пользователей. Установка программы производится простым копированием файлов. Запуск программы осуществляется путём двойного нажатия левой кнопки мыши на иконку (рисунок 1).

Рисунок 1.

После этого мы увидим Рабочую область (стандартное название Context) и панель инструментов.

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

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



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




- поток данных, определяет информацию, передаваемую через некоторое соединение от источника к приемнику. В случае с компанией, занимающейся ремонтом бытовой техники, это квитанция об оплате.
Для того чтобы отразить компоненты на диаграмме, необходимо вывести на экран панель инструментов BPM TOOLS. Данная панель выбирается из меню Display и подменю Toolbars.

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

2. Описание модели бизнес - процессов

для мастерской бытовой техники WorkShop.

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

В качестве примера рассмотрим диаграмму потоков данных для Отдела обслуживания клиента в мастерской бытовой техники (рисунок 1).

Для начала определимся, как происходит работа нашей мастерской.

Суть модели такова: Клиент приходит в мастерскую и делает заявку на ремонт своей бытовой техники. После этого он вносит предоплату, его заявка передается на рассмотрение. Один из специалистов Технической службы выполняет ремонт, сообщает о виде ремонта и своих затратах на него. Всё это обсчитывают по установленному Администрацией прейскуранту, вычитают предоплату, и составляют Квитанцию на окончательный расчёт. Затем клиенту сообщают о выполнении его заказа, выдают квитанцию, оплатив которую он получает своё изделие и гарантийный талон.

Из этого простого общего описания работы системы Клиент-мастерская можно сделать ряд выводов:

  1. в системе есть ряд физических лиц или структур, которые выдают и принимают информацию. В этой системе, как видно, их три: Клиент, Администрация и Техническая служба. Их мы будем называть внешними сущностями.

  2. кроме них в системе есть ещё различные подсистемы, которые отвечают за ту или иную область работы. Начнём с самого начала. Клиент приходит с заявкой. Её должны принять, обработать, выписать квитанцию на предоплату. Пусть этим будет заниматься Служба связи с Клиентом, основным лицом которой является Секретарь. Затем, Клиент должен внести предоплату, иначе его заявку просто не выполнят. Значит, нам нужна подсистема Приёма оплаты за ремонт. Её главой является Бухгалтер. Кроме того, заявку нужно передать в службу, которая сформирует перечень работ. Пусть этим будет заниматься служба Формирования перечня работ, главным исполнителем которой будет Мастер. В эту службу Бухгалтер обязан передать сведения о том, что предоплата поступила. После этого Мастер выписывает Наряд, который передается в Техническую службу. Техническая служба нашей Мастерской состоит из специалистов, каждый из которых отвечает за определённый вид бытовой техники. Конкретный специалист получает Наряд и выполняет ремонт. Теперь ему нужно отчитаться о проделанной работе. Для этого существует Акт приёмки выполненных работ. Специалист Технической службы, после заполнения Акта, должен передать его в подсистему, где каждый вид работ и зап.частей будет обсчитан для составления Квитанции на окончательный расчёт. Введём для этого подсистему Учёта выполненных работ. Здесь Экономист-сметчик произведёт расчёт по сформированному Администрацией прейскуранту, и составит Квитанцию на окончательный расчёт. Эта квитанция попадает в уже известную нам Службу связи с Клиентом. Теперь Секретарь связывается с Клиентом, сообщая ему о выполнении его заказа и окончательной сумме оплаты ремонта. Получив у Секретаря квитанцию, Клиент оплачивает её в службе Приёма оплаты за ремонт, получает гарантийный талон и свою теперь уже исправную технику.

3) но ведь должна ещё существовать некая форма отчётности и внутри самой мастерской! Чтобы решить эту проблему добавим в нашу систему базу данных или накопитель, в котором будет содержаться вся информация о производимых ремонтах, суммах оплаты и пр. Назовём эту базу данных Список оплаты. Сведения сюда должны поступать от лица, принимающего оплату, т.е. в нашей системе это будет Бухгалтер. Он заносит в базу данных сумму оплаты и заполняет прочие поля. Для формирования отчётов создадим отдельную подсистему, которая так и будет называться: служба Формирования отчётов. Во главе её стоит Менеджер. Именно он проверяет и обрабатывает всю поступившую в базу данных информацию и формирует отчёт, который предоставляет затем Администрации.

Так выглядит наша модель на самом верхнем уровне. Попробуем теперь реализовать её с помощью программы SILVERRUN-BPM.
Результатом нашей работы должна стать диаграмма процессов, выполненная с помощью Case– средства Silverrun, представленная на рисунке 2.





Рисунок 2.

Теперь детально рассмотрим описание каждого компонента нашей модели.

2.1.1. Описание внешних сущностей

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

Чтобы отобразить внешнюю сущность на диаграмме, нажимаем в стандартной панели кнопку (третья в правом ряду) а затем нажимаем левой кнопкой мыши на экране в области нашей диаграммы (Context).

Так же как и другие компоненты, он имеет свое имя. Нажав два раза курсором мыши по данному компоненту, мы увидим диалоговое окно (рис.3), в котором в поле EXTERNAL ENTITY NAME введём его имя (например, Клиент).





Рисунок 3.
2.1.2. Описание подсистем и процессов.

Первой подсистемой в нашем примере будет Служба связи с клиентом. Чтобы отобразить её на диаграмме, нажимаем один раз кнопку (вторая сверху в правом ряду панели BPM Tools), а затем нажимаем левой кнопкой мыши на экране в области нашей диаграммы (Context). Теперь необходимо подписать её.

Для этого нажимаем 2 раза кнопкой мыши на этот компонент. После этого появится диалоговое окно следующего вида (рис.4):





Рисунок 4.

Окно разбито на три части. В верхней части расположено поле номера, которое служит для его идентификации (данные номера проставляются автоматически, исправлять не рекомендуется). В центральной части расположено поле имени (сюда мы ввели фразу «Служба связи с клиентом»). Здесь следует учитывать следующие требования: для подсистем наименование имеет вид предложения с подлежащим и соответствующими определениями и дополнениями. В процессах в поле имени вводится предложение с активным недвусмысленным глаголом в неопределенной форме (вычислить, рассчитать, проверить, определить, создать, получить). В нижней части окна имеется поле физической реализации, служащее для отображения информации, которое показывает, какое подразделение организации, программа или аппаратное устройство выполняет данный процесс или подсистему.

Для заполнения поля физической реализации необходимо настроить ресурсы (объекты, которые выполняют какое-либо действие).

Для создания ресурсов выбираем пункт меню MODEL и подменю RESOURCES. После этого откроется окно (рисунок 5), в котором можно вводить и удалять ресурсы.

Рисунок 5.

Для подключения ресурсов выбираем пункт меню MODEL и подменю PROCESS. Из выпавшего меню выбираем LINКED RESOURCES. После этого появится диалоговое окно (рис.6).

В случае если этот объект (ресурс) уже участвовал при выполнении других процессов, его можно присвоить к выбранному процессу следующим путем. Для этого нажимаем кнопку , которая расположена в нижней части окна (рис.6). Теперь появится окно, в котором расположен список всех объектов выполняющих какое-либо действие (операцию) (рис.7). Далее выбираем нужный ресурс и нажимаем кнопку LINK (рис.7).

Д
ля подтверждения всех вышеперечисленных действий нажимаем на кнопку ОК (рис.6).
Рисунок 6.





Рисунок 7.

2.1.3. Описание накопителей данных (хранилища информации)

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

Итак, чтобы отобразить её на диаграмме, нажимаем в стандартной панели кнопку (четвёртая в правом ряду) а затем нажимаем левой кнопкой мыши на экране в области нашей диаграммы (Context).

П
осле двойного нажатия мыши по накопителю появится окно, в котором в поле STORE NAME введём имя накопителя (список оплаты в нашем примере) (рис.8).
Рисунок 8.
2.1.4. Описание потоков данных
Поток данных определяет информацию, передаваемую через некоторое соединение от источника к приемнику. На диаграмме поток данных изображается линией, оканчивающейся стрелкой, которая показывает направление потока. Каждый поток данных имеет имя, отражающее его содержание.

Чтобы поместить поток данных на нашу диаграмму, дважды нажимаем по значку (пятый сверху в правом ряду в стандартной панели инструментов). После этого появится окно (рис.9), в поле NAME которого мы введём имя потока данных (например, Сообщение о заявке).





Рисунок 9.

Н
ажимая один раз левой кнопкой мыши по диаграмме, мы фиксируем направление стрелки. Когда стрелка дорисована до конца, нажимаем левую кнопку мыши дважды. Чтобы отменить действие, нажимаем клавишу ESC. Можно также выбрать тип рисуемой стрелки. Для этого нажимаем по значку правой кнопкой мыши, после чего увидим панель (рис.10) и простым нажатием левой кнопкой мыши выбираем тип стрелки по умолчанию. (Как правило, мы пользуемся стрелками с прямым углом (нижняя на панели)).

Рисунок 10.

Любой из объектов можно удалить, выделив его и нажав на клавиатуре кнопку DELETE. Можно также менять размер объекта, перемещать его, опять же выделив, при помощи мыши. Можно изменять и размеры самого поля диаграммы. Для этого выделяем его одним нажатием левой кнопки мыши и сужаем (расширяем), двигая за появившиеся маркеры.

Таким образом, мы составляем верхний уровень нашей модели (её окончательный вид представлен на Рисунке 1).
2.2.Построение диаграмм нижнего уровня
Для построения или перехода на диаграмму нижнего уровня необходимо на стандартной панели инструментов BPM TOOLS нажать на кнопку с изображением мишени (вторая снизу в правом ряду) и щелкнуть на тот процесс или подсистему, которую собираемся детализировать (в нашем примере это будет подсистема Служба связи с клиентом). При создании диаграммы нижнего уровня все связанные компоненты с данным процессом или подсистемой автоматически появятся на диаграмме нижнего уровня.

Для перехода на диаграмму верхнего уровня необходимо на панели инструментов BPM TOOLS нажать на кнопку с изображением "толстой" стрелки вверх (третья снизу в правом ряду).

Рассмотрим построение диаграмм нижнего уровня для подсистемы Служба связи с клиентом.

Итак, при обращении в мастерскую с просьбой починить ту или иную бытовую технику, Клиент попадает в Службу связи с клиентом к Секретарю. Здесь, в первую очередь, запросят информацию о нём самом (процесс «Ввод сведений о клиенте»), об его технике и её дефекте (поломке) (процесс «Ввод сведений о заявке»). На основе Сведений о заявке, составляется перечень работ и комплектующих, которые передаются в подсистему Расчёт стоимости предоплаты. После этого Клиенту выпишут Квитанцию на предоплату, для выписки которой вновь понадобятся сведения о клиенте (пусть они заносятся в компьютер с целью дальнейшего их использования). Номер и содержание заявки передаются в уже известную нам подсистему верхнего уровня - Формирования перечня работ (1.2.). Выполнение ремонта остаётся за пределами подсистемы Служба связи с клиентом, т.к. в процессе ремонта Клиент никак не участвует. После выполнения ремонта, как мы уже знаем, составляется Акт о приёмке выполненных работ, который передаётся в подсистему 1.4. Учёт выполненных работ. Здесь экономист-сметчик составляет Смету на выполненные работы и обращается в Службу связи с клиентом, где происходит выписка квитанции на окончательную оплату. Эта квитанция является для Секретаря сигналом о том, что ремонт выполнен, поэтому он информирует клиента о выполнении заказа и передаёт ему квитанцию на окончательную оплату. На этом работа этой службы на данном уровне прекращается.

Теперь попробуем реализовать данную модель с помощью Case– средства Silverrun. (Окончательный вид модели представлен на рисунке 11)

Рисунок 11.
Данная диаграмма состоит из шести подпроцессов (1.1.1-1.1.6), двух процессов (1.2. и 1.4.) и с одной внешней сущность ЕЕ-1 Клиент.

Для того чтобы построить её, нажимаем на значок и один раз на процессе, который собираемся детализировать (у нас это процесс 1.1. Служба связи с клиентом). После этого мы попадаем в новое окошко – диаграмму под названием «Служба связи с клиентом». В этом окне уже будут те процессы, внешние сущности, связи и накопители, которые были у этого процесса на верхнем уровне. Их можно переместить, нажав левой кнопкой мыши один раз и, не отпуская, передвинув на нужное место. Чтобы добавить новый процесс (или любую другую сущность) нажимаем на соответствующий значок на стандартной панели инструментов и переносим её на поле диаграммы «Служба связи с клиентом».

Ч
тобы добавить процесс из уже существующих
, производим следующие действия. В главном меню нажимаем: Display-Toolbars, а в появившемся окне (рисунок 12) выбираем Processes.
Рисунок 12.

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

После этого расписываем детально каждое действие, выполненное на верхнем уровне. Например, первой связью у нас была Заявка от внешней сущности Клиент, которую принимает Секретарь. Значит, расписывая это действие более подробно получим два подпроцесса: «Ввод сведений о клиенте (1.1.1.)» и «Ввод сведений о заявке (1.1.2.)». Информация исходит от Клиента, о чём мы и можем судить, посмотрев на нашу модель (это отображают стрелки, идущие от внешней сущности Клиент к подпроцессам 1.1.1 и 1.1.2). Сведения о заявке, содержащие Перечень работ и комплектующих передаются в другой подпроцесс «Расчёт стоимости предоплаты» (1.1.3). Отсюда калькуляция заявки поступает в следующий подпроцесс «Выписка квитанции на предоплату». Эта квитанция поступает Клиенту, кроме того, её номер и содержание передаются в Подсистему 1.2. «Формирование перечня работ». После выполнения работы, из Подсистемы 1.4. «Учёт выполненных работ» от Экономиста-сметчика передаётся Смета на выполненные работы. Она попадает в подпроцесс «Выписка квитанции на окончательную оплату» 1.1.6. Эта квитанция передаётся в подпроцесс 1.1.5. «Информирование клиента о выполнении заказа». Отсюда Клиенту поступает информация о выполнении его заказа и передаётся квитанция для окончательной оплаты. Это все процессы, происходящие на данном уровне.

Попробуем ещё более детализировать один из подпроцессов уровня 1.1. Возьмём для примера подпроцесс 1.1.2 Ввод сведений о заявке. Опять нажимаем на кнопку и попадаем в поле диаграммы 1.1.2. Ввод сведений о заявке. По окончании наших построений оно будет иметь следующий вид (рисунок 13).
Рисунок 13.





Д
ля начала оговоримся, что Сведения о заявке представляют собой таблицу с полями, все данные из которых помещаются в базу данных. Поэтому мы добавляем накопитель «База данных «Сведения о заказе» (нажимаем кнопку стандартной панели и переносим накопитель на поле диаграммы Ввод сведений о заказе). Пусть наша база данных содержит следующие поля: Сведения о ремонтируемой технике, её марка; Описание поломки; Дата заказа. Их заполнение отражено в подпроцессах 1.1.2.1, 1.1.2.2, 1.1.2.4. соответственно. Данные сведения поступают от Клиента, поэтому потоки данных (стрелки) идут от него к соответствующим подпроцессам. Кроме того, на данной диаграмме мы впервые воспользуемся пунктирными стрелками, которые отражают последовательность перехода (в нашем случае это переход курсора с одного поля базы данных на другое). Для того, чтобы её изобразить, как всегда, нажимаем кнопку . После того, как мы нарисовали стрелку, дважды нажимаем на неё и в появившемся окне ставим галочку в поле Control (слева внизу окна) (рисунок 14).

Рисунок 14.

Теперь все необходимые сведения, которые мы получили от Клиента и занесли в базу данных «Сведения о заказе», передаются в уже существующий подпроцесс 1.1.3 Расчёт стоимости предоплаты.

Данный уровень является самым нижним, так как нет смысла ещё более детализировать уже имеющиеся информацию и процессы. Детализация типа «Вводить информацию в поле только русскими печатными буквами с помощью клавиатуры» не имеет смысла. Аналогичным образом мы можем детализировать и другие процессы нашей модели.

2.3. Описание общих сведений о компонентах диаграмм.

После построения диаграмм процессов для модели на всех уровнях, приступаем к описанию общих сведений о компонентах диаграмм (комментарии). Это делается для получения более подробной информации о компоненте.

В
зависимости от выбранного компонента диаграммы, в отображающемся окне (рис.3,4,8,9) необходимо нажать на кнопку PROCESS, STORE, EXTERNAL ENTITY, FLOW. Из выпавшего меню выбираем COMMENT. После этого появится диалоговое окно (рис.15), в которое мы вводим подробную информацию о компоненте.
Рисунок 15.
2.4. Создание структуры данных.

Для создания структуры данных необходимо в меню PROJECT выбрать подменю DATA STRUCTURES. В появившемся окне (рис.16), в поле вводим наименование документа, выступающего в качестве потока данных, затем нажимаем кнопку ADD. В нашем примере на самом верхнем уровне такими документами являются: Заявка, Сообщение о заявке, Квитанция на предоплату, Сведения о внесённой предоплате, Наряд, Акт о приёмке выполненных работ, Прейскурант, Сообщение о выполнении заказа, Квитанция на полный расчёт, Гарантийный талон, Отчёт о выполненной работе. Остановимся поподробнее на документе «Квитанция на полный расчёт»




Рисунок 16.


В реальной мастерской эта квитанция будет иметь следующий вид (рис.17):

Квитанция № 29306
Название мастерской «Workshop»

Дата 2.02.2004

ФИО Клиента Крапицкий Андрей Николаевич

Адрес Клиента г. Усть-Илимск, пр. Мира 5, кв. 159

Телефон Клиента 2-94-62

Марка и название бытовой техники стиральная машина «Малютка»

ФИО Мастера Перловский Александр Викторович

Телефон Мастера 6-56-87


№ п/п

Заменяемые детали

Количество деталей

Цена за 1 шт.

Сумма

1

Мотор

1

300

300

2

Подшипник

2

210

420

3

Корпус

1

850

850

4













5













6













7













8













9













10






















Всего:

1570










Сумма предоплаты:

500










Итого:

1070


Подпись Клиента

Подпись Мастера

Подпись Бухгалтера



Рисунок 17.
Чтобы описать структуру данного документа, необходимо нажать на кнопку DATA STRUCTURE, и выбрать подменю COMPOSITION (либо нажать двойным щелчком мыши на наименовании документа). В появившемся окне (рис.18) необходимо ввести элементы документов.





Рисунок 18.
Наша Квитанция на полный расчёт будет иметь следующие поля: Название мастерской, Номер, Дата, ФИО клиента, Адрес клиента, Телефон клиента, Марка и название бытовой техники, ФИО Мастера, Телефон Мастера. Также здесь содержится таблица: Заменяемые детали, Количество, Цена за 1 шт, Сумма. После этого подсчитывается общая сумма (поле Всего), вычитается сумма предоплаты (поле Сумма предоплаты) и подсчитывается стоимость оплаты (поле Итого).

Затем Бухгалтер, Мастер и Клиент ставят свои подписи (вводим соответствующие поля: Подпись бухгалтера, Подпись мастера, Подпись клиента).

Подобным образом составляется структура каждого документа на всех уровнях детализации модели.
2.5. Вывод на печать диаграмм модели бизнес процессов

Для вывода на печать нашей диаграммы из пункта меню FILE выбираем подменю PRINT. Откроется диалоговое окно, представленное на рисунке 19. В данном окне выбираем те диаграммы из приведенного списка, которые необходимо напечатать. Например, 1.1.2 Ввод сведений о заявке.





Рисунок 19.
Чтобы распечатать эту диаграмму нажимаем кнопку PRINT.

2.6. Сохранение структуры данных в файл



Ч
тобы сохранить структуру данных нашей бизнес-модели в файл нужно из пункта меню FILE выбрать подменю REPORT. Откроется диалоговое окно, представленное на рисунке 20. В данном окне предлагаются различные возможности настройки файла, такие как выбор размеров шрифтов, а так же их вид.
Рисунок 20.
Чтобы выбрать данные, которые будут располагаться в отчете, нажимаем на кнопку REPORT CONTENTS. Появится окно, представленное на рисунке 21.



Рисунок 21.
Д
ля примера выведём структуру данных DATA STRUCTURE. Для этого выберем из левого списка DATA STRUCTURE и заполните колонки галочками (рис.22). Затем нажимаем кнопку ОК. На экране снова отразится форма (рис.20). В пункте меню FILE выбираем подменю SAVE REPORT AS (рис.23). Затем указываем путь для сохранения и имя файла. Например, REPORT 1.txt.
Рисунок 22.

Р
исунок 23.
Е
Data structure

Name Comment Components Flows Stores

Акт о приемке выполненных работ

Гарантийный талон

Заявка

Квитанция на полный расчет

Квитанция на предоплату


Наряд

Отчет о выполненной работе

Перечень работ и комплектующих

Прейскурант

Сведения о внесенной предоплате

Сообщение о выполнении заказа


Сообщение о заявке

сли мы затем просмотрим сохранённый файл, то увидим следующую информацию: (рисунок 24)
Рисунок 24.
Подобным образом можно создать отчёт для любой из структур. Создадим структуру данных Внешних сущностей. Опять набираем из пункта меню FILE подменю REPORT (рис. 20). В левой колонке выбираем External entity (рис.25) и заполняем поля галочками (выберем только поля Имя и Комментарии), нажимаем кнопку ОК. В форме (рис.20) в пункте меню FILE выбираем подменю SAVE REPORT AS (рис.23), указываем путь для сохранения и имя файла. Например, REPORT 2.txt.





Рисунок 25.
Информацию мы увидим следующую: (рисунок 26).
Р
External entity
Name Comment
Администрация
Клиент
Техническая служба

исунок 26.

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

Так же присутствует возможность вывода данного отчета на печать. Для этого необходимо в пункте меню FILE выбрать подменю PRINT REPORT (рис.23) и указать параметры печати (рис.27).
Р
исунок 27.
Учебный текст
© perviydoc.ru
При копировании укажите ссылку.
обратиться к администрации