Проектирование информационной системы

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

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

Проектир-е схемы БД м.б. выполнено 2 путями:

• декомпозиция (разбиение) – исходное мн-во отнош-й, входящих в схему БД заменяется другим мн-вом отнош-й (число их возрастает), явл-ихся проекциями исх-х отнош-й.
• Синтез – компоновка из заданных исх-х элементар-х зависимостей м/объектами предм-й обл-ти схемы БД.

Классич-я технология проектир-я  реляц-х БД связана с теорией  нормализации, основанной на анализе  ф-ционал-х завис-тей м/атрибутами отношений.    

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

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

13. Информационная модель: физическое проектирование.

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

Внешние д-е не подвержены изменениям физич-й памяти и метода доступа к БД.

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

 

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

Интегрир-ые ИС – совок-ть 2-х или более в/связ-х с-м, в к-рой ф-ционир-е каждой из них зависит от ф-ционир-я др-й.

Арх-ра совр-х  ИИС базир-ся на принципах клиент-серв-го в/д-я прогр-х компон-ов ИС.

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

Клиентом явл-ся прилож-е, посылающее запрос на обслуж-ие сервером. Клиент-серв-ая арх-ра реализ-т многопол-льский режим работы и явл-ся распред-ной, когда клиенты и серверы располаг-ся на разных узлах ЛВС/глобал-й ВС. В общем случае схема клиент-серверной архитектуры вкл-т 3 уровня: ур-нь представл-я д-х польз-лем; ур-нь обраб-ки д-х приложением и ур-нь в/д-я с БДой. Клиент-серверная архитектура м.б. реализована по-разному. Выбор конкр-й схемы опред-ся различ-ми вариантами территориал-го распред-я удаленных подразделений пр-ятия, требованиями эксплуатац-ой надеж-ти, быстродействием, простотой обслуж-я. Рассмотрим различ-е схемы.

1. Файл-серверная арх-ра предст-т наиб. простой случай распред-ой обраб-ки д-х, согласно к-рой на сервере располаг-ся только файлы д-х, а на клиентской части нах-ся прилож-я польз-лей вместе с СУБД. Файл-сервер предст-т собой достаточно мощную по производит-ти и ОЗУ ПЭВМ, явл-юся централ-м узлом ЛВС. Файл-сервер организует доступ к файлам. Использ-е файл-серверов предполаг., что вся обраб-ка д-х вып-ся на рабочей станции, а файл-сервер лишь вып-т ф-ции накопителя д-х и ср-в доступа.
2. 2хур-невая арх-ра основана на использ-и только сервера БДы, когда клиент на ур-не представл-я д-х, а на сервере нах-ся БД вместе с СУБД и прикл-ми прогами. DB-сервер дает возм-ть отказ-ся от пересылки по сети файла д-х целиком и предавать ту выборку из БД, к-рая удовл-ряет запросу польз-ля. При этом возм-но раздел-ие польз-кого прилож-я на 2 части:

1-я часть вып-ся на  сервере и связана с выборкой  и агрегир-ем д-х из БД,

2-я часть - по представл-ию  д-х д/анализа и принятия реш-й  вып-ся на клиенте. 

Т.о. увелич-ся общая производит-ть ИС в рез-те объедин-я вычислит-х  рес-сов сервера и клиента. Обращ-е  к БД осущ-ся на языке SQL. Сервер БД наз-т SQL-севером, к-рый поддерж-ся всеми реляц-ми СУБД: Oracle, MS-SQL, InterBase, Sybase.

