реферат информациоеые системы. Пензенский государственный университет архитектуры и строительства
 Скачать 29.89 Kb.
|
|
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ ФГБОУ ВО "Пензенский государственный университет архитектуры и строительства" Инженерно-строительный институт Кафедра информационно-вычислительных систем по дисциплине « информационные системы Сравнительный анализ методологий проектирования архитектуры информационных систем" выполнил(а): Фамилия Имя литвинова э в студент(ка) 2 курса очной формы обучения направления подготовки 09.03.02 Информационные системы и технологии группа ИСТ- ____________________________ (подпись студента) Научный руководитель: , ст. преподаватель кафедры ИВС ____________________________ (подпись руководителя) по сфере применения 6 1.3 Классификация по способу организации 7 2 Проектирование информационных систем 14 2.1 Жизненый цикл ИС 14 2.2 Методология проектирования 15 2.2.1 Общие требования к методолгии проектирования 15 2.2.2 Задача методологии проектирования ИС 15 2.3 Технологии проектирования ИС 16 2.3.1 Проектирование систем на основе концептуального моделирования предметной области 17 2.3.2 Макетирование информационных систем 19 2.3.3 САSЕ-технологии проектирования систем 21 Заключение 23 Список использованной литературы 24 Введение В прошлом информация считалась сферой бюрократической работы и ограниченным инструментом для принятия решений. Сегодня информация рассматривают как один из основных ресурсов развития общества, а информационные системы и технологии – как средство повышения производительности и эффективности людей. Наиболее широко информационные системы и технологии используются в производственной, управленческой и финансовой деятельности, хотя относительно необходимости их внедрения и активного применения начались подвижки в сознании людей, занятых в других сферах. Создание современных электронных вычислительных машин позволило автоматизировать обработку данных во многих сферах человеческой деятельности. Без современных систем обработки данных трудно представить сегодня передовые производственные технологии, управление экономикой на всех ее уровнях, научные исследования, образование, издательское дело, функционирование средств массовой информации, проведение крупных спортивных состязаний. Значительно расширило сферу применения систем обработки данных появление персональных компьютеров. Одним из наиболее распространенных классов систем обработки данных являются информационные системы. Цель моей работы заключается в том что бы определить, в чем заключаются специфические особенности информационных систем, какие функции они могут выполнять, какими ресурсами они располагают, а так же рассмотреть их проектирование. 1 Классификация информационных систем Под системой понимают любой объект, который одновременно рассматривается и как единое целое, и как объединенная в интересах достижения поставленных целей совокупность разнородных элементов. Системы значительно различаются между собой как по составу, так и по достигаемым целям. Информационные системы обеспечивают сбор, хранение, обработку, поиск и выдачу информации, необходимой в процессе принятия решений в любой области деятельности. Они помогают анализировать проблемы и создавать новые продукты. Информационная система – взаимосвязанная совокупность средств, методов и персонала, используемых для хранения, обработки и выдачи информации в интересах достижения поставленой цели. Современное понимание информационной системы предполагает использование персонального компьютера в качестве основного технического средства переработки информации. В крупных организациях наряду с персональным компьютером в состав технической базы информационной системы может входить мэйнфрейм или суперЭВМ. Кроме того, техническое воплощение информационной системы само по себе ничего не будет значить, если не учтена роль человека, для которого предназначена производимая информация и без которого невозможно ее получение и представление. В свою очередь информационные системы классифицируются по разным признакам. Рассмотрим наиболее часто используемые способы классификации 1.1 Классификация по масштабу По масштабу информационные системы подразделяются на следующие группы (рис. 1): Одиночные информационные системы. реализуются, как правило, на автономном персональном компьютере (сеть не используется). Такая система может содержать несколько простых приложений, связанных общим информационным фондом, и рассчитана на работу одного пользователя или группы пользователей, разделяющих по времени одно рабочее место. Подобные приложения создаются с помощью так называемых настольных ИЛИ локальных систем управления базами данных (СУБД). Среди локальных СУБД наиболее известными являются Clarion, Clipper, FoxPro, Paradox, dBase и Qicrosoft Access. Групповые информационные системы ориентированы на коллективное использование информации членами рабочей группы и чаще всего строятся на базе локальной вычислительной сети. При разработке таких приложений используются серверы баз данных (называемые также SQL-серверами) для рабочих групп. Существует довольно большое количество различных SQL-серверов, как коммерческих, так и свободно распространяемых. Среди них наиболее известны такие серверы баз данных, как Oracle, DB2, Qicrosoft SQL Server, InterBase, Sybase, Inforqix. Корпоративные информационные системы являются развитием систем для рабочих групп, они ориентированы на крупные компании и могут поддерживать территориально разнесенные узлы или сети. В основном они имеют иерархическую структуру из нескольких уровней. Для таких систем характерна архитектура клиент-сервер со специализацией серверов или же многоуровневая архитектура. При разработке таких систем могут использоваться те же серверы баз данных, что и при разработке групповых информационных систем. Однако в крупных информационных системах наибольшее распространение получили серверы Oracle, DB2 и Qicrosoft SQL Server. Для групповых и корпоративных систем существенно повышаются требования к надежности функционирования и сохранности данных. Эти свойства обеспечиваются поддержкой целостности данных, ссылок и транзакций в серверах баз данных. 1.2 Классификация по сфере применения По сфере применения информационные системы обычно подразделяются на четыре группы (рис. 2) Системы обработки транзакций, в свою очередь, по оперативности обработки данных, разделяются на пакетные информационные системы и оперативные информационные системы. В информационных системах организационного управления преобладает режим оперативной обработки транзакций — OLTP (OnLine Transaction Processing), для отражения актуального состояния предметной области в любой момент времени, а пакетная обработка занимает весьма ограниченную часть. Для систем OLTP характерен регулярный (возможно, интенсивный) поток довольно простых транзакций, играющих роль заказов, платежей, запросов и т. п. Важными требованиями для них являются: высокая производительность обработки транзакций; гарантированная доставка информации при удаленном доступе к БД по телекоммуникациям. Системы поддержки принятия решений — DSS (Decision Support Systeq) представляют собой другой тип информационных систем, в которых с помощью довольно сложных запросов производится отбор и анализ данных в различных разрезах: временных, географических и по другим показателям. Обширный класс информационно-справочных систем основан на гипертекстовых документах и мультимедиа. Наибольшее развитие такие информационные системы получили в сети Интернет. Класс офисных информационных систем нацелен на перевод бумажных документов в электронный вид, автоматизацию делопроизводства и управление документооборотом. 1.3 Классификация по способу организации По способу организации групповые и корпоративные информационные системы подразделяются на следующие классы (рис. 3): В любой информационной системе можно выделить необходимые функциональные компоненты (табл. 1), которые помогают понять ограничения различных архитектур информационных систем. Рассмотрим более подробно особенности вариантов построения информационных приложений. Таблица 1- Типовые функциональные компоненты информационной системы Архитектура файл-сервер имеет сетевого разделения компонентов диалога PS и PL и использует компьютер для функций отображения, что облегчает построение графического интерфейса. Файл-сервер только извлекает данные из файлов, так что дополнительные пользователи и приложения добавляют лишь незначительную нагрузку на центральный процессор. Каждый новый клиент добавляет вычислительную мощность к сети. Объектами разработки в файл-серверном приложении являются компоненты приложения, определяющие логику диалога PL, а также логику обработки BL и управления данными DL. Разработанное приложение реализуется либо в виде законченного загрузочного модуля, либо в виде специального кода для интерпретации. Однако такая архитектура имеет существенный недостаток: при выполнении некоторых запросов к базе данных клиенту могут передаваться большие объемы данных, загружая сеть и приводя к непредсказуемости времени реакции. Значительный сетевой трафик особенно сильно сказывается при организации удаленного доступа к базам данных на файл-сервере через низкоскоростные каналы связи. Одним из вариантов устранения данного недостатка является удаленное управление файл-серверным приложением в сети. При этом в локальной сети размещается сервер приложений, совмещенный с телекоммуникационным сервером (обычно называемым сервером доступа), в среде которого выполняются обычные файл-серверные приложения. Особенность состоит в том, что диалоговый ввод-вывод поступает от удаленных клиентов через телекоммуникации. Приложения не должны быть слишком сложными, иначе велика вероятность перегрузки сервера, или же нужна очень мощная платформа для сервера приложений Архитектура клиент-сервер предназначена для разрешения проблем файл-серверных приложений путем разделения компонентов приложения и размещения их там, где они будут функционировать наиболее эффективно. Особенностью архитектуры клиент-сервер является использование выделенных серверов баз данных, понимающих запросы на языке структурированных запросов SQL (Structured Query Language) и выполняющих поиск, сортировку и агрегирование информации. Отличительная черта серверов БД — наличие справочника данных, в котором записана структура БД, ограничения целостности данных, форматы и даже серверные процедуры обработки данных по вызову или по событиям в программе. Объектами разработки в таких приложениях помимо диалога и логики обработки являются, прежде всего, реляционная модель данных и связанный с ней набор SQL-операторов для типовых запросов к базе данных. Большинство конфигураций клиент-сервер использует двухуровневую модель, в которой клиент обращается к услугам сервера. Предполагается, что диалоговые компоненты PS и PL размещаются на клиенте, что позволяет обеспечить графический интерфейс. Компоненты управления данными DS и FS размещаются на сервере, а диалог (PS, PL), логика BL и DL — на клиенте. Двухуровневое определение архитектуры клиент-сервер использует именно этот вариант: приложение работает у клиента, СУБД — на сервере (рис. 4.). Поскольку эта схема предъявляет наименьшие требования к серверу, она обладает наилучшей масштабируемостью. Однако сложные приложения, вызывающие большое взаимодействие с БД, могут жестко загрузить как клиента, так и сеть. Результаты SQL-запроса должны вернуться клиенту для обработки, потому что там находится логика принятия решения. Такая схема приводит к дополнительному усложнению администрирования приложений, разбросанных по различным клиентским узлам. Для сокращения нагрузки на сеть и упрощения администрирования приложений компонент BL можно разместить на сервере. При этом вся логика принятия решений оформляется в виде хранимых процедур и выполняется на сервере БД. Хранимая процедура — процедура с операторами SQL для доступа к БД, вызываемая по имени с передачей требуемых параметров и выполняемая на сервере БД. Хранимые процедуры могут компилироваться, что повышает скорость их выполнения и сокращает нагрузку на сервер. Хранимые процедуры улучшают целостность приложений и БД, гарантируют актуальность коллективно используемых операций и вычислений. Улучшается сопровождение таких процедур, а также безопасность (нет прямого доступа к данным). Создание архитектуры клиент-сервер возможно и на основе многотерминальной системы. В этом случае в многозадачной среде сервера приложений выполняются программы пользователей, а клиентские узлы вырождены и представлены терминалами. Подобная схема информационной системы характерна для UNIX. В настоящее время архитектура клиент-сервер получила признание и широкое распространение как способ организации приложений для рабочих групп и информационных систем корпоративного уровня. Подобная организация работы повышает эффективность выполнения приложений за счет использования возможностей сервера БД, разгрузки сети и обеспечения контроля целостности данных. Двухуровневые схемы архитектуры клиент-сервер могут привести к некоторым проблемам в сложных информационных приложениях с множеством пользователей и запутанной логикой. Решением этих проблем может стать использование многоуровневой архитектуры. Многоуровневая архитектура стала развитием архитектуры клиент-сервер и в своей классической форме состоит из трех уровней: нижний уровень представляет собой приложения клиентов, выделенные для выполнения функций и логики представлений PS и PL и имеющие программный интерфейс для вызова приложения на среднем уровне; средний уровень представляет собой сервер приложений, на котором выполняетсяприкладна логика BL и с которого логика обработки данных DL вызываетоперации с базой данных DS; верхний уровень представляет собой удаленный специализированный сервер базы данных, выделенный для услуг обработки данных DS и файловых операций FS (без риска использования хранимых процедур). Подобную концепцию обработки данных пропагандируют, в частности, фирмы Oracle, Sun, Borland и др. Трехуровневая архитектура позволяет еще больше сбалансировать нагрузку на разные узлы и сеть, а также способствует специализации инструментов для разработки приложений и устраняет недостатки двухуровневой модели клиент-сервер. Централизация логики приложения упрощает администрирование и сопровождение. Четко разделяются платформы и инструменты для реализации интерфейса и прикладной логики, что позволяет с наибольшей отдачей реализовывать их специалистам узкого профиля. Наконец, изменения прикладной логики не затрагивают интерфейса, и наоборот. Но поскольку границы между компонентами PL, BL и DL размыты, прикладная логика может появиться на всех трех уровнях. Сервер приложений с помощью монитора транзакций обеспечивает интерфейс с клиентами и другими серверами, может управлять транзакциями и гарантировать целостность распределенной базы данных. Средства удаленного вызова процедур наиболее соответствуют идее распределенных вычислений: они обеспечивают из любого узла сети вызов прикладной процедуры, расположенной на другом узле, передачу параметров, удаленную обработку и возврат результатов. С ростом систем клиент-сервер необходимость трех уровней становится все более очевидной. Продукты для трехзвенной архитектуры, так называемые мониторы транзакций, являются относительно новыми. Эти инструменты в основном ориентированы на среду UNIX, однако прикладные серверы можно строить на базе Qicrosoft Windows NT с использованием вызова удаленных процедур для организации связи клиентов с сервером приложений. На практике в локальной сети могут использоваться смешанные архитектуры (двухуровневые и трехуровневые) с одним и тем же сервером базы данных. С учетом глобальных связей архитектура может иметь больше трех звеньев. В настоящее время появились новые инструментальные средства для гибкой сегментации приложений клиент-сервер по различным узлам сети. Таким образом, многоуровневая архитектура распределенных приложений позволяетповысить эффективность работы корпоративной информационной системы и оптимизировать распределение ее программно-аппаратных ресурсов. Но пока на российском рынке по-прежнему доминирует архитектура клиент-сервер. Интернет/интранет-т хнологии В развитии технологии Интернет/интранет основной акцент пока что делается на разработке инструментальных программных средств. В то же время наблюдается отсутствие развитых средств разработки приложений, работающих с базами данных. Компромиссным решением для создания удобных и простых в использовании и сопровождении информационных систем, эффективно работающих с базами данных, стало объединение Интернет/интранет-технологии с многоуровневой архитектурой. При этом структура информационного приложения приобретает следующий вид: браузер — сервер приложений — сервер баз данных — сервер динамических страниц — web-сервер. Благодаря интеграции Интернет/интранет-те нологии и архитектуры клиент-сервер процесс внедрения и сопровождения корпоративной информационной системы существенно упрощается при сохранении достаточно высокой эффективности и простоты совместного использования информации. 2 Проектирование информационных систем 2.1 Жизненый цикл ИС Жизненный цикл ИС – весь период времени существования ИС, начиная от выработки первоначальной концепции этой системы и заканчивая ее моральным устареванием или потерей необходимости решения соответствующих задач. Жизненный цикл традиционно модулируется в виде некоторого числа последовательных фаз, а именно: Выработка требований к системе. Разработка требований к ПО. Общее проектирование. Детальное проектирование. Создание отдельных модулей. Тестирование отдельных модулей. Объединение модулей в систему. Выпуск системы. Эксплуатация и сопровождение системы. В целом жизненный цикл информационных систем включает следующие основные этапы: 1. Системный анализ - определение потребности, назначения ИС, основных функциональных характеристик ИС, оценка затрат и возможной эффективности применения ИС 2. Проектирование ИС - разработка структуры и компонент ИС, технологические процессы разработки и испытаний ИС, создание версии ИС и ее внедрение 3. Эксплуатация ИС - функционирование ИС при обработке информации по предметной области с целью выявления адекватности ее назначения 4. Сопровождение ИС - эксплуатационное обслуживание, развитие функциональных возможностей и повышение эксплуатационных характеристик ИС, тиражирование и адаптация к другим ИС. 2.2 Методология проектирования 2.2.1 Общие требования к методолгии проектирования Методология проектирования – процесс, включающий совокупность теоретических и инженерных знаний и обеспечивающий упорядоченное создание информационных систем. Методология проектирования включает три части: основные концепции и понятия, используемые при проектировании и реализации систем; технологию, организацию и управление процессом проектирования; инструментальные средства. Методология проектирования должна обеспечивать представление семантических требований к создаваемой системе и минимизировать потери информации при переходе от одного семантического уровня представления к другому. В этой связи большое значение имеют средства спецификации, используемые на различных уровнях представления данных. Под спецификацией понимается точное, полное описание требований, ясно сформулированное в терминах, характерных для целей данной задачи, а не для ее реализации. 2.2.2 Задача методологии проектирования ИС Современные методологии проектирования ИС должны обеспечивать представление следующей информации (задачи методологии): описание объекта автоматизации, а также места разрабатываемой информационной системы и целей, которые должны быть достигнуты в процессе разработки системы; описание функциональных возможностей ИС, достаточное для решения вопроса о том, что поставленные цели автоматизации достижимы; спецификации проекта, гарантирующие достижение заданных технических характеристик системы; описание реализации предлагаемой системы, достаточное для оценки времени разработки системы и необходимых для этой цели трудозатрат; детальный план создания системы с оценкой сроков разработки. Таким образом, современная методология проектирования должна поддерживать сбор данных, их анализ, проектирование, оценку проекта и оценку возможности удовлетворения техническим характеристикам разрабатываемой системы. 2.3 Технологии проектирования ИС Эволюция информационных систем от пакетной, массовой технологии обработки данных к системам, использующим базы данных, выявила три класса наиболее перспективных методологий проектирования. Первый из них ориентирован на концептуальное моделирование предметной области и технологию баз данных, второй – на выявление требований и спецификацию информационной системы через ее макетирование, третий — на системную архитектуру программных средств, поддерживаемую инструментальными средствами САSЕ (Сomputer Аided System Engineering)-технолог и. 2.3.1 Проектирование систем на основе концептуального моделирования предметной области Методология проектирования информационных систем на основе концептуального (понятийного) моделирования предметной области (ПРОБ) – одна из наиболее часто используемых. Она представляет собой структурированный процесс создания систем, который обычно разбивается на следующие шаги: анализ ПРОБ, проектирование ПРОБ, программирование ПРОБ, тестирование программного обеспечения (ПО) проекта, внедрение проекта. Создание ИС на основе методологии концептуального проектирования предполагает четыре этапа проектирования: сбор и анализ информационных потребностей пользователей и системный анализ предметной области; построение концептуальной (понятийной) модели предметной области; создание концептуальной модели базы данных; разработку системы с помощью инструментальных средств выбранной СУБД. Первый очень важный этап разработки системы – анализ требований – может быть определен как этап понимания задач приложений (программ). На втором этапе разработчики системы должны определить устойчивые свойства данных и описать информационные и технологические процессы, использующие данные, их взаимосвязь и характеристики. Иногда эту работу определяют как построение концептуальной (инфологической) модели предметной области, содержащей описание понятий, не ориентированное ни на какую конкретную даталогическую модель. В настоящее время для построения концептуальной модели предметной области обычно используют два подхода. При первом подходе модель ПРОБ строится на основе интеграции спецификаций информационных потребностей, а при втором – на основе непосредственного анализа самой ПРОБ. В методологиях проектирования, основанных на непосредственном создании концептуальной модели предметной области, основной задачей является получение формального (независимого от СУБД) описания предметной области, которая должна моделироваться в БД. При этом система проектирования и методология проектирования должны поддерживать как получение от пользователей знаний о свойствах предметной области, так и отображение этих упорядоченных и организованных знаний в набор предварительных описаний, составляющих собственно концептуальную модель предметной области. Информации должно быть достаточно, чтобы принимать правильные решения при проектировании не только БД, но и программной реализации задач. Основной проблемой третьего этапа является принятие решения о выделении из множества понятий концептуальной модели предметной области таких объектов, которые должны моделироваться в БД. На первых трех этапах проводится не зависящий от технических и системных программных средств анализ целей и назначения проектируемой ИС и моделируются основные информационные и технологические процессы ее функционирования. Результаты, полученные на этих этапах, имеют фундаментальный характер и не изменяются при развитии технической и программной базы ИС. Заключительный (четвертый) этап проектирования тесно связан с возможностями инструментальных средств конкретных СУБД. Данный этап в свою очередь разбивают на следующие шаги: логическое проектирование БД; физическое проектирование БД; реализация приложений. Основу вышеизложенной методологии составляет жестко регламентированная последовательность шагов, каждый из которых должен завершаться формальной спецификацией вне зависимости от того, насколько точно сформулированы спецификации предыдущих этапов проектирования. Такая стратегия проектирования обычно гарантирует разработку удовлетворительной системы при условии, что требования к системе фиксируются, и их изменение не допускается до тех пор, пока система не предъявляется пользователям. Основной недостаток методологии состоит в том, что ошибки проектирования могут быть обнаружены только на последних стадиях проектирования (либо при тестировании системы, либо во время проведения испытаний), что требует пересмотра всех спецификаций проекта и ведет к значительным трудозатратам. 2.3.2 Макетирование информационных систем Практика показывает, что зачастую требования пользователей к ИС не вполне определены и, поэтому, необходимо ориентироваться на постоянные изменения требований к системе, учесть которые можно только при динамической спецификации этих требований. Наиболее приемлемым в этом случае может быть подход, когда требования к системе формируются не сразу, а в процессе разработки функционирующего макета системы. Макет системы создается на основе той минимальной информации, которую могут сообщить пользователи. Цель макетирования состоит в следующем. Макет системы дает возможность конкретизировать проблемы, возникающие между разработчиком и пользователем, существенно сокращает задержку во времени между формулированием требований и первой демонстрацией действующей системы, обеспечивая тем самым эффективный контроль над проектом системы на всех этапах ее жизненного цикла. Однако такая стратегия проектирования может успешно применяться только для небольших и сравнительно простых систем, макет которых может быть создан за достаточно короткое время. Для проектирования больших и сложных систем с неопределенными требованиями пользователей предназначены смешанные подходы. Один из них предусматривает этап макетирования на начальной стадии анализа требований к информационной системе. После выявления информационных потребностей пользователей создаются детальные спецификации системы, которые на последующих этапах разработки системы используются обычным образом. В этом случае макетирование составляет основу для выявления истинных требований к информационной системе. Второй подход смешанной методологии предполагает, что этап структурированного анализа предшествует этапу макетирования. Но дальнейшая стратегия проектирования, по существу, совпадает с традиционной методологией. И если на более поздней стадии проекта потребуется внести изменения, то преимущества макетирования будут минимальными. Третий подход предполагает смешанную методологию пофазового проектирования. В ней присутствует фаза структурированного и общего проектирования, а макетирование выполняется на всех остальных этапах жизненного цикла системы. В этом случае стратегия постепенного улучшения, свойственная методологии макетирования, обеспечивает внесение изменений в эволюционирующую систему, прежде чем она будет полностью внедрена. Такой (третий) подход наиболее приемлем для информационных систем, которые могут быть разбиты на относительно независимые подсистемы, тогда последовательный порядок их реализации делает метод пофазового проектирования эффективным. Если же необходимо произвести такие изменения в подсистемах, которые влияют на другие подсистемы, то могут потребоваться значительные дополнительные усилия. |