Решение задач по программированию

Размещено на http://www.allbest.ru/

1.1 Основные понятия и определения

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

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

*системные программисты, занимающиеся разработкой, эксплуатацией и сопровождением системного программного обеспечения (см. ниже);

*прикладные программисты. Выполняют разработку и отладку программ решения задач из различных прикладных сфер деятельности пользователей;

*конечные пользователи. Используют прикладное программное обеспечение для решения задач в своей повседневной деятельности. Различаются по уровню своей подготовки в части знания и использования компьютерной техники;

*администраторы. Как правило, это высококвалифицированные компьютерные специалисты, отвечающие за работу вычислительной сети, баз данных, корпоративной информационной системы в целом, безопасность и защиту данных. Могут иметь определенную специализацию: управление сетевым каталогом, политикой учетных записей, политикой аудита и т.п.

Задача (problem, task) - проблема, подлежащая решению в интересах пользователя.

Термин "задача" в программировании означает единицу работы вычислительной системы, требующую выделения вычислительных ресурсов (процессорного времени, оперативной и внешней памяти, файлов и т.п.).

Приложение (application) - программная реализация решения задачи на компьютере. Приложение может состоять из одной или нескольких взаимосвязанных и взаимодействующих программ.

Принято (весьма условно) делить программы на небольшие (простые), средней сложности и большие.

Программа считается небольшой как по размерам, так и по другим признакам, если она удовлетворяет следующим признакам:

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

2. неважно, насколько быстро она работает;

3. ущерб от неправильной работы программы - практически нулевой (за исключением возможности обрушения ею системы, в которой выполняются и другие, более важные задачи);

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

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

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

Обычно сложная программа обладает следующими свойствами:

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

2. существенно, чтобы программа была удобной в использовании. В частности, она должна включать достаточно полную и понятную пользователям документацию, возможно, также специальную документацию для администраторов, а также набор документов для обучения работе с программой;

3. низкая производительность программы на реальных данных приводит к значимым потерям для пользователей;

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

5. для выполнения своих задач программа должна взаимодействовать с другими программами и программно-аппаратными системами и обеспечивать работу на разных платформах;

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

7. в разработку программы вовлечено значительное количество людей (более 5-ти человек). Большую программу практически невозможно написать с первой попытки, с небольшими усилиями и в одиночку;

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

Примером большой программы может служить стандартная библиотека классов Java или C#, соответствующих систем программирования.

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

Процесс создания программ можно представить как последовательность следующих действий:

1. постановка задачи;

2. алгоритмизация решения задачи;

3. программирование.

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

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

Программирование (programming) - теоретическая и практическая деятельность, связанная с созданием программ.

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

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

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

1.2 Технологии программирования

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

В литературе имеются и другие, несколько отличающиеся, определения технологии программирования. Используется в литературе и близкое к технологии программирования понятие программной инженерии, определяемой как систематический подход к разработке, эксплуатации, сопровождению и изъятию из обращения программных средств. Главное различие между технологией программирования и программной инженерией как дисциплинами для изучения заключается в способе рассмотрения и систематизации материала.

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

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

В историческом аспекте в развитии технологии программирования можно выделить несколько этапов.

1. Первый этап: "стихийное" программирование - отсутствие сформулированной технологии, когда программирование было, по сути, искусством. Этап охватывает период от появления первых ЭВМ до середины 60-х годов 20-го века. Развитие программирования шло по пути замены машинных языков ассемблерами, а затем алгоритмическими языками (Fortran, Algol) и повторного использования подпрограмм, что повысило производительность труда программиста.

Стихийно использовалась разработка "снизу вверх" - подход, при котором вначале проектировали и реализовали сравнительно простые подпрограммы, из которых потом пытались построить сложную программу [6]. В начале 60-х годов 20-го века разразился кризис программирования [1, 3]. Он выражался в том, что фирмы превышали все сроки завершения программных проектов и их стоимость. В результате многие проекты так и не были завершены.

