И. Соммервилл - Инженерия программного обеспечения (1133538), страница 141
Текст из файла (страница 141)
Диаграммы потоков данных — вто функциональное представление. где прямоугольник с закругленными краями представляет функцию, выполняющую преобразование данных, а стрелка — элемент данных, обрабатываемый функцией. Файлы и другие хранилища данных представлены в виде прямо. угольников. Диаграммы отображают сквозной процесс обработки, т.е. показывают все функции системы, которые взаимодействуют с данными. когда они (данные) проходят по разным стадиям обработки и преобразований. Для иллюстрации функционально. ориентированного проектирования с помощью диаграммы потоков данных рассмотрим рис.
26.8, па котором показана структура системы по расчету заработной платы. Это система пакетной обработки данных. Она считывает ин. формацию о служащих компании, затем рассчитываются платежи и отчисления эа месяц, после чего начисллется заработная плата. Рассмотрим, как зта система реализует сгрукту' ру "вход-процесс-выход". е.ие.
2блй Потокоопя дкаерпеаыа системы оыпоаты зарплат К функции "Считывание записи о служащем", "Считывание данных о платежах за месяц" и Проверка правильности данных о служащем" реализуют ввод и проверлу данных о каждом сотруднике. 542 ззасть 7П. Эволюция программного обеспечения 2. Функция "Расчет зарплаты" обрабатывает всю инфориацию об окладе до удержания налогов по каждому служащему, а также данные об отчислениях с зарплаты. Рсзуль. татом этого лвляется "чистал" зарплата за месяц. 3.
Функции вывода осуществляют запись в ряд файлов. в которых содержится отдель. пая информация по отчислениям с зарплаты. Эти файлы обрабатываются другими программами после того, как будет произведен расчет данных для всех служащих. Вслед за этим следует распечатка платежной ведолюсти, в которой указаны суммы выплат и отчислений. Удачным примером системы обработки транзакций является система, контролирую. щал сеть банкоматов.
На услуги, предоставляемые пользователям, не влияют предварительные операции, поэтому они могут рассматриваться как отдельные транзакции. В лис- тингс26П приведена упрощенная версия такой системы. Следует заметить, что вместо языка программирования )ата я использовал функционально. ориентированный язык Зага — объектно.ориентированный язык программирования, поэтому не подходит для описания функционально-ориентированнык систем.
Листинг 26.1. Описание системы управления банкоматами ВХОД 1оор гврвав Печать сообщение("Добро пожаловать) Вставьте Вашу карточку") чпсз1 Карточка ввод Счет номер := Считывание карточка; ПолУчение счет (РХН код, Счет баланс, Наличность доступность); ПРОЦБСС зг карточка недействительна (РХН код) Спвп Задержать карточку; Ргйпс ("карточка задержана — пожалуйста, свяжитесь с Вашим банком" ); в1вв гервас Печать операция выбор сообщение; Кнопка:= Получение кнопка; савв Получение кнопка зв мпеп Наличность только => Выдача наличность (Наличность доступна, Сумма выдача) мйвп Печать остаток => Печать клиент остаток (Счет остаток); мпвп Отчет -> Заказ отчет (Счет номер]г мпвп Чековая книжка => Заказ чековая книжка (Счет номер); впг( саве( Рггпа (" Нажмите ПРОДОЛЖИТЬ для других операций либо СТОЛ" )( Кнопка := Получение кнопка; ппвз1 Кнопка СТОП ВЫХОД Извлечь карточку; РгТпг (пПожалуйста, извлеките Вашу карточку"); Обновление счет (Счет номер, Счет выдача); впс( 1ооуп 26.
Наследуемые системы 543 В этом проекте работа системы реализуется в виде цикла, где операции начинают вьнюлняться после ввода пользователем карточки. Системные функции (Вьдача наличность, Получение счет, Заказ отчет, Заказ чековая книжка идр.) можно определить при реализации системы.
Контроль за состоянием системы, осуществляемый программой, минимален. Операции по обслуживанию клиентов выполняются индивидуально и нс взаимодействуют между собой. Очевидно, что функционально. ориентированное проектирование б>дет использоваться при разработке программных систем еще много лет. Конечно, эта технолош>я нс привязана к разработке наследуемых систем, она может использоваться и для создания новых систем в следующих ситуациях. 1. При создании систем обработки данных, основанных на работе с транзакциял>н и обновлении баз данных. Программа, обрабатывающая транзакции, нс нуждается в информации о предыдущих транзакциях, поэтому нет необходимости в объектах, работающих с локальными данными. Здесь наблюдается следование модели "вход- процесс-выход", которая рассмотрена выше.
2. В компаниях, вложили>их значительныс средства а структурные методь>, соответствующие СЛОЕ.средства и обучение персонала. Здесь будут нсоправданнымп риск и затраты, связанные с переходом па объектно-ориентированное проектирование. Хотя функциональном>риентнрованный подход во многом счи >мегся устарсвшил>, объектно.ориентированное прослтнрованис в подобных шп>цинян не будет оправданным. Такнье образом, перед нами стоит интересная задача: обеспечить совместную рабату дв>х подходов к программированию — объектноор>гентированного н функционально орпс> и нровапного.
26.3. Оценивание наследуемых систем Организации, деятельность которых во многом зависит от наследуемых систел> н средства которь>х на их сопровождение и людсрннзацню ограниченны, должны хороша подумать над тем, как получить максимум от вложений в наследуемую систему. Это прежде всего означает корректную оценку наслелусьюй системы н выбор наиболее подходащсй стратегии се модернизации. Существует четыре стратегических пути решения втой задачи. 1. Повиоолью омюмпюьея оэ> п>ео>емь>. Это решение применимо в сл>чае. сели система це отвечает своим задачам полдержки бизнес-процессов.
Например, со времени >становки системы бизнес-процегсы изменились настолько, что уже практически нс зависят от работы системы. Чаще всего это сл>чается там, где универсальные ЭВМ были заменень> псрсональныии компьютерами, а устаревшее программное обеспечение было модернизировано а той мере, в которой это необходимо для нр>щолжения его работы на ПК. 2. Продоевеиюь сопровождение е>ееомя>ы.
Это решение подходит в ситуашшх, когда снеге. ма более иьи лесное стабильна и все еще полезна в работе, а пользователи нс требуют ес значительного изменения. 3. >Ыодериив>>рооп>нь сиоисиу дяя уву оиения сопровождения. Этот путь следует выбрать тогда, когда качество работы системы снизилось и результате частых изменений, причем дальнейшие изменения все еще буд>т необходимы. 4. Зпяентпь ео>ярую п>сомну да>ее новой. Этот вариант применяется в том случае, если в связи с появлением современных аппаратных средств старая система становится непригодной в эксон>атацни нли сели уже имеются подобные системы и разработка новых на их основе не б>дет слишком дорогостоящей.
544 Часть з>П. Эволюция программного обеспечения Естественно, нет однозначного решения данной проблемы — к системс, состоящей из нескольких отдельных программ, можно применить несколько различных подходов. При оценивании наследуемую систему нужно рассматривать под разными углами зрения [339]. С коммерческой точки зрения необходимо провести оценку полезности и пригодности системы для бизнеса.
Что же касается перспективы дальнейшей работы аисте. мы, нужно в первую очередь оцензггь качество прикладного ПО, а также программных и аппаратных средств поддержки данной системы. Комбинация двух оценок- бизнес- пригодность и качество — поможет решить, что же делать с наследуемой системой дальше. Для демонстрации применения такой комплексной оценки рассмотрим организацию, использующую в работе 10 наследуемых систем. Качество и бизнес-пригодность каждой нз этих систем были оценены с помощью некоторых количественных показателей.
Результаты оцеиивания представлены на рис. 26.9. Высошя бизиоа. -пригоякасть тво Качества системы Рис. 26. й Бкгиеа-зфигодиоопь и кпчесимо сиппаи На рис. 26.9 видно четыре группы систем, которые определяются следующими оценками. 1. Низкое качество, иигипя б>мига->фигодпоппь Решение оставить такие системы в действии дорого обойдется, а отдача в бизнесе будет незпачителызой. Такие системы— прямые кандидаты на списание. 2.
Низкое кпчество, вмсоипл бшнеспригодиоси>ь Такие системы вносят немалый вклад в бизнес-деятельносттч поэтому списывать их нельзя. Однако низкий уровень качества означает высокие расходы на сопровождение системы. Такие системы подлежит модернизации или замене (при условии наличия другой подходящей системы). 3. Высокое кпчеевыо, >>ивков бигяеспригодкость Такие системы не очень полезны, но недороги в экспл)втации. Риск вследствие замены таких систем неоправдан, поэтому их можно оставить в работе и в дальнейшем списать. 4. Высмгое кпчеппво, выгокпя бигиег.>фигодпогви Их можно оставить, ведь высокое качество означает отсутствие иеобходниости модернизации или замены системы.
Поэтому с ними продолжаем работать, как и прежде. В идеала для решения того, что делать с системой дальше, должны испояьзоваться по. добные объективныс оценки. Однако неоднократно отмечалось, что в действительности при принятии таких решений главную роль играют оргапнзационпыс или политические соображения. Наприлзер, прн слиянии компаний булут использоваться спстслзы Г>олес 26.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
