Преподаватель который помогает студентам и школьникам в учёбе.

Разработка регламента выполнения процесса «Обеспечение послепродажного обслуживания» (Сервис послепродажного обслуживания)

Содержание:

Введение

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

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

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

Целью данной работы является Разработка регламента выполнения процесса «Обеспечение послепродажного обслуживания».

Задачи работы – построить:

- развернутое (подробное) описание предметной области;

- диаграмму вариантов использования;

- диаграмму деятельности;

- диаграмму последовательности;

- диаграмму состояний;

- диаграмму классов.

Обеспечение послепродажного обслуживания

Сервис послепродажного обслуживания

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

определение требований к послепродажному обслуживанию продукции на стадии его разработки совместно с потребителем[3];
определение услуг, предоставляемых потребителю после продажи продукции;
установление порядка послепродажного обслуживания продукции в процессе обсуждения условий её поставки;
подготовка кадрового состава для проведения эксплуатационных и ремонтных работ;
подготовка и выпуск необходимой технической документации;
организация обеспечения запасными частями и инструментами, необходимыми для осуществления послепродажного обслуживания;
управление послепродажным обслуживанием продукции;
подготовка необходимой инфраструктуры для обеспечения послепродажного обслуживания;
разработка системы замены продукции на её современные модификации и утилизации старой продукции

Критерии сервиса послепродажного обслуживания

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

1.1. количество отказов на заявки по проведению определенного вида послепродажного обслуживания определенного вида продукции;

1.2. количество отказов на заявки по обеспечению определенным видом запасных частей определенного вида продукции[2];

1.3. количество отказов на замену устаревшего вида продукции на новые аналоги;

1.4. количество отказов в утилизации определенного вида продукции;

2. качество. Характеризует качество выполняемого сервиса послепродажного обслуживания по каждому виду обслуживания для каждого вида продукции в сопоставлении со среднерыночным уровнем качества;

3. время. Рассматривает временные характеристики сервиса послепродажного обслуживания, т.е. время обеспечения каждого вида сервиса в сравнении со среднерыночным временем;

4. цена. Рассматривает ценовые характеристики вида сервиса послепродажного обслуживания в сравнении со среднерыночной ценой;

5. надёжность предоставления сервиса. Позволяет дать вероятностную оценку определённого вида сервиса послепродажного обслуживания по времени и качеству. Включает[4]:

5.1. вероятность отказа в связи с несоответствием определённого вида сервиса послепродажного обслуживания по требуемому качеству;

5.2. вероятность отказов в связи с невозможностью оказания определённого вида сервиса послепродажного обслуживания за требуемое потребителем время.

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

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

Послепродажное обслуживание часто ассоциировалось с таким явлением, как выход оборудования из строя, так что, в конце концов, на него был наклеен ярлык «необходимого зла». Однако в настоящее время стало ясно, что повышение качества продукции никоим образом не ведет к уменьшению роли обслуживания, и, в частности, в послепродажный период. Напротив, именно благодаря одновременному развертыванию деятельности по двум направлениям на наиболее высокопроизводительных предприятиях удается применить на практике понятие «тотальное качество»[3].

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

Организация ООО «Техсервис» образовалась в 2003 году. Компания предоставляет клиентам широкий спектр услуг по продаже компьютерной техники и ее послепродажному обслуживанию:

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

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

Создание главной диаграммы прецедентов

По умолчанию в представлении Вариантов Использования уже существует главная диаграмма прецедентов (Main)[1].

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

Для нашей предметной области мы выделили следующих актеров:

Таблица 1 Актеры

Актер	Краткое описание
Оператор	Отвечает на звонок клиента и перенаправляет звонок соответствующему специалисту
Специалист по оборудованию	Сотрудник, который занимается решением проблем с оборудованием
Специалист по ПО	Сотрудник, который занимается решением проблем с ПО
Завскладом	Сотрудник, который заведует складом комплектующих

Рассмотрим теперь, какие возможности должна предоставлять наша система[5]:

актер Оператор использует систему для приема и распределения звонков и управления информацией о клиентах предприятия;
актер Специалист по оборудованию использует систему для определения неисправности просмотра перечня необходимых для закупки комплектующих и ведения информации о снабжении;
актер Специалист по ПО использует систему для определения проблемы с ПО и оформления наряда на переустановку или доработку;
актер Завскладом использует систему для учета поступления и выдачи комплектующих[1].

На основании вышеизложенного можно выделить следующие прецеденты:

Таблица 2 Прецеденты

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

Рис.1 Диаграмма прецедентов

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

Х.1 предусловия;
Х.2 главный поток;
Х.3 под-потоки;
Х.4 альтернативные потоки;
Х.5 постусловия.

