Количественный и качественный анализ результатов эмпирического исследования в психологии. Количественный анализ диаграмм Количественный анализ модели характеризующей
IDEFO И DFD
Для проведения количественного анализа диаграмм IDEF0 и DFD используются следующие показатели:
· количество блоков на диаграмме - N ;
· уровень декомпозиции диаграммы - L ;
· число стрелок, соединяющихся с i-м блоком диаграммы - Аi. Данный набор показателей относится к каждой диаграмме модели. Ниже перечислены рекомендации по их желательным значениям.
Необходимо стремиться к тому, чтобы количество блоков на диаграммах нижних уровней было бы ниже количества блоков на родительских диаграммах,
т. е. с увеличением уровня декомпозиции убывал бы коэффициент N/L . По мере декомпозиции модели функции должны упрощаться, следовательно, количество блоков должно убывать.
Диаграммы должны быть сбалансированы. Это означает, например, что у любого блока количество входящих стрелок и стрелок управления не должно быть значительно больше, чем количество выходящих. Следует отметить, что данная рекомендация может не выполняться в моделях, описывающих производственные процессы. Например, при описании процедуры сборки в блок может входить множество стрелок, описывающих компоненты изделия, а выходить одна стрелка - готовое изделие.
Количественная оценка сбалансированности диаграммы может быть выполнена с помощью коэффициента сбалансированности:
Необходимо стремиться к тому, чтобы значение K b для диаграммы было минимальным.
СРАВНИТЕЛЬНЫЙ АНАЛИЗ SADT-МОДЕЛЕЙ
И ДИАГРАММ ПОТОКОВ ДАННЫХ
Сравнительный анализ данных методов структурного анализа проводится по следующим параметрам:
· адекватность средств решаемым задачам;
· согласованность с другими средствами структурного анализа;
· интеграция с другими процессами ЖЦ ПО (прежде всего с процессом проектирования).
Адекватность средств решаемым задачам. Модели SADT (IDEF0) традиционно используются для моделирования организационных систем (бизнес-процессов). С другой стороны, не существует никаких принципиальных ограничений на использовании DFD в качестве средства моделирования бизнес-процессов. Следует отметить, что метод SADT успешно работает только при описании хорошо специфицированных и стандартизованных бизнес-процессов в зарубежных корпорациях, поэтому он и принят в США в качестве типового. Например, в Министерстве обороны США десятки лет существуют четкие должностные инструкции и методики, которые жестко регламентируют деятельность, делают ее высокотехнологичной и ориентированной на бизнес-процесс. Достоинствами применения моделей SADT для описания бизнес-процессов являются:
· полнота описания бизнес-процесса (управление, информационные и материальные потоки, обратные связи);
· комплексная декомпозиция; возможность агрегирования и детализации потоков данных и управления (разделение и слияние стрелок);
· жесткие требования метода, обеспечивающие получение моделей стандартного вида;
· соответствие подхода к описанию процессов стандартам ISO 9000.
В большинстве российских организаций бизнес-процессы начали формироваться и развиваться сравнительно недавно, они слабо типизированы, поэтому разумнее ориентироваться на модели, основанные на потоковых диаграммах. Кроме того, на практике у большинства моделей SADT отмечается ряд недостатков, в частности:
· сложность восприятия (большое количество стрелок);
· большое количество уровней декомпозиции;
· трудность увязки нескольких процессов, представленных в различных моделях одной и той же организации.
Если же речь идет не о системах вообще, а о ПО ИС, то здесь DFD вне конкуренции. Практически любой класс систем успешно моделируется при помощи DFD-ориентированных методов. SADT-диаграммы оказываются значительно менее выразительными и удобными при моделировании ПО. Так, дуги в SADT жестко типизированы (вход, выход, управление, механизм). В то же время применительно к ПО стирается смысловое различие между входами и выходами, с одной стороны, и управлениями и механизмами, с другой: входы, выходы и управления являются потоками данных и правилами их преобразования. Анализ системы при помощи потоков данных и процессов, их преобразующих, является более прозрачным и недвусмысленным.
В SADT вообще отсутствуют выразительные средства для моделирования особенностей ИС. DFD же с самого начала создавались как средство проектирования ИС (тогда как SADT - как средство моделирования систем вообще) и имеют более богатый набор элементов, адекватно отражающих специфику таких систем (например, хранилища данных являются прообразами файлов или баз данных, внешние сущности отражают взаимодействие моделируемой системы с внешним миром).
Наличие в DFD спецификаций процессов нижнего уровня позволяет преодолеть логическую незавершенность SADT (a именно, обрыв модели на некотором достаточно низком уровне, когда дальнейшая ее детализация становится бессмысленной) и построить полную функциональную спецификацию разрабатываемой системы.
Жесткие ограничения SADT, запрещающие использовать более 6-7 блоков на диаграмме, в ряде случаев вынуждают искусственно детализировать процесс, что затрудняет понимание модели заказчиком, резко увеличивает ее объем и, как следствие, ведет к неадекватности модели реальной предметной области. В качестве примера достаточно рассмотреть модель операции по снятию денег с вклада физического лица в банке. В настоящий момент существуют более тридцати типов таких вкладов. Для моделирования соответствующих операций целесообразно использовать единственную DFD, поскольку все без исключения операции имеют одни и те же входы (сберегательная книжка и расходный ордер) и выходы (сберегательная книжка и наличные деньги) и различаются лишь механизмами начисления процентов. Если же попытаться структурировать эти операции путем группирования по какому-либо признаку (срочные, пенсионные, размеры процентов и т.п.) в соответствии с ограничениями SADT, то получится как минимум 6 диаграмм (верхний уровень и округленная в большую сторону дробь 30/7), сложность каждой из которых не меньше сложности единственной диаграммы, моделирующей все операции.
Согласованность с другими средствами структурного анализа. Главным достоинством любых моделей является возможность их интеграции с моделями других типов. В данном случае речь идет о согласованности функциональных моделей со средствами моделирования данных. Согласование SADT-модели с ERM практически невозможно или носит искусственный характер. В свою очередь, DFD и ERM взаимно дополняют друг друга и являются согласованными, поскольку в DFD присутствует описание структур данных, непосредственно используемое для построения ERM.
Интеграция с другими процессами ЖЦ ПО. Важная характеристика модели - ее совместимость с моделями, используемыми в последующих процессах (прежде всего в процессе проектирования).
DFD могут быть легко преобразованы в модели проектируемой системы. Известен ряд алгоритмов автоматического преобразования иерархии DFD в структурные карты различных видов, что обеспечивает логичный и безболезненный переход от формирования требований к проектированию системы. С другой стороны, формальные методы преобразования SADT-диаграмм в проектные решения отсутствуют.
Необходимо отметить, что рассмотренные разновидности средств структурного анализа примерно одинаковы с учетом возможностей изобразительных средств моделирования. При этом одним из основных критериев выбора того или иного метода является степень владения им со стороны консультанта или аналитика, грамотность выражения своих мыслей на языке моделирования. В противном случае в моделях, построенных с использованием любого метода, будет невозможно разобраться.
МОДЕЛИРОВАНИЕ ДАННЫХ
Основные понятия модели «сущность - связь»
Цель моделирования данных состоит в обеспечении разработчика системы концептуальной схемой базы данных в форме одной модели или нескольких локальных моделей, которые относительно легко могут быть отображены в любую систему баз данных.
Наиболее распространенным средством моделирования данных (предметной области) является модель «сущность-связь» (ERM). Она была впервые введена Питером Ченом в 1976 г. Базовыми понятиями ERM являются сущность, связь и атрибут.
Сущность (Entity ) - реальный либо воображаемый объект, имеющий существенное значение для рассматриваемой предметной области.
Каждая сущность должна иметь наименование, выраженное существительным в единственном числе. Примерами сущностей могут быть такие классы объектов, как «Поставщик», «Сотрудник», «Заказ». Каждая сущность в модели изображается в виде прямоугольника с наименованием (рис. 2.23).
Рис. 2.23. Графическое представление сущности
Основной (неформальный) способ идентификации сущностей - это поиск абстракций, описывающих физические или материальные объекты, процессы и события, роли людей, организации и другие понятия. Единственным формальным способом идентификации сущностей является анализ текстовых описаний предметной области, выделение из описаний имен существительных и выбор их в качестве «кандидатов» на роль абстракций.
Экземпляр сущности - это конкретный представитель данной сущности. Например, экземпляром сущности «Сотрудник» может быть «Сотрудник Иванов».
Экземпляры сущностей должны быть различимы, т.е. сущности должны иметь некоторые свойства, уникальные для каждого экземпляра этой сущности. Каждый экземпляр сущности должен однозначно идентифицироваться и отличаться от всех других экземпляров данного типа сущности. Каждая сущность должна обладать некоторыми свойствами:
· иметь уникальное имя; к одному и тому же имени должна всегда применяться одна и та же интерпретация; одна и та же интерпретация не может применяться к различным именам, если только они не являются псевдонимами;
· обладать одним или несколькими атрибутами, которые либо принадлежат сущности, либо наследуются через связь;
· обладать одним или несколькими атрибутами, которые однозначно идентифицируют каждый экземпляр сущности.
Атрибут (Attribute) - любая характеристика сущности, значимая для рассматриваемой предметной области и предназначенная для квалификации, идентификации, классификации, количественной характеристики или выражения состояния сущности.
Атрибут представляет тип характеристик или свойств, ассоциированных с множеством реальных или абстрактных объектов (людей, мест, событий, состояний, идей, предметов и т.д.). Экземпляр атрибута - это определенная характеристика отдельного элемента множества. Экземпляр атрибута определяется типом характеристики и ее значением, называемым значением атрибута. В ERM атрибуты ассоциируются с конкретными сущностями. Таким образом, экземпляр сущности должен обладать единственным определенным значением для ассоциированного атрибута.
Наименование атрибута должно быть выражено существительным в единственном числе (возможно, с характеризующими прилагательными).
Примерами атрибутов сущности «Сотрудник» могут быть такие атрибуты, как «Табельный номер», «Фамилия», «Имя», «Отчество», «Должность», «Зарплата» и т.п.
Атрибуты изображаются в пределах прямоугольника, определяющего сущность (рис. 2.24).
Рис. 2.24. Сущность с атрибутами
Виды атрибутов :
· простой - состоит из одного элемента данных;
· составной - состоит из нескольких элементов данных;
· однозначный - содержит одно значение для одной сущности;
· многозначный - содержит несколько значений для одной сущности;
· необязательный - может иметь пустое (неопределенное) значение;
· производный - представляет значение, производное от значения связанного с ним атрибута.
Уникальным идентификатором называется неизбыточный набор атрибутов, значения которых в совокупности являются уникальными для каждого экземпляра сущности. Неизбыточность заключается в том, что удаление любого атрибута из уникального идентификатора нарушает его уникальность.
Сущность может иметь несколько различных уникальных идентификаторов, они изображаются на диаграмме подчеркиванием (рис. 2.25).
Рис. 2.25. Сущность с уникальным идентификатором
Каждая сущность может обладать любым количеством связей с другими сущностями модели. Связь (Relationship) - поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области. Связь - это ассоциация между сущностями, при которой каждый экземпляр одной сущности ассоциирован с произвольным (в том числе нулевым) количеством экземпляров второй сущности, и наоборот.
Степенью связи называется количество сущностей, участвующих в связи. Связь степени 2 называется бинарной , степени N- N-арной . Связь, в которой одна и та же сущность участвует в разных ролях, называется рекурсивной , или унарной . Один из возможных вариантов графического изображения связи показан на рис. 2.26.
Рис. 2.26. Обозначение сущностей и связи
Пары чисел на диаграмме отражают две важные характеристики связи - мощность связи (второе число) и класс принадлежности (первое число).
Мощностью связи называется максимальное число экземпляров сущности, которое может быть связано с одним экземпляром данной сущности. Мощность связи может быть равна 1, N (любое число) и может быть конкретным числом. Мощности связи на рис. 2.26 означают: каждый сотрудник может работать не более чем в одном отделе, а в каждом отделе может работать любое число сотрудников.
Класс принадлежности характеризует обязательность участия экземпляра сущности в связи. Класс принадлежности может принимать значение 0 (необязательное участие - экземпляр одной сущности может быть связан с одним или несколькими экземплярами другой сущности, а может быть и не связан ни с одним экземпляром) или 1 (обязательное участие - экземпляр одной сущности должен быть связан не менее чем с одним экземпляром другой сущности). Классы принадлежности на рис. 2.26 означают: каждый сотрудник обязательно работает в каком-либо отделе, а в некоторых отделах может и не быть сотрудников.
Связь может иметь один из следующих трех типов (в зависимости от значения мощности):
1. Один-к-одному (обозначается 1:1), показана на рис. 2.27.
Рис. 2.27. Связь типа 1:1
2. Один-ко-многим (обозначается 1:п), показана на рис. 2.26.
3. Многие-ко-многим (обозначается m:n), показана на рис. 2.28.
Рис. 2.28. Связь типа min
Виды идентификаторов
Существуют следующие виды идентификаторов:
· первичный/альтернативный: сущность может иметь несколько идентификаторов (рис. 2.29). Один должен являться основным (первичным), а другие - альтернативными. Первичный идентификатор на диаграмме подчеркивается. Альтернативные идентификаторы предваряются символами <1> для первого альтернативного идентификатора, <2> для второго и т.д. В концептуальном моделировании данных различие первичных и альтернативных идентификаторов обычно не используется. В реляционной модели, полученной из концептуальной модели данных, первичные ключи используются в качестве внешних ключей. Альтернативные идентификаторы не копируются в качестве внешних ключей в другие таблицы;
· простой/составной: идентификатор, состоящий из одного атрибута, является простым, из нескольких атрибутов - составным (см. рис. 2.29);
· абсолютный/относительный: если все атрибуты, составляющие идентификатор, принадлежат сущности, то идентификатор является абсолютным. Если один или более атрибутов идентификатора принадлежат другой сущности, то идентификатор является относительным. Когда первичный идентификатор является относительным, сущность определяется как зависимая сущность , поскольку ее идентификатор зависит от другой сущности. В примере на рис. 2.30 идентификатор сущности «Строка-заказа» является относительным. Он включает идентификатор сущности «Заказ», что показано на рисунке подчеркиванием 1.1.
Рис. 2.29. Составной альтернативный идентификатор
Рис. 2.30. Относительный идентификатор
Связи с атрибутами
Как и сущности, связи могут иметь атрибуты. В примере на рис. 2.31 для того, чтобы найти оценку студента, нужно знать не только идентификатор студента, но и номер курса. Оценка не является атрибутом студента или атрибутом курса; она является атрибутом обеих этих сущностей. Это атрибут связи между студентом и курсом, которая в примере называется «Регистрация».
Рис. 2.31. Связь с атрибутами
Связь между сущностями в концептуальной модели данных является типом, который представляет множество экземпляров связи между экземплярами сущностей. Для того чтобы идентифицировать определенный экземпляр сущности, используется идентификатор сущности. Точно так же для определения экземпляров связи между сущностями требуется идентификатор связи. Так, в примере на рис. 2.31 идентификатором связи «Регистрация» является идентификатор студента и номер курса, поскольку вместе они определяют конкретный экземпляр связи студентов и курсов.
Связи «супертип-подтип»
В связи «супертип-подтип» (рис. 2.32) общие атрибуты типа определяются в сущности-супертипе, сущность-подтип наследует все атрибуты супертипа. Экземпляр подтипа существует только при условии существования определенного экземпляра супертипа. Подтип не может иметь идентификатора (он импортирует его из супертипа).
Рис. 2.32. Связь «супертип-подтип»
Пример нотации модели «сущность-связь» - метод IDEF1X
Метод IDEF1X, входящий в семейство стандартов IDEF, использует разновидность модели «сущность-связь» и реализован в ряде распространенных CASE-средств (в частности, ERwin).
Сущность в методе IDEF1X является независимой от идентификаторов, или просто независимой, если каждый экземпляр сущности может быть однозначно идентифицирован без определения его отношений с другими сущностями. Сущность называется зависимой от идентификаторов, или просто зависимой , если однозначная идентификация экземпляра сущности зависит от его отношения к другой сущности (рис. 2.33).
Каждой сущности присваивается уникальное имя и номер, разделяемые косой чертой «/» и помещаемые над блоком.
Связь может дополнительно определяться с помощью указания мощности (количества экземпляров сущности-потомка, которое может существовать для каждого экземпляра сущности-родителя). В IDEF1X могут быть выражены следующие мощности связей:
Рис. 2.33. Независимые (а) и зависимые (б) от идентификатора сущности
· каждый экземпляр сущности-родителя может иметь нуль, один или более одного связанного с ним экземпляра сущности-потомка;
· каждый экземпляр сущности-родителя должен иметь не менее одного связанного с ним экземпляра сущности-потомка;
· каждый экземпляр сущности-родителя должен иметь не более одного связанного с ним экземпляра сущности-потомка;
· каждый экземпляр сущности-родителя связан с некоторым фиксированным числом экземпляров сущности-потомка.
Если экземпляр сущности-потомка однозначно определяется своей связью с сущностью-родителем, то связь называется идентифицирующей, в противном случае - неидентифицирующей.
Связь изображается линией, проводимой между сущностью-родителем и сущностью-потомком с точкой на конце линии у сущности-потомка (рис. 2.34).
Рис. 2.34. Графическое изображение мощности связи
Мощность связи может принимать следующие значения: N - нуль, один или более, Z - нуль или один, Р - один или более. По умолчанию мощность связи принимается равной N.
Идентифицирующая связь между сущностью-родителем и сущностью-потомком изображается сплошной линией (рис. 2.35). Сущность-потомок в идентифицирующей связи является зависимой от идентификатора сущностью. Сущность-родитель в идентифицирующей связи может быть как независимой, так и зависимой от идентификатора сущностью (это определяется ее связями с другими сущностями).
Рис. 2.35. Идентифицирующая связь
Пунктирная линия изображает неидентифицирующую связь (рис. 2.36).
Рис. 2.36. Неидентифицирующая связь
Сущность-потомок в неидентифицирующей связи будет независимой от идентификатора, если она не является также сущностью-потомком в какой-либо идентифицирующей связи.
Атрибуты изображаются в виде списка имен внутри блока сущности. Атрибуты, определяющие первичный ключ, размещаются наверху списка и отделяются от других атрибутов горизонтальной чертой.
Сущности могут иметь также внешние ключи (Foreign Key), которые могут использоваться в качестве части или целого первичного ключа или неключевого атрибута. Внешний ключ изображается с помощью помещения внутрь блока сущности имен атрибутов, после которых следуют буквы FK в скобках.
Похожая информация.
Для проведения количественного анализа диаграмм перечислим показатели модели:
Количество блоков на диаграмме – N ;
Уровень декомпозиции диаграммы – L ;
Сбалансированность диаграммы – В ;
Число стрелок, соединяющихся с блоком, – А .
Данный набор факторов относится к каждой диаграмме модели. Далее будут перечислены рекомендации по желательным значениям факторов диаграммы.
Необходимо стремиться к тому, чтобы количество блоков на диаграммах нижних уровней было бы ниже количества блоков на родительских диаграммах, т.е. с увеличением уровня декомпозиции убывал бы коэффициент . Таким образом, убывание этого коэффициента говорит о том, что по мере декомпозиции модели функции должны упрощаться, следовательно, количество блоков должно убывать.
Диаграммы дол лены быть сбалансированы. Это означает, что в рамках одной диаграммы не должно происходить ситуации, изображенной на рис. 14: у работы 1 входящих стрелок и стрелок управления значительно больше, чем выходящих. Следует отметить, что данная рекомендация может не выполняться в моделях, описывающих производственные процессы. Например, при описании процедуры сборки в блок может входить множество стрелок, описывающих компоненты изделия, а выходить одна стрелка – готовое изделие.
Рис. 14. Пример несбалансированной диаграммы
Введем коэффициент сбалансированности диаграммы:
.
Необходимо стремиться, чтобы К b , был минимален для диаграммы.
Помимо анализа графических элементов диаграммы необходимо рассматривать наименования блоков. Для оценки имен составляется словарь элементарных (тривиальных) функций моделируемой системы. Фактически в данный словарь должны попасть функции нижнего, уровня декомпозиции диаграмм. Например, для модели БД элементарными могут являться функции «найти запись», «добавить запись в БД», в то время как функция «регистрация пользователя» требует дальнейшего описания.
После формирования словаря и составления пакета диаграмм системы необходимо рассмотреть нижний уровень модели. Если на нем обнаружатся совпадения названий блоков диаграмм и слов из словаря, то это говорит, что достаточный уровень декомпозиции достигнут. Коэффициент, количественно отражающий данный критерий, можно записать как L*C – произведение уровня модели на число совпадений имен блоков со словами из словаря. Чем ниже уровень модели (больше L), тем ценнее совпадения.
Методология DFD
В основе методологии DFD лежит построение модели анализируемой АИС – проектируемой или реально существующей. Основным средством моделирования функциональных требований проектируемой системы являются диаграммы потоков данных (DFD). В соответствии с данной методологией модель системы определяется как иерархия диаграмм потоков данных. С их помощью требования разбиваются на функциональные компоненты (процессы) и представляются в виде сети, связанной потоками данных. Главная цель таких средств – продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.
Компонентами модели являются:
Диаграммы;
Словари данных;
Спецификации процессов.
DFD-диаграммы
Диаграммы потоков данных (DFD – Data Flow Diagrams) используются для описания документооборота и обработки информации. DFD представляет модельную систему как сеть связанных между собой работ, которые можно использовать для более наглядного отображения текущих операций документооборота в корпоративных системах обработки информации.
DFD описывает:
Функции обработки информации (работы, activities);
Документы (стрелки, arrows), объекты, сотрудников или отделы, которые участвуют в обработке информации;
Таблицы для хранения документов (хранилище данных, data store).
В BPwin для построения диаграмм потоков данных используется нотация Гейна-Сарсона (табл. 4).
Нотация Гейна – Сарсона
Таблица 4
На диаграммах функциональные требованияпредставляются с помощью процессов и хранилищ, связанных потоком данных.
Внешняя сущность – материальный предмет или физическое лицо, т.е. сущность вне контекста системы, являющуюся источником или приемником системных данных (например, заказчик, персонал, поставщики, клиенты, склад и др.). Ее имя должно содержать существительное. Предполагается, что объекты, представленные такими узлами, не должны участвовать ни в какой обработке.
Система и подсистема при построении модели сложной ИС она может быть представлена в самом общем виде на контекстной диаграмме в виде одной системы как единого целого, либо может быть декомпозирована на ряд подсистем. Номер подсистемы служит для ее идентификации. В поле имени вводится наименование системы в виде предложения с подлежащим и соответствующими определениями и дополнениями.
Процессы предназначены для продуцирования выходных потоков из входных в соответствии с действием, задаваемым именем процесса. Это имя должно содержать глагол в неопределенной форме с последующим дополнением (например, вычислить, проверить, создать, получить). Номер процесса служит для его идентификации, а также для ссылок на него внутри диаграммы. Этот номер может использоваться совместно с номером диаграммы для получения уникального индекса процесса во всей модели.
Потоки данных – механизмы, использующиеся для моделирования передачи информации из одной части системы в другую. Потоки на диаграммах изображаются именованными стрелками, ориентация которых указывает направление движения информации. Иногда информация может двигаться в одном направлении, обрабатываться и возвращаться назад в ее источник. Такая ситуация может моделироваться либо двумя различными потоками, либо одним - двунаправленным.
Для проведения количественного анализа диаграмм перечислим показатели модели:
количество блоков на диаграмме - N;
уровень декомпозиции диаграммы - L ;
сбалансированность диаграммы - В;
число стрелок, соединяющихся с блоком, - А.
Данный набор факторов относится к каждой диаграмме модели. Далее будут перечислены рекомендации по желательным значениям факторов диаграммы. Необходимо стремиться к тому, чтобы количество блоков на диаграммах нижних уровней было бы ниже количества блоков на родительских диаграммах, т. е. с увеличением уровня декомпозиции убывал бы коэффициент N/L. Таким образом, убывание этого коэффициента говорит о том, что по мере декомпозиции модели функции должны упрощаться, следовательно, количество блоков должно убывать. Диаграммы должны быть сбалансированы. Это означает, что в рамках одной диаграммы не должно происходить ситуации, изображенной на рис. 10: У работы 1 входящих стрелок и стрелок управления значительно больше, чем выходящих. Следует отметить, что данная рекомендация может не выполняться в моделях, описывающих производственные процессы. Например, при описании процедуры сборки в блок может входить множество стрелок, описывающих компоненты изделия, а выходить одна стрелка- готовое изделие. Введем коэффициент сбалансированности диаграммы Необходимо стремиться, чтобыКb был минимален для диаграммы. Помимо анализа графических элементов диаграммы необходимо рассматривать наименования блоков. Для оценки имен составляется словарь элементарных (тривиальных) функций моделируемой системы. Фактически в данный словарь должны попасть функции нижнего, уровня декомпозиции диаграмм. Например, для модели БД элементарными могут являться функции «найти запись», «добавить запись в БД», в то время как функция «регистрация пользователя» требует дальнейшего описания. После формирования словаря и составления пакета диаграмм системы необходимо рассмотреть нижний уровень модели. Если на нем обнаружатся совпадения названий блоков диаграмм и слов из словаря, то это говорит, что достаточный уровень декомпозиции достигнут. Коэффициент, количественно отражающий данный критерий, можно записать какL*C - произведение уровня модели на число совпадений имен блоков со словами из словаря. Чем ниже уровень модели (больше L), тем ценнее совпадения.
22. Моделирование данных. Архитектура ansi-sparc
В общем случае БД обладают свойством независимости от прикладных программ и, как правило, представляются тремя уровнями архитектуры: внешним, концептуальным и физическим; обращение к БД осуществляется с помощью СУБД.
Рассматриваемая нами архитектура почти полностью согласуется с архитектурой, предложенной исследовательской группой ANSI/SPARC (Study Group on Data Management Systems). В задачи группы входило определение того, нуждаются ли какие-либо области технологии БД в стандартизации (и если нуждаются, то какие именно) и выработка набора рекомендуемых действий в каждой из этих областей. В процессе работы над поставленными задачами группа пришла к выводу, что единственный подходящий объект стандартизации – интерфейсы, и в соответствии с этим определила общую архитектуру, или фундамент, СБД, а также указала на важную роль подобных интерфейсов. В окончательном отчете (1978 г.) представлено подробное описание архитектуры и некоторых из 42 указанных интерфейсов.
Архитектура делит СБД на три уровня. Восприятие данных на каждом из уровней описывается с помощью схемы. Рис. Три уровня архитектуры ANSI/SPARC
Внешний уровень – представление отдельного пользователя. Отдельного пользователя интересует лишь некоторая часть всей БД. Кроме того, представление пользователя об этой части будет, безусловно, более абстрактным по сравнению с выбранным способом хранения данных. Предоставляемый в распоряжение пользователя подъязык данных определяется в терминах внешних записей (например, выборка множества записей).каждое внешнее представление определяется внешней схемой, которая в основном состоит из определений записей каждого из типов, присутствующих в этом внешнем представлении.(например, тип внешней записи о сотруднике можно определить как 6-символьное поле с номером работника, как поле из пяти десятичных цифр, предназначенных для хранения данных о его зарплате и т.д.). Концептуальное представление – это представление всей информации БД в несколько более абстрактной форме (как и в случае внешнего представления) по сравнению с описанием физического способа хранения данных. Концептуальное представление определяется с помощью концептуальной схемы. Чтобы добиться независимости от данных, в нее не включаются какие-либо указания о структурах хранения или методах доступа, упорядоченности хранимых данных, индексировании и т.д. Определения концептуального языка должны относится только к содержанию информации. Если концептуальная схема действительно обеспечивает независимость от данных в этом смысле, то внешние схемы, определенные на основе концептуальной, заведомо будут обеспечивать независимость от данных. Концептуальное представление – это представление всего содержимого БД, а концептуальная схема – это определение такого представления. Определения в концептуальной схеме также могут характеризовать большое количество различных дополнительных аспектов обработки информации, например, ограничения защиты или требования поддержания целостности данных. Внутренний уровень – это низкоуровневое представление всей базы данных. Внутренняя запись - хранимая запись. Внутренне представление также отделено от физического уровня, так как в нем не рассматриваются физические записи (обычно называемые блоками или страницами). Внутреннее представление описывается с помощью внутренней схемы, которая определяет не только типы хранимых записей, но и существующие индексы, способы представления хранимых полей, физическую упорядоченность записей и т.д.
Кроме элементов самих трех уровней, рассматриваемая архитектура включает также определенные отображения: Отображение «концептуальный-внутренний» устанавливает соответствие между концептуальным представлением и хранимой БД, т.е. описывает, как концептуальные записи и поля представлены на внутреннем уровне. При изменении структуры хранимой БД данное отображение также изменяется, с учетом того, что концептуальная схема остается неизменной. Иначе говоря, чтобы обеспечивалась независимость от данных, результаты внесения любых изменений в схему хранения не должны обнаруживаться на концептуальном уровне. Это отображение служит основой физической независимости от данных, если пользователи и пользовательские программы обладают невосприимчивостью к изменениям в физической структуре хранимой базы данных. Отображение «внешний-концептуальный» определяет соответствие между некоторым внешним представлением и концептуальным представлением. Это отображение служит основой логической независимости от данных, т.е. пользователи и пользовательские программы обладают невосприимчивостью к изменениям в логической структуре БД (т.е. подразумеваются изменения на концептуальном уровне). (Например, несколько концептуальных полей могут быть объединены в одно внешнее (виртуальное)). Отображение «внешний-внешний» позволяет выражать одно определение внешнего представления через другое, не требуя обязательного явного определения отображения каждого внешнего представления на концептуальный уровень.
Для проведения количественного анализа диаграмм перечислим показатели модели:
· количество блоков на диаграмме – N;
· уровень декомпозиции диаграммы – L;
· сбалансированность диаграммы – В;
· число стрелок, соединяющихся с блоком, – А.
Данный набор факторов относится к каждой диаграмме модели. Далее будут перечислены рекомендации по желательным значениям факторов диаграммы.
Необходимо стремиться к тому, чтобы количество блоков на диаграммах нижних уровней было бы ниже количества блоков на родительских диаграммах, т. е. с увеличением уровня декомпозиции убывал бы коэффициент . Таким образом, убывание этого коэффициента говорит о том, что по мере декомпозиции модели функции должны упрощаться, следовательно, количество блоков должно убывать.
Диаграммы должны быть сбалансированы. Это означает, что в рамках одной диаграммы не должно происходить ситуации, когда у работы входящих стрелок и стрелок управления значительно больше, чем выходящих. Следует отметить, что данная рекомендация может не соблюдаться для производственных процессов, которые подразумевают получение готового продукта из большого количества составляющих (выпуск узла машины, выпуск продовольственного изделия и другие). Например, при описании процедуры сборки в блок может входить множество стрелок, описывающих компоненты изделия, а выходить одна стрелка – готовое изделие.
Введем коэффициент сбалансированности диаграммы:
Желательно, чтобы коэффициент сбалансированности был минимален для диаграммы, а в модели был постоянен.
Кроме оценки качества диаграмм в модели и в целом самой модели по коэффициентам сбалансированности и декомпозиции можно провести анализ и оптимизацию описанных бизнес–процессов. Физический смысл коэффициента сбалансированности определяется количеством стрелок, соединенных с блоком, и соответственно его можно интерпретировать как оценочный коэффициент по количеству обрабатываемых и получаемых конкретным подразделением или сотрудником документов и должностных функций. Таким образом, на графиках зависимости коэффициента сбалансированности от уровня декомпозиции существующие пики относительно среднего значения показывают перегруженность и недогруженность сотрудников на предприятии, так как различные уровни декомпозиции описывают деятельность различных подразделений или сотрудников предприятия. Соответственно, если на графиках реальных бизнес–процессов имеются пики, то аналитик может выдать ряд рекомендаций по оптимизации описанных бизнес–процессов: распределению выполняемых функций, обработке документов и информации, введению дополнительных коэффициентов при оплате труда сотрудников.
Проведем количественный анализ моделей, изображенных на рисунках 12 и 13, согласно вышеописанной методике. Рассмотрим поведение коэффициента у этих моделей. У родительской диаграммы «Обработка запроса клиента» коэффициент равен 4/2 = 2, а диаграммы декомпозиции 3/3 = 1. Значение коэффициента убывает, что говорит об упрощении описания функций с понижением уровня модели.
Рассмотрим изменение коэффициента К b у двух вариантов моделей.
Для первого варианта, изображенного на рисунке 20,
для второго варианта
Коэффициент К b не меняет своего значения, следовательно, сбалансированность диаграммы не меняется.
Будем считать, что уровень декомпозиции рассмотренных диаграмм достаточен для отражения цели моделирования, и на диаграммах нижнего уровня в качестве наименований работ используются элементарные функции (с точки зрения пользователя системы).
Подводя итоги рассмотренного примера необходимо отметить важность рассмотрения нескольких вариантов диаграмм при моделировании системы. Такие варианты могут возникать при корректировке диаграмм, как это было сделано с «Обработкой запроса клиента» или при создании альтернативных реализаций функций системы (декомпозиция работы «Изменение БД»). Рассмотрение вариантов позволяет выбрать наилучший и включить его в пакет диаграмм для дальнейшего рассмотрения.
Данный вид анализа строится на расчете ряда количественных показателей для построенной модели. Необходимо учитывать, что данные оценки во многом субъективны, так как оценивание ведется непосредственно по графическим моделям, а их сложность и уровень детализации определяются многими факторами.
Сложность . Данный показатель характеризует насколько иерархически сложна модель процесса. Численное значение определяется коэффициентом сложности k sl .
k sl = ? ur /? ekz
где? ur -- количество уровней декомпозиции,
Ekz -- количество экземпляров процесса.
Сложность рассматриваемой модели равна:
При k sl <= 0,25 процесс считается сложным. При k sl => 0,66 таковым не считается. Рассматриваемый процесс равен 0,25, что не превышает порог сложности.
Процессность . Данный показатель характеризует, можно ли построенную модель процесса считать сущностной (описывает структуру предметной области в виде набора ее основных объектов, понятий и связей), либо процессной (все экземпляры процессов модели связаны причинно-следственными связями). Другими словами, данный показатель отражает насколько построенная модель некоторой ситуации в компании соответствует определению процесса. Численное значение определяется коэффициентом процессности k pr
k pr = ? raz /? kep
где? raz -- количество «разрывов» (отсутствия причинно-следственных связей) между экземплярами бизнес-процессов,
Процессность равна
Контролируемость . Данный показатель характеризует, насколько эффективно собственники процесса управляют процессами. Численное значение определяется коэффициентом контролируемости k kon
k kon = ? s /? kep
Где? s -- количество собственников,
Kep -- количество экземпляров на одной диаграмме.
Контролируемость равна
При k kon = 1 процесс считается контролируемым.
Ресурсоемкость. Данный показатель характеризует эффективность использования ресурсов для рассматриваемого процесса. Численное значение определяется коэффициентом ресурсоемкости k r
k r = ? r /? out
где? r -- количество ресурсов, задействованных в процессе,
Out -- количество выходов.
Ресурсоемкость равна
Чем ниже значение коэффициента, тем выше значение эффективности использования ресурсов в бизнес-процессе.
При k r < 1 ресурсоемкость считается низкой.
Регулируемость . Данный показатель характеризует, насколько сильно регламентируется процесс. Численное значение определяется коэффициентом регулируемости k reg
где D -- количество имеющейся регламентной документации,
Kep -- количество экземпляров на одной диаграмме
Регулируемость равна
При k reg < 1 регулируемость считается низкой.
Параметры и значения количественных показателей представлены в табл. 7.
Табл. 7. Количественные показатели
Для общей оценки анализируемого процесса вычисляют сумму рассчитанных показателей
K = k sl + k pr + k kon + k r + k reg
Сумма показателей равна
K = 0,1875 + 0, 25 + 0,9375 + 0,273 + 0,937 = 2,585
Рассчитанное значение удовлетворяет условию К > 1. При K > 2,86 процесс считается заведомо неэффективным. При 1 < K < 2,86 процесс частично эффективен.