2. Второй этап - структурный подход к программированию. Этот подход сложился в 60-70-е годы 20-го века и представлял собой совокупность рекомендуемых технологических приемов, охватывающих все этапы разработки программного обеспечения. В основе структурного подхода лежит декомпозиция сложных систем с целью последующей реализации в виде отдельных небольших подпрограмм. В отличие от используемого ранее процедурного подхода к декомпозиции, структурный подход требовал представления задачи в виде иерархии подзадач простейшей структуры.

Проектирование осуществлялось "сверху вниз" и подразумевало реализацию общей идеи, обеспечивая проработку интерфейсов подпрограмм. Вводились ограничения на конструкции алгоритмов, рекомендовались формальные модели их описания, а также специальный метод проектирования алгоритмов - метод пошаговой детализации. Поддержка принципов структурного программирования была заложена в основу процедурных языков программирования (PL/1, Algol-68, Pascal, C).

Появилась и начала развиваться технология модульного программирования, которая предполагает выделение групп подпрограмм, использующих одни и те же глобальные данные, в отдельно компилируемые модули. Практика показала, что структурный подход в сочетании с модульным программированием позволяет получить достаточно надежные программы, размер которых не превышает 100000 операторов [3]. Узким местом модульного программирования стали межмодульные интерфейсы, ошибки в которых трудно обнаружить по причине раздельной компиляции модулей (ошибки выявляются только при выполнении программы).

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

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

Развитие объектного подхода в технологии программирования привело к созданию сред визуального программирования. Появились языки визуального объектно-ориентированного программирования, такие как Delphi, C++ Builder, Visual C++, C# и т. д. Однако технология ООП имеет и недостатки. Главный из них - зависимость модулей программного обеспечения от адресов экспортируемых полей и методов, структур и форматов данных. Эта зависимость объективна, так как модули должны взаимодействовать между собой, обращаясь к ресурсам друг друга.

4. Четвертый этап - компонентный подход и CASE-технологии (с середины 90-х годов 20-го века до нашего времени). Этот подход предполагает построение программного обеспечения из отдельных компонентов - физически отдельно существующих частей программного обеспечения, которые взаимодействуют между собой через стандартизованные двоичные интерфейсы. В отличие от обычных объектов объекты-компоненты можно собирать в динамически вызываемые библиотеки или исполняемые файлы, распространять в двоичном виде (без исходных текстов) и использовать в любом языке программирования, поддерживающем соответствующую технологию. В настоящее время рынок компонентов - реальность, поддерживаемая Интернетом и массовой рекламой и публикациями.

Основы компонентного подхода были разработаны компанией Microsoft, начиная с технологии OLE (Object Linking and Embedding - связывание и внедрение объектов), которая применялась в ранних версиях Windows для создания составных документов. Ее развитием стало появление COM-технологии (Component Object Model - компонентная модель объектов), а затем ее распределенной версии - DCOM, на основе которых были разработаны компонентные технологии, решаются различные задачи разработки программного обеспечения.

Среди них следуют отметить OLE-automation - технологию создания программируемых приложений, обеспечивающую доступ к внутренним службам этих приложений. На основе OLE-automation создана технология ActiveX, предназначенная для создания программного обеспечения, как сосредоточенного на одном компьютере, так и распределенного. Безопасность и стабильная работа распределенных приложений обеспечивается еще двумя технологиями, заложенными в COM. Это MDS (Multitier Distributed Application Sever) - сервер многозвенных распределенных приложений, и MTS (Microsoft Transaction Server) - сервер управления транзакциями.

Компонентный подход лежит также в основе технологии CORBA (Common Object Request Bracer Architecture - общая архитектура с посредником обработки запросов объектов). Эта технология, которая реализует подход, аналогичный COM, разработана группой компаний OMC (Object Management Group - группа внедрения объектной технологии программирования). Программное ядро CORBA реализовано для всех основных аппаратных и программных платформ и обеспечивает создание программного обеспечения в гетерогенной вычислительной среде.

