Структурный подход к разработке программного обеспечения. Структурный подход к разработке по Основные подходы к разработке по

1.Кодирование

На этапе разработки ПП выполняются следующие основные действия: кодирование; тестирование; разработка справочной си­стемы ПП; создание документации пользователя; создание вер­сии и инсталляции ПП,

Кодирование представляет собой процесс преобразования ре­зультатов высокоуровнего и низкоуровнего проектирования в го­товый программный продукт. Другими словами, при кодирова­нии происходит описание составленной модели ПП средствами выбранного языка программирования, которым может быть любой из существующих языков. Выбор языка осуществляется либо по желанию заказчика, либо с учетом решаемой задачи и личного опыта разработчиков.

При кодировании необходимо следовать стандарту на выбран­ный язык, например, для языка С - это ANSI С, а для C++ - ISO/IEC 14882 «Standartforthe C++ ProgrammingLanguage».

Кроме общепринятого стандарта на язык программирования в компании могут использоваться разработаны и свои дополнитель­ные требования к правилам написания программ. В основном они касаются правил оформления текста программы.

Следование стандарту и правилам компании позволяет создать корректно работающую, легко читаемую, понятную другим раз­работчикам программу, содержащую сведения о разработчике, дату создания, имя и назначение, а также и необходимые данные для управления конфигурацией.

На этапе кодирования программист пишет программы и сам их тестирует. Такое тестирование называется модульным. Все воп­росы, связанные с тестированием ПП, рассмотрены в гл. 10, здесь же описана технология тестирования, которая применяется на этапе разработки ПП. Эта технология называется тестированием «стеклянного ящика» (glassbox); иногда ее еще называют тестиро­ванием «белого ящика» (whitebox) в противоположность класси­ческому понятию «черного ящика» (blackbox).

При тестировании «черного ящика» программа рассматривается как объект, внутренняя структура которого неизвестна. Тестировщик вводит данные и анализирует результат, но он не знает, как именно работает программа. Подбирая тесты, специалист ищет интересные с его точки зрения входные данные и условия, которые могут привести к нестандартным результатам. Интересны для него прежде всего те представители каждого класса входных данных, при которых с наибольшей вероятностью могут проявиться ошибки тестируемой программы.

При тестировании «стеклянного ящика» ситуация совершенно иная. Тестировщик (в данном случае сам программист) разрабатывает тесты, основываясь на знании исходного кода, к которому он имеет полный доступ. В результате он получает следующие преимущества.

1. Направленность тестирования. Программист может тестировать программу по частям, разрабатывать специальные тестовые подпрограммы, которые вызывают тестируемый модуль и передают ему интересующие программиста данные. Отдельный модуль гораздо легче протестировать именно как «стеклянный ящик».

2.Полный охват кода. Программист всегда может определить, какие именно фрагменты кода работают в каждом тесте. Он видит, какие еще ветви кода остались непротестированными, и может подобрать условия, в которых они будут протестированы. Ниже описано, как отслеживать степень охвата программного кода про­веденными тестами.

3.Возможность управления потоком команд. Программист всегда знает, какая функция должна выполняться в программе следующей и каким должно быть ее текущее состояние. Чтобы выяснить, работает ли программа так, как он думает, программист может включить в нее отладочные команды, отображающие информацию о ходе ее выполнения, или воспользоваться для этого специальным программным средством, называемым отладчиком. Отладчик может делать очень много полезных вещей: отслежи­вать и менять последовательность выполнения команд программы, показывать содержимое ее переменных и их адреса в памяти др.

4.Возможность отслеживания целостности данных. Программисту известно, какая часть программы должна изменять каждый элемент данных. Отслеживая состояние данных (с помощью того же отладчика), он может выявить такие ошибки, как изменение данных не теми модулями, их неверная интерпретация или неудачная организация- Программист может и самостоятельно автоматизировать тестирование.

