TP_konspekt_prezentatsia


Чтобы посмотреть презентацию с картинками, оформлением и слайдами, скачайте ее файл и откройте в PowerPoint на своем компьютере.
Текстовое содержимое слайдов презентации:

Мохов В.А. конспект-презентация В среде профессиональных программистов существует понятие перманентного «кризиса программирования», который проявляется в следующем:1. Большие проекты выполняются с отставанием от графика.2. Большие проекты выполняются с превышением сметы расходов.3. Разработанный программный продукт не обладает требуемыми функциональными возможностями.4. Производительность разработанного продукта низка.5 Качество разработанного продукта не удовлетворяет пользователя. Основными причинами существования кризиса программирования являются:Сложность. Одна из проблем определяется природой человеческого интеллекта и состоит в неспособности им обрабатывать сложность. Само понятие «сложность» следует рассматривать в виде двух аспектов:Сложность программ.Сложность администрирования.Согласованность. Значительная часть сложности относится к решению проблемы согласования различных интерфейсов.Изменяемость. Программное обеспечение очень легко изменить. При этом появление добавленного кода («заплат») может привести к разрушению идей, заложенных в код изначально. Незримость. Реальность программного обеспечения (ПО) не встраивается естественным образом в пространство. У ПО сверхсложное геометрическое представление – как правило, большое количество неориентированных графов, наложенных один на другой.Разрыв между теорией и практикой во многих областях программирования оказывает существенное влияние на кризис программирования.Незначительные результаты исследовательской работы в области разработки ПО. Исследования, проводимые в последнее время в университетах и большинстве коммерческих компаний, являются фрагментарными и односторонними. Многие крупные компании славятся не столько генерированием новых идей, сколько доводкой заимствованных или купленных. Невозможность проанализировать и обобщить действия великих программистов за работой. Давно возникло понимание того, что некоторые программисты на порядок, а то и на несколько порядков, более полезны, чем остальные.Невозможность менеджера правильно сформировать проектную команду.Экстремальные условия, в которых выполняются многие проекты. Установлено, что продуктивность работы тех, кто находиться в хорошем офисе, и может, закрыв дверь, не отвлекаться на телефонные звонки и посторонние дела, почти в 2,6 раза выше, чем у находящихся в коллективных комнатах. Жизненный цикл (ЖЦ) ПО – это период времени, который начинается с момента принятия решения о необходимости создания ПО и заканчивается в момент его полного изъятия из эксплуатации. Жизненный цикл ПО включает следующие стадии:Анализ.Проектирование.Программирование.Тестирование и отладка.Эксплуатация. Модель ЖЦ ПО – это структура, определяющая последовательность выполнения действий и задач, а также взаимосвязи процессов на протяжении всего его ЖЦ.Базовые документы, создаваемые для стандартизации в области технологий программирования разрабатываются в основном двумя организациями:International Organization for Standardization (ISO) – Международная организация по стандартизации.International Electrotechnical Commission (IEC) – Международная комиссия по электротехнике. Основным нормативным документом, регламентирующим состав процессов ЖЦ ПО является международный стандарт ISO/IEC 12207:1995 «Information Technology – Software Life Cycle Processes».ISO/IEC 12207:1995 определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО. Стандарт определяет программный продукт как набор компьютерных программ, процедур, документации и данных. Процесс - совокупность взаимосвязанных действий, преобразующих некоторые входные данные в выходные. В результате для каждого серьёзного проекта ИС приходиться создавать комплекты нормативных и методических документов, регламентирующих процессы создания конкретного прикладного ПО, поэтому сегодня в отечественных разработках целесообразно использовать современные международные стандарты.В соответствии со стандартом ISO/IEC 12207:1995 все процессы ЖЦ ПО разделены на три группы:- основные;- вспомогательные;- организационные. Состав перечисленных групп процессов определен так, как показано на рисунке. Также стандартом ISO/IEC 12207:1995 определяется технология проектирования ПО.Технология проектирования ПО - совокупность технологических операций проектирования в их последовательности и взаимосвязи, приводящая к разработке проекта ПО. Современная технология проектирования ПО должна обеспечивать выполнение следующих требований:1. Соответствие стандарту проектирования - ISO/IEC 12207 (поддержка всех процессов ЖЦ ПО).2. Гарантированное достижение целей разработки ИС в рамках установленного бюджета, с заданным качеством и в установленное время.3. Возможность декомпозиции проекта на составные части, разрабатываемые группами исполнителей ограниченной численности (3ч7 человек), с последующей интеграцией составных частей.4. Минимальное времени получения работоспособного программного варианта реализации ИС.5. Независимость получаемых проектных решений от средств реализации ИС (СУБД, операционных систем, языков и систем программирования).6. Поддержка проекта ПО комплексом согласованных CASE-средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ ПО. Реальное применение любой технологии проектирования при реализации конкретного проекта в конкретной организации основывается на выработке и соблюдении всеми участниками проекта ряда внутренних стандартов (это особенно актуально при коллективной разработке ПО большим коллективом). К ним относятся следующие:Стандарт проектирования.Стандарт оформления проектной документации.Стандарт интерфейса конечного пользователя с системой. Стандарт проектирования должен устанавливать:- набор необходимых моделей (диаграмм) на каждой стадии проектирования и степень их детализации;- правило фиксации проектных решений на диаграммах (соглашения по терминологии, общий набор атрибутов для всех объектов, правило оформления диаграмм и т.д.);- требования к конфигурации рабочих мест разработчиков (настройки ОС, настройки CASE-средств и т.д.);- механизм обеспечения совместной работы над проектом (правила интеграции подсистем проекта, правила поддержания проекта в одинаковом для всех разработчиков состоянии правила анализа проектных решений на непротиворечивость и т.д.) Стандарт оформления проектной документации должен устанавливать:- комплектность, состав и структуру документации на каждой стадии проектирования (в соответствии со стандартом ГОСТ РИСО 9127-94 «Системы обработки информации. Документация пользователя и информация на упаковке потребительских программных пакетов»);- требования к оформлению документации (включая требования к содержанию разделов, подразделов, таблиц и т.д.);- правила подготовки, рассмотрения, согласования и утверждения документации с указанием предельных сроков для каждой стадии;- требования к настройке издательской системы (стили), используемой в качестве встроенного средства подготовки документации;- требования к настройке CASE-средств (для обеспечения подготовки документации в соответствии с установленными правилами). Стандарт интерфейса конечного пользователя с системой должен регламентировать:- правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления;- правила использования клавиатуры и мыши;- правила оформления текстов помощи;- перечень стандартных сообщений;- правила обработки реакции пользователя. Декомпозиция – разделение сложной системы на несколько составных частей.Классификация – система, согласно которой что-либо распределяется по группам, разрядам, признакам, принципам, классам.Одна из наиболее известных и удачных классификаций – периодический закон и периодическая система химических элементов Д.М. Менделеева.Программа – исполняемый код, пригодный для запуска своим автором на системе, на которой он был разработан.Программный продукт – программа, которую любой человек может запускать, тестировать, исправлять и развивать. Такая программа должна быть написана в обобщенном стиле, тщательно оттестирована и сопровож-дена подробной документацией.«Любой человек» – программист, имеющий разрешение работать с ис-ходными текстами программ. Проект – ориентированное на программный продукт (не на отдельный процесс!) объединение действий разработчиков.Проекты классифицируют по:степени коммерциализации;масштабу.Выделяют две степени коммерциализации проектов:Коммерческий проект — его разработчики ориентируются на получение прибыли.Некоммерческий проект – его разработчики ориентируются на приобретение опыта, статуса, обучение и т.п. В зависимости от масштаба можно выделить четыре категории проектов: № Категорияпроекта Количестворазработчиков Протяженность 1. Небольшой менее 10 от 3 до 6 месяцев 2. Средний от 20 до 30 от 1 до 2 лет 3. Крупно-масштабный от 100 до 300в иерархии от 3 до 5 лет 4. Гигантский от 1000 до 2000в иерархии от 7 до 10 лет Группы участников процесса разработки подразделяют на девять категорий:1. Управляющий комитет;2. Команда разработчиков продукта;3. Команда версии. В состав команды входят:- технические писатели;- инженеры тестирования;- инженеры качества;- специалисты по сопровождению продукта;- специалисты по продажам продукта. 4. Команда разработчиков компонента. В состав команды входят:- инженеры – разработчики;- инженеры тестирования;- технические писатели.5. Пользователи;6. Архитектурный совет;7. Совет старейшин;8. Группа поддержки пользователей;9. Команда локализации. Последовательность версий программного продукта может быть проиллюстрирована следующим образом. Существует одна основная эволюционирующая версия, от которой по мере готовности ответвляются версии, предназначенные для пользователей. Если новая версия включает существенные изменения (например, новый интерфейс), то увеличивается на единицу её «основной» номер (число перед точкой). Если изменения незначительны и сводятся к небольшим поправкам функциональности, то увеличивается на единицу «второстепенный» номер (число после точки). В ответвившиеся версии также могут вноситься исправления (обычно – только исправления ошибок).Следует отметить, что развиваться и включать кардинальные изменения может только основная версия, остальные версии – лишь сопровождаются. Основная задача профессионального программирования заключается в создании качественного программного обеспечения. Стержневая подзадача – осуществление переходов от уровня постановки задачи в предметной области к уровню моделей, алгоритмов и машинного кода.Цель программирования – получение результатов работы программы.Рекомендации к решению основной задачи программирования на профессиональном уровне:1.Сначала следует определить методологию программирования, которая будет включать совокупность методов и концепций, объединённых общим философским подходом.2.Далее следует выбрать технологический подход, который будет определять совокупность процессов, применяемых при разработке программного продукта. Определённая ранее методология включает совокупность методов, которые будут применены в технологическом подходе.3.Методология и технология определяют языки и системы программирования, необходимые для каждого процесса избранного технологического подхода. 4.Технологические процессы будут исполняться на некоторых аппаратной и операционной платформах. Следует отметить, что аппаратная и операционная платформы могут существенно определять наличие и специфику инструментов (систем программирования). В большинстве разработок следует избегать зависимости от платформ, однако ряд проектов (как правило, системных) в большой степени опирается на их хорошее знание.Таким образом, можно резюмировать, что технология программирования, как таковая, изучает технологические процессы и порядок их выполнения при решении основной задачи профессионального программирования, опираясь на использование соответствующих знаний, методов и средств. Алгоритм – точное и конечное описание того или иного общего метода, основанного на применении исполнимых элементарных тактов обработки данных. Алгоритм имеет пять важных свойств:Конечность. Алгоритм всегда должен заканчиваться после выполнения конечного числа шагов.Определённость. Каждый шаг алгоритма должен быть точно определён.Наличие входных данных. Алгоритм имеет некоторое число входных данных, задающихся до начала его работы или определяющихся динамически во время его выполнения.Наличие выходных данных. Алгоритм имеет одно или несколько выходных данных, имеющих определённую связь с входными данными.Эффективность. Алгоритм обычно считается эффективным, если его операторы достаточно просты для того, чтобы их можно было точно выполнить в течение конечного промежутка времени с помощью карандаша и бумаги. С алгоритмами связаны следующие области исследований:Анализ алгоритмов. Предмет этой области состоит в том, чтобы для заданного алгоритма определить рабочие характеристики.Теория алгоритмов. В этой области рассматриваются вопросы существования или не существования эффективных алгоритмов вычисления определённых величин.Построение алгоритмов. В этой области рассматриваются стандартные приёмы и методы, используемые при написании алгоритмов.Большинство практических алгоритмов, с которыми работают программисты, являются полиномиальными. Это означает, что время работы алгоритма с данными на входе длины n составляло не более o(nk) для некоторой константы k, не зависящей от n. Модель – это упрощенное представление реальности.Моделирование рассматривают, как метод исследования систем на основе переноса изучаемых свойств системы на объекты другой природы.Инженерная методика создания моделей позволяет:визуализировать систему;определить структуру системы и её поведение;документировать принимаемые решения.С моделированием тесно связано понятие абстрагирования. Абстрагирование – моделирование возможных реализаций программного продукта с выделением существенных особенностей и подавлением деталей. Подобный прием (и не только!) позволяет рассматривать моделирование также в качестве попытки решить проблему сложности. В этом плане моделирование предоставляет несколько возможных подходов (различающихся способами декомпозиции систем) к разработке программного обеспечения:Структурный (функционально–модульный).Объектно-ориентированный.Моделирование данных.Моделирование знаний. Сложность является основной проблемой при создании больших и сложных систем любой природы.Главным способом преодоления сложности разработки больших программных систем является правильная декомпозиция.Термин «декомпозиция» происходит от латинского «divide et impera», что означает «разделяй и властвуй». Далее по тексту термин «декомпозиция» применяется, как прием иерархического проектирования, который заключается в построении сложной системы, из небольшого количества крупных частей. При этом каждая крупная часть в свою очередь строится из частей меньшего размера и так далее, до тех пор, пока самые небольшие части можно будет строить из имеющегося материала. «Правильная» декомпозиция – означает следующее:- количество связей между отдельными подсистемами – минимально;- связность отдельных частей внутри каждой подсистемы – максимальна;При этом структура системы такова, что все взаимодействия между её подсистемами укладываются в стандартные рамки, то есть:- каждая подсистема скрывает своё содержимое от других подсистем;- каждая подсистема имеет чётко определённый интерфейс с другими подсистемами.Сокрытие содержимого (в данном случае – абстрагирование или инкапсуляция) позволяет рассматривать структуру каждой подсистемы независимо от других подсистем Сущность структурного подхода к разработке ПО заключается в его разбиении на автоматизируемые функции: система разбивается на функциональные подсистемы, которые, в свою очередь делятся на подфункции, те – на задачи и так далее, до конкретных процедур.Для описания системы используются две группы средств:1. Описывающие функциональную структуру системы.2. Описывающие отношение между данными.В обоих случаях широкое распространение получили следующие модели:1. Structured Analysis and Design Technique (SADT) – модели и соответствующие функциональные диаграммы;2. Data Flow Diagrams (DFD) – диаграммы потоков данных;3. Entity-Relationship Diagrams (ERD) – диаграммы «сущность-связь». Метод SADT – это совокупность процедур и правил, предназначенных для построения функциональной модели объекта в какой-либо предметной области.Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями. Основные концепции метода:1. Графическое представление блочного моделирования. Элемент модели (диаграммы) – блок, отображающий функцию. Дуги блока – интерфейсы входа-выхода, предназначенные для взаимодействия блоков друг с другом.2. Строгость и точность. Правила SADT включают:- ограничение количества блоков на каждом уровне декомпозиции (3ч6 блоков);- связность диаграмм (через номера блоков);- уникальность меток и наименований (без повторов);- синтаксические правила для графики (блоков и дуг);- разделение входов и управлений (правило определения роли данных).3. Отделение организации от функции. Необходимо исключить влияние административной структуры организации на функциональную модель. Модель SADT строится из следующих элементов:Диаграммы.Фрагменты текстов.Глоссарий.Ссылки друг на друга между перечисленными элементами.Диаграммы – главные компоненты модели. Все функции организации и интерфейсы на них представлены как блоки и дуги соответственно. На диаграммах используются пять типов взаимосвязей между блоками. На приведенном рисунке тип отношений между блоками определяется как (а) – «управление», (б) – «вход», (в) – «управленческая обратная связь», (г) – «входная обратная связь», (д) – «выход-исполнитель». Построение SADT–модели начинается с определения всей системы в виде простейшего компонента – одного блока и дуг, изображающих интерфейсы с функциями вне системы.Модель SADT представляет собой серию диаграмм с сопроводительной документацией, разбивающих сложный объект на составные части, которые изображены в виде блоков.Диаграмма предыдущего уровня называется родительской для более детальной диаграммы.Дуги, входящие в блок и выходящие из него на диаграмме верхнего уровня, являются точно теми же самыми, что и дуги, входящие в диаграмму нижнего уровня.Не присоединённые дуги соответствуют входам, управлениям и выходам родительского блока. Источник или получатель этих пограничных дуг может быть обнаружен только на родительской диаграмме. Все пограничные дуги должны продолжаться на родительской диаграмме, чтобы она была полной и непротиворечивой. На SADT-диаграммах не указаны явно ни последовательность, ни время. Обратные связи, итерации, продолжающиеся процессы и перекрывающиеся (по времени) функции изображаются с помощью дуг. Обратные связи могут выступать в виде комментариев, замечаний, исправлений и так далее. DFD позволяют представить требования к проектируемой системе в виде иерархии функциональных компонентов (процессов), связанных потоками данных.Цель такого представления – продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами. Модель системы описывает асинхронный процесс преобразования информации. Декомпозиция контекстных диаграмм (диаграмм верхних уровней) продолжается, создавая многоуровневую иерархию диаграмм, до тех пор, пока не будет достигнут уровень декомпозиции, на котором процессы становятся элементарными и детализировать их далее невозможно.Для построения DFD используют две различные нотации, соответствующие методам Йордана и Гейна – Серсона. Далее в примерах будет использоваться более популярная сегодня нотация Гейна – Серсона. Основными компонентами диаграмм потоков данных являются:Внешние сущности.Системы и подсистемы.Процессы.Накопители данных.Потоки данных. Внешняя сущность – материальный объект или физическое лицо, представляющее собой источник или приёмник информации (заказчики, поставщики, клиенты, склад и т.п.) На диаграммах потоков данных внешняя сущность обозначается квадратом, бросающим тень. Системы и подсистемы являются элементами верхнего уровня декомпозиции и отображаются на контекстных диаграммах в виде единого целого. Системы и подсистемы декомпозируются на процессы – компоненты диаграмм, предназначенные для преобразования входных потоков данных в выходные в соответствии с определённым алгоритмом.Физически процесс может быть реализован различными способами: это может быть и подразделение организации, выполняющее обработку входных документов и выпуск отчётов, и программа, и аппаратно реализованное логическое устройство и т.д. Использование на диаграммах таких глаголов, как «обработать», «модернизировать» или «отредактировать», означает недостаточно глубокое понимание данного процесса и требует дальнейшего анализа.Накопитель данных – абстрактное устройство для хранения информации. Предполагается, что информацию в любой момент поместить в накопитель и через некоторое время извлечь, причём способы помещения и извлечения оттуда могут быть различны.Физически накопитель данных может быть реализован в виде ящика в картотеке, таблицы в оперативной памяти, файлы на магнитном носителе и т.д.На диаграмме потоков данных накопитель данных идентифицируется буквой «D» и произвольным числом. Поток данных определяет информацию, передаваемую через некоторое соединение от источника к приёмнику. Реальный поток данных может быть информацией, передаваемой по кабелю между двумя устройствами, пересылаемыми по почте письмами, магнитными лентами или дискетами, переносимыми с одного компьютера на другой, и т.д. На диаграмме поток данных изображается линией, оканчивающейся стрелкой, которая показывает направление потока. Каждый поток данных имеет имя, отражающее её содержание. При построении DFD-диаграмм принято пользоваться следующими рекомендациями:Размещать на каждой диаграмме от 3 до 6ч7 процессов.Декомпозицию потоков данных осуществлять параллельно с декомпозицией процессов.Стараться не использовать аббревиатуры.Не загромождать диаграммы несущественными деталями. Нотация ERD для построения диаграмм «сущность-связь» включает девать основных компонентов.Чаще всегоинформационные модели подобного типа применяются для проектирования структуры базы данных. Рассмотрим графические или текстовые нотации некоторых информационных моделей, поддерживающих методы объектно-ориентированной методологии разработки ПО. Данный язык имеет и текстовую, и графическую нотацию представления элементов.Пример тестового формализованного описания системы клиент-сервер на языке ACME может выглядеть следующим образом: System simple_cs ={ Component client = (Port send-request}Component server = (Port receive-request}Connector rpc = { Roles {caller, receiver}}Attachments: {Client.send-request to rpc-caller;Server.receive-request to rpc-receiver}} Язык UML (Universal Modeling Language - универсальный язык моделирования) включает три вида «строительных» блоков:1. Сущности - абстракции, являющиеся основными элементами модели. В языке есть четыре типа сущностей: - структурные сущности (класс, интерфейс, кооперация, прецедент, активный класс, компонент, узел); - поведенческие сущности (взаимодействие и автомат); - группирующие сущности (пакет); - аннотационные сущности (примечания). 2. Отношения - основные связующие строительные блоки. Язык вводит четыре базисных отношения: 1) зависимость; 2) ассоциацию; 3) обобщение; 4) реализацию. 3. Диаграммы - графические представления набора элементов, изображаемых чаще всего в виде связанного графа с вершинами (сущностями) и ребрами (отношениями).В общем случае диаграммы могут содержать любые комбинации сущностей и отношений. Однако на практике обычно применяется сравнительно небольшое количество типовых комбинаций. Нотация диаграммы классов выглядит следующим образом.Для отдельных классов сначала может быть указано только имя класса (а), а при дальнейшей разработке - добавлены атрибуты и операции класса (б). На рисунке (в) изображена схема задания отношения бинарной ассоциации между классами. Данная нотация также предполагает использование четырех типов отношений между классами, каждому из которых соответствует свое изображение связи. В нотации диаграмм вариантов использования применяется четыре типа элементов. В нотации диаграмм состояний также применяется четыре типа элементов.Для отдельных состояний может быть указано либо только имя состояния (а), либо имя и список внутренних действий или переходов в данном состоянии (б). На рисунке (в) приведен переход между состояниями, а на (г) - графическое изображение начального и конечного состояний. По аналогии с двумя предыдущими в нотации диаграмм деятельности применяется четыре типа элементов.На рисунке (а) приведено графическое изображение состояния действия. На рисунке (б) приведен пример ветвления, (в) и (г) - графическое изображение разделения и слияния параллельных потоков управления. На рисунке (а) ниже приведен простейший графический примитив диаграммы последовательности. Фокус управления изображается в форме вытянутого узкого прямоугольника (б). На рисунке приведено графическое изображение различных видов сообщений между объектами на диаграмме последовательности. На данных рисунках приведена нотация диаграмм кооперации уровня спецификациии – нотация уровня примеров. Нотация диаграмм компонентов выглядит следующим образом. При этом различают компоненты следующих видов:(а) - обычное изображение компонента;(б) - динамически подключаемые библиотеки;(в) - страницы на языке разметки гипертекста;(г) - файлы справки;(д) - файлы с исходными текстами программ. Нотацию диаграммы развертывания приведем на примере без комментариев. Ранее было отмечено, что данные – это отдельные информационные элементы, которые могут быть собраны вместе некоторым образом. Термин «данные» происходит от латинского «datum», означающего «факт». Однако данные могут описывать и нечто, не имеющее место в реальной действительности. Моделью данных будем называть средство, позволяющее реализовать интерпретацию данных в соответствии с указанными требованиями. Мо-дель данных является средством абстрагирования, дающим возможность увидеть информационное содержание данных, а не их конкретные значе-ния.Модели данных разделяются на два класса:1.Сильно типизированные модели, в которых предполагается, что все данные должны быть отнесены к какой-либо категории.2.Слабо типизированные модели, не связанные никакими предположениями относительно категорий. Модель данных определяет правила порождения допустимых структур данных и возможные операции над такими структурами. Это связано с ограничениями, вытекающими из особенностей используемых типов структур данных и операций, которые можно выполнять над структурами. Структуризация основывается на использовании отношений типа обобщение и агрегация.Инструментальные средства для спецификации концептуальной модели предметной области также принято называть моделями данных. Наиболее известной из таких моделей является модель «сущность-связь». Существуют специальные языки моделирования данных, которые являются комбинацией, по крайней мере, двух языков:1. Языка определения данных, который поддерживает определения или объявления данных.2. Языка обработки данных, который поддерживает операции с такими объектами или их обработку.Эти языки по способу получения результата подразделяются на два класса:1. Навигационные языки, которые осуществляют последовательное прохождение по связям, реализованным в структуре модели данных.2. Спецификационные языки, которые определяют только требования к результату, но не задают способ его получения. Основными компоненты модели данных являются:- структуры данных;- операции над данными;- ограничения целостности (логические операции, накладываемые на данные). Реляционная модель данных - это способ рассмотрения данных, то есть предписание для способа представления данных (посредством таблиц) и для способа работы с таким представлением (посредством операторов).Реляционную модель можно рассматривать как набор двумерных таблиц, где вертикальные колонки соответствуют элементам данных или полям, а горизонтальные строки образуют связь между этими элементами. Разработка модели включает идентификацию объектов, их атрибутов и первичных ключей. Первичный ключ - атрибут или набор атрибутов, который может быть использован для однозначной идентификации строки таблицы.Основными проблемами работы с данными является достижение непротиворечивости данных и отсутствие их дублирования. Эти задачи решаются с помощью нормализации. Концепции и методы нормализации были разработаны Эдгаром Коддом (Edgar Codd). Процесс нормализации, вообще говоря, не ограничивается третьей нормальной формой, но ее, в большинстве случаев, вполне достаточно для обеспечения непротиворечивости и отсутствия дублирования. В первой половине 70-х годов XX века велись споры о преимуществах 3-х моделей данных:1. Реляционной.2. Сетевой.3. Иерархической.Эти споры завершились «ничейным» исходом в открытой дискуссии Бахмана и Кодда в 1975 году. В настоящее время сформировалась новая тройка конкурентов.1. Реляционная модель.2. Объектная модель.3. Многомерная модель. Знание - особый, специфический вид информации. Знание характеризуется очень важным свойством - активностью, т. е. способностью самостоятельно обрабатывать информацию. Знание традиционно разделяется на два вида: декларативное и процедурное.Декларативное знание - набор конкретных сведений, относящихся к некоторой ситуации и фигурирующим в ней объектам.Процедурное знание - набор предписаний на какие-то случаи жизни. Это могут быть методы, алгоритмы и программы решения различных задач, с которыми человек уже сталкивался раньше и научился их решать. Существует и более детальная классификация типов знаний:- конструктивное знание - знание о возможной структуре и взаимодействии частей различных объектов;- фактографическое знание - количественные и качественные характеристики конкретных объектов, явлений и их элементов;- понятийное знание - набор некоторых понятий, описание их свойств и взаимосвязей. Это «первичное» знание, можно сказать - знание об основах знаний, знание о том, как использовать знания. Существует две основных модели представления знаний - логическая и эвристическая.В основе логических моделей лежит понятие формальной системы (теории). В формальных системах можно выделить множество базовых элементов, синтаксических правил, аксиом и правил вывода. Применяя правила вывода к аксиомам, можно получать синтаксически правильные совокупности, к которым можно снова применить правила. Правила вывода - наиболее сложная составляющая системы. Примеры формальных теорий - исчисление предикатов, конкретные системы продукций. В логических моделях отношения между отдельными единицами знаний выражаются только с помощью тех небогатых средств, которые предоставляются синтаксическими правилами используемой формальной системы. В отличие от формальной модели, эвристические модели имеют разнообразный набор средств, передающих специфические особенности той или иной проблемной области. Здесь повышается эффективность использования правил вывода. Среди эвристических моделей можно выделить три основные группы:Продукционные модели, образованные правилами.Сетевые модели, в основе которых лежит понятие сети, образованной помеченными вершинами и дугами. Вершины представляют некоторые сущности, а дуги - отношения между связываемыми ими сущностями.Фреймовые модели, базирующиеся на специальных структурах - фреймах, предназначенных для представления некоторых стандартных ситуаций. Левополушарная память обнаруживает себя как хранилище знаний, выраженных словами, символами, значениями и отношениями между ними в формулах и алгоритмах. Относящаяся к ней семантическая память - это «умственный лексикон» абстрактного знания, хранимый без ссылки на обстоятельства, при которых оно приобретено. Осуществляемое в ней обобщение, с одной стороны, обогащает память за счет введения запоминаемого в рамки определенных категорий, а с другой - обедняет ее за счет сохранения в понятиях только типовых деталей. Правополушарная память - эпизодическая, данная в контексте, в противоположность левополушарной памяти - классифицированной по различным основаниям и данной вне контекста. Использование первой дает возможность быстро узнавать, а второй - произвольно воспроизводить и экстраполировать свойства объектов, повышая предсказуемость ситуации.Все сказанное о памяти подводит к выводу, что специфика правого и левого полушарий определяется используемым способом объединения материала. Правополушарная классификация - ситуативная, она опирается на практический опыт человека, а левополушарная - категориальная, основанная на логике и понятийном мышлении. Венгерская нотация – это соглашение о наименовании переменных и функций.Это соглашение широко используется при программировании в среде Windows, так как делает код программы более понятным. Свое название венгерская нотация получила в честь родины ее создателя – Чарльза Симонаи (Charles Simonyi).Венгерская нотация основывается на следующем принципе: имена переменных должны содержать префикс, описывающий тип данных переменной. В ряде случаев, префикс может служить указателем на способ использования переменной. Пример использования соглашения о наименовании:achFile:Array[0…127]of Char;lpszName:PString;Первая переменная achFile содержит префикс, который расшифровывается как массив символов (array of characters); префикс переменной lpszName указывает на то, что переменная является указателем типа long на строку формата ASCIIZ (long pointer to string zero).Помимо предоставления возможности сделать код программы более понятным, венгерская нотация позволяет также избежать ряда ошибок.Список префиксов, наиболее часто используемых при программировании в среде Windows приводится в таблице. Префикс Описание a Массив (array) ch Символ (char) by Байт (byte) n Целое (short/int) i Целое (int) x, y Целое для координат (short/int) cx, cy Короткое целое для координат (short, count) b Булевское (bool) w Слово (word) l Длинное целое (long) dw Двойное слово (dword) fn Функция (function) p Указатель (pointer) s Строка (string) sz Строка, оканчивающаяся байтом 0 (string) Такой же принцип наименования используется при присвоении имен различным константам, но при этом в качестве префикса указывается группа принадлежности константы.Понимание принципов Венгерской нотации позволяет легко разбираться в смысле параметров функций Windows API и в большом числе программ, распространяемых в исходном виде. Методология программирования – совокупность методов, применяемых в жизненном цикле программного продукта и объединенных общим философским подходом.С каждой методологией программирования можно связать некоторые характерные для нее атрибуты:1. Философский подход (или основной принцип).2. Связное множество методов реализации.3. Концепции (понятия, замыслы), поддерживающие методы и позволяющие более точно их определять. Классификацию современных методологий можно определить на основе способов описания алгоритмов:1. Методология императивного программирования.2. Методология объектно-ориентированного программирования.3. Методология функционального программирования.4. Методология логического программирования.6. Методология программирования в ограничениях.7. Методология нейросетевого программирования.Любая методология находятся в диапазоне между двумя фундаментальными понятиями информатики – алгоритма и модели. На данный момент также выделяют две разновидности организации аппаратной поддержки методологий: централизованную и параллельную.Получение качественной оценки любой методологии основано на использовании двух параметров:1. Эффективность ПО на современных компьютерах.2. Общие затраты на разработку ПО.Соответственно выделяют две ветви в развитии языков, поддерживающих методологии:1. Языки (как правило, компилируемые), ориентируемые на скорость исполнения кода программы.2. Языки (и компилируемые, и интерпретируемые), ориентированные на высокий уровень и удобство программирования. Методология императивного программирования – это подход, основанный на последовательном изменении состояния вычислителя пошаговым образом.Методы и концепции:Последовательное изменение состояний вычислителя.Пошаговый контроль управления потоком команд.Вычислительная модель представляет собой описание последовательного изменения состояний вычислителя (применяемая математическая модель - машина Тьюринга).Применяемая структура данных – последовательность пар ячеек «адрес -> значение».Синтаксис и семантика. Основное синтаксическое понятие - оператор. При этом различают:1. Атомарные операторы – никакая их часть не является самостоятельным оператором (например, оператор присваивания, оператор безусловного перехода, вызова процедуры и т.п.).2. Структурные операторы, объединяющие другие операторы в новый, более крупный оператор (например, составной оператор, операторы выбора, цикла и т.п.). На практике для описания синтаксиса языков широко применяется формальная система обозначений Бэкуса – Наура. В ней одни синтаксические категории определяются через другие последовательно. В данной системе обозначений используются:1. Метапеременные — представляют собой слова или группы русских слов, заключённых в угловые скобки. Под значением метапеременной понимается некоторая конечная последовательность основных символов языка, из которых, в конечном счёте, состоят программы.2. Символ ::= означает «определяется как».3. Символ | означает «или».4. Символ * означает «произвольное количество повторений (в том числе ноль раз) того символа, за которым он указан».Символы, указанные в квадратных скобках — являются необязательными. Средство структурирования – подпрограмма (процедура или функция). Подпрограммы имеют параметры и локальные определения и могут быть вызваны рекурсивно. Функции возвращают значения как результат своей работы.Типичный подход к решению задачи: сначала исполняется алгоритм, решающий первую задачу. Результаты его работы сохраняются в специальном месте памяти, которое известно следующему алгоритму, и используется им и т.д.Императивные языки программирования представляют собой компактное средство описания функции переходов между состояниями вычислителя.Считается, что первым алгоритмическим языком программирования был язык Plankalkuel (от plan calculus), разработанный в 1945-1946 гг. Конрадом Цузе (Konrad Zuse). Наиболее известные и распространённые императивные языки программирования, были созданы в конце 50-х – середине 70-х годов XX века.1. Fortran (1954)2. Algol (1960)3. Pascal (1970)4. C (1972)5. ICON (1974)Класс задач. Данная методология наиболее пригодна для решения задач, в которых последовательное исполнение каких-либо команд является естественным. Пример – управление современными аппаратными средствами. С ростом сложности задачи императивные программы становятся менее читаемыми. Методология объектно-ориентированного программирования – подход, использующий объектную декомпозицию.Методы и концепции:1. Выделение объектов и связей между ними. Поддерживается концепциями инкапсуляции, наследования и полиморфизма.2. Применение абстрактных типов данных (основа - инкапсуляция).3. Описание поведения системы в терминах обмена сообщениями между объектами. В данном случае вычислительная модель в явном виде поддерживает только одну операцию - посылку сообщения объекту. При этом для модели справедливы следующие свойства:1. Объектом является процесс, который может иметь различные внутренние состояния.2. При получении сообщения объект становиться активным.3. Извне внутреннее состояние объекта может быть изменено только посредством передачи ему сообщения, специфицирующего выполняемую объектом операцию.4. Во время работы объект может обмениваться сообщениями с другими объектами. Синтаксис и семантика. Для ООП определены три основных свойства:1. Инкапсуляция – это сокрытие информации и комбинирование данных и функций.2. Наследование – сохранение способов первичного доступа к коду и данным у всех порождаемых объектов.3. Полиморфизм – присваивание действию одного имени, для различных объектов (одно название функции – разные действия объектов). Выделяют следующие элементы синтаксиса:Класс – тип данных для описания объектов.Объект – переменная-процесс с собственным внутренним состоянием, представляющая собой экземпляр класса.Сообщение – экземпляр класса, предназначенного для обмена данными между объектами.Поля – внутренние данные объекта.Свойства – переменные, для доступа к внутренним полям объекта.Методы (обработчики событий) – свойства процедурного типа. Если обработчик для сообщения выбирается динамически, то метод, реализующий данный обработчик, принято называть виртуальным. Языки объектно-ориентированного программирования условно подразделяют на три группы:1. Чистые языки. Содержат небольшую языковую часть и существенную библиотеку классов - Simula (1962), Smalltalk (1972), Beta (1975), Self (1986), Cecil (1992).2. Гибридные языки. Появились в результате внедрения объектно-ориентированных конструкций в популярные императивные языки - Ada (1974), C++ (1983), Object Pascal (1984), Eiffiel (1992).3. Урезанные языки. Появились в результате удаления из гибридных языков наиболее опасных и ненужных с объектно-ориентированной точки зрения конструкций – Java (1995), C# (2000). Класс задач. Данная методология является мощным средство для моделирования отношений между объектами практически в любой предметной области. Особенно удачно применяется при описании взаимодействия между элементами графического интерфейса. Методология функционального программирования – способ составления программ, в которых единственным действием является вызов функции, единственным способом расчленения программы на части – введение имени для функции и задание для этого имени выражения, вычисляющего значения функции, а единственным правилом композиции – оператор суперпозиции функции. Методы и концепции:1.Метод аппликативности - заключается в том, что программа есть выражение, составленное из применения функций к аргументам. Программа состоит из совокупности определений функций, представляющих собой вызовы других функций и предложений, управляющих последовательностью вызовов.2.Метод рекурсивного поведения – заключается в самоповторяющемся поведе-нии, возвращающемся к самому себе.3.Метод настраиваемости - заключается в том, что можно легко порождать новые программные объекты по образцу, как значения соответствующих выражений (применение порождающих функций к параметрам образца). Этому способствует то, что не только программа, но и любой программный объект (в идеале) является выражением. Вычислительная модель. Программы являются выражениями, а исполнение программ заключается в вычислении этих выражений. Для программ отсутствует понятие времени.Основная специфика функциональных языков программирования заключается в том, что функции обмениваются между собой данными непосредственно, т.е. без использования промежуточных переменных и присваиваний.Популярные языки функционального программирования:1.Lisp (1958)2.РЕФАЛ (1968)3.Scheme (1975)4.FP (1977) 5.ML (1978)6.Miranda (1985) 7.Standart ML (1985)8.Haskell (1990, 1998) Класс задач. Функциональное программирование обычно применяется для решения тех задач, которые трудно сформулировать в терминах последовательных операций.19. Методология логического программированияВ соответствии с этим подходом проблема описывается в виде программы, которая состоит из фактов и логических формул, и решается с помощью механизмов логического вывода. Методы и концепции:1.Применение единого механизма логического доказательства ко всей программе.2.Унификация структур данных при декомпозиции.Синтаксис и семантика задаются при помощи фактов (аксиом) и правил вывода. Правила вывода имеют вид так называемых «дизъюнктов Хорна» – утверждений вида:А <= B1& … &BnАксиомы в программах обычно представляются, как правила с пустой «посылкой»:А Известные языки логического программирования:1.Prolog (1971)2.LOGLISP (1982)3.Mercury (1993)Класс задач, решаемых с помощью методологии логического программирования, совпадает с классом задач функционального програм-мирования. Для данной методологии характерно, что в программе определяются:-тип данных решения;-предметная область решения;-ограничения на значение искомого решения.Синтаксис и семантика. В данном случае постановка задачи – это:1.Конечный набор переменных V = {v[1], …, v[n]}.2.Набор соответствующих им конечных множеств значений D = {d[1], …, d[n]}.3.Набор ограничений C = {c[1], …, c[m]}. Ограничения представляются как утверждения, в которые в качестве «пара-метров» входят переменные из некоторого подмножества V[j], j=1..m набора V.Решение задачи – это набор значений переменных, удовлетворяющий всем ограничениям C[j].Исполнение программы – это нахождение значений переменных.Языки программирования в ограничениях:1.Sketchpad (1963)2.УТОПИСТ (1980)3.Thinglab (1980)4.IDEAL (1981)5.OPS5 (1987)6.Bertrand (1998)7.OPL (1998) Пример программы на языке УТОПИСТ (Универсальные Текстовые ОПИСания Терминов):ПУСТЬ` СХЕМА: (I1, I2, I3, U1, U2, U3, R1, R2, R3: ВЕЩ`;УРАВ` U1 = I1 * R1;УРАВ` U2 = I2 * R2;УРАВ` U3 = I3 * R3;УРАВ` I1 + I2 + I3 = 0);СХЕМА1: СХЕМАR1 = 16, R2 = 32, R3 = 5,U1 = 50, U2 = -28;ДЕЙСТВИЯ`НА` СХЕМА1 ВЫЧИСЛИТЬ` U3;В класс задач, решаемых с помощью данной методологии, в основном входят задачи исследования операций и задачи искусственного интеллекта. Подход заключается в задании хорошей топологии императивных программ за счёт следующих приёмов:1.Отказ от использования глобальных данных.2.Отказ от оператора безусловного перехода.3.Разработка модулей с сильной связностью и обеспечение их независимости от других модулей. Методы и концепции:1.Метод алгоритмической декомпозиции сверху вниз. Заключается в пошаговой детализации постановки задачи, начиная с наиболее общей задачи.2.Метод модульной организации частей программы. Заключается в использовании при кодировании трёх основных управляющих конструкций (следование, ветвление, цикл). Основное отличие в языках структурного императивного программирования от классической методологии «чистого» императивного программирования заключается в отказе от оператора безусловного перехода.Класс задач для данной методологии соответствует классу задач для императивной методологии. Однако с применением данной методологии удаётся разрабатывать более сложные программы, поскольку их легко воспринимать и анализировать. Эта методология основывается на использовании явных конструкций для параллельного выполнения выбранных фрагментов программ.Методы и концепции:Метод синхронизации исполняемого кода – заключается в использовании атомических операций для осуществления взаимодействия между одновременно исполняемыми фрагментами кода. Метод поддерживается концепцией примитивов синхронизации. Синтаксис и семантика. Прямой аналог оператора в рассматриваемой методологии – процесс. Основное отличие этой методологии от императивной в том, что процессы могут исполняться параллельно. При этом выделяют следующие уровни параллелизма:параллелизм на уровне микрокоманд;параллелизм на уровне операторов;параллелизм на уровне циклов и итераций;параллелизм на уровне подпрограмм;параллелизм на уровне потоков управления;параллелизм на уровне процессов;параллелизм на уровне приложений.Суперпозиция обычно реализуется через систему процессов, обменивающихся между собой информацией о результатах вычислений.Параллельные языки программирования используют явные конструкции для параллельного исполнения выбранных фрагментов программ. Существует несколько языковых подходов к программированию для параллельных вычислительных систем:Программирование на параллельном языке программирования. Причем такие языки могут быть: универсальными (например, язык Ada);для конкретных типов компьютеров, позволяющих эффективно транслировать программы на параллельном языке именно в эту архитектуру (например, язык Occam изначально разрабатывался для транспьютеров).Программирование на широко распространенном языке программирования (например, C, C++, Pascal), который расширен языковыми (на уровне языка) распараллеливающими конструкциями.Программирование с использованием дополнительных указаний компилятору на уровне языка прагм (например, по стандарту OpenMP).Программирование на широко распространённом языке программирования с использованием высокоуровневых коммуникационных библиотек и интерфейсов для организации межпроцессорного взаимодействия. В этом случае конструкции параллелизма вынесены с языкового уровня на уровень ОС.Применение средств автоматического распараллеливания последовательных программ такими инструментами, как компиляторы. Известные языки программирования:Algol-68 (1968)Concurrent Pascal (1972)Modula-2 (1978)CSP (1978)Edison (1980)Ada (1979, 1983)Occam (1982)Concurrent Prolog (1983)Linda (1985)Oblig (1993) Класс задач. Данная методология может очень эффективно применяться для обработки больших однородных массивов данных. Такие массивы часто встречаются в реализации вычислительных и статических методов. Кроме этого, методология параллельного программирования успешно применяется при моделировании в ОС и системах реального времени. Рассмотренные ранее подходы ориентируются на описание шагов алгоритма в программе. В соответствии с рассматриваемой методологией описание шагов алгоритма невозможно.Прототип исполняемого кода формируется на основе понятий «искусственная нейронная сеть» (ИНС) и «тренировка». ИНС выступает своего рода «заготовкой», которая постепенно (в результате тренировки на знаниях, полученных от экспертов) превращается в адекватную модель с требуемым поведением. В последствии такая модель компилируется в эквивалентный исполняемый код или реализуется аппаратно.Для изначального формирования ИНС применяют два основных вида нейронов:Нейроны с линейными функциями активации.Нейроны с радиальными функциями активации. Модель нейрона базируется на использовании функций видаf(X) = x1w1 + x2w2 + … + xRwR + b,которые определяют гиперплоскости, разделяющие на части гиперпространство аргументов x1, x2, …, xR.В двумерном случае (при R = 2) нейрон можно описать как взвешенный сумматор на два входа. В данном случае прямая x1w1 + x2w2 + b разделит плоскость на две полуплоскости y0 и y1.Принадлежность некоторой точки T конкретному полупространству определяется знаком взвешенной суммы на выходе сумматора – n, который с помощью функции активации трансформируется в значение на выходе сети а (в приведенном случае – 1 или 0). Известно несколько вариантов применяемых функций активации. Наиболее популярны пороговая, линейная и сигмоидальная. Искусственные нейронные сети с применением таких нейронов обычно проектируются многослойными и могут разделять пространство аргументов одним из следующих способов. На рисунке показана радиальная базисная сеть с R входами. Функция активации для радиального базисного нейрона имеет вид: Вход функции активации определяется как модуль разности вектора весовых коэффициентов C и вектора входа X, в квадрате, разделённый на квадрат ширины зоны активации: График радиально-симметричной функции активации имеет вид: Эта функция имеет максимум, равный 1, когда вход равен 0. Когда расстояние между векторами C и Х уменьшается, выход радиальной базисной функции увеличивается.Как правило, в качестве меры используется Евклидово расстояние между векторами:Таким образом, радиальный базисный нейрон действует как индикатор, который формирует значение 1, когда выход X идентичен вектору весов C (т.е. L = min).Смещение 1/ позволяет корректировать чувствительность нейрона radbas. На основании приведенных моделей искусственных нейронов формируется искусственная нейронная сеть с организацией множественных внутренних связей. Далее она превращается в адекватную модель с требуемым поведением и реализуется программно или аппаратно. Задача программиста при этом состоит в следующем:1. Определить размерность входного и выходного векторов для моделируемого объекта.2. Сформировать (получить) совместно со специалистом из предметной области обучающую выборку. Обучающая выборка задается как набор пар вида «значение сигналов на входе объекта – соответствующее значение выходов».3. Разделить обучающую выборку на две части: для тестирования и для обучения.4. Подобрать вид искусственной нейронной сети и задать количество нейронов.5. Обучить сеть (настроить весовые коэффициенты W и b – для линейных, и C и 1/ – для радиальных нейронов) и протестировать её на адекватность поведения моделируемому объекту с помощью частей выборки, полученных в п. 3.6. При неадекватном поведении модели повторить п.п. 3ч5.7. Реализовать полученную модель. Для обучения искусственных нейронных сетей применяется ряд алгоритмов, в основном базирующихся на идее обратного распространения ошибки. Более подробно структуры, принципы формирования, алгоритмы обучения нейронных сетей и т.д. изучаются в курсе «Основы искусственного интеллекта». В программах обычно различают три типа ошибок:1. Синтаксические ошибки. Представляют собой нарушения правил языка, т.е. правил реализации конструкций языка, их последовательности, вложенности, и т.д.Синтаксические ошибки обычно возникают из-за описок (ошибок ввода текстов программ), незнания синтаксиса используемого языка программирования, нечеткого представления о структуре программы (например, забывание конечных END при многочисленных вложениях составных операторов).Большинство синтаксических ошибок фиксируется компиляторами и поэтому достаточно легко устраняется. 2. Семантические ошибки – это нарушение логики, структуры программы, неправильное использование структур данных.Семантические ошибки выявляются труднее синтаксических. Для их обнаружения обычно применяются возможности интегрированного отладчика. Значительная часть семантических ошибок может быть обнаружена при выполнении программы, особенно в режиме тестирования и при включенных режимах контроля логики программы. 3. Прагматические ошибки – это нарушение требований к структуре и назначению программы и ее функций.Прагматические ошибки могут быть выявлены и устранены только в режимах тестирования программ и ее испытаний при тщательной сверке с техническим заданием.При поиске ошибок можно руководствоваться следующими «законами программиста»:1. В любой программе всегда имеется хотя бы одна ошибка.2. Последняя из найденных ошибок никогда не является последней. Отладка – это процесс доводки программы до состояния, в котором она до конца транслируется и затем выполняется.Основная масса ошибок в программах выявляется с помощью трансляторов. Некоторая часть из них фиксируется при сбоях программы. Таким образом, задача отладки – устранить ошибки в программе, замечаемые транслятором или ОС.Тестирование – это процесс нахождения ошибок в ПП путем выполнения системы тестов. Задача тестирования - довести программу до состояния, в котором она:1. Работает без остановов2. Выдает похожие на правду результаты3. Правдоподобно реагирует на заданные ситуации.Тесты составляются для такого множества исходных данных, которое по возможности обеспечивает:1. Апробацию каждой ветви (модуля), оператора программы и каждого из возможных вариантов условий.2. Апробацию всех типов и комбинаций исходных данных, особенно их предельных значений. Все стратегии тестирования нацелены на формирование оптимального с экономической точки зрения набора тестов. При этом основное требование к тестированию – подготовка его плана до начала программирования. Соблюдение этого требования позволяет:1. Устранить опасность подгонки тестов к программе.2. Уяснить ограничения на входные данные и сформировать правильное представление о завершенной программе.3. Обеспечить непрерывность этапов создания программы: сначала определяются входные данные, затем они используются при разработке, а потом при тестировании. За подготовку тестов должны отвечать опытные и компетентные лица, знакомые с областью применения программы:- пользователи;- системные аналитики;- руководители проекта.Сами тесты необходимо планировать параллельно с планированием разработки модулей. При этом, прежде всего, определяется типовой набор тестов, в состав которого обычно входят:- тест проверки работы без учета ошибочных ситуаций;- тест, содержащий нетипичные для программы данные;- тест, содержащий неверные данные и т.д. Для и устранения ошибок применяются отладчики – программы предназначены для поиска, обнаружения и исправления ошибок в других программах. Принято различать автономные и интегрированные отладчики.Интегрированные отладчики обладают простотою доступа и единством идеологии работы с компонентами языковой среды разработки.Автономные отладчики порой могут предоставлять дополнительные, порой весьма специфические возможности. Создание исполняемого кода программы обычно выполняется в два этапа:1. Исходные тексты программы преобразуются в файлы, состоящие из двоичных данных и инструкций процессору.2. Все полученные файлы комплектуются с подпрограммами стандартных модулей и объединяются в одно целое.В среде Delphi, начиная с версии 2 оба этих этапа не отделяются друг от друга и называются единым словом «компиляция».Получаемые при этом файлы для отдельных модулей и программы проекта имеют расширение .DCU, а объединённый (исполнительный) файл расширение .EXE.При необходимости можно получать и объектный файл с расширением .OBJ. Для этого необходимо установить следующую опцию Project|Options|Linker| GenerateObject. Файлы с расширением .OBJ можно компоновать с другими проектами, даже выполненными на другом языке. При компиляции отслеживается все возможное множество синтаксических ошибок. Если они имеются, то в нижней части окна редактора выдаётся соответствующее множество строк. Каждая из них содержит:1. Указатель имени файла, в котором найдена ошибка.2. Номер строки текста с этой ошибкой.3. Краткое объяснение этой ошибки.В частности, указываются типы ошибок: простая ошибка, фатальная ошибка, предупреждение, рекомендация.При обнаружении простых и фатальных ошибок компиляция прекращается. При обнаружении рекомендаций и предупреждений компиляция не прекращается. Соответствующие сообщения выдаются только при отсутствии других типов ошибок и при установке опций Project|Options|Compile|Show hints и Project|Options| Compile|Show warning соответственно. Цели компиляции для отладки или для оптимизации программы во многом противоречивы. Поэтому для каждого варианта работы необходима своя настройка режима работы компилятора. Установки выполняются двумя способами:1. Директивами компилятора.2. Соответствующими им установками опций компиляции командами через главное меню.Директивы компилятора имеют приоритет над командами главного меню.Директивы компилятора помещаются в тексте программы в виде комментариев, за открывающей фигурной скобкой которых помещен знак доллара.Пример записи одной и той же директивы в двух видах – в полном и кратком:{$Boolean off}{$B-} Краткий вид директивы состоит из одной буквы (обычно это первая буква полного вида имени директивы). Переключающие директивы после имени директивы имеют в полной форме признаки ON или OFF для обозначения включения или выключения директивы. Для краткой формы они обозначаются знаками + или -. Переключающие директивы можно задавать в одном комментарии через запятую. Как только встречается пробел, так следующая часть рассматривается как чистый комментарий.Пример:{$А+,В-}.Глобальные директивы помещаются в начале программы. Впереди них могут располагаться только другие глобальные директивы, заголовок или комментарии. Глобальные директивы действуют на всю программу. Локальные директивы помещаются в любом месте программы. Их действие распространяется до конца файла или до следующей директивы, отменяющей данную. Рассмотрим некоторые установки, выполняемые командами главного меню среды Delphi (после них в фигурных скобках приводятся соответствующие аналоги в виде директив, а в круглых скобках – вид директивы: локальная или глобальная).После задания команды Project|Options|Compiler можно включать/выключать следующие опции компилятора, предопределяющие режим работы отладчика:Align record field {$A+/-} (локальная) - выравнивание полей записи по границам 32-разрядных слов. Это увеличивает объем используемой оперативной памяти, но увеличивает быстродействие. Debug information {$D +/-} (глобальная) - сохранение информации о связи машинных команд со строками текста программы для установки в программе местонахождения ошибок задания точек остановок, пошагового выполнения программы и др.I/O checking {$I +/-} (локальная) - проверка операций ввода/вывода в период выполнения. Если задана опция Tools|Options|Preferences|Break on exceptions, то при ошибке формируется исключительная ситуация, выводится сообщение об ошибке и работа программы прерывается. В противном случае ПП сама должна обрабатывать исключение.Local symbols {$L+/-} (глобальная) - включать информацию о локальных параметрах подпрограмм и переменных исполнительных частей модулей. Это позволяет анализировать значения таких параметров и модифицировать их при отладке. Optimization {$O +/-} (локальная) – оптимизировать программу за счёт оптимизации употребления регистров общего назначение процессора, устранение повторяющихся выражений, исключение промежуточных данных и другое. Компиляция удлиняется.Range checking {$R +/-} (локальная) - контроль допустимости значений индексов элементов массивов и строк в период выполнения. При ошибке выводится сообщение или работа программы прерывается, если установлена опция Tools|Options|Preferences|Break on exceptions.Extended Syntax {$X +/-} (глобальная) - разрешить обращение к подпрограмме-функции как к подпрограмме-процедуре (исключая стандартные функции модуля System), а также обращение к переменным типа PChar как к строкам, оканчивающимся нулем. Show hints {$Hints on/off} (локальная) - выдавать рекомендации по оптимизации программы. Часто эти рекомендации могут указывать на наличие ошибок.Show warnings {$Warnings on/off} (локальная) - выдавать предупреждения, связанные с сомнительными частями программы (использование неинициализированных переменных, создание абстрактного объекта и т.п.).Generate console application {$Aptype GUI/Console} (глобальная) - использовать обычный графический режим работы Windows или ре-жим эмуляции текстового терминала.Остальные установки могут быть изучены при использовании встроенной справочной системы среды Delphi и соответствующих литературных источников. Термин «поддержка пользователя» обозначает обеспечение потребителей программных продуктов всеми видами услуг, облегчающих работу с этими программными продуктами.Пользователи – это реальные и потенциальные потребители программных продуктов. Среди пользователей различают три основные категории:1. Конечные пользователи – это лица, получающие от приложений интересующую их информацию.2. Электронные пользователи - отдельные аппаратные решения (компьютеры, их сети, сетевые устройства и т.д.).3. Компьютерный персонал - лица создающий новые программы или информацию для программного обеспечения. Проще всего дело обстоит с классификацией программ, предназначенных для «электронного потребления» (ОС, утилиты и другие программы, обслуживающие электронные системы в части их настройки). Основные требования к таким программам можно свести к следующим немногим положениям:- минимальные расходы ресурсов;- полное соответствие функциональных возможностей возможностям электронной системы (корректность в машинном плане);- поддержка предыдущих версий электронных систем;- поддержка прогнозируемых путей развития электронных систем;- поддержка автоматической замены предыдущих версий программ на более новые, исключающая необходимость человеку принимать участие в установке параметров настройки программы;- поддержка идеологии «Plug and Play» (автоматическая настройка ПО без участия специалиста);- обеспечение возможности специалисту самостоятельно определить параметры настройки. Программу для потенциальных пользователей-программистов следует выполнять (в целях её совершенствования или адаптации) максимально просто и понятно (а также соблюдая приёмы рефакторинга). Для этого её надо тщательно спроектировать, закодировать, представить в удобной для понимания форме и снабдить документацией в необходимом объёме. Каждый модуль программы должен быть по возможности аккуратно и без излишеств самодокументирован. Кодирование модуля должно начинаться с его общего описания – так называемого «пролога». Пролог обычно включает в себя следующие элементы:1. Номер и имя модуля.2. Фамилию программиста, дату завершения работы над модулем и номер его версии.3. Функциональное описание модуля.4. Перечень основных используемых алгоритмов со ссылками.5. Словарь данных для параметров.6. Имена подпрограмм, вызывающих (использующих) модуль.7. Имена подпрограмм, вызываемых (используемых) модулем.8. Словарь данных для разделяемых областей хранения данных9. Словарь данных для внутренних (разделяемых) данных.10. Описание ввода-вывода.11. Описание исключений модуля и процесса обработки ошибок, выполняемого модулем.Пролог целесообразно включать в исходный текст модуля в виде комментария. В мнемонических конструкциях целесообразно применять венгерскую нотацию. Проектная документация обычно включает в себя следующие элементы:1. Перечень важнейших функций, реализуемых системой.2. Определения потоков данных.3. Графические описания процессов передачи данных и управления.4. Перечень носителей информации, используемых для хранения.5. Описание средств взаимодействия с вычислительной средой (включая списки уже имеющихся наборов данных и программ).6. Перечень имён наборов данных и программ, подлежащих разработке.7. Требования к синхронизации выполняемых операций с учётом доступности данных.8. Предложения по разработке системных средств защиты.9. Перечень контрольных примеров для проверки всех элементов системы с приведением ожидаемых результатов. Текст программы воспринимается лучше, если он удачно располагается на странице, выделены поля, строки не перегружены информацией использованы отступы и пробелы. Для всего этого полезны следующие приёмы оформления:1. Оставлять между основными частями программы 3 пустых строки, между не основными – 2, а после каждой последовательно выполняющейся группы операторов – 1 пустую строку.2. Использовать базовые управляющие структуры (следование, ветвление цикл).3. Соблюдать абзацный отступ в 2ч5 пробелов для тел циклов и подчинённых операторов.4. Широко применять комментарии.5. Помнить, что объявления переменных, и комментарии составляют вместе с прологом документацию программы. Начальный этап. Основа – предоставление информации о будущем продукте. При этом реклама должна быть деловой и ориентированной на конкретного потребителя, учитывающей основные положения менеджмента.Развитое применение программы. При развёрнутом выпуске и использовании программы в работу с ней подключается всё более широкий круг людей. Многие из них могут использовать опыт тех, кто начал работу с программой ранее и не испытывает существенных, принципиальных трудностей. Однако не все имеют такую возможность. Кроме того, всегда и в первую очередь надо обеспечивать работу тех, кто начинает впервые. Для таких лиц надо предусмотреть весь спектр поддержки. С точки зрения технической организации интерфейса к основным видам поддержки пользователей следует отнести следующие:- экранная помощь;- хинты;- статусные строки;- учебники;- документация к программе в комплекте. Моральное старение и утилизация. На данном этапе основная задача поддержки пользователей – переориентация на потребление новых программных продуктов. На программном уровне для платформы Win32/64 выделяют четыре вида графических интерфейсов для пользовательских программ:1. Graphics Device Interface (GDI).2. Open Graphics Library (OpenGl).3. Direct3D.4. DirectDraw. GDI представляет собой основной интерфейс операционной системы для предоставления традиционного интерфейса приложениям Windows. Этот интерфейс использует аппаратно-независимую подсистему растрового формирования изображений на поверхности экрана, которая наследуется в малоизменяемом виде от версии к версии Windows.OpenGl (открытая графическая библиотека) – спецификация, определяющая независимый от языка программирования кроссплатформенный программный интерфейс для написания приложений, использующих двумерную и трехмерную компьютерную графику. Данный интерфейс предоставляет возможность графическим приложениям работать на низком аппаратном уровне в обход драйвера видеоадаптера. Direct3D – интерфейс управления графическим акселератором на абстрактном уровне, аналогичный по идее доступа OpenGl, но оптимизированный для платформы Windows и реализованный по технологии COM (Component Object Model). Он предоставляет программисту возможность работать с высокоуровневыми объектами графической подсистемы:- формировать содержимое буфера выполнения;- выбирать и устанавливать ракурс для отрисовки трехмерных графических сцен;- управлять виртуальным источником сета;- задавать и менять текстуры графических объектов и т.д. DirectDraw является низкоуровневым и наиболее быстрым интерфейсом доступа к видеоадаптеру. Он предоставляет минимальный набор интерфейсных элементов для работы на программном уровне с графическим акселератором в обход драйвера:- первичный буфер;- вторичный буфер;- Z-буфер;- палитра. Интерфейсы OpenGl, Direct3D и DirectDraw предоставляют расширенный по сравнению с GDI набор интерфейсных функций и используются в основном для разработки мощных графических приложений.Традиционный оконный интерфейс операционных систем семейства Windows построен на основе GDI. Graphics Device Interface является базисом формирования пользовательского интерфейса для большинства разрабатыва6емых приложений. Рассмотрим более подробно его модель, используемую программистами в среде Borland Delphi. Рассматриваемый графический интерфейс базируется на применении класса TCanvas, который является свойством многих визуальных компонентов среды Delphi.Если у компонента канва (свойство типа TCanva) отсутствует, то на его поверхности рисовать нельзя. На поверхности компонентов, имеющих канву, можно печатать тексты, рисовать пером, красить кистью и отображать картинки. Канва предоставляет «холст» (контекст графического устройства GDI), инструменты для рисования (перо, кисть, шрифт), а так же набор функций по изображению рисунков и типовых геометрических фигур типа эллипса, линии и т.п. Канвой обладают такие компоненты, как форма (TForm), наследники класса TgraphicControl – метка (TLabel), панель для рисования (TPaintBox) и др.Шрифт инкапсулируется классом TFont. В нём задаются только горизонтальные шрифты (для других вариантов нужно непосредственно применять API-функции Windows). Основные свойства TFont:Style – особенности начертания шрифта: жирный (fsBold), курсив (fsItalic), подчёркнутый (fsUnderLine), перечёркнутый (fsStrikeOut). Каждый из этих вариантов совместим с другим, то есть шрифт может быть одновременно и жирным, и подчёркнутым, и т.д. Color – задаёт любой из допустимых в системе цветов в интервале TColor = - (COLOR_ENDCOLORS+1)..$2FFFFFF. Для прямого определения номера цвета по его составляющим красного, зелёного и синего компонентов используется функция RGB (R, G, B). Интенсивности R, G и B задаются числами в интервале 0..255. Пример: Color := RGB (0, 127, 255). Для 16 стандартных цветов используются константы с префиксом cl. Например константа clBlack определяет чёрный цвет.Pitch – способ установки ширины знаков шрифта: моно-ширинный (fpFixed), с переменной шириной (fpVariable), когда на знак «i» выделяется меньшая ширина, чем на знак «w», и по определённому начертанию шрифта (fpDefault).Height – высота шрифта в пикселях.Handle – дескриптор шрифта.PixelsPerInch – число точек на дюйм в контексте экрана. Изменять это свойство не рекомендуется, чтобы не искажать изображение. Size – размер шрифта в пунктах, связанный с PixelsPerInch: Size=Height*72/PixelsPerInch.По умолчанию шрифт устанавливается системным (в частности, чёрного цвета).Перо (класс TPen) задаёт свойства вычерчиваемых линий с помощью следующих свойств:Color – цвет пера (аналогично цвету шрифта).Mode – одна из 16 стандартных операций Windows для взаимодействия пера с поверхностью. Обычно задается константой с префиксом pm. Например константа pmMerge задает режим суммирования цветов пера и экрана.Style – один из 7 стандартных для Windows стилей изображения линии. Задается константой с префиксом ps. Например константа psSolid задает сплошную линию.Width – толщина пера в пикселях.Handle – дескриптор пера. По умолчанию перо имеет единичную толщину, чёрный цвет и сплошное изображение. При толщине, отличной от единицы, линия может иметь только сплошной стиль.Кисть (класс TBrush) задаёт способ закраски замкнутых фигур с помощью следующих свойств:Color – цвет кисти.Style – задаёт один из 8 стилей кисти. Определяется константой с префиксом bs. Например константа bsSolid задаёт сплошную закраску.BitMap – задаваемая программистом битовая карта для закраски поверхности определённым орнаментом. Если это свойство задано, то Color и Style игнорируются.Handle – дескриптор кисти.По умолчанию кисть имеет белый цвет при сплошной закраске. Канва (класс TCanvas) для рисования включает в себя шрифт (свойство Font), перо (свойство TPen), кисть (свойство TBrush) и дискриптор (свойство Handle). На поверхности канвы можно рисовать любым из следующих способов:1. Рисовать сложные графические изображения по отдельным точкам с помощью свойства Pixels [X, Y: Integer]: TColor. Пример нанесения красной точки в позиции (5, 5): Pixelsх[5,5] := RGB(255, 0, 0).2. Помещать готовые графические изображения, задаваемые полем Graphic.3. Проводить линии и изображать простые геометрические фигуры текущим пером. Если геометрическая фигура замкнутая, то после её рисования её внутренность закрашивается текущей кистью. Для «сбрасывания» текущих установок шрифта, пера и кисти (установки их значений по умолчанию) используется метод Refresh.При изменении канвы (то есть при любом рисовании) возбуждаются события OnChange и OnChanging (соответственно до начала изменений и по их завершению).Рассмотрим некоторые часто используемые методы для рисования и вывода текстов на поверхность канвы:BrushCopy (const Dest: TRect; BitMap: TBitMap; const Sourse: TRect; Color: TColor); - копирование прямоугольника Sourse из битового изображения BitMap в прямоугольник Dest канвы с изменением цвета Color на цвет кисти Brush.Color. Для рисования «прозрачной» картины цвет кисти фона заменяется на цвет битового изображения, являющийся в нём фоновым или наиболее частым. CopyRect (const Dest: TRect; Canvas: TCanvas; const Sourse: TRect); - копирование прямоугольника Sourse из канвы в прямоугольник Dest в области самого объекта.Drow (X, Y: Integer; Graphic: TGraphic); - отрисовка графического объекта Graphic с заданными координатами его левого верхнего угла.Polygon (const Points: array of TPoint); - отрисовка многоугольника с вершинами в указанных точках.StretchDraw (const Rect: TRect; Graphic: TGraphic); - отрисовка в прямоугольнике Rect объекта Graphic с его масштабированием к размеру прямоугольника Rect.TextOut (X, Y: Integer; const Text: String); - вывод текста Text с заданными координатами его верхнего левого угла (X,Y). Для создания стандартных диалоговых окон в приложениях Windows применяется ряд стандартных программных компонентов. В Delphi эти компоненты находятся на странице Dialogs и располагаются в библиотеке COMMDLG.dll. Выделяют 10 основных видов диалогов:OpenDialog – выбор имени файла, предназначенного для чтения.SaveDialog – выбор имени файла, предназначенного для записи.OpenPictureDialog – выбор имени файла, для чтения графического файла.SavePictureDialog – выбор имени файла, для записи графического файла.FontDialog – выбор одного из установленных в системе шрифтов.ColorDialog – выбор одного из допустимых в системе цветов.PrintDialog – выбор принтера для печати документа.PrintSetupDialog – настройка параметров вывода на принтер.FindDialog – подготовка к поиску нужного фрагмента текста.ReplaceDialog – замена найденного текста другими. Последовательность использования всех указанных диалогов одинакова и состоит из трех этапов:1. Настройка параметров диалога в свойстве Options (иногда и в других свойствах).2. Вызов функции Execute для выдачи диалогового окна. Функция возвращает значение True или False в зависимости от того, подтвердил ли пользователь выбранную настройку или нет.3. Чтение и использование заказанных значений в их свойстве (при положительном ответе). Традиционно разрабатываемое приложение формируется из отдельных файлов, модулей или классов, которые компилируются и компонуются в единое целое. После того, как приложение сгенерировано компилятором, он остается неизменным до тех пор, пока не будет скомпилирована его новая версия.Решение состоит в том, чтобы разбить монолитное приложение на отдельные части – компоненты. По мере развития технологии компоненты, составляющие приложение, могут заменяться новыми. Это позволяет делать приложения не статичными, а постепенно эволюционирующими – в результате замены старых компонентов новыми. Подобный подход также позволяет из существующих компонентов легко создавать и абсолютно новые приложения. Разработка приложений из компонентов – так называемых «приложений компонентной архитектуры» достаточно новая технология. Компонент подобен миниприложению: он поставляется пользователю как двоичный код, скомпилированный и готовый к использованию. Основополагающей технологией разбиения приложений на компоненты является технология СОМ.Component Object Model (СОМ) или модель компонентных объектов – это спецификация метода создания компонентов и построения из них приложений. СОМ была разработана в середине 80-х годов 20-го века компанией Microsoft для того, чтобы сделать программные продукты этой фирмы более гибкими, динамичными и настраиваемыми. Однако существуют и разработки других фирм, ориентированные на построение приложений с компонентной архитектурой. Среди и тех и других известны следующие: COM, DCOM, OLE, CORBA, Java, .NET и др. Основу технологии COM составляет спецификация, которая указывает, как создавать динамически взаимозаменяемые компоненты. СОМ определяет стандарт, которому должны следовать компоненты и клиенты, чтобы гарантировать возможность совместной работы.Компоненты СОМ состоят из исполняемого кода, распространяемого в виде динамически компонуемых библиотек (DLL) или EXE-файлов Win32.Для динамического подключения друг к другу компоненты СОМ используют DLL. Однако, сама по себе динамическая компоновка не обеспечивает компонентной архитектуры: компоненты должны быть инкапсулированы. Обеспечение инкапсуляции в компонентах COM достигается за счет соблюдения ряда следующих технологических ограничений:1.Компоненты полностью независимы от языка программирования (т.е. могут быть разработаны с помощью практически любого процедурного языка).2.Компоненты могут распространяться в информационной среде в дво-ичной форме.3.Компоненты можно модернизировать, не нарушая работы старых клиентов (СОМ предоставляет стандартный способ реализации разных версий компонента).4.Компоненты СОМ можно прозрачно перемещать по сети (компонент на удаленной системе рассматривается так же, как компонент на локальном диске компьютера). ОС Windows выстроена на основе технологии COM. COM-объекты выполняют разные функции, создаются и уничтожаются системой автоматически (по мере возникновения запросов от пользователей). Достаточно только описать интерфейс COM-объекта и запрограммировать его реализацию, все остальное выполняет компилятор и Windows.При разработке приложений COM пользуются следующими составные части технологии:Интерфейс COM – описывает методы и свойства, доступные программам, обращающимся к объекту.Сервер COM – законченный модуль кода (EXE или DLL), в котором хранится программный код одного или нескольких объектов COM.Клиент COM – программный код, в котором происходит обращение к интерфейсу с запросом на выполнение услуг сервера COM. Интерфейсы составляют основу данной технологии. Для клиента компонент представляет собой набор интерфейсов, которые являются единственным каналом взаимодействия клиента с компонентом СОМ.Интерфейс COM позволяет клиентам COM общаться с сервером на основе стандартного механизма публикации интерфейса. После того, как интерфейс COM опубликован (стандартным способом зарегистрирован системой), изменять его нельзя, что гарантирует одинаковую работу объекта COM в любых условиях. Уникальность интерфейса обеспечивается его глобальным идентификатором – Globally Unique IDentifier (GUID) длиной 16 байтов. Каждый объект COM имеет идентификатор интерфейса – Interface IDentifier (IID) на основе GUID. GUID требуется для избежания проблем при появлении интерфейсов COM с одинаковыми именами.Благодаря наличию стандартных интерфейсов объект COM может быть реализован на любом языке программирования. Интерфейс IUnknown содержит метод QueryInterface, возвращающий ссылку на другие доступные интерфейсы, а также методы AddRef и Release, которые увеличивают и уменьшают счетчик ссылок на конкретный интерфейс. Счетчик увеличивается при обращении к интерфейсу и уменьшается при освобождении интерфейса. Как только значение счетчика равно нулю, т.е. к интерфейсу больше нет обращений, соответствующий объект COM может быть удален из памяти до следующего запроса к его интерфейсу.На основе технологии COM был создан ряд расширений: серверы автоматизации (OLE), активные серверные страницы (.ASP), встраиваемые серверы ActiveX с визуальной настройкой и др. При обращении к серверу клиент COM передает ему идентификатор класса. Идентификатор класса (CLSID) – это GUID, который ссылается на подходящий объект COM.Сервер COM создает специальный объект – фабрику классов (IClassFactory), который занимается непосредственно созданием и загрузкой (производством) экземпляра нужного объекта COM, выполняющего конкретные действия его интерфейса, указанные в запросе клиента COM. Сервер COM может быть реализован тремя способами:1. В виде библиотеки .DLL. При этом объект COM выполняется в адресном пространстве обратившегося к нему приложения.2. В виде приложения .EXE, которое выполняется в собственном адресном пространстве, но на одной машине с клиентом COM.3. В виде библиотеки .DLL или приложения .EXE, которые загружаются и работают на иной машине, нежели клиент COM (технология DCOM). Подход, при котором разделение компонентов происходит на уровне самостоятельных приложений, получил название Object Linking and Embedding (OLE). OLE – это огромная и сложная технология, которая оказывает определяющее влияние на отдельные стили программирования.В общем случае технология OLE предназначена для объединения инструментальных возможностей разных приложений независимо от их форматов данных, операционной среды, языка программирования и разработчика. Она поддерживает внедрение копии одного компонента в «контейнер» (в другой компонент), включение в компонент ссылки на другой компонент (связывание компонентов) и сохранение составных объектов (документов). Однако связыванием и внедрением OLE занималась только при рождении своего названия. В настоящее время OLE разрослась и включает целую группу технологий: связывание, внедрение, перетаскивание (drag-and-drop), буфер обмена (clipboard), структурированную память, автоматизацию и др.Все они базируются на программной технологии COM, которая в свою очередь, выстроена на основе концепции объектно-ориентированного системного обеспечения – Object Oriented System Software (OOSS). Объект в технологии OLE – это информационный элемент, объединяемый методами OLE с другими данными. Такой объект – это не то же, что объект в ООП. Поэтому точнее его можно называть как OLE-объект. OLE-объектом может быть целый документ (файл), отдельный его фрагмент или даже отдельный символ.Составной документ (compound document, документ OLE) – это документ, содержащий данные, созданные в разных приложениях, оснащенных OLE. Такой документ называется контейнером.Клиент – это приложение, в котором создается составной документ. Для уточнения его можно называть «OLE-клиент». Сервер (источник) – это приложение, из которого берется объект для составного документа. Для уточнения можно использовать название «OLE-сервер».OLE-серверы и OLE-клиенты взаимодействуют с системными библиотеками (OLESVR.DLL и OLECLI.DLL соответственно) при помощи виртуальных функциональных таблиц (Virtual function Tables – VTBL). Эти таблицы представляют собой наборы указателей функций для организации взаимодействия с сервером или клиентом.Включение объекта в составной документ бывает двух видов: связь и внедрение. Они отличаются способом, местом хранения и использования данных объекта.Внедрение – это такой вид формирования составного документа, когда в него входит сам объект. Размеры составного документа увеличиваются на сумму размеров внедренных объектов. Составной документ можно переносить с компьютера на компьютер, не заботясь об источнике, из которого взяты объекты. Связь – включение в составной документ не объекта, а только ссылка на него. Сами данные продолжают находиться в сервере. Связывание мало увеличивает размер составного документа.Настраиваемые связи (adaptable links) – это связи при использовании которых объекты могут перемещаться вместе с составным документом.Односторонняя связь (one-way link) регламентирует автоматическое обновление данных в клиенте при их изменении в сервере.Двусторонняя связь (two-way link) – это связь при которой один сервер «делится» изменениями данных с сервером. Если, к примеру, данные в текстовом редакторе связаны с электронной таблицей, где на основании этих данных построена таблица, то при изменении исходных данных в текстовом редакторе они обновляются в электронной таблице. Редактирование «по месту» (in-place activation) – это переход к работе в «родном приложении» приложении путем выполнения двойного щелчка на объекте в текущем приложении. Другими словами, если, к примеру, в документе текстового процессора внедрена часть электронной таблицы, то при двойном щелчке на ней меню текстового процессора заменяется на меню электронной таблицы. Закрытие этого окна автоматически возвращает пользователя в текстовый редактор.Технология OLE использует архитектуру «толстого клиента», то есть предполагает использование сетевого компьютера с избыточными вычислительными ресурсами. Это означает, что тип файла либо программа, которую пытаются внедрить, должна присутствовать на машине пользователя. Например, если OLE оперирует электронными таблицами Excel, то программа Excel должна быть инсталлирована на используемом компьютере. Автоматизация OLE – это протокол, посредством которого одно приложение может получить доступ к объекту, размещённому внутри, другого приложения или DLL. Доступ к этому объекту предоставляет воз-можность:-управлять действиями приложения или DLL;-получить доступ к свойствам приложения или DLL.Приложение, которое может быть автоматизировано, называется серве-ром автоматизации. Приложение, которое автоматизирует другое приложение, называется клиентом автоматизации. При этом приложение может быть одновременно как сервером, так и клиентом. Автоматизация – это идеология доступа к объектам приложения и манипуляция с ними извне. Автоматные объекты доступны только программно, т.е. программа-клиент даёт команды программе серверу, и та выполняет эти команды, предоставляя программе-клиенту результат. Команды могут писаться на любых языках или макроязыках. Автоматные объекты не видны конечному пользователю и используются обычно для автоматизации часто повторяемых задач.Автоматные объекты не могут связываться или внедряться в ПП. Они временны, существуют только во время выполнения ПП и доступны только с помощью заранее запрограммированного дистанционного управления. Автоматизация требует три вида информации:1. Класс OLE-объекта (например, Word, Matlab и т.д.)2. Документ OLE – файл с данными объекта.3. Элемент OLE – часть документа, подлежащая связыванию или внедрению.Существует два основных типа автоматизации:- серверы автоматизации;- клиенты автоматизации.Сервер автоматизации – это приложение или DLL, которое владеет объектом. Клиент автоматизации –приложение или DLL, которое получает доступ к объекту. Одно приложение или DLL может выступать и в качестве сервера, и в качестве клиента. При этом автоматизация определяет два вида серверов автоматизации OLE:- серверы внутренней обработки;- локальные серверы. Серверы внутренней обработки – это DLL, которые загружаются в адресное пространство прикладной программы. Причина для создания серверов внутренней обработки – совместное использование объекта, написанного на одном языке, и приложения, написанного на другом языке. Можно, к примеру, совместно использовать объекты Delphi, приложения С++ и Visual Basic.Локальные серверы – это автономные исполняемые модули, которые содержат серверы автоматизации. Классический пример локального сервера – Word.При отсутствии необходимости пересекать языковые барьеры DLL в использовании быстрее и проще. Структурированная память (structured storage) – это специальная техника для записи объектов или данных на диск. Данная техника обеспечивает все услуги, которые пользователи привыкли видеть в стандартном файловом вводе/выводе. Различие между структурированной памятью и стандартным файловым вводом/выводом заключается в том, что каждый набор каталогов и файлов в структурированной памяти размещается внутри единого большого файла. Файл структурированной памяти называется составным файлом. «Каталоги» внутри этих составных файлов называются потоками. В составном файле могут храниться и другие типы объектов. В действительности все DOC-файлы в Microsoft Word являются файлами структурированной памяти.Структурированная память является частью OLE, отвечающей за сохранение составных файлов (объектов, документов).В заключение следует отметить, что программный интерфейс для работы со структурированной памятью поддерживается во многих средах разработки ПО. Составные файлы создаются при помощи двух обращений: StgCreateDocFile и Storage.CreateStream. Открываются составные файлы при помощи вызовов StgOpenStrearn и Stomge.OpenStream. Наиболее важным интерфейсом в OLE является интерфейс IDispatch. CORBA – это аббревиатура от Common Object Request Broker Architecture (стандартная архитектура брокера объектных запросов), обозначающая открытую, независимую от поставщика архитектуру и инфраструктуру, позволяющую использовать различные приложения для совместной работы в сетях.Стандарт CORBA (как и стандарт UML) разработан группой Object Management Guide (OMG) – сообществом ведущих фирм производителей программного обеспечения таких, как Digital Equipment Corporation, Hewlett-Packard Company, HyperDesc Corporation и др. Архитектура CORBA основана на трех ключевых блоках:1. OMG Interface Definition Language (IDL) – язык описания интерфейсов.2. Object Request Broker (ORB) – брокер объектных запросов.3. Internet Inter-ORB Protocol (IIOP) – стандартный протокол обмена данными для CORBA, реализованный на базе TCP/IP.CORBA-приложения состоят из объектов, отдельных модулей программного обеспечения, объединяющих функциональность и данные.Описание интерфейса можно отобразить в описание на одном из популярных языков программирования. В настоящее время разработаны стандарты отображения для C, C++, Java, COBOL, Smalltalk, Ada, Lisp, Python, IDLscript. Реализация объекта (его исполняемый код и данные) инкапсулируется за границей описанного интерфейса.Технология работы CORBA-приложения заключается в следующем.1. Формируется «заглушка» (Stub), которая представляет собой откомпилированное IDL-описание интерфейса клиентской части.2. Формируется «скелет» (Skeleton) - откомпилированное IDL-описание интерфейса серверного объекта.3. Выполняется реализация серверного объекта (Object Implementation) и клиентской части к нему (Client).4. Для каждого экземпляра CORBA-объекта формируется своя уникальная объектная ссылка.5. Клиент, применяя объектную ссылку, передает ORB данные о том, какой именно экземпляр объекта должен быть задействован. При этом клиент действует так, как будто оперирует напрямую с экземпляром объекта, однако в действительности происходит обращение к методам заглушки, которая затем и передает через ORB запрос на выполнение и код скелета серверного объекта. Для описываемой схемы взаимодействия частей приложения характерны следующие черты:1. Клиент с самого начала знает о типе исполняемого объекта, поскольку как клиентская заглушка, так и скелет серверного объекта, генерируются из одного и того же IDL-описания.2. ORB клиента и ORB серверного объекта базируются на общем протоколе IIOP. Технология Java – это распределенная объектно-ориентированная платформа для разработки приложений, предназначенных для работы в среде Web. По замыслу создателей этой технологии отводилась роль сетевого эсперанто:- базовый язык данной технологии – Java максимально независим от используемой платформы;- Java разрабатывался с ориентацией на сетевые применения.Разработка на языке Java имеет ряд особенностей, особое место среди которых занимают семантические компромиссы: императивная минимальность заимствована из языка Pascal, а существующая поддержка многопоточных вычислений указывает на преемственность с языком C++. С одной стороны – основной принцип разработки программ по технологии Java – это безопасность, которая обеспечивается следующими характеристиками:- современный язык программирования;- синтаксис по типу языка C++, без указателей;- виртуальная машина и независимость от платформы;- поддержка библиотек потоков и сетевой среды;- поддержка аплетов (клиентских приложений);- расширенные прикладные интерфейсы типа 3D, MEDIA, Beans, Swing.С другой стороны разработка систем на основе технологии Java – это создание несложных аплетов и мощных серверов. При этом вследствие низкой эффективности выполнения программ на языке Java (обратная сторона подхода с использованием виртуальной машины) и длительной загрузки аплетов по сети, язык Java представляется слишком слабым средством для программирования серверов и избыточно сильным – для не отличающихся особой сложностью клиентов.В целом компонентная технология на основе языка Java представляет собой противоречивую, но перспективную платформу, для которой существует множество прикладных программных интерфейсов для разработки программ в прикладных областях. .NET (произносится «дот-нет») — программная технология, предложенная фирмой Microsoft в качестве платформы для создания, как обычных программ, так и Web-приложений. Во многом является развитием идей и принципов, заложенных в технологии Java.Одной из основных идей .NET является совместимость различных служб, написанных на разных языках. Каждая библиотека (сборка) в .NET имеет сведения о своей версии, что позволяет устранить возможные конфликты между разными версиями сборок. В настоящее время существует реализация .NET для платформы Microsoft Windows, FreeBSD (от Microsoft) и ограниченный вариант технологии для ОС Linux в рамках свободных проектов Mono, DotGNU.Рассматриваемая технология является патентованной технологией фирмы Microsoft, что является препятствием для её распространения на другие платформы. Однако компиляторы для .NET выпускаются множеством фирм для различных языков свободно. Множество используемых языков является несомненным преимуществом технологии .NET по сравнению с Java.Технология приложение .NET подразделяется на две основные части:- среда выполнения (по сути виртуальная машина);- инструментарий разработки.Среды разработки .NET-приложений: Visual Studio .NET (C++, C#, J#), SharpDevelop, Eclipse, Borland Developer Studio (Delphi, C#) и т. д. Приложения можно разрабатывать в текстовом редакторе и использовать традиционный консольный компилятор. Технология описания аппаратуры – это метод однозначного описания межэлементных соединений и работы электрической и электронной частей аппаратных средств вычислительной техники.Технология опирается на применение Hardware Description Language (HDL) – языков описания аппаратуры. Написание HDL-кода вместо использования схемотехнических компонентов (например, логических вентилей) является в настоящее время основным направлением в области проектирования цифровых систем. Сегодня широкое распространение в рамках представленной технологии получили такие высокоуровневые языки как VHDL, Verilog, Schematik и некоторые другие. Среди перечисленных языков описания аппаратуры наиболее универсальным является VHDL.Общая технология использования языков HDL предполагает, что:- проектируемое устройство иерархически разбивается на составные части (компоненты);- каждый компонент имеет четко очерченный интерфейс (для его соединения с другими компонентами) и точное функциональное описание для моделирования его поведения;- функциональное описание может быть основано либо на структуре, либо на алгоритме, которыми определяется функционирование данного компонента.Описание компонента состоит из двух частей:- описания интерфейса («сущность»), которое описывает взаимосвязи между компонентом и средой его «обитания» (функционирования);- архитектуры (архитектурное тело), описывающей поведение компонента с функциональной или структурной точки зрения относительно входов и выходов. Возможные варианты реализации модели сдвигового регистра по данной схеме на языках Schematik, VHDL и Verilog представлены ниже на рисунках (а), (б) и (в) соответственно. а) описание сдвигового регистра на языке VHDL library ieee;use ieee.std_logic_1164.all; entity na_vhdl isport (CLOCK, D: in STD_LOGIC;Q: out STD_LOGIC_VECTOR(3 downto 0)); end na_vhdl; architecture na_vhdl_arch of na_vhdl is signal IQ: STD_LOGIC_VECTOR(3 downto 0);begin process(CLOCK, D, IQ) begin if (CLOCK'event and CLOCK='1') thenIQ <= D & IQ(3 downto 1); end if; Q <= IQ; end process;end na_vhdl_arch; б) описание сдвигового регистра на языке Verilog module Verilog (en, clock, reset, out);parameter Width = 8;input clock, reset, en;output [Width-1:0] out;reg [Width-1:0] out;always @(posedge clock or negedge reset)if(!reset)out = 8'b0;else if(en)out =out +1;endmodule в) описание сдвигового регистра на языке Verilog Высокоуровневые языки описания аппаратуры позволяют при описании электронных компонентов задавать уровень абстракций (сокрытия деталей) – от функционального до полностью вентильного описания.С помощью технологии описания аппаратуры возможно на программном уровне разрабатывать и синтезировать аппаратные проекты в широком диапазоне (от простых комбинационных схем до микропроцессорных систем).Использование программного обеспечения для синтеза позволяет проектировщику устраниться от непосредственного участия в процессах трансляции и минимизации HDL-кода, а также от проверки соответствия временным ограничениям. Существуют несколько различных видов синтеза:1. Логический синтез: трансляция (и минимизация) булевых функций в вентильную схему.2. RTL-синтез: трансляция в схему, содержащую не только вентили, но и триггеры и представляющую собой цифровой автомат.3. Синтез на поведенческом уровне: может использовать один и тот же схемный компонент для более чем одной последовательной конструкции языка.Обобщая, можно отметить, что процесс синтеза можно сравнить с компиляцией: HDL-код транслируется в принципиальную схему.Среди систем автоматизированного проектирования и моделирования на основе языков описания аппаратуры известны следующие: Foundation Series (фирмы Xilinx, Aldec, Synopsys), Model Sim (фирмa Model Technology), StateCad (фирмa Visual Software Solutions), MAX+Plus II (фирмa Altera), IDS (фирмa Atmel), VHDL Simili (фирмa Symphony EDA) и другие. Все множество разработок в зависимости от количества участников и типов взаимоотношений между ними может быть сведено к триаде разработок: Авторская разработка – принцип создания программных продуктов, при котором весь жизненный цикл разработки поддерживается единственным разработчиком.Авторская разработка предполагает достижение профессионального успеха, известности и славы в одиночку.Примеры известных авторских разработок: текстовый редактор Лексикон (Е. М. Веселов), трансляторы с языков Algol-68 (П. Наур), и Pascal (H. Вирт) и др.Принцип авторской разработки неприменим для многих современных разработок из-за их сложности, объема и требований к качеству и сопровождению. Считается, что авторская разработка может выигрывать по производительности в несколько раз у коллективной за счет следующих характеристик:- исключения межличностных коммуникаций, связанных с необходимостью порождения и изучения большого количества технологической документации;- исключения работ по разбиению проекта на составляющие, по распределению их между исполнителями, по координации деятельности исполнителей и контролю за их работой.Однако объем программного продукта, выполненного методом авторской разработки обычно в 5ч20 раз меньше по сравнению с индустриальными аналогами.Наибольшую популярность современная авторская разработка получила при создании условно-бесплатных программных продуктов (shareware). Одним из основных вопросов коллективной разработки является разделение труда – от равноправных соисполнителей до организации в виде жесткой иерархии (например, бригады главного программиста). Бригада равноправных соисполнителей обычно состоит из специалистов, занимающихся примерно подобными задачами в рамках одного проекта. В рамках одной бригады может быть несколько специализаций. Тип работы определяет содержание и природу выполняемой работы:Разработка приложений:- программист;- специалист по инженерии программирования;- специалист по инженерии знаний.Работа с приложениями:- специалист по приложениям;- администратор данных;- администратор базы данных.Техническая поддержка:- системный администратор;- сетевой администратор;- администратор коммуникаций.Обеспечение качества продукта:- технический писатель;- инженер тестирования;- инженер качества. Маркетинг:- специалист по сопровождению продукта;- специалист по продажам продукта.Отдельное место занимает специализация системного интегратора. Основные задачи системного интегратора – предложить заказчику вариант решения его проблемы, выбрав наиболее приемлемый по цене и технике, и реализовать его. Таким образом, системный интегратор продает решения и несет ответственность за их реализацию. Системный интегратор как профессионал должен обладать знаниями из очень многих областей – прикладное и системное программное обеспечение, администрирование систем, аппаратура, сети, экономика и т. п.Бригады главного программиста подобны хирургическим бригадам. Один участник команды занимается основной работой – остальные оказывают ему всевозможную поддержку.В состав бригады входят следующие специалисты. Главный программист. Лично выполняет анализ и проектирование, создание и отладку кода, написание документации. Должен обладать талантом, большим опытом работы и существенными знаниями.Дублер. Может выполнять любую работу главного программиста, но менее опытен. Подстраховывает главного программиста, может заниматься написанием кода, но не несет ответственности за проект.Администратор (он же – менеджер). Под его контролем – деньги, люди, помещения, машинные ресурсы, контакты с другими группами и руководством.Редактор. Фактически, это технический писатель. Его задача – критически переработать черновики документации (созданные главным программистом), снабдить их ссылками и обеспечить публикацию или помещение в Интернете. Языковед. Эксперт в тонкостях языков программирования. Может найти эффективные способы использования языка для решения сложных задач. Обычно работает с несколькими бригадами.Инструментальщик. Разработчик специализированных инструментов – утилит и скриптов. Поддерживает основной инструментарий и оказывает по нему консультации. При необходимости может осуществлять администрирование ОС.Отладчик. Разработчик тестов и организатор тестирования продукта.Делопроизводитель. Отвечает за регистрацию всех технических данных бригады в библиотеке программного продукта. Благодаря делопроизводителю, активные программисты освобождаются от рутинных работ. В настоящее время функции делопроизводителя автоматизированы и переданы репозиторию проекта. Принято выделять восемь ключевых ролей в проекте.Председатель. Выбирает путь, по которому команда движется вперед к общим целям. Умеет обнаружить сильные и слабые стороны команды и обеспечить наибольшее применение потенциала каждого ее участника. Архитектор. Он же оформитель. Придает законченную форму действиям команды. Имеет четкое представление о проблемах и их возможных решениях.Генератор идей. Предлагает радикально новые идеи и стратегии, новые подходы к решению проблем, с которыми сталкивается группа. Особое внимание уделяет главным проблемам. Критик. Он же скептик, оценивающий проблемы с прагматической точки зрения. Ищет недостатки, изъяны и недоделки. Компенсирует оптимизм генератора идей.Исполнитель. Работник, собственно занимающийся написанием кода. Как правило, он не обладает широтой кругозора. Завершающий. Поддерживает в команде настойчивость в достижении цели. Играет доминирующую роль на завершающих стадиях разработки. Дипломат. Поддерживает силу духа в участниках проекта. Оказывает им помощь в трудных положениях. Пытается улучшить взаимоотношения в команде.Организатор. Обнаруживает и сообщает о новых идеях, разработках и ресурсах. Имеет много друзей и связей в своей организации, с помощью которых можно выпросить или одолжить необходимые ресурсы. В реальных командах программистов могут быть выделены не все из этих ролей. Роль исполнителя часто берут на себя сразу несколько членов команды. Коллективная разработка предполагает большое количество различных действий, причем степень совместной деятельности может существенно изменяться от одного действия к другому. Можно выделить следующие четыре типа совместной деятельности.Мандатная деятельность, обычно представленная формальными собраниями, проводимыми на регулярной основе. Обычно собрания планируются заранее, а присутствие на них обязательно. Статистика показывает, что программисты проводят около 4% своего рабочего времени на собраниях. Созываемая деятельность, которая имеет место в случае решения двух или более программистов собраться вместе для решения некоторого технического вопроса. Такие собрания обычно не планируются заранее и в них участвуют только действительно заинтересованные в решении проблемы программисты. На эту деятельность уходит около 14% рабочего времени.Естественная совместная деятельность имеет место, когда как минимум двое программистов работают над одной и той же задачей одновременно и обмениваются информацией о выполняемой работе. Эта деятельность занимает около 41% рабочего времени.Индивидуальная деятельность имеет место, когда программист работает над задачей, которая не выполняется в то же самое время никаким другим программистом и поэтому маловероятно его взаимодействие по этому предмету с любыми другими программистами группы. Эта деятельность занимает также около 41% рабочего времени. Общинная модель характеризуется тремя следующими основными факторами.Децентролизованность разработки. Не существует ограничения сверху на количество людей, принимающих участие в проекте. Как правило, разработки такого типа ведутся на базе сети Интернет и могут включать любого заинтересованного разработчика Сети. Разработка ведется на базе открытых исходных текстов. По ним можно разобраться с сутью задачи и в любой момент подключиться к разработке.Большое количество внешних тестеров (бета-тестеров), позволяющих быстро обнаруживать ошибки и проблемы в программе. Классификация различных подходов к качеству ПО обычно проводится с использованием двух измерений.Первое измерение ориентировано либо на продукт, либо на процесс. Для повышения качества программного обеспечения можно сосредоточиться на качестве самого продукта, например, делая его более дружественным пользователю. Альтернативный подход заключается в совершенствовании процесса разработки, предполагая при этом, что чем лучше процесс, тем лучше качество программного обеспечения.Второе измерение связано либо с соответствием, либо с усовершенствованием. Под соответствием будем понимать соответствие какому-либо стандарту. Усовершенствование имеет своей целью переход на более совершенные методы и лучшую практику для повышения качества. Рассмотрим все четыре подхода к качеству ПО.Документ ISO 9126 является стандартом на качество продукта, определяющим атрибуты и характеристики качества, включая измерения количественной оценки этих характеристик.Под «усовершенствованием практики» понимается усовершенствование управления конфигурацией программного обеспечения, инспекций, тестирования и т. п.ISO 9000 – это совокупность стандартов, декларирующих требования для качественных систем. С точки зрения разработки ПО наиболее полезны «Руководящие указания по применению ISO 9001 при разработке, поставке и обслуживании программного обеспечения». Объект качества Соответствие Усовершенствование Продукт ISO 9126 «Усовершенствованиепрактики» Процесс ISO 9000, процессобеспечения качества CMM, SPICE, ... Методы усовершенствования процесса разработки ПО предлагают некоторую шкалу уровней и требования соответствия, согласно которым можно определить место компьютерной компании на этой шкале. Наиболее известны и популярны следующие два метода:- модель зрелости процесса разработки программного обеспечения – Capability Maturity Model for Software (CMM), предложенная организацией Software Engineering Institute (SEI);- определение возможностей и улучшение процесса создания программного обеспечения; этот метод определен ISO/IEC 15504 Software Process Improvement and Capability determination (SPICE). Классическое определение качества заключается в том, что разработанный программный продукт подтверждает свою спецификацию – при этом спе-цификация должна быть ориентирована на характеристики, которые жела-ет получить клиент.В соответствии с таким определением общепринятые критерии качества ПО определить весьма затруднительно.Однако современные стандарты уточняют понятие качества, вводя совокупность черт и характеристик, которые влияют на его способность удовлетворять заданные потребности пользователей. Рассмотрим некоторые из них. Функциональность (пригодность, точность, интероперабельность, согласованность, безопасность). Функциональность – это способность программного продукта выполнять набор функций, удовлетворяющих заданным или подразумеваемым потребностям пользователей. Набор таких функций определяется во внешнем описании программного продукта.Удобство (понимаемость, эффективность освоения, эргономичность). Удобство – это характеристики программного продукта, которые позволяют минимизировать усилия пользователя по подготовке исходных данных, применению программного продукта и оценке полученных результатов, а также вызывать положительные эмоции определенного или подразумеваемого пользователя. Эффективность (по времени и по ресурсам). Эффективность – это отношение уровня услуг, предоставляемых программным продуктом пользователю при заданных условиях, к объему используемых ресурсов. Сопровождаемостъ (простота анализа, изменяемость, стабильность, проверяемость). Сопровождаемость – это характеристики программного продукта, позволяющие минимизировать усилия по внесению изменений для устранения в нем ошибок и по его модификации в соответствии с изменяющимися потребностями пользователей.Переносимость (адаптируемость, гибкость инсталляции, согласованность со стандартами и правилами, заменяемость). Переносимость – это способность программного продукта быть перенесенным из одной среды выполнения в другую, в частности, с одной аппаратной архитектуры на другую.Следующие две характеристики заслуживают особого внимания. Рассмотрим их подробнее.Надежность – это способность программы безотказно выполнять определенные функции при заданных условиях в течение заданного периода времени с достаточно большой вероятностью. Надежный программный продукт не исключает наличия в нем ошибок. Здесь важно, чтобы ошибки при практическом применении в заданных условиях проявлялись достаточно редко. Степень надежности характеризуется вероятностью работы программного продукта без отказа в течение определенного периода времени. Для обеспечения надежности существуют следующие подходы:- предупреждение ошибок;-самообнаружение ошибок;- самоисправление ошибок;- обеспечение устойчивости к ошибкам.Добротность программы заключается в том, что программа разумно и рационально организована, с достаточно продуманной организацией потоков управления и информационных потоков, не слишком переусложнена. Принято выделять четыре класса критериев добротности программ.Количественные критерии – связаны с различными способами оценки (метриками) сложности программ.Генетические критерии, связанные с происхождением программы и дисциплиной ее создания.Структурные критерии, связанные с оценкой организации управления в программе и отражением организации управления в программном тексте.Прагматические критерии, связанные с оценкой того, насколько про-граммный текст соответствует цели программы. Формулируется список из-лишеств, которых не должно быть в добротных программах, например – вычислительной избыточности. Как было отмечено выше, существует два подхода, которые могут применяться для оценки качества программного продукта:1. Оценка качества конечного продукта.2. Оценка качество процесса разработки.Оценить качество конечного продукта можно тестированием и эксплуатацией. На это должно быть отведено время после завершения основной работы над программой. А вот второй подход должен стать частью долговременной стратегии компании. В этой модели определено пять уровней зрелости для организации – разработчика ПО:Начальный уровень. На этом уровне процесс разработки характеризуется практическим отсутствием процессов управления. Успех проекта зависит от индивидуальных усилий, личных качеств и даже героизма участников проекта. 찂৚(찀ঢ찂ȠēxǯЂ⧀ߵЃ攰‚늘ѓ攰„늘…‡€їƿǿ́ဆ̿쎀οОбъект 2¤ᄐ რ௃￿￿ Повторяемый уровень. На этом уровне в компании должны быть внедрены основные процессы управления для отслеживания стоимости, графика проекта и его функциональности. Уровень характеризуется тем, что управление проектами основывается на накопленном опыте и достигнутые успехи будут повторены на подобных приложениях.Определенный уровень. Процесс разработки программного обеспечения (как на уровне управленческой, так и инженерной деятельности) документирован, стандартизован и интегрирован на уровне всей организации. Процесс перестает зависеть от индивидуальных качеств отдельных разработчиков и не может скатиться на более низкие уровни в кризисных ситуациях.Управляемый уровень. В компании устанавливаются детальные количественные показатели на процесс разработки и качество продукта. И процесс разработки, и продукты – понимаемы и контролируемы.Оптимизирующий уровень. Продолжающееся совершенствование процесса разработки на основе анализа текущих результатов процесса и применения инновационных идей и технологий. Данная модель очень близка к модели зрелости, но уровни возможностей могут быть применены не только к организации в целом, но и к отдельно взятым процессам. Модели такого типа часто называют непрерывными. В непрерывных моделях один процесс может находиться на низком уровне зрелости, а другой – на высоком уровне. Стандарт определяет шесть уровней зрелости процесса:Уровень 0. Процесс не выполняется.Уровень 1. Выполняемый процесс.Уровень 2. Управляемый процесс.Уровень 3. Установленный процесс.Уровень 4. Предсказуемый процесс.Уровень 5. Оптимизирующий процесс.Во время оценки и улучшения качества процессов выполняются следующие задачи. Сравнение процесса разработки программного обеспечения, существующего в данной организации, с описанной в стандарте моделью. Анализ результатов дает возможность определить сильные и слабые стороны процесса, его внутренние риски.Оценка возможности улучшения данного процесса на основе определения текущих возможностей.Техническая реализация поставленных задач на основе сформулированных целей совершенствования процесса. После этого весь цикл работ начинается сначала. Понятие «достаточно хорошее» ПО обычно применяет к «безнадежным проектам», которые связаны жесткими ограничениями на время, бюджет и людские ресурсы.В большинстве безнадежных проектов заказчик может быть удовлетворен системой, которая достаточно дешева, достаточно производительна, обладает необходимыми возможностями, достаточно устойчива и будет готова достаточно скоро. Фактически, эти характеристики можно считать определением «достаточно хорошего» программного обеспечения.Зачастую качество стремятся определить только в терминах ошибок. Однако с точки зрения пользователя не менее важна готовность ПО к определенной дате. Предполагается, что малое количество ошибок равносильно лучшему качеству, и пользователь предпочитает именно такое качество. Однако иногда пользователь готов идти на компромиссы и примириться с некоторыми ошибками в обмен на более скорое выполнение работы.Считается, что для создания «достаточно хорошего» ПО необходимо учитывать следующие условия:Утилитарная стратегия – искусство количественного анализа и максимизации чистого выигрыша в неопределенных ситуациях.Эволюционная стратегия – рассматриваемая не только по отношению к жизненному циклу проекта, но также к людям, процессам и ресурсам.Героические команды – не могучие гениальные программисты, а обычные умелые специалисты, способные к эффективному сотрудничеству.Динамическая инфраструктура – противоположность бюрократии и засилию политики.Динамические процессы – процессы, поддерживающие работу в эволюционной среде. Стандарт – общепринятое определение компонента технических или программных средств, являющихся результатом соглашения.Профиль – набор юридических и/или фактических стандартов, ориентированных на выполнение конкретной задачи.Стандарты можно классифицировать следующим образом:по типу установления требований:- устанавливающие требования к объекту;- устанавливающие требования к процессу;по масштабу:-международные;-государственные;- отраслевые;- предприятий;по степени юридического оформления:- принятые юридически;- действующие фактически. Процесс стандартизации информационных технологий поддерживают три основные группы организаций:1. Международные организации, входящие в структуру ООН.International Organization for Standardization (ISO) - международная организация по стандартизации.International Telecommunication Union-Telecommu-nications (ITU-T) – международный союз по телекоммуникации - телекоммуникация.2. Промышленные профессиональные или административные организации.Institute of Electrical and Electronic Engineers (IEEE) – институт инженеров по электротехнике и электронике.Internet Activity Board (IAB) – совет управления деятельностью Интернета.3. Промышленные консорциумы.Object Management Group (OMG) - группа управления объектами.Х/Open - консорциум, организованный группой поставщиков компьютерной техники.Open Software Foundation (OSF) – фонд открытого программного обеспечения. Инструментальная система – логически связная совокупность программных инструментов, поддерживающая разработку и сопровождение программных продуктов на конкретном языке программирования либо ориентированная на конкретную предметную область. Для инструментальных систем характерны два основных признака:высокая интеграция инструментальных средств в рамках единой оболочки;использование общего репозитория.Выделяют три группы инструментальных систем:1. Инструментальные среды программирования.2. Средства автоматизации разработки программ.3. Интегрированные среды.В идеальном варианте инструментальные системы должны распространяться на максимально возможное количество процессов и покрывать максимум стадий жизненного цикла. Однако исторически сложилось так, что инструментальные среды в большей степени связаны с процессами программирования, тестирования и отладки, а средства автоматизации разработки программ – с анализом и проектированием. Инструментальные среды программирования обычно содержат текстовый редактор, компилятор, отладчик и средства подсказки. Кроме того, в них могут быть включены и другие инструменты, позволяющие выполнять статический и динамический анализ программ. Эти инструменты взаимодействуют между собой через обычные файлы с помощью стандартных возможностей файловой системы. Различают среды общего назначения и языково-ориентированные среды. Среды общего назначения содержат набор программных инструментов (например, текстовый редактор, редактор связей и т. п.), позволяющих выполнять разработку программ на разных языках программирования. Для программирования на конкретном языке программирования требуются дополнительные инструменты, ориентированные на этот язык.Языково-ориентированные среды предназначены для поддержки разработки программ на каком-либо одном языке программирования, причем построение такой среды базируется на знаниях об этом языке.Инструментальная среда не обязательно должна функционировать на том компьютере, на котором должен будет применяться разрабатываемый с ее помощью программный продукт. При этом инструментальные среды программирования имеют следующие особенности:- поддерживают различные методологии;- применяются в различных технологиях;- применяются командами, работающими над различными проектами;- используются для разработки разнообразных приложений;- разрабатываются одной компанией.В качестве примеров инструментальных сред можно перечислить такие, как Microsoft Visual Studio, Forte for Solaris Developer Tools (Sun Microsystems Inc.), Borland Delphi Suite и подобные им. Средства автоматизации разработки программ – это инструментарий для системных аналитиков, разработчиков и программистов, позволяющий автоматизировать процесс проектирования и разработки ПО.Первоначально под CASE-средствами понимались средства, применяемые на ранних процессах жизненного цикла: в первую очередь – на наиболее трудоемких процессах анализа и проектирования.Сегодня CASE-средства трактуются как программные средства с мощными инструментами визуального моделирования, поддерживающие процессы жизненного цикла программного обеспечения. Средства автоматизации разработки программ выделяются наличием следующих особенностей:-поддерживают единственную методологию;-ориентируются на определенную технологию;-предназначаются для команд, работающих над единственным проектом;-используются для разработки информационных систем;-разрабатываются одной компанией.Примерами CASE-средств являются Oracle Designer, ERwin (Computer Associates International, Inc.), Rational Rose (Rational Software Corporation) и т. п. Интегрированная среда – совокупность программных инструментов, поддерживающая все процессы жизненного цикла программного обеспечения в рамках определенной технологии. Компонентами интегрированных сред являются:инструменты управления процессами;инструменты управления проектом;инструменты конфигурационного управления;инструменты верификации;инструменты поддержки разработки документации. Выделяют три уровня интеграции инструментов в интегрированных средах.1. Интеграция инструментов – очень слабая. Обмен информацией между ними происходит, как правило, через интерфейсы экспорта и импорта.2. Интеграция инструментов одной компании осуществляется на основе единого репозитория. Интеграция собственных инструментов с инструментами третьих фирм происходит по образцу предыдущего уровня.3. Интеграция всех инструментов осуществляется с помощью общего репозитория. При этом любой инструмент любой компании может осуществлять взаимодействие через службы взаимодействия с репозиторием.Особенности интегрированных сред:- поддерживают различные методологии;- определяют технологию разработки;- применяются командами, работающими вместе над несколькими проектами;- как правило, используются для разработки научных и инженерных приложений;- разрабатываются одной компанией, но имеется возможность интеграции с инструментами третьих фирм.Примерами интегрированных сред являются WebSphere Studio WorkBench (IBM), CohesionWorX (Digital Equipment Corp.) и SorfBench (Hewlett-Packard). Репозиторий – хранилище информации, связанной с проектом разработки программного продукта в течение всего его жизненного цикла.Большинство технологических подходов к разработке ПО предполагает работу с тремя основными типами информации – модельными спецификациями, интерфейсом прикладного программиста и окружением проекта. В соответствии с этими типами выделяют и три класса уровней репозиториев:1. Модельный.2. Программного интерфейса.3. Окружения.Уровень моделирования достаточно хорошо может быть описан универсальным языком UML. Данный язык является абстрактным, не привязанным к конкретной модели. Язык дает возможность описать зависимости элементов, иерархию, взаимосвязи, свойства и т. п. Уровень программного интерфейса разумно описывать с помощью языка определения интерфейсов IDL, обеспечивающего независимость спецификации интерфейсов от их реализации. Уровень играет не только роль промежуточного слоя – его средства также поддерживают распределенное программирование.Репозиторий окружения программного проекта предназначен для хранения информации, разделяемой компонентами и подкомпонентами систем программирования в процессе их работы. При этом основными группами и подгруппами полезной информации считаются следующие:1. Языково-независимая группа:- информация для отладчика;- информация для анализатора исходных текстов.2. Языково-зависимая группа:- информация для шаблонов;- коды встроенных функций;- виртуальные функции.3. Группа контроля репозитория:- контроль информации о версиях;- контроль отношения к проекту;- тип параллельной обработки;- тип управления репозиторием;- проверка цифровой подписи. Главными достоинствами применения репозиториев окружения являются:- эффективность работы с информацией;- использование информации для целей оптимизации;- распределенность (из которой следуют доступность, параллелизм и специализация);- модульность, включающая независимость от конкретных инструментов (например, компиляторов);- возможность работы с репозиторием как в архитектуре «клиент-сервер», так и в «связанном» с инструментом режиме.Статистика отмечает, что около 80% ПО создается по уже имеющемуся. Следовательно, необходимо иметь электронную библиотеку, которая будет поддерживать архивы и интеллектуальный поиск нужных прототипов и фрагментов. Одним из наиболее известных репозиториев является Microsoft Repository. Системы управления версиями (контроля версий) – программное обеспечение, предназначенное для отслеживания изменений между различными версиями файловых документов и разделения доступа к ним.Такие системы наиболее широко применяются при разработке программного обеспечения – для хранения исходных кодов программ. Однако могут с успехом применяться и в других областях, в которых ведётся работа с большим количеством непрерывно изменяющихся электронных документов (например, в САПР).Система управления версиями позволяет хранить несколько версий одного и того же документа, при необходимости, возвращаться к более ранним версиям, определять, кто и когда сделал то или иное изменение и т.д. Системы контроля версий, как правило, отслеживают только изменения (дельты) между версиями файлов (а не сами полные версии), что позволяет эффективно использовать дисковое пространство.Большинство систем может автоматически объединить (слить) изменения, сделанные разными разработчиками. Однако, такое автоматическое объединение изменений, обычно, возможно только для текстовых файлов и при условии, что изменялись разные (непересекающиеся) части этого файла. Такое ограничение связано с тем, что большинство систем управления версиями ориентированы на поддержку процесса разработки программного обеспечения, а исходные коды программ хранятся в текстовых файлах. Если автоматическое объединение выполнить не удалось, система может предложить решить проблему вручную.Часто выполнить слияние невозможно, ни в автоматическом, ни в ручном режиме, например, если формат файла неизвестен. Некоторые системы управления версиями дают возможность заблокировать файл в хранилище. Блокировка не позволяет другим пользователям получить рабочую копию и обеспечивает, таким образом, исключительный доступ только тому пользователю, который работает с документом. Многие системы управления версиями предоставляют ряд других возможностей:1. Позволяют создавать разные варианты одного документа, т. н. ветки, с общей историей изменений до точки ветвления и с разными – после неё.2. Дают возможность узнать, кто и когда добавил или изменил конкретную строку кода в файле.3. Ведут журнал изменений, в который пользователи могут записывать информацию о том, что и почему они изменили в данной версии.4 Контролируют права доступа пользователей, разрешая или запрещая чтение или изменение информации, в зависимости от того, кто запрашивает это действие.На практике системы управления версиями рекомендуется использовать не только при коллективной, но и при индивидуальной (авторской) разработке ПО.

Приложенные файлы

  • ppt 18088972
    Размер файла: 6 MB Загрузок: 0

Добавить комментарий