Анализ возможностей организации 4 страница

· на DFD выбираются интерактивные процессы нижнего уровня. Интерактивные процессы нуждаются в пользовательском интерфейсе, поэтому можно определить экранную форму для каждого такого процесса;

· форма диаграммы изображается в виде прямоугольника для каждого интерактивного процесса на нижнем уровне диаграммы;

· определяется структура меню. Для этого интерактивные процессы группируются в меню (либо так же, как в модели процессов, либо другим способом — по функциональным признакам или в зависимости от принадлежности к определенным объектам);

· формы с меню изображаются над формами, соответствующими интерактивным процессам, и соединяются с ними переходами в виде стрелок, направленных от меню к формам;

· определяется верхняя форма (главная форма приложения), связывающая все формы с меню.

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

 

2.6

МОДЕЛИРОВАНИЕ ДАННЫХ

2.6.1

ОСНОВНЫЕ ПОНЯТИЯ

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

Наиболее распространенным средством моделирования данных являются диаграммы "сущность-связь" (ERD), нотация которых была впервые введена Питером Ченом в 1976 г. Базовыми понятиями ERD являются:

Сущность (Entity) — реальный либо воображаемый объект, имеющий существенное значение для рассматриваемой предметной

области.

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

· иметь уникальное имя; к одному и тому же имени должна всегда применяться одна и та же интерпретация; одна и та же интерпретация не может применяться к различным именам, если только они не являются псевдонимами;

· обладать одним или несколькими атрибутами, которые либо принадлежат сущности, либо наследуются через связь;

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

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

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

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

 

2.6.2

МЕТОД БАРКЕРА

Одной из наиболее распространенных разновидностей нотации ERD является нотация, предложенная Ричардом Баркером, автором методов, используемых в технологии создания ПО фирмы Oracle. Данная нотация используется в CASE-средстве Oracle Designer. Метод Баркера можно пояснить на примере моделирования данных компании по торговле автомобилями. Этот пример достаточно универсален, в качестве упражнения можно на основе его исходных данных построить ERD с использованием других нотаций. Исходными данными для построения ERD являются результаты интервью, проведенного с персоналом компании, выдержки из которого приведены ниже.

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

Продавец: ему нужно знать, какую цену запрашивать и какова нижняя цена, за которую можно совершить сделку. Кроме того, ему нужна основная информация о машинах: год выпуска, марка, модель и т.п.

Администратор: его задача сводится к составлению контрактов, для чего нужна информация о покупателе, автомашине и продавце, поскольку именно контракты приносят продавцам вознаграждения за продажи.

Первый шаг моделирования - извлечение информации из интервью и выделение сущностей (рис. 2.18).

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

Рис. 2.18.Графическое изображение сущности

 

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

Рис. 2.19.Диаграмма сущностей

 

Второй шаг моделирования - идентификация связей.

Определение связи в методе Баркера несколько отличается от данного Ченом. Связь - это ассоциация между сущностями, при которой, как правило, каждый экземпляр одной сущности, называемой родительской сущностью, ассоциирован с произвольным (в том числе нулевым) количеством экземпляров второй сущности, называемой сущностью-потомком, а каждый экземпляр сущности-потомка ассоциирован в точности с одним экземпляром сущности-родителя. Таким образом, экземпляр сущности-потомка может существовать только при существовании сущности-родителя.

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

Например, связь продавца с контрактом может быть выражена следующим образом:

· продавец может получить вознаграждение за один контракт или более;

· контракт должен быть инициирован ровно одним продавцом. Степень и обязательность связи можно показать графически (рис. 2.20).

return false">ссылка скрыта

 

Рис. 2.20.Степень и обязательность связи

 

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

Рис.2.21. Связь продавца с контрактом

 

Описав также связи остальных сущностей, получим схему, показанную на рис. 2.22.

Рис.2.22. Диаграмма «сущность-связь» без атрибутов

 

Третий шаг моделирования — идентификация атрибутов.

Атрибут может быть либо обязательным, либо необязательным (рис. 2.23).