Важнейшая особенность современного этапа технологии программирования - широкое использование компьютерных технологий создания и сопровождения программных систем на всех этапах их жизненного цикла. Эти технологии получили название CASE-технологий (ComputerAided Software/System engineering - разработка программного обеспечения/программных систем с использованием компьютерной поддержки). Сегодня существуют CASE-технологии, поддерживающие как структурный, так и объектный, в том числе компонентный, подходы к программированию.

Зная, какие программные технологии оказали самое сильное влияние за последние 25 лет, можно оценить их по количеству опубликованных научных статей или выяснить, например, сколько времени продолжался поднятый вокруг них ажиотаж. С другой стороны, с точки зрения пользователя, можно судить о них, оценивая, чего удалось добиться по сравнению с тем, что предварительно было обещано. Так в чем же уникальность последних 25 лет?

Во-первых, программное обеспечение перестало быть прерогативой нескольких компаний и стало частью повседневной жизни практически каждого жителя нашей планеты: ПК, Internet и мобильные телефоны - свидетельства этой грандиозной эволюции. Журналы и интернет-ресурсы за последние 25 лет кардинально изменились. До 1980 года для практиков основным источником сведений о программных технологиях был Datamation, сейчас существует несколько таких источников, например, IEEE Software, а также онлайновые ресурсы вроде Slashdot, которые тоже дают представление о последних шагах в эволюции технологий. Собран материал из множества отдельных источников данных, которые найдены в различных обзорах иwiki в программном мире. Для объективности К. Эберт обратился к своим коллегам из советов IEEESoftware и поинтересовался их представлением о технологиях, появившихся за последние 25 лет. На самом деле, точно определить время перехода на новый этап просто невозможно. Это относится, например, к объектноориентированной разработке, которая активно используется с 1990-х годов, но до сих пор не нашла своего применения в некоторых отраслях.

На рис.1.1 показаны три основные группы программных технологий. Базовые технологии по мере своего развития влияют на массовые тенденции и дисциплины, и они применяются во всех областях и направлениях программной разработки. Большинство из известных сейчас таких технологий существуют последние 25 лет. Технологические концепции и методологии объединяют базовые методики, которые используются во многих различных отраслях и продуктах. Консолидированные технологии опираются на концепции и предоставляют готовые технические решения. В тех случаях, когда технологии принадлежат к двум таким группам, они отнесены к более общей группе.

Что имеют в виду, когда говорят, что программная технология "оказывает влияние"? Задавая этот вопрос разным людям, можно получить множество ответов, отражающих точку зрения конкретного собеседника. Профессор будет оценивать репутацию и исследовательские гранты и то, как технология поможет добиться этих целей. Ученый сформулирует свой ответ, учитывая инновационный потенциал. Менеджеров производства в первую очередь интересуют рентабельность, воплощение и инновационные продукты. Программный инженер будет иметь в виду полезность и эффективность при решении той проблемы, которой он занимается.

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

Ряд тенденций, характерных для эволюции программного обеспечения за последние годы: программирование журнал алгоритмизация windows

*развитие программных технологий теперь стимулируют не отдельные компании, а экосистемы исследователей, поставщиков, потребителей и пользователей;

*технологии должны пройти ряд апробаций с различной направленностью, прежде чем они будут признаны успешными;

*каждая конкретная технология распространяется в разных отраслях с разной задержкой;

*ориентированность на конкретную предметную область дает пользователям возможность адаптировать технологии к своим специфическим потребностям;

*работа с процессами заменила создание методом проб и ошибок решений под конкретную ситуацию;

*технологии, которые раньше были фрагментированными и изолированными, сейчас интегрируются.

