Главная | Обратная связь | Поможем написать вашу работу!

Принципы построения документальных информационных систем. Информационно-поисковые системы.

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

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

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

1.анализ информационных интересов пользователей в данной предметной области.2.определение источников формирования БД.3.выбор архитектуры БД.4.разработка языка описания документа.

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

Одним из широкодоступных и активно используемых русско-язычных лингвистических банков данных является электронный вариант грамматического словаря русского языка Зализняк. Словарь состоит из двух частей. В 1 части называемой грамматические сведения представлена оригинальная модель русского словоизменения. Во 2 приведено около 100 тыс слов, которым приписаны грамматические индексы характеризующие тип их словоизменения и схему ударения.

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

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

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

Целью ИПС явл-ся выдача релевантных док-тов (relevant – относящ-ся к делу), т.е. семантически соответствующих запросу. Массив док-тов разделяется на выданные и невыданные, на релевантные и нерелевантные.

Документы можно разделить на: релев-выд. нерелев-выд.; релев-невыд.; нерелев-невыд.

В идеальной ИПС релев.невыд.=нерев.выд = 0

Релевантность.

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

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

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

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

2, Принципы построения фактографических информационных систем.

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

Информационной системой - большие массивы данных об объектах и явлениях реального мира вместе с программно-аппаратными средствами для их обработки

Целью ИС является обработка данных об объектах, содержащихся в базах данных, с учётом связей между объектами.

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

В фактографических информационных системах регистрируются факты. Основная идея таких систем заключается в том, что все сведения об объектах хранятся в компьютере в каком-то заранее обусловленном формате. Т.е. информация, с которой работает фактографическая ИС имеет чёткую структуру. Благодаря этому фактографическая ИС способна давать однозначные ответы на поставленные вопросы. Например ответить на вопрос о том, какие культурно-исторические памятники Украины занесены в список ЮНЕСКО, или выдать фамилии студентов, имеющих академическую задолженность.

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

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

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

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

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

3, Технология проектирования экономических информационных систем.

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

Методология реализуется через конкретные технологии.

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

- пошаговая процедура, определяющая последовательность технологич-х операций проектирования

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

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

Методология RAD (repeat application development) – методология быстрой разработки приложений. Под этим термином обычно понимается процесс разработки ПО, сод-щий 3 элемента:

1. небольшая команда программистов (2-10 человек)

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

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

Д Методология RAD (repeat application development) – методология быстрой разработки приложений. Под этим термином обычно понимается процесс разработки ПО, сод-щий 3 элемента:

1. небольшая команда программистов (2-10 человек)

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

ЖЦ ПО по методологии RAD:

1) Фаза анализа и планирования требований.

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

2) Фаза проектирования.

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

3) Фаза построения.

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

4) Фаза внедрения.

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

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

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

1. <1000 функциональных элементов - один человек;

2. 1000 - 4000 функциональных элементов - одна команда разработчиков;

3. >4000 функциональных элементов - 4000 функциональных элементов на одну команду разработчиков.

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

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

Две основные модели ЖЦ:

• каскадная модель;

• спиральная модель.

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

Анализ->проектирование->реализация->внедрение->сопровождение

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

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

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

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

Система «сверху–вниз». разбивается на функции подсистем, которые делятся на подфункции, которые подразделяются на задачи и т. д. Процесс разбиения продолжается до конкретных процедур. И.С. сохраняет целостное представление, в котором все составные компоненты взаимосвязаны.

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

5, Case-средства для проектирования ИС.

ЖЦ ИС — это процесс ее построения и развития.

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

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

Современные CASE-средства охватывают обширную область поддержки многочисленных технологий проектирования ЭИС: от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь ЖЦ ПО.Современный рынок прогр-х средств насчитывает около 300 различных CASE-средств, наиболее мощные из которых так или иначе исп-ся всеми ведущими западными фирмами. CASE-средства: Silverrun, Oracle, Designer, BpWin, ErWin, RationalRose.

ErWin – реализация моделирования в ErWin базируется на теории реляционных БД и методологии IDEF

Rational Rose – предназначена для автоматиз-ии процессов анализа и проектир-ия ПО, а также для генерации кодов на различных языках и выпуска проектной документации. RR использует метод ОО анализа и проектирования

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

-ускорение и повышение согласованности разработки приложений;

-снижение доли ручного труда в процессе разработки и/или эксплуатации;

-более точное соответствие приложений требованиям пользователей;

-отсутствие необходимости большой переделки приложений для повышения их эффективности;

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

