Методические разработки проведения уроков по музыке по стандартам ФГОС

Разработка ИС Дошкольного образовательного учреждения

 

 

СОДЕРЖАНИЕ	Стр.
ВВЕДЕНИЕ	3
ГЛАВА 1. НАЗНАЧЕНИЕ И ФУНКЦИОНИРОВАНИЕ ИС. ЭТАПЫ И СПОСОБЫ РАЗРАБОТКИ ИС	5
1.1.ИС и их классификация	5
1.2.Модели ЖЦ ИС	20
1.3.Методологии и технологии проектирования ИС	33
ГЛАВА 2. ОПИСАНИЕ СРЕДЫ РАЗРАБОТКИ АИС	45
2.1.Назначение и функции СУБД	450
2.2.Современные требования к СУБД	50
2.3.СУБД MS Access: характеристика и технология работы	54
ГЛАВА 3.ПРОЕКТИРОВАНИЕ И РАЗРАБОТКА АИС	58
3.1.Проектирование объектов БД	58
3.2.Разработка схемы данных в среде MS Access	60
3.3.Разработка запросов БД	62
3.4.Разработка отчетов	65
3.5.Разработка форм БД	66
ЗАКЛЮЧЕНИЕ	70
СПИСОК ЛИТЕРАТУРЫ	72

 

ВВЕДЕНИЕ

 

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

Актуальность темы: на сегодняшний день автоматизация деятельности становится неотъемлемой частью практически любого предприятия. Управление различными процессами при помощи компьютера позволяет добиться более высокой производительности труда и сэкономить массу времени. Высококачественная автоматизация технологических процессов значительно облегчает работу предприятия и производства в целом.

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

Целью настоящего курсового проекта является разработка автоматизированной информационной системы.

В соответствии с поставленной целью, в работе были решены следующие задачи:

1)                Проектирование АИС;

2)                Разработка АИС.

Структура работы состоит из введения, трех глав, заключения и литературы.

ГЛАВА 1. НАЗНАЧЕНИЕ И ФУНКЦИОНИРОВАНИЕ ИС. ЭТАПЫ И СПОСОБЫ РАЗРАБОТКИ ИС

1.1.Информационные системы и их классификация

 

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

1. Элемент системы — часть системы, имеющая определенное функциональное назначение. Сложные элементы систем, в свою очередь состоящие из более простых взаимосвязанных элементов, часто называют подсистемами.

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

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

4. Архитектура системы — совокупность свойств системы, существенных для пользователя.

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

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

В Федеральном законе «Об информации, информатизации и защите информации» дается следующее определение:

«Информационная система — организационно упорядоченная совокупность документов (массивов документов) и информационных технологий, в том числе с использованием средств вычислительной техники и связи, реализующих информационные процессы»

Классификация по масштабу

По масштабу информационные системы подразделяются на следующие группы:

·                     одиночные;

·                     групповые;

·                     корпоративные.

Одиночные информационные системы реализуются, как правило, на автономном персональном компьютере (сеть не используется). Такая система может содержать несколько простых приложений, связанных общим информационным фондом, и рассчитана на работу одного пользователя или группы пользователей, разделяющих по времени одно рабочее место. Подобные приложения создайся с помощью так называемых настольных или локальных систем управления базами данных (СУБД). Среди локальных СУБД наиболее известными являются Clarion, Clipper, FoxPro, Paradox, dBase и Microsoft Access.

Групповые информационные системы ориентированы на коллективное использование информации членами рабочей группы и чаще всего строятся на базе локальной вычислительной сети. При разработке таких приложений используются серверы баз данных (Называемые также SQL-серверами) для рабочих групп. Существует довольно большое количество различных SQL-серверов, как коммерческих, так и свободно распространяемых. Среди них наиболее известны такие серверы баз данных, как Oracle, DB2, Microsoft SQL Server, InterBase, Sybase, Informix.

Корпоративные информационные системы являются развитием систем для рабочих групп, они ориентированы на крупные компании и могут поддерживать территориально разнесенные узлы или сети. В основном они имеют иерархическую структуру из нескольких уровней. Для таких систем характерна архитектура клиент-сервер со специализацией серверов или же многоуровневая архитектура. При разработке таких систем могут использоваться те же серверы баз данных, что и при разработке групповых информационных систем. Однако в крупных информационных системах наибольшее распространение получили серверы Oracle, DB2 и Microsoft SQL Server.

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

Классификация по сфере применения

По сфере применения информационные системы обычно подразделяются на четыре группы:

·                     системы обработки транзакций;

·                     системы принятия решений;

·                     информационно-справочные системы;

·                     офисные информационные системы.

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

Системы поддержки принятия решений — DSS (Decision Support Systeq) — представляют собой другой тип информационных систем, в которых с помощью довольно сложных запросов производится отбор и анализ данных в различных разрезах: временных, географических и по другим показателям.

Обширный класс информационно-справочных систем основан на гипертекстовых документах и мультимедиа. Наибольшее развитие такие информационные системы получили в сети Интернет.

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

Классификация по способу организации

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

