Размещено на http://www.allbest.ru/

Введение

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

Термин «разработка программного обеспечения» является более общим и часто используемым, по сравнению с термином Программная инженерия и не обязательно включает в себя парадигмы инженерии. Однако вряд ли можно сказать, что использование этого метода оказало сколько-нибудь ощутимый вклад в развитие реальной разработки ПО на протяжении уже более чем 40 лет.

Термин «инженерия программного обеспечения» появился впервые в 1968 году на Конференции НАТО «Инженерия программного обеспечения» и предназначался, чтобы спровоцировать поиск решений для происходившего в то время «кризиса программного обеспечения». С тех пор, это переросло в профессию и область исследований, посвященных созданию программного обеспечения, более качественного, доступного, лучше поддерживаемого, и быстрее разрабатываемого.

Так как область все еще относительно молода по сравнению со своими сестринскими областями инженерии, есть все еще большая работа и дебаты вокруг того, что представляет собой «инженерия программного обеспечения», и удовлетворяет ли оно понятию инженерии. Этот спор развивается естественным образом, начавшись с попыток рассматривать создание программного обеспечения только как программирование. Разработка программного обеспечения -- термин, иногда предпочитаемый практиками в промышленности, которые рассматривают разработку программного обеспечения как несравнимо более мощную и конструкционноёмкую методологию в сравнении с процессом написания кода программистом.

Все же, несмотря на юность профессии, будущее области радужно, поскольку, Money Magazine и Salary.com оценили профессию разработчика программного обеспечения как лучшую работу в Америке в 2006.

Разработка программного обеспечения связана с дисциплинами информатики, управления проектами, и инженерии систем.

Когда первые современные цифровые компьютеры появились в начале 1940-х годов, наборы исполняемых команд уже были встроены в машину. Специалисты быстро поняли, что этот подход не слишком удобен. Так появилась “архитектура хранимых программ” или архитектура фон Неймана. Таким образом, деление на "железо" и "программное обеспечение" началось с абстракции, используемой чтобы решить проблему сложности вычислений.

аэропорт регистрация диаграмма моделирование



1. Стойка регистрации на рейс

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

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

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



1.1 Стандартные стойки регистрации в аэропорту

Несмотря на прогресс, привычные стойки регистрации, расположенные внутри в аэропортах, продолжают оставаться самым распространенным выбором для пассажиров, особенно на международных рейсах, хотя с каждым годом количество людей, пользующихся этим способом регистрации, значительно уменьшается. Это обычные регистрационные стойки, которые существуют уже очень давно в аэропортах, возле которых пассажиры с обычными или электронными билетами «отмечаются» перед вылетом их рейса. Если речь идет о пассажирах международных рейсов, то обычно сотрудники, работающие за такими стойками, просят их в дополнение к билету на рейс предъявить паспорт. Такой метод регистрации для авиакомпаний несет дополнительные расходы в аэропорту, по сравнению с регистрацией на сайте, поэтому, например, компания AirBaltic с 1 февраля 2013 года ввела оплату за регистрацию в аэропорту в размере 10 Евро за одного пассажира.

Также за этими стойками пассажиры «расстаются» со своим багажом, после того, как его взвешивают и прикрепляют к нему бирки. Обычно за стандартными стойками регистрации можно расплатиться за перевозку багажа, а также обсудить с сотрудником авиалиний предпочтения по выбору места в салоне самолета или заказать особое блюдо для обеда в воздухе. Самой главной обязанностью сотрудника стойки регистрации является распечатка посадочного талона, чтобы пассажир мог без проблем пройти к терминалу и дожидаться посадки на рейс.

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

1.2 Стойки регистрации у входа

Эти стойки мало чем отличаются от стандартных стоек регистрации в аэропорте, так как ваш багаж и билет также проверяет сотрудник авиалиний. Отличительной особенностью является расположение этих стоек. Как правило, они находятся у входа в аэропорт (в главный зал), вблизи парковочных зон. Процесс регистрации проходит так же, как и у обычной стойки регистрации внутри аэропорта, с одной лишь только разницей - пассажиры оставляют багаж и получают посадочные талоны перед тем, как переступают «порог» входа в аэропорт.

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

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



2. Диаграмма вариантов использования

Диаграммы вариантов использования UML (англ. Unified Modeling Language) описывают взаимоотношения и зависимости между группами вариантов использования и действующих лиц, участвующими в процессе. Важно понимать, что диаграммы вариантов использования не предназначены для отображения проекта и не могут описывать внутреннее устройство системы. Диаграммы вариантов использования предназначены для упрощения взаимодействия с будущими пользователями системы, с клиентами, и особенно пригодятся для определения необходимых характеристик системы. Другими словами, диаграммы вариантов использования говорят о том, что система должна делать, не указывая сами применяемые методы.

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

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

2.1 Назначение диаграмм вариантов использования

