691

Конференции Семинары и Тренинги / Re: Вебинар "Введение в разработку Технического задания по ГОСТ 34"

« : 11 Июля 2014, 15:58:07 »

А зачем заказчику знать разработку ТЗ по ГОСТ 34? Особенно если он его не просит?

692

Примеры / Re: Диаграмма классов - подкорректируйте\ подскажите

« : 11 Июля 2014, 15:55:50 »

На деле страхуемый, это тот кого страхуют,

на вопрос кого отвечает только одушевленный предмет, т.е.

это может быть либо клиент, с его данными которые занесутся в договор через этот класс,

и никак

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

А вот это утверждение может моделироваться

так что это страхуемый наследует атрибуты либо из словаря либо из клиента.

отношением обобщения а именно: Словари - Это Страхуемый или Клиент - это Страхуемый, т.е. страхуемый либо что-то из Фигнушки (смотри мой предыдущий пост) либо все из Клиента

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

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

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

693

Примеры / Re: Диаграмма классов - подкорректируйте\ подскажите

« : 11 Июля 2014, 15:45:13 »

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

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

Сидоров Сидор Сидорович
физическое лицо
страхует
садовый домик
от пожара

Кто такой Сидоров С.С.?
Это участник договора о страховании, т.е. Клиент, тот кто
1. несет ответственность за оплату страховки
2. получает деньги в случае удовлетворения страхового случая

При этом это Физическое лицо.
По семантике Клиент - это абстрактный класс, т.е. Клиент.
Физическое лицо и Юридическое лицо - это Клиент. По факту обобщения - уточнения, Клиент конкретизируется или в Юрлицо, или в Физ.лицо, но не как одновременно.

Поэтому никакой композиции между Клиентом и Юридическим и Физическим лицом быть не может.

Далее. Стахователь, Выгодоприобретатель, Страхуемый - это Клиент и это набор обощения, т.е. одновременно некий абстрактный клиент не может быть Страхователем и Выгодоприобретателем. и Т.п. Так что Ваше пояснение "может быть одним и тем же" в данном случае некорректно.

Использование композиции также не очень корректно или совсем некорректно.
1. Продукт - Договор - что это за связь? Каков ее смысл? Можно догадаться, что договор заключается на определенный продукт. Один и тот же продукт может быть предметом разных договоров. Гуд, но при чем тут КОМПОЗИЦИЯ? Идем и изучаем что такое композиция.
А в данном случае просто оставить ассоциацию следует!
2. Менеджер - Договор - опять некорректное использование композиции - оставьте только ассоциацию
3. Договор - Страхователь, Договор - Выгодоприобретатель, Договор - Страхуемый (а почему не страхуемое?) - это не композиции! Даже если Вы пытаетесь таким образом передать идентифицирующую связь принадлежности!
4. Клиент - Юр Лицо, Клиент - Физ лицо - уже говори выше - это не композиция, а обощение
5. Словари - вообще выпадает из общего стиля моделирования предметной области. С тем же успехом можно написать Фигнюшки
6. Страхуемый - ну такой непонятный класс, который одновременно наследует свойства каких-то Словарей и Клиента (в общем-то одушевленного лица, ну или обладающий поведением) - выглядит весьма странно, если не сказать забавно - это явная попутка забежать вперед и навязать некую реализацию.

Мой Вам совет, приведите структуру (пример) разных договоров, будет проще Вам чем-то помочь.



Вообще непонятно, зачем связывать разные по своей роли сущности одни классом Клиент. Посмотрите в словаре, что такое Клиент.

694

Примеры / Re: Диаграмма классов - подкорректируйте\ подскажите

« : 10 Июля 2014, 21:52:11 »

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

А в чем конкретно Вы сомневаетесь? Какие связи вызывают у Вас сомнение правильности?

Не знаю как определить динамический выбор класса ведь страхуемый может быть как наследником класса "клиент" так и просто набором полей из справочника.

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

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

