На курсе вы узнаете:
| Неделя | Раздел | Тема |
|---|---|---|
| 16/09 | INTRO+REQ | Введение, цели и содержание курса. Кратко о требованиях. Понятие о качестве ПО. Модели качества. Стандарты серии ГОСТ Р ИСО/МЭК 250хх |
| 23/09 | UML2 | UML2. Варианты использования. Сценарии. Use Case 2.0. Управление рамками системы. Заинтересованные стороны. Полезные функции (Фичи). |
| 30/09 | REQ | Диаграммы потоков данных DFD. Примеры. Разработка требований к продуктам. Элементы customer development. Персоны. |
| 07/10 | REQ | Метод JTBD. Путешествия и карта путешествий. Истории пользователей и истории задач. Процесс гибкой разработки требований. |
| 14/10 | REQ | Порядок разработки программ по ГОСТ 19. Структура и содержание технического задания по ГОСТ 19. |
| 21/10 | DDD | Моделирование в ООП. Системы типов. Абстрактные типы данных (ADT). Понятие о классах. |
| 28/10 | UML2 | Элементы метамодели UML2. Моделирование структуры программы в UML2. Сравнение с моделями данных сущность-связь (ER). |
| 04/11 | DDD | Методы объектно-ориентированного анализа. Методы именных групп и Аббота, контрольные списки. Основные понятия и приемы предметно-ориентированного проектирования (DDD). Повсеместный язык, сущности, агрегаты. Окрестности, предметные области. |
| 11/11 | DDD+UML2 | Моделирование сценариев в системе. Структура в динамике. Взаимодействия, кооперации, последовательности в UML2. Проектирование на основе обязанностей (метод CRC, RDD). Согласованность моделей. |
| 18/11 | UML2 | Моделирование динамики. Конечные автоматы и схемы состояний. Управление сложностью, пакеты и профили. |
| 25/11 | UML2 | Моделирование процессов и алгоритмов. Сети Петри и модели деятельности (activity). Язык действий в UML2. |
| 02/12 | UML2+PROC | Построение согласованных моделей. Big Picture UML2. Процесс гибкого моделирования по требованиям (на основе ICONIX+AM+DDD) |
| 09/12 | ARCH+MSA | Введение в микросервисную архитектуру. Ресурсы. Декомпозиция на окрестности и на сервисы через DDD. Правило Конвея. Логические и физические DFD. Диаграммы компонентов в UML2. |
| 16/12 | EXAM | Дифференцированный зачет, контрольная и защита проектов по курсу |
Практика предполагает решение задач на семинарах, выполнение и защиту задания по командному курсовому проекту.
Для разработчиков, системных аналитиков и будущих архитекторов программного обеспечения.
Учебный проект - это ваш полигон, где вы практикуетесь в применении DDD к разработке микросервисных приложений. Заданием по проекту может быть упрощенный аналог существующей системы, или ваш собственный проект, или часть квалификационной работы.
Задание посвящено проработке требований применению DDD к предметной области, в которой проектируете систему. Прорабатываете и уточняете требования и рамки проекта. В итоге для дальнейшего моделирования с помощью Domain Driven Design нужны 3-4 вариантв использования или 5-6 историй пользователей.
Примерная таблица этапов и применяемых методов.
| # | Этап | Методы и результаты | Задачи |
|---|---|---|---|
| 1 | Анализ требований к продукту | Customer Development, JTBD, JTBD Interview, Personas, User story, Job story, Story Map, Customer Journey Map*, Value Proposition Canvas*, Jobs Map*, UI Wireframes, Product features | Предложить и описать образ продукта и решаемые задачи. Определить аудиторию и провести интервью с пользователями. Сформулировать полезные функции и ограничить его рамки. Прояснить элементарные сценарии для полезных функций. Составить словарь данных. |
| 2 | Разработка модели анализа | Use Case model, Use case text, Candidate classes, SIAOUT checklist, Abbot's method/Noun phrases, Entity-Relationship model | По описанию продукта разработать модель использования. Выделить кандидаты классов, построить модель предметной области в UML2 или ERD. Выписать важные требования к атрибутам качества по стандарту. |
| 3 | Разработка динамической модели | Responsibility-driven design, CRC, UML2 Collaborations model and implementation, UML2 Structured classes, UML2 Activity and Statechart and Interactions models, Logical Data-flow model. | Разделить сценарии по обязанностям и назначить ролям классов. Разработать модель деятельности или псевдокод для исполняемого поведения, схемы состояний или конечных автоматов для интерактивного и реактивного, модели взаимодействий или потоков данных для эмерджентного поведения. Обновить модель классов / данных. |
| 4 | Декомпозиция на микросервисы | Data consistency I, Ресурсы и алгоритмы / решетки типов, CRDT, Event storming, Domain-Driven Design, UML2 Components and Deployments models, Physical Data-flow model | Разделить модель предметной области на агрегаты и сформировать микросервисы. Разработать модель событий и процессов. Разработать модель компонентов в UML2 или Physical DFD. |
Хорошо сделанный проект - это круче, чем типовое тестовое задание на архитектора программных систем, релевантный опыт в применении методов проектирования. Понравившиеся методы можно забрать к себе на работу или вспомнить к собеседованию.
Общие критерии оценивания приведены в методичке Критерии оценивания проектов
Задания по проекту, по возможности, выполняются на семинарах, защита проходит в виде доклада, материалы по проекту высылаются на проверку не позднее, чем за 1 неделю до даты доклада.
Если кратко, то оцениваются следующие харатеристики выполненного проекта
Коллоквиум проводится в середине курса и служит для определения дальнейшей траектории участия в курсе. При успешной сдаче коллоквиума вознкиает возможность сдавать итоговый проект по курсу вместо контрольной работы и устного ответа.
Итоговая контрольная работа может быть предложена тем слушателям, кто не набрал достаточно баллов для получения оценки автоматом. В составе письменной контрольной работы на лекции будут предложены примерные задания.
Примерные критерии оценивания
Критерии оценивания, итоговый балл
ИБ = 0,2 * (ПЗ или ЛЗ)+ 0,3 * КЛК + 0,7 * (ПРЭ или ЭКЗ)
ЛЗ + ПЗ - посещения лекций и работа на семинаре
КЛК - оценка за коллоквиум
ЭКЗ - устно-письменный экзамен в конце семестра
ПРЭ - курсовой проект