Справочник и примеры языка PHP

         

Справочник и примеры языка PHP

PHP: Hypertext Preprocessor — «PHP: препроцессор гипертекста»; первоначально Personal Home Page Tools — «Инструменты для создания персональных веб-страниц»; — скриптовый язык программирования общего назначения, интенсивно применяемый для разработки веб-приложений. В настоящее время поддерживается подавляющим большинством хостинг-провайдеров и является одним из лидеров среди языков программирования, применяющихся для создания динамических веб-сайтов.
Язык и его интерпретатор разрабатываются группой энтузиастов в рамках проекта с открытым кодом. Проект распространяется под собственной лицензией, несовместимой с GNU GPL.
В области веб программирование, частности серверная часть, PHP — один из популярных сценарных языков (наряду с JSP, Perl и языками, используемыми в ASP.NET) благодаря своей простоте, скорости выполнения, богатой функциональности, кроссплатформенности и распространению исходных кодов на основе лицензии PHP.
Популярность в области построения веб-сайтов определяется наличием большого набора встроенных средств для разработки веб-приложений. Основные из них:
автоматическое извлечение POST и GET-параметров, а также переменных окружения веб-сервера в предопределённые массивы;
взаимодействие с большим количеством различных систем управления базами данных (MySQL, MySQLi, SQLite, PostgreSQL, Oracle (OCI8), Oracle, Microsoft SQL Server, Sybase, ODBC, mSQL, IBM DB2, Cloudscape и Apache Derby, Informix, Ovrimos SQL, Lotus Notes, DB++, DBM, dBase, DBX, FrontBase, FilePro, Ingres II, SESAM, Firebird / InterBase, Paradox File Access, MaxDB, Интерфейс PDO);
автоматизированная отправка HTTP-заголовков;
работа с HTTP-авторизацией;
работа с cookies и сессиями;
работа с локальными и удалёнными файлами, сокетами;
обработка файлов, загружаемых на сервер;
работа с XForms.
В настоящее время PHP используется сотнями тысяч разработчиков. Согласно рейтингу корпорации TIOBE, базирующемся на данных поисковых систем, в июне 2013 года PHP находился на 5 месте среди языков программирования.К крупнейшим сайтам, использующим PHP, относятся Facebook, Wikipedia и др.
Входит в LAMP — распространённый набор программного обеспечения для создания и хостинга веб-сайтов (Linux, Apache, MySQL, PHP).
Хотя PHP и не слишком распространён в данном качестве, его можно использовать и для создания GUI-приложений.
Для создания кроссплатформенных приложений служат пакеты PHP-GTK и PHP-Qt, представляющие собой обёртки для соответствующих популярных библиотек виджетов.
Для создания графических приложений для Windows существуют свободный пакет WinBinder (написан на Си, фактически — обёртка для WinAPI).
Также существует реализация PHP для .NET/Mono — Phalanger, результатом компиляции PHP-кода в Phalanger может быть любое .NET-приложение, будь то серверное или настольное.

Справочник по PHP и Lite PHP
Здесь вы найдете краткое справочное руководство по РНР. Список приведенных функций относится к РНР 3. Описаны те функции, которые работают с MySQL и mSQL, но пропущены функции для работы с другими серверами баз данных, такими как Ababas D, dbm, Oracle и PostgreSQL.

Справочник по PHP и Lite PHP (продолжение)

MySQL С API
MySQL С API кроме стандартных типов данных языка С использует некоторые свои типы данных. Они определены в заголовочном файле 'mysql.h', который необходимо подключать при компиляции всех программ, использующих библиотеку MySQL.

Справочник по Perl
В вашей системе должны быть установлены работающие экземпляры Perl 5. Ко времени написания этой книги последний релиз Perl имел номер 5.005_02. Следует пользоваться по меньшей мере Perl 5.004, поскольку в более ранних версиях были ошибки, связанные с защитой.

Введение в программирование на PHP5

