НТП_МУ_ЛР. Томский государственный университет систем управления и радиоэлектроники кафедра компьютерных систем в управлении
 Скачать 1.31 Mb.
|
|
2.6 Задание на лабораторную работу 1. Создайте в решении новый проект WinForms (WinForms Application Project) и задайте ему соответствующее имя. Если проект биз- нес-логики назван как Model, для проекта пользовательского интерфейса логично дать название View. Данный подход в проектировании архитекту- ры приложения называется Model-View: когда бизнес-логика и пользова- тельский интерфейс разделены на разные сборки. В дальнейшем такой подход облегчает ориентирование в рамках проекта. Обратите внимание, что теперь данный проект должен быть стартовым, для этого установите его запускаемым проектом по умолчанию. ПРИМЕЧАНИЕ: ранее созданный проект ConsoleLoader теперь мож- но удалить. Удаление проекта из решения не приводит к его физическому удалению с носителя, в отличие от классов проекта. Помните об этом при удалении каких-либо компонентов проекта. 2. Добавьте в проект View новую форму. Название формы должно отражать назначение формы и оканчиваться словом Form. Как и имена других классов, имя формы оформляется в стиле Pascal. 3. Добавьте на форму элемент GridControl из панели инструментов. Для повышения удобства пользовательского интерфейса лучше сначала разместить на форме элемент GroupBox, в который поместить GridControl. Это позволит поместить в заголовок GroupBox фразу, поясняющую назна- чение GridControl. Под GridControl разместите две кнопки Button. Назовите кнопки Add Object и Remove Object, где вместо Object подставьте название того объекта, который реализован в вашей бизнес-логике. 29 4. Создайте внутри формы поле, хранящее список (List) сущностей, соответствующих вашему варианту. Список должен иметь возможность хранения в себе всех дочерних классов вашей сущности (все виды геомет- рических фигур, все типы работников, все виды скидок и т. д.). 5. Необходимо реализовать следующую логику формы: GridControl должен отображать (без возможности редактирования) все объекты соз- данного списка. Кнопка Add Object должна добавлять новый объект в GridControl и в список объектов. Кнопка Remove Object должна удалять выбранный в GridControl объект и удалять его из списка объектов. 6. Для добавления новых объектов в программу нужно разработать специальную форму, которая вызывалась бы по нажатию клавиши Add Object. В форме должна присутствовать возможность заполнения полей, общих для всех дочерних классов, выбор в виде ComboBox или RadioButton типа объекта и, в зависимости от типа объекта, должна появ- ляться возможность заполнения полей данного типа объекта. Например, если создается новый работник, то в форме обязательно есть поля ФИО и даты принятия на работу, но в зависимости от RadioButton с типом оплаты должны появляться поля либо почасовой оплаты, либо оплаты по ставке. 7. На форме создания нового объекта должны присутствовать кнопки Ok и Cancel. Если пользователь нажмет кнопку Ok — в главной форме дол- жен быть добавлен созданный объект. Если пользователь нажмет Cancel — должна быть выполнена отмена добавления. 8. Форма создания нового объекта должна учитывать ограничения на значения полей объекта (например, неотрицательный размер стороны гео- метрической фигуры). Фактически, здесь должна производиться обработка исключений при попытке ввода неправильных значений. 9. Особое внимание обратите на визуальную аккуратность создавае- мых вами пользовательских интерфейсов. Старайтесь выравнивать эле- менты по левому краю относительно друг друга, делать одинаковые отсту- 30 пы между элементами, правильно подписывать элементы, кнопки и заго- ловки. Грамотно рассчитывайте размеры элементов — если в TextBox должно вводиться целое число со значением до 100, не имеет смысла де- лать его длиннее 50 пикселей. Также поля для фамилии должны быть под- ходящего размера, чтобы корректно отображать обычную фамилию, — не слишком длинные, но и не слишком короткие. Аккуратность и удобство пользовательского интерфейса может стать решающим фактором в выборе именно вашей программы конечным пользователем. 10. При тестировании и отладке программы не очень удобно вручную добавлять новые объекты — необходимость каждый раз вводить данные для 10 объектов может сильно пошатнуть психическое состояние разработчика (или вашего преподавателя). Чтобы облегчить тестирование программы, а значит, и собственную разработку, добавьте на форму создания нового объ- екта кнопку Create Random Data. По нажатию данной кнопки все поля будут заполняться случайными правильными данными для объекта. Пользователю останется только нажать кнопку Ok для добавления нового объекта на глав- ную форму. 11. Кнопка Create Random Data является отладочной, и в версии, кото- рая будет поставляться конечному пользователю, этой кнопки быть не долж- но — не будет же бухгалтерия создавать «случайных» работников со «слу- чайными» зарплатами! Удалять же и заново создавать эту кнопку при необ- ходимости нового установщика опять же не очень удобно — вы можете про- сто забыть это сделать. Используйте механизм условной компиляции. 12. Добавьте форму, на которой можно будет провести поиск объек- та по каждому из полей общих для всех дочерних классов. Помните, что результатом поиска может быть не один объект. Добавьте на главную форму кнопку для вызова формы поиска. 13. Добавьте возможность сохранения и загрузки введенных пользо- вателем данных, используя любой механизм сериализации, на ваше усмот- 31 рение. Сохранять данные необходимо в файл с расширением, которое бу- дет характерно только для вашей программы (не надо использовать из- вестные форматы, например *.doc, *.txt или *.xml). 2.7 Список используемых источников 1. Регулярные выражения. Википедия, свободная энциклопедия [Электронный ресурс]. — URL: https://ru.wikipedia.org/wiki/Регуляр- ные_выражения (дата обращения 29.12.2014). 2. Элементы языка регулярных выражений — краткий справочник. Microsoft Software Developer Network [Электронный ресурс]. — URL: http://msdn.microsoft.com/ru-ru/library/az24scfc(v=vs.110).aspx (дата обра- щения 29.12.2014). 3. Регулярные выражения в .NET Framework. Microsoft Software De- veloper Network [Электронный ресурс]. — URL: http://msdn.microsoft.com/ru-ru/library/hs600312(v=vs.110).aspx (дата обра- щения 29.12.2014). 32 3 Лабораторная работа № 3. Система контроля версий Целью данной работы является знакомство с распределённой систе- мой управления версиями файлов Git и процессом работы с ним, а также с сервисом GitHub. 3.1 Об управлением версиями Описание этой главы основано на книге [1]. Более подробную ин- формацию о работе с Git и особенности его устройства можно взять на- прямую из источника. Что такое управление версиями? Система управления версиями (СУВ) — это система, сохраняющая изменения в одном или нескольких файлах так, чтобы потом можно было восстановить определённые старые версии. Для примеров в этой книге мы будем использовать исходные коды программ, но на самом деле можно управлять версиями практически лю- бых типов файлов. Если вы графический или веб-дизайнер и хотите хранить каждую версию изображения или макета — вот это вам наверняка нужно — то пользоваться системой управления версиями будет очень мудрым решени- ем. Она позволяет вернуть файлы к прежнему виду, вернуть к прежнему состоянию весь проект, сравнить изменения с какого-то времени, увидеть, кто последним изменял модуль, который дал сбой, кто создал проблему и так далее. Вообще, если, пользуясь СУВ, вы всё испортили или потеряли файлы, всё можно легко восстановить. Кроме того, издержки на всё это будут очень маленькими. 33 3.1.1 Локальные системы управления версиями Многие люди, чтобы управлять версиями, просто копируют файлы в другой каталог (некоторые ещё пишут текущую дату в название каталога). Такой подход очень распространён, потому что прост, но он ещё и чаще даёт сбои. Очень легко забыть, что ты не в том каталоге, и случайно изменить не тот файл либо скопировать и перезаписать файлы не туда, куда хотел. Чтобы решить эту проблему, программисты уже давно разработали локальные СУВ с простой базой данных, в которой хранятся все изменения нужных файлов (см. рис. 3.1). Одной из наиболее популярных СУВ данно- го типа является rcs, которая до сих пор устанавливается на многие ком- пьютеры. Даже в современной операционной системе Mac OS X утилита rcs устанавливается вместе с Developer Tools. Эта утилита основана на ра- боте с наборами патчей между парами изменений (патч — файл, описы- вающий различие между файлами), которые хранятся в специальном фор- мате на диске. Это позволяет пересоздать любой файл на любой момент времени, последовательно накладывая патчи. fi le version 3 version 2 ve rsio n 1 Version Database Checkout Local Computer Рисунок 3.1 — Схема хранения версий на локальном компьютере 34 3.1.2 Централизованные системы управления версиями Следующей большой проблемой оказалась необходимость сотруд- ничать с разработчиками за другими компьютерами. Чтобы решить её, бы- ли созданы централизованные системы управления версиями (ЦСУВ). В таких системах, например CVS, Subversion и Perforce, есть центральный сервер, на котором хранятся все отслеживаемые файлы, и ряд клиентов, которые получают копии файлов из него. Много лет это был стандарт управления версиями (см. рис. 3.2). Рисунок 3.2 — Схема централизованной СУВ Такой подход имеет множество преимуществ, особенно над локаль- ными СУВ. К примеру, все знают, кто и чем занимается в проекте. У адми- нистраторов есть чёткий контроль над тем, кто и что может делать, и, ко- нечно, администрировать ЦСУВ гораздо легче, чем локальные базы на ка- ждом клиенте. Однако при таком подходе есть и несколько серьёзных недостатков. Наиболее очевидный — централизованный сервер является уязвимым ме- стом всей системы. Если сервер выключается на час, то в течение часа раз- работчики не могут взаимодействовать и никто не может сохранить новые версии. Если же повреждается диск с центральной базой данных и нет ре- 35 зервной копии, вы теряете абсолютно всё — всю историю проекта, разве что за исключением нескольких рабочих версий, сохранившихся на рабо- чих машинах пользователей. Локальные системы управления версиями подвержены той же проблеме: если вся история проекта хранится в одном месте, вы рискуете потерять всё. 3.1.3 Распределённые системы контроля версий В такой ситуации применяют распределенные системы управления версиями (РСУВ). В таких системах, как Git, Mercurial, Bazaar или Darcs, клиенты не просто забирают последние версии файлов, а полностью копи- руют репозиторий. Поэтому в случае, когда по той или иной причине от- ключается сервер, через который шла работа, любой клиентский репозито- рий может быть скопирован обратно на сервер, чтобы восстановить базу данных. Каждый раз, когда клиент забирает свежую версию файлов, созда- ётся полная копия всех данных (см. рис. 3.3). Рисунок 3.3 — Схема распределённой СУВ 36 Кроме того, в большей части этих систем можно работать с несколь- кими удаленными репозиториями, таким образом, можно одновременно работать по-разному с разными группами людей в рамках одного проекта. Так, в одном проекте можно одновременно вести несколько типов рабочих процессов, что невозможно в централизованных системах. 3.1.4 Краткий экскурс в историю появления Git История Git тесно связана с историей Linux. Ядро Linux — действи- тельно очень большой открытый проект. Большую часть существования ядра Linux (1991—2002) изменения вносились в код путем приёма патчей и архивирования версий. В 2002 году проект перешёл на проприетарную РСУВ Bit-Keeper. В 2005 году отношения между сообществом разработчиков ядра Linux и компанией, разрабатывавшей BitKeeper, испортились, и право бес- платного пользования продуктом было отменено. Это подтолкнуло разра- ботчиков Linux (и в частности Линуса Торвальдса, создателя Linux) разра- ботать собственную систему, основываясь на опыте, полученном за время использования BitKeeper. Основные требования к новой системе были сле- дующими: • скорость; • простота дизайна; • поддержка нелинейной разработки (тысячи параллельных веток); • полная распределенность; • возможность эффективной работы с такими большими проекта- ми, как ядро Linux (как по скорости, так и по размеру данных). С момента рождения в 2005 г. Git разрабатывали так, чтобы он был простым в использовании, сохранив свои первоначальные свойства. Он невероятно быстр, очень эффективен для больших проектов, а также обла- дает превосходной системой ветвления для нелинейной разработки. 37 3.1.5 Особенности Git Так что же такое Git в двух словах? Эту часть важно усвоить, по- скольку если вы поймете, что такое Git и каковы принципы его работы, вам будет гораздо проще пользоваться им эффективно. Изучая Git, поста- райтесь освободиться от всего, что вы знали о других СУВ, таких как Subversion или Perforce. В Git совсем не такие понятия об информации и работе с ней, как в других системах, хотя пользовательский интерфейс очень похож. Знание этих различий защитит вас от путаницы при исполь- зовании Git. 3.1.6 Слепки вместо патчей Главное отличие Git от любых других СУВ (например, Subversion и ей подобных) — это то, как Git смотрит на данные. В принципе, большин- ство других систем хранит информацию как список изменений (патчей) для файлов. Эти системы (CVS, Subversion, Perforce, Bazaar и другие) от- носятся к хранимым данным как к набору файлов и изменений, сделанных для каждого из этих файлов во времени, как показано на рис. 3.4. Рисунок 3.4 — Схема представления данных в других СУВ Git не хранит свои данные в таком виде. Вместо этого Git считает хранимые данные набором слепков небольшой файловой системы. Каж- дый раз, когда вы фиксируете текущую версию проекта, Git, по сути, со- храняет слепок того, как выглядят все файлы проекта на текущий момент. 38 Ради эффективности, если файл не менялся, Git не сохраняет файл снова, а делает ссылку на ранее сохранённый файл. То, как Git подходит к хране- нию данных, похоже на рис. 3.5. Рисунок 3.5 — Схема представления данных в Git Это важное отличие Git от практически всех других систем управле- ния версиями. Из-за него Git вынужден пересмотреть практически все ас- пекты управления версиями, которые другие системы взяли от своих предшественниц. Git больше похож на небольшую файловую систему с невероятно мощными инструментами, работающими поверх неё, чем на просто СУВ. В главе 3, коснувшись работы с ветвями в Git, мы узнаем, ка- кие преимущества даёт такое понимание данных. 3.1.7 Почти все операции — локальные Для совершения большинства операций в Git необходимы только ло- кальные файлы и ресурсы, т. е. обычно информация с других компьютеров в сети не нужна. Если вы пользовались централизованными системами, где практически на каждую операцию накладывается сетевая задержка, вы оцените скорость работы с Git. Поскольку вся история проекта хранится локально у вас на диске, большинство операций выглядят практически мгновенными. К примеру, чтобы показать историю проекта, Git-у не нужно скачи- вать её с сервера, он просто читает её прямо из вашего локального репози- 39 тория. Поэтому историю вы увидите практически мгновенно. Если вам нужно просмотреть изменения между текущей версией файла и версией, сделанной месяц назад, Git может взять файл месячной давности и вычис- лить разницу на месте, вместо того чтобы запрашивать разницу у сервера СУВ или качать с него старую версию файла и делать локальное сравнение. Кроме того, работа локально означает, что мало чего нельзя сделать без доступа к Сети или VPN. Если вы в самолёте или в поезде и хотите не- много поработать, можно спокойно делать коммиты, а затем отправить их, как только станет доступна сеть. Если вы пришли домой, а VPN клиент не работает, всё равно можно продолжать работать. Во многих других систе- мах это невозможно или же крайне неудобно. Например, используя Perforce, вы мало что можете сделать без соединения с сервером. Работая с Subversion и CVS, вы можете редактировать файлы, но сохранить изменения в вашу базу данных нельзя (потому что она отключена от репозитория). Вроде ничего серьёзного, но потом вы удивитесь, насколько это меняет дело. 3.1.8 Git следит за целостностью данных Перед сохранением любого файла Git вычисляет контрольную сум- му, и она становится индексом этого файла. Поэтому невозможно изме- нить содержимое файла или каталога так, чтобы Git не узнал об этом. Эта функциональность встроена в сам фундамент Git и является важной со- ставляющей его философии. Если информация потеряется при передаче или повредится на диске, Git всегда это выявит. Механизм, используемый Git для вычисления контрольных сумм, на- зывается SHA-1 хеш. Это строка из 40 шестнадцатеричных знаков (0-9 и a-f), которая вычисляется на основе содержимого файла или структуры катало- га, хранимого Git. SHA-1 хеш выглядит примерно так: 24b9da6552252987aa493b52f8696cd6d3b00373 40 Работая с Git, вы будете постоянно встречать эти хеши, поскольку они широко используются. Фактически, в своей базе данных Git сохраняет всё не по именам файлов, а по хешам их содержимого. 3.1.9 Чаще всего данные в Git только добавляются Практически все действия, которые вы совершаете в Git, только до- бавляют данные в базу. Очень сложно заставить систему удалить данные или сделать что-то неотменяемое. Можно, как и в любой другой СУВ, по- терять данные, которые вы ещё не сохранили, но как только они зафикси- рованы, их очень сложно потерять, особенно если вы регулярно отправ- ляете изменения в другой репозиторий. Поэтому пользоваться Git — удовольствие, потому что можно экспе- риментировать, не боясь серьёзно что-то поломать. |