- •Билет 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. Алгоритм Кнута - Мориса - Пратта.
30) Архитектурные функции. Контроль архитектуры программных средств.
Для обеспечения взаимодействия между подсистемами в ряде случаев не требуется создавать какие-либо дополнительные программные компоненты (помимо реализации внешних функций) - для этого может быть достаточно заранее фиксированных соглашений и стандартных возможностей базового программного обеспечения (операционной системы). Так в комплексе автономно выполняемых программ для обеспечения взаимодействия достаточно описания (спецификации) общей внешней информационной среды и возможностей операционной системы для запуска программ. В слоистой программной системе может оказаться достаточным спецификации выделенных программных слоев и обычный аппарат обращения к процедурам. В программном конвейере взаимодействие между программами также может обеспечивать операционная система (как это имеет место в операционной системе UNIX).
Однако в ряде случаев для обеспечения взаимодействия между программными подсистемами может потребоваться создание дополнительных программных компонент. Так для управления работой комплекса автономно выполняемых программ часто создают специализированный командный интерпретатор, более удобный в данной предметной области для подготовки требуемой внешней информационной среды и запуска требуемой программы, чем базовый командный интерпретатор используемой операционной системы. В слоистых программных системах может быть создан особый аппарат обращения к процедурам слоя (например, обеспечивающий параллельное выполнение этих процедур). В коллективе параллельно действующих программ для управления портами сообщений требуется специальная программная подсистема. Такие программные компоненты никаких внешних функций не выполняют - они реализуют функции, возникшие в результате разработки архитектуры программного средства. В связи с этим такие функции мы будем называть архитектурными.
Для контроля архитектуры ПС используется смежный контроль иручная имитация.
Смежный контроль архитектуры ПС сверху - это ее контроль разработчиками внешнего описания: разработчиками спецификации качества и разработчиками функциональной спецификации. Смежный контроль архитектуры ПС снизу - это ее контроль потенциальными разработчиками программных подсистем, входящих в состав ПС в соответствии с разработанной архитектурой.
Ручная имитация архитектуры ПС производится аналогично ручной имитации функциональной спецификации, только целью этого контроля является проверка взаимодействия между программными подсистемами. Так же как и в случае ручной имитации функциональной спецификации ПС должны быть сначала подготовлены тесты. Затем группа разработчиков должна для каждого такого теста имитировать работу каждой программной подсистемы, входящей в состав ПС. При этом работу каждой подсистемы имитирует один какой-либо разработчик (не автор архитектуры), тщательно выполняя все взаимодействия этой подсистемы с другими подсистемами (точнее, с разработчиками, их имитирующими) в соответствии с разработанной архитектурой ПС. Тем самым обеспечивается имитационное функционирование ПС в целом в рамках проверяемой архитектуры.