3451

Примеры / Re: Моделирование деятельности деканата

« : 10 Мая 2009, 22:50:44 »

помогите пожалуйста рассмотреть Процесс отчисления студента

А что в нему нужно рассмотреть?

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

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

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

Есть и другие причины, в том числе и личное заявление студента.

Таким образом суммируя можно процесс описать так:
1. произошло событие инициирующее процесс отчисление студента
2. декан издает приказ об отчислени  студента
3. текст приказа доводится до студента
4. приказ передается ректору на утверждение
5. личное дело студента зкрывается и хранится определеное время (обычно до конца учебного года, прежде чем сдается в архив)

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

3452

UML SysML и пр. / Re: Плюсы и минусы диаграмм вариантов использования

« : 09 Мая 2009, 19:49:31 »

Он Ивар, швед.

Ага ты прав, просто я что-то не обратил внимание когда сдирал библиографии книги

3453

UML SysML и пр. / Re: Плюсы и минусы диаграмм вариантов использования

« : 08 Мая 2009, 22:08:36 »

Не влезло в предыдущий

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

3454

UML SysML и пр. / Re: Плюсы и минусы диаграмм вариантов использования

« : 08 Мая 2009, 22:08:12 »

Читая книгу Айвара Якобсона, Грэди Буча, Джеймс Рамбо "Унифицированный процесс разработки программного обеспечения", я вижу, что не имеет смысла так драматизировать ситуацию относительно ДВИ.

Вполне возможно сама по себе ДВИ на ранних стадиях анализа, в первичной работе аналитика (то что у нас обычно возникает при обращении студентов на форуме) ДВИ мала пригодна как инструмент отображения контекста. Ясно, что этот контекст уточняется итерационно.

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

Почему? Да хотя бы потому, что графические образы проще трассировать. Графические образы проще использовать повторно.

Например, гораздо проще представить, чем описать картинку UCDPN1

А картинка UCDPN2 - дает сразу логичскую связь между ДВИ и аналитической моделью VOPC

А как использовать такую картинку UCDPN3 или UCDPN4, если бы у нас не было исходной ДВИ?

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

3455

IDEF ARIS BPMN и пр. / Re: Выбор нотации моделирования IDEF для внедрения Бухгалтерской ИС 1С 8.х

« : 08 Мая 2009, 13:49:09 »

Конечно я ен совсем понимаю, скорее я совсем не понимаю
Хотелось отобразить в функциональной модели работу бух отдела, дабы выявить необходимые для автоматизации участки, и хотелось выявить функциональную разницу между двумя ИС внедряемой и существующей.

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

Скажем ясно что ввод первичных документов - дело сотрудника, хотя здесь можно унифицировать задачу через штрихкодирования, модуль сбора данных и т.п.
А вот проводка будет уже производится автоматом а не вручную

3456

IDEF ARIS BPMN и пр. / Re: Выбор нотации моделирования IDEF для внедрения Бухгалтерской ИС 1С 8.х

« : 08 Мая 2009, 12:55:08 »

1.
Цели

Ниже не цели, а задачи. Цели это улучшить, углубить, расширить,

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

IMHO, для этого лучше подходят другие нотации ARIS, BPMN к примеру

2. Выявить различие между текущей БД и внедряемой БД

Нарисуйте текущую БД, Нарисуйте будущую БД - сразу все станет ясно. Правда как это сделать для 1С, затрудняюсь ответить. Наверное получить исходную конфигурацию, создать новую структуру конфигурации сравнить оценить улучшения

3457

IDEF ARIS BPMN и пр. / Re: Выбор нотации моделирования IDEF для внедрения Бухгалтерской ИС 1С 8.х

« : 08 Мая 2009, 11:27:16 »

Да в том правильно ли я "думаю", и не бью ли гвозди микроскопом, или может нужен совершенно иной "подход", скажем создание отдельной модели в IDEF0 для процессов, и отдельной для выполняемых действий в IDEF3. интересует мнение людей решавших поставленные мною в топике цели, и их подходы к решению.

Цель то какова? Непременно нарисовать диаграммы? Или получить понимание проблемы?

Причем в топике вы задаете выбор нотации IDEF. Это для меня звучит так: выбор инструмента молоток для забивания гвоздей - это правильно или нет?

IDEF - это стандарты. Вы выбрали IDEF0 - функциональное моделирование в виде иерархии взаимосвязанных функций. Деление может происходить по подсистемам- отделам, по функциям, по этапам процесса

