
- •Экзаменационный билет № 13
- •2. Основные понятия и классификация case- технологий. Архитектура case- средства. Классификация современных case-средств.
- •3. Управление модельным временем. Виды представления времени в имитационной модели, изменение времени с постоянным шагом, продвижение времени по особым состояниям.
- •Экзаменационный билет № 14
- •1. Избежание рисков;
- •2.Принятие рисков на себя;
- •3.Предотвращение убытков;
- •4.Уменьшение размера убытков;
- •5.Страхование;
- •6. Самострахование.
- •3. Планирование модельных экспериментов. Цели, стратегическое и тактическое планирование имитационного эксперимента.
- •Экзаменационный билет № 15
- •1. Банковские информационные системы. Особенности организации систем "банк-клиент".
- •3. Основные объекты имитационной модели. Граф модели, транзакты, узлы графа, события, ресурсы, пространство.
- •Экзаменационный билет № 16
- •1. Информационные системы анализа финансовой деятельности предприятия и бизнес-планирования.
- •2. Понятие прототипного проектирования. Приемы быстрой разработки приложений rad. Варианты создания системы прототипа.
- •3. Обработка и анализ результатов имитационного моделирования. Оценка качества имитационной модели, влияния и взаимосвязи факторов.
Экзаменационный билет № 13
В О П Р О С Ы
1. Информационный подход к оценке управленческих структур. Понятие системной, собственной и взаимной (внутренней) сложности системы. Оценки степени централизации/децентрализации системы α и β, их характеристики и использование в сравнительной оценке оргструктур.
Ответ:
2. Основные понятия и классификация case- технологий. Архитектура case- средства. Классификация современных case-средств.
Ответ:
Больш. CASE-систем ориент-но на авт-цию проек-я прогр. обесп-я и основано на методологиях структ. или объектно-ориент-го проек-я и прогр-я. Наиб. потребность в исп-и CASE-систем - на нач. этапах разр-ки, - на этапах анализа и спецификации требований к ЭИС. CASE-тех-я вкл-ет методы, с помощью кот. на основе граф. нотации строятся диагр-ы, поддерж-ые инструм-ой средой. Метод-я опред-ет шаги и этапность реал-ции проекта, а также правила исп-ия методов, с пом. К-ых разр-ся проект. Метод - это проце-ра или техника генерации описаний комп-ов ЭИС (н-р, проект-ие потоков и структур данных). Нотация – отоб-е стр-ры с-ы, эл-тов данных, этапов обр-ки с пом. специальных граф. символов диаграмм, а также описание проекта с-ы на формальных и естественных языках. Ядром с-ы явл-ся БД проекта – репозиторий. Граф. редактор диаграмм предназначен для отобр-я в граф. виде в заданной нотации проект-ой ЭИС. Верификатор диаграмм служит для контроля прав-ти построения диаграмм в заданной методологии проек-я. Документатор проекта позв-ет получать инф-ю о состоянии проекта в виде различ. отчетов. Администратор проекта представляет собой инстр-ты, необх-ые для вып-ия: инициализации проекта; задания нач. пар-ров проекта; Сервис - набор сист. утилит по обслуж-ю репозитория. Важное значение приобретают CASE-с-ы, ориент-ые на проект-е и генерацию баз данных и польз-ких интерфейсов. Генерация интерфейсов с БД и возможность преобразования между различн. концепт. схемами и моделями данных увелич-ет мобильность прикладных систем при переходе в др. операционные среды. В общ. случае при выборе CASE-с-ы необх. учитывать след. аспекты: Наличие базы проектных данных, архива или словаря, Интерфейсы с другими CASE-системами, Многопольз. режим, Расширение новыми методологиями, Наличие граф. средств поддержки методологий проек-я, обесп-е качества проектной документации, мониторинга выполнения проекта. CASE-с-ы класс-ся: по поддерживаемым методологиям проек-я: функц-ориент-ые, объектно-ориент-ые и комплексно-ориент-ые; по поддерживаемым граф. нотациям построения диаграмм: с фикс. нотацией, с отдельными нотациями и наиболее распр-ми нотациями; по степени интегрированности: tools, toolkit и workbench ; по типу и архитектуре выч. техники: ориент-ые на ПЭВМ, ориент-ые на локальную выч. сеть, ориент-ые на глоб. выч. сетьи смешанного типа; по режиму коллективной разработки проекта: не поддерживающие коллективную разработку, ориент-ые на режим реального времени разработки проекта, ориент-ые на режим объединения подпроектов; по типу операционной с-ы (ОС)..
Термин CASE используется в довольно широком смысле. Первоначальное значение термина CASE, ограниченное вопросами автоматизации разработки только лишь программного обеспечения, в настоящее время приобрело новый смысл, охватывающий процесс разработки сложных ИС в целом. С самого начала CASE-технологии развивались с целью преодоления ограничений при использовании структурной методологии проектирования (сложности понимания, высокой трудоемкости и стоимости использования, трудности внесения изменений в проектные спецификации и т.д.) за счет ее автоматизации и интеграции поддерживающих средств.
Таким образом, CASE-технологии не могут считаться самостоятельными, они только обеспечивают, как минимум, высокую эффективность их применения, а в некоторых случаях и принципиальную возможность применения соответствующей методологии.
Большинство существующих CASE-систем ориентировано на автоматизацию проектирования программного обеспечения и основано на методологиях структурного (в основном) или объектно-ориентированного проектирования и программирования, использующих спецификации в виде диаграмм или текстов для описания системных требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств.
Наибольшая потребность в использовании CASE-систем испытывается на начальных этапах разработки, а именно на этапах анализа и спецификации требований к ИС. Это объясняется тем, что цена ошибок, допущенных на начальных этапах, на несколько порядков превышает цену ошибок, выявленных на более поздних этапах разработки.
Преимущества CASE-технологии:
• улучшение качества разрабатываемого программного приложения за счет средств автоматического контроля и генерации;
• возможность повторного использования компонентов разработки;
• снижение времени создания системы;
• освобождение разработчиков от рутинной работы по документированию проекта, так как при этом используется встроенный документатор;
• возможность коллективной разработки ЭИС в режиме реального времени.
Архитектура CASE-технологии:
Ядром системы является база данных проекта - репозиторий. Он представляет собой специализированную базу данных, предназначенную для отображения состояния проектируемой ИС в каждый момент времени. Репозиторий содержит информацию об объектах проектируемой ИС и взаимосвязях между ними, все подсистемы обмениваются данными с ним.
Графический редактор диаграмм предназначен для отображения в графическом виде в заданной нотации проектируемой ИС. Он создает элементы диаграмм и взаимосвязи между ними; задает описания элементов диаграмм; редактирует элементы диаграмм, их взаимосвязи и описания.
Верификатор диаграмм служит для контроля правильности построения диаграмм в заданной методологии проектирования ИС. Он выполняет: мониторинг правильности построения диаграмм; диагностику и выдачу сообщений об ошибках;
Документатор проекта позволяет получать информацию о состоянии проекта в виде различных отчетов. Отчеты могут строиться по нескольким признакам, например по времени, автору, элементам диаграмм, диаграмме или проекту в целом.
Администратор проекта – это инструменты, необходимые для выполнения: инициализации проекта; задания начальных параметров проекта; назначения и изменения прав доступа к элементам проекта;
Сервис – это набор системных утилит по обслуживанию репозитория. Данные утилиты выполняют функции полномасштабных средств автоматизации, покрывающих весь жизненный цикл ИС.