·                     системы на основе архитектуры файл-сервер;

·                     системы на основе архитектуры клиент-сервер;

·                     системы на основе многоуровневой архитектуры;

·                     системы на основе Интернет/интранет - технологий.

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

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

Архитектура клиент-сервер предназначена для разрешения проблем файл-серверных приложений путем разделения компонентов приложения и размещения их там, где они будут функционировать наиболее эффективно. Особенностью архитектуры клиент-сервер является использование выделенных серверов баз данных, понимающих запросы на языке структурированных запросов SQL (Structured Query Language) и выполняющих поиск, сортировку и агрегирование информации.

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

Многоуровневая архитектура стала развитием архитектуры клиент-сервер и в своей классической форме состоит из трех уровней:

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

·                     средний уровень представляет собой сервер приложений;

·                     верхний уровень представляет собой удаленный специализированный сервер базы данных.

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

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

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

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

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

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

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

Предметом изучения информатики являются информационные технологии, которые реализуются на практике в автоматизированных информационных системах (АИС) различного назначения; выступающих в качестве объекта информатики. Таким образом, АИС позволяют автоматизировать ту или иную сферу профессиональной деятельности людей за счет использования компьютерных средств и технологий. Иными словами, в качестве основных средств (инструмента) автоматизации профессиональной деятельности людей сегодня выступают средства ЭВТ и связи.

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

В соответствии с предложенным классификационным признаком можно выделить следующие классы АИС:

·                     автоматизированные системы управления (АСУ);

·                     системы поддержки принятия решения (СППР);

·                     автоматизированные информационно-вычислительные системы (АИВС);

·                     автоматизированные системы обучения (АСО);

·                     автоматизированные информационно-справочные системы (АИСС).

Рассмотрим особенности каждого класса АИС и характеристики возможных видов АИС в составе каждого класса.

Автоматизированные системы управления

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

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

АСУТС предназначены для реализации соответствующих технологических процессов. Они являются по сути перёдаточным звеном между должностными лицами осуществ­ляющими управление техническими системами, и сами ми техническими системами.

В настоящее время АСУТС нашли широкое распространение во всех развитых государствах. Объясняется это тем, что управление существующими новейшими технологический процесс без применения АСУТС становится практически невозможным. Что касается АСУП, то в настоящее'. время такие системы широко используются в странах Запада, и непрерывно ведутся работы по созданию новых систем, в том числе – на базе достижений в области искусственного интеллекта.

Системы поддержки принятия решений

Системы поддержки принятия решений (СППР) являются достаточно новым классом АИС, теория создания которых в настоящее время интенсивно развивается.

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

Выделяются четыре категории должностных лиц, деятельность которых отличается различной спецификой переработки информации: руководитель, должностное лицо аппарата управления, оперативный дежурный, оператор. В соответствии с четырьмя категориями должностных лиц различают и четыре вида СППР: СППР руководителя (СППР Р), СППР должностного лица аппарата управления (СППР 0), СППР оперативного дежурного (СППР Д) и СППР оператора (СППР Оп).

Автоматизированные информационно-вычислительные системы

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

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

Информационно-расчетные системы

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

Системы автоматизации проектирования

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

В области экономики САПР могут использоваться при проектировании экономических информационных систем и их элементов. Кроме того, технология САПР может обеспечить создание автоматизированной системы отображения обстановки на экране в процессе ведения экономических операций или в ходе деловых игр различных типов.

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

В состав программного обеспечения ПОИС входят банк типовых моделей (БТМ) предметных областей, планировщик моделей, базы данных предметных областей, а также средства диалогового общения пользователя с ПОИС.

ПОИС является достаточно сложной АИС, реализуемой, как правило, с использованием технологии искусственного интеллекта на высокопроизводительных ЭВМ.

Моделирующие центры

МЦ — автоматизированная информационная система, представляющая собой комплекс готовых к использованию моделей, объединенных единой предметной областью, информационной базой и языком общения с пользователями.

МЦ, так же, как и ПОИС, предназначены для обеспечения проведения исследований на различных моделях. Но в отличие от ПОИС, МЦ не обеспечивают автоматизацию создания имитационных моделей, а предоставляют пользователю возможность комфортной работы с готовыми моделями.

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

Автоматизированные системы обучения

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

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

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

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

Наибольшую сложность при создании АСПО составляет разработка «компьютерного курса» для конкретной дисциплины. Именно поэтому в настоящее время наибольшее распространение получили «компьютерные курсы» по традиционным, отра6отанным в методическом плане дисциплинам (физике, элементарной математике, программированию и т.д.).

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

В ходе деловой игры на АСОДИ возлагаются следующие задачи:

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

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

·                     обмен информацией между участниками игры (обучаемыми и руководителями игры);

·                     контроль и обобщение действий обучаемых в процессе деловой игры;

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

Технической базой АСОДИ являются высокопроизводительные ЭВМ или локальные вычислительные сети. Методологической базой АСОДИ, как правило, является имитационное моделирование на ЭВМ.