3. 3хур-невая арх-ра позволяет помещать прикл-ые проги на отдельные серверы-прилож-й, с к-рыми через API-и-фейс устан-ся связь клиентов. Работа клиентской части прилож-я сводится к вызову необх-х ф-ций сервера-прилож-й, к-рые наз-ся сервисами. Прикл-ая прога в свою очередь обращ-ся к серверу БД с пом. SQL-запросов. Такая орг-ция позволяет еще больше увел-ть производит-ть и эфф-ть ИС за счет: 1. многократ-ти повтор-го использ-я общих ф-ций обраб-ки д-х в мн-ве клиентских прилож-й; 2. параллел-ти в работе сервера прилож-й и сервера БД; 3. оптимиз-и доступа к БД ч/сервер прилож-й из клиента путем диспетчериз-и вып-ния запросов; 4. повыш-я скорости и надеж-ти обраб-ки д-х в рез-те дублир-я ПО на неск-х серверах прилож-й; 5. переноса ф-ций админ-я с-мы по проверке полномочий доступа польз-лей с сервера БД на сервер прилож-й.
4. Многоур-вая архитектура создается д/тер-риально распред-х пр-ятий. Д/нее хар-но отнош-е m:n м/клиентами и серверами прилож-й. Здесь каждый сервер прилож-й обслуж-т потреб-ти одной ф-ционал-й подс-мы и сосредотачивается в головном д/подс-мы структурном подразделении. Интегрир-ая БД нах-ся на отдельном сервере, на к-ром обеспеч-ся централиз-ое ведение и администрир-е общих д-х д/всех прилож-й. Выделение неск-х серверов БД хар-но д/пр-ятий с филиальной структурой, когда в головном офисе использ-я общая БД, содержащая общую нормат.-справоч., планово-бюдж. инфу, а в филиале поддерж-ся опер-ая инфа о деловых процессах. При обраб-ке д-х в филиалах д/контроля использ-ся нормат.-справоч. и плановая инфа из централиз-ой БД, а в головном офисе получение консолидир-ой отчет-ти опред-ся обраб-кой опер-й инфы филиалов.

Клиент-серверная архитектура  КЭИС упрощает взаимодействие польз-лей  с ИС и м/собой.

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

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

С-ма упр-я инф. потоком  м.б. реализована на основе специализир-го ПО или встроена в контур интегрир-ой ЭИС.

 

15. Автоматизированное проектирование ИС с использованием CASE-технологии.

(Computer Aided System/Software Engineering) Большинство сущ-вующих CASE-с-м ориентировано на автоматизацию проектир-я ПО и основано на методологиях структурного (в основном) или объектно-ориентир-го проектир-я и программир-я, использующих спецификации в виде диаграмм или текстов д/описания с-мных треб-й, связей м/моделями с-мы, динамики поведения с-мы и архитектуры прогр-х ср-в.

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

Преимущ-ва CASE-технологии по ср-нию с традиц-й технологией оригинал-го проектир-я:

• улуч-е кач-ва разрабатыв-го ПО;
• возможность повторного использования компонентов разработки;
• поддержание адаптивности и сопровождения ЭИС;
• сниж-е времени созд-я с-мы,
• освобожд-е разраб-ков от рутинной работы по документир-ю проекта – использ-ся встроенный документатор;
• возможность коллективной разработки ЭИС в режиме реального времени.

Ф-ционально-ориентир-ое проектир-е ЭИС

Осн-ми идеями ф-ционально-ориентир-й CASE-технологии явл-ся идеи структурного анализа и проектир-я ИС. Они  заключаются в следующем:

1) декомпозиция всей с-мы  на некот-е мн-во иерархически  подчиненных ф-ций;

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

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

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

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

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

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

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

*ERD - Диаграммы инфологич-х моделей «сущность-связь» ориентированы на разраб-ку БДы, структура к-рой не зависит от конкр-х инф. потреб-тей и позвол-т вып-ть любые запросы польз-лей. ERD предст-т собой набор мн-ва объектов и их хар-к, а также в/связей м/ними, нужных для выявленных д-х, к-рые в дальнейшем использ-ся ф-циями проектируемой с-мы.

SSD - Диаграмма структуры прогр-го приложения задает в/связь ф-ций и прогр-х модулей, к-рые их реализуют (меню, формы, отчеты и т.д.). Структура прогр-го прилож-я представляет собой иерархич-ю в/связь прогр-х модулей, к-рые реализует ИС. SSD служит мостом д/перехода от с-мных треб-ний, к-рые отображены в предыд-х диаграммах (BFD, DFD, STD, ERD), к реализации ИСы.

Несомненным достоинством ф-ционал-х моделей  явл-ся реализация структурного подхода  к проектир-ю ЭИС по принципу «сверху-вниз».

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

Объектно-ориентир-ое проектир-ие ЭИС

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

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

В наст. время д/объектно-ориентир-го моделир-я проблемной обл-и широко использ-ся унифицир-й язык моделир-я UML. Язык UML реализован многими фирмами-производителями ПО в рамках CASE-технологий, напр. Rational Rose, Natural Engineering Workbench.

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