4096

Теория моделирования и нотации / Re: Как изобразить функциональную схему?

« : 17 Июня 2008, 16:06:14 »

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

Надо сказать что практически все UML диаграммы графовые.

Поток сообщений (информации) можно изобразить диаграммами деятельности, последовательности, коммуникации (collaboration).

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

На диаграммах взаимодействия(последовательности и коллаборации (коммуникации)) тоже можно показать передачу сообщений, но во времени.

В вашем случае показана диаграмма коммуникации, она же диаграмма объектов. Так что думаю можно

4097

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

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

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

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

4098

MDA / Re: Начало

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

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

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

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

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

4099

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

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

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

4100

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

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

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

4101

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

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

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

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

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

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

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

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

4102

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

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

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

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

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

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

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

4103

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

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

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

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

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

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

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

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

4104

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

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

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

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

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

4105

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

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

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

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

4106

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

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

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

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

4107

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

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

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

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

4108

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

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

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

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

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

4109

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

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

Эд,

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

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

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

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

4110

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

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

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