где Х - число от единицы до количества прецедентов[6].

Поток событий для прецедента «Прием звонка».

1. Предусловия.

Если поступает звонок от нового клиента, то под-поток добавить нового клиента (Add a New Client) прецедента Управление информацией о клиенте должен быть выполнен перед его началом.

1. Главный поток.

Прецедент начинает выполняться, когда оператор подключается к системе и вводит свое имя и пароль. Система проверяет правильность пароля (Е-1) и выводит возможные варианты действий: выбрать специалиста, добавить (Add), изменить (Change), удалить (Delete), просмотреть (View) или выйти (Exit),.

1. Под-потоки.

S-1: выбрать специалиста

Система отображает диалоговое окно, содержащее поле, в котором оператор должен выбрать специалиста для решения проблемы клиента.

S-1: добавить новый заказ (Add a New Order)

Система отображает диалоговое окно, содержащее поля для заполнения Оператор заполняет поля (E-2). Система запоминает введенные данные и распечатывает счет для оплаты. Затем прецедент начинается сначала[6].

S-2: изменить заказ (Change Order)

Система отображает диалоговое окно, содержащее список заказов и поле для ввода номера заказа. Оператор выбирает необходимый заказ из списка или вводит номер заказа в поле (Е-3). Система отображает информацию о данном заказе. Оператор делает необходимые изменения (Е-2). Система запоминает введенные данные. Затем прецедент начинается сначала.

S-3: удалить заказ (Delete Order)

Система отображает диалоговое окно, содержащее список заказов и поле для ввода номера заказа. Оператор выбирает необходимый заказ из списка или вводит номер заказа в поле (Е-3). Система удаляет выбранный заказ (Е-4). Затем прецедент начинается сначала.

S-4: просмотреть заказ (View Order)

Система отображает диалоговое окно, содержащее список заказов и поле для ввода номера заказа. Оператор выбирает необходимый заказ из списка или вводит номер заказа в поле (Е-3). Система отображает информацию о выбранном заказе. Когда Оператор просмотрит информацию, прецедент начнется сначала.

Поток событий для прецедента «Управление информацией о клиенте».

2.1 Предусловия.

2.2 Главный поток.

Прецедент начинает выполняться, когда Оператор подключается к системе и вводит свое имя и пароль. Система проверяет правильность пароля (Е-1) и выводит возможные варианты действий: добавить (Add), изменить (Change), удалить (Delete), просмотреть (View) или выйти (Exit).

2.3 Под-потоки.

S-1: добавить нового клиента (Add a New Client)

Система отображает диалоговое окно, содержащее поля для ввода данных о новом клиенте. Пользователь заполняет поля (Е-2). Система запоминает введенные данные. Затем прецедент начинается сначала.

S-2: изменить данные о клиенте (Change Client Data)

Система отображает диалоговое окно, содержащее список клиентов и поле для ввода номера клиента. Оператор выбирает необходимого клиента из списка или вводит его номер в поле (Е-3). Система отображает информацию о данном клиенте. Оператор делает необходимые изменения (Е-2). Система запоминает введенные данные. Затем прецедент начинается сначала.

S-3: удалить клиента (Delete Client)

Система отображает диалоговое окно, содержащее список клиентов и поле для ввода номера клиента. Оператор выбирает необходимого клиента из списка или вводит его номер в поле (Е-2). Система удаляет выбранного клиента (Е-4). Затем прецедент начинается сначала.

S-4: просмотреть данные о клиенте (View Client Data)

Система отображает диалоговое окно, содержащее список клиентов и поле для ввода номера клиента. Оператор выбирает необходимого клиента из списка или вводит его номер в поле (Е-3). Система отображает информацию о выбранном клиенте. Когда Оператор просмотрит информацию, прецедент начнется сначала.

Поток событий для прецедента «Учет поступления и выдачи комплектующих.

3.1 Предусловия.

3.2 Главный поток.

Прецедент начинает выполняться, когда завскладом подключается к системе и вводит свое имя и пароль. Система проверяет правильность пароля (Е-1) и выводит возможные варианты действий: добавить (Add), отметить (Mark) или выйти (Exit).

3.3 Под-потоки.

S-1: внести поступившие комплектующие (Add a New Components)

Система отображает диалоговое окно, содержащее поля для ввода наименования комплектующих, их количества, поставщика. Завскладом заполняет указанные поля (Е-2). Система запоминает введенные данные. Затем прецедент начинается сначала.

S-2: сделать отметку о выдаче комплектующих (Change Order)

Система отображает список комплектующих, находящихся на складе. Завскладом напротив нужных комплектующих вводит количество выданных (Е-3). Система запоминает введенные данные. Затем прецедент начинается сначала[5].