Каждая из этих тенденций оказывает серьезное влияние на инженерные продукты и на формирование программной отрасли. Microsoft с Windows или Sun с Java - пример того, как отдельная компания определяет развитие технологии, но технологии от этих производителей добились успеха благодаря тому, что они создавались и широко распространялись в отраслях. Невозможно даже представить себе Windows без Intel и всей экосистемы поставщиков и провайдеров сервисов. Точно так же банки создали банкоматы и разработали множество связанных с ними программных технологий, таких как распределенная и защищенная обработка транзакций. Компании розничной торговли стимулировали разработку кассовых аппаратов и необходимого программного обеспечения для поддержки цепочки поставки, в том числе штрих-коды и средства радиочастотной идентификации (RFID).

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

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

Безопасность впервые была признана ключевой технологией в ИТ инфраструктурах в конце 1980-х годов, когда вирус Jerusalem и червь Morris, по существу, парализовали Internet-трафик. Инциденты продолжались в 1990-х годах, поскольку технология применялась только как особая мера и без тщательного архитектурного анализа. Сейчас, по прошествии двадцати лет, вместе с новыми ИТ-продуктами наконец стали реализовать базовые принципы обеспечения безопасности. То же самое повторяется в отрасли телекоммуникаций - как показывают атаки в сфере IP-телефонии, здесь опять пока лишь создаются заплатки на особый случай, но без реального контроля. Промышленная автоматизация и другие предметные области еще больше отстают с внедрением инженерии обеспечения безопасности, как это продемонстрировал червь Slammer.

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

Программные процессы, как для инженерии, так и для управления, стимулировали эволюцию технологий с 1980-х годов. Сложность программных систем растет быстрее, чем люди в состоянии к ней адаптироваться. Эти трудности были уже в 1960-х годах, но тогда ситуация начала терять свою остроту после того, как ведущие отрасли перенесли свое внимание на процесс инженерии программного обеспечения. Как следствие, разработка программного обеспечения за последние 25 лет кардинально изменилась, превратившись из индивидуального творчества в дисциплину программной инженерии.

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

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

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

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

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

Совокупность свойств ПС, которая образует удовлетворительное для пользователя качество ПС, зависит от условий и характера эксплуатации этой ПС, т.е. от позиции, с которой должно рассматриваться качество этой ПС. Поэтому при описании качества ПС, прежде всего, должны быть фиксированы критерии отбора требуемых свойств ПС. В настоящее время критериями качества ПС (criteria of software quality) принято считать:

1. функциональность - способность ПС выполнять набор функций, удовлетворяющих заданным или подразумеваемым потребностям пользователей. Набор указанных функций определяется во внешнем описании ПС;

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

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

4. эффективность - это отношение уровня услуг, предоставляемых ПС пользователю при заданных условиях, к объему используемых ресурсов;

5. сопровождаемость, модифицируемость - это характеристики ПС, которые позволяют минимизировать усилия по внесению изменений для устранения в ней ошибок и по ее модификации в соответствии с изменяющимися потребностями пользователей, переходу на новые версии и т.п.;

6. мобильность (многоплатформенность) - независимость от технического комплекса вычислительных средств, операционной системы, сетевых возможностей, специфики предметной области задачи и т. д.;

7. коммуникативность - степень возможной интеграции с другими программами, обеспечение обмена данными между программами.

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

К основным характеристикам программ и программных систем относится сложность программной системы. При оценке сложности программ, как правило, выделяют три основные группы метрик:

1. метрики размера программ;

2. метрики сложности потока управления программ;

3. метрики сложности потока данных программ.

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

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

К группе оценок размера программ можно отнести также и метрику Холстеда. Основу метрики Холстеда составляют четыре измеряемых характеристики программы:

n1- число уникальных операторов программы, включая символы разделители, имена процедур и знаки операций (словарь операторов);

n2- число уникальных операндов программы (словарь операндов);

N1 - общее число операторов в программе;

N2- общее число операндов в программе.

Опираясь на эти характеристики, получаемые непосредственно при анализе исходных текстов программ, М. Холстед вводит следующие оценки:

словарь программы

`n=n1+n2` ,

длину программы

`N=N1+N2`

