path: root/tde-i18n-ru/docs/tdevelop/tdevelop/unixdev.docbook

<appendix id="unixdev">

<appendixinfo>
  <authorgroup>
    <author><firstname>Bernd</firstname><surname>Pol</surname></author>
    <!-- ROLES_OF_TRANSLATORS -->
  </authorgroup>
</appendixinfo>

<title>Разработка ПО в &UNIX;</title>

<indexterm zone="unixdev"><primary>разработка</primary></indexterm>
<indexterm zone="unixdev">
  <primary>&UNIX;</primary>
  <secondary>программирование</secondary></indexterm>

<sect1 id="history">
<title>Исторические замечания</title>

<indexterm zone="history"><primary>история</primary></indexterm>
<indexterm zone="history"><primary>языки сценариев</primary></indexterm>
<indexterm zone="history">
  <primary>&UNIX;</primary>
  <secondary>история</secondary></indexterm>
<indexterm zone="history">
  <primary>&UNIX;</primary>
  <secondary>конфейер</secondary></indexterm>
<indexterm zone="history">
  <primary>&UNIX;</primary>
  <secondary>оболочка</secondary></indexterm>
<indexterm zone="history">
  <primary>shell</primary>
  <secondary>&UNIX;</secondary></indexterm>

<para>С самого начала, программы в &UNIX; разделились на два разных типа. Один тип &mdash; это мир <emphasis>языков программирования системы и приложений</emphasis>, где некоторый исходный код транслируется в машинный транслирующей программой, <emphasis>компилятором</emphasis> или <emphasis>интерпретатором</emphasis>. Примером является язык программирования C. &UNIX; была первой ОС, написанной на таком языке высокого уровня (относительно), вместо ассемблера, ориентированного на конкретную машину (на самом деле одним из изначальных назначений языка C было написание ядра &UNIX; и вспомогательных программ на машинах DEC PDP-11). </para>
<para>Второй тип &mdash; это мир <emphasis>сценариев</emphasis> (скриптов). Он развился с приходом оболочки &UNIX; (shell), которая являлась интерфейсом пользователя к ОС &mdash; и в то же время языком программирования очень высокого уровня. Сценарии используют набор маленьких утилит, таких как <command>grep</command>, <command>sed</command> и <command>find</command>, каждая из которых создана для конкретной задачи. Хитрость заключается в том, что любая такая программа может быть соединена с другой посредством простого транспортного механизма, который называется <emphasis>конвейером</emphasis>, суть его заключается в том, что он перенаправляет вывод одной программы на ввод другой. Это есть основа многофункциональности и гибкости инструмента. </para>
<para>С течением времени, оба мира бурно развивались. Язык C до сих пор используется преимущественно в качестве системного язык программирования, тогда как C++ &mdash; дальнейшее развитие C, воплощающее объектно-ориентированную модель программирования, &mdash; с начала 90-ых используется при программировании сложных структурированных систем. Кроме того, осталась поддержка многих других языков программирования, даже таких, как FORTRAN77 и Ada, которые всё ещё используются в некоторых областях. </para>
</sect1> <!-- history -->

<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->

<sect1 id="unixdev-scripting-languages">
<title>Современные языки сценариев</title>
<para>Ну, а в мире сценариев произошла перестановка, от оболочки, недостатком которой было отсутствие полной переносимости, до языков, которые унифицируют всю общую необходимую функциональность в своих стандартных библиотеках, оставляя возможность прибегать к конвейерному механизму. </para>
<para>Общее всех этих сценарных языков &mdash; их переносимость между клонами &UNIX;, Microsoft &Windows;, &MacOS;, или даже VMS. Также, для всех их доступны свободно распространяемые реализации. </para>

<sect2 id="unixdev-SL-Perl">
<title>&perl;</title>

<indexterm zone="unixdev-SL-Perl"><primary>Perl</primary></indexterm>
<indexterm zone="unixdev-SL-Perl">
  <primary>языки сценариев</primary>
  <secondary>Perl</secondary></indexterm>

<para><ulink url="http://www.perl.com">&perl;</ulink> популярен как язык обработки текста и, следовательно, системного администрирования. На заре World Wide Web, CGI-скрипты на &perl; использовались для генерирования динамических web-страниц на основе базы данных. Сегодня такой метод реализован в виде модуля <command>mod_perl</command> web-сервера &apache;. Среди сильных сторон &perl;'а &mdash; его встроенная поддержка расширенных регулярных выражений и богатый архив свободных модулей к нему, для подробностей см.: <ulink url="http://cpan.org">Comprehensive Perl Archive Network (CPAN)</ulink>. </para>
 
