Отправляет email-рассылки с помощью сервиса Sendsay
  Все выпуски  

CNews.ru : Неделя HI-TECH | итоги IT-рынка |


Информационный Канал Subscribe.Ru

Неделя HI-TECH CNews.ru
 №12   Апрель 26, 2004
Подписаться  
Главные события недели 
Новости высоких технологий 

Аналитика и комментарии 
МЭРТ теснит Минтрансвязь в регулировании ИТ
Российские ИТ-компании ведут экспансию на запад СНГ
Станет ли Китай ИТ-конкурентом Америки?
Александр Калинин: ГАС "Выборы" - это ERP для избирательной системы России
Компании предпочитают чужих девушек на вызовах
"Оловянное" ERP или как автоматизировать монополиста
 
 
go

Вопрос недели 
Аналитики считают, что сейчас компьютеры постепенно переходят в разряд бытовой техники. Чем для Вас является домашний ПК?

Популярные темы Обсуждений 
МТС «Джинс»: абоненту не стоит ждать многого
Старые недостатки TCP могут парализовать интернет
"Евросеть" оштрафовали за мат
Федеральные чиновники покрывают пиратов?
Александр Калинин: ГАС "Выборы" - это ERP для избирательной системы России

Внимание

IP-телефония: как заработать в России

Книги 

Философия C++.
Введение в стандартный C++.
2-е изд.
.
Б. Эккель

Школа ИТ 

05-07.05 | Москва
Управление изменениями, релизами и конфигурациями (MOF changing quadrant)
16-17.06 | Москва
Введение в операторскую IP-телефонию
Весь список курсов

 №12   Апрель 26, 2004
Подписаться  
Публикации из книг

Философия C++. Введение в стандартный C++. 2-е изд.
Б. Эккель

Предисловие
Глава 1. Знакомство с объектами
Глава 2. Создание и использование объектов
Глава 3. Элементы C в языке C++
Глава 4. Абстрактное представление данных
Глава 5. Скрытие реализации
Глава 6. Инициализация и зачистка
Глава 7. Перегрузка функций и аргументы по умолчанию
Глава 8. Константы
Глава 9. Подставляемые функции
Глава 10. Механизм контроля имен
Глава 11. Ссылки и копирующий конструктор
Глава 12. Перегрузка операторов
Глава 13. Динамическое создание объектов
Глава 14. Наследование и композиция
Глава 15. Полиморфизм и виртуальные функции
Глава 16. Знакомство с шаблонами
Приложение А. Стиль программирования
Приложение Б. Рекомендации по программированию
Алфавитный указатель


Глава 1. Знакомство с объектами

Компьютерная революция начиналась с машин, поэтому многие языки программирования ориентированы на машины.

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

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

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

Развитие абстрактных представлений

Любой язык программирования основан на абстрактных представлениях. Более того, сложность решаемых задач напрямую зависит от типа и качества этой абстракции. Под "типом" подразумевается ответ на вопрос: "Что представляет данная абстракция?" Например, ассемблер можно рассматривать как маленькую абстракцию того компьютера, на котором он работает. Многие так называемые "массовые" языки, появившиеся позднее (например, Fortran, BASIC и C), могли рассматриваться как абстракции языка ассемблера. Они были гораздо совершеннее, но их первичная абстракция по-прежнему заставляла программиста мыслить в контексте структуры компьютера, а не структуры решаемой задачи. Программисту приходилось сопоставлять машинную модель (<пространство решения", то есть контекст, в котором моделируется задача, - в данном случае компьютер) и модель решаемой задачи (<пространство задачи", в котором определяется поставленная задача). Такое сопоставление требовало определенных усилий и было чужеродным по отношению к языку программирования. Это затрудняло разработку программ и повышало затраты на их сопровождение; в результате возникла целая отрасль "методологии программирования".

Наряду с моделированием компьютера также существует другое решение - моделирование решаемой задачи. В ранних языках типа LISP и APL было выбрано особое представление мира (<Любая задача сводится к обработке списков" или "Любая задача алгоритмизируется>). В языке PROLOG задача интерпретировалась как цепочка принимаемых решений. Создавались специальные языки программирования, основанные на системах ограничений или на манипуляциях с графическими условными обозначениями (впрочем, последние слишком сильно ограничивали свободу действий программиста). Все эти подходы хорошо соответствовали конкретному классу задач, для которых они разрабатывались, но за пределами этой области были весьма неудобными.

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

Некоторые проектировщики языков посчитали, что самого по себе объектно-ориентированного программирования недостаточно для простого решения всех задач программирования, и выступили за объединение разных подходов в мультипарадигменных языках программирования.

Алан Кей (Alan Kay) кратко сформулировал пять основных концепций SmallTalk - первого успешного объектно-ориентированного языка, который стал одним из прототипов C++. Эти концепции представляют "чистый" подход к объектно-ориентированному программированию.

  • Любая сущность представляется объектом. Объект можно рассматривать как усовершенствованную переменную: он содержит данные, но ему также можно направлять запросы на выполнение операций "с самим собой". Теоретически любой концептуальный компонент решаемой задачи (собака, здание, некоторая операция и т. д.) может быть представлен в программе в виде объекта.
  • Программа представляет собой совокупность объектов, которые общаются друг с другом посредством отправки сообщений. Чтобы обратиться с запросом к объекту, следует отправить ему сообщение. Точнее, сообщение может рассматриваться как запрос на вызов функции, принадлежащей конкретному объекту.
  • Каждый объект владеет собственным блоком памяти, состоящим из других объектов. Иначе говоря, новые объекты в программе создаются как "оболочки" для существующих объектов. Это позволяет усложнять программу, скрывая ее за простотой отдельного объекта.
  • Каждый объект обладает типом. В терминологии ООП каждый объект является экземпляром класса, где термин "класс" является синонимом термина "тип". Важнейшая отличительная характеристика класса формулируется так: "Какие сообщения принимает данный класс?>
  • Все объекты одного типа могут получать одни и те же сообщения. Как вы вскоре убедитесь, это утверждение не совсем корректно. Поскольку объект типа "круг" также является объектом типа "геометрическая фигура", объект-круг заведомо принимает сообщения, предназначенные для объектов-фигур. Следовательно, программа для работы с геометрическими фигурами может автоматически обрабатывать все объекты, которые являются частными случаями геометрической фигуры. Данная особенность является одной из самых сильных сторон ООП.

Интерфейс объекта

Вероятно, Аристотель был первым, кто серьезно изучал концепцию типов: он говорил о "классе птиц и классе рыб". Принцип, в соответствии с которым все объекты, несмотря на свою уникальность, также принадлежат к некоторому классу, обладающему и общими характеристиками и поведением, был напрямую воплощен в первом объектно-ориентированном языке Simula-67 - именно там появилось основополагающее ключевое слово class, которое вводило новый тип в программу.

Язык Simula, как нетрудно догадаться по его названию, создавался для имитации - например, для решения знаменитой "задачи кассира". В этой задаче задействовано множество кассиров, клиентов, счетов, операций и денежных единиц - короче говоря, множество "объектов". Объекты, различающиеся только по текущему состоянию во время выполнения программы, группируются в "классы>; отсюда и произошло ключевое слово class. Создание абстрактных типов данных (классов) является одной из основополагающих концепций объектно-ориентированного программирования. Абстрактные типы данных работают почти так же, как встроенные типы: программист определяет переменные этого типа (в терминологии ООП такие переменные называются объектами, или экземплярами) и работает с ними при помощи сообщений, или запросов. Программист отправляет запрос, а объект сам решает, как следует обработать этот запрос. Объекты, относящиеся к одному классу, обладают общими характеристиками: так, у каждого счета имеется баланс, каждый кассир может принимать деньги от клиентов и т. д. В то же время каждый объект обладает собственным состоянием: на счетах хранятся разные суммы, кассиры обладают разными именами и т. д. Таким образом, любой объект - кассир, клиент, счет, операция - представляется в программе отдельной сущностью (объектом), причем каждый объект принадлежит к конкретному классу, определяющему его характеристики и поведение.

Итак, хотя в объектно-ориентированном программировании фактически определяются новые типы данных, практически во всех объектно-ориентированных языках используется термин "класс". Если вы видите термин "тип", читайте "класс" - и наоборот .

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

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

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

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

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

В приведенном примере имеется тип/класс с именем Light и конкретный объект класса Light с именем It. К объекту Light можно обратиться со следующими запросами: включиться (on()), выключиться (off()), прибавить или убавить яркость (brighten() и dim()). При создании объекта класса Light указывается имя этого объекта (It). Чтобы отправить сообщение объекту, вы указываете имя объекта и отделяете его от сообщения точкой (.). С точки зрения пользователя готового класса, в этом и заключается все программирование с применением объектов.

Приведенная выше диаграмма оформлена по стандарту UML (Unified Modeling Language). Каждый класс представлен отдельным блоком; в верхней части блока находится имя класса, в средней - все переменные класса, которые вы желаете документировать, а в нижней части - функции класса (функции, которые принадлежат данному объекту и обрабатывают получаемые сообщения). Довольно часто на UML-диаграммах отображаются только имя и открытые функции класса, в этом случае средняя часть блока отсутствует. А если важно только имя класса, то и нижняя часть блока становится необязательной.

Скрытая реализация

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

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

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

Итак, существует несколько причин для ограничения доступа. Во-первых, некоторые аспекты класса должны быть защищены от вмешательства прикладных программистов. Речь идет об аспектах, задействованных во внутренней работе типа данных, но не входящих в его интерфейс, применяемый для решения практических задач пользователей. На самом деле ограничение доступа не мешает, а помогает прикладному программисту выделить то, что действительно существенно для его работы.

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

Для определения уровней доступа в C++ используются три ключевых слова: public, private и protected. Их смысл весьма прямолинеен - эти спецификаторы доступа указывают, кто может работать с объявлениями членов класса, следующими за ними. Спецификатор public означает, что следующие объявления доступны для всех. С другой стороны, спецификатор private означает, что доступ к следующим объявлениям возможен только из функций данного типа. Фактически он разделяет "зоны ответственности" создателя класса и прикладного программиста. При попытке обратиться извне к закрытому (private) члену класса происходит ошибка компиляции. Спецификатор protected аналогичен private с одним отличием: производные классы могут обращаться к защищенным (protected) членам класса, но доступ к закрытым (private) членам для них запрещен. О наследовании и производных классах мы поговорим чуть позже.

Повторное использование реализации

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

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

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

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

Наследование и повторное использование интерфейса

Сама по себе идея объекта чрезвычайно удобна. Она позволяет объединить данные и функциональность на концептуальном уровне, чтобы программист работал в контексте пространства решения задачи и не ограничивался идиоматическими представлениями базового компьютера. Эти концепции выражаются на уровне базового синтаксиса языка программирования ключевым словом class.

Но было бы обидно потрудиться над созданием класса, а потом заново определять новый класс, обладающий похожими возможностями. Гораздо удобнее взять существующий класс, скопировать его, а затем внести дополнения и изменения в копию. В сущности, именно это происходит при наследовании, но с одним исключением: изменения, вносимые в исходный класс (также называемый базовым классом, родительским классом или суперклассом), будут отражены и в его "копии" (называемой производным классом, дочерним классом или субклассом).

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

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

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

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

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

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

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

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

Чтобы переопределить функцию, достаточно создать в производном классе новое определение функции. В сущности, это означает: "Мы используем ту же интерфейсную функцию, но в производном типе она будет делать нечто иное".

Точное и приблизительное подобие

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

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

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

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

Взаимозаменяемость объектов и полиморфизм

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

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

Тем не менее интерпретация объектов производных типов в контексте базового типа (круг как геометрическая фигура, велосипед как средство передвижения, ворона как птица и т. д.) не обходится без проблем. Если функция должна приказать обобщенной геометрической фигуре нарисовать себя, обобщенному средству передвижения - повернуть, обобщенной птице - лететь и т. д., на стадии компиляции еще неизвестно, какой фрагмент кода должен при этом выполняться. Собственно, в этом и заключается вся соль - при отправке сообщения программист не желает знать, какой фрагмент кода будет выполняться. Функция вывода может применяться к кругам, квадратам и треугольникам, а объект должен выполнить правильный код в зависимости от фактического типа. Если вам не нужно знать, какой именно фрагмент кода будет выполняться, то при добавлении нового подтипа выполняемый код будет выбран без изменения вызова функции. Итак, если компилятор не может заранее узнать, какой фрагмент кода будет выполняться, что же ему делать? Например, на следующей диаграмме объект BirdController работает с обобщенными объектами Bird (птица) и не знает их точного типа. С точки зрения BirdController это удобно, поскольку этому классу не нужно определять конкретный подтип Bird, с которым он работает, или проверять поведение этого подтипа. Так как же при вызове функции move() без определения конкретного типа Bird выбирается правильное поведение? Ведь гусь (Goose) летает, плавает и бегает, а пингвин (Penguin) только плавает и бегает.

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

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

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