Мне сложно дать точные рекомендации, у меня мало информации. Посмотрите на примеры договоров.

695

Методологии / Re: Комментарии к переводу SWEBOK

« : 08 Июля 2014, 11:58:17 »

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

696

Обсуждение статей / Re: Включение вариантов использования

« : 07 Июля 2014, 18:16:14 »

Я новичек в UML, почему в примере 4, ВИ: Найти данные служащего, п.3. Менеджер удаляет данные служащего ?

Это недосмотр при копировании.  п.3 нужно убрать

697

Конференции Семинары и Тренинги / Re: Бесплатный вебинар "Разработка моделей IDEF0 в Cradle"

« : 02 Июля 2014, 22:53:43 »

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

698

Конференции Семинары и Тренинги / Re: Бесплатный вебинар "Разработка моделей IDEF0 в Cradle"

« : 02 Июля 2014, 21:06:37 »

Опубликована первая часть вебинара
http://youtu.be/psKWKuQAQmM

Здравствуйте, Юлия.
Во-первых, спасибо за Ваш труд.
Во-вторых, у меня тоже был вопрос по диаграмме на заставке. Я его задал в комментариях к ролику.
Суть его сводится к тому, что функция "Летать"  преобразует маршрут в расход топлива.
Мне кажется, на входе явно чего-то не хватает. Маршрут- это эквивалент расстояния, но и структура (граф). По моему самого топлива на входе нет. Я ошибаюсь?

699

Идеи и мозговой штурм / Re: Стенография системного аналитика

« : 27 Июня 2014, 14:36:02 »

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

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

Опыт и идеи автора довольно интересны, можно брать на вооружение.

700

ПО Аналитика / Re: ELMA для управления бизнесом. FAQ, новые «фишки», уникальные возможности

« : 22 Июня 2014, 19:20:37 »

1

701

ПО Аналитика / Re: ELMA для управления бизнесом. FAQ, новые «фишки», уникальные возможности

« : 22 Июня 2014, 14:14:44 »

А в конце страницы просто дикая ошибка. Несолидно как-то

702

Задачи студентов / Re: Вариант использования Создать меню

« : 15 Июня 2014, 20:41:20 »

Сергей Мартыненко на текущем ЛАФ устроил мастер-класс по составлению списка вариантов использования. Он оттолкнулся от моего примера опубликованного в начале темы.
Правда я не во всем согласен в том подходе, который рассказывал на ЛАФ Сергей. Позже меня посетила мысль, вспоминание, что я где-то видел этот подход. Стоит наверное высказать его кратко.

По описанию ( в нашем случае использовался пример начала темы) выделялись объекты предметной области и сопутствующие понятия при работе с информацией.
Для каждого объекта применялся CRUDL анализ, напомню Create Read Update Delete(Deactivate) List.
List - вносить в список, перечислять. Отобразить список объектов данного типа.
Для каждого объекта проверяется потребность в CRUDL операции и на этом строится вариант использования или его сценарий.

Насколько я знаю такой подход активно используется (использовался) в базах данных. Можно ли назначать ВИ для каждой такой операции? Мне это показалось не совсем верным.

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

Мой подход:
1. выделить два уровня. Уровень моря и уровень змея.
2. Разделить на множество юзкейсов.

Почему так:
* Текущий ВИ "Создать меню" не проходит проверку на уровень моря

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

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

Мне кажется, ВИ Создать меню (Я бы конечно лучше сказал Создать меню блюд), вполне подойдет к этим критериям. Руководство вполне одобрит, что некто ответственный создает новое меню, это подходит и под описание ЭБП, да и критерий размера тут вполне подходит.

Потому, не соглашусь с критикой Сергея.

* Текущий ВИ не проходит проверку на полноту по методу "объект-действие"

Этого метода я не знаю, возможно это метод CRUDL. Был бы признателен, если Сергей поделится этим знанием.

* При моем подходе SRS будет более устойчива к изменениям