</sect2> <!-- unixdev-SL-Perl -->

<sect2 id="unixdev-SL-Python">
<title>Python</title>

<indexterm zone="unixdev-SL-Python"><primary>Python</primary></indexterm>
<indexterm zone="unixdev-SL-Python">
  <primary>языки сценариев</primary>
  <secondary>Python</secondary></indexterm>

<para><ulink url="http://www.python.org">&python;</ulink> отличается элегантностью классовой системы, лёгкостью и гибкостью, с которой можно внешние библиотеки могут быть подключены &mdash; к ним можно обращаться как к стандартным классам и функциям &python;. В отличие от &perl;, &python; имеет прозрачный и сконцентрированный встроенный &API;, что делает его прекрасным средством поддержки сценариев для программ, написанных на C и C++, . </para>
</sect2> <!-- unixdev-SL-Python -->

<sect2 id="unixdev-SL-PHP">
<title>PHP</title>

<indexterm zone="unixdev-SL-PHP"><primary>PHP</primary></indexterm>
<indexterm zone="unixdev-SL-PHP">
  <primary>языки сценариев</primary>
  <secondary>PHP</secondary></indexterm>

<para><ulink url="http://www.php.net">&php;</ulink> встраивается прямо в &HTML;-страницы, и, следовательно, применяется для генерирования динамических web-страниц. </para>
</sect2> <!-- unixdev-SL-PHP -->
</sect1> <!-- unixdev-scripting-languages -->

<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<sect1 id="unixdev-hl-script">
<title>Высокоуровневые сценарии</title>

<para>Высокоуровневые приложения обычно более медлительные и не так гибки в применении. Это проявляется в мире программ с графическим пользовательским интерфейсом (GUI), таких как &kde;. </para>
<para>Потребность в некоем подобии конвейеров низкоуровневых консольных программ для высокоуровневых приложений привела к появлению <link linkend="unixdev-corba">CORBA</link> и, позже в среде &kde;, <link linkend="unixdev-dcop">&DCOP;</link>. </para>

<sect2 id="unixdev-corba">
<title>Протокол CORBA</title>

<indexterm zone="unixdev-corba"><primary>CORBA</primary></indexterm>
<indexterm zone="unixdev-corba">
  <primary>языки сценариев</primary>
  <secondary>CORBA</secondary></indexterm>
<indexterm zone="unixdev-corba">
  <primary>связь</primary>
  <secondary>CORBA</secondary></indexterm>

<para><ulink url="http://www.omg.org/gettingstarted/corbafaq.htm">CORBA</ulink> (<emphasis>Common Object Request Broker Architecture</emphasis>) - это механизм, позволяющий разным программам работать совместно через сеть. Он разработан комитетом стандартов <ulink url="http://www.omg.org">OMG</ulink> (Object Management Group). </para>
<para>Программы, поддерживающие CORBA, используют протокол IIOP для связи. Реализации, основанные на IIOP, есть для многих операционных систем, языков программирования, и сетей, что делает его хорошо переносимым. </para>
<para>Основной недостаток CORBA - это его очень низкая скорость. Возможно это не так существенно. в сетях с мощными серверами, но на обычных компьютерах, для которых предназначен &kde;, это является главным. </para>

</sect2> <!-- unixdev-corba -->

<sect2 id="unixdev-dcop">
<title>Интерфейс &DCOP;</title>

<indexterm zone="unixdev-dcop"><primary>DCOP</primary></indexterm>
<indexterm zone="unixdev-dcop">
  <primary>языки сценариев</primary>
  <secondary>DCOP</secondary></indexterm>
<indexterm zone="unixdev-dcop">
  <primary>связь</primary>
  <secondary>DCOP</secondary></indexterm>

