- •Лаба № 2
- •Что такое «система» с точки зрения объектно-ориентированного проектирования?
- •Поясните определение «архитектура» информационной системы согласно iso/iec/ieee 42010:2011.
- •Поясните основные понятия и их взаимосвязь: архитектура, архитектура инфраструктуры, информационная архитектура, архитектура предприятия, управление архитектурой.
- •Поясните основные определения: архитектор, архитектурный артефакт, архитектурное описание, архитектурная структура.
- •Поясните основные понятия и их взаимосвязь: архитектурная методология, архитектурный процесс, архитектурная таксономия.
- •Какая диаграмма создается на первом этапе проекта и для чего она нужна?
- •Поясните назначение Модели прецедентов системы (Use Case Diagrams (ucDs) model) в архитектурном описании.
- •Перечислите и поясните семантику элементов на ucd: границы системы, заинтересованные лица – стейкхолдеры – актеры, типы отношений: ассоциации, зависимости, обобщения.
- •Поясните что такое высокоуровневые требования и элементы-требования, их назначение, содержание и документирование.
- •Поясните назначение, взаимосвязь и основное отличие Модели прецедентов системы и Модели требований, а также дальнейшее использование архитектурного описания данного уровня.
- •Какую возможность дает трассировка требований?
- •Поясните связь между информационной архитектурой, высокоуровневыми требованиями и юзабилити.
- •Лаба № 3
- •Поясните понятие «архитектура программной системы (пс)», назначение и содержание уровней описания архитектуры: концептуальный, логический, физическая реализация.
- •Поясните назначение и основные принципы разработки сервис-ориентированной архитектуры (soa).
- •Поясните назначение концептуальных диаграмм, отражающая архитектуру системы mm Architecture Structure, их элементы, а также особенности их размещения в браузере проекта.
- •Лаба № 4
- •Перечислите и поясните семантику элементов диаграмм.
- •Поясните понятие объекта в аспекте архитектурного проектирования.
- •Поясните особенности портов Provided Interfaces, Required Interfaces и назначение меток, например, lollipop («чупа-чупс») и socket («разъём»).
- •Поясните особенности Behavioral port и Reversed port.
- •Поясните технологию работы с портами на диаграммах и особенности размещения в браузере проекта.
- •Лаба № 5
- •Лаба № 6
- •1.Перечислите диаграммы, описывающие поведение и поясните их назначение для блоков и частей подсистем в архитектурном описании.
- •2.Перечислите и поясните семантику элементов Activity diagrams.
- •3.Поясните понятие блока и части в аспекте архитектурного проектирования.
- •4.Поясните технологию работы с основными элементами диаграммы и особенности размещения их в браузере проекта.
- •5.Поясните назначение детальной проработки и логику действий элементов диаграммы mmCallControl.
- •6.Поясните элемент диаграммы Action и его основное отличие от Activity, Subactivity и Actionbloc.
- •7.Самостоятельно разберитесь и поясните назначение элементов Send Action, Accept Event Action, Accept Time Event, Call Behavior, Call Operation, и Subactivity.
- •8.Поясните особенности использования элементов Object Node, Join Node, Fork Node и элементов Initial Flow, Control Flow, Object Flow.
- •9.Проработайте детально и поясните логику действий элементов диаграммы для Location.
- •10.Проработайте детально и поясните логику действий элементов диаграммы для Registration.
Поясните назначение Модели прецедентов системы (Use Case Diagrams (ucDs) model) в архитектурном описании.
Проектирование UCD осуществляется с целью выявления требований в области проблем которые отражают требования пользователей к основным функциям разрабатываемой системы (Functional Overview). В данном примере это, прежде всего требования к использованию мобильной связи, в том числе к функциям телефонной трубки.
Перечислите и поясните семантику элементов на ucd: границы системы, заинтересованные лица – стейкхолдеры – актеры, типы отношений: ассоциации, зависимости, обобщения.
Ассоциация- представляет собой связь между актерами и соответствующими прецедентами.
Зависимость (Dependency) – это прямая связь, в которой функция элемента требует присутствия и может изменить другой элемент.
Обобщение (Generalizations) – это связь между общим и более конкретным элементом. Более конкретный элемент наследует свойства общего элемента и замещает его. Обобщение позволяет извлечь один прецедент из другого.В данном случае отношение обобщения указывает, что прецедент Supplementary Service (Предоставить дополнительные сервисы) (более конкретно осуществление и прием вызовов) извлекается из прецедента Place Call (Принять вызов вызов) и прецедента Receive Call (Осуществить вызов).
Поясните что такое высокоуровневые требования и элементы-требования, их назначение, содержание и документирование.
Высокоуровневые требования - требования на концептуальном (верхнем) уровне, в области проблем, иначе, требования к использованию мобильной связи, в том числе к функциям телефонной трубки (Functional Overview). Являются откликом системы и отвечают на вопрос: "Что должна сделать система, чтобы выполнить заявленные требования?". В данном примере это требования к реализации основных функции системы для Осуществления вызова (Place Call Overview).
Элементы-требования – это текстовые пояснения, описывающие назначение элемента.
Поясните назначение, взаимосвязь и основное отличие Модели прецедентов системы и Модели требований, а также дальнейшее использование архитектурного описания данного уровня.
Модель прецедентов (UCDs model) является графической Моделью требований, и декларирует высокоуровневые функциональные требования к разрабатываемой системе.
UCDs model преследует следующие три основные цели:
выявление требований в области проблем: отражают требования пользователей к основным функциям разрабатываемой системы (Functional Overview). В данном примере это требования к использованию мобильной связи, в большей степени к функциям телефонной трубки;
выявление требований в области проблем: отражают основные функциональные требования к разрабатываемой системе, иначе отвечают на вопрос «Что должна сделать система, чтобы выполнить заявленные требования пользователей?», что согласуется с положениями SOA, являясь, таким образом, откликом системы. В данном примере это требования к реализации основных функции системы для осуществления вызова (Place Call Overview);
выявление требований в области решений: отражают требования к реализации функциональных требования к разрабатываемой системе в контексте выявленных требований в области проблем. В данном примере это требования к осуществлению передачи различного рода данных (Data Call Requirements).