Учебное пособие по информатике 2014. Основы информатики
 Скачать 4.61 Mb.
|
|
C# C# (C Sharp, Си шарп) - простой, современный, объектно- ориентированный язык с безопасной системой типов, происходящий от С и С++. С# будет удобен и понятен для программистов, знающих С и С++. С# сочетает продуктивность Visual Basic и мощность С++». Переняв многое от своих предшественников — языков C++, Java, Delphi, Модула и Smalltalk — С#, опираясь на практику их использования, исключает некоторые модели, зарекомендовавшие себя как проблематичные при разработке программных систем, например, C# в отличие от C++ не 55 поддерживает множественное наследование классов (между тем допускается множественное наследование интерфейсов). Пример программного кода: using System; using System.Collections.Generic; using System.Linq; using System.Text; namespace p { class Program { static void Main(string[] args) { string str = "FlkjsdfSdsfA"; Console.WriteLine(str); for (int i = 0; i < str.Length; i++) if (char.IsUpper(str[i])) Console.WriteLine("{0} в верхнем регистре ", str[i]); } } } Java Java - объектно-ориентированный язык программирования, разработанный компанией Sun Microsystems (позже приобретённой компанией Oracle). Дата официального выпуска — 23 мая 1995 года. Программы на Java транслируются в байт-код, выполняемый виртуальной машиной Java (JVM) — программой, обрабатывающей байтовый код и передающей инструкции оборудованию как интерпретатор. Достоинство подобного способа выполнения программ — в полной независимости байт-кода от операционной системы и оборудования, что позволяет выполнять Java-приложения на любом устройстве, для которого существует соответствующая виртуальная машина. Другой важной особенностью технологии Java является гибкая система безопасности благодаря тому, что исполнение программы полностью контролируется виртуальной машиной. Любые операции, которые превышают установленные полномочия программы (например, попытка несанкционированного доступа к данным или соединения с другим компьютером) вызывают немедленное прерывание. Пример программного кода: import java.io.*; // This is a simple program called HelloWorld.java class HelloWorld { public static void main(String args[ ]) { System.out.println( Welcome to the world of Java ); } } 56 2.7 Жизненный цикл программного обеспечения Жизненный цикл программного обеспечения включает в себя шесть этапов: анализ требований, определение спецификаций, проектирование, кодирование, тестирование, сопровождение. Рассмотрим их. Анализ требований. При разработке программного обеспечения он исключительно важен. Ошибки, допущенные на этом этапе, даже при условии безупречного выполнения последующих этапов могут привести к тому, что разработанный программный продукт не будет соответствовать требованиям практики, сферы его применения. Для создания конкурентоспособных продуктов в ходе выполнения этого этапа должны быть получены четкие ответы на следующие вопросы: Что должна делать программа? В чем состоят реальные проблемы, разрешению которых она должна способствовать? Что представляют собой входные данные? Какими должны быть выходные данные? Какими ресурсами располагает проектировщик? Определение спецификаций. В определенной степени этот этап можно рассматривать как формулировку выводов, следующих из результатов предыдущего этапа. Требования к программе должны быть представлены в виде ряда спецификаций, явно определяющих рабочие характеристики будущей программы. В число таких характеристик могут входить скорость выполнения, объем потребляемой памяти, гибкость применения и др. Проектирование. На этом этапе создается общая структура программы, которая должна удовлетворять спецификациям; определяются общие принципы управления и взаимодействия между различными компонентами программы. Кодирование. Заключается в переводе на язык программирования конструкций, записанных на языке проектирования. Тестирование. На этом этапе производится всесторонняя проверка программ. Тестирование более подробно рассмотрено ниже. Сопровождение. Это этап эксплуатации системы. Каким бы изощренным не было тестирование программ, к сожалению, в больших программных комплексах чрезвычайно тяжело устранить абсолютно все ошибки. Устранение обнаруженных при эксплуатации ошибок - первейшая задача этого этапа. Однако это далеко не все, что выполняется при сопровождении. Выполняемый в ходе сопровождения анализ опыта 57 эксплуатации программы позволяет обнаруживать «узкие места» или неудачные проектные решения в тех или иных частях программного комплекса. В результате такого анализа может быть принято решение о проведении работ по совершенствованию разработанной системы. Кроме описанного выше, сопровождение может включать в себя проведение консультаций, обучение пользователей системы, оперативное снабжение пользователей информацией о новых версиях системы и т.п. Качественное проведение этапа сопровождения в большой степени определяет коммерческий успех программного продукта. Рассмотрим этап тестирования программ более подробно. Существуют три аспекта проверки программы на: правильность; эффективность реализации; вычислительную сложность. Проверка правильности удостоверяет, что программа делает в точности то, для чего она была предназначена. Математическая безупречность алгоритма не гарантирует правильности его перевода в программу. Аналогично, ни отсутствие диагностических сообщений компилятора, ни разумный вид получаемых результатов не дают достаточной гарантии правильности программы. Как правило, проверка правильности заключается в разработке и проведении набора тестов. Кроме этого, для расчета программ иногда можно сверить получаемые решения с уже известным решением. Таким образом, нельзя дать общего решения для проведения проверки на правильность программы. Проверка вычислительной сложности, как правило, заключается в экспериментальном анализе сложности алгоритма или экспериментальном сравнении двух алгоритмов и более, решающих одну и ту же задачу. Проверка эффективности реализации направлена на отыскание способа заставить правильную программу работать быстрее или расходовать меньше памяти. Чтобы улучшить программу, пересматриваются результаты реализации в процессе построения алгоритма. Не рассматривая все возможные варианты и направления оптимизации программ, приведем здесь некоторые полезные способы, направленные на увеличение скорости выполнения программ. Первый способ основан на следующем правиле. Сложение и вычитание выполняются быстрее, чем умножение и деление. Целочисленная арифметика быстрее арифметики вещественных чисел. Таким образом, Х+Х лучше, чем 2Х, а i+0,5j хуже, чем (2i+j) 0,5 или (i+i+j) 0,5. При выполнении операций над целыми числами следует помнить, что благодаря применению двоичной системы счисления умножение на числа, кратные двум, можно заменить соответствующим количеством сдвигов влево. Второй способ заключается в удалении избыточных вычислений. Третий способ проверки эффективности реализации основан на способности некоторых компиляторов строить коды для вычисления 58 логических выражений так, что вычисления прекращаются, если результат становится очевидным. Например, в выражении A or В or С, если А имеет значение «истина», то переменные В и С уже не проверяются. Таким образом, можно сэкономить время, разместив переменные А, В, С так, чтобы первой стояла переменная, которая вероятнее всего будет истинной, а последней та, которая реже всего принимает истинное значение. Четвертый прием - исключение циклов. Пятый прием - развертывание циклов. Это далеко не полный перечень способов оптимизации. Здесь приведены лишь самые очевидные из них. Следует, кроме того, заметить, что не всегда стоит увлекаться погоней за быстродействием, так как при этом чаще всего ухудшается удобочитаемость программ. В том случае, когда выигрыш получается «мизерный», вряд ли стоит предпочитать его ясности и читабельности программы. 2.8 Основы технологии разработки программ Необходимо кратко коснуться части процесса проектирования программы [19]: - язык программирования, как таковой, не имеет отношения к процессу написания программ (и можно даже прийти к выводу о практической бесполезности многочисленной литературы по системам программирования); - любая технология программирования имеет отношение прежде всего к формальной стороне проектирования. Так, структурное программирование предполагает последовательное движение от внешних программных конструкций к внутренним, но откуда берутся эти конструкции – не говорит; - программы не создаются из набора заготовок путем их механического или случайного соединения. Даже если известны составные части программы, в какой последовательности их соединять? Образная и логическая стороны программирования Поднятые выше вопросы останутся без ответа, если ограничиться формальной стороной процесса т.е. исключительно технологией программирования. Но в самом начале на любом шаге проектирования программы имеют место элементы образного представления программы. Попробуем взглянуть на все это с максимально широких позиций. Мыслительная и творческая деятельность человека имеет две формы: образно-художественную и формально-логическую. Есть основания связывать их с различием функционирования правого (образного) и левого (логического) полушария головного мозга. Инженерному и научному подходам ближе формально-логическое мышление: здесь человек оперирует ограниченным числом четко отделенных друг от друга объектов на основе строгих формальных или логических законов. Наоборот, образ является 59 неделимой сущностью и всегда воспринимается как единое целое. Манипулирование над образом состоит в непосредственном «видении» процесса его изменения. К образному мышлению относятся также такие понятия как интуиция, опыт, аналогия и т.п.. Хотя образное мышление традиционно воспринимают как составляющую художественного творчества и необходимый элемент гуманитарных наук, в технических и технологических отраслях он тоже является важным элементом. Вообще, без него невозможно получение нового знания, ибо любая формальная система допускаем манипулирование только в собственных рамках, что, естественно, ограничивает ее сверху. В процессе разработки программы образная сторона заключается в представлении программы в виде целостной «движущейся картинки», из которой очевидно, как выполняется процесс, приводящий к результату. Словесные формулировки алгоритма типа «переместить выбранный элемент к концу массива» уже сочетают в себе образное и формально-логическое (алгоритмическое) описание действия. Следовательно, программирование – это движение в направлении от образной модели к словесным формулировкам составляющих действий, а уже затем к формальной их записи на языке программирования[19]. Рисунок 2.2 – Образное программирование на бумаге – залог успеха проектирования программы Попробуем более подробно определить составляющие этого процесса. 1. Результат работы программы. Целью выполнения любой программы является получение результата, а результат – это данные с определенными свойствами. Например, целью программы сортировки является создание 60 последовательности из имеющихся данных, расположенных в порядке возрастания. Точно так же любой промежуточный шаг программы имеет свою цель: получить данные с нужными свойствами в нужном месте. Как правило, постановка задачи начинается с формулировки результата. Для простого случая он может быть задан в самой постановке задачи, а в сложных случаях, особенно если речь идет о заказчике, не очень хорошо владеющим формальной стороной проблемы, его требования к исполнителю (программисту) могут звучать как «Сделайте мне красиво». 2. Образная модель программы. Формальное проектирование программы не продвинется ни на шаг, если программист «не видит», как это происходит. То есть первоначально действующая модель программы должна присутствовать в голове. Понятно, что к формальной логике это не имеет никакого отношения. Это – область образного мышления, (правого полушария). Изобразительные средства здесь уместны любые – словесные, графические. Здесь работают интуиция, аналогия, фантазия и другие элементы творческого процесса. На этом уровне справедлив тезис, что программирование – это искусство. Насколько подробно программист «видит» модель в движении и насколько он способен описать это словами – настолько он близок к следующему этапу проектирования. 3. Факты, касающиеся программы. Формальная сторона проектирования начинается с перечисления фактов, касающихся образной модели программы. К таковым относятся: переменные и их смысловая интерпретация, известные программные решения и соответствующие им стандартные программные контексты. Сразу же надо заметить, что речь идет не об окончательных фрагментах программы, а о фрагментах, которые могут войти в готовую программу. Иногда при их включении потребуется доопределить некоторые параметры (например, границы выполнения цикла, которые не видны на этапе сбора фактов). Иногда они могут быть эквивалентно преобразованы (то есть иметь другой синтаксис). Умение видеть в алгоритме известные частные решения тоже приобретается с опытом: для этого и нужно учиться «читать» программы. По поводу этого пункта следует указать на важнейшую роль в этом процессе естественного языка (речи). Человек мыслит образами, а речь его представляет собой уже формально-логическую структуру. Она состоит из отдельных единиц – слов, их взаимосвязь – синтаксис и смысл – семантика, также подчинены определенным законам. Понятно, что естественный язык многообразен, словами в нем могут быть выражены как образные (например, поэзия), так и формально-логические системы (например, математика). Для программирования как раз важно, что переход от образной модели к ее известным составляющим состоит в словесных формулировках. Если Вы не способны сформулировать свои образные представления о процессе работы программы в виде словесных формулировок отдельных действий, дальше двигаться бесполезно. Поэтому вопреки науки о том, что этого пока нельзя сделать, программирование уже давно ведется на естественном языке! 61 4. Выстраивание программы из набора фактов. Эта часть процесса программирования вызывает наибольшие затруднения, ибо здесь начинается то, что извне обычно и воспринимается как «программирование»: написание текста программы. Особенность заключается в том, что обычно фрагменты взаимосвязаны друг с другом прямо по структуре алгоритма или косвенно через данные. Различие подходов состоит в том, в какой последовательности в программу включаются фрагменты (по отношению к гипотетической готовой программе), с какой стороны начать этот процесс и в каком направлении двигаться[19]. «Историческое» проектирование соответствует естественному ходу рассуждений по линии наименьшего сопротивления. Программист просто записывает очередной оператор, который по его мнению должен выполняться программой в процессе ее работы. Ошибочность такого принципа состоит в том, что текст программы и последовательность ее выполнения - это не одно и то же и расхождение между ними рано или поздно обнаружится. Хорошо, если это случится, когда большая часть программы уже написана, и проблема будет скорректирована несколькими «заплатками» в виде операторов goto. Заметим, что «историческим» подходом грешат не только программы, но и любые другие структурированные тексты (например, курсовая работа, диплом, диссертация), если автор не уделяет должного внимания логике их построения. Восходящее проектирование – проектирование программы «изнутри», от самой внутренней конструкции к внешней. Привлекательность этого подхода обусловлена тем, что внутренние конструкции программы - это частности, которые всегда более «на виду», чем внешние конструкции, реализующие обобщенные действия. Частности составляют большую часть фактов в образной модели программы и, что самое ценное, могут быть непосредственно записаны на языке программирования. Поэтому программа в процессе своего написания не нуждается, как и в «историческом» подходе, в иных средствах описания, кроме самого языка программирования. Недостатки тоже очевидны: - не факт, что программу удастся «свести» в единое целое, особенно сложную; - поскольку параметры внутренних конструкций могут зависеть от внешних (например, диапазон поиска минимального значения во внутреннем цикле зависит от шага внешнего цикла), то внутренние конструкции - не есть «истины в последней инстанции» и по мере написания программы тоже должны корректироваться. Нисходящее (структурное) проектирование - проектирование программы, начиная с самой внешней ее конструкции. Самое трудное, но самое правильное движение в направлении от общего к частному. Первая трудность заключается в неочевидности выбора самой внешней (общей, объемлющей) конструкции – частности всегда виднее. Вторая, менее 62 очевидная: ненаписанная часть программы (внутреннее содержимое конструкции) также должна быть сформулирована в общем виде, т.е. словесно. Отсюда следует, что нисходящее проектирование должно сочетать в тексте программы формальное (то есть записанное на языке программирования) и неформальное (то есть словесное или даже образное) представление. «Грязное» программирование – заключается в создании макета, воспроизводящего основные свойства проектируемой программы. В дальнейшем все изменения/дополнения сохраняют эти первоначальные соотношения. 5. Последовательное приближение к результату. Сложную программу не всегда удается спроектировать за один этап. Цикл «результат – образная модель – факты – выстраивание программы» может повторяться. При выстраивании программы может оказаться, что ненаписанная часть программы нуждается в дополнительном осмыслении, начиная с образной модели. При этом само направление выстраивания программы, т.е. собственно технология программирования, имеют большое значение: она в большей или меньшей степени гарантируется правильность и неприкосновенность уже написанного. Кратко рассмотрим упомянутые ранее методики[19]. «Историческое» проектирование – естественный подход к проектированию. Первое, что приходит в голову при старте разработки программы – записывать последовательность действий в проектируемом алгоритме в том порядке, в котором они будут выполняться в программе. «Историческому» принципу проектирования также наиболее соответствует структурная схема алгоритма. К этому есть несколько причин: - «рисование» блок-схемы идет в виде волны: разработчик каждый раз решает в контексте текущего состояния, что же делать дальше, при наличии условий процесс проектирования становится параллельным: каждую ветку можно вести независимо от другой; - циклы возникают естественным образом, при возникновении ощущения, что следующая последовательность действий уже встречалось в программе, следует сделать переход к этой части программы (обратная связь цикла). При этом необходимо проверить и другие составляющие возникающего цикла: условия завершения (или продолжения), переход к следующему шагу. Возможно, что придется переделать уже «нарисованный» фрагмент – он был спроектирован без учета возникшего цикла. Структурное программирование – от общего к частному. Технология структурного программирования в самой краткой формулировке есть нисходящее проектирование, т.е. выстраивание текста программы, точнее алгоритмической компоненты, от общего к частному, от внешней конструкции к внутренней. Естественно, что надо знать, из чего выстраивать. В идеале у опытного программиста действительно очередная 63 нужная конструкция появляется «из головы». Но это не значит, что он не имеет общего плана действий и обобщенного представления процесса, который реализуется проектируемой программой. 1. Исходным состоянием процесса проектирования является более или менее точная формулировка цели алгоритма, или результата, который должен быть получен при его выполнении. Формулировка, само собой, производится на естественном языке. 2. Создается образная модель происходящего процесса, используются графические и какие угодно способы представления, образные «картинки», позволяющие лучше понять выполнение алгоритма в динамике; 3. Выполняется сбор фактов, касающихся любых характеристик алгоритма, и попытка их представления средствами языка. Такими фактами является наличие определенных переменных и их «смысл», а также соответствующих им программных контекстов. Понятно, что не все факты удастся сразу выразить в виде фрагментов программы, но они должны быть сформулированы хотя бы на естественном языке; 4. В образной модели выделяется наиболее существенная часть – «главное звено», для которой подбирается наиболее точная словесная формулировка; 5. Производится определение переменных, необходимых для формального представления данного шага алгоритма и формулируется их «смысл»; 6. Выбирается одна из конструкций - простая последовательность действий, условная конструкция или цикл. Составные части выбранной формальной конструкции (например, условие, заголовок цикла) должны быть переписаны в словесной формулировке в виде цели или результата, которые должны давать эти части алгоритма. 7. Для оставшихся неформализованных частей алгоритма (в словесной формулировке) - перечисленная последовательность действий повторяется. Обычно разработка образного представления программы опережает ее «выстраивание», поэтому следующим этапом для неформализованной части алгоритма может быть п.4 (в лучшем случае, при его проработке в образной модели) или п.1-3. В любом случае для вложенных конструкций мы возвращаемся на предыдущие этапы проектирования[19]. Неправильное программирование – грязное. Под «грязным» программированием обычно понимается написание программы, грубо воспроизводящей требуемое поведение. Такая программа может быть быстро разработана и отлажена, а затем использована для уяснения последующих шагов, либо для наложения «заплаток» с целью получения требуемого результата. Хотя этот подход крайне некрасив с точки зрения технологии проектирования, но он может быть оправдан при следующих условиях: - «грязная» программа воспроизводит требуемое поведение на самом верхнем уровне; 64 - в дальнейшем в нее могут встраиваться контексты и фрагменты, не меняющие ее поведения, но конкретизирующие ее в нужном направлении. Наконец, необходимо сказать несколько слов о «среде обитания» программы. Каждая конструкция языка не просто встраивается в программу, а определяет свойства используемых ею данных, «смысл» переменных, которые появились в программе одновременно с ней. Поэтому при использовании исключительно вложенных конструкций мы получим в каждой точке программы определенный набор выполняемых условий, своего рода «среду обитания» алгоритма. Эти переменные являются исходными данными для очередного шага детализации алгоритма. Рисунок 2.3 – «Среда обитания» программы Почему крайне не рекомендуется использовать при программировании оператор goto (оператор безусловного перехода)? Нисходящее пошаговое проектирование исключает использование оператора goto, более того, запрещает его применение как нарушающего структуру программы. Goto страшен не тем, что «неправильно» связывает разные части алгоритма, а в том, что переводит алгоритм из одних «условий обитания» в другие: в точке перехода они составлены без учета того, что управление будет передано в точку программы «не по правилам». Тем не менее, есть допустимые случаи использования оператора goto. Чрезвычайными обстоятельствами, вынуждающими прибегнуть к помощи оператора goto, являются глобальные нарушения логики выполнения программы, например грубые неисправимые ошибки во входных данных. В таких случаях делается переход из нескольких вложенных конструкций либо в конец программы, либо к повторению некоторой ее части. В других обстоятельствах его использование свидетельствует скорее о неправильном проектировании структуры программы - наличии неявных условных или циклических конструкций. Приведем пример достаточно разумного использования оператора goto. |