Федеральное агентство по образованию РФ

Нижегородский государственный университет им. Н.И. Лобачевского

Факультет Вычислительной математики и кибернетики

Кафедра Математического обеспечения ЭВМ

ПРОГРАММА ЛАБОРАТОРНОГО ПРАКТИКУМА ПО КУРСУ

«Технологии программирования.
Курс на базе Microsoft Solutions Framework (MSF)»

для подготовки по направлению «Информационные технологии»

Курс 2

Семестр 4

Лекции 16 часов

Лаб. работы 16 часов

Зачет 4 семестр

Нижний Новгород, 2006

ЦЕЛИ И ЗАДАЧИ ЛАБОРАТОРНОГО ПРАКТИКУМА

Цель данного лабораторного практикума состоит в практическом знакомстве с процессом командной разработки программного обеспечения на примере Microsoft Solutions Framework (MSF).

В процессе выполнения лабораторного практикума предполагается решение следующих задач:

• 
  начальное освоение унифицированного языка моделирования UML;
  
• 
  получение практического опыта работы в команде из 5-7 человек;
  
• 
  освоение методологии Microsoft Solutions Framework for Agile Software Development в процессе командной разработки учебной программной системы.
  

ХАРАКТЕРИСТИКА ПРАКТИКУМА

Лабораторный практикум предполагает разбиение группы студентов на команды по 5-7 человек, распределение ролей в каждой команде в соответствии с положениями методологии Microsoft Solutions Framework for Agile Software Development и прохождение каждой командой всех фаз процесса разработки.

Практикум состоит из двух разделов.

В первом разделе (практики 1, 2, 3) повторяются принципы объектного подхода и важные аспекты повторного использования, а также демонстрируется применение унифицированного языка моделирования UML для визуализации проектирования примеров из читаемого параллельно курса CS103 “Алгоритмы и структуры данных”. Здесь же происходит разбиение студентов на команды и формулировка задач.

Во втором разделе (практики 4, 5, 6, 7, 8) каждая команда выбирает задачу из списка, предложенного преподавателем, и последовательно проходит через этапы: распределение ролей (в отличие от положений MSF в роли разработчика будут находиться все), выработка концепции и построение видения проекта, планирование, разработка решения, стабилизация и, наконец, внедрение решения.

В процессе разработки преподаватель выступает в роли заказчика. Постановки задач даются студентам в краткой форме. Задача студентов – извлечь из заказчика необходимые сведения.

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

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

СОДЕРЖАНИЕ ПРАКТИКУМА

Практическое занятие №1

Цель занятия: Повтор принципов объектно-ориентированного подхода.

Содержание занятия:

Выполнение объектной декомпозиции на примере задач из курса CS103 “Алгоритмы и структуры данных”. Разбор вариантов проектирования.

Практическое занятие №2

Цель занятия: Знакомство с построением диаграмм вариантов использования.

Содержание занятия:

• 
  Разбиение студентов на команды.
  
• 
  Выделение действующих лиц и создание диаграмм вариантов использования на примере задач из курса CS103 “Алгоритмы и структуры данных”.
  

Практическое занятие №3

Цель занятия: Знакомство с построением диаграмм классов.

Содержание занятия:

• 
  Переход от диаграмм вариантов использования к диаграммам классов. Создание диаграмм классов на примере задач из курса CS103 “Алгоритмы и структуры данных”.
  

• 
  Озвучивание кратких постановок задач.
  

Практическое занятие №4

Цель занятия: Прохождение фазы выработки концепции в каждой команде.

Содержание занятия:

• 
  Распределение задач [Приложение 1] между командами.
  
• 
  Распределение ролей в командах.
  

Каждая команда:

• 
  Формирует видение проекта.
  
• 
  Выделяет и выполняет оценку рисков.
  
• 
  Выявляет и анализирует бизнес-требования.
  
• 
  Определяет структуру проекта.
  
• 
  Разрабатывает концепцию решения.
  

Практическое занятие №5

Цель занятия: Прохождение фазы планирования в каждой команде.

Содержание занятия:

Каждая команда:

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

Практическое занятие №6

Цель занятия: Прохождение фазы разработки в каждой команде.

Содержание занятия:

Каждая команда:

• 
  Создает прототип приложения.
  
• 
  Разрабатывает необходимые компоненты решения.
  

