В теме 8 ответов, и 6 участников, последнее обновление сделано пользователем 
Герман Шестеров 14 г, 1 мес. назад.
-
Сообщения
-
Все мы знаем насколько велико разнообразие языков и нотаций моделирования, не говоря уже о том, что и моделирование по сути бывает разное. Кто-то проводит все время, моделируя бизнес-процессы; другие заняты моделированием конечных систем: от применения до архитектуры и реализации. Выше, в опросе, я постарался выделить нотации моделирования, наиболее часто используемые в процесс бизнес- и системного анализа. Я далеко не считаю себя специалистом-теоретиком в области моделирования
, поэтому наверняка какие-то упустил. Буду признателен, если вы поделитесь дополнительными вариантами в своих ответах.
Также хотелось бы услышать причины, по которым вы используете ту или иную методику или нотацию.
Что касается меня, то я использую только UML (хотя знаком и умею использовать еще и семейство IDEF, и блок-схемы). UML полностью покрывает нужды, с которыми я сталкиваюсь в процессе работы, при это оставаясь гораздо более мощным языком, чем те же специфические и целевые языки семейства IDEF и flowcharts. Плюс к этому я вполне могу быть уверен, что заказчик гораздо вероятнее знаком с UML, чем с другими нотациями (да и это не всегда бывает нужно — я считаю, что UML довольно интуитивно понятный).
Ну а вы?После непродолжительного гугления мне стало как то неловко, что я использую только UML при работе с требованиями. Честно говоря меня поразило количество существующих языков и нотаций моделирования. Невольно в голову закрадывается вопрос — а действительно ли ULM is a right tool for the job? Получилось так, что большое количество бизнес-аналитиков принимают UML как лучший инструмент моделирования (и я в том числе). Конечно UML неспроста стал столь популярным, но ведь нельзя быть на 100% уверенным пока не попробуешь что-нибудь еще.Меня привлек язык моделирования YAWL, исключительно из-за названия — Yet Another Workflow Language
описание которого доступно по следующей ссылке, может у кого то найдеься время и желание ознакомиться.Я тоже использую UML и блок-схемы.
Плюс к этому я могу использовать (и такое бывает довольно часто) нечто свое, любые картинки и образы, суррогат других языков и своего воображения, который поможет мне донести мысль до нужного человека или группы людей. Хотя, вероятно, все такие картинки в основной своей массе можно назвать "блок-схемами".Хочу к этой теме добавить еще интересную ссылочку на всеми любимую википедию, которая помогла мне при создании этой темы — http://en.wikipedia.org/wiki/Modeling_language. На мой взгляд для первоначального ознакомления a must всем, дабы не фокусироваться только на том, что мы используем в работе, а быть хотя бы осведомленным, чем вообще пользуются люди.Уважаемые коллеги, UML — унифицированный язык визуального моделирования (по крайней мере его версия 1.5, а скоро или уже, и версии 2.0 и выше) принят международным консорциумом OMG (основная задача которого принятие стандартов) в качестве международного стандарта для разработчиков объектно-ориентированных программных и микропроцессорных систем. Фактически, визуальное моделирование, это построение чертежей программной системы с разных точек зрения. Другой подобной системы моделирования, позволяющей построить "чертежи" программной системы с разных точек зрения и обеспечить тем самым полную поддержку процесса разработки, увы нет. На вопрос нужно ли вместе с UML использовать другие нотации, чтобы улучшить возможности моделирования я отвечу нет, если речь идет об объектно-ориентированной программной системе.
На вопрос можно ли при построении диаграмм UML отступать от правил и стандартов, внося что-то свое, элементы из диаграмм другого типа или дополнять их другими нотациями, я отвечу вопросом — а можно ли, например, в чертежах схем электрических принципиальных использовать элементы, например, из чертежей зданий и сооружений?…UML — унифицированный язык визуального моделирования (по крайней мере его версия 1.5, а скоро или уже, и версии 2.0 и выше) принят международным консорциумом OMG (основная задача которого принятие стандартов) в качестве международного стандарта для разработчиков объектно-ориентированных программных и микропроцессорных систем…
Простите, на мой взгляд (возможно, — ошибочный) здесь небольшая неточность. Действительно, OMG имеет право непосредственно писать стандарты для ISO. И потому UML (v.1.4.2) соответствует стандарту ISO/IEC 19501:2005. Однако, этот стандарт лишь формализует собственно UML, а не является стандартом для разработчиков ООП вообще.
Достаточно взглянуть на требования к соискателям на вакансии аналитиков, чтобы понять, что UML — хотя и является преобладающим в индустрии, всё же — не единственная используемая нотация.
Хотя моё личное мнение: UML, несмотря на все его недостатки, — имеет всё же больше достоинств, чем любые другие языки моделирования.
Опять же моё личное мнение: основная цель аналитика — описать систему понятно. И эта цель оправдывает любые средства (пусть даже и немного кустарные).Соглашусь с Вами UML, действительно не единственный стандарт и нотация для разработчиков, как и унифицированный процесс не единственный стандартизированный, однако его достоинства это возможность моделирования предметной области и программной системы с разных представлений и заточенность под CASE-средства делают его самым распространенным.
По поводу мысли, что:основная цель аналитика — описать систему понятно. И эта цель оправдывает любые средства (пусть даже и немного кустарные).
я бы мог добавить, что "кустарные средства" могут быть оправданы при относительно небольших проектах, выполняемых в рамках одного сплоченного коллектива разработчиков, как только рамки проекта становятся такими, что один разработчик непосредственно не встречается с другим, или проект выходит на международный уровень, то по моему мнению, применение "кустарных" средств и решений уже не желательно. И, тоже мое мнение, стандартной нотации UML и стереотипов достаточно для понятного описания 99,9% проектов.
Мне тоже раньше, так казалось, пока в 2002 году я не побывал на стенде Rational Software на выставке CeBIT в Ганновере.Потихоньку осваиваю новые ветки форума ;) читаю в день по 2…
я тоже использую UML и еще мне настоятельно было рекомендовано использовать SADT|IDEF0.
Кстати, для описания бизнес-процессов (то есть для написания технического проекта, в котором основной контент составляет описание процессов) SADT можно использовать как ведущую нотацию, а уже в спецификациях — где описываются архитектура, интерфейсы, функции и варианты использования — отлично годятся UML.Но это мой опыт, возможно, он не учитывает каких-то аспектов или принципиальных вещей.
IDEF0 — штука довольно интересная и полезная. Попробуйте еще глянуть на BPMN в дополнение (или, отчасти, в качестве замены) к SADT.
Вы должны авторизироваться для ответа в этой теме.
