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

Указание. В журнале изменений в контекстном меню пункта, на котором находится конец ветви origin/master (прямоугольник в TortoiseGit), следует выбрать пункт «Rebase "master" ontothis…» и далее нажать кнопку «Startrebase».

2.9. Передать итоговое состояние локального хранилища RepoA на удаленный сервер, используя команду push.

2.10. Действуя аналогично п. п. 2.7 и 2.8.3, синхронизировать с удаленным локальное хранилище RepoB (в нем не хватает commit-а с комментарием).

Замечание. На данном этапе во всех трех хранилищах (локальных RepoA и RepoBи удаленном на GitHub) должна быть одинаковая линейная история из пяти — шести commit-ов.

3. Изучить действия, связанные с ветвлениями и разрешением конфликтов.

Замечание. Все действия выполняются в одном локальном хранилище, например, в RepoA.

3.1. Добавить в программу печать произведения чисел и совершите commit.

На данном этапе программа может быть такой:



3.2. Создать новую ветвь (branch) под названием division. из пункта истории, в котором был добавлен комментарий над main().

3.3. В новой ветви повторить пункт 3.1, заменив умножение делением.

Указание. Переключиться на ветвь можно, выбрав в контекстном меню commit-а, которым эта ветвь оканчивается, пункт «Switch/checkout to this». При создании ветви можно сразу установить флажок «Switch to new branch». Переключаться можно только при чистом (clean) хранилище, то есть, без изменений в рабочей копии.

3.4. Переключиться обратно на ветвь master.

3.5. Выполнить слияние ветви division в ветвь master так, чтобы в последней оказался код для печати и произведения, и частного.

3.5.1. В журнале изменений в контекстном меню пункта-окончания ветви division выбрать пункт «Merge into "master"…» и начать слияние, не меняя настроек.

Действие завершится ошибкой из-за конфликта (conflict): в файле main.cpp строка 10 изменена в обоих commit-ах одинаково, а строка 11 — по-разному, и СКВ не может автоматически выбрать «правильный» вариант. Требуется вручную указать, какие строки должны войти в итоговую версию файла.

3.5.2. Приступить к разрешению конфликта.

Указание. Следует нажать кнопку Resolve (снизу), а затем выбрав пункт Edit conflicts из контекстного меню main.cpp.

Примечание. Редактор конфликтов похож на программу для просмотра разностей между файлами: слева показывается файл в ветви, откуда делается слияние (division), справа — ветви, куда делается слияние (master), снизу — результат слияния. Знаками равенства в соседних верхних полях отмечаются не только строки, оставшиеся неизменными, но и строки с одинаковыми изменениями: здесь, в строке 10 убрана точка с запятой в конце в обеих ветвях.

---

В нижнем поле каждый восклицательный знак обозначает отдельный конфликт. Примерный вид окна редактирования конфликтов представлен на рисунке ниже


3.5.3. Разрешить конфликты:

— в качестве строки 10 предпочесть строку 10 любой ветви;

— на место строки 11 вставить 2 строки: строку с печатью произведения и строку с печатью частного;

— лишнюю точку с запятой на строке 11 поля-результата удалить.

Указание. Переносить строки из той или иной версии в итоговую можно, выбирая конфликтные блоки в левом или правом верхнем поле (простым щелчком левой кнопкой мыши) и пользуясь контекстным меню. Например, «Usethistextblock» переносит выбранный блок в поле-результат; пункт «Use text block from 'mine' before 'theirs'» переносит в результат 2 строки: сначала из правого блока, потом из левого (одну под другой). На рисунке ниже показан возможный верный результат



3.5.4. Завершить процедуру разрешения конфликтов.

Указание. Следует нажать на кнопку «Mark as resolved», чтобы отметить файл как избавленный от конфликтов, и закрыть программу для их разрешения.

3.5.5. Завершить слияние ветви division в ветвь master, написав осмысленный комментарий к слиянию и совершив commit.

3.5.6. Убедиться, что программа компилируется и верно работает. Если это не так, исправить все ошибки и добиться правильной работы. Совершить commit.

Замечание-указание. Ситуация, когда после слияния программа все-таки оказывается не вполне корректной, случается на практике довольно часто. В этом случае commit, созданный при слиянии, оказывается логически неправильным, он не имеет ценности без последующего исправления. В Git имеется возможность изменить (amend) уже совершенный commit, пока он не передан на сервер. Это делается при следующем commit-исправлении: следует установить флажок «Amend Last Commit» в диалоге commit — нового commit не появится, а вместо этого изменения будут приписаны предыдущему пункту истории. Можно воспользоваться данной возможностью при выполнении пункта

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

Указание. По умолчанию передаются только изменения текущей ветви, для передачи изменений всех ветвей следует отметить флажок «Push all branches» диалога push.

---

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

В соответствии с индивидуальным вариантом, определить и описать особенности реализации системы (подходы, технологии и т. п.). На основе описанных особенностей системы обосновать выбор вида архитектуры, наиболее подходящей для реализации данной системы. Произвести визуальное проектирование архитектуры системы (рекомендуется использовать программу Microsoft Visio). Добавить текстовое описание к архитектуре, поясняющее ее структуру и связи.

Перечень индивидуальных вариантов приведен в приложении А.

В соответствии с индивидуальным вариантом разработать программу на любом известном языке программирования. Добавить ее в систему контроля версий и отследить изменения.

Перечень индивидуальных вариантов приведен в приложении В.
Контрольные вопросы

1. 
   Что подразумевается под созданием архитектуры приложения?
   
2. 
   Каково основное назначение архитектуры приложения?
   
3. 
   Перечислите основные принципы разработки архитектуры программного обеспечения.
   
4. 
   Перечислите основные типовые архитектурные стили.
   
5. 
   Перечислите основные архетипы приложений.
   
6. 
   Перечислите основные элементы, которые можно использовать для построения архитектуры программного обеспечения.
   
7. 
   Что такое системы контроля версий (СКВ) и для решения каких задач они
   
8. 
   предназначаются?
   
9. 
   Объясните следующие понятия СКВ и их отношения: хранилище, commit, история,
   
10. 
    рабочая копия.
    
11. 
    Что представляют собой и чем отличаются централизованные и децентрализованные
    
12. 
    СКВ? Приведите примеры СКВ каждого вида.
    
13. 
    Опишите действия с СКВ при единоличной работе с хранилищем.
    
14. 
    Опишите порядок работы с общим хранилищем в централизованной СКВ.
    
15. 
    Что такое и зачем может быть нужна разность (diff)?
    
16. 
    Что такое и зачем может быть нужно слияние (merge)?
    
17. 
    Что такое конфликты (conflict) и каков процесс их разрешения (resolve)?
    
18. 
    Поясните процесс синхронизации с общим хранилищем («обновления»)
    
19. 
    в децентрализованной СКВ.
    
20. 
    Что такое и зачем могут быть нужны ветви (branches)?
    
21. 
    Объясните смысл действия rebase в СКВ Git.
    
22. 
    Как и зачем можно игнорировать некоторые файлы при commit?
    

---

---

Практическая работа №3

Построение функциональных диаграмм IDEF0 и диаграмм потоков данных DFD
Цель: получение навыков создания и редактирования функциональных моделей в нотации IDEF0. Изучение основных характеристик и основ работы с DFD-моделями в графическом редакторе.
Форма отчета:

Функциональная диаграмма IDEF0 и диаграмма потоков данных DFD с описанием процесса построения диаграмм.
Краткие теоретические сведения

Функциональная диаграмма IDEF0

1. Основные сведения по методологии IDEF0

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

Цель моделирования. Модель не может быть построена без четко сформулированной цели. Пример цели: «Описать функциональность предприятия с целью написания спецификаций ИС».

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

Основные элементы IDEF0-модели

В основе методологии IDEF0 лежат 4 основных понятия:

• 
  функциональный блок;
  
• 
  интерфейсная дуга (стрелка);
  
• 
  декомпозиция;
  
• 
  глоссарий.
  

1. 
   Функциональный блок
   

Функциональные блоки обозначают поименованные процессы, функции или задачи, которые происходят в течение определенного времени и имеют распознаваемые результаты. Графически функциональные блоки изображаются в виде прямоугольников. Все блоки должны быть названы и определены. Имя функционального блока должно быть выражено сочетанием отглагольного существительного, обозначающего процесс, или глаголом:



Определение функционального блока заносится в глоссарий или словарь работ (Activity Dictionary).

Все функциональные блоки модели нумеруются. Номер состоит из префикса и числа. Может использоваться префикс любой длины, но обычно используется префикс А. Контекстная (корневая) работа (функциональный блок) имеет номер А0.

2. 
   Интерфейсная дуга (стрелка – Arrow)
   

---