Справочник и примеры языка 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
Справочник по PHP и Lite PHP (продолжение)
MySQL С API
Справочник по Perl

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

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

Контекст разработки Web
Соединение XHTML и PHP
Скалярные переменные
Оператор If
Циклы while
Включаемые файлы
Проектирование форм
Сеансы
Доступ ODBC
Доступ к MySQL
Открытие файлов
Сайт e-Commerce
Использование оператора SQL UPDATE
Оператор SELECT

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

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

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

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

Текущее состояние проблемы
Текущее состояние проблемы - 2
Распределение материал книги по главам
Распределение материал книги по главам - 2
Рекомендуемая литература
Упражнения
Смысл экспертного анализа
Смысл экспертного анализ- 2
Характеристики экспертных систем
Характеристики экспертных систем - 2

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

Упражнения
Упражнения - 2
Упражнения - 3
Упражнения - 4
Поиск в пространстве состояний
Поиск в пространстве состояний - 2
Поиск в пространстве состояний - 3
Поиск в пространстве состояний - 4
Поиск в пространстве состояний - 5
Поиск в пространстве состояний - 6

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

Символические вычисления
Символические вычисления - 2
Почему LISP не является языком знаний
Символический уровень и уровень знаний
LISP и разработкпрограмм
Языки представления знаний
Языки представления знаний - 2
Рекомендуемая литература
Упражнения
Символическое представление

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

Системы, основанные нзнаниях
Рекомендуемая литература
Упражнения
Упражнения - 2
Упражнения - 3
Канонические системы
Канонические системы - 2
Системы правил для решения проблем
Синтаксис представления правил
Синтаксис представления правил - 2

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

Ассоциативные сети и системы фреймов
Множественное наследование
Множественное наследование - 2
Множественное наследование - 3
Сравнение сетей и фреймов
Рекомендуемая литература
Упражнения
Упражнения - 2
Графы, деревья и сети
Графы, деревья и сети - 2

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

Метаклассы в CLOS и CLIPS
Метаклассы в CLOS и CLIPS - 2
Множественное наследование в C++
Множественное наследование в C++ - 2
Множественное наследование в C++ - 3
Множественное наследование в C++ - 4
Множественное наследование в C++ - 5
Объектно-ориентированный анализ
Рекомендуемая литература
Упражнения

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

PROLOG и MBASE
Правилпоискв языке PROLOG
Правилпоискв языке PROLOG - 2
Управление поиском в системе MBASE
Управление поиском в системе MBASE - 2
Управление поиском в системе MBASE - 3
Управление поиском в системе MBASE - 4
Управление поиском в системе MBASE - 5
Рекомендуемая литература
Упражнения

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

Теория возможности
Теория возможности - 2
Неопределенное состояние неопределенности
Рекомендуемая литература
Источники неопределенности
Источники неопределенности - 2
Экспертные системы и теория вероятностей
Условная вероятность

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

Эксперты для извлечения знаний в COMPASS
Эксперты для извлечения знаний в COMPASS - 2
Эксперты для извлечения знаний в COMPASS - 3
Автоматизация извлечения знаний в OPAL
Графический интерфейс модели области
Графический интерфейс модели области - 2
Графический интерфейс модели области - 3
Графический интерфейс модели области - 4
Графический интерфейс модели области - 5
Графический интерфейс модели области - 6

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

Структурзадач в системе NEOMYCIN
Структурзадач в системе NEOMYCIN - 2
Структурзадач в системе NEOMYCIN - 3
Рекомендуемая литература
Упражнения
Упражнения - 2
Инструментальные средстви задачи
Инструментальные средстви задачи- 2
Инструментальные средстви задачи - 3
Эвристическая классификация в MUD и MORE

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

Эвристическая классификация (I)
Эвристическая классификация (I) - 2
Классификация задач экспертных систем
Классификация задач экспертных систем - 2
Классификация задач экспертных систем - 3
Классификация задач экспертных систем - 4
Классификация методов решения проблем
Эвристическое сопоставление
Эвристическое сопоставление - 2
Общность эвристической классификации

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

