Диаграмма компонентов и диаграмма развёртывания uml.
Ответ: Диаграмма развертывания (Deployment diagram) – структурная диаграмма, на которой представлена конфигурация обрабатывающих узлов системы и размещенных в них компонентов.
Диаграмма развертывания (deployment diagram) отражает физические взаимосвязи между программными и аппаратными компонентами разрабатываемой системы. Эта диаграмма является хорошим средством для представления маршрутов перемещения объектов и компонентов в распределенной системе.
Каждый узел на диаграмме развертывания представляет собой некоторый тип вычислительного устройства - в большинстве случаев самостоятельную часть аппаратуры. Эта аппаратура может быть как простым устройством или датчиком, так и мэйнфреймом.
Диаграммы развертывания относятся к статическому виду архитектуры системы с точки зрения развертывания. Они связаны с диаграммами компонентов, поскольку в узле обычно размещаются один или несколько компонентов.
Рис. 1 Диаграмма развертывания
Диаграмма компонентов, Component diagram — статическая структурная
диаграмма, показывает разбиение программной системы на структурные
компоненты и связи (зависимости) между компонентами. В качестве
физических компонент могут выступать файлы, библиотеки,
модули, исполняемые файлы, пакеты.
Компонент представляет собой физический модуль программного кода. Компонент часто считают синонимом пакета, но эти понятия могут отличаться, поскольку компоненты представляют собой физическое объединение программного кода. Хотя отдельный класс может быть представлен в целой совокупности компонентов, этот класс должен быть определен только в одном пакете. Например, класс Строка в языке Java является частью пакета java.lang, но он может быть обнаружен в ряде компонентов.
Зависимости между компонентами показывают, как изменения одного компонента могут повлиять на изменение других компонентов. Существует довольно ограниченное количество видов зависимостей, которые можно использовать, включая зависимости типа связь и компиляция.
Хотя диаграммы развертывания и диаграммы компонентов можно изображать отдельно, также допускается помещать диаграмму компонентов на диаграмму развертывания. Это целесообразно делать, чтобы показать какие компоненты выполняются и на каких узлах.
Непрерывная интеграция и основные этапы интеграции.
Ответ: Непрерывная интеграция (англ. Continuous Integration) – это практика разработки программного обеспечения, которая заключается в выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем. В обычном проекте, где над разными частями системы разработчики трудятся независимо, стадия интеграции является заключительной. Она может непредсказуемо задержать окончание работ. Переход к непрерывной интеграции позволяет снизить трудоёмкость интеграции и сделать ёё более предсказуемой за счет наиболее раннего обнаружения и устранения ошибок и противоречий. Практика частой сборки (интеграции) проекта удачно сочетается проведением модульного (unit) тестирования.
Типы сборок:
- редкие сборки под конкретные релизы
- ночные сборки
- непрерывные сборки
Требования к проекту:
Исходные коды и все, что необходимо для сборки и тестирования проекта, хранится в репозитории системы управления версиями;
Система управления версиями или система контроля версий(от англ. Version Control System или Revision Control System) — программное обеспечение для облегчения работы с изменяющейся информацией. Система управления версиями позволяет хранить несколько версий одного и того же документа, при необходимости, возвращаться к более ранним версиям, определять, кто и когда сделал то или иное изменение и многое другое. Такие системы широко применяются при разработке программного обеспечения, для хранения исходных кодов разрабатываемой программы
Распространённые системы управления версиями:
- Subversion
- CVS
- Microsoft Visual SourceSafe
- Microsoft Team Foundation
- Rational ClearCase
Процесс CI:
Практика continuous integration не требует никакого технического и программного обеспечения, но гораздо удобнее, проще и дешевле наладить процесс CI с использованием подобных специальных средств. Такие средства называются сервера интеграции (continuous integration server)- специализированные приложения для автоматизации данного процесса.
Наиболее известный из серверов интеграции пожалуй CruiseControl. CruiseControl это сервер для интеграции приложений на java, написанный на java. Так же широко распространен его собрат (точнее портированная версия) под .NET – CruiseControl.NET, интересен Team City от питерской компании JetBrains.
Итак, для организации процесса CI на выделенном сервере организуется служба, запускающая сборку по триггеру:
- внешнему запросу,
- по расписанию,
- по факту обновления репозитория.
Основные этапы CI в CruiseControl:
1) Trigger - триггер срабатывания Цикл интеграции начинается со срабатывания триггера. Это может быть одно из следующего:
a) изменение в системе контроля версий, зафиксирован факт обновления репозитория;
b) изменение в файловой системе;
c) по расписанию в определенный момент времени;
d) сборка другого проекта;
e) нажата «красная» кнопка, внешний запрос;
f) и др. например, изменение на веб сервере др.;