5641

Теория моделирования и нотации / Re: Графы состояний = диаграмма состояний?

« : 20 Февраля 2007, 23:30:08 »

Диаграмма состояний, классов и остальное - есть нечто иное, как ориентированный граф и часто размеченный.

Диаграмма состояний - есть определенный эквивалент диаграммы или карты Харела и восходит к аппарату конечных автоматов. Общий случай конечного автомата есть вероятностный автомат. Можно сказать что конечный детерминированный автомат имеет вероятность перехода в некое состояние равное 1, а в остальные 0.

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

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

Такчто никаких ограничений - главное понимать когда что и зачем это делается...

А насчет того кто-нибудь делал:
Я целый курс лабораторных разработал, в том числе используем Матлаб, Симулинк, Сатейфлоу - где как раз и конечные автоматы. и веротяностные автоматы и СМО моделируем через фактически диаграммы состояний - жаль нет средства переноса UML диаграмм в стайтетфлоу машину, а то было бы вооще полный аншлаг:-)

5642

Примеры / Реальные примеры - безналичная оплата топлива на АЗС

« : 20 Февраля 2007, 20:07:52 »

Для начала хотелось бы определиться в чем (UML, DFD, IDEF) можно сделать наброски диаграмм (и диаграмм чего), что бы можно было общаться с заказчиком. Представить свое виденье, и соответственно после вопросво-ответов внести изменения в диаграммы.

Читая книгу Рамбо и Блаха, UML 2.0 ОО моделирование и разработка, можно подчерпнуть следующие моменты.

1. Концептуализация системы.
1.1. Изобретение концепции (у тебя она в целом есть)
1.2. Проработка концепции
1.2.1. Для кого предназначено приложение? (спонсоры и конечные пользователи)
спонсоры оплачивают разработку и важно получить добро
конечные пользователи будут работать с системой
1.2.2. Какую задачу приложение будет решать
ограничить масштаб усилий и установить область их применения. функции, которыми будет обладать система, а какими не будет
1.2.3. Где будет использоваться система
1.2.4. Когда будет нужна система
1.2.5. Почему нужна система
1.2.6. Как она будет работать (предложить некий прототип, возможно структуру, например автоматы АЗС - связаны с ЦК, то связан с ПК банка и т.п. или это кассовые терминалы)
2. Постановка задачи - нестрогое, понятное клиенту описание сути видения приложения. Рисовать можно в любой нотации, заменять графически примитивы картинками и т.п.)
3. Анализ предметной области - фактическое построение концептуальной диаграммы классов
3.1. выделение классов - избегать классов реализации, только классы предметной области
3.2. выделение  ассоциаций
3.3. выделение атрибутов
3.4. проверка маршрутов с помощью OCL
3.5. построение диаграммы состояний для объектов изменяющих свое состояние (например для счета в твоем случае - вряд ли больше)
3.6. модель взаимодействий - обычно не используется
4. Анализ приложения
4.1. Модель взаимодействия приложения
4.1.1. Границы системы
4.1.2. Действующие лица
4.1.3. Варианты использования
4.1.4. начальные и конечные события по каждому ВИ
4.1.5. Типовые сценарии - вполне понятные даже людям далеким от ИТ
4.1.6. Сценарии-вариации и исключительных событий
4.1.7. Внешние события
4.1.8. Диаграммы деятельностей - только для сложных ВИ
4.1.9. Структуризация ВИ и ДЛ
4.1.10 проверка по модели классов
4.2. Модель классов приложения
4.2.1. Интерфейсы пользователей
4.2.2. Пограничные классы
4.2.3 Управляющие объекты
4.2.4. Валидация по модели взаиможействия
....

Таким образом - нужно стремится использовать UML, но никто вовсе не запрещает использовать и все остальное

5643

Консалтинг и Внедрение / Re: Прогноз на несколько лет

« : 18 Февраля 2007, 13:38:20 »

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

5644

ПО Аналитика / Re: Оценка CASE интсрументов

« : 18 Февраля 2007, 13:31:52 »

Ничего не понял, а чем тебе это не опросник? А почему с балами не получится?

Саша я тоже ничего не понял, чего ты ничего не понял:-))
А тему переименуй, стыдно как-то читать с такими ошибками

5645

Обучение / Re: Опыт преподавания объектно-ориентированного подхода в моделировании, анализе etc

« : 17 Февраля 2007, 20:47:29 »

Я надеюсь, ты сказал студентам, что они должны будут ответить на все вопросы по его бизнесу во всех деталях?!

Безусловно. Я им сказал Вы владельцы, а следовательно должны знать ответы на все вопросы Вашего бизнеса.

