Отчет по практике. Отчет по учебной практике по профессиональному модулю пм 02 Осуществление интеграции программных модулей

• Название: Отчет по учебной практике по профессиональному модулю пм 02 Осуществление интеграции программных модулей
• Дата: 02.03.2022
• Размер: 1.66 Mb.
• Имя файла: Отчет по практике.docx
• Тип: Отчет; #380200

Краевое государственное бюджетное

профессиональное образовательное учреждение

«Хабаровский промышленно-экономический техникум»
ОТЧЕТ

по учебной практике

по профессиональному модулю

ПМ 02 «Осуществление интеграции программных модулей»

ПМ 03 «Ревьюирование программных продуктов»

Специальность: 09.02.07

«Информационные системы и программирование»

Руководитель практики С.В.Зайчук

Выполнил студент А.П. Понуровский

2022 г.

СОДЕРЖАНИЕ

ВВЕДЕНИЕ
Учебная практика является частью учебного процесса и направлена на формирование у студентов практических профессиональных умений и закрепление умений и навыков по технологии программирования – созданию базы данных.

Цели практики:

- расширение, углубление и систематизация знаний, полученных в процессе теоретического обучения;

- закрепление практических навыков по разработке и интеграции модулей в программное обеспечение;

- формирование профессиональных компетенций.

Задачи практики:

- знакомство с условиями работы предприятия и со своим рабочим местом, а именно с правилами внутреннего распорядка, требованиями по безопасности, физиолого-гигиеническими основами трудового процесса и требованиями санитарии;

- изучение нормативных и методических материалов, фундаментальной и периодической литературы в соответствии с индивидуальным заданием;

- использование информационно-коммуникационных технологий;

- выбор средств разработки программных продуктов;

- выполнение индивидуального задания;

-оформление отчета по практике.

Хабаровский Лесотехнический техникум организован по распоряжению Совета Министров СССР в 1954 году с целью подготовки специалистов для развивающейся на Дальнем Востоке лесозаготовительной и деревообрабатывающей промышленности. Приказом № 54/К от 1 сентября 1954 года по Минлеспрому СССР был назначен Дедов Герасим Тихонович директором Хабаровского Лесотехнического техникума. В августе 1955 года в техникум было принято на первый курс 120 человек: 60 человек по специальности «Технология лесозаготовок» и 60 человек по специальности «Сплав леса». 1 сентября 1955 года в техникуме начались занятия.

Первыми заведующими отделений были — Назаров Г.В., Толченов Ю.Ф., Барановский В.И. Первый выпуск состоялся в 1959 году. В период 1959—1986 гг — техникум возглавлял Савчук Владимир Кузьмич. В этот период было завершено строительство главного учебного корпуса, построено два пятиэтажных общежития для студентов и создана материально-техническая база.



Рис. 1 Структурная схема ХПЭТ
Год введения специальности 09.02.07 - 9 декабря 2016 г

Квалификация: специалист по информационным ресурсам

Область деятельности:

- осуществление интеграции программных модулей;

- ревьюирование программных продуктов;

- проектирование и разработка информационных систем;

- сопровождение информационных систем;

- соадминистрирование баз данных и серверов;

- администрирование информационных ресурсов.

Актуальность продуктов автоматизации рабочих мест

В условиях реализации принципов рыночной экономики возрастает роль организации труда как элемента управления стабильностью экономического, технического и социального развития предприятия любой организационно-правовой формы управления при различных формах собственности. Причём особое место в этом процессе занимает организация труда специалистов. В современных условиях состояние организации труда специалистов необходимо рассматривать в качестве одного из важнейших критериев оказывающих воздействие на себестоимость производимого товара (услуг) и получение прибыли. Данная тема всегда остается актуальной, так как правильная организация труда на предприятии - постоянно действующий фактор эффективности любого вида деятельности. Во все времена рационально организованный труд при его технической оснащённости обеспечивает достижение более высоких результатов. С переходом экономики на постиндустриальные рельсы возросла роль информационных технологий. В настоящее время разработано множество программных продуктов поддержки принятия управленческих решений, автоматизации функций различных специалистов. Но крупные компании стремятся внедрить информационные технологии на все производственные и управленческие процессы. Учитывая большие массивы информации, с которой приходится работать специалистам любого предприятия, в частности специалистам отдела кадров, руководство всё чаще из соображений экономии времени, увеличения производительности, продуктивности и качества работы внедряют на своих предприятиях автоматизированные системы управления. В рамках этой проблемы актуальным становится вопрос об организации труда специалистов отдела кадров в условиях использования автоматизированной системы управления предприятием. Системы позволяют автоматизировать некоторые рутинные функции таких специалистов, как отдела кадров, так и других подразделений, обеспечивают обмен информацией между подразделениями предприятия, облегчают кадровое делопроизводство, сокращая потери времени, повышая производительность труда работников, сокращая издержки производства и увеличивая эффективность функционирования предприятия.


1 Основные понятия и стандартизация требований к программному обеспечению

1. 
   Понятие требований, классификация, уровни требований
   

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

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

Классификация требований разделяется на три разных уровня:

1. 
   Требования пользования (для обозначения высокоуровневых требований);
   
2. 
   Системные требования (для детализированного описания выполняемых системой функций);
   
3. 
   Проектная системная спецификация (используется для более детализированного описания системы, которая может служит мостом между этапом разработки требований и проектирования системы).
   

Три уровня требований:

1. 
   Бизнес-требования;
   
2. 
   Требования пользователя;
   
3. 
   Функциональные требования.
   

2. 
   Методология и стандарты, регламентирующие работу с требованиями
   

Среди основополагающих нормативных документов в области работы с требованиями можно выделить следующие.

1. 
   Разработки IEEE:
   

• 
  IEEE 1362 "Concept of Operations Document".
  
• 
  IEEE 1233 "Guide for Developing System Requirements Specifications".
  
• 
  IEEE Standard 830-1998, "IEEE Recommended Practice for Software Requirements Specifications"
  
• 
  IEEE Standard Glossary of Software Engineering Terminology/IEEE Std 610.12-1990
  
• 
  IEEE Guide to the Software Engineering Body of Knowledge (1) - SWEBOK®, 2004.
  

2. 
   Отечественные ГОСТ:
   

• 
  ГОСТ 34.601-90. Информационная технология. Автоматизированные системы. Стадии создания.
  
• 
  ГОСТ 34.602-89. Информационная технология. Техническое задание на создание автоматизированной системы
  
• 
  ГОСТ 19.201-78. Единая система программной документации. Техническое задание. Требования к содержанию и оформлению.
  

3. 
   Техническое задание
   

1.1. Общие сведения

1.1.1. Наименование системы

1.1.1.1 Полное наименование: Прикладное программное обеспечение деятельности кассы авиакомпании.

1.1.1.2 Краткое наименование: ППО

1.1.2 Наименований организаций – Заказчика и Разработчика

1.1.2.1 Заказчик

Заказчик: КГБ ПОУ «Хабаровский промышленно-экономический техникум», 68006, г. Хабаровск, ул. Краснореченская, д.145, тел. [phone]

1.1.2.2 Разработчик

Разработчик: Понуровский Александр Петрович, 680015, г. Хабаровск, ул. Краснореченская, д. 143, тел. [phone]

1.1.3 Плановые сроки начала и окончания работ

Начало: 12.02.2022

Окончание: 01.03.2022

1.1.4 Порядок оформления и предъявления Заказчику результатов работы

Работы по созданию ППО сдаются Разработчиком поэтапно в соответствии с календарным планом Проекта. По окончании каждого из этапов работ Разработчик сдает Заказчику соответствующие отчетные документы этапа, состав которых определен Договором.

2. Назначение и цели создания системы

2.1. Назначение системы

ППО предназначена для повышения оперативности и качества принимаемых управленческих решений сотрудниками Заказчика.

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

– продажей билетов на предстоящие рейсы.;

– защита от НСД к БД;

2.2. Цели системы

ППО создается с целью:

– сокращение трудозатрат на оформление авиабилета;