Рис.2.23. Обязательный (помечен звездочкой) и необязательный (помечен кружком) атрибуты

 

Обязательность означает, что атрибут не может принимать неопределенных значений (null values). Атрибут может быть либо описательным (т. е. обычным дескриптором сущности), либо входить в состав уникального идентификатора (первичного ключа). Уникальный идентификатор — это атрибут или совокупность атрибутов и/или связей, предназначенная для уникальной идентификации каждого экземпляра данного типа сущности. В случае полной идентификации каждый экземпляр данного типа сущности полностью идентифицируется своими собственными ключевыми атрибутами, в противном случае в его идентификации участвуют также атрибуты другой сущности-родителя (рис. 2.24).

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

Рис.2.24. Виды идентификации: а - полная идентификация; б — идентификация посредством другой сущности

 

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

С учетом имеющейся информации дополним построенную ранее диаграмму (рис. 2.25).

Рис. 2.25. Диаграмма «сущность-связь» с атрибутами

 

Помимо перечисленных основных конструкций модель данных может содержать ряд дополнительных.

Супертипы и подтипы: одна сущность является обобщающим понятием для группы подобных сущностей (рис. 2.26).

Взаимно исключающие связи: каждый экземпляр сущности участвует только в одной связи из группы взаимно исключающих связей (рис. 2.27).

Рекурсивная связь: сущность может быть связана сама с собой (рис. 2.28).

 

Рис. 2.26. Супертипы и подтипы

 

Рис. 2.27. Взаимно исключающие связи

 

 

Рис. 2.28. Рекурсивная связь

 

Неперемещаемые (non-transferrable) связи: экземпляр сущности не может быть перенесен из одного экземпляра связи в другой (рис. 2.29).

 

Рис. 2.29.Неперемещаемая связь

 

2.6.3. МЕТОД IDEF1

Метод IDEF1 также основан на подходе Чена и позволяет построить модель данных, эквивалентную реляционной модели в третьей нормальной форме. В настоящее время на основе совершенствования метода IDEF1 создана его новая версия - метод IDEF1X, разработанный с учетом таких требований, как простота для изучения и возможность автоматизации. IDEFlX-диаграммы используются в ряде распространенных CASE-средств (в частности, ERwin, Design/IDEF).

Сущность в методе IDEF1X является не зависимой от идентификаторов или просто независимой, если каждый экземпляр сущности может быть однозначно идентифицирован без определения его отношений с другими сущностями. Сущность называется зависимой от идентификаторов или просто зависимой, если однозначная идентификация экземпляра сущности зависит от его отношения к другой сущности (рис. 2.30).

 

Рис. 2.30.Независимые (а) и зависимые (б) от идентификатора сущности

 

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

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

· каждый экземпляр сущности-родителя может иметь ноль, один или более одного связанного с ним экземпляра сущности-потомка;

· каждый экземпляр сущности-родителя должен иметь не менее одного связанного с ним экземпляра сущности-потомка;

· каждый экземпляр сущности-родителя должен иметь не более одного связанного с ним экземпляра сущности-потомка;

· каждый экземпляр сущности-родителя связан с некоторым фиксированным числом экземпляров сущности-потомка.

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

Связь изображается линией, проводимой между сущностью-родителем и сущностью-потомком, с точкой на конце линии у сущности-потомка (рис. 2.31). Мощность связи может принимать следующие значения: N — ноль, один или более, Z — ноль или один, Р - один или более. По умолчанию мощность связи принимается равной N.

 

Рис. 2.31.Графическое изображение мощности связи

 

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

 

Рис.2.32. Идентифицирующая связь

 

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

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

 

Рис.2.33. Неидентифицирующая связь

Сущности могут иметь также внешние ключи (Foreign Key), которые могут использоваться в качестве части или целого первичного ключа или неключевого атрибута. Внешний ключ изображается с помощью помещения внутрь блока сущности имен атрибутов, после которых следуют буквы FK. в скобках (см. рис. 2.32 и 2.33).

 

2.6.4

ПОДХОД, ИСПОЛЬЗУЕМЫЙ В CASE-СРЕДСТВЕ SILVERRUN

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