ТиТК предназначены для обучения практическим навыкам работы на конкретных рабочих местах (боевых постах). Они являются средствами индивидуального (тренажеры) и группового (тренажерные комплексы) обучения.

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

Автоматизированные информационно-справочные системы

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

·                     автоматизированные архивы (АА);

·                     автоматизированные системы делопроизводства (АСД);

·                     автоматизированные справочники (АС) и картотеки (AK)

·                     автоматизированные системы ведения электронных карт местности (АСВЭКМ) и др.

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

Простота Создания АИСС и высокий положительный эффект от их использования определили их активное пользование во всех сферах профессиональной (в том числе и управленческой) деятельности.

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

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

Сущность документального обслуживания заключается в том, что информационные потребности членов общества удовлетворяются путем предоставления им первичных документов, необходимые сведения из которых потребители извлекают сами. Обычно грамотное документальное обслуживание осуществляется в два этапа: сначала потребителю предоставляется некоторая совокупность релевантных (релевантность - смысловое соответствие содержания документа информационному запросу {смысловое соответствие между двумя текстами}) его запросу вторичных документов (этот этап называется библиографическим), а затем, после отбора потребителем из этой совокупности определенного числа уже пертинентных (пертинентность - соответствие содержания документа информационной потребности конкретного специалиста) документов, ему предоставляют сами документы (этот этап называется библиотечным обслуживанием). Таким образом, потребность в информации при документальном обслуживании удовлетворяется опосредовано, через первичный документ.

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

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

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

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

 

1.2.Модели ЖЦ ИС

 

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

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

Методология проектирования информационных систем описывает процесс создания и сопровождения систем в виде жизненного цикла (ЖЦ) ИС, представляя его как некоторую последовательность стадий и выполняемых на них процессов. Для каждого этапа определяются состав и последовательность выполняемых работ, получаемые результаты, методы и средства, необходимые для выполнения работ, роли и ответственность участников и т.д. Такое формальное описание ЖЦ ИС позволяет спланировать и организовать процесс коллективной разработки и обеспечить управление этим процессом.

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

Классификация моделей жизненного цикла

К настоящему времени наибольшее распространение получили следующие модели (стратегии) жизненного цикла:

- каскадная;

- инкрементная;

- спиральная.

Дальнейшее рассмотрение моделей жизненного цикла ведется с использованием терминологии классического жизненного цикла.

Каскадная стратегия

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

Рис.1.1. Каскадная стратегия

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

Достоинства модели:

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

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

Недостатки модели:

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

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

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

Инкрементная стратегия

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

Рис.1.2. Инкрементная стратегия

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

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

- отсутствия у заказчика возможности сразу профинансировать весь дорогостоящий проект;

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

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

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

Спиральная стратегия

Спиральная стратегия (эволюционная или итерационная модель, автор Барри Боэм, 1988 г.) подразумевает разработку в виде последовательности версий, но в начале проекта определены не все требования. Требования уточняются в результате разработки версий.

Рис. 1.3. Спиральная стратегия

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

Достоинства модели:

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

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

- обеспечивает большую гибкость в управлении проектом;

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

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

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

Недостатки модели:

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

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

Сравнительный анализ моделей

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

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

Таблица 1.1.

Сравнение моделей жизненного цикла

Характеристика проекта	Модель (стратегия)
	Каскадная	Инкрементная	Спиральная
Новизна разработки и обеспеченность ресурсами	Типовой. Хорошо проработаны технология и методы решения задачи		Нетиповой (новаторский). Нетрадиционный для разработчика
	Ресурсов заказчика и разработчика хватает для реализации проекта в сжатые сроки	Ресурсов заказчика или разработчика не хватает для реализации проекта в сжатые сроки
Масштаб проекта	Малые и средние проекты	Средние и крупные проекты	Любые проекты
Сроки выполнения проекта	До года	До нескольких лет. Разработка одной версии может занимать срок от нескольких недель до года
Заключение отдельных договоров на отдельные версии	Заключается один договор. Версия и есть итоговый результат проекта	На отдельную версию или несколько последовательных версий обычно заключается отдельный договор
Определение основных требований в начале проекта	Да	Да	Нет
Изменение требований по мере развития проекта	Нет	Незначительное	Да
Разработка итерациями (версиями)	Нет	Да	Да
Распространение промежуточного ПО	Нет	Может быть	Да

В табл. 1.1 не стоит рассматривать значения «Да» и «Нет» как жесткие требования. Например, незначительное изменение требований по мере развития проекта при использовании каскадной модели (например, добавление некоторых непредусмотренных сервисных функций) встречается не так уж редко и в случае их реализации способствует улучшению взаимоотношений между сторонами. Аналогично распространение промежуточного программного обеспечения при спиральной модели необязательно, а иногда даже вредно отражается на процессах внедрения и опытной эксплуатации системы.

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

- ревизию (исправительную или опытную) – любые оперативные изменения программного и информационного обеспечения, а также БД, необязательные в данный момент к передаче на объекты внедрения и связанные с устранением ошибок и усовершенствованием;

