Даже если бы удалось получить программы, свободные от ошибок, то возникает необходимость учитывать некоторый переходный период, в течение которого структура системы не должна основываться на предположении об отсутствии ошибок в отдельных модулях, но должна допускать возможность неправильного функционирования компонентов ПО вследствие внутренней ошибки. Спецификации модуля должны закреплять за каждым из них функцию выполнения определенных проверок модулей, с которыми последний взаимодействует. Кроме того, если даже ПО было написано корректно, более ранние ошибки оборудования могли сделать его некорректным. [c.15]
Внешнее проектирование модулей. Начальным шагом в проектировании модуля является определение его внешних характеристик. Эта информация содержится во внешней спецификации модуля, которая включает все данные, необходимые для модулей, вызывающих данный модуль. В особенности необходимо отметить, что внешняя спецификация модуля не должна содержать указаний о внутреннем представлении данных или о логике модуля. Кроме того, недопустимо, чтобы спецификация содержала какие-либо ссылки на вызывающие модули или на контексты, в которых данный модуль используется. Допустим следующий набор информации внешней спецификации [c.141]
Необходимо отличать внешнюю спецификацию модуля от другой документации, такой, как описание логики модуля, так как логика модуля может изменяться без воздействия вызывающих модулей, а изменение внешних спецификаций модуля обычно приводит к изменениям в вызывающих модулях. Внешняя спецификация модуля может принимать ряд физических форм в зависимости от включения шести перечисленных выше категорий. [c.142]
Ш а г 2. Проектирование внешних спецификаций модуля. Этот процесс рассмотрен в предыдущем разделе. [c.143]
Ш а г 3. Проверка внешних спецификаций модуля. Желательно, чтобы спецификация для каждого модуля была бы проверена путем сравнения ее с информацией интерфейса, разработанного при проектировании структуры программы. Спецификация данного модуля должна быть просмотрена программистами всех модулей, вызывающих данный модуль. [c.143]
| Рис. 17.5. Дерево включений для внешней спецификации модуля Т35. |  |
Комплексы СМ-2 компонуются по спецификации заказчика из агрегатных модулей СМ ЭВМ и при необходимости из периферийных устройств из номенклатуры системы М-6000. К СМ-2 могут подключаться все периферийные устройства, имеющие выход на интерфейс 2К и на любой из принятых в СМ ЭВМ периферийных интерфейсов. [c.229]
Подобный анализ можно начать из любого модуля системы и получить полную информацию о том, какие изменения та или иная операция вызвала в данных других модулей. Например, при просмотре картотеки товарно-материальных ценностей, можно мгновенно узнать, в каком модуле инициирована операция, а также номер заказа, закупки, проекта или производственного заказа, вызвавших то или иное движение. Данный подход применим ко всем товарам, услугам, спецификациям. При этом от итоговых данных детализацию можно довести до того, что система сообщит, на какой полке склада находится тот или иной товар, какие партии прихода и расхода введены в систему, какой производственный маршрут определен для готовой продукции и пр. [c.207]
Функцию формирование заявок на отгрузку предложено реализовать с использованием Договорного отдела на закупку через модули управление договорами, управление снабжением. Заявка на отгрузку вводится в виде договорного отдела на закупку на основании спецификации договора или пункта календарного плана сотрудником соответствующей номенклатурной группы отдела материально-технического обеспечения и комплектации. [c.173]
Автоматизировать такой порядок работы не эффективно, и по результатам исследования нами сформулировано несколько вариантов компенсации изменения средства платежа, не связанной с изменением цен. С учетом предлагаемых изменений в документообороте, данные функции реализуются с использованием модуля управление снабжением путем автоматического формирования приходной накладной на основании введенного ранее договорного отдела на закупку. Спецификация на закупку в этом случае формируется тоже автоматически из спецификации договора или пункта календарного плана. [c.174]
Описанием структуры системы являются спецификации межмодульных интерфейсов. Интерфейс между модулями должен обеспечить передачу информации о внешних ошибках. Например, модуль должен иметь возможность получать сообщения о том, что информация, поступающая на его вход, является некорректной или что запрос, выработанный им для другого модуля некоторое время назад, выполняется некорректно. В этом случае необходимо предусмотреть формирование специального сообщения от модуля-потребителя к модулю-поставщику о некорректной информации. [c.14]
Внешнее проектирование системы ПО включает разработку ее архитектуры и проектирование структуры программ на базе детальных спецификаций. Процесс построения архитектуры предусматривает разделение системы на некоторый набор программ, подсистем или компонентов с определением интерфейса между ними. Целью процесса проектирования структуры программ является выделение модулей и определение интерфейса между ними. Результатом данного процесса в общем случае является набор модулей и описание их взаимосвязей. [c.98]
Программисты обычно не имеют достаточной подготовки и опыта по этому виду проектирования. Они должны быть опытными в использовании языков программирования, методов организации вычислительных процессов, теории и практики компиляции, тестирования и отладки. В связи с этим было бы разумно использовать программистов в качестве проектировщиков модулей, предназначенных для средств отладки, компиляции и обнаружения ошибок, но вряд ли целесообразно поручать им разработку внешних спецификаций операционной системы, где они выступают не более чем пользователи. [c.116]
Для любой сложной функции пользователя задача об установлении соотношений между выводами и системными преобразователями и вводами способом причины и следствия — не тривиальная работа. В целом внешние спецификации описывают каждый возможный ввод в систему (как действительный, так и недействительный) и реакцию системы на каждый из входов. Внешние спецификации должны точно и полно описывать внешние интерфейсы, несмотря на то, что они практически не содержат сведений о внутреннем устройстве модулей. [c.120]
Четвертое правило — следить, чтобы все изменения были сделаны на соответствующем уровне. Программист, проектируя внутреннюю логику модуля, может внести изменения, но может не распознать, что изменение касается внешних характеристик продукта. ПО и спецификации теперь не совпадают, и это обстоятельство проявит себя в последующей работе. Не существует легкого решения данной проблемы и другого подхода, кроме уведомления каждого специалиста, связанного с проектом, о принятом решении. [c.123]
Имя модуля. Имеется в виду имя, используемое для вызова модуля. Для модуля с несколькими точками входа это имя является именем точки входа. Для каждой точки входа существует своя отдельная спецификация. [c.141]
Функция. Формулируется определение функции или функций, выполняемых модулем. Этот элемент спецификации не должен описывать логику модуля или контекст, в котором модуль используется. [c.141]
Внешние действия. Описание некоторых действий, принятых как внешние по отношению к программе или системе, где этот модуль вызывается. Примерами внешних действий являются печать сообщений, чтение команды, чтение вспомогательного файла (файла сообщений), выдача сообщений об ошибке. Внешние действия модуля могут включать в себя некоторые внешние действия подчиненных модулей. Например, если модуль А вызывает модуль В, а В печатает сообщение, то описания внешних действий появятся во внешних спецификациях как модуля А, так и модуля В. [c.142]
Тестирование модуля. Целью тестирования модуля является обнаружение различий между логической схемой модуля и его интерфейсом и их внешними спецификациями. Тестирование модуля начинается после его отладки. [c.172]
При проектировании функционального теста внешнюю спецификацию рекомендуется разделить на частные внешние функции а затем тщательно проверить каждую из. них. Для этих целей могут использоваться подходы, рассмотренные для случая тестирования единичного модуля. Они могут быть распространены на все входные условия и режимы, а также на все границы входных и выходных потоков данных. Эти способы обеспечивают также проверку программы на предмет ее поведения на функциональных границах и при появлении недействительных (ошибочных) или неожиданных данных на входе. . [c.176]
На следующем этапе осуществляется физическая интерпретация данных анализа с целью создания схем вычислительного процесса при выполнении требований его оптимизации, конструирования структур данных на логическом и физическом уровнях, генерации и порождения программ, реализующих обработку данных в создаваемой системе. В соответствии с результатами анализа проводится выбор конфигурации комплекса технических средств, которые будут использованы в создаваемой системе. В результате-этого этапа формируются спецификации программных модулей, определяется структура используемой памяти и проводится подготовка к физическому формированию создаваемой системы обработки данных. [c.52]
Чтобы еще более уточнить понятия внешнего и внутреннего проектов, обратимся к рис. 7.7 и 7.8. Древовидная структура, изображенная на рис. 7.7, построена по схеме, представленной на рис. 7.6, и показывает, где используется каждый модуль. Будем считать, что а внешний контур каждого блока из рис. 7.7 отображается совокупность параметров, принадлежащих соответствующему модулю. Контур Р, изображенный на рис. 7.8, на который отображаются все параметры, видимые при рассмотрении программного изделия извне, соответствует внешнему проекту. Внутренний проект образуется объединением всех параметров, отображения которых не попали во внешний контур Р. Внутренние спецификации описывают параметры, принадлежащие остальным контурам блоков. [c.107]
Продолжим изучение рис. 7.8. Отметим, что контур модуля А — высшего в иерархии модулей — полностью проецируется на внешний контур программного изделия Р. Это является прямым следствием нисходящего проектирования, в соответствии с принципами которого модуль высшего уровня лишь инициирует и прекращает работы программного изделия, устанавливает другие виды взаимодействия изделия с пользователем и синхронизирует выполнение модулей более низкого уровня. Вследствие такой декомпозиции модуль А не имеет внутреннего проекта и внутренних спецификаций. [c.107]
В конце испытаний класса А группа разработки подготавливает спецификацию выпуска — документ, который связывает воедино составные части программного изделия в соответствии с их шифрами, требованиями ко вводу в действие и другими, ранее разрозненными данными, такими, как перечень замеченных дефектов и недоработок. Форма спецификации описана в разд. 15.4. После того как число ошибок, обнаруживаемых во время испытаний класса А, станет незначительным, группа разработки начинает приемочные испытания по программе, составленной группой испытаний. Приемочные испытания основываются на наборе тестов, выбранных из общей программы испытаний и предназначенных для выявления недостатков плохо продуманного программного изделия. К сожалению, под впечатлением результатов испытаний группа разработки склонна к проведению поспешных изменений в модулях, которые могут разрушить целостность программного изделия проведение приемочных испытаний убеждает всех, в том числе и руководство группы разработки, что для внесения дополнительных изменений в модули нет оснований. [c.114]
Отметим, что здесь выполняется именно функциональная декомпозиция, поскольку СТ является функциональным документом и не указывает, как предлагаемое изделие будет физически разбито на модули. Во внутренних спецификациях, создаваемых на основе СТ, обязательно должно быть описано физическое разбиение на модули. Чтобы было легче сопоставлять внутренние спецификации с предшествующими им соглашениями о требованиях, удобно представить какое-либо конкретное физическое разбиение и попытаться определить функциональные модули, которые могут быть реализованы как физические модули. Но, поступая так, следует помнить, что в СТ более важным является четкое разбиение по функциям, а физическое разбиение только подразумевается, но не диктуется СТ. [c.213]
В работе [58] Парнас предложил метод составления спецификации на программный модуль, которая имеет много общего с рассматриваемой нами внешней спецификацией и основывается на следующих принципах [c.269]
Информация о структуре вызывающего модуля не должна содержаться во внешней спецификации на вызываемый модуль. [c.269]
Ограничения должны быть полностью и точно определены, но причину возникновения этих ограничений указывать необязательно. Причины ограничений можно включить во внутреннюю спецификацию, если эта информация в дальнейшем будет помогать специалистам, устраняющим дефекты или расширяющим возможности модулей, избежать нарушения установленных ограничений. [c.269]
Каждой функции из разд. 3. (2,3) присваивается имя, указываемое в заголовке на месте скобок. Для удобства после заголовка можно кратко описать назначение функции. Для описанных в других ВшС функций (например, при использовании ранее разработанного модуля или совокупности модулей) указываются соответствующие разделы З.(2,3).п этих ВшС. Если данная функция нигде выше не определена, необходимо составить ее описание и включить его в документ. Однако не следует включать в него описания, которые более естественны в другом месте, иначе это может привести к трудностям поддержания спецификаций в пригодном для работы состоянии. [c.273]
Проектирование программы тестирования — процесс творческий, требующий аналитичёскЬгб мышления Одна-. ко существует определённый наборГ.простцх правил, которые позволяют получить разумное множество, проверочных тестов. Эти правила базируются на рассмотрении программы модуля как черного ящика и использовании , внешних спецификаций модуля для построения тестов далее на базе изучения программы, модуля строятся-дополнительные тесты. Эти действия выполняются за четыре шага, i [c.173]
Шаг 1. Используя внешние спецификации модуля< -необходимо получить проверочные тесты для каждого условия и варианта данных, границ-всех зэданных<>интер- -валоВ На входе и выходе и для неверных условий.- к-,, [c.173]
Спецификация программы (модуля) [Program (Module) Spe ifi ation] — точная и полная формулировка задачи, содержащая информацию, необходимая для построения алгоритма (программы) решения этой задачи. [c.344]
Спецификация процесса обработки [Flow Spe ifi ation] — диаграмма, изображающая модули, образующие прикладную программу, очереди, посредством которых модули взаимодействуют друг с другом, и другую информацию, а также операторы макрокоманд, реализующие данную диаграмму. [c.344]
Наибольшей трудоемкостью в настоящее время обладают процедуры первой группы. Надобность в разработке общих видов составных частей отпадет лишь при проектировании на основе конструктивных модулей. До перехода к такому методу следует ориентироваться на типизацию, которая позволяет выявить структурную однородность составных частей объектов проектирования. На базе типовых структур компоновок могут быть выполнены модификации, которые, однако, не приводят к перестройке общей композиции. Типовые структурные компоновки должны реализовать прогрессивные технические решения. Храниться они могут на магнитных носителях, микрофишах. Каждое описание типовой структурной компоновки в базе данных включает спецификацию составных частей. Для идентификации типовых структурных компоновок можно использовать единую обезличенную классификационную систему обозначений изделий и конструкторских документов. Входящий в нее код классификационной характеристики присваивается конструкторскому документу пр Классификатору ЕСКД независимо от предметной области. Классификатор реализует иерархический метод характеристики изделий, что удобно для декомпозиции при разработке составных частей объекта проектирования. В характеристику должны быть включены наиболее существенные для целей поиска типовых структурных компоновок признаки функциональный, служебного назначения, конструктивный, принципа действия, параметрический, геометрической формы, наименования. [c.233]
Написание компонентов ПО. В точке 4 обсуждаемой модели выполняется несколько шагов трансляции, начиная с трансляции внутреннего описания и кончая детальной разработкой необходимого набора программных операторов, обеспечивающих работу ПО в соответствии с заданными спецификациями. Этот этап работы реализует такие шаги, как трансляция внешнего описания проблемы в структуру компонентов ПО (модулей) и трансляция этих компонентов в описания структурного уровня, например блок-схемы процессов обработки информации. Именно в этой точке модели разработчик имеет дело с все возрастающим объемом информации, а отсюда и вероятность возникновения ошибок здесь достаточно высока. Основными задачами исследования надежности системы в это время являются задачи сравнительного анализа эффективности различных способов обеспечения надежности и выбор вариантов, обладающих заданной надежностью при учете реально существующих ограничений по различного рода ресурсам. Эти исследования могут проводиться на уровне моделей. Получение программы. Процесс последнего этапа разработки представляет собой трансляцию программных спецификаций в операторы языка программирования,. В силу формальности и рутинности выполняемой работы на этом этапе отмечается большое число ошибок, но эти ошибки, как правило, легко обнаруживаются и исправ- [c.51]
Очередным процессом создания ПО является процесс разработки структуры программы, включающий определение всех модулей, иерархической структуры модулей и интерфейса между ними. Если результатом разработки должна быть отдельная программа, то в качестве входной информации для данного процесса должны выступать детализированные внешние спецификации. Если же результатом разработки должна стать система ПО, то в качестве входной информации должны быть детализиро- [c.129]
Для проверки правильности проведения работ по проектированию системы могут быть применены различные способы Одним из них может быть проверка проект ной документации автором архитектуры системы (авто ром внешних спецификаций) и проектировщиком после дующего процесса (разработчиком модулей) с целью обеспечения работоспособности, понятности, соответствия используемому языку программирования, а также совмес тимости с общей системой, частью которой является проект. [c.138]
Тестирование модуля включает проведение определен ного объема работ проектирование набора тестовых -комбинаций на основе анализа внешних Спецификаций и программы модуля написание программы тестирования-и ее проверку и выполнение- программы тестирования Расемотр>ш содержание этих работ. " [c.173]
Одной из составных частей ADAD является модуль для трехмерного проектирования сложных систем трубопроводов. Графическая база данных модуля содержит объемные элементы трубопроводов (соединения, краны, фланцы, трубы). Выбранный из библиотеки элемент автоматически приводится в соответствие с характеристиками трубопроводной системы проектируемой модели. Модуль осуществляет обработку чертежей и создает двух-и трехмерные изображения, включая построение изометрических моделей и ортогональных проекций объектов. Предусмотрен выбор деталей для трубопроводов, видов покрытий и типов изоляций согласно заданной спецификации. [c.238]
Кодирование программ начинается на раннем этапе фазы программирования. На рис. 7.10, представляющем фрагмент сети, выделенной из общего стандартного сетевого графика, показаны этапы последовательного выполнения работ в рамках функции разработки в фазе программирования Р21 — кодирование ачато, РЗО — внешние спецификации утверждены. Р31 — внутренние спецификации завершены. Эти точки демонстрируют проявление волнового эффекта, когда составление внутренних и внешних спецификаций, кодирование, отладка и компоновка программ выполняются одновременно на различных уровнях дерева структуры программного изделия. Например, в некоторый момент фазы программирования состояние разработки модулей (рис. 7.6) может иметь вид, отображаемый табл. 7.2. К этому времени внешние спецификации всего программного изделия могут быть уже утверждены, а внутренние спецификации составлены не до конца. Подобно этому, хотя этапы кодирования, отладки и компоновки некоторых модулей уже могут быть завершены, их разработка в рамках целостного программного изделия еще может быть не за- [c.110]