Деятельность с ценными бумагами

Страница 7

3. Контроль декомпозиции функций включает оценку качества на основе различных метрик ПО и частичный семантический контроль.

4. Сквозной контроль диаграмм одного или различных типов на предмет их состоятельности по уровням - вертикальное и горизонтальное балансирование диаграмм. При вертикальном балансировании (диаграммы одного типа) выявляются несбалансированные потоки данных между детализируемой и детализирующей диаграммами. Горизонтальное балансирование определяет некорректности между DFD, ERD, STD, словарями данных и миниспецификациями процессов. Так при балансировании 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] Операционные залы

Inputs: Платежные документы

Outputs: Принятые платежные документы

Controls: Законы, Продолжит. раб. дня. Остатки счетов клиентов

Mechanisms : Сотрудники, Терминал БД

[А2] Управление банком

Inputs: Принятые платежные документы

Outputs: (Unlabled), Деньги, (Unlabled)

Controls: Спец. законы. Расчет баланса. Срок обработки

Mechanisms: Управленческий персонал. Компьютеры

[АЗ] Центральный банк

Inputs: (Unlabled)

Outputs : Деньги, ( Unabled )

Controls: Срок отправки

Mechanisms: Экспедиторы, Автомашины

Done

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

Поддержка процесса проектирования и разработки

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

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

Важную роль при автоматизации ранних этапов ЖЦ грают возможности поддержки прототипирования. Соответствующие средства используются для определения системных требований и ответа на вопросы об ожидаемом поведении системы. Такие средства как генераторы меню, экраном и отчетов позволяют быстро построить прототипы пользовательских интерфейсов и снабдить моделью функционирования системы с позиций конечного пользователя . Использование языков четвертого поколения ( 4Gl ) позволяет строить более сложные модели, при этом прототип позволяет промоделировать основные функции системы, но не способен контролировать ее ожидаемое поведение. Исполняемые языки спецификаций

преобразуют процесс разработки в следующий итеративный процесс: спецификации определяются и выполняются затем производится переопределение или корректировка

Созданные таким образом прототипы позволяют определять, является ли проектируемая система полной и корректной.