- модификацию – любые оперативные изменения программного и информационного обеспечения, а также БД, обязательные для передачи на объекты внедрения и обусловливающие изменение эксплуатационных характеристик без изменения функций (предусмотренных ТЗ), а также изменения, связанные с устранением ошибок, усовершенствованием;

- версию – любые изменения программного и информационного обеспечения, а также БД, обязательные для передачи на объекты внедрения, позволяющие выполнять заявленные или дополнительные функции, а также обеспечивающие переход на новые операционные системы и информационную среду;

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

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

Методологии, поддерживающие спиральную модель

В настоящее время имеется несколько методологий¹ разработки программного обеспечения, которые можно рекомендовать при использовании спиральной модели жизненного цикла. Наиболее известными из них являются методология быстрой разработки приложений (Rapid Application Development, RAD) и экстремальное программирование (eXtreme Programming, XP – автор Кент Бек, 1999).

Методология RAD. На начальном этапе существования компьютерных информационных систем их разработка велась на традиционных языках программирования и подразумевала, как правило, ручной набор текстов программ. Однако по мере возрастания сложности разрабатываемых систем и увеличения запросов пользователей потребовались новые средства, обеспечивающие значительное сокращение сроков разработки. Это послужило предпосылкой к созданию инструментальных средств для быстрой разработки приложений. Развитие этого направления привело к появлению на рынке разработки программного обеспечения средств автоматизации практически всех стадий жизненного цикла.

Под RAD-разработкой обычно понимается процесс разработки, содержащий 3 элемента:

- небольшую команду программистов (до 10 человек);

- короткий, но тщательно проработанный производственный график (от 2 до 6 месяцев);

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

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

- CASE²-средств для формирования и анализа требований, проектирования системы, автоматической генерации кода программ и структуры БД, а также автоматического тестирования программного обеспечения;

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

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

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

- шаблонов и библиотек готовых решений как собственной разработки, так и сторонних производителей.

Условия применения методологии RAD:

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

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

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

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

Методология XP. Данный подход ориентирован на разработку информационных систем группами малого и среднего размера в условиях неопределенных или быстро изменяющихся требований.

Отличительными особенностями XP-разработки являются:

- частая смена версий и модификаций (длительность итераций вплоть до часов и минут, а обычно – 2 недели; в RAD – минимум 2 месяца);

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

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

- простой дизайн – система должна быть спроектирована настолько просто, насколько это возможно на каждый момент времени. Чем интерфейс проще, тем быстрее и качественнее идет освоение системы пользователями. Это не означает, что интерфейс «командной строки» самый предпочтительный. Как раз наоборот, «дружественный» и простой интерфейс должен быть интуитивно-понятным для пользователя; в нем должны отсутствовать бесполезные элементы, основная цель которых – произвести визуальное впечатление на пользователя; дополнительные диалоговые окна по вводу данных в строку таблицы, когда это можно сделать непосредственно в строке этой таблицы и т. д.;

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

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

- непрерывное и пересекающееся проектирование, разработка, интеграция и тестирование системы.

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

 

1.3.Методологии и технологии проектирования ИС

 

Одним из базовых понятий методологии проектирования ИС является понятие жизненного цикла ее программного обеспечения (ЖЦ ПО). ЖЦ ПО - это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации.

Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207 [5] (ISO - International Organization of Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.

Структура ЖЦ ПО по стандарту ISO/IEC 12207 базируется на трех группах процессов:

·                     основные процессы ЖЦ ПО (приобретение, поставка, разработка, эксплуатация, сопровождение);

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

·                     организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение).

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

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

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

Управление конфигурацией является одним из вспомогательных процессов, поддерживающих основные процессы жизненного цикла ПО, прежде всего процессы разработки и сопровождения ПО. При создании проектов сложных ИС, состоящих из многих компонентов, каждый из которых может иметь разновидности или версии, возникает проблема учета их связей и функций, создания унифицированной структуры и обеспечения развития всей системы. Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ. Общие принципы и рекомендации конфигурационного учета, планирования и управления конфигурациями ПО отражены в проекте стандарта ISO 12207-2.

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

Общие требования к методологии и технологии

Методологии, технологии и инструментальные средства проектирования (CASE-средства) составляют основу проекта любой ИС. Методология реализуется через конкретные технологии и поддерживающие их стандарты, методики и инструментальные средства, которые обеспечивают выполнение процессов ЖЦ.

Технология проектирования определяется как совокупность трех составляющих:

·                     пошаговой процедуры, определяющей последовательность технологических операций проектирования (рис. 1.4);

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

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

Рис. 1.4. Представление технологической операции проектирования

 

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

Технология проектирования, разработки и сопровождения ИС должна удовлетворять следующим общим требованиям:

·                     технология должна поддерживать полный ЖЦ ПО;

·                     технология должна обеспечивать гарантированное достижение целей разработки ИС с заданным качеством и в установленное время;

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

·                     технология должна обеспечивать возможность ведения работ по проектированию отдельных подсистем небольшими группами (3-7 человек). Это обусловлено принципами управляемости коллектива и повышения производительности за счет минимизации числа внешних связей;

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

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

