Л9. Основы ооап Жизненный цикл программы для эвм
Жизненный цикл программы для ЭВМ охватывает период времени между началом разработки и окончанием его использования. При этом начало разработки связывают с моментом возникновения потребности в разработке.
В течение жизненного цикла выделяют три взаимосвязанных базовых процесса (см. рис.):
разработки;
эксплуатации (применения);
сопровождения.
Разработка- это действия по непосредственному созданию программного средства.
Эксплуатация- это действия по непосредственному применению программного средства.
Сопровождение- это действия по поддержанию программного средства в работоспособном состоянии (облуживанию), модернизации (совершенствованию) или устранению обнаруженных ошибок (модификации).
Разработка связана с эксплуатацией через процесс сопровождения.
Рис. Макромодель жизненного цикла программ
Рис. Макромодель разработки программ
1. Задачи и цели анализа и проектирования. Основные понятия.
Трудоемкость создания современных приложений на начальных этапах проекта, как правило, оценивается значительно ниже реально затрачиваемых усилий. Это приводит к следующим неизбежным последствиям:
Затягиваются окончательные сроки готовности программ.
Увеличиваются незапланированные расходы.
В процессе разработки приложений изменяются функциональные требования заказчика, что еще более отдаляет момент окончания работы программистов.
Увеличение размеров программ вынуждает привлекать сверхштатных программистов, что, в свою очередь, требует дополнительных ресурсов для организации их согласованной работы.
В разработке и внедрении современных корпоративных информационных систем принимает участие множество специалистов различной квалификации, для которых единообразное понимание архитектуры и функциональности является серьезной проблемой.
Таким образом, все эти особенности приводят к настоятельной необходимости моделирования структуры и процесса функционирования программных систем до начала написания соответствующего кода.
При этом непременным условием успешного завершения проекта становится построение предварительной модели программной системы - абстракции физической системы.
Такая модель называется логической.
Целевая установка работ по проектированию заключается в формировании ответа на вопрос: каким образом программное средство будет удовлетворять предъявленным к нему требованиям?
Причем здесь могут не рассматриваются аспекты, связанные с реализацией программного комплекса на конкретной инструментальной платформе, хотя чаще всего эта платформа, так или иначе, подразумевается в проектных решениях.
Существенной особенностью инженерного подхода к созданию программных средств является наличие стадии анализа и стадии проектирования, обеспечивающей придание программному комплексу формы, соответствующей цели его разработки.
Ход проектирования отражается в так называемых спецификациях (описаниях) программного средства с разных точек зрения и с разной степенью детализации.
В контексте проектирования спецификация - это описание программного средства любым способом, отличным от его описания на языке программирования.
Способ описания называют нотацией, а гармонизированный набор спецификаций, дающий систематическое представление о программном комплексе с разных точек зрения и с разной степенью детализации, называют системой спецификаций.
В системах спецификаций выделяют так называемые внешние спецификации, отражающие точку зрения на программный комплекс «извне» и внутренние спецификации, дающее представление о программном комплексе «изнутри».
Задачей проектирования является разработка модели программного комплекса в нотации выбранной системы спецификаций.
Исходными данными для решения задачи проектирования являются цель разработки и требования к системе, а точнее результаты их анализа, который проводится в предпроектной фазе разработки – в фазе анализа.
Фактически в фазе анализа требований решается вопрос: что должна делать будущая система? Поэтому специалисты считают, что именно в фазе анализа закладываются основы успешного проектирования и реализации программных средств в целом.
Целью анализа является преобразование общих и, как правило, неполных, нечетко сформулированных, противоречивых, а может быть и нереализуемых требований к программному комплексу в достаточно полные, точные, непротиворечивые и реализуемые формулировки требований, которые называют системными (рис. 1).
Как правило, анализ требований к программному комплексу ограничивается спецификацией требований к функциям, данным и управлению, составляющим так называемую модель требований.
Таким образом, в результате проектирования, опирающегося на требования, должна быть получена согласованная по требованиям модель реализации в рамках выделенных ресурсов и времени.
Процесс разработки логической модели называют внешним (логическим), или эскизным проектированием.
Процесс разработки детальной модели программного комплекса называют внутренним (физическим, детальным), или техническим проектированием.
Список общих требований, определенных в техническом задании, должен содержать следующие сведения:
внешние условия, при которых будет применяться система, а именно: аппаратные и программные ресурсы так называемого операционного окружения, режимы применения, состав пользователей и оборудование их рабочих мест, разграничение доступа к системе;
выполняемые функции, входные и выходные данные;
ограничения на сроки и порядок разработки системы, в том числе состав программной и эксплуатационной документации.
Системные требования, полученные в результате работы над техническим заданием с привлечением заказчиков и пользователей, должны содержать определения, достаточные для описания:
функций и внешних условий применения;
интерфейса с пользователями;
программных компонент системы и их интерфейсов.
,
данные, управление
Под методом проектирования понимают определенный процесс создания моделей, которые описывают различные стороны разрабатываемого программного средства.
В настоящее время существует множество методов проектирования программного обеспечения. Однако принципы их создания остаются общими.
Основными принципами создания моделей программных средств (принципами проектирования) являются абстракция, декомпозиция и концептуальная целостность.
Принцип абстракции заключается в описании структурных компонент проектируемого комплекса с помощью абстракций автоматизируемых процессов (функций), структур данных или объектов предметной области.
Принцип декомпозиции заключается в разбиении программного комплекса на составные части (модули) по одной из следующих схем декомпозиции цели разработки:
«Цель разработки» «Функции» «Данные» «Процедуры» «Модули»;
«Цель разработки» «Данные» «Функции» «Процедуры» «Модули»;
«Цель разработки» «Объекты предметной области» «Модули».
Первая схема отражает так называемую процедурно-ориентированную стратегию (подход) проектирования "от функций",
вторая – процедурно-ориентированную стратегию "от данных",
последняя – объектно-ориентированную.
Принцип концептуальной целостности заключается в обеспечении целостности методологической базы всего процесса проектирования в рамках единой стратегии (процедурного или объектно-ориентированного подхода).
Проектирование основывается на концептуальной целостности иерархии абстракций функций, структур данных, процедур или объектов, соответствующих схеме декомпозиции цели разработки.
Принцип абстракции
Теоретически возможны два радикальных подхода к организации иерархии абстракций (процесса построении модели программы), которые порождают два метода проектирования (исторически возникли первыми):