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

Оглавление / Contents

  • "Программная инженерия". Варианты заданий и перечень лабораторных работ.
  • "Программная инженерия". Контрольная работа
  • Расчетно-графическое задание
  • Образцы документов, связанных с проектированием
  • "Инжиниринг ПО". Описания и варианты заданий к лаб.работам
  • "Управление программными проектами". Коллективный проект

Программная инженерия

 

 Балл
Л.р.1. Бизнес-анализ предметной области, разработка видения. Моделирование предметной области. Системная аналитика15
Л.р.2. Разработка модели прецедентов5
Л.р.3. Разработка требований10
Л.р.4. Разработка прототипа графического интерфейса10
РГР. Шаблоны проектирования20

 

Лабораторный практикум

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

Варианты заданий

  1. Система продажи билетов в кинотеатре. Клиент, кассир, смена, билетер, администратор, планирование сеансов, продажа билетов кассиром, бронирование и продажа через Интернет, финансовые отчеты, план зала.
  2. Система продажи театральных билетов. Приложение кассира  - множество точек продажи, приложение распространителя, бронирование через Интернет, связь с платежными системами, план зала (мета-уровень описания), спектали, репертуар.
  3. Система автоматизации диспетчерской службы такси.  Диспетчер, водитель, клиент, директор, прием заказов, ведение очередей, ручное распределение заказов, приложение водителя, мониторинг прохождения заказа.
  4. Система автоматизированного заказа такси через Интернет. Серверное приложение для автоматического распределения заказов с учетом нагрузки, web-приложение и мобильное приложение для клиентов, приложение водителя, приложение администратора для форсмажорных и конфликтных ситуаций. Автоматическое распределение заказов на основе расстояния для клиента и других критериев, предложение свободных заказов водителю, голосование за заказ, мониторинг прохождения заказа. Виды адресов с привязкой к GPS-координатам: почтовый, место, корпоративный (фирма, организация).
  5. Система ведения корпоративной адресной базы для мобильных клиентов. Типы адресов: служебный - подразделение, корпус, кабинет, домашний - почтовый. Типы контактов: электронная почта, телефон, социальная сеть, адрес. Административная структура организации. Хранение списка контактов, обмен контактами, иерархическая многомерная адресная книга с каталогами (тегами), общая и личная адресные книги.  
  6. Мессенжер мобильных клиентов аналогичный WhatsUp. Регистрация по номеру мобильного телефона. Передача сообщений, файлов, синхронизация адресных книг, иерархическая многомерная адресная книга с каталогами (тегами), поиск по общей адресной книге, личная адресная книга с собственной системой каталогов (тегов)
  7. Мессенжер с прямой связью клиентов. Сервер контактов, регистрация, сохранение IP-адресов клиента и статистики пребывания, авторизация с сообщением текущего IP-адреса, дозвон по списку IP-адресов, прямая связь с передачей сообщений и файлов, локальные адресные книги, обмен адресами.
  8. Система заказных грузоперевозок по городу. Клиент, диспетчер, магазин, водитель. Прием и оформление заказов, отчеты и сопроводительные документы, распределение заказов диспетчером. Два вида заказов: точка-точка и развоз товаров со склада по клиентам. Приложение водителя: просмотр заказа, мониторинг проведения заказа – развоза, планирование последовательности, времени доставки. Приложение диспетчера: прием и оформление заказа, распределение, планирование доставки. Параметры заказа – вес и габариты грузов. Транспортные средства и водители. Оплата доставки авансом и при выполнении заказа.
  9. Система продажи билетов на междугородные автобусы. Планирование рейсов, расписание, чартерные рейсы, типы автобусов, планы рассадки, водители, кассиры, смены, визуализация рассадки, приобретение билетов в кассе и в кассовых терминалах, бронирование через Интернет, сводные отчеты по маршруту, дате. 
  10. Система мониторинга междугородных автобусных перевозок. Карта автодорог, маршрут, график движения по маршруту, планирование рейсов, GPS-навигация транспортных средств, отслеживание графика движения по маршруту, обработка аварийных ситуаций.
  11. Система планирования междугородных транспортных перевозок. Транспортные средства  - тип, тоннаж, вместимость. Населенные пункты, дорожная сеть, прием заявок, поиск подходящего транспорта с учетом его местонахождения и порожнего прогона, составление маршрута, оформление и проводка заявок, отчеты по периоду времени, транспортному средству, водителю.
  12. Система мониторинга междугородных транспортных перевозок Населенные пункты, дорожная сеть, маршрут, планирование движения по маршруту, GPS-навигация транспортных средств, отслеживание графика движения по маршруту, обработка аварийных ситуаций, отслеживание заправки, отчеты по расходу топлива и рабочему времени водителей.
  13. Справочная система наличия товаров. Многоуровневая система категорий и марок товара. Мета-система классификационных признаков и их значений, например, вес, цвет, производитель, объем памяти, наличие GPS и т.п.. Торговые сети, торговые точки с привязкой к GPS-координат. Ассортимент в торговой точке, количество товара. Приложение пользователя: поиск по местоположению, по условиям, сформированным для признаков. Приложение торговой точки – редактирование ассортимента. Приложение администратора – редактирование категорий и марок, классификационных признаков.
  14. Логистическая система интернет-магазина с пунктами выдачи и доставкой по городу. Прием заказов, оформление заявок поставщикам, уведомление клиентов, отслеживание работы курьеров, отчеты по пунктам выдачи. Многоуровневая система категорий и марок товара. Мета-система классификационных признаков и их значений, например, вес, цвет, производитель, объем памяти, наличие GPS и т.п.. Наличие товара на складе. Отслеживание балансов по каждому виду товара: заказано, наличие на складе, в заявках к поставщикам. Принятие товара на складе, формирование комплектов заказов для пунктов выдачи и курьеров. 
  15. Система электронного документооборота учебного процесса в ВУЗе. Структура учебного заведения, факультеты, кафедры, группы, студенты, преподаватели. Сторонние организации. Приказы о зачислении/отчислении, назначении тем ВКРБ,  распределение на практику, распоряжения по подразделениям. Прохождение приказа: создание,  визирование, утверждение, нумерация, рассылка.
  16. Система книговыдачи школьной библиотеки с использованием QR-кодов. Систематический и алфавитный каталог книг с учетом экземпляров, рекомендованные учебники по предметам, структура учебного процесса: класс, ученик, предметы, преподаватели, сторонние лица. Формирование комплектов учебников, выдача литературы на абонемент. QR-коды читательских билетов, экземпляров книг, выдача и прием, ведение формуляра с историей, уведомление о просрочках.
  17. Система книговыдачи библиотеки с использованием QR-кодов. Алфавитный каталог книг с учетом экземпляров, многомерный иерархический тематический каталог или система тегов. Выдача литературы на абонемент. QR-коды читательских билетов, экземпляров книг, ведение формуляра с историей, уведомление о просрочках. Ведение очередей на дефицитные книги - артефакты, уведомления об очередности.
  18. Система управления кафе/баром. План зала, закрепление официантов за столиками, планирование смен. Меню – категории, позиции, описание, привязка к кухне или бару. Проведение заказа: закрепление столика за официантом, выбор по меню, частичный заказ, заявки в бар и на кухню, повторение заказа, итоговый расчет. Приложение посетителя, официанта, бармена – планшет, администратора – desktop.
  19. Система бронирования мест для клубных мероприятий. План концертов. Анонсы. Стоимость столиков. План зала - мета-уровень описания, настройка под конкретный клуб. Билеты – столики, танцпол. Электронная предоплата. Бронирование. Приложение кассира. Мобильное приложение клиента.
  20. Система бронирования мест в гостинице. Мета-уровень описания конкретной гостиницы – расположение и типы номеров, поэтажные планы, список услуг, фото общие и отдельных номеров, расценки. Бронирование через интернет, визуализация свободных/занятых, расчет стоимости, квитанции, отчеты по периодам. Бронирование индивидуальное и групповое. Балансы по занятым, свободным и забронированным номерам по датам и категориям. Заселение, продление проживание, дополнительные услуги, частичный и итоговый расчет.
  21. Система планирования взаимосвязанных работ. Учет сотрудников и их занятости запланированными работами. Определение работ в виде цепочек заданий с параллельными ветвями. Распределение заданий по работникам с учетом их занятости. Сдвиг сроков зависимых работ при задержке выполнения одной из них. Приложения сотрудника, руководителя подразделения, генерация отчетов.
  22. Система мониторинга обслуживания по заявкам. Система с предварительным сбором заявок и обслуживанием. Категории и виды работ, исполнители, квалификация по категориям и видам. Прием заявок, планирование исполнения, распределение по исполнителям. Оперативное планирование времени исполнения заявок, отслеживание времени исполнения, коррекция времени при задержках с уведомлением клиентов, отказы. Мобильный клиент сотрудника, приложение диспетчера.
  23. Система поддержки технологии SCRUM для удаленной работы. Поддержка основных элементов технологии SCRUM - исполнители (команда), лидер, собственник проекта, истории пользователей (задачи), спринты, беклоги, мониторинг исполнения задач, диаграммы сгорания. Митинги, покер-планирование  в режиме чата.
  24. Система многомерной организации документов. В качестве  документов могут выступать короткие заметки (записи в БД), файлы документов, изображений, звуковых. Поддерживается дерево редактирования версий файла. Создается произвольное количество систем классификаций (каталогов ссылок на файлы) по набору ключевых параметров, например, изображения могут классифицироваться по размеру, цветовой палитре, содержанию, наличию определенных предметов, звуковые файлы по исполнителю, стилю, наличию муз. инструментов.

