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

Жизненный цикл разработки информационной системы

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

1. Исследование и анализ. Главной задачей информационной системы является удовлетворение информационных потребностей бизнеса. Поэтому на первом этапе важно разобраться как протекают бизнес-процессы внутри организации, на какие потоки информации они опираются. Чаще всего это происходит в виде интервью с представителями разных отделов предприятия. На этом этапе важно получить исчерпывающую картину работы предприятия в формате который будет с одной стороны понятен разработчикам, а с другой - представителям бизнеса. На этом этапе нам на помощь могут прийти методологии IDEF0 и DFD, которые будут рассмотрены в этой лекции.
2. Прототипирование. На этом этапе моделируется структура информационной системы, структура хранилищ данных, пользовательские интерфейсы.
3. Построение и документирование. На этом этапе происходит согласование прототипа системы с требованиями заказчика. Поведение информационной системы детально документируется, для того чтобы в дальнейшем можно было сравнить ожидаемое и полученное поведение системы.
4. Внедрение. На этом этапе выполняется верификация соответствия реального и ожидаемого поведения системы. Зачастую это происходит в виде пиремо-сдаточных испытаний.
5. Использование. Этот этап разработки информационной системы рассматривается дисциплиной Техническая поддержка программных решений (Technical Solution Support). Он характеризуется гарантийным и послегарантийным обслуживанием информационной системы. Примером такого обслуживания может быть исправление ошибок, внесение новых функций, повышение производительности, обучение персонала и прочее.
    

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

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

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

При этом «концептуальная модель» это:

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

Методология IDEF0

Одной из распространенных методологий построения концептуальных моделей является IDEF0.

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

IDEF0 - это подмножество SADT (Structured Analisys and Design Technique). Методология SADT разрабатывалась Дугласом Т. Россом в 1969-1973 годах и изначально применялась для проектирования систем общего назначения. В данной методологии ключевым является в какую из сторон процесса направлен поток управления.

Поясним суть методологии IDEF0 на примере производства товара. Процесс производства условно изображен на слайде.

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

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

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

Правила интерпретации модели:

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

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

Анализ объекта на основе построения его IDEF0-модели является этапом, который должен предварять разработку информационной системы по целому ряду причин. Во-первых, при ознакомлении с объектом строят модель "КАК ЕСТЬ". Такая модель фиксирует бизнес процессы и используемые ими информационные потоки. Во-вторых, функциональная модель "КАК ЕСТЬ" позволяет увидеть информационно перегруженные бизнес процессы - "узкие" места обследуемого объекта. В-третьих, на основании модель "КАК ЕСТЬ" можно построить модель "КАК БУДЕТ". То есть предложить более совершенную структуру организации объекта. Но это уже вопросы реинжиниринга и мы их не будем касаться. Можно только отметить, что реинжиниринг подчеркивает важную роль информационных технологий в жизни общества. В-четвертых, в процессе построения модели "КАК ЕСТЬ" выявляются бизнес-правила - положения, которые регламентируют процесс функционирования моделируемого объекта. Например, представленный на слайде фрагмент функциональной модели должен быть зафиксирован бизнес-правилом: "служба снабжения обязана определять потребности в материалах для производства готовой продукции только на основании плана выпуска".

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

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

Методология Data Flow Diagram

Тот факт, что IDEF0-модель не разделяет потоки данных на материальные, информационные и управляющие приводит разработчиков к необходимости использовать диаграммы потоков данных (Data Flow Diagrams - DFD). Это можно делать после составления IDEF0-модели, либо вместо этого в зависимости от сложности моделируемого объекта или предпочтений исполнителя.

Основы методологии построения диаграмм потоков данных DFD были описаны в 1979 году C. Gane и T. Sarson в книге "Structured Systems Analysis".

Ее назначение - ограничить рамки системы, определить, где заканчивается разрабатываемая система и начинается среда.

Методология DFD оперирует 4 типами объектов. Их графическое представление представлено на слайде. Обратите внимание, что существует несколько нотаций в рамках методологии DFD. Графическое представление элементов в них несколько отличается. Но внутренне содержание остается неизменным. Давайте разберемся с типами объектов, которые используются в рамках DFD.