5.Видение внутренних граничных точек. В исходном коде видны те граничные точки программы, которые скрыты от взгляда извне. Например, для выполнения определенного действия может быть использовано несколько совершенно различных алгоритмов, и, не заглянув в код, невозможно определить, какой из них выбрал программист. Еще одним типичным примером может быть проблема переполнения буфера, используемого для временного хранения входных данных. Программист сразу может сказать, при каком количестве данных буфер переполнится, и ему не нужно при этом проводить тысячи тестов.

6.Возможность тестирования, определяемого выбранным алгоритмом. Для тестирования обработки данных, использующей очень сложные вычислительные алгоритмы, могут понадобиться спе­циальные технологии. В качестве классических примеров можно привести преобразование матрицы и сортировку данных. Тестировщику, в отличие от программиста, нужно точно знать, какие алгоритмы используются, поэтому приходится обращаться к специальной литературе.

Тестирование «стеклянного ящика» - часть процесса програм­мирования. Программисты выполняют эту работу постоянно, они тестируют каждый модуль после его написания, а затем еще раз после интеграции его в систему.

При выполнении модульного тестирования можно использовать технологию либо структурного, либо функционального тес­тирования или и ту, и другую.

Структурное тестирование является одним из видов тестирования «стеклянного ящика». Его главной идеей является правиль­ный выбор тестируемого программного пути. В противоположность ему функциональное тестирование относится к категории тестиро­вания «черного ящика». Каждая функция программы тестируется путем ввода ее входных данных и анализа выходных. При этом внутренняя структура программы учитывается очень редко.

Хотя структурное тестирование имеет гораздо более мощную теоретическую основу, большинство тестировщиков предпочитают функциональное тестирование. Структурное тестирование лучше поддается математическому моделированию, но это со­всем не означает, что оно эффективнее. Каждая из технологий позволяет выявить ошибки, пропускаемые в случае использования другой. С этой точки зрения их можно назвать одинаково эффективными.

Объектом тестирования может быть не только полный путь программы (последовательность команд, которые она выполняет от старта до завершения), но и его отдельные участки. Протестировать все возможные пути выполнения программы абсолютно нереально. Поэтому специалисты по тестированию выделяют из всех возможных путей те группы, которые нужно протестировать обязательно. Для отбора они пользуются специальными критериями, называемыми критериями охвата {coveragecriteria), которые определяют вполне реальное (пусть даже и достаточно большое) число тестов. Данные критерии иногда называют логическими критериями охвата, или критериями полноты.

3. Разработка справочной системы программного продукта. Создание документации пользователя

Целесообразно одного из сотрудников проекта назначать техническим редактором документации. Этот сотрудник может вы­полнять и другую работу, но главной его задачей должен быть анализ документации, даже если ее разрабатывают и другие сотрудники.

Часто бывает так, что над созданием ПП работают несколько человек, но никто из них не несет полной ответственности за его качество. В результате ПП не только не выигрывает от того, что его разрабатывает большее число людей, но еще и проигрывает, поскольку каждый подсознательно перекладывает ответственность на другого и ожидает, что ту или иную часть работы выполнят его коллеги. Эту проблему и решает назначение редактора, несущего полную ответственность за качество и точность технической доку­ментации.

Справочная система ПП формируется на основе материала, разработанного для руководства пользователя. Формирует и создает ее ответственный за выполнение этой работы. Им может быть как технический редактор, так и один из разработчиков совмест­но с техническим редактором.

У хорошо документированного ПП имеются следующие преимущества.

1. Легкость использования. Если ПП хорошо документирован, то его гораздо легче применять. Пользователи его быстрее изучают, делают меньше ошибок, а в результате быстрее и эффективнее выполняют свою работу.

2. Меньшая стоимость технической поддержки. Когда пользователь не может разобраться, как выполнить необходимые ему действия, он звонит производителю ПП в службу техническойподдержки. Содержание такой службы обходится очень дорого. Хорошее же руководство помогает пользователям решать возникающие проблемы самостоятельно и меньше обращаться в группутехнической поддержки.