<para>Протокол <ulink url="http://developer.kde.org/documentation/library/kdeqt/dcop.html"><emphasis>DCOP</emphasis></ulink> разработан для связи и более тесной интеграции между приложениями &kde;, т.к. использование медленного CORBA, имеющего ряд ограничений, привело бы к всеобщей "неподъёмности" &kde; на обычных компьютерах. </para>
<para>&DCOP; расшифровывается как <emphasis>Desktop COmmuniсation Protocol</emphasis> (протокол связи рабочих станций). Он реализован как простой механизм IPC/RPC, построенный для оперирования сокетами. Словом, он обеспечивает удобства схожие с традиционным конвейерным механизмом &UNIX;. </para>
<para>Традиционные сценарии основываются на очень маленьких программах, которые были созданы для работы на строго текстовой основе. &DCOP; позволяет графическим программам связываться между собой схожим путём. Т.е. одна &kde;-программа может посылать сообщения другой (возможно своей копии), и сама получать и обрабатывать данные от неё. </para>
<para>Однако у такого метода всё же есть и недостатки &mdash; для использования &DCOP; в программу нужно встроить специальный код интерфейса &DCOP;. Кроме того, связь происходит несколько медленно (но значительно быстрее CORBA), хотя, в свою очередь, она даёт мощь и гибкость сценариев &UNIX; высокоуровневым программам с графическим пользовательским интерфейсом. </para>
<para>Для подробностей см. <ulink url="http://developer.kde.org/documentation/library/kdeqt/dcop.html">DCOP: Desktop COmmunications Protocol</ulink> или <ulink url="developer.kde.org/documentation/library/cvs-api/dcop/html/index.html"> &API;-справочник библиотеки &DCOP;</ulink>. </para>
</sect2> <!--  unixdev-dcop -->

</sect1> <!--  unixdev-hl-script -->

<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->

<sect1 id="unixdev-buildsystems">
<title>Системы сборки</title>

<para>Кроме самых простых случаев, ваш проект будет состоять из множества блоков исходного кода, разделённых по нескольким файлам для удобства сопровождения. Для преобразования исходного кода в машинный, нужно транслировать всё это в несколько машинных модулей в удобном для чтения операционной системой формате. </para>
<para>Для этого как минимум требуется <itemizedlist>
  <listitem><para><emphasis>текстовый редактор</emphasis> &mdash; для написания исходного кода, </para></listitem>
  <listitem><para>транслирующая программа, обычно это <emphasis>компилятор</emphasis>, &mdash; для преобразования исходного кода в объектные файлы, </para></listitem>
  <listitem><para><emphasis>библиотекарь</emphasis> &mdash; для сборки объектных файлов в библиотеки для последующего их использования без необходимости перекомпилирования, </para></listitem>
  <listitem><para><emphasis>компоновщик</emphasis> &mdash; связки нескольких объектных файлов и библиотек в один исполнимый файл, </para></listitem>
  <listitem><para><emphasis>система сборки</emphasis>, претендующая на управление всем этим "добром", и </para></listitem>
  <listitem><para><emphasis>отладчик</emphasis> &mdash; чтобы найти (надеемся) все ошибки в исходных кодах, и, возможно, другие диагностические утилиты для последующей оптимизации кода. </para></listitem>
</itemizedlist>
</para>

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

<sect2 id="unixdev-buildsystems-make">
<title>Процесс сборки</title>

<indexterm zone="unixdev-buildsystems-make">
  <primary>make</primary></indexterm>
<indexterm zone="unixdev-buildsystems-make">
  <primary>Makefile</primary></indexterm>
<indexterm zone="unixdev-buildsystems-make">
  <primary>правило</primary></indexterm>
<indexterm zone="unixdev-buildsystems-make">
  <primary>перекомпиляция</primary></indexterm>
<indexterm zone="unixdev-buildsystems-make">
  <primary>target (целевой)</primary></indexterm>
<indexterm zone="unixdev-buildsystems-make">
  <primary>зависимости</primary></indexterm>
<indexterm zone="unixdev-buildsystems-make">
  <primary>команды</primary></indexterm>

<para>Инструмент, выполняющий перекомпиляцию называется <command>make</command>. Его работа управляется специальными <emphasis>правилами</emphasis>, которые описывают необходимые действия в случае изменения определённой информации (обычно объектного файла или файла исходного кода). Все правила, принадлежащие определённому проекту записываются в т.н. <filename>Makefile</filename>, который обрабатывается  командой <command>make</command> в любое время когда вы хотите обновить вашу работу. </para>
<para>Каждое правило состоит из нескольких сборочных блоков, а именно <itemizedlist>
  <listitem><para><emphasis>целевого</emphasis>(<emphasis>target</emphasis>), т.е. файла, который нужно собрать </para></listitem>
  <listitem><para>набора <emphasis>зависимостей</emphasis>, обычно это имена файлов, от которых зависит целевой (target), например это может быть имя исходного файла, где целевой будет упомянут как объектный, </para></listitem>
  <listitem><para><emphasis>команд</emphasis>, которые выполняются для <quote>сборки</quote> целевого файла (например его компиляции или компоновки нескольких объектных файлов). </para></listitem>
