Федеральное государственное бюджетное образовательное учреждение

высшего образования
«Поволжский государственный университет телекоммуникаций и информатики»
_____________________________________________________________________________

Кафедра программного обеспечения и управления в технических системах

(наименование кафедры)

«УТВЕРЖДАЮ»
Заведующий кафедрой ПОУТС
(наименование кафедры)

_______________проф.Тарасов В.Н.
подпись, Фамилия И.О.
«___» _________ 2015 г.
ЛАБОРАТОРНЫЙ ПРАКТИКУМ
ПО УЧЕБНОЙ ДИСЦИПЛИНЕ

Проектирование и архитектура программных систем

(наименование учебной дисциплины)

Для направления подготовки бакалавров:

09.03.04 –« Программная инженерия »
(код и наименование специальности по Классификатору специальностей высшего
профессионального образования)

Обсуждено на заседании
кафедры ПОУТС

«__» _________ 2015 г.

протокол № ___

Самара
2015
 Лабораторная работа № 1
Методология функционального моделирования. Исследование предметной области.
Цель работы: изучить методологию функционального моделирования IDEF0 и получить практические
навыки в моделировании предметной области.
Подготовка к лабораторной работе
Ознакомиться с лекционным материалом.
Теоретическая часть. Моделирование бизнес-процессов предметной области
В случае создания ПО для информационной системы управления предприятием (совокупность средств,
методов и персонала для обработки, хранения и выдачи информации) структурный анализ начинается с
исследования того, как организована система управления предприятием, с обследования функциональной
и информационной структуры системы управления, чтобы понять, как работает организация, которую
собираются автоматизировать. Для описания работы предприятия необходимо построить модель. Такая
модель должна быть адекватна предметной области; следовательно, она должна содержать в себе знания
всех участников бизнес-процессов организации.
По результатам обследования аналитик строит модель «как есть»: обобщенную логическую модель
исходной предметной области, отображающую ее функциональную структуру, особенности основной
деятельности и информационное пространство, в котором эта деятельность осуществляется. Далее создают
модель «как надо»: усовершенствованную обобщенную логическую модель, отображающую
реорганизованную предметную область или ее часть, которая подлежит автоматизации. Эта стадия анализа
содержит элементы проектирования. Структурные, функциональные модели созданные на ранних этапах
проектирования программной систем, помогут проектировщику выявить основные функции и составные части
проектируемой системы и, по возможности, обнаружить и устранить существенные ошибки. Функциональные
диаграммы предметной области помогут понять, как выполняются отдельные операции организации, которые
собираются автоматизировать. На этом уровне определяются все функции, которые выполняет объект, и
процессы , протекающие в объекте (например, подразделениях предприятия) для выполнения функций,
определяются связи между функциями, между процессами. Функция - преобразование входных потоков в
выходные, осуществляемое в соответствии с некоторыми внутренними правилами. Выполнение функции
обеспечивает процесс. Процесс - совокупность взаимосвязанных действий (работ), преобразующих
некоторые входные данные в выходные. Каждый процесс характеризуется определенными задачами и
методами их решения, исходными данными, полученными от других процессов, и результатами. Для
описания работы организации необходимо построить модель и выделить те процессы, которые должны быть
автоматизированы.
Наиболее удобным языком моделирования бизнес-процессов является методология функционального
моделирования - IDEF0, предложенный более 20 лет назад Дугласом Россом (SoftTech, Inc.) и
называвшийся первоначально SADT - Structured Analysis and Design Technique.
В IDEF0 система представляется как совокупность взаимодействующих работ или функций. Такая чисто
функциональная ориентация является принципиальной - функции системы анализируются независимо от
объектов, которыми они оперируют. Это позволяет более четко смоделировать логику и взаимодействие
процессов организации.
Под моделью в IDEF0 понимают описание системы (текстовое и графическое), которое должно дать ответ на
некоторые заранее определенные вопросы.
Моделируемая система рассматривается как произвольное подмножество Вселенной. Произвольное
потому, что, во-первых, мы сами умозрительно определяем, будет ли некий объект компонентом системы,
или мы будем его рассматривать как внешнее воздействие, и, во-вторых, оно зави сит от точки зрения на
систему. Система имеет границу, которая отделяет ее от остальной Вселенной. Взаимодействие системы с
окружающим миром описывается как вход (нечто, что перерабатывается системой), выход (ре зультат
деятельности системы), управление (стратегии и процедуры, под управлением которых производится
работа) и механизм (ресурсы, необходимые для проведения работы). Находясь под управлением, система
преобразует входы в выходы, используя механизмы.
Процесс моделирования какой-либо системы в IDEF0 начинается с определения контекста, т.е. наиболее
абстрактного уровня описания системы в целом. В контекст входит определение субъекта
моделирования, цели и точки зрения на модель.
Под субъектом понимается сама система, при этом необходимо точно установить, что входит в
систему, а что лежит за ее пределами; другими словами, мы должны определить, что мы будем в
дальнейшем рассматривать как компоненты системы, а что как внешнее воздействие. На определение
субъекта системы будет существенно влиять позиция, с которой рас сматривается система, и цель
моделирования - вопросы, на которые построенная модель должна дать ответ; другими словами,
первоначально необходимо определить область (Scope) моделирования. Описание области как системы в
целом, так и ее компонентов является основой построения модели. Хотя предполагается, что в течение
моделирования область может корректироваться, она должна быть в основном сформулирована
изначально, поскольку именно область определяет направление моделирования и когда должна быть
закончена модель. При формулировании области необходимо учитывать два компонента - широту и
глубину. Широта подразумевает определение границ модели - мы определяем, что будет
рассматриваться внутри системы, а что снаружи. Глубина определяет, на каком уровне дета лизации модель
является завершенной. При определении глубины системы необходимо не забывать об ограничениях
времени - трудоемкость построения модели растет в геометрической прогрессии от глубины декомпозиции.
После определения границ модели предполагается, что новые объекты не должны вноситься в
моделируемую систему; поскольку все объекты модели взаимосвязаны, внесение нового объекта может быть
не просто арифметической добавкой, но в состоянии изменить существующие взаимосвязи. Внесение таких
изменений в готовую модель является, как правило, очень трудоемким процессом (так называемая проблема
"плавающей области").
Модели AS-IS и ТО-ВЕ. Целью построения функциональных моделей обычно является выявление
наиболее слабых и уязвимых мест деятельности организации, анализ преимуществ новых бизнес-процессов и
степени изменения существующей структуры организации бизнеса. Анализ недостатков и "узких мест"
начинают с построения модели AS-IS (Как есть), т. е. модели существующей организации работы. Модель
AS-IS может строиться на основе изучения документации (должностных инструкций, положений о
предприятии, приказов, отчетов и т. п.), анкетирования и опроса служащих пред приятия, создания
фотографии рабочего дня и других источников. Полученная модель AS-IS служит для выявления
неуправляемых работ, работ не обеспеченных ресурсами, ненужных и неэффективных работ, дублирующихся
работ и других недостатков в организации деятельности предприятия. Исправление недостатков,
перенаправление информационных и материальных потоков приводит к созданию модели ТО-ВЕ (Как
будет) - модели идеальной организации бизнес-процессов. Как правило, строится несколько моделей ТО-ВЕ,
среди которых определяют наилучший вариант.

