Пластический способ редактирования фигур

К проектированию взаимодействия с пользователем разработчик может подойти двумя путями:

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

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

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

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

Проектирование взаимодействия с пользователем для графического редактора

Рисование фигур

Привычные нам графические редакторы для настольных ПК предоставляют пользователю множество готовых примитивов. Например, графический редактор, встроенный в Microsoft Word 2003, содержит 115 готовых автофигур.

Взаимодействие с пользователем в таких редакторах можно описать при помощи следующего юз-кейса:

1.      Программа предоставляет набор готовых фигур.

2.      Пользователь выбирает фигуру из набора.

3.      Пользователь задает расположение и размеры фигуры.

4.      Программа рисует фигуру в указанном месте и заданного размера.

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

Проектирование реализации

Цель этапа проектирование классов – найти подходящие классы и определить требования к ним.

Цель этапа проектирование реализации – изобрести реализацию класса, удовлетворяющую требованиям к нему.

В предложенном мною подходе логика проектирования может быть выражена формулой:

Функциональная модель => Группы функций => Кандидаты в классы => Реализация

Проектирование классов

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

Классический объектно-ориентированный подход даёт проектировщику чёткое руководство, как это делать.

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

Затем следует установить взаимосвязи между ключевыми абстракциями. Если взаимосвязь можно выразить отношением is-a, то такие абстракции следует связать при помощи  наследования. Если взаимосвязь подходит под отношение has-a, то такие абстракции следует связать при помощи агрегации.

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

Получается стройная и логичная картина:

class Figure;

class Rectangle : public Figure;

class Ellipse   : public Figure;

class Triangle  : public Figure;

К сожалению, она не позволяет создать редактор, который хоть в какой-то мере удовлетворяет потребностям пользователя.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Литература

Решил систематизировать некоторые свои публикации по четырём темам:

1)      Ошибки в программировании

2)      Проектирование игр и программ

3)      Продвижение программ и услуг по их разработке

4)      Проектирование нового продукта (hard & soft)

Общение с заказчиком: переходим на язык задач и проблем

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

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

Такой перерасход бюджета является серьёзной проблемой, но не катастрофой. Последствия плохой архитектуры могут быть частично скомпенсированы хорошим менеджментом (== грамотным распределением задач) и, наоборот, плохой менеджмент может быть частично скомпенсирован хорошим дизайном. Почему? Потому что хороший дизайн вызывает меньше проблем и, как следствие, уменьшает нагрузку на менеджера.

Более страшной – в плане затрат– является неправильная постановка задачи. Потому что она увеличивает расходы в разы. (Запросто может увеличить бюджет в 2, в 3 и даже в 4 раза.) Здесь я имею в виду ситуацию, когда разработчики делают не то, что клиенту нужно, а реализуют то, что клиент говорит.

Проектирование архитектуры программы: постановка задачи

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

В своём сообщении коллега Undying сформулировал такие требования к кандидату:

С виду в задаче нет ничего уникального. От кандидата требуется иметь опыт реализации высоконагруженных серверных приложений работающих в режиме 24 * 7. Сложность только в том как понять, что человек не просто участвовал в разработке такой системы, а играл в этом ключевую роль. По идее проще всего это выяснить в беседе о том какие проблемы были встречены при реализации, как их решали, как производилось расширение и добавление функциональности.

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

Собеседование с архитектором: методические рекомендации

Предположим, существует идеальная методика, которая позволяет эффективно решать задачи проектирования.

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

Тогда процедура проверки квалификации архитектора сводится к проверке следованию им методике:

(1) Если архитектор в процессе проектирования следует рекомендациям методики, то мы считаем его квалифицированным.

(2) Если архитектор в процессе проектирования не следует рекомендациям методики, то мы упрощаем себе жизнь и считаем его неквалифицированным.

Попробуем предположить, какой должна быть эта методика.

Как собеседовать архитектора?

Как-то раз ходил на собеседование в одну компанию на должность архитектора. По результатам - завёл обсуждение на RSDN. Будет интересно, к чему это обсуждение приведёт. Текст моего поста:


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

Суть проблемы: Система, которую придётся рефакторить, состоит из двух составляющих:

(1) картографические данные, хранящиеся в БД на сервере;
(2) визуализация этих картографических данных, хранящаяся на другом сервере.

Дело в том, что с частью (1) работает огромное число пользователей. А наша система относится к части (2), с которой работает лишь небольшое подмножество пользователей части (1).

