Автоматизированный учет радиоточек передающего центра (стр. 3 из 15)
CASE – технология представляет собой совокупность методологий анализа, проектирования, разработки и сопровождения сложных систем ПО, поддержанную комплексом взаимосвязанных средств автоматизации.
CASE – технологии не являются самостоятельными методологиями, они только развивают структурные методологии и делают эффективным их применение за счет автоматизации.
Структурный анализ – это систематический пошаговый подход к анализу требования и проектированию системы независимо от того, является ли она существующей или создается вновь.
Целью методологий является преобразование общих, неясных знаний о требованиях к системе в точные (на сколько это возможно) определения.
Для целей моделирования систем вообще и структурного анализа в частности, используются три группы средств, иллюстрирующих:
- функции, которые должна выполнять система;
- отношения между данными;
- независящее от времени поведение системы (аспекты реального времени).
- Среди всего многообразия средств решения данных задач в методологиях структурного анализа наиболее часто применяемыми являются следующие:
- DFD (Data Flow Diagrams) — диаграммы потоков данных совместно со словарями данных и спецификациями процессов
- ERD (Entity-Relationship Diagrams) — диаграммы “сущность — связь”
- STD (State Transition Diagrams) — диаграммы переходов состояний.
Все они содержат графические и текстовые средства моделирования:
- Первые - для удобства демонстрирования основных компонентов модели,
- Вторые - для обеспечения точного определения ее компонентов и связи.
Перечисленные средства дают полное описание системы, независимо от того, является ли она существующей или разрабатываемой с нуля. Это дает проектировщику четкое представление о конечных результатах, которые следует получить.[5]
Для создания информационно-справочной системы для учета кадров на предприятии «Локомотивное депо Лида» использовались эффективные инструменты анализа, проектирования и кодогенерации фирмы PLATINUM technology – Bpwin и Erwin и CASE – средства Rational Rose фирмы Rational Software Corporation.
Отображение модели данных в Erwin может быть представлено двумя уровнями – логическим и физическим. Erwin имеет несколько уровней отображения диаграммы: уровень сущностей, уровень атрибутов, уровень определений, уровень первичных ключей и уровень иконок. Интерфейс выполнен в стиле Windows-приложений, достаточно прост и интуитивно понятен.
В основе работы Rational Rose лежит построение диаграмм и спецификаций UML, определяющих архитектуру системы, ее статические и динамические аспекты. В составе Rational Rose можно выделить шесть основных структурных компонентов: репозиторий, графический интерфейс пользователя, средства просмотра проекта (браузер), средства контроля проекта, средства сбора статистики и генератор документов.
Репозиторий представляет собой базу данных проекта. Браузер обеспечивает «навигацию» по проекту, в том числе перемещение по иерархиям классов и подсистем, переключение от одного вида диаграмм к другому и т.д. Средства контроля и сбора статистики дают возможность находить и устранять ошибки по мере развития проекта, а не после завершения его описания. Генератор отчетов формирует тексты выходных документов на основе содержащейся в репозитории информации.
В модели Rose поддерживаются четыре представления – это представление вариантов использования, логическое представление, представление компонентов и представление размещения.
Представление вариантов использования содержит всех действующих лиц, все варианты использования и их диаграммы для конкретной системы. Оно может также содержать некоторые диаграммы последовательности и кооперативные диаграммы. Логическое представление концентрируется на том, как система будет реализовывать поведение, описанное в вариантах использования. Оно дает подробную картину составных частей системы и описывает взаимодействие этих частей.[6]
Диаграммы потоков данных являются основным средством моделирования функциональных требований к проектируемой системе. С их помощью эти требования представляются в виде иерархии функциональных компонентов (процессов), связанных потоками данных. Главная цель такого представления – продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить связи между этими процессами.
В анализируемой предметной области документы являются источником сведений для создания БД. Документы позволяют выявить структуру данных и являются основой для разработки форм ввода-вывода и отчетов.
Модель системы определяется как иерархия диаграмм потоков данных, описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи пользователю. Диаграммы верхних уровней иерархии (контекстные диаграммы) определяют основные процессы или подсистемы с внешними входами и выходами. Они детализируются с помощью диаграмм нижнего уровня. Такая декомпозиция продолжается, создавая многоуровневую иерархию диаграмм до тех пор, пока не будет достигнут уровень декомпозиции, на котором процессы становятся элементарными и детализировать их далее не имеет смысла.
Источники информации (внешние сущности) порождают информационные потоки (потоки данных), переносящие информацию к подсистемам или процессам. Те, в свою очередь, преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, накопителям данных или внешним сущностям – потребителям информации.
Основными компонентами диаграмм потоков данных являются:
- внешние сущности;
- системы и подсистемы;
- процессы;
- накопители данных;
- потоки данных.
Внешняя сущность – это материальный объект или физическое лицо, представляющие собой источник или приемник информации, например, заказчик, персонал, поставщик, клиент. Определение некоторого объекта или системы в качестве внешней сущности указывает на то, что они находятся за границами анализируемой системы. В процессе анализа некоторые внешние сущности могут быть перенесены внутрь диаграммы анализируемой системы, если это необходимо, или, наоборот, часть процессов может быть вынесена за пределы диаграммы и представлена как внешняя сущность.
Модель сложной системы может быть представлена на так называемой контекстной диаграмме в виде одной системы как единого целого либо быть декомпозирована на ряд подсистем.
Процесс представляет собой преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом.
Накопитель данных – это абстрактное устройство для хранения информации, которую можно в любой момент поместить в накопитель и спустя некоторое время извлечь, причем способы помещения и извлечения могут быть любыми.
Накопитель данных в общем случае является прообразом будущей базы данных, и описание хранящихся в нем данных должно соответствовать информационной модели (ERD).
Поток данных определяет информацию, передаваемую от источника к приемнику. Реальный поток данных может быть информацией, передаваемой по коммуникационному каналу между двумя устройствами, пересылаемыми по почте письмами, магнитными носителями, переносимыми с одного компьютера на другой, и т.п.
Перед построением контекстной DFD необходимо проанализировать внешние события (внешние сущности), оказывающие влияние на функционирование системы.
Первым шагом при построении иерархии DFD является построение контекстных диаграмм. Обычно при проектировании относительно простых систем строится единственная контекстная диаграмма со звездообразной топологией, в центре которой находится так называемый главный процесс, соединенный с приемниками и источниками информации, посредством которых с системой взаимодействуют пользователи и другие внешние системы.[6]
При проведении анализа документооборота данной предметной области выяснилось, что для получения конечного результата по ведению учета платежных операций функциональная модель на момент разработки может быть описана в виде следующей диаграммы потоков данных, моделирующей деятельность оператора сектора по учету радиоточек в организациях (рисунок 1.1):
Рисунок 1.1 – Диаграмма потоков данных
Здесь основными функциями являются:
- Функция «Заполнение информации о количестве радиоточек и шифрах услуг» (данные для расчета абонентской платы);
- Функция «Заполнение информации об абонентах» (сведения об абонентах);
- Функция «Определение типа операции и вида документов» (определяется вид документа, тип проводимой операции);
- Функция «Расчет начисления абонентской платы» (формирование записей о месячном начислении абонентской платы);
- Функция «Формирование отчетов» (получение необходимой печатной отчетности);
- Функция «Вывод сальдо» (формирование исходящего сальдо).
Проведем анализ хранилища данных «Автоматизированный учет радиоточек передающего центра».
Базируясь на документообороте данной области, выявлены следующие первичные документы:
- платежное требование – документ, заверенный банком о запросе проведения перечисления денежных средств на наш расчетный счет с расчетного счета абонента;
- входящий платежный документ – документ, заверенный банком о проведении перечисления денежных средств на наш расчетный счет за оказанные нами услуги;
- приходный кассовый ордер – документ, о получении наличных денежных средств в кассу;
Рассмотрим подробнее состав первичных документов обрабатываемых в автоматизированном учете радиоточек передающего центра:
Платежное требование/поручение/входящие
Платежное поручение, т.к. оно является банковским документом то должно содержать жестко регламентированную информацию. Основными информационными полями являются: