Архитектура систем и интеграция программного обеспечения | SYSTEMS ARCHITECTING AND SOFTWARE INTEGRATION

University of Southern California, University Park, Los Angeles, CA 90089-2565, USA

Семинар прошел в Универcитете Южной Калифорнии и записан со слов, иллюстрации - аналог нынешних презентаций - приводятся отдельно.

Перевод материалов семинара выполнен в 2025 году. К сожалению, у меня нет точной даты, когда он состоялся. Технические примеры относятся к концу 80х - началу 90х годов. Судя по списку литературы, семинар состоялся не раньше 1994 года. Тем не менее, материалы крайне актуальны, что вы можете оценить сами. Далее параллельно идет текст на английском и русском языках, чтобы было удобно обращаться к оригиналу (прим.перев.).

Первая часть материалов семинара опубликована в трех текстах на платформе telegra.ph для канала https://t.me/computersecuritybasics

Часть первая | текст 1| Введение. Процесс создания архитектуры

Часть первая | текст 2 | Основы создания архитектуры систем (1)

Часть первая | текст 3 | Основы создания архитектуры систем (2) Заключение

Abstract | Аннотация

It is increasingly being recognized that unless complex, real-time systems are well-structured -- architected - they are unlikely to be satisfactory, regardless of the subsequent excellence of systems engineering and integration. This talk addresses the art of systems architecting - its heuristic (qualitative) foundations, its role in system software development, and its educational methodology. Among the system issues raised are the synchronization of the disparate waterfall and spiral processes, the early establishment of acceptance criteria, and the risks of reusable modules.

Мы все больше понимаем, что без надлежащей структуры (архитектуры) сложных систем реального времени они вряд ли будут соответствовать нашим потребностям, независимо от того, каких вершин мы достигнем в системной инженерии и интеграции. Этот рассказ об искусстве разработки системной архитектуры — о его эвристических (качественных) основах, роли в разработке системного программного обеспечения и о методологии обучения. Среди поднимаемых вопросов — синхронизация разрозненных процессов в жизненном цикле ПО типа «водопад» и «спираль», раннее установление критериев приемлемости ПО и риски, связанные с повторным использованием программных модулей.

Part One: Foundations | Часть первая: основы

Introduction | Введение

This seminar is being held during a remarkable time in the history of software. In a major paradigm shift, software for real time systems is transitioning from being a "glue" that holds together previously specified hardware to being the centerpiece of system design and operation. Increasingly, software determines what the user perceives the system to be — its behavior and structure — the friendlier, the better.

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

In a deceptively simple example of what the user perceives, the driver of an automobile believes that moving a wheel steers the car, moving a lever changes gears, pushing on one pedal accelerates and another decelerates the car and so on. Instead (Figure 1), these pseudo-mechanical devices send electrical signals to microprocessors which modify and convert them into engine management, antilock braking, grade-sensitive propulsion and speed-sensitive maneuvering and suspension - modulated by sophisticated vehicular instrumentation and completely hidden from the driver. And this is only the beginning of a new era of automotive redesign. Electric cars, with their compelling need for computer- controlled energy management, can do no less.

Пример чрезмерно упрощенного восприятия системы пользователем: водитель автомобиля считает, что движение колеса управляет автомобилем, движение рычага меняет передачу, нажатие на одну педаль ускоряет, другая замедляет автомобиль и так далее. Вместо этого (рисунок 1, диаграмма Венна для автомобиля), эти псевдомеханические устройства посылают сигналы электронным устройствам, которые преобразуют их в управление двигателем, в активацию тормозов с функцией антиблокировки, в величину тяги, зависящую от уклона, в маневры, которые выполняются по-разному в зависимости от скорости и в модулируемую сложными автомобильными приборами подвеску. Все это полностью скрыто от водителя. Это только начало новой эры автомобильной модернизации. Электрические автомобили, с их потребностью в управляемом компьютером управлении энергией, могут сделать не меньше.