Виртуальные функции (то есть функции, наделенные гибкими возможностями позднего связывания) объявляются с ключевым словом virtual. Чтобы использовать виртуальные функции в программах, не обязательно понимать механику их вызова, но без виртуальных функций объектно-ориентированное программирование на C++ невозможно. В C++ необходимо помнить о добавлении ключевого слова virtual, потому что по умолчанию функции классов не используют динамическое связывание. В виртуальных функциях проявляются различия в поведении классов, принадлежащих к одному семейству. Эти различия заложены в основу полиморфизма.

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

На C++ эта функция выглядит примерно так:

void doStuff(Shape& s) {
s.erase();
// ...
s.draw();
}

Функция работает с любыми объектами типа Shape и не зависит от конкретного типа выводимых и стираемых объектов (суффикс & означает "Получить адрес объекта, передаваемого функции doStuff()", но вам пока не обязательно разбираться в этих тонкостях). Вызов функции doStuff() в другой части программы выглядит так:

Circle c;
Triangle t;
Line l;
doStuff(c);
doStuff(t);
doStuff(l);

Вызовы doStuff() автоматически работают правильно независимо от фактического типа объекта.

На самом деле это очень интересный факт. Рассмотрим следующую строку:

doStuff(c);

Здесь происходит следующее: функции, которая ожидает получить объект типа Shape, передается объект типа Circle. Поскольку класс Circle является частным случаем Shape, он может интерпретироваться как таковой функцией doStuff(). Иначе говоря, любое сообщение, которое функция doStuff() может отправить объекту Shape, будет успешно принято также и объектом Circle. Все предельно безопасно и логично.

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

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

s.erase();
// ...
s.draw();

Обратите внимание: мы не говорим "для объекта Circle сделать то, для объекта Square - сделать это". Программа, анализирующая все возможные разновидности Shape, получится слишком громоздкой, вдобавок ее придется изменять при каждом добавлении новой разновидности Shape. В данном случае мы говорим: "Фигура, я знаю, что ты умеешь самостоятельно обрабатывать вызовы erase() и draw(); сделай это и позаботься обо всех деталях".

Интересно, что код функции doStuff() каким-то образом делает именно то, что требуется. При вызове draw() для Circle будет выполнен совсем не тот код, который выполняется при вызове draw() для Square или Line, а при отправке сообщения draw() неизвестной разновидности Shape правильное поведение выбирается автоматически в соответствии с фактическим типом объекта. И это выглядит совершенно удивительно, потому что, как упоминалось выше, при компиляции функции doStuff() компилятор не обладает информацией о типах, с которыми он работает. Следовательно, в обычной ситуации можно было бы предположить, что будут вызваны версии функций erase() и draw() класса Shape, а не конкретных подтипов Circle, Square и Line. Тем не менее благодаря полиморфизму все работает правильно. Обо всех деталях позаботятся компилятор и система времени выполнения. Программист должен знать лишь то, что этот механизм работает, и уметь применять его при проектировании. Если функция класса объявлена виртуальной, то при получении сообщения объект автоматически выполнит правильные действия, даже если при этом потребуется повышающее приведение типа.

Создание и уничтожение объектов

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

Особого внимания заслуживают операции создания и уничтожения объектов. Где хранятся данные объекта и как определяется продолжительность его жизненного цикла? В разных языках программирования используются разные решения. В подходе, принятом в C++, важнейшим фактором считается контроль над эффективностью, поэтому программисту предоставляется выбор. Если он стремится добиться максимальной скорости выполнения, то место хранения и продолжительность жизненного цикла объектов определяются на стадии написания программы; для этого объекты размещаются в стеке или в статической памяти. Стеком называется область памяти, которая напрямую используется процессором во время выполнения программы. Переменные, хранящиеся в стеке, также называются автоматическими переменными. Статической памятью называется фиксированный блок памяти, выделяемый перед началом выполнения программы. При хранении данных в стеке или статической памяти на первое место ставится скорость выделения и освобождения памяти, очень существенная в некоторых ситуациях. Однако за нее приходится расплачиваться гибкостью, так как программист должен точно знать количество, жизненный цикл и тип объектов во время написания программы. Если задача плохо поддается прогнозированию (системы управления складом, авиадиспетчерские системы и т. д.), это приводит к чрезмерным ограничениям.

Во втором подходе объекты создаются динамически в специальном пуле памяти, называемом кучей. В этом случае программист до момента выполнения программы не знает, сколько объектов потребуется, каким будет их жизненный цикл или фактический тип. Эти решения принимаются "на месте" во время выполнения программы. Если программисту понадобится новый объект, он просто создает его в куче при помощи ключевого слова new. Когда объект становится ненужным, он ликвидируется при помощи ключевого слова delete.

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

Однако наряду с этими факторами существует и другой - продолжительность жизни объекта. Если объект создается в стеке или в статической памяти, продолжительность его существования определяет компилятор, автоматически уничтожая объект. Но если объект создается в куче, компилятор не располагает информацией о сроке его существования. В C++ программист должен самостоятельно уничтожить объект в своей программе при помощи ключевого слова delete. Впрочем, существует и другой вариант - в среде выполнения может поддерживаться механизм уборки мусора, который автоматически обнаруживает неиспользуемые объекты и уничтожает их. Конечно, уборка мусора существенно упрощает программирование, но, с другой стороны, она приводит к дополнительным затратам ресурсов. Этот факт не соответствовал требованиям, принятым при проектировании C++, поэтому механизм уборки мусора не стал частью языка (хотя для C++ существуют уборщики мусора, разработанные сторонними производителями).

Обработка исключений

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

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

Учтите, что обработка исключений не является объектно-ориентированным средством, хотя в объектно-ориентированных языках исключения обычно представляются объектами. Механизм обработки исключений появился раньше первых объектно-ориентированных языков.

Анализ и проектирование

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

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

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

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

В процессе разработки самое важное правило звучит так: "Не заблудитесь". Такое происходит очень часто. Многие методы из области аналитики и проектирования ориентированы на решение глобальных задач. Помните, что большинство проектов не относится к этой категории, поэтому обычно успешный анализ и проектирование удается провести на базе небольшого подмножества того, что рекомендует некоторый метод. И все же некий упорядоченный подход, сколь бы ограниченным он ни был, обычно помогает взяться за дело гораздо лучше, чем если вы просто начнете программировать.

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

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

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

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

  • Какие объекты будут задействованы в проекте? (Как разбивать проект на составляющие?)
  • Какими интерфейсами они будут обладать? (Какие сообщения должны отправляться каждому объекту?)
Даже если у вас не будет ничего, кроме представлений об объектах и их интерфейсах, можно переходить к написанию программы. По различным причинам вам могут потребоваться другие описания и документы, но меньшим обойтись невозможно.

Процесс условно делится на пять фаз с дополнительной нулевой фазой, на которой просто принимается решение об использовании той или иной структуры.

Фаза 0 - составление плана

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

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

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

Формулировка задачи

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

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

Фаза 1 - что делать

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

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

  • Кто будет использовать эту систему?
  • Какие операции смогут выполнять операторы?
  • Как оператор будет выполнять ту или иную операцию?
  • Какие еще возможны варианты, если та же операция будет выполняться кем-то другим или у того же оператора появится другая цель (анализ вариантов)?
  • Какие проблемы могут возникнуть при выполнении операции с системой (анализ исключений)?
Например, если вы проектируете банкомат, то функциональные требования будут описывать действия банкомата в любой возможной ситуации. Каждая из таких ситуаций называется сценарием. Сценарий можно рассматривать как вопрос, начинающийся со слов: "Как поступит система, если:?" Например: "Как поступит банкомат, если клиент только что сделал вклад с 24-часовым оформлением, а без зачисления чека на счету не хватает средств для снятия желаемой суммы?>

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

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

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

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

Хотя весь этот процесс больше напоминает шаманство, нежели научный метод, на какой-то стадии важно провести начальное планирование. Вы уже имеете некоторое представление о системе и можете хотя бы приблизительно оценить, сколько времени займет ее разработка. При этом приходится учитывать множество факторов. Если срок окажется слишком длинным, ваша компания может отказаться от разработки системы и потратить свои ресурсы на что-нибудь более разумное. А может, ваш начальник уже решил, сколько времени должна занять работа над проектом, и попытается повлиять на вашу оценку. Но лучше с самого начала составить честное расписание и принять все ответственные решения. Известно много способов планирования (как и способов прогнозирования биржевых котировок), и все же лучше всего положиться в этом вопросе на собственный опыт и интуицию. Прикиньте, сколько времени потребует ваш проект, затем удвойте это число и прибавьте еще 10 %. Скорее всего, ваше внутреннее ощущение вас не подводит; вам действительно удастся получить нечто работоспособное за это время. Еще столько же времени уйдет на то, чтобы привести это "нечто" к более или менее приличному виду, а последние 10 % уйдут на шлифовку и всякие мелочи . Однако все это еще нужно объяснить руководству, и несмотря на все стоны и попытки давления, которыми сопровождаются такие объяснения, дело обстоит именно так.

Фаза 2 - как делать

В этой фазе создается архитектура, описывающая классы и их взаимодействия. Прекрасная методика определения классов и их взаимодействий основана на использовании карточек CRC (Class-Responsibility-Collaboration - Класс-Ответственность-Взаимодействие>). Ценность данного инструмента отчасти обусловлена его предельной простотой. Вам понадобятся лишь пустые карточки 8 x 12 см. Каждая карточка представляет отдельный класс. На карточках записывается следующая информация.
  • Имя класса. Имя должно отражать сущность класса и быть понятным с первого взгляда.
  • Ответственность класса - то, что он должен делать. Обычно задается простым перечислением имен функций классов (поскольку при хорошем проектировании эти имена должны быть содержательными), однако может содержать и другую информацию. Если понадобится с чего-то начать, взгляните на проблему с точки зрения ленивого программиста: какие объекты должны появиться, чтобы ваша проблема сама собой решилась?
  • Взаимодействия класса - с какими другими классами должен взаимодействовать данный класс? Термин "взаимодействие" намеренно сделан предельно широким: под ним могут пониматься агрегирование или просто существование другого объекта, который выполняет работу по требованию объекта данного класса. Во взаимодействиях также должен учитываться круг пользователей класса. Например, если вы создаете класс Firecracker (фейерверк), какой класс будет им пользоваться: Chemist (химик) или Spectator (зритель)? Первый должен знать, какие реактивы требуются для составления смеси, а второй будет реагировать на яркие краски и узоры после взрыва.
Возможно, вам кажется, что карточки должны быть больше, чтобы на них поместилась вся нужная информация. Однако небольшие размеры выбраны намеренно - не только для того, чтобы классы были более компактными, но и чтобы предотвратить чрезмерную детализацию на слишком ранней стадии. Если все, что необходимо знать о классе, не помещается на маленькой карточке, значит, этот класс слишком сложен (вы либо увлеклись детализацией, либо класс нужно разбить на несколько классов). Идеальный класс должен быть понятен с первого взгляда. Карточки помогают выработать начальное представление об архитектуре системы, чтобы вы могли представить себе "общую картину", а уже потом занимались уточнением проекта.

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

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

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

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

Признаком завершения фазы 2 является законченное описание объектов и их интерфейсов: или по крайней мере их большей части - некоторые из них остаются неучтенными и выявляются только во время фазы 3. Это вполне нормальное явление. Важно лишь, чтобы все объекты были рано или поздно выявлены. Хорошо, когда они обнаруживаются на ранней стадии процесса, но ООП обладает достаточной структурной устойчивостью, так что более позднее обнаружение не принесет особого вреда. Процесс проектирования объектов можно разделить на пять стадий.

Пять стадий проектирования объектов

