Компонентный подход к разработке программного обеспечения. Инструментальные библиотеки. Каркасы приложений (Фреймворки).

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

Изначально (от момента появления ЭВМ до середины 60-х) годов вообще отсутствовала какая-либо технология. Программирование было «стихийным» и считалось практически искусством. Первые программы имели простейшую структуру и были написаны в машинных кодах. С появлением ассемблеров программы стали «читаемыми». Затем появились средства, позволяющие оперировать подпрограммами. Подпрограммы можно было сохранять и использовать в других программах. В результате были созданы огромные библиотеки расчетных и служебных подпрограмм. Все бы хорошо, но начале 60-х годов разразился «кризис программирования». Выражался он в том, что фирмы взявшиеся за разработку сложного программного обеспечения, срывали все сроки завершения проекта. Это было вызвано несовершенством технологии программирования, и на смену «стихийному программированию» пришел структурный подход к программированию (60-е – 70-е годы). В основе подхода лежит декомпозиция (разбиение на части сложных систем с целью последующей реализации в виде отдельных небольших подпрограмм. Дальнейший рост сложности и размеров разрабатываемого ПО повлек развитие модульного программирования. Модульное программирование предполагает выделение групп подпрограмм, использующих одни и те же глобальные данные в отдельно компилируемые модули (библиотеки подпрограмм).В свою очередь сложность и объем программ неуклонно возрастал и структурный подход в совокупности с модульным программированием перестал удовлетворять требованиям разработки ПО. И на смену ему пришел объектный подход.

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

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

Компонентный подход лежит в основе технологий, разработанных на базе COM (Component Object Model – компонентная модель объектов) и технологии создания распределенных приложений CORBA (Common Object Request Broker Architecture – общая архитектура с посредником обработки запросов объектов). Эти технологии используют сходные принципы и различаются лишь особенностями реализации.

Технология COM (Microsoft) является развитием технологии OLE (Object Linking and Embedding – связывание и внедрение объектов), которая использовалась в ранних версиях Windows для создания составных документов. Технология COM представляет общую парадигму взаимодействия программ любых типов: библиотек, приложений, ОС, т. е. позволяет одной части ПО использовать функции (службы), предоставляемые другой, независимо от того, функционируют ли эти части в пределах одного процесса, в разных процессах на одном компьютере. Модификация COM, обеспечивающая передачу вызовов между компьютерами, называется DCOM (Distributed COM – распределенная COM).

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

Объект всегда функционирует в составе сервера – динамической библиотеки или исполняемого файла, которые обеспечивают функционирование объекта. Различают:

· внутренний сервер – реализуется динамическими библиотеками, которые подключаются к приложению-клиенту и работают в одном адресном пространстве.

· локальный сервер – создается отдельным процессом, который работает на одном компьютере с клиентом

· удаленный сервер – создается процессом, работающим на другой машине

Например, MS Word является локальным сервером.

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

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

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

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

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

Если проектировать приложения нелегко, инструментальные библиотеки – еще сложнее, то проектирование каркасов – задача самая сложная. Проектировщик каркаса должен учитывать, что единая архитектура будет пригодна для всех приложений в данной предметной области. Современные – dotnet, Java interprice idetion.

Качество программного обеспечения. Характеристики качества программного обеспечения. Методики повышения качества программного обеспечения. Стандартизация и метрология в разработке программного обеспечения.

Качество ПО имеет внешние и внутренние характеристики. Внешние – св-ва, к-е осознает пользователь прог-мы. К ним относятся: Корректность – отсутствие(наличие) дефектов в спецификации, проекте и реализации прог-мы.

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

Адаптируемость – возможность использования с-мы без ее изменения в тех областях или средах, на к-е она не была ориентирована непосредственно. Правильность –степень безошибочности с-мы, особенно в отношении вывода количественных данных. Она характеризует выполнение с-й функций, а не то, создана ли она корректно. Этим правильность отличается от корректности. Живучесть – способность с-мы продолжать работу при вводе недопустимых данных или в напряженных условиях.

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

Внутренние характеристики:

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

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

Контроль качества ПО – планомерная и систематичная программа действий, призванная гарантировать, что с-ма обладает желательными характеристиками. Методики повышения качества ПО:

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

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

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

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

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

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

Стандарты могут зависеть от масштаба (международные, национальные, отраслевые, внутрифирменная) и от возникновения – «де-факто» и «де-юре».

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

Общее представление о качестве ПС(прогр-х средств) международным стандартом ISO 9126 рекомендуется отражать тремя взаимодействующими и взаимозависимыми метриками характеристик качества:

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

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

15. Отладка и тестирование программного обеспечения. Виды тестирования. Тестирование методом "чёрного" ящика. Тестирование методом "белого" ящика. Модульные тесты (unit tests) и утверждения (assertion).

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

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

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

В тестировании можно выделить несколько различных процессов. Важно различать такие термины, как «тестирование», «отладка», «контроль», «испытание»:

Тестирование – процесс выполнения программы с намерением найти ошибки. Контроль (verification) – попытка найти ошибки, выполняя ошибки в тестовой, или моделируемой, среде. Испытание (validation) – попытка найти ошибки, выполняя программу в заданной реальной среде. Верификация потом валидация. Аттестация (certification) – авторитетное подтверждение правильности программы.
Т. е. при тестировании с целью аттестации выполняется сравнение с некоторым заранее определенным стандартом.

Отладка (debugging) – процесс определения и устранения причин ошибок. (!) Отладка не является разновидностью тестирования, хотя эти понятия часто употребляются как синонимы. Эти два вида деятельности тесно связаны – результаты тестирования являются исходными данными для отладки.

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

Рассмотрим другой ряд определений, охватывающий другую сторону тестирования: типы предполагаемых ошибок и стандарты, с которыми сопоставляются тестируемые программы.

·Тестирование модуля или автономное тестирование (module testing/unit testing) – контроль отдельного программного модуля, обычно в изолированной среде (т. е. изолированно от всех остальных модулей)

·Тестирование сопряжений (integration testing) – контроль сопряжений между частями системы (модулями, компонентами, подсистемами). ·Тестирование внешних функций (external function testing) – контроль внешнего поведения системы, определенного внешними спецификациями. ·Комплексное тестирование (system testing) – контроль и/или испытание системы по отношению к исходным целям. ·Тестирование приемлемости (acceptance testing) – проверка соответствия программы требованиям пользователя. ·Тестирование настройки (installation testing) – проверка соответствия каждого конкретного варианта установки системы с целью выявить любые ошибки настройки.

Существует несколько стратегий тестирования систем. Это стратегии «черного» и «белого» ящиков.

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

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

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

2) Утверждения (assertion) – это технология тестирования, когда пишется код (метод или макрос), с помощью которого проверяется правильность заданного условия.

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