Практическое занятие №7

Цель занятия: Прохождение фазы стабилизации в каждой команде.

Содержание занятия:

Каждая команда:

• 
  Тестирует решение.
  

Практическое занятие №8

Цель занятия: Прохождение фазы внедрения в каждой команде.

Содержание занятия:

Каждая команда:

• 
  Внедряет решение в эксплуатацию в другую команду.
  

ПРИЛОЖЕНИЕ 1. ПОСТАНОВКИ ЗАДАЧ

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

Учебный пример для преподавателей

Система бронирования билетов для авиакомпании

Краткое описание

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

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

Анализ постановки – полное описание

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

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

• 
  Распределенное хранилище рейсов: название рейсов, номера и стоимость билетов.
  
• 
  Покупатель: ФИО, сумма. Покупатель задает параметры, связанные с суммой, которую он хочет потратить. Система должна подобрать оптимальный маршрут. При отсутствии прямых маршрутов система должна попробовать найти маршруты с пересадками. Если таковых не находится, система должна сказать, что с такими ограничениями нельзя добраться до места назначения.
  

Среди причин:

• 
  Отсутствие рейсов в желаемом направлении даже с учетом пересадок.
  
• 
  Нехватка денег.
  

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

• 
  Менеджер рейсов: должен иметь следующие возможности:
  

• 
  создания и удаления аэропортов в системе.
  
• 
  создания и удаления рейсов в аэропортах.
  

Задачи, предлагаемые студентам

Система обработки метеоинформации

Краткое описание

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

Полная постановка задачи

Функционирование системы предполагается на локальном компьютере. Работа в системе должна включать в себя три части:

• 
  редактирование карт;
  
• 
  задание и редактирование движения воздушных масс и циклонов;
  
• 
  демонстрация погодных условий.
  

Для редактирования карт и задания движения воздушных масс предполагается, разработка редактора векторной графики. Изображения могут сроиться как из векторных примитивов: линии, окружности, прямоугольники, – так и из более сложных объектов векторной графики: полигоны, кривые Безье, …

Желательно обеспечить возможность заливки внутренности замкнутых объектов выбранным цветом.

Объекты системы: карта, изображение воздушных масс, подсистема расчета движения воздушных масс, режим просмотра изменения метеоусловий.

Карта, изображение воздушных масс: набор векторных примитивов.

Подсистема расчета движения воздушных масс: в простейшем случае статические формулы. Более сложный случай – имитационная система или решатель систем дифференциальных уравнений.

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

• 
  интегрированное средство просмотра результата;
  
• 
  отдельное приложение просмотра.
  

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

Редактор математических формул

Краткое описание

Фирма «OurResearch» занимается написанием математических программ по заказу. При этом в фирме часто приходится писать отчеты заказчику. При написании отчетов заказчик хочет видеть в отчетах математические формулы в классическом виде.

У Вашей фирмы компания решила заказать удобное средство для перевода и написания математических выражений в разные форматы представления. Причем, если в редакторе присутствует ряд взаимосвязанных формул, то фирма хочет видеть адекватный код. При этом известно, что фирма часто использует C/C++, Pascal и Fortran.

Полная постановка задачи

Необходимо разработать систему для редактирования и написания математических формул.

Объекты системы: формула, формульный редактор.

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

Формульный редактор: визуальная часть. Должен позволять:

• 
  транслировать стандартный синтаксис формул во внутренний формат;
  
• 
  отображать из внутреннего формата в графический вид;
  
• 
  визуально редактировать формулы;
  
• 
  отображать структуру данных формулы.
  

Дополнительно система должна обеспечивать сохранение формул в нескольких форматах (например, в XML).

Редактор должен включать в себя конвертор в различные форматы, к примеру, перевод формулы в стандартное выражение для C/C++, Pascal и Fortran.

Также обязательно нужна возможность перевода формулы в BMP-изображение.

Web-сервис (на основе сокетов)

Краткое описание

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

• 
  входные данные;
  
• 
  выходные данные;
  
• 
  код алгоритмов.
  

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

Полная постановка задачи

Web-сервис должен быть рассчитан на небольшое число пользователей и работу в локальной сети. К web-сервису должен быть реализован разделенный доступ пользователей.

Объекты системы: пользователь, роль, алгоритм, web-сервис.