Рабочая срединженерии знаний TDE
Рабочая срединженерии знаний TDE - 2
Рабочая срединженерии знаний TDE - 3
Рекомендуемая литература
Упражнения
Упражнения - 2
Упражнения - 3
Влияние сложности на организацию системы
Влияние сложности на организацию системы - 2
Влияние сложности на организацию системы - 3

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

Решение проблем конструирования (I)
Рекомендуемая литература
Упражнения
Упражнения - 2
Области применения методов
Области применения методов - 2
СистемR1/XCON
СистемR1/XCON - 2
Компоненты и ограничения
Компоненты и ограничения - 2

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

Стратегии конструирования
Стратегии конструирования - 2
Стратегии конструирования - 3
Стратегии конструирования - 4
Архитектура систем планирования
Архитектура систем планирования - 2
Архитектура систем планирования - 3
Архитектура систем планирования - 4
Архитектура систем планирования - 5
Архитектура систем планирования - 6

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

Системы ВВи ACCORD
Системы ВВи ACCORD - 2
СистемPROTEAN
Интеграция стратегий логического вывода
Общая характеристикВВ
Эффективность и гибкость модели с доской объявлений
Организация доски объявлений в системе GBB
Организация доски объявлений в системе GBB - 2
Организация доски объявлений в системе GBB - 3
Компоновкдоски объявлений в среде ERASMUS

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

Отслеживание зависимостей
Релаксация в сети
Пересмотр допущений
Пересмотр допущений - 2
Пересмотр допущений - 3
Пересмотр теорий высказываний
Пересмотр теорий высказываний - 2
Немонотонное обоснование
Немонотонное обоснование - 2
Немонотонное обоснование - 3

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

Формирование знаний носнове машинного обучения
Формирование знаний носнове машинного обучения - 2
Алгоритм формирования дереврешений по обучающей выборке
Алгоритм формирования дереврешений по обучающей выборке - 2
Алгоритм формирования дереврешений по обучающей выборке - 3
Алгоритм формирования дереврешений по обучающей выборке - 4
Алгоритм формирования дереврешений по обучающей выборке - 5
Алгоритм формирования дереврешений по обучающей выборке - 6
Алгоритм формирования дереврешений по обучающей выборке - 7
Алгоритм формирования дереврешений по обучающей выборке - 8

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

Теория Демпстера—Шефера
Функции доверия
Функции доверия - 2
Применение теории Демпстера—Шеферк системе MYCIN
Применение теории Демпстера—Шеферк системе MYCIN - 2
Применение теории Демпстера—Шеферк системе MYCIN - 3
Применение теории Демпстера—Шеферк системе MYCIN - 4
МетодикПерла
МетодикПерл- 2
МетодикПерл- 3

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

Рассуждения, основанные нпрецедентах
Рассуждения, основанные нпрецедентах - 2
Сравнение систем, основанных нправилах и прецедентах
Рекомендуемая литература
Упражнения
Упражнения - 2
Базпрецедентов
ПрограммCHEF
ПрограммCHEF - 2
Методы извлечения и адаптации прецедентов

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

Организация обучения в системе SCALIR
Будущее гибридных систем
Рекомендуемая литература
Упражнения
Методы обучения в системе ODYSSEUS
Методы обучения в системе ODYSSEUS - 2
Методы обучения в системе ODYSSEUS - 3
Методы обучения в системе ODYSSEUS - 4
Системы ODYSSEUS и MINERVA
Оболочкэкспертной системы MINERVA

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

Загадки искусственного интеллекта
Загадки искусственного интеллекта- 2
Загадки искусственного интеллекта - 3
Представление знаний
Представление знаний - 2
Представление знаний - 3
Языки программирования систем ИИ
Языки программирования систем ИИ - 2
Решение практических проблем
Решение практических проблем - 2

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

Характерные сложности
Характерные сложности - 2
Инструментарий для экспертной системы
Инструментарий для экспертной системы - 2
Инструментарий для экспертной системы - 3
Инструментарий для экспертной системы - 4
Освоение инструментальных средств
Освоение инструментальных средств - 2
Освоение инструментальных средств - 3
Освоение инструментальных средств - 4

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

Проект Explainable Expert Systems
Проект Explainable Expert Systems - 2
Проект Explainable Expert Systems - 3
Проект Explainable Expert Systems - 4
Планирование текстов пояснений в PEA
Планирование текстов пояснений в PE- 2
Планирование текстов пояснений в PE- 3
Перспективы дальнейших исследований методов
Рекомендуемая литература
Упражнения

Литература

Литература
Литература- 2
Литература- 3
Литература- 4
Литература- 5
Литература- 6
Литература- 7
Литература- 8
Литература- 9
Литература- 10

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

Задач"Правдолюбцы и лжецы"
Анализ проблемы
Анализ проблемы - 2
Онтологический анализ и представление
Онтологический анализ и представление - 2
Онтологический анализ и представление - 3
Разработка правил
Разработка правил - 2
Разработка правил - 3
Разработка правил - 4

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

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

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

Быстрые методы для объектных баз данных
Быстрые методы для объектных баз данных - 2
Быстрые методы для объектных баз данных - 3
Быстрые методы для объектных баз данных - 4
Быстрые методы для объектных баз данных - 5
Рефакторинг
Быстрое моделирование
Постоянное регрессионное тестирование
Конфигурационное управление
Песочницы разработчиков

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

О чем?
Первоисточники
В какое время мы работаем?
В какое время мы работаем? - 2
Что такое эффективность?
Что такое эффективность? - 2
Антипаттерны некомпетентности
Антипаттерны некомпетентности - 2
Антипаттерны мнительности
Антипаттерны мнительности - 2

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

Человеческий фактор
Человеческий фактор - 2
Человеческий фактор - 3
Мотивация в функциональной группе
Мотивация в функциональной группе - 2
Project Risk Management

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

Как добиться успеха в безнадежных проектах
Как добиться успеха в безнадежных проектах - 2
Как добиться успеха в безнадежных проектах - 3
Как добиться успеха в безнадежных проектах - 4
Как добиться успеха в безнадежных проектах - 5
Как добиться успеха в безнадежных проектах - 6
Как добиться успеха в безнадежных проектах - 7
Как добиться успеха в безнадежных проектах - 8

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

Жизненный цикл программного продукта
Определение требований
Определение требований - 2
Определение требований - 3
Анализ и проектирование
Анализ и проектирование - 2
Анализ и проектирование - 3
Разработка
Тестирование и профилирование
Тестирование и профилирование - 2

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

Простейший случай диаграмм
Простейший случай диаграмм - 2
Простейший случай диаграмм - 3
Простейший случай диаграмм - 4
Простейший случай диаграмм - 5
Простейший случай диаграмм - 6
Простейший случай диаграмм - 7
Простейший случай диаграмм - 8
Простейший случай диаграмм - 9
Простейший случай диаграмм - 10

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

Основополагающие практики ХР
Основополагающие практики ХР - 2
Преимущества простого дизайна
Преимущества простого дизайна - 2
"Простой дизайн" - что же это за зверь такой?
"Простой дизайн" - что же это за зверь такой? - 2
Нарушает ли рефакторинг принцип YAGNI?
Паттерны и ХР
Паттерны и ХР - 2
Наращивание архитектуры

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

Управляющая информация
Требования
Планы и бизнес-цели
Структура команды
Ответственность команд
Глоссарий
Способы коммуникации
Skype, Icq и другие системы
Телефон
Системы учета заданий и ошибок

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

Экономика производства программ
Экономика производства программ - 2
Экономика производства программ - 3
Экономика производства программ - 4
Организация производства программ
Организация производства программ - 2
Организация производства программ - 3
Организация производства программ - 4
Организация производства программ - 5
Заключение

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

Ключевые особенности Rational Unified Process
Технология адаптации
Взаимодействие с другими процессами ЖЦ ПС
Ролевые функции и организационная структура
Роль артефактов в процессе адаптации
Адаптация и реализация процесса сопровождения
Оформление материалов в виде сайта
Оформление материалов в виде сайта - 2
Оформление материалов в виде сайта - 3
Оформление материалов в виде сайта - 4

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

Инструменты проектного менеджмента
Инструменты проектного менеджмента - 2
Обзор и классификация АСУПП
Обзор и классификация АСУПП - 2
Обзор и классификация АСУПП - 3
Обзор и классификация АСУПП - 4

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

Как обмануть Железный Треугольник
Как же обмануть Железный Треугольник?
Пусть все люди работают в одном помещении
Тихая гавань и стратегии управления проектами
Быстрое документирование плюс обсуждение
Одновременная разработка

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

Понятие реинжиниринга ИС
Понятие реинжиниринга ИС -2
Реинжиниринг ИС и его место в ЖЦ ИС.
Реинжиниринг ИС и его место в ЖЦ ИС - 2
Реинжиниринг ИС и его место в ЖЦ ИС - 3
Реинжиниринг ИС и его место в ЖЦ ИС - 4
Реинжиниринг ИС и его место в ЖЦ ИС. - 5
Реинжиниринг ИС и его место в ЖЦ ИС. - 6
Реинжиниринг ИС и его место в ЖЦ ИС. - 7
Реинжиниринг ИС и его место в ЖЦ ИС - 8

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

Беседа с Брюсом Линдсеем
Беседа с Брюсом Линдсеем - 2
Беседа с Брюсом Линдсеем - 3
Беседа с Брюсом Линдсеем - 4
Беседа с Брюсом Линдсеем - 5
Беседа с Брюсом Линдсеем - 6
Беседа с Брюсом Линдсеем - 7
Беседа с Брюсом Линдсеем - 8
Беседа с Брюсом Линдсеем - 9
Беседа с Брюсом Линдсеем - 10

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

Системные характеристики КМП.
Интерпретация системных свойств к КМП.
Целесообразность.
Иерархическое строение.
Адаптация
Память
Разнообразие состояний
Метатехнология и технология самоорганизации
Область применимости
Условия применимости

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

Краткий обзор
Компоненты и объем методологии
Компоненты и объем методологии - 2
Принципы
Принципы - 2
Принципы - 3
Принципы - 4
Принципы - 5
Приоритеты
Методология и ее автор

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

Для чего нужны модели
Для чего нужны модели - 2
Почему важно, чтобы модели были исполняемыми
Результат исполнения модели
Способы исполнения моделей
Интерпретация
Генерация автоматной модели
Виртуальная машина
Создание виртуальной машины
Виртуальная машина как строительный компонент

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

Базовые концепции и принципы MSF
Единое видение проекта
Управляйте компромиссами
Треугольник компромиссов
Матрица компромиссов
Проявляйте гибкость – будьте готовы
Концентрация на бизнес-приоритетах
Поощряйте свободное общение
Создавайте базовые версии
MSF – симбиоз итеративного и фазового подхода

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

Объем и подход к проведению внедрения
Объем и подход к проведению внедрения - 2
Описание бизнесс-процессов и ПО
Что первично - процессы или ПО?
Квалификация персонала
Квалификация персонала - 2
Квалификация команды проекта внедрения
Квалификация команды проекта внедрения - 2

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

Моцарт и Сальери
Моцарт и Сальери - 2
Моцарт и Сальери - 3
Моцарт и Сальери - 4
Моцарт и Сальери - 5
Моцарт и Сальери - 6
Моцарт и Сальери - 7
Моцарт и Сальери - 8
Моцарт и Сальери - 9
Моцарт и Сальери - 10

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

Роль модельно-ориентированного подхода
Роль модельно-ориентированного подхода - 2
Общий подход к реконсиляции
Этапы реконсиляции
Этапы реконсиляции - 2
Действия
Типы данных и виды ограничений
Семантический анализ транзакций
Понятие корректной транзакции
Понятие корректной транзакции - 2

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

Архитектура ПО и ее рефакторинг
Зачем менять архитектуру?
Как представить архитектуру и ее изменения?
Как представить архитектуру и ее изменения? - 2
Рефакторинг архитектуры
Архитектурный и классический рефакторинг
Фазы архитектурного рефакторинга
Фазы архитектурного рефакторинга - 2
Выделение слоев
Слои в архитектуре ПО

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

