Комментарии 29
UML состоит из множества диаграмм. Каждая из которых подчиняется своим правилам, использует элементы и стрелки в своем понимании. И со стороны выглядит это не как унифицированный язык, а как набор из различных представлений, который часто преподносится как возможность посмотреть на предметную область с различных точек зрения.
Не совсем так. UML предлагает «нотации по умолчанию», но так так же сказано «Вы можете определеять свои нотации для UML диаграмм. Только опубликуйте глоссарий, что бы ваши картинки могли понимать другие».
Так что никто не запрещает сделать свои диаграммы UML в нужном представлении.
А если учесть, что инструменты по разному могут разрешать рисовать диграммы, то эта возможность и так используется.
Попробуйте скрестить диаграмму состояний и диаграмму последовательности, у них одинаковые стрелки обозначают разные вещи.
7.7.4 Notation
A Dependency is shown as a dashed arrow between two model Elements. The model Element at the tail of the arrow (the client) depends on the model Element at the arrowhead (the supplier). The arrow may be labeled with an optional keyword or stereotype and an optional name (see Figure 7.18).
…
A Connector is drawn using similar notation to that for Association (see 11.5.4). The optional name string of the
Connector obeys the following syntax:
::= ( [ ] ’:’ ) | ([ ] ’:’ ) | [ ]
where is the name of the Connector, and or is the name of the Association or AssociationClass, respectively, that is its type. A stereotype keyword within guillemets may be placed above or in front of the Connector name.
…
A number of UML standard stereotypes exist that apply to Component. For example, «Subsystem» to model large-scale Components, and «Specification» and «Realization» to model Components with distinct specification and realization definitions, where one specification may have multiple realizations (see the Standard Profiles).
К примеру… Лишь бы хватило фантазии.
Есть бредовая идея взять все эти XML подобные аннотации от UML до WSDL и реализовать их в виде новой молодежной json-schema, дать на все это редактор который позволит накидывать эти схемы + вертеть их с каких хочешь ракурсов.
json-schema-hub который будет их хранить и несколько библиотек (автоматическая генерация структур, автоматическая интеграция) для кучи языков.
В итоге у нас буду в одном месте
- форматы данных
- форматы структур данных
- схемы хранилищ данных
- описания процессов над данными
- ссылки на готовые реализации этих процессов на любой вкус и цвет
- описания какие процессы на каком сервисе расположены
Не совсем уловил, почему для использования «Умение продавать» пришлось завести «Потребность покупать» и «Желание продавать»?
Взаимодействие через «одно имя» не подходит?
Именно этот момент мне и показался «сложным».
Это да. Хорошо, что есть еще и функциональный подход!
PS: Ведете в сторону ArchiMate или куда-то еще?
Взаимодействие через «одно имя» не подходит?
Именно этот момент мне и показался «сложным».
На слайде о сервис-ориентированной архитектуре я рассказал о двух абстракциях: Процесс и Сервис. Рассматривать и описывать их через призму объектно-ориентированного подхода является, мягко говоря, напряженной задачей.
Это да. Хорошо, что есть еще и функциональный подход!
PS: Ведете в сторону ArchiMate или куда-то еще?
Всё это мнимое многообразие говорит только об одном — для моделирования программных систем пока так и нет удобного и понятного большинству инструмента.
Поэтому ждём, надеемся и верим, что в полутёмном сарае на окраине пока неизвестной никому деревушки уже заканчивает свою гениальную работу очередной(ая) самоучка.
Где жы ты наш, герой?
Так себе аналогия, но близко по духу ...
Вспомните внешность первых «умных» телефонов — каждый производитель изголялся как мог, придумывая всё новые формы и кнопочки. А потом пришёл Apple… и ввёл фактически стандарт современного смартфона.
Поэтому ждём, надеемся и верим, что в полутёмном сарае на окраине пока неизвестной никому деревушки уже заканчивает свою гениальную работу очередной(ая) самоучка.
Где жы ты наш, герой?
Пока стоимость написания программной системы на ЯП будет такой же (если не ниже), моделирования программной системы (в любом виде), этого не случиться никогда.
Грубо говоря, сейчас проще сделать MVP и допилить, до нужного состояния.
Чем построить в начале модель, по которой будет создано ПО.
Все что сложнее простого рисунка на салфетке, будет дичайшим оверхедом.
Грубо говоря, сейчас проще сделать MVP и допилить, до нужного состояния.
Чем построить в начале модель, по которой будет создано ПО.
Все что сложнее простого рисунка на салфетке, будет дичайшим оверхедом.
Все что сложнее простого рисунка на салфетке, будет дичайшим оверхедом.
В принципе справедливо, но лучше все таки поместить эти записи в какую либо систему документации.
А так да, можно построить целую систему на бумаге но её еще нужно и реализовать, в итоге получается двойная работа, плюс при реализации всегда всплывают нюансы не учтенные в основной модели и нужно будет опять обновлять модель.
Можно создать систему которая на основе модели уже генерирует готовый софт. Правда из всех похожих систем я видел только OpenESB и Camunda Workflow Engine.
Первый имеет свой UI для создания модели а вторая использует BPMN и DMN.
Оно даже как-то работает но вот ресурсов на поддержку всего этого добра уходит знатное количество.
Грубо говоря, сейчас проще сделать MVP и допилить, до нужного состояния.
Чем построить в начале модель, по которой будет создано ПО.
Все что сложнее простого рисунка на салфетке, будет дичайшим оверхедом.
А давайте посчитаем стоимости? Стоимость дизайна, стоимость имплементации, стоимость тестирования, стоимость передачи знаний. причем давайте распишем отдельно по статьям — сколько ушло на митинги, сколько ушло «объяснить на пальцах», сколько ушло объяснить тестерам, сколько ушло пофиксить «ну это же очевидно». Причем эти расходы растут далеко не пропорционально и чем дальше тем хуже. Были возможности детально сравнить бюджеты весьма сходных проектов длительностью более года сделанные с разными подходами «Че там делать? фигня вопрос» и «А давайте посмотрим внимательно что мы будем делать и как ?».
Сколько раз было: получаешь легаси код — и месяц-другой разгребаешься «а что это такое ?», потом месяца 3..6 отлавливаешь «с какого ^%@!# перестало работать ?!»
Сколько раз было — приходит новый человек и раньше чем через масяц… два его нельзя в код пускать, потому что «объяснять некому, а Вася которых это делал сейчас в отпуске..»
Лично видел системы — забыли договориться о… форматах даты, о кодировке, о генерации ошибок, о мультиязычности и т.д. и это после полутора лет разработки!
Ну а че? MVP работает же, а заказчик в шоке «как все переписать и через пол года релиз, если я уже завершил переговоры с клиентом о покупке?!»
Это все прикольно, если оплачиваешь не из своего кармана, через год планируешь увольняться «с этой галеры» и т.д.
Это прикольно, если хочешь на себя все «завязать» «А кто меня уволит, если никто не знает кроме меня, как ЭТО работает ?!» и т.д.
И сравните с передачей клиенту для приемки после третьего тестового прогона у QA и прохождения с первого раза UAT продукта который разрабатывался порядка 8 месяцев, а вновь нанятые люди, посмотрев «веселы картинки» через неделю в проект добавляли свой код никого не отвлекая вопросами, кроме «А почему именно такое решение и дизайн выбрали ?»
Э-э-э 0 :-)
Т.к. MVP должен быть готов как можно раньше и сразу показан клиенту, чтобы получить обратную связь.
При этом понятие «релиз» нет. Есть понятие «развитие».
Т.е. у заказчика всегда есть что-то работающее, которое постоянно развивается.
При этом не требуется в начале пол года сбора требований, потом пол года на написание спецификаций, чтобы за пару месяцев программисты в мыле не выкатили коричневую субстанцию, которая никому не нужна. :-)
Т.к. MVP должен быть готов как можно раньше и сразу показан клиенту, чтобы получить обратную связь.
При этом понятие «релиз» нет. Есть понятие «развитие».
Т.е. у заказчика всегда есть что-то работающее, которое постоянно развивается.
При этом не требуется в начале пол года сбора требований, потом пол года на написание спецификаций, чтобы за пару месяцев программисты в мыле не выкатили коричневую субстанцию, которая никому не нужна. :-)
При этом не требуется в начале пол года сбора требований, потом пол года на написание спецификаций, чтобы за пару месяцев программисты в мыле не выкатили коричневую субстанцию, которая никому не нужна. :-)
Что пол года не требуется — согласен.
Что пол года не требуется — не согласен.
На этапе сбора формализация требований(ожиданий ?) позволяет найти проблемы и слабые места без написания кода, что сказывается на ожиданиях «А когда будет MVP и что от него ожидать?» и «А сколько это будет стоить и за чей счет банкет ?»
При этом понятие «релиз» нет. Есть понятие «развитие».
Да да… Все это ровно до первого счета «за работу» и вопроса «Остап Ибрагимович, а когда мы будем делить наши деньги ?» Вы, наверное, никогда не отчитывались инвестору еженедельно «что мы сделали и нафига...»? :)
Зачем разводить схоластику и подсчитывать количество ангелов на кончике иглы,
когда можно быстро сделать Proof of Concept?
И уже на реально работающем приложении узнать что нравиться заказчику, а что нет.
При этом стоимость абстрактного моделирования и/или «сбора данных» не сильно дешевле, чем написание прототипа. :-)
когда можно быстро сделать Proof of Concept?
И уже на реально работающем приложении узнать что нравиться заказчику, а что нет.
При этом стоимость абстрактного моделирования и/или «сбора данных» не сильно дешевле, чем написание прототипа. :-)
Тут думаю важно понимать что разрабатываем, если лендинг или интернет магазин — то действительно на кой нам детальная спецификация проекта.
Точнее спецификация есть — это выписка из брифа с клиентом которая по сути и тз и спецификация.
Другое дело если мы делаем какую либо небольшую информационную систему. Тут уже нужны спецификации — но не обязательно делать их на всю систему — достаточно на критичные модули. Остальное на салфетке и скрины салфетки в систему документации.
Если же нам нужна отказоустойчивая, масштабируемая, инфраструктурная и стабильная система — вроде тех что запускают ракеты/управляют самолетами, кораблями, поездами, линиями связи/медицинская система.
Тут уже полу-мерами не обойтись — ВСЯ система должна быть предварительно смоделирована от веб-портала до последнего микроконтроллера в датчике давления, ВСЕ реализации должны соответствовать спецификации чтобы дать гарантию этого — ВСЕ части системы должны быть обмазаны тоннами авто-тестов, защитным программированием и документацией.
В противном случае — получим кучу трупов, миллиарды баксов убытков и громкое судебное дело с несколькими пожизненными сроками.
Тут думаю важно понимать что разрабатываем, если лендинг или интернет магазин — то действительно на кой нам детальная спецификация проекта.
Юристы объяснят, когда когда клиент с серьезным выражением лица скажет «нифига не работет, я не то хотел и меня не так поняли и платить пока не переделаете не буду». А в суде выяснится, что предмета договора нет, как и критериев приемки. Но это не тот случай.
И уже на реально работающем приложении узнать что нравиться заказчику, а что нет.
Оплачивать удовлетворения любопытство заказчика будете из своего кармана?
При этом стоимость абстрактного моделирования и/или «сбора данных» не сильно дешевле, чем написание прототипа. :-)
За чей счет банкет? Если за счет исполнителя — одно дело. Если за счет заказчика с почасовой оплатой (без учета результата) — другое дело :)
Самое забавное, что и после прототипа вы обязаны будете заняться фискацией ожиданий и требований клиента, заняться передачей знаний другим участника проекта, заняться отслеживанием последствий «а вот тут давайте сделаем так...» и т.д. Экономия дизайна выльется в оплату QA, оплату разработчиков, выяснения «а как надо было», только не в начале проекта\итерации а в конце, и задействовано будет не пару человек а десяток другой и все это надо будет еще координировать.
Стоимость дизайна (BA и архитектура) порядка 5.10% бюджета времени проекта. Это не безумные деньги и не дофига времени.
Прототип и его изменения — это и есть фиксация ожиданий клиента.
Точнее это одна их стадий итеративного процесса разработки.
Дизайн, в процессе может изменяться, да и как вообще цель приложения.
Соответственно должна быть и изменена архитектура.
Т.к. заказчик может и не знать «чего он хочет».
Точнее он знает, что «хочет зашибись».
Но как сделать чтобы было «зашибись» он не знает.
А вы у него спрашиваете «куда пришивать пуговицу». :-)
Точнее это одна их стадий итеративного процесса разработки.
Дизайн, в процессе может изменяться, да и как вообще цель приложения.
Соответственно должна быть и изменена архитектура.
Т.к. заказчик может и не знать «чего он хочет».
Точнее он знает, что «хочет зашибись».
Но как сделать чтобы было «зашибись» он не знает.
А вы у него спрашиваете «куда пришивать пуговицу». :-)
Прототип и его изменения — это и есть фиксация ожиданий клиента.
Точнее это одна их стадий итеративного процесса разработки.
Вроде бы «процесс» и «результат» это несколько разные вещи.
Дизайн, в процессе может изменяться, да и как вообще цель приложения.
Соответственно должна быть и изменена архитектура.
Значит открываем «бумажку» и вычеркиваем не нужное, «рисуем нужное», сравниваем — получаем вменяемое объективное обоснование для оценки «сколько будет стоить».
Т.к. заказчик может и не знать «чего он хочет».
Точнее он знает, что «хочет зашибись».
И как это противоречит «давайте обсудим и зафиксируем»? Т.е вместо того что бы за минут 10 зарисовать форму редактирвание позиции справочника или записать список полей для отчета, вы будете 8 часов ее ваять, потом разворачивать, потом сажать клиента рядом и тыкая пальцем в экран спрашивать каких полей не хватает, на ходу их добавляя и перезапуская код? Вы серьезно? :) А если нужно мнение 5 человек вы будете каждого сажать рядом с собой, потом бегать за каждым и говорить «А Джон сказал что не надо, а Смит сказал что обязательно нужно!» пытаясь 5-ть мнений привести к согласованному состоянию? Потом ходить и до каждого в команде доводить новинку объясняя «почему так»? А потом кто-то задаст Вопрос «Так это же противоречит тому что было 2 недели назад...»
Если этот процесс оплачивается за счет клиента — это шикарная бизнес модель :)
Это не противоречит «давайте обсудим и зафиксируем».
Просто, после «фиксации» половины БП не было никак оговорено, и заказчик считал, что это «само-собой разумеется».
Ну или еще веселее, пока «обсуждали и фиксировали» сменилось руководство, законодательство и т.д. И вот…
ИМХО, пока заказчик не «потрогает продукт», он в принципе не может сказать, правильно его поняли или нет. :-)
Просто, после «фиксации» половины БП не было никак оговорено, и заказчик считал, что это «само-собой разумеется».
Ну или еще веселее, пока «обсуждали и фиксировали» сменилось руководство, законодательство и т.д. И вот…
ИМХО, пока заказчик не «потрогает продукт», он в принципе не может сказать, правильно его поняли или нет. :-)
ИМХО, пока заказчик не «потрогает продукт», он в принципе не может сказать, правильно его поняли или нет. :-)
Я Вас, наверное удивлю, но есть такая работа у менеджера проекта называется «управление ожиданиями». Из моего опыт если ты сажешь человека рядом и начинаешь с ним работать, показывая «что будет» и потом начинаешь «сделать как договорились» — таких проблем нет. Понятно что это не в первую неделю доверие (но эт уже психология), но через месяц сравнивая «мы оговорили» и «я могу потрогать» — 8 и 10 впечатляются и довольны (понимают свой профит в виде экономии времени и оправданных ожиданий), а 2 из 10 сначала пытаются «биться в истерике» (по раздолбайски отнеслись к предоставлению данных), но получив по «наглой рыжей морде» резко становятся «смирными» и чудесным образом у них наступает «прояснение в мозгах», пропадает «склероз» и наступают прочие «улучшения»
P.S.Не вижу смысла самому себе создавать трудности, а потом мужественно их преодолевать оправдывая свое раздолбайство.
Я хочу попить пиво, повялаться на пляжике, позниматься в зале и погонять на вело, а не сидеть в офисе с головой «набитой опилками» или устраивать разборки и митинги по телефону по ночам.
Со стороны может эта романтика впечатляет «рвать на груди рубаху бросаясь в жестокий бой», но как по мне — это некомпетентность и безграмотность:)
ИМХО, пока заказчик не «потрогает продукт», он в принципе не может сказать, правильно его поняли или нет. :-)
С этим можно согласиться. Но, исходя из практики, лучше крайностей избегать. Такими крайностями являются салфетка и детальное ТЗ по ГОСТ :)
Ну вот, к примеру, недавно делал проект. На придумывание и описание архитектуры ушло несколько часов, потом часов 50 на реализацию:
Без предварительного моделирования даже и не знаю, как бы написал сие.
Бонус #1. Если потребуется кому-то пояснить, как это работает, будет гораздо проще.
Бонус #2. Исходя из практики, через несколько месяцев во многом забуду, как это работает, по схеме будет гораздо легче вспомнить. А салфетка к тому времени уже потеряется/износится.
Без предварительного моделирования даже и не знаю, как бы написал сие.
Бонус #1. Если потребуется кому-то пояснить, как это работает, будет гораздо проще.
Бонус #2. Исходя из практики, через несколько месяцев во многом забуду, как это работает, по схеме будет гораздо легче вспомнить. А салфетка к тому времени уже потеряется/износится.
Отличная статья (точнее: так как придерживаюсь подобных взглядов, то считаю статью отличной).
Перестал пользоваться UML уже достаточно давно, хотя глубоко изучал все виды диаграмм на специализированных курсах и пытался использовать в практике. Перестал по причине того, что все варианты «не про то», бизнес-пользователям непонятно, разработчикам непонятно, да и самим аналитикам не всегда понятно. Плюс сильный редукционизм (упрощение) моделей UML не позволяет адекватно описывать поведение и реального мира и программной модели.
Мои бизнес пользователи (отдел стандартизации, отдел развития производственной системы) понимают EPC, прямо стандарты у нас пишутся в такой нотации. А обычное производство, снабжение, финансы (начальники цехов, отделов, мастера, начальники участков) понимают нормально прямоугольники и линии со стрелками. Самая популярная нотация на предприятии: вожу руками в воздухе рядом с доской, на которой нарисованы подписанные прямоугольники и стрелочки.
При этом реальный мир — мир взаимодействия, мир интерфейсов. Причем взаимодействие достаточно сложное, многоуровневое и с большим количеством ветвлений. Пока для этого лучше всего подходит простой текст с добавлением прямоугольников со стрелками. Мне представляется, что нотация будущего должна быть близка к семантическому графу, где ребро=взаимодействие, достаточно сложная сущность. ИМХО.
Перестал пользоваться UML уже достаточно давно, хотя глубоко изучал все виды диаграмм на специализированных курсах и пытался использовать в практике. Перестал по причине того, что все варианты «не про то», бизнес-пользователям непонятно, разработчикам непонятно, да и самим аналитикам не всегда понятно. Плюс сильный редукционизм (упрощение) моделей UML не позволяет адекватно описывать поведение и реального мира и программной модели.
Мои бизнес пользователи (отдел стандартизации, отдел развития производственной системы) понимают EPC, прямо стандарты у нас пишутся в такой нотации. А обычное производство, снабжение, финансы (начальники цехов, отделов, мастера, начальники участков) понимают нормально прямоугольники и линии со стрелками. Самая популярная нотация на предприятии: вожу руками в воздухе рядом с доской, на которой нарисованы подписанные прямоугольники и стрелочки.
При этом реальный мир — мир взаимодействия, мир интерфейсов. Причем взаимодействие достаточно сложное, многоуровневое и с большим количеством ветвлений. Пока для этого лучше всего подходит простой текст с добавлением прямоугольников со стрелками. Мне представляется, что нотация будущего должна быть близка к семантическому графу, где ребро=взаимодействие, достаточно сложная сущность. ИМХО.
Для программистов поддержка осуществляется только фреймворками, например, Java Enterprise Edition или Spring.
А сможете дать отсылку к нотации/подходу/средству/инструменту/книге/статье, где рассматривается проектирование системы уже учитывая наличие спринга?
Хочу глубже вникнуть в проблематику, которую Вы привели в статье.
Никто такие книги и инструменты писать не будет, потому что пока это будут создаваться всё изменится, информационные технологии развиваются стремительно. Никто сейчас не проводит серьезных доказательств работоспособности моделей. Это инженерный подход, он сейчас как бы «не в моде» (Old School). Слишком неудобен для понимания новому поколению программистов. Сейчас программирование преподносится не как инженерия, а как искусство.
Что касается спринга, то максимум на что вы можете рассчитывать — это родная документация по нему и статьи в стиле Best Practices от авторитетных авторов.
Что касается спринга, то максимум на что вы можете рассчитывать — это родная документация по нему и статьи в стиле Best Practices от авторитетных авторов.
А смысл. Когда ПО и есть модель?
Грубо говоря модель ПО это и есть ПО.
И гораздо дешевле сделать proof on concept.
Чем строить математическую модель «на бумажке», когда можно её же реализовать на ЯП.
Это для материального мира создание модели «в натуральную величину» дорого.
Поэтому в начале «рисуют на бумаге»
И все равно прототипы всегда «доводятся напильником».
В ПО можно шаг «нарисовать на бумаге» можно пропустить и сразу приступить к шагу «доработать напильником».
<:o)
Грубо говоря модель ПО это и есть ПО.
И гораздо дешевле сделать proof on concept.
Чем строить математическую модель «на бумажке», когда можно её же реализовать на ЯП.
Это для материального мира создание модели «в натуральную величину» дорого.
Поэтому в начале «рисуют на бумаге»
И все равно прототипы всегда «доводятся напильником».
В ПО можно шаг «нарисовать на бумаге» можно пропустить и сразу приступить к шагу «доработать напильником».
<:o)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
«UML. Взгляд со стороны» или «Как UML удерживает аналитиков в прошлом»