Структурное программирование. Структурное программирование — это метод, предполагающий создание улучшенных программ. Его цель — организация и упорядочение построения программ и процесса программирования для предотвращения большинства логических ошибок и обнаружения оставшихся ошибок. Структурное програм мирование имеет две важные характерные особенности проектирование сверху вниз и модульное программирование. [c.151]
При создании системы хозяйственного учета на базе микро-ЭВМ в основу должно быть положено нисходящее проектирование задач (проектирование сверху вниз). Это требование определяется необходимостью балансового отражения на счетах бухгалтерского учета и отчетного обобщения всех хозяйственных операций за учитываемый и контролируемый периоды. [c.80]
ПРОЕКТИРОВАНИЕ СВЕРХУ ВНИЗ [c.201]
Применение принципа проектирования сверху вниз обеспечивает высокое качество проектных решений создаваемых СМОД. Это достигается главным образом уменьшением количества допускаемых ошибок благодаря тому, что для обнаружения и устранения ошибок с самого начала работ используется ЭВМ. При этом уменьшается число возвратов для повторного проектирования, связанных с исправлением допущенных ошибок. [c.205]
С положениями принципа проектирования сверху вниз хорошо согласуется метод структурного программирования, используемый при разработке программ. В программах, написанных традиционными методами, используются многочисленные ветвления, часто применяется команда безусловного перехода. Ее применение создает некоторые удобства для программиста, например, в тех случаях, когда в модуль программы надо сделать вставку, однако при этом затрудняется возможность понимания логики программы, особенно для программиста, не являющегося автором программы. Другими словами, бесконтрольное применение команд безусловного перехода служит серьезным препятствием для читабельности программ и одним из основных источников ошибок при программировании. [c.205]
Если принцип проектирования сверху вниз , методы структурного программирования и Я/РО-схем больше относятся к техническим приемам проектирования СМОД, то метод организации библиотеки обеспечения процесса проектирования, принцип построения проектной группы с главным специалистом и метод структурных просмотров являются сугубо организационными. [c.209]
Группа главного специалиста ориентирована на использование метода структурного программирования, принципа проектирования сверху вниз , метода Я/РО-схем и библиотеки обеспечения процесса проектирования. Концепция применения группы главного специалиста находится на вершине иерархии изложенных приемов проектирования. [c.213]
В заключение отметим, что организационные методы в совокупности составляют некоторый комплексный подход к проектированию СМОД. Все рассмотренные методы и принципы обычно применяются вместе, но в практике проектирования известны и варианты их автономного использования. Вполне возможно, например, применять структурное программирование без реализации принципа проектирования сверху вниз или, наоборот, проектировать сверху вниз , но не использовать структурное программирование. [c.215]
Дайте сравнительный анализ принципов проектирования сверху вниз и снизу вверх . [c.215]
Поскольку большинство программных изделий являются основными, может появиться желание поменять местами разд. 3.2 и 3.3, а затем опустить разд. 3.3 для основного изделия. Причина выдвижения здесь генерируемого программного обеспечения на первое место состоит в том, что при правильном проектировании сверху вниз генерируемое программное обеспечение является основной целью проектирования и должно быть описано раньше, чем его генератор. Другими словами, структура генерируемых программ должна определять структуру генератора, а не наоборот. Если изделие является основным, под заголовком 3.2. Генерируемое программное обеспечение делается пометка Не используется и опускаются под-разд. 3.2.Г —3i2.n.4.1. [c.212]
Как отмечалось в гл. 13, выбор заголовков, которые включаются в документ, и их последовательность не произвольны. Представленные в этой главе форматы составлены в соответствии с принципом проектирования сверху вниз, т. е. наиболее важные вопросы помещаются первыми незначительные исключения составляют те случаи, где обеспечение удобства чтения текста важнее сохранения реальной схемы декомпозиции проекта. В представленных форматах используется способ нумерации, позволяющий реализовать вложенную структуру документов, удобную с точки зрения возможности дополнения и исключения отдельных разделов. Например, в гл. 13 в табл. 13.2 приведено оглавление подобной структуры для соглашения о требованиях (СТ), внешней спецификации (ВшС), внутренней спецификации (ВтС) и спецификации сопровождения (СС). Элементы каждого такого документа обозначаются следующим образом 3 — заголовок, Об— общая формулировка, Ч — частичная формулировка, Ок — окончательная формулировка. Преобразование 3->-Об->-Ч->Ок, направленное в одну сторону, осуществляется в процессе принятия проектных решений. [c.268]
Метод модульного проектирования поддерживается методом проектирования сверху-вниз . Традиционно применяемое проектирование методом снизу-вверх включает выполнение операций по разработке программного обеспечения в следующей последовательности разработка отдельных компонентов программы, кодирование этих компонентов, отладка и интеграция, т.е. сборка их на последнем шаге, что приводит к вероятности выявления стольких неувязок в программе, сколько было в ней составных частей. [c.192]
ЭТАПЫ ОРГАНИЗАЦИОННОГО ПРОЕКТИРОВАНИЯ. Порядок, в котором мы ранее представляли элементы концепции формирования организаций, может ввести читателей в заблуждение. Наш анализ шел от формулировки задач к взаимоотношениям власти и, наконец, к общей структуре организации. Это могло привести к мысли, что структура организации вырабатывается снизу вверх сначала прорабатываются задачи, а общая структура организации — в самом конце. Однако дело обстоит как раз наоборот. Согласно классической теории организации, с выводами которой по данному вопросу согласно большинство менеджеров, структура организации должна разрабатываться сверху вниз. Нет ничего удивительного, что последовательность разработки организационной структуры схожа с последовательностью элементов процесса планирования. Вначале руководители должны осуществить разделение организации на широкие сферы, затем поставить конкретные задачи — подобно тому, [c.331]
Как видно на рис. 43 (верхняя часть), цикл планирования начинается с рассмотрения тематики, которая сформировалась к моменту утверждения бюджета на текущий год. Кроме того, в ходе стратегического планирования рабочие группы по решению проблем разрабатывают идеи, проводят аналитические исследования и готовят рекомендации. До или после Пасхи проводится основное стратегическое заседание. Параллельно протекает процесс формирования пятилетнего перспективного бюджета, подкрепленный соответствующими мероприятиями. На его базе сверху вниз задают основные ориентиры (например, в форме инструктивного письма) для годового плана или бюджета на предстоящий год, процесс разработки которого осуществляется в три этапа проектирование - взаимоувязка - утверждение. Одобрение бюджета, обеспечивающего достижение целевого показателя рентабельности капитала и желаемой структуры баланса, означает одновременно задание целей для соответствующих подразделений. Для отдела сбыта это будут, возможно, целевые суммы покрытия для производственного отдела - целевые затраты для отдела закупок - цены закупки для каждого отдела -постоянные затраты и нормативы управленческой деятельности. [c.200]
Применение современных методов программирования (структурирования программ, проектирования и разработки методом сверху-вниз , сквозного контроля, предварительного документирования, библиотеки поддержки разработки и др.) во время разработки и сопровождения сказывается следующим образом чем в большей степени они используются, тем меньше затраты на сопровождение и тем легче сопровождать большие программные изделия. [c.100]
Нисходящее проектирование программного обеспечения заключается в том, что разрабатываемый комплекс задач или задача расчленяется сначала на подзадачи, которые в свою очередь детализируются далее. Этот процесс продолжается сверху вниз до тех пор, пока полученные подзадачи не окажутся такими, что их можно будет просто решить на ЭВМ. Для этого в современных условиях компьютеризации учетно-информацион-ных процессов пользователи персональных ЭВМ должны иметь соответствующую компьютерную грамотность. [c.82]
Рассмотренные нами системы автоматизации проектирования СМОД различны по своей ориентации на пользователя, способу реализации модельного подхода к проектированию, структурному составу, степени автоматизации процессов проектирования СМОД и другим параметрам. В то же время наблюдается определенная общность принципов и методов, положенных в их основу. В частности, все эти САПР имеют нисходящий (сверху вниз) принцип проектирования. Процесс разработки развивается от первоначально заданных нечетких целей к конкретным решениям путем последовательной детализации и уточнения исходных целей. При создании программного обеспечения СМОД в этих системах используются прогрессивные принципы и методы программирования. [c.172]
Проектирование СМОД может вестись либо традиционно по принципу снизу вверх , либо по принципу сверху вниз . Название принципов соответствует направлению движения при проектировании по уровням детализации создаваемой СМОД, представленной в виде дерева, корнем которого является собственно система обработки, далее следуют уровни подсистем, задач и т. д. [c.201]
Альтернативным принципом проектирования СМОД является принцип сверху вниз . В этом случае проектирование начинается с самого верхнего уровня — уровня СМОД. Определяются цели, назначение системы и проектные решения, соответствующие данному уровню. Далее производится декомпозиция системы на составляющие компоненты и определяются их взаимосвязи. Для каждого выделенного компонента разрабатываются соответствующие проектные решения. [c.203]
При проектировании по принципу сверху вниз СМОД рассматривается как древовидная структура, составленная из модулей. Корнем дерева является модуль, отражающий логику системы в целом. Он или передает управление модулям более низкого уровня, или идентифицирует их для выполнения. [c.203]
Еще одно преимущество применения принципа сверху вниз заключается в том, что проектирование можно начинать практически с любого модуля, представленного в виде узла древовидной структуры системы. При этом должны быть заранее разработаны интерфейсы между этим модулем и модулем более высокого уровня. Так, отдельные ветви древовидной структуры системы можно разрабатывать раньше других. Например, для облегчения подготовки объекта к внедрению СМОД раньше других можно разработать интерфейсы для пользователей и внешние интерфейсы. [c.203]
Проиллюстрируем применение принципа сверху вниз на упрощенном примере проектирования задачи Бухгалтерский учет материалов . После анализа экономической сущности этой задачи произведем ее декомпозицию на следующие функциональные [c.203]
Библиотека обеспечения служит для проектирования СМОД методом сверху вниз . Разработка и отладка начинаются с системного блока самого высокого уровня. Поскольку этот блок обычно связан с блоками более низкого уровня, они должны быть представлены в виде программ-имитаторов. Имитатор служит для передачи управления, выдачи сообщений и может обеспечивать выполнение минимального набора требуемых функций. Затем программные имитаторы доводятся до уровня полных функциональных блоков, для которых в свою очередь потребуются блоки более низкого уровня, поэтому на всем протяжении разработки интеграция блоков осуществляется постоянно. При отладке система использует готовые блоки из библиотеки новых программ, а в случае их отсутствия — программные имитаторы. В процессе интеграции сама система помогает отладке новых блоков, так как отлаженные блоки, обменивающиеся информацией с вновь создаваемыми, могут использоваться для создания отладочных данных для новых блоков. [c.212]
Проектирование по при ципу "сверху вниз" [c.214]
Рассмотрим любую организацию, связанную с созданием программных средств, начиная с самой вершины иерархии, и попытаемся выяснить, где выполняется каждая функция проектирования программного изделия или где она должна была бы обеспечиваться, если бы не была предусмотрена заранее. Можно с уверенностью сказать, что требуемые функции могли бы выполняться соответствующими подразделениями с должным качеством, если, разумеется, эти функции в принципе выполнимы в данной организации. Во всяком случае, нет оснований считать, что для проектирования универсального программного обеспечения понадобится какой-то особый подход, хотя жрецы программирования могут с этим и не согласиться. Чтобы определить, следует ли функции объединять или нет, необходимо рассмотреть структуру всей организации сверху вниз и выяснить, какие средства — объединенные или раздельные— в большей степени способствуют целям вышестоящей организации. [c.51]
Организуя процесс разработки программного изделия, необходимо иметь в виду основную идею иерархической декомпозиции проекта, при которой всегда сохраняется завершенность (с точки зрения учета всех аспектов проектирования) на различных этапах все более увеличивающейся детализации. Декомпозиция проекта является вторым этапом в цепочке, включающей три этапа декомпозиции, следующих друг за другом. Первый этап — декомпозиция плана, третий—программная декомпозиция, часто называемая программированием сверху вниз или нисходящим программированием. [c.87]
Концепция бригады главного программиста хорошо вписывается в методологию, излагаемую в данной книге. Библиотека поддержки разработки является хорошей иллюстрацией методов конфигурационного управления на уровне проекта. Структурное программирование удовлетворяет многим требованиям методологии проектирования, которые упоминаются в этой книге. Нисходящее проектирование, называемое также программированием сверху вниз, является фактически постепенной детализацией описаний функциональной структуры на уровнях более простых функций до тех пор, пока, наконец, не будет достигнут уровень собственно операторов языка программирования [14]. В ходе этого процесса фактически осуществляется декомпозиция проекта, описанная в предыдущей главе. Как заметил Бейкер [39], один из недостатков работы бригад главного программиста заключается в отсутствии подробных описаний функциональной структуры, которые отражали бы все внешние аспекты системы, не затрагивая внутренней структуры проекта. Ясно, что речь здесь идет о внешних спецификациях, рассмотренных в гл. 2. Бригада главного программиста, в составе которой предусмотрена должность руководителя проек- [c.91]
Спиральная модель. Используется подход к организации проектирования ЭИС сверху-вниз , когда сначала определяется состав функциональных подсистем, а затем постановка отдельных задач. Соответственно сначала разрабатываются такие общесистемные вопросы, как организация интегрированной базы данных, технология сбора, передачи и накопления информации, а затем технология решения конкретных задач. В рамках комплексов задач программирование осуществляется по направлению от головных программных модулей к исполняющим отдельные функции модулям. При этом на первый план выходят вопросы взаимодействия интерфейсов программных модулей между собой и с базой данных, а на второй план - реализация алгоритмов. [c.40]
Проектирование методом сверху-вниз позволяет свести процесс разработки программы к выполнению двух операций логическая разработка с одновременным интегрированием и выполнение кодирования с отладкой. При таком подходе вначале разрабатывается логическая структура программы в виде дерева программных модулей с установлением всех типов связей между ними, а затем идут кодирование и отладка модулей. При этом проектирование начинается с модулей, занимающих верхние уровни иерархии, с одновременной проработкой связей их со всеми соподчиненными модулями, для которых разрабатываются временные заглушки с целью проведения их отладки. [c.192]
При моделировании (разработке) сложные информационные системы разбиваются на составные части, каждая из которых рассматривается отдельно от других. Такой прием, как известно, называется декомпозицией. Классический подход к разработке сложных систем представляет собой структурное проектирование, при котором осуществляется алгоритмическая декомпозиция системы по методу "сверху-вниз". [c.83]
С развитием рынка обнаруживаются серьезные недостатки до-рыночного подхода к проектированию организации. Спроектированные стены между функциями загоняют организационную болезнь — функционализм — вглубь. При этом расширяется дублирование работ, сгруппированных по разным критериям, например, по территории или по продукту, возрастает (в отдельных случаях до 10 раз) стоимость аппаратных структур, принятие решений занимает много времени. Вся организация видна только сверху и только для руководства отсюда вся ответственность тоже наверху, а внизу в этом смысле — пустота. Делегирование полномочий в таких условиях затруднено. Существует недостаток инновационности. Эти недостатки мешают организации оптимизироваться в направлении потребителя и в конечном счете в направлении рынка. [c.370]
В целях повышения эффективности проектирования ПО были разработаны новые методы управления процессом создания ПО и технологии программирования. К этим методам можно отнести проектирование сверху вниз, снизу вверх, группу главного программиста, метод HIPO, R-технологию, структурное, модульное и стандартное программирование и др. [c.79]
Перечисленные причины, способствующие увеличению стоимости программной продукции, указывают на отсутст вие эффективной технологии планирования и разработки программной продукции. В целях устранения отмеченных недостатков предприняты и предпринимаются серьезные усилия в области совершенствования технологии проектирования и программирования. В этой связи можно указать на такие приемы, как проектирование сверху вниз, снизу вверх, структурное проектирование, структурное, модульное, стандартное и защитное программирование. [c.257]
Усовершенствованная технология программирования разработана с учетом принципа проектирования сверху вниз , метода структурного программирования, метода документирования в виде HIPO-схем, принципа построения проектной группы с главным специалистом, метода структурных просмотров, предназначенных для контроля за качеством проектных решений, и метода организации библиотеки обеспечения процесса проектирования. [c.201]
Метод декомпозиции модулей предусматривает дальнейшее разбиение подкомплексов задач на отдельные задачи, показатели. Подход к разбиению всей совокупности задач по принципу сверху вниз особенно удобен для разработки принципиальных организационно-технических решений, внесения в них при необходимости изменений, а также увязки при проектировании хозяйственных и организационно-управленческих целевых установок с конкретными задачами и показателями. [c.68]
Прежние знания часто являются скрытыми и часто недоступными, поэтому их использование внутри организации ограничено. На познавательной карте соответственно отражено важное значение, которое придается как формальному, так и неформальному взаимодействию сотрудников внутри организации. Для увеличения активности общения требуется перекрытие знаний. Такие аргументы привели к разработке концепции поверхностей перекрытия функций, например, между НИОКР, проектированием и маркетингом. Напротив, поток сообщений "сверху вниз" в традиционной иерархической организации блокирует инновации и изменения. Гораздо эффективнее структура сетей, обеспечивающая горизонтальные соединения и помогающая менеджерам и их штату инициировать творчество. [c.71]
Метод HIPO-схем (иерархия — ввод — обработка — вывод) используется на протяжении всего проектирования СМОД для документирования и графического отображения проекта и как дополнительное средство, обеспечивающее создание СМОД по принципу сверху вниз . [c.207]
В библиотеке обеспечения процесса проектирования может быть собрана статистика о режиме работы коллектива над созданием проекта. Использование библиотеки обеспечения в сочетании со структурным программированием, ведением разработок по принципу сверху вниз и HIPO-схемами значительно повышает эффективность руководства проектированием. Причем в каждый момент времени можно четко определить степень завершенности создаваемого проекта, объективно оценить, насколько система готова к работе. [c.212]
На этапах предпрогнозной ориентировки и постановки задачи проводится сбор и анализ имеющейся исходной информации по объекту прогноза (научных отчетов, литературных обзоров, монографий, статистических данных, патентов и авторских свидетельств, нормативно-технической документации, стандартов, правил проектирования, эксплуатации и т. д., материалов научных конференций, данных анкетных опросов и т. д,), оценивается современное состоянине проблемы. В результате формируются главная (генеральная) и частные цели (проблемы), задачи прогноза, строится дерево целей , которое дает графическое представление об объекте прогноза, проблемах, соподчиненности (иерархической структуре) и взаимосвязях элементов структуры объекта прогноза. Дерево целей строится на логической основе сверху вниз, поэтапно, уровень за уровнем, так, чтобы элементы (мероприятия) последующего уровня обеспечивали задачи предыдущего. Построение дерева целей начинается с вершины верхнего уровня (генеральной цели), затем определяются частные цели, намечаются пути достижения поставленных целей (варианты решения), определяются наиболее существенные параметры, изменение которых должно быть учтено. [c.299]
Несомненным достоинством функциональных моделей является реализация структурного подхода к проектированию ЭИС по принципу сверху-вниз , когда каждый функциональный блок может быть декомпозирован на множество подфункций и т.д., [c.281]
Смотреть страницы где упоминается термин Проектирование сверху вниз
: [c.245] [c.191] [c.354]Смотреть главы в:
Проектирование машинной обработки экономической информации -> Проектирование сверху вниз