- •Билет 1 (Понятие технологии программирования. Характеристика основных этапов ее развития.)
- •Билет 2 (Основные этапы развития технологии программирования. Первый и второй этапы.)
- •Билет 3 (Основные этапы развития технологии программирования. Третий и четвертый этапы.)
- •Билет 4 (Программа как формализованное описание процесса обработки данных. Программное средство.)
- •Билет 5 (Неконструктивность понятия правильной программы. Надежность программного средства.)
- •Билет 6 (Технология программирования как технология разработки надежных программных средств.)
- •Билет 7 (Интеллектуальные возможности человека, используемые при разработке программного средства.)
- •Билет 8 (Причина ошибок в программных средствах. Основные пути борьбы с ошибками.)
- •Билет 9 (Специфика разработки программных средств. Жизненный цикл программного средства.)
- •Билет 10 (Основные подходы к организации процесса создания и использования программного средства.)
- •Билет 11 (Водопадный подход к организации процесса создания и использования программного средства.)
- •12. Понятие качества программного средства.
- •14. Методы борьбы со сложностью. Обеспечение точности перевода. Преодоление барьера между пользователем и разработчиком. Известны два общих метода борьбы со сложностью систем:
- •15. Методы борьбы со сложностью. Контроль принимаемых решений. Известны два общих метода борьбы со сложностью систем:
- •19. Спецификация качества программного средства.
- •21) Методы контроля внешнего описания программного средства.
- •22)Основные подходы к спецификации семантики функций.
- •23) Метод таблиц решений.
- •24) Операционная семантика.
- •26) Аксиоматическая семантика.
- •27) Языки спецификаций.
- •28) Понятие архитектуры программного средства. Цельная программа. Комплекс автономно выполняемых программ.
- •29) Понятие архитектуры программного средства. Слоистая программная система. Коллектив параллельно выполняемых программ.
- •30) Архитектурные функции. Контроль архитектуры программных средств.
- •31) Цель и основные характеристики модульного программирования.
- •32) Методы разработки структуры программы. Нисходящие методы. Контроль структуры программы. Методы разработки структуры программы.
- •33) Методы разработки структуры программы. Восходящие методы. Контроль структуры программы. Методы разработки структуры программы.
- •34) Порядок разработки программного модуля.
- •35) Структурное программирование. Контроль программного модуля.
- •36. Пошаговая детализация и понятие о псевдокоде. Контроль программного модуля.
- •48. Алгоритм Кнута - Мориса - Пратта.
27) Языки спецификаций.
Как уже отмечалось, функциональная спецификация представляет собой математически точное, но, как правило, не формальное описание поведения ПС. Однако, формализованное представление функциональной спецификации имеет ряд достоинств, главным из которых является возможность применять некоторые виды автоматизированного контроля функциональной спецификации.
Под языком спецификаций понимается формальный язык, предназначенный для спецификации функций. В нем используется ряд средств, позволяющих фиксировать синтаксис и выражать семантику описываемых функций. Различие между языками программирования и языками спецификации может быть весьма условным: если язык спецификаций имеет реализацию на компьютере, позволяющую как-то выполнять представленные на нем спецификации (например, с помощью интерпретатора), то такой язык является и языком программирования, может быть, и не позволяющий создавать достаточно эффективные программы. Однако, для языка спецификаций важно не эффективность выполнения спецификации (программы) на компьютере, а ее выразительность. Язык спецификации, не являющийся языком программирования, может быть тем не менее полезен в процессе разработки ПС (для автоматизации контроля, тестирования и т.п.).
Язык спецификации может базироваться на каком-либо из рассмотренных нами методов описания семантики функций, а также поддерживать спецификацию функций для какой-либо конкретной предметной области.
28) Понятие архитектуры программного средства. Цельная программа. Комплекс автономно выполняемых программ.
Архитектура ПС - это его строение как оно видно (или должно быть видно) из-вне его, т.е. представление ПС как системы, состоящей из некоторой совокупности взаимодействующих подсистем. В качестве таких подсистем выступают обычно отдельные программы. Разработка архитектуры является первым этапом борьбы со сложностью ПС, на котором реализуется принцип выделения относительно независимых компонент.
Цельная программа представляет вырожденный случай архитектуры ПС: в состав ПС входит только одна программа. Такую архитектуру выбирают обычно в том случае, когда ПС должно выполнять одну какую-либо ярко выраженную функцию и ее реализация не представляется слишком сложной. Естественно, что такая архитектура не требует какого-либо описания (кроме фиксации класса архитектуры), так как отображение внешних функций на эту программу тривиально, а определять способ взаимодействия не требуется (в силу отсутствия какого-либо внешнего взаимодействия программы, кроме как взаимодействия ее с пользователем, а последнее описывается в документации по применению ПС).
Комплекс автономно выполняемых программ состоит из набора программ, такого, что:
любая из этих программ может быть активизирована (запущена) пользователем;
при выполнении активизированной программы другие программы этого набора не могут быть активизированы до тех пор, пока не закончит выполнение активизированная программа;
все программы этого набора применятся к одной и той же информационной среде.
Таким образом, программы этого набора по управлению никак не взаимодействуют - взаимодействие между ними осуществляется только через общую информационную среду.