Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Сергей()

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 »
151
Вот так?
Взято отсюда http://saturs.ru/index.php?r=block/plain&label=education-screen-examples-mir

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

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

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

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

Например.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Скажем так.
Задача-максимум - это как вы правильно заметили:
Цитировать
чтобы при изменении процедуры, учесть влияние этих изменений на методы, которые ее вызывают

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

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

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

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

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

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

Цитировать
[из википедии]

Критика

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

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

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

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

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

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

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

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

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

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

160
Создаю модель в PowerDesigner (object-oriented model).
На диаграмме верхнего уровня (Class Diagram) хочу нарисовать, что вся система состоит из нескольких подсистем.
Вроде бы все просто. В спецификации языка UML есть подсистемы.

Но в PowerDesigner-е значка для подсистемы не нашел :(

Помогите разобраться в чем дело?

161
Надо решить, что является предметом моделирования:
1) процесс выполнения программы - тогда поведенческая диаграмма (может и диаграмма состояний, но лучше - диаграмма деятельности, где вызов будет изображаться узлом вызова деятельности, или старая добрая блок-схема, где вызов будет обозначаться блоком вызова). Правда на таких диаграмме вам не нужны стрелки-переходы и все узлы и блоки, не связанные с вызовами (если не надо отображать условия, при которых происходит вызов или последовательность вызовов или что-нибудь еще);
2) структура программы (исходного текста) - тогда структурная диаграмма (см. ранее).

Предыдущее сообщение от div тоже об этом говорит.

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

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

Ну как же... я в теме объяснил свою задачу.
Может быть не очень точно. Тогда сформулирую задачу еще раз:

Нужно к UML-модели модифицируемой программы добавить новую диаграмму.
На этой диаграмме будет отображена интересующая нас процедура программы и ее связи с другими методами, которые ее вызывают.
Это нужно для изменения этой процедуры, чтобы учесть влияние этих изменений на методы, которые ее вызывают.
Затем для каждого метода, изображенного на диаграмме и связанного с изменяемой процедурой (прямо или опосредованно через другие методы), будет проводиться оценка: нужно ли  переделывать этот вызывающий метод в связи с изменением процедуры.
Диаграмма должна быть выполнена в стандарте UML.

163
В рамках стандарта UML это называется диаграммой объектов. Квадратики (прямоугольники) объекты одного суперкласса - "Метод" с двумя подклассами "Метод программы" и "Метод объекта". Линии - связи одной ассоциации. Стрелки - от вызывающего к вызываемому (вызывающий "знает", кого вызывает, а вызываемый не "знает", кто вызывает).
Диаграмма объектов отображает взаимосвязи между объектами в какой-то конкретный момент времени, как будто описываемая система "заморожена".
То есть мне нужно будет изобразить как один метод вызывает другой метод на временном срезе. Это не то что мне нужно.
Мне нужно отобразить вызов не в конкретный момент, а вообще возможность вызова одного метода другим, неважно в какой момент времени и при каких условиях.

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

164
Если вы так хотите изучить UML, то вызовы процедур (чтобы вы не закладывали в это понятие) можно смоделировать диаграммой последовательности или диаграммой коммуникации.

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

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

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 »