Абстрактный синтез конечных автоматов. Минимизация и детерминация конечных автоматов. Автоматы Мили и Мура. (ТА)Абстрактный синтез автоматов – это представление автомата в виде отдельных блоков функционирующих как одно целое. Например, Микропроцессор можно представить как устройство состоящее из отдельных блоков, таких как: АЛУ, очередь команд, регистровый файл и т.д. это и есть абстрактный синтез, но если Микропроцессор представлять как схему из логических элементов то это уже структурный синтез.(не путать!) По конечному автомату часто можно построить автомат с меньшим числом состояний, эквивалентный исходному. Соответствующий процесс называется минимизацией конечного автомата. Вначале выбросим из автомата все состояния, недостижимые из начального. Затем разобьем все состояния КА на классы эквивалентности следующим способом: в первый класс отнесем все конечные состояния, а во второй - все остальные. Назовем эти состояния 0-эквивалентными. Теперь построим новое 1-эквивалентное разбиение, выделив те состояния, которые по одинаковым символам переходят в 0-эквивалентные состояния. Последовательно строя n+1-эквивалентные состояния по n-эквивалентным, мы будем увеличивать число классов эквивалентности. Прекратим этот процесс тогда, когда n+1-эквивалентное состояние совпадет с n-эквивалентным. Каждый полученный класс эквивалентности и будет состоянием нового минимизированного КА, эквивалентного исходному. Детерминация КА. Для любого недетерминированного Конечного Автомата K=<A,Q,B,b,l> существует эквивалентный ему детерминированный конечный автомат K1=<A,Q,B,b1,l1> имеющий не более чем 2n состояний (n=|Q|, |Q1|=2|Q| =2n). Замечание: Заключительными состояниями детерминированного автомата являются все те состояния, подмножества состояний исходных автоматов, которых содержат заключительные состояния исходного автомата.
2. Понятие надёжности электронного аппарата. Расчёт времени безотказной работы. (КТОП) Требования по надежности. Данные требования включают в себя обеспечение: 1.вероятности безотказной работы 2.наработки на отказ 3.среднего времени восстановления работоспособности 4.долговечности 5.сохраняемости Вероятность безотказной работы есть вероятность того, что в заданном интервале времени при заданных режимах и условиях работы в аппаратуре не произойдет ни одного отказа. Наработкой на отказ называют среднюю продолжительность работы аппаратуры между отказами. Среднее время восстановления работоспособности определяет среднее время на обнаружение и устранение одного отказа. Эта характеристика надежности является также важным эксплуатационным параметром. Долговечностью прибора называют продолжительность его работы до полного износа с необходимыми перерывами для технического обслуживания и ремонта. Под полным износом при этом понимают состояние аппаратуры, не позволяющее ее дальнейшую эксплуатацию. Сохраняемость аппаратуры - способность сохранять все технические характеристики после заданного срока хранения и транспортирования в определенных условиях. 3. Модели жизненного цикла ПО. Методологии разработки сложных программных систем. Примеры «тяжелого» и «легкого» процесса. (ТП) Весь период существования ПО, связанный с подготовкой к его разработке, разработкой, использованием и модификациями, начиная с того момента, когда принимается решение разработать/приобрести/собрать из имеющихся компонентов новую систему или приходит сама идея о необходимости программы определенного рода, до того момента, когда полностью прекращается всякое ее использование, называют жизненным циклом ПО. В ходе жизненного цикла ПО проходит через анализ предметной области, сбор требований, проектирование, кодирование, тестирование, сопровождение и другие виды деятельности. Каждый вид представляет собой достаточно однородный набор действий, выполняемых для решения одной задачи или группы тесно связанных задач в рамках разработки и поддержки эксплуатации ПО.При этом создаются и перерабатываются различного рода артефакты — создаваемые человеком информационные сущности, документы в достаточно общем смысле, участвующие в качестве входных данных и получающиеся в качестве результатов различных деятельностей. Примерами артефактов являются: модель предметной области, описание требований, техническое задание, архитектура системы, проектная документация на систему в целом и на ее компоненты, прототипы системы и компонентов, собственно, исходный код, пользовательская документация, документация администратора системы, руководство по развертыванию, база пользовательских запросов, план проекта и пр. Модель RUP:Модель выглядит как универсальная схема: с точностью до наименований она отражает то, что включается в любое производство программного обеспечения. Однако она не приспособлена к включению в схему дополнительных этапов и функций, отражающих специфику конкретного процесса или коллектива разработчиков. Это нарушило бы фиксированную связь между жизненным циклом по RUP с моделями уровня проектирования, которым в обсуждаемом подходе уделено особое внимание. Существенным препятствием для новых операционных маршрутов является то, что не определен регламент применения для них существующих инструментов и методов работы с ними. В RUP представлена масса детально проработанных операционных маршрутов, но связываются они не с деятельностями пользователя, а с конкретными инструментами (используемыми преимущественно для моделирования), допускающими различное применение. Средства моделирования являются элементами языка UML (если угодно — его операционными конструкциями), а не инструментами фиксированной методологии. Такую методологию всегда нужно разрабатывать специально. Выход из положения, предлагаемый авторами RUP, — множество стандартных ситуаций, в которых можно воспользоваться предлагаемыми средствами. Но, к сожалению, на этом пути сложно выстраивать регламенты ситуаций использования инструментов (одна и та же ситуация для одной методологии может быть правомерной, а для другой — нет). И уж совсем не получится организовать контроль связей между объектами, с которыми работают разные инструменты (то, что один и тот же объект используется в разных моделях, установить достаточно просто, но нет возможности проверить нарушение предписания задействовать в разных моделях один и тот же объект).
|
