Модульность
•Система разбивается на небольшие модули
•Разбиение может итерироваться, пока не станет достаточно ясно, как реализовать каждый модуль
•Каждый модуль решает гораздо меньше задач
•Поэтому он гораздо проще
•Реализуется разделение ответственности, становится проще управлять развитием в целом
•Модули взаимодействуют через четко определенные интерфейсы
•Внутренние особенности реализации модулей мало зависят друг от друга
•Их можно разрабатывать и развивать независимо, если интерфейсы сохраняются
•Согласование изменения интерфейсов только между зависящими от них модулями проще, чем изменение в рамках всей системы
Кулямин В.В. ФКН ВШЭ, ПИ / ВМК МГУ |
Основы инженерии программного обеспечения |
11 |
Желательные свойства интерфейсов
•Адекватность
•Соответствие решаемым модулем задачам
•Пример неадекватности: использование списка вместо множества
•Полнота
•Наличие в интерфейсе операций для всех нужных при использовании модуля действий
•Часто нужна замкнутость – вместе с операцией должна быть и обратная, отменяющая результаты ее выполнения
•Минимальность
•Простота
Кулямин В.В. ФКН ВШЭ, ПИ / ВМК МГУ |
Основы инженерии программного обеспечения |
12 |
Желательные свойства интерфейсов
•Адекватность
•Полнота
•Минимальность
•Несводимость операций к простым комбинациям других
•Особенно важна для систем с ограниченными ресурсами, для богатых ресурсами систем часто игнорируется в пользу большего удобства
•Простота
•Наглядность названий и параметров операций (их соответствие интуитивным понятиям)
•Удобство их использования и понимания в коде
•Примеры непростых операций
•Заменим для стека void push(Object o) и Object pop() на одну операцию Object op(Object o), работающую как push(), если аргумент не null (и возвращающую null), и как pop(), если аргумент null
Весь код, использующий обычный стек, можно переписать на использование этого интерфейса, но его понятность значительно снизится, возрастут риски ошибок
•Можно заменить операцию add(Object o) для множества на операцию add(Object o1, Object o2, Object o3) Формально все можно так переписать, но ясность кода пострадает
Кулямин В.В. ФКН ВШЭ, ПИ / ВМК МГУ |
Основы инженерии программного обеспечения |
13 |
Абстракция и уточнение
•Абстракция
•Устранение в постановке задач деталей, не существенных на данном этапе
•Простой пример: использование множества для хранения каких-то данных, которые отличаются лишь каким-то идентификатором
•Уточнение
•Добавление в рассматриваемые задачи дополнительных деталей, после того, как их решения получены в более абстрактной постановке
•Простой пример: для повышения эффективности операций над множеством, мы можем использовать его представление в виде сбалансированного дерева (например, красно-черного), если хранимые данные можно линейно упорядочить
Кулямин В.В. ФКН ВШЭ, ПИ / ВМК МГУ |
Основы инженерии программного обеспечения |
14 |
Повторное использование
•Каждое отдельное знание (как элемент создаваемых решений) формулируется в одном месте (в виде одного элемента требований или отдельного модуля)
•Во всех местах, где это знание нужно использовать, даются ссылки на это место (или вызывается соответствующий модуль)
Основное следствие – экономия на долгосрочном развитии При изменении этого знания можно менять его единственную
формулировку, во всех местах его использования обновление будет автоматическим Иначе нужно вносить изменения во все места, где оно сформулировано независимо
Возможная проблема – можно случайно склеить разнородные элементы решений, которые случайно совпали в определенном контексте, в дальнейшем их придется разделить Корректность объединения или разделения зависит от возможных
сценариев развития, его можно оценить только в перспективе
Кулямин В.В. ФКН ВШЭ, ПИ / ВМК МГУ |
Основы инженерии программного обеспечения |
15 |
Примеры
•Трудно найти примеры использования отдельных принципов, обычно все три сочетаются
•Эффективное выделение модулей и их повторное использование сильно зависят от правильного (с точки зрения развития) выбора используемых абстракций
•Абсолютно правильного выбора не бывает, в разных контекстах, при разных сценариях развития нужно использовать различные абстракции
Кулямин В.В. ФКН ВШЭ, ПИ / ВМК МГУ |
Основы инженерии программного обеспечения |
16 |
Пример: представление даты
•Выделяются различные понятия, связанные с датами и временем
•Абстрактная точка во времени java.util.Date
•Календарь – набор атрибутов и группировка дат в рамках определенной культуры
Один из подклассов java.util.Calendar
• |
Григорианский календарь |
8 февраля 2021 года |
• |
Исламский (календарь Хиджры) |
25 Джумада ас-сани 1442 года |
• |
Французский республиканский календарь |
20 Pluviôse CCXXIX (229 год) |
• |
Календарь Майа |
13.0.8.4.11 |
• Для текстового представления отдельно задается формат
• java.text.SimpleDateFormat
• |
“yyyy.mm.dd” |
2021.02.08 |
• |
“EEE, d MMM yyyy” |
Mon, 8 Feb 2021 |
Кулямин В.В. ФКН ВШЭ, ПИ / ВМК МГУ |
Основы инженерии программного обеспечения |
17 |
Пример: передача данных
•Задачи обычно разделяются так, что возникает паттерн «Многоуровневая система»
•Передача отдельных битов между двумя связанными машинами Физический уровень
• Вопросы: носитель (электропровода, инфракрасный сигнал, и т.п. ) кодировка битов (прямая, чередование и пр.)
•Надежная передача потока данных между связанными машинами Канальный уровень
•Ethernet, WiFi, ZigBee
•Передача данных между произвольными машинами Сетевой уровень
•IP
•Надежная передача потока данных между произвольными машинами Транспортный уровень
•TCP
•Передача информации определенной структуры Прикладной уровень
•HTTP, FTP
Кулямин В.В. ФКН ВШЭ, ПИ / ВМК МГУ |
Основы инженерии программного обеспечения |
18 |
Конец
