Вы находитесь на странице: 1из 58

РАЗРАБОТКА ПРИЛОЖЕНИЙ НА БАЗЕ

ИНТЕГРИРОВАННЫХ СРЕД
О ГЛ А В Л Е Н И Е

Стр.
ДИДАКТИЧЕСКИЙ ПЛАН........................................................................................................................5
ЛИТЕРАТУРА...............................................................................................................................................6
ТЕМАТИЧЕСКИЙ ОБЗОР..........................................................................................................................7
1. ОСНОВЫ РАЗРАБОТКИ ОФИСНЫХ ПРИЛОЖЕНИЙ......................................................................7
1.1. Понятие офисного приложения, виды приложений.................................................................7
1.2. Функциональность и масштабность приложений....................................................................8
1.3. Классификация офисных приложений......................................................................................8
1.4. Текстовые процессоры................................................................................................................9
1.5. Системы управления базами данных........................................................................................9
1.6. Электронные таблицы...............................................................................................................10
1.7. Деловая графика и электронные коммуникации....................................................................11
1.8. Особенности разработки офисных приложений....................................................................12
1.9. Внедрение приложений............................................................................................................13
1.10. Использование интегрированного пакета Microsoft Office для создания приложений....13
2. ПРОЦЕСС РАЗРАБОТКИ ОФИСНЫХ ПРИЛОЖЕНИЙ..............................................................14
2.1. Жизненный цикл офисного приложения................................................................................14
2.2. Стадии разработки приложения...............................................................................................16
2.2.1. Техническое задание.........................................................................................................16
2.2.2. Словарь предметной области............................................................................................16
2.2.3. Модель приложения..........................................................................................................17
2.2.4. Интерфейс приложения.....................................................................................................17
2.2.5. Код программы...................................................................................................................17
2.2.6. Документация приложения...............................................................................................17
2.2.7. Результаты эксплуатации..................................................................................................17
2.3. Модель процесса разработки приложения..............................................................................18
2.3.1. Анализ.................................................................................................................................18
2.3.2. Проектирование.................................................................................................................19
2.3.3. Реализация..........................................................................................................................19
2.3.4. Стабилизация.....................................................................................................................19
2.3.5. Внедрение...........................................................................................................................20
2.4. Повышение продуктивности разработки приложений..........................................................20
3. МОДЕЛИРОВАНИЕ ОФИСНЫХ ПРИЛОЖЕНИЙ......................................................................22
3.1. Общие сведения и назначение унифицированного языка моделирования UML................22
3.2.Основные конструкции языка UML.........................................................................................23
3.2.1. Графическая нотация.........................................................................................................23
3.2.2. Сущности и отношения.....................................................................................................24
3.2.3. Канонические диаграммы.................................................................................................26
3.2.4. Общие механизмы языка UML.........................................................................................34
3.3. Процесс моделирования...........................................................................................................36
3.4. Использование моделей............................................................................................................39
3.4.1. Способы использования моделей.....................................................................................39

2
Стр.
3.4.2. Создание диаграммы использования офисного приложения
«Автоматизированный документ».............................................................................................40
3.4.3. Создание диаграмм использования многопользовательского офисного
приложения "Отдел кадров".......................................................................................................42
4. АВТОМАТИЗАЦИЯ ПОЛЬЗОВАТЕЛЬСКИХ ЗАДАЧ..................................................................46
4.1. Понятие макроса........................................................................................................................46
4.1.1. Запись макроса...................................................................................................................47
4.1.2. Способы запуска макросов...............................................................................................48
4.2. Создание и применение пользовательских функций.............................................................48
4.2.1. Применение макросов в Excel..........................................................................................48
4.2.2. Использование макросов в Access...................................................................................50
ЗАДАНИЯ ДЛЯ САМОСТОЯТЕЛЬНОЙ РАБОТЫ...............................................................................53
ГЛОССАРИЙ..............................................................................................................................................57

3
ДИДАКТИЧЕСКИЙ ПЛАН

Понятие офисного приложения, виды приложений, функциональность и масштабность


приложений, классификация офисных приложений. Программы, используемые при создании
офисных приложений. Особенности разработки офисных приложений, внедрение приложений.
Использование пакета MS Office для создания приложений
Жизненный цикл офисного приложения, стадии разработки приложения. Модель процесса
разработки приложения, повышение продуктивности разработки приложений.
Общие сведения и назначение унифицированного языка моделирования UML. Основные
конструкции языка UML. Процесс моделирования, использование моделей.
Понятие макроса, использование макросов. Запись макроса, способа запуска макросов.
Создание и использование пользовательских функций

4
ТЕМАТИЧЕСКИЙ ОБЗОР*

1. ОСНОВЫ РАЗРАБОТКИ ОФИСНЫХ ПРИЛОЖЕНИЙ

1.1. Понятие офисного приложения, виды приложений

В общем случае приложением называется прикладная программа, предназначенная для


решения определенных задач и получения конкретных результатов. Например, программа расчета
заработной платы. Офисные приложения представляют собой приложения для бизнеса (business
applications) или системы автоматизации производства. В прошлом столетии их еще называли
автоматизированными системами управления. Практика показывает, что большую долю всего
реально используемого программного обеспечения составляют офисные приложения.
Все офисные приложения предназначаются для ввода, хранения и обработки данных.
Специфическим фактором являются сами данные. Офисные приложения работают с данными,
которые представляют информацию о реальном мире, причем такую, которая используется в
делопроизводстве и имеет форму документов. Ярким представителем офисных приложений
является общеизвестный текстовый процессор Word.
Типичными примерами офисных приложений и связанных с ними документов являются:
 управление кадрами (личная карточка учета);
 медицинское обслуживание (история болезни);
 складской учет (накладная).

*
Полужирным шрифтом выделены новые понятия, которые необходимо усвоить. Знание этих понятий будет
проверяться при тестировании.
5
Многие приложения не являются офисными, так как они не связаны с документами,
например, программа для станков с числовым программным управлением в автоматизированном
производстве.
Все офисные приложения можно разделить на «горизонтальные» («заказные») и
«вертикальные» («коробочные»). В первом случае подразумевается приложение, которое сделано
по конкретному индивидуальному заказу, а во втором – приложение, которое рассчитано на
массовый спрос и которое можно купить в магазине, где оно продается на машинном носителе,
упакованном в коробку вместе с документацией.
Основное различие между этими классами состоит в том, что у вертикального приложения
имеется конкретный пользователь (или организация), который известен до начала разработки.
Этого пользователя можно спросить, что он предпочитает, как он предполагает работать с
приложением, что он ожидает от его внедрения и т.д. Примерами вертикальных приложений
являются различные программы, создаваемые по индивидуальным заказам. При разработке
горизонтального приложения имеется только «модель» пользователя, построенная в результате
исследования спроса на рынке и анализа использования аналогичных приложений. Реакцию на
приложение конкретного будущего пользователя прямо узнать нельзя. Примером горизонтального
приложения является программа PROMT для компьютерного перевода текста на русский язык или
любая офисная программа пакета Microsoft Office.
Необходимо отметить, что граница между этими классами офисных приложений весьма
размыта. Например, комплекс программ «1С: ПРЕДПРИЯТИЕ» включает в себя и «коробочную»
часть, и в то же время может быть адаптирован к требованиям конкретного заказчика.
1.2. Функциональность и масштабность приложений

Важной характеристикой офисных приложений является их масштаб. Масштаб приложения –


это качественная оценка размера приложения с точки зрения его использования.
Обычно различают следующие градации размеров приложения:
 настольные (desktop);
 групповые (groupware);
 масштаба предприятия (enterprise).
Настольное приложение, как правило, имеет одного пользователя, может выполняться на
одном персональном компьютере и работать автономно без сети.
Групповое приложение имеет нескольких пользователей, которые могут работать с ним
порознь или одновременно, но все принадлежат к одной группе или категории пользователей. Как
правило, групповое приложение использует локальную сеть или иной способ связи компьютеров.
Приложение масштаба предприятия имеет значительное количество пользователей,
принадлежащих различным категориям, выполняет несколько различных связанных между собой
функций и работает в локальной, региональной или глобальной сети.
Существует важный класс приложений – так называемые приложения реального времени. Как
правило, прикладные программы реального времени управляют некоторым технологическим
оборудованием (например, работой электростанции, автоматической линии сборочного конвейера
и т.п.), и скорость их работы должна соответствовать скоростям конкретных физических
процессов. В этом случае любая задержка в работе программы может существенно повлиять на
конечный результат. Офисные приложения – это прикладные программы не связанные критически

6
с реальным временем. Не столь уж важно, если программа начисления зарплаты справляется с
задачей за 10 секунд или за 10 минут – на результате это не отразится.

1.3. Классификация офисных приложений

Та конкретная область человеческой деятельности, для автоматизации которой используется


офисное приложение, называется предметной областью. В связи с тем, что при разработке
офисных приложений в самых разных предметных областях используются одни и те же
технологические приемы, к настоящему времени определился набор основных средств, наиболее
часто используемых в офисных приложениях. Эти средств воплотились в форме программных
пакетов офисных приложений, наиболее известным из которых является Microsoft Office.
Пакетом офисных приложений будем называть набор приложений, наиболее часто
используемых в делопроизводстве. Настраивая эти средства, можно получить конкретное
программное решение той или иной задачи делопроизводства. При этом существуют следующие
варианты.
 Приложения пакета можно использовать непосредственно, без настройки, «как есть», так
как в них уже изначально заложены многие типовые средства и функции, нужные в
делопроизводстве. Большинство пользователей пакета Microsoft Office идет по этому пути, на
котором необходимо только правильно применять и комбинировать стандартные средства.
 Приложения пакета можно настроить (без программирования) таким образом, чтобы
конкретные задачи решались теми же стандартными средствами, но более эффективно, с
меньшими затратами ручного труда. К такого рода настройкам относятся создание шаблонов,
автоматическая запись макросов, форматирование и создание формул на рабочих листах,
непосредственная работа с таблицами баз данных и т.п.
 Приложения пакета можно использовать для создания приложений. Действительно
приложения Microsoft Office являются мощными средствами разработки офисных приложений,
оставаясь в то же время самими офисными приложениями. Прикладные программы этого пакета
представляют собой офисные средства разработки, то есть приложения, которые одновременно
являются как офисными приложениями, так и средствами их разработки.
В офисные средства разработки входят текстовые процессоры, системы управления базами
данных, электронные таблицы, средства деловой графики и электронной коммуникации.

1.4. Текстовые процессоры

Программы обработки текстов в настоящее время достигли в своем развитии впечатляющих


успехов. Так называемые текстовые редакторы имеют, как минимум, следующие возможности.
 Создание нового текстового файла.
 Просмотр и редактирование существующего файла.
 Ввод текста в режимах вставки и замены.
 Поиск, выделение, копирование, удаление, замена, перемещение части строки или
нескольких строк.
 Поиск, выделение, копирование, перенос части файла в другой файл.
 Разбивка на страницы.
7
Примером текстового редактора является программа Блокнот для Windows.
Текстовый процессор – это текстовый редактор, дополненный разнообразными средствами
оформления текста, такими, как:
 использование библиотек шрифтов;
 использование стилей – именованных наборов параметров форматирования текста;
 возможность создания и использования шаблонов документов;
 вставка графических изображений и данных из других программ;
 орфографический и грамматический контроль, словарь синонимов;
 автоматическое формирование оглавлений и указателей;
 создание сносок, колонтитулов, примечаний.
Редактор Word, являющийся одним из лучших современных текстовых процессоров,
представляет собой эффективное офисное средство разработки приложений, связанных с
обработкой текстов. Текстовый процессор Word имеет целый ряд средств (поля, рамки, слияние,
элементы управления, смат-теги), которые позволяют разрабатывать высокоавтоматизированные
приложения практически без программирования.

1.5. Системы управления базами данных

Системы управления базами данных (СУБД) являются одним из самых распространенных


видов программного обеспечения. В основе СУБД лежит концепция модели данных, то есть
некоторой абстракции представления данных. В большинстве случаев предполагается, что данные
представлены в виде наборов, состоящих из записей. Структура всех записей в наборе одинакова, а
количество записей в наборе является переменным. Элементы данных, из которых состоит каждая
запись, называются полями.
Таким образом, СУБД является подходящим средством во всех случаях, когда исходную
информацию можно представить в виде таблицы постоянной структуры, но неопределенной
длины. Все СУБД поддерживают в той или иной форме четыре основных операции:
 добавить в базу данных одну или несколько записей;
 удалить из базы данных одну или несколько записей;
 найти в базе данных одну или несколько записей, удовлетворяющих заданному условию;
 обновить в базе данных значения некоторых полей в одной или нескольких записях.
