Пример проектирования: шифрующая папка на "рабочем столе"

Приведу пример на «цепочку действий» из моей практики. Думаю, он будет интересен.

Ситуация: Для одного из заказчиков была написана программа – аналог PGP. Она позволяла шифровать и дешифровать файлы, создавать и удалять ключи. Отсутствовала только одна необходимая «фича»: Заказчик хотел иметь на «рабочем столе» папку, в которую он бы мог при помощи мыши перемещать файлы и другие папки. Перемещенные элементы должны были автоматически шифроваться.

Для реализации шифрующей папки к проекту подключили меня.

Идеальный программист

Вот уже длительное время я наблюдаю за теми программистами, которые добиваются успеха в аутсорсинге. Оказывается, наиболее успешны не те разработчики, которые умеют качественно спроектировать приложение. Наибольшего успеха в аутсорсинге добиваются программисты, которые умеют быстро разрабатывать прототипы.

Почему надо проектировать "от обязанностей", или сколько функций выполняет чашка?

В одном из комментариев к своей статье, желая подчеркнуть важность учёта обязанностей при проектировании программы, я написал:

"У каждой кружки есть своё предназначение. Есть кофейные чашки, есть чашки из чайного сервиза, есть чашки для чайной церемонии, есть походные кружки, кружки офисные, подарочные и т.д. В зависимости от назначения они приобретают нужную форму и размеры, а также - подбирается материал для их изготовления. Если в игру был добавлен объект "смертельно ядовитая трава", то он был добавлен не просто так, а потому что, например, уровень для прохождения без этого объекта - слишком лёгкий. Таким образом, его задача - "усложнить прохождение уровня".

Один из коллег в личной переписке на это возразил:

1. Если задумываться о назначении чашки, то будет сложно налить в чайную чашку кофе, а в кофеную – чай.
2. Гораздо проще снабдить обычную чашку двумя интерфейсами – "налить кофе" и "налить чай".

В качестве возражения на это замечание коллеги мне бы хотелось сказать вот что...

О том, как путают функциональный подход к проектированию с процедурным программированием

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

Пример 1. Проектирование графического редактора

Пример 2. Проектирование программы для метеостанции

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

Какие же недостатки приписывают функциональному подходу?

Как специалисты по эргономике формулируют задачу по оценке качества интерфейса?

Цитата:

"Во многих исследованиях по оценке деятельности операторов задаётся простой вопрос: какая интерфейсная система лучше – A или B? Это пример плохо сформулированной задачи, и результаты последующих усовершенствований почти наверняка будут разочаровывающими., т.е. они будут не очень информативными по сравнению с затратами на их получение. Поскольку интерфейсы используются для сообщения данных оператору в целях оказания помощи при выполнении рабочих заданий, то, как минимум, вопрос об оценке должен задаваться в такой форме:

Проектирование игр: функциональный подход

Сегодня выкладываю свою презентацию с КРИ 2008. Она освещает вопросы проектирования видео игр, разумеется, не с гейм-дизайнерской, а с технической точки зрения. В презентации изложены ответы на такие вопросы:

1. К каким проблемам приводят слишком большие иерархии классов?
2. Чем можно заменить такие иерархии?
3. Что брать в качестве основы декомпозиции на подсистемы - функции или объекты?
4. Как проектировать AI-водителя для гоночной игры? (Описание примера.)
5. Чем "грешит" паттерн "Цепочка обязанностей"?

Задача про датчики: построение функциональной архитектуры

Один из идеологов объектно-ориентированного подхода и один из авторов языка моделирования UML Джеймс Рамбо пишет:

"Модель классов описывает статическую структуру системы: объекты и отношения между ними, атрибуты и операции для каждого класса объектов. Модель классов – самая важная из трёх основных моделей. Мы считаем, что в основе системы должны быть объекты, а не требуемая функциональность, потому что объектно-ориентированная система лучше соответствует реальному миру и оказывается более жизнеспособной при возможных изменениях".

Дж. Рамбо, М. Блаха. UML 2.0. Объектно-ориентированное моделирование и разработка. 2-е изд. – СПб.: Питер, 2007, стр. 42.

На мой взгляд, данное утверждение в корне неверно, потому что любая система проектируется и создаётся для чего-то, т.е. предназначена для выполнения каких-то полезных функций. Эти полезные функции должны выполняться эффективно, желательно, с наименьшими затратами и с соблюдением надлежащего качества. Как результат, архитектура программы должна быть заточена под полезные функции, а не под абстрактные объекты реального мира.