Рис. 2.34. Обозначение сущностей и связей

В данном примере пара (0,N) означает:

· физическое лицо может не иметь банковского счета (необязательная связь) либо иметь много счетов (степень связи - N);

· каждый банковский счет может принадлежать одному (обязательная связь) и только одному физическому лицу (степень связи — 1).

При описании атрибутов в верхней части прямоугольника располагается имя сущности, а в нижней части — список атрибутов, описывающих сущность. Обычно идентификаторы появляются в начале списка атрибутов. Пример графического представления сущности Юридическое лицо приведен на рис. 2.35.

Рис. 2.35. Графическое представление сущности

 

Существуют следующие виды идентификаторов:

• первичный/альтернативный: сущность может иметь несколько идентификаторов. Один должен являться основным (первичным), а другие — альтернативными. Первичный идентификатор на диаграмме подчеркивается. Альтернативные идентификаторы предваряются символами <1 > для первого альтернативного идентификатора, <2> для второго и т. д. В концептуальном моделировании данных различие первичных и альтернативных идентификаторов обычно не используется. В реляционной модели, полученной из концептуальной модели данных, первичные ключи используются в качестве внешних ключей. Альтернативные идентификаторы не копируются в качестве внешних ключей в другие таблицы;

· простой/составной (рис. 2.36): идентификатор, состоящий из одного атрибута, является простым, из нескольких атрибутов — составным;

Рис. 2.36.Составной идентификатор

 

· абсолютный/относительный: если все атрибуты, составляющие идентификатор, принадлежат сущности, то идентификатор является абсолютным. Если один или более атрибутов идентификатора принадлежат другой сущности, то идентификатор является относительным. Когда первичный идентификатор является относительным, сущность определяется как зависимая сущность, поскольку ее идентификатор зависит от другой сущности. В примере на рис. 2.37 идентификатор сущности Строка-заказа является относительным. Он включает идентификатор сущности Заказ, что показано на рисунке подчеркиванием 1.1.

Рис. 2.37. Относительный идентификатор

 

Как и сущности, связи могут иметь атрибуты. Пример на рис. 2.38 показывает атрибуты связи. В этом примере для того, чтобы найти оценку студента, нужно знать не только идентификатор студента, но и номер курса. Оценка не является атрибутом студента или атрибутом курса; она является атрибутом обеих этих сущностей. Это атрибут связи между студентом и курсом, которая в примере называется Регистрация.

 

Рис. 2.38. Связь с атрибутами

 

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

В связи "супертип-подтип" (рис. 2.39) общие атрибуты типа определяются в сущности-супертипе, сущность-подтип наследует все атрибуты супертипа. Экземпляр подтипа существует только при условии существования определенного экземпляра супертипа. Подтип не может иметь идентификатора (он импортирует его из супертипа).

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

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

Рис. 2.39.Связь «супертип-подтип»

 

2.7.

ПРИМЕР ИСПОЛЬЗОВАНИЯ СТРУКТУРНОГО ПОДХОДА

2.7.1.

ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ (ОРГАНИЗАЦИИ)

В качестве предметной области рассматривается работа одного из подразделений государственной налоговой инспекции (ГНИ), а именно подразделения учета налогоплательщиков-организаций

(юридических лиц). Модели строятся с использованием нотации CASE-средства Silverrun.

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

· первичную постановку на налоговый учет (налогоплательщик первый раз становится на учет);

· повторную постановку на налоговый учет (налогоплательщик уже имеет ИНН (идентификационный номер налогоплательщика));

· снятие с налогового учета (без ликвидации юридического лица);

· снятие с налогового учета (при ликвидации юридического лица);

· ведение Государственного реестра (Госреестра) налогоплательщиков;

· учет сведений об открытии и закрытии банковских счетов налогоплательщика;

· сверку данных по расчетным счетам налогоплательщиков с коммерческими банками;

· прием заявлений налогоплательщиков об изменении учетной политики, организации учета и отчетности.

