166

Теория моделирования и нотации / Re: Какую диаграмму и нотацию использовать для моделирования вызовов процедур?

« : 13 Февраля 2013, 09:05:27 »

Тоже повод задуматься о компетентности этих инженеров?

Я ни в чьей компетентности не сомневался.

167

Теория моделирования и нотации / Re: Моделирование связей между сущностями "цель - задача - средство решения"

« : 13 Февраля 2013, 08:57:38 »

Перед тем как думать дальше, изучите остальные диаграммы Голдратта. "цель-задача-средство" это завершение анализа. Начало - "Дерево текущей реальности". Те же "причинно-следственные связи". Положите на изучение 3-5 лет и вперед.

буду изучать

168

Теория моделирования и нотации / Re: Моделирование связей между сущностями "цель - задача - средство решения"

« : 12 Февраля 2013, 18:02:26 »

Я вот подумал, глядя на Flying Logic.
Можно ли озвученную мной тему обобщить в "моделирование причинно-следственных связей"?

Ведь по сути, чтобы моделировать цель-задача-средство, нужно знать причинно-следственные связи между ними.
И получается, что изображая на схеме цели-задачи-средства, я по сути изображаю причинно-следственные связи между ними?

169

Теория моделирования и нотации / Re: Моделирование связей между сущностями "цель - задача - средство решения"

« : 12 Февраля 2013, 17:52:53 »

Зачем вам это?

Как зачем?
Человек думает образами. Никакое текстовое описание, или представление в виде списков и прочее не сравнится с графическим представлением информации.
Не зря же вы сами далее говорите о mind maps, значит понимаете зачем

С визуализацией иерархических связей с элементами сетевых вполне справляются редакторы «ментальных карт» — mind maps. Например, бесплатный XMind.

Да.
Но в mind maps отдельно не выделяются цели\задачи, это красивая рисовалка. По крайней мере мне так кажется. То есть схему, нарисованную в mind map, можно понять только если сам ее составлял, если сам знаешь тот смысл который закладываешь в каждый квадратик. Там нету семантики, нарисованный квадратик может обозначать все что хочешь: и действие, и объект и ограничение. Причем по внешним признакам этого квадратика это не определишь. Приходится написать комментарии, а это уже почти текстовое описание с некоторыми элементами образов.

Вот Flying Logic все-таки с первого взгляда будет получше, чем просто mind map

170

Теория моделирования и нотации / Re: Моделирование связей между сущностями "цель - задача - средство решения"

« : 12 Февраля 2013, 15:48:36 »

Можно использовать классический сетевой график. Из плюсов - о нем многие слышали. А дальше у него куча минусов.

Из современного и поддерживаемого мне нравится "Дерево перехода" и "План преобразований". По этому методу у меня получался наиболее вменяемый результат. Гораздо лучше сетевого графика и разных майндмапов.  Да, это сложно, но думать вообще сложно.
Можно скачать "Flying Logic" и руководство к ней "Thinking with Flying Logic". Есть на русском. http://flyinglogic.com/
Дополнительно можно посмотреть здесь: http://www.tocpeople.com/terminy/derevo-perexoda-dp/ но лучше сразу поискать книгу Детмера http://www.ozon.ru/context/detail/id/5288956/ .

Т.е. если вам нужны приличные результаты и есть время, то логические диаграммы + методы рационального мышления (http://lesswrong.ru/) - это моя рекомендация.

похоже, это то что я искал, спасибо,
подскажите где найти "Thinking with Flying Logic" на русском, там по ссылке вроде на английском

171

Теория моделирования и нотации / Re: Какую диаграмму и нотацию использовать для моделирования вызовов процедур?

« : 12 Февраля 2013, 14:52:23 »

Конкретно эта картинка из 3SL Cradle.

Полная связка по этому проекту:
MS Project - 3SL Cradle - PhpStorm + yii -Github
Управление проектом -  управление требованиями и проектными данными, разработка моделей - разработка +фреймворк разработки, поддерживающий MVC - управление версиями

Связка впечатляет.
В MS Project сам работаю, а вот про другие средства не слышал

172

Теория моделирования и нотации / Re: Моделирование связей между сущностями "цель - задача - средство решения"

« : 12 Февраля 2013, 14:50:25 »

Вот так?
Взято отсюда http://saturs.ru/index.php?r=block/plain&label=education-screen-examples-mir

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

173

Теория моделирования и нотации / Моделирование связей между сущностями "цель - задача - средство решения"

« : 12 Февраля 2013, 12:37:47 »

Подскажите пожалуйста,
существуют ли языки и средства моделирования для изображения в виде диаграммы упомянутых в теме сущностей и связей между ними: "цель - задача - средство решения".
С учетом их иерархии.
Это не связано с программным обеспечением, возможно это больше имеет отношение к бизнес-анализу?

Не могу пока четко сформулировать свой вопрос, попробую объяснить на примере.
Допустим, я вчера прилетел в незнакомый мне город и мне нужно сегодня в 15-00 быть в точке Б этого города, а сейчас я нахожусь в гостинице в точке А.
Для этого я должен выполнить следующие задачи:
1) одеться (так как меня разбудили звонком в кровати)
2) собрать информацию о транспорте, которым я могу добраться в точку Б, и выбрать наиболее подходящий транспорт
3) каким-то образом попасть на этот транспорт
4) на транспорте добраться до точки Б

Каждая из перечисленных 4-х задач является "задачей" по отношению к вышестоящей цели.
Однако, на уровне рассмотрения самой задачи, ее тоже нужно решить какими-то средствами, то есть на этом уровне задача делится на подзадачи, то есть она является "целью" для "нижележащих" подзадач.

Например.

Пункт (2) можно разделить на:
2.1. узнать телефоны головных организаций доступных видов транспорта в этом городе (такси, маршрутка, электричка)
2.2. позвонить по каждому из этих телефонов и узнать расписание движения, стоимость и прочее
Далее, чтобы узнать телефоны транспорта нужно:
2.1.1. позвонить в ресепшин гостиницы и узнать у них телефоны
и т.д.

Если я решил добираться на мартшрутке, то одна из подзадач пункта (4) будет выглядеть:
4.х.1. достать 30 руб. из кошелька
4.х.2. передать 30 руб. кондуктору (или водителю) маршрутки

И так далее, думаю идея понятна.

Так вот существуют ли программные средства моделирования таких зависимостей между отдельными действиями\операциями, чтобы из этой модели было ясно какой уровень иерархии рассматривается, что есть цель на этом уровне, какие задачи и (желательно) в какой последовательности должны быть выполнены и при помощи каких средств?

174

Теория моделирования и нотации / Re: Какую диаграмму и нотацию использовать для моделирования вызовов процедур?

« : 12 Февраля 2013, 12:03:22 »

Мы делаем так..
Полная версия http://edu.reqcenter.pro/?p=3450

P.S. Картинка по ссылке вставилась без уменьшения. Как ее уменьшить?

а на чем вы это делаете?
в смысле какое программное средство используете?

175

Теория моделирования и нотации / Re: Какую диаграмму и нотацию использовать для моделирования вызовов процедур?

« : 12 Февраля 2013, 11:46:08 »

Можно существующие диаграммы посмотреть?

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

Я боюсь, что начиная обсуждать мои диаграммы, мы уйдем в сторону от построения новой интересующей меня диаграммы.

176

Теория моделирования и нотации / Re: Какую диаграмму и нотацию использовать для моделирования вызовов процедур?

« : 12 Февраля 2013, 11:35:25 »

ИМХО вы путаете задачу со способом ее решения.

Судя по всему, задача состоит не в том, чтоб нарисовать диаграмму "в стандарте UML", а в том, чтобы при изменении процедуры, учесть влияние этих изменений на методы, которые ее вызывают.
Признак, по которому можно предположить, что цель в этом - ключевое словосочетание "Это нужно для" в вашем тексте.

Далее, нарисовать диаграмму "в стандарте UML" является одним из возможных способов решения этой задачи. Выбор способа за вами - как вам удобнее.
Лично мне было бы удобнее, на порядок быстрее и нагляднее, просто видеть список имен методов, которые ее вызывают. Хотя бы потому, что из текста удобно копировать имена методов в форму Search для поиска их в исходниках.
Ну а современные средства разработки софта, типа Visal Studio, позволяют делать это парой щелчков мыши. Удивительно, что у вас используется такая древняя среда разработки, в которой нет способа стандартно решить эту задачу.

Нет, я не путаю задачу с решением.