какие артефакты (Б сущности) используются в их процессе.

Так артефакты или бизнес-сущности? А что ты понимаешь под Б-сущностью в данном случае: описание конкретных ресурсов: овощи, крупа, соль и т.п.(т.е. продукты), гроссбух, запись, журнал и т.п.(документы)?

5646

Обучение / Re: Опыт преподавания объектно-ориентированного подхода в моделировании, анализе etc

« : 16 Февраля 2007, 18:47:51 »

Хочу задать несколько вопросов и провести, так сказать, пост-анализ.

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

Итак, в бурной дискуссии мы уже решили, что давать реальный БП для студентов - бесперспективно. Причины ясны и заключаются в следующем:
1. отсутствие жизненного опыта
2. невозможность уточнения возникающих вопросов
3. кому из реального бизнеса это надо!

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

Что хотелось бы дать в помощь. Думаю, фантазия у студента хорошая. Но ей надо помочь. Все-таки дать какие-то рамки, вопросы, шаблон для формирования своего бизнеса. Т.е. мы как бы идем от противного. Нам требуется решить задачу А способ Б, для того чтобы ее решить именно так, пусть формулировка исходной задачи будет такой-то.

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

Однако более сведующие товарищи могут предложить что-то более ясное и существенное!

Пока я фактически рекомендую составить документ оценки деятельности огранизации (документ из RUP)

5647

Конференции Семинары и Тренинги / Re: РИТ-2007

« : 15 Февраля 2007, 19:09:03 »

Нет тогда пока отпадает. Времени просто недостаточно. Спасибо

5648

Конференции Семинары и Тренинги / Re: РИТ-2007

« : 15 Февраля 2007, 13:02:45 »

Денис, поучаствовать очень интересно. Правда неизвестно удасться ли поехать.
Можно узнать как готовить материалы и можешь ли ты в случае чего их представить?

5649

Обучение / Опыт преподавания объектно-ориентированного подхода в моделировании, анализе

« : 14 Февраля 2007, 19:54:41 »

Сегодня провел первое занятие по ООП. Общая цель занятий - познакомить с методологией ООП, моделирования систем в UML.

Первое занятие - Мозговой штурм. Придумывание бизнеса, business case, если хотите.
Группа из 28 человек поделена на 4 подгруппы. Каждой подгруппе предложено придумать бизнес на заданную тему (Кафе, магазин, мелкое производства, оказание услуг и т.п.). Задача подгруппы - расписать все аспекты своего бизнеса. Полагается бизнес уже существует и работает. Требуется определить все процессы, связи между ними, сценарии их выполнения, ресурсы, цели. Ориентация на личный опыт и фантазию. Я как преподаватель курирую группу, корректирую их обсуждение, не навязываю свое мнение, а просто указываю на некоторые ошибки обсуждения, даю мелкие советы: не выкидывайте идею, запишите ее, обсудите, потом отбросьте. пропишите каждый момент исполнения каких-либо действий. Что значит купить товар, как это может происходить, какие варианты вы видете, будете ли вы учитывать все варианты или строго ограничите этот вариант и т.д.
В конце занятия у каждой группы (их у меня 2) принял их самое общее представление о бизнесе,попытался задать определенные вопросы в случае неясных, двухсмысленных моментов. Выдал домашнее задание - подготовить общегрупповую презентацию их бизнеса. Презентация будет проходить на следующем занятии. На презентацию никаких ограничений не накладывал, единственно просил сделать в PowerPoint. Будет ли презентация чисто текстовая или графическая, решать студентам. Им предлагается подумать и попытаться принять полную ответственность на себя. Срок исполнения 2 недели до следующего занятия.

Впечатления: мозговой штурм прошел интересно. Студенты чувствовали себя комфортно. В группе выделились авторитеты и лидеры. В целом обсуждение захватило студентов. На мой взгляд пока им понравилось.

Увиденные проблемы: боязнь принять неверное решение или вывод. Обращаются например с вопросом: "А можно у нас покупки будут также и через интернет?", "А нам следует описывать поставщиков", "А как лучше описать процесс так-то или так-то". Отвечаю - ваша полная воля, как вы определите, так и будет. Что у вас получится обсудим на следующем занятии, ваши коллеги зададут вам вопросы, выступая вы и сами заметите какие-то неувязки и проблемы описания. Вводите любые правила и ограничения. Думайте сами, решайте сами (с)

5650

Примеры / Реальные примеры - БД Финансовых Инструментов

« : 14 Февраля 2007, 14:51:53 »

БД Финансовых Инструментов.

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