объем программы

`V=N*log2(n)(bit)`

Под битом подразумевается логическая единица информации - символ, оператор, операнд.

Далее М. Холстед вводит n*- теоретический словарь программы, т.е. словарный запас, необходимый для написания программы, с учетом того, что необходимая функция уже реализована в данном языке и, следовательно, программа сводится к вызову этой функции. Используя n* , Холстед вводит оценку : V*



V*=n* *log2n*

с помощью которой описывается потенциальный объем программы, который соответствует максимально компактному тексту программы, реализующей данный алгоритм.

Вторая наиболее представительная группа оценок сложности программ - метрики сложности потока управления программ. Как правило, с помощью этих оценок оперируют либо плотностью управляющих переходов внутри программ, либо взаимосвязями этих переходов. И в том, и в другом случае стало традиционным представление программ в виде управляющего ориентированного графа G=(V,E), где V - вершины, соответствующие операторам, а E - дуги, соответствующие переходам.

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

Для вычисления цикломатического числа Маккейба применяется формула

`Z(G)=e-v+2p`

где e - число дуг ориентированного графа G ;

v - число вершин;

p - число компонентов связности графа.

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

Одной из наиболее простых, но, как показывает практика, достаточно эффективных оценок сложности программ является метрика Т. Джилба, в которой логическая сложность программы определяется как насыщенность программы выражениями типа IF-THEN-ELSE. При этом вводятся две характеристики:`GL` - абсолютная сложность программы, характеризующаяся количеством операторов условия; `cl` - относительная сложность программы, характеризующаяся насыщенностью программы операторами условия, т. е. `cl` определяется как отношение `CL` к общему числу операторов.

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

Пара "модуль, глобальная переменная" обозначается как `(p,r)`, где `P` - модуль, имеющий доступ к глобальной переменной `r` . В зависимости от наличия в программе реального обращения к переменнойформируются два типа пар "модуль, глобальная переменная": фактические и возможные. Возможное обращение к с помощью p показывает, что область существования включает в себя .

Характеристика `Aup` говорит о том, сколько раз модули up действительно получали доступ к глобальным переменным, а число `Pup` - сколько раз они могли бы получить доступ. Отношение числа фактических обращений к возможным определяется как `Rup=Aup / Pup`. Эта формула показывает приближенную вероятность ссылки произвольного модуля на произвольную глобальную переменную. Очевидно, чем выше эта вероятность, тем выше вероятность "несанкционированного" изменения какой-либо переменной, что может существенно осложнить работы, связанные с модификацией программы.

Кроме метрик сложности программ, используются метрики стилистики и понятности программ. Наиболее простой метрикой стилистики и понятности программ является оценка уровня комментированности программы

`F` :`F=N(kom)/N(ctr)`

где N(com) - количество комментариев в программе; N(ctr)- количество строк или операторов исходного текста.

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

К другим характеристикам программ следует отнести:

*состав функций обработки информации, определенный функциональными требованиями к программной системе;

*объем файлов, используемых программной системой;

*требования к операционной системе и компьютерной технике и др.

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

*Существует большое количество различных компаний, занимающиеся разработкой проприетарного программного обеспечения (proprietary software). Этим термином обозначают программное обеспечение, которое имеет собственника, осуществляющего контроль над этим программным обеспечением и определяющего собственные лицензионные соглашения по использованию программного продукта. Наиболее типичными ограничениями проприетарного ПО являются:

*1. ограничение на коммерческое использование. Существует большое количество проприетарных программных продуктов, которое можно использовать бесплатно в некоммерческих целях для частных лиц, медицинских и учебных заведений, для некоммерческих организаций и т.д. Такое программное обеспечение очень популярно и широко используется, а за счет своей бесплатности имеет хорошую техническую поддержку со стороны специалистов, у которых отсутствует необходимость дополнительных затрат на обучение;