TO-BE’

AS-IS TO-BE 1

TO-BE 2

TO-BE 3

Рисунок 1 - Схема построения моделей "ТО-ВЕ" как результат анализа модели "AS-IS"
Технология проектирования программного обеспечения ИС подразумевает сначала создание модели AS-
IS, ее анализ и улучшение бизнес-процессов, т. е. создание модели ТО- ВЕ, и только на основе модели ТО-
ВЕ строится модель данных, прототип и затем окончательный вариант ПО.
Порядок выполнения работы
1. Построить функциональную диаграмму предметной области, согласно выбранного варианта
(Приложение А) с помощью нотации IDEF0.
2. Оформить отчет по лабораторной работе.
3. Представить отчет по лабораторной работе для защиты.
Требования к результатам выполнения лабораторной работы
 Модель должна отражать бизнес-процессы предметной области (Приложение А)
 Наличие в модели не менее 3 уровней: контекстная диаграмма и 2 уровня декомпозиции.
 Контекстная диаграмма должна включать не менее 3 функциональных блоков
Защита отчета по лабораторной работе
Отчет по лабораторной работе должен состоять из следующих структурных элементов:
1. титульный лист;
2. текстовая часть;
3. приложение: разработанная функциональная модель.
Текстовая часть отчета должна включать пункты:
 условие задачи;
 порядок выполнения
 краткие сведения о составе и компонентах построенной функциональной модели.
 Зашита отчета по лабораторной работе заключается в предъявлении преподавателю полученных
результатов в виде файла и демонстрации полученных навыков при ответах на вопросы преподавателя.
Контрольные вопросы
1. Что такое жизненный цикл программного продукта?
2. Дайте определение модели жизненного цикла ПО.
3. Приведите этапы разработки программного средства.
4. Что представляет собой структурный подход к разработке ПС?
5. Что включает в себя этап предпроектного исследования?
6. В чем преимущество построения модели предметной области при разработке ПС?
7. Перечислите особенности методологии SADT?
8. Для чего строят модели AS-IS и TO-BE?
9. Что такое бизнес-процесс?
10. В каких отношениях находятся заказчик и разработчик при выработке требований к программному
средству?

Лабораторная работа № 2
Моделирование структур данных
Цель работы: изучить диаграммы «сущность–связь» для моделирования структур данных.
Подготовка к лабораторной работе
Ознакомиться с лекционным материалом по теме «Информационное обеспечение ИС. Моделирование
информационного обеспечения». Для выполнения лабораторной работы студент должен обладать навыками
работы с пакетом ERwin.
Теоретическая часть. Диаграммы «сущность–связь»
На основе модели потоков данных создается словарь данных (Data Dictionary), в котором хранится и
анализируется состав потоков и накопителей данных, взаимосвязь отдельных элементов потоков и
накопителей данных. Например, при моделировании документооборота вводятся сведения о структуре и
реквизитном составе документов.
Хранимые в словаре данных описания каждого накопителя (хранилища) данных используются для
перехода к построению модели данных в виде диаграмм «сущность–связь» (ERD). В отличие от
функциональных диаграмм (IDEF0) и диаграмм потоков данных (DFD) диаграммы «сущность–связь»
описывают информационное пространство, в рамках которого реализуются процессы объекта предметной
области. Выявляются и определяются элементы базы данных, в которых будут храниться данные системы.
Выявляются и определяются их атрибуты и отношения. Модель данных должна быть привязана к
функциональной модели: элементы модели данных и их атрибуты должны соответствовать накопителям
данных. Диаграмма «сущность–связь» – инструмент разработки моделей данных, обеспечивающий
стандартный способ определения данных и отношений между ними. Она включает сущности и взаимосвязи,
отражающие основные бизнес-правила предметной области. Такая диаграмма не слишком детализирована, в
нее включаются основные сущности и связи между ними, которые удовлетворяют требованиям,
предъявляемым к ИС.

Порядок выполнения работы

4. Определить диаграммы «сущность–связь» для моделирования структур данных.
5. Оформить отчет по лабораторной работе.
6. Представить отчет по лабораторной работе для защиты.
Требования к результатам выполнения лабораторной работы
 При построении модели данных для разрабатываемой ИС должны быть учтены хранилища данных,
показанные в диаграмме потоков данных.
 Для построенной модели должен быть создан словарь терминов.
Защита отчета по лабораторной работе
Отчет по лабораторной работе должен состоять из следующих структурных элементов:
4. Титульный лист;
5. Текстовая часть;
6. Приложение: разработанная модель данных.
Текстовая часть отчета должна включать пункты:
  Условие задачи;
 Порядок выполнения
 Краткие сведения о составе и компонентах построенной модели.
Контрольные вопросы
11. Что такое информационная база?
12. Логическая и физическая модели данных.
13. Требования, предъявляемые к проектированию хранилищ данных.
14. Основная цель использования ERwin.
15. Что такое сущность и атрибут?

Лабораторная работа № 3
Структурный подход. Техническое задание.
Цель работы: составить и проанализировать требования к программе и разработать техническое
задание на разработку программного средства.
Подготовка к лабораторной работе
Ознакомиться с лекционным материалом по теме «Модели ЖЦ ПО. Этапы ЖЦ в соответствии с ГОСТ
19.102-77.
Теоретическая часть. Разработка технического задания
Техническое задание представляет собой документ, в котором сформулированы основные цели разработки,
требования к программному продукту, определены сроки и этапы разработки и регламентирован процесс
приемо-сдаточных испытаний. В разработке технического задания участвуют как представители заказчика, так
и представители исполнителя. В основе этого документа лежат исходные требования заказчика, анализ
передовых достижений техники, результаты выполнения научно-исследовательских работ, предпроектных
исследований, научного прогнозирования и т. п.
Порядок разработки технического задания
Разработка технического задания выполняется в следующей последовательности. Прежде всего,
устанавливают набор выполняемых функций, а также перечень и характеристики исходных данных. Затем
определяют перечень результатов, их характеристики и способы представления.
Далее уточняют среду функционирования программного обеспечения: конкретную комплектацию и
параметры технических средств, версию используемой операционной системы и, возможно, версии и
параметры другого установленного программного обеспечения, с которым предстоит взаимодействовать
будущему программному продукту.
В случаях, когда разрабатываемое программное обеспечение собирает и хранит некоторую информацию
или включается в управление каким-либо техническим процессом, необходимо также четко регламентировать
действия программы в случае сбоев оборудования и энергоснабжения.
1. Общие положения
1.1. Техническое задание оформляют в соответствии с ГОСТ 19.106—78 на листах формата А4 и
A3 по ГОСТ 2.301—68, как правило, без заполнения полей листа. Номера листов (страниц) проставляют в
верхней части листа над текстом.
1.2. Лист утверждения и титульный лист оформляют в соответствии с ГОСТ 19.104—78.
Информационную часть (аннотацию и содержание), лист регистрации изменений допускается в документ не
включать.
1.3. Для внесения изменений и дополнений в техническое задние на последующих стадиях
разработки программы или программного изделия выпускают дополнение к нему. Согласование и утверждение
дополнения к техническому заданию проводят в том же порядке, который установлен для технического
задания.
1.4. Техническое задание должно содержать следующие разделы:
•введение;
•наименование и область применения;
• основание для разработки;
• назначение разработки;
• технические требования к программе или программному изделию;
• технико-экономические показатели;
• стадии и этапы разработки;
• порядок контроля и приемки;
• приложения.
 В зависимости от особенностей программы или программного изделия допускается уточнять
