4096

MDA / Re: Новое начало MDA в России

« : 17 Июня 2008, 15:42:25 »

SaTim, Про ЮМЛ редактор можете рассказать поподробнее, только не в это теме ...

Саша, это пока концепция, но мы говорим с SaTim пока об интегрированном редакторе UML, который более строго заточен под билдер. Просто модель нуждается в болдификации. В приницпе болдифицировать можно любую модель, я так полагаю, что если приложение будет иметь успех, то создателей таких трансформаторов будет предостаточно

4097

MDA / Re: Начало

« : 17 Июня 2008, 13:02:12 »

От себя добавлю, что некоторые выжимки и быстрое погружение в версию МДА от BoldSoft можно совершить здесь.

Кроме компонентов BOLD для Delphi сущестует и ECO уже IV версии, но для C#, если я не ошибаюсь.

В настоящее время ведется активная и стремительная работа по дальнейшему развитию идей MDA в реальном воплощении. Почти создан специальный конструктор приложений на базе MDA, а также UML редактор для создания диаграмм классов. Девиз конструктора - Модель все - приложению 10 минут! От проектировщика в этом случае в первую очередь будет нужны отличные знания по созданию диаграммы классов и языка OCL. Никаких других языков программирования в принципе не потребуется, хотя будет возможность создания некоторой особой функциональности посредством скриптовых паскалеподобных языков.

Проект развивается и о его новостях можно будет узнавать на сайте www.fast-base.ru

4098

Обучение / Re: Обучение SPARX EA

« : 17 Июня 2008, 12:29:05 »

Про курсы не слышал. В частности я с коллегой буду проводить нечто вроде мастер-класса по ЕА на Taining labs.
Кроме того можно поговорить лично

4099

Управление Проектом / Re: Народ! Я изобрел проектное управление...

« : 17 Июня 2008, 11:49:57 »

Почитаем. Кто меня окружает - сплошные какие-то уникумы и изобретатели

4100

Примеры / Re: UML диаграммы. Оболочка для БД с включением некоторых математических функций

« : 16 Июня 2008, 19:36:37 »

Я думаю, Юра просто ошибся про отглагольные существительные, он видимо полагал использовать неопеределенную форму глагола, причем совершенную форму. Что сделать! Т.е. что должна сделать система по мнению пользователя.

У Лармана даются рекомендации по выбору ВИ:
одобрение руководства - нормально ли то, что будет пользователь делать в течение времени рабочего
элементарный бизнес-процесс - т.е. функциональная обязанность сотрудника
критерий размера - если мало шагов - то скорее всего это подфункция по Коберну.

Исключением будут ВИ типа Войти в систему важные для организации доступа настройки и т.п.

Однако я бы не стал слишком упираться во все тонкости, навык придет с опытом. В данном случае просто нужно понимать это и идти к цели - семимильными шагами.

По сути ведь есть и разные уровни представления ВИ. Если Gutti, уже имеет программу и делает скажем так обратное проектирование, то можно просто на это посмотреть с точки зрения общего меню программы.

Хотя в данном конкретном случае как мне кажется было бы поще использовать традиционные списки требований

4101

Примеры / Re: UML диаграммы. Помогите, пожалуйста, построить.

« : 16 Июня 2008, 15:46:30 »

Gutti, вообще конечно тут есть множество проблем в понимании вариантов использования, но думаю особо упираться не будем - написали что написали вроде выглядет не плохо.

Насчет MVC - есть вариант использование - это не овальчик с мальчиком - а полнотекстовое описание сценария(иев) того как выполняется данное использование, как достигается или не достигается цель пользователя. Отсюда и танцуем, в описании ВИ вы придумываете (описываетет) порядок того, что должно быть сделано пользователем и системой (обычно в виде черного ящика) для удовлетворения этой самой цели.
Затем вы выполняете так называемую реализацию варианта использования, т.е. описываете какими классами и как будет достигаться эта самая функциональность, тут очень удобно предстваить вариант использования в виде системной диаграммы последовательности: пользователь - система (как черный ящик) и сообщения от пользователя к системем и наоборот согласно описанному сценарию: там будет видно КАКИЕ системные события и соответственно системные операции требуется реализовать, так вот MVC вам и поможет это представить.

