661

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

« : 30 Сентября 2014, 13:01:51 »

В данном случае Эд говорит о подготовке студентов. Они, скорее всего, ещё не понимают целей, для которых может использоваться обобщение, и поэтому у них будут трудности с пониманием include и extend (и есть, судя по вопросам в этом форуме).

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

662

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

« : 29 Сентября 2014, 14:19:23 »

А все действия типа выставить/изменить/удалить они показывают как CRUD или каждое отдельным ВИ?

На самом деле никаких явных рекомендаций по использованию/не использованию CRUD я не давал. Предполагается по правилам игры, что знания у них есть (3 и 4 курсы), и сейчас они эти знания должны применять.

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

663

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

« : 29 Сентября 2014, 12:23:32 »

Студенты выполнили работу над ошибками. Где-то воспользовались рекомендациями Сергея. И вот что получилось:

Учитель:
Выставить оценки ученику (за урок, за четверть, за год), изменить оценки, удалить оценки, записать ДЗ, изменить ДЗ, удалить ДЗ, отметить отсутствующих, записать примечания, изменить примечания, удалить примечания

Админ:
Создать учетную запись с данными о пользователе (ученик, учитель), изменить данные (ФИО, дата рождения, адрес и т.д.) пользователя, удалить данные пользователя, занести расписание (за год), изменить расписание, удалить расписание, занести список учеников в журнал, изменить список учеников, удалить список, запросить отчет рейтинга оценок N класса, запросить отчет о недельной нагрузке учителей в часах, запросить отчет о недельной загрузке учеников N класса в часах

Ученик/родитель: просмотреть расписание, просмотреть оценки, просмотреть ДЗ, просмотреть посещаемость, просмотреть примечания

Что скажет почтенная публика?

664

Примеры / Re: use case и диаграмма последовательноси работы парикмахерской

« : 28 Сентября 2014, 23:20:42 »

А зачем для описания работы парикмахерской вы используете UML?
Вы какую цель преследуете?
Или иначе, какую задачу Вам поставил преподаватель?

665

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

« : 26 Сентября 2014, 21:03:49 »

С точки зрения закона сохранения информационных потоков

Денис, а не можешь развить эту мысль. Что это за закон? Есть ли какие-то ссылки на него? Я слышал о законе сохранения информации, но и то не в рамках нашей специальности.

666

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

« : 26 Сентября 2014, 20:58:43 »

У юксейса «Выставить оценки в журнал» непонятны рамки — ученику? классу? всему потоку? За задание? За день? За неделю? За четверть? За год? Уточнение «в журнал» мне кажется лишним.

Да, конечно, ты прав. Ясно почему возникло именно такое наименование. А как бы ты сформулировал: оценка ставится ученику за выполнение какой-то учебной активности: домашнего задания, ответа на уроке, контрольная, что там еще бывает?

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

Ну, возможно, это Сформировать отчет? Однако ты скорее имеешь в виду, что-то типа Просмотреть успеваемость ученика/класса?

667

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

« : 26 Сентября 2014, 16:25:36 »

Еще тогда предложу к обсуждению такой экземпляр

668

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

« : 26 Сентября 2014, 15:14:56 »

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

Гриша, ты считаешь, что этого достаточно для аргументирования проблемы?

В данном случае UC "Оформить журнал" просто не нужен. Ощущение такое, что вместо диаграммы ВИ автор изобразил структуру меню.

Гриша, я тоже предположил, что выполнена некоторая декомпозиция. (Правда у Коуберна есть такой пример http://www.uml2.ru/faq/use-cases/421- (см рисунок 2).
Можешь ли ты из свое опыта сказать в чем тут будет проблема? И Следует ли просто удалить ВИ Оформить журнал, а то что выполнено как include просто превратить в самостоятельные ВИ.
Тут на мой взгляд достаточным условием будет то, что у учителя нет цели Оформить журнал.

669

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

« : 26 Сентября 2014, 10:31:13 »

Друзья,

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

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

Спасибо

670

IDEF ARIS BPMN и пр. / Re: Считать ли электроэнергию и пар - механизмом

« : 25 Сентября 2014, 22:35:08 »

Это смотря какой нам нужен результат. Нас же не выводы по итогам моделирования интересуют а, так сказать, процесс.

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

Мое мнение - не стоит сводить к проектированию БД. Это все-таки очень разные вещи. Информационная система, к примеру, может и не иметь в составе своего обеспечения БД.

Ну если почитать определение законодательство РФ, не может. К тому же, что вот Вы вкладываете в понятие БД?

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

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

Караул! Объяснения на пальцах в течение пары семестров, да еще и без ИТшной базы - это ж как мертвому припарка.

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

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

И в чем же тут принципиальное различие? Но при любом ответе, я этого в теории и не даю. Пока я просто знакомлю на лекциях с тем, что есть такое Информационный процесс и какие они бывают, что такое ИС, ее назначение и функции, как применяется системный подход при построении ИС, каков ЖЦ ИС, каковы типичные архитектуры, каковы этапы построения. Причем все достаточно пунктирно, учитывая что всего 8 лекций в семестр. Плюс еще нужно познакомить с нотациями.

Они же и так устраиваются. Да еще и "чаще". Те, кто хочет. Зачем мешать им и смущать неокрепшие умы остальных?

Ну, если Вы станете деканом или завкафедрой их факультета, то мы с Вами точно договоримся, что не стоит смущать

671

IDEF ARIS BPMN и пр. / Re: Считать ли электроэнергию и пар - механизмом

« : 25 Сентября 2014, 18:28:00 »

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

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

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

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

Второе. Непосредственно автоматизация производства. То есть, управление "механизмами", ресурсное ("входящее") планирование, планирование обеспечения производственными средствами и т.п.

Этого я вообще не понимаю. Это вы о чем:)?

