По мотивам иногородней ветки Комплексирование:SADT+UML (для целей структурного анализа бизнес-системы). ...

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

Что такое "бизнес-система"/"Система" и каковы цели проекта? Если "Система" - это процессная система, т.е производство, организация или некая деятельность, то для ее описания вполне достаточно (хотя смотря, что требования к модели) ФСП, т.е SADT, т.к полученная модель "AS IS" может быть использована, например, для РБП и/или настройки коробочной ИС.
Если "Система" - это создаваемое вами ИС/ПО, то для ее создания достаточно и лучше использовать ООАП раз уж вы решились на методологический подход с моделированием.
Если же требуются обе модели и создается новая ИС, то есть определенные аргументы за то, чтобы не смешивать эти два очень разных подхода. "В одну телегу впрячь не можно коня и трепетную лань". Обсуждение этой темы было, кажется, в форуме Интерфейса - "Форум "Computer Associates" . Там есть поиск, но искать нужно за 2002 и 2003 года. Насколько мне помнится, там высказывался такой алгоритм: деятельности IDEF0 -> деятельности DFD <=> ВИ, т.е варианты использования - это эквиваленты деятельностей в модели DFD. Однако такой переход не всегда верен, например, с т.з ООАП, в к-ром ВИ не являются системными функциями

1. параллельно разрабатывается модель предметной области (ПО) (диаграмма классов) и функционально-структурная модель бизнес-процесса (SADT), формируется глоссарий предметной области состоящий из:словаря объектов ПО, и словаря функций, в ходе параллельной работы словари уточняются и дополняются, ..

А что такое "объекты ПО", т.е если это программные объекты или объекты БД, то какая связь ними и БП, описанными в SADT?

2. на основе анализа ФСМ выделяются прецеденты взаимодействия, анализируются требования к бизнес-системе (диаграммы прецедентов), на уровне ФСМ декомпозиция не производится, дальнейшее разделение функций посредством диаграммы прецедентов, ..

"на уровне ФСМ декомпозиция не производится" - то есть? В любом случае требуется декомпозиция контекстной функции

3. на основе построенных диаграмм прецедентов, с учетом модели ПО и словаря ПО строятся диаграммы последовательбностей. ..

А что такое такое "модель ПО" и "словарь ПО"? Модель ВИ как раз является моделью, описывающей, ЧТО должна делать система, т.е является частью концептуальной модели. А что за диаграммы последовательностей имеются в виду, т.е они относятся к модели анализа или к модели проектирования?

С учетом данного алгоритма осуществляется системное описание (морфология, функции, процессы) бизнес-системы.

Если вы хотите использовать ФСП даже для описания ИС, то зачем вообще связываться с ВИ?


2 Воронин Константин:
насчет SADT тоже размышлял... есть пожалуй аналогия между уровнями use-case у Кокбёрна и иерархией в IDEF0.

IMHO аналогия лишь внешняя, если только не понимать системные варианты использования (system use case), как функции, а это неверно с т.з (точки зрения) ООАП. У Коберна во "Writing Effective Use Cases" (WEUC) используется 3 уровня(level) описания ВИ с точки зрения протяженности во времени и вовлеченных в ВИ актеров ("1.2 Your use case is not my use case", page 22):

"Depending on the level of view needed at the time, the writer will choose to describe a multisitting
or summary goal , a single-sitting or user goal , or a part of a user goal, or subfunction .
Communicating which of these is being described is so important that my students have come up with two
different gradients to describe them: by height relative to sea level (above sea level, at sea level,
underwater), and by color (white, blue, indigo)."

..т.е ("Chapter 25. Appendix C: Glossary", page 246):

A "summary-level use case" is one that takes multiple user-goal sessions
  to complete, possibly weeks, months or years. Sub use cases can be any level
  of use case. Marked graphically with a cloud or a kite . The cloud is used
  for use cases that contain steps at cloud or kite level. The kite is used for use cases
  that contain user-goal steps.


