Является итеративным и инкрементным.
Итеративнымназывается процесс, который предполагает управление потоком исполняемых версий системы.
Инкрементныйпроцесс подразумевает постоянное развитие системной архитектуры при выпуске новых версий, причем каждая следующая версия усовершенствована в сравнении с предыдущей.
Процесс, являющийся одновременно итеративным и инкрементным, называется управляемым рисками.
Фазы RUP:
Фаза начала проекта.Основная цель этой фазы – достичь компромисса между всеми заинтересованными лицами относительно задач проекта и выделяемых на него ресурсов. На этой стадии определяются основные цели проекта, руководитель и бюджет, основные средства выполнения – технологии, инструменты, ключевые исполнители. Также, возможно, происходит апробация выбранных технологий, чтобы убедиться в возможности достичь целей с их помощью, и составляются предварительные планы проекта. На эту фазу может уходить около 10% времени и 5% трудоемкости одного цикла.
Фаза проектирования. Основная цель этой фазы – на базе основных, наиболее существенных требований разработать стабильную базовую архитектуру продукта, которая позволяет решать поставленные перед системой задачи и в дальнейшем используется как основа разработки системы. На эту фазу может уходить около 30% времени и 20% трудоемкости одного цикла.
Фаза построения.Основная цель этой фазы – детальное прояснение требований и разработка системы, удовлетворяющей им, на основе спроектированной ранее архитектуры. В результате должна получиться система, реализующая все выделенные варианты использования. На эту фазу уходит около 50% времени и 65% трудоемкости одного цикла.
|
|
|
Фаза внедрения. Цель этой фазы – сделать систему полностью доступной конечным пользователям. На этой стадии происходит развертывание системы в ее рабочей среде, бета-тестирование, подгонка мелких деталей под нужды пользователей. На эту фазу может уходить около 10% времени и 10% трудоемкости одного цикла.
Дисциплины RUP:
Моделирование предметной области (бизнес-моделирование). Задачи этой деятельности – понять предметную область или бизнес-контекст, в которых должна будет работать система, и убедиться, что все заинтересованные лица понимают его одинаково, осознать имеющиеся проблемы, оценить их возможные решения и их последствия для бизнеса организации, в которой будет работать система. В результате моделирования предметной области должна появиться ее модель в виде набора диаграмм классов (объектов предметной области) и деятельностей (представляющих бизнес-операции и бизнес-процессы). Эта модель служит основой модели анализа. описывается структура и динамика организации
|
|
|
Определение требований. Задачи – понять, что должна делать система, и убедиться во взаимопонимании по этому поводу между заинтересованными лицами, определить границы системы и основу для планирования проекта и оценок затрат ресурсов в нем. Требования принято фиксировать в виде модели вариантов использования. описывается основанный на прецедентах метод постановки требований
Анализ и проектирование. Задачи – выработать архитектуру системы на основе требований, убедиться, что данная архитектура может быть основой работающей системы в контексте ее будущего использования. В результате проектирования должна появиться модель проектирования, включающая диаграммы классов системы, диаграммы ее компонентов, диаграммы взаимодействий между объектами в ходе реализации вариантов использования, диаграммы состояний для отдельных объектов и диаграммы развертывания. описываются различные виды архитектуры системы
Реализация.Задачи – определить структуру исходного кода системы, разработать код ее компонентов и протестировать их, интегрировать систему в работающее целое. собственно разработка программ, автономное тестирование и интеграция
|
|
|
Тестирование. Задачи – найти и описать дефекты системы (проявления недостатков ее качества), оценить ее качество в целом, оценить выполнены или нет гипотезы, лежащие в основе проектирования, оценить степень соответствия системы требованиям. описываются тестовые сценарии, процедуры и метрики для измерения числа ошибок
Развертывание. Задачи – установить систему в ее рабочем окружении и оценить ее работоспособность на том месте, где она должна будет работать. охватывает конфигурирование поставляемой системы
Управление конфигурациями и изменениями. Задачи – определение элементов, подлежащих хранению в репозитории проекта и правил построения из них согласованных конфигураций, поддержание целостности текущего состояния системы, проверка согласованности вносимых изменений. управление изменениями и поддержание целостности артефактов проекта
Управление проектом. Задачи – планирование, управление персоналом, обеспечение взаимодействия на благо проекта между всеми заинтересованными лицами, управление рисками, отслеживание текущего состояния проекта. описывает разные стратегии работы с итеративным процессом
Управление средой проекта. Задачи – подстройка процесса под конкретный проект, выбор и замена технологий и инструментов, используемых в проекте. рассматриваются вопросы инфраструктуры, необходимой для разработки системы
|
|
|
Модели RUP:
• модель бизнес-процессов – формализует абстракцию организации;
• модель предметной области – формализует контекст системы;
• модель вариантов использования– формализует функциональные требования к системе;
• модель анализа– формализует идею проекта;
• модель проектирования – формализует словарь предметной области и области решения;
• модель процессов (необязательная) – формализует механизмы параллелизма и синхронизации в системе;
• модель развертывания – формализует топологию аппаратных средств, на которых выполняется система;
• модель реализации – описывает части, из которых собирается физическая система;
• модель тестирования – формализует способы проверки и приемки системы.
Технические артефакты:
• группа требований – описывает, что система должна делать. В составе этих артефактов могут быть модели прецедентов, нефункциональных требований, предметной области и иные формы выражения потребностей пользователя, в том числе макеты, прототипы интерфейсов, юридические ограничения и т.д.
• группа проектирования– описывает, как система должна быть построена с учетом ограничений по времени и бюджету, наличия унаследованных систем, повторного использования, требований к качеству и т.д. Сюда относятся проектная модель, модель тестирования и иные формы выражения потребностей пользователя, в том числе прототипы и исполняемые архитектуры.
• группа реализации– описывает сборку разработанных программных компонентов. К группе реализацииотносится вся информация о программных элементах, из которых состоит система, в том числе исходный код на различных языках программирования, конфигурационные файлы, файлы данных, программные компоненты и т.д., а также информация о том, как собирать систему.
• группа развертывания– содержит все данные, необходимые для конфигурирования предоставленной системы. Группа развертываниясообщает о том, как программный комплекс разбит на пакеты, в каком виде он поставляется, как устанавливается и запускается на площадке заказчика.
11. Управление риском
Влияние риска вычисляют по выражению: RE = P(UO) x L(UO), где:
RE – показатель риска (Risk Exposure– подверженность риску);
P (UO) – вероятность неудовлетворительного результата (Unsatisfactory Outcome);
L (UO – потеря при неудовлетворительном результате.
Управление риском включает шесть действий:
1. Идентификация риска – выявление элементов риска в проекте.
2. Анализ риска – оценка вероятности и величины потери по каждому элементу риска.
3. Ранжирование риска – упорядочение элементов риска по степени их влияния.
4. Планирование управления риском – подготовка к работе с каждым элементом риска.
5. Разрешение риска – устранение или разрешение элементов риска.
6. Наблюдение риска – отслеживание динамики элементов риска, выполнение корректирующих действий.
12. Принципы объектно-ориентированного представления программных систем.
Декомпозиция программных систем:
В основе алгоритмической декомпозиции лежит разбиение по действиям – алгоритмам. Эта схема представления применяется в обычных ПС.
Объектно-ориентированная декомпозиция обеспечивает разбиение по автономным лицам – объектам реального (или виртуального) мира. Эти лица (объекты) – более «крупные» элементы, каждый из них несет в себе и описания действий, и описания данных.
Абстрагирование:
Абстрагирование сводится к формированию абстракций.
Каждая абстракция фиксирует основные характеристики объекта, которые отличают его от других видов объектов и обеспечивают ясные понятийные границы.
Абстракция концентрирует внимание на внешнем представлении объекта, позволяет отделить основное в поведении объекта от его реализации.
Инкапсуляция:
Инкапсуляция и абстракция – взаимодополняющие понятия: абстракциявыделяет внешнее поведение объекта,аинкапсуляциясодержит и скрывает реализацию, которая обеспечивает это поведение.
Инкапсуляция достигается с помощью информационной закрытости. Обычно скрываются структура объектов и реализация их методов.
Инкапсуляция является процессом разделения элементов абстракции на секции с различной видимостью.
Инкапсуляция служит для отделения интерфейса абстракции от ее реализации.Модульность:
Модульность –этосвойство системы, которая может подвергаться декомпозиции на ряд внутренне связанных и слабо зависящих друг от друга модулей.
Модуль– это фрагмент программного текста, являющийся строительным блоком для физической структуры системы.
Как правило, модуль состоит из интерфейсной части и части-реализации.
• Общая цель декомпозиции на модули – уменьшение сроков разработки и стоимости ПС за счет выделения модулей, которые проектируются и изменяются независимо.
• Каждая модульная структура должна быть достаточно простой, чтобы быть полностью понятой.
• Изменение реализации модулей должно проводиться без знания реализации других модулей и без влияния на их поведение.
Свойства модулей:
Информационная закрытость утверждает (автор – Д. Парнас, 1972): содержание модулей должно быть скрыто друг от друга.
Модуль должен определяться и проектироваться так, чтобы его содержимое (процедуры и данные) было недоступно тем модулям, которые не нуждаются в такой информации (клиентам).
Информационная закрытость означает следующее:
• все модули независимы, обмениваются только информацией, необходимой для работы;
• доступ к операциям и структурам данных модуля ограничен.
Связность модуля –это мера зависимости его частей.
Связность –внутренняя характеристика модуля.
Чем выше связность модуля, тем лучше результат проектирования.
Измерение связности – сила связности (СС):
Связность по совпадению (СС=0)
Логическая связность (СС=1)
Временная связность (СС=3)
Процедурная связность (СС=5)
Коммуникативная связность (СС=7)
Информационная (последовательная) связность (СС=9)
Функциональная связность (СС=10)
Сцепление – это мера взаимозависимости модулей по данным.
Сцепление – это внешняя характеристика модуля, которую желательно уменьшать.
Сцепление по данным (СЦ=1)
Сцепление по образцу (СЦ=3)
Сцепление по управлению (СЦ=4)
Сцепление по внешним ссылкам (СЦ=5)
Сцепление по общей области (СЦ=7)
Сцепление по содержанию (СЦ=9)
Иерархическая организация:
Иерархическая организация – это формирование из абстракций иерархической структуры.
Иерархическая организация задает размещение абстракций на различных уровнях описания системы.
Двумя важными инструментами иерархической организации в объектно-ориентированных системах являются:
• структура из классов («is а»-иерархия);
• структура из объектов («part of»-иерархия).
• 
• Иерархическая структура программной системы – это основной результат предварительного проектирования. Она определяет состав модулей ПС и управляющие отношения между модулями.
• В этой структуре модуль более высокого уровня (начальник) управляет модулем нижнего уровня (подчиненным).
• Первичные характеристики – количество вершин (модулей) и количество ребер (связей между модулями).
• Глобальные характеристики – высота и ширина.
• Локальными характеристиками модулей структуры являются коэффициент объединения по входу Fan_in(i) и коэффициент разветвления по выходу Fan_out(i).
• 13. Объекты.
• Объект –это конкретное представление абстракции.
• Объект обладает индивидуальностью, состоянием и поведением. Структура и поведение подобных объектов определены в их общем классе. Термины «экземпляр класса» и «объект» взаимозаменяемы.
• Индивидуальность – это характеристика объекта, которая отличает его от всех других объектов.
• Состояниеобъекта характеризуется перечнем всех свойств объекта и текущими значениями каждого из этих свойств.
• Поведениехарактеризует то, как объект воздействует на другие объекты (или подвергается воздействию) в терминах изменений его состояния и передачи сообщений.
• Виды операций клиента над объектом:
• 1) модификатор (изменяет состояние объекта);
• 2) селектор (дает доступ к состоянию, но не изменяет его);
• 3) итератор (доступ к содержанию объекта по частям, в строго определенном порядке);
• 4) конструктор (создает объект и инициализирует его состояние);
• 5) деструктор (разрушает объект и освобождает занимаемую им память).
• Протокол и логические группировки поведения:
• В общем случае все методы и свободные подпрограммы, ассоциированные с конкретным объектом, образуют его протокол.
• Протокол определяет оболочку допустимого поведения объекта и поэтому заключает в себе цельное (статическое и динамическое) представление объекта.
• Большой протокол полезно разделять на логические группировки поведения. Эти группировки, разделяющие пространство поведения объекта, обозначают роли, которые может играть объект.
• Обязанностиозначают обязательства объекта обеспечить определенное поведение. Обязанностями объекта являются все виды обслуживания, которые он предлагает клиентам.
• Виды отношений между объектами:
• Связь – это физическое или понятийное соединение между объектами. Объект сотрудничает с другими объектами через соединяющие их связи.
• Связь обозначает соединение, с помощью которого:
• объект-клиент вызывает операции объекта-поставщика;
• один объект перемещает данные к другому объекту.
• Как участник связи объект может играть одну из трех ролей:
• актер – объект, который может воздействовать на другие объекты, но никогда не подвержен воздействию других объектов;
• cервер – объект, который никогда не воздействует на другие объекты, он только используется другими объектами;
• агент – объект, который может как воздействовать на другие объекты, так и использоваться ими. Агент создается для выполнения работы от имени актера или другого агента.
• Различают четыре формы видимости между объектами:
• Объект-поставщик (сервер) глобален для клиента.
• Объект-поставщик (сервер) является параметром операции клиента.
• Объект-поставщик (сервер) является частью объекта-клиента.
• Объект-поставщик (сервер) является локально объявленным объектом в операции клиента.
• Агрегация обозначает отношения объектов в иерархии «целое/часть».
• Агрегация обеспечивает возможность перемещения от целого (агрегата) к его частям (свойствам).
• Агрегация может обозначать, а может и не обозначать физическое включение части в целое.
• 14. Классы.
• Класс –этоописание множества объектов, которые разделяют одинаковые свойства, операции, отношения и семантику (смысл). Любой объект – просто экземпляр класса.
• Интерфейсобъявляет возможности (услуги) класса, но скрывает его структуру и поведение.Интерфейс может быть разделен на 3 части:
• 1) публичную (public), объявления которой доступны всем клиентам;
• 2) защищенную (protected), объявления которой доступны только самому классу, его подклассам и друзьям;
• 3) приватную (private), объявления которой доступны только самому классу и его друзьям.
• Реализациякласса описывает секреты поведения класса. Она включает реализации всех операций, определенных в интерфейсе класса.
• Виды отношений между классами:
• Всего существует четыре основных вида отношений между классами:
• ассоциация (фиксирует структурные отношения – связи между экземплярами классов);
• зависимость (отображает влияние одного класса на другой класс);
• обобщение-специализация («is а»-отношение);
• целое-часть («part of»-отношение).
• Для покрытия основных отношений большинство объектно-ориентированных языков программирования поддерживает следующие отношения:
• Ассоциации – обеспечивают взаимодействия объектов, принадлежащих разным классам. Они являются клеем, соединяющим воедино все элементы программной системы. Благодаря ассоциациям мы получаем работающую систему. Без ассоциаций система превращается в набор изолированных классов-одиночек.
• Наследование– это отношение, при котором один класс разделяет структуру и поведение, определенные в одном другом (простое наследование) или во многих других (множественное наследование) классах.
• Агрегация – обеспечивает отношения целое-часть, объявляемые для экземпляров классов.
• Композиция– разновидность агрегации, графическое вложение символов частей в символ агрегата.
• Зависимость– это отношение, которое показывает, что изменение в одном классе (независимом) может влиять на другой класс (зависимый), который использует его.
• Конкретизация – это процесс наполнения шаблона (родового или параметризованного класса). Целью ее является получение класса, от которого возможно создание экземпляров.
• Родовой класс служит заготовкой, шаблоном, параметры которого могут наполняться (настраиваться) другими классами, типами, объектами, операциями. Процесс настройки родового класса называют конкретизацией.
• Метакласс– это класс классов, понятие, позволяющее обращаться с классами как с объектами. Отношения метаклассов поддерживаются в языках SmallTalk и CLOS.
• Реализация– определяет отношение, при котором класс-приемник обеспечивает свою собственную реализацию интерфейса другого класса-источника. Иными словами, здесь идет речь о наследовании интерфейса.
• 15. Диаграммы классов.
• Обозначения классов
• 
• Область действия
• 
• Свойства:
• Уровни видимости:
• Public - Любой клиент класса может использовать свойство
• (операцию), обозначается символом +
• protected - Любой наследник класса может использовать свойство
• (операцию), обозначается символом #
• private - Свойство (операция) может использоваться только самим классом, обозначается символом -
• Характеристика свойств:
• changeable - Нет ограничений на модификацию значения свойства
• addOnly - Для свойств с множественностью, большей единицы;
• дополнительные значения могут быть добавлены, но после
• создания значение не может удаляться или изменяться
• frozen - После инициализации объекта значение свойства не изменяется
• Операции:
• Значения элемента Направление
• in - Входной параметр, не может модифицироваться
• out - Выходной параметр, может модифицироваться для передачи информации в вызывающий объект
• inout - Входной параметр, может модифицироваться
• Значения характеристик операций
• leaf - Конечная операция, операция не может быть полиморфной и не может переопределяться (в цепочке наследования).
• isQuery - Выполнение операции не изменяет состояния объекта.
• sequential - В каждый момент времени в объект поступает только один вызов операций. Как следствие, в каждый момент времени выполняется только одна операция объекта. Другими словами, допустим только один поток вызовов (поток управления).
• guarded - Допускается одновременное поступление в объект нескольких вызовов, но в каждый момент времени обрабатывается только один вызов охраняемой операции. Т.е. параллельные потоки управления исполняются последовательно (за счет постановки вызовов в очередь).
• concurrent - В объект поступает несколько потоков вызовов операций (из параллельных потоков управления). Разрешается параллельное (и множественное) выполнение операции. Подразумевается, что такие операции являются атомарными.
• Организация свойств и операции:
• Множественность
• 
• Стереотипы для характеристик классов
• 
• 16. Отношения в диаграммах классов
• 
• Ассоциацииотображают структурные отношения между экземплярами классов, то есть соединения между объектами.
• Каждая ассоциация может иметь метку – имя, которое описывает природу отношения.
• Имени можно придать направление – достаточно добавить треугольник направления, который указывает направление, заданное для чтения имени.
• Имена ассоциаций:
• 
• Роли
• 
• Мощность
• 
• Варианты мощности:
• 5 — точно пять;
• * — неограниченное количество;
• 0..* — ноль или более;
• 1..* — один или более;
• 3..7 — определенный диапазон;
• 1..3, 7 — определенный диапазон или число.
• Квалификация
• 
• Видимость
• 
• Свойства ассоциаций:
• Класс-ассоциация
• 
• Свойства класса-ассоциации характеризуют не один, а пару объектов, в данном случае – пару экземпляров, Профессор и Университет.
• Обобщение –этоотношение между общим предметом (суперклассом) и специализированной разновидностью этого предмета (подклассом).
• Подкласс может иметь одного родителя (один суперкласс) или несколько родителей (несколько суперклассов). Во втором случае говорят о множественном наследовании.
• Множественное наследование
• 
• Зависимостьявляется отношением использования между клиентом (зависимым элементом) и поставщиком (независимым элементом).
• Обычно операции клиента:
• вызывают операции поставщика;
• имеют сигнатуры, в которых возвращаемое значение или аргументы принадлежат классу поставщика.
• Отношения зависимости
Реализация – этосемантическое отношение между классами, в котором класс-приемник выполняет реализацию операций интерфейса класса-источника.
Реализация интерфейса (LIFO – последний вошел, первый вышел; FIFO – первый вошел, первый вышел и т. д.)
В языке UML считаются разновидностями ассоциации, применяемыми для отображения структурных отношений между «целым» (агрегатом) и его «частями».
Агрегация показывает отношение по ссылке (в агрегат включены только указатели на части).
Композиция – этоотношение физического включения (в агрегат включены сами части).
Деревья наследования
Абстрактность и полиморфизм
Пример диаграммы классов
Автоматы.
Классификация динамических моделей объектно-ориентированных ПС
Автоматописывает поведение в терминах последовательности состояний, через которые проходит объект в течение своей жизни.
Автомат:
• задает поведение системы как цельной, единой сущности;
• моделирует жизненный цикл единого объекта;
• удобно применять для формализации динамики отдельного трудного для понимания блока системы.
Диаграммы схем состояний:
Диаграмма схем состояний отображает конечный автомат, выделяя
поток управления, следующий от состояния к состоянию.
Конечный автомат – это поведение, которое определяет
последовательность состояний в ходе существования объекта. Эта
последовательность рассматривается как ответ на события и включает
реакции на эти события.
Диаграммы взаимодействия.
Диаграмма схем состояний показывает:
• набор состояний системы;
• события, которые вызывают переход из одного состояния в другое;
• действия, которые происходят в результате изменения состояния.
Элементы диаграммы схем состояний:
• состояния;
• переходы между состояниями.
Действия в состояниях
Для указания действий, выполняемых при входе в состояние и при выходе из состояния, используются меткиentryиexitсоответственно.
Действие, которое должно выполняться, когда система находится в данном состоянии, указывается после меткиdo.
Условные переходы
Между состояниями возможны различные типы переходов:
• переход инициируемый событием;
• переходы без событий;
• условные или охраняемые переходы.
Порядок выполнения условного перехода:
• происходит событие;
• вычисляется условие [УсловиеПерехода];
• при [УсловиеПерехода] = true запускается переход и активизируется действие, в противном случае переход не выполняется.
Вложенные состояния:
Обозначение подсостояний
Переходы в состоянии Активна
Историческое состояние
Символ состояния со скрытыми подсостояниями
Диаграммы деятельности:
Диаграмма деятельностипредставляет особую форму конечного автомата, в которой показываются процесс вычислений и потоки работ. В ней выделяются не обычные состояния объекта, а состояния выполняемых вычислений – состояния действий. При этом полагается, что процесс вычислений не прерывается внешними событиями.
Переходы и вспомогательные вершины:
Переходы между вершинами – состояниями действий – изображаются в виде стрелок.
В диаграммах деятельности используются вспомогательные вершины:
• решение (ромбик с одной входящей и несколькими исходящими стрелками);
• объединение (ромбик с несколькими входящими и одной исходящей стрелкой);
• линейка синхронизации – разделение (жирная горизонтальная линия с одной входящей и несколькими исходящими стрелками);
• линейка синхронизации – слияние (жирная горизонтальная линия с несколькими входящими и одной исходящей стрелкой);
• начальное состояние (черный кружок);
• конечное состояние (не закрашенный кружок, в котором размещен черный кружок меньшего размера).
Плавательная дорожка – это определенная область, которая имеет имя и фиксирует область деятельности конкретного лица, обозначая зону его ответственности.
Диаграммы сотрудничества:
Диаграмма сотрудничества – это диаграмма взаимодействия, которая выделяет структурную организацию объектов, посылающих и принимающих сообщения.
Элементами диаграмм взаимодействия являются участники взаимодействия – объекты, связи, сообщения.
Алгоритм формирования диаграммы сотрудничества:
• отображаются объекты, которые участвуют во взаимодействии;
• рисуются связи, соединяющие эти объекты;
• связи помечаются сообщениями, которые посылают и получают выделенные объекты.
• Диаграммы последовательности:
Диаграмма последовательности системы управления полетом
Линия жизни объекта:
Линия жизни объекта – это вертикальная пунктирная линия, которая обозначает
период существования объекта:
• большинство объектов существуют на протяжении всего взаимодействия, их линии жизни тянутся от вершины до основания диаграммы;
• объекты могут создаваться в ходе взаимодействия и их линии жизни начинаются с момента приема сообщения «create»;
• объекты могут уничтожаться в ходе взаимодействия и их линии жизни заканчиваются с момента приема сообщения «destroy».
• Фокус управления:
Фокус управления –этовысокий тонкий прямоугольник, отображающий
период времени, в течение которого объект выполняет действие (свою или
подчиненную процедуру). Вершина прямоугольника отмечает начало действия, а
основание – его завершение. Момент завершения может маркироваться сообщением
возврата, которое показывается пунктирной стрелкой. Можно показать вложение
фокуса управления (например, рекурсивный вызов собственной операции).
Для отображения «условности» линия жизни может быть разделена на несколько параллельных линий жизни. Каждая отдельная линия соответствует условному ветвлению во взаимодействии
Ветвление показывается множеством стрелок, идущих из одной точки. Каждая стрелка отмечается сторожевым условием
Диаграммы USE CASE
Диаграмма Use Case определяет поведение системы с точки зрения пользователя. Она рассматривается как главное средство для первичного моделирования динамики системы, используется для выяснения требований к разрабатываемой системе, фиксации этих требований в форме, которая позволит проводить дальнейшую разработку. Диаграммы Use Case часто называют диаграммами прецедентов или вариантов использования.
В состав диаграмм Use Case входят элементы Use Case, актеры, отношения зависимости, обобщения и ассоциации, примечания и ограничения и пакеты.
Актер –это роль объекта вне системы, который прямо взаимодействует с ее частью–конкретным элементом (элементом Use Case).
Элемент Use Case –это описание последовательности действий (или нескольких последовательностей), которые выполняются системой и производят для отдельного актера видимый результат.
Отношение ассоциации между актером и элементом Use Case:
Отношение обобщения между актерами:
Отношение обобщения между элементами Use Case:
Пример диаграммы Use Case:
Компоненты диаграммы.
Компонентная диаграмма показывает организацию набора компонентов и зависимости между компонентами.
Компонент– этофизическая и заменяемая часть системы, которая соответствует набору интерфейсов и обеспечивает реализацию этого набора интерфейсов.
Сходные характеристики компонента и класса:
• наличие имени;
• реализация набора интерфейсов;
• участие в отношениях зависимости;
• возможность быть вложенным;
• наличие экземпляров (экземпляры компонентов можно
использовать только в диаграммах размещения).
Интерфейс – это список операций, которые определяют услуги класса или компонента.
С помощью интерфейсных разъемов компоненты стыкуются друг с другом, объединяясь в систему.
Представление интерфейса в форме пиктограммы
Развернутая форма представления интерфейса
Особенности компонента
Компонент физичен. Он живет в мире битов, а не логических понятий и не зависит от языка программирования
Компонент – заменяемый элемент. Свойство заменяемости позволяет заменить один компонент другим компонентом, который удовлетворяет тем же интерфейсам. Механизм замены оговорен современными компонентными моделями (СОМ, СОМ+, CORBA, Java Beans), требующими незначительных преобразований или предоставляющими утилиты, которые автоматизируют механизм.
Компонент является частью системы, он редко автономен. Чаще компонент сотрудничает с другими компонентами и существует в архитектурной или технологической среде, предназначенной для его использования. Компонент связан и физически, и логически, он обозначает фрагмент большой системы
Компонент соответствует набору интерфейсов и обеспечивает реализацию этого набора интерфейсов
Разновидности компонентов:
«executable» - Компонент, который может выполняться в физическом узле (имеет расширение .ехе)
«library» - Статическая или динамическая объектная библиотека (имеет расширение .dll)
«file» - Компонент, который представляет файл, содержащий исходный код или данные (имеет расширение .ini)
«table» - Компонент, который представляет таблицу базы данных (имеет расширение .tbl)
«document» - Компонент, который представляет документ (имеет расширение .hlp)
Дата добавления: 2018-02-15; просмотров: 982; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!