Программирование в масштабе: от малого к большому.
Programming in the large and programming in the small
Программирование в масштабе: различие между проектированием больших систем и написанием кода. Обзор концепций DeRemer & Kron, сравнение с подходами Брукса и Ousterhout.
Сравнивайте с английским: нажмите на абзац — оригинал откроется в окне. Кнопка EN под абзацем показывает его прямо в тексте.
Содержание
Введение
В разработке программного обеспечения понятия "программирование в большом" и "программирование в малом" относятся к двум различным аспектам создания программ. "Программирование в большом" подразумевает проектирование крупной системы как совокупности более мелких частей, а "программирование в малом" – создание этих частей путем написания строк кода на языке программирования. Эти термины были введены Фрэнком ДеРемером и Гансом Кроном в их статье 1975 года "Программирование в большом против программирования в малом", где они утверждают, что это по сути разные виды деятельности, и что типичные языки программирования и практика структурированного программирования хорошо поддерживают последний, но не первый. Это можно сравнить с более поздней дихотомией Остерхаута, которая различает языки системного программирования (для компонентов) и скриптовые языки (для связующего кода, соединяющего компоненты).
In software engineering, programming in the large and programming in the small refer to two different aspects of writing software. Programming in the large means designing a larger system as a composition of smaller parts, and programming in the small means creating those smaller parts by writing lines of code in a programming language. The terms were coined by Frank DeRemer and Hans Kron in their 1975 paper "Programming in the large versus programming in the small", in which they argue that the two are essentially different activities, and that typical programming languages, and the practice of structured programming, provide good support for the latter, but not for the former. This may be compared to the later Ousterhout's dichotomy, which distinguishes between system programming languages (for components) and scripting languages (for glue code, connecting components).
Описание
Фред Брукс отмечает, что способ создания отдельной программы отличается от способа создания программного продукта системы. Любое из этих условий приводит к большим и, следовательно, сложным программам, которые может быть трудно понять специалистам по сопровождению. При разработке крупных программных комплексов менеджеры кодирования делают акцент на разделении работы на модули с четко определенными взаимодействиями. Это требует тщательного планирования и детальной документации. В случае разработки крупных программных комплексов внесение изменений в программу может оказаться затруднительным. Если изменение затрагивает границы модулей, может потребоваться переработка работы многих разработчиков. Поэтому одной из целей разработки крупных программных комплексов является создание модулей, которые не потребуют изменения при вероятных изменениях. Это достигается за счет проектирования модулей с высокой связностью и слабой связанностью. Разработка крупных программных комплексов требует навыков абстрагирования. Пока модуль не реализован, он остается абстракцией. В совокупности абстракции должны формировать архитектуру, которая вряд ли потребует изменений. Они должны определять взаимодействия с точностью и доказуемой корректностью. Разработка крупных программных комплексов требует управленческих навыков. Процесс построения абстракций направлен не только на описание того, что может работать, но и на координацию усилий разработчиков, которые воплотят это в жизнь. Эта концепция была введена Фрэнком ДеРемером и Гансом Кроном в их статье 1975 года "Программирование в большом против программирования в малом", IEEE Trans. on Soft. Eng. 2(2). В терминологии компьютерных наук, разработка крупных программных комплексов может относиться к коду, представляющему логику переходов состояний высокого уровня системы. Эта логика кодирует информацию, такую как время ожидания сообщений, время отправки сообщений, время компенсации неудачных не-ACID транзакций и т.д. Язык, разработанный для явной поддержки разработки крупных программных комплексов, – BPEL.
Fred Brooks identifies that the way an individual program is created is different from how a programming systems product is created. Either of these conditions will result in large, and hence complicated, programs that can be challenging for maintainers to understand. With programming in the large, coding managers place emphasis on partitioning work into modules with precisely specified interactions. This requires careful planning and careful documentation. With programming in the large, program changes can become difficult. If a change operates across module boundaries, the work of many people may need re doing. Because of this, one goal of programming in the large involves setting up modules that will not need altering in the event of probable changes. This is achieved by designing modules so they have high cohesion and loose coupling. Programming in the large requires abstraction creating skills. Until a module becomes implemented it remains an abstraction. Taken together, the abstractions should create an architecture unlikely to need change. They should define interactions that have precision and demonstrable correctness. Programming in the large requires management skills. The process of building abstractions aims not just to describe something that can work but also to direct the efforts of people who will make it work. The concept was introduced by Frank DeRemer and Hans Kron in their 1975 paper "Programming in the Large Versus Programming in the Small", IEEE Trans. on Soft. Eng. 2(2). In computer science terms, programming in the large can refer to programming code that represents the high level state transition logic of a system. This logic encodes information such as when to wait for messages, when to send messages, when to compensate for failed non ACID transactions, etc. A language that was designed to explicitly support programming in the large is BPEL.
Программирование в малом
В разработке программного обеспечения, программирование в малом описывает деятельность по написанию небольшой программы. Небольшие программы характеризуются малым объемом исходного кода, легкостью спецификации, скоростью разработки и обычно очень хорошо выполняют одну или несколько тесно связанных задач. Программирование в малом может осуществляться отдельными разработчиками или небольшими группами в короткие сроки и может включать менее формальные подходы (например, меньший упор на документирование или тестирование), инструменты и языки программирования (например, предпочтение слабо типизированных скриптовых языков строго типизированным языкам программирования). Программирование в малом также может описывать подход к созданию прототипов программного обеспечения или ситуации, когда быстрая разработка приложений важнее стабильности или корректности. В терминах компьютерных наук, программирование в малом связано с кратковременным программным поведением, часто выполняемым как единая ACID-транзакция, обеспечивающая доступ к локальной логике и ресурсам, таким как файлы, базы данных и т.п.
In software development, programming in the small describes the activity of writing a small program. Small programs are typified by being small in terms of their source code size, are easy to specify, quick to code and typically perform one task or a few very closely related tasks very well. Programming in the small can involve programming by individuals or small groups over short time periods and may involve less formal practices (for instance less emphasis on documentation or testing), tools and programming languages (e. g. the selection of a loosely typed scripting language in preference to a strictly typed programming language). Programming in the small can also describe an approach to making a prototype software or where rapid application development is more important than stability or correctness. In computer science terms, programming in the small deals with short lived programmatic behavior, often executed as a single ACID transaction and which allows access to local logic and resources such as files, databases, etc.