понедельник, 26 августа 2013 г.

UML позволяет мне лично не "тупить глядя в монитор", а быстро входить в состояние "потока" для решения типовых задач

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. Это я расписал для "стереотипов верхнего уровня", но примерно так же и работает для более "глубоких" проектных стереотипов типа "контейнеров".

Комментариев нет:

Отправить комментарий