Основные понятия
Основные понятия - 2
Диалог с оппонентом
Основные проблемы
Задачи управления рисками
Планирование управления рисками
Выявление рисков
Анализ и оценка приоритетности
Планирование ответных действий
Мониторинг рисков

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

Роли в моделях взаимодействия
Роли в моделях взаимодействия - 2
Формализация понятия роли
Свойства ролей
Свойства ролей - 2
Роли в сценариях взаимодействия
Взаимосвязь с аспектами
Композиция поведения в разных ролях
Уточнение семантики композиции
Уточнение семантики композиции - 2

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

Основные вопросы отбора руководителей
Качества, необходимые руководителю
Качества, необходимые руководителю - 2
Качества, необходимые руководителю - 3
Качества, необходимые руководителю - 4
Подготовка и отбор руководителей проектов.
Подготовка и отбор руководителей проектов. - 2
Привлечение кадров в сферу управления

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

Роли
Скрам Мастер (Scrum Master)
Product Owner
Команда (Team)
Product Backlog
Sprint Backlog
Спринт (Sprint)
Планирование спринта
Планирование спринта, митинг первый
Планирование спринта, митинг второй

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

Описание специфики разработки
Рекомендации по организации разработки
Рекомендации по организации разработки - 2
Выделение основных процессов
Разработка требований
Разработка требований - 2
Планирование реализации требований
Планирование реализации требований - 2
Планирование реализации требований - 3
Управление запросами на поддержку

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

Структурное руководство проектом
Структурное руководство проектом - 2
Структурное руководство проектом - 3
Структурное руководство проектом - 4
Структурное руководство проектом - 5
Структурное руководство проектом - 6
Структурное руководство проектом - 7
Структурное руководство проектом - 8

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

Анализ исполняемых UML-моделей
Характеристика конечных автоматов
Характеристика конечных автоматов - 2
Характеристика конечных автоматов - 3
Используемые конструкции
Используемые конструкции - 2
Типичные способы построения автоматов
Трансформация выделение метода для UML
Выделение в метод части конечного автомата
Выделение в метод части конечного автомата - 2

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

Подходы к трансформации UML-моделей
Подходы к трансформации UML-моделей - 2
Подходы к трансформации UML-моделей - 3
Схема инструмента трансформации
Пример простейшей трансформации
Язык описания трансформации
Язык описания трансформации - 2
Язык описания трансформации - 3
Выполнение трансформации
Выполнение трансформации - 2

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

Теория для победителя
Теория для победителя - 2
Теория для победителя - 3
Теория для победителя - 4
Теория для победителя - 5
Теория для победителя - 6

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

Экстремальный цикл
Позднее принятие решений
Кодирование в глубину
Идеальный день разработчика и фактор загрузки
Скорость проекта
История пользователей
План релиза
План итераций
Тесты приемки
Представители заказчиков

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

Игра в планирование
Тестирование до начала разработки
Парное программирование
Постоянная переработка
Простота разработки
Коллективное владение кодом
Продолжающаяся интеграция
Заказчик на рабочей площадке
Быстрый выпуск версий
Сорокачасовая рабочая неделя

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

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

Организация процесса конструирования
Тестирование элементов
Набор метрик Чидамбера и Кемерера


Кортасар Хулио - Киндберг
Информационные технологии
Блеск и нищета информационных технологий
Коростелев Дмитрий - Право На Жизнь
Козлов Сергей - Цыпленок Вечером
Крапивин Владислав - В Глубине Великого Кристалла
Деньги, банки, кредит
Основы функционального программирования
Криптография с открытым ключом
Зарождение криптографии
Кристи Агата - Слоны Помнят Все
Крюков Дмитрий - Хроника Великой Войны
Куликов Роман - Лима
Кук Оскар - По Кускам
Купцов Василий - Моцарт И Сальери, Дубль Два
Документационное обеспечение управления
Photoshop 4-5 - учебный курс
Курс делопроизводства. Документационное обеспечение
Кьяра Пьеро - Соблазны Джулии
Сайтостроительство