- •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. Перспективы развития технологий разработки программного обеспечения.
11. Назначение, особенности и построение диаграммы Activity.
Назначение диаграммы активности
Этот тип диаграмм может использоваться для моделирования различных типов действий. Например, финансовая компания может использовать данный тип диаграмм для моделирования потоков финансовых документов, прохождения оплаты счетов или заказов.
Особенности диаграммы активности
Activity diagram - это специальная разновидность диаграммы состояний (Statechart). В этом типе диаграмм большинство используемых знаков – это знаки активности, переходы между которыми вызваны завершением одних действий и началом других.
Главное отличие между Activity и Statechart diagram в том, что в первом случае основное действия, а во втором статичное состояние. При этом Activity diagram больше подходит для моделирования последовательности действий, a Statechart для моделирования дискретных состояний объекта.
Создание диаграммы активности
Для создания диаграммы Activity используются следующие инструменты:
Start State и End State – начало и окончание работы объекта соответственно.
State аналогичен такому же на диаграмме Statechart и предназначен для обозначения ситуации в течение жизни объекта, когда объект ожидает некоторое событие или находится в некотором состоянии.
Activity (активность) обозначает выполняемые задачи или выполнение определенных действий в течение жизни объекта.
State Transition (переход состояния) - переход из одного состояния в другое или по завершении выполнения определенного действия в начало другого. Этот значок также может характеризовать получение объектом некоторого сообщения с дальнейшей его обработкой.
Synchronizations (синхронизация) позволяет определить независимо выполняемые действия. При этом действия разделяются на несколько выполняемых независимо, и только по завершении всех действий объект продолжает работу. Этот значок представляет собой горизонтальную или вертикальную черту, обозначающую синхронизацию выполняемых работ.
Decision (решение) позволяет показать зависимость дальнейшей работы от внешних условий или решений. Этот значок аналогичен командам языка программирования if или case и может иметь больше двух выходов, но обычно используют выбор из двух переходов, определенных Булевым выражением.
Swimlanes позволяет моделировать последовательность действий различных объектов и связи между ними. При помощи этого элемента можно моделировать бизнес-процессы организации, отражая на диаграмме различные подразделения и объекты, играющие важные роли в модели бизнеса. Swimlanes позволяет показать, кто выполняет те или иные роли в процессе.
12. Назначение, особенности и построение диаграммы Sequence.
Назначение диаграммы
Кроме сценария поведения каждого объекта системы необходимо точно представлять взаимодействие этих объектов между собой, определение клиентов и серверов и порядка обмена сообщений между ними.
Обмен сообщениями происходит в определенной последовательности, и Sequence diagram позволяют получить отражение этого обмена во времени.
В течение работы сложной системы объекты, являющиеся клиентами, посылают друг другу различные сообщения, а объекты, являющиеся серверами, обрабатывают их. В простейшем случае можно рассматривать сообщение как вызов метода какого-либо класса, в более сложных случаях сервер имеет обработчик очереди сообщений, и сообщения им обрабатываются асинхронно.
Создание диаграммы Sequence
Для создания диаграммы Sequence используются следующие инструменты:
Object (объект) позволяет включить новый объект в диаграмму. Каждый объект является реализацией класса, поэтому в нем можно указать класс, на основе которого он создан.
Message (сообщение) позволяет создать сообщение, передаваемое от одного объекта к другому. Классы должны позволять отправку или прием сообщений.
Message to Self (сообщение самому себе) позволяет показать, что отправитель сообщения является одновременно и его получателем. В том случае, когда объект отправляет сообщение самому себе, он одновременно является и сервером и клиентом, что и отражает данный значок.
Return Message (возврат сообщения) позволяет показать, что происходит возврат управления из вызванной подпрограммы на сервере клиенту.
Destruction Marker (маркер уничтожения) позволяет показать, что происходит уничтожение программного объекта.
Свойства сообщений
RR позволяет задавать св-ва для инструмента Message. 2 группы:
Synchronization определяет порядок обмена сообщениями и может быть выбрана из следующих вариантов:
Simple - простая посылка сообщения;
Synchronous – операция происходит только в том случае, когда клиент посылает сообщение, а сервер может принять сообщение клиента;
Balking – операция происходит только в том случае, когда сервер готов немедленно принять сообщение, если сервер не готов к приему, клиент не выдает сообщение;
Timeout - клиент отказывается от выдачи сообщения, если сервер в течение определенного времени не может его принять;
Procedure Call - клиент вызывает процедуру сервера и полностью передает ему управление;
Return -- определяет, что происходит возврат из процедуры;
Asynchronous - клиент выдает сообщение, и, не ожидая ответа сервера, продолжает выполнение своего программного кода;
2. Frequency - определяет частоту обмена сообщениями:
Periodic – сообщения поступают от клиента с заданной периодичностью;
Aperiodic - сообщения поступают от клиента нерегулярно.