– формирования запросов по составляющим авиабилета;

– повышения защищенности конфиденциальности данных.

3. Требования к системе

3.1. Требования к структуре и функционированию системы

ППО состоит из нескольких логических подсистем:

– подсистема ввода и обработки данных;

– подсистема авторизации.

Подсистема ввода и обработки данных должна содержать следующий функционал:

- форму ввода и редактирования данных о клиентах;

- обеспечение поиска по различным графам.

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

3.2. Требования к видам обеспечений

3.2.1. Информационное обеспечение

База данных должна размещаться на MS Access 2016, обеспечивающей возможности многопользовательской работы.

3.2.2. Лингвистическое обеспечение

ППО должна быть реализована и контролируется с использованием СУБД MS Access 2016 и SQL встроенным в данную версию MS Access.

3.2.3. Аппаратное обеспечение

К аппаратному обеспечению предъявляются следующие требования:

- процессор Intel(R) Core(TM) i3-3220 3.30 GHz

- 8 Гб оперативной памяти

- не менее 150 Мб свободного места на жестком диске для установки и работы приложения

- клавиатура

- мышь

- монитор

3.2.4. Программное обеспечение

Необходимое ПО установленное на ЭВМ:

- MS Access 2016 или более новых версий

3.2.2. Техническое обеспечение

Особых требований к техническому обеспечению не предъявляется

3.3. Требования к эргономике и технической эстетике.

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

4 Порядок сдачи-приёмки

Разработчик сдает систему очно. В случае обнаружения смысловых, орфографических и грамматических ошибок разработчик обязан устранить выявленные ошибки в течение трёх рабочих дней.
2 Описание и анализ требований. Диаграммы IDEF

2.2 Методология IDEF0
IDEF0 используется для создания функциональной модели, отображающей структуру и функции системы, а также потоки информации и материальных объектов, связывающие эти функции.

Основные понятия:

1. 
   Блок: прямоугольник, содержащий имя и номер и используемый для описания функции;
   
2. 
   Ветвление: разделение стрелки на два или большее число сегментов. Может означать «развязывание пучка»;
   
3. 
   Внутренняя стрелка: входная, управляющая или выходная стрелка, концы которой связывают источник и потребителя, являющиеся блоками одной диаграммы;
   
4. 
   Входная стрелка: класс стрелок, которые отображают вход IDEF0-блока;
   
5. 
   Выходная стрелка: класс стрелок, которые отображают выход IDEF0-блока;
   
6. 
   Глоссарий: список определений для ключевых слов, фраз и аббревиатур, связанных с узлами, блоками, стрелками или с моделью IDEF0 в целом.
   
7. 
   Граничная стрелка: стрелка, один из концов которой связан с источником или потребителем, а другой не присоединен ни к какому блоку на диаграмме;
   
8. 
   Декомпозиция: разделение моделируемой функции на функции - компоненты.
   
9. 
   Дерево узлов: представление отношений между родительскими и дочерними узлами модели IDEF0 в форме древовидного графа;
   
10. 
    Диаграмма A-0: специальный вид (контекстной) диаграммы IDEF0, состоящей из одного блока, описывающего функцию верхнего уровня, ее входы, выходы, управления, и механизмы, вместе с формулировками цели модели и точки зрения, с которой строится модель.
    
11. 
    Диаграмма: часть модели, описывающая декомпозицию блока.
    
12. 
    Диаграмма-иллюстрация (FEO): графическое описание, используемое, для сообщения специфических фактов о диаграмме IDEF0;
    
13. 
    Дочерний блок: блок на дочерней (порожденной) диаграмме;
    
14. 
    Дочерняя диаграмма: диаграмма, детализирующая родительский (порождающий) блок;
    
15. 
    Имя блока: глагол или глагольный оборот, помещенный внутри блока и описывающий моделируемую функцию;
    
16. 
    Интерфейс: разделяющая граница, через которую проходят данные или материальные объекты; соединение между двумя или большим числом компонентов модели, передающее данные или материальные объекты от одного компонента к другому;
    
17. 
    Код ICOM: код, обеспечивающий соответствие граничных стрелок дочерней диаграммы со стрелками родительского блока; используется для ссылок;
    
18. 
    Контекст: окружающая среда, в которой действует функция (или комплект функций на диаграмме);
    
19. 
    Контекстная диаграмма: диаграмма, имеющая узловой номер A-n ( n ≥ 0 ), которая представляет контекст модели;
    
20. 
    Метка стрелки: существительное или оборот существительного, связанные со стрелкой или сегментом стрелки и определяющие их значение;
    
21. 
    Модель IDEF0: графическое описание системы, разработанное с определенной целью и с выбранной точки зрения;
    
22. 
    Номер блока: число (0 - 6), помещаемое в правом нижнем углу блока однозначно идентифицирующее блок на диаграмме;
    
23. 
    Перечень узлов: список, часто ступенчатый, показывающий узлы модели IDEF0 в упорядоченном виде;
    
24. 
    Примечание к модели: текстовый комментарий, являющийся частью диаграммы IDEF0 и используемый для записи факта, не нашедшего графического изображения;
    
25. 
    Родительская диаграмма: диаграмма, которая содержит родительский блок;
    
26. 
    Родительский блок: блок, который подробно описывается дочерней диаграммой.
    
27. 
    Связывание/развязывание: объединение значений стрелок в составное значение (связывание в «пучок»), или разделение значений стрелок (развязывание «пучка»), выраженные синтаксисом слияния или ветвления стрелок;
    
28. 
    Сегмент стрелки: сегмент линии, который начинается или заканчивается на стороне блока, в точке ветвления или слияния, или на границе (несвязанный конец стрелки);
    
29. 
    Семантика: значение синтаксических компонентов языка;
    
30. 
    Синтаксис: структурные компоненты или характеристики языка и правила, которые определяют отношения между ними;
    
31. 
    Слияние: объединение двух или большего числа сегментов стрелок в один сегмент. Может означать «развязывание пучка»;
    
32. 
    С-номер: номер, создаваемый в хронологическом порядке и используемый для идентификации диаграммы и прослеживания ее истории;
    
33. 
    Стрелка: направленная линия, состоящая из одного или нескольких сегментов, которая моделирует открытый канал или канал, передающий данные или материальные объекты от источника к потребителю;
    
34. 
    Стрелка вызова: вид стрелки механизма, который обозначает обращение из блока данной модели (или части модели) к блоку другой модели (или другой части той же модели) и обеспечивает связь между моделями или между разными частями одной модели;
    
35. 
    Стрелка механизма: класс стрелок, которые отображают механизмы IDEF0, то есть средства, используемые для выполнения функции;
    
36. 
    Стрелка, помещенная в туннель (туннельная стрелка): стрелка (со специальной нотацией), не удовлетворяющая обычному требованию, согласно которому каждая стрелка на дочерней диаграмме должна соответствовать стрелкам на родительской диаграмме;
    
37. 
    Текст: любой текстовый (не графический) комментарий к графической диаграмме IDEF0;
    
38. 
    Тильда: небольшая ломаная (волнистая) линия, используемая для соединения метки с конкретным сегментом стрелки или примечания модели с компонентом диаграммы;
    
39. 
    Точка зрения: указание на должностное лицо или подразделение организации, с позиции которого разрабатывается модель ;
    
40. 
    Узел: блок, порождающий дочерние блоки; родительский блок;
    
41. 
    Узловая ссылка: код, присвоенный диаграмме, для ее идентификации и определения положения в иерархии модели;
    
42. 
    Узловой номер диаграммы: часть узловой ссылки диаграммы, которая соответствует номеру родительского блока;
    
43. 
    Узловой номер: код, присвоенный блоку и определяющий его положение в иерархии модели; может быть использован в качестве подробного ссылочного выражения;
    
44. 
    Управляющая стрелка: класс стрелок, которые в IDEF0 отображают управления, то есть условия, при выполнении которых выход блока будет правильным;
    
45. 
    Функция: деятельность, процесс или преобразование (моделируемые блоком IDEF0), идентифицируемое глаголом или глагольной формой, которая описывает, что должно быть выполнено;
    
