1. Понятие структурного анализа и проектирования
Создателем структурного подхода к программированию и проектированию является Э.Дейкста. Фактически структурное программирование – это первая законченная методология программного обеспечения.
Сущность структурного подхода к разработке ИС заключается в ее декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны.
1.1 Идеи, лежащие в основе структурных методов
Структурные методы являются строгой дисциплиной системного анализа и проектирования, т.е. деятельностей, которые в прошлом были печально известны как сложные и перегруженные проблемами.
Методы структурного анализа и проектирования стремятся преодолеть сложность больших систем путем расчленения их на части ("черные ящики") и иерархической организации этих черных ящиков. Выгода в использовании черных ящиков заключается в том, что их пользователю не требуется знать, как они работают, необходимо знать лишь его входы и выходы, а также его назначение (т.е. функцию, которую он выполняет).
В окружающем нас мире черные ящики встречаются в большом количестве. Проиллюстрируем преимущества систем, составленных из них, на примере музыкального центра.
· Конструирование системы черных ящиков существенно упрощается. Намного легче разработать магнитофон или проигрыватель, если не беспокоиться о создании встроенного усилительного блока.
· Облегчается тестирование таких систем. Если появляется плохой звук одной из колонок, можно поменять колонки местами. Если неисправность переместилась с колонкой, то именно она подлежит ремонту; если нет, тогда проблема в усилителе, магнитофоне или местах их соединения.
· Имеется возможность простого реконфигурирования системы черных ящиков. Если колонка неисправна, то Вы можете отправить ее в ремонтную мастерскую, а сами пока продолжать слушать свои записи в моно-режиме.
· Облегчается доступность для понимания и освоения. Можно стать специалистом по магнитофонам без углубленных знаний о колонках.
· Увеличивается удобство при модификации. Вы можете приобрести колонки более высокого качества и более мощный усилитель, но это совсем не означает, что Вам необходим больших размеров проигрыватель.
Таким образом, первым шагом упрощения сложной системы является ее разбиение на черные ящики, при этом такое разбиение должно удовлетворять следующим критериям:
· каждый черный ящик должен реализовывать единственную функцию системы;
· функция каждого черного ящика должна быть легко понимаема независимо от сложности ее реализации (например, в системе управления ракетой может быть черный ящик для расчета места ее приземления: несмотря на сложность алгоритма, функция черного ящика очевидна - "расчет точки приземления");
· связь между черными ящиками должна вводиться только при наличии связи между соответствующими функциями системы (например, в бухгалтерии один черный ящик необходим для расчета общей заработной платы служащего, а другой для расчета налогов - необходима связь между этими черными ящиками: размер заработанной платы требуется для расчета налогов);
· связи между черными ящиками должны быть простыми, насколько это возможно, для обеспечения независимости между ними.
Второй важной идеей, лежащей в основе структурных методов, является идея иерархии. Для понимаемости сложной системы недостаточно разбиения ее на части, необходимо эти части организовать определенным образом, а именно в виде иерархических структур. Все сложные системы Вселенной организованы в иерархии. Да и сама она включает галактики, звездные системы, планеты, …, молекулы, атомы, элементарные частицы. Человек при создании сложных систем также подражает природе. Любая организация имеет директора, заместителей по направлениям, иерархию руководителей подразделений, рядовых служащих.
Наконец, третий момент: структурные методы широко используют графические нотации, также служащие для облегчения понимания сложных систем. Известно, что “одна картинка стоит тысячи слов”.
1.2 Принципы структурного анализа
Анализ требований разрабатываемой системы является важнейшим среди всех этапов ЖЦ. Он оказывает существенное влияние на все последующие этапы, являясь в то же время наименее изученным и понятным процессом. На этом этапе, во-первых, необходимо понять, что предполагается сделать, а во-вторых, задокументировать это, т.к. если требования не зафиксированы и не сделаны доступными для участников проекта, то они вроде бы и не существуют. При этом язык, на котором формулируются требования, должен быть достаточно прост и понятен заказчику.
Во многих аспектах системный анализ является наиболее трудной частью разработки. Нижеследующие проблемы, с которыми сталкивается системный аналитик, взаимосвязаны (и это является одной из главных причин их трудноразрешимости):
· аналитику сложно получить исчерпывающую информацию для оценки требований к системе с точки зрения заказчика;
· заказчик, в свою очередь, не имеет достаточной информации о проблеме обработки данных для того, чтобы судить, что является выполнимым, а что нет;
· аналитик сталкивается с чрезмерным количеством подробных сведений как о предметной области, так и о новой системе;
· спецификация системы из-за объема и технических терминов часто непонятна для заказчика;
· в случае понятности спецификации для заказчика, она будет являться недостаточной для проектировщиков и программистов, создающих систему.
Конечно, применение известных аналитических методов снимает некоторые из перечисленных проблем анализа, однако эти проблемы могут быть существенно облегчены за счет применения современных структурных методов, среди которых центральное место занимают методологии структурного анализа.
Структурным анализом принято называть метод исследования системы, которое начинается с ее общего обзора и затем детализируется, приобретая иерархическую структуру со все большим числом уровней. Для таких методов характерно разбиение на уровни абстракции с ограничением числа элементов на каждом из уровней (обычно от 3 до 6-7); ограниченный контекст, включающий лишь существенные на каждом уровне детали; дуальность данных и операций над ними; использование строгих формальных правил записи; последовательное приближение к конечному результату.
Все методологии структурного анализа базируются на ряде общих принципов, часть из которых регламентирует организацию работ на начальных этапах ЖЦ, а часть используется при выработке рекомендаций по организации работ. В качестве двух базовых принципов используются следующие: принцип "разделяй и властвуй" и принцип иерархического упорядочивания. Первый является принципом решения трудных проблем путем разбиения их на множество меньших независимых задач, легких для понимания и решения. Второй принцип в дополнение к тому, что легче понимать проблему если она разбита на части, декларирует, что устройство этих частей также существенно для понимания. Понимание проблемы резко облегчается при организации ее частей в древовидные иерархические структуры, т.е. система может быть понята и построена по уровням, каждый из которых добавляет новые детали.
Выделение двух базовых принципов инженерии программного обеспечения вовсе не означает, что остальные принципы являются второстепенными, игнорирование любого из них может привести к непредсказуемым последствиям (в том числе и к неуспеху всего проекта). Отметим основные из таких принципов.
1. Принцип абстрагирования - заключается в выделении существенных с некоторых позиций аспектов системы и отвлечение от несущественных с целью представления проблемы в простом общем виде.
2. Принцип формализации - заключается в необходимости строгого методического подхода к решению проблемы.
3. Принцип упрятывания - заключается в упрятывании несущественной на конкретном этапе информации: каждая часть "знает" только необходимую ей информацию.
4. Принцип концептуальной общности - заключается в следовании единой философии на всех этапах ЖЦ (структурный анализ - структурное проектирование - структурное программирование - структурное тестирование).
5. Принцип полноты - заключается в контроле на присутствие лишних элементов.
6. Принцип непротиворечивости - заключается в обоснованности и согласованности элементов.
7. Принцип логической независимости - заключается в концентрации внимания на логическом проектировании для обеспечения независимости от физического проектирования.
8. Принцип независимости данных - заключается в том, что модели данных должны быть проанализированы и спроектированы независимо от процессов их логической обработки, а также от их физической структуры и распределения.
9. Принцип структурирования данных - заключается в том, что данные должны быть структурированы и иерархически организованы.
10. Принцип доступа конечного пользователя - заключается в том, что пользователь должен иметь средства доступа к базе данных, которые он может использовать непосредственно (без программирования).
Соблюдение указанных принципов необходимо при организации работ на начальных этапах ЖЦ независимо от типа разрабатываемого ПО и используемых при этом методологий. Руководствуясь всеми принципами в комплексе, можно понять на более ранних стадиях разработки, что будет представлять из себя создаваемая система, обнаружить промахи и недоработки, что, в свою очередь, облегчит работы на последующих этапах ЖЦ и понизит стоимость разработки.
1.3 Средства структурного анализа
Прежде чем подробно рассмотреть каждое из основных инструментальных средств структурного анализа, необходимо обсудить их в общем виде и продемонстрировать их взаимосвязи.
Для целей моделирования систем вообще, и структурного анализа в частности, используются три группы средств, иллюстрирующих:
· функции, которые система должна выполнять;
· отношения между данными;
· зависящее от времени поведение системы (аспекты реального времени).
Среди всего многообразия средств решения данных задач в методологиях структурного анализа наиболее часто и эффективно применяемыми являются следующие:
· SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы;
· DFD (Data Flow Diagrams) диаграммы потоков данных;
· ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь".
На стадии проектирования ИС модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм.
Перечисленные модели в совокупности дают полное описание ИС независимо от того, является ли она существующей или вновь разрабатываемой. Состав диаграмм в каждом конкретном случае зависит от необходимой полноты описания системы.
2 SADT - технология структурного анализа и проектирования
SADT (Structured Analysis and Design Technique) - одна из самых известных методологий анализа и проектирования систем, введенная в 1973 г. Россом (Ross). SADT успешно использовалась в военных, промышленных и коммерческих организациях для решения широкого спектра задач, таких как программное обеспечение телефонных сетей, системная поддержка и диагностика, долгосрочное и стратегическое планирование, автоматизированное производство и проектирование, конфигурация компьютерных систем, обучение персонала, встроенное ПО для оборонных систем, управление финансами и материально-техническим снабжением и др. Данная методология широко поддерживается Министерством обороны США, которое было инициатором разработки стандарта IDEF0 как подмножества SADT. Это, наряду с растущей автоматизированной поддержкой, сделало ее более доступной и простой в употреблении.
С точки зрения SADT модель может основываться либо на функциях системы, либо на ее предметах (планах, данных, оборудовании, информации и т.д.). Соответствующие модели принято называть активностными моделями и моделями данных. Активностная модель представляет с нужной степенью подробности систему активностей, которые в свою очередь отражают свои взаимоотношения через предметы системы. Модели данных дуальны к активностным моделям и представляют собой подробное описание предметов системы, связанных системными активностями. Полная методология SADT заключается в построении моделей обеих типов для более точного описания сложной системы. Однако, в настоящее время широкое применение нашли только активностные модели, их рассмотрению и посвящен данный раздел.
Основным рабочим элементом при моделировании является диаграмма. Модель SADT объединяет и организует диаграммы в иерархические древовидные структуры, при этом этом чем выше уровень диаграммы, тем она менее детализирована. В состав диаграммы входят блоки, изображающие активности моделируемой системы, и дуги, связывающие блоки вместе и изображающие взаимодействия и взаимосвязи между блоками. SADT тpебует, чтобы в диаграмме было 3-6 блоков: в этих пределах диаграммы и модели удобны для чтения, понимания и использования. Вместо одной громоздкой модели используются несколько небольших взаимосвязанных моделей, значения которых взаимодополняют друг друга, делая понятной структуризацию сложного объекта. Однако такое жесткое требование на число блоков на диаграмме ограничивает применение SADT для ряда предметных областей. Например, в банковских структурах имеется 15-20 равноправных деятельностей, которые целесообразно отразить на одной диаграмме. Искусственное их растаскивание по разным уровням SADT-модели явно не улучшает ее понимаемость.
Блоки на диаграммах изображаются прямоугольниками и сопровождаются текстами на естественном языке, описывающими активности. В отличие от других методов структурного анализа в SADT каждая сторона блока имеет вполне определенное особое назначение: левая сторона блока предназначена для Входов
, верхняя - для Управления
, правая - для Выходов
, нижняя - для Исполнителей
. Такое обозначение отражает определенные принципы активности: Входы
преобразуются в Выходы
, Управления
ограничивают или предписывают условия выполнения, Исполнители
описывают, за счет чего выполняются преобразования.
Дуги в SADT представляют наборы предметов и маркируются текстами на естественном языке. Предметы могут состоять с активностями в четырех возможных отношениях: Вход, Выход, Управление, Исполнитель
. Каждое из этих отношений изображается дугой, связанной с определенной стороной блока - таким образом, стороны блока чисто графически сортируют предметы, изображаемые дугами. Входные дуги изображают предметы, используемые и преобразуемые активностями. Управляющие дуги обычно изображают информацию, управляющую действиями активностей. Выходные дуги изображают предметы, в которые преобразуются входы. Исполнительские дуги отражают (по крайней мере частично) реализацию активностей (рис. 1).
Блоки на диаграмме размещаются по "ступенчатой" схеме в соответствии с их доминированием, которое понимается как влияние, оказываемое одним блоком на другие. Кроме того, блоки должны быть пронумерованы, например, в соответствии с их доминированием. Номера блоков служат однозначными идентификаторами для активностей и автоматически организуют эти активности в иерархию модели.
Взаимовлияние блоков может выражаться либо в пересылке Выхода
к другой активности для дальнейшего преобразования, либо в выработке управляющей информации, предписывающей, что именно должна делать другая активность. Таким образом, диаграммы SADT являются предписывающими диаграммами, описывающими как преобразования между Входом
и Выходом
, так и предписывающие правила этих преобразований.
В SADT требуются только пять типов взаимосвязей между блоками для описания их отношений: Управление, Вход, Управленческая Обратная Связь, Входная Обратная Связь, Выход - Исполнитель.
Отношения Управления
и Входа
являются простейшими, поскольку они отражают интуитивно очевидные прямые воздействияы. Отношение Управления
возникает тогда, когда Выход
одного блока непосредственно влияет на блок с меньшим доминированием. Отношение Входа
возникает, когда Выход
одного блока становится Входом
для блока с меньшим доминированием. Обратные связи более сложны, поскольку они отражают итерацию или рекурсию - Выходы
из одной активности влияют на будущее выполнение других функций, что впоследствии влияет на исходную активность. Управленческая Обратная Связь
возникает, когда Выход
некоторого блока влияет на блок с большим доминированием, а отношение Входной Обратной Связи
имеет место, когда Выход
одного блока становится Входом
другого блока с большим доминированием. Отношения Выход - Исполнитель
встречаются нечасто и представляют особый интерес. Они отражают ситуацию, при которой Выход
одной активности становится средством достижения цели другой активностью (рис. 2).
При создании модели одна и та же диаграмма чертится несколько раз, что создает различные ее варианты. Чтобы различать различные версии одной и той же диаграммы, в SADT используется схема контроля конфигурации диаграмм, основанная на их номерах. Если диаграмма замещает более старый вариант, то предыдущий номер помещается в скобках для указания связи с предыдущей работой.
SADT, как и другие методологии проектирования, целесообразно использовать на ранних этапах ЖЦ: для понимания системы до ее воплощения. SADT позволяет сократить дорогостоящие ошибки на ранних этапах создания системы, улучшить контакт между пользователями и разработчиками, сгладить переход от анализа к проектированию. Несомненное достоинство SADT заключается в том, что она легко отражает такие характеристики как управление, обратная связь и исполнители.
3 Диаграммы потоков данных
Диаграммы потоков данных (DFD) являются основным средством моделирования функциональных требований проектируемой системы. С их помощью эти требования разбиваются на функциональные компоненты (процессы) и представляются в виде сети, связанной потоками данных. Главная цель таких средств - продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.
Диаграммы потоков данных известны очень давно. В фольклоре упоминается следующий пример использования DFD для реорганизации переполненного клерками офиса, относящийся к 20-м годам. Осуществлявший реорганизацию консультант обозначил кружком каждого клерка, а стрелкой - каждый документ, передаваемый между ними. Используя такую диаграмму, он предложил схему реорганизации, в соответствии с которой двое клерков, обменивающиеся множеством документов, были посажены рядом, а клерки с малым взаимодействием были посажены на большом расстоянии. Так родилась первая модель, представляющая собой потоковую диаграмму - предвестника DFD.
Для изображения DFD традиционно используются две различные нотации: Йодана (Yourdon) и Гейна-Сарсона (Gane-Sarson). Далее при построении примеров будет использоваться нотация Йодана.
3.1 Основные символы
Основные символы DFD изображены на рис.3. Опишем их назначение. На диаграммах функциональные требования представляются с помощью процессов и хранилищ, связанных потоками данных.
ПОТОКИ ДАННЫХ
являются механизмами, использующимися для моделирования передачи информации (или даже физических компонент) из одной части системы в другую. Важность этого объекта очевидна: он дает название целому инструменту. Потоки на диаграммах обычно изображаются имено
Рис. 3. Основные символы диаграммы потоков данных
Иногда информация может двигаться в одном направлении, обрабатываться и возвращаться назад в ее источник. Такая ситуация может моделироваться либо двумя различными потоками, либо одним - двунаправленным.
Назначение ПРОЦЕССА
состоит в продуцировании выходных потоков из входных в соответствии с действием, задаваемым именем процесса. Это имя должно содержать глагол в неопределенной форме с последующим дополнением (например, ВЫЧИСЛИТЬ МАКСИМАЛЬНУЮ ВЫСОТУ
). Кроме того, каждый процесс должен иметь уникальный номер для ссылок на него внутри диаграммы. Этот номер может использоваться совместно с номером диаграммы для получения уникального индекса процесса во всей модели.
ХРАНИЛИЩЕ (НАКОПИТЕЛЬ) ДАННЫХ
позволяет на определенных участках определять данные, которые будут сохраняться в памяти между процессами. Фактически хранилище представляет "срезы" потоков данных во времени. Информация, которую оно содержит, может использоваться в любое время после ее определения, при этом данные могут выбираться в любом порядке. Имя хранилища должно идентифицировать его содержимое и быть существительным. В случае, когда поток данных входит или выходит в/из хранилища, и его структура соответствует структуре хранилища, он должен иметь то же самое имя, которое нет необходимости отражать на диаграмме.
ВНЕШНЯЯ СУЩНОСТЬ
(или ТЕРМИНАТОР
) представляет сущность вне контекста системы, являющуюся источником или приемником системных данных. Ее имя должно содержать существительное, например, СКЛАД ТОВАРОВ
. Предполагается, что объекты, представленные такими узлами, не должны участвовать ни в какой обработке.
3.2 Контекстная диаграмма и детализация процессов
Декомпозиция DFD осуществляется на основе процессов: каждый процесс может раскрываться с помощью DFD нижнего уровня.
Важную специфическую роль в модели играет специальный вид DFD - контекстная диаграмма, моделирующая систему наиболее общим образом. Контекстная диаграмма отражает интерфейс системы с внешним миром, а именно, информационные потоки между системой и внешними сущностями, с которыми она должна быть связана. Она идентифицирует эти внешние сущности, а также, как правило, единственный процесс, отражающий главную цель или природу системы насколько это возможно. И хотя контекстная диаграмма выглядит тривиальной, несомненная ее полезность заключается в том, что она устанавливает границы анализируемой системы. Каждый проект должен иметь ровно одну контекстную диаграмму, при этом нет необходимости в нумерации единственного ее процесса.
DFD первого уровня строится как декомпозиция процесса, который присутствует на контекстной диаграмме.
Построенная диаграмма первого уровня также имеет множество процессов, которые в свою очередь могут быть декомпозированы в DFD нижнего уровня. Таким образом строится иерархия DFD с контекстной диаграммой в корне дерева. Этот процесс декомпозиции продолжается до тех пор, пока процессы могут быть эффективно описаны с помощью коротких (до одной страницы) миниспецификаций обработки (спецификаций процессов).
При таком построении иерархии DFD каждый процесс более низкого уровня необходимо соотнести с процессом верхнего уровня. Обычно для этой цели используются структурированные номера процессов. Так, например, если мы детализируем процесс номер 2 на диаграмме первого уровня, раскрывая его с помощью DFD, содержащей три процесса, то их номера будут иметь следующий вид: 2.1, 2.2 и 2.3. При необходимости можно перейти на следующий уровень, т.е. для процесса 2.2 получим 2.2.1, 2.2.2. и т.д.
4 Диаграммы “сущность-связь”
Диаграммы "сущность-связь" (ERD) предназначены для разработки моделей данных и обеспечивают стандартный способ определения данных и отношений между ними. Фактически с помощью ERD осуществляется детализация хранилищ данных проектируемой системы, а также документируются сущности системы и способы их взаимодействия, включая идентификацию объектов, важных для предметной области (сущностей), свойств этих объектов (атрибутов) и их отношений с другими объектами (связей).
Данная нотация была введена Ченом (Chen) и получила дальнейшее развитие в работах Баркера (Barker). Нотация Чена предоставляет богатый набор средств моделирования данных, включая собственно ERD, а также диаграммы атрибутов и диаграммы декомпозиции. Эти диаграммные техники используются прежде всего для проектирования реляционных баз данных (хотя также могут с успехом применяться и для моделирования как иерархических, так и сетевых баз данных).
4.1 Сущности, отношения и связи в нотации Чена
СУЩНОСТЬ
представляет собой множество экземпляров реальных или абстрактных объектов (людей, событий, состояний, идей, предметов и т.п.), обладающих общими атрибутами или характеристиками. Любой объект системы может быть представлен только одной сущностью, которая должна быть уникально идентифицирована. При этом имя сущности должно отражать тип или класс объекта, а не его конкретный экземпляр (например, АЭРОПОРТ
, а не ВНУКОВО
).
ОТНОШЕНИЕ
в самом общем виде представляет собой связь между двумя и более сущностями. Именование отношения осуществляется с помощью грамматического оборота глагола (ИМЕЕТ
, ОПРЕДЕЛЯЕТ, МОЖЕТ ВЛАДЕТЬ
и т.п.).
Другими словами, сущности представляют собой базовые типы информации, хранимой в базе данных, а отношения показывают, как эти типы данных взаимоувязаны друг с другом. Введение подобных отношений преследует две основополагающие цели:
· обеспечение хранения информации в единственном месте (даже если она используется в различных комбинациях);
· использование этой информации различными приложениями.
Символы ERD, соответствующие сущностям и отношениям, приведены на рис. 4.
Рис.4. Символы ERD в нотации Чена
Независимая сущность представляет независимые данные, которые всегда присутствуют в системе. При этом отношения с другими сущностями могут как существовать, так и отсутствовать. В свою очередь зависимая сущность представляет данные, зависящие от других сущностей в системе. Поэтому она должна всегда иметь отношения с другими сущностями. Ассоциированная сущность представляет данные, которые ассоциируются с отношениями между двумя и более сущностями.
Неограниченное (обязательное) отношение представляет собой безусловное отношение, т.е. отношение, которое всегда существует до тех пор, пока существуют относящиеся к делу сущности. Ограниченное (необязательное) отношение представляет собой условное отношение между сущностями. Существенно-ограниченное отношение используется, когда соответствующие сущности взаимно-зависимы в системе.
Для идентификации требований, в соответствии с которыми сущности вовлекаются в отношения, используются СВЯЗИ
. Каждая связь соединяет сущность и отношение и может быть направлена только от отношения к сущности.
ЗНАЧЕНИЕ
связи характеризует ее тип и, как правило, выбирается из следующего множества:
{"O или 1", "0 или более", "1", "1 или более", "p:q" ( диапазон )}.
Пара значений связей, принадлежащих одному и тому же отношению, определяет тип этого отношения. Практика показала, что для большинства приложений достаточно использовать следующие типы отношений:
1. 1*1 (один-к-одному). Отношения данного типа используются, как правило, на верхних уровнях иерархии модели данных, а на нижних уровнях встречаются сравнительно редко.
2. 1*n (один-к-многим). Отношения данного типа являются наиболее часто используемыми.
3. n*m (многие-к-многим). Отношения данного типа обычно используются на ранних этапах проектирования с целью прояснения ситуации. В дальнейшем каждое из таких отношений должно быть преобразовано в комбинацию отношений типов 1 и 2 (возможно, с добавлением вспомогательных сущностей и с введением новых отношений).
4.2 Диаграммы атрибутов
Каждая сущность обладает одним или несколькими атрибутами, которые однозначно идентифицируют каждый экземпляр сущности. При этом любой атрибут может быть определен как ключевой.
Детализация сущности осуществляется с использованием диаграмм атрибутов, которые раскрывают ассоциированные с сущностью атрибуты. Диаграмма атрибутов состоит из детализируемой сущности, соответствующих атрибутов и доменов, описывающих области значений атрибутов. На диаграмме каждый атрибут представляется в виде связи между сущностью и соответствующим доменом, являющимся графическим представлением множества возможных значений атрибута. Все атрибутные связи имеют значения на своем окончании. Для идентификации ключевого атрибута используется подчеркивание имени атрибута.
Пример диаграммы атрибутов, детализирующей сущность КРЕДИТНАЯ КАРТА
приведен на рис. 5.
Рис. 5. Диаграмма атрибутов.
4.3 Нотация Баркера
Дальнейшее развитие ER-подход получил в работах Баркера, предложившего оригинальную нотацию, которая позволила на верхнем уровне интегрировать предложенные Ченом средства описания моделей.
В нотации Баркера используется только один тип диаграмм - ERD. Сущность на ERD представляется прямоугольником любого размера, содержащим внутри себя имя сущности, список имен атрибутов (возможно, неполный) и указатели ключевых атрибутов (знак "#" перед именем атрибута).
Все связи являются бинарными и представляются линиями с двумя концами (соединяющими сущности), для которых должно быть определено имя, степень множественности (один или много объектов участвуют в связи) и степень обязательности (т.е. обязательная или необязательная связь между сущностями). Для множественной связи линия присоединяется к прямоугольнику сущности в трех точках, а для одиночной связи - в одной точке. При обязательной связи рисуется непрерывная линия до середины связи, при необязательной - пунктирная линия. На рис. 6 приведен фрагмент ERD для банковской задачи в нотации Баркера.
Рис. 6. Нотация Баркера
Читается связь отдельно для каждого конца, показывая, как сущность КЛИЕНТ
связывается с сущностью КРЕДИТНАЯ КАРТА
, и наоборот. При этом необходимо учитывать степень обязательности выбранного конца связи, для этой цели используются слова "должен (быть)" или "может (быть)". Так, диаграмма, приведенная на рис. 5.6, читается следующим образом:
Каждый КЛИЕНТ может ВЛАДЕТЬ одной или более КРЕДИТНОЙ КАРТОЙ
или
Каждая КРЕДИТНАЯ КАРТА должна ПРИНАДЛЕЖАТЬ ровно одному КЛИЕНТУ.
В заключение отметим, что понятия категория и общая сущность заменяются Баркером на эквивалентные понятия подтипа и супертипа, соответственно.
5 Пример банковской задачи
В качестве примера создания модели рассмотрим фрагмент проекта системы, организующей работу банкомата по обслуживанию клиента по его кредитной карте. Этот пример будет строиться поэтапно, на нем будут продемонстрированы базовые техники структурного анализа и проектирования по мере их определения.
На рис. 7 приведена контекстная диаграмма системы с единственным процессом ОБСЛУЖИТЬ, идентифицирующая внешние сущности КЛИЕНТ и КОМПЬЮТЕР БАНКА, хранящий информацию о счетах всех клиентов. Опишем потоки данных, которыми обменивается проектируемая система с внешними объектами.
Рис. 7. Контекстная диаграмма банковской задачи
Для банковского обслуживания клиенту необходимо предоставить системе свою КРЕДИТНУЮ КАРТУ для автоматического считывания с нее информации (ПАРОЛЬ, ЛИМИТ ДЕНЕГ, ДЕТАЛИ КЛИЕНТА), а также сообщить свои КЛЮЧЕВЫЕ ДАННЫЕ, а именно ПАРОЛЬ и ЗАПРОС НА ОБСЛУЖИВАНИЕ, т.е. требуемую ему услугу (например, снятие со счета наличных денег). Банковское обслуживание с позиций клиента, в свою очередь, должно обеспечить следующее:
· выдать СООБЩЕНИЕ, приглашающее клиента ввести КЛЮЧЕВЫЕ ДАННЫЕ;
· выдать клиенту ДЕНЬГИ;
· выдать клиенту ВЫПИСКУ по проведенному обслуживанию, включающую ВЫПИСКУ О ДЕНЬГАХ, ВЫПИСКУ ПО БАЛАНСУ и ВЫПИСКУ ПО ОПЕРАЦИИ, проведенной банком.
Контекстный процесс и КОМПЬЮТЕР БАНКА должны обмениваться следующей информацией:
· ДАННЫЕ ПО СЧЕТУ клиента в банке;
· ПРОТОКОЛ ОБСЛУЖИВАНИЯ, включающей информацию об ОБРАБОТАННОЙ ДОКУМЕНТАЦИИ, изымаемой ДЕНЕЖНОЙ СУММЕ и ДАННЫЕ ПО ИСТОРИИ ЗАПРОСА.
Контекстный процесс может быть детализирован DFD первого уровня как показано на рис. 13. Эта диаграмма содержит 4 процесса и хранилище ДАННЫЕ КРЕДИТНОЙ КАРТЫ, которое изображено дважды на диаграмме с целью избежания пересечений линий потоков данных.
Процесс 1.1 (ПОЛУЧИТЬ ПАРОЛЬ) осуществляет прием и проверку пароля клиента и имеет на входе/выходе следующие потоки:
· внешний выходной поток СООБЩЕНИЕ для информирования клиента о своей готовности принять пароль;
· входной поток ВВЕДЕННЫЙ ПАРОЛЬ как элемент внешнего потока КЛЮЧЕВЫЕ ДАННЫЕ;
· входной поток ПАРОЛЬ из хранилища ДАННЫЕ КРЕДИТНОЙ КАРТЫ для проверки вводимого клиентом пароля.
Процесс 1.2 (ПОЛУЧИТЬ ЗАПРОС НА ОБСЛУЖИВАНИЕ) осуществляет прием и проверку запроса клиента на проведение необходимой ему банковской операции и имеет на входе/выходе следующие потоки:
· внешний выходной поток СООБЩЕНИЕ для информирования клиента о своей готовности принять запрос на обслуживание;
· входной поток ЗАПРОС НА ОБСЛУЖИВАНИЕ как элемент внешнего потока КЛЮЧЕВЫЕ ДАННЫЕ;
· входной поток ЛИМИТ ДЕНЕГ из хранилища ДАННЫЕ КРЕДИТНОЙ КАРТЫ для контроля наличия денег на счете клиента.
Рис. 8. Детализация процесса ОБСЛУЖИТЬ
Процесс 1.3 (ОБРАБОТАТЬ ЗАПРОС НА ОБСЛУЖИВАНИЕ) имеет внешний входной поток ДАННЫЕ ПО СЧЕТУ (из внешней сущности КОМПЬЮТЕР БАНКА), входной поток ДЕТАЛИ КЛИЕНТА (из хранилища), а также внешние выходные потоки ВЫПИСКА, ДЕНЬГИ и ПРОТОКОЛ ОБСЛУЖИВАНИЯ.
Процесс 1.4 (ОБРАБОТАТЬ КРЕДИТНУЮ КАРТУ) осуществляет считывание информации с кредитной карты и имеет на входе внешний поток КРЕДИТНАЯ КАРТА, а на выходе поток ДАННЫЕ КРЕДИТНОЙ КАРТЫ. Отметим, что нет необходимости в идентификации последнего потока, т.к. идентифицировано соответствующее хранилище.
Процессы 1.1, 1.2 и 1.4 являются элементарными, поэтому нет необходимости в их детализации с помощью DFD уровня 2. Процесс 1.3 может быть детализирован с помощью DFD второго уровня как показано на рис. 9. Эта диаграмма содержит 4 элементарных процесса.
Процесс 1.3.1 (ОБРАБОТАТЬ ДОКУМЕНТАЦИЮ БАНКА) осуществляет обработку внутренней банковской документации по клиенту и имеет входной поток ДЕТАЛИ КЛИЕНТА и выходной поток ОБРАБОТАННАЯ ДОКУМЕНТАЦИЯ (часть внешнего потока ПРОТОКОЛ СДЕЛКИ).
Процесс 1.3.2 (РАСПЕЧАТАТЬ БАЛАНС КЛИЕНТА) выдает справку по истории счета клиента и по балансу клиента. Входные потоки - ДЕТАЛИ КЛИЕНТА и ДАННЫЕ ПО БАЛАНСУ (часть внешнего потока ДАННЫЕ ПО СЧЕТУ), выходные потоки - ВЫПИСКА ПО БАЛАНСУ (часть внешнего потока ВЫПИСКА) и ДАННЫЕ ПО ИСТОРИИ ЗАПРОСА (часть внешнего потока ПРОТОКОЛ ОБСЛУЖИВАНИЯ).
Процесс 1.3.3 (ПРИГОТОВИТЬ ДЕНЬГИ КЛИЕНТУ) обеспечивает выдачу наличных денег и информирование компьютера банка об изъятых из банка деньгах. Он имеет входные потоки ДЕНЕЖНАЯ СУММА и ДЕТАЛИ КЛИЕНТА, и выходные потоки ДЕНЬГИ и ДЕНЕЖНАЯ СУММА (часть потока ПРОТОКОЛ ОБСЛУЖИВАНИЯ).
Рис. 9. Детализация процесса ОБРАБОТАТЬ ЗАПРОС НА ОБСЛУЖИВАНИЕ
Процесс 1.3.4 (РАСПЕЧАТАТЬ ОПЕРАЦИЮ КЛИЕНТА) выдает справку по истории счета и уведомление по проведенной операции. Входные потоки ДАННЫЕ ПО СЧЕТУ и ДЕТАЛИ КЛИЕНТА, выходные потоки - ВЫПИСКА ПО ОПЕРАЦИИ (часть потока ВЫПИСКА) и ДАННЫЕ ПО ИСТОРИИ ЗАПРОСА (часть потока ПРОТОКОЛ ОБСЛУЖИВАНИЯ).
На рис.10 приведена диаграмма "сущность-связь", демонстрирующая отношения между объектами банковской системы. Согласно этой диаграмме каждый БАНК ИМЕЕТ один или более БАНКОВСКИХ СЧЕТОВ. Кроме того, каждый КЛИЕНТ МОЖЕТ ВЛАДЕТЬ (одновременно) одной или более КРЕДИТНОЙ КАРТОЙ и одним или более БАНКОВСКИМ СЧЕТОМ, каждый из которых ОПРЕДЕЛЯЕТ в точности одну КРЕДИТНУЮ КАРТУ (отметим, что у клиента может и не быть ни счета, ни кредитной карты). Каждая КРЕДИТНАЯ КАРТА ИМЕЕТ ровно один зависимый от нее ПАРОЛЬ КАРТЫ, а каждый КЛИЕНТ ЗНАЕТ (но может и забыть) ПАРОЛЬ КАРТЫ.
Рис 10. ER-диаграмма в нотации Чена
Заключение
Сущность структурного подхода к разработке систем заключается в ее декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции и т.д.
Структурный подход к исследованию системы позволяет определить элементы системы, их внутренние связи, строение на каждом уровне детализации системы. Структурное описание системы выявляет взаимозависимость элементов, каждый из которых вне зависимости от уровня их структуризации рассматривается в качестве системы, состоящей из множества элементов. При структурном подходе, таким образом, основное внимание уделяется исследованию элементов структуры, где каждый элемент представляет собой систему, функции которой реализуются посредством взаимосвязей ее с другими элементами.
Структура играет огромную роль в системе: связывает компоненты, преобразует их, придавая некую общность, целостность, она обусловливает возникновение новых качеств, не присущих ни одному из них. Особенно большое значение для сохранения системы имеет относительная самостоятельность, устойчивость структуры. Наличие структуры - условие накопления количественных изменений внутри системы, являющихся необходимой предпосылкой для ее последующего развития, преобразования. Структуры, особенно иерархические, могут помочь в раскрытии неопределенности сложных систем. Иными словами, структурные представления систем являются полезным средством их исследования. Выделяют различные типы и виды структур. Если выделить элементы системы, относящиеся к выполнению определенной функции, в отдельную подсистему и определить связи между ними, то полученную структуру называют функциональной, т. е. структура, обусловленная функциональной деятельностью системы. Функциональная структура является основным типом структуры целенаправленных систем и непосредственно связана с целями системы.
Элементами функциональной структуры могут быть отдельные исполнители или их группы, выполняющие общую для них функцию независимо от того, принадлежат они одному подразделению или нет. Элементы (подсистемы) в функциональных структурах связаны при помощи функциональных связей, содержание которых определяется передачей материалов либо информации.
Результат же сознательной деятельности людей по обеспечению эффективного функционирования системы отражает организационная структура. В отличие от функциональной структуры, элементы организационной структуры выполняют не одну, а определенный комплекс функций, которая преследует задачу синтеза различных функций в системе. Функциональная структура, в которой реализуются функции управления, называется структурой управления.
Список литературы
1. Яворский В.В. Технология разработки программного обеспечения информационных систем: монография / В.В. Яворский, Н.И. Томилова // Караганда: КарГТУ, 2006. -228 с.
2. Яворский В.В., Томилова Н.И. Технология разработки программного обеспечения: Учебник // Астана: Фолиант, 2007. -376 с.
3. Калянов Г.Н. Консалтинг при автоматизации предприятий (подходы, методы, средства) // М.: СИНТЕГ, 1997, -316с.