содержание разделов, вводить новые разделы или объединять отдельные из них. При необходимости
допускается в техническое задание включать приложения.
2. Содержание разделов
2.1. Введение должно включать краткую характеристику области применения программы или
программного продукта, а также объекта (например, системы), в котором предполагается их использовать.
Основное назначение введения — продемонстрировать актуальность данной разработки и показать, какое
место эта разработка занимает в ряду подобных.
2.2. В разделе «Наименование и область применения» указывают наименование, краткую
характеристику области применения программы или программного изделия и объекта, в котором используют
программу или программное изделие.
2.3. В разделе «Основание для разработки» должны быть указаны:
• документ (документы), на основании которых ведется разработка. Таким документом может служить
план, приказ, договор и т. п.;
• организация, утвердившая этот документ, и дата его утверждения;
• наименование и (или) условное обозначение темы разработки.
2.4. В разделе «Назначение разработки» должно быть указано функциональное и эксплуатационное
назначение программы или программного изделия.
2.5. Раздел «Технические требования к программе или программному изделию» должен содержать
следующие подразделы:
• требования к функциональным характеристикам;
• требования к надежности;
• условия эксплуатации;
• требования к составу и параметрам технических средств;
• требования к информационной и программной совместимости;
• требования к маркировке и упаковке;
• требования к транспортированию и хранению;
• специальные требования.
2.5.1. В подразделе «Требования к функциональным характеристикам» должны быть указаны
требования к составу выполняемых функций, организации входных и выходных данных, временным
характеристикам и т. п.
2.5.2. В подразделе «Требования к надежности» должны быть указаны требования к обеспечению
надежного функционирования (обеспечение устойчивого функционирования, контроль входной и выходной
информации, время восстановления после отказа и т. п.).
2.5.3. В подразделе «Условия эксплуатации» должны быть указаны условия эксплуатации
(температура окружающего воздуха, относительная влажность и т. п. для выбранных типов носителей данных),
при которых должны обеспечиваться заданные характеристики, а также вид обслуживания, необходимое
количество и квалификация персонала.
2.5.4. В подразделе «Требования к составу и параметрам технических средств» указывают
необходимый состав технических средств с указанием их технических характеристик.
2.5.5. В подразделе «Требования к информационной и программной совместимости о должны быть
указаны требования к информационным структурам на входе и выходе и методам решения, исходным кодам,
языкам программирования. При необходимости должна обеспечиваться защита информации и программ.
2.5.6. В подразделе «Требования к маркировке и упаковке» в общем случае указывают требования к
маркировке программного изделия, варианты и способы упаковки.
2.5.7. В подразделе «Требования к транспортированию и хранению» должны быть указаны для
программного изделия условия транспортирования, места хранения, условия хранения, условия складирования,
сроки хранения в различных условиях.
2.5.8. В разделе «Технико-экономические показатели» должны быть указаны: ориентировочная
экономическая эффективность, предполагаемая годовая потребность, экономические преимущества разработки
по сравнению с лучшими отечественными и зарубежными образцами или аналогами.
2.6. В разделе «Стадии и этапы разработки» устанавливают необходимые стадии разработки, этапы
и содержание работ (перечень программных документов, которые должны быть разработаны, согласованы и
утверждены), а также как правило, сроки разработки и определяют исполнителей.
2.7. В разделе «Порядок контроля и приемки» должны быть указаны виды испытаний и общие
требования к приемке работы.
2.8. В приложениях к техническому заданию при необходимости приводят:
• перечень научно-исследовательских и других работ, обосновывающих разработку;
• схемы алгоритмов, таблицы, описания, обоснования, расчеты и другие документы, которые
могут быть использованы при разработке;
• другие источники разработки.
В случаях, если какие-либо требования, предусмотренные техническим заданием, заказчик не
предъявляет, следует в соответствующем месте указать «Требования не предъявляются».
 Примеры разработки технического задания приведены в приложениях Б и В.
Порядок выполнения работы
1. Разработать техническое задание на программный продукт согласно своему варианту (см.
варианты в приложении А) в соответствии с ГОСТ 19.106-78. При разработке технического задания
не ограничиваться функциями, приведенными в варианте, добавить несколько своих функций.
Пример технического задания представлен в Приложении Б.
2. Оформить отчет по лабораторной работе.
3. Представить отчет по лабораторной работе для защиты.
Требования к результатам выполнения лабораторной работы
При формировании технического задания обратить внимание на
 Наличие пользовательских требований четко описывающий функционал разрабатываемого
программного средства (не мене 20)
 Наличие системных требований, включающих требования к структуре, программному интерфейсу,
технологии разработки, общие требования к системе (надежность, модульность, безопасность и т.д.)
 Наличие календарного графика по этапам разработки программного средства, выполненного в виде
диаграммы Ганта.
Защита отчета по лабораторной работе
Отчет по лабораторной работе должен состоять из следующих структурных элементов:
 титульный лист;
 текстовая часть;
 приложение: разработанное технического задания на программный продукт.
Текстовая часть отчета должна включать пункты:
 условие задачи;
 порядок выполнения.
Зашита отчета по лабораторной работе заключается в предъявлении преподавателю полученных
результатов в виде файла и демонстрации полученных навыков при ответах на вопросы преподавателя.
Контрольные вопросы
1. Что такое жизненный цикл программного продукта?
2. Дайте определение модели жизненного цикла ПО.
3. Приведите этапы разработки программного средства.
4. Какие этапы включает в себя модель ЖЦ ПС согласно ГОСТ 19.102-77?
5. Что включает в себя этап предпроектного исследования?
6. Перечислите функциональные требования к программному продукту.
7. Перечислите эксплуатационные требования к программному продукту.
8. Перечислите правила разработки технического задания.
9. Назовите основные разделы технического задания.
10. В каких отношениях находятся заказчик и разработчик при выработке требований к программному
средству?
Лабораторная работа № 4
Методология объектно-ориентированного моделирования. Анализ системы
Цель работы: изучить методологию объектно-ориентированного моделирования и получить
практические навыки в моделировании предметной области с помощью UML.
Подготовка к лабораторной работе
Ознакомиться с лекционным материалом по теме «Объектный подход к проектированию программного
обеспечения. Диаграммы вариантов использования».
Для выполнения лабораторной работы студент должен обладать навыками работы с пакетом Rational Rose,
справочная информация по использованию которого представлена в первой части данного пособия.
Теоретическая часть. Моделирование бизнес-процессов предметной области
Вариант использования представляет собой последовательность действий (транзакций), выполняемых
системой в ответ на событие, инициируемое некоторым внешним объектом (действующим лицом). Вариант
использования описывает типичное взаимодействие между пользователем и системой. В простейшем случае
вариант использования определяется в процессе обсуждения с пользователем тех функций, которые он хотел
бы реализовать.
 Действующее лицо (actor) – это роль, которую пользователь играет по отношению к системе.