IDEF3 - способ описания рабочего потока, он дополняет скорее IDEF0

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

IDEF0 (в BPWin) допускает декмопозицию в IDEF3 и в DFD, последняя кстати удобна для демонстрации уже автоматизированных процессов но не только, она ориентирует вас на потоки данных

Может вообще вам не следует начинать с IDEF0, а сразу с DFD?

3458

IDEF ARIS BPMN и пр. / Re: Выбор нотации моделирования IDEF для внедрения Бухгалтерской ИС 1С 8.х

« : 08 Мая 2009, 08:41:03 »

Вопрос в чем?

3459

UML SysML и пр. / Re: Плюсы и минусы диаграмм вариантов использования

« : 07 Мая 2009, 23:07:38 »

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

Ida, простите, но это демагогия. Для того чтобы научиться пользоваться инструментом, нужно точно понимать его назначение и правила его применения. Мне кажется, как раз это мы и пытаемся выяснить, поскольку на форуме существуют две диаметральные точки зрения КОНКРЕТНО на ДВИ.

3460

UML SysML и пр. / Re: Плюсы и минусы диаграмм вариантов использования

« : 07 Мая 2009, 23:04:11 »

Each use case specifies some behavior, possibly including variants, that the subject can perform in collaboration with one or more actors...The subject of a use case could be a physical system or any other element that may have behavior, such as a component, subsystem, or class. ...

Английский язык велик и могуч. И не всегда можно его понять буквально.
Цитата имеет разрыв и отсюда лингвистическую несолгасованность.
Если в первом предложении subject явно имеет смысл СИСТЕМЫ, ОБЪЕКТА, то во втором предложении использование этих определений спотыкается. Система (объект) варианта использования? - звучит очень не по-русски. ПРЕДМЕТОМ варианта использования, то же не вполне, но ближе. Но вполне по-русски будет перевод ОБЛАСТЬЮ ДЕЙСТВИЯ варианта использования.
Т.е. первое предложение будет звучать:
Каждый вариант использования точно определяет (обуславливает, устанавливает) некоторое поведение, возможно включая варианты, которое эта система (этот объект - т.е. нечто уже известное нам, ранее оговоренное, упоминаемое и определенное - определенный артикль the) может (а я бы лучше перевёл умеет!) выполнять в сотрудничестве с одним или более акторов.

Опять же не сотрудничество одного или нескольких акторов между собой, а сотрудничество система - самой являющейся особым выделенным действующим лицом и другими ВНЕШНИМИ по отношению к ней ДЛ.

Use cases can be used both for specification of the (external) requirements on a subject and for the specification of the
functionality offered by a subject. Moreover, the use cases also state the requirements the specified subject poses on its environment by defining how they should interact with the subject so that it will be able to perform its services.

Поведение субъекта ВИ устанавливает требования, которые субъект накладывает на окружающую среду через определение взаимодействия среды с субъектом. Т.е. спецификация как раз определяет назначение ВИ  для описание взаимодействия. ДВИ описывает множество взаимодействий, задаваемых ВИ.

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

Вот как тут после этого друг друга понимать

3461

UML SysML и пр. / Re: Плюсы и минусы диаграмм вариантов использования

« : 07 Мая 2009, 22:19:27 »

Уфф. Прочитал мнения участников дискуссии...

Типа, чем бы дитятки не тешились?

Итак, резюмируем.

Ясный плюс с позиции tolldo.

Диаграмма вариантов использования средство нагрузить правое полушарие и снять нагрузку с левого, которому приходится ублажать правое, что приводит с рассеиванию внимания. Т.е. диаграмма ВИ, как и любая другая - это средство сосредоточения внимания на предмете исследования. Исходя из этого, диаграмма в дискуссии помогает привлечь и удержать внимание участников на предмете разговора. Похожий вывод в иной подаче сделан Boatman и Денисом Бесковым.

Вопрос будет ли играть диаграмма ту же самую роль в случае чтения документации?

3462

UML SysML и пр. / Re: Плюсы и минусы диаграмм вариантов использования

« : 06 Мая 2009, 22:26:28 »

Я хочу высказаться в пользу ДВИ в противоречии со занятой в данной теме позиции.

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

С чем бы он столкнулся:
1. повторением одних и тех же ВИ у разных ролей пользователей
2. сложно было бы передать обобщение одиних пользователей другими. Вернее не так сложно, как мало наглядно
3. скорее всего мы бы все равно заставили его что-то нам нарисовать.
4. скорее всего мы бы хуже поняли ход мысли студентам в тексте, чем в диаграмме

