Программное обеспечение. программное обеспечение компьютера
 Скачать 51 Kb.
|
|
Современные образовательные технологии в социальной сфере «ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ КОМПЬЮТЕРА»Цель: рассмотреть технологию проектирования программного обеспечения компьютер, тестирование программного обеспечения Под программным обеспечением (Software) понимается совокупность программ, выполняемых вычислительной системой. К программному обеспечению (ПО) относится также вся область деятельности по проектированию и разработке ПО: технология проектирования программ (например, нисходящее проектирование, структурное и объектноориентированное проектирование и др.); методы тестирования программ; методы доказательства правильности программ; анализ качества работы программ; документирование программ; разработка и использование программных средств, облегчающих процесс проектирования программного обеспечения, и многое другое. Программное обеспечение неотъемлемая часть компьютерной системы. Оно является логическим продолжением технических средств. Сфера применения конкретного компьютера определяется созданным для него программным обеспечением. Сам по себе компьютер не обладает знаниями ни в одной области применения. Все эти знания сосредоточены в выполняемых на компьютерах программах. Программное обеспечение современных компьютеров включает миллионы программ — от игровых до научных. Как бы ни была тщательно отлажена программа, решающим этапом, устанавливающим ее пригодность для работы, является контроль программы по результатам ее выполнения на системе тестов. Программу условно можно считать правильной, если её запуск для выбранной системы тестовых исходных данных во всех случаях дает правильные результаты. Но тестирование может показать лишь наличие ошибок, но не их отсутствие. Нередки случаи, когда новые входные данные вызывают «отказ» или получение неверных результатов работы программы, которая считалась полностью отлаженной. Для реализации метода тестов должны быть изготовлены или заранее известны эталонные результаты. Тестовые данные должны обеспечить проверку всех возможных условий возникновения ошибок: должна быть испытана каждая ветвь алгоритма; очередной тестовый прогон должен контролировать нечто такое, что еще не было проверено на предыдущих прогонах; первый тест должен быть максимально прост, чтобы проверить, работает ли программа вообще; арифметические операции в тестах должны предельно упрощаться для уменьшения объема вычислений; количества элементов последовательностей, точность для итерационных вычислений, количество проходов цикла в тестовых примерах должны задаваться из соображений сокращения объема вычислений; минимизация вычислений не должна снижать надежности контроля; тестирование должно быть целенаправленным и систематизированным, так как случайный выбор исходных данных привел бы к трудностям в определении ручным способом ожидаемых результатов; кроме того, при случайном выборе тестовых данных могуг оказаться непроверенными многие ситуации; усложнение тестовых данных должно происходить постепенно. Процесс тестирования можно разделить на три этапа. Проверка в нормальных условиях. Предполагает тестирование на основе данных, которые характерны для реальных условий функционирования программы. Проверка в экстремальных условиях. Тестовые данные включают граничные значения области изменения входных переменных, которые должны восприниматься программой как правильные данные. Типичными примерами таких значений являются очень маленькие или очень большие числа и отсутствие данных. Еще один тип экстремальных условий  это граничные объемы данных, когда массивы состоят из слишком малого или слишком большого числа элементов.З. Проверка в исключительных ситуациях. Проводится с использованием данных, значения которых лежат за пределами допустимой области изменений. Известно, что все программы разрабатываются в расчете на обработку какого-то ограниченного набора данных. Поэтому важно получить ответ на следующие вопросы: что произойдет, если программе, не рассчитанной на обработку отрицательных и нулевых значений переменных, в результате какой-либо ошибки придется иметь дело как раз с такими данными? как будет вести себя программа, работающая с массивами, если количество их элементов превысит величину, указанную в объявлении массива?  что произойдет, если числа будут слишком малыми или слишком большими?Наихудшая ситуация складывается тогда, когда программа воспринимает неверные данные как правильные и выдает неверный, но правдоподобный результат. Программа должна сама отвергать любые данные, которые она не в состоянии обрабатывать правильно. Процесс проектирования архитектуры программного обеспечения включает в себя сбор требований клиентов, их анализ и создание проекта для компонента программного обеспечения в соответствие с требованиями. Успешная разработка ПО должна обеспечивать баланс неизбежных компромиссов вследствие противоречащих требований; соответствовать принципам проектирования и рекомендованным методам, выработанным со временем; и дополнять современное оборудование, сети и системы управления. Надежная архитектура программного обеспечения требует значительного опыта в теоретических и практических вопросах, а также воображения, необходимого для преобразования бизнес-сценариев и требований, которые могут казаться неясными, в надежные и практичные рабочие проекты. Архитектура программного обеспечения включает в себя определение структурированного решения, соответствующего всем техническим и рабочим требованиям, одновременно оптимизируя общие атрибуты качества, такие как производительность, безопасность и управляемость. Сюда входит серия решений, основанных на широком диапазоне факторов, и каждое из этих решений может значительно влиять на качество, производительность, поддерживаемость и общий успех программного обеспечения.  Современное программное обеспечение редко бывает автономным. Как минимум, в большинстве случаев оно будет взаимодействовать с источником данных, напримеркорпоративной базой данных, предоставляющим информацию, с которой работают пользователи программного обеспечения. Обычно современное программное обеспечение также должно взаимодействовать с другими службами и сетевыми функция для выполнения проверки подлинности, получения и публикации информации и предоставления интегрированных сред работы пользователей. Без соответствующей архитектуры может быть сложно, если вообще возможно, осуществить развертывание, эксплуатацию, обслуживание и успешную интеграцию с другими системами; кроме того, требования пользователей не будут соблюдены.Архитектуру программного обеспечения можно рассматривать как сопоставление между целью компонента ПО и сведениями о реализации в коде. Правильное понимание архитектуры обеспечит оптимальный баланс требований и результатов. Программное обеспечение с хорошо продуманной архитектурой будет выполнять указанные задачи с параметрами исходных требований, одновременно обеспечивая максимально высокую производительность, безопасность, надежность и многие другие факторы. На самом высоком уровне проект архитектуры должен предоставлять структуру системы, но скрывать детали реализации; охватывать все случаи применения и сценарии; пытаться учитывать требования всех заинтересованных лиц; и удовлетворять настолько, насколько возможно, всем функциональные требованиям и требованиям к качеству. В чем важность архитектуры программного обеспечения? Требования к современному программному обеспечению становятся все более сложными, поскольку пользователи ожидают все больше от приложений. Возможностей простых автономных настольных приложений больше не достаточно для большинства коммерческих и деловых ситуаций. В мире развитой связи приложения должны взаимодействовать с другими приложениями и службами, а также работать в различных средах, например в облаке, и на портативных устройствах. На смену распространенным в прошлом монолитных архитектур пришло компонентное сервисориентированное программное обеспечение, использующее платформы, операционные системы, хост-приложения и сети для реализации функций, о которых было не известно всего несколько лет назад. Эти трудности влияют не только на архитектуру, но также и на развертывание, обслуживание и администрирование программного обеспечения. Совокупная стоимость владения (ТСО) программного обеспечения теперь в основном состоит из затрат, возникающих после развертывания. Приложение с хорошо продуманной архитектурой обеспечит минимальную совокупную стоимость владения благодаря снижению затрат и времени, необходимых на развертывание приложения, обеспечение его работы, обновление для удовлетворения меняющимся требованиям и устранение проблем. Администрирование и поддержка пользователей также будут упрощены. Успешное программное обеспечение также должно соответствовать нескольким важным критериям. Оно должно обеспечивать безопасность, чтобы приложение и его данные были защищены от атак злоумышленников и случайных ошибок. Оно должно быть устойчивым и надежным для минимизации сбоев и соответствующих затрат. Оно должно работать с необходимыми параметрами в соответствие с требованиями пользователей, такими как максимальное время отклика или определенная рабочая нагрузка. Оно должно быть простым в поддержке для снижения затрат на администрирование и поддержку и достаточно расширяемым для включения неизбежных изменений и обновлений, которые со временем потребуются. Со всеми этими факторами связаны некоторые компромиссы. Например, реализация наиболее безопасных механизмов с использованием сложного шифрования повлияет на производительность. Реализация множества параметров конфигурации и обновления может усложнить развертывание и администрирование. Кроме того, чем сложнее архитектура, тем дороже ее реализация. Правильная архитектура должна обеспечивать баланс этих факторов с целью получения оптимального результата для определенного сценария. Чем занимаются разработчики архитектуры программного обеспечения? Архитектура программного обеспечения начинается с набора требований. Они могут быть выражены в форме диаграмм, блок-схем процесса, моделей или документированных списков задач эксплуатации, которые должно выполнять программное обеспечение. Обычно клиент или партнер также выражает менее точные требования, такие как внешний вид или способ работы определенных пользовательских интерфейсов для часто встречающихся задач. Требования также должны включать в себя информацию о существующем программном обеспечении, системах, оборудовании и сетях, с которыми будет взаимодействовать новое программное обеспечение; и другие факторы, такие как план развертывания и обслуживания, и, конечно же, доступный бюджет проекта. Разработчик архитектуры программного обеспечения должен учитывать потребности клиента. Однако общий термин «клиент» обычно состоит из трех противоречащих областей ответственности: бизнес-требования, требования пользователя и системные требования. Бизнес-требования обычно определяют диапазон таких факторов, как бизнес-процессы, факторы производительности (такие как безопасность, надежность и пропускная способность), а также бюджетные ограничения и ограничения на издержки. Требования пользователя включают в себя дизайн интерфейса, производственные возможности и простоту использования программного обеспечения. Системные требования подразумевают возможности и ограничения оборудования, сети и среды выполнения. Разработчику необходимо создать архитектуру, подходящую для перекрывающихся областей. Каждый архитектор программного обеспечения имеет собственный подход к сбору и анализу требований, а также определению архитектуры. Однако им часто приходится отвечать на следующие вопросы: «Как пользователи будуг работать с приложением?»; «Как приложение будет развернуто в производственной среде и управляться?»; «Каковы требования атрибутов качества для приложения, такие как безопасность, производительность, параллелизм, интернационализация и конфигурация?»; «Какова должна быть архитектура приложения для обеспечения гибкости и удобства в обслуживании с течением времени?» и «Какие архитектурные тенденции могут воздействовать на приложение сейчас и после его развертывания?». Последний вопрос одновременно важен и интересен. Хорошая архитектура программного обеспечения не только соответствует текущим требованиям клиентов, но и будет соответствовать таким требованиям в обозримом будущем. Это влияет на решения, принимаемые разработчиком архитектуры относительно оборудования, компонентов, платформ, средвыполнения, программных систем управления и множества других функций, встроенных в программное обеспечение или с которыми оно должно интегрироваться.Как и большинство заданий в мире проектирования и разработки программного обеспечения, разработка архитектуры  это одновременно предупредительный и итеративный процесс. Многие первоначальные задачи, такие как анализ требований, техническое исследование и определение целей, обычно выполняются в начале процесса.Следующий этап — определение ключевых сценариев для архитектуры. Это основные требования, которым должно соответствовать программное обеспечение, и ограничения, в рамках которых оно должно работать. На основании этой информации разработчик архитектуры может создать обзор приложения. Этот обзор охватывает такие высокоуровневые сведения, как тип приложения (для Интернета, телефонов, настольное или облачное), архитектура развертывания (обычно многоуровневая архитектура, компоненты которой связываются через границы оборудования и сети), соответствующие применимые стили архитектуры (например, п-уровневая, клиент-сервер или сервис-ориентированная) и технологии реализации, лучше всего подходящие для сценария. После этого разработчик может приступить к созданию кандидатов архитектуры, удовлетворяющих высокоуровневым и наиболее важным требованиям, определенным ранее. После этого проект архитектуры проверяется и тестируется в ключевых сценариях, часто в сочетании с отзывами клиентов и пробными или тестовыми версиями, для обеспечения получения оптимального результата. Это маловероятно при первой итерации, но при повторении цикла будет достигнуто соответствие проекта требованиям и ключевым сценариям. По мере детализации проекта и определения отдельных задач и компонентов архитектор может уточнить и добавить подробности на каждом этапе. Например, после определения архитектурного стиля и подхода к развертыванию архитектор может принять решения о связи уровней и компонентов. Сюда может входить выбор протокола на основе существующих и будущих требований, а также принятие во внимание обзоров новых технологий и возможностей, определенных в будущих стандартах. Окончательный продукт работы архитектора — это обычно набор схем, моделей и документов, определяющих приложение с нескольких точек зрения, чтобы при объединении они могли предоставить разработчикам, группам тестирования, администраторам и управлению всю необходимую информацию для реализации проекта. Эта информация будет описывать структуру и размещение компонентов и уровней приложения; способ обработки горизонтального пересечения иерархии, например, протоколирования и проверки; планы тестирования и развертывания; и документацию для разработчиков, администраторов и персонала службы поддержки . В окончательном проекте также могуг быть указаны атрибуты качества, которым должно соответствовать приложение. Это результат принятых решений и компромиссов разработчика архитектуры по консультации с клиентом. К ним относятся определения требований безопасности и план реализации безопасности, необходимая масштабируемость и производительность при развертывании на целевой платформе, способы реализации возможности обслуживания и расширяемости и функции обеспечения взаимодействия с другими системами. Конечно, для архитектуры программного обеспечения также требуется воображение. Возможность увидеть, как системы будут соединяться и взаимодействовать, как они будут секционированы и развернуты, и как они взаимодействуют с пользователями, часто появляется только после того, как разработчик архитектуры сможет представить в уме общее решение. Для этого требуется организованный подход и большое внимание к деталям, чтобы собрать и понять все требования и ограничения, а также постепенно преобразовать все это в динамичный и исчерпывающий технический проект. Однако для этого необходим талант и воображение, чтобы мысленно представить конечный результат и методично добиваться создания идеального решения. |