·                     технология должна обеспечивать независимость выполняемых проектных решений от средств реализации ИС (систем управления базами данных (СУБД), операционных систем, языков и систем программирования);

·                     технология должна быть поддержана комплексом согласованных CASE-средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ.

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

·                     стандарт проектирования;

·                     стандарт оформления проектной документации;

·                     стандарт пользовательского интерфейса.

Стандарт проектирования должен устанавливать:

·                     набор необходимых моделей (диаграмм) на каждой стадии проектирования и степень их детализации;

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

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

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

Стандарт оформления проектной документации должен устанавливать:

·                     комплектность, состав и структуру документации на каждой стадии проектирования;

·                     требования к ее оформлению (включая требования к содержанию разделов, подразделов, пунктов, таблиц и т.д.),

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

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

·                     требования к настройке CASE-средств для обеспечения подготовки документации в соответствии с установленными требованиями.

Стандарт интерфейса пользователя должен устанавливать:

·                     правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления;

·                     правила использования клавиатуры и мыши;

·                     правила оформления текстов помощи;

·                     перечень стандартных сообщений;

·                     правила обработки реакции пользователя.

Методология RAD

Одним из возможных подходов к разработке ПО в рамках спиральной модели ЖЦ является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки ПО, содержащий 3 элемента:

·                     небольшую команду программистов (от 2 до 10 человек);

·                     короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);

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

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

Жизненный цикл ПО по методологии RAD состоит из четырех фаз:

·                     фаза анализа и планирования требований;

·                     фаза проектирования;

·                     фаза построения;

·                     фаза внедрения.

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

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

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

·                     общая информационная модель системы;

·                     функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков;

·                     точно определенные с помощью CASE-средства интерфейсы между автономно разрабатываемыми подсистемами;

·                     построенные прототипы экранов, отчетов, диалогов.

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

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

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

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

·                     определяется необходимость распределения данных;

·                     производится анализ использования данных;

·                     производится физическое проектирование базы данных;

·                     определяются требования к аппаратным ресурсам;

·                     определяются способы увеличения производительности;

·                     завершается разработка документации проекта.

Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям.

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

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

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

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

В качестве итога перечислим основные принципы методологии RAD:

·                     разработка приложений итерациями;

·                     необязательность полного завершения работ на каждом из этапов жизненного цикла;

·                     обязательное вовлечение пользователей в процесс разработки ИС;

·                     необходимое применение CASE-средств, обеспечивающих целостность проекта;

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

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

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

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

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

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

ГЛАВА 2. ОПИСАНИЕ СРЕДЫ РАЗРАБОТКИ АИС

2.1.Назначение и функции СУБД

 

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

Программное обеспечение, предназначенное для работы с базами данных, называется система управления базами данных (СУБД). СУБД используются для упорядоченного хранения и обработки больших объемов информации.

Система управления базами данных (СУБД) — совокупность программных и лингвистических средств общего или специального назначения, обеспечивающих управление созданием и использованием баз данных

СУБД организует хранение информации таким образом, чтобы ее было удобно:

·                     просматривать,

·                     пополнять,

·                     изменять,

·                     искать нужные сведения,

·                     делать любые выборки,

·                     осуществлять сортировку в любом порядке.

Основные функции СУБД

1. Непосредственное управление данными во внешней памяти

Эта функция включает обеспечение необходимых структур внешней памяти как для хранения данных, непосредственно входящих в БД, так и для служебных целей, например, для ускорения доступа к данным в некоторых случаях (обычно для этого используются индексы). В некоторых реализациях СУБД активно используются возможности существующих файловых систем, в других работа производится вплоть до уровня устройств внешней памяти. Но подчеркнем, что в развитых СУБД пользователи в любом случае не обязаны знать, использует ли СУБД файловую систему, и если использует, то как организованы файлы. В частности, СУБД поддерживает собственную систему именования объектов БД.

2. Управление буферами оперативной памяти

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

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

3. Управление транзакциями

Транзакция - это последовательность операций над БД, рассматриваемых СУБД как единое целое.

Либо транзакция успешно выполняется, и СУБД фиксирует изменения БД, произведенные этой транзакцией, во внешней памяти, либо ни одно из этих изменений никак не отражается на состоянии БД.

Понятие транзакции необходимо для поддержания логической целостности БД. Приведем пример информационной системы с файлами СОТРУДНИКИ и ОТДЕЛЫ, единственным способом не нарушить целостность БД при выполнении операции приема на работу нового сотрудника является объединение элементарных операций над файлами СОТРУДНИКИ и ОТДЕЛЫ в одну транзакцию. Таким образом, поддержание механизма транзакций является обязательным условием даже однопользовательских СУБД (если, конечно, такая система заслуживает названия СУБД). Но понятие транзакции гораздо более важно в многопользовательских СУБД.

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

4. Журнализация

