Форум Сообщества Аналитиков
Общий раздел => Теория моделирования и нотации => Тема начата: Сергей() от 16 Ноября 2012, 10:24:59
-
Здравствуйте!
Я участвую в модификации программы. Есть UML-модель этой программы.
Конкретно в данный момент мне нужно модифицировать одну из процедур.
Проблема в том, что от ее поведения зависят другие методы программы.
То есть она вызывается из других процедур и функций, они в свою очередь также откуда-то вызываются и т.д.
Чтобы учесть все на что может повлиять изменение этой процедуры, я бы хотел составить схему вызовов: методы изобразить квадратиками, и линия со стрелкой показывала бы кто кого вызывает. Но хотелось бы все это сделать в рамках стандарта UML.
Вопрос в том, какая диаграмма в UML больше всего подходит для отображения связей между методами программы, между методами объектов программы?
-
Диаграмма пакетов, но это не принципиально, можно и диаграмму объектов использовать.
-
как вариант, можно и диаграмму последовательности использовать
но надо будет указывать все объекты, из которых вызываются процедуры
-
Диаграмма пакетов, но это не принципиально, можно и диаграмму объектов использовать.
Допустим, надо на диаграмме изобразить что процедура1 вызывает процедуру2, а процедура2 вызывает процедуру3.
1. Если использовать диаграмму пакетов, то непонятно что в нее добавлять. Какими элементами на ней будут представлены процедура1, процедура2 и процедура3?
2. Если использовать диаграмму объектов, то тоже есть проблемы. На диаграмме объектов отображаются экземпляры сущностей\классов модели. Но в модели нашей программы нет таких классов, которые соответствовали процедурам. Можно конечно сделать квадратик объекта и назвать его именем процедуры, но это нарушит понимание всей модели
-
как вариант, можно и диаграмму последовательности использовать
но надо будет указывать все объекты, из которых вызываются процедуры
Согласен, можно использовать диаграмму последовательности.
Но это не очень удобно для моего случая.
Диаграмма последовательности отображает взаимодействие объектов в хронологическом порядке, т.е. во временном аспекте. А в моем случае более важным является структурный аспект, то есть зависимость между процедурами
-
UML разрешает устанавливать ассоциации между двумя операциями, но т.к. нотации для отдельного изображения операции в диаграммах нет, то тут надо немного подумать.
Как вариант, используйте диаграмму активности. Изобразите операции как Action (точнее CallOperationAction) которые вызывают соответствующие операции и между ними уже установите зависимости.
Sparx EnterpriseArchitect поддерживает это с помощью drag&drop.
Для CallOperationAction в скобках указывается класс, операция которого вызывается, и возможно указать название операции, если название действия отлично от него.
-
Изобразите операции как Action (точнее CallOperationAction) которые вызывают соответствующие операции и между ними уже установите зависимости.
А что такое CallOperationAction в переводе на русский?
Просто я UML изучал по книге Буча Г. "Язык UML. Руководство пользователя".
-
Я в принципе написал про это, CallOperationAction (понятие из спецификации UML) это такой Action, который вызывает операцию.
Надеюсь у вас второе издание этой книги, по UML 2.0?
-
Я в принципе написал про это, CallOperationAction (понятие из спецификации UML) это такой Action, который вызывает операцию.
Надеюсь у вас второе издание этой книги, по UML 2.0?
да, второе издание,
только в нем все называется по-русски,
какой перевод в этой книге соответствует CallOperationAction?
-
Диаграмма активности, на ней Action - это Действие
-
Вам шашечки или ехать?
Всё, что вам нужно — это набор прямоугольников со вписанными туда названиями методов и связи между прямоугольниками, показывающими направление вызовов.
Нарисуйте на доске фломастером, сфотографируйте, фотку положите в репозиторий, при изменении перерисуйте.
Если кровь из носу нужно изменить существующую UML-модель программы — задайте этот вопрос автору UML-модели.
-
Все зависит от инструмента, которым вы пользуетесь.
Можно вытащить эту зависимость просто запросами.
Построить матрицу зависимостей
В конце концов сделайте, то что предлагают участники дискуссии.
Следуйте принципу KISS
-
Вам шашечки или ехать?
Всё, что вам нужно — это набор прямоугольников со вписанными туда названиями методов и связи между прямоугольниками, показывающими направление вызовов.
Конечно, для решения моей конкретной задачи, просто набор прямоугольников подойдет.
Но ведь модель создается при помощи определенной стандартной нотации, чтобы ее могли прочитать другие.
И мне хотелось бы, чтобы составленную мной диаграмму могли читать другие программисты, чтобы я ее мог показать им, и обсудить предлагаемое мной решение.
Нарисуйте на доске фломастером, сфотографируйте, фотку положите в репозиторий, при изменении перерисуйте.
Если кровь из носу нужно изменить существующую UML-модель программы — задайте этот вопрос автору UML-модели.
Пока речь идет не об изменении, а о дополнении.
Т.е. хочу добавить в модель диаграмму вызовов процедур
-
Все зависит от инструмента, которым вы пользуетесь.
Пользуюсь Power Desinger
Можно вытащить эту зависимость просто запросами.
Не понял, что значит "вытащить эту зависимость просто запросами"?
В конце концов сделайте, то что предлагают участники дискуссии.
Просто квадратики я уже нарисовал.
Но, я повторюсь, основной вопрос у меня - это знание языка моделирования UML, признанного как наиболее удобного языка моделирования.
Ведь, такая же задача у меня может возникнуть еще не раз.
И мне хотелось бы знать, как правильно на UML изображать зависимости между процедурами.
Следуйте принципу KISS
Для примера, прежде чем пекаря допустят в пекарный цех, чтобы спечь батон, пекарь должен три года учиться в кондитерском училище.
Поэтому, я желаю изучить тонкости UML
Я думаю, что это пригодится
-
Диаграмма активности, на ней Action - это Действие
У меня в Power Desinger в диаграмме активности доступны следующие линии:
1) Flow на закладке "Activity Diagram"
2) Link \ Traceability link на закладке "Standart"
Flow как я понимаю по смыслу не подходит.
Наверное лучше использовать Link.
Как вы думаете?
-
Если вы так хотите изучить UML, то вызовы процедур (чтобы вы не закладывали в это понятие) можно смоделировать диаграммой последовательности или диаграммой коммуникации.
Элементом этих диаграмм являются объекты или линии хизни. Объекты обмениваются собщениями. Сообщения сигналы, которые можно моделирвоать и как вызовы процедур.
-
И мне хотелось бы, чтобы составленную мной диаграмму могли читать другие программисты, чтобы я ее мог показать им, и обсудить предлагаемое мной решение.
Тут такой вопрос: цель в том, чтобы продемонстрировать читателю диаграммы знание UML, или в том, чтобы читатель понял, как это должно работать?
Есть ли уверенность, что другие программисты владеют всеми тонкостями нотаций UML диаграмм? А то ведь можно все формально правильно нарисовать, но окажется, что важные нюансы ускользнули от читателей.
У нас вот программисты слово UML терпеть не могут, говорят "Ты лучше по простому нарисуй и на пальцах объясни".
-
У нас вот программисты слово UML терпеть не могут, говорят "Ты лучше по простому нарисуй и на пальцах объясни".
Понятно, что UML не есть стандарт, данный нам в ощущениях. Однако представим, что инженер-электронщик в ответ на предсталенную для него принципиальную схему электронного устройства говорит проектировщику: "Ты лучше по простому нарисуй и на пальцах объясни".
-
Тут такой вопрос: цель в том, чтобы продемонстрировать читателю диаграммы знание UML, или в том, чтобы читатель понял, как это должно работать?
Есть ли уверенность, что другие программисты владеют всеми тонкостями нотаций UML диаграмм? А то ведь можно все формально правильно нарисовать, но окажется, что важные нюансы ускользнули от читателей.
В любой области должны быть общие понятия, разделяемые всеми, чтобы иметь возможность понять друг друга, и общаться с друг другом.
Чтобы читатель понял что он читает, он прежде всего должен знать "язык" того, что он собирается читать.
Если вы хотите поговорить с англичанином вы должны знать английский.
UML наиболее распространенный язык для моделирования ПО.
У нас вот программисты слово UML терпеть не могут, говорят "Ты лучше по простому нарисуй и на пальцах объясни".
Язык "простого" у каждого свой.
И нарисовав "по-простому", такие программисты вряд ли друг друга поймут _однозначно_ и _правильно_.
Да, изучение UML - нелегкое дело.
А разве изучение C++ или Java или PHP проще? Если программисты осилили язык программирования, то UML для них - не проблема.
А в компетентности программистов, которые не хотят или не могут изучать UML, я бы усомнился
-
Если вы так хотите изучить UML, то вызовы процедур (чтобы вы не закладывали в это понятие) можно смоделировать диаграммой последовательности или диаграммой коммуникации.
Было бы отлично, если бы была возможность показать вызовы как ссылки в сети объектов, без указания того, когда вызов совершается. Просто сам факт вызова. Например, как на скриншоте показаны ссылки с одного объекта на другой.
Оставляю за собой право ошибаться в понимании задачи автора топика.
-
языка моделирования UML, признанного как наиболее удобного языка моделирования
Признанного кем?
google: наиболее удобный язык моделирования (https://www.google.ru/#hl=ru&gs_nf=3&tok=8MUvCMxtI6zgLtXUT9JTiQ&pq=%D0%BD%D0%B0%D0%B8%D0%B1%D0%BE%D0%BB%D0%B5%D0%B5%20%D1%83%D0%B4%D0%BE%D0%B1%D0%BD%D0%BE%D0%B3%D0%BE%20%D1%8F%D0%B7%D1%8B%D0%BA%D0%B0%20%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F&cp=21&gs_id=1l&xhr=t&q=%D0%BD%D0%B0%D0%B8%D0%B1%D0%BE%D0%BB%D0%B5%D0%B5+%D1%83%D0%B4%D0%BE%D0%B1%D0%BD%D1%8B%D0%B9+%D1%8F%D0%B7%D1%8B%D0%BA+%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F&pf=p&newwindow=1&sclient=psy-ab&oq=%D0%BD%D0%B0%D0%B8%D0%B1%D0%BE%D0%BB%D0%B5%D0%B5+%D1%83%D0%B4%D0%BE%D0%B1%D0%BD%D1%8B%D0%B9+%D1%8F%D0%B7%D1%8B%D0%BA+%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F&gs_l=&pbx=1&bav=on.2,or.r_gc.r_pw.r_cp.r_qf.&fp=464aac8fe3e8f12f&bpcl=38625945&biw=1680&bih=932&bs=1)
-
нарисовав "по-простому", такие программисты вряд ли друг друга поймут _однозначно_ и _правильно_.
UML однозначность и "правильность" не обеспечивает.
См. например: http://ru.wikipedia.org/wiki/UML (http://ru.wikipedia.org/wiki/UML)
...
Неточная семантика. ... Неточность описания самого UML одинаково отражается на пользователях и поставщиках инструментов, приводя к несовместимости инструментов из-за уникального трактования спецификаций
...
UML не имеет свойств полноты по Тьюрингу и любой сгенерированный код будет ограничен тем, что может разглядеть или предположить интерпретирующий UML инструмент.
...
-
представим, что инженер-электронщик в ответ на предсталенную для него принципиальную схему электронного устройства говорит проектировщику: "Ты лучше по простому нарисуй и на пальцах объясни".
Принципиальная схема электронного устройства является, в отличие от диаграмм UML, точной однозначной моделью устройства. Эта схема может быть через интернет загружена в САПРовскую систему любого китайского заводика, и на выходе технологической линии через сутки выползет готовая работающая печатная плата со всеми распянными компонентами. Подключил, и работает (в идеале, если отвлечься от исправления ошибок).
Аналогичные автоматические системы, в которые на вход подается набор UML диаграмм, а на выходе получается программный продукт, на практике оказываются неработоспособными, несмотря на многолетние труды фанатов UML. Именно в силу присущих UML врожденных проблем неполноты и неоднозначности.
-
Было бы отлично, если бы была возможность показать вызовы как ссылки в сети объектов, без указания того, когда вызов совершается. Просто сам факт вызова. Например, как на скриншоте показаны ссылки с одного объекта на другой.
Оставляю за собой право ошибаться в понимании задачи автора топика.
вы правильно поняли мою задачу
-
Аналогичные автоматические системы, в которые на вход подается набор UML диаграмм, а на выходе получается программный продукт, на практике оказываются неработоспособными, несмотря на многолетние труды фанатов UML. Именно в силу присущих UML врожденных проблем неполноты и неоднозначности.
На данный исторический момент UML возможно не идеальный язык моделирования,
Кстати мои затруднения выразить на UML вызовы процедур как раз и подтверждают это.
Однако, UML - лучший из того что есть.
-
Если вы так хотите изучить UML, то вызовы процедур (чтобы вы не закладывали в это понятие) можно смоделировать диаграммой последовательности или диаграммой коммуникации.
Элементом этих диаграмм являются объекты или линии хизни. Объекты обмениваются собщениями. Сообщения сигналы, которые можно моделирвоать и как вызовы процедур.
диаграмма последовательности вообще не подходит для моей задачи - она отображает хронологическую последовательность сообщений,
диаграмма коммуникации тоже не подходит - она отражает взаимодействующие объекты
-
Чтобы учесть все на что может повлиять изменение этой процедуры, я бы хотел составить схему вызовов: методы изобразить квадратиками, и линия со стрелкой показывала бы кто кого вызывает. Но хотелось бы все это сделать в рамках стандарта UML.
Вопрос в том, какая диаграмма в UML больше всего подходит для отображения связей между методами программы, между методами объектов программы?
В рамках стандарта UML это называется диаграммой объектов. Квадратики (прямоугольники) объекты одного суперкласса - "Метод" с двумя подклассами "Метод программы" и "Метод объекта". Линии - связи одной ассоциации. Стрелки - от вызывающего к вызываемому (вызывающий "знает", кого вызывает, а вызываемый не "знает", кто вызывает).
-
В рамках стандарта UML это называется диаграммой объектов. Квадратики (прямоугольники) объекты одного суперкласса - "Метод" с двумя подклассами "Метод программы" и "Метод объекта". Линии - связи одной ассоциации. Стрелки - от вызывающего к вызываемому (вызывающий "знает", кого вызывает, а вызываемый не "знает", кто вызывает).
Диаграмма объектов отображает взаимосвязи между объектами в какой-то конкретный момент времени, как будто описываемая система "заморожена".
То есть мне нужно будет изобразить как один метод вызывает другой метод на временном срезе. Это не то что мне нужно.
Мне нужно отобразить вызов не в конкретный момент, а вообще возможность вызова одного метода другим, неважно в какой момент времени и при каких условиях.
По результатам обсуждения я более склоняюсь к диаграмме состояний.
Каждый метод - это состояние моей программы. Переход из одного состояния в другие - будет показывать какие методы могут быть вызваны из текущего метода.
Как вам такое решение?
-
Каждый метод - это состояние моей программы. Переход из одного состояния в другие - будет показывать какие методы могут быть вызваны из текущего метода.
Как вам такое решение?
Если суть решаемой вами задачи (которую вы пока не объяснили) требует показать программу, как конечный автомат, состояние которого полностью характеризуется выполняемым в данный момент методом, то да.
-
Надо решить, что является предметом моделирования:
1) процесс выполнения программы - тогда поведенческая диаграмма (может и диаграмма состояний, но лучше - диаграмма деятельности, где вызов будет изображаться узлом вызова деятельности, или старая добрая блок-схема, где вызов будет обозначаться блоком вызова). Правда на таких диаграмме вам не нужны стрелки-переходы и все узлы и блоки, не связанные с вызовами (если не надо отображать условия, при которых происходит вызов или последовательность вызовов или что-нибудь еще);
2) структура программы (исходного текста) - тогда структурная диаграмма (см. ранее).
Предыдущее сообщение от div тоже об этом говорит.
-
Если суть решаемой вами задачи (которую вы пока не объяснили) требует показать программу, как конечный автомат, состояние которого полностью характеризуется выполняемым в данный момент методом, то да.
Ну как же... я в теме объяснил свою задачу.
Может быть не очень точно. Тогда сформулирую задачу еще раз:
Нужно к UML-модели модифицируемой программы добавить новую диаграмму.
На этой диаграмме будет отображена интересующая нас процедура программы и ее связи с другими методами, которые ее вызывают.
Это нужно для изменения этой процедуры, чтобы учесть влияние этих изменений на методы, которые ее вызывают.
Затем для каждого метода, изображенного на диаграмме и связанного с изменяемой процедурой (прямо или опосредованно через другие методы), будет проводиться оценка: нужно ли переделывать этот вызывающий метод в связи с изменением процедуры.
Диаграмма должна быть выполнена в стандарте UML.
-
Надо решить, что является предметом моделирования:
1) процесс выполнения программы - тогда поведенческая диаграмма (может и диаграмма состояний, но лучше - диаграмма деятельности, где вызов будет изображаться узлом вызова деятельности, или старая добрая блок-схема, где вызов будет обозначаться блоком вызова). Правда на таких диаграмме вам не нужны стрелки-переходы и все узлы и блоки, не связанные с вызовами (если не надо отображать условия, при которых происходит вызов или последовательность вызовов или что-нибудь еще);
2) структура программы (исходного текста) - тогда структурная диаграмма (см. ранее).
Предыдущее сообщение от div тоже об этом говорит.
Наверное, больше подходит - структура программы.
Тогда получается что для каждого отображаемого метода нужно сделать отдельный класс. А правильно ли это будет с точки зрения семантики UML?
-
Для каждого метода - отдельный ОБЪЕКТ. Все эти объекты одного КЛАССА - "Метод".
Для каждого вызова - отдельную СВЯЗЬ. Все эти связи одна АССОЦИАЦИЯ.
Диаграмма классов - простенькая, один класс "Метод" и одна ассоциация ("Метод"-"Метод").
Диаграмма объектов - на каждое состояние каждой программы (или того, в рамках чего осыществляются вызовы, может быть всей системы).
С точки зрения семантики это будет правильно.
-
Вы писали "Нужно к UML-модели модифицируемой программы добавить новую диаграмму."
Можно существующие диаграммы посмотреть?
-
Тогда сформулирую задачу еще раз:
Нужно к UML-модели модифицируемой программы добавить новую диаграмму.
На этой диаграмме будет отображена интересующая нас процедура программы и ее связи с другими методами, которые ее вызывают.
Это нужно для изменения этой процедуры, чтобы учесть влияние этих изменений на методы, которые ее вызывают.
Затем для каждого метода, изображенного на диаграмме и связанного с изменяемой процедурой (прямо или опосредованно через другие методы), будет проводиться оценка: нужно ли переделывать этот вызывающий метод в связи с изменением процедуры.
Диаграмма должна быть выполнена в стандарте UML.
ИМХО вы путаете задачу со способом ее решения.
Судя по всему, задача состоит не в том, чтоб нарисовать диаграмму "в стандарте UML", а в том, чтобы при изменении процедуры, учесть влияние этих изменений на методы, которые ее вызывают.
Признак, по которому можно предположить, что цель в этом - ключевое словосочетание "Это нужно для" в вашем тексте.
Далее, нарисовать диаграмму "в стандарте UML" является одним из возможных способов решения этой задачи. Выбор способа за вами - как вам удобнее.
Лично мне было бы удобнее, на порядок быстрее и нагляднее, просто видеть список имен методов, которые ее вызывают. Хотя бы потому, что из текста удобно копировать имена методов в форму Search для поиска их в исходниках.
Ну а современные средства разработки софта, типа Visal Studio, позволяют делать это парой щелчков мыши. Удивительно, что у вас используется такая древняя среда разработки, в которой нет способа стандартно решить эту задачу.
-
У меня был вынужденный длительный перерыв.
Возвращаюсь к обсуждению темы.
Для каждого метода - отдельный ОБЪЕКТ. Все эти объекты одного КЛАССА - "Метод".
Для каждого вызова - отдельную СВЯЗЬ. Все эти связи одна АССОЦИАЦИЯ.
На данный момент модель связей методов программы сделана мной при помощи диаграммы классов.
На этой диаграмме отдельный класс - это метод. Вызовы методов - это ассоциации между этими классами.
Получилось очень наглядно, видны все косвенные зависимости.
Однако, корректна ли эта диаграмма с точки зрения UML - я пока сомневаюсь.
Пока разбирался с этим вопросом много прочитал об UML. В том числе и его критики.
В какой-то мере эта критика справедлива, как показывает наше обсуждение.
С одной стороны: "UML (англ. Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения" (википедия)
А с другой стороны, вопрос связей методов в программе - это вопрос именно из области программного обеспечения, и на него мы не можем дать четкого и однозначного ответа, что подтверждает критику UML.
[из википедии]
Критика
Несмотря на то, что UML - достаточно широко распространённый и используемый стандарт, его часто критикуют из-за следующих недостатков:
Избыточность языка. UML часто критикуется, как неоправданно большой и сложный. Он включает много избыточных или практически неиспользуемых диаграмм и конструкций. Чаще это можно услышать в отношении UML 2.0, чем UML 1.0, так как более новые ревизии включают больше «разработанных-комитетом» компромиссов.
Неточная семантика. Так как UML определён комбинацией себя (абстрактный синтаксис), OCL (языком описания ограничений — формальной проверки правильности) и Английского (подробная семантика), то он лишен скованности присущей языкам, точно определённым техниками формального описания. В некоторых случаях абстрактный синтаксис UML, OCL и Английский противоречат друг другу, в других случаях они неполные. Неточность описания самого UML одинаково отражается на пользователях и поставщиках инструментов, приводя к несовместимости инструментов из-за уникального трактования спецификаций.
С "третьей" стороны следует признать, что альтернатив UML нету
-
ИМХО вы путаете задачу со способом ее решения.
Судя по всему, задача состоит не в том, чтоб нарисовать диаграмму "в стандарте UML", а в том, чтобы при изменении процедуры, учесть влияние этих изменений на методы, которые ее вызывают.
Признак, по которому можно предположить, что цель в этом - ключевое словосочетание "Это нужно для" в вашем тексте.
Далее, нарисовать диаграмму "в стандарте UML" является одним из возможных способов решения этой задачи. Выбор способа за вами - как вам удобнее.
Лично мне было бы удобнее, на порядок быстрее и нагляднее, просто видеть список имен методов, которые ее вызывают. Хотя бы потому, что из текста удобно копировать имена методов в форму Search для поиска их в исходниках.
Ну а современные средства разработки софта, типа Visal Studio, позволяют делать это парой щелчков мыши. Удивительно, что у вас используется такая древняя среда разработки, в которой нет способа стандартно решить эту задачу.
Нет, я не путаю задачу с решением.
Скажем так.
Задача-максимум - это как вы правильно заметили:
чтобы при изменении процедуры, учесть влияние этих изменений на методы, которые ее вызывают
Задача-минимум (или по вашему - решение задачи-максимум):
нарисовать диаграмму "в стандарте UML"
Т.е. нарисовать диаграмму связей методов в программе.
Да, решить задачу-максимум можно разными способами. Например, как вы предлагаете, списком методов.
Однако, мы (участники проекта) уже решили как ее будем решать, т.е. выбрали способ решения: при помощи диаграммы на UML.
И именно этот вопрос я задал в этой теме.
Кстати, список не поможет.
Как вы при помощи списка отследите и зафиксируете, что метод А вызывает метод Б не напрямую, а косвенно, через цепочку вызовов промежуточных методов С, Д, Е?
А на диаграмме это все прекрасно видно
-
Можно существующие диаграммы посмотреть?
А что это даст?
Вся модель огромная, какие-то кусочки вам особого смысла не раскроют: чтобы понять смысл - это нужно о-очень много времени.
На наших диаграммах также как и на других присутствуют квадратики и стрелочки.
Например, я приложил диаграмму - это кусочек предметной области самого верхнего уровня.
Я боюсь, что начиная обсуждать мои диаграммы, мы уйдем в сторону от построения новой интересующей меня диаграммы.
-
сообщение устарело
-
Мы делаем так..
Полная версия http://edu.reqcenter.pro/?p=3450
P.S. Картинка по ссылке вставилась без уменьшения. Как ее уменьшить?
а на чем вы это делаете?
в смысле какое программное средство используете?
-
сообщение устарело
-
Конкретно эта картинка из 3SL Cradle.
Полная связка по этому проекту:
MS Project - 3SL Cradle - PhpStorm + yii -Github
Управление проектом - управление требованиями и проектными данными, разработка моделей - разработка +фреймворк разработки, поддерживающий MVC - управление версиями
Связка впечатляет.
В MS Project сам работаю, а вот про другие средства не слышал
-
Инженеры Гугла, создавшие собственный инструмент для анализа зависимостей в сложных приложениях, не придерживаются стандартов UML: «Projects are modeled as generic dependency graphs, with many different node and relation types. For example, the Java module uses 6 different node types and 24 different relations»
http://google-opensource.blogspot.ru/2008/09/depan-dependency-analysis-tool.html
http://code.google.com/p/google-depan/
https://developers.google.com/java-dev-tools/codepro/doc/features/dependencies/dependencies
Тоже повод задуматься о компетентности этих инженеров?
-
Тоже повод задуматься о компетентности этих инженеров?
Я ни в чьей компетентности не сомневался.
-
…
А в компетентности программистов, которые не хотят или не могут изучать UML, я бы усомнился
…
я об этой фразе
-
я об этой фразе
а-а-а.
Ну тогда насчет инженеров гугла есть два варианта:
1) Они изучали UML, по крайней мере ознакомились с ним, но по каким-то наверное веским причинам, отказались от его использования. Тогда все нормально
2) Они не знакомились с UML.
В этом случае я свою фразу "...в компетентности программистов, которые не хотят или не могут изучать UML, я бы усомнился..." подтверждаю.
Ведь это еще студентам в институте преподают, что для построения модели одного вида схем или диаграмм недостаточно.
Следовательно, граф зависимостей, используемый инженерами гугла явно недостаточен для полного моделирования разрабатываемого ими ПО.
-
А я всё к тому, какое отношение имеет усомнился или не усомнился ли анонимный es3000 в чьей-то там компетентности, к теме дискуссии?
-
А я всё к тому, какое отношение имеет усомнился или не усомнился ли анонимный es3000 в чьей-то там компетентности, к теме дискуссии?
Так вроде вопрос с компетентностью еще в начале был закрыт.
А тут двумя постами выше вы опять его вроде подняли.
Мне пришлось защищаться объясняться
-
Я не видел, что был какой-то вопрос, и что он был как-то решён.
Я видел, что вы написали критическое замечание по поводу компетенций людей, с которыми никак не знакомы.
Я знаком.
Поэтому и пишу.
-
Я не видел, что был какой-то вопрос, и что он был как-то решён.
Я видел, что вы написали критическое замечание по поводу компетенций людей, с которыми никак не знакомы.
Я знаком.
Поэтому и пишу.
пусть будет "замечание".
так вот это замечание я сделал почти три месяца назад, и тогда это не вызвало таких обсуждений,
почему вы вдруг его сейчас вспомнили?
и еще вопрос.
что вы скажете о ... например, физике, который бы вам сейчас сказал:
"я про теорию относительности слышать не хочу, объясните мне что происходит в ядрах атомов на пальцах - при помощи классической механики"?
даже если этот физик вам знаком?
-
пусть будет "замечание".
так вот это замечание я сделал почти три месяца назад, и тогда это не вызвало таких обсуждений,
почему вы вдруг его сейчас вспомнили?
Потому что прочитал сейчас, и видел, что дискуссия продолжает разворачиваться как ни в чём ни бывало.
и еще вопрос.
что вы скажете о ... например, физике, который бы вам сейчас сказал:
"я про теорию относительности слышать не хочу, объясните мне что происходит в ядрах атомов на пальцах - при помощи классической механики"?
даже если этот физик вам знаком?
Что вы неправильно понимаете место UML в индустрии, только и всего. Впрочем, как и многие другие люди, одураченные обилием книг с заголовком, включающим этом слово, в книжных магазинах. С тем же успехом можно заменить названия этих книг на «В поисках вечного двигателя», «Как я изобрел вечный двигатель», «Почему так мало людей используют этот прекрасный вечный двигатель?», «В поисках святого грааля», «24 способа применения святого грааля».
-
Что вы неправильно понимаете место UML в индустрии, только и всего. Впрочем, как и многие другие люди, одураченные обилием книг с заголовком, включающим этом слово, в книжных магазинах. С тем же успехом можно заменить названия этих книг на «В поисках вечного двигателя», «Как я изобрел вечный двигатель», «Почему так мало людей используют этот прекрасный вечный двигатель?», «В поисках святого грааля», «24 способа применения святого грааля».
С одной но существенной разницей: вечного двигателя никто не видел, он не существует, и не решает никаких насущных проблем.
А теория относительности существует. Она кстати неидеальна. Но ее признают не потому что у нее красивое название. Просто вместо нее нету другой теории, которая бы позволяла описать наблюдаемые явления, и решать конкретные проблемы.
Также и с UML. Конечно, его заслуга не в красивых заголовках книг. А в том, что он позволяет решать конкретные проблемы, пусть и в достаточно ограниченной области деятельности.
Место UML понятно - моделирование.
Вы можете назвать другой инструмент, позволяющий описать модель программной системы, в виде взаимосвязанных диаграмм статических объектов системы и их динамического поведения?
-
es3000, Денис
Отличная дискуссия про значение и значимость UML. Однако может вы начнете новую тему дискуссии. Например
Место UML в индустрии ПО
Мифы и реальности UML
и т.п.
А то, ваши дискуссии носят не конструктивный (в рамках данной темы) характер. Спасибо
-
Тема ушла в другую сторону из-за моей фразы:
…
А в компетентности программистов, которые не хотят или не могут изучать UML, я бы усомнился
…
По справедливости, я был не прав. :-\
Denis Beskov, прошу меня извинить, в дальнейшем я постараюсь не говорить таких легкомысленных фраз.
Подключайтесь к обсуждению других моих тем.