Диаграммы ВИ применяются при бизнес-анализе для моделирования видов работ, выполняемых организацией, и для моделирования функциональных требований к ПС при ее проектировании и разработке. Построение модели требований при необходимости дополняется их текстовым описанием. При этом иерархическая организация требований представляется с помощью пакетов use cases.

2.2 Построение диаграммы вариантов использования

Рисунок 1



3. BPMN диаграмма

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

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

BPMN поддерживает лишь набор концепций, необходимых для моделирования бизнес-процессов. Моделирование иных аспектов, помимо бизнес-процессов, находится вне зоны внимания BPMN. Например, моделирование следующих аспектов не описывается в BPMN:

· Модель данных

· Организационная структура

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

Моделирование в BPMN осуществляется посредством диаграмм с небольшим числом графических элементов. Это помогает пользователям быстро понимать логику процесса. Выделяют четыре основные категории элементов:

· Объекты потока управления: события, действия и логические операторы

· Соединяющие объекты: поток управления, поток сообщений и ассоциации

· Роли: пулы и дорожки

· Артефакты: данные, группы и текстовые аннотации.



4. Методология функционального моделирования IDEF0

IDEF0 - графическая нотация, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является её акцент на соподчинённость объектов. В IDEF0 рассматриваются логические отношения между работами, а не их временнамя последовательность (поток работ).

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

· стрелка входа приходит всегда в левую кромку активности,

· стрелка управления -- в верхнюю кромку,

· стрелка механизма -- нижняя кромка,

· стрелка выхода -- правая кромка.

Описание выглядит как «чёрный ящик» с входами, выходами, управлением и механизмом, который постепенно детализируется до необходимого уровня. Также для того чтобы быть правильно понятым, существуют словари описания активностей и стрелок. В этих словарях можно дать описания того, какой смысл вы вкладываете в данную активность либо стрелку. Также отображаются все сигналы управления, которые на DFD (диаграмме потоков данных) не отображались. Данная модель используется при организации бизнес-процессов и проектов, основанных на моделировании всех процессов: как административных, так и организационных.

История создания IDEF0 как стандарт был разработан в 1981 году департаментом Военно-воздушных сил США в рамках программы автоматизации промышленных предприятий, которая носила обозначение ICAM (Integrated Computer Aided Manufacturing).

Набор стандартов IDEF унаследовал своё название от этой программы (IDEF расшифровывается как ICAM Definition). В процессе практической реализации, участники программы ICAM столкнулись с необходимостью разработки новых методов анализа процессов взаимодействия в промышленных системах.

В результате поиска соответствующих решений родилась методология функционального моделирования IDEF0. С 1981 года стандарт IDEF0 претерпел несколько незначительных изменений, в основном, ограничивающего характера, и последняя его редакция была выпущена в декабре 1993 года Национальным институтом по стандартам и технологиям США.

4.1 Построение методологии функционального моделирования IDEF0

Рисунок 2



5. ER-диаграмма

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

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

Во многих случаях информационная модель очень сложна и содержит множество объектов.

Сущность изображается в виде прямоугольника, вверху которого располагается имя сущности (например, TITLES). В прямоугольнике могут быть перечислены атрибуты сущности; атрибуты ER-диаграмм, набранные полужирным шрифтом, являются ключевыми (так Title Identity - ключевой атрибут сущности TITLES, остальные атрибуты ключевыми не являются).

Отношение изображается линией между двумя сущностями (синие линии на рисунке).

Одиночная линия справа означает "один", "птичья лапка", слева - "многие", а отношение читается вдоль линии, например "один ко многим". Вертикальная черта означает "обязательно", кружок - "не обязательно", например для каждого издания в TITLE обязательно должен быть указан издатель в PUBLISHERS, а один издатель в PUBLISHERS может выпускать несколько наименований изданий в TITLES. Следует отметить, что связи всегда комментируются (надпись на линии, изображающей связь).

Рисунок 3. Построение ER-диаграммы



6. Диаграмма состояний

Каждая диаграмма состояний в UML описывает все возможные состояния одного экземпляра определенного класса и возможные последовательности его переходов из одного состояния в другое, то есть моделирует все изменения состояний объекта как его реакцию на внешние воздействия.

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

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

6.1 Понятие состояния объекта

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

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

Состояние на диаграмме изображается прямоугольником со скругленными вершинами. Прямоугольник может быть разделен на две секции горизонтальной линией. Если указана лишь одна секция, то в ней записывается только имя состояния. При наличии двух секций, в первой из них записывается имя состояния, а во второй список некоторых внутренних действий или переходов в данном состоянии. Под действием в языке UML понимают некоторую атомарную операцию, выполнение которой приводит к изменению состояния или возврату некоторого значения (например, «истина» или «ложь»).

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

При использовании диаграммы состояний важно следовать следующим правилам:

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

· Диаграмма состояний должна быть сосредоточена на описании только одного аспекта поведения объекта. Следует создавать диаграмму автомата, моделирующую поведение только одного объекта. Если необходимо показать поведение нескольких, взаимосвязанных объектов, допустимо создавать для них диаграмму состояний в рамках определенного варианта использования (диаграмма состояний для варианта использования).