Одним из основных требований к СУБД является надежность хранения данных во внешней памяти. Под надежностью хранения понимается то, что СУБД должна быть в состоянии восстановить последнее согласованное состояние БД после любого аппаратного или программного сбоя. Обычно рассматриваются два возможных вида аппаратных сбоев: так называемые мягкие сбои, которые можно трактовать как внезапную остановку работы компьютера (например, аварийное выключение питания), и жесткие сбои, характеризуемые потерей информации на носителях внешней памяти. Примерами программных сбоев могут быть: аварийное завершение работы СУБД (по причине ошибки в программе или в результате некоторого аппаратного сбоя) или аварийное завершение пользовательской программы, в результате чего некоторая транзакция остается незавершенной. Первую ситуацию можно рассматривать как особый вид мягкого аппаратного сбоя; при возникновении последней требуется ликвидировать последствия только одной транзакции.

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

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

Во всех случаях придерживаются стратегии "упреждающей" записи в журнал (так называемого протокола Write Ahead Log - WAL). Грубо говоря, эта стратегия заключается в том, что запись об изменении любого объекта БД должна попасть во внешнюю память журнала раньше, чем измененный объект попадет во внешнюю память основной части БД. Известно, что если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановления БД после любого сбоя.

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

5. Поддержка языков БД

Для работы с базами данных используются специальные языки, в целом называемые языками баз данных. В ранних СУБД поддерживалось несколько специализированных по своим функциям языков. Чаще всего выделялись два языка

·                     язык определения схемы БД (SDL - Schema Definition Language) и

·                     язык манипулирования данными (DML - Data Manipulation Language).

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

В современных СУБД обычно поддерживается единый интегрированный язык, содержащий все необходимые средства для работы с БД, начиная от ее создания, и обеспечивающий базовый пользовательский интерфейс с базами данных. Стандартным языком наиболее распространенных в настоящее время реляционных СУБД является язык запросов SQL (Structured Query Language).

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

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

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

 

2.2.Современные требования к СУБД

 

Производительность

Задачи, стоящие перед современными компаниями, предъявляют к СУБД довольно высокие требования, немыслимые еще несколько лет назад. Одним из наиболее важных требований, с точки зрения пользователей и администраторов СУБД, является высокая производительность, то есть способность быстро обрабатывать запросы пользователей и выполнять транзакции. Немалую роль в этом вопросе играют средства оптимизации выполнения запросов и применения индексов, а также простота их использования. Одни СУБД содержат в своем составе соответствующие инструменты, другие СУБД — встроенные алгоритмы, применяемые автоматически.

Поддержка безопасности

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

По данным ряда аналитических отчетов, наиболее высоко ценятся средства поддержки безопасности СУБД Oracle, DB2 и PostgreSQL.

Масштабируемость

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

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

Отметим, что те или иные ограничения подобного рода (такие как максимальный объем данных, число записей в таблице, количество пользователей) присущи в большей или меньшей степени всем СУБД и при столкновении с ними наблюдаются снижение производительности, возникновение ошибок, отказы в предоставлении доступа или в выполнении запросов. Именно поэтому важна способность преодолевать подобные ограничения за счет поддержки подключения новых ресурсов — вплоть до создания кластеров из нескольких компьютеров (данная функциональность сейчас поддерживается СУБД DB2 и Oracle).

Корректная обработка транзакций

Еще одним важным требованием является корректная обработка транзакций — групп последовательных операций, представляющих собой логические единицы работы с данными. Правила корректной обработки транзакций впервые были описаны автором реляционной модели данных Эдгаром Коддом в виде аббревиатуры ACID (Atomicity, Consistency, Isolation, Durability).

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

Свойство Consistency (непротиворечивость) означает, что завершенная транзакция оставляет данные в непротиворечивом состоянии.

Свойство Isolation (изоляция) означает, что во время выполнения транзакции другие процессы не должны «видеть» данные в промежуточном состоянии. Например, если транзакция изменяет сразу несколько полей в базе данных, то другой запрос, произведенный во время выполнения транзакции, не должен вернуть одни из этих полей с новыми значениями, а другие — с исходными.

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

По данным ряда аналитических отчетов, разработчики и администраторы наиболее высоко оценивают средства корректной обработки транзакций СУБД компаний Oracle и IBM. Впрочем, Microsoft SQL Server с этой точки зрения также оценивается очень высоко.

Другие требования

Для разработки структур баз данных и проектирования запросов принято использовать специализированные инструменты — средства моделирования данных. Такие инструменты могут выпускаться как производителями СУБД, так и независимыми поставщиками. Поддержка СУБД производителями подобных инструментов, как и наличие их в ассортименте программного обеспечения производителя СУБД, считается важным требованием к современным системам управления базами данных. Например, наличие в огромном ассортименте компании Oracle таких продуктов, как средство моделирования Oracle Designer и содержащее инструменты моделирования бесплатное средство разработки JDeveloper, высоко ценится разработчиками решений на основе СУБД Oracle, равно как и наличие поддержки моделирования данных в Visio — разработчиками решений на основе Microsoft SQL Server.

