3 0. Эволюция системного программного продукта. Понятие и составляющие программы, программного комплекса, программного продукта, системного программного продукта (по ф. Бруксу)

Эволюция системного программного продукта ->

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

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

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

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

31. Борьба со сложностью в программном обеспечении. Эволюция методов анализа и разработки (sa/sd, ooa/ood).

Эволюция:

Изначально не существовало никаких методов анализа и разработки проектов, поскольку это и не было нужным (маленькие системы, автоматизирующие элементарные функции), но с течением времени требования к системам возрастали, возросли и области и широта применения систем, а соответственно программисты столкнулись со сложностью анализа и разработки больших систем. Необходимо было найти способ, позволяющий формализовать и облегчить работу программиста. Появление методов SA/SD (структурного анализа и разработки проекта) привело к возможности построения графических представлений создаваемой программной системы. Эти методы стали использоваться с 70-х, и теперь признаны "проверенными и правильными". Они применяются совместно с любым типом приложения и могут быть реализованы на любой платформе.

Анализ SA/SD длительное время применялся при разработке в качестве методики моделирования процесса, данных и поведенческих аспектов. В условиях этой методологии основной акцент делается на уточнении и разложении на составные элементы функциональных возможностей системы. Для функционального разложения и структурирования данных применяются диаграммы потоков данных, диаграммы управления потоками, словарь данных, диаграммы переходов состояния и диаграммы отношений объектов. DFD- и CFD- диаграммы при перемещении данных в системе моделируют трансформацию данных/контроль данных. Словарь данных определяет потоки данных и их хранилища. Диаграммы взаимосвязей иллюстрируют отношения между хранилищами данных. Т.е. модели были как бы разрознены м/у собой. Подобный подход при тестировании оказывается не совсем точным, особенно если изменяются функциональные требования, что часто приводит к реструктуризации моделей.

Появление OOA/OOD. ОО-модель организует систему на основе объектов реального мира или концептуальных объектов, важных для пользователя. Этот подход является противоположным разделению функций и данных. Объект реального мира, существующий внутри области действия приложения, определяется в терминах ответственностей (поведения), соответствующих данных (атрибутов) и отношения к другим объектам. Все функции объекта скрыты в самих деталях объекта. Поэтому если необходимы функциональные изменения, они производятся внутри объекта, что приводит к незначительным изменениям в оставшейся части модуля. Для применения в объекте обновленных или добавленных функций, оставшиеся объекты в модели поддерживаются с помощью интерфейса. ОО-разработчики обычно используют как статические (Диаграммы класса, Диаграммы объектов, Усовершенствованный класс диаграмм), так и динамические модели (Применение регистра, Сценарий, Диаграмма действий, Диаграммы взаимодействия- диаграммы сотрудничества и последовательности, Диаграммы перехода между состояниями).

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