Учебное пособие 1438

2.Если действия внутри модуля связаны, то перейти к п.3. Если действия не связаны – перейти к п.6.

3.Если действия внутри модуля связаны, то перейти к п.4. Если действия внутри модуля связаны потоком управления, то перейти к п. 5.

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

5.Если порядок действия внутри модуля важен, то уровень связности - процедурный. Иначе - временной. Конец алгоритма.

6.Если действия внутри модуля принадлежат к одной категории, то уровень связности – логический. Иначе – по совпадению. Конец алгоритма.

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

4.5.1.4. Сцепление модулей

Сцепление (Coupling) – мера взаимосвязанности модулей по данным [15, 16]. Эту меру желательно уменьшать. Степень сцепления бывает шести типов.

1. Сцепление по данным (СЦ=1)

А В

2.Сцепление по образцу (СЦ=3). Параметр В – структуры данных.

3.Сцепление по управлению (СЦ=4). А посылает флаги в В, которые являются управляющими для В.

43

4.Сцепление по внешним ссылкам (СЦ=5). А и В ссылаются на одни глобальные данные.

5.Сцепление по общей области (СЦ=7). А и В разделяют одну и ту же глобальную структуру данных.

6.Сцепление по содержанию (СЦ=9). Модули ссылаются на данные (команды) другого модуля.

4.5.2. Сложность программной системы

Можно просто просуммировать сложность всех модулей [1, 15]. Сложность модулей по М.Холстеду (1977 г.)

N = n1 log2(n1) + n2 log2(n2), N – мера длинны модуля;

n1 - число различных операторов; n2 - число различных операторов.

Объѐм модуля (количество символов для записи всех операторов и операндов)

V=N log2 (n1+ n2).

Том МакКейб (1976 г.) [1, 15] предположил исходить из топологии внутренних связей и ввѐл цикломатическую сложность

V(G)=E–N–2,

где E – количество дуг, N – количество вершин в управляющем графе программной системы.

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

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

44

условия управления: вышестоящие модули управляют модулем, расположенным ниже уровнем.

Характеристиками являются количество модулей; количество рѐбер (связей);

высота – количество уровней управления; ширина - максимальное количество на

уровне.

Вычисляются следующие коэффициенты.

Fan_in(i) – коэффициент объединения по входу, т.е. количество модулей, которые управляют i-м модулем.

Например:

Fan-in(3)=4

Fan_out(i) – коэффициент разветвления, т.е. количество модулей, которыми управляет i-й модуль.

2

Fan_out(2)=3

Из практики проектирования известно, что лучшее решение обеспечивает иерархическая структура в виде дерева.

Хорошая структура должна иметь низкую степень сцепления и высокую связность.

Л. Константаити и Э. Йодан [13] предложили оценивать структуру ПС с помощью Fan_in и Fan_out модулей этой ПС.

45

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

С. Генри и Д. Кафура [15] ввели информационные коэффициенты Ifan_in(i) и Ifan_out(i). Эти коэффициенты учитывают количество элементов и структур данных, из которых модуль берѐт информацию или которые поступают в модуль. Вводятся аналогичные коэффициенты Sfan_in(i) и Sfan_out(i), которые учитывают вызовы модулей и называются структурными коэффициентами:

Fan_in(i) = sfan_in(i) + ifan_in(i); Fan_out(i) = sfan_out(i) + ifan_out(i).

Оценка общей сложности проводится по формуле

n

S= length(i) x (Fan_in(i) + Fan_out(i))2,

i 1

где Length(i) – оценка размера i-го модуля, например, количество операторов или LOC (Line of Code).

Системный анализ сопряжен с огромными проблемами [6, 12, 13], возникающими из-за взаимонепонимания заказчика и разработчика. Заказчик не имеет сведений о проблемах обработки информации, а аналитик не всегда может понимать тонкостей и специфики работы заказчика. В связи с этим огромную помощь аналитику оказывает методология структурного системного анализа.

Контрольные вопросы

1.В чем состоит этап проектирования ПС?

2.Каковы технологии проектирования ПС?

3.В чем суть нисходящего проектирования?

4.Для чего используются функциональные диаграммы?

46

5.Что понимается под связностью модулей?