*2. ограничение на распространение. Этот вид ограничений сопровождает обычно крупные программные проекты, когда правообладатель требует оплаты за каждую копию программы. Обычно с таким ограничением применяются программные продукты, ориентированные на узкий "профессиональный" сегмент рынка, или программное обеспечение, требующееся большому числу пользователей. Примером может служить пакет программ Adobe CS3 или операционная система Microsoft Windows XP;

*3. ограничение на модификацию. Этот вид ограничения используется только в программных пакетах с закрытыми исходными кодами и может запрещать или ограничивать любую модификацию программного кода, дизассемблирование и декомпиляцию.

*В настоящее время существуют и другие варианты легального распространения программных продуктов, которые появились с развитием Интернета:

*1. freeware - бесплатные, свободно распространяемые программы. Очень много серьезных компаний писали, пишут и будут писать freeware-программы. Дело в том, что freeware - прекрасный инструмент в продвижении новых технологий и продуктов. Например, всем известна программа общения ICQ. Это популярный бесплатный продукт, который имеет очень сильные позиции в сравнении с платными программами. Некоторые shareware-программы становятся бесплатными. Всем известный мультимедиа-проигрыватель Winamp первоначально был shareware-программой стоимостью в $10. Однако, после того как сайт winamp.com стал привлекать большое количество посетителей, разработчики, получая солидные доходы от рекламы, решили сделать свой продукт бесплатным, еще надежнее увеличив рост его популярности и своих доходов;

*2. shareware - условно-бесплатные программы. Употребляется и еще одно наименование этого типа ПО - "пробное" (trial). Основное достоинство shareware - "попробуй, прежде чем купить" (try before you buy). Пользователю предоставляется продукт с некоторыми ограничениями, "на пробу", пока он его не приобретет. Ограничения могут быть функциональными и/или временными (чаще всего программа работает 30 дней или определенное количество запусков). Если пользовать решает, что это программа ему нужна, он должен зарегистрироваться, заплатив автору определенную сумму, в противном же случае обязан прекратить использование программы и удалить ее со своего компьютера;

*3. public domain software - очень похожие на freeware программы. Распространяются бесплатно. Однако, в отличие от freeware, где автор программы имеет все права на программу, в случае с public domain у него эти права отсутствуют. Программа распространяется вместе с исходным кодом, и автор отказывается от своих прав. Главной идеей было развитие программы в дальнейшем. Однако в силу того, что программа была "ничья", кто угодно мог слегка модифицировать код, откомпилировать и распространять ее как платную. По этой причине таких программ в настоящее время просто не найти;

*4. open source. Представляет собой развитие концепции public domain software, в которой учтены ошибки этого варианта. Программа, как и раньше, распространяется на бесплатной основе вместе с исходным кодом. Однако автор уже не отказывается от своих прав. Существует система требований к лицензии на программный продукт, который называется The Open Source Definition (OSD), которая представлена на сайте. К программе обязательно должен быть приложен исходный код. Модифицированное ПО должно распространяться на тех же условиях, что и исходный продукт. Автор исходного продукта даже имеет право требовать, чтобы исходный код его программы распространялся без изменений, но в комплекте с соответствующими модифицирующими исправлениями.

*Существуют и другие, можно сказать, экзотические варианты распространения программ. Например:

*1. adware. К этой категории относятся программы, которые во время своей работы демонстрируют пользователю рекламу, обычно графические баннеры размером 468x60 точек. Adware сочетает в себе freeware и shareware. С одной стороны, пользователь не обязан оплачивать программу и может ею пользоваться сколь угодно долго; с другой - у него есть стимул оплатить программу, ведь в этом случае он избавится от баннера, который так долго его нервирует. Наибольшее развитие этот тип получил в программах, которые работают в Интернете, ведь именно оттуда скачивается новая реклама. Например: браузеры, download-менеджеры и программы дозвона;

*2. donationware. Такое ПО также распространяются бесплатно, однако разработчик программы в лицензионном соглашении указывает, что если пользователю программа нравится, то он может (а не обязан) выслать денежное вознаграждение. К сожалению, как показывает практика, пользователи очень вяло реагируют на такие просьбы и очень редко высылают деньги.