</itemizedlist>
</para>
<para>Обычно команда <command>make</command> читает правила, одно за другим, проверяет каждый файл из списка зависимостей конечного файла и собирает его заново если хотя бы один файл из списка зависимостей был изменён. </para>
<para>В больших проектах <filename>Makefile</filename> может стать очень большим и сложным. Мы не можем здесь углубляться в подробности, однако рекомендуем вам изучить хотя бы основы синтаксиса <command>make</command>. Даже если вы не используете его напрямую, понимание принципов системы сборки вам должно пригодиться. Для подробностей см. <ulink url="info://make/Top"> <quote>GNU Make Manual</quote></ulink>. </para>
<para>Для подробностей, касающихся &tdevelop;, см. главу <link linkend="project-management">Сборка и управление проектом</link>. </para>
<para>Доступно несколько руководств, см. в главе <link linkend="automake-references">Сборка и управление проектом</link>. </para>
</sect2> <!-- unixdev-buildsystems-make -->

</sect1> <!-- unixdev-buildsystems -->

<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->

<sect1 id="unixdev-guidevelopment">
<title>Объектно-ориентированное программирование</title>

<indexterm zone="unixdev-guidevelopment">
  <primary>GUI</primary></indexterm>
<indexterm zone="unixdev-guidevelopment">
  <primary>графический пользовательский интерфейс</primary></indexterm>
<indexterm zone="unixdev-guidevelopment">
  <primary>пользовательский интерфейс</primary>
  <secondary>GUI</secondary></indexterm>

<para>Разработчики программного обеспечения вынуждены создавать не только библиотеки и алгоритмы, но и удобный пользовательский интерфейс, гибкий и интуитивный. Однако большинство программистов не удаляют этому большого внимания, и, как результат, хорошие программы имеют <ulink url="http://www.rha.com/ui_hall_of_shame.htm">бедный дизайн</ulink>. </para>
<para>На протяжении годов, были выработаны некоторые общие принципы реализации интерфейса. Настоятельно рекомендуется придерживаться их. Таким образом ваши пользовательские интерфейсы будут сохранять общий вид и интуитивность, что непременно будет оценено пользователями. </para>
<para>Визуальная разработка &kde; также имеет свои принципы. Их можно найти на <ulink url="http://developer.kde.org/documentation/standards/kde/style/basics/index.html">странице принципов дизайна пользовательского интерфейса</ulink> в уголке разработчика &kde;. </para>
<para>Краткое введение в дизайн графического пользовательского интерфейса можно найти <ulink url="http://axp16.iie.org.mx/Monitor/v01n03/ar_ihc2.htm">здесь</ulink>, либо <ulink url="http://russian.joelonsoftware.com/">здесь</ulink> (больший уклон в сторону умирающей ОС). </para>

</sect1> <!-- unixdev-guidevelopment -->

<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->

<sect1 id="unixdev-ide">
<title>Концепции и средства интегрирования: IDE</title>

<indexterm zone="unixdev-ide">
  <primary>IDE</primary></indexterm>
<indexterm zone="unixdev-ide">
  <primary>интегрированная среда разработки</primary></indexterm>
<indexterm zone="unixdev-ide">
  <primary>разработка</primary>
  <secondary>IDE</secondary></indexterm>
<indexterm zone="unixdev-ide">
  <primary>окружение</primary>
  <secondary>IDE</secondary></indexterm>