6.Что такое сцепление модулей?

7.Как оценивается сложность программных систем?

5. CASE – ТЕХНОЛОГИИ

Современная индустриальная технология разработки программных систем (ПС) включает в себя комплекс мероприятий, руководящих документов и автоматизированных средств, предназначенных для системного анализа, разработки, кодирования, отладки, документирования, управления работой специалистов и контроля эксплуатации программ [1, 6, 12-15].

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

нологии [6].

Бурное развитие технологий разработки, тиражирования и сопровождения программного обеспечения (ПО) привело к созданию специальных технологических систем, названных

CASE (Computer–Aided Software/System Engineering) систе-

мами. Термин CASE относится и к технологиям, используемым системами.

CASE-средствам присущи следующие основные особенности:

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

47

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

использование специальным образом организованного хранилища проектных метаданных (репозитория).

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

ставленному фирмой Systems Development Inc., CASE-

технология в настоящее время попали в разряд наиболее стабильных информационных технологий. Однако, несмотря на все потенциальные возможности CASE-средств, существует множество примеров их неудачного внедрения, в результате которых CASE-средства становятся «полочным» ПО (shelfware). В связи с этим необходимо отметить следующее:

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

-реальные затраты на внедрение CASE-средств обычно намного превышают затраты на их приобретение;

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

Можно выделить основные аспекты применения CASE

–технологии:

создание ПО; проектирование, исследование предметной облас-

ти средствами структурного анализа; выпуск проектной документации; тестирование проектов;

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

48

За последние десятилетия создана громадная индустрия CASE, объединяющая сотни фирм и компаний различной ориентации. Это фирмы–разработчики средств анализа и проектирования ПО; фирмы–разработчики специального ПО; обучающие фирмы; фирмы, оказывающие помощь при использовании CASE–пакетов; фирмы, занимающиеся выпуском литературы по CASE.

За рубежом основными крупными покупателями CASE– пакетов остаются военные организации, центры обработки данных, коммерческие фирмы по разработке ПО. Практически ни одно серьезное приложение не разрабатывается сейчас без CASE. К примеру, министерством обороны США в качестве стандарта на разработку ПО взята методология структурного системного анализа (SADT) [13], составляющая одну из основ

CASE.

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

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

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

ВCASE–системах применяются наглядные диаграммные техники. Для представления модели системы могут использоваться графы, диаграммы, таблицы, схемы.

49

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

Основные преимущества применения CASE– технологий состоят в следующем:

улучшается качество ПО за счет автоматического контроля проекта;

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

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

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

5.1. Структурный системный анализ

50

На первых 2-х этапах ЖЦ ПС (анализе и проектировании) создается проект системы, достаточный для ее реализации

[6, 12 - 13].

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

На этапе анализа уточняются требования заказчика, четко формулируется ответ на вопрос «Что должна делать система?», строится концептуальная модель системы. Разработка концептуальной модели должна в себя включать:

условия, в которых эксплуатируется ПО (Hard и Soft, внешние условия, состав людей и работ);

описание функции ПО; ограничения в процессе разработки (сроки, ресурсы,

организация работы, защита информации).

На основе анализа требования формулируются как можно точнее:

архитектура системы, ее функции, внешние условия, Soft и Hard;

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

требования к программе и информационным компонентам ПО;

необходимая аппаратура, БД, физические характеристики компонентов ПО.

В соответствии с системным подходом, ставшим общепринятым в современной науке и технике, система состоит из элементов и связей между ними. Элементы системы рассматриваются не изолированно, а во взаимодействии. Свойства

51

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

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

В большинстве CASE-систем используется методология структурного системного анализа. Для моделирования системы используют 3 группы средств: функции, которые выполняет система; отношения между данными; поведение системы в реальном времени.

Структурный системный анализ предполагает такой метод исследования системы, который начинает с общего ее обзора, а затем занимается ее детализацией. В результате получается иерархическая структура с большим числом уровней. Уровни обычно имеют 3-7 элементов.

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

На каждом уровне определяются данные и операции над

ними.

Существует два основных принципа в методологии структурного анализа.

1. Разбиение сложных проблем на составляющие независимые элементы – принцип «разделяй и властвуй».

52