Программы для СУБД обычно называются запросами. Результатом выполнения запроса
является либо некоторое множество записей, если запрос основан на операции «найти», либо
изменение информации в базе, если запрос основан на операциях «добавить», «удалить»,
«обновить».
Программа Access является СУБД реляционного типа, имеющей развитый графический
интерфейс для работы с данными в качестве офисного приложения. Например, для формулировки
запроса можно использовать три альтернативных механизма: бланк запроса по образцу,
стандартный язык запросов SQL, мастер запросов, формирующий запрос с помощью диалоговых
окон.
Access как офисное средство разработки используется для разработки конкретных целевых
офисных приложений, в которых пользователи манипулируют данными не напрямую, а с
помощью специально разработанных форм, запросов и отчетов.
8
1.6. Электронные таблицы

Следующим офисным средством разработки являются электронные таблицы и, в частности,


табличный процессор Excel. Для обозначения объекта, представляющего электронную таблицу, в
Excel принят термин "рабочий лист". Рабочий лист - это множество элементарных ячеек, каждая из
которых принадлежит некоторому столбцу и некоторой строке. Строки и столбцы
идентифицируются - столбцы именуются, а строки нумеруются. Имя столбца и номер строки
однозначно идентифицируют ячейку, которая им одновременно принадлежит. Этот идентификатор
представляет собой адрес ячейки или ссылку на ячейку. Кроме того, ячейке можно дать
индивидуальное имя.
Ячейки рабочего листа предназначены для того, чтобы хранить различные значения. Таким
образом, ячейка играет такую же роль, как переменная в программировании: она имеет
обозначение (адрес) и может иметь и менять значение. Всякое вычисление состоит в том, что по
значениям одних переменных вычисляются значения других переменных. Обычно способ
вычисления описывается с помощью формулы, содержащей математические операции и функции.
Но сама формула - это тоже значение, которое можно хранить в ячейке. В этом и состоит основная
идея электронных таблиц: одни ячейки рабочего листа используются как независимые переменные
(влияющие ячейки), которым должны быть приданы значения извне, а другие ячейки
используются как зависимые переменные (зависимые ячейки), которые содержат формулы,
ссылающиеся на независимые переменные. Пользователь вводит исходные данные во влияющие
ячейки, автоматически производятся вычисления по формулам и в зависимых ячейках возникает
готовый результат.
Основная идея электронных таблиц имеет следующие очевидные следствия.
 Автоматическое вычисление может быть сколь угодно длинным (состоять из множества
последовательных шагов).
 Автоматическое вычисление может быть сколь угодно широким (состоять из множества
параллельных шагов).
 Автоматическое вычисление может носить циклический характер (состоять из множества
повторяющихся шагов).
 Автоматическое вычисление может быть сколь угодно многовариантным (состоять из
множества альтернативных шагов).
 Автоматическое вычисление может быть сколь угодно сложным (формула может содержать
сколь угодно сложные функции).
Табличный процессор Excel обладает мощными средствами реализации сложных вычислений,
такими как:
 формулы массива, позволяющие одной формулой задавать вычисления над целыми
массивами данных и получать в результате тоже массивы;
 трехмерные формулы, позволяющие манипулировать не только с двумерными диапазонами
ячеек на рабочем листе, но и со стопками диапазонов, то есть с трехмерными объектами;
 надстройки, такие как "Поиск решения" (решение широкого класса экстремальных задач)
или "Пакет анализа" (решение статистических задач);

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

1.7. Деловая графика и электронные коммуникации

Деловая графика - это графические образы, используемые в делопроизводстве, в деловых


документах. Наиболее характерными являются три вида деловой графики.
 Диаграммы, построенные по числовым данным. Диаграммы используются для компактного
и наглядного представления больших массивов данных.
 Схемы, отражающие структуру и связи в системе взаимодействующих объектов. Например,
организационная диаграмма, то есть структурная схема организации.
 Презентации, представляющие собой набор графических материалов, сопровождающих и
иллюстрирующих устное выступление.
В офисных приложениях деловая графика используется в том объеме, в котором она
поддержана офисными средствами разработки. Пакет Microsoft Office является мощным средством
разработки деловой графики, так как в его состав входят несколько программно-управляемых
приложений. К ним относятся PowerPoint - самое удобное приложение для подготовки и
проведения презентаций, Visio - приложение для подготовки схем и диаграмм. Кроме того, все
основные приложения Microsoft Office эффективно поддерживают работу с деловой графикой.
В современных условиях в число необходимых офисных приложений вошли средства
обеспечения электронных коммуникаций, причем их значение продолжает неуклонно расти.
Появление новых явлений, таких как электронные деньги, виртуальные магазины, корпоративные
сети оказывает серьезное влияние на экономику и делопроизводство. В результате развития
электронных коммуникаций меняется сама предметная область офисных приложений. Так, в
современное семейство офисных приложений Microsoft Office встроены возможности
использования технологий Интернета. Например, Word, Excel, PowerPoint и Outlook поддерживают
в своих VBA-проектах обращение к удаленным специальным образом организованным
приложениям.

1.8. Особенности разработки офисных приложений

