691
Конференции Семинары и Тренинги / Re: Вебинар "Введение в разработку Технического задания по ГОСТ 34"
« : 11 Июля 2014, 15:58:07 »
А зачем заказчику знать разработку ТЗ по ГОСТ 34? Особенно если он его не просит?
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
На деле страхуемый, это тот кого страхуют,на вопрос кого отвечает только одушевленный предмет, т.е.
это может быть либо клиент, с его данными которые занесутся в договор через этот класс,и никак
либо пустые поля котороые заполнятся в этом договоре, но будут получены из словарей.
так что это страхуемый наследует атрибуты либо из словаря либо из клиента.отношением обобщения а именно: Словари - Это Страхуемый или Клиент - это Страхуемый, т.е. страхуемый либо что-то из Фигнушки (смотри мой предыдущий пост) либо все из Клиента
а замена композиции на агрегацию испортит смывсл ведь только при всех заявленных данных договор имеет место быть легетимным, соответственно это как создать документ в котором не все поля со зведочками заполнены. Одного пункта не будет - договор не создастсяПолная каша в голове, при таком рассуждении черные ромбы должны быть прикреплены обратно. Если рассматривать IDEF1x, то между Менеджером, Продуктом и прочими Клиентами и Договором - идентифицирующая связь принадлежности, что означает:
быть может в связи страхуемый - клиент, страхуемый - справочники добавить интерфейс чтоб показать что это скорее получение полей
Начинаю осваивать UML вот набросал диаграмку классов для информационной системы регистрации договоров страховой компании... думается мне не совсем точно определил связи.А в чем конкретно Вы сомневаетесь? Какие связи вызывают у Вас сомнение правильности?
Не знаю как определить динамический выбор класса ведь страхуемый может быть как наследником класса "клиент" так и просто набором полей из справочника.Диаграмма классов - это инструмент отображения статической информации. Динамика (поведение) отображается иными средствами.
Я новичек в UML, почему в примере 4, ВИ: Найти данные служащего, п.3. Менеджер удаляет данные служащего ?Это недосмотр при копировании. п.3 нужно убрать
Опубликована первая часть вебинараЗдравствуйте, Юлия.
http://youtu.be/psKWKuQAQmM
Мой подход:Почему не проходит.
1. выделить два уровня. Уровень моря и уровень змея.
2. Разделить на множество юзкейсов.
Почему так:
* Текущий ВИ "Создать меню" не проходит проверку на уровень моря
* Текущий ВИ не проходит проверку на полноту по методу "объект-действие"Этого метода я не знаю, возможно это метод CRUDL. Был бы признателен, если Сергей поделится этим знанием.
* При моем подходе SRS будет более устойчива к изменениямЯ понимаю, что ты расширил видение задачи. Это хорошо. Хотя исходная задача была иная. При этом в твой список представленный мною ВИ вошел без изменения и превратился в уровень моря, хотя выше ты утверждал иное.
-- Вариант А. Реестр ВИ. (Может быть не самый лучший подход, но достаточно понятный)
1. Управление Меню. Уровень змея [включает в себя все нижеследующие].
2. Создание меню. Уровень моря.
3. Копирование меню. Уровень моря.
4. Просмотр меню. Уровень моря.
5. Редактирование меню. Уровень моря.
6. Просмотр списка меню. Уровень моря.
7. Удаление меню. Уровень моря.
Далее. <<5. Редактирование меню.>> можно оставить как есть, а можно сказать, что включает все операции, кроме операций с блюдами и все пять операций CRUDL с блюдами выписать отдельно. Последнее, на мой взгляд, лучше.
Итого моя рекомендация: Вместо одного ВИ напишите дюжину двух уровней.
Коллеги, извините, выпал немного из обсуждения вернемся к теме )Шутить изволите? Выпали из темы эдак на 4 года:)
Речь о чем: в Erwin например есть логический и физический уровень. Физический - это непосредственно сама база данных, ее объекты. Из этой модели в Erwin генерируются скрипты для создания объектов БД (таблиц, сиквенсов, триггеров и т.д), а вот логический уровень на мой взгляд- это попытка в те давние времена (могу ошибиться), когда только зарождалась нотация UML, сделать нечто подобное в том же направлении.ERWin появился в 90 годы, ну может чуть раньше. И был ориентирован на создание БД по классическому принципу нормализации отношений. Исходно поддерживались две нотации IDEF1x и Information Engineering. IDEF1x вырос из IDEF1 и заточен под реляционную модель, которая есть суть ЛОГИЧЕСКАЯ модель. Потому логический уровень во многом важен.
В настоящее время для описания объектов предметной области я использую UML и, естественно делаю это не в Erwine, а с помощью специализированных продуктов, таких как Enterprise Architect. Структуру базы проектирую в Erwin.А зачем? Я делаю обычную DDL трансформацию. Вернее делаем два этапа. UML превращаем в модель БД и далее трансформационный код с подключением и выгрузкой в физическую БД. Можно использовать и другие подходы, например, ORM преобразование.
Логический слой в модели erwin я выбросил на начальном этапе, за что сейчас и поплатился, но не потому что не вел его, а потому что вообще не создал. В erwin есть возможность некоторой автоматизации путем написания скриптов(например для задания имен связей) и оказалось, что этот механизм вообще не работает, если нет логического слоя модели.Не понял ваших затруднений, если честно. Трансформация в скрипт возможно только для физического уровня, другое дело, что физический уровень можно получать из логического или напрямую ручками.
Так что поймите правильно, я не против создания объектной модели предметной области. Вопрос именно в инструменте. Насколько я знаю, в Power Designer разработчики сделали шаг именно с сторону UML (или скорее даже каких то языковых платформ) и там можно создавать классы и из этого по-моему даже получать исходный код каркаса программы на языке программирования (другой вопрос уже кто и как это использует).ERWin просто изначально на это не ориентирован. По-моему СА делали какой-то инструмент типа Object Paradigm, но не знаю, какова его судьба.
А может Эд имел в виду статью Методика системного анализа?Денис, спасибо. Да - я имел в виду эту статью.
Мы же не сам СА обсуждаем, а его методики (-логии)?
Меня интересует ответ на вопрос, применяют ли форумчане такое словосочетание как "методология системного анализа" в своей работе. И если да, то что они под этим понимают. Но, что-то мне подсказывает, что пока ответ отрицательный.Системный анализ - это методология решения проблем, поиска решений, принятия этого решения с каких-то позиций и критериев.