Многие современные СУБД содержат средства администрирования в комплекте поставки. Помимо этого, нередко доступны и средства администрирования СУБД независимых производителей, таких как Embarcadero и Quest Software. Чем более популярна СУБД и чем более гибкой является политика работы с партнерами ее производителя, тем, как правило, больше средств администрирования этой СУБД доступно на рынке. С этой точки зрения лидерами являются Oracle и Microsoft — данные компании поставляют неплохие средства администрирования вместе со своими СУБД, да и средств администрирования этих СУБД от независимых производителей на рынке более чем достаточно. Неплохо обстоят дела с инструментами и у MySQL и PostgreSQL — будучи СУБД с открытым кодом, они поддерживаются сообществами разработчиков, производящими инструменты администрирования.

Требование поддержки XML в последнее время стало важным для пользователей современных СУБД и разработчиков решений на их основе, поскольку XML является стандартом де-факто для генерации документов и обмена данными между самыми разнообразными приложениями. Способность читать и генерировать XML-документы сейчас доступна в большинстве современных СУБД.

Поддержка различных платформ важна для разработчиков приложений, работающих в разнородной среде, и наиболее существенна для крупных компаний, имеющих, как правило, весьма разнообразную ИТ-инфраструктуру. Большинство современных СУБД поддерживают несколько платформ. Исключением являются СУБД производства Microsoft — список поддерживаемых ими платформ включает только различные версии Windows.

Все современные реляционные СУБД поддерживают язык запросов SQL. Что касается других языков, то их для написания серверного кода можно использовать в СУБД производства компаний Microsoft, Oracle, а также в СУБД PostgreSQL.

 

2.3.СУБД MS Access: характеристика и технология работы

 

Общие сведения о MS Access

MS Access является приложением Windows. В СУБД Access предусмотрено много дополнительных сервисных возможностей. Мастера помогут создать таблицы, формы или отчеты из имеющихся заготовок. Выражения используются в Access, например, для проверки допустимости введенного значения. Макросы позволяют автоматизировать многие процессы без программирования, тогда как встроенный в Access язык VBA (Visual Basic for Applications) дает возможность опытному пользователю программировать сложные процедуры обработки данных.

Рис. 2.1. – Интерфейс программы MS Access

Объекты базы данных

Объектами базы данных являются:

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

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

Запрос – это инструмент для анализа, выбора и изменения данных. С помощью Access могут создаваться несколько видов запросов.

Отчеты – это средство организации данных при выводе на печать.

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

Типы данных

Текстовый – наиболее чисто используемый в Access тип данных. Этот тип данных подходит для хранения адресов, для полей с кратким описанием, для числовых данных, не требующих расчетов, таких, как телефонные номера и почтовые индексы. Длина – 255 символов.

Поле Меmо – предназначен для полей, длина которых превосходит 255 символов. Пример: длинное поле описания. Поле Memo может хранить до 65 535 символов, что приближенно равно 32 страницам текста.

Числовой. Данные, используемые для математических вычислений, за исключением финансовых расчетов (для них следует использовать тип «Денежный»).

Дата/время. Значения дат и времени. Сохраняет 8 байтов. Можно вводить даты с 1 января 100 года по 31 декабря 9999 года. Access предлагает несколько различных форматов дат.

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

Счетчик. Автоматическая вставка уникальных последовательных (увеличивающихся на 1) или случайных чисел при добавлении записи с использованием этого типа данных либо, выбрав соответствующий пункт в свойстве Новое значение этого поля. Если удалить одну из последовательных записей, этот тип поля не запомнит и не перенумерует удаленное значение. Это значение будет просто отсутствовать.

Логический (Да/нет). Данные, принимающие только одно из двух возможных значений, таких как «Да/Нет», «Истина/Ложь», «Вкл/Выкл». Значения Null не допускаются.

Поле объекта OLE. Объекты OLE (такие как документы Microsoft Word, электронные таблицы Microsoft Excel, рисунки, звукозапись или другие данные в двоичном формате), созданные в других программах, использующих протокол OLE.

Гиперссылка. Гиперссылка может иметь вид пути UNC либо адреса URL. Мастер подстановок. Создает поле, позволяющее выбрать значение из другой таблицы или из списка значений, используя поле со списком. Необходимо соблюдать для одних наименований полей данных одинаковый тип данных.

Рис. 2.2. Типы данных MS Access

Создание схем данных в среде MS Access

СУБД MS Access реализует инструмент проектирования связей между таблицами (объектами) БД. Этот инструмент называется «Схема данных».

Для вызова этого инструмента можно воспользоваться соответствующей кнопкой на панели «Работа с базами данных».

В рабочую область схемы можно добавлять и удалять таблицы, а также связи между ними. Для добавления связи между таблицами нужно выбрать необходимое поле (внешний ключ) и использую Drag’n’Drop протянуть его до нужного поля связанной таблицы (потенциальный ключ). После чего, в появившемся окне свойств вновь созданной связи, можно выставить необходимые настройки.

 

ГЛАВА 3. ПРОЕКТИРОВАНИЕ И РАЗРАБОТКА АИС

3.1.Проектирование объектов БД

 

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

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

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

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