46. 
    Цель: краткая формулировка причины создания модели.
    

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


Рисунок 1 – Диаграмма IDEF0
На рисунке 1 представлена функциональная диаграмма уровня 0, описывающая функцию кассира в соответствии с правилами продажи на основе сведений о пассажире и маршруте.

3 Создание ER-модели разрабатываемой БД
ER-модель (от англ. Entity-Relationshipmodel, модель «сущность — связь») — модель данных, позволяющая описывать концептуальные схемы предметной области.

ER-модель используется при высокоуровневом (концептуальном) проектировании баз данных. С её помощью можно выделить ключевые сущности и обозначить связи, которые могут устанавливаться между этими сущностями.

Во время проектирования баз данных происходит преобразование схемы, созданной на основе ER-модели, в конкретную схему базы данных на основе выбранной модели данных (реляционной, объектной, сетевой или др.).

На рисунке 2 представлена ER-модель ППО.

Рисунок 2 – ER-модель ППО
Создание новой схемы модели с нуля:

1. 
   В меню Файл последовательно выберите пункты Создать, Программное обеспечение и базы данных, а затем — команду Схема модели базы данных. (Рисунок 3 – Создание «Схема модели базы данных»)
   

Рисунок 3 – Создание «Схема модели базы данных»

2. 
   В меню База данных выберите пункт Параметры, а затем — команду Документ.
   
3. 
   В диалоговом окне Параметры документа базы данных выберите нужный набор символов и другие параметры таблицы и связи, а затем нажмите кнопку ОК.
   
4. 
   Чтобы создать таблицу, воспользуйтесь фигурой Сущность.
   
5. 
   Из набора элементов Сущности и отношения или Объектно-реляционная схема перетащите фигуру Сущность в документ. (Рисунок 4 – Сущность)
   

Рисунок 4 – Сущность

6. 
   Дважды щелкните фигуру, чтобы открыть окно «Свойства базы данных» (Рисунок 5 – Свойства таблицы)
   

Рисунок 5 – Свойства таблицы

7. 
   В группе Категории выберите вариант Определение и введите имя для таблицы.
   
8. 
   В группе Категории выберите вариант Столбцы, введите имя и выберите тип данных.
   

Установите флажок Обязательное для столбцов, которые не могут иметь значения NULL.

9. 
   Установите флажок PK (первичный ключ) для столбцов, однозначно определяющих каждую строку таблицы базы данных.
   
10. 
    В группе Категории выберите вариант:
    

Индексы, Триггеры, Проверка или Дополнительные, чтобы создать эти дополнительные элементы.

11. 
    Чтобы добавить или изменить свойства для столбцов, включая типы данных и первичные ключи, воспользуйтесь окном «Свойства базы данных»:
    
12. 
    Дважды щелкните таблицу в схеме.
    
13. 
    В окне «Свойства базы данных» в группе Категории выберите вариант Столбцы.
    
14. 
    Щелкните первую пустую ячейку Физическое имя и введите имя.
    

15) Чтобы изменить тип данных для столбца, щелкните его поле Тип данных, а затем из списка выберите тип данных или введите тип данных в список. Например, можно ввести int(eger) для числовых данных, char(30) или varchar (30) для текстовых данных.

16) Чтобы не допустить значений NULL, установите флажок Обязательное.

17) Чтобы указать, что столбец является первичным ключом, установите флажок PK. (Рисунок 5 – PK)

Рисунок 5 – PK
18) Создание связи между таблицами

19) Убедитесь, что в схеме отображены обе таблицы. Если модель реконструировалась из существующей базы данных, может потребоваться перетащить одну или обе таблицы из окна «Таблицы и представления» на страницу документа.

20) Дважды щелкните таблицу, которая будет на стороне первичного ключа в связи.

21) В окне «Свойства базы данных» в группе Категории выберите вариант Столбцы.

22) В сетке выделите столбец для однозначного определения каждой строки таблицы и установите флажок PK, чтобы задать его в качестве первичного ключа.