Действующие лица представляют собой роли, а не конкретных людей или наименования работ. Несмотря на то,
что на диаграммах вариантов использования они изображаются в виде стилизованных человеческих фигурок,
действующее лицо может также быть внешней системой, которой необходима некоторая информация от
данной системы. Показывать на диаграмме действующих лиц следует только в том случае, когда им
действительно необходимы некоторые варианты использования.
Действующие лица делятся на три основных типа – пользователи системы, другие системы,
взаимодействующие с данной, и время. Время становится действующим лицом, если от него зависит запуск
каких-либо событий в системе.
В языке UML на диаграммах вариантов использования поддерживается несколько типов связей между
элементами диаграммы.
Это связи коммуникации (communication), включения (include), расширения (extend) и обобщения
(generalization).
Связь коммуникации – это связь между вариантом использования и действующим лицом. На языке UML
связи коммуникации показывают с помощью однонаправленной ассоциации (сплошной линии со стрелкой).
Направление стрелки позволяет понять, кто инициирует коммуникацию.
Связь включения применяется в тех ситуациях, когда имеется какой-либо фрагмент поведения системы,
который повторяется более чем в одном варианте использования. С помощью таких связей обычно моделируют
многократно используемую функциональность.
Связь расширения применяется при описании изменений в нормальном поведении системы. Она позволяет
варианту использования только при необходимости использовать функциональные возможности другого.
На языке UML связи включения и расширения показывают в виде зависимостей с соответствующими
стереотипами, как показано на рисунке 2.

Рисунок 2 - Связи использования и расширения

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

Рисунок 3 - Обобщение действующего лица

Нет необходимости всегда создавать связи этого типа. В общем случае, они нужны, если поведение
действующего лица одного типа отличается от поведения другого постольку, поскольку это затрагивает
систему. Если оба подтипа используют одни и те же варианты использования, показывать обобщение
действующего лица не требуется.
Порядок выполнения работы
7. Построить модель предметной области, согласно выбранного варианта (Приложение А) с
помощью диаграммы вариантов использования UML.
8. Оформить отчет по лабораторной работе.
9. Представить отчет по лабораторной работе для защиты.
 Порядок построения модели
Создание бизнес-схемы компании
1. Щелкните правой кнопкой мыши на представлении Use Case View в браузере.
2. Выберем пункт New далее Package
3. Назовем новый пакет «Общая схема»
Чтобы поместить действующее лицо в браузер:
1. Щелкните правой кнопкой мыши на пакете «Общая схема» представления Use Case View в
браузере.
2. Выберите в открывшемся меню пункт New далее Actor
3. В браузере появится новое действующее лицо под названием NewClass. Слева от его имени вы
увидите пиктограмму действующего лица UML.
4. Выделив новое действующее лицо, введите его имя.
5. Щелкните правой кнопкой мыши на действующем лице.
6. В открывшемся меню выберите пункт Open Specification.
7. В поле стереотипа выберите Business Actor и нажмите на кнопку ОК.
8. После создания действующих лиц сохраните модель с помощью пункта меню File затем Save.
Чтобы поместить вариант использования в браузер:
1. Щелкните правой кнопкой мыши на пакете «Общая схема» представления Use Case View в
браузере.
2. Выберите в появившемся меню пункт New > Use Case
3. Новый вариант использования под названием NewUseCase появится в браузере. Слева от него
будет видна пиктограмма варианта использования UML.
4. Выделив новый вариант использования, введите его название.
5. Щелкните правой кнопкой мыши на варианте использования.
6. В открывшемся меню выберите пункт Open Specification.
7. В поле стереотипа выберите Business Use Case и нажмите на кнопку ОК.
Для создания новой диаграммы вариантов использования:
1. Щелкните правой кнопкой мыши на пакете «Общая схема» представления Use Case View в
браузере.
2. Из всплывающего меню выберите пункт New далее Use Case Diagram.
3. Выделив новую диаграмму, введите ее имя («Общая схема действий»).
4. Дважды щелкните на названии этой диаграммы в браузере, чтобы открыть ее.
5. Чтобы поместить действующее лицо или вариант использования на диаграмму, перетащите его
мышью из браузера на диаграмму вариантов использования.
6. С помощью кнопки Unidirectional Association (Однонаправленная ассоциация) панели
инструментов нарисуйте ассоциации между действующими лицами и вариантами использования.
Требования к результатам выполнения лабораторной работы
 Модель должна отражать бизнес-процессы предметной области (Приложение Г)
Защита отчета по лабораторной работе
Отчет по лабораторной работе должен быть состоять из следующих структурных элементов:
7. титульный лист;
8. текстовая часть;
9. приложение: разработанная модель вариантов использования.
Текстовая часть отчета должна включать пункты:
 условие задачи;
 порядок выполнения
 краткие сведения о составе и компонентах построенной модели.
Зашита отчета по лабораторной работе заключается в предъявлении преподавателю полученных
результатов в виде файла и демонстрации полученных навыков при ответах на вопросы преподавателя.

Лабораторная работа № 5
Методология объектно-ориентированного моделирования. Проектирование
системы. Логическое представление

Цель работы: изучить методологию объектно-ориентированного моделирования и получить

практические навыки в моделировании конфигурации системы при разработке программного обеспечения с
помощью UML.
 Подготовка к лабораторной работе
Ознакомиться с лекционным материалом по теме «Объектный подход к проектированию программного
обеспечения. Диаграммы вариантов использования».
Для выполнения лабораторной работы студент должен обладать навыками работы с пакетом Rational Rose,
справочная информация по использованию которого представлена в первой части данного пособия.
Теоретическая часть. Моделирование требований к программному обеспечению
Разработка логической структуры. После завершения формирования принципов использования системы,
наступает этап разработки ее логической структуры. В Rational Rose он именуется "Logical View". Логическое
представление, концентрируется на том, как система будет реализовывать поведение, описанное в вариантах
использования. Оно дает подробную картину составных частей системы и описывает взаимодействие этих
частей. Логическое представление включает, помимо прочего, конкретные требуемые классы, диаграммы
классов и диаграммы состояний. С их помощью конструируется детальный проект создаваемой системы.
Логическое представление содержит:
 классы,
 диаграммы классов. Как правило, для описания системы используется несколько диаграмм классов,