-лучшее документирование;

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

-последовательное и постоянное повышение качества проектирования;

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

-лучшая прогнозируемость затрат.

Несмотря на все потенциальные возможности CASE-средств, существует множество примеров их неудачного внедрения

В связи с этим необходимо отметить следующее:

1)CASE-средства не обязательно дают немедленный эффект; результат может быть получен только спустя какое-то время;

2)реальные затраты на внедрение CASE-средств обычно намного превышают затраты на их приобретение;

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

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

Фаза внедрения.

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

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

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

1. <1000 функциональных элементов - один человек;

2. 1000 - 4000 функциональных элементов - одна команда разработчиков;

3. >4000 функциональных элементов - 4000 функциональных элементов на одну команду разработчиков.

6, Методология структурного проектирования.

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

Наиболее распространенные методологии структурного подхода базируются на 2х базовых признаках:

1) принцип «разделяй и влавствуй»-разделение сложных задач на множество легких, легких для понимания.

2) Принцип иерархического упорядочивания- с добавлением новых деталей на каждом уровне.

Др. п ринципы:

1. Абстрагирование – выделение существенных аспектов системы и отвлечение от несущественных.

2. Формализация – необходимость строгого методического подхода к решению проблемы.

3. Непротиворечивость – обоснованность и согласованность элементов.

4. Структурирование данных – данные должны быть структурированы и иерархичны.

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

· SADT модели и соответствующие функциональные диаграммы;(IDEF0)

· IDEF3 диаграммы потоков работ, дополняющие IDEF0

· DFD – диаграммы потоков данных

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

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

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

7 Структура и содержание информационного обеспечения информационных систем

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

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

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

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

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

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

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

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

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

II. Банк данных. Банк данных (БнД) – это система специальным образом организованных данных (баз данных), программных, технических, языковых, организационно-методических средств, предназначенных для обеспечения централизованного накопления и коллективного многоцелевого использования данных.

Модель данных - совокупность структур данных и операций их обработки.

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

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

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

8, Постановка задачи на разработку автоматизированных информационных систем.

Существует ГОСТ 19.102-77 (государственный стандарт), который определяет стадии разработки.

1. Техническое задание

1,1Обоснование необходимости разработки программы

-Постановка задачи

-Сбор исходных материалов

- Выбор и обоснование критериев эффективности и качества разрабатываемой программы.

- Обоснование необходимости проведения научно-исследовательских работ.

1,2 Научно-исследовательские работы

-Определение структуры входных и выходных данных.

-Предварительный выбор методов решения задач.

-Обоснование целесообразности применения ранее разработанных программ.

-Определение требований к техническим средствам.

- Обоснование принципиальной возможности решения поставленной задачи

1,3Разработка и утверждение технического задания

-Определение требований к программе.

-Разработка технико-экономического обоснования разработки программы.

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

-Выбор языков программирования.

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

-Согласование и утверждение технического задания.

2. Эскизный проект

2,1Разработка эскизного проекта

-Предварительная разработка структуры входных и выходных данных.

-Уточнение методов решения задачи.

-Разработка общего описания алгоритма решения задачи

-Разработка технико-экономического обоснования.

2,2Утверждение эскизного проекта

-Разработка пояснительной записки.

-Согласование и утверждение эскизного проекта.

3. Технический проект

3,1Разработка технического проекта

-Уточнение структуры входных и выходных данных.

-Разработка алгоритма решения задачи.

-Определение формы представления входных и выходных данных.

-Определение семантики и синтаксиса языка.

-Разработка структуры программы.

-Окончательное определение конфигурации технических средств.

3,2Утверждение технического проекта

-Разработка плана мероприятий по разработке и внедрению программ.

-Разработка пояснительной записки.

-Согласование и утверждение технического проекта.

4. Рабочий проект

4,1 Разработка программы

-Программирование и отладка программы.

-Разработка программной документации

-Разработка программных документов в соответствии с требованиями ГОСТ 19.101-77.

4,2Испытания программы

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

-Проведение предварительных государственных, межведомственных, приёмо-сдаточных и других видов испытаний.

-Корректировка программы и программной документации по результатам испытаний.

5. Внедрение

5,1Подготовка и передача программы.

-Подготовка и передача программы и программной документации для сопровождения и (или) изготовления.

-Оформление и утверждение акта о передаче программы на сопровождение и (или) изготовление.

- Передача программы в фонд алгоритмов и программ.

Воспользуйтесь поиском по сайту: