631

Примеры / Re: Подскажите что не так

« : 18 Октября 2014, 22:33:58 »

1. обобщение нужно перевернуть. Книга и Статья - это Библиотечная единица, а не наоборот.
2.  почему никак не определены кратности и другие атрибуты связей Журнал- Издательство, Издательство-Книга
3. Связь между Книга или Статья и Рубрика - убрать и провести к Библиотечная единица

632

IDEF ARIS BPMN и пр. / Re: Характерные ошибки построения IDEF0 диаграмм

« : 13 Октября 2014, 12:08:43 »

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

Я имел в виду некий чек лист (экспертная система - это скорее развитие чек листа), по которому студент может себя проверить перед тем, как сдавать работу.

633

IDEF ARIS BPMN и пр. / Re: Характерные ошибки построения IDEF0 диаграмм

« : 10 Октября 2014, 20:50:07 »

"1.3. Модель имеет единственный субъект 
Модель является некоторым толкованием системы. Поэтому субъектом моделирования служит сама система ... SADT-модель всегда ограничивает свой субъект, т.е. модель устанавливает точно, что является и что не является субъектом моделирования,"

английский subject - это субъект и предмет и объект и тема

634

IDEF ARIS BPMN и пр. / Re: Характерные ошибки построения IDEF0 диаграмм

« : 10 Октября 2014, 20:48:38 »

Возможно, этот документ будет более определенным. Но предлагаю дискуссии по корректности или нет методологии вынести за скобки этой темы.

635

IDEF ARIS BPMN и пр. / Re: Характерные ошибки построения IDEF0 диаграмм

« : 10 Октября 2014, 18:00:07 »

во-вторых, есть более дешевые способы учета интересов "заинтересованных лиц".

Было бы интересно обсудить но не в этой теме.

636

IDEF ARIS BPMN и пр. / Re: Характерные ошибки построения IDEF0 диаграмм

« : 10 Октября 2014, 16:47:03 »

Леонид: http://dit.isuct.ru/ivt/books/CASE/case8/sadt/gl22.htm

урок 2

637

IDEF ARIS BPMN и пр. / Re: Характерные ошибки построения IDEF0 диаграмм

« : 10 Октября 2014, 15:36:56 »

Например, "разработка исчерпывающей системы требований на создание информационной системы".

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

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

638

IDEF ARIS BPMN и пр. / Re: Характерные ошибки построения IDEF0 диаграмм

« : 10 Октября 2014, 14:10:27 »

P.S. по "цель"
1. Я бы не стал начинать формулировку цели с "Понять".
2. Эта цель имеет отношение к изображенной модели? Судя по ее содержанию - она относится к более крупной деятельности, частью (артефактом) которой может являться модель. Соответственно, размещение такой цели рядом с моделью может вводить в заблуждение.

Леонид, спасибо за анализ. А Вы как бы сформулировали данную цель (итог по сути сформулировать требования к информационной системе)?

639

IDEF ARIS BPMN и пр. / Характерные ошибки построения IDEF0 диаграмм

« : 10 Октября 2014, 10:59:36 »

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

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

Спасибо!

640

UML SysML и пр. / Re: Характерные ошибки use case диаграммы

« : 10 Октября 2014, 10:09:58 »

Я здесь не вижу ничего про «внутреннее поведение» и «прячем». Я вижу риторику про сдвиг от содержания деятельности к её результату, также, как в именовании юскейсов «Найти письмо» вместо «Искать письмо».

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

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

В общем, не вижу причин в чем-то друг друга убеждать.  Думаю мы говорим об одном и том же. Это лишь было уточнение.

641

UML SysML и пр. / Re: Характерные ошибки use case диаграммы

« : 10 Октября 2014, 09:45:00 »

Это где он о таком пишет?

Я имел в виду, именно это

642

UML SysML и пр. / Re: Характерные ошибки use case диаграммы

« : 10 Октября 2014, 09:32:30 »

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

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

Ты пишешь

6. Пропущен шаг по проверке корректности заполнения полей и уникальности пользователя.

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

Ты пишешь:

Выбрана неудобная система идентификации расширений. Схема 1а1а1 кмк намного нагляднее.

Не совсем понял твою схему -(кмк - как мне кажется?)

643

Теория моделирования и нотации / Re: Диаграмма деятельности. Слияние большого числа потоков условий

« : 09 Октября 2014, 18:50:49 »

Сделал за вас. Просто следовало начать новую тему, а не добавлять в тему не подходящую к вашему вопросу.

644

Теория моделирования и нотации / Re: Диаграмма деятельности. Слияние большого числа потоков условий

« : 09 Октября 2014, 15:56:24 »

скажите пожалуйста, допустим у меня есть шаг 1 к нему идут 3-5 альтернатив, как это сделать?

Разместите сообщение в отдельном потоке!

645

UML SysML и пр. / Re: Характерные ошибки use case диаграммы

« : 09 Октября 2014, 10:43:17 »

Коллеги,

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

Имя: Добавить нового пользователя
ID: 1
Краткое описание: ВИ описывает создание нового пользователя
Действующие лица: Администратор
Предусловие:
1.Администратор авторизован в системе.
2.У администратора должны быть данные о новом пользователя для создания учетной записи.

Постусловие: Пользователь зарегистрирован в системе “Электронная школа”
1.0 Основной поток:
   1.Администратор делает запрос на регистрацию нового пользователя.
   2.Система предоставляет возможность для выбора роли пользователя
   3.Администратор выбирает роль пользователя
   4.Система предоставляет форму для заполнения личных данных о пользователе в зависимости от роли
   5.Администратор заполняет предоставленную системой форму и сохраняет
   6.Система сохраняет пользователя в базе данных
   7.Система выводит сообщение об успешном сохранении данных
   8.Система предлагает администратору добавить нового пользователя

Альтернативные потоки:
1.1Данный пользователь уже существует в системе (ответвление шага 5)
   1.Система выдает сообщение, о том, что данный пользователь уже зарегистрирован в системе.
   2.Возврат к пункту 2 основного потока.

1.2Не все обязательные поля заполнены (ответвление шага 5)
   1.Система выдает сообщение, о том, что пропущено поле для заполнения
   2.Возврат к пункту 4 основного потока.

Ограничения:
1.Пароль должен состоять из набора латинских букв и цифр,  должен быть не менее 6 символов символов.
2.Логин должен содержать не меньше 6 цифр.
3.ФИО должен состоять из русских букв, начиная с заглавной буквы.
4.При заполнении поля “Класс” выбирается число от 1 до 11 включительно и без пробела ставится буква русского алфавита: А, Б, В ,Г ,Д.
5.Адрес должен состоять из букв русского алфавита и цифр и не должен превышать 50 символов.
6.Дата рождения ставится в соответствии с предложенным календарем.
7.Email представляет собой стандартную форму электронного почтового ящика.
8.Администратор может выбрать только одну из ролей, либо ученик, либо учитель.
9.Мобильный телефон должен состоять из 11 цифр, начиная с 8