каждая из которых отображает некоторое подмножество всех классов системы,
 диаграммы взаимодействия, применяемые для отображения объектов, участвующих в одном потоке
событий варианта использования,
 диаграммы состояний,
 пакеты, являющиеся группами взаимосвязанных классов.
Для каждого блока использования строится диаграмма взаимодействия, на которой отображается
взаимодействие во времени объектов, выполняющих поставленную задачу. На подобных диаграммах
идентифицируются объекты системы и определяются сообщения, с помощью которых эти объекты
взаимодействуют
Диаграммы взаимодействия (interaction diagrams) описывают поведение взаимодействующих групп
объектов. На такой диаграмме отображается ряд объектов и те сообщения, которыми они обмениваются между
собой.
Сообщение (message) – это средство, с помощью которого объект-отправитель запрашивает у объекта
получателя выполнение одной из его операций.
Информационное (informative) сообщение – это сообщение, снабжающее объект-получатель некоторой
информацией для обновления его состояния.
Сообщение-запрос (interrogative) – это сообщение, запрашивающее выдачу некоторой информации об
объекте-получателе.
Императивное (imperative) сообщение – это сообщение, запрашивающее у объекта-получателя выполнение
некоторых действий.
Существует два вида диаграмм взаимодействия: диаграммы последовательности (sequence diagrams) и
кооперативные диаграммы (collaboration diagrams).
Каждый объект на диаграмме последовательностей сопровождается именем класса, к которому он
принадлежит. Конкретный объект является экземпляром некоторого класса. Классы образуют логическую
структуру системы.
Результатом данного этапа должна стать главная диаграмма, и детализирующие диаграммы для ее
элементов.
На этом этапе следует определить классы, которые необходимы в системе. Экземпляры этих классов уже
указаны на диаграммах последовательностей. Классы и их связи отражается в модели в виде диаграммы
классов. Группы классов на этих диаграммах могут быть объединены в пакеты.
Проектирование логической структуры следует начинать с определения основных пакетов. Пакет –
универсальное средство для группировки элементов модели. Применение пакетов позволяет сделать модель
более обозримой. Пакеты могут быть вложенными друг в друга. Классы, составляющие каждый пакет,
детализируются на вложенной диаграмме.
Идентификация основных абстракций заключается в предварительном определении набора классов
системы (классов анализа) на основе описания предметной области.
Все классы и диаграммы, описывающие системный проект, помещаются в пакет с именем Design Model.
Диаграммы классов, реализующие варианты использования и диаграммы взаимодействия, отражающие
взаимодействие объектов в процессе реализации сценариев варианта использования, помещаются в кооперацию
с именем данного варианта использования и стереотипом «use-case realization». Все кооперации помещаются в
пакет с именем Use-Case Realization. Связь между вариантом использования и его реализацией изображается на
специальной диаграмме трассировки (рис.4).
 Рисунок 4 - Диаграмма трассировки
Порядок выполнения работы
1. Для реализации сценариев варианта использования постройте
a. диаграммы классов, реализующих вариант использования,
b. диаграммы взаимодействия, отражающие взаимодействие объектов в процессе.
c. кооперативные диаграммы для построенных диаграмм взаимодействия
2. Все построенные диаграммы помещаются в кооперацию с именем данного варианта использования
и стереотипом «use-case realization». Все кооперации помещаются в пакет с именем Use Case
Realizations.
3. Оформить отчет по лабораторной работе.
4. Представить отчет по лабораторной работе для защиты.
Порядок построения модели
Создание классов
1. Щелкните правой кнопкой мыши на представлении Logical View.
2. Выберите в открывшемся меню пункт New\Class. Новый класс под названием NewClass появится в
браузере.
3. Выделите его и введите имя класса.
4. Щелкните правой кнопкой мыши на созданном классе.
5. В открывшемся меню выберите пункт Open Specification.
6. В поле стереотипа выберите необходимый стереотип (Boundary, Control, Entity) и нажмите на
кнопку ОК.
7. Откройте диаграмму Main и перетащите созданные классы.
Создание пакетов и диаграммы Traceabilities:
8. Щелкните правой кнопкой мыши на представлении Logic View.
9. В открывшемся меню выберите пункт New\Package.
10. Создайте пакет Use-Case Realizations, затем внутри него – пакеты соответствующие построенным
вариантам использования.
11. В каждом из пакетов создайте соответствующие кооперации (каждая кооперация представляет
собой вариант использования со стереотипом «use-case realization», который задается в
спецификации варианта использования).
12. Создайте в пакете Use-Case Realizations новую диаграмму вариантов использования с названием
Traceabilities, которая показывает связь между вариантом использования и его реализацией
(диаграмма трассировки).
Создание диаграмм взаимодействия
Настройка
1. В меню модели выберите пункт Tools далее Options.
2. Перейдите на вкладку диаграмм.
3. Контрольные переключатели Sequence Numbering, Collaboration Numbering должны быть
помечены, а Focus of Control – нет.
4. Нажмите ОК, чтобы выйти из окна параметров.
Создание диаграммы последовательности
1. Щелкните правой кнопкой мыши на кооперации
2. В открывшемся меню выберите пункт New далее Sequence Diagram.
3. Назовите новую диаграмму.
4. Дважды щелкните на ней, чтобы открыть ее.
 Добавление на диаграмму действующего лица, объектов и сообщений
1. Перетащите действующее лицо из браузера на диаграмму.
2. Перетащите классы из браузера на диаграмму.
3. На панели инструментов нажмите кнопку Object Message (Сообщение объекта).
4. Проведите мышью от линии жизни действующего лица к линии жизни объекта
5. Выделив сообщение, введите его имя.
6. Повторите действия 3 – 5, чтобы поместить на диаграмму остальные сообщения (для
рефлексивного сообщения используется кнопка Message to Self).
Соотнесение сообщений с операциями
1. Щелкните правой кнопкой на тексте сообщении
2. В открывшемся меню выберите пункт <new operation>. Появится окно спецификации операции.
3. В поле имени оставьте имя сообщения.
4. Нажмите на кнопку ОК, чтобы закрыть окно спецификации операции и вернуться на диаграмму.
5. Повторите действия 1 – 4, пока не соотнесете с операциями все остальные сообщения.
Создание примечаний
Чтобы поместить на диаграмму примечание:
1. Нажмите на панели инструментов кнопку Note.
2. Щелкните мышью в том месте диаграммы, куда собираетесь поместить примечание.
3. Выделив новое примечание, введите туда текст.
4. Чтобы прикрепить примечание к элементу диаграммы, на панели инструментов нажмите кнопку
Anchor Notes To Item (Прикрепить примечания к элементу).
5. Нажав левую кнопку мыши, проведите указатель от примечания до элемента диаграммы, с
которым оно будет связано. Между примечанием и элементом возникнет штриховая линия.
6. Чтобы создать примечание-ссылку на другую диаграмму создайте пустое примечание (без текста)
и перетащите на него из браузера нужную диаграмму.
Чтобы поместить на диаграмму текстовую область:
1. На панели управления нажмите кнопку Text Box.
2. Щелкните мышью внутри диаграммы, чтобы поместить туда текстовую область.
3. Выделив эту область, введите в нее текст.
Создание кооперативной диаграммы
Для создания кооперативной диаграммы достаточно открыть диаграмму последовательности и нажать
клавишу F5.
Лабораторная работа № 6
Методология объектно-ориентированного моделирования. Реализация системы

