И. Соммервилл - Инженерия программного обеспечения (1133538), страница 146
Текст из файла (страница 146)
1. Какижмао и сложность сисиммнмк изкииРфкйсов. Чем больше системных ии.герфейсов и чем более сложными они являютсл, тем выше вероятность изменений в будущем. 2, К~мичссиню измпысиых сисэммнмк мРеймлний. Как уползиналось в главе 6, требования, отражающие деловую сферу или стандарты органиэации, чаще изменяются, чеи требования, описывающие предиетпую область.
3. Бтккэироусссьс в комодик нснакьзуеикл дпккля систсмзк По мере развития бизнеспроцессы приводят к появлению новых требований к системе. Чтобы корректно спрогнозировать процесс сопровождения, нужно знать количество и типы взаимосвязей между разными компоиепгами системы, а также учитывать сложность этих компонентов. Различные виды сложности систем изучались в работах [151, 2321. Другие исследования посвящены взаимосвязям между сложностью систем и процессом сопровождения [18, 195[. Все эти исследования показали, что, чем выше сложность системы и ее компонентов, тем более дорогостояпким окажется сопровождение, чего и следовало ожидать. 27. Модернизации программного обеспечении 561 Ряс.
27.7. 77рогюмнровп наг сокро нож денна Прогнозирование количества запросов на изменения системы зависит от понимания взаииосвязей между системой и ее окружением. Некоторые системы находятся в достаточно сложной взаимозависимости с внешним окружением и изиенение окружения обя. зательно повлияет на систему.
Для того чтобы правильно судить об этих взаимоотио~пениях, необходимо оценить следующие показатели. 1. Когичгсмва к слолгноаяа сисэимннх инэмрфейгоа Чем больше системных интерфейсов и чем более сложными они являются, тем выше вероятность изменений в будущем. 2. Кагнчгсэмо изменяемых аитммкых тргдовяний Как упоминалось в главе 6, требования, отражающие деловую сферу или стандарты организации, чаще измепяютсл, чем требования, описывающие предметную область. 3. Бизнес-нРоцгссы, в хеэмРмх ислааьздчягса данклл сксэимж По мере развития бизнеспроцессы приводлт к появлению новых требований к системе. Чтобы корректно спрогнозировать процесс сопровождения, нужно знать количество и типы взаимосвязей между разными компонентами системы, а также учитывать сложность этих компонентов.
Различные виды сложности систем изучались в работах [151, 232]. Другие нссле. дования посвлщены взаимосвязям между сложностью систем и процессои сопровожлсвгл [18, 195]. Все этн исследования показали, что, чем выше сложность системы н ее компонентов, тем более дорогостоящим окажется сопровождение, чего и следовало ожидать. В работе [16] проведено исследование ряда коммерческих програмлг, написанных на языке СОВО1„с использованием разных методик измерения сложности, включая размер 662 хрясть УП. Эволюция программного обеспечения процедур, размер модулей и количество ветвлений, что определяет сложность системы. Сравниван сложность отдельных системных компонентов с отчетами по сопровождению, исследователи обнаружили, что снижение сложности программирования значительно со.
кращает расходы на сопровождение системы. Измерение >ровня сложности систем оказалось весьма полезным для выявления тех компонентов систем. которые будут особенно сложны для сопровождения. Результаты анализа ряда системных компонентов [195] показали, что сопровождение часто сосредоточено на обслуживании небольшого количества частей системы, которые отличаются особой сложностью, Поэтому экономически выгодно заменить сложные системные компоненты более простыми нх версиями. После введения системы в эксцл>атацию появляются данные, позволяющие прогнозировать дальнейшее сопровождение системы.
Перечисленные ниже показатели полезны для оценивания удобства сопровождения. 1. Каеичепаво занРоеов на хоРРекошРовку сиенммьь Возрастание количества отчетов о сбоях в системе означает увеличение количества ошибок, подлежащих исправлс. нпю нрп сопровождении. Это говорит об ухудшении удобства сопровождения. 2. С)ееднее время, ноэфаченное на анаеиз аринин системных ебеев и огнхозов.
Этот показатель пропорционален количеству системных компонентов, в которые требуется внести изменения. Если этот показатель возрастает, система требует многочисленных изменений. 3. С~едкое в)>емл. необходимое на реаеивацию изиенекюй. Нс следует пугать этот показатель с предыдущим, хотя онн тесно связаны. Здесь учитывается не время анализа снеге. мы по выявлению причин сбоев, а время реализации изменений и нх докумеитиро. ванна, которое зависит от сложности программного кода. Увеличение этого показателя означает сложность сопровождения. 4. Кащчееюво нееаверменнмх зааротв на'изменения.
С возрастанием количества таких запросов затрудняется сопровождение системы. Длл определения стоимости сопровождения используется предварительная информация о запросах на изменения,н прогнозирование относительно удобства сопровождения системы. В решении этого вопроса большинству менеджеров поможет также инзуиция и опыт. В модели определения стоимости СОСОМО 2, описанной в главе 23, предполагается, что для оценки стоимости сопровождения понадобятся сведения об усилиях, потраченных па понимание существующего кода системы и на разработку нового. 27.3. Эволюция системной архитектуры В процессе сопровождения большинство изменений проводится локализовано и не влияет па архитектуру системы.
Однако начиная с 19ВО.х годов экономические показатели компьютерных систем изменилась настолько, что стало более выгодно применять распределенные, а не централизованные, как раныпс, системы. Поэтому многие компании поставлены перед необходимостью преобразовать свои централизованные системы, реализованные на мэйнфреймах, в распределенные системы типа клиент/сервер (системы клиент/сервер ощшапы в главе 11). Перечислим основныс причины перехода от централизованных к распределенным системам. 27. Модернизация программного обеспечения 56$ 1. Сэьлсивпвь алая|Оп|иных еревеим. Закупка и сопровождение распрепеленных систем клиент/сервер обойдется гораздо дешевле, чем покупка мэйнфрейма эквивалентной мощности.
2. УамеРиияетв|маяие лаеьзвваимвьп|их ияямрр|ейевв. Многие из наследуемых систем, основанных иа мэйнфремах, имеют текстовые интерфейсы. основанные па формах. Сегодня пользователям привычнее графические интерфейсы и более простое взаимодействие с системами. Такого рода интерфейсы требуют большего количества локалы|ых вычислений и более эффективно работают в системах типа клиент/сервер. 3. Раеиредыекный двпяул к еисвммалс Сейчас все больше компаний стараются децентрализовать рабочис места, что требует децентрализации компьютерных систем.
При этом необходимо, чтобы компьютерные системы были доступны из разных мест и с разного оборудования. Например, сотрудники могут получить доступ к системам из собсгвенного дома, и такую практик2 нужно поддерживать. С псреходои на распределенную архитею уру компьютерных систем организации значителыю снижают расходы на аппаратное обеспечение н способны создать систему с бо. лес удобным интерфейсом и более современным дизайном, а также ыог)т поддерживать практику распределенной работы. В этом переходном периоде неизбежно должно про.
изойти преобразование системы к объектно.ориентированной модели, что, в свою очередь, может снизить затраты на сопровождение системы в будущем. Однако нужно отметить, что преобразование архитектуры наследуемой системы является сложной задачей и требует больших расходов. Прежде чем приступить к этом» про.
цессу, необходимо провести тщательный анализ наследуемой системы, чтобы оцепить ре. альную пользу от преобразования систем|юй архитектуры. Основная трудность при децентрализации наследуемых систем заключается в тои, что в их структуре не существует четкого разграниченил между архитекгурными компонентами.
Идеальной (и желательной) считается структура системы, показанная на рнс. 27.8. В этом случае есть четкое разделение интерфейса пользователи, сервисов, предоставляемых системой, и базы данных. При этом сервисы четко различимы. В системе с такой структурой легко определить распределяемые компоненты, которые:можно перепрограммировать и запустить на машинах клиентов. Модель системы, Рвзльиыв иаслздуеыыа системы идеальной для децентрализации Рис.
27л2 Идепвьяал и Реальная олрухл|урм |июнем 564 к2асть УП. Эволвкция программного обеспечения Но реальные наследуемые системы напоминают систему, представленную на рис. 27.8 справа, в которой интерфейс пользователя, сервисы и доступ к данным перемежаются. Интерфейс пользователя и сервисы реализованы с помощью одних и тех же компонентов, нет четкого разделения между сервисами и базой данных системы. В таких условия опре. деление компонентов.
подлежащих распределению, практически невозможно. В случаях. когда невозможно разделять наследуемую систему на распределлемые компоненты, следует применить альтернативный подход. Наследуемая система преобразуется в сервер, интерфейс пользователя реализуется на машине клиента, а промежуточное ПО обеспечивает взаимосвязь запросов, поступающих с машины клиента, с наследуемой системой. Этот подход показан на рис. 27лй Пр«лакан«с, эыпонннэысэ на ПК кянснюа мая снстема Текстовые гарин«злы Рно. 27. 9, ПРгобР«зоошим наслеоуеной снсэымы о РослР«)оконную Несмотря на интеграцию интерфейса пользователя и предоставляемых наследуемой системой сервисов, все-таки при планировании децентрализации лучше рассматривать их в качестве отдельных логических уровней (рис.
27.10). 1. Уровень представления отвечает за организацию вывода на экран информации для конечных пользователей системы, .~нолли лн 2. Уровень проверкй данных связан с >правлением вводом-выводом данных, осущест. влясмым конечна>ми пользователями. 3. Уровень управления взаимодействием определяется последовательностью операций конечных пользователей и порядком смены экранов, отображающихся на ма. шинах конечных пользователей. 4.
Уровень сервисов приложения отвечает эа выполнение основных вычнслени11 приложением. Ул Уровень базы данных отвечает за хранение и управление данными приложения. Создавать распределенную базу данных для большинства наследуемых систем невыгодно, но для распределения других уровней существует целый ряд альтернатив, которые показаны на рис.
27.11. В простейшем случае компьютер клиента предоставлнет только интерфейс пользователя, все другие уровни реализованы на сервере. Противоположный случай — сервер управляет только базой данных, все остальные операции выполняет машина клиента. Естественно, что эти варианты распределения не являются взаимоисключающими. Можно начать с распределения уровня представления, а при наличии ресурсов и времени можно распределить др>тие логические уровни. В главе 11 рассмотрены другие варианты распределенных систем. 27, Модернизация программного обеспечения 665 Представление Управление взаимодействием Баэз данных Рне.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