Основная проблема заключается в том, что пользователи части (2) вынуждены синхронизировать вручную визуальную информацию с актуальной картографической. Ситуация осложняется тем, что подобная синхронизация (== создание растрового изображения) занимает длительное время — несколько часов.

Хотелось бы, чтобы в новой версии системы эта проблема была бы устранена. Чтобы для любой картографической информации всегда бы имелась актуальная графическая.

Подходы к решению:

1) Система (2) автоматически следит за данными в системе (1) и, если они обновились, перегенерирует растровое изображения изменённых участков. Недостаток: система (2) должна хранить данные из системы (1) для того, чтобы узнать, что они обновились.

2) Встроиться каким-либо образом между пользователями системы (1) и конечной базой данных для системы (1), чтобы отлавливать запросы на изменение данных. Если данные изменяются, то посылать уведомление системе (2) для того, чтобы она перегенерировала растровые изображения для изменённых данных.

3) Поработать над сокращением времени генерации растрового изображения.

Ситуация осложняется тем, что система (1) является приватной. К ней нет доступа. В принципе, можно было бы растеризовать данные в фоновом режиме, но непонятно, как узнать, что информация в системе (1) обновлена. Нет никаких сервисов, позволяющих узнать это. Доступ к СУБД системы (1) возможен только через Apache Tomcat. Напрямую доступ к БД закрыт, т.к. она приватна и принадлежит другой компании. Доступ только на общих основаниях.

Как проводят собеседования кандидата:

1) Просят рассказать о предыдущем опыте проектирования систем.
2) Просят спроектировать текстовый редактор с хайлайтингом, проверкой правописания и расстановкой переносов.
3) Рисуют на листочке то, как устроена их система, просят кандидата назвать недостатки дизайна и предложить варианты решений.

По п.п. 1 и 2 формально время не ограничивают. Но если за 5 минут кандидат не нарисует на бумаге дизайн системы, быстро теряют интерес и перебивают.

Мой вывод: Не понимают, что прежде чем решать задачу, её для начало надо грамотно поставить (слова "грамотно" и "поставить" здесь ключевые).

Как следствие, не понимают:

(1) важность перевода задачи из формы, как она сформулирована заказчиком (например, "спроектируйте текстовый редактор с хайлайтингом, проверкой правописания и расстановкой переносов") в форму, пригодную для выработки технического решения;
(2) важность написания юз-кейсов для выполнения п. (1).

Резюме: ИМХО, подобный вариант проведения собеседования с архитектором не является эффективным.

Интересует: Мне в этой ситуации интересен общий подход к проведению собеседования с архитектором:

(1) на разработку нового проекта с нуля;
(2) на масштабный рефакторинг готового проекта.

Просьба высказывать свои варианты и свои точки зрения.


P.S.: Чуть позже расскажу, как бы я проводил собеседование с кандидатом в архитекторы. Но сначала будет интересно узнать мнения коллег.

Литература по проектированию

Сегодня приступил к ведению блога, в котором буду публиковать некоторые свои мысли по проектированию софта. Думаю, что в качестве первого поста будет полезен список литературы по проектированию, который я когда-то опубликовал на RSDN:

1. ГОСТ 19.xxx. Единая система программной документации –http://linux.nist.ru/hr/doc/gost/gost19.htm
2. Ален Э. Типичные ошибки проектирования./Пер. с англ. – СПб.: Питер, 2003. – 224 с.: ил.
3. Ахо, Альфред, В., Хопкрофт, Джон, Ульман, Джеффри, Д. Структуры данных и алгоритмы. : Пер. с англ. : Уч. пос. – М.: Издательский дом "Вильямс", 2000. – 384 с.: ил.
4. Бадд Т. Объектно-ориентированное программирование в действии/Перев. с англ. – СПб.: Питер, 1997. – 464 с.: ил.
5. Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на C++, 2-е изд./Пер с англ. – М.: "Издательство Бином", СПб: "Невский диалект", 1998 г. 
6. Гамма Э. , Хелм Р. , Джонсон Р. , Влиссидес Дж. Приемы объектно-ориентированного проектирования. Паттерны проектирования. — СПб: Питер, 2001. — 368 с.: ил.
7. Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. Проектирование информационных систем: курс лекций. - М.: Интернет-Университет Информационных Технологий, 2005. - 304 с., ил. http://www.intuit.ru/department/se/devis/
8. Йордон, Эдвард, Аргила, Карл. Структурные модели в объектно-ориентированном анализе и проектировании. – М.: Издательство «ЛОРИ», 1999. – 264 с.: ил.
9. Кириевски, Джошуа. Рефакторинг с использованием шаблонов/Пер. с англ. – М.: ООО «И.Д. Вильямс», 2006. – 400 с.: ил.
10. Коберн, Алистер. Современные методы описания функциональных требований к системам/Пер. с англ. – М.: Издательство «Лори», 2002 г. – 263 с.: ил.
11. Коуд, Петер, Норт, Дэвид, Мейфилд, Марк. Объектные модели. Стратегии, шаблоны и приложения. — М.: Издательство "ЛОРИ", 1999. — 434 с.: ил.
12. Мацяшек, Лешек, А. Анализ требований и проектирование систем. Разработка информационных систем с использованием UML/Пер. с англ. – М.: Издательский дом «Вильямс», 2002. – 432 с.: ил.
13. Мейер, Бертран. Объектно-ориентированное конструирование программных систем / Пер. с англ. – М.: Издательско-торговый дом «Русская редакция», 2005. – 1232 стр.: ил.
14. Рамбо Дж., Блаха М. UML 2.0. Объектно-ориентированное моделирование и разработка. 2-е изд./Пер. с англ. – СПб.: Питер, 2007. – 544 с.: ил.
15. Раскин Джеф. Интерфейс: новые направления в проектировании компьютерных систем. – Пер. с англ. – СПб: Символ-Плюс, 2007. – 272 с., ил.
16. Страуструп Б. Язык программирования C++, 3-е изд./Пер. с англ. – СПб.; М.: «Невский Диалект» — «Издательство БИНОМ», 1999 г. – 991 с.: ил.
17. Тидвелл Дженифер. Разработка пользовательских интерфейсов. – СПб.: Питер, 2008. – 416 с., ил.
18. Фаулер, Мартин. Архитектура корпоративных программных приложений. – Пер. с англ. – М.: Издательский дом «Вильямс», 2006. – 544 с.: ил.
19. Фаулер М. Рефакторинг: улучшение существующего кода. — Пер. с англ. — СПб: Символ-Плюс, 2003. — 432 с.: ил.
20. Хоп, Грегор, Вульф, Бобби. Шаблоны интеграции корпоративных приложений/Пер. с англ. – М.: ООО «И.Д. Вильямс», 2007. – 672 с.: ил.
21. Шаллоуей, Алан, Трот, Джеймс Р. Шаблоны проектирования. Новый подход к объектно-ориентированному анализу и проектированию/Пер. с англ. — М.: Издательский дом "Вильямс", 2002. — 288 с.: ил.
22. Шумэйкер Скотт. Techniques and Strategies for Data-driven design in Game Development – http://ai.eecs.umich.edu/soar/Classes/494/talks/Schumaker.pdf
23. Элджер Дж. C++: библиотека программиста/Пер. с англ. – СПб.: ЗАО «Издательство «Питер», 1999. – 320 с.: ил.

Рекомендую также посмотреть статьи по применению ТРИЗ в программировании:

1. С.В. Сычев, К.А. Лебедев. Как вспомнить и «так известное» — http://www.triz-ri.ru/themes/method/creative/creative50.asp
2. С.В. Сычев, К.А. Лебедев. Освобождение узников оператора IF — http://www.triz-ri.ru/themes/method/creative/creative57.asp
3. С.В. Сычев, К.А. Лебедев. О потерянном уровне — http://www.triz-ri.ru/themes/method/creative/creative60.asp
4. С.В. Сычев, К.А. Лебедев. Не только про калькулятор - http://www.triz-ri.ru/themes/method/creative/creative66.asp
5. С.В. Сычев, К.А. Лебедев. «Что увидишь, то и неси...» — http://www.triz-ri.ru/themes/method/creative/creative51.asp
6. С.В. Сычев, К.А. Лебедев. «Неважно, где рисовать...» — http://www.triz-ri.ru/themes/method/creative/creative52.asp
7. С.В. Сычев, К.А. Лебедев. «Пусть само проявится...» — http://www.triz-ri.ru/themes/method/creative/creative56.asp

Литература на английском языке:

1. NAS System Engineering Manual Section 4.4.
2. NASA System Engineering Handbook.
3. System Engineering Fundamentals.