Теперь о возможных плюсах диаграммы над текстом (я уже ранее пытался высказать эту мысль в другом месте)
1. диаграмма - это образ, человеку проще воспринимать образы, чем просто текст. Все равно текст преобразуется в образы в голове.
2. диаграмма ВИ в данном случае имеет определенные ограничения в изображении и это заставляет ограничивать свою фантазию в изображении и передавать смысл более простыми средствами.

Далее может вы заметили, что между диаграммами DFD и диаграммами ВИ есть определенное сходство:
1. там и там есть понятие внешней сущности
2. там и там есть сущность, инициирующая процесс, и сущность вспомогательная - поставщик данных
3. в DFD нельзя изобразить обощение одних внешних сущностей через другие, на ДВИ можно
4. как на ДВИ, так и на диаграмме DFD не следует изображать внешние сущности, не взаимодействующие непосредственно с системой
5. контекстная диаграмма DFD почти тоже что и диаграмма ДВИ, если разрешить изображать на DFD внутренние процессы или подсистемы
6. Обе диаграммы ориентированы на отображение взаимодействия внешних сущностей с системой
7. ДВИ специфицируется через описания ВИ, DFD через миниспецификации процессов. Хотя в последнем случае упор на функциональное деление.

Кстати Скотт Амблер в книге Гибкое моделирование тоже об этом говорит. Однако мне кажется, ДВИ выразительнее диаграммы DFD.

Какие трудности я вижу при создании ДВИ, что потом влечет за собой и трудности в описании ВИ.
1. Понятие цели пользователя - что же считать целью пользователя, можно ли использовать текстовый шаблон, какой он будет, какие критерии позволяют сказать - это цель, а вот это не цель. Что же понимают англичание под словом цель: purpose, aim, objective, target, goal, intent, intention...
возможные ответы:
  - то, что может считаться элементарным бизнес-процессом, определенной обязанностью сотрудника
  - то, что одобряется руководством как исполнения полезной работы
  - нечто краткое, сеансовое, законченное - транзакция
2. Наименование варианта использования - с какой стороны стоять при именовании ВИ (это к тому регистрация покупки или регистрация продажи). Если имя ВИ - цель, должное ли оно отржать SMARTER конфигурацию, обязательно выраждаться в ответ ДА-НЕТ.
3. структурирование диаграммы -не понимание связей обобщение, зависимостей include и extend. Не следует ли на этапе анализа заменить их, следуя, Розенбергу на invoke и precede. Первое как либо include или extend (конкретная реализации смысла будет потом на стадии проектирования), а второе без аналогов, просто демонстрирует некое предшествование, то что должно быть выполнено в начале, но имеет и самостоятельно значение? А то и вовсе запретить структурирование ВИ, разрешив только структурирование акторов, как наиболее понятное и очевидное?
4. выделение акторов

3463

UML SysML и пр. / Re: Плюсы и минусы диаграмм вариантов использования

« : 06 Мая 2009, 20:10:13 »

* П.ч. нельзя\сложно показать иерархию ролей, участие одной роли в нескольких задачах, и ВИ, как мы помним, - это цель Пользователя и не совсем задача или функция Системы.

Демонстрация иерархии ролей может быть выполнена и без реализации диаграммы вариантов использования.
Когда я говорил о таблице Участник/Задача я подразумевал коберновскую таблицу участник-интерес. Интерес, задача, цель. Мне кажется мы слишком склоны ориентироваться на понятие цель, а ведь в английском слово цель имеет столь разнообразные значения. Потому когда я упоминал слова Задача, я не говорил что это функция системы, я говорил, что это задача участника, функция система одна обеспечить выполнение задачи пользователя

* Тебе сценарий написал Сергей

Написал, однако участие ДВИ здесь может быть минимальным.

* Например, мы формируем сценарий из 5-9 шагов, а потом каждый Системный шаг детализируем уже с помощью ФТ

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

* Да можно, все можно. Можно сюда заместо одной идеологии ВИ вкрутить и Таблицы и Списки и Ментальные Карты и Контекстные Диаграммы и CRC и т.д. просто ВИ - это комплексный продуманный подход по выявлению, анализу и документированию ПТ.

смотри выше. ВИ может и подход, но причем тут диаграмма?

* Выделение ВИ и выявление Требований немного разные вещи

ВИ - это функциональные ТРЕБОВАНИЯ. Нельзя говорить противопоставлять одно другому. Форма записи не означает различия смысла!

* Если нормально нарисовать и объяснить, то сложностей мало, если этого не делать, то ДВИ бесполезна

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

Диаграмма вариантов использования может быть полезна в рамках организации процесса разработки специалистам компании разработчика, как часть их прфессиональных знаний в:
1. принятии проектных решений
2. в ходе разработке тестов
3. в ходе разработки пользовательской документации
4. как средство навигации по моделям проекта при использовании соотвествующих инструментов

* Если грамотно использовать, то это +, если нет, то это -

Что такое грамотно использовать. Приведи примеры грамотного использования.

3464

UML SysML и пр. / Re: Плюсы и минусы диаграмм вариантов использования

« : 06 Мая 2009, 14:04:00 »

Кто не понял, что я написал? Задайте конкретные вопросы.
В качестве примера - ЛЮБАЯ ГРАМОТНО составленная ДИ.

Денис ты написал все очень корректно. Но на мой взгляд ты говоришь примерно так: Очем тут разговор - ДИ полезна - это аксиома, доказательства не требует. Тем неменее ты приводишь, где будет полезна ДИ. Это хорошо. Но хотелось бы наглядных примеров в пользу твоей точки зрения.

ДВИ полезны для выявления назначения системы в диалоге с Заказчиком/Пользователем.
Как понятно из его рассказа, это целиком и полностью зависит от умения аналитика вести эту работу в качестве Коммуникатора.
Рисует он там овальнички или прямоугольнички — Заказчику всё равно. Рисует он там мужиков с яйцами или мордочки-смайлики — всё равно.
Аналогичным образом я могу составить рассказ о том, как в взаимодействии с Заказчиком получить на доске Список ролей (например, с помощью Контекстной диаграммы), а потом пройдясь по каждой роли, получить Список задач, которые будут решать эти роли с помощью системы (Проходом по сценарию деятельности этой Роли вообще, в бизнесе, а не в системе).

Вот точка зрения Дениса. Полезна не сама ДИ, а процесс получения некой диаграммы в ходе взаимодействия З/П. При этом неважно будет ли это ДИ, или нечто иное.

UML дает нам в качестве КОНТЕКСТНОЙ именно ДИ и будет полезна

ЛЮБАЯ ГРАМОТНО составленная ДИ.

Что значает тогда грамотная?

многочисленные примеры в форуме показывают, что ДИ рисуется в отрыве от З/П, и когда последний получает готовый результат, он не понимает её пользу.

Принимаем ли мы факт, что ДИ полезна только ходе взаимодействия З/П? А сама по себе даже с комментариями лишняя?

Добавлю, что наверное ДИ полезна в рамках UML инструмента, как содержание и средство навигации. Согласны ли вы с этим?

+ ДВИ:
* Охватить одним взглядом функционал Системы, Пользовательские Требования
* Хорош при выявлении Требований
* Служит каркасом для дальнейшей детализации Требований и Архитектуры
* Служит для формирования первоначального набора Тестов, Ролей и Пользовательской Документации

* а почему ты полагаешь, что таблица Участник/Задача не отвечает той же цели? А что делать, если система слишком велика, чтобы продемонстрировать ее функционал для охвата одним взглядом. ДВИ не подлежит декомпозиции
 * а чем она хороша для выявления требований, если тебе нарисуют диаграмму, разве это позволит тебе выявить корректно требования?
 * например?
 * опять же чем плоха простая таблица?

- ДВИ:
* Сложность выявления ВИ и рисования ДВИ
* Сложность понимания
* Не применимость для ряда задач - Интеграционные решения, Один Пользователь и т.д.
* Много взглядов (вариантов) на одну и ту же ДВИ

* нет ли противоречия этого пункта с * Хорош при выявлении Требований
* а разве наглядность диаграммы не служит для облегчения понимания? Если диаграмма сложна для понимания зачем она вообще нужна?
* чем плохо множество взглядов. Может как раз эта позиция и сильна. Диаграммы IDEF0, DFD строго определяют одну и только одну точку зрения, так может множественность токи зрения как раз хороша, поскольку снимает ограничение

3465

UML SysML и пр. / Re: Плюсы и минусы диаграмм вариантов использования

« : 06 Мая 2009, 07:55:00 »

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

Эх.... ничто не скроется от опытного взгляда, умудренного опытом Лодочника

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

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

Есть опровержения, дополнения, усиления?