3. Высокая надежность. Непонятная или неаккуратная документация делает ПП менее надежным, поскольку его пользователи чаще допускают ошибки, им трудно разобраться, в чем их причи­на и как справиться с их последствиями.

Легкость сопровождения. Огромное количество денег и времени тратится на анализ проблем, которые порождены ошибка ми пользователей. Изменения, вносимые в новые выпуски ПП,зачастую являются просто сменой интерфейса старых функций. Они вносятся для того, чтобы пользователи, наконец, разобра­лись, как применять ПП, и перестали звонить в службу техниче­ской поддержки. Хорошее руководство в значительной степени

Информатика, кибернетика и программирование

Итерация N Унифицированный процесс разработки программного обеспечения USDP Модель вариантов использования описывает случаи в которых приложение будет использоваться. Аналитическая модель описывает базовые классы для приложения. Модель проектирования описывает связи и отношения между классами и выделенными объектами Модель развертывания описывает распределение программного обеспечения по компьютерам.

Занятие №20
Общие принципы и подходы к разработке ПО

Модели разработки ПО

1. Водопадная
2. Каскадная модель
3. Спиральная
4. Экстремальное программирование
5. Инкрементальная
6. Методология MSF

Водопадная модель

Спиральная модель

Инкрементальная разработка

Анализ требований

Проектирование

Реализация

Компонентное

тестирование

Интеграция

Тестирование

единого целого

Итерация 1 Итерация 2 …. Итерация N

Унифицированный процесс разработки программного обеспечения (USDP)

1. Модель вариантов использования, описывает случаи, в которых приложение будет использоваться.
2. Аналитическая модель описывает базовые классы для приложения.
3. Модель проектирования описывает связи и отношения между классами и выделенными объектами
4. Модель развертывания описывает распределение программного обеспечения по компьютерам.
5. Модель реализации описывает внутреннюю организацию программного кода.
6. Модель тестирования состоит из тестирующих компонентов, тестовых процедур и различных вариантов тестирования

Методология MSF

Типичные компоненты архитектуры программного продукта и типичные требования к ПО

Отказоустойчивость – совокупность свойств системы, повышающая ее надежность путем обнаружения ошибок, восстановления и локализации плохих последствий для системы. При разработке любой реальной системы для обеспечения отказоустойчивости необходимо предусматривать всевозможные ситуации, которые могут привести к сбою системы и разработать механизмы обработки сбоев.

Надежность – способность системы противостоять различным отказам и сбоям.

Отказ – это переход системы в результате ошибки в полностью неработоспособное состояние.

Сбой – ошибка в работе системы, которая не приводит к выходу системы из строя.

Чем меньше отказов и сбоев за какой-то определенный интервал времени, тем система считается надежнее.

А также другие работы, которые могут Вас заинтересовать
57355.		Многообразие органических соединений, их классификация. Органические вещества живой природы	48.5 KB
	Многообразие органических соединений определяется уникальной способностью атомов углерода соединяться друг с другом простыми и кратными связями образовывать соединения с практически неограниченным числом атомов связанных в цепи циклы бициклы трициклы полициклы каркасы и др.
57359.		Обработка словесных информационных моделей	291 KB
	Основные понятия: модель; информационная модель; словесная информационная модель; аннотация; конспект. Конспект Конспект от лат. Создайте конспект к 2. Сохраните документ в собственной папке под именем Конспект.
57361.		Число і цифра 3. Порівняння чисел у межах 3. Написання цифри 3. Порівняння довжини й товщини предметів	35.5 KB
	Скільки всього тварин Хто стоїть першим Хто стоїть останнім Хто стоїть під номером 1 Хто стоїть під номером 2 Назвіть сусідів їжачка. Хто сусід праворуч білочки Хто сусід ліворуч жирафа Хто є найвищим Хто є найнижчим Хто стоїть посеред тварин Гра Покажи не помились.

При рассмотрении технологии разработки ПО необходимо использовать системный подход, который предполагает рассмотрение не каких-то отдельных аспектов проблемы разработки ПО, а проблемы в целом. Системный подход реализуется в пространстве и во времени.

