Объекты бизнес-системы, разрабатывающей программное обеспечение

из "Реинжиниринг бизнеса - Реинжиниринг организаций и информационные технологии "

Идеальные объекты бизнес-системы, участвующие в прецеденте Разработка Программного Обеспечения, изображены на рис. 8.2. Здесь для ясности изложения основной идеи приведены только семь типов объектов. На практике полная О-модель бизнес-системы по разработке программного обеспечения включает сотни типов объектов, из которых около 30% относятся к интерфейсным и управляющим, а все остальные - к сущностям. [c.210]
Цель сбора требований состоит в получении пожеланий, предъявляемых к информационной системе клиентами и самой компанией. Полученные сведения используются для выявления важнейших требований и определения примерных сроков разработки. Результатом работы является список требований. [c.211]
Наличие модели бизнес-системы в значительной мере помогает сформулировать требования к функциям информационной системы. Кроме этих требований, необходимо собрать и более специфические требования об используемом оборудовании, базах данных и т.д. [c.211]
Задача анализа требований - установить границы информационной системы и определить, какие функции она должна выполнять. П-модель информационной системы следует рассматривать как своеобразный контракт между разработчиком и заказчиками. [c.212]
Если модель бизнес-системы существует, то разработка П- модели поддерживающей информационной системы осуществляется непосредственно из О-модели бизнеса (см. разд. 8.4). Если такой модели еще нет, то П-модель строится исходя из представлений потенциальных пользователей системы. [c.212]
П-модель информационной системы состоит из прецедентов, субъектов и описаний интерфейсов конечного пользователя. Нередко работа начинается с составления набросков интерфейсов, выполняемого совместно с пользователями системы. Затем, после уточнения представлений о системе, приступают к созданию прототипов. [c.212]
В анализе требований участвуют следующие объекты бизнес-системы Заказчик Продукта, Аналитик, Список Требований, Спецификация Требований и П-модель (рис. 8.4). Заказчик Продукта отвечает за инициирование разработки в соответствии со Списком Требований. Анализ требований имеет итеративный характер. Он описывается следующим образом. [c.212]
Разумеется, реальные спецификации составляют десятки страниц, и мы не хотим приводить их полностью. Наша цель - проиллюстрировать основные понятия. [c.213]
В системе АКА выделим двух субъектов. Первый субъект - Клиент Банка, для которого в первую очередь и создается информационная система. Система АКА должна взаимодействовать с центральной финансовой системой банка, содержащей данные о клиентах и счетах. Эта Финансовая Система есть второй субъект. Выделим четыре прецедента Снятие Денег, Перевод Денег, Запрос Баланса и Вложение Денег (рис. 8.5 и 8.6). [c.214]
Описание прецедента Снятие Денег может выглядеть следующим образом. [c.214]
Снятие Денег начинается с того момента, когда Клиент Банка вставляет кредитную карточку в кассовый аппарат. Система проверяет, имеет ли силу (действительна ли) эта карточка. Если нет, то прецедент завершается (см. ниже КОНЕЦ). [c.214]
Система запрашивает информацию о счете и о той сумме денег, которую следует выдать Клиенту Банка. Система повторяет запрос до тех пор, пока сумма не станет кратной 20. Система проверяет, располагает ли данный кассовый аппарат запрашиваемой суммой денег. Если нет, то прецедент завершается (см. КОНЕЦ). Система АКА обращается к Финансовой Системе с запросом о наличии достаточной суммы денег на счете клиента. Если сумма на счете меньше запрашиваемой, то прецедент завершается (см. КОНЕЦ). Если на счете достаточно денег, то система выдает деньги и печатает расходный ордер. Сумма на счете Клиента Банка уменьшается соответствующим образом. КОНЕЦ Аппарат возвращает кредитную карточку прецедент завершается. [c.214]
Объекты, участвующие в прецеденте Снятие Денег, приведены на рис. 8.8. С помощью отношений коммуникации изображена схема взаимодействия этих объектов в ходе выполнения прецедента. Приведем описание выполнения прецедента Снятие Денег в терминах объектов информационной системы. [c.216]
Если карточка действительна, то Графическому Интерфейсу Пользователя поручается запросить у клиента его персональный идентификатор (PIN). После ввода идентификатора Обработчик Транзакций считывает его и сравнивает с кодом, введенным с карточки. В случае несовпадения клиенту предлагается ввести персональный идентификатор повторно. В том случае, когда в течение трех попыток клиент не может правильно указать свой идентификатор, аппарат оставляет у себя карточку, и сеанс завершается (см. КОНЕЦ). [c.217]
После ввода правильного идентификатора Обработчик Транзакций поручает Графическому Интерфейсу Пользователя выдать на экран список возможных операций и предлагает клиенту сделать выбор. Ответ клиента возвращается Обработчику Транзакций. [c.217]
Если клиент выбрал операцию Снятие Денег, Обработчик Транзакций запускает Обработчик Операции Снятия, который начинает свою работу с проверки наличности в аппарате Если ее нет, то сеанс завершается (см. КОНЕЦ). [c.217]
Если в аппарате есть наличные деньги, то Обработчик Операции Снятия запрашивает у Графического Интерфейса Пользователя информацию о номере счета клиента и о требуемой ему сумме. Эта информация должна вводиться клиентом. Запрос повторяется до тех пор, пока требуемая сумма не оказывается кратной 20. [c.217]
Если требуемая сумма превышает размер наличности в Кассе, то сеанс завершается (см. КОНЕЦ). [c.218]
Обработчик Операции Снятия через Интерфейс Финансовой Системы запрашивает подтверждение банка на проведение операции. [c.218]

Вернуться к основной статье