Модульное программирование. Характеристики модуля (связность, сцепление, сложность)



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

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

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

1) модуль вызывается на выполнение вышестоящим по иерархии модулем и, закончив работу, возвращает ему управление;

2) принятие основных решений в алгоритме выносится на максимально высокий по иерархии уровень;

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

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

Например, при разработке СУБД используются следующие программные модули:

1) экранные формы ввода и/или редактирования информации базы данных;

2) отчеты;

3) макросы;

4) стандартные средства для обработки информации;

5) меню для выбора функции обработки и др.

Связность модуля – это мера зависимости его частей (внутренняя характеристика модуля).

Типы связности:

 (сбоку возможность изменения, внутр. связи)                                                              

1) Случайная (по совпадению) – в модуле отсутствуют явно выраженные внутренние связи. СС=0  -- --

2) Логическая – части модуля объединены по принципу функционального подобия. СС=1 -- --

3) Временная – части модуля не связаны, но необходимы в один и тот, же период работы системы. СС=3 -- --

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

5) Коммуникативная – части модуля связаны по данным (используют одни и те же структуры данных). СС=7 + +

6) Информационная (последовательная) – выходные данные одной части используются как входные данные в другой части модуля. СС=8 + +

7) Функциональная – модуль содержит элементы, участвующие в выполнении одной и только одной проблемной задачи. СС=10 + +

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

Типы сцепления: (в лекциях к этому еще и картинки есть)

1) Сцепление по данным – модули обмениваются данными, представленными скалярными значениями. СЦ=1

2) Сцепление по образцу – модули обмениваются данными, объединенными в структуры. СЦ=2

3) Сцепление по управлению – модуль посылает другому некоторый информационный объект (флаг), предназначенный для управления внутренней логикой модуля. СЦ=4

4) Сцепления по внешним ссылкам

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

6) Сцепление по содержимому – модуль содержит обращения к внутренним компонентам другого (передает управление внутрь, читает и/или изменяет внутренние данные или сами коды). СЦ=9

Рутинность модуля - это зависимость модуля от своей собственной предыстории (чем меньше, тем лучше)

Сложность модуля

Мера длины модуля

N=n₁log₂(n₁)+n₂log₂(n₂)

Количество операторов-n₁

Количество операндов-n₂

V=N*log₂(n₁+n₂)

V(G)=E-N+2

V(G)- число вершин в дереве,представл. стр-ру прогр. Системы

E- число дуг


8. Структурные методы анализа и проектирования (проверьте, я в лекциях не нашла!)

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

ü Функциональную структуру системы;

ü Последовательность выполняемых действий;

ü Передачу информации между функциональными процессами;

ü Отношения между данными.

Наиболее распространенными моделями первых трех групп являются:

ü функциональная модель SADT (Structured Analysis and Design Technique);

ü модель IDEF3;

ü DFD (Data Flow Diagrams) - диаграммы потоков данных.

Разъяснения! может и не нужно.

Метод SADT представляет собой совокупность правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями. Метод SADT разработан Дугласом Россом (SoftTech, Inc.) в 1969 г. для моделирования искусственных систем средней сложности. Данный метод успешно использовался в военных, промышленных и коммерческих организациях США для решения широкого круга задач, таких, как долгосрочное и стратегическое планирование, автоматизированное производство и проектирование, разработка ПО для оборонных систем, управление финансами и материально-техническим снабжением и др. Метод SADT поддерживается Министерством обороны США, которое было инициатором разработки семейства стандартов IDEF (Icam DEFinition), являющегося основной частью программы ICAM (интегрированная компьютеризация производства), проводимой по инициативе ВВС США. Метод SADT реализован в одном стандартов этого семейства - IDEF0, который был утвержден в качестве федерального стандарта США в 1993 г., его подробные спецификации можно найти на сайте http://www.idef.com.

Модели SADT (IDEF0) традиционно используются для моделирования организационных систем (бизнес-процессов). Следует отметить, что метод SADT успешно работает только при описании хорошо специфицированных и стандартизованных бизнес-процессов в зарубежных корпорациях, поэтому он и принят в США в качестве типового. Достоинствами применения моделей SADT для описания бизнес-процессов являются:

· полнота описания бизнес-процесса (управление, информационные и материальные потоки, обратные связи);

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

· соответствие подхода к описанию процессов стандартам ISO 9000.

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

Метод моделирования IDEF3, являющийся частью семейства стандартов IDEF, был разработан в конце 1980-х годов для закрытого проекта ВВС США. Этот метод предназначен для таких моделей процессов, в которых важно понять последовательность выполнения действий и взаимозависимости между ними. Хотя IDEF3 и не достиг статуса федерального стандарта США, он приобрел широкое распространение среди системных аналитиков как дополнение к методу функционального моделирования IDEF0 (модели IDEF3 могут использоваться для детализации функциональных блоков IDEF0, не имеющих диаграмм декомпозиции). Основой модели IDEF3 служит так называемый сценарий процесса, который выделяет последовательность действий и подпроцессов анализируемой системы.

Диаграммы потоков данных (Data Flow Diagrams - DFD) представляют собой иерархию функциональных процессов, связанных потоками данных. Цель такого представления - продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.

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

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

Наиболее распространенным средством моделирования данных (предметной области) является модель "сущность-связь" (Entity-Relationship Model - ERМ). Она была впервые введена Питером Ченом в 1976 г. Эта модель традиционно используется в структурном анализе и проектировании, однако, по существу, представляет собой подмножество объектной модели предметной области. Одна из разновидностей модели "сущность-связь" используется в методе IDEF1Х, входящем в семейство стандартов IDEF и реализованном в ряде распространенных CASE-средств (в частности, AllFusion ERwin Data Modeler).


Дата добавления: 2018-06-01; просмотров: 950; Мы поможем в написании вашей работы!

Поделиться с друзьями:






Мы поможем в написании ваших работ!