
- •4.Дайте определение табл реш. Приведите пример.*
- •10. Приведите пример и дайте пояснения редуцирования табл реш для какой-либо внешней спецификации.*
- •7.Дайте определение спецификациям по, назовите известные Вам внешние спецификации и их особенности. Приведите пример спецификации.*
- •6.Дайте определение нотации. Приведите пример.*
- •11. Назовите нотации и приведите пример нотации для изображения стр-ных алгоритмов.*
- •8. Назовите группы симв, к-е исп в схемах проектов по согласно гост, и приведите примеры таких Симов. *
- •13. Дайте определение сцепления мод и приведите примеры мод с разными видами сцепления.*
- •16. Блочно-иерархический подход к созд-ю прог-ных систем.*
- •31. Принципы моДного прог-ирования.* *
- •14.Дайте определение технологии прог-ирования. Какие технологии Вы знаете и к каким периодам относится появление этих технологий? *
- •28. Стихийное прог-ирование. Этапы совершенствования архитектуры прог-.*
- •14.Дайте определение технологии прог-ирования. Какие технологии Вы знаете и к каким периодам относится появление этих технологий? *
- •28. Стихийное прог-ирование. Этапы совершенствования архитектуры прог-.*
- •32. Основные понятия объектно-ориентированного прог-ирования.*
- •33. Достоинства и недостатки объектно-ориентированного прог-ирования.*
- •27. Пошаговое тест-ие моДных прог-. Достоинства и недостатки подходов.*
- •30. Нисходящая стратегия разработки прог-.*
- •27. Пошаговое тест-ие моДных прог-. Достоинства и недостатки подходов.*
- •30. Нисходящая стратегия разработки прог-.*
- •22. Ручной контроль как метод тест-ия.* *
- •23. Методы стр-ного тест-ия. Общий недостаток методов.* //белый ящик
- •24. Методы ф-онального тест-ия. Области применения.* //черный ящик
- •25. Основные положения метода эквивалентного разбиения.*
- •1.Назовите цель разбиения исх-х д-х прог- на классы эквивалентности. Приведите пример выделения классов эквивалентности для какой-либо задачи * *
- •26. Основные положения метода граничных значений.*
- •2.Дайте определение стр-ы д-х. Приведите пример стр-ы д-х. Дайте пояснения относительно ее частей.*
- •17. Проблемы разработки сложных прог-ных систем.*
- •34. Case-технологии как результат эволюционного развития инструментальных средств.*
- •35. Сравнение этапов жизн-ого цикла в case-технологиях и при традиционной разработке по.*
- •34. Case-технологии как результат эволюционного развития инструментальных средств.*
- •35. Сравнение этапов жизн-ого цикла в case-технологиях и при традиционной разработке по.*
13. Дайте определение сцепления мод и приведите примеры мод с разными видами сцепления.*
Сцепление явл-я мерой взаимозависимости МОД, к-я определяет, насколько хорошо модули отделены друг от друга. Модули независимы, if каждый из них не содержит о другом никакой информ. Чем > информ о других МОДх хранит МОД, тем > он с ними сцеплен.
Сцепление по д-ым предполагает, что модули обмениваются д-ыми, предст-нными скалярными значениями.
Сцепление по образцу предполагает, что модули обмениваются д-ыми, объединенными в стр-ы. этот тип также обеспечивает неплохие харак-ки, но они хуже, чем у предыдущего типа, так как конкретные передаваемые д-ые «спрятаны» в стр-ы, и потому уменьшается «прозрачность» связи м/у МОДми. Кроме того, при изменении стр-ы передаваемых д-х необходимо модифицировать все исп-ющие ее модули.
При сцеплении по управлению один МОД посылает другому нек-й информационный объект (флаг), предназначенный для управ внутренней логикой МОД.
Сцепление по общей области д-х предполагает, что модули работают с общей областью д-х. этот тип сцепления считается недопустимым, поскольку:
- прог-ы, исп-ющие д-ый тип сцепления, очень сложны для понимания при сопровождении прог-ного обеспечения;
- ошибка одного МОД, приводящая к изменению общих д-х, может проявиться при выполнении другого МОД, что существенно усложняет локализацию ошибок;
- при ссылке к д-ым в общей области модули исп-ют конкретные имена, что уменьшает гибкость разрабатываемого прог-ного обеспечения.
В случае сцепления по содержимому один МОД содержит обращения к внутренним компонентам другого (передает управление внутрь, читает и/или изменяет внутренние д-ые или сами коды), что полностью противоречит блочно-иерархическому подходу.
16. Блочно-иерархический подход к созд-ю прог-ных систем.*
Предусматривает снач создавать части таких объектов (блоки, модули), а потом собирать из них сам объект.
Процесс разбития слож объекта на независимые части – ДЕК(ДЕК). При ДЕКом учитывают, что связки м/у отдельными частями должны быть слабее, чем связки элем-в внутри частей. чтобы из получе частей м. б. собрать разрабатываемый объект, в процессе ДЕКи необходимо опред-ть все виды связей частей м/у собой.
При созд-и очень сложных объектов процесс ДЕКи выполняется многократно: каждый блок, ДЕКруют на части, пока не получают блоки, к-е сравнительно легко разработать- метод пошаговой детализации.
Существенным явл-я и то, что в процессе ДЕКи пытаются выделить аналогичные блоки, к-е м. б. бы разрабатывать на общей основе. Таким образом обеспечивают увелич степени повторяемости кодов и снижения стоимости разработки.
Результат ДЕКи обычно представ в виде схемы иерархии, на нижнем уровне к-й имеют в своем распоряжении сравнены прост блоки, а на верхнем - объект, к-й подлежит разработке. На каждом иерархическом уровне опис блоков выполняют с определенной степенью детализации, абстрагируясь от несущественных деталей. Следовательно, для каждого уровня исп-ют свои формы документации и свои модели, к-е отображают сущность процессов, к-е выполняются каждым блоком.