A more dramatic paradigm shift is the one in personal computer design from a hardware- constrained "keep the CPU busy" to a software-enabled "keep the user busy"; i.e., from maximizing computer efficiency to increasing system effectiveness. It is an eminently practical shift; hardware costs are so low compared to software costs, that adding hardware can be more cost effective than constraining software for the same system gain.

Более радикальный сдвиг парадигмы произошёл в разработке персональных компьютеров: от аппаратного ограничения «загрузить процессор» к программному обеспечению «загрузить пользователя», то есть от максимизации эффективности компьютера к повышению эффективности системы. Это исключительно практичный сдвиг: стоимость оборудования настолько мала по сравнению со стоимостью программного обеспечения, что добавление оборудования может быть более экономически выгодным, чем ограничение программного обеспечения при том же приросте производительности системы (имеется в виду, что дорабатывать ПО, снижая его потребности под аппаратную часть, может быть дороже, чем добавить аппаратной мощности, плюс во втором случае имеется выигрыш для всей системы, так как пользователь в более мощной системе работает эффективнее; для 80-90х годов это был неочевидный момент – прим.перев.).

On a global scale, it is now readily apparent that two major systems, global air transportation and global communications, have radically changed the social, political and economic conditions of the world. Two others, global positioning and cellular telephony, can only accelerate the change.. The results are more efficient financial transactions, tighter inventory control, and rapid product distribution anywhere any time around the world. All these systems are critically dependent on software to make their information-intensive operations effective and profitable. Literally, success or failure rides on that software.

В глобальном масштабе сейчас совершенно очевидно, что две основные системы – глобальный воздушный транспорт и глобальная связь – радикально изменили социальные, политические и экономические условия в мире. Две другие – глобальное позиционирование и сотовая связь – могут лишь ускорить эти изменения. Результатом этого являются более эффективные финансовые транзакции, более строгий контроль запасов и быстрая доставка товаров в любую точку мира. Все эти системы критически зависят от программного обеспечения, обеспечивающего эффективность и прибыльность их информационно-интенсивных операций. Успех или неудача буквально зависят от этого программного обеспечения.

As a consequence, software engineers are increasingly drawn into systems design. Central to their understanding of such systems is their architectures and how software architectures fit into and control them. Not surprisingly, specialized, domain-specific, software architectures are now a prime topic for both software and system engineers. (Figure 2) Parenthetically, common interest in architectures may well bring these usually separate parties together. At least, Bill Gates of Microsoft seems to be betting on it

В результате инженеры-программисты всё чаще вовлекаются в проектирование систем. Ключевым элементом их понимания таких систем является их архитектура и то, как архитектура программного обеспечения вписывается в них и управляет ими. Неудивительно, что специализированные, предметно-ориентированные архитектуры программного обеспечения теперь являются одной из главных тем как для инженеров-программистов, так и для системных инженеров. (Рис. 2) Кстати, общий интерес к архитектуре вполне может объединить эти обычно разрозненные стороны. По крайней мере, Билл Гейтс из Microsoft, похоже, делает на это ставку.

What software architects now see as they look outward into systems is a much more chaotic, diversified and domain-specific world than the mathematically-elegant, abstract one of von Neumann and Turing. In this new world, problems are far less structured, optimization is meaningless if not impossible, analysis can produce paralysis, and sociopolitical issues really count. Why? (Figure 3) Because there are so many stakeholders, so many definitions of "success," so many variables, and so many tradeoffs - - with far too little data for meaningful analyses and crisp decisions. In the system world, the only practical hope is for reasonable satisfaction based on feasible constructs.

То, что архитекторы программного обеспечения в настоящий момент видят, глядя на системы, — это гораздо более хаотичный, диверсифицированный и предметно-ориентированный мир, чем рафинированно-элегантный и абстрактный мир фон Неймана и Тьюринга. В этом новом мире проблемы гораздо менее структурированы, оптимизация бессмысленна, если не невозможна, анализ может парализовать, а социально-политические вопросы действительно важны. Почему? (Рис. 3) Потому что существует так много заинтересованных сторон, так много определений «успеха», так много переменных и так много компромиссов — при этом слишком мало данных для осмысленного анализа и принятия чётких решений. В системном мире единственная практическая надежда — на разумное удовлетворение, основанное на осуществимых конструкциях.