A "user-goal use case" satisfies a particular and immediate goal of value
  to the primary actor. Typically performed by one primary actor in one
  sitting of 2-20 minutes (less if the primary actor is a computer), after which
  they can leave and proceed with other things. Steps are user-goal or lower.
  Marked graphically with waves .


A "subfunction use case" is one satisfying a partial goal of a user-goal
  use case or of another subfunction. Steps are lower-level subfunctions.
  Subfunction use cases support the user-goal use cases. They are only needed only
  are called from several by other use cases or isolate a complicated piece of behavior.
  Marked graphically with a fish or a clam . Using the clam signifies that the use case
  is too low level and should not be written at all.

В SADT же, как правило, используется функциональная декомпозиция , т.е представление функции или деятельности верхнего уровня в виде составляющих ее подфункций, связаных дугами, независимо от того сколько по времени, или одним или несколькими исполнителями (mechanism) выполняются эти подфункции

Мне кажется, если нет нужды в строго формальном описании, не стоит использовать SADT - лишняя работа и проблема с внесением изменений в модели.

Согласен с вами, если цель только создание собственной ИС, т.к SADT лучше всего подходит для описания бизнес-деятельности

Да и классические проблемы - куда отнести "печать документа на принтере" замучают :)

На самом деле проблема не в этом, т.к Р.Н. мог бы в Bpwin использовать вместе IDEF0 также и нотацию DFD для описания функций ИС, но в этом нет смысла, если цель - только создание ИС, т.к целиком ФСП типа SASD для создания ИС - это позавчерашний день

2 Р.Н.:
Как известно для комплексного описания любой социально-экономической / организационно-технической системы (бизнес-системы/Системы) необходимо описать три вида структур:
морфологическую , функциональную и процессную структуру.

А что значит "комплексного описания" и что вы имеете в виду под "функцией"? Т.е если под "функция" понимается также "свойство", "цель" и т.д, то, возможно, что такого описания будет достаточно, но опять все зависит от целей

Меня интересует предпочтительный выбор методов для разработки единой методики структурного моделирования, предназначенной для формализации задач системного анализа (с научной точки зрения), ...

То есть одна из ваших целей - выбор некого метода для разработки методики, т.е методов или методологии структурного моделирования? Также догадываюсь, но что именно имеется в виду под "задачей системного анализа"? Свой вопрос в форуме CFIN.RU Реинжиниринг, системный анализ не пробовали задавать?

предметная область---(методика)---(модель)---модель процесса ....

А показывает эта схема?

.. но может быть я идеалист,меня интересует возможность логического комплексирования SADT и UML через "мостик" USE CASE, который не является классическим объектным представлением, а является некоторым логическим методом определения контекста системы и в данном смысле слова является аналогом контекстной диаграммы - ICOM - блока.

Ради корректной терминологии: варианты использования (Use Cases) - это не метод (т.е это все равно, что сказать, что UML - это метод), а формат или способ описания поведения актеров и системы. Насчет контекста системы согласен, но не понятно почему ВИ являются аналогом контекстной диаграммы , т.к ВИ не являются функциями и для них не используется функциональная декомпозиция (при корректном использовании, например, в ООАП процессах) - см.выше пост Воронину Константину , т.е там нет "контекстного ВИ" вроде "UC0 Обслужить всех актеров" с разбиением на "составляющие ВИ"

(WEUC, 25. APPENDIX C: GLOSSARY)
A use case expresses a contract between the stakeholders of a system about
its behavior. It describes the system’s behavior and interactions under various
conditions as it responds to a request on behalf of the stakeholders, the primary
actor, showing how the primary actor’s goal gets delivered or fails.
The use case collects together the scenarios related to the primary actor’s goal.

use case (RUP v.2003, Glossary)
A description of system behavior, in terms of sequences of actions. A use case should
yield an observable result of value to an actor. A use case contains all flows of events
related to producing the "observable result of value", including alternate and exception
flows. ....
The specification of a sequence of actions, including variants, that a system (or other
entity) can perform, interacting with actors of the system.

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

