Жизненный цикл-весь период времени начиная с момента возникновения замысла(идеи) и заканчивая моментом выхода программного средства из эксплуатации.Жизненный цикл включает все процессы создания и использования ПС.Различают следующие стадии жизненного цикла ПС:разработку ПС,производство программных изделий (ПИ) и эксплуатацию ПС.каскадная модель ЖЦ(“водопад”),подразумевавшая переход на последующие этапы ЖЦ только после полного окончания работ на предыдущих этапах. Модель предполагает следующие свойства взаимодействия этапов:модель состоит из последовательно расположенных этапов;каждый этап полностью заканчивается до того как начнется следующий; этапы не перекрываются во времени, т.е. следующий этап не начинается пока не завершится предыдущий;возврат к предыдущим этапам не предусматривается или крайне ограничен;результат появляется только в конце разработки.
Рассмотрим подробнее отдельные этапы жизненного цикла. 1стратегическое планирование:определение целесообразности разработки,определение необходимых ресурсов для решения задачи;2анализ требований:спецификация требований к системе в виде “что она должна делать”, но не в виде “как это реализовать”;проверка корректности и реализуемости требований3Проектирование:создается структура будущей программой системы. Можно определить следующие фазы проектирования:проектирование архитектуры,спецификация подсистем,проектирование интерфейса,проектирование компонентов,проектирование структур данных,проектирование алгоритмов4.программирование: На этапе реализации выбирается язык программирования составляется текст программы и производится отладка5тестирование: На этом этапе выполняется комплексное тестирования всей программной системы специальной группой и программная документация.
Положительные стороны применения каскадного подхода заключаются в следующем:на каждом этапе формируется законченный набор проектной документации,отвечающий критериям полноты и согласованности;выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты.
недостатки,вызванны тем,что реальный процесс создания ПО никогда полностью не укладывался в такую жесткую схему.В процессе создания ПО постоянно возникала потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решений.
На смену каскадной модели, жестко регламентирующей последовательность этапов и критерии переходов между ними, пришла поэтапная модель с промежуточным контролем.Это итерационная модель разработки ПС с обратными связями между этапами. Проверки и корректировки разрабатываемой ИС проводятся на каждом из этапов, что позволяет существенно снизить трудоемкость отладки по сравнению с каскадной моделью. Итерационность модели проявляется в обработке ошибок выявленных промежуточным контролем. Если на каком-либо из этапов в ходе промежуточной проверки обнаружилась ошибка,допущенная на более ранней стадии разработки,работы этапа,повлекшего ошибку,необходимо провести повторно. При этом,анализируются причины ошибки и корректируются,по необходимости,исходные данные этапа или перечень проводимых работ. Аналогичная ситуация возникает если в ходе разработки ИС возникают новые требования заказчика или изменяются какие-либо условия функционирования ИС.Спиральная модель особое внимание уделяется начальным этапам проектирования: анализу требований,проектированию спецификаций,предварительному проектированию и детальному проектированию.Каждый виток спирали соответствует поэтапной модели создания фрагмента или версии ПС,уточняются цели и требования к ПС,оценивается качество разработанного фрагмента или версии ПС и планируются работы следующего витка.Таким образом,углубляются и конкретизируются все детали проектируемого ПС,и в результате получается вариант,который удовлетворяет всем требованиям заказчика.
Основная проблема спирального цикла-определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла.Переход осуществляется в соответствии с планом,даже если не вся запланированная работа закончена.План составляется на основе статистических данных,полученных в предыдущих проектах,и личного опыта разработчиков.
6. базовые понятия моделей “сущность-связь”.связи,правила их построения,типы связей.
Модель «сущность–связь» (или ER-модель)позволяет формализовать структуру и отношения между информационными объектами рассматриваемой предметной области.Все предметы реального мира обладают различными свойствами.При разработке модели предмет или класс предметов рассматривается как некоторая сущность,а элементы данных,которые описывают свойства предметов,–как атрибуты сущностей. Между сущностями устанавливаются связи,представляющие в модели отношения между объектами реального мира.Базовыми элементами модели являются понятия:атрибута;сущности;связи.
Атрибут–логически неделимый элемент информации,отображающий некоторую количественную или качественную характеристику сущности.Сущность является агрегацией атрибутов,характеризующих соответствующий ей объект или событие.Связи в модели являются бинарными(задаются между двумя сущностями)или рекурсивными (сущность оказывается связана сама с собой).Для каждого конца связи задаются:имя;степень множественности(участие в связи одного или нескольких экземпляров сущности);степень обязательности(обязательно или необязательно наличие связи между экземплярами сущностей).указывается, является ли данная связь ключевой(участвует ли в образовании ключа сущности).
На диаграмме связь изображается ромбом и линиями, соединяющими сущности.Имя связи должно отражать смысл отношения между объектами.Для связей могут быть сформулированы правила чтения:<имя сущности 1> <имя связи со стороны сущности 1> <имя сущности 2>.По степени множественности различают следующие виды связей:один к одному (1:1);многие к одному(М:1);многие ко многим(М:М).С учетом степени множественности могут быть уточнены правила чтения связей:<имя сущности1> <имя связи со стороны сущности1><один и только один/один или более> <имя сущности2>.Обязательность связи показывает могут,или не могут отдельные экземпляры сущностей находиться вне связи друг с другом.Обязательность для связи задается с двух сторон(как со стороны первой,так и со стороны второй участвующей в связи сущности).Связь является обязательной,если экземпляр сущности на одном конце связи не может быть создан вне связи с экземпляром сущности,находящейся на другом конце связи.Если экземпляр сущности на одном конце связи может быть создан вне зависимости от существования экземпляров связанной сущности,связь будет необязательной.На диаграмме обязательные связи изображаются сплошными линиями,а необязательные–пунктирными.С учетом обязательности и необязательности могут быть уточнены правила чтения связей:<имя сущности1> <должен/может><имя связи со стороны сущности1><один и только один/один или более><имя сущности2>.Связь с одной из сторон может быть помечена как ключевая.Связь является ключевой в том случае,когда собственные атрибуты не позволяют однозначно идентифицировать экземпляры сущности,т. е. различить экземпляры сущности можно только в контексте экземпляра связанной сущности.Для ключевых связей должны выполняться следующие требования:связь может быть ключевой только с одной из сторон(со стороны одной из связанных сущностей);ключевой может быть только обязательная сторона связи;в случае связи “многие к одному” связь может быть ключевой только со стороны “многие”.При графическом изображении ключевая связь помечается словом “key”.