LeterZP
39 KiB
Содержание
- Компьютерные системы
- Система. Системная инженерия
Компьютерные системы
Компьютерные системы (в данном курсе) - любые технические системы, оснащенные алгоритмами или заданным поведением.
Примерами таких компьютерных систем могут являться ПК, сервер, языковая модель, цифровая электрическая схема, кабели зарядки мобильных телефонов, светодиодная лампа, дверной замок, автомобиль, станок и тому подобное. У всех из них есть какие-либо алгоритмы, которые реагируют на определенные действия.
На самом деле, это довольно общее определение, и в современном понятие компьютерных систем определяется намного строже. Иногда бывают случаи, когда очень сложно определить, является ли что-либо компьютерной системой или нет.
В стандартных компьютерных системах в основном преобладает программная составляющая.
Системы с преобладающей программной составляющей
Software-intensive systems are systems in which software development and/or integration are dominant considerations. This includes computer-based systems ranging from individual software applications, information systems, embedded systems, software product lines and product families and systems-of-systems --- ISO/IEC/IEEE 42010. (Системы с преобладающей программной составляющей - это такие системы, в которых основной упор делается на разработку и/или внедрение программного обеспечения. Это включает в себя такие компьютерные системы, как отдельное программное обеспечение, информационные системы, встроенные системы, линейки и семейства программного обеспечения и системы систем.)
В настоящее время такие системы преобладают. В современном мире около половины стоимости всей разработки какого-либо оборудования уходит на разработку программного обеспечения.
Классификация компьютерных систем
В основе своей, вся вычислительная техника создана для того, чтобы либо быстро обрабатывать данные - информационные системы, либо точно управлять данными - управляющие системы. Оба этих класса обладают разными требованиями к своим составляющим, и это в конечном итоге выливается в различие между внутренней составляющей таких систем.
Информационные системы
Основная цель информационных систем - получить данные, преобразовать или накопить их каким-либо образом, и выдать их в измененном или обработанном виде. Приоритетом таких систем всегда является экономия времени и скорость обработки данных, и даже не важно насколько - даже если можно сэкономить одну лишнюю миллисекунду, это нужно сделать (если можно быстрее, то нужно быстрее).
Из-за этого у такой системы развился ряд особенностей. Основными из них являются упор в производительность, появление параллелизма (параллельных вычислений) и спекулятивных вычислений ("угадывание" ответа), а также развитие кластерных и облачных вычислений.
У этих систем история довольно долгая. Начиналось все еще с огромных установок-мейнфреймов, на которых считали сложные формулы, используя перфокарты. Очевидно, при таком подходе сам по себе компьютер был общим для всех. По мере же уменьшения таких конструкций у каждого человека постепенно появился свой пользователь на машине, что позже переросло в персональные компьютеры. Следующим шагом для информационных систем стало развитие интернета и переход к клиент-серверной архитектуре, что позволило обрабатывать данные не на локальных устройствах, а с использованием серверов в интернете. В последствии же решили отказаться даже от компьютеров, и центр сместился на вычисления с использованием мобильных устройств и облачных серверов.
Управляющие системы
Основным приоритетом управляющих систем является взаимодействие с реальным физическим миром с целью контроля или управления посредством получения данных, их преобразования или накопления, и выдачи в измененном или обработанном виде. Приоритетом таких систем является своевременность получения и выдачи данных, а не скорость их обработки.
Основными особенностями таких систем являются встроенное исполнение (то есть интеграция в реальный мир, обладание ограниченными ресурсами или энергией и специализация функций, платформы и аппаратуры), автономная эксплуатация и требование реального времени.
В данном случае, реальное время представляет собой вполне определенный срок. Реальное время не значит быструю работу, абсолютно точную работу или работу без отказов. На самом деле, реальное время - это предсказуемо и в срок. В управляющих системах мы всегда знаем объем вычислительных задач, которые необходимо решить, поэтому основной упор делается на реагирование именно в тот момент времени, в который мы ожидаем, не раньше и не позже. Реальное время также обозначает спецификацию между внешним воздействием и реакцией на него.
Конечно же, нас также интересует история управляющих систем. Началось все еще с 60-ых годов прошлого столетия, с появлением информационно-управляющих систем (ИУС). На их основе были построены встроенные системы (ВсС), а позже они развились и до распределенных встроенных систем (РВсС). В настоящее время самым современным решением считаются киберфизические системы, которые разрабатываются посередине между системами управления и системами вычислительной техники. С каждым десятилетием степень интеграции встроенных систем с объектом мониторинга и/или управления возрастает, хотя изначально ИУС были интегрированы в объект управления достаточно мало.
Параллельно с управляющими системами также развивались малые интегральные схемы, тесно связанные с управляющими системами. С появлением микропроцессоров было принято решение устанавливать их во встроенные системы. Во времена распределенных встроенных систем появление систем на кристалле повысило актуальность таких схем. С появлением же сетей на кристалле, а также графических ускорителей и нейропроцессоров, эти схемы стали неотъемлемой частью киберфизических систем. Таким образом, интегральные схемы выросли параллельно с управляющими системами, увеличив количество элементов в микросхеме с десяти до миллиарда.
Система. Системная инженерия
Системная инженерия
Системная инженерия (SE) - это междисциплинарные подход и средство, позволяющее реализовать успешные системы. Он фокусируется на целостном и одновременном понимании потребностей заинтересованных сторон (стейкхолдеров); изучении возможностей; документировании требований; и синтезе, проверке, приемке и разработке решений при рассмотрении всей проблемы, от исследования концепции системы до вывода системы из эксплуатации. (--- The Guide to the Systems Engineering Body of Knowledge (SEBoK), V.1.3.2014).
Из определения следует, что системная инженерия - процесс рассмотрения системы не только с какой-то одной точки зрения, а исследование всех углов системы и ее полное понимание. Такой подход помогает принимать решения, понимая все процессы внутри системы и результаты какого-либо вмешательства в нее.
Предметом системной инженерии может быть что угодно, будь то даже машина, самолет или нефтяная вышка (такие системы иногда называют сверхбольшими). В таких системах очень важно иметь представление о всех ее составляющих, ведь одно неверное изменение в конструкции может спровоцировать ряд проблем в других частях системы.
Отсюда вытекает и роль системной инженерии. Системный инженер способен взаимодействовать с покупателем (заказчиком), понимая и анализируя его требования, передавая эти требования в нужном виде команде разработчиков для внедрения, а также поддерживая всю систему на протяжении всего ее жизненного цикла. Системная инженерия фокусируется на том, чтобы удостоверится в достижении целей и задач системы связыванием всех ее частей воедино.
Понятие системы
Понятие системы можно рассматривать с трех разных точек зрения. С одной стороны, система - это совокупность частей (различные небольшие элементы образуют полноценную систему). С другой, система - это функциональное место (система - это место, откуда мы получаем результат, и не важно, что происходит внутри этой системы). С третьей, система - это жизненный цикл (то, как система рождается и умирает).
Система как совокупность частей
Система - это комбинация взаимодействующих между собой элементов, организованных для достижения одной или нескольких установленных целей. Такую систему можно рассматривать как готовый продукт или услугу, которую она предоставляет.
Для такого определения системы можно использовать аналогию. Пусть система - это дом. У этого дома есть свои конструкция, электрическое обеспечение, водопровод, канализация, вентиляция и так далее. В разных частях дома эти конструкции иногда соприкасаются друг с другом, а иногда сосуществуют независимо друг от друга. Также и со структурой системы. Она состоит из различных неотделимых друг от друга частей. С разных ракурсов такую систему можно увидеть по-разному. В зависимости от того, что с этой системой происходит, ее структура может меняться.
Система как функциональное место
В данном случае, систему определяет только название, назначение и границы. При этом нам не важно, что именно находится внутри этой системы и как оно работает (что как раз и означает, что мы не пересекаем границы системы).
Операционное окружение
При таком подходе у системы можно выделить операционное окружение.
Операционное окружение - окружение, в котором развертываются системы. Проблема или возможность, в ответ на которую была разработана система, тоже является частью этого окружения.
Это важный фактор, который учитывается при определении возможностей системы, желаемых результатов и выгод для заинтересованных сторон, а также ограничений.
Представление и точка зрения
Определив систему как функциональное место, мы тогда можем рассматривать систему с разных сторон, с разных точек представления, где каждая рассматривает собственную задачу, выполняемую системой.
Представление (View) - представление системы с заданной точки зрения.
Таким образом, система разбивается на несколько частей, каждая из которых решает собственную функцию.
Stakeholder - individual or organization having a right, share, claim, or interest in a system or in its possession of characteristics that meet their needs and expectations --- ISO/IEC/IEEE 2015 (Заинтересованная сторона - это человек или организация, у которой есть права, доля, притязания или интерес к системе или к части ее характеристик, удовлетворяющих соответствующим требованиям и ожиданиям).
Иными словами, система не собирается в одиночку. За каждую часть системы, за каждое представление, отвечает определенная заинтересованная сторона.
Точка зрения (Viewpoint) - это спецификация соглашений, правил построения и использования представления с целью решения проблем заинтересованных сторон.
То есть, каждая функция системы определяется через собственную точку зрения на систему. Тем не менее, мы не можем представить систему сразу со всех точек зрения. Именно поэтому нам это разбиение так необходимо.
Система как жизненный цикл
Жизненный цикл системы - это эволюция интересующей системы во времени от концепции до вывода из эксплуатации.
У жизненного цикла системы можно выделить несколько типовых стадий ее развития.
- Концептуальный этап
- Этап разработки
- Этап производства
- Этап утилизации
- Этап поддержки
- Этап вывода из эксплуатации
В данном случае слово "утилизация" используется как образованное от английского слова "utilization" и означает основной этап использования системы и ее эксплуатации.
Тем не менее, это лишь типовые стадии. Для каждой системы необходимо подгонять стадии под основные нужды с учетом специфики системы, ее целей и возможностей.
Обеспечивающие системы
Конечно, система не может выполнить все такие стадии самостоятельно. Именно для этого существуют обеспечивающие системы.
Обеспечивающая система - система, которая дополняет интересующую систему на этапах ее жизненного цикла, но не обязательно вносит непосредственный вклад в ее функционирование во время эксплуатации. (--- ISO 15288)
Иными словами, для каждого этапа системы существует собственная система, находящаяся на этапе утилизации (эксплуатации) и выполняющая основные функции обеспечения и помощи.
Требования для разработки успешной системы
Разработка успешной системы требует
- рассмотрения ее структуры
- рассмотрения ее функционального места
- рассмотрения ее операционного окружения
- рассмотрения ее жизненного цикла
- рассмотрения ее обеспечивающих систем
Аналогичные результаты были получены в ряде других исследований, и такой же вывод можно найти, к примеру, в OMG Essence (стандарт задающий общее ядро понятий для описания, сравнения и разработки ПО) или в СМД-методологии (системомыследеятельностный подход по Г. П. Щедровицкому).
Архитектура
При разработке компьютерных систем часто возникают проблемы коммуникации. Одной из основных причин возникновения таких проблем является взгляд на систему только с какой-то одной точки зрения. Из-за этого становится важным навык видеть все вопросы и проблемы, возникающие при разработке. Как говорил Барри Боэм (Barry W. Boehm): "Poor management can increase software costs more rapidly than any other factor. (Плохой менеджмент может увеличить стоимость программного обеспечения намного стремительнее, чем любой другой фактор.)". Именно поэтому при разработке очень важна архитектура.
Архитектура - формальный способ зафиксировать множественность точек зрения на систему и передать ее другим.
Классическое определение архитектуры
Архитектура - логическая и физическая структура компонентов системы и их взаимосвязи, сформированные всеми стратегическими и тактическими проектными решениями, применяемыми во время разработки. Логический взгляд на систему учитывает концепции, созданные в концептуальной модели, и устанавливает существование и роль ключевых абстракций и механизмов, которые будут определять архитектуру и общий дизайн системы. Физическая модель системы описывает конкретный программный и аппаратный состав реализации системы. Очевидно, что физическая модель зависит от конкретной технологии. --- Гради Буч
Определение архитектуры в системной инженерии
Architecture - fundamental concepts of properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution. Architecture description - work product used to express an architecture. There is no single characterization of what is essencial or fundamental to a system; characterization could pertain to any or all of: system constituents or elements; how system elements are arranged or interrelated; principles of the system's organization or disign; and principles governing the evolution of the system over its life cycle. --- ISO 42010 (Архитектура - это фундаментальные концепты свойств системы в ее окружении, заключенные в ее элементах, отношениях, а также принципах ее дизайна и эволюции. Описание архитектуры - это рабочий продукт, используемый для выражения архитектуры. Не существует единственного обозначения того, что важно и фундаментально для системы; но оно может иметь все или несколько из таких характеристик, как: элементы или части системы; способы взаимодействия элементов системы; принципы организации или дизайна системы; и принципы направления эволюцией системы на протяжении всего ее жизненного цикла.)
Сущностные определения системы
Архитектура - все важное. --- Интернет
Software architecture is the set of design decisions which, if made incorrectly, may cause your project to be cancelled. --- Eoin Woods (SEI 2010) (Архитектура программного обеспечения - это набор проектных решений, которые, если они будут приняты неправильно, могут привести к отмене вашего проекта.)
Проблема коммуникации при разработке компьютерных систем
При передаче информации или делегировании задач важные для успеха вопросы могут быть упущены. Существует несколько основных причин таких упущений, которые стоит учитывать.
- Вопрос выходит за пределы компетенции разработчика.
- Преобладает шаблонное проектирование.
- Искусственное сужение проектных требований.
- Расстановка приоритетов.
- Подмена одной задачи другой.
Предположим, что у нас есть технический специалист, который поручил работу своему младшему коллеге с целью проработки и усвоения данной темы. Старший специалист отлично знает эту область, и он хочет, чтобы его коллега смог сам изучить все важные вопросы и нюансы, поэтому постарался подобрать наиболее оптимальную задачу, при этом подробно объяснив основы и способ ее выполнения. Несмотря на все трудности, младший коллега все таки выполнил задачу, но не учел некоторых важных вопросов, которые хоть и не были важны в этой конкретной задаче, но имеют не последнее значение в этой теме. Таким образом, коммуникация между двумя коллегами не удалась, ведь младший коллега не смог изучить все необходимые вопросы самостоятельно, несмотря на все указания старшего.
Но что, если задачу ставит человек, который не разбирается в этой теме, но компетентен в других? Предположим, что менеджер ставит задачу разработчику. При поручении задачи менеджер, опираясь на свои знания своей темы, постарался максимально подробно объяснить разработчику основные важные моменты. Но разработчик, обладая знаниями совершенно другой темы, решил задачу, опираясь на свои знания. В итоге, хоть он и учел все возможные проблемы, менеджер все равно не принял его работу, ведь она не соответствовала одному из самых важных вопросов, о котором разработчик даже не догадывался.
Эти два примера, особенно последний, показывают, насколько важно минимизировать проблемы коммуникации между людьми, и соответственно, насколько важна архитектура.
Причины важности архитектуры
Риск откладывания управления рисками
Очень важно не откладывать управление рисками. Как доказано на практике, чем позже дефект продукта будет исправлен, тем больше ресурсов на это будет необходимо потратить. При этом стоимость такого исправления будет расти экспоненциально.
V-диаграмма
Важным понятием при проектировании системы является V-модель, или V-диаграмма. Она показывает несколько этапов развития и внедрения проекта. Внизу данной V-диаграммы находится интеграция в систему. По левой ветке сверху вниз идет процесс определения и уточнения проекта: все начинается с концепции, продолжается требованиями и архитектурой, а позже уточняются детали. По правой ветке снизу вверх идет процесс создания проекта: начиная с внедрения, тестирования и проверки отдельных частей, продолжая тестированием с интегрированием в систему, заканчивая полным внедрением и использованием. При этом каждая правая часть проходит этап верификации: каждый этап проверяется на соответствие тому, что было заложено в соответствующей левой части. В конце, после того как проект стал полностью готов к внедрению, происходит валидация: проверка проекта на соответствие тому, что нам изначально было нужно и какую проблему мы стремились решить (то есть соответствие самому верхнему уровню правой части диаграммы самому верху левой части).
Эффект архитектурного проектирования
Проектирование системы с архитектурой может затруднить ее разработку на раннем этапе (ведь собрать все точки зрения и составить из них полноценную архитектуру, учитывающую все факторы происходящего, довольно дорого), но намного упростит ее на позднем этапе и решит большую часть проблем, которые могут возникнуть.
Наглядно это можно изобразить на графике зависимости затрат на проектирование от отставания проекта от плана. В данном случае, затраты - это функция отношения стоимости и качества архитектуры к стоимости всего проекта, а отставание - это функция отношения реального времени разработки проекта от запланированного. На таком графике видно, что, хоть в начале разброс и получается огромным, но ближе к концу он уменьшается, чаще всего достигая или перегоняя план, но самое главное устанавливая минимальный разброс от плана, что гарантирует стабильность развития проекта на позднем этапе.