Лабораторная работа 1. Бизнес-анализ предметной области, разработка видения. Моделирование предметной области. Системная аналитика.  Для выбранного варианта разработать документы фазы исследования проекта. Содержание документа «Видение проекта»:

·         глоссарий для значимых элементов предметной области;

·         бизнес-требования;

·         границы проекта;

·         перечень заинтересованных лиц, пользователей проекта  и приложений;

  1. Документ – описание бизнес процессов предметной области.

·         словесное описание бизнес-процессов предметной области;

·         формальное описание отдельного бизнес-процесса в виде диаграммы потоков данных, диаграммы деятельности или средствами ;

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

·         диаграмма классов предметной области

·         диаграммы состояний для сущностей, имеющих «историю» в системе

Лабораторная работа 2. Разработка модели прецедентов. Разработать полную модель прецедентов, кратко описать роли и содержание прецедентов, расписать сценарии 2-3 наиболее значимых прецедентов, основываясь на модели предметной области.

Лабораторная работа 3. Разработка требований. Определить полный перечень функциональных и нефункциональных требований к системе. На его основе разработать документ «Спецификация требований к ПО».

Лабораторная работа 4. Разработка прототипа графического интерфейса. Для всех приложений с учетом их функционала и имеющихся прецедентов разработать систему окон графического интерфейса пользователя (GUI), диаграмму оконных классов или граф связей. Обосновать принятые решения требованиями из «Спецификации требований к ПО». Дополнить спецификацию с учетом выполненного проектирования.

 

 

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

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

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

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