Приступим к разработке базы данных. Для того, чтобы создать новую БД открываем приложение Microsoft Access и создаем новую БД и называем «Дошкольного образовательного учреждения».

В базе данных «Дошкольного образовательного учреждения» информация будет храниться в 2 таблицах. Главной таблицей будет «Ромашки» объединяющая все остальные. Приступаем к созданию таблиц. Для того чтобы создать таблицу нужно перейти на вкладку Создание и выбрать Конструктор таблиц.

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

Рис.3.1. Таблица «Ромашка» в режиме конструктора

Следующие таблицы создаем и заполняем аналогично таблице «Ромашка».

Далее приступаем к заполнению всех таблиц данными.

Рис.3.2. Таблица «Цветочек», заполненная данными

Другие таблицы заполняем подобным образом.

 

3.2. Разработка схемы данных в среде MS Access

 

В связях между таблицами применяем обеспечение целостности данных, каскадное обновление/удаление. Тип используемых связей – одни ко многим. Приступаем к созданию Схемы данных. Для того чтобы создать схему данных, нужно перейти на вкладку Работа с базами данных и выбрать Схема данных.

Рис.3.3. Создание Схемы данных

Выбираем и добавляем все таблицы.

Рис.3.4. Добавление таблицы

Создаем связи между определенными полями всех таблиц (см. на рис. 3.8.)

Рис. 3.5. Схема данных, связи между таблицами

ЗАКЛЮЧЕНИЕ

 

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

Для разработки автоматизированной информационной системы, исходя из требований, предъявляемых к системе, было выбрано средство Microsoft Office Access, как для создания базы данных - СУБД, так и для создания интерфейса пользователя. Данная система проста в использовании и не требует от пользователя глубокого знания СУБД Access.

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

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

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

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

 

СПИСОК ЛИТЕРАТУРЫ

 

1.                 А. В. Кузин, С. В. Левонисова, «Базы данных»: Учебное пособие, «Информатика и вычислительная техника», Академия 2019. – 320 с.

2.                 Барановская Т.П., Лойко В.И. и другие Информационные системы и технологии в экономике: Учебник - М.: Финансы и статистика, 2018. - 416 с.

3.                 Бекаревич Ю.Б. Создание реляционной базы данных и запросов. MS ACCESS 2007/Бекаревич Ю.Б., Пушкина Н.В.//Создание таблиц базы данных: СП.: СПбГУЭФ, 2017. - С.9-42.

4.                 Гагарина Л.Г. Разработка и эксплуатация автоматизированных информационных систем/Киселев Д.В., Федотова Е.Л., Гагарина Л.Г.//Автоматизированные информационные системы: М.: ФОРУМ: ИНФРА-М, 2018. - С.67-80.

5.                 Джонатан Генник, SQL. Карманный справочник, - СПб.:Питер, 2019.

6.                 Зобнин Б.Б., Задания и методические указания к выполнению курсовой работы по дисциплине «Моделирование систем» для студентов профилизации «Автоматизированные системы обработки информации и управления» направления 552800 - «Информатика и вычислительная техника», Екатеринбург, 2018.

7.                 Зобнин Б.Б., Моделирование систем, Конспект лекций, Екатеринбург, 2019

8.                 Информационные технологии управления: Учебное пособие / Под ред. Ю.М. Черкасова. -- М.: ИНФРА-М, 2019. -- 216 с. -- (Серия «Высшее образование»)

9.                 Информационные технологии управления: Учебное пособие для ВУЗов под ред. Г.А. Титоренко - М.:ЮНИТИ-ДАНА, 2018. - 439 с.

10.            Павловская Т.А. Программирование на языке высокого уровня. [Текст] / Т.А. Павловская. - М.: Питер, 2018. С. 461.

11.            Петров В.Н. Информационные системы - СПб: Питер, 2019. - 688 с.

12.            Саак А.Э., Пахомов Е.В., Тюшняков В.Н. Информационные технологии управления: Учебник для вузов. - СПб.: Питер, 2018. - 320 с. - (Серия "Учебник для вузов")

13.            Семакин И.Г. Основы программирования. [Текст] / И.Г. Семакин, А.П. Шестаков. - М.: Мир, 2019. C. 346.

14.            Семенов М.И. и другие Автоматизированные информационные технологии в экономике: Учебник - М.: Финансы и статистика, 2017. - 416 с.

15.            Советов Б.Я., Цехановский В.В. Информационные технологии: Учебник для ВУЗов - М.: Высшая школа, 2017. - 263 с.

16.            Уткин В.Б. Информационные системы и технологии в экономике: Учебник - М.: ЮНИТИ-ДАНА, 2018. - 355 с.

17.            Хотинская Г.И. Информационные технологии управления: Учебное пособие. - М.: Дело и Сервис, 2020. - 128 с.

18.            Эккель Б. Введение в стандартный С++. [Электронный ресурс] / Б. Эккель. - М.: Питер, 2019. С. 572.

19.            Чистов Д.В. Информационные системы//Информационные системы: М.: Инфра - М, 2018. - С.103-110.

 

 

 

Скачано с www.znanio.ru