Эволюция программного продукта. Основные определения, понятия, отличительные черты

Следует различать следующие понятия:

● под сопровождением понимается устранение ошибок;

● под эволюцией - внесение изменений в систему в ответ на изменившиеся требования к ней;

● под сохранением - использование всех возможных и невозможных способов для поддержания жизни в дряхлой и распадающейся на части системе.

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

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

8. Понятие «модуль» в программировании. Различные виды модулей при использовании основных методов проектирования ПС.

В настоящее время модульный принцип (подход, методология) является

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

Разбивать ПО на модули необходимо для упрощения процесса разработки и для

уменьшения его сложности. За счет чего же упрощается процесс разработки и

уменьшается сложность? Это происходит за счет следующих факторов:

1.Возможности организации коллективной разработки ПС.

2.Использование созданных ранее модулей в новых разработках модулей).

Так что же такое модуль?

Надо сказать, что на сегодняшний день нет общепризнанного определения модуля в программировании.

Прежде чем дать определение “модуля”, необходимо разобраться в том, что же

является исходным материалом для модуляризации.

К таким материалам, безусловно, следует отнести тексты программ на языках

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

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

Например:

Тексты указаний, применяемых к ПО (например, указание: “транслировать и результат поместить в указанную библиотеку” или, например, “собрать программу указанной конфигурации”).

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

3.

Наконец,

1.

(появились библиотеки

самые первичные материалы – это всевозможные проектные решения, т.е. проект системы (диаграммы, схемы, рисунки, тексты и т.д.).

Из сказанного можно сделать вывод - задача модуляризации должна ставиться (и решаться) не только для исходных текстов программ, а охватывать всю совокупность первичных материалов.

Теперь можно перейти и к определению понятия “модуль”. Для наших целей подойдет

следующее, весьма свободное его определение:

Модуль – это выделенная по тем или иным мотивам часть первичного программного фонда. (Майерс)

Поэтому для различных первичных материалов и с различных точек зрения

интерес представляют мотивы выделения модулей, а значит, и различные формы модулей. (Не следует только путать это понятие с известным и распространенным в программистском лексиконе “объектный” или “загрузочный” модуль – это вторичные материалы. И для наших целей они не имеют никакого значения.)

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

Важно отметить, что при использовании различных методов проектирования (и

языков программирования, соответственно) модулем могут называться различные части исходного текста.

При использовании традиционных методологий и методов SD и DD наиболее

удачным, на мой взгляд, является определение Фокса.

Модуль – это относительно независимая часть программы (процедура, функция, подпрограмма и т.п.), которая имеет один вход и один выход, имеет небольшой размер (50 ÷ 30 опер.), и которая выполняет одну (максимум две) функции.

1)Итак, ключевым соображением при таком определении модуля является его

функциональная самостоятельность.

При использовании объектно-ориентированного метода разработки ПС модулем раньше называли отдельный файл (физический) (у Г.Буча тоже). Еще раньше –файл, который можно отдельно транслировать (OPascal, Modula). Но с появлением новых объектно-ориентированных языков (С++, Java и т.д.) в файлах могут быть различные структурные единицы. Например, классы целиком, только их определения (заголовочная часть класса как в С++), могут быть интерфейсы как самостоятельные части, а реализации интерфейсов в отдельных файлах и т.п. Поэтому в стандарте UML введено новое понятие – компонента.

2)По стандарту компонента – это часть модели ПС на физическом уровне (или еще называют физическим модулем).

При этом выделяют 2 типа компонент: исполняемые и библиотеки исходного кода.

Например, для С++ файлы .h и .cpp будут отдельными компонентами. Файл,

полученный после компиляции (.exe), также является компонентом системы.

Часть ПС также могут быть файлы динамических библиотек (.dll) и другие файлы.

Более подробно о видах компонент и их диаграммах поговорим, когда будем

рассматривать нотацию стандарта UML.

Значок в стандарте

Самое важное, о чем надо знать и помнить – это то, что модуль играет двойственную роль в методологии. С одной стороны, он выступает как единица программного текста, а с другой – как единица программного проекта.

И последнее, что хотелось бы сказать в завершение нашей темы (“Основные понятия и термины”).

Большинство неудач в разработке ПС имели главной причиной неправильный взгляд на процесс программирования (это подтвердила практика).

Еще 25-30 лет назад авторитеты в области программирования заявляли: “Программирование – это искусство!”, чуть позже появился лозунг: “Программирование – это наука!”, затем – : “Программирование – это производство!” Почему это важно? Почему надо иметь правильный взгляд на процесс программирования?

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

Если посмотреть на программирование как на производство, то следует применять промышленные методы работы.

Сегодня актуален лозунг типа: “Программирование – это производство в первую очередь, это – и наука, это – и искусство на определенных этапах разработки!”

9. CASE – технологии (инструменты, системы, средства). Эволюция CASE – средств, их классификация, характеристики современных CASE – инструментов. Перспективы развития.

10. Роль CASE – инструментов в объектно-ориентированной методологии разработки ПС. Связь CASE – технологии с методами быстрой разработки приложений (RAD).