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

Содержание

Введение

1. Понятие автоматизированной информационной системы

1.1 Проектирование автоматизированных информационных систем

1.2 IDEF0-методология

1.3 DFD-методология

1.4 Описание предметной области

2. Постановка задач проектирования

2.1 Функциональная модель



Введение

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

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

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

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

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

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

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

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



1. Понятие автоматизированной информационной системы

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

По степени автоматизации ИС делятся на:

автоматизированные: информационные системы, в которых автоматизация может быть неполной (то есть требуется постоянное вмешательство персонала);

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

Автоматизированная информационная система (Automated information system, AIS) - это совокупность программных и аппаратных средств, предназначенных для хранения и (или) управления данными и информацией, а также для производства вычислений.

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

Выделяют четыре типа АИС:

Охватывающий один процесс (операцию) в одной организации;

Объединяющий несколько процессов в одной организации;

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

Реализующий работу нескольких процессов или систем в масштабе нескольких организаций.

При этом наиболее распространенными и перспективными считаются: фактографические, документальные, интеллектуальные (экспертные) и гипертекстовые АИС.

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

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

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

Информационная база состоит из 2-х взаимосвязанных частей: внемашинной и внутримашинной.

Внемашинная - это часть системы, воспринимаемая человеком без ЭВМ (документы, акты, счета, устная информация).

Внутримашинная содержится на машинных носителях и состоит из файлов.

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

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

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

Различают общее ПО (операционная система, системы программирования, сервисные программы) и прикладное ПО.

Организационное обеспечение АИС включает в себя собственный аппарат управления, обеспечивающий функционирование всех ее подсистем, как единое целое.

Такое структурное подразделение должно выполнять:

· Сбор первичной информации;

· Передачу или рассылку информации;

· Хранение и поддержку коллективного использования информации.

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

1.1 Проектирование автоматизированных информационных систем

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

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

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

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

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

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

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

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

Разработка информационной модели системы (проектирование структур баз данных и их связей).

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

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

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

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

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

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

Интеграция (сборка) системы в соответствии с выбранным методом и ее тестирование.

Этапы тестирования: автономное тестирование

- контроль отдельного программного модуля изолированно от других модулей, тестирование сопряжений

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

- испытание поведения системы по отношению к исходным целям, тестирование приемлемости - проверка соответствия системы требованиям пользователей.

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

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

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

Внедрение системы на объекте.

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

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

1.2 IDEF0-методология

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

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

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

Также отображаются все сигналы управления, которые на DFD (Диаграмме Потоков Данных) не отображались. Данная модель используется при организации бизнес-проектов и проектов, основанных на моделировании всех процессов: как административных, так и организационных.

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

Не смотря на то, что в настоящее время появляются десятки новых методологий моделирования деятельности предприятия и взглядов на её архитектуру, IDEF0 сохраняет актуальность для задач усовершенствования предприятий и организаций. Преимущества методологии IDEF0:

1) долгая история его использования для решения различных задач государственных и коммерческих предприятий;

2) продолжает использоваться и рекомендоваться в качестве стандарта описания деятельности организации и предприятия;

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

4) конкуренция и борьба за качество продукции увеличивает потребности современных предприятий в информатизации, тем самым, поставляя дополнительные задачи для системных аналитиков и проектировщиков;

5) последовательное и постоянное улучшение деятельности, усовершенствование, реорганизация и реинжиниринг предприятия, и т.д., выдвигает ряд системных требований по учёту многих факторов: Люди, Оборудование, Информация, Управление предприятием и Системы управления производственными процессами;

6) успешное моделирование различных аспектов деятельности предприятия позволяет формально выявить и собрать требования к проектируемой системе, а затем вести разработку системы, которая удовлетворяет этим требованиям;

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

8) нотация IDEF0 позволяет моделировать системные функции (работы, действия, операции, процессы), функциональные связи и данные (информацию и объекты), которые обеспечивают интеграцию системных комплексов. Разработанные модели представляют собой полноценное и взаимосвязанное описание деятельности предприятия или функционирования системы;

