 |
Водопадная (каскадная, последовательная) модель
|
|
|
|
Функции ОС
Основные функции (простейшие ОС):
- Загрузка приложений в оперативную память и их выполнение.
- Стандартизованный доступ к периферийным устройствам (устройства ввода-вывода).
- Управление оперативной памятью (распределение между процессами, виртуальная память).
- Управление доступом к данным на энергонезависимых носителях (таких как жёсткий диск, компакт-диск и т. д.), организованным в той или иной файловой системе.
- Пользовательский интерфейс.
- Сетевые операции, поддержка стека протоколов.
Дополнительные функции:
- Параллельное или псевдопараллельное выполнение задач (многозадачность).
- Взаимодействие между процессами: обмен данными, взаимная синхронизация.
- Защита самой системы, а также пользовательских данных и программ от действий пользователей (злонамеренных или по незнанию) или приложений.
- Разграничение прав доступа и многопользовательский режим работы (аутентификация, авторизация).
Операционные системы реального времени (Real-time operating system, RTOS) – используются для управления машинами, научной аппаратурой и промышленными системами.
Однопользовательские однозадачные – как видно из названия, такие системы предназначены для управления компьютером таким образом, чтобы в любой заданный момент времени один пользователь мог эффективно выполнять одну задачу либо действие.
Однопользовательские многозадачные – такие ОС большинство пользователей в настоящее время применяют в своих настольных компьютерах и ноутбуках. Windows от Microsoft и MacOS от Apple – примеры операционных систем, позволяющих одному пользователю одновременно выполнять несколько программ.
Многопользовательская система позволяет многим разным людям одновременно пользоваться ресурсами одного компьютера.
|
|
|
Понятие ресурса. Управление ресурсами в вычислительной системе
Ресурс – всякий объект, который может распределяться внутри ОС.
· процессоры (процессорное время)
· память
· периферийные устройства (диски, таймеры, наборы данных, принтеры, сетевые устройства и т.п.)
Ресурсы могут быть:
· разделяемые (несколько процессов используют их одновременно) и неделимые
· выгружаемые (могут быть отобраны у процесса без негативных последствий – например, оперативная память) и невыгружаемые (принудительная выгрузка приводит к сбою – например, компакт-диск)
Управление ресурсами включает в себя решение следующих задач:
· планирование ресурса (когда, кому и в каком объёме)
· удовлетворение запросов на ресурсы
· отслеживание состояния и учёт использования ресурса
· разрешение конфликтов между процессами в начало
Процессы и потоки
Программа - статический объект на диске.
Процесс - контейнер для ресурсов и исходных кодов программ. С каждым процессом программа связывает её адресное пространство, которое содержит стек, данные, набор регистров.
Поток - системный объект, получающий процессорное время, в рамках потоков выполняются инструкции процессором. Каждый процесс должен иметь хотя бы один поток (если ОС поддерживает потоки). Потоки одного процесса делят между собой адресное пространство, глобальные переменные, открытые файлы, таймеры, семафоры, статическую информацию своего процесса.
Преимущества потоков:
· меньше затрат на создание по сравнению с процессами;
· возможность взаимодействия между собой в пределах одного процесса, не обращаясь к ОС;
· повышение производительности одной программы.
3. Архитектура программного обеспечения (англ. software architecture) — это структура программы или вычислительной системы, которая включает программные компоненты, видимые снаружи свойства этих компонентов, а также отношения между ними. Этот термин также относится к документированию архитектуры программного обеспечения. Документирование архитектуры ПО упрощает процесс коммуникации между заинтересованными лицами (англ. stakeholders), позволяет зафиксировать принятые на ранних этапах проектирования решения о высокоуровневом дизайне системы и позволяет использовать компоненты этого дизайна и шаблоны повторно в других проектах.
|
|
|
Виды
Архитектура ПО обычно содержит несколько видов, которые аналогичны различным типам чертежей в строительстве зданий. В онтологии, установленной ANSI / IEEE 1471-2000, виды являются экземплярами точки зрения, где точка зрения существует для описания архитектуры с точки зрения заданного множества заинтересованных лиц.
Примеры видов:
* Функциональный/логический вид
* Вид код/модуль
* Вид разработки/структурный
* Вид параллельности выполнения/процесс/поток
* Физический вид/вид развертывания
* Вид с точки зрения действий пользователя
* Вид с точки зрения данных
Хотя было разработано несколько языков для описания архитектуры программного обеспечения, но в настоящий момент нет согласия по поводу того, какой набор видов должен быть принят в качестве эталона. В качестве стандарта "для моделирования программных систем" был создан язык UML.
Водопадная (каскадная, последовательная) модель
Основная статья: Модель водопада
Водопадная модель жизненного цикла (англ. waterfall model) была предложена в 1970 г. Уинстоном Ройсом. Она предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе. Требования, определенные на стадии формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.
Этапы проекта в соответствии с каскадной моделью:
1. Формирование требований;
2. Проектирование;
3. Реализация;
4. Тестирование;
|
|
|
5. Внедрение;
6. Эксплуатация и сопровождение.
Преимущества:
- Полная и согласованная документация на каждом этапе;
- Легко определить сроки и затраты на проект.
Недостатки:
В водопадной модели переход от одной фазы проекта к другой предполагает полную корректность результата (выхода) предыдущей фазы. Однако неточность какого-либо требования или некорректная его интерпретация в результате приводит к тому, что приходится «откатываться» к ранней фазе проекта и требуемая переработка не просто выбивает проектную команду из графика, но приводит часто к качественному росту затрат и, не исключено, к прекращению проекта в той форме, в которой он изначально задумывался. По мнению современных специалистов, основное заблуждение авторов водопадной модели состоит в предположениях, что проект проходит через весь процесс один раз, спроектированная архитектура хороша и проста в использовании, проект осуществления разумен, а ошибки в реализации легко устраняются по мере тестирования. Эта модель исходит из того, что все ошибки будут сосредоточены в реализации, а потому их устранение происходит равномерно во время тестирования компонентов и системы[2]. Таким образом, водопадная модель для крупных проектов мало реалистична и может быть эффективно использована только для создания небольших систем[3].
Итерационная модель
Альтернативой последовательной модели является так называемая модель итеративной и инкрементальной разработки (англ. iterative and incremental development, IID), получившей также от Т. Гилба в 70-е гг. название эволюционной модели. Также эту модель называют итеративной моделью и инкрементальной моделью [4].
Модель IID предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает «мини-проект», включая все процессы разработки в применении к созданию меньших фрагментов функциональности, по сравнению с проектом в целом. Цель каждой итерации — получение работающей версии программной системы, включающей функциональность, определённую интегрированным содержанием всех предыдущих и текущей итерации. Результат финальной итерации содержит всю требуемую функциональность продукта. Таким образом, с завершением каждой итерации продукт получает приращение — инкремент — к его возможностям, которые, следовательно, развиваются эволюционно. Итеративность, инкрементальность и эволюционность в данном случае есть выражение одного и то же смысла разными словами со слегка разных точек зрения[3].
|
|
|
По выражению Т. Гилба, «эволюция — прием, предназначенный для создания видимости стабильности. Шансы успешного создания сложной системы будут максимальными, если она реализуется в серии небольших шагов и если каждый шаг заключает в себе четко определённый успех, а также возможность «отката» к предыдущему успешному этапу в случае неудачи. Перед тем, как пустить в дело все ресурсы, предназначенные для создания системы, разработчик имеет возможность получать из реального мира сигналы обратной связи и исправлять возможные ошибки в проекте»[4].
Подход IID имеет и свои отрицательные стороны, которые, по сути, — обратная сторона достоинств. Во-первых, целостное понимание возможностей и ограничений проекта очень долгое время отсутствует. Во-вторых, при итерациях приходится отбрасывать часть сделанной ранее работы. В-третьих, добросовестность специалистов при выполнении работ всё же снижается, что психологически объяснимо, ведь над ними постоянно довлеет ощущение, что «всё равно всё можно будет переделать и улучшить позже»[3].
Различные варианты итерационного подхода реализованы в большинстве современных методологий разработки (RUP, MSF, XP).
Спиральная модель
Спиральная модель (англ. spiral model) была разработана в середине 1980-х годов Барри Боэмом. Она основана на классическом цикле Деминга PDCA (plan-do-check-act). При использовании этой модели ПО создается в несколько итераций (витков спирали) методом прототипирования.
Каждая итерация соответствует созданию фрагмента или версии ПО, на ней уточняются цели и характеристики проекта, оценивается качество полученных результатов и планируются работы следующей итерации.
На каждой итерации оцениваются:
- риск превышения сроков и стоимости проекта;
- необходимость выполнения ещё одной итерации;
- степень полноты и точности понимания требований к системе;
- целесообразность прекращения проекта.
Важно понимать, что спиральная модель является не альтернативой эволюционной модели (модели IID), а специально проработанным вариантом. К сожалению, нередко спиральную модель либо ошибочно используют как синоним эволюционной модели вообще, либо (не менее ошибочно) упоминают как совершенно самостоятельную модель наряду с IID[3].
|
|
|
Отличительной особенностью спиральной модели является специальное внимание, уделяемое рискам, влияющим на организацию жизненного цикла, и контрольным точкам. Боэм формулирует 10 наиболее распространённых (по приоритетам) рисков:
1. Дефицит специалистов.
2. Нереалистичные сроки и бюджет.
3. Реализация несоответствующей функциональности.
4. Разработка неправильного пользовательского интерфейса.
5. Перфекционизм, ненужная оптимизация и оттачивание деталей.
6. Непрекращающийся поток изменений.
7. Нехватка информации о внешних компонентах, определяющих окружение системы или вовлеченных в интеграцию.
8. Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.
9. Недостаточная производительность получаемой системы.
10. Разрыв в квалификации специалистов разных областей.
В сегодняшней спиральной модели определён следующий общий набор контрольных точек[5]:
1. Concept of Operations (COO) — концепция (использования) системы;
2. Life Cycle Objectives (LCO) — цели и содержание жизненного цикла;
3. Life Cycle Architecture (LCA) — архитектура жизненного цикла; здесь же возможно говорить о готовности концептуальной архитектуры целевой программной системы;
4. Initial Operational Capability (IOC) — первая версия создаваемого продукта, пригодная для опытной эксплуатации;
5. Final Operational Capability (FOC) –— готовый продукт, развернутый (установленный и настроенный) для реальной эксплуатации.
Архитектуры ОСРВ
В своем развитии ОСРВ строились на основе следующих архитектур.[1]
- Монолитная архитектура. ОС определяется как набор модулей, взаимодействующих между собой внутри ядра системы и предоставляющих прикладному ПО входные интерфейсы для обращений к аппаратуре. Основной недостаток этого принципа построения ОС заключается в плохой предсказуемости её поведения, вызванной сложным взаимодействием модулей между собой.
- Уровневая (слоевая) архитектура. Прикладное ПО имеет возможность получить доступ к аппаратуре не только через ядро системы и её сервисы, но и напрямую. По сравнению с монолитной такая архитектура обеспечивает значительно большую степень предсказуемости реакций системы, а также позволяет осуществлять быстрый доступ прикладных приложений к аппаратуре. Главным недостатком таких систем является отсутствие многозадачности.
- Архитектура «клиент-сервер». Основной её принцип заключается в вынесении сервисов ОС в виде серверов на уровень пользователя и выполнении микроядром функций диспетчера сообщений между клиентскими пользовательскими программами и серверами — системными сервисами. Преимущества такой архитектуры:
- Повышенная надёжность, так как каждый сервис является, по сути, самостоятельным приложением и его легче отладить и отследить ошибки;
- Улучшенная масштабируемость, поскольку ненужные сервисы могут быть исключены из системы без ущерба к её работоспособности;
- Повышенная отказоустойчивость, так как «зависший» сервис может быть перезапущен без перезагрузки системы.
|
|
|
