Попытался в общих чертах выделить основные свойства современных парадигм программирования применительно с точки зрения статического анализа исходных кодов программы. Главная цель — определить направления исследования (наконец сел писать диссер — а то все идеи да мысли ).
Зацените, плз, и если можно укажите ошибки/недостатки/упущения (на метрики можно не обращать внимания):
1. Метрики, применимые при различных подходах проектирования ПО.
Выделим 4 современных парадигмы программирования для императивных ЯП:
1. Процедурное программирование (ПП)
ПП предполагает разделение процесса обработки данных на процедуры по неким общим признакам и целям обработки.
1.1. Поток управления: определенная последовательность вызовов функций.
1.2. Поток данных: данные представляют собой набор значений, над которыми производится операции. Данные и функции обработки данных логически не связаны между собой.
1.3. Взаимодействие с внешней средой осуществляется путем предоставления списка доступных функций с описанием их сигнатуры, и списка глобальных данных.
1.4. Метаданные: отсутствуют
Для статического анализа исходного кода можно применять метрики:
— Объем программы: LOC-оценки, метрики Холстеда
— Потока управления программы: метрики Маккейба, Майерса, Джилба, «Подсчет точек пересечения», метод граничных значений.
— Потока данных: метрики Чепина, Спена, Овьедо, метрика «модуль-глобальная переменная»
2. Объектно-ориентированное программирование (ООП)
ООП предполагает группировку процесса обработки данных и самих обрабатываемых данных в единый объект по некоторым признакам общности.
2.1. Поток управления: состоит из двух частей — неопределенная последовательность взаимодействий объектов и определенная последовательность вызвов методов внутри объекта.
2.2. Поток данных: состоит из двух частей: данные, передаваемые между объектами, и данные, инкапсулированные внутри объектов. Обработка данных производится только внутри объектов, которым они принадлежат.
2.3. Взаимодействие с внешней средой осуществляется через описание интерфейса объекта и только через него. Интерфейс объекта – это список доступных методов объекта с описанием их сигнатуры и список типов данных, которые можно получить от объекта.
2.4. Метаданные: необязательны, применяются для задания дополнительных аттрибутов как объектам в целом, так и их методам и данным.
Анализ объектно-ориентированной программы можно разделить на две части:
— анализ структуры каждого отдельного объекта: здесь возможно применить все методы анализа процедурных программ. Дополнительно к ним требуется провести анализ интерфейсов объектов и метаданных объектов. Метаданные могут также быть использованы как дополнительная информация для анализа объектов. При этом анализ объекта должен проводится вне контекста взаимодействующих с ним других объектов.
— анализ взаимодействия объектов: анализ графа объектов, степень зависимости объектов и их интерфейсов друг от друга, характеристики потока данных и потока управления между объектами. Здесь применимы метрики связности класса по данным и по методам, зависимости изменений между классами, локальности данных класса, наборы метрик Чидамбера и Кемерера, Лоренца и Кидда, Абреу.
3. Компонентно-ориентированое программирование (КОП)
КОП предполагает объединение ПП-процедур или ООП-объектов в компоненты по принципу функциональной общности и целостности. В отличие от ООП-объектов компонент должен быть независимым от внешней среды в рамках, определяющих его функциональное назначение.
3.1. Поток управления: также состоит из двух частей – взаимодействие ПП-процедур или ООП-объектов внутри компонента и взаимодействие между компонентами в системе. При оценке ПУ для КОП ПС можно применять те же методы, что и для ПП и ООП с учетом свойства «независимости» компонентов друг от друга.
3.2. Поток данных: также можно разделить на два субпотока – данные, поступающие из/во внешний мир и данные, циркулирующие внутри компонента. Аналогично анализу потока управления можно использовать методы ПП или ООП анализа.
3.3. Взаимодействие с внешней средой: осуществляется, как и в ООП, через объявление интерфейса компонента. Но если интерфейс ООП-объекта просто предоставляет «наружу» список возможностей объекта, интерфейс компонента также предъявляет определенные требования к взамодействующим с ним компонентам.
3.4. Метаданные: наличие обязательно, т.к. они являются основным инструментом определения интерфейса компонента.
Структура анализа КОП программ аналогична ООП, для анализа можно использовать модифицированные методы ООП.
4. Аспектно-ориентированое программирование (АОП) (?)
АОП является, по сути, расширением возможностей ООП парадигмы за счет непосредственного внедрения метаданных в ЯП. В АОП дополнительно вводится обобщение объектов, методов и данных объектов на основе их принадлежности к некоторым общим группам по признакам т.н. «сквозной» функциональности. В целом, можно сказать, что такие группы являются отдельными объектами, но в то же время являются частями всех объектов в группе.
4.1. Поток управления: анализ ПУ аналогичен анализу в ООП, но с учетом того, что подпотоки групп являются одинаковыми для всех объектов, принадлежащих некоторой группе и по сути являются отдельными (?) потоками.
4.2. Поток данных: содержит в себе подпотоки данных, являющихся общими для всех объектов групп, но в тоже время каждый из этих подпотоков индивидуален для каждого объекта.
4.3. Взаимодействие с внешней средой: полностью аналогично ООП.
4.4. Метаданные: обязательны, являются частью ЯП.
Структура анализа АОП программ аналогична ООП, для анализа можно использовать модифицированные методы ООП.
Заранее ОГРОМНОЕ спасибо за конструктивную критику
Я бы обязательно добавил еще Модульное программирование. Метриками которого (вдобавок к остальным) является ациклический граф импорта модулей. (Сколько модулей, сколько связей между ними,...)
В разделе про КОП явно бы написал, что КОП появилось в следствии объединения ООП и Модульного программирования. Компонент — это модуль внутри которого определены взаимозависимые друг от друга типы. Соответсвенно, в КОП есть ациклический граф импорта компонентов=модулей и граф зависимости типов (содержащий циклы). Если типы зависят друг от друга не взаимно, а ациклично, то нет смысла помещать их внутрь одного компонента, лучше сделать несколько компонентов с ациклическим графом импорта.
Здравствуйте, Quintanar, Вы писали:
Q>Странно, что не упомянуто функциональное программирование, не смотря на то, что функциональные программы анализировать на порядок легче.
Для начала я взял самое понятное для меня императивное программирование (я даже специально это отметил) — сначала разберусь с ним, а уж затем с функциональным, аппликативным и т.д.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, LIS, Вы писали:
LIS>>Привет!
СГ>Я бы обязательно добавил еще Модульное программирование. Метриками которого (вдобавок к остальным) является ациклический граф импорта модулей. (Сколько модулей, сколько связей между ними,...)
СГ>В разделе про КОП явно бы написал, что КОП появилось в следствии объединения ООП и Модульного программирования. Компонент — это модуль внутри которого определены взаимозависимые друг от друга типы. Соответсвенно, в КОП есть ациклический граф импорта компонентов=модулей и граф зависимости типов (содержащий циклы). Если типы зависят друг от друга не взаимно, а ациклично, то нет смысла помещать их внутрь одного компонента, лучше сделать несколько компонентов с ациклическим графом импорта.
Что-то я не улавливаю разницы между модулем и компонентом — можно на пальцах?
Здравствуйте, LIS, Вы писали:
LIS>Что-то я не улавливаю разницы между модулем и компонентом — можно на пальцах?
Модули и объекты, вообще говоря, существуют не зависимо друг от друга.
Но если мы хотим использовать и модули и объекты одновременно, то мы должны быть более дисциплинированы чем при использовании этих парадигм по отдельности. В частности, при одновременном их использовании становится обязательным сборщик мусора хотя в обычном ООП без модулей можно обойтись и без него. Компонент = Модуль с взаимно зависящими друг от друга типами объектов. Компонент превращается в обычный модуль (с процедурами) если не используется ООП.
"Плоская" win32 *.dll — модуль, но .NET-товская *.dll — уже не просто модуль, а компонент.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, LIS, Вы писали:
LIS>>Что-то я не улавливаю разницы между модулем и компонентом — можно на пальцах?
СГ>Модули и объекты, вообще говоря, существуют не зависимо друг от друга. СГ>Но если мы хотим использовать и модули и объекты одновременно, то мы должны быть более дисциплинированы чем при использовании этих парадигм по отдельности. В частности, при одновременном их использовании становится обязательным сборщик мусора хотя в обычном ООП без модулей можно обойтись и без него. Компонент = Модуль с взаимно зависящими друг от друга типами объектов. Компонент превращается в обычный модуль (с процедурами) если не используется ООП.
СГ>"Плоская" win32 *.dll — модуль, но .NET-товская *.dll — уже не просто модуль, а компонент.
Понял, но я имею в виду логическое разделение, а Вы больше налегаете на физическую реализацию. Для меня с точки зрения статического анализа исходного кода "плоская" win32 *.dll и .NET-товская *.dll — равнозначные компоненты, просто построенные с использованием разных подходов.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>В частности, при одновременном их использовании становится обязательным сборщик мусора хотя в обычном ООП без модулей можно обойтись и без него.
Да? А как насчет VB6- и ActivX-ов? Али это не компонентное программирование? А ЖЦ там нема. А Дельфи?
СГ>Компонент = Модуль
Откуда ты это взял? Компонент конечно термин перегруженный, но модулем он никогда не являлся. В общепринятом понимании компонент скорее == объект.
СГ> с взаимно зависящими друг от друга типами объектов. Компонент превращается в обычный модуль (с процедурами) если не используется ООП.
Не пудри неокрепшие мозги.
СГ>"Плоская" win32 *.dll — модуль, но .NET-товская *.dll — уже не просто модуль, а компонент.
Здравствуйте, LIS, Вы писали:
LIS>Попытался в общих чертах выделить основные свойства современных парадигм программирования применительно с точки зрения статического анализа исходных кодов программы. Главная цель — определить направления исследования (наконец сел писать диссер — а то все идеи да мысли ). LIS>Зацените, плз, и если можно укажите ошибки/недостатки/упущения (на метрики можно не обращать внимания):
Вопрос: это был изложен план первой главы диссертации или всей диссертации?
К чему я это спрашиваю. На тех немногих защитах и предзащитах, на которых мне довелось побывать, было два коронных вопроса:
1. В чем научная новизна вашей работы?
2. Что в этой работе сделали именно вы?
Так вот, если это был план диссертации, то ответов на эти вопросы в нем не просматривается.
К тому же лично я не понял ни темы диссертации (хотя бы ее названия), ни того, что ты в ней пытаешься защитить. Может быть сначала попробовать эти два пункта озвучить? Тогда, глядишь, и критика будет конструктивнее.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
VD>А как насчет VB6- и ActivX-ов? Али это не компонентное программирование? А ЖЦ там нема. А Дельфи?
Это скорее библиотеки, чем компоненты, по крайней мере в Дельфи. Разница между компонентом и библиотекой состоит в том, что компонент, вообще говоря, можно поменять на другой аналогичный компонент от другого производителя хоть во время работы программы. Библиотеку же поменять на другую аналогичную от другого производителя — это уж как повезет (зачастую требуется перекомпиляция, а быть может даже переписывание чего-нибудь).
СГ>>Компонент = Модуль
VD>Откуда ты это взял? Компонент конечно термин перегруженный, но модулем он никогда не являлся. В общепринятом понимании компонент скорее == объект.
Да термин перегруженный, и в КОП компонент — это модуль. Объект компонентом являться не может, так как у объекта есть собственное состояние, а у компонента собственного состояния нет. Компонент — это скорее фабрика по производству объектов, но и это не совсем верно...
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, LIS, Вы писали:
LIS>>Попытался в общих чертах выделить основные свойства современных парадигм программирования применительно с точки зрения статического анализа исходных кодов программы. Главная цель — определить направления исследования (наконец сел писать диссер — а то все идеи да мысли ). LIS>>Зацените, плз, и если можно укажите ошибки/недостатки/упущения (на метрики можно не обращать внимания):
E>Вопрос: это был изложен план первой главы диссертации или всей диссертации?
E>К чему я это спрашиваю. На тех немногих защитах и предзащитах, на которых мне довелось побывать, было два коронных вопроса:
E>1. В чем научная новизна вашей работы? E>2. Что в этой работе сделали именно вы?
E>Так вот, если это был план диссертации, то ответов на эти вопросы в нем не просматривается.
E>К тому же лично я не понял ни темы диссертации (хотя бы ее названия), ни того, что ты в ней пытаешься защитить. Может быть сначала попробовать эти два пункта озвучить? Тогда, глядишь, и критика будет конструктивнее.
1. Название диссертации "Оптимизация программных средств на уровне анализа исходного кода"
2. Это не план, это просто пока попытка максимально понятно оформить те мысли, что накопились за время изучения этой проблемы.
3. Смысл работы:
— структуризация всей информации по данной теме
— объяснение того, как и где мы можем использовать тот или иной метод анализа
— объяснение того, что мы можем получить с помощью того или иного метода анализа
— и, в идеале, предложить улучшение какого-либо метода или свой собственный.
Основная проблема у меня сейчас в том, что чем больше я читаю литературы, тем больше направлений для исследования у меня появляется:
1. Используя существующие метрики провести оценку нескольких реальных программ с близкой функциональностью, посмотреть какие результаты у нас будут и интерпретировать их — надо писать анализирующую программу
2. Провести сопоставление метрик качества ПО и со стандартами качества ПО (ИСО, СММ) — наброски по этой теме есть, но пока пришлось отложить
3. Провести анализ современных методов программирования и сопоставить им существующие метрики — в планах исследовать связь метрик с парадигмами программирования, с использованием паттернов, посмотреть, что можно взять из теории рефакторинга
4. (?) Провести анализ ЯП с точки зрения анализа характеристик исходных кодов конечных программ
5. Посмотреть, как интегрируются метрики с современными методиками создания программных средств
6. Посмотреть, как вписывается статический анализ исходных кодов в современную теорию тестирования
7. Посмотреть на все вышеописанное, почесать тыковку — и... пойти напится с горя
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, VladD2, Вы писали:
Господа, давай не уходить опять во флейм
Что бы не было лишних поводов для продолжения дисскусии по смысловым значениям слов "модуль" и "компонент" я немного переформулирую постановку задачи:
Компонент = модуль с точки зрения статического анализа его исходного кода по направлениям:
1. Анализа структуры логических объектов, из которых он состоит (под объектами я здесь понимаю процедуры или классы)
2. Анализа потока управления программы внутри компонента (модуля)
3. Анализа потока данных внутри компонента (модуля)
А вот с точки зрения анализа взаимодействия с внешней средой:
процедура -> класс -> модуль -> компонент
т.е. модуль выступает просто как контейнер (в обычном смысле этого слова) объектов предыдущих уровней и, в отличие от компонента, не предъявляет требований к внешней среде.
ЗЫ. Уж больно тонка грань между этими понятиями...
Сергей Губанов wrote:
> VD>А как насчет VB6- и ActivX-ов? Али это не компонентное > программирование? А ЖЦ там нема. А Дельфи? > Это скорее библиотеки, чем компоненты, по крайней мере в Дельфи. > Разница между компонентом и библиотекой состоит в том, что компонент, > вообще говоря, можно поменять на другой аналогичный компонент от > другого производителя хоть во время работы программы.
Так меняйте — VB6 не запрещает это делать. Лишь бы интерфейсы были
совместимы.
Этим, кстати, пользовались — были ActiveXные контролы, которые прозрачно
подменяли стандартные (просто перерегистрировались с тем же CLSID).
Обидно как-то...
Неужели никто не интересовался такой темой, как получение количественных оценок по исходному коду программы? Было пару подобных тем, но во всех их них все сводилось к тому, что это никому не нужно. Странно как-то... ведь программирование вышло из математики, где везде нужны анализ, точный расчет и точные цифры; в программировании же, складывется у меня убеждение, практически все думают, что "просчитать" программу нельзя и любые подобные цифры — никому не нужная трата сил и времени. Пишем программы, используя математический аппарат, а анализировать ее с применением оного — вроде как не получится... Непонятно...
Возьмем наиболее близкую, как мне кажется, отрасль — архитектура и строительство. Любое сооружение, будь то небоскреб, супер-пупер навороченный бизнес-центр или простая хижина, все это тщательнейшим образом просчитывается, архитектор не может прийти и просто сказать — "Это супер, вот посмотрите на чертежи", а остальные скажут "Да, круто, можно строить". Ведь какое-бы ни было строение красивое-раскрасивое, если в нем жить неудобно или оно развалится после первого дождичка — такого архитектора больше никто не наймет. А программирование все происходит именно так — Вася крутой спец, он сказал что программа супер и все будет работать, а когда она начинает выдавать ошибки, Вася говорит — "Это не я, это вот Петя там ошибку сделал", а Петя в говорит — "Мне Федя так сказал" и т.д. И получается — никто не виноват, ничего не работает, и покупателю приходится платить дальше, потому что ему "ехать надо, а не шашечки".
К чему я все это? Да опять к тому же — неужели никто не исследовал эту проблему (я имею в виду тех, кто на этом форуме) и не может поделиться чуток знаниями нарытыми?
ЗЫ. Устал я чего-то — вот и прорвало Похоже так и придется одному дальше копать, следовательно диссертацию нормальную написать не получиться
Здравствуйте, LIS, Вы писали:
LIS>Обидно как-то... LIS>К чему я все это? Да опять к тому же — неужели никто не исследовал эту проблему (я имею в виду тех, кто на этом форуме) и не может поделиться чуток знаниями нарытыми? LIS>ЗЫ. Устал я чего-то — вот и прорвало Похоже так и придется одному дальше копать, следовательно диссертацию нормальную написать не получиться
Хотел тебе подробно ответить, да пока с мыслями не собрался (может после небольшого тайм-аута получится). Но одну вешь скажу тебе сразу: никому кроме тебя твоя диссертация не нужна (если только у твоего руководителя учеников для докторской не хватает). Даже тебе после защиты она уже не будет нужна. Не нужна вне зависимости от темы и личности ее автора. Просто не нужна, т.к. это всего лишь твоя попытка получить ученую степень.
И обсуждать что же ты хочешь сделать и как это должно быть написано в диссертации, тебе нужно не здесь в форуме, а у себя на кафедре с твоим научным руководителем. Вспоминая свой опыт могу сказать, что во всех удачных случаях защиты, про которые я знаю, все подобные стратегичекие вопросы решались именно научным руководителем. Потому что у него достаточно опыта и знаний. А соискатеть начинает более-менее четко ориентироваться в теме только к моменту защиты. Причем только в том, что касается его темы. А руководитель изначально гораздо больше знает еще и про смежные области.
А если ты хочешь получать информацию, то задавай вопросы по другому. Безотносительно к твоей диссертации. Например, хочешь узнать, как количественно измерить и качественно проанализировать компоненто-ориентированное программирование (боже, что за муру я только что написал ) -- так и напиши, мол хочу сделать вот так и так, потому что вот так уже далал и вот это получил, но думаю, что это не правильно. Тогда глядишь, кто-то тебе и подскажет, что знает.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, LIS, Вы писали:
Да это я так, от безысходности...
E>Хотел тебе подробно ответить, да пока с мыслями не собрался (может после небольшого тайм-аута получится). Но одну вешь скажу тебе сразу: никому кроме тебя твоя диссертация не нужна (если только у твоего руководителя учеников для докторской не хватает). Даже тебе после защиты она уже не будет нужна. Не нужна вне зависимости от темы и личности ее автора. Просто не нужна, т.к. это всего лишь твоя попытка получить ученую степень.
Не совсем — это еще и попытка сделать хоть что-то стоящее...
E>И обсуждать что же ты хочешь сделать и как это должно быть написано в диссертации, тебе нужно не здесь в форуме, а у себя на кафедре с твоим научным руководителем. Вспоминая свой опыт могу сказать, что во всех удачных случаях защиты, про которые я знаю, все подобные стратегичекие вопросы решались именно научным руководителем. Потому что у него достаточно опыта и знаний. А соискатеть начинает более-менее четко ориентироваться в теме только к моменту защиты. Причем только в том, что касается его темы. А руководитель изначально гораздо больше знает еще и про смежные области.
К сожалению, мой научник совсем не силен в этой теме, так что он может только говорить, что подойдет для диссера, а что не надо туда пихать, а вот про правильность суждений остается по большей части мне размышлять. Т.е. я имею в виду, что он руководит написанием хорошо, но не может достоверно сказать, что я пришел к правильным выводам, и я вот и волнуюсь, что бы не получилось, что я пришел к какому либо заключению, а мне сказали на защите, что оно неправильные, и "вы вообще неправильно этот вопрос поняли".
E>А если ты хочешь получать информацию, то задавай вопросы по другому. Безотносительно к твоей диссертации. Например, хочешь узнать, как количественно измерить и качественно проанализировать компоненто-ориентированное программирование (боже, что за муру я только что написал ) -- так и напиши, мол хочу сделать вот так и так, потому что вот так уже далал и вот это получил, но думаю, что это не правильно. Тогда глядишь, кто-то тебе и подскажет, что знает.
Так я вроде и не налегал на то, что это вопрос по диссертации — я просто отметил почему возник такой вопрос... И вопрос у меня по-моему был конкретный — правильно я думаю или нет, ответов — только СГ и Влад2 опять поспорили чуток по любимой теме и все... У меня вообще складывается впечатление, что этот форум (ФП) — теже СВ, только сбоку: или обсуждение любого вопроса неизменно переходит в мерялку сами знаете чего, или оно глохнет после пары реплик...
ЗЫ. Я не обижаюсь и ни на что особо не рассчитываю, просто на все вопросы, которые я здесь пытался задать, я получал максимум 3 нормальных ответа + 5-6 реплик...
Здравствуйте, LIS, Вы писали:
E>>Хотел тебе подробно ответить, да пока с мыслями не собрался (может после небольшого тайм-аута получится). Но одну вешь скажу тебе сразу: никому кроме тебя твоя диссертация не нужна (если только у твоего руководителя учеников для докторской не хватает). Даже тебе после защиты она уже не будет нужна. Не нужна вне зависимости от темы и личности ее автора. Просто не нужна, т.к. это всего лишь твоя попытка получить ученую степень.
LIS>Не совсем — это еще и попытка сделать хоть что-то стоящее...
Мне кажется, что чем раньше ты поймешь, что что-то стоящее и защищенная защита -- это разные вещи, тем лучше.
Я в свое время оказался почти в такой же ситуации, как ты описал. И остался без степени. Как раз потому, что не понял, что производство чего-нибудь -- это одно. А защита диссертации -- это совсем другое.
LIS>К сожалению, мой научник совсем не силен в этой теме, так что он может только говорить, что подойдет для диссера, а что не надо туда пихать, а вот про правильность суждений остается по большей части мне размышлять. Т.е. я имею в виду, что он руководит написанием хорошо, но не может достоверно сказать, что я пришел к правильным выводам, и я вот и волнуюсь, что бы не получилось, что я пришел к какому либо заключению, а мне сказали на защите, что оно неправильные, и "вы вообще неправильно этот вопрос поняли".
Думаю, что если процесс написания и выхода на защиту будет построен правильно, то об ошибочности выбора ты узнаешь довольно быстро. После пары-другой докладов на конференциях и встреч с потенциальными оппонентами. К тому же, если твой научник не сильно в теме, то есть вероятность, что и остальные члены коммисии будут в таком же положении
LIS>Так я вроде и не налегал на то, что это вопрос по диссертации — я просто отметил почему возник такой вопрос... И вопрос у меня по-моему был конкретный — правильно я думаю или нет,
Как раз этого я не заметил. Мне показалось, что ты изложил план первой главы диссера и спрашиваешь, хороший ли он получился.
LIS>У меня вообще складывается впечатление, что этот форум (ФП) — теже СВ, только сбоку: или обсуждение любого вопроса неизменно переходит в мерялку сами знаете чего, или оно глохнет после пары реплик...
Мне кажется, что большинство форумов такие. Природа, так сказать, обязывает
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Это скорее библиотеки, чем компоненты, по крайней мере в Дельфи.
Не. Это просто ты придумал себе терминалогию и пыташся навязать ее большинству которое уже привыкла к другой (надо признать более логичной).
СГ>Разница между компонентом и библиотекой состоит в том, что компонент, вообще говоря, можно поменять на другой аналогичный компонент от другого производителя хоть во время работы программы.
Этому условию ActivX отвечают даже лучше вем объекты Явы или дотнета.
СГ> Библиотеку же поменять на другую аналогичную от другого производителя — это уж как повезет (зачастую требуется перекомпиляция, а быть может даже переписывание чего-нибудь).
У тебя каша в голове. Библиотека — это модуль хранящий в себе код. Код можт быть организован в компоненты, а может и не быть. И нечего выдумывать.
СГ>Да термин перегруженный, и в КОП компонент — это модуль.
Не выдумывай.
СГ> Объект компонентом являться не может, так как у объекта есть собственное состояние, а у компонента собственного состояния нет.
СГ>Component-Oriented Programming
СГ>A Refined Variation on Object-Oriented Programming
СГ>[The Oberon Tribune, Vol 1, No 2, December 1995]
СГ>Prof. Clemens Szyperski, School of Computing Science, Queensland University of Technology, Brisbane, Australia
In 1993, Microsoft released OLE 2, and created COM as the underlying object model for OLE 2. While OLE 1 was focused on compound documents, COM and OLE 2 were designed to address software components in general. In 1994 OLE controls (OCX) were introduced as the successor to VBX controls. At the same time, Microsoft stated that OLE 2 would just be known as "OLE", and that OLE was no longer an acronym, but a name for all of the company's component technologies.
Тебе не кажется смешным ссылаться на источники появившиеся после того как тот же МС уже реализовала компонентный фрэймворк?
Кстати, ты сам то свою ссылку читал? Там есть замечательные слова:
The combination of some aspects of object-oriented programming, safety, and modularity with extensibility as a goal is called Component-Oriented Programming.
То есть ООП как бы подразумевается как базис.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, LIS, Вы писали:
LIS>Компонент = модуль с точки зрения статического анализа его исходного кода по направлениям:
Не может быть компонет "с точки зрения". Или мы о КООП и тогда компонент имеет конкретный смысл. Или вообще не ясно о чем мы говорим.
LIS>1. Анализа структуры логических объектов, из которых он состоит (под объектами я здесь понимаю процедуры или классы) LIS>2. Анализа потока управления программы внутри компонента (модуля) LIS>3. Анализа потока данных внутри компонента (модуля)
Нельзя рассматриватьв все эти аспекты в рамках модуля.
LIS>А вот с точки зрения анализа взаимодействия с внешней средой:
LIS>процедура -> класс -> модуль -> компонент
Это вообще чушь. В КООП "класс" == "компонент". Таким образом модуль содержит классы которые могут являться компонентом. Классы же содержат методы.
LIS>т.е. модуль выступает просто как контейнер
В твоей схеме модуль идет между классом и компонентом. Так чему он по-твоему является контейнером.
LIS>ЗЫ. Уж больно тонка грань между этими понятиями...
Здравствуйте, eao197, Вы писали:
E>Мне кажется, что чем раньше ты поймешь, что что-то стоящее и защищенная защита -- это разные вещи, тем лучше.
E>Я в свое время оказался почти в такой же ситуации, как ты описал. И остался без степени. Как раз потому, что не понял, что производство чего-нибудь -- это одно. А защита диссертации -- это совсем другое.
Ну вот — только захотел сделать все по правильному, как говорят, что неправильно делаю
E>Думаю, что если процесс написания и выхода на защиту будет построен правильно, то об ошибочности выбора ты узнаешь довольно быстро. После пары-другой докладов на конференциях и встреч с потенциальными оппонентами. К тому же, если твой научник не сильно в теме, то есть вероятность, что и остальные члены коммисии будут в таком же положении
Так в том-то и дело, что не успеваю я на эти конференции-доклады Вот и спрашиваю здесь, чтобы хоть какое-то мнение получить.
).
Похоже так и придется одному дальше копать, следовательно диссертацию нормальную написать не получиться 
) -- так и напиши, мол хочу сделать вот так и так, потому что вот так уже далал и вот это получил, но думаю, что это не правильно. Тогда глядишь, кто-то тебе и подскажет, что знает.