Сегодня создание страницы Web является не слишком трудной задачей. Многие стандартные программные пакеты персональных компьютеров обладают встроенными средствами для преобразования документов текстовых процессоров, электронных таблиц, баз данных и т.д. в специально кодированные документы, которые могут быть доступны в Web. Специальные пакеты для создания страниц Web, такие, как Microsoft FrontPage и Macromedia Dreamweaver, позволяют легко создавать страницы Web с помощью технологии буксировки. В большинстве таких случаев даже не нужно знать о существовании специального языка кодирования HTML (язык разметки гипертекста), который неявно все это обеспечивает.

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

Соединение XHTML и PHP
Код PHP обычно объединяется с тегами XHTML. PHP является встраиваемым языком — это означает, что можно перемещаться между чистым кодом HTML и PHP, не жертвуя возможностью чтения текста.

Скалярные переменные
Переменные являются временным местом хранения, используемым для представления значений в сценарии PHP. В PHP имеется два основных типа переменных: скалярные и массивы. Скалярные переменные содержат только одно значение в данный момент времени, а переменные массивы — список значений. Переменные массивы обсуждаются в следующем разделе

Оператор If
При создании кода часто требуется выполнять различные действия на основе некоторого выбора. В PHP это можно делать с помощью условных операторов – оператора if, оператора if … else и оператора elseif. if – этот оператор используется для выполнения блока кода, когда выполняется условие (true).

Циклы while
В программировании часто необходимо повторить один и тот же блок кода несколько раз. Это можно реализовать с помощью операторов цикла. Язык PHP содержит несколько типов операторов цикла. Данный раздел рассматривает цикл while.

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

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

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

Доступ ODBC
PHP обеспечивает поддержку ODBC (Open DataBase Connectivity), что позволяет обращаться к любой совместимой с ODBC системе управления базами данных (СУБД), если в системе или сети доступно Имя источника данных (DSN — Data Source Name) или доступна строка соединения без DSN. Это включает доступ к таким реляционным базам данных, как Oracle, DB2, MS SQL Server, MySQL, и MS Access.

Доступ к MySQL
База данных MySQL® стала самой популярной в мире базой данных с открытым исходным кодом — благодаря ее высокой производительности, надежности и легкости использования. Существует более 6 миллионов установок этой базы данных, начиная от больших корпораций и до специализированных встроенных приложений.

Открытие файлов
PHP предоставляет доступ к файлам в операционных системах Windows и Unix для чтения, записи или добавления содержимого. Этот раздел описывает, как использовать PHP для открытия файлов в системах Windows.

Сайт e-Commerce
В данном разделе последовательно рассматривается процесс разработки коммерческого сайта Web. В качестве примера используется база данных товаров eCommerce.mdb. Товары будут предложены для онлайн торговли. С помощью этого примера будут рассмотрены все основные вопросы разработки онлайн магазина. Следующая иллюстрация представляет страницы и механизмы связей, которые составляют типичный сайт е-коммерции.

Использование оператора SQL UPDATE
Использованный выше оператор SQL UPDATE имеют следующую общую форму: UPDATE TableName SET FieldName1 = expression1 [,FieldName2 = expression2] ... где TableName является именем таблицы, а FieldName указывает на поле таблицы, в которой происходит обновление. Выражения (expression1,...) могут быть одиночными значениями или арифметическими выражениями, создающими значение.

Оператор SELECT
Системы управления базами данных предоставляют для работы с информацией в базе данных язык структурированных запросов SQL. При использовании SQL всю работу выполняет система управления базой данных. Вместо программирования серверных сценариев для доступа к таблицам или для обслуживания данных в базе данных, можно передать эту работу СУБД.

Самоучитель по введению в экспертные системы

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

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

Что такое экспертная система?
Устав от безнадежных попыток, вы набираете номер сервисной службы поддержки пользователей. И только после этого фортуна поворачивается к вам лицом — на помощь приходит человек, который знает, о чем говорит. Он советует вам выбросить с полдюжины устаревших DLL-модулей в системном каталоге и вновь переустановить программу. Последовав его совету, вы.уже через десяток минут можете нормально работать, и подскочившее недавно кровяное давление вновь возвращается к норме.

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

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