9) влияние внешней среды предприятия или системы может быть также объектом моделирования и исследования;

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



1.3 DFD-методология

DFD -- общепринятое сокращение от англ. Data Flow Diagrams -- диаграммы потоков данных.

Так называется методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ.

Диаграмма потоков данных (data flow diagram, DFD) -- один из основных инструментов структурного анализа и проектирования информационных систем, существовавших до широкого распространения UML. автоматизированный информационный электронный

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

Исторически сложилось так, что для описания диаграмм DFD используются две нотации -- Йодана (Yourdon) и Гейна-Сарсона (Gane-Sarson), отличающиеся синтаксисом.

На приведенной ниже иллюстрации использована нотация Гейна-Сарсона.

Информационная система принимает извне потоки данных.

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

Внутри системы существуют процессы преобразования информации, порождающие новые потоки данных.

Потоки данных могут поступать на вход к другим процессам, помещаться (и извлекаться) в накопители данных, передаваться к внешним сущностям.

Модель DFD, как и большинство других структурных моделей -- иерархическая модель.

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

Когда достигнута требуемая глубина декомпозиции -- процесс нижнего уровня сопровождается мини-спецификацией (текстовым описанием).

1.4 Описание предметной области

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

Оформление электронных билетов на сайте производится не позднее чем за 1 час до отправления поезда со станции посадки пассажира.

Продажа электронных билетов осуществляется на поезда, следующие:

· во внутреннем сообщении по территории Российской Федерации (формирования ОАО "РЖД", ОАО "ФПК", ОАО "ТКС", ЗАО ТК "Гранд Сервис Экспресс", ООО "Тверской экспресс") за исключением поездов, следующих в (из) Калининградскую область транзитом через территорию Литовской Республики;

· в международном сообщении со странами СНГ (Азербайджанская Республика, Республика Казахстан, Кыргызская Республика, Республика Беларусь, Украина, Республика Таджикистан, Туркменистан, Республика Узбекистан, Республика Молдова), Латвийской Республикой, Литовской Республикой, Эстонской Республикой, Республикой Абхазии;

· в международном сообщении (дальнее зарубежье) на поезда:

o №9 Москва - Варшава (в опытном режиме);

o №17/18 Москва - Ницца - Москва;

o №21/22 Москва - Прага - Москва, включ ая беспересадочные вагоны: Москва - Вена - Москва, Москва - Карловы Вары - Хеб - Москва, Санкт-Петербург - Прага - Санкт-Петербург;

o №23/24 Москва - Париж - Москва;

o №32 Москва - Хельсинки и скоростные поезда "Аллегро" отправлением из России в Финляндию.

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

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

Электронные билеты при наличии свободных мест в системе "Экспресс" можно приобрести:

· не ранее 45 суток* до отправления поезда с пунктов формирования поездов железных дорог Абхазии, Таджикистана (продажа билетов начинается в 8 час. 00 мин. по московскому времени);

· не ранее 45 суток* до отправления поезда с пунктов формирования поездов железных дорог Казахстана и Киргизии (продажа билетов начинается в 6 час. 00 мин. по московскому времени);

· не ранее 45 суток* до отправления поезда с пунктов формирования поездов железных дорог Украины, Белоруссии, Литвы, Латвии, Эстонии, Молдовы, Узбекистана (продажа билетов начинается в 9:00 по московскому времени);

· не ранее 45 суток* до отправления поезда с пунктов формирования поездов железных дорог из Украины, Белоруссии, Литвы, Латвии, Эстонии, Молдовы (продажа билетов после перехода Европы на зимнее время будет открываться в 10 час. 00 мин. по московскому времени);

· от 3 суток до отправления поезда с промежуточной станции (если иное не предусмотрено перевозчиком);