*Ряд производителей использует OEM-программы (Original Equipment Manu-facturer), т.е. встроенные программы, устанавливаемые на компьютеры или поставляемые вместе с компьютером.

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

Настройка схем управления питанием

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

По умолчанию Windows® 7 и Windows Server® 2008 R2 предоставляют три схемы управления питанием: сбалансированная, энергосберегающая и с высокой производительностью. Эти схемы можно настроить для имеющихся систем или создать новые на основе существующих. Чтобы создать схему управления питанием, наилучшим образом подходящую для определенной системы, поэкспериментируйте с различными параметрами, а затем протестируйте итоговую производительность.

Общие настраиваемые параметры, влияющие на срок службы батареи

Параметры могут зависеть от варианта работы компьютера: от электросети (AC) или от батарей (DC). Можно настроить следующие параметры.

*Яркость экрана

Уменьшение яркости экрана является самым эффективным способом сокращения энергопотребления мобильным компьютером при включенном экране. Дисплей портативного компьютера потребляет наибольшее количество энергии - для него требуется до 40 процентов общего объема электроэнергии, предназначенного для системы. По умолчанию Windows значительно уменьшает яркость экрана, когда мобильный компьютер работает от батареи. В зависимости от оборудования и потребностей пользователей можно установить более низкое значение параметра яркости экрана по умолчанию, чтобы продлить срок работы батареи, или задать более высокое значение, чтобы облегчить чтение с экрана.

*Уменьшение яркости экрана

По умолчанию портативные компьютеры, работающие под управлением Windows® 7 и Windows Server® 2008 R2, настроены на уменьшение яркости экрана после определенного периода бездействия. Этот процесс предшествует действию, называемому Время ожидания выключения экрана, когда экран выключается полностью. Таким образом можно сэкономить немалое количество электроэнергии для периодически используемого портативного компьютера.

*Время ожидания выключения экрана

Срок службы батареи портативного компьютера может быть значительно продлен за счет сокращения тайм-аута простоя.

*Время ожидания выключения жесткого диска

Хотя жесткий диск (HDD) не является основным потребителем электроэнергии в обычных мобильных ПК, для экономии энергии можно увеличить время ожидания выключения жесткого диска. Если жесткий диск некоторое время находится в состоянии простоя, его двигатель остановится. При следующем доступе компьютера к жесткому диску время отклика системы может увеличиться, поскольку жесткий диск снова начинает набирать скорость.

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

*Спящий режим

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

*Режимы экономии энергии беспроводного адаптера

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

Если для дополнительной экономии электроэнергии и продления срока работы батарей создаются настраиваемые политики энергопотребления, проконсультируйтесь с производителем беспроводного оборудования по поводу результатов изменения значения политики энергопотребления наМаксимальное энергосбережение или Среднее энергосбережение. Параметры питания для каждой встроенной конфигурации питания можно изменить вручную. Дополнительные сведения об этих параметрах и других общих настраиваемых параметрах питания см. в статье Мобильные решения в области срока службы батареи. Руководство для профессионалов по разработке мобильных платформ (может быть на английском языке). Оптимизация использования памяти может преследовать две цели - увеличение объема памяти, доступной приложениям, и повышение быстродействия обращений к памяти. На старых машинах, когда объем установленной физической памяти не превышал единиц мегабайт, зачастую приходилось чем-то жертвовать; в современных системах достижение обеих целей уже не противоречит друг другу. Нет сомнений в том, что, чем больше установленный объем ОЗУ, тем лучше - компьютер будет мощнее: он позволит загружать приложения, особо «жадные» до памяти; увеличить число одновременно работающих приложений (в многозадачной ОС); ускорить работу. Однако для обеспечения возможности использования памяти в ряде случаев требуются некоторые дополнительные действия по конфигурированию компьютера.

...