Офисное приложение является вертикальным, то есть у него существует заказчик (конкретный


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

10
формальный или неформальный документ, который обычно называют техническим заданием (ТЗ).
Различные трактовки ТЗ со стороны заказчика и разработчика могут не совпадать, поэтому ТЗ на
офисное приложение может претерпевать существенные корректировки и изменения в процессе
разработки.
Для сокращения времени на "выяснения отношений" между заказчиком и разработчиком
последний после получения ТЗ как можно быстрее создает некоторую черновую версию
приложения, называемую прототипом приложения. Например, это может быть только интерфейс
будущего приложения и несколько ключевых функций. Заказчик знакомится с прототипом и дает
свои замечания, которые вносятся в ТЗ, после чего начинается работа над основным вариантом
приложения. Обычно достаточно одной версии прототипа, чтобы выявить все необходимые
изменения в постановке задачи.
Офисные средства разработки позволяют очень быстро построить прототип. Приложения
Microsoft Office имеют в своем составе множество "мастеров", позволяющих быстро в
автоматизированном режиме создать сложный отчет, форму, запрос и т.д. Кроме того, при
построении прототипа с помощью офисного средства разработки некоторые функции целевого
приложения можно не программировать, а оставить их для ручного выполнения пользователем с
помощью интерфейса базового приложения.
Важной характеристикой любых приложений является интерфейс пользователя, то есть
способ взаимодействия пользователя с приложением. Для офисных приложений интерфейс
пользователя приобрел исключительное значение по двум причинам. Во-первых, с ростом
возможностей персональных компьютеров все более широкое распространение получает
графический интерфейс пользователя. Он удобен, приятен, обеспечивает высокую продуктивность
работы и обладает массой других достоинств, но сложен в программировании. Разработчики
вынуждены считаться с желаниями пользователей и тратить немалые усилия на программирование
графического интерфейса. Во-вторых, в настоящее время пользователями офисных приложений
являются непосредственно предметные специалисты (менеджеры, бухгалтеры и т.д.), не
являющиеся профессиональными специалистами по работе на персональных компьютерах. В этом
случае на первый план выходят такие характеристики интерфейса, как ясность, "прозрачность",
простота использования, защищенность от ошибок и т.д., что требует немалых усилий со стороны
разработчиков.

1.9. Внедрение приложений

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

Особенности процесса внедрения офисного приложения

Название
Основное содержание Офисные особенности
мероприятия
Доставка приложения Передача пользователям Большое или переменное число поль-
11
электронных и бумажных зователей
материалов приложения
Подготовка пользователей к Нежелательность или невозможность
работе с приложением обучения с отрывом от производства;
Обучение
отсутствие у пользователей специальной
пользователей
подготовки в области информационных
технологий
Установка компонентов Недостаток или отсутствие квали-
приложения на серверах и фицированных системных инженеров в
Развертывание
рабочих станциях организации заказчика; возможное наличие
приложения
других приложений, которые должны
взаимодействовать с устанавливаемым
Запись в базу данных Необходимость загрузки данных за
Загрузка данных необходимых данных предшествующие периоды; необходимость
загрузки данных других приложений
Внесение изменений в Необходимость, как правило, коррек-
Сопровождение
развернутое приложение в тировки приложения по предложениям
приложения
процессе эксплуатации заказчика

1.10. Использование интегрированного пакета Microsoft Office


для создания приложений

Стоимость приложения определяется суммой всех затрат, прямых и косвенных, которые несет
заказчик в процессе разработки, внедрения и эксплуатации. Как показывает практика,
особенностью офисных приложений является то, что доля расходов на разработку существенно
меньше, а доля расходов на внедрение и сопровождение существенно больше, чем для других
классов приложений. Таким образом, для офисных приложений существенным фактором является
снижение расходов на внедрение и сопровождение. Использование Microsoft Office для разработки
офисных приложений имеет неоспоримые преимущества по сравнению с обычными средствами
разработки.
Во-первых, использование Microsoft Office позволяет быстро осуществить разработку
прототипа приложения, причем таким образом, что в дальнейшем прототип приложения может
быть преобразован в само приложение. Прототип позволяет на самых ранних стадиях разработки
уточнить и конкретизировать требования пользователя и тем самым избежать трудоемких
переделок в дальнейшем. В результате общие затраты на разработку значительно уменьшаются.
Во-вторых, вместе с Microsoft Office и языком программирования VBA разработчик получает
огромное количество готовых программных компонентов, которые наилучшим образом
приспособлены для решения именно офисных задач. Благодаря использованию технологий OLE и
Automation разработчик может легко встраивать в свои приложения мощнейшие средства базовых
приложений. Поэтому при использовании Microsoft Office затраты на разработку уменьшаются за
счет использования готовых компонентов.
В-третьих, Microsoft Office существенно упрощает модификацию офисных приложений и
снижает расходы на их сопровождение. Это обусловливается следующими обстоятельствами.
 В Microsoft Office перенос офисного приложения со старой версии базового приложения на
новую происходит без проблем.
 Изменение представления данных осуществляется средствами интерфейса базового
приложения, не прибегая к программированию.

12
 При объединении нескольких офисных приложений в одну систему не возникает проблем,
связанных с форматами данных у разных приложений.
В-четвертых, при использовании Microsoft Office достигается ощутимая экономия на всех
этапах процесса внедрения офисного приложения, а именно:
 доставка осуществляется просто, так как приложения являются набором документов
базового приложения и можно использовать любые носители, электронную почту или выгрузку
файлов через Интернет;
 поскольку офисные приложения наследуют принципы организации интерфейса от своих
базовых приложений, пользователи оказываются в привычной среде и им нет нужды приобретать
базовые навыки;
 развертывание офисного приложения сводится к простому копированию файлов, поскольку
базовые приложения уже развернуты, так как Microsoft Office используется повсеместно;
 при загрузке данных не возникает проблем при работе с данными старых форматов.
Таким образом, можно с уверенностью утверждать, что использование пакета Microsoft Office
для разработки офисных приложений позволяет сэкономить значительные материальные средства.

2. ПРОЦЕСС РАЗРАБОТКИ ОФИСНЫХ ПРИЛОЖЕНИЙ

2.1. Жизненный цикл офисного приложения

Офисное приложение за время жизни претерпевает многочисленные


Возникла
изменения своей формы,
зависящие от состояния процесса разработки и потребность эксплуатации приложения. Обычно
в программе
последовательность этих изменений обозначается термином "жизненный цикл" (рис. 2.1). Это
название связано еще и с тем, что программа претерпевает неоднократные метаморфозы
Реализация невозможна
циклически. С понятием жизненного цикла приложения тесно связано понятие процесса
Постановка
задачи
разработки, то есть определенной
Словарь последовательности сменяющих друг друга видов деятельности.
Техническое
Спецификой офисных предметной приложений является то, что после завершения
задание разработки приложения
области
начинается эксплуатация,
Заказчик хочет не это которая оказывается теснейшим образом связана
Спецификации с разработкой. Можно
не удовлетворены
Проектирование
сказать, что жизненный цикл и процесс разработки офисного приложения представляют собой две
стороны одного понятия.Прототип Модель
интерфейса
приложения
Не удовлетворены ограничения
Программа не работает
Кодирование

Программная Код программы


документация

Найдены ошибки Тестирование и


отладка

Комплект
поставки

Пользователь не понял
Эксплуатация

Результаты
эксплуатации

Анализ
результатов

Программа
больше не 13
нужна
Рис. 2.1. Диаграмма жизненного цикла офисного приложения

Для потребителей определенный интерес представляют модели жизненного цикла и модели


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

2.2. Стадии разработки приложения

Согласно рассмотренной диаграмме жизненного цикла артефактами офисных приложений


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

2.2.1. Техническое задание

14
Техническое задание - это описание того, что должна делать система для пользователя. ТЗ
является сугубо техническим (а не финансовым или организационным) документом,
описывающим решаемую задачу. ТЗ правильно акцентирует взаимоотношения между заказчиком и
разработчиком. Для офисных приложений ТЗ как документ является именно заданием.
Техническое задание может принимать различные формы:
 обычный текст на естественном языке;
 диаграммы использования;
 ссылка на уже работающее унаследованное приложение, которое нужно изменить или
расширить.
Наилучшим является ТЗ, сформулированное как совокупность простых утверждений
относительно того, что делает система для пользователей. Не имея технического задания, хотя бы
самого поверхностного, нельзя приступать к разработке приложения.

2.2.2. Словарь предметной области

Словарь предметной области - это понятие объектно-ориентированного анализа и


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

Модель приложения - это промежуточный артефакт между ТЗ и программным кодом. Модель


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

2.2.4. Интерфейс приложения

Прототип интерфейса - это модель графического интерфейса пользователя. Графический


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

2.2.5. Код программы

Код программы - это все, что подлежит интерпретации компьютером во время выполнения
приложения. Таким образом, кодом является не только текст программ на языке VBA, но и макеты
форм и отчетов, запросы к базе данных на языке SQL, значения свойств элементов управления,
страницы доступа к данным и даже поля в документах Word.
15
2.2.6. Документация приложения

Программная документация необходима, недокументированные программы не могут долго


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

2.2.7. Результаты эксплуатации

Немаловажное значение имеет последний из необходимых артефактов жизненного цикла


офисного приложения – результаты эксплуатации. Необходимо отметить две важнейшие
составляющие этого артефакта:
 офисное приложение должно вести протоколирование своей работы и накапливать
статистические данные по своему использованию;
 разработчики (или специальная группа сопровождения) должны вести базу данных
дефектов, выявленных в приложении в процессе его эксплуатации.
На рис. 2.1 имеется довольно много стрелок, ведущих на диаграмме вверх, к началу
жизненного цикла. Переход по каждой из таких стрелок означает, что необходимо вернуться назад
и что-то изменить, переделать уже сделанное, то есть исправить допущенную ошибку. Ошибки
при разработке офисных приложений, как и в любой другой сфере деятельности, неизбежны.
Важно, на какой стадии жизненного цикла допущена ошибка, и на какой стадии она обнаружена.
Ошибки, допущенные на ранних этапах жизненного цикла, устраняются на поздних этапах очень
дорогой ценой. Поэтому дополнительные затраты на тщательное проектирование, моделирование
и создание прототипов при разработке офисных приложений в конечном счете ведут не к
увеличению, а к снижению совокупной стоимости приложения.

2.3. Модель процесса разработки приложения

Модель процесса разработки приложений основывается на понятиях «фаза» и «веха». Веха –


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

16
перекрываться во времени. В модели процесса разработки приложения можно выделить пять
основных фаз:
 анализ (создание эскизного проекта);
 проектирование (создание проекта приложения);
 реализация (кодирование);
 стабилизация (тестирование);
 внедрение (начало эксплуатации).

2.3.1. Анализ

Фаза анализа является начальной. Ее основная веха – Концепция или Эскизный проект.
Основная цель этой фазы – достичь полного и согласованного понимания заказчиком и
разработчиком целей, задач и области применения разрабатываемого приложения. Эскизный
проект обычно включает в себя следующую информацию.
1. Введение. Основание для разработки и статус проекта.
2. Постановка задачи. Общее описание предметной области проекта; формулировка
проблемы, на решение которой направлен проект; краткий обзор альтернативных решений, если
они есть; основные отличительные особенности проекта.
3. Цель проекта. Явное, лаконичное и допускающее проверку утверждение о целях проекта.
Обычно проект имеет одну главную цель и несколько вспомогательных или промежуточных
подцелей.
4. Категории пользователей. Классификация пользователей результатов проекта; пере-
числение их ожиданий по отношению к результатам проекта.
5. Используемые подходы. Перечисление и краткое описание методов, средств, приемов и
мероприятий, которые предполагается использовать для достижения целей проекта.
6. Критерии успеха. Количественные критерии, позволяющие оценить степень успешности
проекта.
7. Рабочие материалы. Перечисление и краткое описание отчуждаемых рабочих материалов,
которые составляют результат проекта.
Для эскизного проектирования используются различные средства и методы. Например, для
этой цели успешно применяется унифицированный язык моделирования UML и, в частности,
такое средство, как диаграммы использования.

2.3.2. Проектирование

Фаза проектирования является решающей фазой и определяет общий успех проекта.


Основной целью фазы проектирования является составление проекта будущего приложения. Для
проектирования используются различные методы и средства такие, как:
 блок-схемы, с помощью которых удобно проектировать отдельные алгоритмы;
 диаграммы «сущность – связь» для проектирования схем без данных;

17
 диаграммы «потоков данных» для проектирования взаимосвязи потоков информации в
приложении;
 унифицированный язык моделирования UML.
При проектировании офисных приложений наиболее эффективным является использование
языка UML.

2.3.3. Реализация

Фаза реализации имеет основную веху, которая называется «код готов». Несмотря на то, что на
этой фазе создается основной рабочий результат проекта - программный код приложения, на ее
долю приходится не более 20% всех ресурсов проекта. Веха "код готов" означает, что все
специфицированные функции запрограммированы и работоспособность приложения в целом
продемонстрирована на нескольких примерах.

2.3.4. Стабилизация

Фаза стабилизации заканчивается главной вехой, которая называется "выпуск". Достижение


этой вехи характеризуется наличием полного и подготовленного к тиражированию (копированию,
передаче заказчику) комплекта рабочих материалов проекта, которые были специфицированы на
фазах анализа и проектирования. Основной деятельностью на фазе стабилизации являются
тестирование и отладка, то есть выявление и устранение ошибок. Существуют следующие виды
комплексного тестирования.
 Тестирование устойчивости. Целью этого вида тестирования является выявление
неперехватываемых ошибок времени выполнения, то есть тесты устойчивости нацелены на то,
чтобы вывести из строя ("сломать") приложение. Типичными примерами, применяемыми при
тестировании устойчивости, являются ввод данных, выходящих за пределы области допустимых
значений, нарушение порядка действий, предусмотренных сценарием работы, создание ситуаций,
нарушающих количественные ограничения и т.п.
 Тестирование функциональности. Целью этого вида тестирования является проверка
того, что для допустимых (правильных) входных данных получаются допустимые (правильные,
корректные, соответствующие спецификациям) результаты. Ожидаемые правильные результаты
для каждого теста функциональности должны быть получены заранее, независимо от
тестируемого приложения. Типичным примером является ввод предельных, находящихся на
границе области допустимых значений данных.
 Тестирование применимости. Цель этого вида тестирования является проверка того, что
предусмотренные способы использования приложения являются удовлетворительными для
пользователя при выполнении типичных сценариев работы. При тестировании применимости
проверяются, например, следующие параметры: время реакции приложения на команды
пользователя, защищенность данных, способность к восстановлению после ошибки, понятность
интерфейса и др.

18
2.3.5. Внедрение

Фаза внедрения является заключительной, ее главная веха называется "проект закончен". Эта
веха характеризуется следующими основными признаками: разработанное приложение
используется заказчиком на практике; взаимоотношения с заказчиком урегулированы; результаты
проекта документированы, измерены, архивированы и подготовлены для повторного
использования.

2.4. Повышение продуктивности разработки приложений

Рассмотрим некоторые аспекты жизненного цикла офисных приложений и модели процесса


разработки, которые используются для повышения продуктивности разработки. Одним из самых
действенных приемов повышения продуктивности разработки является разбиение всего процесса
разработки на некоторые части, называемые версиями (выпусками, реализациями). При этом в
первую версию включаются только основные функции, без которых работать нельзя, во вторую,
третью и т.д. - дополнительные функции, которые расширяют и обогащают возможности
предыдущих версий. Например, если в любом из приложений Microsoft Office выполнить команду
"Справка-О программе", то появится диалоговое окно, в котором указан номер версии этого
приложения. По неофициальному правилу номер содержит две цифры, разделяемые точкой.
Первая цифра указывает набор функций, включенных в приложение, а вторая указывает на
изменения, не затрагивающие набора функций.
Разделение проектирования приложения на несколько частей выгодно как заказчику - он
начинает пользоваться приложением (пусть и не в полном объеме) раньше назначенного срока, так
и разработчику - процесс разработки приобретает упорядоченный циклический характер.
Сокращению сроков разработки способствует наложение фаз. Работу над следующей версией
можно начинать до того, как произошел выпуск текущей серии.
Описанные выше методы носят административный характер и применяются при
планировании процесса разработки, управлении этим процессом, определении договорных
отношений с заказчиком и т.д. Повышение продуктивности разработки возможно еще за счет
повышения продуктивности программирования на основе двух факторов:
 сокращение количества внеплановых изменений;
 увеличение объема повторно используемого материала.
При разработке офисных приложений ошибки программирования могут быть
классифицированы следующим образом:
 синтаксические ошибки - нет исполняемой программы;
 ошибки кодирования - имеется исполняемая программа, некоторые протоколы выполнения
которой не удовлетворяют спецификации;
 ошибки проектирования - имеется исполняемая программа, выполнение которой формально
не противоречит спецификации, но результаты выполнения фактически не удовлетворяют
заказчика.
В наибольшей степени снижают продуктивность ошибки проектирования, которые
обусловлены неточностью, неполнотой или неадекватностью спецификаций и моделей. Выявление

19
и фиксация этих ошибок происходит через заказчика, поэтому, чем лучше организовано
взаимодействие с заказчиком, тем более продуктивным оказывается программирование.
Величина положительного воздействия повторного использования уже разработанных
компонентов на продуктивность программирования определяется информационным потоком в
цикле, который проходит через разработчика.
В циклах повышения продуктивности можно выделить следующие типы информации и
направления ее движения:
 пользовательские требования (или внешние спецификации) - от заказчика на фазах анализа
и проектирования;
 пользовательская документация (или детальные спецификации) - к заказчику на фазах
стабилизации и внедрения;
 реализованный компонент со спецификацией - к разработчикам на фазе реализации;
 специфицированный компонент - от разработчика на фазе проектирования.
Очевидно, что если все виды спецификаций будут выражены на одном и том же языке, причем
понятном как человеку, так и компьютеру, то это будет способствовать интенсификации
информационных потоков и увеличению продуктивности программирования.
С практической точки зрения для разных видов спецификаций на первый план выдвигаются
разные требования:
 при создании спецификации реализованного компонента наиболее важными являются
точность и полнота спецификаций, и наилучшей в этом смысле спецификацией программы
является сам текст программы;
 при описании программы для пользователя важнее всего понятность, и поэтому в
пользовательской документации традиционно используется естественный язык;
 при повторном использовании компонентов самым важным является спецификация
интерфейсов, поэтому в этом случае активно используются различные объектные модели;
 при составлении внешних спецификаций первостепенной является наглядность, потому что
заказчик может надежно проверить только хорошо обозримые спецификации.
В качестве средства спецификации, которое одновременно удовлетворяет этим
противоречивым требованиям, наиболее целесообразно использовать модель программы,
выраженную в графической нотации языка UML.

3. МОДЕЛИРОВАНИЕ ОФИСНЫХ ПРИЛОЖЕНИЙ

3.1. Общие сведения и назначение унифицированного языка моделирования UML

Унифицированный язык моделирования UML (Unified Modeling Language) представляет


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

20
универсальное средство, пригодное для спецификации всех артефактов, возникающих в процессе
разработки, и позволяющее снизить риск расхождений в толковании спецификаций.
2. Визуализация - это представление информации в графической форме, предназначенной для
восприятия человеком. Модели UML допускают представление в форме картинок, причем эти
картинки наглядны, интуитивно понятны
3. Проектирование – это означает, что UML предназначен и для непосредственного
манипулирования артефактами, входящими в состав приложений, в том числе и такими, как
программный код, то есть UML может создавать модели, для которых возможна автоматическая
генерация фрагментов кода соответствующих приложений. При этом возможен и обратный
процесс: автоматическое построение модели по коду готового приложения.
4. Документация – это человекочитаемое описание некоторого артефакта, используемое при
его применении. Модели UML являются артефактами, которые можно хранить и использовать как
в форме электронных документов, так и в виде твердой копии.
Язык моделирования UML предназначен для решения различных задач и соответственно
может быть использован различными способами:
 рисование картинок. Графические средства UML могут использоваться безотносительно ко
всему остальному;
 обмен информацией. Чем больше будет использоваться UML, тем лучше будет понимание
между людьми;
 спецификация систем. UML полностью соответствует потребностям спецификации
офисных приложений;
 повторное использование архитектурных решений. Имея такую возможность, UML
повышает эффективность разработки;
 генерация кода. Существующие возможности UML в этой области пока ограничены;
 численное моделирование. Обладая определенными возможностями, UML в этой области
уступает специализированным системам;
 верификация моделей. Возможности UML по оценке свойств моделей пока очень малы.

3.2.Основные конструкции языка UML

Унифицированный язык моделирования UML - это очень большой язык ( на порядок больше,
чем VBA), в состав которого входит более 150 конструкций. Модель UML представляет собой
граф. Вершины графа называются сущностями, а ребра - отношениями. Существует несколько
различных типов сущностей и отношений. Ребра и вершины графа могут быть нагружены
дополнительной информацией, которая зависит от типа сущности или отношения.
Граф модели (или некоторая его часть) может быть представлен в виде диаграммы. При
изображении диаграмм используется определенная графическая нотация, которая фактически
является синтаксисом языка.

3.2.1. Графическая нотация

21
При разработке UML были предложены и приняты разумные рекомендации по выбору
нотации. В качестве основных графических элементов были выбраны такие, которые можно было
бы легко использовать во всех случаях - начиная от не очень аккуратного рисования от руки на
листке бумаги, печати черно-белых изображений в книгах и заканчивая созданием сложных
диаграмм с помощью компьютера. Таких элементов нотации четыре:
 фигуры;
 линии;
 значки;
 тексты.
Фигуры и значки применяются для обозначения сущностей, линии - для обозначения
отношений, тексты всегда являются дополнительной информацией, относимой к сущностям и
отношениям.
Фигуры в UML используются двумерные (их можно нарисовать на плоскости) и замкнутые
(у них есть внутренняя и внешняя части). Фигуры могут менять свои размеры и форму при
сохранении своих отличительных признаков. Например, среди фигур UML есть прямоугольники и
эллипсы, которые могут быть изображены многими способами (разного размера, по разному
ориентированы и т.п.), но во всех случаях прямоугольник не должен быть спутан с эллипсом.
Внутри фигур могут помещаться другие элементы нотации: тексты, линии, значки и даже другие
фигуры. Единственное требование: должно быть однозначно понятно, что элемент нотации
находится внутри фигуры (его изображение не должно пересекать границу фигуры).
Линии в UML только одномерные, они всегда присоединяются своими концами к фигурам и
значкам и не могут быть нарисованы сами по себе. Толщина и форма линий может быть
произвольна: прямые, ломаные, плавные кривые, а вот стиль линии имеет значение. В UML
используются два стиля линий: сплошные и пунктирные. Линии могут пересекаться, к линиям
могут быть пририсованы различные дополнительные элементы: стрелки, тексты и т.д.
Единственное требование: должно быть ясно, что дополнительный элемент относится именно к
данной линии.
Значки в UML сохраняют за собой основную функцию однозначно воспринимаемого
иероглифа. Они отличаются от фигур тем, что не имеют внутренности, в которую можно что-то
поместить и, как правило, не меняют свою форму и размеры.
Тексты в UML - это последовательности различимых символов некоторого алфавита.
Алфавит не фиксирован - он только должен быть понятен пользователю модели. Гарнитура, размер
и цвет шрифта не имеют значения, а вот начертание имеет значение: в UML различаются прямые,
курсивные и подчеркнутые тексты.
Примером модели, изображенной графическими средствами UML в виде диаграммы, является
жизненный цикл приложения, приведенный на рис. 2.1.

3.2.2. Сущности и отношения

Сущности в UML можно подразделить на четыре группы:


 структурные;
 поведенческие;

22
 группирующие;
 аннотационные.
Структурные сущности предназначены для описания структуры. К ним относятся следующие
сущности.
 Класс в языке UML - описание множества объектов с общими атрибутами и операциями.
 Интерфейс в языке UML - множество операций, которое определяет набор услуг,
предоставляемых классом или компонентом.
 Действующее лицо в языке UML - сущность, находящаяся вне моделируемой системы и
непосредственно взаимодействующая с ней.
 Вариант использования в языке UML - описание последовательности производимых
системой действий, доставляющей значимый для некоторого действующего лица результат.
 Компонент - физически заменяемый артефакт, реализующий некоторый набор
интерфейсов.
 Узел - физический вычислительный ресурс.
Поведенческие сущности предназначены для описания поведения. Основных поведенческих
сущностей всего две.
 Состояние в языке UML - период в жизненном цикле объекта, в котором объект
удовлетворяет некоторому условию, выполняет деятельность или ожидает событий.
 Деятельность в языке UML - состояние, в котором выполняется работа.
Группирующая сущность в UML одна: Пакет - группа элементов модели (в том числе
пакетов).
Аннотационная сущность тоже одна: Примечание - текстовая информация, присоединенная к
любому элементу модели или к модели в целом.
В табл. 3.1 приведены значки и фигуры вышеперечисленных сущностей с именами.
Таблица 3.1

Отображение сущностей языка UML

Название сущности Изображение Описание фигуры


Фигура - прямоугольник, возможно разделенный
Класс Т01
на части горизонтальными линиями
Интерфейс Т02 Значок - маленький кружок
Действующее лицо Т03 Значок - "худой человечек"
Вариант использования Т04 Фигура - овал
Фигура - прямоугольник с двумя меньшими
Компонент Т05 прямоугольниками, наложенными на левую
боковую сторону
Фигура - стилизованное изображение парал-
Узел Т06
лелепипеда
Состояние Т07 Фигура - прямоугольник со скругленными углами
Фигура - прямоугольник со скругленными
Деятельность Т08
боковыми сторонами
Фигура - прямоугольник с "закладкой" - меньшим
Пакет Т09 прямоугольником, присоединенным к левому
верхнему углу
Примечание Т10 Фигура - прямоугольник с загнутым правым

23
верхним углом

В языке UML используются четыре основных типа отношений:


 зависимость;
 ассоциация;
 обобщение;
 реализация.
Зависимость в языке UML - это наиболее общий тип отношений между двумя сущностями.
Отношение зависимости указывает на то, что изменение независимой сущности каким-то образом
влияет на зависимую сущность. Графически отношение зависимости изображается в виде
пунктирной стрелки, направленной от независимой сущности к зависимой. Семантика конкретной
зависимости может уточняться в модели с помощью дополнительной информации.
Ассоциация в языке UML - это наиболее часто используемый тип отношения между
сущностями. Отношение ассоциации имеет место, если одна сущность непосредственно связана с
другой или с другими. Графически ассоциация изображается в виде сплошной линии с
различными дополнениями, которая соединяет связанные сущности.
Обобщение в языке UML - это отношение между двумя сущностями, одна из которых
является частным или специализированным случаем другой. В UML отношение обобщения
подразумевает выполнение принципа подстановочности: если сущность А (общее) суть обобщение
сущности Б (частное), то Б может быть подставлено вместо А в любом контексте. Графически
обобщение изображается в виде сплошной стрелки с треугольником на конце, направленной от
частного к общему.
Отношение реализации указывает, что одна сущность является реализацией другой.
Например, класс является реализацией интерфейса. Графически реализация изображается в виде
пунктирной стрелки с треугольником на конце, направленной от реализующей сущности к
реализуемой.
3.2.3. Канонические диаграммы

Сущности с указанными между ними отношениями аналогичны отдельным законченным


фразам. Но из отдельных фраз очень трудно получить связанный рассказ. Поэтому помимо
сущностей и отношений, в модели должна быть какая-то структура, которая бы помогала ее
составлению и пониманию. Основной накладываемой на модель структурой является диаграмма
UML, которая облегчает создание и использование модели. Диаграмма в языке UHL - это
графическое представление некоторой части графа модели. В UML определен набор
рекомендуемых к использованию (канонических) типов диаграмм:
 диаграмма использования;
 диаграмма классов;
 диаграмма объектов;
 диаграмма состояний;
 диаграмма деятельности;
 диаграмма последовательности;
 диаграмма кооперации;
 диаграмма компонентов;
24
 диаграмма размещения.
Канонические диаграммы не образуют полного ортогонального набора, они пересекаются как
по включенным в них средствам, так и по области применения. Рассмотрим каждую из
канонических диаграмм.
Диаграмма использования в языке UML - это наиболее общее представление
функционального назначения системы. Диаграмма использования должна отвечать на главный
вопрос моделирования: "Что делает система во внешнем мире?" На диаграмме использования
применяются два типа основных сущностей: варианты использования и действующие лица, между
которыми устанавливаются следующие основные типы отношений:
 ассоциация между действующим лицом и вариантом использования;
 обобщение между действующими лицами;
 обобщение между вариантами использования;
 зависимости (различных типов) между вариантами использования.
Кроме того, на диаграмме использования можно применить специальный графический
комментарий - обозначить границу системы.
Действующее лицо - это обозначение множества объектов, внешних по отношению к системе,
но взаимодействующих с ней. Вопрос о выделении (идентификации) действующих лиц при
составлении модели - один из самых сложных. Неудачный выбор действующих лиц может
отрицательно повлиять на всю модель в целом. В типовых случаях различные действующие лица
назначаются для категорий пользователей или внешних программных и аппаратных средств.
Основные элементы нотации, применяемые на диаграмме использования, показаны на рис. 3.1
(Примечание: на диаграммах тексты на английском языке являются элементами модели, а на
русском - не являются и представляют собой комментарии,
Абстрактное
объясняющие используемые элементы
Имя системы
действующее
графической нотации). The System
лицо
Generic User

Browse
Ассоциация
действующего
лица и варианта
использования
"include"
действующих лиц
Обобщение

Обобщение вариантов

Login
использования
Границы
системы

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

User Authentication
Конкретное
действующее лицо

25
Рис. 3.1. Нотация диаграммы использования

Вариант использования - это описание множества возможных последовательностей действий,


приводящих к значимому для действующего лица результату. Каждая конкретная
последовательность действий называется сценарием. Таким образом, вариант использования
является классификатором, экземплярами которого являются сценарии. Нотацией для варианта
использования является только имя, помещенное в овал, то есть функции, выполняемые системой,
на уровне моделирования использования никак не раскрываются. Выбор вариантов использования
оказывает сильное влияние на качество модели, формальных методов для этого не существует и
выручает только опыт и знания.
Диаграмма классов - основной способ описания структуры системы, так как UML объектно-
ориентированный язык, в котором классы являются основным "строительным материалом"
системы.
На диаграммах классов применяется один основной тип сущностей - классы, которые
включают многочисленные частные случаи классов: интерфейсы, типы, сигналы, классы-
ассоциации и другие. Основные элементы нотации, применяемые на диаграмме классов,
представлены на рис. 3.2.

InterfaceA

Раздел имени
CLASS A
класса ОБОБЩЕНИЕ Class B
Раздел атрибутов ATTRIBUTE:
класса
Раздел операций TYPE
OPERATION ()
Ассоциация

класса QUALI
Кратность полюса
Класс, являющийся ассоциации FER
суперклассом «много» * Классификатор

Кратность полюса Композиция


ассоциации
«один» 1 Class C

Рис. 3.2. Нотация диаграммы классов

26
Между классами устанавливаются следующие основные типы отношений:
 ассоциации между классами;
 обобщение между классами;
 зависимости между классами и интерфейсами.
Описание класса может включать множество различных элементов. В UML предусмотрено
группирование этих элементов по трем разделам:
 раздел имени - наряду с обязательным именем может содержать также стереотип, кратность
и список свойств;
 раздел атрибутов - содержит список описаний атрибутов класса;
 раздел операций - содержит список описаний операций класса.
Раздел имени является обязательным, остальные могут быть пустыми. Содержимым раздела
является текст, который имеет определенный синтаксис.
Атрибут - это именованное место (слот), в котором может храниться значение. В общем
случае описание атрибута имеет следующий синтаксис:
видимость ИМЯ кратность : тип начальное_значение (свойства)
Видимость обозначается знаками + (открытый), - (закрытый), # (защищенный). Кратность
определяет данный атрибут как массив. Тип атрибута - это либо примитивный (встроенный) тип,
либо тип, определенный пользователем. Начальное значение соответствует значению, полученного
атрибутом при создании экземпляра данного класса. Как и любой другой элемент модели, атрибут
может быть наделен дополнительными свойствами в форме ограничений и именованных значений.
Операция - это описание способа выполнения каких-то действий с объектом: изменить
значения его атрибутов, вычислить новое значение по информации, хранящейся в объекте, и т.д.
Выполнение действий, определяемых операцией, инициируется вызовом операции. При
выполнении операция может в свою очередь вызывать операции этого и других классов. Описания
операций класса перечисляются в разделе операций и имеют следующий синтаксис:
видимость ИМЯ (параметры) : тип (свойства)
Видимость обозначается аналогично атрибуту. Подчеркивание имени означает, что область
действия операции - класс, а не объект. После имени в скобках может быть указан список
описаний параметров. Для каждого параметра обязательно указывается имя, а также могут быть
указаны направление передачи параметра, его тип и значение аргумента по умолчанию.
На диаграммах классов редко используются зависимости, а отношение обобщения
применяется часто. Общее целесообразно выделять в отдельный класс, при этом общие
составляющие, собранные в суперклассе, автоматически наследуются подклассами. Таким
образом, сокращается общее количество описаний и уменьшается вероятность ошибок.
Обобщения в модели должны образовывать строгий частичный порядок.
Самым важным на диаграмме классов является отношение ассоциации. Ассоциация, которая
обозначается сплошной линией, соединяющей классы, означает, что экземпляры одного класса
связаны с экземплярами другого класса. Так как экземпляров может быть много и каждый может
быть связан с несколькими, очевидно, что ассоциация является дескриптором, который описывает
множество связанных объектов. В UML ассоциация является классификатором, экземпляры
которого называются связями.
Связь между объектами (экземплярами классов) в программе может быть организована
разными способами. Например, в объекте одного класса может храниться указатель на объект

27
другого класса или объект одного класса является контейнером для объектов другого класса. Связь
не обязательно является непосредственно хранимым физическим адресом. Этот адрес может
динамически вычисляться во время выполнения программы на основании другой информации.
Например, если объекты представлены как записи в таблице базы данных, то связь означает, что в
записи одного объекта имеется поле, значением которого является первичный ключ записи другого
объекта (из другой таблицы).
При моделировании на UML техника реализации связи между объектами не имеет значения.
Ассоциация в UML подразумевает только то, что связанные объекты обладают достаточной
информацией для организации взаимодействия. Возможность взаимодействия означает, что объект
одного класса может послать сообщение объекту другого класса, в частности, вызвать операцию,
прочитать или изменить значение открытого атрибута и т.п. Поскольку в объектно-
ориентированной программе такого рода действия и составляют суть выполнения программы,
моделирование структуры взаимосвязей объектов (то есть выявление ассоциаций) является одной
из ключевых задач при ее разработке.
Для ассоциации в UML предусмотрено наибольшее количество различных дополнений: имя
ассоциации, кратность полюса ассоциации, агрегация и композиция, спецификатор интерфейса
и др.
Диаграмма объектов – это частный случай диаграммы классов. Диаграммы объектов имеют
вспомогательный характер – по существу это примеры, показывающие, какие имеются объекты и
связи между ними в некоторый конкретный момент функционирования системы.
На диаграмме объектов применяется один основной тип сущностей – объекты (экземпляры
классов), между которыми указываются конкретные связи (экземпляры ассоциаций). Основные
нотации, применяемые на диаграмме объектов, показаны на рис. 3.3.

Объект
(указан класс объекта)

: ClassA
Объект
(указаны имя и класс объекта)

B : ClassB

Объект
(указано только имя )

Связь
C (экземпляр ассоциации)

Рис. 3.3. Нотация диаграммы объектов

Все, что можно показать на диаграмме объектов, можно показать и на диаграмме


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

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

Начальное состояние
Initial

Сегментированный Сегментированный
переход: Enable переход:
событие перехода сторожевое условие и
действие

[is off by default] / v:= 0 [is off by default] / v:= 1

Простой переход:
событие перехода и
действие

Toggle / v:= 1
Off ON

Toggle / v:= 0

Disable Disable

Дорожка
Рис. 3.4. Нотация диаграммы состояний
Простое состояние – это обозначение состояния программы, в котором она ожидает
SWIM LANE 1 SWIM LANE 2
наступления какого-либо события. Оно имеет имя и может иметь другие составляющие. Кроме
того, используются два специальных состояния:
Ветвление Деятельность
 начальное состояние (закрашенный кружочек);
Развилка
 заключительное состояние (закрашенный кружочек, ACTIVIT вокруг которого изображена
окружность). Y3
Объект в
Специальные состояния, фактически, состояниями не являются, так как конечный автомат в
состоянии
них не может находиться. Начальное и заключительное состояния отмечают просто начало и
завершение работы автомата. Object
[in state]
ПростойACTIVIT ACTIVIT
переход всегда ведет из одного состояния в другое. Синтаксис описания перехода
следующий: Y 1 Y2
Событие [ Сторожевое условие ] / Действие
Кроме потока управления на этой диаграмме можно показать поток данных, используя такую
ACTIVIT
сущность, как объект и соответствующую зависимость. Y 4На диаграмме деятельности можно
применять специальный графический комментарий – дорожки, подчеркивающие, что некоторые
деятельности отличаются
Соединение друг от друга, например, выполняются в разных местах. Основные
элементы нотации, применяемые на диаграмме деятельности, показаны на рис. 3.5.

29
Рис. 3.5. Нотация диаграммы деятельности

Событие перехода – это тот входной стимул, который вместе с текущим состоянием автомата
определяет следующее состояние. В UML предусматривается несколько типов событий: событие
вызова, событие таймера, событие изменения и событие сигнала. Основной тип событий – это
события вызова методов объекта. Объект реагирует на них, выполняя тела методов, и меняя
значения своих атрибутов (состояние). Возможно наличие переходов без событий – так
называемых переходов по завершении.
Сторожевое условие – это логическое выражение, которое должно оказаться истинным для
того, чтобы возбужденный переход сработал. Если сторожевое условие ложно, то переход не
срабатывает и событие теряется.
Диаграмма деятельности – это фактически блок-схема алгоритма, в которой
модернизированы обозначения, а семантика согласована с объектно-ориентированным подходом.
На диаграмме деятельности применяется один основной тип сущностей – деятельность
(состояние с внутренней активностью) и один тип отношений – переход (передача управления).
Кроме того, используются графические обозначения (развилки, слияния и ветвления), которые
представляют собой графический способ изображения некоторых частных случаев
сегментированных переходов.
На диаграмме последовательности имеет значение не только наличие связей между
элементами, но и взаимное расположение элементов на диаграмме. Считается, что невидимая ось
времени по умолчанию направлена сверху вниз (или слева направо) и то сообщение, которое
отправлено позже изображено ниже (правее). На рис. 3.6 показаны основные элементы нотации,
применяемые на диаграмме последовательности.
30
Объект, существующий до
Actor начала взаимодействия
Экземпляр
действующего
лица Object 1

Message 1()
Сообщение
Создание объекта в
процессе взаимодействия

Активация
 Время

Message 2()
Object 2
Линия
жизни

Возврат

Уничтожение объекта в
процессе взаимодействия

Рис. 3.6. Нотация диаграммы последовательности


Диаграмма последовательности – это способ описания системы «на примерах». Фактически –
это запись протокола конкретного сеанса работы системы. В объектно-ориентированном
программировании самым существенным во время выполнения программы является посылка
сообщений взаимодействующим объектам, а точнее – последовательность посылки сообщений,
отсюда и название диаграммы. В диаграмме последовательности применяется один основной тип
сущностей – объекты (экземпляры взаимодействующих классов и действующих лиц) и один тип
отношений – сообщения, которыми обмениваются взаимодействующие объекты.
Предусматривается несколько типов сообщений, которые в графической нотации различаются
видом стрелки.
Пунктирная линия, выходящая из объекта, называется линией жизни. Она не обозначает
отношения, а показывает нужное направление. Фигуры в виде узких полосок представляют собой
графический комментарий, показывающий отрезки времени, в течение которых объект имеет
управление. Создание объекта в процессе взаимодействия отмечается тем, что значок объекта
располагается ниже, то есть объект появляется позже. Уничтожение объекта отмечается большим
косым крестиком и прекращением линии жизни.
Диаграмма кооперации – это такое же, как и в диаграмме последовательности, описание
последовательности обмена сообщениями взаимодействующих объектов, только выраженное
другими графическими средствами. На диаграмме кооперации также применяется один основной
31
тип сущностей – объекты и один тип отношений – сообщения, но акцент делается не на времени, а
на связях между конкретными объектами. На рис. 3.7 показаны основные элементы нотации
диаграммы кооперации.

1.Message 1() 1.1.Message 2()

Object 1 Object 2
Связь
(экземпляр 1.1.1.Return
ассоциации)
Actor

Рис. 3.7. Нотация диаграммы кооперации

Взаимное расположение объектов на диаграмме кооперации не имеет значения - важны только


связи (экземпляры ассоциаций). Для упорядочивания сообщений по времени применяется
иерархическая десятичная нумерация. Большинство инструментов UML умеет автоматически
преобразовывать диаграммы последовательности в диаграммы кооперации и обратно. Сравните
диаграммы, представленные на рис. 3.6 и рис. 3.7 - на них изображена одна и та же диаграмма.
Диаграмма компонентов - это, по сути, список артефактов, из которых состоит
моделируемая система, с указанием некоторых отношений между артефактами. Наиболее
существенным типом артефактов программных систем являются программы. Поэтому на
диаграмме компонентов основной тип сущностей - это компоненты (исполнимые модули и другие
артефакты), а также интерфейсы для указания связи между компонентами и объекты, входящие в
состав компонентов. На рис. 3.8 показаны основные элементы нотации диаграммы компонентов.

Компонент,
реализующий Component2
интерфейс Компонент,
использующий
Component1 интерфейс

Object 2

Object 1 Объекты, Interface


включенные в
компонент

Рис. 3.8. Нотация диаграммы компонентов

На диаграмме компонентов применяются следующие отношения:


 отношение реализации между компонентами и интерфейсами (компонент реализует
интерфейс);
 отношение зависимости между компонентами и интерфейсами (компонент использует
интерфейс);
 отношение зависимости между объектами и компонентами (объект входит в компонент).
Отношение зависимости, соответствующее включению, например, объекта в компонент,
изображается с помощью помещения фигуры одной сущности в фигуру другой.
32
Диаграмма размещения наряду с отображением состава и связей компонентов, показывает,
как физически размещены компоненты на вычислительных ресурсах во время выполнения
программы. На диаграмме размещения, по сравнению с диаграммой компонентов, добавляется
один тип сущностей - узел (может быть как классификатор, описывающий тип узла, так и
конкретный экземпляр), а также отношение ассоциации между узлами, показывающее, что узлы
связаны во время выполнения.
На рис. 3.9 показаны основные элементы нотации диаграммы размещения.

Узел

Соединение узлов
Workstation Server
* LAN 1

GUI Database

Компонент,
размещенный на узле

Рис. 3.9. Нотация диаграммы размещения

3.2.4. Общие механизмы языка UML

В UML имеются общие правила и механизмы, которые относятся не к конкретным элементам


модели, а ко всему языку в целом:
 внутреннее представление модели;
 дополнения;
 подразделения;
 механизмы расширения.
Модель имеет внутреннее представление, что необходимо для работы инструментов.
Разработчики инструментов для моделирования на UML могут использовать любое представление
или предложить свое. Важным общим правилом UML является спецификация того, какую именно
семантическую информацию, связанную с графическим элементом нотации, обязан хранить
инструмент. Например, инструмент может поддерживать режим, в котором часть информации о
классе не отображается на картинке или отображается не полностью. Но при этом полный список
со всеми деталями во внутреннем представлении сохраняется.
У каждого элемента модели есть базовая графическая нотация. Она может быть расширена
путем использования дополнительных текстовых и графических объектов, называемых
дополнениями. Например, базовой нотацией класса является прямоугольник с его именем. Эта
нотация может быть расширена разделами со списком атрибутов и операций, дополнительными
разделами, указанием кратности, стереотипа и т.д.
Язык UML является объектно-ориентированным, поэтому везде единообразно применяются и
изображаются две дихотомии: "класс-объект" и "интерфейс-реализация". Одна и та же сущность в
разных контекстах может рассматриваться и как класс (множество), и как экземпляр класса
(элемент). Дихотомия "класс-объект" означает, что общее описание некоторого множества
33
однотипных объектов (класс) четко различается от описания конкретного объекта (экземпляр
класса). Если это конкретный объект, то его имя подчеркивается, а если класс, то не
подчеркивается. Различие между ними передается единообразно, важно только четко указать, что
именно подразумевается в данном контексте.
Дихотомия "интерфейс-реализация" позволяет указать в модели, чем является сущность:
абстрактным описанием того, чем она должна быть по отношению к другим сущностям, или
конкретным описанием того, чей сущностью физически является. Например, в программировании
заголовок функции является ее интерфейсом, а тело функции является ее реализацией. В UML для
записи имени абстрактного интерфейса используется курсивное начертание, а для конкретной
реализации - прямое.
Механизм расширения - это встроенный в язык способ изменения языка. Механизмы
расширения позволяют определять новые элементы модели на основе существующих. К ним
относятся:
 Помеченные значения. Помеченное значение - это свойство, добавляемое к внутреннему
представлению модели. Это имя и значение свойства, которые можно добавить к любому
стандартному элементу модели.
 Ограничения. Ограничение - это логическое утверждение относительно значений свойств
элементов модели. Логическое утверждение может иметь два значения: истина и ложь, то есть
задаваемое им условие либо выполняется, либо не выполняется.
 Стереотип. Стереотип - это определение нового типа сущности в UML на основе
существующей сущности. При создании стереотипа к существующему элементу модели
добавляют новые помеченные значения (расширяя внутреннее представление), новые ограничения
(расширяя семантику) и дополнения - новые графические элементы (расширяя нотацию).
3.3. Процесс моделирования

На практике не удается описать с единой точки зрения все без исключения аспекты
моделируемой системы. Действительно, в модели необходимо отразить интерфейсы для
взаимодействия с внешним миром, внутреннюю логическую структуру программы, структуру
хранимых данных, алгоритмы функционирования, состав артефактов, включаемых в поставку, и
многое другое. В настоящее время единого средства для решения этой задачи нет. Поэтому при
моделировании сложной системы ее рассматривают с нескольких различных точек зрения, каждый
раз принимая во внимание один аспект моделируемой системы и абстрагируясь от остальных. В
этом и состоит один из основных принципов универсального языка моделирования UML.
В UML основная идея состоит в том, что абстрактный граф модели, состоящий из множества
разнотипных сущностей и отношений, не подлежит конструированию или изучению в целом.
Каждый раз для визуализации, изменения или других манипуляций из этого общего графа
выделяются только сущности и отношения, наиболее важные для определенного аспекта
моделируемой системы, а все остальные игнорируются. Такой вид или такая проекция модели
называется представлением.Логическое Представление
представление
Одним из самых популярных является набор представленийкомпонентов
модели, представленный на
рис. 3.10. Представление
пользователя
Представление Представление
процессов размещения 34
Рис. 3.10. Пять представлений модели

Представление пользователя - это описание поведения системы с точки зрения внешних по


отношению к ней агентов. Структурные аспекты передаются диаграммами использования, а
поведенческие аспекты - диаграммами взаимодействия, состояний и деятельности.
Логическое представление предназначено для описания словаря предметной области, то есть
для описания классов. Структурные аспекты передаются диаграммами классов и объектов, а
поведенческие аспекты - диаграммами взаимодействия, состояний и деятельности.
Представление процессов - это описание взаимодействия процессов во время работы системы.
Оно отражает такие аспекты, как параллелизм, синхронизация, производительность,
масштабируемость, пропускная способность. Структурные аспекты передаются с помощью
концепции активных классов (процессы и потоки), а поведенческие аспекты - диаграммами
взаимодействия, состояний и деятельности.
Представление компонентов - это описание конфигурации системы на уровне артефактов.
Структурные аспекты передаются диаграммами компонентов, а поведенческие аспекты -
диаграммами взаимодействия, состояний и деятельности.
Представление размещения отражает топологию связей аппаратных средств и размещения на
них компонентов. Структурные аспекты передаются диаграммами размещения, а поведенческие
аспекты - диаграммами взаимодействия, состояний и деятельности.
Учитывая неформальный характер понятия представления и практический опыт
использования UML, более предпочтительным является другой вариант набора представлений,
изображенный на рис. 3.11.

Представлени Представлени
е е структуры
использования

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

Рис. 3.11. Упрощенный набор представлений модели

Представление использования. По сути это то же самое представление, что было указано


выше. Представление использования призвано отвечать на вопрос: "что делает система
полезного?" Определяющим признаком для отнесения элементов модели к представлению
35
использования является анализ факта наличия у системы внешних границ. При этом происходит
выделение внешних действующих лиц, взаимодействующих с системой, и внутренних вариантов
использования, описывающих различные сценарии такого взаимодействия. Таким образом,
единственным выразительным средством представления использования оказываются диаграммы
использования.
Представление структуры. Представление структуры призвано отвечать на вопрос: "из чего
состоит система?" Определяющим признаком для отнесения элементов модели к представлению
структуры является явное выделение структурных элементов - составных частей системы - и
описание взаимосвязей между ними. Принципиальным является чисто статический характер
описания, то есть отсутствие понятия времени в любой форме, например, в форме
последовательности событий и действий. Представление структуры описывается главным образом
диаграммами классов, а также диаграммами компонентов и размещения и, в редких случаях,
диаграммами объектов.
Представление поведения. Представление поведения отвечает на вопрос: "как работает
система?" Определяющим признаком для отнесения элементов модели к представлению поведения
является явное использование понятия времени, в частности, в форме описания
последовательности событий или действий, то есть в форме алгоритма. Представление поведения
описывается диаграммами состояний и деятельности, а также диаграммами взаимодействия в
форме диаграмм кооперации и последовательности.
Используя вышеприведенный набор представлений, сам процесс моделирования можно
изобразить в виде диаграммы, представленной на рис. 3.12.

Моделирование
использования

Представление
использования не
согласовано
else

Моделирование Моделирование
структуры поведения

Модель требует Модель нуждается


уточнения в переделке
else

36
Рис. 3.12. Процесс моделирования

Как видно из диаграммы на рис. 3.12 процесс моделирования итеративен и параллелен.


Приведенной модели процесса моделирования офисного приложения соответствует следующий
алгоритм.
1. Необходимо заниматься моделированием использования до тех пор, пока модель
использования не будет согласована, то есть до тех пор, пока заказчик и разработчик не придут к
согласованному пониманию того, что должна делать система.
2. Параллельно с моделированием использования необходимо вести моделирование структуры
и поведения до тех пор, пока модель не станет достаточно детальной, то есть пока не будут
решены все вопросы, подлежащие решению в принятой дисциплине использования модели.
3. Если на втором шаге выяснится, что модель противоречит каким-либо требованиям
заказчика, то необходимо немедленно вернуться к первому шагу.
В общем, в процессе моделирования должны быть одновременно открыты несколько
диаграмм. Сначала рисуется элемент на одной диаграмме, потом другой элемент на другой
диаграмме и т.д. Например, на диаграмме классов определился атрибут, в котором будет храниться
состояние объекта. Немедленно надо создать диаграмму состояний и перечислить те состояния
(значения атрибута), которые может иметь объект. Или, например, на диаграмме
последовательности один объект посылает сообщение другому. Необходимо вернуться к
диаграмме классов и убедиться, что соответствующая операция определена.
3.4. Использование моделей

3.4.1. Способы использования моделей

Способы использования моделей UML зависят от множества факторов, к которым относятся:


 тип приложения. Модели встроенного приложения реального времени, например,
управляющей программы в мобильном телефоне, и офисного приложения совершенно не похожи.
В отличие от первого однопользовательское офисное приложение не нуждается в моделировании
компонентов и размещения;
 масштаб приложения. Очевидно, что модель офисного приложения, которое разрабатывает
один профессиональный пользователь за неделю, и модель горизонтального приложения, которое
разрабатывается коллективом из сотен программистов за несколько месяцев не соизмеримы;
 инструментальная поддержка. Существенно различаются варианты, когда инструмента нет,
и диаграммы рисуются на бумаге и когда есть мощный инструмент с автоматической генерацией
кода, нацеленный на выбранный язык программирования.
Для разработки офисных приложений хорошо подготовленными пользователями с помощью
средств Microsoft Office можно выделить четыре способа использования моделей:
 анализ бизнес-процессов;
 детальное проектирование и автоматизированная реализация;
 управление тестированием;
 документирование приложения.

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

38
3.4.2. Создание диаграммы использования офисного приложения
«Автоматизированный документ»

В деловой практике одним из этапов ведения бизнеса является процедура заключения


договора с партнером, юридически закрепляющая права и обязанности сторон при совместном
выполнении ими некоторого общего дела. В этой процедуре подписание договора является
заключительным актом, которому обычно предшествуют переговоры, принятие согласованных
решений и тому подобные действия, позволяющие сформулировать основные положения будущего
договора. Часто организации, предоставляющие многочисленным клиентам однотипные услуги,
например, в сфере образования, или выполняющие совместно с другими лицами однотипную
работу, например, издание книг, имеют заранее разработанные типовые договоры, в которые
достаточно вписать в определенные места недостающие данные о партнере. После чего остается
только распечатать и подписать договор.
Если все необходимые данные о возможных партнерах хранятся на магнитном диске
компьютера, то процедура составления договора может быть предельно упрощена. Достаточно
иметь приложение, которое вставляет в электронную заготовку договора данные о партнере,
выбираемом из списка, создаваемого на основе хранимой информации. Если данных о каком-либо
предполагаемом партнере на магнитном носителе нет, то в приложении необходимо предусмотреть
режим ввода требуемых данных с целью последующего их использования. Таким образом,
описанное приложение позволит постоянно наращивать данные в базе данных, а главное, оно
будет работать с достоверной информацией, исключая возможность человеческих ошибок.
Предположим нам необходимо разработать подобное офисное приложение для
гипотетического высшего учебного заведения (Институт Гуманитарных Наук) на оказание
образовательных услуг на платной основе, заключающего обычно типовые договоры со
студентами. Разрабатываемое нами приложение (автоматизированная система ведения договоров)
будет состоять из двух частей. В качестве базы данных будет использоваться рабочая книга Excel, а
типовой договор будет представлен шаблоном Word, в который будет встроено собственное меню с
командами, реализующими следующие функции.
 Добавление и удаление из базы данных информации о студентах, обучающихся в институте.
 Формирование и хранение информации об оплате обучения и успеваемости студентов.
 Автоматизированное формирование договора со студентами.
Итак, нам предстоит разработать шаблон Word со встроенным в него меню, которое будет
заменять основное меню приложения Word при создании на основе этого шаблона документа. Сам
шаблон будет представлять собой текст типового договора со студентами со встроенными в него
полями, заполнение которых будет осуществляться пользователем через вызов команд встроенного
в шаблон меню. Необходимая информация будет извлекаться из листов рабочей книги Excel,
которые в совокупности и будут представлять базу данных приложения. При этом работа по
извлечению информации с листов рабочей книги Excel так же, как и запись на листы новой
информации, будут совершенно скрыты от пользователя.
Формально договор составляется с участием двух договаривающихся сторон - студента и
института. Однако в связи с тем что договор типовой и на практике оформляется "без вопросов",
нет нужды разграничивать права доступа и сценарии использования. Поэтому у нашего
приложения будет одно действующее лицо - "пользователь".

39
Определим круг задач (вариантов использования в терминах UML), которые пользователь
сможет решать с помощью нашего приложения. Для этого необходимо иметь небольшой опыт в
оформлении договоров и руководствоваться здравым смыслом. Перечислим задачи, которые
необходимо решать пользователю.
 Заполнение договора данными о студенте (фамилия, имя, отчество, адрес, паспортные
данные и т.д.) и об образовательных услугах (специальность, срок обучения, стоимость и т.д.),
которые будут извлекаться из базы данных.
 Сохранение сформированного договора в обычном файле Word на основе стандартного
шаблона Normal.dot (без функциональности, встроенной в разработанный нами шаблон).
 Формирование записей в базе данных о новой специальности.
 Занесение информации в базу данных по новым студентам.
 Предоставление пользователю возможности обратиться к командам панелей инструментов
"Стандартная" и "Форматирование" в случае необходимости, например, если потребуется
подкорректировать типовой договор.
Построим диаграмму использования нашего приложения. Согласно вышеприведенному, у нас
одно действующее лицо - пользователь и пять вариантов использования, которые имеют с
пользователем тип отношения - ассоциация между действующим лицом и вариантом
использования.
После того как мы осуществили постановку и формализацию задачи, нам необходимо перейти
к ее поэтапной реализации: созданию базы данных и шаблона с требуемой функциональностью.
На рис. 3.13 приведена диаграмма использования автоматизированной системы ведения
договоров.

Ведение договора

Заполнение
договора
Сохранени
е договора

Добавление
специальности
Пользователь

Добавление
Форматировани
студента
е договора

Рис. 3.13. Диаграмма использования системы ведения договоров

40
3.4.3. Создание диаграмм использования многопользовательского
офисного приложения "Отдел кадров"

Рассмотрим постановку задачи и начальный этап разработки более сложной системы -


многопользовательского офисного приложения. В качестве примера возьмем типичную задачу
автоматизации работы отдела кадров в организации. С помощью MS Access создадим офисное
приложение - информационную систему (ИС) для автоматизации работы отдела кадров
гипотетической корпорации. Этот пример будет последовательно рассматриваться в дальнейшем.
На первом этапе проекта, согласно вышеизложенному материалу, необходимо составить набор
требований, предъявляемый к конечному продукту. Как отмечалось в предыдущих главах, чтобы
сформулировать реальные требования к системе, разработчику требуется получить от заказчика
как можно больше информации, как правило, в виде технического задания. Предположим, что мы,
заключили договор с руководством корпорации на разработку многопользовательского
приложения, в котором указаны его назначение, сроки разработки, стоимость, формы поставки и
пр. Кроме того, мы получили от заказчика и согласовали с ним следующие основные требования
(техническое задание) на разработку проекта.
ИС "Отдел кадров" предназначается для ввода, хранения и обработки информации о
сотрудниках, работающих в организации, о штатном расписании и движении кадров.
Информация о сотрудниках должна включать их резюме и анкетные данные, которые при
необходимости можно изменить.
ИС "Отдел кадров" должна обеспечивать выполнение следующих действий (кадровых
операций), связанных с движением кадров:
- прием сотрудника на работу;
Отдел кадров
- перевод сотрудника с одной должности на другую и из одного отдела в другой;
- увольнение сотрудника.
ИС "Отдел кадров" должна поддерживать несколько категорий приема на работу:
Получение
Пользователь отчетов
- постоянно;
- временно;
- по совместительству; Просмотр
- по договору. таблиц
Одно и то же лицо может быть принято на работу неограниченное число раз с любой
Архивирование
категорией, кроме категории "постоянно". Исходя из каждого и
факта приема необходимо вести
обновление данных
свою историю назначения сотрудника. Увольнение по каждому назначению должно выполняться
отдельно.
Кадровые
Теперь, на основе этих требованийоперациии ограничений, необходимо выделить классы
пользователей системы, определить их требования и построить описание системы с точки зрения
пользователя. Как отмечалось выше, в системе обозначений языка UML таким описанием является
Зав.кадрами
Протоколирование
представление использования. Представление использования может состоять из нескольких диаг-
операций
рамм использования, которые описывают отдельные части системы и систему в целом. Сначала
составим диаграмму использования для системы в целом. Эта диаграмма представлена на рис. 3.14
и включает варианты использования и действующие лица информационной системы Отдел кадров.
Зав.штатным
Штатные
расписанием
операции
Правка
таблиц

Администратор 41
Рис. 3.14. Диаграмма использования информационной системы «Отдел кадров»

ИС "Отдел кадров" должна позволять проводить следующие операции над штатным


расписанием (штатные операции):
- создание нового подразделения в организации;
- создание новой штатной единицы в подразделении;
- сокращение штатной единицы в подразделении;
- ликвидация подразделения в организации.
ИС "Отдел кадров" должна обеспечивать формирование документов, соответствующих
произведенным действиям (операциям): приказы, распоряжения, служебные записки, а также
документов со списками сотрудников (с выбором по заданным параметрам) и штатным
расписанием (текущим на заданную дату).
Напомним, что в UML вариантом использования обозначается отдельная часть
функциональных возможностей, предоставляемых системой, а внешним субъектом или
действующим лицом - любой субъект, использующий эти возможности.
Действующее лицо - это классификатор в UML, который описывает множество конкретных
пользователей, взаимодействующих с системой одинаковым образом. Линиями ассоциации на этой
диаграмме соединяются взаимодействующие элементы. Например, действующее лицо
Зав. кадрами участвует в выполнении кадровых операций, то есть взаимодействует с вариантом
использования Кадровые операции. Имена элементов модели, такие как Зав. кадрами или
Кадровые операции фактически являются идентификаторами языка UML.

42
В ИС Отдел кадров выделяется три категории пользователей или три роли, которым
соответствуют три действующих лица, изображенные на диаграмме.
 Зав. кадрами - отвечает за управление данными о персонале организации.
 Зав. штатным расписанием - отвечает за управление данными о штатном расписании.
 Администратор (суперпользователь) - имеет право полного управления системой, в
частности, может вручную корректировать данные в таблицах.
Отметим, что все действующие лица участвуют в таких вариантах использования, как
Получение отчетов, Просмотр таблиц и Архивирование и обновление данных. Чтобы подчеркнуть
это обстоятельство и не загромождать диаграмму лишними линиями, введено абстрактное
действующее лицо Пользователь, которое обобщает остальные действующие лица. Все
конкретные действующие лица наследуют от абстрактного пользователя способ участия в общих
вариантах использования.
Для действующих лиц Зав. кадрами и Зав. штатным расписанием требования, приведенные
выше, делятся на два частично пересекающихся множества. Разделив соответствующим образом
множество функциональных аспектов системы на две части, организуем две подсистемы
приложения "Отдел кадров": Управление персоналом и Штатное расписание.
Подсистема Управление персоналом предназначена для работы с информацией о сотрудниках
и управления движением персонала. С этой подсистемой взаимодействует внешний субъект
Зав. кадрами. Подсистема Штатное расписание предназначена для работы со штатным
расписанием. Эта подсистема находится под управлением внешнего субъекта Зав. штатным
расписанием. Управлять обеими подсистемами разрешено внешнему субъекту Администратор.
Перечислим варианты использования подсистем, выделенные в результате разделения
множества вариантов использования всей системы на две части: Управление персоналом (УП) и
Штатное расписание (ШР):
 выполнение операций, определенных в подсистеме (Кадровые операции, Штатные
операции);
 подготовка и печать отчетов о проведенной операции и других документов (Получение
отчетов УП, получение отчетов ШР);
 просмотр таблиц в подсистеме (Просмотр таблиц УП, Просмотр таблиц ШР);
 правка таблиц в подсистеме непосредственным редактированием (Правка таблиц УП,
Правка таблиц ШР);
 архивирование содержимого базы данных и удаление устаревших данных в подсистеме
(Архивирование и обновление данных УП, Архивирование и обновление данных ШР);
 протоколирование выполненных операций в подсистеме (Протоколирование операций УП,
Протоколирование операций ШР).
Подсистемы Управление персоналом и Штатное расписание связаны между собой: изменение
данных в одной подсистеме может повлечь изменение данных в другой. Например, сокращение
штатной единицы в подсистеме Штатное расписание может сопровождаться увольнением
сотрудника в подсистеме Управление персоналом. Для этого пользователь приложения Отдел
кадров, исполняющий роль субъекта использования Зав. штатным расписанием, должен
потребовать выполнения соответствующей операции у пользователя, исполняющего роль субъекта
использования Зав. кадрами, например, отправив ему соответствующее сообщение по электронной
почте. Необходимо отметить, что обмен сообщениями по электронной почте часто используется
как способ общения сотрудников в больших и средних организациях.

43
Диаграммы использования подсистем Управление персоналом и Штатное расписание
представлены на рис. 3.15 и 3.16.

Управление персоналом

Кадровые "include" Протоколирова-


операции ние операций
УП

Архивирование
и обновление
Получение данных УП
Зав. отчетов УП
кадрами

Просмотр Правка
таблиц УП таблиц УП

Администратор

Рис. 3.15. Диаграмма использования подсистемы «Управление персоналом»

Штатное расписание

Штатные "include" Протоколиро-


операции вание операций
ШР

Архивирование
и обновление
Получение данных ШР
Зав. штатным
отчетов ШР
расписанием

Просмотр Правка
таблиц ШР таблиц ШР

Администратор
44
Рис. 3.16. Диаграмма использования подсистемы «Штатное расписание»

Далее нам необходимо перейти к созданию логической и физической модели и прототипа


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

4. АВТОМАТИЗАЦИЯ ПОЛЬЗОВАТЕЛЬСКИХ ЗАДАЧ

4.1. Понятие макроса

Если какое-то действие часто повторяется, его выполнение можно автоматизировать с


помощью макроса. Макрос - набор из одной или нескольких макрокоманд, выполняющих
определенные операции и использующихся при автоматизации часто выполняемых задач.
Макрокоманда - основной компонент макроса, замкнутая инструкция, самостоятельно или с
другими макрокомандами определяющая выполняемые в макросе действия. Макросы - это
небольшие программы, в которых содержатся стандартные макрокоманды, предназначенные для
выполнения одного или нескольких действий. После создания макросов их можно запускать
всякий раз, когда необходимо выполнить решаемую ими задачу.
Перед тем как записать или написать макрос, необходимо спланировать шаги и команды,
которые он будет выполнять. В макросах могут использоваться условные выражения, которые
проверяют выполнение некоторого условия для осуществления (неосуществления) перехода к
указанной в выражении макрокоманде. Если при записи макроса была допущена ошибка, ее
исправление будет также записано. Каждый раз при записи макроса он сохраняется в новом
модуле, присоединенном к приложению.
Иными словами, макрос является командой, которая создается самим пользователем и служит
для автоматизации рутинных операций. Макросы избавляют пользователя от скучной
механической работы, освободив его для других дел. Стоит отметить, что преимущество макросов
во многом объясняется тем, что язык макрокоманды, тесно связан с функциями приложений, и, по
сути, макросы являются аналогами команд. Это означает, что, изучая процессы создания и запуска
макросов, пользователь работает непосредственно со структурой функций. Благодаря тесной
взаимосвязи функций и макросов пользователь может закреплять команды или макросы за
любыми меню, комбинациями клавиш и панелями инструментов, в том числе и созданных самим
пользователем.
Выражаясь более точно, макросы позволяют перепрограммировать приложения:
модифицировать его функции, изменяя названия связанных с ними команд и их расположение в
меню, преобразуя выполняемые ими действия и заменяя клавиши, которым они присвоены. Так же
свободно можно обращаться и с кнопками панелей инструментов и операциями, которые они
вызывают.

4.1.1. Запись макроса

45
Для создания макросов и работы с ними, надо, по меньшей мере, знать, как выбираются
команды, перемещается курсор ввода и выделяется текст.
Чтобы воспользоваться макросом, его надо сначала создать (записать), а затем запустить.
Существует два способа создания макросов.
1. Запись действий пользователя.
2. С помощью команды “Макрос” из меню “Сервис”.
При создании макроса первым способом он составляется из операторов так, как если бы
программа писалась на каком-нибудь языке программирования. Пользователь должен быть знаком
с языком, на котором составляются макросы.
Второй способ – запись команд и нажатие клавиш – более простой и наиболее приемлем для
пользователя. Достаточно активизировать встроенную в программу функцию записи макрокоманд
и выполнить нужные действия.
В большинстве основных приложений MS Office запуск записи макроса осуществляется с
помощью команды меню "Сервис-Макрос-Начать запись". В появившемся окне диалога
необходимо в соответствующее поле ввести имя макроса. Первым символом имени макроса
должна быть буква. Остальные символы могут быть буквами, цифрами или знаками
подчеркивания. В имени макроса не допускаются пробелы, в качестве разделителей слов следует
использовать знаки подчеркивания, например, Вставка_заголовка_реквизитов.
Чтобы иметь возможность выполнить макрос с клавиатуры с помощью сочетания клавиш,
необходимо ввести соответствующую букву в поле сочетания клавиш. Для строчных букв
используется сочетание “CTRL+ буква”, а для заглавных – “CTRL+SHIFT+ буква”, где “буква” –
любая клавиша на клавиатуре. Буква, используемая в сочетании клавиш, не может быть цифрой
или специальным символом.
Далее надо выбрать дополнительные установки и при необходимости ввести текст в поле
описания. После нажатия кнопки ОК возникает панель остановки записи и начинается режим
непосредственной записи всех действий пользователя в виде программного кода.
Далее пользователь должен выполнить те манипуляции и процедуры, которые нужно записать.
Действия пользователя могут состоять из нескольких стандартных макрокоманд, которые при
запуске макроса будут выполняться одновременно в той последовательности, в которой они были
записаны.
По завершении всех действий пользователя необходимо остановить запись, нажав
соответствующую кнопку на панели инструментов.
Процедура записи макросов во всех приложениях MS Office имеет свои особенности. Так,
например, при записи макроса в Microsoft Excel используются абсолютные ссылки. Макрос,
записанный с абсолютными ссылками, при выполнении всегда обрабатывает те же ячейки,
которые обрабатывались при его записи. Для того чтобы с помощью макроса обрабатывать
произвольные ячейки, следует записать его с относительными ссылками. Для этого следует нажать
кнопку “Относительная ссылка” на панели остановки записи. Относительные ссылки будут
использоваться до конца текущего сеанса работы в Microsoft Excel или до повторного нажатия
кнопки “Относительная ссылка”.
В Microsoft Access для макросов используется специальная вкладка базы данных. Макросы
создаются в окне конструктора макросов путем выбора макрокоманд и задания их параметров.
Макрос можно связать с кнопкой в форме. Для его запуска достаточно щелчка на кнопке. Кроме

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

4.1.2. Способы запуска макросов

В многих приложениях MS Office готовый макрос можно запустить на выполнение одним из


следующих способов.
 Выбрав из меню “Сервис” команду “Макрос-Макросы”. В поле “Имя” следует указать
нужный макрос и нажать кнопку “Выполнить”.
 Назначив макросу кнопку на панели инструментов и щелкнув эту кнопку. Для создания
кнопки макроса на панели инструментов следует выполнить команду меню “Сервис-Настройка”,
выбрать записанный макрос в списке “Команды” и перетащить его на панель инструментов.
 Закрепив макрос за комбинацией клавиш и нажав эти клавиши.

4.2. Создание и применение пользовательских функций

4.2.1. Применение макросов в Excel

Microsoft Excel, как и любая другая программа MS Office, может создавать макросы,
записывая команды меню, нажатия клавиш и другие действия, необходимые для выполнения
некоторой задачи. Процесс записи макроса состоит из трех шагов. Сначала нужно активизировать
режим записи макроса и присвоить ему имя. Затем выполнить действия, которые требуется
записать. После этого необходимо не забыть остановить запись.
Рассмотрим описанный процесс на примере создания простого макроса, который производит
несложные расчеты. Предположим, что фирма предлагает своим клиентам торговую скидку
10 процентов, если заказано больше 100 единиц продукции. Нам известно наименование,
количество заказанных единиц и стоимость одной единицы продукции. Необходимо рассчитать
сумму, скидку и окончательную стоимость товара. Подобный стандартный расчет необходимо
производить во множестве таблиц по различным покупателям и категориям продукции. Создание
макроса позволит максимально упростить задачу и автоматизировать процедуру расчета.
Предположим, что все таблицы имеют структуру, подобную приведенной на рис. 4.1.

47
Рис. 4.1. Исходные данные

В столбце D должна рассчитываться сумма, как произведение количества на цену 1 единицы.


В столбце Е с помощью стандартной функции ЕСЛИ должен рассчитываться размер скидки и в
столбце F должна определяться окончательная стоимость, как разность данных в столбцах D и Е.
Расчет должен производиться в не менее, чем десяти строках одновременно.
Перед создание макроса сделаем активной любую свободную ячейку на рабочем листе, у
которой слева располагаются не менее двух столбцов, например, ячейку D15. Создадим макрос для
чего в меню Сервис выберем команду Макрос, а затем Начать запись. Excel выведет окно диалога
Запись макроса. В окне Имя макроса введем имя Расчет_стоимости (имя вводится без пробелов)
и в окне Сочетание клавиш - букву z для быстрого запуска макроса. Проверим, что в окне
Сохранить в установлена опция Личная книга макросов (в этом случае макрос становится
доступен сразу после запуска Excel). На рис. 4.2 показан результирующий вид окна диалога.

Рис. 4.2. Окно записи макроса


Чтобы начать запись, нажмем кнопку ОК. Excel выведет в строке состояния сообщение
Запись, и на экране появится панель инструментов Остановка записи. На этой панели нажмем
кнопку Относительная ссылка (в этом случае макрос будет реализовываться в активной ячейке).
В ячейку D15 введем формулу =В15*С15, в ячейку Е15 введем функцию
=ЕСЛИ(В15>100;0,1*D15;0), в ячейку F15 введем формулу =D15-E15. Выделим ячейки D15, E15,
F15 и, используя маркер автозаполнения, скопируем их содержимое в нижерасположенные десять
строк (до строки 24).
На панели остановка записи нажмем кнопку Остановить запись. Мы создали макрос, который,
начиная с активной ячейки, рассчитывает сумму, скидку и стоимость одновременно в десяти
строках рабочего листа.
На рабочем листе сделаем активной ячейку D2 и нажмем сочетание клавиш Ctrl+z, возникнут
данные расчета во всей таблице.

48
На панели инструментов Стандартная создадим кнопку для макроса. В меню Сервис выберем
Настройка. В окне диалога Настройка на вкладке Команды в окне Категории выберем Макросы
(рис. 4.3). Из окна Команды перетащим Настраиваемую кнопку на панель инструментов
Стандартная. Закроем окно Настройка и нажмем на созданную кнопку.
В появившемся окне диалога Назначить макрос выберем имя созданного макроса и нажмем ОК.

Рис. 4.3. Окно настройка

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

4.2.2. Использование макросов в Access

Макросы в Access - это мощное и гибкое средство автоматизации всевозможных операций с


базой данных. Например, макросы могут выполнять следующие операции:
 удаление данных из таблицы, импорт новых данных, форматирование новых данных,
экспорт полученных данных;
 открытие формы, добавление или удаление записей, заполнение полей значениями из
другой формы;
 печать писем, занесение в записи отметок о печати;
 распечатку результатов фильтрации и т.п.
Макрос как объект имеет следующие особенности:
 его можно запускать из окна базы данных или связывать с событием, например со щелчком
по кнопке или открытием формы;
 он может состоять из одной или нескольких макрокоманд, для которых можно определить
условие. Если условие выполняется, то выполняется и сама макрокоманда.
Процедура автоматизации многоступенчатых задач с помощью макросов состоит из
нескольких шагов. Для создания макроса в Access необходимо:
49
 создать список всех макрокоманд макроса;
 создать все формы, отчеты, запросы и страницы, над которыми будут выполняться
макрокоманды;
 создать макрос, выполняющий все намеченные операции;
 определить форму запуска макроса: из окна базы данных, связав его с определенным
событием, или щелчком мыши по кнопке (которую надо предварительно создать) в какой-либо
форме.
Описание макросов в Access дается в виде таблиц, в которых указаны макрокоманды, их
аргументы и другие необходимые сведения.
Рассмотрим процедуру создания макроса, открывающего одну из таблиц условной базы
данных. Откроем базу данных в Access. В окне базы данных выделим объект Макросы и щелкнем
кнопку Создать. Возникнет окно создания макросов. С помощью команды меню Окно-Слева
Направо расположим рядом окна базы данных и макросов (рис. 4.4).

Рис. 4.4. Окна базы данных и макросов

Перетащим значок таблицы Таблица1 в первую строку окна макросов, в ней появится команда
Открыть таблицу, а в полях аргументов ее реквизиты (рис. 4.5).

50
Рис. 4.5. Назначение процедуры макросу

Закроем окно макросов, сохранив макрос под именем Открыть_Таблицу1. Из окна макросов
можно запустить созданный макрос и откроется Таблица1. Теперь свяжем макрос с кнопкой на
форме Кнопочная форма. Откроем эту форму в режиме конструктора и расположим ее рядом с
окном макросов. Перетащим значок макроса в свободное место формы, появится кнопка
Открыть_Таблицу1 (рис. 4.6)

Рис. 4.6. Создание кнопки запуска макроса в форме

Перейдем в режим формы и нажмем созданную кнопку, откроется Таблица1.


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

51
Задания для самостоятельной работы

1. Составьте логическую схему базы знаний по теме юниты:

52
2. Какие программные продукты из перечисленных являются офисными
приложениями и могут использоваться для создания офисных приложений:
1) текстовые процессоры;
2) системы управления базами данных;
3) электронные таблицы;
4) средства деловой графики.

