Технологии программирования на базе Microsoft Solutions Framework

       

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


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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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




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

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

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

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

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

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

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

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

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

  • исполнение алгоритма на сервере.

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

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

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






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

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

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

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

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

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

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

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

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

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

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




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

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

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

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

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

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

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

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

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

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

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




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

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

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

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

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

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

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

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




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

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

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

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

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

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

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

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

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

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

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

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

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




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

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

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

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

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

  • Выдает информацию о ресурсах в соответствии с уровнем доступа.

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

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

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

Дополнительных ролей две:

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

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

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

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

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

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

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



Содержание раздела