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

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

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

При создании и развитии ПО рекомендуется применять следующие общесистемные принципы^[15]:

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

2) Принцип системного единства (на всех стадиях создания, функционирования и развития ПО, его целостность будет обеспечиваться связями между подсистемами, а также функционированием подсистемы управления);

3) Принцип развития (предусматривающий в ПО возможность его совершенствования и наращивания компонентов и связей между ними);

4) Принцип комплексности (ПО обеспечивает связанность обработки информации как отдельных элементов, так и всего объема данных в целом на всех стадиях обработки);

5) Принцип информационного единства (во всех компонентах ПО подсистемах, средствах обеспечения используются единые термины, условные обозначения, символы, способы представления);

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

7) Принцип инвариантности (компоненты подсистемы ПО инвариантны к обрабатываемой информации, являются типовыми или универсальными).

Томас Кун в 1977 г. определил термин «парадигма» как свод норм научного мышления. Парадигма — это правило развития научного знания. Оно в течение определенного времени дает научному сообществу модель постановки проблем и их решений.^[16]

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

В программировании существуют различные концепции языков (парадигмы), которые при написании программ могут приводить как к радикально различным подходам так к одним и тем же^[18]. Для ряда языков необходим свой тип мышления, особая школа обучения, особые технологии разработки. Множество программистов в рамках одной парадигмы используют в работе один-два языка программирования. Бывает программисту трудно понять чужую программу, реализованную в парадигме непривычной для него. В противовес изменению цели проекта под используемый язык в ряде проектных случаев рационально избрать иной язык программирования.^[19]

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

Список основных парадигм программирования вместе с присущими им видами абстракций^[20]:

• Процедурно-ориентированные - алгоритмы;
• Объектно-ориентированные - классы и объекты;
• Логически-ориентированные - цели, выраженные в исчислении предикатов;
• Ориентированные на правила - правила «если…, то…»;
• Ориентированные на ограничения - инвариантные соотношения;
• Параллельное программирование - потоки данных.

Существуют и другие парадигмы. Много их потому, что программирование - новая дисциплина и отчасти - из-за желания решать разные задачи. В настоящее время проводится большое число экспериментов с машинами, имеющими нестандартные архитектуры, многие из которых рассчитаны на применение других парадигм программирования, например числа Фибоначчи^[21]. Природа ЭВМ позволяет с большей или меньшей эффективностью моделировать одну архитектуру с помощью другой. Из архитектур наиболее удачны в которых за счет аппаратуры и программного обеспечения достигнута простота и наивысшая скорость использования.

Невозможно назвать какую-либо парадигму наилучшей во всех областях практического применения.^[22] Для проектирования баз знаний более пригодна парадигма, ориентированная на правила. Объектно-ориентированная парадигма является наиболее приемлемой для широкого круга задач, связанных с большими промышленными системами, в которых основной проблемой является сложность.

• 1. Стандарты программирования

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

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

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

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

Необходимо также отметить стандарты ISO^[25].

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

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

2. ОПТИМИЗАЦИЯ ПРОГРАММНЫХ РАЗРАБОТОК

2.1. Выбор оптимального проектного решения

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

В условиях неполной информации об объекте проектирования, есть возможность ошибочных решений. Поэтому в такой ситуации лицо, принимающее решение (ЛПР^[27]), должно вырабатывать такую стратегию в отношении принятия решений, которая не исключает возможность принятия неправильных решений, но сводит к минимуму связанные с этим нежелательные последствия. Для уменьшения неопределенности ЛПР может провести эксперимент, но это требует больших затрат времени и это дорого. Поэтому ЛПР должно принять решение о форме, времени, уровне эксперимента.^[28]

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

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

• наличие целей (показателей) оптимальности;
• альтернативных вариантов проектируемого объекта;
• учет существенных факторов при проектировании.

Понятие "оптимальное решение^[29]" в проектировании имеет определенное толкование - лучшее в том или ином смысле проектное решение, допускаемое обстоятельствами. В большинстве случаев проектная задача может быть решена несколькими способами, приводящими не только к различным выходным характеристикам, но и классам программ.

Самые универсальные программы - текстовые редакторы^[30], допускающие использование графики. Они позволяют производить вывод на печать, оформлять исходные данные, осуществлять ручной набор обоснования решения с результатами расчета. Для некоторых целей более удобны электронные таблицы. Многих пользователей вполне устраивают интегрированные системы, включающие текстовый процессор, электронных таблиц, процессор графические процессоры (рисунков и деловой графики), систему управления базой данных^[31] (СУБД), системы сетевой и модемной связи пользователей. При этом одно из решений может превосходить остальные по одним показателям и уступать по другим. Может оказаться что разные решения характеризуются разным набором показателей. В этих условиях трудно сказать, какая программная система оптимальна, даже трудно указать какая предпочтительнее.

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

База знаний совокупностей показателей должна состоять как из общих (общепрограммных), так и специальных (предметно-ориентированных^[32]) показателей.

В настоящее время используют следующие классификации показателей^[33]:

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

2) Показатели надежности (характеризующие свойства программной системы сохранять во времени свою работоспособность);

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

4) Эргономические показатели (характеризующие систему человек - изделие - среда и учитывающие комплекс психических, антропологических, физиологических, гигиенических и психических свойств человека, проявляющихся в бытовых и производственных условиях);

5) Эстетические показатели (характеризующие внешние свойства системы: выразительность, оригинальность, целостность, гармоничность, соответствие стилю и среде);

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

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

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

Среда проекта характеризуется:

• возможностями капиталовложения
• возможностями коллектива-производителя
• научно-техническими достижениями
• социальной и природной средой

2.2. Анализ требований к системе (системный анализ) и формулировка целей

Задача оптимизации разработки программ состоит в достижении целей при минимально возможной затрате ресурсов.

Системный анализ в отличие от предварительного системного исследования - это углубленное изучение информационных потребностей пользователей, которое будет положено в основу детального проектирования новой автоматизированной системы^[34] (АС^[35]).

Конечный продукт данного этапа - набор выполняемых функций, или функциональные требования, т.е. документированная постановка системных требований к новой АС^[36]. Когда речь идет о создании большой системы, этот документ представляет собой отчет о системном анализе, который осуществляется по этапам, показанным на рис. 1.