Системы, основанные на знаниях
В области искусственного интеллекта и в современной психологии утверждение, что разумное поведение направляется правилами, превратилось уже в аксиому. Даже в "большом" мире люди склонны связывать уровень интеллектуальности со следованием правилам, и мы все чаще при объяснении разумности обращаем внимание на то, насколько при этом соблюдаются правила. Возьмем для примера манеру разговаривать на естественном языке. Мы все ведем себя так, как если бы обладали знанием всех правил того языка, на котором говорим, например английского, хотя, конечно, мы знаем далеко не все.

Ассоциативные сети и системы фреймов
В предыдущей главе уже отмечалось, что порождающие правила очень подходят для представления связей состояния некоторой проблемы с действиями, которые необходимо предпринять для продвижения к искомому решению. Однако иногда для решения проблемы больший интерес представляет не ответ на вопрос "Что делать, если...?", а свойства и взаимоотношения между сложными объектами в предметной области. Представлять знания о таких объектах и событиях и их взаимосвязях (таких как тип — подтип, часть — целое, до — после и т.д.) с помощью формальных правил далеко не всегда удобно.

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

Логическое программирование
Еще в конце 1970-х годов стала отчетливо просматриваться тенденция к использованию в исследованиях в области искусственного интеллекта "формальных" методов, т.е. основанных на аппарате математической логики. Эти методы противопоставлялись более интуитивным и менее формализованным эвристическим методам, скажем, таким, которые были использованы в системе MYCIN. Для того чтобы стало ясно, что все это значит, нужно познакомить вас с логическими языками, а затем показать, как соотносятся их свойства с теми методами рассуждений, которые должны поддерживать типовые экспертные системы.

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

Приобретение знаний
Термин приобретение знаний носит обобщенный характер и совершенно нейтрален к способу передачи знаний. Например, передача может осуществляться с помощью специальной программы, которая в процессе обработки большого массива историй болезни устанавливает связь между симптомами и заболеваниями. А вот термин извлечение знаний (knowledge elicitation) относится именно к одному из способов передачи знаний — опросу экспертов в определенной проблемной области, который выполняется аналитиком или инженером по знаниям.

Эвристическая классификация (II)
Сейчас мы продолжим начатый в предыдущей главе анализ различий между задачами классификации и конструирования. Но теперь основное внимание будет сосредоточено на методах решения проблем, включая и различные способы представления знаний и реализации машины логического вывода. В частности, мы подробно рассмотрим типы инструментальных программных средств, наиболее подходящих для разработки систем эвристической классификации, примеры использования эвристической классификации в экспертных системах, более современных, чем MYCIN и EMYCIN, и увидим, каким образом сказывается обладание знаниями об используемых методах решения проблем на работе автоматизированных систем извлечения знаний.

Эвристическая классификация (I)
В предыдущей главе мы уже упоминали о том, что базовые компоненты экспертных систем, хорошо зарекомендовавшие себя на практике (машина логического вывода и подсистема представления знаний), могут быть использованы для построения аналогичных систем для других областей приложения. Так, архитектура оболочки EMYCIN явилась результатом дальнейшего развития принципов, положенных в основу ранней и узкоспециализированной системы MYCIN.

Иерархическое построение и проверка гипотез
В данной главе будут рассмотрены три системы, реализующие комбинированный метод решения проблем, который получил в литературе наименование иерархического построения и проверки гипотез (hierarchical hypothesize and test). С методом эвристической классификации этот метод сходен в том, что в нем используется отображение множества абстрактных категорий данных на множество абстрактных категорий решений, но этот подход усложнен тем, что элементы решений могут комбинироваться и объединяться в составные гипотезы.


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

Решение проблем конструирования (II)
В предыдущей главе мы рассматривали экспертные системы для решения проблем конструирования, в которых по ходу процесса никогда не возникала необходимость отмены уже принятых решений. Однако такая стратегия подходит далеко не для всех задач конструирования, поскольку мы не всегда располагаем всеми необходимыми для этого знаниями о предметной области. В этой главе мы проанализируем применение двух стратегий — наименьшего принуждения (least commitment) и предложение и пересмотр (propose and revise). Завершит главу обзор некоторых инструментальных средств приобретения знаний, которые используются в системах решения проблем конструирования

