Сложная система обычно может быть разделена на более простые части — модули. Модульность является важным качеством инженерных процессов и продуктов. Большинство промышленных процессов являются модульными и составлены из комплексов работ, которые комбинируются простыми способами (последовательными или перекрывающимися) для достижения требуемого результата. Главное преимущество модульности заключается в том, что она позволяет применять принцип разделения задач на двух этапах:
— при работе с элементами каждого модуля отдельно (игнорируя элементы других модулей);
— при работе с общими характеристиками групп модулей и отношениями между ними с целью объединить их в конкретный, более крупный и сложный компонент.
Если данные этапы выполняются в последовательности, предусматривающей сначала концентрацию процессов на модулях, а затем — их объединение, то система проектируется снизу вверх. Если сначала систему разбивают на модули, а потом работают над их индивидуальным проектированием, то это — проектирование сверху вниз.
Структура ДНК
При структурном построении комплексов программ важное значение имеет размер и сложность компонентов для каждого уровня иерархии и соответственно число иерархических уровней для крупных ПС. По принципам построения, языку описания, размеру и другим характеристикам компонентов в структуре ПС можно выделить иерархические уровни:
— программных модулей, оформляемых как законченные компоненты текста программ;
— функциональных групп (компонентов) или пакетов программ;
— комплексов программ, оформляемых как законченные программные продукты определенного целевого назначения.
С повышением иерархического уровня увеличивается размер текста программ, реализующих компоненты этого уровня и количество обрабатываемых переменных. Одновременно совокупности команд все более специализируется и снижается возможность повторного применения компонентов в различных комбинациях для решения аналогичных задач.
Программные модули решают относительно небольшие функциональные задачи, и каждый реализуется 10—100 операторами языка программирования.
Каждый модуль может использовать на входе около десятка типов переменных. Если для решения небольшой функциональной задачи требуется более 100 операторов, то обычно целесообразно проводить декомпозицию задачи на несколько более простых модулей.
Функциональные группы программ (компоненты) формируются на базе нескольких или десятков модулей и решают достаточно сложные автономные задачи. На их реализацию целесообразно использовать до десятка тысяч строк текста программы. Соответственно возрастают число используемых типов переменных и разнообразие выходных данных. При этом быстро растет число типов переменных, обрабатываемых модулями и локализующихся в пределах одного или нескольких модулей.
Комплексы программ — программные продукты создаются для решения сложных задач управления и обработки информации. В комплексы объединяются несколько или десятки функциональных групп программ для решения общей целевой задачи системы. Размеры ПС зачастую исчисляются сотнями модулей, десятками и сотнями тысяч операторов. Встречаются ПС, содержащие до двух-трех десятков структурных иерархических уровней, построенных из модулей.
Структурные компоненты адаптированной образов. программы для слепых и слабовидящих обучающихся
Проектирование модулей включает в себя разработку локальных функций и подробных описаний алгоритмов обработки данных; межмодульных интерфейсов; внутренних структур данных; структурных схем передач управления; средств управления в исключительных ситуациях. С их помощью определяются функции: порядок следования отдельных шагов обработки, ситуации и типы данных, вызывающие изменения процесса обработки, а также повторно используемые функции программы. Программные модули для их многократного использования должны базироваться на унифицированных правилах структурного построения, оформления спецификаций требований и описаний текстов программ и комментариев.
Кроме того, целесообразно для каждого проекта директивно ограничивать размеры модулей по числу строк текста с учетом языка программирования, например, 30-ю или 50-ю операторами.
Основная цель такой унификации — облегчить разработку модулей, обеспечение их качества и тестирования, а также упростить управление их функциями и характеристиками.
Источник: karpusheva.ru
Структура учебной программы
Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:
Прямо сейчас студенты читают про:
Система и метод Гегеля. Основные законы диалектики Одним из грандиозных умов в истории человечества стал Георг Вильгельм Фридрих Гегель (1770—1831).
Предметно-количественный учет спирта этилового в медицинской организации Тема: Оборот лекарственных средств Источник: Электронная система «Контроль в ЛПУ» Этиловый спирт не относится к НС и ПВ и включен в.
Геометрические тела с вырезом Пример 1. Вырез на конусе (рис.142). Рис.142 Вырез произведен двумя плоскостями. Одна проходит через вершину конуса и рассечет его.
Выделяют три способа: прямой, отсылочный и бланкетный При прямом способе статья акта содержит одну норму, причем все ее элементы сразу.
Как заполняются электронные уровни, подуровни и орбитали по мере усложнения атома. Если говорить более строго, то относительное расположение подуровней обусловлено не столько их большей или меньшей энергией, сколько.
Источник: studopedia.ru
Структурное проектирование программ
В этом методе разбиение сложной системы на несколько подсистем получило название «разделяй и властвуй» (divide et impera), иерархическая или функциональная декомпозиция и др. При этом базовыми принципами являются:
a) «разделяй и властвуй»;
b) Проектирование «сверху вниз» — от общей постановки задачи к отдельным подзадачам и т.д.;
c) принцип иерархического упорядочения, который предполагает объединение составных частей системы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.
Процесс проектирования сложного программного обеспечения начинают с уточнения его структуры, т. е. определения структурных компонентов и связей между ними. Результат уточнения структуры может быть представлен в виде структурной и/или функциональной схем и описания (спецификаций) компонентов.
Структурная схема разрабатываемого программного обеспечения
Структурной называют схему, отражающую состав и взаимодействие по управлению частей разрабатываемого программного обеспечения. Обычно такие схемы разрабатывают для каждой программы большого пакета, а список программ определяют, анализируя функции, указанные в техническом задании.
Самый простой вид программного обеспечения — программа, которая в качестве структурных компонентов может включать только подпрограммы и библиотеки ресурсов. Разработку структурной схемы программы обычно выполняют методом пошаговой детализации.
Структурными компонентами программной системы или комплекса могут служить программы, подсистемы, базы данных, библиотеки ресурсов и т. п.
Так схема программного комплекса демонстрирует передачу управления от программы-диспетчера соответствующей программе, как показано на рис. 4.1. Программы комплекса, как правило, слабо связаны. Поэтому для организации их совместной работы используется диспетчер.
Рис. 4.1. Пример структурной схемы программного комплекса.
Структурная схема программной системы, как правило, показывает наличие подсистем или других структурных компонентов. В отличие от комплекса отдельные части (подсистемы) программной системы интенсивно обмениваются данными между собой и, возможно, с основной программой. Структурная же схема программной системы этого, как правило, не показывает, как это видно из рис. 4.2.
Обычно она представляет собой многоуровневую иерархическую схему взаимодействия подпрограмм по управлению. На начальном этапе схема отображает два уровня иерархии, т. е. показывает общую структуру программы. Однако тот же метод позволяет получить структурные схемы с большим количеством уровней.
Метод пошаговой детализации реализует нисходящий подход и базируется на основных конструкциях структурного программирования. Он предполагает пошаговую разработку алгоритма, как показано на рисунке 4.3. Каждый шаг при этом включает разложение функции на подфункции. Так на первом этапе описывают решение поставленной задачи, выделяя общие подзадачи.
На следующем аналогично описывают подзадачи, формулируя при этом элементы следующего уровня. Таким образом, на каждом шаге происходит уточнение функций проектируемого программного обеспечения. Процесс продолжают, пока не доходят до подзадач, алгоритмы, решения которых очевидны.
При этом необходимо, в первую очередь, детализировать управляющие процессы, оставляя уточнение операций с данными напоследок. Это связано с тем, что приоритетная детализация управляющих процессов существенно упрощает структуру компонентов всех уровней иерархии и позволяет не отделять процесс принятия решения от его выполнения. Определив условие выбора некоторой альтернативы, сразу же вызывают модуль, ее реализующий.
Функциональная схема или схема данных (ГОСТ 19. 701-90) — схема взаимодействия компонентов программного обеспечения с описанием информационных потоков, состава данных в потоках и указанием используемых файлов и устройств. Для изображения этих схем используют специальные обозначения, установленные стандартом.
Функциональные схемы более информативны, чем структурные. На рис. 4.4 для сравнения приведены функциональные схемы программных комплексов и систем.
б)
Рис. 4.4. Примеры функциональных схем: а — комплекс программ, б — программная система.
Все компоненты структурных и функциональных схем должны быть описаны. При структурном подходе особенно тщательно необходимо прорабатывать спецификации межпрограммных интерфейсов, так как от них зависят самые дорогостоящие ошибки.
Структурное проектирование использует три основных вида моделей (диаграмм):
1) SADT (Structured Analysis and Design Technique — метод структурного анализа и проектирования) — модели и соответствующие функциональные диаграммы;
2) DFD (Data Flow Diagrams) — диаграммы потоков данных;
3) ERD (Entity-Relationship Diagrams) — диаграммы «сущность-связь».
Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями.
Главным компонентом модели является диаграмма. На ней все функции и интерфейсы представлены в виде блоков и дуг соответственно. Место соединения дуги с блоком определяет тип интерфейса. Управляющая информация входит в блок сверху. Входная информация, которая подвергается обработке, показана с левой стороны блока, а результат (выход) — с правой.
Механизм (человек или автоматизированная система), который осуществляет операцию, представляется дугой, входящей в блок снизу (рис. 4.5).
Построение SADT-модели начинается с представления всей системы в виде простейшего компонента — одного блока и дуг, изображающих интерфейс с функциями вне системы. Затем этот блок детализируется на другой диаграмме с помощью нескольких блоков, соединенных интерфейсным дугами. Новые блоки определяют основные подфункции исходной функции, которые, в свою очередь, могут быть детализировании и т.д. (см. рис. 4.6).
Рис. 4.6
Диаграммы потоков данных (DFD) являются основным средством моделирования функциональных требований к проектируемой системе. С их помощью эти требования представляются в вид иерархий функциональных компонентов (процессов), связанных потоками данных. Главная цель такого представления — продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.
Основными компонентами диаграмм потоков данных являются:
a) внешние сущности;
b) системы и подсистемы;
d) накопители данных;
Внешняя сущность представляет собой материальный объект или физическое лицо, являющийся источником или приемником информации. Она изображается объемным прямоугольником с надписью, как показано на рисунке 4.7.
Подсистема (см. рис. 4.8) или процесс (рис. 4.9) представляются прямоугольником с закругленными краями. Он содержит три поля:
c) Физической реализации.
Подсистема и процесс отличаются именем. В первой записывается название подсистемы, а во втором – глагол, определяющий, что делает процесс.
Рис. 4.8. ГНИ – Государственная налоговая инспекция
Накопитель данных — это абстрактное устройство для хранения информации. Он изображается, как показано на рис. 4.10. Его обозначение начинается с буквы D.
Пример диаграммы потоков данных приведен на рис. 4.11.
Более сложная диаграмма потоков данных приведена на рис. 4.12.
ER-диаграммы будут рассмотрены позднее.
В курсовом проекте, кроме функциональной диаграммы, необходимо представить схемы алгоритмов наиболее сложных функций (например, сортировки и поиска).
Источник: poznayka.org