Методы и средства структурного анализа организационно-технических систем

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

Рубрика Программирование, компьютеры и кибернетика
Вид статья
Язык русский
Дата добавления 15.12.2014
Размер файла 52,1 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на http://www.allbest.ru/

Методы и средства структурного анализа организационно-технических систем

Понятие структурного анализа и его основные принципы

Разработка программного и информационного обеспечения АСОИУ представляет собой многоэтапный процесс и основывается на системном анализе и структурном представлении закономерностей функционирования исследуемой ОТС.

Сбор и анализ требований, предъявляемых к содержанию и процессу обработки данных потенциальными пользователями, является первым этапом разработки АСОИУ. Фактически на этом этапе дается ответ на вопрос "Что происходит в исследуемой ОТС?".

Список требований к исследуемой (разрабатываемой) системе должен включать:

совокупность условий, при которых предлагается эксплуатировать будущую систему (аппаратные и программные ресурсы, предоставляемые системе; внешние условия ее функционирования; состав должностных лиц и работ, имеющих к ней отношение);

описание выполняемых системой функций;

ограничения в процессе разработки (оценка временных, организационных и технических ресурсов).

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

Здесь определяются:

архитектура системы, ее функции, внешние условия, распределение функций между аппаратурой и ПО;

интерфейсы и распределение функций между человеком и системой;

требования к видам обеспечивающей части АСОИУ (ТО, СМПО, ИЛО и др.).

Обычно выделяют следующие проблемы, которые затрудняют проведение анализа:

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

заказчик не имеет достаточной информации о проблеме обработки данных; программный информационный интерфейс

аналитик сталкивается с чрезмерным количеством подробных сведений по исследуемой ОТС;

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

Решение этих проблем существенно облегчается за счет применения современных структурных методов, среди которых центральное место занимают методологии структурного анализа.

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

Для СА характерно:

разбиение на уровни абстракции с ограничением числа элементов на каждом из уровней (от 3 до 7);

ограниченный контекст, включающий лишь существенные на каждом уровне детали;

дуальность данных и операций над ними;

использование строгих формальных правил записи;

последовательное приближение к конечному результату.

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

I. Базовые принципы:

1. Принцип декомпозиции ("разделяй и властвуй"), предполагающий решение трудных проблем путем их разбиения на более мелкие и легкие для понимания независимые задачи;

2. Иерархического упорядочивания - принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.

II. Основные принципы:

1. Принцип абстрагирования - выделения только существенных аспектов системы.

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

3. Принцип концептуальной общности - применения единого подхода к проектированию на всех этапах ЖЦ (структурный анализ - структурное проектирование - структурное программирование - структурное тестирование).

4. Принцип непротиворечивости, т.е. обоснованности и согласованности элементов модели.

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

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

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

При разработки МФ полно и точно описываются решаемые оперативно-тактические (ОТЗ), информационно-расчетные (ИРЗ) и информационные задачи, циркулируемые в системе документы и документопотоки, их информационные характеристики и требования обработки (частота решения, срочность, приоритет доступа, используемые и требуемые каналы передачи, устройства отображения и т.д.). До настоящего времени разработка МФ носила рутинный неформальный характер. Предлагаемые к изучению использованию методы и средства структурного анализа позволяют дисциплинировать и отчасти формализовать процесс создания модели функционирования.

Средства структурного анализа

Для достижения целей моделирования вообще и структурного анализа в частности, применяются три группы средств, отражающих:

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

отношения между данными;

зависимость поведения системы от времени (важность выполнения процессов предметной области в реальном масштабе времени).

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

DFD (Data Flow Diagrams) - диаграммы потоков данных совместно со словарями данных и спецификациями процессов;

ERD (Entity-Relationship Diagrams) - диаграммы "сущность-связь";

STD (State Transition Diagrams) - диаграммы переходов состояний.

Данные типы диаграмм содержат развитые графические и текстовые средства для моделирования и документирования проекта.

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