The first step is to bring some order to the situation - to "structure" it, to bring practical "form" to the desired "functions," and to deliver a certifiable result to the user-client

Первый шаг — навести порядок в ситуации, «структурировать» ее, придать практическую «форму» желаемым «функциям» и предоставить пользователю-клиенту подтверждаемый результат.

The process of аrchitecting | Процесс создания архитектуры

And so, welcome to the process of architecting, conceived thousands of years ago in response to just such situations. It necessarily is an art as well as a science.

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

First, the science.

The science of architecting, like any science, is based on established experimental and mathematical principles and proofs. It is based on measurable "facts," defined as reproducible data. Literally, if something isn't measurable, it isn't science. Its problems must be carefully structured. Its boundary conditions must be specified with precision. It is the foundation of systems engineering. It is well taught, well documented, and highly certifiable. "Optimization" is an almost universal byword. When its conditions are met, it is extraordinarily powerful. The difficulty is that in the early stages of new system development, facts and figures are at best imprecise. Many requirements - like customer preferences and social acceptance — are not measurable. Something has to be done to bring more certainty and order before and during the use of scientific and rational problem-solving methods.

Во-первых, наука.

Наука архитектурного проектирования, как и любая другая наука, основана на устоявшихся экспериментальных и математических принципах и доказательствах. Она основана на измеримых «фактах», определяемых как воспроизводимые данные. В буквальном смысле, если что-то не является измеримым, это нельзя назвать наукой. Научные проблемы должны быть тщательно структурированы. Граничные условия в научном подходе должны быть точно определены. Это основа системной инженерии. Системная инженерия хорошо преподаётся, хорошо документирована и в высшей степени сертифицируема (то есть результаты могут быть удостоверены третьей стороной – прим.перев.). «Оптимизация» — это фактически притча во языцех (имеется в виду формальная оптимизация разработки и то, что к ней все стремятся, но достигнуть ее невозможно – прим.перев.). Это необычайно мощный инструмент, если его можно применить корректно. Однако сложность заключается в том, что на ранних этапах разработки новой системы данные и цифры (относящиеся к требованиям – прим.перев.) в лучшем случае неточны. Многие требования, такие как предпочтения клиентов и приемлемость с точки зрения общества, не поддаются измерению. Необходимо что-то сделать, чтобы внести больше определённости и порядка до и во время использования научных и рациональных методов решения проблем.

The art of architecting, in contrast, deals with the challenges of the data-sparse, the unprecedented, the ill-structured, the unbounded and the complex. The systems of most interest have never been built before — a first manned flight to the moon, an in situ exploration of the planets, a new style of computing, an information superhighway, a stealth aircraft. Rank-ordering requirements, crucial for design, can be an exercise in frustration. The systems themselves are unbounded; i.e., they both contain, and are part of, other systems each of which has its own "externals." Their mix of diverse elements -­technical, social, financial and political -- is too complex to treat mathematically with much if any confidence.

Искусство архитектуры, напротив, имеет дело с проблемами разреженных данных, беспрецедентности, плохой структурированности, отсутствия четких границ и излишней сложности. Наиболее интересные системы – это те, которые никогда ранее не были построены, например первый пилотируемый полёт на Луну, исследование планет in situ, принципиально новый стиль вычислений, информационная супермагистраль, самолёт-невидимка. Ранжирование требований, критически важных для проектирования, могут стать настоящим испытанием для ума. Сами системы не являются ограниченными, они одновременно содержат в себе другие системы и являются их частью, и каждая из них имеет свои собственные «внешние» характеристики. Сочетание их разнообразных элементов – технических, социальных, финансовых и политических – слишком сложно, чтобы подходить к ним математически и с какой-либо степенью уверенности.

Далее: Основы создания архитектуры систем (1)