Неплохо бы привести примеры таких таблиц

5651

RUP EUP AUP OpenUP / Re: Практика использования RUP. Или бег на месте...

« : 11 Февраля 2007, 23:46:41 »

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

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

Насчет понятия проблемы, тоже разъянилось. Я тут побеседовал с Юрием Булуем и согласен, что проблема должна исходить от заинтересованной стороны, а не навязываться ей.

Вообщем можно сказать, что конценсус найден :-))

Нужно теперь его закрепить...

5652

RUP EUP AUP OpenUP / Re: Практика использования RUP. Или бег на месте...

« : 11 Февраля 2007, 00:29:25 »

Предлагаю не нагнетать эмоции. если задел - приношу извинения.

Сережа, это ты прости меня, если я дал повод, чтобы ты подумал, что задел меня. Вовсе нет.

ОДЛ - это носитель цели и почти всегда инициатор. Если ОДЛ н еинициатор, то это очень четко оговаривается. Так как я не разделял участников на бизнес-актеров и актеров, то они все нарисованы одинаково.

Еще раз повторюсь, я действовал в роли простого обывателя, который видит картинку, особо не зная всех тонкостей, но имеющий все-таки солидный жизненный опыт. Как раз этот опыт мог мне подсказать, что Клиент и есть некое внешнее лицо, желанное для ЗАО "Рога и копыта" и имеющий некий интерес в этом учреждении. Далее я вижу некую роль Продавца. Ассоциация очевидна. Я не знаю что там такое это продавец продает, но судя по названию ЗАО, рога и копыта... Конечно это домыслы, но что еще можно узнать из такой диаграммы?
Ты ответил, что к ней надо было бы подходить с точки зрения семантики UML, т.е. читать схему. Возможно ты и прав...

Конечно, здравый смысл подсказывает правильное прочтение. Но мой здравый смысл подсказывает, что у всех разный здравый смысл, так что лучше переспросить
То, что клиент хочет получить чек ясно опять только из здравого смысла (который у всех разный ), но не из диаграммы.

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

Выпадом про мнение ты ставишь меня в тупик... Чем принципиально различно мое мнение и мои идеи?

Я имел в виду, что мое мнение в данной ситуации не совсем объективное. Поскольку я сам же задачу придумал. К тому же я скорее неофит, чем серьезный конкурент. Но для того чтобы просто принять например твои доводы, я их должен глубоко осознать, а не просто принять на веру. Частично, я уже проникся твоими идеями. Они помогли мне взглянуть на прочитанное по другому, произошел некий качественный скачек. Но еще не до конца:-)

Твое мнение в данной ситуации очень интересно. Просто, я все пытаюсь донести мысль, что свой здравый смысл следует выносить на бумагу для всеобщего обозрения воизбежание неоднозначного толкования.

Это я уже понял, вернее понимал и раньше и интуитивно использую, просто нет еще навыка делать это скурпулезно.


Я тут обдумывал твой большой и мужественный пост (Кстати еще раз огромное за него спасибо), и знаешь к чему пришел?
Вот ты выдвигаешь скажем некие проблемы и последовательно разворачиваешь анализ, добавляя одну проблему за другой.
Но, если посмотреть на это несколько иначе. Некая выдвинутая проблема вызвана некими причинами, не имеет ли смысл сначала установить а в чем глубинная причина этой проблемы, а может и других проблем. Не окажется ли, что все эти проблемы имеют одни корни, а потому могут быть решены одним решением?


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

5653

Бизнес-анализ и Целеполагание / Re: Что такое бизнес-процесс?

« : 10 Февраля 2007, 12:49:43 »

Пока еще мало чего узнал, но на первый взгляд DFD-методология слабовата... Почитаю посмотрю..., по крайней мере в книге куча примеров

Если внимательно посмотреть на DFD-методологию, то мы в ней найдем очень явные черты вариантов использования и диаграмм деятельности. Конечно, нужно смотреть наоборот DFD_старше. Тем не менее это так:

Внешняя сущность ~ Действующее лицо (есть тут некая тонкость между действительно внешними к системе и внутренними ДЛ, но в целом очень похоже)

Подсистема или Процесс ~ вариант использования, деятельность или действие

Миниспецификация ~ сценарий ВИ, хотя и в более жестких рамках

Хранилища ~ Бизнес сущности или их совокупность

Потоки данных ~ именованные ассоциации и т.п.

Диаграмму дейятельности я бы быстрее сравнил с IDEF3 сценарием. Тут практически 100% совпадение.
Т.е. UML, конечно, развитие ранее существовавших методов.

