1. Этот сайт использует файлы cookie. Продолжая пользоваться данным сайтом, Вы соглашаетесь на использование нами Ваших файлов cookie. Узнать больше.

АОП

Тема в разделе "Программирование", создана пользователем HorstWessel, 15.05.05.

  1. HorstWessel

    HorstWessel Активный участник

    1.585
    0
    Аспектно-ориентированное программирование (АОП) представляет собой одну из концепций программирования, которая является дальнейшим развитием процедурного и объектно-ориентированного программирования (ООП). Данная методология призвана снизить время, стоимость и сложность разработки современного ПО, в котором, как привило, можно выделить определенные части, или аспекты, отвечающие за ту или иную функциональность, реализация которой рассредоточена по коду программы, но состоит из схожих кусков кода.

    У кого-нибудь уже есть опыт использования АОП. Делитесь.
     
  2. AlTk

    AlTk Читатель

    10.699
    0
    огласите нотацию для создания диаграмм и средство для реализации которые Вы используете.
     
  3. HorstWessel

    HorstWessel Активный участник

    1.585
    0
    Отождествите аспект с вариантом использования. А средства реализации имеют принципиальное значения? AspectJ
     
  4. AlTk

    AlTk Читатель

    10.699
    0
    "Отождествите аспект с вариантом использования."
    это один множества вариантов перекладывания аспектов на диаграммы UML. однако к согласию относительно UML так и не пришли, а другого средства визуализации пока не придумали.

    "А средства реализации имеют принципиальное значения?"
    мне кажется, если мы говорим о структурном и процедурном программировании, то должны быть средства реализации этого, например процедурные языки программирвоания. если говорим про объекты, то тоже самое.
    ну и АОП в том же духе.

    ПС. я думаю, что предметный разговор не получится, так ни у кого нет ни мало-мальски какого-либо опыта в использовании АОП, отсутсвует язык моделирования, да и средство реализации всего одно.
     
  5. HorstWessel

    HorstWessel Активный участник

    1.585
    0

    Это я назвал одну из реализаций. У микрософта, на сколько знаю, то же есть что-то похожее поверх dcom (хотя не буду на этом настаивать).


    Не понял, если



    А Вы у Винера поищите
     
  6. AlTk

    AlTk Читатель

    10.699
    0
    HorstWessel,
    "похожее поверх dcom"
    вот это мне кажется несколько мимо кассы.

    "Не понял, если"
    а что тут непонятного.
    на вопрос что мне можно использовать для моделирования схемы БД я могу ответить IDEF1X, IE, и т.д;
    для функционального моделирования систем - IDEF0;
    для объектного моделирования - UML, Шлеер-Меллора и т.д.
    то на вопрос, что мне использовать для аспектного моделирования до сих пор нет ответа, ну, если хотите, стандарта.

    "А Вы у Винера поищите"
    это Ваше высказывание непонятно.
     
  7. HorstWessel

    HorstWessel Активный участник

    1.585
    0

    Да нет.
    В процессе разработки сложных систем на DCOM программисты решают две задачи: создают компоненты сущности и компоненты-сервисы, в которые вовлечены компоненты сущности. И если код компонентов сущности хорошо "локализован", отлично просматривается и готов для повторного использования, то фрагменты кода компонентов-сервисов оказывается распределеными по всей системе дублируя друг-друга. Это приводит к проблеме запутанности кода (code tangling).
    В рамках АОП утверждается, что никакая технология проектирования не поможет решить данную проблему, если только мы будем оставаться в рамках языка, ориентированного только на разработку компонентов. Для программирования сервисов, обеспечивающих взаимодействие объектов, нужны специальные средства, возможно специальные языки.
    Согласно парадигме АОП после этапа кодирования компонентов и аспектов на соответствующих языках выполняется автоматическое построение оптимизированного для выполнения (но не для просмотра и модификации) кода. Этот финальный процесс называется слиянием ( weaving ).


    И я не пойму что тут непонятного. Используйте UML, а стандарты подтянутся.
     
  8. AlTk

    AlTk Читатель

    10.699
    0
    я еще раз повторю. мимо кассы. не путайте понятия!
    DCOM - это распределенная модель объектов,
    реализовать DCOM можно на ассемблере, си, паскале, си++, объектном паскале и т.д.
    DCOM - это не язык и не средство реализации.
    а то, что Вы слышали это рекламный слоган, о том, что объекты СОМ+ имеют теперь декларативные атрибуты, куда перемещены независимые от логики приложения аспекты.

    "И я не пойму что тут непонятного. Используйте UML, а стандарты подтянутся."
    с таким подходом схему БД можно в Word рисовать, причем каждый по-своему. ;)
    еще раз повторю, UML - для объектов, АОП - почти ортогонально ООП, что тогда значат Ваши слова использовать UML?

    ПС . а реализаций, кстати, поболе наберется - пару десятков точно будет.
     
  9. HorstWessel

    HorstWessel Активный участник

    1.585
    0
    Я Вам еще раз повторю. Не путайте понятия:


    Что касается Ваших тезисов относительно DCOM, я с вами согласен и поэтому написал: "...после этапа кодирования компонентов и аспектов на соответствующих языках выполняется...". И не о декларативных атрибутах я вел речь.

    А в отношении моделирования баз данных в Word, я бы так и сделал.;) И всем без исключения было бы понятно что это. А знаете почему? Потому что у меня в базе данных никогда нет ничего кроме таблиц и внешних ключей. Более того я вообще никогда не создаю их сам. За меня это делает сервер приложений. Я создаю компоненты-сущности (для моделирования иногда использую UML) и декларирую их отношения - один ко многим и др. У сервера приложений есть все необходимые службы для управления этими компонентами и мне нет дела как они храняться в базе данных и что это вообще такое.
    Проблемы возникают на следующем шаге - программировании компонентов сервисов. Вот тут-то аспекты и появляются.

    Для DCOM будет то же самое.
     
  10. AlTk

    AlTk Читатель

    10.699
    0
    а какие понятия я спутал?
     
  11. HorstWessel

    HorstWessel Активный участник

    1.585
    0
    перечитайте мой первый пост.
     
  12. AlTk

    AlTk Читатель

    10.699
    0
    перечитал.
    все равно не понял какие понятия я спутал.
     
  13. HorstWessel

    HorstWessel Активный участник

    1.585
    0
    Ну что ж, читаем сначала и вместе: "ПО, в котором, как привило, можно выделить определенные части, или аспекты, отвечающие за ту или иную функциональность, реализация которой рассредоточена по коду программы, но состоит из схожих кусков кода"

    У Вас: "атрибуты, куда перемещены независимые от логики приложения аспекты".

    Я выделил слово "атрибуты" потому что, как я уже писал, реализация объектов-сущностей не вызывает никаких трудностей. У сущности есть атрибуты, они могут изменяться и для их реализации достаточно парадигмы ООП. Код объектов-сущностей идеален с точки зрения ООП. Но проблема в том, что хотя компоненты сущности и могут изменять свои атрибуты, они (сущности) ничего не знают о контексте, в котором эти изменения происходят. Это уже зависит от логики приложения. То есть, помимо сущностей, необходима реализация еще и действий, или сервисов. На практике же получается, что логически разные действия очень часто используют одни и те же фрагменты кода. Это не редко приводит к запутанности.

    Теперь главное, аспекты в принципе не применимы к атрибутам, но применимы к действиям над атрибутами.
     
  14. AlTk

    AlTk Читатель

    10.699
    0
    в терминах СОМ+ атрибуты - это именно то, о чем вы говорите - "функциональность, рассредоточенная по коду программы, но состоящая из схожих кусков кода".
    однако связь атрибутов в СОМ+ и АОП - это не более чем рекламный слоган.
    так что ДСОМ здесь ни причем.

    так что я ничего не попутал.
     
  15. HorstWessel

    HorstWessel Активный участник

    1.585
    0

    Че? Тут нет ошибки? А пример привести можете?
     
  16. AlTk

    AlTk Читатель

    10.699
    0
    могу, вот например:
    для COM+ для каждого его метода в его атрибутах можно задать набор ролей, кторые имеют право его вызывать.
    т.е., так как COM+ объект работает в контексте объекта ObjectContext, то проверка происходит не в пользовательском объекте, а, грубо говоря в другом объекте.
    т.е. в коде программы отсутствует код, который выполняют проверку на возможность вызова метода пользователем.
     
  17. HorstWessel

    HorstWessel Активный участник

    1.585
    0
    ну и теперь посмотрите на свой пример:
    вы демонстируете не атрибуты как функциональность..., а службу безопасности, которая управляется атрибутами. Служба безопасности это сервис. Атрибут, сам по себе, не имеет никакого отношения к аспектам в контексте АОП. А вот реализация сервиса безопасности COM+, вполне возможно, использует АОП.

    HorstWessel добавил [date]1116569354[/date]:
    Если, действительно, в реализации COM+, использовались аспекты, то это уже не рекламный слоган. И если Вам известны детали реализации служб COM+, в части где использовались аспекты и что полезного они привнесли, тогда говорте. Или если Вы сами использовади аспекты тогда это интересно. Иначе бестолковая беседа.