Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Нис_ИО-04_КП_безОценкиТруд.doc
Скачиваний:
0
Добавлен:
01.04.2025
Размер:
1.11 Mб
Скачать

1.Определение требований к информационной подсистеме

    1. Словесное описание содержания бизнес-процесса

Коммерческий отдел авиакомпании предложил расширить свой Web-сайт, чтобы пользователи смогли:

  • узнать о выполнении рейсов текущего дня;

  • запросить информацию о расписании рейсов, стоимости билетов и наличии мест;

  • купить билеты.

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

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

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

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

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

  • систему управления счетами, хранящую информацию о постоянных клиентах и балансе «премиальных километров»;

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

  • базу данных тарифов;

  • базу данных наличия билетов.

    1. Выбор метода моделирования информационных процессов в хозяйственной деятельности организации

      1. Описание процессного подхода к моделированию

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

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

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

  • принцип решения сложных проблем их разбиения на множество меньших независимых задач, легких для понимания и решения;

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

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

  1. SADT (Structured Analysis and Design Technique) – модели и соответствующие функциональные диаграммы;

  2. DFD (Data Flow Diagrams) – диаграммы потоков данных;

  3. ERD (Entity-Relationship Diagrams) – диаграммы «сущность-связь».

На стадии формирования требований к ПО SADT-модели и DFD используются для построения модели "AS-IS" и модели "ТО-ВЕ", отражая, таким образом, существующую и предлагаемую структуру бизнес процессов организации и взаимодействие между ними (использование SADT-моделей, как правило, ограничивается только данной стадией, поскольку они изначально не предназначались для проектирования ПО). С помощью ERD выполняется описание используемых в организации данных на концептуальном уровне, не зависимом от средств реализации базы данных (СУБД).

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

На стадии проектирования системы модели расширяются, уточняются и дополняются диаграммами, отражающими ее структуру.

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

      1. Описание объектного подхода к моделированию

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

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

Концептуальной основой объектно-ориентированного подхода является объектная модель. Основными ее элементами являются:

• абстрагирование (abstraction);

• инкапсуляция (encapsulation);

• модульность (modularity);

• иерархия (hierarchy).

Кроме основных имеются еще три дополнительных элемента, не являющихся в отличие от основных строго обязательными:

• типизация (typing);

• параллелизм (concurrency);

• устойчивость (persistence).

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

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

Модульность — это свойство системы, связанное с возможностью ее декомпозиции на ряд внутренне связных, но слабо связанных между собой модулей. Инкапсуляция и модульность создают барьеры между абстракциями.

Иерархия — это ранжированная или упорядоченная система абстракций, расположение их по уровням. Основными видами иерархических структур применительно к сложным системам являются

структура классов (иерархия по номенклатуре) и структура объектов (иерархия по составу).

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

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

Устойчивость — свойство объекта существовать во времени (вне зависимости от процесса, породившего данный объект) и/или в пространстве (при перемещении объекта из адресного пространства, в котором он был создан).

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

В настоящее время для объектно-ориентированного моделирования проблемной области широко используется унифицированный язык моделирования UML (Unified Modeling Language).

Система объектно-ориентированных моделей в соответствии с нотациями UML включает в себя следующие диаграммы:

  1. Информационная система (Use-case diagram), которая отображает функциональность ЭИС в терминах бизнес-процессов;

  2. Диаграммы классов-объектов (Class diagram), которая отображает структуру совокупности взаимосвязанных классов объектов;

  3. Диаграммы состояний (Statechart diagram), каждая из которых отображает динамику состояний объектов одного класса и связанных с ними событий;

  4. Диаграммы взаимодействия объектов (Interaction diagram), каждая из которых отображает динамическое взаимодействие объектов в рамках одного прецедента использования;

  5. Диаграммы деятельности (Activity diagram), которые отображают потоки работ во взаимосвязанных прецедентах использования (могут декомпозироваться на более детальные диаграммы);

  6. Диаграммы пакетов (Package diagram), которые отображают распределение объектов по функциональным или обеспечивающим подсистемам (могут декомпозироваться на более детальные диаграммы);

  7. Диаграмму компонентов (Component diagram), которая отображает физические модули программного кода;

  8. Диаграмму размещения (Deployment diagram), которая отображает распределение объектов по узлам вычислительной сети.