Программная инженерия — Методические указания по выполнению всех видов работ

Разработка документов для фаз исследования и анализа проекта

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

1. Глоссарий для значимых элементов предметной области;
2. Описание бизнес-процессов предметной области - словесное + UML-диаграммы деятельности
3. Видение проекта:  бизнес-требования – особенности проекта, обеспечивающие его привлекательность,предполагаемые отличия от аналогов, возможности коммерческого использования,способы монетизации. Границы проекта – перечень бизнес-процессов, поддерживаемых и не поддерживаемых системой. Перечень пользователей проекта
4. Диаграмму классов представления предметной области в программном проекте
5. Диаграмму прецедентов, кратко описать роли и содержание прецедентов, расписать сценарии 2-3 наиболее значимых прецедентов, основываясь на модели предметной области
6. Разработка требований. Определить полный перечень функциональных и нефункциональных требований к системе. На его основе разработать документ «Спецификация требований к ПО»
7. Структуру базы данных серверного приложения
8. Структуру графического интерфейса приложений

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

1.     Шаблон MVC. Сетевая (локальная) игра типа «Морской бой», «домино». Модель хранит структуру данных игры  - расстановку кораблей, и над ней выполняются методы по управлению игрой. Контроллер  определяет порядок ходов, проверяет возможность выполнения хода. Внешнее представление (view) связано с контроллером двунаправленным интерфейсом: контроллер управляет отображением элементов игрового поля, выводит текстовые сообщения, получает от представления события – клик по элементу поля, начало новой игры, завершение и т.п.. Варианты игры:

   o   Локальная: одна модель, один контроллер, два представления для игроков

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

   2.      Шаблон MVC (классический). Представление имеет ряд текстовых полей, отображающих параметры модели физического объекта. На каждый параметр представление отдельно подписывается к модели на событие, связанное с его изменением. Интерфейс подписки идентичен для всех параметров. Для каждого параметра создается оригинальный контроллер, обрабатывающий команду изменения значения параметра со стороны представления. Модель описывается набором зависимостей, параметры которой могут быть входными, выходными (результатами) и выходными с возможностью задания начальных значений (инициализацией).

   3.      Шаблон – прототип. Класс таблицы с произвольной структурой столбцов. Хранимые данные разных типов - целые, вещественные, дата, время, GPS-координаты создаются на основе абстракции данных с функционалом: имя класса, парсинг из сроки и вывод в строку, клонирование, сравнение  и сложение с объектом того же типа. Строка таблицы определяется набором объектов-прототипов для столбцов. Сама строка также клонируется. Таблица состоит из вектора строк-имен, строки-прототипа и строк самой таблицы. Функционал:  создание таблицы, добавление столбцов, добавление строк, сортировка по столбцу с заданным номером, сложение строк, сохранение и загрузка из файла. Программный и интерфейс и оконное приложение. Тестирование на больших данных  - импорт из Excel, генерация тестовых таблиц.

   4.      Шаблон – приспособленец. Работа с деревом версий текстового файла. Файл редактируется по словам. Класс словаря содержит хэш-таблицу адаптеров  со ссылками на оригинальные слова в виде ключ – само слово. Адаптер содержит количество ссылок на слово из всех версий текста. Каждая версия текста – вектор ссылок на адаптеры. При добавлении или вставке слова в версию текста оно ищется в фабрике, при нахождении счетчик в адаптере увеличивается на 1. Иначе добавляется в словарь с новым адаптером. При удалении счетчик ссылок уменьшается. Изменение слова рассматривается как последовательность операций удаления и вставки. Вся структура данных сериализуется в файл. Протестировать шаблон на сказке Репка.

   5.      Шаблон – композиция для древовидной системы. Графический редактор с группировкой/разгруппировкой элементов, изменением размеров и порядка отображения  - перенос на передний/задний план, перетаскиванием объектов, сохранением картинки в файл. Абстрактный класс элемента, группы элементов и конкретных графических объектов  - окружность, полигон, строка текста. Ограничивающий прямоугольник, селекция выбора объектов по  точке и прямоугольнику.

   6.      Шаблон Command. Группа команд обработки объекта с общим интерфейсом Do/ReDo/UnDo. Производный класс запоминает параметры, необходимые для выполнения прямой и обратной команды. Класс – менеджер команд поддерживает очередь команд ограниченной длины, текущий обрабатываемый объект, методы Do/ReDo/UnDo, выбирая их из очереди и вызывая соответствующие методы в объектах-командах. Графический редактор набором  команд редактирования графических объектов - создать объект, переместить, изменить размер, удалить, переместить на передний и задний план.

   7.      Шаблон – пул потоков. Класс потока представляет собой поток, запускаемый при создании объекта. Содержит ссылку на исполняемый код через Runnable, код завершения и ссылку на менеджер пула. Код потока содержит цикл, в котором засыпает, после пробуждения выполняет исполняемый код и уведомляет менеджер о своем завершении и засыпает. Менеджер потоков содержит вектор таких потоков. При обращении к менеджеру с запросом, содержащим код исполнения и  код завершения, выбирается поток из пула, заполняется данными и пробуждается. Если свободного потока нет, то запрос ставится в очередь. Провести сравнительное тестирование для потока запросов с пулом и при запуске потоков обычным образом.

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

   9.      Шаблон – сессия для соединения на сокетах в виде библиотеки для клиента/сервера. Клиент и сервер используют синхронный обмен запрос-ответ. При первоначальном установлении соединения клиент получает уникальный идентификатор, сервер создает дескриптор соединения. Клиент нумерует передаваемые сообщения, сервер сохраняет номер и ответ на последнее переданное сообщение. Сервер периодически или после каждого изменения сохраняет дескрипторы в файл. Клиент также запоминает в файле идентификатор сессии, номер и само последнее переданное сообщение. Обеспечить сохранность последовательности (отсутствие пропадания и дублирования) сообщений при перезагрузке клиента и сервера. Реализовать модель банкомата и платежной системы.

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

   11.  Шаблон – кэш объектов. Разработать класс - кэш объектов с возможностью изменения размера кэша, сбора статистики и применения различных стратегий вытеснения (FIFO, LRU, RAND).  Использовать для кэширования слов текстового файла при последовательном чтении. Кэш – хеш-таблица с ключом-словом и необходимыми параметрами для моделирования, например, номер последнего обращения для LRU. При чтении очередного слова проверяется его наличие в кэше. При отсутствии производится замещение. Для выбранного файла строится зависимость доли попадания в кэш в зависимости от размера кэша и способа вытеснения. Сравнить результаты для файлов с разным содержимым -  художественное произведение, технический текст.

   12.  Шаблон – итератор. Операции над итератором:  установка на первый, последний, следующий, предыдущий, по логическому номеру, извлечение через  итератор, вставка на позицию итератора, замещение, удаление. Структура данных: двухуровневый массив ссылок (двумерный массив), двоичное дерево, дерево с данными в конечных вершинах, список с массивом ссылок [3-2]. Использование нескольких итераторов. Замечание по теме: для корректной реализации операции удаления в основном классе использовать вектор созданных итераторов. При удалении одним из них элемента остальные, которые на него ссылаются, генерируют исключение при очередном обращении. Рассмотреть другие варианты корректного разделения.

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

   13.  Класс буферизованного ввода в реальном времени. При конструировании получает параметр – физический поток данных с интерфейсом InputStream. Использует внутренний циклический буфер или односвязный список блоков, содержащих массив байтов фиксированной размерности (буферный пул). Создает поток, который читает байты из входного потока и записывает в циклический буфер. При заполнении циклического буфера засыпает. Метод чтения извлекает из циклического буфера очередной байт, возвращает -1 при окончании данных в потоке-источнике, блокируется при отсутствии данных в циклическом буфере.

   14.  Класс – PipedStream с циклическим буфером данных. Класс PipedOutputStream имеет циклический буфер, в который пишет поток байтов, блокируя текущий поток при заполнении буфера. Класс PipeInputStream получает ссылку на PipedOutputStream и при чтении данных либо блокируется при их отсутствии, либо извлекает данные, деблокируя поток записи.

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

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

1. Taxi. Анализ требований - описание модели предметной области и свойств бизнес-объектов, отдельных компонент архитектуры и алгоритмов для системы упрвления такси (таксопарки). Можно рассматривать как аналитическую предпроектную проработку предметной области.
2. Пример ТЗ. Разработка мобильных версий органайзера TimeMaster - техническое задание для проекта, отдавыавемого на врешнуюю разработку (аутсорсинг). Содержит полностью прописанные сценарии, подробное описание структуры БД, полное описание структуры графического интерфейса
3. Система выдачи ключей аудиторий - набор проектных документов по описанию бизнес-процессов, моделированию предметной области, анализу требований, разработке архитектуры, анализу и проектированию
4. Система учета рейтинга - набор проектных документов по описанию бизнес-процессов, моделированию предметной области, анализу требований, разработке архитектуры, анализу и проектированию, управлению программныим проектами (оценка трудоемкости и стоимости).  Составлен задним числом для разработанной системы.

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