Системы с доской объявлений
В последние годы в разработке архитектуры экспертных систем появилось новое направление, которое получило название системы с доской объявлений (blackboard sys-tems)u. Системы с такой архитектурой могут эмулировать режим построения как прямой цепочки логического вывода, так и обратной, а также попеременно применять эти режимы в процессе работы. Кроме того, применение систем с доской объявлений побуждает инженеров по знаниям к иерархической организации и знаний относительно предметной области, и пространства частичных и полных решений. Таким образом, эта архитектура очень хорошо подходит для решения задач проектирования, для которых характерно большое, но факторизуемое многомерное пространство решений.

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

Формирование знаний на основе машинного обучения
В главе 1 мы уже вскользь упоминали о связи между приобретением знаний экспертной системой и использованием автоматизированных методов формирования знаний на базе машинного обучения (machine learning). Было отмечено, что в ряду тех проблем, с которыми сталкивается разработчик экспертной системы, приобретение знаний является одной из наиболее трудоемких. В главе 10 было рассмотрено множество методов извлечения знаний, но ни один из них не позволяет избавиться от услуг человека-эксперта и соответственно от значительного объема работы, выполняемой "вручную".

Сети доверия
В этой главе мы рассмотрим два количественных метода реализации логических рассуждений при наличии неопределенности в структурированном пространстве гипотез, базирующихся на теории свидетельств Демпстера—Шефера [Gordon and Shortliffe, 1985] и Байесовском формализме [Pearl, 1986]. Каждый из этих подходов предполагает, что на множестве гипотез каким-то способом определена функция доверия (belieffunction), а затем по мере накопления новых свидетельств применяется специфический механизм обновления текущего множества допущений.

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

Гибридные системы
Раньше уже неоднократно высказывалась идея, что экспертная система может содержать не одну форму представления знаний. Даже в таких ранних системах, как MYCIN (см. главу 3), информация, специфическая для предметной области, хранилась в разных формах — например, в виде порождающих правил и в виде таблиц медицинских параметров. Программы, аналогичные CENTAUR (см. главу 13), уже можно было считать гибридными в том смысле, что в них объединялись разные способы представления знаний, а затем эти знания использовались с разной целью — для решения проблемы и формирования пояснений.

Загадки искусственного интеллекта
Тема искусственного интеллекта всегда была в информатике "страной плохишей", населенной массой "неправильных" проблем, не поддающихся решению традиционными способами. Эта область привлекла внимание прежде всего разносторонних специалистов, которых не испугало ее открытое, лишенное всякой организации пространство, — людей, которых влечет задача узнать, как мы мыслим. Такие исследователи, как Марвин Минский (Marvin Minsky), Джон Мак-Карти (John McCarthy), Герберт Саймон (Herbert Simon), Пат Хейес (Pat Hayes), Дональд Мичи (Donald Michie) и Бернард Мельтцер (Bernard Meltzer), стали первопроходцами для тех, кто следовал за ними по пути, пролегающем через информатику, психологию и математическую логику.

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

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

Литература

Программирование на языке CLIPS
Первым этапом любого программного проекта является анализ решаемой проблемы. Эксперт должен уметь решить проблему, а инженер по знаниям должен разобраться, как именно было получено решение. При решении нашей задачи вам придется выступить в обеих ипостасях.
Предложенные головоломки можно решить, систематически анализируя, что случится, если персонаж, произносящий реплику, является правдолюбцем, а что, если он — лжец. Обозначим через Т(А) факт, что А говорит правду и, следовательно, является правдолюбцем, а через F(A) — факт, что А лжет и, следовательно, является лжецом.

Управление проектами

