По оценкам экспертов, 75 % работ по программированию в мире дублируются (например, программы складского учета, начисления зарплаты, расчета затрат на производство продукции и т.п.). Большинство из этих программ типовые, но каждый раз находятся особенности, которые влияют на их повторное разработку. Компонентное проектирование сложных программ из готовых компонентов является наиболее производительным [8–12].
Переход к компонентам происходил эволюционно: от подпрограмм, модулей, функций. При этом усовершенствовались элементы, методы их композиции и накопления для дальнейшего использования (рис.5.2).
Компонентный подход дополняет и расширяет существующие подходы в программировании, особенно ООП. Объекты рассматриваются на логическом уровне проектирования программной системы, а компоненты – это непосредственная физическая реализация объектов.
Один компонент может быть реализацией нескольких объектов или даже некоторой части объектной системы, полученной на уровне проектирования. Компоненты конструируются как некоторая абстракция, которая состоит из трех частей: информационной, внешней и внутренней.
Программирование, Лекция 3. Декомпозиционное проектирование
Информационная часть представляет собой информацию о компоненте: назначение, дата изготовления, условия применения (ОС, среда, платформа и т.п.); уровень повторного использования; контекст или окружение; способ взаимодействия между собою компонентов.
| Элемент композиции | Описание элемента | Схема взаимодействия | Представле–ние, хранение | Результат композиции |
| Процедура, подпрограмма, функция | Идентификатор | Непосредственное обращение, оператор вызова | Библиотеки подпрограмм и функций | Программа |
| Модуль | Паспорт модуля, связи | Вызов модулей, интеграция модулей | Банк, библиотеки модулей | Программа с модульной структурой |
| Объект | Описание класса | Создание экземпляров классов, вызов методов | Библиотеки классов | Объектно–ориентиро–ванная программа |
| Компонент | Описание логики (бизнес), интерфейсов (APL,IDL), схемы развертывания | Удаленный вызов в компонентных моделях (COM, CORBA, OSF, …) | Репозитарий компонентов, серверы и контейне–ры компонентов | Распреде–ленное компонентно–ориенти–рованное приложение |
| Сервис | Описание бизнес–логики и интерфей–сов сервиса (XML, WSDL, …) | Удаленный вызов (RPC, HTTP, SOAP, …) | Индексация и каталогизация сервисов (XML, UDDI, …) | Распреде–ленное сер–висо–ориен–тированное приложение |
Рис.5.2. Схема эволюции элементов компонентов
Внешняя часть определяет взаимодействие компонента со средой и с платформой, на которой он будет выполняться. Эта часть имеет следующие основные характеристики:
– интероперабельность как способ взаимодействия с другими компонентами, с клиентом или сервером, а также обеспечения переносимости на другую платформу;
С чего начать разработку проекта? — Вопросы и Ответы #10
– способ интеграции (композиции) компонентов;
– нефункциональные сведения (безопасность, аутентификация, надежность и др.);
– технология проектирования (например, объектно–ориентированная среда и т.п.) и повторное использования компонентов.
Внутренняя часть – это некоторый артефакт (кластер, системная или абстрактная структура, фрагмент кода и др.) и вид его представления: проектный компонент, проектная спецификация, вычисляемая часть, код и др.
Разработана новая архитектура компонента – контейнер, в котором определяются функции, порядок их выполнения, вызываемые события и сервисные свойства. Выполнение контейнера осуществляется через его интерфейс с помощью провайдера..
Компоненты наследуются в виде классов и используются в модели или композиции, а также в каркасе интегрированной среды. Управление компонентами проводится на трех уровнях: архитектурном, компонентном и на уровне инфраструктуры интерфейса. Между этими уровнями существует взаимная связь.
Внутренняя часть компонента состоит из (рис.5.3): интерфейса (interfaces), реализации (implementation), схемы развертки (deployment).
| ХАРАКТЕРИСТИКИ | ||
| Интерфейс ¨ Один или несколько; ¨ Уникальность именования в пределах системы; ¨ Клиентский или серверный (входной или выходной); ¨ определенная сигнатура; ¨ описание методов взаимодействия | Реализация ¨ одна или несколько; ¨ ориентация на конкретную платформу и операционное окружение ¨ выбор конкретной реализации; ¨ поддержка интерфейсов компонента | Схемы развертывания ¨ типовость процедуры развертывания; ¨ управляемость; ¨ настраиваемость на операционную среду; ¨ модифицируемость |
Рис.5.3. Основные составные элементы компонента
Интерфейсы отображают взгляд пользователя на компонент, то есть что компонент будет делать, когда к нему обращаются.
Реализация – это код, который будет использоваться при обращении к операциям, которые определены в интерфейсах компонента. Компонент может иметь несколько реализаций, например, в зависимости от операционной среды или от модели данных и соответствующей системы управления базами данных, которая необходима для функционирования компонента.
Развертка – это физический файл или архив, готовый к выполнению, который передается пользователю и содержит все необходимые способы для создания, настройки и функционирования компонента.
Компонент описывается в языке программирования, не зависит от операционной среды (например, от среды виртуальной машины JAVA) и от реальной платформы (например, от платформ в системе CORBA), где он будет функционировать.
Расширением понятия компонента есть паттерн – абстракция, которая содержит описание взаимодействия совокупности объектов в общей кооперативной деятельности, для которой определены роли участников и их ответственность. Представляется повторяемой
частью программного элемента, как схемы или взаимосвязи контекста описания решения проблемы.
Интерфейс компонентов. Для объединения компонентов в компонентную модель необходимым условием является наличие формально определенных интерфейсов в языках IDL и APL, а также механизмов динамического контроля связей между компонентами в современных средах.
Спецификация интерфейса в API и IDL включает описание функциональных свойств компонентов, их типов и порядка задания операций передачи аргументов и результатов для взаимодействия компонентов. То есть, компонент – физическая сущность, которая реализует определенную совокупность интерфейсов. Сами интерфейсы являются понятием, которое связывает логическую и физическую модели.
Для описания самих компонентов, как правило, применяется ООП и его свойства: наследование, инкапсуляция, полиморфизм. В языке JAVA понятие интерфейса и класса являются базовыми. Компонентные модели – Javabeans и Enterprise Javabeans, а также модель CORBA используют объектно–ориентированные свойства.
Источник: megaobuchalka.ru
Понятие структурного программирования, этап проектирования – композиция и декомпозиция, понятие статической и динамической структуры программы, спецификация программы.
Говорят, что существует статическая и динамическая структуры программы.
Статическая структура – текст программы и ее структурная схема. Не зависит от исходных данных.
Динамическая структура определяет вычислительный процесс — состояние вычисления программы. Поэтому она(структура) зависит от исходных данных, т.к. от них зависят переходы в программе. Текущее состояние вычислений определяется значением всех входящих величин и зависит от предыдущих состояний вычислений.
Каждый оператор в программе или изменяет состояние вычисления или анализирует его, определяя тем самым переходы.
Каждый язык программирования включает в себя наборы простых операторов и способы их объединения, композиции в составные(структурные операторы).
Основным свойством композиции или структурного программирования заключается в возможности объединения произвольного кол-ва любых структур в одну – с одним входом и выходом.
S – оператор или программа
P – условия для вход.данных
Q – условия для вых.данных
Возможна также запись нотацией: S – эта запись называется спецификацией.
Проектирование программы должно начинаться с определения спецификации, которую нужно будет доказать. При этом P-предусловие, Q-постусловие.
Проектирование сверху-вниз начинается с определения спецификации i>Sii> для каждой операции, с доказательством правильности каждой подзадачи и док-вом того, что композиция всех подзадач приведет к выполнению спецификации S.
Понятие частичной и полной корректности программы, правила вывода – общий вид, правила консеквенции.
Правило вывода – рассуждение, которое говорит о том, что если соотношения, записанные над чертой верны, то справедливы и соотношения, записанные под чертой.
Рассмотрим правило вывода для простых операторов и как они получаются для составных с использованием композиций простых.
2 правила консеквенции:
Если из соотношения P следует соотношение R (предусловие) и постусловием является Q, то Q можно получить и из соотношения P. ( S – оператор).
Если из P получаем Q, а из Q следует R, то из P, после выполнения S, будет верно R.
Критерий корректности – соотношение является постусловием, если верно предусловие.
Частичная корректность программы – если после выполнения программы получаем результат и полная – если доказываем, что программа выполнима для любых допустимых значений.
Правила вывода для операторов: пустого, присваивания, составного.
Пустой оператор. Не выполняет никаких действий, не изменяет состояние вычисления => любое его предусловие будет его постусловием: .
Оператор присваивания: l>x = l
Составной оператор.
Источник: studfile.net
Языки программирования. Композиционный взгляд
Здравствуй, Хабр! Сегодня хотел бы поднять вопрос об использовании композиций и их роли в программировании. Те, кто сталкивался с функциональными языками, скорее всего слышали о них, а те, кто не сталкивался, возможно, узнают что-нибудь новое. Надеюсь на интересную дискуссию в конце статьи об их применении. Эшер для привлечения внимания.
Начнем с понятия программы. С математической точки зрения программа — это функция. Иногда это может показаться не очевидным. Если программа — функция, тогда следует решить что есть ее аргументами и что она возвращает. В случае с простыми утилитами вроде bc всё понятно: аргументом выражение из stdin, а результатом — результат в stdout.
В более сложных случаях тоже можно прийти к тому, что программа — это функция. Рассмотрим, пример, СУБД, в этом случае программа тоже функция, аргументом она принимает память, выделенную ей в user-space, ее же и возвращает, при этом непрерывно выполняясь. Может, довольно неоптимальный пример, но он доступен для понимания.
Если программа — функция, то следует рассмотреть, какие средства получения этой функции могут быть. Тут уже всё зависит от языков программирования, именно они являются такими средствами. И независимо от того функциональный это язык, процедурный, императивный, декларативный и т.д., всем им свойственно использование композиций, явное или неявное.
Пришло время определить понятие композиции. Пусть даны две функции 
и 
, из них можно построить функцию 
применив к ним функцию 
: . Такая функция F, которая принимает как аргумент другие функции и будет называться композицией. А способов построения может быть множество, каждый способ — композиция. Рассмотрим пару примеров композиций: композиция ветвления и композиция суперпозиции.
Композиция ветвления. Пусть заданы две функции и , а также один предикат 
(та же функция, но возвращающая не элемент множества, на котором определена, а значения «истина» либо «ложь»). Существует такая функция 
получается операцией ветвления, обозначим эту операцию как 
, тогда . Применив композицию к функциям, можно получить новую функцию, которую далее использовать.
Композиция суперпозиции. Пусть задана 
функция 
, где 
— 
-арная функция и существует такая функция 
, которая определяется как . В этом случае будет считаться полученной с помощью операции суперпозиции 
: )
.
Рассмотрим же прообразы этих операций в языках программирования. Где-то они более явные, где-то менее. В Языке Си операция ветвления, очевидно, сокрыта в управляющей структуре :
if(p(X)) f1(X); else f2(X);
либо тернарном операторе:
p(X) ? f1(X) : f2(X);
В первом случае был рассмотрен statement, а не expression, но это ведь не мешает представить как, например, все множество переменных в области видимости. В LISP прообраз данной композиции выглядел бы так:
(if (p X) (f1 X) (f2 X))
А в Haskell это выглядит как
if p X then f1 X else f2 X
g x | p x == True = f1 x | p x == False = f2 x
Если говорить об операции суперпозиции, то она еще менее заметна во многих языках программирования, но тем не менее, вездесуща. Операция суперпозиции в языке Си позволяет сделать следующую подстановку
f(f1(X), f2(X), f3(X));
На LISP это выглядело бы как
(f (f1 X) (f2 X) (f3 X))
На Haskell же как
f (f1 x) (f2 x) (f3 x)
Сразу следует отметить, что арность всех предложенных функций должна быть единой, иначе примение к ним механизма композиций может быть значительно затруднено, т.е. X в самом деле это что-то вроде .
Очевидно, что композиции глубоко «похоронены» в синтаксисе языков программирования, неявно присутствуя в них. Впрочем, ничего нового, как может верно заметить искушенный в этом деле читатель. Еще Эдсгар Дейкстра это заметил в своей книге «Дисциплина программирования».
Использование композиций
В связи с вышесказанным, появляется множество вопросов. В частности то, а почему композиции не используются явным образом? Ведь использование композиций явным образом могло бы принести много преимуществ. Особенно то, что станет возможным рассмотрение самого процесса программирования, а следовательно — оптимизация разработки сложных проектов.
Ведь как сейчас программирует программист? Он делает это как художник, пишущий картину. Иными словами, конструкторские решения принимаются на основании его опыта, предчувствия, советов коллег, каких-то личных эстетических убеждений. Но этот ход размышления нельзя выложить просто так в файл вместе с программой. Т.е. программа есть, а хода мыслей, приведшего к ней, нет.
Это первый вопрос. Почему у языков такой синтаксис как есть, почему создатели языка заложили именно такой набор управляющих структур? Почему их набор догматизирован? Что делать если необходимо добавить другие управляющие структуры.
Эти вопросы помогли бы решить средства применения и порождения композиций. Так как решение любой сколь угодно сложной задачи человеком сводится к анализу/декомпозиции, а потом синтезу, этот процесс может быть органично поддержан механизмом композиций. Ведь композиции будут именно тем самым связующим элементом, который будет склеивать части, на которые разбита задача. Ну а задачу разбивать так или иначе придется человеку, именно это его прерогатива, а не синтаксическое оформление задачи. К сожалению пока ни одного языка, который был бы заточен под понятие композиции, не замечено.
Для лучшего понимания рассмотрим пример с нахождением наибольшего общего делителя (НОД) с применением композиций. Вычислитель может находить остаток от деления (
), осуществлять целочисленное деление (
), вычислять предикат неравенства (
), генерировать ноль (
).
Все функции определены на множестве натуральных чисел без нуля. Таким образом имеем следующие функции в предложенной алгебре 
= < , , , , 
>.
Читатель может заметить еще одну функцию — , так называемую селекторную функцию, которая из аргументов возвращает без изменений 
-й, она необходима, так как мы работаем с -арными функциями. Кроме этого доступна композиция циклирования, назовем ее .
Приведем ее определение. Пусть даны -арных функций 
, а также -арный предикат .
Итерационно каждая функция выполняет вычисление одного из аргументов для следующей итерации, так вычисляет 
, вычисляет 
и т.д. Итерационный процесс продолжается до тех пор, пока значение предиката «истина».
Аргументы операции циклирования передаются в следующем порядке . Значение
, полученное на последней итерации будет значением функции, полученной в результате композиции. Кроме того доступна, описанная ранее, композиция суперпозиции. Тогда алгоритм вычисления НОД можно записать как
. Схематически это будет выглядеть следующим образом:
Таким образом становится возможным формализовать сам алгоритм «языком математики», а значит становится возможным его исследование математическими средствами, что позволяет уменьшить долю необоснованных или несознательно принятых конструкторских решений из-за того, что человек думает в терминах того языка программирования, на котором пишет, вместо того, чтобы размышлять композициями, которые, собственно, и лежат в основе различных языков.
Сам композиционный подход к решению начали исследовать А.И. Мальцев (мальцевские алгебры), академик Глушков (алгоритмические алгебры). Но все они работают на уровне применения композиций, догматизируя набор композиций, с которым ведется работа.
Важным улучшением композиционного подхода была бы возможность получать новые композиции из существующих, применив к ним некоторые мета-композиции. Тема интересная, не знаю чтобы кто-то ее затрагивал, но об этом в следующий раз. Надеюсь я вас не утомил.
Вышеизложенное — предмет моих исследований. Сразу сделаю ремарку, что композиционный подход не предлагается использовать для тривиальных вычислений, как тот же самый алгоритм НОД, или в проектах, где доля вычислений ничтожно мала. Хочется очень знать что считает сообщество. Имеет ли композиционный подход будущее? Хотели бы вы на практике применять композиции?
Нужны ли вам для этого инструменты?
P.S. Внезапно увидел недавний пост, затрагивающий тоже тему композиций. Надеюсь они дополнят друг друга.
P.P.S. Большое спасибо sekrasoft за то, что он помог поправить статью.
- композиция
- функции
- теория программирования
- проектирование по
Источник: habr.com