Системный подход во времени рассматривает последовательность этапов создания ПО от момента формирования неудовлетворенной потребности в ПО до момента её разрешения и сопровождения в эксплуатации полученного программного продукта.

Системный подход в "пространстве" предусматривает рассмотрение разрабатываемого ПО, как части системы. При этом на базе изучения информационных потребностей системы, в которую будет входить разрабатываемое ПО, формулируются цели и набор функций ПО, анализируются прототипы программных средств. Формируются и документируются требования к ПО.

Современная технология разработки ПО рассматривает программирование, как один из этапов разработки в цепи последовательных этапов цикла разработки. Все эти этапы объединяются понятием жизненный цикл ПО и должны быть поддержаны соответствующими инструментальными программными и аппаратными средствами.

В соответствии с международным стандартом ISO/IEC 12207 «информационные технологии – Процессы жизненного цикла ПО» процесс разработки ПО содержит следующие этапы жизненного цикла ПО:

1) анализ системных требований и области применения;

2) проектирование архитектуры системы;

3) анализ требований к ПО(спецификации, внешние интерфейсы,);

4) проектирование архитектуры ПО;

5) детальное проектирование каждой единицы ПО;

6) кодирование ПО (программирование)

7) тестирование единиц ПО;

8) интеграция (объединение ПО) и тестирование совокупности единиц ПО;

9) квалификационные испытания ПО (комплексное тестирование);

10) интеграция системы единицы структуры ПО должны быть объединены с единицами аппаратных средств;

11) квалификационные испытания системы;

12) установка ПО.

Таким образом, процесс разработки ПО имеет свое начало от системы, где это ПО будет использовано и завершается опять в системе.

После этапов разработки в жизненном цикле ПО следует этап эксплуатации ПО и сопровождения при эксплуатации. Иногда перечень этапов жизненного цикла ПО приводится с некоторыми обобщениями (укрупнениями) приведенных 12 этапов. Например, этапы проектирования системы и определение требований к ПО, проектирования программного комплекса, проектирования алгоритмов ПО, программирования (кодирования), автономной отладки ПО, комплексной отладки ПО, эксплуатации ПО.

Пренебрежения этапами проектирования ПО, стремление сразу начать программирование без достаточной проработки алгоритмов и вопросов взаимодействия структурных единиц ПО часто приводит к хаотическому процессу разработки ПО с малыми шансами на успех.

Спиральная модель жизненного цикла ПО. «Тяжелые и облегченные» (быстрые) технологии разработки ПО

Рассмотренная модель жизненного цикла (ЖЦ) относится к модели каскадного типа. Этот тип модели ЖЦ хорош для ПО, для которого в самом начале разработки возможно полно и точно сформулировать все требования к ПО.

Схема спирального ЖЦ ПО. Однако, реальный процесс создания ПО не всегда укладывается в такую жесткую схему и часто возникает потребность возврата предыдущим этапам с уточнением или пересмотром принятых решений.

Для ПО также как и для других сложных систем, первоначальные требования к которым недостаточно полны, характерен итеративный процесс разработки. При этом для некоторых типов ПО даже желательно переходить к следующему этапу как можно быстрее. При этом неизбежные при такой поспешной работе недостатки устраняются на следующей итерации или остаются на всегда.

Главная задача как можно быстрее достичь работоспособного ПО, активизируя тем самым процесс уточнения и дополнения требований. Это так называемая спиральная модель ЖЦ ПО.

На каждом витке спирали выполняется создание версии продукта, уточняются требования к ПО и планируются работы следующего витка. Спиральная модель ЖЦ ПО отражает объективно существующий процесс итеративной разработки ПО (рис. 8.2).

Считается, что спиральная схема ЖЦ ПО предназначена не столько для торопливых разработчиков, сколько для ПО, некачественные первые версии которого допустимы по функциональному назначению ПО.