РГР выполняется индивидуально в виде разработки одного из  шаблонов проектирования. Пояснительная записка должна содержать:

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

Все сторонние материалы должны быть снабжены корректно оформленными библиографическими ссылками.

   Варианты заданий

  1. Шаблон – прототип. Класс таблицы с произвольной структурой столбцов. Хранимые данные разных типов - целые, вещественные, дата, время, GPS-координаты создаются на основе абстракции данных с функционалом: имя класса, парсинг из сроки и вывод в строку, клонирование, сравнение и сложение с объектом того же типа. Строка таблицы определяется набором объектов-прототипов для столбцов. Сама строка также клонируется. Таблица состоит из вектора строк-имен, строки-прототипа и строк самой таблицы. Функционал:  создание таблицы, добавление столбцов, добавление строк, сортировка по столбцу с заданным номером, сложение строк, сохранение и загрузка из файла. Интерфейс командной строки (по желанию – оконное приложение). Тестирование на больших данных - импорт из Excel, генерация тестовых таблиц.
  2. Шаблон – Flyweight (приспособленец). Работа с деревом версий текстового файла. Файл редактируется по словам. Класс словаря содержит хэш-таблицу адаптеров  со ссылками на оригинальные слова в виде ключ – само слово. Адаптер содержит количество ссылок на слово из всех версий текста. Каждая версия текста – вектор ссылок на адаптеры. При добавлении или вставке слова в версию текста оно ищется в фабрике, при нахождении счетчик в адаптере увеличивается на 1. Иначе добавляется в словарь с новым адаптером. При удалении счетчик ссылок уменьшается. Изменение слова рассматривается как последовательность операций удаления и вставки. Вся структура данных сериализуется в файл. Протестировать шаблон на сказке Репка.
  3. Шаблон – Flyweight (приспособленец). Коллекция переменных с сохранением измененных значений. Объект «переменная» содержит имя, значение, время изменения, количество ссылок. Метод get(имя переменной) возвращает ссылку «адаптер-приспособленец», который, в свою очередь, ссылается на переменную с самым последним значением и увеличивает в ней счетчик ссылок. При отсутствии переменной  - создает ее. Метод release для приспособленца уменьшает счетчик ссылок в переменной и удаляет ссылку на нее в приспособленце. Метод put(значение) для адаптера-приспособленца обновляет значение переменной при счетчике ссылок, равном 1, иначе – создает новый экземпляр для приспособленца, устанавливает ссылку на нее, уменьшает счетчик ссылок в старом экземпляре.
  4. Шаблон – композиция для древовидной системы. Графический редактор с группировкой/разгруппировкой элементов, изменением размеров и порядка отображения  - перенос на передний/задний план, перемещение объектов, сохранением картинки в файл. Абстрактный класс элемента, группы элементов и конкретных графических объектов  - окружность, полигон, строка текста. Ограничивающий прямоугольник, селекция выбора объектов по  точке и прямоугольнику. Интерфейс командной строки с визуализацией в окно результата редактирования (по желанию – оконное приложение).
  5. Шаблон Command. Группа команд обработки объекта с общим интерфейсом Do/ReDo/UnDo. Производный класс запоминает параметры, необходимые для выполнения прямой и обратной команды. Класс – менеджер команд поддерживает очередь команд ограниченной длины, текущий обрабатываемый объект, методыDo/ReDo/UnDo, выбирая их из очереди и вызывая соответствующие методы в объектах-командах. Графический редактор набором  команд редактирования графических объектов - создать объект, переместить, изменить размер, удалить, переместить на передний и задний план. . Интерфейс командной строки с визуализацией в окно результата редактирования (по желанию – оконное приложение).
  6. Шаблон Command (15 баллов). Имеется для выполнения операции над строкой: добавить символ, удалить символ с позиции n, вставить символ позицию n, заменить символ на позиции n, аналогично для группы символов. Реализовать команды unDo/reDo путем создания очереди команд отката, содержащих «симметричные» команды при выполнении указанных. Например, для команды «удалить с позиции 10» симметричной является «вставить удаляемый символ на позицию 10».
  7. Шаблон – пул потоков. Класс потока представляет собой поток, запускаемый при создании объекта. Содержит ссылку на исполняемый код через Runnable, код завершения и ссылку на менеджер пула. Код потока содержит цикл, в котором засыпает, после пробуждения выполняет исполняемый код и уведомляет менеджер о своем завершении и засыпает. Менеджер потоков содержит вектор таких потоков. При обращении к менеджеру с запросом, содержащим код исполнения и  код завершения, выбирается поток из пула, заполняется данными и пробуждается. Если свободного потока нет, то запрос ставится в очередь. Провести сравнительное тестирование для потока запросов с пулом и при запуске потоков обычным образом.
  8. Шаблон – прокси (фильтр). Класс с интерфейсом текстового потока при конструировании делегируется к однотипному объекту источнику и отфильтровывает набор слов, передаваемый при конструировании, используется внутренняя очередь символов для отложенного распознавания. Протестировать на цепочке фильтров для разных наборов слов. Реализовать метод посимвольного чтения.
  9. Шаблон – сессия для соединения на сокетах в виде библиотеки для клиента/сервера. Клиент и сервер используют синхронный обмен запрос-ответ. При первоначальном установлении соединения клиент получает уникальный идентификатор, сервер создает дескриптор соединения. Клиент нумерует передаваемые сообщения, сервер сохраняет номер и ответ на последнее переданное сообщение. Сервер периодически или после каждого изменения сохраняет дескрипторы в файл. Клиент также запоминает в файле идентификатор сессии, номер и само последнее переданное сообщение. Обеспечить сохранность последовательности (отсутствие пропадания и дублирования) сообщений при перезагрузке клиента и сервера. Реализовать модель банкомата и платежной системы.
  10. Модель параллельных запросов к серверу от группы потоков. Множество потоков может посылать независимые запросы к серверу через единственное соединение. Запрос ставится в очередь, нумеруется, клиентский процесс засыпает. Поток передачи от клиента выбирает сообщения из очереди и передает в соединение. Поток приема на сервере, приняв очередное сообщение, запускает поток исполнения запроса, по завершении которого в очередь ответов ставится ответ, в котором сохраняется порядковый номер запроса. Поток передачи ответов на сервере выбирает сообщения из очереди и передает в соединение. Поток приема ответов определяет по номеру в сообщении поток, передавший запрос и пробуждает его. Ответное сообщение находится в запросе, переданном потоком, и выводится им. Промоделировать группу потоков, посылающих случайные слова, которые сервер переворачивает со случайной задержкой.
  11. Шаблон – кэш объектов. Разработать класс - кэш объектов с возможностью изменения размера кэша, сбора статистики и применения различных стратегий вытеснения (FIFO, LRU, RAND).  Использовать для кэширования слов текстового файла при последовательном чтении. Кэш – хеш-таблица с ключом-словом и необходимыми параметрами для моделирования, например, номер последнего обращения для LRU. При чтении очередного слова проверяется его наличие в кэше. При отсутствии производится замещение. Для выбранного файла строится зависимость доли попадания в кэш в зависимости от размера кэша и способа вытеснения. Сравнить результаты для файлов с разным содержимым -  художественное произведение, технический текст.
  12. Шаблон – итератор. Операции над итератором: установка на первый, последний, следующий, предыдущий, по логическому номеру, извлечение через  итератор, вставка на позицию итератора, замещение, удаление. Структура данных: двухуровневый массив ссылок (двумерный массив), двоичное дерево, дерево с данными в конечных вершинах, список с массивом ссылок [3-2]. Использование нескольких итераторов. Замечание по темедля корректной реализации операции удаления в основном классе использовать вектор созданных итераторов. При удалении одним из них элемента остальные, которые на него ссылаются, генерируют исключение при очередном обращении. Рассмотреть другие варианты корректного разделения.

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

 

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

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

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

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

