CC BY
38
ИСПОЛЬЗОВАНИЕ КАРКАСНОГО ПОДХОДА В РАЗРАБОТКЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
© Гоменюк К.С.*
Национальный исследовательский университет «Высшая школа экономики»,
г. Москва
Работа посвящена решению одной из проблем проектов по созданию программного обеспечения - связыванию элементов пользовательского интерфейса и процедур обработки информационных объектов предметной области. В статье приводятся рекомендации относительно организации командной разработки программного обеспечения с чистого листа.
Разработка программных продуктов требует от их создателей наличия большого опыта разработки приложений, а также навыков проектирования информационных систем. Часто традиционных навыков программирования не хватает, чтобы без промедлений перейти от формализации технического решения к его реализации. Большинство источников по тематике проектирования пользовательского интерфейса информационных систем недостаточно освещает проблему стыкования программного кода и элементов управления.
Многие специалисты в области программирования, находящиеся в начале пути профессионального развития, сталкиваются с некоторыми из следующих проблем:
- в проекте программного продукта не удается однозначно выделить отдельные формы пользовательского интерфейса;
- в процессе работы обнаруживается избыточность или недостаточность функционального наполнения определенных частей интерфейса;
- возникают трудности при совмещении ранее разработанных библиотек обработки внутрисистемных обектов с формати пользовательского интерфейса;
- при наличии определенной схемы пользовательского интерфейса возникают сложности при организации навигации по всей системе;
- формы пользовательского интерфейса оказываются слишком тесно связанными друг с другом, что приводит к невозможности дальнейшего развития программного обеспечения без полной переработки уже написанного текста программы;
- добавление одного и того же представления интерфейса в разные части системы невозможно.
* Преподаватель.
Современные тенденции в области развития информационных систем включают интенсивное использование асинхронных структур и методов. Повышение доступности интернета и постоянное совершенствование веб-технологий накладывает дополнительные требования к квалификации специалистов. Разрыв между имеющемся уровнем подготовки и необходимым уровнем знаний может оказаться значительным, из-за чего часть перспективных проекты длительное время не может перейти к стадии реализации, либо завершаются срезу после выполнения анализа предметной области. Шансы на успех значительно повышаются, если в проектной команде налажена организация работы участников, включая техническую сторону.
Проблемы начальных этапов разработки программного обеспечения
Среди задач разработки программного обеспечения можно выделить две группы:
- работы по настройке существующего программного обеспечения. Также относится интеграция, установка, оптимизация взаимодействия различных программных компонентов. Разработчики жестко связаны с приобретенными заказчиком лицензиями. От специалистов требуется наличие знаний о внутренней организации внедряемой системы;
- самостоятельный проект, подразумевающих регулярный выпуск новых версий разрабатываемого продукта. Заказчик может отсутствовать. Программное обеспечение создается с чистого листа.
Задачи второй группы в конечном итоге могут оказаться сложнее и затратнее проектов по внедрению. Однако, когда речь идет об инновационных, старт-ап - проектах, самостоятельная работка является предпочтительным решением.
Самостоятельные проекты могут быть инициированы сторонними организациями, либо определенной группой. Возможность успеха того или иного проекта может быть определена еще на ранних стадиях. Существуют факторы, отрицательно сказывающиеся на будущем конкретного проекта. В первую очередь, это отсутствие видения у организаторов. Но даже наличие четкого представления о конечных результатах не гарантирует успешное достижение поставленных целей. С другой стороны, недопонимание между заказчиками и исполнителями также понижает шансы на успех, особенно, когда заказывающая сторона не воспринимает проект «с чистого листа» как таковой. Это приводит к завышению ожиданий, невозможности удовлетворить запросы пользователей в разумные сроки, а также к непониманию жизненного цикла программного продукта.
В данной работе рассматриваются вопросы, больше связанные с разработкой, осуществляемой отдельной инициативной группой. Качество приложения напрямую связано с гибкостью процесса разработки, определяя
то, насколько эффективно команда разработки отреагировать на изменяющиеся запросы пользователей.
В процессе работы над проектом участники группы формализуют требования потенциальных пользователей к продукту. Примерный список функций, выявленный на этапе анализа требований конечных пользователей, необходимо преобразовать в формы графического пользовательского интерфейса. В современных средах программирования специалисты обеспечены широким спектром разнообразного полезного инструментария для создания приложений. Визуальные среды разработки содержат средства составления набросков интерфейса, сервисы подсказок по программному коду, отладчики и многое другое.
Системы программирования часто привязаны к определенному списку платформ. Платформы упрощают разработку. Однако, не стоит полностью полагаться на встроенные алгоритмы работы программных каркасов. Для обеспечения полного контроля над собственным проектом требуется ввести дополнительный уровень абстракции, который позволил бы сочетать преимущества нескольких платформ.
Этап анализа предпочтений и потребностей пользователей заканчивается составлением сценариев использования разрабатываемой системы. Основные проблемы, оказывающие влияние на успешность продолжения работы в дальнейшем:
- не получается сопоставить разработанные алгоритмы обработки данных формам интерейса;
- нет однозначного ответа на вопрос о том, как осуществлять переходы между страницами или формами приложения;
- точки расширения неочевидны, добавить новые функции на уровне программного кода слишком сложно, либо проект оказывается «одноразовым».
Переход к этапу реализации проекта
В результате исследований взаимодействия человека и компьютера специалист в области юзабилити Бен Шнейдерман составил набор правил, которые могут быть использованы при разработке многих типов интерфейсов. Он назвал их «Восемь золотых правил для разработчиков интерфейсов». Этот список наиболее полно описывает концепцию предоставления управления пользователю. Ниже приводится данный набор рекомендаций:
1. Стремитесь к логичности;
2. Для опытных пользователей должен быть предусмотрен быстрый способ (сокращения, горячие клавиши, макросы) выполнения действий;
3. Должна быть реализована информативная обратная связь;
4. Диалог должен быть законченным;
5. Обработка ошибок должна быть простой;
6. Должен быть реализован простой способ отмены действий;
7. Пользователь должен чувствовать, что все под его контролем;
8. Как можно меньше загружайте кратковременную память.
Вышеупомянутые рекомендации не накладывают ограничения на выбор способов верстки форм пользовательского интерфейса. Элементы дизайна являются отдельным аспектом разработки приложений и обеспечивают удобное использование прикладной логики. Главенствующую место в разработке приложения занимает организация навигации по фрагментам программы. Переходы между страницами интерфейса должны контролироваться определенными объектами внутри системы. На структуру контроллера накладываются специальные требования, помогающие избежать ранее упомянутых проблем.
В соответствие с рекомендациями ведущих софтверных компаний, необходимо проводить деление пользовательского интерфейса на фрагменты (страницы) так, чтобы каждая страница ассоциировалась с определенной задачей пользователя. Декомпозиция позволяет сгруппировать функции системы, выделить бизнес-объекты, с которыми работает пользователь, и поставить в соответствие действия, допустимые для каждого объекта. Таким образом, интерфейс программного обеспечения должен обладать не только объектно-ориентированными свойствами. Пользователь выполняет действия над объектами предметной области в контексте конкретной задачи с заранее определенным набором результатов.
Для реализации интерфейса, обладающего вышеописанными характеристиками был выбран объектно-ориентированный подход. Далее приводится описание применения данного способа разработки.
Использование объектно-ориентированного подхода
На сегодняшний день объектно-ориентированный подход к разработке информационных систем является достаточно распространенным, в первую очередь благодаря активному развитию различных сред разработки, которые значительно сокращают время, затрачиваемое на написание программного кода. Генераторы программного кода формируют фрагменты приложения, после чего остается дополнить созданные файлы логикой обработки данных, используемых внутри приложения.
Согласно существующим публикациям, объектно-ориентированное программирование можно рассматривать как способ оформления программного кода, а также способ организации разработки в условиях, когда создание конечного продукта ведется командой разработчиков, а конечный продукт -сложная информационная система. Использование ООП включает в себя применение шаблонов проектирования. Следует отметить, что такой способ разработки оправдывает средства только для сложных проектов. В противном случае, время, потраченное на создание иерархии наследования клас-
сов, интерфейсов и переопределений может превысить время, отведенное на создание полезного программного кода.
Для устранения неопределенности при выборе точек расширения, а также для повышения качества организации разработки предлагается начинать проектирование архитектуры программного обеспечения с создания каркаса приложения.
Каркас приложений в информационных системах - это структура программной системы; программное обеспечение, облегчающее разработку и объединение разных компонентов большого программного проекта. Каркас состоит из группы базовых классов и интерфейсов. Для успешной работы над проектом участники проектной команды должны обладать одинаковыми знаниями относительно концепции системы. Положительный эффект применения собственного каркаса заключается в упрощении расширения функциональности приложения, сокращении времени подготовки технического решения, повышении прозрачности программного кода. Наличие своего каркаса способствует ведению параллельной разработке. Недостатком данного подхода является требование постоянного контроля за программным кодом и приведение его в соответствие с принятой заранее концепцией.
Для создания пользовательского интерфейса, отвечающего ранее приведенным требованиям, следует разработать специальную структуру классов. Ниже приводится таблица соответствий между требованиями к пользовательскому интерфейсу и элементами программного обеспечения.
Таблица 1
Требование к интерфейсу Требование к структуре программных средств
Ориентированность на задачи пользователя Наличие отдельных элементов управления (страниц), соответствующих контексту решаемых задач. Каждая страница унаследована от одного и того же интерфейса;
Поддержка работы с бизнес-объектами К каждому бизнес-объекту применяется модель «данные-конт-роллер-представление»; Все контроллеры поддерживают отслеживание изменений
Выполнение действий с учетом прав пользователей Список доступных действий формируется только после выполнения запроса к серверу информационной системы
Разработка каркаса приложения
Многие источники, посвященные программированию, описывают разнообразные шаблоны, но не сообщают читателю о способе применения конкретных шаблонов, а также не содержат инструкций по переносу функциональных требований в плоскость пользовательского графического интерфейса. Применение модифицированного шаблона «единая точка входа» (Front сойгоИег) в качестве основы каркаса приложения может оказаться предпочтительным выбором в виду следующих особенностей:
1. Централизованная обработка сообщений;
2. Простая организация передачи сообщений между фрагментами графического интерфейса;
3. Возможность внесения элемента стандартизации в процесс разработки, что значительно ускоряет работу за счет устранения возможного взаимного непонимания участников проекта.
В свободном доступе в интернете существует множество программных проектов, посвященных решению проблем проектирования на основе каркасов. Недостатками существующих реализаций является:
- слишком сильная зависимость от платформ сторонних разработчиков;
- невозможность изменения логики обработки сообщений;
- склонность сторонних разработчиков привязывать свою платформу к определенной технологии.
Каждая отдельная форма интерфейса соответствует конкретной задаче, а переходы между формами поддерживаются за счет пересылки сообщений.
Предпочтительная структура программного каркаса состоит из:
1. центрального обработчик сообщений, имеющего в своем составе сопоставления типов сообщений и частей интерфейса;
2. единого программного интерфейса (или базового класса) для реализации сообщений;
3. программного интерфейса для страниц.
Центральный обработчик в одновременно может являться генератором пользовательского интерфейса. Фрагменты графического пользовательского интерфейса поделены на две категории: пользовательские фрагменты, на которых размещаются элементы управления, позволяющие решать пользовательские задачи, а также служебные фрагменты, присутствующие на любом окне информационной системы, такие как статусные сообщения, панель переходов между страницами.
Опыт проведенных работ по проектированию пользовательского интерфейса и разработке программного приложения дает возможность сформулировать следующие рекомендации относительно разработки сложных систем с использованием каркасного подхода (с соблюдением последовательности работ):
1. Выделить задачи, решаемые пользователями;
2. Составить карту возможных переходов между задачами и выделить информационные потоки, перемещающиеся между этими задачами;
3. Выбрать вид основного графического элемента (далее - ОЭ), способного встраивать в себя другие элементы;
4. Определить служебные части фрагментов пользовательского интерфейса, такие как строка состояния, меню;
5. Создать набор пользовательских фрагментов интерфейса, каждый из которых отвечает за реализацию отдельной пользовательской задачи.
Состав единого программного интерфейса, от которого унаследованы все пользовательские фрагменты интерфейса, включает в себя:
1. Метод обработки поступившего сообщения.
2. Ссылка на обработчик сообщений.
3. Ссылка на сам графический элемент, который может быть встроен в другие элементы управления.
4. Создать набор сообщений в виде отдельных классов, унаследованных от единого программного интерфейса сообщений, содержащего тип сообщения.
5. Создать класс-обработчик сообщений, содержащий:
- Метод создания нового фрагмента интерфейса(далее МСФ), соединяющий служебные и пользовательские части графического интерфейса;
- Методы встраивания и удаления фрагментов(далее МВУ) из ОЭ;
- Словарь соответствия типов (далее СТ) сообщений методам создания пользовательского интерфейса или классам (зависит от возможностей конкретной платформы) элементов пользовательского интерфейса;
- Метод обработки сообщения, использующий СТ, МСФ и МВУ для открытия нового или существующего окна. Во фрагмент интерфейса, найденного в СТ, передается полученное сообщение;
6. В выбранной платформе реализации создать ОЭ, присоединить новый экземпляр обработчика сообщений. На данном этапе программный каркас можно считать готовым к дальнейшей настройке и разработке.
Для расширения информационной системы следует выполнить следующие шаги:
1. Создать новые сообщения.
2. Создать новый пользовательский фрагмент интерфейса.
3. Внести в СТ привязку новых фрагментов интерфейса к типами сообщений.
Основным преимуществом предлагаемого программного каркаса является его расширяемость и гибкость в случае внесения изменений. Данные рекомендации могут быть изменены для добавления разрабатываемой системе дополнительных возможностей, таких как навигация между открытыми окнами, авторизация пользователей, персонализация, ведение журнала событий в системе. К ограничениям разработанного подхода относятся следующие требования к языку и среде реализации: - Поддержка наследования классов.
- Поддержка наследования интерфейсов.
- Наличие возможности динамического конструирования графического пользовательского интерфейса.
Список литературы:
1. Jacob Gube «40+ Helpful Resources On User Interface Design Patterns» [Электронный ресурс]. - Режим доступа: www.smashingmagazine.com/2009/ 06/15/40-helpful-resources-on-user-interface-design-patterns.
2. Jeff Atwood «Dependency Avoidance» [Электронный ресурс]. - Режим доступа: www.codinghorror.com/blog/2006/01/dependency-avoidance.html.
3. Theresa Neil «12 Standard Screen Patterns» [Электронный ресурс]. -Режим доступа: http://designingwebinterfaces.com/designing-web-interfaces-12-screen-patterns.
4. Model-view-controller. (2011, September 30). In Wikipedia, The Free Encyclopedia [Электронный ресурс]. - Режим доступа: http://en.wikipedia.org/ wiki/Model%E2%80%93view%E2%80%93controller.
5. Ахтырченко К.В., Сорокваша Т.П. Методы и технологии реинжиниринга ИС [Электронный ресурс]. - Режим доступа: http://citforum.ru/SE/ project/isr.
6. Петросян В.С. Методы межкомпонентного взаимодействия в объектно-ориентированных каркасах приложений [Электронный ресурс]. -Режим доступа: http://arxiv.org/pdf/cs/0603033.
7. MSDN Modular Application Development (Chapter 4) [Электронный ресурс]. - Режим доступа: http://msdn.microsoft.com/en-us/library/gg405479 (v=PandP.40).aspx.
8. Товб А.С., Г.Л. Ципес. Управление проектами: Стандарты, методы, опыт. - М.: ЗАО «Олимп-Бизнес», 2003.
9. Лукин В.В., Лукин В.Н. Компонентно-каркасный подход к разработке программного обеспечения // Моделирование и анализ данных. - 2011.
10. Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. Проектирование информационных систем. Курс лекций. Учебное пособие / Интернет-университет ИТ. - М., 2005.
11. Вендров А.М. Проектирование программного обеспечения экономических информационных систем. - М.: Финансы и статистика, 2000.
