Технология программирования. Часть 1

Московский государственный технический университет  
имени Н.Э. Баумана 
Т.И. Вишневская,  Т.Н. Романова 
ТЕХНОЛОГИЯ ПРОГРАММИРОВАНИЯ 
Часть 1 
Методические указания  
к лабораторному практикуму 
М о с к в а  
Издательство МГТУ им. Н.Э. Баумана 
2 0 0 7  

УДК 681.3.06 (076) 
ББК 32.973-018.2 
В55 
Рецензент О.В. Рогозин 
Вишневская Т.И., Романова Т.Н. 
В55 
Технология программирования: Метод. указания к лабораторному практикуму. – Ч. 1. – М.:  
Изд-во МГТУ им. Н.Э. Баумана, 2007. – 59 с.: ил. 
  
Сформулированы задания для лабораторных работ по курсу «Технология программирования», 
даны необходимые пояснения и примеры.  
Для студентов, обучающихся по специальности «Информатика и вычислительная техника».  
Ил. 9. Библиогр. 15 назв. 
УДК 681.3.06 (076) 
ББК 32.973-018.2 
 
© МГТУ им. Н.Э.Баумана, 2007 

 
ПРЕДИСЛОВИЕ  
С каждым годом существенно возрастает уровень сложности программного 
обеспечения (ПО). При этом разработка его становится невозможной без использования современных информационных технологий в программной инженерии.  
Описываемый в данной работе практикум предназначен для освоения полного инженерного цикла разработки сложных программных продуктов: от написания технического задания на проект до тестирования ПО. Рассмотрены вопросы применения объектно-ориентированного подхода при анализе и проектировании программного обеспечения с использованием языка визуального моделирования UML, технологий .Net и методов объектно-ориентированного тестирования; перечислены основные приемы моделирования сложных информационных систем, сформулированы конкретные задания по разработке ПО. 
Практикум предназначен для студентов специальности «Информатика и 
вычислительная техника», изучающих информационные технологии в рамках 
дисциплины «Технология программирования». 
Авторы выражают благодарность студентам факультета «Информатика и 
системы управления» МГТУ им. Н.Э. Баумана А.В. Шляевой, Н.С. Костылеву, 
В.В. Корниенко и Т.И. Максимчук за помощь в разработке программных проектов по предложенной авторами методике. 
ЗАДАНИЕ НА ЛАБОРАТОРНЫЙ ПРАКТИКУМ 
Цель практикума – самостоятельная разработка студентами объектноориентированной системы с использованием основ современной программной инженерии. 
Основные задачи практикума следующие: 
• написание технического задания на проект; 
• создание моделей анализа и проектирования объектно-ориентированных 
систем с использованием языка моделирования UML; 
• получение количественных характеристик для оценки визуальной модели 
разрабатываемой программной системы; 
• знакомство с существующими стратегиями объектно-ориентированного тестирования и приобретение навыков разработки тестов для конкретного программного 
продукта.  
В ходе проведения практикума студент должен: 
• выбрать задачу для разработки объектно-ориентированной программы;  
• написать техническое задание в соответствии с ГОСТ 19.201–78. ЕСПД 
«Техническое задание. Требования к содержанию». Пример оформления технического задания дан в приложении 1;  
 
3

• выполнить восемь лабораторных работ, задания на которые содержатся в 
данных методических указаниях; 
• представить отчет о выполненной работе. 
Для успешного выполнения практикума в приложениях представлены отдельные фрагменты программной разработки моделирования системы массового 
обслуживания. На этом достаточно простом примере демонстрируются основные 
инженерные решения для выполнения лабораторных работ. 
1. ПРИМЕНЕНИЕ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПОДХОДА  
К АНАЛИЗУ И ПРОЕКТИРОВАНИЮ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ 
Подходы к проектированию программного обеспечения 
Программные системы предназначены для моделирования реальных систем, 
поэтому важно, в каких терминах мы пытаемся описать эти реальные системы. 
Процедурным является такой подход, когда функционирование системы описывается в виде последовательности действий. Объектно-ориентированный подход 
предполагает моделирование взаимодействия объектов. Разработка информационной системы всегда начинается с анализа предметной области. Целью любого анализа, в том числе и объектно-ориентированного, является моделирование поведения системы исходя только из функциональных требований к ней. К результатам 
анализа обычно относят техническое задание на разработку системы, модель предметной области, концептуальную модель проектируемой системы. Для описания 
моделей системы при объектно-ориентированном подходе удобно использовать 
визуальное моделирование в достаточно полной нотации UML (Unified Modeling 
Language – унифицированный язык моделирования), которая расширяется при переходе от анализа к проектированию. 
UML представляет собой язык для определения, представления, проектирования и документирования программных систем.  
Стандарт UML версии 1.1 предлагает следующий набор диаграмм для моделирования: 
1) диаграммы вариантов использования, или прецедентов (use case diagrams) – 
для моделирования бизнес-процессов организации и требований к создаваемой системе; 
2) диаграммы классов (class diagrams) – для моделирования статической 
структуры классов системы и связей между ними; 
3) диаграммы поведения системы (behavior diagrams); 
4) диаграммы взаимодействия (interaction diagrams); 
5) диаграммы последовательности действий (sequence diagrams); 
6) диаграммы сотрудничества, или кооперации (collaboration diagrams) – для 
моделирования процесса обмена сообщениями между объектами; 
7) диаграммы состояний (statechart diagrams) – для моделирования поведения 
объектов системы при переходе из одного состояния в другое; 
8) диаграммы деятельности (activity diagrams) – для моделирования поведения системы в рамках различных вариантов использования, или моделирования 
деятельностей; 
 
