Файл: Основы проектирования программ. Этапы создания программного обеспечения(Основы проектирования программ).pdf

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

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

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

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

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

При исследовании систем решаются задачи анализа и синтеза.

Анализ (от греч. analysis— разложение, расчленение) - прием умственной деятельности, связанный с мысленным (или реальным) расчленением на части предмета, явления или процесса.

Синтез (от греч. synthesis— соединение, сочетание, составление) - метод научного исследования явлений действительности в их единстве и целостности, во взаимодействии их частей, обобщение, сведение в единое целое.

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

В теории проектирования используются следующие понятия анализа и синтеза.

Анализ —процесс определения функционирования по заданному описанию системы.

Синтез— процесс построения описания системы по заданному функционированию.

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

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

Программный продукт является разработанной программистом информационной технологией, которая материализуется у заказчика в виде изделия, становясь автоматизированными системами и инструментами их обслуживания. Это объяснение, по-видимому, снимает многие правовые проблемы, а также проблемы ценообразования. В каждой программе есть свои особенности и один человек много об этом пишет, давайте рассмотрим, Томас Кун в 1977г. определил термин «парадигма» как свод норм научного мышления. Парадигма — это правило (modus operandi) развития научного знания. Оно в течение определенного времени дает научному сообществу модель постановки проблем и их решений.

Когда та или иная методология применяется во время стадии кодирования (реализации), очень часто ее называют парадигмой программирования — способом мышления в программировании.

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

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

—процедурно-ориентированные — алгоритмы;

—объектно-ориентированные — классы и объекты;

—логически-ориентированные — цели, выраженные в исчислении предикатов;

—ориентированные на правила — правила «если…, то…»;

—ориентированные на ограничения — инвариантные соотношения;

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

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

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

Группа стандартов ГОСТ «Единая система программной документации» (ЕСПД) претерпела мало изменений с момента ее создания, пережила несколько поколений ЭВМ и революционных изменений технологий разработки программ. При этом она до настоящего времени никогда не затрудняла новаций.

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

В области программирования общепризнанной ведущей организацией по разработке стандартов является институт ANSI (Американский национальный институт стандартов). Данный институт является лидером по установке стандартов языков программирования, кодовых таблиц клавиш и символов, выводимых на экран, и еще многих других. Необходимо также отметить стандарты ISO.

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

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

В заключительной части этой главы рассмотрим жизненный цикл программы

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

Жизненный цикл —совокупность взаимосвязанных процессов создания и последовательного изменения состояния продукции от формирования к ней исходных требований до окончания ее эксплуатации или потребления.

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

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

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