17. Шаблон Two-phase Termination. Класс-поток при запуске выполняет цикл с рандомной задержкой 2-10 сек. При старте получает CallBack для для уведомления о собственном завершении. Имеется метод shutDown инициализации процесса завершения. Основной поток запускает N указанных потоков, ждет 20 сек и вызывает для всех метод shutDown. Через CallBack дожидается, когда все завершатся. Устанавливает таймер, если по истечении тайм-аута потоки не уведомляют о завершении, «убивает» их.

18. Шаблон Scheduler с блокировкой потоков до окончания запланированного действия. Имеет собственный поток и ArrayList запросов (объектов с присоединенным Runnable). Метод runMeInQueue получает этот объект, пробуждает поток планировщика, помещает объект в ArrayList и блокирует поток, (wait на объекте выполнения). Цикл потока планировщика удаляет объект из  ArrayList, выполняет в нем run и пробуждает спящий на нем поток. При пустом ArrayList засыпает. Создать 10 потоков с обращением к планировщику и  засыпанием на 2 сек в передаваемом коде. Убедиться в том, что запланированные действия выполняются последовательно, а потоки ожидают их окончания.

19. Шаблон Read/Write Lock. Объект блокировки имеет 4 метода: readLock, readUnlock,  writeLock и writeUnlock. Имеет два ArrayList объектов блокировки, которые создает для потоков, выполняющих указанные методы (ожидающих разрешения для чтения и для записи, а также счетчик количества потоков, выполняющих чтение и индикатор выполнения записи.  Логика выполнения writeLock (для примера):

  1. если выполняется запись или количество выполняющих чтение не равно 0, создать объект синхронизации, поместить в ArrayList и wait на нем, после разблокировки (см.п.3) выполнить п.2;
  2. иначе установить признак записи и выйти;
  3. после выполнении любого Unlock при нулевом счетчике выполняющих чтение проверить ArrayList ожидающих разрешения для записи. При непустом  удалить один из объектов и выполнить на нем notify (для повторения 2). При пустом – проверить ArrayList ожидающих чтения и выполнить аналогичные действия.

20. Шаблон State. Получает строку и выделяет в ней идентификаторы, константы и остальные символы, пропускает пробелы (пример: AAA78+666/fff). Необходимо «возвращать в поток» один символ по окончании распознавания идентификатора или константы.

 

 

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

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

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