Файл: Методические указания по организации практических занятий и самостоятельной работы по мдк. 02. 01 Технология разработки программного обеспечения.docx

Архитектура программной системы практически никогда не ограничена лишь одним архитектурным стилем, зачастую она является сочетанием архитектурных стилей, образующих полную систему. Например, может существовать SOA-дизайн, состоящий из сервисов, при разработке которых использовалась многослойная архитектура и объектно-ориентированный архитектурный стиль.

Рассмотрим основные базовые типы приложений:

1. Мобильные приложения. Приложения этого типа могут разрабатываться как тонкий клиент или насыщенное клиентское приложение. Насыщенные клиентские мобильные приложения могут поддерживать сценарии без постоянного подключения или без подключения вообще. Веб-приложения или тонкие клиентские приложения поддерживают только сценарии с подключением. Ограничением при разработке мобильных приложений могут быть устройства, на которых их предполагается выполнять.

2. Насыщенные клиентские приложения. Приложения этого типа обычно разрабатываются как самодостаточные приложения с графическим пользовательским интерфейсом, который обеспечивает отображение данных с помощью набора элементов управления. Насыщенные клиентские приложения могут поддерживать сценарии без подключения или без постоянного подключения, если должны выполнять доступ к удаленным данным или функциональности.

3. Насыщенные Интернет-приложения. Приложения этого типа могут поддерживать множество платформ и браузеров. Насыщенные Интернет-приложения выполняются в изолированной программной среде браузера, которая ограничивает доступ к некоторым возможностям клиента.

4. Сервисные приложения. Сервисы предоставляют бизнес-функциональность для совместного использования и позволяют клиентам доступ к ней из локальной или удаленной системы. Вызов операций сервиса осуществляется с помощью сообщений, соответствующих XML-схемам и передаваемых по транспортным каналам. Целью данного типа приложений является обеспечение слабой связанности между клиентом и сервером.

5. Веб-приложения. Приложения этого типа, как правило, поддерживают сценарии с постоянным подключением и различные браузеры, выполняющиеся в разнообразнейших операционных системах и на разных платформах.

6. Существует множество других более специализированных типов приложений. Как правило, эти типы являются специализациями или сочетаниями базовых типов, перечисленных в данном списке.

---

В таблице перечислены преимущества и недостатки общих архетипов приложений.

Тип приложения	Преимущества	Недостатки
Насыщенные клиентские приложения	Возможность использования ресурсов клиента. Лучшее время отклика, насыщенная функциональность UI и улучшенное взаимодействие с пользователем. Очень динамичное взаимодействие с коротким временем отклика. Поддержка сценариев без подключения и сценариев без постоянного подключения	Сложность развертывания; при этом широкий выбор вариантов установки, таких как ClickOnce, Windows Installer и XCOPY. Сложности обеспечения совместимости версий. Зависимость от платформы
Мобильные приложения	Поддержка портативных устройств. Доступность и простота использования для мобильных пользователей. Поддержка сценариев без подключения и сценариев без постоянного подключения	Ограниченные возможности ввода и навигации. Ограниченная область отображения экрана
Насыщенные Интернетприложения (RIA)	Такие же насыщенные возможности пользовательского интерфейса, как и для насыщенных клиентов. Поддержка насыщенных и потоковых мультимедиа и графики. Простота развертывания с возможностями распределения (насыщенными) такими же, как и для Веб-клиентов. Простота обновления и смены версий. Поддержка различных платформ и браузеров	Больший объем памяти, занимаемый на клиенте, по сравнению с Веб-приложением. Ограниченное использование ресурсов клиента по сравнению с насыщенным клиентским приложением. Необходимость развертывания на клиенте подходящей среды выполнения
Сервисные приложения	Слабо связанное взаимодействие между клиентом и сервером. Могут использоваться различными и невзаимосвязанными приложениями. Поддержка для обеспечения возможности взаимодействия	Отсутствие поддержки UI. Зависимость от возможности сетевого подключения
Веб-приложения	Широко доступный и основанный на стандартах UI, поддерживаемый на многих платформах. Простота развертывания и внесения изменений	Необходимость устойчивого сетевого подключения. Сложно обеспечить насыщенный пользовательский интерфейс

---

Каждый тип приложения может быть реализован с использованием одной или более технологий. Выбор технологии будет определяться сценариями и ограничениями технологий, а также возможностями и опытом группы разработки.
Изучение работы в системе контроля версий

Система контроля версий Git представляет собой набор программ командной строки. Доступ к ним можно получить из терминала (в *nix) или из специальной консольной оболочки Git Bash (в Windows). Однако, работа ориентирована на применение графической надстройки TortoiseGit (аналог в Linux — RabbitVCS).

TortoiseGit работает не как отдельная программа, а встраивается в контекстные меню «Проводника» Windows. Вместе с Git для Windows поставляется также программа gitk (Git GUI) — она гораздо менее популярна и пользоваться ей не следует.
Методика выполнения

Построение архитектуры программного средства

Визуальное проектирование может быть осуществлено с помощью программ, поддерживающих базовые функции по построению диаграмм. Рассмотрим основные элементы, которые можно использовать для построения архитектуры в Microsoft Visio.

При разработке основные элементы можно взять из шаблонов «Программы и базы данных».



Дополнительно можно использовать элементы из шаблонов «Сеть».



При проектировании архитектуры используются блоки: «Процесс», «Объект», «Компонент», «Линия связи» и т. п.



Пример разработанной архитектуры приложения


Изучение работы в системе контроля версий

1. Отработать навыки использования хранилища на локальной машине.

1.1. Настроить Git, указав имя и e-mail разработчика для подписи commit-ов.

Указание. Диалог настроек вызывается пунктом TorotiseGit → Settings контекстного меню любого каталога, нужная вкладка называется «Git». Задавать следует глобальные настройки (для всех хранилищ), установив переключатель «Global».

1.2. Создать хранилище для учебного проекта.

1.3. Совершить несколько commit-ов.

---

1.3.1. Скопировать sdt.h в каталог хранилища и создать файл main.cpp со включением sdt.h и пустой функцией main().

1.3.2. Добавить в программу ввод двух целых чисел с приглашением.

Указание № 1. После выполнения каждого подпункта необходимо убеждаться, что программа работает, и совершать commit изменений.

Указание № 2. Следите за тем, какие файлы отмечены в списке для commitа изменений в них, — кроме main.cpp и, иногда, sdt.h, больше никаких других не нужно.

1.4. Предотвратить автоматическое добавление в хранилище файлов, не нуждающихся в контроле версий, — *.o и *.exe.

Правило об игнорировании следует помещать в файл .gitignore в корневом каталоге хранилища («.gitignore in repository root»). Этот файл также попадает под контроль версий, поэтому после создания правил требуется совершить commit изменений в файле .gitignore.

1.5. Добавить в программу вывод суммы введенных чисел и совершить commit.

1.6. Просмотреть историю (журнал) хранилища.

1.7. Просмотреть разность (diff) между пунктами истории 1.3.2 и 1.5.

2. Освоить передачу истории хранилища по сети.

2.1. Организовать общее хранилище на удаленном сервере.

2.1.1. Зарегистрироваться на GitHub.

2.1.2. Создать пустое удаленное хранилище с любым наименованием.

Указание. Вопреки инструкции на GitHub, добавлять в хранилище файл README.md не нужно, удаленное хранилище должно быть пустым.

2.1.3. Разрешить пользователям-преподавателям совершать commit-ы.

Требуется на странице хранилища выбрать «Settings» (справа), далее «Collaborators», где ввести имена пользователей, которым будет предоставлен полный доступ к хранилищу (эти имена можно узнать у лаборантов).

2.1.4. Настроить локальное хранилище для синхронизации с удаленным.

Необходимо в контекстном меню каталога локального хранилища выбрать TortoiseGit → Settings, где перейти к пункту Remote . Достаточно ввести условное имя удаленного хранилища «origin» и его адрес, который отображается на webстранице удаленного хранилища в разделе «Quick setup» (вариант HTTP).

От загрузки сведений о ветвлениях в удаленном хранилище отказаться.

2.2. Передать локальное хранилище на удаленный сервер (push).

Замечание. Здесь и далее при взаимодействии с удаленным сервером потребуется вводить имя пользователя и пароль, с которыми выполнялась регистрация на GitHub.

2.3. Перейти к странице хранилища на GitHub (обновить её) и ознакомиться с возможностями просмотра содержимого через web-интерфейс.

---

2.4. Загрузить копию удаленного хранилища на локальную машину (clone).

Замечание. Целью является имитация совместной работы с удаленным хранилищем. Для этого на одной машине организуются 2 локальных хранилища: созданное в пункте 1.1 (RepoA) и загруженное с удаленного сервера (RepoB).

Указание. Диалог «Git clone» следует вызывать из контекстного меню каталога вне локального хранилища. В качестве URL потребуется указать адрес удаленного хранилища, а в качестве Directory — имя каталога для нового локального хранилища.

2.5. Сымитировать параллельную работу над проектом.

2.5.1. В локальном хранилище RepoB добавить в программу печать разности введенных чисел, сделать commit и передать изменения на сервер.

2.5.2. В локальном хранилище RepoA добавить над функцией main() комментарий о том, что программа является учебной, сделать commit, но не отправлять изменений на сервер.

2.6. На странице хранилища на GitHub перейти в раздел Commits и ознакомиться с возможностью просмотра истории изменений через web-интерфейс.

2.7. В локальном хранилище RepoA выполнить загрузку с сервера новейшихветвлений и изменений (fetch) и просмотреть журнал хранилища.

Указание. По умолчанию показывается только текущая активная ветвь (по умолчанию — master). Просмотреть все commit-ы во всех ветвях, в том числе в загруженной из удаленного хранилища ветви origin/master, нужно включить флажок «All branches» слева снизу окна журнала.

2.8. Совместить изменения в локальном хранилище с загруженными.

2.8.1. Использовать действие pull для загрузки изменений с удаленного сервера и автоматического совмещения их с имеющимися локально.

Просмотреть журнал изменений (или обновить кнопкой Refresh).

Примечание. Фактически, при обновлении производится слияние ветвей masterи origin/master — то есть, двух версий истории, существовавших удаленно и локально. При этом история стала нелинейной и появился лишний commit слияния. Иногда такое усложнение имеет смысл, но в данном случае было бы желательно сохранить историю линейной и просто перенести локальные наработки вслед за новейшими. Добьемся желаемого.

2.8.2. Отменить неудобный результат действия pull.

Указание. В журнале изменений в контекстном меню commit-а, где был добавлен комментарий (то есть, последнего перед слиянием), выбрать «Reset master to this…» и указать тип отмены «Hard».

Указание. Журнал изменений не всегда обновляется автоматически, используйте кнопку Refresh, если изменения не появились сразу.

2.8.3. Выполнить перенос (rebase) локальных изменений на основу новейшего загруженного состояния проекта.

---