Методические указания практика


Практика по дисциплине «Технологии программирования»

Задания на практические занятия

Практическая часть

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

Методологической основой разработки является унифицированный процесс RUP. Каждое практическое занятие посвящено определенным фазам и основным потокам работ.

Будут разработаны следующие диаграммы:

вид с точки зрения функциональности – диаграммы прецедентов;

вид с точки зрения проектирования – диаграммы классов (для структурного моделирования) и диаграммы взаимодействия (для моделирования поведения).

Основная литература

Вигерс Карл Разработка требований к программному обеспечению/Пер. с англ. — М.: Издательство-торговый дом «Русская Редакция», 2004. — 576с.

Практическое занятие 1. Спецификация требований и создание вариантов использования

Цель

Уяснить принципы документирования требований к ПО.

Глава 10. Документирование требований

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

Исходные данные

Учебный центр Program System проводит обучение по официальным программам всемирно известной компании Macro. На начальном этапе своего развития учебный центр начинался с небольшой группы собравшихся вместе преподавателей. В то время компания Macro еще не доминировала на мировом рынке ПО, объем программ обучения был не велик и с ним успешно справлялся коллектив учебного центра. С ростом известности и компании Macro и репутации учебного центра, объем заявок на обучение возрастал. Когда поступало мало заявок, менеджер центра использовал для их учета бумажный журнал, а в случае крайней необходимости простые электронные таблицы Excel.

Проблемы

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

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

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

Решение проблемы

Разработка системы, которая поможет автоматизировать процесс обработки заявок клиентов.

Описание процесса регистрации клиентов на обучение

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

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

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

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

Администратор (лаборант) обеспечивает подготовку учебных классов для проведения курса.

Администратор центра тестирования организует работу центра для приема сертифицированных экзаменов.

Руководитель центра обучения организует работу всего центра.

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

Реализация начальной фазы

На основе исходных данных (пожелания и требования заказчика по функционированию системы) требуется:

Сформировать концепцию – образ проекта в целом.

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

Составить план, в котором отразить основные опорные точки процесса разработки.

Определить основную функциональность, которую должна предоставлять система.

На основе функциональных требований создать модель прецедентов (вариантов использования).

Рекомендации по разработке:

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

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

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

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

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

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

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

Отчетность

Отчет должен содержать:

описание исходных данных проекта;

план разработки системы;

спецификация требований к ПО согласно шаблона (Глава 10. Вигерс Карл Разработка требований к программному обеспечению)



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

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

выводы;

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

Практическое занятие 2. Разработка диаграммы взаимодействия

Цель

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

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

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

Рекомендации по разработке

Диаграмма взаимодействий акцентирует внимание на временной упорядоченности сообщений. Графически такая диаграмма представляет собой таблицу, объекты в которой располагаются вдоль оси X, а сообщения в порядке возрастания времени – вдоль оси Y.

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

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

Класс описывает группу объектов с общими свойствами (атрибутами), общим поведением (операциями), общими связями с другими объектами и общей семантикой (шаблон для создания объекта).

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

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

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

Второе измерение диаграммы последовательности – вертикальная временная ось, направленная сверху вниз. Начальному моменту времени соответствует самая верхняя часть диаграммы. При этом взаимодействия объектов реализуются посредством сообщений, которые посылаются одними объектами другим.

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

Крайним слева на диаграмме изображается объект, который является инициатором взаимодействия

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

Отчетность

Отчет должен содержать:

диаграммы взаимодействия, соответствующие потокам событий вариантов использования с соответствующими пояснениями;

выводы.

Практическое занятие 3. Реализация иерархии классов

Цель

Разработать диаграмму классов и программно реализовать иерархию классов.

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

Работа состоит из двух частей.

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

Обратите особое внимание на отношения между классами, подпишите тип отношения (является, содержит или реализует) над каждой стрелкой на диаграмме.

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

Во второй части работы требуется реализовать диаграмму классов на языке C#. Протестировать работу классов.

Рекомендации по разработке

Для декомпозиции системы на классы следует выделить следующие три стереотипа классов: граничные классы, управляющие классы (контроллеры) и классы-сущности, которые образуют концепцию «модель-представление-контроллер» (MVC) и позволяют отделить представление от предметной области и управления.

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

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

Управляющие классы отражают поведение одного или нескольких прецедентов использования и отвечают за поток сообщений в прецеденте использования. Эти классы зависят от конкретного приложения.

Отчетность

Отчет должен содержать:

диаграммы классов;

код, реализующий иерархию классов;

выводы.

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




Предыдущий:

Следующий: