Поможем написать учебную работу
Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Билет7 1.Численное дифференцирование Это попытка угадать значение производной для функции, заданной в виде таблицы. Но ведь производная определена только для непрерывных и дифференцируемых функций. Поэтому здесь вводят гипотезу, что табличная функция заменяет собою некоторый алгебраический полином. Вот его-то и дифференцируют. Значит, идея такова: надо найти интерполяционный (или даже аппроксимирующий) полином, а потом его продифференцировать. Численное дифференцирование используется для приближенного вычисления производных функции заданной таблицей и для функций, которые по разным причинам неудобно или невозможно дифференцировать аналитически. В последнем случае вычисляется таблица функции в окрестности исследуемой точки и по этим значениям вычисляется приближенное значение производной. Итак, пусть в точках xi, i=0,1,2,...n известны значения функции yi=f(xi). Способ построения формул численного дифференцирования состоит в том, что по табличным точкам строится интерполянт Pn(x), который дифференцируется нужное число раз, и делается допущение о том, что производная от функции приблизительно равна производной от интерполянта Погрешность такой формулы характеризуется k-той производной от ошибки интерполяции. Один из универсальных способов построения формул численного дифференцирования состоит в том, что по значениям функции f(x) в некоторых узлах x0 , x1 , ... , xN строят интерполяционный полином PN(x) (обычно в форме Лагранжа) и приближенно полагают f(r)(x) P(r)N(x), 0 ≤ r ≤ N 3. Сущность структурного подхода проектирования ИС Сущность структурного подхода к разработке ИС заключается в ее декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. Все наиболее распространенные методологии структурного подхода базируются на ряде общих принципов. В качестве двух базовых принципов используются следующие: принцип "разделяй и властвуй" - принцип решения сложных проблем путем их разбиения на множество меньших независимых задач, легких для понимания и решения; принцип иерархического упорядочивания - принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне. Выделение двух базовых принципов не означает, что остальные принципы являются второстепенными, поскольку игнорирование любого из них может привести к непредсказуемым последствиям (в том числе и к провалу всего проекта). Основными из этих принципов являются следующие: принцип абстрагирования - заключается в выделении существенных аспектов системы и отвлечения от несущественных; принцип непротиворечивости - заключается в обоснованности и согласованности элементов; принцип структурирования данных - заключается в том, что данные должны быть структурированы и иерархически организованы. В структурном анализе используются в основном две группы средств, иллюстрирующих функции, выполняемые системой и отношения между данными. Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенными среди которых являются: SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы; DFD (Data Flow Diagrams) диаграммы потоков данных; ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь". На стадии проектирования ИС модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм. Перечисленные модели в совокупности дают полное описание ИС независимо от того, является ли она существующей или вновь разрабатываемой. Состав диаграмм в каждом конкретном случае зависит от необходимой полноты описания системы. 4.Основные особенности протокола UDP. UDP - универсальный протокол передачи данных, более облегченный транспортный протокол, чем TCP. Основные отличия от TCP:
UDP используется если не требуется гарантированная доставка пакетов, например, для потокового видео и аудио, DNS (т.к. данные н ебольших размеров). Если проверка контрольной суммы выявила ошибку или если процесса, подключенного к требуемому порту, не существует, пакет игнорируется (уничтожается). Если пакеты поступают быстрее, чем модуль UDP успевает их обрабатывать, то поступающие пакеты также игнорируются. Структура дейтограммы UDP. Слова по 32 бита. Не все поля UDP-пакета обязательно должны быть заполнены. Если посылаемая дейтаграмма не предполагает ответа, то на месте адреса отправителя могут помещаться нули. 5.Имитационное моделирование и компьютерное моделирование. Основные особенности имитационных моделей. 1) Имитационное моделирование это вид моделирования, при котором логико-математическая модель исследуемого объекта (системы) представляет собой алгоритм его функционирования, реализованный в виде программного комплекса для компьютера. Т.е., программная модель, реализующая алгоритм функционирования исследуемой системы. Для настоящего времени это не совсем точное определение: во-первых, на компьютерах сейчас практически реализуются любые виды моделей, во-вторых, наличие алгоритма не является единственной отличительной особенностью современного понимания имитационного моделирования. Шеннон Р. дает такое определение: имитационное моделирование есть А) процесс конструирования модели реальной системы и Б) постановки экспериментов на этой модели с целью понять поведение системы, либо оценить (в рамках ограничений, некоторым критерием или совокупностью критериев) различные стратегии, обеспечивающие функционирование системы. 2) Компьютерное моделирование В настоящее время компьютеры используются практически при любом способе реализации моделей:
Компьютерное моделирование - метод решения задачи анализа или синтеза сложной системы на основе использования ее компьютерной модели. Суть компьютерного моделирования заключена в получении количественных и качественных результатов по имеющейся модели. Качественные выводы, получаемые по результатам анализа, позволяют обнаружить неизвестные ранее свойства сложной системы: ее структуру, динамику развития, устойчивость, целостность и др. Количественные выводы в основном носят характер прогноза некоторых будущих или объяснения прошлых значений переменных, характеризирующих систему. Предметом компьютерного моделирования могут быть любой реальный объект или процесс, и вообще - любая Сложная Система. Например: экономическая деятельность фирмы или банка, промышленное предприятие, информационно-вычислительная сеть, технологический процесс. |
2. Каскадная модель ЖЦ ИС. Недостатки каскадной модели. Каскадная модель (КМ) характерна для классического подхода к разработке различных систем в любых прикладных областях. Для разработки ИС данная модель широко использовалась в 70-80-х годах. КМ предусматривает последовательную организацию работ. При этом основной особенностью является разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будут полностью завершены все работы на предыдущем этапе. Каждый этап завершается выпуском полного комплекта документации. Основные этапы разработки по КМ · анализ требований заказчика ; · проектирование ; · разработка ; · тестирование и опытная эксплуатация ; · сдача готового проекта . На первом этапе проводится исследование проблемы, четко формулируются требования заказчика. Результат этапа техническое задание (ТЗ), согласованное со всеми сторонами.
Этапы работы в рамках КМ называют частями проектного цикла системы, т.к. этапы состоят из многих итерационных процедур уточнения требований к системе и вариантов проектных решений. Основные достоинства каскадной модели 1. на каждом этапе формулируется законченный набор проектной документации, отвечающий критериям полноты и согласованности. На заключительных этапах разрабатывается также пользовательская документация, охватывающая все предусмотренные стандартами виды обеспечения ИС: организационное, методическое, информационное, программное, аппаратное; 2. выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения и соответствующие затраты; 3. КМ изначально разрабатывалась для решения различных инженерных задач и не потеряла своего значения для прикладной области до настоящего времени. Кроме того, каскадный подход хорошо зарекомендовал себя и при построении ИС определенного типа. Имеются в виду ИС, для которых в самом начале можно точно и полно сформулировать все требования и предоставить разработчикам свободу выбора способа реализации. К таким системам относятся сложные расчетные системы, системы реального времени и ряд других. Недостатки каскадной модели Недостатки каскадной модели ограничивают ее применение при разработке ИС. Причем эти недостатки делают ее либо полностью неприемлемой, либо приводят к существенному увеличению сроков разработки и стоимости проекта. 1. существенная задержка получения результатов; 2. необходимость возврата на предыдущие этапы; 3. сложность распараллеливания работ по проекту; 4. информационная перенасыщенность каждого этапа; 5. сложность управления проектом ; 6. высокий уровень риска и ненадежности инвестиций. Задержка полученных результатов считается главным недостатком каскадной схемы. Этот недостаток проявляется в основном в том, что вследствие последовательного подхода к разработке согласование результатов производится только после завершения очередного этапа. Поэтому может оказаться, что разрабатываемая ИС не соответствует требованиям пользователей. Причем такие несоответствия могут возникать на любом этапе, т.к. искажения могут непреднамеренно вноситься и проектировщиками, и программистами в силу того, что они не всегда хорошо разбираются в тех предметных областях, для которых разрабатывается ИС. Кроме того, используемые при разработке ИС модели автоматизируемого объекта могут в силу различных причин устареть за время разработки. Это относится и к функциональной модели, и к информационной модели, и к проектам интерфейса пользователя, и к пользовательской документации. Необходимость возврата на предыдущие стадии является одним из проявлений предыдущего недостатка. Как правило, ошибки, допущенные на более ранних этапах, обнаруживаются только на последующих. Поэтому после проявления ошибки проект возвращается на предыдущий этап, перерабатывается и снова передается на следующую стадию. Как следствие, срыв графика работ и усложнение взаимоотношений между группами разработчиков, выполняющих отдельные этапы. Самое неприятное это то, что недоработки могут обнаружиться не на следующем этапе, а позднее (например, на стадии опытной эксплуатации могут проявиться ошибки в описании предметной области). Это означает, что часть проекта должна быть возвращена на начальный этап. Сложность параллельного ведения работ связана с необходимостью постоянного согласования различных частей проекта. В результате работа одних групп разработчиков сдерживается другими. Кроме того, при последовательной разработке чрезвычайно сложно внести изменения в проект после завершения очередного этапа и передачи проекта на следующую стадию Информационная перенасыщенность является следствием сильной взаимосвязи групп разработчиков. Суть ее в том, что при внесении изменений в одну из частей проекта необходимо оповещать всех разработчиков, которые использовали эту часть в своей работе. При этом надо еще выяснить, не сказались ли внесенные изменения на уже полученных результатах. Повторное тестирование и, возможно, изменения в уже готовых частях проекта. Отражение этих вторичных изменений во внутренней документации и новое оповещение всех групп. Быстрый рост объема документации. А если еще и ротация кадров . . . Сложность управления проектом обусловлена строгой последовательностью стадий разработки и наличием сложных взаимосвязей между частями проекта. Последовательная разработка одни группы разработчиков должны ждать результатов работы других. Требуется административное вмешательство для согласования сроков работы и состава передаваемой документации. А если обнаружена ошибка и необходим возврат к предыдущим стадиям? поиск виновных сложные отношения в коллективе проблемы у руководства; несовместимость строгой дисциплины и творчества самые талантливые разработчики уйдут. Высокий уровень риска. Чем сложнее проект, тем больше продолжительность каждого этапа разработки. Результат можно увидеть лишь в конце работ. Изменения в предметной области или в законодательстве изменения в проекте «зацикливание» процесса разработки. Расходы растут, срок сдачи откладывается. Поэтому сложные проекты, разрабатываемые по КС, имеют повышенный уровень риска. По данным консалтинговой компании The Standish Group, в США более 31% проектов КИС (IT-проектов) прогорают; почти 53% IT-проектов завершаются с перерасходом бюджета в среднем на 189%, и только 16,2% проектов укладываются и в срок, и в бюджет. 6.Классификация моделей данных Понятие «данные» в концепции баз данных это набор конкретных значений, параметров, характеризующих объект, условие, ситуацию или любые другие факторы. Примеры данных: Петров Николай Степанович, $30 и т. д. Данные не обладают определенной структурой, данные становятся информацией тогда, когда пользователь задает им определенную структуру, то есть осознает их смысловое содержание. Поэтому центральным понятием в области баз данных является понятие модели Модель данных это некоторая абстракция, которая, будучи приложима к конкретным данным, позволяет пользователям и разработчикам трактовать их уже как информацию, то есть сведения, содержащие не только данные, но и взаимосвязь между ними. Классификация моделей данных Физическая модель данных оперирует категориями, касающимися организации внешней памяти и структур хранения, используемых в данной операционной среде. В настоящий момент в качестве физических моделей используются различные методы размещения данных, основанные на файловых структурах: это организация файлов прямого и последовательного доступа, индексных файлов и инвертированных файлов, файлов, использующих различные методы кэширования, взаимосвязанных файлов. Кроме того, современные СУБД широко используют страничную организацию данных. Физические модели данных, основанные на страничной организации, являются наиболее перспективными. При проектировании БД существует еще один уровень, предшествующий им. Модель этого уровня должна выражать информацию о предметной области в виде, независимом от используемой СУБД. Эти модели называются инфологическими, или семантическими, и отражают в естественной и удобной для разработчиков и других пользователей форме информационно-логический уровень абстрагирования, связанный с фиксацией и описанием объектов предметной области, их свойств и их взаимосвязей. Инфологические модели данных используются на ранних стадиях проектирования для описания структур данных в процессе разработки приложения, а даталогические модели уже поддерживаются конкретной СУБД. Документальные модели данных соответствуют представлению о слабоструктурированной информации, ориентированной в основном на свободные форматы документов, текстов на естественном языке. Тезаурусные модели основаны на принципе организации словарей, содержат определенные языковые конструкции и принципы их взаимодействия в заданной грамматике. Эти модели эффективно используются в системах-переводчиках, особенно многоязыковых переводчиках. Принцип хранения информации в этих системах и подчиняется тезаурусным моделям. Дескрипторные модели самые простые из документальных моделей, они широко использовались на ранних стадиях использования документальных баз данных. В этих моделях каждому документу соответствовал дескриптор описатель. Этот дескриптор имел жесткую структуру и описывал документ в соответствии с теми характеристиками, которые требуются для работы с документами в разрабатываемой документальной БД. Например, для БД, содержащей описание патентов, дескриптор содержал название области, к которой относился патент, номер патента, дату выдачи патента и еще ряд ключевых параметров, которые заполнялись для каждого патента. Обработка информации в таких базах данных велась исключительно по дескрипторам, то есть по тем параметрам, которые характеризовали патент, а не по самому тексту патента. |