-- Вариант А. Реестр ВИ. (Может быть не самый лучший подход, но достаточно понятный)
1. Управление Меню. Уровень змея [включает в себя все нижеследующие].
2. Создание меню. Уровень моря.
3. Копирование меню. Уровень моря.
4. Просмотр меню. Уровень моря.
5. Редактирование меню. Уровень моря.
6. Просмотр списка меню. Уровень моря.
7. Удаление меню. Уровень моря.

Далее. <<5. Редактирование меню.>> можно оставить как есть, а можно сказать, что включает все операции, кроме операций с блюдами и все пять операций CRUDL с блюдами выписать отдельно. Последнее, на мой взгляд, лучше.

Итого моя рекомендация: Вместо одного ВИ напишите дюжину двух уровней.

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

703

Проектирование / Re: Проектирование БД. Логический уровень

« : 11 Июня 2014, 19:01:07 »

Коллеги, извините, выпал немного из обсуждения вернемся к теме )

Шутить изволите? Выпали из темы эдак на 4 года:)

Речь о чем: в Erwin например есть логический и физический уровень. Физический - это непосредственно сама база данных, ее объекты. Из этой модели в Erwin генерируются скрипты для создания объектов БД (таблиц, сиквенсов, триггеров и т.д), а вот логический уровень на мой взгляд- это попытка в те давние времена (могу ошибиться), когда только зарождалась нотация UML, сделать нечто подобное в том же направлении. 

ERWin появился в 90 годы, ну может чуть раньше. И был ориентирован на создание БД по классическому принципу нормализации отношений. Исходно поддерживались две нотации IDEF1x и Information Engineering. IDEF1x вырос из IDEF1 и заточен под реляционную модель, которая есть суть ЛОГИЧЕСКАЯ модель. Потому логический уровень во многом важен.

Идея UML стала возникать позже, но в ДК UML и в моделях ERWin заложены совершенно иные принципы. Впрочем не будет эту тему развивать.

В настоящее время для описания объектов предметной области я использую UML и, естественно делаю это не в Erwine, а с помощью специализированных продуктов, таких как Enterprise Architect. Структуру базы проектирую в Erwin.

А зачем? Я делаю обычную DDL трансформацию. Вернее делаем два этапа. UML превращаем в модель БД и далее трансформационный код с подключением и выгрузкой в физическую БД. Можно использовать и другие подходы, например, ORM преобразование.

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

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

Так что поймите правильно, я не против создания объектной модели предметной области. Вопрос именно в инструменте. Насколько я знаю, в Power Designer разработчики сделали шаг именно с сторону UML (или скорее даже каких то языковых платформ) и там можно создавать классы и из этого по-моему даже получать исходный код каркаса программы на языке программирования (другой вопрос уже кто и как это использует).

ERWin просто изначально на это не ориентирован. По-моему СА делали какой-то инструмент типа Object Paradigm, но не знаю, какова его судьба.

Цена ERWin, как и Power Designer, астрономическая. Да признаю, PD делает некоторые вещи совсем неплохо.

704

Теория моделирования и нотации / Re: Какие методологии системного анализа вы используете в своей работе?

« : 08 Июня 2014, 21:28:09 »

А может Эд имел в виду статью Методика системного анализа?

Мы же не сам СА обсуждаем, а его методики (-логии)?

Денис, спасибо. Да - я имел в виду эту статью.

705

Теория моделирования и нотации / Re: Какие методологии системного анализа вы используете в своей работе?

« : 07 Июня 2014, 20:50:54 »

Меня интересует ответ на вопрос, применяют ли форумчане такое словосочетание как "методология системного анализа" в своей работе. И если да, то что они под этим понимают. Но, что-то мне подсказывает, что пока ответ отрицательный.

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

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

На википедии вполне доступно предложена эта методология. Ну, а в конкретных приложениях, мы имеем соответствующее наполнение и исполнение.

Но это в теории.