Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
шпора — копия.docx
Скачиваний:
0
Добавлен:
26.06.2025
Размер:
516.21 Кб
Скачать

13. Дайте определение сцепления мод и приведите примеры мод с разными видами сцепления.*

Сцепление явл-я мерой взаимозависимости МОД, к-я определяет, насколько хорошо модули отделены друг от друга. Модули независимы, if каждый из них не содержит о другом никакой информ. Чем > информ о других МОДх хранит МОД, тем > он с ними сцеплен.

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

Сцепление по образцу предполагает, что модули обмениваются д-ыми, объединенными в стр-ы. этот тип также обеспечивает неплохие харак-ки, но они хуже, чем у предыдущего типа, так как конкретные передаваемые д-ые «спрятаны» в стр-ы, и потому уменьшается «прозрачность» связи м/у МОДми. Кроме того, при изменении стр-ы передаваемых д-х необходимо модифицировать все исп-ющие ее модули.

При сцеплении по управлению один МОД посылает другому нек-й информационный объект (флаг), предназначенный для управ внутренней логикой МОД.

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

- прог-ы, исп-ющие д-ый тип сцепления, очень сложны для понимания при сопровождении прог-ного обеспечения;

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

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

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

16. Блочно-иерархический подход к созд-ю прог-ных систем.*

Предусматривает снач создавать части таких объектов (блоки, модули), а потом собирать из них сам объект.

Процесс разбития слож объекта на независимые части – ДЕК(ДЕК). При ДЕКом учитывают, что связки м/у отдельными частями должны быть слабее, чем связки элем-в внутри частей. чтобы из получе частей м. б. собрать разрабатываемый объект, в процессе ДЕКи необходимо опред-ть все виды связей частей м/у собой.

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

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

Результат ДЕКи обычно представ в виде схемы иерархии, на нижнем уровне к-й имеют в своем распоряжении сравнены прост блоки, а на верхнем - объект, к-й подлежит разработке. На каждом иерархическом уровне опис блоков выполняют с определенной степенью детализации, абстрагируясь от несущественных деталей. Следовательно, для каждого уровня исп-ют свои формы документации и свои модели, к-е отображают сущность процессов, к-е выполняются каждым блоком.