Лекции по "Информационному технологии"

Лекция. Введение в структурный  системный анализ

 

 

 

 

                                                                  

 

                                                                                                      Лекция № 3

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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

 

 

Содержание

(Программные  вопросы лекции)

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

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

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

 

Литература

1. [3] c. 35-44;
2. [4] c.121-127.

 

 Учебно-материальное  обеспечение

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

2. Схема "Характеристика  основных структурных методологий".

 

Организационно-методические указания

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

 

Введение

 

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

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

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

 

Учебные вопросы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 1.

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

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

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

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

Рис . 2.

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

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

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