Привет студент. Нисходящее и восходящее проектирование Описание входной информации
Если решение задач высоких иерархических уровней предшествует решению задач более низких иерархических уровней, то проектирование называют нисходящим (пошаговая детализация). Если раньше выполняются этапы, связанные с низшими иерархическими уровнями, проектирование называют восходящим .
У каждого из этих двух видов проектирования имеются преимущества и недостатки. При нисходящем проектировании система разрабатывается в условиях, когда ее элементы еще не определены и, следовательно, сведения о их возможностях и свойствах носят предположительный характер. При восходящем проектировании, наоборот, элементы проектируются раньше системы, и, следовательно, предположительный характер имеют требования к элементам. В обоих случаях из-за отсутствия исчерпывающей исходной информации имеют место отклонения от потенциально возможных оптимальных технических результатов. Однако нужно помнить, что подобные отклонения неизбежны при блочно-иерархическом подходе к проектированию и что какой-либо приемлемой альтернативы блочно-иерархическому подходу при проектировании сложных объектов не существует. Поэтому оптимальность результатов блочно-иерархического проектирования следует рассматривать с позиций технико-экономических показателей, включающих в себя, в частности материальные и временные затраты на проектирование.
Поскольку принимаемые предположения могут не оправдаться, часто требуется повторное выполнение проектных процедур предыдущих этапов после выполнения проектных процедур последующих этапов. Такие повторения обеспечивают последовательное приближение к оптимальным результатам и обусловливают итерационный характер проектирования. Следовательно, итерационность нужно относить к важным принципам проектирования сложных объектов.
На практике обычно сочетают восходящее и нисходящее проектирование. Например, восходящее проектирование имеет место на всех тех иерархических уровнях, на которых используются унифицированные элементы. Очевидно, что унифицированные элементы, ориентированные на применение в ряде различных систем определенного класса, разрабатываются раньше, чем та или иная конкретная система этого класса.
Достоинство нисходящего проектирования состоит в том, что оно позволяет разработчикам сосредоточиться на основных для данного проблемах и отложить принятие всех тех решений, которые не должны приниматься на данном этапе проектирования. Нисходящее проектирование требует с самого начала ставить и решать наиболее фундаментальные задачи, откладывая частные вопросы для последующего рассмотрения.
СТРУКТУРНОЕ ПРОЕКТИРОВАНИЕ И ПРОГРАММИРОВАНИЕ
Нисходящее проектирование
Модульное программирование
Структурное программирование
Метод нисходящего проектирования предполагает последовательное разложение общей функции обработки данных на простые функциональные элементы ("сверху-вниз").
В результате строится иерархическая схема, отражающая состав и взаимоподчиненность отдельных функций, которая носит название функциональная структура алгоритма (ФСА) приложения.
Последовательность действий по разработке функциональной структуры алгоритма приложения:
определяются цели автоматизации предметной области и их иерархия (цель-подцель);
устанавливается состав приложений (задач обработки), обеспечивающих реализацию поставленных целей;
уточняется характер взаимосвязи приложений и их основные характеристики (информация для решения задач, время и периодичность решения, условия выполнения и др.);
определяются необходимые для решения задач функции обработки данных;
выполняется декомпозиция функций обработки до необходимой структурной сложности, реализуемой предполагаемым инструментарием.
Подобная структура приложения (рис. 18.2) отражает наиболее важное – состав и взаимосвязь функций обработки информации для реализации приложений, хотя и не раскрывает логику выполнения каждой отдельной функции, условия или периодичность их вызовов.
Разложение должно носить строго функциональный характер, т.е. отдельный элемент ФСА описывает законченную содержательную функцию обработки информации, которая предполагает определенный способ реализации на программном уровне.
По частоте использования функции делятся на:
однократно выполняемые;
повторяющиеся.
Степень детализации функций может быть различной, но иерархическая схема должна давать представление о составе и структуре взаимосвязанных функций и общем алгоритме обработки данных. Широко используемые функции приобретают ранг стандартных (встроенных) функций при проектировании внутренней структуры программного продукта.
Пример 18.4. Некоторые функции, например Ф2, далее неразложимы на составляющие: они предполагают непосредственную программную реализацию. Другие функции, например Ф1, Фm, могут быть представлены в виде структурного объединения более простых функций, например Ф11, Ф12 и т.д. Для всех функций-компонентов осуществляется самостоятельная программная реализация; составные функции (типа Ф1, Фm) реализуются как программные модули, управляющие функциями-компонентами, например, в виде программ-меню.
0(Лекция 5)
Методы проектирования БД
Целью проектирования БД является адекватное отображение в базе данных сути предметной области, рассматриваемой с точки зрения решения задачи автоматизации.
В теории баз данных существует ряд методов разработки моделей БД, отображающих разные уровни её архитектуры. Распространены два основных подхода к проектированию систем баз данных: "нисходящий" и "восходящий".
Известен также подход "смешанной стратегии" - сначала «восходящий» и «нисходящий» методы используются для разных частей модели, после чего все подготовленные фрагменты собираются в единое целое.
Рассмотрим на рисунке отличие этих методов
Рисунок - Выбор метода проектирования
Метод восходящего проектирования БД
При «восходящем» подходе осуществляют структурное проектирование снизу-вверх. Этот процесс называют процессом синтеза, попыткой получения целого, адекватно отображающего описание предметной области, на основе описания составляющих его частей.
Этапы проектирования БД методом «восходящего» проектирования представлены на рисунке 2.
ДЛМ - даталогическая модель; НФ - нормальная форма; ИЛМ -информационно-логическая модель предметной области; МБД - модель БД.
Рисунок 2 - Этапы проектирования БД методом «восходящего» проектирования
Работа для реляционной БД начинается с определения свойств объектов (атрибутов сущностей) предметной области, которые на основе анализа существующих между ними связей группируются в реляционные отношения (таблицы), отображающие эти объекты (в том случае, если мы проектируем структуру реляционной БД).
Как правило, получают 2 - 3 реляционных отношения, связанных между собой.
Избыточность данных в ненормализованной схеме - повторение данных в БД.
Для того чтобы полученная структура БД (ДЛМ) не обладала различными аномалиями при добавлении, обновлении или удалении данных вследствие их избыточности, необходимо осуществить проверку каждой полученной схемы отношения, как минимум, на соответствие 3НФ. Если схемы отношений не соответствуют этому условию, а они, как правило, не соответствуют, необходимо проводить процесс нормализации.
Значительный объем мероприятий по нормализации схем реляционных отношений даже дал второе название методу «восходящего» проектирования. Этот метод часто называют методом «нормализации».
Основы теории нормализации создал Э. Кодд.
Нормализация - это процесс проектирования в терминах РМД методом последовательных приближений к удовлетворительному набору схем.
Совокупность схем отношений называется схемой реляционной БД.
Нормализация исключает избыточность и аномалии в БД.
Аномалии в ненормализованной схеме отношения:
а) обновления - противоречивость данных, вызванная их избыточностью и частичным обновлением.
Пример: Схема2
(Код преподавателя, ФИО преподавателя, Код кафедры, Название кафедры, Краткое название кафедры, Код должности, Название должности)
б) аномалия удаления - непреднамеренная потеря данных, вызванная удалением других данных
в) аномалия ввода - невозможность ввести данные в таблицу, вызванная отсутствием других данных.
Схема2 (Код преподавателя, ФИО преподавателя, Код кафедры, Название кафедры, Краткое название кафедры, Код должности, Название должности)
Этапы проектирования БД методом нормализации:
1. Определение всех атрибутов, сведения о которых будут включены в БД -сбор сырых данных на предприятии.
2. Составление списка сырых данных в виде схем реляционных отношений. Полученная в итоге схема отношений находятся в нулевой нормальной форме (0НФ).
3. Приведение схемы отношения к 1НФ
Опр. 1НФ: Схема отношения находится в 1НФ тогда и только тогда, если все атрибуты схемы имеют атомарное значение и в схеме отношений отсутствуют повторяющиеся группы.
Опр.: повторяющаяся группа - один или более элементов данных, которые имеют более одного значения для одного значения части ключа. Рассматривается, если первичный ключ составной.
Разбиение схемы отношения на атомарные атрибуты.
Удаление повторяющихся групп.
ПГ: ЗАКАЗ (Номер заказчика, Ф.,И.,О., тел., дата, Номер заказа)
Первичный ключ - Номер заказчика, Дата, Номер заказа (если в один день заказчик может оформить более чем один заказ)
Повторяющаяся группа: Ф,И,О, телефон - повторяются в каждой новой записи при формировании информации о новом заказе, хотя эта информация относится к части составного ключа - Номер заказчика.
Нужно вынести в отдельную схему отношений:
ЗАКАЗ (№ заказчика, дата, № заказа)
ФИЗИЧЕСКОЕ ЛИЦО (№ заказчика, Ф,И,О, телефон)
Связь 1:М между 2-мя новыми схемами отношений, «много» на стороне отношения ЗАКАЗ.
Каждое ФИЗИЧЕСКОЕ ЛИЦО может оформить много ЗАКАЗОВ.
Каждый конкретный ЗАКАЗ оформлен одним и только одним ФИЗИЧЕСКИМ ЛИЦОМ.
4. Изучение смысла (семантики) данных и определение набора атрибутов -потенциального (уникального) ключа отношения. М.б. несколько уникальных ключей.
Уникальный (потенциальный) ключ - атрибут или набор атрибутов, который полностью и однозначно определяет значения других атрибутов.
5. Если отношение обладает несколькими потенциальными ключами, то нужно выбрать среди них кандидата в первичный ключ.
6. Выявление функциональных зависимостей между атрибутами нормализуемой схемы отношения.
Опр.: функциональной зависимостью атрибута В (набора атрибутов) отношения R от атрибута (набора атрибутов) А отношения R, обозначаемой R.A -> R.B A->B
называется такая связь между атрибутами отношения, что в каждый момент времени каждому значению атрибута (набору атрибутов) В соответствует только одно значение атрибута (набора атрибутов) А.
Однако для заданного значения атрибута В может существовать несколько различных значений атрибута А.
Таким образом, если из семантики предметной области нам известно значение атрибута А, то мы в предметной области однозначно можем определить значение атрибута В.
ФЗ является смысловым свойством атрибутов отношения.
В отношении м.б. выявлено много функциональных зависимостей, т.е. в отношении м.б. выявлено много детерминантов.
Опр.: ключевой атрибут - атрибут, входящий в состав первичного ключа Опр.: не ключевой атрибут - атрибут, не входящий в состав первичного ключа.
Опр.: частичная ФЗ - это зависимость не ключевого атрибута от части составного первичного ключа.
Опр.: полная ФЗ - это зависимость не ключевого атрибута от всего составного первичного ключа.
Имеет смысл рассматривать полную и частичную ФЗ в том случае, если ПК - составной.
Работа(Номер школы (ВК1); Номер инструктора (ПК); Фамилия инструктора; Имя инструктора; Отчество инструктор; Серия паспорта; Номер паспорта; Дата принятия на работу; Госномер автомобиля; Код вида занятий (ВК3))
Функциональные зависимости:
Номер инструктора -> Номер школы Номер инструктора -> Фамилия инструктора Номер инструктора -> Имя инструктора
Номер инструктора -> Отчество инструктора Номер инструктора - >Серия паспорта Номер инструктора -> Номер паспорта Номер инструктора - >Код образования Номер инструктора - >Дата принятия на работу Номер инструктора - >Госномер автомобиля
Функционально полно от первичного ключа Номер инструктора, Код вида занятий не зависит ни один не ключевой атрибут.
Для приведения к 2НФ необходимо выявит подмножество ФЗ не ключевых атрибутов от составного первичного ключа. Сколько не ключевых атрибутов -столько ФЗ!
Замечание: полное множество ФЗ определяется на основе аксиом и теорем теории множеств.
7. Приведение схемы отношения к 2НФ Технология приведения ко 2НФ:
1) В отдельную схему отношения выносится составной первичный ключ и те атрибуты, которые функционально полно зависят от него. Если таких атрибутов нет, то первичный ключ выносится один.
2) В отдельную схему выносится часть первичного ключа и те атрибуты, которые функционально полно зависят от этой части.
Сколько частей первичного ключа образовали частичные ФЗ, столько схем получаем
3) Исходная схема удаляется.
8. Определение транзитивных зависимостей в каждом нормализуемом отношении
Опр.: транзитивная зависимость - атрибут С отношения R транзитивно зависит от атрибута А отношения R, если для атрибутов А, В, С выполняется условие существования следующих ФЗ:
при условии, что атрибут А функционально не зависит ни от атрибута В, ни от атрибута С.
9. Удаление транзитивных зависимостей путем декомпозиции схем отношений
10 Определение условий необходимости анализа схем отношений на соответствие НФБК (нормальной формы Бойса - Кодда - BCNF)
Эта нормальная форма вводит дополнительное ограничение по сравнению с
Опр.: Отношение находится в НФБК, если оно находится в 3НФ и каждый детерминант отношения является потенциальным ключом отношения.
Опр.: Детерминантом ФЗ называется атрибут (набор атрибутов),
расположенный в левой части ФЗ, т.е. от детерминанта функционально полно зависит некоторый другой атрибут (атрибуты)
В отношении м.б. несколько детерминантов
Ситуация, когда отношение будет находиться в 3НФ, но не в НФБК, возникает при условии, что отношение имеет два (или более) возможных (потенциальных) ключа, которые являются составными и имеют общий атрибут.
Таким образом, НФБК учитывает ФЗ, в которых участвуют все потенциальные ключи отношения, а не только ПК.
На практике такая ситуация встречается достаточно редко, и для всех прочих отношений 3NF и BCNF эквивалентны.
Для отношения с единственным потенциальным ключом его 3НФ эквивалентна и НФБК.
Таким образом, для успешного проведения нормализации (до 3НФ) необходимо на основе анализа предметной области (анализа документов
предметной области) для каждой схемы реляционного отношения:
Выявить потенциальные ключи;
Увидеть повторяющиеся группы и не атомарные атрибуты;
Привести схемы отношения к 1НФ;
Определить функциональные зависимости между не ключевыми атрибутами и первичным ключом;
Определить частичные функциональные зависимости;
Осуществить декомпозицию (деление) соответствующих схем отношений для удалений частичных функциональных зависимостей;
Увидеть транзитивные зависимости между не ключевыми атрибутами и первичным ключом;
Исключить транзитивные зависимости путем декомпозиции
соответствующих схем отношений.
Проведение этих мероприятий является достаточно трудоемким процессом. Так, например, выявление полного множества функциональных зависимостей потребует знаний теории множеств и предикатной логики.
Для приведения схем отношений к более высоким нормальным формам необходимо проведение дополнительного исследования предметной области для определения детерминантов отношений, выявления многозначных зависимостей между атрибутами отношения, зависимостей соединения.
Рассмотрим на рисунке схему процесса нормализации
Рисунок - Схема процесса нормализации
«Восходящее» проектирование - это достаточно сложная и устаревшая методика, которая подходит для проектирования только небольших баз данных.
Предметная область - автоматизация учета личных данных инструкторов сети школ авто вождения.
Возросло количество обучающихся, возрос и контингент инструкторов, появилась необходимость автоматизации.
На этапе общения с заказчиком были определены следующие атрибуты, которые необходимо хранить и обрабатывать:
Номер школы;
ФИО инструктора;
Дата рождения;
Номер, серию паспорта;
Дата принятия на работу;
Госномер автомашины, которая закреплена за инструктором (необходимо хранить
последнюю запись - желание заказчика, хотя по-хорошему надо хранить историю);
Вид занятий, которые проводит сотрудник (лекция, вождение), также хранить только последнюю информацию - фотография момента, история не нужна.
Выявленные ограничения предметной области:
Все данные должны быть обязательными.
За одним автомобилем м.б. закреплено несколько инструкторов.
Номер сотрудника уникальный в пределах всей ИС, охватывающей сеть школ.
Наполнение строк реальными данными позволило выявить кандидата в первичный ключ. Серия и номер документа удостоверяющего личность состоит из двух атрибутов, его можно заменить введение дополнительного номера - личный номер инструктора. Это выяснилось и в ходе дальнейшего обследования предметной области - сотрудник, ведущий личные дела инструкторов, присваивает каждому личный номер.
Поле "вид занятий" символьное, что нежелательно для атрибута, входящего в состав первичного ключа. В ходе дальнейшего анализа предметной области был выявлен документ, который перечислял существующие виды занятий автошколы, причем, записи были пронумерованы в шапке отчетного документа- 1 - руководство школой; 2- чтение теоретического курса; 3 - работа на тренажерах и т.д. и по каждому виду подводился итог. Появился атрибут, дополнительно описывающий вид занятий, причем числовой. Его необходимо добавить в схему отношения и сделать атрибутом первичного ключа, заменив, таким образом, длинное символьное поле.
Получили схему отношения:
ПК - первичный ключ - Номер инструктора; Код вида занятий
Необходимость нормализации: исходное отношение, находящееся в нулевой нормальной форме, содержит избыточные данные, что является причиной аномалий вставки - например, мы не можем внести данные о инструкторе, пока он не принесет сведения об образовании или не будет точно известен госномер и марка автомобиля, который за ним закрепляют. Аномалия обновления
Изменение госномера автомобиля (автомобиль списали) поведет за собой необходимость изменения этого поля во всех строках, где он упоминается (фиксируем только фотографию момента - за кем был последним закреплен автомобиль, но таких людей м.б. несколько и для их выявления необходимо проделать определенную работу, при чем работу администратора БД).
Явная избыточность - повторение названия вида занятий.
Неявная избыточность - изменение госномера автомобиля.
Дальнейшим, необходимым для нормализации, этапом работы является определение зависимостей между атрибутами на основе семантики предметной области.
Скачать лекцию: У вас нет доступа к скачиванию файлов с нашего сервера.
Методы проектирования программных продуктов
К концу 20 века не только существенно возросла сложность проектируемых объектов, но и их воздействие на общество и окружающую среду, тяжкость последствий аварий из-за ошибок разработки и эксплуатации, высокие требования к качеству и цене, сокращению сроков выпуска новой продукции. Необходимость учета этих обстоятельств заставляла вносить изменения в традиционный характер и методологию проектной деятельности.
При создании объектов их уже необходимо было рассматривать в виде систем , то есть комплекса взаимосвязанных внутренних элементов с определенной структурой, широким набором свойств и разнообразными внутренними и внешними связями. Сформировалась новая проектная идеология, получившая название системного проектирования.
Системное проектирование комплексно решает поставленные задачи, принимает во внимание взаимодействие и взаимосвязь отдельных объектов-систем и их частей как между собой, так и с внешней средой, учитывает социально-экономические и экологические последствия их функционирования. Системное проектирование основывается на тщательном совместном рассмотрении объекта проектирования и процесса проектирования, которые в свою очередь включают ещё ряд важных частей
Принципы системного проектирования
Системное проектирование должно базироваться на системном подходе. В настоящее время ещё нельзя утверждать, что известны их полные состав и содержание применительно к проектной деятельности, однако можно сформулировать наиболее важные из них:
· Практическая полезность:
o деятельность должна быть целенаправленной , устремленной на удовлетворение действительных потребностей реального потребителя или определенной социальной, возрастной или иной групп людей;
o деятельность должна быть целесообразной . Важно вскрыть причины, препятствующие использованию существующих объектов для удовлетворения новых потребностей, выявить вызывающие их ключевые противоречия и сконцентрировать усилия на решении главных задач;
o деятельность должна быть обоснованной и эффективной . Разумным будет использование не любого решения задачи, а поиск оптимального варианта ;
· Единство составных частей:
o целесообразно любой объект, сложный ли он или простой, рассматривать как систему , внутри которой можно выделить логически связанные более простые части - подсистемы , единство частных свойств которых и образует качественно новые свойства объекта-системы;
o разрабатываемые объекты предназначены для людей, ими создаются и эксплуатируются. Поэтому человек также обязан рассматриваться в качестве одной из взаимодействующих систем. При этом должно приниматься во внимание не только физическое взаимодействие, но и духовно-эстетическое воздействие;
o внешняя, или как её ещё называют - жизненная среда , также должна рассматриваться в качестве системы, взаимосвязанной с проектируемым объектом;
· Изменяемость во времени:
o учёт этапов жизненного цикла объекта;
o учёт истории и перспектив развития и применения разрабатываемого объекта, а также областей науки и техники, на достижениях которых базируются соответствующие разработки.
Нисходящее и восходящее проектирование
Ведение разработки объекта последовательно от общих черт к детальным называется нисходящим проектированием . Его результатом будут требования к отдельным частям и узлам. Возможен ход разработки от частного к общему, что образует процесс восходящего проектирования . Такое проектирование встречается, если одна или несколько частей уже являются готовыми (покупными или уже разработанными) изделиями.
Нисходящее и восходящее проектирование обладают своими достоинствами и недостатками. Так, при нисходящем проектировании возможно появление требований, впоследствии оказывающихся нереализуемыми по технологическим, экологическим или иным соображениям. При восходящем проектировании возможно получение объекта, не соответствующего заданным требованиям. В реальной жизни, вследствие итерационного характера проектирования, оба его вида взаимосвязаны.
Например, разрабатывая при нисходящем проектировании автомобиль (от общей схемы к его частям, например, - к мотору), необходимо увязать общую компоновку с размерами и мощностью уже выпускаемых двигателей. В противном случае придётся разрабатывать применительно к данной компоновке новый двигатель, либо изменять первоначальные варианты его расположения или схему компоновки всего автомобиля.
Подпрограммы
Структурное программирование
В предыдущем разделе рассматривались основные операторы и типы данных, необходимые для составления программ. При этом предполагалось, что текст программы представляет собой линейную последовательность операторов присваивания, цикла и условных операторов. Таким способом можно решать не очень сложные задачи и составлять программы, содержащие несколько сот строк кода. После этого понятность исходного текста резко падает из-за того, что общая структура алгоритма теряется за конкретными операторами языка, выполняющими слишком детальные, элементарные действия. Возникают многочисленные вложенные условные операторы и операторы циклов, логика становится совсем запутанной, при попытке исправить один ошибочный оператор вносится несколько новых ошибок, связанных с особенностями работы этого оператора, результаты выполнения которого нередко учитываются в самых разных местах программы. По этой причине набрать и отладить длинную линейную последовательность операторов практически невозможно.
При создании средних по размеру приложений (несколько тысяч строк исходного кода) используется структурное программирование, идея которого состоит по сути в том, что структура программы должна отражать структуру решаемой задачи, чтобы алгоритм решения был ясно виден из исходного текста. Для этого нужно иметь средства для создания программы не только с помощью трех простых операторов, но и с помощью средств, более точно отражающих конкретную структуру алгоритма. С этой целью в программирование введено понятие подпрограммы - набора операторов, выполняющих нужное действие и не зависящих от других частей исходного кода. Программа разбивается на множество мелких подпрограмм (занимающих до 50 операторов - критический порог для быстрого понимания цели подпрограммы), каждая из которых выполняет одно из действий, предусмотренных исходным заданием. Комбинируя эти подпрограммы, удается формировать итоговый алгоритм уже не из простых операторов, а из законченных блоков кода, имеющих определенную смысловую нагрузку, причем обращаться к таким блокам можно по названиям. Получается, что подпрограммы - это новые операторы или операции языка, определяемые программистом.
Возможность применения подпрограмм относит язык программирования к классу процедурных языков.
Наличие подпрограмм позволяет вести проектирование и разработку приложения сверху вниз - такой подход принято называть нисходящим проектированием. Сначала выделяется несколько подпрограмм, решающих самые глобальные задачи (к примеру, инициализация данных, главная часть и завершение), потом каждый из этих модулей детализируется на более низком уровне, разбиваясь в свою очередь на небольшое число других подпрограмм, и так происходит до тех пор, пока вся задача не окажется реализованной.
Такой подход удобен тем, что позволяет человеку постоянно мыслить на предметном уровне, не опускаясь до конкретных операторов и переменных. Вместе с тем, появляется возможность некоторые подпрограммы не реализовывать сразу, а временно откладывать, пока не будут закончены другие части. К примеру, если имеется крайне важность вычисления сложной математической функции, то выделяется отдельная подпрограмма такого вычисления, но реализуется она временно одним оператором, который просто присваивает заранее выбранное значение (к примеру, 5). Когда все приложение будет написано и отлажено, тогда можно приступить к реализации этой функции.
Немаловажно, что небольшие подпрограммы значительно проще отлаживать, что существенно повышает общую надежность всей программы.
Очень важная характеристика подпрограмм - это возможность их повторного использования. С интегрированными системами программирования поставляются большие библиотеки стандартных подпрограмм, которые позволяют значительно повысить производительность труда за счет использования чужой работы по созданию часто применяемых подпрограмм.
Рассмотрим пример, демонстрирующий методику нисходящего проектирования. Имеется массив Ocenki, состоящий из N (N > 2) судейских оценок (каждая оценка положительна). В некоторых видах спорта принято отбрасывать самую большую и самую маленькую оценки, чтобы избежать влияния необъективного судейства, а в зачет спортсмену идет среднее арифметическое из оставшихся оценок. Решим эту задачу, постепенно детализируя алгоритм (без привязки к конкретному языку программирования).
1. Процесс решения наиболее просто описывается подпрограммами:
Ввести_оценки_в_массив;
Удалить_самую_большую_оценку;
Удалить_самую_маленькую_оценку;
Вывести_результаты;
Теперь можно приступить к детализации каждой их этих подпрограмм.
2. Удалить_самую_большую_оценку;
Как удалить самую большую оценку из статического массива? Вместо нее можно просто записать значение 0, а при подсчете среднего арифметического нулевые значения не учитывать.
I = Номер_самого_большого_элеменша_в_массиве;
3. Удалить_самую_маленькую_оценку;
I = Номер_самого_маленького_элемента_в_массиве;
При реализации подпрограммы Номер_самого_маленького_элемента_в_массиве нужно учесть, что искать придется самое маленькое из положительных значений (больших нуля).
Здесь потребуется оператор цикла, вычисляющий сумму всех элементов массива Ocenki.
FOR I = 1 ТО N
SUM = SUM + Ocenki(I)
SUM = SUM / (N - 2)
В последнем операторе происходит вычисление среднего арифметического всех оценок. Сумма элементов массива делится на число элементов, уменьшенное на 2, потому что две оценки, самую большую и самую маленькую, учитывать не нужно.
В случае если бы эта задача решалась последовательно, то уже на этапе удаления оценок могли возникнуть определенные проблемы.
Реализацию подпрограмм Номер_самого_большого_элемента_в_массиве и Номер_ самого_маленького_элемента_в_массиве выполните самостоятельно.
Метод нисходящего проектирования предполагает последовательное разло- жение общей функции обработки данных на простые функциональные элементы ("сверху- / вниз"). В результате строится иерархическая схема, отражающая состав и взаимопод-чиненность отдельных... [читать подробенее]
Занятие 12-2 часа Метод нисходящего проектирования предполагает последовательное разложение общей функции обработки данных на простые функциональные элементы ("сверху- / вниз"). В результате строится иерархическая схема, отражающая состав и взаимоподчиненность... [читать подробенее]
Между всеми этапами проектирования существует глубокая взаимосвязь. Так, определение окончательной конструкции и разработка всей технической документации часто не могут быть выполнены до окончания разработки технологии. В процессе конструирования и разработки...