3. Для каких целей создается прототип офисного приложения?


____________________________________________________________________________________
____________________________________________________________________________________
____________________________________________________________________________________
____________________________________________________________________________________
____________________________________________________________________________________
_____

4. Опишите особенности процесса внедрения офисного приложения на каждом этапе


этой работы:
____________________________________________________________________________________
____________________________________________________________________________________
____________________________________________________________________________________
____________________________________________________________________________________
____________________________________________________________________________________
_____

5. Перечислите преимущества использования интегрированного пакета Microsoft


Office при создании приложений:
____________________________________________________________________________________
____________________________________________________________________________________
____________________________________________________________________________________
____________________________________________________________________________________
____________________________________________________________________________________
_____

6. Дайте краткую характеристику артефактам офисных приложений согласно


диаграмме жизненного цикла приложения:
____________________________________________________________________________________
____________________________________________________________________________________
____________________________________________________________________________________
____________________________________________________________________________________
____________________________________________________________________________________
_____

7. Перечислите и кратко опишите основные фазы модели процесса разработки


офисного приложения:

53
____________________________________________________________________________________
____________________________________________________________________________________
____________________________________________________________________________________
____________________________________________________________________________________
____________________________________________________________________________________
_____
8. Раскройте термины «спецификация», «визуализация», «проектирование» и
«документирование» по отношению к унифицированному языку моделирования UML:
____________________________________________________________________________________
____________________________________________________________________________________
____________________________________________________________________________________
____________________________________________________________________________________
____________________________________________________________________________________
_____