672

IDEF ARIS BPMN и пр. / Re: Считать ли электроэнергию и пар - механизмом

« : 25 Сентября 2014, 18:21:48 »

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

Не совсем так. Декан вызвал меня и примерно сказал следующее: "Наши автоматчики чаще устраиваются как разработчики ПО, Ну ты там им покажи как используя IDEF0 и т.п. это делается" Когда я встретился со студентами и переговорил, я понял там практически нулевой фундамент по IT. Потому, как и что с ними делать, не совсем ясно. Ну как без умения как-то программировать делать какие-то приложения?

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

Возможно этот путь ошибочен, не знаю.

673

IDEF ARIS BPMN и пр. / Re: Считать ли электроэнергию и пар - механизмом

« : 22 Сентября 2014, 21:08:39 »

Да обычный вроде. Дробим на отдельные процессы, связываем их входами-выходами - и вуаля.

Там радиационная обжарка меня удивила.

От технологических процессов к информационным? Это тема АСУ ТП. Я в них не силен, но логику объекта и субъекта управления, а также прямых и обратных связей никто не отменял. Просто информационные процессы тут будут "сбоку" от технологических.

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

Да, но к описанному процессу это не будет иметь особого отношения.

только как основа, погружение, некий якорь в сознании.

674

IDEF ARIS BPMN и пр. / Re: Считать ли электроэнергию и пар - механизмом

« : 19 Сентября 2014, 19:41:30 »

Я ни в первом процессе, ни во втором не могу понять, чем же нужно управлять. Они же автоматические, насколько я понимаю.

Например, стадиями процесса. Ну из описания это не ясно, автоматические они или нет.

675

IDEF ARIS BPMN и пр. / Re: Считать ли электроэнергию и пар - механизмом

« : 19 Сентября 2014, 17:32:19 »

В продолжение темы. Если интересно. Процесс вообще офигенский.

Название процесса: производство обжаренного кофе

Описание процесса:
Кофейные  зерна пропускают через машину, напоминающую мельницу. Машина производит очистку таким образом, чтобы вся грубая мякоть удалилась, а зерно осталось лишь в тоненькой оболочке. После того как мякоть с плодов была удалена с помощью машин, семена направляют на промывание, которое происходит в специально выстроенных для этих целей каналах. Они сделаны не в виде прямых линий, а слегка извиваются. Это позволяет лучше промыть зерна и обнаружить среди них больные, которые начинают всплывать. После того как зерно промыто, его направляют на ферментацию. Делается это с целью удаления нерастворимых частиц мякоти, оставшейся после промывки. Чтобы зерно прошло эту стадию нормально, его постоянно переворачивают, подставляя под солнце как можно больше поверхности зерна. Как правило, эта стадия длится до 24 часов. После этого зерно направляют на повторную промывку.
Очистка зерен. На данном этапе обработки осуществляется продувание кофейных зерен(машины). Для этого применяют машины, позволяющие удалить пыль, землю, камни и другие примеси. После продувки зерно направляют на магнитную чистку, чтобы удалить все металлические крошки, которые могли попасть в кофейные зерна с металлических машин в результате предыдущих обработок.
Следующая обязательная стадия производства — гранулометрический отбор, который представляет собой сортировку семян по их размеру с использованием специального сита. Первыми отбирают крупные семена, которые относят к элитным, из которых получают кофе самого высокого качества. Сущность этого отбора состоит еще и в необходимости выявить некачественные или больные зерна, ухудшающие качество всей партии товара.
Обжарка зерен. Чтобы обжарка прошла успешно и кофе получился требуемой степени обжарки, температура этого процесса не должна превышать 200 °С, а продолжительность составлять около 1 часа, в зависимости от необходимой степени. В результате происходит потеря массы из-за испарения воды, а также разрушения посторонних частиц, которые находятся в зернах кофе. При этом объем его увеличивается.
Радиационное обжаривание. Сначала кофейные зерна просвечивают гамма-лучами, а затем дожаривают по стандартной тепловой обработке.(технологический регламент радиоактивного обжаривания)
Охлаждение. Происходит в специальных машинах, позволяющих охладить кофе до температуры 40-45 °С. Для более высокого качества продукта его обязательно пропускают через специальные магнитные установки, позволяющие выявить металлические примеси. После этого зерна помещают в машины, отбирающие имеющиеся в массе камни.

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

Входы процесса:
кофейные зёрна, солнечная энергия , эл. энергия, радиоактивный источник.

Управление процесса:
время на сушку 24 часа, обжарка при температуре 200 °С, время обжарки 1 час, температура охлаждения 40-45 °С.

Механизмы процесса:
машина для очистки зёрен, машина для промывки зерен, машины для продувания кофейных зерен, машины на магнитную чистку, сита, машины охлаждения кофе, магнитные установки.

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

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