Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Проектирование информационных систем. Учебное пособие
.pdf
нала и прохождение стажировки на предприятиях родственного профиля, где такая система уже эксплуатируется.
11. Сопровождение. Выезд специалиста для устранения послед-
ствий аварийных ситуаций, техническое обучение, методическая
и практическая помощь при необходимости внесения изменений в систему, установка новых релизов программного обеспечения [3].
1.5. ЖИЗНЕННЫЙ ЦИКЛ
ИНФОРМАЦИОННОЙ СИСТЕМЫ
Жизненный цикл – это модель
создания и использования инфор-
мационной системы, отражающая непрерывный процесс, который
начинается с момента принятия решения о необходимости ее создания
и заканчивается в момент ее полного изъятия из эксплуатации.
Основным нормативным документом, регламентирующим жизненный цикл информационных систем, является международный стандарт
ISO/IEC 12207 (ISO – International Organization of Standardization – Международная организация по стандартизации, IEC – International Electro-
technical Commission – Международная комиссия по электротехнике
).
Структура жизненного цикла информационной системы по стандарту ISO/IEC 12207 базируется на трех группах процессов.
1. Основные процессы жизненного цикла, являющиеся ключевыми
процессами при использовании информационной системы в организации: процессы приобретения, поставки, разработки, функционирования, сопровождения.
2. Вспомогательные процессы жизненного цикла, являющиеся процессами эксплуатации и сопровождения информационной системы,
способствующими поддержанию нормального
функционирования организации и соответствия ее параметров требованиям, предъявляемым
современными условиями, включают в себя следующие мероприятия:
процессы решения проблем, документирования, управления конфигурацией, обеспечения качества, верификации, аттестации, совместной
оценки, аудита.
3. Организационные процессы жизненного цикла, обеспечивающие
организацию деятельности по созданию, эксплуатации и сопровождению информационной системы, включают в себя управление проектом,
создание инфраструктуры проекта АИС, усовершенствование АИС,
обучение персонала.
11
Процессы жизненного цикла информационной системы, регламентируемые стандартом ISO/IEC 12207, могут использоваться различными организациями в конкретных проектах самым разным образом. Тем
не менее стандарт предлагает некоторый базовый набор взаимосвязей
между процессами с различных точек зрения или в различных аспектах. Такими аспектами являются договорной аспект, аспект управления, аспект эксплуатации, инженерный аспект
, аспект поддержки.
В рамках жизненного цикла информационной системы выделяют
следующие стадии.
1. Самой первой стадией жизненного цикла информационной си-
стемы является анализ и планирование требований. Это важнейшая
стадия, при ее реализации закладываются основные свойства разрабатываемого программного продукта и планируется дальнейшая деятельность по его созданию. Результатом стадии анализа и
планирования
требований будет список функций разрабатываемой информационной
системы с указанием их приоритетов и предварительные функциональные и информационные модели системы.
2. Второй стадией жизненного цикла информационной системы яв-
ляется ее проектирование, закладывающее основу для последующих
стадий. На этой стадии информационная система начинает существовать в форме детальной модели, описывающей все ее
свойства. Резуль-
татом стадии проектирования будет следующее.
2.1. Общая информационная модель системы.
2.2. Функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков.
2.3. Точно определенные интерфейсы между автономно разрабатываемыми подсистемами.
2.4. Прототипы экранов, диалогов и отчетов.
3. После проектирования информационной системы наступает этап
построения – реализация системы
на программном уровне. Результатом построения будет готовая информационная система, удовлетворяющая всем требованиям пользователей.
4. После построения информационной системы наступает следую-
щая стадия ее жизненного цикла – внедрение и сопровождение: пуск
в эксплуатацию и обслуживание программного продукта организацией-разработчиком.
5. Последней стадией жизненного цикла информационной системы
является изъятие материально или
морально устаревшей системы из
эксплуатации.
12
Под моделью жизненного цикла информационной системы понимается структура, определяющая последовательность выполнения
и взаимосвязи процессов, действий и задач на протяжении всего периода жизни системы. Модель жизненного цикла информационной системы зависит от специфики, масштаба, сложности проекта и специфики условий, в которых система создается и функционирует.
Модель жизненного цикла любого
обеспечения (ПО) определяет характер процесса его создания – совокупность упорядоченных во времени, взаимосвязанных и объединенных в стадии работ, выполнение которых необходимо и достаточно для
создания ПО, соответствующего заданным требованиям. К настоящему
времени наибольшее распространение получили следующие две основные модели жизненного цикла информационной системы: каскадная модель (1970–1985
ципиальная особенность каскадного подхода (рис. 1.1) заключается
в том, что переход на следующую стадию осуществляется только после
того, как будет полностью завершена работа на текущей стадии, и возвратов на пройденные стадии не предусматривается. Каждая стадия
заканчивается получением некоторых результатов, использующихся
в качестве исходных данных для
гг.) и спиральная модель (1986–1990 гг.). Прин-
следующей стадии.
конкретного программного
Рис. 1.1. Каскадная модель жизненного цикла информационной системы
13
Требования к разрабатываемой информационной системе, определенные на стадии формирования требований, строго документируются
в виде технического задания и фиксируются на все время разработки
проекта. Каждая стадия завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. Критерием качества разработки при таком подходе
технического задания. Процесс создания информационной системы
носит, как правило, итерационный характер: результаты очередной
стадии часто вызывают изменения в проектных решениях, выработанных на более ранних стадиях. Таким образом, постоянно возникает потребность в возврате к предыдущим стадиям и уточнении или пересмотре ранее принятых решений. В
здания информационной системы принимает иной вид (рис. 1.2). Такую схему часто относят к отдельной модели – так называемой модели
с промежуточным контролем, в которой межстадийные корректировки
обеспечивают большую надежность по сравнению с каскадной моделью, хотя и увеличивают весь период разработки.
является точность выполнения спецификаций
результате реальный процесс со-
Рис. 1.2. Реальный процесс разработки информационной системы
В середине 1980-х гг. была предложена спиральная модель жизненного цикла (рис. 1.3). Ее принципиальной особенностью является сле-
14
дующее: прикладное программное обеспечение создается не сразу, как
в случае каскадного подхода, а по частям с использованием метода
прототипирования.
Рис. 1.3. Спиральная модель жизненного цикла
информационной системы
Под прототипом понимается действующий программный компонент, реализующий отдельные функции и внешние интерфейсы разрабатываемой информационной системы. Создание прототипов осуществляется в несколько итераций, или витков спирали. Каждая итерация соответствует созданию фрагмента или версии информационной
системы, на ней уточняются цели и характеристики проекта, оценивается качество полученных результатов и планируются
щей итерации. На каждой итерации производится тщательная оценка
риска превышения сроков и стоимости проекта, чтобы определить
необходимость выполнения еще одной итерации, степень полноты
и точности понимания требований к системе, а также целесообразность прекращения проекта [1, 3].
работы следую-
15
2. АРХИТЕКТУРА
ИНФОРМАЦИОННЫХ СИСТЕМ
2.1. ПОНЯТИЕ АРХИТЕКТУРЫ
ИНФОРМАЦИОННЫХ СИСТЕМ
Архитектура информационной системы – это способ организации программного кода и компонентов, который определяет модель,
структуру и выполняемые информационной системой функции, а также характеризует взаимосвязь всех ее компонентов. Таким образом,
исходя из определения, архитектура информационной системы представляет собой описание ее основных компонентов и модулей с
ципами их работы и взаимосвязи друг с другом. Архитектура также
отображает различные вариации развития и эволюции информационной системы.
Архитектура информационной системы включает в себя следующие компоненты.
1. Слой представления – клиентская часть с графическим интерфейсом пользователя (Graphical User Interface, GUI), которая выполняет
функцию терминала, т. е. средства представления данных и отправки
команд. Часто этот слой называют «frontend».
2. Слой бизнес-логики, где происходит обработка команд, получен-
ных от клиента, и выполняются основные вычисления. Чаще всего этот
слой реализуется в виде серверного приложения (backend). Здесь же
располагается система управления базой данных (СУБД), которая позволяет обратиться к данным и манипулировать ими.
3. Слой доступа к
данных в структурированном виде.
При разработке информационных систем применяется послойная
модель, включающая в себя все перечисленные компоненты. Такая
модель носит название трехслойной архитектуры, ее структура приведена на рис. 2.1.
данным, т. е. сама база данных как хранилище
прин-
16
Рис. 2.1. Трехслойная архитектура информационной
системы
Несмотря на общую структуру, реализация трех слоев может быть
выполнена по-разному. Так, если все компоненты слоев находятся на
одном устройстве (компьютер, мобильный телефон), то такая архитектура называется настольной (desktop). Если компоненты слоев информационной системы распределены по нескольким устройствам, то архитектура называется распределенной (distributed) [4].
2.2. ЧИСТАЯ АРХИТЕКТУРА
Чистая архитектура (Clean Architecture) – это
рования программного обеспечения, предложенная Робертом Мартином, цель которой – создание гибкой, масштабируемой и легко тестируемой архитектуры, отделяющей бизнес-логику от деталей реализации (баз данных, пользовательских интерфейсов, фреймворков и др.).
Основными отличительными особенностями чистой архитектуры
являются следующие.
1. Независимость от фреймворков, что позволяет снизить зависи-
мость бизнес-логики
от различных технических ограничений.
17
концепция проекти-
2. Возможность тестирования бизнес-правил без привлечения UI,
базы данных, серверов или любых других внешних элементов.
3. Возможность разделения программного кода на слои с четко
определенными правилами для упрощения перехода от одного к другому.
4. Независимость от UI, позволяющая легко изменить пользова-
тельский интерфейс без изменения остальной системы.
5. Независимость от баз
правила не связаны с типом хранения данных.
Основные компоненты и их взаимодействие показаны на рис. 2.2.
данных, обусловленная тем, что бизнес-
Рис. 2.2. Чистая архитектура
Ключевыми компонентами чистой архитектуры являются следующие.
1. Сущности (Entities) – это объекты, содержащие критически важные данные для бизнеса и методы для управления этими данными. Они
не зависят от UI, баз данных или любых других элементов инфраструктуры, что делает их независимыми от изменений во внешних слоях и позволяет сохранять стабильность бизнес
всего жизненного цикла программного продукта.
18
-правил на протяжении
2. Use Cases содержат специфичную для приложения бизнес-ло-
гику, они описывают конкретные действия, которые пользователь может выполнить с системой. В чистой архитектуре они реализуются
в виде независимых от UI и баз данных классов, что обеспечивает гибкость и упрощает тестирование.
3. Контроллеры и ведущие служат связующим звеном между Use
Cases и пользовательским интерфейсом
либо другими методами до-
ставки информации, например API. Контроллеры отвечают за обработку входящих запросов, они являются связующим звеном между пользовательским интерфейсом и бизнес-логикой. Их задача – получить
данные от пользователя, преобразовать при необходимости и передать
дальше по цепочке. Ведущие занимаются подготовкой данных для
отображения. Они берут на себя работу
по форматированию данных из
моделей в удобный для пользователя вид, что может включать в себя
выбор нужной информации, ее сортировку или локализацию. Использование этих двух компонентов позволяет избежать смешения бизнеслогики с пользовательским интерфейсом, что является ключевым для
поддержания чистоты кода.
4. Внешние интерфейсы (Interface Adapters) – это точки интеграции
системы с внешним
миром, к ним относятся базы данных, сетевые
службы или пользовательский интерфейс. В чистой архитектуре они
располагаются на внешних слоях и общаются с бизнес-логикой через
определенные границы, преобразуют данные в формат, удобный для
использования Use Cases или сущностями.
Такая концепция архитектуры базируется на принципе DDD
(Domain Driven Design), согласно которому дизайн системы должен
быть основан на
предметной области, т. е. вся система строится прежде
всего на сущностях и связях предметной области, а уже потом на деталях реализации, таких как базы данных, фреймворки и др.
Одним из основных принципов DDD является дистилляция объектов предметной области в сущности системы. Такой дизайн подразумевает, что сущность должна поддерживать
свой инвариант, т. е. непротиворечивое состояние объекта. Инвариант класса не может поддерживаться другим классом, так как другой класс не должен знать про внутренние правила первого. Таким образом, изменения объекта должны
проходить через его внутреннюю логику валидации.
Чистая архитектура напрямую сочетается с концепцией RDM (Rich
Domain Model), в которой бизнес-сущности реализуют
методы работы
19
с самими собой и следят за своими инвариантами. Противоположной
концепцией домена является ADM (Anemic Domain Model), в которой
бизнес-сущности не обладают никакой логикой и представляют собой
простые наборы своих свойств.
Чистая архитектура с RDM-концепцией позволяют реализовывать
информационные системы в сложных предметных областях. При этом
концепция RDM требует хорошей проработки предметной области, за
счет чего разработка
на старте будет идти медленнее. Концепция ADM
позволяет отложить проработку предметной области, обеспечивая более быстрый старт [4, 5].
2.3. АРХИТЕКТУРА CQRS
CQRS (Command Query Responsibility Segregation) – это шаблон
проектирования, который разделяет операции на две категории: команды (изменяют состояние системы) и запросы (получают данные, не изменяют состояние системы). Основной смысл этого подхода состоит
в том, что для
режимов чтения и записи данных используются разные
модели данных. Благодаря этому можно адаптировать модель данных
для чтения таким образом, чтобы она облегчала загрузку данных и их
передачу клиенту.
Основными принципами подхода CQRS являются следующие.
1. Разделение команд и запросов на разные модели, что позволяет
использовать различные подходы к обработке каждого компонента
повысить производительность и масштабируемость системы в целом.
и
2. Отказ от ORM (Object-Relational Mapping) в пользу использова-
ния агрегатов (Aggregates), которые представляют собой связанные
сущности в приложении и содержат логику изменения их состояния.
3. Применение асинхронной обработки, позволяющей выполнять
несколько операций одновременно, что ускоряет обработку запросов и
команд.
Архитектура на основе подхода CQRS показана на рис. 2.3.
Компоненты CQRS можно разделить на две категории: компоненты
записи и компоненты чтения. Компоненты записи:
1) Command – это объект, который содержит данные, необходимые
для выполнения операции записи в системе. Command может быть отправлен из любой части системы, например из веб-приложения;
20
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]