22.OLeDb-объектная модель.

Объекты базовой модели OLEDB:

-Data Source(источник данных)-для соединения с источником данных создания нескольких или 1 сеансов. Управляет соединением, использует информацию о полномочиях

-.объектные сеанс-управляет взаимодействием с источником данных, выполняет запросы и создает результатирующие наборы.

-объект-результатирующий набор. Представляет собой данные, извлекаемые в результате выполнения команды или создаваемые в сеансы.

23. Oledb-основные понятия.

OLEDB представляет собой набор com интерфейсов, которые предоставляют приложению-клиенту унифицированный доступ к различным источникам данных.

OLEDB-метод доступа к любым данным через стандартный com. Интерфейс в независимости от типа данных и места их расположения.

В качестве данных могут выступать БД, простые документы, таблицы Exel? Другие источники данных.

OLEDB позволяет реализовать доступ к источникам данных,как с применением языка SQL? Так и с др.производственными источниками данных.

Программы-клиенты используются для доступа OLEDB провайдеры называется потребителями данных

24. Програ́ммное обеспе́чение — все или часть программ, процедур, правил и соответствующей документации системы обработки информации.

Программное обеспечение принято по назначению подразделять на системное, прикладное и инструментальное, а по способу распространения и использования на несвободное (закрытое), открытое и свободное.

Программное обеспечение является одним из видов обеспечения вычислительной системы, наряду с техническим (аппаратным), математическим, информационным, лингвистическим, организационным и методическим обеспечением

Билет25

В основе проектирования информационной системы (ИС) лежит моделирование предметной обла­сти (МПО). Чтобы получить адекватный предметной области проект ИС необходимо иметь це­лостное, системное представление модели, которая должна отражать все аспекты функционирования будущей ИС. При этом под моделью предметной области понимается система, имитирую­щая структуру или функционирование исследуемой предметной области и отвечающая основному требованию - быть адекватной этой области.

Предварительное моделирование предметной области позволяет со­кратить время и сроки проведения проектировочных работ и получить эффективный и качественный проект.

К МПО предъявляются следующие требо­вания:

формализация, обеспечивающая однозначное описание структуры предметной области;

понятность для заказчиков и разработчиков на основе применения графических средств отображения модели;

реализуемость, подразумевающая наличие средств физической реализации модели предметной области в ИС;

обеспечение оценки эффективности реализации модели предметной области на основе определенных методов и вычисляемых показателей.

Для реализации перечисленных требований, как правило, строится система моделей, которая отражает структурный и оценочный аспекты функционирования предметной области.

Структурный аспект предполагает построение:

объектной структуры, отражающей состав взаимодействующих в процессах материальных и информационных объектов предметной области;

функциональной структуры, отражающей взаимосвязь функций (действий) по преобразованию объектов в процессах;

структуры управления, отражающей события и бизнес-правила, которые воздействуют на выполнение процессов;

организационной структуры, отражающей взаимодействие организационных единиц предприятия и персонала в процессах;

технической структуры, описывающей топологию расположения и способы коммуникации комплекса технических средств.

Для отображения структурного аспекта МПО и представления информации о компонентах системы в основном используются графические методы, которые должны обеспечить структурную де­композицию спецификаций с максимальной степенью детализа­ции. Осуществляется выбор языка представления проектных решений. Язык моде­лирования - это нотация, в основном графическая, которая используется для описания проектов. Нотация представляет собой совокупность графи­ческих объектов, используемых в модели. Нотация является синтаксисом языка моделирования. Язык моделирования должен делать решения проектировщиков понятными пользователю и предоставлять проектировщикам средства достаточно форма­лизованного и однозначного определения проектных решений, подлежа­щих реализации в виде программных комплексов, образующих целост­ную систему программного обеспечения.

Основной критерий адекватности структурной модели предметной области заключается в функциональной полноте разрабатываемой ИС.

26. Утилитарные программы - программы, предназначенные для удовлетворения нужд их разработчиков. Обычно такие программы решают задачи, не предназначенные для широкого распространения.

27

Программный продукт – комплекс взаимосвязанных программ для реше-ния определенной проблемы (задачи) массового спроса, подготовленный к реали-зации как любой вид промышленной продукции

Путь от "программ для себя до программных продуктов достаточно долгий, он связан с изменением технической и программной среды разработки и эксплуа-тации программ, с появлением и развитием самостоятельной отрасли - информа-ционного бизнеса, для которого характерны разделение труда фирм - разработчи-ков программ, их дальнейшая специализация, формирование рынка программных средств и информационных услуг.

