Билет №4
Фактографические ИС накапливают и хранят данные в виде множества экземпляров одного или нескольких типов структурных элементов (информационных объектов). Каждый из таких экземпляров структурных элементов или некоторая их совокупность отражают сведения по какому-либо факту, событию и т. д., отделенному (вычлененному) от всех прочих сведений и фактов. Структура каждого типа информационного объекта состоит из конечного набора реквизитов, отражающих основные аспекты и характеристики сведений для объектов данной предметной области. К примеру, фактографическая АИС, накапливающая сведения по лицам, каждому конкретному лицу в базе данных ставит в соответствие запись, состоящую из определенного набора таких реквизитов, как фамилия, имя, отчество, год рождения, место работы, образование и т. д. Комплектование информационной базы в фактографических АИС включает, как правило, обязательный процесс структуризации входной информации из документального источника. Структуризация при этом осуществляется через определение (выделение, вычленение) экземпляров информационных объектов определенного типа, информация о которых имеется в документе, и заполнение их реквизитов.
Рис. 1. Уровни представления информации в АИС
Начальный уровень определяется локальными представлениями о предметной области пользователей-абонентов информационной системы и их представлениями о своих информационных потребностях. На основе анализа этих представлений определяется информационно-логическая или сокращенно инфологическая схема предметной области, подлежащей отображению информационной системой, и концептуальная модель использования информационной системы. Инфологическая схема представляет собой формализованное представление (описание) объектов и отношений фрагмента действительности. Наиболее часто формализация представлений о предметной области осуществляется в рамках модели «объекты-связи» (так называемая ER-людель — от англ. Entity Relationship). При этом под информационным объектом в общем плане понимается некоторая сущность фрагмента действительности, например организация, документ, сотрудник, место, событие и т. д. В предметной области выделяются различные типы объектов, представляемые в информационной системе в каждый момент времени конечным набором экземпляров данного типа. Каждый тип объекта включает (идентифицируется) присущий ему набор атрибутов (свойств, характерных признаков, параметров). Атрибут представляет логически неделимый элемент структуры информации, характеризующийся множеством атомарных значений. Для примера можно привести атрибут «Имя» объекта типа «Лицо», который характеризуется множеством всех возможных имен, и атрибут «Текст» объекта типа «Документ», который характеризуется множеством средств смыслового выражения в определенном национальном языке. Экземпляр объекта образуется совокупностью конкретных значений атрибутов данного типа объекта. Один или некоторая группа атрибутов объекта данного типа могут исполнять роль ключевого атрибута, по которому идентифицируются (различаются) конкретные экземпляры объектов. К примеру, для объектов типа «Лицо» ключом может являться совокупность атрибутов «Фамилия», «Имя», «Отчество» или один атрибут, выражающий номер паспорта (удостоверения личности). Различные типы объектов и различные экземпляры одного типа объекта могут быть охвачены определенными отношениями, которые в рамках ER-модели выражаются т. н. связями. Так, например, объекты «Сотрудник» и «Организация» могут быть охвачены отношением «Работа», т. е. связаны этим отношением. При этом связи могут быть двух типов — иерархические, или, иначе говоря, структурные (владелец-подчиненный) и одноуровневые, например, родственная связь «Брат-сестра» между двумя экземплярами объекта типа «Лицо» (в отличие от иерархической родственной связи—«Отец-сын»). Объекты-владельцы иерархических связей-отношений иногда называют структурными объектами, в противовес простым объектам, которые таковыми не являются (не являются владельцами). Структурные и одноуровневые связи (отношения), в свою очередь, по признаку множественности могут быть трех типов — «один-к-одному» (например, отношение «Лицо-Паспорт», имея в виду под «Паспортом» не атрибут объекта Лицо, а самостоятельный объект, состоящий из атрибутов «Номер», «Вид паспорта», «Владелец», «Место выдачи», «Дата выдачи» и т. д.), «один-ко-многим» (например, отношение «Подразделение-Сотрудник», имея в виду, что в одном подразделении мо-жет работать много сотрудников, но каждый сотрудник работает только в одном подразделении) и «многие-ко-многим» (например, отношение «Лицо-Документ», имея в виду, что один человек может быть автором, или иметь какое-либо другое отношение ко многим документам, и, в свою очередь, один документ может иметь много авторов. Помимо этого информационные потребности абонентов информационной системы могут включать также и оперирование опосредованными (т. е. косвенными, непрямыми, ассоциативными) связями. Примерами таких непрямых связей является совместная работа нескольких человек на одном предприятии (подразделении). Прямая непосредственная связь в данном случае, как правило, устанавливается только между объектами «Лицо» и «Организация», но не между различными экземплярами объекта «Лицо». Одним из способов представления формализованного описания предметной области информационной системы в рамках модели «объекты-связи» является использование техники специальных диаграмм, которая была предложена известным американским специалистом в области баз данных Ч. Бахманом. В диаграммах Бахмана объекты (сущности) представляются вершинами некоторого математического графа, а связи —дугами графа. Виды и свойства связей-отношений объектов отображаются направленностью, специальным оформлением дуг и расположением вершин графа. В качестве примера можно привести инфологическую схему предметной области сведений информационной системы, предназначенной для накопления данных о научной работе в каком-либо учебном или исследовательском учреждении.
Рис. 2. Мифологическая схема предметной области информационной системы со сведениями о научной работе
На приведенном рисунке однонаправленность дуг означает структурность связи «владелец-подчиненный», двунаправленность дуг означает одноуровневые связи, двойные стрелки означают множественность отношения «один-ко-многим», дву-направленность двойных стрелок означает одноуровневые отношения «многие-ко-многим». Одним из недостатков использования ER-диаграмм Бахмана для описания формализованных схем (моделей) предметных областей информационных систем является их статичность, не позволяющая наглядно и непосредственно отображать процессы, в которые вовлечены сущности и которым подвержены отношения (связи). Отчасти подобные проблемы преодолеваются введением дополнительных сущностей, выражающих собственно процессы и ситуации — событие, действие, момент времени. Аналогичным образом в некоторых случаях вводятся пространственные сущности для адекватного представления сущностей и отношений предметной области—маршрут, место, населенный пункт, здание, элемент здания, зона и т. д. Вторым уровнем представления информации в информационной системе (см. рис. 1) является схема базы дачных, (называемая еще логической структурой данных), представляющая описание средствами конкретной СУБД инфологической схемы предметной области (информационные объекты, реквизиты, связи). Совокупность средств и способов реализации схемы базы данных в конкретной СУБД составляет модель организации данных. Схема базы данных содержит также ограничения целостности данных. Ограничения целостности представляют собой набор установок и правил по типам, диапазонам, соотношениям (и т. д.) значений атрибутов объектов, характеристик и особенностей связей между объектами. К примеру, диапазон значения атрибута «Дата рождения» объекта лицо не может выходить за рамки текущей даты, значение атрибута «Дата приобретения» объекта «Имущество» не может быть позднее значения атрибута «Дата продажи», значение атрибута «Количество» объекта «Материал» не должно быть меньше минимально необходимого на складе и т. п. Ограничения целостности данных лежат в основе контроля корректности информации при ее вводе в систему и периодического контроля наличия смысловых и других ошибок в базе данных после проведения операций добавления, удаления и изменения данных. Третий и самый «низкий» уровень представления информации в фактографических информационных системах выражается внутренней схемой базы данных, определяющей структуру организации и особенности хранения информационных массивов, в которых и находятся собственно сами данные (см. рис. 1). Более конкретные особенности представления и организации данных определяются конкретным типом и особенностями СУБД, используемой для создания фактографической информационной системы.
История СУБД как особого вида программного обеспечения неразрывно связана с историей начала использования электронно-вычислительных машин для организации хранения и обработки информации. Именно в то время (конец 60-х, начало 70-х годов) были разработаны основы программного обеспечения для создания и эксплуатации фактографических информационных систем. В конце 70-х, начале 80-х годов направление программного обеспечения под общим названием «СУБД» превратилось в одну из наиболее бурно развивающихся отраслей программной индустрии. При этом основные программно-математические и технологические решения по СУБД были разработаны в 70-х годах в ряде крупных исследовательских проектов. Наиболее известными из них являются проект «Рабочей группы по базам данных» КОДАСИЛ (DBTG CODASYL) с участием уже упоминавшегося Ч. Бахмана, пионерские работы основателя теории реляционных баз данных Е. Кодда, проект разработки системы управления реляционными базами данных «System R» фирмы IBM (1975-1979 гг.) и проект разработки СУБД «Ingres» (Interactive Graphics and Retrieval System) в университете Беркли (1975-1980 гг.) под руководством известного специалиста в области баз данных М. Стоунбрейкера.
Изначально и по сей день программное обеспечение АИС (СУБД) в качестве места физического размещения данных ориентировано на внешнюю (дисковую) память. Как уже отмечалось, размещение данных во внешней памяти, точнее эффективность доступа к ним во внешней памяти, существенно влияет на эффективность обработки данных. В результате важным аспектом АИС является внутренняя схема базы данных, которую организует и поддерживает СУБД. В общем плане внутренняя схема базы данных включает три основных компонента
Рис. 3. Cocтав внутренней схемы базы данных
Центральным компонентом внутренней схемы являются информационные массивы, включающие собственно данные (информационных объектов логической схемы БД, т.е. в реляционных СУБД таблиц), и массивы индексов, являющихся специальными дополнительными конструкциями для ускорения доступа к данным основных информационных объектов. Информационные массивы в большинстве СУБД состоят из одной или нескольких так называемых страниц, каждая из которых содержит совокупность некоторых единичных элементов, называемых физическими записями. В результате, единичным элементом внутренней схемы баз данных АИС является физическая запись, в большинстве случаев совпадающая по смыслу с логической записью, т. е. в реляционных СУБД с табличной строкой. Способы организации записей в страницах (расположение, добавления, корректировка, удаление) составляют физические структуры данных, которые образуют третий (низший) уровень представления информации в информационной системе (см. рис. 1). Важным компонентом внутренней структуры является каталог БД, в котором размещается системная информация по логической структуре БД, включающая описание основных информационных объектов (имена, структура, параметры, связи) и ограничения целостности данных. Организация системной информации БД определяется особенностями конкретной СУБД, а сам каталог может входить непосредственно в файлы данных (область описателей данных) или составлять отдель-ный информационный массив. Как уже отмечалось, в состав автоматизированного банка данных АИС помимо самой базы данных входит и прикладной компонент, образуемый совокупностью интерфейсных элементов представления, ввода и обработки данных, типовых запросов и процедур обработки данных, а также «событий» и «правил», отражающих правила и специфику предметной области АИС (так называемые «правила бизнеса»). Соответственно во внутренней схеме БД выделяется специальная область, в которой размещается информация по прикладному компоненту АИС. Все три части внутренней структуры и их составные элементы (например, информационные массивы отдельных информационных объектов БД) могут размещаться в одном едином файле базы данных или в разных файлах. Во втором случае внутренняя схема БД определяется совокупностью и порядком расположения данных файлов.
Одной из наиболее трудоемких и сложных задач при создании АИС является проектирование банка данных как основы подсистемы представления и обработки информации. Логическая и физическая структуры банка данных отражают пред-ставление разработчиками и пользователями информационной системы той предметной области, сведения о которой предполагается отражать и использовать в АИС. Проектирование банков данных фактографических информационных систем осуществляется на основе формализации структуры и процессов предметной области АИС, и, в соответствии с уровнями представления информации в АИС (см. рис. 4), включает концептуальное и схемно-структурное проектирование.
Рис. 4. Соотношение понятий БнД, СУ БД и БД
В организационном плане в группе разработчиков банка данных выделяют специалистов по формализации предметной области, специалистов по программному обеспечению СУБД, а также технических дизайнеров и специалистов по эргономике. Специалисты no формализации предметной области (их еще называют формализаторами или постановщиками задач), как правило, возглавляют весь проект создания АИС и обеспечивают (функции взaимодейcтвия с заказчиком. К данной категории специалистов предъявляются наиболее сложные профессиональные требования. С одной стороны, такие работники должны быть специалистами в севере программного обеспечения АИС (операционные системы, СУБД и т. д.), а с другой стороны, они должны хорошо представлять (или освоить) конкретную предметную область АИС, т. е. быть (временно стать) бухгалтерами, экономистами, делопроизводителями и т.п. Специалисты по программному обеспечению СУБД относятся к категории профессиональных программистов, определяют выбор СУБД и обеспечивают построение ее средствами автоматизированного банка данных по разработанной постановщиком задачи (формализатором) концептуальной схеме. Технические дизайнеры и cneциaлисты по эргономике обеспечивают эстетичную и эргономичную сторону интерфейса с пользователем в АИС при вводе, обработке и поиске данных.
OLTP-системы - системы оперативной обработки транзакций. Основная функция подобных систем заключается в одновременном выполнении большого количества коротких транзакций от большого числа пользователей. Сами транзакции выглядят относительно просто, например, "снять сумму денег со счета А, добавить эту сумму на счет В".
Системы OLTP характеризуются:
поддержкой большого числа пользователей; малым временем отклика на запрос; относительно короткими запросами; участие в запросах небольшого числа таблиц. Практически все запросы к базе данных в OLTP-системах состоят из команд вставки, обновления, удаления. Запросы на выборку в основном предназначены для предоставления пользователям возможности выбора из различных справочников. Большая часть запросов, таким образом, известна заранее еще на этапе проектирования системы. Таким образом, критическим для OLTP-приложений является скорость и надежность выполнения коротких операций обновления данных.
Исторически такие системы возникли в первую очередь, поскольку реализовывали потребности в учете, скорости обслуживания, сборе данных и пр. Однако вскоре пришло понимание, что сбор данных - не самоцель и накопленные данные могут быть полезны: из данных можно извлечь информацию.
Фактографические информационные системы оперируют фактическими сведениями, представленными в виде специальным Образом организованных совокупностей формализованных записей данных. Центральное функциональное звено фактографической информационной системы – СУБД. Фактографические информационные системы используются не только для реализации справочных функций, но и для решения задач обработки данных. Под обработкой данных понимается специальный класс решаемых на ЭВМ задач, связанных с вводом, хранением, сортировкой, отбором и группировкой записей данных однородной структуры. Эти задачи предусматривают представление пользователям итоговых результатов обработки в виде отчетов табличной формы. В настоящее время в парадигме создания информационных систем наметился очевидный переход к реляционным моделям данных. Эти модели впервые предложены Е.Коддом в 1970 году в качестве наиболее независимых от аппаратных средств компьютера. Но только персональные компьютеры, мощные ресурсы которых поступают в полное распоряжение одного пользователя в отличие от больших ЭВМ, открыли дорогу реляционным СУБД. За счет некоторой избыточности сетевая и иерархическая модель могут быть сведены к табличной (реляционной) модели данных. Формируемая исключительно в форме множества таблиц, реляционная модель обеспечивает единообразное представление данных.
Сделал: Черняк Н.В.
Ме́тод — осознание формы внутреннего самодвижения содержания изучаемого предмета.
В отличие от области знаний или исследований, является авторским, то есть созданным конкретной персоной или группой персон, научной или практической школой. В силу своей ограниченности рамками действия и результата, методы имеют тенденцию устаревать, преобразовываясь в другие методы, развиваясь в соответствии со временем, достижениями технической и научной мысли, потребностями общества. Совокупность однородных методов принято называть подходом. Развитие методов является естественным следствием развития научной мысли.
Методология — это система принципов, а также совокупность идей, понятий, методов, способов и средств, определяющих стиль разработки программного обеспечения.
Методология — это реализация стандарта. Сами стандарты лишь говорят о том, что должно быть, оставляя свободу выбора и адаптации.
Конкретные вещи реализуется через выбранную методологию. Именно она определяет, как будет выполняться разработка. Существует много успешных методологий создания программного обеспечения. Выбор конкретной методологии зависит от размера команды, от специфики и сложности проекта, от стабильности и зрелости процессов в компании и от личных качеств сотрудников.
Методологии представляют собой ядро теории управления разработкой программного обеспечения. К существующей классификации в зависимости от используемой в ней модели жизненного цикла (водопадные и итерационные методологии) добавилась более общая классификация на прогнозируемые и адаптивные методологии.
Источник
Проектирование ИС охватывает три основные области:
- проектирование объектов данных, которые будут реализованы в базе данных;
- проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;
- учет конкретной среды или технологии, а именно: топологии сети, конфигурации аппаратных средств, используемой архитектуры (файл-сервер или клиент-сервер), параллельной обработки, распределенной обработки данных и т.п.
Проектирование информационных систем всегда начинается с определения цели проекта. В общем виде цель проекта можно определить как решение ряда взаимосвязанных задач, включающих в себя обеспечение на момент запуска системы и в течение всего времени ее эксплуатации:
- требуемой функциональности системы и уровня ее адаптивности к изменяющимся условиям функционирования;
- требуемой пропускной способности системы;
- требуемого времени реакции системы на запрос;
- безотказной работы системы;
- необходимого уровня безопасности;
- простоты эксплуатации и поддержки системы.
Согласно современной методологии, процесс создания ИС представляет собой процесс построения и последовательного преобразования ряда согласованных моделей на всех этапах жизненного цикла (ЖЦ) ИС. На каждом этапе ЖЦ создаются специфичные для него модели - организации, требований к ИС, проекта ИС, требований к приложениям и т.д. Модели формируются рабочими группами команды проекта, сохраняются и накапливаются в репозитории проекта. Создание моделей, их контроль, преобразование и предоставление в коллективное пользование осуществляется с использованием специальных программных инструментов - CASE-средств.
Процесс создания ИС делится на ряд этапов, ограниченных некоторыми временными рамками и заканчивающихся выпуском конкретного продукта (моделей, программных продуктов, документации и пр.).
Обычно выделяют следующие этапы создания ИС: формирование требований к системе, проектирование, реализация, тестирование, ввод в действие, эксплуатация и сопровождение.
Начальным этапом процесса создания ИС является моделирование бизнес-процессов, протекающих в организации и реализующих ее цели и задачи. Модель организации, описанная в терминах бизнес-процессов и бизнес-функций, позволяет сформулировать основные требования к ИС. Это фундаментальное положение методологии обеспечивает объективность в выработке требований к проектированию системы. Множество моделей описания требований к ИС затем преобразуется в систему моделей, описывающих концептуальный проект ИС. Формируются модели архитектуры ИС, требований к программному обеспечению (ПО) и информационному обеспечению (ИО). Затем формируется архитектура ПО и ИО, выделяются корпоративные БД и отдельные приложения, формируются модели требований к приложениям и проводится их разработка, тестирование и интеграция.
Целью начальных этапов создания ИС, выполняемых на стадии анализа деятельности организации, является формирование требований к ИС, корректно и точно отражающих цели и задачи организации-заказчика. Чтобы специфицировать процесс создания ИС, отвечающей потребностям организации, нужно выяснить и четко сформулировать, в чем заключаются эти потребности. Для этого необходимо определить требования заказчиков к ИС и отобразить их на языке моделей в требования к разработке проекта ИС так, чтобы обеспечить соответствие целям и задачам организации.
Задача формирования требований к ИС является одной из наиболее ответственных, трудно формализуемых и наиболее дорогих и тяжелых для исправления в случае ошибки. Современные инструментальные средства и программные продукты позволяют достаточно быстро создавать ИС по готовым требованиям. Но зачастую эти системы не удовлетворяют заказчиков, требуют многочисленных доработок, что приводит к резкому удорожанию фактической стоимости ИС. Основной причиной такого положения является неправильное, неточное или неполное определение требований к ИС на этапе анализа.
На этапе проектирования прежде всего формируются модели данных. Проектировщики в качестве исходной информации получают результаты анализа. Построение логической и физической моделей данных является основной частью проектирования базы данных. Полученная в процессе анализа информационная модель сначала преобразуется в логическую, а затем в физическую модель данных.
Параллельно с проектированием схемы базы данных выполняется проектирование процессов, чтобы получить спецификации (описания) всех модулей ИС. Оба эти процесса проектирования тесно связаны, поскольку часть бизнес-логики обычно реализуется в базе данных (ограничения, триггеры, хранимые процедуры). Главная цель проектирования процессов заключается в отображении функций, полученных на этапе анализа, в модули информационной системы. При проектировании модулей определяют интерфейсы программ: разметку меню, вид окон, горячие клавиши и связанные с ними вызовы.
Конечными продуктами этапа проектирования являются:
- схема базы данных (на основании ER-модели, разработанной на этапе анализа);
- набор спецификаций модулей системы (они строятся на базе моделей функций).
Кроме того, на этапе проектирования осуществляется также разработка архитектуры ИС, включающая в себя выбор платформы (платформ) и операционной системы (операционных систем). В неоднородной ИС могут работать несколько компьютеров на разных аппаратных платформах и под управлением различных операционных систем. Кроме выбора платформы, на этапе проектирования определяются следующие характеристики архитектуры:
- будет ли это архитектура "файл-сервер" или "клиент-сервер";
- будет ли это 3-уровневая архитектура со следующими слоями: сервер, ПО промежуточного слоя (сервер приложений), клиентское ПО;
- будет ли база данных централизованной или распределенной. Если база данных будет распределенной, то какие механизмы поддержки согласованности и актуальности данных будут использоваться;
- будет ли база данных однородной, то есть, будут ли все серверы баз данных продуктами одного и того же производителя (например, все серверы только Oracle или все серверы только DB2 UDB). Если база данных не будет однородной, то какое ПО
- будет использовано для обмена данными между СУБД разных производителей (уже существующее или разработанное специально как часть проекта);
- будут ли для достижения должной производительности использоваться параллельные серверы баз данных (например, Oracle Parallel Server, DB2 UDB и т.п.).
Этап проектирования завершается разработкой технического проекта ИС.
На этапе реализации осуществляется создание программного обеспечения системы, установка технических средств, разработка эксплуатационной документации.
Этап тестирования обычно оказывается распределенным во времени.
После завершения разработки отдельного модуля системы выполняют автономный тест, который преследует две основные цели:
- обнаружение отказов модуля (жестких сбоев);
- соответствие модуля спецификации (наличие всех необходимых функций, отсутствие лишних функций).
После того как автономный тест успешно пройден, модуль включается в состав разработанной части системы и группа сгенерированных модулей проходит тесты связей, которые должны отследить их взаимное влияние.
Далее группа модулей тестируется на надежность работы, то есть проходят, во-первых, тесты имитации отказов системы, а во-вторых, тесты наработки на отказ. Первая группа тестов показывает, насколько хорошо система восстанавливается после сбоев программного обеспечения, отказов аппаратного обеспечения. Вторая группа тестов определяет степень устойчивости системы при штатной работе и позволяет оценить время безотказной работы системы. В комплект тестов устойчивости должны входить тесты, имитирующие пиковую нагрузку на систему.
Затем весь комплект модулей проходит системный тест - тест внутренней приемки продукта, показывающий уровень его качества. Сюда входят тесты функциональности и тесты надежности системы.
Последний тест информационной системы - приемо-сдаточные испытания. Такой тест предусматривает показ информационной системы заказчику и должен содержать группу тестов, моделирующих реальные бизнес-процессы, чтобы показать соответствие реализации требованиям заказчика.
Необходимость контролировать процесс создания ИС, гарантировать достижение целей разработки и соблюдение различных ограничений (бюджетных, временных и пр.) привело к широкому использованию в этой сфере методов и средств программной инженерии: структурного анализа, объектно-ориентированного моделирования, CASE-систем.
Источник 1
Источник 2