· На диаграмме состояний целесообразно использовать только те элементы, которые существенны для понимания описываемого аспекта.

6.2 Построение диаграммы состояний

Рисунок 4



7. Структура системы

· Структура системы - это устойчивая упорядоченность ее элементов и связей.

· Структура есть форма представления некоторого объекта в виде составных частей.

· Структура - это множество всех возможных отношений между подсистемами и элементами внутри системы.

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

· Структура системы - это то, что остается неизменным в системе при изменении ее состояния, при реализации различных форм поведения, при совершении системой операций и т.п. 8.2 Понятие «Структура системы»

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

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

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

Система выделяется человеком из внешнего "фона" по функциональным или пространственным признакам (например, живые и технические системы - скорее по пространственному; экономические, организационные - по функциональному).

Системы, как правило, имеют различные структуры.

7.1 Обзор структуры «Регистрации пассажира в аэропорту»

· Отправляясь в аэропорт, необходимо проверить наличие у себя билета, паспорта и визы, в случае необходимости.

· Для детей необходимо иметь проездной документ или свидетельство о рождении.

· В терминале каждого аэропорта на стойках 1-n кол-во проводится регистрация пассажиров и багажа на рейсы всех направлений.

· Начало регистраций зависит от требований авиакомпаний и количества пассажиров на данном рейсе.

· Обычно, на регулярные международные полеты регистрация начинается за 2 - 3 часа до вылета и заканчивается за 60 - 40 минут до отправления.

· Регистрация на внутренние рейсы открывается - за полтора часа и завершается за 30 минут.

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

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

· Правила регистрации пассажиров и багажа устанавливаются каждой авиакомпанией-перевозчиком отдельно.

7.2 Обзор системы «Регистрации пассажира в аэропорту»

Пассажир должен отдать сотруднику авиакомпании свой паспорт. Если пассажир летит с пересадкой, то необходимо попросить и маршрутную квитанцию.

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

Чемодан необходимо поставить на весы, чтобы его взвесили. Если у пассажира имеется объемная и тяжелая ручная кладь, то могут попросить поставить на весы и её.

После взвешивания на багаж приклеят багажную бирку со штрих-кодом и увезут в багажное отделение для проверки и доставки в самолет.

Если пассажир летит с пересадкой, то в большинстве случаев багаж можно зарегистрировать до конечного пункта. Таким образом, при пересадке не понадобится его получать и сдавать снова.

Если пассажир летит зимой в «теплые» страны, то можно попросить зарегистрировать чемодан только до места пересадки -- так у пассажира будет возможность переодеться из зимних вещей в летние. После чего придется снова пройти процедуру регистрации. Стоит обратить внимание, что это возможно только в том случае, если имеется достаточно долгая пересадка.

У сотрудника авиакомпании можно попросить предоставить пассажиру определенные места в самолете, например, у окна или, наоборот, в проходе. Возле аварийного выхода сажают не всех, т.к. к пассажирам на этих местах есть определенные требования -- сюда не посадят хрупких девушек на каблуках или семью с ребенком.

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

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



Вывод

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

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

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



Список использованной литературы

1. Регистрация на рейс авиакомпании. Пособие для туристов //[Электронный ресурс]//Доступ: https://ifly.ua/news/15/

2. Грейди Буч, Джеймс Рамбо, Айвар Джекобсон. UML. Руководство пользователя. М. ДМК 2000. 432 с.

3. Калянов Г.Н. CASE структурный системный анализ (автоматизация и применение). - М.: ЛОРИ, 1996.

4. Уэнди Боггс, Майкл Боггс «UML и Rational Rose 2002» /Пер. с англ. - М. «Лори», 2004.

5. А.М. Вендров. CASE-технологии. Современные методы и средства проектирования информационных систем. М.: Финансы и статистика, 1998, -176с.

6. Маклаков С.В. ERWin и BPWin. CASE средства разработки информационных систем. - М.: Диалог-МИФИ, 1999.

7. Джеймс Рамбо, Айвар Якобсон, Гради Буч «UML Специальный справочник». - СПб.: «Питер», 2002.

8. Кватрани Т. Rational Rose 2000 и UML. Визуальное моделирование: Пер. с англ. - М.: ДМК Пресс, 2001 - 176с.: ил.

9. Кознов Д.В «Языки визуального моделирования: проектирование и визуализация программного обеспечения. Учебное пособие» СПб.: Изд-во СПбГУ, 2004, 143 с.

10. Леоненков А.В «Объектно-ориентированный анализ и проектирование с использованием UML и IBM Rational Rose» М.: Интернет-Университет Информационных Технологий; БИНОМ. Лаборатория знаний, 2006, 319 с.

11. Кознов Д.В Программная инженерия. Часть I. Методическое пособие СПб.: Изд-во СПбГУ, 2005, 40 с.

Размещено на Allbest.ru