Существует направление «Быстрых технологий» разработки ПО (Agile Software Development), дающее идеологическое обоснование взглядам, связанным с спиральной моделью ЖЦ. Эти технологии базируются на четырех идеях:

Интерактивное взаимодействие индивидуумов важнее формальных процедур и инструментов,

Работающее ПО важнее наличия документации на него,

Сотрудничество с заказчиком важнее формальных договоров,

Быстрое реагирование на внешние изменения важнее строгого следования намеченным планам.

Рис. 8.2 - Схема спирального ЖЦ ПО

Иными словами, быстрые технологии направлены на замену формальных и трудоемких документированных процедур взаимодействия при разработке на интерактивные, что возможно при малых размерах проекта, подобранных качеств сотрудников, размещения разработчиков и заказчиков «в одной комнате» и для разработки ПО некритических систем.

Правильность этих принципов в определенной мере, когда разработку ПО ведет небольшое количество квалифицированных и преданных делу «фанатов») для разработки некоторых видов ПО оспаривать трудно. Однако, Agile технологии и это признают их идеологи применимы в программных проектах определенного класса и масштаба, так же, как и вообще спиральная модель ЖЦ, а именно там, где ошибки ПО приводят к некоторым неудобствам либо потерям возместимых средств.

Там, где неверно работающее ПО приводит к угрозе человеческой жизни либо к большим материальным потерям должны использоваться полновесные продуманные технологии, обеспечивающие надежность программного продукта.

С увеличением масштаба программного проекта- увеличением количества участвующих в нем людей потребность в жесткой технологии разработки, составляющих каскадный ЖЦ ПО, возрастает. Здесь необходима документация, так как в любой момент возможна потеря любого из разработчиков, необходима формализация межпрограммных связей, управление изменениями ПО и т. п. Не даром в стандарты разработки ПО заведена именно каскадная модель жизненного цикла. При этом она также позволяет реализовать итеративный процесс разработки за счет предусмотренной этапности проектирования СТС и ПО для них.

Для очень больших программных проектов (коллектив разработчиков более 100) технология разработки является ключевым фактором, влияющим не только на качество ПО, но и на саму возможность его создания.

«Тяжелые и облегченные» технологии разработки ПО. Разработчики многих видов ПО считают каскадную модель жизненного цикла слишком регламентированной, слишком документированной и тяжелой и поэтому нерациональной. Существует направление «Быстрых технологий» (легких технологий) разработки ПО (Agile Software Development), дающее идеологическое обоснование этим взглядам. Эти технологии базируются на четырех идеях:

1. интерактивное взаимодействие индивидуумов важнее формальных процедур и инструментов,

2. работающее ПО важнее наличия документации на него,

3. сотрудничество с заказчиком важнее формальных договоров с ним,

4. быстрое реагирование на внешние изменения важнее строгого следования намеченным планам.

Правильность этих принципов кроме третьего в определенной мере (разработку ПО ведет небольшое количество квалифицированных программистов - «фанатов», не нуждающихся в контроле и дополнительной мотивации) для разработки ПО оспаривать трудно. Однако, Agile технологии и это признают их идеологи применимы в программных проектах определенного класса и масштаба, так же как и вообще спиральная модель ЖЦ, а именно там, где ошибки ПО приводят к некоторым неудобствам либо потерям возместимых средств и там где требования к ПО постоянно меняются, так как были заранее плохо определены, и требуется быстрая адаптация к этим изменениям.

Быстрые технологии – попытки достичь компромисса между строгой дисциплиной разработки и полным её отсутствием во имя уменьшения потока бумаг, сопровождающих разработку.Быстрые технологии не могут обеспечить высокую надежность программного продукта именно из-за минимизации бумаг, юридически подтверждающих ответственность разработчика.

Примером Agile технологий является «Экстремальное программирование» (ХР). Итерации в ХР очень короткие и состоят из четырех операций: кодирования, тестирования, выслушивание заказчика, проектирование. Принципы ХР – минимальность, простота, участие заказчика, короткий цикл, тесные взаимодействия разработчиков – они должны сидеть в одной комнате, ежедневных оперативных совещаний совместно с заказчиком представляются разумными и давно применяются не только в быстрых технологиях, но в ХР они доведены до экстремальных значений.

Анализ множества программных проектов показал, что облегченные технологии, проповедующие принципы самоорганизации, акцентирующие использование индивидуальных способностей разработчиков, короткие итерации разработки в спиральной модели, ХР, SCRUM распространены и часто также приводят к успеху, максимально используя особенности работы в малых коллективах.

Там, где неверно работающее ПО приводит к угрозе человеческой жизни либо к большим материальным потерям должны использоваться упорядоченные, полностью продуманные и прогнозируемые формализованные «тяжелые» технологии, обеспечивающие надежность программного продукта даже в случае разработчиков средней квалификации.С увеличением масштаба программного проекта - увеличением количества участвующих в нем людей потребность в жесткой и формальной технологии разработки, фиксирующей ответственность каждого участника разработки, составляющих каскадный ЖЦ ПО, возрастает. Не даром в стандарты разработки ПО заведена именно каскадная модель жизненного цикла.

В больших коллективах разработчиков проблема управления – выходит на передний план.

Для очень больших программных проектов вопросы упорядоченной скоординированной разработки: структурирования, интеграции, обеспечения правильного взаимодействия программ, организации правильного и скоординированного проведения неизбежных изменений являются ключевымии влияют на саму возможность их создания.

В малых проектах ПО алгоритмические изыски, влияние отдельных талантливых личностей играют определяющую роль, тогда как в больших проектах эти факторы нивелируются и не оказывают определяющего влияния на ход разработки.

Разработчики ПО, обладающие средними возможностями, а таких большинство, и соблюдающие технологическую дисциплину в рамках правильной технологии, должны разрабатывать ПО требуемого качества. «Поддерживай порядок и он поддержит тебя».

Итак, сущность структурного подхода к разработке ПО ЭИС заключается в ее декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые, в свою очередь, делятся на подфункции, те - на задачи и так далее до конкретных процедур. При этом система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. При разработке системы «снизу-вверх», от отдельных задач ко всей системе, целостность теряется, возникают проблемы при описании информационного взаимодействия отдельных компонентов.

Все наиболее распространенные методы структурного подхода базируются на ряде общих принципов:

1. Принцип «разделяй и властвуй»;

2. Принцип иерархического упорядочения- принцип организации составных частей системы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.

Выделение двух базовых принципов не означает, что остальные принципы являются второстепенными, т.к. игнорирование любого из них может привести к непредсказуемым последствиям (в том числе и к провалу всего проекта»). Основными из этих принципов являются:

1. Принцип абстрагирования- выделение существенных аспектов системы и отвлечение от несущественных.

2. Принцип непротиворечивости,обоснованность и согласованность элементов системы.

3. Принцип структурирования данных- данные должны быть структурированы и иерархически организованы.

В структурном подходе в основном две группы средств, описывающих функциональную структуру системы и отношения между данными. Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенными среди них являются:

· DFD (Data Flow Diagrams) - диаграммы потоков данных;

· SADT (Structured Analysis and Design Technique - методология структурного анализа и проектирования) - модели и соответствующие функциональные диаграммы: нотации IDEF0 (функциональное моделирование систем), IDEF1х (концептуальное моделирование баз данных), IDEF3х (построение систем оценки качества работы объекта; графическое описание потока процессов, взаимодействия процессов и объектов, которые изменяются этими процессами);

· ERD (Entity - Relationship Diagrams) - диаграммы «сущность-связь».

Практически во всех методах структурного подхода (структурного анализа) на стадии формирования требований к ПО используются две группы средств моделирования:

1. Диаграммы, иллюстрирующие функции, которые система должна выполнять, и связи между этими функциями - DFD или SADT (IDEF0).

2. Диаграммы, моделирующие данные и их отношения (ERD).

Конкретный вид перечисленных диаграмм и интерпретация их конструкций зависят от стадии ЖЦ ПО.

На стадии формирования требований к ПО SADT-модели и DFD используются для построения модели “AS-IS” и модели “TO-BE”, отражая таким образом существующую и предлагаемую структуру бизнес-процессов организации и взаимодействие между ними (использование SADT-моделей, как правило, ограничивается только данной стадией, поскольку они изначально не предназначались для проектирования ПО). С помощью ERD выполняется описание используемых в организации данных на концептуальном уровне, не зависимо от средств реализации базы данных (СУБД).

Водопадная модель Анализ требований Проектирование Реализация Интеграция Тестирование Составляется спецификация продукта Составляется архитектура продукта Разработка исходного кода Интеграция отдельных частей исходного кода Тестирование и устранение дефектов

Унифицированный процесс разработки программного обеспечения (USDP) Модель вариантов использования, описывает случаи, в которых приложение будет использоваться. Аналитическая модель описывает базовые классы для приложения. Модель проектирования описывает связи и отношения между классами и выделенными объектами Модель развертывания описывает распределение программного обеспечения по компьютерам. Модель реализации описывает внутреннюю организацию программного кода. Модель тестирования состоит из тестирующих компонентов, тестовых процедур и различных вариантов тестирования

Типичные компоненты архитектуры программного продукта и типичные требования к ПО Организация программы Основные классы системы Организация данных Бизнес–правила Пользовательский интерфейс Управление ресурсами Безопасность Производительность Масштабируемость Взаимодействие с другими системами (интеграция) Интернационализация, локализация Ввод-вывод данных Обработка ошибок

Типичные компоненты архитектуры программного продукта и типичные требования к ПО Отказоустойчивость – совокупность свойств системы, повышающая ее надежность путем обнаружения ошибок, восстановления и локализации плохих последствий для системы. При разработке любой реальной системы для обеспечения отказоустойчивости необходимо предусматривать всевозможные ситуации, которые могут привести к сбою системы и разработать механизмы обработки сбоев. Надежность – способность системы противостоять различным отказам и сбоям. Отказ – это переход системы в результате ошибки в полностью неработоспособное состояние. Сбой – ошибка в работе системы, которая не приводит к выходу системы из строя. Чем меньше отказов и сбоев за какой-то определенный интервал времени, тем система считается надежнее.

Типичные компоненты архитектуры программного продукта и типичные требования к ПО Возможности реализации разрабатываемой архитектуры. Возможности реализации разрабатываемой архитектуры. Избыточная функциональность. Избыточная функциональность. Принятие решение о приобретении готовых компонент ПО. Принятие решение о приобретении готовых компонент ПО. Стратегия изменений. Стратегия изменений.

Ясно ли описана общая организация программы; включает ли спецификация обзор архитектуры и ее обоснование. Ясно ли описана общая организация программы; включает ли спецификация обзор архитектуры и ее обоснование. Адекватно ли определены основные компоненты программы, их области ответственности и взаимодействие с другими компонентами. Адекватно ли определены основные компоненты программы, их области ответственности и взаимодействие с другими компонентами. Все ли функции, указанные в спецификации требований, реализованы разумным количеством компонентов системы. Все ли функции, указанные в спецификации требований, реализованы разумным количеством компонентов системы. Приведено ли описание самых важных классов и их обоснование. Приведено ли описание самых важных классов и их обоснование. Приведено ли описание организации БД. Приведено ли описание организации БД. Определены ли все бизнес правила. Определены ли все бизнес правила. Описано ли их влияние на систему. Описано ли их влияние на систему. Контрольный список вопросов, который позволяет сделать вывод о качестве архитектуры:

