Сложность, присущая программному обеспечению. Составляющие сложности программного обеспечения по Ф. Бруксу
Сложность вызывается четырьмя основными причинами:
Сложность реального мира, из которой исходит заказ на разработку. Решаемые с помощью ПО проблемы, часто неизбежно содержат сложные элементы, также к ним предъявляется множество различных, порой взаимоисключающих требований. Если рассмотреть необходимые характеристики электронной системы, достаточно трудно понять, даже в общих чертах, как работает каждая такая система. Эта внешняя сложность обычно возникает из-за того, что пользователи с трудом могут объяснить в форме, понятной разработчикам, что на самом деле нужно сделать. Часто пользователь лишь смутно представляет, что ему нужно от будущей программной системы. Т.к. у пользователей и разработчиков разные взгляды на сущность проблемы, то они часто делают различные выводы о возможных путях ее решения.
Трудности управления процессом разработки. Когда процесс разработки системы предполагает проведения большого объема работ (например, создается большая корпоративная система), то возникают проблемы организации и управления коллективной разработки. Это проблема согласованности и оптимального использования ресурсов.
Необходимость обеспечить достаточную гибкость ПО. Программирование обладает предельной гибкостью, и разработчик может сам обеспечить себя всеми необходимыми элементами, относящимися к любому уровню абстракции. Такая гибкость чрезвычайно соблазнительна. Она заставляет разработчика создавать своими силами все базовые строительные блоки будущей конструкции, из которых составляются элементы более высоких уровней абстракции. В отличие от строительной индустрии, где существуют единые стандарты на многие конструктивные элементы и качество материалов, в программной индустрии таких стандартов почти нет. Поэтому программные разработки остаются очень трудоемким делом.
Проблема описания поведения больших дискретных систем. Большая прикладная система представляет собой систему с дискретными состояниями, т.к. внутри нее могут существовать сотни и даже тысячи переменных и несколько потоков управления. Полный набор этих переменных, их текущих значений, текущего адреса и стека вызова для каждого процесса описывает состояние системы в каждый момент времени. Каждое событие, внешнее по отношению к системе, может перевести ее в новое состояние и, более того, переход из одного состояния в другое не всегда детерминирован. При неблагоприятных условиях внешнее событие может нарушить текущее состояние системы из-за того, что ее создатели не смогли предусмотреть все возможные варианты. В дискретных системах любое внешнее событие может повлиять на любую часть внутреннего состояния системы. Это, и является главной причиной обязательного тестирования систем; но дело в том, что за исключением самых тривиальных случаев, всеобъемлющее тестирование таких программ провести невозможно. И пока нет ни математических инструментов, ни интеллектуальных возможностей для полного моделирования поведения больших дискретных систем, программисты должны удовлетвориться разумным уровнем уверенности в их правильности.
30. Эволюция системного программного продукта. Понятие и составляющие программы, программного комплекса, программного продукта, системного программного продукта (по Ф. Бруксу)
Эволюция системного программного продукта ->
Программа – завершенный продукт, пригодным для запуска своим автором на системе, на которой она была разработана. Это тот объект, посредством которого программист оценивает свою производительность.
При пересечении горизонтальной границы программа превращается в программный продукт.
Программный продукт – это программа, которую любой человек может запускать, тестировать, исправлять и развивать. Она может использоваться в различных операционных средах и со многими наборами данных. Чтобы стать общеупотребительным программным продуктом, программа должна быть написана в обобщенном стиле. В частности, диапазон и вид входных данных должны быть настолько обобщенными, насколько это допускается базовым алгоритмом. Затем программу нужно тщательно протестировать, чтобы быть уверенным в ее надежности. Для этого нужно подготовить достаточное количество контрольных примеров для проверки диапазона допустимых значений входных данных и определения его границ, обработать эти примеры и зафиксировать результаты. Наконец, развитие программы в программный продукт требует создания подробной документации, с помощью которой каждый мог бы использовать ее, делать исправления и расширять. Следовательно, программный продукт стоит, по меньшей мере, втрое дороже, чем просто отлаженная программа с такой же функциональностью.
При пересечении вертикальной границы программа становится компонентом программного комплекса. Последний представляет собой набор взаимодействующих программ, согласованных по функциям и форматам, составляющих полное средство для решения больших задач. Чтобы стать частью программного комплекса, синтаксис и семантика ввода и вывода программы должны удовлетворять точно определенным интерфейсам. Программа должна быть также спроектирована таким образом, чтобы использовать заранее оговоренный бюджет ресурсов – объем памяти, устройства ввода/вывода, процессорное время. Наконец, программу нужно протестировать вместе с прочими системными компонентами во всех сочетаниях, которые могут встретиться. Это тестирование может оказаться большим по объему, поскольку количество тестируемых случаев растет экспоненциально. Оно также занимает много времени, так как скрытые ошибки выявляются при неожиданных взаимодействиях отлаживаемых компонентов. Компонент программного комплекса стоит, по крайней мере, втрое дороже, чем автономная программа с теми же функциями. Стоимость может увеличиться, если в системе много компонентов. В правом нижнем углу рисунка находится системный программный продукт. От обычной программы он отличается во всех перечисленных выше отношениях. И стоит, соответственно, в десять раз дороже. Но это действительно полезный объект, который является целью большинства системных программных проектов.
31. Борьба со сложностью в программном обеспечении. Эволюция методов анализа и разработки (SA/SD, OOA/OOD).
Эволюция:
Изначально не существовало никаких методов анализа и разработки проектов, поскольку это и не было нужным (маленькие системы, автоматизирующие элементарные функции), но с течением времени требования к системам возрастали, возросли и области и широта применения систем, а соответственно программисты столкнулись со сложностью анализа и разработки больших систем. Необходимо было найти способ, позволяющий формализовать и облегчить работу программиста. Появление методов SA/SD (структурного анализа и разработки проекта) привело к возможности построения графических представлений создаваемой программной системы. Эти методы стали использоваться с 70-х, и теперь признаны "проверенными и правильными". Они применяются совместно с любым типом приложения и могут быть реализованы на любой платформе.
Анализ SA/SD длительное время применялся при разработке в качестве методики моделирования процесса, данных и поведенческих аспектов. В условиях этой методологии основной акцент делается на уточнении и разложении на составные элементы функциональных возможностей системы. Для функционального разложения и структурирования данных применяются диаграммы потоков данных, диаграммы управления потоками, словарь данных, диаграммы переходов состояния и диаграммы отношений объектов. DFD- и CFD- диаграммы при перемещении данных в системе моделируют трансформацию данных/контроль данных. Словарь данных определяет потоки данных и их хранилища. Диаграммы взаимосвязей иллюстрируют отношения между хранилищами данных. Т.е. модели были как бы разрознены м/у собой. Подобный подход при тестировании оказывается не совсем точным, особенно если изменяются функциональные требования, что часто приводит к реструктуризации моделей.
Появление OOA/OOD. ОО-модель организует систему на основе объектов реального мира или концептуальных объектов, важных для пользователя. Этот подход является противоположным разделению функций и данных. Объект реального мира, существующий внутриобласти действия приложения, определяется в терминах ответственностей (поведения), соответствующих данных (атрибутов) и отношения к другим объектам. Все функции объекта скрыты в самих деталях объекта. Поэтому если необходимы функциональные изменения, они производятся внутри объекта, что приводит к незначительным изменениям в оставшейся части модуля. Для применения в объекте обновленных или добавленных функций, оставшиеся объекты в модели поддерживаются с помощью интерфейса. ОО-разработчики обычно используют как статические (Диаграммы класса, Диаграммы объектов, Усовершенствованный класс диаграмм), так и динамические модели (Применение регистра, Сценарий, Диаграмма действий, Диаграммы взаимодействия- диаграммы сотрудничества и последовательности, Диаграммы перехода между состояниями).
Подходы SA/SD и OOA/OOD имеют много общего. Конечно, имеются и значительные отличия, однако иногда более новые методики опираются на то, что хорошо известно. Основным преимуществом OOA/OOD является способность проекта к повторному определению или сотрудничеству. На протяжении всего процесса разработки создаются диаграммы одних типов, а действительные элементы, отображаемые в аналитических моделях, продолжают существовать до завершения разработки. Диаграмма класса, играющая роль аналитического инструмента, обладает свойствами, которые проявляются во время разработки и при внедрении системы.