Пользователи: логин, пароль, роль.

Пользователь может на web-сервисе осуществлять следующие действия:

• 
  размещать алгоритмы;
  
• 
  изымать на редактирование алгоритмы;
  
• 
  удалять алгоритмы с web-сервиса;
  
• 
  исполнять алгоритмы.
  

Роль: представляет собой список пользователей.

Алгоритм: название, код (математическое выражение), принадлежность пользователю, входные и выходные параметры.

Web-сервис предоставляет следующие возможности:

• 
  хранить алгоритмы на сервере;
  
• 
  предоставлять доступ к алгоритмам:
  
  • 
    редактирование;
    
  • 
    удаление;
    
• 
  исполнение алгоритма на сервере.
  

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

Редактировать алгоритм может только пользователь, выложивший алгоритм.

Исполнить алгоритм могут только те пользователи, которым доступна папка с алгоритмом. Исполнение производится через специальный интерфейс.

Система взаимодействия команд

Краткое описание

Руководство фирмы “Effectiveness” пришло к выводу, что производительность труда ее сотрудников не достаточно полно соответствует громкому имени компании. В результате проведенных исследований была выявлена основная причина – недостаточная эффективность обмена информацией между сотрудниками. В качестве решения руководство видит внедрение единого средства электронной коммуникации. Отделу разработчиков компании поручено создать систему, включающую в себя почтовый инструмент и инструмент для обмена мгновенными сообщениями.

Полная постановка задачи

Требуется реализовать комплексную систему обмена сообщениями для небольшого количества пользователей.

Система должна удовлетворять следующим требованиям:

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

Объекты системы: пользователь, сервер, письмо, список контактов, быстрое сообщение, почтовый клиент, клиент для чата.

Пользователь: ФИО, логин, пароль.

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

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

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

Список контактов: список логинов пользователей системы.

Почтовый клиент: включает в себя редактор почты, средства просмотра и отправки почты лицам из списка контактов.

Клиент для чата: содержит список доступных чатов. Предоставляет возможность создания чатов и открытие чата для людей из списка контактов.

Учет работы персонала

Краткое описание

В компании “Justice” были проведены исследования, в результате которых компания поняла, что теряет достаточно много средств из-за не всегда равномерного распределения зарплаты. Кроме денежных потерь есть и недовольство персонала, которое вызвано тем, что те, кто много работают, и те, кто мало, получают одинаковые зарплаты.

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

Полная постановка задачи

Нужно реализовать систему учета работы персонала.

Объекты системы: датчики, хранилища данных, менеджер, работник, система начисления зарплаты, система построения отчетов.

Датчики: считается, что фирма состоит из нескольких филиалов и в каждом филиале есть отдельные наборы датчиков. Каждый набор датчиков сохраняет информацию в свое хранилище данных. Основные данные, с которыми работает система:

• 
  Кто и во сколько пришел.
  
• 
  Кто и во сколько ушел.
  
• 
  Кто когда отбыл в командировку.
  
• 
  Кто и когда вернулся из командировки.
  

Хранилище данных: является распределенным. Предназначение – вести журнал данных, поступающих с датчиков. Доступ к хранилищу могут получать только работники и менеджеры.

В системе должны существовать две роли: работник и менеджер. При этом менеджер также может быть и работником.

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

Менеджер: контролирующая должность. Содержит ФИО, логин, пароль, табельный номер, счет для начисления зарплаты.

Выполняет следующие функции:

• 
  Построение и просмотр отчетности по работникам (через систему построения отчетов).
  
• 
  Премирование выделившихся работников.
  
• 
  Прием и увольнение персонала.
  
• 
  Поднятие и понижение разрядов и определение квалификационной группы.
  
• 
  Установление индексов зарплат для работников.
  
• 
  Контроль за системой начисления зарплаты.
  

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

Система бронирования билетов для авиакомпании

Краткое описание

На рынок вышла новая авиакомпания «GlobalAvia». Менеджеры компании решили заказать у вашей фирмы разработку системы бронирования билетов. При заказе фирма поставила ряд условий, которые обязательно должны быть выполнены. В первой версии системы они хотят видеть две части. В первой требуется заносить необходимую информацию. Со второй частью будут работать покупатели билетов.

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

Полная постановка задачи

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

• 
  Время.
  
