Программная инжинерия. Контрольная работа. Контрольная работа. Вариант Функциональные и нефункциональные требования. Функциональные требования
 Скачать 335.31 Kb.
|
Оглавление6.Функциональные и нефункциональные требования. 2 7.Прототипирование 6 8.Основные понятия методов формальной спецификации. 7 9.Основные понятия и принципы разработки ПО 13 10.Архитектура ПО 17 Список литературы 20 21 Контрольная работа. Вариант 2. 6.Функциональные и нефункциональные требования.Функциональные требования: При разработке программного обеспечения функциональные требования определяют функции, которые должно выполнять все приложение или только один из его компонентов. Функция состоит из трех шагов: ввод данных - поведение системы - вывод данных. Он может вычислять, манипулировать данными, выполнять бизнес-процессы, устанавливать взаимодействие с пользователем или выполнять любые другие задачи. Другими словами, функциональное требование - это то, ЧТО приложение должно или не должно делать после ввода некоторых данных. Функциональные требования важны, поскольку они показывают разработчикам программного обеспечения, как должна вести себя система. Если система не соответствует функциональным требованиям, значит, она не работает должным образом. Не функциональные требования: Нефункциональные требования определяют стандарты производительности и атрибуты качества программного обеспечения, например удобство использования системы, эффективность, безопасность, масштабируемость и т.д. В то время как функциональные требования определяют, что делает система, нефункциональные требования описывают, КАК система это делает. Например, веб-приложение должно обрабатывать более 15 миллионов пользователей без какого-либо снижения производительности, или веб-сайт не должен загружаться более 3 секунд. Если приложение не соответствует нефункциональным требованиям, оно продолжает выполнять свои основные функции, однако не сможет обеспечить удобство для пользователя. Нефункциональные требования важны, поскольку они помогают разработчикам программного обеспечения определять возможности и ограничения системы, которые необходимы для разработки высококачественного программного обеспечения. Следовательно, нефункциональные требования так же важны, как и функциональные требования для успешного внедрения продукта. На рисунке 1 представлен вид деления требований.  Рисунок 1 – Деление требований Почему важна разница между функциональными и нефункциональными требованиями? Четко определенные функциональные и нефункциональные требования помогают разработчикам программного обеспечения создавать продукт, точно соответствующий потребностям клиента. Однако действительно ли необходимо знать разницу между функциональными и нефункциональными требованиями? Основная причина знать разницу между функциональными и нефункциональными требованиями заключается в том, что они определяют объем работ по проекту. Разработчики программного обеспечения должны идти в ногу с этим объемом, чтобы разработать приложение в рамках своих временных рамок и бюджета. Если объем работ постоянно меняется, команде разработчиков приходится продлевать сроки, и затраты на разработку возрастают. Это может привести к неблагоприятным последствиям для проекта. Важность различения двух типов требований имеет первостепенное значение при создании MVP. Команда разработчиков и заказчик должны обсудить, какие функции и функции следует реализовать в приложении в первую очередь. Заказчик может иметь собственное видение проекта и его требований. Если заказчик решает удалить или изменить какую-либо функцию, важно понимать, что это за требование. В большинстве случаев разработчики программного обеспечения могут просто изменить нефункциональные требования, в то время как функциональные требования потребуют дополнительной работы и серьезных изменений. Когда заказчик и поставщик разработки программного обеспечения знают разницу между функциональными и нефункциональными требованиями, это помогает им более точно определять объем работ, более точно ранжировать требования по важности, оптимизировать затраты на проект и лучше удовлетворять потребности заказчика Как собираются функциональные и нефункциональные требования? В идеале, прежде чем обращаться в компанию по разработке программного обеспечения, у клиентов уже должны быть под рукой все функциональные и нефункциональные требования. Поэтому их необходимо подготовить заранее самостоятельно или попросить стороннего поставщика. Давайте посмотрим, что включает в себя каждый тип требований. Функциональные требования можно разделить на три группы: бизнес-требования — опишите цели и ожидания проекта, преимущества, которые может принести проект, возможные ограничения проекта и его объем; требования пользователя — включают потребности пользователя и действия, которые пользователь сможет выполнять в системе; системные требования — включают системные действия, спецификации программного и аппаратного обеспечения и т. д. Нефункциональные требования подпадают под различные категории, в том числе: удобство использования — определяет, насколько легко пользователь может взаимодействовать с интерфейсом приложения, например, цвет экрана, размер кнопок и т. д.; доступность — гарантирует, что приложение будет стабильно работать в течение определенного периода времени, например, редкие простои в течение года 24/7; надежность — определяет, что приложение будет работать в определенной среде или в течение определенного периода времени без сбоев; восстанавливаемость — гарантирует, что приложение сможет восстановить все данные после сбоя системы или восстановить систему до определенных параметров; масштабируемость — определяет, что приложение будет продолжать работать должным образом после изменения его размера или объема; производительность — оценивает, насколько быстро работает приложение; возможность поддержки — определяет, легко ли поддерживать и поддерживать приложение на протяжении всего его жизненного цикла, и какая поддержка ему требуется, например, собственная команда или удаленная поддержка; безопасность — определяет, насколько безопасным должно быть приложение, например, FinTech и банковские приложения должны соответствовать международным и региональным стандартам безопасности; емкость — оценивает объем данных или служб, которые может обрабатывать приложение. 7.ПрототипированиеПрототип и прототипирование Прототип это макет решения, который можно собрать из подручных материалов. Он используется для того, чтобы не тратить время и деньги на создание полноценного продукта, а создать, что то похожее на него т отыскать ошибки, допущенные на этапе проектирования. Собственно говоря, процесс создания прототипа и называется прототипированием, и у него есть свои плюс и минусы. Преимущество прототипирования Повышается гибкость производство. Повышается конкурентоспособность и качество производства. Себестоимость продукта сокращается на 100-150%. Недостатки прототипирования. Денежные затраты. Нередко приходится делать не один прототип, а несколько. Всё это требует денег на материалы и производство. Время. Что бы сделать прототип, в любом случае придётся потратить определённое количество времени. Процесс создания прототипа состоит из четырёх шагов: Определение начальных требований. Разработки первого варианта прототипа (в ПО. например, который содержит только пользовательский интерфейс системы). Этап изучения прототипа заказчиком и конечным пользователем. Получение обратной связи о необходимых изменениях и дополнениях. Переработка прототипа с учётом полученных замечаний и предложений. Термин «прототипирование» активно используется в индустрии компьютерных систем. В английском языке используется термин «Software Prototyping». Прототипирование в разработке программного обеспечения является важным этапом в жизненном цикле программного обеспечения. Для прототипирования компьютерных (программных) систем чаще используют языки программирования высокого уровня абстракции (напр., Java, Perl, Python, Haskell) и специализированные инструменты прототипирования (напр., Axure RP, Microsoft Expression Blend и пр.). После рассмотрения прототипа, при окончательной реализации решения обычно пишут более аккуратный, документированный код, а на тестирование и отладку системы тратят сравнительно большое количество усилий. На этапе прототипирования выявляются важные архитектурные ошибки, вносятся поправки в интерфейсы модулей системы и перераспределяется функциональность между модулями системы. 8.Основные понятия методов формальной спецификации.Этапы разработки программ: Анализ предметной области – чтобы вообще понять, о чем говорит заказчик Анализ требований – чтобы собственно сформулировать требования заказчика Разработка внешних спецификаций – требования явно, четко и недвусмысленно выписываются (с возможностью находить противоречия и несогласованности; до формализации доходит редко). Требования говорят о том, какие задачи должна решать система. Решение каждой задачи разбивается на решение ряда подзадач. Для каждой подзадачи определяется набор требуемых компонент. Разработка архитектуры системы (система разбивается на модули в соответствии функциями; каждый модуль отвечает за решение отдельной подзадачи) Разработка спецификаций модулей (интерфейсы взаимодействия между компонентами) Кодирование Тестирование и отладка. А почему тестировать можно начинать только сейчас? Почему нельзя тестировать, например, архитектуру системы? Проверить-то на соответствие можно, но в тестирование входит еще и выполнение тестируемой программы. Мы фиксируем способ проверки на соответствие – путем запусков программы. Разработка тестов выделяется отдельно. По результатам наблюдений проверяется соответствие требованиям. В чем разница между тестированием отдельной компоненты и тестированием всей программы? Люди, тестирующие систему, тестируют уже готовый продукт и могут не обладать знаниями о его внутреннем устройстве. Выделяют следующие этапы тестирования: Тестирование модулей (тестируется отдельный небольшой модуль) Интеграционное тестирование (тестируется правильность взаимодействия модулей друг с другом) Системное тестирование (тестируется система в целом) Сопровождение ПО. Анализ предметной области. Анализ требований. Полнота тестового покрытия – должны покрываться по возможности наиболее широкие классы входных данных. На целевую программу можно оказывать воздействия, в ответ получать реакции. Достаточная полнота тестирования. Мы должны определить, насколько полно они должны тестировать нашу систему. i. Ошибки обработки входных данных. Здесь могут быть ошибки с неправильным разбиением входных данных или с ошибками на граничных условиях. На этом основаны: 1. Техники тестирования доменов (Partition testing). Есть входной тип – целые числа. При этом для чисел больших 1 функция должна делать одно, при меньших -3 – другое, при прочих – третье. Мы выбираем представителей каждой из групп и граничные значения. Модель покрытия – покрытие доменов. 2. Синтаксическое тестирование. Если возникает некоторых формальный язык (язык общения по сети, формат входных файлов), можно строить воздействия в соответствии с правилами грамматики этого языка. Можно выделить два момента: порождение правильных данных и порождение неправильных данных (о последнем часто забывают). Модель покрытия – различные синтаксические конструкции. ii. Ошибки «в коде» - связаны с потоками управления и потоками данных, а также другими моментами: 1. Потоки управления – написали ошибочное условие или написали один знак «равно» вместо двух. Модель покрытия - покрытие потоков управления. 2. Потоки данных – например, в цикле ищется вхождение подстроки в строку. Если мы где-то в цикле написали лишнюю единицу, то дальнейшее управление может пойти не так. Сюда попадают ошибки, связанные с инициализацией одной переменной через другую. Модель покрытия - покрытие потоков данных. 3. Переход управления между компонентами – например, забыли написать проверку входных данных. Модель покрытия - покрытие переходов состояний. iii. Ошибки при реализации требований. Требования реализованы не полностью – например, что-то забыли или не успели реализовать (или намеренно не реализовали). Модель покрытия – покрытие требований. iv. Ошибки в обработке истории взаимодействия с окружением. Можно, если программу представить в виде автомата, понимать это как переход в неправильное состояние или отсутствие какой-то операции. Модель покрытия – покрытие состояний или переходов () v. Ошибки синхронизации параллельно работающих процессов. Предпринимаются попытки определить какую-то модель покрытия в этой области, пишутся по этому поводу статьи, но общепризнанной модели покрытия пока нет. Проверка требований к тестируемой системе. Раз мы проверяем требования к системе, то мы их должны знать. И наши тесты должны их проверять. Рассмотрим, кто или что может проверять требования и как их можно проверять: i. Тестировщик – мы просто смотрим на то, какие результаты получились. Используется довольно часто. ii. Вообще ничего не проверять – смотреть только, упала программа или нет. Используется при тестировании устойчивости. iii. Формальное описание поведения. Здесь может быть несколько форм описания поведения: 1. Операционная спецификация (или явная) – описывается, какие действия выполняется и какой результат должен быть получен 2. Аксиоматическая спецификация – в виде аксиом. Например, запихнув объект в стек, а потом достав его оттуда, мы не изменим состояние стека. 3. Сценарное – как набор сценариев работы системы. Например, если мы подадим на вход что-то, то получим то-то и то-то, а по сети будет передано что-то еще. Можно для целей описания сценариев использовать темпоральные логики и описывать свойства, которые должны быть выполнены в определенный момент. 4. Контрактная спецификация – пред - и постусловия на входные и выходные данные, инварианты целостности данных. Отчеты о том, как тесты работали, что они тестировали, насколько успешно прошло тестирование, где произошла ошибка. Это вещь достаточно техническая, особо ее касаться мы не будем. Дальнейшая разработка будет сильно зависеть от того, как мы решим эти 3 задачи. Как можно, например, проверять на соответствие требованиям? Поговорим теперь о полноте тестирования. Что под этим понимается? Например, каждый оператор должен быть выполнен хотя бы один раз. Или полнота покрытия различных классов входных данных. Полнота покрытия типов – мы нигде не забыли обработать некоторые специфические типы. Полнота покрытия разных веточек говорит о выполнении каждой веточки кода определенное количество раз. Если есть ошибка в каком-то операторе, то, может быть, мы ее при тестировании найдем. Составляя тесты, мы исходим из того, какие ошибки наиболее часто совершаются. И именно по этой информации мы определяем, насколько тесты полны. Зачастую требуется определять полноту покрытия количественно. Тогда используется понятие модели покрытия. С каждым типом ошибок связан определенный тип покрытия. А теперь нужно определить, как строить тесты. Пусть есть тестируемая программа и тестирующая программа. Тестовые данные необходимо генерировать.  Данные нельзя генерировать бесцельно. Нужно вызывать определенные функции в определенные моменты, нужно вести историю входных данных. Нужно иметь: Генератор воздействий – генерирует действия, которые мы бы хотели получить. Генератор данных очередного воздействия – генерирует данные для каждого из воздействий, например, координаты щелчка мыши. А каким образом можно генерировать входные данные? Вероятностная генерация – генерация случайных данных. Используется довольно часто, и может обеспечить нормальное покрытие. Достаточно просто. Особенно для тестирования небольших процедур. Комбинаторная генерация – выделяются различные аспекты взаимодействия (принтер включен или выключен, разные ОС, разные документы), после этого представители различных классов комбинируются. Автоматная генерация – использование автоматных моделей (в том числе простейших) для генерации тестов. Пусть имеется терминальный автомат. Можно поставить за цель побывать при тестировании во всех состояниях автомата. Можно пытаться покрыть все переходы. Тесты – этого различного рода пути на этом автомате. Схема автомата – это схема тестируемой программы. Переписывание термов. Есть, например, аксиоматическое описание стека. Например, последовательность push(a), pop() не изменяет состояние стека. Если вставить ее в какую-то другую последовательность, то мы должны получить эквивалентную последовательность. Можно проверять измененные последовательности на эквивалентность. Вероятностное тестирование применяется в 2-х случаях: Ничего не понятно. Формулирование тестов в соответствии с Марковскими процессами. Например, рассматривается вероятность или риски тех или иных ошибок, и наиболее опасные ошибки протестировать наиболее тщательно. Комбинаторная генерация – один из самых простых способов. Для него не нужно практически ничего. Есть две основные методики тестирования: белый ящик и черный ящик. При тестировании белым ящиком мы используем как требования, так и внутреннюю структуру программы. При использовании черного ящика мы можем рассматривать только описание системы. Серый ящик (различная степень серости) – когда у нас есть доступ только к части структуры системы. На следующих лекциях будет рассматриваться система UniTesK и то, что она предлагает для тестирования. Эта система основана на формальных спецификациях. Основным видом спецификации является контракт, хотя аксиомы тоже могут использоваться, хоть и менее эффективно. Для оценки качества тестирования используется покрытие спецификаций. Покрытие измеряется исходя из кода спецификации – сколько единиц спецификации покрыто. Для построения последовательности тестирования используется автоматная модель, а для построения отдельных взаимодействий – комбинаторная модель. Используемый метод тестирования – черный ящик. Иногда, если есть надежные методы чтения состояния системы, используется тестирование с открытым состоянием. 9.Основные понятия и принципы разработки ПОПринципы разработки ПО — это набор определенных правил и рекомендаций, которым нужно следовать при написании исходного кода программы, если хочешь написать красивый, понятный и легко редактируемый код. То есть, существуют некоторые подсказки, которые помогают программисту определить, все ли правильно он делает. Давайте рассмотрим эти основные рекомендации. Don’t Repeat Yourself (DRY) — Не повторяйся! Достаточно простой, но при этом очень полезный принцип, который говорит, что повторение одного и того же кода в нескольких местах — очень плохая идея. Это связано в первую очередь с необходимостью дальнейшего поддержания и изменения кода. Если какой-то определенный кусок листинга повторяется в нескольких местах программы, то велика вероятность возникновения двух плачевных ситуаций: - При необходимости внести даже малейшие исправления в исходный код, вам придется заглянуть во все места где он используется, что потребует дополнительных затрат времени и сил - Из первого пункта вытекает второй, вы или другой разработчик может случайно пропустить одно из исправлений и столкнуться с последующими ошибками в работе приложения. В связи с этим есть рекомендация, если какой-либо код встречается в листинге более двух раз, то его нужно выносить в отдельный метод. Это общая рекомендация, на самом деле нужно задуматься о выделении метода даже если вы встречаете повторение второй раз. Occam’s Razor (OR) — Бритва Оккама Очень распространенная идея, которая пришла в программирование из философии. Принцип получил свое имя в честь английского монаха Уильяма из Оккама. Данный принцип гласит следующее: «Не следует множить сущее без необходимости». В сфере программирования, это правило трактуется следующим образом — не нужно создавать лишние сущности без необходимости в них. То есть, всегда задумывайтесь над тем, получите ли вы выгоду выделив дополнительный класс или метод. Ведь если вы будете выделять в отдельный метод одну строчку, которая при этом еще и нигде больше не повторяется, то только запутаете и усложните свой код. Keep It Simple Stupid (KISS) — Делай это проще Схожий с предыдущим пунктом принцип, но имеющий немного другую смысловую нагрузку. Данная рекомендация говорит, что код нужно писать простым, без сложных конструкций, так как в противном случае это может значительно усложнить поддержание и отладку. Кроме того, другому программисту будет намного сложнее разобраться в хитросплетениях и сложных ветвлениях листинга, что тоже потребует дополнительных затрат сил и времени. Поэтому всегда старайтесь использовать простые и логичные конструкции без глубокой вложенности, так вы упростите жизнь и себе, и коллегам. You Aren’t Gonna Need IT (YAGNI) — Вам это не понадобится Проблема которой страдают многие программисты. Стремление разработать сразу весь потенциально необходимый (а иногда даже ненужный) функционал с самого начала процесса разработки. То есть, когда разработчик с самого начала добавляет все возможные методы в класс и реализует их, при этом в дальнейшем может даже ни разу ими и не воспользоваться. Поэтому согласно этой рекомендации, разрабатывайте только то, что вам необходимо в первую очередь, а в дальнейшем при необходимости наращивайте функциональные возможности. Так вы сэкономите многоженство сил, времени и нервов на отладку кода, который на самом деле не нужен. Big Design Up Front (BDUF) — Масштабное проектирование прежде всего Это противоположный предыдущему принцип, который гласит, что перед тем, как приступать к разработке необходимо заранее продумать и спроектировать всю информационную систему вплоть до достаточно мелких деталей, и только после этого приступать к реализации по заранее подготовленному плану. Принцип имеет право на существование, но в последнее время встречается достаточно много его критики. В первую очередь это связано с устареванием плана за время проектирования и разработки. В связи с чем все равно приходится вносить последующие изменения. Но у него есть и неопровержимые плюсы, при грамотном проектировании можно значительно сократить затраты на дальнейшую отладку и исправление багов. Кроме того, такие информационные системы обычно получаются более лаконичными и архитектурно правильными. Avoid Premature Optimization (APO) — Избегайте преждевременной оптимизации Оптимизация — очень правильный и необходимый процесс, который позволяет ускорить работу программы, а также снизить потребление системных ресурсов. Но всему свое время. Если оптимизация проводится на ранних этапах разработки, то она может принести больше вреда чем пользы. Это в первую очередь связано с тем, что на разработку оптимизированного кода необходимо затрачивать больше времени и сил разработчика. При этом достаточно часто необходимо сначала удостоверится в правильности выбранного подхода разработки. Поэтому вначале выгоднее использовать простые, но при этом не самые оптимальные решения. А в дальнейшем, оценив как сильно замедляет работу приложения этот участок кода, выполнить изменение на более быстрый или менее ресурсоемкий алгоритм. Кроме того, за то время пока вы будите изначально реализовывать самый оптимальный алгоритм, требования могут измениться и код отправится в помойку. Так что не нужно тратить время на преждевременную оптимизацию. Principle Of Least Astonishment (POLA) — Принцип наименьшего удивления Данный принцип гласит, что ваш исходный код должен быть интуитивно понятен, очевиден, и как можно меньше удивлять другого программиста, во время чтения листинга. Это означает, что если в метод называется «Сделать автомобиль», а в результате получается мотоцикл, это плохая идея и плохой код. На самом деле я сейчас конечно утрирую, но в любом случае, ваши методы должны делать только то, что можно понять из их названия. А имена должны быть наиболее как можно более информативными, но при этом лаконичными. Не нужно писать в имя переменно целое предложение, но и называть ее одной буквой тоже не стоит. Стремитесь к тому, чтобы написанный вами код можно было читать как книгу. Law of Demeter (LOD) — Закон Деметры Основная идея данного закона состоит в разделении областей ответственности между классами и сокрытием внутренней структуры от внешней среды. То есть, каждый класс должен стремиться к тому, чтобы быть максимально самостоятельными и обособленным от остальных классов, а при необходимости взаимодействовать только с необходимыми другими классами «друзьями». Из этого закона можно выделить несколько рекомендаций: - Классы должны быть самостоятельными - Нужно стараться сократить количество связей между различными классами - Классы должны быть выстроены иерархически По поводу последнего пункта можно привести пример, из жизни. Для того, чтобы заставить собаку побежать, не нужно обращаться отдельно к каждой ее лапе. Достаточно отдать команду собаке, а она уже сама все сделает, чтобы прибежать к вам. Благодаря соблюдению данного принципа приложения становится более гибким и понятным. 10.Архитектура ПОПод архитектурой ПО понимают набор внутренних структур ПО, которые видны с различных точек зрения и состоят из компонентов, их связей и возможных взаимодействий между компонентами, а также доступных извне свойств этих компонентов [1]. Под компонентом в этом определении имеется в виду достаточно произвольный структурный элемент ПО, который можно выделить, определив интерфейс взаимодействия между этим компонентом и всем, что его окружает. Обычно при разработке ПО термин "компонент" (см. далее при обсуждении компонентных технологий) имеет несколько другой, более узкий смысл — это единица развертывания, самая маленькая часть системы, которую можно включить или не включить в ее состав. Такой компонент также имеет определенный интерфейс и удовлетворяет некоторому набору правил, называемому компонентной моделью. Там, где возможны недоразумения, будет указано, в каком смысле употребляется этот термин. В этой лекции до обсуждения UML мы будем использовать преимущественно широкое понимание этого термина, а дальше — наоборот, узкое. В определении архитектуры упоминается набор структур, а не одна структура. Это означает, что в качестве различных аспектов архитектуры, различных взглядов на нее выделяются различные структуры, соответствующие разным аспектам взаимодействия компонентов. Примеры таких аспектов — описание типов компонентов и типов статических связей между ними при помощи диаграмм классов, описание композиции компонентов при помощи структур ссылающихся друг на друга объектов, описание поведения компонентов при помощи моделирования их как набора взаимодействующих, передающих друг другу некоторые события, конечных автоматов. Архитектура программной системы похожа на набор карт некоторой территории. Карты имеют разные масштабы, на них показаны разные элементы (административно-политическое деление, рельеф и тип местности — лес, степь, пустыня, болота и пр., экономическая деятельность и связи), но они объединяются тем, что все представленные на них сведения соотносятся с географическим положением. Точно так же архитектура ПО представляет собой набор структур или представлений, имеющих различные уровни абстракции и показывающих разные аспекты (структуру классов ПО, структуру развертывания, т.е. привязки компонентов ПО к физическим машинам, возможные сценарии взаимодействий компонентов и пр.), объединяемых сопоставлением всех представленных данных со структурными элементами ПО. При этом уровень абстракции данного представления является аналогом масштаба географической карты. Рассмотрим в качестве примера программное обеспечение авиасимулятора для командной тренировки пилотов. Задачей такой системы в целом является контроль и выработка необходимых для безопасного управления самолетом навыков у команд летчиков. Кроме того, отрабатываются навыки поведения в особых ситуациях, связанных с авариями, частичной потерей управления самолетом, тяжелыми условиями полета, и т.д. Симулятор должен: Моделировать определенные условия полета и создавать некоторые события, к которым относятся следующие: Скоростной и высотный режим полета, запас горючего, их изменения со временем. Модель самолета и ее характеристики по управляемости, возможным режимам полета и скорости реакции на различные команды. Погода за бортом и ее изменения со временем. Рельеф и другие особенности местности в текущий момент, их изменения со временем. Исходный и конечный пункты полета, расстояние и основные характеристики рельефа между ними. Исправность или неисправность элементов системы контроля полета и управления самолетом, показатели системы мониторинга и их изменение со временем. Наличие пролетающих вблизи курса самолета других самолетов, их геометрические и скоростные характеристики. Чрезвычайные ситуации, например, террористы на борту, нарушение герметичности корпуса, внезапные заболевания и "смерть" отдельных членов экипажа. При этом вся совокупность условий должна быть непротиворечивой, выглядеть и развиваться подобно реальным событиям. Некоторые условия, например, погода, должны изменяться достаточно медленно, другие события — происходить внезапно и приводить к связанным с ними последствиям (нарушение герметичности корпуса может сопровождаться поломками каких-то элементов системы мониторинга или "смертью" одного из пилотов). Если приборы показывают наличие грозы по курсу и они исправны, через некоторое время летчики должны увидеть грозу за бортом и она может начать оказывать влияние на условия полета. Принимать команды, подаваемые пилотами, и корректировать демонстрируемые характеристики полета и работы системы управления самолетом в зависимости от этих команд, симулируемой модели самолета и исправности системы управления. Например, при повороте на некоторый угол вправо, показываемый пилотам "вид из кабины" должен переместиться на соответствующий угол влево со скоростью, соответствующей скорости реакции симулируемой модели самолета и исправности задействованных элементов системы управления. Понятно, что одним из элементов симулятора служит система визуализации обстановки за бортом — она показывает пилотам "вид за окнами". Пилоты в ходе полета ориентируются по показателям огромного количества датчиков, представленных на приборной панели самолета. Вся их работа тоже должна симулироваться. Наличие и характеристики работы таких датчиков могут зависеть от симулируемой модели, но их расположение, форма и цвет служат слишком важными элементами выработки навыков управления самолетом, поэтому требуется поддерживать эти характеристики близкими к реальным. Представлять их только в виде изображений на некоторой панели неудобно, поскольку они должны располагаться и выглядеть максимально похоже на реальные прототипы. Значит, симулировать можно только небольшое семейство самолетов с практически одним и тем же набором приборов на приборной панели. Список литературы1 Батоврин В.К. Системная и программная инженерия. Словарь-справочник.: учеб. пособие для вузов (направ. 230200 "Информацион. системы") / Батоврин В.К. - Москва : ДМК-Пресс, 2010 .- 280с. 2 Батоврин В.К. Системная и программная инженерия. Словарь-справочник.: учеб. пособие для вузов (направ. 230200 "Информацион. системы") / Батоврин Виктор Константинович. - Москва : ДМК-Пресс, 2010 .- 280с. 3 Бобровский С.И. Программная инженерия. Технологии Пентагона на службе российских программистов / Бобровский С.И. - СПб. : Питер, 2003 .- 224с. 4 Круз Роберт Л. Структуры данных и проектирование программ.: пер. с англ. (3-го англ. изд.) / Круз Роберт Л. - М. : БИНОМ.Лаборатория знаний, 2008 .- 765 с. 5 Липаев В.В. Программная инженерия: методологические основы.: учеб. для вузов (направ. "Бизнес-информатика" (080700)) / Липаев Владимир Васильевич. - Библиогр. в конце кн. - М. : ТЕИС, 2006 .- 608с. 6 Миньков С.Л. Разработка и применение пакетов прикладных программ в экономике.: учеб. пособие для вузов / Миньков С.Л. - Томск : Изд-во ТУСУР, 2002 .- 231с. |