Потоки и накопители данных детализируются с помощью структурограмм описания данных и хранятся в словаре данных.

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

Моделирование содержимого накопителей данных осуществляется с помощью диаграмм "сущность-связь" - ERD.

В случае необходимости соблюдения режима реального времени DFD дополняются средствами описания зависимости поведения системы от времени STD. Формальными признаками подсистемы реального времени являются:

наличие входных/выходных потоков событий, возникающих в случайные моменты времени;

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

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

Диаграмма потоков управления представляет собой направленный граф, узлами которого являются информационные процессы (или просто процессы) и управляющие процессы, а дугами информационные потоки: потоки данных и потоки управления. Управляющие процессы преобразуют входные потоки событий (управления) в выходные и детализируются с помощью диаграмм переходов состояний (STD) или таблиц событие-отклик (ТСО).

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

Взаимосвязь средств функционального моделирования с элементами структуры модели показана на рис.1.

Рис. 1.

Классификация структурных методологий

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

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

1). Общие методологии. Они обеспечивают поддержку всего или большинства стадий ЖЦ АСОИУ. К ним относятся Software Engineering (SE) и Information Engineering (IE), которые охватывают весь спектр действий, осуществляемых в процессе создания ПО и ИО. В качестве базовых объектов разработки и последующей поддержки рассматриваются процедуры обработки данных и собственно обрабатываемая информация.

Рис. 2.

2). Методология повторной разработки (re-development). Данная методология в качестве базового объекта рассматривает различные компоненты уже разработанных систем, называемых базовыми системами. Такая методология хорошо согласуется со спиральной моделью ЖЦ, предложенной Б. Боэмом.

3). Частные методологии. Их назначение - поддержка отдельных стадий ЖЦ. Ярким примером таких методологий могут служить структурные методологии, используемые на стадии анализа. Как правило, они называются по именам своих авторов, например: Ward/Mellor, Yordon/DeMarco, Gane and Sarson и т.д. Графическое представление, соединенное с различными частными методологиями дополняет их и в то же время приводит к их ориентированности на определенные типы используемых ЭВМ.

В основе любой методологии лежит базовая система понятий "вход-процесс-выход". Эта система описывается моделью преобразования входных данных в выходные с помощью соответствующего процесса. Такая система, также как и стадии жизненного цикла АСОИУ, может быть использована для классификации методологий по признаку их ориентации на процедуры; данные; информацию.

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

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

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

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

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

поведенческой, т.е. приводящей к некоторому результату или действию;

математически-лингвистической;

технической.

В таблице 1 приведены наиболее часто используемые методологии.

Таблица 1

Название (авторы)

Год разработки

Частота применения (%)

Школа

Порядок построения

Тип системы

Э. Йордан, Т. ДеМарко

1979-1989

36,5

SE

процедурно-ориентирована

ИС, СРВ

К. Гейн, Т.Сарсон

1977

20,2

SE

процедурно-ориентирована

ИС, СРВ

Л. Констан-тайн

1979

10,6

SE

процедурно-ориентирована

ИС, СРВ

М. Джексон

1975

7,7

SE

ориентирована на данные

ИС, СРВ

К. Орр, Дж. Варнье

1976-1977

5,8

SE

ориентирована на данные

ИС

С. Шлеер, С. Меллор

1985-1992

н/д

SE

ориентирована на данные

СРВ

Дж. Мартин К. Финкель-штейн

1985

22,1

IE

информационно ориентирована

ИС

SADT (Д. Росс, К. Шуман)

1975

3,3

IE

процедурно-ориентирована; ориентирована на данные

ИС

Stradis

1985-1992

1,9

IE

процедурно-ориентирована

ИС

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

максимально покрыть все фазы ЖЦ;

обеспечить переход на любую предыдущую фазу;

осуществлять повторную разработку;

описывать сложные структуры данных;

структурировать процессы обработки данных в ОТС;

наиболее полно реализовать централизованно-информационный подход.

Заключение

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

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

Размещено на Allbest.ru

...

Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.