- •1. История развития систем автоматизированной разработки пс.
- •2. Case-технология в разработке пс
- •3.Основные элементы объектной модели проектирования программного обеспечения (абстрагирование, инкапсуляция, модульность, иерархия). Особенности построения объектно-ориентированной системы.
- •4. Дополнительные элементы объектной модели проектирования программного обеспечения (типизация, параллелизм, устойчивость). Полиморфизм и наследование.
- •5. История появления, особенности и назначение унифицированного языка моделирования uml.
- •6.Назначение программного средства Rational xde. Основные окна и пункты меню Rational xde.
- •7.Сравнительный анализ программных продуктов Rational Rose и Rational xde
- •8. Назначение, особенности и построение диаграммы Use Case.
- •9. Назначение, особенности и построение диаграммы Deployment.
- •10. Назначение, особенности и построение диаграммы Statechart.
- •11. Назначение, особенности и построение диаграммы Activity.
- •12. Назначение, особенности и построение диаграммы Sequence.
- •13. Назначение, особенности и построение диаграммы Collaboration.
- •14. Назначение, особенности и построение диаграммы Component.
- •15, 16. Назначение, особенности и построение диаграммы Class.
- •17. Назначение и виды связей между классами на диаграммах Rational Rose. Особенности следующих связей: однонаправленная ассоциация, зависимость, ассоциированный класс, наследование, реализация.
- •19. Создание шаблона приложения с использованием библиотеки mfc. Структура и классы приложения.
- •20. Функциональные возможности Rational Rose: модуль Component Assignment Tool, компонент Model Assistant, обновление кода по модели и модели по коду.
- •21. Особенности генерации исходного кода в среде Rational xde. Способы синхронизации модели.
- •22. Сравнительный анализ процедур генерации исходного кода в Rational Rose и Rational xde
- •23. Назначение, возможности, особенности использования модуля Data Modeler.
- •24. Назначение, возможности, особенности использования модуля Data Modeler в Rational xde.
- •25. Назначение, возможности, особенности использования модуля Web Modeler.
- •26. Возможности и особенности построения Web-модели в среде Rational xde
- •27. Продукт Rational Unified Process (rup), его цели и назначение.
- •28. Статический и динамический аспекты rup.
- •29. Использование программного средства rup в сочетании с диаграммами uml
- •30.Принципы и стадии разработки пс в технологии Rational Unified Process.
- •31. Содержание и результаты первой и второй стадий в технологии Rational Unified Process
- •32. Содержание и результаты третьей и четвертой стадий в технологии rup.
- •33. Этапы и процессы создания пс в технологии Oracle.
- •34. Классический и быстрый подходы к разработке пс в технологии Oracle. Факторы, определяющие выбор подхода.
- •35. Этапы разработки пс в технологии Borland.
- •36. Принцип модульности при разработке пс
- •37. Управление рисками проекта. Процедуры идентификации и анализа рисков.
- •38. Управление рисками проекта. Ранжирование, планирование управления, разрешение и наблюдение риска.
- •39. Метрики объектно-ориентированных программных систем. Локализация. Инкапсуляция. Информационная закрытость
- •40. Метрики объектно-ориентированных программных систем. Инкапсуляция. Наследование. Абстракция.
- •41. Назначение и компоненты системной модели сапр. Обозначение, наименование, цели системы, общесистемные характеристики, входы-выходы, структура системы.
- •42. Критерии развития сапр. Функциональные и технологические критерии.
- •43. Критерии развития сапр. Экономический и эргономический критерии.
- •44. Перспективы развития технологий разработки программного обеспечения.
43. Критерии развития сапр. Экономический и эргономический критерии.
Любая техническая система, в том числе САПР (Case) характеризуется группой признаков, которые определяют меру совершенства и прогрессивности технического объекта. Такие характеристики называются критериями развития системы. Наборы критериев большинства технических систем совпадают. Это связано с тем, что все технические системы являются искусственными и человекозависимыми.
САПР относится к классу технических объектов, где преобразуемыми операндами является информация. В результате часть характеристик актуальных для других технических систем, не актуальны для САПР (связанные с затратами материалов, энергии, экологичностью).
Т. о. наиболее важные показатели для САПР
1) Функциональные критерии
2) Технологические
3) Экономические
4) Эргономические
Экономичесие:
Экономические критерии САПР служит для комплексного стоимостного учета положительного эффекта автоматизации проектирования и основных затрат при создании САПР. В качестве экономического критерия используются годовой экономический эффект от использования САПР.
КЭ=ДС+Эк-(Дк +Ке)*Ен
ДС – общее изменение себестоимости проектирования в расчетном году (связано с производительностью САПР).
Эк – годовая экономия от повышения качества проектных решений(связан с объемом новой информации).
Дк – дополнительные капиталовложения, связанные с созданием и внедрением САПР (зависит от затрат на приобретение вычислительной техники).
Ке – предпроизводственные затраты на САПР (связан с трудоемкостью разработки САПР)
Ен – нормативный коэффициент.
КЭ – м. б. как >0, так и <0. Со временем он имеет тенденцию к возрастанию.
Эргономические:
Критерий_эргономичности=реализуемая_эфффекивность/max_эффективность.
Он представляет собой зависящую от времени функцию, которая стремится к 1. Данный критерий часто называют КПД человека в системе.
44. Перспективы развития технологий разработки программного обеспечения.
На сегодняшний день технологию разработки ПО рассматривают как IT-индустрию. В этой связи можно выделить несколько перспективных направлений развития:
Динамические ИС и виртуализация – призвано совершенствовать IT, выравнивая баланс между существующими и создаваемыми ПС (сейчас 70% - поддержка, 30% - новое). Перераспределение должно быть оптимальным и эффективным. Виртуализация – один из способов решить поставленную задачу существующими аппаратными ???. Решается задача по созданию управляемого ???
Сервис-ориентированная архитектура. ПО как услуга. Позволяет взглянуть на ПО как на услугу или сервис (те любое приложение можно представить в виде четко формализованного интерфейса или протокола, с помощью которого можно пользоваться приложением). Такой взгляд на системы позволяет компоновать ИС из модулей.
Виртуализация и интерфейс пользователя