All posts by admin

Для контроля структуры программы можно использовать три метода: • статический контроль, • смежный контроль, • сквозной контроль.

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

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

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

Применяются следующие методы контроля программного модуля: • статическая проверка текста модуля; • сквозное прослеживание; 

Отладка ПС ? это деятельность, направленная на обнаружение и исправление ошибок в ПС с использованием процессов выполнения его программ.

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

Ниже приводятся рекомендации по организации отладки в форме заповедей.

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

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

При разработке ПС создается и используется большой объем разнообразной документации. Она необходима как средство передачи информации между разработчиками ПС, как средство управления разработкой ПС и как средство передачи пользователям информации, необходимой для применения и сопровождения ПС.

Пользовательская документация ПС (user documentation) объясняет пользователям, как они должны действовать, чтобы применить разрабатываемое ПС. Она необходима, если ПС предполагает какое-либо взаимодействие с пользователями.

Документация по сопровождению ПС (system documentation) описывает ПС с точки зрения ее разработки. Эта документация необходима, если ПС предполагает изучение того, как оно устроена (сконструирована), и модернизацию его программ.

1. Г. Майерс. Надежность программного обеспечения. — М.: Мир, 1980. 2. E.W. Dijkstra. The Structure of the THE-Multiprogramming // Communications of the ACM. 1968, 11(5). 3. Е.А. Жоголев. Введение в технологию программирования (конспект лекций). — М.:  

C++Builder обеспечивает не только поддержку ANSI C++, но и расширяет язык новыми возможностями. Программистам использующим C++Builder для визуальной разработки приложений теперь доступны:компоненты, св-ва, методы, обработка событий и шаблоны, пространство имен, явные и непостоянные объявления, исключения.

Одним из мощных средств визуального стиля программирования явл. C++Builder компонии INPRISE(Borland) который относится к системам быстрой разработки приложений RAD. Система интегрирована палитрой компонент, разделенной карто-течными вкладками на несколько функциональных групп.

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

На основную программу в рассматриваемой архитектуре возложено 3 задачи: 1.Вызов различных операций инициализации классов 2.Создание внешних событий , которые инициализируют или продолжают канал управления 

Каждый активный класс должен определить операцию загрузить КМС .Эта операция будет вызываться основным модулем во время инициализации программы

Инициализация механизма конечного автомата полностью заключена в создании соответствующего экземпляра КМС и перехода .Это выполняется прикладными классами .

Когда прикладной класс принимает событие , он вызывает активный экземпляр .совершить событие.

Различают следующие принципы проектирования: Необходимо обеспечить: 1) Механизмы поддерживающие конечные автоматы и таймеры с помощью классов в данном архитектурном домене.

Домен – это реальный гипотетический или абстрактный мир, наполненный отчетливым набором объектов, кот-е ведут себя в соответствии с характерными для доменов правилами и линиями поведения.

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

Один и тот же процесс может использоваться в нескольких ДПДД, либо в пределах одной модели состояний, либо в нескольких моделях состояний. Такой процесс является процессом многократного использования на ДПДД и может быть преоб-разован в код многократного использования в реализации.

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

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

Канал управления – последовательность действий и событий, которые происходят на ответ поступления незапрашиваемого события, когда система прибывает в определенном состоянии. Концептуальный эскиз системы с тремя каналами управления:

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

МВО — обеспечивает краткое графическое изложение событий взаимодействия между моделями состояний и внешними сущностями (операторы, физические устройства, объекты других подсистем).