Cтраница 1
Проектирование программы и доказательство ее правильности проводятся параллельно независимо от того, основывается ли такое доказательство лишь на здравом смысле, или требует построения систематических трассировочных таблиц. Предпочтение следует отдавать проекту, который легко проверить. При анализе путей реализации очередного шага процесса совершенствования вначале для заданной функции мысленно подбираются аргументы для проверки правильности. Программист должен уметь не только записать, но и читать свою программу, поставив себя на место человека, которому предстоит разобраться в результатах проделанной им работы. Поэтому, если чтение программы затруднительно, а доказательства правильности ее частей не очевидны, следует более тщательно продумать свою программу, поскольку всегда существует вероятность того, что можно получить более простую, а следовательно, и более ценную программу. [1]
Проектирование программы должно ответить на вопросы стиля программирования, эффективности, тестирования, отладки и сопровождения. Попытки решения этих вопросов являются важной частью разработки любого продукта ПО. Однако в проектировании ПО это как раз именно та область, где рекомендации для одного проекта или программиста не всегда подходят для других программистов или проектов. [2]
Проектирование программы осуществляется параллельно с созданием прототипа. Когда определена архитектура системы, аппаратные и программные средства ее разрабатываются параллельно, и взаимодействие между группами разработчиков становится по мере завершения проекта все более тесным. С помощью кросс-ассемблеров, моделирующих программ и законченных систем проектирования микро - ЭВМ ( СПМ) можно отладить почти всю программу. [3]
Для проектирования программ управления МПС требуется целый комплекс специальных программ, который косит название Средства разработки программного обеспечения. Существующие средства разработки ПО, как правило, ориентированы на конкретную серию МП и на определенный класс средств вычислительной техники. В настоящее время для разработки прикладного ПО широко используются персональные ЭВМ ( ПЭВМ) фирмы IBM и совместимые с ними. Существует большое число пакетов программ для разработки ПО МПС, которые используют в качестве входного как языки Ассемблера, так и языки высокого уровня. Реализованное на ПЭВМ ПО для большинства типов МП является кроссовым, исключение составляют МП серий 1810ВМ86 и 18ШВМ88, для которых такое ПО является резидентным. [4]
Процесс проектирования программ итеративен. Это значит, что при разработке программы мы периодически повторяем весь процесс, по мере того как растет понимание требований, Проект нацелен на решение задачи, но нюансы, возникающие в ходе поиска оптимального решения, воздействуют на сам проект. Невозможно разработать серьезный крупный проект идя по прямой от начала до конца. Вместо этого на отдельных этапах приходится возвращаться к началу, постоянно совершенствуя интерфейсы и процедуры выполнения отдельных объектов. [5]
Процесс проектирования программ имеет иерархическую структуру. Важно заметить, что проектирование подразумевает детализацию, но детализация не включает проекта. [6]
Технология проектирования программ начала развиваться относительно недавно ( 20 - 25 лет назад) и еще не оформилась как самостоятельная область прикладной науки. В 60 - е годы основное внимание специалистов было сосредоточено на разработке языков программирования и средств трансляции программ. [7]
![]() |
Общая схема работы программы перевода. [8] |
Перед проектированием программы проводится анализ задания. [9]
При проектировании программы были использованы в широких масштабах унифицированные типовые схемы. С точки зрения последующей проверки программы появляется возможность тщательной однократной проверки типовой схемы при ее создании и проверки лишь тех путей, которые связаны с внесенными изменениями, при тестировании программы каждой конкретной задачи. Причем предусмотрена возможность автономной проверки как правильности внесенных изменений при настройке программного текста типовой схемы, так и всей настроенной процедуры. [10]
При проектировании программ эвристической классификации, таких как MUD или MYCIN, процесс уточнения правил является, по существу, шестиэтапным. [11]
Формализованные правила проектирования программ устанавливаются стандартами и инструкциями подготовки текстов программ и их структурного построения. Эталоны этого вида включают описание языка программирования, правила оформления текстов программ и описания данных. Эти эталоны являются наиболее универсальными и в ряде случаев формализуются на уровне ГОСТов на языки программирования и базу данных. [12]
В процессе проектирования программы изменяются объекты тестирования от первичных целей и алгоритмов до эксплуатируемого комплекса программ. С этих позиций тестирования наиболее характерными объектами являются [38]: требования и спецификации; программные модули; группы программ, решающие законченные функциональные задачи. [13]
На втором этапе проектирования программ по - технологии осуществляется доопределение полученной ЛСД. На этом этапе ЛСД доопределяется до соответствующего алгоритма обработки выделенных структур данных. Доопределение осуществляется в соответствии с той частью технического задания, в которой определена такая обработка. Память - машины тоже может использоваться поэтапно: вначале как структуры без каких-либо ограничений и наиболее естественные для исходной предметной области, а затем - с учетом всех особенностей их технической реализации. [14]
![]() |
Декомпозиция программного комплекса на принципах нисходящего проектирования. [15] |