Добавлен: 03.07.2023
Просмотров: 44
Скачиваний: 3
Назначение процесса (работы) состоит в продуцировании выходных потоков из входных в соответствии с действием, задаваемым именем процесса. Имя процесса должно содержать глагол в неопределенной форме с последующим дополнением (например, "получить документы по подписки"). Каждый процесс имеет уникальный номер для ссылок на него внутри диаграммы, который может использоваться совместно с номером диаграммы для получения уникального индекса процесса во всей модели.
Хранилище (накопитель) данных позволяет на указанных участках определять данные, которые будут сохраняться в памяти между процессами. Фактически хранилище представляет "срезы" потоков данных во времени. Информация, которую оно содержит, может использоваться в любое время после ее получения, при этом данные могут выбираться в любом порядке. Имя хранилища должно определять его содержимое и быть существительным.
Внешняя сущность представляет собой материальный объект вне контекста системы, являющейся источником или приемником системных данных. Ее имя должно содержать существительное, например, «номенклатура». Предполагается, что объекты, представленные как внешние сущности, не должны участвовать ни в какой обработке.
Кроме основных элементов диаграммы, в состав входят словари данных и миниспецификации.
Словари данных являются каталогами всех элементов данных, присутствующих в диаграмме, включая групповые и индивидуальные потоки данных, хранилища и процессы, а также все их атрибуты.
Все работы модели номеруются. Номер состоит из префикса и числа. Может быть использован префикс любой длины, но обычно используют префикс А. Контекстная (корневая) работа дерева имеет номер А0. Работы i декомпозиции А0 имеют номера А1, А2, A3 и т. д.. Работы декомпозиции нижнего уровня имеют номер родительской работы и очередной порядковый номер, например работы декомпозиции A3 будут иметь номера А31, А32, АЗЗ, А34 и т. д. Работы образуют иерархию, где каждая работа может иметь одну родительскую и несколько дочерних работ, образуя дерево. Такое дерево называют деревом узлов, а вышеописанную нумерацию – нумерацией по узлам. Диаграммы IDEF0 имеют двойную нумерацию. Во-первых, диаграммы имеют номера по узлу. Контекстная диаграмма всегда имеет номер А-0, декомпозиция контекстной диаграммы – номер А0, остальные диаграммы декомпозиции — номера по соответствующему узлу (например, A1, A2, А21, А213 и т. д.).
Диаграммы потоков данных (Data Flow Diagramming) являются основным средством моделирования функциональных требований к проектируемой системе. Требования представляются в виде иерархии процессов, связанных потоками данных. Диаграммы потоков данных показывают, как каждый процесс преобразует свои входные данные в выходные, и выявляют отношения между этими процессами. DFD-диаграммы успешно используются как дополнение к модели для описания документооборота и обработки информации. Представляемая моделируемая система является сетью связанных работ. Основные компоненты DFD (как было сказано выше) – процессы или работы, внешние сущности, потоки данных, накопители данных (хранилища).
Диаграмма является основной единицей описания. Важно правильно построить диаграммы, поскольку они предназначены для чтения другими людьми, а не только автором.
Требуемые информационные потоки данных являются механизмами, использующимися для моделирования передачи информации (или даже физических компонент) из одной части системы в другую и описывается в виде функциональных диаграмм. Важность этих диаграмм очевидна. Они отражают и наглядно показывают логику работы скрытых связей, как цельной структуры. Потоки на диаграммах, как правило, изображаются именованными стрелками, ориентация которых указывает направление движения информации и их иерархическую значимость для всех заинтересованных лиц.
Иногда информационный поток может двигаться в одном направлении, обрабатываться и возвращаться назад к своему источнику. Такая ситуация может моделироваться либо двумя различными потоками, либо одним – двунаправленным.
Модель ERD
ERD состоит из трех основных блоков: сущностей, атрибутов и связей. Если рассматривать диаграмму как некий графический язык, то можно заметить, что объекты являются существительными, атрибуты – прилагательными, а зависимости – глаголами этого языка. Построение модели данных в ERwin заключается в, как бы, нахождении правильного набора существительных, глаголов и прилагательных и в правильном их сочетание.
Основная задача ERD – оценить, какие требования к бизнес-информации будут достаточными для обеспечения нужд планирования разработки информационной системы. Эти модели не очень подробны (включены только основные сущности), атрибуты тоже слабо детализируются. Разрешены отношения многие ко многим, ключи, как правило, не включаются. Эта модель, в основном, предназначена для презентации и обсуждения.
ERD разделяются на предметные области, в которых более детально описываются различные бизнес-функции. Наличие предметных областей позволяет представлять большие модели в более компактной форме. В результате модель становится легко управляемой и редактируемой.
Существует несколько способов разработки ERD. Они варьируют от формальных сессий моделирования (описанных в предыдущей статье) до индивидуальных интервью с менеджерами, обладающими большой сферой ответственности.
В этой статье речь пойдет о методе моделирования данных, используемом ERwin, и о мощности и удобстве этого метода для описания информационных структур вашего бизнеса.
Диаграмма зависимостей сущностей (диаграмма “сущность-связь”)
Рисунок 3 – Пример диаграммы зависимостей сущностей
Если вы знакомы с реляционными базами данных, то вам, конечно, известно, что основным компонентом этих баз данных является таблица. Таблицы используются для управления и хранения информации. Таблицы, как известно, состоят из строк и столбцов.
В реляционной базе данных в каждой ячейке может храниться только один объект. В базе данных существует также взаимосвязь между таблицами. Каждая взаимосвязь представлена в RDBMS (РСУБД) за счет совместного использования одной или нескольких колонок двумя таблицами.
Так же, как таблицы и колонки образуют физическую модель реляционной базы данных, Диаграмма зависимостей сущностей (и другие логические модели) включают в себя компоненты, которые позволяют смоделировать структуры данных для вашего бизнеса. Логическим эквивалентом таблицы является сущность, а логическим эквивалентом колонки является атрибут.
Рисунок 4 – ERD с атрибутами
В ERD сущность представлен рамкой с именем этой сущности. Названия сущностей могут быть только в единственном числе – потребитель (а не потребители), фильм (а не фильмы), страна (а не страны). Если вы всегда будете использовать существительные в единственном числе, то можете получить единый стандарт для всех названий, и тем самым, сделать диаграмму более читаемой.
Взаимосвязи между таблицами являются жизненно важными компонентами реляционных баз данных.
Эти связи создаются за счет использования общих ключей, т. е. записи в одной таблице ссылаются на записи в другой таблице. В ERD взаимосвязи отображены в виде линии между сущностями, входящими в модель. Связь между двумя сущностями также включает то, что факты одной сущности ссылаются или ассоциированы с фактами другой сущности.
В диаграмме, показанной выше, для фильмотеки требуется механизм отслеживания информации о потребителях и прокатных копиях фильмов. Информация этих двух сущностей взаимосвязана, и эта связь может быть выражена так: Потребитель берет напрокат одну или более Прокатных копий фильма.
Сущности могут быть определены в виде какого-либо лица, места, предмета, события, о которых содержится соответствующая информация. Если говорить точнее, то сущность можно представлять как набор отдельных экземпляров (записей). Экземпляр – это конкретная реализация сущности. Каждый экземпляр должен быть отличен от остальных.
В предыдущем примере сущность Потребитель представляет собой всех существующих потребителей, т. е. все экземпляры этой сущности. Вы можете составить список экземпляров в виде таблицы 1, изображенной ниже.
В примере показанном выше, каждый экземпляр сущности Потребитель содержит следующую информацию: Id потребителя, имя потребителя, адрес потребителя. В логической модели эти свойства называются атрибутами сущности. Каждый атрибут содержит только часть информации о сущности.
Вы можете включить атрибуты в ERD для того, чтобы более полно описать объекты в модели.
Практическая реализация структурных методов проектирования ИС
В современных условиях важной областью стало информационное обеспечение, которое состоит в сборе и переработке информации, необходимой для принятия обоснованных управленческих решений. Передача информации на высший уровень управления и взаимный обмен информацией между всеми взаимными подразделениями организации осуществляются на базе современной электронно-вычислительной техники и других технических средствах связи.
В ФНС для повышения эффективности работы возникла необходимость внедрения информационной системы документооборота.
Проанализировав деятельность ФНС, можно выявить следующие недостатки:
- низкая оперативность;
- преобладание ручной обработки информации и в связи с этим ее большая трудоемкость;
- неэффективный обмен информацией внутри отдела;
- дублирование информации;
- сложность поиска актуальной версии документа.
Разработка ИС направлена в первую очередь на:
- снижение трудоемкости процесса;
- сокращение времени на всех стадиях процесса;
- улучшение качества обслуживания;
- снижение вероятности ошибок.
Функциональная модель существующего процесса документооборота при работе с налогоплательщиками представлена на рисунках 5–6.
Цель моделирования: выявить неавтоматизированные процессы для автоматизации и проектирования информационной системы.
Точка зрения: руководство.
Цель моделирования: выявить неавтоматизированные процессы для автоматизации и проектирования информационной системы.
Точка зрения: специалист по налогам, налоговый инспектор.
Рисунок 5 – Контекстная диаграмма существующего документооборота при работе с налогоплательщиками
Входами для процесса исполнения бюджета являются:
- декларация;
- реестр плательщиков;
- заявление о регистрации;
- документы (физические лица);
- документы (юридические лица);
- платежное поручение.
Управляющими воздействиями являются:
- законы;
- тарифы;
- инструкции;
- постановления и приказы.
В качестве механизмов рассматриваются:
- отдел анализа отчетности и урегулирования задолженности;
- отдел по работе с налогоплательщиками;
- отделы камеральных и выездных проверок;
- руководство;
- АРМ, ПО.
Выходами (результатами) для процесса администрирования страховых взносов являются:
- уведомления о регистрации;
- акты:
- отчеты;
- справки;
- требования по взысканию.
На рисунке 6 представлена декомпозиция контекстной модели существующего документооборота при работе с налогоплательщиками
Рисунок 6 – Декомпозиция контекстной модели существующего документооборота при работе с налогоплательщиками
На диаграмме А0 представлена декомпозиция диаграммы А-0. На ней представлены пять функциональных блоков:
- А1. Зарегистрировать налогоплательщиков.
- А2. Производить учет платежей.
- А3. Проводить камеральные проверки.
- А4. Проводить выездные проверки.
- А5. Производить взыскание задолженностей.
Построена функциональная модель предлагаемого процесса по методологии IDEF0 (рисунок 7).
Рисунок 7 – Декомпозиция первого уровня предлагаемого процесса
На диаграмме (рисунок 8) представлена декомпозиция функционального блока «Осуществить работу с налогоплательщиками».
Рисунок 8 – Диаграмма декомпозиции первого уровня «Осуществить работу с налогоплательщиками»
Проектирование баз данных начинается с создания информационной модели приложения. Получение информационной модели называют инфологическим проектированием. Информационной моделью (ИМ) называют представление на некотором языке множества типов объектов, называемых сущностями, и отношений (связей) между ними. В качестве языка представления ИМ наибольшее распространение получил диаграммный язык, предлагаемый в методике информационного (инфологического) проектирования приложений IDEF1X, получившей международное признание.