И. Соммервилл - Инженерия программного обеспечения (1133538), страница 19
Текст из файла (страница 19)
Обатцемнпл пеплы гфоцесеп нРоекишРовпнил 3. Процесс создания программного обеспечения 69 Описанная схема процесса проектирования является досгаточно общей и на практике может (и должна) адаптироваться применительно к разработке конкретного программного продукта. Например, два последних этапа, проектирование структур данных и алгоритмов, могут быть как составными частями процесса проектирования, так и входить в процесс реализации ПО. Если для создания программной системы используются некого.
рые уже готбвые компоненты, это может наложить ограничения на архитектуру системы и интерфейсы системных модулей. Это означает, что количество компонентов, требующих проектирования, значительно уменьшится. Если в процессе проектирования используется метод проб и ошибок. то системные интерфейсы могут разрабатываться после определения структур данных.
3.4.1. Методы проектирования Во многих проектах разработки ПО процесс проектирования выполняется с помощью пгецигмьно подов)ююгыл методов. Отгалкиваясь от множества требований, обычно записанных естественным языком, сначала выполняется неформальное проектирование. Комментарии к программному коду и промежуточные спецификации мокнут изменяться в про. цессе реализации системы. После завершения стадии реализации (т.е. программирования и отладки системы) в проектную документацию также вносятся изменения, призванные устранить ошибки и неполноту описания системы а первоначальной спецификации.
Наиболее разработанным подходом к проектированию ПО обладают так называемые структурные методы, которые предлагают множество формализованных нотаций и нормативных руководств для проектирования программных продуктов. В качестве примера этих методов можно назвать структурное проектирование (79, 7», 24»], структурный анализ систем (125. 1О», 12»), разработку систем Джексона ()вс)гзоп, (181, 9») ), а также разно. образные методы.
основанные на объектно-ориентированном подходе (295, 54, 302, 55, 303, 304, 7», 32», 34»], Применение структурных методов обычно приводит к созданию графических молелей системы и большому объему проектной локументации. САВЕсредства (см. раздел 3,7) предназначены для поддержки именно таких методов.
Структурные методы успешно применялись во многих программных проектах. Они значительно снижают стоимость разработки, поскольку используют стандартные нотации для получения стандартной проекг. ной документации. Ни об одном из этих методов нельзя сказать, что он лучше или хуже других. Успешное или неуспешное применение того или иного метода часто зависит от типа разрабатываемого ПО.
Каждый структурный метод включает такие компоненты, как модель процесса проектирования, стандартизованные нотации для представления структуры сисгемы, форматы отчетов, правила и нормативные указания по проектированию. Хотя разработано большое количество таких лгетодов, оии имеют нечто общее, Структурные методы поддерживают все или по крайней мере некоторые из перечисленных ниже моделей систем. 1. Модель потоков данных, где система моделируется в виде потока данных, преобразуемых в этой системе. 2. Модель "сущность-связь", которая применяется для описании сущностей (объектов программной системы) и связей между ними.
Эта модель часто используется при проектировании структур баз данных. 3. Структурнгл модель, предназначенная для документирования системных компо. нентов и их взаимосвязей. 70 х(асть 1. Инженерия программного обеспечения: обзор Гь Объектно.ориснтироваппыс методы, с помовгью которых получают иерархическую модель системы, модели статических и динамических отношений между объектами и >юдоль взаимодействия оГп скгов во время работы системы. Пскоторыс структурпыс методы дополняются другимн систслшыми моделями, такими как лиаграммы переходов (из одного состояния в другое) или сценарии жизни сущностей, которые показывают послсдоватсльность преобразований для каждой сущности.
Многие методы ирсдполшиют наличие цснтрализованных хранилищ (рспозиторисв) для систем>юй информации или словарей используемых данных. Многие из этих подходов к моделированию систем описаны в главе 7. На практике мстоды прслставляют норматнвныс руководства нсфорлшльно, так что различпыс проектировщики могут реализовать разные пути просю ирования. Фаю ически этн "методы являются набором стандартных нотаций и просто отображают успешную практику просктпрованил. Следуя этим методам и нх нормативным руководствам. можно прийти к рациональному и разумному процессу проектирования. Вместе с тем творчество проскгиров>цнков должно проявиться в способе декомпозиции системы, адекватно отображающей систсмпыс требования.
С другой стороны, проведенные исследования труда проектировщиков показали, что чаще всего они просто слепо следуют этил> методам [20). Ла и саин методы они выбирают в зависимости от частных обстолтсльств, а нс в соответствии с их достоинствами или недостатками. 3.4.2. Программирование и отладка Процесс программированил (написания программного кода, кодирования) обычно следует непосредственно за процессом проектирования. Но для некоторых классов программ.
например критических по надежности систем, последняя стадия просктпрования (дстальнос проектирование) и начало кодирования могут перекрываться. В процсссс проектирования могут использоваться САБЕ-средства, которыс позволяют получить скслстпую программу. Такая программа содержит код для определения н реализации интерфейсов, и во многих случаях программисту остается только добавить код, рсализующий нскоторыс детали функционирования программногс>компонента.
Программирование — индивидуальный процесс, здесь нс существует общих правил, которым необходимо следовать ири написании программного кода. Некоторые программисты начинают кодирование с компонентов, которые они хороню понимают, оставляя напоследок кодирование компонентов, которые являются длл них "темными".
Лругис применяют противоположный подход, оставляя простые длл пих компоненты на потом. ОГ>ычпо программисты анш тестируют на>шсаиный имп програмл>ный код для обнар>жспия возможных о>пиГ>ок и программных дефектов. Этот процесс называется ожллдкой программы, В припципс тсстирова>шс и отладка являются разными процессами. При тестировании устанавливается наличие программных ошибок. В ходе отладки устанавливается мсстоположспис ошибок, затем опи устраняются. На рцс.
Б.10 показан возможный процссс отлэлки программы, Отладка может быть частью как процесса разработки, так и процсгга тестирования ПО. Проволяк1ий отладку программист должсн сгенерировать такие рсжимы работы систсмы. которые помощ г обнаружить програ>ншыс оншбки по аномальному поведению системы. Локализация овшбок может потребовать провсдсшш ручной трассировки кода 3. Процесс создания программного обеспечения 71 программы. В процессе тестирования и отладки ктог>т помочь отладочные средства, пока.
зывающие значении программных переменных и выполняющие трассировку исполняе- мых операторов. Опрвлеление Повторное способа устрв- тестирование ошибки нения ошибки программы уене. 3.10. Провегс помадки 3.5. Аттестация программных систем Лттестацил ПО, или более обобщенно — верификацил и аттестация, прелпазначспа показать гоответствне системы ее спецификации, а также ожиланилм и трсбовапилм заказчика и пользователей.
К процессу аттестации также можно отнести элсмсгггы контролл, такие как инспекция и оцепиванне (гм. главу 19), которые выполняютсн на каждом этапе создания ПΠ— от формировании общих требований ло кодировании программ. Но всетаки основные действия по аттестации выполплтатся после завершения реализации на этапе тестирования законченной системы (глава 20). За исключением небольших программ. программные системы невозможно протестировать как единый цельный программный элеьтеит. Большие системы строятся па осколе полсистсм, которые, в свою очередь, строятся из модулей, модули жс компонуются нз праграмлытроцепур и программ-функций. Длл таких систем процесс тсстирапаппн выполняется постепенна, по мере реализации системы.
Проверка на соответствие системным требованиям Тестирование Тестирование компонентов программных сборок Рис. Л. 1!. Прорегс ггмстгтгератотеил На рис. 3. ! 1 показан плтиэтаппый процесс тестировании, глс сначала тсстир>ютсл от. дельные программные компоненты и полспстемы, затем сабраппап система и наконец система с ланнымн.
прелоставлнемылти заказчиком. В илеале ошибки в программных компонентах лолжньт обнаруживаться и исправллтьсл еще в процессе пх копировании, а ошибки и упущения в интерфейсах — во время сборки системы. Но, поскольку после обна. ружения любых программных огнибок необходимо выполнить отладку программы, это 72 Часть 1. Инженерия программного обеспечения: обзор приводит к необходимости повторения некоторых этапов тестирования. Например, если программная ошибка проявилась на этапе сборки системы, необходимо повторить про. цесс тестирования того программного компонента, в котором обнаружена, вта ошибка.
Поэтому процесс тестирования итерационный, с обратной передачей информации с последующих этапов на предыдущие. Процесс тестирования состоит из нескольких этапов. 1. Тгсэифовяяие комяояеяжая Тестируются отдельные компоненты для проверки правильности их функционирования. Каждый компонент тестируется независимо от других. 2.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