9. Опишите графическую нотацию, используемую в унифицированном языке


моделирования UML:
____________________________________________________________________________________
____________________________________________________________________________________
____________________________________________________________________________________
____________________________________________________________________________________
____________________________________________________________________________________
_____

10. Приведите классификацию сущностей в унифицированном языке моделирования UML


и кратко опишите сущности, входящие в каждый класс:
____________________________________________________________________________________
____________________________________________________________________________________
____________________________________________________________________________________
____________________________________________________________________________________
____________________________________________________________________________________
_____

11. Перечислите типы отношений в унифицированном языке моделирования UML и


дайте краткое описание каждому из них:
____________________________________________________________________________________
____________________________________________________________________________________
____________________________________________________________________________________
____________________________________________________________________________________
____________________________________________________________________________________
_____

12. Для каких целей в UML используются диаграммы использования, классов и объектов:
____________________________________________________________________________________
____________________________________________________________________________________
____________________________________________________________________________________
54
____________________________________________________________________________________
____________________________________________________________________________________
_____

13. Для каких целей в UML используются диаграммы состояний, деятельности и


последовательности:
____________________________________________________________________________________
____________________________________________________________________________________
____________________________________________________________________________________
____________________________________________________________________________________
____________________________________________________________________________________
_____
14. Для каких целей в UML используются диаграммы кооперации, компонентов и
размещения:
____________________________________________________________________________________
____________________________________________________________________________________
____________________________________________________________________________________
____________________________________________________________________________________
____________________________________________________________________________________
_____