• External Entity (Внешняя сущность) представляет собой материальный предмет или физическое лицо, представляющее собой источник или приемник информации, например, заказчики, персонал, поставщики, клиенты, склад. Определение некоторого объекта или системы в качестве внешней сущности указывает на то, что она находится за пределами границ анализируемой ИС. В процессе анализа некоторые внешние сущности могут быть перенесены внутрь диаграммы анализируемой ИС, если это необходимо, или, наоборот, часть процессов ИС может быть вынесена за пределы диаграммы и представлена как внешняя сущность. Внешняя сущность обозначается квадратом, расположенным как бы "над" диаграммой и бросающим на нее тень, для того, чтобы можно было выделить этот символ среди других обозначений.
• Process (Процессы, Системы и подсистемы) - при построении модели сложной ИС она может быть представлена в самом общем виде на так называемой контекстной диаграмме в виде одной системы как единого целого, либо может быть декомпозирована на ряд подсистем. Процесс представляет собой преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом. Физически процесс может быть реализован различными способами: это может быть подразделение организации (отдел), выполняющее обработку входных документов и выпуск отчетов, программа, аппаратно реализованное логическое устройство и т.д.
• Datastore (Хранилище данных) представляет собой абстрактное устройство для хранения информации, которую можно в любой момент поместить в накопитель и через некоторое время извлечь, причем способы помещения и извлечения могут быть любыми.
• Dataflow (Поток данных) определяет информацию, передаваемую через некоторое соединение от источника к приемнику. Реальный поток данных может быть информацией, передаваемой по кабелю между двумя устройствами, пересылаемыми по почте письмами, магнитными лентами или дискетами, переносимыми с одного компьютера на другой и т.д. и т.п.

Аналогично IDEF0, для удобства DF-диаграммы разделяют на уровни.

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

На 1 уровне выделяются основные компоненты системы. С 0-го уровня сюда переносятся все потоки данных. Диаграмма дополняется потоками данных внутри системы и хранилищами данных.

На 2 и далее уровнях происходит постепенная детализация информационной системы.

Внешние сущности:

• объекты взаимодействующий с системой, но не относящийся к ней (поставщики и потребители информации, те для кого информационная система строится и кто задействован при работе с ней);
• должны быть отображены на уровнях 0 и 1 DF-диаграммы;
• не должны присутствовать на уровнях 2(3, …) диаграммы;
• должны иметь содержательное имя;
• могут иметь дубликаты на диаграмме.

Процессы:

• описывают действия с информацией;
• должны быть представлены на всех уровнях диаграммы:
• Уровень 0 - один процесс, описывающий систему;
• Уровень 1+ -рекомендуется размещать не более 7 процессов;
• дубликаты (процессы с одинаковым именем или содержанием) не допускаются.

Хранилища данных:

• указывает вид информации которые хранятся в системе (товары, накладные, персонал);
• не отображаются на уровне 0;
• все хранилища данных, которые есть в ИС должны быть указаны на уровне 1.

Потоки данных:

• отображают направление передачи данных;
• отображаются на всех уровнях диаграммы;
• должны иметь содержательное имя.

Алгоритм построения диаграммы

1. Определите входящие запросы или события, на которые должна реагировать система. Определите что система отвечает на них.
2. Определите кто формирует эти запросы и получает ответ (это внешние сущности).
3. Постройте диаграмму уровня 0 - на ней отображены только внешние сущности и главный процесс системы.
4. Постройте диаграмму уровня 1 - на ней должны быть отображены все внешние сущности, все хранилища данных, главные процессы и потоки информации между ними.
5. Проанализируйте и оптимизируйте диаграмму уровня 1. Рекомендуется на одном уровне диаграммы размещать 7±2 процесса.
6. Если требуется, детализируйте отдельные процессы на уровне 2(3,4 …).

Типичные ошибки построения DF-диаграмм

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