• 
  Цена.
  
• 
  Комфорт.
  

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

Объекты системы: распределенное хранилище рейсов, покупатель билетов.

Распределенное хранилище рейсов: название рейсов, номера и тип самолетов, класс самолета по комфорту и стоимость билетов.

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

• 
  Отсутствие рейсов в требуемом направлении даже с пересадками.
  
• 
  Сумма слишком мала.
  
• 
  Комфорт завышен.
  

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

Система управления проектами

Краткая постановка

В компании “SuperSoft” возникла потребность автоматизировать управление проектами. В силу того, что компания существует на рынке разработки ПО недавно и не обладает достаточным количеством свободных финансовых средств, было принято решение не покупать системы управления проектами типа Microsoft Project (стоимость коробочной версии от $600), а разработать собственное простое решение.

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

Полная постановка задачи

Система управления проектами должна быть рассчитана на небольшие команды. В каждом проекте выделяются только две роли: менеджер и исполнитель.

Менеджер может управлять несколькими проектами, исполнитель участвует только в одном проекте.

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

Исполнитель получает от менеджера задачи, на основании которых для него формируется “ToDo-List”. Список может пополняться по ходу проекта, как менеджером, так и самим исполнителем.

Объекты системы: менеджер, исполнитель, задача, проект, “ToDo-List”.

Менеджер: ФИО, проект(ы).

Исполнитель: ФИО, проект, “ToDo-List”.

Задача: имя, формулировка, срок начала, срок окончания (выставленный менеджером), срок фактического окончания (когда исполнитель “сдал” задачу менеджеру, а тот ее “принял”), состояние (не начата, выполняется, завершена, отложена), причина изменения срока окончания/откладывания.

Проект: имя, менеджер, исполнители, задачи.

“ToDo-List”: список задач для исполнителя. Часть списка формируется автоматически, доступна только для чтения. Часть формируется исполнителем “для себя”, доступна для редактирования.

Сроки для задач могут задаваться с точностью до часов (начало: 21 июля 14.00, окончание: 21 июля 16.00, фактического окончание: 21 июля 17 часов, причина изменения сроков: учения по пожарной безопасности).

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

По данным каждого проекта в системе должна быть возможность поиска.

Система контроля и распределения ресурсов

Краткое описание

Организация “Presentation for you” профессионально занимается подготовкой и проведением презентаций для фирм. В фирме за последние несколько кварталов сильно увеличился объем заказов. В результате постоянно стали наблюдаться ситуации, когда презентации задерживались из-за нехватки каких-либо ресурсов (аудиторий, проекторов, досок).

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

Полная постановка задачи

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

Объекты системы: сервер, ресурс, расписание использования ресурса, пользователь, администратор, менеджер ресурсов, клиент.

Сервер: Обладает следующей функциональностью:

• 
  Хранит информацию обо всех ресурсах и пользователях.
  
• 
  Позволяет управлять пользовательскими записями:
  
  • 
    Добавлять.
    
  • 
    Удалять.
    
  • 
    Назначать уровень доступа.
    
• 
  Разделяет уровень доступа для различных пользователей на основе ролевых кластеров:
  
  • 
    Администратор.
    
  • 
    Менеджер.
    
  • 
    Пользователь.
    
• 
  Выдает информацию о ресурсах в соответствии с уровнем доступа.
  

Ресурс: название, серийный номер (номер аудитории, номер доски), расписание использования ресурса.

Расписание использования ресурсов: порождается для каждого ресурса. Включается записи о времени занятости и цели использования.

Пользователь: ФИО, логин, пароль, информация о дополнительных ролях. Дополнительных ролей две:

• 
  Администратор.
  
• 
  Менеджер ресурсов.
  

У пользователя должны быть следующие функции:

• 
  Запрос на занятие ресурса на определенное время с указанной целью.
  
• 
  Различные виды просмотров занятости ресурсов.
  
  • 
    Конкретного ресурса.
    
  • 
    Группы ресурсов.
    

Администратор: Выполняет функции менеджера пользователей. Не может управлять ресурсами.

Менеджер ресурсов: Основные функции:

• 
  Добавление и удаление ресурсов.
  
• 
  Подтверждение или отклонение запросов на занятие ресурсов.
  

Клиент: Должен быть реализован в виде web-сайта и Windows приложения.