15. Опишите упрощенный набор представлений модели офисного приложения:


____________________________________________________________________________________
____________________________________________________________________________________
____________________________________________________________________________________
____________________________________________________________________________________
____________________________________________________________________________________
_____

16. Опишите назначение макросов при создании офисных приложений:


____________________________________________________________________________________
____________________________________________________________________________________
____________________________________________________________________________________
____________________________________________________________________________________
____________________________________________________________________________________
_____

55
ГЛОССАРИЙ


Новое понятие Содержание
п/п
1 2 3
наиболее часто используемый тип отношения между
1 Ассоциация в языке UML сущностями, который имеет место, если одна сущность
непосредственно связана с другой или с другими
именованное место (слот), в котором может храниться
2 Атрибут
значение
описание последовательности производимых системой
Вариант использования в
3 действий, доставляющей значимый для некоторого
языке UML
действующего лица результат
представление информации в графической форме,
4 Визуализация
предназначенной для восприятия человеком
Действующее лицо в языке сущность, находящаяся вне моделируемой системы и
5
UML непосредственно взаимодействующая с ней
6 Диаграмма в языке UML графическое представление некоторой части графа модели
блок-схема алгоритма, в которой модернизированы
7 Диаграмма деятельности обозначения, а семантика согласована с объектно-
ориентированным подходом
Диаграмма использования наиболее общее представление функционального
8
в языке UML назначения системы
9 Диаграмма классов основной способ описания структуры системы
список артефактов, из которых состоит моделируемая
10 Диаграмма компонентов система, с указанием некоторых отношений между
артефактами
такое же, как и в диаграмме последовательности, описание
последовательности обмена сообщениями взаимо-
11 Диаграмма кооперации
действующих объектов, только выраженное другими
графическими средствами
частный случай диаграммы классов, это примеры,
показывающие, какие имеются объекты и связи между
12 Диаграмма объектов
ними в некоторый конкретный момент функционирования
системы
Диаграмма способ описания системы «на примерах», фактически – это
13
последовательности запись протокола конкретного сеанса работы системы
наряду с отображением состава и связей компонентов,
показывает, как физически размещены компоненты на
14 Диаграмма размещения
вычислительных ресурсах во время выполнения
программы
основной способ детального описания поведения в UML,
представляющий собой граф состояний и переходов
15 Диаграмма состояний
конечного автомата, нагруженный множеством допол-
нительных деталей и подробностей
Жизненный цикл совокупность последовательных форм, которые при-
16
приложения ложение принимает в своем развитии
общий тип отношений между двумя сущностями,
17 Зависимость в языке UML указывающий на то, что изменение независимой сущности
каким-то образом влияет на зависимую сущность
множество операций, которое определяет набор услуг,
18 Интерфейс в языке UML
предоставляемых классом или компонентом
19 Интерфейс пользователя способ взаимодействия пользователя с приложением
описание множества объектов с общими атрибутами и
20 Класс в языке UML
операциями
56
1 2 3
основной компонент макроса, замкнутая инструкция,
21 Макрокоманда самостоятельно или с другими макрокомандами
определяющая выполняемые в макросе действия
набор из одной или нескольких макрокоманд,
22 Макрос выполняющих определенные операции и использующихся
при автоматизации часто выполняемых задач
качественная оценка размера приложения с точки зрения
23 Масштаб приложения
его использования
промежуточный артефакт между техническим заданием и
24 Модель приложения
программным кодом
отношение между двумя сущностями, одна из которых
25 Обобщение в языке UML является частным или специализированным случаем
другой
логическое утверждение относительно значений свойств
26 Ограничение
элементов модели
описание способа выполнения каких-то действий с
27 Операция
объектом
Отношение реализации в указание на то, что одна сущность является реализацией
28
языке UML другой
приложение для бизнеса (business applications) или система
29 Офисное приложение
автоматизации производства
прикладные программы или приложения, которые
Офисные средства
30 одновременно являются как офисными приложениями, так
разработки
и средствами их разработки
Пакет офисных набор приложений, наиболее часто используемых в
31
приложений делопроизводстве
свойство, добавляемое к внутреннему представлению
32 Помеченное значение
модели
прикладная программа, предназначенная для решения
33 Приложение
определенных задач и получения конкретных результатов
черновая версия приложения, которая может состоять из
34 Прототип приложения интерфейса будущего приложения и нескольких ключевых
функций
период в жизненном цикле объекта, в котором объект
35 Состояние в языке UML удовлетворяет некоторому условию, выполняет деятель-
ность или ожидает событий
декларативное описание того, как нечто устроено или
36 Спецификация
работает
определение нового типа сущности на основе
37 Стереотип в UML
существующей сущности
проверка того, что предусмотренные способы
Тестирование использования приложения являются удовлетвори-
38
применимости тельными для пользователя при выполнении типичных
сценариев работы
выявление неперехватываемых ошибок времени
39 Тестирование устойчивости выполнения, нацеленное на то, чтобы вывести из строя
("сломать") приложение
проверка того, что для допустимых (правильных) входных
Тестирование
40 данных получаются допустимые (правильные, корректные,
функциональности
соответствующие спецификациям) результаты
графический язык моделирования общего назначения,
Унифицированный язык предназначенный для спецификации, визуализации,
41
моделирования UML проектирования и документирования всех артефактов,
создаваемых при разработке приложений

57
58