· не ранее 60 суток* до отправления поездов международного сообщения (дальнее зарубежье), на поезда № 1/2 Москва - Киев, № 19/20 Москва - Харьков, № 1/2 Санкт-Петербург - Москва, № 1/2 Москва - Казань, № 3/4 Санкт-Петербург - Москва, № 9/10 Москва - Саратов, № 21/22 Москва - Ульяновск, № 25/26 Москва - Воронеж, № 29/30 Москва - Липецк, № 31/32 Москва - Тамбов, № 35/36 Нижний Новгород - Москва, № 141/142 Москва - Чебоксары. Продажа билетов начинается в 8:00 по московскому времени.

* в период смены расписания срок открытия продажи может быть изменен (последний выходной день мая и первая декада декабря).

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

В одном заказе может быть оформлено не более 4 электронных билетов с указанием персональных данных 4 пассажиров.

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

Оформление электронных билетов на сайте не производится в период технологического перерыва системы "Экспресс" с 3 ч. 30 мин. до 4 ч. 00 мин. по московскому времени.

Особенности оформления электронных билетов:

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

При оформлении заказа на проезд в VIP - вагоне (категория "мягкий" с классом обслуживания "1А", "1М" или "1Н") электронный билет выдается с оплатой целого купе, в котором могут проехать один или два пассажира. В случае оформления проезда в одном купе двух пассажиров должны быть указаны персональные данные каждого пассажира.

Оплата целого купе для проезда в VIP - вагоне поездов 17/18 Москва - Ницца - Москва, 23/24 Москва - Париж - Москва (категории "мягкий" с классом обслуживания "1Г") не обязательна.

При оформлении заказа на проезд в купейных вагонах, вагонах СВ и VIP - вагонах поездов формирования ОАО "ФПК" (в т.ч. вагоны "ТКС"), ЗАО ТК "Гранд Сервис Экспресс", ООО "Тверской экспресс" и ОАО "ПКС", в стоимость электронных билетов включена плата за пользование комплектом постельного белья. При оформлении заказа на проезд в плацкартном вагоне поездов формирования ОАО "ФПК" для удобства пассажира предлагается оплатить стоимость проезда вместе со стоимостью постельного белья, при отказе от оплаты стоимости постельного белья при оформлении заказа пассажир сможет оплатить стоимость комплекта постельного белья в поезде проводнику вагона.

Стоимость проезда в поездах международного сообщения:

· со странами СНГ, Латвийской Республикой, Литовской Республикой, Эстонской Республикой, Республикой Абхазии определяется в швейцарских франках;

· со странами Европы (дальнее зарубежье) определяется в евро.

Оплата проезда на сайте осуществляется в рублях по официальному курсу ЦБ РФ на день оформления электронного билета.

Информацию о владельце вагона Вы получаете в момент оформления заказа при выборе вагона.

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

Заполнение данных о пассажирах:

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

Формат ввода номера российского паспорта нового образца (ПН):

· Серия: четыре цифры, номер: шесть цифр. Количество пробелов не имеет значения.

Формат ввода номера паспорта формы СССР (ПС):

· Серия: римские цифры (в латинском регистре), две буквы кириллицей, номер: шесть цифр. Количество тире и пробелов значения не имеет.

Формат ввода номера заграничного паспорта (ЗП):

· Номер: 9 цифр.

Формат ввода номера свидетельства о рождении, выданного в Российской Федерации (СР):

· Серия: римские цифры (в латинском регистре), две буквы кириллицей, номер: шесть цифр. Количество тире и пробелов значения не имеет.

При заполнении номера документа, удостоверяющего личность, символ "№" не указывается.

Данные паспорта или свидетельства о рождении, выданные гражданам иностранных государств, вводятся с заданием типа документа "иностранный документ (ЗЗ)".

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

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

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



2. Постановка задач проектирования

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

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

2.1 Функциональная модель



В АИС поступает заявка на покупку билета, ИС заказа билета обрабатывает информацию и связывается с БД, которая формируется, получая информацию от руководства РЖД и касс.

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

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

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

...