Программные продукты должны создаваться как:

• Индивидуальная разработка под заказ;

• Разработка для массового распространения среди пользователей

При индивидуальной разработке фирма-разработчик создает оригинальный программный продукт, учитывающий специфику обработки данных для конкрет-ного заказчика.

При разработке для массового распространения фирма-разработчик, с одной стороны, должна обеспечить универсальность выполняемых функций о\д, а с дру-гой стороны, гибкость и настраиваемость ПП на условия конкретного примене-ния.

Отличительной особенностью ПП должна быть их системность - функцио-нальная полнота и законченность реализуемых функций обработки, которые при-меняются в совокупности.

ПП разрабатывается на основе промышленной технологии выполнения про-ектных работ с применением современных инструментальных средств програм-мирования. Специфика заключается в уникальности процесса разработки алго-ритмов и программ, зависящего от характера обработки данных и используемых инструментальных средств. На создание ПП затрачиваются значительные ресур-сы – трудовые, материальные, финансовые; требуется высокая квалификация раз-работчиков.

ПП требуют сопровождения, осуществляемого специализированными фир-мами – распространителями программ (дистрибьюторами), реже - фирмами-разработчиками. Сопровождение программ массового применения сопряжено с большими трудозатратами – исправление обнаруженных ошибок, создание новых версий программ и т.п

Билет №28

ТРЕБОВАНИЯ К ПРОГРАММНОМУ ИЗДЕЛИЮ

Основные:

1. использование собственных подпрограмм;

2. исходные данные должны хранятся на магнитном диске в типизированном файле;

3. обработка данных через вспомогательный массив записей;

4. действия, производимые с данными:

• ввод с клавиатуры (все поля, кроме вычисляемых)

• считывание данных из типизированного файла,

• вычисление поля для каждой записи

• просмотр (все данных) в виде таблицы без рамок,

• сохранение данных в типизированных файл

• поиск по критериям,

• поиск критических значений;

5. результаты поиска должны быть сохранены в текстовый файл;

6. удобный пользовательский интерфейс:

• заставка (название, описание действий, ФИО студента, группа, год),

• цветовое оформление;

• меню для выбора действий (цифровое),

• вспомогательные сообщения при вводе и ошибках при поиске или расчетах,

• при поиске данных выполнять подсчет количества записей,

7. после выполнения любого пункта меню возврат в главное меню.

Дополнительные:

1. действия, производимые с данными:

• редактирование,

• удаление,

• просмотр отсортированных данных;

2. удобный пользовательский интерфейс:

• рисованная или движущая заставка,

• вывод данных в таблице с рамкой,

• выбор пунктов меню управляющими клавишами (стрелками)

• использование функциональных клавиш,

• использование мыши

29 Принцип тестирования

Тестирование — это процесс порождения ошибок.

Принцип 1

Его единственная задача — найти ошибки, инициируя неудачное выполнение. Любое умозаключение по поводу качества относится к области гарантии качества, но никак не к области тестирования. Это определение также напоминает нам, что тестирование, в отличие от отладки, не связано с исправлением ошибок, — оно связано только лишь с их поиском.

Принцип 2.

Этот принцип касается всех ошибок, возникших во время разработки и тестирования. Отсюда вытекает необходимость в инструментарии, позволяющем превращать неудачное исполнение в воспроизводимый тестовый случай, и недавно такой инструментарий появился: Contract-Driven Development, ReCrash, JCrasher.

Принцип 3.

Эта формулировка оставляет открытым вопрос о форме таких предсказаний. Зачастую предсказания специфицируются отдельно. В исследованиях, таких как наше, они встроенные, поскольку анализируемое программное обеспечение уже включает в себя контракты, согласно которым тесты используются как предсказания.

Принцип 4.

Тестовые случаи, проверяемые вручную и автоматически. Эффективный процесс

тестирования должен включать в себя тестовые случаи, проверяемые как вручную, так и автоматически.

Достоинством тестов, выполняемых вручную, является их глубина: они отражают понимание разработчиком имеющегося круга проблем и структуры данных. Преимущество автоматических тестов в их широте: они выполняют проверку большого диапазона значений, в том числе экстремальных, которые люди могут пропустить.

Принцип 5.