Возьмем Контроль учетных записей. Видим пользователя видим ВИ. Предположим Вы будете делать MDI интерфейс. Значит как минимум в вашем ВИ будет две формы - главная и форма учетных записей,  хотя я бы например добавил журнала учетных записей, да и вообще контроль - плохо, лучше управление или ведение.

Далее обозначаем управляющий класс  -это логика - возможно управляющего класса не буедт, а его функциоанл будет повешен на события формы.

Ну и далее иждут классы-сущности связанные с понятием учетных записей: Учетная запись, Пользователь, Права доступа, и т.п.

4102

Примеры / Re: UML диаграммы. Помогите, пожалуйста, построить.

« : 15 Июня 2008, 23:45:26 »

1. Некоректно используется связь обощение. Слеудет использовать связь коммуникации - простая ассоциация - можно направленная.
2. Работа с базой данных - не может быть целью пользователя, а есть способ реализации достижения цели. Что конкретно делает оператор, далее Вы расписываете как связь включения как я понимаю поскольку иначе стрелки должны быть направлены в обратную сторону
3. Отображения данных в графическом виде - это функция системы, а не вариант использования системы.

Вариант использование - это то, что хочет получить оператор или системный администратор, потому он не хочет отобразить в графическом виде - а посмотреть некоторую отчетность или что-то иное

4. Ведение логов тоже функция системы а не цель пользователя, насколько я понимаю это будет происходить автоматически

5. Насчет диаграммы классов, какая нужна? классов предметной области, классов программы?
Если первое назовите классы единствтенным числом - и преобразуйет БД в ДК предметной области

6. Если Вам нужны еще и классы программы, для каждого ВИ составьте по шаблону MVC диаграмму коммуникации или просто аналитическую модель VOPC (view only participiant classes) добавляя на каждый ВИ минимум одну форму и один контроллер по имени ВИ с суффиксом Manager Controller Handler и т.п. Возможно весь контроллер у вас будет размазан по событиям формы где функции контроллера по сути шаги ВИ.

Да и если можно по-русски пожалуйста диаграмму ВИ готовьте.

4103

Системный Анализ и Требования / Re: Преимущества выстроенного процесса Управления Требованиями

« : 10 Июня 2008, 20:41:58 »

Эд, а может посмотришь, очень надо. А то я уже все перерыл

Саня, врядли - это было как-то случайно и уже не помню что и как яискал, толи курсы, толи статьи, просто наткнулся про это дело почитал в памяти отложилось и все, засечку не поставил

А насчет капанья на мозги. Гриша верно говорит. На одном тренинге по бизнесу приводился пример. Сидит старичок в прарке и кидает крошки голубям. Сначал голуби улетали, потом стали ближе и ближе приближаться, наконец в один прекрасный день стали есть с руки старичка. Т.е. нужно постоянно закидывать удочку клиенту, но не говорить ему вот вам нужно, а подкидывать материальчик, чтобы у клиента постепенно созрело решение и он типа сам обратился а ты и никакого мол отношения к этому не имеешь. Т.е. не навязчиво надо гнуть свою линию коли понимаешь ее правоту

4104

Системный Анализ и Требования / Re: Преимущества выстроенного процесса Управления Требованиями

« : 10 Июня 2008, 14:56:43 »

т.е. сама компания является разработчиком софта, а ты типа модный консультант.

