Компонентная объектная модель (СОМ)
Экзаменационные вопросы по дисциплине ООТПиСП
1. Особенности, цели создания и нотация языка UML.
2. Структура данных, таблицы и связи. Диаграмма данных и ее инструменты.
3. Создание проекта на UML. Назначение, синтаксис, инструменты диаграмм вариантов использования и анализа устройств на языке UML.
4. Особенности унифицированного процесса разработки RUP.
5. Назначение, синтаксис, инструменты диаграмм вариантов использования и анализа устройств на языке UML.
6. Статический и динамический аспекты RUP.
7. Автоматизация создания кода класса. Обновление кода по модели и модели по коду. Структура приложения и автоматизация создания его шаблона.
8. Принципы и стадии разработки программных средств в различных технологиях.
9. Технологии Rational Unified Process, Oracle, Borland: Содержание и результаты каждой стадии разработки.
10. Назначение, синтаксис, инструменты диаграмм состояний и деятельности на языке UML.
11. Назначение, синтаксис, инструменты диаграмм взаимодействия и сотрудничества на языке UML. Шаблоны проектирования на основе стандарта UML.
12. Моделирование Web приложений в CASE-среде.
13. Приведите пример диаграммы взаимодействия.
14. Автоматизация кодогенерации проекта и создание приложения на его основе.
15. Назначение, синтаксис, инструменты диаграмм компонентов и классов на языке UML.
16. Назначение, синтаксис, инструменты диаграмм взаимодействия и сотрудничества на языке UML.
|
|
|
17. Шаблоны проектирования на основе стандарта UML.
18. Основные этапы RUP.
19. Артефакты и прецеденты.
20. Использование RUP в сочетании с языком UML.
21. Понятие интерфейса.
22. Требования к разработке интерфейса.
23. Стратегии разработки программных средств и систем и реализующие их модели жизненного цикла.
24. Опишите и продемонстрируйте структурную эволюционную модель быстрого прототипирования.
25. Методология SADT.
26. Инкрементной модели экстремального программирования.
27. Опишите спиральную модель Боэма, адаптированный к положениям стандарта СТБ ИСО/МЭК 12207-2003.
28. Методология структурного анализа потоков данных DFD.
29. Опишите и продемонстрируйте спиральную модель. тоже что 27.
30. Графическое представление в IDEF1X связи мощностью один-к-нулю-одному-или-многим.
31. Компонентно-ориентированная спиральная модель – графическое представление и описание.
32. Графическое представление в IDEF1X связи один-к-одному-или-многим
33. Опишите, по какому принципу происходит выбор модели жизненного цикла для конкретного проекта
34. Графическое представление различных видов дочерней мощности соединительных связей в IDEF1X:
а) ноль-один-или-много;
б) один-или-много;
в) ноль-или-один;
|
|
|
г) точно-n;
д) от n до m;
е) мощность определяется условием, записанным в скобках
35.Структурный подход к проектированию ИС.
36. Графическое представление в IDEF1X неидентифицирующей связи мощностью один-к-нулю-одному-или-многим.
37. Основные процессы жизненного цикла.
38. Графическое представление в IDEF1X неидентифицирующей связи мощностью один-к-одному-или-многим.
39. Вспомогательные процессы жизненного цикла.
40. Графическое представление в IDEF1X неидентифицирующей связи мощностью один-к-нулю-или-одному
41. Организационные процессы жизненного цикла.
42. Графическое представление в IDEF1X обязательной неидентифицирующей связи один-к-одному.
43. Из каких работ состоит процесс разработки ПО.
44. Графическое представление в IDEF1X неспецифической связи.
45. На какие этапы жизненного цикла разбивается процесс разработки ПИ.
46. Формализация связи многие-ко-многим посредством ассоциативной сущности.
47. Экстремальное программирование
48. Организация рекурсивной связи мощностью ноль-или-один-к-нулю-одному-или-многим (использование имени роли)
49. Компонентная объектная модель (СОМ).
50. Организация рекурсивной связи мощностью ноль-или-один-к-нулю-одному-или-многим (использование полного имени внешнего ключа).
|
|
|
51. Методология DATARUN.
52. Метод JSD Джексона.
53.Общий вид ESD-диаграммы
54. Технология Оracle.
Опишите, по какому принципу происходит выбор модели жизненного цикла для конкретного проекта
1. Характеристики требований к проекту
Критерии данной категории классифицируют проекты в зависимости от свойств требований пользователя (заказчика) к разрабатываемой системе или программному средству. Например, известны ли требования к началу проекта, сложны ли они, будут ли они изменяться.
2. Характеристики команды разработчиков
Чтобы иметь возможность пользоваться критериями данной категории классификации проектов, состав команды разработчиков необходимо сформировать до выбора модели ЖЦ. Характеристики команды разработчиков играют важную роль при выборе модели ЖЦ, поскольку разработчики несут основную ответственность за успешную реализацию проекта. В первую очередь следует
учитывать квалификацию разработчиков, их знакомство с предметной областью, инструментальными средствами разработки и т.п.
3. Характеристики пользователей (заказчиков)
Чтобы иметь возможность пользоваться критериями данной категории классификации проектов, до выбора модели ЖЦ необходимо определить возможную степень участия пользователей (заказчиков) в процессе разработки и их взаимосвязь с командой разработчиков на протяжении проекта.
|
|
|
Это важно, поскольку отдельные модели ЖЦ требуют усиленного участия пользователей в процессе разработки. Выбор таких моделей при отсутствии реальной возможности пользователей участвовать в проекте приведет к существенному снижению качества результатов разработки.
4.Характеристики типов проектов и рисков
Внекоторых моделях в достаточно высокой степени предусмотрено управление рисками. В других моделях управление рисками вообще не предусматривается. Поэтому при выборе модели ЖЦ следует учитывать реальные риски проекта, критичность и сложность продуктов разработки.
Критерии данной категории отражают различные виды рисков, в том числе связанные со сложностью проекта, достаточностью ресурсов для его исполнения, учитывают график проекта и т.д. С учетом этого обеспечивается выбор модели, минимизирующей выявленные риски.
Артефакты и прецеденты
Артефакты — это некоторые продукты проекта, порождаемые или используемые в нем при работе над окончательным продуктом.
Фактически любой результат работы индивидуума или группы является артефактом, будь то документ анализа, элемент модели, файл кода, тестовый скрипт, описание ошибки и т.п. За создание того или иного вида артефактов отвечают определенные специалисты.
Таким образом, RUP четко определяет обязанности каждого члена группы разработки на том или ином этапе, то есть когда и кто должен создать тот или иной артефакт.
Прецеденты — это последовательности действий, выполняемых системой для получения наблюдаемого результата.
Основные этапы RUP
| начало | уточнение | построение | внедрение | |
| Трудоемкость | ~5 % | 20 % | 65 % | 10% |
| Продолжительность | 10 % | 30 % | 50 % | 10% |
● Начало - идея или предложение доводятся до состояния одобрения и переходят на этап уточнения.
● Уточнение - определяются видение и архитектура продукта.
● Построение - программное обеспечение разрабатывается на основе архитектурной контрольной версии и доводится до состояния, пригодного к внедрению.
● Внедрение - программное обеспечение передается пользователям.
52. Методология DATARUN.
В соответствии с методологией DATARUN ЖЦ ПО разбивается на стадии, которые связываются с результатами выполнения основных процессов, определяемых стандартом ISO 12207. Каждую стадию кроме ее результатов должен завершать план работ на следующую стадию.
Методология DATARUN опирается на две модели или на два представления:
● модель организации;
● модель ИС.
Подход DATARUN преследует две цели:
● определить стабильную структуру, на основе которой будет строиться ИС. Такой структурой является модель данных, полученная из первичных данных, представляющих фундаментальные процессы организации;
● спроектировать ИС на основании модели данных.
Компонентная объектная модель (СОМ)
В самом общем виде идея COM состоит в том, что одна часть ПО должна получать доступ к сервисам, предоставляемым другой частью, причем используется доступа ко всем видам программных сервисов независимо от способа их реализации. СОМ используется стандартный механизм.
В СОМ любая часть программного обеспечения реализует свои сервисы как один или несколько объектов СОМ.
Каждый такой объект поддерживает один или несколько интерфейсов, состоящих из методов.
Каждый метод — это процедура или функция, которая выполняет требуемое действие и может быть вызвана программным обеспечением, использующим данный объект (клиентом объекта).
Клиенты получают доступ к сервисам объекта СОМ только через вызовы методов интерфейсов объекта — у них нет непосредственного доступа к данным объекта.
Объект COM может поддерживать более одного интерфейса, например, объект COM, показанный на рис. ниже , имеет три интерфейса.
48. Экстремальное программирование
Экстремальное программирование (XP) – это упрощенная методология организации разработки программ для небольших и средних по размеру команд разработчиков, занимающихся созданием программного продукта в условиях неясных или быстро меняющихся требований.
Цели XP
Основными целями XP являются повышение доверия заказчика к программному продукту путем предоставления реальных доказательств успешности развития процесса разработки и резкое сокращение сроков разработки продукта. При этом XP сосредоточено на минимизации ошибок на ранних стадиях разработки. Это позволяет добиться максимальной скорости выпуска готового продукта и даёт возможность говорить о прогнозируемости работы. Практически все приемы XP направлены на повышение качества программного продукта.
Метод JSD Джексона
Метод JSD предназначен для анализа требований и проектирования систем, в которых важное значение имеет фактор времени. Такие системы могут быть описаны с использованием последовательности событий. Метод JSD базируется на положении о том, что проектирование систем является расширением проектирования ПС.
Существует два основных различия между методом JSD и другими методами разработки систем. Первое заключается в том, что начальной областью интересов метода JSD является область ПО. Вторая особенность – метод JSD базируется на последовательности событий.
Воснове применения метода JSD лежат три принципа:
● разработка системы должны начинаться с описания и моделирования предметной области, и только затем должно выполняться определение и структурирование функций, выполняемых системой;
● адекватная модель ориентированной на время предметной области сама должна быть время – ориентированной;
● реализация системы должна быть основана на преобразовании спецификации в эффективный набор процессов.
Дата добавления: 2018-08-06; просмотров: 379; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!