Контрольный список вопросов, который позволяет сделать вывод о качестве архитектуры: Описана ли стратегия проектирования пользовательского интерфейса. Описана ли стратегия проектирования пользовательского интерфейса. Сделан ли пользовательский интерфейс модульным, чтобы его изменения не влияли на оставшуюся часть системы. Сделан ли пользовательский интерфейс модульным, чтобы его изменения не влияли на оставшуюся часть системы. Приведено ли описание стратегии ввода-вывода данных. Приведено ли описание стратегии ввода-вывода данных. Проведен ли анализ производительности системы, которая будет реализовываться с использованием данной архитектуры. Проведен ли анализ производительности системы, которая будет реализовываться с использованием данной архитектуры. Проведен ли анализ надежности проектируемой системы. Проведен ли анализ надежности проектируемой системы. Проведен ли анализ вопросов масштабируемости и расширяемости системы. Проведен ли анализ вопросов масштабируемости и расширяемости системы.

Рефакторинг ПО Код повторяется; реализация метода слишком велика; слишком большая вложенность циклов, или же сам цикл очень большой; класс имеет плохую связность (свойства и методы класса должны описывать только 1 объект); интерфейс класса не формирует согласованную абстракцию; метод принимает слишком много параметров. Необходимо стараться, чтобы количество параметров было разумно минимальным; отдельные части класса изменяются независимо от других частей класса; Рефакторинг предполагает адаптацию программного обеспечения к новому аппаратному обеспечению и к новым ОС, новым средствам разработки, новым требованиям, а также архитектуре и функциональности ПО. Это изменение внутренней структуры ПО без изменения его внешнего поведения, призванное обеспечить модификацию ПО. Разумные причины проведения рефакторинга:

Рефакторинг ПО при изменении программы требуется параллельное изменение нескольких классов. При возникновении такой ситуации необходимо провести реорганизацию классов с целью минимизации в будущем мест возможных изменений; приходиться параллельно изменять несколько иерархий наследования; приходиться изменять несколько блоков case. Необходимо провести модификацию программы таким образом, чтобы сделать реализацию блока case, а вызывать ее в нужном количестве раз в программе; родственные элементы данных, используемые вместе, не организованы в классы. Если вы неоднократно используете один и тот же набор элементов данных, то целесообразно рассмотреть объединение этих данных и выполняемые над ними операции поместить в отдельный класс;

Рефакторинг ПО метод использует больше элементов другого класса, чем собственного. Это означает, что метод нужно переместить в другой класс и вызывать его из старого; элементарный тип данных перегружен. Для описания сущности реального мира лучше использовать какой- либо класс, чем перегружать какой-либо существующий тип данных; класс имеет слишком ограниченную функциональность. Лучше от этого класса избавиться, перенеся его функциональность в другой класс; по цепи методов передаются «бродячие» данные. Данные, передаваемые в метод только для того, чтобы он их передал другому методу, называются «бродячими». При возникновении таких ситуаций постарайтесь изменить архитектуру классов и методов, чтобы от них избавиться.

Рефакторинг ПО объект-посредник ничего не делает. Если роль класса сводится к перенаправлению вызовов методов в другие классы, то лучше всего такой объект-посредник устранить и выполнять вызовы других классов непосредственно; один класс слишком много знает о другом классе. В этой ситуации необходимо сделать инкапсуляцию более строгой, чтобы обеспечить минимальное знание наследника о своем родителе; метод имеет неудачное имя; данные-члены являются открытыми. Это стирает грань между интерфейсом и реализацией, неизбежно нарушает инкапсуляцию, и ограничивает гибкость программы; размещать комментарии в исходном коде;

Рефакторинг ПО подкласс использует только малую долю методов своих предков. Такая ситуация возникает тогда, когда новый класс создается только лишь для наследования нескольких методов из базового класса, а не для того, чтобы описать какую-либо новую сущность. Для того, чтобы этого избежать, необходимо преобразовать базовый класс, таким образом, чтобы он давал доступ новому классу только к необходимым ему методам; код содержит глобальные переменные. Глобальными должны быть только те переменные, которые в действительности используются всей программной. Все остальные переменные должны быть либо локальными, либо должны стать свойствами каких-либо объектов; программа содержит код, который может когда-нибудь понадобиться. При разработке системы целесообразно предусмотреть места, куда в будущем может быть добавлен исходный код.