Поток событий для прецедента «Ремонт техники».

4.1 Предусловия.

4.2 Главный поток.

Прецедент начинает выполняться, когда Специалист по оборудованию подключается к системе и вводит свое имя и пароль. Система проверяет правильность пароля (Е-1) и выводит возможные варианты действий: просмотреть (View), отметить (Mark) или выйти (Exit).

4.3 Под-потоки.

S-1: Просмотреть наряд на htvjyn компьютера (View an Make Computer Order)

Система отображает диалоговое окно, содержащее список нарядов и поле для ввода номера наряда. Специалист выбирает необходимый наряд из списка или вводит его номер в поле (Е-2). Система отображает информацию о выбранном наряде. Когда инженер просмотрит информацию, прецедент начнется сначала[6].

S-2: сделать отметку о статусе компьютера (Mark Computer)

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

Поток событий для прецедента «Установка и настройка ПО».

5.1 Предусловия.

5.2 Главный поток.

Прецедент начинает выполняться, когда Специалист по ПО подключается к системе и вводит свое имя и пароль. Система проверяет правильность пароля (Е-1) и выводит возможные варианты действий: просмотреть (View), отметить (Mark) или выйти (Exit).

5.3 Под-потоки.

S-1: Просмотреть наряд на установку ПО

Система отображает диалоговое окно, содержащее список нарядов и поле для ввода номера наряда. Специалист выбирает необходимый наряд из списка или вводит его номер в поле (Е-2). Система отображает информацию о выбранном наряде. Когда специалистпросмотрит информацию, прецедент начнется сначала.

S-2: сделать отметку о статусе компьютера (Mark Computer)

Создание диаграммы классов

Создание диаграммы классов для сценария "Выполнить ремонт оборудования" прецедента "Ремонт оборудования"
Создадим классы-сущности Еntry (Заявка), Client (Клиент), Мaster (Специалист) и ComponentPart (Комплектующее изделие). Поскольку в один заказ может входить много разных комплектующих изделий, и одно комплектующее изделие может входить во много заказов, то введем еще один класс-сущность ComponentМaintenance (Запчасти для Ремонта). Опишем каждый класс[7].

Таблица 3 Класс Client

Параметр	Значение
Комментарий	Класс, представляющий собой клиента фирмы
Атрибуты	name : String - наименование клиента address : String - адрес клиента phone : String - телефон клиента Все атрибуты имеют модификатор доступа - private
Операции	AddClient() - добавление нового клиента RemoveClient() - удаление существующего клиента GetInfo() - получить информацию о клиенте Все операции имеют модификатор доступа - public

Таблица 4 Класс Мaster

Параметр	Значение
Комментарий	Класс, представляющий собой сотрудника
Атрибуты	name : String - наименование сотрудника address : String - адрес сотрудника phone : String - телефон сотрудника Все атрибуты имеют модификатор доступа - private
Операции	AddClient() - добавление нового сотрудника RemoveClient() - удаление существующего сотрудника GetInfo() - получить информацию о сотруднике Все операции имеют модификатор доступа - public

Таблица 5. Класс Еntry:

Параметр	Значение
Комментарий	Класс, представляющий собой заявку на обслуживание
Атрибуты	entryNumber : Integer - номер заявки entryDate : Date - дата оформления заявки entryComplete : Date - дата выполнения заявки idМaster специалист, выполняющий заявку Все атрибуты имеют модификатор доступа - private
Операции	Create() - создание новой заявки SetInfo() - занести информацию о заявке GetInfo() - получить информацию о заявке Все операции имеют модификатор доступа - public

Таблица 6 Класс ComponentМaintenance

Параметр	Значение
Комментарий	Класс, представляющий собой пункт заявки клиента
Атрибуты	itemNumber : Integer - номер пункта заявки quantity : Integer - количество комплектующих изделий price : Double - цена за единицу Все атрибуты имеют модификатор доступа - private
Операции	Create() - создание новой строки заявки SetInfo() - занести информацию о строке заказа GetInfo() - получить информацию о строке заказа Все операции имеют модификатор доступа - public

Таблица 7 Класс ComponentPart

Параметр	Значение
Комментарий	Класс, представляющий собой комплектующие изделия
Атрибуты	name : String – наименование manufacturer : String – производитель price : Double - цена за единицу description – описание Все атрибуты имеют модификатор доступа - private
Операции	AddComponent() - добавление нового комплектующего изделия RemoveComponent() - удаление комплектующего изделия GetInfo() - получить информацию о комплектующем изделии Все операции имеют модификатор доступа - public

Результат создания классов-сущностей показан на рис. 3:

Рисунок 3. Созданные классы-сущности