Проектирование объекта не ограничивается непосредственным написанием программы. В действительности процесс проектирования объектов состоит из нескольких последовательных стадий. Рассматривая его с этой точки зрения, вы не будете ждать, что вам удастся немедленно достичь совершенства. Достаточно осознавать, что понимание структуры объекта и его работы приходит со временем.
  1. Выявление объектов. Эта стадия происходит во время первоначального анализа программы. Выявление объектов основано на анализе внешних факторов и ограничений, дублирования элементов в системе и наименьших концептуальных единиц. При использовании библиотек классов выбор некоторых объектов оказывается очевидным. Анализ сходства между классами, которое может быть положено в основу выбора базовых классов и иерархии наследования, может происходить как на этой стадии, так и позднее в процессе проектирования.
  2. Доработка объектов. В процессе разработки объекта иногда выясняется, что объект должен содержать новые члены, отсутствующие в первоначальном проекте. Изменение внутреннего устройства объекта может потребовать поддержки со стороны других классов.
  3. Конструирование системы. Как уже отмечалось, на этой стадии иногда выявляются дополнительные требования к объектам. По мере углубленного изучения задачи происходит совершенствование ваших объектов. Необходимость взаимодействия с другими объектами в системе может повлиять на первоначальную структуру классов или потребовать введения новых классов. Например, может выясниться, что в системе нужны вспомогательные классы (вроде классов связанных списков), которые содержат минимум информации о состоянии (или вовсе не содержат ее) и просто облегчают работу других классов.
  4. Расширение системы. По мере расширения возможностей системы иногда выясняется, что это расширение упирается в несовершенство предыдущей архитектуры. На основании полученной информации вы можете реструктурировать часть системы, возможно, добавить новые классы или иерархии.
  5. Повторное использование объектов. На этой стадии класс проходит настоящее "испытание на прочность". Если кто-то попытается заново использовать его в принципиально новой ситуации, могут обнаружиться какие-то недостатки и недочеты. По мере адаптации класса к новым условиям все четче проявляются общие принципы работы класса, пока вы не получите тип, действительно подходящий для повторного использования. Но не стоит ожидать, что многие объекты в системной архитектуре должны иметь универсальный характер - вполне нормально, если большинство объектов ориентировано на конкретную систему. Типы, подходящие для повторного использования, встречаются реже и ориентируются на решение более общих задач.

Рекомендации по разработке объектов

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

Фаза 3 - построение ядра

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

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

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

Фаза 4 - итеративный перебор сценариев

Получив работоспособное ядро, вы начинаете добавлять к нему новые возможности. Каждая группа возможностей может рассматриваться как мини-проект, а ее реализация занимает в цикле разработки относительно короткий период, который называется итерацией.

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

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

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

Фаза 5 - эволюция

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

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

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

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

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

Главное, о чем необходимо помнить, - что по умолчанию (а скорее, даже по определению) модификация класса не должна нарушать работу его базовых и производных классов. Не бойтесь модификации (особенно если у вас имеется встроенный набор модульных тестов для проверки их правильности). Модификации не всегда нарушают работу программы, а любые изменения результата будут ограничиваться производными классами и/или отдельными классами, взаимодействующими с измененным классом.

О пользе планирования

Никому не придет в голову строить жилой дом без множества тщательно проработанных планов. Если вы строите сарай или собачью будку, процесс планирования будет не столь тщательным, но, скорее всего, вы все же сделаете хотя бы простейшие наброски и будете руководствоваться ими. Программирование часто бросалось в крайности. В течение долгого времени разработки вообще не структурировались, но это стало приводить к провалам крупных проектов. В ответ появились новые методологии, невероятно детальные и структурированные, ориентированные прежде всего на крупные проекты. Эти методологии были слишком жуткими - казалось, программисту придется тратить все время на написание документации, а на программирование его уже не останется (кстати, на практике так часто и выходило). Все это наводит на мысль о "золотой середине" - подвижной шкале. Используйте тот способ, который лучше соответствует вашим потребностям (и вашим личным предпочтениям). Но каким бы расплывчатым ни был ваш план, помните, что проекты с хоть каким-нибудь планом идут гораздо лучше проектов, полностью лишенных всякого плана. Также не стоит забывать, что по статистике свыше 50 % проектов завершаются неудачей (а по некоторым данным - до 70 %)!

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

Экстремальное программирование

Автор начал изучать методы анализа и проектирования еще в аспирантуре. Из всего, с чем удалось познакомиться, концепция экстремального программирования (eXtreme Programming, XP) была наиболее радикальной и восхитительной. Ее описание можно найти в книге Кента Бека (Kent Beck) "Extreme Programming Explained>1 и на сайте www.xprogramming.com.

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

Начинайте с написания тестов

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

