UML (отображаемый в сквозную базу знаний) позволяет мне лично не "тупить глядя в монитор" (http://18delphi.blogspot.com/2013/08/blog-post_2315.html), а быстро входить в состояние "потока" для решения типовых задач.
Примерно в таком ключе:
Пусть мы собрали некоторое количество требований и нарисовали некоторое количество прецедентов.
И пусть мы определились, что проектируемое приложение должно быть (по Layout'у) похоже на MSWord.
Тогда мы делаем примерно следующее:
Открываем базу знаний.
Вводим поисковый запрос "WordLike" или "OfficeLike".
Находим КЛАСС TWordLikeApplication видим, что он "абстрактный" (т.е. требует наследования и доопределения) и что он со стереотипом <<VCMApplication>>. Смотрим КТО от него наследуется. Может быть находим эти проекты и запускаем их. Чтобы убедиться, что это то, что нам нужно.
Ищем в базе знаний <<VCMApplication>>.
Находим этот стереотип. Понимаем, что он может быть вложен в <<VCMGUI>>, а тот в свою очередь в <<VCMProject>>.
Создаём <<VCMProject>> -> <<VCMGUI>> -> <<VCMApplication>>. Наследуем его от TWordLikeApplication.
Генерируем кода. Генератор генерирует "скелет приложения" и доопределяет абстрактные методы с указанием "вот тут напиши код". Определяем эти методы (в ДОКУМЕНТАЦИИ к ним "обычно" написано - что требуется от этого метода, если не написано, то бьём меня по голове и получаем нормальную документацию). Получаем ПУСТОЕ приложение. С УЖЕ определённой функциональностью.
Далее "вспоминаем", что у нас есть прецеденты.
Ищем по базе знаний стереотип <<UseCase>>. Который собственно у нас уже нарисован в требованиях.
Понимаем, что он может быть РЕАЛИЗОВАН стереотипом <<UseCaseRealization>>.
Смотрим ГДЕ может быть определён стереотип <<UseCaseRealization>>.
Получаем цепочку <<VCMUseCases>> -> <<VCMUseCaseRealization>>.
Рисуем эту цепочку. Получаем "скелет прецедента". С необходимостью доопределить методы. Если что-то непонятно - опять же - "бьём меня по голове" и получаем нормальную документацию.
Связываем <<VCMAppliaction>> с <<VCMUseCaseRealization>> связью реализации.
Получаем что наше приложение умеет реализовывать данный прецедент.
Учитывая тот факт, что <<VCMUseCaseRealization>> это ЕДИНСТВЕННОЕ место, где мы можем создавать экземпляры стереотипа <<VCMForm>> - мы с лёгкостью находим место, где мы можем создавать проектные формы с правильной инфраструктурой.
А в формах можно определять <<VCMOperation>>, которые собственно и служат "связующим звеном к пользователю".
Вкратце - как-то так.
P.S. Это я расписал для "стереотипов верхнего уровня", но примерно так же и работает для более "глубоких" проектных стереотипов типа "контейнеров".
Примерно в таком ключе:
Пусть мы собрали некоторое количество требований и нарисовали некоторое количество прецедентов.
И пусть мы определились, что проектируемое приложение должно быть (по Layout'у) похоже на MSWord.
Тогда мы делаем примерно следующее:
Открываем базу знаний.
Вводим поисковый запрос "WordLike" или "OfficeLike".
Находим КЛАСС TWordLikeApplication видим, что он "абстрактный" (т.е. требует наследования и доопределения) и что он со стереотипом <<VCMApplication>>. Смотрим КТО от него наследуется. Может быть находим эти проекты и запускаем их. Чтобы убедиться, что это то, что нам нужно.
Ищем в базе знаний <<VCMApplication>>.
Находим этот стереотип. Понимаем, что он может быть вложен в <<VCMGUI>>, а тот в свою очередь в <<VCMProject>>.
Создаём <<VCMProject>> -> <<VCMGUI>> -> <<VCMApplication>>. Наследуем его от TWordLikeApplication.
Генерируем кода. Генератор генерирует "скелет приложения" и доопределяет абстрактные методы с указанием "вот тут напиши код". Определяем эти методы (в ДОКУМЕНТАЦИИ к ним "обычно" написано - что требуется от этого метода, если не написано, то бьём меня по голове и получаем нормальную документацию). Получаем ПУСТОЕ приложение. С УЖЕ определённой функциональностью.
Далее "вспоминаем", что у нас есть прецеденты.
Ищем по базе знаний стереотип <<UseCase>>. Который собственно у нас уже нарисован в требованиях.
Понимаем, что он может быть РЕАЛИЗОВАН стереотипом <<UseCaseRealization>>.
Смотрим ГДЕ может быть определён стереотип <<UseCaseRealization>>.
Получаем цепочку <<VCMUseCases>> -> <<VCMUseCaseRealization>>.
Рисуем эту цепочку. Получаем "скелет прецедента". С необходимостью доопределить методы. Если что-то непонятно - опять же - "бьём меня по голове" и получаем нормальную документацию.
Связываем <<VCMAppliaction>> с <<VCMUseCaseRealization>> связью реализации.
Получаем что наше приложение умеет реализовывать данный прецедент.
Учитывая тот факт, что <<VCMUseCaseRealization>> это ЕДИНСТВЕННОЕ место, где мы можем создавать экземпляры стереотипа <<VCMForm>> - мы с лёгкостью находим место, где мы можем создавать проектные формы с правильной инфраструктурой.
А в формах можно определять <<VCMOperation>>, которые собственно и служат "связующим звеном к пользователю".
Вкратце - как-то так.
P.S. Это я расписал для "стереотипов верхнего уровня", но примерно так же и работает для более "глубоких" проектных стереотипов типа "контейнеров".
Комментариев нет:
Отправить комментарий