23) Из набора элементов Объектно-реляционная схема или Сущности и отношения перетащите фигуру Отношение и разместите ее на свободном месте страницы (Рисунок 6 – Отношение)

Рисунок 6 – Отношение
24) Соедините верхний конец фигуры с родительской таблицей.

25) Соедините другой конец с дочерней таблицей.

4 Создание проекта логической схемы разрабатываемой БД
Нормализацией БД называется процедура декомпозиции или композиции исходных схем отношений проекта БД, назначение ключей для каждого отношения с целью исключения возможных аномалий при манипулировании данными. Правила нормализации разработаны Э. Коддом в 1972 году.

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

Задачи нормализации:

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

Основные свойства нормальных форм:

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

Принципы нормализации:

1. 
   В каждой таблице БД не должно быть повторяющихся полей
   
2. 
   В каждой таблице должен быть универсальный идентификатор (Первичный ключ)
   
3. 
   Каждому значению первичного ключа должна соответствовать достаточная информация о типе сущности или об объекте таблицы.
   
4. 
   Изменение значений в полях таблицы не должно влиять на информацию в других полях (кроме изменений в полях ключа)
   

Первая нормальная форма:

1. 
   Таблица должна быть двумерной и не содержать ячеек, включающих несколько значений.
   
2. 
   Все атрибуты – «простые»
   

Вторая нормальная форма:

1. 
   В случае составного ключа вводится понятие функционально полной зависимости, функционально полная зависимость не ключевых атрибутов заключается в том, что каждый не ключевой атрибут функционально зависит от ключа, н он не находится в функциональной зависимости ни от какой части составного ключа
   
2. 
   Отношение будет находится во второй нормальной форме, если оно находится в первой нормальной форме и каждое не ключевое поле функционально полно зависит от первичного ключа
   

Третья нормальная форма:

1. 
   Чтобы все не ключевые поля таблицы зависли от первичного ключа, но были независимы друг от друга.
   
2. 
   Зависит от транзитивной зависимости
   
3. 
   Одно из двух описательных полей зависит от ключа, а другое описательное поле зависит от первого описательного поля.
   
4. 
   Отношение будет находиться в третьей нормальной форме, если оно находится во второй нормальной форме и каждое не ключевое поле не транзитивно зависит от первичного ключа
   

5 Разработка базы данных в СУБД Access

1. 
   Создадим базу данных в MC Access (Рисунок 7 – Создание БД)
   

Рисунок 7 – Создание БД

2. 
   В ленте MS Access в вкладке «Создание» выбираем пункт «Таблица» и создаем таблицу и даем ей название (Рисунок 8 – Создание таблицы)
   

Рисунок 8 – Создание таблицы

3. 
   Нажатием ПКМ на таблице выбираем «Конструктор таблиц», даем имена полям и задаем PK, тип данных и сохраняем таблицу (Рисунок 9 – Конструктор таблиц)
   

Рисунок 9 – Конструктор таблиц

4. 
   Придерживаясь инструкции, создаем остальные таблицы
   
5. 
   Далее в ленте выбираем «Работа с базами данных» и нажимаем на пункт «Схема данных» (Рисунок 10 – Работа с базами данных)
   

Рисунок 10 – Работа с базами данных

6. 
   В окне «Добавление таблицы» выбираем все нужные таблицы и нажимаем «Закрыть» (Рисунок 11 – Добавление таблиц)
   

Рисунок 11 – Добавление таблиц

7. 
   Соединяем таблицы через нужные поля и получаем схему данных БД (Рисунок 12 – Схема данных БД)
   

Рисунок 12 – Схема данных БД

6 Осуществление интеграции модулей SQL-запросов в БД

1. 
   Для создания SQL-запросов нужно зайти в «Конструктор запросов» и там выбрать режим SQL (Рисунок 13 – SQL)
   

Рисунок 13 – SQL

2. 
   Первым SQL-запросом мы выведем с условием (рейсы на 18.02.2022). Пишем код (Рисунок 14 – Код SQL1)
   

Рисунок 14 – Код SQL1
Получаем результат (Рисунок 15 – Рейсы на 18.02.2022)