Скажем так.
Задача-максимум - это как вы правильно заметили:

чтобы при изменении процедуры, учесть влияние этих изменений на методы, которые ее вызывают

Задача-минимум (или по вашему - решение задачи-максимум):

нарисовать диаграмму "в стандарте UML"

Т.е. нарисовать диаграмму связей методов в программе.
Да, решить задачу-максимум можно разными способами. Например, как вы предлагаете, списком методов.
Однако, мы (участники проекта) уже решили как ее будем решать, т.е. выбрали способ решения: при помощи диаграммы на UML.
И именно этот вопрос я задал в этой теме.

Кстати, список не поможет.
Как вы при помощи списка отследите и зафиксируете, что метод А вызывает метод Б не напрямую, а косвенно, через цепочку вызовов промежуточных методов С, Д, Е?
А на диаграмме это все прекрасно видно

177

Теория моделирования и нотации / Re: Какую диаграмму и нотацию использовать для моделирования вызовов процедур?

« : 12 Февраля 2013, 11:25:05 »

У меня был вынужденный длительный перерыв.
Возвращаюсь к обсуждению темы.

Для каждого метода - отдельный ОБЪЕКТ. Все эти объекты одного КЛАССА - "Метод".
Для каждого вызова - отдельную СВЯЗЬ. Все эти связи одна АССОЦИАЦИЯ.

На данный момент модель связей методов программы сделана мной при помощи диаграммы классов.
На этой диаграмме отдельный класс - это метод. Вызовы методов - это ассоциации между этими классами.
Получилось очень наглядно, видны все косвенные зависимости.
Однако, корректна ли эта диаграмма с точки зрения UML - я пока сомневаюсь.

Пока разбирался с этим вопросом много прочитал об UML. В том числе и его критики.
В какой-то мере эта критика справедлива, как показывает наше обсуждение.
С одной стороны: "UML (англ. Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения" (википедия)
А с другой стороны, вопрос связей методов в программе - это вопрос именно из области программного обеспечения, и на него мы не можем дать четкого и однозначного ответа, что подтверждает критику UML.

[из википедии]

Критика

Несмотря на то, что UML - достаточно широко распространённый и используемый стандарт, его часто критикуют из-за следующих недостатков:

    Избыточность языка. UML часто критикуется, как неоправданно большой и сложный. Он включает много избыточных или практически неиспользуемых диаграмм и конструкций. Чаще это можно услышать в отношении UML 2.0, чем UML 1.0, так как более новые ревизии включают больше «разработанных-комитетом» компромиссов.

    Неточная семантика. Так как UML определён комбинацией себя (абстрактный синтаксис), OCL (языком описания ограничений — формальной проверки правильности) и Английского (подробная семантика), то он лишен скованности присущей языкам, точно определённым техниками формального описания. В некоторых случаях абстрактный синтаксис UML, OCL и Английский противоречат друг другу, в других случаях они неполные. Неточность описания самого UML одинаково отражается на пользователях и поставщиках инструментов, приводя к несовместимости инструментов из-за уникального трактования спецификаций.

С "третьей" стороны следует признать, что альтернатив UML нету

178

ПО Аналитика / Re: [Посчитаемся] Какие CASE средства с поддержкой UML вы используете?

« : 06 Февраля 2013, 14:19:28 »

Наверное, нужно самому сначала проголосовать

спасибо, сейчас сделаем

179

ПО Аналитика / Re: [Посчитаемся] Какие CASE средства с поддержкой UML вы используете?

« : 06 Февраля 2013, 09:48:49 »

как посмотреть результаты этого голосования?

180

ПО Аналитика / Re: Как в объектно-ориентированной модели (PowerDesigner) создать подсистему?

« : 06 Февраля 2013, 09:25:14 »

Подсистема в UML - это пакет со стереотипом подсистема. Делайте пакет - кладите туда свои классы, присваивайте пакет стереотип подсистема. Как-то так.

В моей модели для пакета нельзя присвоить такой стереотип.
Вообще в списке стереотипов для пакета у меня только одна строка - "Archive".

Я кажется разобрался в чем дело.
В свойствах моей модели для свойства "Object Language" указано "Java"
А если создать новую модель, и в свойстве "Object Language" указать другое значение, например "PowerBuilder", то для пакетов появляется стереотип "Subsystem"