А зачем нужен SADT, если используется ARIS? Т.е нотация EPC позволяет более полно описать процесс (в этой нотации больше элементов, чем даже в IDEF3),а для упрощенного описания поддерживается обычное дерево функций. Также в методах ARIS и средствах автоматизации типа ARIS Toolset/Designer, а также других, к-рые могут работать с ARIS ( ArcStyler MDA-Bustiness Transformer : а) процессные модели (EPC), модели данных (EM) и объектные модели (UML) могут совместно существовать как различные виды(view) на структуру предприятия и б) их объекты могут иметь связи трассировки, т.е объекты одних моделей могут быть автоматически и "гладко" преобразованы в объекты других. Вот, например, ArcStyler MDA-Business Transformer Modeling Style Guide For ARIS

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

Здорово! :о)


2 cvoronin:
Не уверен насчет (не)правильности с точки зрения ООАП. Ведь use-cases, вообще говоря, никакого непосредственного отношения к нему не имеют - это просто удобный способ для описания требования к системе.

Согласен, но упомяная ООАП я не имел в виду то, что ВИ могут быть использованы только с ООАП, а лишь то, что ООАП - широко распространенный процесс, использующий ВИ определенным образом, т.е это бралась как бы некая "точка отсчета"

А аналогия же вот чем навеяна. И у Кокбёрна, и у в IDEF0 берётся нечто верхнего уровня и потом это нечто раскрывается на более низких уровнях.

Да, но природа у декомпозиций разная: продолжительность/вовлеченные_актеры (Коберн (кстати, он сам против, чтобы его читали как Кок берн, т.е "петух, чл..н")) и функциональная (IDEF0). Не говоря уже про остальное, как вы сами верно заметили ниже

Ссылка на продолжительность при желании ;) легко обходится тем, что для высоких уровней прецедентов временные рамки не предполагаются :)

Как можно ее обойти если это неотьемлимая характеристика общего (summary level) ВИ, т.е он является таковым, если он "длится долго и/или в нем принимают участие разные актеры со своими целями"?

Есть, разумеется, и отличия. В частности, разная схема связей. В случае прецедентов она "более сетевая", а не ограничена одним (по количеству) отношением "входит-в". ....
... но типичная структура use-case'ов в функциональную иерархию не уложится (за счет extends, includes в частности). ......

Совершенно верно! Причем IDEF0 как раз и хорош своей функциональной "детализацией внутрь", например, при ФСА :о)