Цель работы: изучить методологию объектно-ориентированного моделирования и получить

практические навыки в генерации программы на основе построенных моделей
Подготовка к лабораторной работе
Ознакомиться с лекционным материалом по теме «Объектный подход к проектированию программного
обеспечения. Диаграммы компонентов».
Для выполнения лабораторной работы студент должен обладать навыками работы с пакетом Rational Rose,
справочная информация по использованию которого представлена в первой части данного пособия.
Теоретическая часть. Диаграммы компонентов
Диаграммы компонентов показывают, как выглядит модель на физическом уровне. На них изображены
компоненты программного обеспечения и связи между ними. При этом на такой диаграмме выделяют два типа
компонентов: исполняемые компоненты и библиотеки кода.
Каждый класс модели (или подсистема) преобразуется в компонент исходного кода. После создания они
сразу добавляются к диаграмме компонентов. Между отдельными компонентами изображают зависимости,
соответствующие зависимостям на этапе компиляции или выполнения программы. Пример диаграммы
компонентов показан на рисунке 5
 Рисунок 5 – Пример диаграммы компонентов.
Представление компонентов содержит:
– Компоненты, являющиеся физическими модулями кода.
– Диаграммы компонентов.
– Пакеты, являющиеся группами связанных компонентов.
Порядок выполнения работы
5. Для реализации построенной системы
a. постройте диаграмму компонентов
b. выполните проверку корректности модели
c. выполните генерацию кода,
6. Оформить отчет по лабораторной работе.
7. Представить отчет по лабораторной работе для защиты.
Порядок построения модели
Создание диаграммы компонентов:
1. Дважды щелкните мышью по главной диаграмме компонентов в представлении компонентов.
2. На панели инструментов нажмите кнопку Package Specification.
3. Поместите спецификацию пакета на диаграмму.
4. Введите имя спецификации пакета и укажите в окне спецификации язык программирования для
генерации кода.
5. На панели инструментов нажмите кнопку Package Body.
6. Поместите тело пакета на диаграмму.
7. Введите имя тела пакета и укажите в окне спецификации язык генерации кода
8. На панели инструментов нажмите кнопку Dependency.
9. Проведите линию зависимости от тела пакета к спецификации пакета.
Соотнесение классов с компонентами:
1. В логическом представлении браузера найдите необходимый для генерации класс.
2. Перетащите этот класс на спецификацию пакета компонента в представлении компонентов
браузера. В результате класс будет соотнесен со спецификацией пакета компонента.
Процесс генерации кода состоит из четырех основных шагов:
1. Проверка корректности модели.
2. Установка свойств генерации кода.
3. Выбор класса, компонента или пакета.
4. Генерация кода.
Для проверки модели:
1. Выберите в меню Tools\Check Model.
2. Проанализируйте все найденные ошибки в окне журнала, используя команду View\Log.
К наиболее распространенным ошибкам относятся такие, например, как сообщения на диаграмме
последовательности или кооперативной диаграмме, не соотнесенные с операцией, либо объекты этих диаграмм,
не соотнесенные с классом.
С помощью пункта меню Check Model можно выявить большую часть неточностей и ошибок в модели.
Пункт меню Access Violations позволяет обнаруживать нарушения правил доступа, возникающие тогда, когда
существует связь между двумя классами разных пакетов, но связи между самими пакетами нет.
Для того чтобы обнаружить нарушение правил доступа:
1. Выберите в меню Report\Show Access Violations.
2. Проанализируйте все нарушения правил доступа в окне.
 Можно установить несколько параметров генерации кода для классов, атрибутов, компонентов и других
