
- •Введение
- •1.Определение требований к информационной подсистеме
- •Словесное описание содержания бизнес-процесса
- •Выбор метода моделирования информационных процессов в хозяйственной деятельности организации
- •Выбор метода
- •Определение требования к информационной подсистеме
- •Варианты использования проектируемой информационной подсистемы действующими лицами бизнес-процесса
- •Диаграмма деятельности, моделирующая бизнес-процесс
- •2.Разработка проекта информационной подсистемы
- •Спецификации вариантов использования информационной подсистемы
- •2.1.1.Анализ бизнес- процессов
- •2.1.1.1 Концепция функционирования информационной подсистемы
- •2.1.1.2 Бд, используемые информационной подсистемой
- •2.1.1.3 Процедуры обработки сведений в бд
- •Уточнение концепции состава и назначения программных средств и таблиц бд web - сайта авиакомпании
- •Интерфейсы пользователей информационной подсистемы. Запросы пользователей
- •Диаграммы интерфейсных классов, классов управления и сущностей
- •• Ассоциации (например, клиент может сделать заказ);
- •• Подтипы (частный клиент является разновидностью клиента)
- •Ассоциации классов. Диаграммы последовательности и кооперативные
- •Диаграммы ассоциации классов (показаны на Рисунке 2.3.1):
- •Атрибуты и методы классов
- •3.Класс поисковика
- •4.Класс «Начальная страница Web-сайта»
- •5.Класс с sql-операторами
- •Диаграмма развертывания, показывающая состав аппаратного и обеспечивающего по информационной подсистемы
- •6.Заключение
- •Приложение 1 глоссарий проекта
МИНИСТЕРСТВО ФИНАНСОВ МОСКОВСКОЙ ОБЛАСТИ
КОРОЛЁВСКИЙ ИНСТИТУТ УПРАВЛЕНИЯ, ЭКОНОМИКИ И СОЦИОЛОГИИ
Кафедра информационных технологий и управляющих систем
КУРСОВОЙ ПРОЕКТ
по дисциплине «Проектирование информационных систем»
на тему
«Информационная подсистема коммерческого отдела авиакомпании по продаже билетов на авиарейсы клиентам, отсутствующим в списке «клиенты постоянные»»
Выполнила студентка группы ИО-04 Нистратова М.В.
Принял к.т.н., доцент Федотов Ю.А.
Королёв
2012
РЕФЕРАТ
Курсовая работа: 56с., 14 рис., 4 табл., 4 источника.
Объектом и предметом исследования является информационная подсистема коммерческого отдела авиакомпании по продаже билетов на авиарейсы клиентам, отсутствующим в списке «клиенты постоянные».
Целью работы является изучение процесса проектирования информационной система на примере проектирования информационной подсистемы коммерческого отдела авиакомпании по продаже билетов на авиарейсы клиентам, отсутствующим в списке «клиенты постоянные».
В процессе работы проведены следующие исследования и разработки:
определены функциональные требования к проектируемой информационной подсистеме;
разработана диаграмма деятельности, моделирующая бизнес-процесс;
составлены варианты использования проектируемой информационной подсистемы действующими лицами бизнес-процесса;
разработана диаграмма классов, взаимодействующих в ИС;
разработаны диаграммы последовательности и кооперативные;
разработана диаграмма развертывания;
проведена оценка стоимости создания информационной подсистемы и стоимости используемых в подсистеме аппаратных средств.
Областью возможного практического применения являются коммерческие отделы авиакомпаний, желающие заняться (или занимающиеся, но желающие модернизировать существующую ИС) продажей билетов на авиарейсы через Internet.
Автор подтверждает, что курсовой проект выполнен самостоятельно, правильно и объективно отражает состояние исследуемого процесса, а все заимствованные из литературных и других источников теоретические, методологические и методические положения и концепции сопровождаются ссылками на их авторов. _______________________
(подпись студента)
СОДЕРЖАНИЕ
ВВЕДЕНИЕ 5
1. ОПРЕДЕЛЕНИЕ ТРЕБОВАНИЙ К ИНФОРМАЦИОННОЙ ПОДСИСТЕМЕ 8
1.1. Словесное описание содержания бизнес-процесса 8
1.2. Выбор метода моделирования информационных процессов в хозяйственной деятельности организации 9
1.2.1. Описание процессного подхода к моделированию 9
В основу процессного подхода положен принцип функциональной декомпозиции, при которой структура системы описывается в терминах иерархии ее функций и передачи информации между отдельными функциональными элементами. 9
1.2.2. Описание объектного подхода к моделированию 11
Объектно-ориентированный подход использует объектную декомпозицию, при этом статическая структура системы описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами. 11
1.2.3. Выбор метода 14
1.3. Определение требования к информационной подсистеме 16
1.3.1. Варианты использования проектируемой информационной подсистемы действующими лицами бизнес-процесса 16
1.3.2. Диаграмма деятельности, моделирующая бизнес-процесс 20
1.4. Выводы 23
2. РАЗРАБОТКА ПРОЕКТА ИНФОРМАЦИОННОЙ ПОДСИСТЕМЫ 24
1.5. Спецификации вариантов использования информационной подсистемы 24
1.6. Интерфейсы пользователей информационной подсистемы. Запросы пользователей 29
1.7. Диаграммы интерфейсных классов, классов управления и сущностей 36
Диаграммы классов являются центральным звеном объектно-ориентированных методов. Диаграмма классов определяет типы объектов системы и различного рода статические связи, которые существуют между ними. Имеются два основных вида статических связей: 36
• ассоциации (например, клиент может сделать заказ); 36
• подтипы (частный клиент является разновидностью клиента) 36
1.8. Ассоциации классов. Диаграммы последовательности и кооперативные 37
1.9. Атрибуты и методы классов 44
3. Класс поисковика 44
4. Класс «Начальная страница Web-сайта» 44
5. Класс с SQL-операторами 45
1.10. Диаграмма развертывания, показывающая состав аппаратного и обеспечивающего ПО информационной подсистемы 45
1.11. Выводы 47
6. ЗАКЛЮЧЕНИЕ 48
ПРИЛОЖЕНИЕ 1 ГЛОССАРИЙ ПРОЕКТА 49
Введение
Проектирование экономических информационных систем (ЭИС) — логически сложная, трудоемкая и длительная работа, требующая высокой квалификации участвующих в ней специалистов. Однако до настоящего времени проектирование ЭИС нередко выполняется на интуитивном уровне неформализованными методами, включающими в себя элементы искусства, практический опыт, экспертные оценки и дорогостоящие экспериментальные проверки качества функционирования ЭИС. Кроме того, в процессе создания и функционирования ЭИС информационные потребности пользователей постоянно изменяются или уточняются, что еще более усложняет разработку и сопровождение таких систем.
Основная доля трудозатрат при создании ЭИС приходится на прикладное программное обеспечение (ПО) и базы данных (БД). Производство ПО сегодня — крупнейшая отрасль мировой экономики, в которой занято около трех миллионов специалистов (программистов, разработчиков ПО и т. п.).
В процессе становления и развития программной инженерии можно выделить два этапа: 70-е и 80-е гг. — систематизация и стандартизация процессов создания ПО (на основе структурного подхода) и 90-е гг. — начало перехода к сборочному, индустриальному способу создания ПО (на основе объектно-ориентированного подхода).
В основе программной инженерии лежит одна фундаментальная идея: проектирование ПО является формальным процессом, который можно изучать и совершенствовать. Освоение и правильное применение методов и средств создания ПО позволят повысить качество ЭИС, обеспечить управляемость процесса проектирования ЭИС и увеличить срок ее жизни.
Для успешной реализации проекта объект проектирования (ПО ЭИС) должен быть, прежде всего, адекватно описан, т.е. должны быть построены полные и непротиворечивые модели архитектуры ПО, обусловливающей совокупность структурных элементов системы и связей между ними, поведение элементов системы в процессе их взаимодействия, а также иерархию подсистем, объединяющих структурные элементы.
Под моделью понимается полное описание системы ПО с определенной точки зрения. Модели представляют собой средства для визуализации, описания, проектирования и документирования архитектуры системы. По мнению одного из авторитетнейших специалистов в области объектно-ориентированного подхода Гради Буча, моделирование является центральным звеном всей деятельности по созданию качественного ПО. Модели строятся для того, чтобы понять и осмыслить структуру и поведение будущей системы, облегчить управление процессом ее создания и уменьшить возможный риск, а также документировать принимаемые проектные решения.
Конечная цель разработки ПО — это не моделирование, а получение работающих приложений (кода). Диаграммы в конечном счете — это всего лишь наглядные изображения, поэтому, используя графические языки моделирования, очень важно понимать, чем они помогут при написании кода программ.
В 70-80-х гг. при разработке ПО достаточно широко применялись структурные методы, базирующиеся на строгих формализованных методах описания ПО и принимаемых технических решений (в настоящее время такое же распространение получают объектно-ориентированные методы). Эти методы основаны на использовании наглядных графических моделей: для описания архитектуры ПО в различных аспектах (как статической структуры, так и динамики поведения системы) используются схемы и диаграммы. Наглядность и строгость средств структурного и объектно-ориентированного анализа позволяют разработчикам и будущим пользователям системы с самого начала неформально участвовать в ее создании, обсуждать и закреплять понимание основных технических решений. Однако широкое применение этих методов и следование их рекомендациям при разработке конкретных ЭИС сдерживалось отсутствием адекватных инструментальных средств, поскольку при неавтоматизированной (ручной) разработке все их преимущества практически сведены к нулю. Действительно, вручную очень трудно разработать и графически представить строгие формальные спецификации системы, проверить их на полноту и непротиворечивость и тем более изменить. Если все же удается создать строгую систему проектных документов, то ее переработка при появлении серьезных изменений практически неосуществима. Ручная разработка обычно порождала следующие проблемы: неадекватная спецификация требований, неспособность обнаруживать ошибки в проектных решениях, низкое качество документации, снижающее эксплуатационные характеристики, затяжной цикл и неудовлетворительные результаты тестирования.
Перечисленные проблемы породили потребность в программно-технологических средствах специального класса — CASE(Computer Aided Software Engineering) -средствах, реализующих CASE-технологию создания и сопровождения ПО ЭИС.
CASE-технология представляет собой совокупность методов проектирования ЭИС, а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на всех стадиях разработки и сопровождения ЭИС и разрабатывать приложения в соответствии с информационными потребностями пользователей. Большинство существующих CASE-средств основано на методах структурного или объектно-ориентированного анализа и проектирования, использующих спецификации в виде диаграмм или текстов для описания внешних требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств.