Eclipse RCP. Файловый менеджер
1 Введение
Данный материал — это попытка рассказать о методологии разработки коммерческих профессиональных программ на основе личного опыта и предпочтений автора.
Автор не претендует на полное и единственно правильное освещение данной темы. Существует огромное количество технологий и методологий разработки. Можно долго спорить о преимуществах той или иной технологии, того или иного языка программирования. Все они имеют право на жизнь, а жизнь сама расставляет все по своим местам. Происходит автоматический селекционный отбор, неудачные и устаревшие решения вымирают как мамонты. В процессе профессиональной деятельности автору пришлось разрабатывать самое разнообразное программное обеспечение от заказных информационных систем до сетевых игрушек для мобильных телефонов. Да и языки программирования применялись разнообразные — от CLIPPER, C++ и Delphi до Java. По мере профессионального роста у автора многократно менялись взгляды как на процесс разработки ПО, так и на используемые языки программирования и среды разработки. Это был долгий путь, и хочется отметить, что автору больше всего по душе Java и Delphi. Причем, Delphi на данный момент используется для быстрого создания прототипов программ, так как по скорости "клепания" временных решений тягаться с ним довольно сложно. А так как заказчики часто сами не знают, чего хотят, приходится предлагать различные варианты. В ряде случаев эти прототипы перерастают в полнофункциональные продукты, так как ранее скептически настроенных по отношению к Delphi заказчиков вполне устраивает конечный результат. Ну, а что касается Java, то это не просто язык программирования — это огромный набор технологий для решения практически любых задач. Причем, в отличие от C++, написанный код является гораздо более читабильным. C++ имеет смысл применять лишь в приложениях, которые очень критичны к быстродействию.
Почему выбрана технология Eclipse RCP? Просто звезды так сошлись, или лучше скажем словами героя мультфильма: "Я хочу о нем поведать миру". Ну, а если серьезно, несколько лет назад автору посчастливилось разрабатывать проект по созданию специализированных редакторов грамматики для систем распознавания речи по заказу одной крупной зарубежной компании. Проект требовалось выполнить в виде набора подключаемых модулей к Eclipse IDE еще 2-й версии. В результате работы над этим проектом был приобретен опыт по быстрому созданию крупных модульных приложений. Автору пришлась по душе тщательная продуманность и удобство использования данной технологии. В результате того, что фирма IBM выделила Eclipse в свободный доступ, к данному проекту подключилось огромное количество разработчиков, которые быстро оценили открывшиеся возможности. Лояльная лицензия позволяет использовать код и среду разработки бесплатно, и при этом можно создавать закрытые коммерческие продукты. Но разработка расширений к среде разработки Eclipse IDE не удовлетворяла некоторых разработчиков. В результате предпринимались попытки использовать лишь часть предоставляемых модулей, чтобы не тащить в свои проекты ненужную функциональность. Начиная с 3-й версии Eclipse была переработана архитектура всей системы с целью максимального разделения модулей и взаимосвязи между ними. В результате этого уже в версии 3.1 появился реально работающий механизм построения собственных продуктов на основе модулей Eclipse. Минимальный комплект поставки Eclipse Rich Client Platform (RCP) модулей составляет 6-7 Мб в зависимости от ОС. Размер типового коммерческого продукта составляет порядка 20-30 Мб, при этом мы получаем автоматическую систему апгрейда продукта, подсистемы помощи, обучения, презентации, многоязыковой поддержки и множество других необходимых коммерческому продукту функций. Чтобы оценить, насколько эта технология удобна, надо просто попробовать создать небольшой тестовый проект и сделать для себя выводы. Стоит оно того или нет, каждый решает для себя сам. Конечно, можно создать и более "легкие" версии программ с использованием, например, графической библиотеки SWT или SWING для построения интерфейса пользователя. Но при этом вам придется заново создавать то, что уже есть в готовом оттестированном виде. Нет смысла заново изобретать велосипед. К сожалению, пока мало документации на русском языке, и автор пытается привлечь внимание тех, кто сейчас стоит перед выбором технологий для новых проектов. Сравнительно молодая технология Eclipse RCP за несколько лет обрела заслуженную популярность и признание в мире. Создано уже несколько десятков успешных коммерческих продуктов. По адресу сайт приведен список наиболее известных из них.
По сути, нам предоставляется унифицированный конструктор, собирая кубики которого, можно наращивать функциональность вашего приложения. Причем для решения большинства типовых задач разработки можно бесплатно использовать уже готовые кубики — в терминологии Eclipse это "подключаемые модули" (Plugins). Разрастание приложения больше не проблема, к тому же, разбиение на модули упрощает организацию командной разработки. Графический интерфейс построен с использованием графической библиотеки SWT, что делает конечные программы неотличимыми от других программ используемой ОС. Быстродействие таких приложений не вызывает нареканий. Пользователи даже и не догадываются, что это Java-приложение. Для любителей нестандартных интерфейсов предусмотрена возможность создания настраиваемых стилей, которые позволяют произвольно менять как внешний вид приложения, так и поведение составляющих его компонентов. Чтобы не писать об абстрактных вещах, попробуем создать небольшой полезный продукт. Так как автор многократно сталкивался с трудностями при работе с файлами в ОС Linux, то в качестве примера выбран файловый менеджер. Казалось бы, есть множество готовых решений, но привычка использовать двухпанельные файловые менеджеры дает о себе знать. Менеджер файлов Midnight Commander, хоть и является приемлемым решением, но на фоне современных графических систем навевает мысли о давно ушедших днях работы в командной строке времен DOS. Он больше подходит для системных администраторов, которые в большинстве случаев обходятся консолью и считают это верхом профессионализма. А универсальный файловый менеджер Konqueror, хоть и позволяет приемлемо работать, но есть несколько мелочей, которые сводят на нет всю его мощь.
2 Постановка задачи. Анализ
Постановка задачи является тем, что у заказчика обычно описывается кратким словом: "хочу". На практике вытягивание из заказчика этого "хочу" является одним из самых сложных и ответственных моментов при разработке ПО. Именно из-за некачественного анализа задачи затягиваются сроки разработки, увеличивается затратный бюджет проекта, и нередко проект терпит крах. Это обычно многократный процесс интервьюирования
представителей заказчика, результатом которого является примерный список основных требований, формирование эскизов экранов, прототипов разрабатываемого ПО и сценариев всех процессов выполняемых задач. Практически бесполезно, да порой и неэффективно, требовать у заказчика готового технического задания на разработку. Это обычно делается собственными аналитиками, цель которых — вытянуть из заказчика максимум информации и подготовить на утверждение систематизирующий всю собранную информацию документ. Даже если заказчик представляет такой документ, то следует провести данную работу до окончательного утверждения технического задания, так как заказчик иногда упускает некоторые важные мелочи, которые для него являются само собой разумеющимися, но неочевидными для разработчиков, которые не являются специалистами в данной предметной области. Хочется подчеркнуть, что интервьюирование должно проходить многократно, после обработки результатов предыдущих бесед. К очередной встрече с заказчиком надо тщательно готовиться. В конечном счете не должно быть недопонимания решаемой задачи, все нюансы должны быть обговорены. Несмотря на то, что при разработке современных систем используется многофазный итерационный метод разработки ПО, следует в обязательном порядке фиксировать состояние каждой фазы разработки соответствующими документами. В случае, если в процессе разработки будут выявлены новые требования, вы должны быть защищены с последующим пересмотром бюджета и сроков проекта. В противном случае вам грозит каждый раз переделывать проект в соответствии с новыми пожеланиями заказчика за те же деньги. И этот процесс может затянуться на неопределенно большой срок.
3 Предварительные требования
. Работа с файлами (просмотр, правка, копирование, перемещение, добавление и удаление).
. Прозрачная работа не только с локальной файловой системой, но и с виртуальными или удаленными файловыми системами. Должна быть возможность гибкой настройки поддерживаемых файловых систем (ftp, sftp и т. д.).
. Работа с архивами (упаковка, распаковка и просмотр).
. Работа в консоли для выполнения команд ОС вручную.
. Мультиплатформенность. Должны быть реализованы профили развертывания как минимум для ОС Linux и Windows.
. Многоязычность. В начальной версии должны быть предустановлены английский и русский языковые ресурсы.
. Открытая архитектура, позволяющая гибко добавлять дополнительные модули.
. Возможность просмотра web-ресурсов.
. Возможность работы как в режиме однопанельного проводника в стиле Windows Explorer, так и в режиме двухпанельного файлового менеджера в стиле Midnight Commander, Norton Commander, Total Commander и т.д.
Проект создается по свободной лицензии Eclipse Public License v 1.0 (EPL): сайт .
Информацию по текущему состоянию проекта можно получить по адресу: сайт .
Сергей Бердачук, berdachuk@berdaflex.com
Данный материал — это попытка рассказать о методологии разработки коммерческих профессиональных программ на основе личного опыта и предпочтений автора.
Автор не претендует на полное и единственно правильное освещение данной темы. Существует огромное количество технологий и методологий разработки. Можно долго спорить о преимуществах той или иной технологии, того или иного языка программирования. Все они имеют право на жизнь, а жизнь сама расставляет все по своим местам. Происходит автоматический селекционный отбор, неудачные и устаревшие решения вымирают как мамонты. В процессе профессиональной деятельности автору пришлось разрабатывать самое разнообразное программное обеспечение от заказных информационных систем до сетевых игрушек для мобильных телефонов. Да и языки программирования применялись разнообразные — от CLIPPER, C++ и Delphi до Java. По мере профессионального роста у автора многократно менялись взгляды как на процесс разработки ПО, так и на используемые языки программирования и среды разработки. Это был долгий путь, и хочется отметить, что автору больше всего по душе Java и Delphi. Причем, Delphi на данный момент используется для быстрого создания прототипов программ, так как по скорости "клепания" временных решений тягаться с ним довольно сложно. А так как заказчики часто сами не знают, чего хотят, приходится предлагать различные варианты. В ряде случаев эти прототипы перерастают в полнофункциональные продукты, так как ранее скептически настроенных по отношению к Delphi заказчиков вполне устраивает конечный результат. Ну, а что касается Java, то это не просто язык программирования — это огромный набор технологий для решения практически любых задач. Причем, в отличие от C++, написанный код является гораздо более читабильным. C++ имеет смысл применять лишь в приложениях, которые очень критичны к быстродействию.
По сути, нам предоставляется унифицированный конструктор, собирая кубики которого, можно наращивать функциональность вашего приложения. Причем для решения большинства типовых задач разработки можно бесплатно использовать уже готовые кубики — в терминологии Eclipse это "подключаемые модули" (Plugins). Разрастание приложения больше не проблема, к тому же, разбиение на модули упрощает организацию командной разработки. Графический интерфейс построен с использованием графической библиотеки SWT, что делает конечные программы неотличимыми от других программ используемой ОС. Быстродействие таких приложений не вызывает нареканий. Пользователи даже и не догадываются, что это Java-приложение. Для любителей нестандартных интерфейсов предусмотрена возможность создания настраиваемых стилей, которые позволяют произвольно менять как внешний вид приложения, так и поведение составляющих его компонентов. Чтобы не писать об абстрактных вещах, попробуем создать небольшой полезный продукт. Так как автор многократно сталкивался с трудностями при работе с файлами в ОС Linux, то в качестве примера выбран файловый менеджер. Казалось бы, есть множество готовых решений, но привычка использовать двухпанельные файловые менеджеры дает о себе знать. Менеджер файлов Midnight Commander, хоть и является приемлемым решением, но на фоне современных графических систем навевает мысли о давно ушедших днях работы в командной строке времен DOS. Он больше подходит для системных администраторов, которые в большинстве случаев обходятся консолью и считают это верхом профессионализма. А универсальный файловый менеджер Konqueror, хоть и позволяет приемлемо работать, но есть несколько мелочей, которые сводят на нет всю его мощь.
2 Постановка задачи. Анализ
Постановка задачи является тем, что у заказчика обычно описывается кратким словом: "хочу". На практике вытягивание из заказчика этого "хочу" является одним из самых сложных и ответственных моментов при разработке ПО. Именно из-за некачественного анализа задачи затягиваются сроки разработки, увеличивается затратный бюджет проекта, и нередко проект терпит крах. Это обычно многократный процесс интервьюирования
представителей заказчика, результатом которого является примерный список основных требований, формирование эскизов экранов, прототипов разрабатываемого ПО и сценариев всех процессов выполняемых задач. Практически бесполезно, да порой и неэффективно, требовать у заказчика готового технического задания на разработку. Это обычно делается собственными аналитиками, цель которых — вытянуть из заказчика максимум информации и подготовить на утверждение систематизирующий всю собранную информацию документ. Даже если заказчик представляет такой документ, то следует провести данную работу до окончательного утверждения технического задания, так как заказчик иногда упускает некоторые важные мелочи, которые для него являются само собой разумеющимися, но неочевидными для разработчиков, которые не являются специалистами в данной предметной области. Хочется подчеркнуть, что интервьюирование должно проходить многократно, после обработки результатов предыдущих бесед. К очередной встрече с заказчиком надо тщательно готовиться. В конечном счете не должно быть недопонимания решаемой задачи, все нюансы должны быть обговорены. Несмотря на то, что при разработке современных систем используется многофазный итерационный метод разработки ПО, следует в обязательном порядке фиксировать состояние каждой фазы разработки соответствующими документами. В случае, если в процессе разработки будут выявлены новые требования, вы должны быть защищены с последующим пересмотром бюджета и сроков проекта. В противном случае вам грозит каждый раз переделывать проект в соответствии с новыми пожеланиями заказчика за те же деньги. И этот процесс может затянуться на неопределенно большой срок.
3 Предварительные требования
. Работа с файлами (просмотр, правка, копирование, перемещение, добавление и удаление).
. Прозрачная работа не только с локальной файловой системой, но и с виртуальными или удаленными файловыми системами. Должна быть возможность гибкой настройки поддерживаемых файловых систем (ftp, sftp и т. д.).
. Работа с архивами (упаковка, распаковка и просмотр).
. Работа в консоли для выполнения команд ОС вручную.
. Мультиплатформенность. Должны быть реализованы профили развертывания как минимум для ОС Linux и Windows.
. Многоязычность. В начальной версии должны быть предустановлены английский и русский языковые ресурсы.
. Открытая архитектура, позволяющая гибко добавлять дополнительные модули.
. Возможность просмотра web-ресурсов.
. Возможность работы как в режиме однопанельного проводника в стиле Windows Explorer, так и в режиме двухпанельного файлового менеджера в стиле Midnight Commander, Norton Commander, Total Commander и т.д.
Проект создается по свободной лицензии Eclipse Public License v 1.0 (EPL): сайт .
Информацию по текущему состоянию проекта можно получить по адресу: сайт .
Сергей Бердачук, berdachuk@berdaflex.com
Компьютерная газета. Статья была опубликована в номере 11 за 2006 год в рубрике программирование
