Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
...Прекрасно, так значит всё-таки цели предшествует "жажда" - что это такое? По-моему, ничто иное, как потребность. Вот тогда возникает интересный вопрос, почему был выбран именно чай. И тут скорее всего, действительно, ограничения на средство достижения цели были продиктованы интересами.
Попить чаю - это вообще-то не цель. Так как ответить на вопрос каков образ результата удается с натяжкой.
надо было писать: утолить жажду попив чаю.
А почему бы это не делать на страничке перевода или на худой конец в wikipedia.org? Зачем изобретать велосипед?В чём велосипед? Попробуй сам "сделать на страничке перевода" - я на тебя посмотрю) На википедии лежат более-менее готовые, а не рабочие материалы. К тому же на википедии и http://wiktionary.org/ нет словарей на одну страницу, только отдельными статьями на каждое слово + там тебе в любой момент кто угодно его оттюнит в собственную сторону.
Разница между БД и объектно-ориентированым приложением в том, что объект инициализируется кодом и изменение его структуры и поведения воспринимается при перекомпиляции и новом запуске приложения. А тебе, Денис, тут толкуют, что схема данных в БД обременена данными, которые в ней лежат, по этому кроме изменения схемы надо писать скрипты, перекидывающие данные, а информацию, как данные перекладывать принципиально нельзя достать из старой схемы и новой, ну недостаточно ее там.Я напомню, что в большинстве случаев развитие модели БД идёт по конструктивному принципу - т.е. появляются новые объекты, увеличиваются домены данных и т.д. Трансформационные же изменения, описанные в книге по рефакторингу баз данных, в большинстве случаев можно сопроводить автоматическими операциями над данными. В тех редких случаях, когда изменения не тривиальны, можно выполнить их на уровне СУБД и реинтегрировать в модель. Общее правило такое: "частным задачам - частные решения".
Тот процесс, что ты описал для каждой итерации ("и так на каждой итерации") может быть проведен, если каждый раз база разворачивается пустой, но тогда вопрос, куда деваются все накопленные данные?Где написано, что база разворачивается пустой? Давай я себя ещё раз процитирую, если непонятно:
И все же ты так и не показал, как сравнить две модели, а сравнение версий - ключ к версионному контролю.Что помешало тебе посмотреть видеоролики? Как я тебе ещё должен показывать, на пальцах? Тебе лень поставить PD, открыть 2 модели и сделать Compare, Merge? Прикладываю свои картинки.
А из того, что сама модель при компиляции никак не участвует (по твоим словам) вытекает, что это не MDA, то есть приложение, управляемое моделью, а просто генератор шаблонного кода с использованием UML. Но это во-первых не новость, а во-вторых не так уж и ценно.Так, а что такое MDA? Смотрим текст.
MDA Concerns(выделение моё). Я - про прагматичный MDA, который работает.
...
Idealistic: MDA is conceived as a forward engineering approach in which models are transformed into implementation artifacts (e.g. executable code, database schema) in one direction via a fully or partially automated "generation" step. This aligns with OMG's vision that MDA should allow modelling of a problem domain's full complexity in UML (and related standards) with subsequent transformation to a complete (executable) application[7].
This approach does, however, imply that changes to implementation artifacts (e.g. database schema tuning) are not supported. This constitutes a problem in situations where such post-transformation "adapting" of implementation artifacts is seen to be necessary. Evidence that the full MDA approach may be too idealistic for some real world deployments has been seen in the rise of so-called "pragmatic MDA"[8]. Pragmatic MDA blends the literal standards from OMG's MDA with more traditional model driven mechanisms such as round-trip engineering that provides support for adapting implementation artifacts.
Нет курс называется "Представление знаний в ИС"Отличная тема у курса!
Безусловно, цель- научать студента самостоятельно разрабатывать системы с помощью UML. Но видимо вы не знаете, что учить студента разработке систем с нуля - бессмысленная затея. Это все равно,что заставить строить дом человека, который топора и ножовки не разу в руках не держал! Я считаю что сначала лучше научить рубить дрова - т.е. пользоваться инструментом, потом обтесывать бревна - т.е. учить языку UML. А исскуству строить дом учатся всю жизнь и лишь единицы овладевают им в полной мере... Также и в проектировании. К тому же цель образования в вузе в конечном счете скорее не выпуск высококвалифицированных кадров- это нереально, а дать базовые знания студентам, научить их методологии получения знаний. А потом они самостоятельно смогут освоить все что им нужно.Только на днях писал об обратном - что людей в основном учат совершать движения, научают операциям (даже не техникам и не методам!) как карго-культу, без понимания целей, уместности, умения взвешивать, оценивать и ставить задачу.
Просмотрел выборочно пару докладов с конференции ... вот например этот http://www.rit2007.ru/paper_view.html?id=1049 .... "О чем этот доклад? Да ни о чем :-) ..." (с).Юра, комментарии прямо там оставить можно.
Правильно ли я Вас понял, что Вы не считате, что роль оценщика аналитика существенна для результата оценки? Или что "оценщик" аналитика может быть выбран тем же способом, что и "оценщик" программиста и тестировщика?Существенна конечно, роль - работодатель в лице руководителя той или иной оргструкуры. Понятно, что тестовые задания будут готовиться с участием работодателя, но не только им.
Вопрос: кто должен оценивать аналитика? В какой позиции, роли должен находиться тот, кто должен оценивать аналитика?А кто оценивает программиста? Кто оценивает тестировщика?
1. С одной стороны, результаты работы аналитика оцениваются разработчиками (архитектор, программисты), которые должны использовать его результаты в своей работе.
2. С другой стороны последние посты данной темы подразумевают оценку аналитка, аналитками же. Зачем? Для коллективной анлитической работы? Интересно, что проблемы коллективной аналитической работы (не коллективной разработки в целом!) до сих пор не обсуждались.
3. Или подразумевается оценка аналитка со стороны лидера проекта, который стоит и над разработчками и аналитиками?
