Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
ИМХО важно не только формировать цели списочным образом, но и указывать как они между собой взаимосвязаны, в частности, если одни подчинены другим. До сих пор как-то механизмы такой увязки не обсуждались, обычно увязка получалась через функциональную декомпозицию (типа у головной функции есть цель, а у подфункции - подцели и иерархия целей-задач увзывается через структуру функций). Но Якобсон (в книге Aspect oriented programming) указал, что так можно поступать не всегда: есть цели которые могут реализоваться функциями, уже подчиненными другим целям. Т.е. важен не только список целей и задач, но и как они взимосвязаны.А чем Вам IDEF0 в этом случае не средство указания взаимосвязи целей?
подскажите, пожалуйста, где можно взять тесты для выявления аналитических способностей (самые простенькие)Понимаете, мы и сами хотели бы это знать
. Почитайте внимательно всю ветку рассуждений - сами увидите!Но вообще, прежде чем переходить на другой хостинг, я бы хотел, чтобы были максимально чётко озвучены причины. Т.к. всё что есть сейчас - это какая-то невнятица. И если выяснится, что проблемы у движков, то будет глупо.Денис, ты не спрашивай, а ты изучи проблему. Правами наделен! Некогда? Ну тогда, что ж поделаешь, приходится использовать то, что есть.
Принцип действия
Типовое решение модель-представление—контроллер подразумевает выделение трех отдельных ролей. Модель— это объект, предоставляющий некоторую информацию о домене. У модели нет визуального интерфейса, она содержит в себе все данные и поведе¬ние, не связанные с пользовательским интерфейсом. В объектно-ориентированном кон¬тексте наиболее "чистой" формой модели является объект модели предметной области (Domain Model, 140). В качестве модели можно рассматривать и сценарий транзакции (Transaction Script, 133), если он не содержит в себе никакой логики, связанной с пользо¬вательским интерфейсом. Подобное определение не очень расширяет понятие модели, однако полностью соответствует распределению ролей в рассматриваемом типовом ре¬шении.
Представление отображает содержимое модели средствами графического интерфейса. Таким образом, если наша модель — это объект покупателя, соответствующее представ¬ление может быть фреймом с кучей элементов управления или HTML-страницей, запол¬ненной информацией о покупателе. Функции представления заключаются только в ото¬бражении информации на экране. Все изменения информации обрабатываются третьим "участником" нашей системы — контроллером. Контроллер получает входные данные от пользователя, выполняет операции над моделью и указывает представлению на необхо¬димость соответствующего обновления. В этом плане графический интерфейс можно рассматривать как совокупность представления и контроллера.
Говоря о типовом решении модель—представление—контроллер, нельзя не подчеркнуть два принципиальных типа разделения: отделение представления от модели и отделение контроллера от представления.
Отделение представления от модели — это один из фундаментальных принципов про¬ектирования программного обеспечения. Наличие подобного разделения весьма важно по ряду причин.
• Представление и модель относятся к совершенно разным сферам программирова¬
ния. Разрабатывая представление, вы думаете о механизмах пользовательского ин¬
терфейса и о том, как сделать интерфейс приложения максимально удобным для
пользователя. В свою очередь, при работе с моделью ваше внимание сосредоточе¬
но на бизнес-политиках и, возможно, на взаимодействии с базой данных. Очевид¬
но, при разработке модели и представления применяются разные (совершенно
разные!) библиотеки. Кроме того, большинство разработчиков специализируются
только в одной из этих областей.
• Пользователи хотят, чтобы, в зависимости от ситуации, одна и та же информация
могла быть отображена разными способами. Отделение представления от модели
позволяет разработать для одного и того же кода модели несколько представлений,
а точнее, несколько абсолютно разных интерфейсов. Наиболее наглядно данный
подход проявляется в том случае, когда одна и та же модель может быть представ¬
лена с помощью толстого клиента, Web-обозревателя, удаленного API или интер¬
фейса командной строки. Даже в пределах одного и того же Web-интерфейса в
разных местах приложения одному и тому же покупателю могут соответствовать
разные страницы.
• Объекты, не имеющие визуального интерфейса, гораздо легче тестировать, чем объекты с интерфейсом. Отделение представления от модели позволяет легко про¬тестировать всю логику домена, не прибегая к таким "ужасным" вещам, как сред¬ства написания сценариев для поддержки графического интерфейса пользователя.
Ключевым моментом в отделении представления от модели является направление зависимостей: представление зависит от модели, но модель не зависит от представления. Программисты, занимающиеся разработкой модели, вообще не должны быть осведомле¬ны о том, какое представление будет использоваться. Это существенно облегчает разра¬ботку модели и одновременно упрощает последующее добавление новых представлений. Кроме того, это означает, что изменение представления не требует изменения модели.
Данный принцип тесно связан с распространенной проблемой. При использовании толстого клиента с множеством диалоговых окон на экране могут одновременно нахо¬диться несколько представлений одной и той же модели. Если пользователь внесет из¬менения в модель посредством одного представления, эти изменения должны быть от¬ражены и во всех остальных представлениях. Чтобы это было возможным при отсутствии двунаправленной зависимости, необходимо реализовать типовое решение наблюдатель (Observer) [20] с использованием метода распространения событий (event propagation) или в виде типового решения слушатель (Listener). В этом случае представление будет выполнять роль "наблюдателя" за моделью: как только модель будет изменена, представ¬ление генерирует соответствующее событие и все остальные представления обновляют свое содержимое.
Отделение контроллера от представления не играет такой важной роли, как предыду¬щий тип разделения. Действительно, по иронии судьбы практически во всех версиях Smalltalk разделение на контроллер и представление не проводилось. Классическим при¬мером необходимости подобного разделения является поддержка редактируемого и не-редактируемого поведения. Этого можно достичь при наличии одного представления и двух контроллеров (для двух вариантов использования), где контроллеры являются стра¬тегиями [20], используемыми представлением. Между тем на практике в большинстве систем каждому представлению соответствует только один контроллер, поэтому разделе¬ние между ними не проводится. О данном решении вспомнили только при появлении Web-интерфейсов, где отделение контроллера от представления оказалось чрезвычайно полезным.
Тот факт, что в большинстве инфраструктур пользовательских интерфейсов не про¬водилось разделение на представление и контроллер, привел к множеству неверных тол¬кований типового решения модель-представление—контроллер. Да, наличие модели и представления очевидно, но где же контроллер? Многие решили, что контроллер нахо¬дится между моделью и представлением, как в контроллере приложения (Application Controller, 397). Данное заблуждение еще более усугубил тот факт, что в обоих названиях фигурирует слово "контроллер". Между тем, несмотря на все положительные качества контроллера приложения, он ничем не похож на контроллер типового решения модель-представление—контроллер.
Описанные принципы — это все, что требуется для понимания данного набора типо¬вых решений. Если же вам захочется еще немного покопаться в типовом решении мо¬дель-представление—контроллер, обратитесь к источнику [33] — там содержится лучшее на данный момент описание этого типового решения.
Назначение
Как уже отмечалось, ценность типового решения модель—представление—контроллер
заключается в наличии двух типов разделения. Отделение представления от модели — один из основополагающих принципов, на котором держится все проектирование про¬граммного обеспечения, и пренебрегать им можно только тогда, когда речь идет о совсем простых системах, в которых модель вообще не имеет какого-либо реального поведения. Как только в приложении появляется невизуализированная логика, разделение стано¬вится крайне необходимым. К сожалению, во многих инфраструктурах пользовательских интерфейсов реализовать подобное разделение довольно сложно, а там, где это неслож¬но, о нем все равно забывают.
Отделение представления от контроллера не так важно, поэтому рекомендую прово¬дить его только в том случае, когда оно действительно нужно. Подобная необходимость практически не возникает в системах с толстыми клиентами, а вот в Web-интерфейсах отделение контроллера весьма полезно. Большинство рассматриваемых здесь типовых решений, предназначенных для проектирования Web-приложений, основаны именно на этом принципе.
Это вроде бы не особо большая проблемаНашел гуру. Вообще переход на новый форум не сложен. Проблема интеграции с joomla. Потому интересно, а нужна нам эта интеграция на самом деле?
Ну это только тебе по силам как гуру SMF на нашем сайте
Сделаем, поговрить - это мы всегда за
