- •Предисловие
- •Введение
- •1Архитектура эвм
- •1.1 Биты и их хранение
- •1.1.1Вентили и триггеры
- •1.1.2Другие способы хранения битов
- •1.1.3Шестнадцатеричная система счисления
- •1.2 Оперативная память
- •1.2.1Структура памяти
- •1.2.2Измерение емкости памяти
- •1.3 Устройства хранения данных
- •1.3.1Магнитные диски
- •1.3.2Компакт-диски
- •1.3.3Магнитные ленты
- •1.3.4Хранение и поиск файлов
- •1.4 Представление информации в виде двоичного кода
- •1.4.1Представление текста
- •1.4.2Американский национальный институт стандартов
- •1.4.3Iso - международная организация по стандартизации
- •1.4.4Представление числовых значений
- •1.4.5Представление изображений
- •1.4.6Представление звука
- •1.5 Двоичная система счисления
- •1.5.1Альтернатива двоичной системе счисления
- •1.5.2Дроби в двоичной системе счисления
- •1.5.3Аналоговые и цифровые устройства
- •1.6 Хранение целых чисел
- •1.6.1Представление в двоичном дополнительном коде
- •1.6.2Сложение в двоичном дополнительном коде
- •1.6.3Проблема переполнения
- •1.6.4Представление с избытком
- •1.7 Хранение дробей
- •1.7.1Представление с плавающей точкой
- •1.7.2Ошибка усечения
- •1.8 Сжатие данных
- •1.8.1Общие методы сжатия данных
- •1.8.2Сжатие звука
- •1.8.3Сжатие изображений
- •1.9 Ошибки передачи данных
- •1.9.1Контрольный разряд четности
- •1.9.2Коды с исправлением ошибок
- •2Манипулирование данными
- •2.1 Архитектура эвм
- •2.1.1Сложение двух чисел, хранящихся в оперативной памяти
- •2.1.2Кто и что изобрел?
- •2.2 Машинный язык
- •2.2.1Система команд
- •2.2.2Кэш-память
- •2.2.3Арифметико-логические команды
- •2.2.4Команды управления
- •2.2.5Деление двух значений, хранящихся в памяти
- •2.3 Выполнение программы
- •2.3.1Пример выполнения программы
- •2.3.2Команды переменной длины
- •2.3.3Программы и данные
- •2.4 Арифметические и логические операции
- •2.4.1Логические операции
- •2.4.2Сравнение вычислительной мощности эвм
- •2.4.3Операции сдвига
- •2.4.4Арифметические операции
- •2.5 Связь с другими устройствами
- •2.5.1Связь через контроллер
- •2.5.2Строение шины
- •2.5.3Скорость передачи данных
- •2.6 Другие архитектуры
- •2.6.1Конвейерная обработка
- •3Операционные системы и организация сетей
- •3.13.1. Эволюция операционных систем
- •3.1.1Однопроцессорные системы
- •3.1.2Многопроцессорные системы
- •3.2 Архитектура операционной системы
- •3.2.1Программное обеспечение
- •3.2.2Полезное единообразие или вредная монополия?
- •3.2.3Компоненты операционной системы
- •3.2.4Операционная система linux
- •3.2.5Начало работы операционной системы
- •3.3 Координирование действий машины
- •3.3.1Понятие процесса
- •3.3.2Управление процессами
- •3.3.3Модель «клиент-сервер»
- •3.4 Обработка конкуренции между процессами
- •3.4.1Семафор
- •3.4.2Взаимная блокировка
- •3.5 Сети
- •3.5.1Основы организации сетей
- •3.5.2Интернет
- •3.5.3Топология сети Интернет
- •3.5.4Система адресов Интернета
- •3.5.5Электронная почта
- •3.5.6Всемирная паутина
- •3.6 Сетевые протоколы
- •3.6.1Управление правом отправки сообщений
- •3.6.2Сеть ethernet
- •3.6.3Javascript, апплеты, cgi и сервлеты
- •3.6.4Многоуровневый принцип программного обеспечения Интернета
- •3.6.5Комплект протоколов tcp/ip
- •3.6.6Протоколы рорз и imap
- •3.7 Безопасность
- •3.7.1Протокол защищенных сокетов
- •3.7.2Группа компьютерной «скорой помощи»
- •4Алгоритмы
- •4.1 Понятие алгоритма
- •4.1.1Предварительные замечания
- •4.1.2Формальное определение алгоритма
- •4.1.3Определение алгоритма
- •4.1.4Абстрактная природа алгоритма
- •4.2 Представление алгоритма
- •4.2.1Примитивы
- •4.2.2Псевдокод
- •4.3 Создание алгоритма
- •4.3.1Искусство решения задач
- •4.3.2Итеративные структуры в музыке
- •4.3.3Первый шаг в решении задачи
- •4.4 Итеративные структуры
- •4.4.1Алгоритм последовательного поиска
- •4.4.2Управление циклом
- •4.4.3Алгоритм сортировки методом вставок
- •4.5Рекурсивные структуры
- •4.5.1Поиск и сортировка
- •4.5.2Алгоритм двоичного поиска
- •4.5.3Управление рекурсивными структурами
- •4.6 Эффективность и правильность
- •4.6.1Эффективность алгоритма
- •4.6.2Проверка правильности программного обеспечения
- •4.6.3По ту сторону проверки правильности программ
- •5Языки программирования
- •5.1 Исторический обзор
- •5.1.1Ранние поколения
- •5.1.2Интерплатформенное программное обеспечение
- •5.1.3Независимость от машины
- •5.1.4Парадигмы программирования
- •5.2 Основные понятия традиционного программирования
- •5.2.1Культуры языков программирования
- •5.2.2Переменные и типы данных
- •5.2.3Структуры данных
- •5.2.4Константы и литералы
- •5.2.5Операторы присваивания
- •5.2.6Управляющие операторы
- •5.2.7Комментарии
- •5.3 Процедурные единицы
- •5.3.1Процедуры
- •5.3.2Событийно-управляемые программные системы
- •5.3.3Параметры
- •5.3.4Функции
- •5.3.5Операторы ввода-вывода
- •5.4 Реализация языка программирования
- •5.4.1Процесс трансляции программы
- •5.4.2Реализация java
- •5.4.3Компоновка и загрузка
- •5.4.4Пакеты разработки программного обеспечения
- •5.5 Объектно-ориентированное программирование
- •5.5.1Классы и объекты
- •5.5.3Конструкторы
- •5.5.4Дополнительные возможности
- •5.6 Параллельные операции
- •5.7 Декларативное программирование
- •5.7.1Логическая дедукция
- •5.7.2Язык программирования Prolog
- •6Разработка программного обеспечения
- •6.1 Разработка программного обеспечения
- •6.1.1Ассоциация по вычислительной технике
- •6.1.2Институт инженеров по электротехнике и электронике
- •6.2 Жизненный цикл программы
- •6.2.1Цикл как единое целое
- •6.2.2Разработка программного обеспечения на практике
- •6.2.3Этапы разработки программного обеспечения
- •6.2.4Анализ
- •6.2.5Проектирование
- •6.2.6Реализация
- •6.2.7Тестирование
- •6.2.8Современные тенденции
- •6.3 Модульность
- •6.3.1Модульная реализация программы
- •6.3.2Связь модулей системы
- •6.3.3Связность модуля
- •6.4 Методики проектирования
- •6.4.1Нисходящее и восходящее проектирование
- •6.4.2Модели проектирования
- •6.4.3Разработка открытых программных продуктов
- •6.5 Инструменты проектирования
- •6.6 Тестирование
- •6.7 Документация
- •6.8 Право собственности на программное обеспечение и ответственность
- •Часть 3 организация данных
- •7Структуры данных
- •7.1 Основы структур данных
- •7.1.1Опять абстракция
- •7.1.2Статические и динамические структуры
- •7.1.3Указатели
- •7.2 Массивы
- •7.3 Списки
- •7.3.1Непрерывные списки
- •7.3.2Реализация непрерывных списков
- •7.3.3Связные списки
- •7.3.4Поддержка абстрактного списка
- •7.4 Стеки
- •7.4.1Откат
- •7.4.2Реализация стека
- •7.5 Очереди
- •7.5.1Проблема указателей
- •7.6 Деревья
- •7.6.1Реализация дерева
- •7.6.2Сбор мусора
- •7.6.3Пакет бинарного дерева
- •7.7 Пользовательские типы данных
- •7.7.1Пользовательские типы
- •7.7.2Классы
- •7.7.3Описательное и процедурное знание
- •7.7.4Стандартная библиотека шаблонов
- •7.8 Указатели в машинном языке
- •8Файловые структуры
- •8.1 Роль операционной системы
- •8.1.1Таблицы размещения файлов
- •8.2 Последовательные файлы
- •8.2.1Обработка последовательных файлов
- •8.2.2Консорциум производителей программного обеспечения для www
- •8.2.3Текстовые файлы
- •8.2.4Текстовые и двоичные файлы
- •8.2.5Вопросы программирования
- •8.2.6Семантическая сеть
- •8.3 Индексация
- •8.3.1Основные положения индексации
- •8.3.2Вопросы программирования
- •8.3.3Расположение файлов на дисках
- •8.4 Хэширование
- •8.4.1Хэш-система
- •8.4.2Проблемы распределения
- •8.4.3Аутентификация посредством хэширования
- •8.4.4Вопросы программирования
- •9Структуры баз данных
- •9.1 Общие вопросы
- •9.2 Многоуровневый подход к реализации базы данных
- •9.2.1Система управления базой данных
- •9.2.2Распределенные базы данных
- •9.2.3Модели баз данных
- •9.3 Реляционная модель баз данных
- •9.3.1Вопросы реляционного проектирования
- •9.3.2Системы баз данных для персональных компьютеров
- •9.3.3Хронологические базы данных
- •9.3.4Реляционные операции
- •9.3.5Вопросы реализации
- •9.3.6Язык sql
- •9.4 Объектно-ориентированные базы данных
- •9.5 Поддержка целостности базы данных
- •9.5.1Пространственные базы данных
- •9.5.2Протоколы фиксации/отката изменений
- •9.5.3Блокировка
- •9.6 Воздействие технологий баз данных на общество
- •10Искусственный интеллект
- •10.1 Интеллект и машины
- •10.1.1Конечный результат или имитация
- •10.1.2Истоки искусственного интеллекта
- •10.1.3Тест Тьюринга
- •10.1.4Машина для решения головоломки из восьми фишек
- •10.2 Распознавание образов
- •10.3 Мышление
- •10.3.1Продукционные системы
- •10.3.2Интеллект, основанный на поведении
- •10.3.3Деревья поиска
- •10.3.4Эвристика
- •10.4 Искусственные нейронные сети
- •10.4.1Основные свойства
- •10.4.2Приложение теории
- •10.4.3Ассоциативная память
- •10.5 Генетические алгоритмы
- •10.6 Прочие области исследования
- •10.6.1Обработка лингвистической информации
- •10.6.2Рекурсия в естественных языках
- •10.6.3Роботы
- •10.6.4Системы баз данных
- •10.6.5Экспертные системы
- •10.7 Обдумывая последствия
- •10.7.1Сильный искусственный интеллект против слабого
- •11Теория вычислений
- •11.1 Функции и их вычисление
- •11.1.1Теория рекурсивных функций
- •11.2 Машины Тьюринга
- •11.2.1Основы машины Тьюринга
- •11.2.2Истоки машины Тьюринга
- •11.2.3Тезис Черча-Тьюринга
- •11.3 Универсальные языки программирования
- •11.3.1Скелетный язык
- •11.3.2Существуют ли инопланетяне?
- •11.3.3Универсальность скелетного языка
- •11.4 Невычислимая функция
- •11.4.1Проблема останова
- •11.4.2Неразрешимость проблемы останова
- •11.5 Сложность задач
- •11.5.1Измерение сложности задачи
- •11.5.2Пространственная сложность
- •11.5.3Полиномиальные и не полиномиальные задачи
- •11.5.5Детерминированность против недетерминированности
- •11.6Шифрование с открытым ключом
- •11.6.1Шифрование при помощи задачи о ранце
- •11.6.2Популярные системы шифрования
- •11.6.3Модульная арифметика
- •11.6.4Обратно к шифрованию
6.8 Право собственности на программное обеспечение и ответственность
Многие согласятся, что компания или отдельный человек должны иметь право получать прибыль с инвестиций, вложенных в создание качественного программного обеспечения. Без средств защиты подобных капиталовложений мало кто захотел бы брать на себя ответственность по созданию программного обеспечения, необходимого нашему обществу. Право собственности на программное обеспечение представляет собой нечто среднее между авторским и патентным правом. Эти законы были созданы для того, чтобы разработчик продукта мог представить его обществу, зная, что его авторские права защищены. Но программное обеспечение обладает свойствами, которые не позволяют применять принципы авторского и патентного права к вопросам владения программным обеспечением.
Машина therac-25
Важность дисциплинированности и порядка при создании программных систем подтверждается несчастными случаями, причиной которых стала машина Therac-25, медицинский линейный ускоритель, применяемый в середине 80-х годов XX века. Ошибки при проектировании системы повлекли за собой шесть случаев передозировки радиации, три из которых привели к смертельному исходу. Причиной этого стали ошибки при создании интерфейса системы, который позволял оператору включать излучение раньше, чем машина переключится на заданную дозу излучения, и плохая координация аппаратного и программного обеспечения, что привело к несоблюдению мер безопасности.
Авторское право первоначально создавалось для защиты авторских прав на литературные произведения. В этом случае ценность представляет форма выражения мыслей, а не сами мысли. Ценными в стихотворении являются рифма, стиль и его структура, а не его тема; в романе ценность представляет то, как автор излагает историю, а не сама история. Поэтому вклад автора можно защитить, предоставив ему право собственности на определенное выражение идеи, но не на саму идею. Другой человек имеет право изложить эту же идею, если только его изложение не обладает существенным сходством с оригиналом.
Короче говоря, авторское право было создано для защиты формы, а не содержания, но ценность программного обеспечения часто заключается как раз в его содержании, а не в его форме. Поэтому простое применение авторского права не защищает прав разработчиков программного обеспечения. Суды признали существование такой проблемы и предприняли попытки предоставить разработчикам правовую защиту в рамках существующего авторского права. Трудность состоит в том, чтобы определить, что обозначает термин «существенное сходство» в случае программного обеспечения.
Несерьезно утверждать, что две программы заметно схожи, только потому, что они выполняют одинаковые действия. В таком случае можно сделать вывод, что может существовать только одна операционная система, поскольку любая операционная система занимается координацией действий машины и распределением ресурсов. Но что если совпадают глубинные структуры двух программ (отображаемые на блок-схемах или на диаграммах взаимодействия)? Тогда нельзя сказать точно, имеем ли мы дело с плагиатом. Если, например, одинаковая структура является результатом применения одной модели проектирования, то сходство программ просто означает, что они обе хорошо продуманы. Точно так же тот факт, что две программы выполняют какую-либо задачу одинаковым способом, может просто означать, что существует один хороший алгоритм для выполнения некоторых прикладных задач, а не то, что имело место нарушение авторских прав.
Для разрешения таких трудностей суды разделяли сходство программ, которое можно признать нарушением авторских прав и которое нельзя. Например, к нарушению авторских не относятся характеристики программы, которые определяются существующими стандартами или являются логическим следствием назначения программы, и составляющие, которые являются общедоступными.
Если сходство таких характеристик не нарушает закона об авторском праве, что же тогда можно признать нарушением авторского права? Некоторые обвинители с успехом доказывали, что авторское право должно защищать внешний вид программной системы и способ взаимодействия с пользователем. Хотя эти понятия и не использовались до 1985 года, они появились в 60-е годы XX века, когда фирма IBM объявила о выпуске семейства ЭВМ System/360. Это семейство ЭВМ включало в себя самые разные машины — от небольшой машины для мелких предприятий до крупных машин, выполняющих сложные действия. Все эти машины поставлялись в комплекте с операционными системами, в которых способы взаимодействия с внешней средой мало отличались друг от друга. То есть вся серия машин имела стандартный пользовательский интерфейс. Предприятие могло с легкостью перейти на более сложные машины той же серии. Для этого не потребовалось бы ни перестройки программ, ни дополнительного обучения персонала, поскольку внешний вид системного программного обеспечения и способ взаимодействия пользователя и системы были одинаковыми для всей серии.
В настоящее время достоинства стандартного пользовательского интерфейса признаются всеми разработчиками, и многие стараются применять его. Если интерфейс, разработанный одной компанией, становится популярным, то ее конкурентам выгодно создавать программное обеспечение со сходным пользовательским интерфейсом, поскольку это сходство облегчает переход пользователя от популярной системы к системе, разработанной этой компанией, даже если эти две системы имеют совершенно разное внутреннее строение. Компании, сталкивающиеся с таким поведением конкурентов, обращаются в суд с иском о нарушении авторских прав, утверждая право собственности на внешний вид системы и на способ взаимодействия с пользователем. Можно согласиться, что интерфейс системы программного обеспечения обладает характеристиками собственности, защищаемой авторским правом.
Этот довод в защиту авторского права был проверен в 1987 году, когда корпорация Lotus Development Corporation подала в суд на компанию Mosaic Software за использование интерфейса системы табличных вычислений Lotus 1-2-3 и выиграла дело. Однако в настоящее время этот аргумент не всегда приводит к успеху. Если, например, защитнику удастся убедить суд в том, что интерфейс системы настолько распространен и популярен, что стал стандартом и всеобщим достоянием, тогда авторское право не будет распространяться на данный пользовательский интерфейс.
Программное обеспечение уникально в том смысле, что оно является предметом потребления, к которому применимо и авторское, и патентное право. Однако часто это приводит к тому, что суд отказывается трактовать авторское право широко, боясь нарушить грань между авторским и патентным правом.
Точно так же, как и в случае с авторским правом, при использовании патентного права для защиты программного обеспечения возникают серьезные трудности. Одно из препятствий — это давно существующий закон, гласящий, что никто не может владеть естественными явлениями, такими как законы физики, математические формулы и мысли. В этот список часто включаются и алгоритмы. Однако количество случаев получения разработчиками патентов растет. В качестве примера можно привести алгоритм шифрования RSA, который широко применяется во многих современных системах шифрования с открытым ключом.
Существует еще одна сложность использования патентов для защиты права собственности на программное обеспечение. Получение патента — дорогостоящий и длительный процесс, который часто продолжается несколько лет. За это время программное обеспечение может устареть, а до получения патента заявитель не защищен от незаконного присвоения созданного им продукта.
Авторское и патентное права были созданы для защиты прав разработчиков и изобретателей, чтобы они не опасались представить свои идеи обществу. В отличие от этого закон о производственных секретах ограничивает распространение идей. Этот закон, созданный, чтобы обеспечить этичное поведение конкурирующих компаний, защищает от незаконного разглашения или присвоения внутренних разработок компании. Предприятия, пытающиеся защитить свои производственные секреты, часто используют соглашения о неразглашении информации, которые подписываются сотрудниками, имеющими доступ к секретной информации. Суды поддерживают заключение таких соглашений.
Для того чтобы защитить себя от ответственности, разработчики программного обеспечения часто сопровождают продукт сообщением о том, что они снимают с себя всякую ответственность. Например, распространено такое сообщение, как «Компания X не несет ответственности за последствия использования данного программного обеспечения». Однако суды редко признают такие заявления, если истец может доказать небрежное отношение ответчика к разработке продукта. Поэтому в процессе судебного разбирательства, касающегося ответственности разработчика, основное внимание уделяется тому, был ли разработчик достаточно внимателен, создавая программное обеспечение, выполняющее определенные действия. Внимательность, достаточная для разработки надежного текстового редактора, может быть признана халатным отношением при разработке программного обеспечения, управляющего работой атомного реактора. Следовательно, самой лучшей защитой от судебных исков в данном случае является следование строгим принципам проектирования программного обеспечения.
