Модульная структура программы представляет собой древовидную структуру, в узлах которой размещаются программные модули, а направленные дуги показывают статическую подчиненность модулей. Если в тексте модуля имеется ссылка на другой модуль, то их на структурной схеме соединяет дуга, которая исходит из первого и входит во второй модуль. Другими словами, каждый модуль может обращаться к подчиненным ему модулям. При этом модульная структура программной системы, кроме структурной схемы, должна включать в себя еще и совокупность спецификаций модулей, образующих эту систему.
Функция верхнего уровня обеспечивается главным модулем; он управляет выполнением нижестоящих функций, которым соответствуют подчиненные модули.
При определении набора модулей, реализующих функции конкретного алгоритма, необходимо учитывать следующее:
1) модуль вызывается на выполнение вышестоящим по иерархии модулем и, закончив работу, возвращает ему управление;
2) принятие основных решений в алгоритме выносится на максимально высокий по иерархии уровень;
Что бы вы увидели, если бы могли войти в улей
3) если в разных местах алгоритма используется одна и та же функция, то она оформляется в отдельный модуль, который будет вызываться по мере необходимости.
Состав, назначение и характер использования программных модулей в значительной степени определяются инструментальными средствами.
Например, при разработке СУБД используются следующие программные модули:
1) экранные формы ввода и/или редактирования информации базы данных;
4) стандартные средства для обработки информации;
5) меню для выбора функции обработки и др.
Связность модуля – это мера зависимости его частей (внутренняя характеристика модуля).
(сбоку возможность изменения, внутр. связи)
1) Случайная (по совпадению) – в модуле отсутствуют явно выраженные внутренние связи. СС=0 — —
2) Логическая – части модуля объединены по принципу функционального подобия. СС=1 — —
3) Временная – части модуля не связаны, но необходимы в один и тот, же период работы системы. СС=3 — —
4) Процедурная – модуль состоит из элементов, реализующих независимые действия, для которых задан единый порядок работы, то есть порядок передачи управления (связности по данным нет). -+ -+
5) Коммуникативная – части модуля связаны по данным (используют одни и те же структуры данных). СС=7 + +
6) Информационная (последовательная) – выходные данные одной части используются как входные данные в другой части модуля. СС=8 + +
7) Функциональная – модуль содержит элементы, участвующие в выполнении одной и только одной проблемной задачи. СС=10 + +
Сцепление модуля – мера взаимозависимости модулей (внешняя характеристика модуля), которая определяет, насколько хорошо модули отделены друг от друга. Модули независимы, если каждый из них не содержит о других никакой информации.
Типы сцепления: (в лекциях к этому еще и картинки есть)
1) Сцепление по данным – модули обмениваются данными, представленными скалярными значениями. СЦ=1
#2 Структура программы, переменные, константы, оператор присваивания | Java для начинающих
2) Сцепление по образцу – модули обмениваются данными, объединенными в структуры. СЦ=2
3) Сцепление по управлению – модуль посылает другому некоторый информационный объект (флаг), предназначенный для управления внутренней логикой модуля. СЦ=4
4) Сцепления по внешним ссылкам
5) Сцепление по общей области – модули разделяют одну и ту же глобальную структуру данных. СЦ=7
6) Сцепление по содержимому – модуль содержит обращения к внутренним компонентам другого (передает управление внутрь, читает и/или изменяет внутренние данные или сами коды). СЦ=9
Рутинность модуля — это зависимость модуля от своей собственной предыстории (чем меньше, тем лучше)
Мера длины модуля
V(G)- число вершин в дереве,представл. стр-ру прогр. Системы
8. Структурные методы анализа и проектирования (проверьте, я в лекциях не нашла!)
В структурном анализе и проектировании используются различные модели, описывающие:
ü Функциональную структуру системы;
ü Последовательность выполняемых действий;
ü Передачу информации между функциональными процессами;
ü Отношения между данными.
Наиболее распространенными моделями первых трех групп являются:
ü функциональная модель SADT (Structured Analysis and Design Technique);
ü DFD (Data Flow Diagrams) — диаграммы потоков данных.
Разъяснения! может и не нужно.
Метод SADT представляет собой совокупность правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями.
Метод SADT разработан Дугласом Россом (SoftTech, Inc.) в 1969 г. для моделирования искусственных систем средней сложности. Данный метод успешно использовался в военных, промышленных и коммерческих организациях США для решения широкого круга задач, таких, как долгосрочное и стратегическое планирование, автоматизированное производство и проектирование, разработка ПО для оборонных систем, управление финансами и материально-техническим снабжением и др. Метод SADT поддерживается Министерством обороны США, которое было инициатором разработки семейства стандартов IDEF (Icam DEFinition), являющегося основной частью программы ICAM (интегрированная компьютеризация производства), проводимой по инициативе ВВС США. Метод SADT реализован в одном стандартов этого семейства — IDEF0, который был утвержден в качестве федерального стандарта США в 1993 г., его подробные спецификации можно найти на сайте http://www.idef.com.
Модели SADT (IDEF0) традиционно используются для моделирования организационных систем (бизнес-процессов). Следует отметить, что метод SADT успешно работает только при описании хорошо специфицированных и стандартизованных бизнес-процессов в зарубежных корпорациях, поэтому он и принят в США в качестве типового. Достоинствами применения моделей SADT для описания бизнес-процессов являются:
· полнота описания бизнес-процесса (управление, информационные и материальные потоки, обратные связи);
· жесткие требования метода, обеспечивающих получение моделей стандартного вида;
· соответствие подхода к описанию процессов стандартам ISO 9000.
В большинстве российских организаций бизнес-процессы начали формироваться и развиваться сравнительно недавно, они слабо типизированы, поэтому разумнее ориентироваться на менее жесткие модели.
Метод моделирования IDEF3, являющийся частью семейства стандартов IDEF, был разработан в конце 1980-х годов для закрытого проекта ВВС США. Этот метод предназначен для таких моделей процессов, в которых важно понять последовательность выполнения действий и взаимозависимости между ними. Хотя IDEF3 и не достиг статуса федерального стандарта США, он приобрел широкое распространение среди системных аналитиков как дополнение к методу функционального моделирования IDEF0 (модели IDEF3 могут использоваться для детализации функциональных блоков IDEF0, не имеющих диаграмм декомпозиции). Основой модели IDEF3 служит так называемый сценарий процесса, который выделяет последовательность действий и подпроцессов анализируемой системы.
Диаграммы потоков данных (Data Flow Diagrams — DFD) представляют собой иерархию функциональных процессов, связанных потоками данных. Цель такого представления — продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.
Для построения DFD традиционно используются две различные нотации, соответствующие методам Йордона-ДеМарко и Гейна-Сэрсона. Эти нотации незначительно отличаются друг от друга графическим изображением символов. В соответствии с данными методами модель системы определяется как иерархия диаграмм потоков данных, описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи потребителю. Практически любой класс систем успешно моделируется при помощи DFD-ориентированных методов. Они с самого начала создавались как средство проектирования информационных систем (тогда как SADT — как средство моделирования систем вообще) и имеют более богатый набор элементов, адекватно отражающих специфику таких систем (например, хранилища данных являются прообразами файлов или баз данных, внешние сущности отражают взаимодействие моделируемой системы с внешним миром).
С другой стороны, эти разновидности средств структурного анализа примерно одинаковы с точки зрения возможностей изобразительных средств моделирования. При этом одним из основных критериев выбора того или иного метода является степень владения им со стороны консультанта или аналитика, грамотность выражения своих мыслей на языке моделирования. В противном случае в моделях, построенных с использованием любого метода, будет невозможно разобраться.
Наиболее распространенным средством моделирования данных (предметной области) является модель «сущность-связь» (Entity-Relationship Model — ERМ). Она была впервые введена Питером Ченом в 1976 г. Эта модель традиционно используется в структурном анализе и проектировании, однако, по существу, представляет собой подмножество объектной модели предметной области. Одна из разновидностей модели «сущность-связь» используется в методе IDEF1Х, входящем в семейство стандартов IDEF и реализованном в ряде распространенных CASE-средств (в частности, AllFusion ERwin Data Modeler).
Дата добавления: 2018-06-01 ; просмотров: 864 ; Мы поможем в написании вашей работы!
Источник: studopedia.net
Описание разработки программы
Пользовательский интерфейс это порядок человеко-машинного диалога. Способ взаимодействия человека с компьютером реализуется в прикладной программной системе, которая управляет доступом, переработкой и представлением информации в удобной для восприятия форме.
После запуска программы на экране появляется меню, содержащее следующие пункты: ЗАДАНИЕ, КОДИРОВАНИЕ, ДЕКОДИРОВАНИЕ, ВЫХОД.
Первый пункт дает общую информацию о данной программе.
Пункт Кодирование и Декодирование выполняют саму суть проекта.
В Кодирование мы задаем информационные символы, кодируем и передаем сообщение. В Декодирование принимаем информацию, раскодироваем сообщение, исправляя его, если надо, и выдаем на экран.
Пункт Выход обеспечивает выход из программы.
Внизу экрана постоянно находится информационная подсказка дальнейших действиях при работе с программой.
Выводы
В этой главе были приведены основные этапы проектирования системы. Представлена модульная структура системы и подробно описаны функции каждого модуля системы. Также в данной главе был описан пользовательский интерфейс системы.
Источник: studentopedia.ru
Модульное программирование
В основе того или иного языка программирования лежит некая руководящая идея, вызванная потребностями или, чаще всего, кризисом в области программирования и создания программного обеспечения, которая оказывает существенное влияние на стиль программирования и помогает преодолеть указанный кризис [9]. Рассмотрим вкратце историю появления и развития основных стилей программирования и процедурных алгоритмических языков.
ВВЕДЕНИЕ 3
1. ЦЕЛЬ МОДУЛЬНОГО ПРОГРАММИРОВАНИЯ 6
2. ОСНОВНЫЕ ХАРАКТЕРИСТИКИ ПРОГРАММНОГО МОДУЛЯ 7
3. ПРОЕКТИРОВАНИЕ МОДУЛЯ 11
3.1. ФУНКЦИОНАЛЬНАЯ ДЕКОМПОЗИЦИЯ 12
3.2. МИНИМИЗАЦИИ КОЛИЧЕСТВА ПЕРЕДАВАЕМЫХ ПАРАМЕТРОВ 12
3.3. МИНИМИЗАЦИИ КОЛИЧЕСТВА НЕОБХОДИМЫХ ВЫЗОВОВ 13
4. МЕТОДЫ РАЗРАБОТКИ СТРУКТУРЫ МОДУЛЬНОЙ ПРОГРАММЫ 16
4.1. МЕТОД ВОСХОДЯЩЕЙ РАЗРАБОТКИ 16
4.2. МЕТОД НИСХОДЯЩЕЙ РАЗРАБОТКИ 18
4.3. КОНСТРУКТИВНЫЙ И АРХИТЕКТУРНЫЙ ПОДХОДЫ 19
4.4. ДРУГИЕ МЕТОДЫ РАЗРАБОТКИ СТРУКТУРЫ МОДУЛЬНЫХ ПРОГРАММ И ИХ ОБЩАЯ КЛАССИФИКАЦИЯ 22
5. КОНТРОЛЬ СТРУКТУРЫ МОДУЛЬНОЙ ПРОГРАММЫ 25
ЗАКЛЮЧЕНИЕ 26
СПИСОК ЛИТЕРАТУРЫ: 27
Работа состоит из 1 файл
- всегда следует использовать рутинный модуль, если это не приводит к плохим (не рекомендуемым) сцеплениям модулей;
- зависящие от предыстории модули следует использовать только в случае, когда это необходимо для обеспечения параметрического сцепления;
- в спецификации зависящего от предыстории модуля должна быть четко сформулирована эта зависимость таким образом, чтобы было возможно прогнозировать поведение (эффект выполнения) данного модуля при разных последующих обращениях к нему.
В связи с последней рекомендацией может быть полезным определение внешнего представления (ориентированного на информирование человека) состояний зависящего от предыстории модуля. В этом случае эффект выполнения каждой функции (операции), реализуемой этим модулем, следует описывать в терминах этого внешнего представления, что существенно упростит прогнозирование поведения данного модуля.
3. Проектирование модуля
Модульное проектирование относится к процессу расчленения больших проблем на более узкие, более управляемые подпроблемы. Первым шагом проектирования является решение, в каком месте должна быть граница между этими подпроблемами.
Для получения максимальных преимуществ от использования модульного программирования каждая подпроблема или модуль должны иметь один вход и один выход. В этом случае можно легко отслеживать поток управления в программе. В любом месте модуля должна иметься возможность увидеть точку входа в модуль и определить точное значение переменных и регистров в этой точке, а затем проследить функционирование модуля без тревоги об искажении программы. Один вход обеспечивает возврат потока управления в точку вызова. По этой причине, модульные программы почти всегда выполняются как структуры «CALL — RET».
Использование нескольких предложений RET в модуле не должно нарушать правило одного входа, поскольку все инструкции RET возвращают управление в одну и туже точку. Точно также, переход к общему RET в конце модуля, не изменяет его структуру, а добавляет лишь коды и увеличивает его сложность. С другой стороны, вход или выход из модуля не по этому правилу перечеркивает наибольшие преимущества модульного программирования: ясность и удобство сопровождения.
Имеется исключение из правила входа в модуль. Это происходит при использовании таблицы переходов для реализации потока управления внутри программы. Таблица перехода используется путем «проталкивания» адреса возврата в стек, вычисления индекса требуемого адреса перехода в таблице и выполнения перехода в памяти.
При практическом выполнении декомпозиции модулей можно самим найти некоторое количество альтернативных решений. Прежде чем осуществить правильный выбор, необходимо знать альтернативы. Цель состоит в выборе таких вариантов, которые создадут наилучшие условия проектирования.
3.1. Функциональная декомпозиция
При обращении к проблеме на стадии проектирования первым альтернативным выбором должна быть функциональная декомпозиция, т.е. разбиение проблемы на более узкие, вполне поддающиеся управлению функциональные единицы, где каждая единица выполняет завершенную, легко идентифицируемую задачу. Имеется множество путей определения содержания задачи. Вот лишь некоторые примеры подобных единиц, которые выполняют определенные функции: получение квадратного корня некоторого числа; выполнение всех операций относительно указанного устройства таких, как операции в/в диска, операции в/в клавиатуры; выполняющие общую группу действий в указанное время такие, как инициализация областей данных; и единицы, которые взаимодействуют последовательно или используют общие элементы данных такие, как считывание данных с клавиатуры и преобразование их в целые значения.
В настоящее время в области программирования на языках высокого уровня чаще всего принимаются такие решения, которые представляют собой наилучший способ по использованию сегментации программ. Часто обнаруживается, что некоторые модули связываются с помощью одного набора критериев, а другие модули — с помощью другого. Каждый модуль должен включать легко понимаемые программные секции.
3.2. Минимизации количества передаваемых параметров
Иногда обнаруживается, что после определения модулей программы создано нечто громоздкое и неуклюжее. Это часто случается тогда, когда модули при выполнении возложенных на них задач требуют доступа к обширному количеству данных. Чаще всего это легко может произойти, если на модуль возложено выполнение нескольких опций. Чтобы знать состояние программы в данное время, модуль должен принимать очень много различных переменных. Если это так, и выявлено, что модуль принимает большое количество параметров, необходимо ответить на следующие две группы вопросов:
- В этом модуле предпринята попытка выполнения нескольких функций? Требует ли модуль параметры, используемые в не относящихся к данному модулю секциях? Если ответы на эти вопросы положительные, то необходимо снова обратиться к дальнейшей сегментации этого модуля.
- Модуль представляет собой функциональный разрез? Являются ли на самом деле вызывающий и вызываемый модули частью одной и той же функции? Если это так, то поместите их вместе в один модуль, даже если результирующий модуль окажется слишком большим. Затем попробуйте выполнить сегментацию модуля снова различными способами.
Сегментация модулей через функциональный разрез часто происходит тогда, когда программист обнаруживает, что две программные секции идентичны или сильно похожи друг на друга. Программист затем пытается создать из них один модуль. Это не модульное программирование, поскольку результирующий модуль имеет не функциональное соединение.
Если в процессе проектирования будет обнаружено, что ничего сделать нельзя, чтобы избежать использования большого числа ссылок на данные или передачи меток параметров, надо вернуться обратно в начало проектирования и проверить корректность поставленной проблемы.
3.3. Минимизации количества необходимых вызовов
Одним из существенных преимуществ модульного программирования является то, что программа основного уровня очень часто может быть сконструирована для чтения как последовательность вызываемых процедур. Этот факт существенно повышает «понимаемость» программы, поскольку читатель может познакомиться с ее основным потоком и функционированием после прочтения только одной — двух страниц программного кода. Однако эта особенность может также иметь и недостатки. Одна из многих верхних статистических оценок программирования говорит о том, что 90% времени выполнения типовых программ расходуется в 10 % кода программы. При этом подразумевается, что если эти 10 % содержат большое количество цепочечных вызовов процедур, то суммарное время, затрачиваемое на управление выполнением программы, может стать непреодолимым препятствием на пути использования этого подхода.
Прежде чем отказаться от модульности проектируемой программы, надо проверить, что скрывается под зависимостью программы от времени. Во-первых, большинство программ затрачивают большую часть времени выполнения на ожидание ввода информации с клавиатуры. После нажатия клавиши требуемые функции, с точки зрения выполнения длительного процесса, обычно не расходуют время. Различие между 100 микросекунд и 100 миллисекунд для среднего пользователя неразличимо.
Противоположным для некоторых мнением является то, что действующий механизм пары CALL — RET не перекрывает потребляемое время. По сравнению с инструкциями перехода инструкция CALL выполняется на 30-50% дольше, а RET в среднем длиннее на 1 цикл. Только когда во внимание принимаются накладные расходы передачи параметров, сохранения регистров и т.д., называемые служебными расходами, модульные программы начинают выглядеть медленнее по сравнению с немодульными программами. В дополнение к тому, что модули модульных программ обычно являются более общими, чем их неструктурированные дубликаты, модули модульных программ могут использовать ссылки на память или стек с большей частотой. Дополнительное время, расходуемое на вычисление действительного адреса в теле модуля, может привести к замедлению выполнения конкретного модуля, чем узко закодированная конкретная программа.
Преимущества служебных программ и программ общего назначения заключаются в том, что модуль может быть использован виртуально в некотором месте программы. При написании немодульной программы программист может потратить несколько часов, пытаясь открыть: используется ли регистр (переменная), или хуже того, верно ли то, что он должен использоваться. При модульном программировании программист не интересуется тем, какие регистры (переменные) он использует в настоящий момент, пока вызываемый модуль копирует его параметры в стек и сохраняет весь набор регистров на входе. Эти особенности создают возможность сначала использовать приемы модульного программирования для повышения скорости кодирования и затем переработки программы для удаления «узких» мест.
Для областей, чувствительных к скорости работы, лучшей рекомендацией является выбор основной ветви программы. Если модуль упоминается только в чувствительной к скорости работы программной секции, то он может быть включен в «ветвь» внутри вызывающего модуля. Если другие секции используют модуль, то они могут быть скопированы в вызывающий модуль в необходимое место. В связи с тем, что основной вызывающий модуль станет большим, необходимо вставить комментарии в его тело, помечающие включаемый модуль как блок его владельца. Будущие читатели смогут затем прочитать комментарии для определения функций модуля и пропустить его мимо для возобновления чтения основного кода.
4. Методы разработки структуры модульной программы
Как уже отмечалось выше, в качестве модульной структуры программы принято использовать древовидную структуру, включая деревья со сросшимися ветвями. В узлах такого дерева размещаются программные модули, а направленные дуги (стрелки) показывают статическую подчиненность модулей, т.е. каждая дуга показывает, что в тексте модуля, из которого она исходит, имеется ссылка на модуль, в который она входит. Другими словами, каждый модуль может обращаться к подчиненным ему модулям, т.е. выражается через эти модули. При этом модульная структура программы, в конечном счете, должна включать и совокупность спецификаций модулей, образующих эту программу. Спецификация программного модуля содержит:
- синтаксическую спецификацию его входов, позволяющую построить на используемом языке программирования синтаксически правильное обращение к нему (к любому его входу);
- функциональную спецификацию модуля (описание семантики функций, выполняемых этим модулем по каждому из его входов).
В процессе разработки программы ее модульная структура может по-разному формироваться и использоваться для определения порядка программирования и отладки модулей, указанных в этой структуре. Поэтому можно говорить о разных методах разработки структуры программы. Обычно в литературе обсуждаются два метода: метод восходящей разработки и метод нисходящей разработки.