226

ПО Аналитика / Re: Управление изменениями требований

« : 01 Октября 2017, 00:13:54 »

И тут везде одно и то же: один ВИ и два связанных с ним ДЛ. В каждом случае чеккер прочтёт модель с одинаковым смыслом.

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

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

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

227

Проектирование / Re: Математическое обоснование S.O.L.I.D принципов

« : 30 Сентября 2017, 22:11:17 »

В интернете нельзя будет почитать статью?

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

228

ПО Аналитика / Re: Управление изменениями требований

« : 30 Сентября 2017, 21:54:52 »

Видение такого известного популяризатора стандарта UML как Kirill Fakhroutdinov проиллюстрировано примером на его сайте:
http://www.uml-diagrams.org/bank-atm-uml-use-case-diagram-example.html
На минуту представим себя на планете, где банкоматы выдают деньги в обход банка. Или силами, почерпнутыми у Арлоу и Нейштадта на минуту обобщим Customer и Bank и "исправим" диаграмму. По-моему, неплохая выходит планета. Уже лечу к ней.

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

229

ПО Аналитика / Re: Управление изменениями требований

« : 30 Сентября 2017, 21:48:14 »

Думаю, что утверждение про то, что по стандарту нельзя однозначное и прямое толкование найти, следует обосновать. Сделайте это, а потом я прилечу и с ведомым мне сарказмом проверю Ваше обоснование на прочность.

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

230

ПО Аналитика / Re: Управление изменениями требований

« : 29 Сентября 2017, 13:36:38 »

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

231

ПО Аналитика / Re: Управление изменениями требований

« : 28 Сентября 2017, 23:05:45 »

Давайте её истолкуем в предложенном ключе: либо клиент договаривается о кредите без супервайзора, либо супервайзор договаривается о кредите без клиента якобы в рамках разных сценариев одного ВИ. Выйдет ещё более смешной язык, похожий на UML. Косяк диаграммы пропатчат в оисании? Не, не думаю. Если б так, то описание вытесняет диаграмму UML. Давайте её из ролика "вытеснять".

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

Но. Возьмем таких авторитетов UML как Арлоу и Нейшдат (в своей книге uml2 и UP) в разделе 5.2 описывают как возникает обобщение (кстати ни в руководстве по UML2, ни в книге Рамбо и Блаха, почти ничего об этом не пишется).



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

232

ПО Аналитика / Re: Управление изменениями требований

« : 28 Сентября 2017, 17:56:00 »

НЛО, а вот насколько все-таки Ваше утверждение справедливо. Определяет ли стандарт каким образом интерпретировать такие ситуации. Ведь ВИ  - это набор сценариев, если в одном участвует один тип пользователя, в другом другой?

233

Sparx / Учебные материалы по использованию Sparx Enterprise Architect

« : 28 Сентября 2017, 10:33:55 »

Компания 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

234

Проектирование / Re: Математическое обоснование S.O.L.I.D принципов

« : 22 Сентября 2017, 09:57:31 »

А как связаны между собой SOLID-принципы и процесс разработки ПО?
Ведь SOLID-принципы, насколько я знаю, имеют отношение чисто к построению программного кода.
И с процессом разработки ПО не связаны.

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

235

Задачи студентов / Re: Отношение между классами

« : 21 Сентября 2017, 17:18:33 »

Да, оставим почки человеку.

236

Системный Анализ и Требования / Re: Техническое задание на АС и должностные инструкции

« : 21 Сентября 2017, 17:16:14 »

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

Вы пишите - разработать программный модуль - почему 19 гост не подходит? Насколько я вижу - это расширение существующих возможностей. Другое дело, если под программный модулем Вы тут понимаете разработки различных частей системы: клиентской и серверной как минимум.

237

Системный Анализ и Требования / Re: Техническое задание на АС и должностные инструкции

« : 21 Сентября 2017, 17:12:19 »

То есть на первом месте стоит не вопрос в каком виде и в какой форме делать документацию (в ворде или в вики), а вопрос - как она должна быть структурирована.

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

Вот отсюда и получите структуру. ТЗ по ГОСТ  - это задание на выполнение работ, а Вам насколько я понимаю нужно зафиксировать результат реализации и вопросы организации и внедрения решения, так что пакет документов может быть более широк.

238

Системный Анализ и Требования / Re: Техническое задание на АС и должностные инструкции

« : 21 Сентября 2017, 10:13:12 »

Попробуйте посмотреть ГОСТ 19, если Вам так важно делать по какому-то стандарту. Если нет, почему- бы Вам не разработать собственный шаблон документа и не использовать его. В конце концов, Вам же нужно внедрить и довести до всех это внедрение. Почему бы не организовать такую документацию на wiki?

Можно вообще реализовать в каком-то инструменте типа ЕА модель БП и "навешать" на каждое действие и совокупность действий инструкции по внедрению и использованию.

239

Задачи студентов / Re: Отношение между классами

« : 19 Сентября 2017, 22:36:48 »

А чего композиция? Уж тогда агрегация

240

Задачи студентов / Re: Отношение между классами

« : 18 Сентября 2017, 14:37:19 »

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

Т.е. без контекста не обойтись. Однако в нашем случае мы все-таки говорим не о конкртеной машине и ее конкретных колесах, а об данных (или как тут некто Марк Мельник любит повторят) объектах учета.

В такой концепции возможно, колеса должны просто идентифицироваться тем автомобилем, с которым они были собраны при комплектации. Т.е. до сборки, колеса шли как отдельные, после сборки стали идентифицироваться иначе. Хотя наверняка у колеса есть свой ID, иначе что-то криминалисты распутывали.