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

Введение

 

 

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

 

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

 

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

 

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

 

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

 

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

 

Существует специальный  класс программных систем для  поддержки построения разных типов  концептуальных моделей ИС и автоматизации  проектирования на их основе логических моделей ИС, а также разработки различной документации и генерации  отчетов. Эти программные средства называются CASE-системами, к ним относятся  такие известные продукты как CASE-Аналитик, BPWin, ERWin и многие другие. Кроме того, CASE-средства разработки входят в состав таких мощных СУБД как Oracle.

 

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

 

В данном пособии рассматривается  процесс концептуального проектирования без использования CASE-средств и  объектно-ориентированных методов. Изложение рассматриваемых вопросов согласовано с содержанием учебного пособия «Информационные системы», изданного в ПетрГУ в 2005 г. [1]

 

Одной из широко распространенных современных СУБД является Microsoft SQL Server, различные версии которой выпускаются с 1994 г. В своем составе система имеет средства создания баз данных, работы с информацией баз данных, перенесения данных из других систем и в другие системы, резервного копирования и восстановления данных, развитую систему транзакций, систему репликации данных, реляционную подсистему для анализа, оптимизации и выполнения запросов клиентов, систему безопасности для управления правами доступа к объектам базы данных и другие компоненты.

 

В учебном процессе ПетрГУ используется версия SQL Server 2005. <#"justify">Модели информационных систем

 

 

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

 

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

 

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

 

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

 

В связи с диверсификацией  деятельности поступил заказ от руководства  фирмы «Безенчук и компаньоны»  на разработку информационной системы  с целью повышения эффективности  управления.

 

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

 

 

Функциональное моделирование  ИС

 

 

Существует несколько  различных методик и средств  разработки структурно-функциональных моделей ИС. Одним из широко распространенных является метод, основанный на построении диаграмм потоков данных (DFD - Data Flow Diagrams)

 

 

Диаграмма потоков данных

 

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

 

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

 

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

 

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

 

 

 

Рис.1

 

 

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

 

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

 

 

Рис.2

 

 

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

 

 

 

Рис.3

 

 

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

 

 

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

 

Контекстная диаграмма для  описанного выше примера представлена на рис.4.

 

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

 

 

 

Рис.4

 

 

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

 

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

 

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

 

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

 

 

Декомпозиция процессов

 

 

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

 

Первым шагом в декомпозиции контекстной диаграммы на рис.4 может  быть декомпозиция основного процесса на несколько подпроцессов, каждый из которых соответствует определенной внешней сущности (декомпозиция по внешним сущностям). Результат такой декомпозиции представлен на рис.5.

 

 

Рис.5

 

 

В результате декомпозиции на диаграмме появились новые потоки данных между подпроцессами: от Р2 к Р1 - «мебель, которая должна быть изготовлена», от Р2 к Р3 - «приобретенная старая мебель», от Р3 к Р4 «невостребованная старая мебель».

 

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

 

Дадим краткое описание декомпозиции процессов Р1, Р2, Р3 и Р4.

 

На рис. 6 показана декомпозиция процесса Р1 и используемые этим процессом  накопители данных.