Современные процессы разработки программного обеспечения, такие как Rational Unified Process (RUP), Extreme Programming (XP) и Scrum, являются эволюционными по своей природе, и многие из них – быстрые (agile). При применении эволюционного подхода вы работаете одновременно в итерационной и инкрементальном режимах; быстрый подход сочетает эволюционность с высоким уровнем сотрудничества. Работая в итерационном режиме, вы в каждый момент времени немного моделируете, немного тестируете, немного кодируете и немного развертываете, потом еще немного, и еще немного, и т.д. При использовании инкрементального подхода вы организуете свою систему в виде последовательности выпусков, а не одного большого выпуска. Когда группа разработчиков прибегает к коллаборативному подходу, ее участники активно стараются найти способы эффективной совместной работы; следует даже добиваться того, чтобы инициаторы проекта (заказчики системы) являлись активными членами группы.

Быстрые методы для объектных баз данных
Скотт Амблер – известный, судя по Internet, специалист в области методологий разработки программного обеспечения. Его даже называют “гуру” быстрых (agile) методов разработки. Сам он ассоциирует себя с двумя компаниями – Ambisoft и Robin International – и называет себя старшим консультантом в обеих компаниях. Судя по фотографиям, Амблер достаточно молодой человек, а судя по числу написанных и изданных им книг, а также объему подготовленных им материалов, размещенных на www.ambysoft.com, исключительно активный. Статью, перевод которой мы вам предлагаем, Амблер написал специально для портала (хотя, похоже, что в этом его стимулировала компания db4objects, о которой мы еще поговорим).

Антипаттерны руководства командами разработки ПО
Некоторые руководители программных проектов, в первую очередь начинающие, в работе с людьми постоянно наступают на одни и те же грабли. В компьютерной науке для подобных частонаступаемых граблей придумано название #xab;антипаттерны#xbb; - это повторно используемые практики, которые могут давать видимость эффекта и даже временный эффект, однако, их применение наносит несоизмеримый ущерб конечному результату. Цель статьи - собрать вместе некоторые наиболее тяжелые грабли (антипаттерны), которые встречаются на пути управления командами разработки ПО, и попытаться объяснить, почему на них не стоит наступать.

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

Как добиться успеха в безнадежных проектах
Многим руководителям ИТ-проектов знакомы ситуации, когда прекрасно спланированный процесс не укладывается во временные рамки. Несмотря на то что сроки были определены с запасом, одни модули «забирают» все доступные ресурсы, другие сразу после появления на свет удаляются за ненадобностью, а постоянные изменения требований окончательно разрушают проект.

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

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

Проектирования больше нет?
Тем, кто успел кратко познакомиться с принципами Extreme Programming (ХР), порой кажется, что в этой методологии нет места процессу проектирования программных продуктов. При этом высмеиваются не только "Большое и Подробное Предварительное Проектирование", но и такие техники как UML и гибкие каркасы приложений. Даже значение паттернов либо принижается, либо напрочь отрицается. На самом же деле, в ХР много проектирования, но подается оно по-другому, нежели в обычных устоявшихся процессах разработки ПО. Методология XP оживила эволюционное проектирование новыми техниками, благодаря которым его теперь можно считать вполне жизнеспособной стратегией.

Пересекая границы: специфика разработки ПО распределенной командой
Эта статья написана на основе опыта работы в нескольких проектах по разработке ПО, где участники проектной команды были в большей или меньшей степени удалены друг от друга: начиная от варианта #xab;одна команда в двух офисах в одном городе#xbb;, и заканчивая вариантом #xab;3 команды в разных странах #x2013; из них одна на другом континенте#xbb;. Как появляются такие проекты? В малых компаниях ценность конкретного специалиста для проекта часто выше, чем возможные расходы на коммуникацию, и его местожительство не берется в расчет. В крупных компаниях, наоборот, появляется большой объем работ, не требующих высокой квалификации, и задачи реализуются с привлечением субподрядчиков, в том числе из других стран.

Проблемы анализа экономики производства программных продуктов
Экономические характеристики реальных завершенных разработок, собираются, накапливаются и обрабатываются с начала 80-х годов в разных отечественных организациях и за рубежом [1, 3]. Они позволили получать и прогнозировать основные обобщенные экономические показатели процессов производства комплексов программ. При оценке размера вновь созданных комплексов программ и трудоемкости их полной разработки обычно не учитывались компоненты операционных систем, драйверы, средства контроля и тестирования, а также повторно используемые компоненты.

Реализация стандарта ГОСТ Р ИСО/МЭК
Стандарт ГОСТ Р ИСО/МЭК 12207 определяет архитектуру верхнего уровня жизненного цикла программных средств (ЖЦ ПС) и может быть использован для организации работ по одному или нескольким процессам ЖЦ ПС. Вместе с ГОСТ Р ИСО/МЭК ТО 15271-2002 Руководство по применению ГОСТ Р ИСО/МЭК 12207 стандарт ГОСТ Р ИСО/МЭК 12207 предоставляет возможности для адаптации к широкому кругу задач на основе расширения рекомендаций стандарта путем ввода новых процессов, работ, задач или других объектов ЖЦ ПС, не рассматриваемых в стандарте. В качестве примера можно сослаться на раздел 4 приложения D к ГОСТ Р ИСО/МЭК ТО 15271-2002 - Пример сопровождения.

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

Четвертое измерение или Как обмануть Железный Треугольник
Несмотря на то, что первым в Манифесте Гибких Методологий (Agile Manifesto) стоит правило "Люди и их взаимодействие гораздо важнее процесса и средств разработки", сами приверженцы таких методологий тратят на разговоры о процессе довольно много времени. К примеру, Экстремальное программирование (XP) описывает почти что исключительно процесс разработки: "Вы следуете процессу? Сначала тестируете, потом пишете код? Играете в планирование? Парами программируете?" и т.д.

Понятие «реинжиниринга ИС», его содержание и место в ЖЦ ИС
Сегодня в мире существует большое количество подходов, методов и технологических решений, напрямую или косвенно соотносимых с деятельностью по реинжинирингу ИС. Однако они не интегрированы на уровне методологий (процессов разработки). Как результат, можно наблюдать наличие огромного количества методологий, где основной акцент сделан на разработку ИС «с нуля», и практическое отсутствие «стройных» методологий, целью создания которых являлось бы комплексное, целостное решение задач реинжиниринга ИС.

Designing for FAILURE - ключ к успеху?
Трудно найти более квалифицированного специалиста в области проектирования и разработки систем управления базами данных, чем почетный сотрудник IBM (IBM Fellow) Брюс Линдсей. Он начал заниматься архитектурой РСУБД (реляционных систем управления базами данных) еще до того, как появились такие системы. В 1978 г., закончив аспирантуру Калифорнийского университета в Беркли и получив степень PhD, он поступил на работу в Исследовательскую лабораторию IBM в Сан-Хосе, где исследователи тогда работали над тем, что впоследствии стало основой языка SQL и продукта IBM DB2. С того времени Линдсей играет ведущую роль в развитии РСУБД.

Системные характеристики КМП
Для того чтобы Команда Менеджмента Проекта (Project Management Team) была готова к совместной работе и, в последующем, к эффективной самоорганизации, требуется, чтобы каждый ее участник был интегрирован в команду и в проект.
Сами процессы самоорганизации команды должны быть обеспечены мониторингом и механизмом управления изменениями, которые включают систему норм, правил и процедур, определяющих поведение и действия ключевых участников проекта и активную обратную связь.

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

Исполнение моделей при помощи виртуальной машины
Прошло уже почти 20 лет со времени появления в 1986 году вызвавшей множество споров статьи Фредерика Брукса «Серебряной пули нет». В данной работе автор предрекал, что в течение ближайшего десятилетия с момента её выхода не возникнет методов, использование которых позволит на порядок величин повысить производительность разработки программного обеспечения. Эта статья вызвала множество споров и работ с опровержениями, и в 1995 году Ф. Брукс опубликовал ответы на некоторые из критических замечаний