Опять же между IDEF0 и DFD нет принципиальной разницы. если скажем рассматривать просто материальные системы. Однако переходя к проектированию ПО, возникает необходимость идти от требований, что IDEF0 вообщем не дает явно, а DFD позволяет это поддеркнуть. Кроме того выделение Хранилищ и Потоков Данных, которые например в BPWin ассоциируются с сущностями и атрибутами, позволяет интегрировать моделирование функциональности и моделирование данных

5654

О Сайте и Форуме / Re: Полезен ли наш форум?

« : 09 Февраля 2007, 17:46:44 »

Нормальная анкета. Средствами joomla ты легко ее разошлешь всем зарегистрированным, только сначал удали всех не активированнных.

Вопрос в том, а что мы хотим узнать? Или вернее когда мы узнаем, что мы готовы сделать?

Кажется мы довольно четко обозначили задачи: реструктуризация форума, реструктуризация файлового архива,
возможно реструктуризация контента сайта...

5655

RUP EUP AUP OpenUP / Re: Практика использования RUP. Или бег на месте...

« : 09 Февраля 2007, 17:30:29 »

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

Да ради Бога. Баб Яга всегда против:-) 1. в твоем вопросе описать, что ты видишь на диаграмме, я увидел подколку. Потому абстрагировался от "глубоких" познания UML, а использовал только познания скажем те, которые мне объяснил мой консультант, когда показывал енту самую диаграмму.
Что он мне сказал:
Прямоугольник очерчивает границы вашей зао "рога и копыта". Все что внутри - это ваше устройства бизнеса. Вот эти человечки  - действующие лица, которые чего-то хотят (чего написано внутри овальчиков).
Вот исходя скажим их таких примитивных постулатов я и начинаю исходить.

Ты же мне не написал - проделай полный анализ диаграммы на предмет того-то.  Мы наверное с тобой антагонисты :-) Когда ты задавал мне это вопрос, уже ожидал получить ответ такого вот вида, а я например узрел в этом, что сама по себе диаграмма ВИ неочень информативна, и искренне полагал, что именно это ты мне пытаешся объяснить. Не угадал :-) Опять получил щелбан.

Заметь, за что ты всегда меня стромишь, сам же и делаешь. Все видят банан по своему...

Как бы я предложил читать ту диаграмму: надо понимать, что это вполне конечный и определенный набор фактов.

Кажестя повторяться не имеет смысла, а?

3. Существуют описанные цели и сценарии их реализации

И где ты увидал сценарии реализации? Я пока вижу цели и связи

В частности, непонятно, кто основное действующее лицо - диаграмма не отвечает на этот вопрос, если надо уточнение, придется смотреть текст ВИ.

А с какой позиции смотреть. Кстати про ОДЛ я вообще ничего не говорил явно, однако. Если закрыть листочком все ЗАО мы увидим - а что мы увидим, Клиента - Черный ящик(с целью получить обслуживание)
По-моему не надо быть Коперником, чтобы понять, что клиент тут чего-то хочет. А хочет он явно получить обслуживание. По-моему ничего противоречащего здравому смыслу и здравой логике тут нет.

Давай найдем отличия твоего прочтения от реально имеющегося в диаграмме...

Давай попробуем.


[

b]Клиент обращается в ЗАО "Рога и копыта", чтобы Получить обслуживание.[/b] (Где написано слово "обращается", откуда известно, что основное действующее лицо - клиент?)

См выше. Если тебе так написать Клиент хочет получить обслуживание в ЗАО. Модель тем и характерна, что она скрывает или убирает второстепеннные элементы, а выпячивает значимые. Т.е. я полагаю, если ты мне нарисовал RLC- цепь, то вероятно в ней индуктивность означает именно индуктивность.

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

В данной ситуации продавец исполнитель процесса обслуживать и ОДЛ процесса Пробить чек. Причем из семантики ясно, что клиент хочет получить чек. Опыт жизни. Сергей!

домыслы не засчитаны, таких фактов нет на диаграмме)

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

Теперь смотри сам, чего не хватает на диаграмме для ответа на какие вопросы. И как она должна быть нарисована для того, чтобвы в точности соответствовать твоему тексту.

Это назвается многократный перевод. Такому стилю учать иностранному переводу.
Очевидно можно добавить некие комменты.

Естественно - это все мое частное мнение. Прошу критиковать и обсуждать.

Это не мнение - это декларация своих идей:-))

Мое мнение, думаю, в данной ситуации абсолютно не значимо. Былобы интересно узнать мнения других практикующих людей. Именно практикующих, поскольку мои знания чисто теоретизированы и не подкреплены практикой.