<para>Для каждого этапа процесса программирования существует множество отдельных инструментов &mdash; планирование, редактирование, управление файлами и компилирование (сборка), отладка, документирование и т.д. Однако по мере роста проекта, он (почти всегда) становится громоздким, и процесс его дальнейшего программирования становится затруднительным. </para>
<para>Наиболее повторяющаяся работа проделывается при проектировании, компилировании и отладке программы. Большую часть такой работы можно автоматизировать используя шаблоны и сценарии. Другую большую часть &mdash; наличием инструментов. способных связываться один с другим через общий визуальный интерфейс (GUI). </para>
<para>К примеру, действительно удобно, когда отладчик может открыть исходный код в редакторе и расположить курсор в месте, где произошла ошибка. </para>
<para>Такую схему совершенствуют <emphasis>интегрированные среды разработки</emphasis> (&IDE;). Они собирают воедино все шаблоны, инструменты и сценарии, необходимые для продуктивного процесса разработки. </para>
<para>Для всевозрастающей платформы &kde; таким &IDE; является &tdevelop;. Эта среда разработки содержит широкий набор инструментов, обеспечивая простое окружение разработки и сопровождения ПО, использующего разные языки программирования и платформы. </para>

<sect2 id="unixdev-ide-tdevelop">
<title>Основные возможности &tdevelop; &kdevrelease;</title>

<indexterm zone="unixdev-ide-tdevelop">
  <primary>&tdevelop;</primary>
  <secondary>возможности</secondary></indexterm>
<indexterm zone="unixdev-ide-tdevelop">
  <primary>возможности</primary></indexterm>

<!-- ### copied from web page, needs to be updated -->

<itemizedlist>
  <listitem>
  <para>Управление всеми <emphasis>средствами разработки</emphasis> на языке C++, такими как компилятор, компоновщик, отладчик и система сборки</para>
  </listitem>
  <listitem>
  <para><emphasis>Мастер приложений</emphasis>, упрощающий создание новых программ</para>
  </listitem>
  <listitem>
  <para><emphasis>Интегрированный редактор</emphasis>, основанный на редакторе &kwrite;, <application>QEditor</application> от Trolltec или другой.</para>
  </listitem>
  <listitem>
  <para><emphasis>Генератор классов</emphasis>, для создания новых классов и интегрирования их в проект</para>
  </listitem>
  <listitem>
  <para><emphasis>Управление</emphasis> исходными, заголовочными <emphasis>файлами</emphasis>, документацией и т.д.</para>
  </listitem>
  <listitem>
  <para>Помощь при <emphasis>написании руководства приложения</emphasis> средствами &kde;</para>
  </listitem>
  <listitem>
  <para>Автоматическое генерирование <emphasis>&API;-документации</emphasis> в формате &HTML;, включающей описания классов проекта и перечня используемых библиотек</para>
  </listitem>
  <listitem>
  <para><emphasis>Поддержка интернационализации</emphasis>, &kbabel;</para>
  </listitem>
  <listitem>
  <para>Поддержка управления проектом через <emphasis>систему управления версиями</emphasis> (например, &CVS;)</para>
  </listitem>
  <listitem>
  <para>Встроенный интерфейс к <emphasis>отладчику</emphasis>.</para>
  </listitem>
  <listitem>
  <para>Встроенный эмулятор <emphasis>консоли</emphasis>.</para>
  </listitem>
  <listitem>
  <para><emphasis>Синтаксическая подсветка</emphasis> в файлах исходного кода.</para>
  </listitem>
  <listitem>
  <para><emphasis>Автодополнение кода</emphasis> для переменных класса, его методов, аргументов функций и т.п.</para>
  </listitem>
  <listitem>
  <para><emphasis>Шаблоны для конкретных задач</emphasis> (написание модулей &kcontrol;, &konqueror;, апплетов &kicker;, TDEIO, а также стилей рабочего стола)</para>
  </listitem>
  <listitem>
  <para>Четыре <emphasis>дерева информации</emphasis>, для наглядного разделения исходных, заголовочных файлов, классов и документации, что позволяет отказаться от внешнего проводника</para>
  </listitem>
  <listitem>
  <para><emphasis>Кросс-компилирование</emphasis>, с возможностью указания разных компиляторов, их ключей, архитектуры процессора и т.п.</para>
  </listitem>
  <listitem>
  <para>Поддержка проектов <emphasis>Qt/Embedded</emphasis> (таких как Zaurus и iPAQ).</para>
  </listitem>
  <listitem>
  <para>Простота использования <emphasis>внешних программ</emphasis>, в виде добавления их в меню <guimenuitem>Сервис</guimenuitem>.</para>
  </listitem>
</itemizedlist>

</sect2> <!-- unixdev-ide-tdevelop -->

</sect1> <!-- unixdev-ide -->

</appendix> <!-- unixdev -->