На DFD диаграмме не отображаются точки начала и окончания, решения(if) и циклы.

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

Внешние сущности не могут напрямую обращаться к хранилищам данных

Хранилище данных не может напрямую обращаться к другому хранилищу. Между ними должен быть процесс.

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

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

Избегайте процессов которые не имеют входящих потоков информации.

Избегайте процессов которые не имеют исходящих потоков информации.

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

Фирма функционирует следующим образом:

• Заказчики могут оставлять заявки на аренду.
• Менеджер подыскивает надвижимость и готовит проект договора.
• Клиент подписывает договор.

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

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

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

Диаграмма построена в предположении, что круг клиентов конторы относительно стабилен.

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

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

Наличие на диаграмме процесса "Подготовить договор аренды" - это следствие того, что "черновик" договора аренды готовит клерк, а менеджер принимает решение о заключении договора. Это повышает эффективность работы фирмы в целом.

Роль методологий в анализе моделируемого объекта (Выводы)

В результате анализа моделируемого информационной системой объекта на основе построения IDEF0 и DFD-диаграмм:

Определяют главную функцию проектируемой системы. Например, "сопровождать аренду недвижи­мости".

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

Например, так:

1. заключать договора аренды;
2. сопровождать хранение информации об объектах недвижимости.

Определяют обрабатываемые бизнес процессами информационными потоки. Например, так: "отправка договора менеджеру".

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

Как видим назначение концептуальной модели объекта:

1. прийти к общему с заказчиком представлению о моделируемом объекте;
2. представить, в общих чертах, проектируемую информационную систему. Дело в том, что потоки данных - это прообразы процедур приложения, а хранилища данных - таблиц базы данных.

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

Использование UML для проектирования систем

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

Каждая такая диаграмма или, как ее обычно называют, каждый Use case - это описание сценария поведения, которому следуют действующие лица (Actors).

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

Этот вид диаграмм предназначен для анализа аппаратной части системы, то есть "железа", а не программ. В прямом переводе с английского Deployment означает "развертывание", но термин "топология" точнее отражает сущность этого типа диаграмм.

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

Обычно этот тип диаграмм используется в самом начале проектирования системы для анализа аппаратных средств, на которых она будет эксплуатироваться.

State Maсhine diagram (диаграммы состояний)

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

Statechart diagram (диаграмма состояний)

Диаграмма состояний предназначена для отображения состояний объектов системы, имеющих сложную модель поведения. Это одна из двух диаграмм State Machine, доступ к которой осуществляется из одного пункта меню.

Activity diagram (диаграммы активности)

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

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

Interaction diagram (диаграммы взаимодействия)

Этот тип диаграмм включает в себя диаграммы Sequence diagram (диаграммы последовательностей действий) и Collaboration diagram (диаграммы сотрудничества). Эти диаграммы позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе.

Sequence diagram (диаграммы последовательностей действий)

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

Данный тип диаграмм позволяет отразить последовательность передачи сообщений между объектами.

Этот тип диаграммы не акцентирует внимание на конкретном взаимодействии, главный акцент уделяется последовательности приема/передачи сообщений. Для того чтобы окинуть взглядом все взаимосвязи объектов, служит Collaboration diagram.

Collaboration diagram (диаграммы сотрудничества)

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

Class diagram (диаграммы классов)

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

Значки диаграммы позволяют отображать сложную иерархию систем, взаимосвязи классов (Classes) и интерфейсов (Interfaces). Данный тип диаграмм противоположен по содержанию диаграмме Collaboration, на котором отображаются объекты системы. Классы имеют различные нотации. В нотации, предложенной Г. Бучем классы изображаются в виде чего-то нечеткого, похожего на облако. Таким образом Г.Буч пытается показать, что класс - это лишь шаблон, по которому в дальнейшем будет создан конкретный объект.

Component diagram (диаграммы компонентов)

Этот тип диаграмм предназначен для распределения классов и объектов по компонентам при физическом проектировании системы. Часто данный тип диаграмм называют диаграммами модулей.

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