Рисунок 15 – Рейсы на 18.02.2022

3. 
   Следующим запросом будет запрос с параметром (Поиск рейсов по дате вылета). Пишем код (Рисунок 16 – Код SQL2)
   

Рисунок 16 – Код SQL2
Вводим значение параметра (Рисунок 17 – Ввод параметра)

Рисунок 17 – Ввод параметра
Итог SQL-запроса (Рисунок 18 – Поиск рейсов по дате вылета)

Рисунок 18 – Поиск рейсов по дате вылета

4. 
   Далее зададим запросы с вычислением:
   

Вычислим минимальную цену билета. Пишем код (Рисунок 19 – Код SQL3)

Рисунок 19 – Код SQL3
Итог запроса (Рисунок 20 – Минимальная цена билета)

Рисунок 20 – Минимальная цена билета
Далее вычислим стоимость чека с помощью запроса. Пишем код (Рисунок 21 – Код SQL4)

Рисунок 21 – Код SQL4
Итог SQL-запроса (Рисунок 22 – Стоимость чека)

Рисунок 22 – Стоимость чека

5. 
   Введём запрос с диапазоном. Пишем код (Рисунок 23 – Код SQL5)
   

Рисунок 23 – Код SQL5
Итог SQL-запроса (Рисунок 24 – Цена проданного билета от 10000 до 25000)

Рисунок 24 – Цена проданного билета от 10000 до 25000

7 Разработка пользовательского интерфейса БД

7.1 Создание формы
Для создания формы переходим во вкладку «Создание» после чего выбираем тот пункт «Мастер форм» (Рисунок 25 – Мастер форм)

Рисунок 25 – Мастер форм
После создания формы следует зайти в «Конструктор» и придать форме более приятный вид (Рисунок 26 – Конструктор форм)

Рисунок 26 – Конструктор форм

По итогу получилась следующая форма (Рисунок 27 – Рейс)

Рисунок 27 – Рейс
Далее создадим форму по запросу (Рисунок 28 – Билеты купленные на рейс)

Рисунок 28 – Билеты купленные на рейс
Следующая форма будет составная (Рисунок 29 – Чек)

Рисунок 29 – Чек
Создадим форму авторизации. Для создания формы авторизации нам потребуется создать форму, на которой мы разместим два поля, в первом мы будем вводить логин, во второй пароль (Рисунок 30 – Конструктор формы «Авторизация»)

Рисунок 30 – Конструктор формы «Авторизация»
После того, как создали форму, мы выбираем кнопку «Вход» и нажмаем ПКМ, после чего выбираем пункт «Обработка событий», а дальше выбираем «Выражения». После этих действий нас перенаправляет в Visual Basic. В данном окне мы начинаем прописывать код (Рисунок 31 – Код для авторизации)


Рисунок 31 – Код для авторизации
7.2 Создание отчётов
После создания форм, следует создать отчёты. Для создания отчётов следует провести аналогичные действия, как с формами. После того как создали отчёт, следует придать ему более приятный вид в режиме конструктора (Рисунок 32 – Отчёт в режиме конструктора)


Рисунок 32 – Отчёт в режиме конструктора
Готовый вид отчёта (Рисунок 33 – Цена проданного билета от 10000 до 25000)

Рисунок 33 – Цена проданного билета от 10000 до 25000
Далее мы создадим отчёт, где присутствует группировка и вычисляемое поле (Рисунок 34 – Чек)

Рисунок 34 – Чек
7.3 Создание ленты
Ленту мы будем прописывать с помощью программы «RibbonXMLEditor». Для начала в параметрах навигации поставим все галочки (Рисунок 35 – Параметры отображения системных объектов)


Рисунок 35 – Параметры отображения системных объектов
После чего создадим таблицу под названием UsysRibbons (Рисунок 36 – Таблица UsysRibbons в списке)

Рисунок 36 - Таблица UsysRibbons в списке
Далее создадим поля со следующими именами (Рисунок 37 – Поля в таблице для создания ленты)

