Логическое моделирование
Разработка сценариев и макетов экранных форм для каждого варианта использования
Цель испытаний
Руководство пользователя
ОХРАНА ТРУДА
Расчет экономической эффективности
Определение объема ПС ВТ
Расчет отчислений в Фонд социальной защиты населения
Расчет полной себестоимости разработки ПС ВТ
Человеко-час на 100 КБ
Навигация
Логическое моделирование
Автоматизированный учет радиоточек передающего центра
133397
знаков
8
таблиц
24
изображения
1. Логическое моделирование
1.1Выбор методологии и инструментария
Создание современных информационных систем представляет собой сложнейшую задачу, решение которой требует применения специальных методик и инструментов. Поэтому, в последнее время среди системных аналитиков и разработчиков значительно вырос интерес к CASE-средствам, позволяющим максимально систематизировать и автоматизировать все этапы разработки программного обеспечения.
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]
1.2Анализ потоков данных
Диаграммы потоков данных являются основным средством моделирования функциональных требований к проектируемой системе. С их помощью эти требования представляются в виде иерархии функциональных компонентов (процессов), связанных потоками данных. Главная цель такого представления – продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить связи между этими процессами.
В анализируемой предметной области документы являются источником сведений для создания БД. Документы позволяют выявить структуру данных и являются основой для разработки форм ввода-вывода и отчетов.
Модель системы определяется как иерархия диаграмм потоков данных, описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи пользователю. Диаграммы верхних уровней иерархии (контекстные диаграммы) определяют основные процессы или подсистемы с внешними входами и выходами. Они детализируются с помощью диаграмм нижнего уровня. Такая декомпозиция продолжается, создавая многоуровневую иерархию диаграмм до тех пор, пока не будет достигнут уровень декомпозиции, на котором процессы становятся элементарными и детализировать их далее не имеет смысла.
Источники информации (внешние сущности) порождают информационные потоки (потоки данных), переносящие информацию к подсистемам или процессам. Те, в свою очередь, преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, накопителям данных или внешним сущностям – потребителям информации.
Основными компонентами диаграмм потоков данных являются:
- внешние сущности;
- системы и подсистемы;
- процессы;
- накопители данных;
- потоки данных.
Внешняя сущность – это материальный объект или физическое лицо, представляющие собой источник или приемник информации, например, заказчик, персонал, поставщик, клиент. Определение некоторого объекта или системы в качестве внешней сущности указывает на то, что они находятся за границами анализируемой системы. В процессе анализа некоторые внешние сущности могут быть перенесены внутрь диаграммы анализируемой системы, если это необходимо, или, наоборот, часть процессов может быть вынесена за пределы диаграммы и представлена как внешняя сущность.
Модель сложной системы может быть представлена на так называемой контекстной диаграмме в виде одной системы как единого целого либо быть декомпозирована на ряд подсистем.
Процесс представляет собой преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом.
Накопитель данных – это абстрактное устройство для хранения информации, которую можно в любой момент поместить в накопитель и спустя некоторое время извлечь, причем способы помещения и извлечения могут быть любыми.
Накопитель данных в общем случае является прообразом будущей базы данных, и описание хранящихся в нем данных должно соответствовать информационной модели (ERD).
Поток данных определяет информацию, передаваемую от источника к приемнику. Реальный поток данных может быть информацией, передаваемой по коммуникационному каналу между двумя устройствами, пересылаемыми по почте письмами, магнитными носителями, переносимыми с одного компьютера на другой, и т.п.
Перед построением контекстной DFD необходимо проанализировать внешние события (внешние сущности), оказывающие влияние на функционирование системы.
Первым шагом при построении иерархии DFD является построение контекстных диаграмм. Обычно при проектировании относительно простых систем строится единственная контекстная диаграмма со звездообразной топологией, в центре которой находится так называемый главный процесс, соединенный с приемниками и источниками информации, посредством которых с системой взаимодействуют пользователи и другие внешние системы.[6]
При проведении анализа документооборота данной предметной области выяснилось, что для получения конечного результата по ведению учета платежных операций функциональная модель на момент разработки может быть описана в виде следующей диаграммы потоков данных, моделирующей деятельность оператора сектора по учету радиоточек в организациях (рисунок 1.1):
Рисунок 1.1 – Диаграмма потоков данных
Здесь основными функциями являются:
- Функция «Заполнение информации о количестве радиоточек и шифрах услуг» (данные для расчета абонентской платы);
- Функция «Заполнение информации об абонентах» (сведения об абонентах);
- Функция «Определение типа операции и вида документов» (определяется вид документа, тип проводимой операции);
- Функция «Расчет начисления абонентской платы» (формирование записей о месячном начислении абонентской платы);
- Функция «Формирование отчетов» (получение необходимой печатной отчетности);
- Функция «Вывод сальдо» (формирование исходящего сальдо).
Проведем анализ хранилища данных «Автоматизированный учет радиоточек передающего центра».
Базируясь на документообороте данной области, выявлены следующие первичные документы:
- платежное требование – документ, заверенный банком о запросе проведения перечисления денежных средств на наш расчетный счет с расчетного счета абонента;
- входящий платежный документ – документ, заверенный банком о проведении перечисления денежных средств на наш расчетный счет за оказанные нами услуги;
- приходный кассовый ордер – документ, о получении наличных денежных средств в кассу;
Рассмотрим подробнее состав первичных документов обрабатываемых в автоматизированном учете радиоточек передающего центра:
Платежное требование/поручение/входящие
Платежное поручение, т.к. оно является банковским документом то должно содержать жестко регламентированную информацию. Основными информационными полями являются:
- № платежного требования
- Дата платежа
- Наименование плательщика
- Наименование получателя
- Реквизиты обоих сторон (№ расчетного счета, наименование банка, код, УНН)
- Сумма платежа
- Назначение платежа
Приходный кассовый ордер
Приходный ордер, т.к. оно является кассовым документом то должно содержать жестко регламентированную информацию. Основными информационными полями являются:
- № приходного ордера
- Дата платежа
- ФИО (лицевой счет)
- Сумма платежа
- Содержание операции
Проведенный анализ состава первичных документов позволяет выделить все виды этих документов в единую сущность «Оплата», ограничиваясь при этом лишь ссылкой на их тип.
1.3Построение логической модели данных
Логическая модель – это абстрактный взгляд на данные. На ней данные представляются так, как выглядят в реальном мире. Объекты модели, представляемые на логическом уровне, называются сущностями и атрибутами. Логическая модель является универсальной и никак не связана с конкретной реализацией СУБД.
Выделение сущностей.
Сущность представляет собой множество экземпляров реальных или абстрактных объектов (людей, событий, состояний, идей и т.п.), обладающих общими атрибутами или характеристиками. Любой объект системы может быть представлен только одной сущностью, которая должна быть уникально идентифицирована. При этом имя сущности должно отражать тип или класс объекта, а не его конкретный экземпляр.
Каждая сущность должна обладать некоторыми свойствами:
- иметь уникальное имя; к одному и тому же имени должна всегда применяться одна и та же интерпретация; одна и та же интерпретация не может применяться к различным именам, если только они не являются псевдонимами;
- обладать одним или несколькими атрибутами, которые либо принадлежат сущности, либо наследуются через связь;
- обладать одним или несколькими атрибутами, которые однозначно идентифицируют каждый экземпляр сущности.
Каждая сущность может обладать любым количеством связей с другими сущностями модели. [6]
Определение отношений между сущностями.
Связь – поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области, при которой каждый экземпляр одной сущности ассоциирован с произвольным (в том числе нулевым) количеством экземпляров другой сущности, и наоборот. Отношение в самом общем виде представляет собой связь между двумя и более сущностями. Именование отношения осуществляется с помощью грамматического оборота глагола (ИМЕЕТ, ОПРЕДЕЛЯЕТ и т.п.)..
Атрибут – любая характеристика сущности, значимая для рассматриваемой предметной области и предназначенная для квалификации, идентификации, классификации, количественной характеристики или выражения состояния сущности. Атрибут представляет тип характеристик или свойств, ассоциированных с множеством реальных или абстрактных объектов (людей, мест, событий, состояний, идей, предметов и т.д.). Экземпляр атрибута – это определенная характеристика отдельного элемента множества.
- Проведенный анализ документооборота и потоков данных позволяет выделить сущности, отношения между ними и состав атрибутов, которые можно представить в виде следующих инфологических моделей:
Приложение А – Логическая модель (уровень сущностей)
Приложение Б – Логическая модель (уровень ключей)
Приложение В – Логическая модель (уровень атрибутов)
1.4Разработка диаграммы вариантов использования
Эта диаграмма, отображает взаимодействие между вариантами использования, представляющими функции системы и действующими лицами, представляющими людей или системы, получающие или передающие информацию в данную систему.
Рисунок 1.5 –Диаграмма вариантов использования проекта оператором абонентского отдела
На данной диаграмме иллюстрируются различные варианты использования:
- создание платежных требований,
- обработка входящих платежных документов,
- создание начислений и оплат абонентской платы,
- получение отчетности.
Этот тип диаграмм охватывает общую функциональность системы или требования к системе с точки зрения пользователя и обычно служит техническим заданием к разрабатываемому ПО.
Похожие работы
... комиссии с участием представителя госнадзора и им выдаются удостоверения. Повышение рабочими уровня знаний по безопасности труда осуществляется на курсах повышения квалификации, ее сдачей экзаменов. 136. Виды инструктажа, регистрация инструктажа. Инструктаж работающих подразделяется на: 1. вводный 2. первичный на рабочем месте 3. повторный 4. внеплановый 5. целевой Все ...
... технологии широкополосного доступа - по электросетям. Было разработано оборудование PLC первого и второго поколений. Достигнутая предельная скорость передачи данных не превышала 10-14 Мб/с. Реальная же скорость передачи данных в тестовых сетях PLC с применением этого оборудования отличалась на порядок и составляла 1-2 Мб/с. Кроме этого, абонентское оборудование PLC имело сравнительно высокую ...
... (индикаторов) на душу населения средних значений по Приволжскому федеральному округу, по оптимистическому варианту – достижение среднероссийских показателей. 3.3. Мероприятия по совершенствованию реализации социальных услуг в сфере образования В сфере образования и воспитания необходима реализация следующих мероприятий: - расширение сети дошкольных образовательных учреждений за счет приема ...
0 комментариев