intro2010 (1130585), страница 4

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

Текст из файла (страница 4)

Серьезную проблему представляет использование Интернета в экстремистских целях. Достаточно вспомнить, что Интернет являлся одним из средств координации действий экстремистов при подготовке и проведении атаки в США 11 сентября 2001 года.

1.4.Сетевая этика

В силу сказанного общение и использование Сети требует чувства профессиональной ответственности или, хотя бы минимального знания Netiquette [37]. Что такое Netiquette? Это сетевой этикет или этикет в Интернете. Этикет – это правила хорошего тона, принятые в той или иной социальной группе. Другими словами, Netiquette – это набор предписаний о том, как себя вести в Сети. Когда Вы осваиваете новую культуру – а Интернет, конечно, имеет собственную культуру – то можете совершать ошибки. Можно обидеть человека без причины. Или, не поняв, о чем идет речь, выступать со своей резкой позицией. И, что немаловажно, в виртуальном пространстве легче забыть о том, что вы общаетесь с живыми людьми (а не просто настукиваете на клавиатуре некий текст).

1.5.Инженерия программного обеспечения

Теперь настало время рассмотреть третью движущую силу Информационных технологий – инженерию программного обеспечения.

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

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

Только к концу 60-х стало складываться представление о новой специальности. В это время А.А. Ляпунов открывает свой, ставший в последствии знаменитым, семинар по программированию. В 1970 году академиком А.Н. Тихоновым был основан факультет Вычислительной математики и кибернетики в Московском университете, где появились профильные кафедры.

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

Отправной точкой в истории инженерии программного обеспечения считается конференция, которая состоялась в 1968 году в Германии – Партенкирхене по инициативе комитета по науке НАТО [51]. Поводом для нее стало осознание кризисной ситуации в области разработки программного обеспечения, суть которой в том, что уже в те годы сложность программ и мощность компьютеров пришли в противоречие с технологическими возможностями программирования.

Закона, постулирующего количественное развитие программного обеспечения, наподобие закона Мура не существует. Но рост производительности труда программистов отмечают многие. Достоверных оценок этого роста автору этой книги не известно. Слишком уж сложен предмет анализа. Программирование в 70-х существенно отличается от программирования в 90-х или 2000-х. В [8] приведены данные, согласно которым рост производительности труда программистов к концу 90-х устойчиво составлял не менее чем 100% за 10 лет (см. таблицу 2). В тоже время там же отмечено, что за последние десятилетия темпы роста производительности труда, достигаемые только в самых автоматизированных секторах обрабатывающей промышленности, составляли около 80% за 10 лет. Средние же темпы роста производительности труда, например, в обрабатывающей промышленности США, не превышали 30% за тот же период. Таким образом, можно сделать вывод с одной стороны о рекордных, невиданно высоких темпах роста производительности труда программистов. С другой стороны, в сравнении с темпами роста, определяемыми законами Мура и Гилдера, приведенные оценки не пропорционально низкие.

Таблица 2 Показатели развития индустрии ЭВМ (за единицу приняты показатели 1955 г.)

Источник: 01 Informatique- Hebdo, 1980, IV, p. 10 (приводится по: США – экономика, политика, идеология, 1983, №8, с.106)

С уверенностью можно сказать одно, что этот рост производительности труда представляет собой плохо управляемый процесс: программирование губит иллюзия простоты и вседозволенности; между разработчиком и конечным продуктом в большинстве проектов отсутствует череда специалистов-технологов и производственников. Сравните, как долго и дорого создавать такие изделия, как самолеты или автомобили, сколько времени уходит на проектирование, создание опытных образцов, испытания, запуск в производ­ство с тем, как соблазнительно быстро пишутся программы. Следствие этой иллюзии — многочисленные аварии, вызванные ошибками. Они особенно эффектно, а порой и трагически проявляют себя во встроенных системах; ошибки в офисных программах менее заметны. Тем, кого интересует хроника «программных техногенных катастроф», можно порекомендовать «Дайджест рисков»[9], где описаны сотни, если не тысячи эпизодов, зафиксированных с 1986 года до наших дней.

На рисунке 1-2 представлена хронология развития методов программирования. Все ни были направлены на повышение производительности труда программистов, повышение скорости разработки и надежности создаваемых программ. Уже в 70-е годы пришло понимание, что программы, как продукт инженерной деятельности, имеют беспрецедентную в истории человеческой цивилизации сложность; и нельзя каждый раз разработку программной системы начинать «с нуля». Поэтому активно стали развиваться методы программирования, основная идея которых состояла в том, чтобы программные системы можно было бы создавать из ранее написанных компонентов, кирпичиков, в которых аккумулировать опыт предшествующих разработок и корректность работы которых не надо было бы каждый раз обосновывать.

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

1.6.Сервис ориентированные архитектуры и web-сервисы

Современным воплощением старозаветной мечты индустрии программирования о замене "кустарного" кодирования программ "от и до" на "промышленную" сборку приложений из "стандартных комплектующих", как в автомобильной, или других "традиционных" отраслях промышленности является се́рвис-ориенти́рованная архитекту́ра (от англ. SOA, service-oriented architecture) — подход к разработке программного обеспечения, основанный на использовании сетевых сервисов (служб) со стандартизированными интерфейсами [36].

В самом общем виде SOA предполагает наличие трех основных участников: поставщика сервиса, потребителя сервиса и реестра сервисов (см. рисунок 1-3 из [47]), там на дугах указаны аббревиатуры стандартов языков и протоколов, используемых при реализации SOA, многие из которых мы рассмотрим в этой книге). Взаимодействие участников выглядит достаточно просто: поставщик сервиса регистрирует свои сервисы в реестре, а потребитель обращается к реестру с запросом.

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

Интерфейс компонентов SОА-программы инкапсулирует, скрывает детали реализации конкретного компонента (ОС, платформы, языка программирования, вендора, и т. п.) от остальных компонентов. Таким образом, SОА предоставляет гибкий и элегантный способ комбинирования и многократного использования компонентов для построения сложных распределённых программных комплексов. Компоненты программы могут быть распределены по разным узлам сети, и предлагаются как независимые, слабо связанные, заменяемые сервисы-приложения. Программные комплексы, разработанные в соответствии с SОА, часто реализуются как набор веб-сервисов, интегрированных при помощи известных стандартных протоколов. Веб-сервис – набор логически связанных функций, которые могут быть программно вызваны удаленно через Интернет. Информация о том, какие функции предоставляет данный веб-сервис, содержится в документе WSDL (Web Services Description Language), а для поиска существующих веб-сервисов предполагается использование специальных реестров, совместимых со спецификацией UDDI (Universal Description, Discovery and Integration).

В условиях динамично изменяющегося окружения современное предприятие должно уметь быстро подстраивать свои производственные процессы и их информационную поддержку в соответствии с этими изменениями. Динамичность ИТ-среды современного предприятия, ее нацеленность на решение бизнес-задач, необходимость быстрых изменений в ответ на изменение этих задач – эти характеристики приобретают ключевое значение при проектировании или реформировании корпоративных ИТ-инфраструктур. В этих условиях отдельные, "точечные" решения по интеграции настолько усложняют и саму инфраструктуру, и процесс управления ею, что становятся абсолютно неприемлемыми. Представим себе, к примеру, что в компании существует несколько приложений, каждое из которых интегрировано со всеми остальными посредством соответствующих интерфейсов. Если таких приложений – n, то всего потребуется n(n-1) интерфейсов. С добавлением всего лишь одного нового приложения появится 2n новых интерфейсов, для которых потребуется соответствующее документирование, тестирование и поддержка. При этом придется вносить модификации в код каждого из существующих приложений для учета новых интерфейсов и проводить соответствующее тестирование. SOA позволяет избежать этого, максимально упростить процесс добавления новых приложений, и минимизирует число интерфейсов взаимодействия.

Другими словами, SOA обеспечивает предприятию высокую скорость адаптации к динамично изменяющимся условиям современного рынка. А, по мнению таких лидеров современного бизнеса как Джек Уелч (Jack Welch General Electric), Билл Гейтс (Bill Gates, Microsoft), Джон Чамберс (John Chambers, Cisco Systems), Лари Элисон (Larry Elison, Oracle) в современных условиях самое главное – именно то, насколько быстро компания может адаптировать свои цели и организацию к новым, динамично изменяющимся условиям.

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

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

В этой экономике ценность вырастает из изобилия и возрастает от распространения, при этом резко возрастает роль стандартов.

У эпидемиологов есть такое понятие – точка перелома. После ее наступления процесс не надо подталкивать, он развивается сам. У биологов есть хороший пример с листьями лилии: лилия удваивает поверхность своих листьев ежедневно. Это значит, что за день до того как лилия закроет поверхность пруда, она закроет только половину поверхности, за два дня до «финиша» – лишь четверть и т.д. Это значит, что заметной нашему глазу она станет, когда займет половину поверхности пруда, а это будет уже через много дней после точки перелома.

Сеть можно сравнить с такой лилией, и точка перелома давно пройдена!

34

Характеристики

Список файлов учебной работы