По мотивам иногородней ветки Не понимаю какие типы диаграмм использовать ...\r
\r
2 trotski: \r
У меня индийский заказчик уже год требует документацию на UML. Программа давно готова и писать под уже существующее не понимаю как. \r
Диаграмма классов - понятно, вопросов никаких. \r
Для драйвера написал Activity Diagram. А какую диаграмму использовать для описания работы с GUI? У меня 5 модальных окон, происходит прокрутка данных(аудиоредактор) выделение куска, фильтры и т.д. \r
Посоветуете? \r
\r
1. Лучше, чтобы заказчик сам объяснил, что он хочет от этих диаграмм. Это можно сделать буквально в двух словах: "диаграммы должный описывать это.. и это.. так.. и так".\r
Для описания модели GUI ("статической") необязательно использовать диаграммы UML, а можно использовать нарисованные, например, в MS Visio 2000-2003 с использованием Windows User Interface (Shapes: Software > Windows & Dialogs, Toolbars & Menus, Icons, Common Controls, Wizards ; Extras > Callouts и т.д).\r
Для стандартных ФХД приложений (учет, торговля и т.д) такая модель GUI делается очень быстро и просто, содержит все окна, диалоги и органы управления (контролы) приложения, а также пояснительные комментарии (ссылка на ВИ или просто текст "закрывает окно и завершает текущую сессию") к ним и показывает заказчику реальный вид будущего GUI (если не используются какие-нибудь навороты с GUI вроде пользовательских скинов, контролов и т.д).\r
Такая модель + описание системных вариантов использования/ВИ (Use Case) + нефункциональные требования (например, допустимые значения) + возможно прототип - это все, что нужно для работы с заказчиком, чтобы понять, что он хочет от L&F приложения, т.е соответственно для описания внешнего "вида" и функциональности\r
\r
2. Если заказчик требует, чтобы даже для модели GUI использовался UML, то можно использовать диаграммы деятельностей/состояний, чтобы показать последовательность использования контролов в ВИ, т.е в дереве модели в узле ВИ, помимо обычных диаграмм классов, взаимодействия и т.д, раскрывающих суть ВИ, содержатся еще и эти диаграммы. Например, в книге Лешек А. Мацяшек. «Анализ требований и проектирование систем. Разработка информационных систем с использованием UML.» (М.: «Вильямс», 2002. – 432 с., ISBN 5-845-90276-2, м/о) в главе 7.6.2. Диаграмма навигации по окнам и в 9.2.2. Диаграмма навигации по программе показано как использовать диаграммы деятельностей-состояний для этих целей. Также в топике Пример проектирования в Rational Rose есть ссылка на сайт Мацяшека, где он выложил модели в Rose к своей книге.\r
Однако IMHO такие диаграммы...\r
\r
не так просты для восприятия заказчиком, как модели Windows GUI в Visio,\r
  т.е они используют кучу стереотипов типа <<выпадающий список>> вместо\r
  реального вида контрола;\r

избыточны при наличии полных (full dressed) спецификаций ВИ и описывающих\r
  альтернативные и исключительные потоки/пути сценария, т.е уже есть текст,\r
  описывающий работу пользователя с GUI;\r

не всегда несут в себе достаточно информации: например, у Мацяшека на стр.308\r
  стрелка перехода состояния (state transition), соединяющая кнопки "Save" и "Clear"\r
  c границей окна (state), т.е показывающие, что состояние GUI не меняется\r
  и больше ничего - хотя также можно использовать дополнительные комментарии,\r
  описывающие команду, связанную с контролом.

... Но почему программистов искусственно делят на "быдло" - им только public методы доступны, и "элиту" - им еще и protected?

Вы все справедливо заметили, но ваш вопрос к тем, кто и проектирует классы/компоненты подобным образом. Причин подобных ляпов может быть сколько угодно: от банальной неграмотности, не понимания собственной системы в целом (т.е ЧТО должно быть "видно" и зачем) и кончая проектированием в попыхах или в режиме "low priority", т.е просто тяп-ляп :о)

2 mir:
Где та грань, которая четко отделяет protected метод от public метода?

Грань выбирается (я не беру случаи, когда проектирование делается тяп-ляп) из очень простых соображений, например, целесообразности и простоты интерфейса: public методы - чтобы удовлетворить типичные потребности при использовании объекта, protected - чтобы использовать нестандатрные и дополнительные возможности (их может быть масса), т.е в производном классе я могу их использовать; из соображений безопасности: public методы - обязательно должны содержать проверку передаваемых значений, protected - могут не содержать, т.к в производном классе может быть реализована своя проверка и т.д и т.п

И вообще, нужны ли protected методы даже теоретически?

Теоретически - да, т.к без них не реализовать все возможные типы видимости, к-рые могут понадобиться разработчикам. Например, MSDN ("Visual C++ Documentation"):

Class members declared as protected can be used only by the following:

* Member functions of the class that originally declared these members.
* Friends of the class that originally declared these members.
* Classes derived with public or protected access from the class that originally
declared these members.

Direct privately derived classes that also have private access to protected members.
Protected members are not as private as private members, which are accessible only to members
of the class in which they are declared, but they are not as public as public members, which
are accessible in any function. ....

Практически также бывают нужны, но, конечно, реже, чем public методы