Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Билеты 13-16.docx
Скачиваний:
0
Добавлен:
01.05.2025
Размер:
300.87 Кб
Скачать

Экзаменационный билет № 13

В О П Р О С Ы

1. Информационный подход к оценке управленческих структур. Понятие системной, собственной и взаимной (внутренней) сложности системы. Оценки степени централизации/децентрализации системы α и β, их характеристики и использование в сравнительной оценке оргструктур.

Ответ:

2. Основные понятия и классификация case- технологий. Архитектура case- средства. Классификация современных case-средств.

Ответ:

Больш. CASE-систем ориент-но на авт-цию проек-я прогр. обесп-я и основано на методологиях структ. или объектно-ориент-го проек-я и прогр-я. Наиб. потребность в исп-и CASE-систем - на нач. этапах разр-ки, - на этапах анализа и спецификации требований к ЭИС. CASE-тех-я вкл-ет методы, с помощью кот. на основе граф. нота­ции строятся диагр-ы, поддерж-ые инструм-ой средой. Метод-я опред-ет шаги и этапность реал-ции про­екта, а также правила исп-ия методов, с пом. К-ых разр-ся проект. Метод - это проце-ра или техника генерации описаний ком­п-ов ЭИС (н-р, проект-ие потоков и структур данных). Нотация – отоб-е стр-ры с-ы, эл-тов дан­ных, этапов обр-ки с пом. специальных граф. сим­волов диаграмм, а также описание проекта с-ы на формаль­ных и естественных языках. Ядром с-ы явл-ся БД проекта – репозиторий. Граф. редактор диаграмм предназначен для отобр-я в граф. виде в заданной нотации проект-ой ЭИС. Верификатор диаграмм служит для контроля прав-ти построения диаграмм в заданной методологии проек-я. Документатор проекта позв-ет получать инф-ю о состоянии проекта в виде различ. отчетов. Администратор проекта представляет собой инстр-ты, необх-ые для вып-ия: инициализации проекта; задания нач. пар-ров проекта; Сервис - набор сист. утилит по об­служ-ю репозитория. Важное значение приобретают CASE-с-ы, ориент-ые на про­ект-е и генерацию баз данных и польз-ких интер­фейсов. Генерация интерфейсов с БД и возможность пре­образования между различн. концепт. схемами и моделями данных увелич-ет мобильность прикладных систем при переходе в др. операционные сре­ды. В общ. случае при выборе CASE-с-ы необх. учитывать след. аспекты: Наличие базы проектных данных, архива или словаря, Интерфейсы с другими CASE-системами, Многопольз. режим, Расширение новыми методологиями, Наличие граф. средств поддержки методологий проек-я, обесп-е качества проектной документации, мониторинга выполнения проекта. CASE-с-ы класс-ся: по поддерживаемым методологиям проек-я: функц-ориент-ые, объектно-ориент-ые и комплексно-ориент-ые; по поддерживаемым граф. нотациям построения диаграмм: с фикс. нотацией, с отдельными нотациями и наиболее распр-ми нотациями; по степени интегрированности: tools, toolkit и workbench ; по типу и архитектуре выч. техники: ориент-ые на ПЭВМ, ориент-ые на локальную выч. сеть, ориент-ые на глоб. выч. сетьи смешанного типа; по режиму коллективной разработки проекта: не поддерживающие коллективную разработку, ориент-ые на режим реального времени разработки проекта, ориент-ые на режим объединения подпроектов; по типу операционной с-ы (ОС)..

Термин CASE используется в довольно широком смысле. Первоначальное значение термина CASE, ограниченное вопросами автоматизации разработки только лишь программного обеспечения, в настоящее время приобрело новый смысл, охватывающий процесс разработки сложных ИС в целом. С самого начала CASE-технологии развивались с целью преодоления ограничений при использовании структурной методологии проектирования (сложности понимания, высокой трудоемкости и стоимости использования, трудности внесения изменений в проектные спецификации и т.д.) за счет ее автоматизации и интеграции поддерживающих средств.

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

Большинство существующих CASE-систем ориентировано на автоматизацию проектирования программного обеспечения и основано на методологиях структурного (в основном) или объектно-ориентированного проектирования и программирования, использующих спецификации в виде диаграмм или текстов для описания системных требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств.

Наибольшая потребность в использовании CASE-систем испытывается на начальных этапах разработки, а именно на этапах анализа и спецификации требований к ИС. Это объясняется тем, что цена ошибок, допущенных на начальных этапах, на несколько порядков превышает цену ошибок, выявленных на более поздних этапах разработки.

Преимущества CASE-технологии:

• улучшение качества разрабатываемого программного приложения за счет средств автоматического контроля и генерации;

• возможность повторного использования компонентов разработки;

• снижение времени создания системы;

• освобождение разработчиков от рутинной работы по документированию проекта, так как при этом используется встроенный документатор;

• возможность коллективной разработки ЭИС в режиме реального времени.

Архитектура CASE-технологии:

Ядром системы является база данных проекта - репозиторий. Он представляет собой специализированную базу данных, предназначенную для отображения состояния проектируемой ИС в каждый момент времени. Репозиторий содержит информацию об объектах проектируемой ИС и взаимосвязях между ними, все подсистемы обмениваются данными с ним.

Графический редактор диаграмм предназначен для отображения в графическом виде в заданной нотации проектируемой ИС. Он создает элементы диаграмм и взаимосвязи между ними; задает описания элементов диаграмм; редактирует элементы диаграмм, их взаимосвязи и описания.

Верификатор диаграмм служит для контроля правильности построения диаграмм в заданной методологии проектирования ИС. Он выполняет: мониторинг правильности построения диаграмм; диагностику и выдачу сообщений об ошибках;

Документатор проекта позволяет получать информацию о состоянии проекта в виде различных отчетов. Отчеты могут строиться по нескольким признакам, например по времени, автору, элементам диаграмм, диаграмме или проекту в целом.

Администратор проекта – это инструменты, необходимые для выполнения: инициализации проекта; задания начальных параметров проекта; назначения и изменения прав доступа к элементам проекта;

Сервис – это набор системных утилит по обслуживанию репозитория. Данные утилиты выполняют функции полномасштабных средств автоматизации, покрывающих весь жизненный цикл ИС.