процессов. Так при балансировании DFD-ERD контролируется соответствие
каждого хранилища данных на DFD сущности или отношению на ERD. Контроль DED-
STD осуществляется по следующим правилам: каждый управляющий процесс на DFD
детализируется спецификацией управления STD, и наоборот, каждой STD должен
соответствовать управляющий процесс, каждое условие (действие) в STD должно
соответствовать входному (выходному) управляющему потоку на DFD, и
наоборот, каждому управляющему потоку в зависимости от его направленности
должно соответствовать условие/действие на STD. При балансировании DFD-
словарь данных - миниспецификация должны проверяться следующие правила:
. каждый поток и хранилище данных должны быть определены в словаре данных
(контроль неопределенных значений), и наоборот, каждое определение в
словаре должно быть отражено на диаграмме, в миниспецификации или другом
определении (контроль неиспользуемых значений);
. каждый процесс на DFD должен детализироваться с помощью DFD или
миниспецификации (но не тем и другим одновременно), и наоборот, каждая
миннспецификация должна соответствовать единственному процессу;
. ссылки к данным в миниспецификациях должны соответствовать объектам на
диаграммах и в словаре данных;
. по возможности должна контролироваться семантика миниспецификации:
например, если входные и/или выходные потоки связаны с хранилищем данных
то это должно быть отражено в миниспецификации (операторами READ, GET,
WRITE, PUT и т.п.).
Организация и поддержка репозитария.
Основные функции средств организации и поддержки репозитария - хранение,
доступ, обновление, анализ и визуализация всей информации по проекту ПО.
Содержимое репозитария включает не только информационные объекты различных
типов, но и отношения между их компонентами, а также правила использования
или обработки этих компонентов (рис. 1.3). Репозитарий может хранить свыше
100 типов объектов, примерами которых являются структурные диаграммы,
определения экранов и меню, проекты отчетов, описания данных, логика
обработки, модели данных, модели организации, модели обработки, исходные
коды, элементы данных и т.п.
Рис. 1.3 Содержимое репозитария
Каждый информационный объект в репозитарии описывается перечислением его
свойств: идентификатор, имена-синонимы, тип, текстовое описание,
компоненты, файл-хранилище, область значений. Кроме этого, хранятся все
отношения с другими объектами (например, все объекты, в которых данный
объект используется, все перекрестные ссылки), правила формирования и
редактирования объекта, а также контрольная информация о времени порождения
объекта, времени его последнего обновления, кем и в каком проекте он был
порожден, номере версии, возможности обновления и т.п.
На основе репозитария осуществляется интеграция CASE - средств и
разделение системной информации между разработчиками. При этом возможности
репозитария обеспечивают несколько уровней интеграции: общий
пользовательский интерфейс по всем средствам, передачу данных между
средствами, интеграцию этапов разработки через единую систему представлений
фаз ЖЦ, передачу данных и средств между аппаратурными платформами.
Репозитарий является базой для стандартизации документов по
проекту и контроля состоятельности проектных спецификаций. Все отчеты
строятся автоматически по репозитарию, ниже перечислены основные их типы:
1. Отчеты по содержимому включают сводки потоков данных и их компонентов,
сводки всех пар интерфейсов в описывающих межмодульные отношения
структурных диаграммах, списки входных и выходных потоков для каждого
функционального блока диаграмм, списки измененных за определенный период
объектов, истории всех изменений объектов, описания модулей, планы
тестирования модулей и подпрограмм, списки всех данных и их атрибутов, а
также отношений между их компонентами и правил их обработки.
2. Отчеты по перекрестным ссылкам включают списки всех вызывающих и
вызываемых модулей; списки объектов репозитария, к которым имеет доступ
конкретный разработчик; сводки диаграмм, использующих конкретные данные,
маршруты движения данных от входа к выходу.
3. Отчеты по результатам анализа включают сводки балансирования диаграмм по
уровням, списки неопределенных информационных объектов, списки неполных
диаграмм, сводки результатов анализа структуры проекта, списки
несогласованных в диаграммах и репозитарии объектов, списки
неиспользуемых объектов, списки удаленных объектов.
4. Отчеты по декомпозиции объектов включают таблицы иерархии всех объектов
модели.
Пример отчета по функциональным блокам SADT-модели управления
банком, автоматически создаваемого пакетом Desing/IDEF, приведен ниже.
Activity Report
[A0] Банк
Inputs: Платежные документы
Outputs: Деньги
Controls: Законы, Время, Баланс
Mechanisms : Техника, Сотрудники
Sub-Activities: [А1] Операционные залы,
[А2] Управление банком,
[АЗ] Центральный банк
[А1] Операционные залы
Outputs: Принятые платежные документы
Controls: Законы, Продолжит. раб. дня. Остатки
счетов клиентов
Mechanisms : Сотрудники, Терминал БД
[А2] Управление банком
Inputs: Принятые платежные документы
Outputs: (Unlabled), Деньги, (Unlabled)
Controls: Спец. законы. Расчет баланса. Срок
обработки
Mechanisms: Управленческий персонал. Компьютеры
Inputs: (Unlabled)
Outputs : Деньги, ( Unabled )
Controls: Срок отправки
Mechanisms: Экспедиторы, Автомашины
Done
Важные функции управления и контроля проекта также реализуются на
основе репозитария. В частности, через репозитарий может осуществляться
контроль безопасности (ограничения доступа, привилегии доступа), контроль
версии, контроль изменений и др.
Поддержка процесса проектирования и разработки
При поддержке процесса проектирования и разработки основную роль
играют следующие возможности CASE - проектов: покрытие ЖЦ, поддержка
прототипирования, поддержка структурных методологий, автоматическая
кодогенерация.
При покрытии ЖЦ, наибольшее внимание уделяется его критическим
этапам - анализу требований и проектированию спецификаций. Последние
являются основой проекта, поэтому их полнота и корректность влияют на
успех разработки в целом.
Важную роль при автоматизации ранних этапов ЖЦ грают возможности
поддержки прототипирования. Соответствующие средства используются для
определения системных требований и ответа на вопросы об ожидаемом поведении
системы. Такие средства как генераторы меню, экраном и отчетов позволяют
быстро построить прототипы пользовательских интерфейсов и снабдить моделью
функционирования системы с позиций конечного пользователя . Использование
языков четвертого поколения ( 4Gl ) позволяет строить более сложные модели,
при этом прототип позволяет промоделировать основные функции системы, но не
способен контролировать ее ожидаемое поведение. Исполняемые языки
спецификаций
преобразуют процесс разработки в следующий итеративный процесс:
спецификации определяются и выполняются затем производится переопределение
или корректировка
Созданные таким образом прототипы позволяют определять, является ли
проектируемая система полной и корректной.
Поддержка структурных методологий осуществляется за счет средств
их автоматизации на следующих двух уровнях:
. подготовка документации, графическая поддержка построения структурных
диаграмм различных типов, продуцирование спецификаций для детализации
функциональных блоков в диаграммах и структур данных на нижних уровнях;
. корректное использование шагов обработки в методологиях.
Кодогенерация осуществляется на основе репозитария позволяет
автоматически построить до 80-90% объектных кодов или текстов программ на
языках высокого уровня. При этом различными CASE - пакетами поддерживаются
практически все известные языки программирования, однако наиболее часто в
качестве целевых языков выступают COBOL, C и ADA. Средства кодогенерации по
отношению к полноте целевого продукта разделяются на средства генерации
каркаса ПО и средства генерации полного продукта. В первом случае
автоматически строится откомментированная логика (потоки управления) ПО, а
также коды для БД, файлов, экранов, отчетов и т.п., остальные фрагменты ПО
кодируются вручную. Во втором случае из проектных спецификаций генерируется
полная документированная программа, включая выполняемый код,
пользовательскую и программную документацию, наборы тестов и т.д. Все эти
компоненты полной программы связываются в единый объект, хранящийся в
депозитарии для облегчения доступа и сопровождения.
Приложение 3. Ценные бумаги
П.3.1. Классификация ценных бумаг
Ценная бумага представляет собой документ, который выражает
связанные с ним имущественные и неимущественные права, может
самостоятельно обращаться на рынке и быть объектом купли-продажи и других
сделок, служит источником получения регулярного или разового дохода. Таким
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