ААААА, хм ну тут наверное нужно иметь чутье менеджера по продажам, ну и написать парочку диссертаций или может купить какой-нить аналитический обзор на тему. Хотя ясно - что нужно как-то оценить внедрение и подсчитать прибыль, где-то на просторах рунета я видел статью, как раз посвященную именно твоей проблеме. Там писалось о том, как некая компания проводила внедрение СУТа и вообще ставлиа процесс разработки и делилась опытом того как это делать быстро - вернее рекламировала что умеет делать это быстро и четко, там же описывались пробемы, риски и способы их избежать - но не помню

4105

UML SysML и пр. / Re: Практическое применение UML

« : 10 Июня 2008, 14:49:22 »

Можете в таком случае назвать хотябы десять самых интересных с Вашей точки зрения?

Примеры именно на IBM Rational назвать не могу, хотя BOLD for Delphi (с использование RR еще не IBMовской правда), я наверное не внимательно читал, Вас по видимому интересовали именно реализации с IBM Rational, а не вообще с применением UML тулов?

4106

Системный Анализ и Требования / Re: Преимущества выстроенного процесса Управления Требованиями

« : 10 Июня 2008, 14:45:19 »

Супер, это как?? Т.е. приходишь к заказчику и говоришь, давай я вам внедрю ПУТ, выделим ключевые показатели, и померим до и после и посмотрим что получится???
А вообще ключевые показатели надо выделить. Этим и займусь на днях.

А причем тут заказчик? Ему то это вообще зачем? Или я чего-то не понял

4107

Системный Анализ и Требования / Re: Преимущества выстроенного процесса Управления Требованиями

« : 10 Июня 2008, 13:34:17 »

Саша, для тог чтобы сделать это осязаемым, нужно четко выделить критерии и сопоставить им количественные характеристики.
1 Скажем - время ввода в курс дела нового работника
2 время затрачиваемое на проверку требований рецензентом до и после
3. процент выялвения ошибко при обычном рецензировании и с СУТ
4. время подготовки отчетов по требованиям и т.п.

Для начал нужно выделить все наиболее часто осуществляемые операции. Оценить времязатраты до и после

естествено есть качественные моменты - но они как раз должны идти от качеств самих требований

4108

Системный Анализ и Требования / Re: Преимущества выстроенного процесса Управления Требованиями

« : 10 Июня 2008, 12:57:24 »

Эд,

Ну прямо слоган Может сделать данную фразу девизом сайта???

Ну не я автор этого слогана. Спасибо Виталию Григорашу и его магистерской дисертации - сделан отличный обзор, прямо можно публиковать

По делу - т.е. ты можешь гарантировать, что время разработки уменьшиться в 200 раз или кол-во ошибок уменьшится в 200 раз?? Т.е. после того как мы перейдем от того, что ТЗ писали как хотят и где хотят, в нормальный процесс, то мы в 200 (или меньше - цифра) снизим издержки??
Данный факт не убедит потенциального заказчика. Ну пишут они ща как-то ТЗ, а ты приходишь и говоришь - в 200 раз. А он - за счет чего??

Нет я говорил о цене стоимости ошибки
Цена ошибки и затраты на ее выявление и устранения в 200 раз меньше чем на стадии кодирования, т.е. если не управлять и сопровождать требования, то веротяность ошибки крайне высока как и цена ее устранения.
Говорить же о том что количество ошибок уменьшится в 200 раз - совершенно нельзя

4109

Системный Анализ и Требования / Re: Преимущества выстроенного процесса Управления Требованиями

« : 10 Июня 2008, 09:56:51 »

Цена ошибки при выявлении некорректных требований на стадии их формализации и анализа в 200 раз ниже чем ошибка, обнаруженая в коде.

4110

Для всех / Re: помогите начинаюшему.

« : 09 Июня 2008, 22:35:49 »

Эд дал ссылки на то что есть.

слушаю и повинуюсь
http://www.uml2.ru/forum/index.php?topic=286.0
чем не тривиальная тема
да и та ссылка про службу такси отличная тема
а это чем уж не проще
http://www.uml2.ru/forum/index.php?topic=570.0
да и это несложна
http://www.uml2.ru/forum/index.php?topic=486.0