MSF – философия создания IT-решений или голые амбиции лидера
Корпорацию Майкрософт можно обвинять в чём угодно, но уж точно не в том, что её руководители не умеют вести бизнес и создавать продаваемые программные комплексы. Посредством пакета руководств MSF (Microsoft Solutions Framework) гигант IT индустрии решил поделиться опытом и накопленной информацией в области проектирования, разработки, внедрения и сопровождения IT -проектов. Словосочетание MSF я бы перевёл как «Подходы Майкрософт к созданию решений». База знаний MSF состоит из оригинальных моделей, методов и взглядов на такие области знаний как управление проектами, персоналом, планирование, анализ рисков и другие смежные дисциплины. Нельзя сказать, что MSF очередной чисто теоретический взгляд на управление.

Внедрение систем управления. Что вначале - процессы или ПО?
В последнее время все большее число предприятий осознают необходимость создания автоматизированных систем управления проектами (далее АСУП). При этом первым и необходимым условием для успешной реализации проекта создания АСУП является наличие у руководства организации заинтересованности в будущей системе и четкого понимания целей, для достижения которых она создается. Это значительно упростит процесс формирования требований к системе.

О чем и зачем
Кто виноват? Никто. Как никто не виноват в том, что на небе тучи, что идет дождь, что дует ветер. Поскольку самого-то кризиса не было, и нет, а есть лишь Богом данная (для атеистов - объективная) реальность, которая заключена в особой специфике производства программ, по сравнению с любой другой производственной деятельностью. И с этой спецификой мы обязаны считаться, если, конечно, не хотим «дуть против ветра».

Семантическая реконсиляция прикладных данных на основе моделей
Рассматривается задача семантически корректной и функционально содержательной реконсиляции прикладных данных. Задача имеет ключевое значение для успешного применения современных технологий оптимистической репликации и создания перспективных распределенных приложений, таких как системы коллективной инженерии, мобильные базы данных, семантические сети. Рассматривается модельно-ориентированный подход к семантической реконсиляции данных, описываемых на языках объектно-ориентированного моделирования EXPRESS, UML/OCL, ODL/OQL.

Рефакторинг архитектуры программного обеспечения: выделение слоев
В последнее время наблюдается тенденция к увеличению продолжительности жизненного цикла успешных программных проектов. Как следствие, растет объем унаследованного кода, поддерживаемого сообществом разработчиков [1]. Именно это объясняет исключительную важность задач, связанных с облегчением сопровождения и развития существующего программного кода. В то же время, этим задачам уделяется недостаточное внимание со стороны научного сообщества и разработчиков инструментальных средств. Как следствие, современные методики переоценивают значение начальной фазы жизненного цикла программной системы и практически игнорируют ее дальнейшую эволюцию

Диалог с оппонентом
Выполнение проектов, особенно если они связаны с разработкой программного обеспечения (ПО), — явно не детерминированный процесс. Новизна используемых технологий, сложность заданий, отсутствие у разработчиков необходимой квалификации — из-за этих и многих других факторов проекты часто идут не так, как планировалось. Один из приемов, повышающих вероятность успеха в таких условиях, — использование методов управления рисками. Традиционно под управлением рисками понимают процесс идентификации и анализа событий и ответа на них. При этом ставится цель максимизировать вероятность положительных событий и их последствия и минимизировать вероятность и последствия событий неблагоприятных.

Использование ролей в сценариях взаимодействия
Сценарий взаимодействия описывает поведение системы через описания взаимодействий некоторых объектов. Такими объектами выступают компоненты системы и внешние объекты, называемые акторами (actors). Обычно в сценарии взаимодействия подразумевается уникальность каждого объекта системы, т.е. предполагается, что описываются физически различные экземпляры объектов. Однако в ряде случаев это приводит к дублированию при описании сценариев. В работе предлагается расширить аппарат сценариев взаимодействия, разрешив использование ролей объектов. Роль соответствует некоторому срезу поведения определенного физического объекта.

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

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

