Главная страница
Навигация по странице:

  • Описание Тип Реакция 1

  • Потоки на диаграмме верхнего уровня Потоки на диаграмме нулевого уровня

  • 3. Программные средства поддержки жизненного цикла ПО 3.1. Методологии проектирования ПО как программные продукты. Методология DATARUN и инструментальное средство SE Companion

  • 3.1.1. Методология DATARUN

  • Лекции АИС(1). Современные методы и средства проектирования информационных систем


    Скачать 0.79 Mb.
    НазваниеСовременные методы и средства проектирования информационных систем
    Дата30.11.2018
    Размер0.79 Mb.
    Формат файлаdoc
    Имя файлаЛекции АИС(1).doc
    ТипДокументы
    #58300
    страница5 из 13
    1   2   3   4   5   6   7   8   9   ...   13

    Все действия помечаются как нормальные данные. Эти данные являются событиями, которые ИС воспринимает непосредственно, например, изменение адреса клиента, которое должно быть сразу зарегистрировано. Они появляются в DFD в качестве содержимого потоков данных.

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



    Описание

    Тип

    Реакция

    1

    Клиент желает стать членом библиотеки

    ND

    Регистрация клиента в качестве члена библиотеки

    2

    Клиент сообщает об изменении адреса

    ND

    Регистрация измененного адреса клиента

    3

    Клиент запрашивает аренду фильма

    ND

    Рассмотрение запроса

    4

    Клиент возвращает фильм

    ND

    Регистрация возврата

    5

    Руководство предоставляет полномочия новому поставщику

    ND

    Регистрация поставщика

    6

    Поставщик сообщает об изменении адреса

    ND

    Регистрация измененного адреса поставщика

    7

    Поставщик направляет фильм в библиотеку

    ND

    Получение нового фильма

    8

    Руководство запрашивает новый отчет

    ND

    Формирование требуемого отчета для руководства

    Для завершения анализа функционального аспекта поведения системы строится полная контекстная диаграмма, включающая диаграмму нулевого уровня. При этом процесс "библиотека" декомпозируется на 4 процесса, отражающие основные виды административной деятельности библиотеки. Существующие "абстрактные" потоки данных между терминаторами и процессами трансформируются в потоки, представляющие обмен данными на более конкретном уровне. Список событий показывает, какие потоки существуют на этом уровне: каждое событие из списка должно формировать некоторый поток (событие формирует входной поток, реакция - выходной поток). Один "абстрактный" поток может быть разделен на более чем один "конкретный" поток.

    Потоки на диаграмме верхнего уровня

    Потоки на диаграмме нулевого уровня

    Информация от клиента

    Данные о клиенте, Запрос об аренде

    Информация для клиента

    Членская карточка, Ответ на запрос об аренде

    Информация от руководства

    Запрос отчета о новых членах, Новый поставщик, Запрос отчета о поставщиках, Запрос отчета об аренде, Запрос отчета о фильмах

    Информация для руководства

    Отчет о новых членах, Отчет о поставщиках, Отчет об аренде, Отчет о фильмах

    Информация от поставщика

    Данные о поставщике, Новые фильмы

    На приведенной DFD накопитель данных "библиотека" является глобальным или абстрактным представлением хранилища данных.

    Анализ функционального аспекта поведения системы дает представление об обмене и преобразовании данных в системе. Взаимосвязь между "абстрактными" потоками данных и "конкретными" потоками данных на диаграмме нулевого уровня выражается в диаграммах структур данных.

    На фазе анализа строится глобальная модель данных, представляемая в виде диаграммы "сущность-связь".

    Между различными типами диаграмм существуют следующие взаимосвязи:

    • ELM-DFD: события - входные потоки, реакции - выходные потоки

    • DFD-DSD: потоки данных - структуры данных верхнего уровня

    • DFD-ERD: накопители данных - ER-диаграммы

    • DSD-ERD: структуры данных нижнего уровня - атрибуты сущностей

    На фазе проектирования архитектуры строится предметная модель. Процесс построения предметной модели включает в себя:

    • детальное описание функционирования системы;

    • дальнейший анализ используемых данных и построение логической модели данных для последующего проектирования базы данных;

    • определение структуры пользовательского интерфейса, спецификации форм и порядка их появления;

    • уточнение диаграмм потоков данных и списка событий, выделение среди процессов нижнего уровня интерактивных и неинтерактивных, определение для них миниспецификаций.

    Результатами проектирования архитектуры являются:

    • модель процессов (диаграммы архитектуры системы (SAD) и миниспецификации на структурированном языке);

    • модель данных (ERD и подсхемы ERD);

    • модель пользовательского интерфейса (классификация процессов на интерактивные и неинтерактивные функции, диаграмма последовательности форм (FSD - Form Sequence Diagram), показывающая, какие формы появляются в приложении и в каком порядке. На FSD фиксируется набор и структура вызовов экранных форм. Диаграммы FSD образуют иерархию, на вершине которой находится главная форма приложения, реализующего подсистему. На втором уровне находятся формы, реализующие процессы нижнего уровня функциональной структуры, зафиксированной на диаграммах SAD.

    На фазе детального проектирования строится модульная модель. Под модульной моделью понимается реальная модель проектируемой прикладной системы. Процесс ее построения включает в себя:

    • уточнение модели базы данных для последующей генерации SQL-предложений;

    • уточнение структуры пользовательского интерфейса;

    • построение структурных схем, отражающих логику работы пользовательского интерфейса и модель бизнес-логики (Structure Charts Diagram - SCD) и привязка их к формам.

    Результатами детального проектирования являются:

    • модель процессов (структурные схемы интерактивных и неинтерактивных функций);

    • модель данных (определение в ERD всех необходимых параметров для приложений);

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

    На фазе реализации строится реализационная модель. Процесс ее построения включает в себя:

    • генерацию SQL-предложений, определяющих структуру целевой БД (таблицы, индексы, ограничения целостности);

    • уточнение структурных схем (SCD) и диаграмм последовательности форм (FSD) с последующей генерацией кода приложений.

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

    3. Программные средства поддержки жизненного цикла ПО

    3.1. Методологии проектирования ПО как программные продукты. Методология DATARUN и инструментальное средство SE Companion

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

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

    Электронные методологии и технологии (и поддерживающие их CASE-средства) составляют ядро комплекса согласованных инструментальных средств среды разработки ИС.
    3.1.1. Методология DATARUN

    Одной из наиболее распространенных в мире электронных методологий является методология DATARUN. В соответствии с методологией DATARUN ЖЦ ПО разбивается на стадии, которые связываются с результатами выполнения основных процессов, определяемых стандартом ISO 12207. Каждую стадию кроме ее результатов должен завершать план работ на следующую стадию.

    Стадия формирования требований и планирования включает в себя действия по определению начальных оценок объема и стоимости проекта. Должны быть сформулированы требования и экономическое обоснование для разработки ИС, функциональные модели (модели бизнес-процессов организации) и исходная концептуальная модель данных, которые дают основу для оценки технической реализуемости проекта. Основными результатами этой стадии должны быть модели деятельности организации (исходные модели процессов и данных организации), требования к системе, включая требования по сопряжению с существующими ИС, исходный бизнес-план.

    Стадия концептуального проектирования начинается с детального анализа первичных данных и уточнения концептуальной модели данных, после чего проектируется архитектура системы. Архитектура включает в себя разделение концептуальной модели на обозримые подмодели. Оценивается возможность использования существующих ИС и выбирается соответствующий метод их преобразования. После построения проекта уточняется исходный бизнес-план. Выходными компонентами этой стадии являются концептуальная модель данных, модель архитектуры системы и уточненный бизнес-план.

    На стадии спецификации приложений продолжается процесс создания и детализации проекта. Концептуальная модель данных преобразуется в реляционную модель данных. Определяется структура приложения, необходимые интерфейсы приложения в виде экранов, отчетов и пакетных процессов вместе с логикой их вызова. Модель данных уточняется бизнес-правилами и методами для каждой таблицы. В конце этой стадии принимается окончательное решение о способе реализации приложений. По результатам стадии должен быть построен проект ИС, включающий модели архитектуры ИС, данных, функций, интерфейсов (с внешними системами и с пользователями), требований к разрабатываемым приложениям (модели данных, интерфейсов и функций), требований к доработкам существующих ИС, требований к интеграции приложений, а также сформирован окончательный план создания ИС.

    На стадии разработки, интеграции и тестирования должна быть создана тестовая база данных, частные и комплексные тесты. Проводится разработка, прототипирование и тестирование баз данных и приложений в соответствии с проектом. Отлаживаются интерфейсы с существующими системами. Описывается конфигурация текущей версии ПО. На основе результатов тестирования проводится оптимизация базы данных и приложений. Приложения интегрируются в систему, проводится тестирование приложений в составе системы и испытания системы. Основными результатами стадии являются готовые приложения, проверенные в составе системы на комплексных тестах, текущее описание конфигурации ПО, скорректированная по результатам испытаний версия системы и эксплуатационная документация на систему.

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

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

    Методология DATARUN опирается на две модели или на два представления:

    • модель организации;

    • модель ИС.

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

    Основной принцип DATARUN заключается в том, что первичные данные, если они должным образом организованы в модель данных, становятся основой для проектирования архитектуры ИС. Архитектура ИС будет более стабильной, если она основана на первичных данных, тесно связанных с основными деловыми операциями, определяющими природу бизнеса, а не на традиционной функциональной модели.

    Любая ИС (рисунок 3.1) представляет собой набор модулей, исполняемых процессорами и взаимодействующих с базами данных. Базы данных и процессоры могут располагаться централизованно или быть распределенными. События в системе могут инициироваться внешними сущностями, такими как клиенты у банкоматов или временные события (конец месяца или квартала). Все транзакции осуществляются через объекты или модули интерфейса , которые взаимодействуют с одной или более базами данных.

    Подход DATARUN преследует две цели:

    • определить стабильную структуру, на основе которой будет строиться ИС. Такой структурой является модель данных, полученная из первичных данных, представляющих фундаментальные процессы организации;

    • спроектировать ИС на основании модели данных.

    Объекты, формируемые на основании модели данных, являются объектами базы данных, обычно размещаемыми на серверах в среде клиент/сервер. Объекты интерфейса, определенные в архитектуре компьютерной системы, обычно размещаются на клиентской части. Модель данных, являющаяся основой для спецификации совместно используемых объектов базы данных и различных объектов интерфейса, обеспечивает сопровождаемость ИС. Для их создания используется CASE-средство Silverrun, описанное в подразделе 5.1. Silverrun обеспечивает автоматизацию проведения проектных работ в соответствии с методологией DATARUN. Предоставляемая этими средствами среда проектирования дает возможность руководителю проекта контролировать проведение работ, отслеживать выполнение работ, вовремя замечать отклонения от графика. Каждый участник проекта, подключившись к этой среде, может выяснить содержание и сроки выполнения порученной ему работы, детально изучить технику ее выполнения в гипертексте по технологиям, и вызвать инструмент (модуль Silverrun) для реального выполнения работы.

    Информационная система создается последовательным построением ряда моделей, начиная с модели бизнес-процессов и заканчивая моделью программы, автоматизирующей эти процессы.
    BPM (Business Process Model) - модель бизнес-процессов.


    PDS (Primary Data Structure) - структура первичных данных.


    CDM (Conceptual Data Model) - концептуальная модель данных.


    SPM (System Process Model) - модель процессов системы.


    ISA (Information System Architecture) - архитектура информационной системы.

    1   2   3   4   5   6   7   8   9   ...   13


    написать администратору сайта