4

9) диаграммы реализации (implementation diagrams); 
10) диаграммы компонентов (component diagrams) – для моделирования иерархии компонентов (подсистем) системы; 
11) диаграммы размещения (deployment diagrams) – для моделирования физической архитектуры системы. 
Работа 1. Диаграммы прецедентов 
Рис. 1. Нотация языка UML для изображения актера 
Рис. 2. Нотация 
языка UML для 
изображения 
прецедента  
Поведение разрабатываемой системы, т. е. функциональность, обеспечиваемая ею, описывается с помощью функциональной модели, которая отображает системные прецеденты (use cases), системное окружение (действующих лиц, или актеров, – actors) и связи между прецедентами и актерами. Основная задача модели 
прецедентов – представлять собой единое средство, дающее 
возможность заказчику, конечному пользователю и разработчику совместно обсуждать функциональность и поведение 
системы. 
Разработка модели прецедентов начинается с выбора 
актеров и определения общих принципов функционирования 
системы. Затем на этапе проработки модель дополняется детальной информацией к существующим прецедентам, а при 
необходимости добавляются новые. 
Актер – это не часть системы, а человек или прибор, 
взаимодействующий с ней (рис. 1). Актеры могут: 
• только снабжать информацией систему; 
• только получать информацию из системы; 
• снабжать систему информацией и получать информацию из нее. 
Обычно актеры определяются из описания задачи или путем переговоров с 
заказчиками и экспертами. Для выявления актеров может быть использована следующая группа вопросов: 
1. Кто заинтересован в определенном системном требовании? 
2. Какую роль система будет выполнять в организации? 
3. Кто получит преимущества от использования системы? 
4. Кто будет снабжать систему информацией, использовать 
информацию и получать информацию от системы? 
5. Кто будет осуществлять поддержку и обслуживание 
системы? 
6. Использует ли система внешние ресурсы? 
7. Выступает ли какой-либо участник системы в нескольких ролях? 
8. Выступают ли различные участники в одной роли? 
С помощью прецедентов (use cases) моделируют диалог между актером и 
системой. Другими словами, прецеденты определяют возможности, обеспечиваемые системой для актера. Набор всех прецедентов системы определяет способы ее 
использования. Можно сказать, что каждый прецедент описывает действие, которое должна выполнять система. В языке UML прецедент изображается в виде овала 
(рис. 2). Чтобы определить прецеденты системы, можно использовать следующую 
серию вопросов: 
1. Каковы задачи каждого актера? 
 
5

2. Будет ли актер создавать, хранить, изменять, удалять или получать информацию из системы? 
3. Какой прецедент будет создавать, хранить, изменять, удалять или получать 
эту информацию? 
4. Должен ли актер информировать систему о внезапных изменениях внешней среды? 
5. Должен ли актер быть проинформирован об изменениях состояния системы? 
6. Какие прецеденты будут поддерживать и обслуживать систему? 
Поток событий (flow of events) для прецедента – это последовательность событий, необходимых для обеспечения требуемого поведения. Поток событий описывается на языке предметной области (т. е. формулируется, что система должна 
делать), а не в терминах реализации.  
Поток событий должен определять: 
• когда и как прецедент начинается и заканчивается; 
• как он взаимодействует с актером; 
• какие данные ему нужны; 
• какова нормальная последовательность событий для прецедента; 
• каково описание потоков в альтернативных и исключительных ситуациях. 
Документацию на потоки событий обычно составляют в момент проработки 
итеративным способом. Сначала дают только краткое описание необходимых шагов 
для нормального выполнения прецедента. В ходе анализа шаги уточняются. На завершающем этапе в прецедент добавляют потоки для исключительных ситуаций. 
В каждом проекте должен использоваться стандартный шаблон для создания 
документа, описывающего поток событий. Самыми полезными считаются следующие шаблоны: 
X. Поток событий для прецедента <имя прецедента>. 
Х.1. Предусловия. 
Х.2. Главный поток. 
Х.3. Подпотоки (если применимы). 
Х.4. Альтернативные потоки. 
Здесь X – номер прецедента. 
Отношения прецедентов. Связь между актером и прецедентом называют 
коммуникативной ассоциацией (communicate association). Ассоциативная связь может быть либо двухсторонней (от актера к прецеденту и от прецедента к актеру), 
либо односторонней (от актера к прецеденту или от прецедента к актеру). Направление связи показывает, кто является ее инициатором: актер или прецедент. Такой 
тип отношений изображается в виде линии, соединяющей взаимодействующие 
элементы. Направление связи обозначается стрелками на линии связи. 
Существует два типа отношений между прецедентами: включает и дополняет. Различные прецеденты могут иметь одинаково функционирующие фрагменты. Их обычно помещают в отдельный прецедент, чтобы не повторять несколько раз. Отношение включает (include relationship) создается, когда один из 
прецедентов использует другой. Например, каждый прецедент в системе регистрации учебных курсов начинается с аутентификации пользователя. Такие действия можно объединить в один прецедент, который будет применяться другими 
пользователями. 
 
6