Эмпирические оценки стратегий тестирования. Оценивайте любую стратегию тестирования, однако, какой бы интересной она ни казалась, прибегайте к объективной оценке, используя точные критерии в воспроизводимом процессе тестирования.

Принцип 6.

Функция обнаружения, то есть число ошибок в зависимости от времени fc (t), полезна по двум причинам — используя программную базу с известными ошибками, можно оценить стратегию, посмотрев, сколько ошибок база позволит обнаружить за данное время. Менеджеры проектов могут добавить fc (t) в модель надежности для оценки того, сколько еще ошибок осталось, и ответить на старый вопрос «Когда заканчивать тестирование?»

31

Программы любого вида характеризуются жизненным циклом, состоящим из отдельных этапов: a) Маркетинг рынка программных средств, спецификация требованиё к программному продукту;

b) Проектирование структуры программного продукта;

c) Программирование (создание программного продукта), тестирование, автономная и комплексная отладка программ;

d) Документирование программного продукта, подготовка эксплуатаци-онной и технологической документации;

e) Выход на рынок программных средств, распространение программно-го продукта;

f) Эксплуатация программного продукта пользователями;

g) Сопровождение программного продукта;

h) Снятие программного продукта с продажи, отказ от сопровождения.

Маркетинг и спецификация программного продукта предназначены для изучения требований к создаваемому программному продукту, а именно:

• Определение состава и назначения функций обработки данных про-граммного продукта;

• Установление требований пользователя к характеру взаимодействия с программным продуктом, типу пользовательского интерфейса (система меню, ис-пользование манипулятора мышь, типы подсказок, виды экранных документов и т.п.);

• Требования к комплексу технических и программных средств для экс-плуатации программного продукта и т.д.

32

Маркетинг и спецификация программного продукта предназначены для изучения требований к создаваемому программному продукту, а именно:

– определение состава и назначения функций обработки данных программного продукта;

– установление требований пользователя к характеру взаимодействия с программным продуктом, типу пользовательского интерфейса (система меню, использование манипулятора мышь, типы подсказок, виды экранных документов и т.п.);

– требования к комплексу технических и программных средств для эксплуатации программного продукта и т.д.

На данном этапе необходимо выполнить формализованную постановку задачи.

Если программный продукт создается не под заказ и предполагается выход на рынок программных средств, маркетинг выполняется в полном объеме: изучаются программные продукты-конкуренты и аналоги, обобщаются требования пользователей к программному продукту, устанавливается потенциальная емкость рынка сбыта, дается прогноз цены и объема продаж. Кроме того, важно оценить необходимые для разработки программного продукта материальные, трудовые и финансовые ресурсы, ориентировочные длительности основных этапов жизненного цикла программного продукта.

Если программный продукт создается как заказное программное изделие для определенного заказчика, на данном этапе также важно правильно сформулировать и документировать задание на его разработку. Ошибочно понятое требование к программному продукту может привести к нежелательным результатам в процессе его эксплуатации.

33.Документирование ПП

Все программы можно разделить на 2 класса:

1)утилитарные программы(т.е. программы для себя)

2)программные продукты(предназначены для широкого использования)

Freeware-бесплатные программы,в них можно вносить изменения

Shareware-условно-бесплатные

ПП-комплекс программ для решения определенных задач массового спроса.

ПП должны создаваться как:

-индивидуальная разработкка под заказ

Разработка для массового рспространения среди пользователей

При индивдуальной разаботке фирма-разработчик создает оригинальнй ПП,а при разработке для массового распространения фирма-разработчик должна обеспечить гибкость и настраиваемость.

Основными характеристиками программ явл-ся:размер ОП,версия ОС,тип процессора,объем файлов программ и алгоритмческая сложность

Мобильный ПП может быть установлен на различнх моделх компьютеров и ОС.

Надежность работы ПП определяется точностью выполнения функций и устойчивостью в работе.

Спецификой ПП явл-ся работа на правовой основе.

Программы любого вида характеризуются жизненным циклом,состоящим из этапов:

-маркетинг рынка программных средств

-программирование,тестирование

-документирование ПП

-эксплуатация и сопровождение ПП

Документирование ПП-обязательный вид работ,выполняемых не самим разработчиком,а лицом,связанным с распространением и внедрением ПП.

34 Метод моделирования процесса управления

