---

Практическая работа № 3. Построение архитектуры программного средства
Дисциплина: МДК.02.01 Технология разработки программного обеспечения
Тема: 2.1.1. Основные понятия и стандартизация требований к ПО
Курс: 4 курс, специальность 09.02.07
Продолжительность: 2 академических часа (1 занятие)
Цель работы
Цель: Научиться проектировать архитектуру программного средства на основе
разработанного технического задания, выбирать архитектурный стиль, выделять модули
и определять связи между ними.
Задачи:
1. Закрепить теоретические знания об архитектуре ПО и архитектурных стилях.
2. Освоить методику декомпозиции системы на модули.
3. Научиться строить диаграммы компонентов и связей.
4. Сформировать навык описания архитектуры в проектной документации.
Формируемые компетенции:
• ПК 2.3. Проектировать архитектуру программного обеспечения.
• ПК 2.2. Разрабатывать и оформлять техническую документацию на программное
обеспечение.
• ОК 02. Использовать современные средства поиска, анализа и интерпретации
информации.
• ОК 01. Выбирать способы решения задач профессиональной деятельности.
Оборудование и материалы:
• Персональный компьютер.
• Текстовый редактор (MS Word, LibreOffice Writer или аналогичный).
• Средство для построения диаграмм (draw.io, MS Visio, LibreOffice Draw, PlantUML).
• Результаты практических работ № 1 и № 2 (анализ предметной области и
техническое задание).
Важно! Варианты предметных областей
Варианты предметных областей остаются теми же, что и в практических работах №
1 и № 2. Каждый студент продолжает работу со своей предметной областью. Все
наработки (анализ предметной области и техническое задание) используются как
исходные данные для проектирования архитектуры.
Теоретическая справка
Архитектура программного обеспечения — это совокупность структуры системы
(компонентов, модулей, подсистем) и правил их взаимодействия, а также принципов,
определяющих организацию системы.
Архитектурный стиль — это общий подход к организации структуры системы,
определяющий способ разделения на компоненты и их взаимодействие.
Основные архитектурные стили
Стиль Описание Когда применять
Монолитная
архитектура
Вся система — единый блок кода,
компоненты связаны внутри
одного процесса
Небольшие проекты,
простые приложения,
стартапы
Слоистая
(многоуровневая)
архитектура
Система делится на слои
(представление, бизнес-логика,
доступ к данным)
Корпоративные
приложения, веб-системы
Клиентсерверная
архитектура
Система делится на клиентскую
часть и серверную часть,
взаимодействующие по сети
Приложения с
централизованным
хранилищем данных
Микросервисная
архитектура
Система состоит из множества
независимых небольших сервисов
Крупные, развивающиеся
системы
Событийноориентированная
архитектура
Компоненты взаимодействуют
через события
Системы реального
времени, обработка
потоков данных
Слоистая архитектура (классическая схема)
Слой Назначение Примеры компонентов
Слой представления
(Presentation)
Взаимодействие с
пользователем
Веб-интерфейс, мобильное
приложение, консоль
Слой бизнес-логики
(Business Logic)
Реализация правил
предметной области
Сервисы, обработчики,
контроллеры
Слой Назначение Примеры компонентов
Слой доступа к
данным (Data Access)
Работа с хранилищем
данных
Репозитории, DAO, ORM
Слой данных
(Database) Хранение информации База данных, файлы
Ключевые понятия
Понятие Определение
Модуль Относительно независимая часть системы, реализующая
определённую функциональность
Компонент Более крупная единица, чем модуль; может включать несколько
модулей
Интерфейс Способ взаимодействия между модулями (набор методов, API)
Связность (coupling) Степень зависимости между модулями; чем ниже, тем лучше
Сцепление (cohesion) Степень внутренней связанности элементов модуля; чем выше,
тем лучше
Диаграмма
компонентов
UML-диаграмма, показывающая структуру системы и связи
между компонентами
Принципы хорошей архитектуры
1. Разделение ответственности — каждый модуль отвечает за свою задачу.
2. Слабая связность — модули минимально зависят друг от друга.
3. Высокое сцепление — элементы внутри модуля тесно связаны.
4. Инкапсуляция — модуль скрывает детали реализации.
5. Открытость к расширению — можно добавлять новые функции без изменения
существующих.
Ход работы
Этап 1. Подготовка исходных данных
1. Возьмите результаты практической работы № 2 (техническое задание).
2. Выпишите все функциональные требования — они определят состав модулей.
3. Выпишите нефункциональные требования — они повлияют на выбор
архитектурного стиля.
4. Определите ключевых пользователей системы (из таблицы стейкхолдеров).
Результат этапа: готовность исходных данных для проектирования.
Этап 2. Выбор архитектурного стиля
1. Проанализируйте требования к вашей системе.
2. Выберите один или комбинацию архитектурных стилей.
3. Обоснуйте свой выбор письменно.
Вопросы для обоснования:
• Какой масштаб системы (небольшая, средняя, крупная)?
• Сколько пользователей будет работать одновременно?
• Требуется ли работа через интернет или только локально?
• Нужно ли разделять систему на независимые части?
• Какие требования к масштабируемости и надёжности?
Пример обоснования:
«Для системы учёта библиотеки выбрана трёхуровневая клиент-серверная архитектура.
Это обусловлено необходимостью централизованного хранения данных (книги, читатели,
выдачи) и возможностью работы нескольких библиотекарей с одного сервера. Система
будет реализована как веб-приложение, что обеспечит доступ с любого рабочего места без
установки дополнительного ПО.»
Результат этапа: выбранный архитектурный стиль с обоснованием.
Этап 3. Декомпозиция системы на модули
Разбейте систему на модули (компоненты). Каждый модуль должен реализовывать
логически связанную группу функций.
Правила декомпозиции:
• Каждый модуль отвечает за одну зону ответственности.
• Модули должны быть слабо связаны между собой.
• Количество модулей — от 4 до 10 (для учебного проекта).
Пример декомпозиции для библиотеки:
№ Модуль Ответственность Реализуемые функции
1
Модуль
аутентификации Управление доступом
Вход в систему, разграничение
прав
2 Модуль учёта книг Работа с книжным
фондом
Добавление, редактирование,
удаление книг
3 Модуль читателей Работа с читателями Регистрация, редактирование
данных
4
Модуль
выдачи/возврата
Оформление
операций
Выдача книги, возврат,
продление
5 Модуль поиска Поиск по каталогу Поиск по автору, названию,
жанру
6 Модуль отчётов Формирование
отчётности
Список задолжников,
статистика
7 Модуль базы данных Работа с хранилищем CRUD-операции, транзакции
Результат этапа: таблица модулей с описанием ответственности.
Этап 4. Определение связей между модулями (20–25 минут)
Определите, как модули будут взаимодействовать друг с другом:
1. Направление вызовов — какой модуль вызывает какой.
2. Тип взаимодействия — синхронный вызов, асинхронное сообщение, событие.
3. Передаваемые данные — какие данные передаются между модулями.
Пример описания связей:
Модульисточник
Модуль-приёмник Тип связи Передаваемые
данные
Модуль выдачи Модуль книг Синхронный
вызов
ID книги, статус
Модуль выдачи Модуль читателей Синхронный
вызов
ID читателя
Модульисточник
Модуль-приёмник Тип связи Передаваемые
данные
Модуль поиска Модуль базы
данных
Синхронный
вызов
Параметры поиска
Модуль отчётов Модуль базы
данных
Синхронный
вызов
Запрос данных
Результат этапа: таблица связей между модулями.
Этап 5. Построение диаграммы компонентов
Постройте диаграмму компонентов (UML Component Diagram), отражающую:
1. Все модули (компоненты) системы.
2. Интерфейсы, через которые модули взаимодействуют.
3. Связи между модулями.
4. Внешние системы (если есть).
Требования к диаграмме:
• Диаграмма должна быть читаемой.
• Все модули должны быть подписаны.
• Связи должны иметь направление.
• Желательно использовать нотацию UML.
Инструменты: draw.io, MS Visio, PlantUML, Lucidchart.
Результат этапа: готовая диаграмма компонентов.
Этап 6. Описание слоёв системы
Если вы выбрали слоистую архитектуру, опишите каждый слой:
Слой Компоненты Назначение
Представление Веб-интерфейс, формы Взаимодействие с пользователем
Бизнес-логика Сервисы, контроллеры Реализация правил предметной
области
Доступ к данным Репозитории, DAO Работа с базой данных
Данные PostgreSQL Хранение информации
Результат этапа: описание слоёв системы.
Этап 7. Описание интерфейсов взаимодействия
Опишите, как модули будут обмениваться данными:
1. Внутренние интерфейсы — методы, которые модуль предоставляет другим
модулям.
2. Внешние интерфейсы — API для взаимодействия с другими системами.
3. Форматы данных — JSON, XML, Protocol Buffers.
Пример описания интерфейса:
Интерфейс: IBookService
Методы:
- addBook(bookData): Book
- updateBook(bookId, bookData): Book
- deleteBook(bookId): void
- findBook(query): List<Book>
- getBookById(bookId): Book
Результат этапа: описание интерфейсов.
Этап 8. Обоснование выбора технологий (15–20 минут)
Кратко обоснуйте выбор технологий для реализации:
Компонент Технология Обоснование
Язык программирования Python Простота, большое количество библиотек
Фреймворк Django Быстрая разработка веб-приложений
База данных PostgreSQL Надёжность, поддержка транзакций
Фронтенд React Популярность, компонентный подход
Результат этапа: таблица технологий с обоснованием.
Этап 9. Оформление отчёта
Отчёт должен содержать:
1. Титульный лист.
2. Цель работы.
3. Исходные данные (краткая выдержка из ТЗ).
4. Выбранный архитектурный стиль и обоснование.
5. Декомпозиция на модули (таблица).
6. Связи между модулями (таблица).
7. Диаграмма компонентов.
8. Описание слоёв системы (если применимо).
9. Описание интерфейсов.
10.Обоснование выбора технологий.
11.Вывод.
Задания для выполнения
Задание 1
Разработайте архитектуру программного средства для предметной области, выбранной в
практической работе № 1. Выполните этапы 2–9. Результат оформите в виде отчёта.
Задание 2
Постройте диаграмму развёртывания (Deployment Diagram), показывающую:
• Физические узлы (серверы, рабочие станции).
• Размещение компонентов на узлах.
• Сетевые соединения.
Контрольные вопросы
1. Что такое архитектура программного обеспечения?
2. Какие архитектурные стили вы знаете? В чём их отличия?
3. Что такое слоистая архитектура? Какие слои выделяют?
4. Что такое декомпозиция системы? Зачем она нужна?
5. Что такое связность (coupling) и сцепление (cohesion)?
6. Почему важно стремиться к слабой связности и высокому сцеплению?
7. Что такое диаграмма компонентов? Какие элементы она содержит?
8. Что такое интерфейс модуля? Зачем он нужен?
9. Как архитектура связана с нефункциональными требованиями?
10.Что может произойти, если архитектура спроектирована неправильно?
Критерии оценки
Критерий Баллы
Обоснование выбора архитектурного стиля 2
Полнота декомпозиции на модули (4–10 модулей) 3
Корректность определения связей между модулями 2
Качество диаграммы компонентов 3
Описание слоёв системы 2
Описание интерфейсов взаимодействия 2
Обоснование выбора технологий 1
Оформление отчёта 1
Грамотность и стиль изложения 1
Дополнительно: диаграмма развёртывания +2
Дополнительно: альтернативный вариант архитектуры и сравнение +3
Итого 17 (+5)
Оценка:
• «Отлично» — 15–17 баллов (и более).
• «Хорошо» — 11–14 баллов.
• «Удовлетворительно» — 7–10 баллов.
• «Неудовлетворительно» — менее 7 баллов.
Рекомендуемая литература
1. Конспект лекций по МДК.02.01 «Технология разработки программного
обеспечения».
2. ГОСТ 19.201-78 «Техническое задание. Требования к содержанию и оформлению».
3. Учебные пособия по проектированию информационных систем.
4. Материалы по UML-диаграммам.