Своими силами: управление процессом разработки ПО небольшой командой специалистов
В любой организации существует необходимость в том, чтобы автоматизировать некоторые, свойственные только ей процессы. В случае, когда потребность в создании специального ПО существенно влияет на бизнес, такое ПО может быть заказано для разработки в сторонних компаниях. Однако зачастую организация вполне способна справится с автоматизацией своими собственными силами - с помощью небольшой группы разработки (от одного до трех человек). Риск заключается в том, что управление процессом разработки в этом случае может лечь на плечи людей, основная специальность которых не связана напрямую с такой деятельностью - программистов, инженеров других специальностей или менеджеров, не знакомых со спецификой разработки ПО. Это может быть первый опыт такого рода для данной организации.

Структурное руководство проектом. Серебряная пуля?
Этот термин достаточно давно и активно используется в ИТ как символ технологического прорыва, который позволит разрабатывать ПО намного быстрее и качественнее. Дело в том, что Фред Брукс в 1987 году опубликовал очень широко известную статью под названием "No Silver Bullet" - "Серебряной пули не существует" - в которой доказывал, что нет и не предвидится никакого существенного прогресса в процессе разработки программного обеспечения.

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

Трансформация UML-моделей и ее применение в технологии MDA
На данный момент разработаны и активно используются множество стандартов, middleware-технологий и платформ (CORBA, DCOM, Dot-Net, WebServices, JAVA-технологии и т.д.), и в будущем их количество будет расти. Попытки создать универсальную платформу, которая бы заменила все существующие, привели только к увеличению количества используемых технологий. Всё более важными становятся вопросы выбора технологии для конкретного проекта, осуществления взаимодействия и интеграции разнородных систем и переносе систем на новую технологическую платформу, когда используемая платформа устаревает и уже не может удовлетворить потребности заказчика. Решение может лежать в использовании новой, более совершенной методики разработки ПО.

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

Экстремальное программирование и быстрая разработка ПО
Любая идея, доведенная до абсурда, вырождается в собственную противоположность. Именно такая ситуация складывается в североамериканской промышленности ПО с RAD-средствами разработки. В некоторый момент инструменты, предназначенные для быстрой разработки приложений, стали вытеснять в умах менеджеров все остальное, в том числе разработчиков, заказчиков и сам проект. Неоправданное, гипертрофированное внимание к Процессу в ущерб другим факторам разработки породило массу формальных процедур — но качество полученных продуктов и количество успешных проектов оказалось разочаровывающим.

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

Технологии разработки программного обеспечения

Компьютерные науки вообще и программная инженерия в частности — очень популярные и стремительно развивающиеся области знаний. Обоснование простое: человеческое общество XXI века — информационное общество. Об этом говорят цифры: в ведущих странах занятость населения в информационной сфере составляет 60%, а в сфере материального производства — 40%. Именно поэтому специальности направления «Компьютерные науки и информационные технологии» гарантируют приобретение наиболее престижных, дефицитных и высокооплачиваемых профессий. Так считают во всех развитых странах мира. Ведь не зря утверждают: «Кто владеет информацией — тот владеет миром!»
Поэтому понятно то пристальное внимание, которое уделяет компьютерному образованию мировое сообщество, понятно стремление унифицировать и упорядочить знания, необходимые специалисту этого направления. Одними из результатов такой работы являются международный стандарт по компьютерному образованию Computing Curricula 2001 — Computer Science и международный стандарт по программной инженерии IEEE/ACM Software Engineering Body of Knowledge SWEBOK 2001.

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

Тестирование элементов
Объектом тестирования элементов является наименьшая единица проектирования ПС — модуль. Для обнаружения ошибок в рамках модуля тестируются его важнейшие управляющие пути. Относительная сложность тестов и ошибок определяется как результат ограничений области тестирования элементов.

Набор метрик Чидамбера и Кемерера
Если класс не может отреагировать на сообщение (например, в нем отсутствует собственный метод), тогда он пошлет сообщение родителю. Подсчитываются методы, определенные в текущем классе, и все унаследованные методы. Этот подход подчеркивает важность пространства состояний в понимании класса (а не инкрементности класса).