элементов модели. Этими свойствами определяется способ генерации программ. Для каждого языка в Rose
предусмотрен ряд определенных свойств генерации кода. Перед генерацией кода рекомендуется анализировать
эти свойства и вносить необходимые изменения.
Для анализа свойств генерации кода
1. выберите Tools\Options, а затем вкладку соответствующего языка.
2. в окне списка можно выбрать класс, атрибут, операцию и другие элементы модели.
Для каждого языка в этом списке указаны свои собственные элементы модели. При выборе разных
значений на экране появляются разные наборы свойств.
Для изменения свойства генерации кода для одного класса, атрибута, одной операции и т.д. нужно
1. открыть окно спецификации элемента модели. Выбрать вкладку языка (C++, Java,...) и изменить
свойства. Все изменения, вносимые в окне спецификации элемента модели, оказывают влияние
только на этот элемент.
При генерации кода за один раз можно создать класс, компонент или целый пакет. Код генерируется с
помощью диаграммы или браузера. При генерации кода из пакета можно выбрать или пакет логического
представления на диаграмме классов, или пакет представления компонентов на диаграмме компонентов. При
выборе пакета логического представления генерируются все классы этого пакета. При выборе пакета
представления компонентов генерируются все компоненты этого пакета .
После выбора класса или компонента на диаграмме выберите в меню соответствующий вариант генерации
кода. Сообщения об ошибках, возникающих в процессе генерации кода, будут появляться в окне журнала.
Во время генерации кода Rose выбирает информацию из логического и компонентного представлений
модели и генерирует большой объем «скелетного» (skeletal) кода:
Генерация кода
3. Откройте диаграмму компонентов системы.
4. Выберите все объекты на диаграмме компонентов.
5. Выберите Tools\(язык для генерации кода)\Code Generation в меню.
6. Выполните генерацию кода.
7. Просмотрите результаты генерации (меню Tools\\(язык для генерации кода)\ Browse Header и
Tools\\(язык для генерации кода)\Browse Body.
 Приложение А
Варианты заданий
Лабораторные работы № 1—8 выполняются для одного и того же варианта.
1. Опишите процесс учета посещения студентов учебных занятий и успеваемости студентов с
точки зрения работника деканата.
Разработать программный модуль «Учет успеваемости студентов». Программный модуль предназначен
для оперативного учета успеваемости студентов в сессию деканом, заместителями декана и сотрудниками
деканата. Сведения об успеваемости студентов должны храниться в течение всего срока их обучения и
использоваться при составлении справок о прослушанных курсах и приложений к диплому.
2. Опишите процесс учета студентов, обучающихся в институте от процесса зачисления студента
до получения диплома с точки зрения работника деканата.
Разработать программный модуль «Личные дела студентов». Программный модуль предназначен для
получения сведений о студентах сотрудниками деканата, профкома и отдела кадров. Сведения должны
храниться в течение всего срока обучения студентов и использоваться при составлении справок и отчетов.
3. Опишите процесс организации рабочего дня руководителя с точки зрения его секретаря.
Разработать приложение «Органайзер». Приложение предназначено для записи, хранения и поиска
адресов и телефонов физических лиц и организаций, а также расписания, встреч и др. Приложение
предназначено для организации рабочего дня руководителя.
4. Опишите процесс работы кафедры вуза с точки зрения преподавателя.
Разработать программный модуль «Кафедра», содержащий сведения о сотрудниках кафедры (ФИО,
должность, ученая степень, дисциплины, нагрузка, общественная работа, совместительство и др.). Модуль
предназначен для использования сотрудниками отдела кадров и деканата.
5. Опишите процесс работы лаборатории с точки зрения ее служащего.
Разработать программный модуль «Лаборатория», содержащий сведения о сотрудниках лаборатории
(ФИО, пол, возраст, семейное положение, наличие детей, должность, ученая степень). Модуль предназначен
для использования сотрудниками профкома и отдела кадров.
6. Опишите процесс работы химчистки с точки зрения ее служащего.
Разработать программный модуль «Химчистка». При записи на обслуживание заполняется заявка, в
которой указываются ФИО владельца, описание изделия, вид услуги, дата приема заказа и стоимость услуги.
После выполнения работ распечатывается квитанция.
7. Опишите процесс организации работы с нарушителями правил дорожного движения с точки
зрения работника милиции.
Разработать программный модуль «Учет нарушений правил дорожного движения». Для каждой
автомашины (и ее владельца) в базе хранится список нарушений. Для каждого нарушения фиксируется дата,
время, вид нарушения и размер штрафа. При оплате всех штрафов машина удаляется из базы.
8. Опишите процесс работы автомагазина с точки зрения его служащего.
Разработать программный модуль «Картотека автомагазина», предназначенный для использования
работниками магазина. В базе содержатся сведения об автомобилях (марка, объем двигателя, дата выпуска и
др.). При поступлении заявки на покупку производится поиск подходящего варианта. Если такого нет, клиент
заносится в клиентскую базу и оповещается, когда вариант появляется.
9. Опишите процесс работы АТС с точки зрения ее служащего.
Разработать программный модуль «Картотека абонентов АТС». Картотека содержит сведения о
телефонах и их владельцах. Фиксирует задолженности по оплате (абонентской и повременной). Считается, что
повременная оплата местных телефонных разговоров уже введена.
10. Опишите процесс организации работы автостанции с точки зрения ее служащего.
Разработать программный модуль «Автокасса», содержащий сведения о наличии свободных мест на
автобусные маршруты. В базе должны содержаться сведения о номере рейса, маршруте, водителе, типе
автобуса, дате и времени отправления, а также стоимости билетов. При поступлении заявки на билеты
программа производит поиск подходящего рейса.
11. Опишите процесс работы книжного магазина с точки зрения его служащего.
Разработать программный модуль «Книжный магазин», содержащий сведения о книгах (автор,
название, издательство, год издания, цена). Покупатель оформляет заявку на нужные ему книги, если таковых
нет, он заносится в базу и оповещается, когда нужные книги поступают в магазин.
12. Опишите процесс работы автостоянки с точки зрения ее служащего.
Разработать программный модуль «Автостоянка». В программе содержится информация о марке
автомобиля, его владельце, дате и времени въезда, стоимости стоянки, скидках, задолженности по оплате и др.
13. Опишите процесс организации работы гостиницы с точки зрения администратора.
Разработать программный модуль «Гостиница», содержащий сведения о наличии свободных мест и о
проживающих в гостинице. Программный модуль предназначен для бронирования мест в гостинице и
оформления проживающих.
14. Опишите процесс организации работы детективного агентства с точки зрения ее работников.
 Разработать программный модуль «Детективное агентство», содержащий сведения о клиентах
агентства и об оказанных услугах. Программный модуль предназначен для учета средств за оказанные услуги.
15. Опишите процесс работы музея с точки зрения его служащего.
Разработать программный модуль «Музей», предназначенный для использования работниками музея. В
базе содержатся сведения об экспонатах музея и вносятся данные при поступлении новых экземпляров. При
выполнении инвентаризации данные заносятся в базу, проводится сверка и выдаются отчеты по учету
экспонатов в музее.
 Приложение Б

Пример. Разработать программный модуль «Кадровое агентство», содержащий сведения о вакансиях и

резюме. Программный модуль предназначен как для поиска сотрудника, отвечающего требованиям
руководителей фирмы, так и для поиска подходящей работы. Так же оформляется титульный лист.
Введение
Настоящее техническое задание распространяется на разработку программы для поиска сотрудника,
отвечающего требованиям руководителей фирмы и для поиска подходящей работы, которая предназначена для
автоматизации работы кадрового агентства.
1. Наименование и область применения
1.1. Наименование
Программный модуль «Кадровое агентство».
1.2. Область применения
Данная разработка предназначена для применения в отделе по работе с клиентами кадрового агентства
«Your work»
2. Основание для разработки
2.1. Основание
Программа разрабатывается на основе лабораторной работы «Этапы разработки программного
обеспечения при структурном подходе к программированию. Стадия «Техническое задание»».
2.2. Тема разработки
Разработка программного модуля «кадровое агентство»
2.3. Исполнитель:
Группа №1. Состав группы: Болдескул Евгения, Волнова Наталья, Гриненко Ксения, Лунев Кирилл.
2.4. Соисполнители
Нет.
3. Назначение разработки
Программа предназначена для использования работниками кадрового агентства для автоматизации
процесса поиска по заявкам клиентов требуемых вакансий и по заявкам работодателей соответствующих
сотрудников.
4. Технические требования к программе или программному изделию
4.1. Требования к функциональным характеристикам
4.1.1. Функциональные требования
Программа должна обеспечивать возможность выполнения следующих функций:
 ввод и корректировка информации о соискателях;
 удаление информации о соискателях;
 ввод, корректировка информации о работодателях;
 удаление информации о работодателях;
 поиск соискателей, удовлетворяющих требованиям работодателей;
 поиск работодателей, удовлетворяющих критериям соискателей;
 формирование отчетов по вакантным должностям, предоставляемых фирмами;
 формирование отчетов по квалификациям соискателей на получение вакантных должностей;
4.1.2. Исходные данные
 резюме соискателя;
 заявки работодателей.
4.2. Требования к надежности
В разрабатываемой системе необходимо предусмотреть следующие меры защиты:
 контроль вводимой информации;
 разграничение прав доступа;
 защиту от несанкционированного доступа посредствам паролей;
 возможность резервного копирования;
 автоматического сохранения изменений после завершения транзакций.
Время восстановления после отказа, вызванного сбоем электропитания технических средств (иными
внешними факторами), не фатальным сбоем операционной системы, не должно превышать времени,
необходимого на перезагрузку операционной системы и запуск программы.
Время восстановления после отказа, вызванного неисправностью технических средств, фатальным сбоем
(крахом) операционной системы, не должно превышать времени, требуемого на устранение неисправностей
технических средств и переустановки программных средств.
4.3. Условия эксплуатации
Минимальное количество персонала, требуемого для работы программы, должно составлять не менее 2
штатных единиц - системный программист и конечный пользователь программы - оператор.
Системный программист должен иметь минимум среднее техническое образование.
В перечень задач, выполняемых системным программистом, должны входить:
 задача поддержания работоспособности технических средств;
 задачи установки (инсталляции) и поддержания работоспособности системных программных средств -
операционной системы;
 задача установки (инсталляции) программы.
Конечный пользователь программы (агент по недвижимости) должен обладать практическими навыками
работы с графическим пользовательским интерфейсом операционной системы.
4.4. Требования к составу и параметрам технических средств
В состав технических средств должен входить IBM-совместимый персональный компьютер (ПЭВМ),
включающий в себя:
 процессор Pentium II и выше с тактовой частотой, 400 ГГц , не менее;
 оперативную память объемом, 128 Mб, не менее;
 жесткий диск объемом 40 Гб, и выше;
 манипулятор типа «мышь»;
 и так далее...
4.5. Требования к информационной и программной совместимости
Системные программные средства, используемые программой, должны быть представлены
локализованной версией операционной системы Windows XP.
4.6. Требования к маркировке и упаковке
Не предъявляются.
4.7. Требования к транспортированию и хранению
Не предъявляются.
4.8. Специальные требования
Программа должна быть снабжена графическим интерфейсом.
5. Технико-экономические показатели
Ориентировочная экономическая эффективность не рассчитывается.
Предполагаемое число использования программы в год – ежедневное использование программы, за
исключением выходных дней, в течение рабочего дня.
6. Стадии и этапы разработки
6.1. Стадии разработки
Разработка должна быть проведена в три стадии:
 разработка технического задания;
 рабочее проектирование;
 внедрение.
6.2. Этапы разработки
На стадии разработки технического задания должен быть выполнен этап разработки, согласования и
утверждения настоящего технического задания.
На стадии рабочего проектирования должны быть выполнены перечисленные ниже этапы работ:
 изучение предметной области
 проектирование системы
 разработка программного программы;
 разработка программной документации;
 тестирование и отладка программы.
 внедрение программы
На рисунке представлена диаграмма Ганта для процесса проектирования
7. Порядок контроля и приемки
После проведения испытаний в полном объеме, на основании «Протокола испытаний» утверждают
«Свидетельство о приемке», после чего программный продукт считается принятым.
 Приложение В

Ведомость эскизного проекта

На предыдущих стадиях разработки программы для автоматизации процессов работы книжного
магазина были составлены и утверждены следующие документы:
Техническое задание на создание программы по автоматизации процессов работы книжного магазина,
разработанное на основании ГОСТ 19.201-78 ЕСПД.
Пояснительная записка к эскизному проекту
Общие положения
Данный документ является эскизным проектом на создание программного продукта для автоматизации
работы книжного магазина (ИС «Книжный магазин»).
Перечень организаций, участвующих в разработке системы на стадии разработки, а также ее цели и
назначение указаны в техническом задании на создание программы.
Основные технические решения
Решения по структуре системы
Программная система «Книжный магазин» будет представлять собой систему поиска книг в каталоге и
оповещения покупателя о наличии или поступлении необходимых ему книг, работающей на одном
компьютере.
Система будет взаимодействовать с реляционной базой данных, представляющей собой набор
связанных между собой таблиц в формате Microsoft Access, доступ к которым осуществляется с помощью
ключей или индексов. Сведения в одной таблице могут отражать сведения из другой, и при изменении
сведений в первой таблице эти изменения немедленно отображаются во второй. Таким образом, будет
достигнута непротиворечивость данных.
Общая структура базы данных:
 Информация о покупателях:
 Ф.И.О.;
 E-mail;
 Контактный телефон;
 Заявки покупателей:
 Список требуемых книг:
o Наименование;
o Автор;
o Издание;
o Год издания;
o Количество.
 Информация о книгах:
 Наименование;
 Автор;
 Издание;
 Год издания;
 ISBN номер;
 Количество.
Решения по режимам функционирования, работы системы
ПС «Книжный магазин» будет функционировать в однопользовательском режиме, а также будет
способна:
 просматривать записи базы данных (в том числе и при помощи фильтров);
 добавлять новые записи;
 редактировать записи;
 удалять записи;
Решения по численности, квалификации и функциям персонала автоматизированной системы
(АС)
Указанные решения должны удовлетворять требованиям, приведенным в техническом задании на
разработку системы.
Состав функций комплексов задач, реализуемых системой
Автоматизированная система должна выполнять следующие функции:
 оповестить покупателя о наличии требуемых книг по e-mail;
 оповестить продавца-консультанта о наличии требуемых книг;
 ввод информации о книгах;
 редактирование и удаление информации о книгах;
  ввод информации о покупателях;
 редактирование и удаление информации о покупателях;
 оформление заявок;
 редактирование и удаление заявок;
 поиск по каталогу и определение количества требуемых книг на складе;
 вывод отчета о результатах поиска;
 выдача полной информации о книге (автор, название, издательство, год издания, цена, количество
на складе);
Решения по составу программных средств, языкам деятельности, алгоритмам процедур и
операций и методам их реализации
Для реализации ПС будет использоваться среда программирования Boland Delphi 7.0 и язык
программирования Object Pascal.
Источники разработки
Данный документ разрабатывался на основании ГОСТ 34.698-90 на автоматизированные системы
управления от 01.01.1990 г.
Приложения
К документу прилагаются диаграммы потоков данных для разрабатываемой программной системы.
 Приложение Г

В качестве примера рассматривается деятельность вымышленной компании. Компания занимается в

основном сборкой и продажей настольных компьютеров и ноутбуков. Компания не производит компоненты
самостоятельно, а только собирает и тестирует компьютеры.
Основные процедуры в компании таковы:
 продавцы принимают заказы клиентов;
 операторы группируют заказы по типам компьютеров;
 операторы собирают и тестируют компьютеры;
 операторы упаковывают компьютеры согласно заказам;
 кладовщик отгружает клиентам заказы.
Компания использует купленную бухгалтерскую информационную систему, которая позволяет
оформить заказ, счет и отследить платеж по счетам.
Для создания модели вариантов использования выделены:
Действующие лица (business actors):
1. Клиент; 2 Сотрудник; 3 Кладовщик.
Варианты использования:
Исходя из потребностей действующих лиц, выделяются следующие варианты использования (Business
Use Case):
 принять заказ;
 группировать заказы по типом компьютеров;
 собирать и тестировать компьютеры;
 упаковывать компьютеры согласно заказам.
Готовая диаграмма вариантов использования должна выглядеть как на рисунке
Рисунок 6 - Диаграмма использования для бизнес-модели системы.

принять заказ
Клиент

группирует заказы по типам

компьютеров

отгружает клиентам заказы

Сотрудник

собирают и тестируют компьютеры

упоковывают компьютеры согласно

кладовщик
заказам