Налогоплательщик-организация в соответствии с пунктом 1 статьи 83 Налогового кодекса подлежит постановке на учет в налоговом органе:

· по месту нахождения организации;

· по месту нахождения филиалов и представительств организации;

· по месту нахождения принадлежащего организации недвижимого имущества и транспортных средств, подлежащих налогообложению.

Учет и регистрация выполняются налоговым инспектором ГНИ. Налогоплательщик должен представить следующие документы:

· заявление о постановке на учет;

· устав организации;

· письмо с кодами статистики из Госкомстата;

· свидетельство о государственной регистрации юридического лица, полученное в Государственной регистрационной палате;

· протокол собрания учредителей.

Заявление регистрируется в журнале движения документов. Формы и документы проверяются на соответствие законодательству, полноту заполнения и точность представленной информации. Если документы в порядке, налогоплательщику присваиваются ИНН (десятизначный цифровой код) и код причины постановки на учет (КПП), которые записываются в свидетельство о регистрации и в журнал регистрации предприятий. КПП представляет собой девятизначный цифровой код, состоящий из кода ГНИ (4 знака), кода причины постановки на учет (2 знака) и порядкового номера постановки на учет по соответствующей причине (3 знака). Данные из заявления о постановке на учет вводятся в базу данных ГНИ с последующим занесением в Госреестр. Вводимые данные проверяются на правильность по соответствующим справочникам. Свидетельство о регистрации представляется руководителю налоговой инспекции на подпись и печать. После выполнения всех формальных процедур налогоплательщику выдается свидетельство о постановке на учет в налоговом органе, предъявив которое он может открыть расчетный счет в каком-либо банке. Об открытии счета банк и налогоплательщик должны известить налоговую инспекцию по специальной форме. После того как информация о расчетном счете введена в базу данных налоговой инспекции, налогоплательщик может платить налоги.

По каждому налогоплательщику в БД должны храниться следующие данные реестра:

· ИНН;

· КПП;

· наименование плательщика;

· юридический адрес;

· фактический адрес;

· номер расчетного счета и атрибуты банка, его обслуживающего;

· полные атрибуты учредителей плательщика (как юридических, так и физических лиц);

· дата регистрации;

· размер уставного фонда;

· данные о директоре и бухгалтере;

· код ФС (формы собственности);

· код ОПФ (организационно-правовой формы);

· код ОКПО (общероссийский классификатор предприятий и организаций);

· код ОКОНХ (общероссийский классификатор отрасли народного хозяйства);

· вид деятельности;

· место регистрации;

· регистрационный номер;

· сведения о подразделениях (филиалах, дочерних предприятиях и др.);

· иностранные инвестиции;

· информация о всех счетах предприятия (валютные, текущие, субсчета и др.).

Получаемая в результате БД является основой для последующих камеральных проверок и ведения лицевых карточек предприятий.

 

2.7.2.

ПОСТРОЕНИЕ МОДЕЛЕЙ ДЕЯТЕЛЬНОСТИ ОРГАНИЗАЦИИ

На стадии формирования требований к ПО строятся начальная контекстная DFD, контекстные диаграммы, определяется состав потоков данных и конструируется концептуальная модель данных в виде ERD.

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

Начальная контекстная диаграмма в нотации Гейна-Сэрсона изображена на рис. 2.40.

Рис. 2.40.Начальная контекстная диаграмма

 

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

Концептуальная модель данных в виде ERD (рис. 2.42) строится исходя из следующих соображений:

· сущности могут быть распознаны как структуры данных в DFD. Чтобы рассматривать объект в качестве сущности, он должен обладать более чем одним атрибутом;

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

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

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

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

· модель системных процессов;

· архитектура ЭИС;

· модели данных приложений;

· модель пользовательского интерфейса.

На стадии реализации выполняются генерация SQL-предложений, определяющих структуру целевой БД (таблицы, индексы, ограничения целостности), и генерация кода приложений.

Рис. 2.41.Полная контекстная диаграмма

Рис. 2.42. Диаграмма "сущность-связь" (БИК - банковский идентификационный код)

 

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