В экстремальном программировании концепция тестирования полностью пересматривается, и ей уделяется такое же (а то и более важное) значение по сравнению с программированием. Более того, тесты пишутся раньше тестируемого кода и остаются с ним навечно. Тесты должны успешно выполняться при каждой интеграции проекта (что нередко означает "чаще одного раза в день>).

Написание тестов в начале проекта имеет два исключительно важных последствия.

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

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

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

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

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

Парное программирование

Парное программирование противоречит закоренелому индивидуализму, который нам прививают всю жизнь, начиная со школы (где все успехи и неудачи засчитываются лично нам, а взаимодействие с соседями считается жульничеством) и кончая средствами массовой информации, особенно голливудскими фильмами, в которых герой-одиночка обычно противостоит безликой массе злодеев1. Программисты также считаются воплощением индивидуализма - "ковбоями от программирования", как любит выражаться Ларри Константайн (Larry Constantine). И все же экстремальное программирование, которое ломает сложившиеся стереотипы, утверждает, что программу должны писать двое работников за одним рабочим местом. Более того, рабочие места в группах не должны разделяться перегородками, которые так любимы дизайнерами наших рабочих помещений. Бек говорит, что при переходе на экстремальное программирование нужно прежде всего взять гаечные ключи и разобрать все, что мешает общению (для этого также понадобится начальник, который усмирит гнев хозяйственного отдела).

Главная ценность парного программирования заключается в том, что один программист пишет программу, а второй думает. Этот второй представляет себе общую картину, помня не только о непосредственно решаемой задаче, но и о правилах XP. Когда работают двое, вряд ли кто-нибудь заявит: "Я не хочу писать тесты с самого начала". Если программист окажется в тупике, он может поменяться местами с напарником. А если в тупике окажутся оба, возможно, их разговоры услышит кто-нибудь другой, кто сможет помочь. Парная работа способствует нормальному продвижению проекта, но не менее важно и то, что программирование становится более социальным и интересным занятием.

Автор начал использовать парное программирование на практических занятиях своих учебных курсов. На взгляд автора, оно значительно улучшает восприятие материала учащимися.

Причины успеха C++

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

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

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

Улучшенный язык C

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

Быстрое обучение

Главная проблема с изучением нового языка часто связана с производительностью труда программиста. Ни одна компания не может себе позволить вдруг лишиться эффективно работающего программиста только потому, что он изучает новый язык. C++ является расширением C, его синтаксис и модель программирования не будут абсолютно новыми для программиста. Благодаря этой особенности программист по-прежнему пишет полезные программы, используя новые возможности по мере их изучения. Возможно, это одна из главных составляющих успеха C++.

Кроме того, весь существующий код C может компилироваться в C++, но так как компилятор становится более придирчивым, при перекомпиляции в программах C часто обнаруживаются скрытые ошибки.

Эффективность

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

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

Простота описания и понимания системы

Классы, спроектированные для решения проблемы, обычно выражают ее лучше обычного кода. Это означает, что при написании программы решение представляется в пространстве задачи (<Замкнуть контакт>), а не в пространстве машины (<Установить бит, который является признаком замыкания контакта>). Программист работает с концепциями более высокого уровня, а одна строка программы несет гораздо большую смысловую нагрузку.

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

Максимальная интеграция с библиотеками

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

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

Шаблоны и повторное использование исходных текстов

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

Обработка ошибок

Как известно, обработка ошибок в C порождала немало проблем. Нередко проблема просто игнорировалась и программист полагался "на авось". При построении большого и сложного проекта нет ничего хуже, чем обнаружить ошибку, которая находится неизвестно где. Механизм обработки исключений (кратко упомянутый в этом и подробно рассматриваемый во втором томе) гарантирует, что ошибка будет обнаружена и каким-то образом обработана программой.

Масштабное программирование

Во многих традиционных языках существуют встроенные ограничения на размеры и сложность программ. Например, BASIC прекрасно подходит для разработки быстрых решений некоторых классов задач, но если программа занимает больше нескольких страниц или выходит за рамки обычной области применения этого языка, программирование начинает напоминать плавание в непрерывно густеющей жидкости. У языка C тоже есть свои ограничения. Например, когда объем программы превышает 50 000 строк кода или около того, начинаются проблемы с конфликтами имен - фактически у вас просто кончаются удобные имена функций и переменных. Другая неприятная проблема связана с недоработками самого языка C - в большой программе иногда бывает очень трудно найти ошибку.

Не существует четких критериев, определяющих границы применимости языка, но даже если бы такие критерии и были, скорее всего, вы бы их игнорировали. Никто не скажет: "Моя программа на BASIC слишком велика - пожалуй, ее стоит переписать на C!" Вместо этого вы попытаетесь затолкнуть в нее еще несколько строк и добавить "всего одну" новую возможность. В конечном счете это обернется лишними затратами при сопровождении.

Язык C++ проектировался для масштабного программирования, при котором стираются грани между мелкими и крупными программами. Конечно, при написании утилиты сложности "Hello, World!" вам не придется использовать ООП, шаблоны, пространства имен и обработку исключений, но эти возможности присутствуют в языке и могут задействоваться при необходимости. С другой стороны, компилятор с одинаковым рвением выискивает ошибки как в больших, так и в мелких программах.

Стратегии перехода

Если вы твердо решили перейти на ООП, возникает следующий вопрос: "Как заставить начальство/коллег/другие отделы перейти на использование объектов?" Подумайте, как бы вы - независимый программист - перешли на изучение нового языка и новой парадигмы программирования. Вам ведь уже приходилось делать это раньше, не правда ли? Все начинается с обучения и примеров; далее следует экспериментальный проект, который позволяет прочувствовать суть дела без лишних сложностей. Затем наступает черед "реального" проекта, который делает что-то полезное. На протяжении первых проектов вы продолжаете обучение - читаете книги, задаете вопросы знатокам и обмениваетесь полезной информацией с друзьями. Так выглядит рекомендуемая многими опытными программистами процедура перехода с C на C++. Конечно, при переходе целой организации добавится некоторая групповая динамика, но на каждом этапе стоит помнить, как бы эта задача решалась одним человеком.

Рекомендации

Ниже приводятся некоторые рекомендации по переходу на ООП и C++.

Обучение

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

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

Проекты с низкой степенью риска

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

Успешные решения

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

Готовые библиотеки классов

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

Существующие программы на C++

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

Организационные трудности

Если вы работаете на руководящей должности, ваша задача - предоставить все необходимые ресурсы, преодолеть все препятствия на пути к успеху и вообще создать наиболее продуктивную и приятную рабочую среду, чтобы вашим подчиненным было легче совершать те чудеса, которых от вас вечно требует начальство. Переход на C++ влияет на все три категории задач, и все было бы замечательно, если бы за него не приходилось платить. Хотя для группы программистов C переход на C++ может обойтись дешевле перехода на другие объектно-ориентированные языки1, он все же потребует определенных затрат. Существует целый ряд препятствий, о которых необходимо знать, прежде чем вы решитесь перейти на C++ и перевести на него вашу организацию.

Начальные издержки

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

Проблемы эффективности

Стандартный вопрос: "Разве от применения ООП мои программы не становятся больше и не начинают работать медленнее?". Ответ: "Когда как". Большинство объектно-ориентированных языков проектировалось с расчетом на эксперименты и ускоренную разработку прототипов, нежели на быстроту и эффективность. "p>Соответственно, они практически всегда приводили к увеличению объема и снижению быстродействия программ. Однако язык C++ проектировался для реального программирования. Стремясь побыстрее создать прототип, вы как можно скорее связываете готовые компоненты, не обращая внимания на эффективность. Если при этом используются библиотеки сторонних производителей, они обычно уже оптимизированы своими разработчиками; впрочем, в режиме ускоренной разработки это обычно несущественно. Если в результате получается система, которая делает то, что нужно, и достаточно быстро, работа закончена. А если нет, приходится браться за профайлер и начинать оптимизацию. Поиск начинается с тех усовершенствований, которые могут быть реализованы встроенными средствами C++. Если это не приносит успеха, вы переходите к оптимизации внутренней реализации, чтобы сохранить в неприкосновенности код работы с классами. Только если это не помогает, приходится вносить изменения в архитектуру системы. Тот факт, что эффективность играет критически важную роль в архитектуре системы, свидетельствует о необходимости ее включения в исходные критерии проектирования. Средства быстрой разработки позволяют вовремя это понять.

Как уже упоминалось, различия в быстродействии и размерах программ C и C++ чаще всего характеризуются величиной +10 %, хотя обычно они гораздо ближе друг к другу. В отдельных случаях применение C++ вместо C даже обеспечивает значительный выигрыш в быстродействии и размерах программы, потому что архитектура программ C++ может существенно отличаться от архитектуры программ C.

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

Распространенные ошибки проектирования

В первое время после перехода на ООП и C++ программисты обычно совершают одни и те же стандартные ошибки. Это часто происходит из-за нехватки общения с экспертами в ходе проектирования и реализации первых проектов, потому что свои эксперты в компании еще не появились, а намерение пригласить платных консультантов может столкнуться с возражениями. Многие новички воображают, что они уже разобрались в ООП, и идут в неверном направлении. То, что очевидно опытному программисту, может вызвать долгую внутреннюю борьбу у новичка. Чтобы обойтись без лишних переживаний, для обучения персонала лучше пригласить эксперта.

С другой стороны, простота, с которой совершаются эти ошибки проектирования, указывает на главный недостаток C++ (который одновременно является главным достоинством): его совместимость с языком C. Чтобы можно было компилировать код C, разработчикам C++ пришлось пойти на некоторые компромиссы, что привело к появлению неких "темных мест" - вполне реальных и требующих немалых усилий при изучении языка. В этой книге автор постарался раскрыть большинство ловушек, часто встречающихся при программировании на C++. Всегда помните, что система страховки от ошибок в C++ не идеальна.

Итоги

В этой главе автор постарался дать представление об общих перспективах объектно-ориентированного программирования и С++. В частности, были описаны отличительные особенности ООП (и C++ в частности), методологии ООП, а также некоторые проблемы, встречающиеся при переходе компании на ООП и C++.

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

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

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

Главные события недели
DVD доживает свой век

 
Формат DVD стал одним из наиболее востребованных на потребительском рынке высоких технологий, однако ничто не вечно под Луной. За наследство "уходящего короля" вот-вот разразится нешуточная война. Для потребителей, которые уже привыкли к DVD плеерам, производители электронных устройств готовят новинки - дисковые носители нового поколения с большей вместимостью и повышенной защищенностью от несанкционированного копирования. Конкуренты готовятся к выяснению отношений. [Вернуться в оглавление]

Представительная группа компаний, во главе которой стоит Sony Corp., продвигает на рынок так называемые Blu-ray диски. С ней соперничают Toshiba Corp. и NEC Corp., рекламирующие свой High Definition DVD. Несмотря на то, что действуют они лишь вдвоем, у японских компаний сильные козыри: поддержка промышленности, а также, возможно, самой корпорации Microsoft - софтверный гигант ищет союзников в выведении своего нового мультимедийного формата на рынок потребительской электроники.

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

Что касается рядового потребителя, то ему новый формат принесет большую четкость изображения. Продажи телевизионных приемников высокой четкости (high definition TV, HDTV) уже начались, однако возможности современных DVD не позволяют продемонстрировать все, на что способно телевидение нового поколения.

С точки зрения производителей, новый формат позволит им выбраться из сектора крайне дешевой потребительской электроники, куда они сами и угодили. Если в 1997 году DVD плеер стоил $500, то теперь отдельные модели можно купить за $50 и ниже.

Для считывания информации с дисков нового поколения будет использоваться не красные, как в CD и DVD, а голубые лазеры. Их применение позволит записывать на диск такого же размера, как обычный DVD, в 3-5 раз больше информации. Это позволит воспроизводить полноценное видеоизображение высокой детальности со звуком в режиме surround. При этом обе группы разработчиков планируют встроить в свои плееры и красные лазеры, что позволит воспроизводить на них также обычные DVD.

Что касается емкости новых дисков, то здесь лидирует технология Blu-ray - она позволяет записать на один диск до 50 ГБ информации. Правда, их внутренняя структура сильно отличается от структуры дисков DVD, и промышленности придется вложить немалые средства в новое оборудование.

Диски HD-DVD компании Toshiba позволяют записывать до 30 гигабайт, однако могут еще ближе приблизиться к рекордсмену, использовав более выгодный, чем уже используемый в DVD и планируемый для Blu-ray формат сжатия MPEG-2. Одной из схем сжатия данных, которая рассматривается в качества кандидата и может войти в стандарт HD-DVD, является Windows Media 9 производства Microsoft. По мнению аналитиков, это стало бы огромной победой Microsoft. Помимо отчислений "роялти" с каждого плеера (предположительно 10-15 центов с каждого устройства), корпорация получила бы блестящую возможность выйти на рынок потребительской электроники.

Пока две технологии готовятся сойтись в решающей схватке, у них появляются новые конкуренты. Прогресс в области алгоритмов сжатия данных позволяет уже сейчас записывать на обычные (или слегка модифицированные) DVD видео высокой детальности - правда, худшего, по сравнению с системами на голубых лазерах, качества и с меньшим перечнем дополнительных функций. Так, еще в прошлом году Microsoft представила версию фильма "Терминатор 2: судный день" "Terminator 2: Judgment Day" в формате высокой детальности на обычном DVD-ROM. Правда, для его воспроизведения требовался компьютер. Урок не пропал даром: в Китае уже продаются диски EVD (Enhanced Video Disc). В них используется программное обеспечение компании On2 Technologies Inc. Тайванские разработчики представили FVD (Forward Versatile Disc), основанный на схожих принципах. Плееры для них поступят в продажу уже в этом году. Несмотря на очевидные преимущества систем на голубых лазерах, исход борьбы непредсказуем. Голубые лазеры намного дороже красных, и к тому же в проигрыватель "голубых" дисков придется вводить два лазера для совместимости с DVD и CD. Вполне возможно, что выработать мировой стандарт преемника DVD не удастся, и конкуренты начнут жить собственной жизнью. При этом, вероятно, Blu-ray будет доминировать в Японии, более дешевый EVD - в азиатских странах, а в США и Европе будет господствовать HD-DVD.

Исход борьбы, очевидно, определит голос Голливуда. Новый формат манит производителей видео своими возможностями: во-первых, лучшей защитой от подделок, во-вторых, возможностью начать продажи старых фильмов уже на новых носителях.

Из крупных кинокомпаний к настоящему времени определилась только Columbia TriStar, но она принадлежит Sony, так что с ее выбором все ясно. Кстати, последняя уже начала продажи Blu-ray рекордера для спутникового телевидения стандарта HDTV. Пока только в Японии.

обсудить ::

оглавление ::


"Евросеть" оштрафовали за мат

 
Нижегородское территориальное управление Министерства по антимонопольной политике оштрафовало сеть мобильной связи "Евросеть" за намек на непечатное слово в рекламной листовке. Местной «Евросети» (ООО "Выставка мобильной связи НН") предстоит расстаться с 40 тыс. рублей. [Вернуться в оглавление]

Как сообщает Нижегородское телеграфное агентство, пытаясь привлечь покупателей в свои салоны, «Евросеть» распространяла среди нижегородцев рекламную листовку, содержащую хорошо знакомое москвичам выражение "Цены просто о…", которое в МАПе сочли нецензурным. В соответствии со статьей 8 Закона РФ "О рекламе" комиссия МАП посчитала рекламу неэтичной. Примечательно, что на заседании этой комиссии никто из представителей названного ООО не явился. Впрочем, у «Евросети» еще есть для демонстрации своей активности десять дней, в течение которых компания имеет право обжаловать решение антимонопольного министерства.

Руководитель пресс-службы «Евросети» Татьяна Гуляева рассказала CNews.ru, что руководство московского офиса, разумеется, в курсе этой неприятной истории. «Этот слоган - «Евросеть, Евросеть, цены просто о…ть» мы используем с 1999 года, - отметила она. – И значение слова «о..ть» каждый понимает так, как хочет понимать. Это может быть и «одуреть», и «обалдеть», и т.д.». По словам г-жи Гуляевой, нецензурных выражений в своих рекламных кампаниях «Евросеть» не использует. «Прекращать использование этого слогана мы не собираемся, он будет существовать до тех пор, пока будет себя отрабатывать, - считает она. - Скорее всего, данное решение МАП будет нами обжаловано».

От себя добавим, что этот слоган компания использует не только в целях обретения «своего» покупателя в России, но и для продвижения бренда на международных выставках. Например, его могли слышать безо всякой цензуры посетители стенда «Евросети» на выставке CEBIT-2004.

Рекламными слоганами за гранью приличия не брезгует и другой ретейлер, позиционирующий себя как продавца дешевой бытовой электроники. Речь идет о торговой сети «Эльдорадо», которой сегодня принадлежит свыше 360 магазинов в стране. Недавно «Эльдорадо» запустила сразу в 60 российских городах скандальную рекламную кампанию. На рекламных щитах изображен пылесос LG и слоган «Пыль сосу за копейки», причем реклама задумана так, что слово «пыль» сливается с фоном и практически не заметно. В самой фирме данную рекламную акцию считают удачным ходом по продвижению своих товаров. Так, в интервью изданию «Деловой Петербург» руководитель отдела рекламы компании «Эльдорадо» Татьяна Ивакина отметила, что раз внимание на рекламу торговой сети обратили все, значит, «Эльдорадо» правильно выбрала идею, и рекламную кампанию можно назвать успешной.

Однако эксперты по рекламе считают, что данная кампания является «игрой на грани фола», которая приведет к санкциям со стороны регулирующих органов. Генеральный директор Ассоциации рекламодателей Вадим Желнин, комментируя RBC daily данную ситуацию, не исключает, что после соответствующих экспертиз она может быть признана аморальной. Интересно, что для «Эльдорадо» это уже далеко не первый скандал вокруг ее рекламы «ниже пояса». Например, в одном из телероликов девушка с вожделением наблюдала, как у фотоаппарата вырастает зум, а в другом ролике - мужчина вынимал из стиральной машины и развешивал на веревке презервативы. Похоже, и новый ролик с пылесосом беспрепятственно продолжит свое шествие по стране. Правда, предвидя возможные проблемы и оперативность антимонопольных органов, в «Эльдорадо» все-таки заранее приготовили наклейки со словами «Отдамся за копейки. Твоя цена». Но на днях в Москве и эта надпись (кстати, также достойная отдельного разбирательства), была заменена на совсем целомудренное «Ой!».

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

обсудить ::

оглавление ::


Русские предлагают азиатам выпускать чудо-мобильник

 
Характеристики концепта мобильного телефона, созданного сотрудниками дизайн-бюро «Проект», очень сильно похожи на научную фантастику. Реализовать свои идеи на массовом рынке российские специалисты предлагают японцам, сингапурцам и корейцам. [Вернуться в оглавление]

К сожалению, до появления даже первых прототипов (не говоря уже про серийные образцы) пройдет еще время. Как сообщил CNews.ru креативный директор «Проекта» Роман Крихели, сейчас #1 Phone (так окрестили его разработчики) существует только в виде трехмерной модели, изображения которой и предоставили создатели.

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

Пока речь идет только о GSM 900/1800/1900, но о перспективах сетей третьего поколения тоже не забывают. Не стали отказываться и от того, что получило распространение уже сегодня: bluetooth-модуль имеет все шансы на присутствие в телефоне. Интересен способ зарядки аппарата. Технология Splash Power позволяет зарядить аккумулятор, только положив телефон на специальный коврик. Вся лицевая поверхность – это полноцветный сенсорный экран: его размеры по диагонали будут более четырех дюймов, а разрешение составит 700х266 точек. Не очень ясна ситуация с операционной системой или другим подобным программным обеспечением, которое будет использоваться в аппарате.

#1 Phone 
#1 Phone
Характеристики, разумеется, очень сильно похожи на научную фантастику, но российские разработчики сообщили CNews.ru, что для воплощения в жизнь их замыслов будут приложены все усилия. «Уже сейчас мы ведем переговоры с потенциальными производителями, - говорит Роман Крихели. - К сожалению, конкретных названий фирм-изготовителей мы назвать не можем, но речь идет об одном японском производителе, специализирующимся на адаптации концептов для серийного производства, фирме из Сингапура и корейской компании». Похоже, что именно корейцы имеют самые масштабные планы в отношении разработки россиян. К сожалению, в нашей стране не удалось найти даже потенциальных возможностей для реализации проекта усилиями локальных компаний.

Любопытно, что в плане «Проекта» присутствуют и конкретные сроки коммерческой реализации концепта #1 Phone. Если все будет хорошо, то первые образцы мы сможем увидеть уже через год-полтора, но жизнь, как известно, часто вносит коррективы даже в самые осторожные планы.

Некоторые уточнения CNews.ru удалось получить и по поводу технических характеристик будущего прототипа. Во-первых, изменения уже коснулись элементов питания (это, пожалуй, одна из самых слабых сторон новой разработки). Изначально планировалась реализовать топливные элементы, но сейчас серьезно задумались о применении технологии молекулярных граней, которая, судя по прогнозам, должна получить широкое распространение в ближайшие год-два. Емкость подобных батарей будет примерно в 4 раза больше привычных li-ion и li-pol-решений. Благодаря этому новинка не будет уступать современным телефонам по времени автономной работы, хотя энергопотребление устройства возрастет в несколько раз.

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

обсудить ::

оглавление ::


Цена пароля - шоколадка

 
Почти три четверти респондентов, принявших участие в импровизированном опросе на улицах Лондона, были готовы отдать свои пароли в обмен на шоколад. На проходящей сейчас конференции Infosecurity Europe 2004 аналитики обнародовали результаты исследования, проведённого около оживленной станции Liverpool Street лондонской «подземки»: они выяснили, что 71% офисных служащих добровольно предоставят свои пароли для входа в компьютерные системы за шоколадный батончик.[Вернуться в оглавление]

Примерно 37% опрошенных сразу сказали свои пароли. А в случае, если сначала опрошенный отказывался назвать пароль, исследователи применяли тактику социотехники, пытаясь угадать, не совпадает ли пароль с именем домашнего животного или ребёнка, и тогда еще 34% тут же называли свой пароль.

Самыми распространёнными категориями паролей были имена домашних (15%), далее шли названия футбольных команд (11%) и имена домашних животных (85%). Наиболее употребляемым паролем стало слово «admin». Один из опрошенных сказал: «Я работаю в финансовом call-центре, пароли у нас меняются каждый день, и чтобы не было проблем с запоминанием, их пишут у нас на доске, чтобы все могли их видеть».

В ходе исследования также выяснилось, что обнадеживающие 53% пользователей никогда бы не дали свой пароль по телефону человеку, который скажет, что звонит из ИТ-отдела, четверо из десяти знают пароли своих коллег, 55% сказали, что дали бы пароль своему начальнику. Две трети служащих используют одни и те же пароли на работе и для персонального доступа к онлайновым банковским службам, и для доступа на защищённые сайты. Обычно люди используют около четырёх слов в качестве пароля, хотя один системный администратор использует 40 слов, которые он хранит в программе, специально написанной им самим, для безопасного хранения этих паролей. 51% опрошенных меняют свои пароли ежемесячно, 3% - еженедельно, 2% - каждый день, 10% занимаются этим раз в квартал, 13% - очень редко и 20% опрошенных вообще никогда их не меняют. Большинство из тех, кому регулярно приходится менять пароли, хранят их на обрывке бумаги в ящике стола или в документе Word на компьютере.

обсудить ::

оглавление ::


Салоны связи охотятся за ночными платежами

 
Салоны связи с графиком работы 24 часа – на первый взгляд, предприятия заведомо убыточные. Ночная прибыль, получаемая от работы магазина, не превышает четвертой части дневного оборота. Тем не менее, все больше дистрибьюторов, работающих на рынке сотовой связи, проявляет интерес к ночному рынку. Так, на прошлой неделе группа компаний DIXIS объявила о переходе двух торговых точек на круглосуточное обслуживание, войдя в тройку специализированных сетей, предоставляющих подобные услуги. Однако, несмотря на похожую стратегию, дистрибьюторы возлагают разные надежды на работу магазинов, функционирующих круглые сутки. [Вернуться в оглавление]

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

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

Мнения представителей компаний несколько расходятся на это счет. Группа компаний DIXIS придерживается мнения, что деятельность круглосуточного магазина направлена на предоставление расширенного спектра услуг в области телекоммуникационного обслуживания. «Это и часть имиджа компании, и коммерческий проект, - считает руководитель службы по связям с общественностью группы компаний DIXIS Кирилл Лубнин. - Возможно, что круглосуточный режим работы существенно не увеличит объем продаж сотовых телефонов или иной цифровой портативной техники, но позволит сделать удобным процесс оплаты счетов за мобильную связь и другие услуги». PR-директор компании «Евросеть» Татьяна Гуляева полагает, что данный ход скорее имиджевый, чем связанный с получением прибыли: «Да, это шаг, направленный на повышение лояльности клиентов «Дворца связи», которые знают, что в любое время есть возможность пополнить счет, купить телефон или аксессуар».

Однако далеко не все дистрибьюторы считают, что открытие магазина, работающего круглые сутки, - удачный ход по улучшению имиджа. Например, «Техмаркет» заявляет, что открывать круглосуточные магазины не собирается, т.к., по мнению руководства компании, это совершенно нерентабельно: «Это экономически не оправдано и не востребовано покупателями. Конечно, расширение спектра услуг - хорошо как факт, но ведь каждая из этих услуг должна быть, во-первых, интересна покупателям и, во-вторых, экономически выгодна, - считает PR-менеджер компании «Техмаркет» Оксана Хрусталь. - Круглосуточный режим работы салона - услуга, которая не попадает в эту категорию. Целесообразно создавать лояльность покупателей востребованными и оригинальными услугами, к таковым мы относим, например, введение дисконтных программ».

Круглосуточный магазин «Связного» на Тверской еще не открыт и о его будущей деятельности говорить пока рано. Однако PR-менеджер «Связного» Анна Свердлова, раскрывая некоторые секреты, говорит, что это будет не просто магазин, работающий круглые сутки, а нечто принципиально новое: «Это не имиджевый ход, и мы не стремимся завоевать доверие клиентов этим проектом. Открытие состоится после майских праздников, там и будет все ясно».

Таким образом, проект салона сотовой связи, с графиком работы 24 часа, выглядит нерентабельно и нецелесообразно. Если принять во внимание сухой коммерческий расчёт, то картина получается несколько иная. Давайте проанализируем структуру расходов. Что касается расходов на аренду помещения, то они никак не возрастают. Продлевать или переделывать лицензию также не требуется. Фактически, затраты складываются только из расходов на содержание персонала, которому придется работать по ночам. В среднем, одну точку обслуживают 2 человека: один-два продавца и охранник. Учитывая, что в это время суток акцент делается на платежи, то сумма расходов не велика, и они должны окупаться, поскольку салоны подобного рода находятся в местах людных, где поток клиентов сохраняется практически до утра.

Таким образом, салон сотовой связи с круглосуточным графиком работы - предприятие если и не выгодное, то, по крайней мере, не слишком убыточное и интересное с точки зрения имиджа.

обсудить ::

оглавление ::


Позднее рождение Kaspersky 5

 
«Лаборатория Касперского» представила новую версию своего антивируса для персонального использования – Personal 5.0. Принимая во внимание пожелания и жалобы пользователей, компания полностью изменила интерфейс своего продукта, добавила в него несколько новых технологических решений, вследствие чего новый антивирус должен работать намного качественнее, стабильнее и быстрее, чем предыдущие версии. Россия стала первой страной, где, хотя и с задержкой, компания представила Personal 5.0. [Вернуться в оглавление]

Известно, что вначале «Лаборатория Касперского» планировала выход 5-й версии персонального антивируса на осень 2003 г. Однако осуществить задуманное не получилось. Для того чтобы понять, что произошло, необходимо немного обратиться к предыстории создания продукта. «Предыдущая версия антивируса (Personal 4.5) – состоит из отдельных компонент. В зависимости от конкретных задач, пользователь мог вызывать те или иные из них, - заявила Наталья Касперская, генеральный директор «Лаборатории Касперского». - Как показала практика – это было слишком сложно для среднего пользователя. Поэтому в новой версии мы хотели реализовать программу таким образом, чтобы все эти отдельные модули были собраны в какие-то логические структуры».

«Для того чтобы упростить антивирус, необходимо было полностью изменить его архитектуру. В процессе изменения было допущено несколько серьезных ошибок. В результате, когда до выхода продукта оставалось совсем немного времени, выяснилось, что новая архитектура не работает. Пришлось все переделывать с нуля», - так объяснили представители «Лаборатории Касперского» вынужденную задержку выхода своего нового продукта.

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

Разрабатывая интерфейс новой версии, «Лаборатория Касперского» провела 4 раунда исследований. «Было создано несколько специальных фокус-групп в США, Европе (3 страны) и России. Велась активная работа на выставках, конференциях. Основной целью опросов было выяснить, что пользователям хотелось бы увидеть в новом продукте, чего им не хватает», - так Наталья Касперская описала процесс разработки интерфейса.

Пятая линейка антивирусов «Лаборатории Касперского» будет представлена следующим образом:

  • Personal 5.0;
  • Personal Pro 5.0 (выйдет);
  • Workstation 5.0 (выйдет);
  • Windows File Server 5.0 (антивирус для файлового сервера) (выйдет);
  • Admin 5.0 (выйдет).

    Вследствие того, что lite-версия Антивируса Касперского не нашла спроса на рынке, «Лаборатория Касперского» не планирует поддерживать ее в дальнейшем. Все аппаратное обеспечение, которое ранее поставлялось с lite-версией, теперь будет поставляться с антивирусом Personal 5.0.

    Представители «Лаборатории Касперского» отметили, что цена на продукты не изменится (по крайней мере, до осени), каналы продаж остаются прежними. С 17 мая «Антивирус Касперского Personal 5» появится в интернете и в магазинах.

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

    Презентации антивируса во Франции и Великобритании состоятся 27 апреля. 13 мая продукт будет официально представлен в Германии.

  • обсудить ::

    оглавление ::


    Старые недостатки TCP могут парализовать интернет

     
    Британские ученые из правительственного агентства по изучению вопросов информационной безопасности опубликовали сведения о критической уязвимости, обнаруженной в протоколе TCP. Используя ее, злоумышленники могут отключать от Сети любые компьютеры и препятствовать нормальной работе маршрутизаторов, координирующих движение магистрального трафика. Говоря фигурально, брешь в основном протоколе транспортного и сеансового уровней позволяет разрушит "цемент", соединяющий Сеть в единое целое. Существование уязвимости обусловленно структурой протокола TCP, однако до сих пор считалось, что воспользоваться ею на практике не возможно. Похоже, время внесло свои коррективы.[Вернуться в оглавление]

    Описываемая уязвимость существует в версиях протокола TCP (Transmission Control Protocol - протокол контроля передачи), соответствующих спецификациям проблемной группы проектирования интернета (IETF) RFC 793 и RFC 1323. И хотя данная уязвимость существовала в TCP с самого момента его создания в 1981 году, оказалось, что TCP-сессии, в которых известны адреса как источника, так и реципиента передаваемой информации, могут быть перехвачены злоумышленниками гораздо более простыми методами, чем считалось раньше. Речь идёт о том, что путём спуфинга (имитации чужого IP-адреса или другого TCP-порта) можно повторно инициализировать установленное TCP-соединение, отправив пакеты, соответствующие параметрам соединения с установленными флагами RST (сброс) или SYN (синхронизация). Критичность уязвимости зависит от типа используемого оборудования, защита от её использования не предусмотрена ни одним вендором.

    Как сообщается в бюллетене, наиболее подвержен атакам пограничный межсетевой протокол BGP (Border Gateway Protocol), используемый для обмена данными между таблицами интернет-маршрутизации. Маршрутизаторы магистральных сетей используют BGP для постоянного обновления информации о важных изменениях в потоках трафика для выбора наиболее оптимального маршрута. Успешные атаки на маршрутизатор могут привести к его остановке на несколько часов, так называемому "подавлению". Потенциально уязвимость может воздействовать также и на службу доменных имен DNS (Domain Name System), и на протокол защищенных сокетов SSL (Secure Sockets Layer). Теоретически, возможна фальсификация передачи данных.

    Департамент государственной безопасности США через несколько часов после опубликования бюллетеня выпустил предупреждение, в котором говорится, что "атаки могут поразить значительный сегмент интернет-сообщества". Хотя по окончании атак возможно восстановление нормального функционирования Сети. "Пользователи интернета оказались в положении человека, бегущего голым по джунглям. Это безопасно до тех пор, пока не появятся тигры, - считает Пол Викси (Paul Vixie), представитель общественной организации Internet Systems Consortium. - Важно ликвидировать возможность использования этой уязвимости до того, как "плохие парни" получат от этого какую-либо выгоду, начав эксплуатировать её просто ради развлечения или из любопытства".

    "Любая "дыра" в фундаментальном протоколе вызывает серьезное беспокойство и требует самого пристального внимания лиц, ответственных за функционирование инфраструктуры интернета. Этот конкретный случай уже с прошлой недели стал основной темой разговоров среди специалистов по безопасности", - цитирует издание Аustralian IT News слова Амита Йорана (Amit Yoran), главы департамента кибербезопасности США.

    Возможность практического использования изначально заложенной в протокол TCP ошибки была продемонстрирована американским исследователем Полом Уотсоном (Paul Watson) еще в конце прошлого года. Публичное сообщение о возможности использования уязвимости предваряет доклад г-на Уотсона на конференции по информационной безопасности в Ванкувере, который состоится на этой неделе. На конференции будут представлены основные выкладки изысканий в области обеспечения безопасности TCP.

    обсудить ::

    оглавление ::


    Nokia провалилась на рынке телефонов с камерами

     
    Финский телекоммуникационный гигант Nokia, бессменный лидер рынка мобильных телефонов, практически провалился в сегменте трубок с камерами. По итогам первого квартала конкуренты – шведско-японский Sony Ericsson и корейский Samsung Electronics – увеличили свои рыночные доли, прибыли и продажи. Sony Ericsson и вовсе удалось вырваться на первое место по продажам мобильников с камерами. Финны же, напротив, разочаровали инвесторов. [Вернуться в оглавление]

    По данным аналитической компании Strategy Analytics, в первом квартале 2004 года лидером рынка телефонов с цветными дисплеями и камерам стал Sony Ericsson, заметно обогнавший конкурентов. Рыночная доля компании выросла до 30%, против 18% у Samsung Electronics и всего 6% у Nokia. Хотя Nokia по-прежнему лидирует на рынке в целом, в сегменте телефонов с камерами у нее откровенно слабые позиции. Sony Ericsson же, напротив, пока не добился существенных успехов на общем рынке, компания занимает 6-ю позицию в рейтинге, однако ее продажи стремительно растут: в первом квартале ею продано 8,8 млн. трубок против 5,4 млн. телефонов в аналогичном периоде прошлого года. Это даже больше 8 млн., проданных в четвертом квартале, который традиционно считается лучшим в году для производителей телефонов.

    С финансовой точки зрения, в компании все также становится благополучным: прибыль Sony Ericsson (которая была убыточной с момента образования совместного предприятия Sony и Ericsson в октябре 2001 года) растет три квартала подряд. По итогам первого квартала 2004 г. чистая прибыль компании составила 82 млн. евро против чистого убытка в 104 млн. евро в аналогичном квартале прошлого года. Продажи выросли на 66% до 1,33 млрд. евро с 806 млн. евро в прошлом году. Успех компания связывает с благоприятными рыночными условиями и позитивным влиянием реструктуризации, проведенной в прошлом году. Sony Ericsson с оптимизмом смотрит в будущее – компания повысила прогноз по продажам мобильных телефонов с 520 млн. до 550 млн. по итогам этого года.

    Положение дел в Sony Ericsson кажется еще более радужным на фоне трудностей, которые переживает Nokia, квартальный отчет которой, выпущенный в конце прошлой недели, откровенно разочаровал инвесторов. Прибыль до налогообложения сократилась в первом квартале до 1,21 млрд. евро против 1,446 млрд. евро год назад. Объем продаж Nokia в первом квартале понизился с 6,773 млрд. год назад до 6,625 млрд. евро. Компания сообщила, что прибыль и продажи во втором квартале также снизятся на фоне ужесточения конкуренции на рыке мобильных телефонов.

    Другой удар по позициям Nokia нанес корейский конкурент - Samsung Electronics, объявивший об увеличении своей прибыли в три раза - до 2,3 млрд. евро. Рост связан с активизацией спроса, который стал неожиданностью для самой компании. Увеличились продажи микрочипов, жидкокристаллических панелей и сотовых телефонов, особенно со встроенной фотокамерой. В первом квартале Samsung продал 20 млн. трубок, тогда как прогноз на весь год - 65 млн. Эксперты полагают, что цифры придется пересматривать в лучшую сторону. Прогноз прибыли на второй квартал корпорация улучшила, и аналитики не исключают, по итогам всего года прибыль Samsung может удвоиться.

    обсудить ::

    оглавление ::


    Россияне требуют "выделенку" по цене dial-up

     
    Наиболее популярным способом подключения к интернету в России по-прежнему остается коммутируемый доступ (dial-up). Россияне хотят иметь «быстрый» выход в интернет из дома, но готовы тратить за него ненамного больше, чем за dial-up. За возможность пользоваться «выделенкой» средний российский интернетчик готов выложить $15 в месяц. К такому выводу пришла аналитическая компания J’son & Partners (J&P) в результате исследования, проведенного совместно с VoxRu.Net. [Вернуться в оглавление]

    В отчете J’son & Partners говорится, что 9% опрошенных пользователей, имеющих «домашний» интернет, не смогли ответить на вопрос о способе подключения к Сети. Через dial-up в интернет выходят две трети опрошенных домашних пользователей (68%), при этом для 60% он является единственной возможностью пользоваться интернетом дома. Большинство респондентов (85%) готовы перейти на «быстрый» интернет, однако при этом среднестатический пользователь готов заплатить $40 за подключение к сети выделенного доступа и $15 в месяц - за услуги этой сети.

    Наиболее заметными конкурентами коммутируемого доступа являются домовые сети и GPRS. Абонентами домовых сетей являются 18%, а через GPRS в Сеть выходят 12% опрошенных, имеющих домашний доступ в интернет.

    ADSL-подключение, популярное в Европе, США и Юго-Восточной Азии, не пользуется спросом в России. Это связано с тем, что большинство россиян просто не слышало о данной технологии. О существовании ADSL-провайдеров знает лишь 40% респондентов и не знает – 35%. В то же время о домовых сетях слышали 49% опрошенных и не слышали – 23%.

    По данным J’son & Partners, 55% россиян, имеющих доступ в интернет из дома, пользуются им ежедневно, а 20% - только 1-2 раза в неделю и реже. Среднестатистический интернетчик, по собственным данным, скачивает в месяц около 100 МБ трафика.

    обсудить ::

    оглавление ::


    НР выпускает свой первый смартфон

     
    Уже не один раз в Сети появлялась противоречивая информация о новом карманном ПК от Hewlett Packard сразу с тремя встроенными модулями беспроводной связи (речь идет о BlueTooth, WiFi и GSM/GPRS-приемниках), но сейчас стали известны более-менее точные данные о новинке, которая, судя по всему, появится на прилавках уже этим летом. [Вернуться в оглавление]

    Новый «умный телефон» будет выпускаться в двух вариантах. Первый, с индексом 6315, будет иметь большее количество аксессуаров и встроенную веб-камеру (информация о качестве снимков и, соответственно, размерах матрицы пока отсутствует). Вторая модификация, с индексом 6300, будет логическим продолжением линейки iPaq 5450/5550, а от «старшего брата» 6315 будет отличаться отсутствием камеры и, вероятно, уменьшенным объемом оперативной памяти. Оба телефона будут иметь встроенные GSM/GPRS, WiFi и BlueTooth-модули. Подобное количество беспроводных интерфейсов встроенных в одно устройство впервые будет реализовано именно в 63хх.

    Обрадовала примерная розничная цена новинки: в Европе она будет стоить меньше $600 (хотя в России, к сожалению, ее стоимость, почти наверняка, будет выше). Единственное, что немного разочаровывает, - это габариты iPaq. Точных цифр пока привести не можем, но одно то, что здесь установлен экран диагональю 3,5 дюйма, свидетельствует о не самых «карманных» размерах. С другой стороны, это дает свои плюсы - имеет смысл ожидать от устройства относительно большого времени автономной работы. Например, для понижения энергопотребления тут установлен не привычный многим Xscale-процессор, а TI Omap 1510 processor (тактовая частота его примерно 200 MHz). Заботой о времени автономной работы можно объяснить и съемный li-pol-аккумулятор.

    Из слотов расширения можно рассчитывать только на SecureDigital с поддержкой Input/Output. К сожалению, не удалось узнать, будут ли поддерживаться жакеты от предыдущих серий iPaq (3800/3900/5400/5500).

    Операционная система, естественно, Windows Mobile 2003 Phone Edition. Не идет речи и о поддержке VGA-разрешения. Размеры матрицы КПК будет стандартными – 240х320 точек. Комплект поставки будет включать запасной сменный аккумулятор (какая-либо информация о его емкости пока недоступна), крэдл для синхронизации с настольным ПК, отдельный (!) блок питания для зарядки аккумуляторов, миниатюрную Qwerty-клавиатуру (вместе с ней КПК начинает сильно напоминать HP iPaq 4130), специальную пешеходную гарнитуру, чехол, клипсу для крепления КПК на пояс, комплект программного обеспечения на CD и запасные стилусы.

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

    обсудить ::

    оглавление ::


    IBM предлагает пользователям NT перейти на Linux

     
    На форуме IBM eServer & TotalStorage, который пройдет 21 апреля в Экспоцентре на Красной Пресне, компания IBM предложит всем пользователям NT использовать Linux в качестве альтернативной платформы для серверных приложений. [Вернуться в оглавление]

    По словам Дениса Сосновцева, руководителя Центра компетенций Linux, "опыт IBM внедрения Linux в самых разных организациях по всему миру доказывает готовность Linux обеспечить как коммерческие, так и государственные структуры надежной, безопасной, эффективной ИТ-инфраструктурой".

    Участники форума IBM смогут ознакомиться с широкой линейкой серверов IBM eServer, поддерживающих приложения Linux. Гвоздем программы будет представление нового мэйнфрейма IBM eServer zSeries z890, усовершенствованного для работы с Linux и Java. В год 40-летия мэйнфреймов IBM еще раз доказывает свою приверженность этой платформе и открытым стандартам.

    Зарегистрироваться для участия в Форуме IBM можно по адресу: http://www.ibm.ru/events/forum.

    обсудить ::

    оглавление ::


    Microsoft потеряет патент на FAT?

     
    Влиятельная американская правовая организация Общественный фонд по патентам (Public Patent Foundation) пытается добиться отзыва патента 1996 года, выданного компании Microsoft на её технологию таблицы размещения файлов (FAT). По заявлению представителей организации, ею было обнаружено достаточное количество более ранних патентов для того, чтобы аннулировать этот патент и «в дальнейшем больше никогда его не выдать». [Вернуться в оглавление]

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

    По мнению Общественного фонда, заявляя права на гонорары за использование базисных технологий, Microsoft использует свою интеллектуальную собственность как способ сдерживания развития программных продуктов с открытым кодом. По словам Дэна Ревичера (Dan Ravicher), исполнительного директора и основателя Общественного фонда по патентам, «мы склонны верить, что Microsoft не использует стратегию препятствования конкуренции, используя неоднозначные патенты. К сожалению, монополистическая практика компании в прошлом вкупе с последний кампанией патентных претензий заставляют нас проявить серьёзную озабоченность по поводу намерений корпорации».

    Как сообщает издание PC Pro, несмотря на существование большого количества разработок в области технологии FAT и до 1996 года, её использование компанией Microsoft берёт начало с самых первых дней системы MS-DOS, которая основана на операционной системе CP/M, а спорный патёнт фактически ссылается на расширение Microsoft файловых имен типа «8.3». Это позволило ОС Windows 95 использовать длинные имена файлов, при этом оставаясь совместимой с более ранними приложениями.

    обсудить ::

    оглавление ::


    Федеральные чиновники покрывают пиратов?

     
    На днях CNews.ru сообщал о новых мерах московского правительства, направленных на усиление борьбы с пиратами. Однако не успели инициативы столичных властей вступить в силу, как их сразу же признала незаконными антимонопольная служба. [Вернуться в оглавление]

    О контрафакте и мерах по борьбе с ним сегодня не говорит только ленивый. На днях своим видением этой проблемы поделился даже президент РФ. Он уверен, что пока правительство не обеспечит снижение цен на легальную продукцию и доступ к ней, пока не будет создана соответствующая правовая база, все усилия по борьбе с контрафактной продукцией останутся малоэффективными. Усилий действительно много, однако результат их пока невелик. Различные госсруктуры, ответственные за принятие решений, или «мешают жить» легальным производителям, или оспаривают возможность применения тех или иных способов решения «пиратской» проблемы.

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

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

    «Мне пока неизвестна мотивировочная часть постановления ФАС, - прокомментировал CNews.ru ситуацию директор Некоммерческого Партнерства Поставщиков Программных Продуктов (НП ППП) Дмитрий Соколов. - Представляется, что здесь справедлив традиционный аргумент - противоречие регионального и федерального законодательства». По его словам, федеральное законодательство не предусматривает какой-либо обязательной маркировки, и подобные меры фактически накладывают на предпринимателей дополнительные обязанности, ограничивают свободу перемещения и распространения определенных видов товаров. При этом г-н Соколов отмечает, что НП ППП не против маркировки. Однако рынку компьютерных программ эта мера приносит скорее вред, чем пользу. Часто поверхностная "помощь" властей на практике оборачивается и против правообладателя, и против потребителя. По его мнению, тема обязательного оклеивания идентифицирующими марками программной продукции - именно из этой области. Тем не менее, г-н Соколов считает, что внимание со стороны федерального и московского правительства к проблеме защиты интеллектуальной собственности в сфере компьютерных программ - факт отрадный, и он лишний раз доказывает экономическую и социальную значимость проблемы. «Важно только, чтобы при этом не была создана почва для перегибов и непродуманных шагов», - отмечает он.

    Пример такого рода перегибов в беседе с CNews.ru привел Игорь Кузнецов, отвечающий в фирме "1С" за работу с московскими розничными сетями. По его словам, когда прошлым летом российское правительство приняло постановление, согласно которому аудио- и видеопродукцию больше нельзя было реализовывать в формате развозной торговли, правительство Москвы «пошло дальше», и включило в перечень также "компьютерно-информационные носители". Причем их реализация была запрещена не только в нестационарных точках, но и в киосках московского метрополитена. Результат нововведения не заставил себя долго ждать, однако ударил он не по пиратам, а по поставщикам лицензионной продукции. В начале октября 2003 года в метрополитене было запрещено торговать аудио- видео- и компьютерными носителями. «Сохраняя торговые точки сети «Чистый софт», мы оплачивали аренду, но продажей программных продуктов не занимались, - рассказывает г-н Кузнецов. - Соответственно – «1С» понесла прямые убытки, так же как и другие законопослушные арендаторы, поступавшие подобным образом». По его мнению, сами пираты изменений не почувствовали, поскольку их продукция распространяется не через стационарные киоски (работу которых легче контролировать проверяющим органам), а через передвижные лотки. «Только благодаря усилиям общественных организаций спустя четыре месяца удалось добиться отмены несправедливого постановления, - сетует г-н Кузнецов. - Разрешение на торговлю компьютерными дисками выдали лишь в феврале, и в настоящее время торговля в метрополитене открыта».

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

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

    обсудить ::

    оглавление ::


    "Бухгалтерская болезнь" в США докатилась до ИТ

     
    Мода на вольное обращение с бухгалтерскими документами в Америке проникла и в сферу высоких технологий. Растущий скандал вокруг манипуляций американской компании Computer Associates с бухгалтерской отчетностью привел к увольнению еще девяти ее сотрудников, а председатель совета директоров и исполнительный директор компании Санджей Кумар (Sanjay Kumar) был вынужден оставить свои посты. [Вернуться в оглавление]

    По данным газеты Financial Times, уход сотрудников финансового и юридического отделов стал вызвал волну разговоров о том, окажется или нет замешанным в скандале глава компании - Санджей Кумар. Когда в конце 90-х нью-йоркскую компанию обвинили в мошеннических манипуляциях с данными бухгалтерской отчетностью для завышения показателей, г-н Кумар был в ней вторым лицом. В тот период Кумар наряду с Чарльзом Вангом (Charles Wang) и еще одним сотрудником СА получили премиальные в размере $1 млрд.

    Состоявшиеся на этой неделе увольнения последовали за прошлогодним сокращением трех ответственных работников финансового отдела компании, включая главного финансиста компании Айры Зара (Ira Zar). Тогда все трое признали себя виновными в сокрытии расходов. Признание стало частью соглашения, достигнутого обвиняемыми с правосудием. При этом г-н Зар отдавал себе отчет в том, что тем самым в скандал вовлекаются и другие члены высшего руководства компании, включая, возможно, и Санджея Кумара.

    На позапрошлой неделе новым руководителем финансового отдела Computer Associates был назначен Джефф Кларк (Jeff Clarke), бывший высокопоставленный сотрудник Hewlett-Packard и хороший знакомый Кумара.

    Тем временем, как пишет Financial Times, Computer Associates проводит собственное расследование случившегося, и, по словам официальных представителей компании, оно близко к завершению. Руководит им Вальтер Шутце (Walter Schutze), бывший главный бухгалтер Комиссии по ценным бумагам и биржам США. Для него работать с CA не внове - в 2000 году ему уже приходилось разбирать, каким образом компания рассчитывала свой доход. Несмотря на то, что тогда заявленная величина доходов была признана верной, обнаружилось, что засчитывались они за квартал до фактического получения, что позволило компании неожиданно для Уолл-Стрита показать неплохие результаты.

    В понедельник, сразу же после объявления о новых отставках, на торгах в Нью-Йорке цена акции Computer Associates упала на 24 цента, до уровня $26.09. Уже в среду Кумару под растущим валом критики пришлось распроститься с должностью председателя совета диркторов СА и ее исполнительного директора. Правда, увольняться ему не пришлось. Санджей Кумар стал "главным софтверным архитектором" компании - должность, в чем-то аналогичная текущему титулу Билла Гейтса в Microsoft.

    обсудить ::

    оглавление ::


    Сотовые операторы Европы объединились

     
    Ряд ведущих мировых операторов мобильной связи, включая Vodafone и Orange, ведут переговоры о создании нового индустриального альянса, целью которого должно стать усиление позиций компаний на мировом ИТ-рынке. Помимо прочего, операторы намерены создать собственную операционную систему для мобильных телефонов в противовес Symbian и Windows Mobile.[Вернуться в оглавление]

    Членами нового альянса стали шесть крупнейших европейских операторов: французский Orange, британские Vodafone и mmO2, испанский Telefonica Moviles, немецкий T-Mobile и итальянский TIM. Стоит отметить, что операции этих компаний простираются далеко за пределы Европы и охватывают как США и Латинскую Америку, так и Японию.

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

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

    Примечательно, что вошедшие в состав альянса Orange, Telefоnica Moviles, TIM и T-Mobile, являются членами консорциума Freemove, образованного в 2003 году для успешной конкуренции с Vodafone. А mmO2, в свою очередь, также входит в аналогичную организацию Starmap Mobile Alliance, преследующую те же цели. Если последние две формации нацелены на рынок потребительских услуг (подобные альянсы предполагают единые роуминговые тарифы и сервисные службы в разных странах), то только что образованный альянс ориентирован на укрепление положения операторов в корпоративной среде - вместе они смогут диктовать свои условия производителям ПО и аппаратных средств.

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

    обсудить ::

    оглавление ::

    Новости высоких технологий
    Mail.ru увеличил почтовые ящики до бесконечности

    [Вернуться в оглавление]

    21 апреля почтовая служба Mail.ru объявила об увеличении объемов бесплатных почтовых ящиков, предоставляемых пользователям сервиса. Теперь он не ограничен, каждый пользователь имеет возможность самостоятельно увеличить размер своего почтового ящика до необходимого ему размера. Эта функция доступна в разделе "Настройки" внутреннего интерфейса почтовой службы Mail.ru.

    С 14 апреля функция расширения почтового ящика была доступна в тестовом режиме ограниченному количеству пользователей почтового сервиса Mail.ru. За неделю тестового периода предложенной возможностью воспользовались 11,3% пользователей из тех, кому она была доступна.

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

    Ежемесячно почтовой службой Mail.ru пользуются около 9 млн. человек.

    обсудить ::

    оглавление ::


    Российские абоненты довольны своими операторами

    [Вернуться в оглавление]

    Мобильным телефоном пользуется каждый четвертый россиянин. В городах-миллионерах уровень распространения мобильной связи составляет 42%. Такие данные были получены в ходе социологического опроса, проведенного центром изучения общественного мнения ROMIR Monitoring, сообщает РБК. Большинство пользователей мобильной связи (79%) заявляют об удовлетворенности качеством услуг, предоставляемых своим оператором мобильной связи. Тем не менее, почти каждый десятый пользователь мобильной связью (11%) не удовлетворен сервисом операторов.

    43% владельцев мобильных телефонов приобрели их самостоятельно в фирменных салонах связи. Каждому пятому (19%) - подарили родственники или друзья, 18% - совершили покупку мобильного телефона в крупном магазине бытовой и аудио-видеотехники. Каждая десятая "трубка" россиян куплена с рук. Еще 4% опрошенных владельцев "мобильников" приобрели аппарат на рынке, а 3% - сказали, что им выдали сотовый телефон на работе.

    Более четверти российских пользователей мобильной связи приобщились к ней в течение последних шести месяцев.

    Исследование было проведено в марте 2004 г. в 120 населенных пунктах России по выборке, репрезентирующей взрослое население страны. Было опрошено 1600 респондентов в возрасте от 18 лет и старше.

    обсудить ::

    оглавление ::


    "Мотив" - электронный документооборот от белгородских разработчиков

    [Вернуться в оглавление]

    В рамках проводимой Российским представительством Greenpeace кампании по сохранению лесных ресурсов, компания "Институт Высоких Технологий" при Белгородском госуниверситете предложила систему электронного документооборота “Мотив”. В рамках реформы систем управления “Мотив” уже сейчас внедрен на некоторых предприятиях чернозёмной полосы, являвшихся до этого крупными потребителями бумажной канцелярской продукции. Например, в ОАО "Белгородэнерго".

    АС “Мотив” относится к веб-приложениям автоматизации контроля исполнения заданий, поручений, проектов. Такого рода приложения призваны контролировать задачи внутрикорпоративного планирования деятельности, обновлять данные о персонале, объявлять вакансии и т.п. “Мотив” содержит средства коллективной работы, позволяющие автоматизировать постановку поручений и задач, контроль их исполнения, деловые операции (например, постановку заданий, фиксирование действий и т.п.). Руководителям среднего и верхнего звена, так же как и кадровым работникам, более не придется пересылать свои формуляры по всей компании. Автоматизированная система контроля исполнения поручений “Мотив” организует структуру кадровой подчинённости и ведёт документирование деятельности современного предприятия. Постановка задач персоналу и контроль их исполнения становится более оперативным. Статистические данные на основе накоплений основных рабочих показателей в подобных автоматизированных системах помогают руководящему составу в организации более точного бизнес-плана компании, с предметным финансированием ведущих направлений деятельности.

    обсудить ::

    оглавление ::


    На КПК можно запустить Windows XP

    [Вернуться в оглавление]

    Глава компании OQO Джори Белл (Jory Bell) на протяжение уже 4-х лет руководит проектом по созданию КПК, который бы работал под управлением ОС Windows XP. Штат компании насчитывает 30 человек, результатом их деятельности стало создание нескольких прототипов нового устройства, которое уже получило название «ультраперсональный компьютер». По мнению Белла, пользователи хотят от КПК не только мобильности, но и высокой степени совместимости с различным оборудованием и ПО, которыми обладает Windows XP, сообщает Yahoo!.

    Однако Windows XP изначально не была предназначена для использования с компьютером меньше, чем ноутбук. Это означает, что OQO предстоит значительная инженерная работа, чтобы создать КПК нового типа. В команду OQO входят инженеры, которые разрабатывали популярные ноутбуки Titanium компании Apple Computer, в числе инвесторов проекта – бывшие управляющие Microsoft и Transmeta, а также крупные инвестиционные компании - Azure Capital, Wasserstein Ventures и AsiaTech. То, что OQO удалось привлечь для разработки проекта сумму более $17 млн. говорит не только о серьезности ее намерений, но и уверенности инвесторов в перспективности нового типа мобильных компьютеров.

    Свой первый КПК OQO выпустила в 2002 г. Теперешний прототип оснащен экраном с более высоким разрешением, а также встроенным микроконтроллером (собственная разработка компании), который позволил значительно сократить число микросхем, используемых в ноутбуках. Образец оснащен 1-гигагерцовым процессором Transmeta Crusoe и 20-гигабайтным 1.8-дюймовым винчестером Toshiba, графическим процессором 8 МБ, WiFi-адаптером и клавиатурой, оперативная память суперКПК – 256 МБ.

    Ожидаемая цена «ультра-персонального компьютера» составляет $2000. В ближайшее время компания планирует начать поставки КПК на заказ, а также прямые поставки мелкими партиями, сообщил сайт Siliconvalley.com.

    обсудить ::

    оглавление ::


    Microsoft взял на работу своего давнего противника

    [Вернуться в оглавление]

    Как сообщает сайт Silicon.com, Microsoft принял на работу Карла Айгнера (Karl Aigner), ранее занимавшего пост сотрудника по связи с клиентами компании SuSE. Именно он убедил городское руководство Мюнхена перейти на ОС Linux. В Microsoft Айгнер теперь руководит продажами программного обеспечения для центров обработки данных, ориентированных на сегмент среднего бизнеса. К своим обязанностям он приступил 1-го апреля.

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

    Компания SuSE, которую Айгнер покинул в конце 2003 г., была куплена корпорацией Novell за $210 млн. Переманивание «чужих» специалистов – обычная практика в бизнесе высоких технологий. Несмотря на возможное судебное преследование ведущие компании используют подобные приемы, ввиду высокой степени их «отдачи». Напомним, что, например, в 1997 г. компания Borland судилась с Microsoft, после того как корпорация переманила к себе десятки специалистов Borland.

    обсудить ::

    оглавление ::


    David запускает Windows-приложения на Linux

    [Вернуться в оглавление]

    Филиппинская компания SpecOps Labs утверждает, что разработала программное обеспечение, которое позволяет запускать Windows-приложения на ОС Linux. По заявлению компании, система под кодовым названием David появится к концу этого года. Информация на сайте SpecOps не касается подробностей, но сообщает, что David 1.0 будет связующим ПО, с помощью которого можно будет запускать большую часть Windows-приложений в Linux-среде. По словам компании, «работая в фоновом режиме, David позволит пользователям запускать их любимые программы, которые будут выглядеть и работать так же, как они к этому привыкли».

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

    обсудить ::

    оглавление ::


    НАСА запустило спутник для проверки теории относительности

    [Вернуться в оглавление]

    Национальное агентство по аэронавтике и исследованию космического пространства США (НАСА) запустило на орбиту спутник стоимостью $700 млн., который должен будет подтвердить или опровергнуть теорию относительности Альберта Эйнштейна, сообщает Reuters. Спутник под названием Gravity Probe B был выведен на орбиту ракетой Delta 2 компании Boeing 20 апреля в 18:57 по московскому времени с военно-воздушной базы Ванденберг в Калифорнии. Первоначально запуск был запланирован на понедельник, 19 апреля, но НАСА решило его отложить в связи с проблемами в программном обеспечении.

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

    обсудить ::

    оглавление ::


    DVD-рекордеры - лидеры цифрового рынка

    [Вернуться в оглавление]

    DVD-рекордеры начинают занимать главенствующую роль среди трех видов цифровых продуктов: телевизоров с плоским экраном, DVD-проигрывателей и цифровых камер. Во многом это связано с их функциональными особенностями, позволяющими использовать их вместе с такими устройствами, как, например, те же цифровые камеры. Необычный случай произошел на выставке продуктов Panasonic компании Matsushita Electric Industrial, в которой участвовало 24 местных дилера компании. Большую часть населения города Асахикава, в котором проводилась выставка, составляют пожилые люди, поэтому цифровые камеры не пользовались здесь спросом из-за сложностей переноса затем изображений на ПК для людей такого возраста. Однако все 34 представленные на выставке камеры ушли буквально «с молотка». Все дело в том, что покупатели оценили удобство и легкость записи полученных фото на Panasonic Diga DVD-магнитофон.

    Согласно данным Japan Electronics and Information Technology Industries Association, мировой спрос на DVD- рекордеры вырастет в 2004 году на 150%, а объем продаж составит 9 млн. единиц. В следующем году такой рост несколько ослабнет, однако не остановится и составит 75% и 15,8 млн. проданных записывающих DVD-устройств. Mitsubishi Electric начала полномасштабное производство DVD- рекордеров, поскольку именно это, по мнению руководства компании, необходимое условие для того, чтобы остаться в бизнесе бытовой электроники. Рост популярности этих устройств отразился и на других компаниях, производящих цифровые продукты. Так, Fuji Electric Device Technology увеличила выпуск жестких дисков для этих устройств на одной из своих фабрик на 30%. Sony представила цифровую камеру, использующую в качестве носителя DVD, поскольку все больше пользователей прибегают к редактированию полученных фото с помощью DVD-устройств. Выход Sony, вероятно поспособствует росту популярности цифровых DVD-камер, так как компания занимает 40% мирового рынка цифровых видеокамер, сообщил сайт NE Asia Online.

    обсудить ::

    оглавление ::


    VeriSign поплатился за Sex.com

    [Вернуться в оглавление]

    Владелец сайта Sex.com и регистратор VeriSign урегулировали тяжбу по поводу неправомерной передачи домена 8 лет назад. Условия соглашения не разглашаются. Урегулирование было достигнуто за неделю до передачи дела в федеральный суд Сан-Хосе, Калифорния.

    В 1995 году компания Network Solutions, занимавшаяся регистрацией доменых имен и в данный момент принадлежащая VeriSign, произвела перерегистрацию домена Sex.com, до этого принадлежавшего Гэри Кремену (Gary Kremen), на имя Стивена Коэна (Stephen Cohen). Коэн заработал на использовании домена миллионы долларов, после чего суд заставил его вернуть чужую собственность и возместить $65 млн. ущерба. Но он скрылся, после чего Кремен начал тяжбу с VeriSign. После многолетних раззбирательств суд признал, что, хотя VeriSign и не совершал кражи домена, компания должна нести ответственность за то, что она передала его другому лицу, не уведомив об этом его прежнего владельца.

    По мнению экспертов, суд мог принудить VeriSign компенсировать издержки Кремена в сумме, превышающей $40 млн. Г-н Кремен потратил на судебные издерки около $1 млн. и считает сумму компенсации, договор о которой был достигнут, "справедливой", сообщает Telecom.paper.

    Регистрация доменов в зонах BIZ, RU, COM, NET, ORG, INFO
    Проверка занятости имени домена:
      доменное имя зона
    www.
    Установить

    Подписка на новости о доменах

    обсудить ::

    оглавление ::


    ООО "Кит" выплатит Microsoft 750 тыс.рублей

    [Вернуться в оглавление]

    Как сообщила компания Microsoft, 3 марта 2004 года Арбитражный суд Санкт-Петербурга вынес решение по иску Microsoft к ООО «Кит». Суд установил факты нарушения авторских прав Microsoft и обязал ответчика выплатить в качестве компенсации в ее пользу 750 тысяч рублей, а также покрыть судебные издержки. «Претензии корпорации Microsoft к ООО «Кит» были основаны на материалах проверок деятельности этой компании, проведенных сотрудниками петербургской милиции, - сообщил юридический консультант корпорации Microsoft в РФ, сотрудник юридической фирмы Latham and Watkins Игорь Сосновский. - Рассматривая дело, суд принял во внимание то обстоятельство, что распространение нелицензионного программного обеспечения путем его установки на жесткие диски продаваемой компьютерной техники носило в ООО «Кит» систематический характер».

    Первая проверка правомерности распространения ПО в компьютерном салоне ООО «Кит» была проведена 30 октября 2001 года. При проверочной закупке компьютеров было выявлено, что на них установлены нелегальные копии программных продуктов. По данному факту было возбуждено дело об административном правонарушении в отношении директора компании В. Тимофеева, рассмотрев которое 12 ноября 2001 года Калининский федеральный суд Санкт-Петербурга признал его виновным в нарушении авторских прав Microsoft и постановил подвергнуть штрафу в доход государства.

    В дальнейшем петербургская милиция повторно проверила ООО «Кит», и вновь проверочная закупка выявила факт распространения нелицензионного ПО Microsoft. Также сотрудниками милиции были обнаружены поддельные диски с копиями различных программ, авторские права на которые принадлежат Microsoft. По данным фактам также было возбуждено дело об административном правонарушении, однако на этот раз только им дело не ограничилось: представители Microsoft предъявили нарушителям иск с требованием прекратить неправомерное распространение программного обеспечения, авторские права на которое принадлежат корпорации Microsoft, а также выплатить компенсацию за нарушение авторских прав. Арбитражный суд удовлетворил требования истца.

    обсудить ::

    оглавление ::


    Вышел новый дистрибутив Linux

    [Вернуться в оглавление]

    Компания Linux Business Alliance выпустила новый дистрибутив GNU/Linux под названием LBA Linux. LBA Linux R1 – это технологически усовершенствованная, гибкая и простая операционная система. Создатели ОС утверждают, что она обладает удобством и безопасностью. Новая система также включает полезную функцию «наблюдатель», которая периодически сообщает пользователю о наличии обновлений для ПО LBA-Linux.

    Основной дистрибутив LBA-Linux R1 Foundation CD, устанавливающий систему LBA-Linux, можно скачать с ftp.sot.com. Дополнительно программное обеспечение доступно с того же сайта. Процедура установки системы очень проста, её смогут произвести даже новички в несколько кликов мышью. Для тех, кто больше знаком со средой GNU/Linux также доступны опции ручной установки системы.

    обсудить ::

    оглавление ::


    Microsoft критикуют за патчи

    [Вернуться в оглавление]

    Компания Microsoft столкнулась с серьёзной критикой в свой адрес, касающейся размера и недостаточного тестирования ежемесячного обновления безопасности, выпущенного на прошлой неделе и содержащего 14 исправлений. По словам Расса Купера (Russ Cooper), ведущего специалиста компании TruSecure, «обновляя 14 различных компонентов Windows одновременно, администраторам приходится обновлять все компоненты системы». Это увеличивает срок тестирования, которое пользователям обязательно придётся проводить. Он предположил также, что недостаточно тщательное бета-тестироване ставит под вопрос качество Windows XP Service Pack 2, который должен появиться до конца июня.

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

    По информации Microsoft, 80% кода SP2 относится к безопасности, а оставшиеся 20% дополнят функциональность такими возможностями, как улучшенная поддержка Bluetooth-устройств, и новая версия операционной системы для Tablet PC. Количество планируемых изменений по части безопасности в SP2 таково, что Microsoft выпустит 156-страничный документ Word, описывающий все изменения и то, как они могут повлиять на работу системы.

    Microsoft уже выпустил первую версию релиза SP2, а в середине мая должен представить вторую. Такое сосредоточение усилий на производстве SP2 задерживает выпуск ОС Longhorn, следующей версии Windows. Появление первой беты, ожидавшееся в течение 2004 года, теперь не произойдёт раньше первой половины 2005 года.

    обсудить ::

    оглавление ::


    BenQ разработал стильный монитор

    [Вернуться в оглавление]

     

    Компания BenQ объявила о выходе на российский рынок нового ЖК-монитора FP783. Это вторая модель в продуктовой линейке ЖК-мониторов BenQ с полным временем отклика 12 мс. Кроме того, монитор имеет высокие уровни яркости (300 кд/м²) и контрастности (500:1).

    Монитор имеет также DVI вход, что позволяет добиться высокого качества изображения. В комплект дополнительной поставки с ЖК-монитором FP783 входят вэб-камера и блок колонок, выполненные в едином дизайне.

    Колонки для FP783 создавались на основе SRS-технологии, которая используется в производстве как ЭЛТ-, так и ЖК-телевизоров. SRS-технология позволяет добиться эффекта объемного звучания. При этом всеми преимуществами звучания можно наслаждаться и при использовании наушников. USB-веб-камера имеет разрешение 300 тысяч пикселей, широкоугольный объектив 55° и фокусное расстояние от 2 см.

    обсудить ::

    оглавление ::


    Sony представила ЖК-мониторы бизнес-класса

    [Вернуться в оглавление]

    Компания Sony CDE представила 2 ЖК-монитора, предназначенных, главным образом, для делового сектора. Оба монитора, 17-дюймовый SDM-S74 и 19-дюймовый SDM-S94, поддерживают разрешение SXGA (1280x1024 пикселей), обеспечивая просторное рабочее поле для выполнения любых задач. Картину дополняют высокие значения яркости и контрастности, которые вместе с превосходным антибликовым покрытием экрана гарантируют высокое качество изображения при самых различных условиях освещения. Уникальная функция Sony ECO-Mode позволяет за считанные секунды выбрать уровень яркости, соответствующий любому приложению или внешним условиям освещения. Пользователь также имеет возможность соответственно своим предпочтениям быстро и точно настроить цветовой профиль дисплея.


    SDM-S74 обеспечивает широкий угол обзора в 160° по горизонтали и вертикали, а на SDM-S94 можно смотреть под углом до 170° в обеих плоскостях. Обе модели отличаются великолепной динамикой, но 17” SDM-S74, время отклика которого составляет всего 16 мс, лучше подходит для видеоприложений.

    Для этих моделей предусмотрена трехлетняя европейская гарантия.

    обсудить ::

    оглавление ::


    МТС стали прямым владельцем "Кубань GSM"

    [Вернуться в оглавление]

    ОАО «Мобильные ТелеСистемы» сообщило об увеличении доли своего прямого владения в уставном капитале ЗАО «Кубань GSM» до 100%. До последнего времени МТС напрямую владели 52,67% акций «Кубань GSM», а еще 47,33% акций принадлежали МТС через 100%-ную дочернюю компанию «Кубтелесот». МТС стали владельцем 100% акций ООО «Кубтелесот» в сентябре 2003 года, сумма сделки составила $107 млн.

    В процессе ликвидации ООО «Кубтелесот» как юридического лица, осуществляемой в настоящее время, принадлежавшие ему акции «Кубань GSM» были переданы МТС. Благодаря данной операции МТС стали прямым владельцем 100% акций «Кубань GSM».

    обсудить ::

    оглавление ::

    Ваши комментарии и предложения
     №12   Апрель 26, 2004
    Подписаться  

    :: CNews.ru ::

    Тел. (095) 363–11–57, факс 363–11–53, Электронный адрес

    :: РБК ::


    http://subscribe.ru/
    E-mail: ask@subscribe.ru
    Отписаться

    В избранное