И. Соммервилл - Инженерия программного обеспечения (1133538), страница 11
Текст из файла (страница 11)
в которой используется радиолокационная или какая-нибудь другая сепсорнал система для определения местонахождения самолетов (см. рис 2.3). На рис, 2.5 схематично показаны тс инженерные дисциплины, которыми должны владеть члены команды разработчиков системы. Рис. 2.5.
Инжвнврнмв дисцннвинаь вввлвкпвнмв в нрввесс снсэммввннкннн Для многих систем существует практически бесконечное количество способов деколе позиции (разбиения) системы на подсистемы. При этом специалисты разных профилей могут предлагать различные варианты структурной модели системы, которые будут со. держать разные функциоцзльныс компоненты. Тем самым возможен широчайший диапазон альтернативных моделей.
Выбор определенной модели не обязательно основывается только на технических аргументах. Пусть, например, одной из альтернатив в разработке СУП является установка новой радиолокационной системы вместо модернизации существующей. Если в команду разработчиков входят строители, то они могут настоять именно на этом варианте создания СУП, так как он обеспечит работой и их, и строительные подразделения, которые они прсдставллют. При этом для обоснования нужного варианта мо.
~ут, конечно, привлекаться и технические аргументы. Поскольку ПО по своей природе является гибким и сравнительно легко настраиваемым, часто решение многих неожиданно возникших проблем перекладывастсл на плечи специалистов по програимному обеспечению. Пусть, например, при создании СУП неудачно выбрано местоположение одной радарной установки — на экране локатора иногда происходит рзздвос нис изображений. Для удвленил этого эффекта необходимо передвин)ть радарную установку, что практически не осуществимо. Решением этой проблемы может быль создание специально. го ПО, которое поможет удалить раздвоение изображений.
Но в этом случае может потребо. ваться более мощная вычислительная техника, чем та. которая изначально загнанировзна, и зто, в свою очередь, также может стать определенной проблемой. Перед специалистами по программному обеспечению часто ставятся задачи, которые необходимо решать без увеличения стоимости аппаратных средств. Поэтому многие так называемые программные ошибки не являются следствием каких-либо "врожденных" черт или свойств ПО. Они могут быть результатом попытки модернизировать программное обеспечение в соответствии с изменениями требований, предъявляемых к создаваемой системс. Хорошим примером такой ошибки может служить сбой в системе управления багажом ваэропортуДенвера[329).
44 *%зать В Инженерня программного обеспечения: обзор 2.4.1. Определение системных требований На этапе определения системных требований формируются и формализуются требования к системе, рассматриваемой как единое целое. Как и при анализе требований к программному обеспечению, здесь также необходимы консультации с заказчиками системы и ес конечными пользователями. На этапе определения требований обычно формнр> ются требования трех типов.
1. Об1уиефуккуиоаальиые требпвшамь Основныс функции, выполняемые системой, определяются на самом высшем (абстрактном) уровне представления системы. Детализация функциональных требований происходит уже иа уровне подсистем. Например, при разработке СУП обязательно будет предусмотрено требование иметь базу данных полетов, совершенных в контролируемом системой воздушном пространстве. Оливка структура этой базы данных не будет определена до тех пор, пока пс будут отработаны требования к другим подсистемам.
2. Сиеэмл~иые свойсомп Это те ннтегрированныс свойства системы, которые обсужда. лись выше. Они мокнут включать такие свойства, как производительность. безотказность, защищенность и т.п. Эти нефункциональные свойства оказывают влияние на эсе требования, определяемые для подсистем. 3. Свойства, которьи дпвжкы оо1еуо~пнвовпть у пиожчьь Порой гораздо важнее указать, что система не должна делать, чем та, что она должна выполнять.
Например, в СУП необходимо потребовать, чтобы система не предоставляла операторам слишком много информации, только самую необходимую, не отвлекающую нх внимание. Важной частью этапа определения требований является описание множества целей, к выполнению которых должна стремиться система. Они не обязательно должны быть вы. ражены в терминах функциональньш свойств системы, но должны показать, как она будет себя вести в своем окружении. Чтобы проиллюстрировать описание множества целей, рассмотрим объединенную систему противопожарной безопасности и защиты от несанкционированного вторжения, предназначенную лля установки в офисном здании. Цели, которые основываются на функциональных возможностях системы, можно сформулировать следующим образам.
Сиетелш дпежнп обеспечить предупреждения о возеорпзшлх, возниктик внутри или вблизи здаиизл и змепикз>иоии>>овппнии л)ютшиовеаии в это эдакие. Эта цель точна описывает назначение системы, которая должна предупреждать о неких нежелательных событиях. Такал формулировка подходит для системы безопасности, которая уже существует и которая должна быть заменена. В противоположность этому люжно сформулировать более "широкую" цель.
Сиеомлзп дпежка гп)>пиэпфовазпь оокуоитвиесерьезиык нарушений в ко/иимытн функуионировании и эксплуп от уии зданил вследствие волго(заиий и кезпвоккыл ваиржгяий. Первая формулировка цели ограничивает возможности проектирования системы. В соответствии с ней от несанкционированных проникновений можно применить сложныс защитные средства даже без внутренней системы сигнализации, а для защиты от огня можно использовать автоматическую систему пожаротушения с разбрызгивателлми воды. Но такие средства мазут вывести из строя электрическую снстелг> и причинить серьезные неудобства работающим в здании.
Подчас основная тр>дность в определении системных требований состоит в том, что системз строится для того, чтобы помочь в решении "злостной" проблемы (кйс>лег> 2. Системотехнзпса вычислительных систем 45 ргоЫепз) 1294]. "Злостная" проблема — это проблема такой большой сложности и имею. щая столько взаимосвязанных входных воздействий, что ее невозможно точно описать, Истинная природа такой проблемы может проявиться только в процессе ее решения. В качестве экстремального примера "злостной" проблемы можно привести задачу предска.
зания землетрясений. В настоящее время не существует точных способов предсказания ни эпицентра землетрясения. ни его времени, ни силы, ни воздействия иа окружающую сре. ду. Поэтому невозможно заранее полностью спланировать все действия на случай большо. го землетрясения — это можно сделать только тогда, когда оно произойдет. 2.4.2. Проектирование систем Проектирование системы (рис. 2.6) заключается в определении систелщых компонентов на основе функциональных требований к системе. Процесс проектирования состоит из нескольких этапов.
Рис. 2.6. Зтлппм тфоектпироеппил гисоммм 1. Розбиепие мрпуовпиий нп в)тупплл Требования анализируются и разбиваются на отдельные группы. Обычно множество требований люжно разбить на группы многими способами, на этом этапе сохраняются все "жизнеспособные" разбиения. 2. Оп)тедомиие подсиапвм. Определяются подсистемы, которые индивидуалыю или совместно реализуют системные требования. Группа требований обычно ироецнруется иа несколько подсистем, поэтому можно объединить несколько требований в одно. Вместе с тем на определение систем влияют не только системные требова. ния, но и организационные или производственные факторы.
3. Рпепределение ж)мбовпний по подсиезммам. В принципе эта операция должна быть выполнена на предыдущем этапе определения подсистем. Но на практике не всегда можно четко согласовать разбиение требований и определение подсистем. Или, например, ограниченный ассортимент подсистем, приобретаемых у внешних по. сгавщиков (см. раздел 2А.З), может привести к пересмотру требований к системе. 4. Сяепифипи)товппие фуикииоптмьимх хп)токэиуппиши подапимм. Определяются фуикцио. нзльные характеристики каждой подсистемы. Если подсистема является программной, этот этап будет частью этапа создания спецификации для данной подсистемы. На этом этапе также формализуются взаимоотношения между подсистемами.
5. Опумдеаепие инзмрфейеов лодлиаппи. Для каждой подсистемы определяетсл свой нн. терфейс. Только после этого возможно начать разработку самих подсистем. На рис. 2.6 линии, соединяющие этапы, имеют стрелки на обоих концах. Это означает наличие обратной связи между этапами и возможность возвращаться к предыдущему этапу 46 Часть 1. Инженерия программного обеспечения: обзор в процессе проектирования системы. Очень часто приходится возвращаться к предыдущему этапу для решения возниюпих на данном этапе проблем. Для большинства систем можно разработать несколько проектов. Это предполагает широкий диапазон возможных решений, состоящих из разных комбинаций аппаратных и про.
граммных компонентов и человеческого фактора. Для дальнейшей разработки выбираегся решение, наиболее полна удовлетворяющее системным требованиям. Вместе с тем на выбор проекта часто влияют организационные и политические факторы. Например, если система разрабатываетсл по заказ) правительства, обычно выбиршотся национальные поставщики комплектующих, даже сели по определенным параметрам они (комплектующие) уступают зарубежным; это, естественно, влияет на выбор проекта системы. 2.4.3. Разработка подсистем На этом этапе реализ)ются тс подсистемы, которые были определены на этапе проектирования системы.
Для отдельных подсистем этап разработки может потребовать вклю. чения различных процессов снстсмотсхпикн. Так, если подсистема является программной системой, этап разработки будет вкзючать процессы формализации требований, проектировапил, создания и т.д. Иногда разработка всех подснстск) начинается "с нуля". Но чаще бывает так, что некоторые подсистемы можно приобрести на рынке промышленных изделий и затем интегрировать в создаваемую систему. Обычно бывает дешевле купить готовое изделие, чем разрабатывать собственную подсистему.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