Добавим отношения между классами (рис. 4):

Рисунок 4. Итоговая диаграмма классов

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

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

Составим диаграмму состояний для класса Entry (Заявка), поскольку в нашей модели он наиболее часто будет менять свое состояние. Заказ может находится в нескольких состояния:

при создании заказа он переходит в состояние Инициализация, в котором выполняются некоторые предварительные действия;
после завершения инициализации заказ переходит в состояние Открыт, в котором к заказу добавляются новые пункты. Выход из этого состояния возможен или в случае отмены заказа, или в случае заполненния всех необходимых пунктов заказа;
если заполнены все необходимые пункты заказа, то он переходит в состояние Закрыт, в котором происходит выписка счета. Выход из этого состояния произойдет только после того, как счет будет выписан;
если заказ отменен, то из состояния Открыт он переходит в состояние Отменен. При выходе из этого состояния происходит удаление всех пунктов заказа.

Диаграмма состояний для класса Entry представлена на рис.5:

Рисунок 5. Диаграмма состояний для класса Entry

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

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

В состоянии Выбор Специалиста заявка передается специалисту соответствующего профиля

В состояние Отменен заказ переходит из состояния Открыт при наступлении события "заказ отменен". При выходе из него выполняется действие выхода "Сохранить дату отмены". При переходе из этого состояния в конечное выполняется действие "* OderItem.Delete()" (удаление пункта заказа). Здесь также стоит "*", поскольку это действие будет выполняться много раз.

Создание диаграмм деятельности.

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

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

Для создания диаграммы действий необходимо щелкнуть правой кнопкой мыши по Представлению Вариантов Использования и в появившемся меню выбрать пункт New > Activity Diagram, ввести ее имя, после чего дважды щелкнуть по ней в браузере, чтобы открыть ее. Результат построения диаграммы показан на рис. 6:

Рисунок 6. Диаграмма деятельности бизнес-процесса

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

Поток событий варианта использования "Прием звонка" состоит из главное потока, под-потоков и альтернативных потоков. Чтобы не загромождать диаграмму покажем поток событий на нескольких диаграммах деятельности. На первой из них (условно назовем ее главной) покажем действия для основного потока и связанный с ним альтернативный поток (рис. 7). Под-потоки можно будет показать путем декомпозиции соответствующего действия главной диаграммы.

Рисунок 7. Диаграмма деятельности для потока событий прецедента "Работа с заказом"

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

Создание диаграммы последовательности для сценария "Добавить новую заявку" прецедента " Ремонт техники "

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

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

На диаграмме последовательности объект изображается в виде прямоугольника, от которого вниз проведена пунктирная вертикальная линия. Эта линия называется линией жизни (lifeline) объекта. Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия.

Каждое сообщение представляется в виде стрелки между линиями жизни двух объектов. Сообщения появляются в том порядке, как они показаны на странице сверху вниз. Каждое сообщение помечается как минимум именем сообщения. При желании можно добавить также аргументы и некоторую управляющую информацию. Можно показать самоделегирование (self-delegation) – сообщение, которое объект посылает самому себе, при этом стрелка сообщения указывает на ту же самую линию жизни.

Рисунок 8. Итоговая диаграмма последовательности

Заключение

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

диаграмма вариантов использования;
диаграмма деятельности;
диаграмма последовательности;
диаграмма состояний;
диаграмма классов
диаграмма прецедентов.

Список литературы

Кознов Д.В Языки визуального моделирования: проектирование и визуализация программного обеспечения. Учебное пособиеСПб.: Изд-во СПбГУ, 2004, 143 с
Буч Г., Якобсон А., Рамбо ДжUML 2.0СПб.: Питер, 2006, 735 с
UML 2.0 Infrastructure SpecificationMarca D.A., McGowan C.LSADT Structured Analysis and Design Technique McGraw-Hill, 1988
Якобсон А., Буч Г., Рамбо Дж Унифицированный процесс разработки програмСПб.: Питер, 2002, 492 с
Фаулер М., Скотт К UML. ОсновыСПб.: Символ, 2006, 184 с
Леоненков А.ВОбъектно-ориентированный анализ и проектирование с использованием UML и IBM Rational Rose М.: Интернет-Университет Информационных Технологий; БИНОМ. Лаборатория знаний, 2006, 319 с
Павлинов А., Кознов Д., Перегудов А., Бугайченко Д., Казакова А., Чернятчик Р., Фесенко Т., Иванов АО средствах разработки проблемно-ориентированных визуальных языков. Сб. «Системное программирование», Вып. 2
Гамма Э., Хелм Р., Джонсон Р., Влиссидес ДжПриемы объектно-ориентированного проектированияИзд-во Питер, 2005, 368 с