Разработка ПО ИС покупки билетов в железнодорожной кассе

    Модель  ЖЦ ПО включает в себя:

1. стадии;
2. результаты выполнения работ;
3. ключевые события – точки завершения работ и принятия решений.

    Модель  ЖЦ любого конкретного ПО определяет характер процесса создания, который представляет собой совокупность упорядоченных во времени, взаимосвязанных и объединенных в стадии работ, выполнение которых необходимо и достаточно для создания ПО, соответствующего заданным требованиям. Под стадией понимается часть процесса создания ПО, ограниченная определенными временными рамками и заканчивающаяся выпуском конкретного продукта (моделей, программных компонентов, документации), определяемого заданными для данной стадии требованиями.

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

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

    Принципиальными свойствами так называемой «чистой» каскадной модели являются следующие:

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

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

    Преимущества  применения каскадной модели заключаются в следующем:

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

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

 

Рис 3.1. Каскадная схема разработки ПО ИС 

    Основными недостатками каскадного подхода являются:

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

 
 
 
 
 

4. Структурный подход к разработке ПО ИС

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

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

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

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

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

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

• SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы;
• DFD (Data Flow Diagrams) диаграммы потоков данных;
• ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь".

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

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

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

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

    Моделирование потоков данных (процессов)

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

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

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

Рис.4.1. Начальная контекстная диаграмма 

    Моделирование данных

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

    Нотация ERD была впервые введена П. Ченом (Chen) и получила дальнейшее развитие в работах Баркера.

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

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

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

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

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

 

    Рис. 4.2. Концептуальная модель данных

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

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

    Детализируя начальную контекстную диаграмму, получаем диаграмму потоков данных нулевого уровня (рис. 4.3.). 

 

    Рис. 4.3. Диаграмма потоков данных нулевого уровня

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