Форум Сообщества Аналитиков

×


Просмотр сообщений

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


Темы - Galogen

Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 »
1
Тут в одной ветке мы уже немного обсуждаем, что в UML 2.5.1 несколько иначе трактуется use case, чем это обсуждалось в той самой ветке.
 
Может поговорим, почему object diagram более не поддерживается стандартом?

2
Коллеги, добрый день.

Через пару лет скорее всего я буду читать новый курс "Инженерия требований". Он появился в результате перехода на новый учебный план подготовки по направлению 09.03.02 (бакалавриат) Информационные системы и технологии.

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

3
Компания sparxsystems уделяет большое внимание подготовке и распространению учебных материалов по использованию ЕА. Проводит регулярно вебинары по теме.

Возможно, тем, кто только начинает изучать ЕА может быть полезной эта информация: ЕА начал серию вебинаров по основам моделирования в ЕА.
На текущий момент выпущены
1. Modeling Basics – Creating Your First Model with Enterprise Architect - Основы моделирования: Создаем вашу первую модель с помощью Enterprise Architect
2. Modeling Basics – Creating UML Class Models with Enterprise Architect - Основы моделирования: Создаем UML модель (диаграмму) классов с помощью Enterprise Architect


4
Предлагаю послушать и возможно подискутировать.

https://www.youtube.com/watch?time_continue=481&v=CmCEdVrZQAE

Дело сдвинулось с мертвой точки!

Сегодня узнал выходные данные своей первой статьи про математическое обоснование SOLID принципов (доклада, который я рассказываю с 2014 года - https://goo.gl/jUXeHZ).

Статья называется О формализации процесса разработки программного обеспечения. Выйдет в журнале Математические структуры и моделирование 2017. No 3(43). С. 96–107

Наследующей неделе журнал сдают в печать, а значит в октябре уже будет доступен.

На полное обоснование потребуется 4 статьи общим объемом 40-50 страниц. На публикацию уйдет год, если не будет форс-мажоров. Но это немного, учитывая, что по разным обстоятельствам я публиковал статьи 3 года.

5
Со вчерашнего дня что-то явно произошло с внешним видом форума

При заходе на форум он не показывает мне не прочитанные сообщения (новые)
Показывает только ответы на мои сообщения
В посте исчезла иконка последнего сообщения

Что-то меняли администраторы?

6
Sparx / Sparx Enterprise Architect 13
« : 21 Июня 2016, 11:09:35 »
Готовимся к выходу новой версии: http://www.sparxsystems.com/downloads/pdf/enterprise-architect-130-beta-flyer-a4-web.pdf

8
Друзья, у кого есть опыт создания MDG технологии с использованием внешних файлов изображения в качестве исходного отображения UML элементов, в частности.

Также интересует ваш опыт создания UML профилей и реализации их в рамках MDG технологиии

9
Добрый день, друзья!

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

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

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

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

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

А заявка, созданная обычным пользователем, после того как оператор ее взял на себя, может перейти в исходное "не распределенное" состояние, если с момента ее взятия в течение определенного времени по ней не было никаких работ.

Следует ли рассматривать эти два сценария как разные, хотя и похожие (во много пересекающиеся) ВИ, или же стоит рассмотреть как одни ВИ, в котором есть некий основной сценарий и альтернативы?


10
Пытаюсь со студентами использовать EA при разработке видения системы, т.е. выстроить цепочку рассуждений и трассировки от проблем (issue) к потребностям (need) и к возможностям (feature).

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

Можно начать с потребности "Автоматизация расчета зарплаты (выплаты)" - корректно такое название или нет, какое бы вы дали?
В чем вы видите ошибочность возможностей системы (feature), которые реализуют такую потребность: "вход в систем", "доступ к старым данным", "ежедневное обновление данных для расчета"?

Спасибо !

11
Подробности тут

12
Друзья, с наступающим Новым годом.

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

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

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

вообщем хочется пообсуждать, чтобы или удостовериться в своей правоте или исправить свои предубеждения

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

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

Спасибо!

14
Друзья,

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

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

Спасибо

15
Друзья,

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

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

Студенты, конечно, делают много ошибок.

Вот например, образец произвольного описания
Цитировать
Термофиксационная камера
•   описание процесса
Термофиксационная камера предназначена для фиксации красителя на волокне с помощью горячего воздуха температурой 160 ÷ 180С. Нагрев воздуха осуществляется паровым калорифером и ТЭНом (теплоэлектронагреватель). Фиксация красителя в волокне после печатания проводится насыщенным водяным или перегретым паром, сухим горячим воздухом. В зависимости от реакционной способности активных красителей и температуры фиксации (100 - 200°C) продолжительность тепловой обработки колеблется от 30 с до 5 – 10 мин. Печатная краска обычно содержит краситель, бикарбонат натрия, мочевину, лудигол, загуститель и воду. В качестве загущающих веществ используют альгинат натрия, а также эфиры крахмала и целлюлозы.

•   выход процесса:
Ткань с зафиксированным красителем ,

•   входы процесса:
Бесцветная ткань
Краска(краситель, бикарбонат натрия, мочевина, лудигол, загуститель и вода)

•   управление процесса:
Технологическая схема процесса
Температура в камере 170 ± 5С
Давления на паропроводе – не менее 0,5 МПа
Давление пара перед калорифером 0,5 ± 0,05 МПа

•   механизмы процесса:
Электроэнергия
Пар
ТЭН(теплоэлектронагреватель)
Паровой калорифер
Механизм передвижения ткани

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

А вы как думаете?

Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 »