С чего начать проектирование программы? Часть 2

Прежде чем следовать дальше, повторим основные тезисы предыдущей статьи:

1. Любая программа разрабатывается для решения конкретных задач. Эти задачи будем называть полезными функциями или просто функциями.
2. Прежде чем проектировать архитектуру программы, нужно сначала разработать алгоритм выполнения каждой полезной функции. Такой алгоритм в машиностроении называется технологией или технологическим процессом.
3. Технологический процесс представляет собой последовательность операций, которая может быть описана либо в текстовом виде в форме варианта использования, либо в форме блок-схемы, flowchart'а.
4. Порядок проектирования можно описать в виде такой схемы:

Функция --> Технологический процесс --> Архитектура

Сначала нужно сформулировать полезные функции, которые будет выполнять проектируемая программа. Затем – описать технологический процесс для каждой из них. И только после этого можно проектировать архитектуру.

С чего начать проектирование программы? Часть 1

С чего начать проектирование программы? Классический объектно-ориентированный подход даёт нам однозначный ответ на этот вопрос: с выявления ключевых абстракций и построения объектной модели предметной области.

Джеймс Рамбо, один из создателей языка UML и Rational Unified Process'а, в своей книге "UML 2.0. Объектно-ориентированное моделирование и разработка" предлагает нам такой алгоритм проектирования:

1. Изучить предметную область и выделить классы предметной области.
2. Удалить лишние классы (несущественные или избыточные).
3. Связать классы ассоциациями.
4. Выделить в классах атрибуты.
5. Реструктуризовать классы при помощи наследования.
6. Добавить классы приложения.
7. Добавить операции.

Дж. Рамбо, М. Блаха. UML 2.0. Объектно-ориентированное моделирование и разработка. 2-е изд. – СПб.: Питер, 2007, стр. 218 – 285.

После выполнения этой процедуры предполагается, что проектировщик получает архитектуру программы, которую только и надо что реализовать в коде.

Такой подход к проектированию напоминает мне попытки некоторых учёных и философов эпохи Возрождения построить летательный аппарат, наблюдая за полётами птиц. 

Почему дизайн должен быть функциональным?

Нередко разработчик проектирует систему, ориентируясь на что угодно, но только не на удобство её дальнейшего использования. Часто он даже не задумывается, что проектируемая система должна выполнять определённые обязанности.

Чтобы подчеркнуть мысль о том, что дизайн системы должен быть прежде всего функциональным, приведу три примера. Они взяты из разных областей человеческой деятельности, в том числе, и из software design'а.

Пример 1. Панель управления лифтом

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

Чтобы устранить проблему, сообразительные жильцы наклеили рядом с кнопками бумажки с номерами этажей.

Проектирование: расширение функциональной модели

Прежде чем приступать к проектированию структур данных, следует убедиться в том, что построенная функциональная модель системы достаточно полна.

Будем считать функциональную модель полной, если рассмотрение каждого последующего прецедента не приводит к добавлению новых функций.

Основная ошибка, допускаемая неопытными разработчиками, заключается в том, что они рассматривают упрощённые прецеденты. (Или же не рассматривают их вообще.) Чтобы построить полную функциональную модель, нужно изучать сложные юз-кейсы, взятые из реальной жизни.

Вернёмся к нашему примеру – "проектирование графического редактора для создания открыток".

Первая часть.

Вторая часть.

В третьей части мы расширим функциональную модель модуля редактирования.

Проектирование: построение функциональной модели

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

В умных книжках по OOA&D рекомендуют поступать наоборот: сначала выявлять классы и объекты и лишь затем – находить операции для этих классов и объектов. Автор данного блога рекомендует не верить умным книжкам и начинать проектирование с выявления функций.

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

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

Проектирование: как выполнять декомпозицию задачи?

Нередко формулировка задачи, полученная от заказчика, вызывает у проектировщика шок:

• "Спроектируйте графический редактор".
• "Спроектируйте игру для девочек 4 – 8 лет".
• "Спроектируйте GPS-навигационную систему для мобильного телефона".

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

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

1. выполнить декомпозицию задачи на подзадачи;
2. оценить объём полученных подзадач;
3. составить план работы, упорядочив подзадачи во времени и распределив их между участниками команды.

Рассмотрим эту процедуру на примере проектирования графического редактора.