В процессе изучения объекта проектирования строится экономико – ориентированное и информационно – логические модели, которые включают задачи, структуры и ресурсы объекта. Они отражают хозяйственные и управленческие отношения, а так же связанные с ним информационные потоки. Представляя комбинацию материальных и информационных процессов, способствует повышению уровня организации объекта. Информационо – логические модели содержат необходимые сведения об информационных связях между органами и сферами управления, комплексами решаемых задач и отдельными задачами в единстве с хозяйственными процессами.

35 Метод структурного(модульного) проектирования

Позволяет разработать проект четко разграниченных блоков, между которыми устанавливаются связи по средствам входной и выходной информации, а так же показывается иерархия их подчиненности. Условиями применения этого метода является разбиение крупных комплексов задач на подкомплексы и точное обозначение всех звеньев разъединения и сопряжения. МСП позволяет разделить весь комплекс задач на обозримые и поддающиеся анализу подкомплексы.

36)моделирование и анализ процессов, описывающих деятельность организации, технологические особенности работы. Целью является построение моделей существующих процессов, выявление их недостатков и возможных источников совершенствования. Этот этап не является обязательным в случае, когда существующие технология и организационные структуры четко определены, хорошо понятны и не требуют дополнительного изучения и реорганизации.

37 Метод графического представления фактического заданного состояния

Эти методы предусматривают использование для наглядного представления процессов обработки информации в форме блок-схем, графиков прохождения документов и т.д. Графические методы являются составной частью любого проекта и необходимы для практической работы, поскольку выполняют роль вспомогательного средства при внедрении новых технологий. К наиболее известным относятся блок-схемный метод, методы стрелочных диаграмм, сетевых графиков, таблиц последовательности операций прохождения процессов. Различия методов выражаются в степени их автоматизации, наглядности, глубине отражаемых процессов.

38. Основные понятия реинжиринга

«Реинжиниринг представляет собой систематическую трансформацию существующей системы с целью улучшения ее характеристик качества, поддерживаемой ею функциональности, понижения стоимости ее сопровождения, вероятности возникновения значимых для заказчика рисков, уменьшения сроков работ по сопровождению системы». Миграция, и модернизация ИС являются частью деятельности по реинжинирингу ИС.

Модернизация посвящена вопросам улучшения унаследованных информационных систем. В процессе модернизации делается обзор различных методик модернизации унаследованных систем, определяется роль модернизации систем в процессе управлениях их эволюцией. В миграции основное внимание уделяется исследованию и решению технических проблем, связанных с миграцией унаследованных систем. При этом миграция рассматривается как деятельность, которая начинается с унаследованной ИС и заканчивается сопоставимой целевой ИС.

39

Структу́рное программи́рование — методология разработки программного обеспечения, в основе которой лежит представление программы в виде иерархической структуры блоков. Предложена в 70-х годах XX века Э. Дейкстрой, разработана и дополнена Н. Виртом. Структу́рное программи́рование — методология разработки программного обеспечения, в основе которой лежит представление программы в виде иерархической структуры блоков.

В соответствии с данной методологией

1. Любая программа представляет собой структуру, построенную из трёх типов базовых конструкций:

• последовательное исполнение — однократное выполнение операций в том порядке, в котором они записаны в тексте программы;

• ветвление — однократное выполнение одной из двух или более операций, в зависимости от выполнения некоторого заданного условия;

• цикл — многократное исполнение одной и той же операции до тех пор, пока выполняется некоторое заданное условие (условие продолжения цикла).

В программе базовые конструкции могут быть вложены друг в друга произвольным образом, но никаких других средств управления последовательностью выполнения операций не предусматривается.

2. Повторяющиеся фрагменты программы (либо не повторяющиеся, но представляющие собой логически целостные вычислительные блоки) могут оформляться в виде т. н. подпрограмм (процедур или функций). В этом случае в тексте основной программы, вместо помещённого в подпрограмму фрагмента, вставляется инструкция вызова подпрограммы. При выполнении такой инструкции выполняется вызванная подпрограмма, после чего исполнение программы продолжается с инструкции, следующей за командой вызова подпрограммы.

3. Разработка программы ведётся пошагово, методом «сверху вниз».