Рисунок 37 - Поля в таблице для создания ленты
Присвоим данным полям следующие типы данных (Рисунок 38 – Поля и тип данных в таблице для создания ленты)

Рисунок 38 - Поля и типы данных в таблице для создания ленты
Затем переходим в приложение RibbonXMLEditor и прописываем код нашей ленты (Рисунок 39 - Код ленты в RibbonXMLEditor)

Рисунок 40 - Код ленты в RibbonXMLEditor
После процедуры написания кода проверяем его работоспособность в приложении RibbonXMLEditor с помощью . После того, как убедились, что код работает, копируем его и переходим обратно в Microsoft Acces, задаем имя ленты в поле RibbonName, после чего вставляем его в поле RibbonXML (Рисунок 41 – Код ленты)

Рисунок 41 - Код ленты
После проделанной процедуры перезагружаем базу данных, после чего переходим в параметры текущей базы данных и делаем ленту основной (Рисунок 42 – Параметры ленты)

Рисунок 42 - Параметры ленты
Перезагружаем базу данных и наблюдаем за изменениями (Рисунок 43 – Готовая лента)


Рисунок 43 – Готовая лента

8. 
   Проведение анализа современных браузеров
   

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

Для сравнения можно взять 2 популярных браузера на 2016 год – это Opera и Google Chrome. Критериями оценивания будут служить важные составляющие браузеров: интерфейс, безопасность и скорость работы.

Когда человек заходит в интернет, первое, что бросается ему в глаза – это интерфейс web-браузера. Разработчики Google Chrome придерживаются аскетичного дизайна, т.е когда пользователь попадает на главную страницу браузера, он видит только лишь строку поиска и вкладки, на ссылки сайтов, которые он чаще всего посещает. Это намного упрощает поиск нужной часто посещаемой web-страницы.

На первый взгляд дизайн Opera не такой простой, как дизайн Google Chrome. На главной странице множество панелей, вкладок и кнопок, которые не всегда будут использованы пользователем данного браузера. И для того, чтобы упростить работу с данным web-браузером, нужно потратить некоторое количество времени, чтобы убрать все ненужные настройки, которые в дальнейшем сделают работу с Opera намного удобнее.

Второе, на что люди обращают внимание – это безопасность. Человек может работать с браузером самого неудобного интерфейса, но при этом он должен быть уверен в полной безопасности своих данных.

Безопасность Google Chrome считается самой надёжной, потому что он постоянно обновляется и имеет свой черный список вредоносных сайтов. Также при скачивании каких-либо файлов сначала выходит окно с подтверждением загрузки. Одним из минусов является то, что многие способы защиты в браузер не встроены. Они сделаны в виде плагинов и расширений. Для того, чтобы установить различные способы зашиты, их нужно приобрести в специальном веб-магазине.

Если взять браузер Opera, то здесь все несколько хуже. Так, например в безопасности данного браузера отсутствует фильтр вредоносного программного обеспечения и также отсутствует защита от компрометации HTTPS-соединений

Отличительной чертой хорошего браузера от плохого является скорость работы. Часто люди любят открывать большое количество вкладок, поэтому никто не будет в восторге от медленной работы при большом количестве открытых вкладок и медленной скорости загрузки страниц. В браузере Google Chrome находится движок JavaScript 8, который гарантирует отличную обработку данных. А технология упреждающего чтения позволяет загружать страницы очень быстро. Но для пользователей слабый ОС неприемлемо то, что будет повышенное потребление оперативной памяти.

Opera использует технологию “Turbo”, но, к сожалению, от этого скорость работы не увеличивается. Также многим пользователем данного браузера не нравится то, что утилиты обрабатываются с низкой скоростью. Чтобы избавиться от этого, пользователь должен правильно настроить и оптимизировать программу.

Таким образом, на данный момент самым передовым браузером является Google Chrome, он включает в себя все, что необходимо современному человеку: удобный аскетичный интерфейс, высокую скорость работы и главное - надёжную безопасность всех данных.

ЗАКЛЮЧЕНИЕ

СПИСОК ЛИТЕРАТУРЫ

https://scienceforum.ru/2017/article/2017031119