
- •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. Перспективы развития технологий разработки программного обеспечения.
40. Метрики объектно-ориентированных программных систем. Инкапсуляция. Наследование. Абстракция.
ОО-метрики вводятся с целью:
1) улучшения понимания качества продукта;
2) оценки эффективности процесса конструирования;
3) улучшения качества работы на этапе проектирования.
Для ОО-системы существует 5 метрических характеристик:
1) локализация;
2) инкапсуляция;
3) информационная закрытость;
4) наследование;
5) абстрагирование.
(1) — способ группировки информации в программе. В ОО-среде это происходит внутри классов/объектов. Т.к. базовый элемент — класс, локализация основывается на объектах. Метрики применяются к классу/объекту как комплексной сущности.
Метрики, отражающие способы взаимодействия классов, должны быть приспособлены к отношениям «один-ко-многим» и «многие-ко-многим».
(2) — инкапсулируются обязанности классов, задаваемые его свойствами. Для метрик учёт инкапсуляции приводит к смещению фокуса измерений с одного модуля на группу свойств обрабатывающих модулей (операций).
(3) — делает невидимыми операционные детали программного компонента. Считается, что для качественных ОО-систем характерен высокий уровень закрытости.
(4) — распространяется через все уровни иерархии классов. Не-ОО-системы не поддерживают эту характеристику.
(5) — выделение главного в компоненте/системе. Т.к. главный элемент ОО-системы — класс, следует понимать, что соответствующие метрики должны представлять и оценивать классы в терминах абстракции.
41. Назначение и компоненты системной модели сапр. Обозначение, наименование, цели системы, общесистемные характеристики, входы-выходы, структура системы.
Любая техническая система, в т.ч. и Case, может быть представлена следующим набором характеристик:
S = {Ind, Pr, Atr, Inp, Out, Str} – техническая система, где
Ind – обозначение и наименование системы
Pr – цели системы
Atr – общесистемные характеристики
Inp – входные данные
Out – выходные данные
Str – структура системы, где
Str = {E, R} – структура системы
E – компоненты
R – связи между ними
Ind (обозначение и наименование системы) – каждая коммерческая система должна иметь зарегистрированный товарный знак, который в совокупности с обозначением версии и модификации системы представляет собой обозначение системы. Наименование включает в себя ее функциональное описание.
Pr (цели системы) – достигаются за счет ее технических функций, которые характеризуют способность преобразовывать входную информацию в выходную. В качестве целей системы чаще всего выступают такие характеристики, как:
а) Трудоемкость
б) Себестоимость
в) Длительность цикла процесса
г) Качество продукта
Уменьшение трудоемкости проектирования достигается за счет:
автоматизации оформления документации,
информационной поддержки и автоматизации принятия решений,
параллельного проектирования.
Снижение себестоимости разработки происходит благодаря разумной экономии всех ресурсов.
Сокращение ЖЦ достигается за счет параллельного проектирования и создания виртуальных бюро.
Улучшение качества результатов проектирования обеспечивается путем:
использования автоматизированного поискового и многовариантного проектирования,
применения математических методов оптимизации параметров и структур объектов и процессов,
привлечения стратегического проектирования.
Atr (общесистемные характеристики) – по этим характеристикам выполняют классификацию САПР.
а) тип объекта проектирования
б) сложность проектируемых объектов
в) уровень автоматизации
Низкоавтоматизированная <25%
Среднеавтоматизированная 25%-50%
Высокоавтоматизированная >50%
г) комплексность автоматизации - зависит от стадий проектирования, которые охватывает система, здесь выделяют:
Одноэтапные
Многоэтапные
комплексные
д) возможность работы в сетевом режиме и в Internet.
Inp (входные данные) и Out (выходные данные) – зависят от функционального назначения, обычно отражены в ТЗ.
Основная задача САПР – преобразовать входные данные в выходные в соответствие с ТЗ.
E (компоненты) и R (связи между ними) – подразумевает функциональные компоненты и связи между ними. В целом структура зависит от комплектации САПР.