Сначала пишется текст основной программы, в котором, вместо каждого связного логического фрагмента текста, вставляется вызов подпрограммы, которая будет выполнять этот фрагмент. Вместо настоящих, работающих подпрограмм, в программу вставляются «заглушки», которые ничего не делают. Полученная программа проверяется и отлаживается. После того, как программист убедится, что подпрограммы вызываются в правильной последовательности (то есть общая структура программы верна), подпрограммы-заглушки последовательно заменяются на реально работающие, причём разработка каждой подпрограммы ведётся тем же методом, что и основной программы. Разработка заканчивается тогда, когда не останется ни одной «затычки», которая не была бы удалена. Такая последовательность гарантирует, что на каждом этапе разработки программист одновременно имеет дело с обозримым и понятным ему множеством фрагментов, и может быть уверен, что общая структура всех более высоких уровней программы верна. При сопровождении и внесении изменений в программу выясняется, в какие именно процедуры нужно внести изменения, и они вносятся, не затрагивая части программы, непосредственно не связанные с ними. Это позволяет гарантировать, что при внесении изменений и исправлении ошибок не выйдет из строя какая-то часть программы, находящаяся в данный момент вне зоны внимания программиста.

Наиболее распространенными и наименее эффективными для отладки являются так называемые методы ‘грубой силы’. К ним относят:

отладку с использованием дампа памяти;

отладку с использованием операторов печати по всей программе;

отладку с использованием автоматических средств.

Дампы памяти практически невозможно использовать при программировании на языке высокого уровня, поэтому на этом способе отладки останавливаться не будем

Расстановка печатей в программе бессистемно вряд ли может ускорить отладку. Для системной расстановки нужны четкие представления о структуре алгоритма (схема работы программы или блок-схема).Серьезным недостатком этого метода отладки является тот факт, что печати, вставляемые в программу, изменяют ее, вследствие чего могут послужить дополнительным источником ошибок.

Использование автоматических средств отладки из этой группы методов наиболее предпочтительно.

Общей характеристикой методов ‘грубой силы’ является то, что они не требуют значительных умственных затрат и могут продолжаться бесконечно долго, если наряду с ними не применять более гибкие методы, к которым относятся:

метод индукции;

метод дедукции.

Название методов напоминают о криминалистике и не напрасно, ибо есть аналогия между этими методами и расследованием преступления.

Метод индукции включает:

определение данных тестирования, имеющих отношение к ошибке;

анализ от частного к общему позволит выявить закономерности в данных пункта 1);

в результате анализа выдвигается гипотеза о причине ошибки;

для подтверждения гипотезы 3 разрабатывается один или больше тестов, которые должны либо подтвердить, либо опровергнуть гипотезу;

если дополнительные тесты подтверждают гипотезу, можно приступать к исправлению ошибки, а вот если не подтверждают, то требуется в лучшем случае возврат к п.3, а в худшем

40)Модульное проектирование дает возможность разбить программные и функциональные блоки на оптимальное количество модулей небольшой размерности (длиной до пятисот операторов), определить назначение каждого модуля и осуществить идентификацию его входных и выходных параметров.

По своему назначению модули делят на управляющие и исполнительные, а по степени общности — на стандартные и оригинальные.

Метод модульного проектирования поддерживается методом проектирования «сверху-вниз». Традиционно применяемое проектирование методом «.снизу-вверх» включает выполнение операций по разработке программного обеспечения в следующей последовательности: разработка отдельных компонентов программы, кодирование этих компонентов, отладка и интеграция, т. е. сборка их на последнем шаге, что приводит к вероятности выявления стольких неувязок в программе, сколько было в ней составных частей.

Проектирование методом «сверху-вниз» позволяет свести процесс разработки программы к выполнению двух операций: логическая разработка с одновременным интегрированием и выполнение кодирования с отладкой. При таком подходе вначале разрабатывается логическая структура программы в виде дерева программных модулей с установлением всех типов связей между ними, а затем идут кодирование и отладка модулей. При этом проектирование начинается с модулей, занимающих верхние уровни иерархии, с одновременной проработкой связей их со всеми соподчиненными модулями, для которых разрабатываются временные «заглушки» с целью проведения их отладки.

Билет41

Общие понятия отладки. Виды ошибок.

Отладкой называется процесс выявления природы ошибки программы и исправления ошибок, после того, как ошибки были обнаружены в процессе тестирования.

Из всех этапов проектирования логики программных модулей этап отладки является наименее формализованным. В нем выделяют две задачи:

определение природы ошибки;

исправление ошибки.

Решение первой из этих задач занимает около 95 % времени, затрачиваемых на отладку. Поэтому любые средства ускорения процесса определения местоположения ошибки в программ имеют важное значение.